开代理后网页提示证书错误:HTTPS 证书报错的常见成因与逐项排查

先保留证书校验，再定位是哪一段连接出错。普通的 HTTP CONNECT 或 SOCKS 转发通常不需要解密网页 HTTPS；Clash 客户端正常转发流量，也不要求给浏览器安装根证书。开代理后突然报错，说明连接路径发生变化，但不能直接据此判断客户端损坏或节点劫持。

1. 先分清：网页证书错误，还是节点 TLS 握手失败

同样写着 certificate，报错位置不同，处理对象就不同。浏览器检查的是目标网站证书；使用 TLS 的代理协议还可能由内核检查节点服务器证书。两者不能混为一谈。

报错位置与内容	通常指向	先检查什么
浏览器 `NET::ERR_CERT_DATE_INVALID`	证书有效期与设备时间不符	系统日期、时区、证书起止日期
浏览器 `NET::ERR_CERT_COMMON_NAME_INVALID`	访问域名与证书名称不符	地址栏域名、证书 SAN、DNS 与认证门户
浏览器 `NET::ERR_CERT_AUTHORITY_INVALID`	证书链无法连接到受信任的根	颁发者、系统信任库、抓包或安全软件
客户端日志 `x509: certificate signed by unknown authority`	某次 TLS 连接的证书链不被内核信任	同一条日志中的目标地址及连接用途
客户端日志 `x509: certificate has expired or is not yet valid`	所连接服务证书过期、尚未生效，或本机时间异常	时间同步、节点或订阅服务器证书

日志里的 TLS 错误也可能来自订阅下载、测速地址或加密 DNS 服务，而不是节点。记录完整的目标主机名、出错时间和操作，不要只截取 x509 一行。若浏览器显示 ERR_PROXY_CONNECTION_FAILED，应先查本地监听端口和客户端是否运行，而不是修改证书。

2. 最先检查系统时间与证书有效期

时间不正确会让大量正常网站同时失败。电脑长时间关机、虚拟机恢复快照、主板电池异常后，都值得优先检查。只看任务栏上的小时数不够，还要核对年份、日期和时区。

Windows 11：进入「设置」→「时间和语言」→「日期和时间」，打开「自动设置时间」，核对时区，然后点击「立即同步」。
macOS：进入「系统设置」→「通用」→「日期与时间」，检查「自动设置时间与日期」及自动时区选项。
Android：原生系统通常在「设置」→「系统」→「日期和时间」；其他厂商可能放在「更多设置」。检查自动日期时间与自动时区。
从浏览器错误页的「高级」或证书查看入口读取有效期。界面名称随浏览器版本变化，重点记录「生效时间」「到期时间」。

如果只有一个网站报过期，而设备时间准确、其他网站正常，多半需要网站维护者更新证书。切换节点不会让过期证书重新有效。如果大量网站在同一分钟开始报错，先排查系统时间或统一拦截软件，比反复更新订阅更有效。

3. 固定测试条件，比较直连与代理路径

用同一个完整 HTTPS 地址测试，每次只改变一个条件。不要同时换节点、改 DNS、打开 TUN，否则无法判断哪项操作产生了变化。先记录当前规则模式、选中节点、系统代理状态与 TUN 状态。

建议按这四步做对照

关闭 Clash 客户端的系统代理和 TUN，确认没有其他 VPN 或浏览器代理扩展接管流量，再访问目标网站。
只打开系统代理，保持 TUN 关闭，使用原节点重试。到客户端「连接」页面核对目标域名实际走的是节点还是 DIRECT。
保持其余设置不变，仅换成另一个已知可用的节点，再访问同一地址。
改用手机热点，在相同客户端设置下复测。此步骤主要区分当前局域网与设备自身的问题。

直连本来不可达时，直连失败没有证书层面的比较价值；不要把超时与证书错误记成同一种结果。普通隐私窗口也不等于干净的证书环境，它仍可能使用系统根证书，并不能排除企业安全软件。

用命令查看握手信息

以下为 Windows PowerShell 示例。7890 只是示例端口，执行前替换成客户端当前的 HTTP 或混合监听端口；不要照搬到仅提供 SOCKS 的端口。第二条测试需要客户端正在监听该端口，并确认环境变量 NO_PROXY 没有让测试域名绕过代理。

PowerShell · 直连与显式 HTTP 代理

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

这里没有使用跳过证书校验的参数。第一条只绕过应用层代理；若 TUN 仍在运行，流量依然可能被接管，因此必须先关闭 TUN 才能做直连对照。不同 curl 构建使用的信任库不同，结果应与浏览器证书详情一起看，不能凭一次命令成功就排除浏览器信任库问题。

4. Fake-IP 与 DNS：确认域名有没有被送到错误服务器

Fake-IP 本身不会替换网站证书。在 mihomo 的 Fake-IP 模式中，DNS 返回合成地址，内核保存域名与地址的映射，再根据连接执行路由。配置使用 198.18.0.1/16 时，查到该范围的地址可能是预期结果；它不等于公网服务器真实地址，也不能直接视为 DNS 污染。

DNS 被篡改、路由指向错误服务，或者旧连接与映射状态不一致，都可能让浏览器拿到不属于当前域名的证书。另一方面，很多错误映射只会导致超时，未必出现证书告警。需要用证书名称和实际连接记录交叉判断。

先查证据，再改解析策略

在 Windows PowerShell 执行 Resolve-DnsName example.com，观察返回地址；把示例域名替换为实际报错域名。
打开客户端「连接」或日志视图，核对域名、匹配规则、出站节点。系统命令查询的 DNS 不一定就是浏览器使用的 DNS。
Chrome 的「设置」→「隐私和安全」→「安全」中可检查「使用安全 DNS」。只为对照测试暂时调整，并记录原值；DoH 流量仍可能经过 TUN。
若刚切换 DNS 模式，先关闭相关网页和浏览器连接，必要时重启客户端；Windows 可执行 ipconfig /flushdns 清理系统 DNS 缓存。它不会自动清掉所有浏览器缓存和内核映射。

下面只是 mihomo DNS 配置片段，用于辨认字段，不是修复证书错误的完整配置。DNS 上游、路由与客户端覆写仍需按现有环境设置。

YAML · DNS 字段示意

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

若某个应用确实不兼容 Fake-IP，可在确认原因后评估 fake-ip-filter，而不是把所有域名全部排除。订阅托管的配置应通过客户端支持的覆写机制修改，避免下次更新恢复原值。更多配置入口见进阶配置。

5. 中间人抓包证书、企业 HTTPS 检查与公共 Wi-Fi

如果多个互不相关的网站都显示同一个本地组织或安全产品作为颁发者，应检查 HTTPS 检查功能。Fiddler、Charles、mitmproxy 等调试工具可以在安装并信任其根证书后解密 HTTPS；部分企业网关和终端安全软件也有类似机制。这与 Clash 客户端普通转发 HTTPS 是两回事。

如何检查证书来源

在错误页面或证书查看器中记录主题备用名称（SAN）、颁发者、有效期及证书链。SAN 应覆盖地址栏访问的域名。
退出抓包工具，并检查系统代理是否仍指向它的监听端口。关掉工具窗口不代表系统代理已经还原。
Windows 可用 certmgr.msc 查看当前用户证书；certlm.msc 查看本地计算机证书通常需要相应权限。macOS 可在「钥匙串访问」中查看证书及信任设置。
个人设备只处理已经确认来源的调试证书。受管理的办公设备先联系管理员，不要直接批量删除企业根证书。

浏览器与命令行工具的证书信任来源可能不同，所以可能出现浏览器正常、curl 报错，或反过来的情况。补装根证书之前，先确认这套 HTTPS 检查是否确实属于设备管理策略，以及证书来源是否可信。

6. 只有某个节点报错：核对 SNI 与证书链

如果相同设备、相同网站、相同 DNS 设置下，只要切到某个节点就报错，应暂时停止使用该节点，并区分两种现象：客户端连不上节点，还是节点连接成功后浏览器收到异常网站证书。

客户端日志报节点 TLS 错误

对采用 TLS 的节点，连接地址与用于证书验证的名称可能不同。mihomo 不同协议使用的字段也不完全相同：例如 VMess、VLESS 常见 servername，Trojan 常见 sni。应依据该协议文档及服务方提供的参数核对，不能把一个字段名套到所有节点。

连接地址填写 IP 时，证书未必包含该 IP 的 SAN；应由服务方提供正确的服务器名称和连接参数。
若日志显示证书过期或链不完整，应由节点维护者更新证书、补齐中间证书，用户侧不能用改规则修好服务器证书。
skip-cert-verify 只影响相应节点连接的验证，不会修复浏览器对目标网站证书的验证。不要把它改成 true 来掩盖报错。

浏览器收到异常网站证书

普通转发节点没有目标网站的私钥，不能凭空签出浏览器信任的网站证书。异常证书可能意味着错误 DNS、出口网络的认证或拦截、远端配置错误，也可能涉及恶意干预。仅凭一次报错不能定性为劫持，但足以暂停该路径上的敏感操作。

保留该节点下的证书信息，再用另一可信网络或节点作对照。不同 CDN 出口可能合法使用不同证书和颁发机构，不能只因颁发者不同就认定劫持；关键是域名覆盖、有效期、可信证书链以及重复测试结果。

7. 按结果收尾：修复、复测与求助记录

完成一项修复后，回到最初报错的完整网址复测，再检查另一个独立网站。网页能打开只是第一步，还要确认规则模式、系统代理与 TUN 已恢复到预期状态，没有留下为了测试而启用的全局路由或临时 DNS 设置。

对照结果	优先处理方向
所有网络、多个网站都报日期错误	校准设备时间，再检查系统更新与信任库
仅一个网站在不同路径均报过期	联系网站维护者，不绕过校验
仅当前 Wi-Fi 异常，热点正常	检查认证门户、网关 DNS 与网络 HTTPS 检查
仅一个节点异常	停用该节点，核对节点 TLS 参数与出口路径
仅一个浏览器异常	检查浏览器策略、扩展、专用信任库与安全 DNS

提交问题时附上这些信息

系统版本、Clash 客户端名称与版本、mihomo 内核版本。不要只写“最新版”。
完整错误码、发生时间，以及报错来自浏览器还是客户端日志。
目标域名、证书 SAN、颁发者、有效期；隐去网址查询参数中的个人信息。
系统代理与 TUN 状态、实际监听端口、规则模式，以及直连／节点 A／节点 B 的对照结果。
与问题对应的少量日志，先删除订阅地址、访问令牌、节点密码和外部控制密钥。

排查顺序可以固定为：错误位置 → 系统时间 → 路径对照 → DNS 与证书来源 → 节点参数。这样每一步都有证据，不需要一开始就重装客户端或大改 YAML。基础导入与代理设置可参照使用文档；常见连接故障可继续查看帮助中心。