标签 nginx 下的文章

nginx反向代理到Https后,请求Http资源报错blocked mixed-content

转载自Honins的CSDN博客
解决https请求http资源不可用的情况

第一种方法:

  <link rel="stylesheet" href="http://cdn.bootcss.com/bootstrap/3.3.5/css/bootstrap.min.css">

比如这里我用了bootcss的cdn,但是正常情况下这样写是会报blocked mixed-content错误的。

解决方法:

 <link rel="stylesheet" href="//cdn.bootcss.com/bootstrap/3.3.5/css/bootstrap.min.css">

这样的话浏览器就会根据你域名的请求来识别,比如https下他会自动请求https的资源,而http时,请求http的资源。
但是有可能他并不存在https的资源,但是我又想在Https下用这个cdn怎么办呢?

第二种方法:

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

这样他会在请求Http资源的时候先将他转成Https再请求。

第三种方法:

可以在nginx里面解决
在nginx可通过在server添加

add_header Content-Security-Policy upgrade-insecure-requests;

解决

Nginx的虚拟主机配置

前几天提到,我需要把家里的树莓派、cubieboard等小功耗设备映射到公网,同时解决80被封的问题,那么随之而来的就是域名解析。
不想折腾原有的几个域名(其实是害怕被封),于是就买了一个搬瓦工64M的VPS+申请了几个免费的.tk域名

于是问题就来了,情况是这样的,我申请了aaa.tk和bbb.tk等域名,然后只是想把家里的树莓派解析为pi.aaa.tk,cubieboard解析为cb3.bbb.tk,理论上来说,我写一个新的配置文件,扔到/etc/nginx/sites-available里,然后ln -s 到/etc/nginx/sites-enabled 里即可。

实际操作过程中,发现虽然使用pi.aaa.tk、cb3.bbb.tk两个二级域名访问的目标电脑是OK的,但是www.aaa.tk和www.bbb.tk等等二级域名也都指向了cb3,这样肯定是不对的

第一次尝试:
在默认host的配置文件中将www.aaa.tk、www.bbb.tk加入server_name后面,重启nginx后生效。
问题:我用的是泛域名解析,直接把.aaa.tk和.bbb.tk解析到了vps上,也就是说,随便用aaa.aaa.tk也能解析到vps,而默认host的配置文件中又没有该域名对应server_name,所以访问又被解析到cb3上。


第二次尝试:
pi.aaa.tk和cb3.bbb.tk的host文件还是照样写。
但是在期望是默认host的配置文件中如下填写:

server {
        listen   80 default_server; 
        listen   [::]:80 default_server ipv6only=on; 

        【此处省略若干行】

        server_name   _;

        location / {
          【以下省略若干行】

即,在listen的ip和端口后方增加default_server,同时在server_name部分以 _ 来描述。
保存退出,重启nginx,问题解决。

LVS、Nginx、HAproxy转发模式总结

LVS、Nginx、HAproxy是最常见的三种高可用性负载均衡软件。由于lvs和haproxy在目前的公司的现网环境中并未用到,虽然之前简单的了解和搭建过,现在也已经忘的差不多了,而及于nginx的负载均衡虽然公司在用,不过一配置文件都是ctrl+c、ctrl+v,对转发的理论性的东西也都忘的差不多了。隐约脑子里现在只有upstream、dr 、ip_hash这几个词了。现对三者的转发方式做下总结。
一、LVS转发模式
LVS是章文嵩博士写的一个工作于四层的高可能性软件。不像后两者支持七层转发,不过也正因为其简单,所以其是最稳定的。其共有三种IP负载均衡技术:VS/NAT(Virtual Server via Network Address Translation)、VS/TUN(Virtual Server via IP Tunneling)和VS/DR(Direct Routing),三者之间具体的比较见下表:
lvs.jpg

二、Nginx负载模式

nginx有五种负载算法模式,分别是:轮询、weight(权重)、ip_hash、fair、url_hash 。现逐一说明:

轮询(默认): 每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除。
weight :指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的情况。配置为:

    upstream bakend {
    server 192.168.0.14 weight=10;
    server 192.168.0.15 weight=10;
    } 

ip_hash:每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题。配置为:

    upstream bakend {
    ip_hash;
    server 192.168.0.14:88;
    server 192.168.0.15:80;
    } 

fair:按后端服务器的响应时间来分配请求,响应时间短的优先分配。

    upstream backend {
    server server1;
    server server2;
    fair;
    } 

url_hash:按访问url的hash结果来分配请求,使每个url定向到同一个后端服务器,后端服务器为缓存时比较有效。配置如:

    upstream backend {
    server squid1:3128;
    server squid2:3128;
    hash $request_uri;
    hash_method crc32;
    }

注:第五种模式下,需要注意在upstream中加入hash语句,server语句中不能写入weight等其他的参数,hash_method是使用的hash算法 。

server后面常接的参数有如下几个:

down 表示单前的server暂时不参与负载 
weight 默认为1.weight越大,负载的权重就越大。 
max_fails :允许请求失败的次数默认为1.当超过最大次数时,返回proxy_next_upstream 模块定义的错误 
fail_timeout:max_fails次失败后,暂停的时间。 
backup: 其它所有的非backup机器down或者忙的时候,请求backup机器。所以这台机器压力会最轻。

三、HAproxy

haproxy是三者之间负载算法最多的,有八种,所以其应用场景也是最多,配置也是最灵活的,具体8种算法为:

 ①roundrobin,表示简单的轮询,这个是负载均衡基本都具备的; 

②static-rr,表示根据权重,和nginx的weight算法类似; 

③leastconn,表示最少连接者先处理,有点类似于nginx的fair,不过fair是根据响应时间; 

④source,表示根据请求源IP,这个跟Nginx的IP_hash机制类似,我们用其作为解决session问题的一种方法,建议关注; 

⑤ri,表示根据请求的URI,类似于nginx的url_hash; 

⑥rl_param,表示根据请求的URl参数'balance url_param' requires an URL parameter name; 

⑦hdr(name),表示根据HTTP请求头来锁定每一次HTTP请求; 

⑧rdp-cookie(name),表示根据据cookie(name)来锁定并哈希每一次TCP请求

四、总结

具体现网应用可以根据据体的实际情况选择最好的负载方式。三者中,LVS稳定性最好,可配置性最少;Nginx针对域名、目录结构进行正则匹配是最强的,同时其对网络依赖比较小,不过性能上和LVS和HAproxy相比稍差一点点;HAproxy支持虚拟主机,尤其在session保持方面做的最好,其有三种算法可以实现session共享———— IP识别(source)、cookie识别、session识别三种,除此之外在对mysql做HA方案时也经常会用到该软件。

Nginx配置路径转发至Tomcat

在公司领了几台台式机来做测试服务器,但是这么多台比较难管理,于是把几台PC换成了一台,增加了一些硬件资源,将各种测试环境整合起来,通过Nginx的路径转发来控制请求路径。
Nginx的转发规则如下(片段,tomcat6、tomcat7、tomcat8分别在本机的不同端口):

    location ^~ /tomcat/6/ {
        proxy_pass   http://127.0.0.1:8686/;
        proxy_redirect off;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
    location ^~ /tomcat/7/ {
        proxy_pass   http://127.0.0.1:8787/;
        proxy_redirect off;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
    location ^~ /tomcat/8/ {
        proxy_pass   http://127.0.0.1:8888/;
        proxy_redirect off;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

这样,通过访问http://xxx.xxx.xxx.xxx/tomcat/6/ 就可以直接转发到127.0.0.1的8686端口了,方便做测试。
另外^~ /tomcat/6/代表匹配URL以/tomcat/6/开头,需要计算大小写。

语法规则: location [=|~|~*|^~] /uri/ { … }
= 开头表示精确匹配

^~ 开头表示uri以某个常规字符串开头,理解为匹配 url路径即可。nginx不对url做编码,因此请求为/static/20%/aa,可以被规则^~ /static/ /aa匹配到(注意是空格)。
~ 开头表示区分大小写的正则匹配
~* 开头表示不区分大小写的正则匹配
!~和!~*分别为区分大小写不匹配及不区分大小写不匹配 的正则
/ 通用匹配,任何请求都会匹配到。

对于Openfire或者Oracle,则需要用以下的代码片段来进行配置:

worker_processes  1;
events {
    worker_connections  1024;
}
tcp {
        upstream openfire {
                server 192.168.0.1:5222;
                server 192.168.0.2:5222;
                check interval=3000 rise=2 fall=5 timeout=1000;
        }
        server {
                listen 5222;
                proxy_pass openfire;
        }
}