도메인 연결 서비스가 간헐적으로 느린 이유

사용자가 보는 것과 개발자가 보는 것이 다르다

도메인 연결 문제는 대개 로컬에선 재현되지 않는다. 사용자가 느린 것은 DNS 해석, 캐시, 프록시 등 여러 계층을 통해 누적된 지연이기 때문이다.

user가 느린 증상을 보고하면, 먼저 세 가지를 기록한다.

1. 시간대: 언제부터 느린가
2. 범위: 모든 사용자가 느낀가, 특정 지역인가
3. 반복성: 매번 느린가, 간헐적인가

DNS 응답 시간을 본다

# DNS 쿼리 시간 측정
dig example.com

# 시간까지 포함해서 확인
dig +stats example.com

# 여러 번 반복해서 캐시 영향 확인
for i in {1..5}; do dig example.com | grep "Query time"; done

DNS 응답이 200ms 이상이면 이미 느린 것이다. 같은 도메인을 여러 번 쿼리할 때 시간이 일정하지 않다면 캐시가 제대로 작동 안 하는 것일 수 있다.

Nginx 프록시 규칙 확인

# Nginx 설정 문법 확인
sudo nginx -t

# 현재 적용된 설정 리로드 후 재확인
sudo nginx -s reload
sudo tail -f /var/log/nginx/access.log

프록시가 업스트림 서버를 제대로 찾지 못하거나, 연결 풀이 부족하면 간헐적 지연이 발생한다. 특히 upstream의 서버 상태를 확인한다.

# upstream 서버 상태 확인 (Nginx Plus의 경우)
curl http://localhost:8080/api/6/http/upstream/backend

HTTP 상태 코드 추적

# 마지막 접근 로그에서 응답 시간 확인
sudo tail -100 /var/log/nginx/access.log | \
  awk '{print $10, $NF}' | sort -rn | head -10

응답 시간이 갑자기 증가했다면, 그 시점의 서버 상태 (CPU, 메모리, 디스크)를 함께 본다.

캐시 헤더 설정

Browser나 CDN 캐시 설정이 없으면 매번 서버를 거쳐야 한다.

# 응답 헤더에서 캐시 정책 확인
curl -I https://example.com

# Cache-Control과 ETag를 확인
curl -i https://example.com | grep -E "Cache-Control|ETag|Last-Modified"

정적 자산은 캐시를 길게 (days 단위), 동적 콘텐츠는 적절히 (minutes 단위) 설정해야 한다.

환경별 차이 기록

개발 환경과 운영 환경의 설정을 나란히 놓고 비교한다.

# 로컬 테스트
curl -I http://localhost:3000

# 운영 환경
curl -I https://example.com

# 응답 헤더를 파일로 저장해서 diff
curl -i http://localhost:3000 > local.txt
curl -i https://example.com > prod.txt
diff local.txt prod.txt

헤더 구성, 캐시 정책, 압축 설정이 다를 수 있고, 그게 체감 속도 차이를 만든다.

최종 확인

개선을 적용한 후 같은 조건에서 다시 측정한다.

1. DNS 응답 시간이 줄었는가
2. 평균 응답 시간이 일정한가
3. 캐시가 제대로 작동하는가

이 정도 확인이 끝나면, 그 다음 느린 요청은 다른 원인일 가능성이 높다.