공식 매뉴얼 · 기능 및 주요 설정

Shadowrocket 기능 및 설정

먼저 Global Routing을 확인한 다음 서버, 규칙, DNS를 점검하세요. 연결 스위치, 라우팅 모드, On Demand는 각각 역할이 다르므로 따로 확인해야 합니다.

Shadowrocket은 Apple 플랫폼용 클로즈드 소스 상용 앱으로, 주로 iPhone과 iPad에서 사용합니다. 유일한 구매 경로는 App Store입니다. 시스템 요구 사항과 기기 호환성은 App Store 페이지의 안내를 확인하세요. 앱이나 구매 정보를 확인하려면 먼저 App Store 정식 구매 안내를 읽고, 처음 사용하는 경우 사용 가이드를 참고하세요.

라우팅 설정

Global Routing: 설정, 프록시, 직접 연결

Global Routing은 요청에 적용할 전체 라우팅 방식을 결정합니다. Home에서 Global Routing을 열고 필요에 따라 Config, Proxy 또는 Direct를 선택하세요. Config는 규칙에 따라 요청을 분류할 때, Proxy는 선택한 서버의 연결 가능 여부를 잠시 확인할 때 사용할 수 있습니다. 직접 연결 경로와 비교하려면 Direct를 선택하세요.

화면 옵션 주요 동작 사용 상황 확인할 항목
Config(구성) 현재 구성 파일의 규칙에 따라 요청 처리 방식을 결정합니다. 대상별로 PROXY, DIRECT 또는 REJECT를 적용합니다. 현재 선택된 구성 파일, 규칙 순서, 최종 적용 정책
Proxy(프록시) 트래픽을 프록시로 처리합니다. 앱과 시스템의 관련 예외도 확인해야 합니다. 규칙에 따른 차이를 줄여 서버 연결을 임시로 점검할 때 선택한 서버, 인증 항목, 실제 연결 가능 여부
Direct(직접 연결) 직접 연결을 사용하며 일반 요청을 선택한 프록시 서버로 전달하지 않습니다. 같은 대상에 로컬 네트워크로 직접 접속할 수 있는지 비교할 때 로컬 네트워크, 대상 서비스, 도메인 이름 확인이 정상인지

설정을 변경하기 전에 기존 옵션을 기록하고 Global Routing만 바꾼 뒤 같은 대상에 다시 접속해 보세요. Proxy에서는 접속되지만 Config에서 실패하면 규칙과 현재 구성부터 확인하세요. 두 모드 모두 실패한다면 서버 설정, DNS, 로컬 네트워크를 점검하세요. 이는 원인을 좁히는 방법이며 한 번의 결과만으로 원인을 단정할 수는 없습니다.

Global Routing은 연결 스위치가 아닙니다. Proxy를 선택해도 터널이 연결된 것은 아니며, Direct를 선택해도 시스템 VPN 연결이 해제되는 것은 아닙니다. Home에서 연결 상태도 확인하세요. 점검을 마친 뒤에는 원래 필요한 모드로 되돌려 임시 설정이 계속 사용되지 않도록 하세요.

규칙 및 정책

Rule: 조건에 따라 연결 경로 결정

규칙은 요청을 매칭하고, 정책은 요청을 처리합니다. 먼저 Config에서 현재 활성화된 구성 파일을 확인한 다음 [Rule] 섹션을 살펴보거나 편집하세요. Global Routing이 Config일 때 규칙은 위에서 아래 순서로 평가되며, 매칭된 규칙의 정책이 적용됩니다. 범위가 명확한 조건을 앞에 두고 마지막에 기본 처리 규칙인 FINAL을 배치하면 읽고 점검하기 쉽습니다.

DOMAIN은 지정한 도메인과 매칭되고, DOMAIN-SUFFIX는 도메인 및 하위 도메인과 매칭됩니다. DOMAIN-KEYWORD는 도메인에 포함된 키워드로 매칭합니다. IP-CIDR과 IP-CIDR6은 각각 IP 주소 대역에 사용하고, GEOIP는 대상 IP의 소속 국가·지역 정보로 판단합니다. USER-AGENT는 요청 헤더 정보가 제공되어야 하므로 모든 연결에서 앱을 식별할 수 있는 범용 조건은 아닙니다.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,ads,REJECT
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

위 예시는 문법과 순서를 설명하기 위한 것으로, 모든 네트워크에 적용할 수 있는 완성된 구성은 아닙니다. PROXY는 프록시 정책을 사용한다는 뜻이며 실제 연결 출구는 현재 선택과 구성에 따라 달라집니다. DIRECT는 대상에 직접 연결하고, REJECT는 요청을 거부합니다. ads라는 키워드도 예시일 뿐이며 문자열로 매칭되므로 특정 유형의 콘텐츠를 정확히 식별하지는 않습니다.

편집하기 전에 기존 구성을 보관하고, 저장한 뒤 수정한 파일이 계속 선택되어 있는지 확인하세요. 검증할 때는 새 요청을 보내고, 확인 가능한 연결 기록에서 대상과 매칭된 규칙을 살펴보세요. 기존 연결에는 이전 처리 결과가 적용될 수 있습니다. 각 섹션의 구조, 정책, 우선순위를 알아보려면 규칙 및 구성 항목 참고를 읽고, 의미를 설명할 수 없는 규칙을 한 번에 많이 추가하지 마세요.

연결 정보

Subscribe 및 Add Server: 보유한 정보 관리

서버 항목에는 연결 매개변수를 저장하고, 구독은 여러 항목을 가져오고 업데이트하는 데 사용합니다. Home에서 Add Server를 눌러 보유한 서버 정보를 추가하거나, Type에서 Subscribe를 선택한 뒤 보유한 구독 주소를 입력하세요. 앱에 Scan QR Code 등의 메뉴가 있으면 본인의 연결 정보를 불러오는 데 사용할 수 있습니다. 저장하기 전에 유형을 확인하세요. 구독 주소와 개별 서버 공유 정보는 서로 다른 데이터입니다.

직접 입력할 때는 프로토콜 유형을 서버 측 설정과 일치시켜야 합니다. Shadowsocks, VMess, VLESS, Trojan, WireGuard, Hysteria2, HTTP, SOCKS5는 필요한 항목이 서로 다릅니다. 주소, 포트, 인증 정보, 전송 설정은 보유한 정보에 따라 하나씩 입력하세요. TLS를 사용하는 경우 인증서 검증과 관련 도메인 설정도 확인해야 합니다. 이름이 비슷하다는 이유로 항목을 바꾸어 쓰거나, 연결을 성립시키려고 검증을 임의로 끄지 마세요.

구독을 업데이트하면 원격 콘텐츠를 다시 가져오므로 로컬 항목의 이름, 개수, 매개변수가 바뀔 수 있습니다. 직접 편집한 항목을 유지해야 한다면 구독 관리 범위에 포함되는지 먼저 확인하고 필요한 백업을 보관하세요. 용도별로 알아보기 쉬운 이름을 지정하면 Home에서 현재 선택 항목을 확인하기 편하지만, 이름 자체가 라우팅 정책을 바꾸지는 않습니다.

가져오기가 끝나면 서버 하나를 선택하고 Connectivity Test를 실행한 뒤 실제 요청으로 확인하세요. 테스트 결과가 있다는 것만으로 인증, 도메인 이름 확인, 대상 접속이 모두 정상이라고 볼 수는 없습니다. 구독 주소에는 접근 정보가 포함될 수 있으므로 공개 스크린샷, 진단 첨부 파일, 공유 구성에 넣지 마세요. 문제 해결 정보를 공유하기 전에 주소의 민감한 부분과 서버 인증 항목을 가리세요.

연결 트리거

On Demand: 네트워크 조건에 따라 연결

On Demand는 설정한 조건에 따라 연결을 시작하며, 각 요청의 라우팅 경로를 결정하지는 않습니다. Settings에서 On Demand 관련 옵션을 확인하고 앱에서 제공하는 Wi-Fi, 셀룰러 네트워크 또는 지정 네트워크 조건에 맞춰 설정하세요. 메뉴와 선택지는 기기에 표시되는 내용을 기준으로 확인하세요. 처음 활성화하기 전에 수동 연결이 정상적으로 작동하는지 먼저 확인하세요.

먼저 특정 유형의 네트워크에서만 활성화하는 등 조건을 하나 명확하게 설정하고, 네트워크를 전환해 실제 동작을 확인하세요. 테스트 중에는 Home과 시스템 VPN 상태를 살펴보세요. 조건이 충족될 때 연결되는지, 해당 네트워크에서 벗어난 뒤 예상대로 동작하는지 확인해야 합니다. 특정 Wi-Fi 조건을 사용하는 경우 네트워크 이름을 확인해 비슷한 이름의 네트워크를 같은 조건으로 혼동하지 않도록 하세요.

On Demand와 Global Routing은 함께 작동할 수 있습니다. 전자는 연결을 시작할 시점을 정하고, 후자는 연결 후 요청을 처리하는 방식을 결정합니다. 수동으로 연결을 끊어도 트리거 조건이 계속 충족되면 시스템이 다시 연결할 수 있습니다. 잠시 중지하려면 연결 스위치를 반복해서 조작하는 대신 On Demand 설정도 확인하세요.

On Demand 사용 시 배터리 소모는 네트워크 전환 빈도, 실제 트래픽, 재연결 여부에 따라 달라지므로 스위치 상태만으로 판단할 수 없습니다. 시스템 배터리 설정에서 관찰 시간과 사용 환경을 함께 고려해 사용량을 확인하세요. 재연결이 잦다면 트리거 조건과 서버 안정성을 먼저 점검한 뒤 규칙을 조정하고, 여러 변수를 동시에 바꾸지 마세요.

사용량 확인

Data: 트래픽 통계 확인

Data에서는 앱이 기록한 트래픽 정보를 확인할 수 있어 사용 추세를 살펴보거나 비정상적인 증가를 점검하는 데 유용합니다. Data를 열고 현재 화면의 통계 범위와 기간, 업로드·다운로드 구분을 확인한 뒤 수치를 살펴보세요. 화면마다 연결 범위나 집계 범위가 다를 수 있으므로 실제 표시 내용을 기준으로 판단해야 합니다. 일부 통계를 기기 전체의 총 트래픽으로 간주해서는 안 됩니다.

특정 작업에서 발생한 트래픽을 확인하려면 기존 수치를 기록하고 눈에 띄는 다른 네트워크 활동을 잠시 중단한 뒤, 같은 작업을 한 번 수행해 변화를 비교하세요. 앱 백그라운드 동기화, 미디어 사전 로드, 시스템 네트워크 활동이 동시에 일어날 수 있으므로 짧은 시간 동안의 차이가 방금 연 페이지에서만 발생했다고 볼 수는 없습니다. 통계 범위를 변경하거나 기록을 지우기 전에 필요한 관찰 결과를 저장하세요.

Data 기록, 시스템 셀룰러 네트워크 통계, 사용자가 보유한 서비스의 사용량 기록은 시작·종료 시점과 측정 방식이 다를 수 있습니다. 전송 오버헤드, 집계 범위, 갱신 시점에 따라서도 차이가 발생합니다. Data는 로컬 사용량 확인에 적합하지만 서비스 측 사용량 기록을 대신할 수 없으며, 트래픽이 증가했다는 이유만으로 특정 규칙이 매칭됐다고 단정할 수 없습니다. 규칙 적용 여부는 연결 상세 정보와 실제 정책도 함께 확인해야 합니다.

주요 설정

Settings: DNS, 테스트, 위젯 및 진단

Settings의 옵션은 각기 다른 기능을 담당합니다. DNS는 도메인 이름 확인에 영향을 주고, Test Method는 테스트 방식을 정합니다. Today Widget은 위젯을 제공하고, iCloud는 관련 데이터를 동기화하며, Diagnostics는 문제 해결에 필요한 정보를 수집합니다. 먼저 확인할 문제의 범위를 정한 뒤 해당 옵션을 살펴보세요. 이름, 위치, 사용 가능 여부는 앱에 실제로 표시되는 내용을 기준으로 확인하세요.

DNS: 설정 출처부터 확인

DNS는 도메인 이름을 대상 주소로 변환합니다. Settings에서 DNS 관련 옵션을 확인할 때는 현재 Config의 [General] 섹션도 살펴보고 dns-server 등의 설정이 있는지 확인하세요. 화면 옵션과 구성 파일이 함께 실제 동작에 영향을 줄 수 있으므로 입력란 하나에 값이 있다고 해서 모든 요청이 같은 경로로 이름을 확인한다고 볼 수는 없습니다.

변경하기 전에 기존 값을 기록하고 한 번에 한 항목만 수정한 뒤 같은 도메인으로 확인하세요. 서버 지연 시간은 정상인데 웹페이지가 열리지 않는다면 DNS 확인 실패도 점검 대상에 포함해야 합니다. 라우팅 규칙의 매칭과 대상 상태도 확인하세요. 출처를 모르는 DNS 주소를 여러 개 무작정 추가하지 말고, DNS 서버의 위치를 요청의 최종 출구와 동일시하지 마세요.

Test Method: 측정 대상 확인

Test Method는 Connectivity Test에 사용할 테스트 방식을 정합니다. Settings에서 앱이 제공하는 방식을 선택한 다음 Home으로 돌아와 선택한 서버를 테스트하세요. 여러 결과를 비교할 때는 테스트 방식, 네트워크 환경, 테스트 대상을 동일하게 유지해야 수치를 비교할 수 있습니다.

테스트 방식에 따라 연결 설정이나 특정 테스트 요청의 일부 과정만 확인할 수 있으므로 테스트 수치가 웹페이지 전체 로딩 시간과 같지는 않습니다. 테스트에는 응답이 있지만 실제 요청이 실패한다면 프로토콜 인증, TLS, DNS, 규칙을 추가로 확인하세요. 테스트는 실패하지만 실제 요청이 정상이라면 서버 항목을 바로 삭제하기보다 테스트 대상과 방식을 먼저 점검하세요.

Today Widget: 위젯 사용 범위 확인

Today Widget에서는 시스템 위젯에 표시하거나 조작할 관련 항목을 설정할 수 있습니다. Settings에서 앱의 위젯 설정을 확인한 뒤 시스템의 해당 위젯 영역에서 추가하거나 조정하세요. 위젯의 위치, 표시 방식, 사용 가능한 기능은 시스템 지원 여부에 따라 달라지므로 현재 기기에 표시되는 내용을 기준으로 확인하세요.

설정한 뒤 Home으로 돌아가 연결 상태를 확인하고 위젯 표시와 일치하는지 살펴보세요. 위젯은 빠른 확인이나 지원되는 작업에 적합합니다. 자세한 서버 선택, 구성 편집, 규칙 점검은 앱에서 진행하세요. 기기가 잠겨 있을 때 시스템에서 어떤 정보를 표시하도록 허용하는지도 고려해야 합니다.

iCloud: 동기화 전 양쪽 상태 확인

iCloud 관련 설정은 지원되는 범위에서 앱 데이터를 동기화하는 데 사용됩니다. 사용하기 전에 시스템에서 iCloud가 활성화되어 있는지, Shadowrocket이 관련 서비스를 사용할 수 있도록 허용되어 있는지 확인하고 앱에서 동기화할 데이터 유형을 살펴보세요. 동기화 범위는 화면 안내를 기준으로 확인해야 합니다. 서버 항목, 구성, 통계 데이터가 모두 같은 방식으로 처리된다고 가정하지 마세요.

다른 기기에서 처음 활성화하기 전에 양쪽 기기에서 보존할 내용을 백업하고 로컬 데이터와 클라우드 데이터를 구분하세요. 병합 또는 덮어쓰기 동작을 모르는 상태에서 연속으로 조작하지 마세요. 동기화가 완료되어도 선택한 서버, Global Routing, 연결 스위치가 의도한 상태라는 뜻은 아닙니다. 기기를 바꾼 뒤에도 항목별로 확인하고 다시 검증하세요.

Diagnostics: 한 번의 실패를 기준으로 정보 수집

Diagnostics에서는 연결 문제를 확인하고 앱이 제공하는 진단 정보를 살펴볼 수 있습니다. Settings에서 관련 메뉴를 찾은 뒤 문제가 발생한 네트워크, Global Routing 옵션, 현재 구성을 기록하고 실패 상황을 한 번 재현하세요. 진단 정보는 해당 작업과 연결되어야 합니다. 기록을 장기간 대량으로 쌓아 두면 원인을 찾기 어려워질 수 있습니다.

진단 정보를 읽을 때는 도메인 이름 확인, 서버 연결, 인증, 규칙 처리 단계를 구분한 다음 어느 단계에서 처음 문제가 발생했는지 살펴보세요. 진단 자료를 전달하기 전에 접속 도메인, 서버 주소, 구독 정보, 인증 항목이 포함되어 있는지 검토하고 문제 해결에 필요한 내용만 남기세요. 진단 기록은 단서일 뿐이며, 오류 하나만으로 원인을 확정할 수는 없습니다.

실제 사용 순서

순서대로 설정 확인

먼저 재현 가능한 최소 상황을 만든 다음 자주 사용하는 설정을 하나씩 복구하세요. 서버, 구성 파일, DNS, 테스트 방식을 한꺼번에 바꾸면 결과가 달라져도 어떤 항목이 영향을 줬는지 알기 어렵습니다. 변경할 때마다 상황을 기록하고 이전 값으로 되돌릴 수 있도록 보관하세요.

  1. 정보 확인. Home에서 현재 서버가 사용자가 보유한 유효한 정보인지 확인하고 프로토콜, 주소, 포트, 인증 항목이 모두 입력되었는지 점검하세요.
  2. 연결 확인. 시스템 VPN 구성 승인이 완료되었는지 확인하고 실제 연결 상태를 살펴보세요. 연결 스위치가 켜져 있는 것과 대상에 접속할 수 있는 것은 별개입니다.
  3. 라우팅 확인. Global Routing에서 Config, Proxy, Direct 중 어떤 항목이 선택되었는지 확인하세요. Config를 사용한다면 현재 어떤 구성 파일이 적용 중인지도 점검하세요.
  4. 요청 확인. 같은 대상에 새 요청을 보내고 규칙 매칭, DNS, Diagnostics를 함께 확인해 어느 단계에서 실패했는지 판단하세요.
  5. 자동화 복구. 기본 연결이 정상인지 확인한 다음 On Demand, 위젯, 동기화를 활성화하고 마지막으로 Data의 통계 범위를 확인하세요.

첫 연결을 단계별로 진행하려면 Shadowrocket 사용 가이드를 읽고, 특정 키워드의 작성법을 찾으려면 구성 항목 참고를 확인하세요. 구매, 가져오기, 연결 현상에 대한 질문은 문제 해결에서 살펴볼 수 있습니다. 각 페이지는 작업 단계에 따라 내용을 나누므로 설정 하나를 위해 전체 구성을 다시 변경할 필요는 없습니다.