ログを書く前に、とあるサイトから以下のような理由をコピペしておきます。最も重要なことは、ブロガーの手をノックするものを見ることです。
1. NGINX 502 エラーのトラブルシューティング
NGINX 502 Bad Gateway エラーは FastCGI の問題であり、NGINX を引き起こす
502 エラーの可能性が高くなります。オンラインで見つけたものと 502 Bad を組み合わせます
ここでは、ゲートウェイ エラーに関連する問題とトラブルシューティング方法のリストを示します。FastCGI の構成から始めましょう。
1.FastCGIプロセスが開始されているかどうか
2.FastCGIワーカープロセスの数が足りませんか
netstat -anpo grep "wc -l" を実行します。
FastCGI プロセスに近く、設定ファイルに設定された値に近いかどうかを判断します。これは、ワーカー プロセスの数の設定が少なすぎることを示しています
3.FastCGIの実行時間が長すぎる
実際の状況に応じて、以下のパラメータ値を調整します
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
4.FastCGIバッファが十分ではありません
nginxApacheと同様に、フロントエンドのバッファリング制限があり、バッファリングパラメータを調整できます
fastcgi_buffer_size 32k;
fastcgi_buffers 8 32k;
5.プロキシバッファが十分ではありません
プロキシを使用する場合は、調整してください
proxy_buffer_size 16k;
proxy_buffers 4 16k;
参照: http://www.server110.com
6.https 転送設定エラー
正しい設定方法
サーバー名 www.mydomain.com;
場所 /myproj/repos {
$fixed_destination $http_destination を設定します;
if ( $http_destination ~* ^https(.*)$ )
{
$fixed_destination http$1 を設定します;
}
proxy_set_header ホスト $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header 宛先 $fixed_destination;
proxy_pass http://subversion_hosts;
}
もちろん、バックエンドで使用する FastCGI の種類にも依存します。私は php-fpm を使用しましたが、トラフィックは 1 台のマシンで約 400,000 PV (動的ページ) でした。
現在、基本的に 502 は発生しません。
7.phpスクリプトの実行時間が長すぎます
php-fpm.confの<値を変更します。
name="request_terminate_timeout">0s の 0 を時刻に変更します
~~~~~~~~~~~~~~~~~~~~~~~~~~~ ゴージャスな分割線~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~
ブロガーが遭遇した問題は、コード内に参照によって渡され、502 に直接アクセスするパラメーターがあるためです。ブロガーがこの情報を見たとき、初めて display_errors を直接開いたときに、
その後、エラー表示がオンになったときに 502 が表示されず、いくつかの E_STRICT 警告が表示されるのはなぜだろうと疑問に思いましたが、何度もデバッグを行った後でも、理由を理解する方法はありませんでした。
仕方なく、次のようにnginxエラーのスクリーンショットを確認しました。そのときは、php fastcgi が報告するエラーではないと思っていましたが、なぜ nginx のエラーログに表示されるのでしょうか? あまり科学的ではないので、よく考えてみました
苦痛で無駄な調整を数回繰り返した後でも、まだ無力感があるので、これで終わりとしか言いようがありません。
幸運なプログラマーである私は、何らかのトラブルの後、ローカルの仮想マシン環境にエラー ログ ファイルが書き込まれていないことを知りませんでした。設定には問題はありませんでしたが、エラー ログは書き込まれませんでした。 (ブロガーは通常、苦情を言わないでください) ページにはエラーが直接表示され、xdebug が追加されているので、私の毛深い雨については書かない方が良いと思います。 ) ブロガーの鋭い目と高度な頭脳 (この時代のブロガーはもう少し自己主張が強くなければなりません) は、ファイルのアクセス許可に問題があるはずだと感じ、それについて何かをすることにしました。 chmod 777 の優れたスキルを使用して、php-fpm を再起動し、エラー コードをテストしました。エラー ログ ファイルには期待どおりに書き込まれました。今朝の問題を思い返すと、エラー警告の出力がログに書き込まれたものと同じになるのではないかといつも疑問に思います。寝る 次に、それを裸で実行し、表示をブロックし、502 を報告しなくなり、エラー ログがスケジュールどおりにログ ファイルに書き込まれます。 nginx のエラーログを確認して再度プレイすると、nginx がなくなっていることがわかりました。 間違い。 よし!問題は、502 エラーが PHP のエラー ログの権限の問題によるものだと感じています。それを書き込む方法がなく、CGI に直接スローされるため、nginx は 502 を取得します。なぜそれが CGI に放り込まれたのかについては、私にはわかりません。理解できる人はフォローしてください。 いくつかの動き。 それはすごいですね。この贅沢な旅も終わりました。ありがとうテレビ、ありがとう両親、ありがとうブログパーク。