Roxi先保存错误原文，分清是哪一段失败
| 错误线索 | 常见检查方向 |
|---|---|
| 证书过期或尚未生效 | 系统时间、时区及服务端证书有效期 |
| 主机名不匹配 | URL 域名、证书 SAN、是否用了 IP 代替域名 |
| unknown CA / unable to get local issuer | 应用信任库、缺失中间证书或受管理网络 |
| TLS handshake timeout / reset | 握手链路、代理或服务端；不一定是证书验证 |
| HTTPS 代理自身的证书错误 | 连接代理服务器这一层，不是目标网站那一层 |
浏览器的错误页通常能查看证书详情；记录目标主机名、颁发者和有效期。只需脱敏摘要，不要公开 Cookie、Authorization 请求头或私有服务域名。curl、Git 与浏览器使用的 TLS 实现和信任库可能不同，一边成功不能证明另一边必然应该成功。
第一步：核对系统时间和准确网址
- 开启系统可靠的自动时间同步，核对日期与时区。时区显示不同不一定改变实际系统时间，应检查时间是否真的偏离。
- 从可信书签或服务官方入口确认域名，不把拼写相近的域名当作原站。证书应覆盖实际访问的主机名。
- 不要把 HTTPS 地址里的域名直接换成解析出的 IP。这样可能改变主机名验证、SNI 和虚拟主机选择，造成新的错误。
第二步：同一 URL 做有边界的网络对照
curl --proxy http://127.0.0.1:7890 --connect-timeout 8 --max-time 20 -I https://example.com
curl --noproxy '*' --connect-timeout 8 --max-time 20 -I https://example.com
# Windows 使用 curl.exe。两条命令都保留证书验证。对照时需知道 --noproxy 只绕过 curl 显式代理，不能绕过 TUN、路由器或企业网关。若要比较真正直连路径，先正常关闭自己控制的接管，并记录原配置。再换另一张可信网络复测；公共 Wi-Fi 可能需先完成认证，但不要在可疑证书页面继续输入账号。
若只有某一个出口出现异常证书，停止通过该路径提交敏感信息，并保存脱敏证据核实。正常的 HTTP CONNECT 隧道并不要求你为普通浏览安装一个陌生根证书；声称“必须装证书才能用”的场景应先确认具体产品与管理方。
第三步：区分服务端链错误与本机信任库问题
同一网站在多个更新过的设备、不同网络均报过期或主机名错误时，向站点维护方报告，等待服务端修正。只有某个老应用失败时，核对应用版本、TLS 后端与 CA 来源。curl 官方文档说明，不同构建可能使用 Windows 原生存储、Apple 信任服务或文件型 CA 存储，不能盲目复制一份证书文件到所有环境。
- 优先通过系统和应用官方更新修复过旧的根证书库，记录更新前版本。
- 在企业或学校明确管理的 TLS 检查环境中，向管理员核验根证书来源、指纹和适用范围，使用其正式安装流程。
- 确需为单个工具指定受信任 CA 时，使用该工具支持的限定配置，如 curl --cacert 指向经核验的 CA 文件。它仍应验证目标主机名，不是通用绕过手段。
这些开关不能作为长期修复
curl -k / --insecure、Git 的 http.sslVerify=false，以及浏览器忽略证书错误都会削弱身份验证。教程不需要你执行这些设置。若以前已经为排障关闭过验证，先查明设置来自哪个用户、仓库或系统作用域，再移除对应覆盖；不要盲目改动受管理设备的全局策略。
验收与恢复
在保留完整证书验证的条件下，复测原 URL 和实际登录、下载操作。确认临时 CA 配置、测试代理和错误的持久变量已经撤销。只有证书链、域名与时间都恢复正常，原本失败的工具也能完成操作，才算真正修复。