try_files 不直接代理，而是先检查静态文件存在性，缺失时通过命名 location（如 @backend）执行 proxy_pass 实现分流；典型用于前后端分离部署，需避免在 try_files 末尾直接写 proxy_pass。
在 Nginx 中，try_files 本身不直接“决定是否代理”，而是先检查静态文件是否存在；若都不存在，再把请求交给后端（比如用 proxy_pass）。它和代理配合的关键在于：**用命名 location 做 fallback，再在其中执行代理**，避免直接在 try_files 最后一项写 proxy_pass（语法不支持）。
核心思路：文件优先，缺失则代理
典型场景是前后端分离部署——前端资源（HTML/JS/CSS）放 Nginx 静态服务，API 请求（如 /api/）需转发给后端服务。但有些路径既可能对应静态文件，也可能需要动态处理（比如 SSR 或混合路由），这时就靠 try_files + 命名 location 实现判断分流：
- 先查 $uri 是否为真实文件（如 /user.js）→ 存在就直接返回
- 再查 $uri/ 是否为目录（如 /admin/）→ 存在且含 index.html 就返回
- 都不匹配 → 内部重定向到 @backend，由该命名 location 执行 proxy_pass
正确配置示例
以下配置将请求按存在性自动分流：
location / {
root /var/www/frontend;
try_files $uri $uri/ @backend;
}
location @backend {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
说明：
-
$uri检查/var/www/frontend/xxx是否为文件（如/logo.png） -
$uri/检查是否为目录（如/assets/），并尝试加载其index.html -
@backend是命名 location，不对外暴露，仅作内部跳转目标 - 所有未命中静态资源的请求（如
/api/login、/user/profile）都会落到@backend并被代理
常见错误与避坑点
这些写法会导致配置失败或行为异常：
-
不能在 try_files 最后写 proxy_pass：例如
try_files $uri @backend;后面紧接proxy_pass是无效的——必须把proxy_pass放在location @backend { ... }块内 - 不要混用 root 和 alias 在同一 location：root 拼接路径是追加，alias 是替换前缀，逻辑不同，易导致 404
- 确保命名 location 存在且作用域正确：@backend 必须定义在同级或外层 server 块中，不能嵌套在其他 location 内
-
注意 query string 传递：默认情况下
try_files跳转到命名 location 会丢失$args，如需保留，应在命名 location 中显式拼接，例如：proxy_pass http://127.0.0.1:3000?$args;
进阶：区分 API 与页面路径
如果 API 有固定前缀（如 /api/），更推荐用独立 location 显式代理，避免依赖 try_files 判断：
location /api/ {
proxy_pass http://backend-api;
}
location / {
root /var/www/spa;
try_files $uri $uri/ /index.html;
}
这样更清晰、高效，也符合 Nginx location 匹配的最长前缀优先原则——/api/login 会先匹配 /api/ 块，根本不会进入 SPA 的 try_files 流程。
