curl 8.22 為 Happy Eyeballs v3 加入 25 毫秒解析延遲：代理團隊該如何驗證
curl 8.22.0 於 2026 年 9 月 2 日發布，其中一項網路變更被描述為「Happy Eyeballing v3：25 毫秒解析延遲」。對使用代理執行合規資料蒐集、廣告驗證與市場研究的團隊而言，這項變化值得獨立測試，因為雙棧連線排程會影響客戶端連到哪個代理閘道、何時啟動另一位址族，以及哪些耗時被歸因於代理。
官方變更紀錄很精簡。它不代表每個請求都會快 25 毫秒，也不是把連線逾時或重試間隔統一改成 25 毫秒。解析延遲用於協調非同步抵達的位址族結果；連線嘗試間的節奏、完整連線逾時與端到端請求時間是不同指標。升級應被視為連線排程變更，而非無條件的效能提升。
為什麼需要解析延遲
雙棧主機名稱可能同時回傳 IPv6 與 IPv4 位址，但 A 與 AAAA 結果不一定同時抵達。企業 DNS、VPN、本機快取、行動網路或雲端解析路徑都可能讓某一類結果較晚。如果客戶端立刻使用第一批結果，雖可快速開始連線，也可能讓另一位址族失去參與競速的機會。
短暫的解析延遲會給另一類結果一個有界窗口，再安排連線。curl 8.22 記錄的 25 毫秒屬於這個解析階段，不應與 CURLOPT_HAPPY_EYEBALLS_TIMEOUT_MS 混淆；後者控制位址可用後連線嘗試之間的節奏。
為什麼代理路徑必須獨立驗證
使用代理時，客戶端首先連線的通常是代理閘道，而不是最終目的端。傳統 HTTP 代理與 CONNECT 隧道中，代理閘道可能為雙棧；目的網域則可能由客戶端或代理解析，取決於協定與設定。不同 SOCKS 模式也會改變 DNS 責任方。
因此必須分別回答：
- 客戶端是否同時解析代理閘道的 IPv4 與 IPv6？
- 哪個閘道位址勝出，升級前後是否一致？
- 目的網域由代理解析，還是由客戶端先轉換為位址？
- 首次連線後，連線重用是否掩蓋新的排程邏輯？
- IPv4 與 IPv6 閘道是否對應不同區域、出口池或策略？
僅看到頁面成功回應，無法證明這些邊界全部正確。
建立授權範圍內的迴歸矩陣
只使用獲准的代理帳號與測試目的端。在自有 DNS 測試環境準備 IPv4-only、IPv6-only 與雙棧名稱，並加入可控制 A 或 AAAA 回應延遲的雙棧情境。
至少涵蓋下列用例：
- 不使用代理的雙棧目的端，作為對照；
- 雙棧代理閘道，目的端由代理解析；
- 雙棧代理閘道，目的端由客戶端解析；
- 僅 IPv4 與僅 IPv6 的代理閘道對照；
- 每條路徑分別測試冷連線與重用連線；
- 正常 DNS、延遲 A 回應、延遲 AAAA 回應。
保持客戶端建置、解析器設定、閘道區域、驗證方式、請求內容與逾時預算一致，在同一環境比較目前核准版本與 curl 8.22.0。
記錄能解釋結果的資料
若測試工具允許，記錄 A 與 AAAA 查詢開始和完成時間，並記錄首次連線嘗試、後續位址族嘗試、勝出的閘道位址、連線完成、代理驗證、CONNECT 完成、目的端 TLS、首位元組與總耗時。
每個樣本還應包含：
- curl 與執行時期 libcurl 版本；
- 代理協定與 DNS 責任方；
- 閘道主機名稱、區域與勝出位址族；
- 冷連線或重用連線狀態；
- DNS 結果順序與抵達時間差；
- 連線結果與 curl 錯誤碼；
- 回應驗證、重試次數與位元組數；
- 依路徑類型統計的 p50、p90 與 p95。
不要在紀錄中保留代理密碼、Cookie、權杖或完整個人資料。使用合成識別碼，並在分享診斷檔前完成去識別化。
不要用猜測解釋升級差異
如果 8.22 在某一 DNS 結果較晚時更早開始連線，仍須確認閘道區域與策略正確。中位數變快不代表上線成功；若尾端失敗、路徑漂移或重試放大增加，業務結果仍可能惡化。
若 IPv4/IPv6 勝出比例改變，應分別比較兩類路徑的封包遺失、交握時間與有效回應率。不要因某個辦公室或雲端區域裡 IPv4 較常勝出，就直接關閉 IPv6。問題可能來自解析器、路由公告、防火牆或閘道部署。
若暖連線看不到差異，可能只是連線重用避開了新的解析與建連。在受控樣本強制新連線後再判斷，但不要為了展示基準差異而讓正式環境請求頻繁斷線。
可搭配代理延遲歸因測試把 DNS 與閘道連線變化從目的端處理時間中分離，並使用IPv6 代理連線指南完成更完整的雙棧排查。
設定上線門檻
測試前定義明確門檻，例如：
- 有效請求失敗率不得上升；
- 強制代理情境不得出現直連；
- 閘道區域與出口策略保持穩定；
- IPv4/IPv6 勝出比例變化可解釋且有界；
- p95 建連耗時改善或至少不惡化；
- 每個有效結果的重試數不增加；
- 單一有效業務動作的成本不明顯上升。
若客戶端繞過代理、選擇未授權路徑、持續增加尾端延遲或出現無法解釋的位址族失敗，應立即回復舊版。舊建置應保留到所有正式環境網路類型完成灰度。
升級檢查清單
- [ ] 已確認 curl 8.22.0 與實際載入的 libcurl 版本。
- [ ] 已記錄代理閘道和目的網域的 DNS 責任方。
- [ ] 已準備 IPv4-only、IPv6-only 與雙棧對照。
- [ ] 可在受控環境測量 A 與 AAAA 回傳時間。
- [ ] 冷連線與重用連線分開報告。
- [ ] 已驗證閘道位址族、區域與出口策略。
- [ ] 代理驗證與 CONNECT 耗時分開統計。
- [ ] p50、p90、p95 僅以驗證成功的回應計算。
- [ ] 重試放大與有效結果成本保持在預算內。
- [ ] 灰度回復條件已預先核准。
常見問題
新的 25 毫秒就是 IPv4 回退逾時嗎？
不是。官方條目描述的是 Happy Eyeballs v3 的解析延遲。連線嘗試節奏是另一個控制項，應分別測量 DNS 結果抵達與通訊端啟動時間。
每個代理請求都會受影響嗎？
不一定。它主要影響正在連線的主機名稱為雙棧，且位址族結果非同步抵達的情境。已重用的代理連線可能不會重新解析與建連。
為了穩定是否應強制 IPv4？
除非明確的網路要求如此，否則應先確認故障屬於 DNS、路由、防火牆、閘道部署或客戶端。強制單一位址族會掩蓋 IPv6 缺陷並降低韌性。
更快的建連會不會選到不同代理出口？
部分部署中，不同位址族可能進入不同閘道基礎設施，因此必須記錄閘道位址、區域與實際出口策略。
內部來源說明：curl 專案《Changes in 8.22.0》，2026 年 9 月 2 日發布；條目「Happy Eyeballing v3: resolution delay of 25ms」。外部資料網址只保留在內部營運紀錄中。
代理基礎設施只能用於合法且已獲授權的活動。遵守目的網站條款、速率限制、隱私義務與資料保留要求，不得透過連線調校繞過存取控制或掩飾違規行為。
