nginx 中 alias 和 try_files 混用易出问题，根本原因是二者路径处理逻辑冲突：alias 执行截断拼接但不改变 $uri，而 try_files 仍基于原始 $uri 和 root 查找文件，导致路径错位 404；正确解法是优先用 root 替代 alias，或非用 alias 时改用 $request_filename。
Nginx 中 alias 和 try_files 混用容易出问题，根本原因在于二者对请求路径的处理逻辑不兼容。
alias 是一次性路径替换，而 try_files 是基于 root 上下文做文件存在性检查——它并不知道 alias 已经改过路径。
alias 的行为是“截断 + 拼接”
- 它会把匹配到的
location前缀（比如/static/）完全移除； - 然后把剩下的 URI（如
js/app.js）直接拼到 alias 指定的目录后面； - 最终得到真实文件路径，例如：
/var/www/assets/js/app.js。
但这个过程只影响 Nginx 内部的文件定位，不会改变 $uri、$uri/ 这些变量的值。
try_files 默认按 root 解析路径
-
try_files $uri $uri/ =404;中的$uri仍是原始请求 URI（如/static/js/app.js）； - Nginx 会尝试在
root所设目录下找这个完整路径，比如/var/www/html/static/js/app.js； - 而不是去
alias指向的/var/www/assets/下找 —— 结果自然 404。
所以限制本质是语义冲突
-
alias本意是“换个地方找文件”，但它不提供新的上下文给try_files； -
try_files又坚持用自己的规则查文件，且不自动适配alias的映射结果。
这就导致：
- 直接写
try_files $uri =404;在alias块里基本无效； - 写
try_files $uri/可能误判目录是否存在； - 用
@named_location作 fallback 时，路径错位可能引发循环或 500。
正确解法只有两种
-
优先用
root替代alias：语义清晰，$uri自然拼接正确，try_files行为可预测； -
非用
alias不可时，必须用$request_filename：它是alias处理完后的绝对路径，try_files $request_filename =404;才真正有效。
不复杂但容易忽略。
