本篇介绍比较基础的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 http://demo.cloudxue.com/download/1/video/10

#rewrite模块进行匹配后，占位变量$1的值为1， $2的值为10
uri: /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：返回响应的重定向状态码和重定向URL
return code URL;

#格式3：返回响应的重定向URL，默认的返回状态码是临时重定向302
return 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	http://zuul/;
}

• 指令的执行顺序：与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 http://cloudxue.com/sequence_demo 
#响应
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 http://127.0.0.1:8080/;
			}
  
  		#带location前缀的代理类型
  		location /foo_prefix {
  			proxy_pass http://127.0.0.1:8080;
  		}
  
  		#带部分URI路径的代理
  		location /foo_uri_1 {
  			proxy_pass http://127.0.0.1:8080/contextA/;
  		}
  
  		#带部分URI路径的代理
  		location /foo_uri_2 {
  			proxy_pass http://127.0.0.1:8080/context-A;
  		}
		}
	
}

测试结果如下

?  ~ curl http://127.0.0.1/foo_no_prefix/bar.html
-uri=/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 http://127.0.0.1/foo_prefix/bar.html 
-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 http://127.0.0.1/foo_uri_1/bar.html
-uri=/contextA/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 http://127.0.0.1/foo_uri_2/bar.html
-uri=/context-A/bar.html -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 http://127.0.0.1:8080;
  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;
}