Linux服务器ufw防火墙怎么配？端口放行、SSH与云安全组实战

ufw是Ubuntu/Debian上管防火墙最省事的工具，它本质是iptables/nftables那套复杂规则的“傻瓜前端”——你敲一句ufw allow 22，它在底层翻译成一长串iptables规则。对绝大多数独立站和外贸服务器来说，把ufw配明白，服务器的网络安全底子就立住了一大半。

保哥这篇从ufw和底层iptables的关系讲起，把装好第一件该做什么、默认策略怎么设才不会把自己SSH关在门外、端口和服务怎么放行、怎么只对特定IP开敏感端口、规则怎么查怎么删、日志怎么开又不爆盘、怎么和云厂商安全组配合，一路讲到最容易踩的坑。命令能抄走就用，每一条都标了为什么这么写。

先说个保哥见过太多次的惨案：有人SSH登上一台新服务器，听说要装防火墙，敲了 ufw enable 回车，连接当场断开，再也连不上了。因为ufw的默认策略是“拒绝所有入站”，你一启用它就把还没放行的SSH（22端口）一起拒了，而你正是从SSH连进去的。这台机器要是云服务器还好，能从控制台的网页终端（VNC）救回来；要是托管的物理机，可能就得联系机房了。

这个坑几乎人人都踩过一次。所以这篇文章保哥会反复强调操作顺序——防火墙这东西，配错了不是报个错那么简单，是会把你自己锁在门外的。咱们一步步来，确保你每一步都安全。

ufw到底是什么？和iptables、nftables是什么关系？

要用好ufw，得先知道它在整个Linux防火墙体系里站哪一层。Linux内核里真正干“拦数据包”这件事的，是一个叫 netfilter 的子系统，它是内核级别的包过滤框架。而我们在命令行里操作的工具，是netfilter的用户态前端。

历史上这个前端是 iptables，它功能强大但语法极其劝退——一条规则动辄十几个参数，链（chain）、表（table）、跳转目标搅在一起，新手看一眼就晕。后来新一代的 nftables 出来想取代iptables，语法清爽些，现在的Ubuntu底层默认已经走nftables，但很多人还是觉得直接写它太复杂。

ufw（Uncomplicated Firewall，“不复杂的防火墙”）就是为了解决这个痛点而生的。它名字里的Uncomplicated就是卖点——它是iptables/nftables的一层友好封装。你敲 ufw allow 80/tcp，ufw在背后帮你生成并下发一长串底层规则。你不用懂链和表，只要会说“放行80端口”这种人话就行。

所以三者的关系一句话说清：netfilter是内核里干活的，iptables/nftables是操作它的底层命令，ufw是骑在它们之上的便捷前端。它们管的是同一套东西，所以一个铁律——别在同一台机器上又用ufw又手动iptables改规则，两边各改各的，规则会打架，最后谁也搞不清当前到底放行了什么。要么全程ufw，要么全程裸iptables，别混。对独立站、外贸服务器这种场景，保哥的建议是无脑选ufw，够用、不易错。

装好ufw第一件事先做什么？默认策略怎么设才不会把自己关在门外？

大多数Ubuntu自带ufw，没有就 sudo apt install ufw 装一下。装完千万别急着enable，按保哥这个顺序来，一步都不能跳：

第一步，先看默认策略。ufw的出厂默认是“拒绝所有入站、允许所有出站”，这是个很合理的安全基线——别人主动连你的，默认全拦；你主动连别人的（比如服务器去拉软件包、连数据库），默认全放。

理解这个“默认拒绝入站”是用好ufw的根基：它意味着你不需要去一个个拦截端口，而是反过来，默认什么都不开，只把你确实要对外提供的服务一条条放行进来。这种“白名单”思路比“黑名单”（默认全开、再去封危险端口）安全得多——黑名单你永远不知道漏封了哪个口，白名单则是没明确放行的一律进不来，心里有底。可以显式确认一下默认策略：

sudo ufw default deny incoming
sudo ufw default allow outgoing

第二步——也是救命的一步——在enable之前，先把SSH放行。这是避免把自己锁在门外的关键：

sudo ufw allow OpenSSH
# 或者直接按端口号（如果你改过 SSH 端口，这里必须写实际端口）
sudo ufw allow 22/tcp

这里有个魔鬼细节：如果你按保哥在 SSH登录加固那篇里讲的把SSH默认端口从22改成了别的（比如2222），那这里就必须放行2222而不是22，否则enable之后照样连不上。改了SSH端口又忘了在防火墙放行新端口，是仅次于“裸enable”的第二大翻车原因。

第三步，确认SSH规则已经在列表里了，再启用：

sudo ufw show added      # 看看待生效的规则里有没有 SSH
sudo ufw enable          # 这时启用才安全

enable时它会提示“这可能会中断现有SSH连接”，因为你已经放行了SSH，放心敲y。启用后用 sudo ufw status verbose 看一眼，能看到默认策略和已放行的端口，SSH在列就稳了。保哥的习惯是enable之后另开一个终端窗口重新SSH连一次试试——别关掉当前这个还活着的连接，万一连不上还能用旧窗口救场。这个习惯救过保哥好几次。

端口和服务怎么放行？allow、deny的几种写法该用哪种？

ufw放行规则的写法很灵活，但灵活也意味着容易写错。保哥把常用写法按场景捋一遍。

最常见的是按端口放行。Web服务器要开80和443：

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
# 不写协议则 TCP 和 UDP 都放，一般 Web 端口明确写 /tcp 更干净
sudo ufw allow 443

也可以按服务名放行。ufw内置了一批应用配置档（application profiles），放在 /etc/ufw/applications.d/ 里，把常见服务的端口预定义好了。比如装了Nginx，就能直接：

sudo ufw app list                 # 看有哪些预定义档
sudo ufw allow 'Nginx Full'       # 一次放行 80+443
sudo ufw allow 'Nginx HTTP'       # 只放 80
sudo ufw allow OpenSSH            # 放 22

服务名写法的好处是直观、不容易记错端口号，缺点是只对有预定义档的服务管用。还有一种是按 /etc/services 里的服务名，比如 sudo ufw allow http，ufw会去那个文件里查http对应80端口。

保哥的实战建议是：Web端口（80、443）、SSH这种标准服务，用服务名或带 /tcp的端口号都行，怎么顺手怎么来；但凡是非标准端口、或者你自己应用监听的端口（比如某个跑在8080的后台、某个9000的管理面板），一律写清楚端口号加协议，别图省事不写协议。

为什么强调写协议？不写协议ufw会TCP、UDP都放行，平白多开了你压根没用到的UDP口，攻击面无谓地大了一圈。防火墙的原则永远是“最小放行”：用到哪个口才开哪个口，开了就写得明明白白，别留一堆你自己都说不清为什么开着的端口。每隔一阵用 ufw status 把规则全过一遍，看到不认识的、想不起来为什么开的，先查清楚再决定要不要删，这是个好习惯——服务器跑久了，最怕的就是一堆历史遗留的放行规则没人敢动，攻击面就是这么一点点失控的。

放行一段端口范围要注意必须带协议：

sudo ufw allow 6000:6010/tcp      # 范围必须写 /tcp 或 /udp

说回allow和deny。allow是放行，deny是拒绝。这里有个容易忽略的区别——deny和reject不一样。deny是“默默丢弃”数据包，对方那边表现为连接超时，半天没反应；reject是“明确拒绝”，会回一个拒绝信号，对方立刻知道被拒了。

从安全角度，对外网暴露的端口用deny（默默丢弃）更好，因为让扫描者连不上又得不到任何反馈，不知道这端口到底是关着还是被防火墙挡了，增加了探测成本。绝大多数情况下你不需要手动写deny，因为默认策略已经把没放行的全拒了，deny主要用于在某些特殊场景下精确拦某个IP或端口。

还有一个特别实用的写法叫 ufw limit，是专门防爆破的。它不是简单放行或拒绝，而是“放行，但如果同一个IP在短时间内反复发起连接（默认30秒内超过6次），就把它临时拦掉”。最典型的用法是给SSH加速率限制：

sudo ufw limit 22/tcp
# 或服务名写法
sudo ufw limit OpenSSH

这一条对付密码爆破特别管用——正常人SSH登录不可能30秒连6次，而爆破工具一秒就试好几个密码，limit会自动把这种高频来源掐掉一阵。它和fail2ban思路类似但更轻量，fail2ban是分析日志后封IP、能封更久，ufw limit是内核层直接限速、零额外进程。小站点光靠ufw limit就能挡掉一大半无脑爆破，配fail2ban则是双保险。

怎么只让特定IP访问敏感端口，比如SSH、数据库？

这是ufw最值钱的能力之一，也是把服务器安全往上抬一大截的关键操作。很多端口你根本不想对全世界开放——数据库的3306、Redis的6379、甚至SSH，理想情况是只允许你自己的办公网IP或跳板机连，其他人连敲门的资格都没有。

用 from 限定来源IP：

# 只允许某个固定 IP 连 SSH
sudo ufw allow from 203.0.113.5 to any port 22 proto tcp

# 只允许某个内网段连 MySQL
sudo ufw allow from 10.0.0.0/24 to any port 3306 proto tcp

# 只允许单个 IP 连 Redis
sudo ufw allow from 203.0.113.5 to any port 6379 proto tcp

这几条的威力在于：配了之后，数据库和Redis端口对公网就是彻底隐身的，扫描器扫不到、爆破工具连不上。保哥强烈建议——数据库、缓存这类内部服务的端口，永远不要对0.0.0.0全开。能绑内网就绑内网，要跨机器访问就用from限定来源。每年都有大量数据泄露事故，根因就是MySQL、Redis、MongoDB的端口裸奔在公网上，连密码都是默认的。

SSH也可以这么收紧。如果你有固定的办公IP或一台跳板机，把SSH限定成只允许它们连，那哪怕你密码弱一点，外面的爆破工具也根本碰不到你的22端口。当然前提是你的来源IP真的固定——家庭宽带IP会变的话，限死了反而把自己关外面。IP不固定的话，配合fail2ban自动封爆破源是更现实的方案，保哥在SSH加固那篇里讲了组合拳。

一个真实场景。保哥帮一个外贸团队收拾过一台被入侵的服务器，最初的症状是网站越来越慢、负载飙到十几，按 服务器变慢排查那篇的路子一查，发现CPU长期100%，有个陌生进程在疯狂占资源——挖矿程序。顺藤摸瓜，黑客是从裸奔在公网的Redis（6379没设密码、没限IP）打进来的，Redis有个老套路能让攻击者往系统里写文件，植入了挖矿木马。

事后加固就一条核心动作：ufw allow from 内网段，把6379对公网彻底关死，外加Redis自己设密码。一道命令，这类攻击面直接归零。敏感端口限IP，是性价比最高的安全操作，没有之一。保哥后来复盘，要是这台机器一开始就把数据库、缓存端口用from限死，根本不会有后面这一摊子事——防火墙的价值，往往在出事之后才被人记住，但它该在出事之前就配好。

规则乱了怎么查、怎么删、怎么调顺序？

配着配着规则就多了，难免要回头查、删、调。这里的关键是理解ufw规则是有顺序的，从上到下匹配，命中第一条就生效，后面的不再看。

先看规则，一定要带编号看：

sudo ufw status numbered

它会给每条规则标上 [1] [2] [3] 的序号，删的时候靠这个号。删规则有两种写法：

# 按编号删（推荐，最直观）
sudo ufw delete 3

# 按原规则删（要和当初添加时写的一模一样）
sudo ufw delete allow 80/tcp

按编号删要注意：每删一条，后面的编号会自动往前补位。所以要删多条时，从大编号往小编号删，或者每删一条重新status numbered看一遍最新编号，否则容易删错。这个坑保哥踩过——一口气想删第2、3、4条，删完第2条后，原来的第3条变成了第2条，你再删“第3条”删的其实是原来的第4条，全乱套。

顺序为什么重要？因为匹配是从上往下、命中即停的。假设你想“拒绝某个IP，但放行其他所有人访问80”，那条deny特定IP的规则必须排在allow 80的前面，否则请求先命中了allow 80就放行了，根本轮不到后面那条deny。要把规则插到指定位置，用insert：

# 把这条规则插到第 1 位
sudo ufw insert 1 deny from 198.51.100.7

实在改乱了想重来，sudo ufw reset 会清空所有规则恢复出厂——但注意，reset之后默认策略也回到初始，重新配置时第一件事还是先放行SSH再enable，别又把自己锁外面。

怎么开日志看谁在敲门，又不让日志爆盘？

防火墙不光要拦，还得让你看见“拦了谁、谁在试图敲门”，这对发现攻击苗头很有用。ufw的日志开关很简单：

sudo ufw logging on        # 开启日志（默认 low 级别）
sudo ufw logging medium    # 信息更全
sudo ufw logging off       # 关闭

开启后，被防火墙拦下的连接会记到系统日志里（一般在 /var/log/ufw.log，或通过journald查），每条带着来源IP、目标端口、协议。你能从中看到有多少扫描器在敲你的端口、都盯着哪些端口（数据库端口被高频探测说明你的端口配置可能暴露了）。

怎么从日志里读出有用信息？保哥常用的一招是统计被拦最多的来源IP和被探测最多的端口。把ufw.log里的拦截记录按来源IP排个序，前几名往往是固定的几个扫描源，可以直接deny掉；按目标端口排序，则能看出攻击者最惦记你哪些服务——常年被敲的就是22（SSH）、3306（MySQL）、6379（Redis）、3389（远程桌面）这些。

如果你发现某个本不该对外的端口出现在高频探测里，说明它可能在某个时间点被暴露过，赶紧查规则。这种从防火墙日志里反推攻击意图的习惯，能让你在真出事之前就嗅到苗头，比被动等着出问题强得多。说到底，防火墙日志不是开了就完事，它是你了解“服务器正面对什么威胁”的一扇窗，定期扫一眼，心里对自己机器的安全态势才有数。

但日志级别别开太高。high 和 full 会把大量数据包都记下来，公网服务器上扫描流量是天量的，开高级别日志几天就能把磁盘写满，到时候不是防火墙保护了你，是日志把你的服务器搞挂了。保哥的建议是平时 low 就够，需要排查具体问题时临时调 medium，查完调回去。

不管开哪个级别，都得配合日志轮转，别让它无限长。ufw日志走的也是系统那套日志管理，logrotate和journald怎么配才不爆盘，保哥在 Linux服务器日志管理那篇里讲得很细，防火墙日志一并纳入那套管理就行，原理是相通的。要是你已经把运维任务用cron自动化了，也可以加一条定期分析ufw日志、把高频攻击源汇总出来的任务，保哥在 cron运维自动化那篇里有现成的思路可以套。

改完规则要重启ufw吗？规则会开机自动生效吗？

新手常纠结一个问题：每次allow、delete之后，要不要手动重启ufw才生效？答案是不用。ufw的规则是即时生效的——你敲完 ufw allow 8080 回车，这条规则当场就下发到内核了，新连接立刻按新规则走，不需要重启任何东西。这点和有些服务（改了配置得reload）不一样，ufw改一条生效一条。

那 ufw reload 是干嘛的？它是在你手动改了ufw的配置文件（比如 /etc/ufw/ 下面那些规则文件）之后，让ufw重新读取并应用。日常用命令行allow/deny的话基本用不到reload，命令本身已经即时生效了。

另一个关键问题：规则会不会在服务器重启后丢失？不会，这正是ufw比裸iptables省心的地方之一。iptables的规则默认是存在内存里的，机器一重启就全没了，得自己想办法持久化（装iptables-persistent之类）。而ufw的规则是写在配置文件里的，ufw enable 时它就把自己设成了开机自启服务，服务器重启后会自动加载所有规则、自动激活，你不用做任何额外操作。所以你配一次，之后无论重启多少次，防火墙都老老实实在岗。

不过有一点要留心：如果你是在云服务器上，重启后偶尔会遇到“ufw规则在、但某个服务连不上”，这往往不是ufw的问题，而是云安全组或者服务本身没起来。排查时先 ufw status 确认规则还在（基本都在），再看服务进程和云安全组，别一上来就怀疑防火墙把规则弄丢了——ufw在持久化这件事上是很靠谱的。

ufw怎么和云厂商的安全组配合，别两层互相打架？

这是租云服务器的人最容易困惑的点：阿里云、腾讯云、AWS这些平台，本身在网络层就提供了“安全组”（Security Group）——一套云控制台里配的防火墙规则。那服务器里再装个ufw，不就两层防火墙了吗？会不会打架？

会，而且经常打架，但理清楚就不乱。这两层是串联关系，数据包要先过云安全组，再过服务器里的ufw，两道都放行了才能真正到达服务。任意一层拦了，连接就不通。所以排查“端口明明放行了还连不上”时，得两层都查：

• 只在ufw放行、安全组没放：数据包在云的网络层就被拦了，根本到不了你的服务器，ufw配得再对也没用。这是新手最常见的困惑——“我ufw明明allow了8080啊”，结果安全组里没开。
• 只在安全组放行、ufw没放：包到了服务器，被ufw拦下。
• 两层都得放：要让一个端口真正可访问，云安全组和ufw必须都放行它。

那要不要两层都用？保哥的实战经验是：云安全组当第一道粗筛，ufw当服务器内的精细控制，各有分工，建议都配但规则保持一致。安全组在网络层就把大部分流量挡在机器外面，连服务器的CPU都不用消耗去处理这些被拒的包，这是它的优势；ufw的优势是更灵活、能做更细的来源IP控制、改起来不用登云控制台。两者配合，安全组管“大门开哪几个口”，ufw管“进了大门后细分谁能去哪”。最忌讳的是两层规则对不上——安全组开了一堆端口，ufw又默认全拦，结果天天排查为什么不通。配的时候记一份清单，两边对齐，省心。

实战里最容易踩的坑有哪些？

把保哥这些年用ufw踩过、见过的坑集中列一遍，配防火墙前对一遍，能避开绝大多数事故：

• 裸enable把自己SSH关在门外：头号大坑。enable之前必须先allow SSH（或你改过的实际端口），并status确认在列。
• 改了SSH端口忘了放行新端口：把22改成2222，ufw里却allow的还是22，enable后连不上。改端口和放行新端口要同步做。
• ufw和手动iptables混用：两边各改各的规则会打架，且互相覆盖。选一个用到底，别混。
• 数据库、Redis端口对公网全开：3306、6379、27017这类内部服务端口裸奔公网是重大安全隐患，必须用from限来源IP或只绑内网。
• 忘了云安全组这一层：ufw放行了还连不上，八成是云安全组没放。两层串联，都得放。
• 规则顺序搞反：deny特定IP的规则排在了allow通用规则后面，命中即停导致deny永远不生效。特例规则要insert到前面。
• 批量删规则编号错位：删一条后面编号会补位，从大到小删，或每删一条重看一遍编号。
• 日志级别开太高爆盘：high/full在公网服务器上几天就写满磁盘。平时low，排查时临时medium。
• reset后忘了重新放行SSH：reset恢复出厂默认拒绝入站，重配时第一步还是先allow SSH再enable。
• IP不固定却把SSH限死单IP：家庭宽带IP会变，限死了换IP就进不去。IP不固定的用fail2ban防爆破更现实。

ufw这工具，命令本身没几个，难的全在“操作顺序”和“别把自己锁外面”这根弦。把先放行SSH再enable、敏感端口限IP、和云安全组对齐这几条刻进肌肉记忆，再配合status numbered反复确认当前规则，一台服务器的网络安全基线就稳稳立住了。

最后再叮嘱一句保哥的老规矩：每次动防火墙规则，尤其是在远程服务器上，都另开一个终端验证一遍还连得上再关旧窗口。它不是万能的——防住的是网络层的乱敲门，应用层的漏洞（比如程序自身的注入、越权）还得靠代码和别的手段补，防火墙拦不到走正常端口进来的恶意请求。但作为第一道墙，把没必要暴露的端口全关在外面，性价比极高，是每台对外服务器上线之前都该配好的基本功，花不了十分钟，能挡掉绝大多数无差别攻击。

常见问题解答

ufw和firewalld有什么区别？我该用哪个？

两者都是iptables/nftables的前端，定位类似，主要是发行版习惯不同。ufw是Ubuntu/Debian系的默认选择，命令简单、面向单机场景，独立站和外贸服务器用它最顺手。firewalld是CentOS/RHEL/Fedora系的默认工具，引入了“区域（zone）”的概念，更适合网络环境复杂、多网卡多信任级别的场景。你用什么发行版就用配套那个，别在Ubuntu上硬装firewalld自找麻烦。对绝大多数建站场景，ufw的能力完全够用。

我已经有云服务器的安全组了，还有必要在系统里装ufw吗？

有必要，两层是互补的。安全组在云的网络层拦截，连服务器都到不了，省服务器资源；ufw在系统内，更灵活、能做更细的来源IP控制、不用登云控制台就能改。更重要的是，ufw能防住一些安全组覆盖不到的场景，比如同一内网里其他机器之间的横向访问。保哥的建议是两层都配，安全组管粗筛、ufw管精细，但两边规则要对齐，别一层开一层关导致天天排查不通。

配置ufw会不会影响服务器已有的对外连接，比如发邮件、拉取软件包？

不会，因为ufw默认策略是“拒绝入站、允许出站”。它拦的是别人主动连你的（入站），你服务器主动连出去的（出站，比如apt拉包、curl调接口、发邮件）默认全部放行，不受影响。除非你手动把出站默认改成deny再逐条放行——那是高安全要求场景才做的，配错了容易把服务器的正常外联也掐了，一般机器没必要这么严，保持默认allow outgoing就好。

ufw status显示inactive，是不是没生效？

对，inactive表示ufw没启用，规则全都不生效，等于没装防火墙。你可能只allow了一堆规则但忘了 sudo ufw enable，规则只是“待添加”状态。enable之后再status会显示active，那时规则才真正在拦。但还是那句话——enable之前务必确认SSH已经在放行列表里（ufw show added 看一眼），别一启用就把自己关门外。

删了一条放行规则后，已经建立的连接会立刻断开吗？

不一定会立刻断。ufw底层默认会放行“已建立和相关的连接”（established/related），所以删掉某个端口的allow规则后，已经连上的会话可能还能维持一会儿，但新发起的连接会被拒。如果你要立刻切断某个正在进行的连接（比如发现有可疑会话），光删规则不够，可能还得配合deny明确拦截来源IP，或者重启相关服务断开会话。日常运维里删规则主要影响的是后续新连接，这点要心里有数。

权威参考资料