服务器反向代理

Nginx的配置还是比较简单的，如：

location ~ /* ``{``proxy_pass http://127.0.0.1:8008;``}

或者可以

location /``{``proxy_pass http://127.0.0.1:8008;``}

Apache2的反向代理的配置是：

ProxyPass /ysz/ http://localhost:8080/

然而，如果要配置一个相对复杂的反向代理
Nginx相对Apache2就要麻烦一些了
比如，将url中以/wap/开头的请求转发到后台对应的某台server上
可以再Nginx里设置一个变量，来临时保存/wap/后面的路径信息

location ^~ /wap/``{``if ($request_uri ~ /wap/(\d+)/(.+))``{``set $bucketid $1;``set $params $2;``}``proxy_pass http://mx$bucketid.test.com:6601/$params;``}

也可以首先rewrite一下，然后再代理：

location ^~ /wap/{``rewrite /wap/(\d+)/(.+) /$2?$args break;``proxy_pass http://mx$1.test.com:6601;``}

或者

location ~* /wap/(\d+)/(.+)``{``proxy_pass http://mx$1.test.com:6601/$2?$args;``}

注意上面最后的?$args，表明把原始url最后的get参数也给代理到后台
如果在proxy_pass中使用了变量（不管是主机名变量$1或后面的$2变量），则必须得加这段代码
但如果pass_proxy后没用任何变量，则不需要加，它默认会把所有的url都给代理到后台，如：

location ~* /wap/(\d+)/(.+)``{``proxy_pass http://mx.test.com:6601;``}

而Apache2相对就简单多了：

ProxyPassMatch ^/wap/(.*)$ http://192.168.132.147/$1`` ` `if ($host ~* www.(.*)){``   ``set $host_without_www $1;``   ``rewrite (.*)$ http://$host_without_www/www$1;``  ``}

**url的/问题
**在nginx中配置proxy_pass时，当在后面的url加上了/，相当于是绝对根路径，则nginx不会把location中匹配的路径部分代理走;如果没有/，则会把匹配的路径部分也给代理走。

下面四种情况分别用http://192.168.1.4/proxy/test.html 进行访问。
第一种：

location /proxy/ {``   ``proxy_pass http://127.0.0.1:81/;``}

会被代理到http://127.0.0.1:81/test.html 这个url

第二咱(相对于第一种，最后少一个 /)

location /proxy/ {``   ``proxy_pass http://127.0.0.1:81;``}

会被代理到http://127.0.0.1:81/proxy/test.html 这个url

第三种：

location /proxy/ {``   ``proxy_pass http://127.0.0.1:81/ftlynx/;``}

会被代理到http://127.0.0.1:81/ftlynx/test.html 这个url。

第四种情况(相对于第三种，最后少一个 / )：

location /proxy/ {``   ``proxy_pass http://127.0.0.1:81/ftlynx;``}

会被代理到http://127.0.0.1:81/ftlynxtest.html 这个url

上面的结果都是本人结合日志文件测试过的。从结果可以看出，应该说分为两种情况才正确。即http://127.0.0.1:81 (上面的第二种) 这种和 http://127.0.0.1:81/…. （上面的第1，3，4种） 这种。

使用Nginx对WebSocket进行反向代理

部署websocket服务时，发现无法连接

Nginx从1.3.13版本就开始支持WebSocket了，并且可以为WebSocket应用程序做反向代理和负载均衡。

# 在http上下文中增加如下配置，确保Nginx能处理正常http请求。

http {
    
  map $http_upgrade $connection_upgrade {
    default upgrade;
    ''   close;
  }

  upstream websocket {
    #ip_hash;
    server localhost:8010; #你的ws服务端口
  }
  .....
}

# 以下配置是在server上下文中添加，location指用于websocket连接的path。
server {
    listen       80;
    server_name localhost;
    access_log /var/log/nginx/yourdomain.log;

    location / {
      proxy_pass http://websocket;
      proxy_read_timeout 300s;

      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection $connection_upgrade;
        }
    }
}

最重要的就是在反向代理的配置中增加了如下两行，其它的部分和普通的HTTP反向代理没有任何差别。

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;

这里面的关键部分在于HTTP的请求中多了如下头部：

Upgrade: websocket
Connection: Upgrade

这两个字段表示请求服务器升级协议为WebSocket。服务器处理完请求后，响应如下报文：

# 状态码为101
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: upgrade

告诉客户端已成功切换协议，升级为Websocket协议。握手成功之后，服务器端和客户端便角色对等，就像普通的Socket一样，能够双向通信。不再进行HTTP的交互，而是开始WebSocket的数据帧协议实现数据交换。

这里使用map指令可以将变量组合成为新的变量，会根据客户端传来的连接中是否带有Upgrade头来决定是否给源站传递Connection头，这样做的方法比直接全部传递upgrade更加优雅。

默认情况下，连接将会在无数据传输60秒后关闭，proxy_read_timeout参数可以延长这个时间或者源站通过定期发送ping帧以保持连接并确认连接是否还在使用。

【非常经典的总结】 Ngnix中location与proxy_pass配置规则总结_比特币爱好者007的博客-CSDN博客_location中的proxy_pass

[nginx: emerg] unknown “connection_upgrade” variable解决与思考 - SegmentFault 思否