CORS 中 Access-Control-Allow-Methods 设置不生效怎么办？

令狐爱菊提问于 2026-03-13 18:52:24 阅读 4

安全

我在前端用 fetch 发了个 DELETE 请求，但浏览器报 CORS 错误，说方法不允许。后端明明设置了 Access-Control-Allow-Methods: GET, POST, PUT, DELETE，怎么还是不行？

我试过在 Nginx 里加这个头，也试过后端代码里手动设置，但 OPTIONS 预检请求返回的响应头里就是没有这个字段，或者内容不对。是不是哪里配置漏了？

CORS安全

我来解答赞 4 收藏

反馈

1 条解答

W″宝娥 Lv1

这种情况我遇到过，基本是两个坑：

1. Nginx的add_header不会继承

如果你只在location里加了add_header，当响应状态码不是200的时候（比如304），这个头就不会出现。Nginx 1.7.5以上版本，加上always参数就行：

add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS" always;

2. 你的后端可能没处理OPTIONS请求

很多框架对OPTIONS请求有默认处理，可能直接返回空或者走了另一个逻辑。你需要确保OPTIONS请求也返回正确的头。

最靠谱的写法是在Nginx里把预检请求直接搞定：

location / {

    # 预检请求直接返回

    if ($request_method = 'OPTIONS') {

        add_header Access-Control-Allow-Origin "http://your-frontend.com" always;

        add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS" always;

        add_header Access-Control-Allow-Headers "Content-Type, Authorization" always;

        add_header Access-Control-Max-Age 1728000;

        add_header Content-Length 0;

        add_header Content-Type text/plain;

        return 204;

    }

    

    # 实际请求的处理

    proxy_pass http://backend;

}

或者你在后端语言里确保对OPTIONS请求也加了这些头。性能上这种方式比每次都打后端要快，Nginx直接吃掉预检请求。

你检查一下是不是后端框架把OPTIONS请求拦截了没返回头？

2026-03-13 19:03