外观
浏览器提示「您的连接不是私密连接」、客户端日志出现 x509 或 tls: handshake failure，都属于 TLS 与证书错误。TLS 是 HTTPS 和大多数代理协议所使用的加密层，证书则是服务器向你证明「我就是我」的凭证；任何一方出问题，连接都会在加密建立之前被中断。这类报错既可能出现在访问网站时，也可能出现在更新订阅或连接节点时。本页先用「两步速查」表按症状定位错误类型，简要讲清证书校验原理后，按第一步到第十步的顺序排查：确认错误发生在哪一段，依次检查系统时间、域名匹配、证书链、握手失败、程序差异和节点订阅，再分系统检查、对照报错、用命令诊断，最后给出恢复与预防方法，帮你判断问题在本机、代理链路还是目标服务，并避免用「跳过验证」这类有风险的方式草草了事。
两步速查：先定位问题类型
第一步在下表找到最接近你的症状和错误代码，判断属于时间、域名、信任链还是握手问题；第二步先做「第一个动作」，没解决再点「先看哪一节」跳到对应步骤，绝大多数证书问题在前两步就能解决。表中的错误代码以 Chrome 为例，其他浏览器的对应代码见后文「第九步：对照报错信息」。
| 症状 | 典型错误代码 | 可能原因 | 第一个动作 | 先看哪一节 |
|---|---|---|---|---|
| 几乎所有 HTTPS 网站都报错，提示日期无效 | NET::ERR_CERT_DATE_INVALID | 系统时间、日期或时区错误 | 开启自动设置时间并同步 | 第二步：检查系统时间与证书有效期 |
| 所有 HTTPS 网站都报颁发者不受信任 | NET::ERR_CERT_AUTHORITY_INVALID | 安全软件或抓包工具拦截 HTTPS | 查看证书颁发者，关闭 HTTPS 扫描 | 第四步：证书链和信任问题 |
| 连上公共 Wi-Fi 后所有网站报证书不匹配 | NET::ERR_CERT_COMMON_NAME_INVALID | 认证页拦截了 HTTPS 请求 | 关代理，先完成网页认证 | 第三步：域名和证书不匹配 |
| 只有开代理时某些网站报错 | 多种 | 节点或分流把请求送错了地方 | 换节点、关代理各对比一次 | 第一步：确认错误发生在哪一段 |
| 只有一个网站报错，关代理也报 | 多种 | 网站自身证书过期或配置错误 | 换设备、换网络确认后等待网站修复 | 第六步：对比浏览器、客户端与目标服务的差异 |
| 客户端更新订阅时报 x509 错误 | x509: ... | 时间错误、订阅域名证书问题或被拦截 | 校准时间，见 订阅更新失败 | 第七步：检查代理节点与订阅中的 TLS 问题 |
| 所有节点都报握手失败 | tls: handshake failure 等 | 时间错误、客户端过旧、订阅参数过期 | 校准时间、更新客户端和订阅 | 第五步：TLS 握手失败 |
| 个别节点报握手失败 | remote error: tls: ... | 该节点配置或证书问题 | 换节点，反馈给服务商 | 第五步：TLS 握手失败 |
| 浏览器报协议错误 | ERR_SSL_PROTOCOL_ERROR | 连接被干扰、代理异常或网站配置问题 | 关代理、换网络对比 | 第五步：TLS 握手失败 |
| 错误页没有「继续访问」按钮 | 任意证书错误 | 网站启用了 HSTS 等严格策略 | 找到并修复根本原因 | 第一步：确认错误发生在哪一段 |
名词速查
- TLS（传输层安全协议）：在 TCP 连接之上建立加密通道的协议，HTTPS 就是「HTTP + TLS」。
- 证书：由证书颁发机构（CA）签发的电子凭证，写明了它对哪些域名有效、有效期多长、由谁签发。
- 证书链：从网站证书到中间证书、再到设备内置根证书的一串签发关系，任何一环断开都无法验证。
- SNI（服务器名称指示）：客户端在握手时告诉服务器「我要访问哪个域名」，服务器据此返回对应的证书。
核心结论
核心结论
- 先看错误代码：时间无效、域名不匹配、颁发者不受信任、握手失败，对应的原因各不相同。
- 系统时间排第一：时间或时区错误是证书报错最常见、最容易修复的原因。
- 关代理对比一次：关闭代理后错误消失，问题在代理链路；仍然存在，问题在本机或目标网站。
- 看颁发者就能识别拦截：证书颁发者显示为安全软件、公司名或陌生名称，说明 HTTPS 被中间程序接管。
- 安全软件常被忽视：部分杀毒软件和抓包工具会拦截 HTTPS，导致证书不受信任。
- 不要随意跳过验证：浏览器的「继续访问」和客户端的「跳过证书验证」都会掩盖真正的风险。
TLS 与证书校验原理简述
一次 HTTPS 连接要先完成 TLS 握手：双方协商协议版本和加密算法，服务器出示证书，客户端校验证书，全部通过后才开始传输数据。证书错误发生在「校验证书」这一步，握手失败则可能发生在任何一步。
握手的大致过程
- 客户端发起连接，发送支持的 TLS 版本、加密算法列表和要访问的域名（SNI）；
- 服务器选定版本和算法，返回自己的证书（通常还附带中间证书）；
- 客户端校验证书：时间是否在有效期内、域名是否匹配、证书链能否追溯到受信任的根证书、证书是否被吊销；
- 校验通过后双方交换密钥，建立加密通道；
- 开始传输真正的网页或代理数据。
客户端校验的四个问题
| 校验项 | 失败时的典型报错 | 常见原因 |
|---|---|---|
| 时间是否有效 | 日期无效、已过期、尚未生效 | 本机时间错误，或证书真的过期 |
| 域名是否匹配 | 名称无效、域名不匹配 | 解析错误、认证页拦截、节点 SNI 填错 |
| 签发者是否受信任 | 颁发者未知、不受信任 | 安全软件拦截、自签名证书、系统根证书过旧 |
| 是否被吊销或使用弱算法 | 已吊销、签名算法弱 | 网站证书问题，与本机关系不大 |
代理链路中的两段 TLS
使用机场时往往存在两段独立的 TLS：一段是客户端到节点（很多代理协议用 TLS 包装流量），另一段是浏览器到目标网站（HTTPS 本身）。前者出错会体现在客户端日志里，表现为节点连不上；后者出错会体现在浏览器错误页上。两段的证书由不同的服务器出示，排查时不要混在一起。还有第三类情况是客户端到订阅服务器，出错时表现为订阅更新失败。
第一步：确认错误发生在哪一段
同样是证书错误，出现在浏览器里、客户端里，还是只出现在某个网站上，指向的问题完全不同。先确认错误发生在哪一段链路，再进入对应的小节。
定位错误发生的位置
| 错误出现在 | 说明问题在 | 下一步 |
|---|---|---|
| 客户端更新订阅时 | 本机到订阅服务器 | 时间、DNS、订阅域名，见 订阅更新失败 |
| 客户端连接节点时 | 本机到节点 | 时间、节点参数、客户端版本 |
| 浏览器访问所有 HTTPS 网站 | 本机设置或安全软件 | 时间、根证书、安全软件 |
| 浏览器访问个别网站 | 该网站或到该网站的线路 | 关闭代理对比、换节点对比 |
| 某个应用报错、浏览器正常 | 该应用的证书处理或代理设置 | 更新应用，检查其代理设置 |
关闭代理对比
| 开代理 | 关代理 | 判断 |
|---|---|---|
| 报错 | 正常 | 问题在代理链路：节点、分流规则或客户端配置 |
| 报错 | 报错 | 问题在本机或目标网站 |
| 正常 | 报错 | 当前网络直连到该网站受到干扰 |
换节点、换网络、换设备对比
- 换节点：只有个别节点出错，问题在节点；所有节点都出错，问题在本机或订阅；
- 换网络：连接手机热点后恢复，问题在原网络（认证页、中间设备或运营商）；
- 换设备：另一台设备同一网络下正常，问题集中在本机（时间、安全软件、根证书）。
第二步：检查系统时间与证书有效期
每张证书都有生效时间和过期时间。设备会用本机时间去判断证书是否有效，所以本机时间错了，正常的证书也会被判为「尚未生效」或「已过期」。
典型报错
| 来源 | 报错 |
|---|---|
| Chrome / Edge | NET::ERR_CERT_DATE_INVALID |
| Firefox | SEC_ERROR_EXPIRED_CERTIFICATE 或提示证书尚未生效 |
| 客户端日志 | x509: certificate has expired or is not yet valid |
Go 语言实现的客户端在这条报错后通常还会附上一句 current time ... is after ... 或 current time ... is before ...，前者表示本机时间晚于证书过期时间，后者表示本机时间早于证书生效时间，可以据此判断是本机时间偏快还是偏慢。
排查步骤
- 对比设备时间与手机或其他可靠来源的时间，注意日期和时区也要一致；
- 打开系统的自动设置时间和时区；
- 刷新网页或重新连接；
- 如果时间已正确、错误仍在，可能是网站证书真的过期了，换其他网站对比。
| 系统 | 设置路径 |
|---|---|
| Windows 10 / 11 | 设置 → 时间和语言 → 日期和时间 → 自动设置时间、自动设置时区，可点「立即同步」 |
| macOS | 系统设置 → 通用 → 日期与时间 → 自动设置时间和日期 |
| Android | 设置 → 系统 → 日期和时间 → 自动设置（菜单位置因品牌而异） |
| iOS / iPadOS | 设置 → 通用 → 日期与时间 → 自动设置 |
电脑主板电池
台式机每次开机时间都回到很久以前，可能是主板电池电量耗尽。联网后系统会自动校时，但在校时之前的连接可能报证书错误。
时间同步本身失败怎么办
自动校时需要访问时间服务器。如果代理客户端处于 TUN 模式且把时间同步流量也接管了，或者网络屏蔽了时间同步端口，自动校时可能失败。可以先关闭代理，让系统完成一次同步，再重新开启代理。命令行查看与时间服务器的偏差见后文「第十步：进阶诊断命令」。
第三步：域名和证书不匹配，查认证页与分流
证书只对特定的域名有效。你访问的域名与证书上写的域名不一致时，就会报不匹配。
典型报错
| 来源 | 报错 |
|---|---|
| Chrome / Edge | NET::ERR_CERT_COMMON_NAME_INVALID |
| Firefox | SSL_ERROR_BAD_CERT_DOMAIN |
| 客户端日志 | x509: certificate is valid for ..., not ... |
客户端日志里的 certificate is valid for A, B, not C 非常直观：A、B 是证书覆盖的域名，C 是你实际请求的域名。如果 A、B 是一个完全不相关的域名（比如某个认证页或运营商域名），基本可以断定请求被拦截或送错了服务器。
常见原因
| 原因 | 说明 | 处理方法 |
|---|---|---|
| DNS 解析到了错误的服务器 | 解析被污染或 hosts 被修改 | 检查 hosts，见 DNS 解析问题 |
| 网络中间设备拦截 | 公共 Wi-Fi 的认证页、运营商劫持 | 换网络对比，先完成公共 Wi-Fi 的登录认证 |
| 节点配置中的服务器名称错误 | 节点的 SNI 或服务器名称参数与服务端证书不一致 | 更新订阅，仍有问题联系服务商 |
| 网站自身配置错误 | 网站证书未覆盖该子域名 | 等待网站修复，与代理无关 |
| 用 IP 直接访问 HTTPS | 证书通常只写域名，不包含 IP | 改用域名访问 |
公共 Wi-Fi 的认证页
酒店、机场、咖啡店的 Wi-Fi 往往需要先在网页上登录。登录之前，所有 HTTPS 请求都可能被重定向到认证页，从而出现证书不匹配。先关闭代理完成认证，再开启代理。
第四步：证书链和信任问题，看颁发者
设备只信任由受信任机构签发的证书。如果证书链不完整，或签发者不在设备的信任列表中，就会报「颁发者未知」或「不受信任」。
典型报错
| 来源 | 报错 |
|---|---|
| Chrome / Edge | NET::ERR_CERT_AUTHORITY_INVALID |
| Firefox | SEC_ERROR_UNKNOWN_ISSUER 或 MOZILLA_PKIX_ERROR_MITM_DETECTED |
| 客户端日志 | x509: certificate signed by unknown authority |
| curl | curl: (60) SSL certificate problem: ... |
Mozilla 官方支持文档说明：如果在多个不相关的 HTTPS 网站上都出现 SEC_ERROR_UNKNOWN_ISSUER，通常意味着系统或网络中有程序在拦截连接并注入不受信任的证书，最常见的是扫描加密连接的安全软件；MOZILLA_PKIX_ERROR_MITM_DETECTED 是检测到中间人拦截时的特殊情况，可尝试关闭安全软件中的 SSL 扫描选项。
常见原因与检查方式
- 安全软件拦截 HTTPS：部分杀毒软件、家长控制和企业安全软件会用自己的证书替换网站证书。临时关闭其 HTTPS 扫描功能对比。
- 抓包或调试工具：如果安装过抓包工具并让它接管了流量，关掉后再测。
- 自签名证书：节点或订阅使用自签名证书时，客户端默认会拒绝，需要服务商提供正确的证书配置。
- 服务器未发送中间证书：浏览器有时能自动补全，命令行工具和客户端则会直接报错。这是服务端配置问题。
- 系统根证书过旧：长期未更新的旧系统可能缺少较新的根证书，更新系统后再试。
怎么看颁发者
在浏览器错误页点击「高级」或地址栏左侧的站点信息图标，可以查看证书详情。关注「颁发者」一栏：
| 颁发者显示为 | 说明 |
|---|---|
| 知名公共证书机构 | 证书本身来自正规渠道，问题可能在时间或域名 |
| 你安装的安全软件名称 | 安全软件在扫描 HTTPS，关闭该功能或更新软件 |
| 抓包工具名称 | 抓包工具仍在接管流量 |
| 公司或学校名称 | 所在单位的网络设备在检查流量，请遵守单位规定 |
| 完全陌生的名称 | 需要警惕，检查已安装的根证书和描述文件 |
各系统查看已安装证书的位置
| 系统 | 位置 |
|---|---|
| Windows | 运行 certmgr.msc 查看当前用户的证书，重点看「受信任的根证书颁发机构」 |
| macOS | 打开「钥匙串访问」，查看「系统」和「登录」钥匙串中的证书 |
| Android | 设置 → 安全 → 加密与凭据 → 信任的凭据（路径因品牌和系统而异） |
| iOS / iPadOS | 设置 → 通用 → VPN 与设备管理 查看描述文件；设置 → 通用 → 关于本机 → 证书信任设置 查看已启用完全信任的根证书 |
不要随意信任来源不明的根证书
信任一张根证书，意味着它签发的所有证书都会被设备接受。来源不明的根证书可能被用来查看你的加密流量。不认识的根证书和描述文件，建议删除。
第五步：TLS 握手失败，读懂 remote error
握手是建立加密连接的第一步。握手失败说明双方没能在协议版本、加密算法或参数上达成一致，或者连接在握手过程中被中断。
典型报错
| 来源 | 报错 | 大致含义 |
|---|---|---|
| Chrome / Edge | ERR_SSL_PROTOCOL_ERROR | 握手过程出错，常见于连接被干扰或代理配置异常 |
| Chrome / Edge | ERR_SSL_VERSION_OR_CIPHER_MISMATCH | 双方没有共同支持的协议版本或加密算法 |
| Chrome / Edge | ERR_CONNECTION_RESET / ERR_CONNECTION_CLOSED | 连接被重置或关闭，可能发生在握手阶段 |
| 客户端日志 | tls: handshake failure / remote error: tls: ... | 服务端在握手阶段拒绝 |
| 客户端日志 | tls: first record does not look like a TLS handshake | 对方返回的不是 TLS 数据，多为端口或协议错误 |
| 客户端日志 | EOF / connection reset 出现在握手阶段 | 握手中途连接被关闭 |
| curl | (35) SSL connect error | 建立 TLS 连接失败 |
读懂 remote error 后面的内容
remote error: tls: xxx 表示对方（服务器或节点）主动发来了一个 TLS 告警，后面的 xxx 就是告警类型：
| 告警文本 | 含义 | 常见原因 |
|---|---|---|
handshake failure | 无法完成握手 | 参数不匹配，常见于节点配置过期或客户端过旧 |
protocol version not supported | 不支持所请求的协议版本 | 客户端或服务端版本过旧 |
unrecognized name | 服务器不认识客户端发送的域名（SNI） | 节点的服务器名称参数错误 |
bad certificate / certificate required | 证书相关问题，或服务端要求客户端证书 | 节点配置问题，联系服务商 |
unknown certificate authority | 对方不信任所提供的证书 | 多见于双向认证场景 |
排查顺序
- 校准系统时间；
- 更新订阅，确保节点的 TLS 相关参数是最新的；
- 更新客户端，旧版本可能不支持服务端要求的协议或参数；
- 换一个节点对比：只有个别节点握手失败，多为节点配置问题；
- 换一个网络对比：换网络后正常，可能是当前网络干扰了加密连接；
- 关闭安全软件的 HTTPS 扫描后再测。
第六步：对比浏览器、客户端与目标服务的差异
浏览器、代理客户端和各类应用使用的证书库与校验逻辑并不相同，所以同一台电脑上可能出现「浏览器正常、客户端报错」或相反的情况。理解这些差异，可以避免在错误的地方浪费时间。
各类程序使用的证书库
| 程序 | 使用的信任列表 | 影响 |
|---|---|---|
| Chrome、Edge、Safari | 主要依赖操作系统或浏览器自带的根证书库，具体以浏览器文档为准 | 系统中安装的根证书会影响结果 |
| Firefox | 默认使用自带的根证书库 | 系统里信任的证书，Firefox 不一定信任 |
| 代理客户端内核 | 通常读取系统根证书 | 系统根证书过旧时客户端会报错 |
| 命令行工具（curl、git 等） | 系统证书库或自带的 CA 文件 | 与浏览器结果可能不一致 |
| 手机应用 | 系统证书库，部分应用额外固定证书 | 安装了用户证书仍可能被应用拒绝 |
典型差异场景
| 现象 | 解释 |
|---|---|
| Chrome 正常，Firefox 报颁发者未知 | 证书由仅在系统中信任的根签发，Firefox 自带库不认 |
浏览器正常，命令行报 (60) | 命令行工具的 CA 文件过旧，或服务器缺少中间证书 |
| 浏览器正常，客户端更新订阅报 x509 | 客户端使用的证书库或时间判断与浏览器不同 |
| 某个应用报网络错误，浏览器正常 | 应用固定了证书，被安全软件或抓包工具替换后拒绝连接 |
关于「跳过证书验证」
很多客户端提供跳过证书验证的选项（名称可能是 skip-cert-verify、allowInsecure 或「允许不安全」）。开启后客户端不再校验节点证书，报错会消失，但也失去了识别冒充服务器的能力。除非服务商明确要求，否则保持关闭，并把问题反馈给服务商。
第七步：检查代理节点与订阅中的 TLS 问题
客户端到节点、客户端到订阅服务器这两段 TLS 出错时，浏览器不会显示任何证书错误页，唯一的线索是客户端日志；这类问题的处理重点是更新订阅、更新客户端和反馈给服务商，而不是修改本机证书。
节点 TLS 参数是什么
很多代理协议会把流量包装在 TLS 里，节点配置中因此会出现一些与 TLS 相关的参数。它们由服务商在订阅中下发，普通用户一般不需要手动修改：
| 参数含义 | 作用 | 出错时的表现 |
|---|---|---|
| 是否启用 TLS | 决定客户端是否用 TLS 连接节点 | 与服务端不一致时，出现 first record does not look like a TLS handshake 或连接被关闭 |
| 服务器名称（SNI） | 握手时告诉节点要使用哪个域名的证书 | 与证书不符时报域名不匹配或 unrecognized name |
| 应用层协议（ALPN） | 协商在 TLS 之上使用的协议 | 与服务端不一致时握手失败 |
| 跳过证书验证 | 是否校验节点证书 | 打开后不再报证书错误，但安全性下降 |
不同客户端对这些参数的命名不同，具体字段以所用客户端的官方文档为准，修改前先备份原配置。
订阅更新时的证书错误
订阅地址本身也是 HTTPS 链接，更新时同样要校验证书。常见情况有三种：本机时间错误导致所有 HTTPS 请求都失败；订阅域名在当前网络下被解析到错误地址，出现域名不匹配；当前网络中的中间设备拦截了请求。前两种可以按本页「第二步：检查系统时间」和 DNS 解析问题 处理，第三种换网络对比即可确认。
示例场景：所有节点突然同时握手失败
某用户电脑重装系统后，客户端里所有节点都报握手失败，浏览器打开普通网站却正常。检查发现系统时区被设成了另一个地区，时间相差了若干小时：浏览器访问的网站证书有效期较长，偶尔能通过；而代理协议对时间更敏感，全部失败。开启自动设置时区并同步后恢复正常。这个场景说明，时间问题不一定在浏览器里先暴露出来。
示例场景：只有一个节点报证书不匹配
客户端日志显示某个节点报 x509: certificate is valid for A, not B，其他节点正常。更新订阅后问题依旧，说明不是本地缓存了旧参数，而是该节点服务端证书与下发的服务器名称不一致，属于服务商侧配置问题。此时应换用其他节点，并把日志原文提交给服务商，而不是在本地打开跳过证书验证。
安全软件与代理客户端的叠加
当安全软件开启了 HTTPS 扫描、同时代理客户端也在运行时，浏览器发出的 HTTPS 请求可能先被安全软件解密再加密，再交给客户端转发。此时浏览器看到的证书颁发者是安全软件，部分浏览器或应用会拒绝；而客户端与节点之间的 TLS 一般不受影响。判断方法是查看浏览器证书详情中的颁发者：若显示为安全软件名称，问题与代理无关，调整安全软件设置即可。
客户端版本过旧的影响
TLS 协议和代理协议都在持续演进，服务端启用新特性后，旧版本客户端可能无法完成握手，表现为所有节点同时失败、而同一订阅在更新过的设备上正常。遇到这种情况先更新客户端，并只从官方渠道获取安装包。
第八步：分系统排查步骤
下面按系统列出完整的排查顺序，每一步都说明「正常应该是什么样」，执行到某一步发现异常就先处理这一步，处理完再继续。
Windows 10 / 11
- 设置 → 时间和语言 → 日期和时间，确认自动设置时间、自动设置时区已开启，点击「立即同步」；
- 退出代理客户端，访问同一网站，确认错误是否消失；
- 打开安全软件设置，找到 HTTPS 扫描、网页防护、加密连接扫描之类的选项（名称以软件为准），临时关闭后再测；
- 运行
certmgr.msc，在「受信任的根证书颁发机构」中检查是否有不认识的证书，有则记录名称后再决定是否删除； - 检查 Windows 更新，确保系统根证书能正常更新；
- 重新打开代理客户端，更新订阅和客户端后再测。
macOS
- 系统设置 → 通用 → 日期与时间，确认自动设置已开启；
- 退出代理客户端对比；
- 打开「钥匙串访问」，在「系统」和「登录」钥匙串中按「种类：证书」筛选，查看是否有被设为「始终信任」的陌生根证书；
- 检查 系统设置 → 隐私与安全性 → 描述文件（不同版本位置可能不同）中是否有不认识的描述文件；
- 检查是否安装过抓包工具或安全软件的网络扩展，关闭后再测；
- 更新系统和客户端。
Android
- 设置 → 系统 → 日期和时间，开启自动设置（菜单位置因品牌而异）；
- 关闭代理应用对比；
- 在「信任的凭据」中切换到「用户」标签，查看是否有手动安装的证书；
- 检查是否安装了带有 HTTPS 过滤功能的广告拦截、家长控制或安全类应用；
- 系统长期未更新的旧机型，可能缺少较新的根证书，浏览器可改用自带证书库的浏览器测试。
从 Android 7.0 起，面向新系统版本开发的应用默认不信任用户自行安装的证书（除非应用在配置中主动声明信任），因此在 Android 上安装用户证书一般只对浏览器等部分应用生效，这也是「浏览器正常、应用报错」的常见原因之一。
iOS / iPadOS
- 设置 → 通用 → 日期与时间，开启自动设置；
- 关闭代理应用对比；
- 设置 → 通用 → VPN 与设备管理，检查是否有不认识的描述文件；
- 设置 → 通用 → 关于本机 → 证书信任设置，检查是否对陌生根证书启用了完全信任；
- 更新系统后再测。
第九步：对照报错信息
下表把各浏览器、客户端和命令行工具中常见的 TLS 与证书报错集中在一起，便于直接查找。Chrome 错误代码取自 Chromium 源码的错误列表，Firefox 错误代码参考 Mozilla 官方支持文档，客户端报错以 Go 语言标准库的错误文本为例，curl 错误号参考 curl 官方文档。
Chrome / Edge
| 错误代码 | 含义 | 优先检查 |
|---|---|---|
NET::ERR_CERT_DATE_INVALID | 证书已过期或尚未生效 | 系统时间 |
NET::ERR_CERT_COMMON_NAME_INVALID | 证书与域名不匹配 | 认证页、DNS、节点 |
NET::ERR_CERT_AUTHORITY_INVALID | 证书颁发者不受信任 | 安全软件、抓包工具、根证书 |
NET::ERR_CERT_REVOKED | 证书已被吊销 | 网站自身问题 |
NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM | 证书使用了弱签名算法 | 网站或拦截软件使用了旧证书 |
NET::ERR_CERT_INVALID | 证书无效 | 证书格式或拦截问题 |
NET::ERR_CERT_KNOWN_INTERCEPTION_BLOCKED | 检测到已知的拦截证书 | 检查设备上安装的根证书 |
ERR_SSL_PROTOCOL_ERROR | SSL 协议错误 | 关代理、换网络对比 |
ERR_SSL_VERSION_OR_CIPHER_MISMATCH | 无共同支持的协议版本或算法 | 网站配置过旧，或拦截软件不兼容 |
ERR_SSL_UNRECOGNIZED_NAME_ALERT | 服务器不认识请求的域名 | 网站配置或请求被送错服务器 |
ERR_BAD_SSL_CLIENT_AUTH_CERT | 客户端证书被服务器拒绝 | 多见于企业内网服务 |
Firefox
| 错误代码 | 含义 |
|---|---|
SEC_ERROR_UNKNOWN_ISSUER | 颁发者未知，不受信任 |
MOZILLA_PKIX_ERROR_MITM_DETECTED | 检测到中间人拦截，多为安全软件扫描 HTTPS |
SEC_ERROR_EXPIRED_CERTIFICATE | 证书已过期，或本机时间错误 |
MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE | 证书尚未生效，或本机时间偏早 |
SSL_ERROR_BAD_CERT_DOMAIN | 证书与域名不匹配 |
MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT | 自签名证书 |
SSL_ERROR_NO_CYPHER_OVERLAP | 无共同支持的加密算法 |
SSL_ERROR_RX_RECORD_TOO_LONG | 收到的数据不是正常的 TLS 记录，多为端口或协议错误 |
客户端日志（Go 内核）与命令行
| 报错文本 | 含义 |
|---|---|
x509: certificate has expired or is not yet valid | 时间不在证书有效期内 |
x509: certificate is valid for A, not B | 证书不覆盖请求的域名 |
x509: certificate signed by unknown authority | 颁发者不受信任 |
x509: cannot validate certificate for ... because it doesn't contain any IP SANs | 用 IP 访问，但证书只写了域名 |
tls: handshake failure | 握手失败 |
remote error: tls: ... | 对方发来 TLS 告警，看后面的告警类型 |
tls: first record does not look like a TLS handshake | 对方返回的不是 TLS 数据 |
curl: (35) ... | TLS 握手阶段出错 |
curl: (60) SSL certificate problem: ... | 服务器证书校验失败，冒号后说明具体原因 |
curl: (77) ... | 读取本地 CA 证书文件出错 |
中文界面的错误页
中文界面的 Chrome 证书错误页标题通常是「您的连接不是私密连接」，具体错误代码显示在页面中部或点击「高级」后的说明里。反馈问题时请提供错误代码，而不是只描述标题。
第十步：进阶诊断命令
命令行可以绕开浏览器界面，直接看到服务器返回的证书和握手细节，是定位证书问题最可靠的方法。以下命令都只读取信息，不会修改系统设置。
查看证书与握手过程
bash
# 查看详细的 TLS 握手过程和证书校验结果
curl -v https://example.com -o /dev/null
# 查看服务器返回的证书主题、签发者和有效期（macOS / Linux）
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates
# 显示服务器发送的完整证书链，检查是否缺少中间证书
echo | openssl s_client -connect example.com:443 -servername example.com -showcerts
# 查看证书覆盖的全部域名（在输出中查找 DNS: 开头的条目）
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -text | grep "DNS:"Windows 10 及以上自带 curl，在 PowerShell 中输入 curl.exe -v https://example.com -o NUL。openssl 在 Windows 上通常需要另行安装；macOS 自带的 openssl 命令实际是 LibreSSL，个别参数可能与 OpenSSL 不同，以 openssl s_client -help 的输出为准。
指定协议版本测试
bash
# 只用 TLS 1.2 握手
curl -v --tlsv1.2 --tls-max 1.2 https://example.com -o /dev/null
# 只用 TLS 1.3 握手
curl -v --tlsv1.3 https://example.com -o /dev/null如果某个版本能握手、另一个不能，说明问题与协议版本有关：可能是网站只支持某一版本，也可能是中间设备干扰了特定版本。
通过代理和不通过代理分别测试
bash
# 不经过代理（若设置了代理环境变量，先用 --noproxy 绕开）
curl -v --noproxy "*" https://example.com -o /dev/null
# 经过客户端本地端口（端口换成客户端实际端口）
curl -v -x http://127.0.0.1:7890 https://example.com -o /dev/null两次输出中证书的 issuer 不同，说明某一侧被拦截；直连握手失败而经过代理正常，说明当前网络直连该网站受到干扰。
检查时间偏差
bash
# Windows：查看本机与时间服务器的偏差（只读）
w32tm /stripchart /computer:time.windows.com /samples:3 /dataonly
# Windows：查看时间同步状态
w32tm /query /status
# macOS：查询与时间服务器的偏差（只查询，不修改）
sntp time.apple.com
# Linux（systemd）：查看时间与同步状态
timedatectl偏差在秒级不影响证书校验；偏差达到小时或天级，就足以导致证书错误。
区分「连不上」和「握手失败」
powershell
# Windows PowerShell：只测试 TCP 端口是否可达
Test-NetConnection example.com -Port 443TcpTestSucceeded 为 True 说明 TCP 能连上，问题在 TLS 层；为 False 说明连 TCP 都没建立，属于连接问题，应参考 节点连接失败。macOS / Linux 可用 nc -vz example.com 443 做同样的测试。
输出怎么看
| 关注项 | 正常情况 | 异常说明 |
|---|---|---|
subject | 包含你访问的域名 | 域名不一致，可能被劫持或解析错误 |
issuer | 知名证书机构 | 显示为安全软件或未知名称，说明流量被拦截 |
notBefore / notAfter | 当前时间在两者之间 | 超出范围说明证书过期或本机时间错误 |
curl 的 SSL certificate verify 结果 | ok | 校验失败时会说明具体原因 |
-showcerts 输出的证书数量 | 通常至少包含网站证书和中间证书 | 只有一张且颁发者不是根证书，可能缺少中间证书 |
curl -k 只用于诊断
curl 的 -k（--insecure）会跳过证书校验。它只适合用来确认「除了证书之外其他都正常」，不要把它写进脚本或日常使用，更不要据此认为连接是安全的。
恢复与预防
证书问题修好之后，要把排查过程中临时关闭或修改的设置逐项恢复，并养成几个习惯，避免同样的问题反复出现。恢复的原则是：安全相关的设置一律回到默认，临时信任过的证书一律撤销。
恢复清单
- 重新开启安全软件的防护：如果你为了排查关闭了 HTTPS 扫描，确认问题后要么恢复，要么把它调整为与代理兼容的设置（具体以安全软件文档为准）；
- 关闭客户端中的跳过证书验证：排查时若临时打开过，务必关回去；
- 删除临时安装的根证书和描述文件：特别是抓包工具生成的证书；
- 保持自动时间同步开启；
- 撤销 curl、git 等工具中关闭证书校验的配置，例如 git 的
http.sslVerify false，可用git config --global --unset http.sslVerify删除。
预防习惯
- 保持系统、浏览器、客户端更新：根证书库和 TLS 实现会随更新改进；
- 只从官方渠道下载客户端：来路不明的修改版可能内置了不安全的证书设置，见 客户端下载；
- 公共 Wi-Fi 先认证再开代理；
- 不随意安装根证书：任何要求你「安装并信任证书」的网页或应用，都需要先确认来源；
- 出现证书错误先停下：不要习惯性点击「继续访问」，尤其是涉及登录和支付的网站。
一页排查清单
按顺序逐项核对，全部完成后仍然报错，问题大概率不在本机：
- 已记录完整的错误代码或日志原文，而不只是错误页标题；
- 系统日期、时间、时区均正确，自动同步已开启；
- 关闭代理、换一个节点、换一个网络各对比过一次；
- 已查看证书颁发者，并临时关闭过安全软件的 HTTPS 扫描；
- 系统中没有不认识的根证书和描述文件；
- 客户端与订阅都已更新到最新，跳过证书验证处于关闭状态；
- 用 curl 或 openssl 直接查看过服务器证书的域名、颁发者和有效期。
把清单的核对结果一并写进工单，服务商可以直接跳过基础排查，更快定位问题。
何时联系服务商
- 订阅地址或节点在时间正确、换网络后仍报证书错误；
- 日志显示节点证书过期或与节点域名不匹配；
- 服务商要求开启跳过证书验证才能使用。
提交工单时附上这些信息
完整的错误代码或日志原文、出错的节点名称、系统时间截图、客户端名称和发生时间。注意遮挡订阅链接和账号信息。
常见问题
浏览器提示「您的连接不是私密连接」该怎么办？
先看错误代码。DATE_INVALID 多为系统时间不准，COMMON_NAME_INVALID 是域名与证书不匹配，AUTHORITY_INVALID 是证书不受信任。先校准系统时间，再关闭代理对比，不要直接点「继续访问」。
客户端里能不能打开「跳过证书验证」来解决报错？
不建议。跳过证书验证会让客户端无法识别被冒充的服务器，存在安全风险。只有在服务商明确说明该节点需要这样设置时才考虑，并优先要求服务商修复证书。
为什么只有开着代理时才出现证书错误？
可能是节点或分流规则把请求送到了错误的服务器、客户端配置了需要信任根证书的功能，或节点到目标网站的链路被干扰。切换节点和关闭代理各对比一次即可缩小范围。
系统时间差几分钟会导致证书错误吗？
几分钟的偏差一般不会触发网页证书错误，但部分代理协议对时间更敏感。时间偏差到数小时甚至数天，或时区设置错误时，证书错误就很常见了，建议始终开启自动设置时间。
所有 HTTPS 网站都报证书不受信任，是被攻击了吗？
最常见的原因是本机安全软件或抓包工具在扫描 HTTPS 流量，它们会用自己的证书替换网站证书。先查看证书的颁发者名称，再临时关闭相关软件的 HTTPS 扫描对比；若颁发者完全陌生且无法解释，应按安全事件处理。
为什么浏览器错误页上没有「继续访问」按钮？
对启用了 HSTS 等严格安全策略的网站，浏览器不允许用户绕过证书错误，因此不会显示继续访问的选项。这种情况只能找出并修复错误原因，例如校准时间、关闭 HTTPS 扫描或换网络。
客户端日志里的 tls: first record does not look like a TLS handshake 是什么意思？
这表示客户端期望收到 TLS 握手数据，但对方返回的不是 TLS 内容，常见于端口或协议配置错误、请求被认证页或中间设备截获。先更新订阅确认节点参数，再换网络对比。
电脑上没有 openssl 怎么查看网站证书？
可以在浏览器地址栏左侧点击站点信息图标查看证书详情，或使用系统自带的 curl 加 -v 参数查看握手过程和证书校验结果。Windows 10 及以上在 PowerShell 中需输入 curl.exe。
延伸阅读
- 如何挑选一个靠谱的机场：证书错误多数和系统时间、安全软件有关；确认是服务端证书长期异常且服务商不处理时，再按这里的原则考虑备用服务。
- DNS 解析问题：解析到错误服务器导致证书不匹配时的排查。
- 节点连接失败：握手失败导致节点连不上时的整体排查。
- 节点全部超时排查：所有节点同时异常时的专项步骤。
- 订阅更新失败：更新订阅时出现证书错误的处理。
- 代理与系统冲突：安全软件、多个代理工具冲突的排查。
- 客户端下载：从官方渠道获取和更新各平台客户端。
- 客户端配置教程：节点参数、TLS 相关选项在配置中的位置。
更新记录
| 日期 | 变更 |
|---|---|
| 2026-10-07 | 首次发布完整内容 |
| 2026-10-07 | 扩写为深度指南 |
| 2026-10-08 | 按搜索结果页结构调整：开头加「两步速查：先定位问题类型」表（新增「先看哪一节」列），正文小标题改为第一步到第十步的排查顺序 |
本专题文章
暂无文章，敬请期待。