一次 Nginx 音频 403 问题的完整排查与复盘（Docker 场景）

背景 #

在今天工作时碰到了一个非常奇怪的问题：

• 明明后端接口正常返回了音频文件的访问链接
• 但在页面或播放器中请求该链接时，直接返回 403
• 且接口本身无任何异常日志

然后我经过同事的指导：

• 将 Nginx 配置修改为 user root 时，一切正常
• 改成普通用户（如 user user）后，音频请求立刻 403

运行环境说明 #

宿主机
 └── Docker
      └── nginx 容器
           ├── nginx master（root）
           └── nginx worker（由 user 指令决定）

也就是说：

• Nginx 运行在 Docker 容器中
• 实际读音频文件的是 nginx worker 进程
• worker 的 Linux 用户由 nginx.conf 中的 user 指令决定

初步排查过程 #

1. 检查 Nginx 状态 #

systemctl status nginx 主要用于确认：

• 是否存在宿主机 nginx
• 理清当前环境的 nginx 来源

最终确认：真正提供服务的是 Docker 容器内的 nginx。

2. 修改 Nginx 配置并 reload #

在经理的帮助下，修改 nginx 配置，将：

user nginx;

改为：

user root;

并通过以下命令重新加载配置（在运行中的 Nginx 容器内）：

docker exec -it nginx nginx -s reload

说明：该命令向容器内 Nginx 的 master 进程发送 reload 信号，使其重新加载配置，不中断服务。

关键结论 #

这不是接口 403，而是 Nginx 文件系统权限导致的 403。

为什么 user root 没问题？ #

• 当 user root 时，nginx worker 进程以 root 身份运行
• root 可以无视大部分文件权限限制
• 即使文件或目录权限不正确，也能成功读取

为什么普通用户会 403？ #

• nginx worker 以普通用户运行
• 对音频文件或其父目录没有读取 / 执行权限
• Linux 返回 Permission denied
• Nginx 将其映射为 HTTP 403

为什么接口能返回链接，但访问链接失败？ #

这是本次问题中最迷糊的点。

两个进程、两套权限体系，互不相干。

经验总结 #

本次问题的核心收获：

1. HTTP 403 并不一定是接口权限问题
2. Nginx 静态资源访问直接依赖 Linux 文件权限
3. user root 能跑 ≠ 配置是正确的
4. Docker 容器内的服务不能用 systemctl 管理