Shadowrocket의 연결 테스트에서 지연 시간이 표시되더라도 대상 웹페이지의 도메인 이름이 정상적으로 조회되었다는 뜻은 아닙니다. 사용 중인 서비스와 구독이 있고 현재 설정을 확인할 수 있다는 전제로, 네트워크, Global Routing, DNS, 규칙, 연결 로그를 차례로 점검합니다. 한 번에 설정 하나만 변경하고 같은 웹 주소로 다시 확인하세요. 마지막으로 DNS 조회 오류, 연결 시간 초과, TLS 오류를 구분합니다.
1. 연결 테스트가 정상이어도 웹페이지 요청이 모두 정상인 것은 아닙니다
웹페이지를 열려면 여러 단계를 거쳐야 합니다. 먼저 클라이언트가 대상 도메인에 해당하는 주소를 조회하고, 설정에 따라 연결 경로를 선택한 다음 전송 연결과 TLS 세션을 수립하고 페이지 내용을 요청합니다. 실제 조회는 기기에서 이루어질 수도, 원격에서 이루어질 수도 있습니다. 이 과정 중 어느 한 단계라도 실패하면 브라우저가 계속 대기할 수 있습니다.
Home의 Connectivity Test는 선택한 테스트 방식으로 확인한 결과만 보여 줍니다. 테스트 대상과 프로토콜은 웹페이지에서 사용하는 대상과 다를 수 있습니다. 테스트에 수치가 표시되어도 모든 도메인, 포트, 요청을 사용할 수 있다고 단정할 수는 없습니다.
예를 들어 테스트 결과가 80 ms로 표시되는데 브라우저에서 서버를 찾을 수 없다고 해도, 이 수치는 해당 테스트의 결과일 뿐입니다. 오류가 난 도메인의 조회 결과를 대신하지 않습니다. 문제를 확인할 때는 지연 시간 수치를 반복해서 비교하기보다 웹 주소의 도메인 부분, 오류 문구, 발생 시각을 기록하세요.
- 한 웹사이트만 열리지 않음: 도메인 철자, 해당 사이트의 조회 결과, 적용된 규칙을 먼저 확인합니다.
- 서로 다른 여러 웹사이트가 모두 열리지 않음: 기본 네트워크, 연결 상태, 공통 설정을 먼저 확인합니다.
- 페이지의 기본 틀은 표시되지만 이미지가 보이지 않음: 주소 표시줄의 도메인만 확인하지 말고 이미지나 스크립트가 실제로 요청한 도메인도 기록합니다.
- HTTP
403또는502오류가 바로 표시됨: HTTP 서비스에서 응답이 온 것이므로 응답 출처를 확인해야 합니다. 이를 곧바로 DNS 문제로 단정하지 마세요.
2. DNS를 변경하기 전에 Home과 Global Routing 확인하기
먼저 기기에서 현재 네트워크에 접속할 수 있는지 확인합니다. 웹 로그인이 필요한 Wi-Fi라면 먼저 인증을 마치세요. 그런 다음 Home으로 돌아가 연결 스위치, 선택한 서버, Global Routing을 확인합니다. 서버를 선택한 상태와 연결이 수립된 상태는 서로 다릅니다.
- 현재 네트워크가 Wi-Fi인지 셀룰러인지 기록하고, 같은 오류를 재현할 수 있는 웹 주소를 하나 정해 둡니다.
- Home에서 연결 상태를 확인합니다.
Not Connected로 표시된다면 먼저 연결 수립 문제를 해결하세요. 이 상태에서 발생한 오류를 설정 내 DNS 문제로 보아서는 안 됩니다. - Home → Global Routing으로 이동해 현재 선택된 항목을 기록합니다. 특히
Direct로 설정되어 있는지 확인하세요. - Connectivity Test를 한 번 실행해 테스트 방식과 결과를 기록한 다음, 같은 오류가 나는 웹 주소를 엽니다.
- 비교가 필요하면 현재 설정값을 기록한 뒤 일시적으로 라우팅 모드를 전환하고 한 번 재시험하세요. 확인을 마치면 원래 설정으로 되돌리고, DNS와 서버, 규칙을 한꺼번에 변경하지 마세요.
| 모드 | 점검할 내용 |
|---|---|
Proxy | 프록시 경로에서의 동작을 확인할 때 사용합니다. 모든 DNS 요청이 반드시 같은 경로로 조회된다는 뜻은 아닙니다. |
Direct | 트래픽이 직접 연결됩니다. 원래 프록시를 통해 접속하려던 경우 먼저 라우팅 모드를 바로잡으세요. |
Config | 현재 설정된 규칙에 따라 트래픽을 라우팅합니다. 오류가 난 도메인에 적용된 규칙과 정책을 확인해야 합니다. |
Scene | 설정된 Scene에 따라 라우팅 동작이 결정됩니다. 선택한 서버만 볼 것이 아니라 현재 Scene도 확인하세요. |
판단 기준: 라우팅 모드를 바꿔 비교하며 범위 좁히기
같은 네트워크와 서버에서 Proxy로는 열리지만 Config에서는 열리지 않는다면, 먼저 규칙과 설정에 따른 조회 경로를 확인하세요. 연결 정보를 전부 바꾸는 것은 그다음입니다.
3. DNS 설정 항목별 역할
DNS는 도메인 이름을 주소로 변환합니다. A 레코드는 IPv4 주소를, AAAA 레코드는 IPv6 주소를 제공합니다. 주소를 받았다는 것은 조회 결과가 있다는 뜻일 뿐, 기기에서 해당 주소로 연결할 수 있다는 뜻은 아닙니다. 특히 AAAA 레코드를 받은 뒤에도 연결에 실패한다면 “IPv6 주소를 받음”과 “IPv6 연결이 가능함”을 구분해야 합니다.
Settings → DNS에서 관련 설정을 확인하고, Config에서 현재 사용 중인 구성 파일도 살펴보세요. 전역 설정과 구성 파일이 실제 동작에 함께 영향을 줄 수 있습니다. 편집기에서 파일 하나를 확인했다고 해서 그 설정이 적용 중이라고 단정하지 마세요. 아래 표는 각 항목의 의미를 설명하며, 모든 항목을 직접 사용자 지정 값으로 바꾸라는 뜻은 아닙니다.
| 항목 | 기능 | 점검할 내용 |
|---|---|---|
| 시스템 DNS | 현재 시스템 네트워크에서 제공하는 DNS 설정을 사용합니다. | Wi-Fi와 셀룰러 네트워크를 전환하면 DNS 환경도 달라질 수 있습니다. |
| 사용자 지정 DNS | 조회 서버를 직접 지정합니다. | 서버 주소가 올바르더라도 현재 네트워크에서 해당 서버에 접속할 수 있다는 보장은 없습니다. |
| DNS over HTTPS | HTTPS를 통해 DNS 질의를 전송합니다. | 일반적으로 TCP 443을 사용합니다. 서비스 주소, TLS, 서버까지의 경로가 모두 정상이어야 합니다. |
| DNS over TLS | TLS를 통해 DNS 질의를 전송합니다. | 일반적으로 TCP 853을 사용하며, 네트워크 제한은 일반 DNS와 다를 수 있습니다. |
[Host] | 구성 파일에서 도메인과 주소를 직접 연결합니다. | 오래된 주소가 계속 사용될 수 있으므로 오류가 난 도메인에 수동 매핑이 있는지 확인하세요. |
기존 DNS는 보통 UDP 53을 사용하며, 일부 상황에서는 TCP 53도 사용합니다. 암호화 전송은 질의가 오가는 경로를 바꾸지만, 대상 웹사이트의 중단이나 잘못된 규칙, 연결할 수 없는 주소를 자동으로 해결하지는 않습니다. “암호화”를 이유로 출처가 불분명한 DNS 주소를 여러 개 입력하지 마세요.
시스템 DNS와 비교하려면 먼저 기존 설정을 백업한 뒤 Config에서 테스트용 복사본을 편집하고, 기존 [General] 섹션의 dns-server를 확인하세요. 아래 내용은 관련 필드만 보여 주는 예시이며 전체 설정이 아닙니다. 원본 파일의 다른 섹션을 덮어쓰지 마세요.
[General]
dns-server = system이미 [General] 섹션이 있다면 해당 필드를 수정하고, 같은 섹션을 반복해서 추가하지 마세요. 저장한 뒤 테스트용 복사본이 실제 사용 중인지 확인하고 연결을 다시 수립해 재시험합니다. 수동 DNS 설정도 사용 중이라면 함께 기록해 두세요. 두 변수를 동시에 바꾼 결과를 하나의 변화로 오해하지 않도록 하기 위해서입니다.
4. 순서를 정해 한 번에 하나씩 점검하기
목표는 “어느 단계가 바뀐 뒤 결과가 달라졌는지” 확인하는 것입니다. 먼저 원래 설정과 상태를 기록한 뒤 아래 순서대로 진행하세요. 매번 같은 오류 도메인을 사용해야 테스트 대상을 바꿔 결과를 비교하기 어려워지는 일을 막을 수 있습니다.
- 오류 범위 확인. 평소 열리는 웹사이트 두 곳과 오류가 나는 웹사이트를 차례로 엽니다. 모든 사이트가 열리지 않는지, 특정 사이트만 실패하는지, 정적 리소스만 표시되지 않는지 기록하세요.
- 네트워크 변경 비교. 가능하다면 같은 설정으로 Wi-Fi와 셀룰러 네트워크를 비교합니다. 한 네트워크에서만 실패한다면 해당 네트워크의 인증 상태, DNS 서버 연결 가능 여부, 접근 제한을 확인하세요.
- 설정 적용 상태 확인. Config에서 실제 사용 중인 파일을 확인하고, Home → Global Routing에서 현재 모드를 확인하세요. “파일을 편집함”이 “해당 파일을 사용 중임”을 뜻하지는 않습니다.
- DNS 출처 비교. 원래 설정을 기록한 뒤 시스템 DNS와 기존 사용자 지정 DNS를 임시로 비교합니다. 결과가 다르면 DNS 서버에 연결할 수 있는지, 반환된 주소가 서로 다른지 확인하세요.
- 로컬 매핑과 규칙 확인. 현재 설정에서 오류가 난 도메인과 상위 도메인을 검색하고
[Host]및[Rule]도 확인하세요. 더 포괄적인 규칙이 먼저 적용될 수 있습니다. - 연결을 다시 수립한 뒤 재시험. 설정을 저장한 후 연결을 끊었다가 다시 연결하고 페이지를 재요청합니다. 앱이 기존 연결이나 캐시를 유지할 수 있으므로 필요하면 관련 앱을 완전히 종료한 뒤 다시 여세요.
- 효과 없는 변경은 원복. 특정 단계를 거쳐도 개선되지 않으면 원래 값으로 되돌리세요. 원인을 설명하기 어려운 변경 사항이 여러 개 남지 않도록 합니다.
브라우저 주소창에 웹사이트 IP를 직접 입력하는 방법만으로 DNS를 비교하지 마세요. HTTPS는 인증서 확인과 사이트 선택에 도메인을 사용합니다. IP로 직접 접속하면 인증서 오류가 발생하거나 다른 사이트가 열릴 수 있으며, 원래 DNS에는 문제가 없을 수도 있습니다.
백그라운드에서 연결이 자동으로 다시 수립될 수 있다면 Settings → On Demand도 확인하세요. On Demand는 연결을 시작하는 조건을 관리하며 도메인을 주소로 변환하지는 않습니다. 연결을 끊은 상태와 비교할 때는 해당 기능의 활성화 여부를 기록해 자동 재연결 후의 요청을 직접 연결 결과로 오해하지 않도록 하세요.
5. DNS 조회 오류, 시간 초과, 규칙 적용 구분하기
“열리지 않음”보다 실제 오류 문구가 원인을 찾는 데 더 유용합니다. 아래는 Apple 네트워크 프레임워크에서 표시될 수 있는 영어 오류이며, 브라우저나 Shadowrocket의 모든 화면에 똑같이 표시되는 것은 아닙니다. 로그에 오류 도메인과 코드가 있다면 원문과 함께 기록하세요.
오류: A server with the specified hostname could not be found.
원인 및 해결 방법: NSURLErrorDomain -1003은 지정된 호스트를 찾을 수 없다는 뜻입니다. 먼저 도메인 철자를 확인한 다음 해당 도메인의 조회 결과, DNS 서버 연결 가능 여부, 로컬 매핑을 점검하세요.
오류: The request timed out.
원인 및 해결 방법: NSURLErrorDomain -1001은 요청 시간이 초과되었다는 뜻이지만, DNS 오류라고 단정할 수는 없습니다. 조회, 연결 수립, 서버 응답 중 어느 단계에서 멈췄는지 순서대로 확인하세요.
오류: A server with the specified hostname could not be found.
원인 및 해결 방법: 오류가 사용자 지정 암호화 DNS 서비스의 호스트명과 관련된 것이라면 DNS 서비스 자체의 초기 조회 단계에서 실패했을 수 있습니다. 서비스 주소를 기록하고 시스템 DNS로 비교해 보세요. 대상 웹사이트의 규칙을 바꾸는 것은 적절한 조치가 아닙니다.
오류: An SSL error has occurred and a secure connection to the server cannot be made.
원인 및 해결 방법: NSURLErrorDomain -1200은 보안 연결 수립 실패를 나타냅니다. 기기의 날짜와 시간, 대상 호스트, 인증서 관련 정보를 확인하세요. 인증서 검증을 끄는 방식으로 문제를 숨기지 마세요.
Config 모드에서는 규칙도 결과에 영향을 줍니다. 규칙은 일반적으로 위에서 아래로 확인하며, 일치하는 규칙의 정책을 적용합니다. 아래는 예시 도메인으로 순서를 설명한 것으로, 그대로 교체해 사용할 수 있는 전체 설정이 아닙니다.
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,REJECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX,example.com,DIRECT는example.com과 하위 도메인에 일치합니다. 이 규칙이 앞에 있으면 뒤에 있는 FINAL은 해당 요청의 정책을 결정하지 않습니다.IP-CIDR은 IP 주소 대역에 일치합니다. 예시에 나온192.0.2.0/24는 문서용 주소 대역이며, 대상 서비스로 추가하라는 뜻이 아닙니다.no-resolve는 해당 IP 규칙과 일치하는 항목에 대해 도메인 조회를 별도로 시작하지 않는다는 뜻입니다. 이후 요청에 DNS가 전혀 필요하지 않다는 뜻은 아닙니다.GEOIP는 IP 지리 정보에 따라 일치 여부를 판단합니다. 웹사이트에서 사용하는 언어나 도메인 접미사를 기준으로 판단하지 않습니다.FINAL,PROXY는 앞선 규칙에 모두 일치하지 않을 때 적용되는 기본 규칙입니다. 점검할 때는 PROXY에 연결된 실제 아웃바운드도 확인하세요.
판단 기준: 주소를 받은 뒤에도 실패한다면 연결 단계 확인하기
로그에 대상 주소가 표시된 뒤 연결 시간 초과가 발생한다면, 먼저 적용된 정책과 대상 포트, 아웃바운드 경로를 확인하세요. 웹페이지가 열리지 않는다는 이유만으로 DNS를 계속 바꾸지 마세요.
6. 자주 묻는 질문과 점검 기록 정리
Connectivity Test에 수치가 표시되는데 Safari에서 웹페이지가 열리지 않는 이유는 무엇인가요?
먼저 Home에서 테스트 방식을 기록한 뒤 Home → Global Routing을 확인하세요. 테스트 대상과 웹페이지에서 접속하는 대상은 다를 수 있습니다. 같은 오류가 난 웹 주소의 조회 결과와 적용된 정책을 각각 확인하세요. 지연 시간 하나만으로 모든 사이트에 접속할 수 있다고 판단해서는 안 됩니다.
셀룰러 네트워크에서는 잘 열립니다. 모든 DNS를 변경해야 하나요?
먼저 설정을 그대로 둔 채 네트워크에 따른 차이를 다시 확인하세요. Wi-Fi 인증이 필요한지, 현재 네트워크에서 DNS 서버에 연결할 수 있는지 점검합니다. DNS 출처가 결과에 영향을 준다는 것을 비교로 확인한 뒤에 해당 설정만 변경하세요.
DNS를 변경했는데 이전 결과가 계속 표시되면 어떻게 해야 하나요?
먼저 Config에서 수정한 파일을 실제로 사용 중인지 확인한 다음 연결을 다시 수립하고 페이지를 새로 요청하세요. Settings → DNS와 구성의 [Host]에 수동 설정이 남아 있는지 살펴보세요. dns-server 필드를 계속 추가하지 마세요.
구독 업데이트만 실패해도 DNS 문제라고 판단할 수 있나요?
아니요. 구독 요청은 링크 유효성, 인증, 서버 응답의 영향도 받을 수 있습니다. 업데이트 시 표시된 오류 원문을 기록하고, 사용 중인 서비스 제공업체에 기존 구독이 유효한지 확인하세요. 점검 기록에 전체 구독 주소를 공개하지 마세요.
추가 지원이 필요하다면 아래 정보를 정리하면 됩니다. 민감한 정보를 가리지 않은 전체 설정 파일보다 문제를 재현하는 조건을 명확히 정리하는 것이 더 유용합니다. 구독 인증 정보, 비밀번호, 개인 키, 전체 액세스 토큰은 반드시 가리세요.
- 오류가 난 도메인, 발생 시각, 웹페이지에 표시된 오류 원문.
- 기기가 Wi-Fi와 셀룰러 중 어떤 네트워크를 사용하는지, 네트워크를 바꾸면 증상이 달라지는지.
- Home의 연결 상태, Global Routing 선택 항목, Connectivity Test의 방식과 결과.
- 현재 사용 중인 구성 이름, 관련 DNS 필드, 해당하는 [Host] 매핑이 있는지.
- 관련 규칙과 순서, 로그에서 확인할 수 있는 대상 주소, 적용된 정책 또는 연결 오류.
- 시도한 개별 변경 사항과 각 결과, 원래대로 되돌린 설정.
Shadowrocket은 상용 비공개 앱이며 주로 iPhone과 iPad에서 사용합니다. 앱을 받을 수 있는 유일한 경로는 App Store입니다. 앱 구매와 연결 서비스는 별개이며, 일회성 구매에 사용자의 연결 서비스가 포함되지는 않습니다. 시스템 요구 사항은 App Store 페이지 표기를 기준으로 확인하세요.