이 글은 iPhone 또는 iPad에서 Shadowrocket을 설정하고, 이용 중인 서버나 구독이 있지만 지연 테스트는 정상인데 웹페이지가 로드되지 않는 경우에 유용합니다. ‘증상 확인 → 라우팅 비교 → DNS 확인 → IPv6 점검 → 재테스트’ 순서로 진행하면 DNS 조회 오류, 서버 연결 오류, 규칙 라우팅 문제를 구분할 수 있습니다. 한 번에 여러 설정을 바꿔 원인 파악이 어려워지는 일을 줄여 보세요.
1. 지연 테스트가 정상이어도 웹 요청이 성공한 것은 아닙니다
Shadowrocket의 지연 결과는 해당 테스트 방식으로 특정 연결 단계가 그 시점에 완료됐다는 뜻일 뿐입니다. TCP 테스트는 주로 서버 포트에 연결할 수 있는지를 확인하며, HTTP 계열 테스트도 지정된 대상과 경로만 확인합니다. 문제가 발생한 웹사이트의 DNS 조회, TLS 핸드셰이크, 페이지 리소스 로드까지 확인해 주지는 않습니다.
웹페이지를 열려면 보통 도메인을 IP 주소로 조회한 다음 선택한 직접 연결 또는 프록시 경로로 연결하고, TLS 핸드셰이크와 HTTP 요청을 완료해야 합니다. 프록시를 사용하는 경우 대상 도메인 조회를 원격 서버에서 처리할 수도 있습니다. 지연 시간만으로 로컬 DNS와 원격 DNS가 모두 정상인지 확인할 수 없으며, 웹사이트에 반드시 접속할 수 있다고 단정할 수도 없습니다.
이 포트는 DNS 전송 방식에 관한 설명이지, 서버 포트를 해당 값으로 변경하라는 뜻이 아닙니다. DNS over HTTPS 연결이 정상이어도 대상 웹사이트에 접속할 수 있다는 보장은 없습니다. 반대로 일반 웹페이지가 열린다고 해서 네트워크에서 모든 DNS 전송 방식을 사용할 수 있는 것도 아닙니다.
2. 재현 가능한 방식으로 오류를 비교하세요
같은 전체 URL, 같은 브라우저, 같은 기기를 사용해 확인하세요. 웹사이트 홈, 사이트 내 이동, 동영상 재생을 하나의 테스트로 묶지 마세요. 기본 문서는 열렸더라도 이미지, 로그인 또는 미디어에 사용되는 다른 도메인은 실패할 수 있습니다. 매번 조건 하나만 바꾸고 결과를 기록하세요.
- 문제 범위를 확인하세요. 오류가 발생한 웹사이트와 이전에 정상적으로 열렸던 웹사이트를 각각 방문하세요. 모든 페이지가 실패하는지, 특정 도메인만 실패하는지, 텍스트는 표시되지만 이미지가 계속 로드 중인지 기록하세요.
- 기본 네트워크를 확인하세요. Shadowrocket 연결을 잠시 중지하고 현재 네트워크에서 웹 로그인을 통한 인증이 필요한지 확인하세요. 이 단계는 기본 네트워크를 점검하기 위한 것이며, 문제가 발생한 웹사이트에 직접 연결할 수 있어야 한다는 뜻은 아닙니다.
- 기존 연결을 복원하세요. Home으로 돌아가 이용 중인 서버를 선택하고 연결을 켠 뒤 같은 URL에 접속하세요. 지연 테스트만 반복하지 마세요.
- 네트워크를 바꿔 비교하세요. 서버와 설정은 그대로 두고 Wi-Fi와 셀룰러 네트워크를 전환해 다시 테스트하세요. 특정 Wi-Fi에서만 실패한다면 해당 네트워크의 DNS 연결 가능성, 인증 상태 또는 접속 제한을 우선 확인하세요.
- 자동 재연결의 영향을 확인하세요. 연결을 중지한 뒤 자동으로 다시 켜진다면 Settings → On Demand를 확인하세요. 기존 설정을 기록하고 테스트하는 동안 필요에 따라 일시 중지한 뒤, 테스트가 끝나면 원래대로 복원하세요.
브라우저가 기존 연결을 재사용하거나 DNS 캐시가 남아 있을 수 있습니다. 설정을 바꾼 뒤에는 Shadowrocket 연결을 끊었다가 다시 켜고 문제가 발생한 페이지를 새로 여세요. 결과가 계속 달라진다면 관련 브라우저 탭을 닫고 다시 시도할 수 있습니다. 한 번 새로고침에 성공했다고 문제가 해결된 것으로 판단하지 마세요.
3. Global Routing으로 라우팅 문제와 DNS 문제 구분하기
Home → Global Routing에서 현재 옵션을 확인하세요. Config는 현재 설정에 따라 트래픽을 처리한다는 뜻이며, 모든 요청이 프록시를 통과한다는 의미는 아닙니다. Proxy는 선택한 프록시로 트래픽을 보내 비교할 때 주로 사용하고, Direct는 직접 연결을 비교할 때 사용합니다. Scene은 장면 설정에 따라 동작하므로 문제를 확인할 때는 현재 적용 중인 장면도 확인해야 합니다. 이름만 보고 실제 연결 경로를 단정하지 마세요.
| 비교 결과 | 우선 확인할 항목 | 다음 단계 |
|---|---|---|
| Config 실패, Proxy 성공 | 규칙 적용, 정책 선택 및 경로별 DNS 조회 차이 | 현재 Config에서 대상 도메인에 적용되는 규칙과 정책을 확인하세요 |
| Config와 Proxy 모두 실패 | 현재 서버, DNS 연결 가능성 또는 대상 웹사이트 | 설정은 그대로 두고 이미 이용 중인 다른 서버와 비교하세요 |
| Direct 성공, Proxy 실패 | 프록시 출구, 원격 DNS 조회 또는 대상 사이트의 출구 제한 | 서버 상태를 확인하고 규칙 전체를 먼저 수정하지 마세요 |
| 특정 네트워크에서만 실패 | 해당 네트워크의 전송 제한 및 DNS 경로 | Wi-Fi와 셀룰러 네트워크를 비교하고 DNS 전송 방식을 확인하세요 |
결론: Proxy에서 성공하면 먼저 Config를 확인하세요
같은 서버와 네트워크에서 Config로만 실패한다면 DNS를 조정하기 전에 대상 도메인과 일치하는 규칙 및 실제 정책부터 확인하세요. Proxy를 계속 사용하는 것을 규칙 문제가 해결된 것으로 여기지 마세요.
이러한 결과는 문제 범위를 좁히기 위한 단서이지, 한 번의 테스트로 확정할 수 있는 증거는 아닙니다. Global Routing을 바꾸면 연결 경로와 DNS 조건이 함께 달라질 수 있으므로 다음 절의 DNS 설정도 하나씩 확인해야 합니다. 비교가 끝나면 평소 사용하는 옵션으로 되돌리세요.
4. DNS 주소, 전송 방식 및 설정 출처 확인하기
Settings → DNS를 열고 현재 표시되는 DNS 설정을 기록하세요. 이어서 Config에서 실제로 사용하는 설정 파일에 DNS 관련 설정이 있는지 확인하세요. 주소 하나만 바꾸고 적용됐다고 판단하지 마세요. 설정 파일, 전역 설정 및 관련 옵션의 조합에 따라 동작이 달라질 수 있으므로 다시 연결한 뒤 요청 결과로 확인해야 합니다.
- 입력한 값이 해당 필드에 맞는지 확인하세요. 일반 DNS 주소, DNS over HTTPS의 전체 URL, DNS over TLS 서버 이름은 서로 바꿔 쓸 수 있는 값이 아닙니다. 인터페이스에서 지원하는 형식에 맞게 입력하고, 구독 URL을 DNS 필드에 붙여 넣지 마세요.
- 엔드포인트가 완전한지 확인하세요. DNS over HTTPS에는 일반적으로 전체 HTTPS 엔드포인트가 필요합니다. 웹사이트 홈 주소만 보고 DNS 서비스를 제공한다고 판단할 수는 없습니다. 이용 중인 DNS 서비스의 안내를 확인하고 경로를 임의로 조합하지 마세요.
- 초기 DNS 조회가 필요한지 확인하세요. DNS 엔드포인트가 도메인 이름을 사용한다면 연결 전에 해당 도메인을 먼저 조회해야 할 수 있습니다. 기본 DNS를 사용할 수 없는 상황에서는 도메인 형식만 다른 엔드포인트로 바꿔도 해결되지 않을 수 있습니다.
- 연결 경로가 열려 있는지 확인하세요. 현재 네트워크에서 HTTPS는 허용하더라도 다른 포트는 제한할 수 있습니다. 프록시 서버가 도메인 이름을 사용한다면 프록시 연결 전에 필요한 DNS 조회도 고려해야 합니다. DNS 요청과 프록시 연결 과정이 서로 의존하지 않도록 하세요.
- 하나씩 바꾸고 다시 테스트하세요. 먼저 현재 설정을 백업한 뒤, 사용 가능 여부를 확인한 DNS 설정과 비교하세요. 현재 서버, Global Routing, 테스트 URL은 그대로 두고 다시 연결한 다음 결과를 기록하세요.
DNS 변경 후 문제가 해결되면 다시 연결하거나 네트워크를 전환한 뒤에도 계속 정상인지 확인하세요. 처음에만 성공하고 다시 실패한다면 캐시, 엔드포인트 연결 가능성 또는 자동 전환 조건을 살펴보세요. 구독을 새로고침하면 서버 정보는 업데이트되지만 현재 Config의 DNS 설정까지 함께 업데이트되는 것은 아닙니다.
5. 오류 메시지에 따라 점검 방향 정하기
오류는 브라우저, 시스템 네트워크 계층 또는 요청 로그에 표시될 수 있으며, 반드시 Shadowrocket 자체의 알림인 것은 아닙니다. 아래 문구는 흔히 볼 수 있는 네트워크 오류이며 기기마다 동일하게 표시된다고 보장할 수 없습니다. 단순히 ‘열리지 않음’이라고 기록하기보다 오류가 대상 웹사이트 도메인, 프록시 서버 도메인, DNS 엔드포인트 도메인 중 어디에 해당하는지 기록하는 편이 유용합니다.
오류: The server with the specified hostname could not be found.
원인 및 해결 방법: 호스트 이름을 조회해 사용할 수 있는 결과를 얻지 못했거나 도메인 철자가 틀렸거나 도메인 자체가 더 이상 유효하지 않을 수 있습니다. 전체 도메인을 확인하고 Settings → DNS와 현재 Config를 비교한 다음 다른 네트워크에서도 같은 URL을 테스트하세요.
오류: NXDOMAIN
원인 및 해결 방법: DNS 리졸버가 도메인이 존재하지 않는다고 응답한 경우로, 응답 대기 시간 초과와는 다릅니다. 도메인 철자와 잘못 추가된 하위 도메인이 있는지 확인한 뒤, 사용 가능 여부를 확인한 다른 DNS 경로와 비교하세요. 대기 시간을 계속 늘려 해결하려 하지 마세요.
오류: SERVFAIL
원인 및 해결 방법: DNS 리졸버가 조회를 완료하지 못한 경우이며, 상위 DNS 서버의 오류나 도메인 검증 문제가 원인일 수 있습니다. 다른 조건은 그대로 둔 채 사용 가능한 다른 DNS 경로와 비교하세요. 같은 도메인에서만 문제가 발생한다면 결과를 기록해 이용 중인 서비스 제공자에게 문의하세요.
오류: The request timed out.
원인 및 해결 방법: 요청의 특정 단계가 제한 시간 안에 완료되지 않은 것이지만, 이 문구만으로 DNS 오류라고 단정할 수는 없습니다. 먼저 IP 주소 조회가 완료됐는지 확인하고 연결 경로를 살펴보세요. 조회가 성공했다면 TCP, TLS 또는 대상 서비스의 응답을 추가로 점검하세요.
인증서 오류가 발생하면 기기의 날짜와 시간, 대상 도메인, 설정한 엔드포인트가 올바른지 확인하세요. 이는 ‘도메인을 찾을 수 없음’과 다른 유형의 문제입니다. 오류를 없애려고 TLS 검증을 끄지 말고, 실패한 단계를 구분하기 전에 DNS, 서버, 프로토콜을 한꺼번에 바꾸지 마세요.
6. 일부 도메인만 실패할 때: 규칙, AAAA, 페이지 리소스 확인하기
대부분의 웹사이트는 정상인데 일부 도메인만 실패한다면 차이가 나는 부분부터 확인하세요. A 레코드는 IPv4 주소를, AAAA 레코드는 IPv6 주소를 제공합니다. AAAA 레코드가 있다고 해서 현재 네트워크에서 IPv6 경로를 사용할 수 있는 것은 아닙니다. DNS 조회는 성공했지만 연결이 지연된다면 원래대로 되돌릴 수 있는지 확인한 뒤 IPv6 관련 설정을 비교하세요. 한 번에 하나만 바꾸고 테스트 후 원래 설정으로 복원하거나 최종 설정을 기록하세요.
규칙은 순서대로 적용됩니다. DOMAIN-SUFFIX는 지정된 도메인과 그 하위 도메인에 적용됩니다. IP-CIDR과 GEOIP는 IP 정보를 기준으로 하며, 경우에 따라 판정 전에 DNS 조회가 필요합니다. FINAL은 앞선 규칙에 해당하지 않을 때 적용되는 기본 규칙입니다. 아래 내용은 순서와 문법을 설명하기 위한 예시이며 기존 설정을 그대로 교체하라는 뜻은 아닙니다.
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY- 먼저 도메인 규칙을 확인하세요. 예시에서는
example.com과 그 하위 도메인이 먼저 DIRECT 규칙에 적용됩니다. 해당 도메인에 이용자 본인의 프록시가 필요한 경우 앞에서 잘못된 규칙이 적용되는지 확인하세요. - no-resolve의 의미를 확인하세요. 이 옵션은 해당 IP 규칙을 위해 도메인 조회를 직접 시작하지 않도록 하는 기능입니다. DNS 문제를 해결하는 범용 옵션이 아니며, 요청에서 DNS 조회가 절대 발생하지 않는다는 보장도 없습니다.
- 정책이 실제로 있는지 확인하세요. 예시의
PROXY는 실제로 사용할 수 있는 정책에 연결되어야 합니다. 이름만 복사하고 현재 설정에 해당 정책이 정의되어 있는지 확인하지 않는 실수를 피하세요. - 페이지의 추가 리소스를 확인하세요. 페이지 텍스트는 정상적으로 표시되지만 이미지가 로드되지 않는다면 이미지, 스크립트 또는 로그인 요청에 사용되는 도메인을 확인하세요. 기본 도메인의 규칙만 바꾸면 별도의 리소스 도메인에는 적용되지 않을 수 있습니다.
결론: IP 주소가 조회됐는데 연결되지 않으면 다음 단계를 확인하세요
문제가 발생한 도메인의 IP 주소가 확인됐는데도 연결 또는 TLS 단계에서 요청이 멈춘다면 실제 출구, IPv4 / IPv6 경로, 대상 사이트의 응답을 우선 확인하세요. 모든 실패를 DNS 조회 문제로 돌리지 마세요.
7. 자주 묻는 질문과 최종 점검
지연 테스트는 계속 정상인데 서버를 바꾸면 왜 웹페이지가 열리나요?
지연 테스트는 테스트 대상과 일부 연결 단계만 확인합니다. 다른 서버는 출구, 원격 DNS 조회 또는 대상 사이트에 대한 연결 가능성이 다를 수 있습니다. DNS와 Config를 그대로 둔 채 두 서버를 비교하고, 서버를 바꿀 때 문제가 발생한 웹사이트도 함께 달라지는지 기록하세요. 이 결과만으로 로컬 DNS에 문제가 있다고 단정하지 마세요.
Proxy로 전환하면 열리는데 Config는 확인하지 않아도 되나요?
문제 범위를 좁히는 단서로 활용할 수 있지만 Config로 돌아가 규칙 순서, 대상 도메인에 적용되는 정책, DNS 관련 설정을 확인해야 합니다. 수정한 뒤 평소 사용하는 옵션으로 전환하고 같은 웹페이지와 페이지 리소스가 모두 로드되는지 확인하세요.
Wi-Fi에서만 오류가 나고 셀룰러 네트워크에서는 정상인데 앱을 다시 설치해야 하나요?
먼저 앱을 다시 설치할 필요는 없습니다. 같은 서버와 설정을 유지한 채 Wi-Fi 로그인 인증과 DNS 전송 연결 가능성을 확인하세요. 연결을 중지한 뒤 자동으로 다시 켜진다면 Settings → On Demand도 확인해 자동 재연결로 테스트 조건이 바뀌지 않도록 하세요.
구독을 업데이트하면 DNS도 복구되나요?
반드시 그런 것은 아닙니다. 서버 구독과 Config에는 서로 다른 정보가 포함됩니다. 먼저 Home에서 현재 선택된 서버가 바뀌었는지 확인한 뒤 Config에서 실제 설정을 확인하고 마지막으로 Settings → DNS를 살펴보세요. 서버 목록 업데이트를 모든 네트워크 설정의 초기화로 여기지 마세요.
수정한 뒤에는 원래 오류가 발생한 URL, 정상 여부를 비교할 URL 하나, 네트워크 전환 후 결과를 각각 테스트하세요. 이용 중인 서비스 제공자에게 문의해야 한다면 실패한 도메인, 시각, 네트워크, Global Routing 옵션, 오류 메시지 원문, 수정 전후 비교 결과를 전달하세요. 구독 토큰, 서버 비밀번호와 기타 인증 정보는 스크린샷이나 로그에서 삭제하세요.
- 도메인 조회 오류, 연결 시간 초과, TLS 오류를 구분했으며 지연 결과만으로 원인을 단정하지 않았습니다.
- 현재 Home에서 선택한 서버, Config 파일, Global Routing 옵션을 확인했습니다.
- DNS 주소 형식, 엔드포인트 연결 가능성, 초기 DNS 조회 필요 여부를 확인했습니다.
- 임시로 변경한 On Demand, 라우팅, IPv6 관련 옵션을 복원했거나 유지할 설정을 기록했습니다.
- 한 번만 페이지가 열린 것이 아니라 다시 연결한 뒤에도 문제가 해결된 상태인지 확인했습니다.