未分类

Nginx 502 Bad Gateway 排查实战：一个 /tmp 目录权限引发的血案

blueideaPost a Comment

2026年7月12日早上，突然发现 todo.yuekegu.com 无法访问，浏览器直接显示 502 Bad Gateway。于是开始了一场排查之旅，最终发现罪魁祸首竟然是 —— /tmp 目录权限被改了。

一、问题现象

  • 浏览器访问 https://todo.yuekegu.com 返回 502 Bad Gateway
  • DNS 解析正常，域名指向 118.25.211.245
  • SSL 证书正常，TLS 握手成功
  • 同服务器的 https://grader.yuekegu.com 访问正常

二、排查过程

第一步：确认502来源

用 curl 测试，返回 502：

$ curl -sI https://todo.yuekegu.com
HTTP/2 502

DNS 解析正常，指向服务器 IP，说明问题出在服务器内部。

第二步：查看 Nginx 错误日志

/www/wwwlogs/todo.yuekegu.com.error.log 中报大量如下错误：

connect() to unix:/tmp/php-cgi-82.sock failed (13: Permission denied) 
while connecting to upstream

错误码 13 即 EACCES，表示 Nginx worker 进程没有权限连接 PHP-FPM 的 Unix socket。

第三步：分析权限配置

Nginx 与 PHP-FPM 都以 www 用户运行，按理说应该没问题：

  • user www www （Nginx 配置）
  • user = www; group = www （PHP-FPM 配置）
  • listen.mode = 0600 （PHP-FPM socket 权限，仅所有者可读写）
  • Socket 文件 /tmp/php-cgi-82.sock 所有者为 www

从配置上看完全合理，为何会 Permission denied？

第四步：深入测试

用 Python 测试 socket 连接：

# 以 root 执行 — 成功
$ python3 -c "import socket; s=socket.socket(...); s.connect('/tmp/php-cgi-82.sock')"
ROOT CONNECTED OK

# 以 www 执行 — 失败！
$ su -s /bin/sh www -c 'python3 -c "..."'
PermissionError: [Errno 13] Permission denied

同样用户、socket 也是 0660，为何 www 自己连不上？

第五步：发现根因

检查 /tmp 目录权限：

$ ls -la /
drwx------ 18 root root 94208 Jul 12 07:45 tmp

破案了！ 标准的 Linux /tmp 目录权限应为 drwxrwxrwt（即 1777，带 sticky bit），但这里被改成了 drwx------（700），只有 root 能进入该目录。

Nginx worker 虽然是 www 用户，但要连接到 /tmp/php-cgi-82.sock，必须先能进入 /tmp 目录。目录本身不可访问，socket 文件权限再对也没用！

升级 socket 权限为何无效

一开始尝试将 listen.mode 从 0600 改为 0666 也没解决，因为问题不在 socket 文件本身，而是 通往 socket 的路 被堵住了。Unix socket 的访问受路径上所有目录的权限控制。

三、解决方案

修复 /tmp 目录权限为正确值即可：

chmod 1777 /tmp
ls -la / | grep tmp
# 输出: drwxrwxrwt ... tmp

修复后立即验证：

# 测试 www 用户连接 socket
$ su -s /bin/sh www -c 'python3 -c "..."'
WWW CONNECTED OK after fix

# 测试网站
$ curl -sI https://todo.yuekegu.com
HTTP/2 200

站点恢复正常！

四、经验总结

  1. Unix Socket 权限有两层：不仅要检查 socket 文件本身的权限，还要检查路径上所有目录的权限。
  2. Permission denied (13) ≠ socket 文件权限问题：很多时候是路径目录不可达。
  3. /tmp 权限：标准应为 1777（drwxrwxrwt），切勿随意修改。
  4. 排查套路：DNS → Nginx 配置 → 错误日志 → 后端进程 → 文件权限，逐层深入。
  5. /tmp 权限异常可能是被恶意篡改，修复后建议排查安全日志确认是否有入侵迹象。

这个案例看似简单，但 /tmp 目录权限被改这种问题很不常见，容易让人在 socket 权限上绕圈子。记录于此，供运维同参考。

blueidea

Leave A Comment

Recommended Posts