502 Bad Gatewayが出るとき、どこを見るか

レン

サイトを開いたら「502 Bad Gateway」って出た…！サーバーが壊れたの？

プロクラ

落ち着いて。この番号には、はっきりした意味があるよ。「前に立っているWebサーバーは動いている。でも、その後ろにあるはずのアプリから返事が来ない」という状態だ。

プロクラ

つまり、少なくとも半分は生きている。サーバーごと落ちていれば、そもそもこの画面すら出ないからね。原因はほぼ「後ろ側」に絞れる。

構成を思い出す

プロクラ

多くの構成では、外からの通信をまずnginxやApacheが受け取り、それを後ろのアプリへ渡している。この受け渡しのどこかが切れると502になるんだ。

• 利用者 → nginx（ここは動いている。だから502が返せる）
• nginx → アプリ（PHP・Node.js・Pythonなど）← ここが切れている
• アプリ → データベース（ここが原因で、アプリが応答できないこともある）

原因になりやすい5つ

• アプリのプロセスが起動していない（再起動後に立ち上げ忘れが最多）
• アプリが落ちた（メモリ不足で強制終了されたケースを含む）
• 受け渡し先の指定が食い違っている（ポート番号やソケットのパス）
• アプリの起動に時間がかかり、待ち時間を超えた
• アプリは動いているが、データベース待ちで応答が返せない

プロクラ

1つめと2つめが圧倒的に多いよ。特に、更新のために再起動したあと、自動起動の設定を入れていなかった、という形はよくある。

確認する順番

プロクラ

闇雲に設定を触る前に、この順で見よう。1つずつ潰していけば、たいてい3番目までに見つかる。

• アプリのプロセスが動いているか（systemctl status や ps で確認）
• エラーログを見る。nginxのエラーログには、どこへ繋ごうとして失敗したかが残る
• アプリ自身のログを見る。起動時に失敗していれば理由が書いてある
• free -h でメモリを見る。不足していれば、落ちた原因はこちら
• 設定ファイルの受け渡し先が、アプリの待ち受けと一致しているか

プロクラ

2つめが特に効くよ。nginxのエラーログは「connect() failed」のような形で、繋ごうとした先まで書いてくれる。そこを読めば、設定の食い違いか、相手が居ないのかが分かる。

再発させないために

• アプリを自動起動の設定にしておく（再起動後の立ち上げ忘れが消える）
• 落ちたときに自動で再起動する仕組みを入れる
• メモリ不足が原因なら、根本はプランかアプリ側の問題
• サイトが見えなくなったことに気づける監視を用意する

プロクラ

最後がいちばん大事かもしれない。502は自分では気づきにくいんだ。訪問者から指摘されて初めて知る、という状態は避けたいね。

レン

前は生きていて、後ろが返事をしていない。まずプロセスとログを見る。