우분투 실전 명령어 | ip route와 traceroute로 경로 문제 진단
외부 API 호출은 실패하는데 DNS는 정상이고 서버 자체도 살아 있는 상황이 자주 있습니다. 이럴 때는 라우팅 경로가 꼬였는지 먼저 확인해야 시간을 아낄 수 있습니다. ip route, ping, traceroute 조합으로 어디에서 막히는지 빠르게 좁힐 수 있습니다.
언제 쓰는가
- 서버에서 특정 대역으로만 통신이 안 될 때
- 기본 게이트웨이 변경 후 네트워크 장애가 발생했을 때
- VPN 터널을 붙인 뒤 트래픽이 엉뚱한 인터페이스로 나갈 때
- 방화벽 점검 전에 경로 자체가 맞는지 먼저 확인하고 싶을 때
바로 쓰는 명령어
# 현재 라우팅 테이블 확인
ip route
# 목적지까지 실제로 어떤 경로를 타는지 조회
ip route get 8.8.8.8
# 첫 관문인 게이트웨이 응답 확인
ping -c 4 192.168.0.1
# 외부 목적지까지 홉 단위 경로 확인
traceroute -n 8.8.8.8
핵심 옵션/패턴
- ip route: 커널 라우팅 테이블 전체를 보여주며 default 경로와 인터페이스를 즉시 확인할 수 있음
- ip route get 대상IP: 실제 패킷 전송 시 선택되는 src, dev, via 정보를 한 줄로 확인할 수 있음
- ping -c 4: 4회만 테스트해서 점검 시간을 짧게 유지함
- traceroute -n: DNS 역조회 없이 숫자 IP만 출력해서 지연 원인을 더 빠르게 파악함
- traceroute 결과에서 초반 홉이 멈추면 로컬 라우터나 내부망 문제일 가능성이 큼
명령 출력 예시
$ ip route
default via 192.168.0.1 dev ens18 proto dhcp src 192.168.0.20 metric 100
10.10.0.0/16 via 192.168.0.254 dev ens18
192.168.0.0/24 dev ens18 proto kernel scope link src 192.168.0.20
$ ip route get 8.8.8.8
8.8.8.8 via 192.168.0.1 dev ens18 src 192.168.0.20 uid 0
cache
$ traceroute -n 8.8.8.8
1 192.168.0.1 0.442 ms 0.401 ms 0.398 ms
2 10.20.0.1 1.982 ms 1.913 ms 1.877 ms
3 * * *
4 61.72.44.9 10.521 ms 10.473 ms 10.411 ms
자주 하는 실수
- ip route 출력에서 default 경로를 확인하지 않고 DNS 설정만 반복 점검하는 경우
- traceroute가 막히면 무조건 목적지 서버 장애라고 단정하는 경우
- 사설 대역 라우트를 추가해 놓고 재부팅 후 영구 설정을 안 해 다시 장애가 나는 경우
- ping 대상에 도메인만 사용해서 DNS 문제와 라우팅 문제를 혼동하는 경우
검증 방법
# 1) 기본 경로와 인터페이스 확인
ip route | grep default
# 2) 목적지별 실제 선택 경로 확인
ip route get 1.1.1.1
ip route get 10.10.10.10
# 3) 게이트웨이/외부 경로 단계별 점검
ping -c 2 192.168.0.1
traceroute -n 1.1.1.1 | head -15
# 4) 변경 후 재확인
ip route
운영 팁
- 장애 대응 때는 먼저 ip route get으로 경로 선택이 맞는지 확인하고, 그 다음 방화벽과 보안그룹으로 넘어가면 순서가 깔끔합니다.
- 라우트 임시 추가 테스트가 끝나면 netplan이나 systemd-networkd 설정에 영구 반영해 재부팅 리스크를 없애세요.
- 다중 NIC 서버는 traceroute 결과와 함께 ip -br a 출력을 같이 남겨 두면 사후 분석이 훨씬 빨라집니다.
출처
- iproute2 man pages
- Ubuntu Server Guide
- traceroute man page