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

먼저 DNS 조회와 프록시 연결을 구분하세요

DNS는 도메인 이름을 IP 주소로 변환합니다. 예를 들어 A 레코드를 조회하면 IPv4 주소를, AAAA 레코드를 조회하면 IPv6 주소를 받습니다. DNS 조회에 성공했다는 것은 응답을 받았다는 뜻일 뿐, 대상 포트에 연결할 수 있거나 프록시 연결이 성립했다는 의미는 아닙니다. 반대로 Home에서 서버 테스트에 응답이 있더라도 모든 웹사이트의 도메인이 정상적으로 조회된다는 보장은 없습니다.

이 흐름은 각 단계의 관계를 이해하기 위한 것으로, 모든 요청이 반드시 로컬에서 먼저 조회된다는 뜻은 아닙니다. DOMAIN-SUFFIX는 도메인으로 매칭할 수 있지만, IP-CIDR이나 GEOIP 같은 규칙은 주소 정보가 필요할 때 조회를 유발할 수 있습니다. 프록시로 전달되는 도메인 요청을 원격에서 조회하는지는 프로토콜, 설정, 실제 연결 경로에 따라 달라집니다.

세 가지 DNS 방식의 경로와 장단점

‘사용자 지정 DNS’는 조회 서버를 직접 지정한다는 뜻이며, 특정 암호화 프로토콜을 가리키지는 않습니다. 여기서는 일반 IP 주소 형식의 DNS와 DNS over HTTPS를 나누어 비교해 주소를 어디에 입력할지, 문제가 생기면 어떤 네트워크 경로를 먼저 확인할지 살펴봅니다.

내부 도메인을 사용하는 네트워크에서는 시스템 DNS가 적합한 경우가 많습니다. 사무실 시스템, 프린터, 가정용 저장 장치는 라우터가 제공하는 조회 서버에 의존할 수 있습니다. 이를 외부 조회 서버로 바꾸면 일반 웹사이트는 열려도 내부 이름은 존재하지 않거나 잘못된 주소를 반환할 수 있습니다. 이는 프록시 프로토콜의 문제가 아니라 해당 조회 서버에 내부 레코드가 없기 때문입니다.

DNS over HTTPS가 더 빠르다고 보장되지는 않습니다. 최초 연결에는 엔드포인트 도메인 조회, TCP 연결, TLS 핸드셰이크가 필요할 수 있으며, 이후 요청은 연결과 캐시를 재사용할 수 있습니다. 443번 포트를 사용한다는 이유만으로 안정성을 판단하지 말고, 같은 네트워크와 같은 도메인에서 조회 오류와 접속 결과를 확인하세요.

Settings와 Config: 적용 위치를 확인한 뒤 수정하세요

iPhone / iPad에서는 먼저 Home에서 Global Routing을 확인하고, 규칙을 테스트할 때는 Config를 선택하세요. 그런 다음 Config에서 현재 활성화된 설정 파일을 확인합니다. Settings → DNS에서 전역 DNS 설정을 확인하고, 현재 Config의 DNS 항목도 함께 살펴보세요. Config에 자체 조회 설정이 포함될 수 있으므로 Settings의 주소 하나만 보고 최종 동작을 판단해서는 안 됩니다.

1. 현재 상태를 기록하세요. 네트워크, Global Routing, 활성화된 Config, 기존 DNS 설정, 문제가 발생한 도메인을 기록합니다. 먼저 기존 설정에서 문제가 재현되는지 확인하세요.
2. 현재 설정을 백업하세요. Config에서 기존 설정 파일의 사본을 보관합니다. 설정 텍스트의 [General] 영역에 dns-server가 이미 있는지 확인해 중복 항목을 추가하지 않도록 하세요.
3. 한 곳만 수정하세요. 시스템 DNS를 확인하려면 해당 시스템 조회 설정을 복원하세요. 사용자 지정 방식을 확인하려면 이미 보유한 조회 서버 주소나 DNS over HTTPS 엔드포인트 전체를 입력하세요.
4. 연결을 다시 설정하세요. 저장한 뒤 해당 Config가 계속 선택되어 있는지 확인하고, Home의 연결을 껐다가 다시 켭니다. 대상 도메인에 다시 요청을 보내고 로그와 접속 결과로 설정 적용 여부를 판단하세요.
5. 자동 연결은 마지막에 복원하세요. 테스트 중에는 Settings → On Demand를 확인해 자동 연결이 테스트 상태를 바꾸지 않도록 하세요. 결과를 확인한 뒤 기존의 주문형 연결 설정을 복원합니다.

아래 두 카드는 항목 구조를 설명하기 위한 예시입니다. 192.0.2.53은 문서용 예시 주소이고 resolver.example은 예시 도메인이므로 실제 조회 서비스로 사용할 수 없습니다. 실제 값은 사용이 허가된 네트워크 설정에서 확인하세요. 이 글에서는 조회 서비스나 회선 서비스를 추천하지 않습니다.

설정이 기존 구독이나 원격 파일로 관리되는 경우 업데이트 과정에서 로컬 수정 사항이 덮어써질 수 있습니다. 업데이트 전에 변경 내용을 보관하고, 업데이트 후 현재 선택된 Config와 DNS 항목을 다시 확인하세요. 서버 구독 업데이트와 설정 파일 업데이트는 서로 다른 작업입니다. 서버 항목이 갱신됐다고 해서 DNS 설정도 바뀌었다고 볼 수는 없습니다.

DNS와 Global Routing, 규칙 순서의 관계

Global Routing의 Proxy, Direct, Config, Scene은 서로 다른 라우팅 방식을 결정합니다. 규칙을 점검할 때는 Config를 사용하세요. Proxy와 Direct는 경로를 비교하는 데 유용하지만, 전환한 뒤 나타난 같은 현상만으로는 기존 규칙 중 어느 항목이 매칭됐는지 판단할 수 없습니다. Scene을 사용하는 경우 해당 장면에서 실제로 적용되는 설정도 확인하세요.

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

이 규칙은 문법 설명용이며 범용 분할 라우팅 설정이 아닙니다. example.com과 192.0.2.0/24는 문서용 예시입니다. 현재 Config에서 해당 정책을 올바르게 사용하고 있다는 전제하에 규칙은 순서대로 확인됩니다. 예시를 적용하려고 기존의 완전한 규칙을 덮어쓰지 마세요.

• DOMAIN-SUFFIX: 도메인 접미사로 매칭하므로 대상 도메인을 명확히 알고 있을 때 적합합니다. 이 규칙이 먼저 매칭되면 뒤에 있는 GEOIP에 의존해 정책을 결정할 필요가 없습니다.
• IP-CIDR: IP 주소 대역으로 매칭합니다. 예시의 no-resolve는 이 규칙을 매칭하기 위해 추가 도메인 조회를 유발하지 않는다는 뜻이지, 연결 과정에서 DNS를 전혀 사용하지 않는다는 뜻은 아닙니다.
• GEOIP: 대상 IP를 지리 데이터베이스에 따라 분류합니다. DNS가 반환하는 주소가 달라지면 이후 분류 결과도 달라질 수 있습니다. 데이터베이스상의 분류는 실제 네트워크 지연 시간과 같지 않습니다.
• FINAL: 앞선 규칙이 모두 매칭되지 않았을 때 최종 정책을 선택합니다. 실패한 DNS 조회를 복구하거나 접속할 수 없는 서버 주소를 바로잡지는 않습니다.

프록시 서버 자체에 도메인을 사용하는 경우에도 최초 조회에 사용할 수 있는 경로가 필요합니다. DNS over HTTPS 엔드포인트를 프록시로 연결하도록 설정했는데 해당 프록시 서버의 도메인 조회가 아직 접속할 수 없는 엔드포인트에 의존하면 연결 시작 단계에서 의존성 문제가 발생할 수 있습니다. 연결을 시작하기 전에 서버 도메인과 조회 엔드포인트를 각각 확인할 수 있는지 점검하세요. 프로토콜을 반복해서 바꾸는 것으로 해결할 수는 없습니다.

네트워크와 오류 발생 단계에 따라 DNS 문제 진단하기

테스트할 때는 서버와 Config를 그대로 두고 DNS 방식만 바꾸세요. Wi-Fi와 셀룰러 네트워크에서 각각 결과를 기록하고, 서버와 규칙, 조회 서버를 동시에 변경하지 마세요. 웹페이지가 열리지 않는다고 해서 반드시 DNS 단계의 문제인 것은 아닙니다. 주소를 받은 뒤에도 대상 연결, TLS, 애플리케이션 단계에서 실패할 수 있습니다.

NXDOMAIN은 조회 서버가 해당 이름이 존재하지 않는다고 응답했다는 뜻입니다. 시간 초과는 대기 시간 내에 사용 가능한 응답을 받지 못했다는 뜻이므로 두 상황을 혼동하면 안 됩니다. 특정 네트워크에서만 시간 초과가 발생한다면 먼저 해당 네트워크와 조회 서버 사이의 경로를 확인하세요. 일반 도메인은 정상인데 내부 이름에서 계속 NXDOMAIN이 반환되면 조회 서버를 잘못 선택했는지 확인하세요.

또한 브라우저 주소창에 IP를 직접 입력하는 방법만으로 확인하지 마세요. 많은 HTTPS 사이트는 인증서 검증과 가상 호스트 선택에 도메인을 사용하므로 IP로 접속되지 않는다고 해서 라우팅이 불가능하다는 뜻은 아닙니다. 요청 로그의 조회 결과와 대상 주소, 연결 단계를 함께 확인해 DNS 오류와 TLS 오류를 구분하세요.

DNS 설정 관련 자주 묻는 질문과 복구 방법

마지막으로 네트워크 유형, Global Routing, 현재 Config, DNS 방식, 대상 도메인, 오류 단계, 복구 조치만 간단히 기록해 두세요. 기록을 공유해야 한다면 기존 구독의 토큰과 인증 정보, 내부 도메인을 삭제하세요. 이 사이트는 서버나 구독을 제공·판매·추천하지 않으며, 이 글에서는 사용자가 이미 보유한 설정을 점검하는 방법만 설명합니다.

• 일반 웹사이트와 내부 도메인이 모두 정상이라면 현재 설정을 유지하고 DNS 방식을 하나로 통일하려고 바꾸지 않아도 됩니다.
• 조회 서버를 고정해야 한다면 주소 접속 가능 여부와 사용 권한, 내부 도메인 요구 사항을 먼저 확인한 뒤 변경하세요.
• DNS 전송을 암호화해야 한다면 DNS over HTTPS 엔드포인트 전체, TLS, 최초 조회 경로를 확인하세요.
• 변경 후 문제가 발생하면 설정을 백업본으로 복원하고 연결을 다시 설정한 뒤 항목별로 테스트하세요. 설정을 계속 추가하지 마세요.