본문으로 건너뛰기

안동민 개발노트

본문 시작

핵심 진단 도구

ping·traceroute·dig·ss·curl의 출력과 한계를 이해하고 연결·경로·DNS·포트·HTTP 문제를 계층별로 확인합니다.

트러블슈팅 방법론을 세웠으면, 실제로 계층별 진단을 수행할 도구가 필요합니다.

이 절에서는 네트워크 진단의 핵심 도구를 다룹니다.

핵심 진단 도구는 계층별 질문에 답한다

ping은 도달성, traceroute는 경로, DNS 도구는 이름 해석, ss와 curl은 포트와 HTTP 상태를 보여줍니다.

  1. curl

    L7 curl HTTP 상태 코드·헤더·본문이 기대와 같은가?

  2. dig / nslookup

    NAME dig / nslookup 이름이 올바른 주소로 해석되고 TTL과 권한 응답이 정상인가?

  3. nc / ss

    L4 nc / ss 대상 포트가 열려 있고 연결 상태가 어디에서 멈췄는가?

  4. ping / traceroute

    L3 ping / traceroute 목적지까지 도달하며 지연·손실이 어느 홉에서 시작되는가?

  5. arp / tcpdump

    L2 arp / tcpdump 로컬 이웃을 찾고 실제 프레임·패킷이 인터페이스를 통과하는가?

ping — 연결 가능성 확인

ping 결과는 응답 여부보다 RTT와 손실을 함께 읽는다

ICMP Echo Reply가 오면 경로 생존을 확인할 수 있고, 지연·TTL·손실은 상태 변화를 보여줍니다.

  1. 18ms

    정상

  2. 22ms

    정상

  3. timeout

    손실

  4. 180ms

    지연 급증

  5. 20ms

    회복

ping은 ICMP Echo Request를 보내고 Echo Reply를 받는 가장 기본적인 진단 도구입니다.

ping 사용
ping google.com

# 결과 예시
PING google.com (142.250.196.110): 56 data bytes
64 bytes from 142.250.196.110: icmp_seq=0 ttl=116 time=3.2 ms
64 bytes from 142.250.196.110: icmp_seq=1 ttl=116 time=2.8 ms
ping 결과 해석
항목           의미                       정상 범위
──────────────────────────────────────────────────────
응답 여부      네트워크 경로 생존          응답 있음
time (RTT)    왕복 시간                   LAN: <1ms
                                         국내: <30ms
                                         해외: 100~300ms
ttl           경유 라우터 수 추정          64(Linux), 128(Win)
              도착TTL = 시작TTL - 홉수     에서 시작
패킷 유실      loss%                      0%가 정상

ping이 안 되더라도 반드시 서버가 죽은 것은 아닙니다.

많은 서버가 보안상 ICMP를 차단합니다.

AWS 보안 그룹의 기본 설정도 ICMP를 차단합니다.

traceroute / tracert — 경로 추적

traceroute 사용
traceroute google.com

# 결과 예시
 1  192.168.1.1 (192.168.1.1)    1.2 ms   1.0 ms   1.1 ms  ← 공유기
 2  10.0.0.1 (10.0.0.1)          5.3 ms   4.8 ms   5.1 ms  ← ISP 라우터
 3  72.14.215.85 (72.14.215.85)  8.1 ms   7.9 ms   8.3 ms  ← 백본
 4  * * *                                                    ← ICMP 차단
 5  142.250.196.110              12.5 ms  12.3 ms  12.1 ms  ← 목적지

TTL 값을 1부터 하나씩 증가시키며 패킷을 보냅니다.

TTL이 0이 되면 라우터가 ICMP Time Exceeded 메시지를 반환합니다.

traceroute 해석 가이드
패턴                      의미
──────────────────────────────────────────────
* * *                    ICMP 차단 (반드시 장애 아님)
홉 N에서 갑자기 >50ms     그 구간에 병목 의심
마지막 홉만 * * *         서버가 ICMP 차단
중간부터 전부 * * *        방화벽이 traceroute 차단

mtr(My Traceroute)은 ping과 traceroute를 결합한 도구로, 각 홉의 패킷 유실률과 지터를 실시간으로 보여주어 더 정밀한 경로 분석이 가능합니다.

nslookup / dig — DNS 진단

DNS 진단
# 기본 조회
nslookup example.com
# Server:  8.8.8.8
# Address: 93.184.216.34

# dig로 상세 조회
dig example.com +short          # IP만 간단히
dig example.com MX +short       # 메일 서버 확인
dig example.com +trace          # 루트부터 전체 해석 경로
dig @8.8.8.8 example.com        # 특정 DNS 서버로 질의

# DNS 문제 구분
ping 8.8.8.8       # ✓ 성공 → 인터넷 OK
nslookup google.com # ✗ 실패 → DNS만 문제
                    # → /etc/resolv.conf 확인

netstat / ss — 연결 상태 확인

ss 사용 (netstat 후속)
# 리슨 중인 TCP 포트 확인
ss -tlnp

# 결과 예시
State   Local Address:Port  Process
LISTEN  0.0.0.0:80          nginx
LISTEN  0.0.0.0:443         nginx
LISTEN  127.0.0.1:3000      node        ← localhost만 바인딩!
LISTEN  0.0.0.0:5432        postgres

# 활성 연결 확인
ss -tnp

# 연결 상태 요약
ss -s
# TCP:  152 (estab 43, closed 12, timewait 89)
# → TIME_WAIT 수천 개면 연결 관리 문제

# 특정 포트 연결 수 확인
ss -tn state established | grep :80 | wc -l

127.0.0.1:3000에 바인딩된 프로세스는 외부에서 접근 불가능합니다.

0.0.0.0:3000이어야 외부 접근이 가능합니다.

이것은 매우 흔한 실수입니다.

curl — HTTP 레벨 디버깅

curl은 DNS부터 첫 바이트까지 HTTP 요청 시간을 쪼개 보여준다

전체 시간이 느릴 때 어느 단계가 느린지 분리하면 DNS, TCP, TLS, 서버 처리 중 원인 후보가 좁혀집니다.

  1. 1
    time_namelookup

    DNS time_namelookup 이름 해석 완료

  2. 2
    time_connect

    TCP time_connect 3-way handshake 완료

  3. 3
    time_appconnect

    TLS time_appconnect HTTPS 핸드셰이크 완료

  4. 4
    processing

    Server processing 요청 처리 대기

  5. 5
    time_starttransfer

    TTFB time_starttransfer 첫 바이트 도착

curl 디버깅 기법
# 1. 상세 모드 — 전체 과정 표시
curl -v https://example.com
# * Trying 93.184.216.34:443...
# * Connected to example.com port 443
# * TLS 1.3 handshake
# > GET / HTTP/2
# < HTTP/2 200

# 2. 응답 시간 분석
curl -o /dev/null -s -w "\
    DNS:        %{time_namelookup}s\n\
    TCP:        %{time_connect}s\n\
    TLS:        %{time_appconnect}s\n\
    첫바이트:    %{time_starttransfer}s\n\
    총시간:      %{time_total}s\n\
    상태코드:    %{http_code}\n" https://example.com

# 3. DNS 우회 (IP 직접 지정)
curl --resolve example.com:443:1.2.3.4 https://example.com

# 4. 헤더만 확인
curl -I https://example.com

# 5. 리다이렉트 추적
curl -L -v https://example.com

-w 옵션의 시간 분석은 특히 유용합니다.

DNS 해석에 2초가 걸리면 DNS 문제, TCP 연결에 오래 걸리면 네트워크 문제, 첫 바이트까지 오래 걸리면 서버 처리 문제입니다.

시간 항목의미정상 범위
time_namelookupDNS 해석<50ms
time_connectTCP 연결<100ms
time_appconnectTLS 완료<200ms
time_starttransfer첫 바이트<500ms
time_total전체용도에 따라

다음 절에서는 패킷 캡처를 기반으로 통신 흐름을 확인하는 패킷 분석을 다루겠습니다.

진단 도구 결과는 서로 검증해야 한다

한 도구의 결과만으로 결론을 내리지 말고, 계층을 바꿔 같은 가설을 확인합니다.

  1. 도달성

    ping 도달성 ICMP 응답

  2. HTTP 시간

    curl HTTP 시간 상태 코드와 TTFB

  3. 패킷 증거

    tcpdump 패킷 증거 SYN/ACK/RST

  4. 서버 처리

    log 서버 처리 요청 ID

핵심 진단 도구에서는 프로토콜 상태, 실패 응답, 관측 도구, 복구 기준을 확인합니다.

도구 보충 점검은 관측 위치를 명확히 해야 한다

내 컴퓨터, 프록시 앞단, 서버 내부에서 같은 명령을 실행하면 서로 다른 사실을 보여준다.

  1. Client curl, dig, traceroute

    사용자 체감과 DNS/경로

  2. Edge/LB access log, health

    check 진입 성공과 target 선택

  3. Server ss, tcpdump, app log

    listen 상태와 요청 처리

  4. Container nsenter, ip route

    namespace 안 실제 경로

트러블슈팅 방법론

이전 페이지

패킷 분석

다음 페이지

이 페이지의 목차

ping — 연결 가능성 확인traceroute / tracert — 경로 추적nslookup / dig — DNS 진단netstat / ss — 연결 상태 확인curl — HTTP 레벨 디버깅