먼저 요청에 적용할 라우팅 방식을 정한 다음 규칙, 연결 조건, 진단 옵션을 조정하세요. 설정이 적절한지는 기존 서버, 현재 네트워크, 실제 접속 결과를 함께 확인해야 합니다.
아래 내용은 기능 설명이며 앱 화면이 아닙니다. 항목을 선택해 용도를 확인하고, 구체적인 사용법과 주의사항은 다음 장을 참고하세요.
규칙은 요청의 도메인이나 대상 주소를 설정에 있는 조건과 차례로 비교한 뒤 해당 정책에 따라 처리합니다. Config에서 규칙을 관리하고, 적용하려면 Home의 Global Routing을 Config로 설정해야 합니다. 먼저 현재 활성화된 구성을 확인한 뒤 규칙을 수정하세요. 활성화되지 않은 파일을 변경해도 연결 결과는 달라지지 않습니다. 문제를 확인할 때는 요청 기록에서 어떤 규칙이 적용됐는지 살펴보세요. 서버 응답 속도만으로 규칙 적용 여부를 판단하지 마세요.
DOMAIN-SUFFIX,example.com,PROXYOn Demand는 네트워크 환경이나 지정한 조건에 따라 연결 동작을 시작하는 기능입니다. 개별 요청의 처리 정책을 선택하는 기능은 아닙니다. On Demand에서 자동 연결이 필요한 상황을 정한 다음 Wi-Fi, 셀룰러 네트워크, 도메인 조건을 하나씩 확인하세요. 조건은 한 번에 하나씩 추가하고 해당 네트워크에서 동작을 확인하는 것이 좋습니다. 수동으로 연결을 끊었는데 다시 연결된다면 서버를 반복해서 삭제하거나 구성을 새로 만들기보다, 여전히 충족되는 조건이 있는지 먼저 확인하세요.
연결 시작 조건은 On Demand, 요청 처리 방식은 Global Routing과 규칙에서 정합니다.
다양한 프로토콜을 사용하면 Shadowsocks, VMess, VLESS, Trojan, WireGuard, Hysteria2 등 여러 유형의 기존 서버에 연결할 수 있습니다. 일반적으로 Home의 Add Server에서 서버 정보를 확인해 해당 유형을 선택하고 필요한 항목을 입력합니다. 프로토콜 이름이 비슷해도 입력 항목을 서로 바꿔 쓸 수 있는 것은 아닙니다. 포트, 인증 정보, 전송 설정을 하나씩 확인하세요. 기존 공유 정보를 가져올 수 있지만, 가져온 뒤에도 이름만 확인하지 말고 주요 항목을 점검해야 합니다.
기존 서비스 정보를 기준으로 유형을 선택하세요. 프로토콜 이름만으로 실제 속도를 판단할 수는 없습니다.
Subscribe는 사용자가 이미 보유한 구독 주소를 저장하고 해당 주소에서 서버 항목을 가져오는 기능입니다. Config의 규칙 설정과는 용도가 다릅니다. Subscribe는 선택할 서버를 관리하고 Config는 요청 처리 방식을 정합니다. 추가하기 전에 입력한 주소가 구독 주소인지 계정 로그인 페이지인지 확인하세요. 업데이트 후에는 항목 변경 사항과 현재 선택된 서버를 확인하고, 직접 수정한 내용이 다음 업데이트에서 덮어써지지 않는지도 살펴보세요. 구독 주소에는 접속 정보가 포함될 수 있으므로 스크린샷이나 공개 게시물에 올리지 마세요.
구독을 가져왔다는 것은 서버 항목을 불러왔다는 뜻일 뿐입니다. 연결은 별도로 확인해야 합니다.
Connectivity Test, Data, Diagnostics는 서로 다른 관점의 정보를 제공합니다. 테스트는 선택한 방식에 따른 연결 가능성을 살펴보고, 통계는 트래픽 변화를 확인하며, 진단은 문제 해결에 필요한 단서를 기록합니다. 서로 대체할 수 있는 기능은 아닙니다. 먼저 오류가 발생한 시간과 네트워크를 기록하고 요청을 다시 재현한 뒤 DNS 해석, 규칙 적용 여부, 연결 오류를 확인하세요. 한 번에 한 가지 설정만 변경하고 다시 테스트해야 서버, DNS, 구성을 동시에 바꿔 원인을 파악하지 못하는 상황을 피할 수 있습니다.
테스트에 성공해도 모든 웹사이트에 접속할 수 있다는 뜻은 아닙니다. 실제 요청과 오류 기록을 함께 확인하세요.
Global Routing은 전체 라우팅 방식을 설정합니다. 도메인이나 주소별로 요청을 나누려면 Config를 사용하세요. 프록시 경로를 점검할 때는 Proxy, 직접 연결 결과를 확인할 때는 Direct로 잠시 전환할 수 있습니다. 세 가지는 속도 설정이 아닙니다.
| 모드와 화면 표시 | 처리 방식 | 주요 용도 | 확인할 항목 |
|---|---|---|---|
| 구성 · Config | 현재 활성화된 구성의 규칙과 정책에 따라 요청을 처리합니다. | 일상적인 트래픽 분기, 사용자 규칙 확인 | 구성이 활성화됐는지, 규칙 순서와 정책 대상이 올바른지 확인합니다. |
| 프록시 · Proxy | 트래픽을 전반적으로 프록시 방식으로 처리합니다. 단, 시스템과 앱의 처리 범위에 따라 달라질 수 있습니다. | 현재 서버를 통한 프록시 연결 경로를 임시로 확인합니다. | 선택한 서버가 유효한지 확인하고 테스트 후 평소 모드로 되돌립니다. |
| 직접 연결 · Direct | 트래픽을 전반적으로 직접 연결 방식으로 처리합니다. | 로컬 네트워크 또는 직접 접속 결과를 확인합니다. | Direct는 시스템의 VPN 연결을 끄는 것과 다릅니다. |
Home에서 Global Routing을 열고 원하는 모드를 선택한 뒤 돌아와 현재 표시된 값을 확인하세요. Config를 사용한다면 Config에서 활성화 표시를 확인하고, Proxy를 사용한다면 현재 선택된 서버를 점검하세요. 그런 다음 대상에 다시 요청을 보내세요. 이미 연결된 요청은 새 설정으로 바로 재연결되지 않을 수 있으므로 필요하면 기존 연결을 종료한 뒤 테스트하세요.
Config에서만 문제가 생기고 Proxy에서는 같은 대상에 접속된다면 규칙 적용 여부, 정책 그룹 선택, DNS 경로를 먼저 확인하세요. 이는 문제 범위를 좁히는 방법이지 원인을 확정하는 기준은 아닙니다. 두 모드에서 모두 실패한다면 서버 정보, 인증 상태, 현재 네트워크도 점검해야 합니다.
규칙은 어떤 요청을 어떤 방식으로 처리할지 정합니다. Config에서 현재 구성을 열고 규칙 편집 메뉴로 이동한 다음, 예외를 추가하기 전에 기존 규칙을 먼저 확인하세요. 규칙은 일반적으로 위에서 아래로 검사하며 조건에 맞으면 해당 정책을 적용합니다. 구체적인 조건은 범위가 넓은 조건보다 위에 배치하고, 어느 규칙에도 해당하지 않는 요청에 적용할 FINAL은 마지막에 둡니다.
DOMAIN: 지정한 도메인과 일치시킵니다. 완전한 호스트 이름 하나에만 적용할 때 적합합니다.DOMAIN-SUFFIX: 지정한 도메인과 하위 도메인을 매칭합니다. 도메인 범위별로 요청을 관리할 때 적합합니다.DOMAIN-KEYWORD: 도메인에 포함된 키워드로 매칭합니다. 범위가 넓으므로 추가하기 전에 원치 않는 매칭이 발생할지 확인하세요.IP-CIDR 및 IP-CIDR6: IPv4 또는 IPv6 주소 대역을 기준으로 매칭합니다. DNS 해석이 필요한지, 대상이 동적 주소를 사용하는지 확인하세요.GEOIP: IP 주소의 지리 정보 데이터베이스를 기준으로 매칭합니다. 데이터베이스 결과만으로 서비스의 실제 위치나 용도를 판단해서는 안 됩니다.USER-AGENT: 요청에서 확인할 수 있는 정보에 의존합니다. 모든 앱을 정확하게 식별하는 방법은 아닙니다.DIRECT는 직접 연결, REJECT는 일치하는 요청 거부, PROXY는 프록시 처리를 뜻합니다. 실제 연결 대상은 구성에서 확인하세요. 규칙의 대문자 정책과 Global Routing의 Config / Proxy / Direct는 서로 다른 단계의 설정입니다. 사용자 지정 정책 그룹이 있을 수 있으므로 참조하는 이름이 구성과 일치하는지 확인해야 합니다.
DOMAIN,example.com,DIRECT
DOMAIN-SUFFIX,example.net,PROXY
FINAL,PROXY위 내용은 규칙 문법 예시이며 기존 구성을 그대로 덮어쓸 수 있는 완성 파일이 아닙니다. 수정 전에 원래 구성을 보관하고, 변경 후 해당 파일이 계속 활성화돼 있는지 확인한 다음 요청 기록에서 실제로 적용된 규칙을 살펴보세요. 모든 문제를 범위가 넓은 키워드 규칙으로 처리하면 어떤 도메인의 처리 방식이 함께 바뀌었는지 추적하기 어려워집니다.
서버 항목에는 원격 서버에 연결하는 데 필요한 정보가 저장됩니다. 이름은 항목을 구분하기 위한 표시일 뿐 프로토콜 유형을 결정하지 않습니다. 사용자가 이미 보유한 서버 정보를 기준으로 Home에서 Add Server를 열고 프로토콜을 선택한 뒤 주소, 포트, 인증 정보를 입력하세요. 프로토콜마다 항목의 의미가 다르므로 Shadowsocks 비밀번호를 다른 인증 정보가 필요한 항목에 그대로 입력하지 마세요.
Scan QR Code로 기존 정보를 가져올 때 카메라 접근은 QR 코드 스캔에 사용됩니다. 가져온 뒤에는 항목을 열어 유형과 주소를 확인하세요. QR 코드에 개별 서버 정보가 들어 있을 수도 있고 구독 주소가 포함될 수도 있으므로 겉모양만으로 내용을 판단하지 마세요. 클립보드에서 가져올 때도 앞뒤 설명 문구까지 함께 복사하지 않았는지 확인해야 합니다.
먼저 기존 설정을 기록하거나 별도의 항목을 남겨 둔 다음 확인할 항목을 수정하세요. TLS, 서버 이름, 전송 설정은 기존 서비스 정보와 일치해야 합니다. 연결이 실패해도 포트를 계속 추측하거나 검증 조건을 낮추는 방식으로 해결하려 하지 마세요. HTTP, SOCKS5, WireGuard, Hysteria2 등은 실제 항목 안내에 따라 설정해야 하며 한 프로토콜의 설정 방식을 다른 프로토콜에 그대로 적용해서는 안 됩니다.
저장한 뒤 Home에서 해당 서버를 선택하고 Connectivity Test를 실행한 다음 실제 접속도 확인하세요. 목록에 항목이 표시되는 것은 저장에 성공했다는 뜻일 뿐입니다. 테스트 결과, 원격 서버 연결, 실제 서비스 접속은 각각 별도로 확인해야 합니다. 항목을 삭제하기 전에는 정책 그룹이나 현재 구성에서 사용 중인지도 확인하세요.
Subscribe는 서버 목록을 한곳에서 가져오고 업데이트하는 기능이며 규칙 구성과는 다릅니다. 사용자가 보유한 구독 주소를 해당 메뉴에 입력해 저장한 뒤 업데이트하고, 필요한 항목이 표시되는지 확인하세요. 주소는 본인이 사용하는 서비스 정보에서 확인해야 합니다. 웹 관리 페이지, 결제 페이지, 구독 주소는 용도가 다르므로 서로 대신 사용할 수 없습니다.
구독을 업데이트하면 구독으로 관리되는 항목이 덮어써질 수 있습니다. 특정 설정을 별도로 유지해야 한다면 업데이트 동작을 먼저 확인한 다음 수동 항목을 따로 둘지 결정하세요. 원래 주소를 잃어버린 뒤 전체 그룹을 삭제하지 않도록 주의하세요. 정리하기 전에 다시 가져올 수 있는지 확인하고 필요한 정보를 안전하게 보관하세요.
앱을 한 번 구매해 사용하는 것과 네트워크 서비스 요금제는 별개입니다. Shadowrocket 구매와 기존 서비스의 이용 자격은 각각 관리됩니다. 이 사이트는 노드나 구독을 제공하거나 판매, 추천하지 않으며 사용자가 이미 보유한 정보를 활용하는 방법만 안내합니다.
구독 주소에는 인증 정보가 포함되는 경우가 많습니다. 문제 화면을 공유할 때 전체 주소와 인증 항목을 가리고 링크를 공개 문서에 올리지 마세요. 가져오기에 실패하면 클라이언트 설정을 바꾸기 전에 주소가 유효한지, 현재 네트워크에서 접속할 수 있는지, 올바른 콘텐츠가 반환되는지 확인하세요.
On Demand는 자동 연결 동작의 조건을 설정하는 기능이며 규칙에 따른 트래픽 분기와는 다릅니다. 앱에서 On Demand를 열고 현재 화면에 표시되는 조건과 동작을 확인한 다음 네트워크 환경에 맞게 설정하세요. 구체적인 메뉴 위치와 선택 항목은 현재 앱 화면의 안내를 따르세요. 다른 기기의 메뉴 위치만 보고 찾지 마세요.
Wi-Fi별로 동작을 나누려면 SSID 철자와 적용할 동작을 확인하세요. 셀룰러 네트워크에서도 적용하려면 해당 조건을 별도로 점검해야 합니다. Wi-Fi 조건이 다른 모든 네트워크에도 자동으로 적용되는 것은 아닙니다. 도메인 조건을 사용할 때는 연결 시작 조건과 규칙 파일의 도메인 정책이 각각 연결 트리거와 요청 처리에 적용된다는 점을 확인하세요.
먼저 쉽게 확인할 수 있는 조건 하나만 남기고 대상 네트워크에 연결해 시스템의 VPN 상태를 확인한 다음, 해당 네트워크에서 벗어나 다시 테스트하세요. 조건이 여러 개라면 화면에 표시되는 순서와 실제 동작을 살펴보고 서로 겹치는지 확인하세요. 조건 하나는 연결을 요구하고 다른 조건은 다른 동작을 요구하는 상황도 피해야 합니다. 조건을 모두 한꺼번에 작성하기보다 하나를 추가할 때마다 양방향으로 테스트해야 문제를 찾기 쉽습니다.
수동으로 연결을 끊은 뒤 시스템이 다시 연결한다면 On Demand를 잠시 비활성화하고 다시 테스트해 조건이 원인인지 확인하세요. 평소 연결을 완전히 끊어 두려면 앱 연결 상태와 On Demand 설정을 모두 점검해야 합니다. 사용 전에 시스템에서 요구하는 VPN 구성 권한도 승인해야 합니다. 연결 권한을 승인했다고 해서 사용할 수 있는 서버가 생기는 것은 아닙니다.
Data에서는 앱이 집계한 트래픽 정보를 확인할 수 있습니다. Data를 열고 현재 화면의 집계 범위, 방향, 기간을 확인한 다음 특정 접속 전후의 변화를 살펴보세요. 업로드와 다운로드는 데이터 전송 방향을 나타냅니다. 웹페이지가 완전히 열렸는지를 보여주는 것은 아니며, 숫자 하나만 보고 규칙이나 서버 문제를 판단할 수도 없습니다.
문제를 확인할 때는 눈에 띄는 다른 네트워크 활동을 잠시 멈추고 테스트 전 표시 값을 기록한 다음, 알고 있는 대상에 접속해 비교해 보세요. 통계가 변했는데 페이지가 열리지 않는다면 DNS 해석, 핸드셰이크, 앱 수준 오류를 추가로 확인해야 합니다. 변화가 거의 없다면 연결 상태, 라우팅 방식, 요청이 예상한 처리 경로로 전달됐는지 점검하세요.
앱, 시스템, 기존 서비스의 집계 범위는 서로 다를 수 있습니다. 연결 오버헤드, 집계 기간, 과금 기준도 다를 수 있습니다. Data는 사용 추세를 살펴보고 문제를 진단하는 보조 수단이지 서비스의 잔여 데이터나 사용 내역을 대신하지 않습니다. 비교가 필요하다면 두 항목의 기간과 단위를 먼저 맞추세요. 서로 다른 총계를 그대로 빼서는 안 됩니다.
현재 화면에서 통계 초기화를 지원한다면 문제 해결 기록을 보관해야 하는지 먼저 확인한 다음 초기화하세요. 표시 기록을 초기화해도 이미 발생한 서비스 사용량은 바뀌지 않습니다. 기기를 바꾸거나 앱을 다시 설치한 뒤 이전 통계가 모두 복원된다고 가정하지 마세요.
먼저 정상 작동하는 기본 상태를 유지하고 설정을 하나씩 변경하세요. 일부 설정은 현재 Config에서 관리할 수 있으므로 앱 설정과 함께 구성 파일에 관련 항목이 있는지도 확인해야 합니다. 아래 내용은 용도별 안내이며 모든 옵션을 바꿀 필요는 없습니다.
DNS는 도메인을 주소로 변환합니다. Settings와 현재 Config에서 관련 설정을 확인하고 어떤 DNS를 사용하는지, 다른 설정이 덮어쓰는지 살펴보세요. 웹페이지가 열리지 않지만 Connectivity Test는 정상이라면 대상 도메인이 올바르게 해석되는지 먼저 확인할 수 있습니다.
변경 전에 기존 값을 기록하고 관련 옵션을 한 번에 하나씩만 바꾼 뒤 새 요청으로 확인하세요. 용도가 불분명한 DNS 설정을 여러 개 함께 적용하지 마세요. 도메인 해석에 성공해도 이후 연결까지 성공한다는 뜻은 아닙니다.
Settings에서 Test Method를 확인하고 선택된 방식이 연결의 어느 구간을 검사하는지 살펴보세요. 테스트 방식에 따라 사용하는 요청과 대상이 다를 수 있으므로 같은 서버의 결과라도 직접 비교할 수 없는 경우가 있습니다.
기존 서버를 비교할 때는 가능한 한 같은 네트워크와 테스트 방식으로 비슷한 시간대에 확인하세요. 테스트가 정상이어도 실제 대상에 접속해 봐야 합니다. 테스트에 실패했다면 오류 유형도 확인하세요. 결과만으로 모든 서비스에 접속할 수 없다고 단정하지 마세요.
Today Widget은 시스템에서 지원하는 빠른 확인이나 조작에 사용할 수 있습니다. 먼저 앱에서 관련 설정을 살펴본 뒤 시스템의 위젯 관리 화면에서 추가하세요. 사용 가능한 형태와 기능은 현재 시스템 및 앱 화면의 안내를 따릅니다.
표시 상태가 예상과 다르면 Home으로 돌아가 실제 연결 상태를 확인한 다음 On Demand를 점검하세요. 위젯은 빠른 실행을 위한 기능이며 서버 설정, 시스템 권한 승인, 전체 연결 확인을 대신하지 않습니다.
Settings에서 iCloud 관련 옵션을 확인하고 시스템에서 해당 iCloud 권한도 살펴보세요. 현재 화면의 안내에 따라 동기화 범위를 확인하세요. 서버, 구성, 통계, 시스템 권한이 모두 함께 동기화된다고 가정하지 마세요.
처음 활성화하거나 기기를 바꾸기 전에 중요한 구성을 따로 보관하세요. 여러 기기의 내용이 일치하지 않으면 동시에 편집하지 말고 먼저 작업을 멈추세요. 앱 구매 기록과 구성 동기화는 서로 다른 절차이며, 시스템 VPN 권한은 각 기기에서 따로 확인해야 합니다.
Diagnostics는 문제를 파악하는 데 필요한 단서를 확인하는 기능으로, 보통 Settings의 관련 메뉴에서 이용할 수 있습니다. 문제가 발생한 네트워크, 선택한 서버, Global Routing 모드, 대상 정보를 기록한 뒤 현재 화면의 안내에 따라 필요한 진단을 시작하세요. 모든 문제를 장시간 기록할 필요는 없습니다. 재현 가능한 요청 하나를 중심으로 정보를 수집하면 내용을 확인하기 쉽습니다.
문제 해결이 끝나면 필요에 따라 추가 기록을 중지하고 문제를 설명하는 데 필요한 최소한의 내용만 보관하세요. 외부에 내용을 전달하기 전에 서버 주소, 인증 정보, 구독 주소, 방문 도메인을 확인하고 민감한 부분을 삭제하세요. 그다음 재현 방법과 이미 시도한 변경 사항을 설명하세요.
현재 활성화된 구성, 대상에 적용된 규칙, 정책 그룹의 대상을 확인한 뒤 DNS도 점검하세요. 두 모드의 처리 경로가 다를 수 있으므로 이 현상만으로 서버 문제라고 단정할 수는 없습니다. 이전 연결의 영향을 피하려면 설정을 변경한 뒤 새 요청을 시작하세요.
테스트 결과는 선택한 Test Method에서의 상태만 보여줍니다. 실제 대상의 도메인 해석, 규칙 적용, TLS 연결, 접속 결과를 확인하고 현재 선택된 서버가 방금 테스트한 항목과 같은지도 살펴보세요.
현재 구성을 먼저 보관한 다음 정상 작동을 확인한 기본 구성으로 돌아가고, On Demand 조건을 잠시 단순화하세요. 기존 서버 하나와 테스트 대상 하나를 정한 뒤 한 번에 하나씩 설정을 복원하세요. 백업 없이 모든 내용을 한꺼번에 지우지 마세요.
전체 설정 순서는 시작 가이드에서 확인할 수 있습니다. 첫 실행, 구성 관리, 일상적인 유지 관리를 차례로 살펴보려면 초보자부터 고급 사용자까지 보는 공식 매뉴얼을 참고하세요.