「なぜ今、408が返るのか？」― 現場エンジニアが知るべきRequest Timeoutの深淵
Web APIの開発やインフラ運用に従事していると、ログの中にふと混ざる「408 Request Timeout」。多くのエンジニアは「クライアントが何か遅かったのかな？」とスルーしがちですが、このステータスコードは、実はTCPのハンドシェイクからアプリケーション層の処理に至るまで、ネットワークの深層心理を読み解くための重要なサインです。
今日は、HTTP/1.1の仕様に基づき、この「沈黙のタイムアウト」がなぜ起こるのか、そして現場でどう立ち回るべきかを紐解いていきましょう。
—
1. 408 Request Timeoutの正体：RFCが語る「待機」の限界
RFC 7231における定義を紐解くと、408は「サーバーがリクエストを待機している間に、クライアントがリクエストを完了させなかった」ことを指します。
重要なのは、これが「サーバー側の能動的な切断」であるという点です。サーバーは、コネクションを確立した後、クライアントからデータ（HTTPリクエストヘッダやボディ）が送られてくるのをじっと待っています。しかし、あらかじめ設定された時間内にデータが届かない（あるいは断片的にしか届かない）場合、サーバーは「これ以上リソースを無駄にできない」と判断し、コネクションを強制終了させます。
これが、単なるタイムアウトではなく「408」という明確なレスポンスとして返ってくる背景です。
—
2. 通信フロー：パケットの視点から見る「切断の瞬間」
この挙動をシーケンスとして見ると、以下のようになります。
1. TCP Handshake: クライアントとサーバーでコネクション確立。
2. Idle State: サーバーが `Keep-Alive` などの設定に基づき、リクエストを待機。
3. Timeout Expiration: サーバーのタイマーが発火。
4. 408 Response: サーバーが `408 Request Timeout` を投げ、`Connection: close` ヘッダを付与。
5. Fin/Rst: サーバーからTCP切断処理（FINパケット）が送出。
ここで注意すべきは、「クライアントがリクエストの送信を開始したにもかかわらず、途中で詰まった」場合と、「コネクションを張ったまま何も送ってこなかった」場合の両方が含まれる点です。
—
3. 実践：408を再現し、挙動を観察する
エンジニアたるもの、座学だけでなく「手で触って」挙動を確認するのが一番です。例えば、Pythonの`http.server`やNginxの挙動を模倣して、あえて低速なクライアントをシミュレートしてみましょう。
curlで再現を試みる（意図的な遅延）
以下のコマンドは、あえてデータを断片的に送り、サーバーを焦らせる例です。
1秒ごとに少しずつヘッダを送る（サーバーのタイムアウト設定を潜り抜ける実験）
{
echo -ne “GET / HTTP/1.1\r\n”
sleep 5 # サーバーのタイムアウト設定より長く待つ
echo -ne “Host: localhost\r\n\r\n”
} | nc localhost 8080
Nginx側のタイムアウト設定（実務の現場）
Nginx運用において、このタイムアウトを制御するのは `client_body_timeout` と `client_header_timeout` です。
http {
# クライアントがリクエストヘッダを送るのを待つ最大時間
client_header_timeout 10s;
# クライアントがリクエストボディを送るのを待つ最大時間
# これを超えると 408 が返却されるケースが多い
client_body_timeout 10s;
}
—
4. 現場でのトラブルシューティングTips
408が多発している場合、以下の順序で原因を切り分けます。
1. クライアントのネットワーク環境:
モバイル端末などで、トンネル内や不安定なWi-Fi環境から接続していませんか？ 途中のルータがパケットをドロップし、サーバーへの到達が遅れている可能性があります。
2. サーバーの負荷:
サーバーのCPU負荷が高く、`accept`した後の処理（受信待ち）にまでリソースが割けていない場合、擬似的にタイムアウトが早まることがあります。
3. Keep-Aliveのミスマッチ:
ロードバランサー(LB)とバックエンドサーバー間で、Keep-Aliveのタイムアウト設定に乖離はありませんか？ LBが「まだ生きている」と思っているコネクションをバックエンドが既に切断している場合、頻繁に408や502が発生します。
—
結論：408は「異常」ではなく「警告」である
408 Request Timeoutは、システムが健全に動作しているからこそ出力される「境界線」です。これを単なるエラーと捉えず、「クライアントのUXがどこで損なわれているか」、あるいは「サーバーのリソース管理が適切なチューニング範囲にあるか」を測る指標として活用してください。
もしログに408が溢れ出したら、まずはクライアントの通信品質を疑い、次にLBからバックエンドまでのタイマー設定を横並びで比較する。この基本動作を徹底するだけで、あなたのインフラ運用スキルは一段上のレベルへ到達するはずです。
ネットワークは生き物です。その呼吸（タイムアウトの挙動）を理解し、適切にチューニングしてやることで、システムはより強固なものになります。さあ、次はあなたのサーバーのログを見てみましょう。そこに、改善のヒントが眠っているはずです。
コメント