I'm pretty new to Node.js so this is possibly an basic understanding issue, but I'm getting ECONNREFUSED from a superagent http request when I don't think I should be:
$ curl http://localhost:5000/
{"you": "looking good"}
$ node
> var request = require("superagent");
> var req = request.get("http://localhost:5000/").on('error', function (err) {
console.log("There's an emergency is going on.", err)
}).end(function (data) {
console.log("All is well", data.body)
});
There's an emergency is going on. { [Error: connect ECONNREFUSED]
code: 'ECONNREFUSED',
errno: 'ECONNREFUSED',
syscall: 'connect' }
What assumption have I made that is breaking this? I'm actually writing isomorphic JavaScript and the exact same code making the http query on the browser works fine!
This sounds like a firewall problem, but first run ping localhost from a terminal. You should see localhost has IP 127.0.0.1. If it doesn't your hosts file is probably incorrect or not being loaded, and will need fixing.
If it's correct, try these one at a time then repeat the curl and superagent requests for comparison. If one step doesn't work, reverse it and move to the next:
disable any firewall (if this is the problem, you should add a rule for node rather than leaving the firewall disabled)
disable any anti-virus (again add permissions rather than permanently disabling)
sudo setenforce 0 if you're on a *nix (undo with sudo setenforce 1)
curl and superagent will use different user-agent strings - do you have a proxy running? Run curl http://localhost:5000/ -vvv to see exactly what curl is doing
If these still don't work you could try a packet capture tool like wireshark or tcpdump to trace the HTTP request and see where it's refused.
Related
I have the following setup:
Client => Proxy server => Origin Server
I'm using the following Node.js libraries for each of these pieces, respectively:
isomorphic-fetch => http-proxy => http
Here's a gist of the setup in two files, one for each of the servers and one for the client: https://gist.github.com/headquarters/850cbb199ff397c6da56fb8d86113a7e
To run this locally, run node server.js in one shell and node fetch.js in another shell.
With the servers running, if I go to http://localhost:8818 in a browser, I get the sample response {"a":"b"}, so that's working. If I go to http://localhost:9818, I also get that response, so the proxying appears to be working fine. However, if I run DEBUG=* node fetch.js, which includes the HTTP proxy agent, the request fails (see output at https://gist.github.com/headquarters/850cbb199ff397c6da56fb8d86113a7e#file-failure-txt).
Without the agent property, the fetch command works fine on the command line. How do I go about debugging this socket hang up error?
Turns out I didn't read the https-proxy-agent docs closely enough. This line was a bit confusing: An HTTP(s) proxy http.Agent implementation for HTTPS--the PROXY itself can be either HTTP or HTTPS, but the origin server has to be HTTPS for this flavor of proxy-agent. For an HTTP origin server, I had to use http-proxy-agent. Thus, the socket hang up was probably coming from https.Agent trying to access an HTTP endpoint. It worked when I switched to http-proxy-agent.
I have a simple Node.js bot that makes an HTTP request each second to a rest API.
If the returned data is right then I construct an URL where I HTTP POST.
Everything works alright but after ~4-5hrs of running I got this error
0|server | error: Error: getaddrinfo ENOTFOUND www.rest-api.com www.rest-api.com:443
0|server | at errnoException (dns.js:28:10)
0|server | at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:73:26)
Can someone explain to me why this has happened?
After I restart my server everything got working.
I'm using axios to make the http requests.
I met the same issue and solved it!
try:
sudo vi /etc/hosts
and add:
127.0.0.1 localhost
to hosts
The symptom is that the remote address cannot be resolved.
The cause could be many things. First, try to see if it's node specific by trying to resolve the address directly:
$ nslookup www.rest-api.com
Or:
$ dig www.rest-api.com
If that doesn't work, you've got a connectivity problem. It could be anything. Try looking at how long your DHCP lease lasts if you are using DHCP.
However if that does work fine but your node application still fails, you might be running into this: https://github.com/nodejs/node/issues/5436 , which is a bug in an underlying library. You can implement the workaround mentioned in that thread, which is specifying the IP version family through the following parameter { family: 4 } as a part of your request options.
I had this issue becuase there was a typo in my URL - the path did not exist. Gotta be careful with long subdomain URLs. I discovered the issue while using the Postman Console - available by going to View > Show Postman Console.
I got this error in Postman when I didn't have the Environment I wanted to use selected. The variables I was trying to call were therefore not defined.
I finally figured out what was causing this problem and didn't find any direct answers online, so I thought I'd post an answer (below). Anyway, here's the problem:
I have a simple node app running on port 3000. I was trying out some database connection pooling, and I wanted to load test it to make sure it was working the way I expected. I installed siege and tried:
$ siege -c 10 -r 10 -b http://localhost:3000
I got a Connection reset by peer error. So I tried reducing the number of connections:
$ siege -c 1 -r 1 -b http://localhost:3000
Same problem. I thought maybe it was a problem with siege, so I tried nperf and got a ECONNRESET error. Same with artillery.
The weird thing is that I could connect using curl, telnet, and the web browser and got a valid response.
I tried logging errors in the express app, but it never seemed to receive a request. I tried monitoring network traffic using nettop, but it never showed a connection using siege or nperf (though it did using curl).
I wrote a client app to connect using the same method that nperf uses (node's http.get function), and got the same ECONNRESET response.
I wrote a simple express app running on port 3001 and it worked fine! I tried commenting out most of the lines in my port 3000 app so it was basically the same as my 3001 app, but it still didn't work. I was beginning to suspect that webpack was doing something strange, and then finally started to realize...see answer below.
Maybe there's another program on port 3000!
So, I ran:
$ sudo lsof -i -P | grep -i "listen"
and I found an old VM I'd forgotten to halt, that had port 3000 exposed (another project). I shut it down and everything worked great!
I thought node warned if a port was being used, but for some reason it didn't notice this one.
Anyway, if you're getting a similar error, do a port scan!
I am making a request to a remote server using https and request, and getting a new error after updating node and request:
nes.get err: [Error: 140735207432576:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error:../deps/openssl/openssl/ssl/s23_clnt.c:741:
I already have the protocol set to SSLv3, so I'm wondering why it appears to be using tlsv1.
https.globalAgent.options.secureProtocol = 'SSLv3_method';
I've also tried adding this to request's options:
secureProtocol: 'SSLv3_method'
This error did not occur with earlier versions of Node.js and request, but now with node v0.10.15 and request 2.26.0, it has surfaced. Any ideas? Thanks!
Update -- narrowed this down to something that changes between request 2.14.0 and 2.16.0. 2.14.0 works and 2.16.0 does not work.
Make sure you are making a secure request to the correct port.
I've received this error when attempting to make a secure request to port 80 instead of port 443.
I would fire up Wireshark to verify that the bits on the wire are what you think they should be.
In my socket.io code,
socket.sockets.on('connection', function(client){
var ip = client.handshake.address.address;
..
}
ip always returns 127.0.0.1 and this is because the server sits behind a proxy.
How do I get remote address properly ?
Edit: I am using http-proxy
yes, this is working for me.
client.handshake.headers['x-forwarded-for'] || client.handshake.address.address;
I am properly getting the remote IP address and not 127.0.0.1
In version > 1.0, the syntax is similar:
socket.handshake.headers['x-forwarded-for'] || socket.request.connection.remoteAddress;
For people who may come from Google, using NGINX: none of these worked for me, I followed the answer in this other question and modified my proxy_pass, to create a new header that node could then use. Don't forget to call sudo systemctl restart nginx after.