“사이트에 연결할 수 없음” 오류 진단하는 방법

“사이트에 연결할 수 없음”(또는 브라우저별 비슷한 문구)은 일부러 모호하게 표시됩니다. URL 오타부터 서버 완전 중단, 내 인터넷 연결의 장애까지 모든 경우를 아우르기 때문입니다. 효율적으로 해결하려면 가장 싸고 빠른 것부터 확인해야 합니다.

먼저 단순한 DNS 조회부터

서버가 다운되었다고 단정하기 전에, 브라우저와 무관하게 도메인만 따로 조회해 보세요. 깔끔한 IP 주소가 반환되면 DNS는 문제가 아니므로 연결 자체를 확인하면 됩니다(포트가 열려 있는지, TLS 협상이 되는지, 서버가 실제로 응답하는지). NXDOMAIN, 시간 초과, 또는 비공개이거나 접속할 수 없어 보이는 주소가 나오면 문제가 DNS로 좁혀지며, 그 즉시 다른 많은 점검 범주를 제외할 수 있습니다.

각 결과가 알려 주는 것

인시던트 도중에 가입이 필요 없는 빠른 조회 도구가 실제로 유용한 이유이기도 합니다. 터미널을 열거나 dig/nslookup 문법을 기억하지 않아도 몇 초 만에 DNS 계층의 답을 얻을 수 있으므로, 다른 곳에 시간을 쓰기 전에 DNS 문제인지부터 바로 가려낼 수 있습니다.

DNS 다음에 확인할 것, 순서대로

1. 확인된 IP의 예상 포트(보통 443)로 TCP 연결이 되는지 확인합니다. DNS가 완벽해도 방화벽이나 완전히 중단된 서버는 여기서 연결을 거부하거나 멈춥니다.
2. TLS 인증서가 유효한지 확인합니다. 만료되었거나 일치하지 않는 인증서는 브라우저에 불안한 보안 경고를 띄우지만, DNS나 서버 접속 가능 여부와는 아무 관련이 없습니다.
3. HTTP 수준의 응답을 확인합니다. 연결은 받아들이지만 5xx 오류를 반환하는 서버는 켜져 있고 접속도 가능하며, DNS가 일으킬 수 있는 문제에서 몇 단계 뒤인 애플리케이션 계층에서 실패하는 것입니다.

DNS, 전송, TLS, 애플리케이션 순서로 점검하면 한 단계씩 제외할 때마다 남은 가능성이 의미 있게 줄어들며, 전체 스택을 한꺼번에 추측하는 일을 피할 수 있습니다.

왜 하필 이 순서일까요

이 순서의 각 계층은 앞선 계층이 성공해야만 동작하므로, 가장 그럴듯해 보이는 곳으로 건너뛰기보다 순서대로 확인하는 것이 효율적입니다. TCP 연결이 애초에 완료되지 않았다면 TLS 인증서를 살펴볼 이유가 없고, TLS 협상이 실패했다면 HTTP 응답 코드를 확인할 이유가 없습니다. 나머지 모든 과정이 가능해지기 전에 가장 먼저 일어나야 하는 DNS에서 시작해 한 계층씩 바깥으로 나아가면, 사실은 더 앞 계층의 단순한 문제가 일으킨 증상을 조사하느라 시간을 낭비하는 일이 없습니다.