Nginx throws connection refused error intermittently. Here is the error stack trace,
[error] 12035#12035: *177490 connect() failed (111: Connection
refused) while connecting to upstream, client: xxx.xx.xx, server:
xxx.xx.xx, request: "POST / HTTP/1.1", upstream: "xxxx", host:
"xxx.xx.xxx"
These errors won't occur all the time, but they appear in the log file intermittently. I think it's a serious issue since these errors occure very often. Can someone please shed some light on this issue?
Thanks
Related
I've installed OSticket application on my nginx server.
The webpage is opened only first time, if I simply refresh the page, it gives connection reset by peer upstream error..
I tried to change fastcgi_read_timeout and max_execution time as described in https://laracasts.com/discuss/channels/forge/502-bad-gateway-with-large-file-uploads and https://www.scalescale.com/tips/nginx/configure-max_execution_time-in-php-fpm-using-nginx/#, that didn't help.
nginx error log:
2017/08/07 22:15:08 [error] 26877#26877: *42 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 10.231.1.79, server: web.com, request: "GET /ticket/logo.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php-fpm/php-fpm.sock:", host: "web.com", referrer: "https://web.com/ticket/"
PHP-FPM error log:
WARNING: [pool www] child 26883 exited on signal 11 (SIGSEGV) after 4270.119171 seconds from start
I've been trying for sometime to use the mplz utility to deploy and run a Meteor app. It seems (well now it seemed) simpler and more unified than Meteor Up which said it was targeted towards Debian/Ubuntu distros.
After running a successful mplz setup on a clean CentOS7 image, I cannot access the app. All I have ever gotten is an "nginx error!" page. In the nginx error log I saw this at first:
2016/03/14 17:14:47 [crit] 4997#0: *2 connect() to 127.0.0.1:3000 failed (13: Permission denied) while connecting to upstream, client: myLocalIP, server: domain.com, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:3000/", host: "domain.com"
After doing some research I believe I fixed the permissions issue by changing the nginx user and adding the users to the appropriate groups. The website still only displayed the nginx error page, but had a new message in the error_log.
I am now getting a connection refused error:
2016/03/14 18:15:59 [error] 2489#0: *2 connect() failed (111: Connection refused) while connecting to upstream, client: myLocalIp, server: domain.com, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:3000/", host: "domain.com"
All I'm really trying to get done is deploy a persistent copy of my Meteor app to the server. I am not at all familiar with nginx or server-ops kind of stuff, I've mainly worked on existing websites working on features.
I would love any suggestions of how to solve this issue OR how to better or more easily deploy Meteor to a public server.
I have a codebase that's running fine con HHVM.
I'm realizing some load tests with apache ab tool but when i test with 100 concurrent requests I start to get 502 gateway errors.
I generally only get two types of logs in nginx's error log:
2015/01/10 09:42:48 [crit] 29794#0: *302 connect() to
unix:/var/run/hhvm/hhvm.sock failed (2: No such file or directory)
while connecting to upstream, client: 192.168.56.211, server: ,
request: "GET /api/v2/checkaccess HTTP/1.1", upstream:
"fastcgi://unix:/var/run/hhvm/hhvm.sock:", host: "instela.com"
2015/01/10 09:42:26 [error] 29794#0: *264 connect() to
unix:/var/run/hhvm/hhvm.sock failed (111: Connection refused) while
connecting to upstream, client: 192.168.56.211, server: , request:
"GET /api/v2/checkaccess HTTP/1.1", upstream:
"fastcgi://unix:/var/run/hhvm/hhvm.sock:", host: "instela.com"
Under high load this error occurs on all load balanced backends servers, so it's not a server specific problem (I hope)
Mostly after some time HHVM returns back but many times I had to restart the daemon to bring the server back.
I am using the default configuration mostly. Here I've my configuration: http://pastie.org/9823561
I am using Nginx as Proxy for Websocket SSL upgrade to Asterisk backend.
However at times, my users just couldn't connect to Asterisk. On Asterisk end, I do not see any connection attempt.
Thus I was looking at nginx error log and I found a lot of such error
[error] 1049#0: *28726 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 103.246.xx.xx, server: xxx.xxx.io, request: "GET / HTTP/1.1", upstream: "http://0.0.0.0:8088/ws", host: "yyy.xxx.io"
Is there any clue on how can I solve this?
Is this correct? http://0.0.0.0:8088/ws
In the Internet Protocol version 4 the address 0.0.0.0 is a non-routable
meta-address used to designate an invalid, unknown or non applicable target.
To give a special meaning to an otherwise invalid piece of data is
an application of in-band signaling.
Source: http://en.wikipedia.org/wiki/0.0.0.0
2014/03/31 23:06:50 [error] 25914#0: *765 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 173.77.251.136, server: wiki.resonant-rise.com, request: "POST /index.php?title=Chisel&action=submit HTTP/1.1", upstream: "fastcgi://127.0.0.1:9016", host: "wiki.resonant-rise.com", referrer: "http://wiki.resonant-rise.com/index.php?title=Chisel&action=edit"
2014/03/31 23:06:50 [error] 25914#0: *765 open() "/usr/share/nginx/html/50x.html" failed (2: No such file or directory), client: 173.77.251.136, server: wiki.resonant-rise.com, request: "POST /index.php?title=Chisel&action=submit HTTP/1.1", upstream: "fastcgi://127.0.0.1:9016", host: "wiki.resonant-rise.com", referrer: "http://wiki.resonant-rise.com/index.php?title=Chisel&action=edit"
I have a mediawiki installation and an IPB installation. They both through up errors but this one error from mediawiki prevents me from posting semi-large articles. I have tried a lot of the solutions out there, adding catch_workers_output = yes, adjusting pm.* settings. Still not able to resolve this issue. I am coming to my wits end trying to figure this one out.
PHP-FPM Conf
http://pastie.org/private/aczklc52ll9yv0uz5drcqg
PHP-FPM WWW.CONF
http://pastie.org/private/wod3xipxhm8ractksw7ha
NGINX VHOST for MEDIAWIKI
http://pastie.org/private/h9co8aykbdmfzk2bd5qq
If the failure depends on size of the pages, it has to do with how much work the operation causes. My wild guess would be: increase the timeout (you currently have send_timeout 60s;).
It's easy for the parse time of a very long page to go over 60 seconds, especially if you're on a low power server, have not tuned performance or have enabled heavy parser extensions.
in my case it was that the php version of the project was different with the version of php I had been