nginx错误总结
2、访问日志
log_format main '$http_x_forwarded_for $remote_user [$time_local] '
'"$request" $status $request_time '
'"$http_referer" "$http_user_agent" "$remote_addr" '
'$upstream_response_time "$server_name"';
[Access.log]
log_format main '$remote_addr $remote_user [$time_local] "$request" $http_host '
'$status $upstream_status $body_bytes_sent "$http_referer" '
'"$http_user_agent" $ssl_protocol $ssl_cipher $upstream_addr '
'$request_time $upstream_response_time';
变量名称 |
变量描述 |
举例说明 |
$remote_addr |
客户端地址 |
113.140.15.90 |
$remote_user |
客户端用户名称 |
- |
$time_local |
访问时间和时区 |
18/Jul/2012:17:00:01 +0800 |
$request |
请求的URI和HTTP协议 |
"GET /pa/img/home/logo-alipay-t.png HTTP/1.1" |
$http_host |
请求地址,即浏览器中你输入的地址(IP或域名) |
img.alipay.com 10.253.70.103 |
$status |
HTTP请求状态 |
200 |
$upstream_status |
upstream状态 |
200 |
$body_bytes_sent |
发送给客户端文件内容大小 |
547 |
$http_referer |
跳转来源 |
"https://cashier.alipay.com.../" |
$http_user_agent |
用户终端代理 |
"Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; SV1; GTB7.0; .NET4.0C; |
$ssl_protocol |
SSL协议版本 |
TLSv1 |
$ssl_cipher |
交换数据中的算法 |
RC4-SHA |
$upstream_addr |
后台upstream的地址,即真正提供服务的主机地址 |
10.228.35.247:80 |
$request_time |
整个请求的总时间 |
0.205 |
$upstream_response_time |
请求过程中,upstream响应时间 |
0.002 |
线上实例:
116.9.137.90 - [02/Aug/2012:14:47:12 +0800] "GET /images/XX/20100324752729.png HTTP/1.1"img.alipay.com 200 200 2038 https://cashier.alipay.com/XX/PaymentResult.htm?payNo=XX&outBizNo=2012XX "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; Tablet PC 2.0; 360SE)" TLSv1 AES128-SHA 10.228.21.237:80 0.198 0.001
线下测试($http_referer):
10.14.21.197 - - [14/Aug/2012:17:28:22 +0800] "GET /spanner/watch/v1?--db=ztg-1&--mode=compare&--index=status&--option=&--cluster=whole&-F=2012%2F8%2F12-00%3A00%3A00&-T=%2B2880&-i=1&-n=0&_=1344936501292 HTTP/1.1" 200 94193 "http://spanner.alipay.net/optionFrame/history.html" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.60 Safari/537.1"
备注:$http_referer和重定向有关。
线下测试($http_host):
备注:$http_host的值和你在浏览器里输入的值有关。
3、错误日志
错误信息 |
错误说明 |
"upstream prematurely(过早的) closed connection" |
请求uri的时候出现的异常,是由于upstream还未返回应答给用户时用户断掉连接造成的,对系统没有影响,可以忽略 |
"recv() failed (104: Connection reset by peer)" |
(1)服务器的并发连接数超过了其承载量,服务器会将其中一些连接Down掉; (2)客户关掉了浏览器,而服务器还在给客户端发送数据; (3)浏览器端按了Stop |
"(111: Connection refused) while connecting to upstream" |
用户在连接时,若遇到后端upstream挂掉或者不通,会收到该错误 |
"(111: Connection refused) while reading response header from upstream" |
用户在连接成功后读取数据时,若遇到后端upstream挂掉或者不通,会收到该错误 |
"(111: Connection refused) while sending request to upstream" |
Nginx和upstream连接成功后发送数据时,若遇到后端upstream挂掉或者不通,会收到该错误 |
"(110: Connection timed out) while connecting to upstream" |
nginx连接后面的upstream时超时 |
"(110: Connection timed out) while reading upstream" |
nginx读取来自upstream的响应时超时
|
"(110: Connection timed out) while reading response header from upstream" |
nginx读取来自upstream的响应头时超时 |
"(110: Connection timed out) while reading upstream" |
nginx读取来自upstream的响应时超时 |
"(104: Connection reset by peer) while connecting to upstream" |
upstream发送了RST,将连接重置 |
"upstream sent invalid header while reading response header from upstream" |
upstream发送的响应头无效 |
"upstream sent no valid HTTP/1.0 header while reading response header from upstream" |
upstream发送的响应头无效 |
"client intended to send too large body" |
用于设置允许接受的客户端请求内容的最大值,默认值是1M,client发送的body超过了设置值 |
"reopening logs" |
用户发送kill -USR1命令 |
"gracefully shutting down", |
用户发送kill -WINCH命令 |
"no servers are inside upstream" |
upstream下未配置server |
"no live upstreams while connecting to upstream" |
upstream下的server全都挂了 |
"SSL_do_handshake() failed" |
SSL握手失败 |
"SSL_write() failed (SSL:) while sending to client" |
|
"(13: Permission denied) while reading upstream" |
|
"(98: Address already in use) while connecting to upstream" |
|
"(99: Cannot assign requested address) while connecting to upstream" |
|
"ngx_slab_alloc() failed: no memory in SSL session shared cache" |
ssl_session_cache大小不够等原因造成 |
"could not add new SSL session to the session cache while SSL handshaking" |
ssl_session_cache大小不够等原因造成 |
"send() failed (111: Connection refused)" |
|
错误代码
[emerg]: could not build the proxy_headers_hash, you should increase either proxy_headers_hash_max_size: 512 or proxy_headers_hash_bucket_size: 64
解决办法
在配置文件中新增以下配置项:proxy_headers_hash_max_size 51200;
proxy_headers_hash_bucket_size 6400;
错误2:
在使用 Nginx 的过程中,因为 Nginx 本地使用了缓存,然后发布了静态资源后, CDN 回源的时候,发现没有正常回源,经过查询发现,是因为 Nginx 本地有缓存,而有没有对缓存进行刷新的原因,要刷新本地缓存,可以安装 Purge 模块。
Nginx 的缓存设置:
复制代码 代码如下:
location /
{
proxy_cache cache_go;
proxy_cache_valid 200 304 1d;
proxy_cache_key $host$uri$is_args$args;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For
$remote_addr;
proxy_pass http://127.0.0.1:8800;
expires
3024010s;
}
location ~ /purge(/.*)
{
#设置只允许指定的IP或IP段才可以清除URL缓存。
allow
127.0.0.1;
deny all;
proxy_cache_purge
cache_go $host$1$is_args$args;
}
Purge 模块是用来清除缓存的,首先下载安装 Puerge 模块。
下载 Purge 模块:
wget http://labs.frickle.com/files/ngx_cache_purge-1.2.tar.gz
解压:
tar -zxvf ngx_cache_purge-1.2.tar.gz
再编译前先使用如下命令查看 nginx 的编译选项:
复制代码 代码如下:
/home/nginx/sbin/nginx -V
nginx version: xxxx
TLS SNI support enabled
configure arguments: --prefix=/home/nginx-1.2.8 --with-pcre=../pcre-8.31
--with-zlib=../zlib-1.2.3 --with-openssl=../openssl-1.0.0d
--with-http_ssl_module --with-http_stub_status_module
--without-mail_pop3_module --without-mail_imap_module
--without-mail_smtp_module --add-module=../ngx_cache_purge-1.5
--add-module=../perusio-nginx-http-concat-321e344 --add-module=../ngx_http_vipshop_hostname_filter
--with-ld-opt=-static
上面我的编译显示有 puerge 模块,是因为我已经编译过了,然后在原有的编译参数后面加上:
复制代码 代码如下:
--add-module=/home/ngx_cache_purge-1.5
退出 Nginx ,并重新启动:
复制代码 代码如下:
./nginx -s quit
./nginx
配置 Puerge :
复制代码 代码如下:
location ~ /purge(/.*)
{
#设置只允许指定的IP或IP段才可以清除URL缓存。
allow
127.0.0.1;
deny
all;
proxy_cache_purge
cache_go $host$1$is_args$args;
}
清楚 Nginx 缓存的方式,比如你的 url 是 http://test.com/test/test.js
那清除该 js 缓存的命令即为:
复制代码 代码如下:
curl http://test.com/purge/test/test.js
通用的方式就是:
复制代码 代码如下:
curl http://test.com/purge/uri
其中 uri 就是你的 URL “http://test.com/test/test.js” 的 “test/test.js” 部分
-------------------[warn] conflicting server name "192.168.1.86" on
0.0.0.0:80, ignored
[warn]: conflicting server name “abc.com” on 0.0.0.0:80, ignored
出现这个错误一般是由于技术员的粗心造成的,原因是相同的域名abc.com出现两次甚至是多次
一般在把配置文件分离出来写时候会容易犯。技术员经常复制配置文件,然后忘记修改里面的内容
解决方法就是把所有配置文件查一遍看是否有重复出现的。
或者查询哪个配置文件中有abc.com
WINDOW下用搜索
LINUX下用grep "abc.com"
============================= NGINX 启动时报错“[warn]: conflicting server name “xxx.com” on 0.0.0.0:80, ignored”
include vhost/*.conf;
一般是由于技术人员配置时使用Include 语句,使用了nginx.conf之外的配置文件,如果两个配置文件重复配置了xxx.com就会出现这个错误。
=======================今天PHP的导出EXCEL里面突然出现超时
虽然我在PHP脚本里面写了set_time_limit(0);
但是他还是出现那种50x错误
查看日志文件后发现里面写着:
upstream timed out (110: Connection timed out) while reading response
header from upstream
解决办法如下:
编辑ngnix对应的虚拟主机配置文件
fastcgi_read_timeout 后面的时间可以根据自己的情况设置,默认是60秒
location ~ .+\.php?$
{
fastcgi_pass
127.0.0.1:1025;
#
fastcgi_pass
unix:/usr/local/webserver/fastcgi/sock/fastcgi.sock;
fastcgi_index index.php;
# For Time
out
这句是注释,可以不写
fastcgi_read_timeout 500;
include
fastcgi_params;
}
=======================nginx502 Bad Gateway
Nginx 502 Bad Gateway的含义是请求的PHP-CGI已经执行,但是由于某种原因(一般是读取资源的问题)
没有执行完毕而导致PHP-CGI进程终止。
Nginx 502错误的原因比较多,是因为在代理模式下后端服务器出现问题引起的。
这些错误一般都不是nginx本身的问题,一定要从后端找原因!
php-cgi进程数不够用、php执行时间长、或者是php-cgi进程死掉,都会出现502错误
502错误最通常的出现情况就是后端主机当机
vim /usr/local/webserver/php/etc/php-fpm.conf
一般来说Nginx
502 Bad Gateway和php-fpm.conf的设置有关,
php-fpm.conf有两个至关重要的参数,一个是”max_children”,另一个是”request_terminate_timeout” ,但是这个值不是通用的,而是需要自己计算的。
计算的方式如下:
如果你的服务器性能足够好,且宽带资源足够充足,PHP脚本没有系循环或BUG的话你可以直接将”request_terminate_timeout”设置成0s。0s的含义是让PHP-CGI一直执行下去而没有时间限制。而如果你做不到这一点,也就是说你的PHP-CGI可能出现某个BUG,或者你的宽带不够充足或者其他的原因导致你的PHP-CGI能够假死那么就建议你给”request_terminate_timeout”赋一个值,这个值可以根据你服务器的性能进行设定。一般来说性能越好你可以设置越高,20分钟 -30分钟都可以。由于我的服务器PHP脚本需要长时间运行,有的可能会超过10分钟因此我设置了900秒,这样不会导致PHP-CGI死掉而出现502 Bad gateway这个错误。
而”max_children”这个值又是怎么计算出来的呢?这个值原则上是越大越好,php-cgi的进程多了就会处理的很快,排队的请求就会很少。设置”max_children”也需要根据服务器的性能进行设定,一般来说一台服务器正常情况下每一个php-cgi所耗费的内存在20M左右,因此我的”max_children”我设置成40个,20M*40=800M也就是说在峰值的时候所有PHP-CGI所耗内存在800M以内,低于我的有效内存1Gb。而如果我的”max_children”设置的较小,比如5-10个,那么 php-cgi就会“很累”,处理速度也很慢,等待的时间也较长。如果长时间没有得到处理的请求就会出现504 Gateway Time-out这个错误,而正在处理的很累的那几个php-cgi如果遇到了问题就会出现502 Bad gateway这个错误。
----------------一般解决办法
遇到502问题,可以优先考虑按照以下两个步骤去解决。
1、查看当前的PHP
FastCGI进程数是否够用:
netstat -anpo | grep "php-cgi" | wc -l
如果实际使用的“FastCGI进程数”接近预设的“FastCGI进程数”,那么,说明“FastCGI进程数”不够用,需要增大。
# ps aux | grep php-cgi |wc -l
130
# netstat -anpo | grep "php-cgi" | wc -l
450
# netstat -anpo | grep "php-cgi" |more
tcp 0 0
192.168.12.201:52719
192.168.12.203:13002 ESTABLISHED
27687/php-cgi off (0.00/0/0)
tcp 0 0
192.168.12.201:52713
192.168.12.203:13002 ESTABLISHED
27685/php-cgi off (0.00/0/0)
tcp 0 0
192.168.12.201:52694
192.168.12.203:13002 ESTABLISHED
27682/php-cgi off (0.00/0/0)
tcp 0 0
192.168.12.201:52688
192.168.12.203:13002 ESTABLISHED
27681/php-cgi off (0.00/0/0)
tcp 0 0
192.168.12.201:52701
192.168.12.203:13002 ESTABLISHED
27683/php-cgi off (0.00/0/0)
重启后#
netstat -anpo | grep "php-cgi" | wc -l
46
[root@jushanweb1 ~]# netstat -anpo | grep "nginx" | wc -l
17
[root@jushanweb1 ~]# ps aux | grep nginx |wc -l
10
2、部分PHP程序的执行时间超过了Nginx的等待时间,可以适当增加nginx.conf配置文件中FastCGI的timeout时间,例如:
...... http { ...... fastcgi_connect_timeout 300; fastcgi_send_timeout 300;
fastcgi_read_timeout 300; ...... } ......
php.ini中memory_limit设低了会出错,修改了php.ini的memory_limit为128M,重启nginx,发现好了,原来是PHP的内存不足了。
---------------临时解决办法:
综上所述,Nginx提示502和504错误的临时解决办法是:
1、调整php-fpm.conf的相关设置:
<value name=”max_children”>32</value>
<value name=”request_terminate_timeout”>30s</value> fast-cgi的执行脚本时间
--------------------------终级解决方案:
标题3中所示的解决方案只能临时解决问题,而如果网站的访问量确实非常非常大,而Nginx+FastCGI只能对处理瞬间或短时间内的高并发有很好的效果,所以目前唯一的终极解决方案是:定时平滑重启php-cgi。
具体配置如下:
1、写一个非常简单的脚本:
#vi /home/www/scripts/php-fpm.sh
内容如下:
#!/bin/bash
# This script run at */1
/usr/local/php/sbin/php-fpm reload
2、将脚本添加至计划任务:
#crontab -e
内容如下:
*/1 * * * * /home/www/scripts/php-fpm.sh
注:为了省事起见,也可以不写脚本,直接在crontab里写入php-fpm的平滑重启命令。
-----------------
Nginx 502错误情况1:
网站的访问量大,而php-cgi的进程数偏少。
针对这种情况的502错误,只需增加php-cgi的进程数。具体就是修改/usr/local/php/etc/php-fpm.conf
文件,将其中的max_children值适当增加。这个数据要依据你的VPS或独立服务器的配置进行设置。一般一个php-cgi进程占20M内存,你可以自己计算下,适量增多。
/usr/local/php/sbin/php-fpm restart 然后重启一下.
Nginx 502错误情况2:
CPU占用率、内存占用率非常高,遭到CC攻击.
解决方法请参考:LinuxVPS简单解决CC攻击
Nginx 502错误情况3:
CPU占用率不高,内存溢出。
检查一下网站程序有没有问题?一般小偷站点常常会出现内存溢出。
检查一下/var/log/目录下的日志,看看是不是有人爆破SSH和FTP端口?
SSH、FTP遭到穷举也会占用大量内存。是的话改掉SSH端口和FTP端口即可。
=======================nginx 504 time out
Nginx 504 Gateway Time-out的含义是所请求的网关没有请求到,
简单来说就是没有请求到可以执行的PHP-CGI。
Nginx 504 Gateway Time-out则是与nginx.conf的设置有关。
504 Gateway Time-out问题常见于使用nginx作为web server的服务器的网站
一般看来, 这种情况可能是由于nginx默认的fastcgi进程响应的缓冲区太小造成的,
这将导致fastcgi进程被挂起, 如果你的fastcgi服务对这个挂起处理的不好,
那么最后就极有可能导致504
Gateway Time-out
现在的网站, 尤其某些论坛有大量的回复和很多内容的, 一个页面甚至有几百K
默认的fastcgi进程响应的缓冲区是8K, 我们可以设置大点
在nginx.conf里, 加入:
fastcgi_buffers 8 128k
这表示设置fastcgi缓冲区为8×128k
当然如果您在进行某一项即时的操作,
可能需要nginx的超时参数调大点, 例如设置成60秒:
send_timeout 60;
我只是调整了这两个参数, 结果就是没有再显示那个超时, 可以说效果不错, 但是也可能是由于其他的原因, 目前关于nginx的资料不是很多, 很多事情都需要长期的经验累计才有结果, 期待您的发现哈!
---------------解决办法:
调整nginx.conf的相关设置:
fastcgi_connect_timeout 600;
fastcgi_send_timeout 600;
fastcgi_read_timeout 600;
fastcgi_buffer_size 256k;
fastcgi_buffers 16 256k;
fastcgi_busy_buffers_size 512k;
fastcgi_temp_file_write_size 512k;
有的时候初次安装
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 loading shared libraries: libpcre.so.1: cannot open
shared object file: No such file or directory
这说明我们的环境还不是和启动需要
小小的配置一下
解决方法
(
直接运行
)
:
32
位系统
[root@sever lib]# ln -s /usr/local/lib/libpcre.so.1 /lib
64
位系统
[root@sever lib]# ln -s /usr/local/lib/libpcre.so.1 /lib64
然后执行
ps -ef | grep nginx
查看
nginx
进程确认是否真的已经启动了,在进程列表里会
有最起码两个,
worker(nginx
工作进程
)
和
master
(
nginx
主进程)
root 4349 1 0 02:24 ? 00:00:00 nginx: master process sbin/nginx -c
conf/nginx.conf
nginx 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
、
400 bad request
错误的原因和解决办法
配置
nginx.conf
相关设置如下
.
client_header_buffer_size 16k;
large_client_header_buffers 4 64k;
根据具体情况调整,一般适当调整值就可以。
3
、
Nginx 502 Bad Gateway
错误
在
php.ini
和
php-fpm.conf
中分别有这样两个配置项:
max_execution_time
和
request_terminate_timeout
。
这两项都是用来配置一个
PHP
脚本的最大执行时间的。当超过这个时间时,
PHP-FPM
不只会终止
脚本的执行,
还会终止执行脚本的
Worker
进程。所以
Nginx
会发现与自己通信的连接断掉了,就会返回给客
户端
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: 192.168.1.101, server: test.com, request: "POST /index.php
HTTP/1.1", upstream: "fastcgi://unix:/dev/shm/php-fcgi.sock:",
host: "test.com", referrer: "http://test.com/index.php"
2
)
PHP-FPM
报错日志:
WARNING: child
25708
exited
on
signal
15
(SIGTERM)
after
21008.883410
seconds
from
start
所以只需将这两项的值调大一些就可以让
PHP
脚本不会因为执行时间长而被终止了。
request_terminate_timeout
可以覆盖
max_execution_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
、
Nginx
出现的
413 Request Entity Too Large
错误
这个错误一般在上传文件的时候会出现,
编辑
Nginx
主配置文件
Nginx.conf
,找到
http{}
段,添加
client_max_body_size 10m; //
设置多大根据自己的需求作调整
.
如果运行
php
的话这个大小
client_max_body_size
要和
php.ini
中的如下值的最大值一致或
者稍大,这样就不会因为提交数据大小不一致出现的错误。
post_max_size = 10M
upload_max_filesize = 2M
5
、解决
504 Gateway Time-out(nginx)
遇到这个问题是在升级
discuz
论坛的时候遇到的一般看来
,
这种情况可能是由于
nginx
默认的
fastcgi
进程响应的缓冲区太小造成的
,
这将导致
fastcgi
进程被挂起
,
如果你的
fastcgi
服务
对这个挂起处理的不好
,
那么最后就极有可能导致
504 Gateway Time-out,
现在的网站
,
尤其某
些论坛有大量的回复和很多内容的
,
一个页面甚至有几百
K
。
默认的
fastcgi
进程响应的缓冲区
是
8K,
我们可以设置大点在
nginx.conf
里
,
加入:
fastcgi_buffers 8 128k
这表示设置
fastcgi
缓冲区为
8
×
128
当然如果您在进行某一项即时的操作
,
可能需要
nginx
的超时参数调大点,例如设置成
90
秒:
send_timeout 90;
只是调整了这两个参数
,
结果就是没有再显示那个超时
,
效果不错
Nginx
中关于与上游服务器通信超时时间的配置
factcgi_connect/read/send_timeout
。
以
Nginx
超时时间为
90
秒,
PHP-FPM
超时时间为
300
秒为例,报
504 Gateway Timeout
错误时
的
Nginx
错误访问日志如下:
2013/09/19 00:55:51 [error] 27600#0: *78877 upstream timed out (110: Connection
timed out) while reading response header from upstream,
client: 192.168.1.101, server: test.com, request: "POST /index.php HTTP/1.1",
upstream: "fastcgi://unix:/dev/shm/php-fcgi.sock:",
host: "test.com", referrer: "http://test.com/index.php"
调高这三项的值(主要是
read
和
send
两项,默认不配置的话
Nginx
会将超时时间设为
60
秒)
之后,
504
错误也解决了。
而且这三项配置可以配置在
http
、
server
级别,
也可以配置在
location
级别。
担心影响其他应
用的话,就配置在自己应用的
location
中吧。
要注意的是
factcgi_connect/read/send_timeout
是对
FastCGI
生效的,而
proxy_connect/read/send_timeout
是对
proxy_pass
生效的。
配置举例:
location ~ \.php$ {
root /home/cdai/test.com;
include fastcgi_params;
fastcgi_connect_timeout 180;
fastcgi_read_timeout 600;
fastcgi_send_timeout 600;
fastcgi_pass unix:/dev/shm/php-fcgi.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME
/home/cdai/test.com$fastcgi_script_name;
}
6
、如何使用
Nginx Proxy
朋友一台服务器运行
tomcat
为
8080
端口
,IP:192.168.1.2:8080,
另一台机器
IP:192.168.1.8.
朋友想通过访问
http://192.168.1.8
即可访问
tomcat
服务
.
配置如下
:
在
192.168.1.8
的
nginx.conf
上配置如下
:
server {
listen 80;
server_name java.linuxtone.org
location / {
proxy_pass http://192.168.1.2:8080;
include /usr/local/nginx/conf/proxy.conf;
}
}
7.
安装完成
Nginx
后无法站外访问?
刚安装好
nginx
一个常见的问题是无法站外访问,本机
wget
、
telnet
都正常。而服务器之外,
不管是局域网的其它主机还是互联网的主机都无法访问站点。如果用
telnet
的话,提示:
正在连接到
192.168.0.xxx...
不能打开到主机的连接,
在端口
80:
连接失败
如果用
wget
命令的话,提示:
Connecting to 192.168.0.100:80... failed: No route to host.
如果是以上的故障现象,
很可能是被
CentOS
的防火墙把
80
端口拦住了,
尝试执行以下命令,
打
开
80
端口:
iptables -I INPUT -p tcp --dport 80 -j ACCEPT
然后用:
/etc/init.d/iptables status
查看当前的防火墙规则,如果发现有这样一条:
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
就说明防火墙规则已经添加成功了,再在站外访问就正常了。
8
、如何关闭
Nginx
的
LOG
access_log /dev/null
error_log /dev/nul