Shadowrocket 사용법 완벽 가이드

02 / FIRST LAUNCH

최초 실행과 VPN 구성 권한

먼저 Home을 살펴본 뒤 연결을 시작하세요

Shadowrocket을 처음 열면 연결 스위치를 켜기 전에 Home부터 살펴보세요. Home에는 연결 상태, Global Routing, Connectivity Test, SERVER 등의 항목이 모여 있습니다. SERVER에 사용 가능한 정보가 있어야 하고, Global Routing은 라우팅 방식을 결정하며, 연결 스위치는 시스템 네트워크 터널을 시작합니다. 각 항목의 역할은 다릅니다. 서버가 목록에 있다고 선택된 것은 아니며, 서버를 선택했다고 터널이 연결된 것도 아닙니다.

Home에 Not Connected가 표시되면 앱이 아직 연결되지 않았다고 보고한다는 뜻일 뿐, 구독의 유효성을 판단할 수는 없습니다. 먼저 목록에 자료가 있는지 확인하고, 사용할 서버를 선택한 뒤, 라우팅 방식을 확인하세요. 이 순서를 따르면 목록이 비어 있거나 잘못된 모드에서 연결 권한을 허용한 뒤 모든 문제를 시스템 권한 탓으로 돌리는 일을 피할 수 있습니다. 화면 구성은 첫 실행 및 Home 화면 안내에서도 확인할 수 있습니다.

처음에는 기본 설정을 유지하는 편이 문제를 찾기 쉽습니다. 모든 보조 기능을 한꺼번에 켤 필요는 없습니다. 먼저 보유한 정보로 수동 연결을 한 번 완료하는 데 집중하고, 연결에 성공한 뒤 On Demand, DNS, 규칙을 차례로 조정하세요. 권한, 자료, 고급 설정을 따로 다루면 어떤 변경이 동작에 영향을 줬는지 분명해지고, 검증된 상태로 되돌리기도 쉽습니다.

시스템 권한 요청의 의미

연결을 시작할 때 시스템에서 VPN 구성을 추가하도록 허용해 달라는 요청이 표시될 수 있습니다. 이는 Apple 시스템에서 네트워크 확장을 관리하는 데 필요한 권한 절차입니다. 허용하면 기기에서 Shadowrocket이 사용할 VPN 구성을 만들 수 있습니다. 시스템이 기기 암호 또는 다른 인증을 요청할 수 있으므로 화면 안내에 따라 진행하세요. 이 권한은 구매 절차가 아니며 서버 주소를 자동으로 입력하지도 않습니다. 클라이언트가 해당 네트워크 연결을 시작할 수 있도록 시스템 권한을 부여하는 단계입니다.

VPN 구성과 프록시 서버 기록은 서로 다른 항목입니다. VPN 구성은 시스템이 관리하며 터널 시작과 권한에 관련됩니다. 서버 기록은 앱에 저장되며 서버, 포트, 인증 방식을 설명합니다. 따라서 시스템에 VPN 구성이 있다고 SERVER 목록이 올바르다는 뜻은 아닙니다. 반대로 자료를 가져오는 데 성공해도 시스템 권한 설정이 완료된 것은 아닙니다. 점검할 때는 모든 자료를 삭제하고 처음부터 다시 시작하기보다 두 항목을 따로 확인하세요.

실수로 거부했다면 Home으로 돌아가 연결을 다시 시작해 권한 요청이 표시되는지 확인하세요. 요청이 다시 나타나지 않으면 시스템 설정에서 VPN 또는 VPN 및 기기 관리 관련 항목을 찾아 구성과 상태를 확인합니다. 메뉴 이름과 경로는 시스템 및 기기에 따라 다를 수 있습니다. 기기가 조직에서 관리되는 경우 일부 설정을 변경하지 못할 수 있으므로, 시스템 정책을 반복해서 수정하려 하지 말고 먼저 관리 제한을 확인하세요.

연결이 막히면 먼저 권한 충돌을 점검하세요

기기에 다른 VPN 구성이나 네트워크 확장이 있다면 현재 실제로 활성화된 항목부터 확인하세요. 테스트 중에는 네트워크를 함께 제어할 수 있는 구성을 일시 중지하고 Shadowrocket만 단독으로 확인해 자동 연결 조건이 서로 작동하지 않도록 합니다. 다른 구성의 원본 내용은 보관하세요. 한 번 문제를 점검하기 위해 모두 삭제할 필요는 없습니다. 업무용 또는 학교 기기라면 해당 구성의 용도와 관리 요건을 먼저 확인하세요.

시스템 구성이 손상된 것이 명확히 의심되고 권한을 다시 부여해도 복구되지 않을 때만 관련 VPN 구성을 다시 만드는 방안을 고려하세요. 작업 전에 앱의 서버와 설정 자료를 보관하고 연결을 중지한 다음, 처리할 구성 이름을 확인하고 시스템에서 허용하는 방식으로 제거한 뒤 다시 권한을 부여합니다. 시스템 VPN 구성을 삭제해도 구독이 복구되지는 않으며, 모든 문제 해결의 첫 단계로 삼아서는 안 됩니다. 자세한 내용은 VPN 구성 안내를 참고하세요.

권한을 허용한 뒤에도 연결되지 않으면 어느 단계에서 실패하는지 확인하세요. 스위치가 곧바로 꺼지면 권한이나 확장 기능 시작 문제일 수 있습니다. 스위치는 켜진 상태인데 대상 요청이 실패한다면 서버와 라우팅을 점검해야 합니다. 현상에 따라 점검 방법이 다르므로 권한을 허용했다는 이유만으로 모든 것이 정상이라고 판단할 수는 없습니다. 시스템 메시지 원문, 현재 네트워크 종류, 실패한 동작을 기록하면 스위치를 반복해서 켜고 끄는 것보다 문제를 찾는 데 도움이 됩니다.

04 / GLOBAL ROUTING

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

Config, Proxy, Direct의 역할

Global Routing은 현재 연결에 사용할 라우팅 방식을 선택합니다. Config 모드에서는 현재 Config 파일의 규칙에 따라 요청의 경로를 결정합니다. Proxy 모드는 선택한 프록시 경로를 전체적으로 사용하며, Direct 모드는 직접 연결합니다. 세 모드는 동작 방식을 선택하는 것으로 속도 등급이나 서버 세 종류가 아닙니다. 모드를 전환해도 인증 정보가 바뀌지는 않으므로 서버와 설정이 유효한지 계속 확인해야 합니다.

문제를 점검할 때 Proxy와 Config를 잠시 비교할 수 있습니다. 같은 대상이 Proxy에서는 열리지만 Config에서는 실패하면 규칙 일치와 정책 경로를 먼저 확인하세요. 두 모드 모두 실패한다면 서버와 기본 네트워크를 점검합니다. Direct는 직접 접근 상태를 살펴보는 데 도움이 되지만, 비교 결과는 당시 네트워크와 대상에만 해당합니다. 한 번에 조건 하나만 바꾸고 테스트 후에는 원래 모드로 되돌려 임시 설정을 잊지 않도록 하세요.

Global Routing은 모든 앱의 경로를 우회시키는 독립 스위치가 아닙니다. 실제 요청은 시스템 네트워크, DNS, 앱 캐시, 설정 예외의 영향을 받을 수 있습니다. 현재 모드 이름만 볼 것이 아니라 요청 기록과 함께 실제 트래픽 경로를 판단해야 합니다. 특히 브라우저가 기존 연결을 재사용하거나 앱이 장시간 연결을 유지한다면 모드를 바꾼 뒤 요청을 새로 보내세요. 필요한 경우 기존 세션을 종료하고 새 연결의 경로를 확인합니다.

규칙은 위에서 아래로 확인하며 먼저 일치하는 규칙이 적용됩니다

Config 모드에서는 Rule의 순서가 결과에 직접 영향을 줍니다. 일반적으로 범위가 좁고 조건이 명확한 규칙을 앞에 두고, 최종 처리 규칙은 맨 뒤에 둡니다. DOMAIN은 전체 도메인에 일치하고, DOMAIN-SUFFIX는 도메인 접미사 범위에 일치하며, DOMAIN-KEYWORD는 도메인에 포함된 키워드로 일치 여부를 판단합니다. 키워드 규칙은 범위가 넓을 수 있으므로 작성이 편하다는 이유만으로 모든 정확한 규칙보다 앞에 두지 마세요.

IP-CIDR과 IP-CIDR6은 주소 대역에 적용되고, GEOIP는 해당 주소 데이터를 기준으로 판단합니다. 이 규칙을 도메인 분류의 다른 표기라고 생각해서는 안 됩니다. 도메인 해석 결과, 주소 데이터, 실제 요청 형식이 모두 규칙 일치에 영향을 줍니다. 도메인 규칙이 적용되지 않는다면 요청 기록에 도메인과 주소 중 무엇이 표시되는지, 앞에서 일치한 규칙이 있는지 먼저 확인하세요. 대상 웹페이지 제목만 보고 판단해서는 안 됩니다.

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

이 내용은 학습용 규칙 예시이며 전체 연결 설정이 아닙니다. 첫 번째 줄은 해당 도메인 접미사와 일치하는 요청을 PROXY로 보냅니다. 두 번째 줄은 GEOIP 조건에 따라 DIRECT를 선택합니다. FINAL은 앞의 규칙에 일치하지 않은 요청에 마지막 정책을 지정합니다. 본인의 Config에 넣기 전에 백업하고 참조하는 정책을 현재 설정에서 사용할 수 있는지 확인하세요. 예시 도메인은 문법 설명용이며 특정 종류의 모든 사이트가 같은 정책을 써야 한다는 뜻이 아닙니다.

정책 이름, 최종 규칙, 설정 적용 여부

규칙 키워드는 '어떻게 일치하는지'를 정하고, 마지막 정책은 '일치한 뒤 어떻게 처리할지'를 정합니다. DIRECT, PROXY, REJECT는 역할이 다르므로 문제를 찾기 위해 모든 규칙을 같은 단어로 바꾸지 마세요. Config에서 사용자 지정 그룹을 사용한다면 규칙에서 참조하는 이름이 실제 정의와 일치해야 합니다. 이름 오타, 없는 그룹, 그룹 안에 사용 가능한 항목이 없는 경우에는 규칙이 올바르게 일치해도 예상한 결과가 나오지 않을 수 있습니다.

FINAL은 마지막에 검토할 규칙 뒤에 두어 최종 처리 역할을 하게 해야 합니다. 너무 앞에 있으면 뒤에 있는 규칙이 해당 요청을 처리할 기회가 없습니다. 규칙을 추가한 뒤 새 줄의 문법뿐 아니라 앞뒤 규칙의 범위도 확인하세요. 더 넓은 접미사 또는 키워드 규칙이 이미 대상을 포함하고 있을 수 있습니다. 문제를 해결할 때는 실제로 적용된 규칙부터 거슬러 확인하고, 파일 끝에 같은 규칙을 계속 추가하지 마세요.

수정이 끝나면 저장하고 현재 실제로 활성화된 Config 파일이 무엇인지 확인하세요. 파일을 열어 보았다고 해서 해당 파일이 연결에 사용 중이라는 뜻은 아닙니다. 규칙 세부 사항은 .conf 각 섹션 안내에서 확인할 수 있습니다. 설정 간 연관성을 살펴보려면 설정 안내를 참고하세요. 되돌릴 수 있는 사본을 보관한 뒤 범위를 분명히 정해 수정하면 전체 파일을 교체하는 것보다 검증하기 쉽습니다.

06 / DATA & OBSERVATION

Data 트래픽과 요청 기록 읽는 방법

통계 기준을 확인하고 숫자를 청구 내역으로 오해하지 마세요

Data에서는 앱에 표시되는 트래픽과 연결 정보를 확인할 수 있습니다. 구체적인 통계 항목은 현재 화면에 표시된 내용을 따릅니다. 수치를 보기 전에 어떤 시간 범위를 포함하는지, 재연결 뒤 달라지는지, 업로드와 다운로드를 구분하는지 확인하세요. 페이지마다 다른 항목을 기록할 수 있으므로 숫자가 다르다는 이유만으로 이상이라고 판단해서는 안 됩니다. 한 세션의 트래픽, 누적 트래픽, 시스템에서 앱별로 집계한 트래픽은 같은 기준이 아닙니다.

트래픽이 터널을 지날 때는 프로토콜 캡슐화, 핸드셰이크, 재전송, 백그라운드 요청이 발생할 수 있어 실제 파일 크기와 통계 수치가 정확히 일치하지 않을 수 있습니다. 이미지 캐시, 동영상 미리 불러오기, 시스템 백그라운드 작업도 관찰 결과를 바꿉니다. 특정 동작의 영향을 확인하려면 시작 수치를 기록하고 명확한 동작 하나를 실행한 뒤 종료 수치를 확인하세요. 하루 누적 수치를 방금 연 페이지 하나의 결과로 돌려서는 안 됩니다.

클라이언트에 표시된 트래픽은 서비스 제공업체의 사용량 기록이나 요금 산정 기준을 대신하지 않습니다. 시간 범위, 방향별 집계 방식, 통계 규칙이 서로 다를 수 있습니다. 구독 정보에 잔여 용량이 표시된다면 출처와 업데이트 시간도 확인하세요. 차이가 있을 때는 시간대와 작업 내역을 정리해 본인의 서비스 제공업체에 통계 기준을 문의하세요. 클라이언트 카운터를 초기화해 원격 기록을 바꾸려 해서는 안 됩니다.

요청 기록에서 실제 규칙 적용 여부 확인

접근 결과가 예상과 다를 때 요청 기록에서 유용한 항목은 대상, 시간, 적용 정책, 오류 단계입니다. 총 트래픽만 확인해서는 부족합니다. 대상을 다시 요청한 뒤 비슷한 시간의 기록을 찾아 캐시된 요청이나 오래된 연결을 현재 결과로 착각하지 않도록 하세요. 한 페이지에서 여러 요청이 발생한다면 실패한 항목을 각각 확인합니다. 기본 도메인에 접속된다고 모든 리소스가 같은 경로를 사용한다고 볼 수는 없습니다.

DIRECT 또는 PROXY 같은 정책이 표시되면 Config에서 어떤 규칙이 해당 정책을 적용했는지 확인하세요. 대상이 앞부분의 넓은 범위 규칙에 걸렸다면 파일 뒤에 정확한 규칙을 추가해도 결과가 바뀌지 않는 경우가 많습니다. 규칙 순서를 조정해 저장한 뒤 요청을 새로 보내야 변경된 규칙이 적용되는지 확인할 수 있습니다. 장시간 연결은 기존 경로를 유지할 수 있으므로 새 연결과 기존 세션을 구분하세요.

DNS 관련 오류는 '이름을 해석하지 못한 경우'와 '이름을 해석했지만 연결에 실패한 경우'를 구분해야 합니다. 전자는 이름 해석 설정, 현재 네트워크, 요청 도메인을 확인하고, 후자는 대상 주소, 포트, 경로도 점검해야 합니다. 오류 메시지 하나만으로 모든 원인을 추정하지 마세요. 표시되는 세부 정보는 요청 유형에 따라 달라질 수 있으며, 특정 항목이 없다고 해당 단계가 일어나지 않았다는 뜻은 아닙니다. 관찰 가능한 다른 정보와 함께 판단하세요.

트래픽, 배터리, 백그라운드 동작을 구분해 분석하세요

트래픽은 적은데 배터리 사용량이 높은 경우도 있을 수 있습니다. 자주 재연결하거나 기기가 계속 깨어 있거나 네트워크가 불안정하면 유효 트래픽이 많지 않아도 배터리가 소모될 수 있습니다. 반대로 짧은 시간 동안 큰 파일을 내려받으면 트래픽이 크게 늘 수 있습니다. 사용 시간을 비롯해 네트워크 종류와 작업 상황을 함께 기록하세요. 배터리 비율과 트래픽 크기를 단순 환산하거나 스크린샷 하나만으로 클라이언트 이상을 판단해서는 안 됩니다.

백그라운드에서 계속 동작하는 것 같다면 On Demand가 켜져 있는지, 앱 자동 새로 고침이 있는지, 기기가 네트워크를 반복해서 전환하는지 먼저 확인하세요. 네트워크와 사용 습관을 동일하게 유지하면서 On Demand 설정 하나만 바꾸는 식으로 비슷한 조건에서 비교합니다. 짧은 테스트는 시스템 작업의 영향을 받기 쉬우므로 몇 분간의 변동만으로 결론을 내리지 말고 반복 가능한 추세를 살펴보세요.

시스템 배터리 페이지와 Data 페이지는 통계 기간이 다를 수 있으므로 먼저 관찰 시간을 맞추세요. 백그라운드 동작에 대한 설명은 On Demand 및 배터리 문제 해결 안내에서 확인할 수 있습니다. 데이터 확인의 목적은 불필요한 활동과 재시도를 찾는 것이지 특정 수치를 맞추는 것이 아닙니다. 기기 모델, 네트워크 환경, 사용 방식이 다르므로 누구에게나 적용되는 단일 기준은 없습니다.

직접 관찰표를 만들 때는 날짜, 네트워크, 모드, Config 이름, 재현 동작, 결과만 남겨도 충분합니다. 모든 요청을 장기간 저장할 필요는 없습니다. 간단한 기록은 비교하기 쉽고 민감한 정보가 쌓이는 것도 줄여 줍니다. 추가 분석이 필요할 때만 구체적인 로그를 보완하고, 문제를 해결한 뒤에는 보관 범위를 다시 검토해 진단 도구와 일상 사용을 구분하세요.

08 / MAINTENANCE

구독 업데이트, 백업, 일상 관리

업데이트 전후의 실제 변경 사항 확인

일상 관리는 모든 설정을 자주 다시 만드는 것이 아니라 자료를 유효한 상태로 유지하는 데서 시작합니다. 구독을 업데이트하기 전에 어떤 항목을 업데이트하는지 확인하고, 업데이트 후에는 기록 수와 이름, 현재 선택된 항목에 변화가 있는지 살펴보세요. 기존 선택 항목이 교체되거나 제거되었다면 다시 선택한 뒤 연결을 확인해야 합니다. 업데이트가 완료되어 목록을 가져왔더라도 서버 테스트를 대신하지는 않습니다. 서버 목록을 업데이트했다고 규칙 설정도 자동으로 최신 상태가 되는 것은 아닙니다.

서비스 제공업체에서 주소나 인증 방식을 변경했다면 새로 제공된 정보에 맞춰 확인하세요. 기록의 메모만 바꾸면 해결되지 않습니다. 기존 주소로 잠시 접속할 수 있어도 계속 사용할 수 있다는 뜻은 아닙니다. 새 정보를 가져온 뒤 현재 네트워크에서 다시 확인하세요. 직접 추가한 기록은 구독 업데이트로 변경되지 않을 수 있으므로 별도로 관리해야 합니다. 출처가 서로 다른 비슷한 이름의 항목이 목록에 함께 남아 문제를 점검할 때 잘못 선택하지 않도록 하세요.

앱 업데이트는 App Store에서 진행하며 업데이트 정보와 호환성은 스토어 페이지를 따릅니다. 업데이트 전에는 사용 중인 설정을 백업하고, 업데이트 후에는 권한, 현재 서버, 주요 규칙을 확인할 수 있습니다. 동작이 달라졌다면 어떤 옵션이 바뀌지 않았을 것이라고 기억에 의존하지 말고 실제 설정과 앱 안내를 확인하세요. 앱, 구독, Config 업데이트를 각각 기록하면 변경 원인을 찾기 쉽습니다.

백업은 복구 가능성과 정보 보호를 함께 고려하세요

백업하기 전에 무엇을 복구할지 정하세요. 규칙 파일만 백업하면 서버 인증 정보가 포함되지 않을 수 있고, 서버 목록만 저장하면 사용자 지정 그룹이나 앱 설정이 빠질 수 있습니다. 앱의 내보내기 또는 백업 기능을 사용할 때 실제 옵션을 읽고 포함 범위를 확인하세요. 용도를 알아볼 수 있는 이름을 붙이고 관련 Config와 저장 시간을 기록하되, 파일 이름에 비밀번호나 전체 구독 주소를 넣지 마세요.

백업 파일에는 연결 자격 증명이 포함될 수 있으므로 보호되고 직접 관리할 수 있는 위치에 보관하세요. 시스템 파일 기능이나 개인 저장 공간을 통해 옮길 때는 받는 기기와 계정이 올바른지 확인하고 공개 공유 위치를 잘못 선택하지 않도록 주의하세요. 규칙 예시를 다른 사람에게 제공하려면 전체 백업을 보내지 말고 민감한 정보를 제거한 사본을 따로 만드세요. 겉으로는 규칙만 보여도 파일의 다른 부분에 인증 정보나 구독 내용이 남아 있을 수 있습니다.

내보내기에 성공했다고 복구까지 완료된 것은 아닙니다. 파일을 찾을 수 있고 내용이 온전한지, 앱에서 다시 가져오는 방법을 알고 있는지 확인하세요. 실제로 기기를 옮길 때는 기존 기기의 자료를 보관한 상태로 새 기기에 가져온 뒤 서버, Config, Global Routing을 확인하고 실제 요청으로 연결을 테스트합니다. 새 기기에서 검증하기 전에 기존의 유일한 작동 설정을 삭제하지 마세요.

기기 교체, 재설치, 장기간 미사용 후 확인

기기를 바꾸거나 앱을 다시 설치한 뒤에는 구매 계정의 App Store 구입 항목에서 Shadowrocket을 받으세요. 구매 적용 여부는 스토어에 표시된 내용을 따릅니다. 앱을 다시 받는 일과 연결 정보를 복구하는 일은 별개이며, App Store 구매 내역만으로 설정이 복구되었다고 볼 수 없습니다. 백업을 가져온 뒤 시스템 VPN 권한을 다시 처리해야 할 수도 있습니다. 그런 다음 새 기기에 맞지 않는 설정을 그대로 사용하지 않도록 현재 Config와 On Demand 조건을 다시 확인하세요.

오랫동안 사용하지 않다가 다시 시작한다면 먼저 기본 네트워크를 확인한 다음 구독과 서버의 유효 상태를 확인하세요. 기기 시간이 맞지 않거나 서비스 정보가 바뀌었거나 오래된 설정이 남아 있으면 연결에 영향을 줄 수 있습니다. 처음부터 모든 규칙을 바꿀 필요는 없습니다. 유효한 기존 기록으로 수동 테스트를 한 번 진행하고 성공한 뒤 On Demand와 기타 보조 설정을 복원하세요. 단계별로 다시 켜면 자료가 만료된 문제와 기기 설정 문제를 구분할 수 있습니다.

오래된 기록을 삭제하기 전에 그룹이나 규칙에서 참조하는지 확인하고 사용할 수 있는 대체 항목이 있는지도 점검하세요. 중복 기록은 정리할 수 있지만 이름이 비슷하다는 이유만으로 삭제해서는 안 됩니다. 프로토콜이나 매개변수가 서로 다를 수 있습니다. 삭제한 뒤 자주 사용하는 접근 경로를 다시 확인해 존재하지 않는 항목을 참조하는 설정이 남지 않았는지 살펴보세요. 정리의 목적은 목록을 최대한 줄이는 것이 아니라 모호하고 오래된 정보를 없애는 데 있습니다.

문제가 계속되면 앱 실행 여부, VPN 연결 여부, 구독 업데이트 여부, 실패한 모드, 영향을 받는 대상 등을 짧게 정리하세요. 이 결과를 연결 및 확인 장과 비교하면 반복해서 재설치하는 것보다 문제를 좁히기 쉽습니다. 처음부터 전체 과정을 다시 확인하려면 빠른 시작 튜토리얼을 이용하세요. 구매 또는 재다운로드 문제만 있다면 구입 항목 복원 안내를 참고하세요.

가이드 목차로 돌아가기 ↑