리눅스 시스템 엔지니어를 위한 필수 네트워크 트러블슈팅 명령어 총정리

네트워크 문제, 어디서부터 시작해야 할까?

리눅스 서버를 운영하다 보면 "갑자기 외부에서 접속이 안 된다", "특정 포트가 응답하지 않는다", "패킷이 어디선가 막힌다" 같은 상황을 반드시 마주치게 됩니다. 이럴 때 당황하지 않고 체계적인 순서로 명령어를 실행할 수 있느냐가 숙련된 엔지니어와 그렇지 않은 사람의 차이입니다.

이 글에서는 실무에서 자주 쓰는 네트워크 트러블슈팅 명령어를 레이어별로 정리하고, 각 명령어가 어떤 상황에서 유효한지 함께 설명합니다.

1단계 — 기본 연결 확인: ping / traceroute

가장 먼저 해야 할 건 물리적·논리적 연결 자체가 살아있는지 확인하는 것입니다.

ping

ICMP 패킷을 보내 응답 시간과 패킷 손실률을 확인합니다.

ping -c 4 8.8.8.8          # 4번만 보내고 종료
ping -i 0.2 -c 20 192.168.1.1  # 0.2초 간격으로 20번 전송

• 응답 없음: 방화벽에서 ICMP가 차단됐거나 호스트 자체가 다운된 상태
• 패킷 손실 발생: 네트워크 구간 어딘가에 불안정한 링크 존재
• RTT가 비정상적으로 높음: 대역폭 포화 또는 라우팅 문제 의심

traceroute / tracepath

패킷이 목적지까지 어느 경로로 이동하는지, 어느 구간에서 지연이 발생하는지 확인합니다.

traceroute -n 8.8.8.8        # DNS 조회 없이 IP로만 표시 (빠름)
tracepath google.com          # 루트 권한 없이 사용 가능

특정 홉(hop)에서 * * *가 반복된다면 해당 구간에서 패킷이 차단되거나 응답하지 않는 것입니다. 그 이후 홉이 정상이면 단순 ICMP 차단일 가능성이 높습니다.

2단계 — 인터페이스 및 라우팅 확인: ip / ss / netstat

ip 명령어

ifconfig는 구형 명령어입니다. 현대 리눅스에서는 ip 명령어를 사용하는 것이 표준입니다.

ip addr show                  # 전체 인터페이스 IP 확인
ip addr show eth0             # 특정 인터페이스만 확인
ip link show                  # 인터페이스 UP/DOWN 상태 확인
ip route show                 # 라우팅 테이블 전체 출력
ip route get 8.8.8.8          # 특정 목적지로 가는 경로 확인

ip route get은 특정 IP로 트래픽이 어느 인터페이스를 통해 나가는지 한 줄로 보여주는 매우 실용적인 명령어입니다.

ss — 소켓 상태 확인

netstat의 후속 명령어로 훨씬 빠르고 상세한 정보를 제공합니다.

ss -tlnp          # TCP 리스닝 포트 + 프로세스 이름
ss -ulnp          # UDP 리스닝 포트
ss -s             # 소켓 통계 요약
ss -tnp state established  # 현재 연결된 TCP 세션 전체

• -t: TCP, -u: UDP
• -l: 리스닝 상태만, -n: 숫자(IP/포트)로 표시, -p: 프로세스 정보 포함

3단계 — DNS 문제 진단: dig / nslookup / resolvectl

외부 접속이 안 될 때 DNS 해석 자체가 실패하는 경우가 생각보다 많습니다.

dig

가장 상세한 DNS 조회 결과를 보여주는 표준 도구입니다.

dig google.com                     # 기본 A 레코드 조회
dig google.com MX                  # MX 레코드 조회
dig @8.8.8.8 google.com            # 특정 DNS 서버(8.8.8.8)에 직접 질의
dig +short google.com              # IP 결과만 간단히 출력
dig +trace google.com              # 루트 DNS부터 전체 해석 과정 추적

dig +trace는 DNS 위임 체계 전체를 추적하므로, 특정 레코드가 왜 잘못 응답되는지 원인을 찾을 때 매우 유용합니다.

resolvectl (systemd-resolved 환경)

resolvectl status          # 현재 DNS 설정 및 상태 확인
resolvectl query google.com  # DNS 조회

4단계 — 포트 및 서비스 연결 확인: telnet / nc / curl

nc (netcat) — 포트 연결 테스트

특정 호스트의 포트가 열려있는지 가장 직접적으로 확인하는 방법입니다.

nc -zv 192.168.1.100 80       # TCP 포트 80 열려있는지 확인
nc -zv -u 192.168.1.100 53    # UDP 포트 53 확인
nc -zv 192.168.1.100 8080-8090  # 포트 범위 스캔

curl — HTTP/HTTPS 레벨 진단

curl -v https://example.com              # 전체 요청/응답 헤더 출력
curl -I https://example.com             # 헤더만 확인
curl -o /dev/null -w "%{http_code} %{time_total}s\n" https://example.com
# 응답코드와 응답시간만 출력
curl --resolve example.com:443:1.2.3.4 https://example.com
# 특정 IP로 강제 접속 (DNS 우회 테스트)

5단계 — 패킷 수준 분석: tcpdump

위 명령어로도 원인을 찾지 못했다면 실제 패킷을 직접 들여다봐야 합니다.

tcpdump -i eth0 -nn               # eth0 인터페이스 전체 패킷 캡처
tcpdump -i eth0 port 80 -nn       # 80 포트 트래픽만 필터
tcpdump -i eth0 host 192.168.1.100 -nn  # 특정 호스트 트래픽만
tcpdump -i eth0 -w /tmp/capture.pcap    # 파일로 저장 (Wireshark 분석용)

-nn 옵션은 DNS 역조회와 포트명 변환을 생략해 출력 속도를 높여줍니다. 실시간 트래픽이 많은 환경에서는 필수 옵션입니다.

트러블슈팅 흐름 정리

네트워크 문제를 만났을 때 아래 순서로 접근하면 빠르게 원인을 좁힐 수 있습니다.

• 1. ping — 기본 연결 확인
• 2. traceroute — 경로 및 지연 구간 확인
• 3. ip addr / ip route — 인터페이스, 라우팅 테이블 점검
• 4. ss -tlnp — 서비스가 포트를 정상적으로 리스닝하는지 확인
• 5. dig — DNS 해석 문제 여부 확인
• 6. nc / curl — 실제 포트 및 HTTP 응답 확인
• 7. tcpdump — 패킷 레벨 분석으로 최종 원인 규명

마무리

네트워크 트러블슈팅은 레이어를 낮춰가며 원인을 좁히는 과정입니다. 모든 명령어를 외울 필요는 없지만, 각 명령어가 OSI 어느 계층을 담당하는지 이해하고 있다면 문제 상황에서 빠르게 판단할 수 있습니다. 여기서 소개한 명령어들을 테스트 환경에서 직접 실행해보며 익혀두는 것을 강력히 권장합니다.