· 故障排查 · 预计阅读 10 分钟

开启代理后网页提示证书错误:HTTPS 证书报错原因与排查

梳理系统时间偏差、中间人抓包工具、节点劫持与 DNS 污染等导致证书警告的原因,说明哪些与 Clash 有关、哪些与代理无关及对应处理方法。

先记录错误代码，不要跳过证书验证

开启 Clash 后出现“您的连接不是私密连接”，只能说明浏览器在当前连接路径中未能完成服务器身份验证，不能直接推断为节点失效。HTTPS 校验同时依赖访问域名、证书有效期、证书链和本机信任库；代理改变连接路径后，可能暴露其中任何一项问题。

先记下地址栏中的完整主机名、浏览器错误代码、系统时间，以及证书查看器中的“颁发者”“有效期”和 Subject Alternative Name（SAN，使用者可选名称）。记录主机名通常已经足够，分享截图时应遮住地址中的登录令牌、邮箱和其他个人信息。

错误或现象优先检查不能直接得出的结论
NET::ERR_CERT_DATE_INVALID系统日期、时区、证书起止时间不一定是网站证书过期
NET::ERR_CERT_AUTHORITY_INVALID根证书信任、中间证书链、HTTPS 检查工具不一定需要导入新证书
NET::ERR_CERT_COMMON_NAME_INVALIDSAN 是否包含访问域名、DNS 与重定向不能靠添加信任修复域名不匹配
SEC_ERROR_UNKNOWN_ISSUERFirefox 的信任配置和服务端证书链不能只凭其他浏览器可用就排除问题
ERR_SSL_PROTOCOL_ERROR服务端 TLS、端口协议、网络中间设备它不等同于证书不受信任

不要把关闭证书校验、安装来历不明的根证书或点击“继续访问”当作修复。遇到银行、支付、邮箱和账号登录页面的证书警告，应停止输入密码，先在可信网络核实连接。

Clash、mihomo 与 HTTPS 证书的边界

常规 Clash 或 mihomo 配置负责转发连接。浏览器通过 HTTP 代理的 CONNECT 隧道、SOCKS5 或 TUN 路由连接目标网站时，网站 HTTPS 的 TLS 握手通常仍发生在浏览器与网站之间。启用系统代理本身，不要求向系统安装用于解密网页的根证书。

需要区分两层 TLS：节点配置中的 tls、servername 和 skip-cert-verify 可能控制“内核到代理节点”的连接；浏览器证书警告通常涉及“浏览器到网站”的连接。修改节点的 skip-cert-verify 不会修复网站证书，而且会降低节点身份验证的可靠性。

三种现象对应不同排查入口

  • 浏览器显示证书警告：查看网页证书的域名、颁发者和有效期。
  • 客户端日志出现 x509，浏览器显示代理连接失败：检查节点域名、节点证书和内核运行环境的时间、信任库。
  • 开启 TUN 后才异常：确认连接实际经过的规则、DNS 路径和其他 VPN；TUN 本身不会给网站签发新证书。

浏览器安全 DNS、扩展代理、系统代理和 TUN 可能同时存在。诊断时先固定一种入口，避免“关闭系统代理”后流量仍被 TUN 接管，从而误判为直连也有问题。

系统时间偏差与证书有效期

证书包含生效时间和到期时间。本机时间早于生效时间或晚于到期时间都会失败。双系统切换、虚拟机快照恢复、主板电池失效和时间同步服务异常，都可能让多个原本正常的网站同时报错。

先确认时刻，再检查时区显示

  • Windows 11：进入「设置」→「时间和语言」→「日期和时间」，检查“自动设置时间”，再使用“立即同步”。单位设备的时间源可能由组织策略管理。
  • macOS：进入「系统设置」→「通用」→「日期与时间」，检查自动设置日期与时间以及时区。
  • Ubuntu：执行以下命令，查看当前时间、时区和同步状态。
date -Is
timedatectl status

重点检查 System clock synchronized。在采用 systemd 时间管理且未受其他时间服务或组织策略约束的主机上，可使用下面的命令启用网络时间同步，再重新检查状态：

sudo timedatectl set-ntp true
timedatectl status

时区不同不等于系统绝对时间错误，不必为了匹配网站地区修改时区。如果时间正确、只有一个域名的证书已经过期，通常应由网站维护者更新证书；本机修改日期只会掩盖问题，并影响其他站点。

抓包工具、HTTPS 检查与本机信任库

Fiddler、Charles、mitmproxy 等工具启用 HTTPS 解密后，会为访问的网站动态签发证书。部分安全软件、企业网关也可能执行类似检查。浏览器看到的颁发者因此可能变成工具名称或组织名称，而不是网站原本使用的公共证书颁发机构。

按颁发者追查，而不是直接导入证书

  1. 在错误页提供的证书详情中查看颁发者与证书链；界面路径随浏览器版本变化。
  2. 确认是否有抓包程序正在运行，是否启用了 HTTPS 解密，以及系统代理是否仍指向该程序。
  3. 结束个人测试时，关闭工具的 HTTPS 解密功能，并按工具说明恢复代理设置；只移除已经确认属于该工具且不再需要的测试根证书。
  4. 如果颁发者属于公司或学校，向管理员核实设备管理与信任部署，不要自行删除组织证书或绕过策略。

不要假定所有应用都使用同一套证书信任机制。Firefox、系统浏览器、命令行 curl，以及容器内的程序，可能受到不同证书库、版本和组织策略影响。“浏览器能开、curl 不行”应继续比较各自的信任来源，而不是反复切换节点。

Ubuntu 若只是公共 CA 证书包过旧，可通过可信的软件源更新 ca-certificates。下面的操作更新系统信任材料，不会自动修复网站域名错误，也不会让未知私有证书变得可信：

sudo apt update
sudo apt install --only-upgrade ca-certificates
sudo update-ca-certificates

用直连、固定节点与证书详情做对照

对照测试应使用同一设备、同一 URL 和接近的时间，每次只改变一个变量。先暂时关闭抓包与其他 VPN，再确认 TUN、系统代理和浏览器扩展的实际状态。规则模式中的目标域名可能命中 DIRECT，因此“客户端已开启”不代表该请求一定经过节点。

通过本地 mixed-port 对照请求

以下示例假定本机 mixed-port 是 7890，使用公共示例域名 example.com。测试实际故障时，改为该站点不含令牌的 URL，并按客户端显示替换端口。Windows 建议明确调用 curl.exe，避免部分 PowerShell 环境中的同名别名。

# 不使用 curl 的显式代理；TUN 仍可能接管此连接
curl -Iv --noproxy '*' https://example.com/

# 使用 mixed-port 的 HTTP 代理入口
curl -Iv --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/

--noproxy '*' 只绕过 curl 的代理设置，不能绕过 TUN、透明网关或系统路由。要获得真正的直连基线，需要在允许的环境中同时停用相关接管。以上命令没有关闭证书验证；输出可能包含请求信息，分享前应做脱敏处理。

  • 只有某个节点出错：固定其他条件后更换节点，比较证书 SAN、颁发者和错误码；同时在客户端连接记录中确认命中的策略与实际出口。
  • 所有出口只有一个网站出错：优先怀疑该站点证书、证书链或其 CDN 边缘配置，而不是本机代理端口。
  • 同一设备多个网站都出错：优先检查时间、信任库、抓包工具和受管理网络。
  • 同一网络多台设备出错：检查门户认证、路由器 DNS、网关与运营网络；必要时换可信网络交叉验证。

不同出口看到不同证书不必然表示劫持。CDN 可以按地区使用不同的有效证书和中间链。判断重点是域名是否匹配、链是否可信、时间是否有效，以及异常颁发者是否能够解释。

DNS 污染、节点异常与门户认证的区别

DNS 污染或错误解析可能把域名指向不相关的服务器，进而触发证书域名不匹配。它不会让对方自动拥有目标域名的有效证书。攻击者仅仅改变解析结果，通常无法静默解密一个证书验证正常的 HTTPS 连接；浏览器警告正是需要保留的安全边界。

fake-ip 地址不等于错误解析

mihomo 的 fake-ip 模式会向应用返回用于映射的合成 IP，常见配置使用 198.18.0.0/16，但实际范围以 fake-ip-range 为准。单凭查询结果落在这一范围，不能断言 DNS 被污染。要检查内核是否保留了域名映射，以及连接最终使用了哪个规则和出口。

  • 先查看 dns.enhanced-mode、nameserver、可能存在的 nameserver-policy，以及 TUN 的 dns-hijack。
  • 确认浏览器是否启用安全 DNS；浏览器自选解析器可能让域名解析路径与预期不同。
  • 不要只比较两个解析器返回的 IP 是否相同。CDN、地理位置和负载均衡都会导致正常差异。
  • 更改解析配置后，重新加载配置并重建测试连接；旧连接、DNS 缓存和 fake-ip 映射可能让结果暂时混杂。

如果异常只跟随某个出口，并且证书域名不符或颁发者无法解释，应停用该出口并保留脱敏记录。这说明问题与该路径相关，但仍不足以单独证明节点主动劫持，也可能是出口网络的 DNS 或中间设备异常。

酒店、机场等网络还可能要求先完成门户认证。HTTPS 请求被引向登录网关时可能报证书错误。可使用系统提供的“登录网络”提示完成认证；不要在证书异常的原网站页面输入账号，也不要为门户页面安装未知根证书。

修复确认与常见误区

为什么 HSTS 网站没有“继续访问”？

HSTS（HTTP Strict Transport Security，HTTP 严格传输安全）要求浏览器对相关站点严格执行 HTTPS。证书错误时不提供绕过入口可能是预期行为。清除 HSTS 状态不是证书修复，应解决时间、证书链、域名或网络路径本身的问题。

改成全局模式或开启 TUN 能解决吗？

这两项操作可能改变出口或接管范围，因此可用于受控对照，却不能修复过期证书和未知颁发者。全局模式改变选路，TUN 接管网络层流量；两者都不应改变浏览器对网站身份的验证标准。若测试后恢复正常，还要找出原规则或原路径为什么异常。

完成排查后的检查清单

  1. 恢复需要的规则模式和代理入口，移除临时测试设置，保持证书验证开启。
  2. 关闭旧标签页后重新访问，确认主机名正确、证书有效且错误不再出现。
  3. 在客户端连接记录中确认实际策略，避免用缓存页面或未经过预期出口的请求判断结果。
  4. 若需反馈，提供操作系统、浏览器版本、客户端及内核版本、错误代码、出现时间和脱敏后的证书信息；不要提交订阅地址、节点密码或完整配置。

排查顺序可固定为：错误代码 → 时间 → 证书详情 → 本机 HTTPS 检查 → 直连与固定出口对照 → DNS 与网络路径。先保留验证边界，再逐项缩小范围，比同时修改多个配置字段更容易定位原因。

下载Clash