适用于 v2rayN 连接普通 TLS 节点时出现证书过期、域名不匹配或未知颁发机构的情况。先区分订阅下载错误与节点握手错误，再按系统时间、服务器名称、服务端证书链的顺序检查；最后说明如何保持 allowInsecure 关闭并验证修复结果。使用 REALITY 的节点应核对对应认证参数，不套用普通证书链排查。
先定位报错来自订阅还是节点连接
看到 TLS 错误，先记录触发动作。点击更新订阅时出现的 HTTPS 证书错误，通常属于订阅地址的连接；选中节点并访问网页时，内核日志中的握手错误才可能属于代理节点。两条连接有不同的目标域名，修改节点的 SNI 不会修复订阅网站的证书。
普通 TLS 代理连接可按这条链路理解。TCP 端口能连接，只能证明有服务响应；它不能证明证书正确、代理认证成功或网页能够打开。VMess、VLESS 是代理协议，TLS 是可搭配的传输安全层，并非每个节点都使用 TLS。
- 记录目标：保留日志里的目标地址、端口、错误时间和完整错误片段；分享前删除订阅令牌、用户标识与密码。
- 核对端口：例如节点使用
443，应测试该端口，而不是把客户端本地监听端口当成远端端口。 - 区分阶段：
connection refused优先检查监听和防火墙；i/o timeout可能发生在连接或握手期间，需结合前后日志判断。 - 缩小变量：固定一个节点和一个测试目标，每次只调整一项，避免同时更换 DNS、传输方式与代理模式。
按报错原文确定检查方向
不同内核与版本可能在错误外层附加连接信息。优先找最内层的 x509 或 tls 原因，不要只根据外层的“连接失败”反复重启客户端。下面的英文片段是常见错误形式，实际日志可能附带证书日期或具体域名。
报错：x509: certificate has expired or is not yet valid
原因：本机时间不在证书有效期内，可能是设备时钟错误，也可能是服务端证书过期。
解法：先同步系统时间，再对照证书的生效与到期时间；确认过期后由服务端续期并重载服务。
报错：x509: certificate signed by unknown authority
原因：无法建立到可信根的证书链，常见于缺少中间证书、自签名证书或信任库异常。
解法：先检查服务端发送的证书链，再检查设备信任库；不要从不明来源安装根证书。
报错：x509: certificate is valid for example.com, not www.example.com
原因：用于校验的服务器名称不在证书允许的域名范围内；这里的域名仅作格式示例。
解法：核对节点提供方给出的 SNI 和证书 SAN，不要随意补上或删掉 www。
报错：remote error: tls: handshake failure
原因：对端终止握手，可能涉及 SNI、TLS 参数、客户端认证要求或服务端策略，并不直接证明证书不可信。
解法：核对连接参数并结合服务端日志定位；单独打开跳过验证通常无法解决对端拒绝握手。
校准系统时间，再判断证书是否过期
TLS 校验比较的是实际时间点。只改任务栏显示的时区，不能保证设备时钟已经正确；反过来，时区显示不同也不必然导致证书失败。休眠恢复、主板电池异常、手动改过日期，都可能让时钟偏离正常值。
-
核对日期
在 Windows 11 打开「设置」→「时间和语言」→「日期和时间」，先检查年、月、日，尤其留意年份是否错误。
-
同步时钟
开启「自动设置时间」，在「其他设置」下点击「立即同步」。如果同步失败，先处理网络或时间服务问题，不要把“已开启自动”当成同步成功。
-
重试连接
回到 v2rayN，重新启用当前节点并发起一次请求，查看新时间戳下的日志，避免拿旧报错判断修复结果。
-
核对有效期
若仍报过期，检查证书的
notBefore与notAfter。设备时间正常但超出证书有效期时，交由服务端维护者更新证书。
安卓设备可在系统设置中搜索「日期和时间」，开启自动设置时间后重试 v2rayNG 或 v2flyNG。不同设备菜单位置不同，重点是确认同步后的实际日期，而不是只切换开关。不要把系统日期倒回证书有效期内作为长期解决方案。
核对 SNI、连接地址与传输 Host
SNI 是 TLS 握手中告知服务器的名称，服务器可据此选择证书。普通 TLS 配置中的 serverName 通常也用于指定证书校验的目标名称。“伪装域名”是一个容易混淆的说法：它可能指 TLS 的 SNI，也可能指 WebSocket 的 Host，修改前应先确认具体字段。
| 字段 | 作用 | 检查重点 |
|---|---|---|
| 服务器地址 | 决定连接的远端主机 | 域名或 IP 是否对应正确入口 |
| 服务器端口 | 决定连接的远端服务 | 与提供方配置一致，例如 443 |
| SNI / serverName | 影响 TLS 名称选择与验证 | 与目标服务及证书 SAN 匹配 |
| WebSocket Host | 影响 HTTP 请求的虚拟主机路由 | 不是普通 TLS 的证书校验开关 |
| WebSocket 路径 | 匹配服务端传输入口 | 路径错误可能表现为 HTTP 状态码错误 |
在 v2rayN 主界面双击目标节点，进入节点编辑窗口，先核对「地址」「端口」，再核对 TLS 区域的 SNI 与跳过证书验证项；具体标签会随界面版本略有变化。不要在「设置」→「参数设置」中修改全局选项来代替核对这个节点的参数。
使用 IP 作为连接地址时，往往仍需填写提供方指定的域名作为 SNI。若直接按 IP 校验证书，证书需要包含对应的 IP 类型 SAN；只包含域名的证书不能自动满足这个要求。通配符也有限制，*.example.com 通常不覆盖 example.com 或 a.b.example.com。
判断：不要把网页域名随手填进 SNI
先取得节点提供方确认的服务器名称，再与证书 SAN 对照。网页能打开不代表同一域名可以作为代理节点的 SNI，HTTP Host 正确也不能替代 TLS 名称校验。
检查完整证书链与服务端实际返回
服务端通常需要发送叶证书和必要的中间证书，根证书通常由客户端信任库提供。只配置叶证书可能在某些环境中可用、换到另一台设备却报未知颁发机构；浏览器可能缓存过中间证书，因此“浏览器打开正常”不能单独证明服务端链完整。
如果维护自己的服务端，可在安装了 OpenSSL 的环境执行以下命令。example.com 是保留的示例域名，执行前将两处名称替换为实际 TLS 域名，将端口替换为实际节点端口。命令检查普通 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)表示在该次测试环境和验证参数下通过；不代表所有设备的信任库都相同。 - 看链缺口：
unable to get local issuer certificate可能来自服务端缺少中间证书，也可能是测试环境缺少所需信任根，需要两端分别确认。 - 看部署位置：如果 TLS 在反向代理或边缘入口终止，应更新实际终止 TLS 的那一层，而不是只替换后端内核的文件。
- 看加载状态：续期后按服务配置要求重载，并重新获取证书；磁盘文件更新不等于正在运行的进程已经使用新证书。
理解 allowInsecure：保持验证，不用开关掩盖故障
allowInsecure 控制是否跳过常规 TLS 证书验证。设为 true 后，连接可能仍有加密，但服务端身份不再得到正常的证书信任链与名称验证保障；这不等于修好了证书，也不能保证连接到预期服务器。
下面只是普通 TLS 出站配置中的 tlsSettings 字段片段，不是可直接导入的完整节点。示例域名需要换成真实服务器名称；通过订阅管理的节点应优先修正来源配置，避免下次更新覆盖本地修改。
{
"tlsSettings": {
"serverName": "example.com",
"allowInsecure": false
}
}- 日常连接：保留
false，修复时钟、名称、证书链或信任库中的实际问题。 - 受控诊断：如确需临时对比，只在已确认入口的测试环境中进行，不传输账号、支付或其他敏感数据，测试后立即恢复验证。
- 判断边界：关闭验证后能连接，只能提示故障可能位于证书验证环节，不能区分是证书过期、名称错误还是链不可信。
- 自签名部署：通过可信渠道分发并配置预期证书或受信任的私有 CA，具体做法取决于内核支持；不要长期以跳过验证代替信任配置。
验收：恢复验证后再测试
将 allowInsecure 保持为 false，重新连接并确认不再出现证书错误，再验证网页连通与预期出口。若只在开启跳过验证时可用，问题尚未修复。
常见追问与修复后的复测
订阅更新时报证书错误，也要改节点 SNI 吗？
不应先改节点。核对订阅地址的域名、设备时间和该 HTTPS 服务的证书。若更新操作明确通过代理，再分别验证代理链路与订阅站点，确认究竟是哪一层失败。
电脑能用，安卓却提示证书不可信，怎么办？
先比较两端的地址、端口、SNI 与证书验证开关，再检查安卓系统时间与系统更新。若参数一致，优先让维护者检查是否缺少中间证书，不要直接给设备安装来历不明的根证书。
REALITY 连接失败，也要补中间证书吗？
不要直接套用普通 TLS 的修复流程。先确认节点安全类型确为 REALITY，再逐项核对服务器名称、公钥、shortId 等提供方要求的参数及内核兼容性；开启 allowInsecure 不能替代这套认证参数。
改完能连接一次，怎样确认已经恢复？
保持证书验证开启，重新启动当前连接并连续发起几次实际网页请求。检查新日志是否还有同类错误，再确认系统代理或 TUN 的生效范围；TCP 延迟有数值不能代替这些验证。
最后保留一份简短记录：触发动作、完整错误类型、修改前后的单项设置、复测时间和结果。若仍失败，把记录与脱敏日志交给服务端维护者，明确要求核查实际入口返回的证书，而不是只描述“节点不能用”。需要复查代理生效步骤时，可参考连接测试说明。