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

이 글의 핵심

현재 네트워크에서 DNS가 정상 작동한다면 우선 시스템 DNS를 유지하세요. DNS 서버를 지정해야 할 때는 사용자 지정 DNS를 시험하고, 클라이언트와 리졸버 간 쿼리를 암호화하려면 DNS over HTTPS를 고려할 수 있습니다. 기존 설정을 Shadowrocket에 불러온 사용자를 대상으로 dns-server 수정 위치와 각 방식의 차이, DNS 조회 실패·규칙 오적용·연결 실패를 구분하는 방법을 설명합니다.

1. DNS 조회와 연결 경로 구분하기

DNS는 도메인 이름을 IP 주소로 변환합니다. 예를 들어 www.example.com에 접속하면 리졸버가 IPv4 A 레코드나 IPv6 AAAA 레코드를 반환할 수 있습니다. 주소를 받은 뒤에는 클라이언트가 현재 라우팅 모드와 규칙에 따라 연결 방식을 결정합니다. 따라서 ‘DNS 조회 성공’과 ‘웹페이지 접속 가능’은 서로 다른 확인 단계입니다.

도메인 요청 캐시 확인 리졸버 조회 주소 반환 연결 확인

이 흐름은 일반적인 도메인 조회 확인 순서를 보여 주며, 모든 요청이 매번 DNS를 새로 조회한다는 뜻은 아닙니다. 앱이나 클라이언트 캐시, 원격에서 도메인을 처리하는 연결 방식에 따라 실제 조회 위치가 달라질 수 있습니다. 도메인 규칙이 로컬 조회보다 먼저 적용될 수도 있으므로, DNS가 모든 규칙보다 앞서 거치는 독립 단계라고 단정할 수 없습니다.

Home에서 Global Routing을 확인할 때는 모드와 DNS 설정을 따로 살펴보세요. Config는 현재 설정의 규칙을 사용하고, Proxy와 Direct는 전체 연결 정책을 바꾸며, Scene은 상황별 설정에 따라 작동합니다. 모드를 전환해도 잘못된 리졸버 주소가 수정되는 것은 아닙니다. DoH를 설정했다고 모든 연결이 프록시를 거치는 것도 아닙니다.

DOMAIN-SUFFIX,example.com,DIRECT: 도메인 접미사로 일치 여부를 판단하며, 특정 IP를 기준으로 삼지 않습니다.
IP-CIDR,192.168.0.0/16,DIRECT: 대상 IP의 네트워크 대역으로 일치 여부를 판단합니다. DNS 조회가 필요한지는 요청 방식과 규칙 매개변수에 따라 달라집니다.
GEOIP,CN,DIRECT: 대상 IP의 지리 데이터베이스상 위치를 기준으로 판단하며, 도메인만으로는 판별할 수 없습니다.
FINAL,PROXY: 앞선 규칙과 일치하지 않을 때 적용하는 최종 정책이며, DNS 서버 설정이 아닙니다.

2. 세 가지 DNS 방식 중 선택하기

시스템 DNS와 사용자 지정 DNS는 주로 어떤 리졸버를 사용할지 정합니다. DNS over HTTPS는 쿼리를 전송하는 방식까지 지정합니다. 세 가지는 완전히 같은 기준의 분류가 아닙니다. DoH 엔드포인트를 직접 지정하는 것도 사용자 지정 DNS 설정의 한 형태입니다. 먼저 조회 대상과 네트워크 연결 가능 여부를 확인한 뒤 전송 암호화를 고려하세요.

방식	조회 경로	사용 조건	주요 확인 사항
시스템 DNS	현재 시스템 네트워크가 제공하는 리졸버 정보를 사용합니다.	DNS 조회가 정상 작동하거나 로컬 네트워크의 내부 이름을 조회해야 할 때	Wi-Fi나 셀룰러 네트워크를 바꾸면 리졸버가 달라질 수 있습니다.
사용자 지정 일반 DNS	직접 지정한 DNS 주소로 쿼리를 보냅니다.	사용 가능한 리졸버가 있고 조회 대상을 고정해야 할 때	주소에 연결할 수 있는지, 대상 도메인을 지원하는지, 쿼리 전송이 제한되는지
DNS over HTTPS	HTTPS를 통해 지정한 엔드포인트로 DNS 쿼리를 보냅니다.	암호화된 쿼리 전송이 필요하고 엔드포인트와 인증서를 정상적으로 확인할 수 있을 때	엔드포인트 경로, TLS, 엔드포인트 도메인의 초기 조회, 실제 아웃바운드 경로

일반 DNS에서 흔히 사용하는 UDP/TCP 포트

443

DoH에서 HTTPS를 사용할 때 기본 포트

2종

주요 주소 레코드: A와 AAAA

DoH는 클라이언트와 DoH 리졸버 사이의 쿼리 전송을 암호화하지만, 리졸버는 여전히 도메인 쿼리를 처리합니다. 웹사이트의 HTTPS 동작을 바꾸거나 접속 속도를 보장하지는 않습니다. TLS 연결을 추가하면 첫 쿼리에 시간이 더 걸릴 수 있고, 연결 재사용과 캐시가 이후 결과에 영향을 줍니다. 한 번의 페이지 로딩만으로 성능을 판단하지 마세요.

요약: 정상 작동하는 기준 설정을 유지한 뒤 리졸버 변경하기

시스템 DNS에서 같은 도메인이 안정적으로 조회된다면, 우선 해당 설정을 복구 기준으로 남겨 두세요. 이후에는 매번 dns-server만 바꾸고 규칙, 연결 정책, 서버 매개변수는 함께 바꾸지 마세요. 그래야 결과 변화의 원인을 확인할 수 있습니다.

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

수정하기 전에 Config에서 현재 사용하는 설정을 찾아 사본을 보관한 다음, 해당 설정의 텍스트 편집 화면을 여세요. 수정할 항목은 [General] 섹션의 dns-server 필드입니다. Home의 연결 항목에 있는 Address가 아닙니다. 편집 방법은 현재 화면에 표시되는 메뉴를 따르고, 서버 주소를 DNS 주소로 잘못 수정하지 않도록 주의하세요.

Config에서 현재 선택된 설정 이름을 확인하고 기존 dns-server 값을 기록하세요. 해당 필드가 없었다면 그 상태도 기록해 둡니다.
설정 텍스트를 열고 기존 [General] 섹션을 찾으세요. 같은 설정에 해당 섹션이 있다면 그 안에서 수정하고, 섹션 전체를 중복으로 추가하지 마세요.
이번 테스트에 필요한 dns-server 설정만 하나 남기고 저장한 뒤 해당 설정을 다시 선택하세요.
Home으로 돌아가 테스트할 설정 규칙을 적용하도록 Global Routing을 Config로 설정하세요. 잠시 연결이 끊겨도 괜찮다면 연결을 끊었다가 다시 연결해 변경 사항을 불러옵니다.
동일한 테스트 도메인에 다시 접속해 DNS 조회와 연결 결과를 기록하세요. 실패하면 리졸버를 계속 추가하지 말고 먼저 기존 값으로 되돌리세요.

시스템 DNS: 첫 번째 기준으로 사용하기

[General]
dns-server = system

system은 시스템 DNS 정보를 사용한다는 뜻입니다. 라우터가 반드시 직접 응답한다는 의미도, 다른 앱이 반드시 같은 경로로 조회한다는 의미도 아닙니다. 네트워크를 바꾼 뒤에는 다시 확인하세요. 특히 네트워크 로그인이 필요한 Wi-Fi에서는 유의해야 합니다.

사용자 지정 일반 DNS: 연결 가능성을 확인한 주소 사용하기

[General]
dns-server = 192.168.1.1

192.168.1.1은 로컬 네트워크에서 사용하는 예시 주소입니다. 해당 기기가 실제로 DNS 서비스를 제공하고 현재 네트워크에서 연결 가능한 경우에만 유효합니다. 게이트웨이 주소가 항상 DNS 주소인 것은 아닙니다. 가정용 네트워크의 사설 주소를 셀룰러 네트워크에서 그대로 사용할 수도 없습니다. 실제 값은 사용 중인 네트워크나 DNS 서비스의 설정 안내를 확인하세요.

DoH: 웹사이트 주소가 아닌 전체 엔드포인트 입력하기

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

위의 dns.example.com은 형식을 설명하기 위한 예시이며 실제 연결에 사용할 수 없습니다. 사용 가능 여부를 확인한 DoH 전체 엔드포인트로 바꾸세요. 경로가 항상 /dns-query인 것은 아니므로 해당 DNS 서비스의 안내를 따르세요. 일반 HTTPS 웹페이지가 열린다고 해서 DNS 쿼리도 처리할 수 있는 것은 아닙니다.

4. 엔드포인트, 네트워크, 아웃바운드 조건 함께 확인하기

DoH 엔드포인트는 보통 도메인으로 지정하며, HTTPS 연결을 시작하기 전에 엔드포인트 자체의 주소를 먼저 조회해야 할 수 있습니다. 초기 조회가 되지 않으면 쿼리가 DoH 서비스에 도달하기도 전에 실패합니다. 도메인 형식의 엔드포인트를 목록에 더 추가하는 것만으로는 해결되지 않을 수 있습니다. 엔드포인트의 초기 조회, 라우팅, 현재 네트워크에서의 연결 가능 여부도 확인하세요.

일반 DNS 확인 항목

설정 필드: dns-server
예시 주소: 192.168.1.1, 해당 로컬 네트워크에서만 사용
일반 포트: UDP 53 / TCP 53
네트워크 조건: 현재 인터페이스에서 연결 가능하고 대상이 실제로 DNS 서비스를 제공함

먼저 서버의 역할을 확인한 다음 도메인 조회에 응답하는지 살펴보세요.

DoH 확인 항목

주소 형식: 서비스에서 요구하는 경로를 포함한 전체 HTTPS 엔드포인트
기본 포트: TCP 443
TLS 조건: 인증서가 엔드포인트 도메인과 일치하고 기기 날짜와 시간이 정확함
초기 조회: 연결을 시작하기 전에 엔드포인트 도메인의 주소를 조회할 수 있음

HTTPS는 전송이 암호화된다는 뜻이지, 쿼리가 반드시 프록시를 거친다는 뜻은 아닙니다.

DoH 연결 실패를 해결하려고 인증서 확인을 끄지 마세요. 먼저 전체 주소, 기기의 날짜와 시간, 네트워크 로그인 필요 여부를 확인하세요. Shadowrocket을 켰을 때만 실패한다면 Config의 규칙과 엔드포인트 아웃바운드 조건도 함께 살펴 엔드포인트가 연결할 수 없는 경로로 전송되지 않는지 확인하세요.

로컬 네트워크의 내부 이름이 내부 리졸버에 의존한다면 외부 리졸버로 바꿨을 때 해당 이름의 레코드를 찾지 못할 수 있습니다.
AAAA 레코드가 반환되어도 현재 IPv6 연결 경로가 작동한다고 볼 수는 없습니다. 조회 결과와 연결 가능 여부를 각각 확인하세요.
앱이 자체 DoH를 사용하거나 결과를 장기간 캐시하면 클라이언트 DNS를 바꿔도 새 쿼리가 보이지 않을 수 있습니다.
일부 요청은 원격에서 도메인을 처리하므로 로컬 로그에 조회 기록이 없다는 이유만으로 설정이 작동하지 않는다고 판단할 수 없습니다.

5. 정해진 순서로 DNS 적용 여부 확인하기

확인하는 동안 네트워크, 규칙, 연결 항목을 동일하게 유지하세요. 먼저 시스템 DNS로 기준 결과를 기록한 다음 사용자 지정 리졸버 하나로 바꾸고, 매번 같은 도메인을 사용하세요. 기존 구독을 새로고침하거나 네트워크와 DNS를 동시에 변경하지 마세요. 접속이 복구되더라도 어떤 변경이 효과를 냈는지 알 수 없습니다.

기준 기록: 네트워크 유형, 활성화된 설정, Global Routing 모드, 테스트 도메인, 변경 전 증상이 DNS 조회 시간 초과였는지 연결 시간 초과였는지 기록합니다.
설정 다시 불러오기: 저장한 뒤 설정을 다시 선택하고 재연결하세요. 앱이 이전 연결을 계속 사용한다면 앱을 완전히 종료한 뒤 다시 열어 테스트합니다.
조회 단계 확인: 확인 가능한 진단 정보나 로그에서 같은 도메인의 쿼리, 응답 또는 시간 초과를 찾으세요. 캐시가 있으면 새 쿼리가 발생하지 않을 수 있으므로 이것만으로 실패라고 단정하지 마세요.
연결 단계 확인: 대상 IP를 확인했지만 연결 시도에서 시간 초과가 발생한다면 적용된 정책, 대상 포트, 기존 연결 항목의 사용 가능 여부를 계속 확인하세요.
반복 비교: 같은 조건에서 여러 번 접속해 첫 조회와 캐시 적중을 구분하세요. 우연히 한 번 성공한 결과를 장기적인 안정성의 근거로 삼지 마세요.

확인된 증상	우선 확인할 항목	다음 단계
조회 시간 초과, 응답 없음	리졸버 주소, 네트워크 연결 가능 여부, DoH 엔드포인트 경로	system으로 되돌려 비교한 다음 사용 가능성이 확인된 엔드포인트 하나만 따로 테스트하세요.
NXDOMAIN 응답	철자, 도메인 존재 여부, 내부 DNS 의존 여부	전체 도메인 이름을 확인하고 같은 네트워크의 기준 설정으로 다시 점검하세요.
IP는 반환됐지만 연결 시간 초과	규칙 정책, 대상 서비스, 실제 연결 경로	해당 연결의 정책 기록을 확인하고 DNS를 무작정 바꾸지 마세요.
Wi-Fi에서는 정상, 셀룰러에서는 실패	사설 DNS 주소를 입력했는지, 여러 네트워크에서 엔드포인트에 접속할 수 있는지	먼저 로컬 네트워크 전용 주소를 제외하고 셀룰러 네트워크에서 기준 결과를 다시 확인하세요.

요약: 단계별 증거에 따라 다음 조치 결정하기

DNS 응답이 확인되면 연결 정책과 대상 서비스를 중심으로 점검하세요. 쿼리 자체가 실패한 경우에만 리졸버, 엔드포인트 또는 아웃바운드 조건을 조정합니다. ‘접속할 수 없음’을 모두 DNS 문제로 간주하지 마세요.

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

dns-server를 수정했는데 왜 달라진 점이 없나요?

먼저 Config에서 현재 활성화된 설정을 수정했는지 확인한 뒤 저장하고, 설정을 다시 선택해 재연결하세요. 이후 테스트 앱을 종료했다가 다시 열어 접속합니다. 앱이 주소를 캐시하거나 자체적으로 DNS를 처리한다면 웹페이지 결과만으로 클라이언트 설정이 적용되지 않았다고 판단하기 어렵습니다. 쿼리 로그도 함께 확인하세요.

DoH를 설정하면 DNS 쿼리가 반드시 프록시를 거치나요?

반드시 그렇지는 않습니다. DoH는 쿼리에 HTTPS를 사용하도록 하지만 실제 아웃바운드 경로는 클라이언트의 DNS 처리 방식, 현재 모드, 관련 설정에 따라 달라집니다. 주소가 https로 시작한다는 이유만으로 판단하지 말고 엔드포인트 연결의 실제 경로를 확인하세요.

DNS를 바꾼 뒤 집에서 내부 도메인이 열리지 않는 이유는 무엇인가요?

외부 리졸버는 가정용 라우터나 회사 네트워크의 내부 레코드를 모르는 경우가 많습니다. system으로 되돌리고 기존 Wi-Fi에서 같은 전체 이름을 테스트하세요. 정상으로 돌아오면 내부 네트워크 요구사항에 맞춰 DNS를 설정하고 외부 리졸버가 모든 이름을 대체한다고 가정하지 마세요.

기존 구독을 업데이트했는데 DNS 문제가 해결되지 않는 이유는 무엇인가요?

연결 항목 구독과 Config의 dns-server는 서로 다른 설정입니다. Config로 돌아가 실제 활성화된 파일의 필드를 확인하세요. 원격 설정 파일을 업데이트했다면 로컬 변경 사항이 덮어써졌는지도 살펴보세요. 연결 목록을 반복 업데이트하는 것으로 DNS 확인을 대신할 수는 없습니다.

테스트 중 연결을 끊자마자 자동으로 다시 연결되면 어떻게 비교하나요?

Settings → On Demand에서 현재 조건을 확인하고 기록하세요. 필요한 경우 자동 연결을 잠시 비활성화한 뒤 테스트하고, 완료되면 원래 설정으로 복원합니다. On Demand는 연결을 시작하는 조건을 관리할 뿐 리졸버를 선택하지 않습니다. 비교하는 동안 연결 상태가 자동으로 바뀌지 않도록 하세요.