v2rayN 7.22.7 不是普通功能更新。它在 2026-06-12 发布，github.com 到 2026-07-08 仍把它标成 Latest；7.23.0 之后的 7.23.x 还在 Pre-release 线。要先处理的是 allowInsecure：Xray 将在 2026-08-01 禁用跳过证书验证，v2rayN 也已经移除全局 AllowInsecure。

别等客户端突然连不上再翻配置。现在最小改变量是：保留当前配置备份，找出所有 allowInsecure: true 或 "allowInsecure": true，再把确实需要特殊证书校验的节点改成 pinnedPeerCertSha256 或 verifyPeerCertByName。

7.22.7 现在到底该不该升？

如果你还在 7.22.5，建议全新下载 7.22.7 覆盖更新。Release notes 里专门警告：v7.22.5 临时允许跳过证书验证功能，需要全新下载覆盖更新。这里的关键词是「临时」，不是给旧配置继续长期依赖。

如果你已经在 7.22.7，不要因为看到 7.23.0、7.23.1、7.23.2 就直接把生产目录切到预发布线。Release 页显示 7.23.x 是 Pre-release，7.22.7 仍是 Latest。除非你要单独测试 Windows 进程流量劫持、x86 发布文件、全局分片或 Xray TUN 新能力，否则先在 7.22.7 上处理证书校验。

这次的风险不是版本号落后一位。风险是 Xray-core 到 2026-08-01 后不再接受旧的 allowInsecure 习惯，而你的节点配置还把证书错误当作可以忽略的提示。

allowInsecure 为什么不能继续留着？

allowInsecure 的作用很直白：客户端不验证远端 TLS 证书有效性。xtls.github.io 上的 Xray TLS 文档已经把它标为 deprecated，并建议改用 pinnedPeerCertSha256 手动指定证书。v2rayN 7.22.7 的 Release notes 也把同一件事写成警告。

这不是界面审美问题。证书校验失败时，常见原因有三个：证书名称和 serverName 不一致、自签名证书不在系统根证书里、服务端证书链不完整。allowInsecure 把三种问题都吞掉，所以你看不到真正错在哪。

XTLS/Xray-core Discussion #5859 里有一个典型现场：Hysteria2 + salamander 混淆，自签名证书的名称显示为 localhost，加上 allowInsecure 暂时能用；去掉后出现 tls: failed to verify certificate，再尝试 verifyPeerCertByName 仍可能失败，最后只能讨论怎么拿到 pinnedPeerCertSha256。这类问题不能靠重启客户端解决，不看日志就是玄学。

我的配置里有没有踩到这个雷？

先按文件找，不要在 GUI 里一项项点。v2rayN Wiki 写明，未做界面设置的参数在 v2rayN\guiConfigs\，其中 guiNConfig.json 是 JSON 参数存储文件；修改前要先退出 App，保存后再运行。

看到的信号更可能原因先检查什么
节点之前能连，删除 allowInsecure 后失败证书名称、证书链或自签名证书没有通过校验出站节点的 streamSettings.tlsSettings
日志出现 failed to verify certificateTLS 证书验证失败，不是订阅格式错误serverName、verifyPeerCertByName、证书 SHA-256
GUI 里找不到对应开关参数没有做成界面项，或由订阅导入写入v2rayN\guiConfigs\ 和自定义配置文件
只有 Hysteria2 或特殊 TLS 节点出问题传输层和证书校验组合更复杂network、security、tlsSettings、服务端证书
升到 7.22.7 后全局开关没了Release 已移除全局 AllowInsecure单节点参数，不要找全局补丁

如果你手里只有订阅链接，没有服务端证书信息，也没有服务端管理权限，就不要猜一个指纹写进去。pinnedPeerCertSha256 固定的是远端证书 SHA-256。写错了，连接应该失败；写成别人给的未知值，等于把校验对象交给了别人。

pinnedPeerCertSha256 应该怎么写？

下面是 Xray 出站配置的最小上下文示例。它不是让你照抄地址、端口和 UUID，而是说明：迁移点在 streamSettings.tlsSettings，不要继续保留 "allowInsecure": true。

{
  "outbounds": [
    {
      "tag": "proxy-tls-pinned",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "example.com",
            "port": 443,
            "users": [
              {
                "id": "00000000-0000-0000-0000-000000000000",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "example.com",
          "pinnedPeerCertSha256": "e8e2d387fdbffeb38e9c9065cf30a97ee23c0e3d32ee6f78ffae40966befccc9"
        }
      }
    }
  ]
}

Xray 文档说明，pinnedPeerCertSha256 使用远端服务器证书的 SHA-256 哈希，十六进制编码，不区分大小写；多个值可以用英文逗号连接。文档还给了获取方式：xray tls hash --cert <cert.pem>、openssl x509 -noout -fingerprint -sha256 -in cert.pem，以及 xray tls ping 输出。

这一步的验证方法很简单：删除 allowInsecure 后，启动日志不再出现 failed to verify certificate，并且节点连接失败时不要出现 against pinned 或 against root CAs and verifyPeerCertByName。出现后一类错误，说明你已经进入证书校验问题，别再去改路由规则。

VerifyPeerCertByName 能解决哪些证书名问题？

verifyPeerCertByName 是客户端侧 TLS 参数，用来指定证书验证时使用的名称。它适合 SNI 和证书实际名称不一致的特殊情况。比如连接时的 serverName 为了传输需求写成 A，但证书 Subject/SAN 里真正能匹配的是 B，就可以尝试用它指定 B。

它不是 allowInsecure 的等价替代品。verifyPeerCertByName 仍然要求证书链能被验证，或者和你配置的其他证书校验方式一致。Discussion #5859 里的问题就卡在这里：用户看到证书名称是 localhost，加上 verifyPeerCertByName 后仍报 peer cert invalid。

所以判断顺序是：证书名称不匹配，先看 verifyPeerCertByName；自签名、特殊 CA、证书链不完整，再看 pinnedPeerCertSha256 或修服务端证书。把所有问题都塞回 allowInsecure，8 月后只会变成更难看的日志。

7.22.7 还改了哪些地方？

这次 Release notes 的更新项不少，但普通用户最该先记住的是证书和全局开关变化。其他功能按你是否用得到来排。

更新项Release 里的事实对配置的影响
.NET 10升级至 .NET 10.0桌面运行环境变化，旧系统先看安装包能否正常启动
loong64 deb添加 v2rayN-linux-loong64.deb龙架构 Linux 用户多一个官方包
TUN tag路由规则 inbound 添加 tun tag自定义路由规则可以更细分 TUN 入站
仅检查更新检查更新添加「仅检查」和每 24 小时自动检查提示可以只看版本提示，不直接触发更新动作
SOCKS4/5 分享链接支持导入 SOCKS4/5 分享链接订阅来源里混入 SOCKS 链接时更容易导入
IP 信息列主窗口添加 IP 信息列，需要设置连接信息地址节点列表可显示连接信息，不等于测速结果
VerifyPeerCertByName添加 VerifyPeerCertByName 支持证书名称校验多一个迁移工具
TUN 排除地址为 TUN 添加路由排除地址支持排除局域网、网关或特定地址时更好写
全局开关移除移除全局 AllowInsecure 和 MuxEnabled不要再找全局兜底，改到单节点或协议配置
末端分片添加末端分片支持只在你明确使用分片相关配置时再测试

MuxEnabled 也被从全局移除。这个点容易和证书警告混在一起，但它们不是同一个问题。Mux 影响连接复用；allowInsecure 影响 TLS 证书校验。升级后如果节点慢、断流、握手失败，要先看日志里的关键词，不要把两个全局开关一起补回去。

修改 guiNConfig.json 前要停 App 吗？

要停。v2rayN Wiki 明确写了，修改 guiNConfig.json 前要先退出 App，修改保存后再运行。路径是 v2rayN\guiConfigs\，里面还有 guiNDB.db、pac.txt、Mixin.yaml 和自定义配置文件。不要改 guiNDB.db，那是配置文件等大数据存储数据库。

如果你要做迁移测试，建议复制整个 guiConfigs 目录，再开一个临时目录试。Windows 上可以按这个粒度备份：

v2rayN\
  guiConfigs\
    guiNConfig.json
    pac.txt
    Mixin.yaml
    <GUID>.json

验证时只做一件事：删除一个节点里的 allowInsecure，加入对应的 pinnedPeerCertSha256 或 verifyPeerCertByName，重启 v2rayN，看同一个节点日志。不要同时升级 core、重导订阅、改 TUN、改 DNS。一次改四个变量，最后什么都定位不到。

7.23.x 预发布值得单独测试吗？

可以测，但别和这次证书迁移混在同一轮。7.23.0 Release notes 里新增了 Windows 进程流量劫持实验功能，提示可和系统代理并存，但和 TUN 模式冲突。7.23.1、7.23.2 又继续补 Windows x86、GPG 密钥文件、Hysteria Realm & Gecko、全局分片、Xray TUN 等内容。

这些都是新能力测试，不是 allowInsecure 的逃生按钮。生产目录继续用 7.22.7 Latest，把证书校验迁移做完；想看 7.23.x，就新建目录、导入一份测试配置，只拿一个节点跑。

这篇没有覆盖所有协议的服务端证书生成，也不承诺某个订阅源一定能拿到证书指纹。能确认的是：v2rayN 7.22.7 的 Latest 状态、2026-06-12 发布、Release 警告、Xray 2026-08-01 的 allowInsecure 时间点，以及 pinnedPeerCertSha256 / verifyPeerCertByName 在 TLS 校验里的位置。

相关阅读