干了这么多年Linux运维，接手一台新服务器，我第一件事永远是看它的iptables防火墙规则。这不是什么仪式感，而是因为太多线上故障最后都追溯到这一层：端口通不通、谁能连、能不能转发、NAT有没有生效，全由这一套规则说了算。iptables防火墙是Linux内核netfilter框架的用户态管理工具，它解决的是"谁可以访问我的哪类网络资源"这个最基础也最要命的问题。这篇文章我会从底层逻辑讲到实战配置，再到我踩过的坑和生产环境的运维思路，适合刚接触Linux的运维新手，也适合那些被防火墙规则折磨过、想系统梳理一遍的同行。我把这些年积累的东西一次性写清楚，你可以直接当作参考手册来用。
1. 先把iptables的底层逻辑吃透，不然配规则全凭瞎猜
1.1 四表五链，到底谁在管什么事
很多新手一上来就背"四表五链"，背完还是晕。我换个方式讲：想象数据包是一份快递，服务器是一家公司。快递送到公司门口时，门卫要看一看（这是入站检查）；快递要从公司寄出去时，门卫也要看一看（这是出站检查）；如果这个快递只是路过公司、需要转交给另一家公司，门卫还得检查一下转发路径。iptables里的链（chain）就是这些检查点，表（table）则是不同门卫手上的职责手册。
具体来说，数据包进入本机时，会先经过PREROUTING链，然后进入INPUT链，到这里就交给本机进程处理了。本机进程发出数据包时，先经过OUTPUT链，再到POSTROUTING链出去。如果本机是路由器角色，数据包在PREROUTING之后不进入INPUT，而是走FORWARD链，最后经过POSTROUTING出去。链之间的先后顺序就这么简单，搞清楚这个，你就能定位"我想拦的数据包到底走哪条链"。
再讲表。raw表负责连接跟踪的豁免，mangle表负责修改数据包标志位，nat表负责地址转换（DNAT、SNAT、MASQUERADE都在这），filter表负责真正的允许或拒绝，也就是最常见的ACCEPT、DROP、REJECT。实际工作中，filter表和nat表占了90%以上的使用场景，另外两张表知道存在即可。数据包经过每个链时，会按raw、mangle、nat、filter的顺序去对应的表里查找规则，这个顺序由内核写死了，不用去记太多，只要知道"过滤动作都在filter表、地址转换都在nat表"就够了。
1.2 规则从上往下匹配，默认策略兜底
iptables的规则是按顺序从上到下逐条匹配的，匹配到第一条符合条件的规则就立刻执行，后面的规则不再看。这个特性坑了无数人。我见过最典型的场景：某运维同学想封掉对SSH端口的暴力破解，先加了一条iptables -A INPUT -p tcp --dport 22 -j DROP，过一会儿发现自己怎么也连不上服务器了，只好重启。原因很简单：规则顺序写反了。正确做法是先把合法的来源IP放行，再拒绝其他地址。
我建议的规则组织顺序是：先放行已建立连接的回包，再放行明确的合法流量，然后拒绝明确的非法流量，最后用默认策略兜底。这样即使你漏配了某条规则，默认策略也能拦住不该放行的流量，而不是把所有流量都敞开放出去。
默认策略（policy）是另一个关键点。你可以用iptables -P INPUT DROP把INPUT链的默认策略设为丢弃，这意味着所有没被显式规则匹配到的数据包都会被丢弃。黑名单思路是默认全放、单独封禁；白名单思路是默认全拦、单独放行。生产环境里，像数据库、管理后台这类敏感服务，我强烈建议用白名单思路，默认DROP再逐条放行，安全性完全不是一个级别。
2. 真实场景下的iptables配置实操
2.1 黑白名单两种思路，我为什么劝你在关键服务上选白名单
黑白名单这个词在热搜里出现频率极高，我在这里把两者掰开揉碎讲清楚。黑名单模式下，你的INPUT链默认策略是ACCEPT，只需要把已知的恶意IP封掉即可。它的好处是管理轻松、不容易误伤正常业务，坏处是太被动了——你只能封已知的坏人，新出现的扫描器、漏洞探测流量照样能进来。
白名单模式则相反，默认策略设成DROP，只放行明确需要访问的服务和来源。例如一台MySQL服务器，业务侧只需要应用服务器的IP访问3306端口，那就只放行这一个IP，其他流量统统丢弃。这样做有两个好处：一是攻击面被缩到最小，即使有人扫到了3306端口开放，也没法建立连接；二是出了安全问题排查范围小，能连上数据库的IP一只手数得过来。
实际操作时，我的习惯是写一个规则的先后顺序清单：
- 放行回包流量：
-m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT - 放行本机回环：
-i lo -j ACCEPT - 放行明确的服务端口并限定来源：
-s 允许IP -p tcp --dport 3306 -j ACCEPT - 最后默认策略DROP
这套顺序既保证了正常连接不回包不畅，又最大程度缩小了暴露面。别嫌白名单麻烦，线上被入侵后你才会发现，黑名单模式下漏进来的流量往往就是当初懒得写的那条白名单规则。
2.2 高频需求直接抄作业：SSH、Web、ping、封IP、端口转发
先给出一套最常用的模板，你可以在测试环境直接粘贴运行，然后逐条理解。
# 1. 清空当前规则，注意别在远程连接时随手执行，会导致你的SSH立刻断掉 iptables -F iptables -X iptables -Z # 2. 设置默认策略 iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT # 3. 放行回包和回环，这两条必须放在最前面 iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # 4. 放行SSH，这里假设你的管理IP是192.168.1.100 iptables -A INPUT -s 192.168.1.100 -p tcp --dport 22 -j ACCEPT # 5. 放行Web服务 iptables -A INPUT -p tcp --dport 80 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j ACCEPT # 6. 放行ping，便于监控探测 iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT # 7. 封禁某个恶意IP iptables -A INPUT -s 203.0.113.10 -j DROP这里要重点解释第三条命令里的conntrack模块。TCP连接是有状态的，如果你只放行SSH入站端口而不放行回包，那客户端发来SYN、服务器回了SYN-ACK，这个回包会被INPUT链默认策略丢掉，连接永远建立不起来。很多新手只放行入站端口却发现连不上，原因就是漏了这条状态放行。--ctstate ESTABLISHED,RELATED表示允许所有已建立连接的相关流量通过，这是iptables最核心的用法之一。
端口转发是另一个高频需求，常见场景是内网的一台Web服务器需要对外提供服务，但公网入口在另一台Linux服务器上。我的配置套路是：
# 开启内核转发功能 sysctl -w net.ipv4.ip_forward=1 echo 'net.ipv4.ip_forward = 1' >> /etc/sysctl.conf # 入站DNAT：公网IP的8080端口转发到内网192.168.1.10的80端口 iptables -t nat -A PREROUTING -d 公网IP -p tcp --dport 8080 -j DNAT --to-destination 192.168.1.10:80 # 出站SNAT：让内网服务器回包时经过本机，否则回包会直接发给客户端导致连接失败 iptables -t nat -A POSTROUTING -d 192.168.1.10 -p tcp --dport 80 -j SNAT --to-source 公网IP # FORWARD放行对应流量 iptables -A FORWARD -p tcp --dport 80 -j ACCEPT这套配置的难点在SNAT那一行。很多人只配了DNAT，结果外网客户端发包进来了、内网服务器也收到了，但回包不知道该往哪走，因为目标地址是客户端的公网IP，内网服务器没有默认路由能到达，这个包就丢了。SNAT的作用就是把回包的源地址改成本机，这样内网服务器看到的是"本机在请求自己"，回包自然回到本机，再由本机转给外网客户端。
2.3 按进程屏蔽某个程序联网，这个需求很多人问
热搜里有条"先建立出入站规则屏蔽acrobat.exe联网"，这是个典型的客户端需求：某个软件总在后台联网更新、上传数据，你想把它禁掉。在Windows上可以直接建防火墙出站规则指定程序，但在Linux上用iptables限制"某个程序"并没有那么直观，因为iptables工作在IP层，它不认识进程名。
我能想到的几种实现方案，按推荐程度排序。第一，按运行用户屏蔽：用owner模块匹配发出数据包的UID，适合那些有独立运行用户的程序。比如要给运行用户为appuser的进程断网：
iptables -A OUTPUT -m owner --uid-owner appuser -j DROP这里有个坑，如果程序以root身份运行，--uid-owner root对部分数据包可能不生效，因为root发出的某些包不会走owner匹配。第二，按目标地址屏蔽：先用lsof -i、ss -tnp或者tcpdump抓包，找到这个程序一直在连的目标IP或端口，然后按目标地址封禁。比如某软件总是往某个云厂商的IP段发心跳包，直接封整个IP段：
iptables -A OUTPUT -d 203.0.113.0/24 -j REJECT第三，如果程序是通过systemd管理的服务，直接用systemd的IPAddressDeny特性更干净，不过这偏离iptables的范畴了。我的经验是：具体场景具体分析，不要死磕"必须按进程匹配"，有时候按目标IP封禁反而是最简单、最稳定的方案。
2.4 规则保存与还原：重启不丢配置
新手最容易忽略的问题就是：iptables命令改的是内存里的规则，重启服务器后全部消失。有些同学测试时随手加了规则，以为万事大吉，结果服务器一重启，服务直接裸奔了。
保存规则的命令很简单：
# 保存当前规则到文件 iptables-save > /etc/sysconfig/iptables # 从文件恢复 iptables-restore < /etc/sysconfig/iptablesCentOS 6和部分装了iptables-services的CentOS 7环境，可以直接用service iptables save，它会自动把当前规则写入/etc/sysconfig/iptables。CentOS 7默认用的是firewalld，如果你已经关掉了firewalld，就需要自己把iptables-save的保存操作做成开机自启，我一般是写一个systemd服务或者直接在rc.local里放一行iptables-restore < /etc/sysconfig/iptables。
这里有一个我强烈建议的习惯：改规则前，先备份当前规则到文件，标注好日期。一旦新规则出了问题，三秒钟就能回滚到上一版，不用在故障现场手忙脚乱地回忆自己刚才敲了啥。
3. 常见故障排查实录，每个都是我踩过的坑
3.1 开启防火墙后ping不通，先检查这五件事
"开启防火墙后ping不通"是热搜词，也是运维群里问烂了的问题。ping不通这个事情，99%出在以下五个环节，我建议你按顺序排查。
第一，看默认策略是不是DROP了。如果你的INPUT默认策略是DROP，又没有显式放行ICMP，那任何ping包都会被丢弃。放行包命令是iptables -I INPUT -p icmp --icmp-type echo-request -j ACCEPT。
第二，看放行规则是不是放在了DROP规则后面。规则是自上而下匹配的，如果前面已经有一条-j DROP把所有包拦了，你后面再加放行规则也没用。用iptables -L -n -v查看规则顺序，必要时用-I插入到前面。
第三，看回包是否被拦截。别人ping你，是入站ICMP包；你ping别人，除了出站的ICMP包，还要保证入站的回包能进来。如果你把INPUT链默认设成DROP且没有conntrack放行，那么你ping别人能发出去，但回包进不来，表现也是ping不通。
第四，查FORWARD链。如果你的机器是路由器或者中转节点，ping包走的是FORWARD链，跟INPUT没关系。这时候要看FORWARD默认策略和规则有没有放行。
第五，很多云服务器还有安全组这一层，它在iptables之前就生效了，如果安全组没放行ICMP，本机iptables配得再对也没用。查完这五步，90%的ping不通问题都能定位。
3.2 明明关了防火墙，服务还是提示异常
热搜里那句"防火墙关了还是提示服务异常"我太有共鸣了，因为这句话通常意味着你关掉的只是表面上的防火墙，真正拦截的东西还在暗处。我归纳过几个常见原因。
第一种情况，CentOS 7环境最常见的坑：你执行了systemctl stop firewalld，但系统里可能还跑着iptables-services服务，或者以前手工加的iptables规则还残留在内核里。firewalld停掉只代表它的管理进程不工作了，不代表netfilter里的规则清空了。遇到这种情况，先用iptables -L -n -v看有没有残留规则，有的话iptables -F清一下。
第二种情况，SELinux在背后做手脚。很多服务端口监听正常，防火墙也全关了，但外部就是访问不了，查看日志才发现是SELinux拦截了进程的网络访问。排查命令是getenforce，如果是Enforcing状态，可以用setenforce 0临时切换（仅测试用），或者用ausearch -m avc查看具体的SELinux拒绝记录。
第三种情况，服务本身根本没起来，或者监听的地址不对。用ss -lntp看端口监听状态，特别留意是不是只监听了127.0.0.1、没有监听0.0.0.0，如果是，那外网访问不了跟防火墙一点关系都没有。
3.3 端口转发配置不生效的排查套路
端口转发不生效这个问题，我把它总结成一个五步排查清单，照着走一般很快能找到问题。
第一步，确认内核转发开关打开了。sysctl net.ipv4.ip_forward，输出为0就是没开，执行sysctl -w net.ipv4.ip_forward=1。第二步，确认DNAT规则写在了PREROUTING链而不是INPUT链。我见过有人在filter表的INPUT链里写DNAT，那当然不可能生效，因为PREROUTING在路由决策之前执行，DNAT必须写在这里。第三步，确认POSTROUTING里的SNAT或者MASQUERADE配置正确。MASQUERADE适合出口IP动态变化的场景，命令是iptables -t nat -A POSTROUTING -j MASQUERADE，SNAT适合出口IP固定的场景。第四步，确认FORWARD链没有把转发流量拦掉。很多人默认策略把FORWARD设成DROP，忘了放行对应端口，导致DNAT后的包卡在这里。第五步，在目标服务器上用tcpdump port 80抓包，看包到底有没有到达。
这个顺序是从内核处理路径推出来的，只要包转发链路是通的，按这个顺序排查，问题的根因必然出现在其中某一步。别一上来就怀疑iptables没生效，先看数据包到底走到哪一步了。
3.4 顺手聊聊Windows侧防火墙的故障
热搜词里有条"win11防火墙错误代码0x800706d9"，这是Windows上很典型的防火墙服务故障。虽然这篇文章讲的是iptables，但运维工作从来不是单操作系统战场，我简单说几句。
0x800706d9字面意思是"服务没有及时响应启动或控制请求"，通常和Windows Defender Firewall所依赖的服务有关。排查思路是先确认基础过滤引擎（BFE）服务是否在运行，再确认Windows Defender Firewall服务能否正常启动。多数情况下，重启这两个服务、然后以管理员身份运行netsh advfirewall reset可以恢复。这个问题提醒我的是：不管Linux还是Windows，防火墙本质上都是一项系统服务，出问题先看服务状态和依赖项，不要一上来就重装系统或者关闭防火墙。对Windows的机器，关闭Windows Defender Firewall并不是一个推荐选项，因为它背后还连着网络安全层的多项策略，关掉后系统会失去基础防护，并不值得。
4. 生产环境里的防火墙运维思路
4.1 CentOS 7/8关闭防火墙的正确姿势，以及我为什么不建议你关
搜索"关掉centos7的防火墙命令"的人特别多，我先把命令给你，再说说什么时候真的该用。
# 停止并禁用firewalld服务 systemctl stop firewalld systemctl disable firewalld执行完这两条，firewalld确实不会再启动了。但如果你在CentOS 7上装了iptables-services，或者之前手动用iptables加过规则，那些规矩还是在的，还是需要iptables -F清空。CentOS 8以后情况又不同，默认的防火墙后端是nftables，你看到的iptables命令很可能只是兼容层的iptables-nft，它跟你以前在CentOS 6上用的iptables在底层已经不一样了。
至于"防火墙关闭有影响吗"，我的回答是：影响一定有，只是有的影响你暂时看不见。本机防火墙一旦关闭，所有端口都对网络开放，内网任何一个能连通这台机器的人，都可以尝试连接它暴露的每一个服务。如果你的机器只在内网、有网络隔离保护、而且你清楚自己在做什么，关掉本机防火墙算是一种取舍；但如果是公网服务器，我坚决不建议关闭。云环境里，即使有安全组在网关侧做了限制，本机防火墙依然是最后一道防线，多一层防护多一分安全。
4.2 防火墙双机热备和自动切换的基本原理
热搜里那句"各种故障情况下的防火墙ips waf自动切换原理"让我觉得很多人对高可用切换有误解，以为就是两台机器互相看一眼，挂了一台就顶上。实际上，防火墙做双机热备（HA）比普通应用服务切换要复杂得多，因为防火墙不仅要同步配置，还要同步连接状态。
双机热备的核心是心跳。两台防火墙通过专用心跳线互发探测报文，谁活着谁就是主节点，承担流量转发和策略执行；备节点处于standby状态，实时同步主节点的配置和会话表。当主节点出现故障（电源、网卡、软件进程异常），备节点在毫秒级时间内接管虚拟IP和流量转发。关键点在于会话同步：如果主备两台防火墙没有实时同步conntrack会话表，主节点突然宕机后，所有已建立的连接都会中断，客户端会感觉到明显的断线重连。所以业界做HA时，最简单的高可用也要保证会话表同步，这也是keepalived这类工具在Linux环境下做iptables热备时要额外处理的。
在Linux服务器上，比较常见的做法是keepalived管理VRRP虚拟IP，配合一个同步脚本：主节点通过iptables-save导出规则，通过心跳同步到备节点；备节点用iptables-restore实时加载。但这种方式同步的是规则配置，conntrack会话表的同步需要额外工具实现，配置起来相对复杂。我的建议是：如果业务对连续性要求很高，优先考虑成熟的硬件防火墙或者商业HA方案，自己造的轮子可能省了成本，但故障切换时的坑会多到你不想回忆。
4.3 iptables还是nftables：新装系统怎么选
近几年的Linux发行版，底层已经悄悄从iptables切换到nftables了。拿CentOS Stream、Rocky Linux、Ubuntu新版本来说，你敲iptables的时候，大概率实际执行的是iptables-nft这个兼容层，配置语法兼容，但代码路径已经变了。nftables相比iptables的优点很直接：语法更简洁，支持批量更新，性能在规则量大时更好，而且不再有"四表五链"那么死板的框架。
我以前习惯的iptables命令可以对照一下nftables的写法：
# iptables放行SSH iptables -A INPUT -p tcp --dport 22 -j ACCEPT # nftables对应的写法 nft add rule ip filter INPUT tcp dport 22 accept给我的实际感受是，nftables学习曲线不算陡，但思维模式需要转变：iptables是一行行追加规则，nftables是一张张rule set直接定义。对存量环境，我不建议你急着迁移，因为iptables的规则脚本还能继续用，只是底层实现变了，你的脚本依然有效。对新项目，我建议直接学习nftables，未来的Linux网络管理一定会向它靠拢，早一天上手早一天不慌。
4.4 从ensp模拟器到真机：不同设备上的"防火墙"只是换了壳
热搜里出现了很多设备相关的词：ensp配置防火墙、锐捷防火墙配置、连接h3c防火墙、山石防火墙命令行、小米路由器关闭ipv6防火墙、天翼网关超级防火墙账号密码。看上去五花八门，其实它们干的都是同一件事：通过一定的规则，控制网络流量能不能通过、怎么转换、怎么转发。
ensp是华为的网络设备模拟器，很多初学者在ensp里练习防火墙的web登录配置，设置安全策略、NAT规则，这些思路拿到锐捷、H3C、山石的真机上照样适用，只是命令行和页面入口不同。比如"连接h3c防火墙"这个需求，本质上就是通过console、SSH或者web界面登录防火墙的管理接口，然后配置策略；"小米路由器关闭ipv6防火墙"则是家用设备场景，IPv6防火墙默认开启是为了防止外网直接访问内网IPv6设备，关掉之前要想清楚后果。
我接触过很多从模拟器转到真机、或从Linux转到网络设备的人，最大的感触是：不要被厂商的配置界面吓到，也不要被命令行差异迷惑。不管什么设备，防火墙的底层逻辑都是"匹配条件+动作"，条件无非是源地址、目标地址、协议、端口、时间段，动作无非是放行、拒绝、丢弃、转换。你在iptables里想清楚的问题，换到任何一台设备上都适用。
最后说点实在话
做运维这些年，我在iptables上吃过最大的亏，不是规则配错，而是没给自己留后路。有一次远程改服务器防火墙规则，一个手滑把放行自己管理IP的那条规则删了，紧接着又执行了默认策略改成DROP，结果就是眼睁睁看着SSH断开，只能花钱让机房小哥帮忙重启。从那以后我给自己定了几条规矩：改规则前先备份当前规则文件；改完后不要立刻断开当前会话，先开一个新会话验证；所有变更都通过脚本执行而不是手工敲命令，方便留存和回滚。这些习惯看着麻烦，但关键时刻能救命。防火墙是用来保护业务的，不是用来制造故障的，这句话我一直挂在工位旁边。
