curl 發佈三條 Rock-solid 修補分支：重新稽核代理客戶端版本策略
curl 官方版本歷史現在列出三條日期為 2026 年 9 月 7 日的 Rock-solid curl 版本：8.14.2、8.16.1 及 8.20.1；同一頁面也列出 9 月 2 日的 8.18.2。它們是面向付費客戶、分開管理的長期支援版本，從較早的標準 curl 版本建立分支。目前公開版本仍是 9 月 2 日發佈的 curl 與 libcurl 8.22.0。
這項差異直接影響代理客戶端叢集。看似修補號的版本不一定是下一個公開 curl 版本，數字最高也不代表最適合正式環境。團隊必須確認建置來源、包含的功能與修正、維護責任，以及代理行為的驗證結果。
curl 公開版本表沒有列出每條商業分支的全部詳細內容，因此不能只憑新修補號推測某項安全或代理修正已經納入。
區分公開版本與支援分支
資產清單應維護兩個明確概念：
- 上游公開線：公開發佈的 curl/libcurl 版本、已記錄變更，以及基於它建置的發行版或供應商套件。
- 支援分支：具有明確支援契約、回移政策、交付管道和升級路徑的獨立維護分支。
Rock-solid 使用未被免費公開線採用的版本號。因此，只寫「curl 8.20.1」的部署報告並不完整，還應記錄供應商、套件身分、建置來源及適用支援契約。
盤點真正執行環境，而不是預定套件
代理應用程式載入的 libcurl，常與終端機中的 curl 指令不同。容器、語言繫結、嵌入式代理與系統工具都可能攜帶獨立建置。
每個工作負載至少記錄：
工作負載別名
二進位檔或程式庫路徑
curl 與 libcurl 版本
套件供應商與摘要值
分支類型與建置日期
TLS 與解析器後端
啟用協定與功能
架構與作業系統
支援負責人
回復成品透過受控清單工作讀取實際處理程序資訊。不能假設基礎映像更新會改變所有靜態連結二進位檔或捆綁相依性。
先定義版本分支要最佳化什麼
目前公開版與受維護舊分支解決不同問題，選擇前應寫明：
- 是否需要近期新增的公開功能；
- 對行為改變及回歸的容忍度；
- 是否要求在固定基準上回移修正；
- 供應商支援及回應目標；
- 作業系統與 TLS 後端相容性；
- 合規證據與軟體物料清單需求；
- 升級頻率和維護窗口；
- 是否能執行具代表性的代理金絲雀測試。
支援契約不能取代測試，最新公開版也不必然高風險。正確選擇取決於產品需求和真實路線證據。
依能力建立代理回歸矩陣
只使用自有或明確獲准的端點與帳號：
| 能力 | 最低斷言 |
|---|---|
| HTTP 代理 | 認證請求完成且回應摘要正確 |
| HTTPS 代理 | 代理與目的 TLS 對端分別通過驗證 |
| CONNECT 隧道 | 只對核准的 authority 與連接埠建立 |
| SOCKS5 | 觀測到預期的本機或遠端 DNS 模式 |
| 環境代理 | 大小寫變數及略過規則優先順序符合政策 |
| IPv4 與 IPv6 | 位址族與市場來自觀測，不靠推測 |
| 代理認證 | 核准方法成功且憑證不洩漏 |
| 連線重用 | 不發生跨工作階段身分或認證混用 |
| 重新導向 | 最終目的仍在核准範圍內 |
| 上傳與下載 | 位元組數、摘要及中斷回復正確 |
不能因為建置支援某協定就全部啟用。測試與正式環境只保留工作負載真正獲准使用的能力。
使用單變數金絲雀比較分支
讓現有版本與候選版本使用同一測試端點及代理路線，固定方法、請求標頭、本文、憑證、市場、DNS 模式、位址族與併發。
每次嘗試保存一列去識別資料：
試驗編號
分支別名與客戶端建置摘要
代理路線別名
協定與 DNS 模式
位址族
申請市場與觀測市場
代理認證結果
代理 TLS 與目的 TLS 結果
HTTP 版本與狀態碼
回應摘要
失敗階段
嘗試次數
有效結果耗時首次嘗試與重試後的最終結果必須分開。否則，製造更多重設或認證重試的候選版本可能看似健康，卻增加延遲、頻寬與代理成本。
注意建置相關差異
相同版本號使用不同 TLS、解析器、壓縮、HTTP/2、HTTP/3 或 SSH 後端時，行為也可能不同；套件維護者還可能加入下游修補。
上線門檻應比較完整版本與功能輸出、TLS 後端與 CA 儲存區行為、非同步或執行緒解析器、HTTP/2 與 HTTP/3 能力、代理協定及認證方式、原生 CA 整合、執行設定與環境變數，以及套件和容器摘要。
兩個客戶端即使 curl 標籤相同，只要功能集不同，就應視為不同發佈成品。
驗證代理認證與連線重用
認證回歸可能只在重用、挑戰協商或路線切換後出現。依序測試：
- 新連線上的首次請求；
- 同一連線的第二次請求；
- 透過同一代理池存取新的核准目的；
- 受控環境中的憑證輪替；
- 錯誤認證後使用正確憑證；
- 多個工作執行緒使用獨立工作階段別名；
- 挑戰回應附近的取消與重試。
確認憑證不會跨工作負載、目的或客戶工作階段傳播。僅保存去識別認證方法與結果，絕不保存密碼或完整認證標頭。
依路線分階段，而不只看主機比例
百分之十主機的金絲雀仍可能漏掉只由單一工作負載使用的協定或市場。應依序推進：確定性實驗端點、每種代理類型的一條路線、每個營運區域的一個核准市場、低風險唯讀工作負載、代表性併發與連線重用，最後才擴大正式流量。
保留現有成品。當出現代理或目的 TLS 故障、認證漂移、回應完整性不符、市場異常、重試放大、控制代碼洩漏或尾端延遲回歸時立即回復。
採購支援分支時要問
- 包含哪個上游基準及哪些下游修補？
- 涵蓋哪些系統、架構與 TLS 後端？
- 如何選擇要回移的安全及正確性修正？
- 如何交付並驗證成品真實性？
- 如何提供發佈說明與軟體物料清單？
- 測試哪些代理協定及認證組合？
- 分支維護多久？
- 支援及事件回應目標為何？
- 結束支援後如何處理？
- 是否支援分階段移轉至其他版本線？
答案應寫入相依性登記表。「長期支援」只有在範圍、負責人及退出計畫明確時才有價值。
驗收清單
- [ ] 公開版本與支援分支分開標記。
- [ ] 供應商、套件、摘要及支援負責人已記錄。
- [ ] 每個工作負載實際載入的 libcurl 已盤點。
- [ ] 建置功能、TLS 及解析器後端已擷取。
- [ ] 直連與代理金絲雀使用獲准確定性端點。
- [ ] 已涵蓋使用中的 HTTP、HTTPS 代理、CONNECT 與 SOCKS5。
- [ ] DNS、IPv4、IPv6 及所需市場都有斷言。
- [ ] 認證與連線重用沒有憑證混用。
- [ ] 回應摘要及語意完成皆通過。
- [ ] 重試後仍保留首次失敗訊號。
- [ ] 金絲雀依路線與工作負載細分。
- [ ] 回復成品及終止支援計畫可用。
常見問題
Rock-solid curl 是新的公開 curl 嗎？
不是。curl 將其描述為面向付費客戶、分開管理的長期支援版本；公開 curl/libcurl 有獨立版本歷史。
8.20.1 是否包含公開版 8.22.0 的所有內容？
不能從數字這樣推測。它屬於獨立維護分支的修補版本，應依供應商發佈資訊及所需功能與修正清單判斷。
代理叢集都應選擇長期支援嗎？
沒有統一答案。應結合功能、回移政策、營運風險、支援義務、成本及金絲雀證據評估。
curl --version 能證明應用程式使用哪個程式庫嗎？
它只能證明該指令的建置，不一定代表其他應用程式實際載入的程式庫。必須檢查真正執行環境、套件及相依路徑。
合規與安全運作
僅使用獲准的代理服務、目的、帳號與市場。遵守存取控制、速率限制、隱私要求以及軟體授權與支援條款。透過核准交付流程驗證套件真實性，保護憑證，不能用路線輪替掩蓋政策或信任故障。
繼續閱讀 HTTPS 代理 TLS 憑證鏈稽核、Node.js 代理客戶端金絲雀方案及代理閒置逾時測試。
來源說明：curl 專案 Version Numbers and Releases、Releases and Downloads、Commercial Support，複核於 2026 年 9 月 13 日。
