本人小白记录下Nginx的一些简单说明防止忘了

---

实现反向代理

最简单的一个配置：

server { listen 80; #监听端口 server_name www.abc.com; #同监听域名，只有一个无所谓 location / { proxy_pass http://127.0.0。1:8080; #重定向到另一个的地址 } }

location用于匹配后缀 有几种匹配方式 ：

来自http://blog.csdn.net/chlinwei/article/details/67631830 详细的戳进去看

location = / { # 精确匹配 / ，主机名后面不能带任何字符串 [ configuration A ] } location / { # 因为所有的地址都以 / 开头，所以这条规则将匹配到所有请求 # 但是正则和最长字符串会优先匹配 [ configuration B ] } location /documents/ { # 匹配任何以 /documents/ 开头的地址，匹配符合以后，还要继续往下搜索 # 只有后面的正则表达式没有匹配到时，这一条才会采用这一条 [ configuration C ] } location ~ /documents/Abc { # 匹配任何以 /documents/ 开头的地址，匹配符合以后，还要继续往下搜索 # 只有后面的正则表达式没有匹配到时，这一条才会采用这一条 [ configuration CC ] } location ^~ /images/ { # 匹配任何以 /images/ 开头的地址，匹配符合以后，停止往下搜索正则，采用这一条。 [ configuration D ] } location ~* .(gif|jpg|jpeg)$ { # 匹配所有以 gif,jpg或jpeg 结尾的请求 # 然而，所有请求 /images/ 下的图片会被 config D 处理，因为 ^~ 到达不了这一条正则 [ configuration E ] } location /images/ { # 字符匹配到 /images/，继续往下，会发现 ^~ 存在 [ configuration F ] } location /images/abc { # 最长字符匹配到 /images/abc，继续往下，会发现 ^~ 存在 # F与G的放置顺序是没有关系的 [ configuration G ] } location ~ /images/abc/ { # 只有去掉 config D 才有效：先最长匹配 config G 开头的地址，继续往下搜索，匹配到这一条正则，采用 [ configuration H ] }

关于proxy_pass后的url加不加/的区别

来自http://blog.csdn.net/haitun312366/article/details/38521847

下面四种情况分别用http://192.168.1.4/proxy/test.html 进行访问。 第一种： location /proxy/ { proxy_pass http://127.0.0.1:81/; } 会被代理到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/ftlynx/; } 会被代理到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

配置轮询

　upstream 域名 ｛ 　　　　server IP地址； 　　｝

　server ｛ 　　　location / { 　　　　　proxy_pass http://域名； 　　　} 　} 　有几种轮询方式，暂没怎么研究 轮询(weight=1)默认选项，当weight不指定时，各服务器weight相同， 每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。

upstream bakend { server 192.168.1.10; server 192.168.1.11; }

fair轮询（第三方插件）: 按照响应时间进行分配请求，响应时间短，即rt小的后端服务器优先分配请求；

upstream resinserver{ server 192.168.1.10:8080; server 192.168.1.11:8080; fair; }

ip_hash 轮询：每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session不能跨服务器的问题。

upstream resinserver{ ip_hash; server 192.168.1.10:8080; server 192.168.1.11:8080; }

weight 指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。 如果后端服务器down掉，能自动剔除。

upstream bakend { server 192.168.1.10 weight=1; server 192.168.1.11 weight=2; }

url_hash（第三方插件） 按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存服务器时比较有效。 在upstream中加入hash语句，hash_method是使用的hash算法

upstream resinserver{ server 192.168.1.10:8080; server 192.168.1.11:8080; hash $request_uri; hash_method crc32; }

tips：有时访问不了可能端口没开放试试： /sbin/iptables -I INPUT -p tcp –dport 80 -j ACCEPT