Shadowrocket 웹페이지가 열리지 않지만 지연 시간은 정상일 때: DNS 오류 해결 및 설정 점검

이 글의 핵심

이 글은 Shadowrocket에서 직접 가져온 구독을 추가하고 연결했지만 웹페이지가 열리지 않는 경우를 위한 안내입니다. 먼저 서버 연결, 도메인 조회, 웹페이지 연결을 구분하고, 이어서 Global Routing과 현재 Config를 확인한 다음 DNS 설정 하나만 바꿔 결과를 비교합니다. 모든 접속 문제를 DNS 탓으로 돌리는 대신 문제가 발생한 지점을 찾아내는 것이 목표입니다.

1. 지연 시간이 정상이어도 웹페이지가 열리지 않을 수 있는 이유

Home에 표시되는 서버 항목의 지연 시간은 현재 테스트 방식이 확인하는 연결 경로에 응답이 있다는 뜻입니다. 테스트 방법마다 확인하는 대상과 절차가 다릅니다. 포트 연결에 성공했다고 해서 도메인 조회까지 성공한 것은 아닙니다. 테스트용 웹사이트에 접속할 수 있어도 다른 사이트의 DNS, TLS, HTTP 요청이 모두 정상이라는 보장은 없습니다.

HTTPS 페이지를 열 때는 일반적으로 먼저 도메인에 해당하는 주소를 조회한 뒤 정책에 따라 연결을 설정하고, TLS 핸드셰이크를 마친 후 페이지를 요청합니다. 어느 단계에서든 문제가 생기면 브라우저에는 ‘페이지를 열 수 없음’으로 표시될 수 있습니다. Proxy 정책을 사용한다면 대상 도메인을 원격에서 조회하는지도 고려해야 합니다. 기기에서 실행한 DNS 테스트만으로 전체 연결 경로를 판단할 수는 없습니다.

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

443

HTTPS 및 DoH에서 주로 사용하는 포트

853

DoT 기본 포트

정리: 같은 URL로 전후 결과 비교하기

계속 접속에 실패하는 URL 하나를 정해 동일한 네트워크, 서버, Global Routing 상태에서 변경 전후 결과를 비교하세요. 서버와 DNS를 동시에 바꾸지 마세요. 접속이 복구되어도 어떤 변경이 효과를 냈는지 알 수 없게 됩니다.

2. dns-server를 변경하기 전에 문제 범위부터 확인하기

실패한 URL, 현재 Wi-Fi 또는 셀룰러 네트워크, 선택한 서버, Global Routing 상태, 브라우저에 표시된 전체 오류를 먼저 기록하세요. 도메인과 증상만 남기고 구독 token, 계정 정보, 전체 설정 키는 포함하지 마세요. 구독 링크는 서비스 제공업체에서 받아야 하며, 문제 해결용 스크린샷에 공개하지 마세요.

테스트 조건 고정하기

Home에서 현재 서버를 기록한 다음 Home → Global Routing으로 이동해 선택 항목을 확인하세요. Scene을 사용 중이라면 실제 적용 중인 Scene과 정책을 확인하세요. Scene이 Config와 같은 방식으로 작동한다고 가정하지 마세요.
도메인 두 개 비교하기

Safari에서 접속에 실패한 URL과 평소 정상적으로 열리는 다른 URL을 각각 열어 보세요. 한 도메인만 실패한다면 먼저 철자, 해당 도메인의 DNS 레코드, 적용된 규칙을 확인하세요. 모든 URL이 실패한다면 전체 연결 경로를 점검하세요.
네트워크 환경 비교하기

서버와 설정은 그대로 둔 채 Wi-Fi와 셀룰러 네트워크를 전환해 같은 URL을 다시 열어 보세요. 특정 Wi-Fi에서만 실패한다면 웹 인증을 먼저 완료해야 하는 네트워크인지도 확인하세요.
자동 연결 제어하기

연결을 끊은 상태와 비교하려면 Settings → On Demand에서 현재 상태를 기록하고 필요한 경우 잠시 끄세요. 그렇지 않으면 On Demand가 연결을 다시 설정해 ‘연결 해제 후 테스트’ 조건이 무효가 될 수 있습니다. 테스트를 마친 뒤 원래 설정으로 복원하세요.
현재 설정 보존하기

Config에서 현재 설정의 사본을 보관하거나 내보내 백업하고, 현재 선택된 파일을 기록하세요. 이후 해당 파일의 매개변수 하나만 수정하고 저장한 다음 다시 연결해 테스트하세요. 구독을 동시에 업데이트하거나 다른 전체 설정 파일을 가져오지 마세요.

연결을 끊으면 같은 URL에 접속할 수 있지만 연결 후 실패하는 경우에는 설정의 DNS, 규칙 적용 결과, 원격 연결 경로를 중점적으로 확인하세요. 연결을 끊어도 실패한다면 시스템 네트워크나 웹사이트 자체도 점검해야 합니다. 어느 경우든 테스트 한 번만으로 원인을 단정할 수는 없습니다.

3. dns-server, 시스템 DNS, 사용자 지정 DNS의 차이

dns-server는 설정 파일의 [General]에 지정하는 DNS 업스트림입니다. Config로 이동해 현재 파일의 작업 메뉴에서 Edit Config를 선택한 뒤 기존 [General] 섹션을 확인하세요. 메뉴 표시는 현재 앱 화면을 기준으로 하세요. 매개변수를 [Rule]에 넣지 말고, 같은 파일에 동일한 설정을 여러 번 추가하지 마세요.

설정 방식	의미	점검할 항목
`dns-server = system`	시스템에서 제공하는 DNS 업스트림을 사용합니다.	네트워크를 바꾸면 업스트림도 달라질 수 있으며, 특정 공용 DNS를 고정해서 사용하는 방식은 아닙니다.
`dns-server = 1.1.1.1`	비교 예시로 일반 DNS 업스트림 주소를 지정합니다.	현재 네트워크에서 해당 DNS 서비스에 접속할 수 있는지 확인하세요. 주소에 도달할 수 있어도 조회가 성공한다는 보장은 없습니다.
암호화 DNS 업스트림	사용 중인 설정에서 지원하는 구문에 따라 DoH 또는 DoT로 조회를 전송합니다.	조회 서비스뿐 아니라 엔드포인트 연결, 인증서, 필요한 경우 초기 DNS 조회에도 의존합니다.

시스템 DNS는 현재 네트워크 환경에 따라 선택되므로 시스템 기본값에 가까운 조건과 비교할 때 유용합니다. 사용자 지정 DNS는 업스트림을 명시적으로 지정하지만 모든 Wi-Fi나 셀룰러 네트워크에서 연결할 수 있는 것은 아닙니다. 잘못된 규칙, 서버 장애, 웹사이트 인증서 문제를 자동으로 해결하지도 않습니다. 기업 내부 전용 도메인은 내부 DNS에서만 조회될 수 있습니다.

[General]
dns-server = system

위 내용은 매개변수의 위치만 보여 주는 예시이며, 완전한 설정 파일이 아닙니다. 기존 파일에 [General]이 있다면 해당 섹션의 값을 바꾸세요. 이 두 줄로 파일 전체를 덮어쓰지 마세요. 사용자 지정 업스트림과 비교하려면 해당 줄만 dns-server = 1.1.1.1로 바꾸고 저장한 뒤 다시 연결해 같은 도메인으로 테스트하세요. 이 주소는 구문 설명용이며 모든 네트워크에 적합하다는 뜻은 아닙니다.

4. 응답을 기준으로 미등록 도메인, 조회 서비스 오류, 시간 초과 구분하기

브라우저의 간략한 안내만으로는 원인을 판단하기 어려운 경우가 많습니다. 진단 기록에 DNS 응답 코드나 오류 문구가 있다면 아래 세 가지 유형으로 구분할 수 있습니다. 여기에 나오는 영문은 DNS 응답 코드와 일반적인 네트워크 오류 문구이며, Shadowrocket의 모든 화면에 그대로 표시된다는 뜻은 아닙니다.

오류: NXDOMAIN

원인: DNS 응답에서 조회한 도메인이 존재하지 않는다고 나타났습니다. 업스트림이 반환한 결과가 원인일 수도 있습니다.

해결: 먼저 도메인 철자를 확인하세요. 그런 다음 같은 도메인으로 시스템 DNS와 연결 가능한 사용자 지정 업스트림을 비교하세요. 둘 다 이 응답을 반환한다면 도메인 또는 서비스 관리자에게 레코드 상태를 확인하세요.

오류: SERVFAIL

원인: 조회 서비스가 요청을 처리하지 못했습니다. 업스트림의 재귀 조회 또는 검증 실패가 원인일 수 있으며, 도메인이 존재하지 않는다는 뜻은 아닙니다.

해결: 연결 정책은 그대로 유지하고 연결이 확인된 다른 DNS 업스트림으로 다시 테스트하세요. 특정 도메인에만 영향을 주는지도 기록하고, 기존 규칙을 바로 삭제하지 마세요.

오류: timed out

원인: 제한 시간 안에 응답을 받지 못했습니다. 어느 단계에서 발생했는지 표시되지 않았다면 DNS뿐 아니라 연결 또는 핸드셰이크 시간 초과일 수도 있습니다.

해결: 오류가 DNS 조회와 대상 연결 중 어느 단계에서 발생했는지 먼저 확인한 뒤 네트워크 환경을 비교하세요. DNS 조회가 시간 초과된 경우에만 DNS 업스트림 연결 상태를 우선 점검하세요.

NOERROR 응답을 받았어도 사용할 수 있는 주소를 얻었다는 뜻은 아닙니다. 응답에 해당하는 A 또는 AAAA 레코드가 없을 수 있습니다. 주소를 받은 뒤 TLS 인증서 오류나 HTTP 오류가 발생한다면 기기 시간, 대상 사이트, 연결 경로, 규칙을 확인하세요. 이때는 DNS만의 문제로 계속 다루지 마세요.

5. DNS 조회 성공 후 Global Routing과 규칙 적용 결과 확인하기

Home → Global Routing에서 Config는 현재 설정의 규칙에 따라 정책을 결정하고, Proxy는 트래픽을 프록시 정책으로 전달하며, Direct는 직접 연결 정책을 사용합니다. Scene은 현재 Scene 설정을 함께 확인해야 합니다. 이 모드 설정과 DNS 업스트림 선택은 별개의 항목입니다. Proxy로 전환해도 특정 DNS 서비스에 연결된다는 보장은 없습니다.

Config에서는 실패하지만 Proxy에서는 접속 가능: 같은 조건으로 여러 번 확인한 뒤 대상 도메인에 Direct, REJECT 또는 예상하지 못한 다른 정책이 적용됐는지 점검하세요. 이는 규칙 경로를 살펴볼 단서이지 DNS 문제가 완전히 배제됐다는 증거는 아닙니다.
주소를 받았지만 연결 시간 초과: 대상 연결이 성공하는지 확인하고 필요한 경우 IPv4와 IPv6 경로를 각각 살펴보세요. A 레코드는 IPv4, AAAA 레코드는 IPv6에 해당합니다. AAAA 레코드가 반환됐다고 IPv6 경로를 사용할 수 있다는 뜻은 아닙니다.
페이지 이미지나 로그인의 일부만 실패: 주소 표시줄의 도메인뿐 아니라 실패한 리소스의 도메인도 확인하세요. 하나의 페이지가 여러 도메인에 의존할 수 있으므로, 그중 하나의 DNS 조회나 정책에 문제가 있으면 페이지 일부가 비어 보일 수 있습니다.

[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY

아래 내용은 규칙의 의미를 설명하기 위한 예시이며 기존 규칙을 그대로 대체하면 안 됩니다. DOMAIN-SUFFIX는 example.com과 그 하위 도메인에 적용됩니다. FINAL은 앞선 규칙이 하나도 일치하지 않을 때 적용되는 기본 규칙입니다. 규칙은 순서대로 확인되므로 앞쪽의 넓은 조건이 이미 정책을 결정할 수 있습니다. IP-CIDR와 GEOIP는 대상 IP를 기준으로 하므로 주소를 받은 뒤 어떤 규칙이 적용되는지도 살펴보세요. 이 항목들은 DNS 서버 설정이 아닙니다.

6. 복구 확인 및 자주 묻는 질문

효과가 있는 변경을 찾으면 최종 설정과 간단한 기록을 보관하세요. 기록에는 원래 증상, 변경한 줄, 사용한 네트워크, 테스트한 URL과 결과를 남기면 됩니다. 임시로 바꾼 Global Routing과 On Demand를 일상 설정으로 복원한 다음 다시 테스트하세요. Config로 돌아간 뒤 문제가 재발한다면 규칙을 계속 점검하세요. 임시 전환만으로 문제를 덮어 둔 채 장기간 사용하지 마세요.

DNS를 바꿨는데 결과가 그대로인 이유는 무엇인가요?

Config에서 현재 선택된 파일을 수정했는지, 변경 사항을 저장했는지 먼저 확인하세요. 다시 연결한 다음 테스트 앱을 종료했다가 다시 열어 시도하세요. 캐시에 이전 결과가 남아 있을 수 있으므로 첫 재검사에서 변화가 없다고 여러 설정을 연달아 바꾸지 마세요.

웹사이트 IP 주소를 직접 입력하면 DNS 문제인지 확인할 수 있나요?

신뢰할 수 있는 판단 방법은 아닙니다. HTTPS는 인증서 검증과 사이트 선택에 도메인을 사용하므로 IP 주소로 직접 접속하면 다른 사이트가 열리거나 인증서 오류가 발생할 수 있습니다. IP 주소로 URL을 대신하지 말고 같은 도메인의 DNS 응답과 이후 연결 결과를 비교하세요.

셀룰러 네트워크로 바꾸면 접속되는 이유는 무엇인가요?

서버와 설정을 그대로 둔 채 다시 테스트하세요. 차이가 반복해서 나타난다면 Wi-Fi 인증 상태, 시스템 DNS, 사용 중인 DNS 전송 방식에 대한 제한을 확인하세요. dns-server = system으로 복원해 비교한 다음 사용자 지정 설정을 유지할지 결정하세요.

웹페이지는 복구됐는데 구독 업데이트가 계속 실패하면 어떻게 해야 하나요?

구독 업데이트는 별도의 요청 경로를 사용합니다. 먼저 기존 구독 링크가 유효한지 확인한 다음 서비스 제공업체에 접속 제한이나 계정 상태 문제가 있는지 문의하세요. 웹페이지가 복구됐다고 해서 구독 도메인, 인증 매개변수, 서버 응답까지 모두 정상이라고 단정하지 마세요.

같은 URL이 연속해서 열리고 페이지에 필요한 주요 리소스도 로드됩니다.
일상적으로 사용하는 Global Routing으로 돌아간 뒤에도 접속이 되며, 임시 테스트 모드가 남아 있지 않습니다.
On Demand가 원래 계획대로 복원됐고 구독 및 설정 백업도 보관되어 있습니다.
문제 해결 자료를 공유하기 전에 구독 주소의 token, 인증 정보, 연결 키를 삭제했습니다.