玩代理玩久了就会发现，传输方式这东西跟手机系统一样，隔段时间就冒出个新名字。2025 年开年最值得聊的新面孔，就是 XHTTP——它在 2024 年底还叫 SplitHTTP，2025 年初正式改名，老玩家看到两个名字别懵，是同一个东西。一句话概括它的核心想法：把一条代理连接的上行和下行，拆成两个独立的普通 HTTP 请求来走，伪装得像极了你在刷网页。
第一步：先搞懂它在解决什么问题#
之前主流的 WebSocket 传输有个小毛病：它是一条长连接。你的客户端和服务器之间始终连着一根"线"，有数据没数据它都在那儿。从旁观者的角度看，这根长时间不断、还持续有数据流动的连接，多少有点显眼。
XHTTP 的思路很鸡贼：不维持长连接了，改成"有事就发个 HTTP 请求，没事就断开"。上传走一个请求，下载走另一个请求，完事即走。你可以这么类比：以前是打一通两小时不挂的电话（显眼），现在是发微信消息，发完该干嘛干嘛（淹没在人海里）。流量形态越接近普通人的上网行为，就越不容易被盯上。
第二步：它的三板斧优势#
第一板斧是伪装自然。XHTTP 用的是标准 HTTP 语义，请求头、请求路径都可以自定义，看起来和访问一个普通网站没区别。CDN、反向代理这些基础设施对它都毫无压力，套一层 CDN 就跟回家一样顺。
第二板斧是部署省心。不需要 WebSocket 那样专门的握手升级，也不用折腾 gRPC 的特殊配置，服务端就是收 HTTP 请求，哪里都能跑。对自建玩家来说，配置复杂度降了一大截。
第三板斧是上下行分离带来的韧性。上传和下载走不同的请求，一条路出问题不会直接拖死另一条。在网络抖动比较大的环境下，这种设计的体验反而更稳。
第三步：先别急着换——它的使用门槛#
说优点之前先泼盆冷水，省得你兴冲冲去折腾：
- 核心版本要新。XHTTP 是 2025 年初才扶正的新传输，服务端和客户端的核心都得是新版，老版本根本不认这个选项。
- 客户端支持还在铺开。v2rayNG（切换到 Xray 核心）、NekoBox 这类客户端在 2025 年上半年的版本里陆续加入了 XHTTP 选项，sing-box 系当时还没完全跟上，动手前先看你手头客户端的更新日志。
- 机场不一定提供。2025 年初只有少数机场和面板支持 XHTTP 节点，大部分机场的订阅里你还看不到它。买之前先问客服，别自己脑补。
第四步：实战建议（老司机的忠告）#
如果你是新手，我的建议是：别追新。先把 VLESS + WebSocket 或者 REALITY 这套成熟方案跑通，流程熟了再说。新传输方式的生态（教程、排错经验、客户端支持）都需要时间沉淀，第一批吃螃蟹的人多少要踩点坑。
如果你是自建玩家，可以尝鲜，但记住两条铁律：第一，备份好现有能用的配置再动刀；第二，XHTTP 目前最适合的场景是"套 CDN + 追求伪装"，裸连用它属于杀鸡用牛刀。
第五步：两个常见疑问#
XHTTP 套 CDN 会不会更快？ 不一定。套 CDN 主要改善的是"可达性"和"伪装"，速度取决于 CDN 节点离你近不近。离你近的 CDN 能降延迟，离你远的反而更慢。别把 CDN 当加速器，它是隐身衣。
XHTTP 会取代 WebSocket 吗？ 短期内不会。WebSocket 的生态太成熟了，教程、面板、客户端全链路支持，XHTTP 要追上至少需要一两年。更可能的情况是两者长期共存：要兼容选 WS，要伪装选 XHTTP。技术选型永远看场景，不看热度。
传输方式的进化史其实一直在重复同一个逻辑：从 Shadowsocks 到 VMess 到 VLESS，再到今天的 XHTTP，每一代都是在"更快"和"更像正常人"之间找平衡。对这段历史感兴趣的，可以看看 SSR 的兴衰：一代神器的落幕；纠结客户端选哪家的，参考 Clash Meta 与 Clash 的区别；还不知道节点怎么导入的，先读 订阅链接和手动添加节点：哪种适合你。