Xray 节点突然全连不上？是 allowInsecure 被移除了——自查与三条迁移方案
如果你在 6 月初突然发现：昨天还好好的节点，今天一个都连不上，客户端日志里反复刷一句看不懂的 allowInsecure has been removed——先别急着骂机场跑路，也别以为是墙又升级了。
这其实是 Xray 内核自己把一个叫 allowInsecure 的开关删掉了。换句话说，是"内核变严了"，不是"线路被封了"。这篇把来龙去脉、怎么自查、怎么修，一次讲清。
30秒先看完
- 不是被墙：Xray-core 出于安全，约从 v26.1.31 起，配置里只要含
allowInsecure就直接报错拒绝启动；北京时间 2026-06-01 08:00（UTC 6-01 00:00）旧配置彻底失效——这就是 6 月初集中爆发的原因。 - 谁中招：只有传统 TLS 节点 + 靠
allowInsecure跳过证书校验（自签证书、SNI/域名不匹配）的才会挂。VLESS + Reality 完全不受影响；mihomo、sing-box 是独立内核，也不受影响。 - 怎么修：受信证书节点删掉这行就好；自签节点改填
pinnedPeerCertSha256证书指纹或换 Reality；机场用户最省心的办法是等机场修服务端，急用就临时升级客户端或降级内核。
一、先别慌：这不是被墙，是内核的"安全收紧"
allowInsecure: true 的作用，是让客户端完全跳过对服务器证书的校验——证书是不是自签的、域名对不对、过没过期，统统不管，连上就行。
它很方便，但代价是：这等于把自己暴露在中间人攻击（MITM）下，谁劫持了你的流量都能伪装成服务器。Xray 作者认为这削弱了 TLS 本该有的安全，于是决定把它彻底删掉（相关 issue 以 not planned 关闭，维护者明确不回退）。
整个过程是分阶段的，看这条时间线就懂为什么是"6 月初"集中爆发：
| 版本 | 时间 | 发生了什么 |
|---|---|---|
| v26.1.23 | 2026-01-23 | 引入新字段 pinnedPeerCertSha256；allowInsecure 仅弹废弃告警，仍能用 |
| 约 v26.1.31 | 2026-01 月底 | allowInsecure 从"告警"升级为硬报错：含此字段即拒绝构建 TLS 配置 |
| v26.2.6 | 2026-02-06 | 迁移说明里写明：UTC 2026-06-01 00:00 延时自动禁用 |
| —— | 北京时间 2026-06-01 08:00 | 旧配置彻底失效，大量节点同日集体连不上 |
所以如果你的客户端是这段时间里自动更新了内核（v2rayN、passwall 等），又恰好用着老配置，6 月初"全军覆没"就不奇怪了。
一招验证"不是被墙"
把内核降级回移除前的版本，节点立刻能连——能降级恢复，就说明问题出在内核而不是线路。被墙是不会因为你换个客户端版本就好的。
二、你是不是中招了：一眼自查
看报错
中招的客户端日志/弹窗里，会有这么一句（逐字）：
The feature "allowInsecure" has been removed and migrated to "pinnedPeerCertSha256".
Please update your config(s) according to release note and documentation.注意别认错
这句本身不含任何日期。如果你看到的是带 after 2026-06-01 字样的提示，那是更早"告警阶段"的文案，两者别混。认准 has been removed 这句就对了。
看配置里有没有这几种写法
在你的订阅或配置里搜一下，三种格式对应三种写法：
# 1) Xray JSON（v2rayN 等）：tlsSettings 里
"allowInsecure": true
# 2) VLESS 分享链接：查询参数（不同客户端写法不统一，两种都搜）
…&allowInsecure=1… 或 …&insecure=1…
# 3) Clash / mihomo 的 YAML
skip-cert-verify: true小技巧
本地配置目录直接 grep -r "allowInsecure" 就能定位。但找到它不等于一定会断——只有这个节点确实靠它跳过校验（自签 / SNI 不匹配）才会失效；服务端用的是受信证书的话，删掉这行照样能连。
谁受影响、谁不受影响
| 你的节点 / 内核 | 受影响吗 | 说明 |
|---|---|---|
| VLESS + Reality | ❌ 不受影响 | Reality 不依赖传统证书链，天生与 allowInsecure 无关 |
| TLS + 受信证书（Let's Encrypt 等） | ❌ 删掉即可 | 证书本就过校验，去掉 allowInsecure 不影响连接 |
| TLS + 自签 / SNI 不匹配 / 伪造 SNI | ✅ 会断 | 原本只能靠跳过校验硬连，现在内核不认了 |
| mihomo / Clash.Meta | ❌ 不受影响 | 独立 Go 内核，skip-cert-verify 仍支持 |
| sing-box | ❌ 不受影响 | 独立内核，tls.insecure 仍支持 |
一句话：只有"Xray 内核 + 传统 TLS + 跳过校验"这一类组合会中招，Reality 用户和换了别的内核的用户基本可以划走了。
三、三条迁移方案，对号入座
你大概率改不了服务端，所以顺序是：
- 先等一下：正规机场多半会自己把节点换成受信证书或下发新订阅。重新更新一次订阅，很多时候问题就没了。
- 还不行就联系机场客服，问一句"是不是 allowInsecure 被移除了、有没有更新好的订阅"。
- 真的急着用 → 看「机场用户 · 急用」那条临时救急。
如果一个机场长期不修、客服还甩锅给你，那它的运维水平本身就值得你重新考虑——这也是换个靠谱机场的信号。
最省事的一档：
- 给你的域名签一张正规证书（Let's Encrypt 免费），服务端 TLS 用它。
- 客户端配置里删掉
allowInsecure字段（或取消 UI 上的 "Allow Insecure" 勾选）。 - 证书本就受信，校验通过，直接恢复。
如果你坚持用自签证书或私有 CA，用证书指纹钉扎替代跳过校验——客户端只信任这一张证书：
"streamSettings": {
"security": "tls",
"tlsSettings": {
"pinnedPeerCertSha256": "证书的 SHA-256 指纹"
}
}取指纹（去掉冒号后填入，多个用逗号分隔、命中任一即通过）：
openssl x509 -in cert.crt -noout -fingerprint -sha256⚠️ 字段名别写错：现行唯一替代是
pinnedPeerCertSha256（C和Sha256大写、单数）。老教程里的pinnedPeerCertificateChainSha256、pinnedPeerCertificatePublicKeySha256已被一并移除，别再抄。它取的是整张证书的 SHA-256（和 Chrome 证书查看器、crt.sh 显示的指纹一致），不是公钥、不是证书链。
懒得再跟证书较劲，又是自建，最干净的路子是改用 VLESS + Reality：不需要任何证书，自然就没有"跳过校验"这回事，抗封锁也更强。代价是服务端要重新配置，不是客户端改一行能搞定的。想了解它和其它协议怎么选，见文末的协议横评。
四、实在急着用：两个临时救急
这两招都是"过渡"，不是"根治"
能修服务端 / 换 Reality 就别长期依赖下面这两招——它们要么有时限、要么放弃了安全修复。
- 升级到兼容的客户端：据官方迁移说明，v2rayN 在 7.22.x（约 7.22.5）提供了临时兼容（需全新下载覆盖安装，不能在旧版上原地升级）；v2rayNG 也有对应版本提供类似支持。但官方称这套临时兼容会在 2026 年 8 月前后下线，到时还得回到正规迁移。
- 临时降级内核：把 Xray-core 降回移除前的版本能立刻恢复。但你同时也放弃了这次的安全收紧，只建议拿来救急、顺便验证"不是被墙"，别长期用。
五、几个常见误区
别踩这些坑
- "是不是机场跑路 / 被墙了？" —— 都不是。报这个错就是内核移除了
allowInsecure，降级即恢复。 - "我用 Reality 也得改？" —— 不用。Reality 不涉及传统证书校验，不受影响。
- 把
verifyPeerCertByName当成替代 —— 错。跳过校验的替代是pinnedPeerCertSha256；verifyPeerCertByName是"按域名校验"的另一个东西，语义不同。 - 把两个日期搞混 —— 北京时间 6-01 08:00 是内核侧旧配置硬失效；8 月那条是 v2rayN/NG 客户端临时兼容的下线线，不是一回事。
- 抄老字段名 ——
pinnedPeerCertificateChainSha256/…PublicKeySha256已删，现在只有pinnedPeerCertSha256。
小结
- 6 月初一批节点集体连不上、报
allowInsecure has been removed，是 Xray 内核出于安全把跳过证书校验的开关删了，不是被墙、也多半不是机场跑路。 - 先自查：报错认准
has been removed；配置里搜allowInsecure/insecure=1/skip-cert-verify；Reality 和 mihomo / sing-box 用户基本无事。 - 再对症：受信证书删字段、自签换
pinnedPeerCertSha256指纹或上 Reality、机场用户优先等服务端更新订阅，急用再临时升级客户端 / 降级内核。 - 长期看，Reality 是绕开这类"证书麻烦"最干净的选择，选机场或自建时优先考虑支持 Reality 的方案。
免责声明
本文仅作技术原理与故障排查的科普整理，所涉版本号、字段语法与时间点以 Xray-core 官方 release note 与文档为准（部分客户端版本细节随更新可能变动）。请在遵守当地法律法规的前提下，合理使用相关网络工具。
不想再跟证书较劲？这篇讲清各主流协议的抗封锁能力、速度与客户端支持，帮你理解为什么 Reality 能绕开 allowInsecure 这类证书麻烦，以及什么场景该用哪种协议。
想换一个不受 Xray 内核改动影响、又支持新协议的现代客户端？这篇手把手教你用 sing-box 导入机场订阅、处理格式不匹配与高频报错。
如果你的机场长期不修这类问题、客服还甩锅，是时候换一个运维靠谱的了。这份长期更新的清单按性价比、稳定性和解锁能力筛选，附速查表与分项简评。