WordPress上传提示“413 Request Entity Too Large”怎么办？Nginx、Cloudflare与PHP完整排查

先给结论：WordPress 上传图片、主题或备份时出现 413 Request Entity Too Large，通常不是 WordPress 自己拒绝了文件，而是请求在 Cloudflare、Nginx/OpenLiteSpeed/Apache 或 PHP 的某一层被提前拦截。正确做法是先判断 413 由哪一层返回，再只提高那一层及其后续层的限制；把所有参数一口气改成 2GB，只是把故障变成安全隐患。

为什么改了 php.ini，413 还是不消失？

上传请求会依次经过 CDN/WAF、Web 服务器、PHP，最后才到 WordPress。前一层的上限如果是 100MB，后面的 upload_max_filesize=512M 就没有机会生效。Nginx 官方说明，超过 client_max_body_size 会直接返回 413；PHP 官方则要求 post_max_size 大于 upload_max_filesize。这也是“后台显示可上传 512MB，但 120MB 文件仍报 413”的典型原因。

第一步：用现象定位是哪一层

1. 先记录文件大小、上传入口和报错时间。媒体库、主题上传、WooCommerce 导入、备份恢复走的接口并不相同。
2. 临时绕过 CDN 测试。如果域名接入 Cloudflare，可在维护窗口将该记录暂时设为 DNS only，再上传同一文件。绕过后成功，限制就在 Cloudflare；测试后应恢复代理。
3. 检查服务器错误日志。Nginx 常见日志会出现 client intended to send too large body；OpenLiteSpeed 可查 error.log；PHP 日志完全没有该请求，往往说明请求还没到 PHP。
4. 查看 PHP 实际值。不要只看你编辑的文件，创建一个仅管理员可见的 phpinfo() 页面或在命令行执行 php -i | grep -E 'upload_max_filesize|post_max_size|memory_limit'，确认当前 PHP SAPI 真正加载的配置。

第二步：按你的服务器逐层修复

Cloudflare：先确认套餐上限

Cloudflare 官方在 2026 年 10 月 9 日列出的最大请求体为：Free/Pro 100MB、Business 200MB、Enterprise 可自助调至 5GB。该上限不是改 WordPress 配置就能突破。超过套餐上限时，可改用分片上传、临时 DNS only，或让大文件通过不代理的上传子域名进入源站。不要长期关闭代理来“解决”一个偶发导入任务。

Nginx：设置 client_max_body_size

把指令放在对应站点的 server 块或上传路径的 location 块中；256MB 示例：

server {
    client_max_body_size 256M;
    # 其他站点配置
}

保存后先验证再重载：

sudo nginx -t
sudo systemctl reload nginx

如果 Nginx 前面还有反向代理或面板生成的配置，必须确认最终生效文件，而不是只改一个随后会被面板覆盖的片段。

OpenLiteSpeed/LiteSpeed：调整请求体上限

在 WebAdmin 中进入 Server Configuration → Tuning → Max Request Body Size (bytes)，设置略高于业务实际需要的值并平滑重启。LiteSpeed 官方文档同时提醒：上限应尽量收紧，以减少内存、交换空间和拒绝服务风险。SHOPAGG 用户如果不想碰 WebAdmin，可先在SHOPAGG 创建网站页面核对当前方案支持范围，再提交包含文件大小与报错时间的工单。

Apache：检查 LimitRequestBody

Apache 2.4 可在虚拟主机、目录或 .htaccess 中设置字节数。256MB 为 268435456 字节：

LimitRequestBody 268435456

Apache 官方文档说明 0 表示不限，但生产站不建议为了省事设为无限。修改虚拟主机配置后先执行 apachectl configtest，再平滑重载。

PHP：三个值要有大小关系

Web 服务器放行后，再修改实际生效的 php.ini、PHP-FPM pool 或面板配置：

upload_max_filesize = 256M
post_max_size = 270M
memory_limit = 512M
max_execution_time = 300
max_input_time = 300

post_max_size 必须大于单文件上限，因为 multipart 请求还包含表单边界和其他字段。改完后重载对应 PHP-FPM 服务；如果使用 LiteSpeed 的 LSPHP，则按该运行模式重启 PHP。

WordPress 还有两处容易漏掉

• 多站点：网络管理 → 设置 → 上传设置里还有“最大上传文件大小”，它可以小于服务器上限。
• 插件自己的限制：迁移、备份和商品导入插件可能另设包大小、分片或超时时间。先用媒体库上传同等大小的普通文件，可快速区分插件限制与服务器限制。

修复后如何验证

1. 在 WordPress 媒体库确认页面显示的新上限。
2. 上传一个小文件，确认基础上传链路没有被配置错误破坏。
3. 上传一个略低于目标上限的测试文件；不要直接用客户唯一备份包做第一次测试。
4. 同时观察 CDN、Web 服务器和 PHP 日志，确认请求实际到达 WordPress。
5. 删除测试文件，并把临时关闭的 Cloudflare 代理恢复。

常见错误

只改 WordPress 常量：WP_MEMORY_LIMIT 不控制 HTTP 请求体；直接 chmod 777：413 与文件权限不是一类问题；无限放大所有值：会增加内存和磁盘交换压力；忘记重载服务：配置文件正确但旧进程仍在运行；用浏览器反复重试：如果触发 WAF，排查会更乱。

最稳的配置不是“越大越好”，而是 CDN 上限 ≥ Web 服务器上限 ≥ PHP post_max_size ＞ upload_max_filesize，并给实际业务留出少量余量。这样下一次再见到 413，你是在定位一扇门，而不是对着整栋楼踹门。

官方资料：Cloudflare Error 413、Nginx client_max_body_size、PHP 核心配置、Apache LimitRequestBody、LiteSpeed Server Tuning（访问与核对日期：2026年10月9日）。