To route an n8n HTTP Request node through a proxy, add Options → Proxy, enter a supported HTTP or HTTPS proxy URL, and verify the route from that node. Configure destination API credentials separately under Authentication. A successful response alone does not establish which route carried it.
Source reviewed and local workflow engine tested: October 13, 2026. We executed the official n8n workflow engine with Manual Trigger and HTTP Request node 4.5 on Node.js v24.19.0. The package versions correspond to n8n 2.42.7: n8n-core 2.42.5, n8n-nodes-base 2.42.5 and n8n-workflow 2.42.4. Seventeen checks passed against an owned loopback proxy and HTTP/HTTPS destinations. This was a minimal isolated engine host using synthetic credentials and package code loaded from integrity-verified official archives. The full n8n server, editor import, database credential storage, scheduled runs and queue workers were not tested. These local results do not establish a public exit, provider authentication, country, speed, anonymity or uptime.
Measured results from the local workflow engine
Each case ran the same two-node workflow through the native WorkflowExecute engine and the real HTTP Request node. The harness supplied fixture-only destination credentials and lifecycle hooks; it did not replace the HTTP Request implementation or its backend transport. The proxy accepted only our loopback destination ports. Harmless request IDs and the proxy upstream socket port matched the destination observation, including HTTPS CONNECT tunnels.
| Check | Measured result |
|---|---|
| Direct request with proxy variables cleared | Destination received the request ID; proxy recorded no request. |
| Explicit HTTP proxy and HTTPS CONNECT | Both reached the owned destination. Proxy and destination records correlated through request ID and upstream socket port; TLS verification stayed enabled. |
| Encoded proxy credentials and separate API Basic Auth | The proxy accepted synthetic encoded credentials. The destination received its own API credentials and no Proxy-Authorization header. |
| Missing or wrong proxy credentials | 407 from the proxy; no request reached the destination. |
| Destination credentials omitted | The authenticated proxy forwarded the request; the destination returned 401. |
| HTTP_PROXY, HTTPS_PROXY and ALL_PROXY | Environment routing worked when the explicit node option was absent; HTTPS used CONNECT through the HTTP proxy. |
| NO_PROXY with an environment proxy | The loopback host bypassed the proxy. Adding a supported explicit node proxy routed through the proxy despite that bypass. |
| Unreachable explicit proxy | Connection failure; no silent direct destination request. |
| Untrusted destination certificate | CONNECT succeeded, then strict TLS rejected the certificate before an HTTP request reached the destination. |
| 250 ms timeout and a deliberately delayed response | The node stopped after 270 ms with ECONNABORTED. This checks a local initial-response wait, not provider speed or a complete workflow deadline. |
| Redirects disabled | The initial 302 was surfaced without following its target. |
| Original $env workflow expressions under default policy | Environment access was denied before networking. The other checks used concrete fixture fields; the instance policy was not weakened. |
These are local engine observations, not editor screenshots or an end-to-end certification of an n8n deployment. Confirm the behavior in your own supported server, credential store and execution process before scheduling a workflow.
Set up one HTTP Request node
- Record your running n8n version and the HTTP Request node version. Keep a test workflow inactive and start with one manually triggered request to an HTTPS endpoint you own or trust. Choose an endpoint that returns the observed client IP or gives you access to its server log.
- Add a Manual Trigger and connect it to an HTTP Request node. Set Method to GET and URL to your check endpoint. For an unauthenticated check endpoint, leave Authentication at None.
- Under Options, add Proxy and enter the provider’s endpoint, for example
http://proxy.example:8080. This example host is a placeholder. Match the supplied protocol and port; do not replace the proxy scheme merely because the destination uses HTTPS. - Add Timeout and set a diagnostic value such as
10000milliseconds. Keep Ignore SSL Issues (Insecure) off. Add Redirects and turn Follow Redirects off for the initial route check. Keep pagination and retry loops off until a single request is understood. - Execute the request manually and record the observation described below. Confirm the same execution process and settings are used when the workflow later runs on a schedule or worker.
The official HTTP Request reference describes these controls. An HTTPS destination can use an HTTP forward proxy via CONNECT. The proxy URL identifies the connection to the proxy; it is separate from the destination URL.
The inspected implementation accepts explicit http:// and https:// proxy URLs. SOCKS URLs are not supported by this node path. An unsupported value falls back to environment proxy settings, which can result in a direct connection when no environment proxy applies. Do not paste a SOCKS endpoint and assume it routes traffic. Check the versioned agent implementation and unsupported-value handling when comparing another release.
Separate proxy authentication from API authentication
The node’s Authentication section authenticates with the destination API. Use the relevant service credential or a suitable generic credential there when the API requires it. Putting your proxy username and password into an API Basic Auth credential does not configure proxy authentication and can send those credentials to the wrong service.
For a username/password proxy that supports URL user information, the endpoint form is http://ENCODED_USER:ENCODED_PASSWORD@proxy.example:8080. Percent-encode the username and password independently before composing the URL, especially characters such as @, :, /, # and %. Encode the components once, rather than encoding the entire URL or repeatedly encoding an already encoded password. Encoding preserves URL syntax; it does not encrypt the secret. An HTTP connection to the proxy does not itself protect Basic proxy credentials in transit.
Keep real credentials out of article examples, shared workflow JSON, pinned node data, screenshots and copied errors. A literal Proxy field is part of the workflow parameters; do not assume n8n’s API-credential encryption also protects a password pasted into that field. Where an administrator already permits environment expressions, a secret injected into the execution process can be referenced without embedding its literal value in the export. This does not guarantee that execution errors or logs are redacted. Review them before sharing. Do not weaken an instance’s environment-access policy to make a tutorial work; use the approved secret path for that installation.
For IP allowlisting, authorize the source address that reaches the proxy from the n8n execution host. A container, remote host or worker may have a different outbound address from your laptop. Ask your provider which authentication form it supports. A proxy 407 is distinct from a destination 401 or 403: identify the responding server before changing credentials. See proxy authentication methods and n8n’s export guidance.
Verify the route with the same node and execution host
- Establish a direct baseline. Use an isolated diagnostic execution process with no proxy environment variables and remove the node’s explicit Proxy option. Confirm the destination’s observed address or server log. An empty Proxy field is not a direct-route switch: it still permits inherited environment routing.
- Make the explicit-proxy request. Add the chosen supported proxy URL to the same HTTP Request node. Send the same GET to the same endpoint, keeping redirects and pagination disabled. Record the destination’s observed address, UTC time, status and node version without recording the credential-bearing proxy URL.
- Correlate the evidence. If available, match a harmless unique request ID in the destination and proxy logs. A changed observed address is useful evidence, but several clients can share a NAT address. Proxy receipt plus destination correlation is stronger than assuming a country from an address label.
- Check the failure boundary. In a disposable test, a deliberately unreachable supported proxy endpoint should fail rather than produce the expected destination observation. Do not change production credentials or rotate a shared account to perform this check.
- Repeat in the scheduled execution context. If workers run the workflow, verify each applicable worker configuration. A successful manual request from one process does not prove the route used by another process.
The local engine results above exercise these boundaries against an owned fixture. Repeat these verification steps for your own installation and execution host. A browser IP check or a cURL request can diagnose reachability, but it does not prove this n8n node used the proxy. Compare the cURL diagnostic guide and the proxy verification checklist. Use Proxy Testing and Troubleshooting to separate TCP, proxy authentication, TLS and destination failures.
Understand environment scope and NO_PROXY
For self-hosted n8n, the documented process-level variables are HTTP_PROXY for HTTP destinations, HTTPS_PROXY for HTTPS destinations, and ALL_PROXY as a fallback when the more specific variable is absent. They configure outbound HTTP traffic in the n8n processes that receive them; they do not configure the browser viewing the editor or an inbound reverse proxy. Apply changes to the relevant n8n execution process or container and restart or recreate that process under your deployment procedure. Queue-mode workers need their own matching environment. n8n Cloud users should use the node option and the controls available to their workspace rather than assume access to host environment variables.
HTTP_PROXY=http://proxy.example:8080
HTTPS_PROXY=http://proxy.example:8080
NO_PROXY=localhost,127.0.0.1,internal.example:443This is an illustrative configuration, not a command to change global settings. Inject real values through the deployment’s approved configuration and secret mechanism. n8n documents lowercase proxy variables taking precedence over uppercase variants when both exist; Windows environment names are case-insensitive, so a Windows case comparison differs from a Linux container. Inspect conflicting values without dumping secret-containing environments.
The reviewed backend-network dependency locks proxy-from-env to 1.1.0. That resolver also considers npm_config_http_proxy or npm_config_https_proxy before their ordinary scheme variables, and npm_config_proxy before ALL_PROXY. It considers npm_config_no_proxy before NO_PROXY. Check these inherited npm settings when diagnosing a process launched through npm, and include them when isolating the direct baseline. See the versioned resolver source.
NO_PROXY belongs to environment-based selection. With a supported explicit node proxy, the inspected 2.42.7 path chooses that explicit agent instead; do not expect NO_PROXY to bypass it. To test an environment bypass, remove the explicit Proxy option, request the intended bypass host, and confirm a direct observation. Also test a non-bypassed destination through that same process.
Use host entries, with an optional port, rather than a full URL or path. An exact hostname is a narrow starting point. A leading-dot suffix such as .example.com covers matching subdomains; include example.com separately if the base host should also bypass. The documented proxy-from-env behavior supports * to bypass all environment proxying, but this also defeats an environment-based route test. Do not assume CIDR ranges or local hosts receive an automatic exemption. Review n8n’s deployment variables, the proxy-from-env bypass rules and the client-specific environment guide.
Adapt the workflow reference to your approved configuration
The developer examples download includes a separately labeled n8n workflow reference. Its two nodes are a Manual Trigger and HTTP Request version 4.5. It contains no literal credentials, credential references or pinned output, and starts inactive. The source-confirmed request options disable redirects, preserve certificate verification and set a 10000 ms timeout.
URL expression:
{{ $env.MEXELA_CHECK_URL || 'https://check.invalid/' }}
Proxy expression:
{{ $env.MEXELA_PROXY_URL || 'http://proxy.invalid:1' }}The reserved .invalid fallbacks prevent an omitted value from silently choosing a working public check destination or an empty node proxy. Before using the reference, supply an owned HTTPS check endpoint and a valid supported proxy URL in the execution environment. Confirm that the installation permits $env expressions; blocked access is a configuration boundary, not proof of a bad proxy. Never place these secrets in an upstream Set/Edit Fields node that would save them as ordinary execution data. If environment expressions are not part of your approved setup, configure the fields through the supported local workflow process and sanitize any later export.
The JSON structure was checked against versioned source. On October 13, the native engine executed the same two-node layout with concrete owned-local fields and confirmed the routes listed above. Attempting the original $env expressions under the default environment-access policy produced access to env vars denied before networking. This is a reproducible configuration boundary, not a bad proxy. Use fields or credentials approved for your installation rather than weakening that policy. Editor import, permitted environment-expression execution, database-backed credentials and scheduling remain untested. See environment-access controls and the node-version registry.
Troubleshoot the failing layer
| Observation | Next check |
|---|---|
| Unexpected direct route | Confirm this node has a supported explicit proxy, inspect environment fallback and bypasses, and verify the process that ran it. An empty or unsupported value can permit environment selection. |
| 407 from the proxy | Check the proxy authentication method, independently encoded URL components, account state or the worker’s allowlisted source address. |
| 401 or 403 from the destination | Check destination credentials, permissions and response body. A proxy cannot grant access to an API or remove a destination restriction. |
| Connection refused or name resolution error | Check the proxy host, port and protocol from the execution host. Inside a container, localhost identifies that container, not your laptop or a different service. |
| TLS certificate failure | Check the destination hostname and certificate chain, then any approved private CA for the proxy transport. Keep SSL verification enabled and follow the deployment’s trust policy. |
| Timeout | Separate reaching the proxy, establishing CONNECT and waiting for the destination. The node’s documented timeout bounds the initial response wait; do not present it as a complete workflow deadline. |
| Works manually but fails on a schedule | Check which worker ran it, its environment and source address, and whether the workflow uses the same node settings. |
| Private endpoint or proxy blocked by instance policy | Review the administrator’s egress restrictions and permitted destination list. Do not disable protections to make the example pass. |
Start with one bounded request. Add pagination, concurrency or retries only after authentication and route evidence are stable. For an authorized rate-limited API, respect its documented limits and backoff instructions; changing addresses does not resolve API authorization or create extra permission.
Frequently asked questions
Does setting HTTPS_PROXY mean the proxy endpoint must use HTTPS?
No. The variable selects HTTPS destination requests. Its value still describes the proxy transport and can be an HTTP proxy that supports CONNECT.
Can I put proxy credentials in the HTTP Request Authentication menu?
That menu authenticates with the destination. Configure the proxy’s supported username/password URL or source-IP allowlist separately, and keep exported values and errors free of secrets.
Will NO_PROXY override a proxy entered on the node?
Not in the inspected explicit-proxy path. It applies when the request uses environment proxy selection. Verify both an intended bypass and a proxied destination after removing the explicit node option.
Can this node use a SOCKS5 proxy?
The reviewed node path supports HTTP and HTTPS forward proxies. Unsupported explicit schemes fall back to environment settings; they are not proof of SOCKS routing. For a separate Python service, compare HTTPX’s optional SOCKS support and aiohttp’s session and proxy boundaries.
Is an n8n reverse proxy the same setup?
No. A reverse proxy fronts the editor or webhooks. This guide configures outbound requests from workflow nodes. Document those two network paths separately.
Verify one route before expanding the workflow
Use Proxy Setup and Developer Guides to choose the client responsible for each request. If n8n delegates a request to a Python service, configure and verify that service with HTTPX or aiohttp; the n8n node’s proxy does not automatically configure another application’s traffic. Once the direct baseline and proxied observation are repeatable, compare Mexela proxy locations against the actual destination and location requirements.
Versioned n8n source files
Use the n8n folder in the public source repository for the example, setup instructions, exact dependency versions and a sanitized test summary. The repository is a dated snapshot of owned examples; its loopback checks do not certify a commercial endpoint or every application configuration.