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

이 글 한눈에 보기

Shadowrocket의 DNS 문제를 확인할 때는 먼저 현재 설정을 점검한 뒤 적절한 확인 방법을 선택하세요. 일반적인 네트워크에서는 system으로 기준 상태를 확인하고, 특정 DNS를 지정하려면 IP 주소를 입력하며, 암호화된 DNS 전송이 필요하다면 DNS over HTTPS를 테스트할 수 있습니다. 자체 서비스 제공업체와 구독을 이용하며 정상적으로 연결할 수 있는 사용자를 위해, 다른 설정과 분리해 교체할 수 있는 설정 예시와 DNS 조회 실패, 규칙 선택 오류, 대상 서버 연결 실패를 구분하는 방법을 안내합니다.

DNS 조회와 웹 연결을 구분하세요

DNS는 도메인 이름을 IP 주소로 변환합니다. 웹페이지를 열 수 있는지는 이후의 라우팅 선택, 대상 포트 연결, TLS 핸드셰이크에도 달려 있습니다. Home의 지연 시간 테스트에 값이 표시되더라도 해당 테스트 조건에서 응답을 받았다는 뜻일 뿐, Safari에서 접속하는 도메인이 반드시 조회된다는 의미는 아닙니다. 웹페이지에 필요한 모든 연결이 성공한다고 볼 수도 없습니다.

도메인 요청DNS 조회주소 결과대상 연결페이지 로드

위 과정은 기기에서 DNS 조회가 필요한 접속에 해당합니다. 모든 프록시 연결에서 기기가 대상 IP를 먼저 조회해야 한다는 뜻은 아닙니다. 도메인을 원격에서 직접 처리하거나, 규칙이 먼저 도메인 기준으로 적용될 수도 있습니다. 문제를 확인할 때는 ‘조회 결과를 받았는지’와 ‘결과를 받은 뒤 연결에 성공했는지’를 따로 살펴보고, 모든 실패를 DNS 탓으로 돌리지 마세요.

일반 DNS에서 주로 사용하는 UDP / TCP 포트

443

DNS over HTTPS에서 주로 사용하는 HTTPS 포트

[General]

dns-server 설정이 들어가는 섹션

포트는 전송 방식을 구분하는 데만 참고하세요. 443 포트에 연결할 수 있다고 해서 특정 DNS over HTTPS 엔드포인트를 사용할 수 있는 것은 아닙니다. 53 포트에 연결할 수 있어도 올바른 응답을 받는다는 보장은 없습니다. 실제 반환된 주소와 오류 유형, 이후 접속 결과를 확인해야 합니다.

세 가지 DNS 설정 중 무엇을 선택할까요?

system은 초기 기준을 확인하기에 적합하며, 특히 로컬 네트워크의 DNS 조회가 필요한 경우에 유용합니다. IP 주소로 사용자 지정 DNS를 지정하면 반복 테스트를 진행하기 쉽지만, IP를 입력하는 것만으로 DNS 조회가 암호화되지는 않습니다. DNS over HTTPS(DoH)는 HTTPS를 통해 DNS 조회를 전송하므로 전송 경로에서 네트워크가 조회 내용을 직접 확인하기 어렵게 해 줍니다. 단, 연결할 수 있고 신뢰할 만한 DNS 엔드포인트가 필요합니다.

설정 방식	속도 및 안정성	개인정보 보호 범위	우선 테스트할 상황
`system`	기기 시스템과 네트워크에서 제공하는 DNS 경로에 따라 달라집니다. 로컬 리소스에 접속할 때 편리한 경우가 많습니다.	system 설정만으로 DNS 조회가 암호화되는지 판단할 수 없습니다.	기준 상태 확인, 사내 네트워크, 로컬 네트워크 이름 조회
사용자 지정 DNS IP	지정한 DNS 서버까지의 네트워크 경로에 따라 결과가 달라집니다. 주소를 고정하면 문제를 재현하기 쉽습니다.	일반 DNS 조회는 HTTPS 전송으로 보호되지 않습니다.	네트워크 기본 DNS 서버에 문제가 있는지 확인할 때
DNS over HTTPS	첫 연결에는 엔드포인트 조회와 TLS 핸드셰이크가 필요할 수 있습니다. 연결 재사용과 캐시에 따라 이후 소요 시간은 달라집니다.	DoH 엔드포인트까지의 전송을 보호하지만, 엔드포인트 운영자는 조회 요청을 처리할 수 있습니다.	DNS 조회를 암호화하고 싶고 HTTPS 엔드포인트에 연결할 수 있는지 확인한 경우

세 가지 방식의 속도 순위가 정해져 있는 것은 아닙니다. 가까워도 혼잡한 DNS 서버가 멀리 있는 서버보다 느릴 수 있고, DNS 서버를 바꾸면 CDN에서 반환하는 주소가 달라져 DNS 조회는 빨라져도 웹페이지는 오히려 느려질 수 있습니다. 따라서 DNS 조회 한 번의 시간만 비교하지 말고 실제 웹페이지 접속도 테스트해야 합니다.

Config에서 dns-server 수정하기: 한 번에 한 가지 방식만 테스트

먼저 Config에서 현재 활성화된 설정 파일을 확인하고 원본을 복사한 다음 해당 파일의 편집 화면으로 이동하세요. 기존 [General] 섹션을 찾아 그 안의 dns-server를 수정합니다. 아래 세 가지 예시는 각각 별도로 테스트하는 방법이며, 모두 한꺼번에 붙여 넣는 완성된 설정이 아닙니다.

방법 1: system으로 기준 상태 확인

[General]
dns-server = system

system은 시스템에서 제공하는 DNS 서버를 사용하며, 실제 동작은 기기와 현재 네트워크에 따라 달라집니다. Wi-Fi에 연결했을 때 로컬 네트워크 이름을 조회할 수 있지만 공개 DNS 서버로 바꾸면 실패할 수 있습니다. 해당 이름이 네트워크 내부에서만 사용되는 경우일 수 있습니다. 이때는 공개 DNS 주소를 계속 추가하기보다 네트워크에서 제공하는 DNS 설정을 확인하세요.

방법 2: 일반 DNS 서버 지정

[General]
dns-server = 1.1.1.1

아래 주소는 IP 주소 입력 형식을 보여 주기 위한 예시이며, DNS 서비스의 속도나 사용 가능성을 보장하지 않습니다. 사용하기 전에 현재 네트워크에서 해당 서버에 연결할 수 있는지, 자신의 사용 목적에 적합한지 확인하세요. 기준 상태를 기록하지 않은 채 DNS 서버, 규칙 파일, 프록시 선택을 동시에 바꾸면 어떤 변경이 영향을 미쳤는지 판단하기 어렵습니다.

방법 3: DNS over HTTPS 사용

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

아래는 DoH 엔드포인트 전체 주소 형식입니다. https://, 호스트 이름, /dns-query 경로가 함께 요청 주소를 구성하며, 일반 웹사이트의 첫 화면 주소로 대체할 수 없습니다. 호스트 이름을 사용하는 엔드포인트는 HTTPS 연결을 시작하기 전에 해당 이름을 조회할 수 있어야 합니다. 이 초기 단계에서 문제가 발생한다면 대상 DNS를 DoH로 바꾸는 것만으로 자동 해결되지는 않습니다.

현재 [General] 섹션에서 해당 설정만 바꾸고 나머지 항목은 유지하세요. 같은 이름의 섹션이나 키를 중복해서 만들지 마세요.
저장한 뒤 수정한 설정이 활성화되어 있는지 확인하세요. 연결을 끊었다가 다시 연결한 다음 접속을 테스트합니다.
Home으로 돌아가 Global Routing을 확인하세요. 파일의 분할 라우팅 규칙을 확인할 때는 Config를 사용합니다. Proxy, Direct 또는 Scene의 동작은 현재 선택된 모드에 따라 별도로 판단해야 합니다.
원격 설정 파일을 사용하는 경우 업데이트로 로컬 변경 사항이 덮어써지는지 먼저 확인하세요. 테스트용 사본은 일상적으로 자동 업데이트되는 파일과 분리해 관리합니다.

설정 범위: DNS는 주소를 반환하고 Rule은 처리 방식을 결정합니다

dns-server는 특정 웹사이트를 DIRECT 또는 PROXY로 지정하지 않습니다. 규칙은 [Rule] 섹션에 있으며 위에서부터 순서대로 적용됩니다. 도메인 규칙은 도메인 자체를 기준으로 판단할 수 있고, IP 규칙에는 대상 주소가 사용됩니다. 따라서 DNS 조회 결과가 달라지면 이후 IP 규칙의 일치 여부에 영향을 줄 수 있지만, DNS를 바꾸는 것과 분할 라우팅 정책을 바꾸는 것은 별개의 작업입니다.

DNS 설정 확인

섹션: [General]
항목: dns-server
시스템에서 제공하는 DNS: system
암호화된 엔드포인트: https://cloudflare-dns.com/dns-query

먼저 엔드포인트에서 응답을 받을 수 있는지 확인한 뒤 대상 연결을 점검하세요.

규칙 문법 확인

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

여기서는 키워드와 매개변수를 나누어 표시합니다. 전체 설정에서는 각 항목을 쉼표로 연결해야 합니다.

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

이 규칙은 문법을 설명하기 위한 예시이며, 모든 네트워크에 적용할 수 있는 완성된 설정이 아닙니다. no-resolve는 해당 IP 규칙을 적용하기 위해 도메인을 추가로 조회하지 않는다는 뜻이지, 모든 DNS 조회를 사용 중지한다는 뜻은 아닙니다. FINAL은 규칙 섹션의 마지막에 두며, 앞선 규칙에 일치하지 않은 요청에 기본 정책을 적용합니다.

DNS 조회로 주소를 받았는데도 웹페이지가 시간 초과되면 일치한 정책과 해당 정책에 따른 연결을 확인하세요. 사용자가 보유한 Shadowsocks, VMess, VLESS, Trojan, Hysteria2 또는 WireGuard 연결 정보는 별도의 설정입니다. DNS를 바꾸어도 잘못된 인증 정보, 포트 또는 서버 설정은 해결되지 않습니다.

정해진 절차에 따라 속도와 안정성 비교

한 번 성공했다고 설정이 계속 안정적이라는 뜻은 아니며, 한 번 실패했다고 DNS 서버를 사용할 수 없다고 단정할 수도 없습니다. 테스트할 때는 같은 기기, 네트워크, 설정 규칙, 접속 대상을 유지하고 system, 고정 DNS IP, DoH 순으로 하나씩 비교하세요. Wi-Fi와 셀룰러 네트워크를 바꾸어 테스트한다면 별도의 테스트 결과로 기록해야 합니다.

기준 상태 기록: system을 사용해 평소 정상적으로 접속하는 도메인과 현재 실패하는 도메인을 각각 열어 보세요. DNS 조회와 페이지 접속이 되는지, 어떤 오류가 발생하는지 기록합니다.
DNS 서버만 변경: dns-server를 바꾸고 다시 연결하세요. Global Routing과 선택한 연결은 그대로 유지합니다.
캐시 여부 구분: 첫 접속과 반복 접속 결과를 각각 확인하세요. 기기, 브라우저, DNS 서버에 결과가 캐시될 수 있으므로 페이지를 새로 고쳐도 DNS를 다시 조회한다는 보장은 없습니다.
응답 확인: 앱의 관련 진단 또는 기록에서 DNS 결과를 확인할 수 있다면 A 또는 AAAA 응답 여부, 시간 초과 여부, NXDOMAIN 반환 여부를 살펴보세요. 주소가 다르다는 이유만으로 응답이 잘못됐다고 판단하지 마세요.
실제 연결 확인: DNS 조회는 되지만 페이지가 열리지 않는다면 대상 연결, 규칙 정책, IPv4 / IPv6 경로를 확인하세요. DNS 주소를 계속 추가하는 것으로 해결하려 하지 마세요.
확인한 뒤 설정 유지: 반복 테스트에서도 안정적으로 개선되는 설정만 유지하세요. 개선되지 않으면 사본으로 되돌려 임시 테스트 설정이 장기 설정으로 남지 않게 합니다.

NXDOMAIN은 DNS 서버가 해당 이름이 존재하지 않는다고 응답했다는 뜻으로, ‘응답 대기 시간 초과’와는 다릅니다. AAAA 응답이 없더라도 DNS 조회가 실패한 것은 아닙니다. 대상이 IPv4 주소만 제공할 수 있습니다. A와 AAAA 응답을 모두 받았는데 기기가 연결된 네트워크의 IPv6 경로에 문제가 있으면 일부 페이지가 오래 대기할 수 있습니다. 이 경우 주소 체계와 연결 오류를 따로 확인하고, DoH가 작동하지 않는다고 바로 판단하지 마세요.

자주 묻는 질문: DoH 시간 초과, 로컬 네트워크 접속 실패, 개인정보 보호 범위

DoH를 설정한 뒤 모든 웹페이지가 열리지 않으면 무엇부터 바꿔야 하나요?

먼저 Config에서 현재 파일의 dns-server를 system으로 되돌리고 저장한 뒤 다시 연결하세요. 접속이 복구되면 DoH 주소가 완전한지, 엔드포인트 호스트 이름을 조회할 수 있는지, 현재 네트워크가 HTTPS 연결을 제한하는지, 기기의 시간이 올바른지 각각 확인하세요. 규칙과 연결 정보는 동시에 바꾸지 마세요.

일반 웹사이트는 열리는데 프린터와 내부 네트워크 도메인에 접속할 수 없나요?

먼저 system으로 되돌린 뒤 같은 Wi-Fi에서 동일한 이름으로 다시 접속해 보세요. 내부 도메인은 로컬 DNS에서만 제공될 수 있으므로 공개 DNS 서버에서 응답하지 않을 수 있습니다. 일반 DNS 이름과 로컬 검색 기능에 의존하는 이름도 구분해야 합니다. 모든 로컬 네트워크 접속 문제가 dns-server 설정으로 해결되는 것은 아닙니다.

DoH를 사용하는데도 규칙을 확인해야 하는 이유는 무엇인가요?

DoH는 DNS 전송 방식만 지정합니다. Home으로 돌아가 Global Routing을 확인하세요. 파일에 설정된 규칙을 확인할 때는 Config를 사용하고, 해당 요청에 적용된 DIRECT 또는 PROXY도 살펴봅니다. IP 주소를 받았는데 연결 시간이 초과된다면 DNS 서버만 확인하지 말고 발신 경로를 점검해야 합니다.

DNS 서버를 여러 개 입력하면 항상 더 안정적인가요?

먼저 DNS 서버 하나로 비교 테스트를 완료하세요. 여러 주소를 선택하고 실패에 대응하는 방식은 구현에 따라 다르므로 입력 순서만으로 주 서버와 보조 서버를 단정할 수 없습니다. 일반 DNS와 DoH를 함께 사용한다고 모든 DNS 조회가 암호화되는 것도 아닙니다. 각 주소를 하나씩 테스트해 사용할 수 있음을 확인한 뒤 앱 내 안내에 따라 설정하세요.

DoH를 사용하면 DNS 서비스 제공업체가 조회 내용을 볼 수 없나요?

DoH 엔드포인트는 DNS 조회를 처리하므로 운영자는 전달된 조회 요청을 확인할 수 있습니다. HTTPS는 주로 기기와 엔드포인트 사이의 전송 내용을 보호합니다. DNS 서버를 선택할 때 서비스 안내를 확인하고 ‘전송 암호화’, ‘DNS 서비스에 대한 신뢰’, ‘프록시 라우팅’을 서로 다른 문제로 다루세요.

최종 설정은 현재 네트워크에서의 연결 가능 여부, 실제 웹페이지 접속 결과, 필요한 개인정보 보호 범위를 기준으로 선택하세요. 설정 항목에 관한 자세한 설명은 설정 항목 안내를 참고하세요. 특정 네트워크에서만 문제가 발생한다면 문제 해결을 함께 확인해 보세요. Shadowrocket은 주로 iPhone / iPad에서 사용하며, 시스템 요구 사항과 기기 호환성은 App Store 페이지의 안내를 기준으로 확인하세요.