Shadowrocket
문제 해결 가이드

01 연결 스위치가 켜지지 않을 때: 시스템 권한 확인

Home에서 연결 스위치를 켜자마자 꺼지거나, VPN 구성 추가를 반복해서 요청하거나, 연결 중으로 표시되지만 안정된 상태로 넘어가지 않는 경우에 해당합니다. 이때 규칙부터 바꾸거나 문제를 곧바로 서버 오류로 단정하지 마세요. 스위치가 켜진 상태를 유지하려면 시스템에서 네트워크 확장을 허용하는지, 현재 구성이 유효한지, 다른 연결 작업이 같은 시스템 통로를 사용 중인지 먼저 확인해야 합니다.

스위치가 꺼지기 전 상황 기록

먼저 기기 모델, 현재 네트워크, 선택한 서버와 Global Routing 상태를 기록한 다음 한 번 연결해 보세요. 시스템 팝업이 나타나는지, 기기 인증이 완료되는지, 스위치가 얼마 만에 꺼지는지, 화면에 구체적인 오류가 표시되는지 확인합니다. 빠르게 여러 번 전환하기보다 한 번의 연결 과정을 끝까지 살펴보는 편이 유용합니다. 연속해서 누르면 이전 연결이 종료되기 전에 새 연결이 시작되어 실제 실패 단계가 대기 상태에 가려질 수 있습니다.

연결을 끊고 브라우저에서 평소 바로 접속할 수 있는 페이지를 열어 Wi-Fi 또는 셀룰러 네트워크가 정상인지 확인하세요. 현재 Wi-Fi에서 웹 인증이 필요하다면 먼저 인증을 완료한 뒤 테스트합니다. Wi-Fi 신호가 잡힌다고 해서 인터넷 사용 권한까지 확보된 것은 아닙니다. 네트워크 인증이 끝나지 않으면 구독, 서버 핸드셰이크, 일반 웹페이지가 모두 실패해 앱의 연결 스위치 문제로 오해할 수 있습니다.

VPN 구성 권한과 시스템 상태 확인

처음 연결할 때 VPN 구성 추가를 요청하는 것은 네트워크 구성 변경을 승인받는 시스템 절차입니다. 요청한 앱이 Shadowrocket인지 확인한 뒤 시스템 안내에 따라 승인하세요. 그런 다음 시스템 설정에서 VPN을 검색해 해당 구성을 찾아 상태를 확인합니다. 시스템 버전에 따라 메뉴 위치가 다를 수 있으므로 현재 기기 화면을 기준으로 확인하세요. 상단 상태 아이콘만으로 판단하지 마세요. 기기나 화면 표시 상황에 따라 상태 표시가 항상 같지는 않습니다.

이전에 권한 요청을 거부했다면 앱에서 다시 연결을 시작해 시스템이 재승인을 요청하는지 확인하세요. 해당 구성을 직접 삭제했다면 이름이 비슷한 시스템 구성을 임의로 만들지 말고 앱에서 다시 설정해야 합니다. 구성이 남아 있는데 오류가 반복된다면 앱 안의 서버 정보와 Config를 먼저 보존하세요. 그다음 Shadowrocket에 해당하는 시스템 VPN 구성만 제거하고 다시 승인하는 방법을 고려할 수 있습니다. 소속을 확인할 수 없는 관리 구성은 삭제하지 마세요.

관리 기기라면 권한 범위부터 확인

학교나 직장에서 관리하는 기기는 VPN 구성 변경을 제한할 수 있습니다. 시스템에 관리 제한이 명확히 표시되면 기기 관리자에게 정책을 확인하세요. 제한을 우회하려고 구성을 반복해서 다시 만들지 마세요.

연결 충돌을 확인하고 최소 조건으로 테스트

시스템에 활성화된 VPN 구성이 더 있는지, 네트워크 확장에서 제공하는 필터 기능이 있는지 확인하세요. 직접 관리하고 있으며 일시 중지해도 되는 기능만 먼저 끈 뒤 Shadowrocket을 테스트합니다. 이 단계는 연결을 가로채는 기능과의 충돌 여부를 확인하기 위한 것으로, 해당 기능이 반드시 호환되지 않는다는 뜻은 아닙니다. 일시 중지 후 정상화된다면 기능을 하나씩 다시 켜며 조합을 확인하세요. 보호 설정을 모두 계속 끄지는 마세요.

이어서 Home에서 유효한 서버를 실제로 선택했는지 확인하세요. 목록에 항목이 있다는 것만으로는 충분하지 않습니다. 서비스 제공자가 현재 안내한 정보를 기준으로 본인이 사용할 권한이 있고 설정이 완전한 서버 하나를 선택한 다음, On Demand를 잠시 끄고 수동으로 연결합니다. 스위치는 켜진 채 유지되지만 페이지가 열리지 않는다면 문제는 데이터 전송 단계에 있습니다. 시스템 구성을 계속 삭제하지 말고 다음 장을 확인하세요.

앱이 응답하지 않으면 정상적으로 종료한 뒤 다시 열어 같은 절차로 테스트하세요. 그래도 연결되지 않으면 기기를 재시동합니다. 재시동은 일시적인 시스템 상태를 정리하는 데 도움이 되지만, 잘못된 암호나 만료된 구독, 서버 측 오류를 해결하지는 않습니다. 앱을 다시 연 뒤 선택 항목이 바뀌지 않았는지 확인하고, 연결이 완전히 끝난 후 다음 작업을 시작하세요. 백그라운드 작업이 끝나기 전에 새 오류가 발생한 것으로 오해하지 않도록 주의합니다.

해결 여부 확인

연결 스위치가 켜진 상태를 유지하고, 시스템에 해당 VPN이 연결된 것으로 표시되며, 테스트 요청까지 완료되어야 이 절차가 통과된 것입니다. 계속 꺼진다면 전체 오류 문구와 발생 단계를 기록한 뒤 VPN 구성 추가 안내를 확인하세요. 문의할 때는 필요한 기기 정보와 오류만 제공하고, 암호, 전체 구독 주소, QR 코드, 계정 정보가 포함된 구성은 보내지 마세요.

02 연결됐지만 인터넷이 안 될 때: 라우팅과 출구 구분

연결 스위치가 켜져 있다는 것은 시스템 터널이 만들어졌다는 뜻일 뿐, 모든 요청에 사용할 수 있는 출구가 있다는 의미는 아닙니다. 문제를 세 단계로 나눠 확인하세요. 기기의 기본 네트워크가 접속 가능한지, 선택한 서버가 트래픽을 전달하는지, 현재 Config가 요청을 의도한 정책으로 보내는지 살펴봅니다. 먼저 현재 구성 사본과 선택 항목을 보존한 뒤 정해 둔 테스트 페이지로 비교하세요. 서버 변경, DNS 수정, 규칙 재작성 등을 한꺼번에 하면 문제가 해결돼도 원인을 알기 어렵습니다.

Global Routing으로 짧게 비교 테스트

Global Routing의 Config, Proxy, Direct는 각각 구성, 프록시, 직접 연결을 의미합니다. 문제를 구분하는 데 쓸 수 있지만 임의로 누르는 ‘수리 버튼’ 세 가지는 아닙니다. 테스트 목적을 먼저 정하세요. Direct는 기본 네트워크 경로, Proxy는 선택한 프록시 경로, Config는 규칙에 따른 실제 선택을 확인하는 데 씁니다. 같은 요청을 대상으로 짧게 비교한 뒤 원래 사용하던 Config로 되돌리세요.

Direct에서도 평소 접속하던 페이지가 열리지 않으면 먼저 연결을 끊고 Wi-Fi 인증, 셀룰러 데이터 권한과 현재 네트워크 상태를 확인하세요. Direct는 정상이지만 Proxy가 실패한다면 서버 설정과 연결 가능 여부를 먼저 확인합니다. Proxy는 정상이지만 Config가 실패한다면 일치한 규칙, 정책 이름, 구성의 DNS 설정을 살펴보세요. 이 판단은 이번 테스트 대상에만 해당하며, 웹사이트 하나의 결과를 모든 앱에 일반화할 수 없습니다.

규칙은 위에서부터 일치 여부를 확인하며 ‘더 구체적으로 보이는 순서’로 적용되지 않습니다

규칙은 보통 위에서 아래로 확인합니다. 앞쪽 규칙이 일치하면 뒤쪽 규칙이 같은 요청의 정책을 다시 결정하지 않습니다. 앞에 있는 넓은 조건의 DOMAIN-KEYWORD가 뒤의 정확한 도메인 규칙보다 먼저 적용될 수 있습니다. FINAL은 앞의 규칙이 하나도 일치하지 않을 때를 위한 기본 처리로 사용해야 합니다. 연결 기록에서 대상과 정책을 확인한 뒤 Config에서 실제 순서를 살펴보세요. 특정 규칙이 있는지만 검색해서는 충분하지 않습니다.

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

위 내용은 규칙 문법과 순서를 설명하기 위한 예시이며, 현재 설정을 통째로 덮어쓸 수 있는 완성된 구성은 아닙니다. PROXY는 현재 구성과 선택한 서버의 사용 방식에 맞게 연결되어 있어야 합니다. 사용자 지정 정책 이름도 실제로 존재해야 합니다. example.com은 설명용 도메인이며 특정 서비스에 어떤 정책을 써야 하는지 의미하지 않습니다. 예시를 복사하기 전에 어떤 요청이 바뀌는지 확인하세요. 특히 익숙하지 않은 구성 전체를 현재 사용 중인 Config에 덮어쓰지 마세요.

규칙 하나만 바꾸고 새 연결 하나로 확인

특정 도메인만 실패한다면 로그인, 정적 리소스, 미디어 하위 도메인에도 요청이 필요한지 먼저 확인하세요. 메인 도메인의 경로가 올바르더라도 모든 리소스가 같은 정책을 사용하는 것은 아닙니다. 연결 기록에서 실패 대상을 찾아 확인된 도메인만 최소한으로 조정하세요. 변경 후 새 요청을 시작합니다. 이미 만들어진 장기 연결은 이전 경로를 계속 사용할 수 있으므로 기존 연결 상태로 새 규칙의 적용 여부를 판단하지 마세요.

로컬 네트워크 기기에 접속하는 경우 기기 주소와 현재 Wi-Fi가 서로 통신할 수 있는 범위인지도 확인하세요. 구성에 사설 주소를 위한 DIRECT 규칙이 있어도 게스트 네트워크에서 다른 기기에 접속할 수 있다는 뜻은 아니며, 셀룰러 네트워크에서 집 안의 주소에 도달할 수 있다는 뜻도 아닙니다. 규칙을 확인하기 전에 기본 로컬 네트워크 연결을 테스트하세요. 모든 트래픽을 Proxy로 바꿔도 로컬 네트워크 격리 문제가 해결되지는 않으며 오히려 원인을 찾기 어려워질 수 있습니다.

되돌릴 조건을 명확히 기록

문제 규칙을 찾으면 변경 전후의 순서와 규칙이 일치한 기록을 보존하세요. Config를 원래대로 복구한 뒤 웹페이지, 로그인, 필요한 로컬 네트워크 접속을 다시 테스트합니다. 한 페이지를 고치느라 다른 서비스의 경로가 달라지지 않았는지도 확인하세요.

규칙을 조정해도 실패하지만 같은 대상이 Proxy에서는 정상이라면 구성의 DNS 해석과 정책 참조를 추가로 확인할 수 있습니다. 용어는 용어 매뉴얼에서, Global Routing을 처음 선택하는 방법은 사용 가이드에서 확인하세요. 기록 없이 규칙을 계속 추가하지 마세요. 중복되거나 서로 덮어쓰는 항목은 이후 문제를 재현하고 해결하기 어렵게 만듭니다.

03 서버 시간 초과: 연결 가능 여부, 핸드셰이크, 설정 구분

시간 초과는 어떤 단계에서 제한 시간 안에 예상한 응답을 받지 못했다는 뜻이지, 서버가 중단됐다는 증거는 아닙니다. 도메인 해석, 연결 수립, 프로토콜 핸드셰이크, 대상 전달 중 어느 단계에서든 멈출 수 있습니다. 서버 하나만 시간 초과인지, 구독에 포함된 여러 서버가 모두 시간 초과인지, 특정 대상에서만 발생하는지 먼저 확인하세요. 범위를 분명히 해야 기기 네트워크, 서비스 제공자 정보, 앱 설정 중 어디를 살펴볼지 정할 수 있습니다.

무엇을 테스트했는지 먼저 확인

Connectivity Test 결과는 테스트 방식, 대상 주소, 네트워크 상태에 따라 달라집니다. 특정 탐침이 실패해도 실제 웹페이지 접속까지 실패한다고 단정할 수 없고, 테스트에 성공해도 로그인, 동영상, 지속적인 데이터 전송이 정상이라는 뜻은 아닙니다. 사용한 방식과 대상을 확인한 뒤 실제 서비스 요청도 해보세요. 목록의 숫자 하나만 보고 서버를 반복해서 바꾸지 말고, 방식이 다른 테스트 결과를 그대로 비교하지도 마세요.

테스트할 때 네트워크, 대상, 선택한 서버를 고정하고 이전 테스트가 끝날 때까지 기다리세요. 그다음 Wi-Fi와 셀룰러 네트워크만 바꿔 다시 테스트합니다. 셀룰러 연결을 사용할 수 없는 iPad라면 신뢰할 수 있는 다른 네트워크를 이용하세요. 특정 네트워크에서만 실패한다면 해당 네트워크의 라우팅, 포트 연결 가능 여부, 프로토콜 조건을 확인해야 합니다. 서버 암호부터 바꾸지는 마세요. 모든 네트워크에서 실패한다면 서버 정보를 확인하세요.

프로토콜별 필수 항목 확인

Add Server 또는 해당 서버의 편집 화면을 열고 서비스 제공자가 안내한 정보를 기준으로 주소, 포트, 프로토콜 종류, 인증 항목과 전송 매개변수를 하나씩 확인하세요. 주소 앞뒤에 공백이 있거나 포트가 틀렸거나 식별자가 복사 과정에서 빠지면 대기 또는 핸드셰이크 실패가 발생할 수 있습니다. 이름이 같아 보인다는 이유로 항목별 확인을 생략하지 마세요. 표시 이름은 구분을 위한 것으로 연결 설정의 정확성을 증명하지 않습니다.

전송 방식, Host, 경로와 서버 이름은 서로 바꿔 쓸 수 있는 항목이 아닙니다. 서버가 특정 전송 설정을 사용한다면 클라이언트도 이에 맞춰야 합니다. TLS 오류가 보인다고 이름을 임의로 바꾸거나 공유 링크에서 모르는 항목을 전부 삭제하지 마세요. 먼저 서비스 제공자가 현재 안내한 원본 정보를 다시 가져온 뒤 수동으로 등록한 항목과 비교하세요. 차이를 추적할 수 있도록 기존 항목은 보존합니다.

TLS 오류와 시간 초과는 나눠서 해결

기록에 인증서, 이름 또는 시간 관련 오류가 명확히 표시되면 기기의 날짜와 시간이 정확한지 먼저 확인하고 서버 이름이 서버 측 요구사항과 일치하는지 살펴보세요. 인증서 검증 실패는 일반적인 속도 저하가 아니며 인증서 검증을 끄는 것도 보편적인 해결책이 아닙니다. 인증서 만료나 잘못된 배포는 서버 관리자 측에서 수정해야 합니다. 설정 오류를 감추려고 검증 조건을 낮추지 말고 클라이언트의 인증서 확인을 유지하세요.

같은 서버가 이전에는 작동했지만 지금은 모든 요청에 실패한다면 서비스 제공자 계정의 유효 상태, 서버 변경 공지와 현재 설정을 확인하세요. 앱 구매가 완료돼도 원격 서비스가 계속 작동한다는 보장은 없고, 구독을 업데이트해도 원격 서버가 복구되는 것은 아닙니다. 서비스 제공자에게 문의할 때는 단순히 ‘시간 초과’라고만 하지 말고 오류 발생 시각, 네트워크 종류, 프로토콜과 민감 정보를 가린 오류 문구를 전달하면 포트, 인증, 상위 서버 문제를 판단하는 데 도움이 됩니다.

무작정 서버를 바꾸지 말고 대조 항목으로 범위 좁히기

본인이 보유한 정보 중 정상 작동이 확인된 항목이 있을 때만 이를 비교 대상으로 사용하세요. 대조 항목은 정상이고 원래 항목만 실패한다면 해당 서버를 우선 확인합니다. 모든 항목이 실패한다면 시스템 권한, 기본 네트워크와 DNS를 다시 살펴보세요. 믿을 만한 대조 항목이 없어도 네트워크를 바꾸고 오류가 발생한 단계를 확인해 범위를 좁힐 수 있습니다. 진단을 위해 출처가 불분명한 항목이나 공개 구성을 가져올 필요는 없습니다.

해결한 뒤에는 연결 수립, 대상 열기, 짧은 시간 동안의 지속 전송을 차례로 확인하세요. 탐침 테스트에 한 번 성공한 것은 당시 특정 탐침 경로를 사용할 수 있었다는 뜻뿐입니다. 연결 직후 끊긴다면 대기 중, 네트워크 전환 중, 전송 시작 후 중 어느 때 발생하는지 기록하세요. 각각 연결 유지, 네트워크 전환, 전송 경로 문제일 수 있으므로 속도 저하와 간헐적 끊김 장에서 계속 확인합니다.

04 구독 오류: 가져오기, 파싱, 항목 추가를 구분

구독 업데이트는 원격 콘텐츠를 가져와 항목으로 파싱하는 과정이지 서버 연결 테스트가 아닙니다. 업데이트가 실패해도 기존 서버는 계속 작동할 수 있으며, 업데이트가 성공해도 인증, 네트워크, 원격 서버 상태에 따라 새 서버에 연결하지 못할 수 있습니다. 콘텐츠 가져오기, 형식 인식, 항목 저장 중 어느 단계에서 실패했는지 먼저 구분한 뒤 주소를 수정할지 판단하세요. 구독 주소는 본인의 서비스 제공자에게서 받아야 합니다. 이 사이트에서는 가져오기와 설정 방법만 안내합니다.

먼저 현재 사용 가능한 항목을 보존

작업하기 전에 구독 이름, 현재 항목 수, 선택 항목, 가장 최근 오류 문구를 기록하세요. 기존 항목이 작동한다면 구독 그룹 전체를 바로 삭제하거나 확인을 시작하기 전에 기존 주소를 덮어쓰지 마세요. 원본 정보를 안전하게 보관할 수 있다면 비교용 항목을 새로 추가해 새 주소가 정상적으로 가져와지는지 확인한 뒤 오래된 항목을 정리할 수 있습니다. 그룹을 삭제하면 항목과 연결된 선택 정보까지 사라져 기존 상태를 복구하기 어려울 수 있습니다.

단일 서버 공유 링크와 Subscribe에서 사용하는 구독 주소를 구분하세요. 단일 서버 링크는 서버 하나를 나타내며, 구독 주소는 보통 업데이트 가능한 항목 묶음을 가져오는 데 사용됩니다. 한쪽 주소를 다른 쪽 입력란에 넣으면 목록이 비거나 파싱에 실패할 수 있습니다. 복사할 때 채팅 안내, 줄바꿈, 문장부호, 페이지 제목이 함께 들어가지 않았는지 확인하세요. 주소의 쿼리 부분을 임의로 삭제하지 마세요. 계정 식별이나 형식 선택 정보가 포함돼 있을 수 있습니다.

구독 콘텐츠를 실제로 가져왔는지 확인

주소가 있다고 해서 올바른 콘텐츠를 가져올 수 있는 것은 아닙니다. 서버가 클라이언트에서 파싱할 수 있는 데이터 대신 계정 만료 안내, 로그인 페이지, 점검 페이지, 오류 응답을 반환할 수 있습니다. 상태 안내가 표시된다면 서비스 제공자의 계정 안내에 따라 유효성을 먼저 확인하세요. 로그인 양식이 포함된 웹페이지를 서버 구성으로 취급하지 말고, 구독 데이터가 아닌 콘텐츠를 파싱하려고 프로토콜 종류를 반복해서 바꾸지도 마세요.

가져오기 실패는 현재 요청 경로와 관련이 있을 수도 있습니다. 구독 업데이트에 사용되는 네트워크 경로가 특정 웹페이지의 경로와 같다는 보장은 없습니다. 먼저 기본 네트워크가 정상인 상태에서 수동 업데이트를 한 번 시도하고 오류를 확인한 뒤, 서비스 제공자 안내에 따라 이미 사용 가능한 연결이 필요한지 확인하세요. 구독을 가져오려고 모든 트래픽을 다른 모드로 계속 전환하지 마세요. 비교가 끝나면 원래 Config로 복원하고 어떤 조건에서 요청이 성공했는지 기록합니다.

구독 주소는 인증 정보처럼 보호

전체 주소, QR 코드, 내보낸 항목에 인증 정보가 포함될 수 있습니다. 공개 댓글, 출처를 알 수 없는 파싱 사이트, 공개 스크린샷에 붙여넣지 마세요. 문의할 때는 오류 유형과 민감 정보를 가린 필수 항목만 남기세요.

가져오기는 성공했지만 목록이 비거나 항목이 부족할 때

앱에서 콘텐츠를 가져왔다고 표시되는데 예상한 항목이 보이지 않으면 서비스 제공자가 안내한 형식이 Shadowrocket에 맞는지, 현재 계정에서 서버 목록을 실제로 반환하는지 확인하세요. 다른 형식의 필드 이름을 보고 임의로 변환 방법을 추측하지 마세요. 구독과 Config는 서로 다른 종류의 리소스입니다. 규칙 구성에 서버가 반드시 포함되는 것은 아니며, 서버 구독에 전체 규칙이 반드시 들어 있는 것도 아닙니다. 각각에 맞는 가져오기 위치를 사용하세요.

업데이트 후 일부 항목만 남았다면 이름 필터가 켜져 있는지, 지원되지 않거나 불완전한 필드가 있는지 확인한 뒤 서비스 제공자가 반환 내용을 변경했는지 살펴보세요. 항목 수가 달라졌다고 해서 앱이 데이터를 잃었다고 단정할 수는 없습니다. 원래 구독 안내와 업데이트된 이름을 비교해 서버 이름이나 그룹이 바뀌었는지 확인하세요. 수를 맞추려고 항목을 중복으로 가져오지 마세요. 중복 항목은 이후 선택과 테스트에 혼선을 줍니다.

자동 업데이트 전에 수동 테스트부터 확인

수동 업데이트가 안정적으로 완료되는 것을 먼저 확인한 다음 앱에서 제공하는 자동 업데이트 옵션을 켜세요. 앱이 열릴 때 자동 업데이트가 실행되는 구체적인 조건은 앱 내 설정 안내를 따릅니다. 기기가 어떤 백그라운드 상태에 있어도 계속 새로 고침된다는 뜻은 아닙니다. 자동 업데이트가 실행되지 않는다면 앱을 연 시점, 당시 네트워크, 수동 업데이트 결과를 기록하세요. 시스템이 모든 구독 접속을 막았다고 바로 판단하지 마세요.

업데이트에 성공한 뒤 선택한 서버를 다시 확인하세요. 항목 이름이나 식별 정보가 바뀌면 기존 선택이 더 이상 유효하지 않을 수 있으며, Config에서 참조하는 그룹이나 정책도 일치해야 합니다. 업데이트 알림만 보지 말고 실제 요청으로 확인하세요. 자세한 위치와 실패 상황은 구독 수동·자동 업데이트 안내에서, 링크 형식의 차이는 서버 링크 형식 안내에서 확인할 수 있습니다.

새 구독이 계속 실패하지만 기존 항목은 작동한다면 기존 항목을 당분간 보존하고 서비스 제공자에게 주소가 재설정됐는지, 계정이 유효한지, 형식이 바뀌었는지 확인하세요. 주소를 자주 재설정하면 설정된 다른 기기에서도 업데이트할 수 없게 될 수 있으므로 첫 번째 조치로 삼지 마세요. 문제가 해결되면 다른 기기에도 변경 사항을 반영해야 하는지 확인하고, 혼동을 줄이기 위해 더 이상 사용하지 않는 이전 주소 사본을 정리하세요.

05 속도 저하와 간헐적 연결 끊김: 재현 가능한 비교

속도 저하는 먼저 관찰 가능한 현상으로 구체화해야 합니다. 처음 열 때 오래 기다리는지, 전송을 시작한 뒤 속도가 낮은지, 동영상이 계속 버퍼링되는지, 한동안 사용하지 않은 뒤 다시 연결해야 하는지 확인하세요. 현상마다 원인이 발생하는 단계가 다를 수 있습니다. 연결 목록의 탐지 시간은 지속적인 대역폭이 아니며 대상 사이트의 응답 속도를 나타내지도 않습니다. 대상, 네트워크, 서버를 고정하고 서로 다른 시간과 콘텐츠에서의 경험을 바로 비교하지 마세요.

DNS 대기, 핸드셰이크 대기, 전송 속도 제한 구분

처음 접속은 느리지만 같은 페이지를 다시 열면 빨라지는 경우 도메인 해석, 연결 수립, 캐시 영향을 확인하세요. 처음에는 빠르다가 대용량 파일을 계속 전송할 때 느려진다면 네트워크 품질, 원격 서버 부하, 대상 서비스의 제한을 살펴봅니다. 특정 앱만 느리다면 사용하는 도메인, 백그라운드 다운로드 여부, 요청이 의도한 정책으로 전달되는지를 확인하세요. 동영상이 끊긴다고 모든 네트워크 요청이 같은 원인으로 제한된 것은 아닙니다.

비교 테스트에는 본인이 이용할 권한이 있고 반복해서 테스트할 수 있는 콘텐츠를 선택하세요. 파일 크기와 사용 방법을 비슷하게 유지하고 기기의 대용량 동기화 작업은 잠시 중단합니다. 테스트 전 Wi-Fi와 셀룰러 신호가 크게 달라지지 않았는지도 확인하세요. 속도 테스트를 연달아 많이 실행하지 마세요. 테스트 자체가 대역폭과 서버 부하, 배터리 소모를 늘려 측정 환경을 바꿀 수 있습니다. 해석할 수 있는 적은 횟수의 반복 테스트가 스크린샷을 많이 모으는 것보다 문제 진단에 유용합니다.

네트워크와 서버를 비교하되 한 번에 하나씩만 변경

먼저 서버는 그대로 두고 네트워크만 바꾸세요. 같은 서버가 다른 네트워크에서는 확실히 나아진다면 원래 네트워크의 무선 간섭, 상위 네트워크 혼잡, 특정 전송 조건을 우선 확인합니다. 그다음 네트워크는 그대로 두고 보유한 항목 중 정상 작동이 확인된 서버만 선택해 비교하세요. 비교 항목은 정상이지만 원래 항목만 느리다면 원래 서버나 출구 경로에 문제가 집중되어 있을 수 있습니다. 전환할 때마다 연결을 새로 수립하고 같은 대상을 테스트해 기존 연결의 영향을 배제하세요.

Wi-Fi에서는 액세스 포인트와의 거리, 동일 주파수 간섭, 같은 네트워크를 사용하는 다른 기기의 전송 때문에 지연이나 끊김이 생길 수 있습니다. 안정적인 위치로 이동한 뒤 기본 네트워크 접속에서도 같은 문제가 있는지 확인하고 프록시 경로를 점검하세요. 셀룰러 네트워크에서만 실패한다면 앱의 셀룰러 데이터 권한과 현재 신호 상태도 확인합니다. 통신 네트워크 간 차이가 반드시 앱 설정 오류 때문이라고 단정하지 말고 비교 조건을 기록해 관련 서비스 제공자에게 문의하세요.

간헐적 연결 끊김은 발생 조건 기록

유휴 상태, 화면 잠금, 네트워크 전환 후 연결이 끊기는 현상은 서로 다른 증상입니다. 유휴 상태에서 끊기면 연결 유지나 서버 측 시간 초과가 원인일 수 있습니다. 네트워크 전환 뒤 끊기면 이전 경로의 연결이 아직 다시 만들어지지 않았을 수 있습니다. 화면 잠금 후의 동작은 앱의 백그라운드 작업 방식에도 영향을 받습니다. 모든 앱이 함께 실패하는지, 특정 장기 연결만 끊기는지 기록하세요. 새 웹페이지는 열리지만 기존 세션이 멈췄다면 전체 구성을 재설정하기보다 해당 서비스의 연결을 새로 만드세요.

UDP에 의존하는 서비스는 일반 웹페이지가 열린다고 해당 경로까지 정상이라고 볼 수 없습니다. 특정 유형의 통화, 실시간 전송, 특정 프로토콜에서만 실패한다면 서버가 해당 트래픽을 지원하는지, 프로토콜 설정이 완전한지, 현재 네트워크가 필요한 전송을 허용하는지 확인하세요. MTU를 무작정 조정하거나 온라인에서 본 고정값을 적용하지 마세요. 실제 경로와 서버 요구사항에 맞는 매개변수인지 확인하고, 변경 전 원래 값을 기록한 뒤 같은 서비스로 테스트합니다.

속도 테스트 결과는 테스트 조건을 반영할 뿐입니다

테스트 대상, 시간, 네트워크와 서버가 함께 결과를 결정합니다. 탐지 시간이 짧아도 지속 전송 속도가 빠르다는 보장은 없고, 혼잡 시간대에 느렸다고 기기 설정이 영구적으로 잘못된 것은 아닙니다.

대상 서비스와 로컬 설정의 문제 구분

특정 대상 하나만 느리고 비슷한 다른 요청은 정상이라면 대상 서비스 자체, 계정 상태, 리소스 로딩 상황을 확인하세요. 앱 내장 브라우저와 별도 브라우저는 캐시, 로그인 상태, 연결 재사용 방식이 다를 수 있으므로 차이를 바로 분할 규칙 탓으로 돌릴 수 없습니다. 연결 기록에서 실패한 리소스를 확인해 응답 대기, 반복 재시도, 예상과 다른 정책 중 무엇인지 파악한 뒤 규칙 장으로 돌아가 최소한으로 수정하세요.

처리가 끝난 뒤에는 가장 빠른 한 번만 확인하지 말고 첫 접속, 짧은 시간 동안의 연속 사용, 정상적인 네트워크 전환 후 상태를 점검하세요. 서비스 제공자에게 문의해야 한다면 대상 유형, 네트워크 종류, 오류 시간대와 비교 결과를 정리하고 전체 인증 정보는 보내지 마세요. 속도 저하와 함께 기기가 뜨거워지고 배터리 소모가 늘면 백그라운드 전송, 반복 재시도, 진단 빈도를 확인하세요. 서버만 바꾸는 것보다 이 항목들이 원인에 더 가까울 수 있습니다.

06 DNS 문제: 도메인, 해석 경로, 규칙 확인

DNS는 도메인을 주소로 변환하지만 웹페이지 접속 실패가 모두 DNS 문제인 것은 아닙니다. 오류가 실제로 도메인 해석 단계에서 발생했는지 확인하고 서버 도메인과 대상 사이트 도메인을 각각 해석할 수 있는지 점검하세요. 프록시 서버 자체의 도메인을 해석하지 못하면 연결이 수립되기 전에 중단될 수 있습니다. 대상 도메인 해석 실패는 터널이 연결된 뒤에 발생할 수도 있습니다. 둘 다 인터넷에 접속할 수 없는 것처럼 보이지만 확인해야 할 위치는 다릅니다.

먼저 실패한 도메인을 확인하고 DNS 서비스부터 바꾸지 않기

실패한 대상과 오류 문구를 기록해 도메인 하나만 문제인지, 특정 하위 도메인 유형인지, 모든 도메인이 실패하는지 확인하세요. 도메인 하나만 실패한다면 철자, 서비스 운영 여부, 로그인이 필요한지부터 살펴봅니다. 홈페이지가 열린다고 모든 리소스의 도메인 해석이 정상인 것은 아닙니다. 페이지에서 사용하는 이미지, 인증, API가 서로 다른 도메인일 수 있습니다. 모든 DNS 설정을 곧바로 바꾸기보다 연결 기록에서 실제 실패 항목을 찾는 편이 정확합니다.

서버 주소가 도메인이라면 도메인이 만료됐거나 잘못 입력됐거나 서비스 제공자가 변경하지 않았는지 먼저 확인하세요. 해석된 주소 하나를 임의로 설정에 고정하지 마세요. 서버가 동적 라우팅을 사용할 수 있고 TLS 이름은 기존 도메인을 그대로 요구할 수 있습니다. 주소로 대조 테스트를 해야 한다면 서비스 제공자의 안내를 따르고 서버 이름과 관련 항목을 보존하세요. 그렇지 않으면 임시 테스트가 새로운 인증서나 라우팅 문제를 만들 수 있습니다.

접속 경로와 함께 DNS 설정 확인

Config에서 사용자 지정 DNS 설정이 있는지, 가져온 구성에서 해석 동작을 바꾸는 항목이 있는지, DNS 요청에 특정 출구가 필요한지 확인하세요. DNS 서버에 접속할 수 없으면 설정 문법이 맞아도 결과를 얻지 못합니다. 시스템의 네트워크 DNS 설정도 함께 사용 중이라면 별개의 변수로 하나씩 확인하고 전부 한꺼번에 삭제하지 마세요. 실제로 어느 설정이 적용되는지 확인한 뒤 중복이나 충돌 여부를 판단합니다.

일부 암호화 DNS 방식은 DNS 서버에 먼저 도달해 연결을 완료해야 합니다. 현재 네트워크에서 해당 엔드포인트에 접속할 수 없거나, 엔드포인트 접속 자체에 아직 완료되지 않은 DNS 해석이 필요하면 대기 상태가 연쇄적으로 이어질 수 있습니다. 이때는 DNS 주소를 더 추가하기보다 현재 구성의 전체 설계와 초기 연결 경로를 확인하세요. 출처가 다른 DNS 설정 여러 개를 섞기보다 이전에 검증한 구성 사본으로 복원하는 편이 원인을 찾기 쉽습니다.

도메인 규칙과 주소 규칙의 결과는 다를 수 있습니다

DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD는 도메인 조건을 확인하고 IP-CIDR, IP-CIDR6, GEOIP는 주소와 관련된 조건을 확인합니다. 후자의 결과는 주소를 이미 확보했는지, 앱이 실제로 어떤 요청을 보냈는지에 따라 달라질 수 있습니다. 도메인만 보고 주소 규칙이 반드시 일치한다고 추측하지 마세요. 서버가 지역, 주소 체계, 콘텐츠 전송 경로에 따라 다른 결과를 반환할 수 있으므로 실제 기록을 확인해야 합니다.

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

여기서 no-resolve는 주소 규칙이 일치하는지 확인하기 위해 도메인 해석을 새로 요청하지 않는다는 뜻이지 앱 전체의 DNS를 끈다는 뜻이 아닙니다. 예시는 규칙 일부만 보여 주며 완전한 서버나 DNS 설정을 정의하지 않습니다. 속도를 높이려고 모든 규칙에 이 옵션을 덧붙이지 마세요. DNS 해석 여부를 바꾸면 규칙 판단에 사용할 수 있는 정보도 달라지므로 규칙 목적과 앱에서 지원하는 문법에 맞게 사용해야 합니다.

IPv4, IPv6, 캐시는 각각 따로 확인

네트워크에서 IPv6를 지원한다고 모든 서버와 대상이 같은 경로를 제공하는 것은 아닙니다. 특정 네트워크에서만 실패한다면 오류가 특정 주소 체계에 집중되는지, 서비스 제공자가 현재 해당 경로를 지원하는지 확인하세요. 특정 주소 체계를 전역에서 끄는 방법을 영구적인 기본 해결책으로 삼지 마세요. 실제 실패 경로를 먼저 확인한 뒤 구성 안내에 따라 비교합니다. 로컬 네트워크의 기기 검색이나 로컬 도메인은 현재 Wi-Fi의 DNS 조건에 영향을 받을 수도 있습니다.

DNS 설정을 수정한 뒤에도 이전 캐시나 이미 수립된 연결이 잠시 결과에 영향을 줄 수 있습니다. 연결을 끊었다가 다시 연결하고 대상 앱을 다시 열어 새 요청을 보내세요. 필요한 경우 캐시가 자연스럽게 만료될 때까지 기다립니다. 특정 새로 고침 동작이 모든 계층의 캐시를 반드시 지운다고 단정하지 마세요. 브라우저, 시스템, 앱, 원격 서버가 각각 캐시를 저장할 수 있습니다. 아직 끝나지 않은 같은 요청을 계속 새로 고치기보다 새 연결의 결과를 기록하세요.

프린터, 가정용 기기, 내부 도메인에 접속할 수 없다면 먼저 같은 Wi-Fi에서 직접 접속되는지 확인하고 기기에서 로컬 네트워크 접속을 허용하는지, 네트워크에 클라이언트 격리가 없는지 확인하세요. 사설 주소 규칙은 로컬 DNS 해석을 대신하지 않습니다. 마지막으로 서버 도메인, 일반 대상 도메인, 실제로 필요한 로컬 대상을 각각 테스트하세요. DNS 테스트에서 주소가 한 번 반환된 것만으로는 충분하지 않으며 필요한 접속이 모두 복구되어야 조정이 끝난 것입니다.

07 배터리 소모 문제: 트래픽과 On Demand 함께 확인

시스템 배터리 화면에서 Shadowrocket의 사용 비중이 높아도 앱이 그만큼의 트래픽을 단독으로 발생시키고 있다는 뜻은 아닙니다. 터널을 통해 다른 앱의 요청을 처리하면 관련 작업이 Shadowrocket의 사용량으로 집계될 수 있으며, 같은 집계 기간에 다른 앱이 사용한 전력에 따라서도 비율이 달라집니다. 상대 비율 하나만 보고 모든 연결 기능을 끄지 말고 사용 시간, 화면 활동, 실제 사용 작업을 함께 확인하세요.

비슷한 사용 조건으로 비교 구간 설정

사용 방식이 비슷한 두 시간대를 골라 네트워크 종류, 연결 시간, 주로 사용한 앱, 대용량 업로드나 다운로드가 있었는지 기록하세요. 시스템 업데이트 후 백그라운드 정리, 사진 동기화, 미디어 재생, 불안정한 신호도 배터리 소모를 바꿀 수 있습니다. 한 시간대는 신호가 강한 Wi-Fi, 다른 시간대는 신호가 약한 셀룰러 네트워크라면 스위치 하나의 효과를 직접 비교하기 어렵습니다. 설정 변경의 효과를 확인하려면 먼저 환경을 비슷하게 맞추세요.

기기가 눈에 띄게 뜨거워지는지, 연결이 자주 끊겼다 다시 연결되는지, 기록에 계속 실패하는 요청이 나타나는지도 확인하세요. 설정 오류로 재시도가 반복되면 대기 시간, 트래픽, 처리 비용이 함께 늘 수 있습니다. 이때는 연결만 끄기보다 서버, DNS, 규칙 문제를 먼저 해결해야 합니다. 백그라운드에서 계속 전송되는 작업이 있다면 그 작업을 일시 중지하고 관찰하는 편이 터널만 조정하는 것보다 트래픽 원인을 파악하기 쉽습니다.

On Demand는 연결을 시작하는 조건이지 절전 보장이 아닙니다

On Demand는 설정 조건에 따라 연결을 요청하는 기능이며, 실제 동작은 지정한 규칙과 시스템의 트리거에 따라 달라집니다. 시스템이 각 앱의 사용 의도를 모두 파악한다는 뜻도 아니고, 모든 상황에서 수동으로 연결을 유지하는 것보다 배터리를 절약한다는 보장도 없습니다. 조건이 너무 넓으면 일반 백그라운드 요청도 연결을 계속 시작할 수 있습니다. 반대로 실제 사용 방식과 조건이 맞지 않으면 필요한 순간에 연결되지 않을 수 있습니다. 언제 연결할지 먼저 정한 뒤 조건을 선택하세요.

문제를 확인할 때는 기존 조건을 기록한 다음 On Demand를 잠시 끄고 수동으로 연결해 보세요. 수동 연결은 안정적이지만 On Demand에서 연결이 반복해서 켜졌다 꺼진다면 네트워크 변화에 따라 조건이 번갈아 일치하는지, 다른 자동 연결 설정이 있는지 확인합니다. 조건을 바꾸면서 네트워크를 빠르게 계속 전환하지 마세요. 변경할 때마다 시스템에서 연결을 끊고 다시 설정할 시간을 주고, 스위치가 순간적으로 보이는 상태만 보지 말고 일반적인 사용 중에 확인하세요.

사용 상황에 맞는 연결 관리 방식 선택

같은 서비스를 오랫동안 계속 사용한다면 연결을 자주 만들고 끊는 방식이 더 적합하지 않을 수 있습니다. 가끔 짧게 사용하는 경우에는 작업을 마친 뒤 직접 연결을 끊거나 이해하고 있는 조건에 따라 On Demand를 사용할 수 있습니다. 모든 기기에 통용되는 고정된 방법은 없습니다. 연결 방식이 실제 용도에 맞아야 하며, 상태 아이콘을 숨기려다 앱이 계속 연결에 실패하고 재시도해 네트워크 활동이 늘어나지 않도록 하세요.

수동으로 끈 뒤에도 매번 다시 연결된다면 스위치 고장으로 오해하지 말고 On Demand와 시스템의 해당 VPN 설정에서 연결 조건을 확인하세요. 테스트를 위해 자동 연결 조건을 끈 뒤 연결을 해제하고 상태가 유지되는지 살펴봅니다. 기기가 관리 대상이라면 관리자가 설정한 연결 요구사항도 확인해야 합니다. 알 수 없는 관리 구성은 제거하지 마세요. 시스템 정책과 개인 앱 설정은 별도로 확인해야 하며 처리 권한도 다릅니다.

진단에도 비용이 듭니다

짧은 간격으로 속도 테스트를 반복하거나, 상세 기록을 오래 켜 두거나, 실패한 페이지를 계속 새로 고치면 기기 활동이 늘어납니다. 필요한 자료를 확보한 뒤 추가 테스트를 끝내고 진단 설정은 실제 필요에 맞게 되돌리세요.

앱 처리 문제와 원격 서버 연결 문제 구분

배터리 소모와 속도 저하가 함께 나타난다면 재전송이 많은지, 핸드셰이크가 반복되는지, DNS 엔드포인트에 접속할 수 없는지 확인하세요. 같은 서비스를 유지한 채 본인이 보유한 정상 작동 확인 서버 하나만 잠시 비교 대상으로 바꾸고 발열과 안정성이 함께 개선되는지 관찰합니다. 신호가 약한 특정 네트워크에서 모든 서버가 비정상이라면 구성을 계속 바꾸기보다 기본 네트워크 상태를 먼저 개선하세요. 앱이 무선 네트워크 자체의 전력 소모를 없앨 수는 없습니다.

개선 여부는 사용 시간이 비슷한 구간에서 실제 배터리 변화, 기기 온도, 작업 완료 여부를 비교해 판단하세요. 앱 사용 순위만 내려갔다고 개선된 것은 아닙니다. 다른 앱의 전력 사용이 늘어서 비율이 내려갈 수도 있습니다. 일정한 절전 비율을 보장하지 않으며, 사용 순위를 낮추려고 필요한 연결 안정성을 포기할 필요도 없습니다. 연결이 안정되고 실패 재시도가 줄면서 배터리 소모도 적절하다면 필요한 조정이 효과를 거둔 것입니다.

사용 상황별 선택은 백그라운드 연결 유지와 On Demand 안내에서 더 자세히 확인할 수 있습니다. 추가 진단을 끄고 재시도 원인을 수정한 뒤에도 문제가 계속되면 사용 상황, 시스템 배터리 기록, 민감 정보를 가린 오류 요약을 보존한 뒤 업데이트나 구성 복원을 고려하세요. 백업 없이 바로 다시 설치하지 마세요. 문제 해결에 필요한 기록을 잃을 뿐 아니라 기존 서버와 규칙도 함께 삭제될 수 있습니다.

08 업데이트 후 오류와 iPad: 차이를 기록하고 복구

‘업데이트 후 오류가 발생했다’는 것은 발생 시점의 관계를 설명할 뿐 앱 업데이트만이 원인이라는 증거는 아닙니다. 같은 시기에 시스템 업데이트, 구독 새로 고침, 서버 변경, 네트워크 환경 변화가 있었을 수 있습니다. 마지막으로 정상 작동한 때부터 처음 실패한 때까지 무엇이 바뀌었는지 기록하고 최소 재현 절차를 정하세요. 비교에 필요한 근거를 잃지 않도록 현재 구성 사본과 오류 정보를 보존하세요. 처음부터 앱을 다시 설치하면 기존 문제를 새 설정으로 가져와 다시 겪을 수도 있습니다.

앱, 시스템, 구성 중 어디에서 바뀌었는지 확인

모든 서버, 네트워크, 대상에 문제가 있는지 아니면 특정 Config에만 발생하는지 확인하세요. 같은 서버가 Proxy에서는 작동하지만 업데이트된 Config에서 실패한다면 규칙, 정책 참조, DNS 설정을 비교합니다. 구독을 새로 고친 뒤 항목만 실패한다면 반환된 설정값부터 확인하세요. 앱 업데이트, 구독 업데이트, Config 업데이트는 서로 다른 작업입니다. 문제 기록에 단순히 ‘업데이트함’이라고만 적지 말고 각각 구분해 기록하세요.

앱 업데이트와 다시 받기는 App Store를 통해 진행하세요. 시스템 요구 사항은 App Store 페이지에 표시된 내용을 기준으로 합니다. 배포 출처를 확인해야 한다면 개발자 Shadow Launch Technology Limited, 공식 아이콘, 앱 ID 932747118을 확인하세요. 자세한 방법은 정품 확인 안내를 참고하세요. 구매 내역은 앱을 취득했음을 보여 줄 뿐 구성이 자동으로 올바르거나 본인의 원격 서버가 현재 작동한다는 뜻은 아닙니다.

모든 데이터를 지우기 전에 되돌릴 수 있는 순서로 복구

앱을 정상적으로 종료한 뒤 다시 열고 현재 서버, Global Routing, Config가 바뀌지 않았는지 확인하세요. 필요하다면 기기를 재시동한 뒤 다시 테스트합니다. 문제가 계속되면 출처가 불분명한 전체 구성을 가져오지 말고 보유한 정상 작동 확인 구성 사본과 비교하세요. 기존 구성은 보존하고 현재 활성 항목만 바꿉니다. 차이를 찾으면 필요한 규칙을 하나씩 옮기고 정책 이름과 서버의 연결 관계가 유지되는지 확인합니다.

시스템 VPN 구성이 손상됐다고 의심되는 경우에만 첫 번째 장의 방법에 따라 다시 권한을 승인하세요. 재승인은 시스템 구성 문제를 해결하는 절차이지 삭제된 구독, 암호, 사용자 지정 규칙을 복구하는 방법이 아닙니다. 앱 재설치는 더 나중에 고려하세요. 먼저 원본 구독 주소, 서버 정보, 필요한 구성을 안전하게 저장하고 앱에서 현재 지원하는 내보내기 항목을 확인합니다. 내보낸 파일에도 인증 정보가 포함될 수 있으므로 직접 관리하는 안전한 위치에 보관하세요.

iPad에서는 계정, 선택 항목, 네트워크 차이 확인

iPhone에서는 작동하지만 iPad에서 실패한다면 두 기기에서 같은 유효 정보를 사용하는지, 같은 서버와 Global Routing을 선택했는지 먼저 확인하세요. 표시 이름이 같아도 내부 설정은 다를 수 있으며 기기를 옮긴 뒤 의도한 Config가 활성화되지 않았을 수도 있습니다. 실제 선택 항목, 규칙 일치 여부, 오류 발생 단계를 기기별로 확인하고 차이를 비교하세요. Apple 계정이 같다는 이유만으로 앱의 모든 설정이 자동 동기화되어 동일하게 유지된다고 생각하지 마세요.

화면 크기와 표시 방식에 따라 iPad에서는 측면 패널이 나타나거나 정보 배치가 달라질 수 있습니다. 버튼의 화면 좌표를 따라 찾지 말고 Home, Config, Settings 등의 화면 이름을 기준으로 메뉴를 찾으세요. 분할 화면에서 보이는 영역이 좁아져도 설정이 사라진 것은 아닙니다. 화면을 가리는 요소를 닫거나 해당 영역을 펼쳐 현재 작업이 서버 편집, 구성 선택, 시스템 권한 중 어디에 해당하는지 확인하세요. 잘못된 위치에서 가져오기를 반복하지 않도록 주의합니다.

Wi-Fi만 사용할 수 있는 iPad는 자체 셀룰러 네트워크로 비교할 수 없으므로 신뢰할 수 있는 다른 네트워크를 사용하세요. iPhone은 셀룰러 네트워크, iPad는 인증이 필요한 Wi-Fi를 사용한다면 같은 조건의 비교가 아닙니다. 현재 Wi-Fi에서 기기 간 접속을 제한하는지, 필요한 작업에 로컬 네트워크 권한이 있는지도 확인하세요. 일반 웹페이지가 열린다고 프린터나 내부 도메인에 접속할 수 있는 것은 아닙니다.

구매 항목 복원과 구성 복원은 별개

앱을 다시 받으려면 App Store에서 실제 구매에 사용한 Apple 계정으로 구입 항목을 찾으세요. 표시 내용과 이용 가능 범위는 App Store 페이지를 기준으로 확인합니다. iPad의 호환성과 구매 적용 범위도 App Store 페이지에 표시된 내용을 따릅니다. 앱을 복원한 뒤에도 본인의 구독과 Config가 남아 있는지 확인해야 합니다. 앱 복원이 모든 사용 설정을 복구하는 것은 아닙니다. 절차는 구입 항목 복원 안내를 참고하세요.

재현 가능한 문제 해결 결과 기록

증상, 발생 조건, 변경한 한 가지 항목, 다시 테스트한 결과를 기록하세요. 문제가 계속되면 기기와 네트워크 정보, 민감 정보를 가린 오류 요약을 함께 정리하되 구독 전체 주소, 키, 전체 내보내기 구성은 제공하지 마세요.

복구한 뒤 사용 가이드를 따라 가져오기, Config 선택, 권한 승인과 실제 접속을 다시 확인하고 On Demand와 필요한 로컬 네트워크 작업도 점검하세요. 문제가 재현되면 모두 지우기를 반복하지 말고 해당 증상에 맞는 이 페이지의 장으로 돌아가 범위를 좁히세요. 같은 절차로 안정적으로 성공하고 임시 우회 때문에 기존 사용 목적이 손상되지 않아야 해결된 것입니다. 재시동 후 한 번 정상처럼 보이는 것만으로는 충분하지 않습니다.