【実務・中級編】HTTPステータスコード5xx(Server Error)の発生原因とリカバリ – HTTPプロトコル・通信規格実践ガイド

サーバーが「沈黙」するとき：5xxエラーと向き合うエンジニアの矜持

Webエンジニアとしてキャリアを積んでいると、必ず一度は遭遇する壁がある。それがHTTP 5xx系ステータスコードだ。

クライアント（ブラウザやアプリ）のミスを指す4xx系とは異なり、5xxは「サーバー側の責任」である。つまり、我々インフラエンジニアやバックエンドエンジニアが守り切るべき領域で発生している問題だ。今回は、単なる仕様の解説ではなく、夜中のアラートに叩き起こされた際、いかに冷静に、かつスマートにリカバリを打つかという「現場の流儀」を紐解いていく。

—

1. 5xxエラーの「解剖」：何が起きているのか

HTTPステータスコードは、サーバーからの「叫び」だ。5xx系は、サーバーがリクエストを理解したにもかかわらず、自身の内部的な理由で完遂できなかったことを示唆している。

500 Internal Server Error: 「何かが壊れた」。原因不明の汎用的なエラー。アプリケーションのクラッシュや、DB接続のタイムアウトが主犯だ。
502 Bad Gateway: 「上流が死んでいる」。リバースプロキシ（Nginxなど）が、後段のアプリサーバー（Gunicorn, Node.js等）から不正なレスポンスを受け取った状態。
503 Service Unavailable: 「今は無理」。サーバーの過負荷、あるいはメンテナンス中。
504 Gateway Timeout: 「待ちくたびれた」。上流サーバーからのレスポンスを待ったが、タイムアウト時間を超過した。

これらは単なる数字ではない。パケットがどこで途絶えたのか、どのレイヤーで息絶えたのかを判断するための重要なシグナルなのだ。

—

2. 実務で使えるリトライ戦略：ただ叩けば良いわけではない

5xxが発生したとき、クライアント側で漫然とリトライを繰り返すのは「DDos攻撃」を自ら仕掛けているのと同義だ。特に503（過負荷）のときにそれをやると、サーバーはトドメを刺される。

ここで重要になるのが「エクスポネンシャル・バックオフ（指数バックオフ）」と「ジッター（揺らぎ）」の組み合わせだ。

Pythonでの実装例（requestsライブラリを使用）

単なるループではなく、負荷を分散させつつ再試行する実装がこちらだ。

import time
import random
import requests

def fetch_with_retry(url, max_retries=3):
for i in range(max_retries):
try:
response = requests.get(url, timeout=5)
# 5xx系なら例外を発生させてリトライへ
response.raise_for_status()
return response.json()
except requests.exceptions.HTTPError as e:
status_code = e.response.status_code
if 500 <= status_code < 600: # 指数バックオフ: 2^i 秒待機 + 0~1秒のランダムなジッター wait = (2 i) + random.random() print(f"Error {status_code}. Retrying in {wait:.2f} seconds...") time.sleep(wait) else: raise raise Exception("Max retries exceeded") このコードの肝は `random.random()` だ。もし全世界のクライアントが一斉に「2秒後」にリトライしたら、サーバーは再びパンクする。この「微小なズレ」が、大規模システムにおける雪崩（Thundering Herd）を防ぐ鍵となる。 ---

3. インフラサイドの防波堤：Nginxのログと設定

502や504が頻発する場合、アプリではなくNginxの設定を疑う必要がある。特に、アップストリーム（アプリサーバー）との接続タイムアウト設定は、現場で頻繁に調整するポイントだ。

upstream backend_app {
server 127.0.0.1:8000;
keepalive 32; # コネクションを再利用し、ハンドシェイクのオーバーヘッドを減らす
}

server {
location / {
proxy_pass http://backend_app;
# タイムアウトを適切に設定し、無駄な待機時間を減らす
proxy_connect_timeout 5s;
proxy_read_timeout 10s;
proxy_send_timeout 10s;
}
}

ここで重要なのは `proxy_read_timeout` だ。これが短すぎれば504を量産し、長すぎればコネクションプールが枯渇する。システムの特性（APIなのか、画像配信なのか）に合わせてチューニングすることが、シニアエンジニアの腕の見せ所だ。

—

4. トラブルシューティングの鉄則

最後に、現場で5xxに遭遇した際の手順を記しておく。

1. ログの相関を見る: Nginxのアクセスログ（`404`か`5xx`か）と、アプリケーション側のエラーログを突き合わせる。時刻がずれているなら、NTPの設定を確認せよ。
2. リソース枯渇の確認: `top` や `free -m` でCPU/メモリを確認する。特にメモリ不足によるOOM Killerは、アプリケーションを前触れもなく殺す。
3. 疎通確認: `curl -v` を使って、プロキシを通さない直接アクセスを試みる。これでエラーが消えるなら、原因はプロキシ設定だ。

curlでレスポンスヘッダーを確認し、エラーの原因を探る
curl -Iv http://your-api-server.com/endpoint

最後に

ネットワークは生き物だ。完璧な設計など存在しない。エラーが発生したときこそ、そのシステムがどういう挙動をするように設計されているか、という「哲学」が試される。

もし君が今、5xxのログと格闘しているなら、焦らずにパケットの行方を追ってほしい。サーバーは必ず、何らかのヒントをログの海に残しているはずだ。健闘を祈る。