Nginx未生效是因配置未加载或被覆盖：需确认conf-path路径、检查include规则、软链至sites-enabled、nginx -t验证语法、nginx -s reload重载、排查旧进程、调整server块优先级、验证PHP-FPM连通性。
修改完 Laravel 的 Nginx 配置后刷新页面仍是旧行为、404 不变、500 依旧、甚至 index.php 被直接下载——这不是 Laravel 代码有问题，而是 Nginx 根本没加载你刚改的配置文件，或加载了但被其他规则覆盖、静默忽略。
确认改的是正在用的配置文件
运行 nginx -V 2>&1 | grep "conf-path"，查看输出中 conf-path 指向的路径（例如 /etc/nginx/nginx.conf），这才是 Nginx 启动时实际读取的主配置文件。
打开该文件，检查是否包含 include /etc/nginx/conf.d/*.conf; 或类似行；若没有，你放在 /etc/nginx/conf.d/default.conf 的修改根本不会被加载。
如果主配置里 include 的是 /etc/nginx/sites-enabled/*，那你必须把配置软链过去：ln -sf /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/myapp，而不是只丢在 sites-available 里。
验证语法并重载，不是重启
执行 nginx -t。如果报错，终端会明确指出哪一行、哪个文件出问题，必须修复后再继续。
语法通过后，不要用 systemctl restart nginx，改用 nginx -s reload。restart 会杀掉主进程再拉起，reload 是平滑重载，能避免请求中断，更重要的是——它强制所有 worker 进程重新解析配置树。
这一步漏掉，哪怕配置完全正确，Nginx 仍可能沿用内存中缓存的老配置，表现为“改了等于没改”。
排查残留旧进程干扰
执行 ps aux | grep nginx，观察 master 进程的启动时间是否晚于你执行 reload 的时间。如果 master 进程时间很老，说明 reload 失败或被跳过。
执行 killall nginx → 等 3 秒 → 再执行 nginx 手动启动。这能彻底清空所有旧进程和内存状态，排除多实例共存导致的配置错乱。
注意：此操作会短暂中断服务，生产环境请安排在低峰期。执行前确认 nginx -t 已通过，否则启动会失败。
检查 location 匹配优先级
方法一：删掉所有无关的 server 块，只保留一个最简配置，内容如下：
server {<br> listen 80;<br> server_name _;<br> root /var/www/myapp/public;<br> index index.php;<br> location / {<br> try_files $uri $uri/ /index.php?$query_string;<br> }<br> location ~ \.php$ {<br> fastcgi_pass unix:/run/php/php8.2-fpm.sock;<br> fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;<br> include fastcgi_params;<br> }<br>}
方法二：在现有配置中，把 Laravel 的 server 块移到 nginx.conf 最顶部，并在 server_name 后加 default_server，确保它成为默认匹配项，避免被其他泛域名或 IP 绑定的 server 块劫持请求。
方法三：临时在 location / 块内加一行 return 200 "Laravel config loaded";，然后 curl 测试。如果返回字符串，说明该块已生效；如果返回 404 或旧页面，说明请求根本没进这个 location。
验证 PHP-FPM 是否真正连通
第一步：确认 PHP-FPM 服务正在运行：systemctl is-active php8.2-fpm（版本号按实际替换）。
第二步：检查 fastcgi_pass 地址是否与 PHP-FPM 监听地址一致。常见错误是写成 127.0.0.1:9000，但 PHP-FPM 实际监听的是 Unix socket（如 unix:/run/php/php8.2-fpm.sock）——两者不匹配会导致 502。
第三步：在 Nginx error.log 中搜索 connect() failed 或 No such file or directory，这类日志直接暴露连接失败根源。
第四步：手动测试 PHP 解析能力。在 /var/www/myapp/public 下新建 info.php，内容为 <?php phpinfo(); ?>，浏览器访问 http://yourdomain.com/info.php。如果显示 PHP 信息页，说明 PHP-FPM 通路正常；如果下载文件或 502，问题一定出在 fastcgi_pass 或权限上。
