HTTP 413 请求实体过大：根本原因、修复方法及服务器配置指南

HTTP 413 Request Entity Too Large 错误是一种服务器端响应状态码，当传入的请求体（最常见的是文件上传）超过了在 Web 服务器、反向代理或应用层配置的最大负载大小时，就会发生此错误。服务器在处理请求之前会主动拒绝该请求，并向客户端返回 413 状态码。

此错误并非客户端错误，而是内置于 Nginx 和 Apache 等 Web 服务器、PHP 运行时配置以及应用层中间件中的一种主动执行机制。准确了解哪一层在执行限制，以及如何针对正确的配置指令进行修改，是快速解决问题与耗费数小时排查故障之间的关键区别。

HTTP 413 错误发生的原因：逐层分析

文件上传请求在到达应用程序之前，需要经过多个处理层。其中任何一层都可以独立地以 413 响应拒绝请求。正确诊断错误需要确定是哪一层负责。

第一层：Web 服务器指令

Nginx 通过 client_max_body_size 指令强制执行上传大小限制。其默认值为 1MB，对于大多数现代应用程序来说限制过于严格。该指令可以在 http、server 或 location 块上下文中设置，最具体的块优先生效。

Apache 使用 LimitRequestBody 指令，在大多数发行版中默认值为 0（无限制）——但托管服务提供商通常会在其全局或虚拟主机配置中将其覆盖为较严格的值。Apache 还会处理 .htaccess 文件，这意味着限制可能在目录级别强制执行，而无需修改主配置文件。

第二层：PHP 运行时配置

PHP 引入了两个独立的指令，两者都必须满足才能成功完成大文件上传：

• upload_max_filesize — 单个上传文件的最大大小
• post_max_size — 整个 POST 请求体的最大大小，必须等于或大于 upload_max_filesize

一种常见的配置错误是设置了 upload_max_filesize = 50M，却将 post_max_size 保留为默认值 8M。POST 请求体限制会被优先评估，因此上传会在文件大小限制被检查之前就悄然失败。

还有一个经常被忽视的第三个指令：max_input_time，它定义了 PHP 等待接收输入数据的时长。在网速较慢的情况下上传大文件时，此超时可能触发失败，表现为 413 错误或空白响应。

第三层：反向代理和负载均衡器

如果您的基础设施使用了反向代理——HAProxy、Varnish、Cloudflare，或作为另一台服务器前端代理的 Nginx 实例——该代理层有其自己的请求体大小限制。例如，Cloudflare 返回的 413 错误在免费版和 Pro 版计划中有 100MB 的硬性限制，任何服务器端配置都无法覆盖此限制。请务必检查代理层的响应头，以确定 413 的来源。

第四层：应用程序和 CMS 限制

内容管理系统和框架在服务器和 PHP 层之上应用了自己的上传限制。WordPress 从 PHP 的运行时值读取有效的上传限制，但也会强制执行其自身的媒体库约束。某些 WordPress 插件会添加额外的验证层。自定义 PHP 应用程序可能使用 $_FILES 验证逻辑，施加比服务器允许的更严格的限制。

Nginx 配置：在 Web 服务器层修复 413 错误

对于 Nginx，修复需要在正确的配置上下文中修改 client_max_body_size。编辑 http 块会全局应用该限制；编辑 server 或 location 块则仅将其应用于该虚拟主机或端点。

# Global setting — applies to all virtual hosts
http {
    client_max_body_size 100M;
}

# Per-virtual-host setting — preferred for multi-tenant environments
server {
    listen 80;
    server_name example.com;
    client_max_body_size 100M;

    # Granular control — apply only to the upload endpoint
    location /wp-admin/async-upload.php {
        client_max_body_size 256M;
    }
}

编辑后，在重新加载之前验证配置语法：

nginx -t && systemctl reload nginx

关键边缘情况：如果 Nginx 作为 PHP-FPM 或其他应用服务器前端的反向代理，还必须检查 proxy_read_timeout 和 proxy_send_timeout 指令。大文件上传若超过超时时间将在传输中途被终止，根据代理行为的不同，会产生 413 或 504 错误。

Apache 配置：在 Web 服务器层修复 413 错误

Apache 的 LimitRequestBody 指令接受以字节为单位的值。该指令可以放置在 httpd.conf、VirtualHost 块、Directory 块或 .htaccess 文件中。

# In httpd.conf or VirtualHost block
LimitRequestBody 104857600

# In .htaccess (if AllowOverride is enabled for the directory)
LimitRequestBody 104857600

值 104857600 等于 100MB（100 × 1024 × 1024）。修改 httpd.conf 或虚拟主机文件后，重启 Apache：

apachectl configtest && systemctl restart apache2

重要说明：在共享托管环境中，如果托管服务提供商在其服务器级配置中设置了 AllowOverride None，则 .htaccess 的修改可能会被忽略。在这种情况下，只有托管服务提供商才能更改限制。这是考虑迁移到 VPS 托管环境的主要技术原因之一，因为在那里您拥有对服务器配置的完整 root 访问权限。

PHP 配置：在运行时层修复 413 错误

php.ini 文件是 PHP 上传限制的权威来源。需要编辑哪个文件取决于您的 PHP 执行模型（mod_php、PHP-FPM、CLI）。使用 phpinfo() 或 php --ini 来确认实际加载的是哪个 php.ini。

; Minimum required changes for large file uploads
upload_max_filesize = 128M
post_max_size = 128M
max_input_time = 300
max_execution_time = 300
memory_limit = 256M

编辑 php.ini 后，重启相应的服务：

# For PHP-FPM
systemctl restart php8.2-fpm

# For Apache with mod_php
systemctl restart apache2

当 php.ini 无法访问时的替代方法：

如果您使用的是没有直接 php.ini 访问权限的共享托管计划，可以尝试使用以下方式覆盖 PHP 设置：

1. 在 Web 根目录中放置 .user.ini 文件（适用于 PHP-FPM）：

upload_max_filesize = 64M
post_max_size = 64M

1. 使用 .htaccess 指令（仅适用于 mod_php）：

php_value upload_max_filesize 64M
php_value post_max_size 64M

1. 运行时 PHP 代码（效果有限，不建议用于生产环境）：

@ini_set('upload_max_filesize', '64M');
@ini_set('post_max_size', '64M');

请注意，在 PHP 7.x 及更高版本中，ini_set() 无法在运行时覆盖 upload_max_filesize 或 post_max_size——这些指令在脚本执行开始之前就已被评估。.user.ini 或 .htaccess 方法要可靠得多。

WordPress 专项修复 413 错误

WordPress 在”媒体 > 添加新文件”界面显示其有效的上传限制。如果显示的限制低于您在 php.ini 中配置的值，通常是因为 WordPress 正在从不同的 PHP 进程读取，或者缓存层正在提供过时的配置数据。

将以下内容添加到 wp-config.php 以明确定义上传大小：

@ini_set( 'upload_max_size', '128M' );
@ini_set( 'post_max_size', '128M' );
define( 'WP_MEMORY_LIMIT', '256M' );

对于 WordPress 多站点安装，网络级别的上传大小在网络管理 > 设置 > 网络设置 > 最大上传文件大小中单独控制。此设置独立于 PHP 限制，必须在服务器级更改之外额外进行配置。

对比：根据托管环境选择修复 413 的位置

诊断哪一层返回了 413 错误

在应用任何修复之前，请确认 413 响应的来源。使用 curl 并开启详细输出以检查响应头：

curl -v -X POST -F "file=@/path/to/largefile.zip" https://example.com/upload

检查 Server 响应头以及任何 X-Powered-By 或 CF-RAY 头。CF-RAY 头表明 413 来自 Cloudflare，而非您的服务器。来自 nginx/1.x.x 的响应指向 Nginx 层。没有 Server 头可能表明是您应用程序上游的负载均衡器或 WAF。

触发 413 后，还需立即检查服务器错误日志：

# Nginx
tail -f /var/log/nginx/error.log

# Apache
tail -f /var/log/apache2/error.log

# PHP-FPM
tail -f /var/log/php8.2-fpm.log

当服务器配置不够用时：基础设施考量

对于需要频繁处理大文件传输的应用程序——视频平台、备份系统、医学影像、大规模电商产品目录——将高上传限制硬编码到共享服务器配置中并不是一种可持续的架构。请考虑以下替代方案：

• 分块上传：使用 Resumable.js 或 Uppy 等库在客户端将大文件分割成较小的块。每个块都在服务器限制范围内，服务器负责重新组装。这可以完全绕过 413 错误。
• 直接上传至对象存储：为兼容 S3 的存储生成预签名 URL，让客户端直接上传，完全绕过您的 Web 服务器。Web 服务器只处理元数据事务。
• 专用上传端点：在 Nginx 中为上传路由配置一个单独的 location 块，并设置更高的 client_max_body_size，同时对所有其他端点保持默认的严格限制。

对于涉及大文件处理的计算密集型工作负载——视频转码、对上传数据进行机器学习推理——GPU 托管环境提供了足够的处理能力，可以同时处理上传和后续计算，不会产生瓶颈。

如果您的应用程序需要具有完整 PHP 配置访问权限的托管控制面板环境，带 cPanel 的 VPS 为您提供 WHM 中的 MultiPHP INI 编辑器，无需使用命令行即可实现按域名覆盖 PHP 指令。

提高上传限制时的安全注意事项

在没有相应安全加固措施的情况下提高上传限制会引入真实的攻击面。一台接受 500MB POST 请求的服务器很容易成为耗尽磁盘 I/O、内存或连接池的拒绝服务攻击目标。

在提高任何限制的同时，请实施以下控制措施：

• 对上传端点进行速率限制：在 Nginx 中，使用 limit_req_zone 限制每个 IP 的上传频率。
• 文件类型验证：切勿依赖客户端提供的 MIME 类型。在服务器端验证文件签名（魔术字节）。
• 上传目录权限：接收上传文件的目录不得可通过 Web 访问或可执行。将上传文件存储在文档根目录之外。
• 病毒扫描：对于任何公开可访问的上传端点，将 ClamAV 或类似扫描器集成到上传流程中。
• 仅限已认证的上传：在接受大型负载之前要求身份验证。未经认证的大文件上传端点极易被滥用。

对于处理敏感上传数据的生产环境，将您的托管基础设施与正确配置的 SSL 证书配合使用，可确保文件传输在传输过程中经过加密，防止上传内容被截获。

技术决策矩阵：选择正确的修复方案

解决 HTTP 413 的实用检查清单

• 在进行任何更改之前，使用 curl -v 和服务器错误日志确定返回 413 的层
• 在 Nginx 中，在最具体的适用块中设置 client_max_body_size（location 优先于 server，server 优先于 http）
• 确保 php.ini 中 post_max_size 始终大于或等于 upload_max_filesize
• 对于慢速连接上传大文件，增加 max_input_time 和 max_execution_time
• 在依赖 .htaccess 覆盖之前，验证其是否被允许（AllowOverride All 或 AllowOverride Options）
• 独立检查所有代理层——CDN、负载均衡器和应用服务器各自单独执行限制
• 任何配置更改后，重新加载（而非仅重启）相关服务，并清除所有操作码或页面缓存
• 对于 WordPress 多站点，除 PHP 指令外还需在网络级别配置上传限制
• 在提高面向公众的上传端点的限制之前，实施速率限制和文件类型验证
• 如果共享托管阻止配置访问，请迁移到 VPS 托管或独立服务器环境以获得完全控制权

常见问题解答

Nginx 中导致 413 错误的默认上传限制是多少？

Nginx 的 client_max_body_size 默认值为 1MB。任何超过 1MB 的请求体都将返回 413，除非在 Nginx 配置中明确增加此指令的值。

没有服务器 root 访问权限，我能修复 413 错误吗？

在共享托管上，您可以尝试通过 .htaccess（仅限 Apache，且需要 AllowOverride 允许）或 .user.ini 文件（仅限 PHP-FPM）进行修复。但是，如果托管服务提供商设置了严格的全局限制，这些方法将无效，您需要联系支持或升级到 VPS 计划。

为什么在 php.ini 中增加了 upload_max_filesize 后上传仍然失败？

最常见的原因是 post_max_size 仍保持其较低的默认值。PHP 在评估单个文件大小限制之前会先评估 POST 请求体大小限制，因此上传在 upload_max_filesize 被检查之前就已被拒绝。请务必同时增加这两个指令。

Cloudflare 会导致 413 错误吗？

会。Cloudflare 强制执行自己的请求体大小限制：免费版和 Pro 版计划为 100MB，Business 版为 200MB，Enterprise 版为 500MB。如果您的请求超过这些限制，Cloudflare 会在请求到达您的源服务器之前返回 413。任何服务器端配置更改都无法解决此问题——您必须升级 Cloudflare 计划、使用直接上传绕过（预签名 URL），或实施分块上传。

如何在 cPanel 服务器上的 WordPress 中永久修复 413 错误？

使用 WHM 的 MultiPHP INI 编辑器，针对特定 PHP 版本和域名增加 upload_max_filesize 和 post_max_size。然后在 WordPress 的”媒体 > 添加新文件”中验证更改是否已生效。对于 WordPress 多站点，还需在”网络管理 > 设置”下更新最大上传大小。直接使用 WHM 的 INI 编辑器时，无需更改 .htaccess 或 wp-config.php。