通用面試：HTTP 421 Misdirected Request 如何定位與安全重試？
題干與適用場景
一個啟用 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 終止資訊？
- 請求是否冪等，是否具備冪等鍵與可重試截止時間？
30 秒回答框架
421 表示伺服器認為請求被錯誤導向目前連線或節點，不是普通業務 4xx。先記錄 authority、SNI、憑證、連線 ID 與代理跳轉，比較成功與失敗路徑。若確認是連線複用或路由不匹配，用戶端可在新連線上重試，但只對冪等或有冪等鍵的請求自動執行，並限制次數。修復方向通常在連線池分組、SNI／Host 保留與代理路由，而不是盲目增加重試。
分步驟深入解答
第一步：解釋 421 的邊界
RFC 9110 將 421 定義為 origin server 認為請求被誤導，無法為 URI 中的 scheme 與 authority 組合產生回應。它不同於資源不存在、權限不足或業務驗證失敗。
第二步：核對目標身分
從用戶端記錄提取 URL scheme、authority、Host、SNI、憑證 SAN、ALPN 與連線複用標記。HTTPS 請求必須由涵蓋目標 origin 的憑證與正確 TLS 身分承載，不能只看 DNS 解析結果。
第三步：檢查連線池與複用
HTTP/2 允許一條連線承載多個請求，但伺服器可能不接受把某個 authority 放在已建立連線上。檢查連線池是否按代理、TLS 參數與 authority 正確分組，是否錯誤複用舊連線。
第四步：沿代理鏈定位
在 CDN、閘道、服務網格與源站分別記錄請求 ID、authority、SNI、選中的 upstream 與回應碼。比較成功請求和 421 請求經過的節點，找出 Host 改寫、SNI 遺失或錯誤路由。
第五步：選擇新連線重試
規範允許用戶端收到 421 後在不同連線上重試。新連線必須重新完成 DNS、TLS、ALPN 與 authority 綁定；不能只在原連線上傳送相同請求。重試前還要檢查方法冪等性、請求主體可重放性與截止時間。
第六步：修復伺服器路由
確保邊緣與源站按 scheme、authority、SNI 與憑證設定一致，代理轉發時保留必要欄位。對共享憑證或萬用字元網域，明確哪些網域可共用連線，哪些必須隔離。
第七步：建立觀測與回歸驗證
按 authority、連線 ID、協定版本、節點與憑證版本統計 421 率。用多網域 HTTP/2 壓測、連線複用開關與故障注入驗證修復，確認新連線重試沒有掩蓋持續路由錯誤。
高品質示範回答
我會先確認 421 是否只出現在 HTTP/2 複用連線。日誌同時記錄 URL scheme、authority、Host、SNI、憑證 SAN、ALPN、連線 ID 與代理 upstream；如果失敗請求把 api.example.com 複用到只為 static.example.com 配置的連線，就符合 421 語義。用戶端只對 GET 或帶冪等鍵的請求建立新連線重試一次，寫操作先交給業務層確認。伺服器則檢查 CDN、閘道與源站是否保留 authority 與 SNI，並按網域隔離連線池。最後按網域與節點觀察 421 率，用多網域複用壓測驗證修復。
常見錯誤
- 把 421 當成 404、401 或普通 400，改去修改業務參數。
- 只檢查 DNS，不檢查 SNI、憑證 SAN、authority 與代理轉發。
- 收到 421 後在同一條連線上無限重試。
- 對有副作用的 POST 沒有冪等保障便自動重放。
- 只看最終用戶端錯誤，不保留每一跳的連線與路由證據。
追問及應對
追問一：421 與 400 的關鍵區別是什麼？
400 通常表示請求語法或訊息格式無效；421 指向請求目標與目前伺服器或連線不匹配，重點是路由、authority 與 TLS 身分。
追問二：為什麼 HTTP/2 更容易暴露這個問題？
HTTP/2 支援多路複用與連線共用，用戶端可能在一條 TLS 連線上傳送多個 authority；伺服器若不接受該組合就會回傳 421。
追問三：換 IP 能解決嗎？
不一定。若根因是連線池、SNI 或代理改寫，換 IP 只是改變機率。應先驗證新連線的 TLS 身分與完整路由鏈。
追問四：POST 什麼時候能重試？
只有介面提供冪等鍵、伺服器去重或業務明確允許重放，且請求主體仍可用、未超過截止時間，才自動重試。
追問五：如何證明是連線複用導致？
對比複用開啟與關閉、連線 ID、authority 序列與失敗節點；若新連線成功且複用路徑穩定重現 421，證據更充分。
追問六：生產中應告警什麼？
按 authority、協定、邊緣節點與憑證版本監控 421 比例、重試成功率與新連線建立量；突增通常提示路由或憑證設定漂移。