Proxy doesn't work

Questions
1

Describe the problem/error/question

Can’t figure out how to make proxy work.
I use docker container and use this:
ALL_PROXY=socks5h://172.17.0.1:1080 HTTP_PROXY=http://172.17.0.1:1080 HTTPS_PROXY=http://172.17.0.1:1080 N8N_TLSSERVER=false NODE_TLS_REJECT_UNAUTHORIZED=0

Other containers work fine with this proxy. It is xray-core as a client outside of docker, n8n is inside docker. Http requests work fine in n8n through this proxy. Https doesn’t work.

What is the error message (if any)?

Bad request - please check your parameters
400 The plain HTTP request was sent to HTTPS port 400 Bad Request The plain HTTP request was sent to HTTPS port

Please share your workflow

I use a request node.
I am making a https request

Share the output returned by the last node

Information on your n8n setup

  • n8n version: latest
  • Database (default: SQLite): SQLite
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app): Docker
  • Operating system: Ubuntu Server
2

Hi @ibaikov

This issue is caused by sending a plain HTTP request to a destination expecting HTTPS, often due to misconfigured proxy handling in Docker or how the HTTP Request node handles the HTTPS_PROXY variable.

Key Problem

The error:

400 Bad Request: The plain HTTP request was sent to HTTPS port

means n8n (or the underlying axios/node-fetch) did not properly upgrade the request to HTTPS, even though the target is https://.

Solution Options

:white_check_mark: 1. Use http-proxy to tunnel HTTPS via SOCKS5/HTTP proxy

Docker doesn’t natively support SOCKS5 proxy environment variables fully across all protocols. You can fix this by setting up a local forwarder.

Use proxychains-ng or tsocks inside the container to wrap HTTPS requests, or use a HTTP CONNECT tunnel.

Alternatively, if you’re using xray-core, configure it to expose a local HTTP proxy port that supports tunneling (CONNECT method), for example:

"inbounds": [
  {
    "port": 1080,
    "listen": "127.0.0.1",
    "protocol": "socks",
    "settings": {
      "udp": true
    }
  },
  {
    "port": 8888,
    "listen": "127.0.0.1",
    "protocol": "http",
    "settings": {
      "allowTransparent": false
    }
  }
]

Then in Docker, use:

HTTP_PROXY=http://172.17.0.1:8888
HTTPS_PROXY=http://172.17.0.1:8888

8888 is the HTTP CONNECT-capable proxy, while 1080 is only for SOCKS5.

:white_check_mark: 2. Use curl or wget in Execute Command node instead

If n8n’s internal node fails and you only need HTTPS access, use a shell node to run:

curl -x http://172.17.0.1:8888 https://example.com

:white_check_mark: 3. Add Docker --network host (dev only)

This allows the container to use the host network directly, so localhost:1080 resolves properly. Not secure for production.

Recap

  • Error happens because HTTPS isn’t properly tunneled via your proxy.
  • SOCKS5 (socks5h://) is not supported by all HTTP clients used inside n8n.
  • Expose an HTTP CONNECT proxy via xray (port 8888) and update your Docker HTTPS_PROXY accordingly.
3

@Miquel_Colomer thanks for the options!

I tried to remove socks5 and use

HTTP_PROXY=http://172.17.0.1:8888
HTTPS_PROXY=http://172.17.0.1:8888

along with changing xray config, but it didn’t work. Not sure why.

I will try other options later.

4

You’re definitely on the right path — the issue you’re hitting is a classic one when dealing with proxies and Docker.

That 400 error (plain HTTP request was sent to HTTPS port) tells us the proxy didn’t tunnel the request correctly. Even though you switched from SOCKS5 to HTTP proxy (on 8888), it seems something’s still off in how the container routes requests.

Here are a few quick things to double-check based on your setup:

1. Is your proxy (xray) actually listening on 172.17.0.1:8888?

From inside the container, try:

curl -x http://172.17.0.1:8888 https://google.com

If that fails or hangs, it means either:

  • xray isn’t exposing the proxy on Docker’s internal bridge
  • OR Docker isn’t resolving 172.17.0.1 the way you expect

Try replacing 172.17.0.1 with your actual host IP (run ip a on the host) or use host.docker.internal (works on Mac and Windows, and with --add-host=host.docker.internal:host-gateway on Linux).

2. Confirm xray is handling HTTP CONNECT

Make sure your inbounds config for the HTTP proxy (port 8888) includes support for tunneling. Axios (which n8n uses) needs that to send HTTPS traffic.

You can test it with:

curl -x http://<your-proxy>:8888 -v https://example.com

If the proxy returns a 400 or 405, it’s not handling CONNECT properly.

3. Try using Execute Command temporarily

As a quick workaround, the Execute Command node can run curl successfully even if the HTTP Request node fails:

curl -x http://172.17.0.1:8888 https://example.com

Just pass the response into n8n using stdout.

4. In case nothing works — try --network host (only for testing)

If you’re still stuck, try:

docker run --network host ...

This allows your container to access the exact network interfaces your host sees — useful to rule out Docker bridge issues. Don’t use this in production, but it’s good for debugging.

5

Hey @ibaikov,

We have a long standing issue with Axios where it doesn’t fully support HTTPS traffic being sent to an HTTP Proxy so you would need to configure your proxy to have an https listener as well so https_proxy would be https://172.17.0.1.1443 instead of http://.

6

Yeah I tried that before posting, but for some reason it didn’t work, don’t know why. Yes, xray’s config is correct, it did use https, etc.

In the end I solved this by using openwrt and a homeproxy package (sing-box) on my router, so n8n that is connected to this router can always access something blocked. This was easier to do than to debug the n8n/docker proxy issue.

Thanks anyway folks!

7

Hi.

I am very glad that I found your answer. It helped me understand why third-party proxies (e.g. http://user:pass@proxy:port) do not work in n8n (Self-hosting version 1.91.3).

Unfortunately, I was unable to solve the problem with HTTPS requests via http proxy (400 Bad Request). I tried several different proxy providers, but it does not work. All proxy providers I contacted say that their proxies handle HTTPS via CONNECT. Unfortunately, I was unable to find an HTTPS proxy provider that worked in n8n.

Please tell me where I can find proxies that are guaranteed to work with HTTPS requests via proxy in n8n?

Perhaps you can suggest other alternative solutions to this problem using proxies in n8n?