로드밸런서 Proxy와 DSR 차이: 응답 경로·원본 IP·구성 조건

Full Proxy는 클라이언트와 서버 연결을 나누어 중계하고, DSR(Direct Server Return)은 서버 응답이 로드밸런서를 직접 거치지 않게 구성합니다. One-Arm·In-Line은 배치 용어이며 이 처리 방식과 일대일로 대응하지 않습니다. NAT 기반 전달과 Full Proxy도 같은 개념은 아닙니다.

요청과 응답 흐름 비교

Full Proxy
클라이언트 ↔ 로드밸런서 ↔ 실제 서버
           연결 1        연결 2

일반적인 Direct Routing 방식의 DSR
요청: 클라이언트 → VIP/로드밸런서 → 실제 서버
응답: 실제 서버(VIP를 출발지로 사용) → 클라이언트

위 도식은 개념 설명입니다. DSR에는 직접 라우팅·터널 등 구현 차이가 있고, Full Proxy에서도 원본 주소를 전달하는 방식은 제품·프로토콜별로 다릅니다.

DSR의 서버·네트워크 조건

일반적인 같은 L2 구간의 Direct Routing 예에서는 서버가 VIP로 들어온 패킷을 로컬에서 처리하고 응답 출발지를 VIP로 유지해야 합니다. 서버가 VIP에 대한 ARP 응답을 잘못 보내 트래픽을 가로채지 않도록 제어하는 것도 중요합니다. 터널 방식 등에 이 조건을 그대로 복사하면 안 됩니다.

서버의 VIP 수신·바인딩과 반환 라우팅이 맞는가?
VIP의 ARP 응답 주체가 의도한 로드밸런서인가?
방화벽·역방향 경로 검사·클라우드 네트워크가 비대칭 경로를 허용하는가?
서버 자체와 같은 내부망에서 VIP로 접속하는 경우도 검증했는가?

무엇을 기준으로 선택하나요?

요구	설계에서 확인할 것
응답 대역폭이 큼	DSR의 응답 우회 이점과 네트워크·관측 복잡도를 함께 비교
TLS 종료·HTTP 정책	로드밸런서가 실제로 처리해야 하는 계층과 지원 기능
원본 IP 필요	서버가 보는 주소, 신뢰할 프록시 헤더·PROXY protocol 등 애플리케이션 지원
장애 분석	응답이 지나가는 서버·게이트웨이에서도 관측 가능한지

요청은 들어오는데 응답이 없을 때

가상 점검 예로 로드밸런서에 요청 기록이 있고 서버도 요청을 받았는데 클라이언트가 시간 초과라면, 서버가 VIP 출발지로 응답하는지와 반환 경로의 방화벽을 확인합니다. 요청 경로의 로드밸런서 캡처만으로 응답 부재를 단정하면 안 됩니다.

과거 글의 “서비스 A와 B가 서로 통신하면 DSR로는 불가능하다”는 설명은 일반화할 수 없습니다. 내부 클라이언트의 경로와 구현 조건을 개별 검증해야 합니다. 운영 중 NAT·VIP·ARP 정책을 즉시 바꾸기보다 현재 주소 흐름을 먼저 기록하세요.

함께 읽기

In-Line과 One-Arm 배치 설계에서 관련 개념을 이어서 확인할 수 있습니다.