实战演示Nginx解决跨域环境下PUT与DELETE方法失效-Nginx-PHP中文网

PUT/DELETE跨域“失效”是因浏览器预检OPTIONS失败：Nginx未正确响应204并返回Access-Control-Allow-Methods等头，导致真实请求不发出；需在Nginx中显式拦截OPTIONS并统一配置CORS头。

实战演示nginx解决跨域环境下put与delete方法失效

在跨域请求中，浏览器对非简单请求（如 PUT、DELETE）会先发送一个预检请求（OPTIONS），而 Nginx 默认不处理或转发 OPTIONS 请求，导致后端收不到真正的 PUT/DELETE 请求，表现为“方法失效”——接口返回 405 Method Not Allowed 或直接被拦截。解决的关键不是绕过后端，而是让 Nginx 正确响应预检，并透传真实请求。

为什么 PUT/DELETE 在跨域下“失效”？

浏览器发起跨域 PUT/DELETE 时，会先发一个 OPTIONS 请求询问服务器：“我接下来要发 PUT，你允许吗？”——这个预检请求需满足三个条件才能放行真实请求：

服务器必须返回 200 或 204 状态码
响应头中必须包含 Access-Control-Allow-Methods（明确列出 PUT、DELETE）
响应头中必须包含 Access-Control-Allow-Headers（匹配前端实际发送的自定义头，如 Authorization、Content-Type）

若 Nginx 没配置处理 OPTIONS，它可能直接返回 405（不支持该方法），或把请求错误地转发给后端（而后端未实现 OPTIONS 接口），最终导致预检失败，真实请求根本不会发出。

Nginx 配置：显式拦截并响应 OPTIONS 请求

不要依赖后端处理 OPTIONS，应在 Nginx 层统一响应预检。以下为关键配置片段（放在 location 块内）：

    # 允许跨域请求来源（生产环境请勿用 *，应写具体域名）
    add_header 'Access-Control-Allow-Origin' 'https://your-frontend.com';
    add_header 'Access-Control-Allow-Credentials' 'true';
<pre class="brush:php;toolbar:false;"># 明确声明支持的 HTTP 方法
add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS';

# 声明前端可能携带的请求头（如 token、json 类型等）
add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization,Accept,Origin';

# 预检结果缓存时间（单位秒），减少重复 OPTIONS 请求
add_header 'Access-Control-Max-Age' 1728000;

# 处理 OPTIONS 请求：立即返回 204，不转发给后端
if ($request_method = 'OPTIONS') {
    add_header 'Access-Control-Allow-Origin' 'https://your-frontend.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,Accept,Origin';
    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;
}

⚠️ 注意：if 指令在 location 中是安全的，但禁止在 server 级别使用 if + rewrite 组合，易引发重写循环。此处仅用于 method 判断，符合 Nginx 最佳实践。

确保后端不干扰：关闭后端 CORS 中间件（如适用）

如果后端框架（如 Spring Boot、Express、Django）已启用了 CORS 中间件，它可能覆盖 Nginx 的响应头，或对 OPTIONS 请求做额外处理（如返回 404），造成冲突。建议：

开发/测试环境可保留后端 CORS，便于本地调试
上线后，关闭后端 CORS 中间件，由 Nginx 统一管控跨域策略
若必须保留（如微服务网关层需鉴权），则确保其 OPTIONS 接口返回与 Nginx 一致的 headers，且状态码为 200/204

验证是否生效：三步快速检测

打开浏览器开发者工具 → Network 标签页，执行一次前端 PUT 请求：

看到第一个请求 method 是 OPTIONS，status 为 204，响应头含所有 Access-Control-* 字段 → 预检通过 ✅
紧接着出现第二个请求，method 是 PUT（或 DELETE），status 为 2xx → 真实请求已发出 ✅
检查 PUT 请求的 Response Headers 中，Access-Control-Allow-Origin 等字段依然存在 → Nginx 正确透传了跨域头 ✅

若卡在第一步（OPTIONS 返回 405 或无跨域头），说明 Nginx 配置未生效或被覆盖；若卡在第二步（PUT 未出现），可能是前端代码未正确触发，或浏览器缓存了旧的预检结果（可清空 Network 记录后重试）。