HTTP 408 Request Timeout：意味と解決方法

このエラーの意味と見分け方

• ブラウザ、API クライアント、アップロードツール、合成監視、ヘルスチェックが 408 Request Timeout を受信します。
• エラーはサイト全体ではなく、特定の URL、HTTP メソッド、クライアント、アップロード、ネットワーク経路でのみ発生する場合があります。
• アップロードやフォーム送信など、ボディを送信するリクエストでは、接続が開いたまま完了せず、失敗することがあります。
• レスポンスヘッダーから、プロキシ、CDN、ロードバランサー、WAF、オリジンサーバーのどれがレスポンスを生成したか分かる場合があります。
• その後の HTTP リクエストが 408 を受信した場合でも、DNS 解決と TLS ネゴシエーションは成功することがあります。
• ログには、不完全なリクエスト、アイドル状態の接続、リクエスト読み取りタイムアウト、またはリクエストがアプリケーションに到達する前に生成されたタイムアウトが記録される場合があります。

可能性の高い順の主な原因

1. クライアントがリクエストの送信を完了しなかった。 低速なアップロード、停止した接続、中断されたブラウザリクエスト、不完全なリクエストボディなどにより、サーバーの待機時間を超えることがあります。
2. アイドル状態の永続接続が期限切れになった。 次のリクエストが設定されたアイドル時間内に到着または完了しない場合、サーバーや中間機器が keep-alive 接続を閉じることがあります。
3. プロキシ、CDN、ロードバランサー、WAF が先にタイムアウトした。 各層で、リクエストヘッダー、リクエストボディ、接続のアイドル時間、合計処理時間に異なる制限が設定されている場合があります。
4. ネットワークの不安定さによってリクエストの配送が遅れた。 パケットロス、接続の切断、問題のある経路によって、エンドポイントが完全なリクエストを受信できないことがあります。
5. リクエストの詳細が、特定の層のルールに該当した。 大きなボディ、特殊なヘッダー、サポートされていない転送パターン、メソッド固有のポリシーなどにより、中間機器が待機を停止したり、リクエスト経路を拒否したりすることがあります。
6. レスポンスが誤分類された、またはカスタムインフラによって生成された。 標準的なクライアントリクエストのシナリオとは異なるタイムアウト条件に対して 408 を使用するシステムもあります。そのため、生成元のコンポーネントとそのログを確認する必要があります。

修正方法

サイトを閲覧している場合

1. アドレスが正しいことを確認してから、正確な URL に対して一度だけ再試行します。
2. ファイルのアップロードやフォームの送信中だった場合は、接続が安定していたか、処理を安全に再開できるかを確認します。
3. アカウントが必要なリクエストの場合は、サイトの通常の手順でサインインしてから再試行します。最初のリクエストが完了したか確認せずに、フォームや支払いリクエストを繰り返し再送しないでください。
4. エラーが続く場合は、URL、分かる範囲での HTTP メソッド、おおよその時刻、ネットワークの種類、表示された 408 レスポンスを記録します。パスワード、Cookie、決済データ、API キーを共有せずに、その情報をサイト運営者へ送ってください。

サービスを開発・運用している場合

1. 正確なリクエストを記録する。 メソッド、URL パス、リクエストサイズの特性、関連するヘッダー、ボディが送信されたか、レスポンスステータス、レスポンスヘッダー、タイムスタンプを記録します。認証情報、Cookie、Authorization の値、個人データはマスキングしてください。
2. 同じ条件で再現する。 通常のリクエストと、失敗するメソッド、クライアント、アップロードサイズ、接続の種類、リクエストボディの挙動を比較します。単純な GET が成功しても、POST、アップロード、ストリーミングリクエスト、その他のメソッドでタイムアウトしないとは限りません。
3. レスポンスを生成した層を特定する。 レスポンスヘッダーとリクエストまたはトレース ID を確認し、CDN、WAF、ロードバランサー、リバースプロキシ、Web サーバー、アプリケーションの各ログでタイムスタンプを照合します。通常、最初にタイムアウトを記録した層が調査の最適な出発点です。
4. リクエスト読み取りとアイドルタイムアウトの設定を確認する。 不完全なヘッダー、低速なリクエストボディ、keep-alive 接続、リクエスト全体の処理時間に関する、サーバーと中間機器の設定を確認します。アプリケーションが想定するアップロードやクライアントの挙動と比較してください。
5. ネットワーク経路とクライアントの挙動を確認する。 接続リセット、パケットロス、停止したアップロード、プロキシの変更、接続を開いたままリクエストの送信を完了しないクライアントがないか確認します。
6. 最近の変更を比較する。 デプロイ、ルーティング、プロキシ/CDN 設定、WAF ルール、リクエストサイズ制限、認証ミドルウェア、接続処理に関する変更を確認します。ログからリクエストがそのロジックに到達したことが分からない限り、認証や認可は二次的な調査対象として扱います。
7. 権限のある最小限の修正を適用する。 原因となったタイムアウトまたはリクエスト処理ルールだけを調整するか、クライアントの挙動を修正します。容量や悪用への影響を理解せずに、セキュリティ制御を広範囲に無効化したり、すべてのタイムアウトを延長したりしないでください。
8. 再テストして監視する。 元のリクエストを安全に繰り返し、期待するステータスが返ることを確認します。また、関連するルートとメソッドも確認してください。非冪等リクエストの場合は、承認済みのテストケースを使用するか、再試行前に処理結果を確認します。

予防と修正確認

• ルート、メソッド、クライアントの種類、デプロイごとに HTTP ステータスの割合を監視し、リクエスト固有のタイムアウトが集計メトリクスに埋もれないようにします。
• CDN、WAF、ロードバランサー、リバースプロキシ、Web サーバー、アプリケーションのタイムアウト設定を文書化し、可能な場合はバージョン管理します。
• 管理された環境で、低速なアップロード、不完全なリクエスト、keep-alive の挙動、重要な API メソッドをテストします。
• 正当なクライアントの挙動とリソース消費・悪用リスクのバランスを考慮し、リクエストと接続のタイムアウトを意図的に設定します。
• ネットワーク層全体で、同期されたタイムスタンプとリクエストまたはトレース ID を保持します。
• 特にフォーム送信、注文、支払いなどの非冪等リクエストについて、クライアントの再試行動作を明確にします。
• 408 と、それを発生させたコンポーネントを照合できるよう、十分にサニタイズしたログとメトリクスを保持します。

よくある質問