UFW 默认关闭，启用前必须先放行 SSH 端口并执行 sudo ufw enable，否则规则不生效；ufw status 显示 inactive 即未运行，所有 allow 规则无效；default deny incoming 需配合显式 allow 才安全；ufw allow 应指定协议如 22/tcp；删除规则需用 numbered 查编号后删除，避免残留。
UFW 默认是关闭的，不配置就等于没防火墙；启用前必须先放行 SSH 端口，否则可能被锁在服务器外。
ufw status 显示 inactive 就代表没生效
这是最常被忽略的第一步。执行 sudo ufw status 后如果输出 Status: inactive，说明防火墙根本没运行——所有规则都只是写在配置里，没加载进内核。此时即使你执行过 sudo ufw allow 22，也毫无防护作用。
常见错误现象：
- 明明写了
sudo ufw allow 80，但网页打不开 → 其实 firewall 没开，80 端口根本没被放行 -
ufw status输出空或只显示“Status: inactive” → 忘了执行sudo ufw enable
正确操作顺序：
- 先检查状态：
sudo ufw status - 若为
inactive，立刻执行：sudo ufw enable（系统会提示确认） - 再检查一次：
sudo ufw status应显示Status: active并列出规则
ufw default deny incoming 是安全基线，但必须配合 allow 规则
这条命令不是“一键封死”，而是把入站流量的默认行为设为拒绝。它本身不放行任何端口，所有服务（包括 SSH、HTTP）都得手动加 allow 才能通。
为什么必须做？
- 避免遗漏：比如只开了
80却忘了关3306，default deny能兜底拦截未声明的端口 - 符合最小权限原则：只开放明确需要的服务，而不是靠“没写 deny 就默认通”来赌运气
典型误操作：
Ubuntu 26.04 LTS（代号“Resolute Raccoon”）是Canonical于2026年4月23日发布的下一代长期支持版操作系统，提供长达10年的技术支持。它搭载Linux 7.0内核与GNOME 50桌面环境，全面转向Wayland协议，并引入Rust重写的核心工具以增强安全性。官方提供适用于AMD64和ARM64架构的桌面及服务器ISO镜像，是追求前沿技术与极致稳定的开发者
- 先执行
sudo ufw default deny incoming，再执行sudo ufw allow 22，但中间忘了sudo ufw enable→ 规则白设 - 执行了
default deny，却没加allow 22就直接enable→ SSH 断连，无法重连
ufw allow 的写法差异直接影响协议和来源控制
看似都是“放行端口”，但写法不同，效果天差地别：
-
sudo ufw allow 22→ 默认同时放行 TCP 和 UDP 的 22 端口（SSH 实际只用 TCP，UDP 22 无意义） -
sudo ufw allow 22/tcp→ 只放行 TCP 22，更精确，推荐写法 -
sudo ufw allow from 192.168.1.100 to any port 22→ 仅允许指定 IP 访问 SSH，比全网开放安全得多 -
sudo ufw allow proto tcp from 10.0.0.0/8 to any port 8080→ 支持 CIDR 网段 + 协议 + 端口三重限定
注意：ufw allow ssh 是别名写法，依赖 /etc/ufw/applications.d/ 下的预定义配置，不如直接写端口号+协议可控。
删除规则不能只靠 ufw delete allow 80
当一条规则被多次添加（比如误操作重复执行 ufw allow 80），ufw status 会显示多条相同规则；此时用 sudo ufw delete allow 80 只删第一条，其余照旧生效。
真正可靠的清理方式：
- 先看编号：
sudo ufw status numbered（输出带 [1], [2], [3] 编号） - 再按号删：
sudo ufw delete 2（删第 2 条） - 或者重置全部：
sudo ufw reset（慎用，会清空所有自定义规则，包括 SSH）
容易被忽略的点：删除后不会自动 reload，但 UFW 规则变更本身就是实时生效的，无需重启服务。
最易出问题的环节不在语法，而在于执行顺序——enable 必须在 allow 之后、且确保关键端口（尤其是 SSH）已写入规则；否则一启用就失联。规则写得再准，没 enable 就等于没写。
