n8n HTTP Request Proxy: Configuration Guide

Manual Trigger → HTTP Request

Method: GET
URL: your controlled diagnostic URL
Options → Proxy: your HTTP proxy URL
Options → Timeout: a finite value in milliseconds

Run manually once. Inspect status and response body.
Remove secrets before exporting or sharing the workflow.

The n8n HTTP Request node has an HTTP proxy option. That gives a workflow a place to specify network routing without building a custom node just to make an ordinary HTTP request. Begin with one node and a controlled destination so you can see what the setting changes.

Set the proxy on the request you intend to route

The HTTP Request node reference documents a Proxy option for an HTTP proxy. It also states that this node option takes precedence over the global HTTP_PROXY, HTTPS_PROXY and ALL_PROXY environment settings.

Keep the scope of the change explicit. A setting on one HTTP Request node is not evidence that another node, an external tool or a separately hosted browser uses that route. Test each network step that matters to the workflow.

Use your provider's HTTP endpoint for this documented option. For Proxies.sx connection details, consult the Pool Gateway guide. The provider's support for another protocol does not establish support for that protocol in this particular n8n field.

Keep proxy access separate from target authentication

The proxy authenticates the network connection. The destination API may require its own token or account. Store and review those credentials separately, and make sure the target token is sent only to the intended destination.

Before sharing a workflow, inspect its exported JSON and recorded execution data for secrets. Avoid embedding live credentials in a template. Use the credential or secret facilities supported by your n8n deployment and check who can view the workflow and its execution history.

Build a small, useful test workflow

1. Start with a manual trigger so a new schedule cannot generate traffic before the configuration is reviewed.
2. Add one HTTP Request node that calls a diagnostic endpoint you control.
3. Compare a direct run with a proxy-configured run. Record status, elapsed time and the address observed by the destination.
4. Replace the diagnostic URL with the authorized API or page the workflow needs. Define the expected fields before running it.
5. Set a bounded retry policy. Keep failed requests visible instead of treating an empty result as completed work.

Repeated retries can consume traffic while producing no useful records. For the first evaluation, choose a small input set and review each failure. Record the n8n version and the relevant node settings with the result so another person can reproduce the test.

Do I need a custom Proxies.sx node?

For a basic HTTP request through a proxy, evaluate the existing node first. Additional management features may justify separate development.

Does setting a node proxy route the whole workflow?

Verify the network route from each component that makes requests. This article documents the HTTP Request node's option, not a universal workflow-wide routing guarantee.

Continue to our developer resources or use the proxy test plan before scheduling repeated runs.