现在我有一台服务器,这里叫服务器①,服务器①的80端口因为某些原因被封了,而原来指向这台服务器的域名全都失效了,只能通过服务器①的ip:端口号的方式进行访问,这样用户体验极差,所以找办法解决了一下,于是有了下面的方案。
需要两台服务器(服务器①和服务器②,服务器①是源码所在服务器),以及域名解析权限。
首先解析一个ip:端口号的访问地址,并确保能正常访问。
然后把想要恢复正常的网站解析到服务器②上,然后此服务器打开Nginx的配置,在配置的最后一行会有这么一句:
include /www/server/panel/vhost/nginx/*.conf;
我们去打开这个目录,因为他是用*进行加载的配置,所以这里建议每个网站建立一个conf文件,文件名随意,但建议和域名同步,防止混乱后期也便于维护,要配置的内容是:
upstream shx { server 服务器①的ip:端口号 weight=1; } server { listen 80; server_name 解析的域名地址; index index.html; location / { proxy_pass http://shx/; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Port $server_port; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location ~ ^/(WEB-INF)/ { deny all; } }
配置好后就可以通过域名正常访问,看上去是域名进行访问,但实际上访问的是ip:端口号。
因为此目录下所有配置是一起加载的,所以每个upstream后面的名字都要不一样,下面proxy_pass中的也要相应替换。
这个方法还有其它作用,例如某阿域名要求必须绑定自己公司的服务器,如果你绑定其他公司的服务器,会导致网站无法正常访问,也可以用这种方法,先解析到某阿自己的服务器,再指向到自己的服务器。
S:Sever服务器
C:Client
B:Browser
具有分布性的特点(前后端分离),可以随时随地进行查询、浏览等业务处理。
业务扩展简单,通过增加网页即可增加服务器功能。
维护简单方便,只需要改变网页,即可实现所有用户的同步更新。
不需要安装客户端,可以直接运行在web浏览器中。
逻辑结构比C/S多一层,处理速度较慢。
交互能力较差,不能够在子程序间自由切换。
安全性较差,许多信息容易暴露在浏览器中。
应用服务器运行数据负荷较轻。
具有较强的事务处理能力,能实现复杂的业务流程。
由于客户端与服务器直接相连,中间没有环节,因此响应速度更快。
数据的储存管理功能较为透明,这是相当于前台用户来说的,他们无需过问(也无法干涉)背后的逻辑过程。
客户端需要安装专用的客户端软件。
对客户端的操作系统一般也会有限制。
兼容性差,对于不同的开发工具有较大的局限性。
开发成本相对较高。需要一定专业水准的技术人员才能完成。