开启代理后网页报 HTTPS 证书错误:成因拆解与处理

先看错误类型，不要直接放行证书

开启 Clash 后，浏览器出现“您的连接不是私密连接”，不等于代理软件需要安装一张证书。先停在警告页面，记下访问的完整域名、错误代码和发生时间。暂时不要登录账号、付款，也不要从报错页面下载所谓的证书修复工具。

正常的 HTTP CONNECT 或 SOCKS5 代理主要负责转发连接。浏览器与目标网站之间仍会进行 TLS 握手，由浏览器验证网站证书的域名、有效期与信任链。Clash、Clash Meta（mihomo）的常规代理转发不要求浏览器信任一个新的本地根证书。

“忽略证书错误”不是恢复连接的通用办法。先判断证书为什么不可信，再调整时间、网络或代理路径。不要把关闭验证当作日常配置。

不同浏览器的提示文字会变化，Firefox 也可能使用 SEC_ERROR_UNKNOWN_ISSUER 等代码。协议错误与连接超时不一定已经收到证书，不能一律归因于“证书过期”。

第一步：校准系统时间，记录证书信息

先同步时间，再重开页面

1. Windows 11：进入「设置」→「时间和语言」→「日期和时间」，打开「自动设置时间」，确认时区后点击「立即同步」。
2. macOS：进入「系统设置」→「通用」→「日期与时间」，开启自动设置日期与时间，并核对时区。
3. Android：通常在「设置」→「系统」→「日期和时间」中开启自动设置；不同厂商菜单可能叫「其他设置」。
4. iPhone：进入「设置」→「通用」→「日期与时间」，打开「自动设置」。

日期偏差几个月会让大量正常网站同时报错。只看到时区显示不同，不代表 TLS 验证必然失败：关键是设备的实际时间是否正确。同步后关闭原报错标签页，再重新访问原域名，不要只反复刷新旧提示。

记录三项证书字段

在浏览器可用的“查看证书”入口中，记录有效期、签发者和“使用者可选名称”（SAN）。新版浏览器入口可能位于地址栏左侧的站点信息，或警告页的高级信息中。不要为了查看证书而选择继续访问。

• 有效期：当前日期是否介于生效时间与到期时间之间。
• SAN：是否覆盖地址栏中的实际主机名。证书覆盖 *.example.com，通常不覆盖根域名 example.com，也不覆盖更深一层的 a.b.example.com。
• 签发者：是否出现酒店、公司网关或安全软件名称。名称本身不是可信结论，需要结合网络环境核实。

如果时间正确，且只有一个网站的证书已过期，应由网站维护者更新证书。换节点可能碰巧访问到另一个正常入口，但不能代替站点修复，也不应通过降低验证强度绕过。

第二步：排除公共 Wi-Fi 认证与本机 HTTPS 检查

机场、酒店、校园访客 Wi-Fi 常要求先完成网页认证。尚未认证时，网关可能重定向普通 HTTP 请求；若错误拦截 HTTPS，请求拿到的证书可能属于认证网关，而不是目标网站。此时盲目切换代理节点往往没有作用。

1. 临时关闭系统代理和 TUN，保留当前 Wi-Fi 连接。只关闭其中一项，另一项仍可能接管流量。
2. 优先使用系统弹出的“登录网络”窗口。没有弹窗时，可访问 http://example.com/ 触发认证跳转；该地址只用于引出认证页，不用于提交敏感资料。
3. 核对认证页是否属于现场网络运营方，完成必要认证。认证页本身若出现证书警告，先向现场人员核实。
4. 确认直连普通 HTTPS 网站正常，再开启原有代理设置并重测。

如果同一设备换到手机热点后恢复正常，优先怀疑原 Wi-Fi 的认证、网关或网络策略；但这仍是定位线索，不是证据闭环。企业网络可能按规定部署 HTTPS 检查，应向管理员确认合法的证书分发方式，不要自行绕过组织策略。

仅某台电脑异常，检查本地拦截链

安全软件的“加密连接扫描”、抓包工具和调试代理可能参与 HTTPS 解密。先确认是否最近启用了这些功能，查看证书签发者是否与其对应。个人设备可按软件官方说明暂停相关功能做一次对照，然后恢复原状态；受管理设备应交给管理员处理。

不要批量删除系统根证书，也不要导入节点提供者发来的陌生根证书。普通代理订阅通常包含节点、策略组和规则，并不需要通过安装网站信任证书来生效。

第三步：用同一域名对比直连与代理

保持访问地址完全一致，只改变一个条件。下面的“直连”指关闭系统代理、TUN，以及浏览器单独设置的代理；“代理”指确认请求实际进入当前客户端。若站点无法直连，记录“超时”即可，不能把超时当成证书正常。

使用 curl 区分验证错误与连接失败

以下示例假设客户端的混合代理端口确实为 7890。先在客户端设置中核对端口；它不是所有安装环境的固定值。Windows PowerShell 使用 curl.exe，macOS 或 Linux 可使用 curl。

# 绕过显式代理环境变量，测试直连
curl --noproxy "*" -Iv --connect-timeout 10 https://example.com/

# 明确连接本机 HTTP 混合代理端口
curl --noproxy "" -x http://127.0.0.1:7890 -Iv --connect-timeout 10 https://example.com/

这里的 http://127.0.0.1:7890 表示连接本机 HTTP 代理，不代表目标网页改成了 HTTP。HTTPS 目标通常通过 CONNECT 隧道访问。不要把它随意改成 https://127.0.0.1:7890，后者要求本机代理入口自身支持 TLS。

测试直连时还应关闭 TUN，因为 --noproxy 不能绕过系统层的透明接管。curl 返回码 60 通常表示证书验证失败，7 表示连接失败，28 表示超时；这些结果不是本文实测数据。curl 与浏览器可能使用不同信任库，结果不同也要继续核对，而不是任选一个结论。

第四步：核对规则、DNS 与实际出口

规则误配一般不会直接修改网站证书，但可能让连接走到错误出口，或让域名解析到不适合当前路径的服务端。先在客户端的「连接」页面筛选报错域名，重新发起一次访问，记录命中规则、策略组和最终节点。再看日志中是否出现解析失败或握手失败。

全局模式只用来做短时对照

若规则模式报错，而同一节点在全局模式下正常，检查该域名是否被提前匹配为 DIRECT，或落入另一策略组。测试后恢复规则模式。规则从上到下匹配，不应为了一个域名长期把所有流量改为同一出口。

下面只是规则顺序示意，不是完整配置。添加前先确认策略组中确实存在名为 Proxy 的组，并将示例域名替换成实际故障域名。若配置由订阅管理，优先使用客户端支持的覆写或合并功能，避免下次更新时丢失改动。

mode: rule
rules:
  - DOMAIN,example.com,Proxy
  - DOMAIN-SUFFIX,example.org,DIRECT
  - MATCH,Proxy

fake-ip 地址不等于证书伪造

mihomo 的 fake-ip 模式会给域名分配虚拟地址，常见地址段为 198.18.0.0/16，具体取决于配置。内核通过映射继续处理原域名；看到这种地址并不能证明发生 HTTPS 解密。浏览器应继续使用域名发起 TLS，并验证该域名的证书。

• 不要把地址栏里的域名改成解析出的 IP 测试证书。这样会改变证书匹配条件，也可能改变 SNI 和虚拟主机选择。
• 检查本机 hosts 与配置中的 hosts 段，确认没有把故障域名固定到旧服务器。
• 若浏览器开启安全 DNS，记录所用解析器；它可能与客户端 DNS 使用不同路径。仅在理解影响后做单项对照，测试后恢复。
• 修改 DNS 后应重建连接。Windows 可用 ipconfig /flushdns 清理系统缓存，但浏览器及客户端可能仍有独立缓存。

不要一次性更换 DNS、节点、规则模式和 TUN 设置。每次只改一项，重测同一 URL，并记录错误代码与签发者是否变化，才能判断是哪一步产生了效果。

区分浏览器证书与节点传输证书

还有一种常见混淆：浏览器没有显示网站证书警告，但客户端日志出现 x509: certificate signed by unknown authority。这可能发生在内核连接采用 TLS 传输的代理节点时，是“客户端到节点”的证书问题，不一定是“浏览器到网站”的证书问题。

先核对节点地址、服务端证书有效期、证书链，以及节点提供者指定的服务器名称设置。自建服务应修复证书链或按受控方式配置信任；订阅节点则应联系提供者核实。不要凭猜测修改 SNI，也不要把一个不相关网站的域名填进去。

节点配置中的 skip-cert-verify: true 会跳过相应节点 TLS 连接的证书验证，不会修复目标网站证书。浏览器端的忽略验证开关同样不适合作为长期处理方式。

如果只有一个节点反复触发异常，先停用该节点，换到已确认可用的出口，再向提供者提交时间、节点标识和脱敏日志。不要公开订阅 URL、访问令牌、节点密码或完整配置文件。

恢复后的验收与故障记录

恢复网页显示还不够，应确认没有依靠临时放宽验证来“消除”提示。按下面顺序收尾，可减少下一次网络切换时复发。

1. 恢复日常规则模式，确认系统代理与 TUN 的启用状态符合原来的使用方式。
2. 重新打开原报错域名，确认不再出现证书警告，证书 SAN 与主机名匹配，日期处于有效期内。
3. 再检查两个平时常用的 HTTPS 网站，排除只有单个页面缓存成功的情况。
4. 撤销临时 DNS、规则或调试设置；必须保留的改动写入受支持的覆写配置并做备份。
5. 记录最终原因，例如“系统年份错误”“Wi-Fi 未认证”或“某节点出口异常”，不要只记“重启后好了”。

需要进一步求助时，提供浏览器名称与版本、系统版本、客户端及内核版本、故障域名、错误代码、直连与代理对照结果，以及证书签发者。截图前隐藏账号、私人域名和订阅凭据。准确的证据比反复导入订阅更有助于定位。

处理顺序可以固定为：先确认时间与错误类型，再排除 Wi-Fi 认证和本机检查，随后对比出口，最后检查规则与 DNS。遇到不明签发者或敏感站点异常时，停止提交信息，比强行打开页面更重要。