이 페이지에서는 주로 iPhone과 iPad의 사용 방식을 설명합니다. 기기와 앱 버전에 따라 메뉴 위치가 다를 수 있으므로, 설정 이름과 선택지는 앱에 표시되는 내용을 기준으로 확인하세요. 시스템 요구 사항은 App Store 페이지를 참고하세요. 처음 사용할 때는 보유한 서버 정보를 가져오고 연결을 승인한 다음 아래 옵션을 조정합니다.
앱은 한 번 구매하면 계속 사용할 수 있지만, 회선 요금제는 별도입니다. Shadowrocket은 유료 상용 앱이며 소스가 공개되어 있지 않습니다. 구매 및 설치는 App Store에서만 가능합니다. 이 안내는 본인의 구독 정보나 서버 정보를 이미 보유한 경우를 전제로 합니다. 구독 링크는 이용 중인 서비스 제공업체에서 확인하세요. 이 사이트는 서버나 구독을 제공·판매·추천하지 않습니다.
01 / ROUTING
Global Routing: Config, Proxy, Direct
Global Routing은 요청을 전반적으로 처리할 방식을 정합니다. Home에서 Global Routing을 열면 Config, Proxy, Direct 중 하나를 선택할 수 있습니다. 이 선택은 서버 프로토콜이나 연결을 켜고 끄는 설정과는 다릅니다. 서버 매개변수는 연결 방식을 정하고, Global Routing은 트래픽을 처리하는 방식을 정합니다.
| 모드 | 처리 방식 | 사용 상황 | 확인할 항목 |
|---|---|---|---|
| Config | 현재 적용 중인 설정의 규칙과 정책에 따라 요청을 처리합니다. | 도메인, 주소 등의 조건에 따라 평소 트래픽을 분기할 때 사용합니다. | 현재 Config, 규칙 순서, 일치 정책, FINAL을 확인합니다. |
| Proxy | 클라이언트가 처리하는 요청을 Proxy 방식으로 전달합니다. 실제 동작은 관련 제외 설정의 영향을 받습니다. | 선택한 서버가 대상 요청을 처리할 수 있는지 잠깐 확인할 때 사용합니다. | 선택한 서버, 프로토콜 매개변수, Proxy 관련 설정을 확인합니다. |
| Direct | 클라이언트가 처리하는 요청을 Direct 방식으로 전달합니다. | 현재 네트워크에서 직접 연결했을 때의 결과와 비교해 문제 범위를 좁힙니다. | 로컬 네트워크, DNS 응답, 대상 서비스 상태를 확인합니다. |
평소에는 먼저 Config를 확인하세요
신뢰할 수 있는 Config 파일이 있다면 먼저 Config에서 사용할 파일을 확인한 뒤 Home으로 돌아가 Global Routing → Config를 선택하세요. 파일을 목록에 가져오기만 해서는 적용된 것이 아닙니다. 규칙의 PROXY가 항상 같은 서버를 뜻하는 것도 아닙니다. Config에서 정책 그룹을 사용한다면 그룹 안에서 선택된 항목도 확인해야 합니다.
Proxy와 Direct를 비교 기준으로 활용하세요
특정 사이트가 열리지 않으면 다른 조건은 그대로 둔 채 Proxy와 Direct에서 각각 결과를 확인할 수 있습니다. Proxy에서는 접속되지만 Config에서는 안 된다면 해당 요청이 잘못된 정책으로 전달되는지 규칙을 먼저 점검하세요. 두 방식 모두 실패하면 DNS, 현재 네트워크, 대상 서비스 상태를 확인합니다. 점검을 마친 뒤에는 원래 사용하던 모드로 되돌려 임시 설정이 계속 남지 않도록 하세요. 어떤 모드를 선택해도 모든 시스템 트래픽이 반드시 같은 경로를 거치는 것은 아니므로 실제 연결 기록도 확인해야 합니다.
02 / RULE
규칙 분기: 일치 조건과 처리 정책
규칙은 Config에서 요청 처리 방식을 지정하는 조건 목록입니다. Global Routing → Config를 사용하면 일반적으로 규칙을 위에서 아래로 확인하고, 일치하는 항목의 정책을 적용합니다. 따라서 규칙의 내용뿐 아니라 배치 순서도 중요합니다. Config에서 현재 규칙을 확인하거나 설정 파일의 [Rule] 섹션에서 개별 항목을 살펴볼 수 있습니다. 수정하기 전에 원본 파일을 따로 보관하세요.
| 키워드 | 일치 대상 | 사용 시 주의사항 |
|---|---|---|
DOMAIN | 전체 도메인 이름입니다. | 명시한 단일 호스트 이름에 사용합니다. |
DOMAIN-SUFFIX | 도메인 자체와 하위 도메인입니다. | 하위 도메인을 하나씩 나열하는 것보다 같은 도메인 범위를 다룰 때 적합합니다. |
DOMAIN-KEYWORD | 도메인에 포함된 키워드입니다. | 일치 범위가 넓을 수 있으므로 너무 짧거나 의미가 모호한 단어는 피하세요. |
IP-CIDR / IP-CIDR6 | IPv4 / IPv6 주소 범위입니다. | 도메인 확인 결과와 DNS 조회 시점이 주소 기반 규칙의 판정에 영향을 줍니다. |
GEOIP | 주소 데이터베이스에 등록된 지역 정보입니다. | 데이터베이스상의 지역 정보가 서비스 콘텐츠의 위치와 같지는 않으며, 엣지 주소는 바뀔 수 있습니다. |
USER-AGENT | 확인 가능한 User-Agent 정보입니다. | 트래픽 종류와 노출된 정보에 따라 달라지므로 일반적인 앱 식별 수단으로 사용할 수 없습니다. |
FINAL | 앞선 규칙과 일치하지 않은 요청입니다. | 일반적으로 규칙 목록 맨 아래에 두어 마지막 처리 규칙으로 사용합니다. |
PROXY, DIRECT, REJECT의 의미
PROXY는 프록시 정책을, DIRECT는 직접 연결을, REJECT는 요청 거부를 뜻합니다. 이는 처리 방식이지 도메인이나 서버 프로토콜이 아닙니다. 아래 예시는 순서와 작성법을 설명하기 위한 것으로, 예시 도메인은 실제 서비스 주소가 아닙니다. 복사하기 전에 각 행의 대상과 범위를 확인하세요.
[Rule]
DOMAIN,ads.example.net,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY정확한 예외 규칙은 더 넓은 범위의 규칙보다 앞에 두는 것이 좋습니다. 도메인이 앞선 DOMAIN-SUFFIX와 이미 일치하면 뒤에 있는 DOMAIN 규칙은 적용되지 않을 수 있습니다. 수정한 뒤에는 실제 요청 기록에서 어떤 규칙이 적용됐는지 확인하세요. 웹페이지가 열리는지만으로 설정 전체가 올바르다고 판단하면 안 됩니다. 원격 Config를 업데이트하면 로컬 수정 내용이 덮어써질 수도 있으므로, 장기적으로 관리할 때는 직접 추가한 규칙과 원격 파일의 범위를 구분하세요.
03 / SERVER
Subscribe 및 Add Server: 구독과 서버 관리
서버 항목에는 연결에 필요한 매개변수가 저장되고, 구독을 이용하면 여러 항목을 한꺼번에 가져오고 업데이트할 수 있습니다. 둘 다 Config 규칙 파일과는 다릅니다. Home의 서버 목록에서 연결할 대상을 선택할 수 있습니다. Add Server에서 서버 하나를 직접 추가하거나 앱에 표시되는 Subscribe 메뉴로 기존 구독을 가져올 수 있습니다. 메뉴 위치는 화면 구성에 따라 달라질 수 있으므로 실제 표시된 이름을 기준으로 찾으세요.
구독 링크와 개별 연결 정보를 구분하세요
서비스 제공업체에서 구독 링크를 받은 뒤 해당 Subscribe 또는 URL 입력란에 전체 주소를 붙여 넣고 저장 및 업데이트를 실행하세요. 이후 예상한 서버 항목이 생성됐는지 확인합니다. 개별 서버 매개변수를 받은 경우에는 Add Server에서 해당 Type을 선택하고 주소, 포트, 인증 정보를 입력하세요. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 필요한 항목이 서로 다르므로 프로토콜 이름만 바꾸고 이전 프로토콜의 매개변수를 그대로 사용하면 안 됩니다.
TLS, SNI, 전송 방식 등의 항목은 서버 측 요구사항과 일치해야 합니다. WireGuard의 Address, Endpoint, 키 항목도 각각 용도가 다릅니다. 근거가 없는 항목은 기존 값을 유지하고 임의로 채우지 마세요. 전체 가져오기 과정은 첫 연결 가이드를, WireGuard 항목의 의미는 WireGuard 매개변수 안내를 참고하세요.
업데이트한다고 모든 설정이 바뀌는 것은 아닙니다
구독 업데이트는 일반적으로 구독이 관리하는 서버 목록을 새로 고칩니다. 현재 Config를 업데이트하거나 Global Routing을 전환하거나 최적의 서버를 선택해 주는 기능으로 간주하면 안 됩니다. 업데이트 후에는 항목 이름, 현재 선택된 서버, 테스트 결과를 확인하세요. 구독으로 관리되는 항목은 다음 업데이트 때 다시 생성될 수 있으므로 직접 수정한 내용은 먼저 백업하세요. 구독을 삭제하기 전에는 그 구독에 포함된 서버 기록을 계속 사용할지 확인합니다.
04 / ON DEMAND
On Demand: 네트워크 조건에 따른 연결
On Demand는 설정된 네트워크 조건에 따라 VPN 연결을 시작하는 기능입니다. ‘언제 연결을 시도할지’를 정하며 ‘요청을 어떤 정책으로 처리할지’를 결정하지는 않습니다. 앱의 On Demand 화면에서 조건과 동작을 확인하세요. 트래픽 분기는 Global Routing과 현재 Config가 제어합니다.
설정하기 전에 수동 연결이 정상적으로 작동하는지 확인한 다음 조건을 하나씩 추가하세요. 예를 들어 Wi-Fi 환경에 따라 다르게 처리하려면 조건에 설정된 네트워크 이름, 일치 범위, 해당 동작을 점검하고 조건에 맞는 네트워크와 맞지 않는 네트워크에서 각각 확인합니다. 조건 이름이 올바르게 보여도 현재 네트워크가 실제로 조건을 충족한다는 뜻은 아닙니다. 처음부터 의미가 비슷한 조건을 여러 개 추가하지 마세요.
기능을 켜면 조건이 충족될 때 시스템이 다시 연결을 시작할 수 있으므로, 수동으로 연결을 끊은 뒤 다시 연결되더라도 반드시 이상 동작은 아닙니다. 완전히 비활성화해 테스트하려면 On Demand가 계속 켜져 있는지 먼저 확인한 다음 시스템 VPN 상태를 살펴보세요. 네트워크 전환, 시스템 스케줄링, 기기 권한에 따라 작동 시점이 달라질 수 있으며, 네트워크가 바뀔 때마다 즉시 연결된다고 보장되지는 않습니다. 기기에 다른 VPN 설정이 있다면 현재 실제로 사용 중인 항목도 확인하세요.
05 / DATA
Data: 트래픽 통계와 요청 단서
Data에서는 앱에 기록된 트래픽 통계를 확인해 문제 해결의 단서를 얻을 수 있습니다. Data를 열고 먼저 현재 페이지의 통계 대상, 시간 범위, 단위를 확인한 뒤 업로드와 다운로드 변화를 비교하세요. 페이지마다 연결 중 통계나 다른 범위의 데이터를 표시할 수 있으므로, 특정 수치를 요금 청구량이나 특정 앱의 전체 트래픽으로 해석하면 안 됩니다.
특정 요청을 확인하려면 먼저 Data의 수치를 기록하고 해당 작업만 한 번 실행한 뒤 돌아와 변화를 살펴보세요. 수치가 바뀌지 않았다면 연결 상태, Global Routing, 요청이 클라이언트의 처리 범위에 포함되는지 계속 확인합니다. 수치가 증가했는데도 로딩에 실패했다면 서버가 정상이라고 단정할 수 없습니다. DNS 조회, 연결, 응답 단계도 함께 점검하세요.
클라이언트의 집계에는 연결 오버헤드가 포함될 수 있으며, 서비스 제공업체가 계정, 기간, 과금 방향에 따라 집계하는 방식과 다를 수도 있습니다. 따라서 Data는 서비스 제공업체의 사용량 기록을 대신하지 않습니다. 통계를 지우거나 초기화하기 전에 확인 메시지를 읽고 문제 해결에 필요한 데이터는 먼저 보관하세요. 트래픽 양과 요청 성공률은 서로 다른 지표이므로 수치가 증가했다고 페이지 콘텐츠가 모두 로드된 것은 아닙니다.
06 / SETTINGS
자주 쓰는 Settings: DNS, 테스트, 동기화
Settings의 각 옵션은 적용 범위가 다르며, 일부는 현재 Config와 함께 최종 동작을 결정합니다. 아래에서는 용도별로 설명하며 특정 값을 모든 네트워크에 적용할 고정 권장값으로 제시하지 않습니다. 기본값, 선택지, 메뉴 위치는 앱에 표시되는 내용을 기준으로 확인하세요. 변경 전에는 기존 값을 기록하고 한 번에 한 가지 요소만 바꾸세요.
DNS: 먼저 DNS 조회 경로 확인
DNS는 도메인을 IP 주소로 변환합니다. 조회에 실패하면 연결 시간 초과가 발생하거나 주소 기반 규칙이 예상대로 적용되지 않을 수 있습니다. Settings에서 확인할 수 있는 DNS 항목을 살펴보고 현재 Config에 DNS 설정이 포함되어 있는지도 확인하세요. Settings의 한 항목을 바꾸면 설정 파일의 모든 동작이 반드시 바뀐다고 가정하지 마세요.
설정하기 전에 목적을 명확히 하세요. DNS 조회 시간 초과를 해결하려는 것인지, 주소 결과를 확인하려는 것인지, DNS 요청의 경로를 바꾸려는 것인지 구분해야 합니다. 서비스 제공업체가 관련 설정을 안내했다면 그에 따르세요. 안내가 없다면 현재 작동하는 설정을 유지한 채 하나씩 테스트합니다. 암호화 DNS는 DNS 요청의 전송 방식에 관한 설정이며 모든 앱 트래픽의 라우팅을 자동으로 바꾸지는 않습니다. 웹페이지에 문제가 있을 때는 ‘도메인이 조회되지 않음’과 ‘주소는 확인됐지만 연결에 실패함’을 구분해 DNS를 반복해서 바꾸며 실제 문제를 가리지 않도록 하세요.
Test Method: 같은 기준으로 테스트 결과 비교
Test Method에서 연결 테스트 방식을 선택할 수 있습니다. Settings에서 방식을 확인한 뒤 Home의 Connectivity Test로 등록된 서버를 점검하세요. 방식에 따라 확인하는 단계가 다릅니다. 일부는 전송 계층 연결 여부를 주로 확인하고, 일부는 테스트 대상의 응답도 필요합니다. 사용할 수 있는 방식과 테스트 대상은 현재 버전에 표시되는 항목을 기준으로 확인하세요.
서버를 비교할 때는 테스트 방식, 테스트 대상, 로컬 네트워크를 동일하게 유지하세요. 지연 시간이 짧다고 처리량이 높거나 장시간 연결이 안정적이라는 뜻은 아닙니다. 시간 초과는 테스트 대상에 일시적으로 접근할 수 없어서 발생할 수도 있습니다. 먼저 소수의 항목을 테스트한 다음 실제로 필요한 서비스에서 확인하고, 한 번의 결과를 영구적인 순위로 간주하지 마세요.
Today Widget: 빠른 조작으로 기본 화면 확인을 대신할 수는 없습니다
Today Widget에서는 시스템이 허용하는 범위에서 정보를 빠르게 보거나 기능을 조작할 수 있습니다. 먼저 Settings에서 관련 옵션을 확인한 뒤 시스템의 위젯 편집 화면에서 사용 가능한 위젯을 추가하세요. 위젯의 모양과 사용할 수 있는 기능은 시스템 버전 및 앱 지원 여부에 따라 달라지므로 다른 기기의 화면 구성을 그대로 적용하지 마세요.
위젯에서 조작한 뒤 Home으로 돌아가 현재 서버, 연결 상태, Global Routing을 확인하세요. 위젯 표시 내용은 새로 고침 시점에 따라 달라질 수 있습니다. 즉시 바뀌지 않으면 스위치를 연달아 누르지 말고 기본 화면과 시스템 VPN 상태를 먼저 확인하세요. 자동 연결을 일시 중지하려면 On Demand도 함께 확인해야 합니다.
iCloud 동기화: 동기화 전에 로컬 사본 보관
iCloud 동기화는 지원되는 기기 사이에서 앱이 동기화하도록 허용한 데이터를 전송합니다. 먼저 기기가 사용할 Apple 계정으로 로그인되어 있는지, 앱에 iCloud 사용이 허용되어 있는지 확인한 다음 Settings에서 동기화 옵션을 살펴보세요. 어떤 항목이 동기화되는지, 언제 동기화가 시작되는지는 앱 내 안내를 기준으로 확인해야 합니다. 서버, Config, 통계, 모든 스위치가 빠짐없이 복사된다고 가정하지 마세요.
처음 동기화를 켜거나 기기를 바꾸기 전에 보관할 Config를 백업하세요. 두 기기에서 각각 수정한 경우에는 반복해서 동시에 저장하지 말고, 어느 쪽 내용을 기준으로 삼을지 먼저 정한 다음 다른 기기의 상태를 확인합니다. 동기화가 완료되어도 연결이 설정된 것은 아닙니다. 새 기기에서는 현재 Config, 서버 선택, 시스템 VPN 승인을 다시 확인해야 합니다. 앱 구매 기록과 설정 데이터는 별개이므로 구매한 앱을 복원해도 로컬 설정 전체가 복원되는 것은 아닙니다.
Diagnostics: 문제 발생 단계별 단서 확인
Diagnostics는 DNS 조회, 연결, 요청 처리 등의 단계를 점검하는 데 도움이 됩니다. Settings에서 Diagnostics 또는 해당 진단 메뉴를 찾아 점검할 대상을 정한 다음 문제와 관련된 항목을 실행하세요. 구체적인 항목 이름은 현재 화면을 기준으로 확인합니다. 진단 도구에서 성공으로 표시되더라도 해당 도구가 확인한 단계만 정상이라는 뜻이며 모든 요청이 성공한다는 의미는 아닙니다.
문제가 발생한 당시의 네트워크 유형, Global Routing, 선택한 서버, 오류 메시지를 기록한 뒤 확인할 수 있는 Log 정보와 함께 실패 단계를 살펴보세요. 더 자세한 기록이 필요하면 잠시 켜고 문제를 한 번 재현한 뒤 평소 사용에 적합한 기록 수준으로 되돌립니다. 로그에는 도메인, 주소, 연결 매개변수가 포함될 수 있으므로 외부에 공유하기 전에 민감한 정보를 가리세요. Config 전체를 문제 해결용 스크린샷으로 보내지 마세요.
07 / CHECK
설정 변경 후 점검 순서
한 번의 문제 해결 과정에서 규칙, 서버, DNS, 테스트 방식을 동시에 변경하면 결과를 비교하기 어렵습니다. 아래 순서대로 확인하고 각 단계가 끝날 때마다 결과를 기록하세요. 새 설정으로 개선되지 않았다면 기존 값으로 되돌린 뒤 다음 항목을 점검합니다.
- 기본 연결을 확인합니다. Home의 연결 상태와 시스템 VPN 승인을 확인하고, 선택한 서버가 기존 구독에 포함되거나 직접 설정한 유효한 항목인지 점검합니다.
- Global Routing을 확인합니다. Config, Proxy, Direct를 짧게 비교해 규칙 문제와 연결 경로 문제를 구분한 다음 원래 모드로 되돌립니다.
- 현재 Config를 확인합니다. 적용 중인 파일, 규칙 순서, 정책 그룹 선택, FINAL을 점검해 사용하지 않는 파일을 수정하지 않았는지 확인합니다.
- DNS와 테스트 기준을 확인합니다. DNS 결과를 점검하고 Test Method와 테스트 대상을 동일하게 유지한 뒤 Connectivity Test 결과와 실제 요청을 확인합니다.
- 자동 연결과 동기화를 확인합니다. On Demand가 연결을 다시 시작했는지, iCloud를 통해 다른 기기의 변경 사항이 적용됐는지 확인한 다음 Data와 Diagnostics를 다시 살펴봅니다.
각 설정의 적용 범위를 확인하려면 Settings 항목 안내를 참고하세요. 특정 서버에 연결되지 않는 문제라면 서버 연결 시간 초과 점검 순서에 따라 프로토콜 매개변수와 시스템 시간을 확인할 수 있습니다. 설정 파일 전체를 자주 바꾸기보다 재현 가능한 단계별 테스트를 유지하면 원인을 더 쉽게 찾을 수 있습니다.