Laravel部署至AWS EC2后分页功能异常，寻求技术支持

我之前也碰到过类似Laravel分页在AWS环境卡壳的情况，结合你的场景（本地XAMPP+MySQL正常，线上EC2+Nginx+Aurora MySQL，第一页加载正常、其他页码超时失败），咱们一步步排查解决：

1. 先开启调试模式定位具体错误 #

线上默认关闭调试模式后，错误提示太模糊，先临时打开调试模式获取详细日志：

• 修改.env文件：APP_DEBUG=true
• 运行php artisan config:cache刷新配置
• 再次点击分页页码，查看页面上的具体错误信息，或者查看storage/logs/laravel.log里的日志内容，这能帮你快速锁定是数据库查询超时、Nginx配置问题还是其他原因。

2. 排查数据库查询性能问题 #

Aurora MySQL虽然兼容MySQL，但大数据集下的offset分页会比本地小数据慢很多，这是常见的坑：

• 查看分页对应的SQL语句：在控制器代码里添加DB::enableQueryLog();，执行分页逻辑后用dd(DB::getQueryLog());打印出执行的SQL
• 把这段SQL拿到Aurora的客户端里，用EXPLAIN分析执行计划，看是否用到了合适的索引。如果发现全表扫描或者索引失效，赶紧给查询涉及的字段（比如排序字段、筛选字段）添加索引
• 如果数据集很大，建议把Laravel的paginate()换成cursorPaginate()，游标分页避免了offset带来的性能损耗，适合大数据量的分页场景

3. 调整Nginx的超时配置 #

页面长时间加载后失败，大概率是Nginx的超时时间设置过短，默认的fastcgi_read_timeout可能不足以支撑较慢的数据库查询：

• 打开Nginx的站点配置文件（一般在/etc/nginx/sites-available/your-site.conf）
• 在server块里添加或修改以下配置：

fastcgi_read_timeout 60s;
proxy_connect_timeout 60s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;

• 保存配置后，运行sudo nginx -t检查配置是否合法，再执行sudo systemctl reload nginx重启Nginx

4. 检查Aurora与EC2的资源和网络 #

• 查看AWS CloudWatch的监控数据：检查Aurora实例的CPU利用率、内存使用率、查询等待时间，如果资源占用过高，考虑升级Aurora实例规格
• 确认EC2的安全组是否允许访问Aurora的端口（默认3306），虽然第一页能加载说明基本连接没问题，但偶尔的网络波动或连接数限制也可能导致后续查询失败
• 检查Aurora的参数组配置，比如max_connections是否足够，避免连接数耗尽

5. 验证Laravel的基础配置 #

• 确认.env里的APP_URL是否设置为线上EC2的公网IP或域名，分页链接是基于这个地址生成的，如果地址错误可能导致跳转异常（不过你的情况是加载超时，这个优先级稍低，但也可以检查）
• 检查会话驱动配置，如果用的是file驱动，确认storage/framework/sessions目录的权限是www-data用户可读写，避免会话存储异常影响分页状态

按照这个顺序排查，应该能快速找到问题所在。

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