이 글은 Shadowrocket에서 자신의 연결 서비스를 설정한 뒤 도메인 해석 방식을 조정하려는 사용자를 위한 안내입니다. 먼저 DNS 서버의 출처와 전송 프로토콜을 구분하고, 현재 Config를 확인한 다음 동일한 네트워크와 도메인, 연결 기록을 기준으로 결과를 검증합니다. DNS 설정 변경과 구독 업데이트는 별개의 작업이며, 웹페이지가 열리지 않는 원인이 반드시 DNS인 것도 아닙니다.
1. DNS 조회와 연결 라우팅 구분하기
DNS는 도메인에 대응하는 정보를 조회합니다. 예를 들어 웹사이트 도메인을 IPv4의 A 레코드나 IPv6의 AAAA 레코드로 변환합니다. 주소를 얻은 뒤에도 클라이언트는 현재 규칙에 따라 연결을 설정해야 합니다. DNS 응답을 받았다는 사실만으로 대상 포트에 연결할 수 있거나 TLS 핸드셰이크 및 웹 서버가 정상이라는 뜻은 아닙니다.
Shadowrocket에서 DNS와 Global Routing은 서로 관련은 있지만 같은 설정은 아닙니다. Global Routing의 Proxy, Direct, Config, Scene은 해당 라우팅 동작을 결정하고, DNS 설정은 어떤 조회 경로와 방식을 사용할지 결정합니다. 한쪽을 바꿨다고 다른 쪽도 함께 바뀌었다고 볼 수는 없습니다.
위 내용은 간략한 흐름이며, 모든 요청이 기기에서 먼저 DNS 조회를 해야 한다는 뜻은 아닙니다. 도메인 규칙이 먼저 적용될 수 있고, 일부 프록시 연결은 도메인 처리를 원격으로 넘길 수 있습니다. 캐시에 응답이 있으면 이번 접속에서 새 업스트림 조회가 발생하지 않을 수도 있습니다. 따라서 새 DNS 요청이 보이지 않는다고 해서 설정이 적용되지 않았다고 단정할 수는 없습니다.
- 도메인 규칙:
DOMAIN-SUFFIX,example.com,DIRECT는 도메인 접미사로 일치 여부를 판단하며 DNS 서버를 지정하는 규칙은 아닙니다. - IP 주소 규칙:
IP-CIDR또는GEOIP는 대상 IP를 기준으로 판단하며, 일부 일치 판정 과정에는 먼저 도메인 조회가 필요할 수 있습니다. - 최종 규칙:
FINAL은 앞선 규칙에 일치하지 않은 요청을 처리하며, DNS 서버를 선택하지는 않습니다.
2. 시스템 DNS, 사용자 지정 DNS, DoH의 차이
‘시스템 DNS’와 ‘사용자 지정 DNS’는 주로 DNS 서버를 어디서 가져오는지를 설명합니다. DNS over HTTPS(DoH)는 조회 요청을 어떤 프로토콜로 전송하는지를 뜻합니다. 따라서 세 가지는 엄밀히 서로 배타적인 선택지가 아닙니다. DoH 엔드포인트를 직접 지정하는 것도 사용자 지정 DNS에 해당합니다. 설정할 때는 ‘어디에 조회할지’와 ‘어떤 방식으로 전송할지’를 함께 확인해야 합니다.
| 설정 방식 | DNS 출처 및 전송 방식 | 적합한 상황 | 우선 확인할 사항 |
|---|---|---|---|
| 시스템 DNS | 현재 시스템 네트워크에서 제공하는 DNS 서버를 사용합니다. 전송 방식은 시스템 설정에 따라 달라집니다. | 초기 기준을 마련하거나 현재 네트워크의 내부 도메인에 접속할 때 적합합니다. | Wi-Fi와 셀룰러 네트워크에서 제공하는 DNS 서버가 다를 수 있습니다. |
| 사용자 지정 일반 DNS | 서버 주소를 직접 지정합니다. 일반 DNS 조회는 보통 UDP 53을 사용하며 TCP 53을 사용할 수도 있습니다. | 사용 가능한 DNS 서버를 알고 있거나 회사·가정 네트워크의 내부 레코드를 조회해야 할 때 적합합니다. | 주소에 연결할 수 있는지, 현재 네트워크의 조회 요청을 허용하는지, 53번 포트가 제한되는지 확인합니다. |
| DNS over HTTPS | DoH를 지원하는 엔드포인트에 HTTPS 요청을 보냅니다. 일반적으로 443번 포트를 사용합니다. | 조회 트래픽을 암호화해야 하고 엔드포인트와 연결 경로의 사용 가능 여부를 확인한 경우 적합합니다. | 전체 엔드포인트 주소, 인증서 검증, 엔드포인트 도메인의 최초 조회, 실제 아웃바운드 경로를 확인합니다. |
DoH는 클라이언트와 해당 DNS 서버 사이의 조회 전송을 암호화합니다. DNS 서버가 조회 대상 도메인을 볼 수 없게 하거나 이후 웹 트래픽의 출구를 자동으로 결정하지는 않습니다. 시스템 DNS가 반드시 평문 DNS인 것도 아닙니다. 기기의 시스템 DNS 설정에 별도의 암호화 방식이 적용될 수 있으므로 문제를 조사할 때 관련 설정을 변수로 기록하세요.
선택 기준: 먼저 연결 가능 여부를 확인한 뒤 전송 방식을 비교하세요
현재 시스템 DNS가 안정적으로 응답하고 내부 도메인도 정상적으로 작동한다면 우선 비교 기준으로 유지하세요. 조회 오류가 확인되었거나 암호화 전송이 필요한 경우에만 사용자 지정 DNS나 DoH를 별도로 테스트하세요. DNS 서버와 라우팅 방식을 동시에 바꾸면 원인을 파악하기 어렵습니다.
3. 변경 전에 현재 사용 중인 Config 확인하기
먼저 Home에서 현재 연결 상태와 Global Routing을 확인한 뒤 Config로 이동해 사용 중인 구성 파일을 살펴보세요. 다른 파일을 편집하고 저장했더라도 현재 연결에 해당 DNS 설정이 적용됐다는 뜻은 아닙니다. 화면의 메뉴 위치와 편집 방식은 실제 앱에 표시되는 내용을 기준으로 확인하세요. 구성 텍스트에서는 [General]과 dns-server를 검색할 수 있습니다.
- 기준 상태 기록: 현재 네트워크가 Wi-Fi인지 셀룰러인지, Global Routing 설정, 활성 구성 파일 이름, 실제로 문제가 발생하는 도메인을 기록하세요.
- 백업 보관: DNS를 변경하기 전에 Config에서 복원할 수 있는 구성 파일을 저장하세요. 한 번의 테스트에서 규칙, 연결 프로토콜, DNS를 동시에 바꾸지 마세요.
- 기존 설정 확인: 구성 파일에 DNS 서버가 지정되어 있는지, Settings에 현재 DNS 동작에 영향을 줄 수 있는 설정이 있는지 살펴보세요. 입력란 하나의 내용만 보고 최종 적용값을 판단하지 마세요.
- 변수 하나만 변경: 시스템 DNS에서 사용 가능 여부를 확인한 DNS 서버 하나로 전환하세요. DoH를 테스트할 때는 DNS 서버 관리자가 제공한 전체 HTTPS 엔드포인트를 사용하세요.
- 저장 후 다시 연결: Home으로 돌아가 연결을 다시 설정한 뒤 동일한 도메인을 재검사하세요. 현재 네트워크에서 Wi-Fi 인증 페이지를 먼저 거쳐야 한다면 인증을 완료하세요.
아래 두 카드는 각각 독립된 테스트를 설명하며 두 설정을 동시에 적용하라는 뜻이 아닙니다. 시스템 DNS는 구성 텍스트에서 dns-server = system으로 지정할 수 있습니다. 사용자 지정 일반 DNS에는 실제로 연결 가능한 서버 주소가 필요합니다. DoH는 별도의 전송 방식이므로 일반 IP 주소 앞에 https://를 붙인다고 해당 서버가 DoH를 지원하게 되는 것은 아닙니다.
테스트 A: 시스템 DNS 기준 확인
- 확인 위치
- Config에서 현재 사용하는 [General]
- 매개변수 이름
- dns-server
- 매개변수 값
- system
- 고정할 조건
- 같은 네트워크, 같은 Global Routing, 같은 대상 도메인
다른 DNS 관련 설정이 있다면 먼저 내용을 기록하세요. 한 줄을 추가하는 것만으로 기존 설정과의 우선순위 문제가 모두 해결된다고 단정하지 마세요.
테스트 B: 사용자 지정 일반 DNS
- 확인 위치
- Config에서 현재 사용하는 [General]
- 매개변수 이름
- dns-server
- 주소 요건
- 사용 가능 여부를 확인한 DNS 서버 IP 주소 입력
- 포트 확인
- 일반 DNS는 보통 UDP 53 또는 TCP 53에 연결할 수 있어야 합니다.
예를 들어 192.168.1.1은 현재 네트워크에서 실제 DNS 서버 주소로 제공되는 경우에만 사용할 수 있습니다. 일반적인 주소처럼 무조건 입력하지 마세요.
4. DNS over HTTPS 사용 시 확인할 네 가지
DoH 엔드포인트는 일반 웹사이트의 첫 화면 주소가 아닙니다. 지정된 DNS 메시지 형식을 지원해야 합니다. 브라우저에서 HTTPS 웹사이트가 열린다는 사실은 웹페이지 경로에 접속할 수 있다는 뜻일 뿐, 같은 도메인에서 DoH 서비스를 제공한다는 증거는 아닙니다. 입력할 때는 관리자가 제공한 전체 경로와 필요한 매개변수를 유지하고 호스트 이름, 경로, 프로토콜 헤더를 임의로 삭제하거나 바꾸지 마세요.
- 엔드포인트 형식:
https://example.com/dns-query는 형식 예시일 뿐 실제로 사용할 수 있는 DNS 서비스 주소가 아닙니다. 실제 경로가 반드시/dns-query인 것도 아닙니다. - 인증서 및 시간: HTTPS 연결에는 인증서 검증이 필요합니다. 기기 시간이 틀렸거나 엔드포인트 인증서에 문제가 있거나 네트워크 인증 페이지가 연결을 가로막으면 요청이 실패할 수 있습니다.
- 최초 DNS 조회: 엔드포인트에 도메인 이름을 사용하면 최초 연결을 설정할 때 해당 도메인의 IP 주소를 조회해야 합니다. 최초 조회에 사용하는 경로에 연결할 수 없다면 DoH 연결도 설정할 수 없습니다.
- 아웃바운드 경로: DoH가 특정 프록시 출구를 반드시 사용한다고 가정하지 마세요. 활성 구성과 규칙, 연결 기록을 함께 확인해 실제 경로와 연결 가능 여부를 점검하세요.
DoH 문제를 해결하려고 인증서 검증을 끄지 마세요. 먼저 사용 가능성이 확인된 DNS로 되돌리고 기기 시간이 정확한지 확인한 다음 엔드포인트 연결 가능 여부와 설정에 원래 주소가 유지되어 있는지 살펴보세요. 특정 Wi-Fi에서만 실패하고 셀룰러에서는 정상이라면 해당 Wi-Fi의 인증 상태와 네트워크 제한을 먼저 확인하세요.
5. DNS 설정이 적용됐는지 확인하는 방법
검증할 때는 ‘DNS 조회 결과’와 ‘실제 연결’을 함께 살펴보세요. 웹페이지가 열리는지만으로는 충분하지 않습니다. 웹사이트가 캐시를 사용하거나 브라우저가 기존 연결을 재사용할 수 있습니다. 먼저 네트워크와 Global Routing을 고정하고 변경 전후의 기록을 저장한 뒤 새 요청으로 비교하세요. 테스트 도중 Wi-Fi와 셀룰러를 전환하지 마세요.
- 변경 전 증상 기록: 문제가 발생한 도메인, 테스트 시간, 현재 구성, 오류 유형이 DNS 조회 실패인지 연결 시간 초과인지 TLS 오류인지 기록하세요.
- 구성 저장 후 다시 연결: Home에서 연결을 끊었다가 다시 연결하고 테스트 페이지의 기존 탭을 닫은 뒤 새로 접속하세요. 재연결하면 새 설정이 적용되는 데 도움이 되지만 시스템과 앱의 모든 캐시가 삭제되는 것은 아닙니다.
- DNS 조회 증거 확인: 사용 가능한 DNS 조회 또는 진단 기록에서 도메인, A/AAAA 응답, 오류 상태를 확인하세요. 업스트림 서버 정보가 있다면 예상한 서버인지도 살펴보세요.
- 연결 증거 확인: 해당 요청에 적용된 규칙, 대상 주소, 실제 출구를 확인하세요. DNS에서 반환된 주소가 달라졌다는 사실만으로 출구가 바뀌었다고 판단할 수는 없습니다.
- 반복 테스트 후 원래 설정과 비교: 같은 조건에서 여러 번 테스트하고 원래 설정으로 되돌려 다시 확인하세요. 반복해서 나타나는 차이를 기록하고 한 번의 로딩 속도로 전체 결과를 판단하지 마세요.
| 관찰된 현상 | 알 수 있는 내용 | 다음 확인 항목 |
|---|---|---|
| NXDOMAIN 응답 | DNS 서버가 해당 이름이 존재하지 않는다고 응답한 것입니다. 조회 시간 초과와는 다릅니다. | 철자와 전체 도메인 이름을 확인하고 내부 네트워크에서만 사용하는 이름인지 살펴보세요. |
| 조회 시간 초과, 응답 없음 | 현재 조회 경로에서 대기 시간 안에 처리가 완료되지 않았습니다. | DNS 서버 주소와 네트워크 연결, 엔드포인트 연결을 확인하세요. 웹사이트 라우팅 규칙부터 바꾸지 마세요. |
| A/AAAA 응답은 있지만 웹페이지 연결 시간 초과 | DNS 조회 결과는 있으므로 문제는 이후 연결 단계에서 발생했을 수 있습니다. | 대상 연결, IPv6 경로, 규칙 일치 여부, 원격 서버 연결 가능성을 확인하세요. |
| DNS 변경 후 IP 주소가 달라짐 | DNS 서버, 캐시, 콘텐츠 전송 네트워크의 요청 분산으로 인해 달라졌을 수 있습니다. | 실제 접속이 안정적인지 계속 확인하세요. IP가 다르다는 사실만으로 결과가 잘못됐다고 판단하지 마세요. |
확인 순서: DNS 응답은 있지만 연결할 수 없다면 연결 계층부터 살펴보세요
문제가 발생한 도메인에서 A 또는 AAAA 응답을 받았다면 DNS 설정은 우선 그대로 두고 적용된 규칙과 대상 연결을 확인하세요. DNS 조회 자체가 시간 초과되거나 비정상 응답을 반환하거나 내부 도메인이 해석되지 않는 경우에만 DNS 서버를 비교하세요. 관련 없는 설정을 반복해서 바꾸지 않는 것이 좋습니다.
6. 자주 묻는 질문: DNS, 라우팅, 자동 연결의 구분
DNS를 바꿨는데 진단 페이지에 이전 네트워크 정보가 표시되는 이유는 무엇인가요?
먼저 페이지에 표시된 정보가 공인 IP 출구인지, 페이지가 확인한 재귀 DNS 서버 주소인지 구분하세요. DNS 설정은 공인 IP 출구를 직접 바꾸지 않으며 DNS 서버가 여러 출구 주소를 사용할 수도 있습니다. Home에서 Global Routing을 확인하고 새 요청의 DNS 조회 및 연결 기록을 함께 살펴보세요. 진단 페이지 하나만을 유일한 근거로 삼지 마세요.
공개 웹사이트는 정상인데 집 안 기기 이름으로 접속할 수 없으면 어떻게 해야 하나요?
먼저 시스템 DNS로 되돌려 비교하고 가정용 라우터가 해당 이름의 DNS 레코드를 제공하는지 확인하세요. 공개 DNS 서버는 사설 네트워크의 내부 이름을 모르는 경우가 많습니다. .local로 끝나는 이름은 일반적인 업스트림 DNS가 아니라 mDNS와 관련될 수도 있습니다. 내부 이름 문제를 해결하려고 공개 DNS 서버를 무작정 바꾸지 마세요.
DoH를 켠 뒤 모든 도메인에서 시간 초과가 발생하면 무엇부터 바꿔야 하나요?
먼저 DNS를 변경 전 설정으로 되돌리고 다시 연결해 기본 접속이 복구되는지 확인하세요. 그런 다음 DoH 전체 엔드포인트, 기기 시간, 엔드포인트의 최초 DNS 조회를 각각 점검하세요. 연결 서버를 바꾸거나 모든 규칙을 삭제하지 마세요. 엔드포인트 연결 문제인지 라우팅 변경 문제인지 구분하기 어려워집니다.
연결을 끊었는데 자동으로 다시 연결되어 DNS 비교 테스트에 영향을 줍니다. 어떻게 해야 하나요?
Settings → On Demand를 확인하고 테스트 중에는 관련 자동 연결 조건을 기록하거나 일시적으로 비활성화하세요. Home에서 실제 연결 상태를 확인한 후 테스트하고, 완료되면 원래 설정으로 복원하세요. On Demand는 조건에 따른 연결을 제어하는 기능이지 DNS 서버를 선택하는 메뉴가 아닙니다.
웹페이지가 열리면 모든 DNS 조회에 DoH가 사용된다고 확인할 수 있나요?
아니요. 캐시, 앱 자체의 DNS 처리 방식, 원격 DNS 조회가 결과에 영향을 줄 수 있습니다. 새 요청에 대한 진단 기록을 확인하세요. DNS 전송 방식을 엄밀히 확인하려면 통제된 네트워크 환경이나 DNS 서버 측 로그도 함께 살펴봐야 합니다. 이러한 증거가 없다면 현재 접속이 복구되었다고만 판단할 수 있으며 모든 DNS 조회 경로에 대한 결론으로 확대해서는 안 됩니다.
사용할 수 있는 Config를 하나 보관하고 매번 한 가지 변수만 바꾸는 것이 이후 문제 해결의 기본입니다. 규칙이나 연결 권한을 더 확인하려면 문제 해결 매뉴얼을 참고하세요. 처음 설정하거나 자신의 구독을 가져오려면 가이드에 따라 단계별로 진행할 수 있습니다.