原文：https://blog.csdn.net/amdkings1/article/details/79092937 

nginx 配置中有1個upstream配置是指向一個域名Y的，而這個域名Y解析對應IP其實是會動態變化的。

最近生產環境發現一個奇怪現象，上面的配置正常運行了至少半年以上，突然報告404.開啟nginx的error日誌後，發現nginx解析Y的結果竟然和ping解析的不同。於是查了nignx的資料，發現nginx本身有dns快取機制，配置檔案中 resolver 配置了dns的valid時間是10天。

這樣問題就清楚了。nginx -s reload 就能解決上面的問題。

為了搞明白上面的問題，特地查了作業系統級別的dns快取和nginx 的dns快取機制。對於作業系統級別的dns快取，無論是widnows還是ubuntu都有快取專案的“生存時間”，生存時間到了才會重新整理快取。

對於nginx 的 dns 快取來說，nginx會在首次proxy_pass到upsteam時並且upstream是域名配置的，nginx就會解析域名，並快取直到valid時間後，再重新重新解析dns的結果。

這樣來看的話，如果我們想要把域名Y後面對應的伺服器S退出的話，比較合理的做法應該是讓已經退休的S執行一段時間，在開一臺新的伺服器S2，把域名Y解析到S2上。但是至少要保證原來的S能夠正常執行足夠久的時間T。這樣所有的客戶端，才可以正常訪問服務。通過在windows上檢視 ipconfig /displaydns 發現“生存時間”一般的不會大於24小時，linux上的配置需要看使用何種dns快取軟體，無論使用何種軟體，“生存時間”一般不適宜設定的過大。如果設定的過大，超出了時間T，就會出現不強制重新整理dns快取，就不能訪問服務的問題。像我這次遇到的問題，其實本質上也是把nginx的“生存時間” valid配置的過大有關係。順帶說一下，過小也不可取。其實，我的生產環境中，Y對應的server在改變後，原來的伺服器S是運行了一段時間的，但是我配置的valid太大了，所以出問題了。