2026 年 9 月 2 日發布的 curl 8.22.0 修改了 libcurl 解析 Alt-Svc 回應標頭參數的方式。curl 專案將這項修正概括為「遇到未知參數後繼續解析」。相關變更說明，陌生的擴充值可能讓舊解析器提前停止，因此看不到後面有效的 ma 或 persist 參數。
問題並不是 curl 把任意擴充誤認為已支援設定，而是舊解析器會嘗試將每個參數值解釋成數字。若未知擴充使用非數字權杖或帶引號字串，解析可能提前結束。雖然未知 Alt-Svc 參數本應被忽略，但它後面的最大有效期或持久化指令也可能因此沒有被處理。
curl 8.22 會先解析擴充名稱及其權杖或帶引號字串，再判斷參數是否已知，然後繼續處理。對已識別的 ma 與 persist，數字驗證仍會保留。
為什麼代理用戶端需要關注
Alt-Svc 允許 HTTPS 來源站宣告替代服務，通常是另一種協定或端點。libcurl 應用程式可以在記憶體或快取檔案中保存這些資訊，並在建立後續連線時考慮替代路徑。
代理支援的資料收集、區域可用性檢查與廣告驗證通常包含多層連線：用戶端到代理、可選的 CONNECT 通道、代理出口到來源站，以及替代來源服務。若快取項目解析不完整，可能改變協定選擇、過期行為與新連線使用的路由。因此，這個解析細節具有實際維運意義，但它不會直接修改代理認證或集區選擇。
不要把本次修正理解為通用 HTTP/3 或代理修正。它只針對未知參數出現在應用程式依賴的已知參數之前時的 Alt-Svc 解析行為。
哪些回應形態需要回歸
以下條件同時成立時應優先測試：
- 應用程式已啟用 libcurl Alt-Svc 引擎；
- 可信 HTTPS 來源站回傳 Alt-Svc 標頭；
- 替代項目包含 curl 不認識的擴充參數；
- 有效的
ma或persist位於該擴充之後； - 後續請求依賴快取項目的過期或持久化行為。
只含已知參數的簡單回應可能無法顯示版本差異。有效回歸應將未知權杖值或帶引號字串放在已識別欄位之前。
安全邊界沒有改變
依據 libcurl Alt-Svc 控制說明，只有透過 HTTPS 收到的 Alt-Svc 標頭才會被接受，替代來源站也只透過 HTTPS 使用。替代服務只在建立新連線時考慮；連線池若已有合適連線，用戶端會優先重用。
驗證修正時必須保留這些邊界。如果測試一直重用同一條 HTTP/2 連線，可能根本不會觸發 Alt-Svc 決策。一般 HTTP 回應也不能作為這個 HTTPS 功能的有效正式環境對照。
可使用TLS 工作階段恢復測試區分新建替代服務連線、連線重用與 TLS 恢復。針對 HTTP/3 回應處理，可參考curl 8.22 HTTP/3 代理標頭更新。
建立受控回歸
只使用組織自有或獲授權的測試來源站與代理帳戶。設定三種 Alt-Svc 回應：
- 只含已知
ma與persist的基準項目； - 未知權杖型參數，後接有效
ma與persist； - 未知帶引號字串，內容包含空格、跳脫引號或分號，後接相同有效欄位。
固定宣告協定、替代主機、連接埠與回應內容。使用低請求頻率及較短測試有效期，以便安全觀察快取生命週期。
驗證解析結果，而不只看請求成功
即使 Alt-Svc 快取錯誤，請求仍可能透過原始來源站成功。每輪應記錄：
- curl 與 libcurl 實際執行版本；
- 已啟用的 Alt-Svc 協定旗標；
- 原始來源站、宣告協定、替代主機及連接埠；
- 去識別前的完整測試回應標頭；
- 未知值屬於權杖或帶引號字串；
- 解析出的最大有效期與持久化狀態；
- 快取建立與更新時間；
- 後續請求是重用既有連線或建立新連線；
- 協商協定、選中對端與內容驗證結果。
測試資料與日誌中不得放入真實代理密碼、Cookie 或授權標頭。
測試過期行為
ma 控制替代服務可以保持有效的時間。設定較短的受控有效期，在過期前觀察項目，再於過期後測試。用戶端不應繼續為新連線選擇已過期項目。
若未知擴充曾遮蔽後面的 ma，不同版本觀察到的快取壽命可能不同。應比較實際儲存的過期時間，而不是只看單次請求是否使用替代服務。
單獨測試持久化
持久化表示 Alt-Svc 項目是否預期跨越特定網路變化。它與快取檔案是否跨程序保存不是同一概念，不能合併成一個指標。
分別執行記憶體快取、專用非特權快取檔，以及應用程式確實需要持久化時的程序重新啟動測試。限制檔案權限，並將快取放在非可信使用者無法寫入的目錄。能替換快取檔案的攻擊者可能影響連線路由。
加入代理路徑對照
對同一組回應變體分別執行：
- 直連受控來源站；
- 透過一條穩定、獲授權的 HTTP CONNECT 路徑；
- 保持同一來源站回應，透過受控輪替路徑；
- 對受測後續請求停用連線重用；
- 關閉 Alt-Svc 作為負向對照。
由於標頭來自可信來源站，各路徑解析結果應一致。若有差異，可能是閘道修改回應標頭、用戶端載入不同執行庫，或存活連線使新連線決策沒有執行。
安全部署 curl 8.22
盤點容器、語言繫結與長時間執行程序實際載入的 libcurl。先升級一個工作佇列，只清除測試快取，並與未升級對照組比較。保留足夠證據，將快取解析與 DNS、TLS、代理驗證、出口健康及 HTTP/3 協商區分開。
若替代目標錯誤、過期項目仍被使用、信任驗證發生變化或內容驗證失敗，應停止擴大部署。預期變化很有限：未知擴充值不再阻止後續已識別參數被解析。
驗證檢查清單
- [ ] 實際執行版本為 curl/libcurl 8.22.0 或更新版本。
- [ ] Alt-Svc 引擎已為目標協定明確啟用。
- [ ] 測試標頭來自受控 HTTPS 來源站。
- [ ] 未知權杖與帶引號字串位於有效已知參數之前。
- [ ] 最大有效期與持久化狀態符合測試資料。
- [ ] 過期項目不會用於新連線。
- [ ] 已將存活連線重用與 Alt-Svc 選擇分開。
- [ ] 直連與獲授權代理路徑得到相同解析結果。
- [ ] 快取檔案具有受限擁有權與權限。
- [ ] 成功判定包含協定、對端與內容驗證。
常見問題
curl 8.22 會開始信任未知 Alt-Svc 擴充嗎？
不會。修正只是讓解析器讀取並忽略未知擴充值，以便繼續讀取後面的已識別參數。未知欄位不會變成受支援設定。
Alt-Svc 會取代我的代理設定嗎？
不會。它是來源站提供的替代服務中繼資料。代理選擇、通道與出口政策仍由應用程式獨立決定，但完整連線路徑應一起測試。
為什麼後續請求仍使用 HTTP/2？
合適的存活連線可能在建立 Alt-Svc 新連線前被重用。執行庫也可能不支援或未啟用宣告協定。應確認建置功能並強制執行受控新連線測試。
正式環境工作應共享一個 Alt-Svc 快取檔案嗎？
只有在擁有權、權限、來源站邊界與並行存取都經過設計及審查後才考慮共享。依應用程式或信任網域隔離快取通常更安全。
來源與合規說明
內部研究使用了 2026 年 9 月 2 日的 curl 8.22.0 變更記錄、2026 年 8 月 23 日提交的 curl 拉取請求 22644，以及目前 libcurl Alt-Svc 選項文件。公開內文不包含外部 URL。
只測試自有或獲授權的來源站、代理帳戶與網路。遵守平台條款、頻率限制、隱私義務與地區法律。不得使用 Alt-Svc 測試繞過存取控制或掩飾被禁止的自動化行為。
