In what order do Envoy HTTP filters run?

On the request (decode) path filters run top to bottom in the order they appear in the chain. On the response (encode) path they run in reverse, bottom to top. So a filter added last sees the response first and the request last.

Why must the router filter be last?

The router is the terminal filter: it selects an upstream cluster and forwards the request, ending decode iteration. Any filter after it in the chain would never run on the request path, so Envoy requires envoy.filters.http.router to be the final entry.

What is the difference between ext_authz and jwt_authn?

jwt_authn validates a JWT locally against configured providers and exposes its claims, while ext_authz delegates the allow or deny decision to an external authorization service over gRPC or HTTP. They are often combined: jwt_authn verifies the token, then ext_authz applies richer policy.

How do filters control the chain?

Each filter callback returns a status: Continue passes control to the next filter, StopIteration pauses the chain (for example to buffer the body), and StopAllIterationAndBuffer additionally buffers data. This is how a filter waits for the full request body before deciding.

What is the difference between local_ratelimit and ratelimit?

local_ratelimit enforces a token-bucket limit independently inside each Envoy instance with no external dependency. ratelimit calls a shared external rate limit service (RLS) so the limit is global across all instances, at the cost of a network round trip per decision.

Envoy HTTP Filter Phases

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

The Envoy HTTP filter chain

Envoy processes every HTTP request through an ordered chain of filters in its HTTP Connection Manager. Filters run in two directions — decode on the way in, encode on the way out — and the chain always ends in the terminal router filter. This reference lists the phases and a catalogue of the most common built-in filters.

How it works

A request flows down the chain through the decode phases, hits the router which forwards it upstream, and the response flows back up through the encode phases in reverse order:

decodeHeaders -> decodeData -> decodeTrailers -> [router] upstream
encodeHeaders <- encodeData <- encodeTrailers <- upstream response

Each filter implements callbacks for these phases and returns a status (Continue, StopIteration, StopAllIterationAndBuffer) to control flow. Many filters touch only headers; others buffer the body. Because encode runs in reverse, ordering matters: place authentication before transcoding, and rate limiting before the router.

Tips and notes

The router filter (envoy.filters.http.router) is terminal and must be last in the chain.
Order auth filters (jwt_authn, ext_authz, rbac) early so unauthorised requests stop quickly.
local_ratelimit is per-instance and dependency-free; ratelimit is global via an external RLS.
Transform filters like grpc_json_transcoder and wasm sit between auth and the router.