开启 Clash、Clash Meta（mihomo）客户端后，浏览器可能突然显示“连接不是私密连接”“证书不受信任”或“证书与域名不匹配”，应用也可能报告 TLS 握手失败。此类现象容易被直接归因于代理节点，但 HTTPS 验证涉及系统时间、目标网站证书、DNS 解析、操作系统信任库、上游网络设备和应用自身证书策略，代理只是改变了其中一段连接路径。

标准的 HTTP CONNECT、SOCKS5 或 TUN 转发不会自动解密 HTTPS 内容。客户端通常只负责把加密流量送往选定出口，网站证书仍由目标服务器提供。mihomo 的域名嗅探用于识别流量对应的主机名，也不等于替换网站证书。因此，排查重点不是反复导入订阅或盲目切换代理模式，而是先确认错误类型，再用对照测试定位异常发生在哪一层。

先看懂 HTTPS 证书错误属于哪一类

HTTPS 建立连接时，客户端会检查证书有效期、访问域名、签发链和用途。不同错误指向的原因并不相同。记录浏览器错误代码、出错域名、证书颁发者和有效期，比只保存“打不开”的截图更有帮助。

证书尚未生效或已经过期

这类错误首先检查电脑或手机的日期、时间、时区。系统时间偏差数月时，大量正常网站会同时失败；只有单个网站失败，则更可能是站点证书过期、服务器部署遗漏，或者某个出口访问到了尚未更新证书的边缘节点。自动校时开启后仍不正确时，还要确认系统选择的时区，而不只是钟表显示的小时数。

证书域名不匹配

证书中的主机名与地址栏域名不同，常见表现是证书签给另一个网站、网络登录页或内部网关。可能原因包括 DNS 返回错误地址、本地 hosts 规则覆盖、透明网关重定向、目标站点虚拟主机配置错误，以及代理出口连接到了异常服务器。若证书颁发给路由器管理域名、公共 Wi-Fi 登录域名或陌生企业网关，应优先检查当前网络是否要求认证。

证书颁发者不受信任或证书链不完整

服务器需要提供从站点证书到中间证书的完整链，系统再用内置信任根完成验证。旧系统的根证书库长期未更新、站点漏发中间证书、企业安全网关进行 HTTPS 检查，都可能触发此类错误。部分浏览器使用独立证书库，所以同一网站在不同浏览器中的结果可能不一致，这正是定位信任库问题的重要线索。

TLS 握手失败但没有明确证书页面

命令行工具或应用常只显示 handshake failed、certificate verify failed、unknown CA 等简短信息。还可能涉及客户端支持的 TLS 版本、服务器名称指示、应用证书固定、上游代理协议错误或连接被中途关闭。此时应结合 Clash 日志和应用日志判断：是在连接节点时失败、连接目标地址时失败，还是收到目标证书后验证失败。

用对照测试确定问题在设备、网络还是代理路径

有效的排查应一次只改变一个条件。若同时更换节点、DNS、TUN 设置和浏览器，就无法知道哪项变化真正影响结果。建议先选择一个稳定复现的域名，并记录当前配置名称、代理模式、策略组和所选节点。

  1. 关闭代理后访问同一域名。关闭客户端的系统代理和 TUN 接管，确认流量确实恢复直连。直连也报错时，优先检查系统时间、网站证书和当前网络。
  2. 保持配置不变，只切换节点。某个节点失败而其他节点正常，通常指向该出口的 DNS、上游网络、透明检查设备或目标网站针对不同地区返回的服务器。
  3. 保持节点不变，比较系统代理与 TUN。只有 TUN 模式异常时，检查 DNS 劫持、Fake-IP 映射、路由冲突和其他网络过滤软件；只有系统代理异常时，检查应用是否读取了独立代理设置。
  4. 换浏览器或命令行客户端测试。单个浏览器失败可能与浏览器证书库、扩展、缓存的 HSTS 状态或安全设置有关。所有应用均失败则更接近系统或网络层问题。
  5. 换设备但保持同一网络。只有一台设备失败，应检查该设备的时间、证书库和网络组件；同一网络内多台设备均失败，则检查路由器、公共网络认证和上游网关。
  6. 换网络但保持同一设备。家庭网络失败而移动网络正常，说明问题更可能位于本地 DNS、网关或运营商路径，而不是客户端配置本身。

系统时间、证书链与中间代理怎么检查

确认系统时间和证书有效期

先让系统与可靠时间源同步，再完全退出并重新启动浏览器。打开证书详情，检查“颁发给”“颁发者”“有效期起止时间”和证书路径。若当前日期不在有效期内，不要仅凭页面提示判断网站证书已过期；系统年份错误也会产生相同结果。

桌面系统长期停止更新时，根证书库也可能过旧。应通过操作系统正式更新机制更新证书信任数据，而不是从不明页面下载根证书手工安装。若单位网络要求安装内部根证书，应先向网络管理员核实证书指纹信息、适用设备和部署范围，再按组织流程处理。

识别 HTTPS 检查和中间代理

企业网关、家长控制、安全防护软件和调试代理可能终止原始 TLS 连接，再用本地受信任证书为目标域名签发临时证书。此时证书的域名可能正确，但颁发者变成组织名称或本地安全产品名称。若对应根证书未安装、已过期或仅安装在系统库而未进入浏览器独立证书库，就会出现不受信任错误。

普通 Clash 规则分流不会执行这种证书替换。若看到陌生颁发者，应检查系统中同时运行的抓包工具、过滤程序、杀毒软件 HTTPS 扫描、企业代理和上游 HTTP 代理。不要为了消除提示而随意导入页面提供的根证书，因为根证书一旦受信任，就可能用于签发任意网站证书。

用命令查看握手结果

系统已安装相应工具时，可以查看响应和证书链。以下命令中的域名应替换为实际出错站点，执行时保留证书验证，不添加跳过验证选项。

curl -Iv https://example.com/
openssl s_client -connect example.com:443 -servername example.com -showcerts

curl 输出可显示连接目标、代理隧道建立结果和证书验证原因；openssl s_client 可显示服务器返回的证书链。使用系统代理时，还应确认命令行工具是否实际读取了代理环境变量，否则它测到的可能仍是直连路径。测试结果中若证书颁发者随节点变化，说明不同出口到目标站之间存在路径差异；若颁发者始终相同而只有某个应用失败，应转向应用信任库与证书固定策略。

Clash 系统代理、TUN 与 DNS 对证书错误的影响

系统代理模式

系统代理通常让支持代理设置的应用通过 HTTP 或 SOCKS 接口连接。访问 HTTPS 网站时，HTTP 代理一般通过 CONNECT 建立到目标主机的隧道，TLS 握手仍在应用与网站之间进行。若 CONNECT 请求被上游代理拒绝、替换或要求额外认证，应用可能显示代理连接失败，也可能收到网关生成的证书页面。

有些应用不读取系统代理，而是直连；有些应用保留独立代理设置。出现“浏览器正常、特定应用失败”时，要确认该应用到底走了系统代理、TUN，还是自己的网络栈。Clash 日志里没有对应连接记录，往往说明流量根本没有进入客户端，而不是规则选择错误。

TUN 模式

TUN 模式在网络层接管更多流量，适合不支持系统代理的应用。它改变数据包的路由与 DNS 处理方式，但不会因为接管范围更广就自动解密 TLS。若开启 TUN 后出现证书域名不匹配，重点检查 DNS 模式、其他虚拟网卡、路由优先级，以及设备上是否同时运行另一个 VPN 或过滤服务。

多个网络组件同时接管流量时，数据包可能先进入一个过滤器，再进入 mihomo，返回路径也可能不一致。排查时应暂时只保留一个流量接管组件，确认问题消失后再逐项恢复。移动设备通常只能有一个主要 VpnService，会话被另一个应用替换时，还可能表现为断流而不是明确的证书错误。

Fake-IP、域名嗅探与证书域名

Fake-IP 模式会先向应用返回保留地址，再由内核根据映射找到原始域名并建立连接。这个过程本身不会让网站证书变成 Fake-IP 地址，因为浏览器仍按原始访问域名验证证书。真正需要关注的是映射过期、DNS 请求绕过客户端、特殊应用直接校验证书或连接地址，以及不恰当的 hosts 覆盖。

域名嗅探可以从 TLS ClientHello 等信息识别主机名，帮助规则匹配，但嗅探不是证书签发，也不负责改变系统信任。若关闭嗅探后错误消失，应进一步检查规则命中、目标地址恢复和特殊域名排除，而不是安装额外根证书。对于局域网服务、私有域名和使用自签名证书的设备，可根据实际用途设置直连与 DNS 例外，但证书仍应按组织或设备的正规方式部署。

按风险和成本排序的修复步骤

下面的顺序从低风险、易验证的操作开始，适合大多数“开启代理后 HTTPS 证书报错”的场景。每完成一步都重新测试同一域名，并记录结果。

  1. 修正日期、时间和时区。开启自动同步，重启发生错误的应用。若大量网站同时提示过期或尚未生效，这一步优先级最高。
  2. 确认错误是否仅发生在单个网站。单站异常可查看站点证书有效期与域名，等待站点管理员修复；不要通过关闭全局验证来迁就单个站点。
  3. 完成公共网络登录。关闭代理后打开普通网络检测页面，确认酒店、校园或商场网络没有等待认证。登录完成后再恢复代理。
  4. 切换到已知正常的节点。若只有特定出口失败，暂时移出该节点，并向服务提供方反馈目标域名、时间和节点名称。
  5. 检查 Clash 规则命中与日志。确认目标域名进入了预期策略组，避免规则将其送往不可用的上游代理。日志中的 DNS 失败、连接拒绝和 TLS 错误应分别处理。
  6. 比较系统代理与 TUN。确定异常是否只存在于一种接管方式，再检查对应代理设置、虚拟网卡、DNS 和路由，而不是同时修改全部配置。
  7. 停用冲突的网络过滤组件后复测。一次只停用一个 VPN、抓包代理或 HTTPS 过滤功能，并在测试后按需要恢复。
  8. 更新操作系统与浏览器。让根证书库、TLS 组件和浏览器信任数据处于受支持状态。旧版应用可能无法识别新的证书链。
  9. 核实组织内部证书部署。企业或学校网络使用内部 CA 时，应由管理员提供正式安装方式，不应从错误页面临时下载证书。
  10. 最后再检查或重建客户端配置。只有日志显示 DNS、规则或上游代理配置异常时，才需要调整 YAML、订阅或配置文件。重新导入同一份有问题的配置不会改变证书链。

常见误区与进一步判断

反复切换全局、规则和直连模式

模式切换只能改变流量选择哪个策略，不会修复系统时间或根证书库。它的价值在于对照：直连正常而代理失败，说明应检查出口与代理路径；三种模式均失败，则先处理设备或网络环境。测试后应恢复原模式，避免后续结果混乱。

把所有 TLS 错误都归结为 DNS

DNS 确实可能把域名指向错误服务器，从而产生域名不匹配，但“不受信任的颁发者”更常指向证书链或 HTTPS 检查。先看实际证书内容，再决定是否清理 DNS 缓存、切换解析器或检查 Fake-IP。只改 DNS 无法修复过期证书和缺失的中间证书。

看到自签名证书就直接安装

家庭路由器、开发环境和企业内部服务可能使用自签名证书，但安装前必须确认服务归属和证书来源。公共网站突然出现自签名证书通常不是正常现象。若证书来自陌生网关，应停止输入账号信息，并检查网络认证、代理设置和设备中的根证书变化。

只有某个应用失败

银行、支付、流媒体和部分企业应用可能使用证书固定，只接受预置的服务器公钥或证书链。即使系统信任某个中间代理签发的证书，应用仍会拒绝连接。这通常说明流量路径中存在 TLS 检查或目标连接被替换。应让该应用绕过相关检查设备，或按组织网络规范配置，而不是尝试修改应用验证逻辑。

完整的判断过程可以归纳为四个问题：证书是谁签发的、错误是否随设备变化、错误是否随网络变化、错误是否随节点或接管模式变化。回答这四项，通常就能把范围缩小到系统时间与信任库、目标网站、当前网络、特定代理出口或本机流量接管组件。修复的目标是恢复正确的证书链和连接路径，而不是让警告页面暂时消失。