如何配置Nginx解决ThinkPHP跨域请求服务器失效问题？

本文共计801个文字，预计阅读时间需要4分钟。

由于ThinkPHP自身的中间件或响应逻辑可能覆盖了Nginx设置的头部，Nginx的`add_header默认不会继承到子请求。如果PHP已经输出了响应头（例如通过`header()`或框架自动写入），Nginx将不会再次生效。

• 确认是否用了 fastcgi_pass：Nginx 的 add_header 对 FastCGI 后端默认不传递已设置的响应头，需显式开启 fastcgi_pass_header 或改用 always 参数
• 检查 ThinkPHP 是否启用了 CORS 中间件：如 think-middleware-cors，它会直接调用 header()，优先级高于 Nginx
• 用浏览器 DevTools 的 Network → Response Headers 看最终返回的是哪一层写的 Access-Control-Allow-Origin

Nginx 配置 add_header 必须带 always 才有效

ThinkPHP 的错误页、重定向、404 响应等非 200 状态码下，Nginx 默认不发送 add_header 设置的字段。不加 always，跨域头在接口报错时就消失，前端拿不到，直接卡死。

• 正确写法：add_header Access-Control-Allow-Origin "*" always;
• 必须同时设置 Access-Control-Allow-Methods 和 Access-Control-Allow-Headers，否则预检（OPTIONS）请求失败
• 如果允许携带 Cookie，Access-Control-Allow-Origin 不能为 *，得写具体域名，且要加 Access-Control-Allow-Credentials: true

ThinkPHP 的 Response 对象会清空 Nginx 头部

框架在构造 Response 实例时，若调用了 withHeader() 或设置了 header 配置项，会触发底层 header() 调用，导致 SAPI 层接管响应头控制权，Nginx 的 add_header 完全失效。

• 排查点：搜索项目中是否在控制器、中间件或全局事件里写了 $response->withHeader('Access-Control-Allow-Origin', ...)
• 更稳妥的做法是关掉框架层面的所有 CORS 设置，在 Nginx 统一处理，避免多层覆盖
• 如果必须用框架控制，那就彻底禁用 Nginx 的相关 add_header，只留一条 add_header X-Frame-Options "DENY" always; 这类无关 CORS 的安全头作验证

OPTIONS 预检请求被 405 拒绝？Nginx 要显式放行

ThinkPHP 默认不注册 OPTIONS 路由，Nginx 收到预检请求后，若没匹配到任何 location 或 fastcgi 指令，会返回 405 Method Not Allowed，而不是把请求转给 PHP。

立即学习“PHP免费学习笔记（深入）”；

• 在 server 或 location 块里加：if ($request_method = 'OPTIONS') { add_header Access-Control-Allow-Origin "*"; add_header Access-Control-Allow-Methods "GET, POST, OPTIONS, PUT, DELETE"; add_header Access-Control-Allow-Headers "Content-Type, Authorization"; add_header Access-Control-Allow-Credentials "true"; return 204; }
• 注意：不要用 rewrite 或 proxy_pass 处理 OPTIONS，容易引发循环或状态码错乱；return 204 是最轻量可靠的响应方式
• 确保该 if 块位于所有 try_files 或 fastcgi_pass 之前，否则不生效

实际部署时最容易漏的是 always 参数和 OPTIONS 的显式拦截——这两处一错，跨域就变成“有时行、有时不行”，查起来特别绕。