Nginx配置教程

笔记来自
配置教程一
配置教程二

配置文件

- event块
- http块
   - http全局块
   - upstream负载均衡配置
   - service块
      - location块
        - alias与root的区别
        - 多个server匹配优先级
        - location匹配规则
        - proxy_pass

alias与root的区别

• root 实际访问文件路径会拼接URL中的路径
• alias 实际访问文件路径不会拼接URL中的路径

location ^~ /sta/ {  
   alias /usr/local/nginx/html/static/;  
}
# 请求：http://test.com/sta/sta1.html
# 实际访问：/usr/local/nginx/html/static/sta1.html 文件

location ^~ /tea/ {  
   root /usr/local/nginx/html/;  
}
# 请求：http://test.com/tea/tea1.html
# 实际访问：/usr/local/nginx/html/tea/tea1.html 文件

多个server匹配优先级
在开始处理一个http请求时，nginx会取出header头中的host，与nginx.conf中每个server的server_name进行匹配，以此决定到底由哪一个server块来处理这个请求。
server_name与host匹配优先级如下：

• 完全匹配
• 通配符在前的，如*.test.com
• 在后的，如www.test.*
• 正则匹配，如~^.www.test.com$

如果都不匹配

• 优先选择listen配置项后有default或default_server的

server {
    listen      80 default_server;
    server_name example.net www.example.net;
    ...
}

• 没有default就匹配listen端口的第一个server块

location匹配规则

• = 开头表示精确匹配，如 A 中只匹配根目录结尾的请求，后面不能带任何字符串
• ^~ 开头表示 uri 以某个常规字符串开头，不是正则匹配
• ~ 开头表示区分大小写的正则匹配
• ~* 开头表示不区分大小写的正则匹配
• / 通用匹配，如果没有其它匹配，任何请求都会匹配到
• /images/ 匹配任何以 /images/ 开头的地址

location  = / {
  # 精确匹配 /，主机名后面不能带任何字符串
  [ config A ]
}

location / {
  # 因为所有的地址都以 / 开头，所以这条规则将匹配到所有请求
  # 但是正则和最长字符串会优先匹配，无其他匹配内容的时候才走到这里
  [ config B ]
}

location /documents/ {
  # 匹配任何以 /documents/ 开头的地址，匹配符合以后，还要继续往下搜索
  # 只有后面的正则表达式没有匹配到时，这一条才会采用这一条
  [ config C ]
}

location ^~ /images/ {
  # 匹配任何以 /images/ 开头的地址，匹配符合以后，停止往下搜索正则，采用这一条
  [ config D ]
}

location ~* .(gif|jpg|jpeg)$ {
  # 匹配所有以 gif、jpg 或 jpeg 结尾的请求
  # 所有请求 /images/ 下的图片会被 config D 处理，因为 ^~ 到达不了这一条正则
  [ config E ]
}

location /images/ {
  # 字符匹配到 /images/，继续往下，会发现 ^~ 存在
  [ config F ]
}

location /images/abc {
  # 最长字符匹配到 /images/abc，继续往下，会发现 ^~ 存在
  # F 与 G 的放置顺序是没有关系的
  [ config G ]
}

location ~ /images/abc/ {
  # 只有去掉 config D 才有效：先最长匹配 config G 开头的地址，继续往下搜索，匹配到这一条正则，采用
  [ config H ]
}

location ~* /js/.*/.js

location的proxy_pass 后面的url加与不加【/】的区别
没有【/】时，location /abc/def可以匹配/abc/defghi请求，也可以匹配/abc/def/ghi等
而有【/】时，location /abc/def/不能匹配/abc/defghi请求，只能匹配/abc/def/anything这样的请求

# 下面四种情况分别用http://192.168.1.4/proxy/test.html 进行访问
# 第一种：会被代理到http://127.0.0.1:81/test.html 这个url
location  /proxy/ {
   proxy_pass http://127.0.0.1:81/;
}

# 第二种,会被代理到http://127.0.0.1:81/proxy/test.html 这个url
location  /proxy/ {
   proxy_pass http://127.0.0.1:81;
}

# 第三种：会被代理到http://127.0.0.1:81/ftlynx/test.html 这个url
location  /proxy/ {
   proxy_pass http://127.0.0.1:81/ftlynx/;
}

# 第四种(相对于第三种，最后少一个 / )：会被代理到http://127.0.0.1:81/ftlynxtest.html 这个url
location  /proxy/ {
   proxy_pass http://127.0.0.1:81/ftlynx;
}

负载均衡的策略
跟server是同一级配置

• 轮询策略

// 默认情况下采用的策略，将所有客户端请求轮询分配给服务端。
// 这种策略是可以正常工作的，但是如果其中某一台服务器压力太大，出现延迟，会影响所有分配在这台服务器下的用户。
upstream balanceServer {
    server 10.1.22.33:12345;
    server 10.1.22.34:12345;
    server 10.1.22.35:12345;
}

• 最小连接数策略

// 将请求优先分配给压力较小的服务器，它可以平衡每个队列的长度，并避免向压力大的服务器添加更多的请求。
upstream balanceServer {
    least_conn;
    server 10.1.22.33:12345;
    server 10.1.22.34:12345;
    server 10.1.22.35:12345;
}

• 最快响应时间策略

// 依赖于NGINX Plus，优先分配给响应时间最短的服务器。
upstream balanceServer {
    fair;
    server 10.1.22.33:12345;
    server 10.1.22.34:12345;
    server 10.1.22.35:12345;
}

• 客户端ip绑定

// 来自同一个ip的请求永远只分配一台服务器，有效解决了动态网页存在的session共享问题。
upstream balanceServer {
    ip_hash;
    server 10.1.22.33:12345;
    server 10.1.22.34:12345;
    server 10.1.22.35:12345;
}

nginx除了反向代理，还可以作为了一个优秀的网关的存在，具体查看【Nginx使用Lua】笔记