开启代理后网页提示证书错误？HTTPS 报错原因与处理办法

先分清：网页证书错误，还是代理节点握手失败

开启 Clash 后出现 HTTPS 错误，不等于 Clash 修改了网站证书。常规 HTTP CONNECT、SOCKS 代理与 TUN 转发通常只转送连接，并不解密浏览器与目标网站之间的 HTTPS 内容。需要先确认失败发生在哪一段，再决定检查浏览器、系统信任库，还是节点配置。

浏览器的错误码也有边界。例如 ERR_SSL_PROTOCOL_ERROR 是 TLS 协议层错误，不足以证明证书被替换。它还可能来自把 HTTPS 请求发往普通 HTTP 服务、服务端 TLS 配置异常，或网络设备提前中断握手。

第一步：核对系统时间与证书有效期

证书包含生效时间和到期时间。电脑时间落在这个区间之外，即使访问的是正确服务器，也可能报错。休眠恢复、主板电池异常、虚拟机时间未同步，都可能造成偏差。先检查时间，比立即改 DNS 或重装客户端更直接。

1. Windows 11：进入「设置」→「时间和语言」→「日期和时间」，开启「自动设置时间」，核对时区，再点击「立即同步」。
2. macOS：进入「系统设置」→「通用」→「日期与时间」，检查自动设置日期与时间；需要修改时按系统要求完成授权。
3. Android：在系统设置中搜索「日期和时间」，开启自动设置时间与时区。不同厂商的菜单层级可能不同。
4. iOS：进入「设置」→「通用」→「日期与时间」，检查「自动设置」。受设备管理策略限制时，联系管理员确认。

在浏览器的证书警告详情中查找证书查看入口，记录「有效期起始」「有效期截止」与「颁发者」。桌面 Chromium 浏览器也可在开发者工具的「安全」面板查找证书信息，入口名称会随浏览器版本变化。

如果本机日期正确，只有一个站点的证书已经过期，应由网站维护者续期。切换节点不会让过期证书重新有效。若只有某个节点出现旧证书，则需继续判断该出口是否连接到了不同的服务器。

第二步：用同一网址做直连与代理对照

对照测试应保持完整网址一致，包括域名与路径。每轮只改一个条件，并记录错误码、证书颁发者和命中的规则。不要同时更换节点、DNS、浏览器与网络，否则即使恢复，也无法确定原因。

建议的四轮检查

1. 记录原状态：记下客户端当前模式、选中节点、系统代理和 TUN 开关。先在「连接」列表查找该域名，确认实际使用的策略。
2. 测试直连：关闭系统代理与 TUN，并检查浏览器代理扩展、手动代理和其他 VPN 是否仍在接管。访问同一网址，记录结果。
3. 恢复代理：按原状态开启，选择节点 A。确认连接列表显示该请求确实经由节点 A，而不是命中 DIRECT。
4. 只切换节点：更换为节点 B，其余设置保持不变，再检查错误码与证书信息。

直连正常、节点 A 异常、节点 B 正常，说明问题更集中在节点 A 的出口路径、解析结果或服务配置，但不能只凭这一轮就判定有人拦截。直连和代理都异常，则应优先检查设备时间、网站证书、系统信任库及所在网络。

有些网站无法在当前网络直连，直连超时不是「证书正常」的证据。此时可用另一条可信网络或另一台设备做辅助对照，但仍应记录变量差异。不要把不同设备上的成功访问直接当作本机配置正常。

用命令确认本地代理路径

如果客户端实际混合端口为 7890，可在 Windows 终端使用以下命令。macOS、Linux 使用 curl 替代 curl.exe。示例域名用于演示命令结构，排查时换成发生错误的网站域名。

curl.exe -v --noproxy "*" https://example.com/
curl.exe -v --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/

第一条跳过 curl 的显式代理设置，但不会绕开系统中的 TUN 或其他网络级接管，所以执行前仍需关闭这些功能。第二条明确经由本地 HTTP 代理；端口须以客户端显示为准。不同 curl 构建与浏览器可能使用不同信任库，因此两者结果不同并不矛盾。

第三步：检查中间人拦截与根证书来源

企业网关、杀毒软件的 HTTPS 扫描、抓包工具，可能在本机或网络中终止 TLS，再向浏览器提供重新签发的证书。如果设备信任其根证书，浏览器可能不报警；如果根证书缺失、过期或不被当前浏览器认可，就可能出现颁发机构不受信任的提示。

先看证书链，再决定是否处理信任库

• 核对域名：查看证书的「使用者可选名称」，即 SAN，是否包含地址栏中的主机名。不要只看证书显示名称或组织名称。
• 核对颁发者：如果显示公司网关、抓包工具或安全软件的名称，检查是否与已安装工具和组织策略一致。名称本身不能证明证书可信。
• 核对范围：多个无关网站突然呈现同一套本地签发证书，且只在某台设备或某个网络发生，更应检查统一的 HTTPS 检查环节。

Windows 可按 Win + R，运行 certmgr.msc，查看当前用户的「受信任的根证书颁发机构」→「证书」；计算机级证书需要通过相应管理控制台检查。macOS 可在「钥匙串访问」中选择「系统」或「登录」钥匙串，查看证书及信任设置。

这些入口用于确认来源，不是让用户批量删除证书。受管理设备上的证书可能属于公司业务要求，应交给管理员核实。个人设备若刚使用过抓包工具，先按工具说明停止 HTTPS 解密并撤销其信任，再重新测试。不要从陌生下载页补装所谓「Clash 专用根证书」；常规代理转发不需要这一步。

第四步：区分 DNS 异常与节点 TLS 配置错误

DNS 解析错误为什么会表现成证书错误

DNS 把域名指向错误地址时，浏览器仍会校验目标域名。错误服务器如果返回另一域名的证书，就可能出现名称不匹配；如果直接断开连接，则表现为握手失败。DNS 本身不会签发证书，因此需要把解析结果、连接目标和证书 SAN 放在一起判断。

Windows 可用 Resolve-DnsName example.com 查看系统解析结果，macOS、Linux 可用 nslookup example.com 辅助检查。但浏览器「安全 DNS」、mihomo 内置 DNS、代理端远程解析可能采用不同路径，系统命令的结果不一定就是浏览器实际使用的结果。

• 在客户端「连接」与「日志」中查看目标域名、命中规则和出口策略，先确认请求到底去了哪里。
• 检查当前生效配置中的 dns、nameserver、nameserver-policy 和 TUN DNS 劫持设置，避免只修改未被加载的文件。
• 如果使用 fake-ip，看到 198.18.0.0/16 范围内的地址不一定是污染。mihomo 常见的默认 fake-ip 地址范围为 198.18.0.1/16，这些地址用于内部映射，不能当成网站真实出口地址。
• 修改解析策略后，重新建立连接再测。旧连接和缓存可能继续使用此前的结果；不要一开始就把所有 DNS 项替换为同一个公共解析器。

节点证书错误发生在另一段连接

对于使用 TLS 的代理协议，客户端还要验证代理服务器的证书。这与浏览器验证网站证书是两次独立的校验。如果日志中的目标是节点服务器，而浏览器显示隧道连接失败，应优先核对订阅提供的服务器地址、端口和 TLS 参数。

以 mihomo 的常见 TLS 节点配置为例，server 是连接地址，port 是服务端监听端口；部分协议用 servername 指定 TLS 服务名，另一些配置类型使用 sni。字段是否适用取决于协议与内核支持，不能把一个协议的写法直接复制到另一个协议。

按错误范围处理，并保留可复现记录

排查到这里，可以按影响范围收敛操作。恢复访问只是结果之一，还需要确认恢复后没有留下错误的信任设置或临时放宽的校验选项。

公共 Wi-Fi 可能要求先完成门户认证。优先使用系统弹出的网络登录入口，不要在 HTTPS 证书警告页强行继续并填写账号。若无法确认网络身份，停止连接该热点，换用可信网络。

提交问题时附上哪些信息

• 操作系统、浏览器版本、客户端版本及内核名称，可从「关于」或内核信息页记录。
• 发生时间、目标域名、浏览器完整错误码，以及证书的 SAN、颁发者与有效期。
• 直连、节点 A、节点 B 的对照结果，系统代理与 TUN 是否开启。
• 报错前后相关日志，遮住订阅链接、节点密码、令牌、账号和不宜公开的地址。

如果系统或浏览器长期未更新，可通过官方系统更新与浏览器更新渠道补齐支持的安全更新，再复测信任链。更换客户端时，应先记录现有端口、规则模式和 TUN 状态，避免把安装变化与网络问题混在一起。基础开关可参考系统代理操作说明，解析问题可继续查看DNS 排查说明。

安全的处理顺序是：记录报错、校准时间、对照连接路径、检查证书来源，最后定位 DNS 或节点参数。整个过程中保留证书验证，不把「网页终于打开」当作唯一标准。