Direct Server Return (DSR)

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