공식 매뉴얼 · 기능 및 설정

Shadowrocket
프록시 모드와 주요 설정

먼저 Global Routing의 작동 방식을 선택한 다음 서버와 구성을 확인하세요. 연결 스위치, 트래픽 분할 규칙, 주문형 연결은 각각 다른 기능을 제어하므로 따로 확인해야 합니다.

Home
Config
Data
Settings

01 · 작동 방식 선택

Global Routing 모드 3가지

일상적인 규칙 기반 라우팅에는 Config, 프록시 연결 테스트에는 Proxy, 직접 연결 결과 비교에는 Direct를 사용하세요. Home에서 Global Routing을 열고 원하는 모드를 선택합니다. 이 설정은 앱으로 들어오는 요청의 처리 방식을 정하며, 연결 스위치를 켜거나 서버 주소·인증 정보·DNS 설정을 자동으로 수정하지는 않습니다.

모드	작동 방식	사용 상황	확인할 항목
구성 `Config`	현재 활성화된 구성의 규칙에 따라 정책을 선택합니다.	도메인이나 주소별로 다른 정책을 적용할 때 사용합니다.	구성 활성화 여부, 규칙 순서, 최종 기본 정책을 확인합니다.
프록시 `Proxy`	앱으로 들어오는 트래픽을 프록시 모드로 처리합니다. 시스템 트래픽 범위와 앱별 예외 설정도 확인해야 합니다.	분할 규칙이 문제의 원인인지 잠시 확인할 때 사용합니다.	선택한 서버가 사용 가능한지, 해당 서버를 통해 대상에 연결할 수 있는지 확인합니다.
직접 연결 `Direct`	앱으로 들어오는 트래픽을 직접 연결 모드로 처리합니다.	현재 네트워크에서 직접 연결했을 때의 결과를 비교합니다.	현재 네트워크에서 대상에 접속할 수 있는지, DNS가 정상인지 확인합니다.

Config: 규칙이 연결 경로를 결정합니다

Config 화면에서 현재 사용 중인 구성을 확인한 다음 Home으로 돌아가 Global Routing을 Config로 설정하세요. 구성에서 일치한 정책은 PROXY, DIRECT, REJECT 또는 구성에 정의된 정책 그룹일 수 있습니다. Home에서 서버를 선택했다고 해서 모든 요청이 해당 서버를 거치는 것은 아닙니다. 규칙에 DIRECT가 지정되어 있으면 요청은 직접 연결로 처리됩니다.

Proxy와 Direct: 문제 범위 좁히기

같은 대상이 Proxy에서는 정상이고 Config에서는 실패한다면, 모든 서버 항목을 바로 수정하기보다 일치한 규칙과 정책 참조를 먼저 확인하세요. Direct에서는 정상인데 Proxy에서 실패한다면 선택한 서버, 인증 정보, 전송 매개변수를 확인합니다. 모드별 결과는 원인을 좁히는 단서일 뿐, 한 번의 테스트만으로 장애 원인을 확정할 수는 없습니다.

모드를 바꾼 뒤 테스트 페이지를 닫았다가 다시 열고, 필요하면 앱 연결도 다시 설정해 이전 연결의 영향을 줄이세요. 테스트가 끝나면 원래 사용할 모드로 되돌립니다. 문제 해결용 임시 상태인 Proxy를 계속 사용하면 기존 트래픽 분할 결과가 달라집니다.

02 · 규칙의 일치 조건 확인

규칙 유형과 정책

규칙은 ‘무엇과 일치하는지’를, 정책은 ‘일치한 뒤 어떻게 처리할지’를 정합니다. Config에서 현재 구성을 열고 Rule 부분을 확인하거나 편집하세요. 일반적으로 파일에 적힌 순서대로 판단하며 먼저 일치한 규칙이 결과를 결정합니다. 따라서 구체적인 규칙은 적절한 위치에 두고 FINAL은 마지막 기본 규칙으로 사용하세요.

규칙 유형	일치 대상	설정 시 주의사항
`DOMAIN`	지정한 전체 도메인입니다.	특정 도메인 하나만 처리할 때 적합합니다.
`DOMAIN-SUFFIX`	도메인과 그 하위 도메인입니다.	도메인 항목에 전체 웹 주소나 경로를 입력하지 마세요.
`DOMAIN-KEYWORD`	도메인에 포함된 키워드입니다.	예상보다 넓은 범위와 일치할 수 있으므로 오탐에 주의하세요.
`GEOIP`	IP 주소에 해당하는 지역 분류입니다.	분류 결과는 사용하는 주소 데이터베이스에 따라 달라집니다.
`IP-CIDR` / `IP-CIDR6`	IPv4 / IPv6 주소 범위입니다.	주소 유형과 프리픽스 길이를 확인하세요.
`USER-AGENT`	인식 가능한 User-Agent 정보입니다.	요청에서 해당 정보를 확인할 수 있는지에 따라 일치 여부가 달라집니다.
`FINAL`	앞선 규칙과 일치하지 않은 요청입니다.	규칙 맨 끝에 두어 최종 처리 방식을 지정하세요.

PROXY, DIRECT, REJECT의 차이

PROXY는 프록시로 처리하고, DIRECT는 직접 연결하며, REJECT는 요청을 거부합니다. 이 대문자 키워드는 구성 문법이며 Global Routing의 Proxy·Direct 화면 옵션과는 다른 단계입니다. 전자는 개별 규칙의 처리 결과이고, 후자는 전역 작동 방식입니다. 사용자 지정 정책 이름을 쓸 때는 해당 이름이 구성에 실제로 정의되어 있는지도 확인하세요.

[Rule]
DOMAIN,example.com,DIRECT
DOMAIN-SUFFIX,example.org,PROXY
DOMAIN-KEYWORD,ads,REJECT
GEOIP,CN,DIRECT
FINAL,PROXY

위 예시는 문법을 보여 주기 위한 것으로, 모든 네트워크에 적합한 완성된 구성은 아닙니다. 첫 번째 규칙은 example.com만 일치시키고, 두 번째는 example.org와 그 하위 도메인을 포함합니다. 키워드 규칙은 범위가 더 넓으므로 복사하기 전에 영향을 받는 요청을 파악하세요. 규칙 수를 늘리려고 같은 내용을 반복해서 추가하지 말고, 적용해야 할 규칙보다 앞에 FINAL을 두지 마세요.

수정하기 전에 원래 구성을 복사해 보관하고, 한 번에 적은 수의 규칙만 변경한 뒤 대상 도메인으로 실제 정책을 확인하세요. General, Rule, Host, URL Rewrite의 구조를 항목별로 알아보려면 규칙 및 구성 전체 안내 →를 읽어 보세요.

03 · 연결 정보 관리

구독 및 서버 관리

서버 항목에는 연결 매개변수가 저장되고, 구독은 이러한 항목을 일괄로 가져오고 업데이트하는 데 사용됩니다. 본인 소유의 구독 또는 서버 정보가 있다는 전제하에 Home에서 Add Server를 선택해 추가하세요. Subscribe를 선택하면 본인의 구독 주소를 입력합니다. 수동으로 추가할 때는 먼저 올바른 프로토콜을 선택한 뒤 원본 정보에 따라 해당 항목을 입력하세요.

Add Server: 프로토콜에 맞는 항목 입력

Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard, Hysteria2는 매개변수가 서로 다릅니다. 주소와 포트가 같더라도 항목을 서로 바꿔 쓸 수 있는 것은 아닙니다. 비밀번호, UUID, TLS, 전송 방식 및 관련 항목은 본인의 서버 정보를 기준으로 입력하세요. 일부 항목은 해당 프로토콜이나 전송 방식을 선택한 뒤에만 표시됩니다.

개별 공유 정보가 있다면 앱의 가져오기 기능을 사용할 수 있으며, QR 코드가 있다면 Scan QR Code를 선택하세요. 가져온 뒤에도 항목을 열어 프로토콜, 주소, 포트, 인증 항목을 확인해야 합니다. 표시 이름만으로 가져오기가 올바른지 판단하지 마세요. 이름은 항목을 구분하기 위한 것이며, 실제 연결은 항목에 저장된 매개변수에 따라 결정됩니다.

Subscribe: 업데이트와 로컬 편집 구분

구독을 업데이트하면 주소에서 내용을 다시 가져옵니다. 구독으로 관리되는 항목을 직접 편집해도 다음 업데이트 때 변경 내용이 덮어써질 수 있습니다. 변경 사항을 계속 유지하려면 항목의 출처와 앱의 저장 방식을 먼저 확인하세요. 구독이 여러 개라면 알아보기 쉬운 메모를 사용하고, 그룹을 확인한 뒤 사용할 수 없는 항목을 삭제해 이름이 비슷한 항목을 중복으로 오인하지 않도록 하세요.

구독 새로고침에 성공했다는 것은 내용을 가져와 파싱했다는 뜻일 뿐, 모든 서버에 연결할 수 있다는 의미는 아닙니다. 반대로 구독 업데이트에 실패해도 이미 저장된 항목이 즉시 무효화되는 것은 아닙니다. 주소에서 내용을 가져오는 결과와 서버 연결 결과를 따로 확인하세요.

기존 구독 가져오기와 첫 연결 단계 보기 →

04 · 자동 연결 조건

On Demand 주문형 연결

On Demand는 설정한 조건에 따라 시스템에 연결을 요청하며, 트래픽 분할 규칙을 대신하지 않습니다. Settings에서 On Demand를 열어 앱에 표시되는 조건과 스위치를 확인하세요. 선택할 수 있는 조건은 현재 앱 화면을 기준으로 합니다. 먼저 수동 연결이 정상인지 확인한 뒤 주문형 연결을 켜면 연결 자체의 문제와 실행 조건의 문제를 구분하기 쉽습니다.

설정 및 확인 방법

Home에서 서버와 Global Routing 모드를 선택하고 수동으로 연결한 뒤 테스트할 대상을 여세요.
On Demand로 이동해 현재 조건의 작동 방식을 확인한 다음 필요한 옵션을 켭니다. 네트워크 이름을 기준으로 하는 조건은 기기가 실제로 연결된 네트워크와 일치해야 합니다.
대상 네트워크로 전환하거나 조건을 다시 충족한 뒤 시스템 연결 상태와 실제 요청의 성공 여부를 확인하세요.
결과가 예상과 다르면 먼저 On Demand를 잠시 끄고 수동 연결로 돌아가 확인하세요. 규칙과 서버 매개변수를 동시에 변경하지 마세요.

On Demand와 Config는 함께 사용할 수 있습니다. On Demand는 연결을 설정하는 시점을 제어하고, Config는 연결된 뒤 요청에 적용할 정책을 제어합니다. 시스템에 연결 표시가 보인다고 해서 모든 요청이 프록시를 통과하는 것은 아닙니다. Config에 DIRECT 또는 REJECT 규칙이 있을 수 있습니다.

수동으로 연결을 끊은 뒤 연결이 다시 나타나면 구성을 반복해서 삭제하기보다 On Demand 조건이 여전히 적용 중인지 확인하세요. 첫 연결 때 필요한 시스템 VPN 구성 승인은 시스템 절차입니다. 허용한 뒤에도 앱 설정을 확인해야 합니다. 네트워크 변화, 시스템 스케줄링, 조건 일치 여부가 관찰 결과에 영향을 주므로 주문형 연결을 앱별 요청을 따로 제어하는 스위치로 이해해서는 안 됩니다.

05 · 사용량 확인

Data 트래픽 통계

Data는 앱에 기록된 트래픽을 보여 주며, 서비스 제공자의 청구 내역이 아닙니다. Data를 열고 화면에 표시된 통계 범위에 따라 업로드, 다운로드 및 관련 기록을 확인하세요. 특정 테스트의 변화를 비교하려면 먼저 기준 시점을 기록하고 명확한 작업 하나만 수행한 뒤 다시 확인합니다. 재설정 기능을 사용하기 전에 기존 통계를 보존해야 하는지 확인하세요.

트래픽 수치로 알 수 있는 것

수치가 증가했다면 해당 통계 기준으로 앱이 데이터 활동을 기록했다는 뜻입니다. 하지만 특정 웹 페이지가 완전히 로드되었다고 단정할 수 없고, 총량만으로 어느 서버를 사용했는지도 알 수 없습니다. 백그라운드 앱, 동기화 작업, 반복 요청도 트래픽을 발생시킬 수 있습니다. 특정 대상의 라우팅 결과는 총량만 보는 대신 현재 모드, 일치한 정책, 연결 기록을 함께 확인하세요.

서비스 제공자 기록과 다른 이유

양쪽의 통계 기간, 초기화 시각, 프로토콜 오버헤드 계산 방식 또는 요금 산정 기준이 다를 수 있습니다. 앱 통계와 서비스 제공자가 제공하는 기록은 별도로 확인하고, 남은 사용량은 본인이 이용하는 서비스 제공자의 안내를 기준으로 하세요. 로컬 통계를 초기화해도 서비스 제공자 측 사용량까지 초기화되는 것은 아닙니다.

문제 해결 시 일정한 테스트 절차를 사용할 수 있습니다. 불필요한 백그라운드 활동을 중지하고 Data의 현재 값을 기록한 다음, 확인된 대상에 접속해 수치 변화를 비교하세요. 간섭을 줄이는 데 도움이 되지만 정확한 회선 과금 측정은 아닙니다. 통계에 대상 정보가 포함되어 있다면 공유 전에 개인의 접속 내용이 노출되는지 확인하세요.

06 · 주요 옵션

Settings 설정 안내

Settings에서는 테스트 방식, 보조 기능, 동기화, 진단 등의 옵션을 관리합니다. 일부 네트워크 동작은 현재 구성의 General 부분에서도 제어됩니다. 같은 문제라도 먼저 설정이 어디에서 관리되는지 확인한 뒤 해당 위치를 수정하세요. 이름이 비슷하다고 해서 같은 요청 경로에 영향을 준다고 단정하지 마세요. 아래 항목의 표시 여부와 구체적인 위치는 현재 앱 화면을 기준으로 합니다.

DNS: 먼저 이름 확인 경로 점검

DNS는 도메인을 연결에 필요한 주소로 변환합니다. Settings의 DNS 설정과 현재 Config의 General 내용을 함께 확인하세요. 어떤 리졸버를 사용하는지, 요청이 어떤 경로를 거치는지, 구성에서 별도로 지정한 항목이 있는지 살펴보면 됩니다. 먼저 기존 값을 기록한 뒤 현재 네트워크와 구성의 요구 사항에 맞게 조정하세요. 저장하고 다시 연결한 다음 같은 도메인으로 결과를 비교합니다.

Connectivity Test에 수치가 표시된다는 이유만으로 DNS가 정상이라고 판단하지 마세요. 일부 테스트는 서버 엔드포인트에 도달할 수 있는지만 확인하며, 웹 도메인 이름 확인과는 다른 과정입니다. 도메인 접속만 실패한다면 먼저 이름 확인을 점검하세요. 도메인 확인은 성공하지만 연결되지 않는다면 대상 정책, 서버 경로, TLS 등의 항목을 확인합니다. 이해하지 못한 DNS 옵션을 여러 개 겹쳐 적용하면 원인을 찾기 어려워집니다.

Test Method: 테스트 대상과 측정 방식 확인

Test Method에서는 Connectivity Test의 테스트 방식을 선택합니다. Settings에서 해당 항목을 찾아 화면의 방식과 설명을 확인한 뒤 선택하고, Home으로 돌아가 기존 서버를 테스트하세요. 항목별 결과를 비교할 때는 같은 방식, 대상, 네트워크 환경을 사용해야 수치를 비교할 수 있습니다.

테스트 결과는 해당 시점의 도달 가능성이나 응답 상태를 나타내며, 대역폭을 뜻하거나 모든 웹사이트에 접속할 수 있음을 보장하지는 않습니다. 수치가 표시되는데 웹 페이지가 열리지 않으면 해당 페이지의 도메인, 규칙, DNS를 확인하세요. 테스트가 실패했다면 테스트 대상에 도달할 수 없는 경우와 실제 프록시 연결이 실패한 경우를 구분하고, 여전히 사용할 수 있는 항목을 성급히 삭제하지 마세요.

Today Widget: 보조 기능 진입점

Today Widget에서는 시스템이 지원하는 위젯 기능의 관련 옵션을 설정할 수 있습니다. Settings에서 해당 옵션을 확인하세요. 위젯을 추가할 수 있는지, 어떤 동작이 표시되는지, 위젯에 접근하는 위치는 현재 시스템과 앱의 지원 여부에 따라 다릅니다. 기기의 실제 위젯 목록을 기준으로 사용하세요. 먼저 앱 안에서 연결이 정상인지 확인한 다음 위젯에서 조작해 보세요.

위젯은 보조 진입점이며 서버 매개변수, Global Routing, 시스템 VPN 승인을 대신하지 않습니다. 위젯 표시와 실제 접속 결과가 다르면 위젯 모양만 보고 트래픽 경로를 판단하지 말고 Home으로 돌아가 현재 연결과 모드를 확인하세요.

iCloud: 동기화와 로컬 저장 항목 확인

iCloud 기능은 앱에서 지원하는 범위 내에서 정보를 저장하거나 동기화합니다. Settings에서 iCloud 옵션을 확인하고 기기에 본인의 Apple 계정이 로그인되어 있는지, 시스템에서 앱의 iCloud 사용을 허용하는지 확인하세요. 켜기 전에 중요한 구성의 복사본을 보관하고, 작업 후 앱에 표시되는 동기화 항목과 결과를 확인합니다.

기능을 켜면 모든 서버, 인증 정보, 구성, 통계, 임시 상태가 전부 동기화된다고 가정하지 마세요. 여러 기기에서 사용할 때는 항목별로 내용을 확인하고, 특히 현재 활성화된 구성과 서버 선택을 확인하세요. 앱 구매 기록, iCloud 동기화 정보, 본인이 이용하는 서비스 제공자의 계정은 서로 별개의 항목입니다. 동기화가 완료되어도 연결을 다시 확인해야 합니다.

Diagnostics: 단서를 모은 뒤 설정 변경

Diagnostics에서는 실행 문제와 관련된 진단 정보를 확인하거나 수집할 수 있습니다. Settings에서 해당 기능을 열고 화면 안내에 따라 확인하세요. 문제가 발생했을 당시의 네트워크 환경, Global Routing 모드, 대상, 조작 단계를 먼저 기록한 뒤 진단 결과를 살펴봐야 기록과 실제 실패 상황을 연결해 파악하기 쉽습니다.

경고 한 건만으로 모든 원인을 단정하지 마세요. 진단 내용을 Connectivity Test, DNS, 규칙 결과와 함께 확인하세요. 정보를 외부에 제공하기 전에 구독 주소, 서버 인증 정보, 개인 도메인 등 민감한 내용을 삭제하세요. 설정을 변경하기 전에는 원래 값을 기록해 변경이 실제로 효과가 있었는지 확인할 수 있도록 합니다.

07 · 단계별 최종 확인

설정 확인 및 문제 해결 순서

한 번에 조건 하나만 바꾸고 같은 대상으로 반복 확인하세요. 서버, 모드, 구성, DNS를 동시에 바꾸면 접속이 복구되더라도 어느 변경이 효과가 있었는지 알기 어렵습니다. 먼저 재현 가능한 최소 테스트를 준비한 뒤 다음 순서대로 확인하세요.

현재 네트워크를 확인합니다. 기기가 정상적으로 인터넷에 연결될 수 있는지 확인하세요. Wi-Fi와 셀룰러 네트워크를 전환할 때마다 결과를 기록해 네트워크 변화를 구성 변경으로 오인하지 않도록 합니다.
서버 항목을 확인합니다. 프로토콜, 주소, 포트, 인증 정보, 필요한 전송 항목을 확인하고 현재 선택한 항목이 예상한 구독에서 가져온 것인지 확인하세요.
연결 상태를 확인합니다. Home의 연결 동작과 시스템 승인을 확인하세요. 서버를 선택한 것만으로 연결이 설정되었다고 판단하지 마세요.
모드별 결과를 비교합니다. 같은 대상으로 Proxy와 Config를 비교하세요. Config에서만 실패하면 규칙과 정책 참조를 확인하고, 둘 다 실패하면 연결 경로와 이름 확인을 점검하세요.
DNS와 진단 정보를 확인합니다. 이름 확인 실패, 연결 설정 실패, 연결 후 요청 실패를 구분하고 모든 현상을 하나의 규칙 탓으로 돌리지 마세요.
평소 설정으로 되돌립니다. 확인된 변경 사항은 유지하고 임시로 바꾼 모드는 원래대로 되돌린 뒤 On Demand와 보조 진입점을 테스트하세요.

Config 모드인데 일부 요청이 프록시를 사용하지 않는 이유는 무엇인가요?

Config는 현재 구성에 따라 정책을 선택합니다. 요청이 DIRECT와 일치하거나 직접 연결 옵션이 포함된 정책 그룹을 사용할 수 있습니다. 활성화된 구성, 규칙 순서, 실제로 일치한 결과를 확인하세요. Home에서 선택한 서버만으로 모든 요청의 경로를 판단할 수는 없습니다.

On Demand를 켠 뒤에도 Global Routing을 설정해야 하나요?

네. On Demand는 연결이 시작되는 조건을 제어하고, Global Routing은 트래픽 처리 방식을 제어합니다. 먼저 서버와 모드를 수동으로 확인한 뒤 On Demand를 켜고 조건이 적용되는지 살펴보세요. 두 항목을 각각 확인해야 합니다.

Connectivity Test는 정상인데 웹 페이지가 열리지 않는 이유는 무엇인가요?

테스트와 웹 페이지 접속은 대상과 경로가 다를 수 있습니다. 웹 도메인의 DNS 확인, Config 정책, 선택한 서버에서 대상까지의 연결, 진단 기록의 실패 단계를 확인하세요. 테스트 수치만으로 실제 접속 여부를 판단할 수는 없습니다.

첫 연결을 완료하려면 가져오기 및 연결 안내를, 규칙을 하나씩 확인하려면 구성 전체 안내를 읽어 보세요. 구매, 설치, 자주 발생하는 연결 문제는 항목별 문제 해결에서 확인할 수 있습니다.