中转机搭建配置全面指南:HAProxy、Nginx、iptables 方案对比

详细对比 HAProxy、Nginx Stream 模块和 iptables 三种中转机转发方案,提供完整配置教程、横向对比表和场景推荐

中转机搭建配置全面指南:HAProxy、Nginx、iptables 方案对比

前言:为什么需要中转机和负载均衡

中转机(Relay / Transit)在代理场景中扮演着流量枢纽的角色。将一台带宽大、线路好的机器作为入口,把接收到的流量按特定规则分发给背后的多台落地机,核心目的是解决单点故障资源利用率问题。

为什么要做负载均衡?

  • 流量与带宽聚合:当落地机流量配额有限(比如每台 500G),通过多台聚合可以跑满中转机的大流量(比如 3T),避免浪费。
  • 高可用(防失联):当某台落地机 IP 被封、宕机或流量耗尽时,中转机自动将其剔除,流量无缝切换到其他存活的落地机上,客户端无感知。

本文聚焦三种主流的中转转发方案——HAProxyNginx Stream 模块iptables,逐一给出完整的配置教程,并在最后做横向对比和场景推荐。


重要概念:理解中转机端口与落地机端口

开始阅读前,先理清中转架构中两个关键端口的区别:

  • 中转机端口:中转机上监听的端口,客户端直接连接这个端口。比如下文中的 808010521(TCP)、10522(UDP)。
  • 落地机端口:落地机上代理服务真实运行的端口。比如下文例子中的 8388443这个数字取决于你的落地机上跑的是什么服务
    • 如果落地机跑的是 Hysteria2,默认端口是 443
    • 如果落地机跑的是 VLESS-Reality,默认端口是 443
    • 如果落地机跑的是 Shadowsocks,常见端口是 8388
    • 如果落地机跑的是 Trojan,常见端口是 443

中转机的工作就是:客户端连接中转机的端口 → 中转机原封不动转给落地机的端口。 下文配置中出现的 838844319527 都只是示例,实际使用时必须替换成你落地机上代理服务的真实端口。


方案一:HAProxy(专业四层负载均衡器)

HAProxy 是业界标准的 TCP/HTTP 负载均衡器,原生健康检查、自动剔除故障节点、Web 流量面板一应俱全,适合对高可用要求严格的场景。

安装

apt update
apt install haproxy -y

完整配置

将以下内容写入 /etc/haproxy/haproxy.cfg(注意替换为你真实的落地机 IP 和端口):

# /etc/haproxy/haproxy.cfg

global
  maxconn 51200      # 全局最大连接数,确保高并发不瓶颈
  daemon             # 后台守护进程运行

defaults
  mode    tcp        # 默认模式设为纯 TCP 四层转发
  option  tcplog
  timeout connect 5s
  timeout client  10m
  timeout server  10m

# 核心:中转机代理端口与落地机负载均衡池
listen proxy_relay
  bind *:8080          # 中转机对外暴露的监听端口
  mode tcp
  balance roundrobin   # 负载均衡策略:轮询

  # 落地机节点列表(替换为你真实的落地机 IP 和端口)
  # check:开启主动健康检查
  # inter 5s:每 5 秒检查一次
  # rise 2:成功 2 次认为节点恢复正常
  # fall 3:失败 3 次认为节点宕机并自动剔除
  server node1 1.1.1.1:8388 check inter 5s rise 2 fall 3 weight 1  # 落地机1:IP 和代理服务端口
  server node2 2.2.2.2:8388 check inter 5s rise 2 fall 3 weight 1  # 落地机2:IP 和代理服务端口

# 可视化 Web 监控面板(强烈推荐)
listen stats
  bind *:8888
  mode http
  stats enable
  stats hide-version
  stats uri /stats              # 访问路径:http://中转机IP:8888/stats
  stats auth admin:admin123     # 面板登录账号密码(请修改)

落地机协议兼容性

HAProxy 在 mode tcp 模式下对后端协议完全透明——它只做 TCP 字节流的搬运,不关心上层跑的是什么协议。所以:

落地机协议 能否通过 HAProxy 中转 说明
Shadowsocks (TCP) ✔ 完全支持 SS 的 TCP 加密通道原样透传
VLESS (TCP) ✔ 完全支持 VLESS 基于 TCP,正常转发
Trojan ✔ 完全支持 Trojan 就是 TLS 包裹的 HTTP,正常转发
VMess (TCP) ✔ 完全支持 VMess 基于 TCP,正常转发
Hysteria / Hysteria2 不支持 Hysteria 基于 QUIC/UDP,HAProxy 的 mode tcp 不处理 UDP
WireGuard 不支持 纯 UDP 协议
TCP-Brutal ⚠️ 能转发,但失去了意义 见下方详细解释

关于 TCP-Brutal 为什么不建议用 HAProxy 转发:

TCP-Brutal 不是一种独立的协议,而是运行在客户端和落地机之间的一种拥塞控制算法。它的核心机制是让客户端直接测量到落地机的网络延迟和丢包率,然后"野蛮"地发包来榨干带宽。

HAProxy 在 mode tcp 下会终结来自客户端的 TCP 连接,再新建一个 TCP 连接去连落地机。这就导致:

  1. 客户端以为自己在和落地机通信,但实际上 TCP 握手在 HAProxy 就断了
  2. TCP-Brutal 算法的端到端测量被 HAProxy 截断,算法退化
  3. HAProxy → 落地机这一段走的是系统默认的 TCP 栈(CUBIC/BBR),不是 Brutal

这就是前面方案三(iptables)里强调的"端到端状态保留"。如果你的落地机跑了 TCP-Brutal,需要用 iptables 做内核级直通转发,不能用 HAProxy 或 Nginx。 这正是文章方案对比表里"端到端状态保留"那行对比的含义。

如果落地机上跑的只是普通的 Shadowsocks / VLESS / Trojan,不加 Brutal 算法,那用 HAProxy 完全没有问题。

启动与验证

systemctl restart haproxy
systemctl enable haproxy
ss -tulnp | grep haproxy       # 确认 8080 和 8888 端口在监听

打开浏览器访问 http://中转机IP:8888/stats,输入账号密码即可看到节点状态面板。

关于 Web 面板的常见疑问:这个 stats 面板是监控仪表盘——绿条表示节点在线,红条表示节点挂了,可以看流量曲线和连接数统计。它不是像宝塔面板那样的管理后台,不支持在网页上新增或修改落地机的 IP 和端口。

落地机的信息必须在 /etc/haproxy/haproxy.cfg 里提前写死,改完后执行 systemctl reload haproxy 生效。

这也是为什么前面方案对比表中,iptables 的缺点写着"无健康检查"——HAProxy 需要你把落地机列表写在配置文件里,它才能逐一发送探测包做健康检查。而 iptables 的 NAT 规则里根本没有"节点列表"和"探活"的概念,落地机挂了它仍然盲目转发。两种工具解决问题的层级不同,理解这一点就明白为什么"越简单的方案越需要在其他方面做取舍"。

如果你确实需要动态增删节点又不想改配置重启,HAProxy 提供了 Runtime API(通过 Unix socket),可以用 haproxy-runtime-api 工具在运行时启用/禁用节点。但对于中转机这种配置基本不变的场景,改配置 + reload 是最简单稳定的做法。

优缺点

优势 不足
健康检查与自动剔除,高可用能力强 原生不支持 UDP 转发(如需 UDP 需额外配置层)
自带 Web 面板,排障方便 多一个系统进程,资源略有占用
支持多种均衡策略(轮询、加权、IP Hash) 配置相对重量,功能对纯转发场景有冗余
社区成熟,文档丰富

方案二:Nginx Stream 模块(Web 服务器复用方案)

如果你的中转机上本来就跑着 Nginx 做其他 Web 服务,直接用 Stream 模块做四层转发是最省事的方案——无需额外进程。

Nginx 的 stream 模块需要在 nginx.conf 的最外层(http {} 块之外)配置。

第一步:安装 Nginx

Nginx 默认不包含 stream 模块,需要用完整版 nginx 包:

apt update
apt install nginx -y

# 验证安装是否成功
nginx -v

Nginx 的 stream 模块已内置在官方 nginx 包中,无需单独安装。如果系统提示找不到 stream 模块,说明你装的是精简版,需要换成完整版:apt install nginx-full -y

第二步:确认内核开启 IP 转发(TCP/UDP 都需要)

# 查看当前是否已开启
sysctl net.ipv4.ip_forward

# 如果输出是 net.ipv4.ip_forward = 0,则需要开启
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
sysctl -p

第三步:编辑配置文件

Nginx 的主配置文件是 /etc/nginx/nginx.conf。stream 配置必须写在 http {} 块之外(即 events {} 块之后、文件末尾)。

场景 A:单节点 TCP + UDP 独立转发

如果只转发给一台落地机,不需要负载均衡:

# /etc/nginx/nginx.conf —— 在文件末尾添加以下内容

stream {
  # 转发 TCP 到落地机(如 VLESS、Trojan、Shadowsocks)
  server {
    listen 10521;                    # 中转机暴露的 TCP 端口
    proxy_pass 1.1.1.1:8388;        # 替换为你的落地机 IP 和代理端口
  }

  # 转发 UDP 到落地机(如 Hysteria2)
  server {
    listen 10522 udp;                # 必须加 udp 关键字
    proxy_pass 1.1.1.1:443;         # 替换为你的落地机 IP 和 Hysteria 端口
  }
}

场景 B:TCP 负载均衡(多台落地机)

stream {
  # 定义上游节点池
  upstream proxy_nodes {
    server 1.1.1.1:8388 weight=1 max_fails=3 fail_timeout=30s;  # 落地机1
    server 2.2.2.2:8388 weight=1 max_fails=3 fail_timeout=30s;  # 落地机2
  }

  # 中转机监听端口
  server {
    listen 8080;                     # 客户端连接这个端口
    proxy_pass proxy_nodes;          # 转发到上面定义的节点池
    proxy_timeout 10m;
    proxy_connect_timeout 5s;
  }
}

场景 C:UDP 负载均衡(多台 Hysteria 落地机)

stream {
  upstream hysteria_nodes {
    server 1.1.1.1:443 weight=1;     # 落地机1
    server 2.2.2.2:443 weight=1;     # 落地机2
  }

  server {
    listen 10521 udp;                # 对外暴露 UDP 端口
    proxy_pass hysteria_nodes;
    proxy_timeout 5m;                # UDP 会话保持时间
  }
}

初次配置的建议:先按场景 A 做最简单的单节点转发,测试通了再扩展为负载均衡。

第四步:验证配置语法

修改配置文件后,一定要先检查语法,避免重启失败导致服务中断:

nginx -t

如果输出 syntax is oktest is successful,说明配置没问题。

第五步:启动 Nginx 并设置开机自启

# 首次启动
systemctl start nginx
systemctl enable nginx

# 后续修改配置后重新加载(比 restart 更优雅,不中断已有连接)
systemctl reload nginx

第六步:验证转发是否生效

# 查看端口是否在监听
ss -tulnp | grep nginx

# 查看 Nginx 运行状态
systemctl status nginx

# 查看实时日志(转发异常的排查入口)
tail -f /var/log/nginx/error.log

如何切换方案(卸载 Nginx)

如果后续想改用 iptables,可以安全卸载:

systemctl stop nginx
systemctl disable nginx
apt remove --purge nginx nginx-common -y

落地机协议兼容性

HAProxy 在 mode tcp 模式下对后端协议完全透明——它只做 TCP 字节流的搬运,不关心上层跑的是什么协议。所以:

落地机协议 能否通过 HAProxy 中转 说明
Shadowsocks (TCP) ✔ 完全支持 SS 的 TCP 加密通道原样透传
VLESS (TCP) ✔ 完全支持 VLESS 基于 TCP,正常转发
Trojan ✔ 完全支持 Trojan 就是 TLS 包裹的 HTTP,正常转发
VMess (TCP) ✔ 完全支持 VMess 基于 TCP,正常转发
Hysteria / Hysteria2 不支持 Hysteria 基于 QUIC/UDP,HAProxy 的 mode tcp 不处理 UDP
WireGuard 不支持 纯 UDP 协议
TCP-Brutal ⚠️ 能转发,但失去了意义 见下方详细解释

关于 TCP-Brutal 为什么不建议用 HAProxy 转发:

TCP-Brutal 不是一种独立的协议,而是运行在客户端和落地机之间的一种拥塞控制算法。它的核心机制是让客户端直接测量到落地机的网络延迟和丢包率,然后"野蛮"地发包来榨干带宽。

HAProxy 在 mode tcp 下会终结来自客户端的 TCP 连接,再新建一个 TCP 连接去连落地机。这就导致:

  1. 客户端以为自己在和落地机通信,但实际上 TCP 握手在 HAProxy 就断了
  2. TCP-Brutal 算法的端到端测量被 HAProxy 截断,算法退化
  3. HAProxy → 落地机这一段走的是系统默认的 TCP 栈(CUBIC/BBR),不是 Brutal

这就是前面方案三(iptables)里强调的"端到端状态保留"。如果你的落地机跑了 TCP-Brutal,需要用 iptables 做内核级直通转发,不能用 HAProxy 或 Nginx。 这正是文章方案对比表里"端到端状态保留"那行对比的含义。

如果落地机上跑的只是普通的 Shadowsocks / VLESS / Trojan,不加 Brutal 算法,那用 HAProxy 完全没有问题。

启动与验证

systemctl restart nginx
systemctl enable nginx
ss -tulnp | grep nginx

优缺点

优势 不足
TCP/UDP 双栈原生支持 无内置健康检查面板(需依赖第三方监控)
可复用已有 Nginx 进程,资源零增加 故障剔除能力弱于 HAProxy(依赖 max_fails 被动检测)
支持 SNI 分流(七层域名路由) 配置语法对新手有一定门槛
生态广泛,插件丰富

方案三:iptables(内核级直通转发)

iptables 工作在 Linux 内核网络层,不拆包、不代理,只做纯粹的地址重写(DNAT)。流量直接从内核态转发到落地机,零应用层开销

最适合的场景:使用 TCP-Brutal 等依赖端到端拥塞控制算法时,iptables 不干预 TCP 状态,算法能直接感知客户端真实网络状况。

第一步:确认 iptables 是否已安装

大多数 Linux 发行版默认已安装 iptables。检查方法:

iptables --version

如果没有安装,用包管理器安装:

# Debian / Ubuntu
apt update
apt install iptables -y

# Alpine
apk add iptables

第二步:开启内核 IP 转发(必须!新手最容易漏的一步)

iptables 做 NAT 转发需要内核允许 IP 转发,否则规则加上了也不会生效:

# 先查看当前状态
sysctl net.ipv4.ip_forward

# 如果输出 net.ipv4.ip_forward = 0,执行以下命令开启
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
sysctl -p

# 再次验证,应该输出 net.ipv4.ip_forward = 1
sysctl net.ipv4.ip_forward

第三步:添加转发规则

以下命令都是即时生效的,执行完毕转发就开始工作。

TCP 转发(适用于 VLESS、Trojan、Shadowsocks 等 TCP 协议):

# 将中转机 10521 端口的 TCP 流量转到落地机 1.1.1.1 的 8388 端口
# 按你的实际情况替换 IP 和端口
iptables -t nat -A PREROUTING -p tcp --dport 10521 -j DNAT --to-destination 1.1.1.1:8388

# 源地址伪装:确保落地机的回包能回到客户端
iptables -t nat -A POSTROUTING -p tcp -d 1.1.1.1 --dport 8388 -j MASQUERADE

# 防火墙放行转发流量
iptables -A FORWARD -p tcp -d 1.1.1.1 --dport 8388 -j ACCEPT

UDP 转发(适用于 Hysteria2 等 UDP 协议):

# 将中转机 10522 端口的 UDP 流量转到落地机 1.1.1.1 的 443 端口
iptables -t nat -A PREROUTING -p udp --dport 10522 -j DNAT --to-destination 1.1.1.1:443

iptables -t nat -A POSTROUTING -p udp -d 1.1.1.1 --dport 443 -j MASQUERADE

iptables -A FORWARD -p udp -d 1.1.1.1 --dport 443 -j ACCEPT

同时转发 TCP 和 UDP(不常用,如果你搞不清要不要加就跳过):

如果想用一个端口同时转发 TCP 和 UDP 到同一台落地机:

iptables -t nat -A PREROUTING -p tcp --dport 10521 -j DNAT --to-destination 1.1.1.1:8388
iptables -t nat -A PREROUTING -p udp --dport 10521 -j DNAT --to-destination 1.1.1.1:8388
iptables -t nat -A POSTROUTING -p tcp -d 1.1.1.1 --dport 8388 -j MASQUERADE
iptables -t nat -A POSTROUTING -p udp -d 1.1.1.1 --dport 8388 -j MASQUERADE
iptables -A FORWARD -p tcp -d 1.1.1.1 --dport 8388 -j ACCEPT
iptables -A FORWARD -p udp -d 1.1.1.1 --dport 8388 -j ACCEPT

第四步:查看规则是否已添加

# 查看 NAT 转发规则(DNAT 和 SNAT)
iptables -t nat -L -n -v

# 查看过滤规则(FORWARD 放行)
iptables -L -n

# 如果只想看特定端口的规则,用 grep 过滤
iptables -t nat -L -n -v | grep 10521

第一次执行时,你可能看到 nat 表只有 PREROUTING 和 POSTROUTING 链,后面跟着你刚添加的规则,这是正常的。

第五步:持久化规则(防重启丢失)

iptables 规则默认重启后清空,必须持久化保存:

# 安装持久化工具
apt install iptables-persistent -y

安装过程中会弹出一个粉色界面询问"保存当前规则",选择 Yes(是)。

以后每次修改规则后,手动保存:

netfilter-persistent save

端口跳跃(抗 UDP QoS)

如果不希望 Hysteria 的 UDP 流量长期固定在单个端口上引发运营商 QoS 限速,可以把流量分散到大量端口上:

# 将中转机 20000~30000 端口的 UDP 流量全部汇聚到落地机 443 端口
iptables -t nat -A PREROUTING -p udp --dport 20000:30000 -j DNAT --to-destination 1.1.1.1:443
iptables -t nat -A POSTROUTING -p udp -d 1.1.1.1 --dport 443 -j MASQUERADE
iptables -A FORWARD -p udp -d 1.1.1.1 --dport 443 -j ACCEPT

# 保存规则
netfilter-persistent save

客户端(以 sing-box Hysteria2 为例)相应配置:

{
  "type": "hysteria2",
  "server": "中转机IP",
  "server_ports": ["20000-30000"],
  "hop_interval": "30s",
  "password": "your_password",
  "tls": {
    "enabled": true,
    "server_name": "your-domain.com",
    "insecure": true,
    "alpn": ["h3"]
  }
}

重要提示:端口跳跃只适合 UDP,绝对不要对 TCP 做端口跳跃。TCP 是"有状态"的,每次跳跃都要重新三次握手和 TLS 协商,网速会断崖式下跌。TCP 保持固定端口,伪装成正常的 HTTPS 访问才是最安全的。

修改或删除规则的方法

如果填错了 IP 或端口,需要先删除错误的规则再添加新的。

方法一:按行号删除(推荐新手用)

# 先查看规则编号(每行前面会有 num 列)
iptables -t nat -L PREROUTING -n --line-numbers

# 输出示例:
# num  target     prot opt source         destination
# 1    DNAT       tcp  --  0.0.0.0/0      0.0.0.0/0    tcp dpt:10521 to:1.1.1.1:8388

# 删除第 1 条规则
iptables -t nat -D PREROUTING 1

方法二:完全清空所有规则(重头来过)

# 清空 nat 表规则
iptables -t nat -F

# 清空 filter 表规则(注意:这也会删除你手动添加的其他防火墙规则)
iptables -F

# 清空后重新持久化
netfilter-persistent save

特别提醒iptables -F 会清空所有 filter 表规则。如果中转机上有其他重要业务,请不要直接清空,而是按行号逐个删除你添加的转发规则。

常见问题排查

症状 原因 解决方法
添加规则后客户端仍然连不上 忘记开启 IP 转发 执行 sysctl net.ipv4.ip_forward 确认是 1
客户端能连接但很慢或断断续续 中转机防火墙(iptables filter 表)默认 DROP FORWARD 执行 iptables -A FORWARD -j ACCEPT,或确认你的 FORWARD 放行规则已添加
重启后规则丢失 没有持久化 执行 netfilter-persistent save
落地机能收到请求但客户端收不到回包 缺少 SNAT(MASQUERADE)规则 检查 iptables -t nat -L POSTROUTING -n 是否有对应的 MASQUERADE 规则
添加规则时报错 “No chain/target/match by that name” 内核模块未加载 执行 modprobe iptable_nat 后再试

优缺点

优势 不足
内核级直通,延迟最低、吞吐最高 无健康检查——落地机宕机后仍然盲发,客户端直接断网
零应用层进程,不占用 CPU/内存 无法做基于域名(SNI)的分流
TCP-Brutal 端到端拥塞控制完美保留 没有可视化面板,排障需靠终端工具
端口跳跃抗 UDP QoS,配置极简 不适合多节点负载均衡场景(需配合其他工具)

方案横向对比

特性 HAProxy Nginx Stream iptables
工作层级 四层(应用层) 四层(应用层) 三层/四层(内核层)
TCP 转发
UDP 转发 ✗(需额外层)
健康检查 ✔ 主动检测 ✔ 被动(max_fails)
自动故障剔除 ✔(有限)
负载均衡策略 轮询/加权/IP Hash 轮询/加权/IP Hash
端口跳跃
Web 面板 ✔ 内置 ✗(需第三方)
SNI 分流 ✔(七层模式) ✔(需 ngx_stream_ssl_preread)
端到端状态保留 ✗(会终结 TCP) ✗(会终结 TCP) ✔(完全保留)
额外进程开销 可复用
配置复杂度 中等 中等
延迟损耗 接近零

场景推荐

场景一:追求高可用,有多台落地机需要负载均衡

推荐:HAProxy

健康检查 + 自动剔除 + Web 面板,运维体验最好。业务关键链路首选。如果涉及 UDP(如 Hysteria),需要在 HAProxy 前面再加一层 UDP 转发层,或混用其他方案。

场景二:中转机已有 Nginx 服务,只想简单加几个转发端口

推荐:Nginx Stream

不增加任何系统进程,复用现有 Nginx 即可。TCP/UDP 双支持,配置灵活。适合中小规模场景。

场景三:单落地机,追求极致性能和低延迟

推荐:iptables

如果你只有一台或两台落地机,不需要负载均衡,iptables 是最轻量的选择。特别是使用 TCP-Brutal 这类协议时,iptables 的端到端保留无可替代。

场景四:TCP + UDP 混合协议,多落地机需要健康管理

推荐:Nginx Stream + iptables 组合

用 Nginx 做 TCP 负载均衡和健康管理,用 iptables 做 UDP 端口跳跃转发。各取所长。

场景五:海量端口跳跃抗 QoS

推荐:iptables

这是 iptables 的独家能力,HAProxy 和 Nginx 做不到。


附:中转机优化与监控

BBR 拥塞控制(TCP 性能优化)

无论使用哪种方案,BBR 都应作为标配开启:

modprobe tcp_bbr
echo "tcp_bbr" > /etc/modules-load.d/modules.conf 2>/dev/null || echo "tcp_bbr" >> /etc/modules
cat >> /etc/sysctl.conf << 'EOF'
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
EOF
sysctl -p

验证:

sysctl net.ipv4.tcp_congestion_control    # 应输出 bbr
lsmod | grep bbr                           # 应看到 tcp_bbr

BBR 仅针对 TCP 生效。UDP 流量不受 BBR 影响。

网络监控工具

nload——查看整体带宽吞吐:

apt install nload -y
nload
# 界面上下部分分别显示接收/发送流量,重点看 Curr(当前速度)和 Max(历史峰值)
# 按 q 退出

iftop——查看特定端口和 IP 的连接详情:

apt install iftop -y
iftop -n -N -P
# -n 禁止反向解析,-N 禁止端口名解析,-P 显示端口号
# 右侧三列分别为过去 2 秒/10 秒/40 秒平均速度
# 按 q 退出

vnstat——轻量级流量统计(对齐账单周期):

apt install vnstat -y
# 等待 5 分钟收集初始数据后:
vnstat      # 基础汇总
vnstat -d   # 每日统计
vnstat -m   # 每月统计(对齐 3T 等限额)
vnstat -l   # 实时动态(类似 nload 轻量平替)

修改账单日(如每月 15 号):

nano /etc/vnstat.conf   # 修改 MonthRotate 15
systemctl restart vnstat

安全说明:四层中转不影响加密

一个常见的疑虑:中转机会不会降低安全性或增加被封风险?

  • 不会影响加密:无论是 HAProxy 的 mode tcp、Nginx 的 stream 还是 iptables 的 NAT,它们都只做数据包级别的搬运,不解密、不拆包。TLS 握手、证书验证、密钥交换始终在客户端和落地机之间直接完成。
  • 不会增加被墙风险:GFW 看到的是和中转机之间的加密流量,流量特征与直连落地机完全一致。中转机越"透明"越安全。
  • 特殊提醒——国内中转机:如果中转机在中国大陆境内,风险不在于 GFW 识别协议,而在于国内运营商的风控。长期大带宽向单个海外 IP 发送加密流量,可能触发机房审计导致停机。

总结

没有绝对的"最优"方案,只有最适合你场景的选择:

  • 需要高可用和负载均衡HAProxy
  • 需要TCP/UDP 双支持且复用 Web 服务Nginx Stream
  • 追求极致性能和端到端保留iptables
  • 混合场景 → 组合使用,各取所长

理解每种工具的原理和边界,就能做出最合理的技术选型。