공식 가이드 · 기능 안내

Shadowrocket 기능 및 주요 설정

먼저 트래픽 처리 방식을 정한 다음 연결 시점을 설정합니다. Global Routing은 전체 라우팅 방식을 제어하고, Config의 규칙은 요청의 경로를 결정하며, On Demand는 시스템이 어떤 조건에서 자동으로 연결할지 정합니다. 이 세 가지는 서로 다른 설정입니다.

  • Home에서 서버와 라우팅 선택
  • Config에서 규칙 설정 관리
  • Settings에서 일반 설정 확인
  • Data에서 트래픽 기록 확인

이 페이지는 주로 iPhone과 iPad에서의 사용 방법을 다루며, 각 기능을 ‘무엇인지, 어디에 있는지, 어떻게 설정하는지, 무엇을 주의해야 하는지’ 순서로 설명합니다. 화면 언어와 앱 업데이트에 따라 메뉴 위치가 달라질 수 있습니다. 항목을 찾을 수 없다면 현재 화면과 앱 내 안내를 먼저 확인하고, 여러 설정을 동시에 변경하지 마세요.

Global Routing: Config, Proxy, Direct

Global Routing은 Home에서 현재 연결의 전체 라우팅 방식을 선택하는 기능입니다. Config, Proxy, Direct는 각각 규칙 기반 라우팅, 프록시, 직접 연결에 해당합니다. 평소 규칙에 따라 요청을 나누려면 Config를 사용하세요. 특정 요청이 선택한 서버를 통해 처리되는지 확인하려면 잠시 Proxy로 전환할 수 있습니다. 문제가 프록시 경로와 관련 있는지 확인할 때는 Direct를 비교용으로 사용할 수 있습니다.

모드 주요 처리 방식 사용 상황 먼저 확인할 항목
Config(규칙 기반) 현재 활성화된 구성의 규칙과 정책에 따라 요청을 처리합니다. 일상적인 규칙 분기, 로컬 네트워크와 기타 요청 구분 현재 구성, 규칙 순서, 정책 대상
Proxy(프록시) 트래픽을 프록시로 처리하며, Config의 일반 규칙에 따라 개별 분기하지 않습니다. 선택한 서버의 연결 경로를 잠시 확인할 때 선택한 서버의 유효 여부와 프로토콜 매개변수
Direct(직접 연결) 트래픽을 직접 연결로 처리합니다. 현재 네트워크에서 직접 접속한 결과와 비교할 때 현재 네트워크에서 대상에 직접 접속할 수 있는지

설정 방법: 모드를 선택한 뒤 새 요청으로 확인

Home을 열고 Global Routing에서 원하는 모드를 선택한 다음 돌아옵니다. Config를 사용할 때는 Config에서 예상한 구성이 활성화되어 있는지 확인하세요. Proxy를 사용할 때는 Home에서 예상한 서버가 선택되어 있는지 확인합니다. 대상 앱으로 돌아가 요청을 새로 보내고 결과를 살펴보세요. 기존 연결이나 캐시된 페이지를 새 테스트 결과로 착각하지 않도록 주의해야 합니다.

Direct는 시스템 VPN 연결을 끄는 설정이 아닙니다. 요청을 처리하는 방식을 나타내며 연결 스위치의 상태를 의미하지 않습니다. Proxy도 서버 매개변수 오류를 해결하지는 않습니다. 모드를 비교할 때는 네트워크, 대상 주소, 선택한 서버를 그대로 두고 조건 하나만 바꾸세요. 점검을 마친 뒤에는 임시 설정이 이후 사용에 영향을 주지 않도록 원래 라우팅 방식으로 되돌리세요.

Config: 규칙 유형, 순서 및 정책

Config는 구성 파일을 관리하며, 규칙 분기는 그중 중요한 기능입니다. 규칙은 ‘어떤 요청이 이 유형에 해당하는지’를 정하고, 정책은 ‘규칙에 일치한 요청을 어떻게 처리할지’를 정합니다. Global Routing에서 Config를 선택한 뒤 현재 구성을 열어 규칙 내용과 참조된 정책을 확인하세요. 파일을 가져오기만 하고 활성화하지 않았다면 해당 파일을 사용 중인 것이 아닙니다.

자주 사용하는 규칙 유형 구분하기

DOMAIN은 도메인을 정확히 일치시키고, DOMAIN-SUFFIX는 도메인 접미사와 하위 도메인에 적용됩니다. DOMAIN-KEYWORD는 도메인에 포함된 키워드를 기준으로 판단합니다. 주소 대역을 일치시키려면 IP-CIDR 또는 IP-CIDR6을 사용하고, GEOIP는 IP 지리 데이터베이스를 기준으로 분류합니다. USER-AGENT는 요청에서 확인할 수 있는 User-Agent 정보를 대상으로 하며, 모든 암호화 요청에 통용되는 식별 방식은 아닙니다.

PROXY, DIRECT, REJECT는 각각 프록시, 직접 연결, 거부를 처리하는 일반적인 정책입니다. 구성에서 사용자 지정 정책 그룹을 참조할 수도 있습니다. 사용자 지정 이름이 보이면 실제로 어떤 구성원이 선택되는지 확인하세요. 이름만 보고 최종 경로를 판단할 수는 없습니다.

[Rule]
DOMAIN-KEYWORD,ads,REJECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY

위 예시는 규칙 문법과 순서를 보여 주기 위한 것으로, 완전한 구성은 아닙니다. example.com은 예시 도메인입니다. 키워드 규칙은 예상하지 못한 도메인과 일치할 수도 있으므로 필요에 맞게 범위를 좁히세요. no-resolve는 해당 IP 규칙을 위해 도메인 조회를 추가로 실행하지 않는다는 뜻이며, DNS를 전역적으로 끈다는 의미는 아닙니다.

수정 방법: 구체적인 규칙은 앞에, 최종 처리는 뒤에

규칙은 일반적으로 위에서 아래로 확인되며, 일치하는 규칙이 있으면 해당 정책에 따라 처리됩니다. 따라서 구체적인 예외 규칙을 범위가 넓은 규칙보다 앞에 두세요. FINAL은 앞선 규칙과 일치하지 않은 요청을 마지막으로 처리하는 데 사용합니다. 수정 전에는 원래 구성을 보관하고, 수정 후 새 요청을 보내 사용할 수 있는 요청 기록에서 일치한 규칙과 처리 정책을 확인하세요.

원격으로 관리되는 구성은 업데이트 과정에서 로컬 내용을 대체할 수 있습니다. 개인 설정을 오래 유지하려면 구성의 업데이트 방식과 로컬 사본의 관계를 먼저 확인하세요. 출처를 모르는 규칙을 한꺼번에 많이 추가하지 마세요. 문제가 생겼을 때 중요한 정보는 규칙의 총수가 아니라 ‘어떤 요청이 어떤 규칙과 일치했는지’입니다.

Home: 구독 및 서버 관리

서버 항목에는 개별 연결에 필요한 프로토콜, 주소, 포트, 인증 매개변수가 저장됩니다. Subscribe는 사용자가 보유한 구독 정보를 바탕으로 여러 항목을 업데이트하는 기능입니다. 서버 정보와 Config는 서로 다른 종류의 자료입니다. 서버 정보는 어디에 연결할지, Config는 요청을 어떻게 분배할지를 정합니다. 구독을 가져온 뒤에도 선택한 서버와 Global Routing을 확인해야 합니다.

Add Server: 기존 서버 정보 항목별 확인

Home에서 Add Server로 이동한 뒤 보유한 정보에 맞는 프로토콜을 선택하고 해당 필드를 입력하세요. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard 등은 프로토콜마다 필요한 필드가 다르므로 서로 바꿔 적용할 수 없습니다. 주소와 포트 외에도 인증 정보, 전송 방식, TLS, Server Name 등을 확인해야 할 수 있습니다. 보유한 서버 정보와 앱에 현재 표시되는 필드를 기준으로 입력하세요.

QR 코드로 가져올 때는 Scan QR Code를 사용하고 저장하기 전에 인식된 내용을 확인하세요. QR 코드는 정보를 담는 방식일 뿐, 안에 든 매개변수가 반드시 올바르다는 뜻은 아닙니다. 직접 입력할 때는 앞뒤 공백, 포트 번호, 인증 정보가 정확하고 빠짐없는지 확인하세요. 표시 이름은 항목을 알아보기 쉽게 바꿀 수 있지만, 이름을 변경해도 연결 매개변수가 수정되지는 않습니다.

Subscribe: 업데이트 후 항목 및 선택 상태 확인

사용자가 보유한 구독을 추가하려면 Subscribe를 선택하고 기존 구독 주소를 입력한 뒤 저장하고 업데이트를 실행하세요. 구독 업데이트에 성공했다는 것은 주소를 읽어 인식 가능한 항목을 만들었다는 뜻일 뿐, 모든 서버에 연결할 수 있다는 의미는 아닙니다. 먼저 항목이 표시되는지 확인한 다음 서버 하나를 선택해 Connectivity Test를 실행하고 실제 요청도 확인하세요.

구독 업데이트에 실패하면 링크가 완전한지, 유효한지, 현재 네트워크에서 해당 주소를 읽을 수 있는지 먼저 확인하세요. 모든 항목을 반복해서 삭제하지 마세요. 업데이트 후 항목 이름이나 개수가 달라질 수 있으며 기존 선택을 다시 확인해야 할 수도 있습니다. 구독 주소와 QR 코드에 인증 정보가 포함될 수 있으므로 문제를 기록할 때 민감한 부분을 가리세요.

On Demand: 조건에 따라 자동 연결

On Demand는 시스템의 주문형 연결 기능을 사용해 조건이 충족될 때 연결을 시작합니다. 연결을 시작하는 시점을 정하며 Global Routing의 트래픽 분기 설정을 대신하지는 않습니다. 앱에서 Wi-Fi, 셀룰러 네트워크, 도메인과 관련된 조건을 제공할 수 있으며, 선택할 수 있는 항목은 현재 On Demand 화면을 기준으로 확인하세요.

설정 방법: 명확한 조건 하나부터 시작

Settings에서 On Demand 관련 설정으로 이동해 기존 조건을 먼저 확인한 뒤 실제 사용 상황에 맞게 추가하거나 수정하세요. 처음 설정할 때는 지정한 Wi-Fi 환경에서의 연결 동작처럼 확인하기 쉬운 조건 하나만 남기세요. 저장한 후 해당 네트워크로 전환해 시스템이 처리할 때까지 기다리고, 시스템 연결 상태와 실제 요청 결과를 확인하세요.

조건에 순서가 적용되거나 서로 덮어쓰는 관계가 있다면 화면 안내에 따라 확인하세요. 서로 모순되는 연결 조건과 연결 해제 조건을 여러 개 동시에 추가하지 마세요. 조건을 바꾸면서 서버, DNS, 구성 파일까지 함께 변경하지도 마세요. 그렇지 않으면 동작이 달라져도 어떤 설정이 영향을 주었는지 알기 어렵습니다.

주의 사항: 수동으로 연결을 끊은 뒤 다시 연결되는 이유

수동으로 연결을 끊었는데 다시 연결된다면 스위치 오류라고 단정하기 전에 On Demand 조건이 여전히 충족되어 연결을 시작하는지 확인하세요. 수동 연결을 안정적으로 유지하며 점검해야 한다면 먼저 On Demand를 끄고 기존 조건을 기록한 뒤 테스트를 마치고 다시 설정하세요. On Demand를 켠다고 배터리 소모가 반드시 줄어드는 것은 아닙니다. 실제 사용량은 조건이 실행되는 빈도, 백그라운드 요청, 네트워크 전환에도 영향을 받습니다.

Wi-Fi, 셀룰러 네트워크, 도메인 조건을 조합하는 방법은 On Demand 설정 안내에서 확인하세요. 백그라운드 배터리 사용량을 살펴보려면 백그라운드 배터리 사용량 점검 순서를 참고하고 비슷한 사용 조건에서 결과를 비교하세요.

Data: 트래픽 통계 확인

Data에서는 앱에 기록된 트래픽 정보를 확인할 수 있습니다. 일정 시간 동안 업로드·다운로드 또는 각 항목의 통계 변화를 살펴보는 데 유용하지만, 통신사 청구서나 사용자가 보유한 서비스의 데이터 사용량과는 다릅니다. 집계 범위, 초기화 시간, 네트워크 오버헤드가 다르면 화면마다 표시되는 숫자가 달라질 수 있습니다.

확인 방법: 같은 시간 범위에서 증감 비교

Data를 열고 현재 페이지에서 표시하는 통계 범위와 사용할 수 있는 분류를 먼저 확인하세요. 테스트 전 수치를 기록하고 대상 앱으로 돌아가 작업을 한 번 수행한 다음 다시 확인해 증가량을 비교합니다. 기록을 지우려면 과거 정보가 필요한지 먼저 확인하세요. 통계를 지워도 이미 사용한 외부 데이터 한도가 복구되지는 않습니다.

특정 서버가 실제로 트래픽을 처리하는지 확인하려면 총계만 보지 말고 선택한 서버, 라우팅 모드, 일치한 규칙을 함께 살펴보세요. 직접 연결 요청, 백그라운드 동기화, 다른 앱의 요청도 관찰 결과에 영향을 줄 수 있습니다. 다운로드 수치가 크다는 사실만으로 연결 품질이 더 좋다고 판단할 수는 없습니다. 처리량, 지연 시간, 요청 성공률은 서로 다른 지표입니다.

Data의 변화가 예상과 다르면 대상 요청을 새로 보냈는지, 캐시된 결과를 사용했는지 먼저 확인하세요. 이어서 연결이 계속 유지되었는지, 네트워크가 전환되었는지 살펴보세요. 페이지를 한 번 새로 고친 결과만으로 모든 요청의 처리 경로를 판단하지 마세요.

Settings: DNS, 테스트 방식 및 보조 기능

Settings에는 일반 동작과 보조 설정이 모여 있습니다. 점검할 때는 각 설정이 DNS 조회, 테스트, 시스템 진입점, 정보 동기화 중 무엇에 영향을 주는지 먼저 확인하세요. 일부 옵션은 현재 Config에서 제어될 수도 있습니다. 일반 설정을 바꾸기 전에 사용 중인 구성에 별도 지정이 있는지 확인해야 ‘설정을 바꿨는데 동작은 그대로’라는 착각을 피할 수 있습니다.

DNS: 설정 출처를 확인한 다음 조회 옵션 변경

DNS는 도메인을 주소로 변환합니다. 도메인 조회 실패와 서버 연결 실패는 로딩이 멈추는 등 비슷한 현상으로 나타날 수 있지만 해결 방법은 다릅니다. Settings의 DNS 관련 옵션과 현재 Config의 DNS 설정을 함께 확인해 실제로 어떤 DNS 설정을 사용하는지 파악하세요. 한 화면에 표시된 주소만 기록해서는 부족합니다.

용도를 명확히 알고 있는 DNS 매개변수를 사용하고, 원래 값을 보관한 뒤 한 번에 하나씩만 바꾸세요. 변경 후 새 도메인 요청을 보내 조건을 다시 테스트하세요. 캐시 때문에 이전 결과가 계속 나타날 수 있습니다. 로컬 네트워크 기기, 내부 도메인, 공개 도메인은 서로 다른 처리가 필요할 수 있으므로 모든 DNS 요청을 한 경로로 바꾼 뒤 원인을 찾으려 하지 마세요.

DNS 변경을 모든 시간 초과 문제의 만능 해결책으로 여기지 마세요. 프로토콜 인증 실패, 포트 접속 불가, 서버 시간 조건 미충족은 DNS 설정만 바꿔서는 대개 해결되지 않습니다. 먼저 ‘도메인을 조회하지 못하는 문제’와 ‘주소는 있지만 연결에 실패하는 문제’를 구분하세요.

Test Method: 테스트 결과를 비교할 수 있도록 설정

Test Method는 Connectivity Test에서 사용할 테스트 방식을 결정합니다. Settings에서 해당 항목을 찾아 현재 화면에서 사용할 수 있는 옵션을 선택하고 관련 테스트 대상을 확인하세요. 방식마다 측정하는 단계가 다릅니다. 기본 왕복 테스트와 더 많은 네트워크 단계를 거치는 테스트의 수치를 한데 놓고 직접 비교할 수는 없습니다.

서버를 비교할 때는 Test Method와 테스트 대상, 네트워크 환경을 동일하게 유지하세요. 테스트 시간 초과는 해당 테스트가 예상 시간 안에 완료되지 않았다는 뜻일 뿐, 모든 서비스 요청을 사용할 수 없다는 의미는 아닙니다. 반대로 테스트에 성공해도 모든 대상 웹사이트에 정상적으로 접속된다는 보장은 없습니다. 실제 접속 확인도 진행하세요.

Today Widget: 시스템 위젯 사용 여부 확인

Today Widget은 시스템 위젯을 통한 빠른 조작이나 상태 표시 기능입니다. 먼저 Settings에서 관련 설정을 확인한 다음 시스템 위젯 편집 화면에서 추가할 수 있는 Shadowrocket 항목을 살펴보세요. 지원 여부와 표시 방식은 시스템 및 앱에서 제공하는 기능에 따라 달라지므로 실제 기기 화면을 기준으로 확인하세요.

빠른 조작을 한 뒤 상태가 바로 바뀌지 않으면 연속해서 누르지 말고 Home과 시스템 VPN 상태를 확인하세요. 위젯은 조작을 위한 진입점이지 별도의 연결 구성이 아닙니다. 실제 동작에는 선택한 서버, Global Routing, On Demand 설정이 계속 영향을 줍니다.

iCloud: 동기화 범위를 확인한 뒤 다른 기기에서 점검

iCloud 관련 설정은 지원되는 범위에서 앱 정보를 동기화합니다. 먼저 시스템의 iCloud 상태와 Shadowrocket의 동기화 옵션을 확인하고 화면 안내를 읽어 어떤 항목이 동기화되는지 살펴보세요. iCloud를 켰다고 모든 서버, 규칙, 시스템 권한이 완전히 복사되는 것은 아닙니다.

다른 기기에서 조작하기 전에 중요한 로컬 구성을 보관한 다음 동기화 결과, 선택한 서버, 현재 구성을 확인하세요. 시스템 VPN 권한은 해당 기기에서 별도로 확인해야 합니다. App Store 구매 항목 복원과 iCloud 정보 동기화는 서로 다른 기능입니다. 전자는 구매 자격과 관련되고 후자는 앱 정보와 관련되므로 한쪽 상태로 다른 쪽을 판단할 수 없습니다.

Diagnostics: 문제를 파악하는 데 필요한 정보 수집

Diagnostics는 네트워크와 연결 문제를 살펴보는 데 도움이 됩니다. Settings에서 Diagnostics 관련 메뉴를 찾아 현재 화면에서 제공하는 점검 항목을 실행하세요. 유효한 진단을 위해서는 ‘기존 구독을 업데이트할 수 없음’이나 ‘특정 도메인 요청 시간 초과’처럼 증상을 구체적으로 정해야 합니다. 모든 검사를 한꺼번에 실행한 뒤 숫자가 더 작은 항목만 비교하지 마세요.

사용 방법: 먼저 문제를 재현한 다음 해당 기록 확인

현재 네트워크, Global Routing, 구성, 서버를 먼저 기록하고 자동 전환을 줄여야 한다면 On Demand를 잠시 끄세요. 그런 다음 문제를 한 번만 재현하고 해당 시점 전후의 진단 정보나 요청 기록을 살펴보세요. 조회 실패, 연결 시간 초과, 인증 오류, 규칙 정책 불일치처럼 원인을 구분할 수 있는 단서를 우선 확인하세요.

트래픽 분기를 확인한다면 대상 도메인, 일치한 규칙, 최종 정책을 서로 연결해 살펴보세요. 연결 문제를 확인한다면 Connectivity Test와 서버 매개변수부터 점검하세요. 요청 기록이 없다면 요청이 캐시되었는지, 현재 연결을 실제로 통과했는지, 기록 기능을 사용할 수 있는 상태인지도 확인해야 합니다.

설정 점검 순서: 조건을 한 번에 하나씩 변경

기능 간에는 서로 의존하는 부분이 있습니다. 먼저 앱을 확보하고 기존 정보를 확인한 뒤 연결을 점검하고, 마지막으로 규칙과 자동 동작을 확인하면 반복적인 변경을 줄일 수 있습니다. 아래 순서는 ‘정보를 가져왔지만 접속 결과가 예상과 다를 때’ 적합합니다.

  1. 기존 정보 확인. Home에서 서버 항목이 완전한지, 구독 업데이트가 성공했는지, 예상한 항목이 선택되어 있는지 확인하세요. 구독 정보를 읽을 수 있다는 사실만으로 연결이 가능한 것은 아닙니다.
  2. 시스템 연결 확인. 최초 VPN 구성 권한이 승인되었는지 확인하고 실제 연결 상태를 살펴보세요. 권한 안내의 의미는 VPN 구성 권한 안내를 참고하세요.
  3. 테스트 조건 확인. 네트워크를 그대로 유지하고 명확한 Test Method를 선택해 Connectivity Test를 실행한 뒤 실제 요청도 확인하세요. 시간 초과가 발생하면 연결 실패 점검 순서를 참고하세요.
  4. 라우팅 및 규칙 확인. Global Routing을 확인하세요. Config를 사용하는 경우 현재 구성, 규칙 순서, 정책 대상을 이어서 점검하세요. 모드를 임시로 전환했다면 원래 설정으로 되돌리세요.
  5. 마지막으로 자동 및 보조 설정 확인. 기본 연결이 안정된 다음 On Demand, DNS, 사용자 지정 테스트 방식, 동기화 결과를 하나씩 확인하세요. 변경 전후 내용을 기록해 두면 되돌리기 쉽습니다.
Proxy에서는 접속되는데 Config 결과가 예상과 다르면 무엇을 확인해야 하나요?

현재 활성화된 Config와 대상 요청이 일치한 규칙 및 정책을 먼저 확인한 다음 사용자 지정 정책 그룹의 구성원을 살펴보세요. 모드에 따라 결과가 달라진다는 점은 점검 범위를 좁히는 단서일 뿐, DNS나 서버 오류의 직접적인 증거는 아닙니다.

다른 기기로 바꾸면 설정을 다시 확인해야 하는 이유는 무엇인가요?

구매 항목 복원, 정보 동기화, 시스템 VPN 권한은 각각 다른 항목을 처리합니다. 앱을 복원했더라도 해당 기기의 권한, 현재 구성, 서버 선택을 확인해야 합니다. iPhone과 iPad의 호환성 및 시스템 요구 사항은 App Store 페이지를 기준으로 확인하세요.

가져오기부터 첫 연결까지의 전체 절차는 어디에서 확인할 수 있나요?

초보자 가이드를 순서대로 읽으며 기존 정보 가져오기, Global Routing 선택, 시스템 권한 승인, 실제 접속 확인을 진행하세요. 구매 및 구매 항목 복원에 관한 내용은 App Store 구매 및 설치 안내를 확인하세요.