Proxy cho n8n: cấu hình HTTP Request không có 403 (2026)

```html

Bạn đã xây dựng workflow trong n8n, nó hoạt động trong hai tuần, và sau đó bắt đầu gặp lỗi 403 Forbidden. Suy nghĩ đầu tiên là “trang web bị hỏng” hoặc “mã xác thực đã hết hạn”. Thường thì vấn đề nằm ở chỗ khác: máy chủ mục tiêu đã nhận ra rằng yêu cầu không đến từ trình duyệt, mà từ một tự động hóa đang hoạt động với IP trung tâm dữ liệu của VPS của bạn. n8n có cơ chế proxy tích hợp — chỉ là nó không được bật theo mặc định, và một số cài đặt nằm ở nơi mà người dùng thường không tìm thấy.

Chúng ta sẽ phân tích từng bước: nơi nào thiết lập proxy trong n8n, sự khác biệt giữa self-hosted và Cloud, và ba cạm bẫy nào tiêu tốn nhiều thời gian nhất.

Tại sao n8n bị chặn thường xuyên hơn trình duyệt của bạn

n8n là nền tảng tự động hóa mã nguồn mở lớn nhất: gần 198 nghìn sao và 59,6 nghìn fork trên GitHub, phiên bản hiện tại vào thời điểm xuất bản là [email protected] (24 tháng 7 năm 2026). Sự phổ biến có mặt trái của nó: các hệ thống chống bot rất hiểu cách mà nó hoạt động trên mạng.

Có ba yếu tố kết hợp lại:

User-Agent tiết lộ bạn ngay lập tức. Đây không phải là một giả thuyết, mà là hành vi đã được tài liệu hóa chính thức. Trong n8n có biến N8N_ENFORCE_GLOBAL_USER_AGENT (mặc định là false), và tài liệu mô tả rõ ràng mục đích của nó: thay thế chuỗi User-Agent “trần” n8n bằng một chuỗi tương thích với RFC Mozilla/5.0 (compatible; n8n/<version>; +https://n8n.io/), nhằm ngăn chặn việc chặn yêu cầu bởi tường lửa của các ứng dụng web. Vấn đề đã dẫn đến các báo cáo lỗi: trong issue #28280 (mở vào ngày 10 tháng 4 năm 2026, đã đóng) mô tả cách mà các node gốc trả về bare-UA n8n, và các trang web phản hồi 403 với lý do “Bad User-Agent”. Node HTTP Request tự nó sử dụng axios và dễ dàng bị nhận diện mà không có tiêu đề thủ công.
IP của máy chủ của bạn là từ trung tâm dữ liệu. n8n gần như luôn chạy trên VPS hoặc trong đám mây. Những dải IP này được biết đến công khai và được đánh dấu là “không phải người dùng”: một số trang web cắt giảm chúng nghiêm ngặt hơn, thậm chí với giới hạn yêu cầu thấp hơn nhiều so với các kết nối gia đình.
Tốc độ yêu cầu không giống con người. Node trong vòng lặp phát hành hàng chục yêu cầu mỗi giây từ một địa chỉ — đây là một kịch bản cổ điển dẫn đến việc giới hạn tần suất và sau đó là việc chặn IP.

Bước 1. Proxy trong chính node (hoạt động cả trên Cloud)

Cách nhanh nhất là thiết lập proxy cho một HTTP Request cụ thể:

Mở node HTTP Request.
Ở dưới cùng, nhấn Add Option và chọn Proxy — đây là trường văn bản cho URL của máy chủ proxy.
Nhập chuỗi theo định dạng tiêu chuẩn với xác thực: http://TÊN_NGƯỜI_DÙNG:MẬT_KHẨU@host:port.
Ở đó, thêm tùy chọn tiêu đề: bật Send Headers và đặt User-Agent của trình duyệt thực — sao chép thủ công chuỗi hiện tại từ DevTools của Chrome của bạn.

Cách này là cách duy nhất có sẵn trên n8n Cloud: ở đó bạn không quản lý môi trường thực thi, vì vậy các biến môi trường hệ thống không có sẵn cho bạn, và IP xuất ra không cố định và thay đổi từ lần chạy này sang lần chạy khác. Điểm cộng của phương pháp này là tính chi tiết: các node khác nhau trong cùng một workflow có thể sử dụng các proxy và địa lý khác nhau. Điểm trừ — nếu có hai mươi node, bạn sẽ phải chỉnh sửa hai mươi chỗ.

Bước 2. Proxy toàn cầu qua biến môi trường (self-hosted)

Trên máy chủ của bạn, hợp lý hơn là bao phủ toàn bộ lưu lượng xuất ra cùng một lúc. n8n đọc các biến tiêu chuẩn:

HTTP_PROXY — URL proxy cho lưu lượng HTTP không mã hóa của các node;
HTTPS_PROXY — tương tự cho các yêu cầu TLS/SSL (trong thực tế đây là tham số chính của bạn);
ALL_PROXY — được sử dụng khi không có HTTP_PROXY/HTTPS_PROXY cụ thể hơn được chỉ định;
NO_PROXY — danh sách các máy chủ cách nhau bằng dấu phẩy, mà n8n sẽ truy cập trực tiếp mà không qua proxy.

Trong docker-compose.yml nó trông như thế này:

HTTPS_PROXY=http://TÊN_NGƯỜI_DÙNG:MẬT_KHẨ[email protected]:8080
NO_PROXY=localhost,127.0.0.1,postgres,n8n.example.com
N8N_ENFORCE_GLOBAL_USER_AGENT=true

Nhất định phải điền NO_PROXY. Nếu không, thông qua proxy bên ngoài, cả các yêu cầu nội bộ sẽ bị ảnh hưởng — đến Postgres của bạn, đến các container lân cận, đến miền webhook của riêng bạn. Triệu chứng — “mọi thứ bị hỏng sau khi bật proxy”, mặc dù các trang mục tiêu lại bắt đầu mở ra.

Nếu bạn muốn không tiết lộ phiên bản n8n ra ngoài, thay vì chuỗi RFC, hãy đặt chuỗi của riêng bạn qua N8N_GLOBAL_USER_AGENT_VALUE — nó sẽ ghi đè giá trị mặc định. Logic chung của việc cấu hình lưu lượng container cũng giống như trong các kịch bản khác: phân tích định dạng và những cạm bẫy tiềm ẩn có trong hướng dẫn về proxy cho các container Docker.

Bước 3. Ba cạm bẫy làm mất thời gian buổi tối

Cạm bẫy 1: đăng ký biến quyết định

Điều này không rõ ràng và gần như không xuất hiện trong các hướng dẫn. n8n xử lý các biến kết thúc bằng _PROXY thông qua gói npm proxy-from-env, và nó áp đặt thứ tự ưu tiên của riêng mình: các biến chữ thường (http_proxy) có ưu tiên hơn các biến chữ hoa (HTTP_PROXY), nếu cả hai đều được chỉ định. Kịch bản đau đớn cổ điển: trong hệ thống đã có một https_proxy bị quên từ lâu, bạn cẩn thận chỉ định HTTPS_PROXY trong compose — và lưu lượng vẫn kiên quyết đi qua địa chỉ cũ. Kiểm tra cả hai kiểu chữ.

Một chi tiết riêng cho Enterprise: biến proxy cho các yêu cầu đến máy chủ cấp phép https_proxy_license_server phải là chỉ chữ thường, định dạng — https://user:pass@proxy:port.

Cạm bẫy 2: Code node không làm được điều bạn dự định

Một lời khuyên thường thấy từ các diễn đàn — “hãy viết yêu cầu của bạn trong Code node qua axios với agent proxy”. Mặc định điều này sẽ không hoạt động: n8n tắt nhập các module trong Code node. Bạn phải cho phép chúng một cách rõ ràng — NODE_FUNCTION_ALLOW_BUILTIN cho các module tích hợp và NODE_FUNCTION_ALLOW_EXTERNAL cho các module bên ngoài (từ n8n/node_modules). Một điểm bổ sung: nếu bạn có task runners ở chế độ bên ngoài, các biến này được chỉ định không trong môi trường của container, mà trong cấu hình của các runner /etc/n8n-task-runners.json như env-override. Dễ dàng và an toàn hơn là giữ lại tùy chọn Proxy trong node.

Cạm bẫy 3: có proxy nhưng tốc độ vẫn như cũ

Proxy thay đổi địa chỉ, nhưng không thay đổi hành vi. Nếu workflow vẫn phát hành một loạt yêu cầu, bạn chỉ đơn giản là sẽ đốt cháy các IP mới. Trong cùng node đó có các bộ phận tích hợp:

Batching — Items per Batch (bao nhiêu mục trong một lô) và Batch Interval tính bằng mili giây (0 = không có khoảng dừng). Đặt lô từ 1–5 và khoảng dừng từ 1000–3000 ms.
Timeout — tính bằng mili giây; các kênh cư trú chậm hơn các kênh từ trung tâm dữ liệu, mặc định cần được nâng lên.
Response → Never Error — không làm rơi toàn bộ workflow chỉ vì một lỗi 403 đầu tiên, cho phép xử lý mã phản hồi bằng cách phân nhánh.
Pagination — chế độ Update a Parameter và Response Contains Next URL thay vì các vòng lặp tự chế.

Ở cấp độ instance, tốc độ bị giới hạn bởi N8N_CONCURRENCY_PRODUCTION_LIMIT (mặc định là -1, tức là không có giới hạn) — một giá trị hợp lý sẽ bảo vệ cả bể proxy và máy chủ. Thêm thông tin về cách các nền tảng tính toán yêu cầu của bạn và những gì cần làm với các giới hạn, có trong phân tích vượt qua giới hạn tần suất qua proxy.

Proxy nào nên sử dụng cho n8n

Việc lựa chọn không phụ thuộc vào “độ ngầu”, mà phụ thuộc vào ai ở đầu bên kia.

Proxy từ trung tâm dữ liệu. Rẻ và nhanh. Phù hợp cho các API chính thức, dịch vụ nội bộ, các trang web thân thiện với bot và bất kỳ nhiệm vụ nào cần một địa chỉ tĩnh ổn định — ví dụ, để IP của bạn được đưa vào danh sách trắng của đối tác. Trên các nền tảng bảo mật, chúng sẽ cho bạn đúng lỗi 403 như VPS trần: các dải IP của chúng đã được biết đến. Đây là cơ sở cho các nhiệm vụ hàng loạt không có chống bot.
Proxy từ nhà ở. Địa chỉ của các nhà cung cấp thực tế — điều cần thiết cho việc thu thập dữ liệu từ các trang web có bảo vệ nghiêm ngặt, cho nội dung phụ thuộc vào địa lý và theo dõi giá cả. Đối với các workflow truy cập các trang web công khai, proxy từ nhà ở là mặc định hiệu quả: hãy lấy sự luân phiên theo yêu cầu cho việc thu thập dữ liệu hàng loạt và các phiên sticky, khi cần giữ một phiên trên chuỗi các node.
Proxy di động. Mức độ tin cậy cao nhất: một nhà điều hành có hàng ngàn thuê bao sống, việc chặn một IP như vậy là tốn kém cho trang web. Được sử dụng ở những nơi mà việc chặn diễn ra nghiêm ngặt nhất — làm việc với mạng xã hội và ứng dụng nhắn tin. Đổi lại, bạn sẽ phải trả giá bằng tốc độ và chi phí.

Sơ đồ thực tiễn cho một workflow hỗn hợp: API chính thức — trực tiếp hoặc qua proxy từ trung tâm dữ liệu, các trang web công khai — qua proxy từ nhà ở, mạng xã hội — qua proxy di động. Tùy chọn Proxy được cấu hình riêng cho từng node, vì vậy bạn có thể kết hợp tất cả điều này trong một kịch bản mà không cần phải sử dụng các giải pháp tạm thời.

Danh sách kiểm tra trước khi khởi động

Proxy đã được thiết lập — hoặc là tùy chọn Proxy trong node, hoặc qua HTTPS_PROXY; trên Cloud chỉ có tùy chọn đầu tiên.
Cả hai kiểu chữ của biến đã được kiểm tra — chữ thường ghi đè chữ hoa.
NO_PROXY bao gồm localhost, cơ sở dữ liệu và các máy chủ nội bộ.
User-Agent đã được thay thế: N8N_ENFORCE_GLOBAL_USER_AGENT=true hoặc tiêu đề riêng của bạn trong node. Đồng thời kiểm tra tính nhất quán của các tiêu đề khác — một tập hợp tiêu đề không nhất quán sẽ tiết lộ tự động hóa không kém gì chính User-Agent.
Bật Batching với khoảng dừng không bằng không.
Chạy thử nghiệm trên 3–5 mục, thay vì toàn bộ danh sách.

Kết luận

Lỗi 403 trong n8n — hầu như luôn là không chỉ một lý do, mà là tổng hợp của ba yếu tố: User-Agent dễ nhận diện, IP từ trung tâm dữ liệu và tốc độ yêu cầu quá đều. Điều này cũng cần được khắc phục bằng một bộ giải pháp, chứ không chỉ bằng một tùy chọn: thay thế UA, chuyển lưu lượng qua proxy loại cần thiết và làm chậm node qua Batching. Tất cả ba yếu tố này đã được tích hợp sẵn trong nền tảng — chỉ cần tìm và bật chúng lên.

Cách dễ nhất để bắt đầu là sử dụng kênh từ nhà ở cho các node gặp vấn đề nhất và từ trung tâm dữ liệu cho các node còn lại: việc thanh toán với ProxyCove dựa trên lưu lượng, vì vậy bạn có thể lấy một khối lượng tối thiểu cho các thử nghiệm và xem cách mà workflow của bạn hoạt động. Chọn proxy cho nhiệm vụ và điền chuỗi vào trường Proxy — chỉ mất vài phút.