PHP在Nginx下无法访问的最常见原因是fastcgi_pass指向错误或未连通，其他高频问题包括root路径错位、SCRIPT_FILENAME拼接失效、权限不足及框架未指向public目录。
fastcgi_pass 指向错误或未连通，是 PHP 在 Nginx 下无法访问的最常见原因。其他高频问题包括 root 路径错位、SCRIPT_FILENAME 拼接失效、权限不足，以及框架项目没指向 public/ 目录。
确认 php-fpm 服务状态与监听方式
PHP 脚本根本不会执行，如果 php-fpm 没在跑，或者 Nginx 连不上它。
- 运行
systemctl status php*-fpm（把*替成你装的版本，如8.1），确认状态是active (running) - 检查监听地址：默认用 Unix socket 更稳定，路径类似
/run/php/php8.1-fpm.sock；用ls -l /run/php/看文件是否存在，权限是否属www-data或nginx - 若用 TCP（如
127.0.0.1:9000），别写localhost—— DNS 解析可能卡住请求 -
php-fpm配置里（/etc/php/*/fpm/pool.d/www.conf）要确保listen.owner和listen.group与 Nginx 用户一致
location ~ \.php$ 块里必须配对的关键参数
只写 fastcgi_pass 不够，漏掉任意一个都可能导致 502、空白页或 404。
-
fastcgi_pass必须和php-fpm实际监听方式严格匹配（socket 路径或 IP:端口） -
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;—— 用$realpath_root而非$document_root，能正确解析软链接，避免路径“找不到” - 必须有
include fastcgi_params;，且它不能被重复include或覆盖；有些发行版提供snippets/fastcgi-php.conf，它已封装好常用参数，可直接用 -
fastcgi_index index.php;要存在，否则/访问时不会自动找index.php
root 指向必须精确到框架的 public/ 目录
ThinkPHP、Laravel、Symfony 等现代框架都强制单入口，root 若指向项目根目录，轻则路由 404，重则泄露 .env、config/ 等敏感文件。
- 正确写法：
root /var/www/myapp/public;（注意结尾无斜杠） - 错误写法：
root /var/www/myapp;—— 此时index.php虽能执行，但静态资源 404，且.env可被直接下载 - 若因历史原因必须
root指向项目根，改用alias：例如location / { alias /var/www/myapp/public/; }，但需同步调整try_files和index，极易出错，不推荐 -
try_files $uri $uri/ /index.php?$query_string;必须放在location /块内，不是location ~ \.php$里
权限与日志：最容易被跳过的验证环节
配置全对，但用户没权限读文件，或 Nginx worker 进程无法进入目录，照样 403 或 500。
立即学习“PHP免费学习笔记（深入）”；
- Nginx worker 用户（
www-data或nginx）需对public/及其父目录有x权限（可遍历），对public/index.php有r权限 - 运行
ls -ld /var/www/myapp和ls -l /var/www/myapp/public/，确认权限位含x（如drwxr-xr-x） - 测试时优先看 Nginx 错误日志：
tail -f /var/log/nginx/error.log，里面常直接提示 “No such file or directory”（路径错）、“Permission denied”（权限不足）、“connect() to ... failed”（fastcgi_pass不通） - 别依赖浏览器白屏或 502 —— 它们只是结果，日志才是源头
fastcgi_pass，也得 nginx -t 测试 + systemctl reload nginx + 查 error.log 三步闭环。很多问题其实就卡在 reload 后没查日志，或者改了 php-fpm 配置却忘了 systemctl restart php*-fpm。 
