Django跨域问题解决：配置django-cors-headers方法

本文深入剖析了 Django 项目中使用 django-cors-headers 解决跨域问题时最常踩的“坑”：看似装好了却仍报“No 'Access-Control-Allow-Origin' header”，实则源于中间件加载顺序错误（必须置于 SessionMiddleware 之后、CommonMiddleware 之前）、关键配置参数过时或遗漏（如误用已弃用的 CORS_ORIGIN_ALLOW_ALL、未启用 CORS_ALLOW_CREDENTIALS 支持带 cookie 请求）、白名单格式不严谨、OPTIONS 预检处理缺失，以及生产环境盲目依赖 Python 层 CORS 而忽视 Nginx 反向代理的稳定性与安全性优势；文章不仅给出精准配置要点和调试技巧（如用 curl 模拟预检、正确查看响应头），更强调开发与上线的配置隔离意识——本地可开全源，上线必须严格白名单，避免因一个疏忽将 API 暴露给任意站点。

直接用 django-cors-headers 就行，但顺序、参数和调试方式错一个，前端照样收不到响应头。

为什么装了 django-cors-headers 还报 No 'Access-Control-Allow-Origin' header？

根本不是没装，而是中间件位置错了，或者没配关键参数。浏览器看到 OPTIONS 预检请求返回 200 但没带 Access-Control-Allow-Origin，说明 CorsMiddleware 根本没生效。

• CorsMiddleware 必须放在 SessionMiddleware 之后、CommonMiddleware 之前 —— 放错位置会导致它被跳过
• CORS_ALLOW_ALL_ORIGINS = True 是当前版本（4.0+）的推荐写法，CORS_ORIGIN_ALLOW_ALL = True 已弃用，设了也无效
• 如果前端带 cookie（比如 withCredentials: true），必须同时设 CORS_ALLOW_CREDENTIALS = True，否则浏览器直接拒绝响应
• ALLOWED_HOSTS 和 CORS 没关系，但若设成 ['*'] 而 DEBUG = False，Django 会直接拒掉所有请求，连预检都进不来

CORS_ALLOWED_ORIGINS 白名单怎么写才不踩坑？

开发时用 CORS_ALLOW_ALL_ORIGINS = True 最省事；上线必须关掉，换白名单。注意格式细节：

• 协议、域名、端口都要写全，比如 'http://localhost:3000'、'https://admin.example.com' —— 少个 http:// 或端口就匹配失败
• 不能写 'localhost:3000'（缺协议）或 'http://localhost'（缺端口，而 Vue 默认是 3000）
• 支持正则：用 CORS_ALLOWED_ORIGIN_REGEXES = [r'^https?://(localhost|127\.0\.0\.1):[0-9]+$'] 更灵活，但别滥用，正则写错会静默失效
• 如果后端 API 路径本身带前缀（如 /api/v1/），白名单不用体现这个路径，只管来源域名

OPTIONS 预检失败或 405 Method Not Allowed 怎么查？

前端发 POST/PUT 带自定义 header 时，浏览器先发 OPTIONS。失败通常不是 CORS 配置问题，而是路由或视图没处理 OPTIONS 方法。

• 确保 URL 路由真实存在，且对应视图能响应 OPTIONS —— DRF 的 APIView 默认支持，但普通函数视图要手动加 @csrf_exempt 并 return 空 response
• CORS_ALLOW_HEADERS 必须包含前端实际发送的 header，比如 'Authorization'、'X-Requested-With'，不能只写 '*'（新版已不支持通配符）
• 检查是否误开了 CSRF_COOKIE_SECURE 或 SESSION_COOKIE_SECURE 却在 HTTP 环境下测试，导致 cookie 不下发，进而影响凭证类跨域
• 用 curl 模拟预检：curl -I -X OPTIONS http://127.0.0.1:8000/api/login/ -H "Origin: http://localhost:3000"，看响应头有没有 Access-Control-Allow-Origin

为什么本地开发用 django-cors-headers，上线却推荐 Nginx 反向代理？

不是不能用，而是生产环境绕过 Django 中间件更稳、更快，还能统一处理 SSL、缓存、限流。

• django-cors-headers 是 Python 层拦截，每次请求都走一遍中间件逻辑；Nginx 是 C 层转发，零 Python 开销
• 某些云厂商（如阿里云 SLB）会吞掉 Access-Control-Allow-Origin 响应头，你加了也没用；Nginx 在入口处就补上，更可靠
• Vue 开发服务器（vue-cli-service serve）自带 proxy 配置，开发阶段完全不用动后端，vue.config.js 里加 devServer.proxy 即可
• 真正要警惕的是：把 CORS_ALLOW_ALL_ORIGINS = True 提交到 git 并部署上线 —— 这等于公开接口给任意网站调用，连 Referer 都不校验

最常被忽略的一点：浏览器开发者工具 Network 面板里，要点击具体请求 → Headers → Response，才能确认 Access-Control-Allow-Origin 是否真的返回了；光看 Preview 或 Response body 完全没用。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。