Shadowrocket 전체 사용법 첫 설정과 일상 관리

먼저 앱을 확인한 뒤 구매 내역 확인

Shadowrocket은 App Store 정품 확인 페이지에서 지정된 제품 페이지를 열어 구매하세요. 검색 결과에 표시된 이름만으로 앱을 판단하지 마세요. 제품명이 Shadowrocket인지 확인한 다음 개발자 Shadow Launch Technology Limited, 공식 아이콘, 앱 ID 932747118을 함께 확인하세요. 앱 ID는 제품 링크 끝부분의 id932747118에서 확인할 수 있습니다. 이름이 비슷하다고 같은 제품은 아니므로, 특정 색상이나 검색 순위만 보지 말고 이 항목들을 종합적으로 확인해야 합니다.

App Store에서 가격, 호환성, 구매 안내를 확인한 뒤 시스템의 구매 절차를 진행하세요. Shadowrocket은 주로 iPhone과 iPad에서 사용합니다. Mac, Apple TV, Apple Vision의 지원 여부도 동일한 제품 페이지의 호환성 항목에서 확인할 수 있습니다. 시스템 요구 사항과 구매 가능 여부는 App Store 페이지의 안내를 기준으로 합니다. 기기에서 제품 페이지를 열 수 있다고 해서 해당 기기의 현재 시스템이 실행 요구 사항을 충족한다고 단정하지 마세요. 실제 구매 가능 여부는 현재 기기에 표시되는 App Store 결과를 확인하세요.

일회성 구매에 포함되는 항목

일회성 구매는 앱 자체의 구매 방식이며, 연결 서비스를 지속적으로 제공한다는 뜻은 아닙니다. 미국 스토어 가격은 약 2.99달러이며 실제 가격은 App Store 페이지를 기준으로 합니다. 각 스토어에는 현지 통화로 표시됩니다. 결제하기 전에 현재 스토어 구매에 사용하는 Apple 계정과 페이지에 표시된 금액을 확인하세요. 구매 후에도 클라이언트에는 사용자가 보유한 구독 정보나 서버 설정이 필요합니다. 앱 구매 내역은 이 정보를 대신하지 않으며 특정 서버가 현재 사용 가능하다는 증거도 아닙니다. 두 종류의 비용과 기록을 구분해 두면 기기 변경과 문제 해결이 쉬워집니다.

서버 정보에는 보통 주소, 포트, 프로토콜, 인증 매개변수가 포함됩니다. 구독은 서버 목록을 가져오는 데 사용하는 주소입니다. 구성 파일은 규칙, 일부 연결 설정, 정책 참조를 담당합니다. 이 세 가지와 App Store 구매 내역은 역할이 서로 다릅니다. 구매 내역은 앱을 다시 받는 데, 구독은 서버 목록을 관리하는 데, 구성 파일은 연결 처리 방식을 정하는 데 사용됩니다. 앱만 복원한다고 이전 구독, 수동 입력 정보, 로컬 수정 사항까지 새 기기에 자동으로 모두 복원되는 것은 아닙니다. 이전하기 전에 데이터 출처와 백업을 확인하세요.

첫 구매와 구매 항목 복원 순서

처음 구매한 뒤 App Store에서 앱 다운로드가 완료될 때까지 기다린 다음 기기의 홈 화면에서 앱을 여세요. App Store에 이미 구매됨 또는 다시 다운로드 표시가 있다면, 중복 구매를 하기 전에 해당 구매에 사용한 계정을 확인하세요. 기기를 바꾸거나 앱을 다시 받을 때는 원래 구매한 계정으로 App Store 계정 페이지에서 구매한 앱을 찾습니다. 메뉴 이름은 시스템 인터페이스에 따라 달라질 수 있습니다. 앱을 찾을 수 없다면 먼저 구매 내역, 숨겨진 항목, 현재 스토어 계정을 확인한 뒤 국가 또는 구매 가능 범위를 살펴보세요. 가족 공유 적용 여부도 App Store 안내와 실제 계정 상태를 기준으로 확인해야 합니다.

클라우드 동기화에 사용하는 계정과 App Store 구매 계정은 서로 다를 수 있습니다. 문제를 확인할 때는 시스템 설정 상단에 표시된 이름만 보지 말고 App Store 계정을 확인하세요. 계정 정보는 개인 정보이므로 공개 리뷰나 문제 해결용 스크린샷에 올리지 마세요. 구매 내역을 기록할 때는 본인이 알아볼 수 있는 정도로만 남기고 계정 비밀번호는 기록하지 마세요. 복원 중 결제나 계정 제한 문제가 생기면 App Store의 계정 처리 절차를 따르세요. Shadowrocket의 규칙, 프로토콜, DNS를 변경해도 App Store 구매 상태는 달라지지 않습니다.

구매 후 확인 사항

앱을 연 뒤 먼저 Home, Config, Data, Settings 등 주요 화면에 들어갈 수 있는지 확인하고 고급 옵션은 서둘러 변경하지 마세요. 서버 목록이 아직 없더라도 구매에 실패한 것은 아닙니다. 보통은 사용자의 정보가 아직 가져와지지 않은 상태입니다. 이 매뉴얼의 순서에 따라 첫 권한 설정을 마친 다음 서비스 정보를 입력하세요. 앱 업데이트는 App Store에서 관리하며, 업데이트 내역과 지원 조건도 스토어 페이지를 기준으로 합니다. 기기를 바꾼 뒤 복원하는 방법은 구매한 앱에서 Shadowrocket을 다시 받는 방법을 참고하세요.

시스템 팝업이 표시되는 이유

Shadowrocket은 시스템에서 제공하는 네트워크 확장 기능을 통해 연결을 처리합니다. 관련 연결 기능을 처음 활성화할 때 시스템에서 VPN 구성을 추가하라는 메시지가 표시될 수 있으며, 기기 암호나 기기에서 지원하는 인증 방식으로 확인해야 할 수 있습니다. 이 단계는 앱이 시스템에 해당 네트워크 구성을 설정하도록 허용하는 절차입니다. 새로운 서비스를 구매하거나 구독 주소로 결제 정보를 보내는 과정이 아닙니다. 먼저 팝업에 표시된 앱 이름과 안내를 읽고, 본인이 방금 시작한 작업인지 확인한 뒤 결정하세요. 모든 시스템 팝업을 같은 안내로 여기고 연달아 승인하지 마세요.

권한 승인은 연결 준비의 일부일 뿐입니다. 시스템에서 구성 추가를 허용했더라도 서버 주소가 잘못되었거나 인증 정보가 맞지 않거나 서비스가 제공되지 않으면 접속에 실패할 수 있습니다. 반대로 서버 목록을 올바르게 가져왔더라도 시스템이 요구하는 구성 승인을 건너뛸 수는 없습니다. 처음 사용할 때는 ‘정보 가져오기 완료’, ‘구성 생성 승인’, ‘연결 시작’, ‘대상에 정상 접속’을 각각 별도의 확인 단계로 살펴보세요. 스위치 하나만 보고 전체 과정이 완료됐다고 판단하는 일을 줄일 수 있습니다.

권한 승인을 거부한 뒤 다시 진행하기

팝업을 취소했다면 먼저 앱으로 돌아가 현재 연결 상태를 확인한 뒤, 직접 연결을 다시 시작하고 시스템 메시지가 다시 나타나는지 살펴보세요. 스위치를 빠르게 연속으로 누르지 마세요. 권한 승인, 연결 시작, 중지 과정이 서로 겹칠 수 있습니다. 시스템 메시지가 다시 표시되지 않으면 기기 설정에서 VPN 관련 구성을 찾아 Shadowrocket 항목이 있는지 확인하세요. 시스템 메뉴 이름은 버전에 따라 달라질 수 있으므로, 특정 메뉴 경로를 외우기보다 해당 항목의 앱과 상태를 확인하는 것이 중요합니다.

네트워크 구성이 여러 개라면 먼저 각각의 용도를 확인하세요. 다른 VPN 연결이나 관리형 네트워크 설정이 현재 연결에 영향을 줄 수 있습니다. 문제를 확인할 때는 제어할 수 있는 다른 연결을 먼저 중지한 뒤 Shadowrocket만 따로 테스트하세요. 회사나 학교에서 관리하는 기기에는 추가 제한이 있을 수 있으며, 이 경우 기기 관리자에게 확인해야 합니다. 관리 설정을 임의로 삭제해 해결하려 하지 마세요. 이 앱의 시스템 구성을 삭제하는 것도 첫 번째 조치로 삼지 마세요. 영향을 이해하고 필요한 자료를 저장한 뒤에만 다시 설정을 고려하고, 권한 승인도 다시 완료해야 합니다.

첫 연결 전에 환경 정리

테스트를 준비할 때는 인증을 마친 Wi-Fi처럼 조건이 분명한 네트워크를 선택하세요. 일부 공용 네트워크는 시스템이나 브라우저에서 먼저 접속 인증을 해야 합니다. 기본 네트워크를 사용할 수 없다면 클라이언트 설정이 올바르더라도 원격 연결을 만들 수 없습니다. 먼저 클라이언트 연결을 잠시 중지하고 기기에서 일반적인 인터넷 접속이 되는지 확인한 뒤 앱으로 돌아오세요. 첫 연결을 확인하는 동안 Wi-Fi, 모바일 네트워크, 여러 서버를 동시에 바꾸지 마세요. 실패 원인을 파악하기 어려워집니다.

기기의 날짜와 시간도 확인해야 합니다. TLS 연결은 인증서 유효 기간을 확인하므로 기기 시간이 크게 어긋나면 정상 인증서도 유효하지 않은 것처럼 표시될 수 있습니다. 검증 요구 사항을 낮춰 현상을 감추기보다 시스템 시간을 먼저 바로잡으세요. 인증서, 기기 관리, 추가 프로파일과 관련된 시스템 메시지가 표시되더라도 클라이언트를 설정 중이라는 이유만으로 모두 승인하지 마세요. 일반적인 서버 가져오기와 규칙 설정을 위해 출처가 불분명한 시스템 수준 변경을 승인할 필요는 없습니다.

권한 관련 문제 기록 방법

권한 문제는 대개 연결 시작 전후에 나타납니다. 승인이 완료되지 않거나 구성을 만들 수 없거나 스위치가 예상한 상태를 유지하지 못하는 경우입니다. 문제를 기록할 때는 어떤 작업을 했는지, 시스템 팝업이 표시됐는지, 승인 후 앱에 무엇이 표시됐는지 적으세요. ‘안 돼요’라고만 적지 마세요. 스위치로 연결은 시작되지만 특정 대상에만 접속할 수 없다면 연결 및 규칙 장에서 계속 확인하세요. 권한을 반복해서 다시 설정하지 않아도 됩니다. 발생 순서에 가깝게 기록할수록 시스템 문제와 서비스 문제를 구분하기 쉽습니다.

이 단계에서는 On Demand 설정도 미뤄 두세요. 수동 스위치로 연결과 해제를 한 번 반복해 확인한 뒤 자동 연결 조건을 추가해야, 이후 재연결이 수동 조작 때문인지 자동 조건 때문인지 구분할 수 있습니다. 연결을 끊은 뒤 매번 다시 연결된다면 스위치 고장으로 단정하지 말고 자동 동작이 설정되어 있는지 먼저 확인하세요. 권한 확인을 마치면 다음 장에서 서버나 구독을 추가합니다. 아직 서비스 정보가 없다면 인터페이스 안내를 먼저 읽어도 됩니다. 다음 단계로 넘어가려고 매개변수를 임의로 입력할 필요는 없습니다.

먼저 보유한 정보의 종류 확인

가져오기 전에 서비스 제공처에서 받은 정보가 구독 주소인지, 단일 서버 공유 정보인지, 전체 구성 파일인지 확인하세요. 구독 주소는 보통 서버 정보 목록을 가져오는 데 사용하고, 단일 공유 정보는 하나의 연결만 설명합니다. 구성 파일에는 규칙과 다른 설정이 포함될 수 있습니다. 모두 텍스트나 주소 형태라는 이유로 같은 메뉴에 입력하면 안 됩니다. 정보 출처의 용도 안내를 먼저 읽고 Home의 추가 메뉴나 Config의 구성 관리 메뉴를 선택하면, ‘가져오기는 성공했는데 기대한 내용이 없다’는 상황을 줄일 수 있습니다.

서버 정보와 구독 주소에는 인증 정보가 포함될 수 있으므로 비밀번호처럼 안전하게 보관하세요. 복사할 때는 내용을 빠짐없이 가져오고 설명 문구, 공백, 줄바꿈, 한국어 문장부호가 섞이지 않도록 하세요. Scan QR Code로 가져오는 경우에도 QR 코드가 본인이 신뢰하는 정보 출처에서 온 것인지 확인해야 합니다. QR 코드로 가져왔다고 해서 구성이 자동으로 신뢰할 수 있는 것은 아닙니다. 도움을 요청하려고 QR 코드를 공개 게시판에 올리거나 내용을 확인하려고 전체 구독 주소를 낯선 웹사이트에 붙여 넣지 마세요. 문제를 설명할 때는 정보 유형, 오류 메시지, 발생 단계만 알려주면 됩니다.

서버 수동 추가 시 확인 방법

Add Server에서 서비스 정보와 일치하는 유형을 선택한 다음 주소, 포트, 인증 항목을 입력하세요. 프로토콜에 따라 각 매개변수의 의미가 달라집니다. 유형이 다르면 비밀번호, 식별자, 암호화 방식, 전송 옵션을 서로 바꿔 쓸 수 없습니다. 주소 항목에는 일반적으로 서버 주소만 입력하며 웹 경로를 임의로 덧붙이지 마세요. 포트에는 제공된 숫자를 입력하세요. 저장하기 전에 원래 안내와 각 항목을 대조하고, 특히 대소문자, 마지막 문자, 숫자가 정확한지 확인하세요. ‘비슷해 보인다’는 이유로 같다고 판단하지 마세요.

정보에 TLS, 서버 이름, 경로 또는 다른 전송 매개변수가 포함되어 있다면 해당 항목에 빠짐없이 입력하세요. 서버 이름이 연결 주소와 같지 않을 수 있으며, 경로는 임의로 덧붙이는 설명 문구가 아닙니다. 특정 항목을 확신할 수 없다면 모든 스위치를 번갈아 시도하지 말고 정보 출처에 다시 확인하세요. 매개변수가 빠짐없이 제공되고 수가 적다면 수동 추가가 적합합니다. 표준 공유 정보가 있다면 가져오기를 이용해 입력 오류를 줄일 수 있지만, 가져온 뒤에도 유형과 주요 항목이 예상과 일치하는지 확인해야 합니다.

구독 가져오기와 첫 업데이트

구독을 추가할 때는 해당 Subscribe 유형의 입력란에 전체 주소를 넣고 저장한 뒤 업데이트를 실행해 서버 목록이 표시되는지 확인하세요. 이름은 출처를 구분하는 데 사용할 수 있지만 연결 매개변수는 아닙니다. 목록이 비어 있다면 주소 저장 실패, 요청 실패, 응답 내용을 해석하지 못한 경우 중 무엇인지 먼저 확인하세요. 원인에 따라 해결 방법이 다릅니다. 브라우저에서 주소가 웹페이지로 열린다고 해서 클라이언트에서 사용할 수 있는 구독 내용이 반환되는 것은 아닙니다. 계정 로그인 페이지나 오류 안내 페이지일 수도 있습니다.

구독을 가져온 뒤 목록에서 서버 하나를 선택하고 다음 장의 연결 확인을 진행하세요. 다음 업데이트에서 변경 내용이 덮어써질 수 있으므로 구독으로 생성된 항목을 곧바로 하나씩 편집하지 마세요. 별도로 조정해야 한다면 항목의 출처와 업데이트 동작을 먼저 확인하고 원래 구독을 보존한 뒤, 직접 만든 사본에는 구분하기 쉬운 이름을 붙이세요. 구독 업데이트는 주로 서버 정보를 새로 고치는 작업이며 현재 Config의 규칙 파일을 교체하는 작업과 같지 않습니다. 목록 관리와 라우팅 규칙 관리는 별개의 작업입니다.

가져오기에 실패해도 기존 상태 유지

업데이트에 실패했다고 기존 구독을 곧바로 삭제할 필요는 없습니다. 기존 목록은 보존한 채 주소가 완전한지, 서비스 계정이 여전히 유효한지, 현재 네트워크에서 구독 내용을 가져올 수 있는지 확인하세요. 이전에는 정상이었는데 갑자기 실패했다면 마지막으로 업데이트에 성공한 시점과 최근 변경 사항을 기록한 뒤 서비스 제공처의 상태 안내를 확인하세요. 요청을 반복해도 형식 오류가 해결되는 것은 아니며 오히려 접근 제한이 생길 수 있습니다. 구독 해석 실패 또는 목록이 비어 있을 때의 점검 목록을 따라 원인을 하나씩 확인한 뒤 주소를 교체할지 결정하세요.

먼저 모드를 확인한 뒤 규칙 해석

Global Routing의 Config, Proxy, Direct는 주요 라우팅 방식을 결정합니다. Config는 현재 구성 파일의 규칙에 따라 트래픽을 분기하고, Proxy는 클라이언트가 처리하는 연결을 선택한 서버로 전달하며, Direct는 직접 연결로 처리합니다. 여기서 ‘모든 연결’이라는 표현은 라우팅 모드의 의미이지 기기의 모든 시스템 동작을 절대적으로 설명하는 말은 아닙니다. 시스템의 기본 동작, 기존 연결, 다른 네트워크 설정도 결과에 영향을 줄 수 있습니다. 문제를 확인할 때는 이미 열려 있는 페이지만 보지 말고 새 요청을 보내 테스트하세요.

Config는 구성 모드를 가리키는 인터페이스 용어입니다. 하단의 구성 관리 메뉴와 Global Routing 옵션에 모두 표시되지만 두 곳의 역할은 다릅니다. 전자는 파일을 관리하고 후자는 규칙을 적용할지 선택합니다. 파일을 가져왔다고 현재 모드가 Config인 것은 아니며, 모드가 Config라고 해서 방금 가져온 파일이 이미 적용된 것도 아닙니다. 규칙을 수정하기 전에 두 항목의 상태를 각각 확인하세요. 규칙이 작동하지 않는 것처럼 보이는 경우 실제로는 Proxy 모드이거나 방금 편집한 파일이 적용되지 않은 경우가 많습니다.

규칙은 어떤 항목으로 구성되나요?

일반적인 규칙은 유형, 일치 조건, 정책으로 구성되며 영문 쉼표로 구분합니다. DOMAIN은 전체 도메인과 일치하고, DOMAIN-SUFFIX는 도메인 접미사와 해당 하위 도메인에 일치하며, DOMAIN-KEYWORD는 도메인에 포함된 키워드를 기준으로 일치합니다. IP-CIDR과 IP-CIDR6은 각각 해당 주소 범위를 나타내고 GEOIP는 지리적 주소 데이터베이스를 이용해 판단합니다. PROXY, DIRECT, REJECT 정책은 각각 프록시 전달, 직접 연결, 거부를 의미합니다. 정책 이름은 실제 구성의 의미와 일치해야 하며 규칙의 키워드를 한국어 설명으로 대체할 수 없습니다.

[General]
bypass-system = true

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

위 내용은 규칙을 읽기 위한 최소 예시이며 모든 네트워크 환경에 적합한 완성된 구성은 아닙니다. 예시 도메인은 문법 설명용이며 서버 연결 테스트에 사용할 수 없습니다. 사설 네트워크 주소의 직접 연결 규칙은 주소 범위 일치 방식을 보여줍니다. GEOIP 판정은 데이터베이스에 의존하며 특정 대상의 상태를 확인하는 방법을 대신하지 않습니다. 실제로 적용하기 전에 필요한 서비스, 로컬 네트워크 리소스, 기본 정책을 확인하고 원래 구성 파일을 복사해 두세요. 사본에서 항목별로 조정하고 유일하게 사용할 수 있는 파일을 바로 덮어쓰지 마세요.

위에서 아래로 확인하며 처음 일치한 규칙에서 종료

규칙은 위에서 아래 순서로 확인합니다. 일치하는 항목이 나오면 해당 정책을 적용하고 더 정밀할 것으로 보이는 아래 규칙을 계속 찾지 않습니다. 따라서 특정 도메인에 적용할 예외는 그 규칙을 덮을 수 있는 넓은 범위의 규칙보다 위에 배치해야 합니다. FINAL은 앞선 규칙에 하나도 일치하지 않을 때 적용되는 기본 정책이므로 보통 마지막에 둡니다. FINAL을 앞에 두면 뒤쪽 항목이 예상대로 평가되지 않습니다. DOMAIN-KEYWORD는 예상보다 넓은 범위에 일치할 수 있으므로 다른 도메인까지 잘못 포함하지 않는지 확인하세요. 명확한 접미사로 표현할 수 있다면 조건을 불필요하게 넓히지 마세요.

도메인 규칙과 주소 규칙은 서로 다른 정보를 기준으로 판단합니다. 대상은 먼저 도메인으로 나타난 뒤 주소로 해석됩니다. 일부 규칙 판단에는 DNS가 관여할 수 있습니다. 대상이 최종적으로 특정 주소에 연결됐다는 이유만으로 주소 규칙이 먼저 일치했다고 단정할 수는 없습니다. 실제 요청 기록, 규칙 순서, 해석 결과를 함께 확인하고 주소 소속을 한 번 조회하는 것으로 결론 내리지 마세요. IPv6 환경에서는 해당 주소 규칙도 고려해야 합니다. IPv4 범위만 추가했다고 같은 종류의 연결이 모두 포함되는 것은 아닙니다.

완전한 연결 확인에 필요한 항목

정보를 가져온 뒤 Home에서 보유 중인 서버 하나를 선택하고 Global Routing 모드를 확인한 다음 연결을 시작해 필요한 권한을 승인하세요. 상태가 안정되면 새 요청을 보내 실제 접속을 확인합니다. 완전한 확인에는 최소 네 가지 항목이 포함되어야 합니다. 스위치가 예상한 상태인지, 서버를 올바르게 선택했는지, 대상에서 응답을 받는지, 요청에 적용된 정책이 예상과 일치하는지 확인하세요. 시스템 VPN 표시만으로는 해당 네트워크 구성이 작동 중이라는 점만 알 수 있습니다. 원격 서버 인증 성공이나 모든 웹사이트와 앱의 접속 가능 여부까지 증명하지는 않습니다.

첫 테스트에서는 정상 결과를 판단할 수 있는 익숙한 대상을 선택하고 여러 페이지를 한꺼번에 열지 마세요. 먼저 일반 요청 하나를 확인한 다음 프록시 처리가 필요한 요청을 테스트하세요. 로컬 네트워크 리소스를 사용하는 경우에는 별도로 확인합니다. 대상마다 적용되는 정책이 다를 수 있으므로 하나의 성공 결과가 모든 규칙이 올바르다는 뜻은 아닙니다. 나중에 같은 조건으로 다시 테스트할 수 있도록 당시 네트워크 환경, 서버, 모드를 기록하세요. 테스트 도중 구독을 자동 업데이트하거나 구성을 교체하지 마세요. 테스트 조건이 모르는 사이에 바뀔 수 있습니다.

Connectivity Test 결과 해석

Connectivity Test는 서버나 테스트 대상에 연결할 수 있는지 판단하는 데 도움이 되지만, 결과는 테스트 방식, 테스트 주소, 당시 네트워크 상태에 따라 달라집니다. 테스트에 성공했다고 모든 실제 사용이 정상이라는 뜻은 아니며, 실패했다고 모든 연결이 불가능하다는 뜻도 아닙니다. 하나의 참고 자료로 삼고 실제 접속 결과와 함께 판단하세요. 테스트 방식을 설정할 수 있다면 현재 사용하는 방식을 확인한 뒤 결과를 비교하세요. 서로 다른 테스트 방식의 소요 시간을 단순 비교해 순위를 매기거나 숫자 하나만으로 장기적인 안정성을 판단하지 마세요.

테스트는 통과했지만 웹페이지가 열리지 않는다면 특정 도메인, 요청 유형, 앱에서만 문제가 생기는지 먼저 확인하세요. 대상 서비스 자체, DNS, TLS, 규칙 일치, 원격 접속 제한이 모두 영향을 줄 수 있습니다. 모든 대상에서 실패한다면 서버 주소, 포트, 인증 매개변수, 기본 네트워크를 다시 확인하세요. 특정 앱에서만 문제가 나타나면 기존 연결을 완전히 종료한 뒤 다시 시도해 이전 세션이나 캐시를 새 모드의 결과로 오해하지 않도록 하세요. 한 앱의 연결을 지우려고 기기 전체 설정을 바로 초기화하지 마세요.

단계별로 문제 범위 좁히기

첫 번째 계층은 기본 네트워크입니다. 클라이언트 연결을 중지한 상태에서 기기가 정상적으로 인터넷에 접속하는지, 공용 네트워크 인증을 마쳤는지 확인하세요. 두 번째는 서버 연결입니다. 제어 가능한 조건에서 Proxy를 사용해 선택한 서버가 실제 요청을 처리할 수 있는지 확인합니다. 세 번째는 구성에 따른 트래픽 분기입니다. Proxy는 정상인데 Config에서 문제가 생긴다면 적용 중인 파일, 규칙 순서, 관련 해석 설정을 집중적으로 살펴보세요. 네 번째는 대상 자체입니다. 특정 대상만 계속 실패하고 같은 종류의 다른 요청은 정상이라면 클라이언트 탓으로만 돌리지 말고 대상 서비스 상태와 구체적인 오류를 확인하세요.

모드를 잠시 바꾸는 것은 문제를 찾기 위한 방법이지 최종 해결책이 아닙니다. 테스트가 끝나면 일상에 필요한 모드로 되돌리고 다시 확인하세요. Proxy와 Config의 결과가 다르다면 규칙 경로가 다를 수 있으며 DNS나 기존 연결이 원인일 수도 있습니다. 이 비교 결과 하나만으로 특정 규칙이 잘못됐다고 단정하지 마세요. Direct 비교도 직접 연결이 허용된 테스트 대상을 사용해야 합니다. 한 번에 한 가지 요소만 바꾸고 전후 결과를 기록해야 원인을 좁힐 수 있습니다. 서버, 모드, 네트워크를 동시에 바꿔 성공하더라도 무엇이 문제를 해결했는지 알 수 없습니다.

시간 초과, 이름 해석, 인증서 문제 구분

시간 초과는 예상한 시간 안에 필요한 응답을 받지 못했다는 뜻이지만, 어느 단계에서 응답이 사라졌는지는 알려주지 않습니다. 기본 네트워크, 포트, 대상 범위를 함께 확인하세요. 이름 해석 실패는 우선 도메인 해석 경로를 확인해야 한다는 신호입니다. 바로 인증 비밀번호를 바꾸지 마세요. 인증서 오류가 발생하면 기기 시간, 서버 이름, 서버 측 인증서 상태를 확인하세요. 검증을 끄면 연결의 신뢰 조건이 달라지므로 일반적인 문제 해결 방법으로 사용하지 마세요. 여러 고급 옵션을 무작정 조정하기보다 정보를 확인한 뒤 본인의 서비스 제공처에 서버 측 요구 사항을 문의하는 편이 안전합니다.

네트워크를 전환한 뒤에만 문제가 생긴다면 전환 방향과 연결을 다시 설정했을 때 복구되는지 기록하세요. 잠자기 후에만 발생한다면 깨어난 직후의 첫 요청과 이후 요청을 비교하세요. 안정적으로 재현되는 조건을 찾은 다음 관련 설정을 조정하세요. 처음부터 시스템 동작, 구독 형식, 규칙을 모두 다시 설정하지 마세요. 첫 연결 순서가 아직 불분명하다면 빠른 시작 안내로 돌아가 최소 절차를 다시 완료하세요. 고급 문제 분석은 반복 테스트가 가능한 기본 구성에서 시작해야 합니다.

통계는 어떤 계층의 트래픽을 보여주나요?

Data에서는 클라이언트가 관찰하는 트래픽과 연결 관련 정보를 확인할 수 있습니다. 구체적인 항목은 현재 앱 화면을 기준으로 합니다. 내용을 살펴보기 전에 통계 범위를 확인하세요. 현재 세션인지, 일정 기간 누적 기록인지, 특정 서버 관련 수치인지 확인해야 합니다. 범위가 다르면 직접 비교할 수 없습니다. 클라이언트에서 관찰한 데이터는 시스템 모바일 데이터 통계, 서비스 계정의 사용량, 대상 파일 크기와도 기준이 다릅니다. 수치가 일치하지 않더라도 먼저 범위와 단위를 확인하고 어느 한쪽이 잘못됐다고 단정하지 마세요.

웹페이지를 열면 본문, 이미지, 스크립트, 글꼴, 백그라운드 요청이 발생하므로 주소창에 URL이 하나 보인다고 연결도 하나라고 추정할 수 없습니다. 업로드와 다운로드는 동시에 발생할 수 있습니다. 콘텐츠를 읽는 중에도 기기는 요청과 프로토콜 데이터를 전송합니다. 페이지 새로 고침, 사전 로드, 앱 백그라운드 동기화도 통계에 영향을 줄 수 있습니다. 한 동작으로 발생한 변화를 확인하려면 먼저 동작 전 수치를 기록하고, 명확한 작업 하나를 실행한 다음 증가량을 확인하세요. 계속 늘어나는 총계만 보고 원인을 추측하지 마세요.

클라이언트 통계와 서비스 제공처의 정산은 다릅니다

서비스 제공처는 자체 요금 규칙, 집계 기간, 전송량 산정 기준으로 사용량을 계산할 수 있습니다. 클라이언트 기록은 관찰 가능한 연결 범위에 따라 달라집니다. 전송 오버헤드, 재시도, 집계 범위의 차이로 수치가 달라질 수 있습니다. 따라서 Data는 로컬 사용량 확인과 문제 해결에 참고할 수 있지만 서비스 계정의 정산 기준을 대신하지 않습니다. 앱을 일회성 구매해도 연결 서비스가 포함되지는 않습니다. 앱의 트래픽 기록으로 사용자의 서비스 용량이 추가되는 것도 아닙니다. 용량, 유효 기간, 계정 제한은 본인이 보유한 서비스 정보에서 확인하세요.

단일 테스트로 규칙 확인

특정 규칙을 확인하려면 먼저 현재 모드, 구성 파일, 테스트 시각을 기록한 뒤 대상 하나만 여세요. 현재 화면에서 요청 또는 연결 세부 정보를 확인할 수 있다면 비슷한 시각의 기록을 찾아 도메인, 주소, 정책 정보를 확인하세요. 한 페이지에서 여러 도메인에 요청할 수 있으므로 첫 번째 기록을 찾았다고 확인을 끝내지 마세요. 페이지의 주요 내용은 표시되지만 일부 리소스가 실패한다면 도메인마다 다른 정책이 적용됐을 수 있습니다. 페이지 전체에 너무 넓은 예외를 추가하지 말고 실패한 리소스를 해당 규칙과 대조하세요.

기록에서 예상한 정보가 보이지 않아도 신중하게 해석해야 합니다. 앱이 기존 연결을 재사용했거나 대상이 캐시를 사용했거나 현재 표시 범위에 해당 기록 유형이 포함되지 않았을 수 있습니다. 먼저 구분할 수 있는 새 요청을 보내고 필터와 기록 범위를 확인하세요. 반복 항목을 많이 만들려고 페이지를 계속 새로 고치지 마세요. 분석에 불필요한 잡음이 늘어납니다. 규칙 변경 전후를 비교하려면 두 시점을 각각 기록하고 같은 동작을 반복하세요. 새 구성을 적용했는지도 확인해야 같은 변수를 비교할 수 있습니다.

백그라운드 활동과 개인정보 보호

직접 웹을 탐색하지 않을 때도 트래픽이 변할 수 있습니다. 시스템 동기화, 메시지 수신, 미디어 사전 로드, 앱 백그라운드 작업이 계속 네트워크를 사용할 수 있습니다. 제어할 수 있는 다운로드와 동기화를 먼저 일시 중지하고 변화가 줄어드는지 살펴보세요. 수치가 늘어난다는 이유만으로 이상 동작이라고 판단하지 마세요. 특정 앱이 반복 실패 후 재시도하면 트래픽이 계속 증가할 수도 있습니다. 이때는 통계를 초기화하는 데 그치지 말고 오류 기록을 바탕으로 근본 원인을 확인하세요. 초기화는 관찰 시작점을 바꿀 뿐 연결 문제를 해결하거나 서비스 제공처의 기록을 초기화하지 않습니다.

요청 기록에는 방문한 도메인, 시각, 네트워크 주소, 인증 정보가 포함된 내용이 노출될 수 있습니다. 내보내거나 스크린샷을 찍기 전에 구독 매개변수, 전체 경로, 개인정보가 들어 있는지 확인하고 문제에 필요한 최소한의 부분만 남기세요. 문제 해결이 끝나면 개인정보 보호 기준에 따라 더 이상 필요하지 않은 기록을 정리하세요. 더 많은 정보를 얻으려고 HTTPS 복호화를 임의로 활성화하지 마세요. 일반적인 규칙 확인에는 대상, 시각, 정책 같은 메타데이터를 우선 사용하세요. 하단 메뉴별 역할은 Home, Config, Data, Settings 인터페이스 용어 안내에서 확인할 수 있습니다.

안정적인 기준 상태에서 설정 시작

Settings는 앱 동작을 조정하는 메뉴이지 모든 옵션을 켜면 연결이 좋아지는 기능이 아닙니다. 처음 사용할 때는 검증된 기준 상태를 유지하세요. 서버를 명확히 선택하고, 모드를 고정하고, 출처를 확인할 수 있는 구성 파일과 반복 테스트가 가능한 대상을 준비합니다. 이후에는 한 번에 한 종류의 설정만 변경하고 기존 값과 변경 이유를 기록하세요. 앱 인터페이스는 실제 버전에 따라 달라질 수 있으므로 현재 화면에 표시되는 항목을 기준으로 합니다. 안내에서 본 옵션이 보이지 않는다면 이름이 비슷한 항목으로 대체하지 말고, 알 수 없는 구성으로 억지로 추가하지도 마세요.

어떤 설정은 다음 연결에 영향을 주고, 어떤 설정은 현재 요청에 영향을 주며, 표시 방식이나 업데이트 동작만 바꾸는 설정도 있습니다. 저장한 뒤 연결을 다시 설정해야 하는지 판단하고 새 요청으로 결과를 확인하세요. 화면의 스위치가 바뀌었다고 네트워크가 새 조건을 적용했다고 단정할 수는 없습니다. 구성 파일에 따른 설정은 파일 자체에서 비롯될 수도 있습니다. 문제를 확인할 때 현재 파일과 앱 설정을 함께 살펴봐야 한쪽 메뉴만 변경한 뒤 다른 곳의 기존 설정이 영향을 주는 일을 막을 수 있습니다.

On Demand는 먼저 실행 조건을 명확히 설정

On Demand는 설정한 조건에 따라 연결을 자동으로 시작하는 기능입니다. 사용 전에 어떤 네트워크 환경에서 연결할지, 어떤 조건에서는 연결을 유지하지 않을지 등 원하는 동작을 명확히 정한 뒤 앱에서 실제로 제공하는 조건을 설정하세요. 서버를 항상 사용할 수 있게 해 주는 기능도 아니며 인증 실패를 해결하지도 않습니다. 수동 연결이 정상적으로 작동하는지 확인하기 전에는 자동 동작을 켜지 마세요. 그렇지 않으면 재시도와 네트워크 전환이 겹쳐 조건 설정 문제인지 서버 문제인지 판단하기 어려워집니다.

활성화한 뒤에는 조건을 충족하는 상황과 충족하지 않는 상황을 각각 테스트하고 실제 결과가 예상과 일치하는지 확인하세요. 수동으로 연결을 끊은 뒤 다시 연결되는 것은 연결 해제 조작이 작동하지 않은 것이 아니라 자동 조건이 여전히 충족된 결과일 수 있습니다. 잠시 중지하려면 자동 연결 설정도 함께 확인하세요. 기존 네트워크를 나갔다가 돌아오는 상황, 기기를 잠자기 상태에서 깨우는 상황을 각각 테스트할 수 있습니다. 네트워크 이름을 조건으로 사용한다면 이름은 같지만 실제 환경은 다른 경우도 고려하세요. 이름만으로 신뢰할 수 있는 네트워크인지 판단하지 마세요.

구독 업데이트 설정의 범위

현재 화면에 앱을 열 때 구독을 업데이트하는 설정이 있다면 사용 빈도에 따라 활성화 여부를 정하세요. 서버 목록을 새로 고치는 데 도움이 되지만, 업데이트에는 네트워크 연결과 유효한 구독 주소가 필요합니다. 앱을 연 뒤 업데이트에 실패해도 캐시된 모든 서버가 즉시 사용할 수 없게 되는 것은 아닙니다. 목록 새로 고침과 기존 연결을 별도로 테스트하세요. 자동 업데이트는 서비스 제공처의 변경 사항을 계속 감시하는 기능이 아니며, 매번 가장 적절한 시점에 최신 정보를 가져온다고 보장하지 않습니다.

업데이트 동작을 변경하기 전에 구독으로 생성된 항목이 어떻게 처리되는지 확인하세요. 항목의 이름, 순서, 연결 정보를 직접 변경했다면 다음 업데이트에서도 해당 변경 사항이 유지되는지 확인해야 합니다. 중요한 변경 내용은 별도로 기록하세요. 새로 고침으로 덮어써질 수 있는 항목에만 남겨 두지 마세요. 업데이트에 실패하면 사용 가능한 상태를 먼저 보존한 뒤 원인을 확인하세요. ‘자동’이라고 해서 실패 안내를 무시해도 되는 것은 아닙니다. 구독 수동 업데이트와 앱을 열 때 자동 업데이트 안내를 함께 참고하세요. 메뉴 위치는 실제 앱 화면을 기준으로 합니다.

DNS와 연결 옵션을 한꺼번에 바꾸지 마세요

DNS는 도메인을 주소로 변환하며 요청 경로와 결과가 이후의 규칙 일치 및 대상 연결에 영향을 줄 수 있습니다. DNS 설정을 바꾸기 전에 같은 도메인에서 지속적으로 이름 해석에 실패하는 등 문제가 실제로 해석 과정과 관련 있는지 확인하세요. 기본 네트워크와 서버 연결은 정상인지 검증되어 있어야 합니다. 인터넷에서 본 DNS 주소를 확인 없이 한꺼번에 추가하지 마세요. 출처, 연결 가능 여부, 설정의 의미가 불분명한 상태에서 주소를 추가하면 변수만 늘어납니다. 기존 설정을 보존하고 같은 대상을 사용해 변경 전후 결과를 비교하세요.

TLS, 전송, IPv6, 연결 재사용과 관련된 옵션도 실제 서비스 요구 사항에 따라 조정해야 합니다. 기능을 활성화하려면 네트워크와 서버 측에서 해당 기능을 지원해야 합니다. 옵션을 많이 켠다고 설정이 완전해지는 것은 아닙니다. 연결 문제가 발생하면 먼저 서비스 매개변수를 다시 확인한 뒤 고급 옵션을 살펴보세요. 겉으로 연결에 성공한 것처럼 보이도록 인증서 검증을 끄지 마세요. 로그 상세 수준도 필요한 만큼만 사용하세요. 문제 해결에 필요한 정보를 모은 뒤에는 일상 사용에 적합한 상태로 되돌리고 내보낸 기록을 안전하게 관리하세요.

세 가지 업데이트를 구분해 관리

일상 관리에는 서로 다른 세 가지 작업이 포함됩니다. App Store에서 앱 업데이트, 구독의 서버 목록 업데이트, Config의 구성 파일 업데이트입니다. 앱 업데이트는 클라이언트 기능과 동작을 바꾸고, 구독 업데이트는 서비스 정보를 바꾸며, 구성 업데이트는 규칙과 관련 설정을 바꿉니다. 한 번의 문제 해결 과정에서 이 세 가지를 동시에 진행하지 마세요. 업데이트 후 문제가 생겼을 때 어떤 계층이 바뀌었는지 알아야 전후 차이를 비교하고 올바른 정보 출처에 문의할 수 있습니다.

업데이트 전에 현재 연결이 중요한 작업에 사용 중인지 확인하고 로컬 변경 사항을 저장한 뒤 현재 사용하는 구성 이름을 기록하세요. 업데이트 후에는 목록과 적용된 파일을 확인하고 실제 접속 테스트를 진행하세요. 다른 설정을 곧바로 조정할 필요는 없습니다. 구성 출처에서 업데이트를 가져오면 기존 내용이 덮어써질 수 있고, 구독 업데이트로 항목이 달라질 수도 있습니다. 중요한 예외 규칙과 수동 매개변수는 별도의 안전한 사본에 보관하세요. 앱 업데이트 내역은 App Store 페이지를 기준으로 확인하고 온라인에 떠도는 버전 번호만 보고 업데이트 필요 여부를 판단하지 마세요.

백업은 내용과 출처를 함께 보존해야 합니다

백업할 때는 파일만 저장하지 말고 출처, 사용 환경, 직접 수정한 항목도 확인하세요. 원본 구성, 테스트용 사본, 일상 사용 사본을 짧은 이름으로 구분하고 차이점은 개인 기록에 적어 둘 수 있습니다. 파일을 내보낸 뒤 구독 주소, 서버 인증 항목, 기타 민감한 정보가 포함되어 있는지 확인하고 저장 위치를 정하세요. 백업 파일을 일반 문서처럼 공개 공유하지 마세요. 대부분이 규칙이더라도 인증 정보가 포함된 주소 한 줄만으로 정보가 유출될 수 있습니다.

백업의 유효성은 내보내기에 성공했는지가 아니라 실제로 복원할 수 있는지에 달려 있습니다. 기기를 이전하기 전에 파일을 읽을 수 있는지, 출처 주소에서 정보를 가져올 수 있는지, 직접 입력한 정보가 충분한지 확인하세요. 본인이 관리하는 안전한 위치에 저장하고 복원 순서를 명확히 정해 두세요. 먼저 앱을 받은 뒤 권한을 설정하고, 서비스 정보와 구성을 복원한 다음 연결을 확인합니다. 동기화 기능을 사용한다면 실제 동기화 범위도 확인하세요. 같은 파일 이름이 보인다는 이유로 모든 설정, 기록, 인증 정보가 일치한다고 단정하지 마세요.

새 기기에서 최소한으로 복원하는 순서

새 기기에서는 원래 구매한 계정으로 App Store에서 앱을 다시 받으세요. 시스템 요구 사항과 구매 가능 여부는 App Store 페이지의 안내를 기준으로 합니다. 앱을 연 직후 모든 고급 옵션을 복사하지 마세요. 먼저 사용할 수 있는 서버 하나나 본인의 구독을 복원하고, 모드를 명확히 선택한 뒤 시스템 권한을 승인하세요. 최소 절차가 정상 작동한 다음 일상적인 규칙과 자동 연결 조건을 가져옵니다. 단계별로 복원하면 문제가 생겼을 때 마지막으로 추가한 항목에서 원인을 찾기 쉽습니다. 모든 설정을 한꺼번에 이전한 뒤 알 수 없는 상태를 마주하는 일을 줄일 수 있습니다.

이전 기기에서 연결에 성공했더라도 새 기기에서는 다른 네트워크에서 같은 결과가 나오지 않을 수 있습니다. 로컬 네트워크 주소, 네트워크 인증, 기기 시간, 자동 연결 조건을 다시 확인하세요. 새 기기가 안정적으로 작동하는 것을 확인한 뒤 이전 기기에서 더 이상 필요하지 않은 민감한 정보를 정리하세요. 이전 검증을 마치기 전에 유일한 사본을 삭제하지 마세요. 구매 항목 복원에 관한 질문은 구매 항목 복원 안내를 확인하세요. 가격과 일회성 구매 범위에 관한 자주 묻는 질문은 가격과 일회성 구매 안내를 참고하세요. 계정 문제를 해결하려고 클라이언트 규칙을 변경하지 마세요.

문제가 생기면 가장 최근 변경부터 되돌리기

관리 중 문제가 생겼다면 먼저 ‘마지막으로 정상 작동했을 때의 조건은 무엇이었나?’를 확인한 다음 ‘그 뒤 무엇을 변경했나?’를 살펴보세요. 구성 파일만 수정했다면 백업 파일로 되돌립니다. 구독만 업데이트했다면 항목의 매개변수와 선택 상태를 확인하세요. On Demand를 방금 활성화했다면 자동 동작을 잠시 중지하고 수동으로 테스트하세요. 되돌리는 목적은 비교할 수 있는 기준 상태를 복구하는 것이지 오래된 설정을 계속 사용하라는 뜻이 아닙니다. 차이를 확인한 뒤 해당 항목만 처리하고, 문제가 생길 때마다 모든 구성을 삭제하고 처음부터 시작하지 마세요.

변경 목적, 수정 항목, 확인 결과를 간단한 개인 관리 기록으로 남기세요. 비밀번호나 전체 구독 주소는 기록하지 마세요. 문제가 장기간 재현되지 않았다면 발생 조건이 아직 명확하지 않다고 그대로 적으세요. 결론을 내기 위해 규칙을 계속 추가하지 마세요. 추가 안내가 필요하면 블로그 안내 목록에서 규칙, 구독, 구매 관련 주제를 확인하세요. 첫 연결을 다시 진행하고 싶다면 사용 안내를 참고하세요. 체계적인 매뉴얼의 목적은 모든 옵션을 한 번씩 설정하는 것이 아니라 각 작업에 근거를 두고 결과를 설명할 수 있도록 돕는 것입니다.