ping, traceroute, nslookup 명령어 사용법
서버를 운영하다 보면 “사이트가 안 열려요”라는 말을 듣게 되는 순간이 옵니다. 이때 가장 먼저 해야 할 일은 문제가 어디에서 생겼는지 파악하는 겁니다. 서버 자체가 죽은 건지, 네트워크 경로 어딘가가 막힌 건지, DNS가 도메인을 못 찾는 건지에 따라 대응이 완전히 달라집니다. 리눅스에는 이런 네트워크 문제를 진단할 수 있는 기본 명령어들이 있습니다. 이번 글에서는 가장 자주 사용하는 ping, traceroute, nslookup 세 가지 명령어의 사용법과 결과를 읽는 방법을 정리해보겠습니다.
ping — 서버가 살아있는지 확인하기
ping은 네트워크 진단에서 가장 먼저 사용하는 명령어입니다. 상대 서버에 작은 패킷을 보내고 응답이 돌아오는지 확인합니다. 응답이 오면 서버가 살아있고 네트워크가 연결되어 있다는 뜻이고, 응답이 안 오면 서버가 다운됐거나 네트워크 어딘가에 문제가 있다는 뜻입니다.
사용법은 간단합니다.
ping today-play.com실행하면 이런 결과가 반복적으로 나옵니다.
PING today-play.com (143.198.241.73) 56(84) bytes of data.
64 bytes from 143.198.241.73: icmp_seq=1 ttl=56 time=32.4 ms
64 bytes from 143.198.241.73: icmp_seq=2 ttl=56 time=31.8 ms
64 bytes from 143.198.241.73: icmp_seq=3 ttl=56 time=33.1 ms결과에서 봐야 할 항목이 세 가지 있습니다.
time은 패킷이 상대 서버까지 갔다가 돌아오는 데 걸린 시간입니다. 밀리초 단위이고, 이 값이 작을수록 응답이 빠르다는 뜻입니다. 같은 국내 서버라면 보통 10ms 이내이고, 해외 서버라면 100ms 이상 나올 수 있습니다. 평소에 30ms 정도였는데 갑자기 200ms로 뛰었다면 네트워크 경로에 문제가 생겼거나 서버에 부하가 걸린 겁니다.
ttl은 Time to Live의 약자로 패킷이 네트워크를 지나면서 거칠 수 있는 최대 라우터 수입니다. 라우터를 하나 지날 때마다 ttl이 1씩 줄어들고, 0이 되면 패킷이 폐기됩니다. 네트워크에서 패킷이 무한히 돌아다니는 걸 방지하는 장치입니다. 일반적인 진단에서 ttl 값을 직접 분석할 일은 많지 않지만, 운영체제마다 기본 ttl이 달라서 상대 서버의 운영체제를 대략 추측할 수 있습니다. 리눅스는 보통 64, 윈도우는 128에서 시작합니다.
icmp_seq는 보낸 패킷의 순번입니다. 이 번호가 중간에 빠지면 해당 패킷이 유실된 겁니다. 1, 2, 4, 5처럼 3이 빠져 있다면 세 번째 패킷이 도중에 사라졌다는 뜻입니다. 간헐적으로 패킷이 빠지면 네트워크가 불안정한 상태이고, 전부 다 빠지면 연결 자체가 안 되는 겁니다.
리눅스에서 ping은 중지할 때까지 계속 실행됩니다. Ctrl+C를 누르면 중지되면서 통계가 나옵니다. 보낸 패킷 수, 받은 패킷 수, 유실률, 평균 응답 시간을 보여줍니다.
횟수를 지정하고 싶으면 -c 옵션을 사용합니다.
ping -c 5 today-play.com이렇게 하면 5번만 보내고 자동으로 끝납니다.
ping 결과가 안 나올 때도 있습니다. “Request timed out”이나 “Destination Host Unreachable” 같은 메시지가 나오는 경우입니다. 서버가 다운된 건 아닌데 ping 응답이 안 올 수도 있습니다. 보안상의 이유로 서버나 방화벽에서 ICMP 패킷을 차단하는 경우가 있기 때문입니다. AWS의 보안 그룹에서 ICMP를 허용하지 않으면 서버가 정상이어도 ping이 안 됩니다. 그래서 ping이 안 된다고 무조건 서버가 죽은 거라고 판단하면 안 됩니다.
IP 주소로도 직접 ping을 보낼 수 있습니다.
ping 143.198.241.73도메인으로 ping이 안 되는데 IP로는 되면 DNS에 문제가 있다는 뜻입니다. 이때는 nslookup으로 DNS를 확인해야 합니다.
traceroute — 네트워크 경로 추적하기
ping이 상대 서버까지 도달할 수 있는지만 확인한다면, traceroute는 그 사이에 어떤 경로를 거치는지를 보여줍니다. 내 컴퓨터에서 서버까지 패킷이 어떤 라우터들을 지나가는지 한 단계씩 추적합니다.
traceroute today-play.com실행하면 이런 결과가 나옵니다.
traceroute to today-play.com (143.198.241.73), 30 hops max
1 192.168.1.1 (192.168.1.1) 1.234 ms 1.112 ms 0.987 ms
2 10.0.0.1 (10.0.0.1) 3.456 ms 3.321 ms 3.211 ms
3 172.16.50.1 (172.16.50.1) 8.765 ms 8.654 ms 8.543 ms
4 * * *
5 203.0.113.1 (203.0.113.1) 25.432 ms 25.321 ms 25.210 ms
6 143.198.241.73 (143.198.241.73) 32.123 ms 31.987 ms 31.876 ms왼쪽 숫자는 홉(hop) 번호입니다. 패킷이 거치는 라우터의 순서를 나타냅니다. 첫 번째 홉은 보통 내 공유기이고, 그다음은 ISP의 라우터, 그 이후에는 인터넷 백본 라우터를 거쳐서 최종 목적지에 도달합니다.
각 홉에 세 개의 시간 값이 나오는 건 traceroute가 각 홉에 패킷을 세 번 보내기 때문입니다. 세 번의 응답 시간이 표시되는데, 이 값이 갑자기 크게 뛰는 구간이 있으면 그 구간에서 지연이 발생하고 있다는 뜻입니다. 3번 홉까지 8ms였는데 5번 홉에서 갑자기 25ms로 뛰었다면 4번에서 5번 사이 구간에서 지연이 생기고 있는 겁니다.
별표 세 개가 나오는 홉은 해당 라우터가 응답을 보내지 않은 겁니다. 보안 정책으로 ICMP를 차단해둔 라우터입니다. 중간에 별표가 나오더라도 이후 홉에서 정상 응답이 오면 크게 신경 쓸 필요 없습니다. 하지만 특정 홉부터 끝까지 전부 별표가 나오면 그 지점에서 패킷이 막히고 있다는 뜻입니다.
traceroute는 문제 구간을 특정할 때 유용합니다. ping은 최종 목적지까지 되는지 안 되는지만 알려주지만, traceroute는 어디서 문제가 생기는지를 보여줍니다. ISP 구간에서 막히는 건지, 클라우드 업체 쪽에서 막히는 건지, 내 네트워크에서부터 문제인지를 구분할 수 있습니다.
Ubuntu에서 traceroute가 설치되어 있지 않으면 이렇게 설치합니다.
sudo apt install traceroute윈도우에서는 traceroute 대신 tracert라는 명령어를 사용합니다.
tracert today-play.com기능은 동일합니다.
nslookup — DNS 조회하기
nslookup은 도메인의 DNS 정보를 조회하는 명령어입니다. 도메인이 어떤 IP를 가리키고 있는지, MX 레코드는 뭐가 설정되어 있는지 확인할 수 있습니다.
가장 기본적인 사용법입니다.
nslookup today-play.com결과가 이렇게 나옵니다.
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: today-play.com
Address: 143.198.241.73위쪽의 Server는 조회에 사용된 DNS 서버입니다. 127.0.0.53은 로컬 DNS 리졸버의 주소입니다. 아래쪽의 Address가 도메인에 연결된 IP 주소입니다.
Non-authoritative answer라는 문구가 나오는데, 이건 캐시된 결과라는 뜻입니다. 직접 해당 도메인의 네임서버에서 가져온 게 아니라 중간 DNS 서버가 캐시해둔 정보를 돌려준 겁니다. 정상적인 상황이고 걱정할 필요 없습니다.
특정 DNS 서버를 지정해서 조회할 수도 있습니다.
nslookup today-play.com 8.8.8.8구글의 공개 DNS(8.8.8.8)에서 조회한 결과를 보여줍니다. DNS 설정을 변경한 직후에 로컬 DNS에는 아직 예전 값이 캐시되어 있을 수 있는데, 외부 DNS로 조회하면 전파 상태를 확인할 수 있습니다.
특정 레코드 타입을 조회하고 싶으면 이렇게 합니다.
nslookup -type=MX today-play.com
nslookup -type=TXT today-play.com
nslookup -type=NS today-play.comMX 레코드를 조회하면 메일 서버 설정을 확인할 수 있고, TXT 레코드를 조회하면 SPF 설정이나 도메인 인증 값을 확인할 수 있습니다. 이전 글에서 다뤘던 DNS 레코드들을 실제로 확인할 때 nslookup을 사용합니다.
nslookup 대신 dig 명령어를 쓸 수도 있습니다. dig이 더 자세한 정보를 보여주기 때문에 실무에서는 dig을 선호하는 경우가 많습니다.
dig today-play.com A
dig today-play.com MX +short+short 옵션을 붙이면 핵심 값만 간결하게 보여줍니다. 스크립트에서 결과를 파싱할 때 편리합니다.
세 명령어를 조합한 문제 진단 흐름
실제로 서버에 접속이 안 될 때 이 세 명령어를 순서대로 사용하면 문제를 체계적으로 진단할 수 있습니다.
첫 번째 단계로 nslookup으로 DNS를 확인합니다. 도메인이 올바른 IP를 가리키고 있는지 확인합니다. IP가 안 나오거나 엉뚱한 IP가 나오면 DNS 설정에 문제가 있는 겁니다. A레코드가 잘못 설정되어 있거나 네임서버가 변경된 후 전파가 안 됐을 수 있습니다.
nslookup today-play.com두 번째 단계로 ping으로 서버 응답을 확인합니다. DNS가 정상이면 IP 주소가 나올 테니, 그 IP로 직접 ping을 보내봅니다. 응답이 오면 서버까지의 네트워크는 정상입니다. 응답이 안 오면 서버가 다운됐거나 방화벽에서 차단하고 있을 수 있습니다.
ping -c 5 143.198.241.73세 번째 단계로 traceroute로 경로를 추적합니다. ping이 안 될 때 어디서 막히는지 확인합니다. 특정 홉부터 응답이 없어지면 그 구간이 문제입니다. 내 네트워크 문제인지, ISP 문제인지, 서버 쪽 문제인지를 구분할 수 있습니다.
traceroute today-play.com이 순서를 따라가면 대부분의 네트워크 문제에서 원인이 DNS인지, 서버인지, 중간 네트워크인지를 빠르게 좁힐 수 있습니다.
추가로 알아두면 좋은 옵션들
ping에서 패킷 크기를 지정할 수 있습니다.
ping -s 1400 -c 5 today-play.com-s 옵션으로 패킷 크기를 바이트 단위로 지정합니다. 기본값은 56바이트인데, 큰 패킷을 보내서 네트워크의 MTU 문제를 확인할 때 사용합니다. 작은 패킷은 잘 가는데 큰 패킷이 유실된다면 경로 중간에 MTU 제한이 있는 장비가 있다는 뜻입니다.
traceroute에서 TCP를 사용하는 옵션도 있습니다.
sudo traceroute -T -p 443 today-play.com기본 traceroute는 UDP를 사용하는데, 일부 방화벽이 UDP를 차단해서 결과가 부정확할 수 있습니다. -T 옵션을 사용하면 TCP로 추적하고, -p로 포트를 지정할 수 있습니다. 웹 서버 443 포트로 TCP traceroute를 하면 실제 HTTPS 트래픽과 같은 경로를 확인할 수 있습니다.
mtr이라는 명령어도 있는데, ping과 traceroute를 합친 도구입니다.
sudo apt install mtr
mtr today-play.com실행하면 traceroute처럼 각 홉을 보여주면서 동시에 ping처럼 실시간으로 응답 시간과 패킷 유실률을 갱신합니다. 네트워크 문제를 모니터링할 때 매우 유용합니다. 한 화면에서 어느 구간에서 패킷이 유실되는지, 어느 구간에서 지연이 큰지를 한눈에 볼 수 있습니다.
마무리
ping은 서버가 살아있는지 확인하고, traceroute는 경로 중 어디에서 문제가 생기는지 추적하고, nslookup은 DNS 설정이 올바른지 확인합니다. 이 세 가지만 알아도 네트워크 문제가 발생했을 때 원인을 좁히는 데 충분합니다. 서버가 안 될 때 무작정 설정을 바꾸기 전에 이 명령어들로 먼저 진단하는 습관을 들이면 불필요한 삽질을 많이 줄일 수 있습니다. 다음 글에서는 코드 변경을 서버에 자동으로 반영하는 CI/CD의 기초, GitHub Actions 사용법을 다뤄보겠습니다.
Leave a Reply