开启代理后 HTTPS 证书报错怎么办:常见原因与逐项排查

HTTPS 证书错误通常发生在 TLS 握手阶段。浏览器在真正发送网页请求前，会检查服务器返回的证书是否由可信机构签发、证书中的域名是否与当前地址一致、当前时间是否位于有效期内，以及证书链能否完整连接到系统信任的根证书。开启 Clash 或 mihomo 后出现报错，只能说明连接路径发生了变化，不能直接把原因归到某一个节点。

标准的 HTTP CONNECT、SOCKS5 或 TUN 转发不会替网站签发证书。mihomo 内核通常只负责转发连接、匹配规则和选择出口，并不解密网页中的 TLS 内容。如果浏览器看到的证书签发者突然变成本地安全软件、公司网关或陌生机构，应继续检查 HTTPS 扫描、上游代理、公共网络认证页及系统证书库，而不是反复修改代理规则。

先根据错误代码缩小范围

不同证书错误对应不同检查方向。Chrome、Edge 与基于 Chromium 的客户端通常显示以 NET::ERR_CERT_ 开头的代码；Firefox 常见 SEC_ERROR_UNKNOWN_ISSUER 或 SSL_ERROR_BAD_CERT_DOMAIN。先展开浏览器的“高级”或“查看证书”，再对照下表处理。

证书页面重点看四项

1. 颁发给：应包含当前访问域名。通配符证书 *.example.com 可以覆盖 www.example.com，但通常不能覆盖更深一级的 a.b.example.com。
2. 颁发者：若直连时是公开证书机构，代理时变成本机软件名称或单位内部 CA，说明链路中存在 TLS 检查。
3. 有效期：比较“生效时间”和“到期时间”时，必须同时确认系统时区。日期正确但时区偏差数小时，也可能在证书刚续期时触发错误。
4. 使用者可选名称：现代浏览器主要检查 SAN，而不是只看旧式的 Common Name。证书里缺少当前域名就会触发域名不匹配。

第一步：校准系统时间与证书环境

时间错误是覆盖范围最广、排查成本最低的一项。如果所有 HTTPS 站点都失败，或者电脑刚从休眠恢复、主板电池刚更换、设备使用双系统，应先完成时间同步。Windows 11 路径为“设置”→“时间和语言”→“日期和时间”，开启“自动设置时间”和“自动设置时区”，随后点击“立即同步”。

Windows 还可以在终端执行以下命令查看时间服务状态。结果中的 Source 应显示可用的时间源，Last Successful Sync Time 应接近当前时间。

w32tm /query /status
powershell -NoProfile -Command "Get-Date"

macOS 路径为“系统设置”→“通用”→“日期与时间”，开启自动设置。Linux 可用 timedatectl status 检查 System clock synchronized 与时区。Android 常见路径为“设置”→“系统”→“日期和时间”；不同厂商可能把入口放在“更多设置”中。

清理过期的本地证书干预

如果设备曾安装抓包工具、调试代理、公司终端管理软件或 HTTPS 扫描组件，应检查这些程序是否仍在运行。只退出浏览器通常不够，因为过滤驱动、系统服务和本地代理进程可能继续接管连接。先从软件自身的设置中关闭 HTTPS 扫描或 TLS 解密，再彻底退出对应程序并重启浏览器。

• Windows 可按 Win + R，输入 certmgr.msc 查看当前用户证书；计算机级证书可通过 MMC 的“证书”管理单元检查。
• macOS 在“钥匙串访问”中检查“系统”和“登录”钥匙串，重点查看近期加入且用途为证书签名的条目。
• Firefox 可打开“设置”→“隐私与安全”→“证书”→“查看证书”，检查“证书颁发机构”列表。
• Android 可在“设置”→“安全”→“加密与凭据”中查看用户安装的凭据，实际菜单名称随系统版本变化。

第二步：比较直连、系统代理与 TUN 路径

排查证书问题最有效的方法是做受控对照。每次只改一个变量，避免同时切节点、切 DNS、改规则和重装证书。建议先选择一个稳定的 HTTPS 站点测试，再测试原先报错的目标站点，以区分“所有站点失败”和“单站点失败”。

1. 保留 Clash 或 mihomo 运行，但关闭系统代理与 TUN，测试直连。
2. 只开启系统代理，使用同一节点与同一浏览器再次测试。
3. 关闭系统代理，只开启 TUN，再测试一次。
4. 保持模式不变，把当前节点切换到另一个不同线路的节点。
5. 最后才切换规则模式、全局模式或直连模式，观察问题是否与规则命中有关。

用 curl 验证本地混合端口

Clash 图形客户端常把本地混合端口设为 7890，但实际值应以配置中的 mixed-port 或客户端“设置”→“端口设置”为准。下面两条命令分别测试直连和通过本地 HTTP 代理连接。-I 只请求响应头，-v 会显示连接与 TLS 过程。

curl -Iv https://www.cloudflare.com/
curl -Iv --proxy http://127.0.0.1:7890 https://www.cloudflare.com/

如果直连成功、代理失败，继续切换节点并查看 mihomo 日志。如果所有节点都失败，但关闭某个本地安全组件后恢复，应优先处理本机 TLS 检查。如果只有单个节点失败，可能是节点出口网络、上游 DNS、公共网络认证或服务器到目标站点的路径异常。

也可以使用 OpenSSL 观察服务器发送的证书链。较新的 OpenSSL 支持通过 HTTP 代理建立连接：

openssl s_client -proxy 127.0.0.1:7890 -connect www.cloudflare.com:443 -servername www.cloudflare.com -showcerts

-servername 会发送 SNI。缺少 SNI 时，多域名服务器可能返回默认站点证书，进而造成域名不匹配。比较直连与代理结果时，重点看证书主题、签发者、有效期和验证返回码，不要只看命令最后是否建立了 TCP 连接。

第三步：检查节点、DNS 与代理规则

节点切换能说明什么

HTTPS 通过代理时，客户端通常先向节点建立加密隧道，再由节点连接目标网站。对 HTTP 代理而言，浏览器通过 CONNECT example.com:443 建立隧道；对 SOCKS5 而言，域名或目标地址由 SOCKS 请求传递。正常隧道中的 TLS 仍由浏览器与目标网站完成。

如果换到另一节点立即恢复，可进一步检查失败节点所在网络是否把目标域名导向了错误地址、是否遇到运营商认证页，或者是否无法取得目标站点当前使用的证书链。节点本身只有在链路中同时具备证书替换能力且设备信任其签发证书时，才能让浏览器无警告地接受替换内容；缺少信任时通常直接出现证书错误。

DNS 错误为何会变成证书域名错误

DNS 把域名解析到错误服务器时，浏览器仍会把原域名作为 SNI 发出。如果错误服务器没有对应虚拟主机，它可能返回其他网站的证书，最终出现 NET::ERR_CERT_COMMON_NAME_INVALID。此时证书本身可能仍在有效期内，但适用域名与地址栏不一致。

mihomo 的 fake-ip 模式会先从保留地址池返回映射地址，再在内核中恢复原域名并按规则连接。Fake-IP 本身不会生成网站证书。若问题只在 Fake-IP 下出现，应检查域名是否被错误加入 fake-ip-filter、应用是否绕过了 TUN，以及局域网 DNS 请求是否确实进入 mihomo。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

fake-ip-filter 应针对确实依赖真实地址的局域网服务、设备发现域名或特定兼容性场景设置，不宜把大范围域名全部排除。排除后这些域名会走真实解析，解析来源与规则路径也会随之变化。

查看规则实际命中

在支持连接列表的 Clash 客户端中，打开“连接”或“日志”页面，访问报错站点后按域名筛选。记录命中的规则、策略组和最终节点。如果目标本应直连却进入代理，检查靠前的 DOMAIN、DOMAIN-SUFFIX、GEOSITE 与规则集；如果本应代理却直连，则检查局域网规则、私有地址规则和最终 MATCH。

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOSITE,private,DIRECT
  - GEOIP,private,DIRECT,no-resolve
  - MATCH,PROXY

规则按顺序匹配，前面命中后不会继续向下。修改 YAML 后应先确认缩进，再重新载入配置。若客户端同时使用订阅覆写、脚本或全局扩展配置，还要确认最终生效配置，而不是只看订阅原文。

第四步：定位 MITM、HTTPS 扫描与防火墙介入

MITM 在这里指中间组件终止原始 TLS 连接，再向浏览器签发一张替代证书，同时由该组件与目标网站建立第二条 TLS 连接。企业审计网关、抓包调试工具、家长控制程序和部分终端安全产品可能采用这种方式检查 HTTPS 流量。

标准 mihomo 配置中的 proxies、proxy-groups、rules、tun 与 dns 字段不负责为网页签发证书。因此，在 Clash 客户端界面中找不到所谓“网站证书开关”是正常现象。若证书签发者显示为本机软件，应回到该软件的网络防护或 HTTPS 扫描设置处理。

逐项停用而不是一次卸载全部组件

1. 关闭浏览器扩展中的代理切换、抓包或调试功能，完全退出浏览器后重开。
2. 暂停本地抓包程序的系统代理和 HTTPS 解密，只保留 Clash 的系统代理。
3. 在安全软件中临时关闭“HTTPS 扫描”“加密连接检查”或同类功能，完成一次对照测试后恢复。
4. 断开公司 VPN、零信任客户端或远程办公网关，再比较家庭网络与移动热点。
5. 若公共 Wi-Fi 尚未认证，先关闭代理并访问系统提供的登录页，完成认证后再启用代理。

某些公共网络会把首次 HTTP 请求重定向到认证页。HTTPS 无法直接接受这种重定向，因为认证网关返回的证书不属于原始网站，浏览器便显示域名不匹配。切换到手机热点后立即恢复，是识别此类问题的有效信号。

第五步：处理仅浏览器或仅应用报错

Chrome、Edge 正常，Firefox 报错

Chrome 与 Edge 通常跟随操作系统证书环境，Firefox 的证书处理可能与系统存在差异。先在 Firefox 打开“设置”→“隐私与安全”→“证书”→“查看证书”，确认所需机构是否存在。企业设备应由管理员统一部署证书策略，不应从网页提示中临时下载证书。

浏览器正常，桌面应用或手机应用失败

部分应用使用独立证书库，部分应用还会执行证书固定校验，即只接受开发者预先指定的证书或公钥关系。此时浏览器可以正常打开网站，而应用仍拒绝连接。解决方向通常是让该应用流量绕开 TLS 解密组件，而不是把更多证书导入系统。

若问题只在 TUN 模式出现，检查应用流量是否同时经过另一套 VPN、安全过滤器或私有 DNS。Android 和 iOS 通常一次只允许一个主要 VPN 隧道，但本地 DNS、内容过滤配置或设备管理策略仍可能改变路径。关闭其他网络扩展后再单独启动 Clash 客户端，能减少变量。

无痕窗口正常，普通窗口失败

这通常指向浏览器扩展、缓存的 HSTS 状态、独立代理扩展或用户配置差异。先在扩展管理页停用网络相关扩展，再清理目标站点的 Cookie 与站点数据。不要把“忽略证书错误”启动参数作为长期方案，它会降低整个浏览器会话的证书校验能力。

一套可复用的十分钟排查顺序

1. 第 1 分钟：抄下错误代码，并查看证书的域名、签发者和有效期。
2. 第 2 分钟：同步系统时间，确认日期、时区和时间服务状态。
3. 第 3 分钟：关闭系统代理与 TUN，做一次直连对照。
4. 第 4 分钟：只开系统代理，保持同一网站和同一浏览器测试。
5. 第 5 分钟：更换一个不同线路的节点，不改其他设置。
6. 第 6 分钟：查看连接日志，确认域名命中的规则、策略组与出口。
7. 第 7 分钟：用 curl -Iv 比较直连与 127.0.0.1:7890 代理结果。
8. 第 8 分钟：暂停 HTTPS 扫描、抓包和企业网络组件，逐个做对照。
9. 第 9 分钟：切换到手机热点，排除公共网络认证和当前路由器路径。
10. 第 10 分钟：整理复现条件，包括客户端版本、mihomo 内核版本、系统版本、节点、模式和错误代码。

最终判断应建立在对照结果上：所有网络和所有设备都对同一网站报错，倾向于网站证书部署问题；只有一台设备失败，优先查时间、证书库与安全软件；只有代理路径失败，继续查节点、DNS、规则和上游网络；只有单个应用失败，则重点考虑独立证书库、证书固定和应用流量接管范围。

完成排查后，把临时关闭的安全功能逐项恢复，并再次验证浏览器与常用应用。Clash 或 mihomo 配置也应回到日常使用模式，避免长期保留全局代理、过宽的 Fake-IP 排除项或仅为测试添加的规则。