---
title: "How Arion works"
url: "/docs/get-started/how-it-works/"
kind: "concept"
summary: "One picture of the data plane: listeners accept connections, filter chains process them, routes pick clusters, clusters hold endpoints."
---

> Arion site index: [/llms.txt](/llms.txt)

# How Arion works

One picture of the data plane: listeners accept connections, filter chains process them, routes pick clusters, clusters hold endpoints.

Every request through Arion crosses the same four resources — listener, filter chain, route, cluster — and knowing which is which tells you where to configure anything.

{{ <figure src="img/docs/how-it-works.svg" alt="A request flows from a client through an Arion listener, filter chain and router to a cluster of endpoints, while configuration arrives from a file or xDS." caption="The request path left to right; configuration arrives from below, from a file or an xDS control plane." label="Figure 1." /> }}

A **listener** binds an address and port and accepts connections. For each connection it selects one **filter chain** by the chain's match criteria (destination port, SNI, source addresses). The chain's network filters run in order; for HTTP the last one is the HTTP connection manager, which runs a second list of HTTP filters ending in the **router**. The router matches the request against the route table — virtual hosts by domain, then routes by path and headers — and the winning **route** names a **cluster**, which load-balances the request across its endpoints.

The resources mean the same thing however they arrive: written in an `envoy_bootstrap` section of Arion's config file, or streamed from a control plane over xDS.

## Key terms

| Term | Meaning |
| --- | --- |
| Listener | A bound `address:port` that accepts connections and owns filter chains. See [listeners](@/docs/traffic/listeners.md). |
| Filter chain | An ordered list of network filters, selected per connection by its match. See [the filter chain](@/docs/concepts/filter-chain.md). |
| Network filter | An L4 stage — `tcp_proxy`, or the HTTP connection manager. |
| HTTP filter | An L7 stage inside the HTTP connection manager; the last one is always the router. |
| Route | A match (domain, path, headers) plus an action, usually "send to this cluster". See [routing](@/docs/traffic/routing.md). |
| Cluster | A named group of endpoints with a load-balancing policy. See [upstreams](@/docs/traffic/upstreams-and-load-balancing.md). |
| Endpoint | One upstream `address:port` inside a cluster. |
| xDS | Envoy's discovery protocol, delivering all of the above from a control plane. See [xDS control planes](@/docs/operate/xds-control-planes.md). |

## Next

- [Architecture](@/docs/concepts/architecture.md) — the runtime behind this picture.
- [Life of a request](@/docs/concepts/life-of-a-request.md) — the same path, step by step.
- [The filter chain](@/docs/concepts/filter-chain.md) — attachment points and ordering.
- [Configuration model](@/docs/concepts/configuration-model.md) — the file and xDS forms.