Nginx可以用作后端Websocket服务器的反向代理吗？

Question

我们正在开发一个Ruby on Rails应用程序，该应用程序需要利用html5 websockets。 目前，我们有两个单独的“服务器”可以这么说：我们的主应用程序运行在nginx + passenger上，一个单独的服务器使用Pratik Naik的Cramp框架（在Thin上运行）来处理websocket连接。

理想情况下，当需要进行部署时，我们将在nginx + passenger上运行rails应用程序，并且将websocket服务器代理到nginx之后，因此我们不需要将websocket服务器运行在其他端口上。

问题是，在此设置中，nginx似乎太早关闭了与Thin的连接。 成功建立与瘦服务器的连接，然后立即使用200响应代码关闭连接。 我们的猜测是，nginx并未意识到客户端正在尝试为websocket流量建立长期运行的连接。

诚然，我对nginx config并不那么精明，因此，甚至可以将nginx配置为充当websocket服务器的反向代理吗？ 还是我必须等待nginx为新的websocket握手内容提供支持？ 假设同时需要在端口80上监听应用程序服务器和Websocket服务器，这是否意味着我现在必须先在单独的服务器上运行Thin并没有nginx在前面？

在此先感谢您的任何意见或建议。 :)

-约翰

Answer 1

您目前不能为此使用nginx ^{[不再适用]} ，但我建议您查看HAProxy。 我已将其完全用于此目的。

诀窍是设置较长的超时时间，以便不关闭套接字连接。 就像是：

timeout client  86400000 # In the frontend
timeout server  86400000 # In the backend

如果您想在同一端口上使用Rails和Cramp应用程序，则可以使用ACL规则来检测WebSocket连接并使用其他后端。 所以您的haproxy前端配置看起来像

frontend all 0.0.0.0:80
  timeout client    86400000
  default_backend   rails_backend
  acl websocket hdr(Upgrade)    -i WebSocket
  use_backend   cramp_backend   if websocket

为了完整起见，后端看起来像

backend cramp_backend
  timeout server  86400000
  server cramp1 localhost:8090 maxconn 200 check

Answer 2

如何使用我的nginx_tcp_proxy_module模块 ？

该模块设计用于Nginx的常规TCP代理。 我认为它也适用于websocket。 我只是在开发分支中添加了tcp_ssl_module。

Answer 3

nginx（> = 1.3.13）现在支持反向代理websocket。

# the upstream server doesn't need a prefix! 
# no need for wss:// or http:// because nginx will upgrade to http1.1 in the config below
upstream app_server {
    server localhost:3000;
}

server {
    # ...

    location / {
        proxy_pass http://app_server;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        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_redirect off;
    }
}

Answer 4

Nginx开箱即用（即官方资源）只能建立到上游的HTTP 1.0连接（=后端），这意味着没有保持连接的可能性：Nginx将选择一个上游服务器，打开与之的连接，代理，缓存（如果需要） ）并关闭连接。 而已。

这是需要持久连接到后端的框架无法通过Nginx正常工作的根本原因（我猜没有HTTP / 1.1 =没有keepalive且没有websocket）。 尽管存在此缺点，但仍有明显的好处：Nginx可以从多个上游（负载平衡）中进行选择，并在其中一些发生故障的情况下进行故障转移以使一个存在。

编辑 ：Nginx从版本1.1.4开始支持HTTP 1.1到后端和keepalive。 支持“ fastcgi”和“ proxy”上游。 这是文档

Answer 5

对于任何想知道相同问题的人，nginx现在都正式支持HTTP 1.1上游。 有关“ keepalive”和“ proxy_http_version 1.1”的信息，请参见nginx文档。

Answer 6

Nginx如何使用新的HTTP Push模块： http : //pushmodule.slact.net/ 。 它可以照顾到连接杂耍（可以这么说），而使用反向代理可能要担心。 当然，它是替代Websockets的可行选择，Websockets还没有完全融合。 我知道HTTP Push模块的开发人员仍在开发一个完全稳定的版本，但是它正在积极开发中。 生产代码库中使用了它的某些版本。 引用作者的话：“一个无聊的有用工具。”

Answer 7

我使用nginx反向代理到具有长轮询连接的彗星样式服务器，并且效果很好。 确保将proxy_send_timeout和proxy_read_timeout配置为适当的值。 还要确保nginx代理的后端服务器支持http 1.0，因为我认为nginx的代理模块还不支持http 1.1。

只是为了消除一些答案中的一些混乱：Keepalive允许客户端重用连接以发送另一个HTTP请求。 它与长时间的轮询或保持连接打开无关，直到事件发生为止，而这正是原始问题要问的。 因此，与nginx的代理模块仅支持HTTP 1.0（没有保持活动状态）无关紧要。