开启代理后网页提示证书错误：HTTPS 证书报错原因逐项分析

先识别错误：证书验证失败与连接失败不同

开启 Clash 后出现“您的连接不是私密连接”，并不等于客户端在修改网页证书。通常的 HTTP CONNECT、SOCKS 或 TUN 转发不会替目标网站签发证书；浏览器仍会验证网站的证书链、有效期和域名。代理改变的是连接路径，路径上的 DNS、出口、认证网关或抓包程序，可能让浏览器接收到另一张证书。

先记下地址栏里的完整主机名与错误代码，再打开警告页提供的证书查看入口。不同浏览器入口位置不同，重点记录证书的“颁发者”“有效期”和“主题备用名称”（SAN）。不要只看证书的显示名称：域名是否匹配，应以 SAN 为主要依据。

系统时间与信任库：先排除本机验证条件

检查日期、时间与时区

证书有明确的生效时间和过期时间。电脑休眠恢复、主板电池异常或手动改时后，系统时间可能偏离真实时间。若多个无关站点都出现日期错误，先查本机，不要连续更换节点。

1. Windows 11 打开「设置」→「时间和语言」→「日期和时间」，检查“自动设置时间”和时区，再使用“立即同步”。
2. macOS 打开「系统设置」→「通用」→「日期与时间」，核对自动设置日期与时间；受管理设备可能需要管理员权限。
3. 重新打开浏览器并访问原域名。若只剩一个站点报错，查看该站点证书是否确实过期。

Windows 可用以下命令查看当前时间与 Windows 时间服务状态。第二条命令报服务未运行，表示时间同步状态尚不能由它确认，并不代表 HTTPS 本身故障。

Get-Date
w32tm /query /status

区分缺失证书链与过旧信任库

旧系统、长期未更新的浏览器，以及网站漏发中间证书，都可能产生信任链错误。先安装系统和浏览器的正常更新，再比较同一设备上的另一款浏览器。浏览器使用的根证书机制可能不同，因此“另一个浏览器能打开”只是线索，不是服务端证书一定正确的证明。

若同一网站在多个设备、多个网络都报错，而其他网站正常，更可能需要网站管理员修复证书部署。不要从搜索结果或错误网页下载一张来源不明的证书导入“受信任的根证书颁发机构”。

中间人抓包与 HTTPS 检查：核对证书颁发者

Fiddler、Charles、mitmproxy 等抓包工具启用 HTTPS 解密时，会用本地受信任的根证书动态签发网站证书。企业安全网关或部分安全软件的“HTTPS 扫描”也可能采取类似方式。工具没有正确安装根证书、证书已过期，或浏览器不接受该信任来源时，就会出现证书警告。

从代理设置与抓包进程交叉检查

• 检查是否仍有抓包工具运行，是否启用了 HTTPS 解密，以及它是否设置了系统代理。
• Windows 打开「设置」→「网络和 Internet」→「代理」，记录“使用代理服务器”的地址和端口，再与 Clash 客户端当前监听值对照。
• 核对证书“颁发者”是否变成抓包工具或单位名称。陌生名称需要进一步确认，不能单凭名称就认定攻击。
• 退出个人抓包工具后，重新开启客户端的系统代理，再复测。企业管理设备应联系管理员，不擅自移除组织证书或安全策略。

127.0.0.1:7890 是常见的本地代理示例，不是所有客户端的固定端口。抓包工具和 Clash 若先后改写系统代理，最后写入的值可能覆盖前者；端口被其他进程占用时，也可能连接到并非预期的本地服务。

普通 Clash/mihomo 转发不要求给浏览器安装根证书。若某份所谓“代理修复教程”要求安装未知根证书，应先停止操作。根证书代表一项信任授权，不是加速选项。

Fake-IP 与 DNS 缓存：检查映射是否仍由内核接管

mihomo 的 Fake-IP 模式会给域名返回映射地址，常见配置范围是 198.18.0.1/16。内核根据映射恢复域名，再进行规则匹配与连接。这个地址不是网站的真实公网地址，也不应直接拿它拼成 HTTPS 网址测试。

Fake-IP 本身不会签发证书，也不会改变浏览器信任库。更常见的问题是：浏览器或系统仍缓存旧的 Fake-IP 地址，而 TUN、DNS 劫持或客户端已经停止，连接没有回到维护该映射的内核。这通常表现为连接失败；只有流量最终到达错误的 TLS 服务时，才可能进一步出现域名不匹配等证书错误。

按顺序恢复 DNS 与连接状态

1. 记录当前「系统代理」「TUN 模式」状态，以及活动配置中的 dns.enhanced-mode、fake-ip-range 和 fake-ip-filter。不要同时修改所有设置。
2. 关闭报错页面，确认客户端内核正在运行，重新加载当前配置；若客户端提供清理 DNS 或 Fake-IP 缓存的入口，可在了解作用后使用。
3. Windows 在命令提示符执行 ipconfig /flushdns，然后彻底退出并重新打开浏览器。系统缓存清理不会自动清除浏览器和路由器的所有缓存。
4. 重新访问原域名，同时查看客户端「连接」或「日志」中是否出现该域名，以及命中的规则和代理链。

浏览器“安全 DNS”可能改变域名解析路径。Chrome 的入口为「设置」→「隐私和安全」→「安全」→「使用安全 DNS」，具体选项受版本和组织策略影响。排查时可以记录原值后临时关闭，复测后恢复；不要把关闭安全 DNS 当作所有证书错误的通用解法。

节点、出口与认证网关：用单变量对照缩小范围

若本机时间正常、未发现 HTTPS 解密工具，接下来比较连接路径。节点故障、出口 DNS 异常、公共 Wi-Fi 登录网关以及错误的规则去向，都可能让连接到达错误服务器。代理节点通常无法伪造浏览器认可的目标网站证书；证书警告正是需要保留的边界，不能为“先打开网页”而跳过。

一次只改变一个条件

1. 固定同一设备、同一浏览器和同一网址，记录当前模式、规则命中与实际选中的节点。策略组若使用自动选择，应确认测试期间是否切换了节点。
2. 切换到另一个可信节点，保持其余设置不变，再查看错误码和颁发者是否变化。
3. 在符合网络使用要求的前提下测试直连。若 TUN 仍开启，仅关闭“系统代理”不等于直连；应明确关闭相应接管，或确认测试连接命中 DIRECT。
4. 条件允许时换用手机热点。若只在某个 Wi-Fi 下出现，检查网络是否需要完成门户认证；使用系统网络登录提示，不在证书警告页面输入凭据。

如果只有一个节点异常，应暂停用它处理敏感业务，并向服务提供方反馈域名、发生时间、错误码与证书颁发者。单次域名不匹配不足以证明“节点劫持”，但多个无关站点突然呈现同一张陌生证书，是需要立即停用该路径并核查的信号。

规则决定实际路径，模式名称不是证据

在规则模式下，查看日志中是 DOMAIN-SUFFIX、GEOIP 还是末尾的 MATCH 命中，并确认最终策略。代理组名叫“自动选择”或“Proxy”不代表已经走了预期出口，组内也可能选中 DIRECT。TUN 负责接管流量，不会自动修复错误证书；切换全局模式也不应代替规则检查。

命令行复测：明确端口与验证边界

下面使用 Windows 自带的 curl.exe 对公开示例域名做对照。示例假定客户端的 HTTP 或 mixed 监听端口为 7890，执行前必须换成实际值；纯 SOCKS 端口不能按 HTTP 代理使用。-I 请求响应头，-v 输出连接与 TLS 诊断信息。

curl.exe -Iv --proxy http://127.0.0.1:7890 https://example.com/
curl.exe -Iv --noproxy "*" https://example.com/

第二条只是不使用 curl 的显式代理，不能绕过仍在运行的 TUN、透明网关或企业网络设备。需要真正的路径对照时，应先核实接管状态。不同 curl 构建使用的 TLS 后端和证书库也可能不同，因此命令成功而浏览器失败时，仍需检查浏览器证书策略、扩展与缓存。

• 提示无法连接 127.0.0.1：先检查内核运行与监听端口，不必立即改 DNS。
• 出现代理隧道建立成功后再报证书错误：重点检查后续 TLS 验证；隧道成功不等于证书可信。
• 证书验证成功，但返回 403 或 429：这是 HTTP 访问限制或频率限制，不是证书错误。
• 出现证书验证失败：记录完整错误，继续比较时间、域名、信任链和路径，不使用 -k 或 --insecure 掩盖问题。

恢复设置与提交故障信息

完成排查后，把临时关闭的安全 DNS、调整的代理模式和测试节点恢复到计划使用的状态。若修改过配置，保留原文件与修改记录，避免下一次订阅更新覆盖本地变更后再次出现相同问题。不要把订阅链接直接贴进工单或公开讨论区。

向客户端维护者、网站管理员或网络管理员反馈时，提供以下信息，比一句“开启 Clash 就报错”更容易定位。Clash发布站提供客户端下载与使用说明，不是客户端官方开发团队；具体缺陷应交由对应项目或服务方处理。

• 操作系统、浏览器、客户端与 mihomo 内核的完整版本号，从各自“关于”或版本信息页读取。
• 报错主机名、发生时间与时区、浏览器错误代码，以及证书颁发者和有效期。
• 系统代理与 TUN 状态、实际监听端口、命中的规则类型和最终策略，节点名称可匿名化。
• 同一网址在切换节点、确认直连、换网络后的结果，明确每一步只改了什么。

推荐顺序是：记录错误 → 核对时间 → 检查证书链与解密工具 → 清理失配的 DNS 状态 → 对照节点和网络路径。若需要继续核对接管方式，可查看系统代理设置、规则配置说明与故障排查。证书验证恢复正常后，再进行登录与其他敏感操作。