Shadowrocket DNS 오류 해결 방법: 지연 시간은 정상인데 웹페이지가 열리지 않을 때

핵심 내용

지연 시간이 표시된다고 웹 접속 경로가 모두 정상이라는 뜻은 아닙니다. 기존에 이용 중인 서버와 구독이 있고 Shadowrocket 연결도 되지만 웹페이지가 열리지 않는다면, 먼저 실패한 도메인과 현재 네트워크를 기록한 뒤 DNS 응답, DNS 요청 경로, Global Routing을 차례로 확인하세요. 각 단계에서 변수를 하나씩 비교하면 도메인 미존재, DNS 시간 초과, 규칙 분기 오류, 웹사이트 연결 문제를 구분하는 데 도움이 됩니다.

지연 시간 정상은 테스트 대상이 응답했다는 의미일 뿐

Shadowrocket의 지연 시간 테스트와 브라우저로 웹페이지를 여는 작업은 서로 다릅니다. 테스트 방식에 따라 확인 범위도 달라집니다. 연결 포트에서 응답을 받았더라도 프록시 인증, 대상 도메인 확인, TLS 핸드셰이크, 웹 리소스 로딩까지 성공했다고 볼 수는 없습니다. HTTP 요청이 포함된 테스트라도 당시 테스트 대상에 접속할 수 있었다는 뜻일 뿐, 실제로 접속에 실패한 웹사이트를 확인해 주지는 않습니다.

도메인 확인 규칙 판정 외부 연결 TLS 핸드셰이크 웹페이지 로딩

이 흐름은 접속에 필요한 주요 단계를 나타내며, 모든 프로토콜이 반드시 이 순서대로 작동한다는 뜻은 아닙니다. 프록시 서버 주소가 도메인이라면 서버 주소도 먼저 확인해야 합니다. 대상 웹사이트의 도메인은 원격에서 확인될 수도 있습니다. 따라서 먼저 문제가 ‘서버 주소’와 ‘웹페이지 주소’ 중 어디에서 발생했는지 구분한 다음 수정할 항목을 정하세요.

모든 웹사이트가 열리지 않는 경우: 연결이 성립했는지, 프록시 서버 주소를 확인할 수 있는지, 현재 네트워크에서 웹 로그인이 필요한지 먼저 확인하세요.
특정 도메인 하나만 열리지 않는 경우: 전체 호스트명을 기록하고 철자, DNS 응답 상태, 해당 도메인에 적용되는 규칙을 확인하세요.
페이지의 텍스트는 보이지만 이미지가 표시되지 않는 경우: 이미지 등 페이지 리소스가 사용하는 다른 도메인도 확인하세요. 주소 표시줄의 도메인만 확인해서는 부족합니다.

상황을 기록한 뒤 최소한의 조건으로 비교하기

문제를 확인하는 동안 기존 설정을 유지하고 서버, DNS, 규칙을 한꺼번에 바꾸지 마세요. 아래 절차는 iPhone을 기준으로 설명하며 iPad에서도 같은 방식으로 진행할 수 있습니다. 테스트에는 사용자가 이미 보유한 서버와 구독을 사용하세요. 구독 업데이트에 성공했다는 것은 구독 주소를 읽을 수 있다는 뜻일 뿐, 구독에 포함된 모든 서버나 모든 웹사이트에 접속할 수 있다는 의미는 아닙니다.

Home에서 현재 선택된 서버, 연결 스위치 상태, Global Routing 선택 항목을 기록하세요. Config에서는 현재 활성화된 구성 파일을 확인하세요.
접속에 실패한 URL의 호스트명, 발생 시각, Wi-Fi 또는 셀룰러 네트워크 사용 여부, 브라우저에 표시된 실제 안내 문구를 기록하세요. 기록을 공유하기 전에는 구독 주소, 암호, 토큰을 가리세요.
연결을 끄고 현재 로컬 네트워크에서 일반적으로 바로 접속할 수 있는 웹사이트를 테스트하세요. 이 사이트도 열리지 않으면 먼저 로컬 네트워크나 웹 로그인 인증을 확인하세요.
같은 서버에 다시 연결한 뒤 같은 웹사이트에 접속하세요. 설정을 변경할 때마다 이전 웹페이지 탭을 닫고 새 탭에서 테스트해 기존 연결의 영향을 줄이세요.
필요하다면 Wi-Fi와 셀룰러 네트워크를 한 번씩 비교하되, DNS 설정은 동시에 바꾸지 마세요. 네트워크를 전환했을 때 차이가 나는지 보면 로컬 라우터나 통신망의 영향을 파악하는 데 도움이 됩니다.

DNS 설정별 역할

Settings → DNS에서 앱의 DNS 설정을 확인한 다음 Config에서 현재 구성의 [General]을 살펴보세요. 구성에 따라 DNS 서버, 확인 방식, 도메인별 지정 결과가 함께 적용될 수 있습니다. 현재 활성화된 구성을 확인해야 합니다. 입력란에 주소가 있다는 이유만으로 모든 요청이 해당 주소를 이용한다고 단정하지 마세요.

항목	역할	확인할 점
System DNS	현재 시스템이나 네트워크에서 제공하는 DNS 서비스를 사용합니다.	Wi-Fi를 바꾸면 DNS 환경도 달라질 수 있습니다. 고정된 공용 DNS 주소를 뜻하는 것은 아닙니다.
`dns-server`	구성 파일에 지정된 DNS 서버를 사용합니다.	주소가 입력되어 있는지만 보지 말고 주소의 철자와 형식, 요청이 서버에 도달하는지도 확인하세요.
DNS over HTTPS	HTTPS로 DNS 조회를 전송하며 일반적으로 TCP 443을 사용합니다.	서비스 엔드포인트에 접속할 수 있어야 하고 인증서 검증도 성공해야 합니다. 엔드포인트가 도메인을 사용한다면 최초 도메인 확인도 필요합니다.
일반 DNS	일반적으로 UDP 53을 사용하며, 경우에 따라 TCP 53을 사용합니다.	현재 네트워크에서 관련 트래픽을 제한하는지, 요청이 시간 초과되는지 확인하세요. 웹사이트 접속에 쓰이는 포트 443은 별도의 연결입니다.
`[Host]`	지정한 호스트명에 고정 주소를 연결합니다.	오래된 주소가 정상적인 DNS 확인을 우회해 도메인은 확인되지만 웹사이트 연결은 실패할 수 있습니다.

예를 들어 구성의 다음 줄은 시스템 DNS를 사용한다는 뜻입니다. 문법을 보여 주기 위한 예시이며, 기존 구성을 덮어쓸 완성 파일이 아닙니다. 수정 전에 원래 값을 저장하세요. 사용 중인 서비스에서 받은 구성이라면 일부를 테스트하기 전에 DNS 관련 안내를 먼저 확인하세요.

[General]
dns-server = system

결론: DNS 변수는 한 번에 하나씩 바꾸기

서버, Global Routing, 대상 도메인은 그대로 두고 기존 DNS 설정과 시스템 DNS만 비교하세요. 설정을 바꿀 때마다 문제가 일관되게 재현된다면 DNS 서비스와 요청 경로를 추가로 확인하세요.

응답 상태로 DNS 오류 유형 구분하기

브라우저의 ‘서버를 찾을 수 없음’ 안내만으로는 원인을 특정하기 어렵습니다. 확인할 수 있는 연결 기록이나 진단 출력에서 DNS 응답 상태, 조회 도메인, 시간 초과 정보를 살펴보세요. 아래는 일반적인 DNS 상태 또는 진단 용어이며, Shadowrocket의 모든 화면에 이 문구가 그대로 표시된다는 뜻은 아닙니다.

오류: NXDOMAIN

원인 및 해결: DNS 확인 서버가 조회한 도메인이 존재하지 않는다고 응답했습니다. 전체 호스트명과 철자를 먼저 확인한 뒤 다른 DNS 확인 경로와 비교해 실제로 존재하지 않는 도메인인지, 특정 확인 서버에서만 잘못된 응답을 받는지 구분하세요.

오류: SERVFAIL

원인 및 해결: DNS 확인 서버가 조회를 완료하지 못했습니다. 상위 DNS 서버 장애나 검증 실패가 원인일 수 있습니다. 도메인과 발생 시각을 기록하고 접속 가능한 다른 DNS 경로로 다시 확인하세요. 문제가 계속되면 기록을 사용 중인 서비스 제공업체에 전달하세요.

오류: timeout

원인 및 해결: 정해진 시간 안에 DNS 응답을 받지 못했습니다. DNS 서버 주소와 전송 경로를 확인한 뒤, 같은 설정으로 Wi-Fi와 셀룰러 네트워크를 바꿔 테스트해 특정 네트워크에서만 시간 초과가 발생하는지 확인하세요.

‘AAAA 레코드가 없음’과 ‘도메인이 존재하지 않음’은 구분해야 합니다. AAAA는 IPv6 주소, A는 IPv4 주소를 나타냅니다. 도메인에 A 레코드만 있어도 반드시 문제가 있는 것은 아닙니다. 주소가 응답으로 왔는데 이후 연결이 멈춘다면 DNS를 계속 바꾸기보다 주소 체계별 연결 가능 여부, 라우팅, TLS를 확인하세요.

조회한 레코드 유형이 A, AAAA 또는 다른 유형인지 기록하세요. 서로 다른 조회 결과를 그대로 비교하지 않도록 합니다.
사설 주소나 예상과 다른 주소가 반환되면 먼저 로컬 네트워크의 용도와 고정 주소 매핑을 확인하세요. 주소 모양만 보고 결론 내리지 마세요.
‘HTTPS 주소를 IP 주소로 바꾸기’를 유일한 확인 방법으로 사용하지 마세요. 인증서, SNI, 가상 호스트가 원래 도메인에 의존할 수 있습니다.

Global Routing으로 DNS 문제와 규칙 문제 구분하기

Home → Global Routing에서 Config는 현재 구성에 따라 트래픽을 처리하고, Proxy는 해당 트래픽을 프록시로 보내며, Direct는 해당 트래픽을 직접 연결합니다. 모드를 바꿔 비교하면 원인 파악에 도움이 될 수 있지만, 이는 DNS만 바꾸는 기능이 아닙니다. 대상 연결 경로나 원격에서 도메인을 확인할 기회도 함께 달라질 수 있습니다.

먼저 Config 상태에서 접속 실패를 재현하고 도메인과 적용된 규칙 또는 정책을 기록하세요.
같은 서버를 유지한 채 잠시 Proxy로 전환해 같은 도메인에 다시 접속하세요. 접속이 되면 Config의 분기 규칙과 선택된 정책을 우선 확인하되, DNS가 반드시 정상이라고 단정하지는 마세요.
현재 로컬 네트워크에서 일반적으로 바로 접속할 수 있는 대상이라면 잠시 Direct로 비교하세요. 대상 자체가 로컬 네트워크에서 접속되지 않는 경우, Direct 연결 실패만으로 DNS 설정이 잘못됐다고 볼 수는 없습니다.
비교 테스트를 마친 뒤 원래 모드로 되돌리세요. Scene을 사용한다면 비교에 영향을 주지 않도록 현재 Scene에서 어떤 연결 동작이 선택되어 있는지 먼저 확인하세요.

아래는 규칙 문법 예시입니다. example.com은 예시 도메인이며 진단 서비스가 아닙니다. DOMAIN-SUFFIX는 도메인 접미사를, IP-CIDR은 주소 대역을, GEOIP는 IP의 지리적 위치를 기준으로 일치 항목을 찾습니다. FINAL은 앞선 규칙과 일치하지 않은 요청을 처리합니다. 규칙은 순서대로 확인되며, 주소 기반 규칙에는 DNS 응답 결과가 영향을 줄 수 있으므로 마지막 줄만 확인해서는 안 됩니다.

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

no-resolve는 해당 주소 규칙과 일치시키기 위해 도메인 확인을 추가로 실행하지 않도록 합니다. 모든 DNS 문제를 해결하는 옵션은 아닙니다. 도메인에 앞선 규칙이 적용되어 사용할 수 없는 경로로 전송된다면 DNS를 바꿔도 결과가 달라지지 않을 수 있습니다. 먼저 적용된 규칙을 확인한 뒤 해당 규칙의 정책이나 위치를 조정하세요.

자주 묻는 질문: 캐시, 구독, 연결 복구

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

먼저 변경한 설정이 현재 활성화된 구성에 적용됐는지 확인한 다음 연결을 다시 설정하고 새 탭에서 웹페이지를 여세요. 앱과 시스템에 캐시나 기존 연결이 남아 있을 수 있습니다. 주소 응답을 받았는데도 접속에 실패한다면 규칙, 외부 연결, TLS를 확인하고 DNS 주소를 계속 추가하지 마세요.

구독이 업데이트되면 DNS에도 문제가 없다는 뜻인가요?

아닙니다. 구독 주소, 프록시 서버, 대상 웹사이트는 서로 다른 도메인과 경로를 사용할 수 있습니다. Home에서 구독 업데이트 결과와 서버 상태를 각각 확인한 뒤, 접속되지 않는 호스트명을 따로 점검하세요. 새로운 변수가 생기지 않도록 기존 구성은 그대로 두세요.

Wi-Fi에서만 실패하면 서버를 바꿔야 하나요?

서버와 DNS는 그대로 둔 채 셀룰러 네트워크로 전환해 다시 테스트하세요. 해당 Wi-Fi에서만 실패한다면 웹 로그인 인증, 라우터가 제공하는 DNS, 네트워크 제한을 확인하세요. 원인을 파악하기 전에는 프로토콜과 서버를 함께 바꿀 필요가 없습니다.

인증서 오류도 DNS 오류인가요?

반드시 그렇지는 않습니다. 인증서 오류는 보통 TLS 확인 단계까지 진행됐다는 의미입니다. 기기의 날짜와 시간, 대상 도메인, 인증서가 서로 일치하는지 확인하세요. 잘못된 주소로 연결돼 인증서 오류가 발생할 수도 있지만, 인증서 검증을 무시해 문제를 가리면 안 됩니다.

복구 후 같은 조건으로 다시 테스트하기

웹페이지가 한 번 열렸다고 문제가 해결됐다고 단정할 수는 없습니다. 복구 후에는 처음 실패한 네트워크, 원래 대상 도메인, 평소 사용하던 모드에서 다시 테스트하고 페이지에 딸린 리소스까지 제대로 로드되는지 확인하세요. 문제 해결 기록에는 설정을 몇 개 바꿨는지가 아니라 ‘어떤 변수를 바꾼 뒤 복구됐는지’를 남기는 것이 중요합니다.

연결 설정 복구: 임시로 변경한 Global Routing을 원래대로 되돌리고, Settings → On Demand도 기존 사용 방식에 맞게 복구하세요.
구성 확인: Config에서 올바른 파일이 활성화되어 있는지 확인하고, 테스트용으로 추가했지만 더 이상 필요하지 않은 고정 주소 매핑이나 임시 규칙을 삭제하세요.
기록 보관: 네트워크 유형, 실패한 도메인, DNS 응답 상태, 변경 항목, 재테스트 결과를 기록하세요. 사용 중인 서비스 제공업체에 전달할 때는 계정 정보를 가리세요.
다음 점검 단계 확인: 올바른 주소가 반환되고 DNS 응답도 정상인데 연결할 수 없다면 서버 상태, 대상 포트, TLS를 계속 확인하세요. 모든 실패를 도메인 확인 문제로 돌리지 마세요.

결론: 실패한 단계에 따라 다음 조치 결정하기

응답이 없으면 DNS 요청 경로를 확인하고, 도메인이 존재하지 않는다는 응답이 명확하면 도메인을 확인하세요. 주소가 반환되면 연결과 규칙을 점검하세요. 각 단계의 비교 결과를 기록해야 설정을 반복해서 덮어쓰는 일을 피할 수 있습니다.