Laravel 的 cookie 域名参数(SESSION_DOMAIN)只有在设置为带点前缀的父级域名(如 .example.com)时,才能在同一主域下的不同子域名之间实现会话共享;跨完全不同主域名(如 a.com 和 b.com)无法通过 cookie domain 参数实现跨域生效。
Laravel cookie domain 参数到底控制什么
Laravel 里的 cookie 域名参数并不神秘,它就是 PHP 原生 setcookie 函数中 domain 参数的封装,浏览器会根据这个值判断“当前访问的域名是否应该携带这个 cookie”。
- 不设置
SESSION_DOMAIN:默认留空,Laravel 会把 cookie 绑定到当前完整主机名,admin.example.com就只发给admin.example.com。 - 设置为
admin.example.com:效果和不设置基本一样,cookie 只在这个子域名下有效。 - 设置为
.example.com:带上前缀点之后,浏览器会把 cookie 发送给example.com以及它下面的www.example.com、admin.example.com、api.example.com等所有子域名。
这个参数只对同一个注册域内部的子域名共享有效,行业共识认为,Cookie 的 domain 属性只能覆盖当前域及其子域,无法扩展到完全不同的注册域。shop.example.com 和 blog.example.com 可以共享,但 example.com 和 another.com 做不到。
laravel cookie跨域设置常见误区
很多开发者第一次配置时栽跟头,不是因为代码写错,而是对域名层级理解有偏差,下面这张表列出了常见配置值和实际结果。
| 配置值 | 实际作用范围 | 能否跨子域 |
|---|---|---|
| 留空或 null | 仅当前完整主机 | 不能 |
http://example.com |
无效值,带协议会被浏览器拒绝 | 不能 |
example.com |
浏览器通常按 .example.com 处理 |
多数情况能 |
.example.com |
所有子域名加主域 | 能 |
api.example.com |
仅 api 子域 | 不能 |
常见误区集中在三类:
- 把
SESSION_DOMAIN写成前端地址或后端接口地址,http://localhost:3000,这是典型错误,domain 参数不接受协议和端口。 - 以为只要设置 domain 就能跨不同主域名。
a.com和b.com完全独立,Cookie 根本不会发送过去。 - 只改
.env文件不清理缓存,导致旧配置继续生效,Laravel 的配置会被缓存,必须执行php artisan config:clear或php artisan config:cache才能让新值生效。
laravel cookie domain 跨域不生效排查步骤
设置 SESSION_DOMAIN=.example.com 之后,如果登录状态仍然无法在子域名之间保持,按下面顺序逐项检查,多数情况下能定位问题。
检查 .env 是否真的改对了
打开项目根目录的 .env 文件,确认这一行:
SESSION_DOMAIN=.example.com
不要加引号,不要写 http://,不要有多余空格,改完执行:
php artisan config:clear
php artisan config:cache
检查 config/session.php 是否覆盖了环境变量
Laravel 的 config/session.php 里默认是:
'domain' => env('SESSION_DOMAIN', null),
有些开发者会直接把值硬编码进去,或者误写为 'domain' => 'example.com',这样即使 .env 正确也会被覆盖,确认这里使用 env() 函数读取即可。
清除浏览器旧 cookie
旧 cookie 的 domain 是 api.example.com,即使服务端重新下发新 domain,浏览器可能会优先使用本地旧 cookie,导致看起来“没生效”,在浏览器开发者工具 Application → Cookies 中删除对应站点的 cookie,然后重新登录。
检查 SameSite 和 Secure 属性
现代浏览器对跨站请求携带 cookie 有严格限制,如果前后端分离,前端通过 fetch 或 axios 跨域请求后端接口,必须在 cookie 配置中同时设置:
SESSION_SAME_SITE=lax
SESSION_SECURE_COOKIE=false
如果线上全站 HTTPS,SESSION_SECURE_COOKIE 应设为 true,SameSite 为 strict 时跨站请求不会携带 cookie,即使 domain 设置正确也无法共享。lax 可以在大部分场景下正常工作,
none 则需要同时设置 secure=true。
业内专家指出,排查跨域 Cookie 问题时先确认浏览器是否真的收到了 Set-Cookie 响应头,再检查 domain 和 SameSite 配置,能少走很多弯路。
Laravel 多域名 cookie 共享方案对比
实际项目里经常出现两种情况:一种是同一个项目拆成多个子域名模块,另一种是前端和后端部署在不同主域名,两种处理方式完全不同。
同一主域下的子域名共享
这是 SESSION_DOMAIN 最适合的场景。
- 前端管理后台:
admin.example.com - 后端 API:
api.example.com - 用户中心:
user.example.com
只需要在 .env 中设置:
SESSION_DOMAIN=.example.com
前端发起请求时带上凭证:
axios.defaults.withCredentials = true;
后端 CORS 中间件中设置:
'supports_credentials' => true, 'allowed_origins' => ['https://admin.example.com'],
这样三个子域名之间的登录态就能自动保持。
完全不同主域名之间的共享
如果前端是 www.a.com,后端是 api.b.com,cookie domain 参数无法跨域生效,这是浏览器安全模型决定的,没有任何配置技巧可以绕过,此时只能改用以下方案:
- 后端返回 token(如 JWT、Passport、Sanctum),前端存入内存或
localStorage,请求时放在Authorization头。 - 使用 OAuth 2.0 授权码模式,在不同主域之间跳转换取令牌。
- 通过同主域的代理网关转发请求,把跨域问题转换为同域问题。
下表对比两种场景的适用方案:
| 场景 | 推荐方案 | Cookie 是否共享 |
|---|---|---|
admin.example.com + api.example.com |
SESSION_DOMAIN=.example.com |
是 |
www.example.com + api.example.com |
SESSION_DOMAIN=.example.com |
是 |
www.a.com + api.b.com |
JWT / Sanctum token | 否,改用请求头 |
laravel cookie domain 参数怎么写才规范
参数写法决定了跨域能否生效,这里给出几种正确和错误示例。
正确写法:
SESSION_DOMAIN=.example.com
错误写法:
SESSION_DOMAIN=http://.example.com
SESSION_DOMAIN=.example.com:8080
SESSION_DOMAIN=example.com/path
SESSION_DOMAIN=.
关键点:
- 域名开头要带一个点 。
- 不能包含协议、端口、路径。
- 不能是顶级域名如
.com,浏览器会拒绝。 - 本地开发时常用
SESSION_DOMAIN=.localhost或直接留空,用localhost加上端口访问即可。
常见问题:Laravel cookie域名参数跨域配置相关疑问
laravel cookie domain 参数怎么写才能跨子域共享?
写成带点前缀的父级域名,.example.com,如果主域是 myapp.cn,就写 SESSION_DOMAIN=.myapp.cn,改完执行 php artisan config:clear,并在前端请求中开启 withCredentials。
为什么设置了 SESSION_DOMAIN=.example.com 后 laravel cookie 跨域不生效?
多数情况下是浏览器还保留着旧域名下的 cookie,或者 SameSite 属性过于严格,先清除本地 cookie,再检查 SESSION_SAME_SITE 是否为 lax 或 none,同时确认响应头中 Set-Cookie 的 Domain 字段确实是 .example.com,如果响应头没有出现该字段,优先检查 config/session.php 是否覆盖了 .env 配置。
laravel 前端和后端不同主域名能通过 cookie domain 跨域吗?
不能。example.com 和 another.com 属于不同注册域,Cookie 的 domain 机制天然不支持这种跨主域共享,需要改用 Sanctum token、JWT 或 OAuth 等基于请求头的认证方案,前端手动在每次请求中携带令牌,后端验证令牌后建立会话状态,这是浏览器同源策略下的确定性限制。
设置 Laravel cookie 域名参数时,先明确是否处于同一主域内部,子域名之间共享优先用 SESSION_DOMAIN=.父域名,配合 CORS 凭证和 SameSite 调整即可稳定生效;跨主域名则果断放弃 cookie 思路,转向 token 认证。
首发原创文章,作者:王坚,如若转载,请注明出处:https://idctop.com/article/670750.html




