V2Ray 或 Xray 内核建立加密连接时，会先完成 TCP 或其他底层传输，再进行 TLS 握手。证书有效期、证书域名、系统时间、SNI、TLS 版本与客户端指纹中的任意一项不一致，都可能让连接在代理请求发出之前终止。因此，浏览器显示连接失败、v2rayN 测速为不可用或 v2rayNG 日志出现证书错误，并不能直接说明服务器端口已经关闭。
本文速览
本文适合遇到 TLS handshake、x509、certificate、serverName 或 SNI 报错的 v2rayN、v2rayNG 与 v2flyNG 用户；按照“读日志、校时间、核域名、查参数、再复测”的顺序，可以判断故障位于本机、节点配置还是服务器证书链。
先从日志区分 TLS 报错类型
TLS 故障的第一步不是反复点击测速，而是保存一次完整日志。v2rayN 可在主界面的日志区域查看内核输出，也可通过「设置」→「参数设置」确认日志级别；v2rayNG 与 v2flyNG 可打开侧边菜单中的日志页面，然后重新连接一次。检查时应记录首次出现的错误行，后续的连接关闭、重试失败通常只是连带结果。
报错:x509: certificate has expired or is not yet valid
原因与解法:设备时间不在证书有效期内，或服务器证书确实已经过期——先同步系统日期、时间与时区，再查看证书起止时间。
报错:x509: certificate is valid for example.com, not edge.example.net
原因与解法:客户端校验的 serverName 与证书域名不一致——把 SNI 改为证书覆盖的完整域名，不要直接照抄服务器 IP。
报错:tls: failed to verify certificate
原因与解法:证书链、签发关系或本机信任环境未通过验证——先排除时间问题，再检查服务端是否发送了完整证书链。
报错:remote error: tls: handshake failure
原因与解法:远端在握手阶段主动终止连接——核对 SNI、ALPN、TLS 指纹与传输层配置，并确认连接到的是正确端口。
报错:context deadline exceeded
原因与解法:握手在超时时间内没有完成——先检查网络可达性与端口，再结合前一条日志判断是否属于证书故障。
EOF、connection reset by peer 与超时并不专属于 TLS。它们也可能由服务器进程未监听、传输路径不匹配或中间网络设备提前断开造成。只有日志同时出现 x509、certificate、serverName 或明确的 TLS 握手文字时，才应优先沿证书链排查。- 先找最早出现的错误，不要只复制日志最后一行。
- 记录节点地址、端口、传输方式、TLS 开关与 SNI，但不要公开分享订阅链接。
- 同一节点连续测试两次即可，频繁重连会让日志被重复信息淹没。
- 若多个节点同时在同一设备报证书时间错误，应先检查设备时钟。
系统时间与时区是第一检查项
证书包含“开始生效”和“到期”两个时间点。设备会用本地系统时钟判断当前时刻是否落在有效区间内。日期正确但时区错误、休眠后时钟漂移、虚拟机未同步宿主机时间，都可能触发
not yet valid 或 expired。排查时不能只看任务栏显示的小时与分钟，还要核对年份、月份、日期和时区。443
常见 TLS 服务端口
5 分钟
建议触发校时排查的偏差
TLS 1.2
常见兼容版本
TLS 1.3
常见现代版本
-
核对日期
确认年份、月份与日期均正确。若设备刚从长时间休眠恢复，先等待系统完成网络校时。 -
核对时区
Windows 打开「设置」→「时间和语言」→「日期和时间」，确认时区与当前位置一致，并启用自动设置时间。 -
立即同步
在同一页面点击“立即同步”。安卓设备进入系统「设置」→「系统」→「日期和时间」，开启自动设置时间与自动设置时区。 -
重启内核
停止当前连接，退出客户端内核后重新启动，再对原节点进行一次延迟测试和实际网页访问。
Windows 还可以在管理员终端中查询时间服务状态并发起同步。Linux 可用
timedatectl 检查本地时间、UTC 时间、时区和 NTP 状态。命令返回成功后，应重新启动 V2Ray 或 Xray 内核，避免旧连接继续沿用先前的握手状态。w32tm /query /status
w32tm /resync
timedatectl status
sudo timedatectl set-ntp true核对节点地址、SNI 与证书域名
节点“地址”和 TLS 的
serverName 承担不同职责。地址用于 DNS 解析并建立网络连接；serverName 会放入 TLS ClientHello 的 SNI 扩展，同时通常作为证书域名校验目标。服务器地址可以是 IP 或接入域名，但 SNI 应与服务端证书覆盖的域名一致。例如，客户端连接地址为
203.0.113.20，证书只覆盖 edge.example.net，则地址可以保留为 IP，SNI 应填写 edge.example.net。若 SNI 留空，内核可能根据地址推导校验名称；当地址是 IP、证书却只包含域名时，就容易出现“证书对某域名有效，但不适用于当前地址”的错误。| 配置项 | 作用 | 正确核对方式 |
|---|---|---|
| 地址 Address | 决定实际连接的主机 | 确认域名可解析，或 IP 与服务端一致 |
| 端口 Port | 决定连接的监听端口 | 确认服务端确实在该端口提供对应 TLS 入站 |
| SNI / serverName | 选择虚拟主机并参与证书校验 | 填写证书覆盖的完整域名，不附加协议和路径 |
| Host | 供 HTTP、WebSocket 等传输层使用 | 按服务端反向代理规则填写，不自动等同于 SNI |
| ALPN | 协商应用层协议 | 使用服务端要求的值，未明确要求时避免随意覆盖 |
-
打开节点
在 v2rayN 主界面选中目标节点并打开编辑窗口；在 v2rayNG 或 v2flyNG 中点开对应配置的编辑入口。 -
抄录参数
记录地址、端口、传输协议、TLS 开关、SNI、Host、ALPN 和指纹，修改前保留原值以便回退。 -
比对域名
将 SNI 与报错中列出的证书域名逐字比较，特别检查多余空格、中文标点、错误后缀与缺失的子域名。 -
保存复测
保存后重启内核，只测试这一条节点。若错误从域名不匹配变为连接超时，再单独检查地址解析与端口可达性。
结论:连接地址能通，不代表证书名称正确
当 TCP 已连接但 x509 明确报告域名不匹配时，优先修正 SNI；更换本地 SOCKS 或 HTTP 端口不会改变远端证书校验结果。
判断证书过期、证书链缺失与服务端配置错误
系统时间准确、SNI 也与域名一致后，仍然报证书验证失败，就要检查服务器证书本身。常见情况包括证书已经过期、续期后服务进程没有重新加载、新证书部署到了错误的虚拟主机，以及服务端只发送站点证书却遗漏中间证书。
报错:x509: certificate signed by unknown authority
原因与解法:客户端无法建立到受信任根证书的完整链路——服务端应部署完整证书链，本机系统也应保持证书存储正常更新。
报错:x509: certificate has expired
原因与解法:在系统时间准确的前提下，证书到期时间已经过去——续期后需让实际监听 TLS 的服务重新加载证书文件。
报错:tls: bad certificate
原因与解法:远端拒绝了客户端提供的证书或双向认证参数——确认该入站是否启用了客户端证书认证，并使用对应配置。
如果同一域名通过普通浏览器访问也显示证书异常，问题更可能位于服务器证书部署；如果浏览器正常而 V2Ray/Xray 失败，则继续比较连接端口、SNI、ALPN 和传输层。浏览器访问正常只能证明浏览器连接的那个域名与端口可用，不能证明节点配置中的另一端口使用了同一套证书。
- 确认证书的生效时间与到期时间覆盖当前时刻。
- 确认证书主题备用名称包含 SNI 使用的完整域名。
- 确认反向代理或 TLS 终止服务发送完整证书链。
- 确认证书续期后，实际监听进程已经重新加载配置。
- 确认端口 443 或自定义端口没有被另一服务占用。
- 确认订阅更新没有把旧域名、旧端口重新写回客户端。
allowInsecure、指纹与 ALPN 应该怎样设置
allowInsecure 控制客户端是否跳过证书有效性与域名校验。v2rayN、v2rayNG 和 v2flyNG 的界面可能把它显示为“跳过证书验证”或含义相近的开关。正常使用公开信任证书时应保持关闭，让内核继续验证证书链和 serverName。临时开启该选项可以帮助定位问题：如果开启后立即连通，说明网络地址、端口和主要传输路径大概率可达，故障集中在证书有效期、域名匹配或信任链。但这个结果只用于诊断，随后仍应恢复严格校验并修正真正原因。
- allowInsecure:影响证书验证，不负责修复错误 SNI，也不会更新过期证书。
- fingerprint:用于调整 TLS ClientHello 特征，例如配置要求的
chrome；它不等于证书指纹，也不能替代证书链校验。 - ALPN:常见值包括
h2与http/1.1，必须与服务端入口和传输方式兼容。 - TLS 版本:客户端与服务器需要存在共同支持的版本；老旧系统环境可能无法完成现代 TLS 协商。
修改指纹前，应先确认节点提供方或自建服务配置明确要求了什么。把指纹、ALPN、SNI 一次全部改动，会让测试结果失去可比性。正确方法是保留一份原始配置，每次只改一个字段，重启内核并保存对应日志。
测试 1：保持严格证书校验，只修正系统时间
测试 2：保持其他参数不变，只修正 SNI
测试 3：恢复严格校验，只调整服务端要求的指纹
测试 4：核对 ALPN 与传输层后重新连接结论:跳过验证只能用于缩小故障范围
若关闭证书验证后连接恢复，应回到证书有效期、完整链和 SNI 三项继续定位，而不是把临时诊断开关长期留在节点配置中。
按固定顺序复测，避免多项参数互相干扰
完成修改后，应停止旧连接并重启内核。仅在界面中点击保存，有时不会中断已经建立或正在重试的连接。复测时先做一次节点延迟测试，再访问一个普通 HTTPS 页面，最后查看日志是否仍出现相同的第一条错误。
-
同步时间
把系统时间偏差降到正常范围，确认日期、时区和自动校时状态正确。 -
检查地址
确认节点域名可以解析，服务器地址与端口没有复制错误，TLS 服务确实监听在目标端口。 -
修正 SNI
让 serverName 与证书覆盖域名一致，字段中只填写域名，不加入https://、端口或路径。 -
验证证书链
检查有效期、中间证书与实际加载状态；证书续期后确认监听服务使用的是新证书。 -
逐项改参数
按需检查指纹与 ALPN，每轮只修改一项，并保留修改前后的日志结果。 -
恢复严格校验
完成诊断后关闭跳过证书验证选项，重启内核并进行最终连接测试。
若桌面端与安卓端在同一网络、同一节点上同时失败，而两台设备时间均准确，优先检查服务端证书与 SNI；若只有一台设备失败，优先比较该设备的系统时间、客户端配置和系统证书环境。若所有 TLS 节点失败但非 TLS 测试连接正常，则还应检查本机安全软件、网络出口与系统 TLS 环境是否改写了握手链路。