특정 사이트만 접속되지 않을 때 DNS와 브라우저 확인 순서: 접속 범위부터 원인 좁히기

1. 가장 먼저 무엇이 되고 무엇이 안 되는지 접속 범위를 나눠야 합니다

특정 사이트 접속 오류는 “인터넷이 안 된다”로 묶어 보면 원인을 찾기 어렵습니다. 같은 URL을 기준으로 다른 사이트, 다른 브라우저, 다른 기기, 다른 네트워크를 하나씩 바꿔 비교하면 문제의 범위를 빠르게 나눌 수 있습니다.

예를 들어 같은 노트북에서 Firefox는 열리지만 Chrome만 실패한다면 회선 전체보다 Chrome 설정이나 프로필 쪽 가능성이 커집니다. 반대로 Wi-Fi에서는 실패하지만 같은 휴대폰의 모바일 데이터에서는 열린다면 공유기·DNS·통신 경로처럼 네트워크별 차이를 먼저 확인하는 편이 맞습니다.

2. 오류 메시지를 보면 DNS 문제인지 브라우저·서버 문제인지 먼저 구분할 수 있습니다

브라우저 화면에 표시되는 오류 문구는 진단 순서를 정하는 데 도움이 됩니다. `DNS_PROBE_FINISHED_NXDOMAIN`, `ERR_NAME_NOT_RESOLVED`, “서버를 찾을 수 없음”처럼 이름 해석 실패를 나타내는 메시지는 DNS 확인 우선순위를 높입니다.

반면 `403`, `404`, `500`, `503` 같은 HTTP 상태 코드가 실제 페이지 응답으로 보인다면 일반적으로 브라우저가 서버까지 도달해 응답을 받은 상태입니다. 이때는 DNS 캐시 삭제보다 로그인 권한, URL 경로, 서버 상태, 웹 애플리케이션 오류를 먼저 살피는 편이 효율적입니다.

인증서 경고, 연결 시간 초과, 연결 재설정은 DNS만으로 설명되지 않을 수 있습니다. VPN·프록시·보안 프로그램, 방화벽, TLS 설정, 서버 연결 문제까지 범위를 넓혀야 합니다.

3. DNS는 ‘바꾸기’보다 먼저 현재 조회 결과를 비교합니다

Windows에서는 `nslookup`으로 현재 DNS 서버가 특정 도메인을 어떤 주소로 해석하는지 확인할 수 있습니다. Microsoft는 이 도구를 DNS 인프라 진단에 사용할 수 있는 명령으로 안내합니다.

첫 번째 명령은 현재 기본 DNS 리졸버를 사용하고, 두 번째는 예시로 공개 DNS 리졸버를 지정해 비교합니다. 공개 사이트인데 기본 DNS에서는 실패하고 다른 리졸버에서는 정상 주소가 나온다면 현재 DNS 캐시나 리졸버 경로를 추가로 확인할 근거가 생깁니다.

단, 사내·학교 내부 주소처럼 공개 인터넷용이 아닌 도메인은 공용 DNS에서 조회되지 않는 것이 정상일 수 있습니다. 이 경우 조직이 지정한 DNS를 유지하고 관리자에게 확인하는 편이 적절합니다.

Microsoft 공식 nslookup 명령과 진단 항목 확인
정보 확인하기 →

4. Windows DNS 캐시는 조회 이상이 의심될 때 비운 뒤 다시 테스트합니다

Windows의 `ipconfig /flushdns`는 DNS 클라이언트 해석기 캐시 내용을 비우고 초기화합니다. 이전에 저장된 잘못된 주소나 실패 결과가 로컬에 남아 있다고 의심될 때 유용하지만, 모든 접속 오류를 해결하는 만능 초기화 명령은 아닙니다.

실행 후에는 실패하던 사이트를 새로 열고, 가능하면 `nslookup` 결과도 다시 확인하세요. 그래도 동일하면 브라우저 자체 DNS 설정이나 사이트 데이터, 네트워크 정책으로 범위를 옮기는 편이 좋습니다.

Microsoft 공식 ipconfig /flushdns 설명 확인
정보 확인하기 →

5. 다른 브라우저에서는 열리면 캐시보다 ‘브라우저 격리 테스트’를 먼저 합니다

특정 브라우저에서만 문제가 생기면 모든 기록을 지우기 전에 문제를 재현할 조건을 분리하는 편이 좋습니다. 시크릿/개인정보 보호 창, 새 프로필, 확장 기능이 비활성화된 문제 해결 모드를 이용하면 로그인 세션·확장 기능·프로필 설정의 영향을 구분하는 데 도움이 됩니다.

Chrome 계열에서 먼저 볼 것

시크릿 창에서 같은 사이트를 열어 보고, 정상이라면 해당 사이트의 쿠키·캐시·사이트 권한과 확장 기능을 우선 점검합니다. 전체 브라우징 데이터를 한꺼번에 삭제하면 로그인 정보와 편의 설정까지 영향을 받을 수 있으므로, 가능하면 영향을 받는 사이트 데이터부터 정리하는 편이 부담이 적습니다.

Firefox에서 먼저 볼 것

Firefox의 Troubleshoot Mode는 확장 기능을 끄고 기본 테마와 일부 기본 설정으로 실행해 문제 원인을 분리하는 데 사용할 수 있습니다. 이 모드에서 사이트가 정상이라면 확장 기능이나 사용자 지정 설정을 하나씩 되돌려 원인을 찾는 방식이 효과적입니다.

Safari에서는 특정 사이트의 웹사이트 데이터를 선택해 제거하는 방식도 지원됩니다. 한 사이트만 문제라면 브라우저 전체를 초기화하기 전에 사이트 단위 데이터 정리를 고려할 수 있습니다.

Firefox Troubleshoot Mode 공식 도움말에서 확장 기능과 사용자 지정 요소를 임시로 비활성화하는 진단 방법을 확인할 수 있습니다.

Apple의 Safari 문제 해결 안내에는 영향을 받는 웹사이트 데이터를 선택해 제거하는 방법이 포함되어 있습니다.

6. Secure DNS와 DNS over HTTPS는 OS DNS와 다른 결과를 만들 수 있습니다

Chrome의 Secure DNS와 Firefox의 DNS over HTTPS(DoH)는 브라우저가 DNS 조회를 처리하는 방식에 영향을 줍니다. 따라서 Windows에서 DNS를 바꾸거나 캐시를 비웠는데도 한 브라우저만 계속 다른 결과를 보인다면 브라우저의 보안 DNS 설정을 확인할 필요가 있습니다.

Chrome은 설정의 개인정보 보호 및 보안 영역에서 Secure DNS를 켜거나 끄고 현재 제공자 또는 사용자 지정 제공자를 선택할 수 있습니다. Firefox도 DoH 보호 수준과 공급자 설정에 따라 시스템 DNS와 다른 경로를 사용할 수 있습니다.

테스트 목적이라면 현재 설정을 기록한 뒤 잠시 다른 구성으로 비교하고, 원인이 확인되면 조직 정책이나 보안 요구사항에 맞는 상태로 되돌리세요. 단순히 “빠른 DNS”를 찾기 위해 무작정 바꾸는 것과 장애 원인 비교를 위한 일시적 테스트는 구분하는 것이 좋습니다.

Chrome 공식 Secure DNS 설정 위치 확인
정보 확인하기 →

Mozilla의 Firefox DNS over HTTPS 공식 설명에서 DoH가 일반 DNS와 어떻게 다르게 동작하는지 확인할 수 있습니다.

7. DNS와 브라우저가 정상이면 VPN·프록시·보안 필터·사이트 측 원인까지 확인합니다

DNS 조회가 정상이고 여러 브라우저에서 같은 증상이 이어진다면 네트워크 경로를 확인할 차례입니다. VPN, 프록시, 보안 프로그램의 웹 필터, 공유기의 자녀 보호 또는 DNS 필터, 회사·학교 네트워크 정책은 특정 도메인만 선택적으로 막을 수 있습니다.

또한 `hosts` 파일에 특정 도메인이 수동으로 매핑되어 있으면 DNS보다 우선해 예상과 다른 주소로 연결될 수 있습니다. 다만 시스템 파일을 임의로 편집하면 다른 접속 문제가 생길 수 있으므로, 이상한 항목이 실제로 존재하는지 확인하는 수준에서 시작하고 관리 환경에서는 담당자와 상의하세요.

여러 기기와 여러 네트워크에서 동일 사이트가 모두 실패한다면 로컬 설정만 반복해서 초기화하기보다 사이트 운영자의 장애 공지, 도메인 DNS 상태, 서비스 상태 페이지를 확인하는 편이 낫습니다. Cloudflare의 DNS 문제 해결 문서도 `ERR_NAME_NOT_RESOLVED` 같은 브라우저 오류를 일반적인 DNS 해석 실패 사례로 설명합니다.

Cloudflare DNS 문제 해결 문서에서 이름 해석 오류의 대표적인 형태를 확인할 수 있습니다.

8. 특정 사이트 접속 오류 FAQ