한눈에 보기
브라우저 오류 화면의 영문 코드는 "어느 단계에서 연결이 실패했는지"를 알려주는 가장 빠른 단서입니다. 이 글은 위 열 가지 코드를 이름 해석(DNS) → 연결(TCP) → 암호화(TLS) → 응답(HTTP)이라는 순서에 놓고 읽는 법과, 코드를 본 뒤 일반적으로 거치는 점검 순서를 정리합니다. 일반 정보이며 개별 환경의 원인을 확정해 주지는 않습니다.
- ERR_로 시작하는 코드는 크로미움(크롬·엣지 등)이 내부 오류 목록에서 꺼내 보여주는 이름이고, 서버가 보낸 HTTP 상태 코드(404, 503 등)와는 다른 층의 정보입니다.
- 코드 이름에는 실패한 단계가 들어 있는 경우가 많습니다(NAME_NOT_RESOLVED는 이름 해석, SSL_PROTOCOL_ERROR는 TLS).
- 같은 증상이 여러 사이트에서 동시에 나타나면 내 기기·네트워크 쪽, 한 사이트에서만 나타나면 그 사이트 쪽을 먼저 의심하는 것이 일반적인 순서입니다.
- 인증서 경고는 "연결 실패"가 아니라 "신뢰할 수 없음" 경고이므로, 무시하고 진행하기 전에 의미를 알아야 합니다.
크롬·엣지 기준 코드입니다
여기서 다룬 ERR_ 형태의 코드는 크롬과 엣지 같은 크로미움 기반 브라우저에서 표시되는 표기 방식입니다. 파이어폭스나 사파리는 같은 원인이라도 "안전한 연결을 설정할 수 없습니다" 같은 다른 문구로 안내하므로, 브라우저마다 표시되는 문구가 다를 수 있다는 점을 참고하세요.
코드는 어디에서 오는가: 크로미움의 오류 목록
크로미움 소스의 네트워크 오류 정의 파일(net/base/net_error_list.h)에는 오류마다 이름과 음수 번호, 한 줄 설명이 적혀 있습니다. 화면에 보이는 "ERR_"는 이 이름 앞에 붙는 접두어입니다. 아래는 이 파일에서 직접 확인한 항목입니다.
| 화면 코드 | 내부 번호 | 정의 파일의 설명(요지) |
|---|---|---|
| ERR_NETWORK_CHANGED | -21 | 네트워크가 바뀌었다 |
| ERR_CONNECTION_RESET | -101 | 연결이 초기화되었다(TCP RST에 해당) |
| ERR_CONNECTION_REFUSED | -102 | 연결 시도가 거부되었다 |
| ERR_NAME_NOT_RESOLVED | -105 | 호스트 이름을 해석할 수 없다 |
| ERR_INTERNET_DISCONNECTED | -106 | 인터넷 연결이 끊어졌다 |
| ERR_SSL_PROTOCOL_ERROR | -107 | SSL 프로토콜 오류가 발생했다 |
| ERR_ADDRESS_UNREACHABLE | -109 | IP 주소에 도달할 수 없다(보통 해당 호스트·네트워크로 가는 경로 없음) |
| ERR_CONNECTION_TIMED_OUT | -118 | 연결 시도가 시간 초과되었다 |
| NET::ERR_CERT_AUTHORITY_INVALID | -202 | 서버 인증서가 클라이언트가 신뢰하지 않는 기관에서 서명되었다(가로채기, 서버 설정 오류, 자체 서명 인증서일 수 있음) |
| ERR_TOO_MANY_REDIRECTS | -310 | URL을 불러오는 중 리다이렉트가 너무 많았다 |
| ERR_EMPTY_RESPONSE | -324 | 서버가 데이터를 보내지 않고 연결을 닫았다 |
참고로 DNS_PROBE_FINISHED_NXDOMAIN은 위 목록에서 확인하지 못했기 때문에 번호를 적지 않았습니다. 이름 해석 실패와 관련해 크롬이 보여주는 메시지로 이해하되, 정확한 내부 동작은 크로미움 문서를 확인하세요. 번호는 크로미움 내부 값이므로 일상적인 문제 해결에는 이름만 알면 충분합니다.
실패한 단계로 읽기: DNS에서 HTTP까지
웹페이지가 열리기까지의 일반적인 순서에 열 가지 코드를 놓으면, 코드가 "어느 단계에서 막혔는지"가 보입니다.
| 단계 | 하는 일 | 이 단계에서 보이는 코드 |
|---|---|---|
| 0. 기기 네트워크 | 와이파이·랜 등 기본 연결 | ERR_INTERNET_DISCONNECTED, ERR_NETWORK_CHANGED, ERR_ADDRESS_UNREACHABLE |
| 1. 이름 해석(DNS) | 도메인을 IP 주소로 변환 | ERR_NAME_NOT_RESOLVED, DNS_PROBE_FINISHED_NXDOMAIN |
| 2. 연결(TCP) | 서버의 포트와 연결 수립 | ERR_CONNECTION_REFUSED, ERR_CONNECTION_TIMED_OUT, ERR_CONNECTION_RESET |
| 3. 암호화(TLS) | 인증서 검증과 암호화 협상 | ERR_SSL_PROTOCOL_ERROR, NET::ERR_CERT_AUTHORITY_INVALID |
| 4. 요청·응답(HTTP) | 페이지 요청과 응답 수신 | ERR_EMPTY_RESPONSE, ERR_TOO_MANY_REDIRECTS (정상 수신 시 서버가 보낸 4xx·5xx 상태 코드) |
이렇게 보면 "거부(REFUSED)"와 "시간 초과(TIMED_OUT)"의 차이도 분명해집니다. 거부는 상대 쪽에서 응답이 왔다는 뜻(연결을 받지 않겠다는 응답)이고, 시간 초과는 응답 자체가 오지 않았다는 뜻입니다. 그래서 일반적으로 REFUSED는 "서버 컴퓨터는 있는데 그 포트에서 받는 프로그램이 없거나 막힘", TIMED_OUT은 "중간 경로에서 패킷이 사라지거나 서버가 응답하지 못함"으로 점검을 시작합니다.
브라우저 오류와 HTTP 상태 코드는 다릅니다
ERR_ 코드는 서버와 대화가 성립하기 전이나 도중에 브라우저가 스스로 판단한 실패입니다. 반면 404, 503 같은 숫자는 서버(또는 중간 프록시)가 응답으로 보낸 HTTP 상태 코드로, RFC 9110(HTTP Semantics, 2022)이 의미를 정의합니다. 아래는 RFC 9110 본문에서 확인한 정의 요지입니다.
| 코드 | RFC 9110의 의미(요지) |
|---|---|
| 301 / 308 | 대상이 영구적으로 새 URI로 옮겨졌다. 308은 요청 방식(메서드) 변경을 원하지 않을 때 권장되는 영구 이동 |
| 302 / 307 | 임시로 다른 URI에 있다. 307은 자동 리다이렉트 때 요청 방식을 바꾸면 안 됨 |
| 502 Bad Gateway | 게이트웨이·프록시 역할의 서버가 상위 서버로부터 잘못된 응답을 받았다 |
| 503 Service Unavailable | 일시적 과부하나 점검 등으로 요청을 처리할 수 없다. Retry-After 헤더로 대기 시간을 알릴 수 있다 |
| 504 Gateway Timeout | 게이트웨이·프록시 역할의 서버가 상위 서버로부터 제때 응답을 받지 못했다 |
ERR_TOO_MANY_REDIRECTS는 이 중 301·302 등 리다이렉트 응답이 순환할 때 생깁니다. RFC 9110은 클라이언트가 순환 리다이렉트를 감지해 중단해야 한다고 설명하며, 과거 규격이 최대 다섯 번을 권고했던 점도 언급합니다. 더 자세한 상태 코드 설명은 HTTP 상태 코드 가이드에서 볼 수 있습니다.
실제 사례: 오류 화면이 내 문제가 아니었던 날
Cloudflare, 2019년 7월 2일: 502 오류
Cloudflare가 공개한 사후 분석에 따르면, 2019년 7월 2일 13:42(UTC)쯤 방화벽(WAF) 관리 규칙 업데이트가 배포되었고, 이 규칙에 포함된 정규 표현식이 과도한 역추적을 일으켜 HTTP/HTTPS를 처리하는 서버의 CPU 사용률이 거의 100%에 이르렀습니다. 그 결과 고객 사이트 방문자는 502 오류를 받았고, 회사는 14:07에 WAF를 전 세계적으로 끄는 조치(글로벌 종료)를 실행했으며 14:09에는 트래픽과 CPU가 정상 수준으로 돌아왔다고 설명합니다. 장애는 약 27분이었고, WAF는 원인을 확인한 뒤 14:52에 다시 켜졌습니다. 이 사례의 요점은 방문자가 아무리 캐시를 지우고 DNS를 바꿔도 해결되지 않는 종류의 오류가 있다는 점입니다. 한 사이트만이 아니라 같은 서비스를 쓰는 여러 사이트에서 동시에 오류가 보인다면 사이트 운영 쪽 문제를 의심해볼 만합니다.
Fastly, 2021년 6월 8일: 광범위한 오류
Fastly의 사후 분석에 따르면 2021년 6월 8일 09:47(UTC)에 전 세계적 장애가 시작되어 네트워크의 85%가 오류를 반환했고, 49분 안에 네트워크의 95%가 정상으로 돌아왔다고 합니다. 원인은 5월 12일부터 배포된 소프트웨어에 숨어 있던 버그였으며, 한 고객이 유효한 설정 변경을 적용하자 특정 조건에서 그 버그가 작동했다고 설명합니다. 모니터링은 약 1분 만에 장애를 감지했고, 원인이 된 고객 설정은 10:27에 확인되었습니다. 이 사례의 교훈은 "유효한 설정도 예상 못한 버그를 건드릴 수 있다"는 점과, 이용자 입장에서는 여러 유명 사이트가 한꺼번에 열리지 않으면 개인 환경이 아닌 공급자 장애일 수 있다는 점입니다. 이용자가 본 화면의 구체적인 오류 코드는 사후 분석에서 확인하지 못해 적지 않았습니다.
직접 해보기: 코드를 본 뒤의 점검 순서
아래는 일반적인 점검 순서이며, 모든 환경에서 같은 효과를 보장하지는 않습니다.
- 다른 사이트도 열리는지 확인합니다. 모두 안 되면 기기·공유기·회선 쪽(0단계)을 먼저 봅니다.
- 같은 주소를 다른 기기나 모바일 데이터에서 열어봅니다. 거기서 열리면 내 기기·네트워크 설정(DNS, 프록시, 보안 프로그램)이 원인일 가능성이 높아집니다.
- 이름 해석 오류라면 주소 철자를 확인하고, DNS 캐시 비우기나 다른 DNS 서버 사용을 시도합니다. 새로 등록한 도메인이라면 DNS 전파 시간이 필요할 수 있습니다.
- 연결 오류(REFUSED·TIMED_OUT)라면 주소와 포트가 맞는지, 서버를 운영하는 쪽이라면 서비스가 실행 중이고 방화벽에서 열려 있는지 확인합니다.
- TLS·인증서 오류라면 기기의 날짜와 시간이 맞는지 확인합니다. 인증서 유효성 검증은 현재 시각에 의존하기 때문입니다. 그래도 계속되면 사이트 운영자의 인증서 설정 문제일 수 있습니다.
- 리다이렉트·빈 응답 오류라면 해당 사이트 쿠키를 지우거나 시크릿 모드로 열어봅니다. 서버 운영자라면 리다이렉트 규칙과 서버 로그를 확인합니다.
흔한 오해와 정정
- 오해: ERR_ 코드가 뜨면 사이트가 망가진 것이다. 실제: 내 기기의 네트워크, DNS, 보안 프로그램, 중간 경로 등 어느 단계에서든 생길 수 있습니다. 위 단계 표대로 범위를 좁히는 것이 먼저입니다.
- 오해: 502·503이 뜨면 내 쪽을 고쳐야 한다. 실제: 5xx는 서버 측 상태를 뜻하는 코드이므로 방문자가 할 일은 대개 잠시 후 재시도하는 정도입니다.
- 오해: 인증서 경고는 "고급 → 계속 진행"으로 넘어가면 그만이다. 실제: 크로미움 정의 파일도 이 오류가 가로채기, 서버 설정 오류, 자체 서명 인증서 모두를 뜻할 수 있다고 설명합니다. 원인을 모른 채 로그인·결제 정보를 입력하는 것은 피하는 편이 안전합니다.
- 오해: 캐시를 지우면 대부분 해결된다. 실제: 캐시·쿠키는 리다이렉트 순환 같은 일부 증상에만 관련이 있고, DNS나 연결 단계 오류와는 무관한 경우가 많습니다.
한계와 더 알아볼 점
오류 이름은 브라우저가 관측한 증상을 요약한 것이어서 원인을 하나로 확정하지 못합니다. 예를 들어 ERR_CONNECTION_TIMED_OUT은 서버 다운, 경로 문제, 방화벽 폐기 중 무엇이든 될 수 있고, ERR_CONNECTION_RESET도 서버·방화벽·보안 장비 등 여러 곳에서 연결을 끊을 때 나올 수 있습니다. 또한 크로미움의 오류 목록은 버전에 따라 항목이 추가되거나 표시 문구가 바뀔 수 있으므로, 최신 정의는 크로미움 소스와 브라우저 도움말을 확인하세요. 사이트 운영 중이라면 브라우저 화면만이 아니라 서버 로그와 모니터링을 함께 봐야 정확합니다.
먼저 네트워크 자체를 점검하고 싶다면
같은 증상이 여러 사이트에서 동시에 나타난다면 브라우저보다 네트워크 자체의 문제일 가능성이 높습니다.네트워크 진단 명령어로 인터넷 문제 찾는 방법과핑(Ping)으로 인터넷 연결 상태 진단하는 방법을 함께 확인해보세요. 이름 해석 단계가 궁금하다면 DNS 조회 과정도 이어서 읽어볼 만합니다.
인증서 오류가 반복된다면
NET::ERR_CERT_AUTHORITY_INVALID 같은 인증서 관련 오류가 특정 사이트에서 계속 나타난다면SSL/TLS 인증서란? 기초 개념 정리도 참고해 원인을 이해해두면 좋습니다.
자주 묻는 질문
새로고침을 여러 번 해도 안 되면 어떻게 하나요?
브라우저 캐시와 쿠키를 삭제해보거나 시크릿 모드로 접속해 확장 프로그램 충돌 여부를 확인해보세요. 그래도 안 된다면 다른 기기나 다른 네트워크(모바일 데이터 등)에서 같은 사이트가 열리는지 비교해보는 것이 원인 파악에 도움이 됩니다.
이 오류가 뜨면 내 정보가 유출된 건가요?
대부분의 네트워크 에러 코드는 단순한 연결 실패를 나타낼 뿐 정보 유출과는 관계가 없습니다. 다만 낯선 인증서 경고를 무시하고 개인정보나 결제 정보를 입력하는 것은 위험할 수 있으니, 인증서 오류가 뜬 사이트에서는 민감한 정보 입력을 피하는 것이 안전합니다.
ERR_CONNECTION_REFUSED와 ERR_CONNECTION_TIMED_OUT은 어떻게 구분해 점검하나요?
REFUSED는 상대 쪽에서 연결을 받지 않겠다는 응답이 돌아온 경우이고, TIMED_OUT은 응답이 오지 않은 경우입니다. 일반적으로 REFUSED는 해당 포트에서 서비스가 실행 중인지와 접속 주소·포트가 맞는지를, TIMED_OUT은 경로 중간의 방화벽이나 회선, 서버 다운 여부를 먼저 살펴봅니다.
ERR_NAME_NOT_RESOLVED와 DNS_PROBE_FINISHED_NXDOMAIN은 같은 건가요?
둘 다 이름 해석 단계의 문제를 알리지만 같은 문구는 아닙니다. NXDOMAIN은 DNS가 "그런 이름은 없다"고 응답했다는 의미의 일반적인 DNS 용어이므로 주소 오타나 만료·미등록 도메인을 먼저 의심하고, NAME_NOT_RESOLVED는 DNS 서버에 닿지 못한 경우까지 포함해 나올 수 있어 내 쪽 DNS 설정과 연결 상태도 함께 봅니다.
ERR_TOO_MANY_REDIRECTS는 방문자가 고칠 수 있나요?
쿠키가 꼬인 경우에는 해당 사이트의 쿠키를 지워 해결되기도 합니다. 하지만 사이트 설정 자체가 A와 B를 번갈아 보내는 구조라면 방문자가 해결할 수 없고 운영자가 리다이렉트 규칙(예: HTTP와 HTTPS, www 유무 설정의 충돌)을 고쳐야 합니다.
이어 읽기
HTTP 상태 코드, DNS 레코드 종류,HTTP 프로토콜의 발전도 함께 보면 오류 화면의 앞뒤 맥락이 이어집니다.