Shadowrocket 문제 해결
연결, 구독 및 규칙

스위치가 켜지지 않을 때: 권한과 시스템 제한 확인

스위치가 바로 꺼짐, 연결 중 상태가 계속됨, 앱이 갑자기 종료됨은 서로 다른 증상입니다. 먼저 문제가 발생한 시점을 확인하세요. 시스템 권한 요청이 나타나기 전인지, VPN 구성을 추가하도록 허용한 직후인지, 특정 서버를 선택한 뒤인지 기록합니다. 이때 구독을 모두 삭제하거나 연결 버튼을 연속으로 누르지 마세요. 연결을 끄고 시스템 상태가 안정될 때까지 기다린 다음, 일반 브라우저에서 현재 네트워크로 평소 접속 가능한 페이지가 열리는지 확인하세요. 기본 네트워크가 정상화되기 전에는 서버 테스트와 규칙 변경 결과를 비교하기 어렵습니다.

VPN 권한이 승인되었는지 확인

처음 연결할 때 시스템에서 VPN 구성 추가를 허용하고 기기 암호나 시스템 인증으로 확인하라는 메시지가 표시될 수 있습니다. 요청을 취소하면 권한이 승인되지 않습니다. 앱 스위치가 잠시 바뀌는 것만으로 시스템 확인을 대신할 수는 없습니다. Home으로 돌아가 연결을 다시 시도하고 팝업 내용을 끝까지 확인하세요. 그런 다음 시스템 Settings에서 VPN을 찾아 해당 구성이 있는지 확인합니다. 메뉴 이름과 위치는 시스템 버전에 따라 다를 수 있으므로 설정 검색을 이용하세요. 구성이 있지만 계속 활성화되지 않는다면 먼저 연결을 끊고, 해당 VPN 구성만 제거한 뒤 권한을 다시 부여해 보세요. 앱에 저장된 서버와 Config는 보존하세요.

기기가 회사나 학교의 관리 대상인 경우, 관리 정책에 따라 VPN 추가, 네트워크 확장 기능 또는 백그라운드 연결이 제한될 수 있습니다. 이러한 제한은 관리자에게 확인해야 하며 구독을 다시 가져와도 시스템 정책은 바뀌지 않습니다. 용도를 모르는 관리 프로파일은 제거하지 마세요. 같은 기기에서 다른 VPN 연결이나 로컬 VPN을 사용하는 네트워크 필터링 기능이 작동 중이라면 하나를 잠시 중지하고 Shadowrocket만 실행해 보세요. 여러 네트워크 도구의 상태를 동시에 바꾸면 실패 원인을 파악하기 어렵습니다.

자동 재연결 및 설정 오류 확인

On Demand가 켜져 있으면 수동으로 연결을 끈 뒤에도 다시 연결되거나 네트워크가 바뀔 때 재시도할 수 있습니다. 수동 연결 과정을 한 번 온전히 확인하려면 On Demand를 잠시 끄고 기존 조건을 기록하세요. 테스트가 끝난 뒤 원래대로 복원하면 됩니다. 특정 서버 정보를 선택했을 때만 스위치가 꺼진다면 Add Server에서 주소, 포트 또는 프로토콜 필수 항목이 빠졌는지 확인하세요. 구독 이름이 정상적으로 표시되어도 모든 항목이 올바르다는 뜻은 아닙니다. 가져오는 과정에서 인식되지 않은 필드는 사용자가 가진 원본 정보와 하나씩 대조해야 합니다.

앱은 정상적으로 열리지만 시스템 권한 응답이 오지 않는다면 연결을 끄고 앱을 종료한 다음 다시 실행하세요. 그래도 달라지지 않으면 기기를 재시동합니다. 재시동은 일시적인 확장 기능 상태를 초기화하기 위한 것으로, 설정이 올바르다는 증거는 아닙니다. 재시동 후에는 기존 서버 항목 하나만 테스트하고 구독 업데이트나 규칙 변경은 함께 하지 마세요. 정상화되면 다음 화면 잠금 및 네트워크 전환 때 문제가 재현되는지 확인합니다. 계속 실패한다면 반복해서 재설치하기보다 저장 공간, 시스템 제한, 현재 설정을 점검하세요.

설치 차단과 연결 문제 구분

앱이 아예 열리지 않는다면 뒤의 네트워크 문제 해결에 앞서 설치 문제부터 해결하세요. Shadowrocket은 iPhone, iPad, Mac, Windows, Android 및 Linux를 지원합니다. iPhone / iPad 버전은 App Store에서 미화 $2.99 일회성 구매이며, Mac(Apple 칩 및 Intel), Windows, Android, Linux 버전은 무료입니다. iPhone / iPad의 시스템 요구 사항은 App Store 페이지 표기를 기준으로 확인하세요. 다른 플랫폼의 설치 파일은 이 사이트의 다운로드 페이지에서 받을 수 있으며, 실제 파일은 사이트의 /dl/ 경로에서 제공됩니다.

데스크톱 및 Android 설치 파일에는 코드 서명이 없어 처음 실행할 때 시스템에서 차단될 수 있습니다. 파일이 이 사이트에서 받은 것인지 확인한 다음, Windows에서는 SmartScreen의 ‘추가 정보’에서 ‘실행’을 선택하세요. Mac에서는 ‘개인정보 보호 및 보안’에서 이번 실행을 허용하고, Android에서는 시스템 안내에 따라 사용하는 브라우저나 파일 관리자에 알 수 없는 앱 설치를 허용합니다. Linux에서는 파일 권한과 패키지 형식도 확인해야 합니다. 자세한 설치 방법은 설치 차단 해제 안내를 참고하세요. 설치 문제를 해결하기 위해 규칙을 반복해서 변경하지 마세요.

연결 후 인터넷이 안 될 때: 터널, 서버, 라우팅 구분

연결 표시는 정상인데 페이지가 열리지 않는다면 먼저 모든 요청이 실패하는지, 일부 도메인만 실패하는지 확인하세요. Shadowrocket을 끈 상태에서 평소 직접 접속할 수 있는 페이지를 열어 봅니다. 그래도 실패한다면 라우터, 모바일 데이터, Wi-Fi 인증 또는 시스템 프록시 설정부터 확인하세요. 호텔이나 방문자 네트워크에서는 브라우저로 먼저 네트워크 인증을 해야 하는 경우가 있습니다. 터널을 먼저 연결하면 인증 페이지가 나타나지 않을 수 있습니다. 인증을 완료한 다음 연결을 켜야 네트워크 접속이 허용되지 않은 문제를 서버 오류로 오인하지 않습니다.

Global Routing으로 잠깐 비교 테스트

기본 네트워크가 정상인지 확인한 후, 사용자가 보유한 정보가 완전한 서버 항목 하나를 선택해 같은 대상과 네트워크로 비교하세요. Global Routing의 모드는 Config, Proxy, Direct입니다. 모드를 바꾸는 것은 원인을 좁히기 위한 방법이지, 장기적인 해결책은 아닙니다. 전환할 때마다 요청을 새로 보내세요. 기존 페이지는 이전 연결이나 캐시를 사용할 수 있으므로 화면에 기존 내용이 보이는지만으로 판단하기 어렵습니다.

Direct에서는 일반 페이지가 열리고 Proxy에서는 같은 페이지가 실패한다면 서버 설정값과 서버에서 대상까지의 경로를 확인하세요. Proxy는 정상이고 Config에서 실패한다면 활성화된 Config, 규칙 순서, 정책 이름을 확인합니다. 세 모드가 모두 실패하더라도 바로 규칙 문제라고 단정하지 말고 기본 네트워크, DNS, 시스템 연결 상태를 다시 확인하세요. 웹사이트마다 네트워크 경로에 따른 접속 조건이 다를 수 있으므로 용도가 서로 다른 테스트 대상을 최소 두 개 선택하세요. 한 사이트의 결과만으로 모든 트래픽을 판단하지 마세요.

선택한 항목과 실제 적용 항목이 일치하는지 확인

Home에서 선택한 서버가 Config의 모든 정책에서 최종적으로 사용되는 서버라는 보장은 없습니다. Config는 정책 그룹을 참조하거나 일부 요청을 DIRECT 또는 REJECT로 보낼 수 있습니다. 요청 기록을 열고 방금 테스트한 도메인을 찾아 적용된 규칙과 최종 정책을 확인하세요. 새 기록이 전혀 없다면 요청을 다시 보냈는지, 시스템이 현재 터널에 연결되어 있는지, 테스트 앱이 실제로 네트워크에 접속했는지 확인합니다. 기록은 있지만 정책이 예상과 다르다면 서버를 계속 바꾸기보다 규칙부터 수정하세요.

Config를 확인할 때는 먼저 현재 사용 중인 파일을 확인하고 복사본을 편집하세요. 규칙은 일반적으로 위에서 아래 순서로 적용되므로 구체적인 도메인 규칙을 포괄적인 규칙보다 앞에 두고, FINAL은 나머지 요청의 기본 처리에 사용합니다. 아래 예시는 규칙 순서만 보여 줍니다. example.com은 예시 도메인이며 PROXY는 실제 Config에서 유효한 정책으로 해석되어야 합니다. 이 규칙을 완성된 설정 파일로 간주해 기존 내용을 덮어쓰지 마세요. 의미를 이해하지 못한 광범위한 허용 규칙을 테스트 목적으로 추가하지도 마세요.

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

오류가 발생한 단계에 따라 다음 조치 결정

페이지에 도메인 이름 확인 오류가 표시되면 DNS 항목을 확인하세요. 오래 기다린 뒤 연결 시간 초과가 발생하면 연결 시간 초과 항목을 확인합니다. 연결 후 인증서 경고가 나타나면 시스템 시간, 대상 도메인, 서버에서 제공한 TLS 설정을 대조하세요. 오류를 숨기기 위해 인증서 검증을 끄지 마세요. 특정 앱 하나에서만 문제가 발생한다면 네트워크 권한, 로그인 상태, 앱 자체 서비스가 정상인지 확인한 뒤 브라우저에서 비슷한 대상에 접속해 비교하세요.

복구 후 Global Routing을 원래 사용하려던 모드로 되돌리고, 직접 연결해야 하는 요청 하나와 프록시를 사용해야 하는 요청 하나를 다시 확인하세요. 정상 작동한 네트워크, 서버, Config 이름을 기록합니다. Proxy에서만 임시로 사용할 수 있다면 ‘Proxy 정상, Config 오류’라는 결과를 남기고 라우팅 문제를 계속 확인하세요. 전체 요청 경로를 바꾸면 오류를 우회할 수는 있지만 해결되지는 않습니다. 규칙 적용에 관한 자세한 설명은 사용자 지정 규칙과 FINAL을 참고하세요.

연결 시간 초과: 주소, 포트, 핸드셰이크 단계 확인

시간 초과는 특정 단계가 제한 시간 안에 완료되지 않았다는 뜻이지, 서버가 반드시 오프라인이라는 의미는 아닙니다. Connectivity Test 결과는 테스트 방식, 대상, 당시 네트워크에 따라 달라집니다. 특정 탐색이 성공했다면 그 탐색 경로가 작동했다는 것만 확인할 수 있습니다. 실제 웹페이지 접속에는 DNS, 프로토콜 인증, TLS, 대상 사이트의 응답도 필요합니다. ‘서버에 전혀 연결되지 않음’과 ‘연결은 되지만 웹페이지가 열리지 않음’을 구분해 기록하세요. 하나의 수치를 모든 앱의 사용 가능 여부로 해석하지 마세요.

주소와 포트가 원본 그대로인지 먼저 확인

Add Server에서 서버 주소, 포트, 프로토콜을 확인하세요. 주소란에는 일반적으로 서버 호스트 이름이나 주소만 입력해야 합니다. 웹페이지 경로나 설명 문구를 함께 붙여 넣지 마세요. 포트는 보유한 정보와 대조하고 프로토콜 이름만 보고 추측하지 않습니다. 복사할 때 공백, 줄바꿈, 전각 문장 부호가 들어갔는지도 확인하세요. 원본 주소가 도메인이라면 해당 도메인이 확인되는지 살펴봅니다. IPv6 주소라면 현재 네트워크에서 연결할 수 있어야 합니다. 다른 웹페이지에 접속된다는 이유만으로 해당 주소에도 연결될 것이라고 단정할 수는 없습니다.

Wi-Fi에서는 같은 항목이 실패하고 모바일 네트워크에서는 정상이라면 접속 네트워크나 경로의 문제일 수 있습니다. Wi-Fi 인증, 라우터 규칙, 상위 네트워크 연결 상태를 확인하세요. 두 네트워크에서 모두 실패하지만 보유한 다른 서버 항목은 정상이라면 기존 서버와 설정값을 우선 확인합니다. 모든 항목이 갑자기 동시에 실패한다면 개별 비밀번호를 바꾸지 말고 기본 네트워크와 공통 DNS부터 점검하세요. 테스트할 때마다 네트워크와 서버 중 하나만 바꾸면 결과를 명확하게 해석할 수 있습니다.

프로토콜 설정값은 같은 자료를 기준으로 확인

서로 다른 프로토콜의 필드를 혼용하면 안 됩니다. Shadowsocks는 암호화 방식과 비밀번호를 확인하고, VMess 및 VLESS는 사용자 식별자와 전송 옵션을 확인하세요. Trojan은 비밀번호와 TLS 관련 설정을 확인합니다. 사용자 식별자나 비밀번호가 한 글자만 달라도 인증에 실패할 수 있습니다. 링크를 가져온 뒤에는 특히 이스케이프 문자나 추가 전송 매개변수가 포함된 경우 주요 필드가 올바르게 인식되었는지 확인하세요. 다른 항목의 설정값을 조합해 겉보기에 완전한 새 항목을 만들지 마세요.

TLS의 Server Name과 연결 주소는 서로 다를 수 있으며, Host와 Path도 각각 다른 역할을 할 수 있습니다. 이름이 비슷하다고 해서 모두 같은 도메인으로 설정하지 마세요. 시스템 날짜와 시간이 정확한지 확인하세요. 시간 오차로 유효한 인증서가 아직 유효하지 않거나 이미 만료된 것으로 표시될 수 있습니다. 인증서 오류가 발생하면 오류 유형을 기록하고 설정 정보를 확인하세요. 일치하지 않는 인증서를 무작정 허용하지 마세요. 프로토콜 설정이 올바른지와 인증서를 신뢰할 수 있는지는 별개의 조건이며, 둘 중 하나를 우회해도 다른 조건이 충족된다는 뜻은 아닙니다.

UDP 및 네트워크 경로 차이 확인

일부 프로토콜이나 기능은 UDP에 의존합니다. Hysteria2 연결은 현재 네트워크의 UDP 지원 상태에 영향을 받을 수 있습니다. WireGuard도 올바른 키, 주소, 엔드포인트, 라우팅 범위가 필요합니다. 다른 서버 항목으로 웹페이지가 열리더라도 UDP 경로가 정상이라는 뜻은 아닙니다. 특정 프로토콜에서만 실패한다면 모든 서버를 광범위하게 변경하기보다 해당 프로토콜의 필수 설정값과 네트워크 조건을 확인하세요. 재현 가능한 증상이 있고 다른 요인을 배제하기 전까지 MTU 같은 하위 설정을 임의로 바꾸지 마세요.

시간 초과가 계속되고 원본 설정값도 정확하다면 사용자가 이용 중인 서비스의 관리자에게 테스트 시간, 접속 네트워크, 실패 단계, 민감 정보를 제거한 오류 내용을 전달하세요. 전체 구독 링크, 비밀번호, 키는 보내지 마세요. 연결이 한때 정상 작동하다가 실패하기 시작했다면 서버 주소, 포트 또는 인증 정보가 변경되었는지도 확인합니다. 관리자에게 확인한 뒤 항목을 업데이트하고 기존 설정으로 계속 재시도하지 마세요. 마지막으로 실제 요청을 보내 복구를 확인하고 다음에도 재현할 수 있는 테스트 절차를 기록해 일시적인 혼잡과 지속적인 장애를 구분하세요.

구독 실패 또는 목록이 비어 있을 때: 가져오기와 해석을 나눠 확인

구독 업데이트는 서버에서 내용을 가져오는 단계와 그 내용을 서버 항목으로 해석하는 단계로 나뉩니다. 어느 단계에서든 업데이트 오류가 발생할 수 있으며, 업데이트가 성공했지만 목록이 비어 있다고 해서 네트워크를 사용할 수 없는 것은 아닙니다. 기존 항목은 보존하고 구독 그룹 이름, 업데이트 전후 항목 수, 오류 메시지를 기록하세요. 앱 일회성 구매는 연결 서비스 요금제가 아닙니다. 앱을 설치하거나 구매해도 서버 정보가 자동으로 생기지 않습니다. 이 사이트는 서버나 구독을 제공, 판매, 추천하지 않으며, 이 문서에서는 사용자가 보유한 정보를 확인하는 방법만 안내합니다.

복사한 내용이 구독 주소인지 확인

사용자가 이용 중인 서비스에서 구독 링크를 다시 받아 전체 주소를 복사했는지 확인하세요. 로그인 페이지, 관리 페이지, 잘려서 표시된 텍스트를 복사하지 마세요. 구독 주소에는 쿼리 매개변수가 포함될 수 있습니다. 끝부분을 삭제하거나 특수 문자를 전각 문자로 바꾸면 의미가 달라질 수 있습니다. 붙여 넣은 뒤 앞뒤 공백과 줄바꿈을 확인하되 매개변수 순서를 임의로 바꾸거나 내용을 디코딩하지 마세요. 제공된 자료가 단일 공유 링크라면 서버 항목 하나를 가져오는 방식으로 처리하고, 정기 업데이트가 필요한 구독으로 잘못 판단하지 마세요.

실제 구독 주소를 검색창, 공개 게시판, 온라인 파서에 붙여 넣지 마세요. 주소에 바로 사용할 수 있는 인증 정보가 포함되어 있을 수 있습니다. 오류 기록이 필요하다면 프로토콜 종류, 일부를 가린 도메인, 오류 유형만 남기세요. 스크린샷을 공유하기 전에는 QR 코드, 전체 URL, 사용자 이름, 서버를 알아볼 수 있는 메모를 가리세요. QR 코드와 텍스트 링크에 같은 권한이 담길 수 있으므로 하나만 가린다고 안전해지는 것은 아닙니다.

네트워크 요청으로 실제 내용이 받아들여졌는지 확인

업데이트가 시간 초과되면 현재 네트워크에서 구독 도메인을 확인할 수 있는지 먼저 살펴본 다음, 구독을 가져올 때 사용하는 경로를 확인하세요. 기존 서버를 사용할 수 없고 구독 업데이트에도 현재 프록시 경로가 필요하면 업데이트할 수 없는 상황이 반복될 수 있습니다. 기본 네트워크가 정상이고 서비스 주소에 접속할 수 있는 경우 연결을 끊은 상태에서 업데이트 결과를 비교해 보세요. 사용자가 보유한 다른 정상 항목으로 비교할 수도 있습니다. 구독은 반드시 프록시를 거쳐야 한다거나 반드시 직접 연결해야 한다고 미리 정하지 말고 주소의 실제 접근 가능 여부에 따라 판단하세요.

오류 메시지에 상태 코드가 있다면 의미를 구분하세요. 인증 오류나 접근 거부는 링크 권한을 확인해야 하는 경우가 많습니다. 요청이 너무 잦다는 메시지가 나타나면 반복해서 새로고침하지 마세요. 서버 오류는 이용 중인 서비스의 관리자가 처리해야 합니다. 성공 상태가 반환되어도 구독 데이터가 아니라 로그인 페이지, 인증 페이지, 일반 안내 페이지가 내려올 수 있습니다. 따라서 브라우저에서 페이지가 열린다는 사실만으로 구독 내용이 올바르다고 볼 수 없으며, 페이지 문구 전체를 서버 주소란에 복사해서도 안 됩니다.

목록이 비어 있으면 해석 및 표시 조건 확인

내용은 가져왔지만 항목이 없다면 먼저 Home의 검색 조건을 지우고 해당 그룹을 펼쳐 보세요. 필터나 접힘 상태 때문에 목록이 비어 보이는 것은 아닌지 확인합니다. 그런 다음 형식이 지원되지 않음, 필수 필드 누락, 내용을 인식할 수 없음 등의 오류가 있는지 확인하세요. 구독 형식마다 포함된 필드가 다르므로 링크의 확장자만 바꿔 형식을 변환할 수는 없습니다. 형식을 바꿔야 한다면 사용 중인 서비스에서 제공하는 호환 형식 안내를 이용하고 비공개 링크를 모르는 도구에 제공하지 마세요.

업데이트 후 일부 항목만 사라졌다면 누락된 항목의 프로토콜과 설정을 비교해 서비스 측에서 제거했는지, 이름을 바꾸었는지, 해당 항목만 해석에 실패했는지 확인하세요. 표시 이름은 중복되거나 바뀔 수 있으므로 이름만으로 같은 서버인지 판단하지 마세요. 구독 업데이트로 수동 수정한 값이 덮어써진다면 구독 항목을 계속 수정하지 말고 진단을 위해 관리 가능한 로컬 복사본을 보존하세요. 이 복사본은 이후 변경 사항을 자동으로 이어받지 않습니다. 구체적인 저장 방법은 현재 인터페이스에서 제공하는 기능을 따르세요.

복구 후 원래 문제가 해결되었는지 확인

구독 항목이 다시 나타났다는 것은 가져오기와 해석이 완료되었다는 뜻일 뿐입니다. 항목 하나를 선택해 실제로 연결되는지 확인하세요. 먼저 그룹 항목이 있는지 확인하고 주요 설정값을 점검한 다음 테스트 대상에 접속합니다. Config와 모든 구독을 동시에 업데이트하지 마세요. 어떤 단계에서 복구되었는지 판단하기 어렵습니다. 새 링크는 업데이트되지만 이전 링크는 실패한다면 복구를 확인한 후 이전 주소를 비활성화하고 기존 서비스 관리자에게 이전 인증 정보가 폐기되었는지 확인하세요. 자세한 실패 유형은 구독 업데이트 실패 및 빈 목록 점검을 참고하세요. 링크 종류는 공유 링크와 구독 링크의 차이에서 확인할 수 있습니다.

속도 저하 및 간헐적 연결 끊김: 비교 가능한 테스트 조건 만들기

지연 시간이 짧다고 처리량이 높은 것은 아니며, 처리량이 정상이어도 상호작용 요청에 빠르게 응답한다는 뜻은 아닙니다. 웹페이지를 열 때는 DNS 확인, 연결 설정, 첫 바이트 응답 대기가 필요합니다. 대용량 파일 다운로드는 지속 대역폭, 패킷 손실, 서버 부하에 더 큰 영향을 받습니다. 무엇이 느린지 먼저 구체적으로 확인하세요. 시작할 때 오래 기다리는지, 전송 내내 느린지, 재생 중 멈추는지, 화면을 잠근 뒤에만 연결이 끊기는지 구분합니다. 증상을 구체화한 다음 테스트해야 서로 다른 문제를 모두 ‘속도 저하’로 묶어 프로토콜, DNS, 규칙을 동시에 바꾸지 않게 됩니다.

대상, 네트워크, 시간을 동일하게 유지

적법하게 제공되는 적당한 크기의 테스트 파일을 선택하고 같은 네트워크, 같은 기기, 비슷한 시간대에 비교하세요. 먼저 시스템 업데이트, 클라우드 동기화, 기타 대용량 작업을 일시 중지하고 기기가 과열되지 않았는지 확인합니다. 매번 사용자가 보유한 항목 하나만 변경하거나 Global Routing을 한 번만 전환하고 나머지 조건은 유지하세요. 속도 테스트는 데이터를 사용하므로 모바일 네트워크에서는 횟수를 제한하세요. 대용량 테스트를 계속 실행하면 혼잡과 발열이 생겨 이후 결과가 더 나빠질 수 있습니다.

Direct 모드에서도 일반 페이지가 느리다면 Wi-Fi 신호, 라우터 부하, 상위 네트워크 상태부터 살펴보세요. 라우터 가까이에서 개선된다면 로컬 무선 환경을 우선 점검해야 합니다. 다른 네트워크로 바꿨을 때 개선된다면 기존 네트워크 경로를 확인하세요. 같은 서버가 여러 네트워크에서 모두 느리지만 사용자가 보유한 다른 항목은 정상이라면 해당 서버나 출구 경로의 제한일 수 있습니다. 로컬 규칙을 변경하면 경로 선택은 바뀌지만 원격에서 실제로 사용할 수 있는 대역폭이 늘어나지는 않습니다.

첫 요청 지연과 지속적인 전송 속도 저하 구분

첫 접속은 느리지만 다시 접속할 때 확연히 빨라진다면 DNS 캐시, 연결 재사용, 대상 콘텐츠 캐시가 영향을 미쳤을 수 있습니다. 이 현상만으로 서버가 불안정하다고 판단하지 마세요. 요청 기록에서 도메인, 적용된 정책, 오류 단계를 확인합니다. 요청이 예상보다 우회하는 경로로 전송되었다면 규칙을 수정한 뒤 다시 테스트하세요. 예상한 정책이 적용되었다면 DNS 확인 시간, 연결 단계, 대상 응답을 계속 비교합니다. 기록만으로 충분히 알 수 없다면 걸린 시간을 추측하지 말고 ‘판단하기에 정보가 부족함’으로 남기세요.

다운로드 중 주기적으로 멈춘다면 패킷 손실, 네트워크 전환, 무선 간섭, 서버 속도 제한, 앱 자체의 버퍼링 방식이 원인일 수 있습니다. 기기를 움직이지 않고 네트워크도 바꾸지 않은 상태에서 재현한 뒤 다른 기존 항목과 비교하세요. 특정 대상만 느리다면 대상 사이트나 콘텐츠 전달 경로 문제일 수도 있습니다. 동영상 하나나 다운로드 사이트 하나로 전체 접속 성능을 판단하지 마세요. 특정 테스트 수치를 높이려고 장기 사용 설정을 자주 바꾸지도 마세요.

연결이 끊길 때 상태와 발생 시점 기록

연결이 끊겼을 때 먼저 시스템 VPN 상태가 바뀌었는지, 이어서 Shadowrocket이 계속 연결 상태를 표시하는지 확인하세요. 상태는 유지되지만 새 요청이 실패하는 경우와 시스템 터널 자체가 끊긴 경우는 점검 경로가 다릅니다. 전자는 서버, DNS, 기존 연결을 확인하고 후자는 네트워크 전환, On Demand, 시스템 제한, 앱 오류를 확인하세요. 화면 잠금, Wi-Fi에서 모바일 네트워크로 전환, 핫스팟 활성화, 저전력 모드 진입 직후에 연결이 끊기는지 기록하세요. 발생 시점의 연관성이 한 번의 속도 테스트보다 더 유용할 수 있습니다.

네트워크를 전환한 뒤 일부 연결은 자동으로 복구되지 않아 앱에서 다시 연결해야 할 수 있습니다. 먼저 작은 요청을 새로 보내 연결이 복구되는지 확인한 다음 연결을 끊었다가 다시 연결할지 결정하세요. 기존 다운로드 작업만 멈추고 새 페이지는 열리는 경우에는 전체 터널 문제가 아니라 기존 세션이 만료되었을 수 있습니다. 강제로 다시 연결하면 정상적인 다른 세션도 끊길 수 있으므로 영향 범위를 먼저 확인하세요.

Data를 참고하되 통계를 진단 결론으로 단정하지 않기

Data의 트래픽 수치는 백그라운드에서 대량 데이터가 오가는지 확인하는 데 도움이 될 수 있지만, 통계 기준, 기간, 초기화 시점에 따라 해석이 달라집니다. 서버의 누적 트래픽이 많다고 현재 속도가 빠른 것은 아닙니다. 앱의 트래픽이 적다고 연결 실패가 없다는 뜻도 아닙니다. 먼저 통계 기준을 확인하고 실제 테스트 시간대와 대조하세요. 서버별·앱별 통계 확인 방법은 Data 페이지의 트래픽 통계 안내를 참고하세요. 통계를 초기화해야 한다면 비교에 필요한 기존 수치를 먼저 저장하세요.

DNS 및 규칙 적용 문제: 도메인, 주소, 정책 구분

DNS는 도메인을 주소로 변환하고 규칙은 요청에 적용할 경로를 결정합니다. 서로 관련은 있지만 대체할 수는 없습니다. 도메인에 접속할 수 없는 것은 DNS 확인 실패일 수도 있고, DNS는 정상이나 대상 서버 연결이 실패한 것일 수도 있습니다. 특정 주소에 연결된다고 도메인 경로도 정상이라는 뜻은 아닙니다. HTTPS는 올바른 도메인과 인증서가 필요한 경우가 많습니다. 웹사이트 도메인을 주소로 직접 바꿔 전체 문제를 판단하지 마세요. DNS 오류가 보인다고 낯선 DNS 주소를 여러 개 동시에 추가해서도 안 됩니다.

먼저 실패한 계층 확인

대상을 다시 열고 요청 기록을 확인하세요. 도메인이 표시되는지, 주소를 가져왔는지, 어떤 정책이 최종 적용되었는지, 오류가 DNS 확인 전이나 연결 후에 발생했는지 살펴봅니다. 서로 관련 없는 여러 도메인이 모두 확인되지 않는다면 현재 DNS 설정과 DNS 서버까지의 연결 경로를 점검하세요. 도메인 하나만 실패한다면 해당 도메인 자체, 캐시, 관련 규칙을 확인합니다. 평소 정상 접속되는 일반 도메인을 테스트에 포함해 기준으로 삼으세요. 원래 접속 조건이 다른 대상만 검사하지 마세요.

암호화 DNS도 해당 서버에 연결할 수 있어야 하며, 경우에 따라 DNS 서버의 도메인을 먼저 확인해야 할 수도 있습니다. DNS 요청 경로가 사용할 수 없는 프록시에 의존하면 모든 도메인이 한꺼번에 확인되지 않는 것처럼 보일 수 있습니다. 확인할 때는 ‘어떤 DNS 서버를 사용하는지’와 ‘DNS 서버까지 어떤 경로로 연결되는지’를 나누어 기록하세요. 프로토콜 이름만으로 반드시 작동한다고 단정하지 마세요. 임시 문제 해결을 위해 시스템이나 Config의 필수 보호 기능을 계속 꺼 두지도 마세요.

규칙 순서와 정책 참조 확인

규칙은 위에서 아래 순서로 적용되며 일반적으로 먼저 일치한 규칙이 실행됩니다. DOMAIN은 전체 도메인, DOMAIN-SUFFIX는 도메인 접미사, IP-CIDR은 IP 주소 범위를 대상으로 합니다. FINAL은 앞선 규칙과 일치하지 않은 요청을 처리합니다. 도메인 규칙과 주소 규칙은 서로 다른 기준으로 판단됩니다. 주소를 기준으로 판단할 때는 주소를 이미 확인했는지, Config 옵션이 확인된 주소를 어떻게 처리하는지도 살펴봐야 합니다. 문제를 찾을 때는 구체적인 도메인을 사용해 작은 범위에서 테스트하고 포괄적인 키워드 규칙을 바로 추가하지 마세요.

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

이 예시는 구체적인 규칙을 포괄적인 규칙보다 앞에 배치하는 방법을 보여 줍니다. intranet.example.com은 첫 번째 규칙에 먼저 적용되며 뒤의 동일 접미사 규칙에는 도달하지 않습니다. GEOIP는 IP 주소의 지리적 위치 데이터를 사용합니다. 웹사이트의 언어, 운영 지역, 콘텐츠 종류를 판별하는 기능은 아니며 데이터와 실제 출구 위치가 다를 수도 있습니다. PROXY, DIRECT, REJECT는 정책을 나타냅니다. 실제 Config의 프록시 정책은 사용 가능한 서버를 올바르게 참조해야 합니다. 규칙이 올바르더라도 정책이 작동하지 않는 항목을 가리키면 접속은 실패합니다.

IPv4, IPv6, 로컬 네트워크 도메인을 각각 확인

일부 도메인은 IPv4와 IPv6 주소를 모두 반환하지만 현재 네트워크나 서버는 한쪽 주소 체계에서만 정상 작동할 수 있습니다. 접속 네트워크에 따라 증상이 달라진다면 주소 체계 차이를 확인하고 곧바로 ‘DNS가 잘못된 주소를 반환한다’고 결론 내리지 마세요. 로컬 네트워크 장치는 라우터의 로컬 DNS 확인이나 특정 검색 도메인을 사용하는 경우도 있습니다. 외부 DNS로 바꾼 뒤 일반 사이트는 정상인데 프린터, 파일 서비스, 내부 도메인만 실패할 수 있습니다. 이는 DNS 확인 범위가 달라진 문제이므로 모든 요청을 프록시로 보내 해결하려 하지 마세요.

DNS나 규칙을 변경한 뒤에는 연결과 요청을 새로 시작해야 합니다. 이전 연결이나 캐시가 결과에 계속 영향을 줄 수 있습니다. 관련 상태가 갱신될 때까지 기다린 다음 같은 대상을 테스트하고, 필요하면 테스트 앱을 재시작하세요. 캐시 삭제는 이전 상태의 영향을 확인하는 방법일 뿐 장기적인 해결책은 아닙니다. 정상화되면 변경 전후 차이를 저장하고 테스트용 임시 규칙을 삭제한 뒤 로컬 네트워크 접속에 영향이 없는지 확인하세요. 원인을 찾기 어렵다면 단순히 ‘도메인이 열리지 않음’이라고 하는 것보다 민감 정보를 가린 적용 규칙, 주소 체계, 오류 단계 정보를 제공하는 편이 진단에 도움이 됩니다.

배터리 소모 및 업데이트 후 문제: 안정적인 기준 상태부터 복원

배터리 소모가 갑자기 늘었다면 네트워크 활동과 관찰 시간을 함께 고려해야 합니다. 시스템에서 터널을 통한 네트워크 활동이 관련 앱의 사용량으로 집계될 수 있으므로 앱이 목록 상단에 있다는 것만으로 문제가 있다고 볼 수는 없습니다. 비슷한 사용량에서 배터리 변화, 화면 켜짐 시간, 모바일 신호, 기기 온도, 데이터 사용량을 비교한 뒤 연결이 계속 재시도되는지 확인하세요. 업데이트 후 문제가 생겼더라도 설정이 바뀌었는지 먼저 확인해야 합니다. 시간상 업데이트 뒤에 문제가 나타났다는 이유만으로 업데이트를 원인으로 단정하지 마세요. 기존 설정을 보존하면 네트워크 환경과 기기 내부 상태 중 무엇이 바뀌었는지 판단하기 쉽습니다.

배터리 순위만 보지 말고 지속적인 활동 확인

다운로드, 클라우드 백업, 미디어 업로드, 연속 속도 테스트를 일시 중지하고 기기 온도가 내려갈 때까지 기다린 뒤 평소처럼 사용하며 관찰하세요. 모바일 신호가 약하거나 핫스팟을 공유하거나 네트워크를 자주 전환하면 시스템 작업량이 늘어납니다. 앱의 동작과 구분해서 고려하세요. 대용량 작업을 중지한 뒤 증상이 확연히 나아진다면 트래픽을 발생시키는 앱을 계속 확인합니다. 아무것도 하지 않을 때도 기기가 계속 뜨거워진다면 연결 반복 실패, 구독 반복 업데이트, 요청 반복이 있는지 살펴보세요. 명확한 근거 없이 정리를 위해 모든 서버를 삭제하지 마세요.

On Demand 조건이 현재 네트워크 변화와 맞지 않으면 연결을 반복해서 시도할 수 있습니다. 기존 조건을 기록하고 자동 연결을 잠시 끈 다음 수동 연결 상태로 관찰하세요. 나아졌다면 조건을 하나씩 다시 적용해 문제와 관련된 설정을 찾습니다. 연결을 영구히 끄는 것은 해결책이 아닙니다. 모든 시스템 네트워크 기능을 동시에 끄지도 마세요. 상시 연결이 필요한 환경에서는 안정된 조건에서 화면 잠금, 깨우기, 네트워크 전환을 다시 확인하세요. 앱을 앞에 둔 짧은 테스트만으로 점검을 끝내지 마세요.

진단 과정에서 발생하는 추가 부하 줄이기

상세 로그를 오래 기록하거나 많은 서버를 자주 탐색하거나 구독을 반복해서 새로고침하면 추가 활동이 발생할 수 있습니다. 문제가 재현되는 시간에 필요한 진단만 유지하고 원인을 찾은 뒤에는 평소 설정으로 되돌리세요. 로그에는 방문한 도메인과 연결 정보가 포함될 수 있으므로 내보내기 전에 검토하고 민감 정보를 가리세요. 기록은 ‘테스트 시작, 증상 발생, 테스트 종료’까지 짧은 시간만 포함하도록 합니다. 너무 긴 기록은 처리 부담을 늘리고 중요한 오류 정보를 묻히게 할 수 있습니다.

기기 저장 공간이 부족하면 시스템 및 앱 업데이트, 캐시 기록, 설정 저장에도 영향을 줄 수 있습니다. 먼저 시스템 저장 공간 관리에서 삭제해도 된다고 확인된 내용을 정리한 뒤 앱을 다시 실행하세요. 용도를 모르는 내부 파일을 직접 삭제하지 마세요. 배터리 테스트는 충전하면서 온도를 비교하지 않는 것이 좋습니다. 충전 자체가 기기의 열 상태를 바꿀 수 있습니다. 테스트마다 화면 밝기, 네트워크, 앱 사용량을 비슷하게 맞춰야 조정 효과가 지속되는지 일시적인 변동인지 판단할 수 있습니다.

업데이트 전후 앱과 설정을 나눠 비교

앱 업데이트, 구독 업데이트, Config 업데이트는 서로 다른 작업입니다. 문제가 생기기 전에 실제로 어떤 변경이 있었는지 확인하세요. 앱만 바뀌었는지, 서버 설정과 규칙도 함께 바뀌었는지 살펴봅니다. 현재 선택한 서버와 활성화된 Config를 확인하고 Global Routing이 의도한 대로 설정되어 있는지 점검하세요. Proxy는 정상이고 Config만 문제가 있다면 설정 차이를 우선 비교합니다. 모든 모드에서 실패한다면 기본 네트워크와 서버 설정을 다시 확인하세요. 업데이트 문제를 확인하려고 반복해서 앱을 삭제하지 마세요. 아직 백업하지 않은 자료도 함께 사라질 수 있습니다.

iPhone / iPad 앱은 App Store에서 업데이트합니다. Mac, Windows, Android, Linux용 최신 설치 파일은 앱 다운로드 페이지에서 받으세요. 재설치 중 시스템에서 실행을 차단하면 먼저 이 사이트에서 받은 파일인지 확인한 뒤 다운로드 페이지의 설치 차단 해제 절차를 따르세요. 설치 전에 현재 Config, 수동으로 추가한 서버, 필요한 메모를 저장하세요. 백업 파일에는 민감 정보가 포함될 수 있으므로 직접 관리할 수 있는 위치에 보관하고 공개 공간에 업로드하지 마세요.

복원 순서 및 재현 기록

테스트 환경을 다시 만들어야 한다면 시스템 권한을 먼저 승인하고, 사용자가 보유한 정보가 확실한 서버 항목 하나만 가져와 실제 접속을 확인한 뒤 원래 Config를 추가하고 마지막으로 구독과 On Demand를 복원하세요. 각 단계마다 같은 대상을 확인하고 언제부터 실패하는지 기록합니다. 이렇게 하면 앱의 기본 연결, 서버 정보, 복잡한 설정을 구분할 수 있습니다. 전체 백업을 가져오자마자 문제가 재현되고 단일 항목은 정상이라면 백업 안의 설정을 확인하세요. 재설치를 반복하지 마세요.

업데이트 후 문제를 알릴 때는 기기 모델, 시스템 환경, 네트워크 종류, 실패 단계, 민감 정보를 가린 오류 내용을 작성하세요. 앱 정보는 현재 인터페이스에서 확인하고 기억에 의존해 적지 마세요. ‘문제를 안정적으로 재현할 수 있는지’와 ‘최소 설정에서도 나타나는지’를 함께 알려 주는 것이 특히 중요합니다. 복구 후 검증된 설정을 보관하고 다음 변경 전에 복사본을 만드세요. 일상적인 관리를 위해 자주 초기화할 필요는 없습니다. 변경 내용을 기록하고 되돌릴 수 있게 하며 원래 사용 환경이 여전히 정상인지 확인하는 것이 중요합니다.

iPad 점검: 설정 동기화가 환경까지 같게 만들지는 않습니다

같은 자료가 iPhone에서는 정상이고 iPad에서는 실패한다면 태블릿에 다른 프로토콜이 필요하다고 단정하지 말고 두 기기의 네트워크와 시스템 권한을 비교하세요. 같은 이름의 Wi-Fi에 연결되어도 게스트 네트워크, 주소 체계, 관리 정책이 다를 수 있습니다. 가능한 한 두 기기의 접속 조건을 맞추고 각각 연결을 끈 상태에서 기본 네트워크를 확인한 다음 사용자가 보유한 같은 서버 항목으로 잠시 테스트하세요. 비교할 때 Global Routing도 동일하게 설정해 Config 차이를 기기 차이로 오인하지 않도록 합니다.

iPad에서 최초 권한을 직접 승인했는지 확인

다른 기기에서 VPN 권한을 승인했더라도 iPad의 시스템 확인을 대신할 수 없습니다. 처음 연결할 때 iPad에서 VPN 구성을 추가하도록 허용하고 시스템 인증을 완료해야 합니다. 팝업이 나타나지 않으면 시스템에 해당 구성이 이미 있는지, 기기 관리 제한이 있는지 확인하세요. 학교나 회사에서 지급한 기기에는 별도의 네트워크 정책이 적용될 수 있으며 구독을 반복해서 가져와도 우회할 수 없습니다. 관리 제한이 불분명하다면 먼저 관리자에게 사용 가능한 조건을 확인하세요.

화면이 크고 창을 나란히 배치할 수 있어도 연결의 시스템 수준 동작은 달라지지 않습니다. 앱을 백그라운드로 보내거나 현재 창에서 다른 곳으로 이동한다고 VPN 연결이 끊기는 것은 아닙니다. 반대로 Home이 화면에 보인다고 시스템 터널이 계속 유효하다는 뜻도 아닙니다. 확인할 때는 시스템 VPN 상태와 앱의 연결 상태를 함께 살펴본 다음 요청을 새로 보내세요. 창을 바꾼 뒤 기존 페이지만 멈춘다면 새 요청을 시도해 기존 세션 문제인지 전체 연결 중단인지 구분합니다.

서버 및 Config를 항목별로 비교

같은 구독을 가져와도 두 기기에서 서로 다른 항목이 선택되었거나 한쪽이 아직 업데이트되지 않았을 수 있습니다. 서버 이름뿐 아니라 프로토콜, 주소, 포트, 주요 전송 설정을 비교하고 인증 정보는 기기에서만 확인하세요. 이어서 활성화된 Config, Global Routing, 정책 그룹 선택을 비교합니다. 파일 이름이 같아도 내용까지 같다는 보장은 없습니다. 수동 편집이나 이후 업데이트로 차이가 생길 수 있습니다. 목록의 겉모습만 같다고 실제 요청 경로도 같다고 볼 수는 없습니다.

Scan QR Code로 가져온 경우 서버 정보와 구독 링크 중 무엇을 스캔했는지 확인하세요. 두 종류는 이후 업데이트 방식이 다릅니다. 공유 기능으로 정보를 전달했다면 내용이 완전하게 전송되었는지도 확인하세요. 가져오기가 끝나면 Add Server에서 필수 항목을 점검한 다음 실제 접속을 테스트하세요. 목록에 항목 하나가 생겼다는 이유만으로 설정 전체가 올바르다고 판단하지 마세요. QR 코드를 공유할 때 주변 환경도 주의해야 합니다. 코드에 텍스트 인증 정보와 같은 민감 정보가 포함될 수 있습니다.

로컬 네트워크 및 네트워크 전환 상황 확인

iPad는 프린터, 파일 서비스, 기타 로컬 네트워크 기기와 함께 사용하는 경우가 많습니다. 일반 웹페이지는 열리지만 로컬 네트워크 리소스에 접속할 수 없다면 대상 주소 범위가 DIRECT로 처리되는지, 로컬 도메인이 원래 방식으로 확인되는지 살펴보세요. 로컬 네트워크 대역이 항상 192.168.0.0/16인 것은 아니므로 실제 네트워크를 기준으로 확인하고 예시 규칙을 그대로 복사하지 마세요. 앱이 로컬 네트워크 권한을 요청하면 실제 사용 목적에 따라 허용 여부를 결정하세요. VPN이 정상 연결되어 있어도 앱에 필요한 시스템 권한을 대신하지는 않습니다.

모바일 네트워크를 지원하는 iPad는 Wi-Fi에서 모바일 데이터로 전환한 뒤 기존 연결을 다시 설정해야 할 수 있습니다. Wi-Fi 전용 기기는 잠자기에서 깨어난 뒤 네트워크에 다시 연결되는 과정이 필요할 수 있습니다. 전환이나 깨우기 직후에 문제가 반복되는지 관찰하고 네트워크가 안정된 뒤 새 요청을 보내세요. 다시 연결하면 복구된다면 On Demand 조건과 경로 변경에 대한 서버 동작을 확인하세요. 네트워크 전환과 구독 업데이트를 동시에 하지 마세요. 두 작업이 겹치면 실제 원인을 판단하기 어렵습니다.

구매 항목 복원 및 문제 전달 체크리스트

기기를 바꾸거나 앱을 다시 설치할 때는 먼저 App Store에 원래 구매 계정으로 로그인했는지 확인한 다음 구입 항목에서 앱을 찾으세요. App Store 구매 복원과 앱 내부의 서버 정보 복원은 별개입니다. 전자는 앱을 다시 받기 위한 절차이고, 후자는 사용자가 직접 저장한 설정이나 구독이 필요합니다. iPhone / iPad 버전은 App Store에서 미화 $2.99 일회성 구매이며 두 기기에서 사용할 수 있습니다. Mac, Windows, Android, Linux 버전은 무료입니다. App Store에 표시되는 정보와 시스템 요구 사항은 App Store 페이지 표기를 기준으로 확인하세요. 복원 방법은 구입 항목 안내를 참고하세요.

iPad 문제를 전달할 때는 기본 네트워크가 정상인지, VPN 권한을 승인했는지, 같은 항목을 다른 기기에서 사용할 수 있는지, 세 가지 모드에서 어떤 차이가 있었는지, 화면 잠금이나 네트워크 전환 후에만 문제가 발생하는지를 순서대로 적으세요. 민감 정보를 가린 적용 규칙과 오류 유형을 첨부하되 전체 구독 링크나 QR 코드는 포함하지 마세요. 이 정보가 있으면 처음부터 추측하지 않고 확인된 범위부터 이어서 점검할 수 있습니다. 아직 최초 가져오기를 완료하지 않았다면 빠른 시작 안내로 돌아가세요. 연결은 되지만 일부 요청이 실패한다면 이 페이지의 연결 및 라우팅 점검으로 돌아와 계속 확인하세요.