开启 Clash 后浏览器提示 HTTPS 证书错误的原因分析与解决方法

代理为什么会牵扯到证书校验

HTTPS 连接的证书校验发生在 TLS 握手阶段,由客户端(浏览器或系统)完成,与是否使用代理本身没有直接因果关系——代理只负责把数据包送到目标服务器,证书是服务器返回、客户端验证的东西。多数情况下,Clash 或 Mihomo 内核工作在纯转发模式:它把 TCP/UDP 流量按规则分流到对应节点,数据在传输层原样透传,不拆解、不重新签发证书,浏览器看到的仍然是网站服务器本身的证书链。这种模式下开启代理导致的证书报错,几乎全部是"代理改变了连接路径,暴露出原本被掩盖的其他问题",而不是代理本身伪造了证书。

但也存在例外:一部分客户端提供"HTTP 抓包/MITM 解密"功能,用于查看请求详情或做规则调试,这类功能会启用一张本地生成的根证书,代理进程用它对被解密的连接重新签发证书,再把内容转发出去。如果这个开关处于打开状态,而根证书没有被系统或浏览器信任,证书链就会在校验阶段直接失败,报错信息通常包含"不受信任的颁发者""证书由未知机构签发"一类描述。这是唯一一种由代理软件自身证书机制直接导致报错的情形,区分它是排查的第一步。

排查前先确认的三件事

在深入具体场景前,先按顺序核对以下三点,能快速缩小问题范围。

系统时间与时区是否准确
TLS 证书校验会比对当前系统时间与证书的有效期区间,系统时间早于证书生效时间或晚于过期时间,都会直接判定为证书无效,与代理无关。开启自动同步网络时间,或手动核对时间与时区,是最容易被忽略却最常见的原因之一。
代理是系统级还是仅浏览器级
系统代理模式下,所有应用的流量都会经过代理规则判断;仅浏览器扩展代理时,其他应用不受影响。如果只在浏览器里出现证书报错,而系统其他程序访问同一站点正常,问题范围应缩小到浏览器扩展或浏览器自身的代理设置,而不是 Clash 客户端。
是否刚刚切换过节点或订阅
刚导入新订阅或切换到新节点后出现证书报错,要考虑该节点服务端是否存在劫持、篡改证书或强制跳转的行为,这类问题通常只出现在特定节点上,更换到其他节点测试同一网站即可确认。

常见场景逐一分析

场景一:公共网络的门户劫持(Captive Portal)

机场、酒店、校园等场所的公共 Wi-Fi 常见"先登录再上网"的门户页机制,网络层会在你完成认证前拦截所有 HTTPS 请求并返回自己的登录页证书,与目标网站的真实证书完全不匹配,浏览器判定证书不受信任。这种情况下,先断开代理,完成门户页登录流程,确认可以正常访问任意网站后再重新开启代理,报错通常随之消失。如果开启代理后完全无法弹出登录页,可以先临时关闭代理完成认证,再打开代理正常使用。

场景二:MITM 解密开关被意外开启

如前文所述,若客户端的抓包/重写功能被启用,而对应根证书未安装到系统信任列表或浏览器信任列表中,几乎每个 HTTPS 站点都会报错,现象是"批量性"的,而不是针对某一两个网站。处理方式是在客户端设置里找到抓包或重写相关选项并关闭,或者按客户端说明安装并信任对应根证书。日常仅用于分流代理而不需要查看请求内容的场景,保持该功能关闭是更省心的做法。

场景三:证书链不完整

部分自建代理节点或使用了自签证书的服务在中间证书配置上有缺失,浏览器能验证到叶子证书但补不齐到根证书的完整链条,报错信息常见"未知颁发者"或"证书链不完整"。这类问题出在服务端配置,与本地 Clash 客户端设置无关,能做的排查是换用其他节点访问同一网站进行对比,如果只有某个特定节点触发,说明是该节点自身的证书配置问题,建议切换到其他线路或联系订阅提供方。

场景四:DNS 污染或劫持导致连到错误的服务器

如果域名解析被劫持到一个伪冒地址,该地址返回的证书自然与目标网站的真实证书不匹配。判断方法是在开启代理、且规则设置为"远程解析"(即由代理服务器完成 DNS 查询而非本机 DNS)的前提下重新访问,如果报错消失,基本可以确认是本地网络的 DNS 环境存在问题;如果依然报错,再回到场景一到三继续排查。

注意 NOTICE 浏览器提示的证书错误页通常会附带"继续访问(不安全)"选项,但在未确认原因前不建议点击继续,尤其是涉及登录、支付类站点,该选项应仅用于排查测试,不应作为日常访问方式。

分平台的具体处理步骤

确认问题类型后,可以按以下平台步骤逐项操作。

Windows / macOS

核对系统时间
打开系统设置中的日期和时间选项,确认"自动设置时间"已开启,时区与实际所在地一致。
关闭客户端的解密相关功能
在 Clash 或 Mihomo 客户端的连接/脚本设置中查找抓包、重写或 MITM 相关开关,确认处于关闭状态,除非确实需要调试请求内容。
切换节点做对比测试
在同一浏览器标签下切换到另一个可用节点,重新访问出错的网站,判断问题是否随节点变化。

Android / iOS

检查系统代理与 VPN 模式的冲突
移动端客户端多通过本地 VPN 接口接管流量,若同时安装了其他代理类应用,两者可能互相干扰导致连接异常,建议排查时只保留一个代理应用处于运行状态。
确认自动时间同步已开启
移动设备的系统设置中同样存在"自动设置日期和时间"选项,关闭后容易出现时间漂移。
重启应用或重新导入订阅
如果切换节点仍无效,尝试重启客户端应用,或删除后重新导入订阅链接,排除本地缓存配置异常的可能。

TUN 模式下的证书报错要单独看待

TUN 模式在系统网络层创建一个虚拟网卡,接管全局流量(包括绕过应用层代理设置的程序),这种接管方式本身不涉及证书重签发,原理上不会引入额外的证书问题。但因为 TUN 模式下流量路径变化更彻底,原本被系统代理规则忽略的应用(例如某些后台服务、系统组件的联网请求)也会被纳入代理链路,如果这些请求命中了本节点范围内配置不完整的分流规则,同样可能暴露出前文提到的证书链或 DNS 解析问题。排查方法与前文一致,可以先临时关闭 TUN 模式,恢复到系统代理模式测试同一站点,借此判断报错是否与流量接管范围扩大有关。

什么情况下问题出在规则配置而非证书本身

有一类现象容易被误判为证书错误:某个网站被规则错误地分流到了不适合访问该站点的节点,对方服务器返回了非预期的响应内容(例如运营商的拦截页面),浏览器在解析这个非预期响应时同样会给出连接不安全的提示,但根源是路由规则,不是证书校验逻辑本身出了问题。这种情况下,检查订阅或本地配置文件中该域名命中的策略组,确认对应节点是否可用、策略组测速结果是否正常,往往比纠结证书细节更快定位问题。规则配置的语法与字段说明,可参考完整文档中的规则段落说明。

现象	可能原因	处理方向
几乎所有网站同时报错	系统时间偏差 / MITM 解密开关开启	校准时间、关闭抓包功能
仅公共 Wi-Fi 下出现	门户页劫持	先完成门户认证再开代理
仅特定网站或特定节点出现	节点证书链配置缺失	切换节点对比测试
切换远程解析后消失	本地 DNS 被污染或劫持	启用代理侧 DNS 解析
关闭 TUN 后消失	流量接管范围内的规则命中问题	检查该域名对应的分流规则

整体上,HTTPS 证书报错的排查思路应该是先做减法:关闭代理确认问题是否消失,关闭 MITM 相关功能确认是否与解密有关,切换节点确认是否与特定线路有关,切换 DNS 解析方式确认是否与本地网络污染有关。每一步都能排除一类原因,通常在四步之内就能锁定问题所在,不需要逐条猜测。