An error occurred.
Sorry, the page you are looking for is currently unavailable.
Please try again later.
If you are the system administrator of this resource then you should check theerror log for details.
Faithfully yours, nginx.
如上，剛老徐正打算上簡書平台，寫文章，出現如上錯誤，應該持續了幾分鍾～不知道有多少用戶有感知，平台響應還不錯，幾分鍾后已恢復正常～
一般nginx的此類報錯，原因如下（當然，老徐對nginx了解不深，如下都是一些可能原因～）
可能的常見原因：
／ 1 ／
很明顯這是一個nginx的錯誤，網上查了一些資料，都是和PHP相關的，很多人問了這個問題，但是沒有人回答，在查看nginx.conf的文件過程中分析可能是以下的問題，在nginx.xml中有如下配置：
標紅的部分是很大的嫌疑，恰好應用中在提交數據的一瞬間和服務器有多次交互，這些交互都要過nginx。再加上用戶IP來做key，假如多個用戶訪問在網上的最后一跳是同一個路由器，很顯然會被服務器當成是一台電腦，從而出現判斷錯誤。那么又一個新問題來了，出現503錯誤后為啥返回的是那個錯誤頁面呢？
帶着這個問題在nginx.conf中又發現了一段配置，如下圖：
這個配置的意思是當出現500、502、503、504的錯誤時返回50x.html頁面，這個頁面在nginx安裝目錄的html文件夾下，內容如下：
這個頁面經過瀏覽器解析就是開頭第一幅圖的樣子。
分析到這里，就大概估計出原因了，把之前的rate值該大一點即可。那么到底改多大？這個要根據不同的業務而定，甚至去掉這個配置，所以這個是個經驗值，通過多次試驗可以得到一個相對於應用合理的值，這里就不說了。實際nginx出現這個錯誤原因應該有好多，這里提供一種可能原因，以供網友參考。
／ 2 ／
日志記錄中HTTP狀態碼出現499錯誤有多種情況，我遇到的一種情況是nginx反代到一個永遠打不開的后端，就這樣了，日志狀態記錄是499、發送字節數是0。
老是有用戶反映網站系統時好時壞，因為線上的產品很長時間沒有修改，所以前端程序的問題基本上可以排除，於是就想着是Get方式調用的接口不穩定，問了相關人員，說沒有問題，為了拿到確切證據，於是我問相關人員要了nginx服務器的日志文件（awstats日志），分析后發現日志中很多錯誤碼為499的錯誤，約占整個日志文件的1%，而它只占全部報錯的70%左右（全部報錯見下圖），那么所有報錯加起來就要超過1%了，這個量還是特別大的。
499錯誤是什么？讓我們看看NGINX的源碼中的定義：
ngx_string(ngx_http_error_495_page), /* 495, https certificate error */
ngx_string(ngx_http_error_496_page), /* 496, https no certificate */
ngx_string(ngx_http_error_497_page), /* 497, http to https */
ngx_string(ngx_http_error_404_page), /* 498, canceled */
ngx_null_string, /* 499, client has closed connection */
可以看到，499對應的是 “client has closed connection”。這很有可能是因為服務器端處理的時間過長，客戶端“不耐煩”了。
Nginx 499錯誤的原因及解決方法
打開Nginx的access.log發現在最后一次的提交是出現了HTTP1.1 499 0 -這樣的錯誤，在百度搜索nginx 499錯誤，結果都是說客戶端主動斷開了連接。
但經過我的測試這顯然不是客戶端的問題，因為使用端口+IP直接訪問后端服務器不存在此問題，后來測試nginx發現如果兩次提交post過快就會出現499的情況，看來是nginx認為是不安全的連接，主動拒絕了客戶端的連接.
但搜索相關問題一直找不到解決方法，最后終於在google上搜索到一英文論壇上有關於此錯誤的解決方法：
proxy_ignore_client_abort on;
Don’t know if this is safe.
就是說要配置參數 proxy_ignore_client_abort on;
表示代理服務端不要主要主動關閉客戶端連接。
以此配置重啟nginx,問題果然得到解決。只是安全方面稍有欠缺，但比總是出現找不到服務器好多了。
還有一種原因是 我后來測試發現 確實是客戶端關閉了連接,或者說連接超時 ,無論你設置多少超時時間多沒用 原來是php進程不夠用了 改善一下php進程數 問題解決
／ 3 ／
今天網站突然出現如下錯誤：
The page you are looking for is temporarily unavailable.Please try again later.
很奇怪，我對服務器端的技術不是很熟悉，於是查詢了下google，在https://wiki.archlinux.org/index.php/Nginx
上面的解決方法：
Error: The page you are looking for is temporarily unavailable. Please try again later.
This is because the FastCGI server has not been started.
如何解決呢？
剛開始我懷疑是不是nginx掛了，我首先通過ps aux | grep nginx，結果出現：
root 3769 0.0 0.0 5760 692 ? Ss Apr21 0:00 nginx: master process /usr/local/nginx/sbin/nginx
www 3770 0.0 0.1 18680 14252 ? S Apr21 0:03 nginx: worker process
www 3771 0.0 0.1 18680 14252 ? S Apr21 0:03 nginx: worker process
www 3772 0.0 0.1 18712 14276 ? S Apr21 0:03 nginx: worker process
www 3774 0.0 0.1 18680 14248 ? S Apr21 0:03 nginx: worker process
www 3776 0.0 0.1 18712 14240 ? S Apr21 0:03 nginx: worker process
www 3777 0.0 0.1 18680 14252 ? S Apr21 0:03 nginx: worker process
www 3778 0.0 0.1 18680 14232 ? S Apr21 0:02 nginx: worker process
root 24068 0.0 0.0 5196 756 pts/1 S+ 14:33 0:00 grep nginx
可見nginx是正常的，本來打算重啟nginx的：
/usr/local/nginx/sbin/nginx -t -c /usr/local/nginx/conf/nginx.conf的，
突然覺得有沒有其他方法，有同事提示先在一個目錄下運行下test.html和test.php，結果html可以運行，php無法運行。
證實是php沒有啟動，我剛才也檢測過php的進程，的確是沒有php進程，這台服務器我不熟悉，同事幫忙查看了下
cd /etc/init.d，就是web管理員經常看的地方，是隨着系統自動啟動的服務，程序等。可以看看：
http://blog.wgzhao.com/2008/12/27/talk-about-rc-local.html的《 說說？/etc/rc.d/rc.local》
找到：
/usr/local/php/sbin/php-fpm start，首先什么是php-fpm呢？
就是FastCGI Process Manager，是一種可選的PHP FastGCI執行模式，有一點很有特點的應用，尤其是一個繁忙的網站中：
(1)可適應的進行再生(NEW!)
(2)基本的統計功能（Apache's mod_status)
(3)高級進程管理功能，能夠優雅的停止/開始
(4)能夠使用不同的工作用戶和不同的php.ini
(5)輸入，輸出日志記錄...
開啟后，一切恢復正常！自己的服務器端技術還是有很多地方使用的不夠。需要多學習使用！
總結：
1、試檢查一下nginx.conf的設置，是不是有limit的設置，比如limit_zone、limit_conn，這些參數也是有影響的。
2、檢查一下防火牆，是不是有相關的設置限制。
3、檢查一下nginx.conf的設置，看看有沒有valid_referers none blocked的防鏈設置。
4、看下訪問靜態文件是否正常，錯誤排除～
OK，如上只是一些猜測～
具體原因，具體分析～
越來越多的系統，采用nginx，大家有必要了解些nginx的知識～