导读：本站SSH篇讲过"安全组不放行端口当场失联"，Docker篇提过"Registry只适合内网"，多篇教程里"防火墙放行端口"这句话反复出现，但防火墙本身一直没正面讲过。这篇补上这块拼图：ufw的默认策略为什么是allow会出大事、按服务名放行比按端口号更稳、Docker会绕过ufw的经典大坑、删除规则的正确顺序、以及限速和日志两个进阶玩法。ufw的全称是Uncomplicated Firewall——不复杂的防火墙，这篇的目标是让你五分钟配完、十年不用改。
一、先搞清楚：ufw、iptables、nftables是什么关系
Linux内核的包过滤框架是netfilter，iptables和nftables是直接操作它的两代命令行工具，功能强大但语法劝退。ufw是Ubuntu/Debian在iptables之上包的一层简化皮，把"放行80端口"从五行链表操作变成一行人话。所以ufw不是另一套防火墙，而是iptables的易用前端——这意味着两件事：ufw看不见的规则可能被底层iptables直接插入（Docker就是这么干的，后面细讲）；CentOS/RHEL系用firewalld扮演类似角色，思路相通语法不同，本文以Debian系的ufw为准。
二、安装与默认策略：先想清楚再动手
apt install ufw
装完先别急着enable，第一步是定默认策略。ufw的哲学是"默认全部拒绝，按需放行"（deny incoming, allow outgoing），这是安全界的金标准：
ufw default deny incoming ufw default allow outgoing
危险的相反操作是default allow incoming——每台机器上所有端口对全世界敞开，MySQL的3306、Redis的6379全在裸奔，扫描器一晚上就能把你变成别人的肉鸡。默认拒绝的意思是：你没放行的，一律进不来。这时候SSH的22端口也会被拒，所以enable之前必须先放行它，否则当场失联——这个顺序错误是ufw的第一大翻车现场，和SSH篇讲的"改配置前确认VNC可用"是同一个道理。
三、放行规则：按服务名，别记端口号
ufw limit ssh
这一行就放行了SSH并带限速。ufw内置了/etc/services映射，常见服务都能用名字：ufw allow http、ufw allow https、ufw allow 3306/tcp。带/tcp或/udp后缀指定协议，不带则两个都放。指定来源IP的白名单玩法：
ufw allow from 203.0.113.5 to any port 22 proto tcp
只有这个IP能连你的SSH——SSH篇讲的安全组白名单思路，在主机层面用ufw实现就是这个语法。端口范围和具体端口一样支持：
ufw allow 60000:61000/udp
这是mosh或一些语音服务需要的UDP段。
四、查看与删除：编号删除法
ufw status numbered ufw delete 3
输出里每条规则前面有编号，删除按编号来。高频翻车点来了：删除编号3之后，原来的4就变成了3，所有后面的规则整体前移。连续删两条的正确姿势是先删编号大的再删编号小的，或者每删一条就重新status一次。想清空重来直接：
ufw reset
规则全清、回到未启用状态，测试期的救命稻草。
五、Docker绕过ufw：全宇宙最著名的坑
症状：ufw status明明显示只放行了22和443，但你docker run -p 8080:80起的容器，外网直接就能访问8080。原因：Docker为了端口映射的性能和直通，直接在iptables的nat表插规则，绕过了ufw管理的filter链。你精心设计的默认拒绝策略在Docker面前形同虚设。三个应对层次：第一层，发布端口时绑定本机地址，-p 127.0.0.1:8080:80，配合Nginx反代对外——本站反代篇的标准玩法，顺带还获得了TLS和限速；第二层，需要对外暴露的容器端口，老老实实在ufw里也放行，并接受它绕过默认策略的事实；第三层，改Docker的daemon.json加"iptables": false彻底关掉，但这会破坏Docker自身的网络功能，除非你非常清楚后果，否则别碰。个人建议直接采用第一层，这也是本站Docker系列一贯推荐的姿势。
六、限速：给SSH加个减速带
limit修饰符的含义：同一个源IP在30秒内发起超过6次连接，直接拒绝。它不是完整的防爆破方案（fail2ban按认证失败封禁，更精准），但胜在零成本零依赖，给SSH加一道"连接层面"的减速带，和fail2ban的"认证层面"防线形成纵深——SSH篇讲的两层防御在这里落地。
七、日志：被拒的连接都去了哪
ufw logging low dmesg | grep '[UFW BLOCK]'
开启后，被拒绝的连接会写进系统日志。用途很实际：服务不通时先看是不是被UFW BLOCK了——"应用没监听"和"防火墙拦了"是两种完全不同的故障，日志一行就能分清。low级别只记被拒包，medium以上会记录所有允许的包，日志量暴涨，个人VPS用low足够。排障心法：curl不通、端口监听正常、服务正常，三线交汇时第一个怀疑对象就是防火墙——本机ufw、云厂商安全组，两道闸门按顺序查。
八、规则持久化与开机自启
ufw enable这个动作同时完成了"立即生效"和"开机自启"两件事，规则自动持久化，没有iptables那个save的坑。systemctl status ufw可以确认服务状态。一个容易被忽略的细节：ufw的规则文件在/etc/ufw/，其中before.rules里的注释行允许必要的基础协议（如ICMP），别手贱删ICMP放行——删掉之后你自己的ping诊断、路径MTU发现全废，网络疑难杂症的排查难度直接翻倍。
九、放行清单模板：一台典型Web服务器的全部规则
ufw default deny incoming ufw default allow outgoing ufw limit ssh ufw allow http ufw allow https ufw enable
五行规则覆盖了"SSH有减速带、网站全放行、其余全拒绝"的安全基线。跑邮件服务器的还要放行25、465、587、993；跑DNS的放行53（注意UDP和TCP都要）；跑监控探针的按本站哪吒篇的文档放行对应端口。原则始终如一：每一条放行规则都应该能回答"为什么需要它"——回答不了的端口，就让它保持关闭。
结语
ufw的全部心智模型一句话：默认拒绝进来、按需放行出去，规则要少而精，Docker的-p要绑127.0.0.1。它不追求iptables的全能，只求覆盖个人服务器99%的需求——安全工具的第一美德是"会被正确使用"，而不是"功能最多"。配合本站SSH篇的密钥登录、HTTPS篇的加密传输，你的VPS在网络这个维度就做到了端口最小暴露。剩下的，交给日志去告诉你谁在敲门。
