反向代理能解决跨域请求拦截、隐藏真实服务地址、统一HTTPS入口、负载均衡等实际问题；通过Nginx的proxy_pass实现请求转发，并需正确配置路径重写、关键header透传及超时参数以保障稳定性。
反向代理能解决什么实际问题
当你的前端静态资源和后端 API 分别部署在不同服务器或端口时，浏览器同源策略会拦截请求；或者你想隐藏真实服务地址、统一 HTTPS 入口、做负载均衡，proxy_pass 就是 Nginx 最直接的解法。它不是“转发”，而是让 Nginx 以客户端身份去请求后端，并把响应原样返回给原始请求者。
proxy_pass 的 URL 结尾斜杠到底要不要加
这是最常踩的坑：斜杠决定路径重写行为。Nginx 不是简单拼接字符串，而是按规则替换匹配到的 location 前缀。
- 如果
location /api/后跟proxy_pass http://127.0.0.1:8000/（结尾有/），则/api/user→ 转发为/user - 如果
proxy_pass http://127.0.0.1:8000（结尾无/），则/api/user→ 转发为/api/user，后端必须能处理带/api前缀的路径
绝大多数现代后端（如 Express、FastAPI）默认不期望带前缀，所以推荐加尾部 /，并确保 location 也以 / 结尾。
必须显式设置的几个关键 header
后端服务依赖这些 header 判断原始请求的真实信息，否则可能报 400、跳转出错或无法识别 HTTPS：
-
proxy_set_header Host $host;—— 不用$http_host，避免攻击者伪造 Host -
proxy_set_header X-Real-IP $remote_addr;—— 获取真实客户端 IP（而非 Nginx 本机 IP） -
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;—— 支持多层代理链 -
proxy_set_header X-Forwarded-Proto $scheme;—— 让后端知道原始是 http 还是 https
漏掉 X-Forwarded-Proto 是导致后端重定向跳回 http 的常见原因。
超时与缓冲区配置影响接口稳定性
默认超时只有 60 秒，大文件上传、长轮询或慢查询容易被中断；默认缓冲区也可能导致大响应体截断：
-
proxy_connect_timeout 30s;—— 建连阶段，建议 ≤ 后端连接池超时 -
proxy_send_timeout 300s;—— 发送请求体阶段（如上传），按业务最大耗时设 -
proxy_read_timeout 300s;—— 等待后端响应阶段，长任务必须调高 -
proxy_buffering off;—— 对流式响应（SSE、大文件下载）建议关闭缓冲 -
proxy_max_temp_file_size 0;—— 关闭临时文件缓存，避免磁盘写满
没调 proxy_read_timeout 就上线 WebSocket 或长轮询服务，连接大概率会在 60 秒后静默断开。
路径重写、header 透传、超时参数这三项漏一不可；调试时先用 curl -v 看响应头和状态码，再查 Nginx error log 里的 upstream timed out 或 no live upstreams 提示，比盲改配置快得多。
