공식 매뉴얼 · 기능 안내
먼저 Global Routing을 확인한 다음 규칙과 서버를 살펴보세요. 기능이 있는 화면과 설정 방법, 적용 범위를 기준으로 다시 확인할 수 있는 구성을 차근차근 정리합니다.
Global Routing은 연결을 전반적으로 처리하는 방식을 정합니다. 서버를 선택해도 모든 연결이 해당 서버를 통과하는 것은 아닙니다.
Home에서 Global Routing을 열면 Config, Proxy, Direct를 선택할 수 있습니다. 여기서 ‘구성, 프록시, 직접 연결’은 각 모드를 설명하는 한국어 표현이며, 인터페이스에는 Config / Proxy / Direct로 표시됩니다. 일반적으로는 Config부터 사용해 현재 구성의 규칙에 따라 연결별 정책을 적용합니다. 문제 원인을 좁혀야 할 때만 다른 모드로 잠시 전환하세요.
| 모드 및 인터페이스 용어 | 처리 방식 | 사용 상황 | 주의 사항 |
|---|---|---|---|
| 구성 · Config | 현재 구성의 규칙과 정책에 따라 연결을 처리합니다. | 도메인, 주소 또는 네트워크 용도에 따라 연결을 구분하는 일상적인 사용에 적합합니다. | 현재 활성화된 Config와 규칙에서 참조하는 정책을 먼저 확인하세요. |
| 프록시 · Proxy | 트래픽을 프록시 경로로 처리합니다. 단, 시스템 및 클라이언트가 처리하는 범위에 제한이 있습니다. | 문제가 규칙 분기와 관련 있는지 일시적으로 확인할 때 사용합니다. | 속도를 높이는 스위치가 아닙니다. 서버에 문제가 있을 때 이 모드로 전환해도 서버가 복구되지는 않습니다. |
| 직접 연결 · Direct | 기기의 현재 네트워크에서 직접 연결하는 경로로 트래픽을 처리합니다. | 기본 네트워크와 비교해 문제가 프록시 경로와 관련 있는지 확인할 때 사용합니다. | 클라이언트 연결을 끄는 것과 같지 않으며, 다른 설정의 영향을 모두 제거한다고 보장하지 않습니다. |
먼저 Home에서 현재 Global Routing 모드와 선택한 서버를 기록한 다음, 모드를 하나 바꾸고 같은 네트워크에서 같은 대상에 접속하세요. 기존 연결을 재사용해 판단이 어긋나지 않도록 새 연결을 시도하는 것이 좋습니다. Proxy에서는 되지만 Config에서는 안 된다면 일치하는 규칙과 정책 참조를 집중적으로 확인하세요. Direct에서도 실패한다면 로컬 네트워크, 대상 서비스 상태, 시스템 시간을 먼저 점검하세요. 비교가 끝나면 원래 모드로 되돌리고, 문제 해결을 위한 임시 설정을 계속 사용하지 마세요.
먼저 어떤 규칙이 일치했는지 확인한 뒤, 해당 규칙이 어떤 정책을 가리키는지 살펴보세요.
규칙 분기는 도메인, IP 주소 등의 조건에 따라 연결 경로를 선택합니다. Config에서 사용 중인 구성을 선택한 다음 Rule 내용을 확인하세요. 규칙은 일반적으로 위에서부터 순서대로 일치 여부를 확인하므로, 구체적인 조건을 더 포괄적인 조건보다 앞에 두어야 합니다. 마지막의 FINAL은 앞선 규칙에 일치하지 않은 연결에 적용할 정책을 지정합니다.
DOMAIN은 도메인 전체, DOMAIN-SUFFIX는 도메인과 하위 도메인, DOMAIN-KEYWORD는 도메인에 포함된 키워드를 기준으로 일치 여부를 판단합니다. IP-CIDR과 IP-CIDR6은 각각 IPv4 및 IPv6 주소 범위를 지정하고, GEOIP는 주소의 지리적 위치 데이터에 따라 일치 여부를 판단합니다. USER-AGENT는 해당 요청 정보를 확인할 수 있는 경우에만 사용할 수 있으며, 모든 연결에서 앱을 식별하는 조건으로 적합하지 않습니다.
DIRECT는 직접 연결, REJECT는 연결 거부를 뜻합니다. PROXY는 현재 구성에서 정의된 프록시 정책을 가리킵니다. 사용자 지정 정책 이름도 구성에 실제로 존재해야 합니다. 규칙 구문이 올바르더라도 참조하는 정책이 유효하지 않으면 연결이 예상대로 처리되지 않습니다.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY위 내용은 구문 예시이며 기존 구성을 대체할 수 있는 완성된 파일이 아닙니다. 수정 전에 사본을 보관하고, 한 번에 한 가지 조건만 바꾼 뒤 연결 기록에서 일치 결과를 확인하세요. REJECT는 조건에 해당하는 연결만 거부합니다. 하나의 도메인에서 여러 종류의 콘텐츠를 제공한다면 도메인 차단이 정상 기능에도 영향을 줄 수 있습니다.
구독은 서버 정보를 업데이트하는 경로이고, 구성 파일은 규칙과 설정을 모아 둔 것입니다. 두 기능의 용도는 다릅니다.
Home의 추가 메뉴에서 실제 화면에 표시되는 Subscribe를 선택하고, 이미 보유한 구독 URL과 알아보기 쉬운 이름을 입력하세요. 저장한 뒤 업데이트를 실행하고 서버 목록에 예상한 항목이 나타나는지 확인합니다. 구독 업데이트는 해당 구독에서 제공하는 정보를 동기화하는 기능이며, 현재 Config의 규칙까지 반드시 변경하는 것은 아닙니다.
가져오기 전에 URL이 완전한지 확인하세요. 복사 과정에서 공백이나 줄바꿈이 들어가거나 쿼리 매개변수가 빠지지 않았는지 특히 주의해야 합니다. 구독 링크에는 인증 정보가 포함될 수 있으므로 비밀번호처럼 안전하게 보관하고 공개 로그나 스크린샷에 붙여 넣지 마세요. 업데이트에 실패하면 먼저 오류 유형을 살펴보세요. 주소에 연결할 수 없는 경우, 인증 실패, 지원하지 않는 응답 형식은 각각 다르게 처리해야 합니다. 모든 구성을 반복해서 삭제하는 것은 바람직하지 않습니다.
서버를 직접 추가할 때는 Add Server에서 올바른 프로토콜 유형을 먼저 선택한 다음, 보유한 서버 정보에 따라 주소, 포트, 인증 매개변수를 입력하세요. Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard, Hysteria2는 입력 항목을 서로 바꿔 사용할 수 없습니다. 이름이 모두 ‘비밀번호’ 또는 ‘키’로 표시되더라도 값의 형식은 다를 수 있습니다.
Scan QR Code를 사용한다면 QR 코드가 가져오려는 서버 정보에 해당하는지 확인하세요. 가져온 뒤에도 프로토콜과 입력 항목을 점검해야 합니다. 저장할 때는 용도를 구분할 수 있는 이름을 지정해 목록 순서만 보고 서버를 선택하는 일을 피하세요. 항목을 삭제하기 전에 출처를 확인하세요. 구독으로 생성된 항목은 다음 업데이트 때 다시 나타날 수 있고, 직접 만든 항목은 별도로 백업해야 합니다.
서버를 선택한 뒤 Connectivity Test로 현재 조건에서 연결 가능한지 확인할 수 있습니다. 테스트 결과는 특정 방법, 대상, 시점에 대한 결과일 뿐 모든 웹사이트에 접속할 수 있다는 뜻도, 대역폭 측정 결과도 아닙니다. 전환 후 기존 페이지에 변화가 없다면 새 요청을 보내고, Global Routing이 대상 연결을 선택한 정책으로 전달하는지도 함께 확인하세요.
On Demand는 연결을 설정할 시점을 관리합니다. 개별 연결에 적용할 정책을 판단하는 Rule을 대체하지 않습니다.
On Demand는 시스템의 주문형 연결 기능을 이용해 설정한 네트워크 조건에 따라 연결 동작을 트리거합니다. Settings에서 On Demand 관련 메뉴를 찾으세요. 구체적인 조건과 선택 가능한 동작은 현재 클라이언트 화면을 기준으로 확인해야 합니다. 처음 설정하기 전에 수동으로 연결을 켰을 때 정상 작동하는지 확인해 서버 문제와 자동 연결 문제를 혼동하지 않도록 하세요.
예를 들어 실제로 사용할 수 있는 옵션에 따라 특정 Wi-Fi 환경에서 연결 동작을 다르게 설정할 수 있습니다. 네트워크 이름은 조건이고 연결이 설정되는지는 결과입니다. 연결된 뒤의 트래픽 경로는 여전히 Global Routing과 현재 구성에 따라 결정됩니다.
먼저 쉽게 확인할 수 있는 조건 하나만 추가하세요. 저장한 다음 해당 네트워크와 다른 네트워크를 오가며 연결이 예상대로 설정되는지 확인합니다. 조건을 여러 개 사용하는 경우 순서와 적용 범위가 겹치는지도 점검하세요. 테스트할 때는 연결을 수동으로 끄는 것과 On Demand 규칙이 연결을 다시 트리거하는 것을 구분해야 자동 재연결을 스위치 오류로 오해하지 않습니다.
On Demand는 모든 시스템 상태에서 앱이 계속 실행된다고 보장하지 않으며, 네트워크 전환 중 기존 연결이 모두 끊기지 않는다고 보장하지도 않습니다. 주문형 연결 트리거를 완전히 중지하려면 Home의 연결 스위치만 반복해서 조작하지 말고 On Demand 설정도 함께 확인하세요.
Data에서는 클라이언트가 기록한 트래픽 정보를 확인할 수 있습니다. Data를 연 뒤 표시된 기간과 통계 종류, 재설정 기능이 있는지 먼저 확인하고 업로드 및 다운로드 수치를 살펴보세요. 플랫폼과 화면에 따라 제공되는 통계 항목이 다를 수 있으므로 같은 범위의 통계끼리만 비교해야 합니다.
특정 작업에서 트래픽이 발생했는지 확인하려면 현재 값을 기록한 뒤 명확한 접근 작업을 한 번 수행하고 다시 돌아와 변화를 살펴보세요. 통계를 지워야 한다면 비교에 필요한 결과를 먼저 저장하세요. 재설정하면 이후 비교의 기준값이 바뀝니다. 통계가 늘었다는 사실만으로 페이지가 완전히 로드되었는지, 규칙이 올바르게 일치했는지, 원격 앱이 요청을 정상 처리했는지는 알 수 없습니다.
Data는 서비스 제공자가 청구하는 사용량 내역이 아닙니다. 클라이언트의 통계 범위, 프로토콜 오버헤드, 재전송, 원격 측정 방식이 서로 다를 수 있으므로 이를 바탕으로 남은 사용량을 직접 계산하지 마세요. 사용량이 비정상적으로 늘었다면 시스템의 백그라운드 활동과 연결 기록을 함께 확인해 원인을 찾으세요. 트래픽 수치만 보고 DNS, 프로토콜, 규칙 등 여러 설정을 한꺼번에 바꾸지 마세요.
설정은 용도별로 조정하세요. 변경 전에 기존 값을 기록하고 검증한 뒤 유지 여부를 결정합니다.
DNS는 도메인을 연결에 필요한 주소로 변환합니다. Settings의 DNS 관련 메뉴와 현재 Config에 이름 확인에 영향을 주는 옵션이 있을 수 있으므로, 먼저 어느 설정을 편집 중인지 확인하고 실제 적용 관계를 점검하세요. 한 화면의 설정을 바꾸면 모든 구성이 덮어써진다고 가정하지 마세요.
설정할 때는 내용을 명확히 알고 있으며 실제로 접속 가능한 DNS 주소를 사용하고, 주소 형식이 선택한 확인 방식에 맞는지 확인하세요. 도메인으로만 접속이 실패하고 알고 있는 주소로는 연결된다면 DNS를 점검해 볼 수 있습니다. 서버 자체에 연결할 수 없는 경우 DNS만 바꾸어서는 대개 해결되지 않습니다. IPv6, 캐시, 네트워크별 응답 주소의 차이도 함께 비교해야 합니다.
Settings에서 Test Method를 확인해 Connectivity Test에서 사용하는 방식을 알아보세요. 선택 가능한 항목은 현재 화면을 기준으로 확인해야 합니다. 방식마다 검사하는 단계가 다르므로 한 테스트의 수치를 다른 테스트의 결론처럼 해석하면 안 됩니다.
서버를 비교할 때는 테스트 방법, 대상, 기기 네트워크를 동일하게 유지하고 몇 차례 반복해 안정성을 확인하세요. 테스트가 한 번 성공했다고 인증, 도메인 확인, 실제 앱 요청까지 모두 정상이라는 뜻은 아닙니다. 테스트 실패는 대상 또는 방법의 제한 때문일 수도 있습니다. 목록의 한 번의 결과만으로 순위를 정하지 말고 실제 서비스 요청으로 계속 확인하세요.
Today Widget은 시스템이 지원하는 경우 상태를 확인하거나 클라이언트가 제공하는 동작을 실행할 수 있는 빠른 메뉴입니다. Settings에서 관련 옵션을 찾고 시스템의 위젯 관리 화면에서 추가할 수 있는지 확인하세요. 메뉴가 표시되는지, 어떤 동작을 실행할 수 있는지는 현재 시스템과 클라이언트의 지원 여부에 따라 달라집니다.
설정 후 위젯에서 동작을 한 번 실행하고 Home으로 돌아와 실제 연결 상태를 확인하세요. 위젯 표시가 갱신되기까지 시간이 걸릴 수 있으므로 잠시 남아 있는 문구나 아이콘만으로 판단하지 마세요. 시스템에서 해당 위젯을 찾을 수 없다면 앱 내부 메뉴를 사용하면 됩니다. 위젯을 찾기 위해 네트워크 설정을 변경할 필요는 없습니다.
iCloud를 지원하는 Apple 기기에서는 먼저 시스템 계정, iCloud 권한, Settings의 관련 옵션을 확인한 다음 실제로 어떤 정보가 동기화되는지 살펴보세요. 동기화, 내보내기, 백업은 서로 다른 기능입니다. 모든 서버 인증 정보와 규칙, 실행 상태가 자동으로 동일해진다고 가정하지 마세요.
기기 간 첫 동기화를 시작하기 전에 중요한 구성의 사용 가능한 사본을 각 기기에 보관하세요. 한 기기에서 작은 변경을 한 뒤 동기화가 완료되면 다른 기기의 결과를 확인합니다. 덮어쓰기 순서를 파악하기 어려워지지 않도록 양쪽 기기에서 동시에 여러 항목을 수정하지 마세요. 여러 사람이 함께 쓰는 기기라면 계정 접근 권한에도 주의해 인증 정보가 포함된 구성이 다른 사용자에게 노출되지 않도록 하세요.
먼저 증상과 당시 상황을 기록한 다음 진단 결과로 범위를 좁히세요.
Diagnostics는 문제 해결에 필요한 단서를 확인하는 기능입니다. Settings에서 해당 메뉴를 찾고, 구체적인 도구와 기록 내용은 실제 화면을 기준으로 확인하세요. 시작하기 전에 기기의 네트워크, Global Routing, 현재 Config, 선택한 서버, 대상 주소를 기록하고 문제가 연결 전, 도메인 확인 단계, 요청 응답 이후 중 언제 발생하는지 설명하세요. 같은 증상도 원인이 다를 수 있으므로 상황을 구체적으로 적을수록 다음 조치를 정확히 선택할 수 있습니다.
진단 기록을 공유하기 전에 구독 URL의 인증 정보, 비밀번호, 키, 불필요한 기기 정보를 삭제하되 오류 유형과 필요한 시간 정보는 남기세요. 민감한 항목이 포함된 구성 파일 전체를 공개하지 마세요. 진단 정보는 판단을 위한 근거이지 자동 복구를 보장하지 않습니다. 점검이 끝나면 임시 모드와 테스트 설정을 원래대로 되돌리고, 설명할 수 있는 최종 구성만 유지하세요.