商城首页欢迎来到中国正版软件门户

您的位置: 首页 > 文章列表 > 编程开发 > Laravel怎么配置Nginx_LaravelNginx站点配置方法【操作】

Laravel怎么配置Nginx_LaravelNginx站点配置方法【操作】

  发布于2026-07-11 阅读(0)

扫一扫,手机访问

聊Lara vel的Nginx配置,说实话真的不算什么高深的技术活,但偏偏就是这里最容易出问题。很多新手甚至有些经验的开发者,都会在这一步卡住,然后跑去翻日志。先说个最常见的坑:root指向错了。

location / 要指向 public/ 目录,不是项目根目录

很多人习惯把 root 设成 Lara vel 项目根目录,比如 /var/www/myapp,结果一访问,好家伙,app/vendor/ 这些敏感目录直接暴露在浏览器里了,运气不好的还能看到 Index of / 列表。Lara vel 的入口只有一个 public/index.php,所以 Nginx 必须从这里开始接管请求。

正确做法很简单,root 直接指向 public/ 子目录就行:

server {
    listen 80;
    server_name example.com;
    root /var/www/myapp/public;  # ← 关键:必须是 public/
    index index.php;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        include fastcgi_params;
    }
}

这里有几个细节要留意一下:

  • $realpath_root$document_root 更靠谱,尤其在使用了符号链接的部署场景里,它能避免路径解析出错
  • try_files 一定不能漏,少了它,静态资源比如 /css/app.css 就会直接 404
  • fastcgi_pass 要跟你的 PHP-FPM 实际监听地址对应上,常见翻车案例是写成 127.0.0.1:9000 但实际根本没开 TCP 监听

rewrite 规则不能少,否则 Lara vel 路由 404

Nginx 默认是不认识 Lara vel 路由的,所有非静态资源的请求都得交给 index.php 去分发。光靠 location /try_files 还不够,碰到一些特殊的 URL——比如带点号的或者多层级嵌套的,就可能被提前截断。

稳妥的做法是显式重写所有非静态文件请求:

location / {
    try_files $uri $uri/ @lara vel;
}

location @lara vel {
    rewrite ^(.*)$ /index.php?$query_string last;
}

这里有几个常见误区:

  • 不要用 return 301 或者 proxy_pass,这是 PHP-FPM 场景,不是反向袋里
  • 如果项目用了多语言路由,比如 /zh/about 这种,务必确保 $query_string 被完整传递,否则 app()->getLocale() 可能拿不到正确值
  • 还有人习惯加一条 location ~ /\.ht 的规则,其实 Nginx 根本不读 .htaccess,这完全是冗余配置

PHP-FPM 权限和 PATH_INFO 配置不到位,502/500 随机出现

502 Bad Gateway 算是比较好排查的,多半是 PHP-FPM 进程没响应。但真正让人头疼的是 500 错误,而且日志里啥也看不到——因为 SCRIPT_FILENAME 解析错了,或者 PATH_INFO 为空,导致 Lara vel 认不出当前路由。

关键两行必须存在,而且顺序不能乱:

fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;

再强调几点:

  • 缺了 PATH_INFO,Lara vel 的 Request::path() 会返回空值,所有路由匹配全部失败
  • $document_root 替代 $realpath_root?在 Lara vel Envoyer、Capistrano 这类用了符号链接的部署方式里,$document_root 可能指向软链本身而不是真实路径,file_exists() 检查直接跪掉
  • PHP-FPM pool 用户(比如 www-data)必须对 storage/bootstrap/cache/ 有写权限,否则 php artisan config:cache 之后立马给你报错

HTTPS 和 www 重定向容易写死,后续难调试

上线之后加 HTTPS 或者强制 www 域名,很多人直接在 server 块里硬编码 return 301 https://...,结果本地开发环境也被强制跳转,CDN 回源也失败,调试起来非常痛苦。

更安全的做法是依赖 $scheme$host 做动态判断:

if ($scheme != "https") {
    return 301 https://$host$request_uri;
}

这里有几个关键点:

  • 不要用 rewrite ^(.*)$ https://...rewrite 是字符串替换,$request_uri 本身包含 query string,而 rewrite 默认不会带上它,容易丢参数
  • 如果用了 Cloudflare 或者阿里云 SLB,它们可能会以 HTTP 方式回源,这时候要检查 $_SERVER['HTTP_X_FORWARDED_PROTO'],并在 Lara vel 的 AppServiceProvider 里调用 URL::forceScheme('https')
  • 重定向规则一定要放在主 server 块最前面,否则可能被 location 块拦截,变成 404 而不是跳转

说到底,Lara vel 的 Nginx 配置难点真不在语法本身,而在于路径解析、权限边界还有环境差异这些细节。哪怕一行 $realpath_root 写错了,或者少了一个分号,都可能让日志里只显示一句 "recv() failed",而你根本不知道问题出在哪。可以确定的是,把这些细节吃透了,后面再怎么折腾都不会慌。

本文转载于:https://www.php.cn/faq/2382024.html 如有侵犯,请联系zhengruancom@outlook.com删除。
免责声明:正软商城发布此文仅为传递信息,不代表正软商城认同其观点或证实其描述。

热门关注