有些时候，后端服务器上的服务已经搭好了，但出于入口统一、线路优化或者不希望直接暴露后端地址的考虑，通常还会再加一台中转机。中转机负责对外监听端口，再把流量转发到后端服务器，这就是最常见的一种中转方案。

第一次接触这类配置时，最容易混乱的地方通常有几个：中转机和后端机分别负责什么，面板应该装在哪台机器上，S-UI 和 3X-UI 到底怎么配，客户端又该改哪些参数。下面就按安装、配置、排错这条顺序完整写一遍。

一、先弄清楚中转机和后端机的关系

1. 后端机负责真正提供服务

后端服务器就是原本已经部署好服务的那台机器。无论是程序、节点还是其他需要被访问的服务，本质上都还是跑在后端机上。

2. 中转机负责监听并转发

中转机本身不负责真正处理业务，它只做一件事：监听一个对外端口，然后把收到的流量转发到后端服务器指定的地址和端口。

3. 客户端最终连接的是中转机

做完中转以后，客户端连接目标不再是后端服务器，而是中转机的 IP 和监听端口。真正的后端地址，通常只出现在中转规则里。

整个链路可以直接理解成下面这样：

客户端 -> 中转机监听端口 -> 后端服务器目标端口

二、开始前需要准备什么

正式安装之前，建议先准备好下面这些信息。

1. 后端服务器信息

至少要确认：

• 后端服务器 IP 或域名
• 后端服务端口
• 后端服务当前是否正常可用

2. 中转服务器信息

同时也要确认：

• 中转机公网 IP
• 计划开放的监听端口
• 是否有 root 权限或 sudo 权限
• 系统防火墙和云平台安全组是否能放行端口

3. 面板应该安装在哪台机器上

如果你的目的是做中转转发，那么 S-UI 或 3X-UI 应该安装在中转机上，不是后端机。后端机只需要保证服务本身正常运行即可，不一定非要装面板。

三、先确认后端服务是否正常

中转配置之前，一定要先确认后端本身已经是正常可用的状态。因为中转只负责转发，不会帮你修复后端问题。

1. 检查后端端口是否正在监听

在后端服务器上执行：

ss -lntp

如果需要查看 UDP 端口，可以执行：

ss -lnup

如果系统里没有 ss，也可以尝试：

netstat -lntp

重点是确认后端真实服务端口已经启动。

2. 检查后端防火墙和安全组

确认后端服务器允许来自中转机的连接。常见需要检查的地方有：

• 系统防火墙
• 云平台安全组
• 服务自身监听限制

3. 先做一次直连测试

在做中转前，最好先确认客户端直连后端时是正常的。这样后面如果中转失败，就能更容易定位问题到底出在哪一层。

四、安装 S-UI

如果准备使用 S-UI 作为中转面板，可以直接在中转机上执行下面的安装命令：

bash <(curl -Ls https://raw.githubusercontent.com/alireza0/s-ui/master/install.sh)

1. 在中转机上执行安装

通过 SSH 登录到中转机，使用 root 或 sudo 权限执行上面的命令。

安装过程中，一般会要求设置：

• 面板访问端口
• 登录用户名
• 登录密码

不同版本界面可能略有差异，但整体流程基本一致。

2. 安装完成后访问面板

安装完成后，可以通过浏览器访问：

http://中转机IP:面板端口

如果额外配置了 HTTPS，就改成：

https://中转机IP:面板端口

3. 如果面板打不开，先检查这几项

• 面板服务是否已经启动
• 系统防火墙是否放行面板端口
• 云平台安全组是否放行面板端口
• 端口是否被其他程序占用

五、S-UI 中转规则怎么配置

进入中转机的 S-UI 后台以后，就可以开始添加转发规则。

1. 新建一条转发规则

在 S-UI 面板中找到新增规则或新增入站的位置，新建一条规则。

2. 规则类型选择 direct

规则类型选择：

direct

这个类型就是最直接的端口转发方式。

3. 填写关键参数

最核心的参数就是下面这几项：

• 目标地址：后端服务器的 IP 或域名
• 目标端口：后端真实服务端口
• 本地监听端口：中转机对外开放的端口
• 协议类型：按实际情况选择 TCP 或 TCP+UDP

例如：

• 后端地址：backend.example.com
• 后端端口：10010
• 中转监听端口：10011

那么最终的流量路径就是：

客户端 -> 中转机:10011 -> backend.example.com:10010

4. 保存并启用规则

参数填好以后，保存规则并启用。启用成功后，中转机就会开始监听刚才设置的端口。

这时候可以在中转机上执行下面的命令查看监听状态：

ss -lntp

如果涉及 UDP，也可以执行：

ss -lnup

只要能看到对应端口已经在监听，说明规则至少已经被加载起来了。

六、安装 3X-UI

如果准备使用 3X-UI，也是在中转机上安装。安装命令如下：

bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh)

1. 在中转机上执行安装

通过 SSH 登录中转机，使用 root 或 sudo 权限运行安装脚本。

安装过程中一般会要求设置：

• 面板端口
• 管理用户名
• 管理密码
• 部分基础管理参数

2. 安装完成后确认后台可访问

安装完成以后，先保证你能够正常打开管理后台，再继续下一步的中转配置。

3. Debian 11 遇到 GLIBC 报错时的处理方式

如果在 Debian 11 环境下安装 3X-UI 时遇到 GLIBC 版本相关报错，可以先处理依赖环境：

echo "deb http://ftp.debian.org/debian sid main" >> /etc/apt/sources.list
apt-get update
apt-get -t sid install libc6 libc6-dev libc6-dbg

这类操作会动到系统依赖，执行前最好先确认当前环境，避免影响已有软件源配置。

七、3X-UI 怎么做中转转发

3X-UI 的思路和 S-UI 是一样的，只是新增入站时协议类型不同。

1. 登录 3X-UI 面板

进入中转机上的 3X-UI 后台，找到新增入站的位置。

2. 协议选择 dokodemo-door

创建入站时，协议选择：

dokodemo-door

3. 填写关键参数

核心逻辑和 S-UI 相同，重点还是这几项：

• 中转机监听端口
• 目标地址
• 目标端口
• 网络协议类型

可以理解成只是换了一套面板，但本质仍然是让中转机监听端口，再把流量送到后端。

八、客户端怎么修改

这一步其实比安装面板还关键。很多人面板装对了，规则也配了，但客户端改错了，最后一样不通。

1. 改服务器地址

把客户端原本直连后端的地址，改成中转机 IP 或中转机域名。

2. 改服务端口

把客户端原本连接的后端端口，改成中转机监听端口。

3. 其他参数尽量不要动

像协议类型、身份参数、校验信息等，一般还是以后端真实服务为准。因为中转机只是转发，不会替后端重建一整套参数。

例如原本客户端连的是：

backend.example.com:10010

做完中转以后，客户端应该改成：

中转机IP:10011

除了地址和端口，其他核心配置通常保持不变。

九、最常见的排错思路

中转配置失败时，不要一上来就怀疑整套思路有问题，通常只是某一个小环节没有对上。

1. 客户端根本连不上中转机

优先检查：

• 中转机监听端口是否已经启用
• 系统防火墙是否放行该端口
• 云平台安全组是否放行该端口
• 面板规则是否已经成功保存并生效

2. 中转机能通，但后端没反应

优先检查：

• 目标地址是否填写正确
• 目标端口是不是后端真实服务端口
• 中转机到后端的网络是否畅通
• 后端防火墙是否允许来自中转机的连接

3. 原始配置能用，改完中转后不能用

这种情况最常见的原因就是客户端改多了。

最稳妥的做法就是只修改两项：

• 地址改成中转机
• 端口改成中转监听端口

其他关键参数尽量保持原样。

十、补几个实际使用时的注意点

1. 一台中转机可以挂多条规则

如果有多个后端服务，可以在同一台中转机上配置多个不同的监听端口，分别转发到不同的后端。

例如：

• 10011 转到后端 A
• 10012 转到后端 B
• 10013 转到后端 C

这样做的好处是所有入口都集中在同一台中转机上，后续维护会方便很多。

2. 中转机本身也要考虑带宽和稳定性

虽然中转机不处理核心业务，但所有流量都会先经过它，所以它本身依然是链路中的关键节点。如果中转机不稳定，后端再正常也没用。

3. 先跑通一条链路再扩展

最稳妥的方式不是一开始就同时加很多规则，而是：

1. 先确认后端直连可用
2. 先加一条中转规则
3. 先让一个客户端跑通
4. 再慢慢扩展到多端口、多后端