x-ui面板怎么做中转？Tunnel端口转发和出站链两种做法的区别

发表于 分类于
xui面板里说的中转，常见做法有两种：用Tunnel（dokodemo-door）入站把端口转给落地机，或者在中转机上配出站再用路由规则转发。这篇按3x-ui官方文档和Xray文档讲清两者的区别、各自的限制和怎么选，多节点管理不属于中转。

搜"xui 面板中转"，看到的做法其实不止一种：有的是在中转机上建一个"任意门"入站，有的是配出站再写路由规则，还有人把多节点管理也叫中转。它们解决的是不同的问题。这篇先把几种做法分清，再讲每种适合什么情况。

先说明依据：内容来自 3x-ui（MHSanaei 版）官方中文文档、当前主分支源码里的界面文字，以及 Xray 官方文档的 Tunnel 页面。我没有搭一套中转机加落地机实测，所以不给速度、稳定性方面的结论，也不写某条线路"一定更快"。界面文字在老版本（比如 2.9.4）里可能不同，以你屏幕上的为准。

先分清几个概念

  • 落地机：最终出口的服务器，访问网站时对方看到的是它的 IP。
  • 中转机：夹在你和落地机之间的服务器，常见目的是改善到落地机的线路。
  • 这两台机器上各装一个 3x-ui 面板，是最常见的做法，不过中转机不一定要装面板。

在 3x-ui 里，和"中转"沾边的功能有三类，下面分别讲。

做法一：Tunnel 入站（旧称 dokodemo-door）端口转发

Xray 官方文档对它的描述是：Tunnel，旧称 dokodemo-door（任意门），可以监听数个本地端口，把收到的数据发送到指定服务器的某个端口，达到端口映射的效果。

3x-ui 官方文档的入站协议表里也列了这一项：“Dokodemo-door / Tunnel：端口转发 / 流量重定向”。新版本面板里这个入站的表单字段（来自源码和中文翻译文件）是：

面板字段 对应 Xray 设置 含义
重写地址 rewriteAddress 转发到这个地址，IP 或域名；Xray 文档说默认是 localhost
重写端口 rewritePort 转发到目标地址的这个端口；不填或 0 时，Xray 文档说默认等于监听端口
允许的网络 allowedNetwork tcp、udp 或 tcp,udp；Xray 文档说默认 tcp
端口映射 portMap 监听多个端口时，给不同本地端口指定不同的目标
跟随重定向 followRedirect 用于识别 iptables 转发来的数据，做透明代理用，做中转一般不用

老版本面板的字段名不同。 老教程里写的"目标地址、目标端口"，就是现在的"重写地址、重写端口"，我没有逐版本核对界面。

做法就是：

  1. 先在落地机建好节点，确认客户端直连能用，记下落地机 IP 和节点端口；
  2. 在中转机新建入站，协议选 Tunnel，设置监听端口，重写地址填落地机 IP，重写端口填落地机节点端口；
  3. 如果节点用 UDP（比如 Hysteria2、TUIC），"允许的网络"要包含 UDP，只选 TCP 就转不了；
  4. 在中转机放行监听端口，系统防火墙和服务商安全组都要放；
  5. 客户端：节点其余参数保持落地机的不变，只把连接地址改成中转机、端口改成监听端口。

一个更完整的案例在Vmess+WebSocket 搭建中转服务器里，那篇是老版本界面，字段名对应关系见上表。

这种做法的特点和限制

这些是我从工作方式推出来的，不是官方文档的原话，请当作判断：

  • 它只是把数据转发出去，中转机不理解里面的协议，所以节点的 UUID、传输方式、TLS 或 Reality 参数，全部仍是落地机那一套。客户端只是"连接地址换了"。
  • 节点如果用了 TLS 和域名，客户端的 SNI 和证书校验仍要对应落地机的域名，不能因为连接地址改成了中转机 IP 就改 SNI。Reality 节点同理，参数不动。
  • 落地机上看到的来源 IP 是中转机的 IP，不是你真实的 IP。面板的入站里有"Proxy Protocol"选项，官方翻译里的提示写的是它用来从"上游 L4 隧道或中继（HAProxy、gost、nginx-stream、Xray dokodemo-door）"获取真实客户端 IP，且上游必须发送 PROXY protocol。Xray 的 Tunnel 入站本身能不能发送，我没有核对，不建议只凭这行字就开。

做法二：中转机配出站，再用路由规则转发

这是另一种思路：中转机上有自己的入站，客户端连的是它；中转机再用一个出站去连落地机。3x-ui 官方文档的"出站与路由"一章讲了：入站负责接受客户端，出站决定流量接下来发往何处。其中写道，代理出站（VLESS、VMess、Trojan、Shadowsocks）会转发到另一台服务器，便于链式代理。

要点（都来自官方文档）：

  • 出站、路由规则等都在面板的 Xray 配置里直接编辑 JSON，面板随后重载 Xray；
  • 每个出站要有 tag、protocol、settings，代理协议还要有 streamSettings，必须与远程入站的传输方式和安全设置匹配；
  • 不同协议结构不同：VLESS 是扁平的 address/port/id/flow/encryption，VMess 用 settings.vnext[]，Trojan 和 Shadowsocks 用 settings.servers[]；
  • 路由规则自上而下匹配，第一个匹配的生效，可以用 inboundTag 匹配"哪个入站来的流量"，再指向某个 outboundTag。

路由规则的大致形态如下，relay-in 和 to-landing 是占位的标签名，需要换成你自己的，这只是说明结构的示意，不是可直接粘贴的完整配置：

1
2
3
4
5
6
7
{
  "routing": {
    "rules": [
      { "type": "field", "inboundTag": ["relay-in"], "outboundTag": "to-landing" }
    ]
  }
}

出站本体怎么写，要按落地机节点的协议和传输、安全参数来，官方文档提供了一个出站生成工具；我没有在这里给出具体的出站 JSON，因为它必须与你落地机上的设置逐项一致，抄别人的会配错。面板还提供出站连通性测试和路由测试，配完后可以先用它们看出站通不通、某个目标会走哪个出站。路由规则的整体写法见3x-ui 路由规则配置。

这种做法的特点

  • 客户端连的是中转机自己的入站，节点参数可以和落地机不同，这是和做法一最大的区别；
  • 灵活度更高：可以只让部分流量走落地机，其余直连，也可以给不同用户走不同出站；
  • 代价是配置更复杂，streamSettings 与落地机不一致就连不通，排查成本也更高。

不是中转：多节点管理

3x-ui 官方文档里的"多节点"，指的是一个主控面板通过 API 令牌或 mTLS 管理另一些 3x-ui 面板：集中看状态、版本、CPU/内存、流量，按标签同步入站，并有心跳检测。它解决的是"服务器多了怎么管"，不会把用户的代理流量转发到别的服务器，所以不要把它当成中转。文档里节点还有一个可选的"出站标签"，是用来让主控通过某个出站去访问节点（出口桥接），那是主控和节点之间的连接方式，也不是用户流量的中转。

怎么选

Tunnel 端口转发 出站链
中转机要不要理解协议 不用 要
客户端节点参数 用落地机的，只改地址端口 可以自己定
配置难度 低 较高
灵活性（分流、多出口） 低 高
  • 只想让现有节点绕一下线路：先试做法一，改动最小，出问题也容易回退。
  • 需要分流、多个落地机、不同用户不同出口：用做法二。

两种做法我都没有实测，到底哪条线路更快，只能在你自己的机器上同一时间段对比。

排查：中转之后连不上

按顺序看，这些是通用的网络排查思路，不是官方文档的逻辑：

  1. 不经过中转，客户端直连落地机能用吗？ 直连都不行，问题不在中转。
  2. 中转机的监听端口放行了吗？ 系统防火墙和服务商安全组都要放。
  3. Tunnel 的目标地址和端口填对了吗？ 地址是落地机的，端口是落地机节点的端口，不是面板端口。
  4. 节点是 UDP 协议时，"允许的网络"选了含 UDP 的项吗？
  5. 客户端有没有把 SNI 或 Reality 参数误改成中转机的？
  6. 做法二的话，先用面板的出站连通性测试看出站本身通不通。

相关文章

没有覆盖的

  • iptables、gost、nginx stream、HAProxy 等面板之外的转发工具：这篇只讲 3x-ui 自带的功能，其余没有核对。
  • 中转线路的速度、稳定性对比：没有实测，不下结论。
  • 具体出站 JSON 的完整示例：必须与落地机逐项一致，这里不给。
  • Tunnel 入站是否支持向落地机发送 PROXY protocol：没有核对。
  • 老版本面板的菜单文字：没有逐版本核对。