外观
VLESS + REALITY：工作原理与适用场景
REALITY 是运行在 VLESS 之下的 TLS 传输方案，让服务端在握手阶段表现得像某个真实的第三方网站，无需自有域名与公共证书。它适合能自由更新客户端内核的用户，不适合只能用老内核或路由器固件的环境。
REALITY 是一种运行在 VLESS 之下的 TLS 传输方案，它让代理服务端在握手阶段表现得像某个真实的第三方网站：合法客户端在 ClientHello 中嵌入用密钥保护的认证信息，服务端验证通过后用临时证书完成握手并进入代理；验证失败的连接则被原样转交给那个真实网站，由它用真实证书应答。这样服务端不需要自有域名与公共证书机构签发的证书，握手时呈现的 SNI 与证书都指向第三方站点。它适合可以自由更新客户端内核、关注握手特征一致性的用户，不适合只能使用老内核或路由器固件的环境。
核心结论与适用条件
- 如果你的客户端内核支持 REALITY，并且你希望节点在握手阶段不暴露服务提供者自有的域名与证书信息，那么 REALITY 是当前与 VLESS 搭配的主要方案之一，其价值集中在握手阶段。
- 如果你的设备只能运行老内核、路由器固件或某些不支持 REALITY 的客户端，那么无论品牌怎样标注，REALITY 节点都无法导入使用，应确认品牌是否提供普通 TLS 或其他协议的节点。
- 如果你把 REALITY 与 XTLS Vision 混为一谈，那么需要先分清：前者解决握手阶段的证书与 SNI 来源，后者解决传输阶段的重复加密；两者经常同时出现，但各自独立。
- 如果你遇到 REALITY 节点连不上，那么开启跳过证书校验不会有帮助，因为 REALITY 的验证不走公共证书链，排查应从内核支持与参数完整性开始。
- 本站收录的 12 个标注 VLESS 的品牌，传输方案全部待核实，没有任何品牌资料写明使用 REALITY；所有品牌为 Vendor Data。
以上结论基于 REALITY 公开设计说明与 TLS 的通用原理。协议、线路、安全三层的总体关系，请回到协议与安全专题看 REALITY 在三层中的位置；VLESS 自身的分层设计见VLESS 为什么把加密职责交给外层 TLS。
REALITY 要解决的问题：证书与 SNI 的来源
传统的 VLESS over TLS 或 Trojan 部署有一个共同要求：服务端必须持有一个能通过客户端校验的证书。获得这种证书的常规路径是注册一个域名，向公共证书机构申请证书，再把域名解析到服务端。这个路径带来三个相互关联的问题。
第一个问题是来源可追溯。域名注册记录、证书签发记录、DNS 解析记录都指向同一个服务提供者。即使流量内容被 TLS 保护，握手阶段明文传输的 SNI（服务器名称指示）与返回的证书已经说明了“这条连接去往谁的服务器”。
第二个问题是伪装不一致。一些部署会在服务端放一个静态网页作为伪装站点，但这个站点与真实流行网站在证书签发者、页面内容、响应行为上通常不一致。探测者可以访问同一地址，比较返回内容与声明的域名是否匹配。
第三个问题是维护成本。证书有有效期，需要定期更新；域名需要续费；任何一环出错都会导致客户端证书校验失败。证书校验失败时最常见的错误处理是开启跳过证书校验，而这会让 TLS 的防护完全失效，跳过证书校验为什么让中间人攻击变得可行解释了后果。
REALITY 的思路是绕开“自己持有证书”这个前提。它让服务端“借用”一个真实存在的第三方网站：合法客户端的握手由服务端用自己派生的临时证书完成，非法连接的握手则直接转交给那个真实网站。探测者无论怎样访问，看到的都是真实网站的真实证书与真实页面，而不是一个需要自圆其说的伪装站点。
REALITY 握手分步拆解
下面按时间顺序拆解一次 REALITY 握手。描述只涉及公开设计说明中的原理，不涉及任何实现细节或版本差异。
第一步：客户端准备带认证信息的 ClientHello
客户端发出的 ClientHello 在外观上是一个访问目标站点的普通 TLS 握手：SNI 字段填写的是服务端配置中指定的真实站点域名，而不是服务端自己的任何域名。与普通握手的区别藏在 ClientHello 中一个原本由随机数据填充的字段里：客户端用自己的临时密钥与服务端公布的公钥做密钥协商，派生出一个只有双方能得到的密钥，用它加密一段认证信息（包含 shortId、时间等要素），再把加密结果放进那个字段。对外部观察者而言，这个字段仍然看起来是随机数据。
第二步：服务端尝试解出认证信息
服务端收到 ClientHello 后，用自己的私钥与客户端在握手中携带的临时公钥做同样的协商，尝试解密那个字段。如果解密成功并且 shortId 在允许列表内、时间在容许范围内，服务端把这条连接判定为合法客户端；否则判定为非法连接。判定过程不向客户端返回任何可区分的信息，两类连接在这一刻看起来都在正常进行握手。
第三步（合法连接）：服务端签发临时证书完成握手
对合法连接，服务端自己完成 TLS 握手。它不持有公共证书机构签发的证书，而是即时生成一张与目标站点域名相符的临时证书，并用从密钥协商中派生的信息为证书生成签名。客户端收到证书后，不按常规方式去公共证书链验证，而是用自己同样派生出的信息验证签名。验证通过意味着对方确实持有与配置公钥对应的私钥，握手完成，之后的数据进入 VLESS 层处理。
第三步（非法连接）：服务端转交真实站点
对非法连接，服务端不解析任何后续内容，而是与配置中的真实目标站点建立连接，把客户端的 ClientHello 原样转发过去，之后在两端之间双向转发字节。真实站点用自己的真实证书完成握手，返回真实页面。探测者看到的证书签发者、有效期、页面内容与直接访问该站点时完全一致，因为它确实在与该站点通信，服务端只是中间的转发者。
第四步：客户端指纹使握手各环节相互一致
证书层面的伪装只是一半。如果客户端的 ClientHello 带有代理内核默认的特征，例如扩展列表与常见浏览器不同，那么“一个非浏览器客户端在访问某流行站点”本身就是一种不一致。REALITY 配置中的 fingerprint 字段让客户端通过 uTLS 模拟某种浏览器的握手特征，使 SNI、证书、ClientHello 特征三者指向同一个合理解释。这一机制的原理在TLS 指纹与 uTLS 为何影响连接建立中展开。
第五步：进入 VLESS 层，可选启用流控
握手完成后，TLS 通道之内是标准的 VLESS 流程：客户端发送请求头，服务端校验用户标识并转发。如果配置了 XTLS Vision 流控，内层 TLS 流量的重复加密会在这一阶段被减少，详见XTLS Vision 流控在传输阶段做了什么。REALITY 的工作到握手完成为止，传输阶段的行为由 VLESS 与流控决定。
REALITY 参数作用与配置方对照表
REALITY 的配置项比普通 TLS 多，每一项都有明确职责。下表说明各参数由谁配置、起什么作用、配错后的典型表现。表中不包含任何默认值或版本信息，具体字段名以所用内核的文档为准。
| 指标（参数） | 配置方 | 作用 | 配错后的典型表现 | 单位 | 统计口径 | 数据来源 | 更新时间 |
|---|---|---|---|---|---|---|---|
| 目标站点（dest / serverName） | 服务端指定，客户端填写站点名称 | 决定握手时的 SNI 与非法连接的转交目标 | 名称不一致时握手失败或伪装不成立 | — | 公开设计说明 | 通用技术资料 | 2026-10-18 |
| 私钥 | 仅服务端 | 解出 ClientHello 中的认证信息并派生签名材料 | 泄露后他人可冒充服务端 | — | 公开设计说明 | 通用技术资料 | 2026-10-18 |
| 公钥 | 客户端（由服务端公布） | 与服务端私钥配对，用于密钥协商与证书签名验证 | 复制不完整时握手失败 | — | 公开设计说明 | 通用技术资料 | 2026-10-18 |
| shortId | 服务端允许列表 + 客户端单值 | 区分客户端或配置组，参与认证信息 | 不在允许列表内时连接被转交真实站点 | — | 公开设计说明 | 通用技术资料 | 2026-10-18 |
| 指纹（fingerprint） | 客户端 | 通过 uTLS 模拟浏览器 ClientHello 特征 | 未设置时握手特征与声明站点不一致 | — | 公开设计说明 | 通用技术资料 | 2026-10-18 |
| 流控（flow） | 服务端与客户端一致 | 决定是否启用 XTLS Vision，REALITY 本身不要求 | 两端不一致时连接异常 | — | 公开设计说明 | 通用技术资料 | 2026-10-18 |
| 时间容许范围 | 服务端 | 限制认证信息的有效时间窗口 | 设备时间偏差过大时被判为非法连接 | 相对描述 | 公开设计说明 | 通用技术资料 | 2026-10-18 |
| 爬虫路径（spiderX） | 客户端可选 | 在特定场景下模拟对目标站点的页面访问路径 | 通常不影响基础连接 | — | 公开设计说明 | 通用技术资料 | 2026-10-18 |
| 公共证书机构证书 | 不需要 | REALITY 不走公共证书链 | — | — | 公开设计说明 | 通用技术资料 | 2026-10-18 |
| 自有域名 | 不需要 | SNI 使用第三方真实站点名称 | — | — | 公开设计说明 | 通用技术资料 | 2026-10-18 |
| 握手延迟 / 吞吐开销 | — | — | — | ms / Mbps | 本站无实测 | Not Tested | 2026-10-18 |
| 品牌资料中写明使用 REALITY 的数量 | — | — | — | 个 | brands.json 无传输方案字段 | 待核实 | 2026-10-18 |
“时间容许范围”值得单独说明：REALITY 的认证信息包含时间要素，因此它对设备时钟有一定要求。这与 VLESS 自身不依赖时间的特性并不矛盾，因为时间校验发生在 REALITY 的握手层，而不是 VLESS 的协议层。设备时间严重不准的用户在 REALITY 节点上可能遇到连接被转交的情况，表现为浏览器能打开真实站点但代理不工作。
三种 TLS 来源方案的差异
| 对比项 | 自有域名 + 公共证书 | Trojan 式真实站点 | REALITY |
|---|---|---|---|
| 服务端是否需要域名 | 是 | 是 | 否 |
| 证书来源 | 公共证书机构 | 公共证书机构 | 服务端即时派生，客户端用公钥验证 |
| SNI 指向 | 服务提供者域名 | 服务提供者域名 | 第三方真实站点 |
| 非法连接看到什么 | 伪装页或错误 | 服务端自有的真实站点 | 第三方站点的真实证书与页面 |
| 客户端内核要求 | 较低 | 较低 | 需支持 REALITY 的较新内核 |
| 证书到期维护 | 需要 | 需要 | 不需要 |
这张表说明 REALITY 的差异集中在“来源”一列。它并没有改变 TLS 的加密强度，机密性仍然由 TLS 的密码套件决定；它改变的是握手阶段暴露给观察者的信息指向谁。对加密层次的整体理解，可以对照代理链路上传输加密与端到端加密各自保护什么。
适用场景与不适用场景
适合的情形
可以自由更新客户端的桌面与移动用户是 REALITY 的主要适用群体。这类用户能够使用支持 REALITY 的内核，也能在节点出问题时自行核对参数。关注握手阶段信息指向的用户也属于这一群体：如果你在意服务端是否暴露自有域名与证书记录，REALITY 的设计直接针对这一点。此外，不希望因证书到期而频繁遇到校验失败的用户也会受益，因为 REALITY 不依赖会过期的公共证书。
不适合的情形
只能使用老内核、路由器固件或某些闭源客户端的用户，首先要确认内核是否支持 REALITY；不支持则这一方案与你无关，应确认品牌是否提供普通 TLS 节点。多设备用户需要所有设备都支持，否则需要混合方案。对配置排查没有耐心的用户也需要注意：REALITY 的参数比普通 TLS 多，订阅转换过程中丢失任何一项都会导致连不上，而错误提示往往不直观。路由器上的实现范围与限制在移动与路由器客户端的协议支持差异中有讨论。
与设备时钟相关的情形
前面提到 REALITY 的认证信息含时间要素。长期不联网校时的设备在 REALITY 节点上可能表现为“能连上但没有代理效果”，因为连接被当作非法流量转交给了真实站点。遇到这种现象，校准时间是排查的一步。
决策树：REALITY 是否与你有关
Decision Path
判断是否应关注 REALITY 节点
text
你的客户端内核支持 REALITY 吗？
├─ 不支持 / 不确定
│ ├─ 能更新或更换客户端 → 更新后再判断
│ └─ 不能（路由器 / 老设备 / 固定客户端）
│ └─ 确认品牌是否提供普通 TLS 或其他协议节点，否则不选
└─ 支持
└─ 订阅中的 VLESS 节点安全类型是什么？
├─ reality → 核对公钥 / shortId / 站点名称 / 指纹是否完整
│ ├─ 完整且能连 → 进入安全检查（DNS / 客户端来源）
│ └─ 连不上 → 不要开启跳过证书校验，按参数逐项排查
├─ tls → 与 REALITY 无关，按普通 TLS 节点处理
└─ 字段缺失 / 待核实 → 向客服确认传输方案后再决定周期决策树把“内核支持”放在第一位，因为这是 REALITY 与普通 TLS 节点在用户侧最大的区别。内核对照方法见哪些客户端内核支持 VLESS、Vision 与 REALITY。
知识图谱：REALITY 传输方案
实体定义
REALITY 是一种为 VLESS 等协议提供 TLS 传输的方案，特点是服务端不持有自有域名与公共证书，而是借用第三方真实站点的名称完成握手：对携带有效认证信息的客户端用即时派生的临时证书应答，对其他连接原样转交真实站点。它工作在 TLS 握手层，不改变 VLESS 协议本身，也不改变 TLS 的加密强度。
相关概念
上游概念：TLS 握手流程、SNI、证书链、密钥协商。平行概念：自有域名 TLS（传统方案）、Trojan 式真实站点伪装、uTLS 指纹模拟。下游与组合概念：XTLS Vision（传输阶段流控，常与 REALITY 同时出现但相互独立）、VLESS 回落（服务端对 VLESS 层未认证连接的处理，与 REALITY 对握手层非法连接的转交是两个不同层面的机制）。安全层概念：跳过证书校验（对 REALITY 无意义且不应开启）、DNS 泄露、客户端来源校验。
技术参数
可以从公开设计说明确定的参数：目标站点名称、公钥与私钥、shortId、指纹、时间容许范围、可选的爬虫路径。可以从订阅内容确认的参数：节点的安全类型字段是否为 reality、各参数是否完整。品牌资料能提供的只有协议标注与客户端方式两项，传输方案全部待核实。本站不提供 REALITY 的握手延迟或吞吐数值，如需比较应在同一节点同一时段分别测量，口径见统一口径的测试方法说明。
适用场景
可自由更新内核的桌面与移动用户；关注握手阶段信息指向的用户；希望避免证书到期问题的用户。不适用于老内核、路由器固件与不支持 REALITY 的客户端环境。多设备用户需确认所有设备都支持，否则需要品牌提供多种传输方案的节点。
对比依据
本站对 REALITY 与其他 TLS 来源方案的比较只依据公开设计说明中的机制差异，不依据任何品牌宣传，不依据任何实测。REALITY 在协议维度中的位置以及它为何不应单独成为选型依据，见横向对比中协议与传输方案维度的权重。
常见问题指向
“没有证书怎么验证服务端”“探测者为什么看到真实网站”“shortId 是什么”在本文常见问题章节回答；“流量特征能否被识别”“伪装的边界在哪里”由协议伪装的原理与识别边界承接；“REALITY 节点连不上怎么排查”由VLESS 节点连不上时的配置错误排查承接。
方案关联：如何从订阅内容确认传输方案
本文主题是传输方案，而 brands.json 中没有传输方案字段，因此这里不展示品牌快照，而是说明用户如何自行确认。12 个标注 VLESS 的品牌按客户端方式可分为三类，确认路径不同：
| 客户端方式（资料原文） | 品牌 | 确认传输方案的路径 | 统计口径 | 数据来源 | 更新时间 |
|---|---|---|---|---|---|
| 自研客户端+第三方订阅导入 | 光速云、U1S1、光年梯、SOGO云、速界、快狸 | 自研客户端通常已匹配内核；第三方导入时查看节点安全类型字段 | brands.json clientSupport 原文 | 品牌公开资料/用户提供清单 | 2026-10-18 |
| 自研客户端+第三方客户端 | 宇宙云 | 同上 | brands.json clientSupport 原文 | 品牌公开资料/用户提供清单 | 2026-10-18 |
| 支持第三方客户端订阅导入 / 以官方说明为准 | 一翻云、二猫云、可信云、全球云 | 必须在导入后查看节点字段，或付费前向客服确认 | brands.json clientSupport 原文 | 品牌公开资料/用户提供清单 | 2026-10-18 |
| 根据官方订阅格式使用对应客户端 | 唯兔云 | 以官方教程中出现的客户端与字段为准 | brands.json clientSupport 原文 | 品牌公开资料/用户提供清单 | 2026-10-18 |
确认方法有三种。第一，导入订阅后在客户端中查看节点详情，使用 REALITY 的节点在安全类型字段标注 reality 并带有公钥与 shortId 参数，普通 TLS 节点标注 tls 且没有公钥字段。第二，查看品牌官方教程中出现的客户端名称与配置截图，从中推断传输方案。第三，付费前向客服直接询问。三种方法中第一种最可靠，但需要先获得订阅，因此建议先选择较短周期或较小套餐验证，再考虑长周期付费。传输方案属于本站资料中的待核实字段，待核实字段在选型中应如何处理给出了通用方法。你可以在品牌库中按协议标注筛选后逐个核对客户端方式。
所有品牌为 Vendor Data，测速 Not Tested。品牌资料显示覆盖相关使用场景，具体可用性、解锁状态及节点表现可能随 IP、地区和平台策略变化，建议以最新实际测试结果为准。
优点、限制与风险提示
REALITY 的优点
- 服务端不需要自有域名与公共证书，握手阶段的 SNI 与证书指向第三方真实站点，减少了可追溯的来源信息。
- 非法连接被转交真实站点，探测者看到的是真实证书与真实页面，而不是需要自圆其说的伪装页。
- 不依赖会过期的公共证书，减少了因证书到期导致的校验失败。
- 与 uTLS 指纹模拟配合，使 SNI、证书、ClientHello 特征三者相互一致。
- 不改变 VLESS 协议本身，可以与 XTLS Vision 组合也可以单独使用。
REALITY 的限制
- 需要支持 REALITY 的较新内核，老内核、路由器固件与部分客户端无法使用。
- 配置参数多于普通 TLS，订阅转换过程中丢失任何一项都会导致连接失败，且错误提示不直观。
- 认证信息含时间要素，设备时钟严重不准时连接会被当作非法流量转交。
- 伪装效果依赖服务端选择的目标站点与运维质量，用户侧无法干预。
- 本站没有任何品牌的传输方案信息，也没有 REALITY 的性能数据，相关指标为待核实与 Not Tested。
风险提示
- 把 REALITY 等同于“更安全”是常见误读；它改变的是握手阶段的信息指向，机密性仍由 TLS 加密强度与正确配置决定。
- REALITY 节点连不上时开启跳过证书校验没有帮助，且会在其他 TLS 节点上留下严重的安全隐患。
- 流量特征识别是持续变化的领域，任何传输方案都不应被理解为确定性的不可识别承诺。
- 品牌资料中传输方案全部待核实；机场服务的线路、节点、价格和套餐可能随时调整，下单前请以品牌官网实时信息为准。
- 本文不包含任何品牌的用户评价、亲自使用经历或测速推测，也不构成推荐。关于订阅凭据保管与账号层面的风险，可以查看风险与注意事项专题中的账号与订阅条目。
常见问题
REALITY 服务端没有真实证书，客户端怎么确认连上的是自己的服务端？
客户端配置中有服务端公布的公钥，服务端持有对应私钥。握手时双方基于这对密钥派生出共享信息，服务端用它为临时证书生成客户端可以验证的签名。客户端验证的不是证书是否由公共证书机构签发，而是签名是否能用配置的公钥对应关系验证通过。密钥不匹配时握手会失败，而不是静默接受。
为什么探测者访问 REALITY 服务端会看到一个真实网站？
因为服务端对没有携带有效认证信息的连接不做任何代理处理，而是把这条连接原样转交给配置中指定的真实目标站点。目标站点用自己的真实证书完成握手并返回正常页面，探测者得到的证书、页面内容与直接访问该站点时一致。服务端在这条连接上只扮演了转发者的角色。
REALITY 中的 shortId 是密码吗？
不是密码，而是一个短标识，用来让服务端区分不同客户端或配置组，并作为认证信息的一部分嵌入 ClientHello。它必须与服务端配置中的允许列表匹配，但长度很短，不承担加密强度的职责。真正的认证强度来自公钥与私钥的对应关系，shortId 不匹配只会导致连接被当作非法流量转交。
REALITY 与用自有域名加证书的普通 TLS 代理相比，哪个更安全？
两者在机密性上都依赖 TLS 的加密强度，差别在于来源信息的暴露程度。自有域名方案的证书、域名注册与 SNI 都指向服务提供者，可以被追溯；REALITY 的握手指向第三方真实站点，服务端自身不持有可追溯的证书。但 REALITY 对客户端内核版本要求更高，配置错误时更难排查。安全性取决于整条链路是否正确配置，而不只是方案名称。
REALITY 一定要配合 XTLS Vision 使用吗？
不一定，两者解决的问题不同。REALITY 解决握手阶段的证书与 SNI 来源问题，Vision 解决握手之后数据传输阶段内层 TLS 被重复加密的问题。它们可以同时启用，也可以只用 REALITY 而不启用流控。实际配置中两者经常一起出现，但这是组合选择，不是技术上的强制依赖。
客户端配置里的 fingerprint 字段为什么对 REALITY 很重要？
因为 REALITY 的伪装效果建立在握手看起来像普通浏览器访问真实站点的前提上。如果客户端发出的 ClientHello 带有代理内核默认的指纹特征，与声明的目标站点和常见浏览器行为不一致，伪装就只在证书层面成立。fingerprint 字段让客户端通过 uTLS 模拟某种浏览器的握手特征，使握手的各个环节相互一致。
怎样从订阅内容判断一个 VLESS 节点用的是 REALITY 还是普通 TLS？
查看节点的安全类型字段。使用 REALITY 的节点通常在传输安全字段中标注 reality，并附带公钥、shortId、目标站点名称与指纹参数；使用普通 TLS 的节点则标注 tls，带的是证书相关的服务器名称参数，没有公钥字段。本站收录品牌的资料中都没有写明这一项，需要从实际订阅内容或官方教程确认。
REALITY 节点连不上，排查应从哪里开始？
先确认客户端内核是否支持 REALITY，这是与普通 TLS 节点排查最大的不同点。之后依次核对公钥是否完整复制、shortId 是否在服务端允许范围内、目标站点名称与指纹字段是否被订阅转换过程丢弃。开启跳过证书校验不能解决 REALITY 的连接问题，因为它的验证不走公共证书链。
REALITY 服务端配置的目标站点如果变更或下线会怎样？
合法客户端的连接不经过目标站点，因此目标站点的变化通常不直接影响正常使用；但服务端对非法连接的转交会失败，伪装效果受损，探测者可能看到异常响应。这属于服务端运维问题，用户侧无法干预，只能在节点表现异常时联系服务商。本站没有任何品牌的服务端配置信息。
本站收录的品牌中，哪些使用 REALITY？
无法从本站资料回答。17 个品牌中有 12 个标注 VLESS，但资料均只写了协议名称，没有写明搭配的传输方案是 TLS、XTLS Vision 还是 REALITY，这一项全部待核实。判断方法是导入订阅后查看节点的传输安全字段，或在付费前向客服确认。本站未查看任何品牌的实际订阅内容。
下一步
理解 REALITY 之后，传输阶段的另一半问题是 Vision 流控，上文已给出入口。如果你准备导入订阅并核对节点字段，桌面客户端中查看节点传输参数的通用位置与客户端与配置专题的总览按平台说明了核对方法；如果你正在把传输方案这一待核实项放进整体选型，选型方法专题中确认协议与客户端兼容的步骤给出了它在流程中的位置；若想把协议与其他维度并排对照，可以到对比专题按维度并排查看品牌差异。
Cluster · vless
VLESS 协议
- VLESS 协议是什么：与 VMess 的设计差异VLESS 协议是什么，它和 VMess 有什么不同？
- VLESS + REALITY：工作原理与适用场景REALITY 是如何工作的，适合什么场景？
- XTLS Vision 流控的作用与配置要点XTLS Vision 流控解决了什么问题？
- 哪些客户端支持 VLESS：内核与版本对照哪些客户端和内核版本可以使用 VLESS 节点？
- VLESS、Trojan、Shadowsocks 对比：特征、性能与兼容性VLESS、Trojan 和 Shadowsocks 应该怎么选？
- VLESS 节点连不上：常见配置错误排查VLESS 节点无法连接时应该按什么顺序排查？
- 协议不是越新越好：按设备与网络环境选择协议应该根据什么条件选择代理协议？
下方卡片指向品牌库入口。传输方案在所有品牌资料中均为待核实，进入品牌库后请把它与价格类型、流量一同列入确认清单；这不构成推荐。
信息来源与更新日期
- 信息来源：通用技术资料（REALITY 公开设计说明中描述的认证信息嵌入、临时证书签发与非法连接转交机制；TLS 握手、SNI、证书链与 uTLS 指纹的通用原理）；品牌公开资料/用户提供清单（data/brands.json 的 protocols 与 clientSupport 字段）。
- 数据状态：全部品牌为 Vendor Data，测速 Not Tested，传输方案全部待核实，没有任何品牌资料写明使用 REALITY。
- 数据核实日期：2026-10-18。
- 最近更新时间：2026-10-18。
- 本文不提供握手延迟或吞吐数值；不包含用户评价、亲自使用经历或测速推测；不把任何传输方案描述为不可识别的确定性承诺；不承诺任何平台的收录或排名。