The reverse WebSocket proxy allows all WebSocket traffic between the user and the upstream to pass through the Qrator Labs network. For more, see Technology: Reverse WebSocket proxy.

The required connection configuration order for the reverse WebSocket proxy is described below. You will also find information on setting the limits and balancing for this service.

Order of configurationOrder of configuration

1. Configure the client side of your application such that WebSocket traffic is routed to a dedicated port.

   Qrator Labs uses the same IP address for both HTTP and HTTPS traffic, and for WebSocket traffic. For correct analysis and protection, it is necessary that these two types of traffic come to this IP address on different ports.

   Note

   For example, you can configure your application to use port 8080 for WebSocket traffic, while still processing HTTP and HTTPS traffic on standard ports 80 and 443.

   The reverse WebSocket proxy responds to any HTTP request other than HTTP 101 Switching Protocols with an HTTP error code 400 Bad Request.

2. Tell the Qrator Labs technical support team the IP addresses and ports of your upstreams handling WebSocket traffic. They may not match the upstream IP addresses and ports for reverse HTTP proxy.

   When using multiple upstreams at the same time, balancing will be enabled; see Balancing.

3. If necessary, inform the Qrator Labs technical support team of the limits on the number of simultaneous connections from one IP address. Refer to Limits for more information.

4. Configure the upstream firewall to only allow traffic from trusted networks.

Recommendations for configuring a firewall are given in the relevant section of the article Connection: Reverse HTTP Proxy. Note that in the scripts in it you need to replace ports 80 and 443 with the ports on which your upstream accepts requests via WebSocket.

LimitsLimits

To make it more difficult to launch DDoS attacks against your application's upstreams, Qrator Labs limits the number of WebSocket connections that users can initiate from a single IP address. When the limits are exhausted, the WebSockets proxy will reject new attempts to establish connections until any of the previously established connections are closed.

The default limits are appropriate for most clients, but can be changed if necessary. For example, if your application needs to access many WebSocket resources for a single user at the same time, inform the technical support team and they will increase the limit accordingly. This will avoid erroneous blocking of legitimate traffic.

If you plan to make frequent requests to the resource from some known IP addresses, provide these IP addresses to technical support to be added to the whitelist. Requests from this list will be subject to increased limits.

BalancingBalancing

When dealing with multiple upstreams, the reverse WebSocket proxy allocates users among them using the IP hash algorithm. This algorithm selects an upstream depending on the request IP address, with repeated connections from the same IP address being established with the same upstream. In practice, this means that all connections initiated by a single user are highly likely to be proxied to the same upstream - which is beneficial, in particular, for more efficient use of the cache on each server.

If an upstream does not respond within 5 seconds when trying to connect, the reverse proxy will attempt to connect to the next upstream in the list. The order of upstreams in the list can be changed by contacting technical support.

A response with HTTP status code 400 Bad Request, signaling a connection failure, will be sent to the user only after attempts to connect to each upstream in turn fail.