지연 수치만으로 대상 웹사이트의 DNS, 연결, TLS가 모두 정상이라고 단정할 수는 없습니다. 이미 자체 서버나 구독을 이용 중인데 웹페이지가 열리지 않는다면, 먼저 테스트 조건을 고정하고 DNS 응답을 확인한 뒤 Global Routing과 규칙 기록을 비교해 DNS 문제와 아웃바운드 연결 문제를 구분하세요. 한 번에 하나씩만 변경하고, 복구에 필요한 기존 설정을 기록해 두세요.
01 지연 테스트가 정상이어도 웹사이트 접속이 정상인 것은 아닙니다
Shadowrocket의 서버 테스트와 브라우저에서 특정 도메인에 접속하는 요청은 서로 다릅니다. 테스트 방식에 따라 확인하는 단계도 달라집니다. 서버 포트에 연결할 수 있어도 대상 도메인이 올바른 IP 주소를 받았다는 뜻은 아니며, 테스트 대상 하나가 응답해도 다른 웹사이트의 모든 리소스에 접속할 수 있다는 뜻은 아닙니다.
일반적인 웹페이지 접속은 다음과 같은 단계로 나눠 살펴볼 수 있습니다. 실제로는 규칙 판정과 DNS 조회가 서로 맞물릴 수 있습니다. 예를 들어 도메인 규칙은 먼저 적용될 수 있지만, IP 규칙은 DNS 조회 결과가 필요할 수 있습니다. 이 흐름은 문제를 찾기 위한 기준이며, 앱 내부의 모든 요청이 반드시 같은 순서로 처리된다는 의미는 아닙니다.
- 서버를 찾을 수 없음: 도메인 철자와 DNS 응답부터 확인하세요. 브라우저의 안내 문구만으로 서버를 사용할 수 없다고 단정하지 마세요.
- 계속 기다린 뒤 시간 초과: DNS 조회, 연결, 원격 서버 응답 중 어느 단계에서든 시간 초과가 발생할 수 있으므로 기록을 확인해 원인을 구분하세요.
- 인증서 경고가 표시됨: 기기의 날짜와 시간, 도메인, 인증서 정보를 확인하세요. 인증서 검증을 무시하는 방식으로 해결하지 마세요.
- 본문은 표시되지만 이미지가 누락됨: 페이지 리소스가 다른 도메인에서 제공될 수 있습니다. 주소 표시줄의 도메인만 확인하지 말고 실패한 요청을 하나씩 살펴보세요.
02 현재 상태를 기록한 뒤 Settings → DNS 확인하기
Home에서 현재 서버와 Global Routing 선택 항목을 기록한 다음 Config에서 사용 중인 구성을 확인하세요. 이어서 Settings → DNS로 이동해 현재 DNS 설정을 기록합니다. 구성 파일에 DNS 관련 항목이 있다면 함께 확인하세요. 한 화면만 살펴보면 DNS 동작에 영향을 주는 설정을 놓칠 수 있습니다.
이 절에서는 각 설정의 역할을 설명하며, 특정 구성의 기본값이 모든 기기에서 같다고 가정하지 않습니다. 실제 항목과 사용 가능한 옵션은 현재 앱 화면을 기준으로 확인하세요. 점검할 때는 모든 스위치를 켜기보다 ‘어디에 질의하는지, 어떤 경로로 연결되는지, 조회 결과가 로컬에서 지정되어 있는지’를 확인하는 것이 중요합니다.
| 확인 항목 | 역할 | 확인할 내용 |
|---|---|---|
| DNS 서버 | 도메인 조회를 받아 결과 반환 | 주소를 올바르게 입력했는지, 현재 네트워크에서 해당 서버에 연결할 수 있는지 확인합니다. |
| DNS 조회 전송 방식 | 조회 요청을 전송하는 방식 결정 | 일반 DNS와 암호화 DNS는 주소 형식이 다릅니다. 포트만 바꿨다고 프로토콜까지 변경된 것은 아닙니다. |
| 로컬 매핑 | 특정 도메인의 주소 지정 | 오래된 주소가 남아 있는지, 특정 웹사이트가 더 이상 유효하지 않은 주소로 고정되어 있는지 확인합니다. |
| 구성에 포함된 DNS 설정 | 현재 구성의 DNS 조회 동작에 반영 | 현재 활성화된 Config가 방금 수정한 파일인지, 중복되거나 충돌하는 설정이 있는지 확인합니다. |
| IPv4 / IPv6 | 서로 다른 주소 체계와 네트워크 경로에 대응 | AAAA 응답을 받았다고 해서 현재 네트워크의 IPv6 아웃바운드 연결까지 반드시 작동하는 것은 아닙니다. |
아래 포트는 프로토콜에서 흔히 사용하는 값이며 Shadowrocket에 하나씩 입력하라는 권장 설정이 아닙니다. 서비스에서 기본값이 아닌 포트를 사용할 수도 있으므로, 사용 중인 DNS 서비스의 실제 설정을 확인하세요. 암호화된 조회도 먼저 연결이 가능해야 하며, 잘못된 라우팅이나 작동하지 않는 서버를 자동으로 해결해 주지는 않습니다.
요약: 먼저 조회가 전달되는지, 다음으로 응답이 올바른지 확인하세요
현재 DNS 서버에 연결할 수 없다면 먼저 기록해 둔 사용 가능한 설정으로 복구하세요. 주소가 반환되었다면 해당 주소로 이어지는 아웃바운드 경로를 확인합니다. ‘DNS 응답을 받음’과 ‘웹페이지가 열림’을 같은 검사로 취급하지 마세요.
03 같은 도메인으로 재현 가능한 테스트하기
실제로 열리지 않는 전체 URL 하나를 테스트 대상으로 정하고, 테스트 시간과 당시 네트워크를 기록하세요. Wi-Fi를 바꾸면서 서버, DNS, 규칙까지 동시에 변경하면 접속이 복구되어도 어떤 변경이 원인이었는지 알 수 없습니다.
- 기존 설정 저장: Home의 서버, Global Routing, Config 파일과 Settings → DNS 내용을 기록하세요. 구성 파일을 수정하기 전에 사본을 보관하세요.
- 기준 상태 확인: 기존 설정을 유지한 채 같은 URL을 다시 요청하고, 해당 요청의 연결 기록이나 로그를 확인하세요. 도메인, 조회 결과, 적용된 규칙, 정책, 오류 메시지를 중점적으로 살펴보세요. 표시되는 항목은 실제 기록에 따라 다를 수 있습니다.
- 응답과 시간 초과 구분: DNS 응답 코드가 명확히 표시되면 먼저 그 의미를 확인하세요. 응답 없이 대기 시간만 초과되었다면 DNS 서버에 연결할 수 있는지부터 살펴보세요. 시간 초과만으로 도메인이 존재하지 않는다고 판단할 수는 없습니다.
- DNS 설정 하나만 변경: 직접 확인한 사용 가능한 DNS 설정이 있다면 일시적으로 바꿔 비교해 볼 수 있습니다. 저장한 뒤 연결을 다시 설정하고 같은 URL에 접속하세요. 나머지 조건은 그대로 유지합니다.
- 캐시 영향 재확인: 페이지를 새로고침해도 기존 연결이나 캐시가 사용될 수 있습니다. 필요한 경우 해당 페이지를 닫고 브라우저를 완전히 종료한 뒤 다시 여세요. 연결을 다시 설정해도 앱의 모든 캐시가 즉시 지워지는 것은 아닙니다.
- 원래대로 복구하고 재검사: 개선되지 않았다면 기존 DNS 설정으로 되돌린 뒤 규칙과 아웃바운드 경로를 확인하세요. 설정을 바꾼 뒤 문제가 해결된 것처럼 보여도 다시 테스트해 일시적인 복구를 설정 개선으로 오인하지 않도록 하세요.
04 DNS 오류를 구분하고 모든 시간 초과를 DNS 문제로 보지 않기
아래는 DNS 응답 코드와 시스템 네트워크 오류의 원문입니다. Shadowrocket에 매번 같은 문구가 표시된다는 뜻은 아닙니다. 브라우저에는 간략한 안내만 표시될 수 있으므로, 진단 결과나 로그에서 해당 문구를 실제로 확인한 경우에만 그에 맞춰 점검하세요.
DNS 응답: NXDOMAIN
원인: 조회한 도메인이 존재하지 않는다는 응답입니다. 조회 이름을 잘못 입력했거나 비정상적인 응답을 받은 경우에도 나타날 수 있습니다.
해결 방법: 전체 도메인과 철자를 확인한 뒤, 사용 가능 여부를 직접 확인한 다른 DNS 경로와 비교하세요. 여러 조회 경로에서 같은 결과가 나오면 웹사이트 관리자에게 도메인 상태를 문의하세요.
DNS 응답: SERVFAIL
원인: DNS 서버가 이번 조회를 완료하지 못했다는 의미입니다. 상위 DNS 조회, 권한 DNS 서버 또는 검증 단계에 문제가 있을 수 있습니다.
해결 방법: 도메인과 발생 시간을 기록하고, 사용 가능하다고 확인한 다른 DNS 경로로 다시 테스트하세요. 이 응답을 도메인이 존재하지 않는다는 뜻으로 받아들이거나, 이를 이유로 TLS 검증을 끄지 마세요.
시스템 오류: The request timed out.
원인: 제한 시간 안에 요청이 완료되지 않았다는 뜻입니다. 이 문구만으로 DNS, 연결, 웹페이지 응답 중 어느 단계에서 시간 초과가 발생했는지는 알 수 없습니다.
해결 방법: 시간 초과 전에 DNS 주소와 연결 기록이 있었는지 확인하세요. 응답이 없었다면 조회 경로를 점검하고, 주소가 있었다면 정책, 서버, 대상 사이트 연결을 확인하세요.
기록에 유효한 주소가 표시된 뒤 연결 실패가 나타났다면 아웃바운드 경로를 중점적으로 살펴보세요. 반대로 조회 결과가 계속 없다면 웹페이지 프로토콜을 반복해서 바꾸거나 FINAL을 수정해도 실제 문제가 해결되지 않을 수 있습니다.
05 Global Routing으로 비교하고 Config 규칙 적용 확인하기
Home → Global Routing에서 Proxy, Direct, Config, Scene은 서로 다른 라우팅 선택 방식입니다. 문제를 확인하기 전에 현재 선택 항목을 기록하세요. Scene을 사용 중이라면 현재 Scene이 실제로 어떤 동작을 적용하는지도 확인해야 합니다. 연결 스위치가 켜져 있다는 이유만으로 웹사이트 요청이 선택한 서버를 거친다고 단정하지 마세요.
같은 네트워크, 같은 서버, 같은 URL을 사용해 Config와 Proxy를 잠시 비교할 수 있습니다. Proxy에서는 접속되지만 Config에서는 실패한다면 규칙 적용 결과와 구성 차이를 먼저 확인하세요. 다만 이 비교만으로 원인을 확정할 수는 없습니다. 라우팅을 바꾸면 DNS 조회가 통과하는 경로도 달라질 수 있으므로 기록을 함께 살펴보세요.
| 비교 결과 | 다음 점검 항목 |
|---|---|
| Proxy에서는 접속되지만 Config에서는 실패 | 대상 도메인에 DIRECT, REJECT 또는 잘못된 정책이 적용되는지 확인하고 DNS 조회 결과도 비교하세요. |
| Direct에서는 접속되지만 Proxy에서는 실패 | 선택한 서버의 실제 접속 가능 여부, 원격 DNS 조회, 대상 사이트 연결을 확인하세요. 지연 수치만 보지 마세요. |
| 여러 라우팅 방식에서 모두 실패 | 도메인 상태, DNS 응답, 현재 네트워크와 웹사이트 자체를 확인하세요. 곧바로 Config 규칙 문제라고 단정하지 마세요. |
| 네트워크를 바꾸면 접속됨 | 두 네트워크의 DNS 연결 가능 여부, IPv6 경로, 연결 제한을 비교하고 나머지 설정은 그대로 유지하세요. |
아래는 규칙 문법과 순서를 설명하기 위한 예시이며, 예약된 예시 도메인을 사용합니다. 모든 웹사이트 문제를 바로 해결하는 설정이 아닙니다. Config 전체를 이 두 줄로 덮어쓰지 말고 기존 규칙에서 관련 항목을 확인하세요.
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTDOMAIN-SUFFIX는 도메인 접미사로 일치 항목을 찾습니다. 예시에서는example.com과 그 하위 도메인이 일치합니다.IP-CIDR와GEOIP는 IP 조건을 기준으로 판정합니다. 실제 조회된 IP 주소와 구성에 설정된 DNS 처리 옵션을 함께 확인하세요.- 규칙은 순서대로 확인되며, 일치하는 규칙이 있으면 해당 정책이 적용됩니다. 앞쪽 규칙이 먼저 일치한다면 새 규칙을 뒤에 추가해도 결과가 달라지지 않을 수 있습니다.
FINAL은 앞선 규칙에 하나도 일치하지 않을 때 적용되는 기본 규칙입니다. 이를PROXY로 바꾸면 기본 규칙에 해당하는 모든 요청에 영향을 줍니다. 특정 도메인의 DNS 조회 실패를 해결하는 기본 방법으로 사용하지 마세요.
비교 테스트가 끝나면 평소 사용하는 Global Routing 설정으로 복원하세요. 구성 변경 후 문제가 시작되었다면 해당 변경부터 되돌리고 규칙을 하나씩 확인하세요. 기존 구독을 업데이트하면 서버 정보가 새로고침될 수 있지만, 현재 Config의 DNS나 규칙까지 수정되는 것은 아닙니다. 각각 별도로 점검하세요.
06 자주 묻는 질문과 진단 정보 준비
지연 시간은 짧은데 일부 웹페이지만 열리지 않는 이유는 무엇인가요?
지연 테스트는 모든 웹사이트와 리소스 도메인을 확인하지 않습니다. 먼저 접속에 실패한 URL을 기록하고 Config에서 실제 적용된 정책을 확인한 다음 Proxy와 비교하세요. 이미지나 로그인 단계만 실패한다면 해당 리소스 도메인도 확인하세요. 같은 서버 포트만 반복해서 테스트할 필요는 없습니다.
DNS를 바꾸자 접속이 복구됐는데 계속 사용해야 하나요?
먼저 같은 네트워크에서 다시 테스트하고 기존 DNS가 시간 초과되었는지, 비정상적인 결과를 반환했는지 확인하세요. 새 설정이 안정적으로 작동하고 사용 중인 DNS 서비스의 실제 설정과 일치한다면 유지할 수 있습니다. 기존 값도 기록해 두세요. 한 번 성공한 것만으로 캐시, 웹사이트의 일시적인 장애, 네트워크 변경의 영향을 배제할 수는 없습니다.
Wi-Fi에서는 안 되고 모바일 네트워크에서는 되는데 IPv6를 꺼야 하나요?
먼저 조회된 A 및 AAAA 주소와 실제 연결 상태를 비교하세요. AAAA 응답이 있어도 IPv6 경로가 작동한다고 볼 수는 없지만, 그렇다고 IPv6를 계속 꺼야 한다는 뜻도 아닙니다. 관련 설정을 바꾼다면 한 번에 하나만 변경해 비교하고, 테스트 결과를 기록하거나 원래 값으로 복구하세요.
연결을 꺼도 다시 자동 연결되는데 어떻게 연결 해제 상태를 비교하나요?
Settings → On Demand에서 요청 시 연결이 활성화되어 있는지 확인하세요. 기존 상태를 기록한 다음 일시적으로 비활성화하고, 연결이 끊긴 상태를 비교 테스트하세요. 테스트가 끝나면 필요한 설정으로 복구합니다. On Demand는 연결이 시작되는 조건을 제어하며 DNS 응답이나 규칙 내용을 수정하지 않습니다.
추가 지원을 요청할 때는 지연 수치 하나만 보내기보다 문제를 재현할 수 있는 조건을 함께 제공하는 것이 좋습니다. 기록에 구독 주소, 서버 인증 정보, 개인 요청 내용이 포함되어 있다면 민감한 정보는 가리고 문제를 파악하는 데 필요한 항목만 남기세요.
- 기기 종류와 현재 네트워크 종류, 문제가 특정 네트워크에서만 발생하는지 여부
- 접속에 실패한 도메인, 발생 시간, Global Routing 선택 항목, 사용 중인 Config
- DNS 응답 여부와 실제 응답 코드, 이후 연결이 수립되었는지 여부
- 적용된 규칙의 정책, Config와 Proxy 비교 결과, 되돌린 설정 변경 사항