开启 Clash 后网页提示 HTTPS 证书错误:原因与处理方式

先判断证书错误是否真的由 Clash 引起

HTTPS 证书错误不等于 Clash 客户端损坏。浏览器访问 HTTPS 网站时，会检查证书中的域名、有效期、签发机构和证书链。Clash 通常只负责转发加密流量，并不能读取已经建立的 TLS 会话内容。只要连接目标、系统时间和证书链正常，启用规则代理或 TUN 模式本身不会要求你额外安装网站证书。

问题更常出现在转发路径发生变化之后：代理节点把连接送到了错误服务器，DNS 返回了异常地址，局域网 HTTP 代理尝试解密流量，或者设备时间偏差导致有效期判断错误。开启 Clash 后刚好触发了这些路径，因此两件事在时间上相邻，但排查时仍要区分客户端、配置、节点和目标网站。

先做一组开关对照

1. 记录报错网站的完整域名，例如 accounts.example.com，不要只记首页名称。
2. 截取警告页中的错误代码、证书颁发者和有效期。Safari 可能显示“此连接非私人连接”，Chromium 内核浏览器常见代码包括 NET::ERR_CERT_DATE_INVALID、NET::ERR_CERT_COMMON_NAME_INVALID 和 NET::ERR_CERT_AUTHORITY_INVALID。
3. 关闭 Clash 的系统代理或 VPN 连接，完全退出并重新打开浏览器，再访问同一 HTTPS 地址。
4. 重新启用 Clash，把该域名临时设为 DIRECT。若直连正常而代理组报错，重点检查当前节点与上游线路。
5. 分别使用 Wi-Fi 和蜂窝网络测试。只有某个 Wi-Fi 报错时，应优先检查路由器、公共网络认证页和手动代理。

节点被劫持或上游返回错误证书

当规则把域名交给代理节点后，节点会代表设备连接目标服务器。如果节点出口被透明代理、恶意网关或异常上游接管，浏览器收到的证书可能属于另一个域名，也可能由设备不信任的机构签发。这类问题通常只跟随某个节点或某组线路出现。

典型表现

• 同一网站使用 DIRECT 正常，切到特定代理节点后出现域名不匹配。
• 证书“颁发给”字段与地址栏域名完全无关，例如访问账户域名却收到路由器管理页或陌生域名的证书。
• 切换同一订阅内的另一个地区节点后恢复，原节点重复测试仍然报错。
• HTTP 网站被重定向到广告页、认证页或陌生搜索页面，同时 HTTPS 网站出现证书异常。

Clash 的全局模式适合做节点对照，因为所有匹配流量都会进入当前代理组。测试完成后应恢复原来的规则模式。若只有一个节点异常，不需要删除整份订阅；先在代理组中排除该节点，再更新订阅观察服务方是否调整线路。

核对证书中的三个字段

1. Subject Alternative Name：应包含正在访问的完整域名，通配符 *.example.com 一般只能覆盖一层子域名。
2. Issuer：查看签发机构是否稳定。测试前后突然从公开 CA 变为公司网关、路由设备或陌生名称，需要提高警惕。
3. Validity：确认当前时间位于“生效时间”和“到期时间”之间。证书到期也可能是网站自身维护问题。

在 macOS 上可以用系统自带的命令查看远端握手结果。下面的 example.com 应替换为实际报错域名，端口 443 是标准 HTTPS 端口：

openssl s_client -connect example.com:443 -servername example.com -showcerts
curl -Iv https://example.com/

-servername 会发送 SNI，缺少它可能让同一服务器返回默认证书，从而产生误判。命令输出中的证书信息可以用于对比直连和代理测试，但不要把命令显示“握手成功”理解成网站内容一定安全，仍需核对域名与签发链。

系统时间偏差导致证书有效期判断失败

证书包含明确的生效时间与到期时间。iPhone 时间慢了几天，可能把新证书判断为“尚未生效”；时间快了几个月，则可能把正常证书判断为“已经过期”。这类故障往往不是单个网站，而是一批 HTTPS 服务、App 登录和系统账户同时失败。

iPhone 与 iPad 的检查路径

打开「设置」→「通用」→「日期与时间」，启用「自动设置」。随后检查时区是否与所在地一致。若开关变灰，可能受屏幕使用时间限制、运营商配置或设备管理策略控制，需要先处理对应限制。

• 时间偏差超过 5 分钟时，部分登录令牌和一次性验证码也可能同时失效。
• 修改时间后，关闭 Safari 的问题标签页并重新打开，避免继续复用旧连接。
• 若设备刚从长期关机状态恢复，先连接稳定网络，等待系统完成网络校时。
• 受管理的公司设备应联系管理员，不要自行移除单位下发的管理描述文件。

还要留意证书错误中的日期。如果浏览器显示证书刚过期，而系统日期准确，并且直连、不同节点、不同网络都得到同样结果，问题更可能在网站服务器。此时切换 Clash 设置无法修复，只能等待网站更新证书。

DNS 污染把域名送到错误服务器

HTTPS 连接开始前，设备需要把域名解析成 IP 地址。若 DNS 返回了错误地址，TLS 请求会到达另一台服务器，那台服务器自然可能返回不匹配的证书。此时浏览器常见提示是证书不适用于当前域名，而不是单纯的连接超时。

在 Clash 或 mihomo 配置中，DNS 行为可能来自 nameserver、fallback、nameserver-policy、Fake-IP 映射以及规则里的 DOMAIN、DOMAIN-SUFFIX。TUN 模式还可能接管系统 DNS 请求。排查时不要一次改动所有字段，否则无法知道是哪一项产生影响。

按最小变量检查 DNS

1. 先更新订阅和配置，确认 YAML 能正常加载，没有缩进或字段错误。
2. 将报错域名临时加入直连规则，并确认规则放在 MATCH 之前。
3. 清理客户端 DNS 缓存；若客户端没有独立入口，可断开系统 VPN 连接约 10 秒后重新连接。
4. 关闭再开启飞行模式，重新获取蜂窝网络与 DNS 状态。
5. 换用另一张 Wi-Fi 或蜂窝网络复测，区分本地路由器 DNS 与 Clash 内置 DNS。

临时规则可以写成下面这样。规则从上到下匹配，具体域名应放在宽泛规则之前：

rules:
  - DOMAIN,accounts.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,PROXY

如果直连规则仍使用 Clash 的 DNS 模块，测试结果只能说明出口方式改变，不能完全排除 DNS。更严格的对照需要同时比较系统 DNS 与配置 DNS。修改前保存原配置，测试结束后恢复，避免长期使用临时规则破坏原有分流。

Fake-IP 不是证书伪造

Fake-IP 模式会向本机应用返回保留地址，再由内核根据域名映射转发连接。应用看到的地址可能类似 198.18.0.0/15 范围，但 TLS 握手仍应使用原始域名完成。仅仅看到 Fake-IP 地址并不代表证书被替换。真正需要关注的是域名映射丢失、DNS 请求绕过内核，或目标应用不兼容 Fake-IP 后访问了错误目标。

若只有局域网设备、游戏主机或少数不兼容应用异常，可以针对域名设置 Fake-IP 过滤，而不是直接关闭整套 DNS。具体字段取决于 Clash Meta 或 mihomo 配置版本，编辑后应先确认配置校验通过，再启动 TUN。

HTTP 代理、抓包工具与安装证书的影响

普通 Clash 转发 HTTPS 时，通常只建立连接通道，不需要签发网站证书。只有抓包、调试、家长控制、企业网关或内容过滤工具主动进行 TLS 解密时，设备才会看到由本地或网关 CA 重新签发的证书。如果这张 CA 没有被系统信任，所有被解密的网站都可能出现“签发机构不受信任”。

检查 Wi-Fi 手动代理

在 iPhone 上打开「设置」→「无线局域网」→ 当前网络右侧的信息按钮 →「配置代理」。日常使用 Clash 的系统 VPN 或网络扩展时，这里通常应为「关闭」，除非你明确需要连接局域网代理。

常见本地 HTTP 或 mixed 监听端口包括 7890，SOCKS 端口常见为 7891，但配置可以修改。若 Wi-Fi 代理指向陌生局域网地址，例如 192.168.1.20:8080，先记录设置，再关闭代理复测。不要把一个设备上的 127.0.0.1 当作另一台电脑；回环地址始终表示当前设备自身。

检查描述文件与证书信任

1. 打开「设置」→「通用」→「VPN 与设备管理」，查看是否存在不认识的配置描述文件。
2. 打开「设置」→「通用」→「关于本机」→「证书信任设置」，核对已启用完全信任的根证书。
3. 不要为了消除警告而安装网页临时提供的 CA，也不要随意开启陌生根证书的完全信任。
4. 公司或学校管理的设备可能合法部署检查证书，应先向网络管理员确认名称、用途和有效期。

仅删除 Clash 配置通常不会移除其他工具安装的描述文件或根证书。反过来，随意删除企业证书可能导致公司 Wi-Fi、内部网站和邮件停止工作。处理证书前先确定来源，再决定是停用抓包工具、关闭手动代理，还是由管理员重新下发证书。

Clash 配置与规则的专项检查

证书错误也可能由规则选错出口造成。例如域名本应直连，却被一条过宽的 DOMAIN-SUFFIX 规则送入不稳定节点；或者订阅使用的策略组名称发生变化，规则落入最终的 MATCH 策略。此时应查看实际命中记录，而不是只看当前模式名称。

确认模式与策略组

• 规则模式：按规则决定直连、代理或拒绝，适合定位具体域名命中。
• 全局模式：统一使用当前全局节点，适合比较不同节点，但测试后应恢复。
• 直连模式：绕过代理节点，可用于判断异常是否跟随代理链。

进入客户端的连接记录，找到报错域名及其子域名。现代网页可能同时访问登录域名、静态资源域名和 API 域名，主页面直连并不代表所有请求都直连。重点核对命中的规则类型、策略组名称和最终节点。

避免端口与代理链混用

如果同时运行桌面抓包工具、浏览器代理扩展和 Clash，可能形成多层代理。比如浏览器扩展指向 127.0.0.1:8080，抓包工具再转发到 Clash 的 127.0.0.1:7890。其中任一层启用 HTTPS 解密，都可能改变证书。

排查阶段只保留一条路径：关闭浏览器代理扩展、停用抓包工具，再让系统代理或 TUN 直接交给 Clash。恢复时一次只开启一个组件，每次用同一域名测试。这样可以定位究竟是哪一层开始替换证书。

一份从低风险到高风险的处理顺序

1. 保存错误信息：记录域名、时间、错误代码、证书颁发者和当前节点。
2. 停止敏感输入：在原因明确前，不登录账号，不提交支付资料。
3. 校准系统时间：通过「设置」→「通用」→「日期与时间」启用自动设置。
4. 关闭 Clash 对照：退出浏览器后重新测试，排除旧连接复用。
5. 切换直连与节点：判断错误是否只跟随某个代理出口。
6. 更换网络：比较 Wi-Fi 与蜂窝网络，识别路由器或公共网络认证干扰。
7. 检查规则命中：确认域名实际使用的策略组与节点。
8. 检查 DNS：清理缓存，核对 Fake-IP、nameserver 与域名策略。
9. 检查手动代理：查看 Wi-Fi「配置代理」以及浏览器代理扩展。
10. 检查根证书：确认描述文件和完全信任证书的来源。

如果错误只出现在单个节点，并且证书域名明显不符，应停止使用该节点，把发生时间、目标域名和证书颁发者提交给订阅服务方。如果所有网络、所有设备都在同一网站看到完全相同的过期证书，通常应等待网站运营方修复。

若设备在移除陌生代理、关闭异常节点后仍对大量 HTTPS 网站报错，可以先备份重要数据，再考虑还原网络设置。iPhone 路径为「设置」→「通用」→「传输或还原 iPhone」→「还原」→「还原网络设置」。该操作会清除已保存的 Wi-Fi 网络、VPN 与部分网络参数，应放在常规检查之后，不要作为第一步。

常见问题