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 导入机场订阅、处理格式不匹配与高频报错。
如果你的机场长期不修这类问题、客服还甩锅,是时候换一个运维靠谱的了。这份长期更新的清单按性价比、稳定性和解锁能力筛选,附速查表与分项简评。