Shadowrocket DNS 설정 및 오류 해결: 지연 테스트는 정상인데 웹페이지가 열리지 않을 때

핵심 내용

이 글은 Shadowrocket에 이미 보유한 서비스를 추가하고 연결 스위치도 정상적으로 작동하지만 도메인에 접속할 수 없는 경우를 다룹니다. 서버 연결, Global Routing, DNS, 규칙, 네트워크 환경 순으로 확인하고, 한 번에 한 가지씩 테스트해 DNS 조회 실패와 연결 실패, 웹사이트 자체의 문제를 구분하세요. 설정 예시는 문제 해결 방법만 설명하며 서버나 구독은 제공하지 않습니다.

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

지연 테스트 결과는 해당 테스트 방식이 확인하는 경로에만 해당합니다. 서버 포트 연결 여부만 확인하는 테스트로는 대상 도메인의 DNS 조회가 가능한지, 서버에서 대상 웹사이트까지 연결되는지 알 수 없습니다. HTTP 테스트를 사용하더라도 결과는 테스트 주소와 해당 시점의 경로에 한정되므로 실제 접속에 실패한 웹사이트를 따로 확인해야 합니다.

브라우저에서 HTTPS 웹페이지를 열려면 일반적으로 도메인 조회, 대상 주소 연결, TLS 협상, HTTP 요청 과정을 거칩니다. DNS는 도메인에 대응하는 주소를 찾아 주지만 만료된 서버 인증 정보를 갱신하거나 웹사이트의 접속 제한을 해제하지는 않습니다. ‘연결 정상’으로 표시되더라도 요청이 어느 단계에서 멈췄는지 확인해야 합니다.

확인된 현상	알 수 있는 내용	다음 확인 항목
서버 지연 테스트 결과가 표시됨	테스트에서 확인한 경로가 응답함	대상 도메인 조회 및 실제 요청
도메인 조회 결과로 A 또는 AAAA가 반환됨	IPv4 또는 IPv6 주소를 받음	해당 주소에 연결 가능한지, TLS가 성공하는지
웹페이지에서 HTTP 403 반환	요청이 응답 가능한 HTTP 서비스에 도달함	웹사이트의 접속 정책 및 출구 경로 제한
특정 웹사이트 하나만 접속 실패	문제가 해당 도메인이나 경로에 국한됐을 가능성	관련 규칙, 조회 결과, 웹사이트 상태

요약: 먼저 실패가 발생한 단계를 확인하세요

실패한 도메인과 원래 표시된 오류를 기록하세요. HTTP 상태 코드가 있다면 웹사이트의 응답부터 확인하고, DNS 변경을 첫 단계로 삼지 마세요.

2. 재현 가능한 문제 해결 기준 마련하기

시작하기 전에 Config에서 현재 설정을 백업하고, Home에서 선택된 서버와 Global Routing 상태를 기록하세요. 최근 보유 중인 구독을 갱신했다면 서버 주소, 포트, 인증 정보가 바뀌었는지도 확인합니다. 구독 갱신에 성공했다는 것은 구독 내용을 가져오는 요청이 성공했다는 뜻일 뿐, 그 안의 모든 서비스가 작동한다는 의미는 아닙니다.

실패 사례 기록

접속에 실패한 도메인 하나와 평소 접속할 수 있는 도메인 하나를 고르고, 전체 오류 문구와 발생 시각, 현재 Wi-Fi 또는 셀룰러 네트워크를 기록하세요. 이후에는 같은 페이지를 대상으로 테스트해 비교 대상이 달라져 잘못 판단하는 일을 방지합니다.
서버 확인

Home에서 선택된 서버를 확인하고 현재 사용할 수 있는 지연 또는 연결 테스트를 실행하세요. 서버 자체에 연결할 수 없다면 보유 중인 서비스의 안내 정보를 바탕으로 주소, 포트, 인증 정보를 먼저 확인하고 DNS 설정을 시험 변경하지 마세요.
라우팅 모드 기록

Home → Global Routing을 열어 현재 모드가 Proxy, Direct, Config, Scene 중 무엇인지 기록하세요. 문제를 확인하는 동안에는 모드를 고정합니다. Scene을 사용한다면 실제로 적용 중인 Scene을 확인해 네트워크 전환과 라우팅 방식 변경이 동시에 일어나지 않도록 하세요.
자동 재연결 확인

Settings → On Demand를 확인하세요. 연결을 끈 상태와 켠 상태를 비교하려면 먼저 기존 설정을 기록한 뒤 자동 연결을 잠시 비활성화해 연결을 끈 직후 다시 연결되지 않도록 하세요. 확인이 끝나면 원래 설정으로 복원합니다.
설정 하나씩 변경해 재테스트

한 번에 설정 하나만 변경하고 저장한 다음 연결을 다시 설정해 동일한 도메인들을 방문하세요. 결과를 기록한 뒤 변경 사항을 유지하거나 되돌리세요. 서버와 DNS, 전체 설정을 한꺼번에 바꾸지 마세요.

3. DNS 설정에서 시스템 조회와 설정 덮어쓰기를 구분하세요

Config에서 현재 사용 중인 설정을 열고 편집 화면으로 이동해 [General]에 dns-server가 설정되어 있는지 확인하세요. 사용하지 않는 다른 설정만 살펴보지 마세요. 다른 DNS 관련 설정도 사용 중이라면 함께 기록해 변경하려는 항목이 실제 적용 중인 다른 설정에 의해 덮어쓰이지 않도록 합니다.

system은 시스템에서 제공하는 DNS를 사용한다는 뜻입니다. 비교 기준으로 적합하지만 모든 네트워크에서 같은 결과를 얻는다는 의미는 아닙니다. Wi-Fi, 셀룰러 네트워크, 기기의 DNS 설정이 시스템 조회에 영향을 줄 수 있습니다. DNS 서버를 직접 지정한다면 주소가 올바른지만 확인하지 말고 현재 네트워크에서 해당 서버에 연결할 수 있는지도 확인하세요.

# 관련 항목만 보여 주는 예시입니다. 이 내용으로 전체 설정을 덮어쓰지 마세요.
[General]
dns-server = system

위 예시는 해당 항목의 위치를 보여 줍니다. 실제 테스트에서는 현재 사용 중인 [General]에서 해당 줄만 수정하고 나머지 설정은 유지하세요. 같은 이름의 섹션이나 항목을 중복으로 추가하지 마세요. 기존 값을 기록한 다음 저장하고 연결을 다시 설정해 테스트합니다. 개선되지 않으면 기존 값을 복원한 뒤 다음 항목을 확인하세요.

항목	의미	확인할 점
A	도메인에 대응하는 IPv4 주소 레코드	결과가 반환되면 해당 IPv4 경로에 연결할 수 있는지 확인
AAAA	도메인에 대응하는 IPv6 주소 레코드	주소를 받았는지와 실제 IPv6 경로를 사용할 수 있는지 구분
기존 DNS	일반적으로 UDP 53을 사용하고 필요한 경우 TCP 53을 사용	현재 네트워크가 조회를 제한하거나 비정상적인 결과를 반환하는지
DNS over HTTPS	HTTPS로 DNS 조회를 전송하며 일반적으로 TCP 443을 사용	DNS 서버에 연결할 수 있는지, 서버 도메인을 처음에 어떻게 조회하는지
DNS 캐시	유효 기간 동안 이전 조회 결과를 재사용	설정 변경 후에도 기존 연결이나 이전 결과를 보고 있는지

암호화 DNS는 조회를 전송하는 방식을 바꾸지만 모든 DNS 문제를 자동으로 해결하지는 않습니다. DNS 서버 자체에 연결할 수 없거나 서버 도메인의 초기 조회에 실패해도 시간 초과가 발생할 수 있습니다. 브라우저나 다른 앱이 별도의 조회 방식을 사용하면 Shadowrocket 설정과 다른 결과가 나올 수도 있으므로 테스트 중에는 같은 앱을 사용하세요.

4. 오류를 바탕으로 레코드 없음, 서버 오류, 시간 초과 구분하기

아래는 DNS 진단에서 흔히 볼 수 있는 상태 또는 오류 문자열이며, Shadowrocket의 모든 화면에 그대로 표시된다는 뜻은 아닙니다. 브라우저에는 요약된 오류만 표시될 수 있습니다. 현재 확인할 수 있는 로그, 요청 기록, 조회 결과를 함께 살펴보고 ‘웹페이지를 열 수 없음’이라는 문구만으로 원인을 단정하지 마세요.

오류: NXDOMAIN

원인: 응답 서버가 조회한 도메인이 존재하지 않는다고 알립니다. 도메인 오타, 만료된 도메인, 비정상적인 DNS 응답 등이 원인일 수 있습니다.

해결 방법: 먼저 전체 도메인 이름이 올바른지 확인한 다음 다른 네트워크에서 비교하세요. 한쪽 조회 경로에서만 문제가 발생한다면 양쪽 결과를 기록하고 현재 DNS 출처와 로컬 설정 덮어쓰기를 확인합니다.

오류: SERVFAIL

원인: DNS 서버가 조회를 완료하지 못한 상태입니다. 상위 DNS 서버 조회 실패, 도메인 권한 서버 문제, 검증 오류 등이 원인일 수 있으며 도메인이 존재하지 않는다는 뜻은 아닙니다.

해결 방법: 정상 작동이 확인된 다른 도메인으로 특정 도메인만의 문제인지 확인하세요. 라우팅은 그대로 둔 채 연결 가능 여부가 확인된 다른 DNS 방식으로 전환해 다시 테스트합니다.

오류: connection timed out

원인: 지정된 작업이 제한 시간 내에 완료되지 않았다는 뜻입니다. DNS 조회 단계에서 발생한 것이 명확한 경우에만 DNS 시간 초과로 판단할 수 있습니다.

해결 방법: 먼저 시간 초과가 DNS 서버, 프록시 서버, 대상 웹사이트 중 어디에서 발생했는지 확인하세요. 그런 다음 해당 포트와 네트워크 경로를 점검해 대상 웹사이트의 TCP 시간 초과를 DNS 문제로 오인하지 않도록 합니다.

AAAA 레코드가 없다고 해서 반드시 오류인 것은 아닙니다. 일부 도메인은 A 레코드만 제공합니다. 조회에 성공했지만 요청한 유형의 레코드가 없는 경우도 NXDOMAIN과는 다릅니다. ‘IP가 없음’이라고만 기록하지 말고 조회한 이름과 레코드 유형, 반환 상태를 함께 기록하세요.

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

Global Routing의 Proxy, Direct, Config, Scene은 라우팅 방식이지 DNS 서버 설정이 아닙니다. Proxy는 프록시 라우팅, Direct는 직접 연결, Config는 현재 설정에 따른 처리, Scene은 현재 Scene 설정에 따른 동작을 의미합니다. 모드를 바꿔 비교할 수는 있지만, 특정 모드에서 모든 DNS 조회가 반드시 로컬이나 원격으로 처리된다고 단정할 수는 없습니다.

같은 도메인이 Proxy에서는 열리고 Config에서는 열리지 않는다면 다음으로 Config에서 실제 적용되는 규칙을 확인하세요. Direct에서는 열리지만 Proxy에서 실패한다면 서버에서 대상 웹사이트까지의 경로도 확인해야 합니다. 어느 경우든 DNS 문제라고 단정할 수는 없습니다.

# 규칙 문법과 순서를 설명하기 위한 예시입니다. 그대로 대체해 사용할 수 있는 전체 설정이 아닙니다.
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,REJECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

DOMAIN-SUFFIX,example.com,DIRECT는 해당 도메인과 하위 도메인에 일치합니다. 실패한 도메인이 예상과 다른 정책에 앞서 일치하는지 확인하세요.
IP-CIDR은 IP 주소 범위에 일치합니다. 예시의 192.0.2.0/24는 문서용 예시 네트워크이며 실제 서비스 주소가 아닙니다.
no-resolve는 IP 규칙과 일치시키기 위해 도메인을 별도로 조회하지 않도록 합니다. 전체 설정에서 DNS를 비활성화하거나 요청이 다른 단계에서 주소를 얻는 것을 막는다는 뜻은 아닙니다.
GEOIP는 IP가 속한 지역을 기준으로 일치 여부를 판단합니다. 도메인 요청에 조회가 필요한지는 기존 주소와 규칙 매개변수를 함께 고려해야 합니다.
FINAL은 마지막에 두어 앞선 규칙에 일치하지 않은 요청을 처리합니다. 기본 적용 정책이 예상한 경로를 가리키는지 확인하세요. 특정 도메인 규칙 하나만 확인해서는 충분하지 않습니다.

요약: 주소를 받았는데도 실패한다면 실제 적용된 정책을 확인하세요

DNS는 그대로 둔 채 Proxy와 Config의 접속 결과만 비교하세요. 차이가 반복해서 나타난다면 DNS 설정을 더 변경하기보다 규칙과 선택된 출구 경로부터 확인합니다.

6. Wi-Fi, 셀룰러 네트워크, IPv6 비교하기

같은 설정에서 Wi-Fi는 실패하고 셀룰러 네트워크에서는 성공한다면 네트워크 환경이 중요한 변수라는 뜻입니다. 그렇다고 Wi-Fi의 DNS가 잘못됐다고 단정할 수는 없습니다. 네트워크가 서버 포트를 제한하거나 IPv6 경로에 영향을 주거나 로그인 인증을 요구할 수도 있습니다. 네트워크를 바꾼 뒤에는 연결을 다시 설정하고 Global Routing 및 서버 선택이 Scene 변경에 따라 바뀌지 않았는지 확인하세요.

먼저 네트워크 인증 완료: 공용 Wi-Fi에서 로그인이 필요하면 인증을 완료한 다음 Shadowrocket을 테스트하세요. 인증 전 리디렉션이나 연결 차단으로 여러 웹사이트에 동시에 접속할 수 없는 것처럼 보일 수 있습니다.
같은 도메인으로 비교: 두 네트워크에서 같은 페이지에 접속해 DNS 조회 결과, 연결 시간 초과 여부, HTTP 상태 코드 발생 여부를 기록하세요. 지연 시간만 비교해서는 안 됩니다.
IPv6 경로 확인: 도메인에서 AAAA 레코드를 반환하더라도 현재 네트워크에서 IPv6 연결을 사용할 수 없다면 로딩이 지연되거나 일부 리소스만 실패할 수 있습니다. 먼저 실패한 요청에 실제로 어떤 주소 체계가 사용됐는지 확인하고 임시로 비교해 보세요. IPv6 비활성화를 일반적인 해결책으로 여기지 마세요.
캐시 영향 확인: 연결을 다시 설정하고 테스트 페이지를 다시 여세요. 앱이 자체 DNS 캐시나 연결 풀을 유지할 수 있으므로 필요한 경우 앱을 완전히 종료한 뒤 다시 여세요. 연결을 다시 설정해도 모든 앱의 캐시가 삭제된다고 보장할 수는 없습니다.

7. 자주 묻는 질문과 문제 해결 완료 기준

지연은 계속 정상인데 DNS만 바꾸면 되나요?

먼저 Home에서 서버와 Global Routing을 확인한 뒤 실패한 도메인의 주소 조회 결과를 살펴보세요. 이미 HTTP 오류나 TLS 오류가 반환됐다면 해당 단계의 문제를 확인해야 합니다. DNS 조회 단계에서 실패한 경우에만 DNS를 주요 변수로 다루세요.

dns-server를 바꿨는데 결과가 달라지지 않는 이유는 무엇인가요?

Config에서 현재 활성화된 설정을 수정했는지 확인하고 중복 항목이나 다른 적용 설정이 있는지도 살펴보세요. 저장 후 연결을 다시 설정하고 테스트 앱을 다시 열어 같은 도메인으로 재검사합니다. 앱 자체의 DNS 처리 방식과 캐시도 확인하세요.

웹사이트 하나만 열리지 않아도 설정을 다시 만들어야 하나요?

먼저 도메인 철자와 해당 도메인의 조회 결과, Config에서 실제 적용되는 규칙을 확인한 다음 Proxy와 Direct의 결과를 비교하세요. 정상적으로 열리는 다른 웹사이트는 비교 대상으로 남겨 두고, 도메인 하나 때문에 전체 설정을 교체하지 마세요.

구독 갱신은 성공했는데 웹페이지가 열리지 않는 이유는 무엇인가요?

구독 갱신과 웹페이지 접속은 서로 다른 요청입니다. Home으로 돌아가 현재 실제로 선택된 서버를 확인하고, 보유 중인 서비스의 안내 정보를 바탕으로 설정을 점검한 다음 이 글의 순서대로 대상 도메인, 라우팅, DNS를 확인하세요. 구독 갱신 성공만으로 연결이 정상이라고 볼 수는 없습니다.

문제 해결을 마치기 전에 처음 실패한 도메인과 정상 비교용 도메인에 각각 다시 접속해 보세요. 그런 다음 잠시 비활성화한 On Demand와 기존 Scene 설정을 복원합니다. 개선 원인을 설명하는 데 필요한 최소한의 변경만 유지하고 효과가 없었던 테스트는 되돌리세요. 보유 중인 서비스의 지원 채널에 문의할 때는 실패 시각과 네트워크 유형, 관련 오류, 민감 정보를 삭제한 설정 일부를 제공하세요. 구독 토큰, 비밀번호 등 인증 정보는 제거해야 합니다.