500错误由权限拒绝（13: permission denied）导致，需确认nginx运行用户（如www-data）、检查报错路径的属主与权限（目录需x、文件需r、上传目录需w），并执行chown -r、chmod 644/755/775等精准授权后重启服务。
看到 Nginx 错误日志里出现 500 Internal Server Error，且日志中反复出现 "Permission denied"（权限拒绝）或错误码 13，基本可以锁定是文件或目录权限配置不当导致访问受阻。这类问题不难解决，关键在于快速识别具体哪个路径、哪个用户出了问题。
看懂错误日志里的权限线索
打开 /var/log/nginx/error.log，重点找含以下关键词的行：
-
open() "/var/www/html/wp-config.php" failed (13: Permission denied)→ 明确指出被拒绝访问的具体文件路径 -
stat() "/var/www/html/wp-content" failed (13: Permission denied)→ 目录不可读/不可执行（缺少 x 权限） -
connect() to unix:/run/php/php8.2-fpm.sock failed (13: Permission denied)→ PHP-FPM 套接字权限不对，常因用户/组不匹配
注意括号里的 (13: Permission denied) 是 Linux 系统级错误码，不是 Nginx 自定义提示，可信度极高。
确认 Nginx 实际运行用户
权限是否合法，取决于“谁在运行 Nginx”和“谁拥有目标文件”。不能只看配置文件里写的 user，要查真实进程：
- 运行
ps aux | grep nginx，找 master 进程那一行，第二列就是实际运行用户（如www-data或nginx） - 再检查
/etc/nginx/nginx.conf开头的user指令，确保两者一致；若不一致，以ps结果为准 - 特别注意：如果用 systemd 启动，还可能受
/lib/systemd/system/nginx.service中的User=设置覆盖
检查目标路径的权限与归属
拿到报错路径后，逐级检查每一层目录和最终文件：
- 执行
ls -ld /var/www/html→ 根目录需有 x（执行）权限，否则用户无法进入该目录（即使有 r 权限也不行） - 执行
ls -l /var/www/html/index.php→ PHP 文件需有 r（读）权限，推荐644 - 执行
ls -l /run/php/→ 若报 sock 权限错，确认该目录属主是www-data:www-data，权限为755；sock 文件本身应为660，组为www-data
常见陷阱：上传目录（如 /wp-content/uploads）需要 w（写）权限，但不能盲目设 777；建议用 775 + 正确组归属更安全。
修正权限并验证
修复不是简单 chmod 一遍，而是按角色精准授权：
- 统一属主：
sudo chown -R www-data:www-data /var/www/html（把整个网站目录交给运行用户） - 收紧文件权限：
find /var/www/html -type f -exec chmod 644 {} \; - 放开目录权限：
find /var/www/html -type d -exec chmod 755 {} \; - 单独处理上传目录：
chmod 775 /var/www/html/wp-content/uploads - 改完后重启服务：
sudo systemctl restart nginx php8.2-fpm（PHP 版本按实际调整）
