NET::ERR_ADDRESS_UNREACHABLE 원인

Problem

Chrome(또는 Chromium 계열 브라우저)이 NET::ERR_ADDRESS_UNREACHABLE로 페이지 로드를 거부합니다. 이름은 잘 해석됐습니다 — DNS를 못 찾은 에러가 아닙니다 — 그런데 받은 주소로 연결을 열려는 순간, 운영체제가 거기로 갈 방법이 없다고 답한 겁니다.

Chrome 자체 에러 테이블은 딱 잘라 말합니다: 에러 코드 -109, “IP 주소에 닿을 수 없다. 대개 지정된 호스트나 네트워크로 가는 경로가 없다는 뜻이다.” 그 마지막 구절이 진단 전체를 한 줄로 담고 있습니다. 사이트가 느린 것도, 당신을 거부하는 것도, 사라진 것도 아닙니다. 문제는 당신 기기가 닿으려 한 그 특정 IP 주소가 당신 네트워크 밖으로 나가는 경로가 없다는 것입니다.

Symptoms

• 에러 문구가 ERR_ADDRESS_UNREACHABLE입니다 — ERR_NAME_NOT_RESOLVED(DNS는 됨)도, ERR_CONNECTION_TIMED_OUT(타임아웃 날 실제 시도조차 없었음)도 아닙니다.
• 네트워크를 자주 탑니다: 한 Wi-Fi에선 깨지고, 셀룰러나 다른 연결에선 멀쩡합니다. 그 갈림이 가장 큰 단서입니다.
• 다른 건 다 열리는데 한 사이트만 이럴 수 있습니다 — 그 호스트가 당신 망이 못 가는 주소로 해석되고, 나머지는 아니라서요.
• 빨리 뜹니다. 기다리게 만드는 타임아웃과 달리, ‘경로 없음’은 스택이 배달 못 할 패킷을 아예 안 보내기 때문에 거의 즉시 돌아옵니다.
• 서버측 IPv6 변경 직후, 또는 서비스를 새 IP로 옮긴 직후에 나타나거나 심해집니다.

‘경로 없음’이 별개의 실패인 이유

대부분의 연결 에러는 패킷이 상대편에 닿은 뒤 벌어지는 일입니다: 거부당하거나(RESET), 아무도 안 받거나(TIMED_OUT), TLS 협상이 깨지거나. ERR_ADDRESS_UNREACHABLE는 그 전에 벌어집니다. 기기가 호스트를 IP로 해석하고, 라우팅 테이블을 보고, 그 주소로 가는 경로를 못 찾았습니다 — 그 주소를 덮는 기본 경로도, 실어 나를 인터페이스도 없이. 애초에 회선에 오르질 못한 겁니다.

2026년 현재 압도적으로 흔한 방아쇠는 IPv6입니다. 브라우저는 호스트가 AAAA 레코드를 게시하면 IPv6를 우선해서 IPv4 A 레코드와 경주시킵니다(Happy Eyeballs, RFC 8305). v6 경로가 되면 아무것도 못 느낍니다. 안 되면 — 클라이언트가 link-local IPv6 주소만 갖고 있거나, 라우터가 IPv6를 광고하지만 작동하는 상위 경로가 없거나, 방화벽이 나가는 v6를 버리거나 — AAAA 주소로 닿으려는 시도가 “unreachable”을 돌려줍니다. Happy Eyeballs가 IPv4로 폴백해서 이걸 가려줘야 하고 보통은 그렇지만, 잘못 설정된 망에서의 단호한 “no route to host”는 가려지지 않고 에러로 표출될 수 있습니다.

이야기의 나머지 절반은 서버측입니다: 실제로 IPv6를 듣지 않는 호스트에 게시된 AAAA, 또는 이제 아무 데로도 라우팅되지 않는 폐기된 IP를 여전히 가리키는 A 레코드. 두 경우 모두 DNS가 아무 데도 못 가는 주소를 건네줍니다.

Top Causes

1. AAAA 레코드가 있는 호스트 + 클라이언트 망의 깨진 IPv6 경로 - 가장 흔합니다. 사이트가 IPv6를 게시하고, 브라우저가 그걸 먼저 시도하는데, 당신 망이 IPv6를 라우팅 못 합니다. 그 Wi-Fi에선 깨지고 진짜 IPv6가 있거나 아예 없는 곳에선 됩니다.

2. IPv6를 서빙하지 않는 서버의 AAAA 레코드 - 끝내지 못한 전환 중에 v6 주소를 넣었거나 템플릿을 복사했거나. 주소는 DNS에 있는데 거기서 아무것도 안 들어서, 그걸 우선하는 모든 클라이언트가 죽은 경로에 부딪힙니다. 이건 사이트 소유자가 고칠 문제이고, 한 망이 아니라 많은 방문자에게 깨집니다.

3. 폐기된 IP를 가리키는 낡은 A 레코드 - 서버가 옮겨갔고, 옛 주소는 회수됐고, 이제 이름이 어디로도 라우팅 안 되는 IP로 해석됩니다. 같은 증상, IPv4 버전.

4. 엉뚱한 클라이언트에 넘어간 사설·비라우팅 주소 - split-horizon DNS가 내부망에 없는 클라이언트에게 RFC 1918 주소(10.x나 192.168.x)를 흘린 경우. 클라이언트는 자기가 속하지 않은 사설 대역으로 갈 경로가 없습니다.

5. 로컬 라우팅 또는 VPN 문제 - 기기에 기본 경로가 없거나, split-tunnel VPN이 그 목적지 경로를 삼켰거나, 라우터가 상위 연결을 잃었거나. 여기선 잘못이 전적으로 로컬이고 DNS는 무죄입니다.

DechoNet으로 진단

• DNS 조회는 이름이 건네는 주소를 정확히 보여줍니다 — A(IPv4)와 AAAA(IPv6) 둘 다. 그게 갈림길입니다: AAAA가 있는데 당신 망의 IPv6가 깨졌거나 없다면, 찾은 겁니다. 유일한 주소가 이제 응답 안 하는 곳을 가리키는 A 레코드뿐이라면, 낡은 IP 케이스고요. 이름이 실제로 무엇으로 해석되는지를 당신 망 밖에서 보면, “레코드가 틀렸다”와 “내 망이 맞는 레코드로 라우팅을 못 한다”가 갈립니다.
• 포트 점검은 해석된 주소가 필요한 포트(보통 443)에서 실제로 연결을 받는지 시험합니다. 외부 시점에서, 그 주소로 서버에 애초에 닿을 수 있는지를 알려줘서 “전 세계가 이 IP에 못 닿는다”와 “내 망만 못 닿는다”를 깔끔히 가릅니다.

Resolution Checklist

• DNS 점검을 돌려 두 레코드를 다 읽으세요. A(IPv4) 외에 AAAA(IPv6) 주소가 있는지 확인. 있다면 IPv6가 첫 용의자입니다.
• 두 번째 망에서 테스트하세요. 셀룰러나 다른 연결로 사이트를 열어보세요. 거기선 되고 첫 망에선 안 되면, 잘못은 그 망의 경로 — 대개 IPv6 — 이지 사이트가 아닙니다.
• 도메인을 관리하는데 AAAA가 실제로 IPv6를 서빙 안 하는 서버를 가리킨다면 AAAA를 지우세요. 클라이언트가 A 레코드로 폴백하고 모두에게서 에러가 사라집니다.
• A 레코드가 어디서도 응답 안 하는 IP를 가리킨다면(포트 점검으로 확인) 현재 주소로 레코드를 고치세요.
• 로컬 문제라면 자기 라우팅을 점검하세요: 의심되는 VPN을 끄고, 작동하는 기본 경로가 있는지 확인하고, 그리고 — 영구 해결이 아니라 진단용으로만 — 어댑터에서 IPv6를 잠시 꺼 v6 경로가 범인인지 확인하세요.
• 바꿀 때마다 다시 테스트하세요. 라우팅 가능한 주소가 잡히는 순간 ‘경로 없음’은 사라집니다.

When to Escalate

• 많은 사용자에게 사이트가 안 열리고 AAAA 레코드가 있다면, 서버측 IPv6 문제로 다루세요: 레코드가 응답 안 하는 주소를 광고하는 거라, 방문자가 우회할 게 아니라 DNS/호스팅에서 고칠 문제입니다.
• 외부 IPv6 목적지 전반에 대해 당신 망 전체가 ERR_ADDRESS_UNREACHABLE를 낸다면, 라우터나 ISP의 IPv6 문제입니다 — 망을 운영하는 쪽에 올리세요. 노트북 한 대에서 IPv6를 끄는 건 반창고고, 망의 깨진 v6 경로가 상처입니다.