最直接验证Nginx是否真运行是执行nginx -t检查配置语法，再用systemctl status nginx确认active (running)且无failed；同时须核对PHP-FPM监听地址与Nginx中fastcgi_pass是否一致，并确保网站根目录及文件属主为www。
检查 Nginx 是否真在运行，而不是“看起来在”
宝塔面板里显示 Nginx 状态是“运行中”，不代表它真的能处理请求——配置语法错误、端口被占、worker 进程崩溃都可能导致服务假活。最直接的验证方式是终端里执行 nginx -t，它会报出具体哪一行配置写错了；如果通过了，再用 systemctl status nginx 看有没有 active (running) 且无红色 failed 提示。
- 别只信面板图标：点击“重启”按钮后，务必补一句
nginx -t再 reload，否则 reload 失败时面板可能不报错 - 常见坑：
server_name写成www.example.com却没绑这个域名，或用了通配符但漏了include子配置，Nginx 不报错但匹配不到请求 - 若
nginx -t报bind() to 0.0.0.0:80 failed，说明 80 端口正被其他进程（比如另一个 Nginx 实例、Python HTTP 服务）占着，用lsof -i :80查
确认 PHP-FPM 进程是否响应，而非仅“启动成功”
PHP 页面打不开，常被误判为 Nginx 问题，其实更大概率是 PHP-FPM 没接住请求：socket 文件权限不对、子进程全卡死、或监听地址和 Nginx 配置不一致。宝塔默认用 Unix socket（如 /tmp/php-cgi-74.sock），但如果你改过 PHP 版本或手动编辑过配置，得核对两头是否对得上。
- 检查 PHP-FPM 状态：
systemctl status php-fpm-74（版本号按你实际用的填），重点看最后一行是不是Active: active (running) - 验证 socket 是否可访问：
ls -l /tmp/php-cgi-*.sock，确保属主是www，权限是srw-rw----；如果不是，chown www:www /tmp/php-cgi-74.sock - Nginx 配置里
fastcgi_pass必须和 PHP-FPM 的listen值完全一致——一个是127.0.0.1:9000，另一个是/tmp/php-cgi-74.sock，就必然 502
查 error.log 要盯准“时间戳+请求路径”，别扫全屏
很多人打开 /www/wwwlogs/yourdomain.com.error.log 就从头翻，结果错过关键线索。真正的线索往往藏在你刚刷新页面那几秒的日志里，而且要结合请求路径看：是访问 /index.php 报 500？还是访问 /wp-admin 直接 404？不同路径指向不同问题层。
- 先用
tail -f /www/wwwlogs/yourdomain.com.error.log实时追日志，再浏览器刷新，立刻看到新增行 - 典型线索举例：
connect() to unix:/tmp/php-cgi-74.sock failed→ socket 问题；Permission denied→ 目录或文件权限不对；Primary script unknown→root或fastcgi_param SCRIPT_FILENAME路径拼错了 - 如果日志空空如也，说明请求根本没进 Nginx——这时候问题在防火墙、安全组或 DNS，不是 PHP 或 Nginx 配置
别跳过“网站根目录权限”这一步，尤其换过用户或传过压缩包
宝塔默认用 www 用户跑 Nginx 和 PHP-FPM，但上传文件（比如用 FTP 或宝塔文件管理器解压 ZIP）后，新文件经常属主是 root 或上传用户，导致 www 读不了。现象是首页空白、403 或 500，error.log 里却只写 Permission denied，不提哪个文件。
立即学习“PHP免费学习笔记（深入）”；
- 统一修复命令：
chown -R www:www /www/wwwroot/yourdomain.com（注意末尾斜杠别漏） - 别只改目录不改文件：有些 ZIP 解压后目录权限是 755，但文件是 600，
www用户照样打不开index.php - 上传完立即执行，比等出问题再查快得多；如果用了宝塔的“一键部署”功能，它会自动设权限，但手动传就得自己兜底
fastcgi_pass 和 listen 是否真正对齐，以及根目录下那个 index.php 文件，到底能不能被 www 用户读到。 
