Shadowrocket 지연은 정상인데 웹페이지가 열리지 않을 때: DNS 조회 실패 해결 순서

1. 지연 시간이 정상이어도 웹페이지 연결은 실패할 수 있습니다

먼저 지연 시간이 어떤 테스트에서 나온 값인지 확인하세요. 서버 포트에 연결하는 테스트와 웹페이지 주소에 요청을 보내는 테스트는 확인하는 연결 경로가 다릅니다. 서버 주소가 IP라면 서버 도메인 조회 없이 테스트할 수도 있습니다. 반면 브라우저로 웹사이트에 접속하려면 대상 도메인의 주소를 확인한 뒤 연결해야 합니다. 따라서 Home에 지연 시간이 표시된다는 사실만으로 DNS 문제를 배제할 수는 없습니다.

웹페이지가 계속 로딩되는 현상이 DNS 오류만을 의미하는 것은 아닙니다. DNS 조회는 성공했지만 이후 연결이 차단되거나, 대상 서버가 응답하지 않거나, TLS 핸드셰이크에 실패해도 페이지가 열리지 않을 수 있습니다. 점검할 때는 먼저 오류 문구와 발생 단계를 기록한 뒤 DNS 설정을 조정할지 판단하세요. 모든 접속 문제를 같은 설정 탓으로 돌리지 않는 것이 중요합니다.

포트 번호는 전송 방식의 차이를 이해하기 위한 참고 정보입니다. 현재 네트워크에서 해당 연결이 허용된다는 뜻도, 서버 포트를 이 번호로 변경해야 한다는 뜻도 아닙니다. 프록시 서버 포트와 DNS 서비스 포트는 서로 다른 매개변수이며, 프록시 서버 포트는 사용자가 보유한 서버 설정과 일치해야 합니다.

2. 재현 가능한 점검 기준부터 마련하세요

처음부터 서버, DNS, 규칙을 한꺼번에 바꾸지 마세요. 문제가 발생하는 웹 주소 하나를 정하고 현재 네트워크, 선택한 서버, Global Routing, 활성화된 설정을 기록합니다. 비교할 때는 전체 도메인 이름을 사용하세요. DNS를 확인한다며 HTTPS 주소의 도메인을 IP로 바꾸면 인증서 검증, SNI, 웹사이트의 가상 호스트 선택이 달라져 결과를 직접 비교할 수 없습니다.

1. 현재 상태 기록

   Home에서 선택한 서버와 연결 상태를 기록합니다. Home → Global Routing을 열어 현재 선택 항목을 적어 두고, Config에서 사용 중인 설정을 확인하세요. 변경하기 전에 복원할 수 있도록 사본을 보관합니다.

2. 기본 네트워크 확인

   일시적으로 연결을 끊고 현재 네트워크에서 원래 접속할 수 있는 웹사이트를 열어 보세요. 공용 Wi-Fi에서 웹 인증이 필요한 경우 먼저 인증을 완료합니다. 연결을 끊은 뒤에도 해당 사이트가 열리지 않으면 Wi-Fi나 셀룰러 네트워크 자체를 우선 확인하세요.

3. 테스트 조건 고정

   다시 연결한 뒤 Home → Global Routing에서 Proxy를 임시로 선택하고, 같은 서버를 유지한 채 대상 도메인에 다시 접속해 보세요. 이 단계는 Config와 비교하기 위한 것이며 최종 설정을 권장하는 것은 아닙니다.

4. 네트워크를 바꿔 재테스트

   서버와 설정은 그대로 둔 채 Wi-Fi와 셀룰러 네트워크에서 한 번씩 비교 테스트합니다. 한쪽 네트워크에서만 실패한다면 해당 네트워크의 DNS 요청과 연결 오류를 기록하고, 설정을 바로 덮어쓰지 마세요.

5. 기존 설정 복원

   비교 테스트가 끝나면 원래 Global Routing 설정으로 되돌립니다. 연결을 끊은 뒤 자동으로 다시 연결된다면 Settings → On Demand에서 활성화된 조건을 확인하세요. 연결 해제 테스트를 다시 할 때는 관련 조건을 일시적으로 비활성화합니다.

3. 실제 적용 중인 DNS 설정 확인

Config로 이동해 현재 활성화된 설정을 확인한 다음, 해당 설정의 DNS 항목을 살펴보세요. 비활성 파일을 수정해도 현재 연결에는 반영되지 않습니다. 원격 설정을 업데이트하면 로컬 변경 사항이 덮어써질 수도 있으므로 먼저 사본을 저장하세요. 변경 후 다시 연결해 같은 도메인으로 재테스트합니다. Home에서 서버 구독만 업데이트했다고 해서 Config의 DNS 설정까지 동기화됐다고 볼 수는 없습니다.

아래는 설정 문법을 보여 주는 예시일 뿐, 모든 상황에 적용되는 해결책은 아닙니다. 시스템 DNS를 조회 경로로 사용하는 설정으로, 변수를 하나씩 확인하기 위한 비교 항목으로 활용할 수 있습니다. 현재 네트워크의 시스템 DNS에 문제가 있다면 이 설정도 실패할 수 있습니다. 기존 설정에서 해당 필드만 조정하고, 테스트를 위해 나머지 규칙이나 정책, 서버 매개변수를 삭제하지 마세요.

[General]
dns-server = system

DoH를 사용할 때는 ‘서비스 주소를 먼저 조회해야 하는’ 의존성도 확인하세요. DoH 엔드포인트가 도메인을 사용한다면 HTTPS 연결 전에 엔드포인트 주소를 먼저 확인해야 합니다. 엔드포인트에 연결할 수 없거나 인증서 검증에 실패하거나 엔드포인트 도메인을 조회할 수 없으면 대상 웹사이트의 DNS 조회가 멈출 수 있습니다. 암호화 전송은 조회 요청의 전달 방식을 바꾸는 것이지 엔드포인트 접속을 보장하거나 현재 네트워크 점검을 대신하지 않습니다.

4. 규칙 적용 결과와 DNS 조회 결과를 따로 확인하세요

Global Routing의 Direct, Proxy, Config, Scene은 서로 다른 네 가지 DNS 프로토콜이 아닙니다. Direct와 Proxy는 트래픽을 처리하는 서로 다른 방식이고, Config는 사용 중인 설정에 따라 처리됩니다. Scene은 선택한 장면의 세부 설정을 확인해야 합니다. 점검 중에는 Scene 변경과 DNS 수정을 동시에 하지 마세요. 같은 웹 주소라도 서로 다른 경로로 연결될 수 있습니다.

Config에서는 규칙 순서도 확인해야 합니다. 도메인 규칙과 IP 규칙은 서로 다른 대상을 판별하며, IP 기반 규칙을 적용할 때 대상 도메인을 조회해야 할 수 있습니다. 로그에 이미 주소가 기록됐는데 요청이 적절하지 않은 정책으로 처리된다면 DNS를 계속 바꿔도 문제가 해결되지 않을 수 있습니다. 아래의 예약 도메인과 문서용 주소는 문법 설명을 위한 예시이며, 실제로 연결할 수 있는 서비스가 아닙니다.

[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

• DOMAIN-SUFFIX는 도메인 접미사를 확인합니다. 앞의 포괄적인 규칙이 먼저 적용되면 뒤에 있는 규칙은 이번 요청의 선택 대상이 되지 않습니다.
• IP-CIDR은 주소 대역을 확인합니다. 예시의 no-resolve는 해당 규칙을 위해 도메인 조회를 직접 시작하지 않는다는 뜻이며, 앱 전체의 DNS를 끄는 설정이 아닙니다.
• GEOIP는 IP 지리 정보에 따라 일치 여부를 판단합니다. 도메인의 언어나 웹사이트 이름만으로 규칙이 적용됐는지 추측할 수 없습니다.
• FINAL은 앞선 규칙에 일치하지 않을 때 적용되는 최종 정책입니다. 설정 파일에 이 키워드가 있는지만 확인하지 말고 실제로 어디를 가리키는지 살펴보세요.

A 레코드와 AAAA 레코드도 구분해야 합니다. A 레코드는 IPv4 주소를, AAAA 레코드는 IPv6 주소를 반환합니다. 조회는 성공했지만 특정 주소 체계에서만 연결이 실패한다면 주소 도달 가능성에 관한 단서일 수 있습니다. DNS 응답과 이후 연결 결과를 보관해 두고 확인하세요. AAAA 레코드가 있다는 사실만으로 문제라고 판단하거나 IPv6, DNS, 규칙을 동시에 변경하지 마세요.

5. 실제 오류 문구에 따라 다음 단계를 정하세요

아래는 Apple 네트워크 오류 도메인에서 사용하는 오류 식별자입니다. 오류 세부 정보나 진단 정보에 같은 문구가 있을 때 판단에 참고할 수 있으며, Shadowrocket에 매번 이 문구가 표시된다는 뜻은 아닙니다. 브라우저에는 한국어 안내만 표시될 수도 있습니다. 실제로 확인한 전체 내용을 기록하고, ‘열리지 않음’이라는 현상만으로 원인을 단정하지 마세요.

특정 웹사이트 하나만 실패하고 다른 도메인에는 안정적으로 접속된다면 해당 도메인과 관련 리소스 도메인을 따로 기록하세요. 웹페이지의 본문, 이미지, 스크립트는 서로 다른 도메인에서 제공될 수 있습니다. 페이지는 표시되는데 이미지가 계속 로딩되는 현상은 기본 도메인의 조회가 아직 성공하지 않았다는 뜻이 아닙니다. DNS 전체를 바꾸기보다 실패한 리소스의 도메인에 적용되는 규칙을 확인하는 편이 원인을 찾기 쉽습니다.

• 네트워크 유형, Global Routing, 활성 설정, 오류가 발생한 대상 도메인을 기록합니다.
• ‘조회 결과를 받지 못함’과 ‘IP는 받았지만 연결 시간 초과’를 구분하고 해당 오류 문구를 보관합니다.
• 진단 정보를 제출하기 전에 구독 token, 비밀번호, UUID, 개인 네트워크 주소를 가리세요. 문제 파악에 필요한 내용만 공유합니다.

6. 자주 묻는 질문과 해결 여부 확인

문제가 해결됐는지 확인할 때는 임시 Proxy 테스트 상태가 아니라 원래 사용하던 연결 방식으로 돌아가야 합니다. 필요한 Global Routing과 On Demand 조건을 복원한 뒤 다시 연결하고, 처음 실패했던 웹사이트와 비교용 웹사이트를 열어 보세요. 페이지 본문과 필요한 리소스가 모두 로딩되는지, 네트워크를 임시로 바꿔야만 복구되는 것은 아닌지 확인합니다.

1. 최종적으로 사용한 DNS 경로와 설정 사본을 보관하고, 근거가 확인되지 않은 임시 변경은 되돌립니다.
2. 평소 사용하는 네트워크에서 다시 테스트하세요. Wi-Fi와 셀룰러 네트워크를 모두 확인했다면 결과를 각각 기록합니다.
3. 문제가 계속 재현된다면 민감 정보를 가린 오류 문구, 대상 도메인, 규칙 적용 정보를 준비해 추가로 점검하세요. 같은 구독 설정을 반복해서 가져오지는 마세요.