先判断证书错误发生在哪一层
Clash 开启后浏览器出现“连接不是私密连接”“证书颁发机构未知”“证书名称不匹配”或 TLS 握手失败，并不等于 Clash 客户端直接修改了网站证书。标准的 HTTP CONNECT 或 SOCKS5 代理通常只负责建立到目标服务器的传输通道，HTTPS 加密与证书校验仍在浏览器和目标网站之间完成。正常情况下，浏览器看到的证书应当继续由目标网站及其受信任的证书机构签发。
Clash、Clash Meta（mihomo）以及基于这些内核的客户端，启用系统代理或 TUN 模式本身都不要求为普通 HTTPS 访问安装一张通用根证书。若证书签发者突然变成公司网关、安全检查程序、路由设备或陌生机构，应优先检查代理上游和本机网络中间层，而不是直接删除订阅或反复重装客户端。
开始排查前，先记录三个条件：哪些网站报错、关闭 Clash 后是否立即恢复、同一网络中的另一台设备是否也会报错。单个网站失败更像站点证书、域名解析或规则分流问题；大量网站同时失败更常见于系统时间、证书存储、上游代理和网络检查设备；只有某个浏览器失败，则应关注该浏览器的证书存储、扩展和安全设置。
常见错误与优先检查项
- 证书尚未生效或已经过期：先检查系统日期、时间、时区以及自动校时状态。
- 证书颁发机构不受信任：检查证书链是否完整，以及是否存在企业 HTTPS 检查或本机过滤程序。
- 证书名称不匹配：检查 DNS 解析、透明网关、登录认证页和规则分流结果。
- 握手失败或协议错误：检查代理节点可用性、上游协议参数、TLS Server Name、网络阻断和客户端日志。
- 仅部分子资源失败：在浏览器开发者工具中确认具体失败域名，避免把第三方接口故障误判为主站证书问题。
检查系统时间、时区与自动校时
TLS 证书带有明确的生效时间和到期时间。设备时间偏差数小时、数天甚至数年时，浏览器会把仍然有效的证书判断为尚未生效或已经过期。笔记本长时间断电、主板时钟异常、虚拟机暂停恢复、双系统切换以及手动修改时区，都可能造成此类现象。代理开启后访问了此前未连接的站点，错误才集中出现，因此容易被误认为是 Clash 导致。
- 确认系统显示的日期、时间和所在时区准确，特别检查 UTC 偏移是否符合当前位置。
- 打开系统的自动设置时间与自动设置时区功能，然后主动执行一次时间同步。
- 完全退出浏览器后重新打开，避免旧 TLS 会话或错误页面继续留在标签页中。
- 若自动同步失败，暂时关闭代理再同步一次，并检查时间服务是否被规则错误地转发。
Windows 时间检查
在 Windows 设置中进入“时间和语言”，确认自动设置时间与时区。也可在具有相应权限的终端中查询同步状态：
w32tm /query /status
w32tm /resync如果系统提示时间服务未运行，应先在服务管理中检查 Windows Time 服务。域环境中的设备可能由组织的时间服务器统一管理，此时不宜随意更改同步源。
macOS 与 Linux 时间检查
macOS 可在“系统设置—通用—日期与时间”中启用自动设置。使用 systemd 的 Linux 发行版可查看当前时间状态：
timedatectl status
sudo timedatectl set-ntp true容器或虚拟机中的应用通常继承宿主机时间。若只有虚拟机内部报错，应同时核对宿主机和来宾系统，确认恢复快照后时间已重新同步。
核对浏览器看到的证书链
证书链通常由网站证书、中间证书和受信任根证书组成。浏览器会检查访问域名是否包含在证书的主题备用名称中、证书是否在有效期内、签名链是否能够连接到本机信任的根证书，以及证书用途是否适合服务器身份验证。排查时不能只看错误页标题，应打开证书查看器记录具体字段。
首先查看网站证书的“颁发给”或主题备用名称，确认其中包含当前访问的域名。其次查看“颁发者”，与关闭 Clash 后看到的结果进行比较。如果两种状态下证书主题、序列信息或颁发者明显不同，说明流量路径中存在能够终止并重新建立 TLS 的中间层。它可能来自企业网络的合规检查、家长控制、安全软件的 HTTPS 扫描、调试代理，或订阅中配置的上游代理服务。
如果证书始终相同，但某个浏览器仍提示不受信任，应比较浏览器之间的结果。部分浏览器主要使用系统证书存储，另一些环境可能维护独立的证书数据库。系统更新不完整、根证书列表长期未更新、浏览器配置损坏，都可能使同一证书在不同程序中得到不同判断。
使用命令行查看握手结果
命令行工具可帮助区分浏览器配置与系统网络问题。下面的请求分别测试默认连接和通过本机 HTTP 代理端口连接，端口应按客户端实际配置修改：
curl -Iv https://example.com/
curl -Iv --proxy http://127.0.0.1:7890 https://example.com/比较输出中的证书主题、签发者、有效期和最终错误。如果直连成功而显式代理失败，应继续检查 Clash 选中的节点、代理组和上游链路；如果两者都失败，则更可能是系统时间、证书存储、DNS 或当前网络的问题。测试真实故障域名时，应避免在公开日志中暴露带有账号、令牌或查询参数的完整网址。
排查 Clash 代理链路与规则分流
Clash 的规则模式会按照配置文件中的规则顺序，为请求选择代理组、具体节点或 DIRECT。浏览器访问一个页面时，主域名、静态资源、登录接口和内容分发域名可能分别命中不同规则。若主页面走代理，而认证接口被直连到受限制或被重定向的地址，浏览器可能表现为证书错误、登录循环或部分资源握手失败。
打开客户端连接记录和内核日志，找到报错时间附近的目标域名，确认命中的规则、出口策略和节点。Clash Meta（mihomo）配置通常可通过面板查看实时连接；不同图形客户端的入口名称可能是“连接”“日志”“规则”或“代理”。重点不是反复切换全局模式，而是确定具体域名实际走了哪条路径。
按最小变量切换策略
- 保持原网络不变，将故障域名临时切换为 DIRECT，重新打开浏览器测试。
- 若直连正常，再让该域名经过另一个确认可用的节点，观察证书是否恢复。
- 若所有节点都失败，检查订阅中是否配置了统一的链式代理、外部控制程序或额外上游。
- 若只有一个节点失败，查看该节点的服务器地址、端口、传输参数、TLS Server Name 和系统时间。
- 测试完成后恢复规则模式，避免全局策略掩盖原本的规则顺序问题。
节点协议本身可能使用 TLS 连接代理服务器，这一层的证书与浏览器访问网站时看到的证书不是同一对象。节点日志中的“certificate verify failed”“x509”或“hostname mismatch”，通常表示客户端校验代理服务器证书失败；浏览器页面中的证书警告，则指向目标网站连接。区分这两层能够避免把节点服务器证书问题误当作网站证书问题。
如果节点配置使用域名作为服务器地址，TLS Server Name 通常应与服务端证书覆盖的名称一致。随意改成 IP 地址、填写另一个域名，或者上游服务端证书已经更换，都可能导致节点握手失败。此类参数应以服务提供方发布的有效配置为准，不应通过关闭节点证书校验来维持连接。
系统代理与 TUN 模式的区别
系统代理主要影响遵循操作系统代理设置的程序；TUN 模式通过虚拟网卡接管更广泛的 IP 流量，并配合路由与 DNS 处理不读取系统代理的应用。切换到 TUN 后，大量程序同时开始报错，常见原因包括 DNS 劫持配置冲突、其他 VPN 同时修改路由、安全软件过滤虚拟网卡，或局域网认证流量被接管。
TUN 模式不会因为接管范围更广就自动解密 HTTPS。如果只有开启 TUN 才出现证书名称不匹配，可暂时关闭 TUN、保留系统代理进行对照，再检查 fake-ip、DNS 监听、路由排除项以及其他 VPN。一次只改变一个选项，才能判断是路由、解析还是上游节点造成差异。
识别 DNS 异常、认证页面与网络劫持
证书名称不匹配经常意味着浏览器连接到了错误的服务器。公共 Wi-Fi、酒店和校园网络可能要求先完成网页认证。设备首次接入时，网关会把普通请求导向登录页；如果 HTTPS 请求也被拦截，认证页无法提供目标域名的合法证书，于是浏览器显示证书警告。此时应关闭代理，访问操作系统提供的网络检测页或一个普通 HTTP 页面完成认证，再重新启用 Clash。
DNS 返回错误地址也会造成相同表现。关闭与开启 Clash 时，解析可能分别由系统 DNS、客户端 DNS 模块、远端解析器或 fake-ip 机制处理。若某个域名只在一种状态下报错，可分别查询解析结果，并与可信网络中的结果比较。注意大型网站可能使用地域化地址，IP 不完全相同不一定代表异常，关键是地址归属、证书域名和访问结果是否合理。
nslookup example.com
dig example.com A
dig example.com AAAA家庭路由器的安全过滤、运营网络中的异常重定向、公司出口的 TLS 检查以及本机调试代理，都可能改变连接路径。最有效的交叉测试是让同一设备临时连接另一条可信网络，并保持 Clash 配置不变。如果更换网络后立即恢复，应检查原路由器的 DNS、访问控制、固件设置和上网认证状态；如果所有网络都失败，则回到本机证书存储、客户端配置和安全程序继续排查。
本机过滤程序与企业证书
部分企业环境会通过受管理的根证书检查 HTTPS 流量。在组织设备上，这张证书通常由管理员统一部署，浏览器会显示组织指定的签发者。若证书过期、部署范围遗漏，或浏览器使用独立证书库，就可能出现信任错误。此时应记录证书指纹之外的主题、签发者和有效期信息，交由网络管理员确认，不应自行删除组织证书。
个人设备若安装过抓包调试工具、流量分析工具或带 HTTPS 扫描功能的安全程序，也应检查它们是否仍在运行。退出界面不一定代表后台服务和本地代理已经停止，可在系统代理设置、进程列表和证书管理器中核对。确认软件来源和用途后，再通过其正式卸载流程移除相关网络组件。
分步恢复与结果验证
证书故障排查应从影响最小、最容易回退的操作开始。直接重置全部网络设置或删除所有证书会破坏现有环境，也会丢失关键证据。下面的顺序适合大多数 Clash 开启后 HTTPS 报错场景。
- 记录错误：保存浏览器错误代码、故障域名、证书主题、签发者、有效期和发生时间。
- 校准时间：确认日期、时区与自动同步状态，随后重启浏览器。
- 做开关对照：分别测试关闭 Clash、仅系统代理、仅 TUN 或原有模式，记录每次结果。
- 查看连接日志：确认目标域名命中的规则、代理组、节点与 DNS 解析路径。
- 替换单个出口：在不改变其他配置的情况下切换节点，判断故障是否跟随节点。
- 更换可信网络：排除路由器、公共网络认证和出口检查设备的影响。
- 检查中间程序：核对其他 VPN、本地调试代理、安全过滤和企业管理策略。
- 恢复配置：若近期修改过 DNS、TUN 或规则，使用修改前保留的配置逐项回退。
哪些情况应联系网站或服务提供方
如果同一网站在多台设备、多个网络、直连和代理环境下都显示相同的过期证书或不完整证书链，问题可能位于网站服务端，应等待站点维护或联系站点管理员。若错误只跟随某个代理节点，并且节点日志明确显示服务端证书名称或有效期异常，应向节点配置提供方反馈时间、节点名称和日志摘要。
反馈时不需要提交完整订阅地址、认证密钥或账号信息。提供客户端内核版本、操作系统、连接模式、错误发生时间、目标域名、规则命中结果和经过处理的日志即可。清晰区分“节点 TLS 握手失败”与“浏览器访问网站时证书警告”，能显著缩短定位时间。
恢复后仍需检查的配置
故障消失后，不要立即把原因归结为偶发现象。重新启用原来的规则模式，分别测试常用网站、软件更新、登录接口和不遵循系统代理的应用。如果曾临时关闭 TUN 或 DNS 模块，应逐项恢复并观察日志。若某条自定义规则使认证域名与主站走不同出口，可将相关域名放入同一策略组，同时保留规则顺序说明，便于订阅更新后复查。
对于经常切换公司网络、家庭网络和公共 Wi-Fi 的设备，可以保留一份基础配置用于对照：使用稳定的订阅、明确的 DNS 设置和较少的自定义规则。出现问题时先用基础配置复现，再逐步加入 TUN、脚本或自定义规则。这样的最小化测试比反复安装客户端更容易确定真正的故障层。