排查顺序：先从内核日志区分证书验证失败与普通连接超时，再检查本机时间、SNI、证书链和服务端监听。适合在 v2rayN、v2rayNG 或 v2flyNG 中遇到 TLS 错误的用户；读完可以按报错原文定位配置层级，避免用跳过验证掩盖问题。
先看日志：TLS 握手失败发生在哪一层
连接层级：节点显示超时，并不等于证书出错。一次常见的 TCP + TLS 代理连接，需要先解析服务器地址、建立 TCP 连接，再协商 TLS，最后才进行代理协议认证与数据传输。任何前置步骤失败，都可能在界面上表现为连接不可用。
日志取样：在客户端日志区域找到刚刚一次连接产生的错误，保留时间、错误原文和所用内核名称。优先读取底层原因，不要只看外层的 failed to process outbound traffic。后者通常只是错误包装，无法单独判断是证书、网络还是协议参数的问题。
报错：x509: certificate has expired or is not yet valid
原因与解法：本机时钟落在证书有效期之外，或证书确实过期、尚未生效；先校准系统时间，再检查服务端实际返回的证书起止时间。
报错：x509: certificate signed by unknown authority
原因与解法：证书链无法连接到本机信任的根证书，可能涉及中间证书缺失、自签名证书或连接被拦截；核对证书颁发者及服务端完整证书链。
报错：remote error: tls: handshake failure
原因与解法：对端拒绝了握手，单凭这一行不能确定原因；检查 SNI、TLS 终止位置和服务端日志，再核对协商参数。
超时边界：如果日志只有 dial tcp、i/o timeout 或连接被拒绝，且没有证书错误，应先核对地址、端口与服务端监听。尚未收到服务端证书时，修改证书验证开关不会修复连接。
系统时间不同步：先检查日期，再检查同步状态
有效期判断：证书包含开始时间与到期时间，客户端依据本机时钟判断是否有效。电脑长期关机、虚拟机恢复快照、设备断电后时钟重置，都可能让正常证书看起来尚未生效或已经过期。不要只看任务栏里的小时和分钟，年份与日期同样重要。
- Windows 校时：打开「设置」→「时间和语言」→「日期和时间」，启用「自动设置时间」，核对时区后点击「立即同步」。不同系统版本的按钮位置可能略有变化。
- 同步结果：查看最近一次成功同步时间。需要进一步确认时，在命令提示符中执行下方只读命令，检查时间源及同步状态。
- Android 校时：在系统设置中搜索「日期和时间」，启用自动日期时间与自动时区；具体路径以设备系统为准，然后重新发起连接。
- 复现验证：校时后重新建立连接，比较同一节点的新日志。如果仍提示过期，应让服务端维护者核对证书，而不是继续调整本机日期。
w32tm /query /status
w32tm /query /source时区区别：时区主要影响本地时间的显示，TLS 验证比较的是绝对时间。把时区改成其他地区不是修复证书的办法；目标是让系统实际时刻准确，而不是让钟面看起来接近另一台设备。
SNI 填错：服务器地址、证书域名与 Host 分开核对
字段职责：SNI 是客户端在 TLS 握手中发送的服务器名称，常用于让同一地址上的服务选择对应证书与站点。Xray、V2Ray 的常见 TLS 配置使用 serverName 表达这一设置；客户端界面可能显示为 SNI 或服务器名称。连接地址可以是 IP，但证书身份通常仍需按服务端指定域名验证。
| 字段 | 作用 | 检查重点 |
|---|---|---|
| 服务器地址 | 确定 TCP 连接的目标 | 域名解析或 IP 是否正确，端口是否与服务端一致 |
| SNI / serverName | 参与 TLS 证书选择及名称验证 | 使用服务端指定名称，证书 SAN 必须覆盖待验证名称 |
| WebSocket Host | 在 TLS 之后参与 HTTP 请求路由 | 与反向代理站点配置一致，不能代替 SNI |
| WebSocket path | 匹配服务端 WebSocket 入口 | 路径及大小写以服务端配置为准，不影响证书有效期 |
界面核对：在 v2rayN 中编辑当前节点，检查地址、端口、传输方式和 TLS 设置；在 v2rayNG、v2flyNG 中进入对应节点的编辑界面，核对服务器名称相关字段。不同版本的布局不完全相同，应以字段含义和实际生成的内核配置为准，不要仅凭某个输入框的位置判断。
- 名称格式：SNI 通常填写纯主机名，不带
https://、端口、路径或末尾空格。 - 证书匹配：检查证书的主题备用名称 SAN，不能只看证书列表里显示的简称。通配符通常只匹配一层子域名，不自动覆盖根域名。
- 留空行为：部分配置会从服务器地址推导名称；使用 IP 地址连接时尤其不能依赖猜测，应按服务端说明显式核对。
- 订阅覆盖：手动修正后，下一次订阅更新可能覆盖字段。若导入结果持续错误，应反馈订阅配置来源，而不是反复修改同一节点。
判断：先对证书名称，再对 HTTP 路由
操作顺序：出现名称不匹配时先修正 SNI 与证书的对应关系；TLS 已成功但出现 HTTP 状态错误时，再排查 Host 和路径。只改 Host，不能修复握手阶段的证书名称错误。
证书链与服务端：浏览器能打开不代表内核一定通过
信任链检查：服务端通常需要发送站点证书和必要的中间证书，客户端再把证书链连接到受信任的根证书。浏览器可能缓存中间证书或采用不同的信任机制，因此“浏览器能打开”只能作为线索，不能替代代理内核的验证结果。
- 核对终止位置：确认 TLS 由反向代理、负载均衡入口还是代理内核直接处理。证书应更新在真正处理握手的那一层。
- 核对完整链：检查服务端是否加载完整证书链，证书与私钥是否对应。更新证书后确认配置已重新加载，而不是只替换磁盘文件。
- 核对多个入口：若域名有多个地址或多个入口，逐个检查返回证书。某个入口仍使用旧证书，可能造成间歇性失败。
- 核对本机信任：更新操作系统与客户端到受维护的发行版本，检查是否存在企业网络的 TLS 检查机制。不要为排错随意安装来源不明的根证书。
allowInsecure 误用：跳过验证不是证书修复
开关含义：在常见 TLS 配置中，allowInsecure: true 会跳过通常的证书链与名称验证，使连接不再获得原有的服务器身份保证。它不能修复 TCP 不通、错误端口、服务端拒绝握手或代理认证失败，也不应作为长期可用性的设置。
{
"security": "tls",
"tlsSettings": {
"allowInsecure": false
}
}片段边界：上面只展示常见 streamSettings 内的 TLS 验证开关，不是完整节点配置，也没有包含实际的 serverName、传输层与认证参数。不要用这个片段覆盖现有配置；应在当前节点的 TLS 设置中确认没有启用“允许不安全连接”或“跳过证书验证”。
- 错误消失的含义：跳过验证后错误消失，只能说明问题可能与证书验证有关，不能证明连接到了正确服务端。
- 推荐处理：保持验证开启，修正系统时间、SNI、完整证书链或服务端证书，再重新测试。
- 自签名场景：需要明确设计信任方式，并核对当前内核支持的证书信任配置；不要把关闭验证当作通用替代方案。
处理原则：恢复身份验证后再判定修复完成
验收条件：证书验证保持开启，同一节点重新建立连接不再出现原错误，且目标业务能够正常访问。仅把日志中的证书报错隐藏掉，不算完成修复。
内核与协议边界：普通 TLS、REALITY 不套用同一套参数
协议区分：VMess、VLESS 是代理协议，是否使用 TLS 取决于传输与安全层配置。不能看到 VLESS 就默认一定是普通 TLS，也不能因为界面里有服务器名称字段，就把所有安全层都按证书过期处理。
| 使用场景 | 优先核对 | 避免的误操作 |
|---|---|---|
| v2rayN 桌面配置 | 当前节点调用的实际内核、TLS 字段及底层日志 | 把客户端名称当成内核名称，套用不对应的参数 |
| v2rayNG 的 Xray 配置 | 节点安全层、服务器名称、证书验证状态 | 把普通 TLS 的处理方式直接套到 REALITY |
| v2flyNG 的 v2fly 配置 | 当前内核支持的协议与字段 | 导入依赖 Xray 特有能力的配置后忽略兼容性 |
| Xray 的 REALITY 配置 | 服务端指定的 serverName、公钥及 shortId 等参数 | 用 allowInsecure 替代 REALITY 所需参数检查 |
REALITY 边界：REALITY 使用不同于普通 TLS 证书部署的验证机制，配置必须与服务端成套对应。系统时间依然值得检查，但遇到相关错误时，应先确认安全层类型，再按对应内核要求核对参数，不要要求维护者仅通过更换普通站点证书解决所有问题。
最终复测：每轮只修改一个因素，记录“原始错误—修改项—新日志”。按时间、SNI、证书链、服务端、安全层兼容性的顺序收敛范围；TLS 成功后仍无法访问，再转向代理认证、路由分流和 DNS，而不是继续关闭安全设置。
- 保留基线：记录当前字段与原错误，订阅内容保存在可信位置。
- 单项验证：修正一项后重新连接，确认日志来自本轮测试。
- 恢复设置：撤回临时调试改动，保持证书验证开启。
- 核对持久性：重新启动客户端；如使用订阅，检查下一次更新是否再次覆盖修正。