Nginx配置二级目录/路径 映射不同的反向代理和规避IP+端口访问 |
您所在的位置：网站首页 › nginx反向代理配置多个端口 › Nginx配置二级目录/路径 映射不同的反向代理和规避IP+端口访问 |
|
当配置Nginx来映射不同的服务器 可以通过二级路径来反向代理 来解决一个外网端口实现多个服务访问。 配置如下： server { listen 80; server_name demo.domain.com; #通过访问service二级目录来访问后台 location /service/ { #DemoBackend1后面的斜杠是一个关键，没有斜杠的话就会传递service到后端节点导致404 proxy_pass http://backend1/; 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://backend2; 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 backend1 { server 192.168.1.1; server 192.168.1.2; ip_hash; } upstream backend2 { server 192.168.2.1; server 192.168.2.2; ip_hash; }
对于规避IP+端口访问，可能粗略一看，还没理解是个啥意思吧！ 其实就是现在业界流行的一种防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，此时如果我不深究，顺手可能会写出如下配置： Shell #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的要求啊！再仔细一想，你会发现如此做法会开放越来越多的端口！运维成本以及辨识度低还只是其次，咱说好的安全第一呢？ 经过思考和测试，我写出的最终配置如下： Shell #新增的IP映射配置 server { listen 80; 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 80; 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 80; 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 节点配置，为的是分享另一个小技巧：当后端节点承载了多个站点而且都是监听80端口时（比如某些小公司同一个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 技巧，一看就懂： Shell server { listen 80; 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 设置也是必须的。说白了就是在反代过程中，对后端服务器伪装（传递）了一个自定域名，让后端响应该域名预期内容。 本文分享的经验，其实比较简单，主要就是通过不同路径来反代不同的目标。估计很多大拿早就用烂了吧！不过值得注意的是，通过自定义路径反代，需要注意 proxy_pass 参数后面是否需要斜杠，避免将自定义的路径传递到后端节点，导致访问404！
|
今日新闻 |
推荐新闻 |
| CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |