Shadowrocket 사용법 완벽 가이드

02 / FIRST LAUNCH

첫 실행: VPN 구성과 연결 권한 이해하기

먼저 화면을 살펴본 뒤 시스템 권한을 설정하세요

먼저 유효한 서버 정보를 준비한 다음, 연결을 시작할 때 시스템 권한을 처리하세요. Home에서는 서버와 연결 메뉴를 확인하고, Config에서는 규칙을 관리하며, Data에서는 트래픽 관련 정보를 확인합니다. Settings에는 자주 쓰는 설정이 모여 있습니다. 기기에 따라 화면 배치가 다를 수 있으므로 항목 이름으로 찾고, 버튼 위치를 외워서 조작하지 않아도 됩니다. 처음 열었을 때 목록이 비어 있다면 사용할 연결 정보가 아직 추가되지 않았다는 뜻입니다.

처음 연결을 시작하면 시스템에서 VPN 구성을 추가하도록 허용하고 기기 암호나 기기에서 제공하는 인증 방식으로 확인하라는 메시지가 표시될 수 있습니다. 이는 앱이 네트워크 확장 연결을 만들도록 시스템이 허용하는 단계이며, 구독 로그인 화면이나 서비스 제공업체의 비밀번호 입력창이 아닙니다. 현재 작업으로 인해 표시된 메시지인지, 앱 이름이 올바른지 확인한 뒤 허용 여부를 결정하세요. 취소했다면 앱으로 돌아가 서버 정보를 확인하면 됩니다.

VPN 구성 추가를 허용하면 기기에서 연결할 권한만 설정됩니다. 원격 서버를 사용할 수 있는지 확인되는 것은 아닙니다. 권한 설정이 끝나도 주소, 포트, 인증 정보 또는 네트워크 조건이 맞지 않으면 연결에 실패할 수 있습니다. 시스템 권한을 허용했다고 연결이 완료된 것으로 보지 마세요. 이후 서버 연결, 도메인 이름 확인, 대상 접속을 각각 확인해야 하며, 어느 하나가 나머지를 대신할 수 없습니다.

권한 문제 확인 방법

이전에 권한 요청을 거부했다면 다음 연결 시 시스템 메시지가 다시 표시되는지 먼저 확인하세요. 메시지가 나타나지 않고 연결이 바로 실패한다면 시스템 설정에서 VPN 구성을 찾아 Shadowrocket 항목이 있는지, 기기에 조직 관리 제한이 있는지 확인하세요. 시스템 설정의 메뉴 이름은 화면에 따라 달라질 수 있으므로 기기에 실제로 표시되는 항목을 기준으로 하세요. 정확한 경로를 찾으려고 관련 없는 권한을 연달아 변경하지 마세요.

기기에 다른 VPN 구성이 있다면 실제로 연결 중인 항목이 무엇인지 먼저 확인하세요. Shadowrocket을 테스트하기 전에 사용 중인 다른 VPN 연결을 종료해 시스템의 연결 전환을 서버 오류로 오해하지 않도록 하세요. 구성을 저장해 두는 것과 연결을 유지하는 것은 다릅니다. 테스트를 위해 모든 구성을 삭제할 필요는 보통 없습니다. 먼저 연결을 해제하고 상태를 다시 확인한 다음, 한 번 명확하게 연결을 시도하면 어느 단계에서 실패했는지 판단하기 쉽습니다.

카메라 권한은 QR 코드 스캔에만 필요합니다. Scan QR Code로 기존 서버 정보를 가져오려면 시스템 안내에 따라 카메라 접근을 허용하세요. 스캔을 사용하지 않는다면 앱에서 제공하는 다른 가져오기 방법을 이용할 수 있습니다. 카메라 권한을 거부했다고 VPN 권한까지 거부한 것은 아니며, 서버에 연결할 수 없다는 뜻도 아닙니다. 각 권한은 현재 기능에 필요한지 먼저 확인한 뒤 허용 여부를 결정하세요.

첫 연결 전에 되돌릴 수 있는 상태를 유지하세요

본격적으로 설정하기 전에 기기에서 테스트할 일반 웹 페이지에 정상적으로 접속할 수 있는지 확인하세요. 현재 Wi-Fi와 셀룰러 네트워크 중 무엇을 사용 중인지, 웹 인증이 필요한 네트워크인지도 기록해 두세요. 웹 인증이 필요하면 먼저 인증을 완료한 뒤 Shadowrocket에 연결하세요. 기본 네트워크 접속이 허용되지 않은 상태에서는 앱 권한이 있어도 연결이 실패할 수 있습니다. 프로토콜 매개변수를 계속 바꾸면 실제 원인을 놓칠 수 있습니다.

처음 사용할 때는 복잡한 On Demand 조건을 설정하지 말고 수동 연결부터 테스트하는 것이 좋습니다. 서버 선택, 라우팅 모드 선택, 연결 시작, 대상 접속, 연결 종료까지 전체 과정을 먼저 진행해 각 단계의 상태를 확인하세요. 자동 연결은 기본 설정이 올바른 상태에서 사용해야 합니다. 미리 활성화하면 수동으로 연결을 끊은 뒤 다시 연결될 수 있어 권한 문제인지, 조건이 작동한 것인지, 서버 연결이 불안정한 것인지 구분하기 어려워집니다.

설정 확인이나 오류 기록을 위해 화면을 캡처해야 한다면 비밀번호, 구독 링크, 인증 정보, 민감한 정보를 복구할 수 있는 QR 코드를 먼저 가리세요. 시스템 메시지와 앱 설정 화면으로 진행 단계를 기록할 수 있지만, 공유 전에 내용 전체를 다시 확인해야 합니다. 권한 문제를 점검할 때 필요한 것은 권한 요청이 표시됐는지, 허용했는지, 어느 단계에서 실패했는지입니다. 서버 인증 정보를 공개할 필요는 없습니다. 준비가 끝나면 서버 가져오기 장으로 이동하세요.

04 / GLOBAL ROUTING

라우팅: Config, Proxy, Direct의 역할 구분하기

세 가지 모드로 요청 처리 방향부터 결정하세요

일반적인 규칙 기반 라우팅에는 Config, 선택한 서버를 점검할 때는 Proxy, 기기의 직접 접속과 비교할 때는 Direct를 사용하세요. Global Routing은 앱 전체의 라우팅 방식을 선택하는 항목이지, 서비스 제공업체의 프로토콜 유형이나 시스템 권한 스위치가 아닙니다. 먼저 현재 선택된 값을 확인한 다음 요청이 서버를 거쳤는지 직접 연결됐는지 살펴보세요. 서버 이름만 확인해서는 실제 요청 경로를 알 수 없습니다.

Config에서는 보통 규칙을 순서대로 검사하며, 먼저 일치한 규칙이 해당 요청의 처리 정책을 결정합니다. 더 구체적인 예외 규칙은 이를 덮어쓸 수 있는 광범위한 규칙보다 앞에 둬야 합니다. 앞선 규칙에 일치하지 않을 때 FINAL이 마지막으로 처리합니다. 아래 예시는 규칙 매칭 관계를 설명하기 위한 것으로, 기존 설정 전체를 대체할 완성된 Config가 아닙니다. 수정 전에 현재 유효한 파일을 복사해 서버와 정책 정의를 보관하세요.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,REJECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

규칙 유형, 정책, 순서를 나눠서 이해하기

DOMAIN은 전체 도메인과 일치하고, DOMAIN-SUFFIX는 도메인 접미사와 일치하며, DOMAIN-KEYWORD는 도메인에 포함된 키워드와 일치합니다. 접미사 규칙은 도메인과 하위 도메인에 같은 정책을 적용할 때 적합합니다. 키워드 규칙은 범위가 더 넓어 같은 문자열이 들어간 다른 도메인까지 일치시킬 수 있습니다. 규칙을 추가하기 전에 적용할 대상 범위를 정하고, 대상 도메인을 확인하는 대신 지나치게 넓은 규칙을 사용하지 마세요.

IP-CIDR과 IP-CIDR6은 각 주소 대역에 사용하고, GEOIP는 주소 데이터베이스에 기록된 지역 정보를 기준으로 판단합니다. 도메인 요청은 DNS 확인이 필요할 수 있으며 IP 규칙도 이름 확인 방식과 관련될 수 있습니다. 예시의 no-resolve는 해당 규칙이 추가 DNS 확인을 유발하지 않도록 제한하는 옵션이지, 연결 속도를 높이는 일반적인 스위치가 아닙니다. 규칙이 일치하는지는 실제 요청 정보에 따라 달라지므로 웹 페이지에 표시된 이름만으로 판단할 수 없습니다.

PROXY, DIRECT, REJECT는 서로 다른 요청 처리 정책을 나타냅니다. 이를 Global Routing의 화면 모드와 혼동하지 마세요. Config 규칙이 DIRECT와 일치해도 앱 전체가 Direct 모드로 전환되는 것은 아닙니다. PROXY와 일치하면 현재 Config의 정책 참조와 서버 선택도 확인해야 합니다. 파일에서 사용자 지정 정책 그룹 이름을 쓴다면 규칙 끝에 실제로 존재하며 철자가 일치하는 이름을 지정해야 합니다.

변경을 최소화해 규칙 적용 여부 확인하기

Config를 수정하기 전에 현재 선택된 파일을 바꾸는지, 같은 이름의 복사본을 바꾸는지 확인하세요. 저장한 뒤 앱 안내에 따라 다시 연결하거나 Config를 다시 불러온 다음 새로운 테스트 요청을 보내세요. 기존 장기 연결과 웹·앱 캐시는 이전 동작을 계속 유지할 수 있으므로 이미 열어 둔 페이지에만 의존하지 마세요. 새 요청을 명확하게 한 번 보내고 요청 기록에서 어떤 정책이 적용됐는지 확인하세요.

Proxy에서는 접속되지만 Config에서 안 된다면 규칙 일치 여부, 정책 그룹 참조, DNS 결과부터 비교하세요. 서버를 바로 다시 만들 필요는 없습니다. Direct에서는 정상인데 Proxy에서 실패한다면 서버와 프로토콜 설정을 확인하세요. 세 가지 모드는 원인을 좁히기 위한 비교 도구이지 서로를 대신하는 해결 스위치가 아닙니다. 테스트가 끝나면 원래 필요한 모드로 되돌려 임시 테스트 설정이 계속 사용되지 않도록 하세요.

규칙 파일에는 DNS, 정책 그룹, 원격 규칙 참조가 포함될 수 있으므로 FINAL 한 줄만 보고 전체 동작을 판단해서는 안 됩니다. 명확하고 적은 수의 규칙으로 확인 가능한 기준을 만든 다음 예외를 하나씩 추가하세요. 규칙을 추가할 때마다 대상, 예상 정책, 실제 적용 결과를 기록해 변경 이유를 추적할 수 있도록 하세요. 계속 문제가 발생하면 이 세 가지 정보를 준비해 문제 해결을 확인하세요. 단순히 '라우팅이 이상하다'고 설명하는 것보다 원인을 찾기 쉽습니다.

06 / DATA

Data: 트래픽 통계, 요청 기록, 서비스 사용량 구분하기

숫자는 범위를 먼저 확인한 뒤 크기를 비교하세요

Data의 트래픽 정보는 클라이언트에서 처리된 상황을 확인하기 위한 것으로, 기존 서비스의 최종 과금 사용량과 같지 않습니다. 숫자를 확인하기 전에 항목 이름, 통계 기간, 현재 연결 상태를 살펴보고 업로드, 다운로드, 현재 연결, 누적 기록 중 무엇을 나타내는지 확인하세요. 집계 범위가 다른 숫자는 직접 빼거나 비교할 수 없습니다. 두 숫자가 다르다는 이유만으로 클라이언트나 서버의 통계가 잘못됐다고 판단하지 마세요.

업로드와 다운로드는 현재 기기를 기준으로 데이터 방향을 나타냅니다. 웹 페이지를 열 때도 업로드 요청이 발생할 수 있고, 콘텐츠를 내려받을 때도 프로토콜 통신이 이루어지므로 업로드를 파일을 직접 보내는 동작으로만 이해해서는 안 됩니다. 트래픽 숫자는 데이터가 전송됐음을 나타내며, 모든 콘텐츠가 화면에 정상적으로 표시됐다는 뜻은 아닙니다. 재연결, 백그라운드 새로고침, 실패한 요청에서도 데이터가 발생할 수 있으므로 실제 접속 상황과 함께 해석해야 합니다.

로컬 통계와 서버 기록은 통계 기간, 프로토콜 오버헤드, 재시도 처리, 서버 측 계산 방식 등의 이유로 다를 수 있습니다. 일부 요청은 규칙에 따라 직접 연결될 수 있으므로 서버 측에는 서버를 거친 일부 요청만 표시될 수 있습니다. 사용량을 확인하려면 먼저 관찰 시간과 연결 범위를 맞춘 다음, 이용 중인 서비스 안내를 확인하세요. Data를 청구 내역의 증빙으로 사용하지 마세요.

요청 정보를 이용해 규칙 및 이름 확인 문제 찾기

요청 기록에서는 방금 직접 실행한 작업을 찾아 시간, 대상, 적용된 정책을 확인하세요. 기기에서 백그라운드 연결이 발생할 수 있으므로 목록 맨 위 항목이 확인 중인 웹 페이지 요청이라고 단정할 수 없습니다. 관련 없는 작업을 잠시 중단한 뒤 명확한 테스트를 한 번 진행해 기록 범위를 줄이세요. 재확인할 때도 대상을 그대로 유지해 서로 다른 요청의 결과를 한 요청의 반복 변화로 오해하지 않도록 하세요.

요청 기록에 규칙 일치 정보가 있다면 규칙 유형과 최종 정책을 함께 확인하세요. 도메인 규칙이 일치했다는 것은 매칭 과정이 해당 규칙까지 진행됐다는 뜻입니다. 해당 규칙이 참조하는 정책이 예상과 맞는지도 확인해야 합니다. DIRECT 기록이 서버 오류를 뜻하는 것은 아니며, REJECT 기록도 반드시 연결 오류인 것은 아닙니다. Config에서 의도한 처리일 수 있으니 먼저 예상한 결과와 비교하세요.

도메인 기록과 주소 기록도 구분해서 살펴봐야 합니다. 한 웹 페이지에서 여러 도메인에 접속할 수 있고, 한 도메인도 여러 주소로 확인될 수 있습니다. 네트워크를 바꾸면 결과가 달라질 수도 있습니다. 특정 주소의 지역 정보만으로 전체 웹 페이지에 어떤 규칙을 적용해야 할지 단정할 수 없습니다. DNS 문제를 확인할 때는 확인된 주소, 적용된 정책, 대상 접속 결과를 함께 살펴보고 주소 하나만으로 광범위한 GEOIP 또는 IP-CIDR 규칙을 변경하지 마세요.

트래픽 급증, 기록 삭제 및 개인정보 보호

기기에서 직접 조작하지 않았는데 트래픽이 계속 증가한다면 백그라운드 동기화, 미디어 재생, 시스템 업데이트, 실행 중인 다른 네트워크 작업부터 확인하세요. 명확하게 정한 짧은 관찰 시간 동안 백그라운드 활동을 줄이고 연결 전후 및 라우팅 모드별 결과를 비교할 수 있습니다. 트래픽이 증가했다는 이유만으로 구독 문제라고 단정하지 마세요. 클라이언트가 처리한 백그라운드 요청도 통계에 표시될 수 있습니다.

앱에서 통계 초기화 또는 기록 삭제 기능을 제공한다면 실행 전에 문제 해결에 필요한 범위와 주요 현상을 먼저 저장하세요. 로컬 표시를 지워도 서버 사용량이 초기화되거나 서버 연결 상태가 바뀌는 것은 보통 아닙니다. 표시된 숫자를 초기화해 서비스 사용량을 복구하려고 하지 마세요. 초기화 후 같은 조건으로 짧게 테스트하면 변화를 확인하기 좋지만, 새로운 관찰 시작점을 기록하고 이전 누적 값과 직접 비교하지 마세요.

요청 기록에는 접속한 도메인, 서버 주소, 시간 및 기타 민감한 항목이 포함될 수 있으므로 내보내거나 화면을 캡처하기 전에 하나씩 확인하세요. 문제를 공유할 때는 규칙 유형, 정책 이름, 오류 발생 단계를 남기고 개인 인증 정보와 문제에 관련 없는 접속 내역은 가릴 수 있습니다. 구독 링크는 일부만 보여도 인증 정보가 포함될 수 있습니다. 앞부분을 잘랐으니 안전하다고 여기지 말고, 공유 전에 화면에 표시된 전체 범위를 확인하세요.

Data는 단독으로 결론을 내리는 기능이 아니라 문제를 확인할 근거를 제공하는 데 적합합니다. 한 번의 접속에 대해 네트워크 환경, 라우팅 모드, 적용된 정책, 결과를 함께 기록하면 화면 캡처를 많이 모으는 것보다 효과적입니다. 기록이 관찰 결과와 다르면 같은 요청을 확인한 것인지 먼저 살펴본 뒤 캐시와 장기 연결을 점검하세요. 근거를 정리한 다음 Settings를 조정해야 통계 변화만 보고 설정을 크게 바꾸는 일을 피할 수 있습니다.

08 / MAINTENANCE

유지 관리: 유효한 설정을 보관하고 업데이트와 복원을 따로 관리하세요

앱, 구독, 규칙은 각각 따로 유지 관리하세요

App Store 앱 업데이트, Subscribe 목록 업데이트, Config 규칙 관리는 각각 따로 진행하세요. 앱 업데이트는 클라이언트 자체를 변경하고, 구독 업데이트는 서버 정보를 변경하며, 규칙 업데이트는 요청 라우팅 기준을 변경합니다. 세 가지는 서로 다른 시점에 이루어질 수 있습니다. 동작이 달라졌다면 최근에 어느 항목을 변경했는지 먼저 확인하세요. 구독 업데이트가 성공했다고 앱이 업데이트된 것은 아니며, 앱 업데이트로 만료된 서버 정보를 확인할 수 있는 것도 아닙니다.

App Store에서 업데이트하기 전에 현재 유효한 설정을 저장하고 기존 구독 정보를 다시 찾을 수 있는지 확인하세요. 업데이트 후에는 기존 서버, 라우팅 모드, 테스트 대상을 그대로 사용해 확인하고 새 규칙을 바로 함께 가져오지 마세요. 결과가 달라졌다면 어떤 기능의 어느 단계에서 실패했는지 먼저 기록한 다음, Config 호환성, 네트워크 환경, 서버 상태와 관련이 있는지 확인하세요. 앱 업데이트 기록은 App Store에서 확인할 수 있으므로 별도의 버전 목록을 관리할 필요는 없습니다.

구독을 업데이트한 뒤에는 항목이 추가되거나 삭제됐는지, 이름이 바뀌었는지, 현재 선택이 여전히 유효한지 확인하세요. '성공' 메시지만 보고 끝내지 말고 현재 사용 중인 서버 하나 이상을 테스트하세요. 목록이 갑자기 비어 있다면 기존 자료를 보관하고 링크 상태를 확인하세요. 반복해서 삭제하고 다시 만들지 마세요. 기존 서비스의 이용 기간과 권한은 사용자가 이용 중인 서비스에 따라 결정되며, 클라이언트 업데이트로 연장되거나 변경되지 않습니다.

백업은 파일 하나를 저장하는 것만으로 끝나지 않습니다

백업할 때 규칙 파일, 직접 추가한 서버 매개변수, 구독 링크를 구분하세요. Config 파일 하나에 모든 서버 정보가 들어 있지 않을 수 있으며, 목록 스크린샷으로는 인증 정보를 복원할 수 없습니다. 앱에서 제공하는 내보내기나 백업 기능을 사용하기 전에 무엇이 포함되는지 확인하고 필요한 자료를 직접 관리할 수 있는 위치에 저장하세요. 백업 파일에는 인증 정보가 포함될 수 있으므로 공개 링크, 공유 폴더, 확인되지 않은 채팅 기록에 보관하지 마세요.

백업이 있는지 확인하는 것보다 실제로 복원할 수 있는지 점검해야 합니다. 현재 유효한 설정을 손상시키지 않는 범위에서 내보낸 내용과 복원 메뉴를 확인하고, 파일을 읽을 수 있는지, 규칙 부분이 빠짐없이 들어 있는지, 정책 참조 대상이 여전히 존재하는지 살펴보세요. 백업을 확인하려고 전체 설정을 먼저 지울 필요는 없습니다. 원래 설정을 보관한 상태에서 복사본을 확인하면 유지 관리 작업이 모든 연결을 다시 점검하는 일로 번지는 것을 막을 수 있습니다.

새 기기에서는 먼저 App Store에서 Shadowrocket을 다시 받은 뒤 서버 정보와 Config를 복원하세요. 구매 권한 복원과 로컬 데이터 복원은 별도로 확인해야 합니다. 같은 계정으로 앱을 받아도 모든 설정이 자동으로 나타나는 것은 아닙니다. 가족 공유, 여러 기기 사용, 호환성 조건은 App Store 페이지에 표시된 내용을 기준으로 확인하세요. 복원이 끝나면 먼저 수동 연결을 테스트하고 정상임을 확인한 뒤 On Demand 같은 자동 동작을 다시 활성화하세요.

사용하지 않는 항목을 정리하고 다음에도 활용할 기록을 남기세요

서버 목록을 정리할 때는 일시적인 테스트 실패와 더 이상 사용하지 않는 것이 확인된 항목을 구분하세요. 네트워크가 불안정해 한 번 시간 초과가 발생했다고 삭제해야 하는 것은 아닙니다. 구독을 업데이트하고 매개변수를 확인한 뒤 같은 조건에서 다시 테스트하세요. 직접 추가한 항목은 출처를 기록하고, 구독에서 가져온 항목은 다음 업데이트 때 목록이 다시 만들어질 수 있음을 고려하세요. 이름이나 한 번의 테스트 결과만으로 일괄 정리하기보다 출처에 따라 정리하는 편이 안전합니다.

Config 파일에도 분명한 기준 설정을 하나 보관하세요. 수정하기 전에 복사본을 만들고 도메인 예외 추가나 최종 정책 변경처럼 수정 목적을 기록하세요. 결과를 확인한 뒤 원본을 교체할지 결정하면 됩니다. 이름이 같은 파일 복사본 여러 개가 동시에 현재 설정으로 사용되지 않도록 하세요. 다음 연결 때 파일을 잘못 선택할 수 있습니다. 예시의 예약 주소와 도메인은 설명용이며 실제 서버 접속 정보로 사용할 수 없습니다.

문제 기록은 간단하게 작성하되 네트워크 유형, 선택한 서버의 출처, Global Routing 설정, 문제 발생 시간대, 오류 단계, 최근 변경 내용을 포함하세요. 비밀번호나 구독 인증 정보를 전부 기록할 필요는 없습니다. 비슷한 문제가 다시 생기면 이전에 작동하던 상태와 비교하고 최근 변경 내용을 확인한 뒤 권한, 서버, 이름 확인, 규칙, 대상 접속 순서로 점검하세요. 매번 처음부터 모든 설정을 다시 만들 필요는 없습니다.

장기간 사용할 때는 기본 네트워크가 정상인지, 서버 정보가 유효한지, 올바른 설정이 선택됐는지, 라우팅 규칙이 예상대로 적용되는지, 실제 대상에 접속할 수 있는지 순서대로 확인하세요. 이 흐름이 명확해진 뒤 자동 연결과 복잡한 규칙을 추가하세요. 가장 간단한 절차를 다시 확인하려면 빠른 시작을 읽고, 구매 및 복원을 확인하려면 구매 가이드를 참고하세요. 구체적인 증상이 있다면 문제 해결에서 해당 문제를 찾아보세요.