抱歉，您正在查找的頁面目前不可用。
請稍後再試。
如果您是此資源的系統管理員，那麽您應該檢查錯誤日誌以了解詳細信息。
妳忠實的，nginx。
如上所述，剛剛老徐正打算去平臺寫文章，出現了上面的錯誤，應該會持續幾分鐘~不知道有多少用戶感覺到了，平臺反應不錯，幾分鐘後恢復正常~
nginx報告的此類錯誤壹般有以下原因(當然老徐對nginx並不了解，以下是壹些可能的原因)。
如果有問題，第壹件事就是分析nginx的日誌，得到壹些線索~
可能的常見原因:
/ 1 /
顯然，這是壹個nginx錯誤。在查看nginx.conf文件的過程中，可能會分析出以下問題。nginx.xml中的配置如下:
紅色標記的部分是很大的嫌疑。恰好在應用提交數據的那壹刻就有很多與服務器的交互，這些交互都要經過nginx。再加上用戶IP作為關鍵，如果多個用戶上網的最後壹跳是同壹個路由器，顯然會被服務器當成電腦，造成判斷錯誤。那麽新的問題來了。為什麽出現503服務不可用後返回錯誤頁面？
針對這個問題，我們在nginx.conf中找到了另壹種配置，如下圖所示:
此配置意味著當出現500、502、503和504錯誤時，返回到50x.html頁面。該頁面位於nginx安裝目錄的html文件夾中，內容如下:
這個頁面是瀏覽器分析出來的，看起來像開頭的第壹張圖。
至此，原因大概估計出來了，之前的費率值應該比較大。那麽它有多大呢？這個要看不同的業務，即使去掉這個配置，所以這是壹個經驗值，相對於應用的合理值可以通過多次實驗得出，這裏就不說了。
nginx出現這個錯誤應該有很多原因。這裏有壹個可能的原因供妳參考。
/ 2 /
在許多情況下，HTTP狀態代碼會在日誌記錄中顯示499錯誤。我遇到的壹個情況是nginx被逆向到壹個永遠打不開的後端，就是這樣。日誌狀態記錄為499，發送的字節數為0。
總有用戶反映網站系統大起大落，因為線上產品很久沒有修改了，所以前端程序的問題基本可以排除，所以我以為是Get方法調用的接口不穩定，問了相關人員，說沒有問題。為了得到確切的證據，我向相關人員索要了nginx服務器的日誌文件(awstats log)。經過分析，我在日誌中發現了很多錯誤，錯誤代碼為499。約占整個日誌文件的1%，但只占所有報告錯誤的70%左右(所有報告錯誤見下圖)，所以所有報告錯誤加起來會超過1%，還是很大的。
什麽是499錯誤？讓我們看看NGINX的源代碼中的定義:
ngx _ string(ngx _/2008/12/27/talk-about-RC-local . html "告訴我？/etc/rc.d/rc.local "
查找:
/usr/local/PHP/sbin/PHP-fpm start，什麽是php-fpm第壹？
是FastCGI進程管理器，這是壹個可選的PHP FastGCI執行模式，有壹個非常有特色的應用，特別是在壹個繁忙的網站中:
(1)自適應再生(新！)
(2)基本統計功能(Apache的mod_status)
(3)先進的進程管理功能，可以優雅地停止/啟動。
(4)能夠使用不同的工作用戶和不同的php.ini
(5)輸入和輸出日誌記錄...
打開後，壹切恢復正常！我的服務器端技術還有很多地方用得不夠。需要學會多使用！
總結:
1.試著檢查壹下nginx.conf的設置，看看有沒有限制設置，比如limit_zone和limit_conn這些參數也是有影響的。
2.檢查防火墻，看是否有相關的設置限制。
3.檢查nginx.conf的設置，看是否有valid _ referrernone的反鏈設置被屏蔽。
4.檢查訪問靜態文件是否正常，排除錯誤~
好了，以上只是壹些猜測~
具體原因，具體分析~
越來越多的系統采用nginx，大家有必要了解壹下nginx ~