Shadowrocket DNS 설정 가이드: 시스템 DNS·사용자 지정 DNS·DNS over HTTPS 선택법

DNS 조회와 Global Routing의 트래픽 경로 구분하기

DNS(도메인 이름 시스템)는 도메인 이름을 연결 가능한 주소로 변환합니다. 웹페이지를 열 때 DNS 조회 성공은 시작에 불과합니다. 이후 규칙 매칭, 연결 설정, TLS 핸드셰이크, 응답 전송이 이어집니다. 웹페이지가 열리지 않는다고 해서 곧바로 DNS 문제라고 단정할 수 없으며, DNS 서버를 바꾼다고 모든 연결 시간 초과가 해결되는 것도 아닙니다.

이 흐름은 문제 발생 단계를 구분하기 위한 것으로, 모든 요청이 반드시 같은 순서로 처리된다는 뜻은 아닙니다. 캐시가 있거나 도메인 규칙이 먼저 매칭되는 경우, 원격 DNS 조회, 앱 자체의 조회 기능 등에 따라 실제 처리 과정은 달라질 수 있습니다. 특히 도메인 규칙은 IP 주소를 로컬에서 확인하기 전에 매칭될 수 있습니다.

• Home → Global Routing은 트래픽의 라우팅 방식을 결정하며, DNS 서버 선택과는 별개입니다.
• Config는 현재 설정의 규칙에 따라 트래픽을 분기합니다. Proxy와 Direct는 각각 해당하는 글로벌 아웃바운드 방식을 선택합니다.
• Scene은 사용할 장면을 선택하는 기능입니다. 문제를 확인할 때는 현재 장면과 실제로 적용된 설정을 기록하세요. Scene은 DNS 프로토콜이 아닙니다.
• Settings → On Demand는 연결을 시작할 시점을 제어합니다. 테스트 중 네트워크 조건이 달라지면 연결 상태도 바뀔 수 있으므로 함께 기록하세요.

구독을 보유한 경우 구독을 갱신하면 보통 연결 항목이 업데이트됩니다. 그렇다고 현재 Config의 DNS 설정까지 업데이트되는 것은 아닙니다. 문제를 확인하기 전에 선택한 연결, 현재 활성화된 설정, Global Routing 방식을 각각 기록해 세 상태를 혼동하지 않도록 하세요.

시스템 DNS·사용자 지정 DNS·DoH 선택 기준

시스템 DNS는 현재 시스템 네트워크에서 제공하는 DNS 설정을 사용하며, Wi-Fi와 셀룰러 네트워크에서 설정이 다를 수 있습니다. 사용자 지정 DNS는 조회에 사용할 서버를 지정합니다. 일반 DNS 서버 주소를 입력하면 대개 기존 DNS 전송 방식을 사용합니다. DNS over HTTPS(HTTPS를 통한 DNS 전송, 이하 DoH)는 조회 전송 방식을 바꾸지만, 더 빠른 응답이나 현재 네트워크에 더 적합한 주소를 보장하지는 않습니다.

DoH 엔드포인트는 별도로 지정된 포트를 사용할 수도 있습니다. HTTPS 웹사이트에 접속된다고 해서 특정 DoH 엔드포인트에도 접속할 수 있는 것은 아닙니다. 서버 호스트 이름, 포트, 요청 경로, 인증서가 모두 일치해야 합니다. 조회 전송이 암호화되어도 DNS 엔드포인트는 요청을 처리하고 내용을 볼 수 있습니다. 따라서 모든 트래픽이 숨겨진다고 볼 수는 없습니다.

현재 Config의 DNS를 확인한 뒤 설정 하나씩 변경하기

먼저 Config에서 현재 활성화된 파일을 확인한 다음 [General]의 공통 설정과 dns-server 항목을 살펴보세요. 앱의 DNS 옵션은 Settings → DNS에서 확인할 수 있습니다. 활성화되지 않은 설정 파일만 수정한 뒤 DNS 서버가 적용되지 않았다고 오해하지 않도록 주의하세요.

1. 기존 값을 보관하세요. 현재 설정을 복사해 복원용 사본을 만들고 DNS 항목, Global Routing 방식, 현재 네트워크를 기록하세요. 설정에 인증 정보가 포함되어 있다면 사본을 안전하게 보관하세요.
2. 테스트할 대상을 정하세요. 정상 접속이 확인된 공개 도메인 하나와 실제 문제가 발생하는 도메인 하나를 선택하세요. 로컬 네트워크 이름은 공개 도메인과 분리해 테스트하세요.
3. DNS 설정만 변경하세요. 활성 설정의 dns-server 값을 확인하거나 해당 DNS 설정 화면에서 기존 값을 살펴보세요. 아웃바운드, 규칙, IPv6, On Demand를 동시에 변경하지 마세요.
4. 저장한 뒤 다시 연결하세요. 현재 연결을 끊고 다시 시작한 다음 새 요청을 보내세요. 이미 열려 있는 페이지, 기존 연결, 캐시된 응답만으로는 설정을 검증하기 어렵습니다.
5. 실패한 단계를 확인하세요. DNS 조회 시간 초과, 연결 시간 초과, 인증서 오류 중 어떤 문제가 발생했는지 확인하세요. 결과가 나빠졌다면 원래 설정으로 복원한 뒤 다시 연결하세요.

아래 두 예시는 같은 항목을 두 가지 방식으로 표기한 것입니다. 두 예시를 한 설정에 중복으로 추가하면 안 됩니다. 실제 파일의 다른 필수 설정은 그대로 유지하세요. 예시에 맞추려고 몇 줄의 텍스트로 설정 전체를 덮어쓰지 마세요.

[General]
dns-server = system

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

기존 설정이 원격 업데이트로 관리된다면 업데이트가 로컬 변경 사항을 덮어쓰는지 먼저 확인하세요. 복사본을 보관한 상태에서 테스트하고, 업데이트 후에는 이전에 입력한 값을 기억에 의존하지 말고 활성 파일의 실제 설정을 다시 확인하세요.

DoH 주소와 일반 DNS 주소 입력 및 확인 방법

일반 DNS 주소와 DoH URL은 서로 바꿔 쓸 수 있는 형식이 아닙니다. 일반 DNS 주소는 서버 위치를 나타내고, DoH URL에는 프로토콜, 호스트 이름, 요청 경로가 포함됩니다. 일반 DNS 주소 앞에 https://를 붙여도 해당 서버가 자동으로 DoH를 지원하지는 않습니다.

도메인 이름으로 표시된 DoH 엔드포인트는 사전 조회가 필요합니다. HTTPS 연결을 설정하기 전에 엔드포인트 자체의 주소를 알아야 합니다. 사전 조회를 사용할 수 없으면 “DNS 서버의 도메인을 조회하려면 먼저 DNS가 필요한” 의존성 문제가 발생할 수 있습니다. 이때는 현재 네트워크의 기본 DNS 조회와 엔드포인트 연결 경로를 확인하세요. 같은 이유로 연결할 수 없는 엔드포인트를 계속 추가하지 마세요.

• 주소에 접속할 수 있어도 프로토콜이 지원된다는 뜻은 아닙니다: IP 주소에 연결할 수 있다고 해서 지정한 포트에서 DoH 서비스를 제공하는 것은 아닙니다.
• HTTP 응답이 있다고 조회에 성공한 것은 아닙니다: 브라우저에서 엔드포인트를 열었을 때 오류 페이지가 표시되어도 DoH 서비스가 작동하지 않는다고 단정할 수 없습니다. 브라우저의 일반 접속은 올바른 DNS 조회와 다릅니다.
• 인증서 오류가 발생하면 원인을 확인하세요: 기기 시간, 호스트 이름, 네트워크 로그인 상태를 확인하세요. 인증서 검증을 끄는 것은 해결 방법이 아닙니다.

규칙, IPv6, 로컬 네트워크 DNS가 결과에 영향을 주는 이유

DNS에서 주소를 반환한 뒤에도 트래픽은 적용되는 라우팅 결정에 따라 이동합니다. DOMAIN-SUFFIX는 도메인 접미사를 기준으로 매칭하고, IP-CIDR은 IPv4 주소 범위를, GEOIP는 IP 주소의 지리적 위치 정보를 기준으로 매칭합니다. DNS 서버를 바꾸면 반환 주소가 달라질 수 있으며, 이에 따라 주소 기반 규칙의 매칭 결과도 달라질 수 있습니다.

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

위 예시는 문법과 매칭 관계만 보여주는 것으로 완전한 설정이 아닙니다. DIRECT는 직접 연결, PROXY는 프록시 경로를 뜻합니다. 실제로 사용할 때는 현재 설정에서 인정하는 정책 이름인지 확인하세요. 규칙은 위에서 아래 순서로 매칭되며 FINAL은 앞선 규칙에 매칭되지 않은 트래픽을 처리합니다. 주소 범위는 문서용 예시이므로 일상적인 트래픽 분기에 그대로 사용하지 마세요.

• no-resolve는 해당 주소 규칙을 위해 도메인을 추가로 조회하지 않는다는 뜻입니다. “모든 DNS를 끄는” 옵션이 아니며 기존 조회 결과를 지우지도 않습니다.
• 같은 도메인의 A 레코드와 AAAA 레코드는 서로 다른 주소를 가리킬 수 있습니다. AAAA 레코드를 받았다는 것은 DNS가 IPv6 주소를 반환했다는 뜻일 뿐, 현재 IPv6 연결 경로를 사용할 수 있다는 의미는 아닙니다.
• 회사나 가정의 내부 도메인은 로컬 DNS 서버에 의존할 수 있습니다. 외부 DNS 서버로 바꾼 뒤 공개 웹사이트는 정상인데 내부 도메인만 실패한다면 별도로 확인해야 합니다.
• 일부 앱은 자체 암호화 DNS 조회나 캐시를 사용합니다. 특정 앱에서 변화가 없다고 해서 Shadowrocket의 DNS 설정이 저장되지 않았다고 단정하지 마세요.

웹 로그인이 필요한 Wi-Fi를 사용할 때는 먼저 네트워크 인증을 완료한 뒤 사용자 지정 DNS를 테스트하세요. 인증이 끝나지 않으면 HTTPS 엔드포인트에 접속할 수 없거나 인증서 오류가 발생하거나 외부 요청이 모두 시간 초과될 수 있습니다. 이 경우 DNS 입력 형식보다 네트워크 접속 인증을 먼저 확인해야 합니다.

변경 후 확인 방법: 접속 여부만 보지 말고 실패 단계를 기록하세요

같은 네트워크, 같은 아웃바운드, 같은 라우팅 방식에서 검증하세요. 먼저 기존 설정으로 기준 결과를 기록한 다음 새 설정을 적용합니다. 매번 요청 시각과 대상 도메인, 주소 반환 여부, 이후 연결 결과를 기록하세요. 캐시된 응답 시간과 DoH 연결을 처음 설정하는 데 걸린 시간을 직접 비교하지 마세요.

앱 내 로그는 문제 위치를 파악하는 데 도움이 되지만 요청마다 같은 항목이 표시되는 것은 아닙니다. 로그에 새 DNS 항목이 없다면 캐시가 사용됐거나 다른 곳에서 DNS 조회가 이뤄졌을 수 있습니다. 실제 요청 시각과 라우팅 기록을 함께 확인하세요. 로그 한 줄이 없다는 이유만으로 결론을 내려서는 안 됩니다.

1. 재현 가능한 문제가 발생하는 도메인으로 기존 설정과 새 설정의 결과를 각각 기록하세요.
2. A 또는 AAAA 레코드가 반환됐는지 확인한 다음 연결에 실제로 사용된 주소와 정책을 살펴보세요.
3. 개인정보 관련 여부를 확인해야 한다면 직접 관리하는 테스트 도메인과 서버 기록만 사용하세요. DNS 요청의 출발지 주소가 다르다고 해서 반드시 문제가 있는 것은 아닙니다.
4. 비교가 끝나면 검증된 변경 사항만 남기고 테스트 값은 삭제한 뒤 복원용 사본을 보관하세요.

자주 묻는 질문: 설정을 저장했는데 적용되지 않을 때