nginx 通过 location 匹配 + proxy_pass 转发实现后端路由：支持路径前缀（如 /api/）、域名分流（server_name）、静态资源直出（正则匹配）、upstream 多实例负载均衡及健康检查。
Nginx 实现后端服务的请求路由逻辑，本质是靠 location 匹配规则 + proxy_pass 转发目标 的组合来完成。它不依赖后端代码改动，所有分发决策都在 Nginx 层完成，既安全又可控。
按路径前缀路由（最常用）
适合前后端分离架构，比如前端走根路径 /，API 统一走 /api/：
- 配置示例中
location /api/ { proxy_pass http://127.0.0.1:3000/; }表示：所有以/api/开头的请求，剥离该前缀后转发给本地 3000 端口服务 - 关键细节：proxy_pass 末尾带
/才会自动去掉匹配的前缀；不带则原样拼接，容易导致 404 - 多个路径可并存，例如再加一个
location /admin/ { proxy_pass http://127.0.0.1:8000/; }，指向另一个管理后台服务
按域名分流到不同后端
当有多个子系统共用一个公网 IP 时，用 server_name 区分入口：
- 写两个独立的
server块，分别设置server_name api.example.com和server_name admin.example.com - 每个块内用
location /直接代理对应后端，如proxy_pass http://192.168.1.20:8080; - 客户端通过不同域名访问，Nginx 自动识别并转发，后端完全无感知
按文件类型跳过代理（静态资源直出）
提升性能，避免把图片、JS、CSS 等请求也扔给后端处理：
- 在 proxy 规则之前添加静态匹配，例如：
location ~* \.(js|css|png|jpg|gif)$ { root /var/www/static; } - Nginx 按最长匹配优先原则，先命中正则就直接返回文件，不走 proxy_pass
- 注意顺序：静态规则必须放在
location /api/这类代理规则前面，否则无效
多实例负载与健康感知（进阶路由）
单点后端有风险，可用 upstream 定义服务组，实现基础负载和容错：
- 在 http 块里定义：
upstream backend_api { server 192.168.1.10:3000; server 192.168.1.11:3000; } - 在 location 中引用：
proxy_pass http://backend_api; - 可追加
max_fails=3 fail_timeout=30s实现简单健康检查，失败多次自动剔除节点
