Ufw规则不生效的四大根源：规则未真正加载、匹配顺序错误（编号小者优先且命中即止）、协议/地址匹配不精确、外部机制覆盖（如Docker、安全组或iptables直写）。
Ufw 规则不生效，通常不是命令输错了，而是规则没匹配上、顺序不对、没启用，或者被其他机制覆盖。核心就四点：规则是否真加载了、是否按预期顺序匹配、是否绑定了正确协议/地址、有没有外部干扰。
确认 Ufw 确实已启用且规则已加载
只看 ufw status 显示 active 不够——它可能只是服务在跑，但底层 iptables/nftables 链没挂载或规则为空。
- 运行
sudo ufw status verbose，检查输出中是否有实际的 To / Action / From 条目；若只有 Status: active 但下面空着，说明没加任何规则或加载失败 - 执行
sudo iptables -L ufw-input -n | head -10（或sudo nft list chain ip filter ufw-input），确认 Ufw 对应链存在且含规则；若报错或为空，表示规则未真正写入内核 - 检查日志：
sudo tail -20 /var/log/ufw.log，看是否有 recent reject/deny 记录——没日志可能意味着流量根本没进 Ufw 链（被更早规则截断或 bypass）
检查规则顺序与匹配逻辑
Ufw 所有规则严格按编号从上到下匹配，命中即停。allow 和 deny 规则共用同一编号序列，数字越小优先级越高。
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 用
sudo ufw status numbered查看带编号的完整列表，注意编号是否连续、是否存在隐藏的默认策略（如 #1 是 deny incoming）挡在前面 - 常见陷阱：先加了
ufw allow 22（自动编号靠后），再手动加 deny 某 IP，但 deny 规则编号更大 → 永远匹配不到；必须把 deny 放在 allow 前面，或直接插到顶部 - 若需封禁特定 IP 或网段，建议写进
/etc/ufw/before.rules中的ufw-before-input链，并放在# End required lines之后，确保早于所有 allow 规则执行
验证端口、协议与地址是否精确匹配
Ufw 默认只处理 IPv4，若客户端走 IPv6，或规则里漏写 proto tcp，或源地址写成 192.168.1.100 却实际连的是 NAT 后地址，都会导致不生效。
- 用
sudo ss -tuln | grep :端口确认服务确实在监听，且绑定的是0.0.0.0或对应网卡地址，而非127.0.0.1 - 测试时用
nc -zv 本机IP 端口（本地）和nc -zv 其他机器IP 端口（远程），区分是本机 loopback 通还是外部不通 - 规则中明确指定协议更稳妥，例如：
sudo ufw allow proto tcp from 192.168.1.0/24 to any port 80，避免因 UDP/TCP 混淆漏匹配
排查外部覆盖与底层冲突
Ufw 并非独占防火墙。Docker、iptables 直接操作、NetworkManager 甚至云平台安全组，都可能绕过它。
- Docker 默认会修改
iptables FORWARD链并禁用 Ufw 的转发控制；检查sudo docker info | grep -i 'iptables\|forward'，若显示iptables: true且ip-forward: true，说明 Docker 正在接管，Ufw 对容器间或宿主机转发的规则可能无效 - 运行
sudo iptables -S | grep -E '^-A (INPUT|FORWARD)'，查看原始 INPUT 链首条规则是否为-j ufw-input；如果不是，说明其他工具（如自定义脚本）插入了更高优先级规则 - 云服务器务必同步检查厂商控制台的安全组（Security Group）设置，它在网络层早于 Ufw 生效；Ufw 放行了，安全组没开，照样不通
