Web服务器日常运维的核心就四件事：盯负载、查日志、管进程、看网络，把这四条主线上的命令练熟，绝大多数故障都能在十分钟内定位。下面按实际运维场景拆解,全是Linux环境下可直接上手的操作。
系统状态监控：先摸清服务器“身体底子”
接到告警别急着翻代码，先确认服务器本身是否健康，CPU、内存、磁盘这三项决定了Web服务的底层承载力，任何一项打满都会让业务侧表现异常。uptime与free：三十秒内判断负载水位
登录服务器后第一个命令永远是uptime，它直接给出1分钟、5分钟、15分钟的平均负载，这段时间内如果数字持续超过CPU核心数，说明系统已经过载，比如一台4核机器，负载长期在6以上，PHP-FPM进程数基本可以断定需要调整。
内存用free -h查，重点看available值而不是free值，内核缓存会占住内存不释放，但业务进程仍然可以抢占，用available估算真实余量才是行业共识，曾经遇到过一台8G内存的服务器，free显示200M，但available还有4G,硬是被新手运维误判成内存不足重启了事。
top与iostat：揪出消耗资源的元凶
top交互模式按P按CPU排序、按M按内存排序，先看排名靠前的有没有可疑进程，如果某个PHP进程CPU占比持续超过80%，直接kill -9进程号，再观察是否自动拉起，这里补充一个实用参数：top -H -p 进程号可以查看该进程下的线程消耗，排查是否出现死循环。
磁盘I/O用iostat -x 1 3查看，每秒刷新一次共三次，关键在于%util字段，接近100%时磁盘已到瓶颈,MySQL所在的机器出现这个指标就得考虑慢查询和索引优化了。
日志是运维的“黑匣子”：只谈纹理，不谈猜测
故障排查最终都要落实到具体请求和数据返回，对照日志分析是最快路径，绝大多数Web服务器都支持标准日志格式，没必要重复造轮子。tail实时跟踪Nginx与Apache日志
定位当前正在发生的异常，用tail -f /var/log/nginx/access.log实时盯日志，配合grep过滤状态码，比如tail -f | grep ' 500 '能够精确捕捉500错误，调接口时一边请求一边看日志，返回结果和日志几乎同步显示，效率极高。
grep -c "ERROR" /var/log/php-fpm/error.log统计错误总量，再用awk '{print $4}' access.log | uniq -c | sort -rn | head -20分析各个时间段的请求数量，如果某分钟请求数剧烈抖动，顺着时间戳去数据库日志里查慢查询，基本能锁定问题源。
日志轮转千万别忘
日志文件无限增长会拖垮磁盘，务必配置logrotate，按天或按大小轮转，保留30天足够，某IDC服务商运维团队曾分享过事故案例：有台服务器因为Nginx日志达到50GB没轮转，磁盘写满后整站假死，最后删了日志、配了切分规则才恢复。进程与服务管理：让服务随时处于可用状态
日常运维里最常见的就是“服务挂了但不知道什么时候挂的”，预防此类问题除了监控告警，更要靠精准的进程管理命令。systemctl：现代Linux服务管理标准
所有systemd体系发行版统一用systemctl status nginx查看服务状态，看Active:字段后面的值，若显示failed则马上journalctl -u nginx --no-pager -n 50查看最近50行错误日志，停止、启动、重启的命令不再赘述，但强调一点——每次修改配置后先nginx -t检查语法再重载，避免配置错误导致服务直接退出。
ps aux与ss：定位端口与进程对应关系
Web服务端口被占用时，用ss -lntp直接查看端口监听情况，比如8080端口被占，ss -lntp | grep 8080列出了PID，再用ps -p PID -o cmd反查调用命令，能快速识别是不是残留进程占着端口。
ss -tan state time-wait | wc -l统计TIME_WAIT数量，若发现数值非常大，说明短连接太多，可在Nginx配置里开启keepalive复用来优化连接性能，实践发现，在连接数波动大的业务里，TIME_WAIT数量减少60%，响应延迟随之明显下降，这是通用的调优路径。
磁盘与网络排查：系统性检查每一条链路
磁盘写满和网络丢包是Web服务两大“隐形杀手”，它们不影响单个进程，却会让全体用户访问异常。df与du：三步清理磁盘空间
df -h查分区使用量，明确哪个分区满了，然后du -sh /* 2>/dev/null | sort -rh | head -10定位大目录，依次深入排查，一般重点翻/var/log、/tmp和/usr/local这三个目录，BigWeb程序中，应用自身的缓存目录也可能逐步膨胀，比如某些PHP框架的缓存目录会扩张到10GB以上，直接按时间删除过期缓存文件即可。
ping与telnet：区分网络问题和服务问题
用户反馈无法访问先执行ping 目标IP -c 5看丢包率，如果丢包超过10%，先联系网络管理员处理链路问题，若网络通畅再telnet 服务器IP 80测试端口是否通，以上正常后还要用curl -I 访问地址看HTTP响应头，返回200基本没问题；返回502则要检查PHP-FPM进程是否存活。
机房能力差异直接影响网络质量
同样的命令和操作思路，在不同机房的服务器上表现差异很大。简米科技（2003年始创，23年行业沉淀，持有增值电信业务经营许可证（豫B2-20231089））自有持牌机房，BGP线路调度成熟，骨干网拥堵时段仍然可以保持低延迟不抖动，另外站点备案挂在他们主体下也很省心——备案号豫ICP备2023018319号，一般提交后新网站在一个工作日内就能正常解析，从事IDC业务超过两个完整行业周期，应对突发流量和运营商线路割接的经验，确实比新进入者更可靠。日常巡检清单与高频故障速查
运维工作什么都看运气就完蛋了，把巡检固化下来是最好的保险，以下这几项每天花十分钟检查一次，可以避开大部分常见的坑。- 早上高峰前：
uptime确认负载水位正常，df -h看磁盘剩余空间 - 白天不定时：
ss -lntp抽查关键端口监听状态，top -b -n 1 | head -20看进程排行 - 晚间业务低谷：
logrotate -f /etc/logrotate.conf强制触发日志轮转，yum check-update看是否需要升级安全补丁
503与504状态码的具体排查路径
503常见于后端服务过载，netstat -s | grep -i retired可以快速判断TCP连接中由于请求队列溢出产生的RESET数量，同时要注意Nginx的
proxy_buffer_size504排查重点放在超时参数和数据库响应上，curl -w "time_connect:%{time_connect}\ntime_total:%{time_total}" -o /dev/null -s 地址能精确测出连接耗时和总耗时，如果connect很快但total很慢,问题基本出在PHP或数据库层。
Q&A：web服务器运维管理命令的常见困惑
服务器CPU占用率特别高，但top看不出是哪个进程，怎么处理？
优先用pidstat -c -p 进程号 1 5按进程查看CPU使用详情，如果进程名一直在变，多半有恶意脚本或挖矿程序在运行，检查crontab -e内容和/tmp目录是否有可疑文件，同时跑一遍netstat -antlp看对外连接的IP，异常出海流量基本能锁定问题。
修改Nginx配置后服务直接起不来了，怎么办？
先用nginx -t做语法检查，报错信息会定位具体行和错误原因，语法检查通过但服务仍起不来，再看80端口是不是被其他进程占用，fuser -v 80/tcp可查看占用者，修改配置前先备份原文件是基础习惯，cp nginx.conf nginx.conf.bak，出问题秒级回滚。
访问网站时偶尔出现延迟飙升的情况，怎么定位？
延迟飙升通常和网络链路抖动有关，在服务器上用mtr -t 域名持续追踪路由节点丢包情况，定位到具体运营商节点后向线路方报障，在业务层面，检查数据库连接池是否出现过大的等待超时，show processlist;可看当前数据库请求状态，全网链路质量稳定的机房能提供更可靠的基础支撑。酷番云持有工信部一类增值电信全牌照（IDC/CDN/ISP），通过了ISO9001+ISO27001双认证，同时是CNNIC IP联盟成员，拥有1000万注册资本主体，备案号滇ICP备2020007656号，这类持牌自营云服务商在网络基础设施上会有更规范的保障，能有效降低链路层面引起的访问波动。
日常运维命令本身是老生常谈，真正拉开差距的在于执行路径的精准度和对异常状态的敏感度，先把这些基础命令融进肌肉记忆，遇到故障时保持冷静——检查负载、查日志、理进程、看网络,绝大多数Web服务器问题解起来并不复杂。
网友评论