Shadowrocket DNS 오류 해결 방법: 지연 테스트는 정상인데 웹페이지가 열리지 않을 때

핵심 내용

지연 테스트에 결과가 표시되더라도 대상 도메인이 조회되었거나 웹페이지 연결에 성공했다는 뜻은 아닙니다. Shadowrocket을 설치했고 본인이 이용 중인 서비스와 구독이 있는 사용자를 위한 안내입니다. DNS, 규칙, 외부 연결을 따로 점검한 다음 같은 네트워크에서 같은 URL로 항목별 재시험을 진행하세요. 한 번에 설정 하나만 변경하고, 되돌릴 수 있도록 기존 설정을 복사해 두세요.

1. 지연 시간, DNS, 웹페이지 연결 구분하기

Shadowrocket의 지연 시간은 해당 테스트가 대상으로 삼은 항목과 방식에서 결과를 얻었다는 뜻일 뿐입니다. 서버 주소에 연결할 수 있는지, 도메인이 조회되는지, 프록시 인증이 통과되는지, 대상 웹사이트가 콘텐츠를 반환하는지는 각각 다른 단계입니다. 지연 시간 숫자 하나만으로 전체 접속 경로가 정상이라고 판단할 수 없습니다.

도메인 조회 규칙 판정 외부 연결 TLS 핸드셰이크 웹페이지 응답

이 흐름은 문제를 단계별로 구분하기 위한 것이며, 모든 요청이 항상 로컬에서 먼저 조회된다는 뜻은 아닙니다. 도메인 규칙은 도메인 이름과 직접 일치할 수 있고, 일부 프록시 경로에서는 대상 도메인 처리를 원격에 맡길 수 있습니다. IP 관련 규칙, 서버 자체 도메인, 직접 연결 요청에는 해당 조회 결과가 필요할 수 있습니다.

Home에서 연결 스위치가 켜져 있는지 확인하고 Global Routing의 현재 값을 살펴보세요. 평소 접속되는 HTTPS 페이지와 문제가 발생한 페이지를 차례로 열고, 전체 도메인, 네트워크 유형, 테스트 시간, 오류 내용을 기록합니다. 특정 도메인 하나만 실패한다면 먼저 해당 도메인과 관련 규칙을 확인하고 DNS 설정 전체를 바로 바꾸지 마세요.

웹페이지에서 서버를 찾을 수 없다고 표시됨: 도메인 철자, DNS 응답, Host 재정의를 먼저 확인하세요.
웹페이지가 오랫동안 로딩되다가 시간 초과됨: DNS 조회 시간 초과일 수도 있고 연결 또는 외부 경로의 시간 초과일 수도 있으므로 로그를 함께 확인해야 합니다.
웹페이지에서 인증서 오류가 표시됨: 요청이 TLS 검사 단계에 도달한 상태입니다. 기기 시간, 인증서, 대상 주소를 확인하고 DNS 문제로만 단정하지 마세요.
웹페이지에서 HTTP 403 또는 503을 반환함: HTTP 응답을 받은 상태이므로 DNS를 계속 바꾸기보다 접근 제한이나 웹사이트 상태를 먼저 확인하세요.

2. DNS 설정 항목과 포트의 의미

DNS는 도메인 이름을 네트워크 연결에 필요한 주소로 변환합니다. A 레코드는 IPv4, AAAA 레코드는 IPv6 주소에 해당합니다. AAAA 레코드를 받았다고 해서 현재 네트워크에 사용 가능한 IPv6 외부 연결 경로가 있다는 뜻은 아닙니다. 반대로 도메인에 A 레코드만 있다고 해서 조회 오류인 것도 아닙니다.

일반 DNS: 주로 UDP를 사용하며 TCP도 사용할 수 있음

443

DoH: HTTPS를 통한 조회에 흔히 사용하는 포트

853

DoT: TLS를 통한 조회의 기본 포트

포트는 전송 방식을 설명할 뿐, 연결 가능성을 보장하지 않습니다. 현재 네트워크에서 특정 리졸버에 접근하지 못할 수 있으며, 도메인 이름을 사용하는 암호화 DNS 주소라면 리졸버 자체 도메인을 어떻게 조회하는지도 고려해야 합니다. 일반 DNS의 IP 주소를 임의의 HTTPS 주소로 입력하거나 DNS 조회 포트를 프록시 서버 포트란에 입력하지 마세요.

확인 항목	기능	점검 방법
`dns-server`	구성 파일에 설정된 DNS 서버입니다.	Config에서 현재 구성을 열고 General에 해당 항목이 있는지 확인한 다음 Settings → DNS의 설정도 살펴보세요.
`system`	시스템에서 제공하는 리졸버를 사용합니다.	현재 Wi-Fi 또는 셀룰러 네트워크에서 다시 테스트하세요. 네트워크를 바꾸면 DNS 조회 조건도 달라집니다.
`Host`	지정한 도메인에 고정 주소를 매핑할 수 있습니다.	문제가 발생한 도메인이 이전 주소에 매핑되어 있는지 확인해 고정 매핑을 실시간 DNS 결과로 오인하지 않도록 하세요.
A / AAAA	IPv4 / IPv6 주소를 각각 반환합니다.	조회 결과가 있는지와 해당 주소에 연결할 수 있는지를 따로 확인하세요.

Settings의 전역 옵션과 Config의 구성 항목이 함께 동작에 영향을 줄 수 있습니다. 점검할 때는 현재 활성화된 구성과 실제 로그를 기준으로 판단하세요. 특정 페이지에 값이 저장되어 있다는 이유만으로 적용 중이라고 단정하지 마세요. 앱 업데이트로 화면 구성이 달라졌다면 DNS, Config, General 등의 영문 이름을 기준으로 항목을 찾으세요.

3. 한 번에 하나씩 정해진 순서로 다시 테스트하기

먼저 현재 구성을 복사해 두고 기존 Global Routing, DNS, 서버 선택 값을 기록하세요. 아래 단계마다 동일한 문제의 URL을 사용합니다. 페이지가 다시 열리면 한 번 더 접속하고 로그를 확인한 뒤 변경 사항을 유지할지 결정하세요.

기본 네트워크를 확인합니다. Shadowrocket 연결을 잠시 끄고 평소 정상적으로 열리는 페이지에 접속해 보세요. Wi-Fi 로그인이 필요하다면 먼저 네트워크 로그인을 완료합니다. 그런 다음 연결을 다시 켜세요. 기본 네트워크 자체가 작동하지 않으면 설정을 바꿔도 상위 네트워크 연결 문제는 해결되지 않습니다.
현재 서버를 확인합니다. Home으로 돌아가 선택된 서버가 본인이 이용 중인 유효한 구독에 포함되어 있는지 확인하세요. 지연 테스트는 정상이지만 인증, 전송 또는 원격 외부 연결에 실패한다면 본인의 서비스 제공자에게 연결 정보와 서비스 상태를 문의하세요.
라우팅 모드를 확인합니다. Home → Global Routing에서 현재 Config, Proxy, Direct, Scene 중 어떤 모드인지 기록하세요. Scene을 사용하는 경우 먼저 해당 Scene이 실제로 어떤 설정을 적용하는지 확인해 Scene 전환을 DNS 변경으로 오인하지 않도록 하세요.
실제 적용 중인 DNS를 확인합니다. Settings → DNS를 살펴보고 Config에서 현재 사용하는 구성을 열어 General의 DNS 설정과 Host 매핑을 확인하세요. 한 번에 한 항목만 바꾸고 변경 후 다시 연결해 테스트합니다.
네트워크별로 비교합니다. 셀룰러 데이터를 사용할 수 있다면 구성을 유지한 채 Wi-Fi에서 셀룰러 네트워크로 전환해 같은 URL을 테스트하세요. 한쪽 네트워크에서만 실패한다면 해당 네트워크의 리졸버 연결 가능성, 네트워크 로그인, 외부 연결 제한을 우선 확인하세요.
자동 연결을 확인합니다. 연결을 껐는데 다시 자동으로 켜진다면 Settings → On Demand를 확인하세요. 문제를 점검하는 동안 해당 조건을 기록하고 일시적으로 조정한 다음, 점검이 끝나면 기존 On Demand 설정으로 되돌리세요.

4. Global Routing으로 규칙 문제와 DNS 문제 비교하기

Config는 현재 구성의 규칙에 따라 트래픽을 분기하고, Proxy와 Direct는 전체 라우팅 모드를 비교할 때 사용하며, Scene은 설정된 시나리오에 따라 동작합니다. 모드를 잠시 바꾸는 것은 최종 해결책이 아닙니다. 문제 범위를 좁히기 위한 방법이므로 테스트가 끝나면 평소 설정으로 되돌리세요.

비교 결과	추정할 수 있는 내용	다음 단계
Config에서는 실패하고 Proxy에서는 성공	규칙에서 지정한 경로나 관련 DNS 동작을 확인할 필요가 있습니다. 리졸버 오류라고 바로 단정할 수는 없습니다.	문제가 발생한 도메인에 적용된 규칙과 정책을 확인하고 Direct 또는 다른 지정 경로로 처리되는지 살펴보세요.
Direct에서는 성공하고 Proxy에서는 실패	프록시 경로에서 인증, 연결 또는 원격 조회 문제가 발생했을 수 있습니다.	현재 서버 설정을 확인하고 조회 단계와 연결 단계 중 어디서 실패했는지 로그를 살펴보세요.
세 가지 모드 모두 실패	기본 네트워크, 도메인 자체 또는 공통으로 사용하는 DNS 설정이 원인일 수 있습니다.	네트워크를 바꿔 비교하고 도메인과 Host 매핑도 확인하세요.
특정 도메인만 실패	문제 범위가 제한적이므로 모든 DNS 요청이 실패한다고 볼 수는 없습니다.	해당 도메인의 규칙, 조회 응답, 웹사이트 상태를 확인하세요.

DOMAIN-SUFFIX는 도메인 접미사를 기준으로 일치하고, IP-CIDR은 IP 주소 대역을 기준으로 일치하며, GEOIP는 IP의 지리적 분류를 기준으로 일치합니다. FINAL은 기본 적용 규칙입니다. 규칙은 나열된 순서대로 판정되며, 일치하면 해당 정책을 사용합니다. 아래 내용은 문법 예시일 뿐, 일상적인 구성을 그대로 대체하는 규칙이 아닙니다.

[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

example.com과 192.0.2.0/24는 문법 설명용 예시입니다. 예시의 no-resolve는 해당 IP 규칙과 일치시키기 위해 도메인 조회를 먼저 수행하지 말라는 뜻이며, 이후 연결에 항상 조회가 불필요하다는 뜻은 아닙니다. IP 규칙을 삭제하거나 전체를 Proxy로 변경하면 경로가 달라질 수 있지만, 잘못된 도메인 레코드가 자동으로 수정되지는 않습니다.

정리: 먼저 적용된 경로를 확인한 뒤 DNS 변경 여부를 결정하세요

같은 도메인이 Proxy에서는 열리고 Config에서는 실패한다면 Config의 규칙과 정책부터 확인하세요. 조회 시간 초과, 유효한 주소 없음, 잘못된 매핑이 확인된 경우에만 해당 DNS 설정을 변경해 라우팅 모드 변경으로 기존 문제를 가리지 않도록 하세요.

5. 오류 문구로 조회 실패와 연결 실패 구분하기

브라우저 안내, 앱 로그, 시스템 오류에는 서로 다른 문구가 표시될 수 있습니다. 아래는 브라우저나 Apple 네트워크 오류 기록에서 볼 수 있는 문구와 코드의 예이며, Shadowrocket에서 항상 동일하게 표시되는 것은 아닙니다. 오류가 발생한 위치를 기록하고 같은 시점 전후에 조회된 주소가 있는지 확인하세요.

오류: ERR_NAME_NOT_RESOLVED

원인:브라우저가 대상 도메인의 유효한 조회 결과를 얻지 못했습니다.

해결 방법:먼저 도메인 철자를 확인한 다음 현재 DNS 설정과 Host 매핑을 점검하세요. 라우팅 모드는 그대로 두고 네트워크를 바꿔 같은 도메인을 다시 테스트합니다.

오류: NSURLErrorDomain Code=-1003

원인:Apple URL 로딩 오류의 cannot find host는 지정된 호스트를 찾을 수 없다는 뜻입니다.

해결 방법:대상 웹사이트 도메인과 서버 도메인 중 어느 쪽에서 실패했는지 구분하고 해당 조회 설정을 확인하세요. NXDOMAIN이 반복해서 확인된다면 대기 시간을 늘리는 데 그치지 말고 도메인이 유효한지 점검하세요.

오류: NSURLErrorDomain Code=-1001

원인:요청 시간이 초과된 상태입니다. 이 코드만으로는 DNS 단계에서 시간 초과가 발생했다고 단정할 수 없습니다.

해결 방법:시간 초과 전에 주소와 연결 기록이 있었는지 확인하세요. 주소가 있었다면 외부 연결 가능성을 먼저 점검하고, 조회 결과가 없었다면 리졸버 경로를 확인하세요.

NXDOMAIN은 리졸버가 해당 이름이 존재하지 않는다고 응답한 경우입니다. 응답 자체가 없는 경우는 다른 현상으로, 패킷 손실, 리졸버 연결 불가 또는 대기 시간 초과와 관련이 있을 수 있습니다. 두 경우를 모두 ‘DNS 차단’이라고 표현하지 마세요. 주소가 조회됐지만 연결에 실패한다면 IPv6 경로, 프록시 설정, 대상 포트도 확인해야 합니다. HTTPS에서 흔히 사용하는 포트는 443이지만, 서버 포트는 본인이 이용 중인 서비스 설정을 따라야 합니다.

6. 자주 묻는 질문과 복구 후 확인

지연 테스트는 계속 정상인데 웹페이지가 열리지 않는 이유는 무엇인가요?

지연 테스트와 웹 요청은 서로 다른 단계를 확인합니다. Home에서 선택된 서버와 Global Routing을 기록한 다음 브라우저에서 실제로 문제가 발생한 도메인에 접속하세요. 조회 결과, 적용된 정책, 연결 오류를 각각 확인하고 지연 테스트만 반복하지 마세요.

DNS를 바꿨는데도 실패합니다. 계속 바꿔야 하나요?

먼저 변경한 설정이 실제로 적용 중인지 확인하세요. Config → 현재 구성 → General을 살펴보고 Settings → DNS도 확인합니다. 다시 연결한 뒤 재시험하세요. 로그에 주소가 있는데 연결 단계에서 실패한다면 리졸버를 무작정 바꾸지 말고 외부 연결 경로를 확인하세요.

Wi-Fi에서만 실패하고 셀룰러 네트워크에서는 정상이라면 어떻게 해야 하나요?

같은 구성과 서버를 유지하면서 Wi-Fi에 네트워크 로그인이 필요한지, 사용 중인 리졸버에 해당 네트워크에서 접근할 수 있는지 확인하세요. system을 사용하면 네트워크에 따라 시스템 DNS가 달라지므로 두 네트워크의 조회 조건도 서로 다릅니다.

구독을 업데이트하면 DNS 문제를 해결할 수 있나요?

구독 업데이트는 일반적으로 서버 항목을 새로 고치는 기능이며, 이것만으로 로컬 DNS 설정이 수정됐다고 볼 수 없습니다. 본인의 서비스 제공자가 서버 주소나 연결 설정 변경을 확인해 준 경우에만 안내에 따라 기존 구독을 업데이트하고 현재 선택된 항목을 다시 확인하세요.

페이지가 다시 열리면 기존 Global Routing 모드로 돌아가고 필요한 On Demand 조건을 복원한 다음, 문제가 발생했던 페이지와 자주 사용하는 페이지를 테스트하세요. 변경 전후 로그를 비교해 네트워크나 규칙을 임시로 바꾼 덕분에 복구된 것은 아닌지 확인합니다. 브라우저 요청을 새로 보내려면 문제가 발생한 탭을 닫고 다시 열 수 있습니다. 단, 이것이 시스템 DNS 캐시 전체를 지우는 것은 아닙니다.

최종적으로 유지할 변경 사항을 기록하세요: 설정 항목, 이전 값, 새 값, 확인한 URL.
현재 Config가 의도한 구성인지 확인하고 Host에 테스트용 고정 매핑이 남아 있지 않은지 살펴보세요.
평소 사용하는 규칙이 예상대로 트래픽을 분기하는지 확인하세요. 임시 비교 모드를 장기간 사용하지 마세요.
해결되지 않으면 민감 정보를 가린 로그와 네트워크 비교 결과를 준비해 본인의 서비스 제공자에게 문의하세요. 추가 점검 방법은 문제 해결을 참고하세요.