开启 Clash、Clash Meta（mihomo）或其他代理客户端后，浏览器可能显示“连接不是私密连接”“证书无效”“证书过期”或 NET::ERR_CERT_AUTHORITY_INVALID。这类提示看起来都与 HTTPS 有关，但触发位置可能完全不同：有时是电脑日期偏差导致证书被判断为尚未生效，有时是目标站点的证书链不完整，也可能是当前网络对 TLS 连接进行了检查，或者代理规则把请求送到了不合适的出口。
排查时不要一看到证书警告就直接点击继续访问。HTTPS 证书用于确认访问的域名、连接的加密身份以及证书签发关系，忽略警告可能把真正的网络拦截、错误出口或域名劫持隐藏起来。更高效的办法是先记录报错原文和出问题的域名，再逐层比较“关闭代理”和“开启代理”时的结果，最后才检查客户端的证书相关选项。
先判断：证书错误到底说明了什么
浏览器访问 HTTPS 网站时，会校验证书是否覆盖当前域名、是否处于有效期、是否能沿着受信任的证书链找到根证书，以及连接过程中的主机名是否与证书匹配。代理客户端通常负责连接转发和策略选择，并不天然等于 HTTPS 解密工具。普通 HTTP 代理或 SOCKS 代理可以转发连接；当浏览器通过代理建立到目标站点的 TLS 连接时，浏览器仍会看到目标站点提供的证书。
因此，“打开 Clash 后出现证书错误”不等于“Clash 修改了证书”。需要区分两种连接方式。第一种是代理只转发 TCP 或通过隧道传输 HTTPS，证书通常由目标站点直接返回。第二种是网络设备、企业安全软件或某些调试工具主动检查 HTTPS 内容，它们可能在本机安装一个受信任的根证书，并为访问域名生成替代证书。若这个根证书没有被当前浏览器信任，就会出现证书颁发者不受信任的提示。
Clash Meta 的 TUN 模式也不会自动改变所有 HTTPS 证书。TUN 主要通过虚拟网卡接管系统流量，再依据配置中的路由、DNS 和代理规则处理连接。它改变的是流量进入代理内核的路径；真正需要检查的仍然是最终出口、DNS 解析、规则命中情况，以及是否存在额外的 TLS 检查组件。
第一步：检查系统时间与时区
证书有效期依赖设备当前时间。若系统日期提前或落后数小时、数天，浏览器可能把正常证书判断为“尚未生效”或“已经过期”。时区设置错误也会造成相同现象，尤其是双系统、虚拟机、休眠恢复或主板时钟异常后。这个问题与代理规则无关，但因为它常常在刚切换网络环境后被发现，容易被误认为是 Clash 引起的。
- 打开系统的日期与时间设置，启用自动设置时间，并确认时区与所在地一致。
- 手动同步一次时间，等待系统显示同步成功后，完全关闭并重新打开浏览器。
- 访问两个使用不同证书服务商的网站进行比较。若多个站点同时提示证书尚未生效或已过期，优先处理系统时间。
如果只有一台站点报错，而其他 HTTPS 网站正常，时间问题的可能性会下降。此时应继续查看证书详情，而不是反复切换代理模式。移动热点、家庭宽带和公司网络也可以作为对照环境，但对照前要尽量使用相同的设备时间和浏览器配置。
第二步：查看证书域名、有效期与颁发者
在浏览器地址栏的安全信息中打开证书详情，重点看三个字段。第一是主题或使用者名称，确认证书是否覆盖当前访问的域名；通配符证书只覆盖符合规则的子域名，不能覆盖完全不同的主域。第二是有效期，确认当前时间位于生效时间和失效时间之间。第三是颁发者和证书链，查看中间证书是否完整、根证书是否能被操作系统或浏览器信任。
如果证书显示的域名与地址栏域名完全不一致，可能是 DNS 解析到了错误服务器、代理出口返回了异常页面，或网络路径中存在拦截。若域名一致但颁发者变成了公司网关、杀毒软件或本地调试工具名称，则应检查这些组件是否开启 HTTPS 扫描，以及它们的根证书是否正确部署。不要为了消除提示而随意安装陌生根证书；根证书拥有较高信任权限，来源和用途都应当明确。
| 现象 | 优先怀疑方向 | 对照方法 |
|---|---|---|
| 多个站点同时过期 | 系统时间、时区或本地证书存储 | 同步时间并换一个浏览器测试 |
| 只有一个域名不匹配 | DNS、错误出口或站点端配置 | 比较关闭代理、移动网络和不同解析结果 |
| 颁发者显示企业网关 | HTTPS 检查或安全软件拦截 | 查看网络政策和安全软件的 TLS 扫描设置 |
| 开启代理后才发生 | 规则命中、出口节点或 DNS 路径 | 临时切换节点并查看连接日志 |
第三步：用最小变量比较代理与直连
排查代理问题时，变量越少越容易得出结论。先关闭系统代理或暂停客户端，使用同一个浏览器访问同一个 URL，记录是否仍然报错。随后重新启用代理，但保持同一个节点、同一个 DNS 设置和同一个浏览器窗口。若错误只在代理开启时出现，再切换一个已知可用的节点。每次只改变一个条件，避免同时修改规则模式、TUN、DNS 和浏览器扩展。
在客户端的连接或日志页面中，观察目标域名是否命中预期规则、实际使用了哪个策略组和节点。规则模式下，域名可能先匹配到特定规则，再交给代理、直连或拒绝策略；全局模式则会把更多请求交给选定的代理组，适合用于短时间对照。直连模式可以帮助确认站点本身是否正常，但不应把它当作长期绕过网络策略的方案。
还要留意 DNS 解析位置。浏览器、系统、Clash 内核和远端代理可能使用不同的解析路径。解析结果不同，可能导致访问到不同的 CDN 节点或错误地址。若只有某个域名异常，可以先清理浏览器 DNS 缓存，再检查配置中的 DNS 模式、nameserver、fallback 和 fake-ip 相关设置是否符合当前网络环境。修改配置后要确认实际启用的是该文件，而不是编辑了未被加载的副本。
第四步：检查 TLS、证书存储与 HTTPS 扫描
当证书颁发者指向本地软件或组织网关时，检查系统安全软件、企业代理、家长控制程序和调试代理的 HTTPS 扫描功能。部分软件会在浏览器与目标站点之间建立两段 TLS 连接，并使用自己的根证书签发本地替代证书。若这是受管理设备上的明确网络策略，应联系管理员确认根证书部署和证书轮换状态；若是个人设备上的软件功能，则可以在理解影响后关闭 HTTPS 扫描，再重新测试。
浏览器未必完全使用系统证书存储。有些浏览器会启用自己的证书管理、加密 DNS 或安全策略；因此系统层面看似信任的证书，在浏览器中仍可能不被接受。测试时可用另一个干净的浏览器配置文件进行对照，但不要把“换浏览器能打开”当成问题已经解决。它只说明两个浏览器的证书存储、扩展或网络设置存在差异。
如果错误信息涉及 TLS 版本、握手失败或连接被重置，而不是证书颁发者不受信任，应把排查重点放到出口节点、目标站点兼容性和中间网络设备。此时反复导入根证书通常没有帮助。对于需要客户端证书的站点、企业内网或带有双向 TLS 的服务，还要确认代理链路是否支持该站点要求的认证方式。
TUN 模式下的专项检查
TUN 模式会把系统流量导入虚拟网络接口，浏览器即使没有设置传统 HTTP 代理，也可能受到内核规则影响。出现证书错误时，可以暂时关闭 TUN，仅保留系统代理进行对照；也可以保持 TUN 开启、切换到直连策略进行一次测试。这个过程的目的是定位流量路径，不是建议固定使用某一种模式。
- 确认 TUN 虚拟网卡已正常创建，没有与其他 VPN、虚拟机网卡或网络加速软件冲突。
- 检查 DNS 是否由当前内核接管，以及 fake-ip 映射是否被浏览器、系统安全软件或局域网设备异常处理。
- 查看目标域名的规则命中记录，确认请求没有因为规则集过期而被送往错误策略组。
- 若关闭 TUN 后恢复正常，继续比较 DNS、路由和网卡优先级，而不是直接重置全部配置。
推荐的修复顺序与安全边界
可以把整套流程压缩成一条稳定的检查链：先记录错误，再校准时间；随后查看证书域名、有效期和颁发者；接着用同一个站点比较直连与代理；然后检查节点、规则、DNS 和 TUN 路径；最后处理浏览器、系统或安全软件中的证书存储。每完成一个步骤，都重新打开页面并记录结果，这样可以知道哪一个改动真正影响了连接。
修复时不要把“忽略证书错误”作为常规方案，也不要把陌生根证书导入系统来换取页面可访问。对于公司设备，证书和代理策略可能由管理员统一配置，个人修改会造成合规或访问问题。对于公共网络，证书颁发者异常时应先换用可信网络验证；对于单个站点长期异常，则应联系站点维护者确认服务器证书链和域名配置。
记录错误代码
→ 校准系统时间与时区
→ 查看证书域名 / 有效期 / 颁发者
→ 直连与代理保持同一站点对照
→ 检查节点、规则命中和 DNS
→ 对照 TUN 开关与浏览器证书设置
→ 仅在来源明确时处理 HTTPS 检查证书完成排查后，建议恢复原本的代理模式和安全设置，并清理为了测试而临时添加的证书、浏览器扩展或规则。若问题只在某一节点出现，可以暂时更换节点并向服务提供方反馈；若所有节点和多个网络都出现相同错误，则更应检查设备时间、浏览器环境或目标站点证书。通过这种分层定位，HTTPS 报错就能从模糊的“代理不能用”，缩小到具体的证书、解析、规则或网络环节。