fastcgi_index仅在URI以/结尾且未命中静态文件时补全脚本名，必须配合正确的SCRIPT_FILENAME才能生效，不替代index指令或单独触发索引行为。
在 Nginx 中，fastcgi_index 指令本身**不直接控制 server 块的索引文件行为**，它只在使用 fastcgi_pass 将请求代理给 FastCGI 后端（如 PHP-FPM）时起作用，且**必须配合 fastcgi_param SCRIPT_FILENAME 的正确构造才能生效**。它不会替代 index 指令，也不能单独让 Nginx 自动查找并转发 index.php。
fastcgi_index 的真实作用
fastcgi_index 仅用于补全“未显式指定脚本文件名”的 URI。例如用户访问 /blog/（末尾有斜杠），而该路径映射到一个 FastCGI 处理器时，Nginx 会尝试将 fastcgi_index 的值（如 index.php）拼接到 URI 后，形成 /blog/index.php，再通过 fastcgi_param SCRIPT_FILENAME 计算出实际磁盘路径。
⚠️ 注意：这个拼接仅发生在 URI 以 / 结尾 且 未命中静态文件 时；如果 URI 是 /blog（无斜杠），它不会触发。
server 块中索引文件的完整链路
要让 / 或 /dir/ 正确运行 index.php，需协同配置以下三项：
-
index指令：定义默认索引文件列表（如index index.php index.html;）。Nginx 先按此顺序检查是否存在对应静态文件。 -
location 匹配与 try_files：常用
try_files $uri $uri/ /index.php?$query_string;，确保当 URI 不是真实文件或目录时，兜底转发给 index.php。 -
FastCGI 参数传递：在处理
.php请求的 location 中，必须设置fastcgi_param SCRIPT_FILENAME为实际磁盘路径（通常用$document_root$fastcgi_script_name），否则fastcgi_index的拼接结果无法定位脚本。
典型 PHP 站点 server 块示例
以下配置支持访问 /、/admin/ 自动运行对应目录下的 index.php：
server {
listen 80;
root /var/www/example;
index index.php index.html;
<pre class="brush:php;toolbar:false;">location / {
try_files $uri $uri/ /index.php?$query_string;
}
location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php; # 此行在此处实际影响较小，因 try_files 已明确转发
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}}
说明：fastcgi_index index.php 在该配置中并非关键——真正起作用的是 try_files 把 / 和 /admin/ 都重写为 /index.php 或 /admin/index.php，再由 SCRIPT_FILENAME 解析为磁盘路径。只有当你用 location ~ ^/api/ 这类不带 try_files 的粗粒度匹配时，fastcgi_index 才可能被用到。
常见误区与验证方法
容易误以为设了 fastcgi_index 就能自动跑 index.php，但实际常因以下原因失败：
-
SCRIPT_FILENAME路径错误（如漏掉$document_root），导致 PHP-FPM 报 “No input file specified” - 没配
index指令或try_files，Nginx 直接返回 403/404，根本不会进入 FastCGI 流程 - URI 不以
/结尾（如访问/test而非/test/），fastcgi_index完全不触发
调试建议：开启 error_log /path/to/error.log debug;，查看 Nginx 是否执行了 fastcgi_index 拼接，以及 SCRIPT_FILENAME 最终值是否正确。
