Nginx 通过 http 块顶层 map 模块将 $http_origin 动态映射为 $cors_origin，再用 add_header ... always 注入精确 CORS 响应头，并拦截 OPTIONS 请求返回 204；禁止使用 *，须严格匹配合法域名。
用 map 模块根据前端来源动态返回 CORS 响应头，核心是把原始请求头中的 Origin 映射成一个可信的、可复用的变量，再把这个变量注入响应头。不是写死域名，也不是用 * 一刀切，而是让每个合法来源拿到它自己对应的 Access-Control-Allow-Origin 值。
在 http 块顶层定义 map 规则
map 必须放在 http 块最外层（不能塞进 server 或 location），它会在 Nginx 启动时编译完成，性能高、无运行时开销。
- 源变量固定为
$http_origin，即浏览器发来的 Origin 请求头 - 目标变量自定义，比如
$cors_origin，用于后续注入响应头 - 每条规则按顺序匹配，第一个命中即停止；未匹配时返回
default设定的值（建议设为空字符串，避免意外放行） - 支持正则匹配，推荐用
~*（不区分大小写），例如："~*^https?://(app\.example\.com|demo\.test\.org)$" "$http_origin"
匹配常见开发与测试来源
开发阶段常需支持本地调试地址，比如不同端口的 localhost 或内网 IP：
"~*^https?://localhost(:[0-9]+)?$" "$http_origin""~*^https?://127\.0\.0\.1(:[0-9]+)?$" "$http_origin""~*^https?://192\.168\.[0-9]+\.[0-9]+(:[0-9]+)?$" "$http_origin""~*^https?://.*\.staging\.example\.com$" "$http_origin"
这些规则能覆盖大部分前端联调场景，且不会把生产环境域名混进来。
前端设计优化skill
下载
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
立即学习“前端免费学习笔记（深入）”；
在 location 中注入响应头并处理 OPTIONS 预检
匹配到的 $cors_origin 只有非空时才生效，所以要配合 always 标志确保所有状态码（包括 204、404、301）都携带 CORS 头：
add_header 'Access-Control-Allow-Origin' $cors_origin always;add_header 'Access-Control-Allow-Credentials' 'true' always;add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE' always;add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,Content-Type,Authorization' always;
对 OPTIONS 请求单独拦截，快速返回 204 空响应，不转发给后端：
if ($request_method = 'OPTIONS') { return 204; }- 注意：这个
if放在location内即可，无需重复设置 CORS 头——因为上面的add_header ... always已覆盖
生产环境要严格校验，禁用通配符
带 credentials（如 Cookie、Authorization）的请求，Access-Control-Allow-Origin 绝对不能设为 *，否则浏览器直接拒绝。必须精确匹配来源域名：
- 只列出线上正式域名，例如：
"~*^https?://(app\.example\.com|admin\.example\.com)$" "$http_origin" - 禁用模糊匹配（如
.*\.example\.com），除非你明确允许所有子域 - 上线前用 curl 检查真实请求的
Origin头是否被正确映射，避免因协议（http/https）、端口或路径差异导致匹配失败
