This site can’t be reached 해결 총정리: 크롬 연결 오류 원인과 1분 복구 체크리스트

이 글의 목적은 브라우저에 “This site can’t be reached”가 표시될 때 사용자 수준에서 즉시 적용 가능한 원인 진단과 해결 절차를 체계적으로 제공하여 업무 중단 시간을 최소화하는 데 있다.

1. 에러 메시지의 구조와 의미 이해

브라우저가 특정 사이트에 연결하지 못할 때 공통적으로 나타나는 문구가 “This site can’t be reached”이다. 이는 세부 원인 코드와 함께 표시되며, 대개 DNS 해석 실패, TCP 연결 실패, TLS 핸드셰이크 실패, 프록시·방화벽 차단, 라우팅 불량 등으로 귀결된다. 오류 문구의 하단에 있는 에러 코드를 확인하면 조치의 우선순위를 빠르게 정할 수 있다.

표시 에러 코드	주요 원인	즉시 조치 우선순위	해결 키포인트
DNS_PROBE_FINISHED_NXDOMAIN	도메인 이름 해석 실패	공용 DNS 전환 → DNS 캐시 초기화	nslookup 결과 확인, hosts 충돌 점검
ERR_CONNECTION_TIMED_OUT	서버 응답 지연 또는 경로 장애	다른 네트워크 테스트 → 방화벽·VPN 점검	tracert/tracepath로 홉 지연 확인
ERR_CONNECTION_REFUSED	목적지 포트 거부	서버 상태·포트 오픈 여부 점검	telnet/netcat으로 포트 접근성 확인
ERR_NAME_NOT_RESOLVED	로컬 또는 업스트림 DNS 해석 실패	DNS 전환 → 네트워크 재시작	DoH 비활성화 후 재시도
ERR_SSL_PROTOCOL_ERROR / ERR_SSL_VERSION_OR_CIPHER_MISMATCH	TLS 설정 불일치	시스템 시간 동기화 → TLS 검사 예외 확인	회사망 SSL 검사 정책 확인
ERR_PROXY_CONNECTION_FAILED	프록시 설정 오류	프록시 자동 감지 해제 → 시스템 프록시 초기화	WPAD/PAC 충돌 점검

2. 1분 복구 체크리스트(현장 즉시 적용)

다른 사이트(예: 공용 포털) 접속을 시도하여 전체망 장애인지 특정 사이트 장애인지 구분한다.
다른 브라우저로 같은 URL을 열어 애플리케이션 이슈인지 확인한다.
주소표기 오류를 배제하기 위해 http/https 스킴과 철자를 다시 입력한다.
브라우저 새로고침(하드 리로드: Windows Ctrl+F5, macOS Cmd+Shift+R)을 실행한다.
브라우저 DNS 캐시와 소켓 풀을 초기화한다(크롬: 주소창에 chrome://net-internals/#dns → Clear host cache → Sockets에서 Flush sockets).
Wi-Fi/유선 연결을 끊었다가 다시 연결한다. 테더링이나 모바일 핫스팟으로 우회 연결을 시도한다.
DNS를 공용 DNS로 즉시 전환한다(예: 1.1.1.1, 8.8.8.8). 전환 후 재접속한다.
프록시와 VPN을 잠시 비활성화하고 재시도한다.
보안 프로그램의 웹 차단 기능을 일시 중지하고 접속을 확인한다(가능한 경우 신뢰목록에 대상 도메인을 추가한다).
라우터·모뎀 전원을 10초 이상 차단 후 재가동한다.

3. 원인별 정밀 진단 루틴

3.1 DNS 이슈 진단

증상 : NXDOMAIN, NAME_NOT_RESOLVED, 간헐적 접속, 특정 ISP에서만 실패한다.
확인 : nslookup 도메인 또는 dig 도메인으로 A/AAAA/CNAME 응답을 점검한다.
조치 :
- 로컬 DNS 캐시 초기화: Windows ipconfig /flushdns, macOS sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder, Linux sudo systemd-resolve --flush-caches 등 적용한다.
- 공용 DNS 설정: IPv4 우선 1.1.1.1, 8.8.8.8, 보조 1.0.0.1, 8.8.4.4로 지정한다.
- DoH(DNS over HTTPS) 기능을 끄거나 다른 제공자 프로필로 전환한다.
- hosts 파일에 오래된 매핑이 있으면 주석 처리한다.

3.2 라우팅·지연 이슈 진단

증상 : TIMEOUT, 특정 시간대만 느리거나 실패한다.
확인 : ping으로 왕복지연을 확인하고, tracert(Windows) 또는 tracepath/traceroute로 경로상 타임아웃 홉을 찾는다.
조치 :
- 다른 네트워크로 우회하여 경로 이슈를 배제한다.
- VPN을 끄고 직접 경로로 접근한다.
- 라우터 MTU를 1500 또는 환경에 맞는 값으로 조정하고, ping -f -l(Windows)로 단편화 확인을 수행한다.

3.3 프록시·보안 소프트웨어·방화벽 이슈

증상 : 회사망에서만 실패, 가정망·모바일에서는 정상이다.
확인 : 시스템 프록시 설정, 브라우저 확장, 보안 제품의 웹 필터를 점검한다.
조치 :
- 프록시 자동설정(PAC/WPAD) 해제 후 수동 연결을 시도한다.
- SSL/TLS 가로채기(SSL inspection) 정책이 있는 경우 SNI, 최신 TLS 버전 호환성 예외를 요청한다.
- 사내 방화벽에서 목적지 FQDN 또는 포트(80, 443) 허용 정책을 확인한다.

3.4 애플리케이션·TLS 이슈

증상 : SSL 관련 에러, 특정 브라우저에서만 실패한다.
확인 : 시스템 날짜·시간, 루트 인증서 스토어, 브라우저 프로파일 손상을 확인한다.
조치 :
- 시스템 시간 NTP 동기화 후 재시도한다.
- 브라우저 프로파일을 새로 만들고 확장 프로그램을 비활성화한다.
- QUIC 사용 시 비활성화하고 증상을 비교한다.

4. 운영체제별 빠른 조치 가이드

4.1 Windows 10/11

명령 프롬프트(관리자)에서 ipconfig /flushdns 실행한다.
netsh winsock reset 후 재부팅한다.
네트워크 어댑터 속성에서 IPv4 DNS를 공용 DNS로 설정한다.
프록시 자동 검색을 해제한다(설정 > 네트워크 및 인터넷 > 프록시).
Windows 방화벽 인바운드·아웃바운드 규칙에서 브라우저 차단이 없는지 확인한다.

4.2 macOS

터미널에서 sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder 실행한다.
네트워크 > 고급 > DNS에서 공용 DNS를 추가한다.
프록시 탭에서 체크박스를 모두 해제한 후 재시도한다.
키체인 접근에서 신뢰되지 않은 루트 인증서가 활성화되어 있지 않은지 확인한다.

4.3 Linux

systemd-resolved 사용 시 sudo systemd-resolve --flush-caches 실행한다.
/etc/resolv.conf 또는 NetworkManager에서 DNS를 공용 DNS로 교체한다.
iptables·nftables 규칙과 ufw 상태를 확인한다.

4.4 Android

네트워크 설정에서 개인 DNS를 해제하거나 공용 프로바이더로 지정한다.
Wi-Fi를 껐다가 켠 후, 다른 AP 또는 LTE로 우회하여 재시도한다.
브라우저·앱 캐시를 삭제한다.

4.5 iOS/iPadOS

설정 > 일반 > 전송 또는 재설정 > 네트워크 설정 재설정을 실행한다.
Wi-Fi를 해제 후 다시 연결하고, 셀룰러 데이터로 우회 테스트를 한다.
VPN 또는 개인용 DNS 설정이 있으면 비활성화한다.

5. 명령어·설정 요약표

플랫폼	캐시 초기화	DNS 전환	프록시 해제
Windows	`ipconfig /flushdns`, `netsh winsock reset`	어댑터 IPv4 DNS에 1.1.1.1/8.8.8.8 입력	설정 > 프록시 > 자동 검색 해제
macOS	`dscacheutil` + `mDNSResponder` 재시작	네트워크 > 고급 > DNS 추가	프록시 탭 체크 해제
Linux	`systemd-resolve --flush-caches`	`/etc/resolv.conf` 또는 NM에서 설정	데스크톱 환경 네트워크 프록시 해제
Android	앱 캐시 삭제	개인 DNS 비활성/전환	VPN·프록시 앱 종료
iOS	네트워크 설정 재설정	프로파일 또는 DNS 앱 비활성	VPN 토글 오프

6. DNS 제공자 전환 가이드

DNS 이슈는 가장 빈번하고 영향 범위가 넓다. 공용 DNS는 전파가 빠르고 캐시 품질이 균일하여 문제를 신속히 우회할 수 있다.

제공자	IPv4	IPv6	특징
Cloudflare	1.1.1.1 / 1.0.0.1	2606:4700:4700::1111	빠른 응답, 개인정보 보호 강조
Google	8.8.8.8 / 8.8.4.4	2001:4860:4860::8888	안정적, 전 세계 PoP 분포
Quad9	9.9.9.9	2620:fe::9	악성 도메인 필터 옵션

7. 프록시·VPN·보안 제품과의 상호작용

프록시 자동 구성(PAC) 스크립트가 실패하면 모든 트래픽이 차단될 수 있다. 일시적으로 수동 또는 직접 연결로 전환하고 접속을 확인한다.
VPN은 경로와 DNS를 바꾼다. 회사 VPN 분할 터널링이 꺼져 있으면 인터넷 전 구간이 사내망을 경유한다. 필요 시 분할 터널링 예외를 요청한다.
보안 제품의 웹 보호 기능은 SSL 가로채기 방식을 사용한다. 루트 인증서 배포가 누락되면 TLS 오류가 발생한다. 정책 팀에 예외 등록을 요청한다.

8. 서버·도메인 측 이슈를 사용자 단에서 구분하는 법

다른 네트워크에서 동일 URL이 정상이라면 사용자 환경 이슈 가능성이 높다.
다른 도메인은 정상이나 특정 도메인만 실패하면 해당 도메인의 DNS·WAF·CDN 설정 이슈 가능성이 있다.
HTTP 포트 80은 열리나 443에서만 실패하면 TLS 또는 인증서 체인 설정 문제일 수 있다.
AAAA 레코드가 있고 IPv6 경로가 불안정하면 브라우저가 IPv6을 우선 사용하며 실패한다. 임시로 IPv6 비활성화를 테스트한다.

9. 기업 환경 특수 이슈 체크리스트

SSL inspection 활성화 여부 확인한다.
SNI 필드가 WAF 정책과 충돌하지 않는지 확인한다.
QUIC(UDP/443) 차단 정책이 있는지 확인한다. 필요 시 QUIC 비활성 후 재시도한다.
DNS split-horizon 환경에서 외부망과 내부망의 레코드가 다른지 점검한다.
프록시 인증 토큰 만료로 인한 세션 차단 여부를 확인한다.

10. 크롬·엣지 브라우저 특화 조치

chrome://net-internals/#dns에서 Clear host cache 실행한다.
chrome://net-export로 로그를 30초 수집하고 실패 재현 후 내보내 분석한다.
시크릿 모드에서 재시도하여 확장·쿠키 간섭을 배제한다.
프로파일 새로 만들기 후 동일 증상을 비교한다.

11. 단계별 고장 진단 트리

1단계 전체망 vs 특정 사이트 구분한다.
2단계 다른 브라우저·기기·네트워크로 A/B 테스트한다.
3단계 DNS 전환 및 캐시 초기화 후 재시도한다.
4단계 프록시·VPN·보안 제품을 잠시 해제한다.
5단계 tracert로 경로를 확인하고 경유지 타임아웃을 기록한다.
6단계 문제 재현 시각, 에러 코드, 네트워크 변경 사항을 기록하여 관리 부서에 전달한다.

12. 자주 묻는 실무 포인트

호스트 파일 충돌 : 이전 프로젝트에서 임시 매핑한 레코드가 남아 있을 수 있다. 해당 라인을 주석 처리한다.
캐시 전파 지연 : 도메인 TTL 변경 직후 지역 DNS마다 결과가 다를 수 있다. 수 분~수 시간 간격으로 재시도한다.
CDN·WAF 차단 : 회사망 아이피 평판이 낮으면 보안 솔루션이 차단한다. 모바일망으로 우회하여 확인한다.
IPv6 우선 문제 : IPv6 경로가 불안정하면 임시로 비활성화하고 개선 여부를 본다.

13. 문제 재발 방지를 위한 베스트 프랙티스

신뢰할 수 있는 공용 DNS를 기본값으로 설정하고 DHCP에도 반영한다.
브라우저·OS를 최신 상태로 유지한다.
프록시·VPN 정책 변경 시 사전 공지를 받고 예외 목록을 정기 검토한다.
중요 도메인 목록에 대해 주기적으로 nslookup과 HTTP 헬스체크를 수행한다.
라우터·스위치 펌웨어를 최신으로 유지하고 MTU·QoS를 환경에 맞게 조정한다.

14. 현장 예시: 에러 코드별 신속 조치 시나리오

사례 A : “DNS_PROBE_FINISHED_NXDOMAIN”이 반복되는 경우, 공용 DNS로 전환 후 ipconfig /flushdns를 실시하고, nslookup으로 즉시 응답을 확인한다. 1분 내 정상화되는 경우가 많다.

사례 B : “ERR_CONNECTION_TIMED_OUT”이며 모바일 테더링에서는 정상인 경우, 회사망 방화벽 또는 경로 이슈 가능성이 높다. VPN을 끄고 재시도하거나 네트워크 팀에 특정 구간 지연을 보고한다.

사례 C : “ERR_PROXY_CONNECTION_FAILED” 표시 시, 프록시 자동 구성 해제 후 직접 연결을 시도한다. PAC 스크립트 서버 장애가 원인일 수 있다.

15. 실무용 점검 체크리스트 템플릿

항목	체크 방법	기록 값	상태
증상 재현 시간	오류 발생 시각 기록	YYYY-MM-DD hh:mm	정상/이상
에러 코드	브라우저 하단 확인	예: NXDOMAIN	정상/이상
대체 네트워크	모바일 핫스팟 시도	성공/실패	정상/이상
DNS 전환	공용 DNS 설정	1.1.1.1, 8.8.8.8	정상/이상
프록시/VPN	비활성 후 재시도	성공/실패	정상/이상
경로 지연	tracert 결과	타임아웃 홉 번호	정상/이상

16. 문제 해결 스크립트 모음

# Windows
ipconfig /flushdns
netsh winsock reset
netsh int ip reset

# macOS

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux(systemd)

sudo systemd-resolve --flush-caches

# 경로 확인

# Windows

tracert example.com

# macOS/Linux

traceroute example.com

FAQ

도메인은 열리지만 이미지·스크립트만 로드되지 않는다. 왜 그런가?

CDN 서브도메인 또는 서브리소스 도메인의 DNS·WAF 정책이 달라 차단될 수 있다. 개발자 도구 네트워크 탭에서 실패 리소스의 도메인을 식별하고 해당 도메인에 대해 동일한 진단 절차를 적용한다.

사내에서는 안 열리는데 집에서는 열린다. 어디를 의심해야 하나?

프록시·VPN·방화벽 또는 SSL 검사 정책을 우선 점검한다. 분할 터널링, SNI 예외, QUIC 차단 정책을 확인한다.

DNS를 바꿨는데도 NXDOMAIN이 지속된다. 추가로 무엇을 하여야 하나?

로컬 hosts 파일을 점검하고, 브라우저·OS 캐시를 모두 초기화한다. 그래도 동일하면 도메인 자체의 권한 DNS 설정 오류 가능성이 있으므로 관리자에게 질의한다.

ERR_CONNECTION_REFUSED는 내 쪽 문제인가 서버 문제인가?

대개 서버나 중간 장비가 해당 포트를 수신하지 않을 때 발생한다. 다른 네트워크에서도 동일하면 서버 측 문제 가능성이 크다.

일시적으로만 실패한다. 어떻게 원인을 추적해야 하나?

증상 시간대, IP, 에러 코드, 경로 지연을 로그로 남기고 크롬 net-export 로그를 병행 수집한다. 반복 패턴을 찾아 네트워크 팀과 공유한다.

ZeroError_holic

이 블로그 검색

파워포인트 자막(라이브 캡션) 안될 때 1분 진단과 완전 해결 가이드