1

I have tried every conceivable haproxy configuration posted in blogs and stackoverflow, but I still cannot get haproxy and socket.io to work 100% of the time. In the majority of browsers that "support" web sockets it fails and falls back on long polling after missed heart beats. The browser appears to make the initial connection (nodejs debugging), but I cannot get the clients to receive the connection response. Is anyone else having similar problems? Below are the software version numbers and a couple of the configs I have tried.

  • haproxy 1.4.18
  • node 0.6.5
  • socket.io 0.8.7

Haproxy configurations (I have tried many more and numerous options):

Web sockets working in:

  • Safari 5 (Windows)
  • Chrome 11 (Linux)
Community
  • 1
  • 1
user1120155
  • 241
  • 1
  • 2
  • 7
  • I removed haproxy from the equation and socket.io works flawlessly, so I must be doing something wrong in my haproxy config or the two do not play well together anymore for some reason. – user1120155 Dec 28 '11 at 23:35
  • If I stop haproxy before socket.io switches protocols then the on connection web socket message is sent to the client. I am now using [link](http://stackoverflow.com/questions/8627070/a-good-solution-for-a-websocket-socket-io-server-ive-tried-nginx-node-etc) for configuration. – user1120155 Dec 29 '11 at 20:27
  • I spent a fair bit of time trying to get the right haproxy configuration. In my case, I wanted web and flash sockets to pass through, but no other transports. I also wanted to terminate ssl at haproxy. It's been a while and you have probably worked through the problem. However, I blogged about my solution: http://blog.carbonfive.com/2013/05/02/using-haproxy-with-socket-io-and-ssl/ Cheers, Christian – Christian Nelson May 21 '13 at 16:37

1 Answers1

-2

Websockets cannot be reverse proxy'd because the 8 bytes of data the client must send after the headers is not advertised in a Content-Length header, so the intermediates won't forward that data until the handshake completes. And since the handshake needs those 8 bytes to complete, the handshake never completes and deadlocks, http://www.enotes.com/topic/WebSockets#Proxy_traversal. This is not the only source. Many more sources verify that they cannot be reverse proxy'd.

user1120155
  • 241
  • 1
  • 2
  • 7
  • 1
    This point it totally wrong and relates to the initial websocket draft which was not compatible with HTTP. WebSocket *can* be reverse-proxied because it became HTTP-compatible. – Willy Tarreau May 23 '12 at 22:20