开代理后浏览器提示 HTTPS 证书错误?常见原因与 Clash 相关排查步骤

证书错误提示的几种类型与含义

浏览器给出的证书错误信息看起来种类繁多,但实际归纳起来只有几个方向:证书不受信任(NET::ERR_CERT_AUTHORITY_INVALID)、证书过期或尚未生效(NET::ERR_CERT_DATE_INVALID)、域名不匹配(NET::ERR_CERT_COMMON_NAME_INVALID),以及连接被劫持类的通用警告。这些提示本身是浏览器在做该做的事——TLS 握手阶段验证服务器证书链是否可信、是否在有效期内、是否与访问域名一致。开代理前不出现、开代理后频繁出现,基本可以确认问题出在本机的时间、DNS 解析路径或证书信任链上,而不是目标网站本身出了故障。

排查这类问题时先记录清楚:是所有网站都报错,还是只有部分网站;是所有节点都报错,还是切换节点后消失;是关闭代理立刻恢复,还是代理关闭后依旧存在。这三组对照能把问题范围迅速缩小到系统层、代理层还是本地软件层。

系统时间偏差导致的证书错误

TLS 证书验证会检查当前系统时间是否落在证书的有效期区间内。如果设备时间与真实时间偏差超过几分钟,证书校验就可能判定为"尚未生效"或"已过期",即便证书本身完全正常。这种情况在虚拟机、双系统、长期休眠后重新开机的设备上尤其常见,和是否使用代理没有直接关系,但往往在切换节点、重启客户端之后才被用户注意到,容易被误判为节点问题。

1. 检查系统时间是否自动同步

   Windows 在「设置 → 时间和语言」里确认「自动设置时间」已开启;macOS 在「系统设置 → 通用 → 日期与时间」里确认已勾选自动设置。

2. 手动核对时区

   时间同步开启但时区选错,同样会导致证书有效期判断偏差,尤其是刚更换过所在地区设置的设备。

3. 强制重新同步一次

   关闭自动同步再重新开启,或在系统时间服务里手动触发一次同步,让本机时间立即对齐网络时间服务器。

节点劫持与中间人风险

如果只有切换到某个特定节点才出现证书错误,而更换到其他节点立即恢复正常,需要认真对待这种信号。正常的代理转发不会介入 TLS 握手过程,客户端与目标网站之间建立的是端到端加密连接,中间的代理服务器只负责转发加密后的数据包,理论上没有能力也没有必要查看或替换证书。如果某个节点的出口在做流量层面的中间人干预——比如插入自签名证书来解密流量——浏览器会立刻报出证书不受信任的错误,因为呈现的证书签发者根本不在系统信任的根证书列表里。

这种情况多出现在来源不明、价格异常低廉的免费节点或未经审核的第三方分享节点上,正规机场的可信节点极少出现此类问题。排查方法很直接:

• 记录报错时使用的节点名称,切换到同一订阅下的其他节点观察是否复现。
• 查看错误详情里显示的证书颁发者(浏览器地址栏锁形图标 → 证书信息),如果颁发者是陌生的自建 CA 而不是网站原本使用的知名证书颁发机构,基本可以确认是节点层面的中间人行为。
• 确认问题节点后,在客户端里将其移出选用分组,更换来源可信的订阅。

TUN 模式下的 DNS 污染回退问题

TUN 模式接管系统全部网络流量,包括 DNS 查询请求。Clash Meta(mihomo)核心在 TUN 模式下通常会启用自身的 DNS 解析逻辑,优先走加密 DNS(如 DoH/DoT)并结合 fake-ip 或 redir-host 策略避免被本地网络的 DNS 劫持污染。但如果配置里的 DNS 设置存在遗漏——比如没有正确启用 enhanced-mode,或者 nameserver 列表里混入了容易被污染的普通 DNS 服务器——系统在 TUN 模式解析失败时可能悄悄回退到本机默认 DNS,而本机默认 DNS 如果处于被污染的网络环境下,解析出的 IP 会指向错误的服务器,该服务器自然拿不出目标域名匹配的合法证书,浏览器就会报出域名不匹配或证书不可信的错误。

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://doh.example.net/dns-query
    - https://1.1.1.1/dns-query
  fallback:
    - https://dns.google/dns-query
tun:
  enable: true
  stack: system
  dns-hijack:
    - any:53

核对配置时重点看三处:enhanced-mode 是否设为 fake-ip(或 redir-host,视使用场景而定)、nameserver 是否全部为加密 DNS 而非明文 udp:// 地址、dns-hijack 是否覆盖了 53 端口以强制所有 DNS 请求走客户端接管的解析逻辑。任意一处缺失都可能导致解析在特定网络环境下回退到不可信的路径。

本地抓包软件残留证书

另一类容易被忽略的来源,是本机曾经安装过的调试代理或抓包工具。这类工具为了解密 HTTPS 流量以供分析,通常会生成一张自签名根证书并要求用户手动安装到系统信任列表里,这样它才能在中间"合法地"充当一次中间人。如果卸载工具时没有同步删除该证书,或者证书已过期但仍留在信任列表中,后续使用代理时某些流量路径恰好经过残留的代理配置,就会触发证书告警,表现和真正的中间人劫持在浏览器提示上几乎一样,容易误判为节点问题。

1. 检查系统证书信任列表

   Windows 用「证书管理器」(certmgr.msc)查看「受信任的根证书颁发机构」;macOS 用「钥匙串访问」查看登录与系统证书,寻找带有调试工具名称的自签名条目。

2. 删除或禁用可疑证书

   确认某条证书来自已不再使用的调试工具后,将其从信任列表中移除或标记为不信任。

3. 检查系统级代理设置是否残留

   部分抓包工具会在系统网络设置里写入固定的代理地址和端口,卸载工具后需要手动清空这些残留配置,避免与 Clash 客户端的代理设置互相冲突。

排查步骤优先级清单

遇到证书报错时,按下面的顺序逐条排查,优先做成本最低、最容易排除的项:

1. 确认系统时间与时区

   这是最快能排除的一类,几十秒内就能确认或排除。

2. 关闭代理复测

   完全退出客户端后重新访问同一网站,判断问题是否与代理相关;若关闭后依然报错,说明问题在系统证书信任列表或本机 hosts 设置里,与 Clash 无关。

3. 切换节点复测

   若关闭代理后恢复正常,再逐个切换节点观察,定位是否为单一节点的劫持行为。

4. 核对 TUN 模式 DNS 配置

   确认 enhanced-mode、nameserver、dns-hijack 三项设置齐全且使用加密 DNS。

5. 检查系统证书信任列表里的可疑条目

   重点排查曾安装过的调试工具、抓包软件留下的自签名根证书。

6. 更新客户端与规则订阅

   确保 Clash Meta(mihomo)核心版本为较新版本,老版本在 TLS 库或 DNS 处理上的已知问题可能已在后续更新中修复。