curl 問題報告：OpenWrt 上 Git 在 HTTPS 代理 407 重試後崩潰
curl 專案在 2026 年 9 月 13 日收到一則問題報告：在一個基於 OpenWrt 的環境中，驗證 HTTPS 代理回傳 407 Proxy Authentication Required 後，git-remote-https 可重現地以 signal 11 終止。報告者表示，預先強制選擇 Basic 代理驗證可避開質詢與重新連線路徑，並讓 Git 請求完成。
該問題目前仍為 open，並帶有「outdated」標籤。維護者尚未確認根因、修補程式或普遍回歸結論。現有證據只適用於報告者的特定套件與平台組合，不能擴大為所有 curl、Git、OpenWrt 或代理環境的結論。
報告中的環境
報告列出 iStoreOS 24.10.8、AArch64、Git 2.50.1、curl/libcurl 8.19.0 套件、OpenSSL 3.0.21 與 nghttp2 1.63.0。代理是要求 HTTP Basic 驗證的 HTTPS CONNECT 閘道，目標使用 GitHub HTTPS smart HTTP。
報告中的追蹤資訊顯示：用戶端先送出未驗證 CONNECT，收到宣告 Basic 的 407，開始重新連線，接著在第二次已驗證 CONNECT 送出前崩潰。
內部來源說明：curl 專案問題「git-remote-https segfaults after HTTPS proxy 407 challenge with libcurl 8.19.0 on OpenWrt; preemptive Basic works」，提交於 2026 年 9 月 13 日；複核時仍為 open，標籤為 TLS、connecting and proxies、outdated。
這不是簡單的連線結論
報告者提供了三組有價值的對照：
- 不提供憑證時，Git 如預期收到 407 並正常報錯退出，沒有崩潰。
- 預先強制 Basic 代理驗證時，Git 操作完成。
- 獨立 curl 透過同一驗證 HTTPS 代理正常運作。
這些現象把報告中的失敗範圍縮小到特定 Git 與 libcurl 組合所經歷的質詢、重新連線或驗證重試路徑，但不能證明哪個元件存在缺陷，也不能說明代理不可用。
營運人員應保留這個層次區分：閘道可達、TLS 成功且憑證有效時，某個用戶端整合仍可能在 407 狀態轉換中失敗。
使用受控 A/B 矩陣重現
只使用獲准測試的程式碼儲存庫與代理帳戶。固定目標、閘道、用戶端主機、憑證與網路路徑，再比較：
- Git 不帶代理憑證，預期乾淨地回傳 407。
- Git 使用一般質詢式驗證。
- Git 明確選擇核准的驗證方式。
- 獨立 curl 透過同一閘道。
- 同一裝置上的另一組 Git 與 libcurl 套件。
- 若條件允許，在參考作業系統執行相同套件建置。
不要把密碼放在命令列，也不要貼入追蹤記錄。使用作業系統核准的憑證機制；分享證據前必須移除 Proxy-Authorization、使用者名稱、閘道位址、儲存庫 Token 與私密路徑。
嚴格限制暫時規避範圍
報告中的預先 Basic 設定只是單一環境的觀察，不是通用建議。採用前必須確認代理端 TLS 邊界符合安全政策，並確保憑證絕不經由未加密連線傳送。
優先使用針對儲存庫或主機的 Git 設定，避免全域變更。記錄原始設定、驗證回復，並確認無關目標不會繼承此設定。規避成功也不能取代根因調查，因為映像檔或套件更新後，崩潰路徑可能再次出現。
系統化處理 407 可參考curl 代理驗證 407 除錯指南。若不同用戶端的驗證結果不一致，還應執行代理憑證編碼驗證。
測試目前受支援套件
由於問題帶有 outdated 標籤，升級處理前應在裝置可用的最新受支援 Git、curl 與 libcurl 套件上重現。不要直接替換正式環境二進位檔。建立測試映像檔，保留相同代理與儲存庫矩陣，並比較第一個失敗階段。
記錄 Git 版本、curl 版本、libcurl 功能清單、TLS 後端、CPU 架構、C 函式庫、HTTP/2 函式庫、套件來源與準確代理協定。Git 可能載入與獨立 curl 不同的 libcurl，因此「curl 能用」不代表兩者使用相同函式庫或選項。
HTTPS 代理 TLS 與密碼套件相容性測試可先確認代理端與目的端 TLS 邊界都符合政策，再把焦點轉向驗證重試行為。
安全收集崩潰證據
只收集必要資訊：
- 失敗邊界的去識別化 Git 與 curl 追蹤。
- 退出訊號，以及政策允許時的符號化回溯。
- 套件版本與相依連結關係。
- 移除憑證後的預期 407 回應標頭。
- 每個 A/B 案例的結果與時間戳記。
- 第二次已驗證 CONNECT 是否真的送出。
- 乾淨程序與裝置重啟後是否仍會崩潰。
核心傾印可能包含憑證、URL、環境變數、記憶體內容與客戶資料，未經審查不得公開。應限制診斷資料的存取權並設定保留期限。
營運回應檢查清單
- 輔助程序持續崩潰時停止自動重試。
- 使用獨立且核准的用戶端確認代理基本能力。
- 分別記錄代理 TLS、407 驗證與目的端 TLS 結果。
- 比較質詢式驗證與明確選擇驗證方式。
- 確認 Git 實際載入的 libcurl。
- 在預備環境測試目前受支援的套件組合。
- 將暫時設定限制於目標主機或儲存庫。
- 分享前去識別化追蹤並審查崩潰資料。
- 保留首次失敗指標，不可用規避後的重試成功覆蓋。
常見問題
該問題是否證明 curl 8.19.0 遇到所有驗證代理都會崩潰？
不能。這只是一則特定 OpenWrt 套件組合的開放報告，目前沒有確認普遍根因。
獨立 curl 請求成功是否能完全排除代理問題？
它只確認一個用戶端路徑能使用閘道。Git 的 libcurl 連結、選項與重試行為可能不同，因此對照能縮小範圍，卻不能單獨定案。
是否應全域強制 Basic 代理驗證？
不應。只有安全政策允許時，才能把它作為經過嚴格範圍測試的暫時選項；限定目標、要求代理端 TLS，並保留回復方案。
合規說明
只測試自有或明確獲准評估的代理帳戶、儲存庫與系統。保護憑證與崩潰資料，遵守供應商和目的端限制，不得為通過測試而關閉 TLS 驗證。
