프록시 설계에서는 먼저 무엇을 한 단위로 분산하는지와 애플리케이션이 누구를 신뢰하는지를 분리합니다. L4는 연결 중심으로 전달하고 L7은 요청을 볼 수 있지만, 전달 헤더의 원래 값은 외부 입력일 수 있으므로 실제 peer와 신뢰된 재작성 경계를 함께 확인해야 합니다.
연결 수와 요청·CPU 부하의 불일치
서버 A와 B에 각각 TCP 연결 50개를 보냈다고 합시다. A의 한 HTTP/2 연결이 초당 만 요청을 보내고 B의 연결은 대부분 유휴라면 연결 수는 균등하지만 요청량·CPU는 다릅니다. L4 분산은 주로 연결·전송 계층 정보를 기준으로 하므로 연결 안의 요청 비용을 모두 알지 못합니다.
L7 프록시는 HTTP 요청·경로·헤더를 이해해 요청이나 스트림 단위 정책을 적용할 수 있습니다. 하지만 실제 프로토콜·session affinity·upstream 풀에 따라 분산 단위는 달라집니다. L7로 바꾸면 모든 편중이 사라진다고 보장하지 않습니다.
L4·L7 프록시 비용과 연결 종료 책임
| 선택 | 가능한 역할 | 추가 비용·계약 |
|---|---|---|
| L4 | 연결 단위 전달·분산 | 긴 연결의 고정·전송 상태 |
| L7 | 경로·헤더 라우팅·요청 관측 | TLS 종료·파싱·버퍼·CPU |
| 세션 고정 | 상태가 있는 backend 유지 | 편중·장애 시 상태 복구 |
새 backend가 생겨도 이미 열린 TCP 연결은 자동으로 이동하지 않습니다. 제거할 때도 새 배정 중단과 기존 연결·스트림 drain을 분리합니다. health 성공은 특정 probe의 성공이지 모든 기능과 DB가 정상이라는 증거가 아닙니다. 스트리밍·WebSocket의 장기 연결과 종료 기한도 확인해야 합니다.
그림을 글로 읽기
- 외부 클라이언트: 임의 전달 헤더를 보낼 수 있음
- 신뢰된 경계 프록시: 헤더 제거·재작성 · TLS·라우팅·버퍼 정책
- 애플리케이션: 실제 peer 확인 · 인가·작업 실행
- 외부 클라이언트 → 신뢰된 경계 프록시: 외부 연결
- 신뢰된 경계 프록시 → 애플리케이션: 신뢰된 내부 경로
X-Forwarded-For 첫 값과 신뢰 경계
클라이언트가 X-Forwarded-For: 1.2.3.4를 직접 넣고 프록시가 뒤에 실제 주소를 추가할 수 있습니다. 앱이 맨 왼쪽을 무조건 믿으면 사용자가 주소를 선택하게 됩니다. 경계 프록시가 외부 전달 헤더를 제거하거나 명시적인 재작성 규칙을 적용하고 앱은 신뢰한 peer·hop 범위로 해석해야 합니다.
프록시 체인이 바뀌면 고정된 hop 개수나 첫·마지막 값 규칙도 달라질 수 있습니다. 신뢰할 프록시 목록과 parsing을 한곳에 두고 IPv6·중복 필드·잘못된 값도 검사합니다. 표준 Forwarded 형식을 쓴다는 사실만으로 그 값이 신뢰되는 것은 아닙니다.
직접 backend 경로와 프록시 정책 우회
앱에 외부가 직접 접속할 수 있는데 프록시 헤더를 항상 믿으면 경계 프록시의 검사를 건너뛸 수 있습니다. 네트워크 접근을 제한하거나 실제 peer가 신뢰된 프록시가 아닐 때 헤더를 신뢰하지 않아야 합니다.
Forwarded-Proto·Host도 HTTPS 판정·외부 링크 생성에 영향을 줍니다. 비밀번호 재설정 URL 같은 것은 요청 Host를 무조건 반영하지 말고 신뢰된 서비스 설정의 허용 origin으로 만듭니다. IP는 NAT·VPN으로 여러 사용자가 공유할 수 있으므로 인증·자원 인가를 대신하지 않습니다.
backlog의 수락 전 대기와 처리량 한계
listen backlog는 OS의 수락 대기 큐와 관련된 값입니다. SYN 처리와 연결 완료 후 accept 대기의 구분·실제 상한은 플랫폼별로 확인해야 합니다. 앱이 느리게 accept하거나 FD·worker가 고갈되면 큐만 늘려도 지속 처리 능력은 늘지 않습니다.
순간 burst 뒤 유입이 내려오면 큐가 흡수에 도움이 될 수 있지만, 유입이 처리율을 계속 넘으면 더 늦게 실패할 뿐입니다. accept를 빨리 한 뒤 무제한 앱 큐에 쌓으면 병목이 커널에서 앱 메모리로 옮겨갑니다. 수락 전후의 큐·바이트·실행 상한을 함께 둡니다.
프록시 분산 단위와 보안 신뢰 경계의 통합 검사
재현할 때 같은 연결에서 요청 수만 크게 바꾸어 연결 수와 CPU·stream 수가 분리되는지 보고, 외부 client가 넣은 X-Forwarded-For는 앱의 최종 client 주소로 그대로 남지 않아야 합니다. 직접 backend 경로에서는 전달 헤더를 신뢰하지 않거나 접근 자체가 거절되는 것이 예상 결과입니다.
큰 요청·작은 요청·장기 연결·새 backend 추가·drain을 섞어 연결 수, stream 수, CPU, 응답 바이트, 지연을 따로 비교합니다. 위조 전달 헤더, 직접 backend 접속, 추가 프록시 hop을 넣어 해석된 client IP와 실제 peer가 정책대로 기록되는지 확인합니다.
로그에 주소를 남길 때도 개인정보 보관·접근 범위를 제한합니다. L7 전환은 단순한 성능 옵션이 아니라 요청 분산과 신뢰·종료 경계를 바꾸는 설계입니다.