开启 Clash 后网页提示证书错误：系统时间、中间人与 TUN 的排查顺序

先保留报错，再按时间、节点、TUN 排查

先不要点“继续访问”，也不要安装对方临时发来的根证书。HTTPS 证书错误表示浏览器无法确认当前连接对象的身份，不等同于“代理速度慢”。正常的 Clash 代理转发不会要求浏览器放弃证书验证；mihomo 的 TUN 接管也不等于解密 HTTPS。

如果正在打开邮箱、支付或管理后台，先停止输入密码。保留错误代码、访问域名、证书签发者和发生时间，再做对照。本文的端口与域名均用于演示检查方法，不代表客户端默认配置或本站实测结果。

检查系统日期、时区和证书有效期，排除本机时钟异常。
确认真正退出代理后的结果，再比较两个节点。
查看证书域名和签发者，判断是否存在门户页或 HTTPS 检查。
只切换 TUN 一个变量，核对 DNS、路由与安全软件。
使用命令行复核，并根据证据决定回退哪一项设置。

辨认错误代码：证书错误不等于 TLS 握手失败

Chromium 系浏览器常用 NET::ERR_CERT_ 前缀。Firefox 的文字和代码不同，但检查对象仍是时间、证书链、域名和信任来源。先抄下完整代码，不要只记“无法建立安全连接”。

错误示例	主要含义	优先检查
`NET::ERR_CERT_DATE_INVALID`	本机判断证书尚未生效或已过期	系统时间、证书起止日期
`NET::ERR_CERT_AUTHORITY_INVALID`	证书链无法连接到受信任的根	签发者、链是否完整、HTTPS 检查
`NET::ERR_CERT_COMMON_NAME_INVALID`	证书不适用于当前主机名	证书 SAN、门户重定向、DNS 与 hosts
`NET::ERR_CERT_REVOKED`	证书被判断为已吊销	证书对象、站点或安全产品状态
`ERR_SSL_PROTOCOL_ERROR`	TLS 协议交互异常，不一定拿到了有效证书	代理端口、协议、链路设备与服务端

判断范围也很重要：只有一个域名报错，优先怀疑该站点或针对它的规则；多个互不相关的 HTTPS 网站同时报错，优先检查本机时间、信任库和共同经过的网络设备。两种情况都不能仅凭“刚打开 Clash”就认定内核损坏。

第一步：检查系统时间与证书有效期

让系统自动同步，再重试同一网址

Windows 11 可打开「设置」→「时间和语言」→「日期和时间」，检查“自动设置时间”，并使用“立即同步”。macOS 可打开「系统设置」→「通用」→「日期与时间」，检查自动设置日期与时间的状态。组织管理的设备若限制修改，应联系管理员。

先看年份、月份和日期，休眠恢复或主板电池异常可能让时钟跳回过去。
再看时区。显示的本地时间正确不代表 UTC 时间一定正确，不要只靠肉眼看时钟。
打开浏览器提供的证书查看器，记录“生效时间”和“到期时间”，与系统时间比较。

例如，证书到期日早于当前日期，只有这一个站点报错，就应由站点维护方更新证书；若系统日期落在证书生效日之前，多个网站可能一起失败。不要把时钟改到过去来迁就过期证书，那会影响登录令牌、软件更新和其他连接。

Linux 用命令确认同步状态

timedatectl status
date -u

在使用 systemd 的发行版上，第一条可查看时间、时区和同步状态；第二条显示 UTC 时间。若启用了时间同步却长期不同步，应检查当前使用的时间服务及其网络访问。修正后重新打开目标网页，再判断是否还需调整代理。

第二步：做直连与节点对照，确认故障范围

“关闭系统代理”不一定是直连：TUN 仍可能接管流量，另一个 VPN 也可能保留路由。先保存当前模式、节点和 DNS 设置，再退出客户端，确认 TUN 已关闭且系统代理已恢复。不要为了测试而访问不熟悉的登录页面。

测试条件	观察内容	可支持的判断
客户端退出，其他 VPN 关闭	相同网址是否仍报同一代码	仍报错时先查站点、本机或当前网络
系统代理开启，TUN 关闭，节点 A	命中规则、实际出口、证书签发者	建立普通代理转发的基线
同一模式，切换节点 B	错误是否消失、证书是否变化	只随节点变化时重点检查节点链路
回到节点 A，仅开启 TUN	错误是否只在 TUN 下出现	转向路由、DNS 与驱动共存排查

切节点后要在客户端“连接”面板确认新连接确实走了该节点。策略组可能自动选择其他成员，规则也可能把目标域名交给 DIRECT。关闭出错标签页后重新打开，必要时重启浏览器，避免复用旧连接干扰比较。

第三步：看证书签发者，区分门户页与中间人

普通代理转发不需要替换网站证书

浏览器通过 HTTP CONNECT、SOCKS 或 TUN 发送流量时，目标网站的 TLS 通常仍由浏览器与网站完成。Clash 或 mihomo 不是因为开启代理就必须给所有网站重新签证书。如果多个不同网站突然显示同一家本地安全产品或企业名称作为签发者，应检查 HTTPS 检查功能与设备管理策略。

企业网关可能按组织政策解密检查 HTTPS；部分安全软件也提供类似功能。若其根证书未被当前浏览器信任，就可能出现证书链错误。Firefox 与 Chromium 在证书信任设置、平台集成和企业策略上存在差异，因此“另一个浏览器能打开”只能缩小范围，不能证明链路一定正常。

域名匹配：查看证书的主题备用名称（SAN）是否包含访问的主机名。通配符 *.example.com 不覆盖根域 example.com，也不覆盖多层子域。
签发者异常：若变成路由器、陌生组织或本地产品名称，先确认来源，不要直接添加信任。
证书发生变化：CDN 可按地区提供不同证书，证书不同本身不等于劫持；还要看域名匹配、有效期和可信链。

公共 Wi-Fi 先完成网络认证

酒店或机场网络可能尚未完成门户认证。优先使用系统弹出的网络登录窗口，核对网络名称；必要时访问已知的普通 HTTP 页面触发门户。不要在 HTTPS 证书警告页输入账号，也不要为通过门户而安装陌生证书。完成认证后重新测试，若证书仍不匹配，应停止使用该链路处理敏感业务。

如果只有一个节点持续提供不匹配的证书，而其他节点正常，先停用该节点并向服务提供方提交时间、域名和证书信息。节点故障、出口 DNS 异常或转发链路干预都值得检查，但仅凭一次错误不能断言具体是哪一方实施了劫持。

第四步：只在 TUN 下报错，检查 DNS 与路由

TUN 是把系统流量送入虚拟网络接口的方式，本身不签发网站证书。启用后才报错，通常说明原先没有经过代理的流量被接管了，或者 DNS、路由、安全产品的处理路径发生变化。先保持同一个节点和规则模式，仅关闭 TUN，比较结果。

fake-ip 地址不是网站返回的证书

在常见 fake-ip 配置中，内核可能把域名映射到 198.18.0.0/16 范围内的地址，再按映射处理连接；具体范围以生效配置为准。看到此类 DNS 结果不代表证书被替换。真正需要检查的是：该连接有没有进入负责这份映射的内核，以及目标域名最终被送到了哪里。

打开连接记录，搜索目标域名，记录命中的规则、策略组和出口。
查看生效配置中的 dns.enhanced-mode、tun.dns-hijack 与路由相关设置，不只看订阅原文件。图形客户端可能应用了覆写。
核对浏览器“安全 DNS”设置。浏览器自带 DoH 与系统 DNS 可能走不同路径，改变此设置时记录原值。
检查本机 hosts 是否把域名指向旧地址。Windows 常见位置为 C:\Windows\System32\drivers\etc\hosts，Linux 和 macOS 为 /etc/hosts。
逐一停止其他 VPN 或网络过滤工具进行对照。企业设备先征求管理员同意，不要同时卸载多个组件。

DNS 指向错误服务器时，浏览器仍可能完成 TCP 连接，但收到另一域名的证书，最终报域名不匹配。反过来，路由冲突更常表现为超时或连接重置，不应把所有 TUN 异常都叫作证书错误。只有错误代码与证书详情相符，才继续沿证书方向排查。

第五步：用 curl 对照浏览器，避免误判端口

下面以本地 HTTP 或混合代理监听 127.0.0.1:7890 为示例。先在客户端监听设置或生效配置里确认实际端口；7890 不是所有客户端的固定值。网站使用 HTTPS，并不意味着本地代理地址要写成 https://127.0.0.1:7890。

Windows 的两组请求

curl.exe -v --noproxy "*" --connect-timeout 10 --max-time 30 https://example.com/
curl.exe -v --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 https://example.com/

第一条绕过 curl 的显式代理设置，第二条强制使用本地 HTTP 代理，并清空不走代理的名单。测试实际故障时，把示例域名换成出错网站的公开首页，不附带登录令牌。macOS 或 Linux 可把 curl.exe 换成 curl。

退出 TUN 后再测直连：--noproxy "*" 不能绕过操作系统层面的 TUN 路由。
分清 CONNECT 与 TLS：出现 200 Connection established 只说明代理隧道建立，不代表网站证书已验证成功。
留意返回错误：curl 的错误 60 通常指向对端证书验证失败；错误 7 或 28 更偏向连接失败或超时。
不要加跳过验证参数：本次目的是观察验证为什么失败，不是让请求强行返回页面。

curl 与浏览器使用的 TLS 后端和信任来源可能不同，因此两者结果不一致时，应继续核对证书签发者、系统代理、浏览器扩展和管理策略，而不是认定某一个结果必然更可靠。详细日志可能包含目标地址或认证信息，对外提交前要脱敏。

恢复与复测：每次只改一项

找到相关变量后，先恢复其他测试设置，再单独保留必要修复。比如校准时钟后问题消失，就没有必要继续改 DNS；只有某节点异常，就先停用该节点；只在企业 HTTPS 检查下失败，则由管理员核对证书部署与策略。

用原来出错的网址复测，确认不再出现相同证书错误。
再测试两个互不相关的 HTTPS 网站，检查是否存在全局信任问题。
在连接面板确认目标流量的实际出口，避免误把回到直连当作代理修复。
恢复临时关闭的安全功能和 DNS 设置，逐项确认结果没有反复。
保留错误代码、节点名称、内核名称、TUN 状态和修复步骤，便于后续复现。

需要提交反馈时，可附上客户端实际版本、内核版本、操作系统版本和脱敏日志，不要公开订阅地址、代理密码或完整私有配置。客户端名称和内核名称应分别记录：图形界面相似，不代表使用相同的 Clash 或 mihomo 内核。

后续配置可参考使用手册的 DNS 说明与代理模式说明。判断的核心始终是三件事：当前时间是否正确、证书究竟签给了谁、这次连接实际经过了哪条路径。