Shadowrocket 지연은 정상인데 웹페이지가 열리지 않을 때: DNS 조회 실패 원인과 DNS 설정

핵심 내용

Shadowrocket에 이용 중인 서비스 제공업체의 설정을 가져왔지만 연결 후에도 웹페이지가 열리지 않는 경우에 참고하세요. 먼저 지연 시간 테스트와 도메인 조회를 구분하고, Global Routing, 현재 Config의 DNS, 로컬 네트워크를 차례로 확인합니다. 한 번에 한 항목만 변경한 뒤 같은 URL로 다시 테스트하고, 오류 유형에 따라 DNS, 규칙 또는 연결 설정을 점검하세요.

1. 지연 시간이 정상이어도 웹 요청이 성공한 것은 아닙니다

웹페이지를 열 때는 일반적으로 도메인 조회, 연결 설정, TLS 핸드셰이크, HTTP 요청이 차례로 진행됩니다. Home에 표시되는 지연 시간은 해당 테스트의 대상과 방식에 따른 결과일 뿐, 모든 웹사이트의 도메인 조회나 서버 인증, 전송 설정, 페이지 응답이 정상임을 보장하지 않습니다. 테스트에 성공했더라도 브라우저가 도메인 조회 단계에서 멈출 수 있습니다. 반대로 웹페이지가 열리지 않는 원인이 연결이나 TLS 문제일 수도 있으므로, 지연 시간만으로 DNS 장애라고 단정할 수 없습니다.

먼저 접속에 실패한 URL의 전체 도메인, 발생 시간, 현재 서버, Global Routing 모드, 네트워크 유형을 기록하세요. 이전에 접속할 수 있었던 페이지와 비교하되, 여러 웹사이트와 서버, DNS를 연달아 바꾸지 마세요. 어떤 변경이 결과에 영향을 주었는지 알 수 없게 됩니다. 아래 증상은 원인을 좁히기 위한 단서이므로, 이후 재검사로 확인해야 합니다.

확인할 증상	우선 점검할 항목	이 증상만으로 단정할 수 없는 점
여러 도메인에서 서버를 찾을 수 없다는 메시지가 표시됨	DNS 조회가 시간 초과되었는지, 현재 리졸버에 연결할 수 있는지	메시지만으로 서버가 응답하지 않는다고 단정할 수 없음
특정 도메인만 열리지 않음	도메인 철자, 해당 도메인의 DNS 레코드, 적용된 규칙	모든 DNS 설정이 잘못되었다고 단정할 수 없음
대상 IP를 확인한 뒤 연결 시간 초과	아웃바운드 경로, 포트, 서비스 제공업체의 설정	연결 시간 초과와 DNS 조회 시간 초과는 다름
인증서 또는 보안 연결 관련 메시지가 표시됨	기기의 시간, TLS 호스트명, 대상 웹사이트	DNS를 바꾼다고 반드시 해결되는 것은 아님

2. DNS 설정 항목별 역할

DNS는 도메인 이름을 연결 가능한 주소로 변환합니다. 시스템 DNS는 보통 현재 Wi-Fi 또는 셀룰러 네트워크에서 제공됩니다. Config의 dns-server는 Shadowrocket에서 사용할 리졸버를 지정합니다. 두 설정은 같은 수준에서 작동하는 옵션이 아닙니다. 브라우저의 암호화 DNS, 규칙, 연결 방식에 따라 실제 조회 경로가 달라질 수 있으므로, 특정 리졸버 주소를 입력해도 모든 요청이 반드시 그 리졸버를 거치는 것은 아닙니다.

설정 또는 개념	역할	점검할 내용
`dns-server`	Config의 `[General]`에서 DNS 리졸버 지정	철자와 형식, 리졸버 연결 가능 여부를 확인하고 현재 Config에서 실제로 사용 중인지 먼저 확인
`system`	시스템에서 제공하는 DNS 사용	Wi-Fi와 셀룰러 네트워크를 전환하면 시스템 DNS가 달라질 수 있음
DNS over HTTPS	HTTPS를 통해 DNS 조회 전송	리졸버의 도메인도 먼저 조회해야 할 수 있으며, HTTPS 연결 가능 여부도 중요함
A / AAAA	IPv4 / IPv6 주소 레코드를 각각 반환	AAAA 레코드가 있어도 현재 IPv6 아웃바운드 경로를 사용할 수 있다는 뜻은 아님
캐시와 TTL	일정 시간 동안 조회 결과 재사용	설정을 변경한 직후 이전 결과가 표시되어도 변경이 적용되지 않았다고 단정할 수 없음

기존 DNS에서 일반적으로 사용하는 UDP / TCP 포트

443

DNS over HTTPS에서 일반적으로 사용하는 HTTPS 포트

2가지

주소 레코드: A는 IPv4, AAAA는 IPv6

점검 방법: 먼저 연결 가능 여부를 확인한 뒤 리졸버 변경

기존 DNS 조회가 시간 초과되지만 HTTPS 연결은 정상이라면, 신뢰할 수 있는 기존 출처에서 제공한 DNS over HTTPS 설정을 테스트해 볼 수 있습니다. HTTPS 연결도 되지 않는다면 리졸버 목록을 늘리는 대신 네트워크와 연결 경로부터 점검하세요.

포트 번호는 해당 프로토콜에서 흔히 쓰는 값이며, 서버 설정에 일괄적으로 입력해야 하는 값은 아닙니다. DNS 포트와 기존 서버의 연결 포트는 서로 독립적입니다. DNS 조회 문제를 점검한다고 Home의 서버 Port를 53으로 바꾸지 마세요.

3. 되돌릴 수 있도록 순서대로 점검하기

시작하기 전에 현재 Config를 복사하고 기존 DNS 행을 기록해 두세요. Config가 이용 중인 구독으로 관리된다면 나중에 업데이트할 때 로컬 변경 사항이 덮어써질 수 있습니다. 점검용 복사본은 원본과 구분하세요. 비밀번호, UUID, 구독 토큰, 전체 서버 주소가 포함된 Config를 공개하지 마세요.

현재 상태 기록

Home에서 현재 서버와 연결 상태를 기록합니다. Home → Global Routing을 열어 현재 옵션을 적고, Safari에서 접속에 실패한 URL을 열어 실제 메시지와 테스트 시간을 기록하세요.
네트워크 확인

연결을 잠시 끊고 현재 Wi-Fi에서 네트워크 로그인이 필요한지 확인하세요. 네트워크를 비교하려면 Wi-Fi와 셀룰러 네트워크에서 같은 URL을 각각 테스트합니다. 셀룰러 데이터 사용 시 요금이 발생할 수 있습니다.
모드별 결과 비교

Home → Global Routing에서 Config 모드의 실패 결과를 기록한 다음, 잠시 Proxy로 전환해 테스트합니다. 결과가 달라진다면 규칙과 아웃바운드 경로를 먼저 확인하세요. 이것만으로 DNS 문제가 완전히 해결되었다고 단정하지 마세요.
Config 확인

Config로 돌아가 현재 활성화된 파일을 확인한 뒤, 해당 파일의 편집 화면에서 [General]의 dns-server를 점검합니다. 복사본에서 이 항목만 변경하고 서버 인증이나 전송 설정은 동시에 바꾸지 마세요.
다시 테스트

변경한 Config를 저장하고 실제로 사용 중인지 확인한 다음, 연결을 끊었다가 다시 연결해 같은 URL에 접속합니다. 다시 연결해도 모든 앱 캐시가 지워지는 것은 아닙니다. 필요한 경우 브라우저를 완전히 종료했다가 다시 열고 결과가 일관되게 달라졌는지 기록하세요.
설정 복원

Global Routing을 원래 값으로 되돌립니다. 테스트 중 연결이 자동으로 복구되었다면 Settings → On Demand에서 기존 설정을 확인하세요. 수동 연결 테스트를 위해 잠시 끈 경우, 테스트가 끝난 뒤 원래 필요에 맞게 다시 설정합니다.

아래는 시스템 DNS를 사용하는 최소 설정 예시입니다. 필드 위치를 이해하기 위한 것으로, 실제 연결에 필요한 전체 설정은 아닙니다. 편집할 때는 기존 항목을 수정하고 테스트를 위해 [General] 섹션을 중복해서 추가하거나 Config의 다른 필수 설정을 덮어쓰지 마세요. 시스템 DNS에 연결할 수 없는 경우도 있으므로 이 예시가 모든 상황에 적용되는 해결책은 아닙니다.

[General]
dns-server = system

4. 오류 메시지로 DNS 조회 실패 유형 구분하기

아래에는 DNS 도구나 진단 기록에서 흔히 볼 수 있는 응답 코드와 오류 문구를 정리했습니다. Shadowrocket의 모든 화면에 이 문구가 그대로 표시된다는 뜻은 아닙니다. 브라우저의 “서버를 찾을 수 없음” 메시지만으로는 NXDOMAIN과 시간 초과를 구분할 수 없습니다. 구체적인 조회 결과를 확인한 뒤 해당 항목에 따라 점검하세요.

오류: NXDOMAIN

원인 및 해결 방법: 리졸버가 도메인이 존재하지 않는다고 응답했습니다. 먼저 도메인 철자와 하위 도메인을 확인한 뒤, 연결 가능한 다른 리졸버에 같은 도메인을 조회해 보세요. 여러 리졸버에서 같은 결과가 나오면 대상 웹사이트 관리자에게 레코드를 확인해 달라고 요청하세요.

오류: SERVFAIL

원인 및 해결 방법: 리졸버가 조회를 완료하지 못했습니다. 상위 DNS 서버 장애나 DNSSEC 검증 문제일 수 있습니다. 도메인, 리졸버, 발생 시간을 기록하고 연결 가능한 다른 리졸버와 비교하세요. 이 오류를 도메인이 반드시 존재하지 않는다는 뜻으로 해석하면 안 됩니다.

오류: REFUSED

원인 및 해결 방법: 리졸버가 이번 조회를 거부했습니다. 재귀 조회 요청이 들어온 네트워크를 제한하고 있을 수 있습니다. 해당 리졸버를 현재 네트워크에서 사용할 수 있는지 확인하고, 시스템 DNS나 사용 권한이 있는 리졸버로 바꿔 다시 테스트하세요.

오류: DNS query timed out

원인 및 해결 방법: 정해진 시간 안에 조회 응답을 받지 못했습니다. 리졸버 주소와 조회 경로, 현재 네트워크에서 UDP / TCP 53에 연결할 수 있는지 확인하세요. 네트워크를 바꿔 테스트할 때는 다른 설정을 그대로 유지해 변수를 추가하지 마세요.

5. DNS가 정상이라면 규칙과 주소 체계 점검

Global Routing의 Proxy, Direct, Config, Scene은 요청 처리 방식을 선택하는 옵션입니다. Proxy와 Direct는 비교 테스트에 사용할 수 있고, Config는 현재 Config에 따라 처리하며, Scene은 설정된 장면에 따라 실제 처리 방식을 결정합니다. 이를 네 가지 DNS 스위치로 이해하면 안 됩니다. 모드를 바꾼 뒤 결과가 달라졌다면 해당 요청에 적용된 규칙과 아웃바운드 경로도 확인하세요.

DOMAIN-SUFFIX는 도메인 접미사로, IP-CIDR은 IP 주소 대역으로, GEOIP은 IP 지리 데이터베이스로 요청을 매칭합니다. FINAL은 앞선 규칙에 매칭되지 않은 요청을 처리합니다. 도메인 규칙은 도메인 자체를 비교하므로 대상 IP를 먼저 조회할 필요가 없습니다. IP 규칙은 주소 조회가 필요할 수 있으며, 실제 동작은 규칙 옵션에 따라서도 달라집니다. 아래는 문법 예시일 뿐이므로 기존 규칙을 그대로 덮어쓰지 마세요.

[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를 전역적으로 끄는 설정은 아닙니다.
규칙 순서에 따라 적용 결과가 달라질 수 있습니다. Config에서는 특정 도메인에 접속할 수 없지만 Proxy에서는 가능하다면, 앞선 규칙이 해당 도메인을 다른 경로로 보내는지 먼저 확인하세요.
A 레코드는 사용할 수 있지만 AAAA에 해당하는 경로에서 실패한다면 현재 네트워크와 서버의 IPv6 지원을 확인하세요. 기존 값을 기록한 후 IPv4만 사용하는 비교 테스트를 할 수 있지만, IPv6를 끄는 것이 모든 문제의 해결책은 아닙니다.
서버 주소를 도메인으로 입력한 경우에도 DNS 조회가 필요합니다. 서버 주소를 IP로 바꾸면 TLS 검증, SNI, 서비스 제공업체의 서버 배정에 영향을 줄 수 있으므로 해당 업체에서 제공한 설정을 따르세요.

6. 자주 묻는 질문과 점검 완료 기준

DNS를 바꿨는데도 웹페이지가 열리지 않는 이유는 무엇인가요?

먼저 Config에서 수정한 파일을 실제로 사용 중인지 확인한 뒤, DNS 조회 결과로 주소를 받았는지 점검하세요. 주소를 받았는데 연결이 시간 초과된다면 Home으로 돌아가 서버 설정과 Global Routing을 확인하세요. DNS를 계속 바꾸지는 마세요.

Wi-Fi에서만 문제가 생기고 셀룰러 네트워크에서는 정상이라면 어떻게 해야 하나요?

서버, Config, URL은 그대로 둔 채 먼저 Wi-Fi 네트워크 로그인을 완료하고 해당 네트워크가 제공하는 시스템 DNS를 확인하세요. 그 네트워크에서만 특정 리졸버에 연결할 수 없다면 비교 결과를 저장하고 네트워크 관리자에게 제한 여부를 문의하세요.

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

반드시 그렇지는 않습니다. 주소를 여러 개 입력한다고 모든 조회가 원하는 결과를 얻는 것은 아닙니다. 출처가 분명하고 현재 네트워크에서 연결할 수 있는 DNS 하나를 우선 사용해 문제가 발생한 도메인을 확인하세요. 복구된 뒤 필요에 따라 다른 리졸버를 추가할지 결정하면 됩니다.

구독을 업데이트한 뒤 문제가 다시 생기면 어떻게 하나요?

Config에서 업데이트 전후의 DNS와 규칙을 비교해 업데이트가 로컬 변경 사항을 덮어썼는지 확인하세요. 구체적인 항목과 오류 발생 시간을 이용 중인 서비스 제공업체에 전달하되 전체 구독 토큰은 보내지 마세요. 되돌릴 수 있도록 테스트용 복사본과 원본 파일을 보관하세요.

점검을 마치려면 세 가지를 확인하세요. 같은 URL에 반복해서 접속할 수 있고, Global Routing이 평소 사용하는 모드로 복원되었으며, 다시 연결한 뒤에도 결과가 일관되어야 합니다. “Wi-Fi에서 시스템 DNS 조회가 시간 초과되어 테스트용 Config를 수정한 뒤 복구되었고, Config 모드에서도 재확인됨”처럼 간단히 기록하세요. “DNS를 바꾸니 해결됨”이라고만 적는 것보다 이후 네트워크 문제와 Config 덮어쓰기 문제를 구분하는 데 도움이 됩니다.

문제를 문의할 때는 실패한 도메인, 발생 시간, Wi-Fi 또는 셀룰러 네트워크 여부, Global Routing 옵션, 개인정보를 가린 오류 원문을 제공하세요.
DNS 조회로 주소는 받았지만 이후 핸드셰이크가 실패한다면, 이용 중인 서비스 제공업체가 안내한 Port, TLS, 전송 설정을 확인하세요.
변경해도 문제가 해결되지 않으면 저장해 둔 원본 Config를 복원하고, 임시 테스트 설정을 장기간 사용하지 마세요.