2026-08-14 · 문제 해결 · 약 9분

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

지연 시간 테스트는 정상이지만 웹페이지가 열리지 않나요? DNS 조회 문제일 가능성이 큽니다. Shadowrocket DNS 설정과 조회 실패 증상, 단계별 점검 방법을 알아봅니다.

이 글의 핵심 내용

이 글은 Shadowrocket에서 자신의 서비스를 설정했고, 지연 시간 테스트 결과는 나오지만 브라우저에서 웹페이지를 열 수 없는 경우를 다룹니다. 기본 네트워크, Global Routing, DNS, 규칙, 캐시 순으로 점검해 ‘주소를 찾지 못하는 문제’와 ‘주소는 찾았지만 연결되지 않는 문제’를 구분하세요. 여러 설정을 한꺼번에 바꿔 원인을 파악하기 어려워지는 상황을 피할 수 있습니다.

지연 시간이 정상이어도 웹 연결이 정상인 것은 아닙니다

지연 시간 테스트는 지정된 테스트 방식으로 대상이 응답했다는 뜻일 뿐입니다. 테스트에 도메인 조회, 프록시 인증 또는 대상 웹페이지 접속이 포함되는지는 테스트 방식에 따라 다릅니다. 한 번 테스트에 성공했다고 모든 웹사이트가 열린다는 의미는 아닙니다. 브라우저에서 HTTPS 페이지를 불러오려면 도메인 조회, 대상 서버 연결, TLS 핸드셰이크, 서버 응답이 필요합니다. 어느 단계에서든 실패하면 페이지가 로드되지 않을 수 있습니다.

도메인 요청 DNS 조회 규칙 판단 대상 연결 TLS 핸드셰이크 페이지 응답

위 흐름은 장애 지점을 찾기 위한 참고용이며, 내부 처리 순서가 반드시 이와 같다는 뜻은 아닙니다. 도메인 규칙은 대상 IP를 얻기 전에 적용될 수 있고, IP 규칙은 조회 결과가 필요할 수 있습니다. 또한 두 가지 조회를 구분해야 합니다. 프록시 서버 주소를 도메인으로 입력했다면 먼저 해당 서버의 주소를 조회해야 합니다. 대상 웹사이트 도메인을 어느 경로에서 조회하는지는 프로토콜, 아웃바운드 방식, 구성에 따라 달라집니다.

반복 가능한 테스트 기준 만들기

테스트 전에 실패한 URL, 사용 중인 네트워크, Home에서 선택한 서버, Global Routing 상태를 기록하세요. 평소 접속되는 웹사이트 두 곳과 실패한 웹사이트 한 곳을 비교 대상으로 삼고, 매번 설정 하나만 바꾼 뒤 같은 페이지를 다시 열어 보세요. 아래 단계는 자신의 서버나 구독이 이미 있다는 전제입니다. 클라이언트 구매에는 연결 서비스가 포함되지 않습니다.

  1. 현재 상태 기록

    Config에서 현재 사용 중인 구성을 확인하고 먼저 백업해 두세요. Home → Global Routing의 현재 옵션, 선택한 서버, 기존 DNS 값을 기록해 문제 해결을 위해 바꾼 설정을 장기 설정으로 오인하지 않도록 합니다.

  2. 기본 네트워크 확인

    연결을 잠시 끄고 평소 바로 접속되는 웹사이트를 열어 보세요. 여전히 접속되지 않으면 Wi-Fi 인증을 완료하거나 사용 가능한 네트워크로 전환하세요. Settings → On Demand를 확인하고, 점검하는 동안 자동으로 연결을 다시 설정할 수 있는 조건은 잠시 비활성화했다가 점검이 끝난 후 복원하세요.

  3. 아웃바운드 고정

    Home으로 돌아가 사용 가능한 자신의 서버를 선택하고 연결을 켜세요. Home → Global Routing에서 Proxy를 임시로 선택한 뒤 같은 URL을 다시 열어 보세요. Proxy는 규칙의 영향을 분리해 확인하기 위한 설정이며, DNS 요청이 모두 해당 서버를 경유한다는 뜻은 아닙니다.

  4. DNS 조회 확인

    Settings → DNS를 열어 현재 설정을 기록하고, Config에서 활성화된 구성의 DNS 항목과 비교하세요. 먼저 출처가 분명한 설정 하나로 되돌리세요. 검증되지 않은 여러 DNS 조회기를 한꺼번에 추가하지 마세요.

  5. 원래대로 복원하고 재검사

    원래 Global Routing 설정으로 복원한 뒤 같은 페이지를 다시 열어 보세요. Proxy에서는 정상인데 Config에서 실패하면 규칙을 확인하세요. 둘 다 실패한다면 DNS 조회 실패, 대상 연결 실패, TLS 오류를 구분해 점검하세요.

DNS 설정은 조회기, 전송 방식, 적용 범위를 확인하세요

DNS는 도메인을 IP 주소로 변환합니다. A 레코드는 IPv4 주소를, AAAA 레코드는 IPv6 주소를 제공합니다. 레코드를 받았다는 것은 조회가 성공했다는 뜻일 뿐, 현재 네트워크와 아웃바운드 경로에서 해당 주소에 연결할 수 있다는 의미는 아닙니다. DNS를 설정할 때는 세 가지를 구분하세요. 어디에 조회할지, 어떤 방식으로 전송할지, 어떤 요청에 설정을 적용할지입니다.

확인 항목 실제 의미 점검 방법
Settings → DNS 앱 수준의 DNS 설정과 기존 재정의 옵션을 확인하세요. 주소를 입력했다는 사실만으로 설정이 적용됐다고 판단할 수 없습니다. 기존 값을 기록하고 활성화된 구성과 비교하세요. 한 번에 한 가지 출처만 변경하세요.
dns-server 구성 파일의 DNS 서버 항목입니다. system은 시스템에서 제공하는 조회기를 사용한다는 뜻입니다. 현재 활성화된 구성의 [General]을 확인하세요. 활성화되지 않은 사본을 수정한 뒤 바로 결론을 내리지 마세요.
일반 DNS 일반적으로 UDP 53을 사용하고 TCP 53을 사용할 수도 있습니다. 포트나 전송 방식이 제한되면 시간 초과가 발생할 수 있습니다. Wi-Fi와 셀룰러 네트워크를 비교하고, 조회 시간 초과를 곧바로 웹사이트 장애로 단정하지 마세요.
DoH / DoT DoH는 보통 HTTPS 443을, DoT는 보통 TCP 853을 사용합니다. 암호화되어 있다고 반드시 연결 가능한 것은 아닙니다. 조회 서비스에서 지원하는 프로토콜, 주소, 인증서 조건을 확인하세요. 포트만 바꾸거나 경로를 임의로 조합하지 마세요.
A / AAAA 두 레코드가 모두 존재하더라도 그중 한 주소 체계의 네트워크 경로를 사용할 수 없을 수 있습니다. 조회 결과를 실제 연결에 실패한 주소 체계와 대조한 다음 IPv6 경로를 점검하세요.

구성 텍스트에서 시스템 DNS의 기본 설정을 확인해야 하는 경우 관련 구문은 다음과 같습니다. 이는 구성 일부일 뿐 완전한 구성이 아니며, 기존 파일을 덮어쓰라는 의미도 아닙니다. 백업 사본에서 기존 항목만 수정해 [General] 섹션이 중복으로 생기지 않도록 하세요.

[General]
dns-server = system

시스템 DNS를 사용하면 기존에 지정한 조회기에서 문제가 발생했는지 판단하기 쉽지만, 모든 네트워크에서 같은 결과가 나온다고 보장할 수는 없습니다. 기존 구성에서 특정 도메인에 별도 조회 방식을 지정했다면 해당 설정도 확인하세요. 조회기를 추가하는 것을 만능 해결책으로 여기지 마세요. 출처에 따라 레코드가 다를 수 있고, 여러 결과를 섞으면 오히려 문제를 재현하기 어려워질 수 있습니다.

요약: 네트워크를 전환해 전송 문제 확인

서버, 구성, 테스트 도메인은 그대로 두고 Wi-Fi와 셀룰러 네트워크만 전환하세요. 네트워크에 따라 문제가 달라진다면 프로토콜과 규칙 전체를 한꺼번에 바꾸지 말고 해당 네트워크의 DNS 연결 가능 여부와 주소 체계별 경로를 확인하세요.

오류를 발생 단계별로 구분하기

아래는 Apple 네트워크 요청에서 발생할 수 있는 실제 오류 식별자입니다. 브라우저나 Shadowrocket에 이 문자열이 그대로 표시된다는 보장은 없습니다. 실제로 표시된 오류 원문, 발생 시간, 요청 도메인을 기록한 뒤 실패 단계를 분류하세요. ‘시간 초과’만으로 DNS 문제라고 단정할 수는 없습니다.

오류: NSURLErrorCannotFindHost (-1003)

원인 및 해결 방법: 요청한 호스트를 찾지 못한 상태로, 도메인 철자가 틀렸거나 조회 결과를 얻지 못했을 때 흔히 발생합니다. 먼저 전체 도메인을 확인한 다음 DNS 조회에 응답이 있는지 살펴보세요. 특정 도메인 하나에서만 발생한다면 해당 도메인이 여전히 유효한지도 확인하세요.

오류: NSURLErrorTimedOut (-1001)

원인 및 해결 방법: 제한 시간 안에 요청이 완료되지 않은 상태입니다. 조회, 연결, 응답 대기 중 어느 단계에서든 발생할 수 있습니다. 먼저 대상 IP를 받았는지 확인하고, 이후 연결 단계를 살펴보세요. 모든 시간 초과를 조회 실패로 간주하지 마세요.

오류: NSURLErrorCannotConnectToHost (-1004)

원인 및 해결 방법: 호스트에 연결하지 못한 것으로, 호스트를 찾지 못한 것과는 다릅니다. 주소를 이미 받았다면 사용 중인 아웃바운드, 대상 포트, IPv4/IPv6 경로를 확인하세요. DNS만 반복해서 바꾸지 마세요.

오류: NSURLErrorSecureConnectionFailed (-1200)

원인 및 해결 방법: TLS 보안 연결을 설정하지 못한 상태입니다. 먼저 기기의 날짜와 시간을 확인한 다음 대상 인증서와 관련 TLS 설정을 살펴보세요. 인증서 검증을 끄는 방식으로 문제를 숨기지 마세요.

DNS 조회 결과도 구분해야 합니다. NXDOMAIN은 조회기가 해당 이름이 존재하지 않는다고 응답한 것이고, SERVFAIL은 서버가 조회를 완료하지 못했다는 뜻입니다. 조회 시간 초과는 대기 시간 안에 응답을 받지 못한 상태입니다. 세 가지는 서로 다른 문제입니다. 유효성이 확인된 동일한 도메인을 고정된 DNS 설정으로 반복 테스트하는 편이 브라우저의 ‘페이지를 열 수 없음’ 메시지만 보는 것보다 원인을 파악하는 데 유용합니다.

Global Routing 및 규칙 영향 확인

DNS 조회가 성공했더라도 적절하지 않은 아웃바운드 선택으로 웹페이지 접속에 실패할 수 있습니다. Global Routing에서 Proxy는 프록시를 통한 아웃바운드, Direct는 직접 연결, Config는 활성화된 구성에 따른 처리, Scene은 선택된 장면에 따른 처리를 의미합니다. 문제를 점검할 때는 서버가 선택됐는지만 보지 말고 현재 설정이 실제로 해당 서버를 사용하는지도 확인하세요.

Proxy에서는 같은 페이지가 열리지만 Config에서는 열리지 않는다면 먼저 적용되는 도메인 규칙이나 IP 규칙이 있는지 확인하세요. 규칙은 순서대로 적용됩니다. DOMAIN-SUFFIX는 도메인 접미사를 확인하고, GEOIP와 IP-CIDR은 IP 조건을 다루며, FINAL은 최종 기본 규칙입니다. 아래는 구문 예시일 뿐이므로 기존 구성을 통째로 바꾸지 마세요.

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

HTTPS를 확인하는 유일한 방법으로 브라우저에서 대상 IP를 직접 여는 방식은 사용하지 마세요. HTTPS는 도메인에 대응하는 인증서, SNI, 사이트 라우팅에도 의존하므로 IP를 직접 입력하면 다른 오류가 발생할 수 있습니다. 같은 도메인에서 주소를 받았는지, 어떤 동작의 규칙이 적용됐는지, 이후 연결이 어느 단계에서 실패했는지를 확인하는 것이 더 확실합니다.

캐시, IPv6 및 재검사 관련 질문

DNS를 변경한 후에도 앱, 시스템 또는 조회 서비스에 캐시가 남아 있을 수 있습니다. 구성을 저장하고 적용 여부를 확인한 뒤 연결을 끊었다가 다시 연결하고 브라우저에서 새 요청을 보내세요. 이 방법으로 모든 계층의 캐시가 지워지는 것은 아닙니다. 한 번 새로 고친 결과만으로 해결됐다고 단정하지 말고 같은 페이지들을 반복해서 확인하며 네트워크 변경 여부도 기록하세요.

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

먼저 Config에서 현재 활성화된 파일을 수정했는지, 또는 Settings → DNS에서 실제 사용 중인 설정을 바꿨는지 확인한 다음 조회 결과로 주소를 받았는지 살펴보세요. 주소를 받았지만 연결에 실패했다면 규칙, 대상 포트, TLS를 확인하세요. 조회기를 계속 추가하지 마세요.

Wi-Fi에서만 연결되지 않는데 구독을 다시 입력해야 하나요?

먼저 구독과 선택한 서버를 그대로 둔 채 셀룰러 네트워크로 전환해 다시 확인하세요. 셀룰러 네트워크에서는 정상이라면 Wi-Fi로 돌아가 인증 페이지, 시스템 DNS, 현재 DNS 전송 방식에 연결할 수 있는지 확인하세요. 구독이 만료됐다는 근거가 없다면 먼저 구독을 삭제하지 마세요.

IPv6를 끄니 다시 연결됩니다. 계속 꺼 두어도 되나요?

IPv6 경로를 확인할 필요가 있다는 신호이지만, 근본 원인이 확인된 것은 아닙니다. 실패할 때 AAAA 주소를 사용했는지 기록하고 같은 네트워크에서 IPv4 연결과 비교하세요. 관련 옵션을 임시로 꺼서 비교할 수 있지만, 장기 설정은 네트워크와 사용 중인 서비스의 지원 여부를 고려해 결정하세요.

다시 연결한 후 구성이 다른 것으로 바뀌면 어떻게 하나요?

Config에서 현재 활성화된 항목을 확인하고, Home → Global Routing에서 Scene을 선택했는지, Settings → On Demand가 네트워크 전환 후 연결을 시작했는지 살펴보세요. 구성과 네트워크 조건을 고정한 뒤 다시 테스트해 자동 전환으로 생긴 차이를 DNS의 간헐적 실패로 오인하지 않도록 하세요.

자신의 서비스 제공업체에 문의할 때는 장애 발생 시각, 네트워크 유형, Global Routing 옵션, 실패한 도메인, 실제 오류 원문, A/AAAA 결과를 받았는지 기록해 전달하세요. 구독 토큰, 인증 정보, 개인 키는 숨기고 구성 파일 전체를 공개하지 마세요. 지연 시간 스크린샷만 보내는 것보다 ‘DNS 조회는 성공했지만 연결 실패’ 또는 ‘특정 네트워크에서만 DNS 시간 초과’처럼 설명하면 원인을 찾는 데 도움이 됩니다.

App Store 정품 확인