Shadowrocket DNS 설정 및 문제 해결: 지연 테스트는 정상인데 웹페이지가 열리지 않는 이유

이 글의 핵심

Shadowrocket에서 지연 시간이 표시되더라도 해당 테스트가 그 시점에 완료되었다는 뜻일 뿐, 모든 도메인이 조회되거나 모든 웹페이지에 연결된다는 보장은 없습니다. 이미 사용 중인 서비스를 설정했지만 웹페이지가 열리지 않는 경우, 연결 상태 확인, 실패 단계 파악, DNS 점검, 규칙 확인, 설정 복구 및 재검증 순으로 원인을 찾습니다. 작업 전에 현재 설정을 저장하고 한 번에 하나씩만 변경해, DNS 조회 문제와 프록시 연결 문제를 혼동하지 않도록 하세요.

1. 지연 테스트가 정상이어도 웹 요청 전체가 성공한 것은 아닙니다

웹페이지에 접속하려면 대상 도메인 처리, 라우팅 선택, 연결 설정, 애플리케이션 계층 통신이 필요합니다. DNS는 도메인에 대응하는 주소 등의 레코드를 조회합니다. HTTPS 페이지는 대상 서버와 TLS 핸드셰이크도 완료해야 합니다. 지연 테스트는 서버 포트만 확인하거나 지정된 테스트 주소에 요청을 보낼 수 있으며, 방식에 따라 확인 범위가 다릅니다. 현재 열려는 웹페이지와 이미지, 스크립트, 로그인 API를 하나씩 확인하는 테스트는 아닙니다.

도메인 처리 라우팅 선택 연결 설정 TLS 핸드셰이크 페이지 로딩

이 흐름은 문제를 단계별로 나누기 위한 것이며, 모든 요청이 반드시 기기에서 먼저 DNS 조회를 마쳐야 한다는 뜻은 아닙니다. 도메인 규칙은 대상 IP를 얻기 전에 적용될 수 있고, 일부 프록시 프로토콜과 설정에서는 도메인 처리를 원격 서버에 맡길 수 있습니다. 반면 IP 규칙에는 조회 결과가 필요할 수 있습니다. 따라서 ‘기기에서의 DNS 조회’, ‘프록시 서버 주소 조회’, ‘원격에서의 대상 도메인 조회’를 구분해야 합니다. 지연 시간이 표시된다는 이유만으로 모든 DNS 문제를 배제할 수는 없습니다.

테스트는 정상이지만 모든 사이트가 실패하는 경우: DNS를 바로 바꾸기보다 연결 스위치, 선택된 서버, Global Routing을 먼저 확인하세요.
일부 도메인만 실패하는 경우: 해당 도메인의 조회 결과, 적용된 규칙, 실제 아웃바운드 정책을 확인하세요.
메인 페이지는 열리지만 이미지가 계속 로딩되는 경우: 실패한 리소스의 도메인을 각각 기록하세요. 메인 페이지와 같은 규칙을 적용받지 않을 수 있습니다.
인증서 오류가 표시되는 경우: 시스템 시간, 대상 주소, 네트워크 로그인 상태를 확인하세요. DNS 시간 초과로 단정할 수 없습니다.

2. 현재 상태를 기록하고 재현 가능한 방식으로 비교하세요

문제가 안정적으로 재현되는 전체 URL을 하나 선택하고 네트워크 종류, 발생 시각, 오류 문구를 기록하세요. ‘모든 페이지가 안 됨’이라고만 하지 말고 구체적인 URL을 사용하세요. 서버, 설정 파일, DNS를 동시에 바꾸지 마세요. 아래 절차는 iPhone / iPad의 Home, Config, Settings 화면을 기준으로 하며, 다른 플랫폼에서는 같은 기능을 확인하면 됩니다. 시스템 VPN 표시는 터널 상태일 뿐, 원격 서비스가 사용 가능하다는 뜻은 아닙니다.

현재 상태 저장

Config에서 현재 적용 중인 설정을 확인하고, 편집 전에 백업하세요. Home에서 선택된 서버와 Global Routing 상태, Settings → On Demand에 설정된 조건을 기록하고 기존 설정을 먼저 삭제하지 마세요.
연결 적용 여부 확인

Home으로 돌아가 연결 스위치를 확인하세요. 비교를 위해 연결을 직접 끄려면 먼저 Settings → On Demand를 확인하세요. 기존 조건에 따라 시스템이 연결을 다시 설정하면 ‘연결을 끈 상태에서 테스트’한 결과가 무의미해질 수 있습니다.
라우팅 모드 확인

Home → Global Routing을 확인하세요. Config는 설정된 규칙에 따라 트래픽을 분기하고, Proxy는 프록시 경로와 비교할 때, Direct는 직접 연결과 비교할 때 사용합니다. Scene은 설정된 장면에 따라 동작합니다. 테스트할 때는 한 가지 모드를 명확히 선택하고, Scene을 고정된 프록시 모드로 간주하지 마세요.
같은 요청 반복

같은 네트워크와 서버에서 같은 URL을 다시 열고 오류가 동일한지 기록하세요. 그런 다음 Wi-Fi와 셀룰러 네트워크만 바꿔 재시험하세요. 한 네트워크에서만 실패한다면 해당 네트워크의 DNS 연결 가능 여부, 로그인 인증 또는 접속 제한을 먼저 확인하세요.
설정 복구

비교를 마치면 원래 Global Routing 및 On Demand 조건으로 복구하세요. 변경 사항과 결과를 하나씩 기록하세요. 임시로 Proxy를 사용해 성공했다고 해서 기존 Config의 규칙 분기 문제가 해결된 것은 아닙니다.

3. DNS 주소, 전송 방식, 조회 위치를 구분하세요

DNS를 점검할 때는 세 가지를 확인해야 합니다. 조회를 누구에게 맡기는지, 어떤 전송 방식을 사용하는지, 조회 트래픽이 어떤 경로를 이용하는지입니다. DNS 주소를 입력하는 것만으로는 첫 번째만 지정되며, 현재 네트워크에서 해당 주소에 연결할 수 있다는 보장은 없습니다. 암호화 DNS도 조회 서비스와의 연결이 필요합니다. 조회 서비스 주소가 도메인이라면 최초 조회에 필요한 부트스트랩 경로도 고려해야 합니다.

일반 DNS에서 주로 사용하는 UDP / TCP 포트

853

DNS over TLS에서 주로 사용하는 TCP 포트

443

DNS over HTTPS에서 주로 사용하는 HTTPS 포트

확인 항목	의미	점검 사항
System DNS	현재 시스템에서 제공하는 DNS 설정을 사용하며, 보통 연결된 네트워크에 따라 달라집니다.	같은 기기도 네트워크를 바꾸면 결과가 달라질 수 있습니다. Wi-Fi에서 성공했다고 셀룰러 네트워크에서도 같다고 볼 수 없습니다.
사용자 지정 DNS	조회 서버 또는 지원되는 DNS 서비스 주소를 직접 지정합니다.	주소 형식과 연결 가능 여부를 확인하세요. IP만 입력할 수 있는 필드에 HTTPS 서비스 주소를 넣지 마세요.
DNS over HTTPS	HTTPS를 통해 DNS 조회를 전송합니다.	서비스에 연결되는 전체 경로, TLS 연결, DNS 서비스 자체 도메인의 조회 가능 여부를 확인하세요. 포트에 연결된다는 것만으로는 정상 작동을 입증할 수 없습니다.
DNS over TLS	TLS를 통해 DNS 조회를 전송합니다.	서비스 포트와 인증서 검증을 확인하고, 현재 네트워크에서 해당 연결을 허용하는지 점검하세요.
A / AAAA	각각 IPv4 및 IPv6 주소 레코드에 해당합니다.	AAAA 레코드가 있다고 해서 현재 IPv6 라우팅이 작동한다는 뜻은 아닙니다. 실제 연결 결과와 함께 판단하세요.

현재 설정에서 텍스트 형식의 [General] 섹션을 사용하는 경우, 해당 섹션의 dns-server 설정을 확인할 수 있습니다. 아래 예시는 시스템 DNS를 사용한다는 뜻이며, 모든 환경에 통하는 ‘최적 설정’은 아닙니다. 통제된 비교에만 사용하세요. 먼저 백업한 뒤 기존 항목을 수정하고, 같은 이름의 항목을 파일 끝에 중복 추가하지 마세요. 이 설정이 브라우저 자체의 Secure DNS를 덮어쓴다고 가정해서도 안 됩니다.

[General]
dns-server = system

4. 오류 문구로 DNS 조회 실패, 연결 시간 초과, 인증서 문제 구분하기

‘열리지 않음’이라는 설명보다 실제 오류 문구가 원인을 파악하는 데 더 유용합니다. 아래는 브라우저나 네트워크 도구에 표시될 수 있는 오류 문구입니다. Shadowrocket에서 같은 이름의 메뉴를 찾으라는 뜻도, 모든 플랫폼에서 같은 문구가 표시된다는 뜻도 아닙니다. 오류가 발생한 위치와 로그를 함께 살펴보세요. 단어 하나만 보고 설정을 변경하면 안 됩니다.

오류: ERR_NAME_NOT_RESOLVED

원인 및 해결 방법: 브라우저가 사용할 수 있는 이름 조회 결과를 얻지 못한 상태입니다. 도메인 철자를 확인한 다음 시스템 DNS와 현재 설정의 DNS 결과를 비교하고, 브라우저 자체의 Secure DNS 경로에 문제가 있는지 확인하세요.

오류: DNS_PROBE_FINISHED_NXDOMAIN

원인 및 해결 방법: 진단 결과는 도메인이 존재하지 않는다고 나타냅니다. 하지만 잘못 설정된 DNS 서비스가 비정상적인 부정 응답을 반환할 수도 있습니다. 전체 도메인을 확인하고, 신뢰할 수 있는 다른 조회 경로로 다시 확인하세요. 페이지를 반복해서 새로고침하는 것만으로는 해결되지 않습니다.

오류: ERR_CONNECTION_TIMED_OUT

원인 및 해결 방법: 제한 시간 안에 연결이 완료되지 않았다는 뜻이며, DNS 문제만을 의미하지는 않습니다. 대상의 조회 주소와 적용된 정책, 원격 연결을 점검하고 같은 URL에서 Config와 Proxy 결과를 비교하세요.

오류: ERR_CERT_DATE_INVALID

원인 및 해결 방법: 인증서 날짜 검증에 실패했습니다. 기기 시간 또는 사이트 인증서 유효기간이 원인일 수 있습니다. 먼저 시스템 날짜와 시간대를 확인하고 대상 사이트 상태를 점검하세요. 인증서 검증을 끄는 방식으로 해결하지 마세요.

조회 도구에서 NXDOMAIN이 명확히 반환되면 해당 응답은 도메인이 존재하지 않는다고 판단한 것입니다. SERVFAIL은 DNS 서비스가 조회를 완료하지 못했다는 뜻이며, 응답을 받지 못한 시간 초과와는 다릅니다. 단순히 ‘DNS 오류’라고만 기록하지 말고 응답 유형, 조회한 도메인, 사용한 DNS 서버를 함께 보관하면 후속 점검에 도움이 됩니다.

5. DNS 조회가 정상이어도 아웃바운드 경로가 잘못될 수 있습니다

Global Routing에서 Config를 선택하면 일반적으로 규칙을 위에서 아래로 확인하고, 일치하는 규칙이 적용됩니다. DOMAIN-SUFFIX는 도메인 접미사로, IP-CIDR는 IP 대역으로, GEOIP는 IP 위치 데이터베이스를 기준으로 일치 여부를 판단합니다. FINAL은 앞선 규칙과 일치하지 않은 요청에 적용됩니다. DNS에서 올바른 주소를 반환했다는 것은 조회 단계가 끝났다는 뜻일 뿐, 이후 정책이 해당 요청에 적합하다는 보장은 아닙니다.

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

아래는 문법을 설명하기 위한 예시입니다. example.com은 예시 도메인이고 192.0.2.0/24는 문서용 예시 대역이므로 실제 규칙에 그대로 사용하면 안 됩니다. no-resolve는 이 IP 규칙을 위해 도메인 조회를 새로 시작하지 않는다는 뜻입니다. 요청에 이미 IP가 포함된 경우에는 여전히 규칙과 일치할 수 있습니다. 예시에 있는 PROXY를 사용하려면 현재 환경에서 사용 가능한 프록시 선택 항목이 있어야 합니다. 이 규칙만으로 연결 경로가 만들어지는 것은 아닙니다.

Config에서는 실패하고 Proxy에서는 성공하는 경우: 도메인이 앞쪽의 DIRECT 또는 REJECT 규칙과 일치하는지 먼저 확인하세요. 이는 단서일 뿐이므로 두 요청의 DNS 조회 경로도 비교해야 합니다.
Direct에서는 성공하고 Proxy에서는 실패하는 경우: 선택한 서버와 프록시 아웃바운드를 확인하세요. 로컬에서 DNS 조회가 된다고 해서 원격에서도 조회가 된다고 단정할 수 없습니다.
메인 도메인은 성공하고 리소스 도메인은 실패하는 경우: 리소스 도메인에 적용되는 규칙을 각각 확인하세요. 메인 도메인의 규칙 일치 결과가 전체 페이지에도 적용된다고 볼 수 없습니다.
FINAL을 변경해도 효과가 없는 경우: 요청이 이미 앞쪽 규칙과 일치했는지, 현재 라우팅 모드가 Config인지 확인하세요.

로그에 요청 도메인, 대상 주소, 적용된 정책이 표시된다면 세 항목을 함께 저장하세요. 진단 정보를 전달하기 전에 인증 정보, 사설 주소, 구독 토큰을 가리세요. 문제 해결을 위해 전체 설정을 공개하지 마세요. 이 글은 이미 이용 중인 서비스가 있는 사용자를 위한 안내이며, 이 사이트는 노드나 구독을 제공·판매·추천하지 않습니다.

6. IPv6, 캐시, 브라우저 DNS 관련 자주 묻는 질문

DNS를 바꿨는데 왜 오류가 그대로인가요?

먼저 Config에서 실제 사용 중인 파일을 수정했는지, 변경 내용을 저장했는지 확인하세요. 연결을 다시 설정하고 기존 페이지를 닫은 뒤 새 요청을 보내세요. 브라우저, 시스템 또는 원격 서버에 캐시가 남아 있을 수 있으므로 DNS를 바꿔도 모든 단계의 결과가 즉시 지워지지는 않습니다. 새 요청의 발생 시각을 기록해 이전 탭의 오류를 새 결과로 오인하지 마세요.

IPv6를 끄니 페이지가 열립니다. 계속 꺼 둬야 하나요?

IPv6 경로나 주소 선택을 추가로 점검할 필요가 있다는 뜻일 뿐입니다. AAAA 조회 결과를 기록하고 같은 네트워크에서 IPv4와 IPv6 연결 가능 여부를 각각 확인한 다음 라우팅과 서버 지원을 점검하세요. 관련 옵션을 일시적으로 끄는 것은 비교 테스트에 사용할 수 있지만, 모든 DNS 문제의 해결책으로 고정해서는 안 됩니다.

브라우저 하나에서만 페이지가 열리지 않으면 어떻게 확인하나요?

같은 기기에서 다른 브라우저로 정확히 같은 URL에 접속해 보세요. 문제가 있는 브라우저의 Secure DNS, 내장 프록시 설정, 확장 프로그램을 확인하세요. 비교를 위해 일시적으로 시스템 DNS를 사용해 테스트한 뒤 원래 설정으로 복구하세요. 시크릿 창은 일부 사이트 데이터 문제를 확인하는 데 도움이 되지만 DNS 캐시 우회를 보장하지는 않습니다.

IP 주소로는 열리는데 도메인으로는 열리지 않으면 DNS 문제인가요?

반드시 그런 것은 아닙니다. HTTPS 사이트는 보통 SNI와 인증서 검증에 도메인을 사용하므로 IP 주소로 직접 접속하면 다른 사이트가 열리거나 인증서 오류가 발생할 수 있습니다. DNS 조회 결과와 올바른 도메인을 포함한 연결 테스트를 함께 확인하세요. IP 주소만 입력했을 때 페이지가 열리는지를 유일한 근거로 삼지 마세요.

구독은 업데이트되는데 웹페이지는 왜 계속 열리지 않나요?

구독 업데이트는 해당 시점에 구독 URL에 접근할 수 있었는지만 확인합니다. 모든 서버와 대상 웹사이트를 점검하는 것은 아닙니다. Home으로 돌아가 실제 선택된 서버를 확인하고 Global Routing과 실패한 도메인을 점검하세요. 구독을 반복해서 업데이트하는 것으로 DNS 및 규칙 점검을 대신하지 마세요.

7. 같은 URL로 재검증하고 변경 사항을 최소화하세요

문제 해결의 기준은 지연 시간이 표시되는지가 아니라, 예상한 네트워크와 라우팅 모드에서 이전에 실패한 URL이 반복해서 열리고 주요 리소스도 정상적으로 요청되는지입니다. 작은 요청은 성공하지만 큰 파일 로딩만 멈춘다면 MTU나 전송 계층 문제를 추가로 살펴볼 수 있습니다. 특히 WireGuard를 사용할 때 웹페이지가 열리지 않는다는 이유만으로 MTU를 임의로 바꾸지 마세요. DNS 문제를 점검하는 과정에 다른 계층의 문제를 섞지 않는 것이 중요합니다.

평소 사용하는 Global Routing으로 복구한 뒤 원래 URL과 이전에 실패한 리소스 도메인을 다시 확인하세요.
Wi-Fi와 셀룰러 네트워크에서 각각 확인하고, 한 네트워크에서만 문제가 발생하는지 기록하세요.
기존 On Demand 조건을 복구하고 네트워크를 전환했을 때 연결이 예상대로 동작하는지 확인하세요.
비교 테스트로 효과가 확인된 변경만 남기고, 효과가 없었던 DNS, IPv6, 규칙 변경은 되돌리세요.
계속 실패하면 오류 문구, 발생 시각, 네트워크 종류, 적용된 정책, 비교 테스트 결과를 정리해 현재 이용 중인 서비스의 관리자에게 문의하세요.