外观
TLS 指纹与 uTLS：客户端指纹为何影响连接
TLS 指纹是从握手第一条消息 ClientHello 中提取的一组字段特征，它由客户端所用的 TLS 库决定，与域名、证书、端口无关。
多数代理内核用 Go 语言编写，默认 TLS 实现发出的 ClientHello 与浏览器差异明显，因此即使外层看起来是一条普通 HTTPS 连接，握手样式也可能显示它并非浏览器。uTLS 让客户端能够按主流浏览器的模板组装 ClientHello，使握手阶段的特征与常见浏览器一致，这是 REALITY 等较新传输方案要求配置指纹选项的根本原因。
核心结论与适用条件
TLS 指纹问题在以下条件同时成立时才需要你关心：你的订阅使用的是基于 TLS 的传输方案（如 VLESS over TLS、REALITY、Trojan 类），你的客户端内核支持 uTLS，并且订阅或服务端对指纹有要求。如果你的订阅使用 Shadowsocks 这类不依赖 TLS 握手的方案，指纹选项不适用；如果你的客户端内核根本没有实现 uTLS，填任何取值都不会生效。
本文只讨论指纹的通用原理、它为何影响连接成功率、以及在客户端中如何核对这一项。本文不提供任何速度、延迟或握手耗时的数值，不对任何品牌的服务端参数做判断，17 个品牌的指纹与传输方案字段全部为待核实。如果你是第一次接触协议层概念，可以先回到 从协议总览理解 TLS 在代理中的位置 建立整体框架，再回到本文。
握手的第一条消息：ClientHello 里有什么
TLS 握手由客户端发起。客户端发出的第一条消息叫 ClientHello，它告诉服务端“我支持哪些协议版本、哪些密码套件、哪些扩展、想访问哪个域名”。服务端据此选择双方都支持的参数，返回 ServerHello 并继续后续步骤。ClientHello 在加密通道建立之前发出，因此它是明文的，任何处于路径上的设备都能完整读到。
ClientHello 的内容由客户端的 TLS 库决定。库的开发者会在代码里固定一个密码套件偏好顺序、一个扩展列表及其排列、一组椭圆曲线与签名算法偏好。用户通常无法在应用层改变这些细节，所以同一个库在不同机器上生成的 ClientHello 几乎相同，不同库之间则差别明显。这种“同库相同、异库不同”的性质，正是指纹得以成立的基础。
把 ClientHello 中稳定出现的字段按固定方式拼接并计算散列，就得到一个可以比对的短串。业界有多种公开的归纳方法，JA3 是其中较为人熟知的一类，它选取协议版本、密码套件、扩展、椭圆曲线、曲线点格式五类字段的数值序列生成散列。后续方法在这个思路上做了改进，比如处理扩展顺序的随机化、纳入 ALPN 与签名算法等字段。无论具体方法如何，核心逻辑一致：从明文握手中提取由 TLS 库决定的稳定特征。
为什么代理客户端的握手与浏览器不一样
浏览器厂商各自维护 TLS 实现，并且会定期调整密码套件顺序、增加或删除扩展、引入 GREASE 这类随机占位值来防止中间设备对参数做僵化假设。这些实现经过大量真实流量验证，其 ClientHello 样式是互联网上最常见的一类。
多数代理内核使用 Go 语言编写，默认采用 Go 标准库的 TLS 实现。Go 标准库的 ClientHello 自成一派：密码套件顺序、启用的扩展集合、是否使用 GREASE、ALPN 的写法都与浏览器不同。于是出现一个反直觉的情况：你的代理连接外层确实是标准 TLS，域名与证书也都真实有效，但握手的第一条消息已经说明“这不是浏览器发出的”。
这种差异本身不是安全漏洞，TLS 的机密性与完整性不受影响。问题在于它让代理流量从“大量普通 HTTPS 连接”中变得可区分。对于希望自己的连接在握手阶段与常见客户端保持一致的用户来说，这就是一个需要处理的特征。关于流量在哪些维度上可能被区分，理解流量识别从哪些特征入手 一文有更系统的拆解，本文只聚焦握手这一个维度。
uTLS 做了什么，没做什么
uTLS 是对 Go 标准库 TLS 实现的一个分支。它保留了标准库的握手逻辑与加密实现，但放开了对 ClientHello 内容的控制权：调用方可以指定密码套件列表及顺序、扩展列表及顺序、是否插入 GREASE 值、ALPN 与签名算法偏好等。为了方便使用，uTLS 还内置了一批按主流浏览器样式整理的预设模板，代理内核在发出握手时套用某个模板，ClientHello 就会与该浏览器高度一致。
需要明确 uTLS 的边界。它只改变握手第一条消息的样式，不改变后续加密算法的实际运算、不改变数据包的大小与时序、不改变线路路径与服务端处理方式。因此 uTLS 不会让连接更快，也不能让一条慢线路变快。它解决的是一个很窄的问题：让握手阶段的特征不显得异常。流量在传输阶段的包长分布、时序特征、服务端回应样式等，需要由其他机制处理，这是 REALITY 为何要借用真实网站的回应外观 所要讨论的内容。
uTLS 的模板也不是一成不变的。浏览器每次更新都可能调整 ClientHello 细节，uTLS 维护者需要跟进更新模板；客户端内核再跟进 uTLS 版本。这个链条意味着：你客户端里名为某浏览器的模板，实际对应的是模板录入时那个浏览器的样式，与你机器上正在运行的最新浏览器未必完全相同。这也是为什么本站不写任何具体版本号，这类信息过期很快。
指纹要素与客户端可核对项对照表
下表把 TLS 指纹涉及的要素与你在客户端中能核对的项目放在一起。所有行均为通用原理，不涉及任何品牌的实际参数。
| 指标 | 单位 | 统计口径 | 数据来源 | 更新时间 |
|---|---|---|---|---|
| ClientHello 协议版本字段 | 版本标识 | 握手消息中声明的 TLS 版本范围 | 通用技术资料 | 2026-10-18 |
| 密码套件列表及顺序 | 条目序列 | 列表内容与排列顺序共同构成特征 | 通用技术资料 | 2026-10-18 |
| 扩展列表及顺序 | 条目序列 | 含 SNI、ALPN、supported_groups、key_share 等 | 通用技术资料 | 2026-10-18 |
| GREASE 占位值 | 有/无 | 浏览器实现普遍插入，标准 Go 实现默认不插入 | 通用技术资料 | 2026-10-18 |
| 椭圆曲线与签名算法偏好 | 条目序列 | 由 TLS 库固定，用户不可在应用层修改 | 通用技术资料 | 2026-10-18 |
| 指纹散列（JA3 及后续方法） | 散列字符串 | 对上述字段按固定方式拼接后计算 | 通用技术资料 | 2026-10-18 |
| 客户端 fingerprint 字段 | 模板名称 | 浏览器名称或随机化关键字，取值范围由内核决定 | 客户端文档 | 2026-10-18 |
| 内核是否实现 uTLS | 是/否 | 以客户端公开说明为准 | 客户端文档 | 2026-10-18 |
| 服务端是否要求特定指纹 | 是/否/待核实 | 以订阅文件与服务方说明为准 | 订阅提供方 | 2026-10-18 |
| 品牌资料中的指纹参数 | 文本 | 17 个品牌均未写明 | 品牌公开资料/用户提供清单 | 2026-10-18 |
| 指纹对吞吐与延迟的影响 | 不适用 | 本站不提供性能数值，状态为 Not Tested | 本站口径 | 2026-10-18 |
表中最后一行需要强调：本站对所有品牌的测速状态均为 Not Tested，不会为指纹选项的开关给出任何性能对比数字。
指纹模板的几种取值与含义
客户端中的 fingerprint 字段通常接受三类取值。第一类是具体浏览器名称，表示固定套用该浏览器的模板，流量在握手阶段始终呈现同一种样式。第二类是随机化关键字，表示每次建立连接时从内置模板中随机选择一个，使长期观察下的握手样式不固定。第三类是留空或填写内核不认识的值，多数内核会退回到标准库实现，相当于没有启用 uTLS。
三类取值各有适用情境。固定浏览器模板适合大多数稳定使用场景，与服务端的 REALITY 配置配合时也最可预期。随机化在某些环境下有助于避免单一特征长期出现，但可能随机到与当前服务端或网络环境不太匹配的模板，带来偶发的握手差异。留空则意味着放弃指纹处理，仅在内核不支持或服务端明确不需要时才合理。
一个常被忽略的细节是：模板名称中出现的浏览器只是样式参照，与你电脑上是否安装该浏览器无关，也不会调用该浏览器。它只是告诉内核“按这个样式组装 ClientHello”。同理，模板名称里若带有操作系统或平台字样，也只是样式差异的标注，不代表仅能在该平台使用。
REALITY 为何把指纹作为前提
REALITY 是 VLESS 生态中的一种传输方案，它让服务端在面对非目标访客时把握手转发给一个真实的第三方网站，用该网站的真实证书完成握手外观，使服务端在外部探测者眼中与一个普通网站无异。这个设计的前提是：客户端发出的 ClientHello 也要像访问该网站的普通浏览器，否则“服务端像网站、客户端不像浏览器”的组合会在握手阶段就显得矛盾。
因此 REALITY 的实现把 uTLS 指纹作为必填项。订阅文件中若传输方案字段为 REALITY，通常会同时给出 fingerprint 取值、目标网站名称、公钥与短标识等参数。客户端需要完整支持这一组参数才能连接，这就要求内核不仅实现了 VLESS，还实现了 REALITY 与 uTLS。关于 VLESS 本身为何把安全交给 TLS 层、以及它与 REALITY 的分工，可以参考 理解 VLESS 为什么不内置加密。
容易混淆的三种“指纹”
讨论这个话题时，有三个名字相近但层面完全不同的概念经常被混在一起。TLS 指纹工作在传输层握手阶段，由 TLS 库决定，描述的是“这条连接由哪一类软件发出”，它对所有经过 TLS 的流量都存在，与你访问什么网站无关。
浏览器指纹工作在应用层，由网页中的脚本收集屏幕分辨率、字体列表、时区、图形渲染结果等环境特征拼合而成，描述的是“这个浏览器环境是否独特”。它只在你打开网页并执行脚本时产生，与代理连接的握手没有关系，开启或关闭 uTLS 都不会改变它。
设备指纹则由操作系统或应用程序从硬件标识、系统配置中采集，用于识别同一台设备。它既不经过 TLS 握手，也不依赖网页脚本，属于另一条独立的链路。
区分这三者的意义在于定位问题：如果你担心的是连接在握手阶段被区分，处理对象是 TLS 指纹；如果担心的是网站识别出同一个浏览器环境，处理对象是浏览器设置与扩展；如果担心的是账号与设备绑定，处理对象是设备层面的策略。把 uTLS 当作解决后两类问题的工具，是一种常见误解。
决策树：我的连接需要处理指纹吗
Decision Path
按订阅与客户端条件判断是否需要核对 TLS 指纹
text
订阅使用的传输方案是否基于 TLS（TLS / REALITY / XTLS 等）？
├─ 否（如纯 Shadowsocks）→ 指纹选项不适用，本文内容可略过
└─ 是 → 继续
├─ 订阅文件是否已给出 fingerprint 字段？
│ ├─ 是 → 核对客户端内核是否支持该取值
│ │ ├─ 支持 → 直接沿用订阅取值
│ │ └─ 不支持或不认识 → 更换支持 uTLS 的客户端，或联系服务方确认替代取值
│ └─ 否 → 继续
│ ├─ 传输方案是否为 REALITY？
│ │ ├─ 是 → 指纹为必填，向服务方索取完整参数
│ │ └─ 否 → 可按客户端文档填一个常见浏览器模板，或暂不填写
└─ 连接是否在握手阶段反复失败？
├─ 是 → 依次排查：内核是否实现 uTLS → 取值是否在支持列表 → 服务端是否要求特定模板
└─ 否 → 当前配置可用，记录取值以便换设备时复用决策树中“更换支持 uTLS 的客户端”这一分支，涉及不同平台客户端内核的差异，可以在 按平台核对客户端内核对 uTLS 与 REALITY 的支持 中找到核对方法；桌面与移动端客户端的总体格局分别见 了解桌面客户端内核的大致分类 与 了解移动端客户端内核的大致分类。
知识图谱：TLS 指纹
实体定义
TLS 指纹是从 TLS 握手首条消息 ClientHello 中提取的字段特征集合，用于区分流量由哪一类 TLS 实现发出。它是流量特征的一种，不包含用户身份、设备序列号或访问内容。uTLS 是允许调用方自定义 ClientHello 字段并内置浏览器模板的 Go 语言 TLS 库分支，是代理内核处理指纹问题的主要工具。
相关概念
上游概念：TLS 握手流程、ClientHello 结构、密码套件、TLS 扩展、GREASE。平行概念：浏览器指纹（基于页面脚本收集的设备与环境特征，属于应用层，与 TLS 指纹不同）、流量识别（更广的特征集合，握手指纹只是其中一维）。下游概念：REALITY（要求客户端指纹与服务端伪装对象匹配）、XTLS Vision（处理传输阶段的包长特征，与握手指纹互补，见 理解 Vision 流控解决的是哪一段特征）。
技术参数
可由用户核对的参数：客户端内核是否实现 uTLS、fingerprint 字段的可用取值列表、订阅文件中给出的取值、传输方案字段是否为 REALITY。不可由用户直接测得的参数：指纹散列值（需要抓包工具与计算方法）。本站不提供的参数：指纹开关对吞吐、延迟的影响数值。
适用场景
需要处理指纹的典型场景：使用 REALITY 传输方案；服务端要求特定模板；希望握手特征与常见浏览器一致。不需要处理的场景：使用不依赖 TLS 握手的协议；客户端内核不支持 uTLS 且服务端不要求；仅在可信局域网中测试。
对比依据
本站比较指纹相关方案只依据公开技术资料对 ClientHello 结构、uTLS 工作方式与 REALITY 设计的描述，不依据任何品牌宣传，不依据未经控制变量的连接成功率统计。品牌层面只呈现资料中的协议标注，指纹与传输方案字段均为待核实。横向对比中协议维度如何处理，见 了解横向对比中协议与传输方案字段的呈现方式。
常见问题指向
“fingerprint 填什么”指向本文取值章节；“REALITY 连不上”指向 按步骤排查 VLESS 连接失败；“流量还有哪些特征”指向流量识别文章；“加密到底发生在哪一层”指向 分清传输加密与端到端加密的边界。
方案关联：客户端内核与品牌资料
TLS 指纹是客户端与服务端配合的结果，它与品牌的关系只能通过两个资料字段间接体现：协议标注与客户端方式。
| 资料字段 | 与指纹话题的关系 | 17 个品牌的资料状态 | 状态 |
|---|---|---|---|
| 协议标注 | 标注 VLESS 表示可能搭配 TLS 类传输方案，但不等于使用 REALITY 或要求指纹 | 12 个品牌标注 VLESS，5 个待核实 | Vendor Data |
| 客户端方式 | 自研客户端的内核是否实现 uTLS 需要单独核对；第三方订阅导入则取决于你所选客户端 | 多数标注“自研客户端+第三方订阅导入” | Vendor Data |
| 传输方案字段 | 直接决定是否需要指纹 | 全部未写明 | 待核实 |
| 指纹取值 | 订阅文件中可能给出 | 全部未写明 | 待核实 |
对于标注 VLESS 且客户端方式含第三方订阅导入的品牌，你可以在拿到订阅文件后，用支持 uTLS 的客户端导入并查看传输方案与指纹字段，再对照客户端文档核对。按协议标注筛选品牌可以从 按协议标注筛选品牌库 开始；每个品牌详情页只呈现资料字段，不会出现任何指纹参数。
优点、限制与风险提示
使用 uTLS 指纹的优点
握手阶段的特征与常见浏览器一致，减少因“通用 Go 程序样式”而被单独区分的可能；与 REALITY 配合时形成完整的握手外观；配置成本低，多数情况下只是一个字段的取值；不改变加密强度，不引入新的安全弱点。
限制
只覆盖握手第一条消息，不处理传输阶段的包长、时序等特征；模板跟随浏览器更新存在滞后，客户端里的模板与真实最新浏览器未必完全一致；依赖客户端内核实现，老客户端、路由器固件与部分自研客户端可能不支持；随机化取值可能带来偶发的握手差异；无法用来改善吞吐或延迟。
风险提示
- 不要为了让握手成功而同时开启跳过证书校验，两者是不同的问题，后者会让 TLS 对中间人攻击的防护失效，详见 理解为什么 allowInsecure 不能作为连接失败的解决办法。
- 不要从非官方渠道下载声称“内置特殊指纹”的改版客户端，指纹模板是公开实现，没有必要为此承担安装包被篡改的风险，核对方法见 核对客户端安装包来源与完整性。
- 指纹配置属于客户端侧设置，与品牌服务质量无关；连接问题不能仅凭指纹选项判断责任方，排查顺序应是内核支持、取值合法、服务端要求三步。
- 本站所有品牌的传输方案与指纹字段均为待核实，任何关于“某品牌使用 REALITY”的说法在未核对订阅文件前都不应作为选型依据，核对方法见 把待核实字段列入下单前的确认清单。
常见问题
TLS 指纹到底是什么？
TLS 指纹是从 TLS 握手第一条消息 ClientHello 中提取出来的一组特征，包括支持的协议版本、密码套件列表及其顺序、扩展列表及其顺序、椭圆曲线与签名算法偏好等。这些字段由客户端的 TLS 库决定，同一个库生成的 ClientHello 高度一致，因此可以被归纳成一个可比对的特征串，用来区分流量来自哪一类软件。
为什么同样是 TLS，代理客户端和浏览器的指纹会不一样？
因为它们使用的 TLS 库不同。浏览器使用自己维护的 TLS 实现，而多数代理内核用 Go 语言编写，默认使用 Go 标准库的 TLS。两套实现对密码套件的排序、启用的扩展、GREASE 占位值的使用方式都不同，导致 ClientHello 字节布局不同。即使外层域名、证书、端口完全一样，握手的第一条消息已经暴露了发出方不是浏览器。
uTLS 是怎么解决这个问题的？
uTLS 是对 Go 标准库 TLS 的一个分支，允许调用方自行指定 ClientHello 的字段内容与顺序，并内置了一批按主流浏览器样式整理的预设模板。代理内核接入 uTLS 后，可以在发出握手时套用某个浏览器模板，使 ClientHello 在密码套件、扩展顺序等维度上与该浏览器一致，从而让握手阶段的指纹不再显示为通用 Go 程序。
客户端里的 fingerprint 选项填什么？
该选项通常填一个浏览器名称或随机化关键字，表示 uTLS 套用哪一套模板。常见取值是主流浏览器的名字，以及表示每次连接随机选择模板的随机化选项。具体可填的值取决于你的客户端内核版本，应以客户端文档为准。如果订阅已经写明了该字段，一般直接沿用；如果留空，多数内核会退回到自身默认的 TLS 实现。
指纹模拟会让连接更快吗？
不会。uTLS 只改变握手第一条消息的字段布局，不改变加密算法的实际运算量、不改变线路、也不改变服务端处理速度。它解决的是握手特征是否显得异常的问题，与吞吐和延迟没有直接关系。如果开启指纹后连接体验有变化，更可能是因为握手成功率变化或服务端策略差异，而不是指纹本身带来的性能差别。
REALITY 和 uTLS 是什么关系？
两者分工不同但经常一起出现。uTLS 负责让客户端发出的 ClientHello 像浏览器；REALITY 负责让服务端对非目标访客的回应像一个真实的第三方网站，并用真实网站的证书完成握手外观。REALITY 的实现要求客户端使用 uTLS 指纹，因为如果 ClientHello 仍是通用 Go 程序的样式，服务端伪装成真实网站就失去了意义。
随机指纹和固定浏览器指纹哪个更合理？
两种取值解决的问题不同。固定浏览器指纹让你的流量与一类常见客户端一致，适合大多数稳定使用场景；随机化则让每次连接的模板不同，避免长时间呈现单一特征，但也可能随机到与当前环境不匹配的模板，需要承担偶发握手差异。多数情况下沿用订阅给出的取值即可，若遇到握手阶段频繁失败，可在固定与随机之间切换排查。
指纹选项填错会有什么表现？
常见表现是连接在握手阶段就被服务端断开，或连上后很快被重置，而配置中的地址、端口、UUID 都没有问题。另一种表现是客户端日志提示不认识的指纹名称并退回默认实现。排查时先核对客户端内核是否实现了 uTLS、再核对取值是否在该内核支持的列表中，最后与订阅提供方核对服务端是否要求特定指纹。
我怎么确认自己的客户端有没有在用 uTLS？
最直接的方式是查看客户端文档或内核的公开说明，确认 TLS 设置中是否存在 fingerprint 或等价字段，以及是否列出了可用的模板名称。其次可以查看客户端运行日志，启用 uTLS 的内核通常会在连接日志里写明使用的指纹模板。本站不提供任何客户端的版本号或菜单路径，这类细节变化很快，应以你当前安装的版本为准。
服务端能看到我用的是哪种指纹吗？
服务端能看到完整的 ClientHello，因此可以计算出与中间观察者相同的指纹。代理服务端本来就是通信的一端，看到握手参数是正常的。需要注意的是，TLS 指纹只描述握手消息的样式，不包含你的身份信息、设备序列号或访问内容，它与浏览器指纹、设备指纹是不同层面的概念。
品牌资料里有写指纹相关参数吗？
没有。本站 17 个品牌的资料只包含协议标注与客户端方式两项与此话题相关的字段，没有任何品牌写明 uTLS 指纹、REALITY 或其他传输层参数，这些均为待核实。标注 VLESS 的品牌不等于使用 REALITY 或要求 uTLS 指纹，具体参数只能在拿到订阅文件后对照客户端文档核对。
下一步
理解指纹之后，下一步通常是确认自己的客户端内核能否完整支持订阅里的传输方案。客户端总览见 从客户端总览进入你所用平台的内核说明；如果你还在选型阶段，协议只是众多维度之一，完整的选型步骤见 回到选型流程看协议与客户端如何进入清单，不同协议组合该如何取舍见 按设备与环境选择协议组合。
Cluster · security
安全与隐私
- TLS 指纹与 uTLS：客户端指纹为何影响连接什么是 TLS 指纹，为什么客户端需要模拟浏览器指纹？
- 代理流量的加密层次：传输加密与端到端加密的区别使用代理后流量在哪些环节是加密的？
- DNS 泄露是什么：检测方法与客户端设置什么是 DNS 泄露，如何检测和避免？
- WebRTC 泄露与浏览器设置WebRTC 泄露是怎么发生的，浏览器怎么设置？
- 跳过证书校验（allowInsecure）的风险为什么不建议开启跳过证书校验？
- 客户端从哪里下载：来源校验与签名检查如何确认下载的代理客户端是安全的？
- 流量特征与识别：协议伪装的原理与边界代理流量为什么可能被识别，伪装能做到什么程度？
信息来源与更新日期
- 信息来源：通用技术资料（TLS 握手流程、ClientHello 结构、JA3 类指纹归纳方法、uTLS 项目公开说明、REALITY 设计说明中所述公认原理）；品牌公开资料/用户提供清单（协议标注、客户端方式）。
- 数据状态：全部品牌为 Vendor Data，测速 Not Tested，传输方案与指纹字段全部待核实。
- 数据核实日期：2026-10-18。
- 最近更新时间：2026-10-18。
- 本页不构成推荐，不承诺任何平台的收录或排名；客户端功能与品牌参数如有变更，以各自官方信息为准。