Proxy for n8n: setting up HTTP Request without 403 (2026)

You have set up a workflow in n8n, it worked for two weeks, and then it started consistently failing with 403 Forbidden. The first thought is, "the site is broken" or "the credentials have expired." More often than not, the issue lies elsewhere: the target server has recognized that the request did not come from a browser, but from automation operating with the datacenter IP of your VPS. n8n has a built-in proxy mechanism — it’s just not enabled by default, and some settings are located where they are not expected.

Let’s break it down step by step: where exactly to set the proxy in n8n, how self-hosted differs from Cloud, and what three traps consume the most time.

Why n8n gets blocked more often than your browser

n8n is the largest open-source automation platform: nearly 198 thousand stars and 59.6 thousand forks on GitHub, with the current release at the time of publication being [email protected] (July 24, 2026). Popularity has a downside: anti-bot systems are well aware of its network fingerprint.

Three factors come into play:

User-Agent gives you away instantly. This is not a guess, but officially documented behavior. In n8n, there is a variable N8N_ENFORCE_GLOBAL_USER_AGENT (default is false), and the documentation explicitly describes its purpose: to replace the "bare" User-Agent string n8n with an RFC-compliant Mozilla/5.0 (compatible; n8n/<version>; +https://n8n.io/) to prevent request blocking by web application firewalls. The problem escalated to bug reports: in issue #28280 (opened April 10, 2026, closed), it was described how native nodes returned the bare-UA n8n, and sites responded with 403 due to "Bad User-Agent." The HTTP Request node under the hood uses axios and can easily be identified without a manual header.
Your server's IP is from a datacenter. n8n almost always runs on VPS or in the cloud. These ranges are publicly known and marked as "non-user": some platforms impose stricter limits, even significantly lower request limits than for home connections.
The request rate is inhuman. A node in a loop sends dozens of requests per second from a single address — this is a classic trigger for rate-limiting and subsequent IP bans.

Step 1. Proxy in the node itself (works on Cloud too)

The quickest way is to set a proxy specifically for one HTTP Request:

Open the HTTP Request node.
At the bottom, click Add Option and select Proxy — this is a text field for the proxy server URL.
Enter the string in the standard format with authentication: http://LOGIN:PASSWORD@host:port.
Also add the header option: enable Send Headers and set the User-Agent of a real browser — manually copy the current string from the DevTools of your Chrome.

This method is the only one available on n8n Cloud: there you do not manage the runtime environment, so system environment variables are not available to you, and the outgoing IP is not fixed and changes from run to run. The advantage of this approach is granularity: different nodes in the same workflow can use different proxies and different geos. The downside is that if there are twenty nodes, you will have to edit twenty places.

Step 2. Global proxy through environment variables (self-hosted)

On your server, it makes more sense to wrap all outgoing traffic at once. n8n reads standard variables:

HTTP_PROXY — proxy URL for unencrypted HTTP traffic from nodes;
HTTPS_PROXY — the same for TLS/SSL requests (in practice, this is your main parameter);
ALL_PROXY — used when no more specific HTTP_PROXY/HTTPS_PROXY are set;
NO_PROXY — a comma-separated list of hosts that n8n will access directly, bypassing the proxy.

In docker-compose.yml, it looks like this:

HTTPS_PROXY=http://LOGIN:[email protected]:8080
NO_PROXY=localhost,127.0.0.1,postgres,n8n.example.com
N8N_ENFORCE_GLOBAL_USER_AGENT=true

Make sure to fill in NO_PROXY. Otherwise, internal requests — to your Postgres, to neighboring containers, to your own webhook domain — will also go through the external proxy. The symptom is "everything broke after enabling the proxy," even though the target sites started opening just fine.

If you want to avoid revealing the n8n version externally, instead of the RFC string, set your own through N8N_GLOBAL_USER_AGENT_VALUE — it overrides the default value. The general logic for configuring container traffic is the same as in other scenarios: format breakdowns and pitfalls are covered in the guide on proxying Docker containers.

Step 3. Three traps that steal your evening

Trap 1: Variable case matters

This is not obvious and is rarely mentioned in tutorials. n8n processes variables ending with _PROXY through the npm package proxy-from-env, which enforces its own priority order: lowercase options (http_proxy) take precedence over uppercase ones (HTTP_PROXY) if both are set. A classic scenario of pain: a forgotten https_proxy has long been lying in the system, you carefully set HTTPS_PROXY in compose — and the traffic stubbornly goes to the old address. Check both cases.

A separate detail for Enterprise: the proxy variable for requests to the licensing server https_proxy_license_server must be only in lowercase, format — https://user:pass@proxy:port.

Trap 2: Code node can't do what you intended

A common piece of advice from forums is, "write your request in the Code node using axios with a proxy agent." By default, this will not work: n8n disables module imports in the Code node. You have to explicitly allow them — NODE_FUNCTION_ALLOW_BUILTIN for built-in and NODE_FUNCTION_ALLOW_EXTERNAL for external (from n8n/node_modules). An additional nuance: if you have task runners in external mode, these variables are not set in the container environment but in the runners' config /etc/n8n-task-runners.json as env-override. It’s simpler and safer to stick with the built-in Proxy option in the node.

Trap 3: Proxy is set, but the rate remains the same

The proxy changes the address but not the behavior. If the workflow still sends bursts of requests, you will simply burn through new IPs. In the same node, there are built-in throttles:

Batching — Items per Batch (how many items in a batch) and Batch Interval in milliseconds (0 = no pause). Set the batch to 1–5 and the interval to 1000–3000 ms.
Timeout — in milliseconds; resident channels are slower than datacenter ones, the default should be increased.
Response → Never Error — does not drop the entire workflow on the first 403, allowing you to handle the response code with branching.
Pagination — modes Update a Parameter and Response Contains Next URL instead of custom loops.

At the instance level, the rate is limited by N8N_CONCURRENCY_PRODUCTION_LIMIT (default is -1, meaning no limit) — a reasonable value will protect both the proxy pool and the server itself. More on how platforms count your requests and what to do about limits can be found in the analysis of bypassing rate limiting through proxies.

What proxies to use for n8n

The choice depends not on "coolness," but on who is on the other end.

Datacenter proxies. Cheap and fast. Suitable for official APIs, internal services, bot-friendly sites, and any tasks where a stable static address is simply needed — for example, to get your IP whitelisted by a partner. On secure platforms, they give exactly the same 403 as a bare VPS: their ranges are known. This is the base for batch tasks without anti-bot measures.
Residential proxies. Addresses from real home providers — what you need for data collection from sites with serious protection, for geo-dependent content, and price monitoring. For workflows that access public sites, residential proxies are a working default: use rotation per request for mass scraping and sticky sessions when you need to maintain one session across a chain of nodes.
Mobile proxies. The highest level of trust: behind one operator are thousands of real subscribers, banning such an IP is costly for the platform. Justified where the cuts are the harshest — working with social media and messengers. For this, you pay with speed and price.

A practical scheme for a mixed workflow: official APIs — directly or through datacenter proxies, public sites — through residential proxies, social media — through mobile proxies. The Proxy option is set up separately for each node, so combining all of this in one scenario can be done without hacks.

Checklist before launching

Proxy is set — either as the Proxy option in the node or through HTTPS_PROXY; only the first option is available on Cloud.
Both cases of variables are checked — lowercase overrides uppercase.
NO_PROXY covers localhost, the database, and internal hosts.
User-Agent is replaced: N8N_ENFORCE_GLOBAL_USER_AGENT=true or your custom header in the node. Also, check the consistency of other headers — an inconsistent set of headers reveals automation just as well as the User-Agent itself.
Batching is enabled with a non-zero interval.
A test run is done on 3–5 items, not on the entire list.

Conclusion

A 403 in n8n is almost always not just one reason but a sum of three: a recognizable User-Agent, a datacenter IP, and too consistent a request rate. This is also treated with a set of measures, not just one checkbox: substitute the UA, route traffic through the appropriate type of proxy, and throttle the node through Batching. All three levers are already built into the platform — they just need to be found and enabled.

The easiest way to start is with a residential channel on the most problematic nodes and a datacenter one on the others: payment at ProxyCove is based on traffic, so for testing, you can take a minimal volume and see how your specific workflow behaves. Select proxies for your task and input the string in the Proxy field — it takes just a couple of minutes.