【入門編】 HTTPステータスコード5xx系のサーバーエラー – ネットワーク基礎とWebセキュリティ実践ガイド

「サーバーが死んだ？」を読み解く。5xxエラーと向き合うための現場の心得

ネットワークエンジニアの皆さん、こんにちは！日々の運用、お疲れ様です。

Webサイトを閲覧していて、突然画面に「500 Internal Server Error」なんて表示が出て、冷や汗をかいた経験はありませんか？あるいは、深夜のオンコールで「サイトが繋がりません！」と叩き起こされた経験がある方もいるかもしれません。

今回は、そんなエンジニアを悩ませる「5xx系のサーバーエラー」について、郵便配達の仕組みに例えながら、現場での泥臭いトラブルシューティングまでを紐解いていきましょう。難しい理論は一旦置いて、まずは「何が起きているのか」をイメージするところから始めます。

—

郵便配達で例える「5xx系エラー」の世界

まず、皆さんがWebサイトを見るという行為を「遠くの友人に手紙（リクエスト）を出し、返事（レスポンス）をもらう」ことに例えてみましょう。

クライアント： 手紙を送るあなた
Webサーバー： 手紙を受け取り、中身を読んで返事を書く友人
ロードバランサー（LB）： 郵便局の仕分け担当者

この時、5xx系エラーが発生している状態とは、「手紙は無事に届いたけれど、友人の家で何らかのトラブルが起きて返事が書けない」という状況です。

1. 500 Internal Server Error：友人がパニック状態

「500」は、友人が手紙を読んだものの、その内容を処理するプログラムがバグを起こしたり、データベースとの接続に失敗したりして「うわっ、どうしよう！」とパニックになっている状態です。

現場の視点： サーバー側のプログラム（PHPやPythonなど）のログを確認しましょう。SQLの構文ミスや、メモリ不足が原因であることがほとんどです。

2. 503 Service Unavailable：友人が留守、あるいは忙しすぎ

「503」は、友人がメンテナンス中で不在だったり、あまりにも手紙が届きすぎて過労で倒れていたりする状態です。

現場の視点： サーバーのスペック不足、あるいはプロセスが飽和しています。ロードバランサーが「今は繋がないほうがいい」と判断しているケースも多いですね。

3. 504 Gateway Timeout：友人が返事を書くのに時間がかかりすぎた

「504」は、郵便局（ロードバランサー）が「返事が遅いな…もう待てない！」と諦めてしまった状態です。

現場の視点： サーバーは生きているけれど、処理が重すぎてタイムアウトしています。DBのクエリ最適化が必要なサインです。

—

現場で役立つ！ロードバランサーでのハンドリング

現場では、こうしたエラーをいかにユーザーに見せないか、あるいは適切にログを出すかが腕の見せ所です。例えば、Nginxをリバースプロキシとして使っている場合、以下のように設定して「エラーページ」をカスタマイズするのが定石です。

# nginx.conf の設定例
server {
    listen 80;
    
    # バックエンドのサーバーがダウンした際、ユーザーには綺麗な画面を見せる
    error_page 500 502 503 504 /custom_error.html;
    
    location = /custom_error.html {
        root /usr/share/nginx/html;
        internal; # 外部からは直接アクセスできないようにする
    }

    location / {
        proxy_pass http://backend_cluster;
        # タイムアウト時間を設定（長すぎるとユーザーがイライラし、短すぎるとすぐ504になる）
        proxy_read_timeout 60s; 
    }
}

ポイント： proxy_read_timeout の値は、アプリケーションの処理時間に合わせて慎重に調整します。ここを極端に短くすると、少し重い処理が走っただけで 504 が多発するので注意してくださいね。

—

トラブルに直面したとき、まず何をすべきか？

トラブルが起きたとき、パニックになるのは誰しも同じです。まずは落ち着いて、以下の手順で「切り分け」を行いましょう。

1. 「どこで」起きているか？

クライアントから直接サーバーにリクエストを送って試してみてください。ロードバランサーを経由しないと正常に動くなら、原因はロードバランサーの設定やヘルスチェックにあります。

2. 「何が」起きているか？

まずは access.log と error.log を見ましょう。特に error.log には、なぜサーバーが処理を拒否したかのヒントが書かれています。
コマンド例：tail -f /var/log/nginx/error.log

3. 「いつから」起きているか？

直前にデプロイ（更新）をしませんでしたか？設定変更の履歴を追いかけるのが、実は一番の近道だったりします。

—

最後に：エラーは「サーバーからのSOS」

5xxエラーは、サーバーが「もう無理！助けて！」と送っているSOSです。これを「単なるエラー」と捉えず、「システムが悲鳴を上げているサイン」として読み解けるようになると、ネットワークエンジニアとしてのレベルは一段と上がります。

まずは難しく考えず、curl -I コマンドで実際にHTTPレスポンスを確認するところから始めてみてください。

# ヘッダー情報を確認して、ステータスコードをチェックするコマンド
curl -I https://your-website.com

現場は常にトラブルの連続かもしれませんが、一つひとつ紐解いていけば、必ず解決の糸口は見つかります。一緒に、強靭で信頼されるネットワークを築いていきましょう！

それでは、また次回の記事でお会いしましょう。ハッピー・ネットワーキング！