安装
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 端口），他们不知道也不必知道后面发生了什么
虚拟域名
Nginx 虚拟域名配置较 Apache 真是简单了不少。
我们可以先在根目录（跟 nginx.exe 同级）新建个文件夹 www，和 Apache 的 www 表示同个意思。然后我们假设要配置 www.a.com 的虚拟域名，可以在 www 下新建个 a 文件夹，然后在 Nginx 的配置文件 nginx.conf 中将 root 指向 www/a：
# virtual hosts
server {
listen 80;
server_name www.a.com;
location / {
root www/a;
index index.html index.htm;
}
}然后在 HOSTS 文件中将 www.a.com 指向本地：
127.0.0.1 www.a.com最后启动 nginx，访问 http://www.a.com/ 就能访问到 www/a 下的 index.html 或者 index.htm 文件了。
Nginx for Mac（2017/5/8/ add）
感觉 Nginx 在 Mac 上的安装比在 Windows 复杂，还好有 brew 这个神器，直接 brew install nginx 一行解决了问题，不过安装过程中出现了两个 error，不知道对后续的使用有没有影响，待观察。
主要有以下几个命令：
sudo brew services start nginx // 启动
sudo brew services stop nginx // 关闭启动 Nginx 后在浏览器打开 localhost:8080 即可出现欢迎页面。Nginx 的配置文件在 /usr/local/etc/nginx/nginx.conf 中，像之前在 Win 中的操作一样，可以在这里配置反向代理。Nginx 的安装路径在 /usr/local/Cellar/nginx/ 中，另外还有一个服务器默认地址在 /usr/local/var/www 。
这样启动/关闭 Nginx 比较麻烦，我们把路径写进 Path 中，可以全局调用。比如在我的 .zshrc 文件中，加上这么一行（跟你的 Nginx 安装路径以及 shell 相应配置文件对应）：
export PATH=$PATH:/usr/local/Cellar/nginx/1.12.0/bin这时输入 which nginx 命令便能得到结果，接着调用 Nginx 的命令就不需要通过 brew 了，常见的命令有（跟 Win 有些许差异）：
sudo nginx // 启动
sudo nginx -s stop // 关闭
sudo nginx -s quit
sudo nginx -s reload
sudo nginx -t // nginx 服务器测试more: http://www.barretlee.com/blog/2016/11/19/nginx-configuration-start/