Traffic Distributor Overview

Traffic Distributor is a free, one-click load-balancing solution that intelligently routes HTTP and HTTPS traffic between two application backends according to the selected routing method and traffic ratio.

Traffic Distributor balances requests between two application environments.

As an application grows, several environment copies may be required to provide additional capacity, run different application versions, or protect the service from infrastructure failures. Traffic Distributor simplifies request routing between these copies through an automatically configured load balancer.

On this page

Features and Benefits
Routing Methods
Traffic Distributor Implementation
Entry Points and Protocols
Typical Use Cases
What’s next?

Features and Benefits

High Availability and Failover Distribute traffic between two application copies, including backends hosted on different hardware, to improve fault tolerance.

Blue-Green Deployment Send all requests to one backend while the other application version is updated or maintained.

A/B Testing Divide traffic between two application versions and compare their performance and user experience.

Intuitive Configuration Configure hosts, routing type, traffic ratio, HTTPS, entry point, environment name, and region through a graphical installation form.

Backend Health Checks The distributor verifies that each backend returns a normal response, typically HTTP status code 200, according to configurable frequency and timeout settings.

Flexible NGINX Tuning Extend the standard configuration manually with caching, TCP mapping, SNI, and other NGINX features.

Compared with a single application server, Traffic Distributor can improve request processing, reduce response delay, and allow more simultaneous connections to be handled.

Traffic Distributor installation package — The package form defines the entry point, number of balancers, routing method, traffic ratio, HTTPS, backends, environment name, and region.

Routing Methods

Traffic Distributor supports three routing methods. Select the option that best matches the application architecture and operational objective.

Round Robin Distributes requests between the two backends in rotation according to their configured priorities or traffic ratio.

Sticky Sessions Associates each user with a specific backend according to server weights and keeps subsequent requests on that backend until the session expires.

Failover Uses one backend as the primary service and keeps the second backend in reserve. Traffic is redirected automatically when the primary backend becomes unavailable.

Round Robin requirement: Both backends should contain identical application content because user requests can be served by either environment.

Traffic Distributor Implementation

Traffic Distributor is installed from Marketplace by completing a configuration form and clicking Install. The package creates a separate environment with one or more predefined NGINX load-balancer nodes and installs the Traffic Distributor add-on on top of them.

Select the two backend hosts or application environments.
Choose Round Robin, Sticky Sessions, or Failover routing.
Set the traffic ratio or backend priorities.
Enable HTTPS when secure routing is required.
Select the entry point, number of balancers, environment name, display name, and region.

Traffic Distributor environment — The installed Traffic Distributor appears as a separate environment with NGINX load-balancer nodes.

Entry Points and Protocols

Before installation, select how incoming requests should reach Traffic Distributor:

Shared Load Balancer: Uses the platform-provided shared entry point.
Public IP: Routes requests directly through one or more dedicated public addresses.

Traffic Distributor works with standard HTTP and HTTPS traffic and can also route protocols built on the same handshake model, including WebSockets.

WebSockets: Load balancing is performed during the HTTP handshake. After the handshake succeeds, a persistent WebSocket connection is established directly with the selected backend.

Typical Use Cases

Balance requests evenly between identical application environments.
Protect an application with an active and standby backend.
Perform blue-green application updates without user-visible downtime.
Run ongoing A/B tests between two application versions.
Distribute workloads between environments hosted on different hardware or regions.
Extend routing with advanced NGINX configuration where required.