今日在使用 Nginx 的時(shí)候出現(xiàn) 500 錯(cuò)誤，就搜索了一下錯(cuò)誤代碼，分享給大家。

500（服務(wù)器內(nèi)部錯(cuò)誤）    服務(wù)器遇到錯(cuò)誤，無法完成請求。
501（尚未實(shí)施）   服務(wù)器不具備完成請求的功能。例如，當(dāng)服務(wù)器無法識(shí)別請求方法時(shí)，服務(wù)器可能會(huì)返回此代碼。
502（錯(cuò)誤網(wǎng)關(guān)）   服務(wù)器作為網(wǎng)關(guān)或代理，從上游服務(wù)器收到了無效的響應(yīng)。
503（服務(wù)不可用）  目前無法使用服務(wù)器（由于超載或進(jìn)行停機(jī)維護(hù)）。通常，這只是一種暫時(shí)的狀態(tài)。
504（網(wǎng)關(guān)超時(shí)）   服務(wù)器作為網(wǎng)關(guān)或代理，未及時(shí)從上游服務(wù)器接收請求。
505（HTTP 版本不受支持）    服務(wù)器不支持請求中所使用的 HTTP 協(xié)議版本。

Nginx 500錯(cuò)誤（Internal Server Error  內(nèi)部服務(wù)器錯(cuò)誤）：500錯(cuò)誤指的是服務(wù)器內(nèi)部錯(cuò)誤，也就是服務(wù)器遇到意外情況，而無法履行請求。

在高并發(fā)連接的情況下，Nginx是Apache服務(wù)器不錯(cuò)的替代品。Nginx同時(shí)也可以作為7層負(fù)載均衡服務(wù)器來使用。根據(jù)測試結(jié)果，Nginx 0.6.31 + PHP 5.2.6 (FastCGI) 可以承受3萬以上的并發(fā)連接數(shù)，相當(dāng)于同等環(huán)境下Apache的10倍。

但很多人用 Nginx 的時(shí)候都會(huì)出現(xiàn) 500 錯(cuò)誤，根據(jù)我使用的情況來看，有以下幾種情況。　　

1、是否磁盤空間不足？

使用 df -k 查看硬盤空間是否滿了。清理硬盤空間就可以解決500錯(cuò)誤。nginx如果開啟了access log，在不需要的情況下，最好關(guān)閉access log。access log會(huì)占用大量硬盤空間。

2、nginx配置文件錯(cuò)誤？

這里不是指語法錯(cuò)誤，nginx如果配置文件有語法錯(cuò)誤，啟動(dòng)的時(shí)候就會(huì)提示。當(dāng)配置rewrite的時(shí)候，有些規(guī)則處理不當(dāng)會(huì)出現(xiàn)500錯(cuò)誤，請仔細(xì)檢查自己的rewrite規(guī)則。如果配置文件里有些變量設(shè)置不當(dāng)，也會(huì)出現(xiàn)500錯(cuò)誤，比如引用了一個(gè)沒有值的變量。

3、如果上面的問題都不存在可能是模擬的并發(fā)數(shù)太多了，需要調(diào)整一下nginx.conf的并發(fā)設(shè)置數(shù)

4、還有就是Linux索引節(jié)點(diǎn)(inode)用滿導(dǎo)致故障的，df -i    

由索引節(jié)點(diǎn)(inode)爆滿引發(fā)500問題http://m.fzitv.net/article/175430.htm

inode譯成中文就是索引節(jié)點(diǎn)，每個(gè)存儲(chǔ)設(shè)備（例如硬盤）或存儲(chǔ)設(shè)備的分區(qū)被格式化為文件系統(tǒng)后，應(yīng)該有兩部份，一部份是inode，另一部份是Block，Block是用來存儲(chǔ)數(shù)據(jù)用的。而inode呢，就是用來存儲(chǔ)這些數(shù)據(jù)的信息，這些信息包括文件大小、屬主、歸屬的用戶組、讀寫權(quán)限等。inode為每個(gè)文件進(jìn)行信息索引，所以就有了inode的數(shù)值。操作系統(tǒng)根據(jù)指令，能通過inode值最快的找到相對應(yīng)的文件。 而服務(wù)器的Block雖然還有剩余，但inode已經(jīng)用滿，因此在創(chuàng)建新目錄或文件時(shí)，系統(tǒng)提示磁盤空間不足。

一般分析思路：

（1）查看nginx error log ，查看php error log

nginx 錯(cuò)誤日志 error.log 默認(rèn)位置：/usr/local/nginx/logs

（2）如果是too many open files，修改nginx的worker_rlimit_nofile參數(shù)，使用ulimit查看系統(tǒng)打開文件限制，修改/etc/security/limits.conf

（3）如果是腳本的問題，則需要修復(fù)腳本錯(cuò)誤，并優(yōu)化代碼

（4）各種優(yōu)化都做好，還是出現(xiàn)too many open files，那就要考慮做負(fù)載均衡，把流量分散到不同服務(wù)器上去了。

解決方法是：

1 打開/etc/security/limits.conf文件，加上兩句

代碼如下:

* soft nofile 65535
* hard nofile 65535

2 打開/etc/nginx/nginx.conf

在worker_processes的下面增加一行

代碼如下:

worker_rlimit_nofile 65535;

3 重新啟動(dòng)nginx，重新載入設(shè)置

代碼如下:

kill -9 `ps -ef | grep php | grep -v grep | awk '{print $2}'`
/usr/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -C 100 -u www-data -f /usr/bin/php-cgi
killall -HUP nginx

重啟后再看nginx的錯(cuò)誤日志，也沒有發(fā)現(xiàn)500報(bào)錯(cuò)的情況了。

4、有可能是數(shù)據(jù)庫問題我的在nginx日志php日志都沒有發(fā)現(xiàn)什么問題, 最后發(fā)現(xiàn)數(shù)據(jù)庫訪問不了,修正后問題解決。

如果按上述方法仍然解決不了問題，就可能是配置或是程序有錯(cuò)誤了。

1 查看nginx的錯(cuò)誤日志，找到可能的原因。

如果提示某些兒PHP擴(kuò)展沒有安裝，則去php.ini中打開對應(yīng)該的擴(kuò)展或是安裝對應(yīng)該的擴(kuò)展，重啟nginx和php-fpm，再次刷新頁面。

2 如果數(shù)據(jù)庫連接有問題，也可能會(huì)出現(xiàn)500錯(cuò)誤，不過日志中一定會(huì)體現(xiàn)的

在日志中提示相應(yīng)的數(shù)據(jù)庫連接有問題了，就要去查看數(shù)據(jù)庫連接是否正確。根據(jù)日志，修改對應(yīng)該的文件，數(shù)據(jù)庫問題解決后，頁面即恢復(fù)正常。

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評論