在美国AMD服务器上遇到 Nginx 403，并不意味着 CPU、系统负载或服务器硬件异常。很多情况下，请求已经到达 Nginx，但 Nginx 的工作进程无法穿过某一级父目录、读取目标文件，或者 Nginx 配置主动拒绝了请求。尤其是主进程以 root 身份运行时，不能据此判断静态文件也拥有 root 权限。

建议按照“错误日志 → 实际匹配的 Nginx 配置 → 工作进程身份 → 路径逐级权限 → SELinux/AppArmor → 最小权限修复 → 请求验证”的顺序排查。先定位 403 的生成位置，再修改权限，避免直接执行 chmod -R 777 或把整个网站目录交给 Nginx 用户。

先判断403由谁返回

从错误日志确认现象

Linux 环境下可以先查看 systemd 日志和 Nginx 错误日志：

sudo journalctl -u nginx -n 80 --no-pager

如果 Nginx 使用独立日志文件，再查看常见日志位置：

sudo tail -n 80 /var/log/nginx/error.log

实际日志路径以 error_log 配置为准，可以从完整配置中确认：

sudo nginx -T 2>/dev/null | grep -nE '(^|[[:space:]])error_log[[:space:]]'

不同日志内容对应的处理方向不同：

如果是反向代理配置，Nginx 本身未必在读取本地目录。此时不能仅修改静态目录权限，应先确认 403 是本地 Nginx 生成，还是上游应用返回。

核对实际生效的路径和规则

403 排查不能只看某个配置文件中的 root。Nginx 可能因为请求域名、URI 或 location 匹配结果，使用了另一个 root、alias 或访问规则。

可以先筛选关键配置：

sudo nginx -T 2>/dev/null | grep -nE '(^|[[:space:]])(root|alias|index|deny|allow|internal|disable_symlinks)[[:space:]]'

重点确认以下内容：

• 请求使用的域名是否进入了预期的 server；
• URI 最终匹配了哪个 location；
• root 或 alias 计算出的真实文件路径是什么；
• 是否存在 deny all、allow、internal 等主动拒绝规则；
• 目录请求是否配置了正确的 index 文件；
• 是否启用了 disable_symlinks，导致符号链接访问被限制。

例如，静态站点通常需要明确的索引文件：

server {
    root /srv/www/example/public;
    index index.html index.htm;

    location / {
        try_files $uri $uri/ =404;
    }
}

修改配置前，先保存原配置；修改后必须执行语法检查。仅修改文件权限时通常不需要 reload，但修改了 Nginx 配置就不能跳过检查。

确认Nginx实际使用的服务用户

区分主进程和工作进程

Nginx 常见运行方式是主进程负责管理，工作进程负责处理请求。主进程可能由 root 启动，工作进程则降权为 nginx、www-data 或其他账号。因此，真正需要读取网站文件的通常是工作进程身份。

查看当前进程：

ps -o user=,group=,pid=,ppid=,args= -C nginx

也可以查看完整进程列表：

pgrep -a nginx

如果 Nginx 尚未启动，查看配置中的 user 指令：

sudo nginx -T 2>/dev/null | grep -nE '^[[:space:]]*user[[:space:]]'

systemd 还可能对整个服务设置 User= 或 Group=：

sudo systemctl show nginx -p User -p Group -p DynamicUser

当输出中的 User= 为空时，通常表示 systemd 没有单独覆盖用户，仍需结合 Nginx 的 user 指令和 ps 输出判断。不要仅凭发行版名称猜测服务用户，必须以当前进程为准。

确认账号和附属组：

NGINX_USER=nginx
getent passwd "$NGINX_USER"
id "$NGINX_USER"

将 NGINX_USER=nginx 替换为前面实际查到的账号。如果工作进程使用的是 www-data，就应改为：

NGINX_USER=www-data
id "$NGINX_USER"

用服务身份直接测试读取能力

假设站点根目录为 /srv/www/example/public，目标文件为 /srv/www/example/public/index.html，可以使用与 Nginx 工作进程相同的账号进行测试：

APP_ROOT=/srv/www/example/public
TARGET="$APP_ROOT/index.html"

sudo -u "$NGINX_USER" -- test -x "$APP_ROOT"
echo "目录访问状态：$?"

sudo -u "$NGINX_USER" -- test -r "$TARGET"
echo "文件读取状态：$?"

返回状态为 0 表示测试通过，非 0 表示失败。这个测试比直接使用 root 执行 cat 更有意义，因为 root 读取成功不能证明 Nginx 工作进程也能读取。

按目录层级检查权限

理解文件和目录权限的区别

Linux 权限在 Nginx 访问路径时通常需要同时满足以下条件：

• 文件的读取权限 r：允许读取 HTML、CSS、图片等内容；
• 目标文件所在目录及所有父目录的执行权限 x：允许穿过目录找到目标文件；
• 目录的读取权限 r：涉及列出目录内容时需要，目录索引和自动目录列表场景尤其容易受影响；
• ACL、SELinux 或 AppArmor 没有额外拒绝访问。

例如，/srv/www/example/public/index.html 能否访问，不只取决于 index.html 的权限，还取决于 /srv、/srv/www、/srv/www/example 和 public 每一级目录。

使用 namei 查看完整路径上的所有权限：

namei -l "$TARGET"

再查看目标文件和目录的所有者、组及数字权限：

stat -c '%A %a %U:%G %n' \
    /srv \
    /srv/www \
    /srv/www/example \
    "$APP_ROOT" \
    "$TARGET"

如果系统启用了 ACL，还要查看 ACL 内容：

getfacl -p \
    /srv/www/example \
    "$APP_ROOT" \
    "$TARGET"

仅看到 ls -l 中的 rwx 并不一定足够。ACL 的有效权限可能被 mask 限制，也可能额外授予或拒绝某个用户。

可以针对路径上的关键目录和文件执行服务用户测试：

sudo -u "$NGINX_USER" -- test -x /srv/www/example
sudo -u "$NGINX_USER" -- test -x "$APP_ROOT"
sudo -u "$NGINX_USER" -- test -r "$TARGET"

测试结果的判断方式如下：

• 父目录 test -x 失败：先修复目录穿越权限，文件本身即使是 644 也无法访问；
• 目录测试通过、文件 test -r 失败：检查文件所有者、用户组、ACL 和文件权限；
• 文件读取测试通过但仍返回 403：优先回到 Nginx 的 location、deny、index 和安全模块排查；
• 直接访问文件成功、访问目录地址失败：重点检查索引文件是否存在且可读，不要急于开启目录列表。

按最小权限修复目录

优先使用专用用户组

如果网站目录是独立的公开发布目录，可以让 Nginx 工作进程通过专用组获得只读权限。下面的命令仅适用于已经确认可以公开读取的站点目录，执行前应替换用户、用户组和路径。

APP_ROOT=/srv/www/example/public
NGINX_USER=nginx
NGINX_GROUP=nginx

先保存权限和 ACL 状态，便于回滚：

BACKUP=/root/nginx-permission-backup
sudo mkdir -p "$BACKUP"

sudo getfacl -R -p "$APP_ROOT" | \
    sudo tee "$BACKUP/public.acl" >/dev/null

对专用的公开目录授予用户组读取和目录穿越权限：

sudo find "$APP_ROOT" -type d \
    -exec chgrp "$NGINX_GROUP" {} +

sudo find "$APP_ROOT" -type d \
    -exec chmod g+rx {} +

sudo find "$APP_ROOT" -type f \
    -exec chgrp "$NGINX_GROUP" {} +

sudo find "$APP_ROOT" -type f \
    -exec chmod g+r {} +

这组命令会递归修改指定目录下的组归属和组权限，因此不能对包含数据库密码、私钥、应用配置或用户上传私密数据的混合目录直接使用。更稳妥的做法是把可公开发布内容放在单独的 public 目录中，应用运行时目录和密钥目录保持隔离。

如果只是单个目录或文件缺少权限，可以缩小变更范围：

sudo chgrp "$NGINX_GROUP" "$APP_ROOT"
sudo chmod g+rx "$APP_ROOT"

sudo chgrp "$NGINX_GROUP" "$TARGET"
sudo chmod g+r "$TARGET"

同时还要根据 namei -l 的结果，给缺少执行权限的父目录补充最小的 x 权限。不要为了排查方便把整个路径改成 777，也不要在不确认应用写入需求的情况下执行 chown -R nginx。Nginx 提供静态文件时通常只需要读取权限，不需要对网站目录拥有写权限。

无法改组时使用精确ACL

如果网站文件必须保持原有用户组，可以对 Nginx 用户授予精确 ACL。先确保父目录允许穿越：

sudo setfacl -m "u:${NGINX_USER}:--x" /srv/www/example
sudo setfacl -m "u:${NGINX_USER}:rx" "$APP_ROOT"
sudo setfacl -m "u:${NGINX_USER}:r--" "$TARGET"

如果站点包含多个子目录和文件，可以仅对公开发布树设置只读 ACL：

sudo find "$APP_ROOT" -type d \
    -exec setfacl -m "u:${NGINX_USER}:rx" {} +

sudo find "$APP_ROOT" -type f \
    -exec setfacl -m "u:${NGINX_USER}:r--" {} +

设置后重新查看：

getfacl -p "$APP_ROOT" "$TARGET"

确认 ACL 中的用户权限没有被 mask 限制。ACL 的优势是不会强行改变文件主用户，但它也会增加后续维护复杂度，部署脚本需要同时考虑传统权限和 ACL。

如果修复后产生意外影响，可在确认没有其他进程同时修改该目录的前提下恢复之前的 ACL 和权限：

sudo setfacl --restore=/root/nginx-permission-backup/public.acl

该回滚只针对保存快照时存在的路径；新创建的文件不会因为回滚命令自动恢复，因此生产环境应避免在变更期间同时进行大规模发布。

排查SELinux或AppArmor的额外限制

当 namei、stat、getfacl 和服务用户测试都显示正常，但 Nginx 仍记录 Permission denied，需要检查强制访问控制。

如果系统安装并启用了 SELinux：

getenforce
ls -Zd "$APP_ROOT" "$TARGET"
sudo ausearch -m AVC -ts recent | tail -n 30

只有在 AVC 日志明确对应当前 Nginx 请求，且文件标签不符合策略时，才考虑恢复标签：

sudo restorecon -Rv "$APP_ROOT"

restorecon 会改变指定目录的安全标签，执行前应记录当前标签，并将范围限制在实际站点目录。不要用随意的 chcon 长期掩盖策略问题；自定义站点路径应按照当前发行版的 SELinux 策略配置持久化文件上下文。

如果系统使用 AppArmor，可以查看状态和内核拒绝记录：

sudo aa-status
sudo journalctl -k --no-pager | grep -i 'apparmor.*denied'

这类拒绝不一定能从普通 Unix 权限中看出来。确认是安全策略导致后，应调整对应策略，而不是继续放宽目录权限。

修复后的验证顺序

先验证文件系统，再验证HTTP

重新以 Nginx 服务用户测试目标路径：

sudo -u "$NGINX_USER" -- test -x "$APP_ROOT" &&
sudo -u "$NGINX_USER" -- test -r "$TARGET" &&
echo "服务用户可以读取目标文件"

如果修改过 Nginx 配置，执行语法检查：

sudo nginx -t

检查通过后再平滑重载：

sudo systemctl reload nginx

纯粹修改文件所有者、组或权限时，通常不需要 reload；如果权限已恢复但 Nginx 仍返回旧结果，可在确认服务影响范围后再检查进程和缓存配置。

最后使用与故障相同的域名、路径和请求方法验证：

curl -sS -D - -o /dev/null https://example.com/path/

同时测试目录地址和具体文件地址：

curl -sS -o /dev/null -w '目录请求 HTTP %{http_code}\n' \
    https://example.com/path/

curl -sS -o /dev/null -w '文件请求 HTTP %{http_code}\n' \
    https://example.com/path/index.html

如果具体文件返回 200、目录地址仍返回 403，通常说明权限已经恢复，剩余问题在索引文件、index 指令或目录列表行为。如果服务用户的 test -r 仍失败，应继续处理父目录、组成员关系或 ACL，而不是反复 reload Nginx。

需要注意，以上步骤适用于 Nginx 直接读取 Linux 文件系统中的静态内容。若 Nginx 运行在容器中，宿主机显示的用户名可能只是数字 UID，必须在实际运行 Nginx 的容器或同一命名空间内确认进程身份和挂载路径。只有当错误日志、服务用户测试、路径权限和最终 HTTP 响应相互对应时，才能判断美国AMD服务器上的这次 403 已经真正解决。