路径归一化是nginx在匹配location前自动清理uri的过程，包括合并多斜杠、解析./和../路径段；root拼接完整归一化uri，alias先剥离匹配前缀再拼接，故alias更抗归一化干扰。
路径归一化不是 Nginx 主动执行的“标准化操作”，而是其内部请求处理机制对 URI 自动进行的规范化步骤，直接影响 root 和 location 匹配结果。理解它，才能避免 404 或文件错位。
什么是路径归一化？
Nginx 在匹配 location 前，会对客户端请求的 URI 进行自动清理：
- 合并多个连续斜杠为单个斜杠（
/a//b///c→/a/b/c） - 解析并移除
./（当前目录）和../（上级目录）路径段（/a/./b/../c→/a/c） - 不处理末尾斜杠是否保留（
/api/和/api视为不同路径，除非 location 配置支持）
归一化如何影响 root 路径拼接？
root 指令的拼接逻辑是：root 目录 + 完整归一化后的 URI 路径。例如：
location /static/ {
root /var/www/assets;
}
- 请求
/static/css/app.css→ 归一化后仍是/static/css/app.css→ 实际查找/var/www/assets/static/css/app.css - 请求
/static/./img/logo.png→ 归一化为/static/img/logo.png→ 查找/var/www/assets/static/img/logo.png - 请求
/static/../public/index.html→ 归一化为/public/index.html→ 查找/var/www/assets/public/index.html（可能越权或出错）
⚠️ 注意：../ 归一化后可能跳出 root 目录范围，Nginx 默认禁止此类行为（通过 disable_symlinks 或内建限制），但若配置不当仍可能引发安全风险。
如何控制或规避归一化带来的问题？
多数情况下无需干预归一化，但需主动防御异常路径：
- 用
location ^~ /static/防止正则 location 干扰匹配顺序，确保静态路径优先被精确捕获 - 禁用路径遍历：在
server或location块中添加secure_link或使用internal;配合alias限定访问范围 - 拒绝含
..的原始 URI：用if ($request_uri ~ "\.\.") { return 403; }（注意if性能开销，仅用于兜底） - 对单页应用（SPA）等场景，用
try_files $uri $uri/ /index.html;替代简单root，让前端路由 fallback 到入口文件，避免归一化后找不到子路径的问题
root vs alias：归一化对二者的影响差异
root 拼接的是完整归一化 URI；而 alias 会先剥离 location 前缀，再拼接——这使其天然规避部分归一化副作用：
-
location /docs/ { alias /usr/share/doc/; }→ 请求/docs/nginx/faq.html归一化后仍为该路径 → 剥离/docs/→ 查找/usr/share/doc/nginx/faq.html -
location /docs/ { root /usr/share/doc/; }→ 同样请求 → 拼接为/usr/share/doc/docs/nginx/faq.html（多了一级docs）
因此，当 location 路径与文件系统结构不一致时，alias 更可靠，也更少受归一化中间路径干扰。
