Shadowrocket에서 연결 테스트 지연 시간은 표시되지만 Safari나 다른 앱에서 웹페이지가 열리지 않는 경우를 다룹니다. 먼저 DNS 오류, 연결 시간 초과, TLS 오류를 구분한 다음 Home → Global Routing과 Config의 dns-server를 확인하세요. 동일한 대상에서 한 번에 한 항목만 변경하고 네트워크를 바꿔 원인을 찾습니다. 이미 서비스 제공업체와 구독을 이용 중인 경우를 전제로 하며, 서비스 선택은 다루지 않습니다.
1. 지연 시간이 정상이어도 도메인 조회가 정상이라는 뜻은 아닙니다
웹페이지에 접속할 때는 보통 도메인 조회, 연결 설정, TLS 핸드셰이크, 콘텐츠 수신 과정을 거칩니다. Home의 테스트 결과는 선택한 테스트 방식에서 확인하는 단계만 반영합니다. TCP 연결에 성공했거나 테스트 주소에 도달할 수 있어도 대상 웹사이트의 도메인이 정상적으로 조회되거나 HTTPS 요청이 성공한다는 뜻은 아닙니다. 서로 다른 테스트 결과를 직접 비교하지 않도록 먼저 Connectivity Test의 테스트 방식을 기록하세요.
DNS는 도메인 이름을 IP 주소로 변환합니다. 프록시 서버에 연결할 수 있어도 기기에서 사용하는 리졸버에 접근할 수 없거나, 응답에 주소가 없거나, 조회 결과가 현재 연결 경로에 맞지 않으면 웹페이지가 열리지 않을 수 있습니다. 반대로 IP 주소를 이미 얻은 뒤 연결 시간 초과가 발생했다면 이를 단순히 DNS 문제로 볼 수는 없습니다.
판단 기준: 실패 단계부터 확인한 뒤 리졸버를 변경하세요
오류가 인증서 또는 TLS 핸드셰이크 문제로 명확하게 표시되면 기기 시간, 대상 도메인, 연결 경로를 먼저 확인하세요. 이름 조회 오류, DNS 시간 초과 또는 비정상적인 응답이 있을 때 DNS 경로를 우선 점검합니다. 포트에 연결할 수 있다는 사실만으로 DNS 서비스가 정상적으로 응답한다고 볼 수는 없습니다.
2. 먼저 Home의 테스트 조건을 고정하세요
점검하는 동안 대상 도메인과 기존 설정을 동일하게 유지하세요. 서버 변경, 규칙 수정, 구독 업데이트, DNS 변경을 한꺼번에 진행하면 문제가 해결된 뒤 어떤 변경이 효과가 있었는지 알 수 없습니다. 자주 방문하고 주소를 정확히 알고 있는 웹사이트를 우선 선택한 다음, 비교용으로 다른 도메인 하나를 추가하세요.
- 현재 상태를 기록하세요. Home에서 연결 스위치 상태, 현재 선택한 서버, Global Routing 모드, Connectivity Test의 테스트 방식과 결과를 적어 두세요. 인증 정보는 기록하지 마세요.
- 라우팅 모드를 확인하세요. Global Routing의 Config는 현재 설정의 규칙에 따라 트래픽을 처리합니다. Proxy는 일반 트래픽을 선택한 프록시로 전달하고, Direct는 직접 연결을 비교할 때 사용합니다. Scene은 설정된 시나리오에 따라 작동합니다. 이름만 보고 Scene의 실제 정책을 판단하지 말고 시나리오 내용을 확인하세요.
- 짧게 비교 테스트를 진행하세요. 현재 네트워크에서 접속할 수 있는 경우, 동일한 도메인을 Direct와 Proxy에서 비교합니다. 특정 모드에서만 실패하더라도 경로가 다르다는 점을 보여 줄 뿐, 그것만으로 DNS 문제라고 단정할 수는 없습니다. 테스트가 끝나면 기존 모드로 복원하세요.
- 자동 연결이 개입하지 않는지 확인하세요. Settings → On Demand를 확인합니다. 수동으로 비교 테스트를 하려면 관련 트리거 조건을 먼저 기록한 뒤 잠시 비활성화하세요. 수동으로 연결을 끊어도 On Demand가 다시 연결하는 상황을 방지할 수 있습니다. 테스트 후에는 원래 설정으로 복원하세요.
- 네트워크를 바꿔 다시 테스트하세요. Wi-Fi와 셀룰러 네트워크를 번갈아 사용하며 같은 설정으로 테스트합니다. 한 네트워크에서만 실패한다면 해당 네트워크의 DNS 접근성, 로그인 인증 또는 접속 제한을 중점적으로 확인하세요.
Wi-Fi에 웹 로그인 인증이 필요한 경우 먼저 인증을 완료한 뒤 테스트하세요. 모든 웹사이트가 실패하고 현재 서버의 도메인도 조회되지 않는다면 연결 진입점의 도메인 조회 문제부터 해결해야 합니다. 이때 웹사이트 규칙을 계속 바꾸는 것은 대개 도움이 되지 않습니다.
3. dns-server의 의미와 최소한의 변경 방법
Config는 설정 파일을 관리하는 곳이지 구독 서버 목록 자체를 관리하는 곳이 아닙니다. 변경 전에 현재 파일을 복사해 두고, 어떤 설정 파일을 사용 중인지 확인한 다음 해당 파일의 편집 화면으로 이동하세요. 아래는 필드 위치를 설명하기 위한 최소 예시입니다. 기존 파일에서 해당 필드만 바꾸고 전체 설정을 덮어쓰지 마세요.
[General]
dns-server = system| 필드 또는 값 | 실제 의미 | 점검 시 주의사항 |
|---|---|---|
[General] | 일반 설정 섹션 | 동일한 이름의 설정이 중복되어 혼란이 생기지 않도록 기존 섹션을 수정하세요. |
dns-server | 설정 파일에서 사용할 DNS 리졸버 지정 | 현재 버전에서 지원하는 값을 입력하세요. 프록시 서버 주소나 구독 주소가 아닙니다. |
system | 현재 시스템 네트워크에서 제공하는 DNS 사용 | 기준 비교에 적합하지만 Wi-Fi, 셀룰러 네트워크 또는 네트워크 프로파일에 따라 결과가 달라질 수 있습니다. |
| 리졸버 IP 주소 | 일반 DNS 서버를 직접 지정 | 주소가 올바른지, 해당 서비스에 접근할 수 있는지 확인하세요. 웹사이트 IP나 프록시 포트를 DNS 서비스 주소로 입력하면 안 됩니다. |
| DoH 주소 | HTTPS 요청으로 DNS 응답을 가져옵니다 | 현재 버전에서 지원하는 형식과 전체 엔드포인트를 사용하세요. 일반 웹사이트의 첫 화면 주소는 DoH 엔드포인트를 대신할 수 없습니다. |
먼저 dns-server = system으로 비교해 보세요. 기존 설정에서 리졸버를 지정했으며 system으로 바꾼 뒤 문제가 해결된다면 기존 리졸버의 접근성, 주소 형식, 연결 경로를 확인한 다음 변경을 유지할지 결정하세요. system에서도 문제가 계속되더라도 앱 자체의 문제라고 단정할 수는 없습니다. 시스템에서 제공한 DNS에 접근할 수 없거나 해당 리졸버에 대상 도메인의 유효한 응답이 없을 수 있습니다.
- 한 번에 필드 하나만 변경하고 저장한 다음, 해당 Config가 현재 사용 중인 파일인지 확인하세요.
- 설정을 적용하기 위해 다시 불러와야 한다면 연결을 끊었다가 다시 연결한 뒤 테스트하세요. 실패할 경우를 대비해 기존 값을 보관하세요.
- 이미 사용 중이며 신뢰할 수 있고 접근 가능한 리졸버로 비교하세요. 출처를 모르는 설정에서 낯선 엔드포인트를 복사하지 마세요.
- 암호화 DNS도 기본 네트워크에 접근할 수 있어야 합니다. 엔드포인트에 도메인을 사용한다면 최초 도메인 조회와 인증서 검증이 완료되는지도 고려해야 합니다.
4. 오류 메시지에 따라 점검 방향 구분하기
아래는 네트워크 진단에서 볼 수 있는 표준 오류 메시지 또는 시스템 오류 코드입니다. Shadowrocket의 모든 화면에 동일한 메시지가 표시된다는 뜻은 아닙니다. 기록할 때는 오류가 발생한 위치, 대상 도메인, 실패 단계를 함께 적으세요. 앱, Safari, 원격 서버 로그의 표현은 서로 다를 수 있으므로 단순히 “열리지 않는다”는 이유만으로 원인을 단정하지 마세요.
오류: NSURLErrorDomain Code=-1003
원인: Apple URL 로딩 시스템이 지정된 호스트를 찾지 못했습니다. 이름 조회 실패나 도메인 오타가 흔한 원인입니다.
해결 방법: 도메인 철자를 먼저 확인한 다음, 동일한 도메인으로 system과 기존 리졸버를 비교하고 특정 네트워크에서만 발생하는지 확인하세요.
오류: NXDOMAIN
원인: DNS 응답에서 조회한 이름이 존재하지 않는다고 표시합니다. 리졸버가 응답하지 않는 경우와는 다르며, 사용하는 리졸버의 정책과 관련이 있을 수도 있습니다.
해결 방법: 전체 호스트 이름을 확인하고 이미 사용 중인 신뢰할 수 있는 다른 리졸버로 다시 조회하세요. 결과가 같다면 도메인 관리자에게 레코드를 확인해 달라고 요청하세요.
오류: SERVFAIL
원인: 리졸버가 조회를 완료하지 못했습니다. 상위 DNS 서버 장애, 권한 DNS 서버 문제 또는 DNSSEC 검증 실패 등이 원인일 수 있습니다.
해결 방법: 네트워크와 리졸버를 바꿔 응답을 비교하고 발생 시간을 기록하세요. 도메인이 영구적으로 존재하지 않는다고 판단해 Host 값을 바로 바꾸지 마세요.
오류: NSURLErrorDomain Code=-1001
원인: 요청 시간이 초과되었습니다. 도메인 조회, 연결 또는 응답 대기 단계에서 발생할 수 있으며, 이 코드만으로 DNS 문제라고 단정할 수 없습니다.
해결 방법: 진단 기록을 통해 대상 IP를 이미 얻었는지 확인하세요. IP를 얻었다면 라우팅, 연결 상태, 대상 서비스의 응답을 계속 점검하세요.
AAAA 레코드가 없다는 이유만으로 도메인 전체를 조회할 수 없다고 판단하지 마세요. 사용 가능한 A 레코드가 있을 수 있습니다. 반대로 AAAA 응답을 받았다고 해서 현재 네트워크의 IPv6 경로가 정상이라는 뜻도 아닙니다. 일부 도메인만 실패한다면 모든 IPv6 설정을 한꺼번에 바꾸지 말고 DNS 응답과 실제 연결에 사용된 주소 체계를 각각 확인하세요.
5. 조회에 성공한 뒤 규칙과 재정의 항목 확인하기
DNS 조회에 성공했다는 것은 응답을 받았다는 의미일 뿐입니다. 웹사이트 요청이 올바른 정책으로 처리되어야 합니다. Global Routing이 Config인 경우 규칙은 보통 위에서부터 순서대로 적용되며, 먼저 일치한 규칙이 요청 처리 방식을 결정합니다. 규칙 순서, 정책 이름 또는 기본 처리를 잘못 변경하면 이미 응답을 받은 요청도 사용할 수 없는 경로로 전달될 수 있습니다.
| 확인 항목 | 기능 | 구체적인 점검 방법 |
|---|---|---|
DOMAIN-SUFFIX | 지정한 도메인과 하위 도메인에 일치 | 경로가 포함된 URL이 아니라 도메인을 입력했는지 확인하고, 앞에서 먼저 일치하는 규칙이 있는지 살펴보세요. |
IP-CIDR | IP 대역을 기준으로 일치 | 대상 IP가 앞에 있는 IP 대역 규칙에 먼저 적용되는지 확인하세요. no-resolve가 있으면 해당 수정자의 영향도 파악해야 합니다. |
GEOIP | IP 위치 데이터베이스 분류에 따라 일치 | 데이터베이스 분류가 웹사이트의 실제 소재 국가와 같다고 단정하지 마세요. 실제로 적용된 정책을 확인하세요. |
FINAL | 앞선 규칙에 일치하지 않은 요청 처리 | 요청이 마지막으로 DIRECT, 프록시 또는 정의된 정책 그룹 중 어디에 적용되는지 확인하세요. |
[Host] | 지정된 호스트에 설정 파일의 DNS 매핑 제공 | 오래된 주소가 남아 있는지 확인하세요. 먼저 백업한 뒤 의심되는 매핑 항목 하나를 제거해 비교하세요. |
예를 들어 DOMAIN-SUFFIX,example.com,DIRECT는 예시 도메인과 하위 도메인을 DIRECT로 전달합니다. 해당 요청이 기존에 사용 중인 프록시 경로를 통해서만 정상적으로 연결된다면 리졸버가 올바른 응답을 반환해도 페이지가 열리지 않을 수 있습니다. 여기서 example.com은 규칙 문법을 보여 주기 위한 예시일 뿐, 실제 테스트 대상이 아닙니다.
판단 기준: 대상 IP를 확인했다면 실제로 적용된 정책을 따라 점검하세요
진단 결과에서 조회 응답을 확인했다면 먼저 해당 도메인에 적용된 규칙, 최종 정책, 선택한 연결 경로를 확인하세요. 라우팅 오류를 해결하려고 DNS를 계속 바꾸지 말고, 일시적인 접속을 위해 계속 바뀌는 웹사이트 주소를 Host에 고정하지도 마세요.
6. 자주 묻는 질문과 복구 확인
DNS를 바꿨는데 왜 같은 오류가 계속 표시되나요?
먼저 Config에서 현재 사용 중인 파일에 변경 사항을 저장했는지 확인한 다음 연결을 끊었다가 다시 연결하세요. 오류가 난 페이지를 닫고 새 요청을 보내 캐시가 갱신될 시간을 주세요. 계속 실패한다면 브라우저에 남아 있는 이전 페이지가 아니라 새 요청의 오류를 기록하세요.
Wi-Fi에서는 열리지 않지만 셀룰러 네트워크에서는 열릴 때 어디를 바꿔야 하나요?
서버와 Config는 그대로 두고 두 네트워크에서 system DNS가 어떻게 작동하는지 먼저 비교하세요. Wi-Fi에 웹 로그인이 필요한지도 확인하세요. 해당 Wi-Fi에서만 실패한다면 클라이언트 설정을 바꾸기 전에 네트워크 측의 DNS와 전송 제한을 먼저 확인하세요.
웹페이지는 다시 열리지만 구독 업데이트는 계속 실패하면 어떻게 해야 하나요?
구독 업데이트는 웹페이지 접속 테스트와 다른 URL에 접근합니다. 기존 구독의 도메인, 유효 기간, 오류 응답을 확인하세요. 기록을 공유하기 전에는 token 등의 인증 정보를 삭제하세요. 구독 URL을 dns-server에 입력하거나, DNS 비교 대신 업데이트를 반복하지 마세요.
DNS 문제를 증명하기 위해 웹사이트 IP를 직접 입력해도 되나요?
결정적인 증거로 사용할 수 없습니다. HTTPS는 인증서 확인과 사이트 선택에 도메인을 사용하며, 하나의 IP에서 여러 웹사이트를 호스팅할 수도 있습니다. 원래 도메인을 그대로 두고 DNS 응답과 연결 단계의 기록을 확인하세요. IP 주소로 페이지가 열리는지만을 유일한 판단 기준으로 삼지 마세요.
복구된 뒤 홈페이지를 한 번 여는 것만으로 점검을 끝내지 마세요. 아래 확인 목록에 따라 결과가 반복되는지 확인한 다음 최종 변경을 유지하세요. 서비스 제공업체나 네트워크 관리자에게 문의해야 한다면 민감 정보를 가린 기록만 전달하고, 전체 설정 파일은 보내지 마세요.
- 기능 확인: 이전에 실패했던 도메인과 비교용 도메인을 다시 열어 페이지 캐시에 의존하지 않는지 확인하세요.
- 설정 확인: 평소 사용하는 Global Routing 모드와 On Demand 조건을 복원한 뒤 자동 연결 상태에서도 접속되는지 확인하세요.
- 네트워크 확인: 실제 사용하는 Wi-Fi와 셀룰러 네트워크에서 각각 다시 테스트하고 네트워크별 차이가 있는지 기록하세요.
- 기록 확인: 테스트 시간, 네트워크 유형, 오류 원문, DNS 조회 성공 여부, 적용된 정책, 변경한 항목 하나를 기록하세요. 구독 token, 비밀번호 및 기타 인증 정보는 삭제하세요.