Nginx的env指令仅控制worker进程继承系统环境变量，必须置于main上下文顶层，不能用于proxy_pass、root等指令的动态值替换，也不提供$VAR变量引用能力。
Nginx 的 env 指令不能让配置项（如 proxy_pass、root）动态读取环境变量值，它唯一作用是：在 Master 进程启动 Worker 进程时，把指定的系统环境变量“继承”过去。这个机制对后端动态语言（如 PHP、Python、Node.js）也有效——只要它们运行在 Nginx 子进程中（例如通过 fastcgi_pass 或 proxy_pass 转发），且该子进程由 Nginx fork 启动（如 PHP-FPM 独立运行则不受影响）。
env 指令必须写在 nginx.conf 最顶层（main 上下文）
只有放在全局块最外层才合法，其他位置都会报错：
- ✅ 正确写法（nginx.conf 开头）：
env APP_ENV;
env API_HOST;
env DATABASE_URL; - ❌ 错误写法：
http { env APP_ENV; }→ 报错 “env directive is not allowed here”server { env API_HOST; }→ 同样非法
env 不等于变量引用，Worker 进程能读到 ≠ 配置里能写 $APP_ENV
即使你写了 env APP_ENV;，也不能在配置中这样用：
-
set $stage $APP_ENV;→ 语法错误：“unknown variable” -
proxy_set_header X-Stage $APP_ENV;→ 不生效，Nginx 不识别该变量名 -
root /var/www/$APP_ENV;→ 启动失败或被当作文本字面量处理
它的效果仅限于：Worker 进程内部可通过 getenv("APP_ENV")（C）、os.environ.get("APP_ENV")（Python）等方式读取——但前提是该进程由 Nginx 直接 fork，而非独立守护进程。
向后端动态语言透传变量的实际路径
是否生效，取决于后端服务如何启动和通信：
-
FastCGI 场景（如 PHP）：Nginx 通过
fastcgi_param显式传递变量，env指令本身不自动注入。需配合：fastcgi_param APP_ENV $ENV{APP_ENV};（注意是$ENV{VAR}，不是$VAR） -
反向代理场景（如 Node.js/Python Web Server）：Nginx 本身不修改后端进程环境，
env对其无效；真正起作用的是你在启动后端服务时传入的-e参数（Docker）或 systemd 环境配置。 -
嵌入式模块（如 ngx_http_perl_module 或 lua）：可直接使用
$ENV{VAR}读取已声明的 env 变量，用于日志、响应头等上下文。
常见误区与验证方法
别假设写了 env VAR; 就万事大吉。务必验证实际效果：
- 检查 Worker 进程是否真携带该变量：
ps aux | grep nginx找 worker 进程 PID，再执行：cat /proc/[PID]/environ | tr '\0' '\n' | grep APP_ENV - 若返回空，说明
env未生效——可能因变量未 export（Docker 中必须-e APP_ENV=prod，不能小写）、或镜像启动方式绕过了 Nginx 主进程（如自定义 entrypoint 直接 exec nginx -g ... 而非调用原生 docker-entrypoint.sh） - PHP-FPM 等独立服务不会继承 Nginx 的
env，必须单独配置其环境（如env[APP_ENV] = prod在 www.conf 中）
