All about HAProxy listens
An HAProxy listen exposes a backing service (MariaDB, PostgreSQL, Meilisearch, SingleStore, or RabbitMQ) on a port or socket, load-balanced across the cluster's nodes that run that service.
This article explains the source/destination model, the port-vs-socket choice, and the cross-cluster pattern.
What a listen does
A listen tells HAProxy: "for traffic arriving on this port (or socket), proxy to all nodes with this group, in this cluster."
Your application connects to the listen instead of to MariaDB, PostgreSQL or the rest directly. The listen spreads connections across every eligible backend node and fails over automatically when one is down.
HAProxy listens are managed per cluster.
Fields
'Nodes Group' — which backend service
Supported groups:
- MariaDB
- PostgreSQL
- Meilisearch
- SingleStore
- RabbitMQ
'Port' or 'Socket Path'
Set exactly one.
- 'Port' — a TCP port. Use this for application traffic.
- 'Socket Path' — a Unix socket, which must live under
/run/. Use this only for processes that always run on the same node as the database.
'Nodes IDs' — pin to specific nodes (optional)
By default the listen proxies to every node in the cluster with the group you picked. Set 'Nodes IDs' to restrict it to specific nodes. Those nodes must have that group.
'Load Balancing Method'
Controls how connections are spread. Default: 'Source IP Address', where a given client IP always goes to the same backend.
'Destination Cluster'
The cluster whose nodes are the backends. Usually the same cluster the listen lives on, but it does not have to be.
Cross-cluster proxying
Because 'Destination Cluster' can be a different cluster, a node on cluster A can expose a service running on cluster B.
Typical use: a dedicated application cluster talks to a dedicated database cluster, without the database nodes being reachable from the application network. The application cluster holds the HAProxy listen; the database cluster runs the actual MariaDB or PostgreSQL nodes.