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

Shadowrocket 기능 및 설정

먼저 Global Routing을 확인한 다음 Config와 서버를 점검하세요. 연결 스위치, 규칙 매칭, 조건부 연결은 서로 다른 단계이므로 문제를 확인할 때 동시에 변경하지 마세요.

Home · 연결 및 라우팅 Config · 규칙 및 구성 Settings · 동작 및 진단

Home / Global Routing

세 가지 라우팅 모드

Config, Proxy, Direct는 각각 구성, 프록시, 직접 연결을 뜻합니다. 전체 트래픽 처리 방식을 정하며 연결 스위치나 규칙 행에 표시되는 정책 이름과는 다릅니다.

화면에 표시되는 값처리 방식사용할 때먼저 확인할 항목
Config · 구성현재 활성화된 구성의 규칙에 따라 정책을 결정합니다.일상적인 도메인 및 IP 대역별 트래픽 분기에 사용합니다.Config에서 예상한 파일이 선택되어 있는지, 규칙과 FINAL이 올바르게 구성되어 있는지 확인합니다.
Proxy · 프록시전체 라우팅에 프록시 경로를 사용합니다. 실제 적용 범위는 시스템과 앱의 처리 범위에 따라 달라집니다.잠시 프록시 경로로 테스트해 규칙 매칭 문제인지 확인합니다.선택한 서버의 연결 여부와 인증, DNS, 대상 서비스가 정상인지 확인합니다.
Direct · 직접 연결프록시 서버를 거치지 않고 직접 연결하는 경로를 전체 라우팅에 사용합니다.현재 네트워크에서 대상에 직접 접속되는지 테스트합니다.로컬 네트워크, DNS, 대상 서비스에 연결할 수 있는지 확인합니다.

설정 위치와 확인 방법

Home에서 Global Routing을 찾아 기존 값을 기록한 다음 테스트할 모드를 선택하세요. Config를 사용하려면 Config 화면에서 준비한 파일이 실제로 활성화되어 있는지 확인합니다. 파일을 목록에 다운로드해 두기만 해서는 적용되지 않습니다. Home으로 돌아와 서버를 선택하고 연결을 켠 뒤, 같은 대상을 전후로 비교하세요. 대상을 바꾸면 결과를 제대로 비교하기 어렵습니다.

Proxy에서는 접속되지만 Config에서는 접속되지 않는다면 매칭된 규칙과 해당 정책을 확인하세요. 이는 원인을 좁히는 단서일 뿐 규칙이 잘못 작성되었다는 확정적인 근거는 아닙니다. Direct에서도 접속되지 않으면 현재 네트워크와 대상 서비스 상태부터 확인하세요. Direct는 시스템 VPN 구성을 끄는 모드가 아닙니다. 앱의 연결 처리를 완전히 중지하려면 연결 스위치를 사용하고 On Demand가 다시 연결을 트리거하지 않는지도 확인하세요.

일부 화면에는 Scene이 표시될 수 있습니다. Scene은 상황별 설정에 사용되며 이 절에서 다루는 기본 세 가지 모드에는 포함되지 않습니다. 문제를 확인할 때는 먼저 하나의 모드를 고정해 두고 Scene 전환 조건을 동시에 적용하지 마세요.

Config / [Rule]

규칙 유형과 실행 정책

규칙은 “어떤 요청이 일치하는지”, 정책은 “일치한 요청을 어떻게 처리하는지”를 정합니다. Config 모드에서는 규칙을 위에서 아래로 확인하고 처음 일치한 규칙을 적용한 뒤 검사를 멈춥니다. 키워드 길이에 따라 자동 정렬되지는 않습니다.

구체적인 조건을 먼저, 기본 규칙은 마지막에

DOMAIN은 전체 도메인과 일치합니다. DOMAIN-SUFFIX는 지정한 도메인과 하위 도메인에 일치하고, DOMAIN-KEYWORD는 도메인에 포함된 키워드를 기준으로 하므로 일반적으로 범위가 더 넓습니다. IP-CIDR과 IP-CIDR6은 각각 IPv4와 IPv6 주소 대역을 지정합니다. GEOIP는 IP 위치 데이터에 따라 일치 여부를 판단합니다. 결과는 데이터베이스와 DNS 확인 과정에 영향을 받으므로 웹사이트의 실제 소재지를 증명하지는 않습니다.

USER-AGENT는 확인할 수 있는 User-Agent 정보를 기준으로 일치 여부를 판단합니다. 모든 앱 요청에 적용된다고 가정하거나 일반적인 앱 식별 수단으로 사용하지 마세요. FINAL은 앞선 규칙에 일치하지 않은 요청을 처리하는 기본 규칙이므로 마지막에 배치해야 합니다. 앞에 두면 뒤에 오는 규칙은 매칭될 기회가 없습니다.

읽기용 규칙 예시

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

example.com과 example.net은 설명용 도메인입니다. 아래 내용은 규칙 순서의 예시이며 기존 구성을 대체해 바로 사용할 수 있는 완성 파일이 아닙니다.

PROXY, DIRECT 및 REJECT

PROXY는 프록시 경로를, DIRECT는 직접 연결을 사용하며, REJECT는 해당 요청을 거부합니다. 규칙에 PROXY를 적는 것만으로 서버 설정이 자동으로 채워지지는 않습니다. 필요한 서버나 정책이 유효하게 선택되어 있어야 합니다. REJECT는 차단 대상이 명확할 때 사용하세요. 범위를 너무 넓게 지정하면 페이지의 인증, 이미지, API 요청도 함께 실패할 수 있습니다.

Config에서 현재 파일을 열고 [Rule] 섹션의 유형, 매칭 값, 정책, 순서를 항목별로 확인하세요. 수정 전에 원본을 보관하고 한 번에 조건 하나만 변경한 뒤 대상 요청을 다시 보내 기록에서 매칭 결과를 확인합니다. 도메인 하나를 해결하려고 범위가 넓은 키워드 규칙을 맨 앞으로 옮기지 마세요.

규칙 및 구성 전체 참고서 보기

Home / SERVER / Add Server

Subscribe 및 서버 관리

서버 항목에는 연결 매개변수가 저장되고, Subscribe는 사용자가 보유한 Subscribe에서 항목을 업데이트하며, Config는 규칙 등의 구성 내용을 관리합니다. 서로 연관되어 있지만 서로 대체할 수는 없습니다.

Subscribe: 여러 항목 가져오기 및 업데이트

Home에서 추가 메뉴를 열고 Add Server로 이동한 다음 Subscribe를 선택해 본인이 보유한 Subscribe 주소를 입력하세요. 저장 후 업데이트를 실행하고 SERVER 화면에서 항목이 실제로 생성되었는지 확인합니다. Subscribe 주소에는 보통 접근 인증 정보가 포함되므로 공개 스크린샷이나 채팅, 진단 정보에 올리지 마세요.

업데이트에 실패하면 주소에 공백이나 줄바꿈이 들어갔는지, 매개변수가 만료되지 않았는지 확인한 다음 현재 네트워크에서 해당 주소에 접속할 수 있는지 점검하세요. 업데이트 성공은 Subscribe 내용을 다시 가져왔다는 뜻일 뿐, 포함된 모든 서버에 연결할 수 있다는 의미는 아닙니다. Subscribe로 관리되는 항목은 다음 업데이트 때 다시 생성될 수 있으므로 중요한 수동 변경 사항은 따로 기록해 두세요.

Add Server: 직접 입력 및 QR 코드 스캔

서버 매개변수가 하나 있다면 Add Server에서 해당 프로토콜을 선택하고 제공된 정보에 따라 주소, 포트, 인증 및 전송 옵션을 입력하세요. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 입력 항목의 의미가 다릅니다. 프로토콜 이름만 바꾸고 이전 항목의 매개변수를 그대로 두지 마세요.

Scan QR Code는 정보를 입력하는 방법일 뿐, 출처나 연결 가능성을 검증하지 않습니다. 스캔 후에도 프로토콜, 주소, 주요 매개변수를 확인하세요. QR 코드에 민감한 정보가 포함될 수도 있습니다. 항목을 저장한 뒤 먼저 Connectivity Test를 실행하고, 해당 항목을 선택해 실제 접속도 확인하세요. 항목이 추가되었다고 연결에 성공한 것은 아닙니다.

목록을 정리할 때 추적 가능성 유지

항목을 알아보기 쉬운 이름으로 표시하되 이름에 비밀번호를 쓰지 마세요. Subscribe에서 생성된 항목과 직접 추가한 항목을 구분하고, 삭제하기 전에 Config에서 참조 중인지 확인하세요. 서버 테스트는 통과했지만 대상에 접속할 수 없다면 Global Routing, 규칙, DNS, 대상 서비스를 계속 점검하세요. 같은 내용을 반복해서 삭제하고 다시 가져오지 마세요. 첫 연결 과정을 자세히 알아보려면 빠른 시작을 참고하세요.

Settings / On Demand

네트워크 조건에 따라 연결 트리거

On Demand는 지정한 조건을 충족할 때 시스템이 VPN 연결 동작을 트리거하는 기능입니다. “언제 연결할지”를 정하는 기능이지 “이 도메인에 어떤 경로를 사용할지”를 정하는 기능은 아닙니다. Wi-Fi, Cellular 등의 조건은 Global Routing 및 [Rule]과 서로 다른 계층에 속합니다. 기능을 켠 뒤에도 현재 Config와 서버가 정상적으로 작동하는지 확인해야 합니다.

Settings에서 On Demand를 찾아 현재 화면에 표시된 조건과 동작을 먼저 확인한 뒤, 명확한 사용 상황에 맞게 설정하세요. Wi-Fi 이름을 조건으로 사용할 때는 실제 네트워크를 확인하고 이름이 비슷하다는 이유만으로 판단하지 마세요. 처음 설정할 때는 쉽게 재현할 수 있는 조건 하나만 사용하고, 의도한 대로 작동하는지 확인한 후 다른 조건을 추가하세요.

권장 확인 순서

  1. 먼저 수동으로 연결해 현재 구성에서 필요한 대상에 정상적으로 접속되는지 확인합니다.
  2. On Demand 조건 하나를 설정하고 다른 설정은 그대로 둡니다.
  3. 해당 Wi-Fi 또는 Cellular 네트워크로 전환한 뒤 시스템 연결 상태를 확인합니다.
  4. 조건을 충족하지 않는 네트워크로 전환해 실제 동작을 확인합니다.

시스템 스케줄링, 네트워크 전환, 앱 상태가 트리거 시점에 영향을 줄 수 있으므로 초 단위로 정확히 작동하는 타이머로 간주하지 마세요.

수동으로 연결을 끊은 뒤 다시 연결된다면 시스템 VPN 구성을 바로 삭제하지 말고 On Demand 조건부터 확인하세요. 일반적인 연결 문제를 점검할 때는 조건을 기록하고 잠시 자동 연결을 끈 뒤 수동 연결을 테스트하고, 완료 후 다시 켤 수 있습니다. 네트워크를 자주 전환하는 경우 인증 페이지도 확인하세요. 웹 로그인이 필요한 Wi-Fi는 먼저 네트워크 자체의 접속 절차를 완료해야 합니다.

Data

트래픽 통계 확인 시 유의 사항

Data에는 클라이언트가 기록하는 범위의 트래픽 정보가 표시됩니다. Data를 열어 현재 통계가 어떤 범위, 방향, 기간을 집계하는지 먼저 확인하세요. 화면에 따라 합산 기준이 다를 수 있습니다. 업로드 및 다운로드 수치는 연결 여부를 살펴보는 데 도움이 되지만, 총량만으로 대상 페이지가 완전히 로드되었는지 판단할 수는 없습니다. 클라이언트 통계를 통신사 청구 내역과 동일시하지 마세요.

테스트를 시작하기 전에 표시된 값을 기록한 다음 명확한 작업 하나를 수행하고, 끝난 뒤 변화를 확인하세요. 백그라운드 동기화, 시스템 요청, 재시도, 프로토콜 오버헤드도 추가 트래픽을 발생시킬 수 있습니다. 콘텐츠를 재생하면서 다른 사이트까지 테스트하면 통계 변화의 원인을 구분하기 어렵습니다. 관찰 기준을 다시 잡으려면 이전 데이터를 먼저 기록한 뒤 현재 화면의 초기화 기능을 사용하세요. 초기화하면 삭제된 로컬 통계는 복구할 수 없습니다.

Data는 Subscribe의 사용량 조회를 대신하지 않습니다. 사용자가 보유한 서비스의 사용량, 유효 기간, 정산 기준은 해당 서비스 계정의 안내를 확인하세요. 클라이언트에 표시된 트래픽이 서버 측의 잔여 사용량을 보장하지는 않습니다. 사용량이 비정상적으로 늘어나는 문제를 조사할 때는 요청 기록으로 원인을 확인하고 테스트 범위를 좁히세요. Global Routing을 다른 모드로 바꾼 채 장시간 사용하는 것으로 해결하려 하지 마세요.

Settings

자주 사용하는 설정 항목별 확인

표시되는 설정과 선택 가능한 옵션은 현재 시스템 및 앱 화면에 따라 다릅니다. 변경하기 전에 기존 값을 기록하세요. 관련 기능이 구성 파일의 영향을 받는다면 Config도 확인해 화면의 설정 하나만 수정하는 일이 없도록 하세요.

DNS: 이름 확인과 연결을 구분하세요

기능: DNS는 도메인 이름을 주소로 변환하며, 그 결과가 이후 IP 기반 규칙 및 연결 경로에 영향을 줄 수 있습니다. 도메인 이름이 정상적으로 확인되더라도 서버 포트가 사용 가능하다는 뜻은 아닙니다. 연결 실패의 원인이 반드시 DNS인 것도 아닙니다.

위치 및 설정 방법: Settings에서 DNS 관련 설정을 찾고 현재 Config의 [General] 섹션에 이름 확인 설정이 있는지도 확인하세요. 기존 네트워크 요구 사항에 맞춰 DNS 리졸버와 관련 옵션을 점검하고, 한 번에 하나씩 변경한 뒤 동일한 도메인으로 다시 테스트하세요.

유의 사항: DNS를 무작위로 바꾸는 방법을 만능 해결책으로 여기지 마세요. 사설 네트워크 도메인, 인증 페이지, IPv6 동작에는 서로 다른 요구 사항이 있을 수 있습니다. 캐시 때문에 변경 내용이 즉시 반영되지 않을 수도 있습니다. 변경 전후의 DNS 확인 결과를 보관해야 차이를 파악하기 쉽습니다.

Test Method: 테스트 결과의 의미 확인

기능: Test Method는 Connectivity Test에서 사용할 탐지 방법을 결정합니다. 방법마다 확인하는 연결 구간이 다르므로 방법을 구분하지 않은 채 결과를 직접 비교하지 마세요.

위치 및 설정 방법: Settings에서 Test Method를 찾아 선택 가능한 방법과 테스트 대상을 확인하세요. 선택한 옵션을 기록한 뒤 Home으로 돌아가 Connectivity Test를 실행합니다. 서버 간 결과를 비교할 때는 같은 방법과 대상, 비슷한 네트워크 조건을 유지하세요.

유의 사항: 탐지에 성공해도 모든 웹사이트에 접속할 수 있다는 뜻은 아닙니다. 특정 탐지에 실패했다고 인증 정보가 잘못되었다고 단정할 수도 없습니다. 표시되는 수치를 낮추려고 방법을 반복해서 바꾸지 말고 실제 대상에 접속해 오류 메시지도 함께 확인하세요.

Today Widget: 빠른 실행 및 상태 확인

기능: Today Widget은 시스템 위젯을 통해 빠르게 접근할 수 있게 합니다. 실제로 사용할 수 있는 형태는 시스템 지원 범위에 따라 다릅니다. 위젯은 실행을 위한 진입점이지 별도의 라우팅 구성이 아닙니다.

위치 및 설정 방법: Settings에서 Today Widget 관련 옵션을 확인한 다음 시스템의 위젯 관리 화면에서 추가할 수 있는지 확인하세요. 현재 시스템에서 지원하는 방식으로 설정하고 빠른 작업을 한 번 실행한 뒤 Home에서 연결 상태와 선택된 서버를 확인합니다.

유의 사항: 위젯 정보는 일정 간격으로 갱신될 수 있으므로 오래된 상태만으로 현재 연결 여부를 판단하지 마세요. 위젯이 보이지 않으면 다른 기기의 화면 위치를 그대로 찾으려 하지 말고 시스템 지원 여부와 앱에 표시된 옵션부터 확인하세요.

iCloud: 동기화는 전체 백업과 다릅니다

기능: iCloud 관련 기능은 조건을 충족하는 기기 사이에서 앱이 지원하는 데이터를 동기화합니다. 구체적인 동기화 범위는 화면의 설명을 확인하세요. 서버 인증 정보, 구성 파일, 모든 Settings가 완전히 동기화된다고 가정하지 마세요.

위치 및 설정 방법: 먼저 시스템의 iCloud 권한과 계정 상태를 확인한 뒤 Settings에서 앱 내 동기화 옵션을 점검하세요. 전환하기 전에 기존 구성을 보관하고 다른 기기에서 파일 이름만 나타났는지 확인하는 데 그치지 말고 필요한 내용이 실제로 도착했는지 확인하세요.

유의 사항: 네트워크 상태, 저장 공간, 동기화 충돌이 결과에 영향을 줄 수 있습니다. 내용을 삭제하기 전에 다른 기기에 미칠 영향을 확인하세요. 동기화는 별도의 백업을 대신하지 않습니다. 내보낸 파일이나 구성에 서버 인증 정보가 포함될 수 있으므로 저장 및 전달 시 접근 범위를 제한하세요.

Settings / Diagnostics

진단 및 변경을 최소화하는 문제 해결

Diagnostics는 진단 단서를 수집하거나 확인해 DNS 확인, 연결, 인증, 규칙 경로 등의 문제를 구분하는 데 도움을 줍니다. Settings에서 해당 메뉴를 찾아 현재 제공되는 도구와 결과 설명을 먼저 읽은 뒤 문제를 다시 한 번 재현하세요. 플랫폼과 화면에 따라 제공되는 내용이 다를 수 있으므로 특정 도구가 없다고 앱의 연결 기능 자체가 없다고 판단하지 마세요.

명확한 대상 하나를 정해 문제를 확인하세요. Wi-Fi 또는 Cellular 사용 여부, Global Routing 값, 선택한 서버, 현재 Config, 실패 증상을 기록합니다. 기본 네트워크를 확인하고 서버 연결 및 인증을 점검한 다음 DNS와 규칙 매칭을 살펴보세요. 마지막으로 On Demand 등의 자동 연결을 다시 설정합니다. 한 번에 변수 하나만 바꾸고 테스트 결과를 기록해 여러 변경 사항이 원인을 가리지 않도록 하세요.

예를 들어 Proxy에서는 접속되지만 Config에서는 실패한다면 서버는 그대로 둔 채 해당 도메인이 범위가 넓은 규칙에 먼저 일치하는지, 적용된 정책이 예상과 맞는지 확인하세요. 두 모드에서 모두 실패한다면 FINAL의 위치를 계속 바꾸기보다 서버 매개변수, 현재 네트워크, 대상 서비스 상태를 확인하세요. 규칙, 서버, 시스템 네트워크 문제는 각각 다른 근거로 판단해야 합니다.

진단 정보를 공유하기 전에 Subscribe 주소, 인증 정보, 개인 도메인, 기기 정보, 접속 기록이 포함되어 있는지 확인하고 필요한 부분을 가리세요. 재현 절차와 관련 오류, 필요한 규칙 일부만 공유하면 됩니다. 문제 해결 조언을 받기 위해 전체 구성을 공개하지 마세요. 정상 작동이 확인되면 임시 테스트 설정을 원래대로 되돌리고 일상적으로 사용할 Config와 On Demand 조건도 다시 확인하세요.

구성 구조 및 규칙 매칭 참고 자료 더 보기
Shadowrocket 전체 플랫폼 다운로드