Nginx index指令的默认首页配置顺序是怎样的？如何正确修改优先级？

当用户访问一个网址的根路径时，比如直接打开 https://ipipp.com/，Nginx并不会把目录列表返回给用户，而是尝试找到目录下预先定义的默认首页文件返回。这个行为由 index 指令控制。理解 index 指令的查找顺序，是解决首页显示异常、优先级混乱这类问题的基础。很多看似奇怪的首页现象，其实都源于对这条指令工作机制的误解。

index指令的基本工作机制

index 指令属于 ngx_http_index_module 模块，作用是指定当请求以斜杠结尾（即请求的是一个目录）时，应该依次尝试返回哪些文件。Nginx出厂默认值是：

index index.html;

也就是说，如果没有任何额外配置，访问目录时Nginx只会找 index.html 这一个文件。而常见的LNMP一键安装包或者发行版自带的配置文件，通常会写成更完整的列表：

index index.html index.htm index.php;

关键点在于查找顺序：Nginx严格按照文件名在 index 指令中出现的先后顺序依次检测。请求到来时，Nginx先检查第一个文件在磁盘上是否存在，如果存在就直接以内部重定向的方式发起对该文件的新一轮请求；如果不存在，再检查第二个，以此类推。注意这里说的是磁盘上是否存在，与文件的修改时间、权重设置都没有关系，纯粹是顺序匹配。

举一个具体例子，假设站点根目录 /usr/share/nginx/html 下同时存在 index.html 和 index.php 两个文件，配置如下：

server {
    listen 80;
    root /usr/share/nginx/html;

    location / {
        index index.html index.php;
    }
}

由于 index.html 排在前面且真实存在，访问首页时永远返回静态的 index.html，后面的 index.php 根本不会被检查。如果想让PHP首页优先生效，必须把它挪到最前面，写成 index index.php index.html;。这也是为什么有些开发者部署完PHP应用后发现首页仍然是旧的静态页面——顺序没调对。

index命中后的内部重定向与location匹配

index 指令找到匹配文件后，并不是直接读取文件返回，而是发起一次内部重定向，等同于客户端重新请求了 /index.html 这个URI。这个URI会重新走一遍location匹配流程。这一点非常重要，因为它意味着命中文件可能落到一个完全不同的location块里处理。

典型的场景就是PHP应用。静态文件和PHP脚本往往配置在不同的location中：

server {
    listen 80;
    root /var/www/app;

    location / {
        index index.php index.html;
    }

    location ~ \.php$ {
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_index index.php;
        include fastcgi.conf;
    }
}

上面的配置中，请求 / 时 index 优先匹配到 index.php，随后内部重定向到 /index.php，这个请求命中了正则location ~ \.php$，于是被转发给PHP-FPM处理，最终返回动态渲染的页面。整个流程对客户端完全透明，浏览器地址栏始终只显示域名。

如果命中的文件在所有location里都找不到对应的处理方式，或者文件实际不存在，Nginx会继续尝试 index 列表中的下一个名字。但这里有个容易踩的坑：如果 index 列表中所有文件都不存在，且最后一个参数是以斜杠结尾的URI（例如 index index.html /fallback.php;），Nginx会直接内部重定向到该URI而不再检查它是否存在。可以利用这个特性做首页兜底跳转，但如果写错了路径，就会导致首页请求进入死循环，报出500错误并出现 rewrite or internal redirection cycle 日志。

多层级配置与优先级覆盖规则

index 指令可以出现在 http、server、location 三个层级，遵循Nginx标准的继承规则：内层配置覆盖外层，且是完全覆盖而非合并。如果在 http 块写了 index index.html index.php;，而在某个 location 里又写了 index index.htm;，那么该location生效的只有 index.htm，外层的列表在这个location里完全失效。

http {
    index index.html index.htm;

    server {
        listen 80;
        root /var/www/site;

        # 继承http层的index配置
        location /blog/ {
            root /var/www;
        }

        # 完全覆盖，只有app.php会被查找
        location /api/ {
            index app.php;
        }
    }
}

排查首页问题时，首先要确认当前请求命中的是哪个location块，再看该块内以及它所属的server、http块中的 index 配置。可以使用 nginx -T 输出完整生效配置，快速定位继承链上的覆盖关系。另一个高频错误是把 index 写在了不匹配请求的location里，比如静态资源单独拆分后，首页请求实际落入的location没有任何index配置，就只能继承上层或使用默认值。

常见问题与排查思路

第一个常见问题是403 Forbidden。当 index 列表中所有文件都不存在，且目录没有开启 autoindex 时，Nginx会返回403。此时应检查站点根目录下是否有配置中声明的首页文件，文件名大小写是否完全一致（Linux文件系统区分大小写，Index.html 和 index.html 是两个不同的文件），以及运行Nginx的worker进程用户对目录是否具备读取和执行权限。

第二个问题是首页被下载而不是被执行。这说明命中的PHP文件没有被转发给FastCGI处理，通常是正则location没有正确配置，或者 index 列表里PHP文件排在后面而静态文件先被命中。检查php相关location是否存在、fastcgi_pass地址是否正确即可解决。

第三个问题是修改了配置不生效。改完 index 顺序后务必执行 nginx -t 验证语法，再用 nginx -s reload 平滑重载。另外浏览器可能缓存了旧页面，建议用 curl -I http://ipipp.com/ 直接验证响应头，排除客户端缓存干扰。掌握这些排查路径，配合对 index 查找顺序和内部重定向机制的理解，绝大多数首页相关的问题都能在几分钟内定位解决。

Nginx index默认首页配置顺序修改时间：2026-09-08 09:33:56