Traffic shaping

Rate limiting and IP lists are only as correct as the address they key on, so configure client_ip first if anything sits in front of dash-proxy. With no trusted_proxies, the client is always the address that opened the connection — nothing a client sends can influence it. Once you declare trusted_proxies (and only when the connecting address is one of them), the proxy walks the forwarded chain backwards past every proxy you declared; the first address none of them wrote is the client. List every hop — a chain the proxy cannot resolve denies the request rather than falling back.

A per-client token bucket; requests over the limit get a 429. IPv6 clients are counted per /64, since one client can pick any address inside its own.

An address on both lists is denied, and denied clients never spend rate-limit budget. User-agent patterns are checked after the IP rules; a missing User-Agent only matches an explicit ^$ pattern.

Two enforcement notes, straight from the config validation:

• The health check path is served without an address check or a rate limit, so it stays reachable during a deploy — which is why dash rejects healthcheck: path: / while either feature is on.
• With a load balancer, all of this moves to the load balancer: an allow list on the per-host proxies would refuse every request (they only ever see the load balancer), and one rate limiter would count the whole fleet as a single client.

response_timeout bounds how long the app may take to start answering — its clock stops once response headers arrive. request_timeout bounds the whole request, including streaming the body back. They are not interchangeable: a slow trickle of body bytes never trips response_timeout, because the app answered promptly. WebSocket and event-stream responses are exempt from request_timeout.

read_routing splits traffic between the deployed (writer) targets and read-only targets — app instances backed by database replicas. Read requests go to the read targets; writes always go to the writers, and writer_affinity_timeout keeps a client's reads on the writer briefly after it writes, so clients always read their own writes.

Affinity is off by default, rightly — it exists for apps holding session state in the instance. When a pinned target leaves the pool, the next request falls through and re-pins, so a deploy strands nobody. With a load balancer, both features are decided there — the only layer that sees the whole fleet.

Stop the service's containers after after seconds with no traffic, and start them again on the next request, which is held until they are healthy. Health checks and the proxy's own TLS probes are not traffic and never wake a sleeping service.