Laravel多子域名部署Session重叠引发419错误的解决方案

• Cookie残留与作用域误解：当为SESSION_DOMAIN赋值为具体子域名时，底层Cookie组件自动给域名添加前导.是符合Cookie标准的正常行为，该配置下.app1.mydomain.com的Cookie仅会发送给app1.mydomain.com及其下级子域，绝不会泄露到app2.mydomain.com。你观察到的跨域出现对方站点Cookie、以及默认laravel_session Cookie，本质是之前配置根域名通配符SESSION_DOMAIN=.mydomain.com时浏览器留存的旧Cookie，加上部分场景下应用配置缓存未更新，读不到自定义的APP_NAME和Session配置，自动fallback到laravel_session默认值，两个应用共用Cookie名产生冲突。
• Session存储端未隔离：默认Laravel使用file驱动存储Session，存储路径为storage/framework/sessions。如果两个应用部署在同一台服务器，且PHP运行用户权限一致、未配置独立的存储路径，哪怕Cookie端做了隔离，两个应用也会读取同一份Session文件，出现会话串读。当请求携带不属于当前应用的Session ID时，应用用自身APP_KEY解密失败就会触发CSRF校验不通过，返回419错误。
• 并发场景下的环境变量污染：如果两个应用部署在同一个PHP-FPM池、开启了opcache但未正确配置隔离，或者服务器开启了跨应用的OPcache缓存共享，近似并发请求时会出现环境变量串读，导致两个应用偶尔读取到对方的Session配置，进一步加剧会话冲突。

按以下顺序操作，可彻底解决该问题：

1. 清理浏览器端所有残留Cookie #

先清除mydomain.com及其所有子域名下的全部Cookie，不要仅删除单个子域名的Cookie。之前遗留的根域名通配符Cookie如果不清理，哪怕后续配置完全正确，旧Cookie仍会被同时发送到两个应用，持续触发冲突。

2. 修正两个应用的Session隔离配置 #

分别修改两个应用的.env文件，严格按如下规则配置，禁止将SESSION_DOMAIN留空或配置为根域名：

• app1 配置项：

SESSION_DOMAIN=app1.mydomain.com
SESSION_COOKIE=app1_session
SESSION_PATH=/

• app2 配置项：

SESSION_DOMAIN=app2.mydomain.com
SESSION_COOKIE=app2_session
SESSION_PATH=/

注意：配置SESSION_DOMAIN时不要手动添加前导.，底层会自动按标准处理域名匹配规则，手动添加反而会扩大Cookie作用域。
如果使用file驱动存储Session，需要分别修改两个应用config/session.php中的files路径，指定两个完全独立的存储目录；如果使用Redis或数据库存储Session，需要给两个应用分配独立的Redis库/数据库连接，或配置全局唯一的缓存前缀，禁止共用Session存储空间。

3. 彻底清理应用层缓存 #

在两个应用的根目录分别执行以下命令，清除所有旧缓存并重新生成配置缓存，避免环境变量修改不生效：

php artisan config:clear
php artisan cache:clear
php artisan route:clear
php artisan view:clear
php artisan config:cache

注意：生产环境执行config:cache后，框架不会再读取.env文件，后续修改任何环境变量都必须重新执行config:cache命令，否则所有配置修改都不会生效，这是自定义Session配置不生效的最常见诱因。
如果两个应用部署在同一台服务器，建议给每个应用分配独立的PHP-FPM运行池，同时配置OPcache的opcache.use_cwd=1、opcache.validate_timestamps=1，避免并发请求下的代码和配置缓存串读。

4. 验证隔离效果 #

重启PHP-FPM和Web服务后，重新打开浏览器访问两个应用，打开开发者工具的Cookie面板验证：

• app1域下仅存在app1_session Cookie，作用域为.app1.mydomain.com
• app2域下仅存在app2_session Cookie，作用域为.app2.mydomain.com
• 不存在跨域携带对方Cookie、以及默认laravel_session Cookie的情况
  验证通过后再测试登录流程，419错误与会话互通问题会完全消失。

内容的提问来源于stack exchange，提问作者goodUser