Proxy issue with http node

[smitterer]

Hi!

When I directly query a webpage (no matter which one) using the http request node without a proxy, I get a valid response.
As soon as I set a proxy, I get different errors.

Using evomi proxy:

From HTTP Request

Error code

500

Full message

500 - "attempted 10times, but failed to connect to target site"

Request

{ "headers": { "content-type": "application/json", "accept": "application/json" }, "method": "GET", "uri": "https://orf.at", "gzip": true, "rejectUnauthorized": true, "followRedirect": true, "resolveWithFullResponse": true, "followAllRedirects": true, "proxy": "http://office23:fjza2LQ4wM9nDl8tPPdF_country-AT,[email protected]:1000", "timeout": 300000, "encoding": null, "json": false, "useStream": true }

Using dataimpulse proxy:

{
“errorMessage”: “Bad request - please check your parameters”,
“errorDescription”: “\n\n400 Bad Request\n\n

Bad Request

\n

Your browser sent a request that this server could not understand.
\nReason: You’re speaking plain HTTP to an SSL-enabled server port.
\n Instead use the HTTPS scheme to access this URL, please.
\n

\n\n”,
“errorDetails”: {
“rawErrorMessage”: [
“400 - "\n\n400 Bad Request\n\n

Bad Request

\n

Your browser sent a request that this server could not understand.
\nReason: You’re speaking plain HTTP to an SSL-enabled server port.
\n Instead use the HTTPS scheme to access this URL, please.
\n

\n\n"”
],
“httpCode”: “400”
},
“n8nDetails”: {
“nodeName”: “Get Geizhals Product1”,
“nodeType”: “n8n-nodes-base.httpRequest”,
“nodeVersion”: 4.2,
“itemIndex”: 0,
“time”: “5.6.2025, 14:10:58”,
“n8nVersion”: “1.49.0 (Self Hosted)”,
“binaryDataMode”: “default”,
“stackTrace”: [
“NodeApiError: Bad request - please check your parameters”,
" at Object.execute (/usr/local/lib/node_modules/n8n/node_modules/n8n-nodes-base/dist/nodes/HttpRequest/V3/HttpRequestV3.node.js:1641:33)“,
" at processTicksAndRejections (node:internal/process/task_queues:95:5)”,
" at Workflow.runNode (/usr/local/lib/node_modules/n8n/node_modules/n8n-workflow/dist/Workflow.js:725:19)“,
" at /usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/WorkflowExecute.js:673:51”,
" at /usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/WorkflowExecute.js:1085:20"
]
}
}

I tested both with http://, https://, with and without “ignose ssl issues” option.

In other programs like Octoparse, both proxies work without any issue.

Does anyone have an idea what the problem could be?
I also tried it in an exec node, same issue.

Information on your n8n setup

• **n8n version: 1.48.0
• **Database (default: SQLite): SQLite
• n8n EXECUTIONS_PROCESS setting (default: own, main):
• **Running n8n via (Docker, npm, n8n cloud, desktop app): Docker
• **Operating system: CentOS with Plesk

[hubschrauber]

The 2nd error message suggests you have something crosswired re: http vs https. It’s difficult to zero in on that without seeing the specifics of what options were set when things failed. Be sure if the url you are requesting is https, that the proxy itself is capable of receiving and forwarding https requests on the host:port you have configured as the proxy (whether or not that is using https).

If it is an option for you to update n8n from 1.48.0, that would be a good first step. It is very likely some proxy related issues have been fixed since that was released nearly a year ago.

It might shed some light to try one more proxy which you can set up side-by-side with n8n in your Docker environment.

If those suggestions don’t help get things working, please post a copy of the workflow/nodes so everyone can have a look at how you actually have things configured.

[smitterer]

Updating unfortunately didn’t help.

I will try setting up the mitmproxy.

According to dataimpulse, I should use http proxy even though I’m targeting a https site.

[hubschrauber]

Right, there are 2 places to match up http vs https.

The proxy itself will accept traffic on one or the other, so the proxy target would either be http://myproxy:3128 or https://myproxy:3128

Then, the URL you are trying to reach through the proxy would use one or the other, so it would be http://someremoteservice/api/v1/whatever or (more likely these days)https://someremoteservice/api/v1/whatever

If you had a proxy target URL of (non-SSL) http://myproxy:3128 and a request URL of (SSL) https://someremoteservice/api/v1/whatever then the connection would be:

n8n (http) → myproxy (https) → someremoteservice

[Ya3melo]

Had the same issue when I first added a proxy into my workflow—kept getting timeouts or weird errors even though the site worked fine without it. Ended up switching to Residential Proxies since I needed more stable, real-user IPs. Once I made that change and adjusted the headers a bit, the requests started going through smoothly.