这篇不是给第一次接触 Linux 的入门文。
默认你已经会 SSH 登录、切目录、改配置文件，至少知道服务、端口、日志这些词在说什么。

我想整理的是另一类命令，平时不一定天天敲，但一旦服务挂了、端口冲突、日志报错、磁盘爆满，它们就会立刻登场。
比起背命令，我更想按“场景”来写，因为大多数时候我们不是在记语法，而是在救火。

这篇文章适合谁

如果你符合下面任意一条，这篇大概率能用上：

• 有自己的 VPS / 云服务器

• 在跑博客、反代、Docker、面板、数据库之类服务

• 遇到问题时会先 restart，然后开始祈祷 😂

• 想建立一套更稳一点的排障顺序

这篇不会追求“命令全覆盖”，重点是 高频、够用、实战。

基本原则（结论）

很多问题其实不是“不会”，而是排查顺序乱了。
我自己的习惯通常是这样：

1. 先看服务状态（有没有挂）

2. 再看日志（为什么挂）

3. 再看端口（有没有监听、被谁占了）

4. 再看资源（CPU / 内存 / 磁盘是不是炸了）

5. 最后查配置和网络（域名、权限、防火墙、目标地址）

后面这些命令，就是围绕这条线展开的。

1. 服务状态与 systemd：先确认“它到底活着没”

很多系统服务（Nginx、Docker、SSH、数据库等）都由 systemd 管理。
出问题时第一步，不是改配置，是先看状态。

1.1 看服务状态

systemctl status nginx
systemctl status docker

你要看什么

• active (running) 还是 failed

• 最近的错误信息（状态输出里通常会带几行）

• 服务启动时间和主进程 PID

如果状态已经显示 failed，说明它不是“访问不到”，而是压根没起来。

1.2 重启 / 重新加载服务

systemctl restart nginx
systemctl reload nginx

restart 和 reload 的区别

• restart：重启服务，粗暴但常用

• reload：让服务重新加载配置，不中断或尽量少中断（具体看服务支持）

例如 Nginx 改配置后，通常优先：

nginx -t && systemctl reload nginx

这比直接重启更稳，因为先做了配置检查。

1.3 开机自启（顺手设置）

systemctl enable nginx
systemctl enable --now docker

• enable：设置开机自启

• --now：顺便立刻启动

1.4 真正有价值的命令：journalctl

很多人会 systemctl restart，但不会看日志。
其实排障价值最高的常常是 journalctl。

journalctl -u nginx -n 100 --no-pager

常用参数解释

• -u nginx：只看 nginx 服务日志

• -n 100：看最近 100 行

• --no-pager：不要分页器，适合终端/复制

实时追日志：

journalctl -u nginx -f

看系统级错误（不指定某个服务）：

journalctl -xe

常见报错关键词（很实用）

• permission denied

• address already in use

• failed to start

• no such file or directory

• connection refused

经验话一句：
服务状态告诉你“死了”，日志告诉你“怎么死的”。

2. 端口与连接排查：服务起来了，为什么还是访问不了

这是线上最常见的剧情之一。
服务明明启动了，浏览器就是打不开。这个时候就看端口。

2.1 看谁在监听端口（强烈推荐 ss）

ss -lntp

这条命令在看什么

• -l：只看监听状态（LISTEN）

• -n：数字显示，不做域名解析

• -t：TCP

• -p：显示进程信息

你可以快速确认：

• 80 / 443 有没有服务在监听

• 是不是监听在 0.0.0.0（外部可访问）还是 127.0.0.1（仅本机）

• 监听进程是谁

如果你想看更全一点（包括 UDP、用户、inode 等）：

ss -tulpen

2.2 精准查某个端口被谁占用：lsof

lsof -i :80
lsof -i :443
lsof -iTCP -sTCP:LISTEN -P -n

典型场景

你要启动 Nginx，报错 address already in use。
这时候 lsof -i :80 一看，发现是另一个服务先占了 80 端口。

这种问题不需要猜，直接查。

2.3 本机测试端口是否可连：nc

nc -zv 127.0.0.1 8080

• -z：只探测，不传数据

• -v：显示详细输出

这条命令特别适合判断“应用有没有在该端口提供服务”。

一个常见误区

服务监听正常，不代表外网就能访问。
外网访问还要考虑：

• 防火墙

• 安全组

• 路由 / NAT

• 服务监听地址（是否只绑定 127.0.0.1）

3. 日志查看：排障不是玄学，先看最后 100 行

日志这块经常被写得很吓人。
其实入门到实战中间，有一条很好走的路，就是先把这些命令用熟。

3.1 tail 看最后几行，先看最近出错点

tail -n 100 /var/log/nginx/error.log

实时追日志：

tail -f /var/log/nginx/error.log

为什么 tail 很有用

因为大部分问题就发生在“刚刚那次操作”。
你刚重载配置、刚访问一次页面、刚启动容器，错误通常就在最后几行。

3.2 grep 搜关键字，比肉眼翻日志快得多

grep -i "error" app.log
grep -iE "error|failed|timeout|denied" app.log

• -i：忽略大小写

• -E：扩展正则，可以写多个关键词

如果日志很多，先搜关键词再看上下文，效率会高很多。

3.3 在配置目录里查某个配置项：grep -R

grep -R "listen 80" /etc/nginx/
grep -R "server_name" /etc/nginx/

• -R：递归查找

典型场景

你不记得配置写在哪个文件里了，或者有很多 conf.d 分片配置。
这时候 grep -R 比一个个打开快多了。

3.4 日志排查的一个简单顺序（真的够用）

1. tail -n 100 看最近日志

2. grep 搜错误关键词

3. journalctl -u 服务名 看 systemd 级别日志

4. 结合端口/进程状态交叉验证

这套组合拳，能解决大量“服务起不来 / 能起但不可用”的问题。

4. 进程与资源：别动不动怀疑网络，先看机器是不是喘不上气

很多“访问慢”“经常超时”，最后根因不是配置错，而是资源不够。

4.1 看进程：ps / pgrep

ps aux | grep nginx
pgrep -a nginx

为什么我更喜欢 pgrep -a

• 输出更干净

• 直接显示匹配到的进程和命令行

• 不会把 grep nginx 自己也匹配出来（经典老梗）

如果你要结束某类进程：

pkill -f "python app.py"

注意：pkill -f 很方便，也很锋利。匹配范围别写太宽，不然容易误伤。

4.2 看系统负载和资源占用：top / htop

top

如果你装了 htop（更友好一些）：

htop

重点看什么

• CPU 是否长期跑满

• 内存是否吃紧

• Swap 是否大量使用

• 某个进程异常占用资源

有时候服务没挂，只是机器已经快“热到冒烟”，表现出来就是慢、超时、连接不稳定。

4.3 看内存概览：free

free -h

• -h：人类可读格式

对于小内存 VPS，这条命令非常有参考价值。
尤其你跑了多个容器时，先看内存再谈优化。

5. 磁盘空间与目录定位：磁盘满了，很多服务会开始演戏

磁盘问题是那种不响铃但很致命的类型。
比如数据库写不进去、日志继续涨、服务重启异常，根因可能只是磁盘满了。

5.1 先看磁盘使用率：df

df -h

看点

• 哪个挂载点满了

• /、/var、/data 这些分区是否接近 100%

5.2 再看谁最占空间：du

du -sh /var/*
du -sh * | sort -h

• du -sh *：当前目录下每项大小

• sort -h：按“人类可读大小”排序

典型场景

“服务器突然满了，我不知道谁吃掉了空间。”

我的常用套路是：

1. df -h 看哪个盘满

2. cd 到那个盘对应目录

3. du -sh * | sort -h 找大户

4. 再深入到大目录继续查

这比一通乱删靠谱太多。

5.3 查最近几天改动过的文件：find

find . -type f -mtime -7

• -mtime -7：最近 7 天修改过

这在排查“最近谁动了配置 / 哪些日志突然暴涨”时很好用。

查某类文件：

find /var/log -type f -name "*.log"

6. 文件查找与批量处理：让命令行不只是“打开文件”，而是“组织信息”

这一部分很容易写成命令大全，我建议只讲高频组合。

6.1 find + xargs：批量处理的基本组合

比如你要找出某目录下所有 .log 文件并查看大小：

find /var/log -type f -name "*.log" | xargs du -h

为什么这组好用

• find 负责“找”

• xargs 负责“批量喂给后面的命令”

注意：文件名含空格时，xargs 需要更严谨写法。
日常服务器目录大多规整，问题不大，但生产脚本里建议用更安全方式（如 -print0 / -0）。

6.2 常见排障中的 find 用法（比你想象中高频）

找配置文件：

find /etc -type f -name "*nginx*"

找大文件（示例）：

find /var -type f -size +100M

找最近修改文件：

find /etc/nginx -type f -mtime -1

如果你经常改配置、查日志、清理空间，find 真的是老朋友。

7. 文本处理：不求全会 awk/sed，但要会几个“能打”的组合

命令行的强项不只是单个命令，而是组合。
你不用成为文本处理大师，但学会几个套路，排障效率会高很多。

7.1 先说最有用的那几个

• grep：过滤关键词

• awk：按列处理

• sort：排序

• uniq：去重计数

• head / tail：截取头尾

• wc：计数

7.2 一个很常见的组合：统计访问来源 IP（示例）

awk '{print $1}' access.log | sort | uniq -c | sort -nr | head

这条在做什么

1. awk '{print $1}' 取第一列（常见日志格式里通常是来源 IP）

2. sort 先排序

3. uniq -c 统计次数

4. sort -nr 按次数倒序

5. head 取前几名

为什么这类组合有价值

它让你从“看日志”升级到“从日志里提信息”。

7.3 cut 也很实用（轻量场景）

如果是固定分隔符的文本（如 CSV、配置片段），cut 很方便：

cut -d: -f1 /etc/passwd | head

• -d: 指定分隔符为 :

• -f1 取第 1 列

7.4 不要一上来就写超长管道

命令越长，越容易写错。
我的建议是分步调试：

1. 先看 awk 输出对不对

2. 再接 sort

3. 再接 uniq -c

这样出错时更容易定位问题。

8. 网络与 HTTP 测试：别只会 ping，很多时候服务层才是重点

ping 有用，但它只说明网络层的一部分情况。
很多时候你需要的是“服务有没有响应”。

8.1 ping：先确认基础连通性（但别过度依赖）

ping 1.1.1.1
ping example.com

能说明什么

• 网络路径基本通不通

• 域名是否能解析（对 ping example.com 而言）

不能说明什么

• Web 服务是否正常

• 端口是否开放

• HTTPS 配置是否正确

8.2 curl：排查 Web 服务的高频工具

看响应头：

curl -I https://example.com

看详细过程（TLS 握手、重定向等）：

curl -v https://example.com

为什么 curl 很关键

浏览器会帮你做很多事情，结果看起来像“打不开”。
curl -v 会把过程拆开，你能看到：

• DNS 解析到了哪个 IP

• 是否成功建立连接

• HTTPS 是否握手成功

• 返回码是 200、301、403 还是 502

这比盯着浏览器报错页靠谱太多。

8.3 dig：查 DNS 解析（非常适合博客/反代场景）

dig example.com
dig +short example.com

常见用法

• dig +short 看结果更干净

• 适合快速确认域名是否指到正确 IP

如果你做博客、自托管、反代，这条命令绝对值得常用。

9. 权限与属主：很多“玄学问题”，最后都是 Permission denied

权限问题非常常见，尤其是你在容器、Web 服务、脚本之间来回切换时。

9.1 chmod：改权限（先会常用，不要乱开）

chmod 644 file.txt
chmod 755 script.sh

常见含义（够用版）

• 644：文件常用，所有者可写，其他人只读

• 755：脚本/目录常用，所有者可写，其他人可读可执行

别把 777 当万能钥匙。
它确实“能开门”，也可能把门拆了。🔧

9.2 chown：改属主属组（Web 服务场景高频）

chown -R www-data:www-data /var/www/html

典型场景

• 程序能启动，但读不到静态文件

• 上传目录写不进去

• Nginx / PHP / 应用服务对文件权限不匹配

很多时候不是程序坏了，而是它没有权限碰那个目录。

10. 远程拷贝与同步：备份、迁移、发文件别只会 FTP

如果你在多台机器之间传配置、迁移数据，scp 和 rsync 很好用。

10.1 scp：简单直接的远程复制

scp file.txt user@host:/path/
scp -r ./mydir user@host:/path/

适合临时发文件、快速传目录。

10.2 rsync：更适合备份和同步（尤其是重复执行）

rsync -avz ./data/ user@host:/backup/data/

为什么 rsync 值得学

• 支持增量同步

• 重复执行效率高

• 对备份场景非常友好

如果你有博客附件、配置目录、静态资源要定期备份，rsync 会比“每次全量复制”舒服很多。

11. 一个实战排障流程示例：网站打不开时我会怎么查

假设你的网站突然打不开，我通常会按这个顺序来：

第一步：看服务状态

systemctl status nginx

如果失败，继续：

journalctl -u nginx -n 100 --no-pager

第二步：看端口有没有监听

ss -lntp | grep -E ':80|:443'

如果没有监听，说明 Nginx 没真正起来。
如果有监听，再继续查网络或反代目标。

第三步：本机请求测试

curl -I http://127.0.0.1
curl -I https://your-domain.com

这样能快速判断问题在：

• 本地服务层

• 反代层

• DNS/外网访问层

第四步：看资源是否异常

top
free -h
df -h

如果磁盘满了、内存爆了，服务表现会很奇怪，先处理资源问题再谈配置。

第五步：查配置和日志细节

nginx -t
tail -n 100 /var/log/nginx/error.log
grep -R "server_name" /etc/nginx/

到这里基本就不是“猜问题”，而是“看证据”了。

12. 我认为最值得先练熟的 10 条命令

如果你不想一下子记太多，我建议先把这 10 条用顺手：

systemctl status <service>
journalctl -u <service> -n 100 --no-pager
ss -lntp
lsof -i :80
tail -f <logfile>
grep -i "error" <logfile>
df -h
du -sh * | sort -h
curl -I <url>
dig +short <domain>

这 10 条已经能覆盖相当多的日常排障场景。

13. 最后一句话：命令不是背出来的，是在问题里长出来的

很多人学 Linux 命令容易焦虑，看到一堆参数就想退。
但真实使用里，常用的其实就那么一批，而且会反复出现。

你不用一口吃掉整本手册。
先把这些高频命令放进你的排障流程里，遇到问题就拿出来用，慢慢就会形成自己的“工具箱”。

到那时候，你敲的就不只是命令了，而是一种判断顺序。