설정 주제별로 살펴보기
먼저 모드, 구성, 연결을 구분하세요
아래 화면 경로는 iPhone / iPad를 기준으로 합니다. 다른 플랫폼은 레이아웃과 표시 옵션이 다를 수 있으므로 실제 앱 화면을 확인하고, 특정 화면의 경로를 모든 기기에 그대로 적용하지 마세요.
Global Routing: Config, Proxy, Direct
모드는 트래픽을 처리할 기준을 정합니다. 규칙을 점검하기 전에 먼저 이 설정을 확인하세요.
기능: Global Routing은 연결 처리 방식을 선택하는 설정입니다. Config는 현재 구성 파일의 규칙에 따라 정책을 정하고, Proxy는 클라이언트가 처리하는 요청을 프록시 경로로 보내며, Direct는 해당 요청을 직접 연결합니다. 여기서 ‘전체’는 클라이언트가 처리하는 범위의 트래픽을 뜻하며, 기기의 모든 시스템 트래픽이 같은 경로를 거친다는 의미는 아닙니다.
위치 및 설정: Home에서 Global Routing을 열고 Config, Proxy, Direct 중 하나를 선택한 뒤 현재 서버를 확인하세요. 도메인이나 IP에 따라 경로를 나누려면 평소에는 Config를 사용합니다. 특정 규칙의 정책이 잘못 선택된 것 같다면 잠시 Proxy 또는 Direct로 전환해 비교할 수 있습니다. 비교하는 동안 대상 URL, 네트워크, 서버를 그대로 유지해야 모드와 네트워크 중 무엇이 결과에 영향을 줬는지 판단할 수 있습니다.
| 모드 | 처리 방식 | 사용 상황 | 먼저 확인할 항목 |
|---|---|---|---|
| Config (구성) | 현재 Config의 규칙 매칭 정책을 따릅니다. | 일상적인 규칙 라우팅 및 특정 도메인이나 IP 대역의 경로 확인 | 선택한 구성 파일, 규칙 순서, 정책 대상 |
| Proxy (프록시) | 처리 대상 요청을 프록시 경로로 보냅니다. | 규칙 라우팅의 영향을 잠시 배제하고 기존 서버 연결을 확인할 때 | 현재 서버의 유효성, 인증 정보와 전송 매개변수의 일치 여부 |
| Direct (직접 연결) | 처리 대상 요청을 직접 연결합니다. | 로컬 네트워크 접속 결과와 비교해 프록시 경로의 관련성을 확인할 때 | 로컬 네트워크, 대상 서비스, DNS의 정상 작동 여부 |
유의: Proxy로 전환해도 잘못된 서버 매개변수가 수정되지는 않으며, Direct가 클라이언트 연결을 끄는 것은 아닙니다. 모드를 바꾼 뒤 새 요청을 보내 기록을 확인하세요. 이미 연결된 장시간 연결은 이전 경로를 계속 사용할 수 있습니다. 비교가 끝나면 평소 모드로 되돌려 임시 점검 설정을 계속 사용하지 않도록 하세요. 화면에서 Config는 라우팅 모드와 구성 파일 관리 화면에 모두 쓰이지만, 전자는 라우팅 방식이고 후자는 구성 파일을 관리하는 곳입니다.
규칙 라우팅: 매칭 조건과 정책을 나눠 확인
기능 및 위치: 규칙은 매칭 조건과 처리 정책으로 구성됩니다. Config에서 현재 선택된 구성 파일을 확인하세요. DOMAIN은 전체 도메인, DOMAIN-SUFFIX는 도메인 접미사, DOMAIN-KEYWORD는 도메인 키워드를 기준으로 매칭합니다. IP-CIDR와 IP-CIDR6은 IP 대역에, GEOIP는 IP 지역 데이터베이스의 결과에 따라 매칭합니다. USER-AGENT는 해당 요청 정보를 확인할 수 있어야 사용할 수 있으므로, 모든 암호화 요청을 식별하는 조건으로 간주하면 안 됩니다.
설정 방법: 먼저 경로를 바꾸려는 대상을 정한 다음 가장 구체적인 조건을 선택하세요. 규칙은 일반적으로 위에서 아래 순서로 확인하며, 먼저 매칭된 규칙의 정책이 해당 요청에 적용됩니다. 따라서 특정 도메인 규칙은 이를 덮을 수 있는 넓은 범위의 규칙보다 위에 두고, 매칭되지 않은 요청을 처리하는 FINAL은 맨 아래에 둡니다. 수정 후 구성 파일이 계속 선택되어 있는지 확인하고 새 요청으로 검증하세요. 텍스트가 저장된 것만 확인해서는 안 됩니다.
규칙 예시와 정책 의미
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXYPROXY는 프록시 처리를, DIRECT는 직접 연결을, REJECT는 매칭된 요청의 거부를 뜻합니다. 구성에서 사용자 지정 정책 이름을 사용하려면 해당 정책이 정의되어 있어야 합니다.
유의: 위 예시는 규칙 순서만 설명하며 모든 네트워크에 적합한 것은 아닙니다. IP 기반 매칭에는 DNS 조회가 관여할 수 있으며, 도메인이 가리키는 주소가 바뀌면 연결 경로도 달라질 수 있습니다. REJECT는 매칭된 요청만 거부하며 페이지의 특정 영역을 시각적으로 삭제하거나 원치 않는 리소스를 모두 차단한다고 보장하지 않습니다. 규칙이 올바르게 매칭되는데도 접속할 수 없다면 같은 종류의 규칙을 계속 추가하기보다 정책이 가리키는 서버를 확인하세요.
구독 및 서버 관리: 출처부터 구분
기능 및 위치: 개별 서버 항목에는 프로토콜, 주소, 포트, 인증 정보 등 연결 매개변수가 저장됩니다. Subscribe는 사용자가 이미 보유한 구독 URL에서 항목을 가져오고 업데이트하는 기능입니다. Home에서 서버 목록을 확인하고, 직접 입력하려면 Add Server를 사용하세요. 보유한 QR 코드가 있으면 Scan QR Code로 가져올 수 있습니다. 구독 관리와 Config 파일 관리는 별개입니다. 서버 목록을 업데이트해도 현재 규칙 파일이 함께 업데이트되는 것은 아닙니다.
설정 방법: 이용 중인 서비스 제공자에게 전체 연결 정보를 받은 뒤 실제 제공된 유형에 맞춰 Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard, Hysteria2 등의 프로토콜을 선택하세요. 주소와 포트뿐 아니라 인증, TLS, 전송 방식 및 관련 추가 매개변수도 하나씩 확인해야 합니다. 두 항목의 주소가 같다고 해서 매개변수까지 같다고 단정하지 마세요. 가져온 뒤 항목 수와 이름을 확인하고, 항목 하나를 선택해 Connectivity Test를 실행한 다음 실제 대상에 요청을 보내 검증하세요.
구독을 업데이트할 때는 Home에서 해당 구독을 직접 업데이트하고 결과를 확인하세요. 업데이트 실패와 업데이트 후 목록이 비어 있는 것은 서로 다른 문제입니다. 전자는 링크에 접근할 수 있는지 먼저 확인하고, 후자는 응답 내용이 유효한지와 앱이 인식하는 형식인지도 확인해야 합니다. 링크가 잘렸거나 복사 과정에서 공백이 섞였거나 로그인 페이지가 반환되면 가져오기에 실패할 수 있습니다. 가져오기가 성공한 것을 확인하기 전에는 기존에 사용 가능한 항목을 남겨 두어 비교 대상으로 활용하세요.
유의: 구독으로 생성된 항목을 직접 수정하면 다음 업데이트 때 변경 내용이 덮어써질 수 있습니다. 변경 사항을 계속 유지하려면 먼저 로컬 항목과 구독 항목의 관계를 확인하세요. 구독 URL에는 개인 접속 정보가 포함될 수 있으므로 공개 댓글, 스크린샷, 진단 기록에 올리지 마세요. 프로토콜 이름이 같아도 실제 설정은 다를 수 있으며, Connectivity Test 결과만으로 인증 정보나 대상 접속 여부를 확인할 수는 없습니다.
On Demand: 조건에 따라 연결 시작
기능 및 위치: On Demand는 설정한 네트워크 조건에 따라 연결 동작을 시작합니다. Settings에서 On Demand로 이동해 활성화 상태와 기존 조건을 확인하세요. 이 기능은 연결을 언제 시작할지 정하며, 개별 요청에 어떤 정책을 적용할지는 정하지 않습니다. 도메인과 IP에 따른 라우팅은 계속 Global Routing과 Config가 담당합니다.
설정 방법: 먼저 수동으로 연결해 구성이 작동하는지 확인한 다음 앱에서 실제로 제공하는 조건에 따라 트리거 범위를 설정하세요. Wi-Fi 네트워크 조건을 사용하는 경우 네트워크 식별 정보와 조건 순서를 꼼꼼히 확인합니다. 저장 후 조건에 맞는 네트워크와 맞지 않는 네트워크에서 각각 테스트해 연결 상태가 예상대로인지 살펴보세요. 테스트 중에는 가능한 한 네트워크 조건 하나만 바꾸고 규칙과 서버는 동시에 수정하지 마세요.
유의: On Demand가 백그라운드에서 영구적으로 실행된다는 보장은 없습니다. 네트워크 전환, 시스템 권한, 시스템 정책이 모두 연결 과정에 영향을 줄 수 있습니다. 기능을 켠 뒤 연결 횟수나 배터리 사용량이 달라지면 발생 당시 네트워크 전환 상황을 기록하세요. 먼저 불필요한 트리거 조건을 줄이고 다른 설정을 조정할지 판단하세요. 플랫폼별로 표시되는 조건은 실제 화면을 기준으로 합니다.
Data: 트래픽 변화를 활용한 문제 확인
기능 및 위치: Data는 클라이언트가 처리하는 범위의 트래픽 통계를 보여 줍니다. 분류, 기간, 확인 가능한 세부 정보는 현재 화면에 따라 다를 수 있습니다. 테스트 전후에 요청이나 데이터 변화가 있었는지 살펴보는 데 유용하지만, 서비스 제공자의 청구 내역이 아니며 기기의 모든 네트워크 활동이 집계된다는 뜻도 아닙니다.
사용 방법: Data를 열어 통계 범위와 현재 수치를 먼저 확인한 다음 대상 앱으로 돌아가 반복할 수 있는 요청을 보냅니다. 이후 다시 Data에서 변화를 확인하세요. 앱에서 요청 또는 연결 기록도 제공한다면 대상 도메인, 발생 시각, 정책을 함께 살펴 경로를 판단합니다. 누적량만 보지 마세요. 시스템 백그라운드 활동에서도 트래픽이 발생할 수 있으므로 수치가 크게 늘어도 방금 테스트한 웹페이지 때문이라고 단정할 수 없습니다.
유의: 클라이언트와 서비스 제공자는 프로토콜 오버헤드, 집계 기간, 업로드·다운로드 계산 방식이 다를 수 있으므로 통계 수치가 정확히 일치할 필요는 없습니다. 기록을 지우거나 통계를 초기화하기 전에 문제 확인에 필요한 정보를 보관하세요. 기록에는 도메인, 주소, 접속 시각이 포함될 수 있으므로 공유 전에 민감한 정보를 가리세요. Data에 트래픽이 표시된다는 것은 데이터가 전송되었다는 뜻일 뿐, 대상의 응답 내용이 올바르거나 속도가 보장된다는 뜻은 아닙니다.
DNS: 조회 경로를 확인한 뒤 주소 변경
기능 및 위치: DNS는 도메인을 IP 주소로 변환합니다. 조회 결과는 이후 연결에 영향을 주며 IP 기반 규칙 판정에도 사용될 수 있습니다. Settings에서 DNS 관련 옵션을 확인하고 현재 Config에 DNS 설정이 포함되어 있는지도 살펴보세요. 구성 파일도 실제 동작에 영향을 줄 수 있으므로 한 화면만 변경하고 모든 요청에 새 설정이 적용된다고 가정하면 안 됩니다.
설정 방법: 먼저 문제가 실제로 DNS 조회 단계에서 발생하는지 확인하세요. 대상 도메인 철자가 맞는지, 여러 도메인에서 모두 실패하는지, 로컬 네트워크가 정상인지 살펴봅니다. 현재 DNS 설정을 기록하고 조회 옵션을 한 번에 하나씩만 변경하되 서버와 라우팅 모드는 유지하세요. 입력한 주소는 해당 필드가 지원하는 형식이어야 합니다. 필드에서 특정 프로토콜 주소를 요구한다면 일반 IP 주소와 전체 프로토콜 주소를 혼용하지 마세요.
변경 후에는 새 요청으로 다시 테스트하고 기존 캐시와 장시간 연결의 영향을 고려하세요. 도메인이 정상적으로 조회되는데 연결이 시간 초과된다면 서버, 규칙, 대상 서비스 쪽을 확인합니다. 일부 도메인만 실패한다면 해당 도메인에 실제로 적용된 정책과 조회 결과를 비교하세요. IPv4와 IPv6의 연결 가능 여부는 다를 수 있습니다. 간헐적인 문제가 발생하면 특정 주소 유형을 바로 비활성화하기보다 실제로 사용된 주소 유형을 기록하세요.
유의: DNS는 프록시 전송과 다르므로 DNS를 변경해도 잘못된 비밀번호나 포트는 해결되지 않습니다. 암호화 DNS는 조회 요청이 전송되는 방식의 일부를 설명할 뿐, 모든 앱 트래픽의 개인정보 보호 수준을 뜻하지는 않습니다. 여러 DNS 설정과 라우팅 모드, 서버를 한꺼번에 바꾸지 마세요. 문제가 해결되더라도 어떤 변경이 영향을 줬는지 확인하기 어렵습니다.
Test Method, Today Widget, iCloud
각 설정은 테스트, 빠른 조작, 데이터 동기화에 각각 영향을 줍니다. 연결 품질을 제어하는 설정처럼 함께 취급하지 마세요.
Test Method: 테스트 결과가 의미하는 범위 확인
기능 및 위치: Settings에서 Test Method를 확인하세요. 이 설정은 Connectivity Test가 사용하는 테스트 방식을 정합니다. 방식에 따라 확인하는 연결 단계가 다르므로 결과를 서로 직접 비교하기는 어렵습니다. 특정 방식의 테스트를 통과해도 인증, 대상 웹사이트의 응답, 지속적인 데이터 전송까지 검증된 것은 아닙니다.
설정 방법 및 유의사항: 현재 화면에서 제공하는 테스트 방식을 선택하고, 서버를 비교할 때는 같은 방식을 유지하세요. 테스트 대상을 설정할 수 있다면 대상도 동일하게 유지해야 합니다. 결과가 비정상적이면 먼저 테스트 대상에 접속할 수 있는지 확인한 다음 서버 매개변수를 점검하세요. 실제 사용 여부를 확인하려면 대상 앱에서 직접 요청을 보내야 합니다. 한 번의 테스트 수치를 지속 속도나 장기 안정성의 기준으로 삼지 마세요.
Today Widget: 빠른 조작 후 앱에서 상태 확인
기능 및 위치: Today Widget 설정은 시스템 위젯에서 빠르게 접근할 수 있도록 합니다. 먼저 Settings에서 관련 옵션을 확인한 뒤 시스템에서 제공하는 추가 방법에 따라 사용할 수 있는 위치에 위젯을 배치하세요. 시스템 버전에 따라 위젯의 표시 위치와 조작 기능이 다를 수 있습니다.
설정 방법 및 유의사항: 위젯을 추가한 뒤 한 번 조작하고 Home으로 돌아가 연결 및 선택된 서버가 예상대로인지 확인하세요. 위젯에 표시되는 상태는 시스템의 새로고침 시점에 영향을 받을 수 있으므로 오래된 상태만 보고 연결이 유지되고 있는지 판단하면 안 됩니다. 위젯이 표시되거나 업데이트되지 않으면 먼저 시스템에서 위젯을 허용했는지, 앱을 처음 실행했는지 확인하세요. 이 문제 때문에 규칙 파일을 다시 작성할 필요는 없습니다.
iCloud: 동기화, 백업, 현재 선택 상태 구분
기능 및 위치: iCloud 관련 옵션은 앱에서 지원하는 데이터 동기화 또는 가져오기에 사용됩니다. Settings에서 해당 항목을 확인하고 시스템 iCloud에 로그인되어 있으며 앱 사용이 허용되었는지도 살펴보세요. 화면에 Import from Cloud JSON이 있다면 해당 기능이 지원하는 형식으로 가져오세요. 임의의 구독 텍스트를 같은 종류의 파일로 취급하면 안 됩니다.
설정 방법 및 유의사항: 대상 기기에서 데이터가 수신되었는지 확인한 다음 현재 선택된 Config와 서버를 점검하세요. 선택 상태, 시스템 연결 권한, 모든 로컬 설정이 똑같이 동기화된다고 가정하지 마세요. 동기화 전후에 사용 가능한 구성 사본을 보관하고, 충돌이 발생하면 먼저 유지할 내용을 확인하세요. 서버 인증 정보와 구독 URL은 민감한 정보이므로 클라우드 계정의 접근 권한에도 유의해야 합니다. 플랫폼 간 데이터 호환 범위는 실제 기능에 따릅니다.
Diagnostics: 증상에서 검증 가능한 점검 단계로
기능 및 위치: Diagnostics는 앱이 제공하는 네트워크 점검 정보를 수집하거나 확인하는 진단 메뉴입니다. Settings에서 Diagnostics를 찾아 현재 화면에 표시되는 항목을 선택하세요. 진단 기록은 특정 시점의 테스트 환경을 보여 주므로 오래된 기록을 현재 네트워크 상태의 근거로 삼지 마세요.
사용 방법: 먼저 증상을 구체적으로 기록하세요. 연결 스위치를 켜도 연결되지 않는지, 모든 대상에 접속할 수 없는지, 도메인 하나만 실패하는지, 구독 업데이트가 되지 않는지 구분합니다. 당시 네트워크, Global Routing, 선택된 서버, Config를 기록한 뒤 문제를 한 번만 재현하세요. 발생 시각에 따라 기록을 확인하고 DNS 조회 실패, 연결 시간 초과, 인증 실패, 규칙에 따른 정책 불일치를 구분합니다. 기록을 수집하기 전에 여러 설정을 한꺼번에 변경하면 기록과 원래 증상의 연관성을 확인하기 어렵습니다.
- 먼저 기본 네트워크를 확인하세요. 조건을 통제해 로컬 네트워크 접속과 비교하고, 네트워크 연결 여부와 인증 필요 여부를 확인합니다.
- 그다음 연결 정보를 점검하세요. 서버 주소, 포트, 프로토콜, 인증 매개변수를 확인하고 필요한 경우 보유한 다른 항목과 비교합니다.
- 이어서 모드와 규칙을 확인하세요. 현재 Config가 선택되어 있는지 확인하고 규칙 텍스트만 보지 말고 요청에 실제로 적용된 정책을 살펴봅니다.
- 마지막으로 원래 설정으로 되돌리고 다시 테스트하세요. 검증되지 않은 임시 변경을 취소하고 같은 대상에 다시 요청해 복구 전후의 차이를 기록합니다.
유의: 기록을 공유하기 전에 구독 URL, 인증 정보 및 기타 개인정보를 삭제하고 오류 유형, 발생 순서, 필요한 환경 정보만 남기세요. 구성 업데이트나 전환 후 문제가 발생했다면 모든 데이터를 바로 지우지 말고 기존 구성 사본과 먼저 비교하세요. 증상별 자세한 점검 방법은 문제 해결 매뉴얼에서, 처음 연결하는 전체 과정은 사용 가이드에서 확인할 수 있습니다.