curl 报错 35 怎样查？先定位失败的 TLS 握手
浏览器能打开页面，curl 却报告 35，并不能直接证明机场节点坏了。两个程序可能采用不同代理来源、TLS 后端和连接条件，先找出失败的是哪一次握手。
本文以 Windows PowerShell 调用 curl.exe 为例，只对你有权限的小型公开页面做检查，不携带账号、订阅链接或认证请求。
示意图：先找出握手发生在哪段连接，再核对错误和单项对照。
35 与 60 分别说明什么
curl 官方手册将 35 定义为 SSL/TLS 握手失败；60 则表示对端证书无法通过已知 CA 认证。这些是错误类别，不是足以唯一确定故障来源的诊断结果。
先保存错误原文和发生时间。不要仅凭数字，就把所有问题都按“缺少根证书”处理，也不要用 -k 作为通用修复。
第一步：确认正在使用哪个程序
在 PowerShell 中执行：
curl.exe --version
记录版本输出中实际的 TLS 后端及支持能力。不要把另一台电脑的结果当成本机配置，也不要因网上示例使用某个后端就临时混装多个程序。
核对命令是否明确写了 --proxy，以及当前代理地址的协议和端口是否与客户端说明一致。HTTP 代理、HTTPS 代理和 SOCKS 入口不能仅凭端口号互换名称。
第二步：在日志里找握手对象
可先对一个公开小页面运行如下诊断示例；这不是本机实测结果：
curl.exe -q --retry 0 --connect-timeout 10 --max-time 20 --verbose --output NUL https://example.com/
-q 放在前面用于排除默认配置文件干扰。这条命令没有指定本地代理，仍须核对环境变量或系统接管条件；若要对照某个代理，只使用客户端明确给出的入口另做一轮。
阅读日志时标记：连接到哪个主机、是否先连接代理、是否已经建立代理隧道、错误出现在哪里。使用 HTTPS 代理时还可能存在到代理本身的 TLS 连接，不能把每一条 TLS 提示都当成目标网站握手。
日志可能包含地址和请求信息。公开求助前遮盖内部域名、账号、Cookie、Authorization 和带令牌的 URL；不提交未经检查的完整日志。
第三步：只改变一个条件
| 对照条件 | 记录重点 |
|---|---|
| 同一目标、同一代理入口，换候选节点 | 握手阶段和错误是否改变 |
| 同一目标、同一程序，换可用网络 | 本地网络路径是否相关 |
| 同一设备，核对浏览器实际代理来源 | 是否原本在比较不同路径 |
不同时更换节点、DNS、证书库和 TLS 参数。没有官方兼容要求时，不随意降级 TLS 或放宽加密配置；单位管理的电脑应先核对管理要求。
怎样算排查有结果
你能说明实际程序、代理入口、失败握手对象和单项对照结果，就可以提交有用的记录。若握手恢复，继续确认 HTTPS 验证和原任务都成功；仅错误数字消失仍不足以证明完成使用。机场推荐中的客户端体验，也应说明所用环境而非泛称“所有设备都正常”。
来源与核验日期
官方资料核验日期：2026-10-08。本文提供自行操作与记录的方法，不代表本站对某家机场的实测结论。
评论