发布于2026-07-11 阅读(0)
扫一扫,手机访问
聊Lara vel的Nginx配置,说实话真的不算什么高深的技术活,但偏偏就是这里最容易出问题。很多新手甚至有些经验的开发者,都会在这一步卡住,然后跑去翻日志。先说个最常见的坑:root指向错了。
很多人习惯把 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 就会直接 404fastcgi_pass 要跟你的 PHP-FPM 实际监听地址对应上,常见翻车案例是写成 127.0.0.1:9000 但实际根本没开 TCP 监听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,这完全是冗余配置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() 检查直接跪掉www-data)必须对 storage/ 和 bootstrap/cache/ 有写权限,否则 php artisan config:cache 之后立马给你报错上线之后加 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 默认不会带上它,容易丢参数$_SERVER['HTTP_X_FORWARDED_PROTO'],并在 Lara vel 的 AppServiceProvider 里调用 URL::forceScheme('https')说到底,Lara vel 的 Nginx 配置难点真不在语法本身,而在于路径解析、权限边界还有环境差异这些细节。哪怕一行 $realpath_root 写错了,或者少了一个分号,都可能让日志里只显示一句 "recv() failed",而你根本不知道问题出在哪。可以确定的是,把这些细节吃透了,后面再怎么折腾都不会慌。
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
正版软件
正版软件
正版软件
正版软件
正版软件
1
2
3
7
8