DNS가 정상적으로 작동한다면 시스템 설정을 유지하세요. 고정된 리졸버가 필요할 때는 사용자 지정 DNS를, DNS 쿼리 전송을 암호화하려면 DNS over HTTPS를 사용하면 됩니다. 자체 서비스와 설정을 보유하고 도메인 접속 오류나 라우팅 결과 이상을 점검하는 사용자를 위해 입력 위치, 규칙 매칭, 변수를 하나씩 바꿔 테스트하는 방법과 복구 가능한 기준 설정을 설명합니다.
1. 도메인 이름 확인과 연결 경로 구분하기
Shadowrocket의 DNS 설정은 ‘도메인 이름에 어떤 주소가 연결되는지’를 처리하고, Global Routing과 구성 규칙은 ‘연결이 어떤 경로로 나가는지’를 결정합니다. DNS를 바꿔도 서버가 전환되지는 않으며, 서버 인증 실패나 포트 연결 불가, 회선 혼잡이 자동으로 해결되는 것도 아닙니다. 웹페이지가 열리지 않을 때 여러 설정을 동시에 바꾸지 않도록 두 기능을 먼저 구분하세요.
이 흐름은 문제를 진단할 때의 논리적 관계를 나타내며, 모든 연결이 매번 기기에서 먼저 도메인 이름을 확인한다는 뜻은 아닙니다. DOMAIN-SUFFIX는 도메인 이름으로 직접 매칭할 수 있지만, IP-CIDR와 GEOIP 같은 주소 기반 규칙에는 확인된 주소가 필요할 수 있습니다. 프록시 연결에서 원격으로 이름을 확인하는지는 프로토콜, 요청 방식, 설정에 따라 달라집니다. 웹페이지가 열린다는 이유만으로 모든 DNS 요청이 프록시를 거친다고 단정할 수 없습니다.
포트 번호는 프로토콜을 식별하는 단서일 뿐, 설정 전체를 대신하지 않습니다. DoH 서비스는 지정된 비기본 포트를 사용할 수 있으며, 평소 UDP를 주로 확인하더라도 일반 DNS의 TCP 대체 연결을 무시해서는 안 됩니다. 방화벽 제한, 네트워크 인증 페이지, 리졸버 자체 장애도 최종 결과에 영향을 줄 수 있습니다.
2. 시스템 DNS, 사용자 지정 DNS, DoH 선택 기준
‘시스템 DNS’와 ‘사용자 지정 DNS’는 리졸버를 어디서 가져오는지를 나타내고, ‘DNS over HTTPS’는 쿼리를 어떤 전송 방식으로 보내는지를 나타냅니다. 서로 완전히 배타적인 세 가지 개념은 아닙니다. DoH 엔드포인트를 직접 입력하는 것도 사용자 지정 리졸버를 사용하는 방법입니다. 먼저 현재 DNS 결과를 바꿔야 하는지 판단한 다음 전송 방식 변경 여부를 정하세요.
| 설정 방식 | 적합한 경우 | 변경 전에 확인할 사항 |
|---|---|---|
| 시스템 DNS | 현재 네트워크에서 이름 확인이 정상적으로 작동하거나 회사·학교·가정 내부 도메인에 접속해야 하는 경우 | Wi-Fi 또는 셀룰러 네트워크에서 제공하는 리졸버를 사용할 수 있는지 |
| 사용자 지정 일반 DNS | 고정 리졸버가 필요하고 신뢰할 수 있는 리졸버 주소를 확보한 경우 | 현재 네트워크에서 해당 리졸버에 접속할 수 있고 UDP / TCP 53이 차단되지 않았는지 |
| DNS over HTTPS | DNS 쿼리를 HTTPS로 전송해야 하고 사용 가능한 엔드포인트가 있는 경우 | 엔드포인트 전체 경로, TLS 인증서, 도메인 초기 확인, 연결 경로가 모두 정상인지 |
시스템 DNS는 현재 네트워크의 내부 도메인 확인 기능을 유지하기 쉽습니다. 공용 리졸버는 회사 내부 호스트 이름을 모를 수 있습니다. 고정된 공용 리졸버로 바꾸면 외부 웹사이트는 정상적으로 열리지만 내부 시스템에는 접속할 수 없을 수 있습니다. 이는 이름 확인 범위가 달라진 결과이지, 곧바로 Shadowrocket의 연결 장애를 의미하지는 않습니다.
DoH는 기기와 선택한 DNS 서비스 사이의 DNS 쿼리 전송을 암호화합니다. 리졸버가 쿼리를 볼 수 없게 만드는 것은 아니며, 웹사이트 자체의 HTTPS를 대체하지도 않습니다. 엔드포인트 연결과 TLS 설정 단계가 추가되므로 실제 지연 시간은 네트워크, 연결 재사용, 캐시에 따라 달라집니다. 일반 DNS보다 반드시 빠르다고 할 수는 없습니다.
결론: 내부 도메인에 문제가 생기면 먼저 시스템 DNS로 복구
리졸버를 바꾼 뒤에만 내부 도메인 접속이 실패한다면 먼저 시스템 DNS로 되돌리세요. 서버와 Global Routing은 그대로 둔 채 같은 도메인에 다시 접속해 보세요. 규칙과 프로토콜을 동시에 변경하지 마세요.
3. Config에서 DNS 설정하기 및 복구 지점 보관하기
아래 설명은 iPhone / iPad의 구성 파일 설정을 기준으로 합니다. Config를 열고 현재 활성화된 구성 파일을 찾아 편집 메뉴로 들어간 뒤 General의 DNS Server를 확인하세요. 버전에 따라 편집 메뉴 위치와 항목 배열은 다를 수 있으므로, 텍스트 편집 화면에서 확인할 수 있도록 구성 키 이름도 함께 안내합니다. DNS 엔드포인트를 Home → Add Server의 서버 주소란에 입력하지 마세요.
- Home에서 현재 선택된 서버와 Global Routing 상태를 기록하고, Config에서 활성화된 구성 파일을 확인합니다.
- 복구 지점으로 사용할 수 있도록 구성 파일을 복사하거나 내보냅니다. 사본에서만 DNS를 수정하고 원본은 그대로 보관하세요. 내보낸 파일은 민감한 정보로 취급해야 합니다.
- Config → 현재 구성의 편집 메뉴 → General → DNS Server로 이동합니다. 텍스트 편집 화면을 사용하는 경우
[General]아래에서dns-server를 찾으세요. - 이미 보유한 리졸버 주소나 완전한 DoH 엔드포인트를 입력한 뒤 저장하고, 사본이 활성화되어 있는지 확인합니다. 필요한 경우 연결을 끊었다가 다시 연결해 현재 세션에 설정을 적용하세요.
- 같은 도메인을 대상으로 테스트하고 접속 성공 여부와 오류 유형을 기록하세요. 실패하면 수정 사항을 계속 추가하지 말고 원래 구성으로 되돌리세요.
시스템 DNS 기준 설정
- 위치
- Config → 구성 편집 → General
- 구성 섹션
- [General]
- 구성 키
- dns-server
- 값
- system
시스템 리졸버를 기준으로 삼아 기존 네트워크에서 접속이 되는지 먼저 확인합니다.
DoH 입력 항목
- 프로토콜
- https://
- 호스트 이름
- DNS 서비스에서 지정한 엔드포인트 도메인
- 경로
- 서비스 안내에 명시된 전체 경로 사용
- 기본 포트
- 443
경로 형식만 보고 엔드포인트를 추측하지 마세요. 브라우저에서 페이지가 열리는지만으로 서비스가 정상인지 판단해서도 안 됩니다.
아래 두 항목은 서로 대체해서 사용하는 예시입니다. 하나의 구성에 dns-server를 두 번 선언하라는 뜻이 아닙니다. 두 번째 항목은 문법을 보여 주기 위해 예약된 예시 도메인을 사용하므로 실제 서비스에 사용할 수 없습니다. 실제 설정에는 이미 확보한 DNS 엔드포인트를 사용하세요. 이 문서에서는 특정 DNS 서비스를 추천하지 않습니다.
# 시스템 DNS 기준 설정
[General]
dns-server = system
# DoH 문법 예시: 예시 주소는 직접 사용할 수 없음
[General]
dns-server = https://dns.example.com/dns-query
호스트 이름을 사용하는 DoH 엔드포인트는 초기 이름 확인이 필요합니다. HTTPS 연결을 설정하려면 기기가 먼저 엔드포인트 도메인의 주소를 알아야 합니다. 호스트 이름을 임의로 IP 주소로 바꾸지 마세요. 인증서 이름 확인이나 서비스 라우팅에 실패할 수 있습니다. 현재 네트워크에서 엔드포인트 도메인조차 확인할 수 없다면 작동하는 기준 설정으로 먼저 복구한 뒤 서비스 안내에 따라 초기 이름 확인 문제를 해결하세요.
4. DNS와 규칙 기반 라우팅의 연동 방식
구성 파일의 규칙을 확인하려면 Home에서 Global Routing을 Config로 설정하세요. Proxy와 Direct는 서로 다른 전역 라우팅 상태이므로 그 테스트 결과만으로 특정 구성 규칙이 적용됐다고 입증할 수 없습니다. Scene을 사용하는 경우 실제로 활성화된 Scene과 연결된 설정부터 확인하세요. DNS 변경 전후에 같은 라우팅 상태를 유지해야 결과를 비교할 수 있습니다.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY
DOMAIN-SUFFIX,example.com,PROXY: 해당 도메인과 하위 도메인에 매칭됩니다. 주소의 소재지가 아니라 도메인 이름을 기준으로 판단합니다. 예시 도메인은 서비스 추천을 의미하지 않습니다.IP-CIDR,192.168.0.0/16,DIRECT,no-resolve: 해당 사설 IP 주소 범위에 매칭됩니다.no-resolve는 이 규칙을 위해 도메인 이름 확인을 별도로 시작하지 않는다는 뜻입니다. 대상 주소를 이미 알고 있다면 해당 주소로 매칭할 수 있습니다.GEOIP,CN,DIRECT: 대상 IP의 지리 데이터베이스 분류를 기준으로 합니다. 웹페이지 언어나 도메인 접미사를 기준으로 판단하지 않습니다. 이름 확인 결과가 바뀌면 간접적으로 매칭 결과가 달라질 수 있습니다.FINAL,PROXY: 앞선 규칙에 매칭되지 않을 때 적용하는 기본 정책입니다. 이름 확인 실패를 해결하지 않으며 DNS 쿼리도 동일한 연결 경로를 사용한다고 입증하지 않습니다.
규칙은 위에서 아래 순서로 적용됩니다. 위 예시에서는 먼저 지정된 도메인을 처리하고, 그다음 주소 범위를 확인한 뒤, 마지막으로 기본 정책을 적용합니다. ‘DNS 수정’을 위해 범위가 넓은 규칙을 맨 앞으로 옮기면 뒤쪽의 구체적인 규칙을 가릴 수 있습니다. 예시를 복사하기 전에 현재 구성에서 사용하는 정책 이름을 확인해 기존 정책 그룹을 덮어쓰지 않도록 하세요.
5. 변수를 하나씩 바꿔 DNS 장애 진단하기
테스트를 시작하기 전에 Home에서 기존 서버가 선택되어 있는지 확인한 다음 Connectivity Test를 실행하세요. 이 테스트는 연결 상태를 비교하기 위한 기준일 뿐, 모든 DNS 요청을 검증하지는 않습니다. 테스트에 성공했더라도 리졸버가 잘못된 주소를 반환하거나 규칙이 잘못 매칭되거나 웹사이트 자체에 문제가 있으면 특정 도메인 접속은 실패할 수 있습니다.
- 조건을 고정합니다. 같은 Wi-Fi, 같은 서버, 같은 도메인, 같은 Global Routing 상태를 사용하세요. 테스트 중에는 프로토콜을 바꾸거나 구독을 업데이트하지 마세요.
- 기준 상태를 먼저 테스트합니다. 시스템 DNS 구성을 활성화하고 사이트가 열리는지, 도메인 이름 확인 오류가 표시되는지, 일부 웹사이트에만 문제가 있는지 기록하세요.
- 리졸버만 바꿉니다. 사용자 지정 DNS 또는 DoH 구성을 활성화하고 다시 연결한 뒤 같은 사이트에 접속하세요. 첫 요청과 캐시된 결과를 각각 기록하세요.
- 그다음 네트워크를 바꿉니다. DNS 구성은 그대로 두고 Wi-Fi에서 셀룰러 네트워크로 전환하세요. 한 네트워크에서만 실패한다면 네트워크 인증, 포트 제한, 엔드포인트 접속 가능 여부를 확인하세요.
- 복구 후 다시 확인합니다. 시스템 DNS로 되돌리고 한 번 더 테스트하세요. 한 번 성공한 것만으로 원인을 단정하지 말고 같은 결과가 반복되는지 확인해야 합니다.
| 증상 | 우선 확인할 항목 | 다음 단계 |
|---|---|---|
| 시스템 DNS는 정상이지만 DoH가 계속 시간 초과됨 | 엔드포인트 도메인, 전체 경로, 연결 경로, 네트워크 제한 | 기준 설정으로 복구하고 엔드포인트 안내를 확인한 뒤 단독으로 다시 테스트 |
| 외부 웹사이트는 정상이지만 회사 내부 도메인 접속 실패 | 내부 도메인을 인식하지 못하는 리졸버로 바꿨는지 | 같은 네트워크에서 시스템 DNS로 되돌려 비교 |
| 도메인 주소는 확인됐지만 연결 시간 초과 | 규칙 매칭, 대상 포트, 서버 연결 | 연결 기록에서 실제 적용된 정책을 확인하고 DNS를 무작정 바꾸지 않기 |
| 설정을 변경해도 당장 결과가 달라지지 않음 | 앱 캐시, 기존 연결, 구성 활성화 여부 | 연결을 다시 설정하고 대상 앱을 재실행한 뒤 현재 구성을 확인 |
표는 문제를 진단하기 위한 분기이며, 이 문서에서 실제 속도 측정을 했다는 뜻이 아닙니다. 명령줄 도구로 조회할 때도 어떤 리졸버를 사용하는지 확인하세요. 시스템에서 별도로 실행한 조회 한 번으로 Shadowrocket 내부 요청도 같은 경로를 사용한다고 입증할 수 없습니다. 비교를 위해 HTTPS 웹사이트 주소를 IP 주소로 바꾸는 것도 피하세요. 인증서와 가상 호스트 차이로 결과가 달라질 수 있습니다.
6. 자주 묻는 질문과 설정 보존 원칙
DoH 설정 후 모든 웹페이지가 열리지 않으면 무엇부터 바꾸나요?
먼저 Config에서 보관해 둔 시스템 DNS 구성으로 되돌리고 다시 연결한 다음 기존에 접속하던 사이트를 열어 보세요. 정상으로 돌아오면 DoH 엔드포인트의 프로토콜, 도메인, 경로, 포트를 확인하세요. 서버를 동시에 변경하지 마세요. 복구 후에도 문제가 계속되면 Home에서 연결 상태와 Global Routing을 확인하세요.
브라우저에서 DoH 주소가 열리면 설정이 올바른 건가요?
아닙니다. DoH 엔드포인트는 정해진 형식의 DNS 요청을 처리합니다. 일반 브라우저로 접속하면 오류 상태가 반환되거나 안내 페이지가 표시될 수도 있습니다. 페이지에 내용이 보이는지만 판단하지 말고 클라이언트의 실제 이름 확인 결과, 연결 기록, 서비스 제공자의 엔드포인트 안내를 함께 확인하세요.
Wi-Fi를 바꾸면 DNS 결과가 달라지는 이유는 무엇인가요?
시스템 리졸버는 네트워크에 따라 달라질 수 있으며, 엔드포인트 접속 가능 여부와 내부 도메인 범위도 다를 수 있습니다. 같은 구성을 사용해 Wi-Fi와 셀룰러 네트워크의 결과를 비교하세요. 연결 스위치까지 자동으로 바뀐다면 Settings → On Demand의 트리거 조건을 확인해 자동 연결 동작을 DNS 문제로 오인하지 않도록 하세요.
구독 업데이트 후 수정한 DNS 설정이 원래대로 돌아가면 어떻게 하나요?
먼저 서버 구독 업데이트와 원격 구성 파일 업데이트를 구분하세요. 전자는 주로 서버 항목을 업데이트하고, 후자는 구성 내용을 대체할 수 있습니다. Config에서 현재 활성화된 파일의 출처를 확인하고 로컬 사본을 보관한 뒤 업데이트 후 dns-server 값을 점검하세요. 인증 정보가 포함된 전체 구성을 공개 페이지에 붙여 넣지 마세요.
안정적인 설정은 필요한 도메인의 이름을 확인할 수 있고, 연결에 예상한 정책이 적용되며, 자주 사용하는 네트워크에서 결과를 반복해 확인할 수 있고, 복구 방법도 보관된 상태를 말합니다. 시스템 DNS가 이 조건을 충족한다면 설정을 바꾸기 위해 굳이 변경할 필요는 없습니다. DoH가 필요하다면 효과를 구분하기 어려운 옵션을 한꺼번에 추가하지 말고, 사용 가능한 것으로 확인된 엔드포인트 하나부터 시작하세요.