Ubuntu UFW 防火墙配置：先保住 SSH，再开放网站端口
Ubuntu 上的 UFW 用来管理主机防火墙规则。第一次配置时，最需要保护的是当前管理通道：先确认 SSH 真实端口，添加允许规则，再启用防火墙。仅在旧窗口里能继续敲命令，并不能证明新的 SSH 连接也能进来。
本文以 Ubuntu 24.04、普通公网网站为例。已有控制面板、容器平台、VPN 或复杂路由规则的服务器，应先了解谁在管理防火墙；不要把本教程当成重置脚本。
配置前先画清两道门
如果平台提供云安全组，它控制流量进入服务器前的一道入口；UFW 则运行在操作系统里。访问网站需要业务监听端口、主机规则和云侧规则共同允许。修改其中一层，不能自动修复另一层的阻断。
先保留正在使用的 SSH 会话，同时确认服务器控制台或救援方式可用。记录现有规则，检查 SSH 当前连接与监听状态：
# Ubuntu 服务器
printf '%s\n' "$SSH_CONNECTION"
sudo ss -lntp
sudo ufw status verbose
sudo ufw status numbered
SSH_CONNECTION 通常依次给出客户端地址、客户端端口、服务器地址和服务器端口，最后一项才是本次 SSH 连接的服务端端口。若通过跳板机或端口转发接入，结合监听结果和平台配置确认。不要看到教程用 22 就认定自己的机器也用 22。
第一步：先放行当前 SSH 入口
下面的 22 只是示例，替换为实际端口后执行。公网地址固定时，可以在验证基础连通后再进一步限制来源。
# Ubuntu 服务器：先核对端口，再添加规则
sudo ufw allow 22/tcp comment 'SSH management'
sudo ufw status numbered
在云安全组中也核对同一端口和你的来源地址。若 UFW 显示未安装，先查看现有防火墙管理方案；确认没有其他工具负责该任务后，再从 Ubuntu 软件源安装 ufw。不要因为它缺席就清空 iptables 或 nftables。
为什么不直接使用“允许 OpenSSH”应用规则？该规则有自己的端口定义，未必跟随你改过的 SSH 配置。显式填写并核对真实端口，更容易发现不一致。Ubuntu UFW 手册列出了应用规则、端口规则和状态查看方式。
第二步：为业务开放必要端口
普通 HTTP 与 HTTPS 网站通常需要 TCP 80 和 TCP 443：
# Ubuntu 服务器：仅在确有网站服务时添加
sudo ufw allow 80/tcp comment 'Website HTTP'
sudo ufw allow 443/tcp comment 'Website HTTPS'
数据库、Redis、后台管理接口通常不需要直接暴露公网。先考虑本机回环、私有网络或经过认证的管理通道，再决定是否添加公网规则。不要为了排错一次开放所有端口；这会让“究竟哪个入口需要允许”变得更难判断。
新服务器采用默认拒绝入站、允许出站，可以作为常见起点。已有生产环境应先确认健康检查、备份、监控、邮件以及转发依赖，不能直接改变默认策略。
# Ubuntu 服务器：仅用于已核对依赖的新配置
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable
sudo ufw status verbose
命令按顺序逐条执行，先确认放行 SSH 的步骤已完成。不要忽略启用时的提示，也不要把它放进不检查中间结果的一键脚本。
第三步：从服务器外部验收
保留旧窗口，在个人电脑新开 SSH 连接。再用浏览器访问实际域名的网站；如果 HTTPS 尚未配置，只验证已部署的 HTTP 服务。Windows 可在本机 PowerShell 检查端口：
Test-NetConnection 203.0.113.10 -Port 22
Test-NetConnection 203.0.113.10 -Port 80
示例地址需要替换。端口可连接只说明 TCP 通路成立，不代表网站内容、证书或登录流程正确。若服务器本地可以访问网站，外部超时，依次核对监听地址、UFW 和云安全组；若所有入口都正常但返回错误页面，应转向应用排查。
IPv6 和 Docker 需要单独核对
域名配置 AAAA 记录后，部分访问会走 IPv6。应同时检查 IPv6 地址、服务监听以及云侧规则。UFW 是否管理 IPv6 与系统设置有关，可以核对 /etc/default/ufw；不要通过随意关闭 IPv6 来掩盖错误解析。
Docker 发布容器端口时会参与网络规则处理，不能仅凭 UFW 的拒绝规则就认定容器端口没有对外开放。Docker 防火墙文档说明了这类交互。管理型应用可先绑定 127.0.0.1，由受控反向代理提供入口，并从外网实际验证。不要为了适配 UFW 直接清空 Docker 创建的规则。
修改与恢复都应只针对已确认的规则
需要撤回某条规则时，先运行 sudo ufw status numbered，核对编号与内容后逐条删除；删除后编号会变化，不能沿用旧编号连续操作。不要执行重置或批量清空规则来“重新来过”。
如果新 SSH 会话失败，优先在保留窗口修正端口或来源规则；旧窗口不可用时，通过控制台处理。每次调整后记录用途、负责人和验证结果，后续下线业务时再移除对应入口。防火墙的可维护性，来自每条规则都有明确的业务理由。