Nginx の 500 エラー:原因と解決策
冒頭まとめ Nginx が返す 500 Internal Server Error には、出どころが2つあります。Nginx 自身が処理を続けられずに生成したものと、上流のアプリケーションが返した 500 をそのまま中継しただけのものです。この2つは対処が完全に別なので、最初に切り分ける必要があります。 見分け方は単純です。Nginx 自身が生成した場合、error.log に必ず理由を書いた行が出ます。中継しただけの場合、access.log には 500 が記録されますが、error.log に Nginx 発の行は出ません。つまり、ログを2つ並べて、同じ時刻に対応する行があるかどうかを見れば、責任の所在はその場で決まります。 先に否定しておくべき筋が1つあります。上流への接続が失敗した場合や、上流の応答が遅れて打ち切られた場合は 500 になりません。Nginx のソースでは、接続の失敗は 502 Bad Gateway、時間切れは 504 Gateway Timeout として確定されます。connect() failed (111: Connection refused) の行を見て 500 の原因だと考えるのは、この分岐と食い違います。502 と 504 の調べ方はそれぞれ別記事にあります(Nginx の 502 の記事、504 の記事)。 Nginx 自身が 500 を生成する場面で最も多いのは、内部リダイレクトの循環です。Nginx は1つのリクエストの中で内部的に転送できる回数を10回と定めており、これを使い切ると循環とみなして 500 を返します。この上限は NGX_HTTP_MAX_URI_CHANGES として定義されています。 エラーの概要 利用者側に表示されるのは、次の定型の応答です。この画面だけでは、Nginx 発かアプリケーション発かは判別できません。 <html> <head><title>500 Internal Server Error</title></head> <body> <center><h1>500 Internal Server Error</h1></center> <hr><center>nginx/1.28.0</center> </body> </html> 判別の材料は error.log です。内部リダイレクトの循環なら、次のいずれかの形で記録されます。 ...
<html>
<head><title>500 Internal Server Error</title></head>
<body>