在服务器运维过程中，故障排查是每位站长的必修课。不管是网站突然打不开、SSH 连接不上，还是磁盘空间告警，掌握系统化的排查方法能让你在最短时间内恢复服务。本文结合真实运维案例，分享网络连接和磁盘空间两大类常见故障的排查思路。
一、网络连接故障排查
当网站无法访问时，不要急着重启服务器，按照以下步骤逐一排查：
1.1 确认服务器是否在线
如果连 SSH 都连不上，先检查服务器提供商的控制面板（如阿里云、腾讯云、Vultr 等）是否显示服务器在线。有时云服务商的 Network 维护会导致短时断连，这种情况等待即可。如果控制面板显示服务器已关机，可能是 OOM（内存溢出）导致系统自动重启或关机。
能 SSH 登录的情况下，首先执行基础网络检查：
# 检查网络接口状态 ip addr show # 或者使用旧版命令 ifconfig -a # 检查默认路由 ip route show # 或 route -n # 检查 DNS 解析 nslookup www.zz1984.com dig www.zz1984.com # 测试外网连通性 ping -c 4 8.8.8.8
1.2 端口监听检查
确认 Web 服务是否在正常监听：
# 查看所有监听端口 ss -tlnp # 或者使用 netstat -tlnp # 确认 Nginx 运行状态 systemctl status nginx # 检查 Nginx 错误日志 tail -100 /var/log/nginx/error.log
如果 80 或 443 端口没有监听，基本可以确定是 Nginx 挂掉了。查看 systemctl status 的输出，重点关注 "Active:" 行是 running 还是 failed。如果是 failed，用 journalctl -xeu nginx 查看详细的崩溃日志。
1.3 连接数排查
网站访问慢的常见原因是连接数耗尽：
# 查看当前连接数统计
ss -s
# 按状态统计连接数
ss -t | awk '{print $1}' | sort | uniq -c
# 查看特定端口的连接数
ss -t state established | wc -l
# 查看 TIME_WAIT 状态连接数
ss -t state time-wait | wc -l
如果 TIME_WAIT 连接过多（超过几千个），可能是短连接没有复用导致的。可以在系统内核参数中调优：
# /etc/sysctl.conf 添加以下配置 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_fin_timeout = 15 net.core.somaxconn = 65535 net.ipv4.tcp_max_syn_backlog = 65535
执行 sysctl -p 使配置生效。
1.4 防火墙与安全组排查
很多网络问题其实是防火墙导致的：
# 检查 iptables 规则 iptables -L -n -v # 检查 nftables（CentOS/RHEL 8+ 默认） nft list ruleset # 检查 firewalld firewall-cmd --list-all # 临时关闭防火墙测试（切勿在生产环境长时间关闭） systemctl stop firewalld # 或 iptables
另外不要忘了检查云服务商的安全组规则。很多时候在服务器内部防火墙放行了端口，但云平台的安全组没放行。需要在云控制台的「安全组」或「防火墙」页面配置入站规则。
二、磁盘空间与 I/O 故障排查
磁盘问题通常表现为：网站写入失败、数据库无法启动、日志报 "No space left on device"。
2.1 磁盘空间检查
# 查看磁盘总体使用情况 df -h # 查看 inode 使用情况（小文件过多也会导致不能写入） df -i # 找出占用最大的目录 du -sh /* 2>/dev/null | sort -rh | head -10 # 逐层深入查找大文件 du -sh /var/log/* | sort -rh | head -10
很多站长忽略 inode 耗尽导致的"磁盘满"问题。inode 用满时 df -h 可能显示还有剩余空间，但 df -i 显示 inode 使用率 100%。这种情况通常是因为某个目录下有海量小文件，比如 PHP 会话文件缓存过多或邮件队列积压。解决方案是删除无用的小文件，并调整相关应用的清理策略。
2.2 大日志文件清理
日志文件是磁盘空间的头号杀手：
# 查看各类日志大小
ls -lh /var/log/
# 安全清空日志（不要直接 rm，因为服务进程可能还在写入）
truncate -s 0 /var/log/nginx/access.log
# 或者使用
: > /var/log/nginx/error.log
# 配置 logrotate 自动轮转（/etc/logrotate.d/nginx）
/var/log/nginx/*.log {
daily
rotate 7
compress
delaycompress
missingok
notifempty
sharedscripts
postrotate
[ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`
endscript
}
2.3 找出并清理大文件
# 找出大于 100MB 的文件
find / -type f -size +100M -exec ls -lh {} \; 2>/dev/null | sort -k5 -rh
# 找出超过 7 天的临时文件
find /tmp -type f -atime +7 -delete
# 查找未被打包但可清理的缓存文件
find /var/cache -type f -atime +30 -delete
2.4 Docker 磁盘清理
如果使用了 Docker，容器镜像的磁盘占用往往超出预期：
# 查看 Docker 磁盘占用
docker system df
# 一键清理（删除停止的容器、未使用的网络、悬空镜像和构建缓存）
docker system prune -af --volumes
# 查看各容器磁盘占用
docker ps -a --format "table {{.Names}} {{.Size}}"
# 限制容器日志大小（在 docker-compose.yml 中添加）
logging:
driver: "json-file"
options:
max-size: "10m"
max-file: "3"
三、故障排查的通用原则
经过多年的运维实践，我总结出三条故障排查的核心原则：
原则一：从外到内。先排查网络连通性，再检查服务状态，最后查看应用日志。不要一上来就去查数据库配置，可能问题仅仅是防火墙没放行端口。
原则二：查看日志。绝大部分故障的原因都能在日志中找到。Nginx 有 access.log 和 error.log，PHP-FPM 有 www.error.log，数据库有 error.log。养成先看日志的习惯，能节省大量无谓的猜测时间。
原则三：做好监控预警。推荐使用开源监控工具如 Prometheus + Grafana 或轻量级的 Netdata 来设置磁盘使用率、CPU 负载、内存使用率的告警阈值。这样很多问题在爆发之前就能收到提醒。对于小型站点，至少配置一个磁盘使用率的 crontab 检查脚本，每天发送邮件报告。
总结
服务器故障排查是一项需要不断积累经验的技能。本文介绍的排查方法覆盖了最常见的网络和磁盘两类问题，建议新手站长把这篇文章收藏起来，遇到问题时按照步骤逐一检查。同时，我还建议每个站长都建立一个运维手册，记录自己遇到过的问题和解决方法。不仅是方便自己，日后交接服务器时也能让接手的人更快上手。最后要强调的是：不要等到出问题了才去排查，建立完善的监控和定期巡检机制才是服务器长期稳定运行的根本保障。