记一次线上接口404排查过程

前言

今天周五美滋滋的划半天水，上个厕所回来客户群里来了一条信息，丢了一张截图，冲上来就问，这个怎么编辑不了了？

我特么一脸蒙蔽，我也想知道为什么编辑不了了啊。打开线上系统，找到编辑弹窗，按下F12，调到network，使出浑身力气按下保存按钮，心里想着，xx用户肯定是你操作不当，看我这不是好的吗。

network中血红的报错就像被一巴掌打过的脸一样，我太难了。为什么，为什么明明这个功能上线了一个多月了没有这个问题。好了不戏精了，来看问题。

排查

• 第一步

打开network观察发现只有一个接口报了404。其他接口都是好的，想着这个破代码一个多月没动过了，应该不是代码的问题。右键将这个接口地址复制到浏览器直接打开

image

因为这个接口是POST请求方式，所以返回错误，但是http status还是正常的200的呀，因为还能正常走到代码逻辑里

这里暂时排除后端代码的问题

• 第二步

因为这个需求已经上线一个多月了，而且测试环境线上环境都验证过。前端调用其他接口包括GET/POST都是正常的

这里暂时排除前端代码问题

• 第三步

把这个接口url复制到postman，不带任何参数请求一次：

image

同样可以调通，也是正常的200。

这里排除是浏览器的问题

• 第四步

我把浏览器请求体里的参数复制到postman中试一下，如下图：

image

这个数据好像有点多哎，心里想着是不是参数的问题呢，赶紧试试看，复制到调试中：

image

注意，这里我调通了，因为最后解决这个问题了，所以现在能调通，但是之前排除的时候是返回404的

走到这里，犯罪嫌疑人已经锁定为POST请求的body了。初步怀疑是参数json体数据太多

• 第五步：验证是否是参数问题

随便在线上找一个POST请求，参数少的试一下便知有没有。

image

发现其他的POST接口是正常的，而且参数不是很多。只有刚才有问题的那个接口包含大量的参数。我去新建个文本将参数复制进去看了一下大小

这个是成功的

image

这个是失败的

image

好了罪魁祸首大概已经确定了，就决定是你的，带着这个问题去度娘找找看有没有人遇到一样的问题

• 第六步：原来是nginx搞的鬼

带着疑问去网上百度，关键词：

nginx http Post body过大 404

image

给出原文链接

发现一个很类似的问题
按照方案修改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，就会将数据先存储到临时文件中

关于

• 本文首发于记一次线上接口404排查过程