Shadowrocket DNS 설정 가이드: 시스템 DNS, 사용자 지정 DNS, DNS over HTTPS

이 글 미리보기

이 글은 Shadowrocket 연결 설정을 마친 뒤 도메인 이름 확인 방식을 조정하려는 사용자를 위한 안내입니다. 먼저 DNS 서버, DNS 전송 방식, 요청의 아웃바운드 정책을 구분한 다음 Config의 최소 설정으로 하나씩 확인합니다. 시스템 DNS는 기준 설정으로, 사용자 지정 DNS는 특정 리졸버를 지정할 때, DNS over HTTPS는 클라이언트와 리졸버 간 질의를 암호화할 때 사용할 수 있습니다. 어떤 방식을 쓰든 현재 네트워크와 규칙, 실제 조회 결과를 함께 확인해야 합니다.

1. DNS 조회와 연결 아웃바운드 구분하기

Shadowrocket의 DNS 설정은 ‘도메인에 어떤 주소가 연결되는지’를 결정하고, Global Routing과 규칙은 ‘연결을 어떤 경로로 내보낼지’를 결정합니다. 웹 페이지가 열리지 않는 원인은 두 단계 중 하나일 수도 있고 대상 서비스 자체의 문제일 수도 있습니다. DNS만 바꿔서는 서버 포트에 연결되지 않거나 인증에 실패하거나 대상 웹사이트에서 접속을 거부하는 문제를 해결할 수 없습니다.

아래는 로컬에서 DNS 조회가 필요한 경우를 단순화해 나타낸 경로입니다. 실제 처리에서는 도메인 규칙이 주소 규칙보다 먼저 적용될 수 있습니다. 일부 프록시 요청은 도메인 처리를 원격으로 넘기기도 하므로 모든 연결이 동일한 로컬 DNS 경로를 거치는 것은 아닙니다.

도메인 요청 리졸버 선택 주소 반환 정책 판단 연결 수립

앱 자체의 조회 방식도 확인해야 합니다. 브라우저나 다른 앱이 별도의 암호화 DNS를 사용할 수 있으며, 기존 연결이나 캐시에서 이전 주소를 재사용할 수도 있습니다. Config에 리졸버를 지정했다고 해서 기기의 모든 앱이 매번 그 리졸버를 통해 조회하는 것은 아닙니다. 문제를 확인할 때는 같은 앱, 도메인, 네트워크를 사용해 서로 다른 요청을 섞지 않도록 하세요.

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

시스템 DNS는 일반적으로 현재 네트워크에서 제공하는 DNS 설정을 따르므로 Wi-Fi나 셀룰러 네트워크를 바꾸면 실제 리졸버도 달라질 수 있습니다. 사용자 지정 DNS는 설정에서 리졸버 주소를 직접 지정합니다. ‘사용자 지정’은 선택 방식을 뜻할 뿐, 전송이 암호화되었다는 의미는 아닙니다. DNS over HTTPS(DoH)는 DNS 질의를 HTTPS로 전송하는 방식이며, 이 또한 리졸버를 직접 지정해 사용할 수 있습니다.

설정 방식	리졸버 출처	전송 특성	우선 확인할 상황
시스템 DNS	현재 시스템 및 네트워크 설정	이름만으로 암호화 여부를 판단할 수 없음	네트워크 로그인 페이지, 가정용 네트워크, 내부 도메인
사용자 지정 일반 DNS	설정에서 지정한 IP 주소	대개 UDP 53을 사용하며 TCP 53을 사용할 수도 있음	리졸버를 고정해 조회 결과를 비교할 때
DNS over HTTPS	설정에서 지정한 HTTPS 엔드포인트	주로 443 포트를 사용하며 TLS 연결 필요	DNS 질의를 암호화해야 하고 엔드포인트에 연결할 수 있을 때

일반 DNS의 표준 포트로, 주로 UDP를 사용하며 TCP도 가능

443

HTTPS 기본 포트이며 DoH 엔드포인트도 주로 사용

2가지

일반적인 주소 레코드: A는 IPv4, AAAA는 IPv6에 해당

요약: 기준 설정을 먼저 확인한 뒤 DoH를 고려하세요

먼저 시스템 DNS로 대상 도메인이 조회되는지 확인한 다음, 한 번에 한 가지 방식만 바꿔 다시 테스트하세요. 일반 DNS는 작동하지만 DoH가 시간 초과된다면 규칙과 연결 설정을 동시에 바꾸지 말고 DoH 엔드포인트에 HTTPS로 연결할 수 있는지부터 확인하세요.

DoH는 선택한 리졸버까지의 질의 전송을 암호화하지만, 리졸버는 여전히 질의 내용을 처리해야 합니다. 반환되는 주소가 더 빠르다거나 내부 도메인을 조회할 수 있다고 보장하지는 않습니다. 리졸버가 반환한 주소, 대상 서비스의 지역별 트래픽 분산, 네트워크 경로가 최종 접속에 영향을 줄 수 있습니다.

3. Config에서 DNS 설정하기: 백업 후 한 항목씩 변경

작업 전, 사용 중인 서비스 제공업체와 구독 정보를 직접 확보했고 기본 연결 테스트를 마쳤는지 확인하세요. Subscribe로 가져오거나 업데이트하는 것은 기존 연결 정보이며, DNS 설정이 완료되었다는 뜻은 아닙니다. 이 글에서는 현재 Config의 조회 설정만 변경하며, 서비스 출처 선택은 다루지 않습니다.

Config로 이동해 실제 사용 중인 구성 파일을 확인하고 사본을 저장하세요. 활성화되지 않은 파일만 수정하지 않도록 주의하세요.
해당 구성의 편집 화면을 열어 [General] 섹션과 dns-server 항목을 찾으세요. 편집 메뉴의 문구나 아이콘은 인터페이스에 따라 다를 수 있으니 현재 표시되는 항목을 기준으로 하세요.
이미 dns-server 항목이 있다면 기존 항목을 수정하세요. 파일 끝에 같은 설정을 여러 번 추가하지 마세요.
저장한 뒤 해당 구성이 계속 선택되어 있는지 확인하세요. Home으로 돌아가 연결을 끊어도 되는 상황에서 다시 연결한 다음, 같은 도메인을 테스트하세요.
변경 전후의 조회 결과와 오류 메시지를 기록해 두세요. 개선되지 않으면 사본으로 되돌린 뒤 다음 항목을 테스트하세요.

아래 세 가지는 서로 함께 사용할 수 없는 최소 예시입니다. 매번 하나만 골라 현재 설정의 해당 항목을 바꾸세요. 완성된 구성 파일이 아니므로 기존 규칙과 연결 정보를 덮어쓰면 안 됩니다. 예시의 공개 리졸버는 설정 문법을 보여 주기 위한 것이며, 사용할지는 접속 가능 여부와 서비스 정책을 확인해 판단하세요.

방법 A: 시스템 DNS 사용

[General]
dns-server = system

system은 시스템 DNS를 사용한다는 뜻입니다. 기준 설정을 잡거나 로컬 리졸버에 의존하는 환경에서 유용합니다. 연결하지 않았을 때 내부 도메인이 조회되지만 공개 DNS로 바꾸면 조회되지 않는다면, 해당 도메인을 로컬 네트워크의 리졸버만 알고 있는지 먼저 확인하세요.

방법 B: 일반 DNS를 직접 지정

[General]
dns-server = 1.1.1.1

여기서는 변수를 분리하기 위해 리졸버 하나만 지정합니다. 일반 DNS 주소 앞에 https://를 붙이지 말고, 웹 페이지 주소를 일반 서버 주소 입력란에 넣지도 마세요. 현재 네트워크에서 외부 DNS를 제한하면 IP를 지정해도 시간 초과가 발생할 수 있습니다. 이때는 주소를 더 추가하기보다 시스템 DNS로 되돌려 확인하세요.

방법 C: DNS over HTTPS 지정

[General]
dns-server = https://1.1.1.1/dns-query

DoH에는 프로토콜, 호스트, 경로가 모두 포함된 전체 엔드포인트가 필요합니다. DNS 서비스의 홈페이지 주소만 입력한다고 DoH 주소가 되는 것은 아닙니다. 이 예시는 해당 IP 주소에 대한 인증서를 지원하는 엔드포인트를 사용합니다. 다른 도메인 엔드포인트를 임의로 IP 주소로 바꾸면 인증서 검증에 실패할 수 있습니다.

4. DNS와 Global Routing 및 규칙 연동하기

Home에서 Global Routing을 확인하세요. Config는 현재 구성의 규칙에 따라 연결을 처리하고, Proxy와 Direct는 각각 프록시 또는 직결 방식을 사용합니다. Scene은 설정된 장면에 따라 동작 방식을 선택합니다. 규칙 문제를 확인할 때는 먼저 동작 방식을 고정하세요. Proxy나 Direct에 고정한 채 Config의 분기 규칙으로 접속 결과를 설명하면 잘못 판단하기 쉽습니다.

DNS 설정 확인

위치: Config → 현재 구성 → 편집
구성 섹션: [General]
설정 항목: dns-server
확인 조건: 저장한 뒤 구성을 선택하고 다시 연결

활성화되지 않은 구성을 수정해도 현재 세션의 DNS 설정은 바뀌지 않습니다.

규칙 키워드 확인

DOMAIN-SUFFIX: 도메인 접미사로 일치
IP-CIDR: IPv4 주소 범위로 일치
GEOIP: IP 지리 데이터베이스로 일치
FINAL: 앞선 규칙이 모두 일치하지 않을 때 적용되는 최종 규칙

규칙은 순서대로 확인하며 주소 기반 규칙에는 조회 결과가 영향을 줄 수 있습니다.

아래는 규칙 문법 예시일 뿐, 완성된 구성을 대신할 수 없습니다. 192.0.2.0/24는 문서용 예시 네트워크 대역이며 접속할 서비스 주소가 아닙니다. DOMAIN-SUFFIX는 도메인으로 일치 여부를 판단합니다. 주소 기반 규칙은 확인된 대상 IP를 바탕으로 적용해야 합니다. no-resolve를 추가하면 해당 주소 규칙을 위해 도메인 조회를 새로 시작하지 않는다는 뜻이지, 연결 전체에서 DNS를 사용하지 못하게 한다는 뜻은 아닙니다.

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

DNS가 주소를 반환해도 이후 연결이 예상한 경로로 나간다는 보장은 없습니다. 조회 결과와 규칙 일치 기록을 각각 확인하세요. 도메인이 앞선 규칙에 이미 일치했다면 뒤쪽의 GEOIP나 FINAL을 수정해도 이번 적용 결과는 달라지지 않습니다. Global Routing이라는 이름만 보고 DNS 질의 자체의 아웃바운드 경로를 추측하지 마세요. 실제 경로는 현재 DNS 관련 설정과 기록에 따라 달라집니다.

5. DNS 오류 점검 순서

Connectivity Test는 선택한 연결의 테스트 결과를 보여 주지만, 특정 웹사이트의 DNS, TLS, 서비스 접속까지 모두 검증하지는 않습니다. 테스트가 정상인데 웹 페이지가 열리지 않는다면 ‘주소를 받지 못함’과 ‘주소를 받은 뒤 연결 실패’를 나눠 확인하세요. 아래 단계는 근거 없는 속도 수치에 의존하지 않으며, 매 단계에서 재현 가능한 현상을 기록해야 합니다.

네트워크와 테스트 대상을 고정하세요. Wi-Fi 또는 셀룰러 네트워크, 대상 도메인, 현재 Config, Global Routing을 기록하세요. 실제로 실패하는 도메인을 먼저 선택하고, 정상 작동이 확인된 도메인 하나를 비교 대상으로 추가하세요.
설정이 적용됐는지 확인하세요. 저장 후 다시 연결하고 방금 수정한 파일을 계속 사용 중인지 확인하세요. 원격 업데이트가 설정을 덮어쓸 수 있다면 사본으로 테스트하고, 업데이트 후 다시 확인하세요.
오류가 발생한 단계를 구분하세요. 주소를 받지 못함, 조회 시간 초과, 존재하지 않는다는 응답은 주소를 받은 뒤 연결이 시간 초과되는 경우와 서로 다른 문제입니다. 확인 가능한 연결 기록이나 대상 앱의 오류 메시지를 참고하세요. 웹 페이지가 열리지 않는다는 이유만으로 DNS 오류라고 단정할 수 없습니다.
비교를 위해 시스템 DNS로 되돌리세요. 되돌린 직후 작동하고 지정한 리졸버에서는 계속 실패한다면, 현재 네트워크에서 해당 리졸버에 연결할 수 있는지와 내부 도메인 조회가 필요한지 확인하세요.
DoH 조건을 별도로 테스트하세요. 엔드포인트 주소, HTTPS 경로, 기기 시간, 인증서 오류를 확인하세요. 일반 HTTPS 웹사이트가 열린다고 해서 특정 DoH 엔드포인트에도 반드시 연결할 수 있는 것은 아닙니다.
A와 AAAA 레코드를 확인하세요. 주소를 받았는데도 접속에 실패한다면 한쪽 주소 체계에서만 문제가 발생하는지 확인하세요. IPv6 경로 문제를 곧바로 리졸버 오류로 단정하거나 IPv6 관련 설정을 일괄 삭제하지 마세요.
마지막으로 캐시와 자동 연결을 확인하세요. 연결을 다시 수립하고 대상 앱도 다시 여세요. 테스트 중 자동 재연결로 연결 상태가 바뀌지 않도록 Settings → On Demand도 확인하세요. 캐시 삭제를 앞선 확인 절차를 대신하는 만능 해결책으로 여기지 마세요.

요약: 주소를 받았다면 연결과 규칙을 확인하세요

같은 대상에서 A 또는 AAAA 레코드가 안정적으로 반환되는데 연결 단계에서 시간 초과가 발생한다면 규칙 적용 기록, 선택한 연결, 대상 서비스 포트를 확인하세요. 이 경우 리졸버를 계속 바꿔도 실제 실패 지점을 찾기 어렵습니다.

6. 자주 묻는 질문: 설정 후에도 문제가 계속될 때

DoH로 바꾼 뒤 웹 페이지를 처음 열 때 더 느린 이유는 무엇인가요?

DoH 연결에는 엔드포인트의 초기 조회, TLS 연결, DNS 질의 과정이 포함될 수 있습니다. 같은 네트워크에서 같은 도메인을 연속으로 테스트해 첫 연결과 이후 연결의 차이를 확인하세요. 매번 오래 기다려야 한다면 시스템 DNS로 되돌려 비교하고 엔드포인트에 연결할 수 있는지 확인하세요. 한 번의 로딩 속도만으로 결론 내리지 마세요.

공개 웹사이트는 열리는데 집 안의 내부 도메인은 열리지 않으면 어떻게 하나요?

먼저 dns-server를 system으로 되돌리고 기존 가정용 Wi-Fi에서 다시 테스트하세요. 복구 후 작동한다면 내부 이름 확인에 로컬 리졸버가 필요할 수 있습니다. 공개 도메인과 내부 도메인 모두 조회해야 한다면 현재 네트워크 설계에 맞춰 도메인별 조회 정책을 설정하세요. 공개 리졸버가 사설 네트워크의 이름을 알고 있을 것이라고 기대하지 마세요.

DNS를 여러 개 입력하면 반드시 순서대로 대체 사용되나요?

주소를 적은 순서만 보고 엄격한 기본·보조 동작을 예상하지 마세요. 질의 선택과 대체 동작은 실제 구현과 설정에 따라 달라집니다. 문제를 확인할 때는 연결할 수 있는 것으로 확인된 리졸버 하나만 남기고 저장한 다음 다시 연결하세요. 하나씩 검증한 후 현재 설정에서 지원하는 방식에 따라 다른 리졸버를 추가하세요.

Subscribe 업데이트는 성공했는데 DNS 설정은 왜 바뀌지 않나요?

연결 정보의 Subscribe 업데이트와 현재 Config의 DNS 항목은 서로 다른 확인 지점입니다. Config로 돌아가 선택된 파일을 확인한 다음 [General]의 dns-server 항목을 살펴보세요. 원격 구성 파일을 업데이트했다면 원격 내용이 로컬 변경 사항을 덮어썼는지도 확인해야 합니다.

재현 가능한 결과를 얻었다면 사용한 네트워크, Config 이름, Global Routing 방식, DNS 설정값, 대상 도메인, 오류 발생 단계를 기록해 두세요. 기록을 공유하기 전에는 구독 주소, 인증 정보, 개인 도메인을 삭제하세요. 여러 옵션을 한꺼번에 바꾸기보다 하나씩 테스트하고 작동하는 기준 설정으로 되돌릴 수 있게 관리해야 문제 발생 지점을 쉽게 파악할 수 있습니다.