故障排查 预计阅读 12 分钟

开代理后网页提示证书不安全?HTTPS 证书错误的成因与处理

梳理代理环境下出现证书警告的几类原因:系统时间偏差、MITM 设置残留、劫持型节点与 DNS 污染,并给出对应的检查与修复步骤。

先区分证书错误与代理连接失败

遇到 HTTPS 证书警告，先停止输入密码与付款信息，再检查系统时间、证书签发者和实际连接路径。不要把“继续访问”当成修复步骤。普通代理转发不需要浏览器信任一个新的根证书；仅仅导入订阅，也不应要求安装网站提供的证书。

ClashX 或使用 mihomo 内核的客户端通常负责流量转发。浏览器通过 HTTP CONNECT 隧道、SOCKS 或 TUN 路径访问 HTTPS 站点时，网站证书仍由浏览器验证。TUN 接管网络流量不等于解密 HTTPS；mihomo 的流量嗅探功能也不等于为网站重新签发证书。

常见提示 优先检查 不能直接下的结论
NET::ERR_CERT_DATE_INVALID 本机时间、证书起止时间 不一定是节点故障
NET::ERR_CERT_AUTHORITY_INVALID 签发者、根证书信任、证书链 不代表应该安装陌生证书
NET::ERR_CERT_COMMON_NAME_INVALID 网址与证书 SAN、DNS、重定向 不一定只是 DNS 缓存问题
ERR_PROXY_CONNECTION_FAILED 代理监听端口、客户端运行状态 这不是网站证书验证错误
ERR_SSL_PROTOCOL_ERROR TLS 握手、错误服务端口、中间设备 不等同于根证书缺失

不同浏览器的错误名称可能不同。先保存错误代码、访问域名、发生时间和证书签发者，后续每次只改变一个条件。只记录域名即可，不要公开带登录令牌的完整地址。

第一步：检查系统时间与证书有效期

系统时间错误会让多个正常网站同时显示证书过期或尚未生效。虚拟机恢复快照、设备长时间断电、双系统切换后尤其值得先查。时区显示不一致本身未必影响验证，关键是系统记录的实际时间是否正确。

  1. Windows 11：打开「设置」→「时间和语言」→「日期和时间」，启用「自动设置时间」，在「其他设置」中执行「立即同步」。
  2. macOS：打开「系统设置」→「通用」→「日期与时间」，启用自动设置日期与时间；旧版系统的入口名称可能不同。
  3. 重新打开浏览器，再查看错误页中的证书详情，核对“生效时间”和“到期时间”。如果系统时间正确且只有一个网站证书过期，应由网站维护者更新证书。

终端中可用以下命令读取 UTC 时间，再与可信设备比较。这里的命令只读取时间，不修改系统配置。

# macOS / Linux
date -u

# Windows PowerShell
(Get-Date).ToUniversalTime().ToString("o")

第二步：用直连与显式代理确定影响范围

“关闭系统代理”不一定等于直连。TUN 仍可能接管连接，浏览器扩展也可能独立配置代理，企业网络还可能在设备之外检查流量。先记下当前模式、所选节点和配置文件，再建立可重复的对照条件。

按同一域名完成三组对照

  1. 直连组：关闭客户端的系统代理和 TUN，暂时停用浏览器代理扩展；在允许直连且目标可达的网络中访问同一 HTTPS 域名。
  2. 节点 A：恢复原配置，选择原节点，记录证书签发者和错误代码。
  3. 节点 B：仅切换节点，保持浏览器、目标域名和其他设置不变，再次测试。

直连不可达时，不能把超时当成“证书正常”。可以改用另一条可信网络做补充对照，例如手机热点。不要同时更换 DNS、节点、浏览器和规则，否则无法判断是哪一项改变了结果。

用 curl 检查 HTTP CONNECT 路径

以下以客户端实际监听的混合端口为 7890 为例。先在当前生效配置中确认 mixed-port，端口不是 7890 时须同步修改命令。Windows 建议写 curl.exe，避免部分 PowerShell 环境中的同名别名。

# macOS / Linux：排除环境变量中的 HTTP/SOCKS 代理
# 只有在 TUN 已关闭、没有其他透明代理时，才能作为直连对照
curl -Iv --connect-timeout 10 --max-time 20 --noproxy '*' https://example.com/

# 显式使用本地 HTTP 代理；清空 no_proxy 的绕过列表
curl -Iv --connect-timeout 10 --max-time 20 --noproxy "" \
  --proxy http://127.0.0.1:7890 https://example.com/

# Windows PowerShell：显式使用本地 HTTP 代理
curl.exe -Iv --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/

200 Connection established 只说明代理接受了 CONNECT 请求，不代表后续 TLS 验证已经成功。继续查看证书验证结果和最终响应。示例域名用于演示命令；排查时应换成实际报错的域名，不必附带私密路径。

curl 与浏览器可能使用不同的 TLS 后端和信任库，因此“curl 成功、浏览器失败”是定位线索，不是最终判定。命令行中不要加入 -k 或 --insecure，否则会跳过本次正要检查的验证环节。

第三步：检查 MITM、抓包工具与根证书残留

MITM 指中间人拦截。在经过明确授权的调试或企业环境中，抓包工具可能终止原始 TLS 连接，再用本地根证书签发一张站点证书。若代理设置仍在、根证书已移除，或者应用不信任该证书库，就会出现证书错误。

先看签发者，再查设置来源

  • 在浏览器错误页或网站信息面板中打开证书详情，查看签发者、有效期与“主题备用名称”（SAN）。SAN 中应包含当前访问的域名。
  • 若多个互不相关的网站都显示同一个陌生组织或本地工具名称，检查抓包工具、HTTPS 扫描功能、浏览器扩展和设备管理策略。
  • Windows 可在「设置」→「网络和 Internet」→「代理」检查手动代理与设置脚本；macOS 可在「系统设置」→「网络」→当前网络→「详细信息」→「代理」检查残留。
  • 同时检查环境变量 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 与 NO_PROXY。浏览器与终端未必使用同一套代理设置。

证书移除需要确认用途

macOS 可在「钥匙串访问」中分别检查“登录”和“系统”钥匙串。Windows 的 certmgr.msc 查看当前用户证书，certlm.msc 查看本地计算机证书；后者的修改通常需要管理员权限。检查“受信任的根证书颁发机构”时，先核对证书名称、用途与部署来源。

个人设备上，确认是旧抓包工具安装的证书后，应先关闭该工具的 HTTPS 拦截并恢复代理设置，再按其卸载说明移除证书。不要批量删除系统根证书。受组织管理的设备应交由管理员处理，避免破坏内部服务或违反网络管理要求。

第四步：排查异常节点、DNS 与错误站点

如果只有某个节点出现证书域名不匹配，切换后立即恢复，需要隔离该节点并检查解析路径。但仅凭一次错误不能认定节点在劫持：出口附近的登录门户、上游 DNS、错误的反向代理配置，也可能把请求引向别的服务器。

DNS 污染为什么会触发证书警告

当域名被解析到错误服务器，浏览器仍会按地址栏中的原域名验证证书。错误服务器若返回其他域名的证书，就会出现名称不匹配。攻击者通常不能仅靠修改 DNS 就获得目标域名的有效证书，因此证书警告是需要保留的安全边界。

先确认地址栏域名拼写，再检查本机 hosts、浏览器安全 DNS、路由器 DNS 与客户端 DNS 配置。mihomo 的 fake-ip 模式可能返回 198.18.0.0/16 范围内的映射地址；该网段本身不是污染证据。普通 nslookup 也未必经过浏览器的安全 DNS 或客户端实际使用的解析路径。

  • 在客户端「连接」或「日志」页面按目标域名筛选，确认命中的规则、策略组和最终节点；具体入口以客户端界面为准。
  • 检查是否有更靠前的 DOMAIN、DOMAIN-SUFFIX 或规则集把目标送往 DIRECT。规则通常按顺序匹配，切换策略组不一定改变已命中直连规则的请求。
  • 不要把全局模式当成长期开关来掩盖问题。可以短时用于对照，但完成测试后应恢复原模式并修正规则。
  • 公共 Wi-Fi 先完成系统提供的网络登录流程。若 HTTPS 页面被门户证书替代，改用可信网络验证，不要为门户放行目标网站的证书警告。

确认解析设置已修正后，才考虑清缓存。Windows 可执行 ipconfig /flushdns；macOS 可执行下列命令。浏览器和客户端也可能维护独立缓存，必要时完全退出后重新启动。

# macOS：刷新系统 DNS 缓存，需要管理员权限
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

如果同一节点持续返回不匹配证书，而另一可信节点与直连都正常，暂停使用该节点，并向服务提供方反馈脱敏后的证据。证据包括域名、时间、签发者和错误代码；不要提交订阅地址、节点密码或完整配置文件。

第五步：区分网站证书链与客户端信任库问题

系统时间正确、连接路径稳定后，剩余问题常见于证书链不完整或信任库差异。网站服务器若漏发中间证书，有的浏览器可能借助缓存补齐，另一些设备或命令行工具则会失败。不能因为一台电脑能打开，就认定服务器配置正确。

使用 OpenSSL 查看链与域名验证

在支持这些参数的 OpenSSL 环境中，可执行下列命令。-servername 指定 SNI，让共享 IP 上的服务器选择对应站点；-verify_hostname 明确启用域名检查。仅执行普通 s_client 并看到连接成功，不等于证书已通过完整验证。

# 直连检查：确保测试时没有 TUN 或其他透明转发
openssl s_client -connect example.com:443 \
  -servername example.com -showcerts \
  -verify_hostname example.com -verify_return_error < /dev/null

# 经过本地 HTTP CONNECT 代理；需要 OpenSSL 支持 -proxy
openssl s_client -proxy 127.0.0.1:7890 \
  -connect example.com:443 -servername example.com \
  -showcerts -verify_hostname example.com \
  -verify_return_error < /dev/null

查看输出中的验证错误、证书链和 Verify return code。OpenSSL 的信任库可能与 macOS 钥匙串、Windows 证书存储或浏览器不同；出现“无法取得本地签发者证书”时，需要同时考虑本地 CA 配置与服务端漏发中间证书，不能立刻断定是节点问题。

  • 只有一个网站失败，跨设备和网络一致：优先联系网站维护者，检查过期证书、SAN 与完整证书链。
  • 只有一台旧设备失败：更新受支持的操作系统与浏览器，再检查根证书更新状态，不从论坛下载来源不明的证书包。
  • 只有一个应用失败：检查该应用是否使用独立 CA 文件或证书固定机制。不要通过关闭验证来处理证书固定失败。
  • 出现证书吊销相关错误：记录具体错误和网络条件，检查吊销服务是否可达，交由管理员或网站维护者确认，不永久关闭吊销检查。

修复后的验证与安全边界

完成修改后，用原来报错的域名重新验证，而不是只打开另一个网站。依次检查浏览器、实际需要使用的应用，以及客户端日志中的规则与节点。恢复原先的规则模式，确认重启客户端后问题没有再次出现，才能认为配置已经稳定。

  1. 系统日期与时间正确，证书有效期覆盖当前时间。
  2. 证书 SAN 与目标域名匹配，证书链能够建立到设备信任的根证书。
  3. 系统代理、TUN、浏览器扩展与环境变量的用途明确，没有遗留的调试代理。
  4. 未使用忽略证书错误的浏览器启动参数，也未在命令行中跳过 TLS 验证。
  5. 重新测试原节点或替代节点，确认故障范围与修复动作一致。

如果曾在警告页继续访问并提交敏感信息，应在可信网络中更改相关密码、撤销可疑会话，并检查账户登录记录。证书警告并不自动证明信息已经泄露，但不应继续沿用有疑问的连接处理敏感操作。

下载Clash