Nginx中用include引入站点专属跨域OPTIONS预检响应，需创建独立配置文件（如cors-options.conf），在server块顶部include并前置于proxy_pass location，使用if判断OPTIONS方法、add_header加always、map动态匹配Origin白名单，确保返回204及完整CORS头。
在 Nginx 中用 include 引入站点专属的跨域 OPTIONS 预检响应，核心是把预检逻辑抽离成独立、可复用的配置文件，并确保它被正确加载且优先匹配。这不是简单“加个 include”，而是要兼顾路径匹配顺序、header 注入完整性与上下文安全。
创建专用预检配置文件（如 cors-options.conf）
在 /etc/nginx/conf.d/ 或站点配置同级目录下新建文件，例如 /etc/nginx/snippets/cors-options.conf，内容需满足三点：显式拦截 OPTIONS、带 always 的完整 CORS 头、返回 204。
- 必须用
if ($request_method = 'OPTIONS') { ... return 204; }判断，不能依赖后端 - 所有
add_header后必须加always，否则 return 204 时头会丢失 - Origin 应动态匹配白名单（如用
map或正则），禁用通配符*配合Access-Control-Allow-Credentials: true
在站点 server 块中按顺序 include 并前置声明
include 的位置很关键——必须放在所有 location /api/ 等代理块之前，否则 Nginx 可能先匹配到 proxy_pass location，导致 OPTIONS 被错误转发。
- 在
server块顶部或location /之前写：include /etc/nginx/snippets/cors-options.conf; - 该 include 内容应封装在一个精准的
location ~ ^/api/或location /api/块里，确保只对目标路径生效 - 避免在同一个 location 内混用
if和proxy_pass，这是 Nginx 官方明确不推荐的非标准上下文
配合 map 实现多源 Origin 动态回传
若站点需支持多个前端域名（如开发环境 localhost、测试环境 test.example.com、生产 admin.example.com），直接写死 Origin 不够灵活。用 map 提前定义可信源更安全：
- 在
http块中定义：map $http_origin $cors_origin { default ""; "~*^https?://(localhost|test\.example\.com|admin\.example\.com)(:[0-9]+)?$" "$http_origin"; } - 在 cors-options.conf 中写：
add_header 'Access-Control-Allow-Origin' $cors_origin always; - 只有匹配成功的 Origin 才写入响应头，不匹配则不设该头，浏览器自然拒绝，避免伪造来源绕过
验证 include 是否生效及缓存控制
include 进来的配置不是“自动生效”，需确认两点：是否被加载、是否真被触发。
- 执行
nginx -t检查语法；用nginx -T | grep -A5 -B5 "OPTIONS"查看最终合并后的配置 - 发起 curl 测试：
curl -X OPTIONS -H "Origin: https://admin.example.com" -I http://your-api.com/api/user，检查响应中是否有全部 CORS 头和204 No Content - 为减少重复预检，建议在 cors-options.conf 中加：
add_header 'Access-Control-Max-Age' '86400' always;和add_header 'Cache-Control' 'public, max-age=86400' always;
