在 linux 中配置 nginx 处理跨域 cors 请求，核心做法是在 `server` 或 `location` 块中添加特定的响应头指令。通过设置 add_header access-control-allow-origin、access-control-allow-methods 和 access-control-allow-headers，nginx 会在 http 响应中携带这些字段，从而允许浏览器前端发起跨域请求。若涉及预检请求（preflight），需额外配置对 options 方法的处理逻辑。
Nginx 如何配置简单的 CORS 请求头
对于不涉及预检的简单请求，只需在 Nginx 配置文件中添加基础的 CORS 响应头即可。主要需要配置允许的来源、允许的 HTTP 方法以及允许的自定义请求头。这些配置直接作用于目标 location 块，确保所有经过该路径的请求都附带正确的跨域标识。
server {
listen 80;
server_name api.example.com;
location /api/ {
# 允许特定来源，或使用 * 允许所有（生产环境慎用）
add_header 'Access-Control-Allow-Origin' 'https://frontend.example.com' always;
# 允许的 HTTP 方法
add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS' always;
# 允许的请求头
add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type, Accept' always;
# 代理转发
proxy_pass http://backend_server;
}
}
上述配置中，always 参数确保即使 Nginx 返回错误状态码（如 4xx 或 5xx），响应头也会附加到响应中。这是关键细节，因为浏览器在收到错误时仍会检查 CORS 头以决定如何处理错误信息。实际运行时，前端发送 GET 或 POST 请求，Nginx 直接转发并带上这些头，浏览器解析后放行数据。
Nginx 如何处理 CORS 预检请求 (OPTIONS)
当请求包含非简单方法（如 PUT、DELETE）或自定义头（如 X-Custom-Header）时，浏览器会先发送一个 OPTIONS 预检请求。Nginx 必须显式处理这个请求，否则连接会被拒绝。最佳实践是拦截 OPTIONS 请求并立即返回 200 状态码，同时携带完整的 CORS 头，避免将预检请求转发给后端服务。
server {
listen 80;
server_name api.example.com;
location /api/ {
# 处理预检请求
if ($request_method = 'OPTIONS') {
add_header 'Access-Control-Allow-Origin' 'https://frontend.example.com' always;
add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS' always;
add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type, X-Custom-Header' always;
add_header 'Access-Control-Max-Age' 1728000;
add_header 'Content-Type' 'text/plain; charset=utf-8';
add_header 'Content-Length' 0;
return 204;
}
# 正常请求处理
add_header 'Access-Control-Allow-Origin' 'https://frontend.example.com' always;
add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS' always;
add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type, X-Custom-Header' always;
proxy_pass http://backend_server;
}
}
在此配置中，if 块专门捕获 OPTIONS 方法。返回 204 No Content 是标准做法，表示预检成功且无内容返回。Access-Control-Max-Age 设置了预检结果缓存时间（秒），减少重复预检开销。注意，if 指令在 Nginx 中需谨慎使用，但在 CORS 场景下是官方推荐的标准模式。验证时，可使用 curl 命令模拟：curl -I -X OPTIONS https://api.example.com/api/resource -H "Origin: https://frontend.example.com"，观察返回头是否完整。
动态 Origin 配置中的安全风险与限制
在实际开发中，有时需要根据请求中的 Origin 头动态设置 Access-Control-Allow-Origin，以支持多个前端域名。然而，Nginx 原生不支持直接将请求头变量赋值给响应头，直接使用 $http_origin 可能导致安全漏洞，如反射型 XSS 或开放重定向风险。因此，必须配合白名单机制进行严格校验。
map $http_origin $cors_origin {
default "";
"https://frontend1.example.com" "https://frontend1.example.com";
"https://frontend2.example.com" "https://frontend2.example.com";
}
server {
listen 80;
server_name api.example.com;
location /api/ {
# 使用 map 变量，若不在白名单则为空
add_header 'Access-Control-Allow-Origin' $cors_origin always;
if ($request_method = 'OPTIONS') {
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;
add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type' always;
return 204;
}
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;
add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type' always;
proxy_pass http://backend_server;
}
}
此方案利用 map 指令构建白名单映射表。只有当 $http_origin 匹配白名单中的值时，$cors_origin 才会被赋值为对应的域名；否则为空字符串。由于 add_header 在值为空时不添加头，浏览器将拒绝跨域请求，从而实现安全过滤。切勿直接使用 add_header 'Access-Control-Allow-Origin' $http_origin; 而不加校验，这会允许任何来源发起请求，构成严重安全隐患。
