【入門編】HTTP/1.1ステータスコード5xx(Server Error)の発生原因とインフラ側の対応 – HTTPプロトコル・通信規格実践ガイド

「サーバーが応答してくれない！」HTTP 5xxエラーを、郵便局のトラブルに例えてスッキリ理解しよう

Webサイトを運営していると、避けて通れないのが「5xxエラー」というやつです。「500」「502」「503」「504」……。これらはすべて、サーバー側で発生した「何らかのトラブル」を意味しています。

ブラウザの画面にこれらの数字が表示されたとき、多くの初心者は「自分のPCが壊れたのかな？」と不安になりますが、実は違います。これらは「あなたの出した手紙（リクエスト）は届いたけれど、受け取った相手（サーバー）がパンクしたり、お休みしていたりして返事が書けない状態」なのです。

今日は、ロードバランサーやバックエンドサーバーという「裏方の舞台裏」を覗きながら、これらのエラーがなぜ起きるのか、どう対処すべきか、身近な例えで紐解いていきましょう。

—

5xxエラーは「サーバー側の叫び声」

HTTPのステータスコードにおいて、500番台は「サーバーエラー」です。これは、クライアント（あなたのブラウザ）には一切の非がないことを示しています。

ロードバランサーを「郵便局の受付カウンター」だと想像してください。バックエンドサーバーは、奥で手紙の内容を確認して返事を書く「職員」たちです。このチームワークが崩れると、エラーが発生します。

1. 500 Internal Server Error：職員が「パニック」を起こしている

これは「サーバー内部で予期せぬエラーが起きた」状態です。

例えるなら： 郵便局の職員が、受け取った手紙を読もうとしたら、コーヒーをこぼして書類を台無しにし、「すみません、分かりません！」と混乱している状態。
現場の視点： プログラムのバグや、データベースへの接続ミスなどが原因です。インフラ側では、サーバーのログ（エラーログ）を真っ先に確認するのが鉄則です。

2. 502 Bad Gateway：窓口と奥の職員の「連携ミス」

ロードバランサー（窓口）が、バックエンドサーバー（奥の職員）に手紙を回したのに、奥から「意味不明な返事」が返ってきたときに起こります。

例えるなら： 窓口が「これ処理して！」と書類を渡したのに、奥の職員が「何語で書かれているか分かりません」と突き返してきたような状態。
現場の視点： バックエンドのプロセスが死んでいたり、設定ファイルの記述ミスで通信プロトコルが食い違っているときによく発生します。

3. 503 Service Unavailable：サーバーが「お休み中」

これは「一時的に処理できない」という状態です。

例えるなら： 郵便局の職員が、あまりの忙しさに休憩に入ってしまったか、メンテナンス中で窓口を閉めている状態。
現場の視点： 単純な過負荷（アクセス集中）や、デプロイ（更新作業）による一時的な停止が原因です。インフラ的には「今は忙しいから、少し経ってからまた来てね（Retry-After）」というメッセージを添えるのが優しさです。

4. 504 Gateway Timeout：返事が「待ちきれない」

ロードバランサーがバックエンドに仕事を頼んだけど、あまりに時間がかかりすぎて「待つのをやめた」状態です。

例えるなら： 窓口が「返事はまだか？」と奥の職員に聞いたのに、30秒経っても返事がないので「もう待てません！」と諦めた状態。
現場の視点： データベースのクエリが重すぎたり、外部APIのレスポンスが遅延しているときに起きます。

—

インフラエンジニアはどう向き合うべきか？

エラーが発生した際、闇雲にサーバーを再起動するだけでは根本解決になりません。まずは「どこで止まっているか」を切り分けることが大切です。

ロードバランサー（Nginx等）での設定例

ロードバランサーの設定を確認する際は、タイムアウト設定が適切かどうかが鍵になります。

Nginxの設定例（ロードバランサーとして動作する場合）
upstream backend_servers {
server 10.0.0.1; # バックエンドサーバー1
server 10.0.0.2; # バックエンドサーバー2
}

server {
location / {
proxy_pass http://backend_servers;

# 504 Gateway Timeoutを防ぐためのタイムアウト設定
proxy_connect_timeout 60s; # 接続を待つ時間
proxy_read_timeout 60s; # サーバーからの返事を待つ時間

# 502 Bad Gateway対策：バックエンドが死んでいたら別サーバーへ振る
proxy_next_upstream error timeout http_502;
}
}

まとめ：落ち着いて「ログ」を見ることから始めよう

5xxエラーが出たとき、初心者が一番やってはいけないのは「なんとなく設定ファイルを書き換えてみる」ことです。まずは以下の手順を意識してみてください。

1. 「いつ」発生したか： 特定の時間帯か？
2. 「どこで」止まったか： ロードバランサーのログを見るか、バックエンドのアプリケーションログを見るか。
3. 「何が」起きているか： ログにあるエラーメッセージ（例：`Connection refused`なのか`Timeout`なのか）を読み解く。

ネットワークは複雑ですが、本質は「手紙のやり取り」と同じです。一つずつ紐解いていけば、必ず解決の糸口は見つかります。焦らず、一歩ずつ進んでいきましょう！