Settings 설정 항목 가이드

01 · Settings 및 기본 상태 확인

설정 문제를 점검할 때는 모든 값을 초기화하기보다 반복해서 확인할 수 있는 기준 상태를 먼저 정하세요. Home에서 현재 선택된 서버를 확인하고, Global Routing 상태와 Config에서 실제로 활성화된 구성을 살펴보세요. Settings의 설정은 이 조건들과 함께 확인해야 의미가 있습니다. 같은 DNS 값이라도 네트워크, 규칙, 서버에 따라 결과가 달라질 수 있습니다. 이 세 가지를 기록한 뒤 변경하려는 설정 화면으로 이동해 기존 값, 변경 이유, 테스트 결과를 남기세요.

기본값, 현재 값, 권장 설정은 서로 다릅니다

기본값은 특정 초기 조건에서 앱이 사용하는 값이며, 현재 값은 직접 변경했거나 설정을 가져왔거나 이전에 복원한 데이터에서 비롯될 수 있습니다. 사용 이력이 있는 기기에서는 스위치 위치만 보고 처음 설정된 상태를 판단할 수 없습니다. 이 가이드에서는 모든 기기에서 확인할 수 없는 값을 일괄적인 기본값으로 제시하지 않습니다. 스위치, 포트, 테스트 방식은 먼저 기기에 표시된 값을 확인하세요. 권장 설정은 현재 용도에 적합한 선택일 뿐, 모든 네트워크에서 더 빠르다는 뜻은 아닙니다.

기본 동작을 확인하려면 해당 항목의 앱 내 설명을 먼저 읽고, 활성화된 구성 파일에 관련 지시어가 있는지 살펴보세요. 상태를 깔끔하게 만들겠다고 모든 구성을 바로 삭제하지 마세요. 삭제하면 되돌리기에 필요한 서버 기록, 규칙, 그룹 정보까지 함께 사라질 수 있습니다. 기존 내용을 먼저 백업하고 테스트용 구성을 따로 복사한 다음, 평소 사용하는 구성과 어떤 점이 다른지 기록하는 편이 안전합니다.

먼저 Global Routing의 세 가지 모드를 구분하세요

Config는 현재 구성의 규칙에 따라 요청을 처리합니다. Proxy는 해당 모드의 프록시 경로로 트래픽을 처리하고, Direct는 직접 연결합니다. 세 가지는 트래픽 처리 방식의 차이이지 속도 등급이 아닙니다. 평소 규칙에 따라 트래픽을 분리하려면 대개 Config부터 확인하세요. 규칙의 영향을 분리해 살펴보려면 잠시 다른 모드로 바꾸어 같은 대상을 비교할 수 있지만, 테스트가 끝나면 원래 모드로 되돌려야 합니다. 모드 변경만으로 잘못된 서버 설정을 보완할 수는 없습니다.

한 번에 하나의 변수만 변경하세요

반복해서 테스트할 수 있는 대상 페이지 하나를 정하고 네트워크 유형, 연결 상태, 실패 양상을 기록하세요. 설정 하나를 바꾼 뒤 필요하면 다시 연결하고 새 요청을 보내세요. 서버, DNS, 규칙을 한꺼번에 바꾸면 접속이 복구되어도 무엇이 영향을 주었는지 알 수 없습니다. 되돌릴 때는 변경한 순서대로 하나씩 복구하고 새로운 설정을 계속 추가하지 마세요. 결과에는 단순히 “정상인 것 같다”라고 쓰기보다 어느 단계에서 성공했는지 적으세요.

앱 전체에 적용되는 범위와 구성별 적용 범위도 구분해야 합니다. Settings에 표시되는 전역 항목, Config 파일의 지시어, 개별 서버의 매개변수가 반드시 같은 계층에 있는 것은 아닙니다. 변경한 설정이 예상대로 작동하지 않는다면 먼저 현재 사용 중인 대상에 변경 사항을 적용했는지 확인한 뒤, 앱 내 설명에서 적용 범위를 살펴보세요. 이름이 같은 설정들이 단순히 서로 덮어쓴다고 단정하거나, 활성화되지 않은 다른 구성의 내용을 현재 실행 상태로 간주하지 마세요.

메뉴 이름이 이 문서와 조금 다르면 기능과 앱 내 설명을 기준으로 확인하고, 이름이 비슷하다는 이유만으로 설정을 바꾸지 마세요. 처음부터 연결하는 전체 순서는 튜토리얼에서, 증상별 문제 해결 경로는 문제 해결에서 확인할 수 있습니다. 다음 섹션은 모두 “현재 상태 확인, 최소한의 변경, 실제 테스트, 실패 시 되돌리기” 순서로 설명합니다.

02 · DNS: 이름 확인 경로와 규칙 점검

DNS는 도메인 이름을 연결에 사용할 수 있는 주소로 변환합니다. 도메인 이름이 확인되었다고 이후 연결까지 성공하는 것은 아니며, 연결에 성공했다고 해서 의도한 DNS 경로를 사용했다는 뜻도 아닙니다. 따라서 DNS를 점검할 때는 도메인 이름, 조회 결과, 이후 적용된 정책을 함께 살펴보세요. 먼저 현재 Config에 DNS 관련 지시어가 있는지 확인하고 Settings에서 실제로 사용할 수 있는 DNS 항목과 설명을 읽으세요. 브라우저의 오류 메시지만 보고 모든 DNS 설정을 바꾸지 마세요.

기존에 작동하는 설정을 기준으로 시작하세요

기기에 현재 표시되는 값은 문제를 점검하기 위한 기준이지 자동으로 기본값이 되는 것은 아닙니다. 구성에 따라 DNS 서버, 조회 방식, 도메인 처리 조건이 다를 수 있습니다. 기존 구성을 사용 중이고 DNS 조회가 정상이라면 우선 현재 설정을 유지하세요. 반복적으로 조회에 실패하거나 예상과 다른 주소가 반환되거나 특정 네트워크 조건을 충족해야 할 때만 필요한 부분을 조정하세요. 주소를 많이 직접 입력한다고 신뢰성이 높아지는 것은 아닙니다.

학교, 회사 등 관리되는 네트워크에서는 내부 도메인 확인에 해당 네트워크가 제공하는 DNS 정보가 필요할 수 있습니다. 모든 요청을 다른 DNS 주소로 보내면 내부 사이트에 접속하지 못할 수 있습니다. 반대로 현재 네트워크에서 특정 DNS 주소에 연결할 수 없다면 요청이 느려질 수 있습니다. “DNS 서버에 연결할 수 없음”과 “서버가 예상과 다른 결과를 반환함”을 먼저 구분하세요. 두 상황은 해결 방법이 다르므로 대기 시간만으로 판단하면 안 됩니다.

도메인 규칙과 주소 규칙은 서로 다른 문제를 다룹니다

DOMAIN-SUFFIX는 도메인 접미사로 요청을 매칭하고, GEOIP는 주소에 해당하는 지리 정보로 판단합니다. 기준이 다르므로 서로 완전히 대체할 수는 없습니다. 규칙은 보통 순서대로 확인되므로 더 구체적인 도메인 규칙을 적절한 위치에 두고, 마지막에는 FINAL을 최종 정책으로 사용합니다. 다음 예시는 순서를 설명하기 위한 것이며 개인 구성을 그대로 대체할 수 있는 완성된 파일이 아닙니다. PROXY는 현재 구성에서 인식할 수 있는 정책 참조여야 합니다.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

이 예시에서는 먼저 example.com과 하위 도메인을 처리한 다음 주소 조건을 확인하고, 나머지 요청은 마지막 정책으로 보냅니다. DIRECT와 PROXY 중 무엇을 선택할지는 실제 이용 목적과 기존 구성에 따라 결정하세요. 이 규칙을 복사한다고 특정 사이트에 접속할 수 있는 것은 아니며, DNS 문제를 가리기 위해 모든 도메인을 같은 정책으로 보내서도 안 됩니다. 지정한 사이트만 프록시를 사용하도록 하려면 DOMAIN-SUFFIX 설정 및 확인을 참고하세요.

단계별로 확인해 캐시 영향을 줄이세요

먼저 같은 도메인에서 문제를 재현한 뒤 요청 기록에서 주소를 얻었는지, 어떤 규칙이 매칭되었는지, 연결이 어느 단계에서 이루어졌는지 확인하세요. DNS를 바꾼 뒤에는 새 요청을 보내야 합니다. 기존 연결이 이전 조회 결과를 계속 사용할 수 있고 브라우저나 시스템에 캐시가 남아 있을 수도 있습니다. 필요한 경우 관련 페이지를 닫았다가 다시 열고 앱에서 지원하는 방식으로 연결을 다시 설정하세요. 페이지를 한 번 새로 고친 것만으로 모든 캐시가 삭제되었다고 단정하지 마세요.

도메인 하나만 실패한다면 철자, 도메인 규칙, 해당 대상의 상태부터 확인하세요. 대부분의 도메인에서 조회가 실패한다면 DNS 주소에 연결할 수 있는지와 네트워크 상태를 살펴보세요. 주소를 받았지만 연결 단계에서 실패한다면 DNS를 계속 바꾸기보다 서버, TLS, 라우팅 또는 대상 서비스 문제를 확인해야 합니다. 주소를 직접 입력해 접속하는 방식도 항상 비교 기준이 되지는 않습니다. HTTPS 사이트는 올바른 도메인과 인증서 확인이 필요할 수 있습니다.

성공과 실패를 비교할 수 있도록 같은 네트워크, 같은 서버, 같은 도메인을 사용하고 확인하려는 DNS 설정만 바꾸어 기록하세요. 네트워크를 바꾸어 테스트해야 한다면 네트워크 변경도 별도로 적어 두세요. 내부 도메인에 문제가 생기면 기존 DNS 조건으로 되돌려 확인하고, 광범위하게 실패한다면 마지막 변경부터 되돌리세요. 여러 주소를 계속 바꾸기보다 결과를 Log의 해당 시간 기록과 비교하면 원인을 찾기 쉽습니다.

03 · On Demand: 조건에 따른 연결과 수동 제어

On Demand는 시스템에서 지원하는 조건에 따라 VPN 연결 동작을 시작하거나 관리합니다. 연결을 시도할 시점을 다루는 기능이지, 특정 사이트에 적용할 분할 규칙을 선택하거나 사용할 수 없는 서버를 자동으로 수정하는 기능은 아닙니다. 이 기능을 사용하기 전에 수동 연결이 안정적으로 되는지 확인하세요. 직접 구성을 가져오고 현재 서버를 사용할 수 있는지 확인한 다음 Global Routing을 점검하고 실제 접속을 테스트해야 합니다. 수동 연결부터 실패한다면 자동 연결을 켜 변수를 늘리지 않는 편이 좋습니다.

활성화하기 전에 현재 상태와 조건을 확인하세요

관련 설정을 열어 전체 스위치와 이미 지정된 조건을 기록한 다음 각 조건의 적용 범위를 확인하세요. 현재 상태는 이전 설정이 남아 있을 수 있으므로 앱을 다시 열었다고 기본값으로 돌아왔다고 볼 수 없습니다. 화면에 네트워크별 또는 조건별 항목이 표시된다면 하나씩 확인하세요. 표시되지 않는 기능을 다른 기기의 스크린샷만 보고 추측하지 마세요. 자동 연결이 꼭 필요한 상황에만 적용되도록 조건을 최소한으로 설정하는 것이 좋습니다.

조건이 충족된 시점과 실제 연결 성공 사이에는 여러 단계가 있습니다. 시스템이 조건을 인식하고 연결을 허용한 다음 네트워크 경로를 만들고, 클라이언트가 서버에 연결해야 합니다. 현재 네트워크에서 사용할 수 있는 주소를 받지 못했거나 먼저 네트워크 로그인이 필요한 상황이라면 자동 연결 시도가 일시적으로 실패할 수도 있습니다. On Demand가 켜져 있다고 연결이 항상 성공하는 것은 아니며, 모든 요청이 예상대로 완료된다고 보장하지도 않습니다.

네트워크를 전환할 때 확인할 점

먼저 사용 가능한 Wi-Fi 환경에서 확인한 다음 다른 네트워크로 전환해 VPN 상태와 앱 내 연결 상태가 조건에 맞는지 살펴보세요. 네트워크를 바꿀 때마다 연결이 완료될 시간을 두고 새로운 요청을 보내세요. 기존 연결은 끊겼다가 다시 설정될 수 있고 백그라운드 앱이 이전 상태를 유지할 수도 있습니다. 전환 전에 열어 둔 페이지가 계속 보이는지만 보지 말고 새 요청과 현재 기록을 기준으로 판단하세요.

조건에 Wi-Fi 이름이 포함된다면 대소문자, 공백, 비슷하게 생긴 문자를 포함해 이름이 정확히 일치하는지 확인하세요. 이름이 같더라도 신뢰할 수 있는 네트워크 환경이 같다는 뜻은 아니므로 이름 조건만으로 기기를 인증할 수는 없습니다. 기기의 다른 VPN 구성이나 관리 정책도 연결 결과에 영향을 줄 수 있습니다. 연결이 서로 전환되는 현상이 있으면 현재 어떤 구성이 연결을 제어하는지 먼저 확인하세요.

연결 해제와 자동 연결 조건을 구분하세요

On Demand를 켠 상태에서는 수동 연결 해제와 이후 조건 충족이 서로 다른 동작입니다. 연결을 끊은 뒤 다시 연결되더라도 먼저 On Demand 조건을 확인하고 스위치가 고장 났다고 단정하지 마세요. 오프라인 상태를 분명히 확인해야 한다면 관련 자동 연결 동작을 잠시 끄고 수동으로 연결을 해제한 뒤 시스템과 앱 상태를 확인하세요. 점검이 끝나면 기록해 둔 설정으로 복구해 임시 변경한 자동 연결 조건을 잊지 않도록 하세요.

시스템 권한, 기기 관리 제한, 현재 네트워크 상태는 자동 연결 동작에 영향을 줄 수 있습니다. 화면에 VPN 구성을 처리하라는 안내가 나타나면 시스템 메시지를 읽고 진행하세요. 출처를 확인할 수 없는 안내에 반복해서 동의하지 마세요. 최초 권한 승인과 이후 자동 연결은 별개의 절차이며, 구성이 저장되어 있다고 모든 조건이 작동하는 것도 아닙니다. 현재 상태를 확인하기 어렵다면 수동 연결로 돌아가 기본 네트워크와 서버 정보를 먼저 확인하세요.

권장 설정은 자동 연결이 필요한지에 따라 달라지며, 무조건 켜야 하는 것은 아닙니다. 규칙을 자주 수동으로 테스트한다면 방해 요소를 줄이기 위해 잠시 수동으로 제어할 수 있습니다. 구성이 안정적이고 조건에 따라 연결해야 할 이유가 분명하다면 기능을 켜고 조건을 하나씩 확인하세요. 조작 횟수를 줄이려고 조건을 한꺼번에 많이 추가하지 마세요. 조건을 추가할 때마다 어떤 상황에 필요한지, 원치 않는 연결이 발생하면 어떻게 해제할지 확인해야 합니다.

연결이 간헐적으로 끊긴다면 발생 직전에 화면이 잠겼는지, 네트워크를 전환했는지, 네트워크 로그인을 완료했는지 기록한 뒤 Log 진단과 비교하세요. 연결 버튼을 반복해서 누르면 관찰하기만 더 어려워집니다. 자동 연결을 잠시 끄고 수동 연결을 한 번 재현하면 네트워크, 서버, 연결 조건 중 어느 경로를 점검해야 하는지 구분하기 쉽습니다.

04 · Ping 및 Connectivity Test: 측정의 한계

Ping과 Connectivity Test는 서로 다른 수준의 연결 상태를 확인하며, 결과가 실제 접속 전반을 보장하지는 않습니다. 먼저 현재 테스트 방식, 대상, 시간 초과 설정을 확인한 뒤 결과를 해석하세요. 이름이 비슷한 테스트라도 점검하는 단계가 다를 수 있습니다. 호스트나 포트에 연결할 수 있는지 확인하는 테스트가 있는가 하면, 프록시 경로로 요청을 보내는 테스트도 있습니다. 기기에 표시된 항목 설명을 읽고 모든 밀리초 값을 같은 종류의 지연 시간으로 간주하지 마세요.

숫자를 비교하기 전에 측정 대상을 확인하세요

한 번의 측정 결과는 특정 네트워크와 대상 조건을 반영합니다. 서버 주소에 직접 보내는 테스트와 서버를 통해 웹페이지에 접속하는 테스트는 확인 범위가 다릅니다. 전자는 해당 경로의 일부 단계에 연결할 수 있음을 보여줄 뿐이며, 후자는 도메인 조회, 프로토콜 핸드셰이크, 대상 서비스의 영향을 받을 수 있습니다. 테스트 방식이나 대상이 다른 결과를 직접 순위로 비교하지 말고, 수치가 낮다고 모든 앱이 더 빨라진다고 판단하지 마세요.

현재 값은 변경되었을 수 있고 실제로 사용할 수 있는 항목도 앱 화면에 따라 다르므로 이 가이드에서는 일괄적인 기본 시간 초과 값이나 테스트 대상을 정하지 않습니다. 우선 현재 사용할 수 있는 방식을 유지하고 반복 테스트로 기준을 만드세요. 조정할 때는 한 가지 조건만 바꾸세요. 예를 들어 같은 대상을 유지하고 네트워크를 바꾸거나, 같은 네트워크에서 테스트 방식을 비교할 수 있습니다. 시간 초과가 너무 짧으면 느리지만 완료될 연결을 실패로 판단하고, 너무 길면 연결 불가 상태를 알아차리는 데 시간이 오래 걸립니다.

유용한 결과를 얻기 위한 테스트 방법

먼저 서버 정보가 사용 권한이 있는 구성에 속하는지 확인하고 주소, 포트, 프로토콜을 점검하세요. 그런 다음 같은 네트워크에서 몇 차례 테스트해 성공과 실패의 양상을 기록하고, 가장 좋았던 결과 하나만 저장하지 마세요. 결과가 크게 달라진다면 네트워크 전환, 신호 변화, 기기에서 대량 데이터 전송이 진행 중인지 먼저 살펴보세요. 테스트를 동시에 여러 개 실행하면 네트워크 자원을 서로 사용해 결과를 비교하기 어려워집니다.

그다음 연결을 설정하고 반복해서 확인할 수 있는 대상에 접속해 실제 요청이 완료되는지 살펴보세요. 페이지가 열리더라도 용도에 따라 추가 리소스를 불러오거나 일반적인 상호작용을 완료하는 등 후속 동작을 테스트해야 합니다. 첫 응답이 빠르다고 지속적인 전송이 안정적인 것은 아니며, 한 번의 다운로드 결과가 짧은 요청의 지연 시간을 그대로 보여주지도 않습니다. 측정은 더 나은 숫자를 얻기 위한 것이 아니라 현재 확인 중인 현상을 파악하기 위한 것입니다.

시간 초과가 항상 서버 사용 불가를 뜻하지는 않습니다

일부 네트워크는 특정 탐지 방식을 제한하고 서버도 특정 유형의 탐지에 응답하지 않을 수 있습니다. 따라서 Ping 시간 초과와 실제 프록시 요청 실패를 같은 문제로 볼 수는 없습니다. 실제 접속은 정상인데 탐지에 실패한다면 사용 가능한 구성을 유지하면서 현재 환경에 더 적합한 테스트 방식이 있는지 확인하세요. 반대로 포트에 연결할 수 있다고 인증 정보가 올바른 것은 아닙니다. 비밀번호, UUID, TLS 설정의 오류는 이후 핸드셰이크 단계에서 드러날 수 있습니다.

사용 중인 모든 서버에서 같은 시점에 비슷한 문제가 발생한다면 먼저 기기가 네트워크에 정상적으로 연결되어 있는지 확인한 뒤 공통 DNS 설정이나 테스트 대상 조건을 살펴보세요. 항목 하나만 이상하다면 해당 항목의 매개변수와 서비스 상태부터 확인하세요. 여러 테스트가 실패했다고 모든 서버에 동시에 문제가 생겼다고 볼 수는 없습니다. 특히 테스트들이 같은 대상을 사용한다면 대상 자체가 공통 원인일 수 있습니다.

TLS 연결에서는 인증서 확인을 유지하고 테스트를 통과하려고 보안 관련 옵션을 함부로 바꾸지 마세요. 테스트에 실패하면 서버 주소, 포트, 도메인, 기기 시간을 먼저 확인한 뒤 서버 측 요구 사항을 살펴보세요. 시간 초과를 늘려도 프로토콜 매개변수 오류는 해결되지 않습니다. 입력 항목을 이해하려면 Trojan 매개변수 안내를 참고하되, 실제 설정은 자신의 구성에 맞춰 확인하세요.

마지막에는 테스트 값을 가장 낮추기보다 필요한 요청을 안정적으로 완료할 수 있는 설정을 선택하세요. 테스트 시각, 네트워크 유형, 결과를 간단히 기록한 다음 Log에서 같은 시각에 발생한 실패 단계를 찾으세요. 이렇게 하면 테스트 방식이 현재 환경에 맞지 않는 경우, 기본 연결 실패, 대상 접속 실패를 구분해 잘못된 단계의 설정을 반복해서 바꾸지 않을 수 있습니다.

05 · Log 및 Data: 기록으로 실패 단계 찾기

Log는 실제 요청에서 어떤 일이 있었는지 확인하는 기능이지, 영어 단어 하나가 보인다고 곧바로 오류를 판정하는 도구가 아닙니다. 점검을 시작하기 전에 현재 시각, 대상 도메인, 네트워크 유형, Global Routing, 선택한 서버를 기록하세요. 그런 다음 반복해서 확인할 수 있는 요청을 한 번 보내고 시간대가 가까운 기록을 찾으세요. 여러 앱이 백그라운드에서 동시에 네트워크를 사용하므로 목록 맨 위의 한 줄만 보고 판단하면 관계없는 요청을 문제와 혼동하기 쉽습니다.

DNS 조회, 규칙, 연결, 응답 순으로 나누어 살펴보세요

첫 번째로 도메인이 조회되었고 주소를 받았는지 확인합니다. 두 번째로 어떤 규칙에 매칭되어 어떤 정책을 사용했는지 살펴봅니다. 세 번째로 대상 또는 서버와 연결을 설정했는지 확인하고, 마지막으로 핸드셰이크와 데이터 전송을 살펴보세요. 구체적인 기록 항목은 앱에 실제로 표시되는 내용을 기준으로 하며, 모든 요청에서 같은 세부 정보를 제공하지는 않습니다. 특정 기록이 없다고 해당 단계가 발생하지 않았다고 단정할 수 없으므로 기록 범위와 현재 설정을 함께 확인하세요.

예를 들어 도메인과 주소가 표시된 뒤 시간 초과가 발생했다면 연결 경로를 계속 확인해야 하며 DNS만 바꾸어서는 안 됩니다. 요청이 예상과 다른 규칙에 계속 매칭된다면 Config와 규칙 순서를 살펴보세요. 정책은 맞지만 인증에 실패한다면 서버 매개변수를 확인해야 합니다. 문제를 전체 흐름에 맞춰 살펴봐야 익숙한 오류 단어 하나만 보고 실제 실패 단계를 놓치지 않을 수 있습니다.

로그 수준과 보관 범위는 어떻게 정할까요

먼저 현재 로그 관련 설정과 앱 내 설명을 확인하고, 기기의 현재 값을 일괄적인 기본값으로 단정하지 마세요. 평소에는 필요한 정보를 살펴보기에 충분한 범위를 유지하고, 문제를 재현할 때만 필요한 기록을 임시로 늘리세요. 기록이 상세해지면 저장 공간과 처리 부담이 커질 수 있고 접속 상황에 관한 정보도 더 많이 포함될 수 있습니다. 진단이 끝나면 평소 설정으로 되돌리고 모든 테스트 기록을 장기간 보관할 필요는 없습니다.

유용한 정보를 저장하기 전에 기록을 바로 지우지 마세요. 먼저 증상과 시각을 적고 필요한 부분을 저장한 다음 되돌릴 근거가 있는지 확인하고 필요에 따라 정리하세요. 다시 연결하면 기록의 시간 순서가 바뀔 수 있으므로 연결 및 해제 시각을 표시해 두세요. 문제가 간헐적으로 발생한다면 맥락 없는 로그를 많이 모으는 것보다 언제 시작되었는지, 얼마나 지속되었는지, 네트워크를 바꾸었는지 기록하는 편이 유용합니다.

Data 통계를 곧바로 요금으로 볼 수는 없습니다

Data는 앱에서 집계할 수 있는 트래픽 정보를 확인하는 기능입니다. 통계를 읽기 전에 집계 범위와 방향, 시간 구간, 초기화 여부를 확인하세요. 앱, 시스템, 네트워크 사업자, 연결 서비스는 서로 다른 기준으로 집계할 수 있습니다. 프로토콜 오버헤드, 집계 시작·종료 시점, 갱신 시각도 다를 수 있습니다. 따라서 Data는 테스트 중 데이터가 전송되었는지 확인하는 데 유용하지만 다른 시스템의 정산 기준으로 직접 사용해서는 안 됩니다.

수치가 계속 증가한다면 설정 오류라고 단정하기 전에 전면 다운로드, 미디어 로딩, 백그라운드 작업을 확인하세요. 연결이 설정되어 있어도 새 요청이 없으면 데이터가 눈에 띄게 늘지 않을 수 있습니다. 짧고 반복 가능한 요청을 먼저 보내 변화를 살펴보고 통계를 확인하려고 대량 전송을 반복하지 마세요. 장기간 비교하려면 집계 시간 범위와 초기화 시점을 먼저 통일해야 합니다.

공유하기 전에 민감한 정보를 제거하세요

구독 링크, 인증 정보, 접속 주소, 서버 식별 정보가 진단 기록에 포함될 수 있습니다. 공개적으로 공유하기 전에 화면 중앙의 비밀번호만 가리지 말고 전체 내용을 확인하세요. 오류 유형과 시간 순서, 필요한 항목 이름은 남기되 개인 계정이나 연결 리소스를 식별할 수 있는 값은 다른 내용으로 바꾸세요. 규칙 문제를 설명하는 데 전체 구독 정보나 구성 파일을 제출할 필요는 대개 없습니다.

마지막으로 “관찰한 사실”과 “개인적인 추측”을 구분해서 적으세요. 사실은 어느 요청이 언제 어떤 정책에 매칭되어 실패했는지이고, 추측은 어떤 설정이 원인일 수 있는지입니다. 이 최소 기록을 가지고 문제 해결을 확인하면 적절한 점검 경로를 더 빠르게 찾을 수 있습니다. 점검이 끝나면 임시로 켠 상세 기록을 끄고 평소 사용하던 구성이 선택되어 있는지 확인하세요.

06 · Widget: 빠른 실행과 상태 확인

Widget은 일상적으로 상태를 보거나 작업 화면으로 이동할 때 유용한 바로 가기이며, Home에서 전체 상태를 확인하는 절차를 대신하지 않습니다. 시스템이 Widget의 갱신과 조작 방식을 관리하므로 표시 내용이 현재 연결 결과와 다를 수 있습니다. Widget과 앱 내 상태가 다르면 Shadowrocket을 열어 현재 서버, Global Routing, 연결 상태를 확인한 다음 실제 요청을 보내세요. Widget에 표시된 오래된 문구만 보고 연결이 계속 성공했다고 판단하지 마세요.

Widget 표시와 실제 제어를 구분하세요

기기 환경에 따라 사용할 수 있는 Widget 모양과 조작 항목이 다를 수 있으므로 시스템에서 Widget을 추가할 때 표시되는 옵션과 앱 내 설명을 기준으로 확인하세요. 일부 작업은 앱을 열거나 시스템 확인 절차를 거쳐야 할 수 있습니다. 탭했을 때 화면이 바로 바뀌지 않는다고 기능이 작동하지 않는다고 단정하지 마세요. Widget을 추가한 뒤 연결 해제 상태에서 연결하고, 다시 연결 상태에서 해제하는 순서로 명확히 테스트해 앱 내 상태와 Widget 갱신 시점을 비교하세요.

Settings에서 Widget 관련 항목을 찾으면 현재 값을 확인한 뒤 변경 여부를 결정하세요. 레이아웃과 시스템 지원 범위에 따라 실제 표시 방식이 달라지므로 이 가이드에서는 공통 기본 모양을 정하지 않습니다. 일상적인 판단에 필요한 정보만 남겨 비슷한 바로 가기가 많아져 잘못 조작하는 일을 줄이세요. 서버, 프로토콜 매개변수, 복잡한 규칙을 바꿀 때는 앱 내 해당 화면으로 돌아가 전체 내용을 확인해야 합니다.

Widget 정보가 최신 상태가 아닐 때 점검하는 방법

먼저 앱 내에서 상태가 이미 변경되었는지 확인한 뒤 시스템이 갱신될 때까지 기다렸다가 Widget을 다시 살펴보세요. 앱 내에서도 연결 중이라면 Widget을 다시 만들기보다 연결 과정을 먼저 점검해야 합니다. 앱 내 상태와 실제 접속은 정상인데 Widget 정보만 갱신되지 않는다면 시스템에서 지원하는 방법으로 Widget을 다시 구성하거나 추가하세요. 이 경우 Config, DNS, 서버 기록까지 한꺼번에 초기화하지 마세요. 표시 문제의 우선 점검 대상이 아닌 경우가 많습니다.

네트워크 전환, 화면 잠금, 백그라운드 상태에 따라 보이는 결과가 달라질 수 있습니다. 문제가 어떤 동작 뒤에 발생했는지 기록하고 “Widget이 갱신되지 않음”, “탭해도 작업이 완료되지 않음”, “연결 설정 실패”를 구분하세요. 앞의 두 가지는 표시 또는 조작 과정의 문제이고, 세 번째는 Ping과 Log를 활용해 네트워크를 점검해야 합니다. 세 현상을 한꺼번에 다루면 정상인 연결 매개변수까지 반복해서 바꾸게 될 수 있습니다.

On Demand와 함께 사용할 때는 동작 순서를 확인하세요

On Demand가 켜져 있으면 Widget으로 수동 연결을 해제한 뒤 조건이 다시 충족되어 새 연결을 시도할 수 있습니다. 그렇다고 Widget 버튼이 작동하지 않았다고 단정할 수는 없습니다. 테스트할 때는 자동 연결을 잠시 끄고 바로 가기 조작을 따로 확인하세요. 정상 작동을 확인한 후 On Demand 설정을 복구하고 두 기능을 함께 사용할 때의 결과를 테스트하세요. 아이콘 모양만 비교하지 말고 매번 앱 내 실제 상태를 기준으로 판단해야 합니다.

바로 가기는 앱에서 마지막으로 선택한 서버와 구성을 그대로 사용할 수 있으므로 조작 전에 어떤 상태로 설정되어 있는지 확인하세요. 임시 테스트를 마친 뒤 평소 사용하던 구성으로 되돌리지 않으면 다음에 Widget에서 연결할 때 테스트 설정이 적용될 수 있습니다. 규칙 점검을 마칠 때마다 구성을 복구하고 Global Routing을 되돌린 뒤 서버를 확인하고 바로 가기 동작까지 살펴보는 고정된 마무리 절차를 두는 것이 좋습니다.

표시되는 정보의 범위를 관리하세요

Widget은 다른 사람이 쉽게 볼 수 있는 위치에 표시될 수 있습니다. 표시 내용을 설정할 수 있다면 서버 이름과 상태 정보가 외부에 보여도 되는지 고려하세요. 개인 항목의 이름에 전체 계정 정보, 구독 주소, 인증 정보를 넣지 않는 것이 좋습니다. 이름은 항목을 구분하는 데만 사용하고 상세 정보는 해당 설정에 보관하세요. 일상적으로 항목을 선택하기 쉬워지고 화면을 캡처하거나 보여줄 때 정보가 노출될 위험도 줄어듭니다.

Widget에 표시되는 트래픽이 앱 통계에서 제공된다면 Data 집계의 한계를 함께 고려하세요. Widget 숫자만으로 기기 전체의 트래픽을 판단할 수는 없습니다. 시스템 갱신 주기와 앱의 통계 시간 범위가 표시 값에 영향을 줄 수 있습니다. 특정 요청 전후의 변화를 비교하려면 먼저 앱에서 집계 범위를 확인한 뒤 통제된 테스트를 진행하세요. 서로 다른 시점에 캡처한 Widget 숫자 두 개를 바로 빼서 비교하지 마세요.

Widget은 간단한 바로 가기로 두고 복잡한 변경은 앱에서 처리하는 것이 좋습니다. Widget만 계속 이상하고 앱과 실제 접속은 정상이라면 표시 문제로 다루세요. 세 가지 모두 이상하다면 기본 연결부터 점검하세요. 이렇게 하면 바로 가기의 편리함은 유지하면서 표시 지연만 해결하려고 연결 설정을 반복해서 초기화하는 일을 막을 수 있습니다.

07 · iCloud: 동기화, 백업 및 기기 교체 후 복원

iCloud 동기화와 내보내기 백업은 용도가 다릅니다. 동기화는 지원되는 범위에서 기기 간 변경 내용을 전달하고, 백업은 특정 시점의 사본을 보관합니다. 동기화가 원하는 과거 시점으로 언제든 돌아갈 수 있는 보관본을 제공하는 것은 아닙니다. 설정을 정리하거나 기기를 교체하기 전에 앱에서 실제로 제공하는 iCloud 항목과 현재 스위치 상태, 내보낼 수 있는 내용을 확인하고 별도의 사본을 저장하세요. 데이터를 확인하기 전에 여러 기기의 설정을 한꺼번에 변경하지 마세요.

모든 내용이 복사된다고 가정하지 말고 동기화 범위를 확인하세요

서버 기록, Config 파일, 앱 설정이 각각 어떤 방식으로 저장되거나 동기화되는지 하나씩 확인해야 합니다. 항목마다 처리 방식이 다를 수 있으므로 구성 파일 하나가 표시된다고 모든 비밀번호, 선택 상태, 통계 기록까지 이전되었다고 단정하지 마세요. 구체적인 동기화 범위는 앱 내 설명과 실제 결과를 기준으로 확인하세요. 먼저 민감한 정보가 없는 알아보기 쉬운 항목 하나로 테스트한 다음 범위를 넓힐지 결정하는 것이 좋습니다.

시스템 설정에서 현재 iCloud 계정과 관련 접근 권한을 확인하고 사용 가능한 저장 공간과 네트워크 상태를 점검하세요. 앱에서 스위치를 켜는 것은 동기화 조건 중 하나일 뿐, 원격 저장이 완료되었다는 증거가 아닙니다. 내용이 갱신되지 않으면 먼저 기본 조건을 확인한 뒤 다른 기기에서 읽을 수 있는지 살펴보세요. 스위치를 계속 켰다 끄거나 같은 파일을 반복해서 가져와 동기화를 재촉하지 마세요. 중복되거나 구분하기 어려운 사본이 생길 수 있습니다.

기기 교체는 설치, 확인, 복원, 검증 순서로 진행하세요

먼저 App Store에서 Shadowrocket을 받고 구매 및 구입 항목 확인 방법은 복원 안내를 참고하세요. 앱 구매 기록과 개인 연결 구성은 서로 다른 데이터입니다. 앱을 다시 받았다고 서버 정보까지 복원되는 것은 아닙니다. 설치를 마친 후 iCloud 조건을 확인하고 기존 백업에서 필요한 내용을 복원하세요. 마지막으로 현재 서버, Config, Global Routing, 필요한 시스템 권한을 다시 확인해야 합니다.

처음 복원한 뒤에는 복잡한 On Demand 조건을 바로 켜지 말고 수동 연결부터 테스트하는 것이 좋습니다. 익숙한 대상을 선택해 실제 요청을 완료한 뒤 DNS와 규칙이 예상대로 작동하는지 확인하세요. 내용은 복원되었지만 연결에 실패한다면 동기화 문제라고 단정하지 말고 서버 매개변수와 현재 네트워크를 점검하세요. 이전 기기에서 정상적으로 연결되던 상태는 비교 자료로 활용하되 두 기기에서 서로 충돌하는 변경을 동시에 하지 마세요.

기기 간 차이나 충돌이 생기면 두 사본을 모두 보존하세요

두 기기에서 같은 내용을 수정했더라도 시스템이 원하는 사본을 남길 것이라고 가정하지 마세요. 먼저 각 기기의 사용 가능한 사본을 별도로 저장하고 어느 쪽을 기준으로 계속 사용할지 정한 다음 앱에서 지원하는 방식으로 처리하세요. 비교할 때는 규칙 순서, 최종 정책, 서버 참조, 필요한 매개변수를 확인해야 합니다. 파일 이름이 같다고 내용도 같다는 뜻은 아니며 표시된 시간이 더 최근이라고 실제 확인을 대신할 수 없습니다.

중복 항목이 보이면 먼저 내용이 다른 항목인지 같은 내용을 반복해서 가져온 것인지 확인한 다음 불필요한 항목을 삭제하세요. 이름만 기준으로 여러 항목을 한꺼번에 정리하지 마세요. 이름이 같은 서버도 포트나 전송 매개변수가 다를 수 있습니다. 정리를 마친 뒤 한 기기에서 먼저 테스트하고 다른 기기의 결과도 확인하세요. 특히 동기화로 삭제할 때는 영향 범위를 확인하기 전까지 독립적으로 복원할 수 있는 사본을 보관하는 것이 목록을 깔끔하게 만드는 것보다 중요합니다.

백업에도 접근 제어가 필요합니다

내보낸 구성 파일에 주소, 비밀번호, UUID, 구독 링크가 포함될 수 있습니다. 파일 이름이 평범해 보여도 공개해도 되는 자료로 취급하지 마세요. 접근 범위를 직접 관리할 수 있는 위치에 저장하고 공유하기 전에 항목을 하나씩 확인하세요. 규칙을 논의할 때는 개인 매개변수를 제거한 최소 예시를 별도로 만드세요. 백업이 성공했다는 것은 파일이 존재하는 것뿐 아니라 파일을 읽고 저장된 내용을 확인할 수 있다는 뜻입니다.

중요한 설정을 바꾸기 전에 정상 작동이 확인된 사본을 보관하고 용도를 기록하는 것이 좋습니다. 의미 없는 테스트를 매번 장기 백업으로 보관할 필요는 없습니다. 기기 교체 순서와 복원 확인 방법은 구성 백업 및 iCloud 이전을 참고하세요. 이전을 마친 다음 자동 연결과 바로 가기를 다시 설정하고, 테스트용 사본을 평소 사용하는 구성으로 잘못 선택하지 않았는지 확인하세요.

08 · Proxy 포트: 로컬 리스닝과 접근 범위

Proxy 관련 포트는 로컬 리스닝 포트와 원격 서버 포트부터 구분해야 합니다. Add Server에 입력하는 포트는 자신의 서버에 연결할 때 사용하고, 로컬 프록시 리스닝 포트는 해당 프록시 방식의 요청이 기기에서 실행 중인 리스닝 서비스에 연결할 때 사용합니다. 두 포트는 위치와 용도, 접근 경로가 서로 다릅니다. 로컬 포트를 바꾸어도 원격 서비스의 실제 포트는 바뀌지 않으며 인증 오류를 해결하거나 사용할 수 없게 된 연결 서비스를 대신할 수도 없습니다.

프로토콜, 주소, 포트가 일치하는지 먼저 확인하세요

앱에서 관련 리스닝 설정을 제공한다면 표시되는 프로토콜 유형, 리스닝 주소, 포트 안내를 확인하세요. HTTP와 SOCKS5는 서로 다른 프록시 접속 방식이므로 연결하는 쪽에서도 일치하는 유형을 선택해야 합니다. 주소는 요청을 보낼 곳을, 포트는 연결할 리스닝 지점을 나타냅니다. 숫자만 맞고 프로토콜이나 주소가 틀리면 사용할 수 없습니다. 다른 기기의 예시를 보고 흔히 쓰이는 숫자를 이 기기의 기본값이라고 단정하지 마세요.

연결 요청이 실제로 있을 때만 해당 기능을 켜고 기기에 표시된 기존 값을 기록하세요. Shadowrocket에서 일반적인 VPN 연결과 규칙 분리만 사용한다면 우선 기본 연결 경로를 확인하고, 설정을 완성해 보겠다는 이유로 리스닝 항목까지 바꿀 필요는 없습니다. 메뉴마다 적용 조건이 다를 수 있으므로 앱 내 설명을 따르세요. 화면에 없는 리스닝이나 접근 제어 기능이 설정 필드를 추측해 추가할 수 있다고 가정하지 마세요.

루프백 주소와 로컬 네트워크 주소는 서로 다릅니다

루프백 주소는 요청을 보내는 기기 자체를 가리킵니다. 다른 기기에 루프백 주소를 입력하면 Shadowrocket이 실행 중인 기기가 아니라 그 다른 기기 자신을 가리킵니다. 다른 기기에서 접속해야 한다면 먼저 앱이 해당 접속 방식을 지원하는지 확인하고 리스닝 범위, 네트워크, 필요한 접근 제어를 점검하세요. 리스닝 범위만 넓히면 기기 간 요청이 도달한다고 단정할 수 없습니다.

리스닝 범위를 넓히면 더 많은 네트워크에서 해당 포트에 접근을 시도할 수 있으므로 필요한 최소 범위를 우선 사용하세요. 화면에서 인증이나 접근 제한을 설정할 수 있다면 용도에 맞게 확인하세요. 접근 범위를 확인할 수 없다면 신뢰할 수 없는 네트워크에 리스닝 서비스를 노출하지 않는 것이 좋습니다. 네트워크가 바뀌면 기기 주소도 달라져 이전 주소가 더는 맞지 않을 수 있습니다. 사용이 끝나면 더 이상 필요하지 않은 접근 설정을 되돌리세요.

연결 거부, 시간 초과, 인증 실패를 구분해 처리하세요

연결이 거부되면 먼저 해당 리스닝이 켜져 있는지, 앱 상태가 조건에 맞는지, 포트가 올바르게 입력되었는지 확인하세요. 시간 초과가 발생하면 주소, 네트워크 연결 가능 여부, 접근 범위도 살펴봐야 합니다. 연결은 되었지만 인증이나 프로토콜 오류가 발생한다면 연결하는 쪽에서 선택한 프로토콜과 양쪽의 요구 사항을 확인하세요. 실패 단계를 확인하지 않은 채 포트를 여러 개 바꾸지 마세요. 연결을 요청하는 쪽과 리스닝 쪽의 기록을 비교하기 어려워질 수 있습니다.

테스트할 때는 정상적인 VPN 경로를 비교 기준으로 유지하고 리스닝 접속을 따로 확인하세요. 연결하는 쪽에서 프록시 설정을 지원한다면 필요한 항목만 변경하고 테스트가 끝난 뒤 원래대로 되돌리세요. 그렇지 않으면 이후 다른 앱에서 생긴 문제는 종료한 리스닝 주소를 계속 사용하고 있기 때문일 수 있습니다. 한 앱에서 프록시를 통해 접속할 수 있다고 기기의 모든 앱이 자동으로 같은 설정을 사용한다는 뜻은 아닙니다. 실제 요청 범위를 확인하세요.

포트 확인도 전체 점검의 마무리에 포함하세요

로컬 접속이 가능해진 뒤에도 요청에 최종 적용된 정책과 서버를 확인해야 합니다. 리스닝 연결에 성공했다는 것은 요청이 접속 지점에 도달했다는 뜻일 뿐, 이후 DNS 조회, 규칙, 연결까지 정상이라는 뜻은 아닙니다. Log에서 같은 시간의 요청을 찾아 대상의 응답까지 확인하세요. 해당 기록이 없다면 원격 서버 설정을 계속 바꾸기보다 연결하는 쪽에서 방금 입력한 프록시를 실제로 사용했는지 먼저 확인하세요.

마지막으로 정해진 순서에 따라 마무리하세요. 평소 사용하는 Config와 Global Routing을 복구하고 선택한 서버를 확인한 다음 임시 DNS와 로그 설정을 되돌리고 On Demand를 점검한 뒤 Widget을 확인하세요. 변경 사항을 유지해야 한다면 백업 기록부터 갱신하세요. 문제가 해결되지 않으면 문제 해결에서 계속 확인하거나 튜토리얼로 돌아가 최소 연결 절차를 다시 진행하세요. 아직 설명되지 않은 현상을 관련 없는 스위치를 더 켜서 덮으려 하지 마세요.