FEATURES & SETTINGS
Shadowrocket 기능과 설정: Global Routing, 규칙 라우팅 및 주요 항목
이 페이지는 화면 순서대로 Shadowrocket의 주요 기능을 짚어봅니다: Global Routing 세 가지 모드가 각각 어떤 상황에 맞는지, 규칙 목록의 키워드와 정책을 어떻게 읽는지, 서버와 구독을 어떻게 관리하는지, On Demand·Data 트래픽 통계·Settings 주요 항목이 각각 무엇을 담당하는지. 항목마다 무엇인지, 어느 화면에 있는지, 어떻게 설정하는지, 무엇을 주의해야 하는지 정리했습니다.
- iOS / iPadOS
- App Store 전용
- 일회성 구매
- iPhone·iPad 공용
섹션
GLOBAL ROUTING
Global Routing 세 가지 모드: Config, Proxy, Direct
Global Routing은 Home 화면에 있으며, 클라이언트가 연결을 누구에게 넘길지 결정합니다. 세 가지 모드는 서로 배타적이라 동시에 하나만 적용되고, 전환해도 이미 가져온 서버와 구성은 바뀌지 않습니다.
무엇인가
Global Routing은 Home 화면에 있는 전역 모드 옵션으로, 개별 규칙이 아니라 기기에서 나가는 연결 전체를 대상으로 합니다. 이미 가져온 서버와 구성 파일은 바뀌지 않고, 그 연결을 처리하는 방식만 달라집니다.
세 가지 모드의 역할
Config(구성): 현재 선택한 구성의 규칙 목록을 한 줄씩 판단합니다. PROXY에 매칭된 연결은 서버를 거치고, DIRECT에 매칭된 연결은 직접 나가며, REJECT에 매칭된 연결은 차단됩니다. 일상적인 사용에서는 이 모드를 주로 씁니다.
Proxy(프록시): 모든 연결을 현재 선택한 서버로 일괄 전달하며, 규칙 목록은 판단에 참여하지 않습니다. 전체를 같은 회선으로 보내야 하는 임시 상황에 적합합니다.
Direct(직접 연결): 모든 연결을 서버를 거치지 않고 그대로 내보냅니다. '지금 연결이 안 되는 게 회선 때문인지 로컬 네트워크 때문인지' 확인할 때 적합합니다.
전환 방법
Home → Global Routing에서 Config, Proxy, Direct 중 하나를 선택합니다. 전환하면 이후 연결은 새 모드로 처리되며, 구성·규칙·서버 목록은 그대로 유지됩니다. Config로 되돌리면 다시 규칙에 따른 라우팅이 적용됩니다.
주의할 점
Direct 모드에서도 규칙 목록은 그대로 남아 있고, 다만 판단에 참여하지 않을 뿐입니다. 규칙이 삭제됐다고 오해하지 마세요. Proxy 모드는 모든 트래픽을 한 대의 서버로 몰아넣기 때문에 Data 화면의 수치도 그 서버에 집중됩니다. 트래픽을 점검하기 전에 현재 모드를 먼저 확인하세요.
| 모드 | 화면 표시 | 트래픽 경로 | 주요 용도 |
|---|---|---|---|
| 구성 | Config | 현재 구성의 규칙 목록을 한 줄씩 판단 | 일상 사용, 라우팅과 직접 연결 병행 |
| 프록시 | Proxy | 전부 현재 선택한 서버로 전달 | 전체를 같은 회선으로 보내야 할 때 |
| 직접 연결 | Direct | 전부 서버를 거치지 않고 직접 전송 | 문제가 회선인지 로컬인지 판단 |
RULES
규칙 라우팅: 키워드, 정책, 매칭 순서
규칙 목록은 각 연결이 어느 경로로 갈지 결정합니다. 가져온 구성에서 비롯되며, 클라이언트는 위에서 아래로 한 줄씩 비교해 처음 매칭된 규칙을 적용하고, 그 뒤 규칙은 더 이상 보지 않습니다.
규칙은 어디에서 오나
규칙은 구성 파일에 들어 있습니다. Config 화면에서 어떤 구성을 추가해 선택했느냐에 따라 클라이언트가 그 구성의 규칙 목록으로 판단합니다. 클라이언트 자체에는 특정 서비스를 겨냥한 규칙 세트가 내장되어 있지 않으며, 규칙 내용은 구성을 제공하는 쪽이 정합니다.
규칙 하나의 구성 요소
세 부분입니다: 매칭 키워드, 매칭 값, 정책. 정책은 PROXY(서버로 전달), DIRECT(직접 연결), REJECT(차단) 세 가지뿐입니다. 키워드는 무엇을 기준으로 비교할지, 정책은 매칭된 뒤 어떻게 처리할지를 정합니다.
매칭 순서
위에서 아래로 한 줄씩 비교하며, 처음 매칭된 규칙이 그 연결의 경로를 결정합니다. FINAL은 보통 마지막 줄에 두는 기본값으로, 앞의 규칙이 모두 매칭되지 않았을 때 적용됩니다. 범위가 좁은 규칙을 앞에, 넓은 규칙을 뒤에 두어야 결과가 예상대로 나옵니다.
주의할 점
REJECT는 매칭된 연결에만 적용되며, 차단 효과는 요청을 보낸 쪽이 실패를 어떻게 처리하느냐에 달려 있습니다. 어떤 상황에서도 광고 차단 효과를 보장하지는 않습니다. 규칙을 수정한 뒤에는 구성을 먼저 저장하고 그 구성을 다시 선택해야 변경이 적용됩니다.
규칙 키워드별 매칭 범위는 별도 문서에서 하나씩 설명합니다: DOMAIN, GEOIP, IP-CIDR, FINAL은 각각 무엇에 매칭되나.
| 키워드 | 매칭 대상 | 작성 예시 |
|---|---|---|
DOMAIN | 전체 도메인, 정확히 일치 | DOMAIN,example.com,PROXY |
DOMAIN-SUFFIX | 도메인 접미사, 해당 도메인과 하위 도메인 모두 매칭 | DOMAIN-SUFFIX,example.com,PROXY |
DOMAIN-KEYWORD | 도메인에 포함된 키워드 | DOMAIN-KEYWORD,static,DIRECT |
IP-CIDR | 대상 IPv4 주소 대역 | IP-CIDR,203.0.113.0/24,DIRECT |
IP-CIDR6 | 대상 IPv6 주소 대역 | IP-CIDR6,2001:db8::/32,DIRECT |
GEOIP | IP 소속 지역 코드 | GEOIP,CN,DIRECT |
USER-AGENT | 요청에 포함된 User-Agent | USER-AGENT,Example*,DIRECT |
FINAL | 기본값, 앞의 규칙이 모두 매칭되지 않았을 때 적용 | FINAL,PROXY |
SERVERS & SUBSCRIBE
서버와 구독: Add Server와 Subscribe 사용법
서버를 클라이언트에 넣는 방법은 두 가지입니다: 레코드를 직접 추가하거나, 서비스 제공자가 준 구독 링크를 가져오는 것입니다. 두 방법 모두 결국 같은 서버 목록에 들어갑니다.
Add Server: 레코드 직접 추가
Add Server는 서버 레코드 하나를 추가할 때 씁니다. 이름, 유형, 주소, 포트, 그리고 그 유형이 요구하는 자격 증명 필드를 입력해야 합니다. 유형은 Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard, HTTP, SOCKS5 등이 흔하며, 프로토콜마다 입력할 필드가 다르므로 실제 폼에 표시되는 내용을 기준으로 하세요.
Subscribe: 구독 가져오기
구독 링크는 서비스 제공자에게서 받습니다. Config 화면에서 구독 주소를 추가하면 클라이언트가 그 안의 서버와 규칙을 가져와 해석합니다. 링크가 언제 갱신되는지, 내용이 무엇인지, 언제 만료되는지는 모두 제공자가 정하며, 클라이언트는 가져오기와 갱신만 담당합니다.
다른 가져오기 방법
Scan QR Code는 서비스 제공자가 준 QR 코드를 스캔할 때 씁니다. Import from Cloud JSON은 클라우드 저장소에 있는 JSON 구성을 가져올 때 씁니다. 본문에 나오는 주소, 도메인, 링크는 모두 example.com 같은 명백한 가짜 값이며, 자신의 실제 구독 링크를 공개된 곳에 붙여 넣지 마세요.
관리와 주의사항
서버 목록은 지연 시간 측정, 정렬, 복사, 삭제를 지원합니다. 구독 링크는 일종의 자격 증명이라 이를 가진 사람이 같은 회선을 쓸 수 있으므로 공개적으로 공유하기에 적합하지 않습니다. 구분해야 할 점: 클라이언트는 App Store에서 일회성으로 구매하는 것이고, 사는 것은 앱 자체입니다. 회선과 요금제는 서비스 제공자가 제공하며, 둘은 별개의 문제입니다.
구독을 추가한 뒤에는 수동으로 갱신할 수도 있고, 클라이언트를 열 때 자동으로 갱신하게 할 수도 있습니다. 갱신에 실패하면 먼저 안내 메시지를 확인하고 항목별로 점검하세요. 이 부분은 별도 문서에서 다룹니다: 구독 갱신: 수동 갱신, 열 때 자동 갱신, 실패 원인.
클라이언트 구매 ≠ 회선 요금제. App Store에서 일회성으로 구매하는 것은 Shadowrocket 앱 자체입니다. 노드, 구독, 회선은 서비스 제공자에게서 받아야 하며, 이 사이트는 어떤 노드 서비스도 제공하거나 추천하지 않습니다.
ON DEMAND
On Demand 자동 연결: 세 가지 트리거 조건
On Demand는 조건에 따라 클라이언트가 연결을 자동으로 처리하게 합니다. 특정 네트워크에 연결되거나 특정 도메인에 접속할 때 미리 정한 동작을 실행하므로, 매번 수동으로 켜고 끌 필요가 없습니다.
TRIGGER 01
Wi-Fi
현재 연결된 Wi-Fi 네트워크 이름을 조건으로 삼습니다. '집 네트워크에서는 이렇게, 다른 네트워크에서는 저렇게' 처리하고 싶을 때 적합합니다.
TRIGGER 02
셀룰러
셀룰러 데이터 사용 여부를 조건으로 삼습니다. 'Wi-Fi에서 벗어나면 자동으로 이렇게 처리'하고 싶을 때 적합하며, 조건 자체에는 특정 통신사 정보가 들어가지 않습니다.
TRIGGER 03
도메인
접속하려는 대상 도메인을 조건으로 삼습니다. 특정 도메인에 매칭되면 설정한 동작으로 처리하며, 개별 도메인만 따로 떼어 지정한 방식으로 보내야 할 때 적합합니다.
설정 방법
Settings → On Demand에서 규칙을 하나 추가합니다: 조건 유형(Wi-Fi / 셀룰러 / 도메인)을 고르고, 조건 파라미터를 채운 뒤, 매칭된 다음의 동작을 선택합니다. 규칙은 여러 개 추가할 수 있으며, 여러 조건이 동시에 충족되면 실제 매칭 결과에 따라 처리됩니다.
주의할 점
조건을 넓게 잡을수록 트리거되어서는 안 될 때 트리거되기 쉽습니다. 특정 네트워크에서 '연결이 안 된다'면 먼저 On Demand에서 그 네트워크가 어떤 동작에 매칭되는지 확인하고, 그다음 Global Routing 모드와 규칙 목록을 살펴보며 두 원인을 나눠서 점검하세요.
세 가지 트리거 조건의 파라미터 의미와 흔한 오설정은 별도 문서에서 자세히 설명합니다: On Demand 자동 연결: Wi-Fi, 셀룰러, 도메인 트리거 설정법.
DATA
Data 트래픽 통계: 서버별·앱별 두 가지 지표
Data 화면은 트래픽을 두 가지 지표로 나눕니다: 하나는 서버별 통계, 다른 하나는 앱별 통계입니다. 두 기준이 달라서 함께 봐야 문제를 짚어낼 수 있습니다.
서버별
서버마다 누적 처리한 업로드·다운로드 트래픽을 집계합니다. 트래픽이 어느 회선에 몰려 있는지, 특정 회선이 과도하게 쓰이는지 확인할 때 씁니다.
앱별
앱마다 클라이언트를 거쳐 처리된 트래픽을 집계합니다. '어떤 앱이 계속 트래픽을 쓰는지' 찾아낸 뒤, 다시 서버별 지표로 돌아가 그 앱이 어느 회선을 탔는지 확인합니다.
시스템 통계와 왜 다른가
시스템 설정의 트래픽 통계는 기기의 모든 네트워크 활동을 포괄하지만, Data 화면은 클라이언트를 거친 연결만 기록합니다. 집계 범위와 시작 시점이 서로 다르므로 수치가 맞지 않는 것은 정상이며, 통계 오류가 아닙니다.
이상 트래픽 점검에 활용하기
권장 순서: 먼저 앱별 지표에서 수치가 눈에 띄게 큰 항목을 찾습니다. 다음으로 서버별 지표에서 그 트래픽이 어느 서버로 갔는지 확인합니다. 마지막으로 Global Routing으로 돌아가 현재 모드가 Config인지 확인해, '전역 프록시 때문에 모든 트래픽이 한 대에 몰린' 경우를 배제합니다.
주의할 점
수치는 이 기기에 기록된 것이라 기기를 바꾸거나 재설치하면 따라가지 않습니다. '최근에 이상한 게 있는지' 판단할 때는 현재 수치를 먼저 적어 두고 변화를 보세요. 단위는 KB / MB / GB로 자동 환산되며, 구체적인 표시는 앱 안의 실제 화면을 기준으로 합니다.
두 지표의 의미는 별도 문서에서 자세히 설명합니다: Data 화면 트래픽 통계 읽는 법: 서버별·앱별 수치의 의미.
SETTINGS
Settings 주요 항목: DNS, Test Method, Today Widget, 진단
Settings 화면에는 항목이 적지 않지만, 일상에서 실제로 손댈 일이 있는 것은 몇 개뿐입니다. 아래는 '연결과 해석 / 진입점과 동기화 / 진단과 기록' 세 묶음으로 설명합니다. 묶음은 읽기 편하도록 나눈 것일 뿐, 실제 위치는 기기의 Settings 화면을 기준으로 하세요.
- DNS 도메인을 누가 해석하는지
- Test Method 지연 시간 측정에 쓰는 탐색 방식
- Connectivity Test 연결 전후 도달 가능성 테스트
DNS는 도메인을 누가 해석할지 정합니다: 해석 서버를 지정할 수도 있고 시스템 기본 해석에 맡길 수도 있으며, 변경 효과는 회선과 네트워크 환경에 따라 다르므로 확신이 없으면 기본값을 유지하세요. Test Method는 지연 시간 측정에 쓰는 탐색 방식을 정하며, 방식마다 수치 기준이 다르므로 두 방식의 결과를 서로 비교하지 마세요. Connectivity Test는 연결 전후에 현재 네트워크에 도달할 수 있는지 확인해, '네트워크 자체가 안 되는 것'과 '회선이 안 되는 것'을 구분하는 데 씁니다.
- Today Widget 시스템 위젯 영역에 진입점 배치
- iCloud Sync 구성과 서버 항목을 계정으로 동기화
Today Widget을 켜면 시스템의 '오늘' 보기나 위젯 영역에서 클라이언트 진입점을 볼 수 있어 상태 확인이나 연결 처리에 쓸 수 있습니다. 시스템에 최종적으로 무엇이 표시되는지는 어떤 위젯을 추가했는지에 따라 다릅니다. iCloud Sync는 구성과 서버 항목을 iCloud 계정으로 동기화해, 같은 Apple ID를 쓰는 다른 기기에서 다시 불러올 수 있게 합니다. 동기화되는 것은 클라이언트 안의 구성 데이터이며, 서비스 제공자 쪽 회선은 포함되지 않습니다. 동기화 범위와 동작은 앱 안의 실제 표시를 기준으로 하세요.
- Diagnostics 실행 상태와 연결 기록 요약
- Data 트래픽과 연결 기록 진입점
Diagnostics는 실행 상태와 연결 과정의 기록을 모아 보여줍니다. 문제를 점검할 때 여기서 뚜렷한 오류 항목이 있는지 먼저 보고, 구성을 고칠지 서비스 제공자에게 문의할지 판단하세요. Data는 트래픽과 연결 기록의 진입점으로, 앞 절에서 설명한 두 지표와 대응합니다. '클라이언트 때문인지' 판단할 때는 시스템 통계만 보지 말고 여기의 기록을 기준으로 하세요.
NOTES
이 페이지 내용을 볼 때의 전제
기능과 설정은 모두 두 가지 전제 위에 있습니다: 앱 자체는 App Store에서 받고, 회선과 구독은 서비스 제공자가 제공합니다.
클라이언트 구매 ≠ 회선 요금제. Shadowrocket은 App Store에서 일회성으로 구매하며(미국 스토어 기준 2.99달러, 각 스토어는 현지 통화로 표시, 스토어 페이지 기준), 사는 것은 앱 자체입니다. 노드, 구독, 회선은 서비스 제공자에게서 받아야 하며, 이 사이트는 어떤 노드 서비스도 제공·판매·추천하지 않습니다.
구매 경로 안내
Shadowrocket은 App Store에서만 판매되며, 개발자는 Shadow Launch Technology Limited, 앱 ID는 932747118입니다. iPhone과 iPad가 중심이고, Mac, Apple TV, Apple Vision도 같은 스토어 페이지의 호환성 항목에 있습니다. 시스템 요구 사항은 App Store 페이지에 표기된 내용을 기준으로 하세요.
화면 차이 안내
시스템 버전에 따라 Settings의 항목 이름과 위치가 조금씩 다를 수 있어, 이 문서는 일반적인 배치를 기준으로 설명합니다. 맞지 않는 부분이 있으면 기기의 앱 안 실제 표시를 기준으로 하세요.
예시 값 안내
본문에 나오는 주소, 도메인, 규칙 조각은 모두 example.com, 203.0.113.0/24 같은 명백한 가짜 값이며, 어떤 실제 서비스와도 대응하지 않습니다.
Global Routing을 Direct로 바꾸면 규칙이 삭제되나요?
아니요. Direct는 연결이 서버를 거치지 않게 할 뿐이고 구성과 규칙 목록은 그대로 남아 있습니다. Config로 되돌리면 다시 규칙에 따른 라우팅이 적용됩니다.
구독 링크를 다른 사람과 공유해도 되나요?
권장하지 않습니다. 구독 링크는 일종의 자격 증명이라 이를 가진 사람이 같은 회선을 쓸 수 있습니다. 링크의 갱신과 만료는 서비스 제공자가 정합니다.
Settings 항목을 바꿨는데 왜 바로 변화가 보이지 않나요?
일부 설정은 다음 연결 때부터 적용됩니다. 연결을 끊었다가 다시 연결하거나, Global Routing 모드를 한 번 전환한 뒤 Data 화면의 수치 변화를 지켜보세요.
Mac과 Apple TV에도 이런 설정이 있나요?
같은 앱이라도 기기마다 화면 배치가 완전히 같지는 않으므로, 항목 이름은 해당 기기의 앱 안 실제 표시를 기준으로 하세요. 시스템 요구 사항은 항상 App Store 페이지 표기를 기준으로 합니다.