必须先放行SSH端口再启用UFW：执行ufw allow OpenSSH（或ufw allow 22），确认ufw status verbose显示22/tcp允许入站，再ufw enable；若已断连需通过控制台恢复。
ufw 默认拒绝所有入站流量后，SSH 连接直接断开怎么办
默认策略设成 ufw default deny incoming 后立刻 ufw enable，当前 SSH 会话大概率卡死——因为规则生效时，已建立的连接不被豁免，新连接（包括你后续重连的请求）又全被挡在门外。
必须先放行 SSH 端口，再启用防火墙：
-
ufw allow OpenSSH或ufw allow 22（推荐前者，自动适配配置变更） - 确认规则已加载：
ufw status verbose，看到22/tcp ALLOW IN Anywhere - 再执行
ufw enable；如果已断连，只能通过控制台或物理终端恢复 - 注意：
ufw allow OpenSSH依赖/etc/ufw/applications.d/openssh-server文件存在，重装或精简系统可能缺失，此时需手动补上
iptables 规则和 ufw 共存时谁优先级更高
ufw 本质是 iptables 的封装，它生成的规则写在 INPUT、FORWARD 链的靠前位置；但如果你手动用 iptables -I INPUT ... 插入规则，它会插在 ufw 规则之前——意味着手动插入的规则先匹配，可能绕过 ufw 策略。
常见误操作：
- 用
iptables -A INPUT追加规则 → 安全，排在 ufw 规则之后，受其约束 - 用
iptables -I INPUT 1 ...插入到第一条 → 危险，可能跳过 ufw 的 deny 策略 - 重启
ufw会清空所有非 ufw 管理的 iptables 规则（除非你禁用ufw flush行为） - 生产环境建议只用 ufw 管理，避免混用；如必须用 iptables，请统一用
iptables-restore加载完整规则集，并停用 ufw
如何让 ufw 允许特定 IP 访问 MySQL（3306），但禁止其他所有地址
ufw 的 allow from 是按源 IP 匹配，不是“白名单模式”，所以必须配合默认策略才能实现真正限制。
正确顺序不能错：
- 先设默认策略：
ufw default deny incoming - 再精确放行：
ufw allow from 192.168.1.100 to any port 3306 - 检查是否生效：
ufw status numbered，确认该规则序号靠前（ufw 按顺序匹配） - 注意：MySQL 默认绑定
127.0.0.1，若要接受远程连接，还需改bind-address = 0.0.0.0并确保用户有对应 host 权限（如'user'@'192.168.1.100'） - 别用
ufw allow 3306，那等于全放开
systemd 服务启动失败，提示 “Failed to start firewall” 怎么查
ufw 服务启动失败，通常不是 ufw 本身出错，而是底层依赖没就绪——最常见的是网络未就绪或 netfilter 模块未加载。
排查步骤直奔关键点：
- 看具体错误：
journalctl -u ufw --since "1 hour ago" | grep -i "fail\|error"，重点找modprobe: FATAL: Module nf_tables not found类提示 - 检查内核模块：
lsmod | grep nf_，缺nf_tables、nf_nat等说明内核裁剪过度或容器环境不支持 - 确认 systemd 依赖项：
systemctl list-dependencies ufw.service --reverse，ufw 要求network-pre.target就绪，某些云镜像中该 target 被跳过 - 临时绕过：手动运行
ufw --force enable可跳过部分检查，但只是掩耳盗铃，得回溯模块或 init 问题
ufw 表面简单，但它的行为高度依赖内核模块状态、systemd 启动顺序、以及是否与其他网络工具（如 firewalld、docker）冲突；很多“配置生效了”的假象，其实只是某条规则碰巧排在前面而已。
