跳过导航,阅读正文

开启 Clash 后浏览器提示证书错误:NET::ERR_CERT 报错原因与处理

开启代理后网页提示「您的连接不是私密连接」,常见原因有系统时间偏差、MITM 设置残留、DNS 污染和节点劫持。本文按症状逐项区分,并给出对应的处理办法。

先记录证书报错,不要点击继续访问

Chrome 或 Edge 出现「您的连接不是私密连接」时,先记下页面底部的完整错误代码。NET::ERR_CERT_DATE_INVALID 与 NET::ERR_CERT_AUTHORITY_INVALID 指向的检查方向不同,不能统一按“节点坏了”处理。若地址栏属于支付、邮箱、企业登录或管理后台,立即停止输入密码。

常规 Clash、Clash Meta(mihomo)代理转发不会为目标网站重新签发证书。浏览器通过 HTTP 代理建立 CONNECT 隧道,或由 TUN 接管流量后,HTTPS 通常仍在浏览器与目标网站之间建立。开启代理不需要先安装一个来源不明的根证书。

把这四项信息记下来

按 NET::ERR_CERT 错误代码缩小范围

错误代码主要含义优先检查
NET::ERR_CERT_DATE_INVALID证书尚未生效或已经过期,也可能是设备时间错误。系统日期、时间同步,以及证书起止日期。
NET::ERR_CERT_AUTHORITY_INVALID浏览器无法建立到受信任根证书的验证链。自签名证书、缺失的中间证书、HTTPS 检查软件及根证书策略。
NET::ERR_CERT_COMMON_NAME_INVALID访问的主机名与证书覆盖的名称不匹配。SAN、错误解析、门户跳转,以及网站服务器配置。
NET::ERR_CERT_REVOKED证书被判定为已吊销。网站证书状态及本机安全软件,不应通过放宽验证继续访问。

错误名称中的 COMMON_NAME 不代表只检查证书的 CN 字段。现代浏览器主要依据 SAN 验证主机名。例如访问 www.example.com,却拿到只覆盖 portal.example.net 的证书,主机名验证就不会通过。

ERR_SSL_PROTOCOL_ERROR、ERR_TUNNEL_CONNECTION_FAILED 与上述证书错误也不是同一类。前者可能发生在 TLS 协议协商阶段,后者可能是代理隧道未建立;这时未必已经取得目标网站证书,应先查看客户端连接记录与日志。

日期错误:先校准系统时间,再检查网站有效期

如果许多网站同时出现 NET::ERR_CERT_DATE_INVALID,优先查看任务栏时间。设备长期关机、电池异常、手动改过年份,都会让正常证书看起来过期或尚未生效。单纯时区显示不同不一定会导致错误,关键是系统实际时间是否准确。

  1. Windows 11:打开「设置」→「时间和语言」→「日期和时间」,开启「自动设置时间」,检查时区,再在「其他设置」中点击「立即同步」。
  2. macOS:打开「系统设置」→「通用」→「日期与时间」,开启「自动设置时间与日期」。
  3. Android:在系统设置中搜索「日期和时间」,开启自动设置时间;不同厂商的菜单位置可能不同。
  4. 校准后完全退出浏览器再打开,重新访问同一网址;若设备重启后时间再次漂移,继续检查系统同步服务或硬件时钟。

如果系统时间正确,只有某一个网站失败,就查看该站证书的有效期。证书确实过期应由网站维护者续期;换节点可能恰好连到另一台服务器,但不能替网站完成证书修复。记录失败域名、时间和证书有效期,反馈给网站维护者更有效。

颁发者异常:检查 MITM、抓包工具与安全软件残留

若多个无关网站的证书都显示同一个陌生颁发者,应检查是否有软件在进行 HTTPS 解密。MITM 指中间人方式的流量检查;调试代理、企业网关与部分安全软件可以用本地受信任证书重新签发站点证书。这与 Clash 的常规流量转发是两回事。

先停用重签功能,再核对证书来源

  1. 退出曾用于抓包的 Fiddler、Charles、mitmproxy 等工具,并在对应工具中关闭 HTTPS 解密或 SSL Proxying。仅关闭窗口不一定代表后台进程已结束。
  2. 检查安全软件的 HTTPS 扫描、加密连接检查功能。个人设备可以临时停用该功能作对照,测试后按产品文档恢复;受管理设备应先联系管理员。
  3. Windows 按 Win + R 输入 certmgr.msc,查看当前用户的「受信任的根证书颁发机构」→「证书」。计算机级证书可通过 certlm.msc 查看。
  4. macOS 打开「钥匙串访问」,分别检查「登录」和「系统」钥匙串中的证书与信任设置。

根证书仍在并不代表正在发生重签,还需要对应代理或检查服务参与连接。反过来,重签服务仍在、信任证书却已经删除,也会出现颁发机构不受信任。因此应同时检查代理入口、运行进程和证书,而不是只在证书管理器中反复增删。

名称不匹配:区分 DNS 异常、门户网络与网站配置

NET::ERR_CERT_COMMON_NAME_INVALID 常见于请求去了错误的服务器,但不能仅凭这一条就认定 DNS 被污染或节点劫持。网站 CDN 配置错误、公共 Wi-Fi 登录门户、手动输入了 IP 地址,也可能产生同样结果。

先检查本机覆盖,再看实际解析路径

Windows 可以用以下命令查看系统默认解析器返回的结果,并在修正 hosts 或系统 DNS 后清理系统缓存。这里的域名仅作命令示例,排查时换成实际出错域名。

nslookup example.com
ipconfig /flushdns

nslookup 不能单独证明浏览器实际用了哪一个地址。开启 mihomo 的 TUN、DNS 劫持或 fake-ip 后,查询路径可能被接管;fake-ip 模式返回 198.18.0.0/16 范围内的合成地址也不必然异常。应结合当前配置中的 dns、enhanced-mode、fake-ip-range 和客户端连接记录判断。

不要一边修改 DNS、一边换节点、一边清理缓存。每轮只改一项,关闭旧连接再重试。CDN 在不同网络返回不同 IP 很常见,IP 不同本身不能作为污染证据;证书是否覆盖请求域名,才是这里需要核对的关键。

用直连与节点对照,定位代理链路问题

当问题只在开启代理后出现,可以做一次受控对照。选择不需要登录的公开页面,记录同一域名在直连、节点 A、节点 B 下的结果。使用自动选择策略组时,实际节点可能发生切换,因此需要在连接记录中确认最终出站,而不是只记录策略组名称。

  1. 保存现场:记录当前配置、规则模式、系统代理和 TUN 开关状态。先暂停其他 VPN、抓包代理,避免链路叠加。
  2. 直连测试:关闭 Clash 的系统代理与 TUN;确认系统没有残留手动代理或自动配置脚本,再退出客户端并重开浏览器。仅退出客户端不一定会自动清除所有代理设置。
  3. 代理测试:恢复原配置,用固定节点访问同一域名,在连接记录中核对命中的规则与出站。
  4. 替换单一变量:保持规则和 DNS 设置不变,只换另一条可信节点,再比较证书名称、颁发者和错误代码。

需要命令行对照时,明确指定本地端口

下面是假设客户端显示 HTTP 或混合端口为 7897 时的 Windows 示例;实际端口以客户端为准。显式代理测试先关闭 TUN,避免所谓“直连”仍被透明接管。macOS、Linux 通常将命令名改为 curl 即可。

curl.exe -I -v --connect-timeout 10 --max-time 20 --noproxy "*" https://example.com/
curl.exe -I -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7897 https://example.com/

第一条绕过显式代理,第二条指定本地 HTTP 代理。不要添加 -k 或 --insecure,否则会绕过本次要检查的证书验证。-I 发送 HEAD 请求,个别网站返回 405 不等于证书错误;如果已经收到 HTTP 响应,说明这次 TLS 验证阶段通常已通过。

curl 与浏览器使用的信任库、代理路径可能不同,因此命令成功不能替代浏览器测试。分享 -v 输出前,删去认证头、Cookie、内网地址等敏感信息。也不要为了测试把订阅链接粘贴进命令行或公共检测网站。

根据对照结果决定下一步

恢复设置与复测:不要把跳过验证留在配置里

配置中的 skip-cert-verify: true 不是浏览器证书错误的通用修复。对于使用 TLS 的代理协议,该字段通常控制内核是否验证代理服务器证书,而不是让浏览器信任目标网页。修改它可能削弱节点连接的身份验证,却无法修复网页证书的域名、有效期或信任链问题。

同样,TUN 主要改变流量接管路径,本身不会替网站签发证书。开启 TUN 后才出错,应查流量是否走到不同节点、DNS 是否被接管、是否与另一款 VPN 冲突,而不是立刻给系统安装证书。

证书错误的处理顺序可以固定为:看完整代码,查系统时间,查证书颁发者与名称,再做直连和节点对照。这样能把本机信任问题、网站配置问题与代理链路问题分开,避免用换配置或关闭验证反复碰运气。

Clash 安装包