Backend Pools¶
Backend pools define where Core sends allowed requests after routing and security decisions.
Syntax¶
POOL <pool_name>
LB_POLICY=<round_robin|least_conn>
SESSION_STICKY=<true|false>
STICKY_COOKIE=<cookie_name>
HEALTH_PATH=<path>
HEALTH_METHOD=<GET|HEAD|POST>
MEMBER <name> <host> <port> <http|https> weight=<number> enabled=<true|false> tls_verify=<true|false> sni=<hostname>
END
Example¶
POOL web_pool
LB_POLICY=round_robin
SESSION_STICKY=false
HEALTH_PATH=/health
HEALTH_METHOD=GET
MEMBER web1 app01.example.local 8443 https weight=1 enabled=true tls_verify=true sni=www.example.com
MEMBER web2 app02.example.local 8443 https weight=1 enabled=true tls_verify=true sni=www.example.com
END
Allowed keywords¶
| Keyword | Purpose |
|---|---|
POOL |
Starts a backend pool. |
LB_POLICY |
Load-balancing policy. |
SESSION_STICKY |
Enables cookie-based session affinity when supported. |
STICKY_COOKIE |
Cookie name for sticky routing. |
HEALTH_PATH |
Path used for health checks. |
HEALTH_METHOD |
Method used for health checks. |
MEMBER |
Backend member definition. |
END |
Ends the pool block. |
Best practices¶
- Use HTTPS to upstream applications when possible.
- Set
tls_verify=truein production when backend certificates are trusted. - Keep health paths lightweight.
- Avoid sending all traffic to a single backend unless intentionally testing.