HTTP/3 已經普及到不能在全球代理測試中忽略的程度。Cloudflare Radar 近期全球協定視圖顯示，觀測到的 HTTP 請求中約三分之一使用 HTTP/3。不同測量平台的樣本與口徑並不相同，這不是整個網際網路的統一市場占比，但已足以改變代理採購、品質測試和公開資料業務對「連線成功」的定義。
HTTP/3 為什麼形成不同測試路徑
HTTP/1.1 與 HTTP/2 通常運行在 TCP 上；HTTP/3 將 HTTP 語義映射到基於 UDP 的 QUIC，並整合 TLS 1.3。IETF RFC 9114 描述了獨立 QUIC 串流、較低延遲的連線建立，以及 UDP 無法連通時向 TCP 版本回退的行為。
在代理鏈路中，應用收到內容前，協定行為就可能不同。瀏覽器可能直接使用 HTTP/3，也可能回退到 HTTP/2；代理隧道還可能改變連線某一側使用的協定。因此，只查看 HTTP 狀態碼無法說明真實傳輸路徑。
代理團隊應新增的五類指標
1. 分別記錄兩側協商協定
記錄用戶端到代理、代理到目標端的協定。瀏覽器支援 HTTP/3，不代表整條鏈路都使用 HTTP/3。TCP CONNECT 隧道、閘道策略或目標設定都可能改變結果。
2. 按地區測試 UDP 可達性
分別檢查北美、歐洲和亞太的 UDP 連通性。企業防火牆、接入網路和本地路由策略對 QUIC 的處理可能不同。某地區看似延遲較高，實際原因可能是 QUIC 多次嘗試後才回退到 TCP。
3. 測量回退耗時，而非只看最終成功
請求最終成功仍可能因回退增加數秒等待。應記錄首次連線、回退、TLS 完成、首位元組和整體完成時間，並使用 p50、p95 與 p99，而非只看平均值。
4. 檢查連線重複使用與工作階段穩定
QUIC 連線可以承載多個獨立串流。需要檢查網路變化時長連線是否穩定，以及重試時代理輪換是否意外改變身分。應用 Session、Cookie 與代理工作階段標識必須符合業務預期。
5. 按協定統計有效業務結果
將挑戰率、預期地區內容、完整頁面率、API 有效性、重試率與單位有效結果成本按協商協定拆分。交握更快不代表結果更好，尤其當回退導致地域身分或工作階段改變時。
四格測試矩陣
- 直連加 TCP：建立傳統基準。
- 直連加 HTTP/3：確認目標與本地網路支援 QUIC。
- 代理加 TCP：測量常規隧道或閘道路徑。
- 代理加支援 HTTP/3 的用戶端：確認 HTTP/3 是被保留、終止還是替換，並衡量回退速度。
四種測試必須使用相同的獲准目標、地區、請求集與時間視窗，否則差異可能來自目標負載、頁面變化或地域，而不是協定。
常見故障模式
- HTTP/3 失敗但 TCP 成功：檢查 UDP、防火牆與閘道支援。
- 兩種協定都成功但 HTTP/3 更慢：檢查路由、封包遺失、連線重複使用與回退。
- 不同地區協商結果不同：檢查目標邊緣設定和區域網路策略。
- 重試後工作階段身分改變：檢查黏性工作階段參數和重試範圍。
- 只有業務完成失敗：檢查依賴介面、授權與地區內容一致性。
選擇代理時應該問什麼
應確認代理入口協定代表什麼、相關產品是否支援 UDP 或 QUIC、回退如何處理以及可提供哪些指標。大範圍區域測試可用上述矩陣評估 98IP 的動態住宅代理；需要更長期網路身分的任務可比較靜態住宅代理。
本文由 98IP 團隊發布並揭露服務關係。代理基礎設施只應用於有權存取的系統與資料，並應遵守適用條款和速率限制；協定測試不等於取得繞過存取控制的許可。
內部研究說明
本文內部參考了 Cloudflare Radar 全球 HTTP 版本觀測資料（查閱於 2026 年 8 月 16 日）、IETF RFC 9114 HTTP/3（2022 年 6 月發布）以及 IETF RFC 9000 QUIC Version 1（2021 年 5 月發布）。依照 98IP 零外鏈規則，只保留機構、資料名稱和日期的純文字。
結論：關鍵不是強制所有請求使用 HTTP/3，而是知道結果由什麼協定交付、回退如何發生，以及最終業務結果是否正確。
