curl 8.22 恢復共享連線池上限：代理客戶端升級測試
curl 8.22.0 於 2026 年 9 月 2 日發布，其中一項連線快取修正會把 multi handle 的連線限制套用至使用共享池的傳輸。原始報告涉及 easy handle 透過 CURL_LOCK_DATA_CONNECT 共享連線時，CURLMOPT_MAX_HOST_CONNECTIONS 與 CURLMOPT_MAX_TOTAL_CONNECTIONS 的執行。
報告指出，在這種特定架構中，curl 8.13.0 至 8.21.0 可能沒有執行已設定的上限。這不表示所有 curl 使用者都會超出連線數；應用程式必須同時使用 multi handle、設定連線上限，並採用 share handle 擁有的連線池。不過，高並行代理客戶端仍應把 8.22 視為容量控制變更進行驗證。
為何代理團隊需要關注
連線上限不只保護目標站，也能限制代理閘道通訊端、控制檔案描述符及暫時連接埠使用、平滑驗證突發，並防止單一主機耗盡工作節點預算。
上限未生效時，可能出現實際並行高於預期、代理 407 驗證突發、目標或代理限速、來源連接埠壓力、不同目標之間不公平，以及升級後吞吐與成本突然變化。
不能只憑流量推斷此問題；必須測量活躍連線，並重現相同 share handle 架構。
辨識受影響架構
盤點使用 libcurl multi 介面的應用程式。逐一記錄 easy handle 是否共享連線資料、設定哪些 multi 上限、多個 multi handle 是否共用同一 share handle，以及主要流量指向哪些代理閘道與目標。
特別檢查把 libcurl 設定隱藏在 HTTP 客戶端、工作池或 SDK 後方的框架。記錄執行時實際載入的 libcurl 版本；主機上的命令列 curl 可能不同。
盤點表不得保存代理密碼或工作階段權杖，只記錄密鑰參照與驗證方式。
建立二維上限測試
使用獲准代理與受控目標，分別設定較低且容易觀察的單主機上限與總連線上限，再產生足夠並行傳輸以超過兩者。
至少測試四種形態：
- 一個目標經過一個代理閘道；
- 多個目標經過一個代理閘道；
- 一個目標經過多個代理端點；
- 多個 multi handle 共用同一共享連線池。
每種形態記錄活躍連線、排隊傳輸、每秒完成量、p50/p95 延遲、代理驗證次數、錯誤碼、通訊端數量及實際出口。預期結果不只是「請求成功」，還要證明峰值不超過上限，超額工作進入佇列並在稍後完成。
在相同負載下比較版本
先用現行核准版本建立基線，再在灰度環境以 curl 8.22.0 重複測試。代理路線、目標、並行、逾時、連線重用、DNS 模式及請求內容必須保持一致。
若舊版本曾超出設定上限，修正版本可能出現瞬時吞吐降低與排隊增加。這可能是上限恢復執行的正確證據，而非效能倒退。應依原定資源及服務目標判斷。
另加一組停用連線共享的對照，以確認差異來自共享池路徑，而不是代理、目標或壓測工具。
測試故障及復原
連線失敗時，上限也必須穩定執行。重新啟動受控代理、使閒置連線失效、注入有界逾時，並輪換一個代理端點。確認失效連線離開池、佇列恢復處理，而且新建連線仍遵守兩種上限。
代理失敗後不得靜默直接連線。可搭配代理故障切換演練與暫時連接埠耗盡排查，區分連線上限變化與復原或本地網路問題。
用容量證據灰度上線
先選擇少量工作節點，監控活躍代理連線、佇列年齡、有效吞吐、尾端延遲、驗證率、重試放大及每個有效結果成本。只有在上限被遵守且佇列能於業務目標內排空時，才擴大灰度。
不要因排隊增加就立即提高上限。先確認舊設定符合代理合約、目標規則、本地通訊端預算及公平性要求。調整正式容量前，執行代理並行階梯測試。
升級檢查清單
- [ ] 已記錄每個客戶端執行時 libcurl 版本。
- [ ] 已盤點使用
CURL_LOCK_DATA_CONNECT的 multi/share handle。 - [ ] 單主機與總連線上限均有負責人。
- [ ] 測試負載能超過兩種設定上限。
- [ ] 直接測量活躍連線與排隊傳輸。
- [ ] 比較共享池與非共享池對照組。
- [ ] 驗證代理驗證、重試與出口路線。
- [ ] 故障復原仍遵守兩種上限。
- [ ] 已停用並驗證不會直接連線回退。
- [ ] 已定義灰度及回復門檻。
常見問題
命令列 curl 預設受影響嗎？
報告案例需要 libcurl 應用程式同時使用 multi handle 上限及共享連線池，簡單的單次命令不一定符合此架構。
curl 8.22 會讓工作負載變慢嗎？
如果舊版本曾超過設定上限，瞬時並行會改變，佇列可能增加。這可以是正確行為，應同時評估有效吞吐、排隊時間與資源安全。
升級後應提高連線上限嗎？
只有在獲准容量測試後才能調整。上限可能保護代理合約、目標限制、本地連接埠及公平性，不應透過恢復失控並行來追求舊吞吐。
合規說明
只對自有或明確獲准的代理帳戶與目標執行負載測試。遵守供應商並行限制、目標政策、隱私義務及速率限制，優先使用合成流量，不得利用連線共享規避存取控制。
研究說明：curl 專案《Changes in 8.22.0》，發布於 2026 年 9 月 2 日；curl 問題《CURLMOPT_MAX_HOST_CONNECTIONS is ignored with CURL_LOCK_DATA_CONNECT》，建立於 2026 年 7 月 4 日，並在版本發布前關閉。外部資料位址只保存於內部營運紀錄。
