前言
今天周五美滋滋的划半天水，上个厕所回来客户群里来了一条信息，丢了一张截图，冲上来就问，这个怎么编辑不了了？
我特么一脸蒙蔽，我也想知道为什么编辑不了了啊。打开线上系统，找到编辑弹窗，按下F12，调到network，使出浑身力气按下保存按钮，心里想着，xx用户肯定是你操作不当，看我这不是好的吗。
network中血红的报错就像被一巴掌打过的脸一样，我太难了。为什么，为什么明明这个功能上线了一个多月了没有这个问题。好了不戏精了，来看问题。
排查
- 第一步
打开network观察发现只有一个接口报了404。其他接口都是好的，想着这个破代码一个多月没动过了，应该不是代码的问题。右键将这个接口地址复制到浏览器直接打开
因为这个接口是POST请求方式，所以返回错误，但是http status还是正常的200的呀，因为还能正常走到代码逻辑里
这里暂时排除后端代码的问题
- 第二步
因为这个需求已经上线一个多月了，而且测试环境线上环境都验证过。前端调用其他接口包括GET/POST都是正常的
这里暂时排除前端代码问题
- 第三步
把这个接口url复制到postman，不带任何参数请求一次：
同样可以调通，也是正常的200。
这里排除是浏览器的问题
- 第四步
我把浏览器请求体里的参数复制到postman中试一下，如下图：
这个数据好像有点多哎，心里想着是不是参数的问题呢，赶紧试试看，复制到调试中：
注意，这里我调通了，因为最后解决这个问题了，所以现在能调通，但是之前排除的时候是返回404的
走到这里，犯罪嫌疑人已经锁定为POST请求的body了。初步怀疑是参数json体数据太多
- 第五步：验证是否是参数问题
随便在线上找一个POST请求，参数少的试一下便知有没有。
发现其他的POST接口是正常的，而且参数不是很多。只有刚才有问题的那个接口包含大量的参数。我去新建个文本将参数复制进去看了一下大小
这个是成功的
这个是失败的
好了罪魁祸首大概已经确定了，就决定是你的，带着这个问题去度娘找找看有没有人遇到一样的问题
- 第六步：原来是nginx搞的鬼
带着疑问去网上百度，关键词：
nginx http Post body过大 404
按照方案修改nginx配置
# Nginx分配给请求数据的Buffer大小
client_body_buffer_size 128k;
# 控制该server的所有请求报文大小
client_max_body_size 16m重启服务，再次尝试问题就解决了。
总结
-
client_max_body_size
client_max_body_size 默认 1M，表示 客户端请求服务器最大允许大小，在“Content-Length”请求头中指定。如果请求的正文数据大于client_max_body_size，HTTP协议会报错 413 Request Entity Too Large。就是说如果请求的正文大于client_max_body_size，一定是失败的。如果需要上传大文件，一定要修改该值。
-
client_body_buffer_size
Nginx分配给请求数据的Buffer大小，如果请求的数据小于client_body_buffer_size直接将数据先在内存中存储。如果请求的值大于client_body_buffer_size小于client_max_body_size，就会将数据先存储到临时文件中