공식 매뉴얼 · 기능 및 설정

Shadowrocket
프록시 모드 및 설정

먼저 Global Routing에서 라우팅 방식을 정한 다음 규칙과 서버를 확인하세요. On Demand는 연결이 시작되는 조건을 관리하고, Data와 Diagnostics는 실제 결과를 확인하는 데 사용합니다. 각 설정 계층은 서로 대체할 수 없습니다.

세 가지 모드 비교 단계별 설정

Global Routing: 세 가지 모드

구성 / 프록시 / 직접 연결에 해당하는 화면 용어는 Config / Proxy / Direct입니다.

Global Routing은 연결 트래픽에 적용할 라우팅 방식을 정하며, 서버를 만들거나 연결을 켜고 끄는 기능은 아닙니다. Home에서 Global Routing을 찾아 Config, Proxy 또는 Direct를 선택한 다음 현재 SERVER와 연결 상태를 확인하세요. 처음 사용할 때는 기존 서버 정보를 먼저 점검하고, 짧게 테스트해 연결 가능 여부를 확인한 뒤 Config로 돌아와 규칙을 검증하는 것이 좋습니다. 모드를 전환한 후에는 새 요청을 만들어 확인하세요. 이미 연결된 장시간 연결은 모드 전환이 적용됐는지 확인하는 기준으로 적합하지 않습니다.

모드 및 화면 용어라우팅 동작사용 시점주의 사항
구성 · Config현재 활성화된 구성 파일을 바탕으로 연결을 처리하며, [Rule]이 정책을 매칭합니다.일상적인 트래픽 분기 또는 특정 도메인이 DIRECT, PROXY, REJECT 중 어떤 경로를 사용하는지 확인할 때 사용합니다.먼저 어떤 Config가 활성화되어 있는지 확인한 다음 규칙 순서와 FINAL을 살펴보세요.
프록시 · Proxy주요 연결을 현재 선택한 프록시 서버로 보내며, 일반 규칙에 따라 항목별로 분기하지 않습니다.서버가 대상 요청을 처리할 수 있는지 짧게 확인해 규칙 문제의 범위를 좁힐 때 사용합니다.시스템 라우팅, 필요한 우회 항목 및 네트워크 환경의 영향을 받으므로 기기의 모든 트래픽을 반드시 처리한다고 볼 수는 없습니다.
직접 연결 · Direct주요 연결을 직접 연결하며 프록시 서버를 통해 전달하지 않습니다.직접 연결 경로의 상태를 비교해 직접 연결 문제와 프록시 경로 문제를 구분할 때 사용합니다.Direct는 VPN 연결을 끄는 모드가 아닙니다. 연결을 끄려면 Home의 연결 스위치를 조작하세요.

같은 대상을 기준으로 비교하고 여러 설정을 동시에 바꾸지 마세요

Proxy에서는 접속되지만 Config에서는 접속되지 않는다면 먼저 Config의 매칭 규칙, 정책 및 DNS 설정을 확인하세요. 이는 모든 서버 정보가 잘못된 것이 아니라 트래픽 분기 경로에 문제가 있을 수 있다는 뜻입니다. Proxy와 Config에서 모두 실패한다면 서버, 로컬 네트워크 및 프로토콜 설정을 확인하세요. Direct의 결과는 직접 연결 경로의 상태만 보여 주며, 이를 근거로 프록시 서버의 정상 여부를 판단할 수는 없습니다.

테스트할 때 현재 모드, 선택한 서버, 대상 도메인을 기록하고 테스트가 끝나면 원래 설정으로 되돌리세요. 문제를 한 번 확인하려고 예상과 다른 모드에 계속 머물지 마세요. 특히 구성 파일을 바꾼 뒤에는 Home의 연결 스위치가 켜져 있는지만 보지 말고 Global Routing도 다시 확인해야 합니다.

규칙 유형 및 정책

유형은 무엇을 매칭하는지, 정책은 매칭 후 어떻게 처리하는지를 나타냅니다.

Config에서 [Rule] 확인

규칙 기반 트래픽 분기는 Config 모드에서 구성 파일의 조건에 따라 연결 경로를 정하는 방식입니다. Config에서 현재 구성 파일을 열고 [Rule]을 찾아 위에서 아래 순서로 읽으세요. 일반 규칙은 매칭되면 이후 규칙을 더 확인하지 않는 경우가 많으므로 구체적인 조건을 포괄적인 조건보다 위에 두고, 매칭되지 않은 요청은 마지막의 FINAL에서 처리하도록 합니다.

DOMAIN은 도메인 전체를 매칭하고, DOMAIN-SUFFIX는 도메인과 하위 도메인을 매칭하며, DOMAIN-KEYWORD는 도메인에 포함된 키워드를 기준으로 매칭합니다. IP-CIDR과 IP-CIDR6은 각각 IPv4와 IPv6 네트워크 대역을 나타냅니다. GEOIP는 IP 지리 데이터베이스를 기준으로 판단합니다. USER-AGENT는 확인할 수 있는 User-Agent 정보를 대상으로 하므로 모든 연결에서 앱을 식별할 수 있다고 가정해서는 안 됩니다.

PROXY 정책은 프록시 경로로 전달하고, DIRECT는 직접 연결하며, REJECT는 요청을 거부합니다. 정책 이름은 서버 상태를 나타내지 않으며 새 서버 정보도 제공하지 않습니다. 먼저 요청이 어떤 규칙에 매칭됐는지 확인한 다음 정책에 따른 연결이 성공했는지 살펴보세요.

키워드만 보지 말고 규칙 우선순위도 확인하세요

문법이 모두 올바른 두 규칙도 서로 반대되는 결과를 낼 수 있습니다. 예를 들어 포괄적인 DOMAIN-SUFFIX를 특정 DOMAIN보다 앞에 두면 뒤의 규칙은 매칭될 기회를 얻지 못합니다. 수정 전 현재 구성을 백업하고 관련된 줄의 위치나 정책만 바꾼 다음 새 연결로 확인하세요. IP 규칙은 사용 가능한 조회 결과에도 영향을 받습니다. GEOIP 판단은 데이터베이스에 의존하므로 서비스의 실제 배포 위치를 정확히 증명하는 데 적합하지 않습니다. 전체 문법과 구성 항목은 규칙 및 구성 참고를 확인하세요.

Subscribe 및 서버 관리

서버 정보는 “어떻게 연결할지”를, 구성 규칙은 “언제 사용할지”를 결정합니다.

Add Server로 보유한 정보 추가

Home에서 Add Server를 누르고 보유한 정보에 맞는 Type을 선택한 다음 주소, 포트, 인증 및 전송 매개변수를 입력하세요. Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard, Hysteria2 등은 유형별 입력 항목이 다릅니다. 주소가 같다는 이유만으로 다른 유형의 매개변수를 복사하지 마세요. TLS, 서버 이름 및 전송 옵션도 기존 서버의 요구 사항과 일치해야 합니다. 입력 오류를 감추려고 인증서 검증을 끄지 마세요.

저장한 뒤 Home으로 돌아가 SERVER에서 현재 선택된 항목을 확인하세요. 목록에 서버가 표시된다고 해서 연결에 사용 중인 것은 아닙니다. 직접 입력할 때는 항목을 알아보기 쉬운 이름으로 지정하세요. 목록에 표시되거나 진단 정보를 공유할 때 노출될 수 있으므로 비밀번호, 키 또는 전체 구독 주소를 이름에 넣지 마세요.

Subscribe는 기존 구독 내용을 업데이트합니다

기존 구독은 보통 Add Server에서 Subscribe 유형을 선택해 추가할 수 있습니다. 자신의 구독 URL을 입력해 저장한 뒤 해당 항목의 업데이트 기능을 사용하고, 서버 항목이 표시되는지와 현재 선택이 예상대로인지 확인하세요. Subscribe에 포함된 액세스 정보는 민감한 정보로 취급해야 합니다. 공개 페이지에 붙여 넣거나 관련 없는 진단 도구에 입력하지 마세요.

구독 업데이트 실패와 서버 연결 실패는 서로 다른 문제입니다. 전자는 구독 주소의 유효성, 현재 네트워크에서 해당 주소에 요청할 수 있는지, 반환된 내용을 인식할 수 있는지와 관련됩니다. 후자는 실제 서버의 프로토콜, 인증 및 전송 설정과 관련됩니다. 업데이트에 성공해도 모든 서버에 연결할 수 있는 것은 아닙니다. 구독을 삭제하기 전에 연결된 항목도 함께 삭제되는지 확인하세요. 구독에서 생성된 항목을 직접 수정하면 다음 업데이트에서 변경 사항이 덮어써질 수 있습니다.

Connectivity Test는 지정된 테스트 조건만 확인합니다

Home에서 Connectivity Test를 사용하기 전에 Settings에서 Test Method를 확인하세요. 방식에 따라 포트 응답만 확인하거나 특정 대상에 대한 요청까지 확인할 수 있습니다. 특정 테스트를 통과해도 모든 웹사이트와 앱을 사용할 수 있다는 뜻은 아닙니다. 테스트에 실패한 경우에도 먼저 테스트 대상과 방식의 영향을 점검하세요. 테스트 결과와 실제 대상에 대한 요청을 함께 확인하는 것이 목록의 테스트 표시만 보는 것보다 정확합니다.

On Demand 자동 연결

연결이 언제 시작될지 제어하며 Global Routing과 [Rule]을 대체하지 않습니다.

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

On Demand를 사용하면 설정된 조건에 따라 시스템이 VPN 연결을 시작하거나 유지할 수 있습니다. 먼저 Home에서 수동으로 연결해 서버와 Config가 정상 작동하는지 확인한 다음 Settings의 On Demand에서 스위치와 설정 가능한 조건을 살펴보세요. 사용할 수 있는 조건은 현재 앱에 표시되는 항목을 기준으로 확인하세요. Wi-Fi 또는 셀룰러 네트워크와 관련된 조건은 적용 범위를 하나씩 확인하고, “자동 연결”을 “가장 빠른 서버 자동 선택”으로 오해하지 마세요.

설정을 마치면 예상한 네트워크 조건에서 다시 테스트하고 Home의 연결 상태를 확인하세요. Wi-Fi와 셀룰러 네트워크를 전환하면 기존 연결이 다시 설정될 수 있으므로 잠깐 끊기는 현상을 바로 규칙 문법 문제로 판단하지 마세요. 먼저 트리거 조건이 충족됐는지 확인한 뒤 연결이 설정된 후의 라우팅을 살펴보세요.

연결을 일시 중지할 때도 On Demand를 확인하세요

수동으로 연결을 끊은 뒤 연결이 다시 시작되면 먼저 On Demand가 활성화된 상태인지, 시스템이 기존 조건에 따라 다시 연결을 시작했는지 확인하세요. 연결을 일시 중지해야 한다면 먼저 On Demand 설정을 조정하고 연결 스위치를 조작한 다음 상태가 다시 바뀌지 않는지 확인하세요. 순서를 기록하지 않은 채 여러 설정을 반복해서 조작하지 마세요.

On Demand로 만료된 인증 정보, 잘못된 포트 또는 유효하지 않은 구성을 해결할 수는 없습니다. 자동 연결 후에도 접속할 수 없다면 수동 연결 절차로 돌아가 원인을 찾으세요. 업무용 네트워크에 별도의 연결 요구 사항이 있다면 자동 연결을 활성화하기 전에 네트워크 관리 규정과 로컬 리소스 접근 방식을 확인하세요.

Data 트래픽 통계

카운터 변화를 확인해 문제 해결에 참고하되 네트워크 요금 내역으로 간주하지 마세요.

Data에서는 앱이 기록할 수 있는 트래픽 정보를 확인합니다. Data를 열고 먼저 현재 화면의 통계 범위와 카운터 설명을 읽은 뒤 연결 전후의 업로드·다운로드 수치 변화를 살펴보세요. 화면마다 집계 범위가 다를 수 있으므로 한 세션, 특정 항목, 장기 누적 값을 단순히 더해 비교하지 마세요. 통계 반영 시점에도 차이가 있으므로 짧은 시간 동안 변화가 없다는 사실만으로 요청이 발생하지 않았다고 판단할 수 없습니다.

반복 가능한 작업으로 변화를 확인하세요

관련 없는 백그라운드 네트워크 활동을 먼저 멈추고 Data의 현재 카운터를 기록하세요. 그런 다음 고정된 페이지를 열거나 알고 있는 요청을 한 번 실행하고 Data로 돌아와 증가량을 비교합니다. 카운터를 초기화해야 한다면 문제 해결에 필요한 기록을 먼저 저장한 다음 화면에서 제공하는 초기화 기능을 사용하세요. 두 테스트를 비교할 때는 같은 대상과 비슷한 실행 시간, 동일한 통계 범위를 유지하세요. 실험 조건이 달라서 생긴 차이를 모드별 성능 차이로 해석하지 않도록 주의하세요.

Data의 카운터는 셀룰러 통신사의 과금 데이터와도, 사용자가 보유한 연결 서비스의 사용량 기록과도 다릅니다. 프로토콜 오버헤드, 재전송, 통계 집계 위치 및 측정 기간에 따라 수치가 달라질 수 있습니다. 특정 도메인이 PROXY 또는 DIRECT에 매칭됐는지 확인하려면 연결 기록과 현재 규칙을 함께 살펴보세요. 트래픽이 증가했다는 사실만으로 모든 요청이 같은 경로를 사용했다고 판단할 수는 없습니다.

Settings 주요 항목

메뉴 위치와 항목은 현재 앱 화면을 기준으로 확인하고 한 번에 한 가지 설정만 변경하세요.

Settings의 기능과 Config 파일은 함께 연결에 영향을 줄 수 있습니다. 아래 항목을 찾을 때는 전역 설정, 현재 구성 또는 시스템 권한 중 무엇을 조정하는지 먼저 확인하세요. 이름이 비슷하다고 같은 설정 계층에 속한다고 단정하지 마세요. 화면 위치는 앱 업데이트에 따라 달라질 수 있으므로 아래에서는 메뉴의 고정된 줄 번호 대신 영어 항목명을 사용합니다.

DNS: 도메인 조회 실패와 연결 실패 구분

DNS는 도메인을 연결에 필요한 주소로 변환합니다. Settings의 DNS 관련 옵션과 현재 Config의 [General]에 dns-server 등의 설정이 있는지 함께 확인하세요. 한쪽만 바꾸고 다른 쪽을 놓치지 않도록 주의해야 합니다. 문제를 살펴볼 때는 기존 값을 먼저 보존하고 도메인을 확인할 수 없는 것인지, 조회 결과가 예상과 다른 것인지, 주소는 확인되지만 연결이 실패하는 것인지 구분한 뒤 변경 여부를 결정하세요.

예를 들어 dns-server = system은 시스템 DNS 설정을 사용하는 구성 문법의 한 형태이며, 모든 네트워크에 적용할 수 있는 권장 설정은 아닙니다. DNS를 변경하면 IP 규칙 매칭과 실제 연결 대상에 영향을 줄 수 있지만 서버 인증 오류를 해결하지는 못합니다. 테스트 후 새 요청을 보내고 기존 DNS 캐시가 결과에 미칠 수 있는 영향도 고려하세요. 한 번 성공했다고 모든 도메인의 문제가 해결된 것은 아닙니다.

Test Method: Connectivity Test의 확인 범위

Settings에서 Test Method를 찾아 현재 옵션의 설명을 읽고 테스트 방식을 선택하세요. 해당 방식에 대상 주소가 필요한 경우 대상 자체에 접속할 수 있는지도 확인해야 합니다. 포트 수준의 응답과 앱 수준의 요청 완료는 서로 다른 결과이므로 방식이 다른 테스트를 직접 비교하기 어렵습니다. 변경 후 Home으로 돌아가 Connectivity Test를 다시 실행하고 동일한 대상을 실제로 접속해 확인하세요.

테스트 표시는 서버를 선별하고 문제를 찾는 데 참고할 수 있지만 지속적인 전송 성능이나 모든 요청의 사용 환경을 나타내지는 않습니다. 테스트만 실패하고 실제 사용은 정상이라면 서버 정보를 전부 다시 작성하기 전에 테스트 방식과 대상을 확인하세요.

Today Widget: 빠른 접근 및 시스템 표시 조건

Today Widget은 시스템에서 지원하는 위젯 위치에서 빠르게 확인하거나 조작할 수 있도록 합니다. 먼저 Settings에서 Today Widget 관련 옵션을 확인한 뒤 시스템의 위젯 편집 화면에서 해당 항목을 추가할 수 있는지 살펴보세요. 사용할 수 있는 형태는 기기의 운영체제와 현재 앱이 제공하는 기능에 따라 달라집니다. 특정 위젯 모양이 모든 기기에서 제공된다고 가정하지 마세요.

빠른 접근 기능도 저장된 서버, 구성 및 연결 권한을 사용합니다. 이를 누른 뒤 Home으로 돌아가 실제 상태를 확인하세요. 특히 기기에서 데이터를 복원한 직후이거나 앱의 초기 설정이 완료되지 않은 경우에는 주의해야 합니다. 위젯은 별도의 연결 설정을 제공하지 않으며 현재 SERVER 확인을 대신할 수 없습니다.

iCloud: 데이터 동기화와 구입 항목 복원은 별개입니다

여러 기기에서 설정을 유지하려면 Settings의 iCloud 동기화 항목을 확인하고 시스템에서 Shadowrocket의 iCloud 사용을 허용했는지 확인하세요. 활성화하기 전에 중요한 구성을 백업하고 두 기기에 이미 저장된 내용을 비교하세요. 동기화를 언제든 되돌릴 수 있는 이전 기록 보관 기능으로 여겨서는 안 됩니다. 동기화가 완료됐는지는 스위치가 켜져 있는지만 보지 말고 실제 항목을 확인하세요.

App Store의 구입 항목은 앱을 다시 받을 수 있는 권한을 복원하고, iCloud는 앱이 지원하는 데이터를 동기화합니다. 두 작업은 서로 다른 절차입니다. 기기를 바꾼 뒤 앱을 설치했더라도 서버 정보, Config 선택 및 VPN 권한을 확인해야 합니다. 동기화 범위는 앱 내 설명을 기준으로 확인하세요. 서버 인증 정보와 구독 내용은 민감할 수 있으므로 사용 전에 로그인한 계정과 기기 접근 권한을 점검해야 합니다.

Diagnostics: 상황을 기록한 뒤 진단 정보 수집

문제가 발생하면 Settings에서 Diagnostics를 찾아 앱이 제공하는 진단 또는 기록 기능으로 정보를 수집하세요. 먼저 문제가 발생한 시각, 네트워크, Global Routing, 선택한 서버 및 접속에 실패한 대상을 기록한 뒤 문제를 한 번 더 재현하세요. 이런 상황 정보는 오류 한 줄만 남기는 것보다 DNS 조회, 인증, 전송 또는 규칙 매칭 중 어느 단계의 문제인지 구분하는 데 도움이 됩니다.

기록을 공유하기 전에 도메인, IP, 구독 주소, 인증 정보 및 개인적인 접속 내용을 확인하고 불필요한 민감 정보를 삭제하세요. 로그에서 특정 요청이 실패했다고 해서 모든 연결이 불가능하다고 단정해서는 안 됩니다. 발생 시각과 동일한 대상을 반복 테스트한 결과를 함께 확인하세요. 문제 해결이 끝나면 임시로 변경한 진단 옵션을 되돌려 일상적인 사용과 무관한 기록이 계속 남지 않도록 하세요.

설정 후 검증 순서

먼저 기본 연결을 확인한 뒤 트래픽 분기와 자동 연결을 설정하세요.

  1. 입력한 정보를 확인합니다. Home에서 SERVER를 확인하세요. 구독을 추가한 뒤 항목이 온전히 표시되는지, 직접 추가한 경우 프로토콜, 주소, 포트 및 인증 정보가 맞는지 확인합니다.
  2. 반복할 수 있는 연결 테스트를 진행합니다. Test Method를 확인하고 Proxy 모드로 짧게 비교 테스트한 뒤 명확한 대상을 접속하세요. 테스트에 실패하면 먼저 기본 연결부터 점검합니다.
  3. Config로 돌아가 규칙을 확인합니다. 활성화된 구성 파일을 확인하고 [Rule]의 순서와 FINAL을 살펴본 뒤 대상 요청을 새로 만들어 관련 기록을 확인하세요.
  4. 그다음 On Demand를 활성화합니다. 수동 연결이 정상인 상태에서 트리거 조건을 테스트하세요. 네트워크를 전환한 뒤 상태를 다시 확인하고 자동 연결과 규칙 매칭을 혼동하지 마세요.
  5. 결과를 저장하고 임시 설정을 복원합니다. 검증한 구성을 기록하고 백업한 뒤 추가로 조정하세요. Data와 Diagnostics는 확인을 돕는 도구로 활용하고, 단일 테스트 표시를 최종 결론으로 삼지 마세요.

처음 설정하는 경우 Shadowrocket 사용법을 이어서 읽어 보세요. 구성을 한 줄씩 살펴보려면 규칙 및 구성 참고를 확인하세요. 앱을 아직 구입하지 않았다면 먼저 개발자, 공식 아이콘 및 앱 ID 확인 방법을 살펴본 다음 App Store에서 받으세요.