nginx 中 alias 与 try_files 配合不会产生路径解析死循环，所谓“死循环”实为配置错误引发的反复内部重定向，最终触发最大重定向次数限制（默认10次）而返回500或err_too_many_redirects。
Alias 和 try_files 配合使用时不会产生“路径解析死循环”，Nginx 本身不支持递归或循环解析；所谓“死循环”其实是配置错误导致的反复内部重定向，最终触发 Nginx 的最大重定向次数限制（默认 10 次），返回 500 Internal Server Error 或浏览器报 ERR_TOO_MANY_REDIRECTS。排查重点不是“循环本身”，而是定位哪一步重定向被错误触发、为何 fallback 路径又重新匹配了当前 location。
检查 try_files 最后一个参数是否引发 location 重复捕获
这是最常见诱因。例如：
- 在
location /static/ { alias /var/www/assets/; try_files $uri $uri/ /static/index.html; }中，/static/index.html是相对路径，Nginx 会按全局root解析它，若该路径不存在，则 fallback 失败 → 返回 404；但如果同时配了error_page 404 =302 /;，就会跳转到/，而/又可能匹配另一个location /块，其中又有try_files ... /index.html，形成真跳转闭环 - 正确做法：fallback 必须是绝对路径（如
/var/www/assets/index.html）或能明确指向静态文件的 URI（如@fallback），且命名 location 不应再匹配原 location 前缀
验证 $request_filename 是否与预期物理路径一致
alias 修改的是文件系统路径，但不改变 $uri；try_files 若用 $uri 就会查错位置。关键调试手段：
- 在对应 location 中临时加入日志：
access_log /var/log/nginx/alias_debug.log main; log_format main '$remote_addr - $uri → $request_filename'; - 访问
/static/js/app.js，观察日志输出：
— 若$request_filename是/var/www/assets/js/app.js，说明 alias 生效；
— 若$uri是/static/js/app.js，而$request_filename却是/var/www/html/static/js/app.js，说明 root 干扰或 alias 未生效（比如 location 末尾缺/或 alias 路径末尾多/）
确认 alias 与 location 前缀严格对齐
alias 的路径截断依赖 location 完全匹配前缀，任何偏差都会导致拼接错位：
-
location /static/+alias /var/www/assets/;→ 请求/static/js/app.js映射为/var/www/assets/js/app.js（正确） -
location /static（无结尾斜杠） +alias /var/www/assets/;→ 请求/static/js/app.js会被截成t/js/app.js，拼成/var/www/assets/t/js/app.js（严重错位） -
location /static/+alias /var/www/assets;（缺结尾斜杠）→ 拼成/var/www/assetsjs/app.js（漏斜杠）
避免 rewrite 与 try_files 在同一 location 内共存
二者逻辑冲突极易闭环：
- 错误示例：
location /app/ { alias /opt/app/dist/; rewrite ^/app/(.*)$ /$1 last; try_files $uri =404; }
— rewrite 后请求变成/js/app.js，又被location /或其他规则捕获，可能再次进入 alias 块 - 正确解法：删掉 rewrite，用 root + try_files 替代；或确保 rewrite 的目标 URI 不会重新落入当前 alias location 范围
不复杂但容易忽略。
