TUIC 协议是什么？QUIC 系代理协议的特点

梯子岛编辑部 · 更新于

协议新一代协议难度：高级约 10 分钟读完

先说结论

TUIC 协议是一份转发 TCP 与 UDP 流量的代理协议规范，主要设计在 QUIC 之上使用。协议仓库不带官方实现，能不能用取决于客户端内核是否内置，不同协议版本之间还不保证兼容。

TUIC 资料卡核验于 2026-10-09

来历
协议仓库 github.com/tuic-protocol/tuic（GPLv3；README 称协议概念不受授权限制、不注册商标不申请专利）。最初由 EAimTY 开发；其 2025-02-22 的博客写明项目转入 TUIC Protocol 组织、仓库只保留规范与文档、不再有“官方”实现。
传输与加密
依赖可多路复用的 TLS 加密流，主要用于 QUIC。认证命令带 UUID 与 32 字节 token，由 TLS 密钥材料导出器（RFC 5705）以 UUID、密码导出；命令含 Connect、Packet 等。
官方文档写明支持的内核
Mihomo、sing-box、shoes、Itsusinn/tuic、ClashRS、dae、Egern、Shadowrocket、Stash、Surge
相关 RFC
RFC 5705、RFC 3489、RFC 9000

站内收录的客户端里，文档写明支持 TUIC 的

完整对照见协议 × 客户端支持矩阵。

tuic-protocol/tuic 仓库TUIC 协议规范（SPEC.md）EAimTY 博客：重启 TUIC 的开发sing-box 文档：TUICMihomo 文档：TUIC

这张卡片的资料来源（9 条）
  1. README：协议目标、不含官方实现、最新协议版本 0x05、版本间不保证兼容、服务端与客户端实现列表、GPLv3 与协议不受授权限制（github.com）
  2. SPEC：依赖可多路复用的 TLS 加密流、主要为 QUIC 设计；命令类型；认证 token 通过 TLS Keying Material Exporter 导出；UDP 关联 ID 实现 0-RTT Full Cone 转发（github.com）
  3. EAimTY 博客（2025-02-22）：作者主导了 TUIC 的设计与开发，项目迁入 TUIC Protocol 组织，仓库只保留规范与文档（www.eaimty.com）
  4. sing-box 文档含 TUIC 出站，udp_relay_mode 有 native 与 quic，拥塞控制可选 cubic/new_reno/bbr（sing-box.sagernet.org）
  5. Mihomo 文档含 tuic 代理类型；客户端 QUIC 0-RTT 可缩短建连但可能增加重放风险（wiki.metacubex.one）
  6. RFC 5705：TLS 密钥材料导出器（SPEC 引用）（www.rfc-editor.org）
  7. RFC 3489：STUN（README 以其 5 节引用 Full Cone 定义）（www.rfc-editor.org）
  8. RFC 9000：QUIC 传输协议（TUIC 所依托的传输）（www.rfc-editor.org）
  9. Xray 出站协议列表为 blackhole、dns、freedom、http、loopback、shadowsocks、socks、trojan、vless、vmess、hysteria、wireguard，不含 TUIC（xtls.github.io）
本文要点
  1. TUIC 协议的来历：规范和实现是分开的
  2. 为什么说它是 QUIC 系：流、数据报与连接迁移
  3. UDP 转发、拥塞控制与 0-RTT：节点里几个可选项
  4. tuic节点里有什么，怎么读
  5. tuic客户端怎么判断：先看内核，再看界面
  6. TUIC 与 Hysteria2：两种 QUIC 系协议怎么取舍
  7. 导入 TUIC 节点后，怎么自己确认它在工作
  8. 下一步：按手里的东西选一条路

TUIC 协议不是一款软件，而是一份规范：它规定了怎样转发 TCP 和 UDP 流量，主要设计在 QUIC 之上使用。规范写出的目标很具体，包括 0-RTT 转发、兼容 Full Cone NAT 的 UDP，以及同时支持有损和无损两种 UDP 转发。订阅里的 tuic节点，是某个内核按这份规范实现出来的连接方式。下面依据官方仓库和内核文档，讲它的来历、几个关键设计、客户端怎么判断，以及它和 Hysteria2 的取舍。

TUIC 协议的来历：规范和实现是分开的

协议仓库是 tuic-protocol/tuic，里面放的是规范文档 SPEC.md。README 说明，协议的概念不受授权限制，也不注册商标、不申请专利。TUIC 最初由 EAimTY 开发，他在 自己的博客 里写明：项目已转入 TUIC Protocol 组织，仓库只保留规范与文档，不再有“官方”实现。

这件事决定了你该怎么找资料。几个常见的误会，对照着看：

容易产生的想法 资料里的实际情况
搜到 TUIC 就能下到官方客户端 仓库只有规范与文档，实现由第三方提供
仓库页面就是下载页 它是规范仓库，要用 TUIC，应去具体客户端的官方入口，见 下载导航
所有 tuic 节点互相兼容 README 写明，不同协议版本之间不保证兼容
各软件的实现完全一样 README 列出的实现包括 Mihomo、sing-box、shoes 和 Itsusinn/tuic，逐一的互通说明没有查到，资料待核实

为什么说它是 QUIC 系：流、数据报与连接迁移

SPEC 写明，TUIC 依赖一条可多路复用的 TLS 加密流，主要为 QUIC 设计，同时声明协议并不关心底层传输是什么。QUIC 本身由 RFC 9000 定义，摘要里的要点是：带流控的流、低延迟建连、网络路径迁移；数据包承载于 UDP 数据报，TLS 握手也整合在里面。

放进 TUIC 协议的设计里，大致是下面这张表：

部件 规范与 README 的写法 对使用者的意义
传输 主要在 QUIC 之上使用 从设备到服务器的路径要放行 UDP
TCP 流量 每个连接占一条双向流 网页、下载这类流量不用额外设置
UDP 流量 客户端生成关联 ID 来同步会话，实现 0-RTT 的 Full Cone 转发 UDP 类程序有被转发的可能，实际表现自己验证
认证 认证命令带 UUID 和 32 字节 token，token 用 TLS 密钥材料导出器（RFC 5705）以 UUID、密码导出 UUID 与密码都要同服务端一致，缺一个 token 就对不上
连接特性 README 称借助 QUIC 的用户态拥塞控制、流多路复用与连接迁移 这是设计目标，不是测试结论

最后一行是项目自己的说法。梯子岛没有任何自己的测速、延迟数据，既不能证实，也不能反驳。能确定的只有一条推论：QUIC 数据包走 UDP，所以路径上只要有一段不放行 UDP，这类节点就有连不上的可能。词典里的 QUIC 对这个概念有简短解释。

UDP 转发、拥塞控制与 0-RTT：节点里几个可选项

TUIC 节点里有三项常被忽略的选项：UDP 怎么转、用哪种拥塞控制算法、要不要开 0-RTT。三项都有文档可查，先看 UDP。

UDP 怎么转发：native 与 quic 两种中继模式

TUIC 把 UDP 转发写成两个需求：兼容 Full Cone NAT，并且有损、无损两种方式都要支持。sing-box 文档 里对应的选项叫 udp_relay_mode：

取值 文档的描述 取舍思路
native 沿用原生 UDP 的特性 保持 UDP 本来的样子，丢了就是丢了
quic 经 QUIC 流做无损转发，有额外开销 要求数据不丢，代价是额外开销

Full Cone 是描述 NAT 映射行为的说法，README 在定义它时引用了 STUN 的早期规范 RFC 3489。放到日常里可以粗略理解为：内网设备对外建立一个 UDP 映射后，外部其他主机也能通过这个映射把包送回来。点对点连接这类程序会在意这一点。你有没有这种需求，取决于你要跑的程序，梯子岛不替你判断。

两种模式没有脱离程序的标准答案。比较的办法是：固定同一个节点、同一个程序，先用 native 用一阵，再换成 quic，各记下自己的感受和出现的问题，不要拿别人的截图当依据。

拥塞控制与 0-RTT：两个容易被忽略的开关

sing-box 的 TUIC 出站文档里，拥塞控制可选 cubic、new_reno、bbr。拥塞控制就是决定发送速率如何随网络状况调整的那套算法，README 提到的“用户态拥塞控制”，在 sing-box 文档里就表现为这个可选项。这一项没有对错之分，节点提供方有说明就照说明填，没有说明就保持客户端默认。

0-RTT 则要多留意一点。TUIC 的目标之一就是 0-RTT 转发，而 Mihomo 文档 给出了一条提醒：开启客户端 QUIC 0-RTT 握手可以缩短建连时间，但可能增加重放攻击风险。重放攻击，指的是别人把截获的合法数据原样再发一遍。所以这是一个取舍：

  • 节点说明没有要求时，没有必要为了“听说能更快”就打开。
  • 打开之后出现异常，先关掉再对比，别同时改好几项。
  • 想知道自己的客户端有没有这一项，去看该客户端的官方文档，界面里没有就别硬找。

tuic节点里有什么，怎么读

从规范和两份内核文档倒推，一个 tuic节点 至少会带这些信息：

  • 服务器地址和端口。
  • UUID 和密码，两者共同决定认证用的 token。
  • UDP 中继模式，取值 native 或 quic。
  • 拥塞控制算法，可选项以所用内核的文档为准。
  • 是否启用 0-RTT。
  • TLS 相关设置，因为规范依赖 TLS 加密流。

字段在各个客户端里的叫法不一样，不要照搬别人截图里的填法。链接里每一段的含义，在 节点链接怎么读 里逐项讲；手里有一串链接想拆开看，可以用 节点解析 这个工具。

tuic客户端怎么判断：先看内核，再看界面

“客户端支持 TUIC”同样分两层：内核有没有实现，界面有没有把选项开放出来。先按客户端类型看文档里的线索：

你用的客户端属于 文档里的线索 怎么判断
Clash 系 Mihomo 文档有 tuic 代理类型 确认客户端用的是 Mihomo 内核，见 Mihomo 内核
sing-box 系 sing-box 文档有 TUIC 出站，可设 UDP 中继模式和拥塞控制 见 sing-box 档案
只用 Xray 内核的客户端 Xray 的出站协议列表不含 TUIC 先查它有没有另带别的内核，没有就不适用
iOS 付费客户端 README 的列表里有 Shadowrocket、Stash、Surge 闭源软件，以官方手册和商店页面为准

还有一层容易漏的：协议版本。README 说明不同版本之间不保证兼容，所以“客户端支持 TUIC”并不等于“能连你手里这个节点”。客户端文档没写它实现哪一版的，资料待核实，不要替它补。具体哪款客户端写明支持，查 协议支持矩阵；还没选客户端，先用 客户端选择工具 按平台缩小范围。

TUIC 与 Hysteria2：两种 QUIC 系协议怎么取舍

两者都建立在 QUIC 上，也都依赖 UDP，容易被放在一起问“哪个好”。资料层面能对照的是设计取向：

看点 TUIC Hysteria2
官方实现 仓库只有规范，没有官方实现 有官方实现
与 QUIC 的关系 主要为 QUIC 设计，规范称不关心底层传输 必须建立在标准 QUIC 与不可靠数据报扩展之上
UDP 转发 native 与 quic 两种中继，兼容 Full Cone 用不可靠数据报转发 UDP
速率控制 拥塞控制可选 cubic、new_reno、bbr（sing-box 文档） 客户端认证时声明接收速率
对外形态 规范里没有查到对应说明，资料待核实 服务端同时是标准 HTTP/3 服务器
版本问题 版本间不保证兼容 与 1.x 旧版不兼容

这张表回答“设计上有什么不同”，不回答“谁更快”。后者取决于你的客户端、节点和网络，梯子岛没有数据。想看 Hysteria2 一侧的细节，读 Hysteria2 协议；想看专门的对照，读 Hysteria2 与 TUIC 的区别。

导入 TUIC 节点后，怎么自己确认它在工作

  1. 在节点详情里确认类型显示为 TUIC，没有被转换成别的类型。
  2. 对照上一节，确认客户端内核在文档里有 TUIC。
  3. 检查 UUID 和密码都在，且没有多余的空格或换行。
  4. 向节点提供方确认协议版本，和客户端文档写的版本对一下，对不上就不要继续调参数。
  5. 连上后，用 IP 与 DNS 检测 看出口地区和 DNS 走向。梯子岛只教方法，不提供检测结果。
  6. 连不上时，换一个网络再试同一个节点，例如从家宽换成手机热点。结果不同，说明问题更可能在链路上，这只是判断思路，不是结论。
  7. 仍然不通，按 梯子连不上怎么办 的顺序往下查。

下一步：按手里的东西选一条路

  • 拿到了 tuic 节点：先查 协议支持矩阵，确认你的客户端写明支持。
  • 想读规范原文：去 协议规范导航，那里集中放了各协议的官方资料入口。
  • 订阅里 Hysteria2 与 TUIC 都有，想知道先试哪个：读 代理协议怎么选，按客户端、订阅内容和网络环境倒推。
  • 还没有合适的客户端：去 下载导航 找官方入口，不要在搜索结果里的“下载站”获取。

读完这篇，你应该记住三件事：TUIC 协议是规范不是软件，它依赖 UDP，版本对不上就连不上。

这篇没有覆盖的

  • 各软件对 TUIC 的实现是否完全互通，没有查到逐一的官方说明，这部分资料待核实。
  • 本文没有任何延迟或速度对比，UDP 转发在你的网络里表现如何，只能自己对比。
  • 只讲客户端一侧怎么读节点，服务端部署和证书申请不在本文范围内。

本文引用的官方来源

  1. TUIC（github.com）
  2. TUIC 协议规范（SPEC.md）（github.com）
  3. EAimTY 博客：重启 TUIC 的开发（www.eaimty.com）
  4. sing-box 文档：TUIC（sing-box.sagernet.org）
  5. Mihomo 文档：TUIC（wiki.metacubex.one）
  6. RFC 9000：QUIC（www.rfc-editor.org）

以上链接均为官方页面，梯子岛在 2026-10-09 核对过；个别网站会拦截自动化访问，用浏览器直接打开即可。平台规则可能随时调整，以官方页面当前内容为准。

TUIC 协议常见问题

TUIC 是什么协议？

TUIC 是一套转发 TCP 和 UDP 流量的代理协议规范，主要设计在 QUIC 之上使用。规范写明的目标包括 0-RTT 转发、UDP 的 Full Cone NAT 兼容，以及同时支持有损和无损两种 UDP 转发。它只是规范，真正跑起来的是各个内核或软件的实现。

TUIC 有官方客户端吗？

没有。协议仓库的作者博客写明，项目转入 TUIC Protocol 组织后，仓库只保留规范与文档，不再有官方实现。README 列出的实现来自 Mihomo、sing-box 等第三方项目，所以想用 TUIC，要去具体客户端的官方入口获取，而不是去协议仓库找安装包。

TUIC 的 UDP 中继模式 native 和 quic 有什么不同？

按 sing-box 文档，native 沿用原生 UDP 的特性，quic 则经 QUIC 流做无损转发，并带来额外开销。哪种更适合你，取决于运行的程序是否允许丢包，官方没有给出统一结论，梯子岛也没有测速数据，建议用同一个程序各试一次。

TUIC 节点连不上，先查什么？

先确认客户端内核有 tuic 类型，再确认 UUID 与密码都和节点一致，然后核对协议版本是否对得上，因为不同版本之间不保证兼容。最后换一个网络再试，因为 QUIC 依赖 UDP，路径上有环节不放行 UDP 时这类节点连不上。

TUIC 的 0-RTT 要不要打开？

Mihomo 文档提示，开启客户端 QUIC 0-RTT 握手可以缩短建连时间，但可能增加重放攻击风险。这是一个取舍，不是必选项。节点说明没有要求时，没有必要为了听说能更快就打开，开了之后出现异常，先关掉再对比。

TUIC 和 Hysteria2 能互相连接吗？

不能。两者是各自独立的协议，认证方式、握手流程和规范都不同，只是都建立在 QUIC 之上。节点是哪种协议，客户端就必须使用对应的类型去连，选错类型填得再对也连不上。

接着读

文中出现的术语

相关专题

接下来去哪儿？

找官方入口去网址导航，想核对仓库和版本看GitHub 项目导航；需要现成的机场，机场目录收了 28 家的价格与线路资料，性价比机场、便宜机场、VPN 机场分别有专项页。