Aliases: DSR
Direct Server Return (DSR)
Direct Server Return — load-balanced requests arrive via the balancer, but responses bypass it entirely, straight from server to client. Huge asymmetric-traffic win, real operational sharp edges.
Last reviewed: July 25, 2026
What is Direct Server Return?
In ordinary load balancing, both directions traverse the balancer. DSR breaks the symmetry: the balancer forwards the request to a backend (typically at layer 2/3, leaving the client’s destination IP — the VIP — intact), and the backend answers the client directly, spoofing the VIP as its source address. Each backend holds the VIP on a loopback interface (with ARP suppressed) so it accepts and answers for an address it never advertises.
Why bother: the asymmetry argument
Most serving traffic is wildly asymmetric — a 200-byte request pulls a megabyte response. Under DSR the balancer touches only the small inbound half, multiplying its effective capacity by orders of magnitude for download-heavy workloads: video delivery, object storage frontends, software mirrors. This is why DSR variants power serious L4 fabrics (IPVS in DSR mode; Google’s Maglev/katran-style designs share the return-path philosophy).
What you give up
The balancer never sees responses, so anything requiring response inspection or modification is off the table: no TLS termination at the LB, no response rewriting, no L7 routing on the return, and health checking must be active-probe rather than response-observed. Same-subnet L2 constraints (classic DSR) or tunneling complexity (IPIP-based DSR) bind topology. And debugging asymmetric paths is genuinely harder — packet captures at the balancer show half a conversation, confusing every engineer who hasn’t met DSR before.
What people get wrong
- Reaching for DSR on API traffic — symmetric request/response with TLS termination needs a proxying LB; DSR shines on bulk asymmetric flows.
- Skipping the ARP suppression on backend loopbacks: two devices answering for the VIP is an instant intermittent outage.
- Forgetting stateful middleboxes: firewalls between client and backend that never saw the inbound SYN drop the “unsolicited” return traffic.
Primary source: Linux Virtual Server documentation — LVS/DR
Why DSR Suits Asymmetric Traffic Patterns
DSR is particularly valuable for workloads where response payloads are dramatically larger than requests — video streaming or large file downloads, for example — since routing only the small inbound request through the load balancer while letting the much larger response bypass it entirely avoids the load balancer becoming a bandwidth bottleneck for the majority of the actual data volume. The operational tradeoff is that DSR requires more careful network configuration (the backend servers need to be configured to respond using the load balancer’s virtual IP as the source address) and complicates certain features like SSL termination and detailed request/response logging at the load balancer, since it never sees the full round trip — which is why DSR is a specialized technique reserved for specific high-bandwidth, asymmetric-traffic scenarios rather than a general-purpose load balancing default.
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.