前言
今天週五美滋滋的劃半天水，上個廁所回來客戶羣裏來了一條信息，丟了一張截圖，衝上來就問，這個怎麼編輯不了了？
我特麼一臉矇蔽，我也想知道爲什麼編輯不了了啊。打開線上系統，找到編輯彈窗，按下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排查過程