try_files 按配置从左到右依次检查文件存在性，遇首个存在的即返回；全不存在则执行最后的兜底选项（如 @fallback 或 =404）。检查严格逐项进行，不跳过或优化，且仅判断真实可读文件（目录需以/结尾并配合index指令）。
try_files 的文件存在性检查是按配置中列出的路径顺序依次进行的，遇到第一个存在的文件就停止检查并返回该文件；如果全部不存在，则返回最后指定的“兜底”选项（如命名 location 或 HTTP 状态码）。
检查顺序严格从左到右
Nginx 不会跳过中间项或做任何优化，它逐个判断每个参数是否对应一个真实存在的、可读的文件（注意：不检查目录，除非末尾带 / 且开启 index）。
- 每个参数先尝试作为文件解析（例如
index.html→ 查找磁盘上/path/to/index.html） - 若参数以
/结尾（如/static/），Nginx 会当作目录处理，并触发index指令（如index index.html;），最终查找/static/index.html - 最后一个参数不能是纯文件路径，必须是内部重定向（如
@fallback）或状态码（如=404）
常见写法与对应行为
以以下配置为例：
try_files $uri $uri/ /index.html =404;- 先查
$uri对应的静态文件（如请求/about→ 查/about文件） - 若不存在，再查
$uri/对应的目录 + 默认首页（即/about/index.html） - 都失败后，返回
/index.html的内容（注意：这是内部重写，URL 不变，且不触发新 location 匹配） - 若
/index.html也不存在，才返回 404
如何验证实际检查了哪个路径
可通过 Nginx 日志确认真实匹配项：
- 开启
error_log的info级别，会记录 “*1 open() “/xxx” failed” 类提示 - 用
strace -e trace=openat -p $(pidof nginx)观察 worker 进程打开哪些路径 - 临时在各候选路径下放测试文件（如
touch /var/www/test1 /var/www/test2），配合不同try_files顺序观察响应变化
容易忽略的关键细节
-
$uri是解码后的路径，不含查询参数；$request_uri才保留原始 URI 和 query - 检查依赖
root或alias的值拼接完整路径，务必确认 root 路径正确且有读取权限 - 如果用了
alias，$uri的匹配逻辑会变化（alias 会替换整个 location 前缀，不是简单拼接） - 所有检查都在 master 进程不参与，由 worker 进程同步完成，无缓存 —— 文件增删后立即生效
