能实现，而且是中小项目最常用、最经济的编排方式：通过nginx反向代理统一入口，按子域名或路径前缀分发至多后端服务，并配置关键请求头、upstream、超时与缓冲等参数适配业务需求。
能实现，而且是中小项目最常用、最经济的编排方式。一台云服务器跑 nginx + 多个后端服务（比如前端静态资源、用户服务、订单服务），全靠反向代理统一入口、按需分发。
域名或路径区分不同服务
这是最清晰、最易维护的方式。Nginx 根据 server_name 或 location 路径 把请求导向不同后端：
- 用不同子域名：比如 web.example.com → 前端，api.example.com → 后端 API，配置两个独立的
server块，各自proxy_pass到对应服务 - 用统一域名+路径前缀：比如 example.com/ → 前端，example.com/api/ → 用户服务，example.com/order/ → 订单服务，每个
location块单独指定后端地址
必须配对的关键请求头
多个服务共存时，后端需要知道真实用户是谁、访问的是哪个域名。漏掉这些头，登录态丢失、日志 IP 全是 Nginx 本机、HTTPS 重定向出错都很常见：
-
proxy_set_header Host $host;—— 保留原始域名，避免后端生成错误跳转链接 -
proxy_set_header X-Real-IP $remote_addr;和X-Forwarded-For $proxy_add_x_forwarded_for;—— 透传客户端真实 IP -
proxy_set_header X-Forwarded-Proto $scheme;—— 告诉后端当前是 http 还是 https，防止混合内容或跳转死循环
后端服务统一收口到 upstream
即使只部署一个实例，也建议用 upstream 块定义后端。好处是后续扩容、加健康检查、切流量都只需改这一处：
- 单实例写法：
upstream user-svc { server 127.0.0.1:3001; } - 多实例负载均衡：
upstream order-svc { server 192.168.1.10:8080 weight=3; server 192.168.1.11:8080; } - 支持备用节点：
server 192.168.1.12:8080 backup;，主节点挂了自动切过去
注意超时与缓冲匹配业务特性
不同服务响应时间差异大，不能一套参数打天下：
- 前端静态页、API 接口：
proxy_read_timeout 30s;足够 - 文件上传、导出报表类接口：可能要调到
120s甚至更高，否则中途断连报 504 - 大文件下载或流式响应：加上
proxy_buffering off;避免 Nginx 缓存整份响应再吐给用户 - WebSocket 长连接：必须加
proxy_http_version 1.1;和proxy_set_header Upgrade $http_upgrade;等两行，否则连接立刻断开
