Can I load balance WebSocket traffic?
Short answer
Yes. An HTTP vService carries the WebSocket connection (HTTP Upgrade → 101 Switching Protocols) on its own; there is no separate WebSocket setting to turn on in TR7. After the connection is established, a WebSocket connection that stays idle is closed when the Tunnel(Websocket) Timeout (default 120 seconds) expires; this duration is increased according to the needs of the application with a Timeouts profile, and the profile is selected from the Timeout box in the Details panel of the vService.
Problem: Why Do WebSocket Connections Drop?
A WebSocket connection starts with an HTTP request, turns into a bidirectional tunnel with Upgrade, and can stay open for hours. After the tunnel is established, Tunnel(Websocket) Timeout applies instead of the client and server timeouts: if no data passes in either direction during this time, the connection is closed. The default of 120 seconds is short for applications that exchange messages infrequently; users see the connection drop on its own.
Solution: Two Methods
| Your situation | Suitable method |
|---|---|
| Web application; WAF, HTTP Logs and routing by path should be used | Method 1: HTTP vService |
| WebSocket traffic should be forwarded at the connection level, without being processed as HTTP | Method 2: L7 TCP vService |
Method 1: HTTP vService Recommended
- How it works The HTTP vService forwards the Upgrade request to the Backend Service; after the
101response, it carries the connection as a bidirectional tunnel. - Where it is opened No additional setting is required for WebSocket; for the duration, vService → Details → Timeout → Timeouts profile
- Requirement For
ws://, HTTP; forwss://, a protocol (HTTP/1.1 or HTTP/2) from the Encrypted (HTTPS) group and a certificate - vService type HTTP
- Backend Service side It is enough for the application to accept the WebSocket Upgrade request; no additional setting is required on the server for TR7.
Step-by-Step Configuration
The Load Balancer → Profiles → Timeouts → Add steps are followed (how to add). If a suitable profile already exists, the process continues from step 4; editing a profile that other vServices use also affects them.
The Name is entered. In the Tunnel(Websocket) Timeout field, a value greater than the longest time the application stays silent between two messages is written in seconds (e.g. 3600). The field accepts at most 60,000 seconds. The other fields can stay at their default values.
The Add button at the bottom of the form is clicked.
On the Load Balancer → Load Balancer vService List screen, the HTTP vService is selected and the Edit button is clicked.
The Details switch at the top right of the form is turned on; in the panel, the Timeout box is checked and the created profile is selected.
If wss:// will be used, HTTP/1.1 or HTTP/2 from the Encrypted (HTTPS) group must be selected in the Protocol field of the frontend row, and a certificate must be selected in the Certificate field. If the certificate is not on TR7, it is first uploaded with Certificates & PKI → SSL/TLS Certificates → Add (How do I upload my certificate to TR7; which formats are supported?).
The Save button is clicked. With the save, the duration in the profile takes effect on this vService; the progress of applying it is followed from the sync indicator at the bottom right of the screen. In a cluster setup, the change is also transferred to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent manually with Synchronize.
Verification
curl -i -N --http1.1 -H "Connection: Upgrade" -H "Upgrade: websocket" -H "Sec-WebSocket-Version: 13" -H "Sec-WebSocket-Key: SGVsbG8sIHdvcmxkIQ==" https://www.example.com/wsHTTP/1.1 101 Switching Protocols--http1.1 is required; if HTTP/2 is negotiated, curl cannot send the Upgrade header.The status code of the WebSocket request is examined on the HTTP Logs screen of the vService.
101Method 2: L7 TCP vService
- How it works L7 TCP forwards the stream to the Backend Service without parsing it as HTTP; the WebSocket handshake and the messages pass as they are.
- Where it is opened vService → Type: L7 TCP → Frontend → Protocol: TCP (TLS on the Backend Service) or TCP + TLS (TLS on TR7)
- Requirement WAF, HTTP Logs and routing by path not being needed
- vService type L7 TCP
- Backend Service side If Protocol TCP is selected, the certificate and TLS for
wss://are on the server; if TCP + TLS is selected, the server accepts unencrypted WebSocket (ws://).
Step-by-Step Configuration
For connections that stay silent for a long time, a Timeouts profile with an increased Tunnel(Websocket) Timeout value is created as in steps 1–3 of Method 1; in L7 TCP too, this is the duration that applies after the connection is established.
The Load Balancer → Backend Services → Add steps are followed (How is a Backend Service added; which information is required?). The Backend Service can also be created without leaving the form, with the Backend Service button of the selector in the vService form.
The Backend Service Name and the Address (the IP of the server and the WebSocket port) are entered.
The Add button at the bottom of the form is clicked.
The Load Balancer → Load Balancer vService List → Add steps are followed; Name is entered and L7 TCP is selected as the Type.
In the frontend row, the IP is selected and the port is written. If TLS will stay on the Backend Service, Protocol TCP is selected; if it will be terminated on TR7, TCP + TLS is selected and a certificate is selected in the Certificate field. If the IP is not in the list, it is first added to the interface with Network → Interfaces → Actions → Add IP (how to add); the same form also opens with Add IP in the Frontend IP list (Why can't I type the Frontend IP manually; what should I do to use an IP that is not in the list (e.g. IPv6) on a vService?).
The Backend Service is selected in the Default Backend Services table.
The Save button is clicked. In a cluster setup, the change is also transferred to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent manually with Synchronize.
Verification
websocat wss://www.example.com/wsThe connection stays open, messages are carried in both directionsCommon Mistakes
- Leaving the duration at the default. Tunnel(Websocket) timeout is 120 seconds; in applications that exchange messages infrequently, connections drop while idle. If the application can stay silent longer than 60,000 seconds, a periodic ping message is enabled on the client or server side.
- Selecting the profile without checking the Timeout box. The profile is not applied unless the Timeout box in the Details panel of the vService is checked and the profile is selected.
- Leaving the
ws://request to the HTTP → HTTPS redirect on port 80. WebSocket clients are not required to follow a 3xx redirect (RFC 6455 §4.1); the client must connect directly to thewss://address.
How it is done in the documentation
