我有一台服务器,在 2013 年 10 月 3 日上午 10:50 之前一直运行正常,但后来开始间歇性地向客户端返回 "502 Bad Gateway" 错误。
5 次浏览器请求中约有 4 次成功,但约有 1 次返回 502 错误。
nginx错误日志中包含数百个此类错误;
2013/10/05 06:28:17 [error] 3111#0: *54528 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 66.249.66.75, server: www.bec-components.co.uk request: ""GET /?_n=Fridgefreezer/Hotpoint/8591P;_i=x8078 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.bec-components.co.uk"
但 PHP 的错误日志中没有任何匹配的错误。
**是否有办法让 PHP 提供更多信息,说明重置连接的原因?
这是 nginx.conf
;
user www-data;
worker_processes 4;
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
access_log /var/log/nginx/access.log;
sendfile on;
keepalive_timeout 30;
tcp_nodelay on;
client_max_body_size 100m;
gzip on;
gzip_types text/plain application/xml text/javascript application/x-javascript text/css;
gzip_disable "MSIE [1-6]\.(?!.*SV1)";
include /gvol/sites/*/nginx.conf;
}
这是本站的 .conf
;
server {
server_name www.bec-components.co.uk bec3.uk.to bec4.uk.to bec.home;
root /gvol/sites/bec/www/;
index index.php index.html;
location ~ \.(js|css|png|jpg|jpeg|gif|ico)$ {
expires 2592000; # 30 days
log_not_found off;
}
## Trigger client to download instead of display '.xml' files.
location ~ \.xml$ {
add_header Content-disposition "attachment; filename=$1";
}
location ~ \.php$ {
fastcgi_read_timeout 3600;
include /etc/nginx/fastcgi_params;
keepalive_timeout 0;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
}
}
## bec-components.co.uk ##
server {
server_name bec-components.co.uk;
rewrite ^/(.*) http://www.bec-components.co.uk$1 permanent;
}
如果我的网络服务器告诉我:"502 坏网关",我一定会相信。
这是什么意思?
网关坏了的意思是:nginx无法通过fastcgi_pass访问127.0.0.1:9000定义的资源。
您的初始错误日志说明了一切:
.
recv() failed
-> nginx failed
(104: Connection reset by peer) while reading response header from upstream,
-> no complete answer, or no answer at all
upstream: "fastcgi://127.0.0.1:9000",
-> who is he, who failed???
从我有限的视角来看,我建议:
您可能需要考虑一下 github 上的这个 git: https://gist.github.com/amichaelgrant/90d99d7d5d48bf8fd209
我遇到过类似的情况,当我检查上游服务器的错误日志时,它们报告了一些 ulimit 错误,因此我将其增加到 1000000(在上游和 nginx 上),结果一切正常。