n8n Proxy Configuration: HTTP Request Nodes, Workers and AI Tools

Choose node-level or deployment-level routing

The HTTP Request node documentation provides a Proxy option for HTTP proxies. It takes precedence over the instance’s HTTP_PROXY, HTTPS_PROXY and ALL_PROXY settings.

Use the node option when only that request should use an endpoint. Use a deployment setting when an administrator intentionally wants broader outbound routing. Before applying a global change, list the dependencies that must remain reachable, including internal APIs and services used by other workflows.

The deployment variable reference defines HTTP_PROXY for HTTP destinations, HTTPS_PROXY for HTTPS destinations, and ALL_PROXY as a fallback. NO_PROXY declares exclusions. Lowercase forms take precedence when both lowercase and uppercase variables exist, so inspect the deployed configuration rather than adding another competing value.

These are outbound settings. An inbound reverse proxy and webhook URL are configured separately in n8n’s webhook deployment guide. Changing WEBHOOK_URL does not select the route used by an HTTP Request node.

Build a manual request before connecting the production workflow

Create a Manual Trigger followed by an HTTP Request node. Use GET and the URL https://api.ipify.org?format=json. The ipify API returns the IP observed for that request.

In the node’s options, set your HTTP Proxy endpoint and a timeout of 15000 milliseconds. Turn off redirects for this diagnostic. Enable the full response so the result includes status and headers. Leave Ignore SSL Issues off and Never Error off.

The released node description defines those controls. Its timeout covers waiting for response headers and the start of the body; do not treat that setting as a guaranteed deadline for the entire workflow. A separate workflow timeout and execution policy may still be needed.

Execute the node and inspect statusCode and body.ip. A green workflow status alone does not prove that the destination returned the content your next step expects. Repeat from the actual execution environment before processing sensitive data or enabling a schedule.

Workflow template and validation limits

The following JSON uses HTTP Request node version 4.5 from the n8n 2.42.6 release, reviewed on October 11, 2026. Import it into a test workflow and replace http://proxy.example:8080. It contains no working proxy or credentials and remains inactive.

{
  "name": "Proxy route diagnostic",
  "nodes": [
    {
      "parameters": {},
      "id": "manual-trigger",
      "name": "Run diagnostic",
      "type": "n8n-nodes-base.manualTrigger",
      "typeVersion": 1,
      "position": [
        0,
        0
      ]
    },
    {
      "parameters": {
        "method": "GET",
        "url": "https://api.ipify.org?format=json",
        "options": {
          "proxy": "http://proxy.example:8080",
          "timeout": 15000,
          "allowUnauthorizedCerts": false,
          "redirect": {
            "redirect": {
              "followRedirects": false
            }
          },
          "response": {
            "response": {
              "fullResponse": true,
              "neverError": false,
              "responseFormat": "json"
            }
          },
          "sendCredentialsOnCrossOriginRedirect": false
        }
      },
      "id": "check-route",
      "name": "Check outbound IP",
      "type": "n8n-nodes-base.httpRequest",
      "typeVersion": 4.5,
      "position": [
        260,
        0
      ]
    }
  ],
  "connections": {
    "Run diagnostic": {
      "main": [
        [
          {
            "node": "Check outbound IP",
            "type": "main",
            "index": 0
          }
        ]
      ]
    }
  },
  "settings": {
    "executionOrder": "v1"
  },
  "active": false
}

We checked the field names and option handling against the released node implementation. This template was not executed in an n8n instance with a commercial proxy, so importing it is the start of your environment check, not evidence of provider compatibility.

For a provider endpoint authorized by source IP, confirm that the worker’s actual outbound address is on its allowlist. Do not assume a hosted plan supplies a fixed outbound address without checking that plan’s current network configuration.

Handle an authenticated proxy URL as a secret

Proxy credentials can be part of the connection URL, using the form http://user:password@proxy.example:8080. Encode reserved characters in the username and password separately. The HTTP Request node’s ordinary Proxy parameter is a string field in the released description; it is not a dedicated encrypted credential field.

For self-hosted deployments, an administrator can inject the authenticated endpoint through the platform’s secret mechanism into the relevant proxy environment variables. Limit who can inspect the process environment and diagnostic output. For a workflow shared with editors, an IP-authorized endpoint or a controlled private egress service may avoid placing a password directly in its node parameters.

The external secrets documentation limits that feature to Enterprise plans and says external secrets resolve only in credential fields. Therefore a $secrets expression in the ordinary Proxy option is not a supported shortcut. Keep destination API credentials in n8n’s credential system; do not put a proxy password in the destination’s Basic Auth settings.

Check workflow exports and execution data before sharing them. Environment expressions, logs and exported configuration have different exposure paths; obscuring a value in a screenshot does not remove it from the stored workflow.

Verify scheduled jobs on the worker that executes them

In queue mode, workers perform workflow executions. A manual editor test and a scheduled production execution may therefore use different processes or hosts, depending on the deployment.

Apply the intended outbound configuration to every process that can execute the relevant job. An endpoint reachable from the main container may be unreachable from a worker because DNS, network policy or source-IP authorization differs. After changing a deployment secret, follow your deployment’s restart or rollout procedure so running processes receive it.

Keep a small diagnostic workflow available for operators. Record the execution identifier, worker environment and observed exit without recording the authenticated proxy URL. Compare the same destination from the same execution path when investigating a failure.

Use status codes to choose the next action

A 407 indicates proxy authentication needs attention. Check the supplied URL, encoding and authorization mode. A destination 401 needs its own credentials. A 403 requires inspection of the destination response, and a 429 should follow the service’s retry guidance.

The node implementation shows how response and redirect options affect error handling. Keep Never Error off for the initial diagnostic. If a production workflow turns it on to branch on status, make the status check explicit before sending data to a downstream step.

Keep TLS verification enabled. If a certificate fails, investigate trust configuration and the endpoint you reached. A proxy setting does not justify accepting every certificate. For further diagnosis, use the proxy error reference and IP restriction guide.

Keep AI tool routing and request budgets explicit

The HTTP Request node can also serve as a tool for an AI agent. Its network settings apply to that HTTP request, not automatically to the model connection or a separate browser service.

Keep the proxy endpoint fixed by the workflow owner. Let the agent fill only the request fields it needs for the authorized task, with destination and method restrictions where appropriate. Do not let page text or a tool response replace connection secrets or networking configuration.

An agent can call a tool more than once while pursuing a task. Set a request budget, bound retries and inspect returned status before treating the tool result as useful data. If the workflow launches a browser, configure its route separately using the Playwright guide. For custom Node code that uses Axios, use the Axios configuration guide.

Frequently asked questions