location / 能兜底是因为其优先级最低，仅在无 =、^~ 或正则匹配成功时才生效，且需置于所有具体规则之后；它匹配所有以 / 开头的 URI，作为默认 fallback 处理未被精确捕获的请求。
在 Nginx 中，location / 是最宽泛的前缀匹配规则，它会匹配所有以 / 开头的 URI（即几乎全部请求），因此常被用作“兜底”配置，将未被更精确 location 捕获的请求统一转发到后端服务（如 API 网关、Node.js 应用、上游集群等）。
为什么 location / 能兜底？
Nginx 的 location 匹配遵循“最长前缀匹配”原则。只要没有更具体的前缀（如 /api/、/static/、/health）或正则匹配（~ 或 ~*）先命中，location / 就会生效。它不排斥其他 location，而是作为默认 fallback 存在。
正确写法：放在所有具体规则之后
顺序很重要 —— location 块在配置文件中的书写顺序会影响匹配逻辑（尤其对相同优先级的前缀匹配）。务必把 location / 放在所有更具体的 location 之后：
- ✅ 先定义
location /api/、location /static/、location = /health - ✅ 最后写
location /，用于兜底代理 - ❌ 不要把它写在最前面，否则其他规则根本没机会匹配
典型兜底转发配置示例
以下是一个常见实践（假设后端服务监听在 http://127.0.0.1:3000）：
location /api/ {
proxy_pass http://backend_api/;
}
location /static/ {
alias /var/www/static/;
}
location = /favicon.ico {
log_not_found off;
access_log off;
}
location / {
proxy_pass http://127.0.0.1:3000/;
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;
}注意：proxy_pass 末尾的 / 很关键 —— 它表示“去除匹配前缀后转发”，避免路径重复（例如请求 /user/list 会转发为 http://127.0.0.1:3000/user/list）。
补充说明与避坑点
-
location /不匹配空 URI（如GET /）？—— 实际会匹配，/就是根路径，location /明确覆盖它 - 想排除某些路径但又不想逐条写？可配合
location ^~ /assets/或正则location ~* \.(js|css|png|jpg)$提前拦截静态资源 - 如果用了
try_files（如 SPA 的 history 模式），location /内通常写try_files $uri $uri/ /index.html;，而非proxy_pass - 测试是否兜底生效：用
curl -v http://your-domain.com/any-unmatched-path，观察响应来源和日志
