API跨域返回403通常因Nginx未正确处理预检OPTIONS请求或后端自身鉴权失败；需先用curl模拟OPTIONS确认响应状态与CORS头，再检查Nginx配置是否显式支持OPTIONS并返回204，同时排查后端逻辑及安全模块干扰。
API跨域请求返回403 Forbidden，通常不是因为Nginx主动拒绝了请求，而是Nginx在处理预检（OPTIONS）请求时未正确响应，或后端服务（如Node.js、Python Flask/Django）本身返回了403，而Nginx又将该状态透传给了前端。更常见的情况是：Nginx未配置对OPTIONS方法的显式支持，导致预检失败，浏览器直接拦截后续实际请求。
检查是否为预检（OPTIONS）请求被拒
浏览器发起跨域POST/PUT/DELETE等非简单请求前，会先发一个OPTIONS请求探路。若Nginx未配置响应该请求，就可能返回405（Method Not Allowed）或默认拒绝（触发403）。虽然标准是405，但在某些Nginx+安全模块（如mod_security、ngx_http_access_module误配）组合下，也可能表现为403。
- 用curl模拟预检：curl -X OPTIONS -H "Origin: https://your-app.com" -H "Access-Control-Request-Method: POST" -I http://your-api.com/endpoint
- 查看响应头中是否有Access-Control-Allow-Origin，状态码是否为200或204
- 若返回403，说明Nginx或上游服务在OPTIONS阶段就中断了流程
修复Nginx跨域基础配置（含OPTIONS支持）
仅添加CORS头不够，必须确保OPTIONS请求能被Nginx直接处理并快速返回，不转发给后端。以下是最小可靠配置：
- 在location块内添加：
if ($request_method = 'OPTIONS') {
add_header Access-Control-Allow-Origin "https://your-app.com";
add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS";
add_header Access-Control-Allow-Headers "DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization";
add_header Access-Control-Allow-Credentials "true";
add_header Access-Control-Max-Age 1728000;
add_header Content-Type 'text/plain; charset=utf-8';
add_header Content-Length 0;
return 204;
} - 在同个location中补充通用CORS头（供实际请求使用）：
add_header Access-Control-Allow-Origin "https://your-app.com" always;
add_header Access-Control-Allow-Credentials "true" always;
add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS" always;
add_header Access-Control-Allow-Headers "DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization" always; - 注意：always参数确保响应头在3xx/4xx/5xx状态下也生效，避免后端返回403时丢失CORS头
排查后端服务自身返回403
Nginx只是代理，若后端接口逻辑校验失败（如JWT过期、权限不足、CSRF token缺失、IP黑名单），会直接返回403。此时Nginx如实转发，但前端看到的是“跨域403”，容易误判为Nginx问题。
- 关闭Nginx，直接curl访问后端服务（如curl -H "Origin: https://your-app.com" http://127.0.0.1:3000/api/login），确认是否仍返回403
- 检查后端日志，确认403来源是鉴权失败还是路由/中间件拦截
- 若后端已实现CORS（如Express的cors中间件），需确保其允许OPTIONS方法，且未在OPTIONS路径上执行鉴权逻辑
警惕安全模块与路径匹配干扰
某些Nginx部署启用了额外安全层，可能在OPTIONS阶段误触发规则：
- ngx_http_access_module：检查是否有deny all;或IP限制未放行OPTIONS
- mod_security（如有）：查看audit log，确认是否因空body或无Content-Type的OPTIONS请求被WAF拦截
- 路径匹配错误：比如location /api/ { ... }未覆盖/api/v1/，导致OPTIONS落到其他location块（如root静态目录），返回403
- 验证方式：临时注释所有access_log/access deny规则，测试是否恢复；再逐条开启定位
