502 Bad Gateway 是 nginx 因超时主动断连而非 MySQL 故障，需调大 proxy_read_timeout（≥PHP max_execution_time+20–30s）、proxy_connect_timeout（≥60s）和 proxy_send_timeout（如300s），并关闭 proxy_buffering 以支持流式响应，同时配置 client_max_body_size 防 413 错误，并同步调整 PHP-FPM、MySQL 和 phpMyAdmin 超时与限制参数。
502 Bad Gateway 是 nginx 主动断连，不是 MySQL 挂了
看到 502 不要急着查 mysql 日志——它大概率根本没收到请求。nginx 在等上游（php-fpm）返回响应体时超时，直接断开连接并返回 502。错误日志里如果出现 upstream timed out while reading response from upstream，就是这个原因。
关键点有两个：proxy_read_timeout 控制“读响应体”的最长时间；proxy_connect_timeout 控制“建立连接并收响应头”的时间。两者都得调大，且 proxy_read_timeout 必须 ≥ PHP 的 max_execution_time（建议多留 20–30 秒缓冲）。
-
proxy_read_timeout设为 300（5 分钟）或更高，别设 0（部分 nginx 版本不支持） -
proxy_connect_timeout至少 60，避免 DNS 或后端启动慢导致卡住 -
proxy_send_timeout也要同步设为 300，防止上传阶段被中断 - 必须放在
location ~ \.php$块内，否则不生效
proxy_buffering 开关决定响应是否“透传”
默认开启的 proxy_buffering 会让 nginx 把整个响应攒满缓冲区再发给浏览器，对 phpMyAdmin 这种长耗时导入极不友好——页面一直白屏，直到最后才刷出结果或直接 502。
关掉它，让响应流式透传：
- 加
proxy_buffering off;到 location 块中 - 即使关了 buffering，
proxy_buffer_size仍需设够（如128k），否则可能报upstream sent too big header - 注意：关 buffering 后 nginx 内存占用略升，但换来的是可感知的进度反馈
client_max_body_size 漏配会导致 413，但用户误以为是 502
选完大 SQL 文件点“执行”后页面空白或秒退？先别怀疑超时——很可能是 nginx 在请求入口就拦下了，返回 413 Request Entity Too Large，而某些前端 UI 没正确展示该状态码。
立即学习“PHP免费学习笔记（深入）”；
这个限制和 PHP 的 upload_max_filesize 无关，是 nginx 独立控制的：
- 在
http、server或location块中加client_max_body_size 2048M; - 单位必须带
M或G，写2048不生效 - 宝塔用户可在网站配置 → “配置修改” → “其他配置” 中追加
后端 PHP-FPM 和 MySQL 配置必须同步放宽
nginx 放宽了，但 php-fpm 自己超时、MySQL 拒收大包，照样前功尽弃。
检查三项：
- PHP-FPM 的
www.conf中是否有php_admin_value[max_execution_time]——它会覆盖 php.ini，必须一并改 - MySQL 的
max_allowed_packet至少设为256M（默认仅 4MB），否则 INSERT 语句超长会被静默丢弃 - phpMyAdmin 自身的
$cfg['ExecTimeLimit'] = 0;要加在config.inc.php里，不是config.default.php，改完清浏览器缓存
最容易被忽略的是：所有配置改完后，必须重启对应服务（nginx、php-fpm、MySQL），且要确认你改的是实际生效的那个配置文件——用 phpinfo() 查 Loaded Configuration File，别凭路径猜。
