Linux配置端口转发，最靠谱的方案是使用iptables完成DNAT加SNAT双向规则，再开启内核IP转发，整个流程十分钟内能跑通。如果你只是想快速转发个端口，不想折腾复杂规则，firewalld或rinetd这类轻量工具也能顶上去，但灵活性和性能都不如iptables，下面先从最通用的iptables方案讲起，再聊替代工具和常见踩坑点。
linux端口转发配置方法：两个核心步骤打通内外网
端口转发的本质是数据包的重定向，当外部请求到达你服务器的某个端口，内核根据你设定的规则，把数据包的目标地址和端口改写成内网目标机器的地址和端口，同时在回程时再把源地址改回来，这样内外网机器互相通信时，感知不到中间做了手脚。
以简米云或酷番云上最常见的使用场景为例：你有一台公网服务器（假设公网IP是203.0.113.10），想访问内网另一台机器（192.168.1.100）的Web服务（80端口），但内网机器没公网IP，这样配置：
开启内核IP转发
先检查当前内核转发是否已开启：
sysctl net.ipv4.ip_forward
输出结果为 net.ipv4.ip_forward = 0 说明没开，执行下面命令临时开启：
echo 1 > /proc/sys/net/ipv4/ip_forward
想让配置重启后依然生效,编辑 /etc/sysctl.conf 文件，找到或添加下面这行：
net.ipv4.ip_forward = 1保存后执行 sysctl -p 让配置立即加载，这一步是端口转发的地基，不少人漏掉它导致数据包进来后直接丢弃。
配置DNAT规则（改变目的地址）
DNAT负责改写数据包的目标地址和端口,在公网服务器上执行：
iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 192.168.1.100:80
这条命令的意思是：所有到达本机8080端口的TCP流量，目标地址统统改为192.168.1.100的80端口。
配置SNAT规则（改变源地址）
只有DNAT还不够,如果缺少SNAT规则，后端服务器收到数据包后，看到源地址是客户端的真实IP，回包时会直接把响应发给客户端，而不是通过公网服务器中转，客户端就会觉得连接被重置，所以还需要加一条：
iptables -t nat -A POSTROUTING -p tcp -d 192.168.1.100 --dport 80 -j SNAT --to-source 113.108.10.10
108.10.10 需要替换成你公网服务器网卡上的内网IP（用 ip addr 查看，通常是eth0网卡的IP，不是公网IP），如果你懒得确认具体IP，也可以用MASQUERADE动态伪装：
iptables -t nat -A POSTROUTING -p tcp -d 192.168.1.100 --dport 80 -j MASQUERADE
MASQUERADE会自动识别出口网卡的IP,缺点是每次数据包出去时都要查询一次出口IP，高并发场景下性能比SNAT略差，但日常使用感知不到区别。
持久化规则
iptables规则重启后消失，这是Linux的默认行为，用下面命令保存规则（以CentOS为例）：
iptables-save > /etc/sysconfig/iptables
然后设置开机自动加载：
systemctl enable iptables
Debian/Ubuntu系可以用 netfilter-persistent 工具：
apt install netfilter-persistent netfilter-persistent save netfilter-persistent reload
验证转发是否成功
配置完成后,在客户端机器上执行：
curl http://203.0.113.10:8080
能正常返回页面就说明转发已生效,如果卡住不动，多半是回程路由或SNAT没配置好。
linux端口转发和反向代理区别：别总用一套思路
很多初次接触的人容易搞混端口转发和反向代理,这俩解决的问题有重叠，但底层原理完全不同，熟悉两者差异后，选型会更有方向。
| 维度 | 端口转发（iptables） | 反向代理（Nginx） |
|---|---|---|
| 工作层级 | 内核态网络层（L4） | 用户态应用层（L7） |
| 转发单位 | 数据包（不改内容） | HTTP请求（可改协议头） |
| 支持协议 | TCP/UDP任意协议 | 主要是HTTP/HTTPS/WebSocket |
| 性能损耗 | 极低，内核直接处理 | 较高，需要拷贝数据到用户态 |
| 高级功能 | 无，纯粹转发 | 负载均衡、缓存、SSL卸载、路径重写 |
| 配置复杂度 | 规则简短但概念抽象 | 配置直观易理解 |
行业共识认为,iptables适合流量纯转发场景，比如数据库端口映射、SSH跳板、游戏服务器中转，这类场景数据包本身不能被修改，Nginx处理不了非HTTP协议，Nginx更适合Web流量管理的场景，比如一个域名后面挂多台后端服务器，需要按路径分流或做缓存。
如果你的目标是把内网多个Web服务暴露出去，Nginx反向代理更灵活，可以按域名区分；如果只是单纯映射一个数据库端口，iptables是更轻的选择。
iptables端口转发不生效？按这个顺序排查
配置完了就是不工作,这个问题的出现频率远超预期，按下面的顺序逐层排查，多数情况下半小时内能定位到问题。
第一层：内核转发确认开启
重新检查一下：
sysctl net.ipv4.ip_forward
命令返回 1 才是开启状态，有些云服务器默认开启，但你可能改过sysctl配置把值覆盖了。
第二层：防火墙规则拦截
你的云安全组和服务器本地防火墙都放行对应端口吗？
- 简米云/酷番云：控制台安全组规则里要放行对应端口
- 服务器内部：
firewall-cmd --list-all（CentOS）或ufw status（Ubuntu）确认没有拦截
安全组默认拦截是高危误配置,特别是国内云厂商，默认只放行22端口，8080这类端口需要手动添加规则。
第三层：iptables规则顺序
iptables规则是按顺序匹配的,如果前面有条 -j DROP 规则把流量拦了，后面的DNAT规则就永远执行不到，查看当前规则列表：
iptables -t nat -L -n --line-numbers
输出里的数字就是规则的顺序号,如果发现规则没加入，或者顺序不对，可以先清空再重新加：
iptables -t nat -F
第四层：目标服务监听状态
登录内网目标机器,在目标机器上确认服务真的在跑：
ss -lntp | grep 80
如果目标服务只监听在127.0.0.1，而非0.0.0.0，那外部转发过去的流量会被拒绝，需要修改服务监听地址，让其监听在所有网卡上。
第五层：抓包定位丢包点
上面四层都查了还不行,用tcpdump抓包看数据包到底走到哪一步：
tcpdump -i eth0 port 8080 -nn
观察是否有SYN包到达公网服务器,再看内网机器上的抓包结果，能定位到是转发链路断了还是回程包丢了。
轻量替代工具：rinetd与socat
如果只是临时转发一个端口,或内网机器数量很少，不想写iptables规则，用现成工具能省不少事。
rinetd：配置文件最简洁
安装后编辑 /etc/rinetd.conf，写入一行规则即可：
0.0.0 8080 192.168.1.100 80意思是监听所有网卡的8080端口,转发到192.168.1.100的80端口，重启服务生效：
systemctl restart rinetd
rinetd的好处是配置可读性强，改动后不用管内核状态，适合配置交给运维新人维护的场景，缺点是不支持UDP转发，规则多的情况下性能不如iptables。
socat：适合复杂协议的瑞士军刀
socat能把几乎任何数据流接起来,命令方式执行，不写配置文件：
socat TCP-LISTEN:8080,fork TCP:192.168.1.100:80
加 fork 参数支持并发连接，socat也支持UDP（UDP-LISTEN）和Unix Socket转发，调试网络问题时特别顺手。
用 nohup 或 systemd 把它跑成后台服务即可，这类方案的问题在于没有内核层面的NAT能力，转发大流量数据时CPU占用比iptables高不少。
linux端口转发常见问题解答
问：iptables端口转发配置完成后重启服务器就失效了，怎么处理？
把规则保存到持久化配置文件中，CentOS执行 iptables-save > /etc/sysconfig/iptables，Ubuntu安装 netfilter-persistent 并运行 netfilter-persistent save，还要确保iptables服务已设置为开机自启。
问：端口转发能支持UDP协议吗？
支持，iptables规则里把 --dport 和 --toport 前面的协议从 tcp 改为 udp 即可，规则格式完全一样，rinetd默认不支持UDP，需要UDP转发时优先考虑iptables或socat。
问：服务器上没配SNAT规则，只做了DNAT会怎样？
后端服务器收到请求后，回包会直接发给真实客户端，客户端收到来源IP与请求IP不一致的数据包会直接丢弃，表现为连接超时，SNAT规则保证回包必须经过转发服务器中转，这是保证双向通信的关键。