结构化Nginx反向代理的关键是分层解耦：upstream统一定义后端集群，server按域名隔离入口，location按路径精准路由，配合include拆分配置提升可维护性。
在 Linux 上用 Nginx 管理多个反向代理后端，关键不是堆配置，而是分层、解耦、可维护。结构化管理的核心是把“谁来处理请求”和“怎么处理请求”分开，让 upstream、server、location 各司其职，避免混写一团。
用独立 upstream 块统一定义后端集群
所有后端服务必须在 http 块顶层 定义为命名 upstream，不能放在 server 或 location 里：
- 每个 upstream 对应一个业务逻辑单元（如
api_backend、admin_backend、file_backend），名称要见名知意 - 支持混合地址类型：IP+端口（
10.0.1.5:8080）、域名（svc-auth.internal）、Unix socket（unix:/var/run/app.sock） - 按需加健康参数：
weight=5控制流量比例，max_fails=2 fail_timeout=15s触发自动摘除，backup标记备用节点
用独立 server 块按入口维度隔离配置
每个对外暴露的域名或端口，单独配一个 server 块，不混用：
- 例如：
server_name api.example.com处理 API 流量，server_name admin.example.com处理后台管理 - 每个 server 内只写与该入口强相关的逻辑：SSL 配置、访问控制、自定义日志路径、特定 header 过滤等
- 避免在一个 server 里塞多个 proxy_pass；不同路径应由 location 分治，而非靠 if 判断
用 location 按路径粒度精准路由到 upstream
location 是真正决定“哪个请求打给哪个 upstream”的开关，注意路径匹配细节：
- 严格区分末尾斜杠：
proxy_pass http://api_backend/;会剥离/v1/再转发，而proxy_pass http://api_backend;（无斜杠）则原样透传 - 优先使用前缀匹配（
location /api/）而非正则，性能更高；复杂路由再考虑~ ^/static/.*\.(js|css)$ - 同一 server 下可并存多个 location，分别指向不同 upstream，实现单域名多后端（如
/auth→ auth_backend，/metrics→ monitor_backend）
用 include 拆分配置文件提升可维护性
不要把所有内容挤在 /etc/nginx/nginx.conf 或 default 里：
- 将 upstream 定义单独存为
/etc/nginx/upstreams.conf，在 http 块中include upstreams.conf; - 每个业务域配一个文件：
/etc/nginx/sites-available/api.conf，软链到sites-enabled/ - 公共代理参数（如通用 header、超时值）抽成
/etc/nginx/proxy_params，在 location 中include proxy_params;
