curl 8.22 將連線年齡檢查擴及多工重用：代理連線池需重新驗證
curl 與 libcurl 8.22.0 於 2026 年 9 月 2 日發佈，其中一項連線重用變更值得長時間運作的代理客戶端注意。當傳輸工作設定 CURLOPT_MAXLIFETIME_CONN 時，libcurl 現在會在重用符合條件的連線前檢查其年齡，即使該連線仍處於作用中並支援多工。專案變更紀錄指出，過齡連線不再符合新工作選用條件，過齡且閒置的連線會被關閉。
這項變更於 8 月 25 日提出，8 月 27 日在 curl 專案中關閉，並以「connection reuse: age check」列入 8.22.0 發行說明。它是行為修正，不是新的代理輪換功能，也不是獨立的安全公告。
作用中的多工連線為何特殊
在 HTTP/2 或 HTTP/3 中，多個傳輸工作可以共用一條傳輸連線。繁忙連線可能持續處於作用狀態，同時接收新的串流。如果最大壽命策略只在連線閒置時檢查，高負載多工連線就可能無法在預期邊界停止接收新工作。
8.22 變更後，超過設定壽命的連線不應只因仍在處理其他串流，就被選給新的傳輸。官方描述並非在選用檢查時突然終止既有工作；需要驗證的營運效果，是新工作轉移到仍符合條件或新建立的連線。
不要混淆三種壽命
代理營運常把不同控制都稱為「工作階段壽命」：
- 傳輸連線壽命： 客戶端可重用同一 TCP 或 QUIC 連線的總時間。
CURLOPT_MAXLIFETIME_CONN控制這一層。 - 代理驗證或閘道工作階段： 代理服務依憑證、連線或供應商定義的其他鍵保存的狀態。
- 出口身分壽命： 在黏性或輪換產品策略下，上游 IP 或路由維持穩定的時間。
汰換 libcurl 連線不保證出口 IP 改變；反之，客戶端連線保持開啟時，出口也可能依產品策略輪換。三層必須分開記錄與測試。
哪些團隊應優先複核
若應用程式符合以下任一條件，應優先進行迴歸測試：
- 正從 libcurl 8.21 或更舊版本升級至 8.22；
- 設定
CURLOPT_MAXLIFETIME_CONN執行連線汰換政策； - 使用 HTTP/2 或 HTTP/3 多工；
- 代理工作程序長時間不結束；
- 共用連線快取或具有高並行量；
- 依賴連線綁定驗證或供應商工作階段規則；
- 對新連線數、TLS 交握或出口成本有嚴格預算。
從未設定該選項的應用程式不直接受其設定上限控制，但仍應檢查封裝層與語言繫結：框架可能自動設定，而應用程式組態沒有顯示該值。
建立舊版與候選版金絲雀測試
使用你擁有或明確獲准測試的確定性端點，比較現行正式版本與 8.22，並固定以下變數：
proxy_route_alias
requested_market
address_family
proxy_protocol
negotiated_http_version
session_mode
max_lifetime_seconds
concurrency
request_rate
response_size
test_duration測試必須長到足以讓連線跨越壽命邊界。五分鐘測試無法驗證三十分鐘的汰換政策。可先在非正式環境測試端點設定較短且明確的壽命，快速觀察轉換，再以預定正式值重複。
記錄汰換邊界
每次傳輸記錄去識別化證據：
client_build
connection_id
connection_created_at
connection_age_at_selection_ms
stream_id_or_sequence
connection_reused
new_connection_opened
proxy_connect_ms
tls_ms
queue_ms
ttfb_ms
total_ms
first_attempt_result
response_digest_ok
observed_market
exit_alias
failure_phase不要記錄代理憑證、Cookie 或個人資料。內部連線 ID 應為不含敏感意義的隨機識別碼；若不需要保存原始位址，出口也應使用受控別名。
繪製每次新傳輸開始時的連線年齡。候選版本不應再把超過設定上限的連線分配給新工作，同時要考量客戶端文件中的測量精度與語意。另需確認跨越汰換邊界時，已在執行的串流仍維持正確。
預期第二層容量影響
壽命邊界更有效後，即使請求正確性提升，也可能改變資源行為：
- 連線汰換： 每小時建立的傳輸連線可能增加。
- TLS 與代理交握成本： 汰換波次附近的 p95 延遲與 CPU 可能上升。
- 排隊： 嚴格的全域或單一主機連線上限，會在建立替代連線時延遲工作。
- 連接埠與檔案描述符： 高並行量加上過短壽命可能增加資源壓力。
- 供應商計費： 部分方案或閘道可能不同方式處理新連線與重用流量。
- 工作階段連續性： 即使供應商回傳相同出口，連線綁定狀態也可能重設。
可錯開工作程序啟動時間；只有應用程式能安全實作且不違反政策時，才為壽命加入小幅抖動。若所有程序在同一秒建立與汰換連線，會產生可避免的交握尖峰。
測試連線池上限的交互作用
記錄單一主機與全域連線上限。在汰換邊界驗證：
- 舊連線達到壽命後不再接收新傳輸；
- 替代連線不會突破預期連線池限制；
- 排隊請求保持有界且可觀測；
- 重試風暴不會掩蓋連線建立失敗；
- 首次成功率與回應完整性保持穩定；
- HTTP/1.1、HTTP/2 與 HTTP/3 結果不會混成一項結論。
若代理路徑使用 CONNECT，遙測中應區分到代理的連線與通道內目標行為。單一客戶端到代理的連線可能有特定協定語意，而封裝層可能只揭露部分路徑。
用證據選擇壽命
不要只為了頻繁更新而盲目縮短壽命。應綜合：
- 實測閒置與最大連線行為；
- 代理閘道和目標端逾時；
- 驗證與憑證政策；
- DNS、代理連線及 TLS 增加的延遲；
- 多工串流持續時間；
- 路由與市場穩定性；
- 檔案描述符、連接埠與頻寬預算；
- 供應商文件與合約條款。
比較升級前後每個已驗證結果的成本。某項政策若降低陳舊連線失敗卻使交握加倍，仍可能是正確選擇，但需要明確調整容量，而不是無感上線。
發佈檢查清單
- [ ] 確認實際執行的 libcurl 版本及 TLS/HTTP 後端。
- [ ] 盤點
CURLOPT_MAXLIFETIME_CONN的設定位置、單位和值。 - [ ] 區分傳輸壽命、供應商工作階段與出口 IP 壽命。
- [ ] 讓至少一條作用中多工連線跨越壽命邊界。
- [ ] 驗證新傳輸避開過齡連線，且作用中串流未損壞。
- [ ] 測量連線建立、交握、排隊、重試與有效結果成本。
- [ ] 檢查替代連線期間的全域及單一主機連線限制。
- [ ] 按協定、市場、位址家族與代理產品分別試運行。
- [ ] 保留已測試的回復版本與告警門檻。
常見問題
curl 8.22 會在精確壽命時刻強制中斷每條連線嗎？
官方變更關注的是重用前檢查符合條件連線的年齡，包括作用中多工連線，並在連線閒置且過齡時關閉。應在選用後端中驗證實際汰換時機與作用中串流行為，不能假設是牆鐘式強制終止。
這會讓輪換代理更換 IP 嗎？
不一定。該選項控制客戶端傳輸連線重用；出口選擇仍由代理供應商的產品與工作階段規則決定。
最大壽命應短於閒置逾時嗎？
兩者解決不同問題。閒置限制清理未使用連線，最大壽命依總年齡限制重用。應搭配代理閘道與工作負載測試，不能機械推導。
這項變更代表應暫緩升級嗎？
不是。它代表需要金絲雀驗證。升級決策應包含版本來源、相關修正、迴歸證據、容量影響與回復準備。
相關 98IP 指南
來源說明
內部研究依據 curl 專案 2026 年 9 月 2 日的「curl 8.22.0」發行公告，以及 2026 年 8 月 25 日提出、8 月 27 日關閉的「connection reuse: age check」專案變更紀錄。公開頁面僅以純文字保留機構、資料名稱與日期，以遵守 98IP 零外鏈規則。
合規說明
只測試你擁有或獲准使用的端點與代理帳號。遵守並行上限、存取規則、隱私要求及供應商合約。不得以縮短連線壽命或輪換路由規避封鎖與限速。追蹤資料不得保存憑證與使用者資料。
