1. 为什么我要整理这份 CentOS 命令合集先别急着复制命令我说说我整理这份东西的初衷。干运维这行久了你会发现一个尴尬的现实不是每条命令你都记得住也不是每次遇到问题你都有时间去翻手册。尤其是 CentOS作为服务器领域最常见的发行版之一生产环境一跑就是好几年、甚至上十年。很多命令你可能上个月才用过下个月遇到类似场景又卡壳了。最要命的是网上搜出来的教程质量参差不齐抄错一条参数轻则白折腾半小时重则把生产数据搞坏。我整理这份合集不是要把 man 手册搬过来而是想把日常排查问题、配置系统、管理服务时最高频、最实用、最容易踩坑的命令挑出来配上实际场景和注意事项。适合谁看刚入门的运维新手、从其他发行版转过来的开发者还有那些需要偶尔登服务器操作一下的测试、后端同学都能从中拿到可以直接用的东西。需要先说明一下环境背景。这篇合集以 CentOS 7 和 CentOS Stream 为主部分命令在 CentOS 6 上基本不适用比如 systemctl文章里我会单独标注。如果你还在用 CentOS 6建议尽早规划迁移毕竟它的生命周期早就结束了留在生产环境里是给自己埋雷。2. 系统信息与硬件状态速查2.1 先弄清楚你面对的是什么样的系统登录服务器之后干的第一件事往往不是敲命令而是要确认系统版本、内核、位数和架构。很多时候你以为自己在 CentOS 7 上结果发现其实跑的是 CentOS Stream 9命令参数可能就不太一样了。# 查看发行版信息最常用的方式 cat /etc/os-release # 查看内核版本 uname -r # 查看完整的内核信息、主机名、架构 uname -a # 查看主机名 hostnamectl我一般开机后第一件事就是敲cat /etc/os-release而不是cat /etc/redhat-release。前者是所有 systemd 系统通用的后者只有 Red Hat 系才有万一你哪天登录的是一台 Ubuntu 机器cat /etc/redhat-release会直接报文件不存在。hostnamectl这个命令也值得多说一句它不仅能看主机名还能一次性展示系统的启动时间、操作系统版本、内核版本、架构是了解一台服务器“底细”的最快路径。至于uname -r别看它输出就短内核版本里藏的信息不少。比如3.10.0-1160.el7.x86_643.10是内核主版本el7代表 Red Hat Enterprise Linux 7 的内核x86_64是架构。遇到内核相关问题时这两个命令就是排查的基础。2.2 CPU、内存、磁盘、负载一眼看穿服务器卡了首先怀疑什么CPU、内存、磁盘。这三个维度每个都有对应的速查命令。# CPU 详细型号、核数、架构 lscpu # 内存使用情况-h 参数转换为人类可读格式 free -h # 磁盘分区及使用率 df -hT # 块设备列表看硬盘和分区结构 lsblklscpu最值得关注的是CPU(s)和Core(s) per socket这两个字段。前者是逻辑 CPU 总数含超线程后者是每颗物理 CPU 的核心数。判断一台机器到底有几个物理 CPU不能只看CPU(s)要看Socket(s)。free -h输出里的available字段要重点看。老版本 CentOS 7 的free命令里没有这个字段只有free和buff/cache新手经常会误认为 used 就是真实占用。实际上buff/cache里的内存是可以被系统在需要时回收的真实可用内存应该看available。现在 CentOS 7.5 以上基本都有这个字段了看到 used 很高先别慌看一眼 available 再下结论。df -hT里面T参数是关键。它会把文件系统类型也列出来比如 xfs、ext4、tmpfs。注意在 CentOS 7 里根分区默认用的往往是 xfs如果你的脚本或工具只支持 ext4那就要提前规划。# 系统最近1分钟、5分钟、15分钟的平均负载 uptime # 实时的 CPU 和内存使用情况按 CPU 使用率排序 top -c # 更友好的系统监控界面支持鼠标操作 htop # 需要单独安装uptime输出的负载值很多人误以为和 Windows 的 CPU 使用率是同一个概念。其实不是。负载值代表的是处于可运行状态和不可中断状态的进程平均数量。判断系统负载是否过高要结合 CPU 核数来看负载值长期高于核数说明系统确实忙不过来如果负载很高但 CPU 使用率不高那可能是磁盘 I/O 或锁等待导致的得进一步排查。2.3 硬件信息排查的几个冷门但有用的命令# 查看物理内存条数量和容量 dmidecode -t memory # 查看 CPU 厂商和主频 dmidecode -t processor | grep -E Socket|Version|Max Speed # 查看硬盘型号和序列号 hdparm -i /dev/sda # 可能需要先安装 hdparmdmidecode在物理机上非常有用但在云服务器上基本读不到真实硬件信息因为虚拟化层不会把底层的 DMI 数据透传给你。如果你用的是某云服务器执行这个命令可能会看到一堆虚拟硬件信息这是正常现象不必紧张。3. 文件与目录操作的肌肉记忆3.1 这些基础命令请形成条件反射文件操作是 Linux 使用频率最高的命令。如果你在 CentOS 上做开发或运维以下命令应该达到不用过脑子的水平。# 列出文件 ls -l # 长格式含权限、属主、大小、修改时间 ls -la # 显示隐藏文件 ls -ltr # 按修改时间倒序排列最老的在最上面 # 切换目录 cd /var/log # 绝对路径 cd ../ # 上一级目录 cd - # 返回上次所在目录这个技巧很实用 # 查找当前目录下的内容 pwdls -ltr是个被严重低估的命令。日志目录里文件特别多时按时间倒序排列能让你一眼看到最近修改的文件排查问题时非常顺手。cd -这个命令在长路径之间来回切换时特别高效不用重新输入一串路径了。3.2 find 命令的几个高频用法find是文件查找的核心工具但参数太多容易记混。我只说几个生产环境里最常用的组合。# 按文件名查找 find /etc -name *.conf # 按文件类型查找 find / -type f -name nginx.conf find / -type d -name logs # 按修改时间查找mtime 表示修改时间-1 表示1天内 find /var/log -mtime -1 # 按文件大小查找100M 表示超过100MB find / -size 100M # 找到后直接执行命令比如找出大文件并删除 find /tmp -type f -name *.log -mtime 7 -exec rm -f {} \;新人在写find ... -exec rm -f {} \;的时候最容易犯的错是漏掉末尾的分号或者中间的空格。{}表示前面 find 找到的每一个文件\;里的反斜杠是对分号转义因为分号在 shell 里是命令分隔符。建议在使用-exec rm之前先用不带-exec的 find 把列出来的文件过目一遍确认没有误伤再执行。3.3 打包与压缩tar 一条命令搞定CentOS 7 上tar 是默认的归档工具。ZIP 也能用但在服务器上tar 几乎是一统天下的因为它能保留文件权限、属主、时间戳等元数据。# 打包并压缩gzip最常用 tar -czvf backup.tar.gz /etc/nginx/ # 解压 tar -xzvf backup.tar.gz # 只查看压缩包里的内容不解压 tar -tzvf backup.tar.gz # 打包时排除某个目录 tar -czvf backup.tar.gz --exclude/etc/nginx/cache /etc/nginx/-c创建、-x解压、-z使用 gzip、-v显示过程、-f指定文件。这套参数几乎可以视为“固定搭配”。--exclude参数是生产里特别实用的打包之前如果忘了排除大目录可能导致压缩包体积失控甚至撑爆磁盘。最近几年我在做一些增量备份时也会用tar配合--newer参数只打包最近修改过的文件tar -czvf incremental-$(date %F).tar.gz --newer /var/lib/mysql/data这个思路在手动做增量备份时很好用但注意它只是按文件修改时间过滤不处理删除操作真做备份方案还是得靠专业的备份工具。3.4 rsync 同步文件比 cp 高级不少rsync 在服务器之间同步文件是标配。它的最大优势是增量传输只传变化的部分比 cp 然后不断重复全量复制高效得多。# 本地同步 rsync -avh /source /destination # 远程同步推送到远程服务器 rsync -avz /local/path/ userremote:/remote/path/ # 从远程拉取 rsync -avz userremote:/remote/path/ /local/path/ # 删除目标端多出来的文件保持两端完全一致 rsync -av --delete /source/ userremote:/remote/path/-a是归档模式保留权限、时间戳等属性-v是显示过程-h是输出人类可读的大小-z是传输时压缩。还有一个细节路径后面的斜杠source/与source是有区别的。rsync -av /source /destination会在目标端创建destination/source目录而rsync -av /source/ /destination会把 source 目录下的内容直接同步到 destination 里。这个区别非常容易踩坑建议自己动手试一次感受一下差别。3.5 软链接和硬链接# 创建软链接相当于 Windows 里的快捷方式 ln -s /usr/local/nginx/conf/nginx.conf /etc/nginx.conf # 创建硬链接两个文件名指向同一个文件内容 ln /usr/local/nginx/logs/access.log /var/log/nginx-access.log软链接在生产环境里用得非常广泛比如把程序配置文件链接到/etc下统一管理。软链接的特点是可以跨文件系统指向的路径如果失效链接就断了。硬链接不跨文件系统只是同一个 inode 的另一个名字删除任何一个链接都不会影响文件实际数据。判断软链接是否失效最简单的办法是ls -l看到一个nginx.conf - /usr/local/nginx/conf/nginx.conf后面带了个红色的路径说明目标不存在了。4. 用户与权限管理不再两眼一抹黑4.1 创建用户的正确姿势CentOS 上创建用户请养成使用useradd的习惯而不是直接编辑/etc/passwd。而且最好带上参数。# 创建用户并创建家目录指定默认 shell 为 bash useradd -m -s /bin/bash webapp # 创建用户并指定附加组这里是加入 wheel 组获得 sudo 权限 useradd -m -s /bin/bash -G wheel deploy # 直接指定用户 ID 创建 useradd -m -u 1500 -s /bin/bash webapp-m参数是强制创建家目录-s是指定登录 shell。不加-m时有些系统配置下不会自动创建/home/用户名登录进去可能发现自己在一个很奇怪的目录下找不着家。-G wheel是将用户加入 wheel 组在 CentOS 上wheel 组默认拥有 sudo 权限。创建完用户后记得第一时间设置密码passwd webapp该命令会提示你输入两次密码。CentOS 默认的密码策略要求长度至少 8 位包含多个字符类型生产环境建议用强密码或密钥登录。4.2 修改用户信息、删除用户# 修改用户 shell usermod -s /bin/zsh webapp # 修改用户注释信息可以记录姓名、工号等 usermod -c Webapp Deploy User webapp # 锁定用户禁止登录 usermod -L webapp # 解锁用户 usermod -U webapp # 删除用户-r 会同时删除家目录和邮件池 userdel -r webappusermod -L这个功能很实用员工离职或临时冻结账号时不需要删用户锁定即可。锁定后用户无法登录但文件权限和属主关系依然保留后续如果别人接手还可以解锁并重新分配。4.3 权限管理chmod 和 chown权限这块我不做过多理论铺垫直接说实际场景。# 修改文件权限数字法 chmod 644 /etc/nginx.conf # 644 属主可读写组用户和属主外用户只读 chmod 755 /usr/local/web/start.sh # 755 属主可读写执行组用户和属主外用户可读执行 # 递归修改目录权限 chmod -R 755 /usr/local/web # 修改文件属主和属组 chown -R nginx:nginx /usr/local/web # 仅修改属组 chown :nginx /usr/local/web数字权限的规则r4w2x1。7421 表示读写执行642 表示读写541 表示读和执行。这三个数字依次代表属主、属组、其他人。实际工作中把属主改成nginx:nginx、然后把目录设为755、文件设为644是部署静态网站最常见的组合。注意别动不动就chmod 777这在论坛里到处都有人推荐但生产环境里 777 意味着任何用户都能改你的文件如果目录里还有脚本、配置就可能被植入恶意代码。4.4 sudo 权限怎么给CentOS 7 上把用户加入 wheel 组就有 sudo 权限了这个方案在大部分场景下足够了。但有时候你只想给某个用户开放几条特定命令的权限比如只允许重启 nginx、只允许查看日志那就得编辑 sudoers。visudo注意不要直接vim /etc/sudoers因为 sudoers 文件的语法要求很严格写错了会导致 sudo 命令全部失效。visudo会在保存前做语法检查可以有效避免这个问题。追加一行允许 webapp 用户无密码执行 systemctl 重启 nginxwebapp ALL(ALL) NOPASSWD:/usr/bin/systemctl restart nginx这种细粒度授权在生产环境里推荐结合监控审计需求使用减少管理员的直接操作也让操作留痕。5. 服务与进程管理的实操套路5.1 systemctl 时代的服务管理CentOS 7 开始全面采用 systemd管理服务的核心命令从 service 变成了 systemctl。两者的思维模式不太一样systemctl 不仅管理服务还能管理挂载点、socket、设备、定时器等。# 启动、停止、重启服务 systemctl start nginx systemctl stop nginx systemctl restart nginx # 设置开机自启 systemctl enable nginx systemctl disable nginx # 查看服务状态含最近日志 systemctl status nginx # 重新加载配置文件不重启服务 systemctl reload nginx # 查看所有开机自启的服务 systemctl list-unit-files --typeservice --stateenabled # 查看运行失败的服务 systemctl list-units --failedsystemctl status nginx是我排查服务问题时第一个使用的命令。它能显示服务当前状态、主进程 PID、已启动时间、内存占用、最近的 journal 日志。很多新手看到 mn 状态不知道什么意思这里说一下 systemctl 里的状态含义状态说明active (running)服务正常运行中active (exited)服务已启动并正常退出比如一次性任务active (waiting)运行中但正在等待事件inactive (dead)服务未运行failed启动失败或异常退出5.2 进程查看的三个层级服务出问题往往要下钻到进程层面。我的习惯是层层下钻先通过ps确认进程是否存在再用top看资源占用最后用ss查看端口监听。# 查看某个服务的进程 ps -ef | grep nginx # 按 CPU 占用从高到低排序前10个进程 ps aux --sort-%cpu | head -n 10 # 查看进程树 pstree -p # 查看进程的实时资源占用 top -p 1234ps -ef | grep nginx是最常见的查看进程方式但需要注意grep本身也会出现在结果里。如果不想看到 grep 自己可以这样写ps -ef | grep [n]ginx中括号[n]ginx会规避 grep 自身的匹配。这是一个经典的小技巧。top进入交互界面后常用按键1展开每个 CPU 的使用情况M按内存占用排序P按 CPU 占用排序c显示完整命令行z界面显示彩色q退出5.3 kill 的优雅与暴力# 正常终止进程发送 SIGTERM 信号 kill 1234 # 强制终止进程发送 SIGKILL 信号 kill -9 1234 # 按进程名终止 pkill -f nginx # 重启 nginx 配置优雅重载 kill -HUP $(cat /var/run/nginx.pid)生产环境优先用kill不带 -9让进程自己处理退出逻辑。kill -9是最后手段会直接切断进程可能导致数据丢失或文件损坏。kill -HUP对 nginx 这类服务来说会重新加载配置而不中断服务比restart要平滑得多。终止进程前建议先执行ps -ef确认进程号没变化避免误杀。现在很多工具命令输出里自带了 pid 信息比如ss -tlnp可以直接看到端口对应的进程和 PID。6. 网络排查命令的实战用法6.1 网络连通性三步排查服务器无法访问我用得最多的套路就是先 ping 测试基本连通性再 curl 测试服务端口最后 ss 看监听状态。# 测试连通性-c 指定次数-W 指定超时秒数 ping -c 4 -W 3 8.8.8.8 # 测试某个端口是否开放 nc -vz remote-server 443 # 查看本机所有监听的端口和对应进程 ss -tlnpping 不通不一定代表网络故障很多云环境默认禁 ping。nc -vz直接测端口能绕过 ping 的干扰。ss -tlnp是现在推荐使用的端口查看命令老的netstat在 CentOS 7 里虽然还能找到但默认可能没有安装功能上来讲ss效率更高。ss -tlnp的几个参数含义-t只显示 TCP 连接-l只显示监听状态的端口-n不解析服务名直接显示端口数字-p显示对应的进程信息6.2 curl 测试 HTTP 接口排查 web 服务问题curl 是我的第一工具。# 看响应头 curl -I http://127.0.0.1 # 看完整请求与响应头 curl -v http://127.0.0.1 # 模拟 POST 请求 curl -X POST -d nametest http://127.0.0.1/api # 指定超时时间 curl --connect-timeout 5 -m 10 http://127.0.0.1 # 下载文件到本地并保留原始文件名 curl -o test.zip http://127.0.0.1/test.zipcurl -v输出里的打头的行是发送的请求头打头的行是收到的响应头。每次排查接口问题都建议加上-v能省很多时间。--connect-timeout和-m总超时这两个参数在脚本里一定要加否则 curl 默认没有超时时间一旦网络异常脚本会挂在那里一直等下去。6.3 防火墙管理的两种工具CentOS 7 默认防火墙是 firewalld但在云环境里很多人习惯直接关掉防火墙用安全组代替。这不是不行但一旦你在本地测试环境或物理机上还是得用这套命令。# 查看防火墙状态 systemctl status firewalld # 开放端口 firewall-cmd --zonepublic --add-port8080/tcp --permanent # 重载防火墙配置 firewall-cmd --reload # 查看已开放的端口 firewall-cmd --zonepublic --list-ports # 临时关闭防火墙当前生效重启后恢复 systemctl stop firewalld # 永久禁用防火墙 systemctl disable firewalld重点说一下--permanent这个参数。不加 permanent只是临时生效重启系统后端口又关闭了加了 permanent需要执行firewall-cmd --reload才会真正生效。很多新人加了 permanent 但忘了 reload导致端口似乎开放了又好像没有很迷惑。还有一种情况是服务器上同时存在 iptables 和 firewalldCentOS 7 里 iptables 服务是独立的默认不启动。如果你发现改了 firewalld 的规则不生效先确认是不是 iptables service 也在运行。6.4 抓包工具 tcpdump 的最简用法排查网络连接被重置Reset、连接超时、协议异常等深层次网络问题时tcpdump 直接抓包能看到真相。# 抓取本机 eth0 网卡上访问 80 端口的数据包 tcpdump -i eth0 port 80 # 抓取主机之间通信的数据包 tcpdump -i eth0 host 192.168.1.10 # 抓取并保存为文件后续用 Wireshark 分析 tcpdump -i eth0 -w /tmp/cap.pcap port 443 # 读取抓包文件 tcpdump -r /tmp/cap.pcap抓包打了两行就可以按CtrlC停止。不用过多追求把所有包都抓下来用条件过滤好、抓到关键交互即可。tcpdump 输出中S是 SYN 包F是 FIN 包R是 Reset 包。看到大量R包基本可以断定连接被对端重置了这种问题再往下查就得看应用层和内核参数。7. 日志、磁盘占用与日常清理7.1 journald 日志的查看与清理CentOS 7 所有服务的标准输出默认都会写入 systemd journal 日志。用 journalctl 查看。同时它也是排查服务崩溃、启动失败的利器。# 查看某个服务的所有日志 journalctl -u nginx # 加上 -f 参数实时查看最新日志 journalctl -u nginx -f # 查看最近10分钟内的系统日志 journalctl --since 10 minutes ago # 查看今天的日志 journalctl --since today # 查看上次启动过程的日志 journalctl -b -1 # 查看磁盘占用情况 journalctl --disk-usage服务器跑了很久之后journal 日志会非常占磁盘默认存储上限是系统盘可用空间的 10%。一旦日志量大根分区可能被撑满。定期清理的方法# 删除超过 7 天的日志 journalctl --vacuum-time7d # 限制日志总大小不超过 200MB journalctl --vacuum-size200M也可以直接修改配置限制 journal 日志上限# 编辑 /etc/systemd/journald.conf设置 SystemMaxUse500M改完之后执行systemctl restart systemd-journald。生产环境里我一般会把 SystemMaxUse 设到 300M-1G具体看机器磁盘和日志量。7.2 磁盘占用的排查思路日志文件、应用缓存、临时文件这三样是最常见的磁盘杀手。定位磁盘占用大户的路径一般是# 查看根分区的使用率 df -h / # 查看一级目录下的大目录 du -sh /* 2/dev/null | sort -rh | head -n 10 # 进入大目录再逐层往下看 du -sh /var/* 2/dev/null | sort -rh | head -n 10 # 找出大于 100MB 的文件 find / -xdev -type f -size 100M -exec ls -lh {} \; | sort -k5 -rh | head -n 20du -sh是统计目录大小的核心命令。/ *表示根目录下的所有一级目录2/dev/null把权限不足的报错丢弃。sort -rh按人类可读大小倒序排列看一下那个目录最大就顺着往下查。还有一个容易被忽略的大文件藏身地已删除但仍被进程占用的文件。Linux 下文件被删除后如果有进程还持有它的文件句柄磁盘空间不会释放。排查方法# 查看已删除但被进程占用的文件 lsof L1看到输出里有(deleted)标记的条目时解决办法是重启对应的进程或者在 /proc/PID/fd 下删除对应的文件句柄链接一般不推荐直接操作。这个知识点在清理磁盘空间时非常实用很多人 du 发现磁盘没什么大文件但 df 显示使用率很高就是这种情况在作怪。7.3 一些顺手提高效率的命令日常操作里我还喜欢用 alias 简化一些命令比如在.bashrc里加上alias llls -l --colorauto alias lals -la alias grepgrep --colorauto alias untartar -xzvfalias只是临时会话有效要永久生效得写进/etc/bashrc或~/.bashrc然后用source或重新登录生效。历史命令这块也有技巧。history可以查看之前执行过的命令!100可以执行历史中第 100 条命令!!执行上一条命令!$展开上一条命令的最后一个参数。这些在重复执行相近命令时能省不少输入时间。另外CtrlR可以反向搜索历史命令输入几个关键字就能快速找到之前敲过的完整命令。这是我最常用的一个快捷操作强烈建议养成习惯。8. 遇到报错时务必先分清问题层级最后聊点经验上的东西。很多人在服务器上报错后的第一反应是去复读报错文本但排查效率最高的方式是先把问题归入正确的层级是网络层、系统层还是服务层网络层有问题先看连通性。ping网关、nc -vz测端口、tcpdump抓包都能帮你确认是不是网络问题。系统层有问题先看资源。内存不够、磁盘满、句柄耗尽表现五花八门但最终原因往往是资源不够导致的连锁反应。free -h、df -h、ulimit -n这三个命令基本就能覆盖大部分资源类问题。服务层有问题先看日志。journalctl -u 服务名 -f看启动日志、错误日志比任何猜测都靠谱。我见过太多人看到一个报错第一反应是问别人或者百度其实只需要先按这三层定位一下花的时间不会超过两分钟但排查方向立刻明确效率能提升几倍。这份命令合集里我最想请你重点记住的就是ss -tlnp、journalctl -u、df -h、free -h和du -sh这几个查询命令它们是日常排查的基石也是所有进阶实战的基础。