HTTP Request via Proxy (connect ECONNREFUSED 127.0.0.1:80)

[alfomin]

Hi everyone!

I’m trying to use a proxy server in HTTP Request (I put it in the options section of the node)
And this kind of error occurs, no matter what server address I specify:

{
"status": "rejected",
"reason": {
"message": "connect ECONNREFUSED 127.0.0.1:80",
"name": "Error",
"stack": "Error: connect ECONNREFUSED 127.0.0.1:80 at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1146:16)",
"code": "ECONNREFUSED"
}
}

NodeApiError: UNKNOWN ERROR - check the detailed error for more information
    at Object.execute (/usr/local/lib/node_modules/n8n/node_modules/n8n-nodes-base/dist/nodes/HttpRequest.node.js:860:27)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
    at async /usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/src/WorkflowExecute.js:447:47

We’re currently on n8n v. 0.142.0, and it’s being run in Docker.

I’m trying proxy servers from this list: https://spys.one/en/free-proxy-list/

Please help me understand, how to fix it.

[RicardoE105]

Welcome to the community @alfomin

Are you running the proxy server locally? What version of n8n are you using?

[alfomin]

v. 0.142.0

I’m trying proxy servers from this list https://spys.one/en/free-proxy-list/

[RedPacketSec]

i also get this when using a local proxy on local network. it happened since the switch over to a new backend tool in n8n I believe.

[samuk]

I also have this error. I’m running N8N under https://docs.cloudron.io/

[RicardoE105]

Probably the change form request to axios.

You can try setting the env variable N8N_USE_DEPRECATED_REQUEST_LIB=true

[RedPacketSec]

yeah i’d like to not go back to depreciated if possible. But the new HTTP engine totally crippled my TOR scraping via a local proxy device.

[Uness]

Hi,

I’m facing the same issue,
Have you find any solution ?

Thank you

[MutedJam]

Hi @Uness, have you tried setting the N8N_USE_DEPRECATED_REQUEST_LIB=true enviroment variable suggested by Ricardo to (temporarily) switch to the old library to see if this addresses the issue?

I can see that my colleagues have already flagged this to @krynble who will be back next week and who will take a closer look into the implications of the library change in this context. Until then it would be of great help if you could the above suggestion a go to narrow down the issue.

[Uness]

Hi @MutedJam

Just tested that, but no sucess.

I’m using Private Dedicated Proxies i just bought. I’m sure that i’m missing something.

[Jon]

I got bored so took a quick look at this one, The problem is the proxy option is being sent in the wrong format to Axios so you end up with "proxy": "whatever_the_value" and it looks like Axios wants an object like "proxy" : { "host": "host_name", "port": "port" }

As a very quick and dirty concept if you pop open HttpRequest.node.ts and find if (options.proxy !== undefined) ~ line 715…

Replace:

requestOptions.proxy = options.proxy as string;

With

let proxy = (options.proxy as string).split(":");
requestOptions.proxy = {host: proxy[0], port: proxy[1]};

It will start working as expected, There is a catch though… In the UI where you input the proxy address it won’t work with a protocol as Axios always assumes HTTPS (why would you use an HTTP proxy anyway) so you would need to input the IP / Hostname and port like 13.229.73.17:443 (this is a proxy I found on the free list)

Happy to pop in a pull request with this quick fix but I think a better one might be to have 2 fields for proxy one for host and one for port and if it can be worked out a select box for the protocol (HTTP / HTTPS / SOCKS(?) ).

Anyway… I hope this helps those with problems using proxies.

[Jon]

If anyone is interested I have create a pull request for this one.

Updated HTTP Request Node to use proxies and added a couple of options

I have also added in a couple of extra options for proxies that require authentication.

[krynble]

Hello everyone!

I’m sorry about the delay! Thanks @Jon for your help!

I created another PR based on your changes that make n8n compatible with both request and axios libraries.

You can follow-up on it here: Fixed the way proxies are declared with axios by krynble · Pull Request #2384 · n8n-io/n8n · GitHub

Should be released soon.

[Jon]

@krynble looks good to me, I didn’t look into the protocol side of Axios too much but if you specify HTTP does that include HTTPS as well or does HTTPS need to be a config option as I can’t see many people using an HTTP proxy.

[krynble]

Hey @Jon

In order to use https you’d need to specify it as part of your proxy URL, such as: https://user:[email protected]:1234

You can also use SOCKS5 for instance this way.

[Jon]

Nice that is a winner

[jan]

Got released with [email protected]

[RedPacketSec]

i’ll have to check if my docker has auto-updated to this version

[Anthony]

@alfomin

I’m trying to use a proxy server in HTTP Request (I put it in the options section of the node)
And this kind of error occurs, no matter what server address I specify:

If you are trying to use HTTP node with proxies to scrape some external website, this might be very relevant:

ScrapeNinja n8n node supports custom proxies and also features rotating proxies from many countries, out of the box.

if “custom proxy” is selected, http(s) proxy can be filled in http://user:pw@host:port format.

[NEW] ScrapeNinja official integration with n8n: web scraping API with rotating proxies and real browser

ScrapeNinja is a web scraping API SaaS that can run a real browser and capture website screenshots. I use it with n8n every day to scrape thousands of web pages and extract useful data. Ever since I published my first n8n web scraping tutorials using the ScrapeNinja API (via the n8n HTTP request node), I’ve received tons of questions from n8n users — understandably so, because ScrapeNinja offers many parameters to control proxies, browser behavior, and more. Putting all these params into big JS…

[Shriket_Panchal]

Based on the ECONNREFUSED 127.0.0.1:80 error when trying to use a proxy in your n8n Docker setup, here’s the most likely immediate solution and why:

Short & Direct Solution:

The error ECONNREFUSED 127.0.0.1:80 strongly indicates that the proxy settings in your n8n HTTP Request node are either incorrectly configured with 127.0.0.1:80 (which is your local machine, not a public proxy) or the proxy settings are not being applied at all, and it’s attempting a local connection.

Therefore, the first and most crucial step is to carefully verify and correct the proxy settings in your n8n HTTP Request node’s “Options” section.

Here’s what you need to do:

1. Double-check the “Proxy URL” field: Ensure you have entered the correct IP address and port of the external proxy server you intend to use (e.g., http://<proxy_ip>:<proxy_port> or https://<proxy_ip>:<proxy_port>). Make absolutely sure it is NOT 127.0.0.1:80.
2. Verify the Protocol: Confirm if the proxy server uses HTTP or HTTPS and prepend the correct protocol to the “Proxy URL.”
3. Authentication (If Required): If the proxy server requires a username and password, ensure you have correctly filled in the “Proxy Username” and “Proxy Password” fields in the “Options” section.