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

이 글의 핵심

Shadowrocket의 지연 시간은 해당 테스트 경로만 보여 주며, 웹페이지 도메인이 정상적으로 조회되었음을 의미하지는 않습니다. 이미 이용 중인 서비스 제공업체와 구독 설정이 있고 연결 후 웹페이지가 열리지 않는다면 로컬 네트워크, 현재 Config의 DNS, Global Routing, 요청 기록을 차례로 확인하세요. 한 번에 한 항목씩 변경하고 조회 결과와 연결 단계로 문제 위치를 파악합니다.

1. 지연 시간이 정상이어도 웹 요청은 실패할 수 있습니다

먼저 선택한 서버에 연결하는 것과 대상 웹사이트에 접속하는 것을 구분해야 합니다. 지연 시간 테스트는 서버 연결이나 지정된 테스트 주소까지만 확인할 수 있습니다. Safari에서 웹페이지를 열려면 대상 도메인 조회, 아웃바운드 정책 선택, 연결 설정, TLS 핸드셰이크까지 완료되어야 합니다. 앞 단계가 응답하더라도 이후 단계에서 실패할 수 있습니다. 따라서 지연 시간이 표시되더라도 네트워크 전체가 정상이라고 단정하지 말고 DNS를 우선 확인하세요.

도메인 조회 규칙 매칭 아웃바운드 연결 TLS 핸드셰이크 웹페이지 응답

이 흐름은 문제 해결 단계를 나누기 위한 것으로, 모든 연결에서 내부 처리가 반드시 이 순서로 진행된다는 뜻은 아닙니다. 도메인 규칙이 먼저 매칭에 관여할 수 있고, 일부 IP 규칙은 주소를 조회해야 적용됩니다. 실제로 확인할 때는 ‘IP 주소를 받았는지’, ‘최종적으로 어떤 정책을 사용했는지’, ‘연결이 어느 단계에서 실패했는지’를 각각 기록하세요. 인증서 오류나 HTTP 상태 코드가 표시된다면 단순한 DNS 무응답만의 문제는 아닐 가능성이 큽니다.

일반 DNS에서 주로 사용하는 UDP / TCP 포트

443

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

A / AAAA

각각 IPv4 / IPv6 주소 레코드

포트 설명은 서비스에서 일반적으로 사용하는 방식에 관한 것이며, 라우터에서 인바운드 포트를 열어야 한다는 뜻은 아닙니다. A 또는 AAAA 레코드를 받았더라도 잘못된 주소가 반환되거나 IPv6 경로에 연결할 수 없거나 이후 포트가 제한되면 웹페이지가 열리지 않을 수 있습니다.

2. 로컬 네트워크와 현재 설정의 기준 상태 확인

설정을 변경하기 전에 현재 설정을 복사해 두고, 문제가 발생한 전체 도메인, 사용 중인 Wi-Fi 또는 셀룰러 네트워크, Global Routing의 현재 옵션, 오류 발생 시각을 기록하세요. 같은 웹페이지로 테스트하고, 현재 네트워크에서 원래 접속할 수 있었던 웹페이지도 비교 대상으로 준비합니다. 한 웹사이트만 확인하면 해당 사이트의 장애를 모든 DNS 요청의 실패로 오해하기 쉽습니다.

자동 연결 일시 중지

Settings → On Demand에서 현재 활성화 상태와 조건을 기록한 뒤, 문제를 확인하는 동안 잠시 비활성화합니다. 그런 다음 Home에서 연결을 끊어, 연결 해제 직후 On Demand 조건에 따라 다시 연결되지 않도록 합니다.
기본 네트워크 확인

연결을 끊은 상태에서 Safari로 비교용 웹페이지에 접속합니다. 공용 Wi-Fi에서 인증이 필요하다면 먼저 네트워크에 로그인하세요. 기본 네트워크에서도 접속할 수 없다면 Wi-Fi, 셀룰러 데이터 또는 네트워크 인증부터 확인합니다.
현재 설정 확인

Config에서 실제로 선택된 설정 파일을 확인한 다음 해당 파일의 내용을 살펴봅니다. 활성화되지 않은 다른 파일만 편집하면 현재 요청 처리에는 영향을 주지 않습니다.
연결 후 다시 테스트

Home으로 돌아가 현재 이용 중인 서버에 연결한 뒤 Safari에서 같은 웹페이지를 다시 엽니다. 연결을 끊었을 때와 연결했을 때의 차이를 기록하고, 서버·DNS·규칙을 동시에 바꾸지 마세요.
네트워크를 바꿔 확인

설정과 서버는 그대로 둔 채 Wi-Fi와 셀룰러 네트워크를 전환해 다시 시도합니다. 한 네트워크에서만 실패한다면 해당 네트워크의 DNS 연결 가능 여부, 인증 및 접속 제한을 우선 확인하세요.

현재 이용 중인 서버 주소가 도메인이라면 연결을 시작하기 전에 해당 주소를 조회해야 할 수도 있습니다. 따라서 ‘대상 웹페이지의 DNS’와 ‘서버 도메인의 초기 조회’는 별개의 확인 대상입니다. 전자에 문제가 있어도 연결은 유지될 수 있지만, 후자에 문제가 있으면 연결 자체가 설정되지 않을 수 있습니다. 상태 표시줄의 연결 표시만으로 두 단계가 모두 완료되었다고 판단하지 마세요.

3. [General]의 dns-server 확인

Config에서 현재 파일의 [General] 섹션을 확인하고 dns-server를 찾습니다. 시스템 DNS, 직접 지정한 DNS 주소 또는 DNS over HTTPS 중 무엇을 사용하는지 확인한 뒤, 입력한 서비스의 철자와 현재 네트워크에서 접속 가능한지 점검하세요. 여러 출처의 설정을 무작정 합치거나 서비스 제공업체의 다른 항목을 DNS 주소로 잘못 입력하지 마세요.

[General]
dns-server = system

위 예시는 시스템 DNS를 사용하는 최소 설정으로, 필드 작성 방법을 보여 주기 위한 것입니다. 전체 설정은 아닙니다. 비교 테스트를 하려면 백업한 뒤 기존의 같은 설정 항목을 바꾸세요. [General]을 중복으로 추가하거나 dns-server를 여러 개 쌓아 넣지 마세요. 저장한 다음 다시 연결하고 새 요청을 보냅니다. 문제가 해결되었다면 조회 경로 변경이 효과가 있었다는 뜻이지만, 원인을 파악하려면 기존 설정과 비교해야 합니다.

시스템 DNS:system은 시스템에서 제공하는 DNS 설정을 사용합니다. Wi-Fi와 셀룰러 네트워크를 전환하면 실제 조회 환경도 바뀔 수 있으므로 현재 네트워크의 비교 기준을 마련하는 데 적합합니다.
직접 지정한 DNS 주소:주소가 올바른지, 현재 네트워크에서 해당 DNS 서버에 접속할 수 있는지 확인하세요. 주소를 설정했다고 해서 요청이 반드시 도달하는 것은 아닙니다. 서버 지연 시간만으로는 이를 확인할 수 없습니다.
DNS over HTTPS:HTTPS 엔드포인트의 전체 경로, 호스트 이름, TLS 연결 조건을 확인하세요. DNS 서버 호스트 이름을 처음 조회하는 과정이 연결에 영향을 줄 수도 있습니다. HTTPS를 사용한다는 이유만으로 이용 가능하다고 단정하지 마세요.
로컬 도메인:회사나 가정의 내부 이름은 로컬 DNS에서만 조회될 수 있습니다. 외부 DNS로 바꾸면 공용 웹페이지는 다시 열리더라도 내부 이름은 조회되지 않을 수 있습니다.

4. Global Routing으로 규칙 문제와 DNS 문제 구분

Home → Global Routing으로 이동해 현재 옵션을 먼저 기록합니다. Config는 현재 설정의 규칙에 따라 요청을 처리합니다. Proxy와 Direct는 아웃바운드 경로를 비교할 때 사용할 수 있습니다. Proxy로 바꾼 뒤 웹페이지가 열렸다고 해서 곧바로 “DNS가 해결됐다”고 해석하지 마세요. 대상 도메인은 계속 정상적으로 조회되고 있었지만 기존 규칙이 연결을 적절하지 않은 아웃바운드 정책으로 보냈을 수도 있습니다.

테스트 상태	관찰 결과	다음 확인 항목
Config 실패, Proxy 정상	선택한 아웃바운드 경로로 해당 웹페이지 요청이 완료됨	규칙 매칭, 정책 지정 및 DNS 관련 설정 확인
Direct 정상, Proxy 실패	직접 경로에서는 접속되지만 프록시 경로에는 차이가 있음	선택한 서버, 아웃바운드 연결 및 조회 경로 확인
여러 상태에서 모두 실패	문제가 특정 분할 라우팅 규칙에만 국한되지는 않음	로컬 네트워크, DNS 서버 연결 가능 여부 및 대상 웹사이트 확인
특정 도메인 하나만 실패	문제가 특정 대상에 집중됨	해당 도메인의 조회 결과, 전용 규칙 및 웹사이트 상태 확인

규칙은 순서대로 매칭되며, 일치하는 규칙의 정책이 적용됩니다. DOMAIN-SUFFIX가 대상 도메인을 포함하는지, GEOIP 또는 IP-CIDR가 조회된 주소를 다른 경로로 보내는지, FINAL이 규칙 섹션의 마지막에 있는지 확인하세요. 아래 예시는 구문과 순서만 보여 줍니다. example.com은 문서 예시용 도메인이며 웹 접속 테스트 대상이 아닙니다.

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

no-resolve는 해당 IP 규칙이 매칭을 위해 도메인 조회를 능동적으로 시작하지 않는다는 뜻이지, 모든 DNS를 끈다는 뜻은 아닙니다. 대상 IP를 이미 알고 있는지, 앞에서 도메인 규칙이 매칭되었는지에 따라 이후 규칙 적용이 달라집니다. 현재 설정에서 이름이 지정된 정책을 사용한다면 정책이 최종적으로 어디로 연결되는지도 확인하세요. 규칙 행에 정책 이름이 표시된다는 이유만으로 의도한 서버를 사용한다고 단정할 수 없습니다.

요약: 차이가 재현되는 비교 조건을 먼저 유지하세요

Config와 Proxy의 결과가 다르면 먼저 같은 도메인에 적용된 규칙과 최종 아웃바운드 경로를 기록한 뒤 해당 항목을 수정하세요. DNS와 서버를 동시에 바꾸면 어떤 변경이 효과가 있었는지 판단할 수 없습니다.

5. 오류가 발생한 단계로 DNS·연결·TLS 구분

Safari의 오류 문구는 시스템 언어에 따라 달라질 수 있습니다. 오류 상세 정보나 진단 기록에 시스템 오류 식별자가 있다면 아래 원문으로 발생 단계를 구분할 수 있습니다. 이 이름은 Apple URL Loading System의 오류 명칭이며, Shadowrocket 화면에 그대로 표시된다는 뜻은 아닙니다. 이번 접속 시각과 일치하는 요청 기록을 확인하고, 조회 실패, 대상 IP, 적용된 정책, 이후 연결 결과를 우선 살펴보세요.

오류: NSURLErrorCannotFindHost（-1003）

원인:요청에서 지정한 호스트를 찾을 수 없는 상태로, 도메인 오타나 이름 조회 문제가 원인일 수 있습니다. 해결 방법:전체 호스트 이름을 먼저 확인한 뒤 시스템 DNS와 현재 DNS 설정에서 주소를 가져올 수 있는지 비교합니다.

오류: NSURLErrorDNSLookupFailed（-1006）

원인:DNS 조회가 실패한 상태입니다. DNS 서버에 연결할 수 없거나 조회 과정에 문제가 생겼을 수 있습니다. 해결 방법:현재 DNS 서버와 네트워크 경로를 확인하고, 다른 조건은 그대로 둔 채 네트워크를 전환하거나 시스템 DNS로 비교 테스트를 진행합니다.

오류: NSURLErrorTimedOut（-1001）

원인:요청 시간이 초과된 상태로, 조회·연결·응답 대기 중 어느 단계에서든 발생할 수 있습니다. 해결 방법:기록에 대상 IP가 이미 있는지 먼저 확인하고 해당 아웃바운드 경로와 연결 결과를 점검합니다. 시간 초과 문구만으로 DNS 문제라고 단정하지 마세요.

오류: NSURLErrorSecureConnectionFailed（-1200）

원인:보안 연결 설정에 실패한 상태로, TLS, 인증서 또는 네트워크상의 연결 간섭이 원인일 수 있습니다. 해결 방법:기기의 날짜와 시간, 대상 호스트 이름을 확인하고 TLS 관련 기록을 살펴보세요. 인증서 확인을 끄는 것으로 문제 해결을 대신하지 마세요.

기록에 대상 IP가 이미 있는데 해당 IP 연결이 시간 초과되었다면 DNS를 계속 변경하기보다 서버의 아웃바운드 경로, 대상 포트, IPv4 / IPv6 경로를 확인하세요. DNS 조회 요청만 기록되고 오랫동안 응답이 없다면 DNS 서버에 접속할 수 있는지 집중적으로 살펴봅니다. 이전에 방문한 웹페이지는 열리지만 새 도메인만 실패한다면 캐시가 문제를 가리고 있을 수 있으므로 새 요청으로 다시 테스트하세요.

6. 정상 복구를 확인한 뒤 On Demand 복원

설정을 변경한 뒤에는 현재 설정을 저장하고 연결을 끊었다가 다시 연결한 다음 대상 웹페이지를 새로 엽니다. Safari나 앱에 기존 연결 및 캐시가 남아 있을 수 있으므로 한 번 새로고침해 성공했다고 문제가 완전히 해결된 것은 아닙니다. 반대로 이전 연결이 계속 실패한다고 새 설정이 적용되지 않았다고 볼 수도 없습니다. 문제가 발생한 웹페이지, 비교용 웹페이지, 다른 네트워크에서 반복 확인하고 결과가 일관적인지 기록하세요.

조회 확인:대상 도메인에서 적절한 주소를 받을 수 있고, 재현 당시와 같은 조회 실패 기록이 더 이상 나타나지 않습니다.
규칙 확인:평소 사용하는 Global Routing 상태로 복원한 뒤 대상 요청이 예상한 규칙과 정책에 적용되는지 확인합니다.
네트워크 전환 확인:주로 사용하는 Wi-Fi와 셀룰러 네트워크에서 각각 테스트하고, 네트워크 전환 후에만 DNS 서버에 연결할 수 없게 되는지 특히 주의합니다.
자동 연결 조건 복원:Settings → On Demand로 돌아가 이전에 기록한 조건을 복원하고 연결이 예상대로 시작되는지 확인합니다.
정상 설정 보관:변경 전후 설정을 모두 보관합니다. 원격 설정이 업데이트되면서 로컬 편집 내용이 덮어써질 수 있으므로 업데이트 내용을 확인하고, 임시 수정 사항을 영구적인 해결책으로 간주하지 마세요.

계속 실패한다면 이용 중인 서비스 제공업체나 네트워크 관리자에게 문제 발생 시각, 네트워크 유형, 대상 도메인, Global Routing 상태, 적용된 정책, 민감 정보를 가린 오류 일부 등 필요한 최소한의 정보를 전달하세요. 전체 구독 링크, 인증 암호, 액세스 토큰이 포함된 설정은 보내지 마세요. “DNS 응답이 없음”과 “주소를 받은 뒤 연결에 실패함”을 구분해 설명하면 지연 시간 테스트 결과만 전달하는 것보다 문제를 찾는 데 도움이 됩니다.