Shadowrocket에서 지연 시간이 정상으로 표시되더라도 웹 요청의 모든 과정이 정상이라는 뜻은 아닙니다. DNS 조회 실패, 잘못된 규칙에 따른 아웃바운드 선택, 연결 핸드셰이크 실패를 구분한 뒤 현재 Config의 DNS 설정을 확인하세요. 한 번에 한 항목씩 변경하고 같은 도메인으로 다시 테스트합니다. 서비스와 구독을 이미 이용 중이며 연결은 되지만 웹페이지가 제대로 열리지 않는 경우, 설정을 반복해서 바꾸기보다 실패 지점을 찾는 데 초점을 둡니다.
1. 지연 시간이 정상인데 웹페이지가 열리지 않는 이유
지연 테스트 결과는 테스트 방식에 따라 다릅니다. 서버 연결만 확인할 수도 있고, 지정된 테스트 주소에 접속할 수도 있습니다. 테스트에 성공해도 모든 웹사이트의 도메인이 조회되거나 모든 규칙이 제대로 적용된다는 보장은 없으며, 대상 웹사이트의 TLS 핸드셰이크 성공 여부도 알 수 없습니다. 따라서 지연 시간이 표시된다는 사실은 일부 네트워크 경로가 동작한다는 증거일 뿐입니다.
이 흐름은 문제 해결을 위한 모델이지, 내부 처리 순서가 항상 고정되어 있다는 뜻은 아닙니다. 도메인 규칙은 조회 전에 적용될 수 있고, IP 규칙은 주소를 먼저 가져와야 할 수 있습니다. 프록시 아웃바운드에서는 대상 도메인 조회가 원격에서 이루어질 수도 있습니다. 서버 주소 자체가 도메인이라면 먼저 서버 주소를 조회해야 프록시 연결을 시도할 수 있습니다.
- 모든 도메인에서 실패: DNS 서버에 연결할 수 있는지, 현재 설정이 적용되었는지, 기본 네트워크에서 로그인이 필요한지 먼저 확인하세요.
- 일부 도메인에서만 실패: 해당 도메인의 조회 결과와 적용된 규칙을 확인하세요. 모든 네트워크 설정을 바로 초기화하지 마세요.
- 텍스트는 표시되지만 이미지가 로드되지 않음: 페이지 리소스가 다른 도메인에서 제공될 수 있으므로, 로드에 실패한 리소스의 요청을 각각 확인하세요.
- 주소를 받았는데도 시간 초과: 아웃바운드, IPv6 경로, 대상 서비스도 확인하세요. 곧바로 DNS 문제라고 단정하면 안 됩니다.
2. 먼저 네트워크, 모드, 설정을 하나씩 확인하기
현재 네트워크, Home에서 선택한 서버, Global Routing 값, Config에서 사용 중인 설정을 기록해 두세요. 그래야 테스트 후 원래 상태로 되돌릴 수 있습니다. 한 번의 테스트에서 구독을 업데이트하고 서버를 바꾸고 DNS까지 수정하면 어느 변경이 결과에 영향을 주었는지 알기 어렵습니다.
- 기본 네트워크 확인. Shadowrocket 연결을 잠시 끄고 현재 Wi-Fi 또는 셀룰러 네트워크에서 평소 직접 접속하는 웹사이트를 열어 보세요. 공용 Wi-Fi에서 인증 페이지가 나타나면 먼저 인증을 완료하세요. 기본 네트워크가 동작하지 않는다면 DNS를 바꿔도 대개 해결되지 않습니다.
- 다시 연결해 문제 재현. Home으로 돌아가 유효한 연결 설정을 사용하는지 확인한 다음, 같은 실패 도메인에 접속하세요. 실패한 시각을 기록해 두면 요청 기록이나 로그에서 해당 항목을 찾기 쉽습니다.
- Global Routing 확인. 규칙 기반 설정을 평소에 사용할 때는 Config를 선택하세요. 잠시 Proxy로 바꾸면 문제가 분기 규칙과 관련 있는지 확인하는 데 도움이 됩니다. Direct는 현재 네트워크에서 직접 연결되는지 비교할 때 사용합니다. 테스트 후에는 원래 모드로 되돌리세요.
- 실제 사용 중인 설정 확인. Config에 들어가 점검하려는 설정이 선택되어 있는지 확인하세요. 활성화되지 않은 다른 파일만 편집한 것은 아닌지 살펴봅니다. Scene을 사용 중이라면 해당 장면의 모드와 설정도 확인해 장면 변경으로 테스트 조건이 달라지지 않도록 하세요.
- 같은 대상을 다시 테스트. 홈페이지 열기, 실패한 페이지 새로고침, 다른 도메인 접속 결과를 각각 기록하세요. 도메인 하나가 정상화되었다고 해서 문제가 모두 해결된 것은 아닙니다.
3. DNS 설정 항목의 의미를 확인한 뒤 현재 Config 수정하기
Config에서 현재 사용하는 설정을 열고 편집 화면으로 이동해 DNS 관련 항목을 확인하세요. 텍스트 설정을 사용한다면 [General] 아래의 dns-server를 중점적으로 살펴봅니다. 항목은 실제 설정과 앱 인터페이스에 따라 다를 수 있습니다. 시스템 Wi-Fi DNS, 설정 파일의 DNS, 브라우저의 암호화 DNS는 서로 다른 설정 위치입니다.
| 항목 또는 개념 | 용도 | 점검할 사항 |
|---|---|---|
dns-server | 설정에서 사용할 DNS 서버의 출처입니다. 지원되는 형식은 앱의 최신 안내를 확인하세요. | 철자와 주소 형식, 연결 가능 여부를 확인하세요. 검증되지 않은 주소를 한꺼번에 많이 입력하지 마세요. |
system | 시스템에서 제공하는 DNS를 사용합니다. | 비교 테스트에 적합합니다. 다만 현재 네트워크의 DNS에 문제가 있다면 시스템 DNS를 사용해도 실패할 수 있습니다. |
| DNS over HTTPS | DNS 쿼리를 HTTPS로 전송하며, 일반적으로 TCP 443을 사용합니다. | 올바른 전체 서비스 엔드포인트가 필요합니다. 호스트 이름 조회, TLS, 네트워크 연결이 모두 정상이어야 합니다. |
| DNS over TLS | DNS 쿼리를 TLS로 전송하며, 표준 서비스는 일반적으로 TCP 853을 사용합니다. | 네트워크에서 해당 포트에 연결할 수 있는지, 인증서의 호스트 이름이 올바른지 확인하세요. |
| IPv6 및 AAAA | AAAA 레코드는 IPv6 주소를 제공합니다. 주소를 받는 것과 실제로 연결할 수 있는 것은 별개의 조건입니다. | AAAA 조회 결과가 있어도 IPv6 경로에 문제가 있으면 다른 주소를 시도하기 전까지 웹페이지가 시간 초과될 수 있습니다. |
| Fallback | 해당 조건을 충족할 때 대체 DNS 조회 출처를 사용합니다. | 먼저 적용 조건을 확인하세요. 모든 대체 출처가 동시에 조회되거나 가장 빠른 결과를 자동으로 반환한다고 가정하지 마세요. |
최소한의 비교 테스트를 하려면 먼저 기존 설정을 복사해 저장한 뒤 DNS 출처만 시스템 DNS로 바꿔 보세요. 아래는 텍스트 설정에서 관련 항목을 보여 주는 예시입니다. 전체 설정이 아니므로 기존 파일의 다른 내용을 덮어쓰지 마세요.
[General]
dns-server = system저장한 뒤 해당 설정이 계속 활성화되어 있는지 확인하고 연결을 끊었다가 다시 연결해 테스트하세요. 시스템 DNS는 동작하지만 기존 암호화 DNS가 동작하지 않는다면 원래 엔드포인트까지의 연결 경로를 확인해야 합니다. 암호화 DNS의 호스트 이름은 미리 조회해야 할 수도 있습니다. 연결할 수 없다면 웹페이지를 반복해서 새로고침해도 이 전제 조건을 우회할 수 없습니다.
4. 규칙 적용 확인하기: 조회가 성공해도 잘못된 경로로 연결될 수 있습니다
Home에서 Global Routing을 Config에서 Proxy로 잠시 바꾼 뒤 같은 웹페이지가 열린다면, 규칙 선택이나 직접 연결 경로, 아웃바운드별 조회 방식이 원인일 수 있습니다. 그렇다고 원래 DNS에 문제가 있었다고 단정할 수는 없습니다. Config로 돌아가 요청에 실제로 적용된 규칙을 따라가며 확인하세요.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY위 내용은 문법 설명을 위한 예시입니다. example.com과 192.0.2.0/24는 문서용 값이며, 실제 서비스 주소나 그대로 따라야 할 분기 규칙을 뜻하지 않습니다. 실제 규칙은 설정 순서대로 위에서 아래로 적용되고, 처음 일치하는 규칙에서 처리가 끝납니다. 나머지 요청은 마지막에 FINAL로 처리합니다.
DOMAIN-SUFFIX: 도메인 접미사를 기준으로 일치시킵니다. 대상 도메인이나 리소스 도메인이 부적절한 아웃바운드로 먼저 지정되지는 않았는지 확인하세요.IP-CIDR: 대상 IP 대역을 기준으로 일치시킵니다. 예시의no-resolve는 이 규칙에 일치시키기 위해 도메인을 능동적으로 조회하지 않도록 합니다. 앱이 대상에 접속할 때 DNS가 항상 필요 없다는 뜻은 아닙니다.GEOIP: 주소의 지역 데이터베이스 정보를 기준으로 일치시킵니다. 도메인 요청에서 먼저 조회가 필요한지는 일치 과정과 관련 설정에 따라 달라지므로 규칙 이름만으로 판단할 수 없습니다.FINAL: 앞선 규칙에 일치하지 않은 요청을 처리합니다. 마지막 아웃바운드를 사용할 수 없다면 DNS에서 주소를 받았더라도 접속에 실패할 수 있습니다.
정리: 실패한 요청에 적용된 규칙을 찾은 뒤 DNS 또는 아웃바운드를 수정하세요
Proxy에서는 동작하지만 Config에서는 동작하지 않는다면 Config로 돌아가 해당 도메인의 요청 기록을 확인하세요. DNS 조회 시간 초과나 잘못된 응답이라는 근거가 있을 때만 DNS를 수정합니다. 기록에 대상 주소가 표시되고 연결 단계로 넘어갔다면 적용된 규칙과 아웃바운드를 먼저 확인하세요.
5. 로그에서 조회 실패, 시간 초과, TLS 오류 구분하기
앱의 요청 기록이나 로그에서 방금 실패한 도메인과 접속 시각을 기준으로 항목을 찾으세요. 오류 문구는 네트워크 계층에 따라 다를 수 있습니다. 아래는 로그에 표시될 수 있는 문구의 예이며, 모든 화면에서 똑같이 표시된다는 뜻은 아닙니다. 오류가 어떤 주소와 단계에서 발생했는지 함께 확인하세요.
오류: no such host
원인: 조회 단계에서 사용할 수 있는 호스트 주소를 얻지 못했습니다. 도메인 오타, 존재하지 않는 레코드, 상위 DNS 서버의 부정 응답 등이 원인일 수 있습니다.
해결: 먼저 도메인 철자를 확인한 뒤 같은 네트워크에서 다른 DNS 조회 출처와 비교하세요. 서비스 제공업체가 제공한 서버 도메인만 실패한다면 해당 주소가 유효한지 제공업체에 문의하세요.
오류: i/o timeout
원인: 네트워크 작업이 제한 시간 안에 끝나지 않았다는 뜻입니다. DNS 조회 중일 수도, 아웃바운드 연결 중일 수도 있으므로 이 문구만으로는 원인을 분류할 수 없습니다.
해결: 앞뒤 로그를 확인해 DNS 서버, 웹사이트 또는 프록시 서버 중 어디에서 문제가 발생했는지 살펴보세요. DNS 조회 단계에서 시간 초과가 발생한 경우에만 다른 조회 출처를 테스트하세요.
오류: connection refused
원인: 연결 대상이 요청을 명시적으로 거부했습니다. 일반적으로 조회를 더 기다리기보다 대상 서비스와 포트를 확인해야 합니다.
해결: 실제 연결 주소와 포트를 확인하세요. 거부된 대상이 암호화 DNS 엔드포인트라면 해당 서비스가 지정된 포트에서 연결을 받는지 확인하세요.
오류: certificate verify failed
원인: TLS 인증서 확인에 실패했습니다. 기기의 날짜 및 시간, 엔드포인트 호스트 이름, 인증서 체인과 관련된 문제일 수 있습니다.
해결: 시스템 날짜와 시간, 엔드포인트 주소를 확인하고 해당 서비스 제공업체에 설정을 문의하세요. 인증서 확인을 꺼서 문제를 숨기지 마세요.
로그에 조회된 IP가 표시된 뒤 연결 오류나 TLS 오류가 발생한다면 해당 단계로 점검 초점을 옮기세요. HTTPS를 확인하려고 브라우저 주소창에 웹사이트 IP를 직접 입력하지도 마세요. 그러면 인증서 이름, SNI, 가상 호스트 선택이 달라질 수 있어 도메인으로 접속하는 것과 같은 테스트가 아닙니다.
6. 수정 후 테스트 순서와 자주 묻는 질문
설정을 수정할 때마다 저장하고 현재 Config인지 확인한 뒤, 다시 연결해 같은 도메인에 접속하세요. 브라우저 캐시와 기존 연결 때문에 이전 결과가 잠시 유지될 수 있으므로 해당 페이지를 닫았다가 다시 여세요. 먼저 영향이 적은 조치를 시도하고, 시스템 설정을 크게 변경하는 일은 나중에 고려하세요.
- 기존 네트워크에서 실패한 도메인과 평소 정상인 도메인 하나를 테스트해 각각 조회 결과를 받는지 기록하세요.
- 서버, Global Routing, Config는 그대로 두고 Wi-Fi와 셀룰러 네트워크를 바꿔 가며 비교하세요. 셀룰러 데이터 사용 시 요금이 발생할 수 있습니다.
- 한 네트워크에서만 실패한다면 해당 네트워크의 DNS 연결 상태, 인증 여부, 포트 제한을 중점적으로 확인하세요.
- 원래 사용하던 Config 모드와 On Demand 조건으로 되돌린 뒤, 평소 사용하는 규칙과 페이지 리소스, 다른 앱의 접속이 정상인지 확인하세요.
지연 시간이 표시되면 서비스 제공업체 연결 문제를 배제할 수 있나요?
아니요. Home으로 돌아가 같은 서버를 유지한 상태에서 실패한 도메인에 접속한 뒤, 요청 기록에서 연결 단계 오류가 있는지 확인하세요. 테스트 주소에 접속할 수 있다는 것과 대상 웹사이트에 접속할 수 있다는 것은 별개의 결과입니다. 구독이나 서버 정보 확인이 필요하면 서비스 제공업체에 문의하세요.
DNS를 암호화 DNS로 바꾸면 반드시 해결되나요?
반드시 그렇지는 않습니다. Config에서 기존 설정을 저장한 뒤 DNS 출처만 따로 바꿔 비교하세요. DNS over HTTPS와 DNS over TLS도 연결 가능한 엔드포인트와 정상적인 TLS가 필요합니다. 실제 문제가 규칙에 따른 아웃바운드 연결에서 발생했다면 DNS 리졸버를 바꿔도 근본 원인은 해결되지 않습니다.
Wi-Fi에서만 열리지 않고 셀룰러 네트워크에서는 정상이라면 어디를 바꿔야 하나요?
먼저 Shadowrocket 설정을 그대로 둔 채 Wi-Fi에서 인증이 필요한지, 시스템 Wi-Fi 세부 정보에서 DNS가 수동으로 설정되어 있는지 확인하세요. 암호화 DNS를 사용한다면 해당 네트워크에서 관련 포트에 접속할 수 있는지도 확인하고, 여러 설정을 동시에 바꾸지 마세요.
구독을 업데이트한 뒤에도 열리지 않으면 계속 새로고침해야 하나요?
아니요. 구독 업데이트는 연결 항목을 가져오는 기능이지 현재 Config의 DNS나 규칙을 고치는 기능이 아닙니다. 먼저 Home에서 실제로 선택된 항목을 확인한 뒤 Config로 돌아가 설정을 점검하세요. 구독 업데이트 자체가 실패한다면 구독 매뉴얼의 업데이트 안내를 확인하세요.
IPv6를 끈 뒤 정상화됐다면 앞으로 계속 꺼 두어야 하나요?
주소 계열이나 해당 경로를 추가로 확인할 필요가 있다는 뜻일 뿐입니다. 기존 설정을 기록하고 A 및 AAAA 조회 결과와 연결 로그를 비교하세요. 네트워크의 IPv6 경로가 정상인지 확인한 뒤 설정을 유지할지 결정하고, 한 번의 비교 결과를 모든 네트워크에 적용하지 마세요.
추가 확인이 필요하다면 서비스 제공업체에 실패한 도메인, 발생 시각, 현재 네트워크, Global Routing, 오류 발생 단계를 알려 주세요. 로그를 공유하기 전에 구독 주소, token, 비밀번호와 기타 인증 정보를 삭제하세요. 기본 조작법은 사용 안내의 문제 해결을, 구독 업데이트 방법은 Subscribe 업데이트 안내를 확인하세요.