問題描述：
1.通常我們會想到是不是因為中文?
2.通過測試，發現不包含中文的返回最終響應的也是亂碼。
3.目前為止排除了編碼問題，檢視閘道器日誌，應用日誌，發現閘道器拿到的資料全部亂碼，但是應用返回確是全部正常，問題查到這兒，基本將問題定位到閘道器和服務之間的互動可能不太正常。
通過抓包工具，發現了伺服器端http響應頭多了一行:content-encoding:gzip；查到這兒，問題已經找到，閘道器並沒有對壓縮後的資料進行解壓縮，所以響應亂碼，特做如下記錄：
content-type與content-encoding區別？
通過中文翻譯，前者為內容型別，後者為內容編碼；
可以這樣理解：後者用於指定服務端在內容傳輸到客戶端之前執行的任何其他編碼，所以客戶端需要針對內容編碼進行處理，然後根據內容型別去最終響應資料。
解決方案也很簡單，閘道器在請求服務端時新增相應的請求頭資訊，宣告客戶端支援的編碼型別就可以了:accept-encoding:gzip,deflate
那麼這次事件是怎麼產生的呢，檢視公升級歷史，才發現，這次公升級在spring boot中增加了如下配置資訊:server.compression.enabled，這項配置預設是false，但是專案組有同事把這項配置設定為true了，好吧，原來是這個問題。。。
至於為什麼直接訪問伺服器位址可以訪問，經過測試，是因為在使用瀏覽器，請求工具等去傳送請求的時候，預設新增了頭資訊accept-encoding:gzip, deflate, br，可以解析資料，但是閘道器在設計層面，還沒有相容這種場景。。。
爛泥 記一次詭異的網路中斷
本文首發於 爛泥行天下 本來這篇文章早就改寫了，但是因為各種原因一直拖著沒有寫。今天剛好周五，把這篇文章寫下。最近一段時間，同事反映每天下午6 00到6 30公司網路會中斷一次，並且一次的終端持續時間為15s左右。而後自動網路恢復正常。既然同事都說了，那咱就找找問題的原因。既然是網路終端，而且是很有...
記一次詭異的SpringMVC中攔截路徑的問題
dispatcherservlet org.springframework.web.servlet.dispatcherservlet contextconfiglocation classpath springmvc.xml 1dispatcherservlet 2.將url pattern改為 ...
一次詭異的http404錯誤的解決
新開發的 在開發機上執行的好好的，部署到伺服器上就出錯了，並且錯誤的現象很詭異，總是在開機的第一次開啟瀏覽器時顯示http 1.1 404 not found 重新整理頁面或者從新開啟瀏覽器就好了。最開始懷疑是程式的問題，後來想想沒有道理啊，重新整理後就可以正常執行了，不應該是程式有問題啊。再懷疑是...