AI API 提示 SSL 证书验证失败怎么办？从系统时间到企业代理的排查步骤

调用中转 API 时出现 certificate verify failed、unable to get local issuer certificate 或 ERR_TLS_CERT_ALTNAME_INVALID，先不要更换模型、反复充值，也不要关闭证书验证。这些信息通常指向 HTTPS 连接的身份验证环节，与余额、模型权限不是同一层问题。

本文讲清如何在不发送 API Key 和用户对话的情况下收集线索，并区分本机信任库、企业代理和服务商证书配置问题。它不是对某家服务商的可用性评测；具体错误名称会随客户端和 TLS 库而变化。

一、先分清“证书错误”和“接口拒绝”

HTTPS 客户端会检查证书是否适用于目标域名、是否在有效期内，以及证书链能否建立到它信任的证书颁发机构（CA）。任一环节失败都可能中止连接。

提示或现象	可能方向	优先动作
certificate has expired / not yet valid	证书过期、尚未生效，或设备时间错误	核对系统日期和证书有效期
unable to get local issuer certificate	服务器证书链不完整，或客户端缺少所需 CA	比较运行环境和证书颁发者
self-signed certificate in certificate chain	企业 HTTPS 检查、私有 CA，或不可信证书链	向管理员核实，不能看到“自签名”就直接信任
ERR_TLS_CERT_ALTNAME_INVALID	URL 主机名与证书覆盖的名称不匹配	核对 API 域名，避免把域名替换成 IP
HTTP 401/403 的 JSON 响应	已收到 HTTP 层响应，需检查鉴权或权限	转入密钥及账户排查

从错误名不能单独判断责任方。例如“找不到颁发者”既可能是中转站漏配中间证书，也可能是容器里的 CA 包过旧。若你的后端已经收到请求、只是它连接上游失败，浏览器还可能显示后端包装后的 500/502，而不是原始 TLS 错误。

二、先做不带密钥的基础检查

第一步，核对设备日期、时间和时区，启用系统可信的自动校时。证书有效期按时间判断，不能为了绕过过期错误而把机器日期改回过去。

第二步，从已确认的服务商官方文档核对 API 主机名。官网、充值后台和 API 入口可能不同；不要使用聊天群里未经核实的“修复域名”。复制地址时检查是否多了空格、错拼字母或变成了裸 IP。

第三步，在出现问题的环境中检查 HTTPS 连接，而不只是自己的浏览器。可使用客户端自带的网络诊断，或让开发人员进行一次不带 Authorization、Cookie、正文和敏感查询参数的 HTTPS 请求。使用已知安全的诊断地址，保留证书验证，不自动跟随到陌生域名。

在正确 API 主机上得到 401、404 或 405，不代表模型可用，但通常意味着这次连接已经走到 HTTP 层。相反，TLS 验证失败时可能根本没有 HTTP 状态码。不要用接口是否返回 200 作为唯一判断。

三、用环境对照定位范围

记录客户端版本、操作系统、实际 API 主机名和完整错误码；不记录密钥。随后在获得授权的网络中做有限对照，每次只改变一个因素。

对照结果	应重点检查
浏览器正常，同电脑的程序失败	两者使用的信任库、代理和运行时版本是否不同
本机正常，部署容器失败	容器时间、CA 包、运行时及出站代理
家庭网络正常，公司网络失败	企业 HTTPS 检查或出站策略；联系管理员，不绕过企业控制
多个独立环境都提示相同主机名不匹配或过期	保存证据，联系服务商检查证书部署

这些是定位线索，并非结论。浏览器可能拥有与程序不同的证书缓存或信任配置，不能据此认定服务商或本机一定没问题。

四、分别处理三类常见原因

本机或容器的信任库问题

通过操作系统或运行环境的正式更新渠道更新 CA 包和受支持的客户端版本。容器镜像精简后可能没有完整 CA 配置，应由维护者检查构建步骤，而不是从不明网站下载根证书合集。

curl 使用哪个信任库取决于构建方式和 TLS 后端。例如使用 Schannel 的构建通常使用 Windows 原生证书存储，其他构建可能使用证书文件。因此“Windows 已经信任”不一定等于所有程序都信任，检查实际工具版本和后端才有意义。

企业代理或私有 CA

如果管理员确认网络采用 HTTPS 检查，应通过企业正式渠道取得 CA 证书，并用独立可信渠道核对指纹和用途。安装一个根 CA 相当于扩展信任范围，不能把服务商页面临时弹出的证书一键当作可信根。

以 Node.js 为例，NODE_EXTRA_CA_CERTS 可以指向包含受信任额外 CA 的 PEM 文件。它在进程启动时读取，修改后需要重启相应服务；运行中只改环境变量不会改变当前进程的信任集合。若 SDK 显式传入了 ca 选项，默认 CA 和额外 CA 的行为也会不同，需要查看 SDK 配置。这里只说明配置边界，不要求普通用户自行安装企业证书。

服务商的域名、有效期或证书链问题

域名不匹配时，先恢复文档中正确的主机名，不要强制修改 Host 头或关掉主机名校验。确认是服务商证书过期、链不完整或新域名未正确部署后，应由服务商修复。客户端盲目增加不明 CA，无法可靠解决这些问题。

重要任务可切换到已经验证过的独立备用服务，而不是临时信任陌生“镜像站”。切换前确认模型 ID、接口格式和数据处理政策，并核对原调用是否曾经过其他自动重试路径。

五、不要把关闭验证当作长期修复

curl -k、Python 的 verify=False 或 Node.js 的 NODE_TLS_REJECT_UNAUTHORIZED=0 都会削弱或关闭证书验证。它们不会修复证书链，只会让程序失去关键的身份确认，可能把 Key 和业务内容交给错误的连接对端。

也不要从 HTTPS 改用 HTTP 来让报错消失。排查资料若让你长期保留这些设置，先停止照搬，在正式配置中恢复验证。对于普通接入与生产环境，本教程不需要使用这些开关。

如果此前曾关闭验证并发送敏感信息，应结合实际网络和日志评估风险；如有密钥被不可信对端接触的可能，撤销并更换相关 Key，核对异常调用。不应仅凭出现一次证书错误就断言已经泄露。

六、修复后的验收与客服材料

先检查环境变量、代码和 SDK 参数，确认没有遗留关闭验证的设置。然后在原来出错的运行环境进行不带密钥的 HTTPS 检查。通过后，再用测试 Key、允许的模型和一条不含敏感信息的短问题验证完整调用。这一步可能计费，应使用自己的小额测试预算。

验证模型返回、账户日志和重启后的行为；不要只在浏览器成功一次就结束。若 HTTPS 已恢复、网页仍提示跨域错误，按 CORS 排查教程继续定位，不要再次修改证书信任。Key 的保存和撤销可参考 API Key 安全指南。

联系客服时提供：发生时间与时区、API 主机名、系统和客户端版本、原始错误码、证书有效期与颁发者、是否使用企业代理、不同环境的对照结果。分享证书截图前隐藏内部域名等不宜公开的信息，不发送私钥、Authorization、Cookie、完整请求正文或未经脱敏的调试日志。

参考资料（2026-10-08 查阅）：curl 官方：TLS Certificate Verification、Node.js 官方：NODE_EXTRA_CA_CERTS。信任库与代理行为还取决于所用版本和 SDK，不把某个运行时的配置直接套用到所有客户端。