Shadowrocket의 지연 시간 결과는 테스트 대상에 그 시점에 연결할 수 있음을 보여줄 뿐, 웹페이지 도메인 조회까지 성공했다는 뜻은 아닙니다. 사용할 서비스 정보와 구독을 이미 보유한 경우를 전제로, 기본 네트워크, DNS 응답, Global Routing, IPv6, 설정 덮어쓰기를 차례로 점검합니다. 기존 설정을 먼저 보관하고 한 번에 변수 하나만 변경한 뒤 같은 도메인으로 다시 테스트하세요.
1. 지연 시간은 정상인데 웹페이지가 열리지 않는 이유
웹페이지 접속은 단순한 지연 시간 테스트와 다릅니다. 브라우저는 보통 먼저 도메인을 IP 주소로 조회한 다음 연결을 설정하고 TLS 핸드셰이크를 완료한 뒤 페이지를 요청합니다. 서버 주소나 특정 테스트 대상을 확인하는 테스트만으로는 해당 웹페이지가 사용하는 DNS, 규칙 분기, 인증서 검증 과정까지 점검할 수 없습니다. 지연 시간이 짧게 표시되더라도 조회 문제를 배제할 수는 없습니다.
이 흐름은 문제가 발생한 단계를 찾기 위한 것이며, DNS 조회와 웹페이지 요청이 반드시 같은 경로로 나간다는 뜻은 아닙니다. DNS 전송 방식이 별도로 설정될 수 있고, 일부 연결은 원격에서 도메인을 처리할 수도 있습니다. 따라서 “노드 지연 시간 정상”과 “로컬 DNS 정상”은 서로 다른 결론입니다.
- 모든 웹사이트에 접속할 수 없음: 먼저 기본 네트워크, 터널 상태, DNS 업스트림 연결을 확인하세요. 특정 웹사이트의 규칙부터 변경하지 마세요.
- 특정 도메인 하나만 접속할 수 없음: 도메인 철자, 해당 도메인의 DNS 응답, 적용된 규칙을 확인하세요. 웹사이트 자체의 장애일 수도 있습니다.
- 홈페이지는 열리지만 이미지나 로그인이 실패함: 실패한 리소스가 실제로 사용하는 도메인을 확인하세요. 주소창의 기본 도메인만 테스트해서는 안 됩니다.
- 인증서 경고 또는 HTTP 403이 표시됨: DNS와는 다른 단계에서 발생한 문제입니다. “페이지가 열리지 않는다”는 이유만으로 DNS 실패라고 판단할 수 없습니다.
2. 재현 가능한 점검 기준 만들기
점검을 시작하기 전에 Home에서 현재 선택된 연결을 확인하고, Config에서 사용 중인 구성을 확인한 뒤 사본을 저장하세요. 이후 테스트에서는 같은 전체 URL을 사용하고 네트워크 종류, 시간, Global Routing 상태, 오류 양상을 기록합니다. 구독 갱신, 연결 변경, DNS 변경, 규칙 변경을 동시에 하면 어떤 항목이 영향을 미쳤는지 판단하기 어렵습니다.
- 기본 네트워크 확인: Shadowrocket 연결을 잠시 끊고 평소 접속되는 웹사이트를 열어 보세요. 공용 Wi-Fi에서 웹 인증이 필요하다면 먼저 인증을 완료하세요. 기본 네트워크에 연결되지 않는다면 Wi-Fi 또는 셀룰러 네트워크부터 점검합니다.
- 자동 재연결 제어: Settings → On Demand에서 자동 실행이 켜져 있는지 확인하세요. 연결 해제 상태와 비교하려면 관련 실행 조건을 잠시 비활성화한 뒤, 점검이 끝나면 복원하세요. 자동 재연결을 수동 연결 해제 테스트로 오해하지 않도록 주의합니다.
- 실패 상황 재현: 다시 연결한 뒤 문제가 발생한 URL에 접속하고, 오래 기다리는지, 도메인 오류가 표시되는지, 연결 시간이 초과되는지, TLS 오류가 발생하는지 기록하세요. 브라우저의 일반적인 오류 메시지만으로 DNS 조회 결과를 대신할 수는 없습니다.
- 네트워크를 바꿔 재시험: 가능하다면 같은 기기에서 Wi-Fi를 셀룰러 네트워크로 바꾸고 연결과 설정은 그대로 유지하세요. 특정 네트워크에서만 실패한다면 해당 네트워크에서 DNS 전송 또는 대상 주소에 연결할 수 있는지 집중적으로 확인합니다.
- 관련 기록 확인: Shadowrocket의 연결 기록, DNS 조회 결과 또는 현재 사용할 수 있는 진단 도구를 이용해 실패한 도메인, 응답 주소, 실제 적용된 정책을 확인하세요. 구체적인 메뉴 위치는 현재 앱 화면을 기준으로 확인합니다.
“웹사이트 IP 주소를 직접 열기”를 일반적인 확인 방법으로 사용하지 마세요. HTTPS 웹사이트는 도메인에 연결된 SNI, 인증서, 가상 호스트에 의존할 수 있습니다. IP 주소로 직접 접속에 실패해도 네트워크 연결에 문제가 있다는 증거는 아닙니다.
3. DNS 오류 응답과 무응답 구분하기
DNS 문제는 크게 두 가지입니다. 서버가 명확한 오류를 반환하거나, 조회에 유효한 응답이 돌아오지 않는 경우입니다. 두 상황의 해결 방법은 다릅니다. 아래는 DNS 프로토콜에서 실제 사용하는 상태 이름이며, Shadowrocket이나 브라우저에 반드시 그대로 표시되는 문구는 아닙니다. 일부 로그에는 일반적인 조회 실패 또는 시간 초과만 표시될 수 있습니다.
오류: NXDOMAIN
원인: 조회한 이름이 존재하지 않는다는 응답입니다. 잘못된 로컬 매핑이나 업스트림의 비정상 응답과 관련될 수도 있습니다. 해결: 전체 도메인이 맞는지 먼저 확인하고, 정상 작동이 확인된 다른 조회 경로에서 같은 레코드를 조회하세요. 존재하지 않는 이름은 대기 시간을 늘려도 해결되지 않습니다.
오류: SERVFAIL
원인: 리졸버가 조회를 완료하지 못한 상태입니다. 업스트림 권한 서버, 검증 과정 또는 일시적인 서비스 장애가 원인일 수 있습니다. 해결: 같은 리졸버로 정상 도메인을 조회한 다음, 문제가 발생한 도메인도 다른 경로에서 확인해 리졸버 전체 문제인지 특정 도메인 문제인지 구분하세요.
오류: REFUSED
원인: 서버가 해당 조회 요청을 거부한 상태입니다. 접근 제어 또는 현재 요청 출처의 재귀 조회를 허용하지 않는 설정에서 흔히 발생합니다. 해결: 해당 DNS 서비스의 사용 범위를 확인하고 현재 네트워크 또는 기존 설정에서 허용된 리졸버로 되돌리세요.
응답이 전혀 없다면 DNS 서버 주소, 전송 방식, 아웃바운드 경로를 중점적으로 확인하세요. NOERROR라고 해서 반드시 사용할 수 있는 주소를 얻었다는 뜻은 아닙니다. 조회 자체는 성공했지만 해당 레코드 유형이 없으면 답변 영역이 비어 있을 수 있습니다. AAAA 레코드만 조회되지 않고 A 레코드는 정상이라면 도메인 전체의 조회 실패는 아닙니다.
- A: IPv4 주소를 반환합니다. IPv4 조회가 정상인지 확인할 때 사용합니다.
- AAAA: IPv6 주소를 반환합니다. 주소를 확인한 뒤 현재 네트워크에서 사용할 수 있는 IPv6 경로가 있는지도 확인해야 합니다.
- CNAME: 별칭을 나타냅니다. 별칭이 가리키는 이름도 이어서 조회해야 하므로 기본 도메인에 응답이 왔다고 해서 전체 별칭 체인이 정상인 것은 아닙니다.
4. DNS 설정 항목별 기능
Shadowrocket에서 실제 적용되는 DNS 동작은 현재 설정에 따라 달라집니다. Config에서 활성화된 구성과 General 설정을 확인하세요. 텍스트로 확인할 때는 해당 항목이 [General] 등 관련 구성 섹션에 있습니다. 비활성화된 다른 구성의 값을 보고 현재 상태를 판단하거나, 서비스 정보에 적힌 서버 주소를 DNS 서버 주소로 잘못 입력하지 마세요.
| 설정 또는 개념 | 기능 | 변경 시점 및 주의 사항 |
|---|---|---|
dns-server |
DNS 업스트림을 지정합니다. 지원되는 주소 형식과 전송 방식은 현재 앱 설정 안내에 따라 입력해야 합니다. | 현재 사용 중인 업스트림에 연결할 수 없거나 응답이 비정상일 때 조정하세요. 주소를 여러 개 입력해도 항상 입력 순서대로 하나씩 시도한다는 뜻은 아닙니다. |
system |
이 값을 지원하는 DNS 설정에서 현재 시스템 네트워크가 제공하는 리졸버를 사용합니다. | 기존 상태와 비교할 때 사용할 수 있습니다. 실제 서버는 Wi-Fi, 셀룰러 네트워크 또는 네트워크 관리 설정에 따라 달라질 수 있습니다. |
fallback-dns-server |
보조 DNS 업스트림을 설정해 기본 조회 과정을 보완합니다. | 구체적인 활성화 조건은 현재 설정 방식에 따라 다릅니다. 모든 실패 요청이 자동으로 해결된다고 볼 수는 없습니다. |
ipv6 |
IPv6 관련 처리에 영향을 줍니다. 시스템, 터널, 실제 네트워크의 지원 여부를 함께 고려해야 합니다. | AAAA 응답은 정상인데 IPv6 연결이 실패할 때 변수를 하나씩 바꿔 비교하세요. 이 항목을 끄는 것이 모든 DNS 문제의 해결책은 아닙니다. |
[Host] |
로컬 도메인 매핑을 설정해 특정 도메인에서 최종적으로 사용하는 주소에 영향을 줄 수 있습니다. | 특정 도메인에서만 문제가 발생할 때 오래된 매핑이 있는지 확인하세요. 웹사이트 주소는 바뀔 수 있으므로 임시 IP를 정상적인 조회 대신 장기간 사용하지 마세요. |
도메인 이름을 사용하는 암호화 DNS 엔드포인트라면 엔드포인트 자체의 이름 조회와 연결 문제도 먼저 해결해야 합니다. 엔드포인트에 연결할 수 없다면 일반 DNS를 암호화 DNS로 바꾸는 것만으로 접속이 복구되지는 않습니다. 인증서 검증, 기기 시간, 엔드포인트가 사용하는 경로도 함께 확인하세요.
요약: 먼저 업스트림 연결을 확인한 뒤 조회 방식을 변경하세요
포트 번호는 전송 유형을 알아보는 데 도움이 될 뿐, 엔드포인트를 사용할 수 있다는 증거는 아닙니다. 현재 네트워크에서 같은 업스트림에 연결할 수 없다면 검증된 설정으로 먼저 되돌리세요. 그런 다음 일반 DNS와 암호화 DNS를 각각 테스트해 올바른 응답을 반환하는 방식을 유지합니다.
5. Global Routing으로 DNS 문제와 규칙 분기 문제 구분하기
Home → Global Routing에서 현재 상태를 확인하세요. 일상적인 규칙 설정을 사용할 때는 보통 Config를 점검해야 합니다. Proxy 또는 Direct로 잠시 전환하면 비교에 도움이 되지만 DNS의 모든 독립 설정을 덮어쓴다고 보장할 수는 없습니다. Scene은 시나리오 선택과 관련된 항목이므로 고정된 직접 연결 또는 프록시 정책으로 해석하면 안 됩니다.
| 상태 | 점검 목적 | 결과 해석 |
|---|---|---|
| Config | 현재 설정에서 요청에 적용된 규칙과 정책을 확인합니다. | 이 상태에서만 실패한다면 규칙 순서, 정책 그룹 선택, 구성의 DNS 설정을 중점적으로 확인하세요. |
| Proxy | 프록시 경로에서 대상 웹사이트에 접속할 수 있는지 임시로 비교합니다. | 접속이 복구되면 아웃바운드 경로를 점검할 필요가 있다는 뜻이지만, DNS가 해결됐다는 증거만으로 볼 수는 없습니다. |
| Direct | 대상에 직접 연결한 결과를 임시로 확인합니다. | 대상 자체가 직접 접속을 허용하고 실제로 접속할 수 있을 때만 유효한 비교가 됩니다. |
| Scene | 현재 시나리오에서 어떤 구성과 동작이 선택되어 있는지 확인합니다. | 먼저 시나리오 내용을 확인해 시나리오 전환으로 생긴 차이를 DNS의 무작위 오류로 오해하지 않도록 하세요. |
올바른 IP 주소를 확인했는데도 연결 시간이 초과된다면 아웃바운드 정책을 계속 점검하세요. 도메인 규칙과 IP 규칙은 같은 방식으로 적용되지 않습니다. DOMAIN-SUFFIX는 도메인 접미사를, IP-CIDR은 IP 주소 대역을 매칭하며, GEOIP는 IP 주소 위치 데이터베이스를 사용하고, FINAL은 앞에서 매칭되지 않은 요청을 처리합니다. 대상 IP가 필요한 매칭 과정에서는 조회가 이뤄질 수 있지만, no-resolve를 사용하면 규칙 매칭을 위해 조회가 시작될 것으로 기대해서는 안 됩니다.
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY위 내용은 규칙 문법의 예시일 뿐, 현재 구성을 그대로 교체하라는 뜻은 아닙니다. example.com은 예시 도메인이며, PROXY도 현재 구성에서 사용할 수 있는 정책이어야 합니다. 진단할 때는 실제 매칭 기록부터 확인하세요. 위쪽의 더 넓은 규칙이 이미 적용되었다면 뒤에 있는 수정 규칙은 적용되지 않습니다. FINAL은 마지막에 두어야 합니다.
6. 조회에 성공해도 접속되지 않을 때: IPv6, 캐시, 설정 덮어쓰기 확인
DNS가 주소를 반환하는 것은 첫 단계일 뿐입니다. A와 AAAA 모두 결과가 있지만 특정 네트워크에서 IPv6 경로에만 문제가 있다면, 브라우저가 실패하는 경로를 기다렸다가 다른 경로를 시도할 수 있습니다. 이 때문에 로딩이 오래 걸리거나 접속이 불안정해질 수 있습니다. 이 경우 DNS를 계속 바꾸기보다 연결에 사용된 주소 계열을 비교해야 합니다.
- 주소 계열 비교: 실패한 연결이 IPv4와 IPv6 중 어느 쪽을 사용했는지 기록하세요. 필요하다면 구성 사본에서 IPv6 관련 옵션을 변경해 테스트합니다. 기존 값은 보관하고 테스트 결과에 따라 복원 여부를 결정하세요.
- 캐시 영향 배제: 설정을 변경한 뒤 연결을 다시 설정하고 웹페이지 요청도 새로 시작하세요. 브라우저, 시스템, 리졸버가 각각 캐시를 보유할 수 있으므로 한 번 새로고침한다고 새 DNS 조회가 이뤄지는 것은 아닙니다.
- 적용 중인 구성 확인: Config로 돌아가 방금 수정한 구성이 여전히 활성화되어 있는지 확인하세요. 사본을 수정했지만 활성화하지 않은 경우 “변경 사항이 적용되지 않았다”고 오해하기 쉽습니다.
- 두 가지 업데이트 구분: Home의 기존 Subscribe 업데이트는 주로 해당 서비스 정보를 새로 고칩니다. 원격 Config 업데이트는 구성 내용을 덮어쓸 수 있습니다. 구독 새로 고침이 DNS 매개변수 수정에 반드시 필요한 절차는 아닙니다.
- 변경 사항이 덮어써졌는지 확인: 원격 구성을 업데이트할 때마다 문제가 다시 발생한다면 업데이트 전후의 DNS, Host, Rule 내용을 비교해 로컬 변경 사항이 교체되었는지 확인하세요.
전체 구독 링크, 인증 정보, 처리하지 않은 로그를 다른 사람에게 보내지 마세요. 도움을 요청할 때는 오류 유형, 대상 도메인, 네트워크 종류, 정책 이름만 남기면 됩니다. 계정이나 토큰 관련 정보는 먼저 삭제하세요.
7. 근거를 바탕으로 마무리하기: DNS 변경을 멈춰도 되는 시점
점검을 마친 뒤에는 문제가 “조회 무응답”, “명확한 오류 응답”, “잘못된 주소 반환”, “올바른 주소지만 연결 실패” 중 어디에 해당하는지 설명할 수 있어야 합니다. 매번 예상한 주소가 반환되고 로그에서 연결 설정 또는 TLS 핸드셰이크 단계의 실패가 확인된다면 DNS 변경을 멈추고, 기존 서비스 연결 상태, 대상 웹사이트, 기기 시간, 정책 경로를 점검하세요.
- DNS 문제로 볼 근거가 충분함: 같은 도메인이 기존 업스트림에서는 실패하고 검증된 다른 조회 경로에서는 성공하며, 다른 조건을 그대로 유지했을 때 웹페이지 접속도 복구됩니다.
- 규칙 분기 문제일 가능성이 큼: DNS 결과는 같지만 Config에서만 실패하고, 실제 적용된 규칙을 조정한 뒤 복구됩니다.
- 네트워크 경로 문제일 가능성이 큼: 설정은 그대로인데 Wi-Fi에서는 실패하고 셀룰러 네트워크에서는 성공하거나, 특정 주소 계열로만 연결되지 않습니다.
- 대상 서버 문제일 가능성이 큼: 특정 웹사이트 하나만 문제가 있고 DNS 조회는 정상이지만, 같은 연결과 정책에서 다른 웹사이트는 접속됩니다.
사용 중인 서비스 제공자에게 문의할 때는 발생 시간, Wi-Fi 또는 셀룰러 네트워크 여부, 문제가 발생한 도메인, DNS 응답 상태와 반환된 주소 계열, Config와 임시 비교 상태의 차이를 제공하세요. “지연 시간은 정상인데 작동하지 않음”이라고만 하기보다 “도메인 조회에서 SERVFAIL 응답이 반환됨”이라고 설명하면 원인 파악에 도움이 됩니다. 점검 후에는 잠시 비활성화한 On Demand를 복원하고 최종적으로 작동하는 구성의 사본을 보관하세요.