413错误有效负载太大是什么以及如何修复它?

正尝试将一个大文件上传到网站——也许是假期视频,或者可能是一个巨大的照片组合——突然,弹出一条神秘消息,而不是预期的确认:“413有效负载太大”?或者,更糟糕的是,费力填写的表单被服务器拒绝,因为它包含“太多数据”?我知道那种感觉。此错误也称为HTTP 413有效负载太大或请求实体太大,实际上是客户端错误(来自4xx类别),它清楚地表明服务器不想接受请求。为什么?因为发送的内容,即有效载荷,实在太大了!在本文中,我将展示如何了解这个问题的根源、最常见的原因是什么,更重要的是——如何有效地处理它以及如何通过关注Nginx、Apache和PHP服务器来预防它。

什么是HTTP 413有效负载过大错误?了解服务器消息

HTTP 413有效负载太大错误只不过是一条消息,表明Web服务器无法或根本不会处理发送给它的内容。为什么?因为“有效负载”(即有效负载)超出了服务器上设置的限制。这个错误,虽然它实际上是由于服务端的问题造成的(这就是我们将其归类为4xx错误的原因),但意味着一件事:发送了太多数据。简而言之,服务器告诉我们:“负载太大。这是一个信号,表明尝试传输的数据量大于服务器能够接受的最大请求大小。‘’

简单来说,当客户端尝试发送大于服务器“允许”的文件时,就会发生413错误。在HTTP术语中,来自4xx组的代码始终指示客户端问题。这个“有效载荷”是什么?这只是请求的关键——想要传递给服务器的所有内容。它可以是文件的内容、表单中的数据或其他任何内容。

收到413错误的常见情况

每当尝试发送超出服务器或应用程序“允许”的数据时,都会出现错误413。无论是文件还是表单中的数据,都没关系——关键是有效负载太笨重了。

以下是可能熟悉的一些最常见的场景:

  • 尝试上传太大的文件:这是经典之作。当想要上传大小大于服务器上设置的限制的照片、视频、文档或其他文件时,就会发生这种情况。
  • 发送的表单太大:这种情况很少见,但包含大量文本的表单(例如,长调查或具有较大描述字段的注册表单)可能会超过post_max_size限制或LimitRequestBody。
  • 向具有巨大有效负载的API发出请求:开发人员非常了解这一点。当他们向API发送包含大量JSON或XML数据的请求时,通常会弹出错误413,这些数据仅超过API服务器上的请求大小限制。
  • 在CMS中添加大型媒体或内容:在WordPress等系统上,如果上传限制太低,尝试添加大型媒体文件(例如超高分辨率图像或视频)可能会导致413错误。
  • 代理或其他中介的局限性:有时问题不在于主服务器,而在于代理或网络上的其他设备,例如防火墙或CDN。它们可能有自己的请求大小限制,甚至在有效负载到达目标Web服务器之前就拒绝了有效负载。

总而言之,每次都归结为同一件事:发送的内容只是大于服务器所能容纳的内容。

为什么会出现错误413?主要原因及配置

好的,既然知道什么是413错误,可能想知道为什么它首先会弹出?它出现是因为服务器收到了来自我们的请求,其数据负载超出了其设定的限制。此问题的最常见原因在于Web服务器的配置(无论是Nginx还是Apache)、PHP设置,甚至代理服务器或应用程序本身。这些元素中的每一个都可能有自己的局限性,因此会拒绝我们的请求。

Web服务器配置限制(Nginx、Apache)

Nginx和Apache等Web服务器具有用于管理传入请求大小的内置机制。多亏了它们,它们才能保护自己免受过载或DDoS攻击。这些机制由服务器管理员可以自由设置的特殊配置参数控制。当超过这些限制时,就会收到413错误。

在Nginx中,client_max_body_size参数负责客户端请求的大小限制。默认情况下,它设置为一个令人惊讶的低值,例如1MB。很容易想象,一旦尝试上传更大的文件,这将以多快的速度导致413错误。最常在nginx.conf文件或特定网站的配置文件中找到这样的限制。

另一方面,在Apache中,LimitRequestBody指令起着类似的作用。它允许指定HTTP请求有效负载的最大大小(以字节为单位)。可以在主httpd.conf文件或.htaccess文件中定义此指令。后一种解决方案可以灵活地在单个目录级别管理限制。这些限制通常是导致Web服务器端出现413错误的原因。

PHP配置中的限制

不仅仅是Web服务器有其限制,PHP配置还可以对传输的数据大小施加限制,尤其是在文件上传和POST数据处理方面。这些限制在php.ini文件中定义,它们的正确设置对于基于PHP的Web应用程序(例如WordPress)的运行非常重要。

需要注意的三个最重要的PHP指令是:

  • upload_max_filesize:此参数设置可通过表单上传到服务器的单个文件的最大大小。如果文件较大,PHP将简单地丢弃它。
  • post_max_size:此指令控制单个请求中所有POST数据的最大大小。它不仅包括文件,还包括在表单中发送的所有其他数据。post_max_size的值应始终等于或大于upload_max_filesize。
  • max_execution_time:虽然此参数与有效负载大小没有直接关系,但它指定了PHP脚本可以运行的最大时间(以秒为单位)。如果有处理大型上传文件或大型POST数据的脚本,则max_execution_time值过低可能会导致服务器在处理整个请求之前超时。

值得记住的是,这些限制与Web服务器上设置的限制一起使用,并且这些值中的最低值始终是决定性的。

代理和Web应用程序的作用

碰巧代理和Web应用程序引入了自己的有效负载限制,这是413错误问题的重要组成部分。即使主Web服务器被理想地配置为处理大文件,也是这些中间设备可以阻止请求。

代理——例如反向代理或CDN(内容分发网络)——通常位于主服务器前面,并且对请求大小有自己独立的限制。如果请求超过代理限制,413错误甚至会在到达目标服务器之前返回给我们。

Web应用程序虽然不太经常引入完全单独的限制,但也可能有内部上传限制。当然,它们基于服务器配置和PHP,但有时它们会添加自己的验证层。如果对服务器和PHP中的修改没有带来解决方案,则值得检查它们的设置。

许多开发人员忘记了413错误通常不仅会影响主Web服务器,还会影响架构中的每个中间元素,例如反向代理或CDN。它们中的每一个都必须具有适当调整的限制,以实现大数据有效负载的顺利传输。

如何修复错误413?服务器配置说明

好的,让我们进入正题——如何最终修复这个不幸的413错误?为此,需要通过简单地增加请求大小限制来更改Web和PHP服务器配置。这通常是有权访问配置文件的服务器管理员或开发人员的任务。将在下面找到最流行的服务器的详细说明。

修复 Nginx 中的错误 413

要修复 Nginx 中的错误 413,需要修改其配置文件中的 client_max_body_size 参数。这个参数控制 Nginx 服务器能够处理的最大客户端请求大小。

  • 在哪里可以找到 nginx.conf 文件?通常,这是路径 /etc/nginx/nginx.conf 或 /etc/nginx/conf.d/default.conf。如果有特定域的配置,请查看 /etc/nginx/sites-available/your-domain。
  • 添加或更改client_max_body_size:在文本编辑器中打开相应的配置文件(例如 nano 或 vi)。在 http、服务器或位置部分添加或修改client_max_body_size行。想要设置 50 兆字节 (MB) 的限制?它看起来像这样:http { …client_max_body_size 50M;… }服务器 { …client_max_body_size 50M;# 也可以在这里设置… }位置 /上传 { …client_max_body_size 50M;# 或者对于特定位置… }
  • 保存更改并重新启动 Nginx:进行更改后,保存文件。现在是一个非常重要的步骤——使用命令 sudo nginx -t 测试 Nginx 配置。如果一切正常,请使用 sudo systemctl restart nginx 或 sudo service nginx restart 重新启动服务器。

重新启动 Nginx 服务器后,对于大小不超过 50 MB 的请求,错误 413 应该会消失。

解决 Apache 中的错误 413

要处理 Apache 中的错误 413,需要修改 LimitRequestBody 指令。它确定 HTTP 请求有效负载的最大大小,以字节为单位指定。

  • 更改 httpd.conf 或 .htaccess 文件:
    • httpd.conf:主要的 Apache 配置文件通常可以在 /etc/httpd/conf/httpd.conf 或 /etc/apache2/apache2.conf 中找到。请记住,此处的更改将影响整个服务器。
    • .htaccess:无权访问 httpd.conf 或只想将限制应用于选定的目录?将指令添加到此目录中的 .htaccess 文件中。只需确保在 Apache 配置中为此目录启用了 AllowOverride All 选项即可。
  • 设置 LimitRequestBody:打开所选文件并添加或修改 LimitRequestBody 指令。该值必须以字节为单位。如果要将限制设置为 50 MB,请输入值 52428800 (即 50 * 1024 * 1024):# 在 httpd.conf LimitRequestBody 52428800 # 或在 .htaccess 文件中 LimitRequestBody 52428800
  • 保存更改并重新启动 Apache:保存 httpd.conf 文件后(对 .htaccess 的更改通常会立即生效,但为了确定,重新启动总是一个好主意),需要重新启动 Apache 服务器。使用 sudo systemctl restart apache2 (如果有 Ubuntu/Debian) 或 sudo systemctl restart httpd (如果使用的是 CentOS/RHEL)。

重新启动 Apache 服务器后,有效负载高达 50 MB 的请求应该已经被接受。

PHP 中的限制校正(用于 PHP-FPM 等)

纠正 PHP 中的限制对于摆脱 413 错误是绝对必要的,尤其是当问题出在上传文件或传输大型 POST 数据时。需要修改php.ini文件,该文件负责整个 PHP 运行时。

  • 在哪里可以找到php.ini文件?它的路径取决于操作系统和安装 PHP 的方式。可以通过创建一个内容为 <?phpinfo(); ?> 的.php文件,在浏览器中打开它,然后查找“加载的配置文件”行来轻松检查它。常见位置是 /etc/php/X.X/fpm/php.ini(用于 PHP-FPM)或 /etc/php/X.X/apache2/php.ini(用于运行 Apache 的 PHP)。
  • 更改指令的值:打开php.ini文件,找到以下参数,并将其值更改为更高的值,例如,为 50 MB:
    • upload_max_filesize = 50M – 这是要上传的单个文件的最大大小。
    • post_max_size = 50M – 这是请求中所有 POST 数据的最大大小;此值必须等于或大于 upload_max_filesize。
    • max_execution_time = 300 – PHP 脚本可以运行的最长时间(以秒为单位),这在处理大文件时很重要。
    • max_input_time = 300 – 脚本可以用于分析输入的最大时间(以秒为单位)。
  • 重新启动 PHP-FPM 进程或 PHP 服务器:保存对 php.ini 的更改后,请务必重新启动 PHP-FPM 进程(例如,sudo systemctl restart phpX.X-fpm)或整个 Web 服务器(如果 PHP 作为 Apache 模块运行)。重新启动对于 PHP 加载新配置至关重要。

重新启动后,PHP 将能够处理更大的文件和 POST 数据,这应该可以消除 PHP 限制引起的 413 错误。

简要介绍 IIS

IIS(互联网信息服务)是 Microsoft 的 Web 服务器,也可能会在那里遇到 413 错误。修复方法是修改 maxAllowedContentLength 参数。此参数通常在应用程序的 web.config 文件中找到,它指定请求有效负载的最大大小(以字节为单位)。

错误 413 预防:应用程序和客户端最佳做法

防止 413 错误不仅仅是正确配置服务器的问题。这也是 Web 应用程序和用户方面的主动行动。通过建立正确的机制,我们可以避免在请求到达服务器之前发送超出限制的请求。这将确保用户不会遇到这个烦人的消息。

以下是实施的最佳实践:

  • 实现客户端文件大小验证:应用程序应在将文件上传到服务器之前检查文件的大小。例如,使用 JavaScript,可以在超出限制时立即通知用户并阻止上传。这样可以节省精力和时间。
  • 使用分块上传:如果正在处理非常大的文件(例如高分辨率视频),请考虑分块上传技术。它涉及将文件拆分为单独发送的更小部分,这允许绕过单个请求的大小限制。
  • 上传前压缩文件或优化其大小:在文件到达服务器之前减小文件的大小(例如,通过优化压缩来减小照片,通过更改格式或分辨率来减小视频),可以显着降低超出限制的风险。
  • 在应用程序界面中告知用户文件大小限制:简单明了的消息,例如“最大文件大小:25 MB”,可以防止沮丧并节省用户时间,它们不会尝试上传太大的文件。
  • 使用云服务或专用平台共享大文件:可以使用外部服务,而不是直接处理非常大的文件来给服务器带来负担。创建 Google Drive、Dropbox 或 WeTransfer 等平台是为了有效管理和共享大量数据。然后,应用程序只能存储指向文件的链接,而不是文件本身。

有效预防 413 错误是双管齐下的方法:不仅要正确配置服务器,而且最重要的是,应该在客户端对数据进行智能验证和优化。这减轻了服务器的负载并提供了更好的用户体验。

错误413对用户体验和SEO的影响

413有效负载太大错误虽然是一个技术问题,但会对用户如何看待网站(用户体验)产生直接且不幸的负面影响。间接地,它还会损害SEO(搜索引擎优化)。经常产生错误的页面立即显得不那么专业,也不太有用。

负面用户体验:想象一下,正在尝试上传文件或提交表单,突然弹出413错误。这非常令人沮丧。数据丢失(如果表单尚未保存)、需要重新填充所有内容或手动减少文件——所有这些都极大地恶化了用户体验。这可能是阻止进一步使用网站的有效方法。

对SEO的间接影响:尽管413错误对于搜索引擎抓取并不重要(如5xx系列错误),但其后果可能会影响在搜索结果中的排名。

  • 跳出率增加:遇到错误的用户通常会很快离开网站。高跳出率可能向Google发出信号,表明网站存在可用性问题,这显然会对其排名产生负面影响。
  • 网站质量评级较低:包括Google在内的搜索引擎会推广提供最佳用户体验的网站。频繁的错误,即使是看似在客户端的错误,也可能表明服务器或应用程序的配置不理想。这可能会降低Google对网站的整体质量评级。
  • 对抓取预算的影响:尽管413错误不会像5xx错误那样阻止索引编制,但它可能会影响抓取预算。如果搜索引擎爬虫经常遇到错误,它们可能会花更少的时间索引其他重要内容,从而减慢其发现速度。

这就是为什么修复和防止413错误非常重要的原因——不仅是为了让用户满意度,也是为了让网站在搜索引擎中保持良好表现。

常见问题解答–有关413有效负载过大错误的最常见问题

413错误是服务器端还是客户端问题?

从理论上讲,413错误是客户端问题(这就是我们将其归类为4xx客户端错误的原因)。毕竟,作为客户发送的请求的有效负载对于服务器来说太大了。但是,修复它通常需要更改服务器配置以增加可接受的限制。

如何快速检查超出了哪个限制?

检查这一点的最快方法是分析服务器日志(Nginx、Apache)和PHP日志。在那里,通常会发现一条详细消息,该消息将准确指示已超出哪个参数(无论是client_max_body_size、LimitRequestBody、upload_max_filesize还是post_max_size)。

提高限额总是安全的吗?

不,增加限制并不总是完全安全的。过高的限制可能会使服务器遭受DDoS攻击(攻击者发送大量数据负载使其过载)或导致个人用户消耗过多的服务器资源(RAM、CPU、存储空间)。在功能和安全性之间找到平衡非常重要。

CDN或代理会导致413错误吗?

当然,代理和CDN绝对可能是413错误的原因。这些中间件设备有自己的请求大小限制,也需要定制以满足应用程序的要求。如果请求对于CDN或代理来说太大,则错误甚至会在到达主服务器之前出现。

如果我无法访问我的服务器配置文件,我该怎么办?

如果无法直接访问服务器的配置文件(例如,在共享主机上),请联系服务器管理员或托管服务提供商。描述问题并请求提高限制。也可以尝试在上传前压缩文件,或使用云服务(如Google Drive、Dropbox)共享大文件。

摘要:错误413的限制和解决方案

413 Payload Too Large错误是Web环境中一个相当常见的问题,它告诉我们服务器无法处理请求,因为数据负载太大。正如我们所见,其原因很明确,通常是由于服务器配置(Nginx、Apache、PHP)或中间设备不足造成的。

修复此错误归结为精确增加相应配置文件中的请求大小限制并重新启动服务器。然而,修改本身只是一个开始。防止未来犯错同样重要。可以通过实施客户端文件大小验证、为大型上传应用数据碎片以及优化和压缩文件来做到这一点。

下表显示了主要配置参数及其位置:

服务器/元素参数/指令描述在哪里可以找到更改为 50 MB 的示例
Nginxclient_max_body_sizeHTTP 请求的最大有效负载大小。nginx.conf 或 sites-available/domainclient_max_body_size 50M;
Apache限制请求正文HTTP 请求有效负载的最大大小(以字节为单位)。httpd.conf 或 .htaccessLimitRequestBody 52428800
PHPupload_max_filesize要上传的单个文件的最大大小。php.iniupload_max_filesize = 50M
post_max_size所有 POST 数据的最大大小(必须为 >= upload_max_filesize)。php.inipost_max_size = 50M
max_execution_timePHP 脚本的最长时间(以秒为单位)。php.inimax_execution_time = 300
IIS最大允许内容长度请求有效负载的最大大小(以字节为单位)。web.config<requestLimits maxAllowedContentLength=“52428800” />
代理 / CDN自有限制中间服务器的局限性。配置给定的 CDN/代理取决于服务/解决方案

正确的服务器配置和应用程序端的主动方法是保持网站平稳运行、让用户满意并在搜索引擎中保持良好位置的关键。

👋 感谢您的观看!

© 版权声明
THE END
喜欢就支持一下吧
点赞0 分享