> For the complete documentation index, see [llms.txt](https://docs.console.zenlayer.com/welcome/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.console.zenlayer.com/welcome/elastic-compute/load-balancing/07-all-ports-listener.md).

# All-Ports Listener

The all-ports listener is a single listener that matches **every port** on its protocol — one rule covers every TCP (or UDP) destination port from 1 to 65535. Use it for workloads where the destination port is part of the protocol and the backend already knows how to handle every port itself.

## How It Works

![All-ports listener: every destination port preserved end-to-end](/files/OHWDuFluoN14y1T9serW)

A client connecting to any port on the VIP is matched by the listener, the scheduler picks a healthy backend, and the **client's destination port is preserved on its way to the backend**. Different flows on different ports may land on the same or different backends — the port stays the same end-to-end.

For this to work, the backend's port must be configured as "same as listener port." See [Backend Servers](/welcome/elastic-compute/load-balancing/04-backend.md) for the field.

## When to Use, When Not To

| Scenario                                                                                                                                     | Use it? | Why                                                                                                           |
| -------------------------------------------------------------------------------------------------------------------------------------------- | ------- | ------------------------------------------------------------------------------------------------------------- |
| Backends use the destination port as part of the protocol — FTP active mode, RTSP / RTP, MMO and game servers, dynamic-port custom protocols | ✅ Yes   | One listener rule covers the whole port surface; the original destination port reaches the backend unchanged. |
| Passthrough VIP in front of a service where every port decision belongs to the backend                                                       | ✅ Yes   | Keeps the LB out of the port-policy choice.                                                                   |
| You can express the workload with explicit ports — even a long list                                                                          | ❌ No    | Explicit ports are easier to monitor, audit, and reason about.                                                |
| You also want explicit-port listeners on the same protocol                                                                                   | ❌ No    | All-ports and explicit-port listeners overlap on every port; configure one or the other, not both.            |
| Health needs to be evaluated per port                                                                                                        | ❌ No    | One probe per backend covers the whole port range; partial-port failures aren't detected.                     |

## Limitations

* One protocol per listener. If you need both TCP all-ports and UDP all-ports, create two listeners.
* All ports share one backend pool, scheduler, and health check — scheduling and health behavior cannot vary across the port range.
* Per-port observability (per-port traffic counters, per-port rate limits) is not available.