节点一夜全断，不一定是被墙：Xray 升级后连不上怎么分清、怎么修
不翻车编辑部 · 更新于
先说结论：10 月底那一周，不少人的自建节点突然全连不上，一部分是真被墙了，另一部分是 Xray 升级出的问题，两种情况看起来一模一样。Xray 从 9 月 8 日那一版开始，REALITY 服务端不再接受 edge、ios、qq、random 这几种指纹；10 月 21 日那一版开始，目标网站的握手回应太简短，每条连接都会失败。维护者说第一条是有意为之，两个问题都标了“不打算修”。分清的办法看三样：客户端报错的快慢、服务器日志里有没有你的连接、国内测端口通不通。升级出的问题改指纹或换目标网站就能修好，别长期停在降级的旧版本上。
文中的版本号和 issue 状态，2026 年 11 月 2 日在 GitHub 上核对过：Xray 最新是 v26.10.31（REALITY 部分和 v26.10.21 一样），3x-ui 最新是 v3.11.0，自带 Xray v26.10.21。复现用的是一台美国的测试服务器，原始记录写清了版本和参数，截图里的客户端 IP 地址只留了前三段。
同一周里的两种“连不上”
10 月 25 日，3x-ui 发布了 v3.11.0，发布说明第一行就写着带上 Xray-core v26.10.21。新装或者更新面板的人，拿到的都是这一版。
两天后，3x-ui 的问题区出现了 #6983：楼主三台节点同一晚断了，重装系统、重装新版都没用，后来照 YouTube 上的说法把 Xray 降级，马上连上了。
同一天，另一个帖子 #6980 的标题是“有出现被墙了吗”。10 月 27 日到 31 日，陆续有 7 个人回复，有人说被墙了 2 台，有人说这几天连着被封了两个 IP，好几个人用的是 VLESS + REALITY。
两件事挤在同一周，碰到节点断了，大多数人第一反应都是被墙。被墙要换 IP 地址，升级故障改一个选项就好。搞反了，要么白花钱换服务器，要么一直开着有漏洞的旧版本。
改动一：服务端不再接受 edge、ios、qq、random 指纹
指纹，就是客户端连服务器时发出去的那段“自我介绍”：里面带了哪些加密方式、按什么顺序排，看得出它像哪个浏览器。v2rayN、v2rayNG 这类客户端里可以选让它装成 chrome、firefox、safari、edge，或者 ios。
从 9 月 8 日那一版开始，REALITY 服务端要求这段自我介绍里必须带上一种新的密钥交换方式 X25519MLKEM768（用来防以后的量子计算机破解）。edge、ios、qq、random 发出来的自我介绍里没有它，服务端就把这条连接当成外人，转给目标网站处理。客户端拿到的是目标网站的真证书，日志里就是这一句：
REALITY: received real certificate (potential MITM or redirection)10 月 26 日，有人在 Xray 问题区报告了这件事（#7259）：服务端从 v26.7.28 升级以后，选 edge 的客户端就连不上，退回旧版又好了。
维护者的第一句回复是“so use chrome instead”，同时把 issue 关了，标的是不打算修。报告的人是俄罗斯用户，他说在俄罗斯 edge 反而最好用，chrome 最容易被针对。维护者接着解释：这是有意为之，只是更新说明一直没人写；原因是有些客户端发出的指纹装成新版 Chrome，却去掉了这段新的密钥交换，这样的请求本身就有特征。
改动二：目标网站回应太简短，每条连接都失败
REALITY 的做法，是让你的服务器假装成一个真网站，握手时照着那个网站的回应来演。10 月 21 日那一版，Xray 在自己的回应里多加了 4 个字节（确认域名用的）。如果目标网站本身的回应很简短，既不确认域名、也不回 ALPN（告诉对方用哪种网页协议），长度就对不上，每一条连接都失败。打开 show 以后，服务端日志是这样：
hs.handshake() err: payload[0]: 8, padding: -4
这种网站有多少：issue 里有人拿全球访问量前 3000 的网站逐个握手，31 个是空回应，大约 1%。我们 11 月 2 日在测试服务器上用同样的办法重扫了一遍前 3000 名，结果也是 31 个，里面有 agoda.com、wix.com、dailymotion.com、ieee.org、purdue.edu 这些常见网站。
维护者的回复是：有必要再说，而且不支持 ALPN 的目标本身就不鼓励用。这个 issue 也被关了，同样标的不打算修。
还有一种：客户端太旧，或者不是 Xray 内核
#6983 的楼主后来补充，他用的是 v2rayN 7.10.5。项目的自动回复判断：老客户端配新服务端，新服务端不认，该升级的是客户端。
Clash 系的客户端（Clash Verge Rev、FlClash 这些用 mihomo 内核的）默认也不带那段新的密钥交换，要在节点配置的 reality-opts 里手动加一行：
reality-opts:
public-key: 你的公钥
short-id: 你的 short id
support-x25519mlkem768: true用本站分流规则工具转换的订阅，这一行已经默认加好了。sing-box 内核的客户端（测的是 1.14.4）连新版服务端会报 reality verification failed。
在测试服务器上复现了一遍
服务器在美国，服务端装 Xray v26.10.31，客户端也是 v26.10.31，VLESS + REALITY + Vision，同一个节点挨个换指纹，经代理访问 https://www.google.com/generate_204，返回 204 算连通。北京时间 11 月 3 日早上测的。
| 指纹 | 服务端 v26.10.31 | 服务端换回 v26.7.28 |
|---|---|---|
| chrome | 连通，0.10 秒 | 连通 |
| firefox | 连通，0.08 秒 | 未测 |
| safari | 连通，0.09 秒 | 未测 |
| edge | 失败，2.19 秒，received real certificate | 连通，0.06 秒 |
| ios | 失败，2.23 秒 | 连通，0.08 秒 |
| 失败，2.17 秒 | 连通，0.07 秒 | |
| random | 失败，2.15 秒 | 连通，0.06 秒 |
| randomized | 4 次连通 1 次 | 未测（测 1 次失败） |
服务端换回 7 月 28 日那一版，配置一个字没改，edge、ios、qq、random 全通了。这就是“降级就好”的来由。
目标网站换成 agoda.com（握手回应里什么都不带），客户端用 chrome：
| 服务端 | 结果 |
|---|---|
| v26.10.31 | 失败，客户端日志 EOF；服务端日志 padding: -4 |
| v26.10.21 | 失败，同上 |
| v26.7.28 | 连通 |
Clash 内核（mihomo v1.19.33）指纹选 chrome：不加 support-x25519mlkem768: true 失败，日志里是 REALITY Authentication: false；加上就通了。加上这一行但指纹改成 edge，照样失败。
另外两点：用 v25.3.6 这种旧版 Xray 当客户端，连 v26.10.31 和 v26.7.28 都失败，降级救不回来；sing-box 1.14.4 连这两个版本也都失败。
三样东西，分清是升级故障还是被墙
1. 客户端报错的快慢和内容
升级出的问题失败得很快，两三秒就报错，写着 received real certificate、EOF 或者认证失败。这说明连接进了服务器，服务器也回了话，路是通的。
被墙是另一种样子。我们在测试服务器上用防火墙把客户端的包全部丢弃，模拟一次被墙：客户端等了 25 秒，一点回应都没有，最后超时。
2. 服务器日志里有没有你这次连接
3x-ui 默认的 Xray 日志级别是 warning，被拒的连接不会记下来。在面板「Xray 配置 → 日志」里把日志级别改成 info，保存重启后再连一次。
日志里出现这一行，后面跟着你的 IP 地址，就说明连接进了服务器，被拒是因为认证没通过或者握手没完成：
[Info] REALITY: processed invalid connection from 136.52.144.***:58600: authentication failed or validation criteria not met模拟被墙的那 25 秒里，服务器日志一条记录都没有，因为包根本没进来。查完记得把日志级别改回 warning，日志太多会拖慢服务器。
3. 在国内测服务器的端口
用国内能测 TCP 端口的网站，电信、联通、移动三家都测一下。测试服务器的这个端口，Globalping 的公开探针测出来是：电信北京、联通武汉、移动南宁都能连上，丢包 0；同一时间 edge 照样连不上，说明问题不在墙。
被墙的典型样子是国外能连上，国内三家都连不上。光是一个端口不通，换个端口就行；整个 IP 地址都不通，就只能换 IP 地址。
还有一点：3x-ui 面板不会自己偷偷升级 Xray。节点突然断了，先回想这几天有没有点过更新、重装过系统。
修法：按报错对号入座
- received real certificate（收到真实证书）：把客户端指纹改成 chrome，firefox、safari 也可以。3x-ui 入站「安全 → Reality」里的 uTLS 也改成 chrome，客户端更新一次订阅。
- padding: -4：换一个目标网站。可以先在本站 REALITY 目标网站检测里查，“支持 H2”一项写着“ALPN 协商到 h2”的就行。目标网站怎么选，另见REALITY 目标网站和 SNI 怎么填。
- 客户端太旧：v2rayN、v2rayNG 升级成新版；Clash 系客户端在
reality-opts里加support-x25519mlkem768: true。
都改好以后，再把服务端 Xray 升级成最新版。
降级的代价
降级能救急，但至少有三条代价。
第一，Xray v26.10.31 之前的每一版都默认打开 MPTCP。内核还没修的服务器，降级就等于把 Linux 内核 MPTCP 漏洞那个口子重新打开。
第二，v26.10.21 本身是一次紧急更新：印度一家证书机构有 8 张中间证书的私钥太简单，被人算了出来。这一版用 Go 1.27.3 编译，系统证书库没更新也能把问题证书过滤掉。退回 7 月的 v26.7.28（我们看到它是 go1.26.5 编译的），就没有这层保护；退回 v26.10.10、v26.10.17 这两个撤版的版本，内置的根证书名单里还带着那几张证书。
第三，问题没有解决，下次升级还会断。
这套办法的局限
- 复现只用了一台美国服务器、一个目标网站组合，没有测各家手机客户端（小火箭、v2rayNG 等）在新服务端上的表现，以你自己测出来的为准。
- “被墙”那一段是用防火墙模拟的，真实封锁可能是丢包、重置连接或者只封某些时段，表现不完全一样。
- 两个 issue 都标了不打算修，但以后的版本可能改主意，升级前看一眼发布说明。
常见问题
3x-ui 升级以后节点全连不上，是被墙了吗
不一定。先看客户端报错：两三秒就报 received real certificate 或 EOF，是连接进了服务器、被服务端拒了，多半是升级出的问题；一直转圈到超时，服务器日志里一条记录都没有，再按被墙的思路查。
指纹选 edge 是不是更安全
没有依据说哪个更安全。新版服务端已经不接受 edge，选了就连不上。用 chrome、firefox、safari 都可以。
降级 Xray 能连上，就一直用旧版行不行
不建议。旧版默认开 MPTCP，内核没修的服务器有被远程拿下的风险；7 月版也没有 10 月那次问题证书的过滤。改指纹、换目标网站之后，升级成最新版。
Clash Verge 连 REALITY 节点报认证失败怎么办
在节点的 reality-opts 里加 support-x25519mlkem768: true，指纹用 chrome。用本站分流规则工具转换的订阅已经带上了。
目标网站怎么知道回不回 ALPN
在本站 REALITY 目标网站检测里查“支持 H2”那一项；名单外的网站，在服务器上用 openssl s_client -tls1_3 -alpn h2,http/1.1 -servername 域名 -connect 域名:443 看输出里有没有 ALPN protocol: h2。
来源
- 3x-ui issue #6983、#6980；3x-ui v3.11.0 发布说明；3x-ui 默认 Xray 配置
internal/web/service/config.json - Xray-core issue #7259、#7243；v26.10.21、v26.10.31 发布说明
- 测试服务器复现记录（2026-11-03，服务端 Xray v26.10.31 / v26.10.21 / v26.7.28，客户端 Xray v26.10.31 / v25.3.6、mihomo v1.19.33、sing-box 1.14.4）；Globalping 公开探针 TCP 端口测试