# 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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.console.zenlayer.com/welcome/elastic-compute/load-balancing/07-all-ports-listener.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.