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

핵심 내용

Shadowrocket의 DNS 설정은 도메인 이름을 해석하는 기능이며, 프록시 출구를 선택하는 기능과는 다릅니다. 이미 사용할 수 있는 연결 구성이 있다는 전제하에 시스템 DNS를 기준으로 삼고, 사용자 지정 DNS나 DNS over HTTPS로 바꿔야 할 때와 설정이 덮어쓰였는지 확인하는 방법, DNS 기록과 규칙 매칭으로 변경 결과를 검증하는 방법을 설명합니다.

1. DNS 서버, 조회 전송 방식, 접속 경로 구분하기

웹사이트에 접속할 때 기기는 먼저 도메인 이름을 IP 주소로 변환해야 하는 경우가 많습니다. DNS는 “이 이름에 어떤 주소가 연결되는지” 답하고, Global Routing과 규칙은 “이 연결이 어떤 경로로 접속할지” 결정합니다. 두 설정은 서로 영향을 줄 수 있지만, DNS를 바꾼다고 웹 트래픽이 자동으로 PROXY를 사용하거나 기존 연결 서비스가 바뀌지는 않습니다.

‘시스템 DNS’와 ‘사용자 지정 DNS’는 주로 DNS 서버를 어디서 가져오는지 구분합니다. DNS over HTTPS(DoH)는 조회를 어떤 방식으로 전송하는지를 나타냅니다. 따라서 사용자 지정 DNS에 DoH를 사용할 수도 있으며, 세 가지 중 하나만 선택해야 하는 것은 아닙니다. 실제 설정 방식에 따라 아래 세 가지로 나누어 테스트 순서를 정리했습니다.

기존 DNS는 보통 UDP 또는 TCP 포트 53을 사용합니다.

443

DoH는 보통 HTTPS 포트 443을 통해 전송됩니다.

A / AAAA

IPv4 주소와 IPv6 주소를 각각 반환합니다.

포트 번호는 일반적으로 사용하는 약속일 뿐, 서비스가 정상 작동한다는 증거는 아닙니다. DoH에는 올바른 HTTPS endpoint, 유효한 인증서, 연결 가능한 네트워크 경로가 필요합니다. 일반 웹페이지가 HTTPS로 열린다고 해서 같은 호스트가 DNS 조회 인터페이스를 제공하는 것은 아닙니다. 이 글의 예약 주소와 예시 도메인은 형식을 설명하기 위한 것으로, 실제 DNS 서비스 주소가 아닙니다.

2. 시스템 DNS, 사용자 지정 DNS, DoH 중 무엇을 선택할까

시스템 DNS: 문제 해결의 기준점

권장

현재 시스템에서 사용할 수 있는 DNS 설정을 그대로 사용하며, 보통 접속 중인 네트워크의 영향을 받습니다. Wi-Fi와 셀룰러 네트워크를 전환하면 실제 DNS 환경이 달라질 수 있습니다. 시스템에 설치된 DNS 구성도 영향을 줄 수 있으므로, 시스템 DNS를 라우터 주소와 동일한 것으로 단정할 수는 없습니다.

적합한 상황: 처음 연결을 확인할 때, 기본 동작으로 되돌릴 때, 사용자 지정 설정이 문제의 원인인지 확인할 때

사용자 지정 DNS: DNS 서버 지정

DNS 서버를 직접 지정해 네트워크를 바꿀 때 생기는 변수를 줄입니다. 일반 IP 주소를 입력해 기존 DNS를 사용하면 ‘사용자 지정’이라는 이유만으로 조회가 암호화되지는 않습니다. 또한 실제 조회 경로에서 해당 서버에 접속할 수 있어야 합니다.

적합한 상황: 사용할 DNS 서버가 정해져 있을 때, 내부 도메인을 처리해야 할 때, 동일한 조건으로 비교 테스트를 할 때

DNS over HTTPS: 조회 전송 암호화

DNS 조회를 HTTPS로 전송해 클라이언트와 DNS 서비스 사이의 조회 내용을 보호합니다. DNS 서비스가 직접 확인하는 조회 내용까지 숨기지는 않으며, 웹사이트 접속 경로와 최종 연결 품질을 보장하거나 DNS 응답이 항상 예상과 일치하게 해 주지도 않습니다.

적합한 상황: 신뢰할 수 있고 접속 가능한 DoH endpoint가 있으며 DNS 전송을 암호화해야 할 때

요약: 기본 DNS를 확인한 다음 별도로 변경하세요

먼저 시스템 DNS를 사용한 접속 결과를 기록한 뒤 DNS 설정만 바꾸세요. 서버, Global Routing, 규칙 파일을 동시에 변경하면 접속이 복구되어도 어떤 변경이 원인이었는지 알 수 없습니다.

DoH를 사용한다고 해서 모든 DNS 조회가 프록시를 통과하는 것은 아닙니다. 조회가 직접 연결되는지 프록시를 거치는지는 현재 구성과 실제 기록을 함께 확인해야 합니다. endpoint에 접속할 수 없거나 endpoint 호스트 이름을 처음부터 해석할 수 없다면, DoH를 켠 뒤 여러 웹사이트에서 동시에 DNS 시간 초과가 발생할 수도 있습니다.

3. 변경 전 Settings와 Config에서 적용 중인 설정 확인하기

먼저 Home에서 현재 서버와 Global Routing을 기록한 다음 Settings → DNS에 설정된 항목을 확인하고, Config에서 현재 선택된 구성 파일을 살펴보세요. 활성 구성에 자체 DNS 매개변수가 포함되어 있을 수 있습니다. 입력란 하나가 바뀐 것만 보고 모든 연결에 새 DNS 서버가 적용됐다고 판단하지 마세요. 화면의 분류와 구성에서 제공하는 옵션은 다를 수 있으므로 실제로 표시되는 항목을 기준으로 확인하세요.

기존 값을 저장하세요. 현재 DNS 주소, 활성 Config 이름, 라우팅 모드를 기록하고 복원할 수 있는 구성 사본을 보관하세요. 구성이 구독이나 원격 파일로 관리된다면, 이후 업데이트가 로컬 변경 사항을 덮어쓰는지도 먼저 확인하세요.
기준 결과를 기록하세요. 같은 Wi-Fi, 같은 서버, 같은 테스트 도메인을 사용해 시스템 DNS로 한 번 접속하고 성공 여부, 시간 초과 또는 DNS 오류를 기록하세요. 페이지 로딩 속도만 기록해서는 안 됩니다.
변경 위치를 하나만 선택하세요. Settings의 DNS 항목을 사용하거나 직접 관리하는 활성 Config를 편집하세요. 여러 위치에 서로 다른 설정을 입력한 뒤 우선순위를 추측하는 상황은 피하세요.
입력 형식을 확인하세요. 일반 DNS에는 서버 주소를 입력하고, DoH에는 전체 HTTPS endpoint를 입력하세요. 경로도 DNS 서비스 안내와 일치해야 합니다. 구독 주소나 웹사이트 홈페이지를 DNS endpoint로 입력하지 마세요.
연결을 새로 시작하세요. 저장한 뒤 Shadowrocket 연결을 끊었다가 다시 연결하고, 기존 웹페이지 연결을 닫은 다음 새 도메인에 접속하세요. 이전 세션이 아니라 새 요청의 기록을 확인해야 합니다.

직접 관리하는 텍스트 구성에서는 dns-server 작성 방식 세 가지를 아래에서 확인할 수 있습니다. 한 번에 하나만 남기고 [General] 섹션 세 개를 합쳐 복사하지 마세요. 시스템 방식은 기준 설정으로 되돌릴 때 사용할 수 있습니다. 나머지 두 항목은 형식 예시이므로, 이미 보유하고 사용 가능 여부를 확인한 DNS 정보로 바꿔야 합니다.

# 시스템 DNS
[General]
dns-server = system

# 사용자 지정 DNS: 192.0.2.53은 문서 예시용 예약 주소
[General]
dns-server = 192.0.2.53

# DoH: example.com은 endpoint 형식을 보여 주는 예시일 뿐
[General]
dns-server = https://example.com/dns-query

4. DNS 응답이 DOMAIN-SUFFIX, GEOIP, IP-CIDR에 미치는 영향

도메인 규칙과 IP 규칙은 확인하는 대상이 다릅니다. DOMAIN-SUFFIX는 도메인 및 하위 도메인을 확인하고, IP-CIDR은 대상 IP가 지정된 네트워크 대역에 속하는지 확인합니다. GEOIP는 IP 데이터베이스를 기준으로 분류합니다. DNS가 다른 주소를 반환하면 뒤의 두 규칙은 다른 결과를 낼 수 있지만, 도메인 접미사 자체가 바뀌지는 않습니다.

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

도메인 규칙이 먼저 매칭됩니다. 요청에 포함된 도메인이 www.example.com이라면 첫 번째 규칙이 매칭되어 PROXY를 선택할 수 있으며, 이후 IP 규칙은 해당 요청의 정책을 결정하지 않습니다.
주소가 판단에 사용됩니다. 도메인 규칙이 먼저 매칭되지 않은 요청은 이후 IP 규칙에서 대상 주소나 DNS 응답을 참조할 수 있습니다. 추가 DNS 조회가 필요한지는 규칙 옵션과 요청 상태에 따라 달라집니다.
no-resolve의 의미를 확인하세요. 두 번째 규칙 예시의 no-resolve는 해당 규칙을 매칭하기 위해 도메인을 능동적으로 조회하지 않는다는 뜻이지, 모든 DNS를 사용 중지한다는 뜻은 아닙니다. 요청에 대상 IP가 이미 포함되어 있다면 네트워크 대역 매칭은 계속 가능합니다.
FINAL을 마지막 대체 규칙으로 유지하세요.FINAL은 앞선 규칙에 매칭되지 않은 요청을 처리하므로 맨 마지막에 배치해야 합니다. 예시의 예약 네트워크 대역은 문법 설명용이며 실제 서비스 네트워크 대역을 뜻하지 않습니다.

이 규칙을 확인하려면 Home → Global Routing에서 Config를 선택해야 합니다. Proxy와 Direct는 해당 Config의 규칙 목록에 따라 동일한 방식으로 트래픽을 분기하지 않습니다. Scene을 사용한다면 현재 장면에서 실제로 적용되는 설정도 확인해야 합니다. 그렇지 않으면 DNS가 아니라 모드 변경 때문에 접속 경로가 달라졌을 수 있습니다.

같은 도메인이 서로 다른 IP를 반환한다고 해서 반드시 DNS 오류인 것은 아닙니다. CDN 라우팅, 캐시, DNS 서버 위치, A / AAAA 조회 유형에 따라 결과가 달라질 수 있습니다. 매번 같은 응답을 기대하기보다 ‘어떤 주소가 반환됐는지’, ‘어떤 규칙이 매칭됐는지’, ‘최종적으로 어디에 연결됐는지’를 각각 기록하세요.

5. 변경 사항 적용 여부 확인하기: DNS 조회와 접속을 따로 테스트

‘페이지가 열렸다’는 사실만으로 이번 접속이 완료됐다는 점은 확인할 수 있지만, DoH가 적용됐다는 증거는 되지 않습니다. 브라우저가 기존 연결을 재사용하거나 기기, 앱, DNS 서버에 캐시가 남아 있을 수도 있습니다. 가능하면 조회 기록을 확인할 수 있고 직접 제어할 수 있는 테스트 도메인을 사용하세요. 도메인을 직접 관리할 수 없다면 테스트 시간을 기록하고 기존 기록과 새 기록을 구분하세요.

테스트 방법: 같은 구성을 유지하고 두 네트워크를 따로 확인

Wi-Fi에서 테스트

서버, Config, Global Routing을 고정하고 규칙은 동시에 변경하지 마세요.
다시 연결한 뒤 테스트 도메인에 접속하고 A / AAAA 응답과 DNS 오류를 기록하세요.
endpoint에 접속할 수 있는지 확인하고 내부 도메인이 계속 해석되는지도 살펴보세요.

셀룰러 네트워크에서 재테스트

DNS 매개변수는 그대로 두고 접속 네트워크만 바꾸세요.
새 요청을 보내 특정 네트워크에서만 시간 초과가 발생하는지 비교하세요.
DNS 응답이 정상이지만 접속에 실패한다면 규칙, 접속 경로, IPv6 경로를 추가로 확인하세요.

두 네트워크에서 모두 테스트가 성공한 뒤 새 설정을 유지하세요. 한쪽에서만 실패한다면 우선 해당 네트워크와 DNS 서비스 사이의 경로를 확인하세요.

먼저 DNS 기록을 확인하세요. 사용할 수 있는 DNS 로그나 연결 로그에서 이번 테스트 도메인을 찾아 시간, 반환 주소, 오류를 확인하세요. 로그에 DNS 서버나 전송 방식이 표시되지 않는다면, 로그만으로 DoH를 사용했다고 단정할 수 없습니다.
다음으로 규칙 매칭을 확인하세요. 기록에 표시된 정책이 해당 규칙 행과 일치하는지 살펴보세요. 예를 들어 도메인이 DOMAIN-SUFFIX에 매칭되어야 하는데 FINAL로 처리됐다면 실제 요청 도메인과 활성 Config를 확인해야 합니다.
마지막으로 연결 결과를 확인하세요. 유효한 주소를 받았지만 TCP 연결이 시간 초과되거나 TLS 핸드셰이크에 실패했다면 연결 경로와 대상 사이트도 확인해야 합니다. 모든 오류를 DNS 문제로 간주하지 마세요.
필요하면 원래 설정과 비교하세요. 기존 DNS 설정을 복원하고 다른 설정은 그대로 둔 채 같은 도메인을 다시 테스트하세요. 복원 직후 정상적으로 접속될 때 새 DNS 서비스나 endpoint 경로를 추가로 점검할 근거가 생깁니다.

조회가 실제로 DoH를 통해 전송됐다는 점을 확인하려면 DNS 서비스 측의 요청 기록이나 HTTPS 조회 대상을 명확히 표시하는 진단 정보가 가장 직접적인 근거입니다. DNS 응답 시간이 짧아지거나 응답 주소가 달라지는 것, 브라우저의 보안 자물쇠 표시만으로는 이를 입증할 수 없습니다.

6. 자주 묻는 문제: 시간 초과, 내부 도메인, 업데이트 후 설정 변경

DoH 주소를 입력한 뒤 모든 웹사이트가 열리지 않으면 어떻게 하나요?

저장해 둔 시스템 DNS 기준 설정을 복원하고 다시 연결하세요. 접속이 복구되면 endpoint의 전체 경로, 인증서, 포트, 연결 가능 여부를 하나씩 확인하세요. 호스트 이름 자체를 해석할 수 없다면 초기 DNS 조회 조건도 확인해야 합니다. 원인을 찾기 위해 확인되지 않은 endpoint를 여러 개 한꺼번에 추가하지 마세요.

웹페이지는 열리는데 회사 내부 도메인에 접속할 수 없습니다. DNS를 바꿔야 하나요?

먼저 기기가 필요한 내부 네트워크에 연결되어 있는지 확인한 다음 해당 도메인이 내부 DNS에서만 조회되는지 살펴보세요. 공개 DNS 서비스에는 기업 내부 기록이 없는 경우가 많습니다. 내부에서 사용할 수 있는 DNS 방식으로 되돌리거나 조직에서 안내한 도메인 분기 규칙에 맞춰 설정하세요. 내부 도메인을 관련 없는 DNS 서버에 반복해서 조회하지 마세요.

설정을 바꿨는데 로그에 이전 IP가 계속 표시되는 이유는 무엇인가요?

먼저 기록의 시간을 확인하고 기존 웹 세션을 닫은 뒤 다시 연결해 새 요청을 보내세요. 캐시가 만료되지 않았거나 앱이 기존 연결을 재사용하면 새 DNS 조회가 표시되지 않을 수 있습니다. 그래도 바뀌지 않는다면 같은 주소를 반복해서 입력하지 말고 Config에서 실제로 선택된 파일을 확인하세요.

일부 웹사이트만 접속에 실패하면 IPv6를 꺼야 하나요?

먼저 A와 AAAA 응답을 각각 확인하고 실패한 연결이 실제로 어떤 주소 유형을 사용했는지 살펴보세요. AAAA 응답이 있다고 해서 현재 접속 경로에서 IPv6를 사용할 수 있다는 뜻은 아닙니다. 기록이 원인을 뒷받침할 때만 변수를 하나씩 바꿔 비교하세요. 문제를 찾는 대신 IPv6를 전역으로 끄지는 마세요.

업데이트 후 DNS 설정이 원래대로 돌아간 이유는 무엇인가요?

Config에서 활성 구성이 원격 업데이트를 사용하는지 확인하고, 업데이트 전에 보관해 둔 사본과 비교하세요. 서버 구독 업데이트와 전체 구성 업데이트는 서로 다르므로 먼저 어떤 항목이 업데이트됐는지 확인해야 합니다. 로컬 DNS 변경을 계속 유지하려면 직접 구성 사본을 관리하고 이후 변경 사항을 어떻게 병합할지 정해 두세요.

문제를 확인하는 동안 연결 상태가 자동으로 바뀐다면 Settings → On Demand에서 자동 연결 조건이 설정되어 있는지도 확인하세요. 테스트 중에는 현재 상태를 기록해 두세요. 수동으로 연결을 끊은 직후 자동 재연결되면 결과를 잘못 판단할 수 있습니다. 테스트가 끝난 뒤 기존 자동 연결 설정을 복원하세요.

설정을 유지하려면 대상 네트워크에서 DNS가 안정적으로 응답하고, 필요한 내부 도메인에 접속할 수 있으며, 규칙 매칭이 예상대로 동작하고, 기존 구성으로 복원할 수 있어야 합니다. DNS over HTTPS는 조회 전송 방식을 바꾸는 기능이며 서버 연결, Global Routing, 규칙 순서 점검을 대신하지 않습니다.