开代理后浏览器提示证书不受信任：HTTPS 证书报错的成因与排查

一、先保留报错信息，不要直接绕过警告

开启 Clash 系列客户端后，浏览器出现“您的连接不是私密连接”或“此连接非私人连接”，说明浏览器无法完成对目标站点身份的验证。它不等于节点超时，也不等于订阅失效。连接可能已经到达某台服务器，只是服务器提供的证书、证书链或本机信任状态不符合要求。

排查前先停止在该页面输入密码、支付信息与验证码。记录地址栏中的完整主机名、浏览器错误码、证书颁发者和有效期。截图用于求助时，要遮住账户信息、订阅地址及含令牌的查询参数。

二、Clash 代理在 HTTPS 握手中负责什么

普通转发不会替换网站证书

以浏览器通过本地 HTTP 代理访问 HTTPS 网站为例：浏览器先向代理发送 CONNECT example.com:443，代理建立可用的转发通道，随后浏览器与目标站点进行 TLS 握手。网站证书由浏览器验证；本地监听端口即使是 7890，也不意味着 HTTPS 内容变成明文。

SOCKS 代理与 TUN 接管的入口不同，但也不会天然产生 HTTPS 解密。Clash 与 Clash Meta（现称 mihomo）的常规代理转发不要求用户安装用于解密网页的根证书。配置里的流量嗅探也不等于解密 HTTPS 正文；读取可见的握手元数据与签发替代证书是两件事。

代理节点的 TLS 与网站 TLS 是两层连接

部分节点协议本身也使用 TLS。此时，客户端到节点服务器有一层握手，浏览器到网站还有另一层握手。若日志显示节点端证书验证失败，常见结果是代理连接失败、超时或隧道错误，不一定会显示浏览器的网站证书警告。

某些配置支持的 skip-cert-verify 针对对应出站连接的证书校验，不会修复网站的证书链，也不会让浏览器信任该网站。不要为了解决网页报错就将它改为 true；应核对节点地址、服务端证书与 TLS 服务器名称是否由服务提供方正确配置。

三、先查系统时间，再做单变量对照

确认 macOS 日期与时间

在 macOS Ventura 13 及后续版本中，打开「系统设置」→「通用」→「日期与时间」，检查自动设置日期与时间是否开启，并核对当前日期、年份与时区。较旧的 macOS 可在「系统偏好设置」→「日期与时间」检查。恢复旧系统备份或长时间离线后，尤其要确认年份没有偏移。

证书有效期按时间戳判断。若本机时间错误，即使正常网站也可能被判断为尚未生效或已经过期。仅修改时区通常不会修正错误的系统时钟；应以自动同步后的实际时间为准。修正后退出并重新打开浏览器，再访问同一主机名。

按同一网址记录四组结果

1. 当前节点：记录浏览器错误、证书颁发者，以及客户端连接列表中的规则和出站策略。
2. 另一节点：只切换策略组中的节点，不同时修改 DNS、规则和浏览器设置。
3. 直连：暂时关闭系统代理与 TUN，并检查浏览器扩展或独立代理设置是否仍在接管流量。
4. 另一网络：在条件允许时使用个人热点重复访问，以区分当前 Wi-Fi、路由器或组织网络的影响。

直连测试失败不一定说明网站证书有问题：当前网络可能根本无法连接该网站。只有拿到具体证书、错误码或成功页面，结果才有可比性。测试时保持网址不变，特别注意跳转后是否到了另一个子域名。

四、检查中间人解密与陌生根证书

公司网络的 HTTPS 检查、调试抓包工具和某些安全软件，可能在浏览器与网站之间终止 TLS，再向浏览器提供重新签发的证书。这类机制需要对应的根证书被设备信任。根证书未正确部署、证书过期或软件卸载不完整，都可能引发“不受信任”的提示。

• 查看颁发者：在浏览器的警告详情或证书查看器中，记录证书颁发者。多个无关网站都出现同一个陌生组织名称，是值得调查的线索。
• 检查证书存储：打开「应用程序」→「实用工具」→「钥匙串访问」，分别查看“登录”和“系统”钥匙串中的证书。不要批量删除系统根证书。
• 核对调试工具：若安装过 HTTPS 抓包工具，先关闭它的 HTTPS 解密与系统代理接管，再复测，避免两个本地代理相互覆盖。
• 识别受管理设备：若 Mac 由单位管理，证书可能通过设备管理配置下发。请让管理员确认用途、有效期和部署状态，不要自行改变组织的信任策略。

颁发者变化本身并不能直接证明攻击。大型网站可能更换证书机构，CDN 的不同边缘节点也可能返回不同证书。需要结合主机名覆盖范围、有效期、信任链与多条访问路径判断。若个人设备突然被要求安装来源不明的根证书才能“修复代理”，应暂停操作并核实来源。

五、区分节点异常、DNS 偏差与网站配置错误

仅一个节点报错：先停用该节点

如果其他节点访问同一主机名正常，而某节点持续返回无关域名的证书，可能涉及该出口的 DNS、网络劫持或服务端路由异常。先停止通过它访问敏感站点，再向服务提供方提交时间、目标主机名、错误码与证书颁发者。仅凭一次报错不能认定节点运营方实施了劫持。

DNS 被改写后，连接可能落到错误服务器；正常的证书验证通常会阻止这台服务器冒充原网站。mihomo 的 Fake-IP 模式则是本地将域名映射到合成地址，再由内核处理连接的机制，看到合成地址并不等于 DNS 污染。应结合连接详情中识别的域名、命中规则及实际出站核对。

所有路径只有一个站点报错：检查站点证书

若同一网站在不同节点、直连和其他设备上都出现类似错误，应考虑站点证书过期、域名覆盖不全或中间证书链配置缺失。例如，覆盖 *.example.com 的通配符证书通常能匹配 www.example.com，但不能单独凭这一条匹配 a.b.example.com，也不自动覆盖裸域名 example.com。

服务器遗漏中间证书时，不同浏览器可能因缓存或补全能力不同而表现不一致。因此，“Safari 能开、另一个浏览器不能开”也不能完全排除服务器配置问题。记录证书链信息并联系站点管理员，比更改本机信任设置更合适。

只在公共 Wi-Fi 出现：先完成网络认证

酒店、机场等网络可能要求先通过门户登录。若它试图把 HTTPS 请求导向认证页，就可能出现域名不匹配。先使用 macOS 的网络登录提示完成认证，不要在证书警告页面输入网站密码。认证后仍异常，可换个人热点验证。

六、用 curl 对照直连与本地代理

终端测试可以提供独立于浏览器缓存和扩展的线索，但不替代浏览器结果。先在客户端设置中确认 HTTP 或混合监听端口；下面的 127.0.0.1:7890 只是明确的测试示例，不是所有客户端的固定值。将示例域名替换为实际出错的主机名，保留 https://。

# 记录 curl 版本与 TLS 后端
curl --version

# 绕过 curl 的代理选择；若启用了 TUN，流量仍可能被接管
curl -Iv --connect-timeout 10 --max-time 20 --noproxy '*' https://example.com/

# 明确使用本地 HTTP / 混合代理端口
curl -Iv --connect-timeout 10 --max-time 20 --noproxy '' \
  --proxy http://127.0.0.1:7890 https://example.com/

• 建立真正的直连对照：除使用 --noproxy '*' 外，还要关闭 TUN，并确认没有其他 VPN 或网络扩展接管。该参数只能绕过 curl 自身的代理选择。
• 区分隧道与网站：输出中的 200 Connection established 通常表示代理接受了 CONNECT 请求，不代表目标网站已经通过证书验证。
• 读取错误类别：curl: (60) 通常表示对端证书验证失败；curl: (7) 通常是连接失败。先分清本地代理没监听，还是网站 TLS 验证失败。
• 注意信任源差异：macOS 自带 curl 与其他渠道安装的 curl，可能使用不同 TLS 后端与 CA 存储。一个成功、一个失败，需要核对版本和信任源。

这些命令设置了 10 秒连接超时和 20 秒总时限，方便避免测试长期挂起；它们不是性能实测值。-I 发出 HEAD 请求，个别网站会返回 405，但若已经完成 TLS 验证，HTTP 方法不受支持与证书错误是两个问题。

七、按证据修复，并确认问题没有被掩盖

1. 时间错误：恢复自动校时，重新打开浏览器，确认原主机名可以正常验证。
2. 组织 HTTPS 检查异常：由管理员修复证书部署或检查网关，不通过聊天附件临时安装未知根证书。
3. 单个节点异常：暂停使用该节点，保留证据并联系服务提供方；用其他可信路径复测。
4. 网站证书异常：等待站点更新证书、补全中间链或修复域名绑定，本地重装客户端通常无效。
5. 本地软件冲突：按软件自身文档撤销 HTTPS 解密和代理接管，每次只调整一项，再重复相同测试。

最后恢复原本需要的规则模式、系统代理或 TUN 设置，重新检查目标网站及另外两个常用 HTTPS 网站。确认地址栏没有意外跳转，证书有效，客户端连接列表中的出站符合预期。如果只是换了浏览器后不再提示，仍应查清两者信任源或扩展设置的差异，而不是直接把问题视为解决。

客户端安装与基本配置可参考快速上手；需要核对代理协议、规则与 DNS 配置时，可查阅协议手册。证书错误的排查重点始终是时间、主机名、证书链与访问路径，而不是反复更新订阅或随机更换端口。