单页应用刷新会404是因为Nginx按真实路径查找文件，而/history模式路由路径（如/user/profile）在服务端并不存在；try_files通过$uri $uri/ /index.html顺序匹配，最终兜底返回index.html，交由前端路由接管。
为什么单页应用刷新会 404
SPA（如 Vue、React）前端路由由 JS 控制，真实路径只有一份 index.html。用户访问 /user/profile 时，浏览器地址栏显示该路径，但 Nginx 默认按文件系统查找对应目录或文件——显然不存在 /user/profile 这个物理路径，于是返回 404。
try_files 怎么兜住所有前端路由
核心是让 Nginx 在找不到真实文件时，不直接 404，而是 fallback 到 index.html，把路由控制权交还给前端路由库。
典型配置如下：
location / {
try_files $uri $uri/ /index.html;
}
这行指令含义是：先查 $uri（如 /assets/app.js），再查 $uri/（如 /api/ 目录），最后 fallback 到 /index.html。注意顺序不能颠倒，否则静态资源也会被错误重写。
- 必须放在
location /块里，不能只写在 server 级别 -
$uri是原始请求路径，Nginx 自动解码，无需额外处理 - 如果 SPA 部署在子路径（如
/admin/），需调整 fallback 路径为/admin/index.html
哪些情况会让 try_files 失效
常见失效不是语法错，而是和其它指令冲突或路径理解偏差：
-
alias和root混用：若用alias定义根目录，try_files的 fallback 路径必须匹配 alias 的映射逻辑，否则/index.html找不到 - API 接口被误捕获：后端 API 通常走
/api/，若没单独配location /api/，它也会被try_files拦下来返回index.html，导致接口 200 但内容是 HTML - 带查询参数的路径：如
/user?id=123，$uri只取路径部分（/user），不影响匹配，但要注意前端是否依赖完整 URL
要不要加 last 或 break 标志
不需要。默认行为已足够：try_files 找到 /index.html 后，会内部重写请求并继续匹配 location，最终由该 location 的 root 或 alias 提供文件。加 last 反而可能触发无限循环（尤其配合 rewrite 时）；加 break 会跳过后续匹配，导致 MIME 类型错误或 404。
真正要小心的是：如果你在 try_files 后面写了 rewrite，或者用了 internal 标志，那整个流程就脱离了常规路径——这种组合极少需要，多数时候只是把问题复杂化。
