curl 8.23.0-rc1 開啟加速發布前的代理回歸測試窗口

curl 專案在 9 月 17 日宣布，基於安全原因，本輪發布週期縮短兩週。專案隨即提前關閉功能窗口，於 9 月 18 日發布 curl 8.23.0-rc1，並把正式版本的目標日期調整為 2026 年 10 月 14 日。官方同時明確指出：候選版本用於測試與驗證，不應投入正式環境。

對於在 HTTP、HTTPS CONNECT、SOCKS4、SOCKS5、住宅代理或雙堆疊代理路徑中依賴 curl/libcurl 的團隊，這段時間的價值是提早找出回歸，而不是提早升級正式環境。應讓目前穩定版與候選版在相同受控條件下對照執行。

發布時間線的變化

curl 的一般週期包含功能凍結、三個候選版本以及最終發布。本輪為了更快交付待處理的安全修正而壓縮週期。rc1 代表穩定階段開始，但正式發布前仍可能繼續修正行為與實作。

• 9 月 17 日：提前關閉功能窗口並宣布縮短週期；
• 9 月 18 日：8.23.0-rc1 開放測試；
• 10 月 14 日：目前規劃的正式發布日期。

不要因為「安全原因」就推論所有代理用戶端都受某項漏洞影響，也不要認為候選版必然比目前穩定版安全。RC 的主要用途，是在正式發布前暴露相容性與回歸問題。

建立穩定版與候選版雙通道

兩個通道必須使用相同的受控目標、代理帳戶、路徑選擇、請求樣本、並行度與觀察窗口。分別記錄二進位檔或程式庫摘要、TLS 後端、解析器後端、啟用協定、作業系統、架構與套件來源。

如果穩定版與候選版走不同網路，測試就失去比較意義。盡可能固定相同的授權閘道、市場、工作階段策略與目標夾具。對於本來就輪替出口的產品，只進行有限且可重現的多次樣本，以區分路徑波動與用戶端回歸。

最低代理回歸矩陣

可參考代理回應完整性測試驗證狀態、標頭、內文標記與路徑身分；對於長期重用 libcurl 控制代碼或連線池的應用，再搭配代理連線池年齡測試。

記錄可解釋失敗的證據

每個案例記錄合成測試 ID、用戶端版本、建置摘要、代理協定、路徑類型、目標市場、位址族、DNS 模式、TLS 後端、開始時間、總耗時、狀態或錯誤分類、重試次數、連線重用決策、預期標記結果與最終結論。

報告不得保存代理密碼、授權標頭、Cookie、真實客戶網址或完整回應內容。需要保留 curl 詳細輸出時，必須先去識別化並限制存取。

先比較正確性，再比較速度。請求更快卻走錯路徑、繞過代理、接受異常憑證或回傳不完整內容，仍然是失敗。

特別檢查容易漏掉的代理行為

驗證邊界

同時測試正確與錯誤憑證。代理驗證失敗時，受控目標不應收到請求。若帳戶、市場或工作負載採用不同身分，除非供應商與應用明確支援，某個身分建立的連線不得被另一身分重用。

DNS 位置

對 SOCKS 等可設定模式，要證明解析發生在本機或遠端。使用受控區域中的合成網域名稱，對照解析器日誌與用戶端證據，避免候選版悄悄改變隱私或路由假設。

雙堆疊選擇

分別執行僅 IPv4、僅 IPv6 與雙堆疊測試，並記錄實際選用的位址族。只有雙堆疊成功不足以證明 IPv6 正常，因為用戶端可能透過 IPv4 完成。

通道與連線重用

覆蓋新建 CONNECT 通道、重用通道、閒置連線與最大連線年齡。確認代理層標頭不會混入目標中繼資料，失敗通道也不會回到連線池。

重試與取消

注入有限的逾時、連線重設與明確取消。重試控制器必須區分三種結果。錯誤代碼變化可能把單次失敗放大為重試風暴、新出口選擇或重複收集。

預先定義晉級與停止條件

建議至少要求：

• 直接連線回退為零；
• 憑證、Cookie 與診斷資訊洩漏為零；
• 所需代理協定與市場全部通過；
• 負向測試得到預期失敗；
• 重試、連線抖動與傳輸位元組沒有無法解釋的增加；
• 回應完整性不低於穩定通道；
• 延遲與錯誤率差異位於預先宣告的容差內；
• 可重現地回復至穩定成品。

若候選版存取未授權目標、繞過必要代理、把憑證傳到錯誤層、破壞回應框架或產生無界流量，應立即停止測試。安全與政策錯誤不能用平均值掩蓋。

候選版必須留在正式環境之外

使用隔離執行器、一次性測試憑證、合成目標與保守並行度。不要用 RC 替換正式基礎映像標籤、共享程式庫或系統套件，也不要把它放入可能被其他團隊誤用的通用內部儲存庫。

正式版發布後，必須針對簽署的最終成品重新執行驗收矩陣。RC 通過是有用證據，但無法取代正式版本驗證。

發布前檢查清單

• 穩定版與候選版均以摘要唯一識別。
• 套件來源、TLS 與解析器後端已記錄。
• 候選版與正式流量、正式憑證隔離。
• HTTP、CONNECT 與必要 SOCKS 模式已涵蓋。
• IPv4、IPv6 與雙堆疊分別驗證。
• 包含驗證正向與負向案例。
• DNS 位置已驗證而非猜測。
• 連線重用、閒置年齡與取消已測試。
• 已比較重試次數與傳輸位元組。
• 明確禁止並測試直接連線回退。
• 日誌已去識別化後再保留。
• 已指定正式版複測與回復負責人。

常見問題

8.23.0-rc1 可以直接升級正式環境嗎？

不可以。curl 專案明確說明候選版本是用於測試與驗證的進行中成品。正式版通過內部控制前，正式環境應繼續使用受支援的穩定版。

縮短週期是否證明我的代理用戶端受漏洞影響？

不能。實際暴露面取決於最終安全公告、具體 curl/libcurl 建置，以及應用啟用的功能。

是否要測試所有代理節點？

應涵蓋所有實質不同的類別：協定、驗證方式、DNS 模式、位址族、市場、工作階段策略與 TLS 後端。涵蓋不同能力比重複抽樣大量同質節點更重要。

請求成功是否足以證明使用了代理？

不足。必須判定路徑身分、關閉直接連線回退、驗證受控回應標記，並在條件允許時核對授權的代理側證據。

RC 失敗而穩定版通過時怎麼辦？

保存最小且已去識別化的重現材料，確認兩個通道只在候選成品上有差異，並透過 curl 專案規定的管道回報。正式環境保留穩定成品，並在下一候選版或正式版重新測試。

合規說明

只測試已授權的代理帳戶、憑證、目標與市場。使用合成資料、有限請求率和隔離執行器，遵守目標條款、robots 政策、隱私要求與速率限制。不得利用代理輪替規避存取控制、發布者決定或地區限制。

來源說明：curl 專案《A shortened release cycle》，2026 年 9 月 17 日；curl 專案《curl release candidates》，2026 年 9 月 18 日更新。外部研究網址僅保存在內部營運紀錄。