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

이 글의 핵심 내용

Shadowrocket의 지연 테스트가 성공해도 웹사이트의 DNS 조회, 규칙 적용, HTTPS 연결까지 정상이라는 뜻은 아닙니다. 이미 서비스 제공업체와 구독을 이용 중인 경우를 대상으로, 증상을 기록하고 설정과 DNS, 규칙, IPv6를 차례로 점검하는 방법을 안내합니다. 한 번에 변수 하나만 바꾸고 같은 도메인으로 다시 테스트해 조회 실패와 조회 후 연결 실패를 구분하세요.

1. 지연 테스트는 정상인데 웹페이지가 열리지 않는 이유

Home의 지연 시간은 선택한 테스트 방식에 따른 대상과 경로만 보여 줍니다. 테스트가 완료되더라도 브라우저에서 접속하는 모든 도메인이 조회되거나 웹사이트의 TCP, TLS 연결 및 이후 리소스 요청까지 성공한다고 볼 수는 없습니다. 먼저 접속되지 않는 도메인과 발생 시각, 당시 Wi-Fi와 셀룰러 네트워크 중 어떤 것을 사용했는지 기록하세요. 단순히 '네트워크가 안 됨'이라고만 적어 두지 마세요.

웹페이지에 접속하려면 보통 도메인을 IP 주소로 변환한 다음 연결을 설정하고 TLS 협상을 완료해야 합니다. 설정에 따라 일부 도메인은 프록시 측에서 조회하거나, 기기에서 먼저 주소를 가져와야 할 수 있습니다. 모든 요청이 항상 같은 경로를 따른다고 볼 수는 없습니다. 아래는 문제 해결을 위한 논리적 순서이며, 프로토콜별 실제 패킷 전송 순서를 나타내지는 않습니다.

도메인 요청 조회 및 라우팅 주소 연결 TLS 협상 페이지 리소스

도메인 주소를 가져오지 못함: DNS 응답, 리졸버 연결 가능 여부, 로컬 매핑을 중점적으로 확인하세요.
주소는 가져왔지만 연결 시간이 초과됨: 적용된 정책과 대상 포트, 주소 계열을 확인하세요. 이를 곧바로 DNS 문제라고 단정할 수는 없습니다.
페이지에 HTTP 403 또는 503이 표시됨: 해당 요청은 최소한 HTTP 응답을 반환할 수 있는 서버에 도달했습니다. 사이트의 접속 제한이나 서비스 상태를 확인하세요.
홈페이지는 표시되지만 이미지가 로드되지 않음: 이미지나 스크립트가 사용하는 도메인을 기록하세요. 기본 사이트 도메인에 적용된 규칙과 리소스 도메인에 적용된 규칙은 다를 수 있습니다.

2. 먼저 변수를 하나씩 바꿔 점검하기

시작하기 전에 현재 구성의 사본을 저장하고 Home → Global Routing 상태와 선택된 서버를 기록하세요. 이 글에서는 일상적인 규칙 라우팅의 기준으로 Config를 사용합니다. Proxy, Direct, Scene의 동작은 각각의 설정을 함께 확인해야 하며, 모드를 전환하는 것 자체가 DNS 문제를 해결해 주지는 않습니다.

현재 상태 기록

Home에서 현재 서버와 Global Routing 상태를 기록하세요. 브라우저에서 같은 도메인을 다시 열어 오류 문구를 적어 둡니다. 구독 갱신, 서버 변경, DNS 수정은 동시에 하지 마세요.
구성 확인

Config에서 현재 실제로 활성화된 구성 파일을 확인한 다음 [General]과 [Rule]을 살펴보세요. 먼저 백업하고 로컬 사본에서 테스트해 유일한 구성 파일을 직접 수정하지 않도록 합니다.
네트워크 전환

서버와 구성은 그대로 둔 채 Wi-Fi와 셀룰러 네트워크를 한 번 비교하세요. Wi-Fi에서만 실패한다면 해당 네트워크에 웹 인증이 필요한지 먼저 확인한 다음 DNS와 네트워크 제한을 점검하세요.
DNS 결과 비교

테스트용 사본에서 dns-server만 변경하고 저장한 뒤 해당 사본을 활성화하세요. 연결을 끊었다가 다시 연결한 다음 같은 도메인을 테스트해 주소를 가져왔는지, 페이지가 다시 열리는지 기록합니다.
원래 설정으로 되돌려 확인

변경해도 효과가 없다면 원래 값으로 되돌려 테스트하세요. 연결을 끊어야 한다면 Settings → On Demand를 확인하고, 필요할 때는 테스트 중 자동 연결 조건을 잠시 해제하세요. 테스트 후에는 다시 원래대로 설정해 자동 재연결이 관찰을 방해하지 않도록 합니다.

3. dns-server, 시스템 DNS, 구성 파일의 관계

dns-server는 구성 파일의 [General] 섹션에서 리졸버를 지정합니다. system은 시스템에서 제공하는 DNS를 사용한다는 뜻입니다. 시스템 DNS는 현재 Wi-Fi의 자동 설정이나 수동 설정에서 제공될 수 있으며, 고정된 공용 리졸버와 같지 않습니다. 네트워크를 전환하면 시스템이 사용하는 DNS 조건도 달라질 수 있습니다.

현재 활성화된 구성에서 dns-server를 검색해 중복 정의나 이전 테스트 값이 남아 있는지 확인하세요. 그런 다음 로컬 테스트 사본 두 개에서 아래 두 가지 설정을 각각 사용하세요. 하나의 파일에 [General] 섹션 두 개를 그대로 이어 붙이지 마세요. 아래 공용 주소는 연결 가능 여부를 비교하기 위한 것으로, 모든 네트워크에서 사용할 수 있다고 보장되지 않습니다.

비교 A: 시스템에서 제공하는 DNS 사용

[General]
dns-server = system

비교 B: 일반 DNS 주소 지정

[General]
dns-server = 1.1.1.1

테스트할 때는 변수의 영향을 확인하기 쉽도록 후보 리졸버를 하나만 남겨 두세요. 여러 리졸버를 동시에 사용하면 요청 분배, 캐시, 응답 차이 때문에 결과의 원인을 파악하기 어려울 수 있습니다. 지정한 주소는 응답하지 않지만 system은 정상이라면 구독을 반복해서 가져오기보다 해당 네트워크에서 지정된 리졸버까지의 경로를 먼저 확인하세요.

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

443

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

2가지 유형

A 및 AAAA 주소 레코드를 각각 확인

포트에 연결할 수 있다고 해서 프로토콜도 작동하는 것은 아닙니다. 일반 DNS는 UDP 응답이 잘려 전송될 때 TCP가 필요할 수 있으며, DoH는 HTTPS 연결을 완료해야 합니다. 일반 DNS 주소를 HTTPS 주소로 바꾸기만 하면 DoH로 사용할 수 있는 것은 아닙니다. DoH에는 실제로 작동하는 서버 엔드포인트가 필요하며, 엔드포인트가 도메인 이름을 사용한다면 최초 연결 전에 해당 도메인을 어떻게 조회할지도 고려해야 합니다.

정리: 리졸버 하나씩 비교하기

같은 네트워크와 서버를 유지한 상태에서 dns-server를 바꾼 뒤에만 문제가 해결됐다면, 이 비교 결과를 기록하고 기존 DNS 리졸버에 연결할 수 있는지 확인하세요. 규칙이나 프로토콜은 동시에 변경하지 마세요.

4. DNS 오류 메시지로 원인 구분하기

다음은 DNS 응답 코드와 네트워크 진단에서 흔히 볼 수 있는 오류 문구입니다. Shadowrocket의 모든 화면에 동일한 문구가 표시되는 것은 아닙니다. 로그나 진단 결과에 이런 문구가 있으면 조회한 도메인과 레코드 유형, 리졸버 주소, 발생 시각도 함께 기록하세요. 오류 한 줄만으로는 문제가 발생한 구간을 판단하기 어렵습니다.

오류: NXDOMAIN

원인: 리졸버가 해당 이름이 존재하지 않는다고 응답한 것입니다. 조회 시간 초과와는 다릅니다.

해결 방법: 먼저 도메인 철자를 확인한 뒤 다른 리졸버로 같은 이름을 조회하세요. 결과가 계속 같다면 도메인 또는 서비스 관리자에게 레코드를 확인하세요.

오류: SERVFAIL

원인: 리졸버가 조회를 완료하지 못했습니다. 상위 DNS, 권한 DNS 서버, DNSSEC 검증 등의 과정이 원인일 수 있습니다.

해결 방법: 다른 리졸버로 비교하고 특정 도메인에서만 실패하는지 기록하세요. 이 코드만으로 서버가 작동하지 않는다고 단정할 수는 없습니다.

오류: connection timed out

원인: 제한 시간 내에 작업이 완료되지 않았다는 뜻입니다. 해당 작업이 DNS 조회였다고 확인된 경우에만 DNS 조회 시간 초과의 근거가 됩니다.

해결 방법: 오류가 발생한 대상과 포트를 확인하세요. 실제 DNS 조회 오류라면 리졸버 경로와 현재 네트워크, UDP/TCP 통신을 점검하세요.

'특정 유형의 레코드가 없음'과 '도메인 자체가 존재하지 않음'도 구분해야 합니다. AAAA 조회에서 주소를 받지 못했지만 A 조회는 정상이라면 해당 도메인에 IPv6 주소가 없을 수 있습니다. 사용 가능한 주소를 받은 뒤 TLS 인증서 오류가 발생한다면 DNS를 계속 바꾸기보다 시스템 시간, 인증서 이름, 연결 대상을 확인하세요.

5. 특정 도메인에 접속할 수 없음: 규칙과 Host 매핑 확인

일부 웹사이트에서만 문제가 발생한다면 해당 요청에 실제로 적용된 규칙과 정책을 먼저 확인하세요. DOMAIN-SUFFIX는 도메인 접미사로 직접 일치 여부를 판단합니다. IP-CIDR와 GEOIP는 주소를 기준으로 판단하므로 DNS 조회가 필요할 수 있습니다. 규칙은 위에서 아래로 적용되며, 먼저 일치한 규칙이 이후 경로에 영향을 줍니다. 앞선 규칙에 일치하지 않은 요청은 FINAL이 처리합니다.

아래 예시는 문법을 설명하기 위한 것이므로 기존 구성을 통째로 대체하지 마세요. example.com과 192.0.2.0/24는 문서용 예시 값입니다. 실제 구성에서 PROXY는 사용 가능한 정책을 가리켜야 합니다.

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

확인 항목	의미	점검 방법
`DOMAIN-SUFFIX`	지정된 도메인과 하위 도메인에 일치합니다.	접속에 실패한 도메인이 앞선 규칙에 의해 다른 정책으로 분류되는지 확인하세요.
`IP-CIDR`	IP 주소 범위에 일치합니다.	주소가 예상치 못한 직접 연결 범위에 포함되는지 확인하세요.
`no-resolve`	이 IP 규칙에 일치시키기 위해서만 도메인 조회가 발생하지 않도록 합니다.	전체 구성의 DNS를 비활성화하는 설정으로 이해하지 마세요.
`[Host]`	로컬 이름 매핑을 제공합니다.	이전 주소가 남아 있는지 확인하세요. 테스트 사본에서 의심되는 매핑을 제거해 결과를 비교합니다.
`FINAL`	앞선 규칙에 일치하지 않은 요청을 처리합니다.	규칙이 존재하는지만 보지 말고 최종 정책이 실제로 작동하는지 확인하세요.

임시로 Home → Global Routing → Proxy로 변경하면 접속되지만 Config에서는 실패하는 경우, 두 라우팅 조건이 서로 다르다는 점만 확인할 수 있습니다. 특정 DNS 설정이 잘못됐다고 바로 단정할 수는 없습니다. 두 번 테스트할 때 적용된 정책과 연결 주소, 실패 단계를 기록한 다음 Config에서 범위를 좁혀 보세요. 테스트가 끝나면 원래 모드로 되돌려 임시 설정을 일상적인 구성으로 남겨 두지 마세요.

6. 조회 결과가 있다면 IPv6, 캐시, 네트워크 조건 확인

A 레코드는 IPv4 주소를, AAAA 레코드는 IPv6 주소를 제공합니다. AAAA 응답을 받았다는 것은 리졸버가 주소를 반환했다는 뜻일 뿐, 현재 네트워크에서 해당 주소로 연결할 수 있다는 뜻은 아닙니다. 도메인에 두 유형의 주소가 모두 있다면 '레코드가 없음', '레코드는 받았지만 연결 시간 초과', '앱이 어떤 유형의 주소를 선택했는지'를 구분해야 합니다.

IPv4는 연결되지만 IPv6는 시간 초과: DNS 응답을 증거로 보관하고 현재 네트워크의 IPv6 연결 상태를 확인하세요. 관련 옵션을 조정해야 한다면 원래 값을 기록하고 임시 비교만 진행하세요. DNS와 라우팅 규칙을 동시에 바꾸지 마세요.
설정을 바꿨는데도 이전 결과처럼 보임: 새 구성이 활성화됐는지 확인하고 연결을 끊었다가 다시 연결한 뒤 브라우저를 완전히 종료하고 다시 시도하세요. 브라우저와 앱, 리졸버 모두 결과를 캐시할 수 있으며, 다시 연결해도 모든 캐시가 지워지는 것은 아닙니다.
호텔 또는 공용 Wi-Fi에서만 실패: 먼저 네트워크에서 요구하는 웹 인증을 완료하세요. 네트워크 사용 권한을 얻기 전에는 DNS 응답이나 HTTPS 연결에 영향을 줄 수 있습니다.
특정 브라우저에서만 실패: 다른 앱에서 같은 도메인에 접속한 결과와 비교하고, 앱 자체의 DNS 조회나 캐시, 연결 설정이 있는지 확인하세요. 전역 구성을 바로 변경하지 마세요.
서버 주소가 도메인 이름인 경우: 연결을 시작하기 전에 서버 도메인을 조회할 수 있는지도 확인해야 합니다. 연결을 설정하기 위해 필요한 최초 조회를, 아직 설정되지 않은 연결에 의존해 해결할 수는 없습니다.

정리: 주소를 얻었다면 연결 단계 확인

같은 도메인에서 A 또는 AAAA 응답이 안정적으로 확인되고 연결 또는 TLS 단계에서 실패한다면 리졸버 변경을 멈추고 실제 사용된 주소와 적용된 정책, 대상 포트를 확인하세요.

7. 구성을 복원하고 재현 가능한 기록 정리

문제를 해결한 뒤 테스트 중 임시로 해제한 On Demand 조건을 복원하고 Global Routing과 현재 구성을 확인한 다음 기본 사이트와 리소스 도메인을 각각 다시 테스트하세요. 페이지가 처음 한 번 열렸다는 이유만으로 해결됐다고 판단하지 마세요. 캐시가 문제를 가릴 수 있으므로 다시 연결한 뒤 같은 작업을 한 번 더 진행하세요.

구독은 서버 정보를 제공하고 갱신하는 기능이지 현재 네트워크의 DNS 문제를 해결해 주는 기능은 아닙니다. 구독은 이용 중인 서비스 제공업체에서 가져옵니다. 새로고침 후 서버 목록이 정상이어도 대상 웹사이트의 DNS 조회가 정상이라는 뜻은 아닙니다. 로컬 구성만 수정했다면 이후 구성이 업데이트될 때 해당 수정이 덮어써지는지도 확인하세요.

접속에 실패한 도메인과 오류 문구를 기록하고 전체 사이트에서 발생하는지 특정 도메인에서만 발생하는지 구분하세요.
Wi-Fi 또는 셀룰러 네트워크 여부, Global Routing 상태, 현재 구성과 서버를 기록하세요. 다른 사람에게 전달할 때는 민감한 주소와 인증 정보를 가리세요.
dns-server 변경 전후의 값과 A, AAAA 레코드에서 주소를 받았는지 기록하세요.
요청에 적용된 규칙과 정책, 최종 실패 단계를 기록해 DNS, 연결, TLS, HTTP 응답 문제를 구분하세요.
어떤 설정 하나를 변경했을 때 증상이 달라졌는지 설명하세요. 구독 전체 링크와 token, 비밀번호는 공유하지 마세요.

연결 문제를 더 살펴보려면 문제 진단을 확인하세요. 키워드의 의미가 궁금하다면 용어집을 참고하세요. 여러 설정을 연달아 바꾸기보다 이번처럼 변수를 하나씩 바꾼 기록을 남겨야 문제를 재현하고 원인을 판단하기 쉽습니다.