适合在 v2rayN、v2rayNG 或 v2flyNG 中遇到 TLS 握手失败、证书过期、域名不匹配的用户。先定位日志来自订阅更新还是节点连接，再依次检查时间、地址与端口、SNI、证书链和传输参数。读完可以判断哪些设置能在客户端修复，哪些必须交由节点维护者处理，以及为什么不应把 allowInsecure 当成日常连接方案。
先确认 TLS 报错来自哪条连接
“握手失败”是结果，不是唯一原因。一次普通 TLS 连接要先解析服务器地址、建立 TCP 连接，再协商 TLS 参数并验证证书；代理协议认证和实际转发通常发生在后面。某个域名解析失败、443 端口不可达，或者协议认证被拒绝，都可能在客户端上表现为连接失败，却不能靠修改证书设置解决。
首先看报错发生在什么操作之后。点击“更新订阅”出现证书错误，涉及的是订阅服务器的 HTTPS 连接；选中节点后访问网页，核心日志出现 x509，才可能是代理出站的 TLS 验证失败。节点编辑页里的 allowInsecure 通常不会改变订阅下载所使用的 HTTPS 验证行为。
- 订阅更新失败：记录更新时间和订阅服务域名，检查系统时间及订阅服务证书，不要公开完整订阅地址。
- 节点连接失败：在 v2rayN 主界面查看日志输出，或在 v2rayNG 菜单的「日志」中定位同一时刻的出站错误。
- 浏览器单独报错：检查报错域名是否属于目标网站；不要把目标网站证书错误直接归因于代理节点。
按报错原文划分排查方向
不同内核和版本会在原文外面加上连接上下文。以下片段是常见的核心错误信息，不要求整行日志完全相同。它们能缩小范围，但单条报错通常不能证明最终原因。
报错:x509: certificate has expired or is not yet valid
原因与解法:设备时间不在证书有效期内，或服务端证书确实过期。先同步系统时间；时间正确仍复现时，由维护者检查证书有效期及续期后的服务重载。
报错:x509: certificate is valid for edge.example, not node.example
原因与解法:客户端验证的名称不在证书覆盖范围内。核对服务端要求的 SNI 和证书 SAN，不要只因连接地址是 node.example 就把 SNI 也设成该地址。
报错:x509: certificate signed by unknown authority
原因与解法:信任链无法建立，可能是缺少中间证书、自签名证书、旧信任库或网络中的证书替换。比较不同设备与网络的结果，再检查服务端完整证书链。
报错:remote error: tls: handshake failure
原因与解法:对端拒绝握手，可能涉及 SNI、协议版本、客户端指纹或服务端策略。按原始节点配置逐项恢复参数，不把它直接解释为证书过期。
报错:tls: first record does not look like a TLS handshake
原因与解法:目标端口返回了非 TLS 数据。核对端口和 TLS 开关，例如不要把提供明文 HTTP 的 80 端口当成 TLS 服务的 443 端口。
EOF、connection reset by peer 与 i/o timeout 的范围更宽。它们可能来自中途断开、防火墙、错误端口或服务器不可用，不能仅凭这些词就开启跳过证书验证。先确认 TCP 连接是否能建立，再处理 TLS 层。
系统时间与节点参数的五步检查
每次只修改一个变量，并重复同一种测试请求。先保存原配置，避免把地址、端口、SNI 和指纹一起更改，最后虽然能连上，却无法确认究竟修复了哪一项。下面的 Windows 路径以 Windows 11 中文界面为例；客户端字段位置会随桌面界面和版本变化，字段含义不变。
-
同步时间
Windows 进入「设置」→「时间和语言」→「日期和时间」，开启「自动设置时间」，点击「立即同步」。Android 通常在「设置」→「系统」→「日期和时间」开启自动时间，厂商也可能放在「更多设置」中。核对实际日期与时间，不只看时区名称。
-
核对端口
v2rayN 在主界面双击当前节点打开编辑页；v2rayNG 在节点列表点击对应节点的编辑图标。对照节点提供方给出的「地址」和「端口」。TLS 常用 443，但节点使用 8443 或其他端口同样正常，不能看到证书错误就统一改成 443。
-
检查 SNI
查看节点编辑页的 TLS 或传输安全区域，核对「SNI」或「serverName」字段。填服务端要求的域名，不带
https://、端口、路径和空格。连接地址与 SNI 可以不同，不能用自己的猜测替代节点参数。 -
恢复验证
检查「允许不安全连接」或「allowInsecure」，正常使用应关闭，即
false。同时恢复提供方要求的指纹与 ALPN；如果原配置没有这些值，不要为了消除报错随意添加。 -
重连看日志
保存节点并重新启动连接。v2rayNG 可先停止再启动连接；v2rayN 保存后确认当前选中的是修改过的节点，重新发起测试。记录错误是否从证书错误变成连接超时或协议认证错误，这代表失败阶段已经变化。
证书验证使用的是实际时间点。仅仅调整显示时区而不修正错误的系统时钟，通常解决不了有效期问题。例如系统日期停留在 2025 年，而证书从 2026 年才开始有效，就会出现“尚未生效”；反过来，系统日期跳到未来也可能把仍有效的证书判断为过期。
# Linux：查看系统时间与同步状态
timedatectl status
# Linux：启用系统支持的网络时间同步，通常需要管理员权限
sudo timedatectl set-ntp trueLinux 的第二条命令依赖系统已提供可用的时间同步服务；设置后仍应重新查看同步状态。macOS 可在「系统设置」→「通用」→「日期与时间」检查自动设置。时间已准确且只有一个节点报错时，不必反复改设备时间，应转向服务端证书和节点参数。
SNI、连接地址与 Host 不是同一个字段
SNI 是 TLS 握手中客户端告知服务器的名称，常用于选择虚拟站点和证书。普通 TLS 配置里的 serverName 还通常用于确定证书验证名称。连接地址负责找到服务器，HTTP Host 则属于更上层的 HTTP 请求。三者可能相同，也可能按服务部署要求分别填写。
| 字段 | 作用阶段 | 填写依据 | 常见错误 |
|---|---|---|---|
| 地址与端口 | 解析和建立连接 | 节点实际入口，例如 443 或 8443 | 把订阅网站地址当成节点地址 |
| SNI / serverName | TLS 握手与名称验证 | 服务端允许的名称及证书 SAN | 加入协议前缀、路径，或随意换域名 |
| WebSocket Host | HTTP 升级请求 | 反向代理的虚拟主机配置 | 以为修改 Host 会自动修正 SNI |
| WebSocket path | 请求路径匹配 | 服务端设定的路径 | 路径错误却只排查证书 |
例如，入口地址是 node.example，服务端要求的 SNI 是 edge.example，那么连接仍然发往入口，但普通 TLS 的证书应覆盖 edge.example。本文这些 .example 名称只是保留域名示意，不是可用节点。如果直接用 IP 连接，却没有设置正确的验证名称，证书只覆盖域名时就可能发生名称不匹配。
结论:先对照字段，再改域名
出现名称不匹配时，先向维护者确认地址、SNI 和 HTTP Host 各自的值。只有证书实际覆盖且服务端接受的名称才有意义，换成一个知名网站域名并不能修复普通 TLS 配置。
所谓“伪装域名”不是统一技术字段。有的配置用它指 SNI，有的指 HTTP Host，有的涉及 REALITY 的服务端名称。必须先确认传输安全方式：普通 TLS 的 CA 证书验证，与 REALITY 使用的认证参数不是同一套排错流程。
证书链、指纹与传输参数怎样检查
浏览器能打开同一个域名，不代表代理节点的 TLS 配置一定正确。浏览器可能连接 443，而节点连的是 8443；两次请求也可能采用不同 SNI、不同入口地址，或不同的信任库。应对照同一个入口和同一个名称，才有诊断价值。
- 完整证书链：服务端通常应发送叶证书和需要的中间证书。缺少中间证书时，部分设备能建立信任链，另一些设备却会提示 unknown authority。
- 域名覆盖：检查证书的 Subject Alternative Name。
*.example.com通常覆盖a.example.com，不覆盖a.b.example.com，也不自动覆盖example.com。 - TLS 版本：TLS 1.2 与 TLS 1.3 是协议版本，不是客户端版本号。如果两端没有共同支持的版本或密码套件，可能在证书验证之前就失败。
- 客户端指纹：Xray 的相关配置可用指纹选项调整 ClientHello 特征，例如
chrome。它不是服务端证书指纹，也不等于关闭身份验证。支持范围应按当前内核判断。 - ALPN：
h2与http/1.1用于协商应用协议。gRPC、WebSocket 和普通 TCP 的部署要求不同，不要从其他节点照搬 ALPN 列表。
如果设备已安装 OpenSSL，可用下面的命令检查普通 TLS 入口。示例使用保留域名，需要按自己的入口和 SNI 修改后再执行；这不是代理协议测试，也不能用来验证 REALITY 节点是否可用。
openssl s_client \
-connect node.example:443 \
-servername edge.example \
-verify_hostname edge.example \
-verify_return_error \
-showcerts-connect 决定连接目标，-servername 发送 SNI，-verify_hostname 明确验证名称。只发送 SNI 并不等于已经执行域名匹配验证。查看证书有效期、名称和验证结果；工具使用的信任库也可能与客户端不同，因此结果应作为定位线索，而不是唯一结论。
allowInsecure 为什么不应长期打开
在常见 V2Ray/Xray 普通 TLS 配置中，allowInsecure: true 会跳过服务端证书链和名称的正常验证。连接仍可能使用加密，但客户端失去了对连接对象身份的可靠确认。能加密传输，不代表加密的另一端就是预期服务器。
| 问题 | 开启后可能改变吗 | 正确处理 |
|---|---|---|
| 证书过期或名称不匹配 | 可能绕过验证错误 | 修正时间、SNI，或更新服务端证书 |
| 自签名证书不被信任 | 可能绕过信任链错误 | 按受控环境要求配置可信证书或受支持的信任方案 |
| 端口不通、连接超时 | 不能修复网络连通性 | 核对端口、网络与服务状态 |
| 路径、认证参数错误 | 不能修复上层协议配置 | 恢复正确路径和节点凭据 |
| REALITY 认证失败 | 不能替代其认证过程 | 核对 REALITY 专用参数与内核支持 |
如果为了受控诊断临时开启后能连接，只能说明证书验证很可能参与了失败，不能证明节点安全或所有问题已经解决。诊断时不要传输敏感业务，结束后立即关闭，并根据原始错误修复具体原因。更稳妥的做法是先用日志和证书检查定位，不以长期跳过验证换取“能连”。
结论:验证恢复后才算修复
把 allowInsecure 恢复为 false，再用同一节点重复连接。如果仍然报错，就继续修正时间、名称或信任链；只有正常验证通过且实际请求成功，才完成了这次证书故障排查。
常见追问与提交故障信息
电脑能连，Android 为什么提示证书不可信？
先让两台设备使用同一节点、SNI 和网络，并确认自动时间已开启。若参数一致，检查系统信任库差异及服务端是否遗漏中间证书；不要直接复制电脑上的跳过验证设置。
更新订阅后突然握手失败，该重新安装吗？
先在节点编辑页对比地址、端口、TLS 类型和 SNI 是否变化，确认选中的是新节点而非旧副本。重新安装一般不能修复服务端过期证书；先保存错误原文并联系维护者核对配置。
为什么换成手机热点就正常了？
这说明网络路径可能影响连接，但还不能直接判定原因。保持节点参数不变，分别记录两种网络的错误；如果异常网络出现未知签发机构，检查是否存在 HTTPS 检查或证书替换，不要盲目信任来历不明的根证书。
延迟测试通过，是否代表证书已经正常？
不一定。TCP 延迟测试只说明端口连接成功，未必执行 TLS 验证和代理请求。确认使用的测试类型，再实际发起请求并查看核心日志；不要把一个延迟数字当成完整连接验收。
证书续期了，客户端为什么还提示过期？
请维护者检查服务是否重新加载新证书，以及不同入口是否仍提供旧证书。客户端同时确认时间和入口地址；多台服务器或 IPv4、IPv6 入口配置不一致，也可能导致只有部分连接失败。
需要进一步协助时，提交能复现问题的最小信息即可。不必贴出整个配置文件，更不要把订阅链接当成故障截图的一部分。可以参考下面的清单整理，再前往本站的故障排查继续定位；字段含义不清楚时，可查阅概念速查。
- 客户端名称、实际版本、正在使用的内核名称与版本，以及操作系统版本。
- 操作发生在订阅更新、节点测试还是实际访问，附发生时间与脱敏后的错误原文。
- 端口、传输类型、TLS 或 REALITY 类型，以及 SNI 是否与连接地址一致，不附节点凭据。
- 系统时间是否同步、换网络是否复现、另一台设备是否正常，以及已尝试的单项修改。