适用于 v2rayN、v2rayNG 与 v2flyNG 连接节点时出现的 TLS 握手和证书验证问题。先从内核日志区分超时、证书日期与域名不匹配，再依次检查系统时间、节点地址、SNI、传输参数及服务端证书链。排查时一次只改一项，保留证书验证，不把开启 TUN 模式当作修复握手的通用办法。
一、先确认失败发生在哪一层
TLS 握手发生在建立安全连接的过程中，通常早于实际业务数据传输。节点列表里能测到延迟，并不等于 TLS 已通过：TCP 连通性测试可能只证明端口可达，无法证明证书、身份认证和代理转发都正常。VMess、VLESS 是代理协议名称，TLS 是安全层选项，二者不能混为一个设置。
在 v2rayN 主窗口底部的日志区域查看连接失败前后的内容；Android 端可从侧边菜单进入「日志」。不同版本入口位置可能调整，应以当前界面为准。先清理或记住旧日志的时间，再只发起一次访问，避免把订阅下载错误、节点连接错误和目标网站错误看成同一次故障。
报错：x509: certificate has expired or is not yet valid
原因：本机时间不在证书有效期内，也可能确实是服务器证书过期。解法：先同步本机时钟，再对照日志中的当前时间与证书有效期；时间正确仍失败，交由节点维护方检查证书。
报错：x509: certificate signed by unknown authority
原因：证书链无法连接到受信任根证书，可能涉及缺失中间证书、自签名证书或本地 HTTPS 检查。解法：检查系统更新、网络环境和服务端完整证书链，不要直接关闭验证。
报错：remote error: tls: handshake failure
原因：对端拒绝了握手，可能是 SNI、TLS 参数或入口服务配置不匹配。解法：对照原始节点配置复核安全层与传输方式，并请维护方查看同一时刻的服务端日志。
如果日志只有 i/o timeout、connection refused 或 EOF，还不足以认定证书有问题。应先验证节点地址能否解析、远端端口是否可达、对应端口是否真的运行 TLS 服务。记录完整的错误链比只截取最后一个单词更有用。
二、校准系统时间，再重试连接
证书有明确的生效和到期时间。本机日期错到上一年，或虚拟机从旧快照恢复后时钟偏移，都可能让有效证书变成“尚未生效”或“已经过期”。先修正时间，再讨论节点参数，可以少改很多原本正确的配置。
-
检查日期
Windows 11 打开「设置」→「时间和语言」→「日期和时间」，核对年月日与当前时间。不要只看任务栏的小时和分钟。
-
执行同步
开启「自动设置时间」，在「其他设置」中点击「立即同步」。若同步失败，先确认当前网络可正常访问时间服务；组织管理的设备应遵循管理员配置。
-
检查安卓时间
Android 通常在「设置」→「系统」→「日期和时间」开启「自动设置时间」和「自动设置时区」。部分设备将入口放在「更多设置」，以系统搜索“日期和时间”定位。
-
重新取日志
时间修正后停止并重新启动客户端连接，再发起一次访问。若仍报日期错误，对照日志中证书的有效期，避免反复更换节点传输参数。
macOS 可在「系统设置」→「通用」→「日期与时间」检查自动设置；Linux 可用下方命令查看时钟与同步状态。时区主要影响显示，证书验证比较的是绝对时间，单纯把显示时区换成本地时区并不能修正错误的系统时刻。
timedatectl status判断：先确认时钟，再修改节点
若多个不同来源的 TLS 节点同时出现证书日期错误，优先检查本机时钟；若时间准确且只有一个节点报过期，应把错误时间和节点标识交给维护方处理。
三、分清服务器地址、SNI 与 Host
在 v2rayN 的节点列表中，双击目标节点进入编辑窗口，找到「地址」「端口」以及 TLS 区域的「SNI」或「服务器名称」字段。v2rayNG 与 v2flyNG 可通过节点右侧的编辑入口查看对应参数。字段名称会随版本与协议变化，不应为了对上截图而切换协议类型。
| 字段 | 实际作用 | 核对方法 |
|---|---|---|
| 服务器地址 | 决定客户端连接哪个 IP 或域名 | 核对订阅原始值及 DNS 解析结果，不附带网页路径 |
| 远端端口 | 指定服务监听入口 | 按服务端配置填写，不能因为使用 TLS 就统一改成 443 |
| SNI / serverName | 通常用于握手时告知域名，并作为证书名称验证依据 | 使用维护方提供的域名，确认证书覆盖该名称 |
| WebSocket Host | 用于 HTTP 请求的虚拟主机匹配 | 与反向代理或 CDN 配置一致，不视为 SNI 的替代品 |
| WebSocket Path | 决定请求转发到哪条路径 | 核对大小写与开头的斜杠，不把它填进 SNI |
例如证书包含 edge.example.net，而 SNI 填成 other.example.net，就可能出现名称不匹配。SNI 应填写纯域名，不带 https://、端口或 /ws。这里的域名只是字段格式示例，不是可用节点，不能直接用于连接。
服务器地址是 IP、SNI 是域名的组合可以成立，前提是对端配置与证书相匹配。使用 IP 连接时若没有设置正确的验证名称，客户端可能按 IP 验证证书，而普通域名证书通常不包含该 IP。界面中的“伪装域名”并不是可以随意填写的域名，仍须区分它对应的是 HTTP Host 还是 TLS 服务器名称。
四、核对证书链与传输安全类型
本机时间和 SNI 正确后，再检查系统信任与服务端证书链。旧系统缺少根证书更新，或服务端只发送站点证书、漏发中间证书，都可能造成验证失败。浏览器能够打开同域名网页也不能完全排除问题：浏览器与代理内核可能使用不同的信任来源或证书链补全机制。
- 只有一台设备失败：检查系统日期、系统更新和受管理的根证书策略；在获准的另一网络重试，判断是否涉及网络侧 HTTPS 检查。
- 所有设备同一节点失败：请维护方检查证书到期时间、完整证书链、域名覆盖范围及证书更新后的服务重载状态。
- 近期改过传输：重新核对 TCP、WebSocket、gRPC 与 TLS 开关。向普通 HTTP 端口发送 TLS 握手，不会靠修改 SNI 自动修复。
- 订阅恢复后又报错：检查是否手动修改过节点。订阅更新可能覆盖本地改动，应修正订阅源，而不是依赖每次更新后手动补参数。
若日志指向 REALITY 验证失败，优先重新导入可信来源的完整配置，再核对客户端和内核是否支持该配置。不要把安全类型从 REALITY 改成 TLS 试运气，也不要把公钥当成证书域名填写。
五、为什么不应跳过证书验证
节点编辑页中的「允许不安全连接」「跳过证书验证」或配置中的 allowInsecure，会改变对服务端身份的验证行为。数据即使仍经过加密，也不代表对端身份已经可信。错误的证书、错误的入口甚至被替换的连接，都可能因此不再触发原本的证书告警。
- 日期错误应修正系统时钟，服务端证书过期应更新证书，而不是让客户端忽略过期。
- 域名不匹配应核对 SNI 和证书覆盖范围，不应把关闭验证当作长期设置。
- 自建服务若确需私有信任，应在明确理解证书分发和信任范围后配置；不要导入陌生人提供的根证书。
- 曾为排查临时改动该开关，应恢复验证并重新测试，确认最终配置仍能正常连接。
开启系统代理或 TUN 模式改变的是流量进入代理的方式，通常不会修复节点自身的证书错误。如果错误实际来自订阅地址的 HTTPS 请求，则应核对订阅域名与更新所走的网络；它与当前节点的 TLS 握手是两条不同连接，修改节点 SNI 不会修好订阅网站证书。
六、常见追问与排查记录
时间同步了，还是提示证书过期？
重新连接并看新日志，确认不是旧记录。若系统日期正确，且错误中的到期时间确实已过去，请节点维护方更新证书并重载相关服务，不要继续调整本机时区。
订阅里的 SNI 是空白，要补吗？
先看服务器地址是不是域名，以及当前内核是否据此推导服务器名称。空白不必然错误；若日志明确显示名称验证失败，应向维护方确认预期 SNI，不能从其他节点抄一个域名。
手机能连，电脑不能连，先改什么？
先对照两端的节点地址、端口、SNI、安全类型与传输参数，再检查电脑时间和系统信任。保留原配置，每次只改一项。不要因为 Android 端可用就忽略桌面内核和配置兼容性。
怎样把问题发给维护方更有效？
提供客户端与内核版本、错误发生时间及带上下文的错误原文，说明是否已同步时间、是否所有节点都失败。遮住订阅链接、UUID、密码和认证信息；不要直接发送整份配置。
收尾时，用同一节点、同一访问目标重新测试，确认新日志不再出现相同错误，再恢复日常路由分流。若仍然失败，保留“修改了什么、错误是否变化”的简短记录：从证书日期错误变成连接超时，是新的排查线索，不应继续重复同一套证书操作。