Envoy Health Checks: Active, Passive, Filters, and Connection‑Pool Interaction

Envoy supports both active and passive health checking mechanisms that can be configured per upstream cluster. Active checks include three types—HTTP, L3/L4, and Redis—each with customizable intervals, failure thresholds, and success thresholds.

For HTTP health checks, Envoy sends an HTTP request to the upstream host and expects a 200 response for a healthy host or a 503 to immediately stop forwarding traffic. L3/L4 checks send a configurable byte buffer and expect the same buffer in response if the host is healthy. Redis checks send a PING command and expect a PONG response; any other response triggers an immediate failure.

Passive health checking is performed by Envoy through anomaly detection, allowing it to mark hosts unhealthy based on observed runtime behavior without explicit probes.

When deploying an Envoy mesh, the volume of health‑check traffic can be large. Envoy includes an HTTP health‑check filter that can be installed on configured HTTP listeners. The filter operates in three modes:

Bypass: health‑check requests never reach the local service; Envoy replies with 200 or 503 based on its own health state.

Forward: requests are forwarded to the local service, which returns 200 or 503 according to its health.

Cache: requests are forwarded, but the result is cached for a configurable period, reducing load on the service while still providing up‑to‑date health information.

Envoy also supports fast‑fail for active checks. When the x-envoy-immediate-health-check-fail header is set by an upstream host, Envoy immediately marks the host as failed without waiting for the next scheduled check.

Health‑check identity can be enforced by configuring a service_name option. Envoy then compares the x-envoy-upstream-healthchecked-cluster response header with the configured service name, rejecting the check if they differ.

Connection pooling in Envoy abstracts the underlying transport (HTTP/1.1 or HTTP/2). HTTP/1.1 pools acquire connections as needed, do not pipeline, and reset downstream requests if the upstream connection is broken. HTTP/2 pools maintain a single multiplexed connection per upstream host, creating a new connection if a GOAWAY frame is received or the stream limit is reached; HTTP/2 is preferred for its stability.

If a host becomes unhealthy, Envoy closes all its connection‑pool connections. When the host returns to a healthy state, a new connection pool is created, minimizing the impact of bad traffic caused by routing anomalies.