写一个中转服务器，核心就三步：找一台有公网 IP 的机器，选一种四层转发方式（iptables、Nginx stream、HAProxy 或 frp），把规则写对并补上限流与监控。 真正的代码往往不到二十行，难点在选型、带宽成本和上线后的运维细节。
中转服务器在转发什么
中转服务器的本质是一条可控的转发链路,客户端连的是中转机的某个端口，中转机把流量原样交给真实后端，后端响应再沿原路返回。
它工作在传输层,处理的是 TCP/UDP 连接，不改报文内容，协议对它透明，所以同一个端口既能转 HTTP，也能转数据库、游戏联机、SSH。
常见的落地场景有这么几类：
- 后端服务只在某个地域有节点,需要就近出口
- 内网服务要临时暴露给外部访问
- 跨地域调用时线路质量差,需要一条更稳的中间跳板
- 多个后端要做统一入口和故障切换
- 数据库只允许白名单访问,用一台固定的中转机做跳板
先列一张端口表再动手,能省掉大半来回排查，表里至少写清：客户端连哪个 IP 端口、中转机监听哪个端口、后端是谁、协议是 TCP 还是 UDP。
中转服务器怎么搭建：四步跑通最小可用版本
第一步，把网络前提确认清楚
中转机必须有公网 IP，云厂商的安全组和机器内的防火墙要同时放行监听端口，只改一边是最常见的“连不上”原因。
# 确认端口在监听 ss -lntp | grep 8080 # 确认内核转发已打开（用 iptables 方案时必须） sysctl -w net.ipv4.ip_forward=1
第二步，选转发方式
不要一上来就纠结工具,先看需求：只做端口搬运用 iptables 最快；要健康检查和多后端用 Nginx stream；要内网穿透用 frp；要精细的 ACL 和高并发用 HAProxy。
第三步，写出第一条规则
iptables 做端口转发，三行就够：
iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 10.0.0.5:80 iptables -t nat -A POSTROUTING -d 10.0.0.5 -p tcp --dport 80 -j MASQUERADE netfilter-persistent save
Nginx 需要 1.9 以上版本并带 --with-stream 模块：
stream {
upstream backend { server 10.0.0.5:3306; }
server {
listen 3307;
proxy_connect_timeout 5s;
proxy_timeout 300s;
proxy_pass backend;
}
}
临时验证用 socat，一条命令就能测通链路：
socat TCP-LISTEN:8080,fork,reuseaddr TCP:10.0.0.5:80
第四步，从外网真实测一遍
在本机连得通不代表外网通,换一台机器执行 curl -v telnet://中转IP:8080 或用 nc -vz，再抓包确认 SYN 有没有回来。
自建中转服务器需要什么配置
CPU 在中转场景里几乎不是瓶颈，除非你要在中转机上做 TLS 卸载，内存主要吃在并发连接上，1 核 1G 的轻量云服务器，撑住几千个短连接没什么问题。
真正的成本项是带宽,行业共识认为，中转类业务的费用大头在流量和带宽，不在算力，这里有几个容易忽略的点：
- 双向计费：客户端到中转、中转再到后端，很多云厂商两边都算流量，实际消耗是账面数字的两倍
- conntrack 表容量：连接数一多，
nf_conntrack: table full会直接丢包，需要调net.netfilter.nf_conntrack_max - 文件描述符：
ulimit -n和fs.file-max不放开，几千连接就开始报错 - 内核参数：
net.core.somaxconn、net.ipv4.tcp_tw_reuse值得调一遍
系统选型上,Debian 和 Ubuntu Server 的默认内核参数比较保守，改起来文档最多；CentOS 系注意 firewalld 和 iptables 的规则会互相隐藏。
四条技术路线怎么选
| 方案 | 工作层级 | 上手难度 | 多后端与健康检查 | 适合场景 |
|---|---|---|---|---|
| iptables DNAT | 四层 | 低 | 不支持 | 单端口搬运、临时跳板 |
| Nginx stream | 四层 | 中 | 支持基础探测 | 多后端、需要日志 |
| HAProxy | 四层/七层 | 中高 | 支持完善 | 高并发、精细 ACL |
| frp | 四层/七层 | 低 | 有限 | 内网穿透、动态 IP 客户端 |
如果只是“把 A 端口转到 B 机器”，别上 HAProxy，配置维护成本不值，反过来，要做灰度切换和健康检查，iptables 会让你很被动。
中转服务器和正向代理有什么区别
两者经常被混为一谈,实际差别不小。
正向代理是客户端主动告诉代理“我要访问谁”，代理理解应用层协议，可以改请求头、加认证、做缓存，中转服务器多数情况下只是把 TCP 流照搬过去，它不知道也不关心里面跑的是什么。
这带来两个直接后果：
- 中转对协议透明,HTTPS 不需要额外证书，正向代理要处理 CONNECT 或做中间人
- 中转无法按 URL 做鉴权，只能按源 IP、端口做粗粒度控制
需要按用户身份限流时,选能读应用层的方案；只需要通道稳定时，四层转发更省事。
海外中转服务器搭建教程里的三个坑
跨地域链路是这个话题里问题最集中的部分,新手基本都会踩一遍。
线路绕路，机房标称在某个区域，实际回程可能绕了大半个地球，上线前用 mtr 或 traceroute 看回程路径，比看宣传页有用。
拥塞控制算法，长距离高延迟链路上，默认的 CUBIC 表现一般，开 BBR 往往有明显改善：
sysctl -w net.ipv4.tcp_congestion_control=bbr sysctl -w net.core.default_qdisc=fq
MTU 与 MSS，经过隧道或多次封装后，大包会被丢弃，表现为能连上但传大文件卡死，用 ping -M do -s 1472 逐级试探，必要时在转发机上做 MSS clamping。
另外记得配好时间同步,TLS 握手、日志排查、限流窗口都依赖准确的时钟，chronyd 起来只是几十兆内存的事。
中转服务器一年多少钱：把成本拆开看
成本结构其实不复杂,就三块：机器、带宽、附加服务。
- 入门级轻量云服务器,多数在每月几十元区间，年付通常有折扣
- 固定带宽计费：带宽每升一档，价格接近线性上涨，长期跑满的流量型业务反而不划算
- 按流量计费：低峰期省钱，突发大流量时账单会失控，务必设好告警
据统计,踩坑最集中的不是买贵了，而是买之前没算清双向流量，一个中转机每月转出 1TB，如果后端回源也计费，实际用量可能翻倍，第一台机器建议按月付，跑满一个计费周期看清真实用量，再决定要不要转年付。
上线之后要补的四件事
限速与限连，Nginx 的 limit_conn、limit_req，或者用 tc 做网卡级限速，防止单个客户端把带宽吃光。
监控，至少看三样：当前连接数、出入带宽、丢包率。ss -s、iftop、sar -n DEV 1 就够起步。
日志留存，四层转发默认不带应用日志，用 HAProxy 或 Nginx stream 的 access_log 补上，出问题时能定位到具体源 IP。
合规边界，只转发自己有权访问的服务，对外端口加白名单或密钥认证，不要把中转机做成对公网完全开放的无认证通道，多数云厂商的服务条款都对开放代理有明确限制，违规会被直接封机器。
关于中转服务器搭建的常见问题
中转服务器能直接转发 UDP 吗
可以,iptables 用 -p udp 写同样的 DNAT 规则即可，Nginx stream 从 1.9.13 起支持 listen ... udp，要注意 UDP 没有连接状态，conntrack 的超时时间偏短，长会话类应用需要单独调 nf_conntrack_udp_timeout。
中转机和后端在同一内网，还需要 MASQUERADE 吗
需要,DNAT 只改了目的地址，回包仍会带着客户端的源 IP 直接找客户端，多数情况下会被丢弃，加上 SNAT 或 MASQUERADE 让回包经过中转机，链路才是完整的，如果后端有到客户端的正确路由，也可以不加，但那属于少数情况。
中转服务器和 CDN 加速哪个更合适
看流量形态,静态资源、有明显地域分布的用户群，CDN 的边际成本更低，运维也轻，私有协议、长连接、需要固定入口 IP 的业务，自建中转更可控，两者也可以叠加：让 CDN 回源到自己的中转机，兼顾就近接入和统一出口。
写一个中转服务器,写规则只占十分钟，剩下的时间都在算带宽、调内核参数、看监控图表，把端口表和流量账算清楚，比选哪个工具重要得多。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/790417.html
