Nginx反向代理需协同配置HTTPS重定向与后端路径映射：80端口用return 301实现高效跳转；/api/映射需proxy_pass以/结尾并设置proxy_redirect修正Location头；透传X-Forwarded-Proto等头使后端识别真实协议。
HTTPS 重定向和后端服务地址映射是 Nginx 反向代理中最常并存的两个需求。它们各自解决不同问题：前者确保用户始终走加密通道，后者让前端路径与后端真实部署解耦。但若配置不当，二者会相互干扰——比如重定向后 Location 头仍是 HTTP 地址，或虚拟路径映射后重定向跳转到错误前缀。
HTTP 自动跳转 HTTPS（推荐用 return）
监听 80 端口时，用 return 301 比 rewrite 更高效、语义更清晰：
- 直接返回状态码，不触发重写引擎，性能更好
- 自动保留原始 host 和 request_uri，路径与参数零丢失
- 避免 rewrite 中 ? 清参等易错细节
示例配置：
server {
listen 80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}
/api 路径映射到后端服务
核心是 location 匹配 + proxy_pass 截断逻辑。关键看 proxy_pass 结尾是否有 /：
-
proxy_pass http://localhost:8080/;→ 自动剥离 location 前缀，/api/users → /users -
proxy_pass http://localhost:8080;→ 不截断，/api/users → /api/users（通常错误）
完整片段：
location /api/ {
proxy_pass http://localhost:8080/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
修正后端返回的重定向响应头
后端生成 302 时，Location 往往含内网地址或错误协议/路径。Nginx 必须改写它，否则用户跳转失败：
- 若后端返回
Location: /login，应改为/api/login：用proxy_redirect / /api/; - 若后端返回
Location: http://10.0.1.5:8080/dashboard，应改为公网 HTTPS 地址：用proxy_redirect http://10.0.1.5:8080/ https://example.com/api/; - 统一处理 HTTP→HTTPS 重定向头：
proxy_redirect ~^http://(.*)$ https://$1;
确保后端能识别真实协议和主机名
仅靠 proxy_redirect 不够。后端框架（如 Spring Boot、Django）需知道原始请求是 HTTPS，否则仍可能生成 HTTP 重定向：
- 透传
X-Forwarded-Proto $scheme—— 告诉后端当前是 http 还是 https - 透传
X-Forwarded-Host $host或保持Host $host—— 避免后端拼出内网域名 - Spring Boot 需配
server.forward-headers-strategy=framework；Django 需设SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
