mirror of
https://github.com/MHSanaei/3x-ui.git
synced 2026-10-25 10:05:21 +08:00
feat(sub): make the host "Mihomo X25519" switch drop ML-KEM (#6803)
The per-host Mihomo X25519 switch has been stored since managed hosts landed, but no renderer read it, while every REALITY proxy was forced to support-x25519mlkem768: true. On some networks DPI drops the second segment of an ML-KEM ClientHello and blackholes the server for that client. A host with the switch on now gets support-x25519mlkem768: false and no ML-KEM hint in its vless link; switches saved while they had no effect are cleared once, so upgrading does not silently change existing subscriptions. A REALITY host's fingerprint now reaches the Clash and JSON outputs, and every host endpoint gets its own deep copy of the stream, so one host's blank SNI, fingerprint, Host header or path no longer inherits another host's value.
This commit is contained in:
@@ -131,9 +131,11 @@ vless://<uuid>@<server>:443?security=reality&pbk=<public-key>&sid=<short-id>&sni
|
||||
with Mihomo's uTLS v1.8.7); enabling the flag cannot upgrade an old fingerprint.
|
||||
Raw `vless://` links carry the equivalent `support-x25519mlkem768=true` hint;
|
||||
clients that support this URI extension, including current Mihomo builds, apply
|
||||
it on import. Very old REALITY servers that reject ML-KEM require a per-node
|
||||
client override setting this option to `false`, or a server upgrade. Clearing
|
||||
the version limit alone does not fix the handshake.
|
||||
it on import. Servers on Xray-core older than 26.9.8 accept a plain `X25519`
|
||||
hello, and very old ones reject ML-KEM outright. For those, or where a network
|
||||
drops the larger ML-KEM ClientHello, enable **Mihomo X25519** on a Host: its
|
||||
Clash proxy gets `support-x25519mlkem768: false` and its `vless://` link drops
|
||||
the hint. Clearing the version limit alone does not fix the handshake.
|
||||
|
||||
</Callout>
|
||||
|
||||
|
||||
@@ -140,9 +140,15 @@ vless://<uuid>@<server>:443?security=reality&pbk=<public-key>&sid=<short-id>&sni
|
||||
راهنمای معادل
|
||||
`support-x25519mlkem768=true`
|
||||
را منتقل میکند؛ کلاینتهایی که این افزونهٔ URI را پشتیبانی میکنند، از جمله نسخههای فعلی Mihomo، آن را هنگام ورود اعمال میکنند.
|
||||
برای سرورهای بسیار قدیمی که ML-KEM را رد میکنند، گزینه را برای همان گره در کلاینت روی
|
||||
`false`
|
||||
بگذارید یا سرور را ارتقا دهید. حذف محدودیت نسخه بهتنهایی دستدهی را اصلاح نمیکند.
|
||||
سرورهای Xray-core قدیمیتر از 26.9.8 دستدهی سادهٔ
|
||||
`X25519`
|
||||
را میپذیرند و سرورهای بسیار قدیمی ML-KEM را رد میکنند. برای آنها، یا اگر شبکه ClientHello بزرگتر ML-KEM را حذف میکند، گزینهٔ
|
||||
**Mihomo X25519**
|
||||
را در میزبان (Host) فعال کنید: پروکسی Clash آن مقدار
|
||||
`support-x25519mlkem768: false`
|
||||
را میگیرد و لینک
|
||||
`vless://`
|
||||
آن راهنما را ندارد. حذف محدودیت نسخه بهتنهایی دستدهی را اصلاح نمیکند.
|
||||
|
||||
</Callout>
|
||||
|
||||
|
||||
@@ -135,10 +135,12 @@ vless://<uuid>@<server>:443?security=reality&pbk=<public-key>&sid=<short-id>&sni
|
||||
нужен отпечаток с ML-KEM (`chrome` при uTLS v1.8.7 в Mihomo). Сам флаг не
|
||||
обновляет старые отпечатки. Исходные ссылки `vless://` передают эквивалентную
|
||||
подсказку `support-x25519mlkem768=true`; клиенты, поддерживающие это расширение
|
||||
URI, включая актуальные сборки Mihomo, применяют её при импорте. Для очень старых
|
||||
серверов REALITY, отвергающих ML-KEM, задайте `false` для соответствующего узла
|
||||
в клиенте или обновите сервер. Снятие ограничения версии не исправляет это
|
||||
рукопожатие.
|
||||
URI, включая актуальные сборки Mihomo, применяют её при импорте. Серверы на
|
||||
Xray-core ниже 26.9.8 принимают обычный `X25519`, а очень старые отвергают
|
||||
ML-KEM. Для них, а также если сеть отбрасывает крупный ClientHello с ML-KEM,
|
||||
включите **Mihomo X25519** в хосте: его прокси в Clash получит
|
||||
`support-x25519mlkem768: false`, а ссылка `vless://` — без подсказки. Снятие
|
||||
ограничения версии не исправляет это рукопожатие.
|
||||
|
||||
</Callout>
|
||||
|
||||
|
||||
@@ -106,7 +106,7 @@ vless://<uuid>@<server>:443?security=reality&pbk=<public-key>&sid=<short-id>&sni
|
||||
- **私钥泄露。** 永远只把**公钥**分发给客户端。
|
||||
- **流控设置错误。** REALITY + XTLS-Vision 要求在入站的客户端条目和分享链接上都设置 `flow = xtls-rprx-vision`。
|
||||
- **客户端版本限制。** Xray-core v26.9.8+ 在**最小客户端版本**留空时不再设置默认下限,但已明确保存的限制仍生效。较早的内核可能使用内置下限(如 `26.3.27`),导致第三方客户端即使密钥正确也被拒绝。修改前先核对运行中的内核版本;降低限制也会放行较旧的指纹。
|
||||
- **Mihomo 与 ML-KEM。** Xray-core v26.9.8+ 还独立要求 `X25519MLKEM768` key share 位于可选的 `X25519` 之前。Clash/Mihomo YAML 订阅会为 REALITY 节点(含外部链接)启用 `reality-opts.support-x25519mlkem768`,未设置指纹时使用 `chrome`。明确选择的指纹会保留,必须选择支持 ML-KEM 的指纹(Mihomo 使用 uTLS v1.8.7 时可选 `chrome`);开关无法让旧指纹获得新能力。原始 `vless://` 链接会携带等效的 `support-x25519mlkem768=true` 提示;支持此 URI 扩展的客户端(包括当前 Mihomo 版本)会在导入时应用它。对拒绝 ML-KEM 的很旧的 REALITY 服务端,需在客户端按节点将此项覆写为 `false`,或升级服务端。仅清空版本限制无法解决握手问题。
|
||||
- **Mihomo 与 ML-KEM。** Xray-core v26.9.8+ 还独立要求 `X25519MLKEM768` key share 位于可选的 `X25519` 之前。Clash/Mihomo YAML 订阅会为 REALITY 节点(含外部链接)启用 `reality-opts.support-x25519mlkem768`,未设置指纹时使用 `chrome`。明确选择的指纹会保留,必须选择支持 ML-KEM 的指纹(Mihomo 使用 uTLS v1.8.7 时可选 `chrome`);开关无法让旧指纹获得新能力。原始 `vless://` 链接会携带等效的 `support-x25519mlkem768=true` 提示;支持此 URI 扩展的客户端(包括当前 Mihomo 版本)会在导入时应用它。Xray-core 26.9.8 以下的服务端接受普通 `X25519` 握手,很旧的服务端则会拒绝 ML-KEM。对这些服务端,或网络会丢弃较大的 ML-KEM ClientHello 时,可在主机(Host)上启用 **Mihomo X25519**:该主机的 Clash 代理会得到 `support-x25519mlkem768: false`,`vless://` 链接也不再携带该提示。仅清空版本限制无法解决握手问题。
|
||||
|
||||
</Callout>
|
||||
|
||||
|
||||
Reference in New Issue
Block a user