📄 前言与阅读约定 00-preface.md✓ 标记已学

---

title: 00 前言与阅读约定 updated: 2026-09 applies-to: Ubuntu 22.04 LTS

这是一套面向零基础读者的《Linux 服务器部署教程》。在翻开任何一章之前，请先读完本章——它只有十几分钟的阅读量，却能帮你建立正确的操作姿势，避开后面 80% 的坑。本章不讲部署，讲的是怎么读这本书、怎么安全地操作服务器、以及 shell 背后最基本的运行规则。

[!NOTE] 本教程基于 Ubuntu 22.04 LTS 编写，版本号截至 2026-09。用 RHEL 系的读者请留意各章的「RHEL 对照」折叠块。

这本教程怎么读

三条阅读路线

不同的人带着不同的目的来，我们准备了三条路线：

路线	适合谁	怎么走
新手直通	从零开始、想系统学习	按章节编号从 00 顺序读到 40，每章动手做完再往下
按组件查阅	有基础，只想装某个软件	直接跳到对应章节（如 MySQL、防火墙），章内自成闭环
救火	线上出事了，急需答案	先看 排错手册 定位章节，用「常见问题」表对症下药

完整章节目录见 README。

动手优先

每章的「验证方法」小节都给了命令 + 预期输出。请务必亲手敲一遍、亲眼核对输出——服务器运维是肌肉记忆，光看不练等于没学。准备一台练习环境即可开始：本地 VirtualBox/VMware 虚拟机，或任意云厂商按量付费的低配服务器（用完记得销毁，防止持续扣费）。

全书约定

提示符

全书代码块统一使用 $ 作为命令提示符：

# 以普通用户执行（绝大多数场景）
$ ls -la
# 需要 root 权限时，加 sudo 前缀
$ sudo apt update

三条规则：

1. $ 是提示符，不是命令的一部分，不要把它复制进去。
2. $ sudo 开头表示该命令需要管理员权限，执行后可能要求输入当前用户的密码（输入时屏幕不显示任何字符，这是正常设计，输完回车即可）。
3. 全书不使用 root 直接登录，需要最高权限的地方一律 sudo。这是安全基线，原因见下文「安全基线」一节。

占位符

代码中出现的尖括号是占位符，需要替换成你自己的真实值，不要原样照抄：

占位符	替换成
<服务器IP>	你服务器的公网/内网 IP，如 203.0.113.10
<你的域名>	你在域名商处购买的域名，如 example.com
<强密码>	你自己生成的强密码（建议用密码管理器生成）
<新主机名>	你想要的主机名，如 web-01
<用户名>	你的登录用户名

提示块

全书只用四种提示块，含义如下：

标记	含义	你该怎么做
> [!NOTE]	补充说明、背景知识	可以跳过，回头再看也行
> [!TIP]	更好的做法、省事的技巧	建议采纳
> [!IMPORTANT]	关键前提，不做会失败或留隐患	必须照做
> [!WARNING]	有风险，可能丢数据或失联	停下来读清楚再动手

代码块语言标注

全书代码块开头都标注语言：bash（命令）、console（终端交互含输出）、text（纯文本输出）、ini / yaml（配置文件）、powershell（Windows PowerShell 命令）。标注语言除了高亮，更重要的目的是让你一眼分辨「这是要输入的命令」还是「参考输出」。

RHEL 对照折叠块

Ubuntu 之外，很多公司用 RHEL / Rocky / AlmaLinux。涉及发行版差异的地方，我们会放一个可点击展开的折叠块，不影响 Ubuntu 读者的阅读连贯性。长这样（点击即可展开）：

RHEL / Rocky / AlmaLinux 9 对照

Ubuntu (apt/ufw)	RHEL (dnf/firewalld)	说明
sudo apt install nginx	sudo dnf install nginx	包管理器不同
sudo ufw allow 80/tcp	sudo firewall-cmd --permanent --add-service=http	防火墙工具不同

版本声明

全书版本号截至 2026-09。 软件版本会持续更新，本书给出的具体小版本号（如 8.0.4x）可能已经过期。唯一权威的核对方式是查阅 版本速查表，以及动手前自己执行 apt policy <包名> 确认当前源里的候选版本。冲突时一律以官方文档为准，本书只负责告诉你「怎么自己核对」。

安全基线（新服务器第一小时要做的事）

[!IMPORTANT] 任何一台新拿到的服务器（云主机、虚拟机都算），在部署任何业务之前，先完成下面 6 件事。顺序执行，全程不超过一小时。跳过任何一步，都是在给未来的自己埋雷。

1. 用 SSH 密钥登录，禁用密码登录。 密码可以被暴力破解，密钥几乎不能。生成密钥并配置的完整步骤见 18 SSH 加固。

2. 建一个普通用户并加入 sudo 组，禁止 root 直接登录。 root 权限太大，一条手滑命令就能毁掉系统；日常用普通用户 + sudo，既留了审计痕迹，也让误操作多一道确认门槛。

3. 开启防火墙，但第一步必须先放行 SSH（22 端口）。 顺序反了会把自己锁在门外。Ubuntu 用 ufw，详见 16 防火墙：

   # 先放行 SSH，再启用防火墙，顺序不能反！
   $ sudo ufw allow 22/tcp
   $ sudo ufw enable
   

4. 更新系统。 新镜像自带的软件包往往落后于安全补丁：

   # 刷新软件源索引，再升级已安装的包
   $ sudo apt update && sudo apt upgrade
   

5. 设置时区并开启时间同步。 时间不准会弄坏 HTTPS 证书校验、日志对齐和定时任务，原理与操作见 15 网络配置 的时间同步一节：

   # 设置时区为北京时间
   $ sudo timedatectl set-timezone Asia/Shanghai
   

6. 改任何配置文件前，先备份。 养成条件反射：

   # -a 归档模式复制：保留权限、属主、时间戳，还原时不会因权限问题出错
   # $(date +%F) 是命令替换，展开成当天日期如 2026-09-29，备份文件带日期便于区分版本
   $ sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F)
   

   备份加日期后缀的好处：同一个文件改多次也不会覆盖旧备份，出问题时能精确回滚到「出事前一天」的版本。

环境变量与 PATH（先搞懂这个，后面少踩 80% 的坑）

什么是环境变量

环境变量是操作系统传给每个程序的「全局设置」，格式是 名字=值。你已经在不知不觉中用过它：HOME 是你的家目录，LANG 是语言设置，而其中最重要的是 PATH。

# 查看当前用户家目录
$ echo $HOME
# 查看 PATH：一串用冒号分隔的目录
$ echo $PATH

预期输出（具体内容因环境而异）：
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

命令是怎么被找到的

当你敲下 ls 回车，shell 不会搜索整个硬盘，而是按 PATH 里目录的先后顺序，逐个目录找名为 ls 的可执行文件，找到第一个就执行。这个机制解释了大量新手疑问：

• 「为什么我 cd 到目录里，敲 ./xxx.sh 前面要加 ./？」——因为当前目录 . 通常不在 PATH 里，必须显式指明。
• 「为什么 ./xxx 能跑而 xxx 报 command not found？」——同上，shell 在 PATH 里找不到它。

# which：显示命令的可执行文件在哪个目录（按 PATH 顺序找到的第一个）
$ which python3
# type：比 which 信息更全，能识别别名和内建命令
$ type ll
# whereis：把相关的二进制、源码、手册页位置全列出来
$ whereis nginx

临时设置与永久设置

# 临时添加环境变量：export 后当前终端立即生效，但关闭终端就消失
$ export APP_ENV=production
# 验证
$ echo $APP_ENV

想永久生效，必须写进配置文件。写哪里取决于你希望它对谁生效：

写在哪	对谁生效	适用场景
~/.bashrc	只对你自己的交互终端	个人别名、个人常用变量
/etc/profile.d/*.sh	所有用户（推荐做法）	服务器级配置，如 JAVA_HOME
systemd 服务的 Environment=	只对该服务进程	给 nginx/应用服务注入变量，见 40 systemd

给所有用户设置变量的推荐做法：

# 新建一个独立配置文件，命名建议带上用途前缀
$ sudo nano /etc/profile.d/myapp.sh

# /etc/profile.d/myapp.sh 的内容
export APP_ENV=production
export JAVA_HOME=/opt/jdk-21

为什么「装好了却 command not found」

最常见的根因：程序装了，但它所在目录不在 PATH 里。比如你把程序解压到 /opt/myapp/bin/，shell 自然找不到。排查三步：

# 第 1 步：确认程序文件真实存在
$ ls /opt/myapp/bin/
# 第 2 步：确认该目录在不在 PATH 里
$ echo $PATH | tr ':' '\n' | grep myapp
# 第 3 步：不在就把目录追加进 PATH（写进 ~/.bashrc 持久化）
$ echo 'export PATH=/opt/myapp/bin:$PATH' >> ~/.bashrc
$ source ~/.bashrc

登录 shell 与非登录 shell：为什么 cron 里读不到我的变量

shell 分三类，加载的配置文件不同，这是本书埋得最深的一个坑：

类型	什么时候出现	按序加载
登录 shell	SSH 登录、控制台登录	/etc/profile → ~/.profile（其内部会 source ~/.bashrc；Ubuntu 22.04 默认没有 ~/.bash_profile）
非登录交互 shell	直接开一个终端窗口	只加载 ~/.bashrc
非交互 shell	执行脚本、cron 任务	不加载任何 bash 启动文件（除非设置了 BASH_ENV）

[!WARNING] cron 任务的环境变量和你 SSH 登录后看到的完全不同。 你在 ~/.bashrc 里 export 的变量，cron 的非交互 shell 不会加载——这就是「命令行里跑得好好的脚本，放进 cron 就失败」的头号原因。解决方法见定时任务章节：要么在 crontab 里写绝对路径，要么在任务行里显式 source 配置文件。

source 与点命令

source（简写就是一个点 .）的作用：在当前 shell 里执行指定脚本的命令，而不是新开一个子进程。

# 修改 ~/.bashrc 后让它立即生效，无需重新登录
$ source ~/.bashrc
# 点命令与 source 完全等价
$ . ~/.bashrc

为什么要区分？普通方式执行脚本（bash xx.sh 或 ./xx.sh）会开一个子进程，脚本里 export 的变量随子进程结束而消失；source 则把变量留在当前 shell 里。所以「让 .bashrc 的修改立即生效」只能用 source。

危险命令红名单

[!WARNING] 下面这些命令本身都是正常工具，但用错场景就是灾难：轻则删光数据，重则整台服务器报废。在生产服务器上敲任何本节命令前，请默念一遍「安全做法」。

危险命令	一句后果	安全做法
rm -rf <目录>	递归强制删除，无确认、不进回收站，删了就没了	先 ls 确认路径；变量路径先 echo "$DIR" 确认非空
rm -rf $DIR/（变量为空时）	变量为空时命令变成 rm -rf /，删除整个系统	用 "${DIR:?变量为空}" 语法强制检查：rm -rf "${DIR:?}/"
chmod -R 777 <目录>	所有文件对所有人可写可执行，是安全漏洞，还可能破坏 ssh 等对权限敏感的服务	按需最小授权，目录 755、文件 644，私钥 600
mkfs <设备>	格式化磁盘，数据全部清空且无法恢复	执行前三次确认设备名；用 lsblk 核对，防止格错盘
dd if=... of=<设备>	直接按字节写设备，写错目标 = 烧毁数据	先写清 of 目标再回车；可用 oflag=sync status=progress 观察进度及时 Ctrl+C
> 重要文件（如 > /etc/fstab）	重定向立即清空文件内容，没有确认提示	追加用 >>；覆盖前先备份（见安全基线第 6 条）
ufw enable（未放行 SSH 前）	防火墙一开，SSH 立即被拦，把自己锁在服务器外	永远先 sudo ufw allow 22/tcp 再 enable，见 16 防火墙
kill -9 <数据库进程>	数据库来不及刷盘和释放锁，可能数据损坏、下次起不来	先 systemctl stop mysql 走正常停机流程，实在不行用普通 kill（SIGTERM）留善后时间
crontab -r	一次性删除当前用户全部定时任务，且没有确认	用 crontab -e 删单条；删前先 crontab -l > crontab.bak 备份

一条通用原则：破坏性操作的命令，先在测试环境跑一遍，生产环境执行前先把命令完整写出来检查两遍，不要凭肌肉记忆直接敲。

Windows 读者的特别提醒

换行符问题（最常见的翻车点）

Windows 的文本文件用 CRLF（\r\n）换行，Linux 用 LF（\n）。在 Windows 上编辑过的 shell 脚本传到 Linux 后，每行结尾多一个看不见的 \r，运行时就会报：

/bin/bash^M: bad interpreter: No such file or directory

^M 就是那个多余的 \r。三种解决办法：

# 方法 1：在 Linux 服务器上用 dos2unix 转换（没有就先安装）
$ sudo apt install dos2unix
$ dos2unix script.sh

更推荐在源头解决：编辑器设置成 LF。VSCode 点右下角状态栏的 CRLF 切换为 LF，或 settings.json 里加 "files.eol": "\n"；Notepad++ 在「编辑 → 文档格式转换」里切换。这样保存的文件天然兼容 Linux。

推荐终端

• Windows Terminal（微软官方，微软商店免费装）：多标签、字体渲染好，是 Windows 上操作 Linux 服务器的首选界面。
• 连接服务器不需要装 Xshell/PuTTY：Windows 10/11 自带 OpenSSH 客户端，直接在 PowerShell 或 Windows Terminal 里用：

# 在 PowerShell 里直接 ssh，与 Linux 上的用法一致
ssh <用户名>@<服务器IP>

• Windows 上的 WSL2（适用于 Linux 的 Windows 子系统）也值得一试：一个真正的 Linux 环境跑在 Windows 里，本地练手非常方便。

推荐阅读顺序

如果你是零基础新手，建议严格按这个顺序走（编号即难度递进）：

1. 本章 00 前言与阅读约定
2. 15 网络配置 —— 排错思路是一切的基础
3. 16 防火墙 —— 懂了端口，防火墙才不会把自己锁外面
4. 18 SSH 加固 —— 新服务器第一小时的安全基线
5. 40 systemd 服务管理 —— 理解服务怎么被管理
6. 23 MySQL 安装与配置 —— 第一个完整的生产组件实战
7. 随时查阅 91 版本速查表 与各章命令速查

完整目录见 README。祝部署顺利。

📄 10 Shell 与文件系统 10-shell-and-filesystem.md✓ 标记已学

---

title: 10 Shell 与文件系统 updated: 2026-09 applies-to: Ubuntu 22.04 LTS

本章解决三个问题：Linux 的文件都放在哪、怎么在目录间准确移动、为什么有些文件「看起来在但其实不在」（链接）。命令均在 Ubuntu 22.04 LTS 上验证，涉及版本号的信息一律截至 2026-09。

[!NOTE] 本章版本号截至 2026 年 9 月。版本信息的唯一权威来源是 版本速查表，冲突时以速查表为准，核对方法见 91 版本速查。

[!NOTE] 本章绝大多数命令不需要管理员权限，只有安装 tree 那一步需要 sudo。

---

Linux 目录结构（FHS）

是什么

Linux 没有 C 盘、D 盘，所有存储设备都挂到一棵以 / 为根的树上。FHS（Filesystem Hierarchy Standard）规定了哪个目录放什么：约定统一后，你在甲机器学会的路径到乙机器同样适用，包管理器也依赖它——apt 必须把程序放 /usr/bin，否则 Shell 找不到。

目录	放什么 / 提醒
/	根目录。根下不要放业务数据，根分区满了系统就起不来
/home	普通用户家目录 /home/<用户名>，个人配置 .bashrc 在这里
/etc	系统和程序的配置文件，改配置主要就是改这里
/var	经常变化的数据：日志 /var/log、网站根 /var/www、缓存 /var/cache
/usr	系统级程序与只读资源：/usr/bin 命令、/usr/lib 库。名字来自 Unix System Resources，不是 user
/opt	第三方独立软件，如手动安装的 /opt/jdk-21
/tmp	临时文件，会被定期清理，不要放重要数据
/root	root 的家目录，不在 /home 下，普通用户无权进入
/boot	内核与 grub，删错就开不了机
/dev	设备文件：磁盘 /dev/sda、黑洞 /dev/null
/proc	内核与进程的虚拟视图，不占磁盘，如 /proc/cpuinfo
/bin /sbin /lib	基本命令与库，Ubuntu 22.04 上是到 /usr 同名目录的软链
/run	运行时数据（pid、socket），重启即清空
/mnt /media	临时挂载点

怎么做

先亲眼看一遍，比背表格记得牢：

$ ls -1 /
$ ls -ld /bin /sbin /lib

第二行输出开头的 l 和 -> 说明它们是指向 /usr 的软链。养成习惯：任何写操作前先确认「我在哪、目标长什么样」，这是避免事故最便宜的习惯。

参数说明

参数	作用	何时用
-1	每行一个名字	输出要交给脚本或管道
-l	长格式：权限、属主、大小、时间	看细节
-d	只显示目录本身不展开	看目录自己的属性
-F	结尾加类型标记，目录加 /	快速分辨目录和文件
-a	显示点开头的隐藏文件	找 .env 这类文件

验证方法

$ ls -ld /etc

预期输出：

drwxr-xr-x 183 root root 12288 Sep 20 10:02 /etc

d 是目录；两个 root 分别是属主和属组——所以改 /etc 下的配置需要 sudo；183 是硬链接数（子目录数 + 2）；12288 是目录元数据大小，不是内容大小。

常见问题

现象	根因	解决
源码放 /root 下，Nginx 报 403	/root 对其他用户完全不可读	放 /var/www 或家目录
/tmp 里的数据第二天没了	systemd-tmpfiles 定期清理	重要数据放 /var
装了程序却找不到在哪	包管理器按 FHS 放 /usr/bin	command -v <命令> 定位
根分区 100% 却没存大文件	日志在 /var/log 持续增长	用 du 定位，见 磁盘排查

---

路径：绝对路径、相对路径与特殊符号

是什么

绝对路径从根写起（/var/log/nginx/access.log），无论当前在哪指向都一样；相对路径以「当前目录」为起点，起点变了指向就变了。特殊符号：. 当前目录、.. 上级、~ 家目录、- 上一次所在目录。

为什么重要：定时任务和 systemd 服务启动时，当前目录往往不是你以为的那个。所以写脚本和服务配置一律用绝对路径。

怎么做

$ pwd
$ cd /var/log
$ cd ../..
$ cd ~
$ cd -
$ ./deploy.sh

最后一行为什么必须带 ./：Shell 只在 PATH 列出的目录里找命令，故意不含当前目录（防止误执行被投放的同名程序）。给出路径才是安全的做法。

参数说明

命令 / 参数	作用	说明
cd 不带参数	回到家目录	等价 cd ~
cd -	切回上一个目录	依赖 OLDPWD，并打印目标目录
pwd / pwd -P	逻辑路径 / 解析软链后的物理路径	软链目录下两者不同
$PWD $OLDPWD	当前 / 上一个目录	脚本里用 $(pwd) 取位置

验证方法

$ cd /var/log/nginx && pwd && cd - && pwd

预期输出：

/var/log/nginx
/home/ubuntu
/home/ubuntu

第二行是 cd - 打印的「回到哪里」，第三行确认已回来。

常见问题

现象	根因	解决
No such file or directory	相对路径起点不对或拼错	先 pwd，或改用绝对路径
目录名带空格被拆成两个参数	Shell 按空格分词	加引号 cd "/data/my app"
cd "~" 说目录不存在	~ 在引号里不展开	去掉引号或写 /home/ubuntu
脚本里 cat app.conf 找不到	脚本当前目录是执行位置，不是脚本所在位置	用绝对路径，或 cd "$(dirname "$0")"

---

查看目录内容：ls 输出解读与 tree

是什么

ls 列目录，tree 把目录画成树。既然天天用，就值得把 ls -l 的输出逐字段看懂——排查权限、判断文件是否被改动都靠这些字段。

怎么做

$ ls -lah

典型输出：

total 48K
drwxr-xr-x  2 ubuntu ubuntu 4096 Sep 20 10:02 .
-rw-r--r--  1 ubuntu ubuntu  1.2K Sep 20 09:58 app.conf
lrwxrwxrwx  1 ubuntu ubuntu    11 Sep 20 10:01 current -> /opt/app

逐字段：① 权限位 drwxr-xr-x，首字符是类型（d 目录、- 文件、l 软链），后 9 位分三组给属主、属组、其他人；② 硬链接数（文件通常 1，目录是子目录数 + 2）；③ 属主；④ 属组；⑤ 大小（-h 变人类可读，目录的 4096 只是元数据，不代表内容大小）；⑥ mtime；⑦ 名称，软链显示 -> 目标。

$ ls -lt
$ ls -lSh
$ sudo apt install -y tree
$ tree -L 2 -d /etc/nginx

ls -lt 按时间排（找最近被改的文件），ls -lSh 按大小排。tree 需安装，-L 限制层数、-d 只看目录——不限制层数在大目录上会刷屏。

RHEL / Rocky / AlmaLinux 9 对照

Ubuntu (apt)	RHEL (dnf)	说明
sudo apt install -y tree	sudo dnf install -y tree	包名相同
/etc/nginx/sites-available	/etc/nginx/conf.d	RHEL 系没有 sites-available/-enabled 软链机制

参数说明

参数	作用	何时用
-h	大小用 K/M/G	几乎总是加
-t / -S	按时间 / 按大小排序	找最近改动、找大文件
-r	逆序	常与 -t、-S 组合
-i	显示 inode 号	判断硬链接关系
tree -L n	限制层数	建议总是加
tree -d / -a / -h	只看目录 / 含隐藏 / 显示大小	看结构、找 .env
tree -I 'pattern'	排除匹配项	如跳过 node_modules

验证方法

$ ls -lht /var/log | head -n 2

预期输出：

-rw-r----- 1 syslog adm  12M Sep 20 10:05 syslog
-rw-r----- 1 syslog adm 4.2M Sep 20 09:40 auth.log

常见问题

现象	根因	解决
找不到 .env	隐藏文件默认不显示	加 -a
cannot open 'x': Permission denied	父目录缺执行权限 x	加 sudo，见 用户与权限
目录大小都显示 4.0K	ls 显示的是元数据大小	用 du -sh <目录>
tree: command not found	未安装	sudo apt install -y tree
tree 一执行就刷屏	没限制层数	加 -L 2，刷屏中按 Ctrl+C

---

目录容量与磁盘：du 与 df

是什么

df（disk free）看分区还剩多少，du（disk usage）看这个目录占了多少（累加文件大小）。排障顺序固定：先 df 定位是哪个分区满了，再用 du 在那个分区里逐级缩小范围。顺序反了会浪费大量时间。

怎么做

$ df -h
$ du -sh /var/log
$ du -h --max-depth=1 /var | sort -hr

第三条最常用：把 /var 下每个子目录的大小列出来并从大到小排序，谁占用最大一目了然。

参数说明

参数	作用	说明
-h	人类可读单位	两个命令通用
du -s	只给汇总值	只要「这个目录多大」
du --max-depth=n	展开 n 层	配 sort -hr
du -c / --exclude=P	给合计 / 排除目录	跳过 node_modules
df -T	显示文件系统类型	区分 ext4 / xfs
df -i	显示 inode 使用率	有空间却报 No space 时必查

验证方法

$ df -h /

预期输出：

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        40G   12G   26G  32% /

Use% 超 80% 就该排查，90% 以上要马上处理——很多程序在磁盘写满时直接崩溃，而不是报错。

常见问题

现象	根因	解决
df 100% 但 du 加起来差很多	文件被删后仍被进程占用	lsof | grep deleted 找到进程并重启
No space left 但还有空间	inode 耗尽（小文件太多）	df -i 确认
du: ... Permission denied	部分目录无权进入	加 sudo，扫 /proc 的报错可忽略
du 跑得极慢	文件数量巨大	限定目录范围

---

软链接与硬链接：从 inode 说起

是什么

理解链接先要理解 inode：文件系统把每个文件登记成一条 inode 记录（存权限、属主、数据块位置，不存文件名）；文件名只存在于目录里——目录本质是一张「名字 → inode 号」的表。名字和文件是分开的两件事，于是有了两种链接：

	硬链接	软链接（符号链接）
本质	多个名字指向同一个 inode	特殊文件，内容是目标路径字符串
跨文件系统	不可以	可以
指向目录	不可以（会造成目录环）	可以
源文件删除后	数据仍在，另一个名字照常访问	失效，访问报 No such file

为什么需要软链：让 /opt/app/current 指向 /opt/app-1.2.3，程序永远读 current，升级换目录、回滚改指向，不用改任何配置。Nginx 的 sites-enabled、systemd 的开机自启都是这个机制。

怎么做

$ ln -s /opt/app-1.2.3 /opt/app/current
$ ln -sfn /opt/app-1.2.4 /opt/app/current
$ ln app.conf app.conf.hardlink
$ ls -li app.conf app.conf.hardlink
$ readlink -f /opt/app/current

第二行是更新软链的正确写法：-n 防止在旧链接指向的目录里再套一个链接（否则会出现 current/current）。

[!WARNING] 删除软链接时不要在结尾加斜杠。rm -rf /opt/app/current/ 会顺着链接删掉目标目录里的内容，而 rm /opt/app/current 只删链接本身。这是最经典的删库姿势之一。

参数说明

参数	作用	说明
-s	创建软链接	不加就是硬链接
-f	目标已存在时强制覆盖	更新软链常用
-n	把已存在的软链当文件而非目录	与 -f 一起用，防套娃
-i / -v	覆盖前询问 / 显示过程	不确定时加 -i
ls -i	显示 inode 号	验证硬链接
readlink -f	递归解析真实绝对路径	脚本里拿真实路径

验证方法

$ ln app.conf app.conf.hardlink
$ ls -li app.conf app.conf.hardlink

预期输出：

131084 -rw-r--r-- 2 ubuntu ubuntu 1024 Sep 20 10:00 app.conf
131084 -rw-r--r-- 2 ubuntu ubuntu 1024 Sep 20 10:00 app.conf.hardlink

inode 相同、链接数变 2，说明是同一份数据的两个名字。此时删掉 app.conf，另一个名字仍能读到内容——数据要等链接数归 0 才释放。

常见问题

现象	根因	解决
软链红色闪烁 / 报 No such file	目标被删或移动	ln -sfn <真实目标> <链接名> 重建
软链移动后失效	相对路径是相对链接所在目录解析的	建软链时源路径写绝对路径
Invalid cross-device link	跨分区建硬链接	改用 ln -s 或 cp -a
hard link not allowed for directory	对目录建硬链接	系统禁止，用软链
出现 current/current 套娃	已存在指向目录的链接又被 -sf 覆盖	用 ln -sfn 重建

---

文件类型与 file 命令

是什么

ls -l 第一个字符就是类型：- 普通文件、d 目录、l 软链、b 块设备（磁盘 /dev/sda）、c 字符设备（/dev/null）、s 套接字（/run/mysqld/mysqld.sock，进程间通信）、p 管道。Linux 不靠扩展名判断类型——app.log 也可能是二进制。要知道文件到底是什么，用 file。

怎么做

$ file /var/log/syslog
$ file /dev/null /dev/sda
$ file -L /opt/app/current

第三行加 -L 才能跟随软链看目标的类型，否则 file 只会告诉你「这是软链」。

参数说明

参数	作用	说明
file -b	只输出类型不带文件名	脚本解析
file -i	输出 MIME 类型	判断编码，如 charset=utf-8
file -L	跟随软链	默认只报「symbolic link to ...」
file -s	读取设备文件内容判断	查看磁盘分区文件系统
stat -c %F	只输出类型描述	如 regular file

验证方法

$ file /dev/null /dev/sda

预期输出：

/dev/null: character special (1/3)
/dev/sda:  block special (8/0)

常见问题

现象	根因	解决
file: cannot open 'x' (Permission denied)	无权读取	加 sudo file
file 只说「symbolic link to ...」	默认不跟随	加 -L
文本被识别成 data	混入不可见字节或编码异常	file -i 看编码，iconv 转换
脚本有 .sh 却不能执行	看的是执行权限位而非后缀	加执行位，见用户与权限

---

Shell 效率：补全、历史、快捷键与通配符

是什么

服务器没有图形界面，敲命令的速度就是排查速度。三件套：Tab 补全（不拼错）、历史命令（不重敲）、行编辑快捷键（不必重打整句）。另外通配符让你一次选中一批文件。

怎么做

$ history
$ !102
$ sudo !!
$ history | grep nginx

sudo !! 是「忘了加 sudo」时的救星——!! 代表上一条命令。交互式快捷键：Tab 补全（连按两次列出候选）、Ctrl+R 反向搜索历史（继续按找更早的，回车执行）、Ctrl+A/Ctrl+E 跳行首行尾、Ctrl+U/Ctrl+K 删光标前后全部、Ctrl+W 删前一个词、Ctrl+L 清屏、Ctrl+C 中断。

通配符由 Shell 展开后再交给命令，echo 可以预览结果：

$ ls *.log
$ ls app?.log
$ mkdir -p /data/{logs,backups,tmp}
$ cp app.conf{,.bak}
$ echo *.conf

[!WARNING] 通配符和 rm 组合是最危险的操作之一。执行 rm *.log 前请先用 ls *.log 看一遍匹配到了什么——展开结果若包含你没预料到的文件，删除不可逆。

参数说明

符号 / 变量	含义	说明
* / ?	任意长度字符 / 单个字符	不匹配点开头的隐藏文件
[abc] [a-z] [!a]	括号中任一 / 范围 / 取反	glob 语法
{a,b}	依次展开成多个参数	file.{txt,bak}
引号	阻止展开	"*.log" 是字面量
HISTSIZE / HISTFILESIZE	内存 / 文件保存的历史条数	Ubuntu 默认 1000 / 2000
history -a / -d N	立即写入文件 / 删除第 N 条	防断线丢失、清掉带密码的命令
shopt -s histappend	多终端追加而非覆盖	建议写进 ~/.bashrc

[!IMPORTANT] glob 的 * 和正则表达式的 * 不是一回事：glob 里是「任意字符」，正则里是「前一个字符重复任意次」。正则用法见文本处理。

验证方法

$ echo app.conf{,.bak}

预期输出：

app.conf app.conf.bak

用 echo 预览展开结果，是确认通配符行为最安全的办法。

常见问题

现象	根因	解决
cannot access '*.log': No such file	没有匹配项，原样交给命令	确认目录内容；或 shopt -s nullglob
文件名带空格被当成多个参数	Shell 按空格分词	加引号 rm "my file.log"
* 没匹配到隐藏文件	glob 默认跳过点开头文件	显式写 .*（会包含 . 和 ..）
刚执行的命令 history 里没有	历史默认退出时才写文件	history -a 立即写入
两个 SSH 窗口历史互相覆盖	后退出者覆盖了文件	~/.bashrc 加 shopt -s histappend

---

本章命令速查

命令	作用
pwd / pwd -P	显示当前目录（逻辑 / 解析软链后的物理路径）
cd ~ / cd - / cd ..	回家目录 / 回上一次的目录 / 上一级
ls -lah	长格式列出所有文件，大小人类可读
ls -lt / ls -lSh	按时间排序 / 按大小排序
ls -ld <目录>	只看目录自身属性
ls -i	显示 inode 号，判断硬链接
tree -L 2 -d	树状显示两层目录结构
df -h / df -i	分区空间 / inode 使用率
du -sh <目录>	目录总大小
du -h --max-depth=1 | sort -hr	找目录下占用最大的子目录
ln -s <源> <链接名>	创建软链接
ln -sfn <源> <链接名>	强制更新软链接（防套娃）
ln <源> <链接名>	创建硬链接
readlink -f <路径>	解析软链得到真实绝对路径
file <文件> / file -L	判断类型 / 跟随软链判断
history / !n / !!	查历史 / 执行第 n 条 / 重复上一条
Ctrl+R / Ctrl+A / Ctrl+E	反向搜索 / 跳行首 / 跳行尾

相关章节

• 目录与阅读路线
• 文件操作
• 文本处理
• 用户与权限
• 磁盘满了怎么排查
• 版本速查

📄 文件操作 11-file-operations.md✓ 标记已学

---

title: 文件操作 updated: 2026-09 applies-to: Ubuntu 22.04 LTS

本章覆盖部署中最频繁的动作：建目录、复制、移动、删除、查看内容、打包压缩、跨机器传输。命令均在 Ubuntu 22.04 LTS 上验证，涉及版本号的信息一律截至 2026-09。

[!NOTE] 贯穿全章的原则：写操作之前先确认。复制前确认目标，删除前确认清单，解压前确认压缩包内容。这个习惯能挡掉大多数运维事故。

---

创建目录与文件：mkdir、touch

是什么

mkdir 建目录，touch 建空文件。touch 本职是"修改时间戳"，文件不存在时顺手创建一个空的——所以它也常用于占位、让日志轮转程序识别到文件、触发依赖 mtime 的构建。

为什么要加 -p：不加时父目录不存在会报错；加了之后已存在也不报错。脚本和自动化部署一律用 mkdir -p，否则第二次运行就失败。

怎么做

$ sudo mkdir -p /data/app/{logs,conf,backup}
$ touch README.md
$ touch app.log error.log

第一条同时建出嵌套目录和三个子目录（花括号展开，见通配符）。

参数说明

参数	作用	说明
mkdir -p	递归创建，已存在不报错	脚本必用
mkdir -m 755	创建时直接指定权限	省一步 chmod
touch -c	文件不存在时不创建	只想更新时间戳
touch -d "2026-09-01"	指定具体时间戳	测试日志轮转

验证方法

$ sudo mkdir -p /data/app/logs && ls -ld /data/app/logs

预期输出：

drwxr-xr-x 2 root root 4096 Sep 20 10:10 /data/app/logs

用 sudo 首次创建的目录属主是 root。若要交给普通用户使用，记得 sudo chown <用户名>:<属组> /data/app -R 调整属主。

常见问题

现象	根因	解决
No such file or directory / File exists	父目录不存在 / 已存在	都加 -p（幂等）
Permission denied	在 /etc、/var 下建目录需管理员权限	加 sudo 或改到家目录
建出的目录权限不对	受 umask 影响	-m 755 显式指定，见用户与权限

---

复制：cp

是什么

三种场景对应三种写法：日常复制 cp a b；复制目录 cp -r（不加 -r 会直接跳过目录）；备份用 cp -a——保留权限、属主、时间戳和软链接本身。

为什么备份必须用 -a：部署包的权限位、软链结构、时间戳都承载信息。用 -r 备份 Nginx 配置，sites-enabled 里的软链会变成实体副本，恢复后维护关系就断了。

怎么做

$ cp nginx.conf nginx.conf.bak
$ sudo cp -i nginx.conf /etc/nginx/
$ sudo cp -a /etc/nginx /etc/nginx.bak-$(date +%F)
$ cp -ru /data/src/ /data/dst/

[!TIP] 覆盖系统配置前先留一份带日期的副本，是成本最低的后悔药： sudo cp -a /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak-$(date +%F)

参数说明

参数	作用	说明
-r / -R	递归复制目录	复制目录必须加
-a	归档模式，保留权限/属主/时间/软链	备份首选
-i / -n	覆盖前询问 / 绝不覆盖	交互式操作建议 -i
-u / -p	只复制更新的 / 保留权限时间属主	-p 是 -a 的子集

验证方法

$ sudo cp -a /etc/hostname /tmp/hostname.copy
$ ls -l /etc/hostname /tmp/hostname.copy

预期输出：

-rw-r--r-- 1 root root 14 Sep 20 09:00 /etc/hostname
-rw-r--r-- 1 root root 14 Sep 20 09:00 /tmp/hostname.copy

权限、属主、时间戳三者一致说明 -a 生效。去掉 -a 再试，时间会变成当前时间。

常见问题

现象	根因	解决
omitting directory 'xxx'	复制目录忘了 -r	加 -r，备份用 -a
复制后权限或属主变了	默认不保留属性	用 -a 或 -p
软链变成了实体文件	-r 会跟随链接复制内容	用 -a 保留链接

---

移动与重命名：mv

是什么

同一分区内 mv 不搬运数据，只改目录项里的名字（或换个父目录），所以瞬间完成；跨分区则是"复制+删除"，大文件会很慢——这不是 bug，是文件系统的工作方式。重命名和移动在 Linux 里是同一个操作，因为路径本来就包含文件名。

怎么做

$ mv app.conf app.conf.old
$ mv app.log /var/log/app/
$ mv -i app.conf /etc/app/
$ cp app.conf{,.bak}

最后一条是"移动/复制+改名"的快捷写法（花括号展开）。

参数说明

参数	作用	说明
-i / -n	覆盖前询问 / 不覆盖	目标已存在时保护数据
-f	强制覆盖不询问	脚本中避免卡住，风险自负
-v / -u / -t <目录>	显示过程 / 只移更新的 / 先写目标	-t 配合 xargs

验证方法

$ mv app.conf app.conf.old && ls -l app.conf.old

预期输出：

-rw-r--r-- 1 ubuntu ubuntu 1024 Sep 20 10:15 app.conf.old

注意时间戳没变——同分区移动不改文件本身，这正是它快的原因。

常见问题

现象	根因	解决
移动大文件特别慢	跨文件系统，实为复制+删除	正常；或用 rsync 看进度
移动后属主变了	跨分区复制按当前用户重建	用 rsync -a 或事后 chown
同名文件被覆盖	未加 -i	先 ls 目标；设 alias mv='mv -i'
Permission denied	对所在目录无写权限	检查父目录而非文件本身

---

删除：rm 与它的安全替代方案

是什么

Linux 的删除是"解除目录项与 inode 的关联"，没有回收站，也没有确认弹窗。这就是它值得单独用一整节讲的原因。

[!WARNING] rm -rf 是最危险的命令组合：-r 递归、-f 强制不询问——不问你、不进回收站、不给第二次机会。下面这些写法都会造成不可逆的数据丢失，永远不要照抄：

rm -rf /
rm -rf $VAR/
rm -rf ./*
rm -rf /opt/app/current/

依次是：删掉整个系统（部分发行版有保护，但仍会毁掉数据盘）、变量为空时展开成 rm -rf /、通配符可能匹配到意外的目录、结尾斜杠会顺着软链删掉目标目录的内容。

怎么做

四个安全替代方案，按推荐度排序：

# 1. 先确认清单再删（立刻能用）
$ ls -l *.log && rm -i *.log

# 2. 先移到隔离目录，观察几天再清理（可反悔）
$ mkdir -p ~/.trash && mv old-release ~/.trash/old-release-$(date +%F)

# 3. 用 trash-cli 提供真正的回收站
$ sudo apt install -y trash-cli && trash-put old-release

# 4. find 精确定位后删（比通配符可控）
$ find /var/log/app -name "*.log" -mtime +30
$ find /var/log/app -name "*.log" -mtime +30 -delete

方案 4 的顺序很关键：先不带 -delete 看清单，确认后再加 -delete。

参数说明

参数	作用	说明
-i	删除前逐个询问	交互式默认保护
-r / -R	递归删除目录	删目录必须加
-f	强制，不询问、忽略不存在	慎用，会屏蔽"路径写错"的提示
-d / -v	删空目录（等价 rmdir） / 显示过程
trash-put	移入回收站	需装 trash-cli，trash-restore 恢复

[!TIP] 在 ~/.bashrc 加一行 alias rm='rm -i'，让删除默认需要确认。代价是多敲一个 y。

验证方法

$ mkdir -p /tmp/rm-demo/sub && touch /tmp/rm-demo/sub/a.txt
$ rm -r /tmp/rm-demo
$ ls /tmp/rm-demo

预期输出：

ls: cannot access '/tmp/rm-demo': No such file or directory

常见问题

现象	根因	解决
cannot remove 'x': Is a directory	删目录没加 -r	加 -r，空目录可用 rmdir
Permission denied	对父目录无写权限	用 sudo，但先确认路径
Argument list too long	参数超过系统上限	用 find ... -delete 或 xargs，见文本处理
删了大文件但磁盘没释放	文件仍被进程打开	lsof | grep deleted 找到进程重启

---

查看文件内容：cat、less、head、tail

是什么

cat 一次输出全部（只适合小文件）；less 分页浏览并支持搜索（看日志的默认选择）；head/tail 看开头/结尾几行，tail -f 实时跟踪。为什么看日志不能用 cat：几百 MB 的文件会疯狂刷屏，甚至卡死终端；less 只加载当前屏需要的内容，秒开。

怎么做

$ cat /etc/hostname
$ less /var/log/syslog
$ head -n 20 /var/log/syslog
$ tail -f /var/log/nginx/access.log

less 里的按键（进入后按，不是命令行参数）：空格/b 翻页、/关键词 搜索（n 下一个、N 上一个）、g/G 跳首尾、F 进入实时跟踪、q 退出。

参数说明

参数	作用	说明
cat -n / -A	显示行号 / 显示不可见字符	排查 Windows 换行 ^M
less -N / -i / +F	行号 / 搜索忽略大小写 / 打开即跟踪
head -n N / -c N	前 N 行 / 前 N 字节	可简写 -20
tail -n N / -n +N	后 N 行 / 从第 N 行到结尾
tail -f / -F	跟踪文件增长 / 并按文件名重试	日志轮转场景用 -F

验证方法

$ head -n 2 /etc/passwd

预期输出：

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin

常见问题

现象	根因	解决
cat 大文件刷屏停不下	一次性输出全部	Ctrl+C 中断，改用 less
tail -f 过一会儿不动	日志被轮转，跟踪的是旧 inode	改用 tail -F，见日志基础
Permission denied	日志通常仅 root 与 adm 组可读	加 sudo 或加入 adm 组
看到 ^M 符号	文件在 Windows 编辑过（CRLF）	sed -i 's/\r$//' 或 dos2unix

---

打包与压缩：tar、zip

是什么

tar 只做打包，压缩由 gzip/xz 完成，所以常见后缀是 .tar.gz（默认选择，快、兼容性好）和 .tar.xz（压缩率更高，适合分发包）。zip 的优势是 Windows/macOS 原生支持，跨平台交换文件时用它；服务器之间优先 tar.gz，因为后者能完整保留权限和软链。

[!IMPORTANT] 解压前务必先看一眼压缩包内容：

$ tar tf app-1.2.3.tar.gz | head -n 5

有些压缩包不是"一个目录装着所有文件"，而是散装的一堆文件，直接解压会把当前目录铺满，清理起来非常麻烦。先看顶层结构，再 mkdir 一个子目录用 -C 解压进去。

怎么做

$ tar czf app-1.2.3.tar.gz app/
$ tar cJf app-1.2.3.tar.xz app/
$ tar xzf app-1.2.3.tar.gz -C /opt/app
$ zip -r app.zip app/ -x "app/node_modules/*"
$ unzip -l app.zip && unzip app.zip -d /opt/app

-C 指定的目录必须已存在，所以常先 mkdir -p。

RHEL / Rocky / AlmaLinux 9 对照

Ubuntu (apt)	RHEL (dnf)	说明
sudo apt install -y zip unzip	sudo dnf install -y zip unzip	包名相同
sudo apt install -y rsync	sudo dnf install -y rsync	最小化安装通常不自带
sudo apt install -y trash-cli	sudo dnf install -y trash-cli	RHEL 需 EPEL 源

参数说明

参数	作用	说明
-c / -x / -t	创建 / 解包 / 列出内容	-t 不解压只看清单
-z / -J / -j	gzip / xz / bzip2	对应 .tar.gz / .tar.xz / .tar.bz2
-f <文件名>	指定归档文件	必须紧挨文件名放最后
-v / -C <目录>	显示过程 / 指定解压位置
-p / --exclude=P	保留权限 / 排除文件	如排除 node_modules
zip -r / -x P / unzip -l	递归压缩 / 排除 / 列内容	解压用 unzip -d <目录>

验证方法

$ tar tf app-1.2.3.tar.gz | head -n 3

预期输出：

app/
app/conf/
app/conf/app.conf

第一项是 app/ 目录，说明可以安全解压；若直接就是文件名（无统一目录），就该先建子目录再用 -C。

常见问题

现象	根因	解决
解压后当前目录被铺满	包内没有统一顶层目录	先 tar tf，再 mkdir + -C
解压后属主变成陌生数字	包里存的是打包机器的 uid	加 --no-same-owner 或用 sudo
Removing leading '/'	打包时用了绝对路径	是安全保护，不是错误

---

远程传输：scp

是什么

scp 基于 SSH 传输，只要能 SSH 登录就能传，不需要额外开服务。语法始终是"源在前、目标在后"，其中一端写成 用户@主机:路径 就是远程。

怎么做

$ scp ./app.tar.gz <用户名>@<服务器IP>:/opt/app/
$ scp <用户名>@<服务器IP>:/var/log/app/error.log .
$ scp -r ./dist <用户名>@<服务器IP>:/var/www/
$ scp -P 2222 ./app.tar.gz <用户名>@<服务器IP>:/opt/app/
$ scp -i ~/.ssh/id_ed25519 ./app.tar.gz <用户名>@<服务器IP>:/opt/app/

[!WARNING] 传输会直接覆盖远程同名文件，没有任何提示。上传前先确认远程目录里有什么： ssh <用户名>@<服务器IP> 'ls -l /opt/app/'

参数说明

参数	作用	说明
-r	递归传输目录	传目录必须加
-P <端口>	指定 SSH 端口	大写 P；小写 -p 是保留时间戳
-p / -i <私钥>	保留时间权限 / 指定身份文件
-C / -v / -l <速率>	压缩传输 / 显示详情 / 限速	限速单位 Kbit/s，如 -l 8000

验证方法

$ scp ./app.tar.gz <用户名>@<服务器IP>:/opt/app/

预期输出：

app.tar.gz                    100%   12MB   8.4MB/s   00:01

常见问题

现象	根因	解决
Permission denied (publickey,password)	密钥不对或该用户禁止登录	检查密钥与用户名，见SSH 加固
Connection refused	SSH 端口未开或被防火墙拦	确认端口，见防火墙
No such file or directory	远程目标目录不存在	先 SSH 上去 mkdir -p
传大文件中断要重头再来	scp 不支持断点续传	改用 rsync --partial

---

远程同步：rsync 与结尾斜杠的语义

是什么

rsync 只传变化的部分，支持断点续传和保持两端一致，是部署代码和备份目录的首选。它最大的坑是源路径结尾的斜杠，语义完全不同：

写法	含义	结果
rsync -avz src/ dest/	同步 src 目录里的内容	dest/a.txt、dest/sub/
rsync -avz src dest/	同步 src 目录本身	dest/src/a.txt、dest/src/sub/

口诀：带斜杠是"里面的东西"，不带斜杠是"连目录一起"。

[!WARNING] --delete 会删除目标端多出来的文件，让目标与源严格一致。若源路径写错（比如少了斜杠导致层级偏移），它会删掉目标目录下所有对不上的文件。 安全做法：先加 -n（预演）看清单，确认后再去掉 -n 真正执行。

怎么做

$ rsync -avz ./dist/ <用户名>@<服务器IP>:/var/www/html/
$ rsync -avzn --delete ./dist/ <用户名>@<服务器IP>:/var/www/html/
$ rsync -avz -e 'ssh -p 2222' --exclude 'node_modules' ./app/ <用户名>@<服务器IP>:/opt/app/
$ rsync -avzP ./bigdata.tar.gz <用户名>@<服务器IP>:/data/

第二条是预演（-n），只在屏幕上显示会做什么；确认无误后去掉 n 再执行。

参数说明

参数	作用	说明
-a	归档：保留权限、时间、软链并递归	几乎总是加
-v / -z	显示详情 / 传输时压缩	跨公网加 -z
-n	预演，不实际改动	配 --delete 时必用
--delete	删除目标端多余文件	保持严格一致，慎用
--exclude=P	排除文件	可写多次
-P / -e 'ssh -p N'	进度+断点续传 / 指定端口	非 22 端口时用 -e

验证方法

$ rsync -avzn ./dist/ /tmp/deploy-test/

预期输出：

sending incremental file list
./
index.html
assets/app.js

sent 220 bytes  received 28 bytes  496.00 bytes/sec

把源路径的斜杠去掉再跑一次，对比第一行是 ./ 还是 dist/，就能直观看到差异。

常见问题

现象	根因	解决
同步后多了一层 dest/dist/...	源路径没带结尾斜杠	源写成 ./dist/
目标端文件被删光	--delete + 源路径写错	立刻停止；先 -n 预演，从备份恢复
每次都全量重传	未用 -a，时间戳/权限未保留导致比对失败	加 -a

---

下载文件：wget 与 curl

是什么

两者都能下载。简单选择：wget 专做下载（默认存成文件、支持断点续传）；curl 是通用网络工具（默认输出到屏幕，调试接口也靠它）。

怎么做

$ wget https://example.com/app.tar.gz
$ wget -O app-1.2.3.tar.gz https://example.com/download/latest
$ wget -c https://example.com/big.tar.gz
$ curl -O https://example.com/app.tar.gz
$ curl -Lo app.tar.gz https://example.com/download/latest

注意 curl 的大小写：大写 -O 按远程文件名保存，小写 -o 指定文件名。

[!IMPORTANT] 下载可执行文件后不要直接运行。先看内容确认来源可信：less install.sh；正规项目会提供校验值，下载后用 sha256sum 核对。

参数说明

参数	作用	说明
wget -O <名> / -P <目录>	指定保存名 / 保存目录
wget -c / -q	断点续传 / 安静模式	大文件必备 -c
curl -O / -o <名>	按远程名保存 / 指定输出名
curl -L / -s	跟随重定向 / 安静模式	多数下载链接需要 -L
curl -I / -f	只看响应头 / HTTP 错误返回非 0	脚本里用 -f 判断成败

验证方法

$ curl -sI https://example.com/app.tar.gz | head -n 2

预期输出：

HTTP/1.1 200 OK
Content-Length: 12582912

200 说明资源存在，Content-Length 告诉你文件大小——下载前先确认，能避免把 404 页面当安装包解压。

常见问题

现象	根因	解决
下载下来是 HTML 文本	链接是跳转页或需登录	加 -L；检查是否需认证
403 Forbidden	对方禁了默认 UA 或需鉴权	加 -H "User-Agent: ..." 或带 token
下载速度很慢	源站在境外	换国内镜像，见镜像加速
脚本里 curl 失败仍继续	curl 对 404 默认也返回 0	加 -f 并检查 $?

---

本章命令速查

命令	作用
mkdir -p /data/a/b	递归创建目录，已存在不报错
touch <文件>	创建空文件或更新时间戳
cp -a <源> <目标>	归档复制，保留权限/时间/软链（备份首选）
cp -r <目录> <目标>	递归复制目录（不加 -r 会跳过目录）
mv <源> <目标>	移动或重命名（同分区瞬时完成）
rm -i <文件> / rm -r <目录>	逐个确认删除 / 递归删目录
trash-put <文件>	移入回收站，可 trash-restore 恢复
cat <文件>	输出全部内容（只适合小文件）
less <文件>	分页浏览：/搜索、G 到底、F 跟踪、q 退出
head -n 20 / tail -n 20	看开头 / 结尾 20 行
tail -F <文件>	实时跟踪，支持日志轮转后重连
tar czf 包.tar.gz <目录>	打包并 gzip 压缩
tar cJf 包.tar.xz <目录>	打包并 xz 压缩（压缩率更高）
tar tf 包.tar.gz	只列内容不解压（解压前必做）
tar xzf 包.tar.gz -C <目录>	解压到指定目录
zip -r 包.zip <目录> / unzip -l	zip 压缩 / 列出内容
scp -P 2222 -r <源> <用户>@<服务器IP>:<路径>	通过 SSH 传文件或目录（-P 指定端口）
rsync -avz src/ <服务器>:dest/	增量同步目录内容（结尾斜杠决定层级）
rsync -avzn --delete src/ dest/	预演同步（不实际改动）
wget -c <URL> / curl -LO <URL>	下载文件，wget 支持断点续传

相关章节

• 目录与阅读路线
• Shell 与文件系统
• 文本处理
• 用户与权限
• SSH 加固与密钥登录
• 磁盘满了怎么排查
• 备份与定时任务

📄 文本处理 12-text-processing.md✓ 标记已学

---

title: 文本处理 updated: 2026-09 applies-to: Ubuntu 22.04 LTS

服务器上的信息绝大多数是纯文本：配置、日志、进程列表、CSV 数据。能不能在三分钟内从 20 万行日志里找出错误 TOP 10，靠的就是这一章。命令均在 Ubuntu 22.04 LTS 上验证，涉及版本号的信息一律截至 2026-09。

[!NOTE] 核心思想是"组合"：每个命令只做一件事，用管道 | 串起来。先学会单个命令，再学组合。

---

输出重定向：>、>>、2>、2>&1

是什么

命令的输出分两条管道（文件描述符）：1 号 stdout 走正常结果（>），2 号 stderr 走报错（2>）。默认都打到屏幕，重定向就是让它们改道。分开的意义：正常结果要存下来分析，报错要单独看，混在一起会干扰判断。

写法	含义
> file	stdout 覆盖写（原有内容被清空）
>> file	stdout 追加（安全）
2> / 2>>	stderr 覆盖 / 追加
> file 2>&1	两者都进同一文件
&> / &>>	同上，bash 简写
> /dev/null	丢弃输出

怎么做

$ ls -lh /var/log > loglist.txt
$ echo "$(date): backup done" >> /var/log/mybackup.log
$ nginx -t 2> nginx-error.txt
$ ./deploy.sh > deploy.log 2>&1
$ ./deploy.sh > /dev/null 2>&1

[!IMPORTANT] 2>&1 必须写在 > 后面，顺序错了语义就变：

# 正确：stdout 先去文件，stderr 再跟过去
$ ./deploy.sh > out.log 2>&1
# 错误顺序：stderr 先接到"当前的"屏幕，stdout 才去文件
$ ./deploy.sh 2>&1 > out.log

原因：2>&1 的含义是"把 stderr 指向 stdout 当前所指向的地方"，而不是永远跟着 stdout。重定向从左到右依次生效，所以顺序决定结果。

参数说明

写法	作用	说明
> / >>	覆盖 / 追加 stdout	文件不存在则创建
2> / 2>>	覆盖 / 追加 stderr	数字 2 紧贴 >，中间不能空格
2>&1	stderr 指向 stdout 当前目标	必须写在 > 之后
&> / &>>	两者一起覆盖 / 追加	bash 简写，脚本可读性更好
> /dev/null	丢弃	只关心退出码时用
set -o noclobber	禁止 > 覆盖已存在文件	需覆盖时用 >|

验证方法

$ echo "hello" > t.txt
$ echo "world" >> t.txt
$ cat t.txt

预期输出：

hello
world

把第二个 >> 换成 > 再跑，文件里只剩 world——这就是覆盖与追加的区别。

常见问题

现象	根因	解决
用 > 后原内容没了	> 是覆盖写	改用 >>；重要文件先备份
sudo echo x > /etc/a.conf 报 Permission denied	重定向由当前 Shell 执行，sudo 只作用于 echo	echo x | sudo tee /etc/a.conf
加了 2> 屏幕还有输出	输出走的是 stdout 而非 stderr	改用 > file 2>&1
2>&1 似乎没生效	顺序写反了	放到 > 之后
定时任务里没输出	cron 输出默认丢弃或发邮件	显式写 >> /var/log/x.log 2>&1

---

管道 | 与 tee

是什么

管道把左边命令的 stdout 变成右边命令的 stdin。这是 Linux 设计的精髓：每个工具只做一件事，串联起来完成复杂任务。tee 是管道上的三通——一边往下传一边存文件，让你同时看到结果并保存。

怎么做

$ ls -1 | wc -l
$ du -h /var/log/* | sort -hr | head -n 5
$ sudo apt install -y nginx | tee install.log
$ ./deploy.sh | tee -a deploy.log
$ echo "server_tokens off;" | sudo tee -a /etc/nginx/nginx.conf

最后一条能绕过权限问题：写文件的是被 sudo 提权的 tee，而不是 Shell。

参数说明

写法	作用	说明
|	左边 stdout 接右边 stdin	只传 stdout，stderr 不传
|&	连 stderr 一起传	等价 2>&1 |
tee <文件>	输出屏幕并覆盖写入
tee -a <文件>	追加写入	记录多次运行
tee f1 f2	同时写多个文件
sudo tee	以管理员权限写文件	解决重定向提权问题

验证方法

$ echo "test-line" | tee out.txt

预期输出：

test-line

同时 out.txt 里也写入了 test-line——既看见又保存。

常见问题

现象	根因	解决
管道后加 sudo 没效果	sudo 只提升后一个命令的权限	| sudo tee
管道后错误信息消失	管道只传 stdout	用 2>&1 | 或 |&
tee 后原文件被清空	默认覆盖	用 tee -a
管道太长难调试	一次写太多段	从最短开始逐段加，用 head 查中间结果

---

xargs：把标准输入变成参数

是什么

很多命令（rm、cp、kill）只接受命令行参数，不读标准输入，而管道传过去的是文本流。xargs 把文本流转成参数列表，补上这个缺口：

find . -name "*.tmp" | rm        ← 不行，rm 读不到管道
find . -name "*.tmp" | xargs rm  ← 可以

怎么做

$ find . -name "*.tmp" | xargs echo rm
$ find . -name "*.tmp" | xargs rm
$ find . -name "*.conf" | xargs -I{} cp {} {}.bak
$ cat hosts.txt | xargs -n 1 ping -c 1
$ find . -name "*.log" -print0 | xargs -0 rm

[!WARNING] xargs rm 会删除管道送来的每一个路径。请先 xargs echo rm 把将要执行的完整命令打印出来看一遍，确认清单后再去掉 echo。

参数说明

参数	作用	说明
-I{}	{} 作占位符，参数插到指定位置	参数不在命令末尾时用
-n N	每次取 N 个参数执行一次	逐个处理用 -n 1
-0	以 NUL 分隔输入	配 find -print0，正确处理含空格文件名
-p / -t	执行前询问 / 打印要执行的命令	危险操作加 -p
-r / -P N	输入为空时不执行 / 并发 N 个

验证方法

$ echo -e "a.txt\nb.txt" | xargs -I{} echo "cp {} {}.bak"

预期输出：

cp a.txt a.txt.bak
cp b.txt b.txt.bak

常见问题

现象	根因	解决
Argument list too long	参数数量超系统上限	用 xargs 分批，或 find -delete
文件名含空格被拆开	默认按空白分词	find -print0 | xargs -0
xargs: No such file or directory	参数为空仍执行了命令	加 -r
想在参数前后加内容	默认只能追加在末尾	用 -I{} 占位

---

grep：搜索文本

是什么

grep 按模式匹配行并输出，是"在几百个配置里找某一项""在日志里找报错"的首选。最常用的写法是 grep -rn "关键词" .：递归搜索当前目录并显示行号。找不到配置在哪时，第一反应就应该是它。

怎么做

$ grep -n "error" app.log
$ grep -rn "listen" /etc/nginx/
$ grep -v "^#" nginx.conf
$ grep -c "ERROR" app.log
$ grep -oE "[0-9]{1,3}(\.[0-9]{1,3}){3}" access.log
$ grep -n -C 3 "Exception" app.log
$ grep -rn "database" . --exclude-dir={.git,node_modules}

倒数第二条用 -C 3 显示匹配行的前后各 3 行，排错时看上下文必备。

参数说明

参数	作用	说明
-i / -n	忽略大小写 / 显示行号	-n 总是加
-r / -R	递归目录（-R 跟随软链）	找配置用 -r
-v / -c	反向匹配 / 只统计行数	过滤噪声、计数
-o / -w	只输出匹配部分 / 全词匹配	提取 IP；避免 err 命中 error
-E / -F	扩展正则 / 字面字符串	关键词含特殊字符用 -F（更快）
-l / -m N	只列文件名 / 每文件最多 N 条	只关心"哪些文件里有"
-A3 -B3 -C3	显示后 / 前 / 前后各 3 行	看上下文
--exclude-dir= --include=	排除目录 / 只搜匹配文件	支持花括号展开

验证方法

$ grep -n "^root" /etc/passwd

预期输出：

1:root:x:0:0:root:/root:/bin/bash

^ 是行首锚点，1: 是行号。

常见问题

现象	根因	解决
Binary file xxx matches	文件被识别为二进制	加 -a 当文本处理，或 -I 跳过
明明有关键词却搜不到	大小写不符或被拆行	加 -i；用 -C 3 看上下文
搜出几千行没法看	没限定范围	加 --include，或接 | head -n 20
正则的 |、+ 不生效	基本正则不支持	加 -E
关键词含 . * 匹配异常	被当正则元字符	加 -F 或转义 \.

---

find：按条件查找文件

是什么

grep 搜内容，find 找文件本身（按名字、类型、时间、大小）。两者常组合：先 find 圈定文件，再 grep 搜内容。

怎么做

$ find /etc -name "*.conf"
$ find /var -type d -name "log"
$ find /etc -type f -mtime -7
$ find / -type f -size +100M
$ find /var/log -maxdepth 2 -name "*.log"
$ find /etc -name "*.conf" -exec grep -Hn "listen" {} \;
$ find /var/log -name "*.log" -mtime +30 -delete

模式必须加引号，否则 Shell 会先展开通配符。倒数第二行是 find 与 grep 的组合，-H 让 grep 总是显示文件名。

[!WARNING] -delete 和 -exec rm {} \; 都会真正删除文件，且没有回收站。务必先不带 -delete 跑一遍看清单，确认后再删。另外 -delete 必须放在所有条件之后：find 从左到右求值表达式，-delete 一旦出现就对当前遍历到的每个文件直接执行删除，写在它后面的条件形同虚设——find . -delete -name "*.log" 会删光整棵目录树而不是只删 .log，而且不会报错提醒你。

参数说明

参数	作用	说明
-name "模式" / -iname	按名匹配（区分 / 不区分大小写）	模式要加引号
-type f d l	文件 / 目录 / 软链接	常加，缩小范围
-mtime -N / +N	N 天内 / N 天前修改	-7 = 最近 7 天
-size +100M	大于指定大小	单位 k M G
-maxdepth N	最多深入 N 层	建议加，避免全盘扫描
-exec cmd {} \; / {} +	逐个执行 / 拼一批执行	+ 快得多
-delete / -print0	删除 / 以 NUL 分隔输出	-delete 必须放在所有条件之后（放在前面会绕过条件全量删除且不报错）；-print0 配 xargs -0

验证方法

$ find /etc -maxdepth 1 -name "*.conf"

预期输出（因机器而异）：

/etc/host.conf
/etc/resolv.conf
/etc/sysctl.conf

常见问题

现象	根因	解决
结果奇怪或搜不到	模式没加引号被 Shell 展开	用引号 -name "*.conf"
Permission denied 刷屏	遍历到无权目录	加 2>/dev/null 或用 sudo
搜索特别慢	没限制深度，全盘遍历	加 -maxdepth 和起始路径
以为加了条件，结果删多了文件	-delete 写在了条件前面，条件被整体跳过	-delete 永远放最后；先用 -print 预览清单再删
找到了却删不掉	对父目录无写权限	加 sudo

---

sed：替换与行编辑

是什么

sed 逐行处理文本，最常用两个能力：替换（批量改配置）和取行区间（截取日志的一段）。

怎么做

$ sed 's/old/new/g' app.conf
$ sed -i 's/old/new/g' app.conf
$ sed -i.bak 's/old/new/g' app.conf
$ sed -n '10,20p' app.log
$ sed '/^#/d' nginx.conf
$ sed 's#/var/www/html#/data/www#g' nginx.conf

第一行不加 -i 只把结果打到屏幕（预览）；第三行 -i.bak 会先备份再改。路径含斜杠时换 # 作分隔符，就不用写一堆转义。

[!TIP] 用 -i 之前先不加 -i 跑一遍，确认屏幕上输出的正是你要的结果，再加 -i。这一步能挡住绝大多数"改坏配置文件"的事故。改动重要配置时用 sed -i.bak，改完立刻做语法检查（如 nginx -t）。

参数说明

语法 / 参数	作用	说明
s/old/new/ / s/old/new/g	替换每行第一个 / 全部	g = global
-i / -i.bak	原地修改 / 修改并备份	先预览再改
-n '10,20p'	只打印 10–20 行	-n 抑制默认输出
/pat/d	删除匹配行	如删注释行
s#a#b#g	用 # 作分隔符	处理路径时避免转义
& / -e 'cmd'	代表匹配到的内容 / 执行多个规则	s/[0-9]/[&]/g

验证方法

$ echo "port=8080" | sed 's/8080/9090/'

预期输出：

port=9090

常见问题

现象	根因	解决
改完配置服务起不来	未预览、未备份	用 -i.bak，改完 nginx -t 校验
替换没生效	模式没匹配上（大小写、空格）	先 grep 确认原文
路径替换报 unknown option to 's'	替换串含 / 与分隔符冲突	换 s#a#b#g 或 `s
sed -i 报 extra characters	macOS/BSD sed 的 -i 必须带后缀	Linux 无此限制；跨平台脚本用 -i.bak
只替换了每行第一个	忘了 g	加 g

---

awk：按列处理与统计

是什么

awk 把每行按分隔符切成列：$1 第一列、$2 第二列、$0 整行、$NF 最后一列。它是一门小型语言，能做条件判断和累加统计，是日志分析的主力。默认按任意空白分列（多个空格算一个），这一点比 cut 好用得多。

怎么做

$ awk -F: '{print $1}' /etc/passwd
$ awk -F: '{print $NF}' /etc/passwd
$ awk '{print NR": "$0}' app.log
$ awk '$3 > 100 {print $1, $3}' data.txt
$ awk 'NR>1 {print $1}' data.csv
$ awk '{sum+=$1} END {print sum}' numbers.txt
$ awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -n 10

[!NOTE] awk 程序体必须用单引号 '{print $1}'。用双引号时 Shell 会把 $1 当自己的变量展开，结果就不是你要的列了。

参数说明

变量 / 参数	作用	说明
-F:	指定输入分隔符	如 -F, 处理 CSV
$0 / $1…$n / $NF	整行 / 第 n 列 / 最后一列	NF 是当前行列数
NR / FNR	当前行号 / 当前文件内行号	NR==1 是表头
BEGIN{} / END{}	处理前 / 处理后执行一次	打印表头、输出汇总
条件 {动作}	满足才执行	如 $3 > 100
-v OFS=','	指定输出分隔符	控制输出格式

验证方法

$ echo -e "10\n20\n30" | awk '{sum+=$1} END {print sum}'

预期输出：

60

常见问题

现象	根因	解决
输出为空或整行	用了双引号，$1 被 Shell 展开	改用单引号
取列不对	分隔符不是空白	用 -F 指定
求和结果是科学计数法	数值过大	printf "%.0f\n", sum
表头也被统计	未跳过第一行	加 NR>1 或 tail -n +2
多空格导致列错位	用了 cut 而非 awk	优先用 awk

---

统计三件套：sort、uniq、wc、cut、tr

是什么

组合起来回答"哪个值出现得最多"：

sort  → 把相同的值排到一起（uniq 只能去掉相邻的重复行）
uniq -c → 统计每种值出现几次
sort -rn → 按次数从大到小，最大的排最前

必须先 sort 再 uniq：uniq 只比较相邻行，不去重全局，所以"先排序再去重"是固定套路。cut 按分隔符或字符位置截取，tr 做字符级替换/删除；两者都比 awk/sed 简单，适合格式固定的简单场景——但 cut 遇到连续空格会错位，处理命令输出优先用 awk。

怎么做

$ awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -n 10
$ sort -n numbers.txt
$ sort -t: -k3 -n /etc/passwd
$ wc -l access.log
$ cut -d: -f1,3 /etc/passwd
$ tr 'a-z' 'A-Z' < input.txt
$ tr -d '\r' < win.txt > unix.txt

参数说明

参数	作用	说明
sort -n / -r	数值排序 / 逆序	数字必须加 -n，否则 10 排在 9 前
sort -u / -h	排序并去重 / 按人类可读大小排	-h 配 du -h
sort -k N / -t:	按第 N 列排 / 指定列分隔符
uniq -c / -d / -u	计数 / 只显示重复 / 只显示唯一	-c 前必须先 sort
wc -l / -w / -c	行数 / 单词数 / 字节数
cut -d: -f1	指定分隔符 / 取第 1 列	-f1,3 多列，-f2- 到第 2 列起
cut -c1-10	按字符位置截取	定长格式日志
tr -d / -s	删除字符 / 压缩重复字符	如压缩多余空格

验证方法

$ printf "b\na\nb\nc\n" | sort | uniq -c

预期输出：

      1 a
      2 b
      1 c

去掉 sort 后 uniq -c 会把两个不相邻的 b 算成两次，得到错误结果——这就是必须先排序的原因。

常见问题

现象	根因	解决
uniq 没去掉重复	相同值不相邻	先 sort | uniq
排序结果 10 排在 9 前	按字符串排序	加 -n
统计结果包含表头	未过滤第一行	加 awk 'NR>1'
cut 取列错位	连续空格被当作多个分隔符	改用 awk '{print $1}'
tr 提示 extra operand	参数个数不对	tr 需两个集合，删除用 -d
tr 似乎没生效	它只处理 stdin，不接受文件名参数	用 tr ... < file

---

本章命令速查

命令	作用
cmd > f / cmd >> f	输出覆盖写 / 追加写到文件
cmd 2> f	只保存错误信息
cmd > f 2>&1	正常与错误都进同一文件（顺序不能反）；换 /dev/null 即丢弃
cmd1 | cmd2	管道：前一个的输出交给后一个
cmd | tee -a f	同时显示并追加保存
echo x | sudo tee /etc/f	提权写系统文件（绕过重定向权限限制）
... | xargs -I{} cmd	把标准输入转成参数，{} 是占位符
find ... -print0 | xargs -0	安全处理含空格的文件名
grep -rn "关键词" .	递归搜索并显示行号（找配置首选）
grep -i -v -c -o	忽略大小写 / 反向 / 计数 / 只输出匹配部分
grep -E / -F / -C3	扩展正则 / 字面匹配 / 显示前后各 3 行
find -name "*.conf" / -mtime -7	按名查找（模式加引号）/ 找 7 天内改过的
find -size +100M / -delete	找大于 100MB 的文件 / 删除（先预览）
sed 's/old/new/g' f	替换并预览（不加 -i 不改文件）
sed -i.bak 's/old/new/g' f	原地修改并备份（-n '10,20p' 取行区间）
awk -F: '{print $1}' f	按冒号分隔取第 1 列（NR>1 跳过表头）
awk '{sum+=$1} END {print sum}'	对第一列求和
sort | uniq -c | sort -rn	统计出现次数并倒序（三件套）
sort -n / -h	数值排序 / 按人类可读大小排序（如配 du -h）
wc -l / cut -d: -f1 / tr -d '\r'	统计行数 / 按分隔符取列 / 删除字符

相关章节

• 目录与阅读路线
• Shell 与文件系统
• 文件操作
• 日志基础
• 日志查询常用配方
• 日志分析与统计
• 命令速查

📄 用户、组与权限管理 13-users-and-permissions.md✓ 标记已学

---

title: 用户、组与权限管理 updated: 2026-09 applies-to: Ubuntu 22.04 LTS

Linux 天生是多用户系统：一台服务器上可同时存在几十个账号，谁能读哪个文件、谁能重启哪个服务，全靠一套规则划分。这套规则只有三块积木：账号（你是谁）、归属（文件归谁）、权限位（属主 / 属组 / 其他人分别能干什么）。

先把最容易踩的两个坑写在最前面，因为它们都会造成不可逆的后果：图省事执行 chmod 777（等于把服务器的所有门钥匙发给每一个能登录的人）；用普通编辑器直接改 /etc/sudoers（语法写错就会把自己永久锁在管理员权限之外）。

[!NOTE] 本章命令与默认行为均基于 Ubuntu 22.04 LTS，版本相关信息截至 2026-09。

用户、组与身份查询

是什么

Linux 里没有"用户数据库"，用户信息就是三个纯文本配置文件：

文件	存什么	谁能读
/etc/passwd	用户名、UID、GID、家目录、登录 Shell	所有人
/etc/shadow	密码哈希与有效期	仅 root
/etc/group	组名、GID、附加成员名单	所有人

/etc/passwd 第二个字段恒为 x，意思是"密码不在这儿，去 /etc/shadow 找"——早期 Unix 把密码哈希放在人人可读的 passwd 里，容易被离线爆破，后来才拆出只给 root 读的 shadow。内核只认 UID（数字），用户名只是给人看的别名：0 是 root（绕过一切权限检查），1–999 是系统用户（服务账号，通常禁止登录，如 www-data=33），1000+ 是管理员创建的普通用户。

日常排错很少翻这三个文件，更多是用只读命令回答"我是谁、谁在机器上、谁登录过"：whoami、id、groups、who（当前在线）、last（历史登录）。

怎么做

# 我是谁 / 我的全部身份 / 我的组
$ whoami
$ id
$ groups

# 当前在线会话（用户名、终端、来源 IP）
$ who

# 最近 10 条登录历史（含重启记录）
$ last -n 10

# 查账号（含 LDAP 等外部源）
$ getent passwd <用户名>

[!WARNING] 不要用 vim / nano 直接编辑这三个文件。少一个冒号就可能让所有用户无法登录。请始终用 useradd、usermod、passwd、groupadd，它们保证格式正确与并发安全。

参数说明

/etc/passwd 每行 7 个字段，冒号分隔：

字段	示例	说明
1 用户名	alice	登录名，最长 32 字符
2 密码占位	x	真身在 /etc/shadow
3 UID	1001	内核识别用户的数字 ID
4 GID	1001	主组，新建文件默认属该组
5 注释	Alice	GECOS 字段，仅注释用途
6 家目录	/home/alice	登录后进入的目录
7 登录 Shell	/bin/bash	填 /usr/sbin/nologin 表示禁止登录
id -u / -g / -G	—	只打印 UID / 主组 / 全部组，id -n 显示名字而非数字

另外 last -n N 限制条数，who -a 信息更全。

验证方法

$ id

预期输出：

uid=1000(ubuntu) gid=1000(ubuntu) groups=1000(ubuntu),4(adm),27(sudo),100(users)

读作：我是 ubuntu，UID 1000，主组 ubuntu，另属 adm、sudo、users。出现在 sudo 组里，正是我能使用 sudo 的原因。

常见问题

现象	根因	解决
/etc/passwd 里 grep 不到某用户	账号由 LDAP / SSO 提供，不在本地文件	用 getent passwd <用户名>，它同时检索外部源
cat /etc/shadow 报 Permission denied	权限为 -rw-------，仅 root 可读	用 sudo cat；别为省事给它加读权限
进程属主显示为数字而非用户名	用户已删但进程还在，或在容器命名空间内	属正常，用 ps -o user= -p <PID> 复核
last 输出为空	/var/log/wtmp 被清空或被 logrotate 轮转	查 /var/log/auth.log 或 journalctl -u systemd-logind

创建、修改与删除用户

是什么

创建用户 = 在三个文件里追加记录 + 建家目录骨架 + 设初始密码。Ubuntu 给了两个命令：useradd（底层、不交互，不带 -m 时不建家目录，新手常被坑）和 adduser（交互式封装，自动建家目录、拷 /etc/skel 模板、问密码）。新手手动操作用 adduser，写自动化脚本用 useradd。

建好后的常见后续操作是改组和改状态：加进 sudo 组让他能提权、加进 docker 组让他能用 Docker、有人离职时锁定而不是立刻删除。配套命令是 groupadd 建组、gpasswd 加减成员。

怎么做

# -m 建家目录，-s 指定登录 shell
$ sudo useradd -m -s /bin/bash <用户名>

# 设密码（没密码的账号处于锁定态，无法登录）
$ sudo passwd <用户名>

# 更友好的交互式方式
$ sudo adduser <用户名>

# 加入 sudo 组（-a 是 append，必须加！）
$ sudo usermod -aG sudo <用户名>

# 锁定 / 解锁账号
$ sudo usermod -L <用户名>
$ sudo usermod -U <用户名>

# 建组、加人、减人
$ sudo groupadd devops
$ sudo gpasswd -a <用户名> devops
$ sudo gpasswd -d <用户名> devops

# 删账号；加 -r 连家目录一起删
$ sudo userdel -r <用户名>

[!WARNING] usermod -G 不带 -a 会覆盖用户的全部附加组，这是 Linux 运维的经典事故。 用户原属 sudo,docker,www-data，执行 usermod -G devops alice 之后他就只剩 devops ——刚丢掉的 sudo 意味着他再也提不了权。正确写法永远是 usermod -aG devops alice，改完务必用 id <用户名> 复核。此外 userdel -r 会递归删除家目录且不可恢复，生产环境建议先 usermod -L 锁定观察一段时间再删。

参数说明

参数	作用
-m	建家目录，并把 /etc/skel 下的 .bashrc 等模板拷进去
-s <shell>	指定登录 Shell；写 /usr/sbin/nologin 即建不可登录的服务账号
-aG <组列表>	追加附加组，逗号分隔；缺 -a 则变成覆盖（见上方警告）
-g <组>	改主组（小写 g），影响此后新建文件的默认属组
-L / -U	Lock / Unlock：在 shadow 密码字段前加 ! 或去掉它
-r	建系统用户（UID < 1000）；用在 userdel 上则是连同家目录一起删
gpasswd -a / -d	往组里 add / delete 成员

[!NOTE] -L 只锁密码登录，配了 SSH 密钥的账号照样能进。要彻底禁止请同时 usermod -s /usr/sbin/nologin，或移除 ~/.ssh/authorized_keys。RHEL 系的差异是 adduser 只是 useradd 的软链接、并不交互，所以那边必须显式加 -m。

验证方法

$ id <用户名>

预期输出：

uid=1001(alice) gid=1001(alice) groups=1001(alice),27(sudo),998(docker)

确认 27(sudo) 仍在列表中。若它消失了，说明误用了不带 -a 的 -G，立刻用 sudo usermod -aG sudo <用户名> 恢复。账号是否被锁定可用 sudo passwd -S <用户名> 确认，输出第二个字段 L=锁定、P=有可用密码、NP=空密码。

常见问题

现象	根因	解决
新用户提示符是光秃秃的 $，没颜色不补全	用了 useradd 却没加 -m，.bashrc 没被拷贝	补建 sudo mkhomedir_helper <用户名>
新用户无法 SSH 登录、或加了 sudo 组仍提示 "not in the sudoers file"	未设密码处于锁定态（或 Shell 是 nologin）；组成员变更要重新登录才生效	sudo passwd <用户名> 并检查 /etc/passwd 第 7 字段；退出重连 SSH 或 newgrp sudo 刷新
userdel: user X is currently used by process N	该用户还有进程在跑	先 sudo pkill -u <用户名>，再删除
删了又重建同名用户，文件归属错乱	旧文件属主变成孤儿数字 UID	sudo find / -uid <旧UID> -exec chown <用户名> {} +

sudo 提权与身份切换

是什么

root 的 UID 是 0，内核对它不做任何权限检查。直接用 root 登录有两个致命问题：没有刹车（一条手滑的 rm -rf / home/* 就是灾难），没有审计（三个人都用 root，日志里追不到人）。

sudo 的设计哲学是最小权限 + 可追溯：默认仍是你自己，只在需要时临时借用 root 身份执行一次命令，每次调用都写进 /var/log/auth.log，能查到谁、在什么时候、跑了什么。授权规则存在两处：/etc/sudoers（主配置，Ubuntu 上 sudo 组拥有全部权限）和 /etc/sudoers.d/*（推荐，一个应用一份，被主文件末尾的 @includedir 加载）。

要从"自己"变成别人，还有三个命令，关键差别在是否加载目标用户的环境：

命令	加载目标环境	需要谁的密码
su <用户>	否，$HOME、$PATH 还是原来的	对方密码
su - <用户>	是，等同于重新登录	对方密码
sudo -i / sudo -u <用户> -i	是	自己的密码

[!NOTE] su 不加 - 的典型症状：切过去了，但 echo $PATH 还是原来用户的，java、node 这些装在对方家目录里的命令全部找不到。只要是"要在这个账号下干活"，就该用 su -。

怎么做

# 查看"我被授权了什么"——排查权限问题的第一步
$ sudo -l

# 以指定用户身份执行一条命令
$ sudo -u www-data whoami

# 打开完整的 root shell（环境也重置为 root 的）
$ sudo -i

# 完整切到其他用户；不切环境只跑一条命令则用 su -c
$ su - <用户名>
$ su <用户名> -c 'whoami'

# 只编辑独立文件，不碰主配置（visudo 保存时会做语法检查）
$ sudo visudo -f /etc/sudoers.d/deploy

写入一条"只允许免密重启某个服务"的规则；授予完整管理员权限（需输密码）则写 deploy ALL=(ALL:ALL) ALL。切换后离开用 exit：

deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart myapp

[!IMPORTANT] 永远用 visudo，永远不要 sudo vim /etc/sudoers。 visudo 先把内容写临时文件做语法校验，只有正确才落盘；直接编辑一旦写错语法，系统里所有 sudo 调用都会失败——包括你想用来修复它的那次 sudo。这就是把自己锁在门外的经典方式。

[!WARNING] NOPASSWD:ALL 意味着该用户无需任何确认即可执行任意 root 命令，等同于送出一个不受限的 root 后门。它只允许出现在容器内一次性构建、CI runner 这类场景；任何人类账号、任何能从公网登录的账号都不要写。需要免密时把命令限定到具体路径：NOPASSWD: /usr/bin/systemctl restart myapp。

参数说明

sudo 规则格式为 用户 主机=(可切换的身份) 命令：

片段 / 参数	含义
deploy	被授权的用户；写 %devops 表示授权整个组
ALL=	在哪些主机生效，单台写 ALL 即可
(ALL:ALL)	可切换成的用户:组，省略则默认 root
末尾 ALL	允许执行的命令；写绝对路径则只允许那一条
NOPASSWD:	该命令免密；不加则要求输入自己的密码
sudo -l / -l -U <用户>	列出自己 / 指定用户的 sudo 规则
sudo -u <用户>	以指定用户身份执行
sudo -i / sudo -s	登录式 / 非登录式 root shell（后者保留部分原环境变量）
sudo -k	清空时间戳缓存，强制下次重新验密
su -c '<命令>'	只执行这一条命令后返回，适合脚本

规则里的命令路径请写绝对路径（which systemctl 查到的那个）——写成相对命令名的话，攻击者只要在 PATH 里放一个同名脚本就能提权。

RHEL / Rocky / AlmaLinux 9 对照

Ubuntu (sudo 组）	RHEL (wheel 组）	说明
sudo usermod -aG sudo <用户名>	sudo usermod -aG wheel <用户名>	组名不同，机制相同
安装时创建的首个用户默认在 sudo 组	需手动勾选 "Make this user administrator"	RHEL 装完要先确认
/etc/sudoers.d/*	/etc/sudoers.d/*	目录约定一致

验证方法

$ sudo -l

预期输出：

User ubuntu may run the following commands on <主机名>:
    (ALL : ALL) ALL

(ALL : ALL) ALL 表示可以以任意用户、任意组身份执行任意命令——这就是 sudo 组的默认授权。

su 加 - 与不加 - 的差别，用一条命令即可看清（先不加载环境、后加载环境）：

$ sudo su alice -c 'echo $HOME' && sudo su - alice -c 'echo $HOME'

预期输出：

/root
/home/alice

常见问题

现象	根因	解决
xxx is not in the sudoers file	既不在 sudo 组，也没有自定义规则	管理员执行 sudo usermod -aG sudo <用户名>，然后重新登录
改了 sudoers 后所有 sudo 报语法错误	用普通编辑器写入了错误语法	见下方 IMPORTANT 的挽救办法
sudo: command not found	PATH 问题（sudo 所在目录不在 PATH 里），或最小化镜像未安装 sudo	用绝对路径 /usr/bin/sudo；未安装则先想办法 apt install sudo
su - 输 root 密码总是错	Ubuntu 默认锁定 root 密码	日常提权改用 sudo -i
脚本里 sudo 卡住等密码	非交互环境无法输入密码	配精确到命令的 NOPASSWD:，不要 echo 密码 | sudo -S

[!IMPORTANT] 把自己锁在 sudo 门外后的挽救办法（代价从小到大）：① 还有另一个 sudo 账号，用它登录修复；② 有桌面环境时用 pkexec visudo 走 polkit 提权，不依赖 sudo 本身可用；③ 云服务器用厂商提供的 VNC / 串行控制台以 root 身份直连；④ 物理机重启进单用户模式（GRUB 按 e，在 linux 行末尾加 init=/bin/bash），改完 exec /sbin/init 重启。这也是为什么服务器上永远要保留两个可用的 sudo 账号。

读懂文件权限位

是什么

每个文件都记着两套信息：归谁（属主 + 属组）和谁能干什么（三组 rwx）。ls -l 第一列就是权限位：

-rw-r--r-- 1 alice devops 2048 Sep 20 10:35 report.txt
drwxr-x--- 2 alice devops 4096 Sep 20 10:35 data/

第 1 字符是类型（-文件、d目录、l软链接），随后三组分别是属主（rwx）、属组（r--）、其他人（r--）的权限。匹配规则是一次命中即停止：你就是属主的话，只看前三位，后六位完全不参与判断。

rwx 对文件和目录含义差别很大，这是初学者最大的困惑点：

权限	对文件	对目录
r	能看内容（cat）	能列出目录里的文件名（ls）
w	能改内容	能新建 / 删除 / 重命名目录内的文件
x	能当程序运行	能进入该目录（cd）并访问其中文件的元数据

[!IMPORTANT] 目录的 x 位是"能否进入"，没有 x 即使有 r 也列不出内容。 很多人以为"给了 r 就能看"，于是 chmod 644 somedir，结果 ls somedir 报 Permission denied、cd 也进不去——因为少了 x，ls 连读取目录项这一步都走不到。目录可读 = r-x(5)，可写 = rwx(7)，几乎没有例外。同理，删除文件的权限取决于其所在目录的 w 而非文件本身：444 只读的文件，只要父目录可写照样能被删——因为"删除"改的是目录的内容清单。

怎么做

# 查看权限位与归属
$ ls -l report.txt

# 查看目录本身（而不是它的内容）的权限
$ ls -ld /var/www

# 同时显示符号与数字形式，最直观
$ stat -c '%A %a %U:%G %n' report.txt

# 逐层列出路径上每一级的权限，排查长路径的神器
$ namei -l /var/www/html/index.html

八进制换算只有一句：r=4、w=2、x=1，每组相加，三组依次是属主、属组、其他人：

数字	组合	常见场景
755	rwxr-xr-x	目录的标准权限；可执行脚本
644	rw-r--r--	普通文件的标准权限（配置、网页、文档）
700	rwx------	家目录、备份目录、私密脚本
600	rw-------	私钥（SSH key、TLS 私钥）、含密码的配置
777	rwxrwxrwx	所有人可读可写可执行——永远不要用

[!WARNING] 为什么是 755 而不是 777？ 777 表示任何能登录这台机器的人都可以修改并执行该文件。放到 /var/www 上意味着普通用户能改写你的网页挂马；放到脚本上意味着别人能塞一行 rm -rf 等你或 cron 去执行。chmod 777 不是"宽松的权限设置"，而是把服务器控制权交给所有登录者。 遇到 Permission denied 时正确做法是查出该文件应该属于谁、需要什么权限再精确授权，而不是无脑加权限。唯一勉强可接受的 777 场景是 /tmp，而它靠 sticky 位兜底，实际显示为 drwxrwxrwt。

参数说明

参数	作用
ls -l	长格式：权限、硬链接数、属主、属组、大小、时间、名称
ls -ld	对目录本身操作，而不是列出它的内容
ls -lh	大小显示成 4.0K 这种人类可读形式
stat -c '%a'	只输出八进制权限位（如 644）
stat -c '%A'	只输出符号形式（如 -rw-r--r--）
stat -c '%U:%G'	输出属主名:属组名
namei -l <路径>	逐层列出路径上每一级的权限与归属

验证方法

复现"目录没有 x 位"这个经典现象：

$ mkdir demo && echo hi > demo/a.txt
$ chmod 644 demo
$ ls demo

预期输出：

ls: cannot access 'demo/a.txt': Permission denied

明明有文件、r 也给了，却连文件名都看不到；执行 chmod 755 demo 之后 ls demo 才会正常显示 a.txt。

常见问题

现象	根因	解决
目录有 r 但 ls 仍 Permission denied	缺 x 位，进不去目录就读不到目录项	chmod 755 <目录>
文件是 444 只读却被人删了	删除权限看父目录的 w	chmod o-w <父目录>
bash: ./deploy.sh: Permission denied	脚本没有 x 位	chmod +x deploy.sh，或 bash deploy.sh 显式用解释器
改了权限仍被拒	卡在父目录，任一层没 x 都进不去	namei -l <完整路径> 逐层查

遇到 Permission denied 时按这个顺序排查，比乱加权限快得多：① 权限位 → ② 属主属组 → ③ 父目录每一级 → ④ AppArmor / SELinux → ⑤ 文件系统是否只读或 immutable。

chmod 与 chown：修改权限和归属

是什么

chmod 改那三组 rwx，有两种写法：符号法（u/g/o/a 配合 +、-、=，只动你指定的那一位）和数字法（一次性给出三组最终值）。原则是微调用符号法，定值用数字法。

chown 改属主和属组，chgrp 只改属组。归属决定"这套权限对谁生效"：最典型的部署场景是文件由 root 用 sudo 解压出来、服务却以 www-data 身份运行而读不到——这时该做的是 chown www-data:www-data，不是 chmod 777。

怎么做

# 符号法：属主加执行 / 去属组写 / 清空其他人 / 所有人加读
$ chmod u+x deploy.sh
$ chmod g-w report.txt
$ chmod o= secret.txt
$ chmod a+r README.md

# 数字法
$ chmod 755 /var/www/html/index.html
$ chmod 600 ~/.ssh/id_ed25519

# 改归属：同时改属主属组 / 只改组
$ sudo chown www-data:www-data /var/www/html/index.html
$ sudo chgrp www-data /var/www/html/index.html

# 递归把整个目录树交给应用账号
$ sudo chown -R www-data:www-data /var/www/html

[!WARNING] chmod -R 无差别作用于所有层级，而文件和目录需要的权限并不相同：chmod -R 755 会把普通文件也变成可执行，chmod -R 644 则会抹掉所有子目录的 x 位、让整棵目录树再也进不去。安全做法是分开处理——目录 find /var/www/html -type d -exec chmod 755 {} +、文件 find /var/www/html -type f -exec chmod 644 {} +；也可以直接用大写 X：chmod -R a+rX /var/www/html 只给目录和已可执行文件加 x。执行任何 -R 之前先确认路径写对了——多一个空格就可能改到完全不同的地方。

[!IMPORTANT] 递归 chown -R 前请确认路径写对。最经典的事故是 chown -R www-data:www-data /var/www/html / ——末尾手滑多敲了一个空格和斜杠，在 sudo 下它会把整个根目录的所有权改掉，系统立刻崩溃且极难恢复。危险命令执行前先 ls 一遍路径，或先不加 -R 试一次看结果。

参数说明

参数	作用
u / g / o / a	属主 / 属组 / 其他人 / 三者
+ / - / =	增加 / 移除 / 精确设定（= 会清空未列出的位）
X（大写）	只对目录和"已可执行的文件"加 x，配 -R 比小写安全
chmod -R / -v / -c	递归 / 显示每条改动 / 只显示真正变化的
chmod --reference=<文件>	从参照文件复制权限
chown user:group	同时指定属主和属组
chown user: / :group	只改属主（冒号不能省）/ 只改属组
chgrp -R <组> <目录>	递归只改组，文件仍归原属主

只想让组可写又不想改属主时，用 chgrp 而不是 chown：sudo chgrp -R www-data /var/www/html && sudo chmod -R g+w /var/www/html。文件仍归你，只是同组的服务账号也能写。

验证方法

$ chmod 644 demo.txt && stat -c '%a %A' demo.txt

预期输出：

644 -rw-r--r--

chmod o= demo.txt 会清空其他人的权限，得到 640 -rw-r-----。改归属后核对：

$ sudo chown www-data:www-data demo.txt && ls -l demo.txt

预期输出：

-rw-r--r-- 1 www-data www-data 12 Sep 20 11:05 demo.txt

常见问题

现象	根因	解决
chmod: Operation not permitted	你不是属主，也不是 root	用 sudo chmod，或先 chown 到自己名下
chmod -R 644 之后整个目录进不去	目录的 x 位被抹掉	find <目录> -type d -exec chmod 755 {} + 恢复
脚本加了 x 仍报 bad interpreter	内容有问题（CRLF 换行或 shebang 错），与权限无关	head -1 script.sh；file script.sh 看是否 CRLF
chown: invalid user: 'www-date'	用户名拼错或不存在	getent passwd www-data 核对
改了属主仍 Permission denied	路径中间某层没权限，或服务被 systemd ProtectSystem= 隔离	namei -l 排查；systemctl show nginx | grep Protect

umask、特殊权限位与 ACL

是什么

umask 回答"为什么我新建的文件自动就是 644 / 755"：系统先给一个满权限初值，再减去 umask 标出的位——普通文件初值 666（本来就不给 x，避免新建文件都可执行的荒唐事），目录初值 777（必须有 x 才可用），所以 umask 022 下文件得 644、目录得 755。

特殊权限位是三组 rwx 之外的第 4 位数字，平时用得少但你要能认出来：

位	数值	作用
setuid	4	执行时以文件属主身份运行（/usr/bin/passwd 靠它让你改自己的密码）
setgid	2	对目录：其中新建的文件自动继承目录的属组，团队共享目录必配
sticky	1	对目录：只有文件属主或 root 能删自己的文件，即使目录是 777

/tmp 显示为 drwxrwxrwt —— 末尾的 t 就是 sticky 位，所有人都能建临时文件，却删不掉别人的。ACL 是 rwx 的补充：rwx 只能表达"属主 / 属组 / 其他"三类人，ACL 允许给某一个具体用户单独授权。

怎么做

# 查看当前掩码 / 符号形式 / 临时修改（只对当前 shell 有效）
$ umask
$ umask -S
$ umask 027

# 设 setgid，使目录内新建文件继承目录属组（等价数字法 chmod 2775）
$ sudo chmod g+s /srv/shared

# 加 sticky 位
$ sudo chmod +t /srv/tmpdir

# ACL：单独给 bob 读写执行；查看；删除该条
$ sudo setfacl -m u:bob:rwx /srv/shared/report.txt
$ getfacl /srv/shared/report.txt
$ sudo setfacl -x u:bob /srv/shared/report.txt

[!NOTE] 设了 ACL 后 ls -l 的权限位末尾会多一个 +（如 -rw-rwxr--+），提醒你"还有规则没显示"。备份用 getfacl -R /srv > acl.bak，恢复用 setfacl --restore=acl.bak。

参数说明

命令 / 参数	作用
umask 022	其他人不可写——Ubuntu 默认值
umask 027	其他人完全无权限，适合同组协作
umask 077	只有自己能访问，最严格，适合跳板机
chmod u+s / g+s / +t	设 setuid(4) / setgid(2) / sticky(1)
chmod 4755	4=setuid + 755
setfacl -m u:<用户>:rwx	给指定用户加 ACL（-m = modify）
setfacl -m g:<组>:rx	给指定组加 ACL
setfacl -x u:<用户> / -b	删除某条 ACL / 清除全部 ACL
getfacl <文件>	查看 ACL 规则

[!WARNING] 给脚本设 setuid 在 Linux 上无效（内核出于安全考虑忽略脚本的 setuid 位），别指望靠它提权。而给属主是 root 的二进制设 u+s，意味着任何人执行它都拥有 root 权限——若该程序有漏洞就是一条完整提权链。不要给来路不明的程序设 setuid；排查时可用 find / -perm -4000 -type f 2>/dev/null 列出系统上所有 setuid 文件。

验证方法

验证 umask 如何决定新建文件的权限：

$ umask 022
$ touch newfile && mkdir newdir
$ stat -c '%a %n' newfile newdir

预期输出：

644 newfile
755 newdir

验证 setgid 的组继承效果：我（ubuntu）建的文件，属组自动变成目录的 devops 而非我的主组——这就是 setgid。

$ sudo chmod g+s /srv/shared
$ touch /srv/shared/a.txt && ls -l /srv/shared/a.txt

预期输出：

-rw-r--r-- 1 ubuntu devops 0 Sep 20 11:20 /srv/shared/a.txt

常见问题

现象	根因	解决
改了 ~/.bashrc 里的 umask 不生效	Ubuntu 默认 ~/.profile 会 source ~/.bashrc，登录 shell 里其实同样生效；真正不生效的是非交互 shell（脚本/cron 不加载任何 bash 启动文件）	非交互场景在脚本里显式 source ~/.bashrc；或写 /etc/profile.d/umask.sh 统一所有登录环境
服务创建的文件权限与命令行不同	systemd unit 里单独设了 UMask=	systemctl show <服务> | grep UMask，在 unit 里改
chmod +t 后显示大写 T 不是 t	sticky 已设但该位没有 x	补 chmod o+x <目录>，或直接用 chmod 1777
setfacl: Operation not supported 或备份后 ACL 丢失	文件系统未开 acl；普通 cp 不保留 ACL	mount 检查挂载选项；备份改用 cp -a / rsync -a，tar 加 --acls

本章命令速查

命令	作用
id / id <用户名>	查看 UID、GID 与所属的全部组
whoami / who / last / getent passwd	当前用户名 / 在线会话 / 历史登录 / 查账号（含 LDAP）
sudo adduser <用户名> 或 useradd -m -s /bin/bash	创建用户（前者交互式，推荐新手）
sudo passwd <用户名>	设密码；passwd -S 看锁定状态
sudo usermod -aG sudo <用户名>	加入 sudo 组（-a 不能忘）
sudo usermod -L / -U <用户名>	锁定 / 解锁账号
sudo userdel -r <用户名>	删用户并删家目录（危险）
sudo groupadd / gpasswd -a / -d	建组 / 加人 / 减人
sudo -l	查看自己被授予的 sudo 规则
sudo visudo -f /etc/sudoers.d/<名>	安全编辑自定义授权规则
su - <用户名> / sudo -i	完整切换身份 / 提权到 root
ls -l / stat -c '%a %A %U:%G'	查看权限位与归属；后者一次看全数字 + 符号 + 属主
chmod 755 / 644 / 700 / 600	目录 / 普通文件 / 私密目录 / 私钥
chmod u+x / g-w / o= / a+rX	符号法微调权限
sudo chown <用户>:<组> <文件>	改属主与属组；只改组用 chgrp；-R 递归
umask / chmod g+s / chmod +t	查看默认掩码 / 设 setgid 继承属组 / 设 sticky 防互删
setfacl -m u:<用户>:rwx <文件> / getfacl	给单个用户单独授权 / 查看 ACL

相关章节

• 00 前言与阅读约定 —— 全篇命令约定、安全基线与危险命令红名单
• 10 Shell 与文件系统 —— FHS 目录地图，理解 /etc、/home 的定位
• 11 文件操作 —— cp -a / rsync -a 如何保留权限与归属
• 14 进程管理 —— 用 ps -o user= 确认进程以什么身份运行
• 16 防火墙 —— 网络层访问控制，与文件权限互补
• 18 SSH 远程登录与安全加固 —— 密钥与 ~/.ssh 目录权限要求、禁 root 直登
• 40 systemd 服务管理 —— 服务的 User=、UMask=、ProtectSystem= 如何影响权限
• 43 运维工具箱 —— lsof 定位「文件被谁占用」

📄 进程管理 14-process-management.md✓ 标记已学

---

title: 进程管理 updated: 2026-09 applies-to: Ubuntu 22.04 LTS

程序是躺在磁盘上的文件，进程是它被运行起来之后在内存里的实例。同一个 Nginx 程序可以同时跑出十几个进程，每个都有一份独立的运行时状态。服务器上"服务起不来""CPU 飙高""端口被占"本质上都是进程问题，所以这一章是排错的地基。

全章最重要的两条原则：先 SIGTERM、实在不行才 SIGKILL；杀进程前先确认你杀对了。

[!NOTE] 本章命令与默认行为均基于 Ubuntu 22.04 LTS，版本相关信息截至 2026-09。

进程、PID 与父子关系

是什么

内核给每个进程分配一个唯一编号 PID（Process ID），并记下是谁启动了它——PPID（Parent PID）。于是所有进程构成一棵树：开机后内核启动的第一个用户态进程是 systemd（PID 1），它拉起 sshd、cron、网络服务，sshd 再为你每个 SSH 连接开一个 bash，bash 再启动你敲的每一条命令。

这个"父子"关系在排错时非常有用：

• 父进程退出，子进程会被"过继"给 PID 1（称为孤儿进程），不会消失
• 子进程退出但父进程没来收尸，它就变成僵尸进程（<defunct>），占着一个 PID 条目
• 杀父进程通常不会自动杀掉子进程，这就是为什么"重启了服务但旧进程还在"

概念	含义
PID	进程的唯一编号，kill 就是按它寻址
PPID	父进程编号，据此画出进程树
PID 1	systemd，所有进程的最终祖先
僵尸进程	已退出但父进程未回收，状态为 Z

怎么做

# 以树状结构查看进程关系（看清谁拉起了谁）
$ pstree -p

# 只看某个进程的树
$ pstree -p -s <PID>

# 查自己的 PID 与父进程
$ echo $$         # 当前 shell 的 PID
$ ps -o pid,ppid,cmd -p $$

# 查某个进程的父子信息
$ ps -o pid,ppid,cmd -p <PID>

参数说明

参数	作用
pstree -p	显示树状结构并标出每个进程的 PID
pstree -p -s <PID>	只显示指定进程及其祖先链（-s = show parents）
pstree -u	在进程名后标出属主，多用户机器上很直观
ps -p <PID>	只看指定 PID
$$	Shell 变量，展开为当前 shell 自己的 PID
$!	Shell 变量，展开为最近一个后台任务的 PID

验证方法

$ ps -o pid,ppid,stat,cmd -p $$

预期输出：

  PID  PPID STAT CMD
 8123  8119 Ss   -bash

当前 bash 的 PID 是 8123，它的父进程是 8119——顺着 8119 往上查，最终会走到 SSH 会话和 PID 1。

常见问题

现象	根因	解决
pstree: command not found	精简镜像没装 psmisc	sudo apt install psmisc
子进程还在，父进程没了	父进程退出后子进程被过继给 PID 1	属正常；要一起停得显式杀子进程或改用 systemd 托管
进程名后面带 <defunct>	僵尸进程，父进程未回收	杀不掉，需重启其父进程（真正要修的是父程序）
杀掉父进程后子进程仍在跑	Linux 不会级联杀子进程	用 pkill -P <PPID> 按父进程批量清理子进程

查看进程：ps 与 pgrep

是什么

ps 是"拍一张快照"，它只显示执行瞬间的状态，不会刷新。它有两大风格，混用是新手最常见的困扰：

风格	写法	来源	特点
BSD 风格	ps aux	BSD 传统	选项不带短横线，输出含 %CPU %MEM、命令行完整
System V 风格	ps -ef	UNIX 传统	选项带短横线，额外显示 PPID

两者看到的进程完全一样，只是列不同。日常推荐 ps aux（列更实用），需要看 PPID 时用 ps -ef 或 ps -eo。

按名字找进程还有更省事的命令：pgrep 直接输出匹配到的 PID，pkill 直接对它们发信号。

怎么做

# BSD 风格：看全部进程，含资源占用与完整命令行
$ ps aux

# System V 风格：额外带 PPID
$ ps -ef

# 找 nginx 相关进程（注意 grep 自身也会匹配到）
$ ps aux | grep nginx

# 用 pgrep 直接拿到 PID，不会匹配到自己
$ pgrep -f nginx

# 自定义输出列：PID、父进程、启动时长、完整命令
$ ps -o pid,ppid,cmd,etime -p <PID>

# 只看某个用户的所有进程
$ ps -u www-data

[!TIP] ps aux | grep nginx 的结果里总有一条是 grep nginx 自己（因为它也是个进程，命令行里含 "nginx"）。想排除它，用 ps aux | grep '[n]ginx'，或者干脆用 pgrep -f nginx——后者不会把检索命令本身算进去。

参数说明

参数	作用
a	显示所有用户的进程（不只是自己的）
u	以用户友好的格式显示，含属主、%CPU、%MEM
x	包含没有控制终端的进程（守护进程关键在这）
-e	显示所有进程，等价于 BSD 的 ax
-f	全格式，含 PPID 与完整命令行
-o <列名>	自定义输出列，如 pid,ppid,cmd,etime,user,%cpu,%mem
etime	进程从启动到现在过了多久（比 TIME 的 CPU 时间更直观）
pgrep -f <模式>	按完整命令行匹配（不加 -f 只匹配进程名）
pgrep -u <用户>	只看某用户的进程
pgrep -a	同时打印 PID 和完整命令行

验证方法

$ ps -o pid,ppid,user,%cpu,%mem,etime,cmd -p $$

预期输出：

  PID  PPID USER     %CPU %MEM ELAPSED CMD
 8123  8119 ubuntu    0.0  0.1   02:31 -bash

各列含义：PID、父进程、属主、CPU 占用率、内存占用率、已运行 2 分 31 秒、完整命令。

确认 pgrep 不会匹配到自己：

$ pgrep -f nginx

预期输出：

1042
1043
1044

只列出真正的 nginx 进程 PID，没有多余条目。

常见问题

现象	根因	解决
ps aux 看不到别人的进程	容器/PID 命名空间隔离，只能看到本命名空间	属正常；宿主机上 ps aux 才看得到全部
命令行被截断看不全	默认按终端宽度截短	加 -ww（ps auxww），或用 ps -ef
grep 结果里总有一条多余的	grep 自身进程也被匹配	用 pgrep / grep '[n]ginx'
ps aux 里 STAT 列出现 Z	僵尸进程	见上一节，需处理其父进程
想看进程占用哪个端口	ps 不显示端口	用 ss -lntp 或 lsof -i:<端口>（见常见问题汇总）

实时监控：top 与 htop

是什么

ps 是快照，top 是实时刷新的动态视图（默认每 3 秒）。它的输出分两部分：上方 5 行是系统总览，下方是进程列表。

首部行	含义
第 1 行	当前时间、运行时长、登录用户数、load average（1/5/15 分钟）
第 2 行 Tasks	进程总数及 running / sleeping / stopped / zombie 数量
第 3 行 %Cpu(s)	CPU 时间分配：us用户态、sy内核态、id空闲、wa等待 IO、st被虚拟机偷走
第 4 行 MiB Mem	物理内存：总量 / 空闲 / 已用 / 缓存与缓冲
第 5 行 MiB Swap	交换分区：总量 / 空闲 / 已用

[!TIP] 第 3 行的 wa（iowait）高是重要信号：它说明 CPU 在等磁盘或网络 IO 返回，而不是在计算。这时去优化 CPU 是南辕北辙，该查的是磁盘（iostat）和慢查询。

htop 是 top 的增强版：支持鼠标、彩色、横向滚动看完整命令行、直接按树状显示。Ubuntu 22.04 默认没装，需要 sudo apt install htop。

怎么做

# 启动实时监控（按 q 退出）
$ top

# 只监控某个用户的进程
$ top -u www-data

# 只盯着某个进程
$ top -p <PID>

# 安装并使用 htop
$ sudo apt install htop
$ htop

top 运行时的常用交互键：

按键	作用
q	退出
P	按 CPU 占用排序（默认）
M	按内存占用排序
1	展开显示每个 CPU 核心的单独占用率
k	杀进程（会提示输入 PID 和信号）
c	显示完整命令行（不再截断）
H	按线程显示而非进程

参数说明

参数	作用
-d <秒>	刷新间隔，如 top -d 1 每秒刷新
-p <PID>	只看指定进程，多个用逗号分隔
-u <用户>	只看指定用户的进程
-b	批处理模式，输出到标准输出，适合脚本采集（top -b -n 1）
-n <次数>	刷新 N 次后退出，配合 -b 用
-H	显示线程
htop -t	以树状结构显示父子关系
htop -u <用户>	只看某用户的进程

RHEL / Rocky / AlmaLinux 9 对照

Ubuntu (apt)	RHEL (dnf)	说明
sudo apt install htop	sudo dnf install htop	包名一致，包管理器不同
top（procps-ng）	top（procps-ng）	命令与快捷键完全一致
sudo apt install psmisc（pstree）	sudo dnf install psmisc	同上

验证方法

取一次性的系统总览（不进入交互界面，适合写进脚本或贴到工单里）：

$ top -b -n 1 | head -n 5

预期输出：

top - 14:32:10 up 12 days,  3:41,  2 users,  load average: 0.35, 0.42, 0.38
Tasks: 187 total,   1 running, 186 sleeping,   0 stopped,   0 zombie
%Cpu(s):  3.1 us,  1.2 sy,  0.0 ni, 95.4 id,  0.3 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :   3916.9 total,    512.3 free,   1180.4 used,   2224.2 buff/cache
MiB Swap:   2048.0 total,   2048.0 free,      0.0 used

判读：负载 0.35 很低；zombie 为 0 说明没有僵尸进程；id 95.4% 说明 CPU 基本空闲；wa 0.3% 说明没有 IO 瓶颈；内存里真正被程序用的是 used，buff/cache 那部分内核会自动回收，不算占用。

常见问题

现象	根因	解决
top 里 %CPU 超过 100%	多核机器上按单核归一化，400% = 占满 4 核	属正常；按 1 看每核分别占用
内存看起来几乎用满	Linux 会用空闲内存做磁盘缓存（buff/cache）	看 used 而非 free；缓存可被内核自动回收
htop: command not found	未安装	sudo apt install htop
top 里看不到想找的进程	默认按 CPU 排序，进程在后面	按 c 看完整命令行，或用 top -p <PID>
zombie 数量不为 0	父进程没回收子进程	找到其父进程并重启父进程

理解 load average

是什么

load average 是 top 第一行末尾和 uptime 输出的三个数字，例如 0.35, 0.42, 0.38，分别是过去 1 分钟、5 分钟、15 分钟的系统平均负载。

它的含义常被误解：负载统计的是可运行（正在用 CPU 或排队等 CPU）的进程数 + 不可中断睡眠（等 IO）的进程数，不是 CPU 百分比。

判读的关键是核心数：

场景	判断
单核，负载 1.00	CPU 刚好打满，所有任务无需排队
单核，负载 2.00	有一半进程在排队，明显过载
4 核，负载 4.00	刚好打满（等价于单核的 1.00）
4 核，负载 1.00	只用了约 1/4 算力，很闲

[!IMPORTANT] 负载高 ≠ CPU 高。 如果 top 里 %Cpu 的 wa（iowait）很高而 us/sy 很低，说明进程都卡在等磁盘或网络 IO 上——它们不消耗 CPU，但仍然计入负载。同理，大量进程争抢一把锁（如数据库锁、NFS 挂死）也会让负载飙升而 CPU 空闲。所以看到负载高，第一步是看 wa，而不是急着找 CPU 大户。

三个值的趋势同样重要：1 分钟高而 15 分钟低 = 刚刚开始有压力；1 分钟低而 15 分钟高 = 压力正在缓解；三个都高且持续 = 真的过载了。

怎么做

# 看负载与运行时长
$ uptime

# 确认有几个核（判读负载的分母）
$ nproc

# 更详细的 CPU 信息
$ lscpu | grep -E '^CPU\(s\)|Model name'

# 看 CPU 各状态占比，重点看 wa
$ top -b -n 1 | head -n 3

参数说明

命令 / 参数	作用
uptime	一行显示运行时长、登录数、1/5/15 分钟负载
nproc	打印可用 CPU 核心数——判读负载的分母
lscpu	显示 CPU 架构、核心数、线程数、型号
cat /proc/loadavg	直接读内核暴露的负载值，前三个即 1/5/15 分钟
top 的 wa	iowait 占比，判断负载是否来自 IO
top 的 st	steal time，虚拟机上被宿主机"偷走"的 CPU，高说明宿主机超卖

验证方法

$ nproc && uptime

预期输出：

4
 14:32:10 up 12 days, 3:41, 2 users, load average: 1.20, 0.90, 0.60

判读：4 核机器，1 分钟负载 1.20 相当于占用了 30% 算力，不算过载；但 1 分钟 > 5 分钟 > 15 分钟，说明压力正在上升，值得继续观察。

$ cat /proc/loadavg

预期输出：

1.20 0.90 0.60 2/187 91234

前三个是 1/5/15 分钟负载，2/187 表示当前可运行进程数 2、总进程数 187，最后是最近创建的 PID。

常见问题

现象	根因	解决
负载很高但 CPU 空闲	进程卡在 IO（wa 高）或争锁	查磁盘 iostat -x 1、查数据库慢查询、查 NFS
负载很低但服务很慢	瓶颈不在 CPU（可能是网络延迟、DNS、连接池）	换个方向排查，别只盯负载
容器里 uptime 显示的负载是宿主机的	容器共享宿主机内核，/proc/loadavg 未被隔离	属正常，看容器的 CPU 配额与用量
负载突然飙升又回落	定时任务（cron）、日志轮转、备份	对比 1/5/15 分钟三个值判断是瞬时还是持续
虚拟机里明明很闲但负载高	st（steal）高，宿主机超卖	联系云厂商或迁移实例

前后台、作业控制与脱离终端

是什么

在终端里直接敲命令，进程在前台运行并独占终端——它不结束你就敲不了下一条命令。在命令末尾加 &，进程就进入后台运行，终端立刻还给你。

但后台进程仍然依附于这个终端（会话）。SSH 断开时，系统会向该会话的所有进程发 SIGHUP（hangup，挂断信号），默认行为就是终止进程。这就是为什么"关掉终端，程序就死了"。

手段	原理	适合场景
&	放到后台，但仍属于当前会话	临时让出终端
Ctrl+Z + bg	先挂起再转后台	命令已经在前台跑起来了才想转后台
nohup	忽略 SIGHUP，且自动把输出重定向到 nohup.out	简单的一次性长任务
setsid	让进程脱离当前会话，成为新会话组长	需要完全脱离终端
tmux / screen	虚拟终端，断开会话也不影响里面的进程	长期运行、还要回去看输出（最推荐）

怎么做

# 后台运行（终端立即可用）
$ long-task &

# 查看当前会话的后台作业
$ jobs

# 把 1 号作业拉回前台 / 让它在后台继续
$ fg %1
$ bg %1

# 挂起当前前台进程：这是键盘操作，直接按 Ctrl+Z 键（不是命令），之后可用 bg 转后台

# 脱离终端运行：忽略 SIGHUP，输出自动写入 nohup.out
$ nohup long-task > task.log 2>&1 &

# 完全脱离当前会话
$ setsid long-task > task.log 2>&1 &

# 最推荐：用 tmux 开一个可随时回来的会话
$ sudo apt install tmux
$ tmux new -s work

[!WARNING] nohup 只解决"不会被 SIGHUP 杀掉"，不解决输出无处可去的问题。 如果你写了 nohup cmd & 却没重定向，输出会写进当前目录的 nohup.out——它可能在无人看管的情况下涨到几十 GB 撑爆磁盘。规范写法永远是显式重定向：nohup cmd > /var/log/myapp.log 2>&1 &，并且交给 logrotate 管理（见 54-logrotate.md）。线上长期服务请不要用 nohup，改用 systemd（见 40-systemd.md），它自带重启、日志和资源限制。

在 tmux 会话里，Ctrl+B 然后按 D 可以"脱离"（detach），进程继续跑；之后 tmux attach -t work 可以原样回来。

参数说明

命令 / 参数	作用
&	放到后台执行，$! 拿到它的 PID
Ctrl+Z	向前台进程发 SIGTSTP，挂起（暂停而非终止）
jobs	列出当前会话的后台作业，%1 是作业号
fg %N / bg %N	把 N 号作业拉回前台 / 在后台继续运行
disown %N / disown -h	把作业从 shell 的作业表移除，使其不受本次会话退出影响
nohup	忽略 SIGHUP；未重定向时输出写 nohup.out
setsid	在新会话中启动进程，彻底脱离当前终端
> file 2>&1	标准输出和错误输出都写进 file
tmux new -s <名>	新建一个具名会话
tmux attach -t <名>	重新连回会话

验证方法

后台运行后确认它还在：

$ sleep 300 &
$ jobs -l

预期输出：

[1]+  9128 Running                 sleep 300 &

[1] 是作业号，9128 是 PID，Running 是状态。

验证 nohup 已经忽略 SIGHUP（用 ps 看不出来，要发一个信号试）：

$ nohup sleep 600 > /dev/null 2>&1 &
$ kill -HUP $! ; sleep 1 ; ps -p $! -o pid,cmd=

预期输出：

 9347 sleep 600

进程仍然存在，说明 HUP 被忽略了。普通后台任务在收到 HUP 后会立刻消失。

常见问题

现象	根因	解决
SSH 断开后进程就没了	会话退出时内核对该会话发 SIGHUP	用 nohup、setsid，或放进 tmux / systemd
关掉终端后程序"卡住"不退出	进程仍持有终端，写输出时阻塞	启动时就把 stdout/stderr 重定向到文件或 /dev/null
当前目录莫名出现巨大 nohup.out	用了 nohup 却没重定向	显式重定向，并 rm 掉旧文件（注意先确认无人写入）
jobs 看不到之前启动的后台任务	jobs 是 shell 内置，只认当前会话	换个终端就看不到了，用 ps aux | grep 找
disown 之后进程消失了	disown 只是移出作业表，并不阻止 SIGHUP	先 nohup 或 setsid 再考虑 disown

信号与终止进程

是什么

kill 这个名字有误导性——它真正的含义是向进程发一个信号，进程收到后怎么做由它自己决定。信号是进程间最基础的通信方式。

最常用的两个：

信号	编号	默认行为	什么时候用
SIGTERM	15	请求退出，进程可以捕获并做收尾	默认第一选择
SIGKILL	9	内核直接杀死，进程无法捕获、无法拒绝	只有 TERM 无效时才用

SIGTERM 相当于礼貌地请人离开：程序可以保存数据、关闭连接、清理临时文件、通知上游。"服务停不下来"时很多人直接 kill -9，代价是程序没机会做这些事。

其他常见信号：SIGHUP(1) 挂断，很多程序收到它会重新加载配置；SIGINT(2) 就是 Ctrl+C；SIGSTOP(19) 暂停进程（不可被捕获），SIGCONT(18) 继续。

怎么做

# 列出所有信号
$ kill -l

# 优雅停止（默认就是 SIGTERM）
$ kill <PID>

# 只有 TERM 无效时才用 -9
$ kill -9 <PID>

# 让程序重读配置（nginx / sshd 等都支持）
$ sudo kill -HUP <PID>

# 按进程名批量终止
$ killall nginx

# 按完整命令行匹配终止
$ pkill -f "python app.py"

# 先确认会杀到谁（把 pkill 换成 pgrep 预演一遍）
$ pgrep -af "python app.py"

[!WARNING] kill -9 是最后的手段，不是第一选择。 进程收到 SIGKILL 时会被内核立刻抹掉，没有任何机会执行清理代码。对数据库（MySQL、PostgreSQL、Redis）和数据写入类程序，kill -9 很可能造成数据文件损坏、事务丢失、启动时长时间崩溃恢复。正确顺序是：先 kill <PID>（TERM）→ 等 10~30 秒 → 仍无反应再 kill -9。如果是 systemd 托管的服务，一律用 systemctl stop，它会先 TERM 再超时 KILL，并且知道正确的停止流程。

[!WARNING] pkill -f 按完整命令行做正则匹配，非常容易误杀。 例如 pkill -f java 会杀掉机器上所有命令行里含 "java" 的进程——可能包括你不想碰的另一个服务，甚至包括你自己正在跑的部署脚本。执行前请先用 pgrep -af <模式> 把将要被杀的进程完整列出来核对一遍，确认无误后再把 pgrep 换成 pkill。

参数说明

命令 / 参数	作用
kill -l	列出全部信号名与编号
kill <PID>	发 SIGTERM（15），默认信号
kill -9 <PID> / kill -KILL	发 SIGKILL，强制、不可捕获
kill -HUP <PID>	发 SIGHUP(1)，多数守护进程用来重读配置
kill -STOP / -CONT <PID>	暂停 / 继续进程（19 / 18）
kill -0 <PID>	不发信号，只探测进程是否存在（写脚本判断存活常用）
killall <名字>	按进程名终止所有匹配进程
pkill -f <模式>	按完整命令行正则匹配终止（危险，见上方警告）
pgrep -af <模式>	安全地预演：-a 打印 PID + 完整命令行
pkill -u <用户>	终止某用户的所有进程（踢人下机常用）

验证方法

先确认目标进程，再终止，最后确认已消失：

$ pgrep -af "sleep 900"

预期输出：

9150 sleep 900

$ kill 9150 ; sleep 1 ; ps -p 9150 -o pid,cmd=

预期输出：

（无输出，进程已退出）

ps -p 找不到该 PID 时输出为空，说明进程确实结束。用 kill -0 探测存活更明确：

$ kill -0 9150 2>/dev/null && echo "还在" || echo "已退出"

预期输出：

已退出

常见问题

现象	根因	解决
kill -9 也杀不掉	进程处于 D 状态（不可中断睡眠，通常卡在磁盘/NFS），或已是僵尸	D 状态只能等 IO 恢复或重启；僵尸进程需杀其父进程
kill: (PID) - Operation not permitted	该进程不属于你，也不是 root	用 sudo kill，或让属主操作
kill 后进程立刻又出现了	被 systemd / supervisor / PM2 自动拉起	要停服务就用 systemctl stop <服务>，别直接 kill
killall: command not found	未装 psmisc	sudo apt install psmisc，或用 pkill
误杀了不该杀的进程	用了宽泛的 pkill -f 模式	以后先 pgrep -af 预演；被杀的服务用 systemctl start 恢复
端口被占用，要先找到是哪个进程	需要反查监听者	sudo ss -lntp | grep :<端口> 或 sudo lsof -i:<端口>

进程优先级与按资源定位

是什么

Linux 用 nice 值表示进程的"谦让程度"，范围 -20（最优先，抢 CPU）到 +19（最谦让，让别人先跑），默认 0。nice 值越高，分到的 CPU 时间越少。它的意义在于：让备份、日志压缩这类批处理任务别拖垮线上服务。

按资源定位进程则是排错的核心动作——"CPU 飙高""内存爆了"都要能第一时间找出是哪个进程。

怎么做

# 以低优先级启动（+10 表示谦让，不抢线上服务的 CPU）
$ nice -n 10 tar czf backup.tgz /data

# 调整已在运行的进程的优先级
$ sudo renice -n 10 -p <PID>

# 按内存占用找前 5 名
$ ps aux --sort=-%mem | head -n 6

# 按 CPU 占用找前 5 名
$ ps aux --sort=-%cpu | head -n 6

# 查看进程的 nice 值（NI 列）
$ ps -o pid,ni,cmd -p <PID>

[!NOTE] 调低 nice 值（提高到 -20 这样的负优先级）需要 root 权限，普通用户只能把自己的进程越调越谦让（0 → 19）。这是防止普通用户抢占系统资源的设计。

参数说明

命令 / 参数	作用
nice -n <值> <命令>	以指定 nice 值启动进程，默认 10
renice -n <值> -p <PID>	改运行中进程的 nice 值
renice -n <值> -u <用户>	改某用户所有进程的 nice 值
ps --sort=-%mem	按内存降序（- 表示降序）
ps --sort=-%cpu	按 CPU 降序
ps -o ni / top 的 NI 列	查看 nice 值
head -n 6	取 5 条进程 ——多出的 1 行是 ps 的表头
top -b -n 1 -o %MEM	批处理模式下按内存排序，适合脚本
systemd 的 Nice=	unit 里配置服务的固定优先级

验证方法

$ ps aux --sort=-%mem | head -n 3

预期输出：

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
mysql     1042  2.1 18.4 1758236 721356 ?      Ssl  Sep12  45:12 /usr/sbin/mysqld
www-data  2311  0.3  4.2  238412 165204 ?      S    Sep12   3:04 nginx: worker process

第一列之后看 %MEM：mysqld 占了 18.4% 内存（RSS 721356 KB ≈ 704 MB），是本机内存大户。

验证 nice 值生效：

$ nice -n 10 sleep 600 &
$ ps -o pid,ni,cmd -p $!

预期输出：

  PID  NI CMD
 9180  10 sleep 600

NI 列为 10，说明该进程以谦让模式运行，会主动把 CPU 让给更重要的进程。

常见问题

现象	根因	解决
renice: failed to set priority	普通用户不能提高优先级（调低 nice 值）	加 sudo
明明有进程占内存，%MEM 却不高	机器内存很大，或看的是 VSZ（虚拟内存）而非 RSS	看 RSS 列（实际物理内存）
找不到 CPU 高的进程但负载很高	负载来自 IO（wa 高），不是 CPU	查 iostat -x 1 和 iotop
ps --sort 排序结果不对	列名要带 % 且区分大小写	用 --sort=-%cpu / --sort=-rss
想限制进程最多用多少 CPU / 内存	nice 只是相对权重，不是硬限制	用 systemd 的 CPUQuota=、MemoryMax=（见 40-systemd.md）
负载高，不知从何入手	可能来自 CPU、IO、内存三个方向	先看 top 的 %Cpu 与 wa，再决定查 ps --sort 还是 iostat

[!TIP] 负载高时的三步入手法：① 看 top 的 wa ——高就是 IO 问题，去查磁盘和慢查询；② wa 不高则按 P 按 CPU 排序找出 CPU 大户；③ 内存紧张时按 M 排序，并留意 swap 是否被用到（用到说明物理内存不足，性能会断崖式下降）。

本章命令速查

命令	作用
pstree -p	树状查看进程父子关系
ps aux / ps -ef	查看全部进程（BSD 风格 / System V 风格）
ps -o pid,ppid,cmd,etime -p <PID>	自定义列查看进程与运行时长
pgrep -af <模式>	按完整命令行查找并打印 PID + 命令（杀进程前预演）
top / htop	实时监控（后者需安装，交互更友好）
top -b -n 1 | head -n 5	取一次系统总览，适合写进工单
uptime / nproc	看负载 / 看核心数（判读负载的分母）
命令 & / jobs	后台运行 / 查看后台作业
fg %1 / bg %1 / disown	拉回前台 / 后台继续 / 移出作业表
nohup cmd > log 2>&1 &	忽略 SIGHUP 并重定向输出，断网也不停
setsid cmd > log 2>&1 &	彻底脱离当前会话
tmux new -s <名> / attach -t	建可重连的虚拟终端会话（长期任务推荐）
kill -l	列出所有信号
kill <PID> / kill -9 <PID>	优雅终止（TERM）/ 强制杀死（KILL，最后手段）
kill -HUP <PID>	让守护进程重读配置
kill -0 <PID>	只探测进程是否存活，不发信号
pkill -f <模式> / killall <名>	按命令行 / 进程名批量终止（先 pgrep -af 预演）
nice -n 10 <命令> / renice -n 10 -p <PID>	以低优先级启动 / 调整运行中进程优先级
ps aux --sort=-%cpu | head -n 6	找 CPU 占用最高的 5 个进程
ps aux --sort=-%mem | head -n 6	找内存占用最高的 5 个进程

相关章节

• 00-preface.md —— 全篇命令约定、安全基线与危险命令红名单
• 13-users-and-permissions.md —— 用 ps -o user= 确认进程以什么身份运行
• 15-network-configuration.md —— 端口被占用时如何定位监听进程
• 16-firewall.md —— 进程在跑但访问不到，可能是防火墙挡了
• 40-systemd.md —— 长期服务的正确托管方式：Nice=、CPUQuota=、MemoryMax=
• 42-process-supervision.md —— systemd / supervisor / PM2 三种守护方式选型
• 43-ops-toolbox.md —— htop / iotop / lsof / strace 等排错工具
• 54-logrotate.md —— 后台进程日志无限增长的处理办法
• 92-troubleshooting-playbook.md —— 通用排错方法论与症状索引

📄 网络配置 15-network-configuration.md✓ 标记已学

---

title: 15 网络配置 updated: 2026-09 applies-to: Ubuntu 22.04 LTS

服务器「连不上」是新手遇到频率最高、也最容易慌的问题。本章先给你一套从近到远的排错思路，再逐层讲清楚：怎么看 IP、怎么看监听端口、怎么测连通性、DNS 和主机名是怎么回事、怎么配静态 IP、为什么时间必须准。学完本章，面对「服务器不通」你不再靠猜，而是按层排查。

[!NOTE] 本章版本号截至 2026 年 9 月。版本信息的唯一权威来源是 版本速查表，冲突时以速查表为准。

排错思路：从近到远四层

是什么

网络排错的核心思想是：问题一定出在从本机到目标之间的某一段路上，逐段确认就能定位。就像家里停水时，你会先看自家水龙头，再看小区是否停水，而不是直接打电话问自来水厂。服务器排错同理，按「离自己由近到远」的顺序检查四层，每一层都有对应的命令。

怎么做

先记住这张排查路线表，后面小节会逐条展开：

层	确认什么	命令	通了说明
1. 本机 IP	网卡有没有拿到地址	ip a	本机网络配置存在
2. 网关	能不能出去（ping 网关 / 公网 IP）	ping -c 4 192.168.1.1	本机到出口的链路正常
3. DNS	域名能不能解析成 IP	dig example.com	名字解析正常
4. 目标端口	对方服务端口通不通	curl -I http://<服务器IP>:80	端到端全部正常

排错时从上往下走，在哪一层断掉，问题就在哪一层：

# 第 1 层：本机有 IP 吗？
$ ip -br a
# 第 2 层：网关通吗？（网关地址从 ip r 里看）
$ ip r
$ ping -c 4 192.168.1.1
# 第 3 层：DNS 正常吗？直接 ping 一个公网 IP 对比
$ ping -c 4 223.5.5.5
$ dig example.com
# 第 4 层：目标端口通吗？
$ curl -I http://example.com

参数说明

• 为什么要分层次：新手最常见的错误是「curl 不通就重启服务器」。分层的意义在于把一个大问题（连不上）拆成四个小问题，每个小问题都有明确的是/否答案，定位效率完全不同。
• 第 2 层 ping 公网 IP（如 223.5.5.5）是关键对照实验：如果 ping IP 通、ping 域名不通，问题几乎可以锁定在 DNS，而不是网络断了。
• 第 4 层要分清「网络不通」和「服务没起」：能 ping 通但端口不通，多数情况不是网络问题，而是目标机器上服务没监听或防火墙拦截。

验证方法

按顺序执行四层检查，正常情况下每层都应有响应：

# 第 1 层：确认本机有 IP
$ ip -br a

预期输出：
lo               UNKNOWN        127.0.0.1/8 ::1/128
ens33            UP             192.168.1.10/24 fe80::20c:29ff:fe8a:1234/64

常见问题

现象	根因	解决
不知道从哪查起，乱试命令	没有排查框架	严格按本节路线表从第 1 层走到第 4 层，断在哪层查哪层
ping 网关都不通	网线/虚拟网络/云安全组问题	检查虚拟机网络模式（NAT/桥接）或云控制台安全组
四层都通但应用还是连不上	应用层问题（配置错端口、认证失败）	看应用日志，网络问题已排除

查看网卡地址与路由

是什么

ip 命令是 Linux 当代标准的网络查看/配置工具，属于 iproute2 包，Ubuntu 默认自带。老教程里的 ifconfig 属于 net-tools 包，已停止维护多年，Ubuntu 默认根本没装。看到教程让你 ifconfig，直接换成 ip a 即可，功能对应关系本章会给出。

怎么做

# 查看所有网卡的详细地址信息（最常用）
$ ip a
# 简洁视图：一行一块网卡，日常排错更快
$ ip -br a
# 查看路由表，default 那一行就是默认网关
$ ip r

ifconfig → ip 的常用对应关系：

老命令（net-tools，过时）	新命令（iproute2，推荐）
ifconfig	ip a
route -n	ip r

参数说明

• ip -br a 里的 -br 是 --brief（简洁），只显示网卡名、状态、地址三列，适合快速扫一眼。
• ip r 输出里 default via 192.168.1.1 表示：去往任何未知网络的数据包，都先交给 192.168.1.1（网关）转发。网关地址就是你的「出口大门」，排错第 2 层 ping 的就是它。
• 网卡名在新系统上叫 ens33、enp0s3、eth0 等，不再统一叫 eth0，写配置时以 ip a 看到的为准。

验证方法

# 简洁视图确认网卡和 IP；再看默认网关
$ ip -br a
$ ip r

预期输出：
lo               UNKNOWN        127.0.0.1/8 ::1/128
ens33            UP             192.168.1.10/24
default via 192.168.1.1 dev ens33 proto dhcp src 192.168.1.10 metric 100
192.168.1.0/24 dev ens33 proto kernel scope link src 192.168.1.10

default via 192.168.1.1 就是默认网关，排错第 2 层要 ping 的就是它。

常见问题

现象	根因	解决
ifconfig: command not found	net-tools 已被淘汰，默认不装	用 ip a，不要安装过时包
ip a 里网卡显示 DOWN 且无 IP	网卡没起来（驱动/虚拟网络问题）	sudo ip link set 网卡名 up 后观察，仍不行查虚拟网络配置
只有 lo，看不到 ens33	虚拟机网络适配器未连接 / 云主机网卡异常	VMware/VirtualBox 检查「已连接」选项；云主机在控制台查看网卡状态

RHEL / Rocky / AlmaLinux 9 对照

Ubuntu (apt/ufw)	RHEL (dnf/firewalld)	说明
ip a / ip r（自带）	ip a / ip r（自带）	iproute2 两边一致，命令通用
网卡名常见 ens33	常见 ens160、enp1s0	命名规则相同，以实际输出为准
网络由 netplan 管理	网络由 NetworkManager 管理	改 IP 的方式不同，见本章 netplan 一节的对照块

查看连接与监听端口

是什么

ss（socket statistics）是当代查看网络连接的标准工具，取代了老教程里的 netstat。它回答两个高频问题：「我的服务到底监听了哪个端口、监听在哪个地址上」和「现在有哪些连接连进来了」。判断「服务没起」还是「防火墙挡了」，全靠它。

怎么做

# 查看所有 TCP 监听端口，并显示是哪个进程在监听（最常用）
$ sudo ss -lntp
# 汇总统计：各类 socket 数量一览
$ ss -s
# 只看已建立的连接（排查谁在连我 / 我连着谁）
$ sudo ss -tnp | grep ESTAB

netstat → ss 一一对应：netstat -lntp 即 ss -lntp，netstat -an 即 ss -tan，netstat -s 即 ss -s。看到老教程里的 netstat 命令，直接替换成 ss 即可。

参数说明

ss -lntp 四个字母拆开记：-l 只显示 listening（正在监听）的 socket；-n 不解析域名和端口名，直接显示数字（快，且不受 DNS 故障影响）；-t 只看 tcp；-p 显示占用端口的process（进程名和 PID），需要 sudo 才能看到全部。

输出里监听地址是关键：127.0.0.1:3306 表示只有本机能连；0.0.0.0:3306 表示所有网卡都能连。后面「判断本机端口为什么不通」一节全靠这个区别。

验证方法

# 查看 TCP 监听端口及所属进程
$ sudo ss -lntp

预期输出：
State   Recv-Q  Send-Q   Local Address:Port   Peer Address:Port  Process
LISTEN  0       4096     127.0.0.53:53        0.0.0.0:*          users:(("systemd-resolve",pid=512,fd=14))
LISTEN  0       4096     0.0.0.0:22           0.0.0.0:*          users:(("sshd",pid=701,fd=3))
LISTEN  0       151      127.0.0.1:3306       0.0.0.0:*          users:(("mysqld",pid=1204,fd=28))

上面输出能直接读出三条信息：本机 DNS 由 systemd-resolved 监听在 127.0.0.53；SSH 对全网开放（0.0.0.0:22）；MySQL 只监听 127.0.0.1，外部连不上是设计如此，不是故障。

常见问题

现象	根因	解决
ss -lntp 不加 sudo 看不到进程名	-p 需要权限读取其他用户的进程信息	加 sudo
找不到 netstat	新系统默认不装 net-tools	一律改用 ss，参数几乎一一对应
服务明明起了，ss 里却搜不到	端口号记错了、服务其实没在监听，或监听在别的地址/端口上	先不筛选，直接 ss -lntp 全量看一遍再核对（ss -t 本身就同时列出 IPv4 与 IPv6 监听）

连通性测试：ping / traceroute / curl

是什么

确认了本机 IP 和监听状态后，就该测试「路通不通」。ping 测最基本的可达性，traceroute/mtr 看路径上断在哪一跳，curl 直接测 HTTP 服务（Web 排错的终极大招），wget 用来下载文件顺带验证网络。

怎么做

# ping 4 次就停（-c 指定次数，不加会一直 ping 下去）
$ ping -c 4 223.5.5.5
# 查看路由路径，每一跳到达哪个路由器
$ traceroute 223.5.5.5
# mtr = ping + traceroute 合体，实时刷新每跳丢包率，更好用
$ mtr 223.5.5.5
# 只看 HTTP 响应头：状态码 200 说明服务正常
$ curl -I http://example.com
# 显示详细过程：DNS 解析、TCP 连接、TLS 握手、请求响应全流程
$ curl -v https://example.com
# 下载文件，顺带验证网络与 DNS 都正常
$ wget https://example.com/file.tar.gz

traceroute 和 mtr 在 Ubuntu 最小安装里默认没有，需要安装：

# 安装路由追踪工具
$ sudo apt install traceroute mtr-tiny

参数说明

• ping -c 4：务必加 -c。裸 ping 会永远执行下去，新手常以为终端卡死。Ctrl+C 可随时中断。
• curl -I：-I（大写 i）表示只要响应头（HEAD 请求）。看状态码就够了：200 正常、404 路径错、502 后端挂了、connection refused 端口没开。
• curl -v：verbose 模式。当 -I 显示结果异常时，用 -v 看卡在了哪一步：卡在 DNS 说明解析问题，卡在 TCP connect 说明端口不通，卡在 TLS handshake 多半是证书或时间问题。
• mtr 比 traceroute 强在持续统计：单次 traceroute 某一跳超时可能只是路由器不响应 ping，不代表断；mtr 跑一分钟看丢包率才可信。

验证方法

# 测试到公网 DNS 的连通性
$ ping -c 4 223.5.5.5
# 只看响应头判断 HTTP 服务是否正常
$ curl -I http://example.com

预期输出：
PING 223.5.5.5 (223.5.5.5) 56(84) bytes of data.
64 bytes from 223.5.5.5: icmp_seq=1 ttl=118 time=8.32 ms
64 bytes from 223.5.5.5: icmp_seq=2 ttl=118 time=8.11 ms
64 bytes from 223.5.5.5: icmp_seq=3 ttl=118 time=8.25 ms
64 bytes from 223.5.5.5: icmp_seq=4 ttl=118 time=8.19 ms

--- 223.5.5.5 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8

ping 的 0% packet loss 说明链路健康；curl 返回 HTTP/1.1 200 OK 说明服务正常。

常见问题

现象	根因	解决
ping 域名失败，ping IP 成功	DNS 问题	跳到本章「DNS 解析」一节
curl 报 Connection refused	目标端口没有服务在监听	去 4 层排查第 5 步：ss -lntp 看服务是否监听
curl 卡在 TLS 握手后无响应	服务器时间错误导致证书校验失败	timedatectl 检查时间，见本章时间同步一节

判断本机端口为什么不通（重点）

是什么

这是排错实战中出现率最高的场景：你从自己电脑 curl http://<服务器IP>:8080 连不上，但服务明明装了。原因只有三种可能，本节教你用两条命令把三种情况彻底区分开，不再靠猜。

怎么做

先在服务器本机上测试（这一步必须在服务器上做，不要在自己电脑上）：

# 测试本机 8080 端口是否有服务在响应
$ curl localhost:8080
# 用 netcat 精确测试端口连通性（-z 只扫端口不发数据，-v 显示过程）
$ nc -zv 127.0.0.1 8080
# 关键一步：看服务到底监听在哪个地址上
$ sudo ss -lntp | grep 8080

nc（netcat）在最小安装里同样需要安装：

# 安装 netcat
$ sudo apt install netcat-openbsd

三种情况的对照表（先在服务器本机测，再在自己电脑测，对比结果）：

服务器本机 curl localhost	自己电脑 curl <服务器IP>	ss -lntp 监听地址	结论
不通	不通	搜不到 8080	服务没起：去查服务状态和日志
通	不通	127.0.0.1:8080	只监听了本机回环：改服务配置绑到 0.0.0.0
通	不通	0.0.0.0:8080	防火墙/安全组拦截：查 ufw 和云安全组

参数说明

• nc -zv：-z 是 zero-I/O 模式，只探测端口开不开，不发送应用数据；-v 把结果打印出来。成功时输出 succeeded!，失败输出 refused 或超时。
• 为什么只监听 127.0.0.1 会连不上：127.0.0.1 是「本机回环」地址，只有服务器自己能访问。很多服务（MySQL、Redis）出于安全默认只听 127.0.0.1，这是故意的保护机制，改成 0.0.0.0 之前必须想清楚是否要暴露给全网。
• 为什么 0.0.0.0 还连不上：数据包到得了服务器，但被防火墙（ufw）或云平台安全组丢弃。云服务器还要特别注意控制台里的安全组，它独立于系统内的 ufw。

验证方法

# 在服务器本机验证端口是否开放，并确认监听地址
$ nc -zv 127.0.0.1 8080
$ sudo ss -lntp | grep 8080

预期输出：
Connection to 127.0.0.1 8080 port [tcp/http-alt] succeeded!
LISTEN  0  511  0.0.0.0:8080  0.0.0.0:*  users:(("myapp",pid=2301,fd=6))

nc 返回 succeeded、ss 显示监听在 0.0.0.0:8080，对应对照表第三行：如果外部仍连不上，就去查 ufw 和云安全组。

常见问题

现象	根因	解决
nc 报 Connection refused	端口上没有进程监听	ss -lntp 确认服务是否启动、端口是否写对
本机通、外部不通、ss 显示 0.0.0.0	ufw 或云安全组未放行	sudo ufw status 查看；云控制台检查安全组规则
外部偶尔能连上偶尔超时	安全组只放行了部分来源 IP	检查安全组授权对象是否包含你的出口 IP

DNS 解析

是什么

域名（如 example.com）和 IP 地址（如 93.184.216.34）之间的翻译工作由 DNS 完成。Ubuntu 22.04 用 systemd-resolved 服务统一管理 DNS：应用程序的解析请求先交给它，它再转发给真正的上游 DNS 服务器。理解这个架构，才能解释本节那个著名的坑。

怎么做

# 安装 DNS 诊断工具（dig 和 nslookup 都在这个包里）
$ sudo apt install dnsutils
# 用 dig 查询域名对应的 IP（推荐，输出信息全）
$ dig example.com
# nslookup 更简单直观，适合快速确认
$ nslookup example.com
# 查看 systemd-resolved 的整体状态：当前用的哪个上游 DNS
$ resolvectl status
# 查看真实的 DNS 配置文件（注意它是个软链接）
$ cat /etc/resolv.conf

[!WARNING] 不要直接编辑 /etc/resolv.conf 来「永久改 DNS」。 Ubuntu 22.04 上这个文件由 systemd-resolved 管理，是软链接，你的修改会在重启、systemd-resolved 重载或 DHCP 续租时被静默覆盖回去。要持久修改 DNS，正确做法是改 netplan 的 nameservers（见本章静态 IP 一节）或 resolvectl dns 网卡名 <DNS-IP>（临时生效）。

参数说明

• dig 输出重点看两处：ANSWER SECTION 里的解析结果，和末尾 Query time（解析耗时）。status: NXDOMAIN 表示域名不存在，status: SERVFAIL 多为上游 DNS 故障。
• /etc/resolv.conf 里的 nameserver 127.0.0.53 就是 systemd-resolved 的本机代理地址，它不是真正的 DNS 服务器，真正的上游用 resolvectl status 查看。
• 常用公共 DNS：阿里 223.5.5.5、腾讯 119.29.29.29、谷歌 8.8.8.8（国内不稳）。

验证方法

# 验证 DNS 解析是否正常
$ dig example.com

预期输出：
; <<>> DiG 9.18.12 <<>> example.com
;; ANSWER SECTION:
example.com.    86400   IN  A   93.184.216.34

;; Query time: 25 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; status: NOERROR

SERVER: 127.0.0.53 证明请求走了 systemd-resolved，NOERROR + ANSWER 记录说明解析成功。

常见问题

现象	根因	解决
改了 resolv.conf 过一会又变回去	systemd-resolved 覆盖了手改内容	改 netplan 的 nameservers 后 sudo netplan apply
dig 报 SERVFAIL 或超时	上游 DNS 不可用	resolvectl status 看上游；临时换 resolvectl dns ens33 223.5.5.5
域名解析到内网假 IP	运营商 DNS 劫持	换可信公共 DNS（223.5.5.5 / 119.29.29.29）

主机名与 /etc/hosts

是什么

主机名是机器的「名字」（如 web-01），日志、提示符、集群里互相识别都用它。/etc/hosts 则是一张本地手工解析表：系统查域名时先查它，查不到才去问 DNS。这个优先级是理解很多诡异地名问题的关键。

怎么做

# 查看当前主机名与系统信息
$ hostnamectl
# 设置新主机名（把 <新主机名> 换成你想要的，如 web-01）
$ sudo hostnamectl set-hostname <新主机名>
# 编辑本地解析表，给新主机名配上 127.0.1.1，避免 sudo 报「无法解析主机」
$ sudo nano /etc/hosts

/etc/hosts 的典型内容：

127.0.0.1   localhost
127.0.1.1   web-01
192.168.1.20  db-01.internal

设置完主机名后，务必同步修改 /etc/hosts 里的 127.0.1.1 那行，否则每次执行 sudo 都会慢一下并报 sudo: unable to resolve host。

参数说明

• 127.0.1.1 是 Debian/Ubuntu 系的习惯用法：给本机主机名一个回环地址，与 127.0.0.1（localhost）区分开。
• 解析优先级：/etc/hosts > DNS。所以把 192.168.1.20 db-01.internal 写进 hosts 后，即使没有内网 DNS，ping db-01.internal 也能通。内网机器少时，用 hosts 管理互相访问是最简单的方案。
• 主机名命名建议：小写字母、数字、连字符，带上用途和编号（web-01、db-01），多台服务器时日志里一眼可辨。

验证方法

# 确认主机名已生效，并验证 hosts 本地解析（不走 DNS，立即返回）
$ hostnamectl
$ ping -c 2 web-01

预期输出：
 Static hostname: web-01
       Icon name: computer-vm
 Operating System: Ubuntu 22.04.5 LTS
PING web-01 (127.0.1.1) 56(84) bytes of data.
64 bytes from web-01 (127.0.1.1): icmp_seq=1 ttl=64 time=0.021 ms

常见问题

现象	根因	解决
改完主机名，sudo 报 unable to resolve host	/etc/hosts 里没有新主机名的记录	把 127.0.1.1 <新主机名> 加进 /etc/hosts
提示符还显示旧主机名	当前 shell 是改之前开的	重新登录或执行 bash 刷新
域名指向了意料之外的 IP	/etc/hosts 里有历史残留记录	grep 域名 /etc/hosts 检查并删除过期条目

静态 IP 配置（netplan）

是什么

Ubuntu Server 从 17.10 起用 netplan 管理网络配置：你写 YAML 描述「想要什么网络」，netplan 把它翻译给底层的 systemd-networkd 执行。配置文件在 /etc/netplan/ 目录下，Server ISO 安装的机器默认是 00-installer-config.yaml；云服务器（cloud-init 镜像）上常见的则是 /etc/netplan/50-cloud-init.yaml，由 cloud-init 生成，改前先 ls /etc/netplan/ 看清自己机器上是哪个。DHCP 是「自动获取 IP」，静态 IP 是「手动指定固定地址」——服务器通常必须用静态 IP，否则重启后 IP 一变，所有人都连不上它了。

怎么做

先看清现状：

# 查看当前 netplan 配置（DHCP 模式长这样）
$ cat /etc/netplan/00-installer-config.yaml

network:
  version: 2
  renderer: networkd
  ethernets:
    ens33:
      dhcp4: true

改成静态 IP 的完整写法（按你的实际环境替换地址、网卡名和网关）：

network:
  version: 2
  renderer: networkd
  ethernets:
    ens33:
      dhcp4: false
      addresses:
        - 192.168.1.10/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses: [223.5.5.5, 119.29.29.29]

# 应用配置（立即生效）
$ sudo netplan apply
# 更稳妥的方式：90 秒内不确认则自动回滚，适合改远程服务器
$ sudo netplan try

[!WARNING] YAML 对缩进极其敏感。 缩进必须用空格（不能有 Tab），同一层级的缩进格数必须一致。一个空格的差错都会导致 netplan apply 直接报错或配置不生效。改完可先用 sudo netplan --debug apply 看详细报错。

[!WARNING] 修改远程服务器的 IP 配置前，必须先想好回退方案，否则改错一步就永久失联，SSH 再也连不上，只能靠云控制台的 VNC/串口登录进去救。动手前确认三件事：① 新 IP、网关、掩码与所在网络完全匹配（最好先在本地虚拟机演练一遍）；② 备份原文件 sudo cp /etc/netplan/00-installer-config.yaml /etc/netplan/00-installer-config.yaml.bak；③ 优先用 sudo netplan try——它会应用新配置并等待你确认，你不敲确认键就自动回滚旧配置，是远程改 IP 的救命机制。云服务器失联时的最后手段是控制台里的 VNC 登录。

参数说明

字段	含义	注意
addresses: 192.168.1.10/24	IP + CIDR 掩码，/24 等价于 255.255.255.0	掩码写错会导致连不通网段
routes: to: default / via:	默认网关	老写法 gateway4: 已废弃，新配置用 routes
nameservers: addresses:	DNS 服务器列表	持久改 DNS 的正确位置，见 DNS 一节的 WARNING
dhcp4: false	关闭 IPv4 自动获取	静态 IP 的前提；静态地址必须避开 DHCP 分配范围，防止 IP 冲突

验证方法

# 确认新 IP、网关、DNS 都已生效
$ ip -br a && ip r
$ resolvectl status ens33

预期输出：
lo               UNKNOWN        127.0.0.1/8 ::1/128
ens33            UP             192.168.1.10/24
default via 192.168.1.1 dev ens33
Link 2 (ens33)
    DNS Servers: 223.5.5.5 119.29.29.29

常见问题

现象	根因	解决
netplan apply 报 YAML 语法错误	缩进用了 Tab 或层级错位	全部改空格，对照本节示例逐行核对缩进
改完 netplan 后 SSH 失联	IP/网关写错	云控制台 VNC 登录，还原 .bak 备份后 sudo netplan apply
静态 IP 生效但上不了外网	网关或 DNS 没配对	ip r 查 default 路由，resolvectl status 查 DNS

RHEL / Rocky / AlmaLinux 9 对照

Ubuntu (netplan)	RHEL (NetworkManager/nmcli)	说明
配置文件 /etc/netplan/*.yaml	nmcli con mod 命令或 /etc/NetworkManager/system-connections/*.nmconnection	RHEL 没有 netplan，配置方式完全不同
sudo netplan apply	nmcli con up ens160 或 nmcli dev reapply ens160	应用配置
sudo netplan try	无直接等价；可用 nmcli + 保留旧会话防失联	RHEL 远程改 IP 前同样要备好 VNC 退路
YAML 里写 nameservers	nmcli con mod ens160 ipv4.dns "223.5.5.5"	持久改 DNS

时间同步

是什么

服务器时间不准不是小事，它会直接弄坏服务：

• HTTPS 证书校验依赖时间：证书有生效/过期时间，系统时间偏差过大（比如差几年），浏览器和 curl 会直接报证书错误，服务之间互相调用全部失败。
• 日志时间戳失去意义：排查问题时你要按时间对齐多台机器的日志，时间不准就无法定位故障顺序。
• cron 定时任务会错乱：任务在错误的时间执行或不执行。
• 分布式锁与令牌：很多鉴权机制（JWT 过期校验、分布式锁租期）都基于时间戳，多机时间不一致会造成灵异故障。

所以每台服务器装完系统的第一件事之一，就是配置自动时间同步。Ubuntu 22.04 的标准方案是 timedatectl（查看/设置时区）+ chrony（持续校准时间）。

怎么做

# 先看当前时间、时区、是否已开启 NTP 同步
$ timedatectl
# 设置时区为上海（北京时间，UTC+8）
$ sudo timedatectl set-timezone Asia/Shanghai
# 安装 chrony（Ubuntu 22.04 也可用系统自带的 systemd-timesyncd，chrony 精度与可控性更好）
$ sudo apt install chrony
# 启动并设置开机自启
$ sudo systemctl enable --now chrony

国内服务器建议把 chrony 的上游换成国内 NTP 源，编辑 /etc/chrony/chrony.conf，把默认 pool 行替换为：

pool ntp.aliyun.com iburst
pool ntp.tencent.com iburst

# 修改配置后重启服务
$ sudo systemctl restart chrony

参数说明

• timedatectl 输出里最关键的两行：Time zone（应为 Asia/Shanghai）和 System clock synchronized: yes（表示已同步成功）。
• chrony 配置里的 iburst 表示启动时先快速连续发几个探测包，加快首次同步速度。
• 日志时区的两种口径：要么所有服务器统一用 UTC（日志记 UTC、展示时再换算），要么统一用本地时区（如本章演示的 Asia/Shanghai，日志时间戳即北京时间）。两种都可行，关键是团队统一一种口径即可，不要混用；否则对日志时会把 09:00 和 01:00 当成两件事。
• chrony 与 systemd-timesyncd 二选一即可，同时开两个会互相抢时钟。

验证方法

# 确认时区与同步状态；再查看 chrony 的上游时间源
$ timedatectl
$ chronyc sources

预期输出：
               Local time: Tue 2026-09-29 10:30:12 CST
           Universal time: Tue 2026-09-29 02:30:12 UTC
                 Time zone: Asia/Shanghai (CST, +0800)
System clock synchronized: yes
       NTP service: active
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* 203.107.6.88                  2   6   377    45    +12us[ +15us] +/- 18ms
^+ 42.192.0.10                   2   6   377    44    -28us[ -25us] +/- 24ms

System clock synchronized: yes 表示已同步成功；chronyc sources 里 ^* 标记的行是当前正在使用的时间源，Reach 达到 377 表示通信稳定，^? 则表示该源不可达。

常见问题

现象	根因	解决
curl 报证书错误但证书没过期	系统时间偏差过大	timedatectl 检查时间，配置 chrony 同步
chronyc sources 全是 ^?	防火墙拦了 NTP（UDP 123）或上游不可达	放行出站 UDP 123；换国内 NTP 源
双系统/克隆出来的虚拟机时间漂移大	虚拟机时钟与宿主机不同步	装 chrony 后执行 sudo chronyc makestep 强制立即校准

本章命令速查

命令	作用
ip a	查看所有网卡详细地址
ip -br a	简洁视图：网卡名、状态、IP 一行看清
ip r	查看路由表与默认网关
sudo ss -lntp	查看 TCP 监听端口及所属进程
ss -s	socket 数量汇总统计
sudo ss -tnp | grep ESTAB	查看已建立的连接
ping -c 4 <IP>	测试连通性，4 次后自动停止
traceroute <IP>	查看到目标经过的每一跳
mtr <IP>	实时统计每跳丢包率（ping+traceroute）
curl -I <URL>	只看 HTTP 响应头，快速判断服务状态
curl -v <URL>	显示完整请求过程，定位卡在哪一步
nc -zv <IP> <端口>	精确测试某端口是否开放
dig <域名>	查询 DNS 解析结果与耗时
resolvectl status	查看 systemd-resolved 与上游 DNS
sudo hostnamectl set-hostname <名>	设置主机名
sudo netplan try	应用 netplan 配置，不确认自动回滚
sudo netplan apply	应用 netplan 配置（立即生效）
timedatectl	查看时间、时区、同步状态
sudo timedatectl set-timezone Asia/Shanghai	设置时区为北京时间
chronyc sources	查看 chrony 上游时间源状态

相关章节

• 00 前言与阅读约定
• 16 防火墙
• 18 SSH 加固
• 40 systemd 服务管理
• 91 版本速查表

📄 16 防火墙与网络安全 16-firewall.md✓ 标记已学

---

title: 16 防火墙与网络安全 updated: 2026-09 applies-to: Ubuntu 22.04 LTS

服务器一旦有公网 IP，从上线第一分钟起就会有扫描器试探 22、3306、6379 这些常见端口。防火墙就是你和它们之间的门。

[!NOTE] 本章版本号截至 2026 年 9 月。版本信息的唯一权威来源是 版本速查表，冲突时以速查表为准。

新手最常见的误解是：以为「配了 ufw 放行 8080」就等于「外网能访问 8080」。实际上请求要到达服务，必须连续通过三层关卡：

   客户端请求
        │
        ▼
  ┌───────────────────────────────┐
  │ 第 1 层 云安全组（云控制台）    │ 被挡：Connection timed out
  ├───────────────────────────────┤ 放行 ↓
  │ 第 2 层 主机防火墙 ufw         │ 被挡：timed out
  ├───────────────────────────────┤ 放行 ↓
  │ 第 3 层 进程监听地址           │ 被挡：Connection refused
  │ 0.0.0.0:8080 对外             │
  │ 127.0.0.1:8080 只本机         │
  └───────────────────────────────┘
        │ 放行
        ▼
     服务响应

[!IMPORTANT] 三层是「与」的关系，不是「或」。 三层全通才能连上，任一层挡住都不行。

---

三层模型与端口排查顺序

是什么

层	在哪配置	谁负责	典型拦截表现
云安全组	云厂商控制台	云平台，流量到网卡前就过滤	Connection timed out
主机防火墙	服务器内 ufw / firewalld	你自己，内核 netfilter 过滤	Connection timed out
进程监听地址	应用配置（bind / listen）	应用程序自己	Connection refused

理解这个模型的价值：「端口不通」不再是玄学，而是一个可穷举的清单。绝大多数「明明开了防火墙还是访问不了」属于三种之一：安全组没开（包根本没进机房）、ufw 已启用但没放行该端口、程序只监听了 127.0.0.1。

怎么做

[!IMPORTANT] 端口不通时严格按以下 4 步执行，每步排除一类原因。没走完 4 步之前不要改任何配置。

# 1. 进程是否真的在监听？注意地址是 127.0.0.1 还是 0.0.0.0
$ sudo ss -lntp | grep 8080

# 2. 本机自测，确认服务本身能响应
$ curl localhost:8080

# 3. 主机防火墙是否放行
$ sudo ufw status

# 4. 云安全组是否放行 —— 登录云控制台查看，服务器内查不到

步骤 1	步骤 2	步骤 3	结论
无输出	—	—	进程没起，先查服务（40）
127.0.0.1	通	任意	监听地址不对，改绑 0.0.0.0
0.0.0.0	不通	任意	服务本身有问题，看应用日志
0.0.0.0	通	未放行	补 sudo ufw allow 8080
0.0.0.0	通	已放行	去查云安全组，九成问题在这

参数说明

参数	全称	作用
-l	listening	只显示监听中的套接字
-n	numeric	不解析域名和服务名（否则显示 http 而非 80）
-t	tcp	只看 TCP（看 UDP 换成 -u）
-p	process	显示进程名和 PID（需 sudo）

验证方法

$ sudo ss -lntp | grep 8080

预期输出（监听所有网卡，上两层放行后外网可达）：

LISTEN 0  511  0.0.0.0:8080  0.0.0.0:*  users:(("java",pid=1234,fd=8))

预期输出（只监听回环，外网必然不通）：

LISTEN 0  511  127.0.0.1:8080  0.0.0.0:*  users:(("java",pid=1234,fd=8))

常见问题

现象	根因	解决
防火墙全开，外网还是不通	进程只监听 127.0.0.1	改应用配置绑 0.0.0.0，或用 Nginx 反代
本机 curl 通、外网不通	安全组或 ufw 没放行	按 1 → 2 层顺序查
ping 得通但端口不通	安全组只放了 ICMP	控制台补业务端口规则

---

ufw 状态查看与启用

是什么

ufw（Uncomplicated Firewall）是 Ubuntu 自带的防火墙工具，本质是一个「写 iptables/nftables 规则的前端」，把复杂语法简化成 ufw allow 80 这样一句话。Ubuntu 22.04 上默认安装但未启用（inactive），即不拦截任何流量。

怎么做

# 查看状态（未启用时显示 inactive）
$ sudo ufw status

# 详细状态：额外显示默认策略和日志开关
$ sudo ufw status verbose

# 带编号显示，删除规则时要用编号
$ sudo ufw status numbered

[!WARNING] 启用 ufw 前必须先放行 SSH，否则你会把自己永久锁在服务器外面。 这是云服务器第一号事故。 补救思路：登录云控制台，用 VNC / WebShell / 串口终端（各家叫法不同）进入服务器 —— 这个通道不走 22 端口，进去后执行 sudo ufw allow 22 或 sudo ufw disable 即可恢复。 所以开新机器时，先确认控制台 VNC 能登录，再动防火墙。

# 第一步：放行 SSH（推荐后者，更语义化）
$ sudo ufw allow 22
$ sudo ufw allow OpenSSH

# 或只放行来自固定 IP 的 SSH（更安全）
$ sudo ufw allow from <你的IP> to any port 22

# 第二步：确认 22 已在规则里，再启用（重启后依然生效）
$ sudo ufw status
$ sudo ufw enable

参数说明

命令	作用
ufw status	查看规则与激活状态
ufw status verbose	增加显示默认策略、日志级别
ufw status numbered	给规则编号，供 ufw delete <编号> 使用
ufw enable / disable	启用 / 停用（规则保留，只是不生效）
ufw reload	重新加载规则，不断开现有连接

验证方法

$ sudo ufw status verbose

预期输出：

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)

To                         Action      From
--                         ------      ----
22                         ALLOW IN    Anywhere
22 (v6)                    ALLOW IN    Anywhere (v6)

注意 sudo ufw allow 22 的规则显示为 22（不带协议后缀）——它同时放行 TCP 和 UDP 两个协议的 22 端口。显示成 22/tcp 的是 sudo ufw allow OpenSSH 或 sudo ufw allow 22/tcp 这类写法的输出，只放行 TCP。

常见问题

现象	根因	解决
ufw enable 后 SSH 断线连不回	没先放行 22	云控制台 VNC 登录，sudo ufw allow 22
Status: inactive 但以为在保护	从未执行 enable	先放行 SSH 再 enable
重启后规则没了	只加规则没 enable	sudo ufw enable 写入开机自启

---

ufw 规则：放行、拒绝与删除

是什么

规则描述「允许/拒绝什么样的流量进来」，通常包含目标端口 + 协议 + 来源地址三部分。

怎么做

# 放行 HTTP / HTTPS
$ sudo ufw allow 80
$ sudo ufw allow 443

# 只放行 TCP（推荐，Web 服务不需要 UDP）
$ sudo ufw allow 8080/tcp

# 放行端口范围
$ sudo ufw allow 6000:6010/tcp

# 只允许指定来源 IP 访问 22（SSH 强烈推荐）
$ sudo ufw allow from <你的IP> to any port 22

# 只允许内网网段访问数据库
$ sudo ufw allow from 10.0.0.0/8 to any port 3306

# 显式拒绝某端口 / 封某个 IP
$ sudo ufw deny 3306
$ sudo ufw deny from 203.0.113.66

删除规则：

# 方式一：按内容删除（写法必须与添加时完全一致）
$ sudo ufw delete allow 80

# 方式二：先编号，再按编号删（推荐，不会匹配错）
$ sudo ufw status numbered
$ sudo ufw delete 3

[!NOTE] 规则有先后顺序，先匹配的先生效。 前面已有 deny，后面再加 allow 也不会生效 —— 这就是「删除规则后仍不通」的真正原因：冲突的 deny 还在前面。

参数说明

写法	含义
allow 80	放行 80，TCP + UDP 都放行
allow 80/tcp	只放行 TCP，更精确
allow 6000:6010/tcp	放行 6000～6010 共 11 个 TCP 端口
allow from <IP>	只允许该来源，其余按默认策略处理
deny	显式拒绝并记日志，优先级高于默认策略

验证方法

$ sudo ufw status numbered

预期输出：

Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    Anywhere
[ 2] 80/tcp                     ALLOW IN    Anywhere
[ 3] 8080/tcp                   ALLOW IN    Anywhere
[ 4] 6000:6010/tcp              ALLOW IN    Anywhere
[ 5] 3306                       DENY IN     Anywhere

常见问题

现象	根因	解决
加了 allow 仍不通	前面有更优先的 deny	status numbered 看顺序，删掉冲突的 deny
加了 allow 仍不通，规则没错	Docker 直接写 iptables，绕过 ufw	见下方 WARNING
delete allow 80 说规则不存在	添加时写的是 80/tcp，删除没带协议	用编号删
允许了来源 IP，同事还是连不上	同事出口 IP 与配置的不同（NAT/多线路）	curl ifconfig.me 确认真实出口 IP

[!WARNING] Docker 会绕过 ufw。 容器启动时 Docker 直接往 iptables 插入自己的规则，优先级高于 ufw 生成的链，结果 deny 了某端口、容器的 -p 8080:8080 映射依然能被外网访问。 规避：容器只映射到 127.0.0.1（-p 127.0.0.1:8080:8080）再用 Nginx 反代，不要依赖 ufw 管容器端口，详见 30-docker.md。

---

ufw 应用配置、默认策略与日志

是什么

应用配置：部分软件（Nginx、OpenSSH）安装时会放一个描述文件声明自己用了哪些端口，于是可以写 ufw allow 'Nginx Full' 而不必记端口。 默认策略：对所有「未被任何规则匹配」的流量采取什么动作。

怎么做

# 列出可用的应用配置，并查看某个配置包含哪些端口
$ sudo ufw app list
$ sudo ufw app info 'Nginx Full'

# 按应用名放行（名字带空格必须加引号）
$ sudo ufw allow 'Nginx Full'

# 默认策略：拒绝所有入站，允许所有出站
$ sudo ufw default deny incoming
$ sudo ufw default allow outgoing

# 日志开关，日志写在 /var/log/ufw.log
$ sudo ufw logging on

# 重置：清空所有规则并停用
$ sudo ufw reset

[!IMPORTANT] 先 default deny incoming，再逐条 allow 需要的端口（白名单思路）。反过来「默认放行、只 deny 少数」迟早会漏。改默认策略前同样要确认 22 已放行。

[!WARNING] sudo ufw reset 会清空所有规则并把防火墙设为 inactive，包括放行 SSH 的那条。执行后不重新放行 22 就 enable，等于把服务器锁在门外。只在规则彻底搞乱时用。

参数说明

命令	作用
ufw app list	列出所有应用配置名
ufw app info <名字>	显示该配置包含的端口与协议
ufw default deny incoming	未匹配的入站流量全部丢弃
ufw default allow outgoing	服务器主动访问外网不受限
ufw logging on	开启日志，记录在 /var/log/ufw.log

deny incoming + allow outgoing 是推荐组合：别人进不来，我出去不受限。

验证方法

$ sudo tail -n 5 /var/log/ufw.log

预期输出（关键字段：[UFW BLOCK] 表示拦截，SRC 来源 IP，DPT 目标端口）：

Sep 29 10:22:31 ubuntu kernel: [UFW BLOCK] IN=eth0 OUT= SRC=203.0.113.66 DST=10.0.0.5 PROTO=TCP SPT=42122 DPT=3306 SYN URGP=0

常见问题

现象	根因	解决
allow 'Nginx Full' 说找不到配置	没装 Nginx	sudo apt install nginx 后再看
应用配置的端口与实际不符	改过 Nginx 监听端口	直接用 ufw allow <端口>/tcp
服务器访问外网失败（如 apt update）	出站被改成了 deny	sudo ufw default allow outgoing

---

firewalld（RHEL 系）

是什么

RHEL / Rocky / AlmaLinux 9 默认用 firewalld，它比 ufw 多一层抽象：zone（区域）。zone 是一组规则的集合，网卡或来源 IP 被划到哪个 zone 就套用哪套规则（常用 public、internal、trusted、drop）。它还支持用 service（服务名） 代替端口号。

怎么做

# 查看运行状态与当前 zone 的完整规则
$ sudo firewall-cmd --state
$ sudo firewall-cmd --list-all

# 按服务名放行
$ sudo firewall-cmd --permanent --add-service=http
$ sudo firewall-cmd --reload

# 按端口放行
$ sudo firewall-cmd --permanent --add-port=8080/tcp
$ sudo firewall-cmd --reload

# 把当前运行时规则一次性保存为永久规则
$ sudo firewall-cmd --runtime-to-permanent

# 移除规则
$ sudo firewall-cmd --permanent --remove-service=http
$ sudo firewall-cmd --reload

[!WARNING] --permanent 不加 --reload 不生效 —— firewalld 第一号坑：加了 --permanent 只写进配置文件，内核里的规则没变，服务依然访问不了。 反过来不加 --permanent 的规则立即生效，但重启后消失。生产环境统一写 --permanent + --reload。

[!WARNING] --panic-on 会立刻切断所有网络连接（包括你当前的 SSH），只在被入侵需紧急隔离时使用。误执行后只能靠云控制台 VNC 执行 sudo firewall-cmd --panic-off 恢复。

参数说明

参数	作用
--list-all	显示默认 zone 的全部规则
--add-service=http	按服务名放行（服务定义已含端口）
--add-port=8080/tcp	按端口号放行
--permanent	写入配置文件永久生效，需配合 --reload
--reload	重载配置让永久规则生效，不中断现有连接
--runtime-to-permanent	反向操作：把运行时规则保存到配置文件

验证方法

$ sudo firewall-cmd --list-all

预期输出：

public (active)
  target: default
  interfaces: eth0
  services: ssh http https
  ports: 8080/tcp
  forward: yes

常见问题

现象	根因	解决
加了 --permanent 规则但端口不通	没执行 --reload	sudo firewall-cmd --reload
重启后规则失效	加规则时漏了 --permanent	重新加，或用 --runtime-to-permanent
同时装 ufw 和 firewalld，规则打架	两个工具都写 iptables	只保留一个

RHEL / Rocky / AlmaLinux 9 对照

Ubuntu (apt/ufw)	RHEL (dnf/firewalld)	说明
sudo apt install ufw	sudo dnf install firewalld	安装防火墙工具
sudo ufw enable	sudo systemctl enable --now firewalld	启用并开机自启
sudo ufw status	sudo firewall-cmd --list-all	查看当前规则
sudo ufw allow 80	sudo firewall-cmd --permanent --add-port=80/tcp && sudo firewall-cmd --reload	放行端口
sudo ufw allow 'Nginx Full'	sudo firewall-cmd --permanent --add-service=http	按应用/服务放行
sudo ufw allow from <IP> to any port 22	sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="<IP>" port port="22" protocol="tcp" accept'	限定来源 IP
sudo ufw delete allow 80	sudo firewall-cmd --permanent --remove-port=80/tcp	删除规则
sudo ufw reload	sudo firewall-cmd --reload	重载生效
sudo tail /var/log/ufw.log	sudo journalctl -u firewalld	查看防火墙日志

---

iptables 与 nftables 基础

是什么

iptables 是内核 netfilter 的用户态配置工具，规则按「表」和「链」组织：

• 四表：filter（放行/丢弃，默认表）、nat（地址转换，Docker 端口映射用它）、mangle（改 TOS/TTL 等标记）、raw（连接跟踪前处理）
• 五链：PREROUTING（刚进网卡还没定去向）、INPUT（目标是本机）、FORWARD（转发给别人）、OUTPUT（本机发出）、POSTROUTING（即将离开网卡）

[!NOTE] Ubuntu 22.04 底层已是 nftables，iptables 命令只是兼容层（iptables-nft），把 iptables 语法翻译成 nftables 规则。日常用 ufw 即可，不必深究。

怎么做

# 查看 filter 表规则（-n 不解析域名，-v 显示命中计数）
$ sudo iptables -L -n -v

# 查看 nat 表（Docker 的规则都在这）
$ sudo iptables -t nat -L -n -v

# 查看 nftables 原生规则集
$ sudo nft list ruleset

[!WARNING] 不要混用多种防火墙工具。 ufw、firewalld、裸 iptables 本质都在改同一套内核规则，同时用会互相覆盖，行为完全不可预测。一台机器只保留一种：Ubuntu 用 ufw，RHEL 用 firewalld。

[!WARNING] iptables -F（清空所有规则）是危险命令。 默认策略为 DROP 时执行它，你会立刻失去 SSH 连接；即使用 ufw，-F 也会清掉 ufw 生成的链，让防火墙形同虚设。排错不要图省事执行 -F。

参数说明

参数	作用
-L	list，列出规则
-n	numeric，不解析域名（不加会很慢）
-v	verbose，显示命中数、接口
-t nat	指定表名，默认 filter
nft list ruleset	查看 nftables 原生规则集

验证方法

$ sudo iptables -L -n -v | head -n 5

预期输出（policy DROP + 一串 ufw- 链，正是 ufw 生成规则的证据，说明两者操作的是同一套机制）：

Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
  120  7200 ufw-before-logging-input  0    --  *      *       0.0.0.0/0            0.0.0.0/0
  120  7200 ufw-before-input  0    --  *      *       0.0.0.0/0            0.0.0.0/0

常见问题

现象	根因	解决
输出里有大量 ufw- 链	ufw 已启用，规则由它生成	正常，统一用 ufw 管理
手动加的规则重启后没了	只存在于内存，未持久化	改用 ufw 或装 iptables-persistent
容器端口 ufw 拦不住	Docker 直接写 iptables，优先级更高	容器映射改用 127.0.0.1:

---

端口开放的安全建议

是什么

防火墙不是「开了就安全」，核心原则是最小暴露面：能不对外开放的端口一律不开。

怎么做

应该对外开放的：22（最好限来源 IP）、80（跳转 HTTPS）、443。 绝对不要对 0.0.0.0 开放的（弱认证或无认证，扫描器首要目标）：3306 MySQL、5432 PostgreSQL、27017 MongoDB、6379 Redis、9200 Elasticsearch、11211 Memcached。

# 一（推荐）：应用只监听 127.0.0.1，端口在公网上物理不可见
$ sudo ss -lntp | grep 3306

# 二：只对内网网段放行
$ sudo ufw allow from 10.0.0.0/8 to any port 3306

# 三：走 SSH 隧道，本地连 localhost:3306 即可
$ ssh -L 3306:127.0.0.1:3306 <用户名>@<服务器IP>

[!TIP] 能不放行就不放行，能限 IP 就限 IP。 每多开一个公网端口，就多一个需要长期打补丁的攻击面。临时远程访问数据库用 SSH 隧道，用完即关。

参数说明

写法	含义
0.0.0.0	所有网卡，等同于对公网开放
127.0.0.1	只有本机，外网无法连接
10.0.0.0/8	内网网段（CIDR 写法）
ssh -L	本地端口转发，见 18

验证方法

$ sudo ss -lntp | grep -E '3306|5432|27017|6379'

预期输出（安全，只监听本机）：

LISTEN 0  151  127.0.0.1:3306  0.0.0.0:*  users:(("mysqld",pid=900,fd=21))

预期输出（危险，对公网开放，需立刻整改）：

LISTEN 0  151  0.0.0.0:3306  0.0.0.0:*  users:(("mysqld",pid=900,fd=21))

常见问题

现象	根因	解决
数据库本机连得上，应用服务器连不上	监听在 127.0.0.1	改监听内网地址 + ufw 限内网 IP，或走 SSH 隧道
日志里大量 DPT=3306 的 BLOCK	扫描器在爆破数据库	正常，说明防火墙拦住了；确认端口没对公网开
改了 bind 配置但 ss 结果没变	没重启服务	sudo systemctl restart <服务>

---

本章命令速查

命令	作用
sudo ss -lntp | grep <端口>	查看端口是否被监听、监听在哪个地址
curl localhost:<端口>	本机自测，排除网络因素
sudo ufw status / verbose / numbered	查看状态 / 含默认策略 / 带编号
sudo ufw allow 22	放行 SSH（启用 ufw 前必做）
sudo ufw allow 80 / 443 / 8080/tcp	放行 HTTP / HTTPS / 指定 TCP 端口
sudo ufw allow 6000:6010/tcp	放行端口范围
sudo ufw allow from <IP> to any port 22	只允许指定 IP 访问 SSH
sudo ufw deny <端口>	显式拒绝某端口
sudo ufw delete <编号>	按编号删除规则（推荐）
sudo ufw enable / disable / reload	启用 / 停用 / 重载
sudo ufw default deny incoming	默认拒绝入站（白名单思路）
sudo ufw app list / allow 'Nginx Full'	列出应用配置 / 按应用放行
sudo ufw logging on + sudo tail -f /var/log/ufw.log	开启并查看拦截日志
sudo ufw reset	清空所有规则并停用（危险）
sudo iptables -L -n -v	查看底层规则（排错用）
sudo firewall-cmd --list-all	RHEL：查看 firewalld 规则
sudo firewall-cmd --permanent --add-port=8080/tcp && sudo firewall-cmd --reload	RHEL：永久放行端口并生效

---

相关章节

• 15 网络配置 —— ip / ss 详解、DNS、netplan
• 17 包管理 —— 安装 ufw、fail2ban 等工具
• 18 SSH 远程登录与安全加固 —— 改 SSH 端口后必须同步改防火墙
• 29 Nginx —— 只开 80/443，其余全部反代
• 30 Docker —— Docker 绕过 ufw 的原理与规避