공식 매뉴얼 · 기능 및 설정
Global Routing부터 Diagnostics까지 ‘기능 이해 → 화면 위치 → 설정 방법 → 결과 확인’ 순서로 점검합니다. 먼저 현재 모드와 구성을 확인한 뒤 필요한 항목만 조정하세요. 여러 설정을 한꺼번에 바꾸면 원인을 찾기 어렵습니다.
이 페이지는 주로 iPhone과 iPad에서의 사용 방법을 다룹니다. 메뉴 위치와 사용할 수 있는 옵션은 현재 앱 화면을 기준으로 확인하세요. 시스템 요구 사항은 App Store 페이지에 표시된 내용을 기준으로 합니다. 처음 설정한다면 먼저 시작하기를 읽고 이 페이지에서 각 항목을 확인하세요.
Global Routing은 연결을 처리하는 전체 방식을 정합니다. 보통 Home에 있으며 Config, Proxy, Direct는 각각 구성, 프록시, 직접 연결 모드에 해당합니다. 서버 정보나 연결 스위치와는 다릅니다. 모드를 선택한 뒤에도 Home에서 선택된 서버와 현재 구성, 연결 상태를 확인해야 요청이 실제로 어떻게 처리되는지 판단할 수 있습니다.
도메인이나 주소에 따라 처리 방식을 나누려면 Config를 사용하세요. 규칙 매칭의 영향을 잠시 배제하고 비교하려면 Proxy를, 현재 네트워크에서 직접 접속이 되는지 확인하려면 Direct를 사용할 수 있습니다. 각 모드의 결과는 대상별로 확인해야 합니다. 한 페이지가 열린다고 모든 요청이 같은 경로로 처리된다고 단정할 수는 없습니다.
| 모드 및 화면 용어 | 주요 처리 방식 | 사용 사례 | 주의 사항 |
|---|---|---|---|
| 구성 / Config | 현재 활성화된 구성의 규칙과 정책에 따라 요청을 처리합니다. | 규칙에 따른 라우팅이 필요하거나 특정 도메인에 어떤 규칙이 적용되는지 확인할 때 사용합니다. | 구성이 활성화되어 있는지 확인하세요. 파일을 저장하는 것만으로 해당 구성이 적용되지는 않습니다. |
| 프록시 / Proxy | 일반 요청을 프록시 방식으로 처리합니다. 구체적인 동작은 관련 네트워크 설정의 영향을 받을 수 있습니다. | 서버 연결과 규칙 판정의 차이를 일시적으로 비교할 때 사용합니다. | 모든 시스템 트래픽이 같은 경로를 거치는 것은 아니며, 대상에 접속할 수 있다고 보장하지도 않습니다. |
| 직접 연결 / Direct | 현재 네트워크를 통해 대상에 직접 연결합니다. | 현재 Wi-Fi 또는 셀룰러 네트워크의 기본 접속 상태를 비교할 때 사용합니다. | 연결 스위치를 끄는 모드가 아닙니다. On Demand의 연결 동작은 별도로 확인해야 합니다. |
Home에서 Global Routing을 열고 원하는 모드를 선택한 다음, 돌아와 표시된 값을 확인합니다. 같은 대상을 새로 요청하고 확인 가능한 연결 기록을 살펴보세요. 기존에 연결된 장시간 연결에는 새 설정이 바로 반영되지 않을 수 있습니다. 필요하면 테스트 연결을 종료한 뒤 요청을 다시 시작하세요. 비교가 끝나면 원래 모드로 되돌리세요. 특히 임시로 사용한 Proxy나 Direct를 선택한 상태에서 규칙이 계속 적용된다고 오해하지 않도록 주의하세요.
규칙은 요청이 어떤 조건에 해당하는지 판정하고, 정책은 규칙에 일치한 요청의 처리 방법을 정합니다. Config에서 현재 활성화된 구성을 확인한 뒤 규칙의 순서를 살펴보세요. 일반적으로 위에서 아래 순서로 확인하며, 앞선 규칙에 이미 일치하면 뒤의 규칙은 다시 판정되지 않습니다. FINAL은 앞선 규칙에 일치하지 않은 요청을 처리합니다.
DOMAIN은 전체 도메인과 일치하고, DOMAIN-SUFFIX는 도메인 접미사와 일치하며, DOMAIN-KEYWORD는 도메인에 특정 키워드가 있는지 확인합니다. IP-CIDR과 IP-CIDR6은 각각 해당 주소 대역과 일치하고, GEOIP는 주소의 지역 정보를 기준으로 판정합니다. 규칙을 선택할 때는 대상이 도메인인지 IP 주소인지 먼저 확인하세요. 전체 URL을 도메인 규칙의 매칭 값으로 사용할 수는 없습니다.
DOMAIN-SUFFIX,example.com,PROXY
DIRECT는 직접 연결, PROXY는 프록시를 통한 처리, REJECT는 요청 거부를 뜻합니다. 구성에서 정책 그룹 이름을 참조할 수도 있으며, 이 경우 실제 동작은 그룹에서 현재 선택된 항목에 따라 달라집니다. 수정할 때는 규칙 끝의 정책뿐 아니라 해당 규칙이 참조하는 그룹도 확인하세요. 규칙 앞부분만 보고 요청 경로를 판단하지 마세요.
IP-CIDR,192.168.0.0/16,DIRECT
먼저 대상을 찾고, 일치할 가능성이 있는 앞쪽 규칙을 확인하세요. 더 구체적인 조건을 적절한 위치에 배치하고 명확한 최종 처리 방식을 유지합니다. 위 규칙은 문법 설명용이며 완전한 구성 파일이 아닙니다. 구성을 적용한 뒤 웹페이지에 문제가 생기면 먼저 일치한 규칙을 기록하고 해당 항목만 수정하세요. 구성 파일 전체와 DNS를 동시에 바꾸지 마세요. 프로토콜 매개변수는 프로토콜 참고에서 확인할 수 있습니다.
서버 항목에는 연결에 필요한 주소, 포트, 프로토콜 및 인증 정보가 저장됩니다. 구독은 기존 항목을 일괄 가져오고 업데이트하는 데 사용합니다. 이 둘은 Config의 라우팅 규칙과 서로 다른 계층입니다. 서버 정보가 있어도 적절한 규칙이 활성화되어 있다는 뜻은 아니며, 규칙 파일을 가져와도 연결 가능한 서버가 생기는 것은 아닙니다.
Home에서 Add Server를 열고 보유한 서버 정보에 맞는 유형을 선택한 다음 매개변수를 하나씩 입력합니다. 기존 구독을 사용한다면 추가 화면에서 해당 Subscribe 유형을 선택하고 자신의 구독 주소를 입력해 저장하세요. QR 코드를 사용하는 경우 Scan QR Code로 가져온 뒤 유형과 주요 항목을 확인해야 합니다. 프로토콜마다 인증, 전송 및 TLS 항목이 다르므로 한 유형의 매개변수를 다른 유형에 그대로 적용하지 마세요.
저장한 뒤 Home으로 돌아가 항목이 표시되는지, 원하는 서버가 선택되어 있는지 확인하고 Connectivity Test를 실행하세요. 항목 이름은 식별을 돕는 라벨일 뿐 연결 성공 여부를 나타내지 않습니다. 직접 수정하기 전에 기존 값을 기록해 두세요. 구독으로 생성된 항목은 다음 업데이트 때 덮어써질 수 있으므로, 계속 유지할 설정을 변경하기 전에 현재 앱에서 제공하는 관리 방법을 확인하세요.
기존 구독을 업데이트한 뒤 항목 수의 변화, 그룹 및 현재 선택 상태가 예상과 일치하는지 확인하세요. 업데이트에 실패하면 주소가 완전한지, 현재 네트워크에서 해당 주소에 접속할 수 있는지 먼저 확인한 다음 유효한 원본 정보를 다시 받아야 하는지 살펴보세요. ‘구독 업데이트 성공’과 ‘서버 연결 성공’은 서로 다른 결과입니다. 전자는 정보를 가져왔다는 뜻일 뿐이며, 후자는 서버 상태, 프로토콜 매개변수 및 네트워크 환경에도 영향을 받습니다.
구독 주소, QR 코드 및 내보낸 구성에는 인증 정보가 포함될 수 있습니다. 문제 해결 자료를 캡처하거나 공유할 때 해당 정보를 가리세요. 특히 전체 구독 주소를 공개 댓글에 올리지 마세요. 가져오기 과정을 단계별로 확인하려면 시작하기의 추가 절차를 참조하세요.
On Demand는 설정한 네트워크 조건에 따라 시스템이 연결을 시작할지 결정하도록 합니다. 연결을 시작하는 조건을 처리하며 Config의 요청 라우팅을 대체하지는 않습니다. 앱에서 On Demand 관련 메뉴를 열어 사용할 수 있는 조건을 확인하세요. 메뉴 위치와 조건 이름은 현재 앱 화면을 기준으로 합니다. 설정에 앞서 한 번 수동으로 연결해 시스템 VPN 구성 권한, 서버 매개변수 및 기본 접속이 정상인지 확인하세요.
Wi-Fi, 셀룰러 네트워크 또는 특정 네트워크 조건을 설정해야 한다면 적은 수의 조건부터 시작하세요. 저장한 뒤 해당 네트워크에서 연결 상태를 각각 확인합니다. 트리거 조건이 현재 환경과 일치해야 테스트 결과를 판단할 수 있습니다. 같은 네트워크에서 페이지를 반복해 열고 닫는 것으로는 네트워크 전환 테스트를 대신할 수 없습니다.
수동으로 연결을 끈 뒤에도 다시 연결된다면 시스템 VPN 구성을 반복해서 삭제하기보다 On Demand가 계속 연결을 트리거하는지 먼저 확인하세요. 이번 테스트를 완전히 중단하려면 On Demand를 일시 중지한 다음 연결 스위치를 처리하고 시스템 상태를 확인합니다. 반대로 자동 연결이 되지 않을 때도 서버를 바로 바꾸지 말고 조건이 현재 환경과 일치하는지 먼저 확인하세요.
On Demand는 잘못된 인증 정보를 수정해 주지 않으며 네트워크를 전환한 뒤 기존 연결이 모두 유지된다고 보장하지도 않습니다. Wi-Fi와 셀룰러 네트워크 사이를 전환하면 연결을 다시 설정해야 할 수 있습니다. 테스트할 때 전환 전후의 네트워크, 트리거 조건 및 상태를 기록하면 On Demand 조건 문제와 연결 자체의 실패를 구분할 수 있습니다.
Data에는 클라이언트가 기록할 수 있는 범위의 트래픽 통계가 표시됩니다. 사용량과 변화를 살펴볼 때 활용하세요. Data를 열면 먼저 표시된 통계 범위, 기간 및 단위를 확인하고 업로드와 다운로드를 비교합니다. 앱 내 통계와 시스템의 셀룰러 데이터 사용량, 기존 서비스의 과금 기준은 다를 수 있으므로 남은 사용량을 추정하는 데 사용하지 마세요.
실제로 확인하려면 현재 수치를 기록하고 정해진 작업을 수행한 뒤 돌아와 변화를 살펴보세요. 초기화 기능이 있다면 적용 범위를 먼저 확인하고 보관할 데이터는 기록해 두세요. 초기화하면 문제를 추적하기 위한 기준값을 잃을 수 있습니다. 통계가 증가했다는 사실은 해당 범위에서 트래픽이 기록되었음을 뜻할 뿐, 특정 도메인에 PROXY가 적용되었거나 요청한 콘텐츠를 모두 받았다는 증거는 아닙니다.
비정상적인 사용량을 확인할 때는 Data와 연결 기록을 함께 살펴보세요. 먼저 사용량이 증가한 시간을 확인한 뒤 해당 시점의 대상과 처리 정책을 확인합니다. 백그라운드 동기화, 미디어 미리 로드 및 앱 재시도도 요청을 발생시킬 수 있으므로 규칙을 조정하기 전에 구체적인 활동을 찾아보세요. 일정 기간의 총량만 보고 특정 프로토콜이 ‘데이터를 더 적게 쓴다’고 판단하지 마세요.
아래에서는 각 항목의 기능을 설명합니다. Settings 또는 해당 기능 메뉴에서 현재 사용할 수 있는 옵션을 확인하세요. 화면 이름과 위치, 시스템 지원 여부는 실제 표시 내용을 기준으로 합니다.
DNS는 도메인 이름을 연결에 사용할 수 있는 주소로 변환합니다. 이름 조회 성공과 대상 서비스 접속 가능 여부는 서로 다른 단계입니다. Settings의 DNS 관련 설정 또는 현재 Config의 DNS 항목에서 실제로 사용 중인 설정을 먼저 확인하세요. 구성 파일에 자체 DNS 지시문이 포함될 수 있으므로, 다른 설정과 중복되거나 영향을 주는지 확인한 뒤 조정하세요. 입력란 하나만 변경했다고 모든 요청이 새 설정을 사용한다고 볼 수는 없습니다.
설정 변경 전 기존 값을 기록하고, 매번 DNS 출처나 동작을 한 가지만 조정한 뒤 같은 대상에 접속해 조회 및 연결 기록을 확인하세요. 지연 테스트는 정상인데 웹페이지가 열리지 않는다면 DNS 조회 실패, 연결 실패, TLS 단계 실패를 구분하세요. 모든 문제를 DNS 탓으로 돌리지 마세요. IPv6를 사용하는 경우 IPv6 주소가 표시되는지만 보고 이상 여부를 판단하지 말고, 현재 네트워크가 해당 주소로 연결할 수 있는지도 고려해야 합니다.
Test Method는 Connectivity Test에서 사용할 테스트 방식을 정합니다. 해당 설정을 열어 현재 방식의 설명을 읽고, 기존 서버를 같은 방식으로 비교하세요. 테스트 대상이 필요한 방식이라면 대상도 동일하게 유지해야 합니다. 방식에 따라 포트 연결 여부나 특정 요청의 결과를 각각 반영할 수 있으므로 서로 다른 방식의 결과를 한데 놓고 순위를 매기면 안 됩니다.
테스트에 표시된 수치만으로 실제 페이지가 열리거나 지속적인 전송 속도가 보장되지는 않습니다. 비교할 때는 기기가 같은 네트워크에 연결되어 있는지 확인하고 대용량 작업은 가급적 피하세요. 한 번 실패했다면 테스트를 반복하고 결과를 기록합니다. 전체 문제 해결 과정에서는 Global Routing, 일치한 규칙 및 실제 접속 대상을 함께 확인해야 합니다.
Today Widget은 시스템 위젯에서 빠르게 정보를 확인하거나 조작하는 기능입니다. 먼저 Settings에서 앱이 제공하는 관련 옵션을 살펴본 다음 시스템 위젯 편집 화면에서 해당 항목을 추가할 수 있는지 확인하세요. 시스템 환경에 따라 메뉴 위치가 다를 수 있으므로 현재 기기에 표시되는 내용을 기준으로 합니다. 위젯이 표시되는지 여부만으로 앱의 연결 기능을 판단하지 마세요.
설정을 마친 뒤 앱에서 연결이 가능한지 확인하고 위젯의 표시 및 조작 결과를 살펴보세요. 위젯은 업데이트가 늦을 수 있습니다. 표시 상태가 다르면 Home과 시스템 VPN 상태를 다시 확인하세요. 위젯의 문구만 보고 연결 여부를 판단하지 마세요. 잠금 화면이나 기기를 공유하는 상황에서 서버 이름이 노출될 수 있는지도 고려해야 합니다.
iCloud 관련 옵션은 앱에서 지원하는 데이터를 동기화하는 데 사용됩니다. 먼저 시스템에서 iCloud 사용 가능 여부와 앱 접근 권한을 확인한 뒤 Shadowrocket의 관련 설정에서 동기화 범위를 살펴보세요. 동기화, 파일 가져오기, 전체 복원은 서로 다른 작업입니다. 모든 서버, 인증 정보, 통계 및 시스템 VPN 권한이 함께 이전된다고 가정하지 마세요.
동기화를 켜거나 다른 기기에서 복원하기 전에 현재 사용할 수 있는 구성의 사본을 보관하고, 병합 또는 덮어쓰기 동작이 발생할 수 있는지 확인하세요. 완료 후 현재 Config, 서버 선택, Global Routing 및 On Demand를 항목별로 확인합니다. 시스템 VPN 구성 권한은 각 기기에서 따로 확인해야 합니다. 동기화된 항목이 표시되더라도 실제 연결 테스트를 거친 뒤 사용하세요.
Diagnostics에서는 연결과 관련된 단서를 수집하고 확인할 수 있습니다. Settings의 해당 메뉴에서 현재 제공되는 진단 항목을 살펴보세요. Connectivity Test와는 용도가 다릅니다. 한 번의 지연 테스트로 얻을 수 있는 연결 정보는 제한적이며, 진단은 어느 단계에서 실패했는지 파악하는 데 도움이 됩니다. 실행 전에 ‘같은 도메인이 Config에서는 실패하지만 Direct에서는 접속된다’처럼 재현할 현상을 정하세요. 막연히 ‘연결이 안 좋다’고만 기록하지 마세요.
문제가 발생했을 때의 네트워크 유형, 모드, 테스트 방식 및 오류 문구를 기록하세요. 시간 초과, 인증 실패, 인증서 오류는 각각 다른 단계에서 발생하며 해결 방법도 다릅니다. 진단 결과에 도메인, 주소 또는 인증 정보가 포함되면 민감한 부분을 가린 뒤 필요한 내용을 정리하세요.
오류를 없애려고 인증서 검증을 함부로 완화하지 마세요. 먼저 서버 정보, 인증서 이름 및 기기 시간을 확인한 다음 항목이 맞는지 확인하고 같은 대상을 다시 테스트하세요.
대상 하나만 실패한다면 해당 대상의 DNS 조회, 일치한 규칙 및 서비스 상태를 먼저 확인하세요. 모든 대상이 실패한다면 기본 네트워크와 서버 매개변수를 다시 살펴봅니다. 이 순서를 따르면 불필요한 변경을 줄이고 앱 설정 문제와 서버 측 상태를 구분하기 쉽습니다. 자주 발생하는 상황은 문제 해결에서 확인하세요.
처음 설정할 때는 ‘수동 연결 성공’과 ‘원하는 방식으로 라우팅’이라는 두 가지 과제를 나누어 진행하세요. 전자는 기존 서버 정보와 시스템 권한을 확인하고, 후자는 Global Routing과 Config를 확인합니다. 기본 연결을 확인하기도 전에 복잡한 규칙, 자동 연결 조건, 여러 DNS 설정을 추가하면 하나의 실패에도 원인이 여럿 생길 수 있습니다.
설정을 복원한 뒤에도 새 테스트 요청을 보내야 합니다. 기존 연결, 앱 캐시 및 시스템 네트워크 변경으로 인해 설정을 바꾼 직후에는 결과가 예상과 다를 수 있습니다. 여러 스위치를 반복해서 전환하기보다 테스트 대상, 네트워크 조건 및 관찰 시간을 일정하게 유지해야 재현 가능한 결과를 얻기 쉽습니다.