适用于 v2rayN、v2rayNG 与 v2flyNG 的普通 TLS 节点排错：先读日志判断连接停在哪一层，再依次核对系统时间、服务器地址、SNI 与证书链。本文给出客户端检查步骤和典型报错对应关系，帮助区分本机配置问题与服务端证书问题，并说明为什么不能把 allowInsecure 当作长期修复方案。
一、TLS 握手失败，先分清连接阶段
图形客户端负责保存节点和生成配置，实际建立连接的是 Xray 或 V2Fly 等内核。v2rayNG 使用 Xray 内核，v2flyNG 使用 V2Fly 内核；v2rayN 的实际内核以当前配置和日志为准。不同内核、版本的日志前缀可能不同，定位时应看错误链末端，而不是只看最外层的“连接失败”。
以启用 TLS 的 VLESS、VMess 或 Trojan 节点为例，通常先解析服务器地址，再连接远端 TCP 端口，随后进行 TLS 握手，成功后才进入后续代理协议交互。协议名称本身不能证明节点启用了普通 TLS，仍需核对安全层设置。REALITY 有自己的参数和验证机制，不应直接套用本文的证书处理方法。
| 日志线索 | 大致阶段 | 优先检查 |
|---|---|---|
no such host | 地址解析 | 服务器地址拼写、DNS 响应 |
connection refused | TCP 连接 | 远端监听端口、防火墙、服务状态 |
x509: | 证书验证 | 设备时间、证书域名、信任链 |
tls: handshake failure | TLS 协商 | SNI、TLS 服务配置、服务端日志 |
EOF 或 i/o timeout | 需结合上下文 | 错误发生在握手前还是握手后 |
例如远端端口配置为 443，却在握手开始前就出现 connection refused，此时修改证书选项没有帮助。443 只是常见端口，不能代替服务方给出的实际端口；本地代理端口也不是这里要填写的远端端口。
二、系统时间与证书有效期：先修正本机时钟
证书包含生效时间与到期时间。客户端会用设备当前时间判断证书是否处于有效期内：日期被重置到过去，可能得到“尚未生效”；日期跳到未来，则可能得到“已经过期”。时间显示应以准确的实际时刻为准，单纯修改时区通常不能修复错误的系统时钟。
-
记录报错
在客户端日志中找到本次连接对应的错误，记录当前时间与证书有效期提示。先停止连续测试，避免旧日志与新日志混在一起。
-
同步时间
Windows 11 打开「设置」→「时间和语言」→「日期和时间」，开启「自动设置时间」，再点「立即同步」。先确认设备具备可用的网络连接。
-
检查安卓
Android 原生界面通常在「设置」→「系统」→「日期和时间」，开启「自动设置时间」。厂商名称不同时，可在设置中搜索“日期和时间”，检查自动时间是否生效。
-
重新连接
返回客户端，重新建立一次连接并查看新日志。若本机时间准确但证书确已过期，应由服务端续期并重新加载证书，而不是继续调整客户端日期。
证书有效期是硬边界，不是“允许偏差五分钟”之类的固定宽限。例如证书在 UTC 00:00 生效，本机实际时钟落后到前一天 23:50，就可能无法通过验证。日志与证书工具可能采用不同的时区显示，比较时应先统一到 UTC 或同一当地时区。
三、服务器地址、SNI 与证书域名分别填什么
服务器地址决定连接去哪里；SNI 是 TLS 握手中向服务端声明的目标主机名，服务端可能据此选择站点和证书。常见内核配置中的 serverName 还用于指定预期验证的服务器名称，因此它不是可以随意填写的备注。
假设服务方明确提供连接地址 edge.example.com、远端端口 443，以及 TLS 名称 tls.example.com，客户端就应按这些独立字段填写。两者不同并不必然是错误，但必须由服务端配置支持；不能从搜索结果随意挑一个域名当作 SNI。
- 服务器地址：填写节点提供的域名或 IP 地址，不加
https://，也不拼接网页路径。 - SNI / serverName：填写服务方指定的 TLS 主机名，通常不包含端口、协议头或斜杠。
- 证书 SAN：证书的主体备用名称必须覆盖预期验证的名称，不能只看证书展示的组织名称。
- WebSocket Host：属于后续 HTTP 请求字段，不等同于 TLS 的 SNI；只改 Host 不能修复证书名称不匹配。
通配符证书也有边界：*.example.com 通常能匹配 node.example.com，不能据此认为它也覆盖 example.com 或 a.node.example.com。如果服务器地址改成 IP，而预期名称没有明确设置，内核可能尝试验证该 IP；只有域名 SAN 的证书就不能满足这种验证。
结论：按服务端参数核对名称，不凭地址猜 SNI
只有连接地址是 IP、证书却签给域名时，尤其要确认服务方指定的 serverName。保留正确连接地址，并设置证书覆盖的预期名称，比开启跳过证书验证更可靠。
四、典型证书报错：按错误原文定位
下面列出日志中常见的错误核心文本。外层可能还有出站名称、连接编号或地址；不要把整条日志的最后一个泛化提示当成唯一原因。证书类错误应优先保留 x509 后面的完整说明，向服务方反馈时再遮盖订阅令牌、用户标识和个人地址。
报错：x509: certificate has expired or is not yet valid
原因：本机时间不准确，或服务器证书确实不在有效期内。解法：先同步设备时间，再对照日志给出的有效期；本机正确时由服务端续期或修正证书部署。
报错：x509: certificate signed by unknown authority
原因：证书链无法连接到客户端信任的根证书，可能是中间证书未发全、自签名证书或本机信任环境异常。解法：让服务方检查完整证书链，同时更新系统信任库；不要安装来源不明的根证书。
报错：x509: certificate is valid for
原因：该错误后续通常列出证书覆盖的名称以及不匹配的目标名称。解法：核对节点的 serverName 与证书 SAN；若服务端因错误 SNI 返回了默认站点证书，也要修正虚拟主机配置。
报错：tls: first record does not look like a TLS handshake
原因：当前端口返回的内容不像 TLS，常见于连接到了明文服务。解法：核对远端端口、安全层和反向代理入口；不要把修改证书验证选项当作端口修复。
报错：remote error: tls: handshake failure
原因：对端拒绝了 TLS 协商，可能涉及 SNI、协议版本或服务端策略，单凭这句不能断定证书过期。解法：恢复服务方提供的 TLS 参数，并结合服务端同一时间的日志继续定位。
如果只有 EOF，还不能得出“证书不可信”的结论。对端提前关闭连接、入口配置不匹配或网络设备中断连接，都可能产生这个结果。先检查是否存在更早的 TLS 细节，再决定是否需要服务方协助。
五、allowInsecure 的作用与风险边界
allowInsecure 在常见普通 TLS 配置中用于控制是否跳过服务器证书验证。它不是“增强兼容性”的通用开关：跳过验证后，即使连接被导向错误服务或受到中间人干预，客户端也可能不再通过常规证书验证拒绝连接。连接有加密，并不代表对端身份已得到可靠确认。
下面只展示内核出站 streamSettings 内的 TLS 字段示意，不是可直接导入的完整节点配置。tls.example.com 是说明用域名，实际值必须使用服务方明确提供的 TLS 名称。GUI 客户端通常会生成这些字段，应优先通过节点编辑界面修改。
{
"security": "tls",
"tlsSettings": {
"serverName": "tls.example.com",
"allowInsecure": false
}
}- 日常连接：保持证书验证开启。界面若使用“跳过证书验证”或“允许不安全连接”之类反向措辞，对应开关应关闭。
- 受控诊断：优先检查证书链与服务端日志。确需短时对照时，只在受控测试环境中进行，期间不传输账号、令牌或其他敏感内容，测试后立即恢复验证。
- 结果解释：跳过后成功，只能说明失败与被跳过的验证有关，不能证明服务器身份正确，也不能证明只存在域名不匹配这一种问题。
- 私有证书环境：应由管理方通过可信渠道配置适合该系统与内核的信任机制，而不是让所有使用者永久跳过验证。
六、v2rayN 与 v2rayNG 的检查顺序
界面文字会随版本变化，排查前先记录客户端版本和实际内核版本。下面按常见节点编辑方式说明：v2rayN 在服务器列表中双击目标节点；v2rayNG 点击目标配置右侧的编辑图标。进入后核对同一节点的地址、端口、安全层、SNI 和证书验证状态，不要把全局设置与单节点设置混淆。
-
固定目标
只选择一个需要排查的节点，记录其备注与来源分组。确认日志对应的是该节点，而不是另一个自动切换的出站。
-
核对入口
在节点编辑页逐项对照服务方参数：服务器地址、远端端口、传输方式，以及安全层是否为 TLS。示例中的 443 不能替代实际配置值。
-
核对名称
检查「SNI」或「serverName」字段；确认没有协议头、端口或首尾空格。若还有 Host 字段，分别按服务方要求填写，不要相互替代。
-
保留验证
关闭「跳过证书验证」或同义选项后保存。返回主界面，重新启动连接；需要时通过客户端提供的重启内核操作加载更改。
-
对照日志
发起一次实际请求，比较修改前后的错误。若 TLS 报错消失，但出现鉴权或传输错误，应转查用户标识、路径和服务端协议参数。
订阅节点还要考虑更新覆盖：直接修改订阅生成的条目，下次更新可能被替换。用于排错时可在客户端支持的情况下复制为独立条目，并注明用途；长期修复应让服务方更正订阅中的参数。不要把导出的完整节点、原生 JSON 或订阅地址公开粘贴到求助页面。
七、常见追问：浏览器正常，客户端为什么仍失败
浏览器打开同一域名正常，节点还是证书报错？
先比较浏览器访问的域名与节点 serverName 是否相同，再核对端口。浏览器和内核的信任来源、证书链构建行为也可能不同；网页正常并不能排除服务端缺少中间证书，应请服务方检查实际 TLS 入口。
改成服务器 IP 后就报证书名称不匹配？
保留服务方允许使用的连接 IP，同时核对是否需要单独填写 TLS 的 serverName。域名证书通常不能用来验证任意 IP；不要仅因连接地址改成 IP，就把 SNI 也一起改成 IP。
时间已经同步，为什么还是提示证书过期？
查看同步后的新日志，核对证书到期时间。若证书确实过期，需要服务端续期、重新加载服务并确认入口正在返回新证书；只在管理面板显示续期成功，不代表运行中的服务已经使用新证书。
开启跳过验证就能用，可以一直开着吗？
不宜作为日常设置。记录现象后恢复验证，继续区分时间错误、名称不匹配和信任链异常。若是服务端部署问题，把准确时间、内核版本及脱敏后的 x509 错误发给服务方处理。
节点用的是 REALITY，也要找证书域名吗？
不要套用普通 TLS 证书排错流程。先确认安全层确为 REALITY，再按服务端参数核对 serverName、公钥、shortId 等字段，并检查客户端与内核支持情况；不要擅自切换为 TLS。
结论：一次只改一项，并保留验证
按“时间 → 入口 → 名称 → 证书链”的顺序处理，每改一项就重新连接并保存新日志。TLS 验证通过后再检查代理协议与路由，能避免把两个阶段的问题混在一起。