Edit Listener

After the listener is created, you can modify its forwarding rules by going to the listener list page and selecting Actions > Edit Listener.

Protocol

Listener will use the protocol to receive client traffic.

Please note that the protocol cannot be changed after the listener is created.

TCP

Suitable for scenarios that require reliable, connection-oriented data transmission, such as web services, databases, file transfers, email services, and remote access.

UDP

Suitable for scenarios that prioritize low latency and real-time communication over reliability, such as video conferencing, online gaming, DNS services, and real-time data streaming.

Listening Port

Listening ports define the ports on which the listener accepts client requests. Valid range: 1 to 65535.

• You can specify one or more ports for the listener.

• Each port listens for incoming traffic using the selected protocol.

• Traffic received on these ports is forwarded to the backend server ports defined in the backend configuration.

Example:

• Listening port: 443

• Backend server port: 8443

Note

When the forwarding mode is Direct Routing, the backend server port must match the listening port.

Forwarding Mode

Forwarding mode that determines how traffic is forwarded to backend servers.

Currently, only Destination NAT (DNAT) is supported for the newly created listeners.

Destination NAT (DNAT)

The load balancer rewrites the destination IP address to the selected backend server while preserving the client source IP address. Backend servers can obtain the real client IP.

Full NAT (FNAT)

The load balancer rewrites both the source and destination IP addresses of packets before forwarding them to backend servers. Backend servers see the load balancer’s IP as the source IP.

Direct Routing (DR)

The load balancer forwards traffic to backend servers without modifying the destination IP address. Backend servers respond directly to the client.

Scheduling Algorithm

Scheduling algorithm determines how traffic is distributed across backend servers.

Maglev Hashing (mh)

A consistent hashing–based algorithm that provides even traffic distribution and minimizes remapping when backend servers are added or removed. Suitable for large-scale and high-concurrency workloads.

Weighted Round Robin (wrr)

Distributes requests sequentially across backend servers based on assigned weights. Servers with higher weights receive more traffic.

Least Connections (Ic)

Routes new requests to the backend server with the fewest active connections.

Weighted Least Connections (wIc)

Routes traffic based on both the number of active connections and server weights. Servers with higher weights can handle more connections.

Source Hashing (sh)

Distributes traffic based on a hash of the client source IP address, ensuring that requests from the same client are consistently routed to the same backend server.

Destination Hashing (dh)

Distributes traffic based on a hash of the destination IP address.