用 SSH 做端口转发的口转人不少，但真正把 Linux 上几种转发工具用明白的发工，其实没那么多。口转我见过太多人一上来就 iptables -t nat -A PREROUTING 一顿敲，发工结果规则没保存，口转重启之后全没了，发工还以为是口转内核问题。这篇文章不讲虚的发工，直接说清楚几种常见工具怎么选、口转怎么用，发工以及我踩过的口转那些坑。

SSH 隧道：最被低估的发工临时方案

如果你只是临时把本地 8080 转到远程服务器的 80，别装任何软件，口转SSH 自带的发工功能就够了。本地转发命令长这样：

ssh -L 8080:127.0.0.1:80 user@remote_host

这条命令的口转意思是：在你本机监听 8080，所有流量通过 SSH 隧道送到 remote_host，再由 remote_host 转发到它自己的 80 端口。注意，这里的 127.0.0.1 是站在 remote_host 的视角看的。很多人搞混这一点，写成 -L 8080:localhost:80 然后发现连不上，其实就是没理解“谁在访问谁”。

反向转发更实用。比如你在公司内网，想把自己机器的 3000 端口暴露给外面的 VPS：

ssh -R 9000:127.0.0.1:3000 user@vps_ip

这样 VPS 上监听 9000，流量会通过隧道回到你本地的 3000。我经常用这招给客户临时演示本地开发环境，比部署到测试机快得多。缺点是 SSH 断了一切就没了，所以加个 -o ServerAliveInterval=30 保活比较稳妥。

socat：一条命令搞定 TCP/UDP 转发

socat 是我最喜欢的“瑞士军刀”。装起来简单，apt install socat 或者 yum install socat 就完事。把本地 3306 转到另一台机器的 3306：

socat TCP-LISTEN:3306,fork TCP:192.168.1.100:3306

fork 参数很关键，不加的话只能处理一个连接就退出。UDP 转发也类似，把 TCP-LISTEN 换成 UDP-LISTEN 就行。有次我帮朋友调试一个游戏服务器，UDP 端口死活不通，最后就是用 socat 临时转发的，前后不到两分钟。

但 socat 有个问题：它不处理连接状态，高并发下性能一般。生产环境别拿它当长期方案，临时救急可以。

iptables/nftables：正经做 NAT 转发

要持久、要性能，还是得靠内核级的转发。假设你有一台网关机，eth0 是公网，eth1 是内网，想把公网 8080 转到内网 192.168.1.10 的 80：

sysctl -w net.ipv4.ip_forward=1 iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 192.168.1.10:80 iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

第一条开启内核转发，第二条做目标地址转换，第三条做源地址伪装。很多人只写第二条，然后发现内网机器回包回不来，就是因为少了 MASQUERADE。这个坑我至少踩过三次。

nftables 是 iptables 的替代品，语法更清爽：

nft add rule ip nat prerouting tcp dport 8080 dnat to 192.168.1.10:80

但说实话，除非你用的是比较新的发行版，否则 iptables 的文档和例子还是更多。我建议先把手头的 iptables 玩熟，nftables 慢慢过渡。

选哪个？看场景

临时调试、跨网络穿透，SSH 隧道最快。单条 TCP/UDP 转发、不想碰防火墙规则，socat 最省事。要做网关、要持久化、要处理大量连接，iptables 或 nftables 是唯一选择。别拿 socat 去扛生产流量，也别用 iptables 做一次性的临时转发——杀鸡用牛刀，还容易忘删规则。

最后提一句：不管用哪种，转发的端口记得在防火墙放行。我见过有人 iptables NAT 规则写得漂漂亮亮，结果 INPUT 链默认 DROP，外面根本连不进来，查了半天以为是转发没生效。