프록시 모드와 자주 쓰는 설정

Global Routing은 Home에 있으며, 연결 전체에 적용할 처리 방식을 선택합니다. 구성은 Config, 프록시는 Proxy, 직접 연결은 Direct입니다. 모드를 선택해도 서버 정보가 자동으로 입력되지는 않으며 연결이 켜지는 것도 아닙니다. 설정 후 Home에서 현재 서버와 실제 연결 상태를 확인하세요.

일상적인 사용에서 대상별로 처리 방식을 나누려면 Config에서 적절한 구성 파일을 선택해 활성화한 다음 Global Routing을 Config로 설정하세요. 이때 연결은 구성에 포함된 규칙에 따라 처리되며 모든 대상에 같은 정책이 일괄 적용되지 않습니다. 파일을 가져왔어도 활성화하지 않았거나 예상과 다른 파일이 선택되어 있으면 현재 확인 중인 규칙과 결과가 달라질 수 있습니다.

Proxy는 짧은 진단에 유용합니다. 같은 대상이 Proxy에서는 작동하지만 Config에서 문제가 생기면 대상에 적용된 규칙과 정책을 확인하세요. 서버 설정을 전부 다시 입력할 필요는 없습니다. Direct는 직접 연결에서도 문제가 발생하는지 비교하는 데 도움이 되지만, 특정 대상에 직접 접속하지 못한다는 사실만으로 프록시 설정의 정상 여부를 판단할 수는 없습니다.

비교 테스트를 마치면 원래 필요한 모드로 되돌리세요. Global Routing의 Proxy / Direct는 화면에서 선택하는 모드이고, 규칙의 PROXY / DIRECT는 정책 키워드입니다. 서로 다른 계층이므로 이름이 비슷하다고 같은 스위치로 보아서는 안 됩니다.

규칙 라우팅은 Config에서 ‘어떤 대상에 어떤 정책을 적용할지’를 지정합니다. 현재 구성의 편집 또는 규칙 확인 화면으로 이동해 파일이 활성화되어 있는지 먼저 확인한 다음 [Rule] 섹션을 살펴보세요. 일반 규칙은 위에서 아래로 검사하며, 처음 일치하는 규칙이 처리 방식을 결정합니다. 같은 매칭 과정에서 이후 규칙은 대체 결과로 적용되지 않습니다.

DOMAIN은 도메인과 정확히 일치하는 항목에, DOMAIN-SUFFIX는 도메인과 하위 도메인에, DOMAIN-KEYWORD는 도메인에 포함된 키워드에 매칭됩니다. IP-CIDR과 IP-CIDR6은 각각 두 종류의 IP 주소 범위를 지정하며, GEOIP는 IP 위치 정보에 의존합니다. 도메인 규칙과 IP 규칙은 필요한 정보가 다르므로 규칙 순서와 DNS 조회 결과가 판단에 영향을 줄 수 있습니다.

정책은 규칙이 일치한 뒤 수행할 동작을 지정합니다. PROXY는 프록시를 통해 처리하고, DIRECT는 대상에 직접 연결하며, REJECT는 연결을 거부합니다. 구성에서 사용자 지정 정책 그룹을 사용한다면 그룹이 존재하는지, 그룹 내 선택이 예상과 일치하는지도 확인하세요. 규칙 문법이 올바르더라도 참조하는 그룹이 유효하다는 뜻은 아닙니다.

[Rule]
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.org,DIRECT
DOMAIN,ads.example.net,REJECT
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY

위 내용은 텍스트 구성의 읽는 방법을 보여주는 예시이며, 기존 구성을 대체할 수 있는 완성 파일이 아닙니다. 일반적으로 구체적인 규칙을 더 넓은 범위의 규칙보다 위에 둡니다. FINAL은 앞선 규칙에 일치하지 않은 연결을 처리하도록 마지막에 배치합니다. 범위가 넓은 규칙을 너무 앞에 두면 뒤에 작성한 세부 규칙이 올바르더라도 적용되지 않을 수 있습니다.

수정 전에 복구할 수 있는 사본을 보관하고, 한 번에 규칙 하나만 변경한 뒤 같은 대상으로 확인하세요. 문제가 생기면 대상 도메인, 당시의 Global Routing 모드, 적용된 정책을 기록한 다음 로그를 확인하세요. 페이지가 열리는지만으로 특정 규칙이 적용됐다고 판단하지 마세요. 규칙 키워드 설명은 용어집에서 확인할 수 있습니다.

서버 항목에는 연결에 필요한 프로토콜, 주소, 포트, 인증 정보가 저장되고 구독은 하나의 주소로 여러 항목을 업데이트합니다. 두 항목은 주로 Home에서 관리합니다. 이미 구독 주소가 있다면 Add Server로 이동해 Type에서 Subscribe를 선택하고, 서비스 제공업체에서 받은 주소를 화면의 입력란에 입력한 뒤 저장하고 업데이트하세요. 단일 서버 정보를 가지고 있다면 해당 프로토콜을 선택해 각 항목을 입력하세요. 서버 주소를 구독 주소로 가져오면 안 됩니다.

저장한 뒤 목록에 예상한 그룹과 항목이 표시되는지 확인하고 사용할 서버를 선택하세요. 프로토콜 유형은 서버 측 설정과 일치해야 합니다. 포트, 암호 또는 식별자, TLS와 전송 관련 항목도 원본 정보를 기준으로 확인하세요. 익숙한 프로토콜 이름이라는 이유로 Type만 바꾸고 다른 프로토콜의 설정값을 그대로 사용하면 안 됩니다.

Subscribe는 구독 원본에서 관리하는 항목을 업데이트하고, Config는 구성 파일을 업데이트합니다. 두 기능을 혼동하지 마세요. 구독을 업데이트한 뒤에는 선택한 항목이 남아 있는지, 이름이 바뀌었는지, 현재 정책 그룹이 여전히 유효한 항목을 참조하는지 확인하세요. 구독으로 생성된 항목을 직접 수정하면 이후 업데이트에서 변경 내용이 덮어써질 수 있습니다. 계속 유지할 차이가 있다면 별도로 기록하고 관리 방법을 확인하세요.

여러 구독을 관리한다면 출처를 알아보기 쉬운 메모로 구분하고, 업데이트 후 이름이 중복되거나 작동하지 않는 항목이 있는지 확인하세요. 삭제하기 전에 대상이 서버 하나인지 구독 그룹 전체인지 확인해야 합니다. 이름이 같아도 설정값이 같다는 뜻은 아니며, 일시적인 테스트 실패만으로 출처의 구독이 만료됐다고 볼 수도 없습니다. 구독 주소에는 접근 인증 정보가 포함될 수 있으므로 화면을 캡처하거나 기록을 공유하거나 백업 파일을 만들기 전에 민감한 내용이 있는지 확인하세요.

Connectivity Test는 초기 점검에 활용할 수 있지만, 테스트 통과가 모든 대상에 정상적으로 접속할 수 있다는 뜻은 아닙니다. 테스트에 실패하면 현재 네트워크와 Test Method를 먼저 확인한 뒤 서버 정보와 구독 업데이트 결과를 살펴보세요. 가져오기 절차는 사용 안내에서, 프로토콜 항목의 기술적 의미는 프로토콜 매뉴얼에서 확인할 수 있습니다.

On Demand는 설정된 네트워크 조건에 따라 연결 동작을 실행합니다. 수동 연결을 확인한 뒤 특정 네트워크 환경에서 연결을 자동으로 처리하려는 경우에 적합합니다. 관련 설정은 Settings에서 찾을 수 있으며 시스템 VPN 설정에도 해당 상태가 표시될 수 있습니다. 세부 옵션은 앱에 현재 표시되는 내용을 기준으로 확인하세요. 설정 전에 어떤 네트워크에서 연결하고 어떤 조건에서는 연결하지 않을지 정해 두세요.

먼저 On Demand를 끈 상태에서 서버 선택, Global Routing 설정, 연결 시작, 대상 접속까지 수동으로 확인하세요. 기본 연결이 작동하는 것을 확인한 뒤 On Demand 설정으로 이동해 조건과 동작을 살펴보고, 재현하기 쉬운 조건 하나를 설정해 저장하세요. 이후 조건이 충족될 때와 충족되지 않을 때, 네트워크를 전환할 때의 실제 상태를 각각 확인하세요. 겹치는 조건을 한꺼번에 여러 개 설정하면 어떤 조건이 동작을 실행했는지 파악하기 어렵습니다.

On Demand는 만료된 인증 정보를 해결하거나 Config 규칙을 대신하지 않습니다. On Demand는 언제 연결할지를, Global Routing은 연결을 어떻게 처리할지를 결정합니다. 주 스위치를 끈 뒤에도 연결이 시작된다면 서버 항목을 반복해서 삭제하지 말고 자동 실행 조건이 있는지 먼저 확인하세요.

Data에서는 앱에 기록된 트래픽을 확인할 수 있습니다. 연결 중 데이터가 전송됐는지, 테스트 전후에 눈에 띄는 변화가 있었는지 살펴볼 때 유용합니다. Data에 들어가 현재 표시된 통계 범위와 집계 기준을 먼저 확인하세요. 시간이나 연결 범위를 선택할 수 있다면 범위를 정한 뒤 비교해야 합니다. 범위가 다른 수치를 서로 빼서 비교하지 마세요.

재현하기 쉬운 방법은 테스트 전 표시된 수치를 기록하고, 같은 서버와 모드를 유지한 채 확인된 대상 하나만 접속한 다음 Data로 돌아와 변화를 살펴보는 것입니다. 시스템 동기화, 미디어 미리 가져오기, 다른 연결이 통계에 영향을 줄 수 있으므로 테스트 중에는 다른 앱의 백그라운드 전송을 가능한 한 중지하세요. 트래픽이 증가했다는 것은 데이터 전송이 있었다는 뜻일 뿐, 페이지가 완전히 로드됐거나 특정 규칙이 적용됐다는 것을 단독으로 증명하지는 않습니다.

앱 통계와 서비스 제공업체의 청구 내역은 측정 위치, 집계 기간, 오버헤드 산정 기준이 다를 수 있으므로 Data를 남은 데이터 용량을 확인하는 유일한 기준으로 삼지 마세요. 구독에 표시된 용량 정보와 기기에 기록된 데이터도 출처가 다르므로 각각 확인해야 합니다. 통계를 지우거나 초기화하려면 필요한 데이터를 먼저 기록하고 초기화 범위를 확인하세요. 구성 파일을 복원해도 과거 통계가 모두 복구된다고 보장할 수는 없습니다.

Settings에서는 앱 동작을 관리하지만 모든 연결 설정을 여기서 변경하는 것은 아닙니다. 서버 설정은 해당 서버 항목에서 확인하고, 규칙과 일부 DNS 동작은 현재 Config의 설정을 따를 수 있습니다. 설정을 열기 전에 해당 항목이 전체 앱, 현재 구성, 개별 항목 중 어디에 적용되는지 확인하세요. 구성 파일에 관련 지시문이 있다면 적용 범위도 함께 고려해야 합니다.

DNS: 먼저 이름 조회, 다음은 연결 확인

DNS는 도메인 이름을 연결에 필요한 주소로 변환합니다. IP 주소로는 접속되지만 도메인으로는 문제가 있거나, 같은 도메인이 네트워크에 따라 다르게 작동한다면 DNS 조회를 점검 항목으로 삼을 수 있습니다. Settings의 DNS 관련 옵션과 현재 Config의 DNS 지시문을 함께 확인하세요. 원래 값을 기록하고 한 번에 하나씩 변경한 뒤 같은 도메인으로 다시 테스트하세요.

DNS 변경을 모든 문제에 통하는 해결책으로 여기지 마세요. 주소 조회에 성공해도 이후 연결, TLS, 서버 인증 단계에서 실패할 수 있습니다. 설정 변경 후에는 캐시의 영향을 고려하고 테스트 요청에 변경된 설정이 적용됐는지 확인하세요. 용도를 설명할 수 있고 현재 구성과 호환되는 설정을 우선 사용하고, 출처를 알 수 없는 여러 설정을 겹쳐 적용하지 마세요.

Test Method: 테스트 결과의 범위

Test Method는 목록에서 항목을 테스트하는 방식을 지정하며, Settings에서 해당 옵션을 찾을 수 있습니다. 테스트 방식마다 확인하는 연결 단계가 다르므로 결과를 그대로 비교할 수는 없습니다. 적절한 방식을 하나 선택하고 대상과 네트워크 환경을 동일하게 유지한 뒤 Home에서 Connectivity Test를 실행하세요.

목록 테스트는 명백히 실패하는 항목을 찾는 데 유용하지만 실제 서비스 요청을 대신하지는 않습니다. 테스트는 통과했는데 대상에 접속할 수 없다면 DNS 조회, 규칙, 대상 서비스 상태를 계속 확인하세요. 테스트에는 실패했지만 실제 요청이 성공한다면 항목을 바로 삭제하기보다 테스트 방식부터 확인하세요.

Today Widget: 빠른 조작 후 상태 확인

Today Widget은 시스템 위젯에서 관련 기능을 빠르게 실행할 수 있도록 합니다. 사용할 수 있는 동작은 현재 시스템과 앱에 표시되는 내용을 기준으로 확인하세요. Settings에서 관련 옵션을 확인한 뒤 시스템의 위젯 편집 화면에서 사용할 수 있는 위젯을 추가하세요. 처음 사용할 때는 Home으로 돌아가 주 스위치, 현재 서버, 모드를 확인한 뒤 위젯으로 한 번 실행하고 앱에서 결과를 살펴보세요.

위젯 표시가 갱신되기까지 시간이 걸릴 수 있으며 빠른 실행 기능만으로 전체 진단을 할 수는 없습니다. 탭한 뒤 예상과 다르게 작동하면 앱으로 돌아가 실제 상태를 확인하고 On Demand가 연결을 다시 실행했는지도 살펴보세요. 위젯에 한 번 표시된 내용만으로 서버가 작동하는지 또는 규칙이 적용됐는지 판단하지 마세요.

iCloud: 동기화 전에 별도 백업 보관

iCloud는 앱에서 제공하는 클라우드 동기화 또는 관련 저장 기능에 사용됩니다. 사용하기 전에 기기에 로그인된 계정, 시스템의 iCloud 권한, 앱 내 관련 스위치를 확인한 뒤 현재 화면의 안내에 따라 동기화 대상을 살펴보세요. 데이터 유형별로 따로 확인해야 합니다. Config가 표시된다는 이유만으로 구독, 선택 상태, 통계 기록까지 모두 복원됐다고 판단하지 마세요.

기기를 바꾸기 전에 복구할 수 있는 별도 백업을 보관하고, 두 기기에서 동시에 큰 폭으로 편집하지 마세요. 새 기기에서는 파일 내용과 서버 항목을 먼저 확인한 뒤 현재 활성화된 Config와 Global Routing을 점검하세요. 동기화가 편리하더라도 연결 설정을 확인하는 절차를 생략해서는 안 됩니다. 인증 정보가 포함된 파일은 민감한 자료로 안전하게 보관하세요.

Diagnostics: 연결 실패 원인 파악

Diagnostics에서는 진단 및 기록 관련 기능을 확인할 수 있으며 Settings의 해당 메뉴에서 이용할 수 있습니다. 문제가 발생한 시각, 네트워크 유형, 선택한 서버, 대상 정보를 먼저 기록하고 실패 상황을 한 번 재현한 다음 앱에서 제공하는 진단 정보를 살펴보세요. 여러 설정을 연달아 바꾸고 기록을 대량으로 내보내기보다 조건을 명확히 한 번 재현하는 편이 원인을 찾기 쉽습니다.

기록을 살펴볼 때 DNS 조회 실패, 연결 수립 실패, 인증 또는 핸드셰이크 실패를 구분하세요. 모든 문제를 규칙 탓으로 돌려서는 안 됩니다. 기록을 공유하기 전에 구독 주소, 서버 정보, 접속 도메인, 인증 내용에 민감한 정보가 있는지 확인하고 제거하세요. 기록은 당시 조건을 반영하므로 네트워크를 전환한 뒤 생긴 문제는 새로 기록하고 확인해야 합니다.