HTTP 505 HTTP Version Not Supported：意味と対処方法

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

• ブラウザ、APIクライアント、監視システム、コマンドラインツールが 505 HTTP Version Not Supported を受け取ります。
• レスポンスには、リクエストされたHTTPバージョンがサポートされていないことを示すメッセージが含まれる場合があります。
• その後クライアントがHTTPレスポンスを受け取っているため、DNSは正常に解決され、TLSも正常に完了する場合があります。
• 特定のクライアント、プロトコルネゴシエーション経路、URL、HTTPメソッド、または中間処理装置でのみエラーが発生する場合があります。
• レスポンスヘッダーから、レスポンスがプロキシ、CDN、ロードバランサー、オリジンサーバーのいずれから返されたかを確認できるほか、キャッシュや接続の詳細が分かる場合があります。

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

1. サポートされていないHTTPプロトコルバージョン: エンドポイントが、リクエストで使用されたHTTPのメジャーバージョンをサポートしていません。これがステータス505の定義上の原因です。
2. 中間処理装置とアップストリーム間のプロトコル不一致: リバースプロキシ、CDN、ロードバランサー、ゲートウェイが、次のサーバーで受け入れられないプロトコルバージョンを使用しているか、独自の505レスポンスを返している可能性があります。
3. HTTPプロトコル設定の誤りまたは不完全な設定: 最近のサーバー、プロキシ、アプリケーションの変更により、リクエスト経路全体でサポートされていないプロトコルバージョンが有効化または必須化された可能性があります。
4. クライアント固有のネゴシエーションまたはリクエスト動作: あるクライアントや監視ツールが、ブラウザや他のクライアントとは異なるHTTPプロトコルを選択し、互換性の問題が表面化する場合があります。
5. オリジン以外の層からの予期しないレスポンス: ステータスは、URLを管理するアプリケーションではなく、ゲートウェイやセキュリティ中間処理装置が生成している可能性があります。オリジンサーバーからのレスポンスと区別するには、ヘッダーとログの確認が必要です。

認証、レート制限、DNS、TLSはリクエストに影響する可能性がありますが、それだけでHTTP 505レスポンスを説明することはできません。レスポンスヘッダーまたはログからプロトコルバージョンの失敗との関連が確認できない限り、これらは別の調査経路として扱ってください。

修正方法

訪問者とAPIユーザー向け

1. 正確なURLを一度だけ再試行し、クライアントが最新で、通常のHTTPリクエストを行う設定になっていることを確認します。
2. APIクライアントや監視ツールで問題が発生する場合は、別のサポート対象クライアントと結果を比較します。失敗がクライアント固有かどうかを記録してください。
3. URL、HTTPメソッド、おおよその発生時刻、レスポンスステータス、レスポンスヘッダーを記録します。パスワード、Cookie、認証トークン、その他の秘密情報は含めないでください。
4. エラーが続く場合は、サニタイズした情報をサイトまたはAPIの所有者に送ります。訪問者がサーバー側のプロトコル互換性問題を修正できることは通常ありません。

開発者とサイト所有者向け

1. 正確なリクエストを取得する: ホスト名、パス、メソッド、リクエストプロトコル、クライアント、タイムスタンプ、最終ステータスを記録します。レスポンスが実際に505であり、リダイレクトや、別の障害の後にクライアントが表示しているステータスではないことを確認します。
2. プロトコルネゴシエーションを確認する: クライアントが使用または使用を試みたHTTPバージョンと、エンドポイント、プロキシ、ロードバランサー、CDNがサポートするバージョンを確認します。暗号化接続では、使用するツールで確認できる場合、ネゴシエートされたアプリケーションプロトコルを確認します。
3. レスポンス層を特定する: レスポンスヘッダー、確認可能な場合はサーバーシグネチャ、リクエストID、アクセスログを使い、505がCDN、WAF、ゲートウェイ、リバースプロキシ、Webサーバー、アプリケーションのどこから返されたかを特定します。
4. ログを照合する: 特定した層とアップストリーム層で、同じタイムスタンプ、ルート、メソッド、クライアント、リクエストIDを検索します。オリジンにログがない場合、中間処理装置が転送前にリクエストを拒否した可能性があります。
5. 最近のプロトコル変更を確認する: HTTPバージョンのサポート、プロキシからオリジンへの接続、ロードバランサーのリスナー、ゲートウェイのルーティング、クライアントまたは監視設定に影響する最近のデプロイと設定変更を確認します。
6. 承認された範囲で最小限の修正を行う: 影響を受けたクライアント、中間処理装置、オリジンを、リクエスト経路全体がサポートするプロトコルバージョンに合わせます。回避策としてTLS検証、認証、セキュリティ制御を無効化しないでください。
7. 同じリクエストを再テストする: 元のURLとメソッドを確認してから、代表的なルートとプロトコル経路をテストします。修正によって無関係なステータスコードやルーティング動作が変わっていないことを確認します。
8. 共有インフラでは段階的に展開する: 多数のサイトやルートに影響する設定の場合、広範囲に適用する前に、承認済みのステージング環境または限定範囲の変更でテストします。環境の変更手順とロールバック手順に従ってください。

予防と修正確認

• 各リクエスト経路において、クライアント、ゲートウェイ、プロキシ、ロードバランサー、オリジンがサポートするHTTPバージョンを文書化します。
• プロトコルまたはインフラストラクチャを変更した後は、実際の本番環境に近いプロキシおよびCDN経路を通して、重要なブラウザ向けルートとAPIメソッドをテストします。
• ルート、クライアント種別、プロトコル、デプロイごとにステータスコードを監視し、クライアント固有の505レスポンスを把握できるようにします。
• プロキシ、ロードバランサー、Webサーバー、アプリケーションの設定を、テスト済みのロールバック手順とともにバージョン管理します。
• 予期しないレスポンスをどの層が生成したか特定できる期間、アクセスログとゲートウェイログを相互に照合できる形で保持します。
• 監視ツールとAPIクライアントを最新の状態に保ち、導入時や設定変更時にプロトコル設定を検証します。

よくある質問