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

이 글 미리보기

Shadowrocket의 DNS 설정은 먼저 정상 작동하는 기준 상태를 유지한 뒤 필요에 따라 변경하는 것이 좋습니다. 시스템 DNS는 현재 네트워크의 도메인 조회 상태를 확인할 때, 사용자 지정 DNS는 조회 서버를 직접 지정할 때, DNS over HTTPS는 지정한 DNS 서비스까지의 조회 전송을 암호화할 때 적합합니다. 이미 이용 중인 서비스와 구독이 있다는 전제하에 설정 파일에서 dns-server를 찾는 위치, 세 가지 설정 방식, 단계별 확인 순서를 안내합니다. DNS 설정은 서버 연결 점검을 대신하지 않으며 웹 트래픽의 경로를 자동으로 결정하지도 않습니다.

1. 도메인 조회와 연결 라우팅 구분하기

DNS는 도메인 조회 결과를 연결에 사용할 주소 정보로 바꿉니다. 예를 들어 www.example.com에 접속할 때 앱은 A 또는 AAAA 레코드를 조회한 뒤, 응답으로 받은 IPv4 또는 IPv6 주소에 연결할 수 있습니다. 조회에 성공했다는 것은 응답을 받았다는 뜻일 뿐, 대상 포트에 접속할 수 있거나 TLS 핸드셰이크가 성공하거나 웹 페이지가 완전히 로드된다는 뜻은 아닙니다.

앱 요청 도메인 조회 주소 확인 연결 라우팅 대상 응답

이 과정은 문제를 점검하는 단계를 구분하기 위한 것으로, 모든 연결이 내부적으로 같은 순서로 처리된다는 뜻은 아닙니다. 도메인 규칙이 적용되면 클라이언트가 도메인만으로 정책을 결정할 수 있고, 원격에서 도메인을 처리하는 연결은 로컬에서 대상 주소를 먼저 조회하지 않을 수도 있습니다. 앱 자체에서 사용하는 암호화 DNS, 기존 캐시, 설정의 다른 DNS 옵션도 실제로 관찰되는 과정에 영향을 줍니다.

Global Routing과 DNS는 서로 다른 설정입니다. Proxy, Direct, Config, Scene은 트래픽 처리 방식을 선택하고, dns-server는 조회 출처를 지정합니다. DNS 서버 주소를 입력해도 모든 연결이 Proxy로 바뀌는 것은 아니며, 조회가 현재 선택한 프록시 서버를 통해 전송된다는 보장도 없습니다.

2. 세 가지 DNS 설정 방식의 차이

설정 파일의 [General]에서 dns-server에는 시스템 DNS, 지정한 DNS 서버 주소 또는 지원되는 암호화 DNS 주소를 사용할 수 있습니다. 아래 내용은 설정 방식의 비교이며 속도 순위가 아닙니다. 실제 응답 시간은 네트워크 상태, DNS 서비스 연결 가능 여부, 캐시 및 응답 결과에 따라 달라지므로 사용 중인 네트워크에서 확인해야 합니다.

방식	예시 값	적합한 경우	유의 사항
시스템 DNS	`system`	현재 네트워크의 DNS 기능을 먼저 확인하거나 로컬 네트워크의 내부 이름에 접속할 때	Wi-Fi와 셀룰러 네트워크를 전환하면 DNS 출처가 달라질 수 있습니다.
사용자 지정 DNS	`1.1.1.1`	연결 가능 여부를 확인한 DNS 서버를 지정해야 할 때	일반 DNS 조회는 전송을 암호화하지 않습니다.
DNS over HTTPS	`https://cloudflare-dns.com/dns-query`	클라이언트와 지정한 DNS 서비스 사이의 조회 전송을 암호화해야 할 때	엔드포인트 연결 가능 여부, TLS 검증, 엔드포인트 도메인의 초기 조회가 필요합니다.

표에 나온 공용 DNS 주소는 문법을 설명하기 위한 예시이며 모든 네트워크에 적합하다는 뜻은 아닙니다. 회사나 가정의 내부 이름은 내부 DNS에만 등록되어 있을 수 있습니다. 공용 DNS로 바꾸면 일반 웹사이트는 열리더라도 내부 이름은 조회되지 않을 수 있습니다. 이는 조회 범위가 달라진 것이므로 공용 웹사이트가 열린다는 이유만으로 설정 전체가 올바르다고 판단할 수는 없습니다.

일반 DNS에서 흔히 사용하는 서버 포트입니다. 기존 조회는 대개 UDP를 사용하지만 TCP를 사용할 수도 있습니다.

443

HTTPS 기본 포트입니다. DoH 엔드포인트는 보통 이 포트에서 조회를 받습니다.

판단 기준: 확인 가능한 DNS 출처를 먼저 선택한 뒤 암호화 전송을 검토하세요

현재 DNS 조회가 정상이라면 먼저 기준 상태를 기록하세요. DoH를 선택할 경우 엔드포인트 연결과 인증서 검증이 정상인지 확인한 다음 대상 도메인을 테스트하세요. 주소가 https로 시작한다는 이유만으로 서버 연결과 규칙 점검을 생략하지 마세요.

3. 현재 설정에서 dns-server 변경하기

변경하기 전에 Home → Global Routing에서 현재 처리 방식을 확인하고 Config에서 사용 중인 설정 파일을 확인하세요. 여러 파일을 저장해 둔 경우 활성화되지 않은 파일만 수정하면 원하는 결과가 나오지 않습니다. 혼동을 피하려면 현재 설정을 복사하거나 백업하고 기존 dns-server 값을 기록한 다음 해당 파일의 편집 화면으로 이동하세요.

Config에서 현재 사용 중인 설정 파일을 찾아 편집 화면을 여세요. 구체적인 버튼 이름은 앱에 표시되는 내용을 기준으로 확인하세요.
[General] 섹션과 기존 dns-server 항목을 찾으세요. 항목이 이미 있으면 값을 바꾸고, 파일 끝에 같은 설정을 반복해서 추가하지 마세요.
아래 세 가지 예시 중 하나만 선택하세요. 파일에 필요한 다른 설정은 유지하고, 이 줄들로 전체 설정을 덮어쓰지 마세요.
저장한 뒤 해당 설정 파일이 계속 선택되어 있는지 확인하고 Home으로 돌아가 연결을 끊었다가 다시 연결한 다음 테스트를 다시 실행하세요.

시스템 DNS: 비교 기준 설정

[General]
dns-server = system

system은 설정 파일에 공용 주소를 고정하는 대신 시스템이 제공하는 DNS를 사용한다는 뜻입니다. 네트워크 로그인이 필요한 Wi-Fi에서는 먼저 로그인 인증을 완료하세요. 네트워크 접속이 허용되지 않은 상태라면 공용 DNS 주소나 DoH 엔드포인트로 바꿔도 문제가 해결되지 않을 수 있습니다.

사용자 지정 DNS: 조회 서버 지정하기

[General]
dns-server = 1.1.1.1

여기 입력하는 IP 주소는 DNS 서버 주소이며 프록시 서버 주소나 접속하려는 웹사이트 주소가 아닙니다. 일반 DNS 주소를 여러 개 입력하려면 영문 쉼표로 구분하세요. 예: dns-server = 1.1.1.1, 8.8.8.8. 목록 순서가 엄격한 주 서버·보조 서버 전환을 보장한다고 해석하지 마세요. 문제를 점검할 때는 원인을 쉽게 찾을 수 있도록 먼저 하나만 입력하세요.

DNS over HTTPS: 전체 엔드포인트 입력하기

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

DoH 값에는 DNS 서비스가 제공하는 전체 HTTPS 엔드포인트를 입력해야 하며, 서비스 소개 페이지 주소를 입력하면 안 됩니다. https://를 빼거나 /dns-query 경로를 임의로 삭제하지 마세요. 도메인 형식의 엔드포인트는 연결 전에 IP 주소를 알아내야 하므로, DoH를 사용해도 초기 DNS 조회 과정에 대한 의존성이 완전히 사라지는 것은 아닙니다.

설정 파일 확인

경로: Config → 현재 사용 중인 설정 파일
섹션: [General]
키: dns-server
작업: 기존 값을 변경하고 저장한 뒤 다시 연결

예시는 DNS 항목만 보여 주며 기존 파일을 대체할 수 있는 전체 설정이 아닙니다.

DoH 엔드포인트 확인

프로토콜: https://
호스트: cloudflare-dns.com
경로: /dns-query
전제 조건: 엔드포인트에 연결할 수 있고 TLS 검증이 정상이어야 합니다.

일반 웹페이지에서 오류가 표시된다는 사실만으로 DoH 조회 실패를 단정할 수는 없습니다.

4. DNS와 규칙 및 On Demand의 관계

규칙 라우팅을 확인하려면 먼저 Home → Global Routing에서 Config를 선택한 다음 현재 설정 파일의 [Rule]을 살펴보세요. 도메인 규칙과 주소 규칙은 서로 다른 정보를 사용합니다. DOMAIN-SUFFIX는 도메인 접미사를 기준으로 일치시키고, IP-CIDR은 주소 대역을 기준으로 일치시키며, GEOIP는 주소 위치 데이터베이스를 기준으로 일치시킵니다. 주소를 알아내야 판단할 수 있는 규칙은 DNS 응답 결과의 영향을 받을 수 있습니다.

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

DOMAIN-SUFFIX,example.com,DIRECT는 해당 도메인과 하위 도메인을 일치시키는 규칙이지, DNS 서버를 지정하는 설정이 아닙니다.
IP-CIDR 예시는 사설 주소 대역 하나를 대상으로 합니다. no-resolve는 이 규칙을 확인하기 위해 도메인 조회를 별도로 실행하지 않는다는 뜻이며, 모든 DNS를 끈다는 뜻은 아닙니다.
GEOIP,CN,DIRECT는 주소를 기준으로 판단하므로 결과를 웹사이트의 언어나 도메인 접미사와 동일하게 볼 수 없습니다.
FINAL,PROXY는 앞선 규칙에 일치하는 항목이 없을 때 적용되는 기본 규칙입니다. 문법 설명용 예시이므로 기존 규칙 전체를 그대로 바꾸는 데 사용하지 마세요.

Settings → On Demand는 조건에 따라 연결을 시작하거나 끊는 기능이며 DNS 서버를 선택하지는 않습니다. Wi-Fi를 전환할 때 이 설정이 연결 상태를 자동으로 바꾸면 전후 요청이 서로 다른 조건에서 실행될 수 있습니다. 테스트에 영향을 줄 수 있는 조건을 먼저 기록하거나 잠시 비활성화하고, 확인이 끝나면 원래 설정으로 되돌리세요.

이미 사용 중인 구독의 업데이트와 Config 파일 업데이트도 구분해야 합니다. 서버 목록이 바뀌어도 현재 설정의 DNS 항목이 함께 변경되는 것은 아닙니다. 설정 파일을 다시 가져오거나 교체했다면 [General]을 다시 확인해 변경한 내용이 유지되었는지 점검하세요.

5. 변경 후 동일한 조건에서 확인하기

특정 웹페이지가 가끔 열린다는 사실만으로 결론을 내리지 마세요. 네트워크, 서버, Global Routing, 테스트 대상을 동일하게 유지하고 dns-server만 변경하세요. 캐시 때문에 변경 직후에도 이전 결과가 사용될 수 있고 기존 연결이 계속 작동할 수도 있습니다. 따라서 이미 열려 있는 페이지를 다시 보는 데 그치지 말고 연결을 다시 설정한 뒤 요청을 새로 보내 테스트하세요.

기준 상태 기록. 기존 DNS 값, 사용 중인 네트워크, Global Routing 방식을 기록하고 같은 서버에서 Connectivity Test를 실행해 성공 여부를 남기세요.
한 번에 한 항목만 변경. DNS 값 하나만 바꾸고 현재 설정을 저장한 뒤 연결을 끊었다가 다시 연결하세요. 이때 규칙, 서버 프로토콜, On Demand 조건은 함께 바꾸지 마세요.
요청 다시 보내기. 접속이 확인된 도메인을 다시 열고 이전에 실패한 도메인에도 접속하세요. 로컬 네트워크 서비스를 사용한다면 내부 이름도 테스트하세요.
결과 확인. Data의 연결 기록에서 대상, 규칙, 처리 결과를 확인하세요. 화면에 DNS 조회 세부 정보가 표시되지 않는다면 트래픽 수치만으로 어떤 DNS 서비스를 사용했는지 추측하지 마세요.
네트워크별 재검사. Wi-Fi와 셀룰러 네트워크에서 각각 확인하고 결과를 기록하세요. 한쪽 네트워크에서만 실패한다면 해당 네트워크에서 DNS 서버나 DoH 엔드포인트에 연결할 수 있는지 먼저 점검하세요.
원래 값으로 되돌려 비교. 기존 값을 복원한 뒤 한 번 더 테스트하세요. 설정 변경에 따라 실패가 반복해서 나타나는 경우에만 새 DNS 출처나 엔드포인트를 추가로 점검하고, 여러 설정을 계속 덧붙이지 마세요.

Connectivity Test는 연결 가능 여부를 확인하지만 한 번 성공했다고 모든 도메인이 지정한 DNS 서버를 사용한다거나 DNS 조회가 특정 경로로 전송된다는 뜻은 아닙니다. 마찬가지로 Data에 DIRECT 또는 PROXY가 표시되면 우선 해당 연결의 처리 결과를 나타내는 것이므로, 이를 모든 DNS 조회에 대한 판단으로 확대해서는 안 됩니다.

6. 자주 묻는 질문과 되돌리는 방법

DoH를 설정한 뒤 웹페이지가 열리지 않는 이유는 무엇인가요?

먼저 Config에서 현재 설정 파일의 dns-server를 기존 값으로 복원하고 다시 연결한 뒤 재검사하세요. 복원 후 정상이라면 전체 엔드포인트 주소, 네트워크 연결 상태, 기기 시간을 확인하세요. 엔드포인트는 초기 DNS 조회가 필요하며 인증서 검증에도 정확한 시간이 필요합니다. 원인을 구분할 수 없게 되므로 서버와 규칙을 동시에 바꾸지 마세요.

사용자 지정 DNS로 바꾼 뒤 집 안의 내부 이름이 조회되지 않나요?

먼저 system으로 복원하고 같은 Wi-Fi에서 내부 이름을 다시 조회하세요. 공용 DNS 서비스는 대개 가정용 라우터나 회사 내부에서 관리하는 이름을 알지 못합니다. 이런 상황이라면 내부 이름에 응답할 수 있는 DNS 출처를 유지하고 실제 네트워크 구성에 맞춰 공용 도메인을 처리하세요. 내부 이름 조회 실패를 프록시 서버 탓으로만 돌리지 마세요.

변경 사항을 저장했는데 아무것도 달라지지 않은 것 같나요?

Config에서 실제로 사용 중인 파일을 확인하고 다른 사본을 수정한 것은 아닌지 살펴본 뒤 dns-server 항목이 중복으로 입력되지 않았는지 확인하세요. 저장 후 Home에서 연결을 끊었다가 다시 연결하고 요청을 새로 보내세요. 대상 앱이 자체 암호화 DNS나 캐시를 사용한다면 관찰한 결과가 이 설정을 그대로 반영하지 않을 수 있습니다.

DoH를 사용하면 모든 DNS가 암호화된다고 볼 수 있나요?

아닙니다. 이 값은 해당 조회 요청에 사용할 엔드포인트를 지정할 뿐, 엔드포인트의 초기 조회나 앱 자체 DNS, 다른 설정 경로까지 모두 포함하지는 않습니다. 먼저 설정이 적용되었는지 확인하고 확인 가능한 기록을 바탕으로 실제 요청을 살펴보세요. DoH는 DNS 서비스까지의 전송을 암호화하며, DNS 서비스는 여전히 조회 내용을 처리해야 합니다.

마지막으로 정상 작동이 확인된 설정과 테스트 기록을 보관하세요. 되돌릴 때는 이번에 변경한 DNS 항목만 복원하고 저장한 뒤 다시 연결하세요. 설정 파일 전체를 교체했다면 백업을 복원하고 Global Routing도 다시 확인하세요. 이렇게 하면 여러 옵션을 계속 바꿔 보는 대신 DNS 출처 변경과 트래픽 정책 변경을 구분해 점검할 수 있습니다.

Shadowrocket은 Apple 플랫폼 전용 상용 클로즈드 소스 앱이며 App Store에서만 제공됩니다. 주로 iPhone과 iPad에서 사용하며 시스템 요구 사항은 App Store 페이지를 기준으로 확인하세요. 앱의 일회성 구매는 서버 이용권과 다릅니다. 이 글은 DNS 및 연결 확인에 사용자가 이미 이용 중인 서비스를 전제로 합니다.