Nginx层统一处理CORS和安全响应头更高效可靠：可拦截OPTIONS预检请求避免后端无谓启动，通过map动态匹配可信origin并配合credentials支持，同时注入HSTS、X-Content-Type-Options等关键安全头，实现前置防护与零侵入协同。
直接在 Nginx 层统一处理跨域（CORS）和安全响应头，比在 Node.js 应用层做更高效、更可靠——它能拦截预检请求（OPTIONS），避免 Node 进程无谓启动；也能前置加固，减少后端暴露面。
跨域配置：精准控制 origin 与凭证支持
不建议全局用 Access-Control-Allow-Origin: *，尤其当涉及 Cookie 或认证头时。必须配合 Access-Control-Allow-Credentials: true 使用，且 origin 不能为通配符。
- 只允许可信前端域名：如前端部署在
https://app.example.com，Nginx 配置中显式写死该 origin - 若需多域名，可用 map 模块动态映射（推荐）：
map $http_origin $cors_origin { default ""; "https://app.example.com" "https://app.example.com"; "https://staging.example.com" "https://staging.example.com"; } # 在 location 块中使用 add_header 'Access-Control-Allow-Origin' $cors_origin always; add_header 'Access-Control-Allow-Credentials' 'true' always; - 必须响应 OPTIONS 预检请求：对 API 路径（如
/api/）添加内部返回，不转发给 Node
安全响应头：覆盖主流防护维度
除 CORS 外，应在 Nginx 中一并注入关键安全头，避免依赖 Node 中间件遗漏或顺序错乱。
-
Strict-Transport-Security：强制 HTTPS，防止降级攻击（生产环境必开）add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
-
X-Content-Type-Options和X-Frame-Options：防 MIME 嗅探和点击劫持add_header X-Content-Type-Options "nosniff" always; add_header X-Frame-Options "DENY" always;
-
Content-Security-Policy：按实际资源来源精细定义（如 script-src 'self' cdn.example.com）；开发期可先设为 report-only 模式观察违规
与 Node.js 协同的关键细节
Nginx 是反向代理，不是透明通道。以下配置直接影响 Node 应用行为：
- 透传真实客户端 IP：
proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme;
- 禁用 Node 的 CORS 中间件：若 Nginx 已统一管控，Node 中
app.use(cors())应移除或仅用于本地开发（通过环境变量判断） - 超时与缓冲区调优：避免大文件上传被截断
proxy_read_timeout 300; proxy_send_timeout 300; client_max_body_size 50M;
验证与调试要点
配置生效后，用 curl 或浏览器开发者工具检查响应头是否完整输出（注意：add_header ... always 才能在 4xx/5xx 响应中也生效）。
- 发起一个带 Credentials 的跨域请求，确认：
— Origin 头匹配且非 *
— Access-Control-Allow-Credentials: true
— Set-Cookie 正常下发（浏览器不会拒绝） - 用
curl -I -X OPTIONS https://your-api.com/api/users验证预检响应是否含全部 CORS 头，且状态码为 204 - 用 securityheaders.com 扫描域名，确认安全头评级达到 A 或 A+
