A forward proxy is used on this network. That’s to say all requests must go through http://<proxy_ip>:8080. All http and https go through this proxy url.
Wget and curl work fine in the server since env vars are set (http_proxy and https_proxy).
N8n 0.173.0 is installed in npm (not docker), in ubuntu 20.04.
My working theory is that axios has trouble using an http proxy url for https requests. There are posts explaining this exact behaviour or similar: [Solved] axios Request to HTTPS with HTTP proxy fails.
What is the error message (if any)?
When using http request node, and getting a http request it works fine. For instance:, NeverSSL - helping you get online is fetched fine.
When hitting an https url it errors out with: {"status":"rejected","reason":{"message":"400 - \"<html>\\r\\n<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>\\r\\n<body>\\r\\n<center><h1>400 Bad Request</h1></center>\\r\\n<center>The plain HTTP request was sent to HTTPS port</center>\\r\\n<hr><center>nginx</center>\\r\\n</body>\\r\\n</html>\\r\\n\"","name":"Error","stack":"Error: Request failed with status code 400\n at createError (/home/ubuntu/.npm-global/lib/node_modules/n8n/node_modules/axios/lib/core/createError.js:16:15)\n at settle (/home/ubuntu/.npm-global/lib/node_modules/n8n/node_modules/axios/lib/core/settle.js:17:12)\n at IncomingMessage.handleStreamEnd (/home/ubuntu/.npm-global/lib/node_modules/n8n/node_modules/axios/lib/adapters/http.js:269:11)\n at IncomingMessage.emit (events.js:412:35)\n at endReadableNT (internal/streams/readable.js:1334:12)\n at processTicksAndRejections (internal/process/task_queues.js:82:21)"}}
Please share the workflow
Share the output returned by the last node
{"status":"rejected","reason":{"message":"400 - \"<html>\\r\\n<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>\\r\\n<body>\\r\\n<center><h1>400 Bad Request</h1></center>\\r\\n<center>The plain HTTP request was sent to HTTPS port</center>\\r\\n<hr><center>nginx</center>\\r\\n</body>\\r\\n</html>\\r\\n\"","name":"Error","stack":"Error: Request failed with status code 400\n at createError (/home/ubuntu/.npm-global/lib/node_modules/n8n/node_modules/axios/lib/core/createError.js:16:15)\n at settle (/home/ubuntu/.npm-global/lib/node_modules/n8n/node_modules/axios/lib/core/settle.js:17:12)\n at IncomingMessage.handleStreamEnd (/home/ubuntu/.npm-global/lib/node_modules/n8n/node_modules/axios/lib/adapters/http.js:269:11)\n at IncomingMessage.emit (events.js:412:35)\n at endReadableNT (internal/streams/readable.js:1334:12)\n at processTicksAndRejections (internal/process/task_queues.js:82:21)"}}
Information on your n8n setup
n8n version: 0.173.0
Database you’re using (default: SQLite): default
Running n8n with the execution process [own(default), main]: default
Running n8n via [Docker, npm, n8n.cloud, desktop app]: npm
I would say your error is possibly different, It looks like you are getting a message from an NGINX server so the request is being sent out but something is going on once it has left n8n. At the moment though I am not sure why you would get that error message, I was about to test it on a Squid setup I have but Squid is telling me it isn’t set up for SSL traffic so I need to work on the configuration to allow it.
Have you tried checking the proxy logs to see what is being sent? In theory you should see the https url in the log.
Hey @Jon .
I saw that but was confused about nginx being part of n8n, but of course, since it’s npm it can’t be.
I don’t have access to the proxy logs…
The thing is it fails on all https traffick, but wget and curl work fine…
I installed cntlm on the server to work as a mitm proxy for n8n. Again, it works fine with wget, but stalls n8n (https).
it may also be relevant that I have setup env vars… and the behaviour is different if I set the proxy option in the node settings…
I’m going to clear the env vars and see what happens.
without env vars, and setting proxy option to http://127.0.0.1:3128: {"status":"rejected","reason":{"message":"400 - \"<html>\\r\\n<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>\\r\\n<body>\\r\\n<center><h1>400 Bad Request</h1></center>\\r\\n<center>The plain HTTP request was sent to HTTPS port</center>\\r\\n<hr><center>nginx</center>\\r\\n</body>\\r\\n</html>\\r\\n\"","name":"Error","stack":"Error: Request failed with status code 400\n at createError (/home/ubuntu/.npm-global/lib/node_modules/n8n/node_modules/axios/lib/core/createError.js:16:15)\n at settle (/home/ubuntu/.npm-global/lib/node_modules/n8n/node_modules/axios/lib/core/settle.js:17:12)\n at IncomingMessage.handleStreamEnd (/home/ubuntu/.npm-global/lib/node_modules/n8n/node_modules/axios/lib/adapters/http.js:269:11)\n at IncomingMessage.emit (events.js:412:35)\n at endReadableNT (internal/streams/readable.js:1334:12)\n at processTicksAndRejections (internal/process/task_queues.js:82:21)"}}
same, but proxy option set to https://127.0.0.1:3128:
{“status”:“rejected”,“reason”:{“message”:“read ECONNRESET”,“name”:“Error”,“stack”:“Error: read ECONNRESET\n at TLSWrap.onStreamRead (internal/stream_base_commons.js:209:20)”,“code”:“ECONNRESET”}}
Slightly different errors if proxy option points directly to forward proxy.
Pointing to http://192.168.2.1:8080: {"status":"rejected","reason":{"message":"400 - \"<html>\\r\\n<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>\\r\\n<body>\\r\\n<center><h1>400 Bad Request</h1></center>\\r\\n<center>The plain HTTP request was sent to HTTPS port</center>\\r\\n<hr><center>nginx</center>\\r\\n</body>\\r\\n</html>\\r\\n\"","name":"Error","stack":"Error: Request failed with status code 400\n at createError (/home/ubuntu/.npm-global/lib/node_modules/n8n/node_modules/axios/lib/core/createError.js:16:15)\n at settle (/home/ubuntu/.npm-global/lib/node_modules/n8n/node_modules/axios/lib/core/settle.js:17:12)\n at IncomingMessage.handleStreamEnd (/home/ubuntu/.npm-global/lib/node_modules/n8n/node_modules/axios/lib/adapters/http.js:269:11)\n at IncomingMessage.emit (events.js:412:35)\n at endReadableNT (internal/streams/readable.js:1334:12)\n at processTicksAndRejections (internal/process/task_queues.js:82:21)"}}
And to https://192.168.2.1:8080: {"status":"rejected","reason":{"message":"Client network socket disconnected before secure TLS connection was established","name":"Error","stack":"Error: Client network socket disconnected before secure TLS connection was established\n at connResetException (internal/errors.js:639:14)\n at TLSSocket.onConnectEnd (_tls_wrap.js:1570:19)\n at TLSSocket.emit (events.js:412:35)\n at endReadableNT (internal/streams/readable.js:1334:12)\n at processTicksAndRejections (internal/process/task_queues.js:82:21)","code":"ECONNRESET"}}
They all look to be a similar error, It would be really handy to know what proxy it is and what the proxy log is saying. Do you know who manages the proxy or is it a cloud based service?
I’m going to talk to the proxy guy tomorrow (he’s off work now)… who knows, maybe this particular IT guy will be a nice dude…
It seems to me something is not working with an “https over http proxy” scenario. I can find many hits on this, regarding using axios… I’m leaning towards n8n because everything else works fine with this proxy.
That could be the case, but I find it odd that you are getting an error back from some other server. It would be interesting to see what that actually is and from there we might be able to work out how to solve it.
As a temporary solution you could try the older request library by setting the N8N_USE_DEPRECATED_REQUEST_LIB environment variable to true
I haven’t been able to talk to my colleague.
But I’ve set up a transparent proxy that routes all n8n traffic through the forward proxy with no issues. I prefer this to using a deprecated lib that may disappear any time.
This works for npm and docker both. I wrote instructions on the appsmith forum, since they have a limitation on not supporting a forward proxy at all (for the time being - they are working on it).
I though this might be useful for someone else, hope it’s ok posting it here:
Hi everyone. So, N8N_USE_DEPRECATED_REQUEST_LIB was already removed. Now all my external http requests fails. It seems I should stay on the pre-v1 release and wait for the fix. However, more than 1y left from the last comment, and there’s no update from n8n team.
You can work around this if you configure your proxy to also listen on HTTPS and set http_proxy to http://proxy:port and https_proxy to https://proxy:port
I talked to our proxy vendor. It’s expected, they won’t implement https://proxy:port. Most of the enterprise proxies support only http_proxy for both HTTP and HTTPS (that is HTTP CONNECT via HTTP) schemas.
According to Feature: HTTPS (HTTP Secure or HTTP over TLS) | Squid Web Cache wiki, https_proxy=https://host:port is a completely different thing called “Encrypted browser-Squid connection”. It’s rarely used. Here’s a quote: “Unfortunately, popular modern browsers do not yet permit configuration of TLS encrypted proxy connections. There are open bug reports against most of those browsers now, waiting for support to appear. If you have any interest, please assist browser teams with getting that to happen.”
I do undestand that this is not n8n fault. There’re a lot of open requests to Axios, and I hope they will finally manage to solve it. And n8n team will update the lib I’m an optimist, but the issue wasn’t solved by Axios for at least 3 years starting from 2020. Still relevant.
Now I can’t use the solution for external connections, the only way is to request direct acesses per website on a firewall. It takes a lot of time to apply, and brings additional security holes. And it’s not acceptable if one just want to test an ad-hoc flow.
I hope n8n team could also provide a workaround for this. Thank you!
That is interesting to know thanks, I have been thinking about a workaround for this but it won’t be a quick or easy change to make. If your proxy is using squid though it will support https_proxy which will work and is supported by a few browsers like Firefox and Chrome but the browsers don’t really matter as your users would continue to use the existing http_proxy.
I’m an optimist, but the issue wasn’t solved by Axios for at least 3 years starting from 2020. Still relevant.