刚拿到一台新 VPS（虚拟专用服务器），第一件事往往不是装面板，而是处理防火墙：SSH（安全外壳协议）连不上、网站打不开、Ping 得通但端口不通，十有八九都卡在这一层。这篇指南解决的就是这个高频问题——如何用 ufw（Uncomplicated Firewall，Ubuntu 自带的防火墙管理工具）把常用规则配明白，并在端口打不开时按正确顺序排查。在我的测试环境中，一台全新的 Ubuntu 22.04 机器从开启 ufw 到完成 Web 端口放行，只需要六条命令；而排查一个”端口不通”的工单，最常见的原因其实是三个：规则没放行、服务没监听、云平台安全组没开。下面按实际操作顺序展开，每一步都给出可直接复制的命令。
先搞懂 ufw 的默认逻辑：默认拒绝，按需放行
ufw 的设计哲学一句话就能说清：默认拒绝所有入站，默认允许所有出站。你做的每一件事，都是在这个默认策略上”打洞”。相比直接操作 iptables（Linux 内核级防火墙工具）动辄几十条链表规则，ufw 把日常操作压缩成了几句人话命令，这也是它能在 Ubuntu 生态成为默认推荐的原因。
为什么这个默认策略重要？因为大量新手翻车的场景是：先执行 ufw enable，然后 SSH 直接断开，再也连不上。正确顺序永远是——先放行 SSH，再启用防火墙：
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verboseufw status verbose 会显示当前状态、默认策略和已生效规则。如果输出里 Status: active 且三条 allow 都在，Web 基础端口就已经通了。改过 SSH 端口（比如 2222）的机器，务必把 22 换成实际端口——这条规则就是你保命的绳子。
ufw 常用规则：按场景记这六种形态就够了
日常运维中真正高频的规则形态只有六种，逐一列出，建议收藏备用：
- 放行单个端口：
sudo ufw allow 8080/tcp——适用于临时调试的应用端口。 - 按服务名放行：
sudo ufw allow "Nginx Full"——自动展开为 80 和 443，服务名定义在/etc/ufw/applications.d/目录。 - 只允许指定 IP 访问管理端口：
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp——把 SSH 收紧到办公网出口，是性价比最高的一招加固。 - 放行端口段：
sudo ufw allow 6000:6010/tcp——必须显式写/tcp或/udp，否则两个协议会同时放行。 - 删除规则：
sudo ufw delete allow 8080/tcp——也可以先ufw status numbered再按编号删除。 - 显式拒绝：
sudo ufw deny 3306/tcp——对 MySQL（关系型数据库）这类不该暴露的端口明确拒绝，让外部扫描吃闭门羹。
理解规则顺序是避坑的关键：ufw 按添加顺序自上而下匹配，第一条命中的规则生效，后面的不再看。所以”先 deny 后 allow”和”先 allow 后 deny”结果完全不同。举个真实案例：有人想把 SSH 限制到指定 IP，先执行了 allow 22/tcp，事后补了一条 deny 22/tcp，结果所有 IP 照样能连——因为流量在第一条 allow 就命中放行了。正确做法是删掉旧的 allow 规则，只保留带 IP 限制的那条。检查顺序用 sudo ufw status numbered，输出里每条规则前的编号就是匹配优先级。
端口打不开？按这三层顺序排查
“端口不通”很少是单一原因，效率最高的排查方式是按流量经过的路径分层检查：云平台安全组 → 系统防火墙 → 服务监听。任何一层拦住，外部的表现都是同样的超时，所以要一层层排除，而不是上来就乱改配置。
第一层，先确认服务真的在监听目标端口。在服务器上执行：
sudo ss -tlnp | grep -E ':(80|443|8080)'
# 或者老系统
sudo netstat -tlnp | grep 8080如果输出为空，问题根本不在防火墙——是应用没启动，或者绑定到了 127.0.0.1 只接受本机访问。Web 服务必须绑定 0.0.0.0（或公网 IP）才能接受外部流量，这是新手第二常见的坑，实测出现过部署 Node 应用后 localhost 能访问、公网连不上的案例，把监听地址改成 0.0.0.0 后立即恢复。
第二层，检查 ufw 是否放行。sudo ufw status numbered 里找不到对应端口的 allow，就补一条。如果规则存在但排在 deny 之后，按上一节的方法调整顺序。想确认防火墙到底拦了多少包，可以打开日志：sudo ufw logging on，然后 sudo dmesg | grep '\[UFW' 能看到每一条被拦截流量的来源 IP、目标端口和动作，实测比凭感觉猜快得多。
第三层，别忘了云平台安全组。ufw 是系统层防火墙，而多数服务商在宿主网络层还有一道安全组或防火墙模板，两层是串联关系，任何一层不放行都不通。系统里 ufw status 明明放行了、外网 telnet 依然超时，八成是控制台里的安全组没开对应端口。这一层经常被忽略，因为它完全不在服务器内部，ss 和 ufw 都看不到它。排查命令从外部验证：
telnet 203.0.113.50 443
# 或者装了 nmap 的话
nmap -p 443 203.0.113.50输出 Connection refused 和 Connection timed out 含义完全不同：refused 说明流量到了机器但端口没服务，timeout 才是防火墙或安全组在拦截。抓住这个区别，能把排查范围砍掉一半。
顺带说一句，端口问题和网络线路问题要区分开：如果是访问慢而不是彻底不通，那大概率是路由和线路质量的事，可以参考这篇影响美国 VPS 服务器速度的核心因素与优化指南，两者思路互补。另外很多新手纠结 VPS 和虚拟主机怎么选，这篇虚拟主机 vs. VPS：性能、权限与成本全维度对比讲得比较全面——只有拿到独立系统权限，防火墙这一层才归你自己管。
总结：一套可以照抄的上线检查清单
回顾全文，ufw 防火墙管理的核心是三件事：理解”默认拒绝、按需放行”的默认策略，记住六种常用规则形态，排查端口问题时按”服务监听 → ufw → 安全组”的顺序分层检查。把它固化成一套上线流程，新机器开通后照着走一遍：
- 先放行 SSH 实际端口，再
ufw enable，保住连接； - 按业务放行 Web 端口（80/443），数据库端口保持 deny 或不放行；
- 把 SSH 收紧到常用出口 IP，减少暴露面；
- 部署应用后用
ss -tlnp确认监听地址是0.0.0.0； - 外部
telnet验证端口，refused 查服务、timeout 查防火墙和安全组。
建议把这份清单存成运维手册的一部分，每次开通新 VPS 都过一遍。如果你需要一台开箱即可自主管理防火墙的 VPS，Hostease 的美国 VPS（虚拟专用服务器）方案带独立 root 权限和中文客服支持，搭配本文的 ufw 流程可以直接落地；选购前也可以对照这篇美国 VPS 选购指南：五大核心指标一次看懂做决策。防火墙不是配完就结束的东西——每次新增服务、每次收到扫描告警，都回到 ufw status numbered 看一眼规则表，保持最小放行原则。总结成一句话：规则跟着业务走，端口开放必须有明确理由，这台机器的安全性就已经超过大多数同类配置了。
