FlClash 节点 Timeout，原来是 Xray 握手兼容问题
内容提要
两台VPS以相同配置部署VLESS+Reality+Vision，DMIT节点在FlClash中持续Timeout。排查发现TCP与TLS握手正常，但REALITY认证失败，原因是新版Xray要求客户端启用X25519MLKEM768密钥交换。在reality-opts下添加support-x25519mlkem768: true后认证成功，作者也更新了安装器模板。
延伸解读
Timeout 不等于网络不通，要看内核日志
文章里 FlClash 界面只显示 Timeout，但实际 TCP 连接、普通 TLS 握手都正常，真正的失败发生在 REALITY 认证阶段。这说明界面上的超时提示可能掩盖具体错误，排查时不能只依赖测速结果，应查看代理内核日志，确认连接卡在哪一步，避免误判为网络或端口问题。
同配置不同结果，版本差异是关键变量
两台 VPS 使用相同安装器部署 VLESS + Reality + Vision，Rack 正常而 DMIT 超时。核对公钥、short-id、servername 等参数均一致后，问题指向 DMIT 上运行的新版 Xray 对 REALITY 客户端握手提出新要求。这提醒读者，配置原理相同不代表实际行为一致，服务端版本升级可能引入客户端兼容性变化。
修复只需客户端加一行，但旧配置不会自动更新
在客户端 reality-opts 下添加 support-x25519mlkem768: true 后认证成功，无需修改公钥、UUID、short-id 或服务端配置。作者虽更新了安装器模板，但已导入 FlClash 的旧配置需要手动补上，且要确认 FlClash 实际使用的配置已同步，避免只改了原始文件而客户端未生效。
用实际请求验证，比只看界面状态可靠
修改配置并重新加载节点后，文章建议用 curl 通过本地代理请求 generate_204 地址，返回 204 才说明请求真正走通了代理。这种方法能验证端到端连通性，比仅看 FlClash 的 Timeout 提示更具体，也呼应了排查思路：把 TCP、TLS、REALITY 认证和实际代理请求分开确认。
Q&A
FlClash 连接 DMIT 节点一直 Timeout，但 Rack 节点正常，可能是什么原因？
可能是新版 Xray 服务端要求客户端启用 X25519MLKEM768 密钥交换，而 FlClash 配置未开启该选项，导致 REALITY 认证失败。在客户端 reality-opts 下添加 support-x25519mlkem768: true 即可解决。
如何判断 FlClash 的 Timeout 是网络不通还是 REALITY 认证失败？
查看 FlClash 内核日志，若出现“REALITY Authentication: false”或“REALITY authentication failed”，则说明 TCP 和 TLS 握手正常，但 REALITY 认证失败；界面上的 Timeout 会隐藏这些细节。
FlClash 配置中 support-x25519mlkem768 应该加在哪里？格式是什么？
在客户端配置的 reality-opts 下添加，与 public-key、short-id 对齐，例如：reality-opts: public-key: "你的原公钥" short-id: "你的原 short-id" support-x25519mlkem768: true。注意缩进。
修改 FlClash 配置后如何验证代理是否生效？
重新加载 FlClash 中的节点配置，然后使用 curl 命令测试：curl --noproxy '' -x http://127.0.0.1:7890 --max-time 10 -sS -o /dev/null -w '%{http_code}\n' https://www.gstatic.com/generate_204，返回 204 表示请求已通过代理成功。
为什么同样的 VLESS+Reality+Vision 配置，Rack 服务器能用而 DMIT 不能用？
因为 DMIT 上运行的是新版 Xray（26.10.21），对 REALITY 客户端的 TLS 握手有新的要求，需要客户端启用 X25519MLKEM768 密钥交换；而 Rack 服务端可以接受原来的握手方式，所以表现不同。
更新 xray-installer 后，已经导入 FlClash 的旧配置会自动加上 support-x25519mlkem768 吗？
不会。更新安装器不会自动修改客户端里的配置，已导入 FlClash 的旧配置需要手动补上 support-x25519mlkem768: true，但无需重新部署服务端。
