네트워크 문제는 서버 장애의 주요 원인 중 하나다. 먼저 연결이 되는지, 어떤 포트가 열려 있는지, 경로와 DNS가 정상인지 순서대로 확인하면 원인을 빠르게 좁힐 수 있다. 이 글은 ping, ss, traceroute, dig, curl을 사용해 기본 점검 흐름을 정리한다. 각 명령에 대한 간단한 사용 예와 함께 실무 점검 포인트를 정리한다.
목차
- 연결 상태 확인: ping
- 열린 포트·세션 확인: ss (netstat 대체)
- 경로 추적: traceroute
- DNS 질의와 이름해석: dig, nslookup
- HTTP 체크와 API 점검: curl
- 운영 루틴 예시
- 정리
1. 연결 상태 확인: ping
서버나 네트워크 연결이 정상인지 확인할 때 가장 먼저 사용하는 명령이 ping이다. 대상 IP나 도메인으로 패킷을 전송하고, 응답이 돌아오는지와 지연 시간을 측정한다.
ping -c 4 8.8.8.8
- 구글의 공개 DNS 서버(8.8.8.8)에 4번 패킷을 전송해 응답을 확인한다.
- -c 4는 전송 횟수를 4회로 제한한다.
- 결과에는 응답 시간(RTT)과 패킷 손실률이 표시된다.
ping -c 4 example.com
- 도메인을 직접 입력하면 DNS 해석 과정까지 함께 점검할 수 있다.
- IP는 통신만, 도메인은 DNS와 네트워크 두 부분을 동시에 확인할 수 있다.
결과 해석 예시
- 100% packet loss : 네트워크 단절, 방화벽 차단, 대상 서버 다운 가능성.
- 응답 시간(RTT)이 일정하게 증가하거나 300ms 이상으로 높으면, 구간 혼잡이나 네트워크 지연 가능성.
- 패킷이 정상 응답하더라도 curl이나 ss로 포트 단위 통신이 가능한지 추가 확인이 필요하다.
ping은 네트워크 점검의 첫 단계로, “서버가 살아 있는가?”를 가장 빠르게 판단할 수 있는 기본 도구다.
2. 열린 포트·세션 확인: ss (netstat 대체)
서버에 접속이 되지 않거나 서비스가 응답하지 않을 때는, 해당 포트가 실제로 열려 있는지 확인해야 한다. 이때 사용하는 명령이 ss다. ss는 예전 명령인 netstat을 대체하며, 더 빠르고 가볍다.
ss -tuln
- 서버에서 열려 있는 포트와 프로토콜을 확인한다.
- -t는 TCP, -u는 UDP, -l은 리슨(listen) 중인 소켓, -n은 주소와 포트를 숫자로 표시한다.
- 예를 들어 *:80이 표시되면 웹 서버가 80번 포트에서 요청을 기다리고 있다는 뜻이다.
ss -tp | grep nginx
- nginx 관련 TCP 연결과 프로세스 정보를 확인한다.
- -p는 각 포트를 사용 중인 프로세스를 함께 보여준다(관리자 권한 필요).
- 특정 서비스가 정상적으로 리슨 중인지, 어떤 PID가 포트를 점유하는지 확인할 수 있다.
ss -s
- 소켓 상태를 통계 형태로 요약한다.
- ESTAB(연결됨), TIME-WAIT(종료 대기) 등의 상태를 한눈에 볼 수 있다.
- 세션이 비정상적으로 많다면, 연결이 닫히지 않거나 트래픽 폭주 가능성이 있다.
실무 팁
외부에서 서비스 접속이 안 될 때는 먼저 서버 내부에서 ss -tuln으로 포트가 열려 있는지 확인한다. 포트가 리슨 중이라면, 다음으로 방화벽(ufw, firewalld)이 해당 포트를 막고 있지 않은지 점검한다. 방화벽 설정에서 포트가 허용되어 있지 않거나, 리슨 중인 프로세스가 없다면 서비스가 정상적으로 동작하지 않는 상태다. 일반적으로 포트 리슨 여부와 방화벽 허용 상태만 확인해도 접속 불가 원인의 대부분을 파악할 수 있다.
3. 경로 추적: traceroute
네트워크 연결이 불안정하거나 특정 구간에서 속도가 느릴 때는 패킷이 목적지까지 어떤 경로를 거치는지 확인해야 한다.
이때 사용하는 명령이 traceroute다.
sudo apt install traceroute
설치되어 있지 않은 경우 먼저 설치한다. 대부분의 리눅스 배포판에서 기본 패키지로 제공된다.
traceroute 8.8.8.8
- 목적지(예: 8.8.8.8)까지의 경로를 단계별로 보여준다.
- 각 줄은 한 개의 라우터(홉, hop)를 의미하며, 지연 시간(ms)도 함께 표시된다.
- 특정 홉에서 응답이 멈추거나 지연이 심하면 그 구간이 병목일 가능성이 있다.
traceroute -T -p 443 example.com
- TCP 포트 443(HTTPS)으로 테스트한다.
- -T는 TCP 모드, -p는 포트 지정이다.
- 방화벽에서 ICMP 패킷이 차단된 환경에서도 경로 확인이 가능하다.
결과 해석 예시
- * * * : 해당 홉에서 응답이 없음을 의미한다. 방화벽 차단이나 비공개 구간일 수 있다.
- 중간 구간에서 RTT가 갑자기 늘어나면, 그 지점이 네트워크 지연 구간일 가능성이 높다.
- 여러 네트워크(예: 사무실, 외부 망)에서 traceroute를 실행해 비교하면 특정 구간의 장애 여부를 더 정확히 판단할 수 있다.
traceroute는 “어디서 문제가 생겼는가”를 파악하는 명령이다. ping이 단순히 “연결 가능 여부”를 본다면, traceroute는 “연결 경로의 품질”을 분석하는 도구다.
4. DNS 질의와 이름해석: dig, nslookup
서버 접속이 되지 않거나 도메인 이름으로 접근이 안 될 때는 DNS(도메인 이름 시스템) 해석이 올바르게 동작하는지 확인해야 한다. 이때 사용하는 명령이 dig와 nslookup이다.
dig A example.com +short
- example.com의 IPv4 주소(A 레코드)만 간단히 출력한다.
- +short 옵션은 결과를 간결하게 보여준다.
- IP가 정상적으로 표시되면 DNS 질의는 성공한 것이다.
dig CNAME www.example.com +short
CNAME(별칭) 레코드를 확인한다. 여러 도메인이 같은 서비스로 연결되는 경우, 연결 경로를 점검할 때 유용하다.
dig example.com ANY
A, MX, TXT, NS 등 모든 레코드를 한 번에 요청한다. 일부 DNS 서버는 ANY 요청을 제한하므로 결과가 없다고 해서 오류는 아니다.
nslookup example.com 8.8.8.8
8.8.8.8(구글 DNS)을 이용해 직접 질의한다. 다른 DNS 서버와 응답이 다르다면 캐시나 전파 지연 문제일 수 있다.
실무 팁
DNS 응답이 없거나 불규칙하면 /etc/resolv.conf 파일의 nameserver 설정을 확인한다. 내부 네트워크에서는 사설 DNS 서버 주소가 잘못 등록된 경우가 많다. 동일 도메인을 여러 네트워크(사무실, 클라우드, 외부)에서 조회해 결과가 다르면 캐시 불일치 또는 지역 DNS 전파 지연 가능성을 의심해야 한다. DNS 점검은 “도메인 이름이 어디로 연결되는가”를 확인하는 단계다. 이 단계에서 문제가 없다면 실제 서비스(HTTP, SSH 등) 통신으로 넘어가면 된다.
5. HTTP 체크와 API 점검: curl
서버가 네트워크에는 연결되지만 웹 서비스나 API가 응답하지 않을 때는 curl 명령으로 실제 HTTP 통신이 정상인지 직접 확인할 수 있다. curl은 URL을 지정해 요청을 보내고, 응답 코드와 내용을 출력한다.
curl -I https://example.com
- HTTP 헤더만 요청해 상태 코드(200, 301, 404 등)를 빠르게 확인한다.
- -I 옵션은 HEAD 요청을 의미한다.
- 서버가 정상이라면 HTTP/1.1 200 OK 같은 응답이 표시된다.
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/health
- 응답 본문을 출력하지 않고 상태 코드만 확인한다.
- -s는 조용한 모드(silent), -o /dev/null은 출력 버림, -w는 형식 지정이다.
- 200이면 정상, 500이면 서버 오류, 404면 경로 없음이다.
curl -vk https://example.com
- -v는 상세 연결 로그를 출력하며, SSL 협상 등 세부 과정 확인에 유용하다.
- -k는 인증서 검증을 생략하지만, 보안상 운영 환경에서는 사용을 피해야 한다.
- 인증서 오류나 HTTPS 설정 문제를 점검할 때만 제한적으로 사용한다.
실무 팁
- 응답 코드가 200이라도 실제 본문이 비정상일 수 있다.
curl -L로 리디렉션을 따라가거나, -v로 헤더를 확인하면 원인을 더 정확히 파악할 수 있다. - API 서버의 응답 시간(latency)을 확인하려면 time curl -s -o /dev/null URL 형식으로 실행한다.
- 방화벽이나 로드밸런서 뒤에 있는 서버라면, 외부·내부 각각에서 curl을 실행해 차이를 비교해야 한다.
curl은 단순 테스트용이 아니라, 서비스 가용성과 헬스체크를 자동화할 때도 자주 사용된다. 서버 상태를 모니터링하거나 스크립트로 API 응답을 검증할 때 필수 도구다.
6. 운영 루틴 예시
지금까지 살펴본 네트워크 진단 명령어들은 각각의 기능도 중요하지만, 실무에서는 순서대로 조합해 사용하는 것이 핵심이다. 문제가 발생했을 때 무작정 명령을 입력하기보다, 연결 → 포트 → 경로 → DNS → 서비스 응답 순서로 점검하면
문제 원인을 빠르고 정확하게 찾을 수 있다.
# 1) 연결 상태 확인
ping -c 4 example.com
기본적인 통신이 가능한지 확인한다. 응답이 없으면 네트워크 단절, 방화벽 차단, 대상 서버 다운을 의심한다.
# 2) 서비스 포트 리슨 여부
ss -tuln | grep ':80\|:443'
웹 서버(80, 443 포트)가 실제로 열려 있는지 확인한다. 포트가 닫혀 있거나 리슨 중인 프로세스가 없다면 서비스 자체 문제일 수 있다.
# 3) 외부 경로 지연 확인
traceroute -T -p 443 example.com
특정 구간에서 지연이나 응답 손실이 있는지 확인한다. 일정 홉 이후에 지연이 급격히 늘어난다면 그 구간이 병목 구간이다.
# 4) DNS 응답 점검
dig A example.com +short
nslookup example.com 8.8.8.8
도메인이 올바른 IP로 해석되는지 확인한다. 내부 DNS와 외부 DNS 결과가 다르면 캐시 문제나 설정 오류 가능성이 있다.
# 5) 서비스 응답 확인
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/health
웹 서버나 API가 정상적으로 응답하는지 상태 코드로 확인한다. 200이면 정상, 400~500대 코드면 애플리케이션 또는 서버 오류다.
실무 팁
이 다섯 단계를 스크립트로 자동화하면 정기 점검이나 장애 대응 시간을 크게 줄일 수 있다. 예를 들어 check_network.sh 같은 간단한 셸 스크립트를 만들어 ping, ss, traceroute, dig, curl 명령을 순서대로 실행하도록 설정하고 cron으로 하루 한 번 자동 실행하면 기본적인 서비스 상태를 항상 모니터링할 수 있다. 이 루틴은 서버 크기와 상관없이 적용 가능한 기본 네트워크 점검 절차다. 리눅스 관리자는 이 흐름을 몸에 익혀두면, 어떤 환경에서도 빠르게 원인을 파악할 수 있다.
7. 정리
이번 글에서는 리눅스 환경에서 네트워크 연결 문제를 진단하는 기본 명령어들을 정리했다. ping으로 연결 가능 여부를 확인하고, ss로 포트 상태를 점검, traceroute로 경로를 추적해 병목 구간을 찾고, dig와 nslookup으로 DNS 해석이 정상인지 검증, 마지막으로 curl을 통해 실제 서비스나 API가 올바르게 응답하는지도 확인했다. 이 다섯 가지 명령은 네트워크 문제의 대부분을 스스로 진단할 수 있게 해주는 기본 도구다. 문제 발생 시 아래 순서를 기억해 두면 빠르고 체계적인 대응이 가능하다.
- ping – 서버와의 연결 여부 확인
- ss – 포트가 열려 있는지 확인
- traceroute – 경로와 지연 구간 점검
- dig / nslookup – DNS 이름 해석 확인
- curl – 실제 서비스 응답 테스트
네트워크 문제의 원인은 대부분 이 다섯 단계 안에서 해결된다. 특히 여러 서버를 운영하는 환경에서는 이 루틴을 자동화하거나 스크립트로 관리하면 장애 대응 시간을 크게 줄일 수 있다.