机场客户端提示证书错误怎么办？时间、域名与信任链排查

机场客户端提示证书错误，先看报错发生在节点连接还是网页连接，再检查设备时间、证书对应的名称和信任来源。不要看到 TLS 字样就开启“跳过证书验证”：连接超时、协议不匹配和证书验证失败，需要的处理并不相同。

本文适合使用带 TLS 的节点时出现验证错误，或连接代理后浏览器出现证书提示的情况。字段以 Mihomo 为例，不同客户端的入口可能不同。

作者：小六｜资料核对日期：2026年10月5日

先分清是哪一段连接报错

客户端连接节点，与浏览器访问 HTTPS 网站，是不同的连接。它们可能各自验证不同的证书，不能只凭“开代理后出现”就认定同一处配置出了问题。

只把“无法连接”转述成“证书坏了”，会丢掉最关键的线索。求助前保存准确错误，但不要公开订阅地址、令牌或节点认证信息。

证书有有效期。设备时间明显提前或落后，可能把正常证书判断成尚未生效或已经过期。Mozilla 的时间相关证书错误说明列出了这种情况，也说明正确的设备时间不能修复服务器自身过期的证书。

检查当前日期、时间与时区，并与可信时间来源对照。Windows 可在日期和时间设置中检查自动设置与同步状态。不要只改显示格式，或为了绕过过期提示故意把时钟调回过去。

修正后重新发起连接。如果时间已经正确，只有某个节点或网站仍报有效期错误，应继续核对远端证书，而不是反复同步电脑时间。

手动改节点地址时，容易把“连接到哪里”和“TLS 使用什么名称”混在一起。把服务器域名替换成 IP，并不代表证书名称也能随意换成这个 IP。

Mihomo 的 sni 或 servername 用于指定 TLS 服务器名称，具体字段取决于节点协议；name-cert-verify 则用于调整证书名称验证目标，不会同时修改 SNI。见官方 TLS 配置文档。

先对照可信的订阅原始配置和服务方说明，看是否手动改过服务器地址或相关名称。不要把其他节点的域名拿来填，也不要根据一个能打开的网站猜应该填写什么。

如果订阅更新后开始报错，记录更新前后的变化并联系维护方核对。自己重新命名节点的显示名称，不能修复 TLS 名称不匹配。

确认浏览器地址栏中的目标，以及提示里的证书名称。若网页本身的名称与证书不匹配，调整节点显示名没有帮助。特别是访问设备的 IP 管理入口时，需要确认设备支持的访问名称。

只比较同一目标、同一访问方式的结果，避免把网站域名访问和另一个 IP 入口当成完全相同的测试。

同一网站在浏览器能打开，在另一个工具里却出现“不受信任”的提示，不一定是证书突然改变，也可能是工具使用的证书来源不同。

例如，curl 官方说明：使用 Schannel 的构建通常使用 Windows 原生证书存储，其他 TLS 后端可能使用文件形式的 CA 来源。见 curl 证书验证说明。这个例子说明需要核对具体工具，不能假定所有客户端都使用同一套信任设置。

检查客户端和系统是否使用可信渠道提供的更新，确认有没有自定义 CA 文件、组织管理设置或曾经安装的证书。不要把网上下载的根证书当成通用修复包，也不要为了让提示消失而导入来源不明的证书。

工作设备如果由组织统一管理，应按其支持流程核对证书要求，避免自行替换管理配置。个人设备则先保留错误记录，判断问题是单个目标还是多个目标都出现。

Mihomo 的 skip-cert-verify 会跳过相关 TLS 证书验证。它改变了验证条件，不会修好过期证书、错误名称或缺失的信任链，字段含义见前面的官方 TLS 文档。

节点上的这一项也不能当作浏览器网站证书提示的统一开关。即使某次修改后连接成功，仍然需要找到原来的验证错误来自哪里。

为了让排查可比较，每次只核对一项：时间是否正确、名称是否对应、信任来源是否合适。不要同时换节点、改名称、导入证书再关验证，否则很难判断哪一步影响了结果。

整理系统与客户端版本、报错原文、出现位置、首次发生时间，以及是否只有一个目标异常。可以提供脱敏后的错误类型和字段名称，不需要提供订阅内容。

订阅信息怎样保管，可参考本站的订阅链接安全说明；如果只是超时或拒绝连接，先按机场连接排查顺序确认故障层次。

想交流证书名称、时间或客户端信任来源的排查，可以带上脱敏后的错误记录：Telegram 联系我