Files
3x-ui/docs/content/docs/zh/config/reality.mdx
T
PathGao a2774bf212 fix(ui): explain the REALITY client version gate and drop the impossible placeholder (#6125)
* fix(ui): explain the REALITY client version gate and drop the impossible placeholder

An empty Min Client Ver looks unrestricted, but Xray-core silently
falls back to a built-in minimum (currently 26.3.27) that rejects
third-party cores such as Mihomo and sing-box with a bare REALITY
verification failure, and nothing in the panel points at the field.
Add tooltips to both version fields explaining the fallback and its
TLS-fingerprint-freshness rationale.

The Max Client Ver placeholder (25.9.11) sat below the built-in
minimum, so filling in both placeholders produced a range that
rejects every client. Remove it; empty genuinely means no upper
limit for that field.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* docs(reality): warn that an empty min client version rejects old cores

Common pitfalls covered bad targets, SNI mismatches, leaked keys and
wrong flow, but not the client version gate that currently bites
Mihomo and sing-box users. Add it to all four doc languages.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(ui): word the version hints against the effective minimum

Address the automated review: the Max Client Ver hint said only 'not
lower than Min Client Ver', which re-establishes the empty-means-unset
mental model when the effective floor is the core's built-in minimum.
Both hints now name the effective minimum and tie the quoted 26.3.27
to the core build the panel runs, since operators can install any
Xray-core version.

Also from review: full-width quotes and a missing verb in the zh doc
bullet, the idiomatic Arabic opening, and a format-only x.y.z
placeholder on Max Client Ver so the field still conveys its shape.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
2026-07-28 22:08:39 +02:00

122 lines
5.0 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 会退回到所运行内核版本的内置最低值(当前版本为 26.3.27)以保证客户端 TLS 指纹的新鲜度,因此 Mihomo、sing-box 等第三方内核即使配置完全正确也会导致 REALITY 验证失败——表现为客户端超时,只有基于 Xray-core 的应用能连上。只有在必须支持它们时才填 `1.0.0`;这同时也会放行过时的指纹。
</Callout>
## 生成配置
使用下面的生成器创建一对全新的 X25519 密钥、UUID 和 short ID,然后复制服务器入站 JSON 和客户端分享链接。
所有内容都在**你的浏览器中**计算——不会有任何密钥或链接被发送到任何地方。
<RealityConfigGenerator />
<Callout type="info">
**私钥**只应留在你的服务器上。请把生成的 `vless://` 链接(其中包含**公钥**)分享给客户端。
</Callout>