HTTP 504 Gateway Timeout とクライアント側タイムアウトの違い

クライアントは60秒待つ用意がある。それから10秒後に HTTP 504 が返ってくる。クライアントのタイムアウトを2分に延ばしても、ゲートウェイに50秒の余裕が生まれるわけではない。

504 は、リクエストを完了しようとした際に上流から適時の応答を得られなかったゲートウェイまたはプロキシを表す。ゲートウェイはすでに判断を下し、応答を返している。クライアントはその応答を問題なく読める。

どの仲介者が返したのか

発行者はフォワードプロキシかもしれない。サイトが運用する後段のゲートウェイかもしれない。CONNECT 内部の通常のエンドツーエンド TLS では、その保護された宛先とのやり取りから返る HTTP 応答は、CONNECT 自体の拒否とは同じではない。

段階、応答ヘッダー、エラーページの文言、そして入手できる場合は対応するログを残す。サーバー名は手がかりにはなるが、誤りのない帰属として扱うべきではない。経路にはクライアントに設定したものより多くの仲介者が含まれうる。

次に、その上流の処理がなぜ完了しなかったのかを調べる。到達性、過負荷のサービス、上流が想定どおりに処理できないリクエスト本文、アプリケーションの挙動のいずれも関係しうる。数値のステータスだけでは、User-Agent の変更やタイムアウト設定を一つ足すことが万能の解決策だとは証明できない。

同じリクエストを比較する

別のツールで成功するなら、メソッド、対象、本文のエンコーディング、認証、経路を比較する。「ブラウザーで URL が開く」は、サービス用クライアントからの multipart 送信との完全な比較にはならない。

発行するゲートウェイを運用しているなら、その上流の予算をサポート対象の負荷と周辺の期限に合わせる。運用していないなら、その結果を証拠として残し、運用者が文書化したアクセス経路やサポート経路を使う。手元で長く待っても、すでに届いた応答は変わらない。