[Infra Ops] HTTP 요청이 서버에 도달하기까지의 전체 흐름

브라우저가 https://example.com을 요청하는 순간, OS는 IP 주소를 알아내기 위해 순서대로 다음 위치를 조회합니다.

IP를 변경했는데 일부 사용자만 계속 구 서버로 접속하는 문제가 있었습니다. DNS TTL이 아직 살아있어 캐시된 IP를 사용하고 있었기 때문입니다. 개발팀에서 /etc/hosts에 테스트 서버 IP를 등록해뒀다가 실수로 운영 서버에도 같은 파일을 배포해 트래픽이 엉뚱한 서버로 가기도 합니다. DNS가 어떻게 동작하는지 모르면 이런 상황에서 원인조차 찾을 수 없습니다.

1단계 — /etc/hosts 우선 조회

OS가 가장 먼저 확인하는 곳입니다. 파일에 도메인-IP 매핑이 있으면 DNS 서버로 질의를 보내지 않고 즉시 사용합니다.

# /etc/hosts 예시
127.0.0.1   localhost
192.168.1.50  internal-api.company.com

이 특성을 알면 두 가지 실수를 이해할 수 있습니다. 개발계에서 /etc/hosts에 내부 도메인을 추가해뒀다가 운영계에서 그 항목 때문에 잘못된 서버로 요청이 가는 경우, 반대로 장애 대응 중 hosts를 수정했지만 다른 서버에는 반영 안 된 경우가 대표적입니다.

2단계 — /etc/resolv.conf로 DNS 서버 지정

/etc/hosts에 항목이 없으면 /etc/resolv.conf에 기록된 DNS 서버로 질의를 보냅니다.

# /etc/resolv.conf 예시
nameserver 8.8.8.8       # 첫 번째로 질의할 DNS 서버
nameserver 8.8.4.4       # 첫 번째 실패 시 대체
search company.com       # 짧은 호스트명에 자동으로 붙이는 도메인

DNS 질의 흐름 — 캐시 → 재귀 질의

DNS 서버가 응답을 갖고 있으면 캐시에서 즉시 반환합니다. 없으면 루트 DNS → TLD DNS → 권한 DNS 순으로 재귀 질의를 수행합니다.

TTL(Time To Live)과 DNS 전파

DNS 레코드에는 TTL이 설정돼 있습니다. TTL이 300이면 5분 동안 캐시가 유지됩니다. IP를 변경해도 기존 TTL이 만료되기 전까지는 옛 IP로 요청이 갈 수 있습니다. "도메인 바꿨는데 일부 사용자만 반영이 안 된다"는 이 TTL 때문입니다.

내부 DNS vs 공인 DNS

사내 서비스는 공인 DNS에 등록하지 않습니다. 내부 DNS 서버를 따로 운영하거나 /etc/hosts를 사용해 내부 도메인을 해석합니다. 인프라 엔지니어는 내부 DNS 레코드 추가 요청을 자주 받습니다.

Nginx 접근 로그에서 모든 IP가 같은 주소로 찍히는 현상이 있었습니다. 앞에 L7 로드밸런서가 있는데 X-Forwarded-For 헤더 설정이 없어서 Nginx 입장에서는 모든 요청이 LB에서 오는 것처럼 보였기 때문입니다. 클라이언트 IP를 모르면 특정 사용자 문제 추적도, 보안 차단도 불가능해집니다. L4와 L7의 동작 방식 차이가 IP 보존 방법을 결정합니다.

L4 로드밸런서 — IP:Port 기반 라우팅

L4 LB는 패킷의 IP 주소와 포트만 보고 라우팅합니다. HTTP 헤더를 읽지 않습니다. 처리 속도가 빠르지만 URL 경로나 헤더 기반 라우팅은 불가능합니다.

클라이언트 IP 보존 방법으로 DSR(Direct Server Return)이나 프록시 프로토콜을 사용하지만, 설정이 없으면 서버에서 보이는 $remote_addr은 LB의 IP가 됩니다.

L7 로드밸런서 — HTTP 헤더 기반 라우팅

L7 LB는 HTTP 요청 전체를 읽습니다. URL 경로, 쿠키, 헤더 값에 따라 다른 서버로 보낼 수 있습니다.

L7 LB가 요청을 백엔드로 전달할 때 원래 클라이언트 IP를 헤더에 담아 보냅니다.

Nginx의 access_log에서 $remote_addr은 LB의 IP를, $http_x_forwarded_for는 실제 클라이언트 IP를 출력합니다.

WAF(Web Application Firewall)

대부분의 L7 LB 앞단이나 내부에 WAF가 위치합니다. SQL Injection, XSS, 비정상 요청 패턴을 탐지해 차단합니다. WAF가 요청을 차단하면 클라이언트에게 403이 반환되고 Nginx에는 요청이 도달하지 않습니다. "서버는 정상인데 403이 떨어진다"면 WAF 차단 로그를 먼저 확인해야 합니다.

SSL 종료 위치

SSL(TLS)을 어디서 끊느냐는 보안 정책과 운영 편의성의 균형입니다.

내부망이 신뢰 가능하면 LB에서 종료하는 것이 일반적입니다.

Nginx는 단순한 정적 파일 서버가 아니라 요청을 받아 어디로 보낼지 결정하는 트래픽 제어 지점입니다. location 블록 매칭 규칙을 모르면 특정 경로의 502 원인을 찾는 데 한참이 걸리고, access_log의 upstream 변수를 읽지 못하면 어느 Tomcat 인스턴스에 문제가 생겼는지 파악할 수 없습니다. Nginx 설정과 로그 구조를 이해하는 것이 요청 흐름 추적의 핵심입니다.

요청 수신 → server 블록 → location 블록

특정 API 경로만 502가 났는데 Tomcat은 살아있었습니다. Nginx 설정을 확인하니 해당 경로의 location 블록이 Tomcat이 아닌 다른 upstream을 바라보고 있었습니다. location 블록 매칭 규칙을 몰라서 어떤 요청이 어디로 가는지 파악하지 못했기 때문입니다. access_log의 $upstream_addr을 읽을 수 있으면 요청이 어느 Tomcat으로 갔는지 1분 안에 확인할 수 있습니다.

Nginx는 도착한 요청의 Host 헤더와 URL 경로를 보고 어떻게 처리할지 결정합니다.

server {
    listen 80;
    server_name example.com;

    # 정적 파일 직접 서빙
    location /static/ {
        root /var/www/html;
    }

    # 동적 요청은 Tomcat으로 전달
    location /api/ {
        proxy_pass http://tomcat_upstream;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

upstream tomcat_upstream {
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    keepalive 32;          # 커넥션 재사용 (매 요청마다 TCP 연결 새로 맺지 않음)
}

정적 파일 vs proxy_pass

• 정적 파일(.html, .js, .css, 이미지): Nginx가 디스크에서 직접 읽어 응답. Tomcat까지 가지 않습니다.
• /api/ 경로: proxy_pass로 Tomcat에 전달. Nginx는 중간 전달자 역할.

access_log에서 읽을 수 있는 정보

# 기본 log_format에 upstream 정보 추가
log_format main '$remote_addr - $request - $status - $upstream_addr - $upstream_response_time - $http_x_forwarded_for';

$upstream_response_time이 길어지기 시작하면 Nginx-Tomcat 구간이 아니라 Tomcat 내부(또는 DB)가 느린 것입니다.

Nginx는 빠른데 응답이 느리다는 제보가 왔습니다. Nginx $upstream_response_time을 보니 30초가 찍혀 있었고, Tomcat catalina.out에는 DB 커넥션 타임아웃 오류가 가득했습니다. 문제는 Nginx-Tomcat 구간이 아니라 Tomcat-DB 구간이었습니다. 어느 단계에서 시간이 소비되는지 알아야 정확한 원인을 찾을 수 있습니다.

요청 처리 순서

Tomcat 수신
  → Filter 체인 (인증, 로깅, CORS 등)
    → Dispatcher Servlet
      → Controller (URL 매핑)
        → Service (비즈니스 로직)
          → Repository / DAO
            → DB Connection Pool에서 커넥션 획득
              → SQL 실행 → DB 응답
            → 커넥션 반환 (Pool로 되돌림)
          ← 결과 반환
        ← DTO 조립
      ← JSON 직렬화
    ← HTTP 응답
  ← Nginx로 반환
← 클라이언트에 전달

DB Connection Pool

Tomcat은 매 요청마다 DB에 새로 연결하지 않습니다. 미리 만들어둔 커넥션 Pool에서 빌려 쓰고 반납합니다. Pool의 커넥션이 모두 사용 중이면 요청은 대기 상태가 됩니다. 이 대기가 쌓이면 Tomcat 응답 시간이 길어지고 결국 Nginx에서 타임아웃이 발생해 502가 됩니다.

각 단계별 로그 위치

응답은 역순으로 반환됩니다. DB → Repository → Service → Controller → Tomcat → Nginx → LB → 클라이언트. 각 구간에서 처리 시간이 누적됩니다.