科技 · 实用指南
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。
