NGINX作為 reverse proxy 效果非常的好。最近一場暴增的流量讓我們遇到了 502 Bad Gateway 的狀況。於是著手釐清為何會發生 502 Bad Gateway 、及如何解決？ 為何502 首先，先說明NGINX為何會丟出 502 Bad Gateway ？說穿了，就是NGINX認為後端的WEB主機都無法提供服務時…當下，NGINX的錯誤log也會留下以下記錄… no live upstreams while connecting to upstream NGINX是如何判斷後端的WEB主機無法提供服務呢？目前有提供以下兩種方式

NGINX有提供以下專用的header，讓後端的程式可以藉由這些HTTP header和NGINX溝通。這些HTTP header都不會傳送到client端。 X-Accel-Expires: set the parameters of response caching; X-Accel-Redirect: performs an internal redirect to the specified URI; X-Accel-Limit-Rate: sets the rate limit for transmission of a response to a client; X-Accel-Buffering: enables or disables buffering of a response; X-Accel-Charset: sets the desired charset of a response. 導入NGINX後都沒什麼情境去使用這些專用header。最近發現到有個情境可使用到X-Accel-Expires。簡單說明如下…

在 前一篇文章 ，提到了如何藉由重新設定NGINX Cache Key，移除不會影響網頁內容的參數。這樣的作法雖然可以提升hit rate，但實務上仍會有所限制，這篇就稍做說明… 首先，我使用瀏覽器瀏覽以下網頁 https://test.com.tw/?para1=123&fbcld=XXXXXXXXXX&para2=456 Nginx Cache Key的組成是否如 前一篇文章 所說的呢？這疑問可以觀察NGINX的cache檔案內容得到答案。 以下節錄Cache檔案的部分內容，可見fbcld已經不見 KEY: test.com.tw/?para1=123&para2=456 HTTP/1.1 200 OK Date: Tue, 14 Jan 2020 07:27:02 GMT Server: Apache Cache-Control: max-age=0 Expires: Tue, 14 Jan 2020 07:27:02 GMT Vary: Accept-Encoding,User-Agent Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=UTF-8 剛提到實務上仍會有所限制，WHY？

對一個大流量的網站，cache可說是無所不在。由訪客端的browser cache、傳輸過程中的proxy cache，到程式端的nosql等各種cache…對於cache機制，最重要的指標莫過於hit rate。這數字越高，表示該cache機制的效果越佳。 最近在處理一個爬蟲的過程中，注意到一個狀況，當行銷部門買Google廣告、或有網友將網址分享於FB時，Google或Facebook都會在網址後面加上他們自己獨有GET參數。 由於我們有採用nginx作為 reverse proxy ，主要用以降低後端的web server的loading（還有其他用途），上述的狀況會使得hit rate不好。