14장 : 네트워크 트러블슈팅
핵심 진단 도구
트러블슈팅 방법론을 세웠으면, 실제로 계층별 진단을 수행할 도구가 필요합니다. 이 절에서는 네트워크 진단의 핵심 도구를 다룹니다.
ping — 연결 가능성 확인
ping은 ICMP Echo Request를 보내고 Echo Reply를 받는 가장 기본적인 진단 도구입니다.
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항목 의미 정상 범위
──────────────────────────────────────────────────────
응답 여부 네트워크 경로 생존 응답 있음
time (RTT) 왕복 시간 LAN: <1ms
국내: <30ms
해외: 100~300ms
ttl 경유 라우터 수 추정 64(Linux), 128(Win)
도착TTL = 시작TTL - 홉수 에서 시작
패킷 유실 loss% 0%가 정상ping이 안 되더라도 반드시 서버가 죽은 것은 아닙니다. 많은 서버가 보안상 ICMP를 차단합니다. AWS 보안 그룹의 기본 설정도 ICMP를 차단합니다.
traceroute / tracert — 경로 추적
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 메시지를 반환합니다.
패턴 의미
──────────────────────────────────────────────
* * * ICMP 차단 (반드시 장애 아님)
홉 N에서 갑자기 >50ms 그 구간에 병목 의심
마지막 홉만 * * * 서버가 ICMP 차단
중간부터 전부 * * * 방화벽이 traceroute 차단mtr(My Traceroute)은 ping과 traceroute를 결합한 도구로, 각 홉의 패킷 유실률과 지터를 실시간으로 보여주어 더 정밀한 경로 분석이 가능합니다.
nslookup / dig — 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 — 연결 상태 확인
# 리슨 중인 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 -l127.0.0.1:3000에 바인딩된 프로세스는 외부에서 접근 불가능합니다. 0.0.0.0:3000이어야 외부 접근이 가능합니다. 이것은 매우 흔한 실수입니다.
curl — HTTP 레벨 디버깅
# 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_namelookup | DNS 해석 | <50ms |
| time_connect | TCP 연결 | <100ms |
| time_appconnect | TLS 완료 | <200ms |
| time_starttransfer | 첫 바이트 | <500ms |
| time_total | 전체 | 용도에 따라 |
다음 절에서는 가장 강력한 진단 도구인 패킷 분석을 다루겠습니다.