适用于已经导入配置、但连接日志出现 TLS 或 x509 错误的用户。先确认错误来自订阅请求还是节点连接,再同步系统时间,核对服务器地址、SNI 与证书域名,最后检查证书链和服务端入口。每次只改一个字段,并保持证书验证开启,便于判断真正生效的修改。
先分清报错位置与握手阶段
“TLS 握手失败”是结果,不是唯一原因。订阅地址使用 HTTPS 时,更新订阅也会进行 TLS 握手;节点启用 TLS 时,代理内核还会与节点服务器握手。前者失败应检查订阅域名与订阅服务,后者失败才需要检查节点的 SNI。不要看到同一个关键词,就把两处配置一起修改。
先停止连接,记录触发报错的动作,再启动连接并发起一次网页请求。v2rayNG 与 v2flyNG 可从主界面侧边菜单进入「日志」查看;v2rayN 可查看主界面的日志区域。界面措辞随版本略有差异,重点是保存错误前后几行、目标域名和端口,而不是只截取“连接失败”。分享日志前隐藏订阅地址、用户标识与凭据。
x509: certificate has expired or is not yet valid
原因:当前设备时间不在证书有效期内,或服务端证书确实已经过期。解法:先同步设备时间,再检查证书的起止日期;时间正确仍报错时,由服务端续期并重新加载证书。
x509: certificate signed by unknown authority
原因:证书链无法连到当前环境信任的根证书,可能缺少中间证书,也可能使用了私有证书。解法:核对服务端完整证书链与设备信任库,不要直接跳过验证。
remote error: tls: handshake failure
原因:远端终止握手,可能涉及 SNI、TLS 参数、客户端证书要求或入口配置。解法:先核对订阅原始参数,再结合服务端日志判断,不能仅凭这一行认定证书过期。
若日志只有 i/o timeout、connection refused 或 EOF,尚不能证明发生了证书验证错误。应先确认服务器地址能否解析、目标端口是否可达,以及该端口是否真正提供 TLS。本文后续步骤针对明确启用普通 TLS 的连接;REALITY 的参数与验证方式另有要求,不应直接套用。
系统时间同步:先排除证书有效期误判
证书包含生效时间与到期时间。设备日期偏到未来,可能把有效证书判为过期;偏到过去,则可能判为尚未生效。只看时钟上的小时和分钟不够,还要核对年份、日期以及自动时间同步是否正常。时区显示不同不必然导致错误,真正参与验证的是系统所表示的实际时间。
-
定位时间设置
Android 进入「设置」→「系统」→「日期和时间」。部分设备位于「更多设置」或「常规管理」,可在设置搜索框搜索「日期和时间」。
-
开启自动同步
开启「自动设置时间」与「自动设置时区」,等待网络校时完成。若日期仍异常,先检查设备网络和系统时间服务,不要用错误日期反复测试节点。
-
核对桌面时间
Windows 进入「设置」→「时间和语言」→「日期和时间」,开启自动设置时间并点击「立即同步」。macOS 进入「系统设置」→「通用」→「日期与时间」,开启自动设置时间和日期。
-
重连留存日志
停止客户端连接后重新启动,再请求同一网页。若仍报有效期错误,记录日志中的当前时间与证书有效期,交由节点维护方核对证书续期状态。
Linux 可用 timedatectl status 查看系统时间与同步状态;使用 systemd 的系统可通过 sudo timedatectl set-ntp true 启用网络校时。该命令不适用于所有发行版,已有其他时间同步服务时应按系统配置处理,不要同时启动互相冲突的校时服务。
SNI、服务器地址与伪装域名的区别
服务器地址决定连接到哪个 IP 或域名,端口决定访问哪个监听入口。SNI 是 TLS 握手中发送的服务器名称,服务端可能依靠它选择证书或后端站点;客户端通常还会使用配置的服务器名称进行证书名称验证。SNI 应填写纯域名,不带 https://、端口或路径。
教程里的“伪装域名”并不总指同一个字段。WebSocket 的 Host、HTTP 请求路径与 TLS 的 SNI 处于不同层。它们可以按服务端设计使用相同域名,也可能不同。不能因为 Host 填了某个域名,就认定证书一定覆盖该域名,更不能把网页路径复制进 SNI。
| 字段 | 实际用途 | 核对重点 |
|---|---|---|
| 服务器地址 | 建立底层网络连接 | 与提供方给出的入口一致,可以是 IP 或域名 |
| 服务器端口 | 选择远端监听服务 | 443 是常见 TLS 端口,但端口数字不能证明服务启用了 TLS |
| SNI / serverName | 发送 TLS 服务器名称,并通常用于名称验证 | 与服务端预期及证书 SAN 覆盖范围一致 |
| Host | 传输层使用 HTTP 时的主机字段 | 按 WebSocket 等传输入口要求填写,不替代 SNI |
| allowInsecure | 控制是否跳过证书验证 | 正常使用保持 false,不能修复证书或域名错误 |
结论:地址是 IP 时,优先核对 SNI
若节点连接到 IP,但证书只覆盖域名,应使用服务端指定、且证书覆盖的域名作为 SNI。不要随意换成知名网站域名,也不要仅为消除报错把服务器地址改成证书域名;那可能连接到完全不同的入口。
名称匹配主要查看证书的 SAN。通配符 *.example.com 通常能匹配 node.example.com,但不能匹配根域名 example.com,也不能匹配 a.node.example.com。这里的域名仅用于说明匹配规则,并非可用节点。
各客户端的 SNI 与证书验证入口
先记下节点原有的地址、端口、传输方式、TLS 类型、SNI 和 Host。订阅生成的节点可能在下次更新时覆盖手工修改,建议先复制为独立测试配置;若界面没有复制入口,可在保存原始参数后手工新建。不同发行版本的字段可能显示为英文或中文,以字段含义为准,不要在全局设置中寻找所有节点的统一 SNI。
-
检查 v2rayNG
在主界面点击目标节点的铅笔编辑按钮,进入配置编辑页。找到 TLS 区域,确认安全类型为
tls,核对「SNI」;将「跳过证书验证」或allowInsecure保持关闭。保存后重新选中该节点并重启连接。 -
检查 v2rayN
在服务器列表双击目标节点,打开服务器编辑窗口。在「传输层安全(TLS)」区域核对 TLS 类型、「SNI」及「跳过证书验证(allowInsecure)」。后者选择
false,保存后重新设为活动服务器并重新连接。 -
检查 v2flyNG
在主界面点击目标配置的编辑按钮,进入节点配置页,在 TLS 相关字段中核对
serverName或 SNI,并将allowInsecure设为关闭。若导入的是自定义 JSON,应在该配置的 TLS 设置中检查,不能假定普通节点表单会覆盖它。 -
对照原始参数
将编辑页内容与提供方的配置说明逐项对照,尤其检查更新订阅后 SNI 是否丢失、TLS 是否误选为其他安全类型。一次只修正一项,再保存、重连并查看新日志。
v2rayNG 使用 Xray 内核,v2flyNG 使用 v2fly 内核。两者的配置支持范围并不完全相同;不能为了测试把包含特定扩展的配置直接互换。对于常规 VMess 或 VLESS 的 TLS 连接,先确认协议及传输方式受当前内核支持,再讨论证书验证问题。用户标识错误通常也不是通过修改 SNI 来解决。
证书链与服务端入口检查
时间与 SNI 正确后,仍出现不受信任错误,应检查服务器发送的证书链。常见情况是只配置了站点证书,遗漏中间证书;也可能续期文件已经更新,但实际处理 TLS 的反向代理尚未重新加载。若前面还有中转或 CDN,应检查客户端实际连到的那一层,而不是只检查源站文件。
- 自建服务:检查实际 TLS 监听进程加载的证书路径、完整证书链与私钥配置,并查看配置重载是否成功。
- 订阅节点:将错误原文、发生时间、节点备注和所用客户端发给维护方;不要发送完整订阅地址或认证凭据。
- 仅一个网络失败:对比另一条可信网络,检查是否有登录门户、DNS 异常或网络设备替换证书,不要随意安装来源不明的根证书。
- 只有旧设备失败:检查系统更新与信任库状态。桌面工具验证成功,并不代表 Android 上的内核一定使用相同的信任环境。
已安装 OpenSSL 的 macOS 或 Linux 环境可用下面命令观察 TLS 证书链及名称验证结果。示例访问的是保留示例域名,不用于验证你的节点;实际排查时,把连接地址、端口和两处域名替换成自己的真实参数。命令会建立连接,但不会验证 VMess、VLESS 认证或后续传输路径。
openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error -showcerts
查看输出中的证书有效期、名称与验证错误。即使显示 Verify return code: 0 (ok),也只说明这次测试环境中的证书验证通过,不能证明代理配置整体可用。若普通 TLS 握手成功但客户端仍失败,应继续检查传输路径、Host、协议认证,以及客户端实际连接的地址是否相同。
allowInsecure 与常见误区
allowInsecure=true 会跳过关键的证书验证,使连接失去可靠的服务器身份核验。它既不会续期证书,也不会补齐证书链,更不会自动修正 SNI。即便开关打开后暂时能连,也只能缩小到验证相关问题,不能据此认定配置已经修复。
关掉证书验证就能连,可以一直开着吗?
不建议。恢复 allowInsecure=false,按时间、名称、证书链顺序排查。自建私有证书环境应按受控方案配置信任或证书固定,并确认当前内核支持,而不是长期跳过身份验证。
SNI 留空,是不是自动使用服务器地址?
部分配置会从地址推导服务器名称,但具体行为取决于内核和配置类型。地址是 IP 时尤其不能依赖这种推导;按提供方要求明确填写证书覆盖的域名,再保存重连。
浏览器打开域名正常,为什么节点还报错?
浏览器可能访问不同端口、不同 IP 或不同入口,信任库也可能不同。先对照节点的连接地址、端口和 SNI;网页可打开只说明该次网页访问成功,不代表节点的 TLS 链路相同。
更新订阅后又恢复原来的错误,怎么办?
比较更新前后的 SNI、TLS 类型和端口。把临时修改保留在独立测试配置中,并向提供方反馈订阅参数错误;不要反复修改后再更新覆盖,也不要把错误归因于路由分流。
节点可以连接,只有更新订阅提示 x509 错误?
检查订阅地址本身的 HTTPS 证书及系统时间。节点编辑页的 SNI 通常不控制订阅请求;若订阅通过代理更新,还需检查代理链路,但不应先改节点的证书验证开关。
修复后的复测顺序
排查结束后,先确认系统时间正常、证书验证开启,再重启连接。不要以延迟测试结果作为唯一依据:不同测试方式覆盖的连接阶段不同,有结果不等于认证、传输与网页请求全部成功。复测应使用同一节点、同一网络和同一目标,减少变量。
- 确认编辑后的节点确实是当前活动配置,旧连接已停止并重新建立。
- 发起一次实际网页请求,检查日志中是否仍有同类 x509 或 TLS 错误。
- 若证书错误已消失而网页仍失败,按新日志检查认证、WebSocket 路径、Host、DNS 与路由分流,不再反复修改 SNI。
- 确认订阅更新不会覆盖修复参数;记录修改项与验证结果,后续出现同类问题时直接对照。
结论:以新日志决定下一步
时间修正后错误转为名称不匹配,就继续核对 SNI;名称错误消失后转为传输失败,就进入传输层排查。沿着最新的具体错误推进,比同时更换 DNS、端口、协议和证书开关更容易定位原因。