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 | 전체 | 용도에 따라 |
다음 절에서는 패킷 캡처를 기반으로 통신 흐름을 확인하는 패킷 분석을 다루겠습니다.
핵심 진단 도구에서는 프로토콜 상태, 실패 응답, 관측 도구, 복구 기준을 확인합니다.
핵심 진단 도구에서 놓치기 쉬운 기준은 보충 점검 항목으로 다시 확인합니다.