科技 · 實用指南
curl 錯誤 35「wrong version number」？改 TLS 前先證明哪一跳說了明文
這通常是協定不匹配，不代表 TLS 版本太舊。逐跳核對代理與來源站，只修正真正邊界，並保留憑證驗證。
這通常是協定不匹配，不代表 TLS 版本太舊。逐跳核對代理與來源站，只修正真正邊界，並保留憑證驗證。
這句話容易讓人誤判：某個邊界回傳了不符合握手預期的協定位元組，但這不能證明 TLS 版本本身已過時。
1. 固定失敗路由
重試前保存完整 curl 命令、URL、curl -V、結束碼與已脫敏的 curl -v 或 --trace-time。記錄主機與 shell，因代理變數和 .curlrc 依環境而變。
列出 http_proxy、HTTPS_PROXY、ALL_PROXY 與 NO_PROXY，但不要公開憑證。只有政策與路由允許直連時，--noproxy "*" 才是有效對照。
2. 逐一命名網路跳點
把路徑寫成用戶端到代理、代理 CONNECT、隧道、來源站。http:// 代理表示先以明文到代理；https:// 代理表示先與代理做 TLS。
也要核對目標 scheme 與服務連接埠。把 HTTPS 送到只提供明文 HTTP 的埠，即使雙方支援現代 TLS，也可能出現 wrong version number。
3. 讀取詳細記錄邊界
在詳細記錄中找最後一次成功連線與第一次 TLS 記錄失敗，判斷它在 CONNECT 前、CONNECT 回應處，或隧道成功後的來源站握手。
若期待 ServerHello 卻看到代理橫幅、HTTP 狀態列或可讀明文，這就是路由證據。保存前移除認證標頭、Cookie 與查詢秘密。
4. 只修一個協定契約
只修已證明的不匹配：代理 URL scheme、代理埠、目標 scheme、服務監聽器或過期環境變數。不要先用 -k，也不要盲目強制 TLS 版本。
若組織要求 TLS 攔截，應在證明路由後安裝並限定核准的信任鏈；若不應存在，將意外代理或憑證視為安全與設定事件。
5. 證明修復結果
沿預期路徑再做一次詳細請求，要求代理與隧道順序正確、TLS 完成、主機名稱驗證通過，並收到目標 HTTP 狀態。
保存修正命令、脫敏追蹤與設定差異，再測試原應用程式或安裝器，因其環境可能不同於目前 shell。
