Shadowrocket DNS 설정: 시스템 DNS·사용자 지정 DNS·DNS over HTTPS 선택 가이드

이 글의 핵심

현재 정상 작동하는 DNS 설정을 기준으로 삼고, 필요에 따라 리졸버와 전송 방식을 하나씩 선택하세요. Shadowrocket에 직접 설정을 추가해 사용하는 분들을 위해 시스템 DNS, 사용자 지정 DNS, DoH의 차이와 설정 확인 순서를 설명합니다. 조회 실패, 규칙 매칭, 대상 연결 실패는 각각 구분해 점검합니다.

리졸버 주소와 DNS 전송 방식을 구분하세요

DNS는 도메인을 주소 등의 레코드로 변환합니다. 시스템 DNS는 기기가 현재 네트워크나 시스템 설정에서 가져온 조회 설정을 뜻하고, 사용자 지정 DNS는 리졸버를 직접 지정하는 방식입니다. DNS over HTTPS(DoH)는 DNS 조회를 HTTPS로 전송하는 방식입니다. 따라서 사용자 지정 DNS와 DoH는 서로 배타적인 선택지가 아닙니다. 사용자 지정 리졸버를 DoH로 사용할 수도 있습니다.

선택할 때는 두 가지를 먼저 확인하세요. 요청을 어느 리졸버로 보낼지, 그리고 어떤 연결을 통해 보낼지입니다. 리졸버를 바꾸면 반환되는 주소가 달라질 수 있고, 전송 방식을 바꾸면 조회 경로와 보호 방식이 달라집니다. 어느 쪽도 웹사이트 자체의 HTTPS 설정을 바꾸는 것은 아니며, 대상 사이트에 반드시 연결할 수 있게 해 주지도 않습니다.

방식	작동 경로	우선 확인할 항목
시스템 DNS	현재 시스템에서 가져온 조회 설정을 사용합니다. 실제 요청 경로는 터널과 설정의 영향을 받습니다.	Wi-Fi와 셀룰러 네트워크를 전환했을 때 조회 결과와 내부 도메인 결과가 달라지는지 확인합니다.
사용자 지정 DNS	지정한 리졸버로 조회 요청을 보냅니다. 일반 DNS는 보통 UDP 또는 TCP 53번 포트를 사용합니다.	주소에 연결할 수 있는지, 포트가 사용 가능한지, 내부 도메인 조회가 필요한지 확인합니다.
DNS over HTTPS	DNS 메시지를 HTTPS를 통해 리졸버 엔드포인트로 전송합니다.	전체 URL, 인증서, 엔드포인트 도메인의 초기 조회 및 실제 아웃바운드 경로를 확인합니다.

판단 기준: 사용 가능한 기준 설정을 유지하고 변수를 하나씩 바꾸세요

현재 네트워크에서 조회가 정상적으로 이루어진다면 시스템 DNS 결과를 먼저 기록하세요. 리졸버를 고정해야 할 때 사용자 지정 DNS를 설정하고, 암호화된 조회 전송이 필요할 때 DoH를 확인하면 됩니다. 리졸버, Global Routing, 프록시 설정을 한꺼번에 바꾸면 어떤 변경이 결과에 영향을 줬는지 알기 어렵습니다.

DNS 조회와 웹 연결은 별도의 점검 단계입니다

일반적인 도메인 접속에서는 앱이 대상 주소를 확인한 다음 연결을 수립합니다. 실제로는 캐시를 사용하거나 앱 자체에서 조회할 수 있으며, 프록시 서버가 조회를 처리할 수도 있습니다. 아래 흐름을 매번 모든 단계가 로컬에서 처리된다는 뜻으로 이해하지 마세요.

도메인 요청 조회 처리 주소 반환 라우팅 결정 대상 연결

문제를 확인할 때는 ‘조회 결과가 있었는지’와 ‘결과를 받은 뒤 연결에 성공했는지’를 따로 기록하세요. 주소가 반환되었다면 해당 조회에는 응답이 온 것입니다. 하지만 그 주소가 현재 출구 경로에서 적절한지, 대상 포트에 연결할 수 있는지, TLS 연결이 성공하는지는 별도로 확인해야 합니다. 브라우저에서 페이지를 열 수 없다는 이유만으로 DNS 장애라고 단정할 수는 없습니다.

일반 DNS에 주로 사용되는 포트이며 UDP 또는 TCP로 통신할 수 있습니다

443

HTTPS 기본 포트이며 DoH 엔드포인트에서 주로 사용합니다

포트에 연결할 수 있는지는 확인 사항 중 하나일 뿐입니다. DoH에는 올바른 HTTPS 경로와 유효한 인증서도 필요합니다. 일반 DNS 주소의 포트를 53에서 443으로 바꾼다고 DoH 서비스가 되는 것은 아닙니다. 반대로 DoH는 리졸버 엔드포인트까지의 조회 전송을 암호화할 뿐, 리졸버가 조회 내용을 볼 수 없게 하거나 모든 서비스 연결을 자동으로 프록시를 통해 전송하지는 않습니다.

설정 전에 백업하고 현재 설정이 DNS 처리에 반영되는지 확인하세요

Shadowrocket에서 먼저 Home을 열어 현재 연결 상태와 Global Routing을 확인한 다음, Settings → DNS에서 조회 설정을 살펴보세요. Config에서 현재 사용 중인 구성 파일도 확인해야 합니다. 구성 파일의 DNS 항목이 실제 동작에 영향을 줄 수 있으므로 Settings에 주소를 입력했다는 이유만으로 최종 사용 리졸버를 단정하지 마세요. 구체적인 항목과 선택지는 현재 앱에 표시되는 내용을 기준으로 확인하세요.

기존 값을 기록하세요. 현재 DNS 항목, 구성 이름, Global Routing 옵션을 기록하세요. 구성 파일을 수정하기 전에 사본을 보관하면 항목별로 원래 상태를 복원하기 쉽습니다.
기준 상태를 확인하세요. 현재 네트워크에서 정상 작동이 확인된 공용 도메인에 접속해 보세요. 내부 리소스가 필요하다면 실제 사용하는 내부 도메인도 비교 대상으로 확인하세요.
DNS만 변경하세요. 이미 보유하고 있고 사용 권한이 있는 리졸버 설정을 사용하세요. 서버, 규칙, 프로토콜 설정은 동시에 바꾸지 마세요.
연결을 새로 설정하세요. 저장한 뒤 연결을 끊었다가 다시 연결하고 접속을 재시도하세요. 기존 연결이나 캐시에서 이전 결과를 계속 사용할 수 있으므로 페이지를 한 번 새로 고치는 것만으로 판단하지 마세요.
네트워크별로 다시 확인하세요. 실제 사용하는 Wi-Fi와 셀룰러 네트워크에서 각각 확인하세요. Settings → On Demand를 설정했다면 테스트 중 자동 재연결이 발생하는지도 점검하세요.

일반 DNS 설정 확인

주소 형식: 리졸버 IP 주소
문서 예시: 192.0.2.53
주로 사용하는 포트: UDP / TCP 53
주요 확인 사항: 연결 가능 여부, 내부 도메인 조회 필요성, 실제 아웃바운드 경로

192.0.2.53은 문서용 예시 주소이며 실제 리졸버로 사용할 수 없습니다.

DoH 설정 확인

주소 형식: 전체 HTTPS URL
문서 예시: https://dns.example.com/dns-query
주로 사용하는 포트: HTTPS 443
주요 확인 사항: 경로, 인증서, 엔드포인트 초기 조회 및 연결 가능 여부

예시 엔드포인트는 조회 서비스를 제공하지 않습니다. 실제 URL에는 사용 중인 DNS 서비스에서 제공한 전체 설정을 사용하세요.

DoH 엔드포인트가 도메인을 사용한다면 HTTPS 연결을 시작하기 전에 해당 도메인의 주소를 알아야 합니다. 이를 초기 조회 또는 bootstrap이라고 합니다. 아직 연결되지 않은 DoH 연결을 엔드포인트의 유일한 조회 경로로 설정할 수는 없습니다. 현재 설정에 이런 의존성이 있다면 같은 URL을 계속 다시 입력하는 대신 초기 조회가 어떻게 이루어지는지 확인하세요. 엔드포인트 도메인을 임의로 IP 주소로 바꾸면 인증서 이름 검증이 실패할 수 있습니다.

DNS와 규칙 기반 라우팅의 관계: 주소가 반환되어도 정책이 매칭된 것은 아닙니다

Home → Global Routing의 Config는 현재 구성의 규칙에 따라 트래픽을 처리합니다. Proxy와 Direct는 서로 다른 전역 라우팅 선택지이므로, 해당 설정에서의 테스트 결과를 Config 규칙 검증에 그대로 사용할 수 없습니다. Scene을 사용하는 경우에는 해당 시나리오에서 실제 적용 중인 라우팅 설정도 먼저 확인하세요. DNS 조회 경로와 대상 연결에 적용된 정책은 각각 점검해야 합니다.

도메인 규칙은 사용할 수 있는 도메인 정보를 기준으로 매칭하고, IP 규칙은 대상 주소를 기준으로 매칭합니다. IP 판정이 필요한 트래픽에서는 조회 결과가 이후 규칙 매칭에 영향을 줄 수 있습니다. 그렇다고 모든 규칙이 먼저 로컬 DNS 조회를 완료해야 하는 것은 아닙니다. 예를 들어 앱이 IP 주소로 직접 요청하면 매칭에 사용할 원래 도메인 정보가 없을 수도 있습니다.

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

DOMAIN-SUFFIX,example.com,PROXY는 example.com과 그 하위 도메인을 매칭해 지정된 정책으로 처리합니다.
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve는 주소 대역 규칙의 예입니다. no-resolve는 이 규칙을 매칭하기 위해 도메인 조회를 새로 시작하지 않는다는 뜻입니다.
GEOIP,CN,DIRECT는 IP 주소 위치 데이터베이스를 기준으로 매칭하며, 도메인 문자열을 기준으로 판단하지 않습니다.
FINAL,PROXY는 앞선 규칙에 매칭되지 않을 때 적용되는 기본 규칙입니다. 규칙 순서가 결과에 영향을 주며 일반적으로 위에서 아래로 확인합니다.

위 내용은 문법 설명이며 예시 도메인과 주소 대역은 문서용입니다. 그대로 적용할 수 있는 완성된 설정이 아닙니다. DNS를 바꾼 뒤 접속이 다른 IP 규칙에 매칭되었다면 먼저 반환된 주소를 비교한 다음 규칙 순서를 확인하세요. 도메인 하나의 문제를 해결하려고 모든 규칙을 삭제하지 마세요. 리졸버 요청도 프록시를 거쳐야 한다면 ‘프록시 연결에 필요한 조회가 그 프록시에 의존하는’ 순환 참조가 발생하는지도 확인하세요.

현상별로 조회 오류를 구분하고 모든 시간 초과를 DNS 탓으로 돌리지 마세요

재검사할 때마다 네 가지를 기록하는 것이 좋습니다. 현재 네트워크, 조회한 도메인, 반환 결과 또는 오류, 이후 연결 성공 여부입니다. 비교할 때는 설정과 대상을 동일하게 유지하고 캐시도 고려하세요. Home의 Connectivity Test는 연결 상태를 파악하는 데 참고할 수 있지만, 한 번 측정한 지연 시간은 다운로드 속도가 아니며 모든 도메인의 조회가 정상이라는 증거도 아닙니다.

DoH로 바꾼 뒤 모든 도메인에서 시간 초과가 발생하면 어떻게 해야 하나요?

먼저 기존 DNS 설정으로 되돌려 기준 상태가 복구되는지 확인하세요. 그런 다음 Settings → DNS의 전체 URL, 엔드포인트 도메인의 조회 가능 여부, 기기 시간이 정확한지, 현재 라우팅이 엔드포인트 연결을 차단하는지 점검하세요. 일반 웹페이지가 열린다고 해서 지정한 DoH 경로도 반드시 작동하는 것은 아닙니다.

공용 웹사이트는 열리지만 집의 내부 도메인은 열리지 않나요?

기기가 해당 내부 네트워크에 계속 연결되어 있는지 먼저 확인한 다음, 시스템 DNS와 사용자 지정 DNS의 결과를 비교하세요. 공용 리졸버에는 로컬 네트워크의 비공개 레코드가 없는 경우가 많습니다. 공용 리졸버를 계속 바꾸기보다는 필요한 내부 DNS 조회 경로를 유지하세요. 일반 DNS 이름과 .local을 사용하는 mDNS 이름도 구분해야 합니다.

IP 주소가 반환되었는데 웹페이지가 계속 로딩됩니다. DNS 문제인가요?

먼저 해당 연결에 매칭된 규칙과 정책을 확인한 다음 대상 연결 시간 초과나 TLS 오류를 점검하세요. A 레코드와 AAAA 레코드가 함께 반환되었다면 IPv4와 IPv6 경로가 모두 사용 가능한지도 확인해야 합니다. 한쪽 주소 경로만 실패했다면 리졸버 전체가 작동하지 않는다고 단정하지 마세요.

설정을 바꿨는데도 결과가 그대로인 이유는 무엇인가요?

먼저 설정을 저장하고 연결을 다시 설정한 뒤 기존 페이지를 닫고 다시 접속하세요. Config에 관련 DNS 설정이 남아 있는지도 확인해야 합니다. 앱 내장 DoH, 시스템 또는 앱 캐시, 기존 장기 연결 때문에 페이지를 한 번 새로 고쳐도 새 설정이 반영되지 않을 수 있습니다. 관련 요청 기록을 함께 확인하세요.

NXDOMAIN은 리졸버가 도메인이 존재하지 않는다고 응답했다는 뜻이며, 응답이 오지 않는 시간 초과와는 다릅니다. SERVFAIL은 리졸버가 처리를 완료하지 못했다는 뜻으로, 상위 DNS 서버, DNSSEC 검증 또는 다른 조회 오류가 원인일 수 있습니다. 먼저 도메인 철자를 확인하고 같은 도메인의 기준 조회 결과와 비교하세요. 서로 다른 오류를 모두 ‘네트워크가 느림’으로 기록하지 마세요.

확인을 마친 뒤 되돌릴 수 있도록 설정 기록을 보관하세요

최종 선택은 실제 접속 환경과 필요에 따라 결정하세요. 시스템 DNS는 현재 네트워크의 기준으로 사용하기 좋습니다. 리졸버를 고정하면 조회 출처를 명확히 관리할 수 있고, DoH는 HTTPS 조회 전송이 필요하며 엔드포인트에 정상적으로 연결할 수 있는 환경에 적합합니다. 특정 방식을 유지할지는 조회 시간 한 번만 볼 것이 아니라 공용 도메인, 내부 도메인, 현재 규칙 기반 라우팅을 함께 확인해 결정하세요.

설정 출처를 기록하세요. 리졸버 설정의 출처와 용도를 기록하고, 공개 스크린샷에 개인 주소나 인증 정보, 구독 내용을 노출하지 마세요.
자동 업데이트를 확인하세요. 기존 구독의 업데이트와 로컬 설정 변경은 별개의 작업입니다. 업데이트 후 관련 설정을 다시 확인해 업데이트로 인한 변화를 DNS 불안정으로 오인하지 않도록 하세요.
복구 절차를 기록하세요. 기존 DNS 값과 Global Routing 옵션을 기록해 두세요. 문제가 생기면 먼저 기준 상태로 되돌린 뒤 항목별로 다시 확인하세요.
한 번에 한 가지씩 확인하세요. 규칙과 DNS를 모두 조정해야 한다면 저장과 테스트를 두 차례로 나누세요. 각 단계의 결과를 구체적인 변경 사항과 연결할 수 있습니다.

Shadowrocket은 Apple 플랫폼용 상용 폐쇄형 앱으로, 주로 iPhone과 iPad에서 사용합니다. 다른 기기와의 호환성 및 시스템 요구 사항은 App Store 페이지 표기를 확인하세요. 앱은 일회성 구매 방식이며 앱 구매와 회선 서비스는 별개입니다. 이 글은 사용자가 직접 구성한 설정을 보유하고 있다는 전제로 작성했으며, 이 사이트는 노드나 구독을 제공·판매·추천하지 않습니다.