WebSocket 代理

要将客户端与服务器之间的连接从 HTTP/1.1 转换为 WebSocket，可以使用 HTTP/1.1 中提供的协议切换机制。

然而，这里有一个微妙之处：由于 “Upgrade” 是一个逐跳 (hop-by-hop) 头部，它不会从客户端传递到被代理的服务器。对于正向代理 (forward proxying)，客户端可以使用 CONNECT 方法来规避此问题。但是，对于反向代理 (reverse proxying)，这不起作用，因为客户端并不知道存在任何代理服务器，因此需要在代理服务器上进行特殊处理。

自版本 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 帧来重置超时并检查连接是否仍然存活。