Configure QuotaGuard in an n8n Cloud HTTP Request node, and the destination sees one of the two static IP addresses assigned to your subscription. That direct setup works for HTTP and HTTPS only. SFTP, SSH, and native database nodes require an HTTPS relay or a self-hosted tunnel.
n8n Cloud runs on dynamic cloud infrastructure. Its outbound traffic can come from any entry in n8n's published Cloud IP list, and n8n warns that the list can change without notice. That is workable when a destination accepts the full shared list. It becomes a blocker when a client, vendor, database, or trading partner will allowlist only one or two stable addresses.
First Decide What Kind of Connection You Have
- HTTP or HTTPS from an HTTP Request node: configure the node's Proxy option with your QuotaGuard connection URL.
- Another n8n Cloud app node: it works directly only if that node exposes a proxy option. The HTTP Request node's setting does not automatically apply to other nodes.
- SFTP, SSH, or a native database connection: these are not HTTP. On n8n Cloud, use an HTTPS relay that performs the TCP connection, or move the workflow to self-hosted n8n where you can run SOCKS5/QGTunnel.
This distinction matters. Configuring QuotaGuard in one HTTP Request node does not route the SFTP node, PostgreSQL node, or every other node in the workflow through the proxy.
Why n8n Cloud IP Allowlisting Breaks
n8n's current official list contains both individual /32 addresses and /28 CIDR blocks. More important than the count or notation, it is shared platform infrastructure rather than a dedicated identity assigned to your workflow. Allowlisting the entire list authorizes traffic by its n8n Cloud source address, not by your individual tenant.
Some destinations will accept that published list. Others will not accept a broad or changing set because it grants access to more infrastructure than the individual integration requires. Typical examples include client APIs, financial systems, healthcare systems, internal services, MongoDB Atlas, corporate databases, and partner SFTP servers.
If your destination accepts the current n8n list and your team can monitor it for changes, you may not need QuotaGuard. Use a managed static-egress path when the destination requires a small stable set or when you do not want to own the proxy, NAT, availability, monitoring, and incident response yourself.
HTTP and HTTPS: Configure the HTTP Request Node Directly
- Create a QuotaGuard subscription and copy the proxy connection URL and the two assigned static IP addresses from the dashboard.
- Open the HTTP Request node that calls the protected destination.
- Select Add Option, then Proxy.
- Paste the complete QuotaGuard proxy URL:
http://username:password@<your-quotaguard-proxy-host>:9293 - Ask the destination administrator to allowlist both static IP addresses shown in your QuotaGuard dashboard.
- Save and test the node.
The node-level Proxy option takes precedence over global proxy environment variables. It also gives you selective routing: only the HTTP Request nodes where you add the option use QuotaGuard, while unrelated workflow traffic keeps its normal route.
Verify the HTTP Route
Create a temporary HTTP Request node for https://ip.quotaguard.com and configure the same Proxy option. The returned address should match one of the two IPs assigned to your subscription.
One successful request proves that request used an assigned address. Do not wait for repeated checks to display both IPs; load balancing and connection reuse do not guarantee that both will appear during a short test.
Self-Hosted n8n: HTTP Proxy Environment Variables
On self-hosted n8n, you can also set proxy environment variables on the n8n process:
HTTP_PROXY=http://username:password@<your-quotaguard-proxy-host>:9293
HTTPS_PROXY=http://username:password@<your-quotaguard-proxy-host>:9293
ALL_PROXY=http://username:password@<your-quotaguard-proxy-host>:9293
NO_PROXY=localhost,127.0.0.1
Use the bypass list for local and internal destinations that must not use the proxy. Test every node you depend on: environment variables affect only software that honors them, and they still do not turn an HTTP proxy into an SFTP or arbitrary TCP proxy.
SFTP from n8n Cloud: Use a Relay or Self-Host
The n8n SFTP node opens an SSH connection, not an HTTP request. Its configuration does not inherit the Proxy option from an HTTP Request node, and n8n Cloud does not give you a process where you can run QGTunnel alongside the managed SFTP node.
If an SFTP vendor requires a stable source IP, choose one of these architectures:
Option A: Keep n8n Cloud and Use an HTTPS-to-SFTP Relay
The path is:
n8n Cloud -> authenticated HTTPS relay -> QuotaGuard SOCKS5 or QGTunnel -> vendor SFTP server
n8n sends the file and transfer instructions to a small service you control. That service performs the SFTP operation through QuotaGuard, so the vendor sees your assigned static IPs. Keep the QuotaGuard and SFTP credentials in the relay rather than in the n8n workflow, authenticate every relay request, restrict the destinations it can reach, and validate filenames and paths.
Why use QuotaGuard if you already operate the relay? A relay on Lambda, Cloud Run, Render, or another serverless or container platform usually has dynamic egress of its own. QuotaGuard gives that relay a stable outbound identity without requiring you to build and operate NAT infrastructure. If your relay already runs on a fixed VM with a suitable static address, you probably do not need QuotaGuard for that connection.
This preserves n8n Cloud, but you now own the relay application's deployment and security. QuotaGuard manages the static proxy infrastructure and its availability; it does not operate your relay code.
Option B: Run n8n on Infrastructure You Control
With self-hosted n8n, you can run QGTunnel with the process or use a compatible SFTP client that supports authenticated SOCKS5. The connection then follows:
self-hosted n8n -> QuotaGuard SOCKS5/QGTunnel -> vendor SFTP server
Self-hosting gives you control over the runtime, but it also gives you responsibility for the n8n host, updates, backups, scaling, monitoring, and recovery. Compare that operational work with the relay approach rather than comparing monthly prices alone.
Native Database Nodes Have the Same Protocol Boundary
PostgreSQL, MySQL, MongoDB, and similar native drivers use raw TCP protocols. The HTTP Request node's Proxy option does not affect them. On n8n Cloud, use an HTTP data API or a tightly scoped relay when the database offers one. For a direct native connection through QuotaGuard, use self-hosted n8n with SOCKS5 or QGTunnel.
Troubleshooting
The destination still sees an n8n address. Confirm that the Proxy option is configured on the exact HTTP Request node making the call. A proxy configured on one node is not global.
The IP test returns only one of the assigned addresses. That is normal. Confirm that the returned address belongs to your subscription and that the destination has allowlisted both assigned addresses.
The SFTP node ignores the proxy. This is expected: the field is an HTTP proxy setting, not an SFTP setting. Use the relay or self-hosted architecture above.
An app-specific node still uses the normal n8n route. Many app nodes do not expose a proxy field. Where practical, call the service's API with an HTTP Request node. Otherwise use a relay that you control.
The destination accepts n8n's full published list. You may not need QuotaGuard. Remember that n8n says the list can change without warning, so agree on an update process with the destination administrator.
Plans and Regions
QuotaGuard Static starts at $19 per month. QuotaGuard Shield starts at $29 per month. Both products provide the pair of static outbound IP addresses used in this guide; check the current plans page for included usage and features.
Choose the nearest of 12 AWS regions when you sign up to reduce latency. If an existing subscription needs to move regions, contact QuotaGuard support rather than replacing the proxy hostname yourself.
QuotaGuard Static or Shield?
QuotaGuard Static is the normal starting point for API allowlisting. HTTPS payloads remain encrypted end to end through a blind CONNECT tunnel; QuotaGuard does not decrypt them. Choose Shield when your security requirements call for TLS on the client-to-proxy hop or when an approved regulated-data configuration requires it. SFTP already encrypts the SFTP payload, so the presence of SFTP alone does not automatically require Shield.
Getting Started
For HTTP traffic, configure one HTTP Request node first and verify it with https://ip.quotaguard.com. For SFTP or a native database connection, decide whether you will operate a relay or self-host n8n before buying or changing infrastructure.
View QuotaGuard plans or contact support if you want help mapping your specific n8n node and destination to the correct route.
QuotaGuard Static IP Blog
Practical notes on routing cloud and AI traffic through Static IPs.
