Nginx 安装以及反向代理配置（windows）

安装

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 端口），他们不知道也不必知道后面发生了什么