Iptables是Linux内核内置的报文过滤防火墙，它通过操作规则表来允许或拒绝数据包进出，掌握它，你就能精准掌控服务器的每一条流量去向。这篇文章从零梳理iptables的核心概念到落地配置，不绕弯子，直接讲透。
iptables 和 firewalld 到底怎么选，才能让服务器既安全又不卡
很多刚接触Linux服务器的朋友会问,iptables 和 firewalld 有什么区别，简单说，firewalld是动态防火墙，适合频繁变更规则的桌面或云主机场景，它按区域管理流量，配置起来更像“填空”，而iptables是静态规则集，每一条规则都按顺序匹配，匹配到就停止，效率极高，资源占用极低，多数生产环境下的Linux老手，尤其跑着Nginx、MySQL的服务器，仍然偏向iptables。
坦白说，两者并不冲突，但一台机器上同时启用两个防火墙服务会导致规则互相覆盖，排查问题时容易让人抓狂，如果你的Linux版本是CentOS 7或以上，系统自带firewalld，也可以手动切换回iptables：
systemctl stop firewalld
systemctl disable firewalld
yum install -y iptables-services
systemctl start iptables
systemctl enable iptables为何国内服务器运维仍偏爱 iptables 做流量入口管控
去各大IDC机房转一圈,或翻看技术社群的讨论，你会发现大量云服务器在Nginx前置层、数据库访问层仍用iptables做白名单，原因很直接：iptables规则生效是内核态直接处理，不经过用户态转发，延迟极低，脚本化部署方便，写一段shell即可在批量服务器上同步规则，而firewalld的XML配置在批量场景下反而不太直观。
iptables 规则怎么添加：从四表五链到你的第一条规则
要上手,得先理解它的骨架，iptables包含四张表和五条链，表是功能的分类，链是报文流经的关卡，四张表分别是：
- filter表：核心的过滤功能，允许或拒绝数据包，最常用。
- nat表：网络地址转换，端口映射、共享上网靠它。
- mangle表：修改数据包的服务类型、TTL等特殊字段。
- raw表：用于配置NOTRACK，跳过连接跟踪。
五条链则对应数据包在内核中的五个挂载点：
- PREROUTING：报文进入路由决策之前。
- INPUT：报文发给本机进程。
- FORWARD：报文需本机转发。
- OUTPUT：本机进程发出报文。
- POSTROUTING：报文即将离开网卡前。
第一道指令：查看当前规则与清空规则
执行iptables -L -n --line-numbers，即可看到服务器当前的规则列表，注意-n表示不做反向域名解析，速度更快也更清晰，若机器刚买回来，规则大概率是空的，此时不要急着加规则，先执行
iptables -F清空默认规则，避免旧配置干扰后续调试。
第二道指令：放行SSH，避免自己把自己锁在门外
给服务器配防火墙最怕的是规则顺序写错,把自己拒之门外，很多人在配置iptables的实战演练中都会踩这个坑，务必在添加任何拒绝规则之前，先将SSH端口放行，假设你修改过SSH端口，假设是22026，那应该执行：
iptables -A INPUT -p tcp --dport 22026 -j ACCEPT
这行命令的意思：追加一条规则到INPUT链，匹配TCP协议且目标端口为22026，动作为接受，这里有一个通用建议，端口号在规则里一定要用22端口还是22026，取决于你实际改过的配置，别照抄网络教程不带脑子。
第三道指令：配置默认策略
默认策略是整个规则的兜底,如果规则全部没匹配上，走默认策略，安全角度建议将INPUT链默认策略设为DROP，但在设置前确保已经有了放行规则：
iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT
设定之后你会发现,这台服务器只有你显式放行的流量能进来，这就是iptables使用教程中最核心的“白名单思维”。
Linux iptables 配置实战：端口转发与NAT场景
NAT表与mangle表在真实业务中高频应用,尤其在公网IP不足或内网服务隔离的场景，下面是两个业内最常见的配置场景。
端口映射，把内网MySQL服务暴露给指定公网IP
假设内网有一台数据库服务器,IP为192.168.1.100，运行在3306端口，防火墙服务器有两块网卡，公网网卡eth0，内网网卡eth1，操作为：
iptables -t nat -A PREROUTING -d 公网IP -p tcp --dport 3306 -j DNAT --to-destination 192.168.1.100:3306 iptables -t nat -A POSTROUTING -s 192.168.1.100 -p tcp --sport 3306 -j SNAT --to-source 公网IP iptables -A FORWARD -p tcp -d 192.168.1.100 --dport 3306 -j ACCEPT iptables -A FORWARD -p tcp -s 192.168.1.100 --sport 3306 -j ACCEPT
需要注意,做完DNAT之后还要确保FORWARD链没有拦截，多数运维新手在这里漏掉FORWARD规则，导致内网服务通了但数据包没被转发，这也是nginx 做反向代理时 iptables 规则怎么配这类问题里经常被提及的坑，反向代理机器本身也要放行相应端口。
共享上网，让内网机器统一走一台服务器出口
办公室或家里有多台内网设备,不想每台都配公网IP，直接用一台Linux盒子做网关：
echo 1 > /proc/sys/net/ipv4/ip_forward iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE
这样内网所有机器把网关指向这台服务器即可自然上网,MASQUERADE适合动态获取IP的出口线路，若是固定IP，建议用SNAT指定具体源IP，性能更好，整体而言，
iptables端口转发机制适用于链路层以上的流量控制，但内核生产版本更推荐直接使用nftables替代旧命令集，不过这是后话。
iptables 规则保存：重启不丢的三步操作
新手最常见的疑惑：明明配置好了规则，重启服务器或者重启iptables服务后，规则全没了，因为iptables规则的默认状态是内存态，重启即失。
正确的保存姿势：
- CentOS 6或较早版本：执行
/etc/init.d/iptables save - CentOS 7及以上版本：先安装iptables-services，执行
service iptables save，规则会写入/etc/sysconfig/iptables。 - 通用备份方式：执行
iptables-save > /root/iptables.rules，恢复时用iptables-restore < /root/iptables.rules。
生产环境建议把规则文件纳入版本管理,修改前先备份，每次变更后执行iptables-save，做到重启不慌、回滚有据。
iptables 常见疑难排查与错误处理
规则已放行，流量仍无法到达服务
按顺序排查三个层面,先用iptables -L -v -n查看规则命中计数，若计数为0，说明数据包根本没走到这条链，此时需要检查数据包是否被前面的DROP规则拦截，或者流量压根没到达本机。别忘检查系统里是否还有firewalld在运行，两个防火墙服务并存会导致规则互相覆盖又不报错，是排障中最隐蔽的源头。
配置了端口转发，内网访问不正常
多数情况下是回程流量没有做SNAT，DNAT只改了目标地址，如果出口报文源地址仍是内网机器的私有IP，对端响应时无法正确回包，解决办法是追加POSTROUTING链的SNAT规则。
iptables服务启动失败且无报错
检查内核模块是否加载：lsmod | grep ip_tables，若输出为空，执行modprobe ip_tables，云服务器厂商的控制台安全组也要确认已放行对应端口，有时规则没错，但云平台安全组把流量挡在了外面。
iptables 删除规则与规则优化技巧
删除规则有两种方式。方法一：按规则编号删除，先iptables -L -n --line-numbers查看规则序号，再iptables -D INPUT 3，含义为删除INPUT链第3条规则。方法二：按规则内容精确匹配删除，例如iptables -D INPUT -p tcp --dport 22 -j ACCEPT，后者适合脚本中动态删除某条已知规则的场景。
优化方面,行业内共识是把高命中率的规则放在链的前面，每条规则被匹配就会产生CPU开销，链越长，线性匹配耗时越大，一个常见做法是：将同类别规则聚合，多个端口可合并为连续端口范围，减少规则条目数。
iptables -A INPUT -p tcp -m multiport --dports 80,443,8080 -j ACCEPT
若规则条目动辄上百条,且需要频繁变更，建议考虑使用ipset配合iptables，ipset能大幅提升集合匹配性能，尤其适合封禁大量IP的场景，值得注意的是，即使遇到复杂场景也切莫偏离基础逻辑，iptables命令本身依然是所有上层工具的最终执行者。
iptables 和 nftables 演变趋势，2026年还值得学吗
Linux内核早已用nftables逐步替代iptables框架,但iptables命令在不少存量服务器上仍长期存在，从结局看，iptables被nftables完全取代是趋势，但存量规模庞大，2026年主流发行版依然默认兼容iptables命令集，学习iptables的价值并不局限于命令本身，它让你理解报文在内核中经过的路径和挂载点，这个底层概念在理解nftables、ebtables乃至云原生网络插件时依旧适用，可以按时间预算分配，先熟练掌握iptables再过渡到nftables，而非跳过基础。
常见问题解答：iptables 详解周边疑问
修改iptables规则后，连接中的TCP会话会立即断开吗？
不会,iptables是基于连接跟踪状态的机制，修改规则仅影响新建立连接的报文匹配，已经处于ESTABLISHED状态的连接，只要没有显式删除对应的状态放行规则，通常不会被立刻切断，但若执行iptables -F清空所有规则，则状态跟踪表也会丢失上下文，导致会话中断，需要应用层重连。
docker容器端口映射与iptables规则冲突，网站为何无法访问？
Docker在启动时会动态写入iptables的DOCKER链,许多软件在安装防火墙规则时习惯添加-I INPUT将规则插入最前，从而拦截了Docker的FORWARD流量，排查方法是执行iptables -L -n查看FORWARD链和DOCKER链的位置关系，解决办法是通过iptables -A追加规则而非强制插入最前，或为Docker流量单独放行。
规则都是正确的，为何本机访问公网IP的映射端口不通，其他机器却正常？
这通常被称为“NAT回环”问题，本机发出的数据包若经过PREROUTING的DNAT规则，源地址是本机，出口为lo接口，实际并不经过eth0，导致回包时无法正确匹配源地址，业内专家指出，解决思路有两种：一是添加内部访问的独立DNAT规则指向内网IP；二是在POSTROUTING链为本机地址追加一条SNAT规则。
最终的判断标准很简单,将filter链的默认策略设为DROP后，你需要的服务端口全部显式放行，规则顺序清晰可读，这就是一份合格的iptables配置，从内核报文路径到实战命令，养成配置、验证、保存的闭环习惯，防火墙不再是绊脚石。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/588637.html
