공식 가이드 / 기능 및 주요 설정
Shadowrocket 설정 방법
먼저 Global Routing 작동 방식을 정하고 Config의 규칙과 정책을 확인한 다음 주문형 연결, DNS, 테스트 옵션을 조정하세요. 한 번에 하나씩 변경하고 같은 대상으로 검증해야 변경 원인을 파악할 수 있습니다.
- 라우팅 메뉴 Global Routing
- 구성 메뉴 Config
- 통계 메뉴 Data
기능별 설정 찾기
아래 링크는 페이지 내 해당 절로 이동하며 본문을 전환하거나 숨기지 않습니다. 각 항목의 명칭은 기기에 표시되는 현재 앱 화면을 기준으로 합니다. 메뉴 위치가 다르면 영어 명칭으로 먼저 찾아보고 다른 설정 항목을 대신 적용하지 마세요.
Global Routing: Config, Proxy, Direct
기능: Global Routing은 요청을 처리할 때 클라이언트가 사용할 라우팅 방식을 결정합니다. 자주 사용하는 모드는 Config(구성), Proxy(프록시), Direct(직접 연결)입니다. 속도 설정이 아니라 구성 규칙에 따라 요청의 목적지를 판단할지 결정하는 방식입니다.
위치 및 설정 방법: Home에서 Global Routing을 열고 원하는 모드를 선택한 뒤 돌아와 현재 선택을 확인하세요. 도메인이나 주소 등의 조건에 따라 평소처럼 트래픽을 분기하려면 Config를 사용합니다. 선택한 프록시 연결을 잠시 확인하려면 Proxy를, 로컬 네트워크의 직접 접속 상태와 비교하려면 Direct를 선택하세요.
| 화면 옵션 | 작동 방식 | 사용 상황 | 먼저 확인할 항목 |
|---|---|---|---|
| Config(구성) | 현재 활성화된 구성의 규칙과 정책에 따라 요청을 처리합니다. | 직접 연결, 프록시 또는 거부를 구분해야 하는 일반적인 사용 상황 | 활성화된 파일, 규칙 순서, 정책 이름 |
| Proxy(프록시) | 클라이언트가 처리하는 요청을 프록시 방식으로 다룹니다. 앱과 시스템의 관련 처리 조건도 고려해야 합니다. | 규칙의 영향을 분리해 선택한 프록시를 사용할 수 있는지 확인할 때 | 선택한 서버, 연결 매개변수, 테스트 대상 |
| Direct(직접 연결) | 클라이언트가 처리하는 요청을 직접 연결 방식으로 다룹니다. | 로컬 네트워크와 비교해 프록시 경로에 문제가 있는지 확인할 때 | 현재 네트워크에서 같은 대상에 접속할 수 있는지 |
유의 사항: Direct를 선택해도 클라이언트 연결이 종료되는 것은 아니며, Proxy를 선택해도 시스템의 모든 통신이 반드시 같은 경로를 이용하는 것은 아닙니다. 모드를 바꾼 뒤에도 기존 장시간 연결은 이전 상태를 유지할 수 있습니다. 확인할 때는 요청을 새로 보내고, 필요하면 관련 연결을 종료한 다음 테스트하세요. 문제를 확인하려고 Proxy로 잠시 전환했다면 필요한 Config 모드로 다시 돌려놓으세요.
규칙 기반 라우팅: 일치 조건과 정책 대상
기능: 규칙은 일치 조건과 처리 정책으로 구성됩니다. 일치 조건은 ‘어떤 요청인가’를, 정책은 ‘일치한 요청을 어디로 보낼 것인가’를 정합니다. Config 모드에서는 일반적으로 규칙을 순서대로 확인하며, 앞의 규칙이 일치하면 뒤의 규칙이 적용되지 않을 수 있습니다. 따라서 범위가 좁고 명확한 예외 규칙을 포괄적인 조건보다 앞에 배치하세요.
위치 및 설정 방법: Config에서 현재 활성화된 파일을 확인하고 해당 편집 메뉴에서 규칙을 살펴보세요. 먼저 대상을 전체 도메인, 도메인 접미사, IP 대역 중 어떤 기준으로 일치시킬지 정한 뒤 규칙 값과 정책을 입력합니다. 저장 후 방금 수정한 파일이 활성화되어 있는지 확인하고 같은 대상으로 연결을 다시 시도하세요.
| 규칙 키워드 | 일치 기준 | 확인할 사항 |
|---|---|---|
DOMAIN | 전체 도메인 | 도메인만 입력하고 경로나 프로토콜 접두사는 입력하지 마세요. |
DOMAIN-SUFFIX | 도메인 접미사와 해당 하위 도메인 | 접미사 범위가 여러 서비스를 포함할 수 있습니다. |
DOMAIN-KEYWORD | 도메인에 포함된 키워드 | 일치 범위가 넓으므로 잘못 일치하는 사례부터 확인하세요. |
IP-CIDR / IP-CIDR6 | IPv4 / IPv6 주소 대역 | 주소 체계, 프리픽스 길이, 해석 조건을 확인하세요. |
GEOIP | IP 지리 정보 데이터 | 데이터상의 지역이 서비스의 실제 이용 지역과 같다는 뜻은 아닙니다. |
FINAL | 앞선 규칙이 일치하지 않을 때 적용되는 최종 대상 | 마지막 규칙으로 배치해 기본 처리에 사용하세요. |
DIRECT, PROXY, REJECT
DIRECT는 직접 연결, PROXY는 프록시 정책 사용, REJECT는 요청 거부를 뜻합니다. 구성에서 사용자 지정 정책 그룹 이름을 참조할 수도 있습니다. 해당 이름은 구성에 정의되어 있어야 하며, 이름만 보고 실제 연결 경로를 추측해서는 안 됩니다. 규칙 키워드의 대소문자와 구분 기호는 형식에 맞게 유지하세요.
아래는 규칙 문법을 설명하기 위한 예시일 뿐, 앱 화면이나 기존 파일을 그대로 덮어쓸 수 있는 완성된 구성은 아닙니다. 예시의 example.com은 접미사 일치 방식을 설명하기 위한 것입니다.
DOMAIN-SUFFIX,apple.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY
유의 사항: 규칙이 예상대로 작동하지 않으면 앞쪽 규칙이 이미 일치했는지 확인한 다음 요청 기록에 표시된 실제 도메인과 IP를 점검하세요. 한 페이지가 여러 도메인에 접속할 수 있으므로 주 도메인에만 규칙을 추가하면 모든 리소스가 처리되지 않을 수 있습니다. 실제 일치 문제를 가리기 위해 범위가 넓은 키워드를 계속 추가하지 마세요.
Subscribe: 기존 구독 및 서버 관리
기능: Subscribe는 사용자가 이미 보유한 구독 주소에서 서버 정보를 가져와 업데이트하는 기능입니다. 구독은 일반적으로 여러 서버를 관리하며, 서버를 직접 추가하면 각 매개변수를 사용자가 관리합니다. 구독 업데이트와 App Store 앱 업데이트는 서로 다른 작업이며, 한쪽을 업데이트해도 다른 쪽이 자동으로 업데이트되지는 않습니다.
위치 및 설정 방법: Home에서 추가 메뉴를 열어 Add Server로 이동합니다. 현재 화면에 Subscribe 옵션이 있으면 본인의 구독 주소와 메모를 입력하고 저장한 뒤 업데이트를 실행하세요. 이후 그룹과 항목이 표시되는지 확인합니다. 기존 QR 코드가 있다면 Scan QR Code로 가져올 수 있습니다. 가져온 뒤에는 메모 이름만 보지 말고 유형, 주소, 포트도 확인하세요.
서버를 직접 관리하려면 Add Server에서 올바른 프로토콜 유형을 먼저 선택한 다음 주소, 포트, 해당 인증 정보를 입력하세요. 메모는 항목을 구분하기 위한 것으로 연결 방식에는 영향을 주지 않습니다. 용도나 사용자 지정 이름을 알기 쉽게 설정해 항목을 구분하면 이름이 같은 여러 항목 중 잘못 선택하는 일을 줄일 수 있습니다.
유의 사항: 구독 주소에는 개인 접근 정보가 포함될 수 있으므로 공개 스크린샷, 로그, 문의 내용에 넣지 마세요. 업데이트 후에는 원본 내용에 따라 항목 이름, 그룹, 개수가 달라질 수 있습니다. 구독 항목을 직접 수정한 내용도 이후 업데이트의 영향을 받을 수 있으므로 변경 전에 필요한 정보를 기록해 두세요. 업데이트에 실패하면 주소 오류, 요청 시간 초과, 콘텐츠 해석 실패를 구분하고, 아직 사용할 수 있는 항목 전체를 성급하게 삭제하지 마세요.
이 사이트에서는 이미 보유한 정보의 가져오기와 관리 방법만 안내합니다. 구독의 유효성, 여러 기기에서의 사용 가능 여부와 서비스 기간은 사용자가 이용 중인 서비스의 안내를 확인하세요. 앱 구매 기록만으로 이를 판단할 수는 없습니다.
다중 프로토콜: 유형 확인 후 매개변수 입력
기능: 프로토콜은 클라이언트와 서버가 연결을 설정하고 데이터를 주고받는 방식을 정합니다. Shadowrocket은 다양한 프로토콜을 지원하며, 대표적인 이름으로 Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard, Hysteria2가 있습니다. 선택할 수 있는 유형과 매개변수는 앱의 Add Server 화면을 기준으로 확인하세요.
위치 및 설정 방법: Add Server에서 기존 서버 정보에 맞는 프로토콜을 선택하세요. 그런 다음 주소, 포트, 인증 정보와 해당 유형에 필요한 TLS 또는 전송 관련 항목을 하나씩 확인합니다. 가져오기 링크에도 올바른 유형이 지정되어 있어야 합니다. 한 프로토콜의 항목을 다른 유형에 그대로 옮겨 입력하지 마세요.
유의 사항: 서버 주소가 같아도 프로토콜이 다르면 서로 바꿔 쓸 수 없으며, 표시 이름만으로 매개변수가 올바른지 판단할 수도 없습니다. 도메인, TLS 검증 이름, 전송 경로 등은 각각 용도가 다르므로 입력 전에 본인의 연결 정보를 확인하세요. 연결에 실패하면 먼저 누락된 항목이나 입력 오류를 확인하고, 인증서 검증 비활성화는 일반적인 문제 해결 방법으로 사용하지 마세요. 프로토콜 이름만으로 특정 네트워크에서의 속도나 안정성을 보장할 수 없습니다.
Config: 구성 파일 활성화 및 변경
기능: Config는 구성 파일을 관리하는 메뉴입니다. 구성에는 규칙, 정책 및 기타 관련 옵션이 포함될 수 있습니다. 서버 구독은 주로 연결 항목을 가져오고 업데이트하는 기능이므로 두 기능은 용도가 다릅니다. 구독을 가져왔다고 해서 트래픽 분할 규칙까지 개인의 필요에 맞게 설정되었다고 가정하지 마세요.
위치 및 설정 방법: Config에서 파일 목록을 확인하고 현재 활성화된 항목을 기록한 다음 변경할 파일을 여세요. 편집 전에 원본 파일을 복사해 두고 기존 규칙과 정책 그룹의 관계를 확인합니다. 저장 후 해당 파일을 선택하고 현재 활성화 상태를 확인하세요. 원격 파일을 사용하는 경우에는 업데이트 여부를 결정하기 전에 콘텐츠의 용도와 신뢰성을 확인하세요.
유의 사항: 원격 파일을 업데이트하면 특히 규칙 순서, 정책 그룹 이름, 해석 설정 등 기존에 예상한 내용이 달라질 수 있습니다. 출처가 다른 규칙 조각을 참조 관계 확인 없이 합치지 마세요. 문제가 생기면 변경을 계속 추가하는 것보다 이전에 정상 작동을 확인한 파일로 복원하는 편이 원인을 찾기 쉽습니다. 구성에 개인 주소나 인증 정보가 포함된 경우 백업과 동기화 시에도 민감 정보로 취급하세요.
On Demand: 조건에 따른 연결
기능: On Demand는 조건에 따라 시스템 VPN 연결을 시작하거나 유지하는 기능입니다. 규칙 기반 라우팅과는 설정 단계가 다릅니다. On Demand는 ‘언제 연결할지’를 처리하고 Config의 규칙은 ‘연결 후 요청을 어디로 보낼지’를 처리합니다. 주문형 연결을 켜도 서버 매개변수가 수정되거나 규칙이 자동으로 추가되지는 않습니다.
위치 및 설정 방법: 앱에서 On Demand 설정 메뉴를 열고 기존 조건을 확인한 뒤 현재 화면에서 지원하는 네트워크 조건에 따라 규칙을 추가하세요. Wi-Fi, 셀룰러 네트워크, 도메인 관련 조건 등을 기준으로 동작을 설정할 수 있으며, 구체적인 동작과 항목은 앱 화면을 기준으로 확인해야 합니다. 처음에는 명확한 조건 하나만 설정하고 제대로 작동하는지 확인한 뒤 확장하는 편이 좋습니다.
- 먼저 수동 연결 상태에서 기존 서버와 구성이 정상적으로 작동하는지 확인합니다.
- 테스트에 사용할 네트워크를 기록하고 관련 조건과 동작을 추가한 뒤 규칙 순서를 확인합니다.
- 조건에 맞는 네트워크로 전환해 시스템 VPN 상태와 실제 요청을 확인합니다.
- 조건에 맞지 않는 상황에서도 테스트해 예상치 못한 재연결이나 연결 해제가 없는지 확인합니다.
유의 사항: Wi-Fi 이름이 정확한지 확인하고 여러 조건이 겹치면 적용 순서를 점검하세요. On Demand가 켜져 있으면 조건이 다시 충족될 때 수동으로 연결을 끊어도 다시 연결될 수 있습니다. 이는 문제를 확인할 때 먼저 고려해야 할 사항입니다. 일시적인 문제 해결 중에는 자동 동작이 비교에 영향을 주지 않도록 주문형 연결을 먼저 비활성화하세요. 테스트가 끝나면 원래 설정으로 복구합니다. 주문형 연결을 사용해도 백그라운드 통신이 중단되는 것은 아니며, 배터리 사용량은 실제 요청, 네트워크 상태, 재연결 빈도에 따라 달라집니다.
Data: 데이터 사용량 통계 및 요청 확인
기능: Data에서는 클라이언트가 기록한 범위의 데이터 사용량을 확인할 수 있으며, 업로드와 다운로드 및 관련 요청의 변화를 살펴보는 데 유용합니다. ‘어느 시간대에 데이터가 전송됐는지’, ‘추가로 확인할 요청이 무엇인지’를 파악하는 데 적합하지만, 셀룰러 요금 청구 내역이나 사용 중인 서비스의 데이터 기록을 대신하지는 않습니다.
위치 및 설정 방법: Data를 열고 먼저 현재 통계 범위와 표시 기준을 확인한 뒤 관련 기록을 살펴보세요. 특정 대상을 테스트할 때는 시작 시각을 기록하고 새 요청을 몇 건 보낸 다음 데이터 사용량 변화를 비교합니다. 라우팅 결과를 더 확인해야 한다면 앱에서 볼 수 있는 연결 기록을 함께 확인해 대상과 처리 경로를 점검하세요. 통계를 초기화하기 전에 비교에 필요한 값을 저장해 두세요.
유의 사항: 앱 기록, 시스템 통계, 원격 서비스의 사용량은 집계 시간, 프로토콜 오버헤드, 집계 범위가 달라 서로 일치하지 않을 수 있습니다. 다운로드 수치가 크다는 이유만으로 특정 규칙에 문제가 있다고 판단하지 마세요. 테스트 중 다른 앱의 백그라운드 통신을 테스트 대상 요청으로 간주해서도 안 됩니다. 문제를 확인할 때는 테스트 조건을 최대한 동일하게 유지하고 동기화나 미디어 재생 등 동시에 발생하는 전송을 피하세요.
Settings: 해석, 테스트, 구성요소 및 동기화
Settings의 옵션은 서로 다른 동작에 영향을 줍니다. 해결하려는 문제를 먼저 정한 다음 해당 설정을 조정하세요. 기능 이름, 지원 범위, 메뉴 위치는 현재 앱과 시스템에 표시되는 내용을 기준으로 확인해야 합니다.
DNS: 이름 해석 문제와 연결 문제 구분
기능 및 위치: DNS는 도메인 이름을 IP 주소로 변환합니다. Settings에서 DNS 관련 옵션을 확인할 때는 현재 Config에 해석 설정이 포함되어 있는지도 확인하세요. 실제 사용 중이 아닌 항목만 변경하는 일을 방지할 수 있습니다.
설정 방법 및 유의 사항: 기존 값을 먼저 보관하고 같은 도메인으로 해석이 정상적으로 되는지 확인한 다음 현재 네트워크에 맞춰 시스템 DNS 또는 사용자 지정 해석 방식을 선택하세요. DNS over HTTPS를 사용하는 경우 해석 서비스에 접속할 수 있는지도 고려해야 합니다. 해석 요청에 아직 설정되지 않은 연결 경로가 필요하면 연결 시작에 문제가 생길 수 있습니다. 웹페이지가 열리지 않는 원인이 반드시 DNS인 것은 아니므로 잘못된 주소, 서버 인증, 규칙의 연결 대상을 각각 확인하세요. 자세한 원리는 DNS 설정 안내를 참고하세요.
Test Method: 동일한 테스트 방식으로 비교
기능 및 위치: Settings의 Test Method는 Connectivity Test에서 사용하는 테스트 방식에 영향을 줍니다. 테스트 결과는 선택한 방식, 대상, 당시 네트워크 상태를 반영할 뿐이며 서버의 전체적인 사용 경험을 보장하지 않습니다.
설정 방법 및 유의 사항: 화면에서 제공하는 방식 중 하나를 선택하고 테스트 대상과 네트워크를 유지한 상태에서 기존 항목과 비교하세요. 방식이 다른 결과의 수치를 그대로 순위 매기기는 어렵습니다. 테스트 시간이 초과되어도 모든 앱 요청이 연결되지 않는다는 뜻은 아닙니다. 실제로 접속하려는 대상으로 다시 확인하고 핸드셰이크 실패, 이름 해석 실패, 대상 응답 지연을 구분하세요. 순간적으로 가장 낮은 값을 얻으려고 반복 테스트하지 마세요.
Today Widget: 빠른 조작 후 상태 확인
기능 및 위치: Today Widget은 시스템 위젯에서 빠른 메뉴를 제공합니다. 관련 옵션은 Settings에서 확인하고 위젯은 시스템의 위젯 편집 화면에서 추가하세요. 사용할 수 있는 형식은 기기와 시스템에 실제로 표시되는 항목에 따라 다릅니다.
설정 방법 및 유의 사항: 먼저 메인 앱에서 서버와 라우팅을 설정한 다음 필요한 위젯을 추가하세요. 위젯에서 작업한 뒤 Home으로 돌아가 연결 상태와 선택된 항목을 확인할 수 있습니다. 시스템 위젯은 갱신이 지연될 수 있으므로 오래된 위젯 문구만 보고 현재 연결 상태를 판단하지 마세요. 작업이 적용되지 않았다면 메인 앱을 열어 권한과 상태를 확인하세요.
iCloud: 동기화 범위와 기기별 차이
기능 및 위치: iCloud 관련 옵션은 앱에서 지원하는 범위 내의 데이터를 동기화합니다. Settings에서 앱의 동기화 옵션을 확인하고 시스템의 iCloud 접근 권한도 점검하세요. 앱 구매 내역과 구성 동기화는 서로 다른 방식이므로 혼동하지 마세요.
설정 방법 및 유의 사항: 원래 사용하던 기기에서 동기화 상태를 확인한 다음 다른 기기에서 실제로 동기화된 항목을 점검하세요. 변경 전에는 복원할 수 있도록 구성을 따로 보관해 두세요. 모든 로컬 기록, 시스템 VPN 권한, 기기 상태가 완전히 이전된다고 가정하지 마세요. 동기화되는 데이터에 개인 서버 정보가 포함될 수 있으므로 계정과 기기 접근 권한을 적절히 관리하세요. 새 기기에서 처음 연결할 때는 시스템 안내에 따라 필요한 권한을 설정해야 합니다.
Diagnostics: 비교 기록으로 문제 확인
기능: Diagnostics는 문제 해결에 필요한 정보를 확인하거나 수집하는 메뉴입니다. 진단의 목적은 모든 옵션을 한꺼번에 변경하는 것이 아니라, 실패 원인을 로컬 네트워크, 서버 연결, 도메인 해석, 규칙 처리 중 어느 단계에서 발생했는지 좁히는 것입니다.
위치 및 설정 방법: Settings에서 Diagnostics를 찾아 현재 화면에서 제공하는 도구로 연결이나 기록을 확인하세요. 먼저 실패한 대상, 네트워크 유형, Global Routing 모드, 활성화된 Config를 기록한 뒤 문제를 한 번 재현합니다. 진단을 위해 일시적으로 기록을 켰다면 재현 후 바로 끄고 내보낸 내용에 민감 정보가 포함되어 있는지 확인하세요.
- 기본 네트워크 확인. 기기의 현재 네트워크가 정상적으로 작동하는지 확인하고, 네트워크 전체 문제와 특정 대상만의 문제를 구분하세요.
- 서버 확인. 기존 연결 정보를 점검하고 Connectivity Test를 실행하세요. 결과 수치만 기록하지 말고 테스트 방식도 함께 기록합니다.
- 모드와 규칙 확인. 일시적으로 Proxy를 사용해 Config와 비교하세요. 결과가 다르면 규칙 일치 여부와 정책 참조를 확인합니다.
- 이름 해석 확인. 도메인 해석에 문제가 있을 때만 DNS를 확인하고 서버 인증 실패를 해석 문제로 판단하지 마세요.
- 테스트 변경 사항 복구. 원래 모드, 주문형 조건, 기록 설정으로 되돌리고 한 번에 하나씩 변경하며 확인한 결과를 보관하세요.
유의 사항: 진단 기록에 접속 도메인, 서버 주소, 구독 매개변수, 인증 정보가 노출될 수 있습니다. 외부에 문제를 설명할 때는 오류 유형과 필요한 맥락만 남기고 개인 정보가 담긴 항목은 가리세요. 전체 구성이나 원본 구독 주소를 공개하지 마세요. 도구 출력은 여러 증거 중 하나이므로 실제 요청 및 현재 설정과 함께 판단해야 합니다.