1. 題目與適用場景
一個多租戶 HTTPS API 透過 HTTP/2 連線重用多個網域。某些請求偶爾收到 421，團隊想在應用控制器中統一改成 503。請判斷 421 的語義，解釋 SNI 與 Host 的關係，並設計閘道、來源站、客戶端和可觀測性方案。假設請求可能經過 CDN、反向代理和服務網格。
2. 面試官考察點
- 是否知道 421 表示請求到達了無法或不願為目標 URI 提供權威回應的來源站。
- 是否能把連線重用、TLS SNI、請求 Host、scheme 與 authority 放進同一條診斷鏈。
- 是否理解代理不能憑自身判斷產生 421，以及客戶端應換連線後再謹慎重試。
- 是否能區分 421、上游故障、404、503 與憑證設定錯誤，避免只改狀態碼。
3. 回答前需要釐清的問題
- 421 是由來源站、閘道、CDN 還是應用直接產生的？
- 請求使用 HTTP/2 或 HTTP/3 嗎？同一條連線是否承載多個 authority？
- TLS 交握中的 SNI、HTTP Host 和最終路由到的虛擬主機分別是什麼？
- 客戶端是否能建立目標網域專用的新連線，方法是否具冪等性，是否已產生副作用？
4. 30 秒回答框架
421 表示來源站認為請求被錯誤導向了目前連線或虛擬主機，例如連線憑證與目標 authority 的組合不適用。先在 TLS、連線池、代理路由和來源站虛擬主機層定位 SNI、Host、scheme 與 authority 的不一致，不要把它改寫成 503。來源站可以返回 421，代理不能憑自身產生它；客戶端可在新連線上重試，但要遵守方法冪等性、請求體重放和退避規則。日誌要關聯連線 ID、SNI、authority、路由和重試結果。
5. 分步驟深入解答
第一步：界定 421 的責任邊界
RFC 9110 將 421 定義為來源站拒絕請求，因為目標 URI 看起來被錯誤導向。它可能是不匹配的來源站設定，也可能是不適合目前連線脈絡的請求。應用層不應把任意上游逾時、DNS 錯誤或憑證過期映射成 421；這些問題要保留各自的錯誤語義。
第二步：重建一次請求的連線脈絡
TLS 交握階段的 SNI 用於選擇憑證和虛擬主機；加密連線建立後，請求攜帶的 Host 或 authority 決定目標。HTTP/2 允許一條連線承載多個請求，但連線只有在憑證、協定和伺服器設定都允許時才能安全重用。診斷時記錄 SNI、Host、scheme、authority、ALPN、連線建立時間和選中的後端，比較「連線屬於誰」和「請求要去哪裡」。
TLS SNI: api-a.example
HTTP authority: api-b.example
ALPN: h2
selected virtual host: api-a.example
result: 421 from origin第三步：處理代理、CDN 與服務網格
邊緣代理應保留原始 authority、TLS 終止資訊和上游連線狀態，並避免把不同租戶錯誤地重用到同一上游連線。代理可以轉發來源站 421，但不能僅因自身認為路由失敗就產生 421；代理應使用自己的 502、503 或路由錯誤契約。服務網格的連線池鍵必須包含會影響憑證和虛擬主機選擇的欄位，而不是只按 IP 和連接埠重用。
第四步：設計客戶端重試
規範允許客戶端在不同連線上重試 421，包括針對目標 origin 的新連線。重試前要判斷方法是否具冪等性、請求體是否可重放、驗證權杖是否仍有效，以及是否已收到部分回應。對 POST 等可能產生副作用的方法，優先使用冪等鍵或讓伺服器確認沒有執行，再決定是否重試。重試只允許有限次數並記錄原因，不能用固定迴圈掩蓋錯誤設定。
第五步：觀測、修復與回歸驗證
指標應按 SNI、authority、虛擬主機、協定版本和邊緣節點統計 421，而不是只看總量。日誌保存去識別化的連線 ID、路由決策、憑證指紋、來源站回應和客戶端是否換連線。修復後用多個網域、同一連線重用和新連線三組測試驗證：合法重用不應返回 421；錯誤連線應穩定返回 421；新連線重試應得到目標服務的最終回應。
6. 高品質示範回答
我會把 421 視為連線脈絡或來源站權威性不匹配，而不是通用的暫時故障。先關聯 TLS SNI、HTTP authority、憑證、ALPN、連線池和虛擬主機路由，確認請求是否重用了不適用的連線。來源站可以返回 421，代理應轉發它而不是憑自身產生。客戶端可針對目標 origin 建立新連線後重試，但要檢查方法冪等性、請求體重放和冪等鍵。觀測上按網域、協定、節點和連線池維度統計，並用同連線重用與新連線回歸測試證明修復有效。
7. 常見錯誤
- 把 421 統一改成 503 → 遺失連線脈絡線索 → 保留 421，並在閘道日誌中記錄 SNI 與 authority。
- 只檢查 Host 不看 SNI → 無法解釋憑證和虛擬主機重用問題 → 同時記錄 TLS 和 HTTP 兩層目標。
- 讓代理隨意產生 421 → 違反狀態碼責任邊界 → 代理轉發來源站 421，自己的路由故障使用明確的 5xx 契約。
- 收到 421 後無條件重試 POST → 可能重複寫入 → 先用冪等鍵或確認未執行，再限制次數和退避。
- 只在單網域單連線測試 → 遺漏 HTTP/2 重用路徑 → 加入跨網域重用、錯誤重用和新連線三組回歸。
8. 追問及應對
追問一：421 與 503 的區別是什麼？
421 指向請求與目前連線或來源站權威性的錯配，換到目標專用連線可能恢復；503 表示服務暫時無法處理請求，通常與容量、維護或依賴有關。兩者的修復路徑、重試條件和告警維度不同。
追問二：客戶端可以重用舊連線重試嗎？
不應繼續使用被判定不適用的連線。客戶端應針對目標 origin 建立新連線，重新完成 TLS 和協定協商；同時遵守退避、請求體可重放和驗證狀態要求。
追問三：代理看到 Host 與 SNI 不一致時能否直接返回 421？
不能僅憑代理自身判斷產生 421。它應按自身路由契約返回合適錯誤，或把請求轉給來源站由來源站決定；若確實轉發了來源站 421，應保留來源資訊供排查。
追問四：如何驗證連線池修復沒有降低效能？
分別測量合法重用、按 authority 分池和錯誤重用被拒絕三種情境，比較 421 率、交握次數、尾延遲、連線數與 CPU。目標是消除錯誤重用，同時把新增交握成本控制在可接受的預算內。