要在 Microsoft Win32® 平台上构建 nginx，您需要：
Microsoft Visual C编译器。已知 Microsoft Visual Studio® 8 和 10 可以正常工作。MSYS。如果您要构建 OpenSSL® 和有 SSL 支持的 nginx，则需要 Perl。例如 ActivePerl 或 Strawberry Perl。Mercurial 客户端PCRE、zlib 和 OpenSSL 库源代码。在开始构建之前，确保将 Perl、Mercurial 和 MSYS 的 bin 目录路径添加到 PATH 环境变量中。从 Visual C 目录运行 vcvarsall.bat 脚本设置 Visual C 环境。
构建 nginx：
启动 MSYS bash。检出 hg.nginx.org 仓库中的 nginx 源代码。例如： hg clone http://hg.nginx.org/nginx 创建一个 build 和 lib 目录，并将 zlib、PCRE 和 OpenSSL 库源码解压到 lib 目录中： mkdir objs mkdir objs/lib cd objs/lib tar -xzf ../../pcre-8.41.tar.gz tar -xzf ../../zlib-1.2.11.tar.gz tar -xzf ../../openssl-1.0.2k.tar.gz 运行 configure 脚本： auto/configure --with-cc=cl --builddir=objs --prefix= \ --conf-path=conf/nginx.conf --pid-path=logs/nginx.pid \ --http-log-path=logs/access.log --error-log-path=logs/error.log \ --sbin-path=nginx.exe --http-client-body-temp-path=temp/client_body_temp \ --http-proxy-temp-path=temp/proxy_temp \ --http-fastcgi-temp-path=temp/fastcgi_temp \ --with-cc-opt=-DFD_SETSIZE=1024 --with-pcre=objs/lib/pcre-8.41 \ --with-zlib=objs/lib/zlib-1.2.11 --with-openssl=objs/lib/openssl-1.0.2k \ --with-select_module --with-http_ssl_module 运行 make： nmake -f objs/MakefileWindows 下的 nginx
http://nginx.org/en/docs/howto_build_on_win32.html
使用共享主机的用户以前仅使用 Apache 的 .htaccess 文件来配置一切，通常翻译下列规则：
RewriteCond %{HTTP_HOST} example.org RewriteRule (.*) http://www.example.org$1像这样：
server { listen 80; server_name www.example.org example.org; if ($http_host = example.org) { rewrite (.*) http://www.example.org$1; } ... }这是一个错误、麻烦而无效的做法。正确的方式是为 example.org 定义一个单独的服务器：
server { listen 80; server_name example.org; return 301 http://www.example.org$request_uri; } server { listen 80; server_name www.example.org; ... }在 0.9.1 之前的版本，重定向可以通过以下方式实现：
rewrite ^ http://www.example.org$request_uri?;另一个例子是使用了颠倒逻辑，即 所有不是 example.com 和 www.example.com 的：
RewriteCond %{HTTP_HOST} !example.com RewriteCond %{HTTP_HOST} !www.example.com RewriteRule (.*) http://www.example.com$1应该简单地定义 example.com、www.example.com 和 其他一切：
server { listen 80; server_name example.com www.example.com; ... } server { listen 80 default_server; server_name _; return 301 http://example.com$request_uri; }在 0.9.1 之前的版本，重定向可以通过以下方式实现：
rewrite ^ http://example.com$request_uri?;典型的 Mongrel 规则：
DocumentRoot /var/www/myapp.com/current/public RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f RewriteCond %{SCRIPT_FILENAME} !maintenance.html RewriteRule ^.*$ %{DOCUMENT_ROOT}/system/maintenance.html [L] RewriteCond %{REQUEST_FILENAME} -f RewriteRule ^(.*)$ $1 [QSA,L] RewriteCond %{REQUEST_FILENAME}/index.html -f RewriteRule ^(.*)$ $1/index.html [QSA,L] RewriteCond %{REQUEST_FILENAME}.html -f RewriteRule ^(.*)$ $1.html [QSA,L] RewriteRule ^/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L]应该转换为：
location / { root /var/www/myapp.com/current/public; try_files /system/maintenance.html $uri $uri/index.html $uri.html @mongrel; } location @mongrel { proxy_pass http://mongrel; }http://nginx.org/en/docs/http/converting_rewrite_rules.html
要将客户端与服务器之间的连接从 HTTP/1.1 转换为 WebSocket，可是使用 HTTP/1.1 中的 协议切换 机制。
然而，有一个微妙的地方：由于 Upgrade 是一个逐跳（hop-by-hop）头，它不会从客户端传递到代理服务器。当使用转发代理时，客户端可以使用 CONNECT 方法来规避此问题。然而，这不适用于反向代理，因为客户端不知道任何代理服务器，这需要在代理服务器上进行特殊处理。
自 1.3.13 版本以来，nginx 实现了特殊的操作模式，如果代理服务器返回一个 101响应码（交换协议），则客户机和代理服务器之间将建立隧道，客户端 通过请求中的 Upgrade 头来请求协议交换。
如上所述，包括 Upgrade 和 Connection 的逐跳头不会从客户端传递到代理服务器，因此为了使代理服务器知道客户端将协议切换到 WebSocket 的意图，这些头必须明确地传递：
location /chat/ { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; }一个更复杂的例子是，对代理服务器的请求中的 Connection 头字段的值取决于客户端请求头中的 Upgrade 字段的存在：
http { map $http_upgrade $connection_upgrade { default upgrade; '' close; } server { ... location /chat/ { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; } }默认情况下，如果代理务器在 60 秒内没有传输任何数据，连接将被关闭。这个超时可以通过 proxy_read_timeout 指令来增加。 或者，代理服务器可以配置为定期发送 WebSocket ping 帧以重置超时并检查连接是否仍然活跃。
http://nginx.org/en/docs/http/websocket.html
