nginx 的 root 指令不支持环境变量，配置中如 root /var/www/$app_env; 中的 $app_env 不会被解析，而是作为字面路径使用，导致 403 或 404 错误；官方明确 root 和 alias 均不支持运行时变量，仅 map、set、proxy_pass 等少数指令支持。
在 Nginx 中，root 指令不支持直接使用环境变量（如 $ENV_VAR），若配置中误写了类似 root /var/www/$APP_ENV;，Nginx 启动时**不会报错**，但实际请求会返回 403 或 404 —— 因为它把未展开的字符串当作了字面路径（例如尝试访问 /var/www/$APP_ENV/index.html）。
确认 root 是否真的不支持环境变量
Nginx 官方明确说明：只有部分指令支持变量（如 set、rewrite、return、proxy_pass 等），而 root 和 alias 均不支持运行时变量解析。即使你用 env APP_ENV=prod; 在 nginx.conf 里声明，或通过系统环境启动，root 行里的 $APP_ENV 也始终是原样字符串，不会被替换。
快速验证当前 root 路径是否生效
不要只看配置文件，要查 Nginx 实际解析出的路径：
- 用
nginx -T输出完整生效配置（含 include 展开），搜索root行，确认变量是否还“挂着” - 在对应 location 中临时加一行日志，记录请求 URI 和文档根路径：
log_format debug '$remote_addr - $request_uri → root: "/var/www/$APP_ENV"';
（注意：这里$APP_ENV不会展开，仅用于观察是否被当作字面量写入日志） - 更可靠的方式：在 location 中用
add_header把真实路径“回显”到响应头（需配合root的静态值）：add_header X-Root-Path "/var/www/prod";
然后用curl -I查看响应头，确认你期望的路径是否一致
正确传递环境化路径的三种方法
方法一：启动前用模板工具生成配置
用 envsubst、sed 或 confd 等工具，在容器启动或部署阶段把变量替换成真实值：
env APP_ENV=prod envsubst /etc/nginx/conf.d/site.conf
模板中写：root /var/www/${APP_ENV};（注意用 ${} 更安全）
方法二：用 map 指令做运行时映射（推荐）
虽然 root 本身不支持变量，但你可以用 map 预定义路径映射，再在 root 中引用变量名：
map $http_host $app_root {
~^prod\.example\.com$ /var/www/prod;
~^staging\.example\.com$ /var/www/staging;
default /var/www/dev;
}
server {
location / {
root $app_root; # ✅ 这里 $app_root 是 map 计算出的纯字符串，合法
}
}
方法三：用 set + try_files 绕过 root（适用于简单场景）
如果只是想按条件选不同目录，可改用 try_files 显式拼接路径（需开启 disable_symlinks 安全限制时谨慎使用）：
set $base_path "/var/www";
location / {
try_files $uri $uri/ =404;
# 再用 rewrite 或内部重定向配合 alias（不推荐复杂逻辑）
但注意：alias 也不支持变量，所以该方式通常只适合固定路径切换，不如 map 清晰可靠。
常见误判点：别把 error_log 级别调太高就以为没报错
Nginx 对未解析变量的 root 行完全静默，既不 warning 也不 error。即使你设了 error_log /var/log/nginx/error.log debug;，也不会输出变量相关提示。真正有用的线索往往藏在 access log 的状态码和响应体里：
- 403 Forbidden：通常是路径存在但无读权限 → 检查 Nginx worker 用户能否访问那个“字面量路径”（比如是否有
$APP_ENV这个子目录） - 404 Not Found：路径根本不存在 → 说明 Nginx 正在找一个带美元符的目录名，比如
/var/www/$APP_ENV - 用
strace -p $(pgrep nginx) -e trace=openat可实时看到 Nginx 尝试打开哪些物理路径，最直接定位问题
