Shadowrocket DNS 설정 가이드: 지연은 정상인데 웹페이지가 열리지 않을 때

이 글의 핵심

Shadowrocket에서 지연 시간이 표시되더라도 대상 웹페이지의 DNS 조회가 완료됐다는 뜻은 아닙니다. 자체 서비스와 설정을 이미 보유한 사용자를 대상으로, 테스트 조건을 고정한 뒤 현재 Config, DNS 상위 서버, 규칙 적용 여부를 확인하고 조회 실패와 연결 실패, 웹사이트 자체의 문제를 구분합니다. 한 번에 한 항목만 변경하고 원래 설정을 복구할 수 있도록 보관하세요.

1. 지연 시간 테스트와 웹페이지 접속 구분하기

지연 시간 테스트는 해당 테스트 방식이 확인하는 연결 경로가 그 시점에 응답했다는 점만 보여 줍니다. 오류가 발생한 웹사이트에 직접 접속하는 테스트가 아닐 수도 있고, 브라우저 요청에 필요한 모든 조회 및 연결 단계를 거치는 것도 아닙니다. 따라서 지연 시간이 표시되어도 도메인 조회, 정책 선택, TLS 핸드셰이크 또는 웹페이지 리소스 로딩 단계에서 실패할 수 있습니다.

실패한 도메인 하나와 발생 시각, 현재 네트워크, Home의 Global Routing 상태를 기록하세요. ‘모든 웹페이지가 열리지 않는다’고만 적지 말고 구체적으로 테스트해야 합니다. 한 페이지도 메인 사이트, 이미지 도메인, 로그인 API에 각각 연결할 수 있습니다. 메인 페이지는 열리지만 일부 리소스만 실패하는 경우와 기본 도메인을 전혀 조회하지 못하는 경우는 서로 다른 문제입니다.

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

443

DNS over HTTPS에서 일반적으로 사용하는 포트

853

DNS over TLS 표준 포트

요점: 실패한 단계를 먼저 찾으세요

대상 IP를 확인한 뒤 연결 시간 초과가 발생한다면 대상 연결과 정책을 먼저 점검하세요. 같은 도메인에서 계속 조회 결과를 얻지 못한다면 DNS를 확인해야 합니다. 포트 번호는 일반적인 프로토콜 사용 방식을 나타낼 뿐, 현재 네트워크에서 해당 요청이 허용된다는 뜻은 아닙니다.

2. Home, Config, On Demand 테스트 조건 고정하기

문제 해결을 시작하기 전에 현재 설정을 복사하거나 내보내 백업하고, 기존 Global Routing 상태를 기록하세요. 이 글에서는 설정의 규칙을 확인하기 위해 Config 모드에서 점검합니다. Proxy와 Direct는 잠깐 비교해 볼 수 있지만, 이것만으로 DNS가 정상인지 이상인지 판단할 수는 없습니다. Scene도 조건을 기록하지 않은 비교 기준으로 적합하지 않으므로 현재 Scene에서 어떤 동작이 설정되어 있는지 먼저 확인하세요.

현재 상태 기록

Home → Global Routing으로 이동해 현재 모드가 Config, Proxy, Direct, Scene 중 무엇인지 기록하고 선택되어 있는 기존 서버도 적어 두세요. 테스트 중에는 서버와 DNS를 동시에 변경하지 마세요.
활성 설정 확인

Config에서 현재 선택된 구성 파일을 확인하세요. 해당 파일 오른쪽의 정보 버튼을 누른 다음 Edit Plain Text로 이동해 실제 저장된 [General] 및 [Rule] 내용을 확인합니다. 선택하지 않은 파일만 살펴보는 것으로는 부족합니다.
자동 연결 확인

Settings → On Demand로 이동해 기능의 활성화 여부와 기존 조건을 기록하세요. 연결을 끊은 뒤 자동으로 다시 연결된다면 먼저 이 항목을 확인하세요. 테스트 중 잠시 비활성화해야 한다면 기존 상태를 기록한 후 테스트가 끝나면 복구합니다.
한 번에 한 가지 변수만 변경

같은 Wi-Fi 또는 셀룰러 네트워크를 유지하고 Home → Global Routing → Config 상태에서 같은 도메인에 반복 접속하세요. 설정을 변경할 때마다 저장하고 다시 연결한 다음 새 요청을 보내 결과를 기록합니다.

특정 Wi-Fi에서만 문제가 발생한다면 해당 네트워크에 웹 인증이 필요한지 먼저 확인하세요. 인증이 완료되지 않으면 DNS 요청과 HTTPS 연결이 모두 제한될 수 있습니다. 이 경우 규칙을 계속 수정해도 네트워크 인증은 완료되지 않습니다. 네트워크를 전환해 비교할 때는 별도 테스트로 기록하고 다른 설정 변경과 함께 진행하지 마세요.

3. 확인해야 할 DNS 설정

DNS 상위 서버는 도메인에 연결된 주소를 응답하고, 규칙은 요청에 적용할 정책을 선택합니다. 두 설정은 서로 다른 기능입니다. 현재 구성의 [General]에서 dns-server는 DNS 서버를 지정합니다. 다른 서버로 바꾸기 전에 현재 값과 주소 형식, 연결 가능 여부를 확인하세요. 익숙해 보이는 주소라도 현재 네트워크에서 사용할 수 있다고 단정할 수 없습니다.

확인 항목	의미	점검할 내용
`dns-server`	구성에 지정된 DNS 상위 서버 목록	오타나 만료된 주소, 현재 네트워크와 호환되지 않는 상위 서버가 있는지 확인합니다.
`system`	시스템에서 제공하는 DNS 서버 사용	Wi-Fi와 셀룰러 네트워크를 전환하면 시스템에서 사용하는 DNS 조건이 달라질 수 있습니다.
DNS over HTTPS	HTTPS를 통한 DNS 쿼리 전송	전체 URL, 경로, 인증서, 상위 서버 연결을 확인하세요. 호스트 이름만 있다고 해서 유효한 쿼리 엔드포인트가 되는 것은 아닙니다.
A / AAAA	IPv4 / IPv6 주소를 각각 반환	AAAA 레코드를 받았더라도 현재 네트워크에서 IPv6를 통해 외부에 연결할 수 있다는 뜻은 아닙니다.
서버 도메인	기존 서버 주소를 확인할 때도 DNS 조회가 필요할 수 있음	서버 도메인 조회 실패와 대상 웹사이트 도메인 조회 실패를 구분하세요.

아래는 필드 위치를 이해하기 위한 최소 예시이며, 구성 전체를 덮어쓸 수 있는 템플릿이 아닙니다. DNS 상위 서버로 시스템 제공 서버를 지정해 비교 조건을 명확히 하지만 모든 네트워크에 적합하다고 보장하지는 않습니다. 편집할 때는 기존 필드만 수정하고 다른 설정은 유지하세요. 같은 이름의 항목을 여러 개 추가하지 마세요.

[General]
dns-server = system

도메인 이름을 사용하는 암호화 DNS 엔드포인트라면 상위 서버의 도메인을 먼저 어떻게 조회하는지, 엔드포인트에 연결할 수 있는지도 확인해야 합니다. 암호화는 쿼리 전송 방식만 바꾸며 조회 결과가 정확하거나 웹사이트에 연결된다는 보장은 없습니다. 상위 서버 연결 자체가 실패한다면 주소를 더 추가해 문제를 가리기보다 상위 서버에 연결할 수 있는지 먼저 확인하세요.

현재 사용하는 구성에서만 수정하세요. 원격 구성을 다시 업데이트한 뒤에는 로컬 수정 내용이 유지되었는지 확인합니다.
웹사이트 URL, 구독 링크 또는 서버 연결 매개변수를 dns-server에 입력하지 마세요.
IPv6 문제는 같은 네트워크에서 조건을 비교해 원인을 좁히세요. IPv6를 영구적으로 끄는 것을 모든 DNS 문제의 해결책으로 삼지 마세요.

4. 규칙 적용 결과로 DNS와 라우팅 문제 구분하기

Global Routing이 Config일 때는 규칙 순서에 따라 최종 정책이 달라집니다. 일반적으로 구체적인 도메인 규칙을 먼저 확인한 뒤 주소 규칙과 마지막의 FINAL을 점검하세요. 도메인이 정상적으로 조회되더라도 요청이 사용할 수 없는 경로로 지정될 수 있습니다. 이 경우 DNS를 변경해도 정책 오류는 해결되지 않습니다.

아래 예시는 규칙 문법만 보여 줍니다. 예시 도메인과 문서용 예약 주소는 실제 서비스를 가리키지 않습니다. 기존 규칙을 이 내용으로 통째로 바꾸지 마세요. 현재 구성에서 같은 유형의 항목을 찾아 연결 기록과 함께 적용 여부를 확인해야 합니다. 특히 FINAL,DIRECT는 이 예시에서 최종 정책을 나타낼 뿐, 일반적으로 권장하는 값이 아닙니다.

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

키워드	일치 기준	문제 해결 시 확인할 점
`DOMAIN-SUFFIX`	도메인 접미사	더 앞에 있는 규칙이 대상 도메인에 예상과 다른 정책을 적용하고 있는지 확인합니다.
`IP-CIDR`	IP 주소 범위	대상이 도메인뿐인 경우 주소 규칙을 적용하는 과정에 DNS 조회가 필요할 수 있습니다. `no-resolve`는 해당 주소 규칙을 위해 조회를 직접 시작하지 않도록 합니다.
`GEOIP`	IP 지리 정보 데이터베이스	주소 분류 정보일 뿐, 웹사이트 도메인이나 실제 서비스 위치를 보장하지 않습니다.
`FINAL`	앞선 규칙이 모두 일치하지 않음	마지막에 적용되는 정책을 확인하고, 기본 정책을 구체적인 규칙보다 앞에 두지 마세요.

요점: 정책을 먼저 비교하고 DNS를 수정하세요

같은 대상이 Proxy에서는 접속되지만 Config에서는 실패한다면 적용된 규칙과 사용 경로를 우선 비교하세요. 이는 문제 범위를 좁히는 단서일 뿐 DNS 오류를 확정하는 근거는 아닙니다. Config로 되돌린 뒤 관련 규칙을 하나씩 확인하세요.

5. 실제 오류에 따라 다음 단계 선택하기

오류 메시지는 발생한 단계와 함께 살펴봐야 합니다. 아래 문구는 DNS 응답이나 네트워크 로그에서 나타날 수 있는 원문이며, Shadowrocket이 모든 문제 상황에서 고정적으로 표시하는 안내가 아닙니다. 실제 기록에 해당 문구가 있을 때만 관련 판단을 적용하세요. 브라우저의 막연한 ‘웹페이지를 열 수 없음’ 메시지를 NXDOMAIN과 동일한 의미로 볼 수는 없습니다.

오류: NXDOMAIN

원인 및 해결 방법: DNS가 조회한 이름이 존재하지 않는다고 응답했습니다. 전체 도메인과 철자를 확인한 뒤 같은 도메인으로 다른 상위 서버와 비교하세요. 상위 서버마다 결과가 다르면 응답 출처를 기록하고 추가로 확인합니다.

오류: SERVFAIL

원인 및 해결 방법: DNS 서버가 쿼리를 완료하지 못했습니다. 상위 서버 장애나 검증 실패가 원인일 수 있습니다. 영향을 받는 도메인이 하나뿐인지 확인한 다음, 연결 가능성이 확인된 상위 서버와 비교하세요. 대상 웹사이트가 종료되었다고 바로 판단하지 마세요.

오류: connection timed out

원인 및 해결 방법: 연결이 제한 시간 안에 완료되지 않았다는 뜻입니다. 이 문구만으로는 DNS 문제인지 판단할 수 없습니다. 시간 초과가 발생한 대상이 DNS 상위 서버, 기존 서버, 웹사이트 주소 중 무엇인지 확인하고 해당 연결 경로를 점검하세요.

인증서 오류가 발생하면 기기 시간, 접속 도메인, 인증서 이름, HTTPS 연결 환경을 확인하세요. 인증서 검증을 무시해 DNS 문제를 ‘해결’하려고 하지 마세요. 웹페이지 본문은 표시되지만 이미지가 실패한다면 리소스 도메인의 규칙과 DNS를 각각 확인하세요. 메인 사이트만 반복해서 테스트하지 마세요.

도메인 하나만 실패: 철자와 해당 도메인의 DNS 응답, 개별 규칙을 확인한 다음 웹사이트 자체에 문제가 있는지 살펴봅니다.
같은 네트워크에서 전반적으로 실패: 인증 상태, 시스템 DNS, 상위 서버 연결을 확인하세요. 네트워크를 전환할 때는 다른 조건을 그대로 유지합니다.
조회 결과는 있지만 연결 실패: DNS 주소를 계속 바꾸기보다 주소 연결 가능 여부, IPv4 / IPv6 경로, 정책, TLS를 확인하세요.
변경 후 간헐적으로 복구: 캐시 만료, 재연결, 설정 변경의 영향을 각각 구분하세요. 한 번 성공했다고 근본 원인이 확인된 것은 아닙니다.

6. 재테스트, 설정 복구, 점검 기록 정리

DNS를 변경해도 이미 연결된 세션에서 바로 새로 조회하지 않을 수 있으며, 브라우저와 시스템에 캐시가 남아 있을 수도 있습니다. 구성을 저장하고 다시 연결한 다음 새로 접속하세요. 필요하다면 기존 페이지를 닫고 다시 엽니다. 기존 페이지를 계속 새로고침하는 것으로 별도 테스트를 대신하지 마세요. 재연결한다고 모든 앱의 캐시가 삭제되는 것도 아닙니다.

접속이 복구되면 임시 변경 사항을 하나씩 되돌리고, 반복 비교로 효과가 확인된 항목만 유지하세요. 특히 기존 On Demand 상태와 Global Routing을 복원해 점검이 끝난 뒤에도 임시 Proxy 또는 Direct 모드가 계속 유지되지 않도록 합니다. 구성을 업데이트한 다음에는 활성 파일과 관련 필드가 바뀌었는지 확인하세요.

기록 항목	기록할 내용
네트워크 및 시간	문제 발생 시각, Wi-Fi 또는 셀룰러 네트워크 여부, 네트워크를 바꾼 뒤에도 재현되는지 기록합니다.
활성 구성	현재 구성 이름, Global Routing, DNS 상위 서버 유형, 관련 규칙을 기록합니다.
요청 결과	실패한 도메인, DNS 응답 또는 오류 원문, IP를 받았는지 여부, 최종 적용된 정책을 기록합니다.
항목별 비교	변경한 항목, 재연결 후 결과, 원래 값으로 되돌렸을 때 문제가 다시 발생하는지 기록합니다.

자신이 이용하는 서비스 제공업체나 지원 채널에 기록을 전달하기 전에 구독 링크 전체, token, UUID, 비밀번호와 기타 인증 정보를 가리세요. 구성 전체를 공개하지 마세요. 이 글은 클라이언트 문제 해결 방법만 안내하며 서버나 구독을 제공·판매·추천하지 않습니다. 클라이언트 일회성 구매와 회선 요금제는 별개입니다.