OFFICIAL MANUAL · SETTINGS

Shadowrocket
기능 및 주요 설정

먼저 Home에서 선택한 서버와 Global Routing을 확인한 다음 Config와 Settings를 점검합니다. 연결 스위치, 라우팅 모드, 규칙 매칭은 서로 다른 설정이므로 서로 대신할 수 없습니다.

안내 범위와 설정 전 확인 사항

이 페이지는 iPhone / iPad의 Home, Config, Data, Settings 화면을 기준으로 설명합니다. 시스템 및 앱 버전에 따라 항목 위치가 달라질 수 있으므로 현재 화면에 표시된 이름을 기준으로 확인하세요. 보이지 않는 옵션은 비슷한 이름을 추측해 설정할 필요가 없습니다.

Shadowrocket은 iPhone, iPad, Mac, Windows, Android, Linux 버전을 제공합니다. Mac은 Apple 실리콘 버전과 Intel 버전으로 제공됩니다. 클라이언트가 필요하면 전체 플랫폼 다운로드 안내에서 기기에 맞는 버전을 선택하세요.

01 · GLOBAL ROUTING

Config, Proxy, Direct 세 가지 모드

Global Routing은 연결을 어떤 방식으로 처리할지 결정합니다. 평소 규칙에 따라 사용하려면 Config를 선택하고, 프록시 경로의 사용 가능 여부를 임시로 확인하려면 Proxy를 선택하세요. 현재 네트워크의 직접 연결 상태와 비교하려면 Direct를 선택합니다.

모드 및 화면 표시 이름연결 처리 방식사용 상황유의 사항
Config · 구성현재 활성화된 구성 파일의 규칙에 따라 연결을 매칭하고 해당 정책을 적용합니다.대상에 따라 PROXY, DIRECT 또는 별도로 정의한 정책을 적용해야 할 때 사용합니다.먼저 의도한 구성이 활성화되어 있는지 확인한 다음 규칙 순서와 FINAL을 점검하세요.
Proxy · 프록시일반적으로 가로채는 연결을 현재 선택된 프록시 서버로 처리합니다.규칙 분기의 영향을 제외하고 서버와 프록시 경로를 임시로 확인할 때 사용합니다.규칙이 예상대로 매칭되는지 확인하는 방법은 아니며, 서버의 사용 가능 여부를 보장하지도 않습니다.
Direct · 직접 연결가로채는 연결을 선택한 프록시 서버를 거치지 않고 직접 연결합니다.로컬 네트워크, 대상 서비스, 프록시 경로 간 차이를 비교할 때 사용합니다.연결 스위치를 끄는 것과는 다릅니다. 시스템의 VPN 상태는 계속 유지될 수 있습니다.

Home에서 모드 전환 후 다시 확인

Home으로 이동해 Global Routing을 열고 원하는 모드를 선택한 뒤, 돌아와 현재 표시된 값을 확인하세요. 모드를 바꾼 후 웹페이지 요청을 새로 보내야 합니다. 이미 연결된 장시간 연결은 이전 상태를 계속 사용할 수 있으므로 기존 페이지가 여전히 표시되는지만 보고 새 설정이 모든 요청에 적용됐다고 판단하지 마세요.

Proxy에서는 정상인데 Config에서 문제가 생기면 구성 파일, 정책 이름, 규칙 매칭을 먼저 확인하세요. 둘 다 문제가 있으면 선택한 서버와 기본 네트워크부터 점검하고 구성 전체를 바로 다시 작성하지 마세요. 점검이 끝나면 원래 사용하던 모드로 되돌려 Proxy 설정이 앱 트래픽 경로를 계속 바꾸지 않도록 하세요.

02 · CONFIG / RULE

규칙은 매칭하고 정책은 처리합니다

Config에서 현재 구성을 확인하세요. 규칙 유형은 ‘무엇을 매칭하는지’를 나타내고, 규칙 끝의 정책은 ‘매칭 후 어떻게 처리하는지’를 나타냅니다. 두 요소를 구분해 이해해야 합니다.

Config는 파일을 저장하는 곳일 뿐 아니라 현재 어떤 규칙을 사용하는지와도 관련이 있습니다. 구성을 가져오거나 다운로드한 뒤에는 목록에만 있는 것이 아니라 실제로 선택되어 활성화됐는지 확인하세요. 편집하기 전에 사본을 저장하고, 원래 정상적으로 연결되던 구성을 기록해 두세요. 한 번에 한 종류의 규칙만 변경하면 변경 사항과 실제 결과를 비교하기 쉽습니다.

규칙 유형매칭 대상설정 기준 및 유의 사항
DOMAIN지정한 전체 도메인입니다.명확한 호스트 이름 하나만 처리할 때 적합하며 모든 하위 도메인에 자동 적용되지는 않습니다.
DOMAIN-SUFFIX지정한 도메인과 그 하위 도메인입니다.도메인 접미사 기준으로 분류할 때 적합합니다. 전체 웹 주소가 아니라 도메인을 입력하세요.
DOMAIN-KEYWORD도메인에 포함된 특정 문자열입니다.매칭 범위가 넓으므로 관련 없는 도메인이 잘못 매칭되지 않도록 주의하세요.
IP-CIDR / IP-CIDR6IPv4 / IPv6 주소 대역입니다.명확한 네트워크 범위를 지정할 때 적합합니다. 주소 계열과 프리픽스 길이를 확인하세요.
GEOIPIP 지리 정보 데이터베이스에 등록된 분류입니다.결과는 데이터베이스와 확인된 주소에 따라 달라지며, 계정 지역을 뜻하지 않습니다.
FINAL앞선 규칙에 매칭되지 않은 나머지 연결입니다.마지막 기본 규칙으로 두고 최종 정책을 명시하세요.

구체적인 규칙부터 일반적인 규칙 순으로 구성

규칙은 일반적으로 순서대로 매칭되므로 구체적인 예외를 범위가 넓은 규칙보다 앞에 두세요. PROXY는 프록시 경로로 처리하고, DIRECT는 직접 연결하며, REJECT는 연결을 거부합니다. 구성에서 사용자 지정 정책 이름을 사용한다면 해당 정책도 정의되어 있어야 합니다. 이름이 일치하지 않거나 정책 참조가 유효하지 않으면 규칙이 올바르게 보여도 예상대로 동작하지 않을 수 있습니다.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,DIRECT

이 예시는 문법 설명용이며 완전한 구성 파일이 아닙니다. example.com과 그 하위 도메인은 PROXY로 처리하고, 지정한 로컬 주소 대역은 DIRECT로 연결하며, 나머지는 FINAL에 지정된 DIRECT로 처리합니다. 실제로 사용하기 전에는 대상과 기존 구성에 맞춰 정책을 결정하세요. 예시 전체를 기존 파일에 그대로 덮어쓰지 마세요.

규칙 적용 결과를 확인하려면 먼저 Global Routing이 Config인지 확인하고, 명확한 대상 하나에 요청을 새로 보내세요. 대상에 도메인 이름 대신 IP 주소로 접속하면 도메인 규칙이 매칭되지 않을 수 있습니다. 서비스에서 여러 도메인을 사용한다면 홈페이지 요청 한 번이 성공했다고 해서 모든 요청이 같은 정책을 따른다고 볼 수 없습니다.

03 · HOME / ADD SERVER

구독 및 서버 관리

구독은 서버 항목을 일괄 관리하며, Home에서 선택한 서버는 현재 기본 프록시 출구를 결정합니다. 가져오기 성공, 업데이트 성공, 실제 연결 가능 여부는 각각 별개의 문제입니다.

기존 정보 가져오기

Home에서 Add Server를 선택하고 보유한 정보에 맞는 유형을 고르세요. 구독을 가져오려면 Subscribe를 선택한 뒤 전체 구독 주소를 입력합니다. QR 코드가 있다면 Scan QR Code를 사용할 수 있지만, 스캔한 뒤에도 항목 유형과 주요 필드를 확인해야 합니다. 일반 웹사이트 주소, 계정 관리 페이지, 구성 안내 웹페이지를 구독 주소로 입력하지 마세요.

서버를 직접 추가할 때는 프로토콜 유형, 서버 주소, 포트, 인증 정보, TLS 및 전송 관련 항목을 보유한 정보와 일치하게 입력해야 합니다. 프로토콜 이름은 원문 그대로 사용하세요. 예: Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard, Hysteria2. 양식을 저장하기 위해 필드를 임의로 채우지 마세요. 확실하지 않은 값은 원본 정보를 다시 확인하고, 프로토콜 참고 자료도 읽어 보세요.

업데이트, 선택 및 정리

구독을 업데이트한 뒤 서버 목록이 바뀌었는지 확인하고, Home에서 점 표시를 보고 기본 서버를 다시 선택하세요. 기존에 선택한 항목이 삭제되거나 교체됐을 수 있습니다. 이름이 비슷한 서버가 목록에 있어도 주소와 매개변수가 같다는 뜻은 아닙니다. 직접 추가한 항목에 알아보기 쉬운 메모를 붙일 수 있지만, 메모 자체는 연결 방식을 바꾸지 않습니다.

구독을 삭제하기 전에 유지해야 할 항목과 원래 구독 주소를 확인하세요. 구독으로 관리되는 항목은 다음 업데이트 때 덮어써질 수 있으므로 항목을 직접 수정해도 변경 사항이 계속 유지되지 않을 수 있습니다. 매개변수를 따로 테스트하려면 먼저 원본 항목을 보존하고 구분하기 쉬운 테스트 사본을 만드세요. 테스트가 끝나면 중복 항목을 정리해 잘못 선택하지 않도록 하세요.

04 · ON DEMAND

On Demand와 수동 연결의 차이

On Demand는 시스템의 네트워크 조건에 따라 연결을 시작하는 기능입니다. 특정 도메인에 적용할 PROXY 또는 DIRECT 정책을 선택하지는 않습니다. 먼저 수동 연결이 안정적으로 작동하는지 확인한 뒤 자동 연결 조건을 설정하세요.

Settings에서 On Demand를 찾아 현재 스위치와 사용할 수 있는 네트워크 조건을 확인하세요. 처음 설정할 때는 Home에서 서버를 직접 선택해 연결을 확인한 다음, On Demand 동작을 하나씩 설정하세요. 시스템에서 VPN 구성을 추가하도록 요청하면 안내를 읽고 확인하세요. 조건은 현재 화면에 표시되는 항목을 기준으로 설정하며, 모든 옵션을 동시에 켤 필요는 없습니다.

활성화한 뒤 실제로 사용하는 Wi-Fi와 셀룰러 네트워크를 전환하면서 연결이 예상대로 시작되거나 중지되는지 확인하세요. 그런 다음 Home에서 Global Routing이 원하는 모드로 유지되는지 살펴보세요. 연결이 자동으로 시작됐다고 해서 서버가 사용 가능하거나 모든 요청이 프록시를 사용한다는 뜻은 아닙니다. 실제 처리 방식은 라우팅 모드와 현재 구성에 따라 결정됩니다.

수동으로 연결을 끈 뒤 다시 연결된다면 구독을 반복해서 삭제하기보다 먼저 On Demand를 확인하고 시스템의 VPN 설정도 살펴보세요. 연결 문제를 점검하거나 자동 연결을 완전히 중지하려면 On Demand를 잠시 끈 다음 Home의 연결 스위치를 조작하세요. 기존 설정을 기록해 두고 테스트가 끝나면 필요한 설정으로 복원하세요.

On Demand는 데이터를 계속 전송한다는 뜻이 아닙니다. 배터리와 데이터 사용량은 실제 앱 동작, 프로토콜, 네트워크 안정성, 재연결 빈도에도 영향을 받습니다. VPN 아이콘이 표시된다는 이유만으로 비정상적인 데이터 사용이라고 판단할 수 없습니다. 확인이 필요하면 On Demand의 연결 트리거 기록, Data의 관찰 구간, 실제 앱 사용 상황을 함께 살펴보세요.

05 · DATA

Data 트래픽 통계 확인 방법

Data는 클라이언트에 기록된 트래픽 변화를 확인하는 기능입니다. 서비스 제공자의 청구 내역이 아니며 네트워크 속도나 회선 품질을 직접 평가하는 지표도 아닙니다.

Data를 열고 먼저 현재 화면에 표시된 통계 범위, 방향, 단위를 확인한 다음 실제로 수행한 작업과 비교하세요. 업로드와 다운로드는 서로 다른 방향의 데이터를 나타냅니다. 화면에서 기간을 바꾸거나 데이터를 지울 수 있다면 선택한 범위를 먼저 확인하세요. 한 세션의 수치를 한 달 전체 사용량으로 간주하지 말고, 데이터를 지운 뒤에는 기존 관찰 시작점을 그대로 적용하지 마세요.

비교 테스트를 할 때는 현재 수치를 먼저 기록하고, 관련 없는 백그라운드 전송을 중지한 뒤 명확한 작업 하나만 수행해 변화를 확인하세요. 트래픽이 증가했다는 것은 기록된 데이터 전송이 발생했다는 뜻일 뿐, 특정 도메인이 PROXY에 매칭됐다는 증거는 아닙니다. 정책을 확인하려면 Global Routing, 구성 규칙, 확인 가능한 연결 기록도 함께 살펴보세요.

클라이언트 통계와 서비스 제공자 통계는 집계 시간, 프로토콜 오버헤드, 재전송, 측정 기준 차이로 다를 수 있습니다. 계정의 잔여 사용량은 이용 중인 서비스의 계정 기록에서 확인하세요. Data 수치 하나만으로 청구 내역을 추정하지 마세요. 문제 해결 기록에는 누적 수치만 캡처하기보다 네트워크 유형과 테스트 동작을 함께 적는 것이 유용합니다.

06 · SETTINGS

Settings 주요 항목과 설정 기준

정상 작동하는 설정을 기준으로 유지하고 한 번에 한 항목만 변경하세요. DNS, 테스트 방식, 바로가기, 동기화, 진단은 각각 다른 문제를 해결하므로 모든 스위치를 한꺼번에 바꾸는 것은 문제 해결 방법이 아닙니다.

DNS: 도메인 조회와 연결을 구분하세요

DNS는 도메인 이름을 주소로 변환합니다. Settings에서 DNS 관련 설정을 확인하고 현재 Config에 DNS 설정이 포함되어 있는지도 함께 살펴보세요. 실제 동작은 구성 파일의 영향을 받을 수 있습니다. 명확한 필요가 없다면 현재 정상 작동하는 설정을 유지하세요. 지정된 DNS 설정이 있다면 원본 정보를 확인해 입력하고 변경 전 값을 기록해 두세요.

도메인으로는 접속할 수 없지만 주소를 직접 입력하면 응답이 오는 경우 DNS 문제일 수 있지만, 이것만으로 원인을 확정할 수는 없습니다. HTTPS 사이트에는 인증서와 도메인도 관련됩니다. DNS를 바꾼 뒤에는 요청을 새로 보내고 캐시된 결과를 새 설정의 효과로 착각하지 마세요. DNS 변경은 서버 매개변수 수정과 다르며 IPv6, 규칙, 서버를 동시에 바꾸면 원인을 찾기 어려워집니다.

Test Method: 측정 기준을 일관되게 유지하세요

Test Method는 관련 테스트에서 사용할 확인 방식을 결정합니다. Settings에서 현재 사용할 수 있는 옵션을 확인하고 선택할 수 있습니다. 방식마다 확인하는 연결 단계가 다르므로 같은 방식과 비슷한 네트워크 조건에서만 결과를 비교하세요. 방식을 바꾼 뒤에는 이전 결과와 새 결과를 나란히 놓고 서버 품질을 판단하지 마세요.

방식을 선택한 뒤 Home으로 돌아가 Connectivity Test를 실행하고 실제 앱 동작도 확인하세요. 테스트 성공이 모든 웹사이트에 접속할 수 있다는 뜻은 아니며, 실패한 경우에도 테스트 대상과 현재 네트워크를 함께 고려해야 합니다. 특정 테스트 방식에서만 문제가 생기면 해당 방식의 테스트 조건부터 확인하고 서버 전체를 바로 삭제하지 마세요.

Today Widget: 빠른 조작 후에도 상태를 확인하세요

Today Widget은 시스템에서 지원하는 범위 내에서 빠르게 상태를 확인하고 조작하는 기능입니다. 먼저 Settings에서 관련 옵션을 확인한 다음, 현재 시스템에서 제공하는 위젯 추가 방법에 따라 바로가기를 설정하세요. 시스템이나 현재 버전에 이 항목이 표시되지 않는다면 위젯을 찾기 위해 연결 매개변수를 바꿀 필요는 없습니다.

위젯에서 조작한 뒤 Home으로 돌아가 서버, 연결 스위치, Global Routing을 확인하세요. 바로가기에 표시된 상태는 갱신이 필요할 수 있으므로 실제 연결 확인을 대신할 수 없습니다. 잠금 화면에 표시되는 내용도 시스템의 표시 권한을 확인해 공공장소에서 불필요한 서버 메모가 노출되지 않도록 하세요.

iCloud 동기화: 구독 업데이트와는 별개입니다

iCloud 동기화는 현재 버전에서 지원하는 데이터를 개인 기기 간에 동기화하는 기능입니다. 기존 서비스 제공자의 서버 목록을 새로고침하는 구독 업데이트와는 별개의 기능입니다. Settings에서 동기화 옵션을 확인하고, 기기에서 원하는 iCloud 계정을 사용 중인지, 시스템이 관련 접근을 허용하는지, 네트워크를 사용할 수 있는지 확인하세요. 활성화 전에 중요한 구성을 저장하고 기기와 클라우드의 내용을 비교해 기존 데이터를 새 설정으로 착각하지 않도록 하세요.

한 기기에서 수정한 뒤 동기화가 완료될 때까지 기다리고 다른 기기에서 실제 결과를 확인하세요. 연결 상태, 시스템 권한, 모든 설정이 기기 간에 완전히 옮겨진다고 가정하지 마세요. 서버 비밀번호, 구독 주소, 키는 민감한 정보이므로 동기화되는 데이터 범위를 확인해야 합니다. 기기별 시스템 VPN 권한도 각각 확인해야 합니다.

Diagnostics: 단일 오류의 조건을 기록하세요

Diagnostics는 연결 관련 진단 정보를 수집하고 확인하는 기능으로, Settings의 해당 메뉴에서 열 수 있습니다. 먼저 현재 네트워크, 선택한 서버, Global Routing, 오류 재현 단계를 기록한 다음 사용할 수 있는 진단 도구를 실행하세요. 유효한 정보를 불필요한 요청으로 묻히지 않도록 명확한 오류 하나만 재현하는 것이 좋습니다.

결과를 확인할 때는 문제가 발생한 단계를 살펴보세요. 연결을 수립할 수 없는지, 인증에 실패했는지, 도메인 조회에 문제가 있는지, 대상 요청이 예상한 응답을 받지 못했는지 확인합니다. 진단 결과는 문제 범위를 좁히는 데 쓰이며 모든 대상에 대한 장기적인 결론은 아닙니다. 자료를 공유하기 전 구독 매개변수, 인증 정보, 키, 불필요한 개인 접속 기록을 가리세요. 문제 해결을 마친 뒤에는 필요한 경우 상세 기록을 끄세요.

07 · CHECK ORDER

설정 변경 후 점검 순서

기존 상태를 보존하고 ‘서버 → 모드 → 구성 → DNS → 진단’ 순서로 단계별 점검하면 여러 스위치를 동시에 바꾸는 것보다 원인을 찾기 쉽습니다.

  1. 기본 네트워크를 확인하세요. 현재 Wi-Fi 또는 셀룰러 네트워크를 사용할 수 있는지, 네트워크 인증이 필요한지 먼저 점검하세요. 이런 문제는 규칙을 바꿔 해결할 수 없습니다.
  2. 서버를 확인하세요. Home에서 점 표시가 선택된 항목을 가리키는지 확인하고, 보유한 정보를 기준으로 프로토콜과 매개변수를 점검한 다음 Connectivity Test를 실행하세요.
  3. Global Routing을 확인하세요. 규칙에 따라 사용하려면 Config를 선택하세요. 비교를 위해 Proxy를 잠시 사용했다면 원래 모드로 되돌리는 것을 잊지 마세요.
  4. Config를 확인하세요. 활성화된 파일, 규칙 순서, 정책 참조, FINAL을 점검하세요. 변경 후에는 기존 연결만 살펴보지 말고 요청을 새로 보내세요.
  5. 이름 조회와 진단을 확인하세요. 앞선 항목이 모두 확인된 뒤 DNS와 Diagnostics를 점검하세요. 변경할 때마다 결과를 기록하고 효과가 없으면 원래 설정으로 되돌리세요.

첫 연결을 아직 완료하지 않았다면 첫 연결 가이드를 읽고 정보 가져오기, 서버 선택, VPN 구성 허용, 연결 확인을 순서대로 진행하세요. 프로토콜 필드를 이해하려면 프로토콜 참고 자료를 확인하세요. 프로토콜 매개변수를 점검하는 대신 Global Routing을 바꾸지 마세요.

Proxy에서는 연결되지만 Config에서는 안 될 때 무엇을 먼저 확인해야 하나요?

먼저 Config에서 활성화된 파일, 해당 대상에 매칭되는 규칙과 연결된 정책을 확인한 다음 FINAL을 점검하세요. Proxy로 비교해 연결됐다는 사실은 그 테스트에서 현재 프록시 경로를 사용할 수 있었다는 뜻일 뿐, Config의 모든 정책이 유효하다는 뜻은 아닙니다. 정상 작동이 확인된 서버 매개변수는 우선 변경하지 마세요.

연결을 끈 뒤 자동으로 다시 연결됩니다. 구독 업데이트 때문인가요?

먼저 On Demand와 시스템 VPN 설정을 확인하세요. 구독 업데이트는 서버 정보를 새로고침하고, On Demand는 연결을 자동으로 시작합니다. 문제를 확인하는 동안 On Demand를 잠시 끄고 수동 스위치가 예상한 상태를 유지하는지 살펴보세요.

Data에 트래픽이 표시되는데 웹페이지가 열리지 않는 이유는 무엇인가요?

트래픽이 변했다고 해서 대상 요청이 성공한 것은 아닙니다. 백그라운드 활동, 연결 재시도, 일부 요청만으로도 데이터가 발생할 수 있습니다. 같은 대상을 기준으로 서버, Global Routing, 규칙, DNS를 확인하고 Diagnostics를 활용해 문제 범위를 좁히세요.

설정한 뒤 구독을 매번 다시 가져와야 하나요?

일반적으로 그럴 필요는 없습니다. 라우팅 모드, DNS, 구독 내용은 서로 다른 설정 항목입니다. 구독 주소나 기존 서버 정보가 바뀌었거나 항목이 실제로 누락된 경우에만 업데이트하거나 다시 가져오세요. 삭제하기 전에 원본 정보와 필요한 구성 사본을 보관하세요.