代理证书错误排查

先判断证书错误发生在哪一层

开启代理后出现证书警告，不等于 Clash 需要安装根证书。普通 HTTP CONNECT、SOCKS 和 TUN 转发通常只改变流量路径，浏览器仍应与目标网站完成 TLS 握手并验证网站证书。先核对报错代码、证书对应的域名和签发者，再检查系统时间与实际出口，比直接重装客户端更有效。

这里存在两条不同的加密连接：一条是浏览器到目标网站的 HTTPS，另一条可能是代理内核到节点服务器的 TLS。浏览器显示 NET::ERR_CERT_AUTHORITY_INVALID，与内核日志出现 x509: certificate signed by unknown authority，不能直接当成同一个故障处理。

记录 NET::ERR_CERT 的完整后缀

“您的连接不是私密连接”只是提示标题，后面的错误代码才有定位价值。Chrome 与 Edge 的代码较接近，Firefox 的命名不同，但核查方向类似。浏览器版本、系统信任库和企业策略也会影响具体提示。

• NET::ERR_CERT_DATE_INVALID：本机时间不正确，或证书已经过期、尚未生效。先比较本机日期与证书的有效期，不要只看右下角的小时数。
• NET::ERR_CERT_AUTHORITY_INVALID：无法建立受信任的签发链，可能涉及自签名证书、缺失中间证书、本机信任库异常或 HTTPS 检查工具。
• NET::ERR_CERT_COMMON_NAME_INVALID：访问域名不在证书的主题备用名称（SAN）范围内。旧错误名里的 Common Name 不代表现代浏览器只检查 CN 字段。
• NET::ERR_CERT_REVOKED：证书被判定为已吊销。应由站点或相关管理方更换证书，不宜通过降低浏览器校验要求处理。

证书详情至少记下四项

通过警告页提供的证书入口，或浏览器地址栏的站点信息面板，查看访问域名、SAN、签发者、有效期。不同版本入口可能不同，不能打开详情时，可先保留报错代码与访问时间。若多个互不相关的网站都突然由同一个陌生组织签发，优先怀疑中间人解密，而不是这些网站同时换错证书。

反过来，签发者相同也不是单独定罪的依据：许多网站本就使用同一家公共 CA。需要结合证书链、访问域名、网络环境和是否安装过 HTTPS 检查软件判断。

第一步：校准时间并建立对照

先同步系统时间

Windows 11 可进入「设置」→「时间和语言」→「日期和时间」，检查「自动设置时间」并点击「立即同步」。macOS 可进入「系统设置」→「通用」→「日期与时间」检查自动设置。重点确认年月日、时区以及同步是否成功；仅把显示时区改成另一个地区，不能修复底层系统时钟偏差。

休眠恢复、双系统切换、虚拟机时间漂移，都可能让证书看起来“尚未生效”。修正时间后重新建立连接再测试。如果只有一个站点仍报过期，而其他 HTTPS 网站正常，应检查该站证书本身，避免继续改动全局设置。

对同一网址做四组测试

1. 记录完整网址、报错时间，以及当前客户端是规则模式还是全局模式。
2. 保持网址不变，关闭系统代理；若同时启用了 TUN，也应明确关闭它，再测试一次。
3. 重新开启原有代理路径，只切换一个节点，观察证书错误是否跟随节点变化。
4. 在允许的情况下，用手机热点或另一台设备测试同一网址，区分本机问题与网络问题。

一次只改变一个变量。系统代理关闭后，浏览器扩展仍可能指定代理；TUN 关闭后，系统代理也可能继续工作。判断“已经直连”应结合客户端连接记录，而不只是看某个开关。直连不可达只能说明对照缺少结果，不能证明代理路径一定安全或一定有问题。

第二步：检查中间人解密与认证网络

杀毒软件的“HTTPS 扫描”、抓包工具、企业网关和部分调试代理，会先终止浏览器 TLS，再为目标域名签发一张本地证书。浏览器不信任对应根证书时会报警；即使已经信任，也应确认这是不是自己预期的管理策略。

• 个人设备：回想近期是否启用过抓包工具、安装网络防护软件或导入证书。通过相应软件的设置恢复原有 HTTPS 检查状态，不要批量删除系统根证书。
• 公司或学校设备：对照签发者名称与组织说明，联系管理员确认根证书部署及代理策略。不要私自删除受管证书或绕过组织访问控制。
• 酒店、机场与访客 Wi-Fi：先通过系统弹出的网络登录入口完成认证。认证网关若错误拦截 HTTPS，可能返回域名不匹配的证书；不要在被劫持的 HTTPS 警告页输入账号。

第三步：核对节点、DNS 与实际规则

先查连接记录，再改规则

规则模式按规则顺序选择策略组，策略组名称并不等于最终节点。应在客户端的连接记录或日志中找到目标域名，核对命中规则、策略链和最终出口。不同客户端入口名称有差异，通常为「连接」或「日志」；如果只看到策略组名称，还需确认组内当前选项。

DNS 解析错误可能把请求引向错误服务器，后者返回不匹配的证书；但 DNS 异常也经常表现为解析失败或超时。使用 fake-ip 时看到 198.18.0.0/16 范围的映射地址，并不自动意味着 DNS 被污染，mihomo 可通过映射恢复域名并继续转发。

若仅某个节点触发错误，而另一个节点正常，应比较两条路径实际收到的证书。出口网络干预、CDN 边缘配置和目标站区域服务差异都可能参与其中。“换节点后恢复”是定位线索，不是节点窃取流量的充分证据。不要为了试错同时更换 DNS、切全局模式、启用 TUN 和改写规则，否则很难复现。

内核日志里的 x509 应检查节点配置

如果网页只是无法连接，客户端却对节点服务器记录了 x509 错误，核查的是节点 TLS 层。证书域名、连接地址与 SNI 不一定相同：例如节点用 IP 建连，但由服务商提供的域名完成服务器名称验证。应对照服务商的有效配置，不要猜一个热门域名填入。

mihomo 的节点 TLS 选项中可能出现 skip-cert-verify。将其设为 true 会跳过相关节点证书验证，既不能修复浏览器收到的目标站证书，也会降低节点身份验证保障。正确处理通常是修正证书链、服务器名称或服务端证书，而不是把该选项当作通用开关。

第四步：用 curl 区分隧道与证书故障

命令行对照能补充浏览器提示，但必须先确认真实监听端口。下面以本地 HTTP 或 mixed 端口 7890 为例，端口来自示例，不代表所有客户端默认值。目标为 https://example.com/，复现实际问题时请改为不含令牌的目标网址。

# 不使用显式代理；若 TUN 仍开启，流量仍可能被接管
curl -Iv --noproxy "*" https://example.com/

# 明确通过本机 HTTP 代理建立 CONNECT 隧道
curl -Iv --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/

Windows PowerShell 中建议将命令里的 curl 写成 curl.exe，避免部分环境将其解析成其他命令。-I 请求响应头，-v 输出连接诊断；个别网站不支持 HEAD 方法时，可以去掉 -I 并将响应正文重定向到本地空设备。

不要添加 -k 或 --insecure 来宣称“问题已修复”。这些参数跳过证书验证，只会改变测试条件。另外，curl 与浏览器可能使用不同的 TLS 后端、信任库或 DNS 路径；一边成功、一边失败时，应继续核查差异，而不是只相信其中一个结果。

最后处理浏览器状态与站点证书链

缓存并不是证书错误的首要解释。清空所有浏览记录通常无法修复已过期证书、错误域名或不受信任的签发者。更稳妥的顺序是先关闭相关标签页、完全退出浏览器后重试，再用临时新配置文件或另一款浏览器对照。

• 只有一个浏览器失败：检查浏览器更新、扩展代理、企业策略与证书信任配置。无痕窗口仍可能受系统代理、组织策略或获准运行的扩展影响，不能视作完全隔离环境。
• 只有旧设备失败：检查操作系统支持状态和信任库更新。不要随意从论坛下载根证书补丁；应优先使用系统与浏览器提供的更新渠道。
• 多个设备、多个网络都对同一站点报错：站点证书过期、缺少中间证书或 CDN 某个边缘节点部署错误的可能性上升。记录域名、时间和证书信息交给站点维护者。
• 清理状态后短暂恢复又复现：继续核对连接复用、DNS 结果和实际节点变化，避免把时间上的先后误判为缓存修复。

启用 HSTS 的网站会要求使用 HTTPS，浏览器可能不提供继续访问按钮。这是安全策略在生效，不建议删除 HSTS 状态来绕过错误。真正的修复标准是：在正常证书验证开启的情况下，浏览器可以完成连接，证书覆盖目标域名且有效期、签发链都正常。

排查结果与后续处理

1. 校时后所有站点恢复：检查时间同步服务、休眠或双系统切换问题，保留正常证书验证设置。
2. 只在受管网络出现统一签发者：联系管理员确认 HTTPS 检查部署，不自行导入来源不明的根证书。
3. 错误跟随单一节点：保留节点标识与脱敏日志，切换到验证正常的路径，并向服务方反馈。
4. 仅订阅更新报错：核对订阅域名及其证书，确认更新请求是否经过代理；不要把私密订阅链接贴到公共检测网站。
5. 所有路径都只有一个网站失败：向站点维护者提交证书有效期、SAN 和复现时间，等待其修复证书部署。

给维护者的有效信息包括：操作系统版本、浏览器版本、客户端与内核版本、完整错误代码、发生时间、受影响域名，以及切换节点或网络后的对照结果。客户端版本和内核版本应分开记录，界面相似不代表证书处理路径完全一致。更多操作入口可查看使用教程，通用连接问题可查阅常见问题。

结论：先确定错误属于浏览器、节点 TLS 还是订阅请求，再依次检查时间、证书签发者、实际出口与本机状态。证书验证通过才是恢复标准，忽略警告或关闭校验不属于修复。