Shadowrocket DNS 오류 해결: 지연 시간은 정상인데 웹페이지가 열리지 않을 때

1. 지연 시간이 정상이어도 DNS가 정상이라고 볼 수 없는 이유

Shadowrocket의 Connectivity Test는 선택한 테스트 방식에 해당하는 연결 상태를 확인합니다. 결과에 표시된 시간은 해당 테스트에서 사용한 대상과 경로만 반영합니다. 테스트에 성공했더라도 모든 웹사이트의 도메인이 조회된다거나 모든 아웃바운드 연결이 가능하다거나 HTTPS 핸드셰이크가 성공한다고 단정할 수 없습니다. 결과를 해석하기 전에 테스트 방식과 대상을 확인하세요. 지연 시간 숫자만으로 판단해서는 안 됩니다.

웹페이지를 열려면 도메인에 해당하는 주소를 조회하고, 접속 정책을 선택하고, 연결을 설정한 다음 TLS 핸드셰이크를 완료해야 합니다. 아래는 문제를 찾기 위한 논리적 구분이며, 클라이언트 내부의 각 단계가 항상 엄격한 순서로 처리된다는 뜻은 아닙니다. 예를 들어 도메인 규칙은 IP를 얻기 전에 매칭될 수 있지만, IP 규칙은 조회 결과가 필요할 수 있습니다.

DNS 문제인지 확인하려면 조회 실패의 증거를 찾아야 합니다. 브라우저에 서버를 찾을 수 없다는 메시지가 표시되거나 시스템 조회 도구가 주소를 가져오지 못하는 경우는 단순히 웹페이지가 로딩 중인 것보다 원인을 더 잘 가리킵니다. 주소를 이미 얻었는데 연결 또는 인증서 확인 단계에서 실패한다면 아웃바운드 연결, 규칙, 시스템 시간 또는 웹사이트 자체를 확인하세요.

• 모든 도메인 접속 실패: 먼저 리졸버에 연결할 수 있는지, 현재 네트워크에서 웹 로그인이 필요한지, VPN 연결이 실제로 유지되는지 확인하세요.
• 일부 도메인만 접속 실패: 도메인 철자, 해당 도메인 전용 DNS, 규칙 매칭 및 대상 사이트 상태를 먼저 확인하세요.
• 페이지 글자는 보이지만 이미지가 로드되지 않음: 실패한 리소스의 도메인을 기록하세요. 메인 사이트와 이미지, API가 서로 다른 도메인과 규칙을 사용할 수 있습니다.
• IP 주소로 직접 접속해도 실패: DNS 문제를 바로 배제할 수도, 연결 경로 문제라고 단정할 수도 없습니다. HTTPS 사이트는 일반적으로 올바른 도메인, SNI 및 인증서가 필요하므로 IP 주소만으로 접속하는 방법은 신뢰할 만한 비교 기준이 아닙니다.

2. 현재 상태를 기록한 뒤 세 가지 조건을 비교하세요

변경을 시작하기 전에 Home → Global Routing의 현재 선택 항목, 사용 중인 서버, Config에서 활성화된 설정, Settings → DNS의 현재 값을 기록하세요. 문제 해결용 사본을 만들어 두고, 유일한 설정 파일을 연속해서 수정하지 마세요. 구독 내용은 업데이트 시 다시 덮어써질 수 있으므로 직접 설정한 값과 서비스 제공업체 설정의 값을 구분해야 합니다.

1. 같은 네트워크에서 비교: 현재 Wi-Fi에서 원래 직접 접속되던 웹사이트와 문제가 발생한 웹사이트를 각각 테스트하세요. “열리지 않음”이라고만 적지 말고 전체 오류 메시지를 기록하세요. 비교를 위해 연결을 끊어야 한다면 직접 접속이 허용된 사이트만 테스트하고, Settings → On Demand 조건에 따라 자동 재연결되는지 확인하세요.
2. 네트워크를 바꿔 비교: 서버, Config, DNS는 그대로 둔 채 Wi-Fi를 모바일 네트워크로 바꾸거나, 사용 가능하다고 확인된 다른 네트워크에 연결하세요. 특정 Wi-Fi에서만 실패한다면 해당 네트워크의 인증 페이지, DNS 제한 또는 라우터 설정을 우선 점검하세요.
3. 라우팅 모드를 바꿔 비교: 원래 선택 항목을 기록한 다음 Home → Global Routing에서 Config와 Proxy를 임시로 비교하세요. Proxy는 일반 웹 트래픽이 프록시를 통해 아웃바운드될 때의 동작을 비교하는 용도이며, 모든 DNS 요청이 자동으로 프록시를 거친다는 뜻은 아닙니다. 테스트가 끝나면 원래 선택 항목으로 되돌리세요.

3. Settings → DNS: 주소, 기본값 및 권장 설정

Settings → DNS로 이동해 현재 시스템 DNS를 사용하는지 사용자 지정 리졸버를 사용하는지 확인하세요. 모든 기기에 적용되는 단일 기본 주소를 정해 둘 수는 없습니다. 플랫폼, 기존 설정, 가져온 Config에 따라 실제 적용값이 달라질 수 있습니다. 기기에 표시된 현재 값과 활성화된 Config를 기준으로 확인하세요. 사용자 지정 값을 사용 중이라면 먼저 원래 값을 저장한 뒤 한 항목씩 비교하세요.

리졸버 주소는 어디에 조회할지를 정하고, 전송 방식은 조회 요청을 어떻게 보낼지를 정하며, 도메인 전용 설정은 특정 도메인에 다른 조회 경로를 사용할지를 정합니다. 이 세 항목을 나누어 확인하세요. 리졸버를 바꿔도 잘못된 PROXY 정책이 자동으로 수정되거나 연결할 수 없는 프록시 서버가 복구되지는 않습니다.

DNS 주소를 여러 개 추가한다고 문제가 자동으로 해결되는 것은 아닙니다. 구현 방식에 따라 조회 및 대체 동작이 다를 수 있으므로 목록의 두 번째 주소가 첫 번째 주소의 시간 초과 후 반드시 사용된다고 가정하지 마세요. 먼저 리졸버 하나로 연결 가능 여부를 확인한 다음 실제 필요에 따라 설정을 복원하세요.

암호화 DNS 서버가 도메인 이름을 사용하고, 그 도메인을 조회하려면 아직 연결되지 않은 해당 서비스가 필요한 경우 시작 단계에서 의존성 문제가 발생할 수 있습니다. 이때는 인증서 검증을 끄지 말고 설정 제공자가 안내한 부팅 시 조회 및 라우팅 설정을 확인하세요. 암호화 DNS 주소를 임의로 IP 주소로 바꾸지 마세요. 인증서 이름과의 일치가 깨질 수 있습니다.

4. Config의 DNS 재정의 및 규칙 순서 확인

Settings → DNS만 변경해도 증상이 그대로라면 Config로 돌아가 활성화된 설정의 [General], [Host], [Rule]을 확인하세요. DNS 관련 옵션, 도메인 매핑, 규칙이 함께 실제 접속 경로를 바꿀 수 있습니다. 설정 화면에 표시된 주소가 해당 도메인에 최종적으로 사용되는 리졸버라고 단정하지 마세요. 설정과 확인 가능한 요청 기록을 함께 살펴봐야 합니다.

규칙은 위에서 아래 순서로 매칭되며, 매칭되면 해당 정책을 사용합니다. 아래는 순서를 보여 주는 예시일 뿐, 기존 설정 파일을 그대로 대체할 수 있는 완성본이 아닙니다. PROXY는 현재 Config에서 사용할 수 있는 정책 또는 정책 그룹이어야 하며, 예시 도메인은 실제로 점검할 대상으로 바꿔야 합니다.

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

• DOMAIN-SUFFIX,example.com,PROXY: 해당 도메인과 하위 도메인을 매칭합니다. 앞쪽에 관련 규칙이 이미 있다면 뒤에 추가한 규칙은 적용되지 않을 수 있습니다.
• IP-CIDR,192.168.0.0/16,DIRECT,no-resolve: 이 사설 주소 대역에 DIRECT를 지정합니다. no-resolve는 이 IP 규칙을 매칭하기 위해 도메인 조회를 시작하지 않는다는 뜻이지, 클라이언트 전체의 DNS를 끈다는 뜻이 아닙니다.
• GEOIP,CN,DIRECT: IP 지리 데이터베이스를 기준으로 판단합니다. 결과는 IP 주소와 데이터베이스에 따라 달라지므로 실제로 조회된 IP를 기준으로 매칭된 규칙을 확인해야 합니다.
• FINAL,PROXY: 앞선 규칙이 모두 매칭되지 않을 때 사용하는 기본 정책입니다. DNS 설정을 대체하거나 잘못된 도메인 매핑을 고치지는 못합니다.

도메인이 REJECT에 매칭된다면 의도적으로 활성화한 필터 규칙인지 확인하세요. DIRECT에 매칭되어 접속할 수 없지만 프록시를 통한 아웃바운드 연결은 가능하다면 모든 DNS를 바꾸지 말고 해당 도메인의 정책을 조정하세요. 회사 내부 도메인은 대개 내부 DNS와 DIRECT를 함께 사용해야 하며, 공용 리졸버가 내부 도메인 서비스를 대체할 수는 없습니다.

5. 오류 메시지로 조회, 연결, 인증서 문제 구분

아래는 브라우저나 명령줄 도구에 표시될 수 있는 원문 오류입니다. Shadowrocket의 모든 플랫폼에서 동일한 메시지가 표시된다는 뜻은 아닙니다. 오류가 발생한 앱, 대상 도메인, 발생 시간을 기록한 다음 클라이언트 요청 기록과 비교하세요. 브라우저의 모든 오류를 DNS 문제로 분류하지 마세요.

Mac, Windows, Linux에서는 기본 제공되는 nslookup을 보조 비교에 사용할 수 있습니다. 아래의 example.com은 예시 도메인이므로 실제로 접속이 실패하는 도메인으로 바꾸세요. 첫 번째 명령은 도구에서 사용하는 기본 리졸버를 조회하고, 두 번째 명령은 공용 리졸버를 지정합니다:

nslookup example.com
nslookup example.com 1.1.1.1

응답에서 조회 서버, 주소 반환 여부, 시간 초과 또는 NXDOMAIN 발생 여부를 확인하세요. 이 도구는 브라우저의 암호화 DNS나 Shadowrocket의 모든 도메인 정책을 재현하지 못할 수 있습니다. 따라서 비교 자료로 사용해야 하며 클라이언트 내부 조회 결과를 대신할 수는 없습니다. 브라우저에서 보안 DNS를 별도로 활성화했다면 해당 상태도 기록하고, 통제된 조건에서 시스템 DNS를 사용할 때의 결과와 비교하세요.

6. 변경 후 재테스트 및 원상 복구 순서

DNS 응답은 클라이언트, 시스템, 브라우저에서 각각 캐시될 수 있습니다. 설정을 바꾼 뒤에도 기존 연결이나 이전 응답이 결과에 영향을 줄 수 있으므로 웹페이지를 한 번 새로고침한 것만으로 변경이 효과 없다고 판단하지 마세요. 캐시를 비우기 위해 구독을 반복 업데이트하는 것도 피하세요. 구독 업데이트는 서버와 설정까지 바꿀 수 있어 비교 결과를 해석하기 어려워집니다.

1. 한 항목만 변경하고 저장: 활성화된 Config가 바뀌지 않았는지 확인하고, 변경 전후의 DNS 또는 규칙 값을 기록하세요.
2. 연결 다시 설정: 잠시 끊어도 괜찮은 경우 Home의 연결 스위치를 껐다가 다시 켜세요. Settings → On Demand에서 자동으로 다시 연결하는지 확인하세요.
3. 요청 다시 보내기: 문제가 발생한 페이지를 닫고 다시 여세요. 필요하면 브라우저를 종료한 뒤 다시 실행하세요. 시크릿 창은 일부 사이트 데이터의 영향을 배제하는 데 도움이 되지만 시스템 DNS 캐시까지 지운다고 보장할 수는 없습니다.
4. 같은 대상으로 재테스트: 같은 도메인, 네트워크, Global Routing 옵션을 사용해 오류 유형이 바뀌었는지 비교한 다음, 원래 정상적으로 열리던 사이트도 여전히 접속되는지 확인하세요.
5. 변경 유지 또는 되돌리기: 결과가 반복해서 재현되는 경우에만 변경 사항을 유지하세요. 개선되지 않으면 원래 값으로 복구한 뒤 다음 항목을 확인하세요. 검증하지 않은 변경을 여러 개 겹쳐 적용하지 마세요.

7. DNS 문제 해결 관련 자주 묻는 질문

추가로 확인하려면 규칙 매뉴얼에서 매칭 순서를 살펴보거나 연결 문제 안내에서 DNS 조회와 아웃바운드 연결 문제를 구분하세요. 이 사이트는 노드나 구독를 제공·판매·추천하지 않습니다. 계정 상태와 서버 설정은 사용자가 이용 중인 서비스 제공업체에 확인해야 합니다.