공식 매뉴얼 · 기능 및 설정
Shadowrocket 기능 및 주요 설정
먼저 트래픽 처리 방식을 정한 다음 서버, 연결 조건, 진단 결과를 확인하세요. 각 설정은 서로 다른 역할을 하므로 모든 항목을 한꺼번에 변경할 필요는 없습니다.
이 페이지는 iPhone과 iPad에서의 사용 방법을 중심으로 설명합니다. 화면 구성과 사용할 수 있는 옵션은 현재 앱에 표시되는 내용을 기준으로 하며, 시스템 요구 사항은 App Store 페이지를 확인하세요.
규칙, 프록시 또는 직접 연결 중 처리 방식을 정합니다.
규칙 순서에 따라 트래픽 정책을 선택합니다.
실제 접속 결과를 바탕으로 문제 지점을 찾습니다.
Home → Global Routing
Global Routing 세 가지 모드
평소 규칙에 따라 사용하려면 Config를 선택하고, Proxy와 Direct는 특정 조건을 확인할 때 임시로 사용하세요.
Global Routing은 클라이언트가 처리하는 범위의 트래픽에 어떤 방식을 적용할지 정합니다. Home에서 Global Routing을 열고 Config, Proxy 또는 Direct를 선택한 뒤 현재 선택을 확인하세요. Config, Proxy, Direct는 각각 규칙에 따른 처리, 프록시, 직접 연결을 뜻하는 화면 용어입니다. 서버 정보를 구분하는 항목이 아니며 연결 매개변수를 자동으로 채워 주지도 않습니다.
| 모드 | 처리 방식 | 사용 시점 | 확인할 항목 |
|---|---|---|---|
| Config · 규칙 설정 | 현재 활성화된 Config의 규칙에 따라 정책을 선택합니다. | 대상별로 PROXY, DIRECT 또는 REJECT를 적용하려는 경우 | 활성화된 Config, 규칙 순서, 최종 매칭 정책 |
| Proxy · 프록시 | 해당 모드의 처리 범위에 프록시 경로를 적용합니다. | 서버를 통해 특정 대상에 접속할 수 있는지 임시로 확인할 때 | 현재 서버, 인증 정보, 실제 접속 결과 |
| Direct · 직접 연결 | 해당 모드의 처리 범위에서 대상에 직접 연결합니다. | 현재 로컬 네트워크에서도 같은 문제가 발생하는지 확인할 때 | 로컬 네트워크, 도메인 조회, 대상의 연결 가능 여부 |
모드를 바꾼 뒤 확인하는 방법
먼저 기존 모드와 현재 서버를 기록한 뒤 동일한 대상을 사용해 비교 테스트하세요. Proxy에서는 접속되지만 Config에서는 안 된다면 Config와 규칙을 확인하세요. 두 모드에서 모두 실패한다면 서버 정보와 기본 네트워크부터 점검하는 것이 좋습니다. Direct에서 접속된다고 해서 프록시 설정이 올바르다는 뜻은 아닙니다. 해당 조건에서 대상에 직접 접속할 수 있다는 의미일 뿐입니다.
Global Routing은 모든 시스템 트래픽이 항상 같은 방식으로 처리된다고 보장하지 않습니다. 시스템의 네트워크 동작, Config의 관련 옵션, 기존 연결이 결과에 영향을 줄 수 있습니다. 모드를 바꾼 뒤에는 새로 요청을 보내고, 기존 연결 결과를 새 모드의 효과로 오해하지 않도록 하세요. 테스트가 끝나면 평소 사용하던 모드로 되돌리세요.
Config → 규칙
규칙 유형과 정책 동작
규칙은 요청을 매칭하고 정책은 동작을 정합니다. 먼저 순서를 확인한 뒤 각 규칙의 문법을 살펴보세요.
규칙 분기는 Global Routing에서 Config를 선택했을 때 적용됩니다. Config를 열어 현재 활성화된 구성을 확인한 다음 규칙을 확인하거나 편집하세요. 규칙은 Config에 표시된 순서대로 위에서 아래로 검사하며, 처음으로 일치한 규칙의 정책이 실행됩니다. FINAL은 앞선 규칙에 일치하지 않은 요청을 처리하도록 마지막에 배치해야 합니다.
대상 특성에 맞는 규칙 유형 선택
DOMAIN은 도메인을 정확히 일치시킬 때 사용합니다. DOMAIN-SUFFIX는 지정한 도메인 접미사와 관련 하위 도메인을 매칭하고, DOMAIN-KEYWORD는 도메인에 포함된 키워드를 기준으로 매칭하므로 적용 범위가 더 넓을 수 있습니다. IP-CIDR과 IP-CIDR6은 각각 IPv4 및 IPv6 주소 대역을 지정합니다. GEOIP는 IP 주소의 지역 정보를 기준으로 판단합니다. 규칙 유형마다 필요한 정보가 다르므로 도메인 규칙과 IP 주소 규칙을 단순히 서로 바꿔 쓸 수는 없습니다.
USER-AGENT는 요청에 포함된 관련 정보를 기준으로 매칭하지만, 모든 연결에 판단에 사용할 수 있는 정보가 제공되는 것은 아닙니다. 일반적인 앱 식별 방법으로 간주하지 마세요. 편집하기 전에 현재 앱에서 지원하는 규칙 문법과 해당 규칙 유형이 대상 트래픽에 적용될 수 있는지 확인하세요.
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
DOMAIN-KEYWORD,ad,REJECT
FINAL,PROXY위 내용은 규칙 순서를 설명하기 위한 예시이며, 기존 Config를 그대로 대체하라는 권장 사항이 아닙니다. example.com은 예시 도메인입니다.
PROXY, DIRECT, REJECT 구분하기
PROXY는 프록시 정책 사용, DIRECT는 직접 연결, REJECT는 매칭된 요청 거부를 뜻합니다. 사용 가능한 정책 그룹 이름을 지정한 경우에는 해당 그룹에서 선택된 결과도 확인해야 합니다. 화면 모드 Proxy와 규칙 동작 PROXY는 대소문자가 다릅니다. Config 모드라고 해서 모든 요청에 프록시를 사용해야 하는 것도 아닙니다.
원격 Config를 업데이트하면 로컬에서 수정한 내용이 대체될 수 있습니다. 변경 사항을 계속 유지하려면 현재 파일의 출처와 업데이트 방식을 먼저 확인하고 복원할 수 있는 사본을 보관하세요. 단계별 설명은 사용 안내를 참고하세요.
Home · Subscribe · Add Server
구독 및 서버 관리
기존 구독 또는 서버 정보가 있다는 전제로 설명합니다. 가져오기에 성공한 뒤에도 선택 항목과 매개변수를 확인해야 합니다.
구독을 사용하면 서버 항목을 한곳에서 업데이트할 수 있고, 수동 추가는 명확한 연결 정보를 직접 관리할 때 적합합니다. 구독 URL은 이용 중인 서비스 제공업체에서 받아 해당 Subscribe 화면에 입력하세요. 서버를 개별 추가하려면 Home에서 Add Server를 열고, 보유한 정보를 기준으로 프로토콜 유형을 선택해 매개변수를 입력합니다. 정확한 메뉴 위치는 현재 앱 화면을 확인하세요.
프로토콜을 선택한 뒤 연결 정보를 입력하세요
Shadowrocket은 Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard, Hysteria2 등의 프로토콜을 지원합니다. 프로토콜마다 필요한 인증 및 전송 항목이 다르므로 주소와 포트만 복사했다고 설정이 완성되는 것은 아닙니다. 서버 주소, 포트, 비밀번호 또는 기타 인증 정보를 하나씩 확인하고 제공된 정보에 따라 TLS, 전송 방식 등의 옵션을 입력하세요.
QR 코드를 스캔하려면 Scan QR Code를 사용하세요. 클립보드에서 가져올 때는 클립보드에 예상한 공유 정보가 들어 있는지 먼저 확인하세요. QR 코드와 공유 링크에는 인증 정보가 포함될 수 있으므로 공개 페이지에 올리지 마세요. 구독 URL도 자격 증명처럼 안전하게 관리해야 합니다. 예시 https://example.com/sub?token=xxxx는 입력 형식을 설명하기 위한 것으로 실제 연결 정보가 아닙니다.
업데이트, 선택, 삭제를 각각 확인하세요
Subscribe 업데이트는 제공된 내용을 기준으로 서버 항목을 새로 고칩니다. 클라이언트 업데이트와는 다르며, 현재 선택된 서버가 계속 유효하다는 보장도 없습니다. 업데이트 후에는 항목 이름과 개수의 변화, 현재 선택을 확인하고 Connectivity Test를 실행한 다음 실제 웹페이지나 서비스에 접속해 검증하세요. 구독에 포함된 항목을 수동으로 수정하면 다음 업데이트에서 덮어쓸 수 있으므로 중요한 정보는 별도로 안전하게 기록하세요.
구독을 여러 개 관리한다면 용도와 출처를 알아볼 수 있도록 메모를 작성하세요. 삭제하기 전에는 작업 대상이 개별 서버인지 구독 전체인지 확인해야 합니다. 목록에서 항목을 삭제해도 서비스 제공업체와의 서비스 이용 관계가 해지되는 것은 아니며, 원격 자격 증명이 폐기되는 것도 아닙니다.
Settings → On Demand
On Demand 연결 설정
연결을 언제 시작할지 정하는 기능이며, 요청의 경로를 결정하는 Global Routing을 대신하지 않습니다.
On Demand는 설정한 네트워크 조건에 따라 연결 동작을 실행합니다. 네트워크가 바뀔 때마다 수동으로 조작하는 일을 줄이고 싶을 때 유용합니다. Settings에서 On Demand를 열어 사용할 수 있는 조건을 확인한 뒤 실제 사용 방식에 맞게 설정하세요. SSID 조건을 사용하는 경우 연결할 Wi-Fi의 정확한 이름을 입력하고, 해당 조건이 연결, 무시 또는 다른 동작 중 무엇을 적용하는지 확인하세요.
수동 연결을 확인한 뒤 조건을 추가하세요
먼저 On Demand 동작을 일시적으로 끄고, 현재 서버에 수동으로 연결할 수 있는지와 Global Routing이 예상대로 설정되어 있는지 확인하세요. 그다음 명확한 조건 하나를 설정합니다. 저장 후에는 조건이 적용되는 네트워크와 적용되지 않는 네트워크에서 각각 테스트하고 연결 상태와 실제 접속 결과를 살펴보세요. 서버, 규칙, 네트워크 조건을 동시에 바꾸면 문제의 원인을 찾기 어렵습니다.
On Demand는 정해진 시각에 실행되는 예약 작업이 아니며, 네트워크가 바뀌어도 기존 연결이 모두 유지된다는 뜻도 아닙니다. 시스템 스케줄링, 네트워크 사용 가능 여부, VPN 설정 상태가 실행에 영향을 줍니다. 실행되지 않으면 조건과 시스템 권한부터 확인하세요. 연결이 반복해서 복구된다면 주 스위치를 계속 조작하기보다 On Demand 조건이 계속 적용되고 있는지 확인하세요.
연결을 시작하는 시점과 요청을 분기하는 방식은 별개의 설정입니다. On Demand가 연결을 시작했더라도 Config에 설정된 DIRECT 규칙과 일치하는 트래픽은 직접 연결됩니다. 이동하거나 네트워크를 바꾸기 전에 조건을 간단히 기록해 두면 기존 SSID 조건을 잊지 않는 데 도움이 됩니다.
Data
Data 트래픽 통계
클라이언트에 기록된 트래픽 변화를 확인하는 기능이며, 서비스 제공업체의 과금 내역을 대신하지 않습니다.
Data에서는 클라이언트 측에서 집계한 트래픽을 확인할 수 있습니다. Data를 열고 현재 화면에 표시된 집계 범위와 기간, 분류를 확인한 뒤 업로드, 다운로드, 누적값의 의미를 살펴보세요. 집계 범위가 다른 수치는 직접 빼거나 비교할 수 없습니다. 초기화하기 전에는 어떤 기록이 영향을 받는지 확인하세요.
통계는 문제 파악에 활용하고 총량만으로 결론 내리지 마세요
문제를 확인할 때는 현재 수치를 기록한 다음 명확한 접속 동작을 한 번 수행하고 통계 변화를 살펴보세요. 업로드량은 늘었지만 다운로드량이 거의 없다면 요청을 보낸 뒤 기대한 응답을 받지 못했을 수 있습니다. 다만 진단 결과와 대상 상태도 함께 확인해야 합니다. 백그라운드 활동, 다른 진행 중인 요청, 연결 재시도도 통계에 영향을 줄 수 있으므로 테스트 조건을 최대한 단순하게 유지하세요.
집계 기간, 프로토콜 오버헤드, 측정 기준 등의 차이로 클라이언트 통계와 서비스 제공업체의 청구 내역이 다를 수 있습니다. Data의 총량은 남은 서비스 용량을 뜻하지 않으며 구독 만료 여부를 판단하는 근거도 아닙니다. 서비스 유효 기간이나 용량은 이용 중인 서비스의 실제 기록을 확인하세요.
트래픽이 늘었다고 해서 반드시 분기 규칙이 잘못된 것은 아닙니다. 어떤 유형의 요청으로 수치가 변했는지 확인한 다음 Global Routing과 규칙 매칭 결과를 살펴보세요. 문제 확인을 위해 기록을 남길 때는 테스트 시각과 작업을 적어 두면 됩니다. 기록을 공유하기 전에는 서버, 도메인 등 민감한 정보를 가리세요.
Settings
DNS, 테스트, 동기화 및 진단
한 번에 하나만 변경하고 기존 설정을 보관한 뒤 같은 대상으로 확인하세요.
DNS: 현재 설정을 관리하는 위치부터 확인
DNS는 도메인 이름을 IP 주소로 변환합니다. Settings에서 사용할 수 있는 DNS 관련 설정과 현재 활성화된 Config 파일의 DNS 항목을 확인할 수 있습니다. 변경하기 전에 어느 쪽에서 현재 DNS 동작을 제어하는지 파악한 뒤 해당 항목만 수정하세요. 웹페이지가 열리지 않는다고 여러 DNS 설정을 한꺼번에 바꾸지 말고, 서버 주소 조회와 대상 웹사이트의 도메인 조회도 구분하세요.
지연 시간 테스트는 통과했지만 웹페이지가 열리지 않는다면 도메인 조회 여부, 규칙이 최종적으로 선택한 정책, 실제 요청 성공 여부를 차례대로 확인하세요. Config에서 설정한 조회 경로와 프록시 요청 경로가 다를 수 있으므로 테스트 결과 하나만으로 전체 접속 경로가 정상이라고 판단할 수 없습니다. 기존 Config를 보관하고 설정을 바꾼 뒤 요청을 다시 보내세요. 기존 설정으로 되돌렸을 때의 결과와도 비교하세요.
Test Method와 Connectivity Test: 동일한 조건에서 측정하기
Test Method는 사용할 수 있는 테스트 방식을 선택하는 기능으로, 보통 Settings의 테스트 관련 항목에서 변경합니다. Connectivity Test는 연결 테스트를 실행합니다. 방식마다 확인하는 단계가 다르므로 동일한 네트워크와 방식, 비슷한 시간대에서 측정한 결과를 비교하세요. 한 번 낮은 수치가 나왔다고 모든 웹사이트가 더 빨라졌다고 판단하지 마세요.
테스트에 실패하면 먼저 선택한 방식의 요구 사항을 확인하고 서버 매개변수와 네트워크 환경을 점검하세요. 테스트를 통과했더라도 실제 대상에 접속해 도메인 조회, 연결, 콘텐츠 로딩이 모두 완료되는지 확인해야 합니다. Test Method를 바꾼 뒤 결과가 크게 달라졌다면 방식 이름을 기록해 서로 다른 조건의 결과를 혼동하지 않도록 하세요.
Today Widget: 빠른 실행 항목으로 사용하기
Today Widget은 시스템에서 허용하는 범위 내에서 빠르게 확인하거나 조작할 수 있는 진입점을 제공합니다. 먼저 Settings에서 관련 옵션을 확인한 다음 시스템의 위젯 관리 화면에서 해당 항목을 추가할 수 있는지 살펴보세요. 사용할 수 있는 형태는 기기의 시스템과 현재 앱이 제공하는 기능에 따라 다르므로 특정한 예전 레이아웃이 모든 기기에 표시되어야 한다고 생각하지 마세요.
위젯은 일정 간격으로 갱신될 수 있습니다. 조작 후 상태가 예상과 다르면 Home으로 돌아가 실제 연결 상태를 확인하고 시스템에서 해당 기능을 허용했는지 살펴보세요. 위젯은 별도의 서버 설정이 아니며 앱 내 VPN 권한을 대신하지 않습니다.
iCloud 동기화: 동기화와 백업 구분하기
Settings에서 iCloud 관련 옵션을 확인하고 시스템에서 Shadowrocket의 iCloud 사용을 허용했는지도 확인하세요. 활성화하기 전에 해당 옵션이 어떤 데이터를 포함하는지 설명을 읽어 보세요. 서버 항목, Config 파일, 선택 상태와 기타 설정이 모두 동기화된다고 확인 없이 가정해서는 안 됩니다. 처음 사용할 때는 로컬 사본을 보관한 뒤 다른 기기에서 항목별로 확인하는 것이 좋습니다.
동기화는 지원되는 데이터를 여러 기기에서 일치시키는 기능이며 모든 변경 이력을 보존하지는 않습니다. 삭제하거나 잘못 수정한 내용도 동기화될 수 있으므로 별도의 백업을 대신할 수 없습니다. 동기화 데이터에 구독 URL이나 인증 정보가 포함될 수 있으니 기기와 iCloud 계정을 안전하게 관리하세요. 문제 확인을 위해 전체 동기화 데이터를 공개하지 마세요.
Diagnostics: 실패한 요청 하나를 중심으로 정보 수집하기
Settings의 Diagnostics 또는 현재 화면에 표시된 진단 메뉴에서 시작하세요. 먼저 네트워크 유형, Global Routing, 현재 Config와 서버를 기록한 뒤 실패한 요청을 한 번 재현합니다. 기본 네트워크, 서버 주소 조회, 연결 설정, 규칙 처리, 대상 접속 순서로 확인하면 모든 설정을 반복해서 바꾸는 것보다 원인을 좁히기 쉽습니다.
진단 기록에는 대상 도메인, 서버 주소, 요청 세부 정보가 포함될 수 있습니다. 공유하기 전에 구독 URL, 인증 항목, 기타 개인정보를 삭제하고 현상을 설명하는 데 필요한 최소한의 내용만 남기세요. 확인이 끝나면 임시로 변경한 설정을 복원하고 더 이상 필요하지 않은 상세 기록을 중지해 이후 작업이 이전 테스트와 섞이지 않도록 하세요.