When an n8n workflow calls an API that whitelists IPs, Cloud's rotating egress breaks it. Route your HTTP Request nodes through two fixed static EU IPs and the whitelist keeps working.
// env: HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
// an HTTP Request node calling a whitelisted API
return await this.helpers.httpRequest({
method: 'POST',
url: 'https://api.partner.com/orders',
headers: { Authorization: 'Bearer ..' }
})
n8n is bidirectional, but the part that breaks is the outbound leg: workflows calling APIs that only trust specific source addresses.
Payment, banking, CRM, and B2B partner APIs often restrict access to known IPs. An n8n HTTP Request node calling them from an unknown address just returns 403, and the workflow fails mid-run.
Cloud instances scale across shared infrastructure, so the outbound IP shifts over time. A workflow that passed a whitelist on Monday can be blocked by Friday with no change to the nodes.
Self-hosted n8n often runs in a private network or behind a NAT that partners can't whitelist. Teams end up punching holes or running custom proxies just to give partners a predictable address.
A typical setup runs dozens of workflows across dev and prod. Without a fixed egress, there is no one address to hand a partner or to point at in an audit of where automation traffic originates.
"Give us the IP address your automation will call from."
You want one fixed answer that holds across every workflow run, not "whichever Cloud worker served the execution."
n8n workflow
HTTPS Proxy
(Static EU IP)
Whitelisted API
Every HTTP Request node in every workflow leaves from the same pair of EU addresses. Two IPs back the account, and if one is down the other takes over.
X-N8N-API-Key) also go out through the same fixed pair.
Building n8n workflows that call partner APIs behind IP whitelists and need those calls to keep passing.
Running self-hosted n8n behind NAT who need a predictable external address without maintaining their own proxy.
Connecting CRMs, ERPs, and B2B systems through n8n where the partner demands a fixed source IP.
Accountable for where automation data goes, who want a documented EU egress rather than an ever-changing address.
Set HTTPS_PROXY and your workflow's outbound requests leave through your fixed EU IP. No node redesign.
n8n honours the standard proxy environment variables, so an HTTP Request node calling a whitelisted partner API already leaves through your static IP once HTTPS_PROXY is set on the host.
# env on the n8n host (Cloud env vars or self-hosted docker)
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
// inside an n8n HTTP Request node (Code node form)
return await this.helpers.httpRequest({
method: 'POST',
url: 'https://api.partner.com/orders',
headers: { Authorization: `Bearer ${$env.PARTNER_TOKEN}` },
body: items[0].json,
});
Managing workflows programmatically? Calls to the n8n REST API (authenticated with X-N8N-API-Key) also route through your static IP.
# .env
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
N8N_API_KEY=n8n_api_xxx
import requests
# requests reads HTTPS_PROXY from the environment automatically
r = requests.get(
"https://your-instance.app.n8n.cloud/api/v1/workflows",
headers={"X-N8N-API-Key": os.environ["N8N_API_KEY"]},
)Set the variable where your n8n runs. Never paste the proxy string in plaintext.
# self-hosted n8n in docker-compose: load a .env file
services:
n8n:
image: n8nio/n8n
env_file:
- .env
# Kubernetes: pull it from a Secret
env:
- name: HTTPS_PROXY
valueFrom:
secretKeyRef:
name: outboundgateway-proxy
key: proxy-url
# n8n Cloud: set as a custom environment variable
HTTPS_PROXY=${OUTBOUNDGATEWAY_PROXY_URL}Two IPs, so a workflow run doesn't depend on one box
Your account comes with two static IP addresses (for example 51.xx.xx.10 and 51.xx.xx.11). Register both wherever you whitelist a source IP. If one proxy node is briefly unavailable, traffic shifts to the other, so a scheduled n8n execution isn't the thing that fails because of a proxy blip.
📖 Want the longer version? Worked examples, error handling, and other languages are in the Python SSL Proxy Guide, Node.js Guide, and the rest of the docs.
Workflows move real business data. Controlling where that traffic leaves from is part of keeping it compliant.
The proxy runs in EU data centres, so your workflow's outbound calls leave from European infrastructure rather than wherever a Cloud worker happens to be scheduled.
Because TLS passes straight through, the proxy never decodes your tokens or the records your workflows move. It forwards encrypted bytes; it doesn't read them.
Traffic doesn't bounce through US infrastructure on its way to a partner API, which removes a common wrinkle from GDPR data-transfer reviews.
When a partner or auditor asks where your automation calls from, the answer is two fixed EU addresses, not a list that changes with Cloud scaling. The failover pair covers maintenance windows.
Two addresses to register, with automatic failover, so your workflow traffic isn't riding on a single point of failure.
Set one env var and your existing HTTP Request nodes start routing through the proxy. The workflow logic is untouched.
The same fixed pair follows n8n from a Cloud instance to a self-hosted deployment, so partners see one address.
Calls you make to manage workflows and executions (with your X-N8N-API-Key) go out through the same stable pair.
TLS passthrough means the proxy can't read your traffic. Tokens, API keys, and records stay private the whole way.
Starting from €29/month. Flexible plans for every scale. Cancel anytime.
Stop letting Cloud scaling and NAT decide which IP your workflows call from. Put n8n's outbound traffic behind one stable, GDPR-conscious address.
€29/month starter plan • 7-day refund policy • Direct founder support
It covers the outbound side. Webhook nodes in n8n are inbound triggers that other services call into your n8n instance, so a forward proxy doesn't affect them (they need your instance to be reachable, optionally behind n8n's own Basic/Header/JWT auth). The proxy is for the HTTP Request nodes and REST API calls that your workflows send out to other APIs.
Yes. Self-hosted n8n honours the same HTTPS_PROXY environment variable, whether you run it in Docker, Kubernetes, or directly on a VM. That's useful for self-hosted setups behind a NAT or VPN where partners can't whitelist your private address: you give them the fixed EU proxy pair instead.
That's the main reason teams add the proxy. n8n Cloud's outbound address shifts as instances scale across shared infrastructure, which would normally break an IP whitelist over time. By routing outbound calls through a fixed pair of EU addresses and registering both, the whitelist keeps passing no matter which worker serves a given execution.
Happy to talk through how a two-IP egress fits your specific n8n setup, whether it's Cloud, self-hosted, or a mix.
Contact Our Founders →