プロンプトとコンテキスト
HTTP/2 のコネクション再利用を使用しているクライアントが、複数の HTTPS ドメインを呼び出す際に断続的に 421 Misdirected Request を受信しています。このレスポンスの意味、プロトコルルーティングとアプリケーションエラーの切り分け方、SNI、authority、プロキシチェーンの調査方法、および安全にリトライする方法を説明してください。
面接官が評価するポイント
- 421 を、現在のパスにおいてサーバーが要求された scheme および authority を処理できない状態として理解しているか。
- TLS SNI、証明書、HTTP/2 コネクション再利用、リバースプロキシルーティングを関連付けて捉えられているか。
- クライアント、エッジ、プロキシ、オリジンにわたってリクエストを追跡できるか。
- 副作用を重複させることなく、新しいコネクションでリトライできるか。
回答前に確認すべき明確化のための質問
- 421 は HTTP/1.1、HTTP/2、HTTP/3 のいずれで発生しており、再利用されたコネクションでのみ発生していますか？
- scheme、authority、Host、SNI、証明書の SAN は一致していますか？
- DNS、ロードバランサー、CDN、またはサービスメッシュが複数のドメインを単一のコネクションに送信していませんか？
- プロキシが Host、authority、または TLS 終端の詳細を書き換えていませんか？
- リクエストは冪等（idempotent）であり、冪等性キーによって保護され、リトライ期限内ですか？
30秒の回答フレームワーク
421 は、通常のビジネスバリデーションが失敗したのではなく、リクエストが誤ったコネクションまたはノードに送信されたとサーバーが判断したことを意味します。authority、SNI、証明書、コネクション ID、プロキシホップを記録し、成功パスと失敗パスを比較します。再利用やルーティングの不一致が確認された場合、クライアントは新しいコネクションでリトライできますが、自動で行うのは冪等なリクエストまたは冪等性キー付きのリクエストのみとし、上限を設定します。解決策は通常、無暗にリトライを繰り返すことではなく、コネクションプールのグループ化、SNI/Host の保持、またはプロキシルーティングの修正です。
ステップバイステップの詳細解説
ステップ 1: 421 の境界を定義する
RFC 9110 は、オリジンがリクエストの宛先が誤っていると判断し、URI の scheme と authority の組み合わせに対するレスポンスを生成できない場合に 421 と定義しています。これはリソースの不在、権限拒否、ビジネスバリデーションエラーとは異なります。
ステップ 2: ターゲット ID を検証する
URL scheme、authority、Host、SNI、証明書の SAN、ALPN、コネクション再利用マーカーを取得します。HTTPS リクエストには、ターゲットオリジンをカバーする証明書と TLS ID が必要であり、DNS 解決だけでは不十分です。
ステップ 3: プーリングと再利用を検査する
HTTP/2 は単一のコネクションで多数のリクエストを伝送できますが、サーバーはすでに確立されたコネクション上の authority を拒否する場合があります。プールがプロキシ、TLS パラメータ、authority ごとにグループ化されているか、古いコネクションが誤って再利用されていないかを確認します。
ステップ 4: プロキシチェーンを追跡する
CDN、ゲートウェイ、サービスメッシュ、オリジンで、リクエスト ID、authority、SNI、選択されたアップストリーム、ステータスを記録します。成功したリクエストと 421 リクエストが通過したノードを比較し、Host の書き換え、SNI の欠落、または誤ったルーティングを特定します。
ステップ 5: 新しいコネクションでリトライする
仕様上、クライアントは 421 を別のコネクションでリトライすることが許可されています。新しいコネクションでは、DNS、TLS、ALPN、authority バインディングをやり直す必要があり、古いコネクションで同じリクエストを再送するだけでは不十分です。まずメソッドの冪等性、再生可能なリクエストボディ、期限を確認します。
ステップ 6: サーバーサイドのルーティングを修正する
エッジとオリジンで scheme、authority、SNI、証明書の設定を一致させ、転送中に必要なフィールドを保持します。ワイルドカード証明書または共有証明書の場合、どのドメインがコネクションを共有でき、どのドメインを分離する必要があるかを明示的に決定します。
ステップ 7: 可観測性と回帰テストを追加する
authority、コネクション ID、プロトコル、ノード、証明書のバージョンごとに 421 を計測します。複数ドメインの HTTP/2 負荷テスト、再利用の切り替え、フォールトインジェクションを使用して修正を検証し、新しいコネクションでのリトライによって永続的なルーティングの欠陥が隠蔽されないようにします。
高品質な回答サンプル
まず、421 が再利用された HTTP/2 コネクションでのみ発生しているかを確認します。ログで scheme、authority、Host、SNI、証明書の SAN、ALPN、コネクション ID、プロキシのアップストリームを取得します。失敗した api.example.com へのリクエストが static.example.com 専用に設定されたコネクションで再利用されていた場合、それは 421 の挙動と一致します。クライアントは、GET または冪等性キー付きのリクエストについてのみ、新しいコネクションで 1 回リトライします。書き込みリクエストは確認のためにビジネス層に渡します。サーバー側では、CDN、ゲートウェイ、オリジンが authority と SNI を保持していることを確認し、ドメインごとにプールをグループ化します。その後、ドメインとノードごとに 421 を計測し、複数ドメインの再利用テストで修正を検証します。
よくある間違い
- 421 を 404、401、または通常の 400 として扱い、ビジネスパラメータを変更してしまう。
- DNS を確認する一方で、SNI、証明書の SAN、authority、プロキシの転送を確認しない。
- 421 の後、同一コネクション上で無制限にリトライを繰り返す。
- 冪等性保護なしに、副作用のある POST を自動的に再送してしまう。
- クライアントの最終エラーのみを保持し、ホップごとのコネクションやルーティングの証跡を失ってしまう。
フォローアップ質問と回答
フォローアップ 1: 421 と 400 の決定的な違いは何ですか？
400 は通常、無効なリクエスト構文やメッセージフレーミングのエラーを示します。421 はターゲットと現在のサーバーまたはコネクションの間の不一致、特にルーティング、authority、または TLS ID の不一致を示します。
フォローアップ 2: なぜ HTTP/2 でこの問題が頻繁に表面化するのですか？
HTTP/2 は多重化と共有コネクションをサポートしているため、クライアントは単一の TLS コネクションを介して複数の authority を送信できます。その組み合わせを拒否するサーバーが 421 を返します。
フォローアップ 3: IP アドレスを変更すれば解決しますか？
必ずしもそうとは限りません。プーリング、SNI、またはプロキシの書き換えに問題がある場合、IP を変えても発生確率が変わるだけです。まず新しいコネクションの TLS ID と完全なルートを検証してください。
フォローアップ 4: POST はいつリトライできますか？
API に冪等性キー、サーバー側の重複排除、または明示的なリプレイ契約があり、かつリクエストボディが期限内に利用可能な場合に限られます。
フォローアップ 5: コネクション再利用が根本原因であることをどのように証明しますか？
再利用の有効/無効の比較、コネクション ID、authority シーケンス、失敗したノードを比較します。新規コネクションの成功と再現可能な再利用の失敗を組み合わせることで、より強力な証拠が得られます。
フォローアップ 6: 本番環境では何をアラート監視すべきですか？
authority、プロトコル、エッジノード、証明書のバージョンごとに、421 の発生率、リトライ成功率、新規コネクション作成数を監視します。急増した場合は、ルーティングや証明書のドリフトを示唆していることがよくあります。