中转机搭建配置全面指南:HAProxy、Nginx、iptables 方案对比
前言:为什么需要中转机和负载均衡
中转机(Relay / Transit)在代理场景中扮演着流量枢纽的角色。将一台带宽大、线路好的机器作为入口,把接收到的流量按特定规则分发给背后的多台落地机,核心目的是解决单点故障和资源利用率问题。
为什么要做负载均衡?
- 流量与带宽聚合:当落地机流量配额有限(比如每台 500G),通过多台聚合可以跑满中转机的大流量(比如 3T),避免浪费。
- 高可用(防失联):当某台落地机 IP 被封、宕机或流量耗尽时,中转机自动将其剔除,流量无缝切换到其他存活的落地机上,客户端无感知。
本文聚焦三种主流的中转转发方案——HAProxy、Nginx Stream 模块、iptables,逐一给出完整的配置教程,并在最后做横向对比和场景推荐。
重要概念:理解中转机端口与落地机端口
开始阅读前,先理清中转架构中两个关键端口的区别:
- 中转机端口:中转机上监听的端口,客户端直接连接这个端口。比如下文中的
8080、10521(TCP)、10522(UDP)。 - 落地机端口:落地机上代理服务真实运行的端口。比如下文例子中的
8388、443。这个数字取决于你的落地机上跑的是什么服务:- 如果落地机跑的是 Hysteria2,默认端口是
443 - 如果落地机跑的是 VLESS-Reality,默认端口是
443 - 如果落地机跑的是 Shadowsocks,常见端口是
8388 - 如果落地机跑的是 Trojan,常见端口是
443
- 如果落地机跑的是 Hysteria2,默认端口是
中转机的工作就是:客户端连接中转机的端口 → 中转机原封不动转给落地机的端口。 下文配置中出现的 8388、443、19527 都只是示例,实际使用时必须替换成你落地机上代理服务的真实端口。
方案一: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 连接去连落地机。这就导致:
- 客户端以为自己在和落地机通信,但实际上 TCP 握手在 HAProxy 就断了
- TCP-Brutal 算法的端到端测量被 HAProxy 截断,算法退化
- 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 -vNginx 的 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 ok 和 test 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 连接去连落地机。这就导致:
- 客户端以为自己在和落地机通信,但实际上 TCP 握手在 HAProxy 就断了
- TCP-Brutal 算法的端到端测量被 HAProxy 截断,算法退化
- 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 ACCEPTUDP 转发(适用于 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_bbrBBR 仅针对 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
- 混合场景 → 组合使用,各取所长
理解每种工具的原理和边界,就能做出最合理的技术选型。