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

이 글의 핵심

먼저 시스템 DNS를 기준으로 삼고, DNS 상위 서버를 고정해야 할 때 사용자 지정 DNS를 설정하세요. DNS 쿼리를 해석 서비스까지 암호화해 전송하려면 DNS over HTTPS를 고려할 수 있습니다. 사용할 수 있는 서비스 설정이 있고 도메인이 열리지 않거나 네트워크 변경 후 이름 확인에 문제가 생긴 경우를 대상으로, 세 방식의 차이와 dns-server 입력 방법, 문제 원인이 DNS 확인 단계인지 연결 단계인지 구분하는 방법을 설명합니다.

DNS는 이름을 확인할 뿐, 연결 경로를 정하지 않습니다

Shadowrocket의 DNS 설정은 주로 도메인 이름을 IP 주소로 확인하는 방식을 정합니다. Home의 Global Routing과는 별개로, DNS는 이름 확인에 영향을 주고 Global Routing은 연결에 적용할 경로를 결정합니다. 웹페이지가 열리지 않으면 주소를 얻지 못한 것인지, 주소를 얻은 뒤 연결에 실패한 것인지 먼저 구분하세요. DNS, 규칙, 서버 설정을 한꺼번에 바꾸지 마세요.

도메인 조회 DNS 상위 서버 주소 반환 연결 경로 결정 대상에 접속

이 흐름은 로컬에서 DNS 확인이 필요한 일반적인 접속 과정을 설명하며, 모든 연결이 항상 같은 단계를 거친다는 뜻은 아닙니다. 앱이 캐시를 재사용하거나 자체적으로 암호화 DNS를 사용할 수 있고, 일부 프록시 연결은 대상 도메인의 확인을 원격 서버에 맡길 수 있습니다. 따라서 dns-server를 바꾼 뒤 기기의 모든 DNS 조회가 즉시 새 설정을 사용하리라고 기대해서는 안 됩니다.

DNS 확인 성공: 사용 가능한 A 또는 AAAA 레코드를 받았다는 뜻일 뿐, 대상 포트에 연결할 수 있다는 의미는 아닙니다.
연결 성공: 라우팅 정책, 서버 설정, 대상 서비스, 현재 네트워크도 모두 정상이어야 합니다.
페이지 표시 성공: 여러 리소스 도메인에 의존할 수 있습니다. 기본 도메인이 확인되더라도 이미지, 로그인, API 도메인까지 정상이라는 보장은 없습니다.

시스템 DNS, 사용자 지정 DNS, DoH의 차이

시스템 DNS는 현재 시스템 네트워크에서 제공하는 해석기를 사용하며, 보통 Wi-Fi 또는 셀룰러 네트워크 설정을 따릅니다. 사용자 지정 DNS는 사용할 상위 서버를 직접 지정하는 방식입니다. 일반 IP 주소만 입력하면 대개 기존 DNS 전송 방식을 사용합니다. DNS over HTTPS(DoH)는 HTTPS를 통해 DNS 메시지를 해석 엔드포인트와 주고받습니다. 세 방식은 완전히 배타적인 분류가 아닙니다. DoH도 DNS 상위 서버를 직접 지정하는 방법 중 하나입니다.

세 가지 DNS 설정 방식 비교
설정 방식	상위 서버와 전송 방식	먼저 확인해 볼 상황	유의 사항
시스템 DNS	시스템에서 제공하는 해석기를 사용합니다. 전송 방식은 시스템 네트워크 설정에 따라 달라집니다.	문제 비교의 기준을 마련하거나 로컬 네트워크 및 조직 내부 도메인에 접속할 때	Wi-Fi와 셀룰러 네트워크를 전환하면 상위 서버와 결과가 달라질 수 있습니다.
사용자 지정 일반 DNS	지정한 DNS 서버의 IP를 입력합니다. 보통 UDP 53으로 조회하고, 필요한 경우 TCP 53을 사용합니다.	문제가 현재 네트워크의 DNS 서버와 관련 있는지 확인할 때	IP 주소만 바꿔도 DNS 쿼리가 자동으로 암호화되지는 않습니다.
DNS over HTTPS	전체 HTTPS 엔드포인트 주소를 입력합니다. 일반적으로 TCP 443을 사용합니다.	클라이언트와 DNS 엔드포인트 사이의 쿼리 전송을 암호화해야 할 때	엔드포인트 연결 상태, 인증서 검증, 엔드포인트 도메인의 초기 DNS 확인이 모두 사용 가능 여부에 영향을 줄 수 있습니다.

요약: 도메인은 하나씩 바꿔 가며 비교하세요

네트워크, Global Routing, 기본 서버는 그대로 두고 DNS 설정만 바꾸세요. 결과가 반복해서 확인된 뒤에 변경 사항을 유지하세요. 여러 항목을 한꺼번에 바꾸면 웹페이지가 다시 열리더라도 어떤 설정이 영향을 줬는지 알 수 없습니다.

DoH는 DNS 쿼리가 해석 서비스까지 전송되는 구간을 암호화할 뿐, 전체 접속 과정을 암호화하지는 않습니다. 해석 서비스는 쿼리를 처리해야 하고, 웹사이트 연결은 해당 라우팅에 따라 이루어집니다. DoH를 사용한다고 해서 모든 DNS가 프록시를 통과하거나 접속 경로가 바뀌는 것은 아닙니다.

Config의 [General]에서 dns-server 설정하기

먼저 Config에서 현재 선택된 설정 파일을 확인하고, 기존 내용을 백업한 뒤 해당 파일의 텍스트 편집 화면을 여세요. 아래 코드 블록 세 개는 각각 별도의 예시이므로 한꺼번에 붙여 넣으면 안 됩니다. 파일에 [General]이 이미 있다면 같은 설정을 중복으로 추가하지 말고 기존 섹션의 dns-server를 수정하세요.

Home에서 현재 선택된 Global Routing 옵션과 서버를 기록해 두어 비교 조건을 유지하세요.
Config에서 현재 사용하는 파일을 열고 [General]과 기존 dns-server 항목을 찾으세요.
이 항목만 바꾸고 저장한 뒤 해당 파일이 계속 선택되어 있는지 확인하세요. 확인하기 쉽도록 연결을 끊었다가 다시 연결해도 됩니다.
대상 도메인에 다시 요청을 보내 결과를 확인하세요. 기존 연결과 캐시가 이전 결과를 계속 사용할 수 있으므로 페이지를 한 번 새로 고친 것만으로 결론을 내리지 마세요.

시스템 해석기 사용

[General]
dns-server = system

system은 설정값이지, 바꿔야 하는 도메인 이름이 아닙니다. 문제 해결을 위한 기준으로 적합하며, 특히 네트워크에 내부 도메인, 라우터 이름, 조직 전용 DNS 레코드가 있을 때 유용합니다. 공개 DNS 서버는 이런 레코드를 모를 수 있으므로 공개 DNS로 바꾸면 내부 서비스에 접속할 수 없게 될 수도 있습니다.

일반 DNS 주소 지정

[General]
dns-server = 1.1.1.1

여기서 1.1.1.1은 공개 DNS 서버의 입력 형식을 보여 주는 예시일 뿐, 모든 네트워크에서 더 빠르다는 뜻은 아닙니다. 상위 서버를 여러 개 지정할 때는 영문 쉼표로 구분할 수 있지만, 나열 순서가 확실한 주 서버·보조 서버 전환을 보장한다고 해석해서는 안 됩니다. 문제를 확인할 때는 먼저 상위 서버 하나만 설정해야 연결 여부와 응답을 파악하기 쉽습니다.

DNS over HTTPS 엔드포인트 지정

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

DoH 값에는 https://, 호스트 이름, 서비스에서 요구하는 경로가 모두 포함되어야 합니다. 일반 웹사이트의 첫 페이지 주소는 DNS 엔드포인트를 대신할 수 없습니다. 아래 예시는 형식 설명용이므로 실제로 입력하기 전에 DNS 서비스에서 안내하는 엔드포인트인지 확인하세요. 호스트 이름을 임의로 IP 주소로 바꾸지 마세요. 인증서의 신원 확인, 서비스 라우팅, 엔드포인트 지원 여부에 따라 대체할 수 없을 수 있습니다.

포트와 설정값으로 입력 상태 확인하기

기존 DNS의 표준 포트. UDP 또는 TCP 사용

443

HTTPS 기본 포트. DoH는 보통 이 포트를 사용

2가지

주요 주소 레코드: A는 IPv4, AAAA는 IPv6

포트 번호는 전송 방식을 구분하는 값이지 속도 순위가 아닙니다. 일반 DNS의 53번 포트에 접속할 수 있어도 DoH 엔드포인트의 HTTPS 연결이 정상이라는 보장은 없습니다. 일반 HTTPS 웹페이지가 열려도 지정한 DoH 서비스가 사용 가능하다는 뜻은 아닙니다. 임의의 웹사이트 연결 상태가 아니라 실제 사용할 DNS 서버를 테스트하세요.

시스템 DNS 기준값

설정 섹션: [General]
설정 이름: dns-server
설정값: system
확인할 항목: 같은 네트워크에서 공개 도메인과 내부 도메인이 모두 확인되는지

먼저 기준 상태를 기록한 뒤 DNS 상위 서버를 바꾸세요.

DoH 엔드포인트 확인

프로토콜 접두사: https://
예시 호스트 이름: cloudflare-dns.com
예시 경로: /dns-query
확인할 항목: 엔드포인트의 초기 DNS 확인, HTTPS 연결, 인증서 검증이 정상인지

프로토콜 접두사만 확인하지 말고 엔드포인트 주소를 항목별로 점검하세요.

도메인에서 AAAA 레코드를 받은 뒤 접속이 불안정하다면 DNS가 잘못된 주소를 반환했다고 바로 단정하지 말고 IPv6 경로를 추가로 확인하세요. 해석기가 주소를 반환하는 것과 현재 네트워크에서 해당 주소에 연결할 수 있는 것은 별개의 조건입니다. 브라우저에서 IP 주소로 직접 접속하는 것만으로 판단해서도 안 됩니다. HTTPS 사이트는 인증서 확인과 가상 호스트 선택에 도메인 이름이 필요할 수 있습니다.

DNS와 Global Routing·규칙의 관계

Home의 Global Routing에서 Config는 현재 설정의 규칙에 따라 연결을 판단합니다. Proxy와 Direct는 각각 프록시와 직접 연결 방식을 선택하며, Scene은 설정된 장면을 선택하는 기능입니다. DNS 문제를 확인할 때는 현재 선택된 항목을 기록하세요. 라우팅 방식을 바꾼 뒤 나타난 차이를 모두 DNS 서버 탓으로 돌리면 안 됩니다.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,DIRECT

DOMAIN-SUFFIX,example.com,PROXY: 도메인 접미사로 일치 여부를 판단합니다. 예시에서는 해당 도메인과 하위 도메인에 PROXY 정책을 적용합니다.
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve: 지정한 IPv4 대역을 기준으로 일치 여부를 판단합니다. no-resolve는 이 IP 규칙을 위해 별도의 도메인 확인을 실행하지 않는다는 뜻입니다.
FINAL,DIRECT: 앞선 규칙에 일치하지 않을 때 적용하는 기본 정책입니다. 배치 위치에 따라 이후 규칙의 판단 여부가 달라집니다.

이 예시는 규칙 간의 관계를 설명하기 위한 일부 내용이며, 완성된 설정 파일도 기존 규칙을 덮어쓰라는 뜻도 아닙니다. GEOIP와 IP-CIDR는 IP 주소를 기준으로 판단하므로 DNS에서 확인한 IP가 관련될 수 있습니다. DOMAIN-SUFFIX는 도메인을 기준으로 합니다. 연결 경로를 분석할 때는 일치한 규칙과 최종 정책을 함께 확인해야 하며, DNS가 반환한 주소만 봐서는 안 됩니다.

도메인이 열리지 않을 때 점검할 순서

먼저 이전에 접속할 수 있었던 도메인 하나를 정하고, 문제가 Wi-Fi에서만 발생하는지, 셀룰러 네트워크에서만 발생하는지, 아니면 두 네트워크 모두에서 발생하는지 기록하세요. 아래 내용은 관찰 결과에 따라 확인할 항목을 안내하는 것이며, 이 페이지에서 직접 테스트한 결과가 아닙니다. 설정을 바꿀 때마다 요청을 다시 보내 시간, 네트워크, 결과를 기록하고 조건이 다른 결과끼리 비교하지 마세요.

DNS 문제 증상과 다음 점검 항목
관찰된 증상	우선 확인할 항목	확인 방법
DoH로 바꾼 뒤 여러 도메인을 확인할 수 없음	엔드포인트 입력 오류, 엔드포인트 도메인의 초기 DNS 확인, HTTPS 연결 가능 여부	system으로 되돌려 비교하세요. 정상으로 돌아오면 규칙 전체를 다시 작성하지 말고 DoH 엔드포인트를 집중적으로 확인하세요.
공개 웹사이트는 정상인데 내부 도메인에 접속할 수 없음	내부 레코드가 없는 공개 DNS 서버로 바뀌었는지	기존 네트워크에서 시스템 DNS로 되돌린 뒤 같은 내부 도메인을 다시 테스트하세요.
주소는 받았지만 연결 시간 초과	적용된 정책, 서버 연결 상태, 대상 포트, IPv6 경로	연결 기록에서 정책과 대상을 먼저 확인하고, DNS 서버를 무작정 계속 바꾸지 마세요.
설정을 바꿔도 일부 앱의 동작이 그대로임	캐시, 기존 연결, 앱 자체의 DNS 처리 방식	관련 요청을 종료한 뒤 다시 시도하세요. 이미 열린 페이지만 보지 말고 새 요청의 결과를 비교해야 합니다.

Connectivity Test는 서버 연결 상태를 확인하는 데 도움이 되지만, 모든 서비스 도메인이 올바르게 확인된다는 것을 단독으로 증명하지는 않습니다. 반대로 DNS 조회가 한 번 성공해도 선택한 서버와 대상 웹사이트에 접속할 수 있다는 뜻은 아닙니다. DNS 결과, 연결 테스트, 실제 페이지 요청을 각각 따로 기록하세요.

요약: 오류가 발생한 단계를 찾은 뒤 해당 설정을 변경하세요

주소를 얻지 못했다면 DNS 서버와 엔드포인트를 확인하세요. 주소는 있지만 연결되지 않으면 라우팅과 연결 경로를 점검하세요. 특정 앱에서만 문제가 발생하면 해당 앱의 캐시와 DNS 처리 방식을 확인하세요. 기존 설정을 보관하고, 검증에 실패하면 되돌리세요. 확인되지 않은 변경을 연달아 추가하지 마세요.

사용 환경에 맞춰 최종 설정 유지하기

내부 서비스에 주로 접속하는 경우: 먼저 시스템 DNS를 사용해 조직 네트워크의 DNS 응답을 확인하세요. 내부 도메인에 영향을 주는 설정 변경은 해당 네트워크의 설정 지침을 따르세요.
공개 DNS 서버를 고정해야 하는 경우: 현재 네트워크에서 실제로 연결할 수 있는 DNS 서비스를 선택하세요. 먼저 주소 하나로 확인한 뒤 상위 서버를 여러 개 사용할지 결정하세요.
DNS 전송을 암호화해야 하는 경우: DNS 서비스에서 제공하는 전체 DoH 엔드포인트를 사용하고, 주로 사용하는 Wi-Fi와 셀룰러 네트워크에서 각각 확인하세요.
설정 파일이 정기적으로 업데이트되는 경우: 업데이트 전후에 [General]의 설정을 확인하세요. 파일 업데이트로 로컬 변경 사항이 덮어써질 수 있으므로, 이전에 설정했다는 이유만으로 현재도 적용 중이라고 단정하지 마세요.

최종 설정은 작동 이유를 설명할 수 있고, 같은 결과를 재현할 수 있으며, 쉽게 되돌릴 수 있어야 합니다. DNS 상위 서버가 많다고 더 좋은 설정은 아닙니다. 이 글은 사용자가 자신의 서비스 설정을 이미 보유하고 있다는 전제에서 작성했으며, 서비스 구독을 제공하거나 추천하지 않습니다. 설정 파일과 연결 확인 방법은 전체 매뉴얼 또는 사용 가이드에서 확인하세요.