리눅스 mtr 명령어 사용법 - 홉별 패킷 손실 추적과 리포트 모드

이 명령어를 언제 쓰는가

traceroute는 한 번 찍고 끝난다. 그런데 실무에서 마주치는 네트워크 문제는 "아예 안 된다"보다 "가끔 끊긴다"가 훨씬 많다. 간헐적 손실은 한 번 찍어서는 안 잡힌다. mtr은 경로상의 모든 홉에 계속 프로브를 보내며 홉별 손실률과 지연을 실시간으로 갱신해준다.

회선 사업자나 클라우드 지원팀에 장애를 제기할 때도 mtr 리포트가 사실상 표준 증빙이다. "느려요"가 아니라 "7번 홉부터 손실 12%가 100회 중 지속 관측됨"이라고 말할 수 있어야 대화가 진행된다.

Ubuntu/Debian은 apt install mtr-tiny(콘솔 전용) 또는 mtr, RHEL/Rocky는 dnf install mtr로 설치한다. 기본 설치되는 배포판은 거의 없다.

기본 형식

mtr [옵션] 목적지

옵션 없이 실행하면 전체 화면 대화형 모드로 들어가 계속 갱신된다. q로 종료한다.
서버·스크립트에서는 -r(report)로 정해진 횟수만 돌고 결과를 출력하게 쓴다.
ICMP raw 소켓을 쓰므로 보통 root 권한이 필요하다. 배포판에 따라 setuid나 cap_net_raw가 붙어 일반 사용자로도 되는 경우가 있다.

자주 쓰는 옵션

옵션	의미	예시
`-r`	리포트 모드. 정해진 횟수만 돌고 텍스트로 출력	`mtr -r -c 20 8.8.8.8`
`-w`	넓은 출력. 호스트명이 잘리지 않는다	`mtr -rw -c 20 8.8.8.8`
`-c`	프로브 횟수(기본 10). 손실 판단에는 100 이상	`mtr -rwc 100 8.8.8.8`
`-n`	역방향 DNS 조회 생략	`mtr -rwnc 50 8.8.8.8`
`-b`	호스트명과 IP를 함께 표시	`mtr -rwbc 50 devin.kr`
`-T`	TCP SYN 사용. ICMP가 막힌 경로에 쓴다	`sudo mtr -T -P 443 -rwc 50 devin.kr`
`-P`	대상 포트(TCP/UDP 모드에서)	`sudo mtr -T -P 3306 -rwc 30 db01`
`-i`	프로브 간격(초). 기본 1	`mtr -rwc 100 -i 0.5 8.8.8.8`
`--json`	JSON 출력. 모니터링 수집에 쓴다	`mtr --json -c 20 8.8.8.8`

실전 예제

1. 지원팀에 제출할 근거 자료를 만든다. 실무에서 가장 많이 쓰는 형태다. 100회는 돌려야 몇 퍼센트 단위 손실이 통계적으로 의미를 가진다.

mtr -rwc 100 8.8.8.8

Start: 2026-08-25T22:30:00+0900
HOST: web01                        Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.0.1                 0.0%   100    1.3   1.1   0.6   2.9   0.3
  2.|-- 182.222.121.225             0.0%   100    1.8   2.0   1.5   9.1   0.8
  3.|-- ???                       100.0%   100    0.0   0.0   0.0   0.0   0.0
  4.|-- 100.125.3.33                0.0%   100    2.1   2.4   1.8  11.2   1.0
  5.|-- 8.8.8.8                     0.0%   100   36.5  37.2  35.9  58.4   2.1

여기서 3번 홉의 100.0%는 장애가 아니다. 그 라우터가 ICMP 응답을 안 줄 뿐, 뒤의 4·5번이 정상이므로 패킷은 문제없이 지나갔다.

2. 특정 시점에 끊기는 문제를 잡는다. 대화형으로 띄워놓고 증상이 나타나는 순간의 화면을 본다. 손실이 어느 홉부터 시작되는지가 핵심이다.

mtr -n devin.kr

대화형 화면에서 d는 표시 모드 전환, r은 통계 초기화, o는 표시할 필드 변경, q는 종료다.

3. ICMP가 막힌 상대에 실제 서비스 포트로 측정한다. 클라우드 인스턴스나 로드밸런서는 ICMP를 차단하는 경우가 많다. 이때 기본 모드로는 마지막 홉이 안 나온다.

sudo mtr -T -P 443 -rwnc 50 devin.kr

4. 결과를 기록으로 남긴다. 장애 시간대에 cron으로 돌려 로그를 쌓아두면 사후 분석이 가능해진다.

mtr -rwnc 60 8.8.8.8 >> /var/log/mtr-8888.log 2>&1

cron에 넣을 때는 -r을 반드시 붙인다. 대화형 모드로 들어가면 프로세스가 영원히 남는다.

5. 자동 수집용으로 JSON을 뽑는다.

mtr --json -c 20 -n 8.8.8.8 | jq '.report.hubs[] | {hop: .count, host: .host, loss: ."Loss%", avg: .Avg}'

함정과 주의점

중간 홉의 Loss%를 그대로 믿으면 안 된다. 라우터는 자기에게 온 ICMP 응답 생성을 낮은 우선순위로 처리하거나 속도 제한(rate limit)을 건다. 그래서 중간에 손실이 보여도 그 뒤 홉들이 0%면 실제 트래픽 손실은 없다. 판단 기준은 단 하나다. 어느 홉에서 손실이 시작돼 마지막 홉까지 계속 이어지는가. 마지막 홉의 Loss%가 실제 서비스가 겪는 손실이다.

경로는 비대칭이다. mtr이 보여주는 것은 우리 서버에서 상대로 가는 길뿐이다. 손실이 돌아오는 경로에 있으면 우리 쪽 mtr에는 그 원인 홉이 안 나온다. 그래서 회선 문의를 넣을 때는 양방향 mtr 리포트를 함께 제출한다. 상대 서버에서도 우리 IP를 향해 같은 명령을 돌린다.

-c 10 리포트는 근거가 안 된다. 10회에서 1회 실패면 10%로 찍히는데 이건 통계가 아니라 잡음이다. 최소 100회를 돌리고, 판단이 애매하면 시간대를 바꿔 여러 번 뽑는다.

Avg보다 Wrst와 StDev를 본다. 평균은 정상인데 최악값이 수백 ms이고 StDev가 크면 지터가 심한 것이다. 화상회의나 게임처럼 지연 변동에 민감한 서비스는 평균이 좋아도 체감이 나쁘다.