Shadowrocket 기능 및 설정 가이드 | Shadowrocket 공식 사이트

Global Routing: Config, Proxy, Direct

Global Routing은 현재 연결에 적용할 전체 처리 방식을 결정합니다. Home에서 Global Routing을 열고 용도에 따라 Config, Proxy 또는 Direct를 선택하세요. 한국어 설명의 ‘구성’, ‘프록시’, ‘직접 연결’은 각각 이 세 가지 영문 메뉴를 가리킵니다. 이 항목은 서버 세 대를 뜻하지 않으며, 누락된 서버 정보를 대신 입력하지도 않습니다.

메뉴 옵션	연결 처리 방식	적합한 작업	사용 전제 조건
Config(구성)	현재 Config를 읽고 Rule의 일치 결과에 따라 정책을 선택합니다.	도메인이나 대상 주소 등의 조건에 따라 평소처럼 트래픽을 라우팅합니다.	현재 사용 중인 구성과 규칙에서 참조하는 정책을 확인합니다.
Proxy(프록시)	일반적인 연결 처리를 선택한 프록시에 맡깁니다. 실제 동작은 시스템 및 관련 설정의 영향을 받습니다.	현재 서버가 요청을 처리할 수 있는지 일시적으로 확인합니다.	사용 가능한 서버를 선택했고 프로토콜 매개변수를 빠짐없이 입력해야 합니다.
Direct(직접 연결)	선택한 프록시 서버를 거치지 않고 직접 연결합니다.	현재 네트워크에서 대상에 직접 연결할 때의 결과를 비교합니다.	현재 네트워크에서 대상에 직접 연결할 수 있어야 합니다.

평소에는 Config부터 확인하세요

일부 대상은 PROXY, 나머지는 DIRECT로 처리하려면 Config를 선택한 다음 Config에서 올바른 파일이 활성화되어 있는지 확인하세요. 구성 파일을 가져오기만 해서는 현재 구성으로 지정되지 않습니다. 서버를 선택했다고 해서 모든 요청이 해당 서버를 통과하는 것도 아닙니다. 현재 구성, Global Routing, 서버 선택을 함께 확인해야 합니다.

문제 해결을 위해 Proxy로 잠시 전환한 뒤 같은 대상에 다시 접속해 보세요. Proxy에서는 정상인데 Config에서 문제가 발생한다면 모든 프로토콜 매개변수를 바로 바꾸기보다 규칙 일치 여부, 정책 참조, DNS를 먼저 확인하세요. Direct는 직접 연결 결과를 비교할 때 사용합니다. 비교할 때는 같은 네트워크와 대상을 사용하고 요청을 새로 보내야 합니다. 이전 연결을 전환 후의 결과로 오해하지 않도록 주의하세요.

Proxy를 선택해도 연결이 반드시 성공하는 것은 아니며, Direct를 선택해도 시스템의 모든 네트워크 설정이 꺼지는 것은 아닙니다. 테스트가 끝나면 원래 사용하려던 모드로 되돌리세요. 문제 해결 모드를 계속 사용하면 트래픽 경로가 예상과 달라질 수 있습니다.

Rule: 매칭 조건과 처리 정책

Rule은 ‘연결이 어떤 조건을 만족할 때 어떤 정책을 적용할지’를 정하는 순서가 있는 목록입니다. 현재 Config에서 확인할 수 있습니다. 편집이 필요하면 먼저 원본 구성의 사본을 저장한 뒤 규칙 섹션을 확인하세요. 규칙은 일반적으로 위에서 아래 순서로 매칭되므로 구체적인 조건을 더 포괄적인 조건보다 앞에 배치합니다. FINAL은 앞선 규칙에 매칭되지 않은 연결을 처리합니다.

자주 쓰는 규칙 유형 구분하기

DOMAIN: 지정한 전체 도메인과 일치합니다. 특정 호스트 이름 하나에만 적용할 때 적합합니다.
DOMAIN-SUFFIX: 지정한 도메인과 하위 도메인에 일치합니다. 같은 도메인 계열에 동일한 정책을 적용할 때 적합합니다.
DOMAIN-KEYWORD: 도메인에 포함된 키워드와 일치합니다. 범위가 넓으므로 관련 없는 대상까지 포함되는지 먼저 확인하세요.
IP-CIDR와 IP-CIDR6: 각각 IPv4 및 IPv6 주소 대역을 기준으로 매칭하며, URL 문자열을 기준으로 하지 않습니다.
GEOIP: 대상 IP의 귀속 정보에 따라 매칭합니다. 결과는 IP 주소 데이터베이스와 실제 DNS 조회 결과에 영향을 받습니다.
FINAL: 앞선 규칙에 매칭되지 않은 연결을 처리합니다. 기본 경로가 예상과 일치하는지 확인하세요.

PROXY, DIRECT, REJECT의 역할

매칭 유형은 ‘어떤 연결을 선택할지’를, 정책은 ‘선택한 연결을 어떻게 처리할지’를 정합니다. PROXY는 프록시 경로로, DIRECT는 직접 연결로 처리하며 REJECT는 연결을 거부합니다. 구성에서 이름이 지정된 정책을 참조하는 경우에는 해당 이름이 실제로 무엇을 가리키는지 확인하세요. 규칙이 있다는 사실만으로 구성이 완성된 것은 아닙니다.

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

아래는 구문 설명을 위한 별도의 예시이며, 완성된 구성이나 사용 가능한 서버 정보가 아닙니다. 첫 번째 줄은 example.com에만 매칭되며 하위 도메인은 자동으로 포함하지 않습니다. 두 번째 규칙은 example.net과 그 하위 도메인에 적용됩니다. 마지막의 FINAL,DIRECT는 앞선 규칙에 선택되지 않은 연결을 직접 처리한다는 뜻이지, 모든 연결을 기본적으로 PROXY에 맡긴다는 뜻이 아닙니다.

편집 후 저장하고 수정한 Config가 실제로 사용 중인지 확인한 다음, 실제 접속 기록으로 규칙 일치 결과를 살펴보세요. 한 페이지에서 여러 도메인에 요청할 수 있으므로 페이지의 기본 도메인이 규칙에 일치하더라도 이미지, 로그인, 기타 리소스가 같은 경로를 사용한다고 단정할 수 없습니다. 규칙 구문과 예시는 규칙 키워드 입문에서 확인하세요.

Subscribe 및 서버 관리

서버 항목에는 원격 연결에 필요한 프로토콜, 주소, 포트, 인증 정보가 저장됩니다. Subscribe는 이미 보유한 구독 주소에서 서버 항목을 업데이트하는 기능입니다. Home은 서버를 확인하고 선택하는 기본 화면이며, 서버를 직접 입력하려면 보통 Add Server로 이동합니다. 가져오기 전에 보유한 정보가 구독 주소인지, 단일 서버 링크인지, 전체 구성 파일인지 확인하세요. 모두 텍스트로 복사할 수 있어도 같은 메뉴에서 가져오는 것은 아닙니다.

가져온 후 구조를 확인하고 테스트하세요

보유한 정보 유형에 맞는 메뉴를 이용해 가져오세요. 단일 서버 항목은 Add Server에서 해당 프로토콜을 선택해 입력하고, QR 코드는 Scan QR Code로 읽을 수 있습니다.
가져온 항목을 열어 프로토콜, 주소, 포트와 해당 프로토콜에 필요한 인증 및 전송 매개변수를 확인하세요.
Home에서 사용할 서버를 선택한 뒤 Connectivity Test를 실행하고, 알려진 대상에 실제로 접속해 보세요.
Config를 사용한다면 규칙에서 참조하는 정책이 현재 서버 또는 사용 가능한 정책을 올바르게 가리키는지도 확인하세요.

구독을 업데이트하면 원격 콘텐츠를 기준으로 항목을 다시 가져옵니다. Subscribe에서 관리하는 서버를 직접 수정하면 다음 업데이트 때 로컬 변경 사항이 덮어써질 수 있습니다. 계속 유지해야 할 수정 내용은 미리 별도로 백업하세요. 구독이 다르면 이름이 비슷한 항목도 주소나 매개변수가 다를 수 있으므로 출처와 용도를 구분할 수 있는 로컬 메모를 사용하세요.

구독에 서버 목록이 포함되어 있어도 현재 필요한 Rule이나 DNS 설정까지 포함된다는 뜻은 아닙니다. 업데이트에 실패하면 먼저 주소가 완전하고 유효한지 확인한 다음 현재 네트워크에서 구독 주소에 접속할 수 있는지 살펴보세요. 공개 스크린샷, 로그, 게시물에 인증 정보가 포함된 구독 링크를 노출하지 마세요. 도움을 요청하기 전에는 인증 정보와 개인 식별 정보를 제거하세요.

구독을 삭제하거나 항목을 일괄 정리하기 전에 구성에서 해당 서버를 참조하는지 확인하세요. 서버를 선택할 수 있는 것과 실제로 사용할 수 있는 것은 다릅니다. Connectivity Test 결과도 테스트 방식에 따라 달라질 수 있으며, 판단 방법은 뒤에서 설명합니다. 서버 추가 및 가져오기의 전체 과정은 입문 가이드를 참고하세요.

On Demand: 조건에 따라 연결하기

On Demand는 설정한 조건이 충족될 때 시스템이 연결을 시작하도록 합니다. 반복해서 수동으로 조작하는 일을 줄이고 싶을 때 유용합니다. iPhone / iPad의 On Demand 설정에서 기존 조건을 먼저 확인하고 활성화 여부를 결정하세요. 조건 유형과 메뉴 위치는 앱 및 시스템의 현재 화면을 기준으로 확인해야 합니다. On Demand는 ‘언제 연결할지’를 정하는 기능이지, ‘요청을 어떤 규칙에 맡길지’를 정하는 기능이 아닙니다.

수동 연결을 확인한 다음 자동 조건을 활성화하세요

먼저 On Demand를 끄고 수동으로 연결해 서버, Config, DNS가 정상 작동하는지 확인하세요. 그다음 필요한 조건을 한 번에 한 그룹씩 추가합니다. 네트워크 환경에 따라 조건을 설정했다면 해당 환경에서 연결과 연결 해제 동작을 확인한 뒤 다른 환경에서도 테스트하세요. 한 Wi-Fi에서만 성공했다고 해서 모바일 네트워크나 다른 Wi-Fi에서도 예상대로 작동한다고 볼 수는 없습니다.

On Demand가 활성화되어 있으면 사용자가 수동으로 연결을 끊어도 시스템이 조건을 다시 충족해 재연결할 수 있습니다. 이것만으로 스위치가 작동하지 않는다고 판단하지 마세요. 잠시 멈추려면 먼저 On Demand 조건을 조정하거나 끈 다음 현재 연결을 해제하세요. Global Routing만 바꿔도 시스템이 조건에 따라 연결을 시작하는 동작은 멈추지 않을 수 있습니다. 두 설정은 서로 다른 단계에서 작동합니다.

자동 연결로 만료된 구독, 잘못된 비밀번호, 연결할 수 없는 서버를 해결할 수는 없습니다. 규칙과 서버가 안정적으로 작동하는 것을 확인한 뒤 활성화하세요. 기본 구성을 검증하기 전에 켜면 반복 연결 문제와 매개변수 오류를 구분하기 어렵습니다. 배터리 사용량은 네트워크 전환 빈도, 연결 시간, 실제 트래픽을 함께 살펴봐야 하며, 스위치 상태만으로 판단할 수 없습니다.

Data: 트래픽 통계와 확인 범위

Data에서는 앱에 기록된 트래픽을 확인할 수 있습니다. 이를 통해 데이터가 계속 전송되는지, 특정 작업에서 데이터가 발생했는지, 장기간 사용 추세가 어떤지 살펴볼 수 있습니다. 먼저 Data의 통계 범위와 표시 기간을 확인한 다음 수치를 읽으세요. 플랫폼이나 화면에 따라 표시 단위가 다를 수 있으므로 모든 기기에서 통계 항목이 같다고 가정하지 마세요.

반복 가능한 간단한 작업으로 비교하기

특정 작업을 확인하려면 먼저 현재 통계를 기록하고, 대상 하나를 열어 명확한 작업을 한 번 수행한 뒤 Data로 돌아와 변화를 확인하세요. 현재 화면에 초기화 기능이 있다면 보관할 기록을 먼저 저장한 다음 초기화하고 새로 측정하세요. 통계 초기화는 로컬 확인 기준을 지울 뿐, 이미 이용 중인 서비스의 사용량을 초기화하지 않습니다.

Data는 통신사 청구서도, 이미 이용 중인 서비스의 과금 내역도 아닙니다. 터널링 오버헤드, 재전송, 백그라운드 요청, 통계 산정 방식에 따라 차이가 생길 수 있습니다. 트래픽이 증가했다면 기록 범위 안에서 데이터 전송이 발생했다는 뜻일 뿐입니다. 수치만으로 웹페이지가 완전히 로드되었는지 또는 예상한 서버에서 콘텐츠를 받았는지 판단할 수 없습니다.

대기 중에도 트래픽이 계속 발생한다면 시스템 백그라운드 활동, On Demand 조건, 요청 기록을 함께 확인해 원인을 찾으세요. 특정 통계 수치를 낮추려고 여러 시스템 기능을 한꺼번에 끄지 마세요. 먼저 연결을 추적하고 조정이 필요한지 판단해야 비교 가능한 결과를 유지할 수 있습니다.

Settings: 자주 쓰는 항목과 조정 방법

Settings에는 테스트, 시스템 연동, 진단 관련 메뉴가 모여 있습니다. 일부 네트워크 동작은 현재 Config의 영향을 받을 수도 있으므로 설정을 바꾸기 전에 적용 범위를 확인하세요. 전체 설정인지, 현재 구성의 내용인지, 특정 서버의 개별 매개변수인지 구분해야 합니다. 기존 값을 기록하고 한 번에 하나씩 변경한 뒤 같은 대상으로 다시 테스트하세요.

DNS: 조회 결과를 확인한 다음 경로를 판단하세요

DNS는 도메인을 IP 주소로 변환합니다. DNS 설정은 Settings의 관련 메뉴에 있거나 현재 Config의 DNS 항목에 지정되어 있을 수 있습니다. 먼저 현재 구성에 DNS 설정이 있는지 확인한 다음 입력한 주소에 접속할 수 있는지, 예상한 설정인지 살펴보세요. 웹페이지가 열리지 않는다는 이유만으로 DNS를 계속 바꾸지 마세요. DNS를 변경해도 Global Routing이 자동으로 바뀌지는 않습니다.

도메인 규칙과 주소 규칙은 서로 다른 대상을 기준으로 합니다. 도메인은 규칙에 올바르게 매칭되어도 조회된 IP 주소에 연결할 수 없을 수 있고, 서버 연결은 정상이어도 도메인 조회가 실패할 수 있습니다. 문제를 확인할 때는 도메인, 조회 결과, 오류가 발생한 단계를 기록하면 DNS, 규칙, 서버 문제를 더 쉽게 구분할 수 있습니다. 설정 변경 후 요청을 다시 보내고, 필요하면 실제 화면의 안내에 따라 캐시를 처리하세요. 이전 조회 결과로 새 설정을 테스트하지 않도록 주의하세요.

Test Method: 테스트 결과의 의미

Settings의 Test Method에서 테스트 방식을 선택하면 연결 테스트의 동작에 영향을 줍니다. 먼저 선택한 방식의 테스트 대상과 판정 조건을 확인한 뒤 서버 결과를 비교하세요. 서로 다른 방식으로 얻은 수치를 한데 놓고 직접 비교할 수 없으며, 테스트 수치를 브라우저 다운로드 속도와 동일시해서도 안 됩니다.

비교할 때는 테스트 방식, 네트워크, 테스트 대상을 동일하게 유지하세요. 서버 테스트는 실패했지만 실제 접속은 정상이라면 해당 테스트 방식이 연결에 적합한지 먼저 확인하세요. 테스트는 성공했지만 페이지에 문제가 있다면 대상 서비스, DNS, 규칙을 추가로 살펴보세요. Connectivity Test는 문제 범위를 좁히기 위한 도구이며 모든 앱 요청의 성공을 보장하지 않습니다.

Today Widget: 시스템 바로가기

Today Widget은 시스템에서 지원하는 위젯 기능입니다. 관련 옵션은 Settings에서 확인할 수 있으며, 위젯 추가 가능 여부와 표시 방식은 시스템 및 앱에서 제공하는 메뉴에 따라 달라집니다. 먼저 앱에서 서버를 선택하고 수동 연결이 정상인지 확인한 다음 시스템의 위젯 편집 절차에 따라 추가하세요. 시스템에 해당 메뉴가 표시되지 않으면 실제로 사용할 수 있는 기능을 기준으로 하세요.

위젯은 상태 확인이나 빠른 작업에 적합하며, 복잡한 편집은 앱에서 진행해야 합니다. 위젯과 앱의 상태 표시가 잠시 다르면 구성을 바로 삭제하거나 구독을 다시 가져오지 말고, 먼저 앱에서 연결 상태를 확인한 뒤 시스템의 새로고침 여부를 살펴보세요.

iCloud: 동기화 범위와 백업 순서

iCloud 동기화 메뉴를 확인할 때는 시스템 계정, iCloud 사용 가능 여부, 앱 설정을 함께 살펴보세요. 활성화하기 전에 Settings에서 구체적으로 어떤 항목이 동기화되는지 확인하세요. 모든 서버, Config, 통계, 연결 상태가 함께 동기화된다고 가정하지 마세요. 기기별 로컬 선택이나 시스템 권한도 동기화 항목과 함께 이동하지 않을 수 있습니다.

다른 기기에서 처음 사용하기 전에 두 기기의 중요한 구성을 백업하고 어떤 내용을 기준 사본으로 유지할지 정하세요. 항목이 누락되면 여러 파일을 연달아 가져오기보다 동기화를 기다리면서 계정과 네트워크를 확인하세요. 동기화는 콘텐츠를 전달하는 기능이지 연결 검증을 대신하지 않습니다. 완료 후에도 기기별로 Global Routing, 현재 Config, 서버를 확인해야 합니다.

Diagnostics: 문제 발생 단계별로 정보 수집하기

Diagnostics에서는 현재 버전에서 제공하는 진단 항목을 확인하거나 실행할 수 있습니다. 보통 Settings의 관련 메뉴에서 열 수 있습니다. ‘작동하지 않는다’는 문제를 판단 가능한 항목으로 나누는 것이 목적입니다. 서버 연결 여부, 도메인 조회 여부, 요청에 일치한 규칙, 특정 대상에서만 발생하는 오류인지 확인하세요. 실제 화면에서 제공하는 항목을 기준으로 하며, 정보를 수집한다는 이유로 모든 진단 옵션을 계속 켜둘 필요는 없습니다.

진단 시 함께 기록할 네 가지 정보

환경: Wi-Fi와 모바일 네트워크 중 무엇을 사용 중인지, 한 네트워크에서만 문제가 발생하는지 기록하세요.
모드: Global Routing이 Config, Proxy, Direct 중 무엇으로 설정되어 있는지와 현재 사용 중인 구성을 기록하세요.
대상: 실패한 작업이 구독 업데이트, 서버 테스트, 특정 대상에 대한 실제 요청 중 무엇인지 확인하세요.
증상: 화면에 표시된 구체적인 오류, 발생 시각, 재현할 수 있는 조작 순서를 기록하세요.

모든 대상에 연결할 수 없다면 현재 네트워크, 서버 주소와 포트, 인증 매개변수, 시스템 시간을 먼저 확인하세요. 한 대상에서만 문제가 발생하면 해당 대상의 DNS, 규칙 일치 여부, 서비스 상태를 우선 살펴보세요. Config에서만 문제가 있고 Proxy는 정상이라면 구성 참조와 라우팅 규칙부터 확인하세요. 앱 재설치부터 시작하지 마세요.

진단 정보를 공유하기 전에 구독 인증 정보, 비밀번호, 개인 접속 도메인 및 기타 민감한 내용을 제거하세요. 진단이 끝나면 더 이상 필요하지 않은 상세 기록을 끄고 내보낸 파일을 안전하게 관리하세요. 시간 초과 및 연결 실패의 구체적인 확인 순서는 연결 시간 초과 문제 해결 가이드에서 확인할 수 있습니다. 프로토콜 필드 차이는 프로토콜 기술 참고를 참고하세요.

자주 쓰는 설정 확인 순서

모든 옵션을 한 번에 조정하지 마세요. 먼저 최소한의 연결을 검증한 다음 규칙, 자동 연결, 시스템 바로가기를 단계별로 추가하면 각 변경 사항의 영향을 파악하기 쉽습니다. 아래 순서는 기존 구성이 갑자기 작동하지 않을 때 다시 확인하는 데도 유용합니다.

입력 정보 확인: 이미 보유한 서버 또는 구독 정보의 유형을 확인하고 프로토콜, 주소, 포트, 인증 매개변수가 모두 입력되어 있는지 살펴보세요.
서버 확인: Home에서 예상한 항목을 선택하고 동일한 Test Method로 Connectivity Test를 실행한 다음 실제로 접속해 보세요.
모드 확인: Global Routing을 확인하세요. 규칙에 따라 처리하려면 Config를 선택하고 현재 파일이 올바른지 확인하세요.
규칙 일치 확인: Rule의 순서, 정책 참조, FINAL을 확인하고 요청 기록을 바탕으로 대상의 처리 경로를 살펴보세요.
DNS 확인: DNS의 출처와 적용 범위를 확인하고 DNS 조회 실패와 서버 연결 실패를 혼동하지 마세요.
자동 연결 설정: 수동 연결이 안정적으로 작동한 뒤 On Demand를 활성화하고 네트워크 환경별로 하나씩 확인하세요.
기준 기록 보관: 구성 사본을 저장하고 Data와 Diagnostics로 이후 변화를 비교한 다음 위젯과 동기화 설정을 검토하세요.

각 항목을 완료할 때마다 같은 대상에 다시 접속해 테스트하고 변경 전후 결과를 기록하세요. 새 설정으로 문제가 생기면 다른 설정을 덧붙여 해결하려 하지 말고 방금 변경한 항목부터 되돌리세요. 이렇게 하면 사용할 수 있는 구성을 보존하고 다음 문제 해결도 명확한 상태에서 시작할 수 있습니다.

이 페이지에서는 기능별 역할과 설정 범위를 확인할 수 있습니다. 처음 가져오기를 아직 완료하지 않았다면 입문 가이드에 따라 진행하세요. 설치 경로, 플랫폼별 설치 또는 구매 복원을 확인하려면 전체 플랫폼 다운로드 가이드를 참고하세요. 구체적인 질문은 FAQ에서 항목별로 찾아볼 수 있습니다.

Shadowrocket 기능 및 자주 쓰는 설정