n8n proxy setup: the HTTP Request node's Proxy option and HTTP_PROXY for the whole instance

For an n8n proxy on an HTTP Request node, open the node, click Add Option under Options, choose Proxy, and enter http://USERNAME:PASSWORD@HOST:PORT with the values from your ProxyHive order. The node option wins over any environment variables. On a self-hosted instance you can instead set HTTPS_PROXY on the n8n process, which sends every node's HTTP traffic through the proxy.

We ran both methods on 2026-09-30 with the official n8nio/n8n Docker image, n8n 2.41.4, against a local proxy that enforces a username and password. Labels checked against the HTTP Request node docs and n8n's deployment environment variables the same day.

#Which n8n proxy method to use

Use the node option when only some requests need a particular IP, such as a price check from a German ISP IP while the rest of the workflow talks to your CRM directly. Use the environment variables when the whole instance must leave through one address, for example because a partner API allowlists it.

#Before you start

1. Buy an IP and open the order in the dashboard at https://app.proxyhive.io. A static ISP proxy is a good default: one address, fixed for the term, chosen by country, region, city and carrier.
2. Copy HOST, the HTTP port, USERNAME and PASSWORD. Each IP is its own endpoint.
3. Pick an authentication method. For a self-hosted n8n on a server with a fixed public IP, an IP allowlist on the order keeps the password out of your workflows. On n8n Cloud, use username and password.

#Set a proxy on the HTTP Request node

#1. Add the node

Add an HTTP Request node, set Method to GET and URL to https://api.ipify.org?format=json.

#2. Add the Proxy option

Under Options, click Add Option and choose Proxy.

#3. Enter the proxy URL

http://USERNAME:PASSWORD@HOST:PORT

Use http:// and the HTTP port even for https:// targets: the request stays encrypted inside the tunnel. If the password contains @, : or /, URL-encode it. With an IP allowlist on the order, drop the credentials: http://HOST:PORT.

#4. Run it

Run the node with Execute step (Test step in older versions). The output should be {"ip": "..."} with the address on your order. In our run the node returned the local proxy's exit IP, and the proxy's log showed an authenticated CONNECT api.ipify.org:443.

Here is the node as it appears in exported workflow JSON:

{
  "parameters": {
    "url": "https://api.ipify.org?format=json",
    "options": { "proxy": "http://USERNAME:PASSWORD@HOST:PORT" }
  },
  "name": "Exit IP",
  "type": "n8n-nodes-base.httpRequest",
  "typeVersion": 4.2
}

That export is the catch: the password sits in the workflow in plain text, visible to anyone who can open or export it. Where you can, allowlist the server's IP instead, and keep credentials only in instances you control. Password or IP allowlist covers the trade-off.

We also tried {{ $env.PROXY_URL }} in the Proxy field to read the URL from the environment. On 2.41.4 the execution failed with access to env vars denied, so plan on the literal URL or the instance-wide variables below.

#Set a proxy for a self-hosted n8n instance

n8n reads the standard proxy variables:

• HTTP_PROXY for plain http:// requests.
• HTTPS_PROXY for https:// requests.
• ALL_PROXY for both, used when the more specific one is missing.
• NO_PROXY, a comma-separated list of hosts that go direct.

n8n's docs note that lowercase versions such as https_proxy take precedence over the uppercase ones when both are set. With Docker:

docker run --rm -p 5678:5678 \
  -e HTTPS_PROXY="http://${PROXY_USER}:${PROXY_PASS}@${PROXY_HOST}:${PROXY_PORT}" \
  -e HTTP_PROXY="http://${PROXY_USER}:${PROXY_PASS}@${PROXY_HOST}:${PROXY_PORT}" \
  -e NO_PROXY="localhost,127.0.0.1,postgres" \
  n8nio/n8n

With the variable set and no Proxy option on the node, the same workflow went out through the proxy. So did n8n itself: our proxy log showed calls to telemetry.n8n.io alongside the workflow's request. Add your database, internal services and any API that should see your real IP to NO_PROXY, or set N8N_DIAGNOSTICS_ENABLED=false if you do not want telemetry at all. The Docker proxy guide covers the other places a proxy can be set for containers.

#n8n Cloud

On n8n Cloud you do not control the process environment, so the environment variables are not available. Use the Proxy option on each HTTP Request node with credentials in the URL. An IP allowlist does not fit here: the requests leave from n8n's servers, not from an IP you own.

#Troubleshooting

• 407 or an authentication error. Wrong username or password in the URL, or a password with special characters that is not URL-encoded.
• The execution hangs at the HTTP Request node. In our test, a wrong password in the Proxy field left the CLI execution running with no result until we stopped it after five minutes. Check the credentials first.
• The IP check shows the server's own address. The Proxy option is on a different node, or the target host is listed in NO_PROXY.
• ECONNREFUSED. Wrong host or port, or a SOCKS5 port entered as http://.
• Other nodes stopped working after setting HTTPS_PROXY. They are now going through the proxy too. Add their hosts to NO_PROXY.

For scraping jobs, keep n8n's request rate modest and check the target against our allowed-use policy. To test the same endpoint by hand first, Postman takes the same proxy URL.