背景
前几天在学习负载均衡的知识，遇到了 Nginx 反向代理 的概念，其实在年初就写过一次 Nginx 反向实例的笔记，今天翻看发现很是潦草，而且当时的编辑器也不满足Markdown，作为尴尬症晚期的我，索性删掉重新整理一篇 ...
【一】概念解释
- 代理
代理其实就是一个中介，A 和 B 本来可以直连，中间插入一个 C，C 就是中介。
- 正向代理
刚开始的时候，代理多数是帮助内网 client 访问外网 server 用的（比如HTTP代理），从内到外。
- 反向代理（Reverse Proxy）
- "反向"这个词在这儿的意思其实是指方向相反
- 以代理服务器来接受Internet上的连接请求，然后将请求转发给内部网络上的服务器；并将从服务器上得到的结果返回给Internet上请求连接的客户端
- 此时代理服务器对外就表现为一个服务器
- 当一个代理服务器能够代理外部网络上的主机，访问内部网络时，这种代理服务的方式称为反向代理服务。
- 图像解释 【ps : 来源 知乎】
知乎用户解释图
- 正向代理中，Proxy 和 Client 同属一个 LAN，对 Server 透明；
- 反向代理中，Proxy 和 Server 同属一个 LAN，对 Client 透明。
- 实际上 Proxy 在两种代理中做的事都是代为收发请求和响应，不过从结构上来看正好左右互换了下，所以把后出现的那种代理方式叫成了反向代理。
- 形象图【ps : 来源 知乎】
形象图示
- 总结
正向代理隐藏真实客户端，反向代理隐藏真实服务端
正向代理，代理的对象是客户端；反向代理，代理的对象是服务端
【二】反向代理的应用/好处
- 反向代理的应用：
现在许多大型 web 网站都用到反向代理。
除了可以防止外网对内网服务器的恶性攻击、缓存以减少服务器的压力和访问安全控制之外，还可以进行负载均衡，将用户请求分配给多个服务器
- 反向代理的好处：
(1). 解决了网站服务器对外可见的问题；
(2). 节约了有限的 IP 地址资源，企业内所有的网站共享一个在 internet 中注册的 IP 地址，这些服务器分配私有地址，采用虚拟主机的方式对外提供服务；
(3). 保护了真实的 web 服务器，web 服务器对外不可见，外网只能看到反向代理服务器，而反向代理服务器上并没有真实数据，因此，保证了 web 服务器的资源安全；
(4). 加速了对网站访问速度，减轻 web 服务器的负担，反向代理具有缓存网页的功能，如果用户需要的内容在缓存中，则可以直接从代理服务其中获取，减轻了 web 服务器的负荷，同时也加快了用户的访问速度。
(5).可以实现安全过滤，流控，防 DDOS 等一系列策略
【三】反向代理的实现
- 1）需要有一个负载均衡设备来分发用户请求，将用户请求分发到空闲的服务器上
- 2）服务器返回自己的服务到负载均衡设备
- 3）负载均衡将服务器的服务返回用户
以上的潜台词是：用户和负载均衡设备直接通信，也意味着用户做服务器域名解析时，解析得到的 IP 其实是负载均衡的 IP，而不是服务器的 IP，这样有一个好处是，当新加入/移走服务器时，仅仅需要修改负载均衡的服务器列表，而不会影响现有的服务。（来自：知乎）
【四】Nginx 反向代理 操作
1). nginx 反向代理 参考配置代码
#设定负载均衡的服务器列表
#weigth参数表示权值，权值越高被分配到的几率越大
upstream Mos{
server 192.168.1.106:80 weight=3;
server 192.168.1.143:80 weight=1;
#server localhost:80 weight=1; #本机
}
server {
listen 80;
server_name localhost;
index index.html index.htm index.php;
root /mnt/web/hyicnoa;
location / {
if (!-e $request_filename){
rewrite ^/(.*)$ /index.php?s=/$1 last;
}
proxy_pass http://Mos ; #在这里设置一个代理，和upstream的名字一样
}
location ~ .*\.(php|php5)?$
{
#fastcgi_pass unix:/tmp/php-cgi.sock;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fastcgi.conf;
}
location ~ \.php$
{
proxy_pass http://192.168.1.106; #此处限制访问 php 文件时，跳转到192.168.1.106 服务器解析
}
location ~ .*\.(js|css)?$
{
expires 1h;
}
}
2).提示
- 上述配置文件内容仅供参考，信息并未显示完全
- 强烈建议不要直接修改 nginx.conf 文件，一般是根据类似如下的代码
include /etc/nginx/conf.d/*.conf;进行对应目录下新建文件的配置，以避免较大的配置影响.- "proxy_pass http://xxxxxx" 作为代理的位置，需要明确自己在哪种条件下进行代理的使用，具体实践需要参考 nginx 配置语法，着重在于正则表达的限制条件
3). 注意信息
- （1）. 服务器列表仅做参考，以本次操作为例，代理机为
192.168.1.87：80，则访问静态文件时会按 weight 比重分配到192.168.1.106：80和192.168.1.143：80服务器器，进行负载分配 - （2）.根据配置信息
location ~ \.php$
{
proxy_pass http://192.168.1.106; #此处限制访问php文件时，跳转到192.168.1.106服务器解析
}
当访问 php 文件时，会由 192.168.1.106 服务器解析内容,完成后再交由192.168.1.87：80显示给用户.
- （3）.针对不同的目录进行代理把下面的配置放到根目录代理的上面
location /zmPro/ {
proxy_pass http://192.168.1.143; #当访问zmPro目录时,由该IP服务器进行解析
}
- （4）. 反向代理进行的负载均衡需要注意 session 的使用限制， 参考文章介绍
- （5）. 个人理解，负载均衡的配置只需更改一处 nginx 配置文件即可，要求服务器列表中的相应目录是尽量可以成功访问的。
- （6）.开启服务，允许访问，本人测试时只是关闭了防火墙，根据定义的均衡服务器，避免访问文件的存在性.
4). 截图
- default.conf 配置截图，仅供参考
- 笔记截图
5）.结果描述
- 访问 html 文件时，会根据权重由 192.168.1.106 和 192.168.1.143 进行解析
- 访问 php 文件时，只会由 192.168.1.106 解析
- 访问 zmPro 目录下的文件时，会由 192.168.1.143 解析，此时如果是 html 文件，如果 192.168.1.106 对应位置没有相关文件，会根据前面的权重出现不同的访问状况，一种情况是由 192.168.1.143 正常解析，另一种情况是 192.168.1.106 无对应文件而 404 解析失败，如图：
- 所以，强烈建议匹配不同内容时，注意访问的可行性，以及文件的同步性，建议可参考文章 nginx 反向代理配置及优化
