Nginx常見(jiàn)錯(cuò)誤與解決方法解讀

1、上海紐斯達(dá)科技Nginx常見(jiàn)錯(cuò)誤與解決方法上海紐斯達(dá)科技有限公司2014-10-25文檔狀態(tài)文件狀態(tài)：文檔編號(hào)Nsdkj-778保密等級(jí)限制【】草稿作者劉恒亮最后完成日期2014-12-25【】修改稿審核人最后審核日期2014-12-25【2】正式發(fā)布批準(zhǔn)人最后批準(zhǔn)日期2014-12-25目的：在Nginx服務(wù)器岀現(xiàn)故障時(shí)，能快速定位并解決相關(guān)錯(cuò)誤。保密：本文檔僅供內(nèi)部使用，請(qǐng)勿外傳概述：Nginx常見(jiàn)錯(cuò)誤與問(wèn)題之解決方法技術(shù)指南。安裝環(huán)境：系統(tǒng)環(huán)境：redhat en terprise 6.5 64bit1、Nginx常見(jiàn)啟動(dòng)錯(cuò)誤有的時(shí)候初次安裝nginx的時(shí)候會(huì)報(bào)這樣的錯(cuò)誤sbin/ngi

2、nx -c conf/ngin x.c onf報(bào)錯(cuò)內(nèi)容： sbin/nginx: error while load ing shared libraries: libpcre.so.1:cannot open shared object file: No such file or directory啟動(dòng)時(shí)如果報(bào)異常error while loading shared libraries: libpcre.so.1: cannot openshared object file: No such file or directory這說(shuō)明我們的環(huán)境還不是和啟動(dòng)需要小小的配置一下解決方法（直接運(yùn)行）：

3、32 位系統(tǒng)rootsever lib# ln -s /usr/local/lib/libpcre.so.1 /lib64 位系統(tǒng)rootsever lib# ln -s /usr/local/lib/libpcre.so.1 /lib64然后執(zhí)行ps -ef | grep nginx查看nginx進(jìn)程確認(rèn)是否真的已經(jīng)啟動(dòng)了，在進(jìn)程列表里會(huì)有最起碼兩個(gè)，worker（nginx工作進(jìn)程）和master （nginx主進(jìn)程）root 4349 1 0 02:24 ? 00:00:00 ngi nx: master process sbi n/n gi nx -cconf/ngin x.c onf

4、nginx 4350 4349 0 02:24 ? 00:00:00 ngi nx: worker processroot 4356 28335 0 02:30 pts/1 00:00:00 grep ngi nxNGINX 就 OK 了2、 400 bad request錯(cuò)誤的原因和解決辦法配置nginx.conf相關(guān)設(shè)置如下.clie nt_header_buffer_size 16k;large_clie nt_header_buffers 4 64k;根據(jù)具體情況調(diào)整，一般適當(dāng)調(diào)整值就可以。3、Nginx 502 Bad Gateway 錯(cuò)誤在 php.ini和口 php-fpm.co

5、nf 中分別有這樣兩個(gè)配置項(xiàng)：max_execution_time和口request_termi nate_timeout。這兩項(xiàng)都是用來(lái)配置一個(gè)PHP腳本的最大執(zhí)行時(shí)間的。當(dāng)超過(guò)這個(gè)時(shí)間時(shí)，PHP-FPM不只會(huì)終止腳本的執(zhí)行，還會(huì)終止執(zhí)行腳本的Worker進(jìn)程。所以Nginx會(huì)發(fā)現(xiàn)與自己通信的連接斷掉了，就會(huì)返回給客戶端502錯(cuò)誤。以 PHP-FPM的 request_terminate_timeout=30秒時(shí)為例，報(bào) 502 Bad Gateway 錯(cuò)誤的具體信息如下：1) Nginx錯(cuò)誤訪問(wèn)日志：2013/09/19 01:09:00 error 27600#0: *78887 rec

6、v() failed (104: Conn ectionreset by peer) while readi ng resp onse header from upstream,client: 01, server: , request: POST /index.phpHTTP/1.1, upstream: fastcgi:/u ni x:/dev/shm/php-fcgi.sock:,host: , referrer: /in dex.php2) PHP-FPM報(bào)錯(cuò)日志：WARNING: child 25708

7、 exited on signal 15 (SIGTERM) after 21008.883410sec onds from start所以只需將這兩項(xiàng)的值調(diào)大一些就可以讓PHP腳本不會(huì)因?yàn)閳?zhí)行時(shí)間長(zhǎng)而被終止了。request_terminate_timeout 可以覆蓋 max_execution_time，所以如果不想改全局的php.ini ，那只改PHP-FPM的配置就可以了。此外要注意的是 Nginx的upstream 模塊中的 max_fail和fail_timeout 兩項(xiàng)。有時(shí) Nginx與上游服務(wù)器(如Tomcat、FastCGI )的通信只是偶然斷掉了，但max_fail如果

8、設(shè)置的比較小的話，那么在接下來(lái)的fail_timeout時(shí)間內(nèi)，Nginx都會(huì)認(rèn)為上游服務(wù)器掛掉了，都會(huì)返回502錯(cuò)誤。所以可以將max_fail調(diào)大一些，將 fail_timeout調(diào)小一些。4、Nginx 岀現(xiàn)的 413 Request Entity Too Large 錯(cuò)誤這個(gè)錯(cuò)誤一般在上傳文件的時(shí)候會(huì)出現(xiàn)，編輯Nginx主配置文件 Nginx.conf ，找到http段，添加clie nt_max_body_size 10m; /設(shè)置多大根據(jù)自己的需求作調(diào)整如果運(yùn)行php的話這個(gè)大小client_max_body_size 要和php.ini中的如下值的最大值一致或者稍大，這樣就不會(huì)因

9、為提交數(shù)據(jù)大小不一致出現(xiàn)的錯(cuò)誤。post_max_size = 10Mupload_max_filesize = 2M5、解決 504 Gateway Time-out(nginx)遇到這個(gè)問(wèn)題是在升級(jí) discuz論壇的時(shí)候遇到的一般看來(lái)，這種情況可能是由于 nginx默認(rèn)的 fastcgi進(jìn)程響應(yīng)的緩沖區(qū)太小造成的，這將導(dǎo)致fastcgi進(jìn)程被掛起，如果你的fastcgi服務(wù)對(duì)這個(gè)掛起處理的不好，那么最后就極有可能導(dǎo)致 504 Gateway Time-out,現(xiàn)在的網(wǎng)站，尤其某 些論壇有大量的回復(fù)和很多內(nèi)容的，一個(gè)頁(yè)面甚至有幾百 K。默認(rèn)的fastcgi進(jìn)程響應(yīng)的緩沖區(qū)是8K,我們可以設(shè)

10、置大點(diǎn)在nginx.conf里，加入：fastcgi_buffers 8 128k 這表示設(shè)置fastcgi緩沖區(qū)為 8X 128當(dāng)然如果您在進(jìn)行某一項(xiàng)即時(shí)的操作，可能需要nginx的超時(shí)參數(shù)調(diào)大點(diǎn)，例如設(shè)置成90秒：send_timeout 90;只是調(diào)整了這兩個(gè)參數(shù)，結(jié)果就是沒(méi)有再顯示那個(gè)超時(shí)，效果不錯(cuò)Nginx中關(guān)于與上游服務(wù)器通信超時(shí)時(shí)間的配置factcgi_connect/read/send_timeout。以Nginx超時(shí)時(shí)間為90秒，PHP-FPM超時(shí)時(shí)間為 300秒為例，報(bào)504 Gateway Timeout 錯(cuò)誤時(shí)的Nginx錯(cuò)誤訪問(wèn)日志如下：2013/09/19 00:5

11、5:51 error 27600#0: *78877 upstream timed out (110:Conn ecti on timed out) while readi ng resp onse header from upstream,clie nt:01, server: , request: POST /in dex.phpHTTP/1.1, upstream: fastcgi:/u ni x:/dev/shm/php-fcgi.sock:,host: , referrer: /in dex.php調(diào)高

12、這三項(xiàng)的值(主要是read和send兩項(xiàng)，默認(rèn)不配置的話Nginx會(huì)將超時(shí)時(shí)間設(shè)為 60秒)之后，504錯(cuò)誤也解決了。而且這三項(xiàng)配置可以配置在http、server級(jí)別，也可以配置在location級(jí)別。擔(dān)心影響其他應(yīng)用的話，就配置在自己應(yīng)用的locati on中吧。要注意的是 factcgi_connect/read/send_timeout是對(duì) FastCGI 生效的，而proxy_connect/read/send_timeout是對(duì) proxy_pass 生效的。配置舉例：locati on .php$ root/home/cdai/;ms;fastcgi_c onn

13、ect_timeout fastcgi_read_timeout fastcgi_se nd_timeout fastcgi_pass-fcgi.sock;fastcgi_param/home/cdai/$fastcgi_script_ name;600;600;uni x:/dev/shm/phpin dex.php;SCRIPT_FILENAME6、如何使用 Ngi nx Proxy朋友一臺(tái)服務(wù)器運(yùn)行 tomcat為8080端口，IP::8080,另一臺(tái)機(jī)器IP:.朋友想通過(guò)訪問(wèn)即可訪問(wèn)tomca

14、t服務(wù).配置如下在 的nginx.conf 上配置如下server listen 80;server_ name java .lin uxt on locati on / proxy_pass :8080;in clude /usr/local/ngin x/c on f/proxy.c onf; 7.安裝完成Nginx后無(wú)法站外訪問(wèn)？剛安裝好nginx 個(gè)常見(jiàn)的問(wèn)題是無(wú)法站外訪問(wèn)，本機(jī)wget、tel net都正常。而服務(wù)器之外,不管是局域網(wǎng)的其它主機(jī)還是互聯(lián)網(wǎng)的主機(jī)都無(wú)法訪問(wèn)站點(diǎn)。如果用tel net 的話，提示:正在連接到

15、192.168.0.XXX. 不能打開(kāi)到主機(jī)的連接,在端口 80:連接失敗如果用wget命令的話，提示：Connecting to 00:80. failed: No route to host.如果是以上的故障現(xiàn)象，很可能是被CentOS的防火墻把80端口攔住了，嘗試執(zhí)行以下命令，打開(kāi)80端口：iptables -I INPUT -p tcp -dport 80 -j ACCEPT然后用:/etc/ in it.d/iptables status查看當(dāng)前的防火墻規(guī)則，如果發(fā)現(xiàn)有這樣一條:ACCEPT80tcp/0o.o.o.o/otcp dpt:就說(shuō)明防火

16、墻規(guī)則已經(jīng)添加成功了，再在站外訪問(wèn)就正常了8、如何關(guān)閉 Nginx的LOG access_log /dev/ null error_log /dev/ null此外，錯(cuò)誤日志主要記錄客戶端訪問(wèn)nginx出錯(cuò)時(shí)的日志， 通過(guò)錯(cuò)誤日志，能快速定位客戶端訪問(wèn)異常！錯(cuò)誤信息錯(cuò)誤說(shuō)明upstream prematurely (過(guò)早 的) closed conn ecti on請(qǐng)求uri的時(shí)候出現(xiàn)的異常，是由于 upstream還未返回應(yīng)答給用戶時(shí)用戶斷 掉連接造成的，對(duì)系統(tǒng)沒(méi)有影響，可以 忽略recv() failed (104: Conn ection reset by peer)（1）服務(wù)器的并發(fā)連

17、接數(shù)超過(guò)了其承載 量，服務(wù)器會(huì)將其中一些連接 Down掉；（2）客戶關(guān)掉了瀏覽器，而服務(wù)器還在 給客戶端發(fā)送數(shù)據(jù)；（3）瀏覽器端按了 Stop(111: Co nn ection refused) while connecting to upstream用戶在連接時(shí)，若遇到后端upstream掛掉或者不通，會(huì)收到該錯(cuò)誤(111: Co nn ection refused) while readi ng resp onse header from upstream用戶在連接成功后讀取數(shù)據(jù)時(shí)，若遇到 后端upstream掛掉或者不通，會(huì)收到該 錯(cuò)誤(111: Co nn ection refuse

18、d) while sending request to upstreamNginx和upstream連接成功后發(fā)送數(shù)據(jù) 時(shí)，若遇到后端upstream掛掉或者不通， 會(huì)收到該錯(cuò)誤(110: Co nn ection timed out) while connecting to upstreamnginx連接后面的upstream時(shí)超時(shí)(110: Co nn ection timed out) whilenginx讀取來(lái)自u(píng)pstream的響應(yīng)時(shí)超時(shí)readi ng upstream(110: Co nn ection timed out) while readi ng resp onse header from upstreamnginx讀取來(lái)自u(píng)pstream的響應(yīng)頭時(shí)超 時(shí)(110: Co nn ection timed out) while readi ng upstreamnginx讀取來(lái)自u(píng)pstream的響應(yīng)時(shí)超時(shí)(104: Connection reset by peer) while connecting to upstreamupstream發(fā)送了 RST，將連接重置upstream sent in valid header while readi ng resp onse header from upstr