Shadowrocket 전체 사용 설명서

먼저 App Store에서 확인하세요

Shadowrocket은 Apple 플랫폼용 유료 앱이며, 이 설명서는 주로 iPhone과 iPad를 기준으로 작성되었습니다. 앱은 App Store 제품 페이지에서 확인할 수 있습니다. Mac, Apple TV 및 Apple Vision 호환 여부도 같은 스토어 페이지에서 확인하세요. 기기 이름만으로 구체적인 시스템 요구 사항이나 구매 가능 범위를 추측하지 마세요. 시스템 요구 사항, 지원 기기와 현재 가격은 App Store 페이지에 표시된 내용을 기준으로 합니다. 구매 전 현재 이용 중인 App Store 스토어프런트와 해당 제품 페이지의 구매 가능 여부를 확인하세요. 검색 결과는 제품 페이지를 찾기 위한 경로일 뿐이므로, 최종 정보는 제품 상세 페이지에서 확인해야 합니다.

제품을 확인할 때는 세 가지를 함께 살펴보세요. 앱 이름은 Shadowrocket, 개발자는 Shadow Launch Technology Limited, 제품 링크의 앱 ID는 932747118입니다. 페이지에 표시된 아이콘은 스토어 제품 아이콘과 일치해야 하지만, 아이콘만으로 판단해서는 안 됩니다. 이름이나 이미지가 비슷한 검색 결과가 다른 제품으로 연결될 수도 있습니다. 상세 페이지에서 개발자 이름 전체를 읽고 주소에 id932747118이 포함되어 있는지 확인하세요. 이 세 가지 정보가 서로 일치하는지 확인하는 편이 별칭 하나를 기억하는 것보다 정확합니다. 확인 위치와 기기 안내는 App Store 앱 확인 안내를 참고하세요.

앱 가격과 연결 정보를 구분하세요

구매 비용은 Shadowrocket 앱 자체에 대한 것입니다. 미국 스토어 페이지에는 과거 일회성 구매 가격이 약 2.99달러로 표시된 적이 있습니다. 실제 가격, 통화와 구매 조건은 현재 App Store 페이지를 기준으로 하세요. 앱 일회성 구매 ≠ 연결 서비스 요금제: 구매를 완료해도 앱을 사용할 수 있게 될 뿐, 연결할 서버 정보가 자동으로 제공되지는 않습니다. 이후 가져오기 단계는 본인이 이미 보유한 구독이나 서버 매개변수가 있다는 전제에서 진행합니다. 아직 해당 정보를 가지고 있지 않더라도 라우팅 및 인터페이스 안내는 확인할 수 있지만, 앱에 SERVER 항목이 보이지 않는다고 해서 구매에 실패했다고 판단해서는 안 됩니다.

iPhone 또는 iPad에서 구매한 뒤 App Store 제품 상세 페이지로 돌아가 설치하고, 시스템 처리가 완료될 때까지 기다리세요. 버튼이 앱을 다시 받는 상태로 표시되면 현재 로그인한 구매 계정을 확인한 다음 App Store의 구입 항목을 살펴보세요. 기기 홈 화면에 아이콘이 있는지만으로 구매 기록을 판단하지 마세요. 기기를 바꾸거나 앱을 다시 설치할 때 구매 기록과 앱에 직접 가져온 설정은 서로 별개입니다. 앱을 다시 받아도 기존 구독, 서버 메모와 사용자 규칙이 반드시 복원되는 것은 아닙니다. 기기 이동을 준비할 때는 사용할 권한이 있는 원본 정보를 먼저 보관한 다음 새 기기의 실제 상태에 맞춰 가져오세요.

‘제품이 맞는지’, ‘앱을 구매했는지’, ‘연결 정보가 준비되었는지’를 따로 확인하면 이후의 오판을 줄일 수 있습니다. 예를 들어 Home을 열었는데 목록이 비어 있다면 다시 구매하기보다 먼저 가져오기를 완료했는지 확인하세요. 연결 후 대상 웹사이트에 접속할 수 없다면 아이콘이나 스토어 계정 탓으로 돌리기보다 서버, 라우팅과 네트워크를 확인하세요. 준비가 끝나면 첫 실행과 VPN 구성 권한 단계로 넘어갑니다.

먼저 Home 화면의 주요 영역을 확인하세요

Shadowrocket을 처음 열면 Home에서 현재 상태를 살펴보고, 모든 옵션을 바로 변경할 필요는 없습니다. Home은 연결 조작의 시작점입니다. 상단의 연결 스위치와 상태 문구는 현재 연결 상태를 보여주고, Global Routing은 트래픽의 라우팅 방식을 정하며, SERVER 영역에서는 추가한 서버를 확인하고 선택할 수 있습니다. Connectivity Test는 연결 상태를 점검하는 데 도움이 됩니다. 처음 열었을 때 Not Connected가 표시되면 현재 연결이 설정되지 않았다는 뜻입니다. 선택할 SERVER 항목이 없다면 먼저 가져오기를 진행하세요. 화면 크기와 앱 레이아웃에 따라 항목 위치가 달라질 수 있으므로, 찾을 때는 영어 인터페이스 용어를 기준으로 하세요.

‘상태 확인 → 정보 확인 → 라우팅 선택 → 연결 켜기’ 순서로 진행하는 것이 좋습니다. 그러면 시스템 권한 팝업이 나타났을 때 어떤 스위치 조작으로 실행되었는지 파악할 수 있어 권한 요청, 서버 가져오기와 규칙 선택을 혼동하지 않습니다. 사용 가능한 서버를 선택하지 않은 채 스위치를 켰다면, 이후 연결 실패는 권한 허용을 반복한다고 해결되지 않습니다. 조작 전 상태 문구를 기록해 두면 다음에 확인할 때 실제로 변화가 있었는지 판단하기 쉽습니다.

시스템 권한 팝업 이해하기

iPhone 또는 iPad에서 처음 연결을 켜려고 하면 시스템에서 Shadowrocket의 VPN 구성 추가를 허용할지 물을 수 있습니다. 이는 네트워크 구성 변경을 확인하는 절차이며, 특정 서버에 이미 연결되었다는 의미는 아닙니다. 팝업에 표시된 앱 이름과 시스템 안내를 읽고 현재 조작에 해당하는지 확인한 다음, 안내에 따라 권한을 허용하세요. 기기에 따라 암호나 생체 인증을 요구할 수도 있습니다. 권한을 허용한 뒤 앱으로 돌아와 연결 스위치, 선택한 SERVER, Global Routing과 테스트 결과를 확인해야 합니다. 시스템 상태 막대에 VPN 표시가 나타나도 관련 네트워크 구성이 활성화되었다는 뜻일 뿐, 모든 대상에 예상대로 접속할 수 있다는 보장은 아닙니다.

팝업을 취소했다면 먼저 Home으로 돌아가 스위치 상태를 확인한 다음 앱에서 연결을 다시 조작해 권한 요청을 띄우세요. 스위치를 빠르게 반복해서 켰다 끄지 마세요. 이미 구성을 허용했는데 이후 연결 시 권한 관련 안내가 계속 나타난다면 기기에서 VPN 설정 변경을 허용하는지, 기기 관리 제한이 있는지 먼저 확인하세요. 실제로 조정할 수 있는 항목은 기기 설정에 따라 다릅니다. 일반적인 서버 매개변수 오류를 해결하려고 시스템 구성을 반복해서 삭제하지 마세요. 오류가 ‘권한 허용 전’, ‘권한 허용 후 연결되지 않음’, ‘연결되었지만 접속 이상’ 중 어느 단계에서 발생했는지 먼저 구분하세요. 각 상황의 확인 방향은 서로 다릅니다.

iPad에서도 같은 순서로 확인하세요

iPad의 넓은 화면에서는 Home의 목록과 컨트롤 배치가 iPhone과 다르게 보일 수 있지만, 권한의 성격은 같습니다. 시스템은 기기의 VPN 구성을 확인하며, SERVER 정보는 사용자가 직접 가져와야 합니다. 두 기기를 처음 사용할 때는 각 기기의 시스템 권한과 앱에서 선택된 항목을 따로 확인하세요. 한 기기에서 허용했다고 다른 기기에서도 자동으로 완료되는 것은 아닙니다. 동일한 Apple ID의 구매 기록은 App Store의 구입 항목에서 확인하고, 연결 정보는 각 기기의 실제 목록에서 확인하세요.

권한을 확인한 뒤에는 연결을 끈 상태로 유지하고, 먼저 보유한 정보를 가져와 각 항목을 확인하세요. 스위치, 목록 또는 테스트 메뉴를 찾기 어렵다면 첫 실행 및 Home 화면 안내를 참고하세요. 이 단계에서 유용한 기록은 ‘웹사이트에 접속되는지’보다 앱이 정상적으로 시작되는지, Home이 표시되는지, 시스템 권한을 허용했는지, SERVER 목록이 비어 있는지입니다. 이러한 사실을 확인해 두면 다음 단계에서 가져오기 문제의 범위를 좁힐 수 있습니다.

먼저 정보 유형을 구분하세요

Shadowrocket의 서버 항목은 직접 입력, 단일 공유 링크 또는 구독을 통해 추가할 수 있습니다. 시작하기 전에 보유한 정보의 유형을 확인하세요. 서버 주소, 포트, 프로토콜과 인증 항목은 각각 입력하면 됩니다. 프로토콜 접두사로 시작하는 공유 링크는 보통 단일 항목을 나타냅니다. 서비스 제공자가 여러 항목을 정기적으로 가져오도록 제공한 URL은 Subscribe 방식으로 처리해야 합니다. 구독 URL과 서버 주소는 서로 대체할 수 없습니다. 구독 URL을 서버 주소 칸에 넣거나 단일 공유 링크를 구독 업데이트 주소로 사용하면 원인을 파악하기 어려운 오류가 발생할 수 있습니다.

직접 추가하려면 Home에서 추가 메뉴를 찾아 Add Server로 이동한 뒤, 보유한 정보와 일치하는 프로토콜 유형을 선택하고 항목을 하나씩 입력하세요. 주소에는 호스트 이름이나 IP를 입력하고, 포트는 제공된 값과 일치시켜야 합니다. 인증 정보는 해당 프로토콜의 요구 사항에 따라 입력하세요. 메모는 항목을 구분하는 데 유용하지만 연결 매개변수는 아닙니다. 복사한 내용 앞뒤의 공백, 숫자로 된 포트, 대소문자를 구분하는 필드와 혼동하기 쉬운 문자를 확인하세요. 저장한 다음 SERVER로 돌아가 새 항목이 나타났는지, 실제로 어떤 항목이 선택되어 있는지 확인한 후 연결을 시작하세요. 지원되는 필드는 현재 Add Server 화면을 기준으로 합니다.

프로토콜별 필수 매개변수 확인

이 표는 확인 방향을 찾기 위한 참고 자료이며, 일반적인 입력 템플릿이 아닙니다. 같은 프로토콜이라도 전송, 보안 및 도메인 매개변수가 다를 수 있으므로 서비스 제공자가 안내한 값을 기억에 의존해 바꾸지 마세요. WireGuard의 PrivateKey는 로컬 인증 정보이며, PublicKey와 Endpoint는 각각 역할이 다릅니다. 자세한 내용은 WireGuard 매개변수 안내를 참고하세요. 인증 정보는 공개 페이지, 스크린샷 또는 문의 메시지에 전체 내용을 노출하지 마세요. 필드를 점검할 때는 원본 정보와 항목별로 직접 대조하는 것이 좋습니다.

기존 구독 가져오기 및 업데이트

Subscribe URL을 보유하고 있다면 앱에서 해당 구독 추가 방식을 선택해 전체 주소를 붙여넣고 저장한 다음 앱에서 제공하는 업데이트 기능을 실행하세요. https://example.com/sub?token=xxxx 같은 구독 주소 예시는 URL 형식을 설명하기 위한 것이며 연결에 사용할 수 없습니다. 업데이트가 성공하면 SERVER로 돌아가 항목이 생성되었는지, 선택된 항목이 여전히 필요한 것인지 확인하세요. 가져오기 성공과 서버 사용 가능 여부는 별개입니다. 전자는 앱이 정보를 가져와 해석했다는 의미이고, 후자는 연결 및 대상 접속 테스트가 필요합니다. ss://, vmess://, vless://, trojan:// 단일 링크와 구독 URL의 차이는 공유 링크와 구독 링크 안내를 참고하세요.

업데이트에 실패하면 먼저 기기에서 구독 주소에 접속할 수 있는지, URL이 잘리지 않았는지, 원본 정보가 여전히 유효한지 확인하세요. 업데이트 완료로 표시되지만 목록이 비어 있다면 구독의 실제 내용과 앱이 인식하는 형식이 맞는지 확인해야 합니다. 비공개 URL을 공개 검사 웹사이트에 붙여넣어 시험하지 마세요. Scan QR Code는 본인이 보유한 유효한 정보를 가져오는 데 사용할 수 있지만, 스캔한 뒤에도 항목과 출처를 다시 확인해야 합니다. 정보가 SERVER에 추가되면 다음으로 Global Routing을 선택하세요. 목록에 항목이 표시된다는 이유만으로 라우팅이 올바르다고 판단해서는 안 됩니다.

규칙을 살펴보기 전에 라우팅 방식을 선택하세요

Global Routing은 트래픽에 적용할 라우팅 판단 방식을 정합니다. 인터페이스의 Config, Proxy, Direct는 각각 설정에 따른 라우팅, 선택한 프록시 경로 사용, 직접 연결 경로 사용으로 이해할 수 있습니다. 여기의 한국어 설명은 동작을 풀어 쓴 것이며, 실제 설정을 찾을 때는 영어 용어를 기준으로 하세요. 방식을 바꾸더라도 서버 정보를 다시 입력할 필요는 없지만, 연결 결과를 해석하는 방식은 달라집니다. 같은 대상도 Config에서는 DIRECT로 처리되고 Proxy에서는 선택한 서버를 경유할 수 있습니다. 따라서 문제를 점검할 때는 현재 방식을 먼저 기록하세요. 스위치가 켜져 있는데 서버를 거치지 않은 것처럼 보이는 현상이 라우팅 선택에 따른 정상 동작일 수도 있습니다.

Config에서는 규칙 순서와 기본 정책을 이해하는 것이 중요합니다. 규칙은 일반적으로 구체적인 조건부터 더 일반적인 조건 순으로 적용됩니다. DOMAIN은 정확한 도메인을 지정하고, DOMAIN-SUFFIX는 도메인 접미사를, DOMAIN-KEYWORD는 키워드를 기준으로 일치 여부를 판단합니다. GEOIP, IP-CIDR 및 IP-CIDR6은 주소 범위에 따른 판단에 사용됩니다. 규칙 오른쪽의 PROXY, DIRECT, REJECT는 처리 정책이며 프로토콜 이름이 아닙니다. PROXY는 사용 가능한 서버가 선택되어 있어야 하고, DIRECT는 기기의 현재 네트워크를 통해 직접 접속하며, REJECT는 일치하는 요청을 거부합니다. USER-AGENT도 규칙에서 사용하는 키워드입니다. 특정 요청에 적용되는지는 앱에서 실제로 어떻게 일치하는지 확인하세요.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,ads,REJECT
GEOIP,CN,DIRECT
FINAL,PROXY

여기서 example.com은 예시 도메인입니다. 이 조각은 규칙 간의 관계만 보여 주며 완전한 설정으로 사용할 수 없습니다. 첫 번째 줄은 해당 도메인과 하위 도메인에 PROXY를 적용합니다. 두 번째 줄은 키워드 일치 후 REJECT를 적용하는 예입니다. 세 번째 줄은 GEOIP와 DIRECT의 조합을 보여 줍니다. 앞선 규칙에 해당하지 않는 요청은 FINAL에서 처리됩니다. 마지막에 FINAL,DIRECT를 작성하면 일치하는 규칙이 없는 요청은 직접 연결됩니다. 변경 전에는 현재 Config를 저장하고 대상과 예상 동작을 기록하세요. 여러 규칙을 한꺼번에 바꾸면 어떤 변경이 결과에 영향을 줬는지 파악하기 어렵습니다.

세 가지 라우팅 방식으로 문제 범위 좁히기

Config에서 특정 대상에 접속할 수 없다면 테스트 범위를 명확히 한 뒤 Proxy와 Direct 결과를 비교해 보세요. Proxy에서는 접속되지만 Config에서는 되지 않는다면 규칙 일치 여부와 FINAL을 먼저 확인하세요. Proxy에서도 실패한다면 선택한 서버의 매개변수, 인증, 네트워크 연결과 대상 자체를 다시 점검해야 합니다. Direct에서는 접속되지만 Config에서 문제가 생긴다고 해서 Direct를 계속 사용해야 한다는 뜻은 아닙니다. 해당 요청에 적용되는 규칙을 찾아보세요. 세 가지 라우팅 방식의 비교는 문제 진단 방법이지, 모든 네트워크 환경에 일률적으로 권장하는 설정이 아닙니다. 테스트가 끝나면 필요한 방식으로 되돌리고 자주 사용하는 대상을 다시 확인하세요.

구성 파일에는 규칙 외에도 DNS 관련 설정이 포함될 수 있습니다. 요청 결과는 도메인 해석, IP 규칙, 라우팅 방식과 대상 서비스의 영향을 함께 받을 수 있습니다. 테스트 웹사이트의 단일 결과를 Config 전체가 올바르다는 증거로 간주하지 마세요. 용어를 더 알아보려면 용어집을, DNS 설정을 확인하려면 DNS 설정 안내를 참고하세요.

연결 과정을 관찰 가능한 단계로 나누세요

연결을 시작하기 전에 SERVER에서 본인이 보유한 서버를 하나 선택하고, Global Routing이 방금 결정한 방식으로 설정되어 있는지 확인한 다음 Home의 스위치를 조작하세요. 이후 시스템 권한 허용 여부, 앱 상태가 Not Connected에서 바뀌었는지, 기기에 해당 네트워크 상태가 표시되는지, Connectivity Test 결과가 있는지, 실제 대상에 예상대로 접속되는지를 순서대로 확인합니다. 각 항목은 서로를 대신할 수 없습니다. 스위치가 켜져 있어도 서버 인증에 성공했다는 보장은 없으며, 한 주소의 테스트에 성공해도 모든 도메인에 같은 규칙이 적용된다는 뜻은 아닙니다.

Connectivity Test는 빠르게 결과를 비교할 때 유용하지만, 테스트 대상, 현재 네트워크와 라우팅 설정에 따라 결과가 달라집니다. 테스트가 한 번 실패하면 먼저 기기 자체가 인터넷에 연결되어 있는지 확인한 다음 테스트하려는 서버가 선택되어 있는지 살펴보세요. Subscribe를 최근에 업데이트했다면 특히 선택된 항목을 다시 확인해야 합니다. 이어서 현재 방식이 Config, Proxy, Direct 중 무엇인지 확인하고 동일한 대상을 다시 테스트하세요. 매번 네트워크와 대상을 바꾸지 마세요. ‘라우팅 방식, 선택한 항목, 테스트 대상, 관찰된 현상’을 기록하면 단순히 ‘연결되지 않음’이라고 적는 것보다 원인을 찾기 쉽습니다.

현상에 따라 나누어 점검하기

연결을 시작할 수 없다면 규칙을 급히 바꾸기보다 시스템 VPN 구성 권한과 Home 상태를 먼저 확인하세요. 연결됨으로 표시되지만 대상에 접속할 수 없다면 해당 대상이 Config의 REJECT 또는 DIRECT 규칙에 해당하는지 판단한 다음 PROXY가 사용하는 서버를 점검하세요. 일부 도메인만 문제가 있다면 해당 DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD 규칙과 DNS를 집중적으로 확인하세요. 모든 대상에 문제가 있다면 기기의 기본 네트워크 연결, 서버 항목, 인증 정보와 선택된 항목을 먼저 확인하는 것이 좋습니다. 대상 웹사이트 자체가 일시적으로 중단되었을 수도 있으므로, 익숙한 대상을 여러 개 선택해 교차 확인하세요.

기존 서버의 매개변수를 확인해야 한다면 처음 받은 정보와 대조하세요. 프로토콜, 포트와 보안 설정을 무작위로 바꾸지 마세요. 주소가 정상적으로 확인되는데도 연결에 실패한다면 인증이나 전송 매개변수가 원인일 수 있습니다. 구독은 업데이트되지만 서버를 사용할 수 없는 경우도 정보 가져오기에 성공했다는 뜻일 뿐, 서버 테스트를 생략할 수는 없습니다. 반대로 개별 서버는 사용 가능하지만 구독 업데이트에 실패한다면 구독 URL이 완전한지, 접속 가능한지 확인하세요. ‘설정 정보 가져오기’, ‘연결 설정하기’, ‘대상에 접속하기’를 서로 다른 단계로 나누어야 같은 점검을 반복하지 않습니다.

연결이 안정된 뒤 장기 사용 상태를 확인하세요

처음 대상에 접속된 뒤에도 평소 사용하는 상황을 몇 차례 더 테스트하세요. 확인된 네트워크 사이를 이동하거나, 화면을 잠갔다가 다시 잠금 해제하거나, 구독을 업데이트한 뒤 항목을 다시 선택해 보세요. 네트워크를 바꾸면 DNS, 사용 가능한 경로 또는 연결 유지 상태가 달라질 수 있으므로 한 번 성공했다고 이후 모든 환경에서 확인이 필요 없는 것은 아닙니다. 평소 On Demand를 사용한다면 작동 조건을 먼저 파악한 뒤 테스트에 포함하세요. 그렇지 않으면 자동 연결이 수동 스위치 테스트에 영향을 줄 수 있습니다. On Demand와 백그라운드 사용에 관한 내용은 요청 시 연결 및 배터리 문제 해결을 참고하세요.

검증의 기준은 특정 상태 표시등이 켜지는 것이 아닙니다. PROXY를 사용하도록 설정한 대상에 예상대로 접속되고, DIRECT를 사용하도록 설정한 대상도 정상적으로 작동하며, 일상적으로 사용하는 Config로 돌아왔을 때도 결과가 일관되어야 합니다. 이런 조건이 갖춰져야 Data의 수치를 올바르게 해석할 수 있습니다. 문제가 위의 점검 항목에 해당하지 않는다면 빠른 시작 안내로 돌아가 입력, 선택과 스위치 조작 순서를 다시 확인하세요. 상태를 모르는 채 설정 변경을 계속 쌓지 않는 것이 좋습니다.

먼저 통계 범위를 파악하세요

Data에서는 앱에 표시되는 트래픽 정보를 확인할 수 있습니다. 페이지를 열기 전에 현재 연결 상태, 선택한 서버와 Global Routing을 기록한 뒤 수치를 살펴보세요. 숫자의 변화는 이 조건을 바탕으로 이해해야 합니다. 일부 요청은 DIRECT로 처리될 수 있고, 일부 요청은 REJECT될 수 있습니다. 기기의 다른 활동, 백그라운드 새로 고침과 이전 연결도 관찰 시간대의 수치에 영향을 줄 수 있으므로, 바로 앞에서 연 페이지의 트래픽만 반영한다고 볼 수는 없습니다. Data의 전체 수치를 특정 웹사이트의 사용량으로 단정하거나 앱 내 통계와 통신사 청구량의 측정 기준이 완전히 같다고 가정하지 마세요.

데이터를 비교하기 전에 관찰 시작점과 종료 시점을 정하세요. 현재 수치를 확인한 뒤 익숙한 대상을 방문하고 Data로 돌아와 변화를 살펴볼 수 있습니다. 그사이에 네트워크, 서버 또는 라우팅 방식을 바꿨다면 그 내용도 기록하세요. 화면에 따라 연결, 항목 또는 시간 범위별로 정보가 표시될 수 있으니 비교하기 전에 페이지 레이블을 확인하세요. 실제로 제공되는 필터와 초기화 메뉴는 현재 앱에 표시되는 내용을 기준으로 하세요. 다른 사람의 스크린샷만 보고 내 화면에도 같은 버튼이 있다고 추측하지 마세요.

통계는 참고 자료로 활용하고 연결 테스트를 대신하지 마세요

트래픽이 증가했다면 관찰 범위에 관련 데이터 활동이 있었다는 뜻이지만, 대상 콘텐츠가 올바르게 로드되었거나 모든 요청이 PROXY를 통과했다는 증거는 아닙니다. Data가 바로 바뀌지 않는다면 연결이 유지되는지, 요청이 실제로 발생했는지, 현재 필터 범위가 테스트 시간을 포함하는지 확인한 다음 Home과 Connectivity Test를 살펴보세요. 특히 Config 방식에서는 같은 앱이 보낸 요청도 서로 다른 규칙에 해당할 수 있으므로 누적 수치 하나만으로 각 요청의 경로를 파악하기는 어렵습니다. 특정 대상의 상태를 확인하려면 라우팅 규칙, 연결 상태와 대상의 실제 동작을 함께 살펴보세요.

트래픽이 예상보다 많아 보인다면 모든 기능을 한꺼번에 끄기보다 반복 가능한 작은 범위로 관찰하세요. 시작할 때 수치를 기록하고 현재 진행 중인 대용량 작업을 멈춘 뒤 평소와 같은 네트워크 사용 방식으로 일정 시간 확인합니다. 백그라운드에서만 계속 증가한다면 시스템의 배터리 및 네트워크 사용 정보를 비교하고, On Demand처럼 연결 시점에 영향을 줄 수 있는 설정이 활성화되어 있는지 살펴보세요. 두 통계는 범위와 계산 방식이 다를 수 있으므로 차이가 있다고 바로 앱 오류로 단정할 필요는 없습니다. 단위, 시간 범위와 백그라운드 활동 포함 여부를 먼저 확인한 다음 설정을 조정할지 결정하세요.

나중에 다시 확인할 수 있도록 기록하세요

서비스 제공자에게 연결 정보 문제를 문의할 때는 네트워크 유형, 선택한 프로토콜, 연결 시각과 재현 가능한 현상만 설명하면 됩니다. 전체 구독 URL, 비밀번호 또는 키를 첨부하지 마세요. Data 스크린샷에 계정, 서버 메모 또는 기타 개인정보가 포함되어 있는지도 확인하세요. 규칙 때문에 예상과 다른 경로로 트래픽이 이동한다고 의심되면 통계만 초기화하지 말고 Config에서 처리 정책을 하나씩 살펴보세요. 초기화는 관찰 시작점만 바꿀 뿐 라우팅 로직을 수정하지 않습니다.

Data는 ‘알려진 조건에서 트래픽이 변했는지, 조작과 대략 일치하는지’를 확인하는 데 적합합니다. ‘서버 인증이 실패한 이유’, ‘특정 도메인이 어떤 규칙에 해당했는지’, ‘스토어 구매가 성공했는지’를 단독으로 확인하는 도구는 아닙니다. 앞의 두 문제는 연결 및 Global Routing 섹션에서, 구매 문제는 구입한 앱 복원 안내에서 확인하세요. 도구의 용도를 명확히 이해해야 통계 수치를 새로운 오판의 원인이 아닌 문제 해결의 단서로 활용할 수 있습니다.

먼저 정상 작동 기준을 보존하세요

Settings에는 사용 방식과 연결 동작에 영향을 주는 옵션이 모여 있지만, 처음 연결에 성공한 뒤 모든 항목을 바꿀 필요는 없습니다. 먼저 정상 작동을 확인한 기준을 기록하세요. 선택한 SERVER, Global Routing, 현재 Config, On Demand 사용 여부가 여기에 해당합니다. 이후 명확한 문제에 관련된 설정만 조정하고, 한 번에 한 항목만 변경한 뒤 같은 테스트 대상에 다시 접속하세요. 결과가 나빠졌을 때 어떤 항목을 되돌려야 하는지 알 수 있어 여러 스위치를 바꾼 뒤 원인을 추측할 필요가 없습니다. 기기와 앱 화면에 따라 표시되는 항목이 다를 수 있으므로 이름과 사용 가능 여부는 실제 화면을 기준으로 하세요.

On Demand는 설정한 조건에 따라 언제 연결할지 정하는 기능이지, 특정 서버의 속도를 높이는 버튼이 아닙니다. 특정 네트워크에서 자동 연결이 필요하다면 먼저 작동 조건과 예외 상황을 확인한 뒤 해당 구성을 활성화하세요. 네트워크에 연결하거나 연결을 끊을 때, 기기 잠금을 해제할 때의 상태를 관찰해 보세요. 수동 연결 문제를 점검하는 중이라면 테스트 조건을 단순하게 유지해 자동 동작이 방금 조작한 스위치를 덮어쓰지 않도록 하세요. 백그라운드 활동이나 배터리 사용이 걱정된다면 시스템의 배터리 사용 정보를 먼저 확인하고 연결 빈도와 함께 판단하세요. 앱이 연결 상태를 유지한다는 사실만으로 원인을 단정할 수 없습니다.

DNS와 라우팅 규칙을 구분하세요

DNS는 도메인을 이후 연결에 필요한 정보로 변환하고, Global Routing과 Config 규칙은 요청을 어떻게 처리할지 정합니다. 두 기능은 서로 관련되어 있지만 같은 설정은 아닙니다. 시스템 DNS, 사용자 지정 DNS와 DNS over HTTPS는 각각 적합한 사용 상황이 다릅니다. DNS 방식을 바꾼 뒤에는 문제가 있었던 도메인을 다시 테스트하고, 해당 문제의 영향을 받지 않는 비교 대상도 하나 남겨 두세요. 서버 인증 정보가 잘못된 문제라면 DNS를 바꿔도 보통 해결되지 않습니다. 일부 도메인에만 문제가 있다면 DNS 응답과 규칙 일치 여부를 함께 확인할 수 있습니다.

Config에서 dns-server 등의 항목을 발견하면 먼저 편집 중인 구성이 맞는지, 변경 후 해당 구성이 실제로 활성화되었는지 확인하세요. 문서의 예시 주소를 모든 네트워크에 적용되는 기본값으로 사용하지 마세요. 기존 값을 기록하고 하나만 변경한 뒤 저장, 재테스트하고 관련 연결을 새로 고쳐야 하는지 확인하면 설정 변경을 제대로 검증할 수 있습니다. 세 가지 DNS 방식과 테스트 절차는 DNS 설정 안내를 참고하세요. 보유한 정보에서 가져온 Config라면 수정 전에 이후 업데이트가 로컬 변경 사항을 덮어쓸 가능성도 고려해야 합니다.

설정과 기기 간 차이 확인하기

같은 연결 정보를 iPhone과 iPad에 사용하더라도 각 기기의 Settings가 완전히 같지는 않을 수 있습니다. 시스템 네트워크, 권한 상태, 선택한 Config와 로컬 설정을 기기별로 확인해야 합니다. Import from Cloud JSON 같은 가져오기 메뉴는 해당 형식의 자료를 실제로 보유한 경우에만 사용하세요. 일반 구독 URL을 대신 넣어서는 안 됩니다. 가져온 뒤에는 내용을 확인하고 사용할지 결정하세요. 출처가 분명하지 않은 구성으로 현재 정상 작동하는 설정을 바로 덮어쓰지 않는 것이 좋습니다.

설정을 관리할 때는 세 가지 질문에 먼저 답하세요. 어떤 현상을 바꾸려는지, 어떤 옵션이 그 현상에 직접 영향을 줄 수 있는지, 변경이 효과가 있었는지 어떻게 확인할지입니다. 답을 정할 수 없다면 검증된 기준 설정을 유지하세요. Settings는 모든 항목을 동일한 상태로 맞추는 곳이 아니라 필요에 따라 동작을 세밀하게 조정하는 메뉴입니다. 인터페이스의 영어 용어와 규칙 키워드는 용어집을 함께 참고하세요. 설정을 마친 뒤에는 연결 섹션의 방법에 따라 실제 대상에 접속해 확인하세요.

업데이트를 두 종류로 구분하세요

일상적으로 관리할 때는 앱 업데이트와 연결 정보 업데이트를 구분해야 합니다. Shadowrocket 자체는 App Store에서 업데이트합니다. 스토어 페이지에서 앱 정보, 호환성과 업데이트 기록을 확인할 수 있습니다. Subscribe 업데이트는 앱이 보유 중인 구독 URL에서 설정 내용을 다시 가져오는 작업입니다. 두 작업의 이름에 모두 ‘업데이트’가 들어간다고 해서 자동으로 동기화되는 것은 아닙니다. 새 항목이 나타나지 않으면 먼저 구독 업데이트와 SERVER를 확인하세요. 앱 기능이나 인터페이스 설명이 안내와 다르면 App Store 페이지와 앱에 표시된 문구를 확인하세요. 서버 목록 변화로 앱 버전을 추측하거나 앱 업데이트만으로 구독 정보까지 새로 고쳐졌다고 판단하지 마세요.

기기를 바꿀 때는 먼저 App Store 구입 기록과 새 기기에서 사용할 수 있는 구매 계정을 확인하세요. 그런 다음 사용 권한이 있는 구독 URL, 직접 입력에 필요한 항목, 개인 Config 수정 사항과 필요한 메모를 정리합니다. 비공개 정보는 본인이 관리하는 안전한 장소에 보관하고 전체 URL이나 키를 공개 게시판에 올리지 마세요. 새 기기에서 앱을 받은 다음 ‘권한 → 가져오기 → 서버 선택 → Global Routing → 테스트’ 순서로 다시 확인하세요. 두 기기에서 같은 구매 계정을 사용하더라도 각 기기에 실제로 어떤 항목이 있는지, 현재 어떤 구성이 선택되어 있는지 따로 확인해야 합니다. 구매 상태만으로 앱 데이터를 확인할 수는 없습니다.

문제 재검토에 필요한 정보만 기록하세요

문제를 나중에 검토할 수 있도록 대략적인 발생 시각, iPhone 또는 iPad, 현재 네트워크 유형, 연결 전후의 Home 상태, 선택한 프로토콜과 서버 메모, Global Routing 방식, 테스트 대상 및 결과를 기록하세요. 설정을 변경한 뒤 문제가 생겼다면 방금 바꾼 항목도 적어 두세요. 메모는 항목을 구분하는 용도로만 사용하고 비밀번호, 키 또는 전체 구독 주소를 기록하지 마세요. 한 번 재현한 다음 조건 하나만 바꿔 다시 테스트하세요. 결과가 달라졌다면 해당 경로를 따라 확인합니다. 여러 항목을 동시에 바꾸면 다음에 같은 문제가 생겼을 때 해결하기 더 어려워집니다.

정해진 점검 순서로 문제를 정리할 수 있습니다. 앱이 정상적으로 열리는가? SERVER에 필요한 항목이 있는가? 시스템 VPN 구성 권한을 확인했는가? 연결 상태가 바뀌는가? Proxy에서 선택한 서버를 사용할 수 있는가? Config에서 대상이 어떤 규칙에 해당하는가? 알려진 테스트에서 Data가 변하는가? 각 질문은 이 문서의 앞선 단계와 연결됩니다. 구독 업데이트가 되지 않는다면 먼저 DNS와 모든 규칙을 바꿀 필요는 없습니다. 특정 도메인만 실패한다면 앱을 다시 설치할 필요도 없습니다. 문제 발생 단계를 좁힌 다음 해당 단계의 매개변수와 예외 상황을 확인하세요.

자주 초기화하기보다 주기적으로 확인하세요

정기적으로 App Store 제품 페이지, 저장해 둔 원본 정보의 유효성, 현재 Config에서 자주 사용하는 대상이 예상대로 작동하는지 확인할 수 있습니다. 네트워크 환경이 바뀌면 먼저 간단한 테스트를 반복한 뒤 On Demand나 DNS를 조정할지 결정하세요. 규칙에 사용하는 도메인과 주소 범위, 개인의 사용 목적은 바뀔 수 있으므로 과거에 유효했던 규칙이 계속 적용된다고 볼 수 없습니다. 설정을 변경할 때마다 이전 구성으로 복원할 수 있도록 보관하세요. 목록 비우기, 통계 초기화 또는 모든 정보 다시 가져오기는 목적과 백업 범위를 명확히 한 뒤 실행해야 합니다. 테스트 한 번이 실패했을 때 기본적으로 먼저 할 일은 아닙니다.

이 설명서는 특정한 ‘완료’ 버튼을 누르는 것으로 끝나지 않습니다. App Store에서 제품을 확인하고 권한과 보유한 정보를 점검한 다음, Global Routing에서 경로를 선택하고 연결을 테스트하며 Data로 상태를 살펴보고 Settings에서는 목적이 분명한 항목만 변경하는 과정을 반복해서 사용할 수 있어야 합니다. 간단한 절차를 다시 진행하려면 빠른 시작 안내로 돌아가세요. 구매와 기기 조건을 확인하려면 App Store 앱 확인 안내를 참고하세요. 조작 위치는 App Store 페이지와 앱에 현재 표시되는 문구를 기준으로 이 설명서와 대조하세요.