Integration · AI & workflow tools
How to use a proxy with n8n
n8n sends a request through a proxy when you add the Proxy option to an HTTP Request node and enter the full proxy URL, credentials included: http://USERNAME:PASSWORD@host:port. For a whole self-hosted instance, the HTTPS_PROXY and HTTP_PROXY environment variables do the same for every node, and the node option overrides them. Because ARC targeting lives in the username, the proxy field can also take an expression that changes the country or the session per execution.
Reviewed 30 Oct 2026
http://USERNAME _pool-arcfast _country-de:PASSWORD@ proxy.arcproxies.io:8000The short answer
- Per node: Options → Add option → Proxy, value
http://USERNAME:PASSWORD@host:port. It takes precedence over the instance's proxy variables. - Per instance: set
HTTPS_PROXY(andHTTP_PROXY) on the n8n container, and list hosts that must not use the proxy inNO_PROXY. - The Proxy field accepts expressions, so
{{ $execution.id }}in the username gives each workflow run its own sticky session. - A wrong password fails the node with HTTP code 407, not with an empty result. Check the exit IP once before you build the rest of the workflow.
Setup
Set up n8n with a proxy, step by step
- 01
Add the Proxy option to an HTTP Request node
Open the HTTP Request node, scroll to Options, choose Add option → Proxy and paste the gateway URL with your credentials in it. Use the
http://scheme: n8n documents this option as an HTTP proxy, and HTTPS targets still work through it because the client opens an HTTP CONNECT tunnel. If the password contains@,:or/, percent-encode those characters.HTTP Request → Options → Proxy1 linehttp://USERNAME_pool-arcfast_country-de:PASSWORD@proxy.arcproxies.io:8000 - 02
Check the exit IP with a test workflow
Point the node at an IP echo service and run it once. The output item shows the address the target sees, which should be a German residential IP for this username. You can paste this node straight onto the canvas; it is the exact node we ran.
paste onto the n8n canvas17 lines{ "nodes": [ { "parameters": { "url": "https://api.ipify.org?format=json", "options": { "proxy": "http://USERNAME_pool-arcfast_country-de:PASSWORD@proxy.arcproxies.io:8000" } }, "name": "Check exit IP", "type": "n8n-nodes-base.httpRequest", "typeVersion": 4.2, "position": [0, 0] } ], "connections": {}} - 03
Give each execution its own sticky session
A workflow that fetches a listing page and then its detail pages should keep one IP for the run. Switch the Proxy field to Expression and build the username from the execution ID: every run gets a new
_session-handle, and every request inside that run shares it for up to ten minutes.Proxy field, Expression mode1 linehttp://USERNAME_pool-arcfast_country-de_session-{{ $execution.id }}_sesstime-10:PASSWORD@proxy.arcproxies.io:8000 - 04
Change the country per item
The same field can read from the incoming item. If an earlier node outputs a
countryfield with a lowercase ISO code, each item is fetched from that country. Keep the rest of the username, including the pool, unchanged.Proxy field, Expression mode1 linehttp://USERNAME_pool-arcfast_country-{{ $json.country }}:PASSWORD@proxy.arcproxies.io:8000 - 05
Or proxy the whole self-hosted instance
On a self-hosted instance, the standard proxy variables apply to outgoing HTTP requests from nodes. If both are set, lowercase variants such as
https_proxywin over uppercase ones. Put internal services inNO_PROXYso they are reached directly.docker run6 linesdocker run -it --rm -p 5678:5678 \ -e HTTPS_PROXY="http://USERNAME_pool-arcfast_country-de:PASSWORD@proxy.arcproxies.io:8000" \ -e HTTP_PROXY="http://USERNAME_pool-arcfast_country-de:PASSWORD@proxy.arcproxies.io:8000" \ -e NO_PROXY="localhost,127.0.0.1,postgres,redis" \ -v n8n_data:/home/node/.n8n \ docker.n8n.io/n8nio/n8n
Node option or environment variables in n8n?
Both reach the same gateway; the difference is how much traffic they catch. The node option is precise, the variables are broad.
| Behaviour | Proxy option on the node | HTTPS_PROXY on the instance |
|---|---|---|
| Scope | That one node | Outgoing HTTP requests from every node |
| n8n Cloud | Available | Not available (no access to the environment) |
| Targeting per run | Yes, the field takes expressions | No, one fixed username until restart |
| Risk | Easy to forget on a new node | Unrelated calls, such as LLM APIs, can also use the proxy and its bandwidth |
A sensible split: set the node option on the nodes that fetch public web pages, and leave API calls to services you have an account with on a direct connection.
Rate limits, batching and retries
- Batching (Options → Batching) sets Items per Batch and Batch Interval (ms). A small batch with an interval is the simplest way to keep a large item list from hitting one site all at once.
- Retry On Fail sits in the node's Settings tab. Set Wait Between Tries (ms) to a few seconds so a 429 has time to clear. Handling 429 rate limits explains why backing off beats switching IPs faster.
- Never Error (Options → Response) returns 4xx and 5xx responses as items instead of failing the node. Combine it with Include Response Headers and Status and an IF node to route blocked pages to a retry branch.
Rotating or sticky in an n8n workflow
Without a _session- token, each new connection can leave from a different exit. That suits a workflow that fetches unrelated URLs, one per item. Pagination, search-then-detail flows and anything that sets cookies should be sticky, with one handle per execution as in the step above. Rotating vs sticky sessions covers the trade-off.
For larger crawls with a queue, deduplication and browser rendering, a crawling framework is usually a better fit than a long n8n loop; Crawl4AI and Firecrawl can both sit behind an n8n HTTP Request node.
The problem
Common pitfalls
Credentials in a separate field
The Proxy option has one text field. The username and password go inside the URL, before the @; there is no separate credential type for proxy authentication on this node.
Instance variables that catch too much
With HTTPS_PROXY set, requests you did not mean to proxy can also go through the gateway and count against the balance. Add those hosts to NO_PROXY, or use the node option instead.
Reading a 407 as a site error
In our test a wrong password produced the node error "Your request is invalid or could not be processed by the service" with httpCode 407. The 407 comes from the proxy, not the target: check the username and password, not the URL.
Unencoded special characters
The value is parsed as a URL. A password with @ or : in it breaks the parse unless those characters are percent-encoded (%40, %3A).
FAQ
Questions
Something not covered? Write to contact@arcproxies.io.
Where is the proxy setting in n8n?
In the HTTP Request node, under Options. Choose Add option, then Proxy, and enter http://USERNAME:PASSWORD@host:port. Self-hosted instances can also set HTTPS_PROXY and HTTP_PROXY as environment variables; the node option takes precedence.
Does the n8n proxy option support username and password?
Yes, inside the URL: http://USERNAME:PASSWORD@host:port. We ran this on n8n 2.45 against a proxy that requires Basic authentication and the credentials were sent on the CONNECT request.
Can n8n use a different proxy IP for each workflow run?
Yes. Switch the Proxy field to an expression and put _session-{{ $execution.id }} in the ARC username. Each execution gets its own handle and therefore its own exit IP, which stays the same for the length of _sesstime-.
Does the proxy work on n8n Cloud?
The node's Proxy option does, because it is part of the workflow. Environment variables such as HTTPS_PROXY need access to the instance's environment, which only a self-hosted installation gives you.
Sources & review
Last reviewed by the ARC Proxies team. Prices are read from the live catalog at build time.
Next
What people build with it
Integrations
Other ai & workflow tools
Get started
Get credentials and paste them in.
Sign up, buy a gigabyte, generate a username in the dashboard. Code WELCOME15 takes 15% off your first purchase; bandwidth never expires.