LNMP如何解决502错误

LNMP出现502错误的定位与修复指南

一、快速判断与定位

• 含义：502 Bad Gateway表示Nginx作为网关/反向代理无法从上游的PHP-FPM获取有效响应，常见成因包括进程崩溃、连接被拒、权限不匹配、资源耗尽、配置不一致等。
• 第一步：确认服务状态
  • 检查 PHP-FPM 是否存活：ps -ef | grep php-fpm 或 systemctl status php-fpm；若未运行，启动：systemctl start php-fpm。
• 第二步：查看错误日志
  • Nginx 错误日志（默认路径如：/usr/local/nginx/logs/error.log），必要时临时将级别调为 debug 以捕获更多线索，排查后改回 crit，避免磁盘被撑满。
  • PHP-FPM 日志（如：/usr/local/php/var/log/php-fpm.log），关注连接失败、进程崩溃、慢请求等信息。
• 第三步：核对监听与转发是否一致
  • 在 Nginx 虚拟主机中：fastcgi_pass unix:/tmp/php-cgi.sock; 或 fastcgi_pass 127.0.0.1:9000;
  • 在 PHP-FPM 中：listen = /tmp/php-cgi.sock; 或 listen = 127.0.0.1:9000;
  • 两者必须一一对应；不一致会直接导致 502。
• 第四步：排除资源与系统限制
  • 磁盘空间：df -h；若根分区 100%，清理大日志/缓存后再重启服务。
  • 文件描述符与进程数：检查系统/进程限制是否过低。
• 第五步：识别错误类型
  • 所有 PHP 动态请求都 502：多为 PHP-FPM 未启动/崩溃或监听错误。
  • 高并发时偶发 502：多为 子进程不足或 请求超时。
  • 特定页面/插件 502：多为 代码死循环/扩展冲突。

二、常见原因与对应修复

• 配置不一致（最常见）
  • 症状：刚部署或改配置后出现 502。
  • 修复：确保 Nginx 的 fastcgi_pass 与 PHP-FPM 的 listen 一致；若使用 Unix Socket，确保路径、权限一致；必要时由 socket 切换为 127.0.0.1:9000 验证连通性。
• 权限问题（Unix Socket 模式）
  • 症状：偶发 502，错误日志提示 permission denied。
  • 修复：让 Nginx 与 PHP-FPM 使用相同用户/组，或在 PHP-FPM 中设置 listen.owner/listen.group 与 Nginx worker 一致（如 nobody）。
• PHP-FPM 进程不足或请求过载
  • 症状：高峰期或并发上来后 502。
  • 修复：调大 pm.max_children，并合理设置 pm.start_servers / pm.min_spare_servers / pm.max_spare_servers；可按内存估算：每个 PHP 进程约 20MB，如 4GB 内存可设到约 150，8GB 可设到约 300（需结合实际业务与数据库等资源占用）。
• 执行/响应超时
  • 症状：长脚本或慢接口 502。
  • 修复：在 php.ini 提高 **max_execution_time`（如 300 秒）；在 PHP-FPM 设置 request_terminate_timeout（如 300 秒或更高，视业务而定）；在 Nginx 适当增大 fastcgi_connect_timeout / fastcgi_send_timeout / fastcgi_read_timeout。
• 扩展/模块冲突
  • 症状：升级或新增扩展后出现 502。
  • 修复：注释冲突扩展逐一排查（如 eAccelerator 与 Zend Optimizer 顺序问题，或 Zend GuardLoader 与 Opcache/ionCube 冲突等）。
• 磁盘空间耗尽
  • 症状：服务启动缓慢或失败、502。
  • 修复：df -h 定位大文件，清理 /var/log、应用日志、数据库日志等，再重启服务。
• 虚拟主机日志过大
  • 症状：访问变慢、偶发 502。
  • 修复：定期轮转/清空虚拟主机日志，避免单个日志文件过大影响性能。
• 代码问题（死循环/内存泄漏）
  • 症状：个别 URL 必现 502。
  • 修复：临时注释可疑路由/插件，开启 slowlog 定位慢脚本，优化代码或限制内存。

三、关键配置示例

• Nginx 虚拟主机片段（TCP 方式示例）

  server {
      listen 80;
      server_name example.com;
      root  /data/www;
      index index.php index.html;
  
      location ~ \.php$ {
          include        fastcgi_params;
          fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
          fastcgi_pass   127.0.0.1:9000;
          fastcgi_connect_timeout 300s;
          fastcgi_send_timeout    300s;
          fastcgi_read_timeout    300s;
      }
  }
  

• PHP-FPM 片段（与 Nginx 保持一致）

  [www]
  listen = 127.0.0.1:9000
  user = php-fpm
  group = php-fpm
  pm = dynamic
  pm.max_children = 150
  pm.start_servers = 20
  pm.min_spare_servers = 20
  pm.max_spare_servers = 35
  pm.max_requests = 500
  request_terminate_timeout = 300
  

• 使用 Unix Socket 时的要点
  • PHP-FPM：listen = /tmp/php-cgi.sock，并设置 listen.owner/listen.group 与 Nginx worker 一致（如 nobody）。
  • Nginx：fastcgi_pass unix:/tmp/php-cgi.sock;。
  • 两者路径、权限必须一致，否则必现 502。

四、维护与预防建议

• 监控与告警：监控 502 比例、PHP-FPM 进程数/队列、响应时延、磁盘空间，超过阈值及时告警。
• 日志与诊断：保留并定期归档 Nginx/PHP-FPM 日志；疑难问题开启 slowlog 与临时 debug 级别排查。
• 资源规划：按内存与业务复杂度合理设置 pm.max_children 与超时参数，避免“一刀切”。
• 变更管控：变更扩展/主题/配置先在测试环境验证，变更后观察 502 与错误日志。
• 自动恢复：在极端情况下可配置自动重启脚本作为兜底，但根本仍需修复根因。