安装
windows 下 Nginx 安装非常简单,下载地址 http://nginx.org/en/download.html。
选择红框这个,下载下来是个 zip 文件,解压。这时我们双击根目录的 nginx.exe
文件便可启动 Nginx 服务器,启动后打开 localhost 会出现 Nginx 欢迎页(因为和 Apache 默认都是 80 端口,所以开着 Apache 可能会有冲突)。
几个常用命令:
start nginx // 启动 nginx,和双击 nginx.exe 等效
nginx -s stop // 快速关闭 nginx 服务,fast shutdown
nginx -s quit // 退出 nginx ,graceful shutdown
nginx -s reload // 重启 nginx 服务
nginx -h // 查看帮助
Nginx 反向代理
用 Nginx 做反向代理非常简单,比如有这样一个 Node 文件(假设为 index.js)。
var http = require("http");
http.createServer(function(request, response) {
response.writeHead(200, {"Content-Type": "text/html"});
response.write("Hello World!");
response.end();
}).listen(8000);
我们用 node index.js
命令启动 Node 服务,在浏览器输入 localhost:8000 便可看到结果。由于某些原因,我们想用 www.test.com 打开它,可以在 conf\nginx.conf
文件中追加如下配置(追加在 http{}
中):
# node test
server {
listen 80;
server_name www.test.com;
location /{
proxy_pass http://127.0.0.1:8000;
proxy_set_header Host $host;
}
}
然后在 HOSTS(C:\Windows\System32\drivers\etc) 文件中将 www.test.com 指向本地(这一步没做困扰我好久):
127.0.0.1 www.test.com
启动 Nginx 服务器,这时再在浏览器中输入 www.test.com 就能看到 Hello World 字样了。
反向代理
以下内容摘自 https://segmentfault.com/q/1010000003491873/a-1020000003492000
A 找 B 直接沟通,这就等于没有什么代理;
然而中间夹一个传话的 C,C 就是代理了,A 通过 C 把信息传递给 B,然后 C 再把 B 的反馈转达给 A。
在这个过程中,A 知道沟通的直接目标是 B,只不过由于各种原因无法直接和 B 面对面,需要中间人 C,这就是所谓“正向代理”,其实我们很少说正向代理,在英文原文里,这个叫 Forward Proxy,一般就直接叫代理,你翻译成“转交代理”或“传达代理”都比“正向代理”强,然而没必要,因为代理这个词的本意就是如此。
另外一种情况则是:A 并不知道 B 的存在,它只知道找 C 就可以得到想要的回复,对于 A 来说有没有 B 或者有多少个 B、D、E、F……都不重要,只要有 C 就够了。而 C 则根据情况去获取反馈然后响应给 A。
这种就叫反向代理了。理解其中的区别不要从“正反”两个反义方向词上做文章,英文里的 Forward 和 Reverse 并不是一对反义词,Forward 和 Backward 才是,然而 Reverse 和 Backward 并不是一个意思……所以说技术书籍资料还就是得看原文的啊。
Forward Proxy(代理)
我想访问 www.google.com,然而大家都知道它被墙了,我没法直接访问它。于是我连接了一个 VPN 服务并设定其为本地 HTTP 访问的代理(比如说在 Mac 下勾选“通过 VPN 连接发送所有流量),然后我再访问 www.google.com,此时我的请求被该 VPN 服务代理了,它帮我访问了 www.google.com 然后把结果返回给我。
- 这个例子是代理的一种应用场景,但并非代表代理只能用于这个
- 最重要的特征是我知道 www.google.com 的存在,而且我访问的网址也的确是 www.google.com,只不过我的访问请求经由了 VPN 代理来转交,同样响应也是如此
- 在本例中,代理是透明的,用户有可能不知道它的存在(通常是知道的,只不过代理的设置可能不是他自己来做)
Reverse Proxy(反向代理)
我有一个 Nginx 服务部署在 www.mysite.com 的 80 端口,用户访问它就可以看见我做的网站;在我的网站中有一些 Ajax 请求去获取 JSON 数据,然而提供这些数据的 API Service 部署在服务器上的 8000 端口,该端口由于防火墙的阻挠使得用户无法直接访问到。
于是我重新配置了 Nginx,让它把所有经由 :80/api/ 的访问请求都代理给 localhost:8000,然后把响应返回给原始的请求方(即:Origin Host),这就是反向代理。现在我的用户可以正常访问 www.mysite.com 啦。
- 同上,这是反向代理的一种应用场景,但并非代表它只能这样用
- 最重要的特征是我的用户压根不知道 localhost:8000 这个服务的存在,并且即使知道也访问不到——开 VPN 也访问不到,这是俩码事!
- 对于用户来讲,唯一的“对话”方只有 www.mysite.com(80 端口),他们不知道也不必知道后面发生了什么