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

이 글의 핵심 내용

시스템 DNS는 현재 네트워크를 점검할 때 기준으로 삼기 좋고, 사용자 지정 DNS는 사용할 리졸버를 직접 지정할 때, DNS over HTTPS는 클라이언트와 리졸버 간의 쿼리를 암호화할 때 적합합니다. 자체 서비스와 구독을 이용 중인 Shadowrocket 사용자를 위해 Config의 General 섹션을 수정하는 방법, DNS 문제와 연결 문제를 구분하는 방법, 변경 사항을 확인하고 되돌리는 방법을 설명합니다.

1. DNS 조회와 웹사이트 연결 구분하기

DNS는 도메인 이름을 IP 주소로 변환합니다. 예를 들어 A 레코드 조회로 IPv4 주소를 얻고, AAAA 레코드 조회로 IPv6 주소를 얻습니다. 주소를 받은 뒤에도 HTTPS 웹사이트에 접속하려면 연결을 설정하고 TLS 핸드셰이크를 완료한 다음 콘텐츠를 받아야 합니다. 따라서 DNS 응답이 있다고 해서 웹페이지가 반드시 열리는 것은 아니며, 웹페이지가 열리지 않는다고 해서 DNS에 반드시 문제가 있는 것도 아닙니다.

도메인 접속 요청 리졸버에 조회 주소 확인 연결 설정 콘텐츠 가져오기

이 흐름은 문제를 단계별로 구분하기 위한 것이며, 모든 요청이 기기에서 직접 DNS 조회를 한다는 뜻은 아닙니다. Shadowrocket에서 실제로 DNS를 조회하는 위치는 요청 유형, 규칙, 프록시 아웃바운드 방식에 따라 달라집니다. 일부 연결은 대상 도메인의 처리를 원격으로 넘길 수 있습니다. 기기에 DNS 주소를 설정했다는 이유만으로 모든 도메인이 해당 리졸버를 사용한다고 단정할 수는 없습니다.

문제를 확인할 때는 먼저 Home에서 현재 서버를 확인한 다음 Global Routing을 점검하세요. Config는 현재 설정에 따라 트래픽을 분기하고, Proxy와 Direct는 전체 라우팅 방식을 바꾸며, Scene은 선택한 시나리오의 설정에 따라 작동합니다. DNS를 비교하는 동안에는 라우팅 방식을 동일하게 유지하세요. 아웃바운드와 리졸버를 동시에 바꾸면 어떤 변경이 영향을 줬는지 판단하기 어렵습니다.

조회 시간 초과: 리졸버에 연결할 수 있는지, 현재 네트워크에서 해당 전송 방식이 제한되는지 먼저 확인합니다.
NXDOMAIN 응답: 리졸버가 도메인이 존재하지 않는다고 응답한 것입니다. 네트워크 시간 초과와는 다르므로 도메인 철자와 레코드 상태도 확인해야 합니다.
주소는 받았지만 연결 실패: DNS를 계속 바꾸기보다 규칙 적용 여부, 아웃바운드 연결 가능 여부, IPv4/IPv6 경로, TLS를 확인합니다.

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

여기서 ‘사용자 지정 DNS’는 HTTPS 엔드포인트와 구분하기 위해 리졸버 IP를 직접 입력하는 기존 방식의 DNS를 뜻합니다. 설정 관점에서는 직접 입력한 DoH 엔드포인트도 사용자 지정 설정에 해당합니다. 어떤 방식을 선택할지는 이름이 더 고급스럽게 들리는지가 아니라 네트워크 환경, 리졸버 연결 가능 여부, 원하는 쿼리 전송 방식에 따라 결정해야 합니다.

방식	조회 경로	사용 조건	확인할 사항
시스템 DNS	시스템에서 현재 사용할 수 있는 리졸버를 이용하며, 일반적으로 현재 Wi-Fi 또는 셀룰러 네트워크의 영향을 받습니다.	문제 해결의 기준을 마련하거나 현재 네트워크에서 제공하는 내부 도메인 조회가 필요한 경우	네트워크를 바꾸면 리졸버와 조회 결과가 달라질 수 있습니다.
사용자 지정 DNS	지정한 리졸버 IP로 기존 방식의 DNS 쿼리를 전송합니다.	리졸버를 고정해야 하고 해당 주소에 현재 네트워크에서 연결할 수 있는 경우	UDP/TCP 53에 연결할 수 있는지, 리졸버가 현재 요청 출처의 조회를 허용하는지
DNS over HTTPS	DNS 쿼리를 HTTPS 요청에 담아 DoH 엔드포인트로 전송합니다.	암호화된 쿼리 전송이 필요하고 HTTPS 엔드포인트와 인증서를 사용할 수 있는 경우	엔드포인트 전체 경로, TLS 인증서, 엔드포인트 도메인의 초기 조회, 실제 라우팅 경로

기존 방식의 DNS는 일반적으로 UDP/TCP 포트 53을 사용합니다.

443

HTTPS는 포트를 지정하지 않으면 기본적으로 443을 사용합니다.

2가지

주소 레코드: A는 IPv4, AAAA는 IPv6에 해당합니다.

DoH는 클라이언트와 리졸버 사이의 전송을 암호화합니다. 리졸버는 여전히 수신한 쿼리를 처리하고 볼 수 있으며, 웹사이트 연결은 별도의 아웃바운드 경로를 따릅니다. DoH를 켠다고 모든 트래픽이 자동으로 Proxy를 사용하는 것은 아니며, 규칙과 서버 상태 확인을 대신할 수도 없습니다.

요약: 연결 가능 여부를 먼저 확인한 뒤 DoH 사용 여부 결정

시스템 DNS는 안정적으로 응답하는데 DoH 조회가 시간 초과된다면 먼저 엔드포인트와 TLS 경로를 확인하세요. Global Routing은 동시에 변경하지 마세요. 내부 도메인 조회가 필요하다면 시스템 DNS 테스트 결과를 보존한 뒤 외부 리졸버에도 같은 레코드가 있는지 확인합니다.

3. Config에서 dns-server 수정하기

dns-server는 설정 파일의 [General] 섹션에 작성하며 [Rule] 섹션에는 작성하지 않습니다. 아래 코드 블록은 각각 독립적인 설정 예시이므로 한 파일에 모두 이어 붙이지 마세요. 기존 설정을 수정할 때는 기존 규칙과 다른 항목을 유지하고, 이번에 테스트할 DNS 설정만 바꾸세요.

Config에서 현재 활성화된 설정 파일을 확인하고, 먼저 로컬 사본을 저장한 뒤 기존 dns-server 값을 기록합니다.
해당 파일의 편집 화면을 열고 [General]을 찾습니다. 이미 dns-server가 있으면 기존 줄을 수정해 중복 키가 생기지 않도록 합니다.
한 번에 한 가지 방식만 선택하세요. 저장한 뒤에도 이 파일이 활성화되어 있는지 확인합니다. 활성화되지 않은 사본만 편집하면 현재 연결에는 변화가 없습니다.
Home으로 돌아가 연결을 끊었다가 다시 연결해 저장된 설정으로 새 연결을 테스트합니다. 기존 연결과 캐시가 관찰 결과에 계속 영향을 줄 수 있습니다.

방법 A: 시스템 DNS 사용

[General]
dns-server = system

[General]: 일반 설정 섹션을 선언합니다.
dns-server = system: 시스템에서 현재 사용할 수 있는 DNS를 사용합니다. 사용자 지정 설정과 비교할 기준으로 적합합니다.

방법 B: 기존 방식의 DNS 주소 지정

[General]
dns-server = 192.0.2.53

[General]: 동일한 일반 설정 섹션을 사용하며, DNS라는 이름의 별도 섹션을 만들 필요가 없습니다.
dns-server = 192.0.2.53: IPv4 주소를 직접 입력하는 문법의 예시입니다. 이 주소는 문서용 예시 대역에 속하며 실제로 사용할 수 있는 리졸버가 아닙니다. 테스트하기 전에 사용 권한이 있고 연결 가능 여부를 확인한 리졸버 주소로 바꾸세요.

방법 C: DoH 엔드포인트 지정

[General]
dns-server = https://dns.example.com/dns-query

[General]: 앞의 두 방법과 같은 설정 섹션입니다.
https://: HTTPS 전송을 지정합니다. 이를 생략하고 앱이 DoH로 처리할 것이라고 가정해서는 안 됩니다.
dns.example.com: 예시 도메인으로, 이 글에서 DNS 서비스를 제공하는 것이 아닙니다. 실제로는 이미 사용 중인 DNS 서비스의 엔드포인트를 입력해야 합니다.
/dns-query: 흔히 쓰이는 DoH 경로지만 모든 엔드포인트가 이 경로를 사용하는 것은 아닙니다. DNS 서비스에서 제공한 전체 주소를 그대로 입력하고 임의로 경로를 추가하거나 줄이지 마세요.

4. 조회 설정과 규칙, Host를 따로 확인하기

DNS는 주소를 조회하고, 규칙은 요청에 적용할 정책을 선택하며, Host는 특정 도메인에 고정 매핑을 제공할 수 있습니다. 각각 영향을 주는 단계가 다릅니다. 설정에 Host 매핑이 있으면 특정 도메인이 예상대로 상위 리졸버에 조회되지 않을 수 있습니다. 앱이 이전 주소를 보관하고 있다면 페이지를 바로 새로고침해도 변경이 드러나지 않을 수 있습니다.

DNS 설정 확인

경로: Config → 현재 활성화된 파일 → 편집
설정 섹션: [General]
필드: dns-server
매핑 확인: [Host]에 대상 도메인이 있는지 확인

테스트 중인 파일이 맞는지 먼저 확인한 다음 고정 매핑이 결과에 영향을 주는지 살펴보세요.

라우팅 방식 확인

경로: Home → Global Routing
Config: 현재 설정에 따라 트래픽 분기
Proxy / Direct: 전체 아웃바운드 방식 구분
Scene: 선택한 시나리오의 실제 설정 확인

DNS 테스트 중에는 라우팅 방식을 유지하고, 리졸버 변경과 아웃바운드 변경을 한 번의 테스트에 섞지 마세요.

예를 들어 DOMAIN-SUFFIX는 도메인 접미사를, IP-CIDR은 IP 주소 대역을, GEOIP는 IP 지리 데이터베이스를 기준으로 일치 여부를 판단합니다. FINAL은 앞선 규칙에 일치하지 않은 요청을 처리합니다. IP 유형 규칙을 사용할 때는 조회 결과와 규칙 옵션을 함께 확인해 실제 적용 여부를 판단해야 합니다. 도메인 규칙이 적용됐다는 사실만으로 DNS 조회가 성공했다고 볼 수는 없습니다.

도메인 규칙: 대상 도메인과 접미사가 일치하는지 먼저 확인한 다음 최종 정책을 살펴봅니다.
IP 유형 규칙: 실제 대상 주소를 기록합니다. DNS 응답 주소가 달라지면 IP 규칙의 적용 결과도 달라질 수 있습니다.
Host 매핑: 대상 도메인에 고정 주소가 설정되어 있다면 해당 매핑이 현재 용도에 맞는지 먼저 확인합니다.
FINAL: 라우팅의 기본 처리 규칙이며 DNS 조회 실패 시 사용할 대체 리졸버가 아닙니다.

5. 변경 후 확인 및 기록 방법

같은 네트워크, 같은 대상, 같은 라우팅 방식에서 필드 하나만 바꾸는 방식으로 검증하세요. 정상적으로 관리되고 직접 접근 권한이 있는 도메인을 선택해 시스템 DNS 결과를 먼저 기록한 뒤 기존 방식의 DNS 또는 DoH를 테스트합니다. 페이지가 한 번 열린 속도만으로 리졸버를 평가하지 마세요. 연결 재사용, 페이지 캐시, 웹사이트 응답 시간이 조회 차이를 가릴 수 있습니다.

기준 기록: Wi-Fi 또는 셀룰러 네트워크, Home의 현재 서버, Global Routing 방식, 활성화된 Config 파일, 대상 도메인을 기록합니다.
저장 후 재연결: dns-server만 수정하고 설정을 저장한 뒤 다시 연결합니다. 대상 앱에서 기존 요청을 종료하고 새로 도메인에 접속합니다.
DNS 조회 확인: 앱에서 사용할 수 있는 DNS 조회 도구나 로그로 대상 도메인의 결과를 확인합니다. A, AAAA, 시간 초과 또는 오류 응답을 기록하세요. 도구에서 리졸버를 따로 선택할 수 있다면 이번 테스트 대상 리졸버를 사용 중인지도 확인합니다.
연결 확인: 실제 요청이 성공하는지, 어떤 정책이 적용됐는지, 연결 또는 TLS 오류가 발생하는지 계속 확인합니다. 지연 시간 숫자 하나만 기록하지 마세요.
네트워크 변경 후 재테스트: 같은 네트워크에서 비교를 마친 다음 Wi-Fi와 셀룰러 네트워크를 각각 테스트합니다. 한쪽 네트워크에서만 실패한다면 먼저 해당 네트워크의 연결 가능성 차이를 확인하세요.

관찰된 현상	다음 확인 사항	바로 단정하면 안 되는 점
기존 방식의 DNS는 시간 초과, DoH는 응답	현재 네트워크에서 리졸버까지 UDP/TCP 53 경로를 확인합니다.	이 결과만으로 모든 웹사이트 연결이 정상이라고 판단할 수는 없습니다.
DoH에서 TLS 오류 발생	엔드포인트 도메인, 인증서 유효성, 시스템 시간, 연결 경로를 확인합니다.	인증서 오류를 일반적인 DNS 지연으로 취급해서는 안 됩니다.
A는 응답하지만 AAAA는 응답하지 않음	도메인에 AAAA 레코드가 있는지 확인하고, 레코드가 없는 경우와 조회 시간 초과를 구분합니다.	AAAA 레코드가 없다고 해서 DNS 전체가 고장 난 것은 아닙니다.
주소는 받았지만 웹페이지가 계속 시간 초과	규칙 적용 여부, 현재 아웃바운드, 반환된 주소에 연결할 수 있는지 확인합니다.	리졸버를 바꾸면 반드시 해결된다고 볼 수 없습니다.
변경 후 결과가 완전히 동일함	활성화된 파일, Host 매핑, 캐시, 기존 연결을 확인합니다.	결과가 같다는 사실만으로 변경 사항이 적용되지 않았다고 단정할 수 없습니다.

요약: 조회 결과와 연결 결과를 함께 확인

DNS 응답이 정상이고 실제 접속도 성공해야 현재 용도에 맞는 설정이라고 판단할 수 있습니다. 특정 네트워크에서만 실패한다면 해당 오류를 기록한 뒤 검증된 설정으로 되돌리고 실패한 단계를 따로 점검하세요.

6. 자주 묻는 질문과 안전한 원상 복구

리졸버를 여러 개 입력하면 왼쪽부터 자동으로 대체 사용하나요?

입력 순서만으로 조회 순서, 병렬 처리 여부, 실패 시 대체 동작을 추정할 수 없습니다. 처음 문제를 점검할 때는 연결 가능 여부가 확인된 리졸버 하나만 사용하세요. 정상적으로 작동하는지 확인한 뒤 실제 설정 요구에 따라 조정하면 됩니다. 시스템 DNS, 기존 방식의 DNS, DoH를 한 목록에 함께 넣으면 특정 응답이 어디에서 왔는지 판단하기 어려워집니다.

DoH를 켜면 조회가 반드시 Proxy를 거치나요?

반드시 그렇지는 않습니다. DoH는 쿼리 전송 방식을 가리키며 라우팅 정책과는 다릅니다. 실제 경로는 현재 설정, Global Routing, DNS 관련 설정을 함께 확인해야 합니다. https://만으로 쿼리가 특정 아웃바운드를 거친다거나 모든 앱이 같은 조회 경로를 사용한다고 판단할 수는 없습니다.

Wi-Fi를 바꾸면 문제가 다시 발생합니다. 무엇을 확인해야 하나요?

먼저 네트워크 변경에 따라 시스템 DNS가 달라지는지, 새 네트워크에서 사용자 지정 엔드포인트에 연결할 수 있는지 확인합니다. Settings → On Demand를 설정했다면 연결 상태가 자동 규칙에 의해 바뀌지 않았는지, 주문형 연결 조건도 점검하세요. On Demand는 연결이 시작되는 조건을 제어하며 dns-server를 대신하지 않습니다.

변경 전 상태로 되돌리려면 어떻게 해야 하나요?

Config에서 기존 dns-server 줄을 복원하거나 미리 저장한 로컬 사본을 다시 활성화한 다음 Home으로 돌아가 재연결합니다. 원래 파일에 해당 필드가 없었다면 임의의 값을 추가하지 말고 원래 상태 그대로 복구하세요. 같은 대상을 다시 테스트해 복원 결과를 확인하고, 이후에도 한 번에 하나씩만 변경합니다.

DNS 설정의 목표는 용도에 맞는 검증 가능한 조회 결과를 얻는 것이지, 모든 네트워크에서 한 가지 방식을 고집하는 것이 아닙니다. 시스템 DNS, 기존 방식의 사용자 지정 DNS, DoH 모두 실제 네트워크에서 확인해야 합니다. 설정 사본과 테스트 기록을 보관하면 여러 설정을 자주 바꾸는 것보다 문제를 찾기 쉽습니다.