多环境nginx cors白名单应通过map指令+环境变量或独立配置文件实现分层管理，禁用*+credentials组合，按环境精确匹配origin并确保错误响应携带cors头。
在多环境（开发、测试、生产）中自动化管理 Nginx CORS 白名单，核心是避免硬编码、实现配置分离与运行时动态加载，同时保障安全性——尤其不能让开发环境的 localhost 泄露到生产，也不能因白名单错配导致带凭证请求失败。
用 map 指令 + 环境变量或独立配置文件做白名单分层
推荐在 http 块顶部统一定义 map，通过 Nginx 变量（如 $env）或 include 机制区分环境：
- 在主配置中设置环境标识，例如：
env DEV; # 或通过 systemd / docker env 注入
或更稳妥地，在启动前用脚本生成含环境变量的 conf 片段 - 为每个环境准备白名单映射：
map $http_origin $cors_origin {<br> default "";<br> ~*^https?://localhost(:\d+)?$ "$http_origin"; # 仅 dev<br> ~*^https?://(app|staging)\.example\.net$ "$http_origin"; # test<br> ~*^https://(dashboard|api)\.example\.com$ "$http_origin"; # prod<br>} - 若需更高灵活性，可将白名单规则拆成独立文件：
include /etc/nginx/conf.d/cors-whitelist-dev.conf;
部署时按环境 symlink 对应文件，CI/CD 流程自动切换
配合 if 判断环境，精准启用对应策略
不依赖外部变量注入时，可用 if 结合 host 或端口特征做轻量判断（适合容器化部署）：
- 开发环境常监听
0.0.0.0:8080，测试环境用staging.example.net，生产走example.com - 示例：
set $cors_env "dev";<br>if ($host ~ "staging\.example\.net") { set $cors_env "test"; }<br>if ($host ~ "example\.com") { set $cors_env "prod"; }
再基于$cors_env控制是否加载某段map或开关add_header - 注意：
if不可用于直接设置 header，但可配合map输出不同值，保持逻辑清晰
确保 credentials 和 Origin 严格匹配
多环境最易出错的是带 Cookie 的请求被拒绝——根源常是白名单未覆盖当前前端域名，或误用了通配符：
- 所有环境禁用
Access-Control-Allow-Origin: *+Access-Control-Allow-Credentials: true组合，Nginx 会静默失效 - 开发环境允许
http://localhost:3000和http://127.0.0.1:3000，正则要写全："~*^http://(localhost|127\.0\.0\.1)(:\d+)?$" "$http_origin" - 生产环境只允许可信子域，避免泛域名（如
*.example.com）——浏览器不支持该写法，必须显式列出app.example.com、admin.example.com
预检响应和错误码也要环境感知
OPTIONS 返回 204 是基础，但不同环境对调试友好度要求不同：
- 开发环境可加
add_header 'Access-Control-Allow-Headers' 'DNT,Authorization,X-Debug-Env' always;，方便前端传调试头 - 生产环境精简 headers，去掉非必要字段（如
X-Debug-Env），降低信息泄露风险 - 所有环境都加
always标志，确保 401/403/500 等错误响应也带 CORS 头，否则前端看不到真实报错原因
