宝塔面板上传文件出现 413 怎么处理？Nginx、PHP 与 WordPress 限制

直接结论：上传时出现 413 Request Entity Too Large，通常是请求先被 Nginx 的 client_max_body_size 拒绝；如果 Nginx 已放行但 WordPress、PHP 源码仍提示文件过大，再检查 PHP 的 upload_max_filesize 和 post_max_size。宝塔用户先进入“网站 → 目标站点 → 配置文件”确认 Nginx 限制，再到站点所用 PHP 版本的配置页调整上传限制。三层限制必须按实际业务统一，不能只把其中一项改成无限大。

修改配置通常不收费，也不会主动删除数据，但更大的上传会占用公网流量、临时目录、磁盘、PHP 内存和处理时间。配置写错会让 Nginx 或 PHP-FPM 无法重载；上传过程中磁盘耗尽还可能影响整个站点。操作前备份站点配置和 PHP 配置，先检查磁盘空间，并保留当前 SSH 或面板会话。

先确认 413 是在哪一层返回的

记录失败时间、请求域名、上传入口、文件大小和浏览器网络面板中的状态码。随后查看 Nginx 错误日志。典型 Nginx 拒绝会出现请求体过大的提示，而且 PHP 访问日志里没有对应请求。若 Nginx 已把请求交给 PHP，WordPress 或应用可能显示自己的“超过上传上限”提示，PHP 的 $_FILES 也会给出上传错误码。

sudo nginx -T 2>/dev/null | grep -n client_max_body_size
sudo tail -n 100 /var/log/nginx/error.log
df -h
df -i

nginx -T 会展开当前实际加载的配置，比只看某个站点文件可靠。宝塔的日志路径可能在站点配置中另行指定，应以 nginx -T 输出为准。命令只读取配置和空间；不要把完整配置贴到公开渠道，因为其中可能含域名、上游地址或访问控制信息。

Nginx 限制应该设在哪里

client_max_body_size 可以写在 http、server 或 location 范围。普通站长优先只给需要上传的站点或路径设置，不要为了一个后台入口放大全服务器。比如业务允许最大 64 MB，可在对应 server 或上传路径中设置：

server {
    server_name www.example.com;
    client_max_body_size 64m;

    # 其余站点配置保持原样
}

保存后必须先运行 sudo nginx -t。只有语法通过才执行 sudo systemctl reload nginx。Nginx 默认限制是 1 MB；设为 0 会关闭请求体大小检查，不适合作为日常修复。若 CDN、WAF、负载均衡或另一层反向代理在 Nginx 之前，它们也可能有独立上限，源站放大后仍返回 413 就要沿请求链逐层检查。

PHP 的两个大小为什么不能设成一样

PHP 的 upload_max_filesize 限制单个文件，post_max_size 限制整个 POST 请求。表单还包含边界、字段和可能的多个文件，所以 post_max_size 必须略大于单文件上限。若要允许单个 64 MB 文件，可以从下面的保守起点测试，而不是照抄到所有站点：

upload_max_filesize = 64M
post_max_size = 72M
max_execution_time = 120
max_input_time = 120

还要确认 upload_tmp_dir 可写且有空间。memory_limit 不等于上传上限，但应用如果把整个文件读入内存，仍可能在上传后处理阶段耗尽内存。宝塔可以同时安装多个 PHP 版本，面板全局设置、命令行 php -i 和站点实际 PHP-FPM 可能不是同一个配置。最可靠的方法是在受控测试页或应用状态页读取当前生效值，确认后立即删除公开的 phpinfo() 页面。

WordPress 还会有哪些独立阻塞

• WordPress 多站点可能在网络设置中另有限制。
• 备份、导入或媒体插件可能设置自己的分片和文件大小。
• 安全插件、WAF 或 CDN 会按规则拦截大请求。
• 临时目录、网站目录或 Docker 数据卷空间不足，会在放行后失败。
• 上传成功但解压失败，可能是 PHP 扩展、权限、超时或压缩包本身问题，不应继续放大请求上限。

这也是为什么 413 修复不能只看 WordPress 后台显示的“最大上传文件大小”。先看网络状态码和 Nginx 日志，再看 PHP 实际配置，最后看应用日志，能够避免在错误层反复修改。

怎样选择一个不会失控的上限

业务	默认建议	更安全的替代
普通图片和文档	按真实最大素材加少量余量	压缩图片、限制扩展名和用户权限
大主题、插件或备份包	只临时开放到管理员入口	使用 SFTP、对象存储或服务器端导入
数百 MB 到 GB 文件	不要让 PHP 单请求直传	分片上传、对象存储直传和校验

把限制设成“当前文件刚好能过”也不理想，后续稍大的文件会再次失败；但设成无限大，会给磁盘耗尽和滥用留下空间。结合用户权限、请求频率、临时目录容量和业务文件类型设置上限，并为异常流量和磁盘使用率告警。

修复后如何验证，失败时怎么回退

1. 准备一个略低于上限和一个略高于上限的非敏感测试文件。
2. 低于上限的文件应上传成功，高于上限的文件应被可理解地拒绝。
3. 检查 Nginx、PHP 和应用日志，没有 413、临时目录错误或内存错误。
4. 确认上传后的文件能打开、校验大小正确，后台不会重复提交。
5. 观察磁盘、临时目录、CPU 和请求时间，再覆盖一次服务重载。

Nginx 配置测试不通过时，恢复备份文件，不要重启服务。PHP 调整后站点出现 502 时，恢复原 php.ini 并重载对应 PHP-FPM，可参考宝塔 PHP 502 排查。磁盘异常可参考Linux 磁盘满排查；Nginx 站点结构可参考Nginx 反向代理与 HTTPS。

官方依据

• Nginx：client_max_body_size 指令与 413 行为
• PHP：文件上传相关 php.ini 指令
• PHP：文件上传错误码说明