Shadowrocket에서 연결을 설정한 뒤 DNS 동작을 확인하려는 사용자를 위한 안내입니다. DNS 서버, 쿼리 전송 방식, 트래픽 처리 정책을 구분하고 Config에서 dns-server를 확인한 다음, 시간 초과·응답 주소 이상·네트워크 전환 문제를 한 번에 하나씩 점검합니다. 본인에게 이미 서비스 제공업체와 구독이 있는 경우를 전제로 하며, 사용할 수 있는 연결이나 공용 DNS 서버 목록은 제공하지 않습니다.
1. DNS 조회와 연결 경로 구분하기
Shadowrocket은 Apple 플랫폼용 폐쇄형 상용 앱으로, 주로 iPhone과 iPad에서 사용하며 App Store에서만 구매하고 설치할 수 있습니다. 앱은 일회성 구매 방식입니다. 앱 구매는 연결 서비스 요금제와 별개이며, 이 사이트는 노드·구독·서비스 제공업체를 제공하거나 판매하거나 추천하지 않습니다. 가격, 시스템 요구 사항 및 구매 가능 여부는 App Store 페이지의 안내를 확인하세요. DNS 설정은 앱 구성의 일부이며, 사용자가 이미 이용 중인 연결 서비스를 대체하지 않습니다.
DNS는 도메인 이름을 주소 등의 레코드로 조회하는 기능이지, 웹사이트 연결을 수립하는 기능은 아닙니다. 브라우저에서 도메인에 접속할 때 캐시를 사용하거나 새로 조회할 수 있습니다. 주소를 받은 뒤에도 라우팅, 전송 연결, TLS 핸드셰이크가 이어집니다. 따라서 DNS 조회에 성공했다고 사이트가 열리는 것은 아니며, 연결 실패의 원인이 반드시 DNS인 것도 아닙니다.
이 흐름은 각 단계의 관계를 이해하기 위한 설명이며, 모든 요청이 기기에서 같은 순서로 처리된다는 뜻은 아닙니다. 캐시가 있으면 조회를 건너뛸 수 있고, 일부 프록시 처리 방식에서는 도메인 조회를 원격으로 수행합니다. 앱 자체가 암호화된 DNS 조회를 사용하면 설정된 서버를 사용하지 않을 수도 있습니다. 문제를 확인할 때는 먼저 어떤 종류의 요청을 살펴보는지 파악하세요.
2. 시스템 DNS, 사용자 지정 DNS, DoH 비교
‘시스템 DNS’와 ‘사용자 지정 DNS’는 주로 서버의 출처를, ‘DNS over HTTPS’는 쿼리 전송 방식을 가리킵니다. 따라서 두 개념은 완전히 같은 기준으로 나뉘지 않습니다. DoH 주소를 직접 지정해도 사용자 지정 DNS에 해당합니다. 시스템에서 제공하는 조회 경로도 기기의 DNS 구성 프로파일 등 설정에 영향을 받을 수 있으므로, 반드시 평문으로 전송된다고 단정할 수 없습니다.
| 설정 방식 | 출처 또는 전송 방식 | 사용 전제 | 우선 확인할 항목 |
|---|---|---|---|
| 시스템 DNS | 현재 시스템의 DNS 설정 사용 | 현재 네트워크의 DNS 조회가 정상이며 기준 상태를 확인하려는 경우 | Wi-Fi와 셀룰러 네트워크에서 결과가 다른지 |
| 사용자 지정 일반 DNS | 서버를 직접 지정하며, 일반적으로 UDP/TCP 53 사용 | 서버 주소와 접근 권한을 확인한 경우 | 서버 연결 가능 여부, 포트, 내부 네트워크 접근 범위 |
| DNS over HTTPS | HTTPS로 조회 엔드포인트에 요청 | 신뢰할 수 있고 연결 가능한 전체 DoH 주소를 알고 있는 경우 | 도메인, 경로, TLS 인증서, 초기 DNS 조회 |
포트 번호만으로 서비스 사용 가능 여부를 판단할 수는 없습니다. 어떤 주소에서 443 포트가 열려 있어도 DoH를 제공한다는 뜻은 아닙니다. 일반 DNS도 응답이 크거나 특정 조건에서는 TCP를 사용할 수 있으므로 UDP만 확인해서는 안 됩니다. DoH는 클라이언트와 DNS 서비스 간의 쿼리 전송을 암호화합니다. DNS 서비스는 여전히 쿼리 내용을 처리하며, 웹 연결이 같은 경로로 나간다는 뜻도 아닙니다.
요점: 정상 기준을 유지한 뒤 DNS 방식 변경하기
현재 네트워크가 정상이라면 먼저 시스템 DNS의 동작을 기록하세요. DNS 서버를 지정하거나 쿼리 전송을 암호화해야 할 이유가 분명할 때만 DNS를 별도로 변경하고, 규칙이나 연결 설정을 동시에 바꾸지 마세요.
3. Config에서 dns-server 찾고 수정하기
먼저 Home에서 Global Routing의 현재 선택 항목을 확인한 다음, Config에서 실제로 사용 중인 구성 파일을 확인하세요. 이름이 비슷하지만 활성화되지 않은 파일만 수정하지 않도록 주의하세요. 이 글에서는 설정 텍스트의 [General]과 dns-server를 기준으로 위치를 설명하므로, 화면 배치에 따라 달라지는 버튼 위치에는 의존하지 않습니다.
- Config에서 현재 구성을 선택하고, 원본 파일을 복사해 두거나 기존 DNS 행을 기록해 복구할 수 있도록 준비하세요.
- 해당 구성의 편집 메뉴를 열어 설정 텍스트를 편집할 수 있는 항목으로 이동한 다음
[General]섹션을 찾으세요. 메뉴 구성은 현재 앱 화면을 기준으로 확인하세요. - 기존
dns-server항목을 찾아 해당 행을 수정하세요. 파일 끝이나 다른 섹션에 같은 설정을 추가하지 마세요. - 저장한 뒤 해당 구성이 계속 선택되어 있는지 확인하세요. 다시 불러와야 한다면 Home에서 연결을 껐다가 다시 켤 수 있습니다. 이 과정에서 현재 연결이 잠시 끊깁니다.
- 같은 네트워크와 테스트 도메인을 사용해 다시 확인하고, 변경 전후 결과를 기록하세요. 실패하면 원래 설정으로 되돌려 문제가 해결되는지 확인하세요.
시스템 DNS 기준 설정
- 구성 섹션
[General]- 설정 키
dns-server- 설정 값
system- 확인 작업
- 저장, 선택 상태 확인, 연결 다시 수립
system은 시스템 DNS를 사용한다는 뜻이며, 고정된 서버 주소를 가리키지 않습니다.
DoH 주소 확인
- 구성 섹션
[General]- 설정 키
dns-server- 주소 구성
- HTTPS 스킴, 호스트 이름, 서비스 경로
- 문서 예시
https://dns.example.com/dns-query
example.com은 문서에 사용하는 예시 도메인입니다. 실제 DNS 서비스 주소가 아니므로 연결에 사용할 수 없습니다.
시스템 DNS로 되돌리려면 해당 설정을 아래 형식으로 바꾸세요. 코드는 관련 섹션만 보여주는 예시이며 전체 구성 파일이 아닙니다. 이 내용으로 파일 전체를 덮어쓰지 마세요. 현재 구성이 원격 업데이트로 관리되는 경우 업데이트가 로컬 변경 사항을 덮어쓸 수 있으므로, 사본을 보관하고 업데이트 후 다시 확인하세요.
[General]
dns-server = system4. DNS와 Global Routing, 규칙의 관계
Home → Global Routing은 트래픽 처리 방식을 제어하며 DNS 서버를 선택하는 기능이 아닙니다. Config는 현재 구성의 규칙에 따라 트래픽을 처리합니다. Proxy는 일반 트래픽을 프록시 방식으로, Direct는 직접 연결 방식으로 처리하며, Scene은 설정한 장면 조건에 따라 처리합니다. 이 항목을 전환해도 dns-server 확인을 대신할 수 없으며, 옵션 이름만으로 DNS 요청의 암호화 여부나 특정 경로 사용 여부를 판단할 수도 없습니다.
DOMAIN-SUFFIX는 도메인 접미사로 일치 여부를 판단합니다. 규칙 자체는 대상 IP를 먼저 조회해야 한다고 요구하지 않지만, 실제 연결에는 이후 DNS 조회가 필요할 수 있습니다.IP-CIDR과GEOIP는 IP 정보를 기준으로 일치 여부를 판단합니다. 실제 동작은 요청에 IP가 이미 포함되어 있는지, 규칙에 DNS 조회에 영향을 주는 옵션이 있는지에 따라 달라질 수 있습니다.FINAL은 앞선 규칙에 일치하지 않을 때 적용되는 최종 정책이지, ‘DNS 실패 시 사용할 대체 서버’가 아닙니다.- Settings → On Demand는 조건에 따라 연결을 시작하도록 설정하는 기능이며, 일반 DNS를 DoH로 바꾸지는 않습니다. 문제를 확인할 때 이 설정이 실제 연결 상태를 바꿨는지 기록하세요.
DNS가 반환한 주소는 이후 IP 기반 규칙의 일치 결과에 영향을 줄 수 있지만, 규칙 결과가 달라지는 모든 원인을 DNS로 돌릴 수는 없습니다. DNS 변경 후 접속 경로가 달라졌다면 A/AAAA 레코드, 일치한 규칙, 최종 아웃바운드도 함께 확인하세요. 특정 접속 결과를 얻으려고 규칙 전체를 바로 다시 작성하지 마세요.
5. DNS 오류를 한 번에 하나씩 확인하기
먼저 증상을 구체적으로 기록하세요. 한 도메인만 실패하는지 모든 도메인이 실패하는지, DNS 요청이 시간 초과되는지 주소를 받은 뒤 연결에 실패하는지, Wi-Fi에서만 발생하는지 셀룰러 네트워크에서도 재현되는지 구분합니다. 한 번에 한 항목만 바꾸고 원래 구성으로 되돌렸을 때 접속이 복구되는지 기록해야 관련 원인을 검증 가능한 수준으로 좁힐 수 있습니다.
- 구성이 적용되었는지 확인하세요. Config로 돌아가 현재 선택된 파일과
[General]의 실제 값을 확인합니다. 구독 업데이트와 구성 파일 업데이트는 서로 다른 작업입니다. 노드 목록이 업데이트되었다고 DNS 항목도 변경되었다고 볼 수는 없습니다. - 시스템 DNS 기준으로 되돌리세요. 일시적으로
dns-server = system으로 바꾸고 Global Routing과 선택된 연결은 그대로 유지하세요. 바로 복구된다면 연결 설정을 계속 바꾸기보다 사용자 지정 DNS 엔드포인트를 집중적으로 확인하세요. - 네트워크별로 따로 테스트하세요. Wi-Fi와 셀룰러 네트워크에서 각각 확인합니다. 내부 네트워크 DNS가 Wi-Fi에서만 연결되는 것은 정상적인 제약일 수 있습니다. 웹 인증이 필요한 네트워크에서는 먼저 인증을 완료하세요.
- DoH 관련 조건을 확인하세요. 전체 주소와 서비스 경로, 기기의 날짜 및 시간, 인증서 오류를 확인합니다. 엔드포인트 호스트 이름은 먼저 주소로 조회해야 하는 경우가 많습니다. 초기 DNS 조회가 실패하면 이후 HTTPS 요청을 수립하지 못할 수 있습니다.
- 캐시된 결과와 새 결과를 구분하세요. 테스트 페이지를 다시 열고 앱 및 시스템 캐시를 고려하세요. 연결을 끊었다가 다시 연결해도 모든 캐시가 지워지는 것은 아닙니다. 이전 결과가 계속 사용된다는 이유만으로 설정이 저장되지 않았다고 판단하지 마세요.
- 주소 유형을 확인하세요. AAAA 레코드가 반환된 뒤에만 실패한다면 현재 네트워크와 아웃바운드 경로에서 IPv6에 연결할 수 있는지 확인하세요. AAAA 레코드가 있다는 이유만으로 IPv6 관련 설정을 모두 삭제하지 말고, 실패가 DNS 조회 단계인지 연결 단계인지 먼저 확인하세요.
| 확인된 증상 | 우선 확인할 항목 | 바로 단정할 수 없는 내용 |
|---|---|---|
| 시스템 DNS는 정상이나 사용자 지정 DNS는 시간 초과 | 대상 주소, 포트, 네트워크 연결 가능 여부 | 모든 사용자 지정 DNS를 사용할 수 없다고 단정할 수 없습니다. |
| DoH에서 TLS 관련 오류 발생 | 호스트 이름, 인증서 유효성, 기기 시간 | 인증서 검사를 끄는 방식으로 오류를 숨기면 안 됩니다. |
| 주소는 반환됐지만 웹페이지에 연결할 수 없음 | 일치한 규칙, 아웃바운드, 대상 포트, TLS | 웹페이지가 열리지 않는다는 이유만으로 DNS 시간 초과라고 단정할 수 없습니다. |
| Wi-Fi는 정상이나 셀룰러 네트워크에서 실패 | DNS 엔드포인트가 내부 주소인지, 두 네트워크에서 연결 가능한지 | 같은 주소가 두 네트워크에서 모두 연결 가능하다고 가정할 수 없습니다. |
브라우저에서 DoH 엔드포인트를 직접 열고 빈 페이지나 오류 페이지가 표시된다는 이유만으로 서비스가 중단됐다고 판단하지 마세요. DoH는 프로토콜에 맞는 DNS 요청을 사용하므로 일반 웹페이지 접속은 동일한 테스트가 아닙니다. 웹사이트의 IP 주소에 직접 접속해도 HTTPS 인증서, SNI, 가상 호스트 설정 문제로 실패할 수 있습니다. 이를 ‘DNS를 우회하면 반드시 정상적으로 접속된다’는 근거로 삼지 마세요.
6. 자주 묻는 설정 질문
DoH로 변경한 뒤 느려졌습니다. 계속 기다려야 하나요?
먼저 시스템 DNS로 되돌린 뒤 같은 네트워크와 도메인으로 다시 확인하세요. DoH는 연결 수립에 추가 시간이 들 수 있으며, 캐시와 연결 재사용도 결과에 영향을 줍니다. 페이지 로딩 시간 한 번만으로 DNS 조회 속도를 판단하지 마세요. 차이가 반복해서 확인되면 엔드포인트 연결 가능 여부와 요청 경로를 점검하세요.
DoH 도메인을 IP 주소로 바꿔도 되나요?
직접 바꾸지 마세요. HTTPS 인증서의 호스트 이름 검증이 일치하지 않을 수 있고, 엔드포인트가 해당 호스트 이름에 의존할 수도 있습니다. 기존 DNS 서비스가 제공한 전체 주소를 사용하세요. 초기 DNS 조회에 문제가 있다면 먼저 정상 기준으로 복구한 뒤 해당 서비스의 공식 설정 안내를 따르세요.
DNS 주소를 여러 개 입력하면 순서대로 대체 서버로 사용되나요?
여러 주소가 엄격한 우선순위에 따라 기본·보조 서버로 동작한다고 단정할 수 없습니다. 병렬 처리, 캐시, 구체적인 처리 방식에 따라 결과가 달라질 수 있습니다. 문제를 확인할 때는 사용 가능한 주소 하나만 남겨 단독으로 동작하는지 확인한 뒤 다른 주소를 추가하세요. 그래야 응답이 어느 주소에서 왔는지 구분하기 쉽습니다.
구독 업데이트에 성공했는데 웹페이지가 열리지 않는 이유는 무엇인가요?
구독 업데이트 성공은 해당 구독 내용을 가져와 처리하는 과정이 완료됐다는 뜻일 뿐, 모든 도메인과 연결 경로가 정상이라는 의미는 아닙니다. Config에서 DNS를 확인하고 Home에서 Global Routing과 선택된 연결을 점검하세요. DNS가 이미 주소를 반환했다면 구독을 반복 업데이트하기보다 규칙과 아웃바운드를 확인하세요.
나중에 복구할 수 있는 구성 파일과 간단한 기록을 남겨 두세요. 사용한 네트워크, DNS 설정, 테스트 도메인, 주소 반환 여부, 실패 단계, 복구 결과를 기록하면 됩니다. 기존 서비스의 지원 채널에 문의할 때는 필요한 정보만 전달하고 구독 토큰, 인증 정보, 개인 네트워크 정보는 숨기세요. 구성 파일 전체를 공개하지 마세요.