先判断：证书错误不是普通的连接超时

先核对系统时间，再记录证书信息，最后对比代理与 TUN 路径。浏览器出现 NET::ERR_CERT_AUTHORITY_INVALID，表示收到的证书未通过信任验证；它与节点超时、订阅失效不是同一种故障。换节点可能改变现象，但不能代替检查证书。

普通 Clash 或 Clash Meta（mihomo）代理连接通常只转发 HTTPS 流量，不会为目标网站重新签发证书。使用 HTTP 代理时，浏览器可以通过 CONNECT 建立隧道，再与目标网站进行 TLS 握手；目标站点的证书仍由浏览器验证。正常使用 Clash 客户端不需要安装所谓的“Clash 根证书”。

先保留这 5 项信息

  • 地址栏中的完整域名，以及错误页显示的报错代码；分享时移除 URL 中的令牌和个人参数。
  • 证书的颁发者、有效期、使用者可选名称（SAN）；不同浏览器可从错误页高级信息或证书查看器进入。
  • 故障范围：一个域名、同一机构的多个域名，还是几乎所有 HTTPS 网站。
  • Clash 当前模式、实际选中的节点，以及系统代理和 TUN 模式是否开启。
  • 故障发生前是否启用了抓包软件、更新了安全软件，或连接了酒店、机场等需要认证的网络。

按报错代码缩小检查范围

Chrome、Edge 等 Chromium 浏览器的代码相近，Firefox 的表述可能不同。代码说明的是验证失败环节，并不能直接证明是哪款软件导致。先对照下表，再执行后续步骤。

错误代码常见含义优先检查
NET::ERR_CERT_DATE_INVALID证书过期、尚未生效，或设备时间不正确系统日期、时间同步、证书有效期
NET::ERR_CERT_AUTHORITY_INVALID证书链无法连接到受信任的根证书抓包代理、安全软件、企业证书和服务器中间证书链
NET::ERR_CERT_COMMON_NAME_INVALID证书所覆盖的名称与访问域名不匹配地址拼写、DNS、hosts、认证网关
NET::ERR_CERT_REVOKED证书已被吊销网站证书状态、签发方与服务器更新

ERR_SSL_PROTOCOL_ERROR 则不一定是证书信任错误，也可能是端口服务不对、TLS 协商失败或网络设备干扰。不要把所有包含 SSL 的报错都归为“缺少根证书”。

第一步：核对系统时间与证书有效期

设备时间跳到过去或未来，会让本来有效的证书变成“尚未生效”或“已经过期”。如果大量无关网站同时出现日期错误，应先查本机，而不是批量修改规则。

  1. Windows 11 打开「设置」→「时间和语言」→「日期和时间」，检查“自动设置时间”，再点击“立即同步”。确认日期、年份和显示时间都合理。
  2. macOS 打开「系统设置」→「通用」→「日期与时间」，检查自动设置日期与时间以及时区选项。
  3. 同步后彻底退出浏览器再启动，重新打开原网址，不只刷新旧的错误页。
  4. 如果只有一个站点仍失败，查看该站证书的起止日期；服务器证书确实过期时，应由站点维护者续期。

Windows 命令行辅助检查

Get-Date
w32tm /query /status

以上命令在 PowerShell 中用于查看当前时间和 Windows 时间服务状态；第二条在服务未运行时可能报错。时区主要影响显示，证书验证取决于实际系统时间，因此不要只改时区却忽略年月日。若设备每次断电后时间都重置，还需检查固件时间和硬件时钟。

第二步：排查抓包代理与 HTTPS 扫描

Charles、Fiddler 等调试工具在启用 HTTPS 解密时，会向浏览器提供由其本地根证书签发的站点证书。部分安全软件的 HTTPS 扫描、企业网关也可能采用类似机制。根证书未被当前浏览器信任、已经过期，或工具卸载后代理设置残留，都可能触发警告。

从证书颁发者开始找

  • 若多个不同网站的证书都由同一个本地调试工具或组织名称签发，优先检查中间代理，而不是网站本身。
  • 暂时停止自己安装的抓包工具及其 HTTPS 解密功能，再检查系统是否还指向该工具的监听端口。
  • Windows 11 可在「设置」→「网络和 Internet」→「代理」查看手动代理；macOS 可在「系统设置」→「网络」→当前连接→「详细信息」→「代理」查看。
  • 同时记录 Clash 的实际混合端口。7890 只是常见示例，另一个进程也可能占用它；系统代理地址应与当前客户端显示的监听地址一致。

个人设备上若只在一个浏览器出错，可用另一个已更新的浏览器对比。浏览器版本、根证书存储和管理策略可能不同，因此“另一个浏览器能打开”只说明验证环境存在差异，并不代表可以直接信任那张异常证书。

第三步：检查 DNS、hosts 与网络认证页

DNS 本身不签发 HTTPS 证书，但错误解析可能把连接送到另一台服务器。如果请求的是一个域名，对方却返回另一个域名的证书，就会出现名称不匹配。公共 Wi-Fi 的认证网关、遗留 hosts 记录和错误的 DNS 映射都值得检查。

先处理认证网络，再查解析

  1. 若刚连接酒店或机场 Wi-Fi，先使用系统提供的网络登录入口完成认证，不要在证书报错页输入账号。
  2. 检查 hosts 中是否存在目标域名的旧映射。Windows 文件位置是 C:\Windows\System32\drivers\etc\hosts，macOS 和 Linux 通常是 /etc/hosts。
  3. Windows 可用下面的命令查看系统 DNS 查询结果并清理系统缓存；清理后还应重启浏览器，再检查 Clash 自身的 DNS 缓存与连接。
nslookup example.com
ipconfig /flushdns

example.com 是命令格式示例，实际排查时使用发生错误的域名。注意，nslookup 的查询路径不一定与浏览器一致：浏览器安全 DNS、代理端解析和 TUN DNS 劫持都可能改变结果。单独一份命令输出不足以证明浏览器访问到了哪个地址。

不要把 Fake-IP 地址直接判为污染

mihomo 使用 Fake-IP 模式时，可能向应用返回 198.18.0.0/16 范围内的映射地址，再由内核关联回原域名。该范围是常见配置，并非所有客户端都相同。看到这类地址并不等于连接到了伪造网站；应结合活动配置的 dns.enhanced-mode、fake-ip-range 和连接日志判断。

如果只有直连路径收到错误证书，而经代理访问正常，才进一步排查本地解析、运营网络和直连服务器。不要为了测试把 HTTPS URL 改成 IP 地址：证书通常按域名签发，直接访问 IP 本身就可能制造名称不匹配。

第四步：分开验证系统代理与 TUN 模式

TUN 模式通常在网络层接管流量，并不天然解密 TLS。开启后才出错，常见原因是它改变了路由、DNS 处理或规则命中，让连接走上了另一条路径。还可能与其他 VPN、虚拟网卡或安全软件发生冲突。

按单变量顺序测试

  1. 记录基线：保存当前模式、节点、DNS 设置与报错证书信息。测试期间固定节点，不同时更新订阅或修改规则。
  2. 测试系统代理：关闭 TUN，开启系统代理，完全退出浏览器后重开。确认浏览器未被扩展或组织策略指定到其他代理。
  3. 测试 TUN：关闭系统代理，再开启 TUN。仍使用同一域名和节点，观察 Clash 连接记录里的规则、出站策略及目标信息。
  4. 测试本地直连：关闭系统代理与 TUN，并确认其他 VPN 或手动代理也未接管连接。重新建立连接后比较证书，而不只是比较能否打开。

若仅 TUN 路径失败，先关注 DNS 劫持、其他 VPN 和虚拟网卡冲突；若系统代理路径也失败，重点比较证书颁发者和实际节点。修改配置前先备份，一次只改一项。订阅更新可能覆盖直接编辑的内容，持久调整应使用客户端支持的覆写或合并机制，具体字段需按当前 mihomo 版本确认。

用 curl 对比连接路径，保留验证证据

下面以本机 HTTP 或混合代理端口 7890 为例。先从客户端设置页确认端口，再执行命令；Windows PowerShell 使用 curl.exe 可避免部分环境中同名别名的影响。

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

macOS、Linux 可把 curl.exe 改为 curl。第一条明确指定应用层代理，第二条跳过 curl 的应用层代理设置。第二条不会绕过 TUN，也不会绕过系统中其他网络层接管。想做本地直连对照，仍需先关闭这些功能。

  • 对比 TLS 验证结果、证书主题和颁发者；具体能输出多少证书信息取决于 curl 的版本和 TLS 后端。
  • curl 返回错误码 60 通常表示证书验证失败，仍需阅读后面的具体原因，不能直接认定是 DNS 问题。
  • 不要添加 -k 或 --insecure，否则会跳过本次正在排查的验证步骤。
  • curl 与浏览器使用的信任存储可能不同，curl 成功不能自动证明浏览器策略正常。HEAD 请求返回 405 也不等于 TLS 握手失败。

分享日志前移除代理认证信息、Cookie、订阅地址及带令牌的请求参数。保留测试时间、错误代码和证书颁发者，通常比提交整份配置更有助于定位。

按故障范围决定下一步

所有网站都报错

优先检查系统时间、根证书更新、抓包软件和网络认证。保持操作系统与浏览器处于受支持的更新状态；旧系统的信任存储可能缺少新证书链。不要下载来路不明的根证书“修复包”。

只有一个网站报错

用另一台设备和另一条网络对比。如果都显示相同的过期证书或名称错误，应联系站点维护者；如果仅某个节点出现，记录该节点和证书信息，切换其他可信节点后复测，并向服务提供方反馈。

恢复后如何确认

  • 原报错域名和至少两个不同站点都能通过正常证书验证。
  • 证书覆盖当前访问域名，有效期合理，没有新增来源不明的根证书。
  • 恢复日常规则模式后，连接记录的出站策略符合预期；重启客户端和浏览器后结果保持一致。

最终应修复的是时间、信任链、解析或连接路径中的具体问题，而不是隐藏浏览器警告。需要核对模式和订阅操作时，可继续查看Clash 配置手册；客户端安装及首次配置步骤见使用教程。