宝塔反向代理后接口跨域失败主因是响应头缺失或被覆盖，需在Nginx配置中用always参数添加Access-Control-Allow-Origin等5个关键头，并处理Cookie路径、重定向及HTTPS转发问题。
宝塔反向代理后接口请求失败，大概率不是代理本身没生效，而是跨域响应头缺失或被覆盖，尤其当后端没配 CORS 且前端走 HTTPS 时。
为什么加了反向代理还报跨域错误
反向代理本应让前后端同源（比如都走 https://example.com/api），但实际仍报 CORS 错误，常见原因有：
- 后端 SpringBoot 等框架默认未开启
CORS，且没禁用预检（OPTIONS）拦截 - 宝塔的 Nginx 配置里手动加了
add_header，但没加always参数，导致对301/302/4xx/5xx响应不生效 - 代理路径带前缀（如
/api/），但后端返回的Location或Set-Cookie头仍含原始端口或路径，触发浏览器拒绝 - 前端发的是
credentials: true请求，但 Nginx 没透传Origin或没设Access-Control-Allow-Credentials: true
Nginx 配置中必须加的响应头项
在宝塔网站配置 → 反向代理 → 配置文件中，在 location 块内补全以下头（注意顺序和 always）：
add_header 'Access-Control-Allow-Origin' '$http_origin' always; add_header 'Access-Control-Allow-Credentials' 'true' always; add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE' always; add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization' always; add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range' always;
特别注意：$http_origin 要求前端请求带 Origin 头；若只允许特定域名，可写死为 'https://your-frontend.com'，但不能写成 * + Access-Control-Allow-Credentials: true 组合（浏览器会直接拒收）。
代理路径与后端 Cookie/Redirect 的冲突点
当反向代理路径是 /api/，而 SpringBoot 后端监听 http://127.0.0.1:8080 时，容易出两类问题：
-
Set-Cookie中的Path=默认为/，但前端请求路径是/api/login，导致 Cookie 不携带 —— 解决：后端设server.servlet.context-path=/api或 Nginx 用proxy_cookie_path / /api/; - 后端返回
302重定向到http://localhost:8080/xxx—— 解决：Nginx 加proxy_redirect http://localhost:8080/ /api/;，或后端用相对路径跳转 - SpringBoot 的
server.forward-headers-strategy=framework必须启用，否则X-Forwarded-Proto等头无效，HTTPS 下可能跳 HTTP 重定向
调试时最容易忽略的三个检查点
别只盯着 proxy_pass 是否写对，这几个地方一错，整个链路就断：
- 宝塔「网站」→「SSL」页确认已启用并部署成功，且「强制 HTTPS」开关没误开（它会 301 跳转，干扰 WebSocket 和部分 API）
- 浏览器开发者工具 → Network → 点开失败请求 → 查看
Response Headers里有没有你加的Access-Control-*头 —— 没出现说明 Nginx 没加载新配置，执行nginx -t && systemctl reload nginx - 后端日志是否收到请求？如果 Nginx
error_log出现connection refused，说明proxy_pass地址不可达，而非跨域问题
真正卡住的往往不是“怎么配”，而是“哪一层悄悄覆盖了头”或者“哪个 302 把 Origin 带丢了”。多看响应头原始内容，比反复改配置更省时间。
