HTTP 421 Misdirected Requestとは？接続先と要求先が食い違う理由

この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。HTTP 421の意味とHTTP/2の接続再利用について、RFC 9110とRFC 9113の一次仕様をもとに整理しました。

検証ステータス：📘 公式仕様確認済み・実通信未実施

「421 Misdirected Request」が出たとき、404のようにページがないのか、503のようにサーバーが停止したのかと考えがちです。しかし421は、要求を受けたサーバーが、その要求先に対して適切な応答を生成できない、または応答するよう設定されていないことを示すステータスです。HTTP/2の接続再利用、TLS、CDN、リバースプロキシ、仮想ホストを調べる手掛かりになります。

421は何を意味する？

RFC 9110 §15.5.20では、421は受信したサーバーが要求のターゲットURIに対して権威ある応答を生成できない、または生成するよう構成されていないことを表します。ここでいう「権威」はDNSの権威サーバーとは別で、そのWeb要求先を適切に処理できるかという意味です。421はHTTP/2でよく議論されますが、HTTP/2専用のステータスではありません。

まず操作：開発者ツールで421を調べる

自分が管理するサイト、または検査を許可されたサイトを対象にします。

1. ブラウザーの開発者ツールから「Network」を開きます。

2. 対象ページを再読み込みし、421になった要求のURL、ステータス、プロトコル（表示される場合）を記録します。

3. どのホスト名への要求が失敗したか、リダイレクトでホスト名が変化したかを調べます。

4. CDN・リバースプロキシ・Webサーバーのログを発生時刻や安全なリクエスト識別子で照合します。

期待結果： 421になった要求ホストと、その通信を受け取ったサーバー側の経路を絞り込めます。再現しなければ「再現なし」と記録してください。Cookie、認証ヘッダー、署名付きURLを公開ログや問い合わせ文に貼り付けないでください。

curlでHTTPバージョンを比較する

以下は読者が管理するURLに置き換えて試すための例です。執筆時に実行成功を確認したコマンドではありません。

curl --version
curl --http1.1 --head --show-error https://your-owned.example/
curl --http2 --head --show-error https://your-owned.example/

curlのHTTP/2対応は最初のバージョン情報で確認します。HEADはGETと同じ本文を受信しないため、HEADが正常でもGETの問題がないとは断定できません。ブラウザーのNetworkで実際のGETを併せて確認してください。

「HTTP/2だけ421」「両方421」「どちらも正常」という比較は原因調査のヒントですが、curlを別々に起動するだけではブラウザーの複数オリジン間の接続再利用を再現したことにはなりません。結果だけでTLS証明書やCDNの不具合と断定しないことが重要です。

仕組み：接続先と要求先のオリジン

HTTPSでは、TLS接続時のSNIとHTTP要求のターゲットオリジン（HTTP/2の:authorityなど）が関係します。HTTP/2では条件を満たす場合に既存接続を別オリジンへの要求にも再利用できます。しかし証明書が複数ホスト名に有効であることと、接続先サーバーが全ホストの内容を配信できることは別です。

概念的な架空例です。

1. クライアントがホストAへTLS接続を確立する。

2. 再利用可能と判断し、同じ接続でホストB向けの要求を送る。

3. 受信したサーバーはホストBを扱えず421を返す。

4. クライアントは別の接続で再試行できる場合がある。

この流れはRFCの説明であり、特定のブラウザー・CDNで実測した結果ではありません。

一つ条件を変える：HTTP/1.1なら正常？

HTTP/1.1で正常、HTTP/2で421という差があれば、接続再利用やオリジンの扱いを調査候補にできます。ただし、プロトコルの変更で経路や中継装置の挙動が変わることもあります。HTTP/2を本番で無効化する前に、検証環境で要求ホスト、接続先、ログを比較します。

HTTP/1.1でも421なら、HTTP/2固有の仕組みだけに原因を限定せず、Host、SNI、仮想ホスト、CDNのオリジン設定を確認してください。

うまくいかない場合の切り分け

RFC 9110は421への別接続での再試行を認めています。ただし、利用者や運用スクリプトが副作用のある要求を無制限に再送してよいわけではありません。実際の再試行条件はクライアント実装とHTTPの規則を確認してください。

運用上の安全策

変更前に、対象ホスト、TLS証明書の対象名、SNI、Host/:authority、リバースプロキシの仮想ホスト、CDN転送先を照合し、設定のバックアップとロールバック手順を用意します。421を隠すために証明書検証を無効化したり、すべてのホストを無条件に受け入れたりしないでください。

図解：ホストAの接続でホストBを要求すると何が起こる？

宛先Bの荷物を、宛先Aしか扱わない窓口へ渡した場面を想像してください。421の本質は、「目的地が存在しない」のではなく、その要求を受け取った接続先が、指定された要求先を処理できないという点です。HTTP/2では一定の条件下で接続を複数のオリジンへ再利用できるため、この問題が現れることがあります。

次の図は架空の通信であり、特定のブラウザやCDNで観測したログではありません。実際に接続を再利用できる条件、421を生成する箇所、再試行が行われるかどうかは環境に依存します。

sequenceDiagram
    participant B as ブラウザ
    participant A as ホストAを扱う接続先
    participant H as ホストBを扱う接続先
    B->>A: ホストA向けに接続を確立
    A-->>B: 応答を返せる
    B->>A: 同じ接続でホストB宛ての要求
    A-->>B: 421 要求先Bは扱えない
    B->>H: 条件を確認して別接続で再試行
    H-->>B: 構成が正しければ応答する場合がある

ここで見分けたいのは、「TLSの接続が成立した」という事実と、「HTTPで要求されたサイトの内容を正しく配信できる」という事実の違いです。複数のホスト名に有効な証明書を持っていても、受信先の仮想ホスト設定やCDNの転送条件がすべての要求先を扱えるとは限りません。証明書だけを確認して問題なしとするのは早計です。

SNI・Host・:authorityを層で分ける

421を調べていると、SNI、Host、:authorityなど似た言葉が出てきます。SNIはTLS接続時に伝えるサーバー名に関わる情報です。HTTP/1.1のHostとHTTP/2の:authorityは要求先を示す情報です。これらをすべて「接続先のホスト名」という一語で済ませてしまうと、どこで食い違ったのか追えません。

特にCDNを利用している場合、ブラウザからCDNまでとCDNからオリジンサーバーまでで、TLS接続や送られるホスト情報が別々に扱われることがあります。421が返ったという結果だけでは、どの区間が原因か断定できません。ブラウザのNetwork、CDN側の記録、オリジンサーバーのログを時刻や安全な識別子で照合して、発生箇所を絞ります。

flowchart TD
    A["421の要求をNetworkで特定"] --> B["URL・時刻・HTTPバージョンを記録"]
    B --> C{"複数ホスト間の通信か"}
    C -->|"はい"| D["接続の再利用と受信先を調べる"]
    C -->|"不明・いいえ"| E["要求先Hostと仮想ホストを照合"]
    D --> F["TLS・SNI・CDN転送経路を比較"]
    E --> F
    F --> G["検証環境で条件を一つだけ変更"]
    G --> H["同条件で再現・改善を確認"]

この図はトラブルシューティングの順番を示したものです。図中のいずれかの確認が一致したからといって、その項目が必ず根本原因とは限りません。調査時にやりがちなのは、421を見た瞬間にHTTP/2を停止したり、証明書を交換したりすることです。これらは別の利用者の通信にも影響するため、まず読取可能なログと小さな比較から始めます。

具体的な障害場面：画像だけが421になる

架空のサイトAが画像を別ホストBから読み込む構成を考えます。ページAは表示できるのに画像だけが421となり、画像URLを単独で開くと正常に見える場合があります。この違いは画像データが壊れている証拠ではありません。ページの一部として画像を要求するときと、URLを直接開くときでは、ブラウザが選ぶ既存の接続や経路が違う可能性があるからです。

まず画像の要求URL、失敗したときのステータス、HTTPバージョン、発生日時を記録します。次に同じ操作を再試行し、成功した場合もそのときの条件を残します。再試行で成功しても「修理が終わった」とは言えません。別の接続が選ばれただけで、同じ条件を再現すると再び421になる可能性があります。

curlでHTTP/1.1とHTTP/2を比較するときも注意が必要です。別々にcurlを起動した結果は、ブラウザの複数オリジン間での接続再利用をそのまま再現したものではありません。「HTTP/2だけ421なら接続再利用が原因だ」と即断せず、追加確認が必要な仮説として扱います。HEADとGETの違いも混同しないようにします。

仕事で使うなら、修正前後の比較条件をそろえる

Web運用担当者が調査結果を引き継ぐなら、「421が出た」という報告だけでは不十分です。要求URL、発生時刻、接続方式、影響したホスト、正常だった比較条件、実施していない検証を一緒に残します。CookieやAuthorization、署名付きURLなどの秘密情報は共有前に除き、アクセスログの個人情報も取り扱いに注意します。

原因が分かって設定を変更する場合でも、対象のホストを明確にし、変更前の設定と戻し方を保存します。修正後は同じブラウザ操作、同じHTTPバージョン、同じ複数ホストの組み合わせで確認します。再起動や一時的な再試行成功だけで作業を完了にせず、実際に利用者のページが正常に表示されるかを見ることが重要です。

まとめ

421は「ページが存在しない」ではなく、受信したサーバーと要求先オリジンの不一致を疑う手掛かりです。HTTP/2の接続再利用は代表例ですが、421だけで原因は確定しません。要求URL、プロトコル、ホスト、TLS・中継経路を並べて調べることが、再現性のある切り分けにつながります。

公式一次資料

• RFC 9110 §15.5.20 — 421 Misdirected Request

• RFC 9113 §9.1 — HTTP/2 Connection Management

• curl公式マニュアル

未実施： 421の実通信再現、curl・ブラウザー・CDN・Webサーバー実機検証、WordPress表示確認。