try_files 是 Nginx 实现静态资源智能兜底的核心指令，按空格分隔顺序检查路径存在性，命中即返回，全不命中则跳转至最后一个命名 location 或状态码；需注意 root/alias 差异、不可用绝对路径、与静态压缩模块执行顺序等细节。
在 Nginx 中，try_files 是实现静态资源“先尝试命中缓存或本地文件，失败再回退到后端服务”的核心指令。它让静态资源请求具备智能兜底能力，既提升性能又保障可用性。
理解 try_files 的匹配逻辑
try_files 按空格分隔的顺序依次检查每个路径是否存在（对文件或目录）。只要某一项存在，就直接返回对应资源；全部不存在时，才跳转到最后一个参数（通常是命名 location 或状态码）。
- 路径以
/开头表示相对于 root 或 alias 定义的根目录 - 最后一个参数不能是纯路径，必须是内部重定向（如
@backend）或 HTTP 状态码（如=404） - 注意：Nginx 不会自动拼接扩展名，
try_files $uri只查/a/b/c，不查/a/b/c.html
常见静态资源回退场景配置
典型用法是让前端单页应用（SPA）支持 HTML5 History 路由，同时兼顾真实静态文件优先返回：
location / {
root /var/www/html;
try_files $uri $uri/ /index.html;
}
-
$uri：尝试精确匹配请求路径（如/js/app.js） -
$uri/：若为目录且开启autoindex，则尝试列出内容；否则忽略 -
/index.html：兜底返回 SPA 入口，浏览器自行处理路由
这种写法确保 /logo.png、/css/main.css 直接返回，而 /user/profile 这类前端路由也返回 index.html，由 JS 解析。
结合后端服务做动态兜底
当静态资源不存在时，把请求交给上游应用服务器（如 Node.js、Python Flask）处理：
location / {
root /var/www/static;
try_files $uri @app;
}
location @app {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
}
-
@app是命名 location，仅用于内部跳转，不对外暴露 - 所有未命中静态文件的请求（包括 API 接口和动态页面）都会被代理
- 注意：
proxy_pass后的地址需与 upstream 或具体 IP:PORT 匹配
避免常见陷阱
几个容易出错的细节会影响回退效果：
-
root和alias对$uri的拼接方式不同：使用alias时，$uri会被截掉匹配前缀，务必核对路径是否正确 - 不要在
try_files中写绝对路径（如/var/www/...），Nginx 只认相对于 root 的相对路径 - 如果启用 gzip_static 或 brotli_static，需确保
try_files在它们之前执行，否则压缩版本可能被跳过 - 调试时可临时添加
log_not_found off;减少 error log 干扰，但上线前建议打开以便监控缺失资源
合理使用 try_files 能让静态服务兼具效率与容错，关键在于理清路径查找顺序和兜底目标语义。不复杂但容易忽略细节。
