在 nginx 中实现文件服务器的本地缓存兜底，核心做法是利用 try_files 指令按优先级依次尝试匹配资源。具体操作是配置一个列表，先检查请求的文件是否存在（如 $uri），若存在则直接返回；若不存在，再指向一个预定义的静态错误页面或默认首页（如 /index.html）。这样当用户访问不存在的文件时，nginx 不会返回默认的 404 状态码，而是“兜底”展示你指定的内容，从而实现友好的错误处理或单页应用的路由支持。
如何配置 try_files 实现基础的文件存在性检查与默认页跳转
要实现基础的兜底功能，需要在 location 块中定义 try_files 的查找序列。通常第一个参数是当前请求的 URI，第二个参数是一个固定的文件名或路径。如果第一个参数对应的文件在磁盘上找不到，Nginx 会内部重定向到第二个参数指定的位置。例如，将 $uri 和 /fallback.html 组合，就能确保任何未找到的请求都回退到 fallback.html。这种配置简单直接，适用于大多数需要统一错误页面的场景。
server {
listen 80;
server_name example.com;
root /var/www/html;
location / {
# 先尝试找实际文件，找不到则返回 fallback.html
try_files $uri $uri/ /fallback.html;
}
}
上述配置中，/var/www/html 是根目录。当请求 /style.css 时，Nginx 首先检查 /var/www/html/style.css 是否存在。如果存在，直接返回该文件。如果不存在，它接着检查 /var/www/html/style.css/（即是否为目录），如果还不是目录，最后执行内部重定向到 /fallback.html。注意，最后的 /fallback.html 必须以斜杠开头，表示它是相对于根目录的内部 URI，而不是文件系统上的相对路径。
如何处理 SPA 应用的路由兜底与静态资源分离
对于单页应用（SPA），前端路由依赖 JavaScript 处理 URL 变化，因此所有非静态资源的请求都应回退到 index.html。此时，try_files 的配置需要区分静态文件和动态路由。最佳实践是先列出常见的静态文件扩展名（如 .js, .css, .png），确保它们优先被命中，避免不必要的 index.html 加载。如果这些静态文件都不存在，则最后回退到 /index.html。这种策略既保证了静态资源的快速响应，又确保了 SPA 路由的正确工作。
server {
listen 80;
server_name app.example.com;
root /var/www/spa;
location / {
# 优先尝试静态文件，最后回退到 index.html
try_files $uri $uri/ /index.html;
}
# 可选：为静态资源设置长期缓存
location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}
}
在这个配置中，当用户刷新一个深度链接如 /dashboard/settings 时，Nginx 会在 /var/www/spa 下寻找名为 dashboard/settings 的文件或目录。由于 SPA 项目中通常没有这样的物理文件或目录，try_files 会失败并回退到 /index.html。浏览器接收到 index.html 后，前端框架接管路由，显示正确的视图。同时，独立的 location 块为静态资产设置了强缓存，提升了性能。
当 try_files 最后一个参数是内部重定向时，循环检测机制是如何工作的
在使用 try_files 进行兜底时，必须避免配置错误导致的内部重定向循环。Nginx 有一个内置机制来防止这种情况：如果 try_files 列出的所有选项都失败，且最后一个选项是一个以 = 开头的状态码（如 =404）或一个已经处理过的 URI，Nginx 会停止重试并返回相应的错误或状态。然而，如果最后一个参数是一个普通的 URI（如 /index.html），Nginx 会发起一个新的内部请求。如果这个新请求再次触发相同的 try_files 逻辑且依然失败，Nginx 会检测到循环并终止请求，返回 500 错误。因此，确保兜底目标（如 index.html）确实存在于文件系统中是关键。如果 index.html 也不存在，就会引发循环错误。验证方法是检查根目录下是否真的存在兜底文件，或者使用 =404 作为最终兜底来明确返回 404 而非循环。
