413错误本质是Nginx在请求进入PHP前拦截所致，须在server或location块中设置client_max_body_size（如256M），并同步调大PHP的upload_max_filesize和post_max_size（均设为256M），修改后必须重载Nginx配置。
phpMyAdmin 导入大 SQL 报 413 Request Entity Too Large
这是最常见的情况，本质是 Nginx 拒绝了超过默认限制的请求体。phpMyAdmin 上传 SQL 文件走的是 POST 请求，Nginx 默认 client_max_body_size 是 1MB，一旦 SQL 文件超限就直接返回 413 错误，根本不会进 PHP 或 phpMyAdmin 的逻辑。
解决方法很简单：在 Nginx 配置中调整该参数。注意不是改 phpMyAdmin 的配置，也不是改 php.ini，而是必须改 Nginx 的 server 或 location 块：
- 找到你的站点配置（比如
/etc/nginx/sites-enabled/myadmin或/usr/local/nginx/conf/nginx.conf） - 在
server块或包含 phpMyAdmin 的location块里添加：client_max_body_size 256M;
- 如果用了反向代理（比如 phpMyAdmin 跑在 Apache 上），还要检查
proxy_max_temp_file_size和proxy_buffering，但多数情况只需改client_max_body_size - 改完后必须执行
nginx -t && nginx -s reload，仅重启 PHP-FPM 无效
导入中途断开、提示“服务器意外终止连接”
这通常不是 Nginx 报错，而是请求被静默中断——原因多是 fastcgi_read_timeout 或 client_header_timeout 过短。大 SQL 解析和执行耗时长，Nginx 在等待 PHP-FPM 返回响应时超时，就主动关闭连接，浏览器看到的就是“连接被重置”或空响应。
关键参数有三个，需同步调整：
立即学习“PHP免费学习笔记（深入）”；
-
fastcgi_read_timeout 300;：控制 Nginx 等待 PHP-FPM 执行完成的最长时间（单位秒），导入 200MB SQL 建议设为600或更高 -
client_header_timeout 60;和client_body_timeout 60;：虽然影响较小，但若网络不稳定或上传慢，也可能触发，建议统一设为300 - 这些参数要放在与
fastcgi_pass同级的location ~ \.php$块内，否则不生效
改了 Nginx 参数还是失败？检查是否被 proxy_pass 或 SSL 中间件截断
如果你的 phpMyAdmin 实际部署在其他服务上（比如 Docker 容器、Apache、或通过 Cloudflare / Nginx Ingress 暴露），Nginx 只是前端代理，那么 client_max_body_size 必须加在**最外层入口 Nginx** 上，而不是后端容器里的 Nginx。
常见陷阱：
- Docker Compose + nginx-proxy：要在
nginx-proxy容器的自定义配置里挂载client_max_body_size，而非 phpMyAdmin 容器内部 - Kubernetes Ingress：需要在
nginx.ingress.kubernetes.io/proxy-body-size注解中设置，值如"256m" - Cloudflare：免费版默认限制 100MB 上传，且无法绕过；即使你本地 Nginx 放开了，请求到 Cloudflare 就被拦了
- SELinux 或 AppArmor：极少数情况下会拦截大文件临时写入，可临时用
setenforce 0排查，但不建议长期关闭
为什么不能只调大 PHP 的 upload_max_filesize？
因为 phpMyAdmin 的“导入”功能有两种路径：一种是表单上传（走 PHP 文件上传机制），另一种是直接粘贴 SQL 文本（走 POST body）。后者完全绕过 upload_max_filesize，只受 Nginx 的 client_max_body_size 限制。而很多人只改了 php.ini 却忽略 Nginx 层，结果粘贴大 SQL 仍失败。
更隐蔽的问题是：某些 Nginx 编译版本（尤其是 OpenResty 或旧版）对 client_max_body_size 的单位解析不一致，256M 有时会被当成 256 字节。保险起见，统一用大写 M 或显式写成 268435456（256×1024×1024）。
真正起作用的永远是最靠近客户端的那个 Nginx 实例，而不是离 PHP 最近的那个。
