記一次線上接口404排查過程

時間 2020-01-20

標籤一次線上接口排查過程简体版

原文原文鏈接

前言

今天週五美滋滋的劃半天水，上個廁所回來客戶羣裏來了一條信息，丟了一張截圖，衝上來就問，這個怎麼編輯不了了？html

我特麼一臉矇蔽，我也想知道爲何編輯不了了啊。打開線上系統，找到編輯彈窗，按下F12，調到network，使出渾身力氣按下保存按鈕，內心想着，xx用戶確定是你操做不當，看我這不是好的嗎。前端

network中血紅的報錯就像被一巴掌打過的臉同樣，我太難了。爲何，爲何明明這個功能上線了一個多月了沒有這個問題。好了不戲精了，來看問題。nginx

排查

第一步

打開network觀察發現只有一個接口報了404。其餘接口都是好的，想着這個破代碼一個多月沒動過了，應該不是代碼的問題。右鍵將這個接口地址複製到瀏覽器直接打開json

由於這個接口是POST請求方式，因此返回錯誤，可是http status仍是正常的200的呀，由於還能正常走到代碼邏輯裏後端

這裏暫時排除後端代碼的問題瀏覽器

第二步

由於這個需求已經上線一個多月了，並且測試環境線上環境都驗證過。前端調用其餘接口包括GET/POST都是正常的bash

這裏暫時排除前端代碼問題服務器

第三步

把這個接口url複製到postman，不帶任何參數請求一次：post

一樣能夠調通，也是正常的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，必定是失敗的。若是須要上傳大文件，必定要修改該值。