Files
3x-ui/docs/content/docs/zh/config/reality.mdx
T
libmur-dev ce221c33d0 fix(sub): carry REALITY ML-KEM hint in VLESS links (#6712)
* fix(sub): carry REALITY ML-KEM hint in VLESS links

Keep raw share links in parity with Clash subscriptions for Xray 26.9.8+. Preserve the URI hint through Go and frontend imports, expose it in the outbound editor, and update the documentation tooling.

* fix(link): accept REALITY ML-KEM boolean aliases

* test(frontend): isolate Happ preset notifications

* fix(link): keep the ML-KEM hint out of Xray REALITY settings

support-x25519mlkem768 is a Mihomo reality-opts option; xray-core's
REALITYConfig (infra/conf/transport_security.go) has no such field and its
JSON loader drops unknown keys silently. The PR also stored it as
realitySettings.supportX25519Mlkem768 in Xray outbounds (form switch, Go and
TS link import, docs outbound builders) and as an inbound settings default
that is stripped before Xray and read by no link generator. The outbound
switch therefore did nothing, and imported links carried a dead key into the
JSON subscription.

The share-link hint itself stays: Go, frontend and docs still emit
support-x25519mlkem768=true on VLESS REALITY links and drop it on a TLS host
override.

---------

Co-authored-by: libmur-dev <333915961+libmur-dev@users.noreply.github.com>
Co-authored-by: MHSanaei <ho3ein.sanaei@gmail.com>
2026-10-02 15:44:41 +02:00

123 lines
5.6 KiB
Plaintext

---
title: REALITY
description: 在 3x-ui 中配合 XTLS-Vision 搭建 VLESS + REALITY 入站——密钥、short ID、SNI、指纹以及常见陷阱。
icon: ShieldCheck
---
**REALITY** 是 Xray 的一种传输安全机制,它将你的代理流量伪装成发往某个真实、热门网站的普通流量。
与传统 TLS 不同,你的服务器**无需拥有自己的证书**——它会借用目标站点(`dest`)的 TLS 握手。
再结合 **XTLS-Vision** 流控,它既快速又能抵抗深度包检测(DPI)。
REALITY 配合 **VLESS**(以及 Trojan)使用,推荐的流控为 `xtls-rprx-vision`。
## 关键设置
当你在某个 VLESS 入站上将安全模式选为 **REALITY** 时,3x-ui 会暴露以下字段:
| 字段 | 含义 |
| ------------------------ | ------------------------------------------------------------------ |
| **Dest (target)** | 要伪装成的真实 TLS 站点,例如 `www.microsoft.com:443`。 |
| **SNI / Server Names** | 客户端发送的主机名;必须与目标站点的证书匹配。 |
| **Public / Private key** | 一对 **x25519** 密钥。私钥保留在服务器上。 |
| **Short IDs** | 用于验证客户端的十六进制字符串(可以设置多个)。 |
| **Flow** | 设为 `xtls-rprx-vision`。 |
| **Fingerprint (uTLS)** | 要模仿的客户端 TLS 指纹,例如 `chrome`。 |
私钥由 Xray 的 `x25519` 工具生成(面板可以为你生成这对密钥):
```bash title="generate an x25519 keypair"
xray x25519
```
## 在面板中配置
<Steps>
<Step>
### 创建 VLESS 入站
添加一个新入站,协议选择 **VLESS**,并将 **Security** 设为 **reality**。
</Step>
<Step>
### 选择目标(dest)和 SNI
选一个支持 TLS 1.3 和 HTTP/2、且你的服务器与客户端都能访问的可信站点
(例如 `www.microsoft.com:443`)。将 server names / SNI 设为与该站点证书匹配。
</Step>
<Step>
### 生成密钥和 short ID
生成 x25519 密钥对以及一个或多个 short ID。请妥善保管**私钥**;客户端永远只会收到**公钥**。
</Step>
<Step>
### 设置流控和指纹
使用 `xtls-rprx-vision` 流控,以及一个常见的 uTLS 指纹(例如 `chrome`)。
</Step>
<Step>
### 添加客户端并分享链接
创建一个客户端,然后在兼容的应用(v2rayNG、Hiddify、Mihomo 等)中使用它的分享链接或二维码。
</Step>
</Steps>
## 配置长什么样
在服务器端,一个 REALITY 入站的 `streamSettings` 大致如下:
```json title="server inbound (excerpt)"
{
"network": "tcp",
"security": "reality",
"realitySettings": {
"dest": "www.microsoft.com:443",
"serverNames": ["www.microsoft.com"],
"privateKey": "<x25519 private key>",
"shortIds": ["<hex short id>"],
"fingerprint": "chrome"
}
}
```
与之匹配的客户端分享链接携带的是**公开**参数:
```text title="vless:// (excerpt)"
vless://<uuid>@<server>:443?security=reality&pbk=<public-key>&sid=<short-id>&sni=www.microsoft.com&fp=chrome&spx=%2F&flow=xtls-rprx-vision#my-reality
```
- `pbk` —— REALITY **公**钥
- `sid` —— short ID(与服务器上的某一个匹配)
- `sni` —— server name(与目标站点的证书匹配)
- `fp` —— 客户端指纹
- `spx` —— spiderX 路径
- `flow` —— `xtls-rprx-vision`
## 常见陷阱
<Callout type="warn">
- **目标选得不好。** `dest` 必须是一个真实站点,支持 **TLS 1.3** 和 **HTTP/2**、可访问,且在你所在地区未被封锁。请选一个你并不拥有、且访问量很大的站点。
- **SNI 不匹配。** SNI / server names 必须与目标站点的真实证书匹配,否则握手会暴露伪装。
- **私钥泄露。** 永远只把**公钥**分发给客户端。
- **流控设置错误。** 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`,或升级服务端。仅清空版本限制无法解决握手问题。
</Callout>
## 生成配置
使用下面的生成器创建一对全新的 X25519 密钥、UUID 和 short ID,然后复制服务器入站 JSON 和客户端分享链接。
所有内容都在**你的浏览器中**计算——不会有任何密钥或链接被发送到任何地方。
<RealityConfigGenerator />
<Callout type="info">
**私钥**只应留在你的服务器上。请把生成的 `vless://` 链接(其中包含**公钥**)分享给客户端。
</Callout>