Shadowrocket
기능 및 설정

01 / ROUTING

Global Routing: Config, Proxy, Direct

Global Routing은 요청 처리 방식을 선택하는 기본 메뉴이며, 일반적으로 Home에서 엽니다. Config, Proxy, Direct는 각각 Config, Proxy, Direct에 해당합니다. 이 설정은 트래픽의 라우팅 방식을 정하며 서버를 생성하거나 서버 매개변수 오류를 수정하지는 않습니다. 모드를 선택하기 전에 서버 정보가 이미 가져와져 있는지, 현재 선택된 서버가 테스트하려는 서버인지 확인하세요.

1. Home에서 Global Routing을 열고 기존 선택 항목을 기록한 다음 확인하려는 모드로 전환하세요.
2. 같은 네트워크에서 같은 대상에 실제 접속해 보세요. 서버와 DNS를 동시에 바꾸면 결과 변화의 원인을 파악하기 어렵습니다.
3. Proxy로는 접속되지만 Config로는 접속되지 않는다면 규칙 일치 여부와 정책 참조를 먼저 확인하세요. 테스트가 끝나면 평소에 사용할 모드로 되돌리세요.

02 / RULE ROUTING

규칙 라우팅: 매칭 대상과 적용 정책

규칙 한 줄에는 ‘어떤 요청을’ ‘어떻게 처리할지’가 함께 정의됩니다. 규칙은 Config에서 현재 사용 중인 구성 파일에 있습니다. Global Routing에서 Config를 선택한 뒤 규칙이 실제로 적용되는지 확인하세요. 규칙은 일반적으로 위에서 아래 순서로 매칭되므로 구체적인 조건을 포괄적인 조건보다 위에 둡니다. 앞선 규칙이 이미 일치하면 뒤에 있는 같은 종류의 규칙은 해당 요청에 적용되지 않습니다.

DOMAIN은 도메인 전체와 일치하고, DOMAIN-SUFFIX는 지정된 도메인 및 하위 도메인과 일치하며, DOMAIN-KEYWORD는 도메인에 포함된 키워드로 매칭합니다. IP-CIDR과 IP-CIDR6은 각각 IPv4 및 IPv6 대역을 지정하고, GEOIP는 IP 지리 정보 데이터베이스를 기준으로 판단합니다. 도메인 규칙과 주소 규칙은 매칭 대상이 다르므로 웹페이지의 도메인만 보고 특정 주소 규칙이 반드시 적용된다고 단정할 수 없습니다.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

위 예시는 문법 설명을 위한 것입니다. example.com 및 하위 도메인에는 PROXY를 적용하고 나머지는 마지막 규칙인 FINAL,DIRECT로 처리합니다. DIRECT는 직접 연결, REJECT는 거부, PROXY는 Proxy 정책을 뜻합니다. 사용자 지정 정책 그룹을 참조한다면 해당 이름이 구성 파일에 실제로 있는지 확인하세요. 이 예시는 모든 네트워크에 적합한 완전한 구성이나 연결 서비스를 제공하지 않습니다.

1. 편집 전에 현재 구성 파일을 백업하고, 확인이 필요한 규칙만 추가하거나 수정하세요. 파일 전체를 그대로 덮어쓰지 마세요.
2. 정확한 예외 규칙을 포괄적인 규칙보다 위에 두고, FINAL은 규칙 목록의 마지막에 기본 처리 규칙으로 유지하세요.
3. 저장한 뒤 방금 수정한 파일이 활성화되어 있는지 확인하고 요청 기록에서 대상, 일치한 규칙, 정책을 확인하세요.

확인 사항: 규칙이 올바르게 적용되어도 대상 서버에 접속할 수 있다는 뜻은 아닙니다. 요청이 예상한 정책으로 전달되는데도 실패한다면 같은 규칙을 반복해서 추가하지 말고 서버, 이름 확인 및 네트워크를 점검하세요. 자세한 문법은 규칙 키워드와 매칭 순서를 참고하세요.

03 / SERVER MANAGEMENT

구독 및 서버: 목록과 개별 서버 매개변수 구분하기

서버 관리는 사용자가 이미 보유한 구독 또는 서버 정보를 기준으로 합니다. Home의 SERVER 영역에서 서버를 확인하고 선택할 수 있습니다. Add Server는 개별 서버 정보나 해당 유형의 항목을 추가하며, Subscribe에서는 구독 관련 작업을 합니다. 구독은 업데이트할 수 있는 서버 목록이고, 개별 공유 링크는 주로 서버 하나의 정보를 담습니다. 둘 다 링크라는 이유만으로 같은 입력란에 넣을 수는 없습니다.

가져오기 전에 보유한 정보가 구독 주소인지, 개별 공유 링크인지, 직접 입력해야 하는 매개변수인지 확인하세요. Add Server를 사용할 때는 기존 정보와 일치하는 유형을 선택한 뒤 주소, 포트, 인증 및 전송 설정을 하나씩 확인하세요. 구독은 해당 Subscribe 메뉴에서 추가하고 업데이트해야 합니다. 정확한 메뉴 위치는 현재 앱 화면을 기준으로 확인하세요. Scan QR Code로 QR 코드를 가져올 수 있지만, 스캔에 성공해도 정보가 인식된 것일 뿐 매개변수가 유효하다는 뜻은 아닙니다.

Shadowsocks, VMess, VLESS, Trojan, Hysteria2 등의 프로토콜은 인증 및 전송 항목이 서로 다를 수 있습니다. 예를 들어 VLESS의 인증 정보를 다른 유형의 비밀번호로 그대로 사용할 수는 없습니다. TLS, 전송 경로 또는 서버 이름이 필요한지는 사용자가 보유한 원본 서버 정보를 확인하고, 흔히 쓰이는 값을 임의로 입력해 맞추지 마세요.

1. 기존 구독을 업데이트하기 전에 현재 사용 중인 서버 이름과 그룹을 기록하고, 필요하다면 구성 파일의 백업을 저장하세요.
2. 업데이트 후 목록이 실제로 새로고침되었는지, 기존 선택 항목이 계속 있는지 확인하세요. 삭제되었거나 이름이 바뀐 항목은 다시 선택해야 합니다.
3. 먼저 Connectivity Test를 실행한 다음 실제로 접속해 보세요. 테스트 결과와 웹페이지 로딩 결과를 따로 기록하세요.

04 / CONFIG FILE

Config: 구성 파일과 서버 목록을 따로 관리하기

Config는 규칙 및 관련 구성 내용을 관리하며 서버 목록과는 용도가 다릅니다. 서버 매개변수는 어디에 어떻게 인증해 연결할지를 설명하고, 구성 파일은 요청을 어떻게 라우팅하며 어떤 관련 설정을 적용할지 정합니다. 구독을 업데이트해도 현재 구성 파일까지 함께 업데이트되는 것은 아닙니다. 구성 파일을 가져왔다고 해서 모든 서버 매개변수가 준비되었다고 볼 수도 없습니다.

Config에서 현재 활성화된 파일을 먼저 확인한 뒤 해당 파일의 보기 또는 편집 메뉴로 이동하세요. 수정 전에 복구 가능한 사본을 보관하고 기존 Global Routing 모드를 기록하세요. 사용자가 이미 보유한 출처의 구성 파일을 추가한다면 규칙, 정책 참조 및 이름 확인 설정을 먼저 살펴보고, 용도를 모르는 상태에서 활성화하지 마세요. 파일이 저장되더라도 모든 정책 이름이 올바르게 참조되는 것은 아닙니다.

확인 사항: 수정 내용을 저장한 후 활성화 표시가 있는 파일을 확인하고 대상 요청을 다시 실행해 실제 적용 결과를 살펴보세요. 이전 상태로 되돌릴 때는 서버 이름만 바꾸지 말고 구성 파일과 관련 설정을 복원해야 합니다. 복잡한 규칙 문제는 문제 해결 매뉴얼에서 증상별로 확인할 수 있습니다.

05 / ON DEMAND

On Demand: 네트워크 조건에 따라 연결하기

On Demand는 미리 설정한 조건에 따라 연결 동작을 실행합니다. 수동 연결이 정상임을 확인한 뒤 특정 네트워크 조건에서 자동으로 연결을 처리하고 싶을 때 사용할 수 있습니다. 서버 접속을 보장하거나 구성 오류를 자동으로 수정하는 기능은 아닙니다. 앱에서 On Demand 설정을 열고 현재 사용할 수 있는 네트워크 조건과 동작을 하나씩 확인하세요. 조건 항목은 기기에 실제로 표시되는 내용을 기준으로 합니다.

1. 먼저 On Demand 조건을 끄고 수동 스위치만 사용해 서버, 라우팅 모드 및 접속 결과가 예상대로인지 확인하세요.
2. On Demand로 이동해 필요한 조건 유형 하나만 활성화하세요. Wi-Fi 또는 네트워크 이름을 기준으로 설정할 수 있다면 현재 네트워크 이름과 정확히 일치하는지 확인하세요.
3. 조건에 해당하도록 네트워크를 전환한 뒤 시스템 연결 상태와 대상 접속 결과를 확인하세요. 원래 네트워크로 돌아와 복원 동작도 예상대로인지 점검하세요.

주의: On Demand 규칙을 켜 두면 수동으로 연결을 끊어도 다시 연결되어 스위치가 켜질 수 있습니다. 연결을 안정적으로 중지하려면 On Demand가 여전히 적용 중인지 먼저 확인하세요. 이 현상만으로 앱에 문제가 있다고 판단하지 마세요. 문제를 확인할 때 자동 조건을 잠시 끄고 수동 연결을 테스트하면 상태가 반복해서 바뀌는 일을 줄일 수 있습니다.

06 / DATA

Data: 트래픽 변화와 접속 기록 확인하기

Data에서는 클라이언트의 트래픽 통계와 관련 기록을 확인할 수 있어 요청 활동 및 데이터 변화를 살펴보는 데 유용합니다. 통계를 비교하기 전에 집계 범위, 시간 범위 및 화면에 표시된 단위를 확인하세요. 클라이언트 기록과 사용자가 보유한 연결 서비스의 과금 통계는 집계 기준이 다를 수 있으므로 여기에 표시된 수치를 잔여 데이터나 청구 금액으로 간주하지 마세요.

먼저 Data에서 기준값을 기록한 뒤 고정된 페이지 하나를 불러오는 등 통제된 접속을 실행하고 다시 돌아와 변화를 확인하세요. 라우팅을 확인하려면 이용 가능한 요청 기록에서 도메인, 대상 주소 및 정책을 함께 살펴보세요. 속도를 확인하려면 네트워크, 서버 및 테스트 대상을 동일하게 유지해야 합니다. 전체 트래픽이 늘었다는 사실만으로 특정 페이지가 완전히 로드되었다고 볼 수는 없습니다.

확인 사항: 백그라운드 작업, 시스템 요청 및 다른 앱의 활동도 동시에 트래픽을 발생시킬 수 있습니다. 문제를 확인할 때는 불필요한 활동을 줄이고 작업 전에 집계 범위를 기록하세요. 기록을 지우면 문제를 파악할 단서가 사라질 수 있으므로 필요한 정보를 먼저 보관하세요. 다른 사람에게 문제를 설명할 때는 해당 테스트와 관련된 부분만 남기고, 도메인 외에 개인 사용 내역이 드러날 수 있는 정보는 가리세요.

07 / SETTINGS

Settings: 이름 확인, 테스트 및 보조 기능

Settings의 옵션은 서로 다른 기능에 영향을 주므로 모두 켜야 하는 설정으로 취급하지 마세요. 문제가 도메인 이름 확인, 연결 테스트, 빠른 작업, 구성 동기화 또는 진단 중 어디에 해당하는지 먼저 파악한 뒤 관련 항목으로 이동하세요. 아래에 안내된 메뉴 위치와 사용 가능한 옵션은 기기 및 앱 화면에 따라 달라질 수 있으므로 실제 조작 시 현재 표시되는 영문 문구를 기준으로 확인하세요.

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

DNS는 도메인 이름을 IP 주소로 변환합니다. Settings에서 DNS 관련 항목을 확인하고 현재 Config에 이름 확인에 영향을 주는 설정이 있는지도 살펴보세요. 지연 시간 테스트는 정상이지만 웹페이지가 열리지 않는다면 이름 확인, TLS, 대상 서비스 또는 규칙 등 다른 단계의 문제일 수 있습니다. 한 가지 증상만으로 DNS 오류라고 단정하지 마세요. 먼저 현재 DNS 설정을 기록한 다음 같은 도메인으로 테스트하세요. 변경이 필요하다면 관련 항목 하나만 수정하고 되돌릴 방법을 마련해 두세요.

확인 사항: Proxy 서버 주소, 구독 주소 및 DNS 주소를 서로 대신 입력하지 마세요. 변경 후 일부 도메인만 접속된다면 해당 도메인에 적용된 정책과 이름 확인 결과를 추가로 확인하세요. 자세한 절차는 DNS 조회 실패 점검 목록을 참고하세요.

Test Method: 테스트 결과가 의미하는 것 확인하기

Test Method는 연결 또는 지연 시간 테스트에 사용할 방법을 정하며 Settings에서 확인할 수 있습니다. 테스트 방법마다 확인하는 연결 구간이 다르므로 각 방법의 수치를 직접 비교해 순위를 매기지 마세요. 현재 선택된 방법과 관련 대상을 먼저 확인한 뒤 Connectivity Test를 실행하세요. 방법을 변경한 경우에는 같은 서버들을 새로 테스트하고 이전 결과와 새 결과를 섞어 비교하지 마세요.

확인 사항: 응답이 빠르다고 해서 지속적인 데이터 전송 속도도 빠른 것은 아니며, 테스트 시간 초과가 모든 요청의 실패를 뜻하지도 않습니다. 실제 대상으로 접속해 확인하고 당시의 라우팅 모드도 기록하세요.

Today Widget: 빠른 작업도 기존 설정에 따라 동작합니다

Today Widget은 시스템 위젯과 관련된 보조 메뉴입니다. 앱과 시스템에서 해당 항목을 제공한다면 Settings에서 설정 가능한 내용을 확인한 뒤 시스템에서 지원하는 방법으로 추가하거나 관리하세요. 시스템 요구 사항은 App Store 페이지 표기를 기준으로 확인하세요. 위젯을 추가할 수 있는지와 표시 방식은 기기에 제공되는 메뉴를 기준으로 합니다.

위젯을 추가하기 전에 앱에서 선택된 서버와 연결 상태를 확인하고, 추가한 뒤에는 위젯 표시가 실제 상태와 일치하는지 확인하세요. 빠른 실행 메뉴가 구성 점검을 대신하지는 않습니다. 표시가 바로 바뀌지 않는다면 연결을 반복해서 실행하지 말고 앱과 시스템의 상태를 확인하세요.

iCloud: 동기화 후에도 이 기기의 상태 확인하기

iCloud 관련 기능은 지원되는 범위에서 앱 데이터를 저장하거나 동기화하며, 해당 옵션은 Settings에서 확인할 수 있습니다. 사용하기 전에 기기에서 본인의 Apple 계정에 로그인했는지, 시스템에서 앱의 iCloud 사용을 허용했는지 확인하세요. 먼저 이 기기에서 복구할 수 있는 사본을 보관한 다음 화면에 제공되는 방법으로 동기화 또는 복원을 실행하세요. 동기화 범위는 옵션 설명을 기준으로 하며, 모든 데이터와 시스템 권한이 함께 이전된다고 가정하지 마세요.

확인 사항: 다른 기기에서도 현재 구성, 서버 선택 및 VPN 구성 권한을 확인해야 합니다. iCloud 동기화를 실시간 연결 상태 동기화로 여기지 말고, 어느 쪽의 데이터가 덮어써지는지 모르는 상태에서 복원을 연속 실행하지 마세요.

Diagnostics: 재현 가능한 문제 단서 보관하기

Diagnostics는 진단 정보를 수집하는 데 도움을 주며, 해당 메뉴는 Settings에서 찾을 수 있습니다. 문제가 발생한 네트워크, 라우팅 모드 및 조작 단계를 먼저 기록한 다음 화면 안내에 따라 관련 결과를 한 번 수집하세요. 문제를 재현할 때는 테스트 대상을 동일하게 유지하고, 다시 시도하기 전에 이전에 변경한 항목을 기록해 로그가 실제 설정과 맞지 않는 일을 방지하세요.

주의: 진단 정보에는 서버 주소, 요청 정보 또는 인증 관련 항목이 포함될 수 있습니다. 내보내거나 공유하기 전에 항목별로 확인하고 민감한 정보는 가리세요. 문제를 설명하는 데 필요한 최소한의 부분만 보관하세요. 진단 정보는 문제 범위를 좁히는 데 사용하며, 오류 문구 하나만으로 모든 설정을 한꺼번에 초기화하지 마세요.

08 / VERIFICATION

설정 후 확인: 하나의 요청을 단계별로 점검하기

각 기능은 서로 연결되어 있습니다. 서버 매개변수는 연결의 기반이 되고, Global Routing은 처리 모드를 정하며, Config는 규칙 정책을 정합니다. DNS는 이름 확인에 관여하고 Data와 Diagnostics는 상태를 파악할 단서를 제공합니다. 설정이 제대로 작동하는지 판단하려면 스위치가 켜져 있는지만 보는 대신 같은 요청을 각 단계별로 점검하는 것이 좋습니다.

1. 연결 기반 확인. 사용자가 이미 보유하고 있고 매개변수가 모두 입력된 서버를 사용하는지, 현재 네트워크가 작동하는지, 시스템에서 필요한 VPN 구성 권한을 허용했는지 확인하세요.
2. 라우팅 모드 확인. Global Routing이 테스트 목적에 맞는지 확인하세요. Config를 사용한다면 활성화된 파일과 적용된 규칙도 점검하세요.
3. 실제 접속 확인. 테스트를 실행한 다음 고정된 대상에 접속하고 성공, 시간 초과 또는 구체적인 오류를 기록하세요. 지연 시간 수치만으로 결론을 내리지 마세요.
4. 자동 동작 확인. 평소 설정으로 되돌리기 전에 On Demand가 연결 상태를 다시 바꾸는지 확인하고 이번에 유효했던 설정을 기록해 두세요.

아직 설치하지 않았다면 먼저 App Store 정품 확인 및 구매 안내를 읽어보세요. Shadowrocket을 받을 수 있는 유일한 곳은 App Store입니다. App Store의 개발자는 Shadow Launch Technology Limited이며 앱 ID는 932747118입니다. 가격, 시스템 요구 사항 및 구매 적용 범위는 App Store 페이지 표기를 기준으로 확인하세요. 처음 가져오는 방법은 사용 가이드를 참고하고, 문제가 계속되면 문제 해결 매뉴얼에서 항목별로 점검하세요.