Shadowrocket에 연결되고 노드 지연 시간 테스트에도 결과가 나오지만, 웹페이지에 서버를 찾을 수 없다는 메시지가 표시되거나 일부 도메인이 계속 로딩되고 구독 새로고침이 실패하는 경우에 적합한 안내입니다. 먼저 연결과 DNS 조회를 구분하고, Settings → DNS, Global Routing 및 현재 config를 확인한 뒤 Log에서 요청이 DNS, 규칙 매칭, 프록시 연결 중 어디에서 멈췄는지 판단합니다.
지연 시간이 정상이어도 DNS가 작동한다는 뜻은 아닙니다
Shadowrocket의 노드 지연 시간 테스트는 테스트 대상, 연결 방식, 웹페이지 접속 과정이 서로 완전히 같지 않습니다. 지연 시간은 당시 클라이언트가 이미 알고 있는 서버 주소로 연결 또는 탐색을 한 번 수행할 수 있었다는 뜻일 뿐, 모든 도메인이 올바르게 조회된다는 의미는 아닙니다. 웹페이지 접속에는 도메인 조회, 규칙 매칭, TCP 또는 QUIC 연결, TLS 핸드셰이크, 콘텐츠 전송이 필요하며, 어느 단계에서든 실패하면 빈 페이지가 표시되거나 계속 로딩될 수 있습니다.
DNS의 역할은 도메인을 IP 주소로 변환하는 것입니다. 도메인 조회 결과가 없으면 DOMAIN-SUFFIX, GEOIP, IP-CIDR 및 FINAL 규칙이 전체 처리 과정을 예상대로 진행하지 못할 수 있습니다. 잘못된 주소가 반환되면 클라이언트가 규칙을 정상적으로 매칭해도 사용할 수 없는 대상으로 연결할 수 있습니다. 따라서 “노드는 80ms로 표시되는데 웹페이지가 열리지 않는다”는 현상을 곧바로 노드 속도 문제로 단정할 수 없습니다.
포트 번호는 조회 경로를 이해하기 위한 정보일 뿐, 직접 열거나 항목별로 입력해야 한다는 뜻은 아닙니다. 기존 config, 서비스 제공자의 안내 또는 현재 네트워크에 따라 다른 조회 방식이 지정될 수 있습니다. 문제를 해결할 때는 먼저 현재 설정을 기록한 뒤 한 번에 한 항목만 변경해야 합니다. DNS, 노드, Global Routing, config를 동시에 바꾸면 결과를 비교하기 어렵습니다.
Settings → DNS 항목 이해하기
Shadowrocket의 Settings를 열고 DNS 관련 페이지로 이동합니다. 실제로 표시되는 항목은 현재 설정과 config의 영향을 받으므로 기기에 표시된 영어 라벨을 기준으로 확인해야 합니다. 일반적으로 DNS Server는 기본 조회에 사용되고, Fallback DNS Server는 기본 조회 경로가 실패했을 때 대체 처리를 담당하며, Bootstrap DNS는 암호화된 DNS 서비스 자체의 도메인을 먼저 조회하는 데 사용됩니다. Bootstrap DNS는 모든 일반 조회를 대신하지 않으며, “DNS 서비스에 접속하려면 먼저 해당 서비스의 주소를 알아야 한다”는 시작 단계의 문제를 해결합니다.
System 또는 system은 시스템에서 제공하는 조회 경로를 사용한다는 뜻입니다. 사용자 지정 주소를 직접 입력하지 않았고 config가 덮어쓰지도 않았다면, 현재 클라이언트에 표시되는 초기 상태를 유지해야 합니다. 다른 기기의 스크린샷만 보고 그대로 입력하지 마세요. config를 가져온 뒤에는 [General]의 dns-server, fallback-dns-server, ipv6 필드가 실제 동작을 바꿀 수 있으므로 Settings 페이지와 현재 config를 함께 확인해야 합니다.
| 항목 | 역할 | 문제 해결 시 확인할 점 |
|---|---|---|
| DNS Server | 주요 도메인 조회 담당 | 모든 도메인에 결과가 없을 때 접근 가능 여부와 형식의 완전성을 먼저 확인 |
| Fallback DNS Server | 기본 조회 실패 시 대체 결과 제공 | 기본 조회가 간헐적으로 시간 초과될 때 대체 경로도 현재 네트워크에서 차단되는지 임시로 확인 |
| Bootstrap DNS | DoH 또는 DoT 서비스 자체의 호스트명 조회 | 암호화된 DNS 주소가 도메인이고 시작 단계에서 실패할 때 우선 확인 |
| IPv6 | AAAA 조회 및 IPv6 연결을 제어하거나 영향을 줌 | 네트워크가 IPv6를 일부만 지원하면 AAAA가 먼저 반환되지만 연결은 시간 초과되는 현상이 나타날 수 있음 |
현재 config에 DNS 필드가 명시되어 있다면 해당 config의 처리 로직을 중심으로 확인해야 합니다. 아래 예시는 문법을 식별하기 위한 것으로, 공용 설정을 그대로 사용하라는 뜻이 아닙니다. 주소는 문서용 예시 대역이므로 실제 DNS 서비스로 사용할 수 없습니다.
[General]
dns-server = system, 192.0.2.53
fallback-dns-server = system
ipv6 = false
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
IP-CIDR,198.51.100.0/24,DIRECT
FINAL,PROXY결론: 먼저 DNS를 제어하는 주체를 확인하세요
Settings와 현재 config에 DNS 설정이 함께 있다면 한 페이지만 보지 마세요. 먼저 현재 활성화된 config를 기록한 다음 [General]을 확인하면 DNS Server를 반복해서 바꿔도 변화가 없는 문제를 피할 수 있습니다.
모든 도메인이 열리지 않을 때의 단계별 점검
모든 웹페이지에 서버를 찾을 수 없다는 메시지가 표시되면 먼저 현재 노드와 config를 그대로 유지하세요. 그래야 DNS 변경 전후의 차이를 확인할 수 있습니다. 각 단계를 완료할 때마다 같은 자주 사용하는 도메인을 다시 테스트하고, 이전에 실패한 페이지는 완전히 닫은 뒤 다시 열어 브라우저에 남은 오류가 표시되지 않도록 합니다.
연결 상태 확인
Home으로 돌아가 상단 연결 스위치가 켜져 있는지, 현재 노드 이름과 config가 모두 예상한 항목인지 확인합니다. 스위치가 곧바로 꺼진다면 DNS를 조정하기 전에 연결 문제부터 해결하세요.
Routing 전환
Home에서 Global Routing을 확인합니다. 잠시 Proxy로 바꿔 한 번 테스트한 다음 Direct로 바꿔 다시 테스트하고, 마지막에는 원래 Config 또는 Scene으로 되돌립니다. Config에서만 실패한다면 규칙과 config를 확인해야 하며, 여러 모드에서 모두 실패할 때 DNS 또는 로컬 네트워크를 집중적으로 점검합니다.
DNS 확인
Settings → DNS를 열고 DNS Server, Fallback DNS Server, Bootstrap DNS 및 IPv6의 현재 값을 기록합니다. 방금 직접 추가했지만 출처가 불분명한 중복 항목은 삭제하고, 앱의 기존 상태 또는 사용자가 직접 사용 가능하다고 확인한 설정을 유지합니다.
연결 재구성
Home으로 돌아가 연결을 끈 뒤 몇 초간 기다렸다가 다시 켭니다. DNS 설정을 변경한 후에는 터널을 다시 구성해야 하며, 웹페이지만 새로고침하면 이전 세션이나 캐시 결과가 계속 사용될 수 있습니다.
네트워크 변경
Wi-Fi와 셀룰러 네트워크를 전환한 뒤 같은 테스트를 반복합니다. 특정 네트워크에서만 실패한다면 Shadowrocket 노드를 계속 바꾸기보다 해당 네트워크의 DNS 접근성, IPv6 지원 또는 접속 제한을 중심으로 확인해야 합니다.
Log 확인
Data 또는 Settings에서 사용할 수 있는 Log 메뉴로 이동한 뒤 실패한 도메인을 다시 엽니다. resolve, DNS, timeout, hostname과 관련된 기록이 나타나는지 확인하고 발생 시간을 기록합니다.
Global Routing의 네 가지 일반 모드는 문제 범위를 좁히는 데 사용합니다. Proxy는 지원되는 요청을 프록시 정책으로 통일하고, Direct는 요청을 직접 연결하며, Config는 규칙을 순서대로 매칭하고, Scene은 설정된 사용 상황에 따라 동작을 선택합니다. 잠시 전환하는 것은 원인 파악을 위한 것이므로 테스트가 끝나면 원래 설정으로 되돌려야 합니다. Proxy에서는 열리지만 Config에서는 열리지 않는다면 DNS 주소를 계속 바꾸기보다 DOMAIN-SUFFIX, GEOIP, IP-CIDR 및 FINAL의 순서를 먼저 확인합니다.
오류:지정한 호스트 이름을 찾을 수 있는 서버가 없습니다.
원인 및 해결 방법:시스템이 해당 호스트 이름에 사용할 수 있는 주소를 얻지 못했거나 현재 연결에 사용할 수 없는 결과를 받았습니다. 먼저 Settings → DNS를 확인한 뒤 Shadowrocket 연결을 다시 구성하고 Log에 조회 시간 초과가 있는지 확인하세요.
오류:인터넷 연결이 오프라인 상태인 것 같습니다.
원인 및 해결 방법:연결 과정의 DNS, 라우팅 또는 네트워크 인터페이스가 요청을 완료하지 못했습니다. 먼저 Home 스위치가 안정적으로 켜져 있는지 확인한 뒤 Proxy와 Direct를 각각 테스트하여 특정 모드에서만 문제가 발생하는지 판단하세요.
오류:구독을 불러오지 못했습니다
원인 및 해결 방법:구독 도메인 조회에 실패했거나 링크가 만료되었거나 사용자가 이용하는 서비스 제공자가 접속을 제한했을 수 있습니다. 원래 구독 링크의 형식과 유효성을 확인하세요. 예를 들어 https://example.com/sub?token=xxxx는 형식 예시일 뿐입니다. 확인이 끝나면 Home에서 아래로 당겨 새로고침합니다.
일부 도메인만 실패할 때 규칙과 IPv6 확인
일부 웹사이트는 정상인데 소수의 도메인만 실패한다면 기본 DNS 경로가 완전히 중단된 것은 아닐 가능성이 큽니다. 이때는 실패한 도메인이 특정 규칙에 먼저 매칭되는지 확인해야 합니다. 예를 들어 DOMAIN-SUFFIX,example.com,DIRECT는 해당 접미사를 Direct로 보냅니다. 대상이 프록시 경로에서만 접근 가능하다면 다른 웹사이트는 정상인데 해당 도메인만 시간 초과될 수 있습니다. 규칙은 위에서 아래 순서로 매칭되므로 더 구체적인 규칙을 포괄적인 규칙보다 앞에 배치해야 하며, FINAL은 앞에서 매칭되지 않은 요청을 처리합니다.
GEOIP는 조회된 대상 IP를 기준으로 정책을 판단하고, IP-CIDR은 주소 대역을 직접 매칭합니다. DNS가 예상과 다른 주소를 반환하면 GEOIP 결과도 달라질 수 있습니다. 문제를 해결할 때는 Log에서 실패한 도메인의 조회 결과, 매칭된 규칙 키워드, 최종 정책을 확인한 뒤 Config에서 관련 줄을 점검하세요. 도메인의 소속 지역만으로 추측해서는 안 됩니다.
- DOMAIN-SUFFIX:접미사가 완전하게 입력되었는지, 더 앞에 있는 DOMAIN 또는 DOMAIN-KEYWORD 규칙이 먼저 매칭되지 않았는지 확인합니다.
- GEOIP:DNS가 사용 가능한 IP를 먼저 반환했는지, 규칙에서 선택한 정책이 현재 config의 설계와 맞는지 확인합니다.
- IP-CIDR:주소 대역과 마스크 길이를 확인합니다. 예를 들어 /24와 /32는 매칭 범위가 크게 다릅니다.
- FINAL:앞선 규칙에 매칭되지 않은 요청이 최종적으로 PROXY, DIRECT 또는 다른 정책 그룹 중 어디로 들어가는지 확인합니다.
- IPv6:Log에 AAAA 결과가 표시된 뒤 오래 기다리는 경우, 원래 값을 기록한 후 현재 네트워크에서 IPv6를 사용할 수 있는지 테스트하고 config와 일치하는 설정으로 되돌립니다.
On Demand로 인해 “특정 네트워크에서만 실패하는” 상황이 발생할 수도 있습니다. Settings → On Demand를 열고 Wi-Fi SSID, 인터페이스 유형 또는 도메인 조건에 따라 다른 연결 동작이 활성화되어 있는지 확인합니다. Wi-Fi에서 벗어난 뒤 Shadowrocket이 예상대로 연결되지 않으면 웹페이지 오류가 DNS 문제처럼 보일 수 있지만 실제 원인은 On Demand 조건이 충족되지 않은 것일 수 있습니다. 테스트할 때는 먼저 규칙을 기록하고 On Demand를 잠시 비활성화한 뒤 수동으로 연결하여 같은 도메인을 다시 테스트합니다.
DNS를 바꿔도 계속 실패할 때의 추가 확인 방법
DNS Server를 바꿨는데 변화가 없다고 해서 반드시 DNS와 무관한 문제라는 뜻은 아닙니다. 이전 조회 결과가 앱, 시스템 또는 웹페이지 프로세스에 남아 있을 수 있고, 암호화된 DNS 자체의 도메인도 Bootstrap DNS에 접근할 수 없어 시작되지 않을 수 있습니다. 올바른 방법은 Shadowrocket 연결을 다시 구성하고 테스트 페이지를 새로 연 뒤 같은 시각에 Log를 확인하는 것입니다. 조회 주소를 여러 개 연속으로 입력해서는 안 됩니다.
프로토콜 계층도 DNS 계층과 분리해서 판단해야 합니다. Shadowsocks, VMess, VLESS, Trojan, Hysteria2 및 WireGuard의 연결 매개변수는 사용자가 보유한 서비스 설정에 따라 결정됩니다. Log에 도메인 조회 성공과 예상한 정책 매칭이 이미 표시된 뒤 연결 시간 초과 또는 핸드셰이크 실패가 발생한다면, DNS가 아니라 현재 노드, 프로토콜 매개변수, 네트워크 패킷 손실 또는 서버 상태를 확인해야 합니다. DNS는 주소를 얻는 역할만 하며 이후 전송 문제를 해결할 수 없습니다.
오류:DNS 요청 시간이 초과되었습니다
원인 및 해결 방법:조회 요청은 전송되었지만 제한 시간 안에 응답이 오지 않았습니다. Wi-Fi와 셀룰러 네트워크를 바꿔 비교하고, 일반 DNS의 53 포트 또는 암호화된 DNS에서 사용하는 443, 853 경로가 현재 네트워크에서 접근 가능한지 확인합니다.
오류:서버에 연결할 수 없습니다.
원인 및 해결 방법:앞선 Log에 이미 조회 결과가 기록되어 있다면 이는 일반적으로 조회 이후의 연결 단계 문제입니다. 매칭된 정책, 현재 노드 상태, 프로토콜 매개변수를 확인하고 DNS를 반복해서 바꾸지 마세요.
- 실패 시간, 네트워크 유형, Global Routing 모드, 현재 config 및 노드 이름을 기록합니다.
- Log에서 도메인 조회가 있었는지, 조회 결과로 A 또는 AAAA 주소가 반환되었는지 확인합니다.
- 주소가 있으면 매칭된 DOMAIN-SUFFIX, GEOIP, IP-CIDR 또는 FINAL 규칙을 계속 확인합니다.
- 규칙이 올바른데 연결이 시간 초과되면 노드 연결, 프로토콜 매개변수 및 사용자가 이용하는 서비스 상태를 확인합니다.
- 구독 새로고침만 실패한다면 구독 도메인, 링크 유효성 및 서비스 제공자가 안내한 업데이트 요구 사항을 확인합니다.
결론: Log에서 마지막으로 성공한 단계를 기준으로 책임 계층을 나누세요
조회 결과가 없으면 DNS를 처리하고, IP는 있지만 정책이 잘못되었으면 Config를 처리하며, 정책은 올바르지만 핸드셰이크가 실패하면 노드와 프로토콜을 처리합니다. 마지막으로 성공한 단계부터 다음 단계로 점검하는 편이 DNS Server를 반복해서 교체하는 것보다 빠릅니다.
안정적인 설정으로 복원하고 점검 기록을 보관하세요
원인 파악이 끝나면 임시로 사용한 Global Routing을 원래의 Config, Proxy, Direct 또는 Scene으로 되돌리고, On Demand도 테스트 전 상태로 복원합니다. 문제 해결을 위해 추가한 중복 DNS 항목은 삭제합니다. 문제가 config의 규칙에서 비롯되었다면 오류가 확인된 줄만 수정하고, 현재 네트워크가 원인이라면 다른 네트워크에서의 비교 결과를 보관해 나중에 재현할 수 있도록 합니다.
사용자가 이용하는 서비스 제공자에게 문의할 때는 장애 발생 시간, 사용한 네트워크 유형, 실패한 도메인, Shadowrocket Log에서 해당 요청과 가까운 몇 줄, Direct와 Proxy에서 재현되는지를 전달합니다. 구독 내용과 접속 자격 증명은 민감한 정보이므로 스크린샷을 공유하기 전에 token, 서버 주소에 포함된 인증 정보 및 WireGuard 개인 키를 가려야 합니다.
Shadowrocket은 Apple 플랫폼용 유료 상용 앱이며, iPhone과 iPad가 주요 사용 기기입니다. Mac, Apple TV 및 Apple Vision의 호환성과 시스템 요구 사항은 App Store 페이지의 표기를 기준으로 확인하세요. 유일한 공식 구매 경로는 App Store이며, 개발자는 Shadow Launch Technology Limited로 표시되고 앱 ID는 932747118입니다. 클라이언트 일회성 구매와 회선 서비스는 별개의 항목이며, 클라이언트를 구매했다고 해서 노드나 구독이 제공되는 것은 아닙니다.