Using a proxy in n8n: the HTTP Request node, credentials and rotation

An n8n workflow makes its web requests from wherever n8n runs: your server, your laptop, or n8n’s cloud. Sometimes that is the wrong place. The API only accepts calls from an allowlisted address, or your host’s IP is shared with a thousand other workflows and gets treated accordingly. An n8n proxy moves where those requests leave from. This guide covers the HTTP Request node’s proxy option, a proxy for the whole instance, and which kind of IP to put behind each.

Option names below are from n8n’s documentation and the HTTP Request node’s source code, checked in September 2026.

How to use a proxy in the n8n HTTP Request node

Short answer: open the HTTP Request node, click Add option, choose Proxy, and enter the full proxy URL, username and password included:

http://USER:PASS@IP:PORT

Execute the node against https://httpbin.org/ip and the origin in the output should be the proxy’s address. That setting applies to that one node only; every other node in the workflow still leaves from your own server.

n8n HTTP Request proxy: format and credentials

The field’s own hint is e.g. http://myproxy:3128 and n8n’s docs call it simply the HTTP proxy to use, without saying how to pass a password. So we read the source. In current n8n, the node hands the whole URL to a standard proxy agent, which takes the username and password from the URL and sends them to the proxy. The format that works:

http://USER:PASS@IP:PORT

Three details the field will not tell you:

• Start with http://. The source only accepts URLs starting with http:// or https://. Anything else, a socks5:// URL included, is ignored with a warning in the server log, and the request falls back to the instance’s proxy settings, or to no proxy. It fails silently, which is the worst way to fail. There is no SOCKS support in this option.
• Percent-encode odd characters. If your password contains @, :, / or #, encode them (@ becomes %40) or the URL splits in the wrong place.
• The password lives in the workflow. n8n has no credential type for a proxy, so the URL sits in the node’s parameters in plain text. Anyone who can open or export the workflow can read it. Keep that in mind before sharing one.

If you are on an older n8n and a URL with correct credentials still gets a 407, update first; the request code has been reworked more than once, and we only checked the current version.

n8n proxy settings for the whole instance

Self-hosted n8n reads the usual proxy environment variables. From n8n’s deployment docs:

• HTTP_PROXY: proxy for unencrypted http:// requests from nodes.
• HTTPS_PROXY: proxy for https:// requests.
• ALL_PROXY: used when neither of the above is set.
• NO_PROXY: comma-separated hosts that go direct.

With Docker Compose, that looks like this:

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    environment:
      - HTTP_PROXY=http://USER:PASS@IP:PORT
      - HTTPS_PROXY=http://USER:PASS@IP:PORT
      - NO_PROXY=localhost,127.0.0.1

Two warnings from the docs and the code. First, lowercase variables such as https_proxy beat uppercase ones when both are set, so an old lowercase variable in the container can quietly override the one you just added. Second, a Proxy set on a node takes precedence over all of these, which is handy: a global proxy for most traffic, and a different one for the node that needs it.

Think before sending the whole instance through a proxy. The docs say the variables apply to HTTP traffic from nodes, so your Slack, Google and AI model calls go through it too. On a proxy billed by the gigabyte, that is traffic you pay for and did not mean to. Put those hosts in NO_PROXY, or use the per-node option instead.

n8n Cloud: the node option is your only switch

Environment variables are part of self-hosting: n8n’s docs describe them as configuration for your self-hosted instance. On n8n Cloud you do not run the server, so there is nowhere to set them. Use the Proxy option on each HTTP Request node that needs it. Nodes for specific apps have no proxy option of their own, so a call that must leave through the proxy has to be made with an HTTP Request node, which can still use the app’s saved credential through its Authentication setting.

Rotating residential or a static IP for n8n workflows?

It depends on what the workflow talks to.

• One API, all day: use a static datacenter proxy, or an ISP proxy if the API is fussy about datacenter ranges. APIs often ask you to allowlist the address you call from, and a key used from a new IP on every call can look like a stolen key. You choose the country of a static IP at checkout.
• Many public pages: use rotating residential, with http://USER:[email protected]:8000 in the Proxy field. The gateway gives a new address per new connection.

Does each item get a new IP? In the current source, the HTTP Request node builds its proxy agent per request rather than keeping a shared pool, so each item should arrive on a fresh connection and a fresh residential address. We read that in the code; we did not measure it across versions. Check it yourself: feed the node five items, point it at https://httpbin.org/ip, and compare the origins. If you need the same address across several steps, a login followed by a fetch, turn on a sticky session in the dashboard. The rotating vs sticky guide covers the trade. Residential does not let you pick a country.

Batching and pacing in the HTTP Request node

A proxy changes where requests come from, not how many a site will put up with. The node sends one request per input item, so a list of 2,000 URLs is 2,000 requests as fast as n8n can make them. Under Add option, Batching slows that down:

• Items per Batch: how many items go before a pause. It starts at 50 when you add the option.
• Batch Interval (ms): how long to wait between batches. It starts at 1000.

Items per Batch of 1 with an interval of 2000 is one request every two seconds, a sensible start for a site you do not own. Follow the target’s terms, its robots.txt and any rate limits it publishes, and read our acceptable use policy. Changing IPs to get past a limit you have been given is not something a proxy should be for.

n8n proxy errors: 407, ECONNRESET and timeouts

407 Proxy Authentication Required

The proxy rejected the credentials in the URL, or found none. Check that the URL has USER:PASS@ in it, that special characters are encoded, and that you copied the right order’s details. The 407 guide has the full list.

ECONNRESET

The connection was cut mid-request, by the target, the proxy, or a residential exit that went offline. Occasional resets on residential are normal; a steady stream means the target is refusing you. Turn on Retry On Fail in the node’s Settings tab for the occasional ones, and slow down for the steady ones. The ECONNRESET page goes deeper.

Timeouts

Without a Timeout option, the node waits up to five minutes for a response, according to its source. Add the option (it starts at 10,000 ms) so a stuck request fails fast and a retry can take over. If every request times out, the proxy itself is unreachable; test the same URL with curl, and see the connection timeout page.

Testing the API by hand before building the workflow? The Postman proxy guide sets up the same proxy there, so you can see what the API returns before n8n ever calls it.