HTTPS 证书错误到底表示什么

浏览器访问 HTTPS 网站时，会先与目标服务器建立 TLS 连接。服务器会返回证书链，浏览器随后核对证书的有效期、签发机构、域名范围和吊销状态。任何一项不符合要求，都可能中止连接并显示证书错误。Clash 位于网络转发路径中，但常规的系统代理、HTTP 代理、SOCKS5 代理和 TUN 转发本身不会自动解密网页内容。

以 HTTP 代理为例，浏览器访问 HTTPS 网站时通常先向本地代理端口发送 CONNECT 请求，例如连接到 127.0.0.1:7890，再要求建立通往 example.com:443 的隧道。隧道建立后，TLS 握手仍发生在浏览器与远端服务器之间。只要中间环节没有执行 HTTPS 解密，Clash 看不到网页明文，也不会替网站签发证书。

浏览器错误代码对应的检查方向

错误代码 常见含义 优先检查项
NET::ERR_CERT_DATE_INVALID 证书不在有效期内，或本机时间偏差过大 系统日期、时区、自动校时、网站证书期限
NET::ERR_CERT_COMMON_NAME_INVALID 证书覆盖的域名与当前访问域名不一致 DNS 污染、节点劫持、错误的 hosts 记录
NET::ERR_CERT_AUTHORITY_INVALID 证书链无法追溯到受信任根证书 本地抓包证书、企业网关、证书库异常
ERR_SSL_PROTOCOL_ERROR TLS 握手被中断，返回内容不是预期的 TLS 数据 节点可用性、端口转发、协议配置、网络拦截
SEC_ERROR_UNKNOWN_ISSUER Firefox 无法信任证书签发者 Firefox 独立证书库、本地中间证书

为什么开启 Clash 后才出现报错

开启 Clash 会改变连接使用的出口、DNS 解析路径和路由规则。报错在开启代理后出现，只能说明问题与这条新路径相关，不能直接认定是 Clash 核心修改了证书。实际排查时应把路径拆成浏览器、本地代理、规则匹配、节点、远端 DNS 和目标服务器六个环节。

节点把请求送到了错误服务器

如果节点出口使用了异常 DNS，或线路中存在域名劫持，目标域名可能被解析到错误 IP。浏览器原本访问 account.example.com，远端却返回了另一个站点的证书，于是出现域名不匹配。此类问题通常只影响部分域名，切换到另一节点后会立即恢复。

还可以观察证书详情中的“颁发给”字段。如果当前域名与证书中的 Subject Alternative Name 完全无关，重点检查节点和 DNS，不要直接点击浏览器的“继续访问”。登录页、支付页和账户中心出现域名不匹配时，应停止输入账号与密码。

本地软件执行了 HTTPS 解密

Charles、Fiddler、mitmproxy、部分调试代理、企业终端管理软件和安全软件可以安装本地根证书，再对 HTTPS 流量执行中间人解密。配置正确时，浏览器会信任本地签发的临时证书；根证书缺失、过期或只安装到错误证书库时，就会显示签发机构无效。

常见链路是浏览器先连接 Clash，Clash 再把流量转给另一个本地代理，或者操作系统仍保留着旧的 PAC 地址。即使 Clash 面板显示系统代理已开启，流量也可能经过多个进程。Windows 可在「设置」→「网络和 Internet」→「代理」检查手动代理和设置脚本；macOS 可在「系统设置」→「网络」→当前网络→「详细信息」→「代理」检查网页代理、安全网页代理与自动代理配置。

系统时间导致证书看起来尚未生效或已经过期

TLS 证书包含明确的 Not Before 与 Not After 时间。电脑日期误差一天、时区选择错误，或设备休眠后时钟未同步，都可能触发 NET::ERR_CERT_DATE_INVALID。代理开启与时间错误可能只是同时发生，尤其是刚重装系统、主板电池电量不足或虚拟机从快照恢复时。

Windows 11 可打开「设置」→「时间和语言」→「日期和时间」，启用“自动设置时间”和“自动设置时区”，再点击“立即同步”。macOS 可打开「系统设置」→「通用」→「日期与时间」，启用自动设置。同步后应完全退出浏览器并重新打开，而不是只刷新当前标签页。

按顺序完成的 Clash 证书错误排查

下面的顺序用于快速缩小范围。每一步只改变一个变量，并记录结果。不要同时更换节点、修改 DNS、重装证书和清空浏览器数据，否则恢复后无法确认真正原因。

  1. 记录完整错误代码。 不要只记录“连接不安全”。复制地址栏域名、浏览器错误代码和证书签发者，并确认报错发生时间。
  2. 关闭系统代理后重新测试。 在 Clash 客户端关闭“系统代理”，完全退出浏览器，再访问同一网址。如果直连正常、代理报错，问题范围可缩小到规则、节点或代理链路。
  3. 切换一个不同线路的节点。 优先选择不同地区、不同服务商或不同协议的节点。切换后等待 3 至 5 秒，让旧连接关闭，再用无痕窗口测试。
  4. 将代理模式临时改为全局。 若全局模式正常、规则模式报错，说明同一页面所需的主域名、接口域名或静态资源域名可能被分到不同出口。测试完成后改回规则模式。
  5. 核对系统时间。 检查年月日、小时、分钟和时区。中国大陆通常使用 UTC+08:00；不要只看任务栏显示是否接近当前时间。
  6. 检查证书签发者。 浏览器地址栏打开证书详情。如果签发者名称指向本地调试工具、公司网关或安全软件，继续排查对应程序和根证书。
  7. 停用额外代理层。 退出抓包程序、浏览器代理扩展和其他代理客户端，确认系统里只有一个程序监听预期端口。
  8. 最后再检查 DNS 与配置文件。 如果只有少数域名返回错误证书，比较直连与代理路径得到的解析地址，并核对规则是否把相关域名送往错误出口。

检查端口、代理链与本地监听状态

不同客户端的默认端口可能不同，配置中常见的混合端口是 7890，SOCKS 端口可能是 7891，外部控制端口常见为 9090。这些只是常见值，实际结果以当前配置和客户端设置页为准。浏览器或系统代理指向旧端口时，可能连接到另一个仍在运行的进程。

在 Windows PowerShell 中，可以检查常见端口由哪个进程监听：

Get-NetTCPConnection -State Listen |
  Where-Object LocalPort -In 7890,7891,9090 |
  Select-Object LocalAddress,LocalPort,OwningProcess

Get-Process -Id <OwningProcess 数值>

在 macOS 或 Linux 中，可使用以下命令：

lsof -nP -iTCP:7890 -sTCP:LISTEN
lsof -nP -iTCP:7891 -sTCP:LISTEN
lsof -nP -iTCP:9090 -sTCP:LISTEN

如果 7890 由旧版客户端、调试代理或其他服务占用，当前 Clash 客户端可能自动改用了另一个端口，也可能启动失败。此时应先退出冲突进程，再回到客户端的「设置」→「端口设置」或「设置」→「Clash 设置」核对 Mixed Port、HTTP Port 与 SOCKS Port。菜单名称因客户端不同会有差异，但端口值必须与系统代理中填写的值一致。

检查是否存在上游代理

mihomo 配置可以通过代理提供者、链式代理或 dialer-proxy 等机制让连接经过另一代理。浏览器扩展也可能覆盖系统代理。排查时先保留最短链路：浏览器使用系统代理，系统代理直接指向 Clash 的 Mixed Port，Clash 选择一个确定可用的普通节点。链路恢复后，再逐项加入中转和扩展功能。

若使用命令行测试，可分别比较直连和本地代理返回的证书信息。以下示例只发送请求头，不会提交账户数据：

curl -I https://example.com/
curl -I --proxy http://127.0.0.1:7890 https://example.com/

如果直连成功而代理请求显示证书错误，再切换节点重复第二条命令。若只有一个节点失败，通常不需要修改系统证书库；停用该节点并向节点提供方反馈域名、时间和错误代码即可。

DNS、规则模式与 TUN如何影响证书结果

证书校验针对域名进行，但连接最终要落到 IP 地址。Clash 的 DNS 模块、Fake-IP 模式、规则分流和节点远端解析共同决定实际连接目标。配置不一致时，虽然浏览器地址栏里的域名没有变化，服务器返回的证书却可能属于另一域名。

规则模式中的出口不一致

现代网页通常同时请求主站、登录接口、内容分发网络和第三方资源。主域名走代理、接口域名走直连并不会自动导致证书错误，但在有地区限定、企业内网解析或分区域 CDN 的场景下，不同出口可能拿到不同地址。应打开客户端的连接记录，按报错时间查找目标域名，确认命中的规则和代理组。

如果临时切换全局模式后恢复，可以为同一业务域名补充一致的规则。例如主域名与其子域名需要走同一代理组时，可按实际域名添加规则：

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

规则从上到下匹配。更具体的域名规则应放在宽泛规则之前。不要把示例域名直接写入正式配置，应根据连接记录确认真实请求域名。

Fake-IP 与 DNS 劫持

Fake-IP 模式会向本机返回映射地址，再由核心根据域名执行规则和真实解析。浏览器看到 198.18.0.0/16 范围内的地址并不等于证书被替换，这是 Clash 常见的内部映射方式。真正需要关注的是流量是否被核心正确接管，以及目标域名是否进入了不合适的 Fake-IP 过滤列表。

TUN 模式通常会接管更多应用流量，并可配合 DNS 劫持把 53 端口查询交给核心。若系统同时运行企业 VPN、游戏加速器、虚拟机网络或另一套 TUN 驱动，路由和 DNS 可能发生竞争。测试时可在客户端的「设置」→「TUN 模式」暂时关闭 TUN，只保留系统代理。如果证书错误消失，应继续检查路由表、DNS 劫持和其他虚拟网卡，而不是导入来源不明的根证书。

比较域名解析结果

Windows 可使用 Resolve-DnsName，macOS 和 Linux 可使用 dig。先在 Clash 关闭时查询一次，再开启后查询。Fake-IP 模式下结果不同属于预期，应结合 Clash 连接记录确认真实目标；Redir-Host 模式下若返回完全不同的公网地址，则要检查 nameserver、fallback、代理节点的远端解析和本机 hosts 文件。

Resolve-DnsName example.com
nslookup example.com

dig example.com A
dig example.com AAAA

证书库与浏览器差异的处理方法

Chrome、Edge 通常使用操作系统证书能力，但不同平台的实现细节并不完全一致。Firefox 可以使用自己的证书存储，因此可能出现 Chrome 正常、Firefox 报 SEC_ERROR_UNKNOWN_ISSUER 的情况。只在单一浏览器报错时，应先排查该浏览器的扩展、代理设置、证书库和安全策略。

Windows 证书检查

按 Win + R，输入 certmgr.msc，可查看当前用户证书。重点检查「受信任的根证书颁发机构」→「证书」中是否存在已经停用的抓包工具证书。不要批量删除系统根证书，也不要根据不明教程随意导入证书。若证书明确属于已经卸载的调试工具，应先查阅该工具的卸载说明，再移除对应证书。

macOS 钥匙串检查

打开「应用程序」→「实用工具」→「钥匙串访问」，分别查看“登录”和“系统”钥匙串。搜索报错页面证书详情中显示的签发者名称，检查证书有效期与信任设置。企业或学校管理的设备可能由描述文件安装证书，此类证书不应自行删除，应交由网络管理员确认。

Firefox 独立检查

打开「设置」→「隐私与安全」→「证书」→「查看证书」，核对“证书颁发机构”列表。还应在「设置」→「常规」→「网络设置」确认 Firefox 是使用系统代理、手动代理还是自动代理配置。若系统代理已经指向 Clash，而 Firefox 又手动指向另一个端口，就形成了与其他浏览器不同的链路。

从 Clash 日志判断故障位置

证书校验发生在浏览器侧时，Clash 日志不一定直接出现“certificate invalid”。日志更常提供连接目标、规则命中、节点名称和底层握手错误。排查期间可将日志级别临时调到 info 或 debug，复现一次后立即恢复，避免长期产生大量记录。

  • i/o timeout：连接或握手超时，优先检查节点质量、目标可达性和防火墙。
  • connection refused：目标端口或上游代理拒绝连接，检查端口、协议和服务状态。
  • tls handshake timeout：TLS 握手未在限定时间内完成，可能是线路丢包、节点异常或目标限制。
  • remote error: tls：远端主动结束 TLS 会话，需要结合前后日志和目标域名判断。
  • no such host：域名解析失败，重点检查 DNS 配置、网络可达性和域名拼写。

如果日志显示连接已匹配预期规则、通过另一个节点也能成功，而浏览器仍显示本地签发者证书，问题更可能位于浏览器与 Clash 之间。反过来，如果只有某个节点出现握手超时或错误目标地址，应停用该节点，不要通过降低浏览器安全设置来规避。

恢复后的配置收尾

找到原因后，应撤销排查期间的临时改动。将全局模式改回规则模式，恢复正常日志级别，关闭不再使用的手动代理，核对 TUN 和系统代理是否符合日常需求。如果修改过规则，至少测试首页、登录接口和常用资源域名，确认它们命中了预期代理组。

可以保留一份已验证可用的配置副本，并记录客户端名称、核心版本、Mixed Port、DNS 模式和出现问题的节点。下次再次遇到证书错误时，先比较这些项目，比清空全部设置或重新安装更容易定位差异。