How to use a proxy in n8n

n8n is a workflow automation tool: you chain nodes that call APIs, read sheets, run code and, more and more, feed AI agents with data from the web. When a workflow fetches pages from sites that rate-limit by IP, or checks prices across hundreds of product URLs, the requests need to come from somewhere other than your one server IP. That’s where a proxy goes.

The setup question people ask most is “where do I even put the proxy?”, and the honest answer depends on where n8n runs. Self-hosted n8n gives you two places: a per-node option and environment variables. n8n Cloud gives you only the node option, and its servers send traffic from IPs that change and that other n8n Cloud customers share. That rules out proxies that authorize by IP.

This guide covers both setups, how the HTTP Request node’s batching really controls concurrency, what the environment variables do to your other nodes (including AI model calls), and the n8n error messages you’ll see when the proxy is wrong.

Rotating and residential gateways accept connections only from authorized IPs. n8n’s own docs say n8n Cloud can’t guarantee static source IPs and publish a list of addresses and ranges that Cloud traffic may come from. Two problems follow. The list can change, so a workflow that works today can start failing. And it’s one list for all of n8n Cloud, so authorizing those IPs would let other people’s workflows use your threads. Residential packages also allow only one authorized IP.

• n8n Cloud: use private dedicated proxies with http://USERNAME:PASSWORD@PROXY_IP:PORT in the node’s Proxy option. They’re static USA IPs, used only by you, up to 100 concurrent threads.
• Self-hosted on a VPS: any Storm product works. Authorize the VPS IP and use rotating or residential gateways without credentials.
• Self-hosted at home: works with IP authorization if you authorize a dynamic DNS hostname, or use dedicated proxies with user:pass.

If your scraping workflows must stay on n8n Cloud but you want rotating IPs, a small fixed-IP VPS running self-hosted n8n just for those workflows is the cleanest route. More background in the IP authentication guide.

n8n reads HTTP_PROXY, HTTPS_PROXY, ALL_PROXY and NO_PROXY on self-hosted instances and applies them to HTTP traffic from all nodes. Lowercase versions win if both cases are set. The Proxy option on an HTTP Request node overrides the variables for that node.

That “all nodes” part is the catch. With the variables set, your Slack, Google Sheets, OpenAI and webhook-calling nodes also go through the gateway. They use threads from your plan, an API may flag sign-ins from changing IPs, and an AI agent that makes several model calls per step can quietly eat a third of a small plan.

• Prefer the node option when only a few HTTP Request nodes scrape. Everything else keeps your server’s own IP.
• Use the variables when most of the instance’s traffic should be proxied, and list everything else in NO_PROXY: localhost, your database and Redis hostnames, and the AI and SaaS APIs you call.

After changing variables, restart the container; running processes don’t pick them up.

When an HTTP Request node gets many items, it builds one request per item. Without batching, n8n starts them all without waiting for answers. 500 rows from a Google Sheet means up to 500 requests at the same moment. On a 40-thread plan most of them queue, time out or get reset.

The Batching option changes the start rate, not a hard cap. Items per Batch requests start, n8n waits Batch Interval (ms), then starts the next batch, whether or not the earlier ones have answered. So the number in flight is roughly items per batch × seconds per response ÷ interval in seconds.

• Fast pages (~1 s): 30 per batch, 1,000 ms interval ≈ 30 in flight on a 40-thread plan.
• Slow pages (~4 s): 10 per batch, 1,000 ms ≈ 40 in flight, which is the whole plan. Drop to 8.
• Google results: a quarter of your threads at most. On 40 threads, 3 per batch with a 1,000 ms interval keeps you near 10 if responses take about 3 seconds.

Several workflows running at once share the same plan, so add them up. The threads guide explains how connections are counted.

• Price checks, listings, public pages: rotating, Main gateway: a new IP per request. 40 threads ($39/mo) suits most n8n instances; 80 threads ($59) if several scraping workflows overlap. See rotating proxy plans.
• Multi-step flows (log in with one request, fetch with the next): the 3-minute (USA) or 15-minute gateway so both requests leave from the same IP.
• Sites that block datacenter IPs: residential ports. Each port is one IP that changes every 5 minutes at fixed times; give each scraping workflow its own port.
• n8n Cloud or anything that must log in to the same account every day: dedicated proxies.

Bandwidth is unlimited on every plan, so pulling full HTML into an AI node for summarizing doesn’t cost extra. For heavier AI crawling with a headless browser, see the AI browser agent guide and the LLM scraping guide.