공식 매뉴얼 · 기능 안내
먼저 트래픽 처리 방식을 정하고 서버와 구성을 확인한 다음 자동 연결, DNS, 테스트 항목을 조정합니다. 한 번에 한 항목만 변경하고 같은 대상으로 다시 테스트하면 설정 적용 여부를 판단하기 쉽습니다.
01 · GLOBAL ROUTING
Global Routing 모드 선택과 서버 선택은 서로 다른 설정입니다. 서버를 선택해도 모든 요청이 해당 서버를 거치는 것은 아닙니다.
무엇이며 어디에 있나요: Global Routing은 Home에 있는 전체 라우팅 메뉴로, Config, Proxy, Direct 세 가지 모드를 제공합니다. Config는 현재 구성의 규칙을 적용하고, Proxy는 클라이언트가 처리하는 요청을 프록시 정책에 따라 처리하며, Direct는 처리 대상 요청을 목적지에 직접 연결합니다. 이 모드들은 요청 처리 방식을 정하며 서버의 연결 가능 여부를 나타내지는 않습니다.
| 화면에 표시되는 모드 | 처리 방식 | 사용하는 경우 | 우선 확인할 항목 |
|---|---|---|---|
Config · 구성 | 현재 구성의 규칙과 정책에 따라 트래픽을 분류합니다. | 일부 목적지는 프록시로, 나머지는 직접 연결해야 할 때 | 활성화된 구성, 규칙 순서, 정책 참조 |
Proxy · 프록시 | 처리 대상으로 지정된 요청을 프록시로 전달합니다. | 프록시 연결을 임시로 확인하거나 요청을 일괄 처리할 때 | 선택한 서버, 프로토콜 설정, 목적지 연결 가능 여부 |
Direct · 직접 연결 | 처리 대상으로 지정된 요청을 목적지에 직접 연결합니다. | 직접 연결이 필요하거나 프록시 경로와 비교할 때 | 현재 네트워크에서 목적지에 접속할 수 있는지 |
설정 방법: Home에서 Global Routing을 열고 필요한 모드를 선택한 뒤 현재 서버를 확인합니다. 평소에 명확한 분류 규칙을 사용한다면 Config를 선택하세요. 특정 목적지를 점검할 때는 원래 모드를 기록한 다음 Proxy 또는 Direct로 잠시 전환해 같은 대상으로 비교할 수 있습니다. 테스트가 끝나면 원래 설정으로 되돌려 임시 점검 상태가 계속 사용되지 않도록 합니다.
주의할 점: Direct는 클라이언트 연결을 끄는 설정이 아니며, Proxy를 선택해도 목적지 접속이 보장되지는 않습니다. 서버를 선택했더라도 규칙에 따라 요청이 DIRECT로 처리되거나 REJECT될 수 있습니다. 모드를 전환한 뒤 결과가 달라지면 프로토콜 문제로 단정하지 말고 먼저 규칙과 DNS를 확인하세요. 첫 연결 단계는 Global Routing 튜토리얼을 참고하세요.
02 · RULES & POLICIES
규칙은 어떤 요청과 일치하는지, 정책은 일치한 요청을 어떻게 처리하는지 정합니다. 두 항목을 함께 확인해야 합니다.
DOMAIN은 전체 도메인과 일치하고, DOMAIN-SUFFIX는 도메인과 그 하위 도메인에 일치하며, DOMAIN-KEYWORD는 도메인에 포함된 키워드를 찾습니다. IP-CIDR과 IP-CIDR6은 IP 주소 대역에 사용하고, GEOIP는 IP 지리 데이터베이스 결과를 기준으로 매칭합니다. USER-AGENT는 요청에서 해당 정보를 확인할 수 있어야 하며, 일반적인 앱 식별 규칙으로 사용할 수 없습니다.
DOMAIN,www.example.com,PROXY
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTPROXY는 프록시를 통해 처리하고, DIRECT는 직접 연결하며, REJECT는 요청을 거부합니다. FINAL은 앞선 규칙에 일치하지 않은 요청에 적용되는 기본 규칙이며 네 번째 정책이 아닙니다. 구성에서 이름이 지정된 정책 그룹을 참조할 수도 있습니다. 이 경우 규칙이 일치했다는 사실만으로 연결 경로가 결정된 것은 아니므로 그룹 안의 선택 항목도 확인해야 합니다.
위치와 설정 방법: Config에서 현재 활성화된 구성을 확인한 뒤 해당 구성의 편집 메뉴에서 Rule 부분을 살펴봅니다. 먼저 복원할 수 있는 사본을 저장하고 범위가 명확한 규칙을 추가하세요. 우선 적용할 구체적인 규칙은 범위가 넓은 규칙보다 앞에 두고 FINAL은 마지막에 배치합니다. 저장한 다음 Config 모드에서 테스트하고, 확인 가능한 연결 기록에서 매칭된 규칙과 최종 정책을 살펴봅니다.
주의할 점: 규칙은 일반적으로 순서대로 적용됩니다. 앞쪽 규칙이 먼저 일치하면 뒤에 있는 더 구체적인 규칙은 적용되지 않을 수 있습니다. 예시의 example.com은 문법 설명용이며 연결 서비스를 뜻하지 않습니다. IP 규칙은 도메인 확인 과정의 영향을 받을 수 있으므로 도메인 규칙과 IP 규칙의 결과가 다르면 DNS 조회 결과도 확인하세요. 전체 구성 구조는 구성 파일 참고를 확인하세요.
03 · SERVER MANAGEMENT
구독은 서버 정보 목록을 관리하고, 구성 파일은 규칙과 기타 설정을 관리합니다. 한쪽을 가져왔다고 다른 쪽까지 설정된 것은 아닙니다.
무엇이며 어디에 있나요: Home에는 선택할 수 있는 서버와 구독 그룹이 표시됩니다. Add Server에서 연결 정보를 추가하고, Subscribe에서 구독 유형을 선택하며, Scan QR Code로 기존 정보가 담긴 QR 코드를 읽을 수 있습니다. 입력 방식은 서로 다르지만 최종적으로 서버 측 정보와 일치하는 연결 설정을 모두 갖춰야 합니다.
설정 방법: 구독 정보가 있다면 Add Server에서 해당 유형을 선택하고 본인의 구독 주소를 입력한 뒤 확인 후 저장 및 업데이트합니다. 개별 서버 정보가 있다면 프로토콜에 맞춰 주소, 포트, 인증 정보를 입력하세요. Home으로 돌아와 해당 그룹을 펼친 다음 사용할 항목을 선택합니다. 이름만으로 연결 상태를 판단하지 말고 먼저 Connectivity Test를 실행한 뒤 실제 목적지에 접속해 보세요.
업데이트 시 확인할 사항: 구독을 업데이트하면 해당 출처에서 서버 목록을 다시 가져옵니다. 서버 측 자체 문제를 해결하는 기능은 아닙니다. 업데이트 전에 구독 주소가 유효한지 확인하세요. 업데이트 후에는 항목 이름, 설정값 또는 목록 범위가 달라질 수 있으므로 현재 선택 항목을 다시 확인합니다. 구독으로 관리되는 항목은 다음 업데이트 때 수정 내용이 덮어써질 수 있으니 장기간 사용할 설정을 변경하기 전에 출처를 확인하세요.
주의할 점: 구독 주소에는 접근 정보가 포함될 수 있습니다. 스크린샷을 찍거나 동기화하거나 진단 자료를 제출하기 전에 전체 주소와 민감한 매개변수를 삭제하세요. 서로 다른 프로토콜의 항목을 섞어 입력하거나 서버 주소를 구독 주소로 사용하지 마세요. 구독을 가져오는 순서는 구독 튜토리얼을, 기존 구성을 활성화하는 방법은 구성 파일 섹션을 참고하세요.
04 · PROTOCOL PARAMETERS
프로토콜 이름이 같다는 것은 시작에 불과합니다. 인증, 전송 방식, TLS 관련 설정도 본인의 서버 정보와 일치해야 합니다.
무엇이며 어디에 있나요: WireGuard는 키 기반 터널 프로토콜이며 해당 서버 유형에서 설정할 수 있습니다. 키, 주소, 피어 정보는 각각 용도가 다르므로 다른 프로토콜의 계정과 암호로 대신할 수 없습니다.
설정 방법: 기존 WireGuard 설정을 기준으로 로컬 Private Key, 주소, 피어 Public Key, Endpoint 등의 정보를 확인합니다. 원래 구성에 다른 매개변수가 포함되어 있다면 각 항목을 빠짐없이 맞춰 입력하세요. 가져온 후에는 주소와 라우팅 관련 항목도 확인해야 합니다. Endpoint가 입력되었는지만 확인해서는 충분하지 않습니다.
주의할 점: Private Key는 민감한 정보입니다. 핸드셰이크나 접속에 실패하면 키 쌍, Endpoint, 네트워크의 UDP 접속 가능 여부, 주소 설정을 먼저 확인하세요. 전체 구성을 공개해 문제를 해결하려고 하지 마세요. Global Routing과 앱 규칙도 별도로 확인해야 합니다.
무엇이며 어디에 있나요: VMess는 서버 유형 중 하나입니다. 연결 정보에는 주소와 포트뿐 아니라 UUID와 해당 전송 설정도 포함됩니다. 필요한 항목은 본인의 서버 구성에 따라 달라집니다.
설정 방법: Add Server에서 VMess를 선택하고 기존 정보를 입력한 뒤 UUID를 확인하세요. WebSocket이나 TLS를 사용한다면 Host, Path, Server Name 등의 항목도 하나씩 확인합니다. 각 항목의 값이 서로 다를 수 있으므로 서버 설정에 기재된 그대로 입력해야 합니다.
주의할 점: 기기의 시간이 맞지 않으면 인증에 영향을 줄 수 있으며, 설정값이 일치하지 않으면 연결 시간 초과가 발생할 수 있습니다. 오류가 발생하면 원본 정보와 기기 시간을 먼저 확인하세요. 오류를 없애려고 인증서 검증을 임의로 끄지 마세요. 가져오기에 성공했다는 것은 정보를 읽었다는 뜻일 뿐, 연결이 검증되었다는 뜻은 아닙니다.
Shadowsocks, VLESS, Trojan, HTTP, SOCKS5, Hysteria2 등도 같은 순서로 확인하세요. 먼저 프로토콜을 확인하고 주소와 포트를 검토한 다음 인증, 전송 방식, TLS 관련 항목을 살펴봅니다. 프로토콜마다 필요한 설정이 다르며 모든 입력 항목이 모든 유형에서 사용 가능한 것도 아닙니다. 편집할 때는 앱에 표시되는 항목과 본인의 서버 안내를 기준으로 하고, 누락된 정보를 추측해서 입력하지 마세요.
05 · ON DEMAND
먼저 수동 연결을 확인한 뒤 자동 연결 조건을 활성화하세요. 자동화가 서버와 규칙을 올바르게 설정하는 일을 대신하지는 않습니다.
무엇이며 어디에 있나요: On Demand는 설정한 조건에 따라 시스템의 VPN 연결 동작을 시작합니다. Settings의 On Demand 메뉴에서 사용할 수 있는 옵션을 확인하세요. 네트워크 유형이나 SSID 등의 조건이 표시되는지, 어떤 방식으로 구성되는지는 현재 앱 화면을 기준으로 합니다. On Demand와 Global Routing의 역할은 다릅니다. 전자는 언제 연결할지, 후자는 연결 후 요청을 어떻게 처리할지를 결정합니다.
설정 방법: 먼저 자동 연결을 끄고 수동으로 연결해 본인 서버와 Config가 제대로 작동하는지 확인합니다. 그런 다음 On Demand에서 범위가 분명한 조건 하나부터 설정하세요. 저장 후 해당 조건에 맞는 네트워크로 전환해 시스템 연결 상태를 확인하고, 목적지 접속과 정책이 예상대로 동작하는지 살펴봅니다. 다른 조건이 필요하면 하나씩 추가해 각각 테스트하세요.
주의할 점: 여러 조건이 겹칠 수 있으며 조건 순서나 동작 설정에 따라 결과가 달라질 수 있습니다. 수동으로 연결을 끊은 뒤 다시 연결된다면 시스템 설정을 반복해서 추가하지 말고 On Demand가 계속 작동 중인지 먼저 확인하세요. 문제를 점검할 때는 현재 네트워크, 조건, 예상 동작을 기록하세요. On Demand를 잠시 비활성화하고 다시 테스트하면 자동 연결과 일반 연결 문제를 구분하는 데 도움이 됩니다.
06 · DATA
트래픽 통계는 연결 활동을 파악하는 데 도움이 되지만 서비스 제공업체나 시스템의 측정 기준을 대신하지는 않습니다.
무엇이며 어디에 있나요: Data에는 클라이언트가 기록한 트래픽 정보가 표시됩니다. Data를 열고 현재 화면의 집계 범위와 단위를 확인한 뒤 업로드, 다운로드, 화면에 표시된 시간이나 연결 기준을 구분하세요. 통계값은 클라이언트가 기록한 활동을 나타내며 구독의 잔여 데이터로 바로 해석해서는 안 됩니다.
사용 방법: 특정 작업을 확인하려면 테스트 전 수치를 기록한 다음 명확한 목적지에 접속하고 돌아와 변화를 살펴봅니다. 현재 화면에서 초기화 기능을 제공한다면 영향 범위를 파악한 뒤 사용하고 초기화 시각을 직접 기록하세요. 연결 기록과 Global Routing도 함께 확인해야 해당 작업이 예상대로 처리되었는지 판단할 수 있습니다.
주의할 점: 백그라운드 동기화, 웹 페이지 리소스, 시스템 요청도 트래픽 수치에 영향을 줄 수 있습니다. 수치가 늘었다고 해서 목적지 연결이 예상한 정책을 따랐거나 요청 내용이 올바르게 반환되었다고 단정할 수 없습니다. 집계 범위와 연결 오버헤드는 다른 측정 도구와 다를 수 있습니다. 연결 문제를 점검할 때는 총 트래픽만 비교하지 말고 구체적인 요청과 매칭 결과를 우선 확인하세요.
07 · SETTINGS
아래에서는 기능 이름을 기준으로 설정 위치를 안내합니다. 일부 설정은 현재 Config의 영향을 받을 수 있으므로 변경 전에 어떤 설정이 적용되는지 확인하세요.
무엇이며 어디에 있나요: DNS는 도메인 이름을 연결에 필요한 주소로 변환합니다. 먼저 Settings의 DNS 관련 메뉴를 확인하고, 현재 Config의 General, Host 등 관련 설정도 살펴보세요. 한 곳만 변경하고 구성에 지정된 값을 놓치지 않도록 합니다.
설정 방법: 먼저 기존 값을 기록하고 선택한 DNS 서비스에 현재 네트워크에서 접속할 수 있는지 확인한 뒤 해당 설정을 변경합니다. 같은 도메인으로 다시 테스트하고 조회 결과, 규칙 매칭, 목적지 연결 상태를 함께 살펴보세요. 현재 구성에 DNS가 지정되어 있다면 적용 범위를 먼저 확인해야 합니다.
주의할 점: IP 주소로는 접속되지만 도메인으로 접속되지 않는다면 DNS가 원인일 수 있습니다. 다만 TLS 등 다른 요소도 확인해야 합니다. 규칙 오류를 가리기 위해 DNS를 자주 바꾸지 마세요. Host에 지정된 매핑이 최종 결과에 영향을 줄 수도 있습니다.
무엇이며 어디에 있나요: Settings의 Test Method에서는 연결 테스트 방식을 선택합니다. 이 설정은 Connectivity Test가 서버를 확인하는 방법에 영향을 주지만 프로토콜 설정이나 Global Routing을 변경하지는 않습니다.
설정 방법: 현재 화면에 제공되는 옵션 중에서 방식을 선택합니다. 해당 방식에 테스트 대상 등의 추가 설정이 있다면 대상에 실제로 접속할 수 있는지도 확인하세요. 여러 항목을 비교할 때는 같은 방식과 네트워크를 유지하고 필요하면 테스트를 반복해 일시적인 변동의 영향을 줄입니다.
주의할 점: 테스트에 성공해도 모든 웹사이트에 접속할 수 있다는 뜻은 아니며, 실패했더라도 테스트 방식에 따라 해석이 달라집니다. 핸드셰이크 연결 여부, 웹 페이지 응답, 실제 전송 속도는 서로 다른 지표입니다. 계속 점검하려면 연결 문제 안내를 참고하세요.
무엇이며 어디에 있나요: Today Widget은 시스템 위젯과 관련된 메뉴입니다. Settings에서 제공되는 내용과 옵션을 확인하세요. 해당 위젯을 추가할 수 있는지는 기기의 현재 위젯 화면을 기준으로 합니다.
설정 방법: 먼저 앱에서 서버를 선택하고 수동 연결을 테스트합니다. 그런 다음 시스템 위젯 편집 절차에 따라 사용할 수 있는 위젯을 추가하고 표시 내용을 확인하세요. 위젯에서 작업한 뒤 필요하면 Home으로 돌아가 실제 연결 상태를 확인합니다.
주의할 점: 위젯 정보는 일정 간격으로 갱신될 수 있으므로 화면이 한 번 바뀐 것을 실시간 진단 결과로 간주하지 마세요. 위젯을 조작한 뒤 상태가 예상과 다르면 앱으로 돌아와 권한, 서버 선택, On Demand 조건을 확인합니다.
무엇이며 어디에 있나요: Settings의 iCloud 관련 기능은 앱에서 지원하는 범위의 데이터를 동기화하거나 백업합니다. 동기화한다고 모든 시스템 권한까지 복사되는 것은 아닙니다. 어떤 항목이 포함되는지는 해당 메뉴의 안내를 확인하세요.
설정 방법: 기기에서 본인의 iCloud 계정에 로그인했는지 확인하고 시스템 설정에서 필요한 접근을 허용합니다. 처음 활성화하기 전에 기존 구성의 사본을 보관하세요. 다른 기기에서 동기화 결과를 확인한 뒤 기존 내용을 대체할지 결정합니다.
주의할 점: App Store 구매 항목 복원과 iCloud 데이터 동기화는 별개의 작업입니다. 앱을 다시 다운로드한 뒤에도 서버, 구성, 연결 권한을 확인해야 합니다. 동기화되는 데이터에 구독 주소나 인증 정보가 포함될 수 있으므로 계정과 기기 접근 권한을 안전하게 관리하세요.
설정을 마치면 Home으로 돌아가 서버와 Global Routing을 확인한 뒤 실제 목적지를 테스트하세요. 가져오기부터 차례로 진행하려면 전체 사용 튜토리얼을 읽고, 규칙 문법을 수정하려면 규칙 매뉴얼을 확인하세요.