Shadowrocket DNS 설정 방법: 시스템 DNS, 사용자 지정 DNS, DNS over HTTPS 비교

이 글의 핵심

Shadowrocket의 DNS 설정은 일부 도메인 조회를 처리할 대상을 정하며, 모든 연결의 출구를 직접 결정하지는 않습니다. 이미 보유한 서비스를 가져온 뒤 도메인 조회 문제를 확인하거나 DNS를 조정하려는 사용자를 위한 글입니다. 먼저 시스템 DNS가 현재 네트워크에서 충분한지 확인하고, 사용자 지정 DNS와 DNS over HTTPS를 비교한 다음 동일한 도메인과 네트워크, 같은 규칙으로 결과를 검증합니다. 초기값과 사용 가능한 옵션은 현재 앱에 표시되는 내용을 기준으로 확인하세요.

1. DNS 조회와 서비스 연결 구분하기

DNS는 도메인 이름을 연결에 필요한 정보로 변환합니다. 일반적으로 A 레코드는 IPv4 주소를, AAAA 레코드는 IPv6 주소를 반환합니다. 주소를 받은 뒤에는 클라이언트가 TCP, UDP 또는 다른 방식으로 서비스 연결을 설정해야 합니다. 따라서 ‘도메인 조회 성공’과 ‘웹페이지 열림’은 서로 다른 항목입니다. DNS가 주소를 반환해도 대상 포트에 연결할 수 있는지, 프록시 연결이 성공하는지, 웹사이트 인증서가 정상인지는 별도로 확인해야 합니다.

아래 흐름은 흔히 볼 수 있는 로컬 조회 상황을 설명하며, 모든 요청이 로컬 DNS를 거쳐야 하는 것은 아닙니다. 일부 프록시 연결은 도메인 조회를 원격으로 처리할 수 있고, 일부 앱은 자체 암호화 조회를 사용하기도 합니다. 문제를 진단할 때는 실제 요청 기록을 함께 확인하세요. 한 곳의 DNS 설정이 모든 앱의 조회를 강제로 처리한다고 단정해서는 안 됩니다.

도메인 요청 시작 조회 경로 선택 주소 결과 받기 서비스 연결 설정 응답 결과 확인

예를 들어 웹페이지에 ‘서버를 찾을 수 없음’이 표시되면 조회가 시간 초과되었는지, 도메인이 존재하지 않는다는 응답을 받았는지 확인해야 합니다. 주소를 이미 받았는데 이후 연결이 시간 초과된다면 출구 경로, 대상 포트, 네트워크 상태를 추가로 점검하세요. 브라우저의 오류 메시지만 보고 DNS를 계속 바꾸지는 마세요.

2. 시스템 DNS, 사용자 지정 DNS, DoH 비교

시스템 DNS는 일반적으로 현재 네트워크의 조회 설정을 따르며, Wi-Fi, 셀룰러 네트워크 또는 기기 관리 설정에서 제공될 수 있습니다. 사용자 지정 DNS는 조회 서버를 직접 지정하는 방식이고, DNS over HTTPS(DoH)는 HTTPS 연결을 통해 DNS 조회를 전송합니다. 두 방식은 서로 배타적이지 않습니다. DoH 서비스 주소를 직접 입력하는 것도 사용자 지정 조회 설정에 해당합니다.

방식	일반적인 전송 방식	적합한 상황	주요 확인 사항
시스템 DNS	시스템 및 현재 네트워크 설정에 따라 다름	현재 네트워크의 조회가 정상인 경우 또는 내부 도메인에 접근해야 하는 경우	네트워크를 바꿀 때 조회 서버와 내부 도메인이 달라지는지
사용자 지정 일반 DNS	대개 UDP 53, 일부 응답은 TCP 53 사용	접속 가능한 조회 서버 주소를 알고 있는 경우	서버 경로와 53번 포트가 연결되는지, 반환된 레코드가 예상과 일치하는지
DNS over HTTPS	대개 HTTPS 443	접속 가능한 DoH 서비스가 있고 암호화된 조회 전송이 필요한 경우	전체 URL, 인증서, 서비스 도메인 조회 및 연결 경로

DoH는 기기와 DoH 서비스 사이의 조회 전송을 보호하지만, 조회 내용은 해당 서비스에 전달됩니다. 또한 모든 서비스 트래픽을 암호화하는 기능은 아닙니다. 프록시를 경유하는지는 실제 조회 경로와 아웃바운드 정책을 별도로 확인해야 합니다. 주소가 https://로 시작한다는 이유만으로 서비스 연결까지 프록시를 경유한다고 단정할 수는 없습니다.

설정값 제안: 작동하는 기준부터 확인하고 암호화 조회는 그다음에

현재 네트워크에서 DNS 조회가 안정적이라면 먼저 시스템 DNS의 동작을 기록하세요. 재현 가능한 조회 문제가 있거나 조회 전송 방식에 명확한 요구가 있을 때만, 접속 가능한 사용자 지정 DNS 또는 DoH 서비스를 하나씩 테스트합니다. 확인되지 않은 설정을 한꺼번에 여러 개 추가하지 마세요.

3. Settings → DNS 설정 순서와 값 기록하기

Settings → DNS를 열어 현재 값을 먼저 기록하고, Config에서 현재 활성화된 설정에도 DNS 관련 항목이 있는지 확인합니다. 앱 설정과 Config가 함께 실제 동작에 영향을 줄 수 있으므로 한쪽 입력란만 확인해서는 안 됩니다. 필드 이름과 초기값, 지원되는 형식은 현재 앱에 표시되는 내용을 기준으로 확인하세요. 이전 설정의 값을 모든 기기의 기본값으로 간주하지 마세요.

기존 설정을 보존합니다. Settings → DNS의 현재 값과 활성화된 Config를 기록하고, 필요하면 기존 Config의 사본을 보관하세요. 유일하게 작동하는 설정을 바로 덮어쓰지 마세요.
한 번에 한 가지 방식만 선택합니다. 시스템 DNS, 사용자 지정 일반 DNS, DoH를 테스트할 때마다 설정 하나만 바꾸세요. Global Routing, 서버 선택, 테스트 네트워크는 동일하게 유지합니다.
실제 서비스 정보를 입력합니다. 일반 DNS에는 접속 가능한 서버 주소를 사용하고, DoH에는 서비스 제공자가 안내한 전체 URL을 입력합니다. 경로를 임의로 추측하거나 일반 웹사이트의 홈 주소를 DoH 엔드포인트로 사용하지 마세요.
안내에 따라 저장하고 적용합니다. 현재 화면에서 다시 연결해야 적용된다고 안내하면 그대로 진행한 뒤 새 조회를 시작하세요. 기존 연결과 캐시에 이전 결과가 남아 있을 수 있습니다.
검증한 뒤 설정을 유지할지 결정합니다. 같은 도메인으로 조회와 서비스 연결을 확인하고, Wi-Fi와 셀룰러 네트워크를 바꿔 다시 테스트하세요. 새 문제가 생기면 기록해 둔 기존 설정으로 되돌립니다.

일반 DNS 기록 카드

확인 항목: Settings → DNS
주소 형식: 조회 서버의 IPv4 또는 IPv6 주소
일반적인 포트: UDP 53, 필요한 경우 TCP 53
기록 예시: 192.0.2.53 — 문서 예시일 뿐입니다

예시 주소는 실제 조회 서비스로 사용할 수 없습니다. 실제 값은 사용 중인 네트워크나 조회 서비스의 안내를 확인하세요.

DoH 기록 카드

주소 형식: scheme, 도메인, 경로를 포함한 전체 URL
형식 예시: https://dns.example.com/dns-query
일반적인 포트: HTTPS 443
사전 조건: 서비스 도메인을 조회할 수 있고 인증서가 유효하며 엔드포인트에 연결 가능해야 함

이 URL은 형식을 보여 주기 위한 예시이며 실제로 사용할 수 있는 서비스가 아닙니다. 경로는 해당 서비스가 제공한 값이어야 합니다.

주소를 여러 개 설정해도 적힌 순서대로 엄격하게 차례차례 대체된다는 뜻은 아닙니다. 조회를 어떻게 분배하는지, 실패 시 대체 경로가 있는지, 현재 조회에 어떤 설정이 적용되는지는 앱과 Config의 실제 동작을 기준으로 확인해야 합니다. 문제를 찾는 동안에는 여러 주소를 쌓아 두기보다 명확한 출처 하나만 사용해야 결과를 해석하기 쉽습니다.

4. DoH에 연결되지 않으면 서비스 도메인의 초기 조회부터 확인하기

DoH 엔드포인트 자체도 보통 도메인 이름을 사용합니다. HTTPS 연결을 설정하려면 기기가 먼저 해당 도메인의 주소를 가져와야 하며, 이 단계를 초기 조회라고 부르기도 합니다. 유일한 조회 경로가 아직 연결되지 않은 DoH 연결에 의존하면 순환 의존성이 생길 수 있습니다. DoH를 켠 뒤 새 도메인이 모두 시간 초과되지만 기존 조회 설정을 복원하면 다시 접속되는 현상이 나타날 수 있습니다.

URL을 확인합니다. 앞뒤 공백이 없고 경로가 빠지거나 복사 중 잘리지 않았는지 확인하세요. /dns-query는 흔히 쓰이는 경로지만 모든 서비스가 반드시 이 값을 사용하는 것은 아닙니다.
인증서를 확인합니다. 기기 시간이 정확한지, HTTPS 인증서가 서비스 도메인과 일치하는지 확인하세요. 연결 문제를 숨기려고 인증서 검증을 끄지 마세요.
초기 조회를 확인합니다. 기존에 작동하던 조회 방식으로 서비스 도메인이 주소를 반환하는지 확인하고, 현재 설정에 순환 의존성이 있는지 점검하세요.
전송 경로를 확인합니다. 443번 포트에 연결할 수 있는 것은 필요한 조건 중 하나일 뿐입니다. 일반 웹페이지가 열린다고 해서 DoH 조회에 정상적으로 응답한다는 뜻은 아닙니다.

DoH URL의 도메인을 임의로 IP 주소로 바꾸지 마세요. HTTPS 인증서와 서비스 라우팅은 원래 도메인에 의존할 수 있으므로, 주소를 바로 바꾸면 인증서가 일치하지 않을 수 있습니다. 서비스가 초기 조회나 주소 연결에 관한 별도 안내를 제공한다면 실제 문서와 앱의 지원 항목에 따라 설정하세요. 경험만으로 매개변수를 임의로 조합하지 마세요.

5. DNS와 Global Routing 및 규칙 기반 라우팅의 관계

Home → Global Routing의 Proxy, Direct, Config, Scene은 라우팅 방식을 선택하는 항목이며 DNS 서버 주소와는 별개입니다. Proxy는 프록시 경로를, Direct는 직접 연결 경로를 사용합니다. Config는 현재 설정의 규칙에 따라 처리하고, Scene은 선택한 시나리오 설정에 따라 처리합니다. 규칙이 적용되는지 확인하기 전에 현재 방식이 예상한 규칙을 실제로 사용하는지 먼저 확인하세요.

아래는 규칙 문법 예시일 뿐이며, 기존 Config를 그대로 대체할 수 있는 완전한 설정이 아닙니다. PROXY가 현재 설정에서 유효한 정책을 가리켜야 합니다. 문서용 IP 주소 대역은 실제 서비스 대상이 아닙니다.

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

DOMAIN-SUFFIX는 도메인 접미사로 일치 여부를 판단하며, 해당 규칙을 적용하기 위해 대상 IP를 미리 조회할 필요는 대개 없습니다. 이 규칙은 DNS 서버 설정이 아닙니다.
IP-CIDR은 대상 IP가 속한 네트워크 대역을 기준으로 일치 여부를 판단합니다. 예시의 no-resolve는 해당 규칙을 위해 도메인을 능동적으로 조회하지 않는다는 뜻입니다. 대상 IP를 이미 알고 있다면 네트워크 대역을 판단할 수 있습니다.
GEOIP는 IP의 지리적 위치 데이터에 따라 일치 여부를 판단합니다. 아직 주소를 얻지 못한 도메인 요청은 이 판단 과정에서 조회가 필요할 수 있습니다. 위치 판정이 대상의 실제 위치를 항상 정확히 보장하는 것은 아닙니다.
FINAL은 앞선 규칙 중 어느 것도 일치하지 않을 때 적용할 기본 정책을 지정합니다. 잘못된 DNS 응답이나 연결할 수 없는 조회 서버를 해결해 주지는 않습니다.

DNS를 바꾸면 반환되는 대상 주소가 달라져 IP 기반 규칙의 일치 결과에 영향을 줄 수 있습니다. 반대로 프록시 출구와 네트워크 상태도 조회 서비스에 연결할 수 있는지에 영향을 줍니다. 문제를 진단할 때는 ‘도메인이 어떻게 조회되는지’와 ‘조회 후 어떤 경로로 나가는지’를 따로 기록하세요. 두 가지를 동시에 바꾸면 원인을 판단하기 어렵습니다.

6. 조건을 고정해 검증하고 한 번의 페이지 로딩으로 결론 내리지 않기

DNS 캐시, 연결 재사용, 웹사이트의 여러 주소 처리 방식은 관찰 결과에 영향을 줍니다. 설정을 바꾼 뒤 기존 웹 연결은 계속 작동하는데 새 도메인은 실패할 수 있습니다. 그렇다고 설정이 저장되지 않았다고 단정할 수는 없습니다. 정상 작동을 확인한 공개 도메인 하나와 실제 문제가 발생한 도메인 하나를 정하고, 테스트 조건을 동일하게 유지하면서 조회 단계와 연결 단계를 각각 기록하세요.

기준 상태를 기록합니다: 같은 Wi-Fi에 연결한 상태에서 DNS 방식, Global Routing, 선택한 서버, 대상 도메인, 오류 메시지를 기록합니다.
기본 연결을 확인합니다: Home에서 Connectivity Test를 실행해 테스트 대상에 연결할 수 있는지 확인합니다. 테스트 성공은 해당 테스트 경로가 작동한다는 뜻일 뿐, 모든 도메인과 모든 DNS 조회가 정상이라는 보장은 아닙니다.
한 항목만 변경합니다: DNS 방식만 바꾸고 앱 안내에 따라 적용합니다. 같은 대상을 새로 세 차례 접속해 성공, 시간 초과 또는 구체적인 오류를 기록하세요. 세 번의 결과를 장기적인 성능 결론으로 확대 해석하지 마세요.
네트워크별 차이를 확인합니다: 그다음 다른 설정은 그대로 두고 셀룰러 네트워크로 바꿉니다. Wi-Fi에서만 실패한다면 해당 네트워크의 조회 설정과 포트 제한부터 확인하세요.
원래 설정으로 되돌려 재확인합니다: 기존 설정을 복원한 뒤 같은 테스트를 반복합니다. 설정을 바꿀 때마다 문제가 일관되게 재현되는 경우에만 해당 조회 경로가 원인이라고 판단할 근거가 됩니다.

판단 기준: 조회에 성공했는데도 시간 초과되면 연결을 점검하세요

기록에 대상 주소가 있는데 이후 연결 단계에서 실패한다면 규칙 적용 여부, 아웃바운드 정책, 대상 포트를 확인하세요. 주소를 전혀 얻지 못한다면 DNS 서비스 연결 상태, DoH 초기 조회, 캐시 영향을 중심으로 점검해야 합니다.

7. DNS 설정 관련 자주 묻는 질문

DoH를 켠 뒤 웹페이지가 느려졌습니다. 계속 사용해야 하나요?

같은 네트워크와 Global Routing 설정에서 기존 조회 방식과 비교하세요. DoH는 최초 연결 시 초기 조회와 TLS 연결 설정에 시간이 들 수 있고, 이후 연결에서는 기존 연결을 재사용할 수도 있습니다. 새로 접속하는 여러 차례의 테스트에서 계속 눈에 띄게 느리거나 시간 초과된다면 기존 설정으로 되돌린 뒤 엔드포인트에 연결할 수 있는지 확인하세요. ‘암호화’가 반드시 더 빠르다는 뜻은 아닙니다.

회사나 집의 내부 도메인이 열리지 않습니다. 공개 DNS로 바꾸면 해결되나요?

내부 도메인은 현재 네트워크의 조회 서버에서만 확인할 수 있을 수 있습니다. 먼저 네트워크의 기존 DNS를 복원해 내부 도메인이 다시 조회되는지 확인하세요. 서로 다른 조회 경로를 함께 사용해야 한다면 현재 Config에서 지원하는 설정을 이용해 경로를 명확히 나눠야 합니다. 내부에서만 사용할 수 있는 도메인을 해당 레코드를 모르는 외부 조회 서비스에 계속 보내지 마세요.

DNS를 바꿔도 일부 웹사이트가 열리지 않습니다. IPv6 문제인가요?

일부 웹사이트에 접속할 수 없다는 이유만으로 원인을 단정할 수는 없습니다. AAAA 레코드가 반환되는지, IPv6 연결 단계에서 실패하는지 먼저 확인하세요. AAAA 레코드가 있다는 것은 IPv6 주소가 존재한다는 뜻이지, 현재 네트워크에서 사용할 수 있는 경로가 있다는 보장은 아닙니다. 현재 IPv6 관련 설정을 기록한 뒤 하나씩 테스트하고, DNS와 규칙, 네트워크 옵션 여러 개를 동시에 바꾸지 마세요.

구독 업데이트에 실패했습니다. DNS를 바꾸면 바로 해결되나요?

먼저 Home에서 보유 중인 구독을 업데이트하고 구체적인 오류를 기록하세요. 도메인 조회 실패가 표시되면 구독 도메인의 조회 상태를 확인합니다. HTTP 상태 오류, 인증 정보 만료 또는 응답 내용 파싱 오류라면 DNS를 바꿔도 대개 해결되지 않습니다. 구독 업데이트와 서비스 연결은 서로 다른 경로를 사용할 수 있으므로 각각 검증해야 합니다.

최종적으로 사용할 설정을 보관할 때 테스트 네트워크와 현재 Config도 함께 기록하세요. 다음에 네트워크를 바꾸거나 Config를 업데이트한 뒤 문제가 생기면 DNS를 조정하기 전에 먼저 조건을 비교하세요. Global Routing 및 규칙 확인 방법은 옵션 매뉴얼의 Global Routing 안내와 규칙 안내를 참고하세요.