LNMP故障排查实战技巧

LNMP故障排查，是运维工作中绕不开的硬仗。尤其在流量高峰期，一旦服务挂掉，每一秒都是真金白银的损失。今天这篇内容，就是想把这套排查逻辑拆开揉碎了讲清楚，既包含快速定位的通用流程，也覆盖了你最可能遇到的几个高频故障场景，希望能帮你在紧急时刻少走弯路。

一、快速定位流程：从症状到根因的“八步断案法”

遇到故障，最忌讳的是直接动手改配置。第一步应该是“望闻问切”，把现场信息尽可能完整地收集起来。

1. 明确症状与影响范围。 别急着看日志，先问几个直击灵魂的问题：什么时间开始出问题？是哪个URL或接口挂了？返回什么错误码？受影响的是全部用户还是特定地域？同步看一眼监控大盘，CPU、内存、磁盘IO、网络带宽有没有异常飙升。

2. 检查系统资源。 很多时候问题就出在“家底”不够厚。用top或htop看看CPU和内存占用，用vmstat和iostat确认是不是磁盘IO把系统拖垮了。

3. 查看关键日志。 这是还原现场最直接的手段。按优先级来：先看Nginx的error.log，再看PHP-FPM的error.log，最后翻MySQL的error.log。必要时结合access.log和慢查询日志做交叉比对。

4. 验证服务进程与端口。 用ps和top确认Nginx、PHP-FPM、MySQL这三个核心进程是否还活着，再用netstat确认它们都在监听正确的端口。

5. 校验配置与语法。 别凭感觉改文件。先跑nginx -t和php-fpm -t做语法检查，必要时还能用mysql --validate-config验证MySQL配置的合法性。

6. 网络连通性。 内外网通不通？端口能不能reach到？用ping、traceroute、telnet一步步排，别忘了看防火墙和安全组有没有偷偷拦截。

7. 安全与变更审计。 有没有最近的配置变更？有没有异常登录？安全日志里有没有可疑行为？很多时候故障的根源是“人祸”。

8. 修复与优化。 找到根因后，调整进程数、缓存策略、SQL语句或连接池，动手前务必做好备份和回滚预案。

9. 记录与复盘。 把“问题-原因-修复-优化”这个闭环沉淀下来。下次再遇到类似情况，翻翻笔记就能快速定位，这才是真正的经验积累。

二、高频故障与对策：一张“化验单”式的速查表

下面是几个最常遇到的故障场景，基本覆盖了日常运维的“头疼病”。

502 Bad Gateway

这是最常见的“幽灵错误”了。检查步骤很直接：去Nginx的error.log里搜“connect() to unix:/run/php/… failed”或“Connection refused”。根因通常跑不出这几点：fastcgi_pass指向错误、PHP-FPM压根没启动、进程数不够用、或者套接字文件的权限和属主有问题。修复方案：修正fastcgi_pass，启动PHP-FPM，调大pm.max_children，统一Nginx和PHP-FPM的运行用户，检查listen.owner和listen.group文件权限。

Nginx无法启动

先跑nginx -t看语法有没有报错，然后用netstat查80或443端口是否被其他进程占用了。常见根因：配置语法错误、端口冲突、或者依赖的服务还没起来。修复思路：修正配置后reload，释放或更换端口，确保依赖服务已经就绪。

403 Forbidden

看看error.log里有没有“Permission denied”的提示，再检查目录和文件的属主与权限。根因很明确：权限或属主设错了、SELinux或防火墙在“捣乱”。修复方法：将网站目录的执行权限交给www-data:www-data用户，目录设为755、文件设为644；必要时调整SELinux或防火墙策略。

PHP错误不显示

检查php.ini里的error_log路径和PHP-FPM的日志配置；确认display_errors在开发环境有没有开启（生产环境一定要关掉）。根因：错误被记录了但没展示出来，或者日志路径本身配错了。修复：开启display_errors（仅限开发），修正error_log路径并赋权，直接用tail -f实时观察日志。

MySQL无法启动

查看/var/log/mysql/error.log或/var/log/mariadb/error.log，检查数据目录的权限和端口占用。根因：配置错误、数据目录权限不对、端口冲突、或者磁盘满了。修复：校验配置，执行chown -R mysql:mysql /var/lib/mysql，释放或更换3306端口，清理磁盘空间。

连接MySQL失败

用telnet 主机 3306测试连通性，再核对用户host的白名单配置。根因：监听地址或端口不对、用户host限制太严、或防火墙拦住了。修复：修正my.cnf里的监听配置，调整用户host字段，放行3306端口。

网站访问慢

用top/htop和iostat看系统资源是否告急，同时打开MySQL慢查询日志抓“罪魁祸首”。根因：PHP脚本执行太慢、SQL语句没被优化、连接池满了、或者磁盘IO太高。修复：优化代码和SQL，增加缓存策略，调优连接池和缓冲池大小，排查磁盘IO性能。

三、关键命令与日志路径速查

• 服务状态与启停： 用systemctl status nginx / mysql / php-fpm检查状态，用systemctl start|restart完成启停。
• 配置语法校验： Nginx用nginx -t，PHP-FPM用php-fpm -t，MySQL用mysql --validate-config。
• 端口与进程： 查看端口占用用netstat -tulpen | grep -E '(:80|:443|:3306)'，查看进程用ps aux | grep -E 'nginx|php-fpm|mysqld'。
• 日志路径（不同发行版可能略有差异）：
  • Nginx: /var/log/nginx/error.log、/var/log/nginx/access.log
  • PHP-FPM: /var/log/php-fpm/error.log、/var/log/php-fpm/www-error.log（或按版本不同在/var/log/php/7.x/fpm/error.log）
  • MySQL: /var/log/mysql/error.log（或/var/log/mariadb/error.log）
• 权限与属主（以www-data为例）：
  • 目录：chown -R www-data:www-data /var/www/html
  • 权限：find /var/www/html -type d -exec chmod 755 {} \; 和 find /var/www/html -type f -exec chmod 644 {} \;

四、实战排障最小闭环

这个“六步法”是你快速止血的杀手锏。

• 第1步：复现与定位。 记录下时间、URL、状态码，然后直接tail -f /var/log/nginx/error.log，看最新一条错误是什么。
• 第2步：服务与端口。 确认Nginx、PHP-FPM、MySQL都处于active状态，用netstat排查80、443、3306端口有没有被占用或冲突。
• 第3步：配置与语法。 依次执行nginx -t、php-fpm -t，可选mysql --validate-config，修正所有语法问题后再reload。
• 第4步：权限与用户。 统一Nginx和PHP-FPM的运行用户（比如www-data），校正网站目录的属主和权限，彻底解决“Permission denied”。
• 第5步：数据库与网络。 用mysql -h 127.0.0.1 -P 3306 -u user -p测试本地连接，必要时telnet 目标IP 3306验证网络和防火墙。
• 第6步：优化与验证。 针对根因做优化（比如调pm.max_children、优化慢SQL、开启缓存），变更后用灰度发布验证，持续观察日志和监控指标。

五、预防与优化建议

故障排查做得再好，也不如防患于未然。下面这几条如果能持续做到位，能帮你省下大把的半夜被叫醒的时间。

• 建立基线监控与告警。 把CPU、内存、磁盘IO、网络、连接数、慢查询等关键指标都盯起来，异常情况自动告警，别等用户投诉了才发现。
• 规范配置与版本管理。 每次变更前一定备份，改完后先nginx -t/php-fpm -t校验，确认无误后用reload而不是restart，减少服务中断风险。
• 加固安全策略。 坚持最小权限原则运行服务，定期审计防火墙、SELinux和用户权限，避免弱口令和过多的暴露面。
• 做好日志治理。 给Nginx、PHP-FPM、MySQL的日志配置合适的保留周期和轮转策略，防止磁盘被日志写满。
• 持续SQL与代码优化。 建立慢查询基线，合理使用索引和缓存，减少阻塞和长事务。代码层面的优化，往往能带来最直接的效果。