Nginx无法直接在配置中用$ENV引用系统环境变量；可行方案是：客户端通过X-Env头传递环境标识，Nginx用map指令映射为后端地址或新请求头，实现安全、动态的多环境路由与透传。
Linux 下 Nginx 不能直接读取系统环境变量（如 export ENV=prod）并在配置中用 $ENV 拼接请求头，因为 Nginx 启动时就完成配置解析，而系统环境变量在运行时才存在，且 Nginx 默认不暴露它们为配置变量。
用 map + 自定义请求头实现“类环境变量”动态转发
真正可行、安全、线上常用的方式是：让客户端（或上游网关）通过请求头（如 X-Env）显式传递环境标识，Nginx 用 map 提取并映射为后端地址或新请求头值：
- 在
http块顶层定义映射，例如：
default "http://default.internal/";
"staging" "http://staging-api.internal/";
"prod" "http://prod-api.internal/";
}
- 在
location中使用该变量做代理和头设置：
proxy_pass $target_backend;
proxy_set_header X-Env $http_x_env;
proxy_set_header X-Forwarded-Env $http_x_env;
}
这样，客户端发 curl -H "X-Env: prod" https://example.com/api/，Nginx 就自动路由到生产后端，并透传该环境标识。
如果必须注入系统级环境标识（极少数运维场景）
可通过启动时模板化配置实现——不是运行时拼接，而是预生成：
- 用 shell 脚本读取
ENV，替换 Nginx 配置中的占位符，再重载：
- 配置中写成：
proxy_set_header X-Deploy-Env "{ENV}"; - 注意：这属于部署期静态注入，每次改环境都要重载配置，不适用于请求粒度的动态切换。
不推荐也不可行的方式
以下操作均无效或危险，应避免：
-
在配置里直接写
$ENV或${ENV}：Nginx 不识别，会当作字面量或报错； -
用
if + set试图从$http_*外提取系统变量：Nginx 无对应内置变量，set仅支持常量或已有变量； - 依赖 Lua 或 OpenResty 动态读取 os.getenv()：虽技术上可行，但引入额外模块、增加攻击面和维护成本，违背轻量代理设计原则，非必要不采用。
补充：如何让后端看到“拼接后的头”
若需把环境名和其他字段组合成新头（如 X-App-ID: myapp-prod-v2），可用 map 多级嵌套或 concat 模块（需编译支持），但更通用的做法是：
- 用两个独立
map分别提取$http_x_app和$http_x_env； - 再用第三个
map组合（支持字符串拼接，Nginx ≥1.11.6）：
default "";
"myapp:prod" "myapp-prod";
"myapp:staging" "myapp-staging";
}
然后 proxy_set_header X-App-ID $x_app_id;
