연결 문제를 계층별 질문으로 나눠
“사이트가 안 열린다”는 말만으로는 DNS, 경로, 포트, TLS와 HTTP 가운데 어디가 실패했는지 알 수 없어. ping, dig, traceroute, nc는 서로 다른 층을 관찰해. 한 도구의 성공이나 실패를 전체 서비스 상태로 확대 해석하지 말고 다음 계층의 증거와 연결해.
ping: ICMP 응답을 받을 수 있나
ping -c 4 example.com이름이 IP로 해석되고 ICMP Echo 응답이 돌아오면 기본적인 네트워크 경로의 일부가 작동한다는 증거야. 그러나 방화벽이 ICMP만 막을 수 있어서 timeout이 곧 호스트 다운을 뜻하지는 않아. 반대로 ping 성공도 HTTPS 애플리케이션이 정상이라는 증거는 아니야.
dig: 이름이 어떤 DNS 답으로 풀리나
dig example.com A
dig example.com AAAA
dig +short example.com
dig @1.1.1.1 example.com레코드 종류와 질의한 DNS 해석기를 기록하고 여러 DNS 해석기의 답을 비교하면 캐시와 전파 차이를 볼 수 있어. 스크립트에서는 출력 형식과 빈 응답의 의미를 확인하고, DNSSEC나 split DNS처럼 네트워크 위치에 따라 답이 달라지는 환경도 고려해.
traceroute: 어느 경로로 가나
traceroute example.com
traceroute -P icmp example.com각 줄은 TTL이 만료된 지점의 응답을 보여 줘. 중간의 별표는 해당 라우터가 탐사 패킷에 응답하지 않았다는 뜻일 수 있고, 그 지점에서 실제 데이터가 반드시 끊겼다는 뜻은 아니야. mtr로 반복 관찰하면 시간에 따른 지연과 손실 경향을 볼 수 있지만 마지막 목적지의 애플리케이션 검사와 함께 해석해야 해.
nc: 특정 포트에 연결할 수 있나
nc -zv example.com 443
nc -zv localhost 5432-z는 데이터를 주고받지 않고 연결을 확인하고 -v는 자세한 결과를 보여 줘. TCP 연결 성공은 그 포트에서 프로세스가 응답했다는 증거이지 TLS 인증서, 프로토콜과 로그인까지 성공했다는 뜻은 아니야. UDP 검사는 연결형 TCP와 결과 의미가 다르다는 점도 주의해.
DNS에서 애플리케이션까지 순서대로 확인해
dig +short host로 이름 해석을 확인해.ping이나 traceroute로 경로 단서를 모아.nc -zv host port로 목적 포트의 TCP 연결을 확인해.curl -v https://host/...로 TLS와 HTTP 상태, 응답 본문을 확인해.
각 단계의 호스트 이름, IP, 포트와 시간을 기록하면 “안 된다”를 재현 가능한 장애 보고로 바꿀 수 있어.