前言
今天週五美滋滋的劃半天水,上個廁所回來客戶羣裏來了一條信息,丟了一張截圖,衝上來就問,這個怎麼編輯不了了?
我特麼一臉矇蔽,我也想知道爲什麼編輯不了了啊。打開線上系統,找到編輯彈窗,按下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
,就會將數據先存儲到臨時文件中
關於
- 本文首發於記一次線上接口404排查過程