您在 n8n 中创建了工作流，它运行了两周，然后开始稳定地出现 403 Forbidden 错误。 第一个想法是“网站坏了”或“凭证过期了”。但通常情况是：目标服务器发现请求不是来自浏览器，而是来自使用您 VPS 数据中心 IP 的自动化程序。n8n 有一个内置的代理机制——只是默认情况下没有启用，并且部分设置的位置并不是人们通常寻找的地方。
我们来逐步分析：在 n8n 中代理的设置位置，self-hosted 和 Cloud 的区别，以及哪些三大陷阱最耗时间。
为什么 n8n 被封锁的频率高于您的浏览器
n8n 是最大的开源自动化平台：在 GitHub 上几乎有 198,000 个星标和 59,600 个分支，截至发布时的最新版本是 [email protected]（2026 年 7 月 24 日）。受欢迎的背后有其反面：反机器人系统非常清楚它的网络特征。
有三个因素影响：
- User-Agent 立即暴露了您。 这不是猜测，而是官方记录的行为。在 n8n 中有一个变量
N8N_ENFORCE_GLOBAL_USER_AGENT（默认值为false），文档明确描述了它的用途：将“裸露”的 User-Agent 字符串n8n替换为符合 RFC 的Mozilla/5.0 (compatible; n8n/<version>; +https://n8n.io/)，以 防止请求被 Web 应用防火墙阻止。这个问题甚至导致了错误报告：在问题 #28280（于 2026 年 4 月 10 日开设，已关闭）中描述了原生节点返回 bare-UAn8n的情况，而网站则以 403 响应，原因是“Bad User-Agent”。HTTP Request 节点在底层使用 axios，且没有手动设置的头部很容易被识别。 - 您的服务器 IP 是数据中心的。 n8n 几乎总是运行在 VPS 或云上。这些范围是公开已知的，并被标记为“非用户”的：某些平台对它们的限制更严格，甚至请求限制比家庭连接低得多。
- 请求频率不人道。 节点在循环中每秒发出数十个请求，这就是经典的速率限制触发和后续 IP 封禁。
步骤 1. 在节点中设置代理（在 Cloud 上也有效）
最快的方法是为单个 HTTP Request 精确设置代理：
- 打开节点 HTTP Request。
- 在底部点击 Add Option 并选择 Proxy——这是用于代理服务器 URL 的文本框。
- 输入标准格式的授权字符串：
http://用户名:密码@host:port。 - 在同一位置添加头部选项：启用 Send Headers 并手动复制您 Chrome DevTools 中的真实浏览器的
User-Agent字符串。
这种方法是 n8n Cloud 上唯一可用的：在那里您无法管理运行环境，因此系统环境变量对您不可用，且外发 IP 不固定，每次启动时都会更改。此方法的优点是粒度：同一工作流的不同节点可以通过不同的代理和不同的地理位置进行请求。缺点是，如果有二十个节点，您需要在二十个地方进行修改。
步骤 2. 通过环境变量设置全局代理（self-hosted）
在自己的服务器上，合理的做法是一次性封装所有外发流量。n8n 读取标准变量：
HTTP_PROXY——用于节点的未加密 HTTP 流量的代理 URL；HTTPS_PROXY——用于 TLS/SSL 请求的代理 URL（在实践中这是您的主要参数）；ALL_PROXY——在没有更具体的HTTP_PROXY/HTTPS_PROXY时使用；NO_PROXY——逗号分隔的主机列表，n8n 将直接绕过代理访问这些主机。
在 docker-compose.yml 中，这样写：
HTTPS_PROXY=http://用户名:密码@gate.provider.com:8080NO_PROXY=localhost,127.0.0.1,postgres,n8n.example.comN8N_ENFORCE_GLOBAL_USER_AGENT=true
务必填写 NO_PROXY。 否则通过外部代理的请求也会影响内部请求——比如对您的 Postgres、相邻容器、您自己的 Webhook 域的请求。症状是“在启用代理后，一切都坏了”，尽管目标网站恰好开始正常访问。
如果您希望不向外部暴露 n8n 的版本，可以通过 N8N_GLOBAL_USER_AGENT_VALUE 设置您自己的 RFC 字符串——这将覆盖默认值。容器流量的设置逻辑与其他场景相同：格式和潜在问题的解析可以在 Docker 容器代理 的指南中找到。
步骤 3. 三个陷阱，偷走您的时间
陷阱 1: 变量注册决定一切
这并不明显，几乎在教程中没有提到。n8n 通过 npm 包 proxy-from-env 处理以 _PROXY 结尾的变量，而该包强制执行自己的优先级顺序：小写形式（http_proxy）优先于大写形式（HTTP_PROXY），如果两者都被设置。经典的痛苦场景是：系统中早已存在一个被遗忘的 https_proxy，您在 compose 中小心地设置了 HTTPS_PROXY——而流量却顽固地走向旧地址。请检查两个注册。
企业版的一个特别细节：用于请求许可证服务器的代理变量 https_proxy_license_server 必须是 小写的，格式为 https://user:pass@proxy:port。
陷阱 2: Code node 无法实现您的想法
论坛上的常见建议是“在 Code node 中通过 axios 和代理代理编写请求”。默认情况下这不会生效：n8n 禁用 Code node 中的模块导入。必须显式允许它们——NODE_FUNCTION_ALLOW_BUILTIN 用于内置模块，NODE_FUNCTION_ALLOW_EXTERNAL 用于外部模块（来自 n8n/node_modules）。另一个细节是：如果您的任务运行器处于外部模式，这些变量不是在容器环境中设置的，而是在运行器配置 /etc/n8n-task-runners.json 中作为 env-override 设置。保持使用节点中的 Proxy 选项更简单和安全。
陷阱 3: 有代理，但请求频率不变
代理更改了地址，但未更改行为。如果工作流仍然发出一连串请求，您只会消耗新的 IP。在同一节点中有内置的延迟：
- Batching——每批项（每批多少个元素）和 批间隔 以毫秒为单位（
0= 无延迟）。设置批次为 1-5，间隔为 1000-3000 毫秒。 - Timeout——以毫秒为单位；驻留通道比数据中心的慢，默认值应该提高。
- Response → Never Error——不会在第一个 403 时崩溃整个工作流，允许通过分支处理响应代码。
- Pagination——使用 Update a Parameter 和 Response Contains Next URL 模式，而不是自定义循环。
在实例级别，速率限制由 N8N_CONCURRENCY_PRODUCTION_LIMIT 控制（默认值为 -1，即无限制）——合理的值将保护代理池和服务器。有关平台如何计算您的请求以及如何处理限制的更多信息，请参见 通过代理绕过速率限制 的分析。
选择适合 n8n 的代理
选择并不取决于“酷炫程度”，而是取决于另一端是谁。
- 数据中心代理。 便宜且快速。适用于官方 API、内部服务、友好的机器人网站以及任何需要稳定静态地址的任务——例如，让您的 IP 被合作伙伴列入白名单。在受保护的平台上，它们会返回与裸露 VPS 相同的 403：它们的范围是已知的。这是 无反机器人包任务 的基础。
- 住宅代理。 真实家庭提供商的地址——这是从具有强大保护的网站收集数据、地理依赖内容和价格监控所需的。对于访问公共网站的工作流，住宅代理 是有效的默认选择：在大规模解析时选择按请求轮换，并在需要在节点链上保持一个会话时使用 sticky 会话。
- 移动代理。 最高的信任级别：一个运营商背后有成千上万的真实用户，封禁这样的 IP 对平台来说代价高昂。适用于限制最严格的地方——社交媒体和即时通讯的工作。为此，您需要付出速度和价格的代价。
混合工作流的实用方案：官方 API——直接或通过数据中心，公共网站——通过住宅代理，社交媒体——通过移动代理。代理选项在每个节点上单独配置，因此可以在一个场景中无缝组合。
启动前检查清单
- 代理已设置——要么在节点的 Proxy 选项中，要么通过
HTTPS_PROXY；在 Cloud 上仅提供第一个选项。 - 检查两个变量的注册——小写会覆盖大写。
NO_PROXY关闭 localhost、数据库和内部主机。- User-Agent 已替换：
N8N_ENFORCE_GLOBAL_USER_AGENT=true或节点中的自定义头部。同时检查其他头部的一致性——不一致的头部集合同样会暴露自动化。 - 启用 Batching，设置非零间隔。
- 在 3-5 个元素上进行了测试，而不是整个列表。
结论
在 n8n 中出现 403 错误几乎总是有多个原因，而是三者的总和：可识别的 User-Agent、数据中心 IP 和过于均匀的请求频率。解决方案也需要一整套，而不是单一的选项：替换 UA，通过所需类型的代理引导流量，并通过 Batching 限制节点。所有这三种机制都已内置于平台中——只需找到并启用它们即可。
最简单的开始方法是在最有问题的节点上使用住宅通道，而在其他节点上使用数据中心代理：ProxyCove 的收费是按流量计算的，因此可以选择最小的测试流量，观察您的具体工作流的表现。选择适合任务的代理 并将字符串放入 Proxy 字段——这只需几分钟。