try_files指令按顺序尝试匹配文件、目录或URI，任一成功即处理请求，全部失败则执行最后一项兜底操作；其参数依次检查物理文件、目录、内部重定向，且回退目标须为同级或外层命名location。
在 Nginx 中，location 块内的 try_files 指令用于按顺序尝试查找文件或路径，一旦某个选项匹配成功（如文件存在、目录可访问或内部重定向有效），就立即处理该请求；若全部失败，则返回最后一个参数指定的“兜底”响应（如 404 或跳转）。
try_files 的基本语法与执行逻辑
try_files 后面跟一到多个参数，以空格分隔，最后一个参数必须是状态码（如 =404）、URI（带或不带 @named_location）或变量。Nginx 会依次检查每个参数：
- 如果参数是文件路径（如
$uri、$uri/index.html），Nginx 检查对应物理文件是否存在且可读； - 如果参数是目录路径（如
$uri/），Nginx 检查该目录是否存在且开启autoindex或含索引文件； - 如果参数是 URI（如
/fallback或@php），Nginx 发起内部重定向（不改变浏览器 URL），交由匹配的location处理； - 只有当前面所有项都未命中时，才触发最后一项——这是“回退”的核心机制。
常见回退场景与配置示例
典型用途包括静态资源兜底、SPA 路由支持、PHP 后端代理等：
- 单页应用（如 Vue/React）：用
try_files $uri $uri/ /index.html;确保前端路由刷新不 404； - 静态文件 + 动态后端：如
try_files $uri $uri/ @backend;，先找静态文件，找不到则交给@backend处理； - 带查询参数的兼容：注意
$uri不含 query string，若需保留参数，应在@named_location中显式传递（如fastcgi_param QUERY_STRING $query_string;）； - 避免误判：不要写
try_files $uri =404;这类仅含变量和状态码的组合，除非确认前面一定失败——否则可能跳过合法路径。
location 匹配与 try_files 的协作关系
try_files 在 location 内部执行，但它的“回退目标”（如 @php）必须是同一层级或外层定义的命名 location；它本身不改变 location 匹配结果，只控制内部资源查找流程：
- 匹配进入某个
location后，try_files才开始工作； - 若回退到
@named_location，Nginx 会重新进行 location 查找（但仍是内部请求，无网络往返）； - 不能跨 server 块引用命名 location；
- 优先级高于
alias和root的路径拼接——try_files中的路径是相对于root或alias计算的。
调试与常见陷阱
回退失效往往源于路径计算错误或 location 作用域理解偏差：
- 开启
error_log /path/to/log warn;并触发请求，查看是否出现 “file not found” 或 “no such file” 提示； - 用
curl -I验证响应状态码，确认是否真走到兜底项； - 注意
alias下$uri的行为：当location /img/ { alias /data/images/; }时，$uri是/img/logo.png，而实际查找路径是/data/images/logo.png（自动截掉 location 前缀）； - 避免在正则 location 中滥用
try_files——某些版本中，正则 location 内的try_files可能不按预期工作，建议改用命名 location 分离逻辑。
