90%的502/404/空白页问题源于alias与SCRIPT_FILENAME路径逻辑不一致：alias不改变$document_root，必须用$request_filename显式指定真实PHP路径，并严格匹配location和alias结尾斜杠。
alias 配置 PHP 子目录应用时，90% 的 502/404/空白页问题，根源不是 PHP-FPM 没启、也不是权限没开，而是 alias 和 fastcgi_param SCRIPT_FILENAME 的路径拼接逻辑不一致。
location 中用 alias 时，PHP 脚本路径必须显式重写
很多人以为只要 alias 指向了 /var/www/myapp/public/，再配个 location ~ \.php$ 就能自动执行 PHP 文件——这是最大误区。Nginx 的 alias 只影响静态文件查找，它不会自动修正 $document_root 或 $fastcgi_script_name 的值。一旦你用 alias，$document_root 仍沿用 server 级的 root（或未定义），而 $fastcgi_script_name 是原始 URI，两者相加会指向一个根本不存在的路径。
比如请求 /myapp/index.php，alias /var/www/myapp/public/ 会让 Nginx 去找 /var/www/myapp/public/index.php，但若你在 PHP location 里写：
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
而 $document_root 是空或 /var/www/html，那实际传给 PHP-FPM 的就是 /var/www/html/myapp/index.php 或 /var/www/html//myapp/index.php，必然 502 或 404。
立即学习“PHP免费学习笔记（深入）”；
正确做法是：在匹配 PHP 的 location 块中，用 alias 显式重写脚本路径，或用 rewrite + fastcgi_param 手动构造：
- ✅ 推荐写法（用 alias）：
location ~ ^/myapp/(.+\.php)$ { alias /var/www/myapp/public/$1; fastcgi_pass unix:/run/php/php8.2-fpm.sock; fastcgi_param SCRIPT_FILENAME $request_filename; } - ✅ 替代写法（用 root + rewrite）：
location /myapp/ { root /var/www/myapp; } location ~ ^/myapp/(.+\.php)$ { rewrite ^/myapp/(.+\.php)$ /public/$1 break; fastcgi_pass unix:/run/php/php8.2-fpm.sock; fastcgi_param SCRIPT_FILENAME $document_root/public/$1; } - ❌ 危险写法：
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;——$document_root与alias无关，永远别信它
alias 结尾斜杠和 location 斜杠必须严格配对
alias 后是否带斜杠，直接决定 Nginx 如何截取 URI。漏掉斜杠不是“少个字符”，而是触发完全不同的路径替换规则。PHP 场景下尤其致命，因为脚本路径错一位，SCRIPT_FILENAME 就全盘失效。
假设物理路径是 /var/www/myapp/public/，里面含 index.php 和 router.php：
- ✅ 正确：
location /myapp/ { alias /var/www/myapp/public/; }→ 请求/myapp/index.php→ 映射为/var/www/myapp/public/index.php - ❌ 错误：
location /myapp/ { alias /var/www/myapp/public; }→ 请求/myapp/index.php→ 映射为/var/www/myapp/publicindex.php（中间缺斜杠，拼成一个怪文件名） - ❌ 更错：
location /myapp { alias /var/www/myapp/public/; }→ 请求/myapp/index.php→ 映射为/var/www/myapp/public/index.php✅，但请求/myapp（无尾斜杠）→ Nginx 不匹配该 location，可能落到其他块里 404
结论：location 必须以 / 结尾，alias 值也必须以 / 结尾。二者像齿轮咬合，差一齿就打滑。
try_files 回退到 index.php 时，路径前缀不能丢
ThinkPHP、Laravel、CodeIgniter 这类框架依赖前端控制器（index.php）统一处理路由。在子目录部署时，try_files 的兜底目标必须带子路径前缀，否则 Nginx 找不到那个 index.php——不是它不存在，而是 Nginx 在错误的位置找。
常见错误配置：
location /myapp/ {
alias /var/www/myapp/public/;
try_files $uri $uri/ /index.php?$query_string;
}
这里 /index.php 表示网站根目录下的 index.php，但你的入口文件其实在 /var/www/myapp/public/index.php，也就是 URL 上的 /myapp/index.php。Nginx 不会自动把 alias 映射关系“复用”到 try_files 的字符串里。
正确写法只有两种：
- ✅ 显式写前缀：
try_files $uri $uri/ /myapp/index.php?$query_string;（注意：这要求location /myapp/和alias已建立映射，Nginx 才能把/myapp/index.php解析为/var/www/myapp/public/index.php） - ✅ 用命名 location 分离逻辑：
try_files $uri $uri/ @myapp; location @myapp { rewrite ^/myapp/(.*)$ /myapp/public/index.php?$query_string last; }—— 更可控，避免路径歧义 - ❌ 用
root混搭：root /var/www/myapp; try_files $uri $uri/ /public/index.php?$query_string;—— 看似合理，但$uri包含/myapp/，拼出来是/var/www/myapp/myapp/public/index.php，多了一层
验证方法：打开 Nginx error log，设 error_log /var/log/nginx/error.log debug;，看日志里 “open() … failed” 后面的真实路径是什么。路径错，就说明 try_files 或 alias 写错了。
PHP8.2 下 fastcgi_param 必须用 $request_filename 而非 $document_root
PHP 8.2 对 SCRIPT_FILENAME 的校验更严格。旧版可能容忍路径偏差（比如多一个点、少一个斜杠），PHP 8.2 会直接拒绝执行并返回空白页或 500，且不报具体错误。这时 $request_filename 是最可靠的变量，因为它由 Nginx 在完成所有 location 匹配和 alias 替换后生成，代表“最终要读取的文件绝对路径”。
对比三个常用变量：
-
$request_filename：Nginx 内部计算出的、准备打开的文件完整路径（如/var/www/myapp/public/index.php），✅ 安全可靠 -
$document_root$fastcgi_script_name：拼接结果依赖root和原始 URI，与alias无关，❌ PHP 子目录场景下基本不可用 -
$script_filename：等价于$request_filename，但部分 Nginx 版本（尤其是某些 Debian 衍生版）在alias下行为不稳定，⚠️ 建议统一用$request_filename
所以 PHP location 块里，固定写这一行即可：
fastcgi_param SCRIPT_FILENAME $request_filename;
不需要再配 fastcgi_split_path_info，不需要算 PATH_INFO，只要确保 $request_filename 指向的是真实存在的 PHP 文件（可通过 ls -l /var/www/myapp/public/index.php 验证），PHP 8.2 就能正常加载。
容易被忽略的一点：如果项目用了 .htaccess 风格的重写（如 ThinkPHP 的 pathinfo 模式），Nginx 本身不支持 .htaccess，必须靠 rewrite 规则提前把 /myapp/user/list 改成 /myapp/index.php?s=/user/list，再交给 $request_filename 执行。否则 PHP 收到的还是原始 URI，框架路由无法识别。
