try_files 本身不回源，仅按序检查文件存在性，缺失时跳转至命名 location（如 @backend）执行 proxy_pass 才实现回源；测试需确保文件不存在、用 curl 观察响应码及日志验证跳转路径。
要测试 try_files 在静态文件缓存缺失时的回源行为，核心是模拟「本地文件不存在 → 触发回源（如 proxy_pass）」的完整链路，并验证 Nginx 是否按预期跳转，而非直接返回 404 或错误响应。
确认 try_files 的基本语法与回源逻辑
try_files 本身不直接“回源”，它只是按顺序检查路径是否存在。所谓“回源”，通常指最后一条 fallback 指向一个命名 location（以 @name 开头），并在其中配置 proxy_pass 到上游服务（如后端应用或 CDN 源站）。
例如典型配置：
location /static/ {
alias /var/www/assets/;
try_files $uri @backend;
}
location @backend {
proxy_pass http://127.0.0.1:8000;
proxy_set_header Host $host;
}
这里的关键是：$uri 对应磁盘上文件；若不存在，Nginx 自动跳转到 @backend，由该 location 执行代理——这才是实际的“回源”动作。
手动触发缓存缺失并观察行为
静态文件缓存缺失通常指：
- 文件从未被请求过（磁盘无缓存副本）
- 文件被主动删除（
rm /var/www/assets/js/app.js） - 文件路径拼写错误（如请求
/static/js/appj.js，而实际是app.js）
测试步骤：
- 确保目标文件（如
/var/www/assets/css/style.css）确实不存在 - 用
curl -v http://your-domain/static/css/style.css发起请求 - 观察响应状态码（应为上游返回的 200/404/502 等，而非 Nginx 自身的 404）
- 检查
access_log中该请求是否命中@backend（可通过 log_format 加入$request_uri和$upstream_addr辅助判断）
用日志和调试工具验证执行路径
在 location 块中临时开启调试日志（需编译时含 --with-debug）：
error_log /var/log/nginx/debug.log debug;
location /static/ {
alias /var/www/assets/;
try_files $uri @backend;
}
然后查看 debug 日志中是否出现类似：
*1899898 trying to use file: "/css/style.css" "/var/www/assets/css/style.css" *1899898 file not found *1899898 using named location "@backend"
这说明 try_files 正确识别缺失并跳转。若看到 open() "/var/www/assets/..." failed (2: No such file) 后直接返回 404，则说明未进入 @backend，可能是语法错误（如漏写 @ 符号）或 location 未匹配。
避免常见陷阱
-
alias + try_files 易出错：使用
alias时，$uri是完整路径（含前缀），而alias会替换整个前缀。建议改用root配合try_files更直观 - 命名 location 必须在同级 scope：@backend 不能定义在另一个 location 内部，否则不可见
-
proxy_pass 后不要加斜杠（除非有意重写）：如
proxy_pass http://upstream/;会剥离原始 URI 前缀，可能造成上游收不到正确路径 - 忽略 root/alias 权限问题：即使文件存在，若 Nginx worker 进程无读权限，也会表现为“文件不存在”，误判为回源
