nginx处理空url（/）时，先匹配location（优先精确匹配location = /，其次location /），再依序执行index查找默认文件、try_files内部重定向或目录自动301跳转（当root为目录且无index/try_files时）。
当客户端发起一个“空 URL”请求（比如 GET / HTTP/1.1），Nginx 并不会直接返回 404，而是按预设规则尝试定位默认资源或触发重定向。这个过程不是单一动作，而是贯穿多个处理阶段的协同行为，核心围绕 location 匹配 → 默认文件查找 → 重写/跳转决策 → 内容生成 展开。
空 URL 如何匹配 location
空 URL 实际上是 URI 为 / 的请求。Nginx 首先根据 Host 头找到对应 server 块，再进入 NGX_HTTP_FIND_CONFIG_PHASE 阶段匹配 location。此时最常命中的是：
-
location / { ... }—— 前缀匹配，兜底规则 -
location = / { ... }—— 精确匹配，优先级更高 - 若存在
location ^~ /static/等更长前缀，但请求是/，仍走/分支
注意：匹配发生在所有重写之前，所以 server 或 location 中的 rewrite 指令是否生效，取决于它所处的阶段（如 server_rewrite_phase 可能提前改写 URI）。
index 指令如何触发默认文件查找
一旦 location 匹配成功，且该 block 中配置了 index 指令（如 index index.html index.htm;），Nginx 就会在 NGX_HTTP_CONTENT_PHASE 阶段启动文件探测流程：
- 它会依次尝试拼接 URI 与每个 index 文件名，形成候选路径：例如
/index.html、/index.htm - 对每个路径调用文件系统检查（stat），确认是否存在且可读
- 只要找到第一个合法文件，就直接作为响应体返回（状态码 200），不再执行后续
try_files或proxy_pass - 若全部失败，且未配置
try_files，则继续走当前 location 的其他指令（如 fallback 到proxy_pass）
try_files 如何接管并可能触发重定向
当配置了 try_files（如 try_files $uri $uri/ /index.html =404;），它在 NGX_HTTP_TRY_FILES_PHASE 执行，优先级高于 index。对空 URL / 的处理逻辑如下：
-
$uri→ 对应/，检查根目录下是否有名为/的文件（几乎不存在）→ 跳过 -
$uri/→ 对应//？实际等价于检查/是否为目录 → 若根路径是目录，则内部重写 URI 为/并追加斜杠，即变成/→ 触发 directory listing 或再次匹配 location（常见于开启autoindex on） - 若前两项都失败，最后一项
/index.html会被当作新 URI 发起内部重定向（internal redirect），重新进入 FIND_CONFIG_PHASE，再次匹配 location，最终由index或静态文件模块服务 - 注意：
try_files的重定向是内部的，不发 301/302 给客户端；只有显式使用return 301或rewrite ... redirect才会对外跳转
什么情况下会返回 301 重定向到带斜杠的 URL
这是用户常困惑的点：为什么访问 http://example.com 有时自动跳成 http://example.com/？这并非 index 或 try_files 导致，而是由 NGX_HTTP_CONTENT_PHASE 中的目录处理机制触发：
- 当请求 URI 是
/，且匹配的 location 指向一个真实存在的目录（如root /var/www/html;，而/var/www/html是目录） - 同时该 location 未配置
index，也未配置try_files，且未启用autoindex - 此时 Nginx 认为“/ 应该是一个目录入口”，为避免歧义（比如防止把
/api错当成/api/的子路径），会主动返回301 Moved Permanently，Location 头设为/（即自身），浏览器刷新后带斜杠 - 这个行为由
ngx_http_index_module和核心目录判断逻辑共同控制，不可禁用，但可通过添加index指令或try_files显式覆盖
