本篇介绍比较基础的Nginx常用命令及配置。

启动、检查、重启及关闭命令

#假设Nginx的安装目录为/home/nginx/nginx/#启动命令/home/nginx/nginx/sbin/nginx -c /home/nginx/nginx/conf/nginx.conf#状态检查/home/nginx/nginx/sbin/nginx -t#重新加载配置/home/nginx/nginx/sbin/nginx -s reload#关闭#查询nginx主进程号 ps -ef | grep nginx#从容停止   kill -QUIT 主进程号#快速停止   kill -TERM 主进程号#强制停止   kill -9 主进程号#若nginx.conf配置了pid文件路径，如果没有，则在logs目录下kill -信号类型 '/usr/local/nginx/logs/nginx.pid'

基础配置

events事件驱动配置

use指令worker_connections指令accept_mutex指令

events {	use epoll;										#使用epoll类型的IO多路复用模型，性能比select高  worker_connections 204800;		#Worker进程能够打开的最大并发连接数  accept_mutex on;							#各个Worker进程通过锁来获取新连接}

server虚拟主机配置

server {	listen	80;  server_name admin.cloudxue.com;		#后台管理服务的域名前缀  location / {  	default_type 'text/html';    charset utf-8;    echo "this is admin server";  }}server {	listen	80;  server_name file.cloudxue.com;		#文件服务的域名前缀  location / {  	default_type 'text/html';    charset utf-8;    echo "this is file server";  }}server {	listen	80 default;  server_name cloudxue.com *.cloudxue.com;		#若未指定前缀，配置默认访问的虚拟主机  location / {  	default_type 'text/html';    charset utf-8;    echo "this is default server";  }}

多个虚拟主机之间根绝server_name匹配的优先级从高到低：

精确匹配左侧通配符匹配右侧通配符匹配正则表达式匹配defalt_server：在listen指令后面如果带有default指令参数，表示默认的、最后兜底的虚拟主机。

错误页面配置

error_page指令，该指令可用于http、server、location、if in location等上下文。

server {	listen			80;  server_name admin.cloudxue.com;		#后台管理服务的域名前缀  root 				/usr/local/openresty/www;    location / {  	default_type 'text/html';    charset utf-8;    echo "this is admin server";  }    #设置错误页面  #error_page 404 /404.html;  error_page 404 =200 /404.html			#防止404页面被劫持  error_page 500 502 503 504 /50x.html;}

长链接配置

keepalive_timeout	75;				#长链接有效时长，0表示禁用长链接，默认75秒keepalive_requests	100;		#一条长链接上允许被请求的资源的最大数量，默认100

访问日志配置

access_log path [format [buffer=size] [gzip[=level]] [flush=time] [if=condition]];

http {  #先定义日志格式，名为为	log_format  format_main  '$remote_addr - $remote_user [$time_local] "$request" '                     '$status $body_bytes_sent "$http_referer" '                     '"$http_user_agent" "$http_x_forwarded_for"';  #日志文件、日志访问格式  access_log	logs/access_main.log format_main;}

location路由规则配置

精确匹配：标记符号为"="普通匹配：标记符号为"^~"。是Nginx默认的匹配类型，标记符号可以省略。如果一个URL命中多个普通匹配，则最长的location普通匹配获胜。正则匹配：标记符号为"~"、 "~*"、 "!~"、 "!~*"。若配置文件中有多个正则匹配location，只要匹配到第一个正则类型的location就停止匹配。正则匹配与location规则定义在配置文件中的先后顺序强相关。默认匹配：标记符号为"/"。通常用来配置默认静态页（index.html）。

rewrite模块指令配置

Nginx的rewrite模块即ngx_http_rewrite_module标准模块，默认安装的模块。主要功能是对URI进行重写，然后再一次进行location匹配或者直接进行30X重定向返回给客户端。

set指令：用于向变量赋值。当变量存在时就赋值，不存在时，先创建再赋值。创建后的可见范围为Nginx整个配置

set	$variable	value#实例set	$a "foo";set $b "$a, $a";

rewrite指令：主要功能是重写URI。

rewrite regrex replacement [flag];#实例location /download/ {	rewrite ^/download/(.*)/video/(.*)$	/view/$1/mp3/$2.mp3/	last;  rewrite ^/download/(.*)/audio/(.*)$	/view/$1/mp3/$2.rmvb/	last;  return 404;}location /view {	echo "uri: $uri ";}#访问如下地址curl 模块进行匹配后，占位变量$1的值为1， $2的值为10uri: /view/1/mp3/10.mp3

如果同一个上下文中出现多个rewrite指令，匹配会按照rewrite指令出现的顺序先后依次进行下去，匹配成功后并不会终止，而是继续往下匹配，知道返回最后一个匹配为止。可以通过指令参数flag控制是否中途停止匹配，假设在location上下文中：

last：停止rewrite匹配，使用当前计算后的新URI进行location匹配和跳转。break：停止rewrite匹配，但是不进行location跳转。redirect：外部重定向，返回302响应码permanent：服务器将新URI地址返回给客户端浏览器，并返回301响应码给客户端，客户端使用新地址再发一次请求（地址栏会变）

注意事项:

last和break的区别仅仅发生在location上下文中，如果发生在server上下文，那么last和break的作用是一样的。location上下文中的rewrite指令使用last指令参数会再次以新的URI重新发起内部重定向，再次进行location匹配，而新的URI若和旧的URI一样，会发生死循环。当循环发生到第10次时，Nginx会终止这样无意义的循环，并返回500错误。if指令：相当于引入了一个新的上下文作用于，适用于server、location两个上下文。

if (condition) {...}#实例location /if_demo {  if ($http_user_agent ~*"Firefox") { 	#匹配Firefox浏览器  	return 403;  }  if ($http_user_agent ~*"Chrome") { 	  #匹配Chrome浏览器  	return 301;  }  if ($http_user_agent ~*"iphone") { 	  #匹配iPhone手机  	return 302;  }  if ($http_user_agent ~*"android") { 	#匹配安卓手机  	return 404;  }  return 405;														#其他浏览器默认规则}

return指令：可用于server、location、if上下文中，执行阶段是rewrite阶段。

#格式1：返回响应的状态码和提示文字，提示文字可选return code [text];#格式2：返回响应的重定向状态码和重定向URLreturn code URL;#格式3：返回响应的重定向URL，默认的返回状态码是临时重定向302return URL;

add_header指令：设置返回客户端的响应。

使用Ajax进行跨域请求时，浏览器会向跨域资源的服务端发送一个OPTION请求，用于判断实际请求是否安全或者判断服务端是否允许跨域访问，这种请求也叫预检请求。跨域访问的预检请求是浏览器自动发出的，用户程序不知情，如果不进行特殊的配置，那么客户端发出一次请求，在服务端会收到两个请求：一个是预检请求，一个是正式的请求。会比较影响性能，通常Nginx代理服务器对预检请求进行拦截，同时对预检请求设置比较长时间的有效期。

add_header Cache-Control no-store;add_header Content-Encoding gzip;add_header Content-Type 'text/html; charset=utf-8';#实例upstream zuul {	server "192.168.233.122:7799";  keepalive 1000;}server {	listen      80;  server_name	nginx.server *.nginx.server;  default_type 'text/html';  charset utf-8;    #转发到上游服务器，但是‘OPTIONS’请求直接返回空  location / {  	add_header	Access-Control-Max-Age 1728000;		#指定本次预检请求的有效期，单位秒，允许缓存该条回应20天，此期间内客户端不用发出另一条预检请求    add_header	Access-Control-Allow-Origin	*;    add_header	Access-Control-Allow-Credentials	true;    add_header	Access-Control-Allow-Methods	'GET, POST, OPTIONS';    add_header	Access-Control-Allow-Headers	'Keep-Alive, User-Agent, X-Requested-With, \      If-Modified-Since, Cache-Control, COntent-Type,token';    return 204;  }  proxy_pass	;}

指令的执行顺序：与Nginx的请求处理的11各阶段有密切关系。其中3个比较常见的按照执行时的先后顺序依次是rewrite阶段、access阶段、content阶段。Nginx的配置指令一般只会注册并运行在其中的某一个处理阶段，比如set指令就是在rewrite阶段运行的，而echo指令只会在content阶段运行，在一次请求处理流程中，rewrite阶段总是在content阶段之前执行。

location /sequence_demo {	set $a foo;  echo $a;    set $a bar;  echo $a;}#访问测试：curl  #响应bar bar#若按照请求处理阶段的先后次序排序location /sequence_demo {	#rewrite 阶段的配置指令，执行在前面  set $a foo;  set $a bar;    #content阶段的配置指令，执行在后面  echo $a;  echo $a;}#所以以上输出为 bar bar

反向代理与负载均衡配置

proxy_pass反向代理指令

位于ngx_http_proxy_module模块，注册在HTTP请求11个阶段的content阶段。

不带location前缀的代理：proxy_pass指令后面的目标URL格式为："协议" + "IP[:PORT]" + "/"，最终的代理URL不带location前缀。带location前缀的代理：proxy_pass指令后面的目标URL格式未："协议" + "IP[:PORT]" ，最终的代理URL带有location前缀。带部分URI路径的代理：最终的代理URL为配置项中的目标URL前缀+请求URI中去掉location中前缀的剩余部分。

worker_processes  1;error_log logs/error.log;events {    worker_connections 1024;}http {    server {			listen 8080;  		server_name localhost;  		default_type 'text/html';  		charset utf-8;  		location / {  			echo "-uri=$uri"         		 "-host=$host"      	 		 "-remote= $remote_addr"         		 "-proxy_add_x_forwarded= $proxy_add_x_forwarded_for"         		 "-http_x_forwarded_for= $http_x_forwarded_for";        }  	}  	  	server {		  listen 80;  		server_name localhost;  		default_type 'text/html';  		charset utf-8;    		location / {  			echo "默认根路径匹配:/";  		}    		#不带location前缀的代理类型			location /foo_no_prefix {				proxy_pass ;			}    		#带location前缀的代理类型  		location /foo_prefix {  			proxy_pass ;  		}    		#带部分URI路径的代理  		location /foo_uri_1 {  			proxy_pass ;  		}    		#带部分URI路径的代理  		location /foo_uri_2 {  			proxy_pass ;  		}		}	}

测试结果如下

➜  ~ curl  -host=127.0.0.1 -remote= 127.0.0.1 -proxy_add_x_forwarded= 127.0.0.1 -http_x_forwarded_for= ➜  ~ curl  -uri=/foo_prefix/bar.html -host=127.0.0.1 -remote= 127.0.0.1 -proxy_add_x_forwarded= 127.0.0.1 -http_x_forwarded_for= ➜  ~ curl  -host=127.0.0.1 -remote= 127.0.0.1 -proxy_add_x_forwarded= 127.0.0.1 -http_x_forwarded_for= ➜  ~ curl  -host=127.0.0.1 -remote= 127.0.0.1 -proxy_add_x_forwarded= 127.0.0.1 -http_x_forwarded_for= ➜  ~ 

proxy_set_header请求头设置指令

在反向代理前，proxy_set_header指令能重新定义添加字段传递给代理服务的请求头。请求头的值可以包含文本、变量和它们的组合，格式如下

proxy_set_header head_field field_value;

该指令在发生反向代理之前，将保持在内置变量$remote_addr中的真实客户端地址保持到请求头中，通常请求头参数名为X-real-ip。

在Java端可以使用request.getHeader("X-real-ip")获取请求头的值，就可以拿到客户的真实IP。

由于在整个请求处理链条上可能不仅一次反向代理，可能会经过N次反向代理，为了获取整个转发记录，可以使用$proxy_add_x_forwarded_for内置变量，该值的第一个就是真实地址

为了不丢失信息，反向代理的设置如下：

location /hello {	proxy_pass ;  proxy_set_header Host $host;  proxy_set_header X-real-ip $remote_addr;  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  proxy_redirect off; #修改从上游被代理服务器传来的应答头中的Location和Refresh字段}

以上配置，设置了Host、X-real-ip、X-Forwarded-For，分别将当前的目标主机、客户端IP、转发记录保存在请求头中。

当上游服务器返回的响应码是重定向301或者刷新302请求时，proxy_redirect指令可以重设HTTP头部的location或refresh字段值，off参数表示禁止所有的proxy_redirect指令，即反向代理时，禁止重定向。

upstream上有服务器组

作为Nginx的一大特色，若没有负载均衡，只有反向代理，那么其使用价值会大打折扣。Nginx在配置反向代理时，可以通过负载均衡机制配置一个上有服务器组。当组内某台机器宕机时，仍能维持系统可用，从而实现高可用。

Nginx的负载均衡配置主要用到upstream指令，其格式为：

upstream name {	server name address [parameters];}#上下文为http配置快，内部使用server指令定义组内的上游候选服务器

配置示例：

upstream zuul {  #名为upstream_zuul的共享内存区，大小为64k	zone upstream_zuul 64k;  #组内该机器的权重为5，最大并发连接数为500  server "192.168.223.121:7799" weight=5 max_conns=500;  #组内该机器的默认权重为1，同时设置20秒内失败2次，判定该服务器不可用  server "192.168.233.122:7799" fail_timeout=20s max_fails=2;  #后备服务  server "192.168.233.123:7799" backup;}

upstream的负载分配方式

加权轮询：默认负载方式，组内各服务器的权重默认为1，且上游各服务器的weight值相同，表示每个请求按到达的先后顺序逐一分配到不同的上游服务器，若果某个上游服务器宕机，就自动剔除。hash指令：基于hash函数值进行负载均衡，hash函数的key可以包含文本、变量或二者的组合。是一个独立的指令，通常与consistent参数搭配使用，避免组中某台机器宕机后，原来的大多数key可能会寻址到不同的server上。使用consistent参数，则hash一致性将选择Ketama算法，从而只有少数key会重新映射到其他server上，即大多数key不受server宕机的影响，还走原来的server，这对高缓存server命中率有很大帮助。配置示例如下：

upstream backend {  #通过请求的$request_uri的hash值进行负载均衡	hash $request_uri	consistent;  server 192.168.233.121;  server 192.168.233.122;  server 192.168.233.123;}

ip_hash指令：基于客户端的IP的hash值进行负载均衡，这样每个客户端固定访问同一个后端服务器，可以解决类似session不能跨服务器的问题。如果上游server不可用，就需要手工摘除或者配置down参数。是一个独立的指令。配置示例如下：

upstream backend {	ip_hash;  server 192.168.233.121;  server 192.168.233.122;  server 192.168.233.123;}