Shadowrocket에 직접 설정을 가져온 사용자를 위한 안내입니다. 지연 시간 테스트의 한계를 살펴본 뒤 Global Routing, 현재 Config, DNS 응답 결과, IPv6 경로를 차례로 확인해 DNS 조회 실패와 조회 후 연결 실패를 구분합니다. 점검할 때는 기존 설정을 보존하고 한 번에 한 항목만 변경한 다음 같은 도메인으로 다시 테스트하세요.
1. 지연 시간이 정상이어도 도메인 조회는 실패할 수 있습니다
Home에 지연 시간이 표시된다는 것은 해당 테스트에서 사용한 대상, 프로토콜, 경로가 응답을 받았다는 뜻일 뿐입니다. 테스트 방식마다 확인하는 단계가 다릅니다. 포트 연결이 된다고 웹페이지의 TLS 핸드셰이크까지 성공하는 것은 아니며, 한 번의 HTTP 테스트가 성공해도 모든 웹사이트에 접속할 수 있다는 뜻은 아닙니다. DNS 문제를 확인하려면 지연 시간 표시만 보지 말고 문제가 발생한 도메인의 조회 결과를 살펴보세요.
브라우저에서 웹사이트를 열 때는 보통 먼저 도메인을 IP 주소로 조회한 다음 실제 라우팅 경로로 연결을 설정하고 TLS와 HTTP 요청을 진행합니다. 프록시 프로토콜, 도메인 규칙, 원격 조회 여부에 따라 각 단계가 실행되는 위치는 달라질 수 있습니다. 따라서 아래 순서는 진단을 위한 것이며 모든 요청의 데이터 흐름이 완전히 같지는 않습니다.
로그에 주소 응답이 없다면 우선 DNS를 확인하세요. A 또는 AAAA 주소를 받았는데 연결 단계에서 시간 초과가 발생한다면 실제 아웃바운드 경로, 대상 포트, 네트워크 경로를 확인해야 합니다. 인증서 검증에 실패했다면 기기 시간, 대상 도메인, 인증서 정보를 점검하세요. 이를 곧바로 DNS 문제로 단정해서는 안 됩니다.
IP 주소로 직접 접속하는 것만으로 모든 항목을 검증할 수는 없습니다. 많은 HTTPS 웹사이트는 도메인에 따라 인증서와 사이트 콘텐츠를 선택합니다. 주소창의 도메인을 IP로 바꿨을 때 접속에 실패해도 해당 IP에 도달할 수 없다는 뜻은 아니며, DNS가 정상이라는 증거도 아닙니다.
2. Home, Config 및 연결 상태 확인
DNS 설정은 실제로 적용된 Config와 경로를 기준으로 확인해야 합니다. 먼저 Home에서 현재 사용 중인 연결 항목을 확인하고 Global Routing도 살펴보세요. Proxy, Direct, Config, Scene은 서로 다른 라우팅 방식이므로 특정 방식에서 성공하거나 실패했다는 이유만으로 DNS 서버 문제라고 단정할 수 없습니다. Scene의 실제 동작은 설정된 조건에도 좌우됩니다.
-
현재 상태 기록
Home에서 현재 선택된 연결 항목과 Global Routing 값을 기록하고, 네트워크가 Wi-Fi인지 셀룰러인지도 적어 두세요. 실제로 열리지 않는 도메인 하나를 테스트 대상으로 정해 매번 같은 도메인을 사용합니다.
-
Config 확인
Config에서 현재 선택된 구성 파일을 확인합니다. 해당 파일의 편집 화면을 열어 먼저 원본 내용을 따로 보관한 뒤
[General]과[Rule]을 확인하세요. 선택되지 않은 다른 파일만 수정하면 현재 연결 동작에는 영향을 주지 않습니다. -
자동 연결 분리
Settings → On Demand에서 현재 상태를 기록합니다. 비교를 위해 수동으로 연결을 끊어야 한다면 On Demand를 잠시 끄면 시스템이 조건에 따라 다시 연결하는 일을 막을 수 있습니다. 테스트가 끝나면 원래 설정으로 되돌리세요.
-
한 항목씩 다시 테스트
한 항목을 변경하고 저장한 뒤 Home으로 돌아가 연결을 끊었다가 다시 연결한 다음 같은 도메인을 요청하세요. 필요하면 브라우저에서 새 탭을 여세요. 기존 페이지와 시스템 또는 브라우저 캐시 때문에 결과가 바로 바뀌지 않을 수 있습니다.
Global Routing 방식을 비교하려면 먼저 원래 값을 기록한 다음 잠시 테스트하고 즉시 복원하세요. Direct는 대상 트래픽을 직접 연결 경로로 보내고, Proxy는 아웃바운드 선택을 바꿉니다. 이런 비교로 네트워크 경로 차이를 확인할 수 있지만, 일반적인 운영 설정의 해결책은 아닙니다. 민감한 작업을 진행 중이라면 경로 변경의 영향을 먼저 검토하세요.
3. DNS 설정 항목 이해하기
현재 Config의 텍스트를 확인할 때는 먼저 [General] 아래의 dns-server를 찾으세요. 이 항목은 DNS 리졸버를 지정하며, system은 시스템이 제공하는 DNS를 사용한다는 뜻입니다. Config에 다른 DNS 옵션이 있다면 현재 앱의 설정 설명에 따라 항목별로 확인하세요. 용도가 다른 주소를 하나의 필드에 몰아넣지 마세요.
| 항목 | 의미 | 확인할 점 |
|---|---|---|
dns-server | Config에서 사용할 DNS 리졸버 | 주소가 올바른지, 현재 네트워크에서 접속 가능한지, 현재 Config가 활성화되어 있는지 |
system | 시스템에서 제공하는 DNS 사용 | Wi-Fi와 셀룰러 네트워크를 전환하면 시스템 리졸버와 접속 조건이 달라질 수 있음 |
A | 도메인의 IPv4 주소 레코드 | 응답을 받았는지, 반환된 주소로 연결할 수 있는지 |
AAAA | 도메인의 IPv6 주소 레코드 | 주소가 반환되어도 현재 IPv6 경로를 사용할 수 있는 것은 아님 |
TTL | DNS 레코드 캐시의 유효 시간 | 설정을 변경해도 이전 결과가 한동안 캐시에 남아 있을 수 있음 |
아래는 Config 구조를 파악하기 위한 최소 예시이며 완전한 Config가 아니므로 원본 파일을 덮어쓰면 안 됩니다. 시스템 리졸버와 비교하려면 기존 [General]에서 해당 키만 조정하고 섹션이나 키를 중복으로 추가하지 마세요.
[General]
dns-server = system포트 번호로 전송 방식을 알 수는 있지만 접속 가능 여부까지 보장되지는 않습니다. 일반 DNS 요청은 현재 네트워크에서 시간 초과가 발생할 수 있습니다. DoH도 HTTPS 연결이 필요하며, 도메인으로 지정된 DoH 엔드포인트는 최초 주소 조회도 거쳐야 합니다. 리졸버를 선택할 때는 기존 Config의 요구 사항, 네트워크 접속 가능 여부, 데이터 처리 방식을 고려하세요. 암호화된 전송이 반드시 더 빠르다는 뜻은 아닙니다.
4. 응답 결과로 DNS 장애 유형 구분하기
앱 내 요청 기록이나 진단 로그에서는 문제가 발생한 도메인, 조회 유형, 응답 상태, 후속 연결 결과를 확인하세요. 아래 문자열은 DNS 응답 코드나 자주 보이는 시간 초과 문구의 예이며, Shadowrocket의 모든 화면에 그대로 표시되는 것은 아닙니다. 브라우저에 한국어 안내만 나타난다면 해당 문구를 원문 그대로 기록하고 임의로 특정 오류 코드로 바꾸지 마세요.
NXDOMAIN
원인: 리졸버가 해당 도메인이 존재하지 않는다고 응답했습니다. 도메인 오타, 만료된 도메인 또는 현재 리졸버의 부정 응답이 원인일 수 있습니다.
해결 방법: 먼저 호스트 이름 전체가 올바른지 확인한 뒤 유효한 것으로 알려진 다른 도메인과 비교하세요. 해당 도메인에서만 문제가 계속되면 웹사이트 관리자에게 문의하세요. 기다리는 시간만 늘리는 것으로 해결하려 하지 마세요.
SERVFAIL
원인: 리졸버가 조회를 완료하지 못했습니다. 상위 서버 응답, 권한 서버 또는 검증 과정에 문제가 있을 수 있으며, 도메인이 존재하지 않는다는 뜻은 아닙니다.
해결 방법: 기존 값을 기록해 둔 다음 이미 설정되어 있고 접속 가능한 다른 리졸버로 한 번 비교해 보세요. 특정 도메인에서만 문제가 발생한다면 웹사이트 관리자가 확인할 수 있도록 조회 시각과 응답 코드를 기록하세요.
timeout
원인: 제한 시간 안에 응답을 받지 못했습니다. 리졸버에 접속하는 경로에서 지연되었을 수도 있고, 조회가 완료된 뒤 대상에 연결하는 과정에서 지연되었을 수도 있습니다.
해결 방법: 먼저 시간 초과가 발생한 단계를 확인하세요. DNS 응답이 없다면 리졸버 주소와 네트워크 접속 가능 여부를 점검하고, 주소가 이미 반환되었다면 아웃바운드 경로와 대상 포트를 확인하세요.
한 번의 실패만으로 결론을 내리지 마세요. 같은 도메인을 여러 번 요청한 뒤 유효한 것으로 알려진 다른 도메인과 비교하세요. 모두 실패하면 공통 DNS 경로 문제일 가능성이 크고, 특정 도메인만 실패하면 해당 도메인과 권한 조회를 더 자세히 살펴봐야 합니다. 기록할 때 조회 유형도 남기세요. AAAA 레코드가 한 번 반환되지 않았다는 이유만으로 도메인 전체가 조회되지 않는다고 판단해서는 안 됩니다.
- 주소 응답 없음: 철자, 응답 코드, 리졸버 접속 경로를 먼저 확인하세요.
- A 주소는 받았지만 연결 시간 초과: 해당 요청에 실제로 적용된 규칙과 아웃바운드 경로를 확인하세요. DNS를 계속 바꿀 필요는 없습니다.
- AAAA 경로에서만 실패: IPv4와 IPv6 연결 결과를 비교한 뒤 주소 계열 관련 설정을 조정할지 판단하세요.
- 첫 페이지는 열리지만 일부 리소스는 실패: 실패한 리소스의 도메인을 따로 확인하세요. 한 페이지에서 여러 도메인을 사용할 수 있습니다.
5. 규칙과 IPv6가 DNS 문제처럼 보이는 이유
Global Routing에서 Config를 사용하면 규칙에 따라 아웃바운드 경로가 선택됩니다. DOMAIN-SUFFIX는 도메인 접미사를 기준으로 매칭하고, IP-CIDR와 GEOIP는 주소 관련 조건을 확인하며, FINAL은 앞선 규칙에 매칭되지 않은 요청에 적용됩니다. 규칙 순서, 조회 필요 여부, 조회가 이루어지는 위치가 모두 실제 동작에 영향을 줄 수 있습니다.
아래는 매칭 대상을 설명하기 위한 규칙 문법 예시입니다. example.com과 192.0.2.0/24는 문서용 예시 값이며 추가해야 할 사이트나 경로가 아닙니다. 이 내용을 통째로 기존 규칙 끝에 붙이지 마세요. 기존 FINAL과 앞에 있는 규칙 때문에 추가한 규칙이 적용되지 않을 수 있습니다.
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,PROXYno-resolve는 IP 규칙에 매칭하기 위해 도메인 조회를 새로 시작하지 않는다는 뜻입니다. 모든 DNS를 차단한다는 뜻도, 조회 실패를 해결하는 옵션도 아닙니다. 도메인 규칙이 적용된 뒤 적절하지 않은 경로로 연결되면 DNS가 정상이어도 페이지가 열리지 않을 수 있습니다. Config 텍스트만 읽는 대신 요청 기록에서 실제로 적용된 규칙을 확인하세요.
IPv6 문제는 비교 테스트로 확인하세요. AAAA 레코드를 받았다는 것은 리졸버가 IPv6 주소를 반환했다는 뜻일 뿐입니다. 현재 네트워크의 IPv6 연결이 완전하지 않으면 대기 상태가 지속되거나 다른 경로로 전환될 수 있습니다. 먼저 현재 Config의 IPv6 관련 옵션을 기록한 다음 한 항목씩 짧게 비교 테스트하세요. DNS, Global Routing, IPv6를 동시에 바꾸면 어떤 설정이 결과에 영향을 줬는지 알 수 없습니다.
6. 자주 묻는 질문과 재현 가능한 점검 기록
DNS를 바꿨는데 왜 결과가 그대로인가요?
먼저 Config에서 현재 선택된 파일을 수정했는지 확인하고 저장한 뒤 Home으로 돌아가 다시 연결하세요. 새 탭을 열어 같은 도메인을 요청하는 것도 좋습니다. 시스템, 브라우저, 앱에 캐시가 남아 있을 수 있으므로 기존 페이지를 연속 새로고침하는 것만으로 새 리졸버가 사용됐다고 판단하지 마세요.
Wi-Fi에서는 안 열리는데 셀룰러 네트워크에서는 열려요. 어떻게 해야 하나요?
같은 연결 항목, Global Routing, Config를 유지하고 네트워크만 바꿔 비교하세요. 차이는 네트워크에서 제공하는 DNS, 리졸버 접속 가능 여부 또는 IPv6 경로에서 비롯될 수 있습니다. system을 사용 중이라면 네트워크 전환 여부를 특히 기록하세요.
지연 시간은 정상인데 기존 구독을 업데이트하지 못하는 것도 DNS 문제인가요?
먼저 구독 호스트 이름 조회 실패, 연결 시간 초과, HTTP 응답 오류를 구분하세요. 조회는 성공했는데 401 또는 403이 반환된다면 서비스 제공자에게 권한과 링크 유효성을 확인하세요. DNS 설정을 바꿔도 접속 자격 증명 문제는 해결되지 않습니다.
Proxy로 바꾸니 열립니다. DNS가 해결된 건가요?
아닙니다. Global Routing을 Proxy로 바꾸면 아웃바운드와 DNS 관련 경로가 함께 달라질 수 있습니다. 기존 값으로 되돌리고 Config에서 실패한 요청에 적용된 규칙과 반환 주소를 확인한 뒤, 이상이 확인된 항목만 조정하세요.
추가 도움을 요청할 때는 지연 시간 스크린샷보다 재현 조건을 제공하는 편이 유용합니다. 아래 정보를 한 차례 테스트 중에 모으세요. 로그에서 구독 자격 증명, 계정 정보, 전체 연결 Config는 먼저 삭제하고 문제 판단에 필요한 항목만 남기세요.
- 환경: iPhone 또는 iPad, Wi-Fi 또는 셀룰러 네트워크, On Demand 활성화 여부.
- 상태: Home의 Global Routing 값, 현재 Config 이름, 방금 재연결했는지 여부.
- 요청: 실패한 도메인, 발생 시각, A 또는 AAAA 조회 결과, DNS 응답 코드 또는 원본 오류 메시지.
- 후속 단계: 주소를 받은 경우 적용된 규칙과 아웃바운드 선택, 연결·TLS·HTTP 중 실패가 발생한 단계.
- 비교: 매번 변경한 설정 한 가지, 변경 전후 증상, 원래 값으로 되돌렸을 때 문제가 재현되는지 여부.
점검의 목표는 지연 시간을 줄이는 것이 아닙니다. 같은 도메인이 안정적으로 조회되고 요청이 예상한 규칙에 따라 아웃바운드로 전달되어 페이지 응답을 받는 것이 기준입니다. 특정 도메인이나 네트워크 경로에서만 문제가 발생한다고 확인했다면 유효한 비교 결과를 기록해 두고 정상인 다른 설정은 더 이상 변경하지 않아도 됩니다.