做服务器运维这些年我最怕听到的一句话不是“服务器挂了”而是电话那头补一句“你自己看吧我啥也没动”。半夜两点的机房告警周末的微信轰炸新手接手一台来历不明的服务器面对的往往是一个黑盒加一堆模棱两可的现象。但时间长了你会发现服务器故障和人体疾病一样大部分都是常见病、多发病来来回回就那么些套路。这篇文章我把这些年高频踩中的12种服务器基础故障整理成了一份排查清单每种都给出明确症状、判定方法和处理路径。刚入行的运维照着走一遍基本能解决八成问题兼职管服务器的开发和小团队负责人也能拿来当速查手册。1. 排错框架先行三层定位法和证据链思维1.1 三层定位法网络层、系统层、应用层排查服务器故障最大的坑不是现象多而是现象会骗人。比如“网站打不开”这个描述既可能是指网络不通、也可能是指DNS解析失败、还可能是Nginx进程死了、甚至可能是后端数据库连接数满了。如果你一上来就直接重启服务器问题可能暂时“消失”但根因还在过两天还会再犯。我把排查思路收敛为三层定位法先判断问题出在哪一层再决定要不要动手。下面是这三层分别关心什么定位层核心问题典型命令网络层链路通不通端口通不通ping、telnet、ip a、route、ss系统层资源够不够进程活没活top、free、df、ps、dmesg应用层服务本身是否正常工作curl、日志文件、服务状态顺序很重要。很多时候应用层报错根子却在系统层或网络层。比如MySQL报连接超时你先去看MySQL配置翻了半天发现是磁盘满了导致写入阻塞——这就是典型的层级判断错误。我的习惯是先确保网络层通再看系统层资源最后才进应用日志里抠细节。1.2 排错黄金步骤先取证后变更除了层级判断我还有个铁律排障过程中先收集证据再做变更。很多新手一看到服务挂了就立刻重启相当于警察没到现场就把尸体烧了根因永远查不出来。我通常遵循一条“排错六步”复现现象 → 收集日志/状态快照 → 提出假设 → 用最小代价验证 → 执行修复 → 观察验证。比如磁盘满这种问题你在df -h那一刻看到的数据就是关键证据。如果直接删文件释放空间空间是有了但你可能永远不知道是什么把磁盘写满的——下次它还会再满。正确的做法是先df -h和du -sh /*把现场拍下来定位到具体是哪个目录在膨胀再决定要清理还是要切割。这个习惯让我少踩了无数个“治标不治本”的坑。2. 网络与连接故障ping不通、SSH失败、端口假监听2.1 故障一服务器完全ping不通这是最经典的“服务器挂了”但原因往往非常低级大概率是线路问题而不是整机宕机。按链路顺序排查别跳步第一步看本机网络状态。登录服务器控制台云平台的控制台或者物理机的KVM/IPMI执行ip a看网卡有没有IP状态是不是UP。物理机还要去机房看网卡灯亮不亮虚拟化环境要看虚拟机网卡有没有被平台踢掉。很多“ping不通”其实只是网卡没起来或IP漂移了。第二步ping网关。ip route先看默认路由然后ping网关地址。网关通说明物理链路和二层转发没问题网关不通问题就出在这台机器到交换机之间可能是网线松动、交换机端口VLAN配错、或者网卡驱动挂了。第三步ping外网IP。网关通但外网不通大概率是路由或防火墙问题。查iptables -L -n的OUTPUT链、firewalld区域规则以及是否有策略路由把流量引到了错误方向。第四步最后再怀疑安全组。云服务器尤其要注意系统内部怎么查都通但外部ping不通八成是控制台安全组的入方向规则没放行ICMP。也别急着加规则先确认安全组所属的实例是不是这台机器。有次同事给一台新服务器配IP就是子网掩码抄错了一位结果本网段能通、跨网段全丢包。这种问题排查起来心累但按链路顺序走一遍十分钟内必然定位。2.2 故障二能ping通但SSH连不上能ping通说明网络层是通的问题收窄到了远程管理通道。SSH连不上要分三种情况处理千万不要混为一谈连接超时TCP层都没通。多半是防火墙丢弃了22端口包或者云安全组没放行22端口。先telnet IP 22试一下超时基本就是被防火墙拦了。连接被拒能到达服务器但端口没监听。systemctl status sshd看服务状态再用ss -tlnp | grep 22确认sshd到底有没有监听。被拒还有一个常见原因是ssh改了非标准端口你还在敲默认22。认证失败能连上但密码/密钥不对。这时候别再瞎试密码了直接看/var/log/secureCentOS系或/var/log/auth.logUbuntu系翻到最后几条日志是密码错还是公钥校验失败一目了然。还有一个特别容易踩的坑是host key冲突。重装系统后用SSH客户端连接同一台服务器会报REMOTE HOST IDENTIFICATION HAS CHANGED。这是客户端在保护你——防止中间人攻击。解法很简单编辑本地~/.ssh/known_hosts删掉对应IP的那一行重新连接即可。千万别图省事把整个known_hosts文件清空或者关掉StrictHostKeyChecking那是把大门锁拆了。顺便说一句用VSCode远程开发连服务器时如果改了SSH端口记得在~/.ssh/config里给这台主机定义一个别名和Port参数否则默认还是走22端口连不上是必然的。2.3 故障三端口明明在监听外部却访问不了这个故障我见得太多了尤其是刚部署完Web服务的新手最容易遇到。症状是你自己在服务器上curl http://127.0.0.1:8080一切正常但浏览器从外部访问就是打不开。用ss -tlnp查一下监听地址大概率能看到这样一行LISTEN 0 128 127.0.0.1:8080 0.0.0.0:*问题就在这里。127.0.0.1:8080意味着服务只绑定了回环地址外网流量根本进不到这个进程。很多应用默认会绑定到localhost比如某些版本的Nacos、Redis、MySQL、Spring Boot内置Tomcat如果你部署后没改bind地址外部当然访问不了。解决办法是改配置把监听地址改到0.0.0.0或者具体的内网/公网IP。但这里我要多说一句运行时绑定到127.0.0.1在不少场景下是刻意的安全设计。比如数据库只允许应用本机访问就不应该为了图方便改成0.0.0.0。要先想清楚这个端口到底需不需要对外暴露再动手改。另一个外部访问不了的原因是云服务器安全组。系统防火墙放行了服务也绑到了0.0.0.0但云平台控制台安全组的入方向规则没放行该端口照样访问不了。这个经常会和系统防火墙混淆排查顺序固定为服务监听地址 → 系统防火墙 → 云安全组 → 硬件/云防火墙。3. 资源耗尽三件套CPU飙高、内存枯竭、磁盘打满3.1 故障四CPU使用率飙升CPU飙高是服务器运维的日常问题是怎么判断是正常业务负载还是异常程序在作怪。先看top按CPU排序找到占CPU最高的进程。但在这里我要先纠正一个常见误区load average高不代表CPU满。它统计的是处于运行态和不可中断睡眠态的进程数磁盘I/O等待也会让负载飙升。不信你在一个传统机械硬盘的机器上做大量小文件读写load average可能冲到10以上但CPU的us和sy都很低大把时间花在waI/O wait上了。如果确认确实是CPU高再分us用户态和sy系统态us高业务进程在消耗CPU下一步用top -H -p PID看线程维度再用pidstat -t -p PID 1看具体哪个线程。Java应用可以jstack导出线程栈Python/PHP就strace -p PID看到底在调什么系统调用。常见肇事者包括没加索引的慢查询、死循环、正则灾难性回溯、客户端连接疯长。sy高CPU耗在内核态典型的场景是虚拟化环境的网络软中断可以用top里看si那一栏、系统调用过于频繁、或者被某些内核模块拖累。还有一种特殊情况是服务器被当作跳板机大量转发流量进来也会导致sy高。这里必须要提一下挖矿木马。中招的机器CPU使用率直接飙到100%top里能看到一个名字随机或伪装成系统服务的进程比如kdevtmpfsi这种。处理步骤是先用ls -l /proc/PID/exe找到可执行文件路径再用lsof -p PID看它打开了哪些文件接着crontab -l查有没有可疑计划任务最后检查~/.ssh/authorized_keys有没有被塞入陌生公钥。杀掉进程只是开始不把后门清干净过几天它还会回来。3.2 故障五内存耗尽触发OOM Killer内存问题比CPU更容易迷惑人因为Linux的内存管理机制和Windows不一样。很多人看到free -h里used很高、free很低就慌了其实只要available那一列还有富余就不需要紧张。available是一个重要指标它估算出在不触发swap的情况下系统还能分配多少内存给新进程。Linux会把大量空闲内存用作page cache文件缓存这部分缓存内存是可以在内存紧张时自动让出来的。所以判断内存够不够用看available而不是裸的free。真正需要警惕的是OOM Killer。当系统内存耗尽、swap也被吃满时内核会挑选一个进程杀掉来释放内存——而且它挑的不一定是你以为的那个进程。症状就是服务突然消失dmesg -T | grep -i oom能看到内核日志Out of memory: Killed process 1234 (mysqld) total-vm:8388608kB我见过最典型的案例Java应用-Xmx8g跑在8G内存的机器上堆内存线程栈元空间GC开销叠起来早就超了物理内存一启动没多久就被OOM掉。这种其实很好排查因为日志里会持续复现。处理内存问题的几个要点free -h先确认available是否告急cat /proc/pressure/memory可以看内存压力用ps aux --sort-%mem | head找内存消耗大户查swapswapon -s或cat /proc/swapsswap长期被大量使用说明物理内存确实不够了按业务性质调整Java调堆大小Redis设置maxmemory数据库优化连接数。临时急救可以直接sync echo 3 /proc/sys/vm/drop_caches清理page cache但这只是治标根本解法是扩容内存或者优化应用内存占用。3.3 故障六磁盘空间写满或inode耗尽磁盘满是最常见的“服务器突然写不了数据”的原因。排查流程分两步先看容量df -h定位哪个分区满了然后用du -sh /目录逐层往下找定位到大目录再du --max-depth1往下钻。等找到真凶可以用find / -size 1G -exec ls -lh {} \;快速找出超大文件。再看inode有时候df -h显示还有空间但应用就是报“No space left on device”这时候要查df -i。inode耗尽是因为文件系统里小文件数量太多把索引节点全占光了。常见于邮件队列、PHP session目录、Docker容器产生的大量JSON日志。处理思路是删除无用的海量小文件并修改应用让它不再疯狂生成。还有一个隐藏很深的坑——文件删了但空间没释放。有进程一直持有某个已删除文件句柄磁盘空间明明被占用但你ls找不到这个文件。典型场景是日志文件被误删但写日志的进程Nginx、Tomcat等还开着那个文件句柄。用lsof L1 | grep deleted找到这些进程重启或重载进程空间才会真正释放。遇到磁盘满先别急着删文件一定先du定位、再确认是不是有进程占着句柄最后再动手清理。之前有个项目就是这种情况运维删了access.log但Nginx不重载空间一直不释放业务一直接连报错重启Nginx之后才恢复。4. 系统层翻车现场时间漂移、开机失败、RAID降级4.1 故障七系统时间悄悄漂移时间问题是最容易被低估的故障类型但它造成的破坏极其迷惑——HTTPS证书校验失败、Kerberos票据失效、数据库主从复制错乱、日志时间排序全乱。有一种非常诡异的现象系统登录突然提示“凭证过期”或“证书错误”你查证书明明有效最后发现是服务器本地时间偏了好几十分钟。排查非常简单date timedatectl status如果时间不对首选方案是配置chrony做时间同步。编辑/etc/chrony.conf加上国内可用的NTP服务器server ntp.aliyun.com iburst server ntp.tencent.com iburst pool 2.pool.ntp.org iburst改完重启服务systemctl restart chronyd chronyc sources -v我自己维护的一批机器都配置了chrony作为NTP客户端并要求监控告警里加上时间偏移量检查。另一个之前踩过的坑在云服务器上手动执行hwclock --systohc把系统时间写进了硬件时钟结果重启之后时间反而更乱了。正确做法是用timedatectl set-ntp true交给系统自动管理。如果你负责的是一组内网服务器还可以挑一台机器作为时间服务器其他机器统一从它同步。做法是在这台服务器上配置chrony允许内网网段访问allow 192.168.0.0/16其他机器上把server指向这台时间服务器的内网IP这样整个集群的时间就能保持一致。这个方案在无外网的内网环境里尤其有用比让每台机器自己找公网NTP稳定得多。4.2 故障八开机进入emergency mode或GRUB起不来服务器无法开机是最让人头皮发麻的故障但其中绝大多数问题出在一个很基础的配置上——/etc/fstab写错了。我见过太多这种场景新加了一块数据盘手滑写错了UUID或者挂载路径执行reboot之后系统直接卡在emergency mode登录进去一看根文件系统被挂载成只读。这是因为systemd在启动时发现某个挂载项失败为了安全起见进入了紧急模式。处理流程通过物理控制台或云控制台的VNC/救援模式进入系统执行mount -o remount,rw /把根分区切成可写vim /etc/fstab检查刚才写的挂载项错误的行先注释掉blkid查出正确的UUID或确认挂载路径的目录确实存在再执行umount -a测试挂载配置是否正确谨慎使用然后reboot。如果连GRUB都起不来问题更严重一些。常见原因有引导分区损坏、内核文件丢失、或者双系统安装时引导记录被覆盖。处理思路是使用系统安装盘的rescue模式启动chroot进原系统环境后重新生成引导mount /dev/sda2 /mnt mount /dev/sda1 /mnt/boot chroot /mnt grub2-mkconfig -o /boot/grub2/grub.cfg grub2-install /dev/sda这里有个经验教训执行grub2-install之前一定要确认BIOS里的启动顺序和磁盘识别顺序一致。前些年有台服务器就是装到了sdb上重启后系统直接找不到引导。别问我怎么知道的。4.3 故障九RAID阵列降级或损坏每个把RAID当备份用的人迟早要吃大亏。RAID不是备份它的核心目的是保障单块磁盘故障时业务不中断但绝不防误删、不防勒索病毒、不防双盘同时故障。排查RAID故障的第一步是确认当前状态cat /proc/mdstat mdadm --detail /dev/md0软件RAID看这两个命令就够了。硬件RAID需要厂商工具比如LSI/MegaRAID用MegaCli64戴尔用perccli惠普用hpssacli。这些工具能查到物理磁盘状态和控制器日志。当界面显示degraded状态时说明阵列里有一块盘掉了数据还在但已经失去冗余保护。这时候最忌慌乱按以下顺序处理用mdadm /dev/md0 -f /dev/sdb把坏盘标为fail用mdadm /dev/md0 -r /dev/sdb从阵列中移除物理更换新硬盘用mdadm /dev/md0 -a /dev/sdb把新盘加入阵列查看cat /proc/mdstat确认rebuild进度。整个重建过程会持续一段时间期间系统I/O负载会明显升高。如果是生产环境建议在业务低峰期操作同时做好临时备份。还要强调两个容易犯的错误一是新换的硬盘容量不能小于阵列中其他盘我做RAID5时曾经插了一块不同容量的盘结果识别不出来白白浪费时间二是RAID5在单盘降级期间如果再挂一块盘数据基本救不回来这种时候不要盲目重建阵列第一时间联系专业数据恢复才是止损的正确方式。磁盘出现大量I/O error看dmesg或者SMART日志开始报警时就该提前换盘了别等降级了才行动。5. 应用层疑难杂症Web假死、FTP传不动、日志雪崩5.1 故障十服务进程活着但Web站点“假死”这个故障的迷惑性在于你ps -ef | grep nginx能看到master进程和worker进程都在但网站就是打不开。这种就叫“服务假死”。排查顺序我建议从外到内先看本机健康状态curl -I http://127.0.0.1看是否响应。如果这里都卡住问题在服务自身。再看连接状态ss -s看连接总数和TIME_WAIT数量。如果TIME_WAIT堆积到几万说明短连接负载过高需要开连接复用。但注意net.ipv4.tcp_tw_reuse可以开net.ipv4.tcp_tw_recycle慎开——它会在NAT环境下把正常用户连接给重置掉。然后看Nginx日志/var/log/nginx/error.log是定位问题的金矿。如果发现大量worker_connections are not enough说明worker_connections配置太小或者worker进程数不够需要调大。还有一种情况是背压问题Nginx本身没毛病但后端的PHP-FPM或Java服务挂掉了导致所有请求都在等待后端响应。PHP-FPM的经典症状是日志里大量出现WARNING: [pool www] server reached pm.max_children这说明PHP-FPM的pm.max_children已经耗尽新来的PHP请求全部排队等待Nginx随之超时。处理办法是调大pm.max_children同时排查后端有没有慢请求把进程池占满——通常用slowlog或者request_slowlog_timeout找出哪些脚本卡住了。对于长期运营的业务最终解法往往不是临时调参而是加缓存、加机器、做限流。之前一个线上商城就是高峰期图片请求把Nginx worker全占满加了页面缓存之后才彻底解决。5.2 故障十一FTP能连上但列目录/传文件卡死FTP这个协议设计于上世纪70年代它在NAT和防火墙环境下工作时能踩的坑基本都被人踩遍了。先理解FTP一个反直觉的地方FTP用两个连接一个控制连接21端口一个数据连接动态端口。能不能登录看的是控制连接能不能列目录、传文件看的是数据连接。所以会出现“能登录但列目录卡死”这种诡异现象。FTP有两种数据连接模式模式数据连接建立方式NAT/防火墙环境表现主动模式Active服务器主动连接客户端的随机端口客户端在内网时基本必挂被动模式Passive客户端连接服务器指定的随机端口需要防火墙放行对应端口段绝大多数现代网络环境都要求使用被动模式。服务器的vsftpd配置需要明确被动端口范围pasv_enableYES pasv_min_port30000 pasv_max_port31000然后防火墙必须放行这个端口段。只放行21端口的防火墙规则几乎是所有FTP问题的共同答案。Windows Server上配置IIS FTP也会遇到相同问题控制面板勾选FTP服务后防火墙虽然自动生成了规则但通常只放行21。要么手动加上被动端口段要么干脆放弃纯FTP。我的建议是能不用FTP就别用FTP。现在的SFTP基于SSH一个22端口全部搞定不需要被动端口段传输加密权限体系也成熟。Windows Server装了OpenSSH Server之后就能直接SFTPLinux本来就用ssh自带的sftp子系统没必要抱着几十年前的老协议不放。5.3 故障十二系统日志雪崩式增长拖垮整台机器日志本身是帮我们排查故障的但如果日志失控它自己就会变成一个故障源。症状通常是这样某个服务开始疯狂报错日志文件以GB级速度增长导致/var分区被写满系统出现各种莫名其妙的问题。更恶心的是日志雪崩往往和磁盘满互为因果——磁盘满触发更多写失败写失败产生更多错误日志形成恶性循环。我曾经处理过一个游戏服项目Nginx access.log几个月没切割一个文件涨到30GB然后把/var分区占满数据库和存档同盘差点把玩家数据搞没。从那以后所有服务器的日志切割都纳入了我的基础配置清单。应急清理命令truncate -s 0 /var/log/nginx/access.log注意用truncate而不是rm直接删文件会让持有句柄的进程继续往这个“幽灵文件”里写空间根本释放不了。根治方案是logrotate按天切割daily rotate 30 compress delaycompress copytruncatecopytruncate参数很重要——日志文件被复制后原文件被清空不需要重启服务进程。还有journald日志系统也要管它默认存储在/var/log/journal里时间久了也能占掉大量空间journalctl --vacuum-size500M同时修改/etc/systemd/journald.confSystemMaxUse500M最后建议把重要日志集中起来统一发到ELK或Loki这类日志平台。这样既避免日志堆在单台服务器上挤占磁盘排查问题时也能一次搜索多台机器比挨个上去tail -f效率高太多了。排障这一年一年做下来最大的敌人其实不是故障本身而是“猜”。不带证据就上手操作和蒙着眼睛拆炸弹没什么区别。这套排查思路陪我处理过几百次事故不能说每次都完美但至少让我在紧急时刻不慌——因为我知道先看哪一层、先收集什么证据再决定动什么刀。另外很建议你给自己维护的服务器建一个“故障档案”用最普通的Markdown文件记录日期、故障现象、排查过程、根因、处理命令、后续预防措施。别嫌麻烦半年后翻出来看你会发现那些曾经的“疑难杂症”都已经变成你最快的定位经验。服务器踩坑是踩不完的但每踩一次都记下来下一次就会快很多。