Nginx通过二级目录(路径)映射不同的反向代理,规避IP+端口访问 | 张戈博客

  • 时间:
  • 浏览:9
  • 来源:空间引流吧_提供小刀辅助网技术_蚂蚱辅助网资讯

这是我上一家公司的案例总结,发现躺在草稿箱兩个月了,今天得空就分派发布一下。

先说一下开发那边提来的另另兩个 多多case:

①、同另另兩个 多多域名前要反向代理到前台和后台(不同机器和端口);

②、前要采用IP+端口的模式,嵌入到APP作为DNS污染后的备选方案。

对于第①个哪几种的大问题,很好正确处理:通过区分二级目录来反代不同的节点即可,只是代码类似于于如下:

server {
        listen 150;
        server_name demo.domain.com;
        #通过访问service二级目录来访问后台
	location /service/ {
            #DemoBackend1顶端的斜杠是另另兩个


多多关键,这么斜杠话语就会传递service到后端节点因为404
            proxy_pass      http://DemoBackend1/;
            proxy_redirect  off;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
        #某些路径默认访问前台网站
        location / {
            proxy_pass http://DemoBackend2;
            proxy_redirect  off;
            proxy_set_header  Host  $host;
            proxy_set_header  X-Real-IP  $remote_addr;
            proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }

#简单的负载均衡节点配置
upstream DemoBackend1 {
     server 192.168.1.1;
     server 192.168.1.2;
     ip_hash;
 }
upstream DemoBackend2 {
     server 192.168.2.1;
     server 192.168.2.2;
     ip_hash;
}

如上配置即可实现通过另另兩个 多多域名来反代不同的后端节点,用到的思路只是匹配二级目录来反代。

对于第②个哪几种的大问题,怎么让粗略一看,还没理解是个啥意思吧!

着实只是现在业界流行的五种防DNS污染的正确处理方案之一:手机APP顶端除了通过域名来获取数据,还会 额外嵌入某些备用的IP。APP在获取数据时,会先通过域名向服务器发起另另兩个 多多简单的校验请求,怎么让得到的还会 预期数据,说明该网络环境下的DNS已被污染,比如被运营商劫持,请求A内容却让人展示B内容!这只是,APP怎么让启动备用预案,通过IP的依据来请求数据!很明显,你什儿 做法可不前要有效正确处理恶心的DNS劫持了(想看 这段是还会 有所收获呢?)。

做法很简单,只是在APP中集成多个IP和端口作为备用的访问途径。

当开发GG找到我,提出的需求是:

前要实现公网IP+端口来访问,比如邮件API使用 http://192.168.1.10:125

Ps:公网服务器是多线的,这么还会 多个IP,本文假设电信是192.168.1.10,联通是192.168.2.10,移动是192.168.3.10等

说白了只是要用端口来区分不同的API,此时怎么让我不深究,顺手怎么让会写出如下配置

#API1
server {
        listen 125;
        server_name 192.168.1.10 192.168.2.10 192.168.3.10;
        location / {
            proxy_pass      http://DemoBackend;
            proxy_redirect  off;
            proxy_set_header   Host  api1.domain.com;
            proxy_set_header   X-Real-IP   $remote_addr;
            proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        }
}
#API2
server {
        listen 126;
        server_name 192.168.1.1 192.168.2.1 192.168.3.1;
        location / {
            proxy_pass      http://DemoBackend;
            proxy_redirect  off;
            proxy_set_header   Host  api2.domain.com;
            proxy_set_header   X-Real-IP   $remote_addr;
            proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        }
}
##API n等等....

粗略一看,着实是可不前要实现开发GG的要求啊!再仔细一想,让人发现这么做法会开放越多的端口!运维成本以及辨识度低还只是其次,咱说好的安全第一呢?

经过思考和测试,我写出的最终配置如下:

#新增的IP映射配置
server {
        listen 150;
        server_name 192.168.1.10 192.168.2.10 192.168.3.10;
        location /mail_api/ {
            proxy_pass      http://DemoBackend/; #顶端的斜杠必须少,作用是不往后端传递/mail-api 你什儿




路径
            proxy_redirect  off;
            proxy_set_header  Host  mailapi.domain.com; #传递不同的host给后方节点,实现IP和域名均可不前要访问
            proxy_set_header  X-Real-IP  $remote_addr;
            proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
        }
        location /other_api1/ {
            proxy_pass      http://DemoBackend/; 
            proxy_redirect  off;
            proxy_set_header  Host  otherapi1.domain.com;
            proxy_set_header  X-Real-IP  $remote_addr;
            proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
        }
        #还可不前要加进去去更多映射,通过不同的路径来映射不同的API,最后对于直接访问IP则返回403,防网络上的扫码探测
	location / {
	    return 403;
	}
}

#原有的域名映射
server {
     listen 150;
     server_name mailapi.domain.com;
     location / {
	    proxy_pass      http://DemoBackend;
            proxy_redirect  off;
            proxy_set_header  Host  $host;
            proxy_set_header  X-Real-IP  $remote_addr;
            proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
	}
}
server {
     listen 150;
     server_name otherapi1.domain.com;
     location / {
	    proxy_pass      http://DemoBackend;
            proxy_redirect  off;
            proxy_set_header  Host  $host;
            proxy_set_header  X-Real-IP  $remote_addr;
            proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
	}
}
#简单的节点配置(当哪几种API都用到同另另兩个


多多Backend时,上述代码中的proxy_set_header传递的host就起到了关键性作用!)
upstream DemoBackend {
     server 192.168.10.1;
     server 192.168.10.2;
     ip_hash;
 }

最终实现的效果只是:我前要通过IP请求邮件API,怎么让请求 http://192.168.1.1/mail_api/ 即可,而不前要开放多余端口。怎么让,后续要新增更多API,只前要定义不同的二级路径即可,哪几种二级路径的辨识度可比端口要好得多!

Ps:正如代码中的注释,示例代码只用了另另兩个 多多 DemoBackend 节点配置,为的是分享另另兩个 多多多小技巧:当后端节点承载了多个站点怎么让还会 监听150端口时(比如某些小公司同另另兩个 多多IIS服务器部署了N个站点),反向代理中的proxy_set_header参数,可不前要自定义传递另另兩个 多多host域名给后端节点,从而正确响应预期内容!

这段解释有点痛 无力,还是拿实际例子举例吧!

我只是供职的公司节点用的是IIS服务器,前端用Nginx反向代理,IIS服务器上有多个站点,站点之间部分会通过 rewrite 规则联系起来。

打个比方:比如A网站有个专题内容(www.a.com/zt/)是通过IIS伪静态映射到了B网站(content.b.com)。也只是访问到http://www.a.com/zt/,着实最后是通过A网站映射到了B网站顶端。

只是发现IIS有个伪静态BUG,会经常 奔溃,就我想要用前端的Nginx来实现直接映射,而不再走IIS的A网站中转。

这么你什儿 需求就正好用到了 proxy_set_header 技巧,一看就懂:

server {
     listen 150;
     server_name www.a.com;
     location /zt/ {
	    proxy_pass      http://ABackend; #还会

相同的节点,此示例代码让人不写upstream了
            proxy_redirect  off;
            proxy_set_header  Host www.b.com; #这里只是关键性作用,传递b域名给后端IIS
            proxy_set_header  X-Real-IP  $remote_addr;
            proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
	}
}

#upstream略..

很明显,通过传递自定义域名,就可不前要实现通过A网站访问Nginx,返回B网站内容,和反向代理谷歌的原理是一致的。

当然,上文为了实现 IP 和域名都可不前要访问,你什儿 proxy_set_header 设置也是前要的。说白了只是在反代过程中,对后端服务器伪装(传递)了另另兩个 多多自定域名,让后端响应该域名预期内容。

当然,在只是张戈博客分享的《分享十几个 WordPress本地缓存gravatar评论头像的方案》一文中也用到了你什儿 技巧,感兴趣的亲戚亲戚你们可只是往查看。

本文分享的经验,着实比较简单,主要只是通过不同路径来反代不同的目标。估计只是大拿早就用烂了吧!不过值得注意的是,通过自定义路径反代,前要注意 proxy_pass 参数顶端否有前要斜杠,正确处理将自定义的路径传递到后端节点,因为访问404!