网站上传文件提示413怎么办？

网站上传小图片正常，但上传视频、压缩包或较大的附件时，页面出现“413 Request Entity Too Large”或“413 Payload Too Large”，一般表示请求内容超过了某一层服务允许的大小。

处理这类问题，需要先找到拒绝请求的位置，再调整对应限制。本文以Linux服务器上的Nginx网站为例。

一、确认413错误来自哪一层

在浏览器中按F12打开开发者工具，进入“网络（Network）”，重新上传一次，找到返回413的请求，记录请求地址、发生时间和文件大小。

随后查看对应站点的Nginx错误日志：

sudo tail -n 50 /var/log/nginx/error.log

日志路径以实际配置为准。使用建站面板的网站，可能有单独的站点日志。

如果看到类似内容：

client intended to send too large body: 10486000 bytes

并且时间、域名、请求路径与本次上传一致，说明这一层Nginx因请求体过大而拒绝了上传。

如果没有对应记录，还需要检查前置CDN、WAF、其他反向代理及应用日志。仅凭错误页面上的标识，不能准确判断故障来源。

注意： 首页能打开，或者执行curl -I返回正常，都不能证明文件上传限制已经满足要求。

Linux查看Nginx日志定位文件上传413错误

二、调整对应站点的Nginx限制

查看Nginx读取的配置文件：

sudo nginx -T

根据输出中的配置文件路径、server_name和上传接口对应的location，找到实际需要修改的位置。

假设业务要求允许上传单个不超过50M的文件，可以给整个请求预留一定余量：

client_max_body_size 60m;

将这行配置添加到对应站点的server块，或修改匹配上传接口的现有location中的同名配置。

这里需要区分两个概念：

限制对象	示例值	含义
单个文件	50M	由应用或PHP限制单个上传文件
整个请求体	60m	包括文件、表单字段及封装内容

Nginx的client_max_body_size默认值为1m，可以配置在http、server或location中。如果匹配的location另设了更小的值，只修改server中的配置可能无效。

修改时还应注意：

同一配置块已有该指令时，修改原值。
保留原来的转发、鉴权和路由配置。
不要为了上传限制，直接新增一个缺少原有处理逻辑的location。
Docker部署应修改实际挂载文件或部署配置，避免容器重建后丢失。

nginx -T展示的是当前读取到的配置文件，修改后仍需完成检查和重载。

Nginx配置client_max_body_size调整上传请求大小

三、PHP网站同步检查上传配置

如果网站后端使用PHP，还需要检查PHP自身的限制。其他语言或框架应检查各自的请求体、附件或上传组件设置。

以单文件上限50M为例：

upload_max_filesize = 50M
post_max_size = 60M

其中，upload_max_filesize限制单个文件，post_max_size限制整个POST请求。

一次提交多个文件时，应按所有文件、表单字段及封装内容的总大小计算。例如，同一次请求上传两个50M文件，60M的总请求限制就不够。

修改的是网站实际使用的PHP配置。命令行PHP与网站使用的PHP-FPM可能加载不同文件，不能仅凭php --ini的输出认定网站配置已经改变。还应检查FPM池或站点配置是否覆盖了相关值。

PHP超过限制时，也可能表现为上传错误或$_POST、$_FILES为空，不一定直接返回413。

四、检查CDN和应用自身的限制

如果网站经过CDN、WAF或多层反向代理，每一层都可能限制请求大小。源站设置为60m，并不代表前面的服务也允许同样大小的请求。

建议依次核对：

检查位置	重点内容
CDN或WAF	当前套餐和站点允许的请求大小
前置反向代理	上传路径实际匹配的请求体限制
网站应用	后台附件大小、接口或上传组件限制
存储服务	单次上传限制、账号配额和可用空间

如果使用Cloudflare等服务，应以当前账号、套餐和站点设置为准。

需要上传更大文件时，可以评估应用支持的分片上传或对象存储直传方案。分片上传需要前后端配合，单独调整Nginx参数无法让普通上传接口自动支持分片。

五、检查配置并重载对应服务

对于使用systemd管理、服务名为nginx的部署，修改完成后执行：

sudo nginx -t && sudo systemctl reload nginx

&&表示配置检查通过后才执行重载。如果检查失败，应先根据报错修正文件，再重新检查。

如果Nginx运行在Docker中，并且容器名为nginx：

docker exec nginx nginx -t &&
docker exec nginx nginx -s reload

容器名需要替换为实际名称。通过面板或自定义路径安装的Nginx，应使用对应实例的检查和重载方式。

如果修改了PHP配置，还需要通过面板或服务管理工具，让网站实际使用的PHP服务重新加载配置。只重载Nginx不会让PHP配置自动生效。

六、重新验证实际上传

回到网站上传页面，依次测试：

小文件是否仍能正常上传。
原先触发413的文件是否恢复正常。
接近业务上限的文件能否完整保存。
超过业务上限的文件是否仍会被合理拒绝。

如果上传接口支持普通表单提交，也可以使用curl辅助测试：

curl -sS --max-time 120 \
  -o /tmp/upload-response.txt -w 'HTTP %{http_code}\n' \
  -F 'file=@/tmp/test-upload.pdf' \
  https://example.com/upload

执行前，需要将接口地址、字段名file和本地文件路径替换为实际值。示例文件必须存在，并符合网站允许的文件类型。

需要登录、验证码或CSRF校验的接口，优先通过网站页面测试。

返回HTTP 200并不一定代表上传成功。 还应检查应用返回内容，确认文件已经完整保存，且能够正常预览或下载。

检查并重载Nginx配置后使用curl验证文件上传

常见问题

1. 为什么把限制设置成50m，上传50M文件仍可能失败？

整个请求除了文件，还包含表单字段和封装内容。请求体限制需要留出余量，同时还要检查应用和PHP的单文件限制。

2. 增加超时时间或缓冲区大小，能解决413吗？

通常不能。超时、缓冲区和请求大小限制是不同配置。应先确认是哪一层拒绝了请求，再调整对应大小限制。

3. 修改配置后为什么仍然报413？

常见原因包括改错站点、匹配的location覆盖了设置、修改后未成功重载，或者CDN、另一层代理、应用仍保留较小的限制。

4. 413消失后，上传又出现500或保存失败怎么办？

继续查看应用日志，并检查上传临时目录、目标目录权限、磁盘剩余空间和存储服务配额。请求通过大小检查后，后续保存环节仍可能失败。

注意事项

修改前备份相关配置，按照业务需要设置合理上限。大文件上传还会占用带宽、临时磁盘空间和并发处理资源，不建议直接取消所有大小限制。

如果使用莱卡云服务器后仍无法定位问题，可提交工单，并提供报错时间、请求路径、文件大小、部署方式及相关日志片段，便于进一步排查。提交材料前请隐藏密码、令牌等敏感信息。