Ubuntu Nginx如何解决502错误 - 问答

Ubuntu 上 Nginx 出现 502 的排查与修复

一、快速定位

查看 Nginx 错误日志：sudo tail -f /var/log/nginx/error.log，优先寻找关键词：connect() failed (111: Connection refused)、upstream timed out (110: Connection timed out)、Permission denied。这些分别对应上游未启动/不通、超时、权限问题。
验证 Nginx 配置语法：sudo nginx -t，确保修改后配置无语法错误。
检查 上游服务状态（以 PHP-FPM 为例）：sudo systemctl status php8.1-fpm（版本号按实际），必要时 sudo systemctl restart php8.1-fpm。
测试与上游的 端口/套接字连通性：ss -lntp | grep :9000 或 curl http://127.0.0.1:9000；若用 Unix socket，确认文件存在且权限正确。
复核 防火墙/安全组：sudo ufw status、sudo iptables -L -n，确保 9000 或对应端口开放。
以上步骤能覆盖大多数 502 的根因：上游未起、网络不通、配置错误、权限不足。

二、PHP-FPM 专项排查与修复

核对 Nginx 与 PHP-FPM 的通信方式一致：
- TCP 方式：fastcgi_pass 127.0.0.1:9000;
- Unix socket 方式：fastcgi_pass unix:/run/php/php8.1-fpm.sock;（路径随版本/发行版可能不同）。
在 PHP-FPM 池配置 中确保监听与权限匹配（/etc/php/8.1/fpm/pool.d/www.conf）：
- listen = /run/php/php8.1-fpm.sock
- listen.owner = www-data、listen.group = www-data、listen.mode = 0660
若使用 TCP，确认 PHP-FPM 确实监听 9000：ss -lntp | grep :9000；若使用 socket，确认文件存在且属主为 www-data。
调整 进程与超时（避免进程耗尽或执行过慢被中断）：
- 增大 pm.max_children（如从默认提升到更高值，需结合内存评估）。
- 视情况调整 request_terminate_timeout、max_execution_time，并与 Nginx 的 FastCGI 超时保持协调。
重启生效：sudo systemctl restart php8.1-fpm && sudo systemctl reload nginx。
以上措施解决“协议/地址不匹配、权限不对、进程不足、执行超时”等高频问题。

三、反向代理场景的要点（Node.js、Tomcat、Gunicorn 等）

核对 proxy_pass 目标地址与端口 是否正确，示例：
- proxy_pass http://127.0.0.1:3000;
- 按需设置请求头：proxy_set_header Host $host;
调整超时，避免偶发 502：
- proxy_connect_timeout 60s;、proxy_read_timeout 60s;
若后端偶尔无可用实例，检查 upstream 配置 与后端健康；日志可能出现 no live upstreams while connecting to upstream。
排查 网络/防火墙 与 资源限制（CPU、内存、文件描述符）。
这些配置直接决定 Nginx 与上游的握手与读超时行为。

四、权限与安全模块

网站目录与文件权限（以 /var/www/html 为例）：
- sudo 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 {} \;
AppArmor（Ubuntu 常见）：
- 检查拒绝日志：dmesg | grep apparmor
- 必要时临时禁用某策略做验证：sudo ln -s /etc/apparmor.d/usr.sbin.php-fpm /etc/apparmor.d/disable/ && sudo apparmor_parser -R /etc/apparmor.d/usr.sbin.php-fpm
如启用 SELinux，核对上下文或临时 setenforce 0 做排查（生产环境慎用）。
权限/安全策略不当常导致 Permission denied 类 502。

五、常见现象与对应修复对照表

现象与日志关键词	可能原因	快速修复
`connect() failed (111: Connection refused)`	上游未启动/端口不对	启动上游（如 `systemctl start php8.1-fpm`），核对 `fastcgi_pass` 或 `proxy_pass` 地址与端口
`upstream timed out (110: Connection timed out)`	上游响应慢/超时过短	增加 `proxy_read_timeout` 或 FastCGI 超时；优化上游性能
`Permission denied`	文件/目录或 socket 权限不对	`chown www-data:www-data`、`chmod 755/644`；核对 `listen.mode=0660`
`No such file or directory`（FastCGI）	`SCRIPT_FILENAME` 或 `root` 路径错误	修正 `root` 与 `fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;`
`no live upstreams while connecting to upstream`	upstream 列表为空/后端全挂	检查 upstream 配置与后端健康状态
高并发间歇 502	进程数不足/内存不足	调大 `pm.max_children`，提升 `memory_limit`，必要时扩容

以上条目覆盖了 连接被拒绝、超时、权限、配置路径、上游不可用、资源不足 等典型场景。

0 赞

0 踩