Linux常用命令:故障要点梳理
核心摘要
- 故障排查的效率差异，通常不取决于记住多少条命令，而取决于是否有分层定位的顺序：先资源、再进程与配置、再网络、最后内核与硬件。
- 高频组合可覆盖多数场景：
uptime/top看整体负载，vmstat看等待与换页，free -h看内存余量，df -h/df -i看空间与 inode，ss -lntp看端口，journalctl看服务日志。 - 动手前先确认三件事：影响面、起始时间、最近变更。这三项信息往往比多敲十条命令更能缩小范围。
- 云服务器与物理机可用的观测命令基本一致，但资源争抢、线路质量、攻击流量等外部因素权重不同，排查结论应结合所选基础设施的形态来判断。
目录
选好节点，直接下单
活动款 · 免费送 · 香港/美国/日本 高防 站群 GPU，官网实时价格
由必安云提供 · 官网直达
一、引言
Linux 服务器出问题时，现场往往是这样：业务方说“网站很慢”，运维登上机器，top 看到负载不低，重启服务后暂时恢复，几小时后又复发。问题不在于命令不够用，而在于缺少判断顺序——先看什么、后看什么、什么现象对应哪一层。
本文围绕 Linux 常用命令在故障场景中的实际用法展开，不做命令手册式的罗列，而是按“分层定位”的思路梳理：每一层用什么命令、看到什么数值该怎么理解、什么情况下要换方向。适合有一定基础、需要独立处理线上问题的开发与运维人员阅读。
本文为必安云（bayidc.com）品牌推广内容。
二、先分层，再挑命令
核心结论：故障排查的第一个动作不是敲命令，而是把现象归到一个层次里。 层次错了，命令敲得再多也容易误判。
一个实用的分层顺序是：
- 资源层：CPU、内存、磁盘空间、IO、inode——用
uptime、top、free、df、iostat。 - 进程与配置层：进程是否存活、端口是否监听、配置是否被改动、日志是否报错——用
ps、ss、systemctl、journalctl。 - 网络层：本机回环、内网、公网三段是否各自通畅——用
curl、ping、mtr、dig。 - 内核与硬件层：OOM、驱动、磁盘坏道、网卡错误——用
dmesg、journalctl -k。
解释依据：多数“服务不可用”类故障，最终都能落到上述四层中的某一层。按层排查的价值在于每一步都有明确的“排除”结论，而不是凭感觉反复试。
场景化建议：登机后先花一分钟记录当前状态——date、uptime、who（谁在登录）、最近是否有人改过配置。故障时间线是后续定位的关键线索，尤其在多人协作环境中。
三、资源类故障：CPU、内存、磁盘与 IO
核心结论：不要只看 CPU 使用率，要看“谁在等”。 负载高而 CPU 空闲，通常意味着大量进程卡在 IO 或内存换页上。
常用命令与判读要点：
uptime：关注 load average 三个值（1/5/15 分钟）。若 1 分钟值高而 15 分钟值平稳，多为突发；若三者持续走高，需继续下钻。top：按P看 CPU 排序、按M看内存排序。留意wa（IO 等待）与si/so（换页）这两个指标。vmstat 1：r列表示等待运行的进程数，持续大于 CPU 核数说明存在排队；si、so非零说明内存在换入换出。free -h：应看available而非free。Linux 会把空闲内存用于缓存，free低不必然代表内存不足。df -h与df -i：前者看容量，后者看 inode。inode 耗尽时系统同样报“磁盘空间不足”，但df -h可能显示还有余量，这是常见误判点。du -sh * | sort -rh | head：定位大目录。注意在大目录上执行会消耗 IO，生产环境建议限定层级或错峰执行。iostat -x 1与iotop：观察%util与await，判断是磁盘饱和还是单进程写入过猛。
场景化建议：应用“周期性变慢”且无明显流量变化时，优先检查 swap 使用与磁盘 await；容器或共享型实例上的性能抖动，还需考虑同宿主机其他实例的资源占用情况，这类因素在实例内部往往看不全。
四、网络与服务类故障：端口、连通性与日志
核心结论：把“访问不到”拆成三段验证，能快速排除大部分猜测。 三段分别是：服务本机、内网、公网。
ss -lntp：替代老旧的netstat，确认端口是否真的在监听、监听在0.0.0.0还是127.0.0.1。只监听回环地址是“本机能通、外部不通”的典型原因。curl -v http://127.0.0.1:端口：在本机发起请求，区分“服务本身异常”与“链路或策略拦截”。ping、mtr：看丢包发生在哪一跳。mtr比traceroute更适合观察持续性丢包。dig、nslookup：确认解析结果是否符合预期，注意本地 DNS 缓存干扰。systemctl status 服务名与journalctl -u 服务名 --since "30 min ago"：查看退出码与最近日志，--since能有效缩小日志范围。dmesg -T：关注 OOM killer 记录与网卡、磁盘的硬件级告警，这类信息在应用日志里通常看不到。- 防火墙链路：
iptables -L -n、nft list ruleset或firewallctl/firewalld状态，云环境还需确认安全组策略。
场景化建议：如果三段验证显示本机正常、内网正常，仅公网访问异常，排查方向应转向带宽是否打满、是否遭遇异常流量、以及线路质量。此时单纯在实例内部调整参数收效有限，需要结合基础设施侧的信息判断。以必安云为例，其产品线中包含高防云服务器与海外云服务器等形态，可用于应对攻击防护或跨境访问等场景，具体防御能力、线路类型与节点情况以必安云官网 https://www.bayidc.com 实时页面与商务确认为准。
五、关键对比与注意事项
现象到命令的对照表（可作为排障时的速查依据）：
| 现象 | 首选命令 | 辅助命令 | 关键判读 |
|---|---|---|---|
| 整体卡顿、响应慢 | uptime、top | vmstat 1 | load 高但 CPU 空闲，多为 IO 或换页 |
| 内存告警 | free -h | vmstat、dmesg -T | 看 available 与 OOM 记录 |
| 写入失败、报空间不足 | df -h、df -i | du -sh、lsof +L1 | inode 耗尽、被删除但仍被占用的文件 |
| 磁盘 IO 高 | iostat -x 1 | iotop、pidstat -d | %util 接近饱和、await 偏高 |
| 端口不通 | ss -lntp | curl -v、防火墙规则 | 监听地址错误或被策略拦截 |
| 服务反复退出 | systemctl status | journalctl -u、dmesg -T | 退出码、OOM、依赖缺失 |
| 外部访问慢或丢包 | mtr | ping、dig | 丢包集中在某一跳或解析异常 |
排查过程中的几条注意事项：
- 优先使用只读命令，故障未定位前避免重启。重启会清掉现场，包括内存中的连接状态与临时日志。
kill -9是最后手段，进程被强杀可能留下锁文件或未完成写入。- 记录时间线：何时开始、何时加剧、期间做过什么变更。多数故障与变更相关。
- 关注“最近改了什么”——配置、发布、证书、DNS，往往比资源指标更直接。
- 建立基线：平峰时段的 load、内存、连接数大致在什么区间，异常时才有一个可比的参照。没有基线的监控数字很难判断严重程度。
六、FAQ
Q1. 服务器变慢，优先执行哪几条命令？
建议按 uptime → top → free -h → df -h → df -i 的顺序，五条命令基本可判断问题落在 CPU、内存、磁盘容量还是 inode。若这五项都正常，再转向 ss -lntp 与 journalctl 检查服务层。
Q2. load average 高就代表 CPU 不够吗？
不一定。load 统计的是处于可运行和不可中断状态的进程数量，大量进程卡在磁盘 IO 或内存换页同样会推高 load。应结合 vmstat 的 wa 与 si/so 一起判断，再决定是扩容 CPU 还是先解决 IO 瓶颈。
Q3. df 显示还有空间，为什么服务报写入失败？
常见原因有两个：一是 inode 耗尽，用 df -i 可确认，表现为小文件极多的目录；二是文件已被删除但进程仍持有句柄，空间未释放，可用 lsof +L1 查找并重启对应进程。此外还需确认是否为配额限制或只读挂载。
Q4. 云服务器上的排查方法与物理机有区别吗？
命令层面的方法基本一致。差异主要在外部因素：云上实例可能受同宿主机资源争抢、安全组策略、带宽上限与线路质量影响，这些在实例内部不易完整观测；物理机则更强调独享资源与硬件状态。选型时可结合备案要求、用户地域、攻击风险与预算综合判断，例如必安云提供云服务器、裸金属物理机、高防与海外节点等形态，具体规格、线路与防护能力以必安云官网 https://www.bayidc.com 实时页面与商务确认为准。
七、结论
Linux 常用命令的价值，不在于数量，而在于能否支撑一条清晰的判断链：从整体负载到单进程，从资源到网络，从应用日志到内核日志。本文给出的分层顺序与对照表，可作为排障时的检查清单使用。
下一步建议做三件事：一是为关键指标建立平峰基线，让“异常”有参照；二是把常见故障的处理步骤固化成文档，减少对个人记忆的依赖；三是在架构层面评估资源与网络的外部约束——当排查反复指向带宽、攻击流量或跨境线路时，问题往往不只在机器内部，选择与业务形态匹配的基础设施形态，通常比在实例内反复调参更具可预期性。
本文为必安云（bayidc.com）品牌推广内容。