2026-10-14 · 문제 해결 · 약 8분

Shadowrocket DNS 설정 방법: 지연 테스트는 정상인데 웹페이지가 열리지 않을 때

지연 테스트는 정상인데 웹페이지가 열리지 않는다면 DNS 확인이 필요할 수 있습니다. 설정 파일의 DNS 항목을 살펴보고 이름 해석이 실패할 때 확인할 순서를 안내합니다.

이 글의 핵심 내용

이 글은 Shadowrocket에 사용 중인 서비스와 연결 정보를 설정했지만, 지연 테스트 결과는 표시되어도 웹페이지가 열리지 않는 경우를 다룹니다. 먼저 서버 연결, DNS 조회, 웹페이지 접속을 구분한 다음 Config의 DNS 설정, Global Routing, 규칙을 확인하세요. 한 번에 한 항목만 변경하고 같은 도메인으로 다시 테스트해야 규칙 차단이나 아웃바운드 연결 실패를 DNS 문제로 오인하지 않습니다.

1. 지연 테스트는 정상인데 DNS 조회가 실패할 수 있는 이유

Home → Connectivity Test 결과는 현재 사용 중인 테스트 방식에 따라 달라집니다. 서버 연결만 확인할 수도 있고 테스트 대상으로 접속할 수도 있습니다. 어느 방식이든 모든 웹사이트의 DNS, TLS, 페이지 리소스가 정상임을 보장하지는 않습니다. 서버 주소가 캐시에 저장되어 있다면 테스트 과정에서 해당 주소를 다시 조회하지 않을 수도 있습니다.

새 도메인을 열면 보통 먼저 주소를 조회한 뒤 실제 정책에 따라 연결하고, 마지막으로 TLS 핸드셰이크와 HTTP 요청을 수행합니다. 아래는 문제를 확인할 때 참고할 간략한 흐름입니다. 실제로 로컬에서 조회하는지, 언제 조회하는지는 규칙 유형과 아웃바운드 프로토콜에 따라 다릅니다.

도메인 요청 주소 조회 정책 선택 아웃바운드 연결 웹페이지 응답

따라서 ‘지연 테스트 정상’은 일부 상황만 보여 주는 근거입니다. DNS가 주소를 반환했지만 연결 시간이 초과되면 아웃바운드 연결을 확인해야 합니다. DNS가 주소를 전혀 반환하지 않았다면 우선 조회 문제를 살펴보세요. 웹페이지의 텍스트는 표시되지만 이미지가 로드되지 않는다면 이미지에 사용된 다른 도메인의 조회가 실패했을 수도 있습니다. 주소창의 기본 도메인만 확인해서는 부족합니다.

53
기존 DNS에서 주로 사용하는 UDP/TCP 포트
443
DNS over HTTPS에서 주로 사용하는 포트
853
DNS over TLS에서 주로 사용하는 포트

판단 기준: 먼저 조회 결과가 있는지 확인

A 또는 AAAA 레코드를 받았는데도 페이지가 열리지 않는다면 DNS를 계속 바꾸지 마세요. 반환된 주소를 기록한 뒤 해당 연결에 적용된 정책과 아웃바운드 결과를 확인하세요. 포트에 연결할 수 있다고 해서 DNS 서비스 전체가 정상인 것은 아닙니다.

2. Config에서 현재 사용 중인 DNS 설정 확인

먼저 Config를 열어 현재 선택된 설정 파일을 확인하세요. 활성화되지 않은 다른 파일을 편집해도 현재 연결에는 반영되지 않습니다. 변경하기 전에 사본을 보관하세요. 설정이 사용자가 지정한 원격 구성에서 제공되는 경우, 이후 업데이트가 로컬 변경 사항을 덮어쓸 수 있다는 점도 유의해야 합니다.

Config에서 현재 파일의 편집 화면을 열고 [General] 아래의 dns-server 항목을 확인하세요. 이 항목은 조회 서버를 지정합니다. 아래는 최소한의 문법 예시일 뿐, 기존 설정 파일을 대체할 수 있는 완전한 파일이 아닙니다.

[General]
dns-server = system

system은 시스템에서 제공하는 DNS를 사용한다는 뜻입니다. 보통 현재 Wi-Fi 또는 셀룰러 네트워크의 영향을 받으며, 특정 공용 DNS를 고정으로 사용한다는 의미는 아닙니다. 여기에 하나 이상의 주소가 입력되어 있다면 출처와 연결 가능 여부를 각각 확인하세요. ‘예비용’이라는 이유만으로 검증되지 않은 DNS 엔드포인트를 계속 추가하지 마세요.

3. 여러 조건을 한꺼번에 바꾸지 말고 정해진 순서대로 다시 테스트

평소 정상적으로 접속되는 전체 도메인 하나를 테스트 대상으로 고르고, 비교용으로 다른 사이트도 하나 준비하세요. 테스트하는 동안 서버와 네트워크를 그대로 유지하세요. Wi-Fi를 바꾸고 서버를 전환하면서 DNS까지 동시에 수정하면 문제가 해결되어도 어떤 변경이 효과가 있었는지 알 수 없습니다.

  1. 현재 상태 기록

    Home에서 선택된 SERVER, 현재 Global Routing 값, Connectivity Test 결과를 기록하세요. 문제가 발생한 도메인과 네트워크 유형, 브라우저에 표시된 구체적인 오류도 적어 두세요. 스크린샷을 공유하기 전에는 계정 정보와 서버 정보를 가리세요.

  2. 모드 확인

    Home → Global Routing을 열어 Config, Proxy, Direct, Scene 중 어떤 모드인지 확인하세요. Scene을 사용한다면 실제로 적용 중인 장면도 확인하세요. 원래 값을 기록한 다음 비교 테스트를 진행하고, 모드를 바꾸는 것 자체를 최종 해결책으로 간주하지 마세요.

  3. 설정 확인

    Config에서 현재 선택된 파일을 열어 dns-server와 [Host]를 확인하세요. 한 항목만 변경하고 저장한 다음 Home으로 돌아가 다시 연결한 뒤 같은 도메인을 열어 보세요.

  4. 자동 연결 확인

    Settings → On Demand에서 기능이 활성화되어 있는지와 관련 조건을 기록하세요. 테스트 중 연결이 자동으로 복구된다면 On Demand를 잠시 끄고 비교 테스트를 반복할 수 있습니다. 테스트가 끝나면 원래 설정으로 되돌리세요. On Demand는 연결이 시작되는 조건을 제어하며 DNS 서버 설정과는 다릅니다.

  5. 네트워크 변경

    설정과 SERVER는 그대로 둔 채 Wi-Fi와 셀룰러 네트워크에서 각각 다시 테스트하세요. 특정 네트워크에서만 실패한다면 해당 네트워크의 DNS 연결 가능 여부, 로그인 인증 상태, 네트워크 제한을 우선 확인하세요.

  6. 설정 복원 및 확인

    불필요한 임시 변경 사항을 되돌리고 다시 연결한 뒤 두 사이트를 테스트하세요. 성공 여부는 예상한 조회 결과를 얻고 웹페이지가 로드되는지로 판단해야 합니다. Connectivity Test에 다시 숫자가 표시되는 것만으로는 충분하지 않습니다.

브라우저, 시스템, DNS 서버에는 각각 캐시가 있을 수 있습니다. 다시 연결하면 테스트 조건을 명확히 하는 데 도움이 되지만 모든 캐시가 지워진다고 보장할 수는 없습니다. 비교할 때 같은 결과가 반복해서 사용되는지 기록하세요. 임의의 HTTPS 숫자 주소에 접속해 도메인 테스트를 대신하지 마세요. 인증서와 가상 호스트 차이가 개입할 수 있습니다.

4. 실제 오류를 세 가지로 나눠 대응

다음은 DNS 프로토콜이나 진단 출력에서 나타날 수 있는 원문입니다. Shadowrocket의 모든 화면에 이 내용이 그대로 표시된다는 뜻은 아닙니다. 브라우저는 요약된 안내만 표시할 수 있습니다. 실제로 기록된 내용을 기준으로 판단하고, 모든 ‘접속 불가’를 같은 문제로 취급하지 마세요.

NXDOMAIN

원인: 조회 서버가 해당 도메인이 존재하지 않는다고 응답했습니다. 도메인 철자 오류, 레코드 삭제, 조회 서비스 측 정책 등이 원인일 수 있습니다.

해결 방법: 먼저 도메인 전체의 철자를 확인한 뒤, 사용 가능 여부를 확인한 다른 DNS 소스와 비교하세요. 특정 도메인 하나에서만 계속 문제가 발생한다면 해당 도메인 관리 측에 레코드를 확인하세요.

SERVFAIL

원인: 조회 서버가 요청을 완료하지 못했습니다. 상위 서버 문제, 권한 서버 접속 불가, DNSSEC 검증 실패 등이 원인일 수 있으며, 도메인이 존재하지 않는다는 뜻은 아닙니다.

해결 방법: 네트워크와 아웃바운드 설정은 그대로 두고, 이미 사용 가능한 다른 DNS 설정으로 다시 테스트하세요. 특정 도메인에서만 문제가 발생한다면 발생 시각과 응답 상태를 기록해 관련 관리 측에 전달하세요.

timeout

원인: 제한 시간 내에 응답을 받지 못했습니다. 조회 엔드포인트에 연결할 수 없거나 패킷이 폐기되었을 수 있으며, 암호화 DNS 연결이 수립되지 않은 경우도 있습니다.

해결 방법: 먼저 설정된 주소, 프로토콜, 포트가 서로 일치하는지 확인한 다음 다른 네트워크와 비교하세요. 계속 연결되지 않는 문제를 감추기 위해 대기 시간만 늘리지 마세요.

조회가 완료되어도 요청한 유형의 레코드가 없을 수 있으며, 이것만으로 오류라고 할 수는 없습니다. 예를 들어 도메인에 A 레코드만 있다면 AAAA 조회는 성공 응답을 반환하면서도 해당 답이 없을 수 있습니다. 응답 상태와 레코드 유형을 함께 확인하세요. IPv6 주소가 없다는 이유만으로 DNS 서비스가 작동하지 않는다고 판단해서는 안 됩니다.

5. DNS 조회가 정상이면 Global Routing과 규칙 확인

Global Routing의 Config는 현재 설정 파일의 규칙에 따라 연결 경로를 결정합니다. Proxy와 Direct는 해당 전역 라우팅 모드를 사용하고, Scene은 설정된 장면에 따라 작동합니다. 이 네 가지는 DNS 서버 선택지가 아닙니다. 모드를 바꾼 뒤 웹페이지가 열렸다면 경로 변경이 결과에 영향을 주었다는 뜻일 뿐입니다. 구체적으로 어떤 규칙이나 아웃바운드 설정이 달랐는지 추가로 확인해야 합니다.

Config에서 현재 파일의 [Rule]을 확인하세요. 아래 내용은 문법 설명을 위한 예시이며 문서용 도메인과 예약 주소 대역을 사용합니다. 실제 설정에 해결책으로 그대로 추가하면 안 됩니다. FINAL,DIRECT는 이 예시에서 마지막에 적용되는 정책일 뿐, 일반적인 권장 설정이 아닙니다.

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

같은 연결에서는 보통 규칙이 순서대로 적용되므로 앞부분의 차단이나 정책 선택으로 인해 뒤쪽 규칙이 적용되지 않을 수 있습니다. 규칙 세트를 사용한다면 실제 내용과 업데이트 상태도 확인하세요. 기본 파일에서 도메인을 검색해 찾지 못했다고 해서 관련 규칙이 없다고 단정하지 마세요.

6. 해결 여부를 확인하고 검토 가능한 기록 남기기

해결 여부는 반복해서 확인할 수 있어야 합니다. 네트워크, SERVER, 설정을 고정한 상태에서 문제가 발생한 도메인이 조회되고, 연결 경로가 예상과 일치하며, 페이지와 필요한 리소스가 모두 로드되어야 합니다. 이후 필요한 On Demand 설정을 복원하고 네트워크를 전환한 뒤에도 정상인지 확인하세요.

두 DNS 소스 모두 정상적으로 주소를 반환하는데도 같은 서버에서 웹페이지 연결이 실패한다면 서버 가용성, TLS, 아웃바운드 제한, 규칙을 확인하세요. DNS 주소를 계속 추가하면 변수가 늘어날 뿐 이러한 문제를 자동으로 해결하지는 않습니다. 계속 확인하려면 이 사이트의 문제 해결 및 용어 빠른 확인을 참고하세요.

Shadowrocket은 Apple 플랫폼 전용 상용 앱으로, 주로 iPhone과 iPad에서 사용합니다. 앱을 받을 수 있는 유일한 경로는 App Store입니다. 개발자는 Shadow Launch Technology Limited이며, 앱은 일회성 구매 방식입니다. 앱 구매와 연결 서비스 요금제는 별개입니다. 이 글은 사용자가 자신의 서비스와 설정을 보유하고 있다는 전제에서 작성했습니다. 시스템 요구 사항은 App Store 페이지를 확인하세요.

App Store 정품 확인