Shadowrocket
사용법 완벽 가이드

App Store 구입 및 정품 확인

먼저 App Store 정품 확인 페이지에서 앱 이름, 개발자, 앱 ID를 대조한 다음 App Store에서 구입하세요. Shadowrocket은 Apple 플랫폼에서 제공되는 유료 상용 폐쇄형 앱이며, 유일한 구입 경로는 App Store입니다. 아래 설명은 주로 iPhone과 iPad를 기준으로 합니다. Mac, Apple TV, Apple Vision의 호환성, 시스템 요구 사항, 통합 구입 적용 여부는 App Store 페이지의 안내를 따르세요. 기기 이름만으로 사용 가능 여부를 판단하지 마세요.

구입 전 확인할 세 가지 항목

제품 페이지에서 먼저 앱 이름이 Shadowrocket인지 확인하고, 이어서 아이콘이 이 사이트에서 사용하는 공식 아이콘과 일치하는지 살펴본 다음 개발자 정보를 확인하세요. 개발자는 Shadow Launch Technology Limited여야 합니다. 검색 결과에는 이름이 비슷한 앱이 표시될 수 있으므로 한글 별칭이나 검색 순위만으로 확인하지 마세요. 이름은 앱을 식별하는 데 도움이 되며, 개발자와 앱 ID까지 확인해야 어떤 제품을 보고 있는지 더 정확히 판단할 수 있습니다.

App Store 제품 링크에서 id932747118을 확인하세요. 숫자 932747118은 앱 ID이며 구입 증명이나 현재 버전이 아닙니다. 공유된 제품 주소에서도 이 ID로 같은 앱을 찾을 수 있습니다. 링크를 열었을 때 다른 제품이 표시되면 구입을 중단하고 확인 페이지에서 다시 여세요. 비슷한 아이콘이나 설명의 키워드, 다른 사람의 말을 확인 절차 대신 사용하지 마세요.

구입 항목과 기기 조건 확인

가격 버튼 근처에서 현재 스토어의 금액을 확인한 뒤 시스템의 구입 확인 절차를 진행하세요. 미국 스토어 가격은 약 2.99달러이며 일회성 구입입니다. 실제 금액, 세금, 통화 표시는 App Store 페이지를 따릅니다. 구입 대상은 앱 사용 권한이지 서버 계정이 아닙니다. 앱 일회성 구입 ≠ 연결 서비스 요금제입니다. 이후 연결하려면 사용자가 이미 보유한 구독 정보나 서버 정보가 필요합니다. 이 사이트는 해당 정보를 사용하는 방법만 안내하며 연결 서비스는 제공하지 않습니다.

호환성 항목에서 현재 기기와 시스템으로 설치할 수 있는지 확인하세요. 시스템 요구 사항은 App Store 페이지의 안내를 따르며, 오래된 가이드에 적힌 시스템 버전으로 현재 사용 가능 여부를 판단하지 마세요. 스토어에서 구입을 완료할 수 없다면 먼저 계정 상태, 결제 수단, 스토어 이용 가능 여부를 확인하세요. 이는 스토어 결제 단계의 문제이며 앱의 Address, Port, 라우팅 규칙과는 무관합니다. 이때 서버 매개변수를 수정해도 구입 결과는 달라지지 않습니다.

설치 후 복원에 필요한 정보 보관

설치가 끝나면 홈 화면에서 Shadowrocket을 열어 정상적으로 실행되는지 확인한 뒤 설정을 가져오세요. 구입 내역은 App Store 계정에 연결되므로 기기를 바꾸거나 재설치할 때는 동일한 구입 계정의 구입 항목에서 앱을 찾으세요. 가족 공유 지원 여부, 기기 간 적용 범위, 구체적인 복원 조건은 App Store 페이지와 계정에 실제로 표시되는 내용을 따릅니다. 한 기기에 설치가 됐다고 해서 모든 기기에서 바로 사용할 수 있다고 단정하지 마세요.

복원할 때는 구입 권한과 앱 데이터를 구분하세요. 구입 내역을 통해 앱을 다시 받을 수는 있지만 서버 목록, 구독 주소, 규칙 수정 사항, 개인 키까지 복원되는 것은 아닙니다. 앱이 다시 설치된 뒤에도 이러한 항목을 하나씩 확인해야 합니다. 앱만 복원되고 설정이 없는 경우 Home에 사용할 수 있는 서버가 표시되지 않는 것은 정상적인 준비 단계이며, 구입이 취소된 것이 아닙니다. 설정 백업과 이전 방법은 유지 관리 장에서 별도로 설명합니다.

첫 실행 및 VPN 구성 권한

Shadowrocket을 처음 열면 먼저 Home, Config, Data, Settings의 위치를 확인한 다음 가져오기와 연결을 진행하세요. Home에서는 서버 확인, 항목 선택, 연결 제어를 주로 수행합니다. Config에서는 라우팅 설정을 관리하고, Data에서는 트래픽과 요청 기록을 확인하며, Settings에는 실행 옵션이 모여 있습니다. 기기에 따라 화면 배치가 다를 수 있으므로 영어 인터페이스 용어를 기준으로 찾고 버튼의 고정된 화면 위치에 의존하지 마세요.

첫 연결 시 시스템 팝업 처리

Home에서 연결 스위치를 켜면 시스템에서 VPN 구성을 추가하도록 요청할 수 있습니다. 팝업에 Shadowrocket이 표시되는지 확인한 뒤 시스템 안내에 따라 허용하고 기기 인증을 완료하세요. 이 권한은 시스템 네트워크 확장 구성을 만들어 클라이언트가 현재 모드에 따라 터널로 들어가는 트래픽을 처리하도록 합니다. 서비스 제공자에게 연결 권한을 구입하는 절차도 아니며, 서버 매개변수가 원격 서버에서 검증되었다는 뜻도 아닙니다.

당시에 거부를 선택했다면 앱으로 돌아가 연결을 다시 시도하고 권한 요청이 다시 표시되는지 확인하세요. 계속 진행할 수 없다면 시스템 Settings에서 VPN 관련 구성을 찾아 해당 항목이 있는지 또는 관리 제한이 적용되는지 확인하세요. 시스템 설정의 구체적인 위치는 기기 환경에 따라 다르므로 실제 화면에 표시된 이름을 기준으로 찾으면 됩니다. 용도를 모르는 네트워크 구성을 한꺼번에 삭제하지 마세요. 특히 기기에 업무용 연결이 남아 있다면 주의해야 합니다.

구성 추가를 허용한 다음 Home에서 연결 상태를 확인하세요. 시스템 권한을 허용하면 이 기기에서 네트워크 확장을 사용할 수 있게 되지만 Address, Password, SNI 등의 항목이 자동으로 수정되지는 않습니다. 권한을 허용했는데도 연결에 실패한다면 권한을 반복해서 취소하기보다 다음 단계의 매개변수와 네트워크 문제를 점검하세요. 시스템 권한과 원격 인증을 구분하면 잘못된 단계에서 같은 작업을 반복하지 않을 수 있습니다.

필요한 권한과 선택 기능 구분

Scan QR Code로 사용자가 보유한 서버 QR 코드를 스캔할 때 앱에서 카메라 접근을 요청할 수 있습니다. 스캔 기능을 사용할 때만 이 권한이 필요하며, 기존 링크를 직접 입력하거나 붙여넣는 데 카메라는 필요하지 않습니다. 스캔 결과를 저장하기 전에 프로토콜 종류와 주요 항목을 확인하세요. QR 코드에는 서버 인증 정보가 포함될 수 있으므로 원본 이미지를 공개 사진 앨범에 저장하거나 문의 글에 그대로 올리지 마세요.

클립보드에서 가져올 때 시스템에서 붙여넣기 접근을 안내할 수 있습니다. 먼저 방금 복사한 내용이 실제로 사용자가 보유한 설정 정보인지 확인한 뒤 이번 접근을 허용하세요. 일반 웹페이지 주소가 구독 주소인 것은 아니며, 설명문 전체를 복사하면 인식되지 않을 수 있습니다. 파싱에 실패하면 원본 정보로 돌아가 전체 링크만 복사하세요. 필요한 문장 부호와 인코딩은 유지하고, 형식을 모르는 상태에서 끝부분 문자를 임의로 삭제하지 마세요.

기기의 현재 네트워크 연결 상태 확인

처음 연결을 확인하기 전에 기기가 현재 Wi-Fi 또는 셀룰러 네트워크에 정상적으로 접속되는지 확인하세요. Wi-Fi에 웹 인증이 필요하다면 Shadowrocket 연결을 켜기 전에 인증을 완료한 뒤 앱으로 돌아와 조작하세요. 기본 네트워크가 연결되지 않은 상태에서는 클라이언트의 서버 테스트도 실패합니다. 이 순서로 점검하면 기기의 네트워크 접속 문제와 서버 문제를 구분해 모든 시간 초과를 같은 구독 정보 탓으로 돌리지 않을 수 있습니다.

기기에 다른 VPN 구성이 있다면 현재 실제로 활성화된 구성이 무엇인지 먼저 확인하세요. 네트워크를 제어하는 구성이 여러 개면 서로 영향을 줄 수 있으므로 문제를 점검할 때는 이번 테스트에 필요한 연결 상태만 유지하세요. 조직에서 관리하는 기기에는 별도 제한이 있을 수 있으니 관리 지침을 따르고 모르는 정책을 수정하지 마세요. 시스템의 VPN 표시는 터널이 실행 중이라는 단서일 뿐, 실제 사용 가능 여부는 앱 상태와 요청 결과를 함께 살펴봐야 합니다.

첫 테스트에서는 On Demand를 켜지 말고 수동 스위치로 연결과 연결 해제를 한 번씩 명확히 확인하세요. 그렇지 않으면 네트워크 조건이 바뀌며 자동 연결이 실행되어 스위치 조작이 반영되지 않은 것으로 오해할 수 있습니다. 수동 연결이 안정된 뒤 Settings에서 자동 동작을 하나씩 설정하세요. 이렇게 하면 상태가 바뀐 이유를 파악하기 쉬워지고 이후 자동 재연결 문제도 더 쉽게 진단할 수 있습니다.

기존 서버 및 구독 추가

먼저 사용자가 보유한 정보가 단일 서버 매개변수인지, 서버 공유 링크인지, 구독 주소인지, 라우팅 구성 파일인지 확인한 다음 적절한 가져오기 경로를 선택하세요. 각 항목의 용도는 서로 다릅니다. 서버 정보는 원격 서버에 연결하는 방법을 설명하고, 구독은 서버 목록을 업데이트하며, 구성 파일은 라우팅과 기타 실행 설정을 정의합니다. 규칙 파일을 구독으로 가져오거나 제품 소개 웹페이지를 서버 링크로 붙여넣으면 연결 가능한 항목이 아니라 파싱 오류가 발생할 수 있습니다.

Add Server에서 항목 확인

Home의 Add Server에서 Type을 선택한 다음 원본 정보에 따라 Address와 Port를 입력하세요. Address는 보통 도메인이나 IP 주소이며 임의로 웹 경로를 덧붙이면 안 됩니다. Port는 서버가 연결을 수신하는 포트이지 프로토콜 이름이 아닙니다. 다음으로 해당 유형에 필요한 Password, UUID, 키 등의 인증 정보를 입력하세요. Type을 잘못 선택하면 입력 양식이 맞지 않아 주소와 포트가 정확해도 의도한 핸드셰이크를 완료할 수 없습니다.

TLS를 사용하는 경우 서비스 제공자의 안내에 따라 SNI와 인증서 조건을 확인하세요. Address는 연결 대상이며, SNI는 TLS 핸드셰이크에서 서버 이름을 식별하는 데 사용됩니다. 둘은 같을 수도, 다를 수도 있으므로 무조건 같은 값을 복사하지 마세요. 인증서 오류가 발생하면 이름, 기기의 시간, 서버 인증서를 확인하세요. Allow Insecure를 일반적인 해결 방법으로 사용하지 마세요. 자세한 항목은 Trojan 매개변수 안내를 참고하세요.

Subscribe 및 링크로 가져오기

구독 주소가 있다면 현재 화면의 Subscribe 또는 구독 추가 메뉴에 전체 주소를 붙여넣고 알아보기 쉬운 이름을 지정한 다음 업데이트하세요. Config 페이지의 원격 구성 메뉴는 라우팅 구성 주소를 받을 수도 있으므로 가져오기 전에 대상 유형을 확인해야 합니다. 둘 다 URL을 입력할 수 있다고 해서 서로 바꿔 사용할 수 있는 것은 아닙니다. 가져온 뒤 예상한 서버나 구성 항목이 표시되는지 확인하세요. 웹페이지 내용만 표시된다면 실제 리소스 주소가 아니라 소개 페이지를 복사했는지 확인하세요.

구독 주소의 쿼리 매개변수는 사용자 식별에 사용되는 경우가 많으므로 대소문자, 인코딩, 마지막 문자가 중요할 수 있습니다. 먼저 복사 과정에서 섞인 공백과 줄바꿈을 제거하고 주소가 완전한지 확인하세요. 링크를 짧게 만들려고 매개변수를 삭제하지 마세요. 업데이트가 실패하면 도메인 이름 확인 실패, 요청 시간 초과, 인증 거부, 콘텐츠 파싱 실패 중 어느 경우인지 기록하세요. 원인에 따라 점검 단계가 다르며, 같은 주소를 반복해서 추가하면 중복 그룹만 생길 수 있습니다.

개별 공유 링크는 앱에서 지원하는 링크 인식, 클립보드 또는 Scan QR Code로 가져올 수 있습니다. 가져온 뒤 항목 상세 화면을 열어 Type, Address, Port, 인증 정보가 빠짐없이 인식되었는지 확인하세요. 자동 인식은 직접 입력을 줄여 줄 뿐, 모든 선택 매개변수가 현재 서버 요구 사항에 맞는다는 뜻은 아닙니다. 가져오기 경로별 조작 방법은 구독 및 서버 가져오기 방법 안내를 참고하세요.

저장 후 관리하기 쉬운 목록 만들기

목록에서 방금 저장한 서버를 선택하고 선택 표시가 대상 항목으로 실제 이동했는지 확인한 뒤 테스트하세요. 메모에는 용도나 출처를 적고 비밀번호는 이름에 넣지 않는 것이 좋습니다. 구독으로 생성된 항목과 직접 추가한 항목을 구분해 두세요. 구독을 업데이트하면 일부 항목이 다시 생성될 수 있어 생성된 항목을 직접 수정해도 계속 유지되지 않을 수 있습니다. 장기간 유지해야 하는 변경 사항은 앱에서 덮어쓰기 방지나 별도 저장을 지원하는지 먼저 확인하세요.

처음 가져올 때는 출처가 분명한 항목 하나만 유지하고 내용이 불분명한 구성을 여러 개 한꺼번에 가져오지 마세요. 서비스 제공자가 일부 항목만 알려줬다면 원본 정보 제공자에게 확인하고 인증 유형이나 포트를 추측하지 마세요. 이 사이트는 서버나 구독을 제공·판매·추천하지 않습니다. 이 장을 마칠 때 현재 사용하는 서버 항목, 그 정보의 출처, 다음 업데이트 경로를 설명할 수 있어야 합니다.

Global Routing 세 가지 모드와 규칙 순서

Home에서 Global Routing을 열고 현재 Config, Proxy, Direct 중 무엇이 선택되어 있는지 확인하세요. 세 모드는 각각 구성, 프록시, 직접 연결 방식에 해당하며 트래픽 처리 방법을 결정합니다. 서로 다른 서버 세 개를 뜻하는 것은 아닙니다. 서버를 선택하면 “프록시 연결에 어떤 서버를 사용할지” 정하고, Global Routing을 선택하면 “각 요청을 어떤 방식으로 처리할지” 정합니다. 이 두 단계를 구분해야 같은 서버를 사용해도 사이트마다 결과가 달라지는 이유를 설명할 수 있습니다.

활성 Config 확인

Config 페이지에서 현재 활성화된 구성을 확인하고, 필요하면 파일 이름만 보지 말고 내용을 직접 살펴보세요. 목록에 파일이 있다고 해서 현재 적용 중인 것은 아닙니다. Config 모드에서는 규칙이 보통 위에서 아래 순서로 일치하며, 먼저 일치한 규칙이 처리 방식을 결정합니다. 따라서 구체적인 조건을 더 넓은 조건보다 앞에 두고, FINAL은 마지막 기본 처리 규칙으로 남겨 뒤쪽 규칙이 실행될 기회가 사라지지 않도록 하세요.

다음은 문법 설명을 위한 .conf 규칙 예시이며 서버 매개변수가 포함된 완전한 구성 파일이 아닙니다. example.com은 예시용 도메인이고 PROXY는 프록시 정책 참조를 뜻하므로 실제 구성에서 해당 정책을 확인할 수 있어야 합니다. 이 줄만 복사해도 서버가 생기거나 기존 서버와 자동으로 연결되지는 않습니다. 먼저 현재 내용을 백업한 다음 실제 구성 구조에 맞게 조정하세요.

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

매칭 조건과 처리 방식 이해하기

DOMAIN은 지정된 전체 도메인과 일치하고, DOMAIN-SUFFIX는 도메인 접미사와 하위 도메인에 일치하며, DOMAIN-KEYWORD는 도메인에 포함된 키워드로 일치 여부를 판단합니다. 마지막 방식은 적용 범위가 넓으므로 독특해 보이는 단어 하나만 보고 오매칭이 없을 것이라고 판단하지 마세요. IP-CIDR과 IP-CIDR6은 주소 대역으로 매칭합니다. 입력할 때 접두사 길이를 유지하세요. IP 대역 매칭은 도메인을 기준으로 판단하는 조건과 다릅니다.

GEOIP는 IP 위치 데이터에 따라 매칭하며 웹사이트의 언어나 운영 주체를 판단하는 규칙이 아닙니다. 하나의 웹사이트가 여러 분산 주소를 통해 콘텐츠를 제공할 수 있으므로 페이지 문구가 같다는 이유만으로 모든 요청이 같은 지역으로 연결된다고 추정할 수 없습니다. DIRECT는 직접 연결, REJECT는 요청 거부를 뜻합니다. 다른 정책 이름은 구성에서 실제 정의를 확인할 수 있어야 합니다. FINAL은 “모든 규칙을 다시 확인”하는 것이 아니라 앞선 규칙이 하나도 일치하지 않을 때 적용되는 마지막 처리 방식입니다.

비교 테스트로 규칙 문제 찾기

Proxy에서는 정상인데 Config에서 특정 대상에 문제가 생기면 먼저 해당 요청에 적용된 규칙과 정책을 기록한 뒤 순서와 조건을 확인하세요. 프록시 경로가 이미 비교 기준이 되므로 모든 서버를 바로 바꾸지 마세요. 반대로 Proxy에서도 실패한다면 서버, 인증, TLS, 네트워크 조건을 먼저 점검하세요. Direct에서 접속되는지 여부는 직접 연결 경로의 결과만 보여 줄 뿐 프록시 매개변수가 올바르다는 증거는 아닙니다.

규칙을 수정할 때는 한 번에 한 항목만 바꾸고 저장한 뒤 현재 화면의 안내에 따라 구성을 적용한 다음 대상 요청을 다시 실행하세요. 기존의 장시간 연결은 이전 경로를 계속 사용할 수 있고 브라우저 페이지에는 캐시가 남을 수 있으므로 필요한 경우 관련 페이지를 닫고 다시 시도하세요. 규칙 테스트는 홈페이지 도메인만이 아니라 실제로 실패한 하위 도메인까지 확인해야 합니다. 페이지의 이미지, API, 로그인 요청은 도메인이 달라 서로 다른 규칙이 적용될 수 있습니다.

연결 확인 및 단계별 문제 해결

Home에서 확인이 끝난 서버를 선택하고 Global Routing을 확인한 다음 연결 스위치를 켜세요. 앱의 상태가 바뀔 때까지 기다린 뒤 반복해서 테스트할 수 있는 익숙한 대상을 먼저 열고 실제 요청 기록을 확인하세요. “스위치가 켜짐”, “시스템에 VPN 표시가 나타남”, “테스트에 수치가 표시됨”을 하나의 성공으로 묶지 마세요. 각각 앱 실행 상태, 시스템 터널 상태, 특정 테스트 조건에서의 결과를 나타냅니다.

테스트 결과와 실제 접속을 따로 확인

Connectivity Test를 실행하면 현재 테스트 방식에서 선택한 서버가 응답하는지 확인할 수 있습니다. 테스트 대상, 프로토콜 지원 여부, 네트워크 조건에 따라 결과가 달라지므로 한 번의 응답 시간을 모든 웹사이트의 속도로 해석하지 마세요. 테스트가 실패했다고 모든 요청을 사용할 수 없는 것도 아닙니다. 테스트는 정상인데 웹페이지가 열리지 않으면 테스트 버튼만 반복해서 누르지 말고 대상 도메인, 라우팅 정책, 앱의 실제 요청을 확인하세요.

검증할 때는 같은 기기, 같은 기본 네트워크, 같은 서버, 같은 요청을 사용하세요. 먼저 Config 모드의 결과를 기록하고 규칙의 영향을 분리해야 할 때만 잠시 Proxy로 바꾼 뒤 테스트가 끝나면 원래 설정으로 되돌리세요. 네트워크와 서버를 바꾸면서 DNS까지 수정하면 결과가 나아져도 어떤 조치가 효과를 냈는지 알 수 없습니다. 이후 문제를 해결할 때도 재사용할 수 있는 판단 기준이 남지 않습니다.

문제가 발생한 단계에 따라 점검

연결 스위치가 곧바로 꺼진다면 시스템 권한, 네트워크 확장 실행, 로컬 구성 오류 단계에서 멈췄는지 먼저 확인하세요. VPN 구성이 있고 기기에서 활성화할 수 있는지 확인한 다음 앱에서 구성 파싱이나 정책 참조 오류를 표시하는지 살펴보세요. 이 단계에서는 요청이 안정적으로 실행되는 클라이언트에 도달하지 않았을 수 있으므로 특정 웹사이트 규칙을 먼저 살펴볼 필요는 없습니다. “열리지 않는다”라고만 설명하는 것보다 오류 원문을 보존하는 편이 원인을 구분하는 데 도움이 됩니다.

스위치는 켜져 있지만 모든 대상에 접속할 수 없다면 기본 네트워크를 먼저 확인한 다음 서버의 Address, Port, 인증 정보, 서비스 상태를 살펴보세요. 연결 시간 초과는 제한 시간 안에 특정 단계가 완료되지 않았다는 뜻일 뿐 비밀번호가 틀렸다고 단정할 수 없습니다. 인증 거부는 계정이나 매개변수 문제일 가능성이 더 큽니다. TLS 오류가 발생하면 SNI, 인증서 이름, 기기 시간을 추가로 확인하세요. 실패 아이콘 하나만으로 근본 원인을 판단하지 마세요.

일부 대상만 실패한다면 기록에서 해당 대상과 관련 하위 도메인을 찾아 어떤 정책이 적용됐는지 확인하세요. 기본 페이지는 열리는데 이미지나 로그인이 실패하는 경우 요청별로 경로가 다를 수 있습니다. 원격 서버에서 반환된 서비스 오류와 네트워크 오류도 구분해야 합니다. 페이지에 계정 권한 안내가 표시됐다면 적어도 일부 연결은 완료된 것이므로 기기의 VPN 권한을 반복해서 조작할 필요는 없습니다.

문제를 재현할 수 있는 최소 기록 보관

문제가 발생한 시간대, Wi-Fi 또는 셀룰러 환경, 현재 모드, 대상 도메인, 오류 유형을 기록하세요. 로그에 구독 주소, 인증 정보, 개인 키, 전체 요청 매개변수가 포함되어 있다면 공유하기 전에 민감한 부분을 가리세요. 프로토콜 종류와 오류가 발생한 단계만으로도 초기 판단에 도움이 되는 경우가 많으므로 전체 구성을 공개할 필요는 없습니다. 점검이 끝나면 임시 상세 기록을 꺼서 불필요한 접속 내역이 계속 쌓이지 않도록 하세요.

네트워크를 전환한 뒤에는 연결과 요청을 새로 시작하고 전환 전 결과를 현재 상태로 간주하지 마세요. 일부 프로토콜은 특정 전송 조건을 요구하므로 한 네트워크에서 사용할 수 있다고 다른 네트워크에서도 같은 결과가 나온다고 볼 수 없습니다. 문제가 재현되지 않는다면 마지막으로 정상 작동을 확인한 구성으로 되돌리고 차이점을 기록한 뒤 하나씩 다시 변경하세요. 빠른 진행 순서는 연결 및 확인 튜토리얼에서 볼 수 있습니다. 이 장의 목적은 범위를 좁히는 것이지 모든 설정을 한 번에 바꾸는 것이 아닙니다.

Data 트래픽 및 요청 기록

연결이 설정되면 Data를 열어 먼저 화면에 표시된 통계 범위를 확인한 다음 업로드, 다운로드, 요청 변화를 살펴보세요. 이 데이터는 현재 클라이언트에서 확인할 수 있는 네트워크 활동을 파악하는 데 쓰이며 통신사 청구 내역과 같지 않고 기기의 모든 네트워크 활동을 포함하지 않을 수도 있습니다. 항목에 따라 세션, 실행 단계, 화면에 표시된 기간을 기준으로 합산할 수 있습니다. 수치를 해석하기 전에 단위와 범위를 확인하고 총량만으로 특정 앱이 전송한 데이터 양을 추정하지 마세요.

방향, 단위, 시간 범위 확인

업로드는 기기에서 외부로 전송한 데이터이고 다운로드는 외부에서 기기로 받은 데이터입니다. 속도는 일정 시간 동안의 변화량이며 누적량은 관찰 범위의 합계이므로 둘을 직접 비교할 수 없습니다. 웹페이지 로딩이 끝난 뒤 속도가 낮아지는 것은 보통 전송이 완료되었기 때문이며 연결이 끊겼다는 뜻은 아닙니다. 백그라운드 동기화로 소량의 트래픽이 발생할 수 있으므로 조작하지 않을 때 수치가 조금 변하는 것만으로 이상 여부를 판단하지 마세요.

문제 해결을 시작하기 전에 현재 카운터 값을 기록하거나 화면에서 제공하는 초기화 기능을 사용해 새로운 관찰 구간을 만드세요. 그런 다음 대상 작업 하나만 수행합니다. 완료 후 변화를 비교하면 이번 요청과 이전 백그라운드 트래픽을 구분할 수 있습니다. 화면에 특정 통계 기간이 명시되어 있지 않다면 임의로 “이번 달 사용량”이라고 부르지 마세요. 요금 확인이 필요하다면 클라이언트의 일부 통계만 보지 말고 서비스 제공자나 통신사의 계정 기록을 확인하세요.

요청 기록으로 라우팅 결과 확인

Data 또는 요청 기록 메뉴에서 방금 방문한 도메인을 찾아 현재 화면에 표시되는 대상, 정책, 매칭 정보, 오류를 확인하세요. 기록 항목은 실제 화면과 활성화된 기록 옵션에 따라 달라지므로 모든 요청에 모든 세부 정보가 포함된다고 가정하지 마세요. 우선 세 가지를 확인합니다. 요청이 표시되는지, 어떤 경로로 처리됐는지, 어느 단계에서 끝났는지입니다. 요청이 기록에 남았는지 확인해야 규칙을 구체적으로 분석할 수 있습니다.

예상한 요청이 보이지 않으면 대상 앱에서 실제로 새 연결을 시작했는지 먼저 확인하세요. 브라우저 캐시, 기존 연결 재사용, 페이지 미갱신 때문에 작업을 한 것처럼 보여도 새 네트워크 요청이 발생하지 않을 수 있습니다. 대상 페이지를 닫았다가 다시 열거나 네트워크가 필요한 작업을 실행해 보세요. 기록 필터가 오류나 특정 정책 요청만 표시하도록 설정되어 있지 않은지도 확인하세요. 그렇지 않으면 다른 요청이 클라이언트를 거치지 않았다고 오해할 수 있습니다.

DIRECT가 표시된다고 해서 반드시 문제가 있는 것은 아닙니다. 현재 Global Routing 모드와 매칭 조건을 함께 확인하세요. Config 모드에서 직접 연결로 처리되는 것은 규칙의 의도된 결과일 수 있습니다. Proxy 모드의 동작은 적용 범위와 실제 기록을 기준으로 점검해야 합니다. 규칙 매칭은 특정 경로가 선택되었다는 뜻일 뿐 대상 서버가 요청을 받아들였음을 보장하지 않습니다. “규칙이 올바른 경로를 선택했는지”와 “대상이 정상 응답했는지”를 별도로 확인하면 오판을 줄일 수 있습니다.

반복 테스트로 트래픽 차이 확인

특정 작업의 데이터 사용량이 지나치다고 생각되면 같은 대상과 같은 작업으로 테스트를 반복한 뒤 요청 수, 재시도, 연결 지속 시간을 비교하세요. 동영상, 이미지, 동기화 작업은 데이터 크기가 원래 다르므로 텍스트 페이지 로딩 한 번과 미디어 재생 한 번을 비교하면 안 됩니다. 연속 실패로 요청이 반복되면 누적 트래픽은 증가할 수 있습니다. 트래픽이 변했다고 해서 서비스 작업이 완료된 것은 아닙니다.

통계 수치가 원격 계정의 사용량과 다르면 먼저 두 통계의 시간 범위, 업로드·다운로드 합산 기준, 프로토콜 오버헤드를 확인하세요. 클라이언트는 자체 범위의 처리량을 표시하고 원격 계정은 다른 기준으로 누적할 수 있습니다. 차이만으로 기록 오류를 판단하거나 라우팅 규칙을 바꿔 두 수치를 일치시킬 수 있다고 생각하지 마세요. 같은 시간대를 기준으로 확인한 다음 기존 서비스의 정보 제공자에게 계산 방식을 문의하세요.

접속 기록 저장 및 공유 시 주의

요청 기록에는 접속 대상, 시간, 일부 URL 매개변수가 표시될 수 있으므로 신중하게 다뤄야 합니다. 문제 해결에 필요한 구간만 보관하고 공유 전에 개인 정보, 구독 인증 정보, 관련 없는 도메인을 가리세요. 구성의 서버 메모에도 개인적인 용도 설명이 들어 있을 수 있으므로 화면을 캡처하거나 내보내기 전에 확인하세요. 기록을 지우면 문제 해결 단서도 사라지므로 필요한 내용을 비식별 형태로 먼저 정리한 뒤 삭제하세요.

Settings, DNS, On Demand

Settings을 열기 전에 현재 연결에서 정상 작동을 확인한 조건을 기록하고 어떤 문제를 해결할지 정하세요. Settings의 옵션은 구성 파일과 함께 실행 결과에 영향을 줄 수 있으며, 일부 항목은 현재 프로토콜이나 기기 조건에 따라 달라집니다. 실제 화면에 표시된 항목을 기준으로 설명을 먼저 읽은 뒤 수정하세요. 화면을 “완벽하게 설정”해 보이게 하려고 모든 옵션을 켜지 마세요. 사용하지 않는 기능은 미리 조정할 필요가 없습니다.

DNS 확인 경로 이해

DNS 관련 옵션을 찾을 때는 현재 시스템 DNS, 사용자 지정 DNS, 구성 파일 설정 중 무엇을 사용하는지 먼저 확인하세요. DNS는 도메인을 IP 주소로 변환하며 규칙은 도메인이나 DNS 결과에 의존할 수 있으므로 DNS 문제는 웹페이지 접속 실패로 나타나거나 IP 기반 규칙 매칭에 영향을 줄 수 있습니다. DNS를 변경하기 전에 도메인 확인 실패와 서버 연결 실패를 구분하세요. 서버 연결 문제는 DNS 주소만 바꾼다고 자동으로 해결되지 않습니다.

시스템 DNS를 선택하면 현재 네트워크가 제공하는 DNS 조건의 영향을 받습니다. 사용자 지정 DNS를 사용한다면 현재 연결 경로에서 DNS 서버에 접근할 수 있는지 확인하세요. DNS over HTTPS는 HTTPS를 통해 쿼리를 전송하지만 해당 서비스 주소 자체에 접근할 수 있어야 하며, 최초 연결에는 도메인 확인이 필요할 수도 있습니다. 암호화된 전송을 켰다는 이유만으로 모든 DNS 단계가 정상이라고 판단하지 말고 실제 쿼리가 성공하는지 확인하세요.

DNS를 테스트할 때는 한 번에 한 가지 출처만 변경하고 변경 전 값을 보관한 다음 대상 요청을 새로 실행하세요. 필요하면 앱에서 제공하는 방법으로 관련 캐시를 지우거나 다시 연결해 이전 결과가 판단에 영향을 주지 않도록 하세요. 특정 도메인만 실패하고 다른 도메인은 정상이라면 전체 DNS 설정을 처음부터 바꾸지 말고 해당 도메인과 관련 요청을 확인하세요. 자세한 내용은 DNS 설정 안내를 참고하세요.

수동 연결이 안정된 뒤 On Demand 활성화

On Demand 메뉴에서 작동 조건을 확인한 뒤 자동 연결 또는 연결 유지가 필요한 네트워크 상황을 설정하세요. 이 기능은 연결을 언제 시작할지 결정하며 서버 인증 가능 여부를 판단하거나 Global Routing을 대신하지 않습니다. 수동 연결이 안정되기 전에 자동 동작을 켜면 상태 변화의 원인을 파악하기 어려워집니다. 먼저 수동으로 연결하고 확인한 뒤 연결을 해제하세요. 그다음 조건을 추가하고 별도로 테스트합니다.

설정 후 계획한 대로 네트워크를 한 번 전환해 의도한 동작이 실행되는지 확인하세요. 연결이 끊겼다가 자동으로 다시 연결되면 스위치 고장으로 단정하기 전에 On Demand 조건을 먼저 확인하세요. 문제를 점검하기 위해 연결을 계속 끊어 두어야 한다면 해당 자동 동작을 먼저 일시 중지한 뒤 시스템 상태를 살펴보세요. 네트워크 변경, 기기 잠자기, 앱의 전경·백그라운드 전환은 서로 다른 조건이 될 수 있으므로 한 번 정상 실행되었다고 모든 상황을 확인한 것은 아닙니다.

전송 및 고급 매개변수 변경 시 주의

특정 프로토콜과 관련된 문제가 있을 때만 해당 서버나 구성의 고급 항목을 확인하세요. MTU는 한 번의 전송에서 전달되는 데이터 크기에 영향을 줍니다. 값이 너무 크면 일부 경로에서 문제가 생길 수 있고 너무 작으면 오버헤드가 증가할 수 있습니다. 근거 없이 다른 사람의 값을 그대로 사용하지 마세요. WireGuard에서는 Allowed IPs와 앱 수준 규칙의 적용 범위도 구분해야 합니다. 자세한 내용은 WireGuard 매개변수 안내를 참고하세요.

인증서와 TLS 설정은 서버 신원 확인의 의미가 유지되도록 주의하세요. 인증서 오류가 발생하면 이름, 유효 기간, 기기 시간을 먼저 확인하세요. 검증을 끄면 신뢰 조건이 달라지므로 일반적인 속도 개선 방법으로 사용하지 마세요. 추가 인증서 신뢰, 요청 변환, 콘텐츠 처리와 관련된 고급 기능은 이 가이드에서 기본 연결을 설정하는 데 필요한 단계가 아닙니다. 적용 범위를 이해하지 못했다면 복잡한 설정을 그대로 따라 하기보다 현재 작동하는 구성을 유지하는 편이 관리하기 쉽습니다.

구성 덮어쓰기 및 적용 시점 확인

수정한 뒤 Config로 돌아가 현재 활성 파일이 다른 항목으로 바뀌지 않았는지 확인하고 화면 안내에 따라 저장하거나 다시 연결하세요. 일부 설정은 이후 요청부터 적용되고, 일부는 연결을 다시 만들어야 반영됩니다. 이전에 열어 둔 페이지에 결과가 그대로 표시된다고 해서 저장에 실패했다고 판단하지 마세요. 원격 파일을 업데이트한 뒤 설정이 되돌아간다면 같은 위치를 반복해서 수정하기보다 원격 구성이 해당 내용을 덮어썼는지 확인하세요.

구독 업데이트, 백업, 유지 관리

일상적으로 사용할 때는 정상 작동이 확인된 구성을 하나 유지하고 실제 필요에 따라 구독과 앱을 업데이트하세요. 유지 관리는 주기적으로 모든 설정을 다시 바꾸는 것이 아니라 정보의 출처, 변경 사항, 결과를 추적할 수 있게 하는 일입니다. 변경할 때마다 최소한 무엇을 왜 수정했고 어떻게 복구할 수 있는지 설명할 수 있어야 합니다. 그러면 연결 문제가 달라졌을 때 처음 설치 단계부터 다시 살피지 않고 최근 변경부터 확인할 수 있습니다.

세 가지 업데이트 대상 구분

구독 메뉴에서 업데이트하는 것은 서버 정보이며 항목 수, 주소, 인증 정보, 메모가 바뀔 수 있습니다. Config에서 원격 파일을 업데이트하면 규칙과 실행 옵션이 바뀔 수 있습니다. App Store에서 앱을 업데이트하면 클라이언트 자체가 바뀝니다. 이 세 가지 작업은 서로 대체할 수 없습니다. 구독 업데이트가 성공해도 라우팅 파일이 업데이트된 것은 아니며 앱을 업데이트해도 만료된 서버 인증 정보가 유효해지는 것은 아닙니다.

기존 구독을 업데이트하기 전에 주소가 여전히 사용자가 보유한 서비스 정보에서 제공된 것인지 확인하고 현재 선택된 항목을 기록하세요. 업데이트 후 그룹, 서버 내용, 선택 상태를 확인한 다음 같은 대상으로 테스트하세요. 기존 항목이 사라졌다면 서비스 정보가 변경되었는지 확인하고 이전 이름이 영구 식별자라고 생각하지 마세요. 업데이트가 실패하면 구체적인 오류를 보관하고 리소스 가져오기와 콘텐츠 파싱 중 어느 단계에서 실패했는지 먼저 판단하세요. 기존에 작동하던 목록을 바로 삭제하지 마세요.

백업 시 비밀 정보와 일반 메모 구분

앱에서 제공하는 내보내기나 백업 기능을 사용하기 전에 어떤 항목이 포함되는지 확인하세요. 규칙 파일, 서버 기록, 구독 주소, 개인 키는 따로 저장될 수 있으며 파일 하나를 내보냈다고 모든 데이터가 포함되었다고 단정할 수 없습니다. 백업이 완료되면 포함 범위와 저장 위치를 확인하고 실제로 복원할 수 있는지 점검하세요. 중요한 복원 절차는 기기를 바꾼 뒤 처음 확인하지 말고 현재 사용하는 구성에 영향을 주지 않는 방법으로 미리 검증할 수 있습니다.

백업에는 Password, UUID, Private Key, 사용자 식별 정보가 포함된 구독 주소가 들어 있을 수 있으므로 적절한 접근 보호가 적용되고 사용자가 직접 관리하는 위치에 저장하세요. 규칙을 설명할 때는 필요한 부분만 제공하고 전체 백업을 보내지 마세요. 예시 도메인은 공개해도 되지만 실제 인증 정보는 구성 파일에 적혀 있다는 이유만으로 일반 설명처럼 취급할 수 없습니다. 인증 정보가 유출된 것으로 의심되면 기존 서비스의 정보 관리 메뉴에서 해당 정보를 폐기하고 교체하세요.

기기 교체 및 재설치 후 복원 순서

새 기기에서 먼저 App Store의 구입 항목으로 Shadowrocket을 다시 받고 기기 호환성을 확인한 뒤 앱을 열어 기존 백업을 가져오세요. 구입 권한 복원과 설정 복원은 별개의 단계입니다. 전자는 스토어 계정에, 후자는 보관한 데이터에 달려 있습니다. 가져온 뒤 권한, 서버 선택, Global Routing, 활성 Config를 다시 확인하세요. 이전 기기의 시스템 권한이 새 기기로 모두 이전된다고 가정하지 마세요.

복원 후에는 수동 연결로 정상 요청과 규칙 결과를 한 번 확인한 다음 On Demand 등의 자동 동작을 켜세요. 백업한 지 오래되었다면 서버 인증 정보가 여전히 유효한지 먼저 확인하세요. 구독 업데이트가 필요하다면 업데이트를 완료한 뒤 선택된 항목을 다시 확인하세요. 새 기기의 검증이 끝나고 필요한 데이터를 복구할 수 있는지 확인하기 전에는 기존 기기의 모든 기록을 먼저 삭제하지 마세요. 그 후 개인 데이터 관리 필요에 따라 이전 내용을 처리하세요.

변경 전후 간단한 기록 남기기

개인 메모에 변경 날짜, 수정한 항목, 확인 결과를 기록할 수 있지만 비밀번호나 전체 구독 주소를 다시 적지 마세요. “DOMAIN-SUFFIX 규칙의 정책을 바꾼 뒤 대상 API가 복구됨”이라고 적는 편이 “설정을 바꿈”보다 유용합니다. 문제가 다시 발생하면 이러한 차이를 먼저 확인한 뒤 연결 문제 해결을 참고해 권한, 네트워크, 서버, 규칙, 대상 서비스 순서로 범위를 좁히세요.

오랫동안 사용하지 않았다가 다시 연결할 때는 기본 네트워크와 App Store에서 앱 상태를 먼저 확인한 다음 기존 서비스 정보를 점검하세요. 과거의 한 번의 테스트 결과를 현재 상황에 그대로 적용하거나 화면 배치가 바뀌었다고 모든 구성을 다시 만들지 마세요. 메뉴 위치가 달라졌다면 영어 용어를 기준으로 해당 기능을 찾으세요. 매개변수의 의미가 바뀌지 않은 부분에는 이 가이드의 판단 방법을 계속 적용할 수 있으며, 실제 사용 가능한 옵션은 현재 앱 화면을 따릅니다.

유지 관리가 끝나면 최소한의 정상 작동 상태로 돌아가야 합니다. 선택된 서버가 명확하고, 활성 구성을 확인할 수 있으며, 테스트 결과를 재현할 수 있고, 임시 기록을 정리한 상태여야 합니다. 처음부터 순서대로 진행하려면 빠른 시작 가이드로 돌아가세요. 프로토콜 배경을 더 알아보려면 기술 노트를 확인하세요. 이 가이드는 단계별 책임 범위를 설명하며 사용자가 보유한 서비스의 계정 관리와 매개변수 안내를 대신하지 않습니다.