啊, 怎么就 413 了呢?

引言

我个人所有的笔记、文章都是记录在, 个人站点昆仑虚上的, 这段时间在粘帖图片(GIF)时总是没有反应, 正常的截图还是可以的! 最开始以为是图片比较大, 加上网络问题就没怎么在意, 但是反复试了几次依然不行, 后面就抽空排查了下, 所以就有了这篇文章!

快速总结:

现象: 请求接口状态为 413, 表明请求主体的大小超过了服务器愿意或有能力处理的限度

根本原因: 前段时间对项目整体的架构做了调整, 前后端统一都走了 Nginx 反向代理, 而 Nginx 默认情况下请求体的大小被限制为 1M, 同时我上传的图片为 5M 超出了限制, 所以就报错了

解决办法: 修改 Nginx 配置文件, 新增 client_max_body_size 字段, 修改请求体的大小限制

一、BUG 现象

在上传大文件(文件 5M 多, 格式为 GIF)时, 上传失败, 查看控制台 Graphql 接口请求情况, 发现其状态码为 413

回看参数, 没有啥毛病

回看响应, 内容为空

二、问题排查

请求接口状态码 413 是目前已知的唯一信息, 第一反应就是需要确认该状态码所代表的含义: 请求体 body 太大

回顾下近期项目做了哪些调整:

前端项目整体迁到 NextJS, 同时 Graphql 相关代码也做了改造
整体相关架构做了调整, 在部署上, 前后端单独进行部署, 用户端所有访问统一走 Nginx 进行反向代理到对应的服务(前端、后端)

接下来就需要从上面两个近期优化的方向进行排查了, 简单来说就是需要确认是部署问题、还是代码问题

代码问题好排查, 直接本地运行项目进行测试即可(本地后端接口是走 NextJS 代理的), 我这里本地项目跑起来后是无法复现该问题, 相同的文件是能够正常上传的

那么大概率就是部署的问题了, 下面我们基本就确认关键信息为 「Nginx 413」, 简单 Google 下, 可以找到很多类似的问题

找个靠谱的站点, 点进去基本就能确定下一个关键信息为 「client_max_body_size」

再换一个关键词 nginx client_max_body_size 来搜索, 多翻一翻基本就能确定就是 Nginx 配置问题了: 默认情况下 Nginx 请求体大小限制为 1M, 而我要上传的文件为 5M 明显超出了, 最后自然就 413 了, 这里我们可以通过修改 client_max_body_size 配置修改限制值

三、解决

下面就直接修改相关 Nginx 配置即可, 相关代码如下所示:

diff 复制代码

...
http {
    # HTTPS 设置
    server {
        listen 443 ssl;
        ...
+       client_max_body_size 1000M; # 设置客户端请求的最大尺寸
    }
}

修改, 并上传代码(配置文件我是放在项目下的, Nginx docker 通过挂载的方式直接使用项目下的配置文件)

重启服务(docekr compose)

sh 复制代码

docker compose stop
git pull
docker compose up -d

啊, 怎么就 413 了呢?

引言

一、BUG 现象

二、 问题排查

三、解决

四、参考

二、问题排查