2013年10月3日午前10時50分頃までは正常に動作していたサーバーが、断続的にクライアントに "502 Bad Gateway" エラーを返すようになりました。
ブラウザからのリクエストの5回に4回は成功しますが、5回に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 Bad Gateway」と言っているなら、常に信用します。
これは何を意味しているのでしょうか?
バッドゲートウェイとは、nginxが定義されたリソース127.0.0.1:9000にfastcgi_passできないということです。
最初のエラーログがすべてを物語っています。
.
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エラーが報告されていたので、アップストリームサーバーとnginxの両方で1000000に増やしたところ、すべてがうまくいきました。
私の場合は、php-fpm
サービスを再起動することで解決しました。
sudo service php5-fpm restart
あるいは、膨大なリクエストのためにこの問題が起こることもあります。デフォルトでは、php5-fpmの pm.max_requests
は100以下になっているかもしれません。
この問題を解決するには、あなたのサイトのリクエスト数に応じてこの値を増やしてください。
その後、サービスを再起動する必要があります。