Nginx常見錯誤與解決方法

1、上海紐斯達科技上海紐斯達科技 Nginx 常見錯誤與解決方法常見錯誤與解決方法上海紐斯達科技有限公司上海紐斯達科技有限公司2014-10-25文檔狀態(tài)文檔狀態(tài)目的：目的：在 Nginx 服務器出現(xiàn)故障時，能快速定位并解決相關錯誤。保密：保密：本文檔僅供內部使用，請勿外傳概述：概述：Nginx 常見錯誤與問題之解決方法技術指南。安裝環(huán)境：安裝環(huán)境：系統(tǒng)環(huán)境：redhat enterprise 6.5 64bit文檔編號文檔編號Nsdkj-778保保 密密 等等 級級限制作作 者者劉恒亮最后完成日期最后完成日期2014-12-25審審 核核 人人最后審核日期最后審核日期2014-12-25文件狀態(tài)

2、：文件狀態(tài)：【 】草稿草稿【 】修改稿修改稿【】正式發(fā)布正式發(fā)布批批 準準 人人最后批準日期最后批準日期2014-12-251 1、NginxNginx 常見啟動錯誤常見啟動錯誤 有的時候初次安裝 nginx 的時候會報這樣的錯誤 sbin/nginx -c conf/nginx.conf 報錯內容：sbin/nginx: error while loading shared libraries: libpcre.so.1: cannot open shared object file: No such file or directory 啟動時如果報異常 error while loadin

3、g shared libraries: libpcre.so.1: cannot open shared object file: No such file or directory 這說明我們的環(huán)境還不是和啟動需要小小的配置一下 解決方法(直接運行)：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 進程確認是否真的已經啟動了，在進程

4、列表里會有最起碼兩個， worker(nginx 工作進程)和 master（nginx 主進程） root 4349 1 0 02:24 ? 00:00:00 nginx: master process sbin/nginx -c conf/nginx.confnginx 4350 4349 0 02:24 ? 00:00:00 nginx: worker process root 4356 28335 0 02:30 pts/1 00:00:00 grep nginx NGINX 就 OK 了 2 2、400400 badbad requestrequest 錯誤的原因和解決辦法錯誤的原因

5、和解決辦法配置 nginx.conf 相關設置如下.client_header_buffer_size 16k;large_client_header_buffers 4 64k;根據具體情況調整，一般適當調整值就可以。3 3、NginxNginx 502502 BadBad GatewayGateway 錯誤錯誤在 php.ini 和 php-fpm.conf 中分別有這樣兩個配置項：max_execution_time 和request_terminate_timeout。這兩項都是用來配置一個 PHP 腳本的最大執(zhí)行時間的。當超過這個時間時，PHP-FPM 不只會終止腳本的執(zhí)行，還會終止

6、執(zhí)行腳本的 Worker 進程。所以 Nginx 會發(fā)現(xiàn)與自己通信的連接斷掉了，就會返回給客戶端 502 錯誤。以 PHP-FPM 的 request_terminate_timeout=30 秒時為例，報 502 Bad Gateway 錯誤的具體信息如下：1）Nginx 錯誤訪問日志： 2013/09/19 01:09:00 error 27600#0: *78887 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 01

7、, server: , request: POST /index.php HTTP/1.1, upstream: fastcgi:/unix:/dev/shm/php-fcgi.sock:, host: , referrer: http:/ 報錯日志： WARNING: child 25708 exited on signal 15 (SIGTERM) after 21008.883410 seconds from start所以只需將這兩項的值調大一些就可以讓 PHP 腳本不會因為執(zhí)行時間長而被終止了。request_terminate_timeout 可以覆蓋 max_execution_

8、time，所以如果不想改全局的 php.ini，那只改 PHP-FPM 的配置就可以了。此外要注意的是 Nginx 的 upstream 模塊中的 max_fail 和 fail_timeout 兩項。有時 Nginx 與上游服務器（如 Tomcat、FastCGI）的通信只是偶然斷掉了，但 max_fail 如果設置的比較小的話，那么在接下來的 fail_timeout 時間內，Nginx 都會認為上游服務器掛掉了，都會返回 502 錯誤。所以可以將 max_fail 調大一些，將 fail_timeout 調小一些。4 4、NginxNginx 出現(xiàn)的出現(xiàn)的 413413 RequestR

9、equest EntityEntity TooToo LargeLarge 錯誤錯誤這個錯誤一般在上傳文件的時候會出現(xiàn)，編輯 Nginx 主配置文件 Nginx.conf，找到 http段，添加client_max_body_size 10m; /設置多大根據自己的需求作調整.如果運行 php 的話這個大小 client_max_body_size 要和 php.ini 中的如下值的最大值一致或者稍大，這樣就不會因為提交數(shù)據大小不一致出現(xiàn)的錯誤。post_max_size = 10Mupload_max_filesize = 2M5 5、解決、解決 504504 GatewayGateway

10、Time-out(nginx)Time-out(nginx)遇到這個問題是在升級 discuz 論壇的時候遇到的一般看來, 這種情況可能是由于 nginx 默認的fastcgi 進程響應的緩沖區(qū)太小造成的, 這將導致 fastcgi 進程被掛起, 如果你的 fastcgi 服務對這個掛起處理的不好, 那么最后就極有可能導致 504 Gateway Time-out,現(xiàn)在的網站, 尤其某些論壇有大量的回復和很多內容的, 一個頁面甚至有幾百 K。默認的 fastcgi 進程響應的緩沖區(qū)是 8K, 我們可以設置大點在 nginx.conf 里, 加入： fastcgi_buffers 8 128k

11、這表示設置fastcgi 緩沖區(qū)為 8128當然如果您在進行某一項即時的操作, 可能需要 nginx 的超時參數(shù)調大點，例如設置成 90 秒：send_timeout 90;只是調整了這兩個參數(shù), 結果就是沒有再顯示那個超時, 效果不錯Nginx 中關于與上游服務器通信超時時間的配置 factcgi_connect/read/send_timeout。以 Nginx 超時時間為 90 秒，PHP-FPM 超時時間為 300 秒為例，報 504 Gateway Timeout 錯誤時的 Nginx 錯誤訪問日志如下： 2013/09/19 00:55:51 error 27600#0: *788

12、77 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 01, server: , request: POST /index.php HTTP/1.1, upstream: fastcgi:/unix:/dev/shm/php-fcgi.sock:, host: , referrer: http:/ read 和 send 兩項，默認不配置的話 Nginx 會將超時時間設為 60 秒）之后，504 錯誤也解決了。而且這三項配

13、置可以配置在 http、server 級別，也可以配置在 location 級別。擔心影響其他應用的話，就配置在自己應用的 location 中吧。要注意的是 factcgi_connect/read/send_timeout 是對 FastCGI 生效的，而proxy_connect/read/send_timeout 是對 proxy_pass 生效的。配置舉例：location .php$ root /home/cdai/; include fastcgi_params; fastcgi_connect_timeout 180; fastcgi_read_timeout 600; fas

14、tcgi_send_timeout 600; fastcgi_pass unix:/dev/shm/php-fcgi.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /home/cdai/$fastcgi_script_name; 6 6、如何使用、如何使用 NginxNginx ProxyProxy朋友一臺服務器運行 tomcat 為 8080 端口,IP::8080,另一臺機器IP:. 朋友想通過訪問 即可訪問 tomcat 服務.配置如

15、下:在 的 nginx.conf 上配置如下:server listen 80;server_name location / proxy_pass :8080;include /usr/local/nginx/conf/proxy.conf;7.7. 安裝完成安裝完成 NginxNginx 后無法站外訪問？后無法站外訪問？剛安裝好 nginx 一個常見的問題是無法站外訪問，本機 wget、telnet 都正常。而服務器之外，不管是局域網的其它主機還是互聯(lián)網的主機都無法訪問站點。如果用 telnet 的

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

17、0.0.0/0 /0 tcp dpt:80 就說明防火墻規(guī)則已經添加成功了，再在站外訪問就正常了。8 8、如何關閉、如何關閉 NginxNginx 的的 LOGLOGaccess_log /dev/nullerror_log /dev/null此外，錯誤日志主要記錄客戶端訪問 nginx 出錯時的日志，通過錯誤日志，能快速定位客戶端訪問異常！錯誤信息錯誤說明upstream prematurely（過早的） closed connection請求 uri 的時候出現(xiàn)的異常，是由于upstream 還未返回應答給用戶時用戶斷掉連接造成的，對系統(tǒng)沒有影響，可以忽略recv() fai

18、led (104: Connection reset by peer)（1）服務器的并發(fā)連接數(shù)超過了其承載量，服務器會將其中一些連接 Down掉； （2）客戶關掉了瀏覽器，而服務器還在給客戶端發(fā)送數(shù)據； （3）瀏覽器端按了 Stop(111: Connection refused) while connecting to upstream用戶在連接時，若遇到后端 upstream 掛掉或者不通，會收到該錯誤(111: Connection refused) while reading response header from upstream用戶在連接成功后讀取數(shù)據時，若遇到后端 upstre

19、am 掛掉或者不通，會收到該錯誤(111: Connection refused) while sending request to upstreamNginx 和 upstream 連接成功后發(fā)送數(shù)據時，若遇到后端 upstream 掛掉或者不通，會收到該錯誤(110: Connection timed out) while connecting to upstreamnginx 連接后面的 upstream 時超時(110: Connection timed out) while reading upstreamnginx 讀取來自 upstream 的響應時超時 (110: Connec

20、tion timed out) while reading response header from upstreamnginx 讀取來自 upstream 的響應頭時超時(110: Connection timed out) while reading upstreamnginx 讀取來自 upstream 的響應時超時(104: Connection reset by peer) while connecting to upstreamupstream 發(fā)送了 RST，將連接重置upstream sent invalid header while reading response head

21、er from upstreamupstream 發(fā)送的響應頭無效upstream sent no valid HTTP/1.0 header while reading response header from upstreamupstream 發(fā)送的響應頭無效client intended to send too large body用于設置允許接受的客戶端請求內容的最大值，默認值是 1M，client 發(fā)送的body 超過了設置值reopening logs用戶發(fā)送 kill -USR1 命令gracefully shutting down,用戶發(fā)送 kill -WINCH 命令no s

22、ervers are inside upstreamupstream 下未配置 serverno live upstreams while connecting to upstreamupstream 下的 server 全都掛了SSL_do_handshake() failedSSL 握手失敗ngx_slab_alloc() failed: no memory in SSL session shared cachessl_session_cache 大小不夠等原因造成could not add new SSL session to the session cache while SSL handshakingssl_session_cache 大小不夠等原因造成9.9. NginxNginx 出現(xiàn)出現(xiàn) upstreamupstream prematurelyprematurely closedclosed connectionconnection whilewhile readingreading responseresponse headerheader fromfrom