开启代理后网页提示证书错误：HTTPS 证书报错与 Clash 的关系解析

HTTPS 证书错误：先确认报错发生在哪一层

开启 Clash 客户端后出现“您的连接不是私密连接”，只能说明浏览器无法确认当前连接的身份，不能直接证明代理节点篡改了网页。系统时间错误、网站证书过期、公共 Wi-Fi 登录页、企业网络的 HTTPS 检查，以及 DNS 将域名解析到错误的服务器，都可能触发类似提示。

HTTPS 通常连接目标服务器的 443 端口。TLS 握手时，浏览器会检查证书有效期、证书链和请求域名是否匹配。代理改变的是流量路径；浏览器仍然需要完成这些身份检查。排查的第一步不是关闭验证，而是记录完整错误代码、地址栏域名，以及证书的颁发者和有效期。

Clash 客户端如何转发 HTTPS

普通代理转发不需要替换网站证书

浏览器使用本地 HTTP 代理访问 HTTPS 时，通常先发送 CONNECT 目标域名:443，再通过建立的通道与目标网站进行 TLS 握手。SOCKS 代理和 TUN 模式也可以转发加密连接。正常转发场景下，浏览器看到的应当是目标网站的证书，而不是某张“Clash 证书”。

Clash 客户端的规则决定连接走直连还是代理，以及使用哪个策略组。即使启用域名嗅探，读取可见的握手信息也不等于解密 HTTPS 正文。不能仅凭启用了 TUN、Fake-IP 或嗅探，就判断浏览器证书已被替换。

目标网站证书与代理节点证书要分开看

部分代理协议自身也使用 TLS。此时有两层不同的校验：内核检查代理节点的 TLS 证书，浏览器检查目标网站的 HTTPS 证书。若内核日志显示连接代理服务器时出现 x509: certificate has expired or is not yet valid，问题可能位于节点端；若浏览器能展示目标网站的证书并报域名不匹配，则要检查网站连接这一层。

mihomo 配置中，部分 TLS 节点支持 skip-cert-verify。该字段作用于对应节点的证书验证，不会关闭浏览器对目标网站的检查。将它改为 true 既不能可靠修复网页证书错误，还会削弱节点身份验证。应让配置提供方修正节点证书、服务器名称或连接地址。

第一轮排查：时间、域名与证书详情

1. 保存报错信息。记录完整网址与错误代码。在浏览器的站点信息或证书查看器中，查看颁发者、有效期及“主题备用名称”，即 SAN。不同浏览器版本的入口可能不同，以证书详情窗口为准。
2. 校正设备时间。Windows 11 可打开「设置」→「时间和语言」→「日期和时间」，启用自动设置时间并使用“立即同步”。macOS 可打开「系统设置」→「通用」→「日期与时间」，检查自动设置日期和时间。
3. 核对实际域名。检查是否输入了错误拼写，是否从旧书签跳转到新的子域名。证书 SAN 中的 *.example.com 一般覆盖 www.example.com，但不覆盖 a.b.example.com，也不自动覆盖根域名 example.com。
4. 比较证书有效期。例如，设备显示 2025 年，而证书从 2026 年开始生效，会被判断为尚未生效；设备跳到 2030 年，也可能把仍有效的证书判断为过期。这是判断示例，不是当前网站的证书数据。

时区主要影响本地时间的显示。仅显示时区不同，而设备实际时间戳准确，通常不会导致证书验证失败。需要纠正的是实际日期和时间，而不只是把时区名称改为所在地区。

只在一个网站出现错误

如果同一网络中的其他 HTTPS 网站正常，且直连与代理都看到同一张过期证书，优先考虑网站端证书续期或证书链部署问题。更换多个节点不会让已经过期的证书重新有效。可记录错误交给网站维护方，并等待服务端修复。

第二轮排查：用对照测试定位代理路径

测试时每次只改变一个条件，保持同一个网址、同一个浏览器和相近的测试时间。先记录正在使用的规则模式、策略组和节点，再做下面的比较。不同路径可能连到不同 CDN 边缘服务器，因此证书不同本身不是被劫持的充分证据，还要看域名覆盖范围与证书链是否可信。

关闭系统代理不一定等于直连

TUN 模式仍然开启时，流量可能继续被虚拟网卡接管；浏览器扩展也可能设置独立代理。进行直连对照前，应关闭 Clash 客户端的系统代理与 TUN，并确认浏览器未使用独立代理。测试结束后恢复原设置。受单位管理的设备应遵守网络要求，不自行绕过强制策略。

在 Clash 客户端的连接列表中，找到目标域名对应的连接，查看匹配规则与最终策略。不要因为界面上选中了某个节点，就认为所有请求都经过该节点：规则可能将目标分配到 DIRECT 或其他策略组。更详细的匹配逻辑可查看配置进阶。

使用 curl 对照本地代理

下面使用 example.com 演示命令结构，并假设本地 HTTP 或混合端口为 7890。实际端口应以 Clash 客户端当前设置为准。Windows 使用 curl.exe，macOS 或 Linux 使用 curl。

# 显式忽略代理环境变量，比较直连路径
curl --noproxy "*" -Iv https://example.com/

# 显式使用本地 HTTP 代理
curl --proxy http://127.0.0.1:7890 -Iv https://example.com/

如果 TUN 仍在运行，第一条命令也可能被接管，因此需先完成前述关闭步骤。-I 请求响应头，-v 输出连接与握手信息；不要加入 -k 或 --insecure，否则会跳过本次要检查的证书验证。curl 与浏览器使用的 TLS 实现、信任库可能不同，其结果是对照线索，不能代替浏览器验证。

DNS、Fake-IP 与网络登录页如何影响证书

错误目的地址可能返回另一张证书

DNS 将域名解析到错误服务器时，浏览器仍会按原域名检查证书。例如访问 www.example.com，却收到只覆盖网络登录门户的证书，就可能报域名不匹配。若多个完全不同的网站都显示同一个陌生颁发者或门户域名，应优先检查公共 Wi-Fi 认证、路由器设置和本地 HTTPS 检查软件。

Fake-IP 是域名与连接之间的映射机制，不是伪造 HTTPS 证书的功能。mihomo 常见示例使用 198.18.0.1/16 作为 Fake-IP 范围，实际以配置为准。解析到该范围并不自动意味着污染；要结合 DNS 增强模式、TUN 接管状态和域名映射是否有效判断。

• 切换 DNS 增强模式或关闭 TUN 后，旧的 DNS 缓存可能暂时保留映射地址。应先确认新配置已生效，再刷新缓存并重启浏览器。
• Windows 可执行 ipconfig /flushdns 刷新系统 DNS 缓存，但浏览器可能有独立缓存；刷新缓存也不会修复过期证书。
• 浏览器的安全 DNS 设置可能改变域名解析路径。先记录当前设置，再按客户端 DNS 方案做一致性测试，避免同时更换节点和解析器。

公共 Wi-Fi 先完成正常认证

酒店、机场或校园网络可能需要先打开登录门户。优先使用系统弹出的网络登录窗口，或网络运营方提供的认证入口。若 HTTPS 页面被重定向却出现证书警告，不要在警告页面填写帐号密码。完成可信入口的认证后，再恢复代理并重新访问目标网站。

企业根证书、网站证书链与安全边界

企业网关、安全软件或调试工具可能主动进行 HTTPS 检查：在设备与网关之间建立一段 TLS，再由网关连接网站。这时浏览器可能看到由单位根证书签发的网站证书。对受管理设备而言，这可能是明确配置的网络策略；对个人设备而言，突然出现陌生颁发者则需要认真核实。

1. 确认管理来源。询问单位管理员是否部署了 HTTPS 检查，并核对根证书的来源与设备管理记录，不通过论坛附件或陌生消息获取证书。
2. 比较网络。在允许的情况下切换到可信的个人网络。如果异常颁发者只在特定网络出现，重点检查该网络的网关；如果所有网络都出现，检查本机软件和信任设置。
3. 检查网站证书链。网站缺少中间证书时，某些浏览器可能依靠缓存正常访问，而另一台设备失败。应由网站维护方补齐服务端证书链，而不是要求访客信任其叶证书。
4. 恢复受支持环境。更新操作系统和浏览器以获得相应的安全修复与信任库更新。对于受管理设备，更新与证书调整由管理员按策略执行。

恢复连接前的检查清单

• 时间准确：系统已完成时间同步，证书当前处于有效期内。
• 域名匹配：地址栏域名被证书 SAN 覆盖，不依赖手动忽略错误继续访问。
• 路径明确：已确认系统代理、TUN、浏览器独立代理和规则命中的实际状态。
• 颁发者可信：陌生证书已查明来源，单位证书由正式管理渠道确认。
• 修改可回退：保留原配置，未通过跳过证书校验来掩盖问题。

提交求助信息时，建议提供错误代码、操作系统与浏览器版本、Clash 客户端及内核版本、是否开启 TUN、直连与代理的对照结果。证书截图可保留域名、颁发者和有效期；日志应隐藏订阅链接、节点密码、访问令牌及个人网址。基础连接排查也可参考疑难解答。

判断顺序可以归纳为：先识别错误层级，再检查时间与证书身份，随后对照连接路径，最后定位 DNS、网关或网站部署。修复目标是恢复可信的 HTTPS 连接，而不是让警告页面消失。