Shadowrocket 사용법 완벽 가이드

01 / APP STORE

정품 구매 및 구입 내역 확인

먼저 앱이 정품인지 확인한 뒤 구매하세요. Shadowrocket은 Apple 플랫폼용 유료 클라이언트이며, App Store에서만 구매할 수 있습니다. 사이트의 앱 구매 안내에서 App Store 링크, 정품 확인 방법, 구입 항목 복원 안내를 확인할 수 있습니다. 이 장에서는 설정을 가져오기 전에 이러한 항목을 확인해야 하는 이유를 설명합니다. 앱 구매와 서버 준비는 별개의 과정입니다. App Store 결제가 완료되어도 앱 사용 자격만 확보된 것이며, 연결할 서버까지 제공되는 것은 아닙니다.

개발자, 아이콘, 앱 ID 확인

App Store에서 검색할 때 ‘Shadowrocket’과 비슷한 이름만 보고 판단하지 마세요. 제품 상세 페이지에서 앱 이름 Shadowrocket, 개발자 Shadow Launch Technology Limited, 제품 링크의 앱 ID 932747118을 확인하세요. 아이콘은 사이트 상단에 표시된 공식 아이콘과 일치해야 합니다. 특히 검색 결과에 비슷한 이름의 앱이 있다면 결과 목록에서 바로 결제하지 말고 상세 페이지를 열어 이름, 아이콘, 개발자를 모두 확인하세요.

앱 ID는 동일한 제품인지 확인하는 중요한 기준입니다. 제품 페이지 주소 끝의 id932747118은 이 매뉴얼에서 다루는 앱을 가리킵니다. App Store에 표시된 설명, 호환성, 구매 정보와 업데이트 내역은 현재 제품 페이지를 기준으로 확인하세요. 앱 표시 정보와 시스템 설정은 실제 기기 상태에 따라 달라질 수 있으므로, 이 매뉴얼은 특정 버전 번호로 확인 절차를 대신하지 않습니다. 개발자 이름이나 앱 ID가 다르면 앱 구매 안내로 돌아가 올바른 링크인지 다시 확인하세요.

일회성 구매에 포함되는 범위

Shadowrocket은 일회성 구매 방식이며, 결제 금액과 통화, 구매 가능 여부는 App Store 페이지에 표시된 정보를 기준으로 확인하세요. 특히 클라이언트 일회성 구매 ≠ 서버 이용 요금제라는 점을 구분해야 합니다. 앱은 서버 정보를 읽고 연결을 설정하며 라우팅 규칙을 적용합니다. 서버 주소, 인증 정보, 구독 링크는 사용하는 서비스 제공업체에서 받아야 합니다. 앱 구입 내역만으로 구독의 유효성을 판단할 수 없으며, 구독이 만료되었다고 해서 클라이언트를 다시 구매해야 하는 것은 아닙니다.

결제 전에 현재 App Store에서 사용하는 계정을 확인하세요. 나중에 앱을 다시 설치하거나 기기를 바꿀 때는 원래 구매에 사용한 계정의 구입 내역을 확인해야 합니다. 기기의 다른 기능에 사용하는 계정과 App Store 구매 계정은 서로 다를 수 있으므로, 기기 설정 상단에 표시된 이름만으로 구매 계정을 판단하지 마세요. App Store 버튼의 표시가 예상과 다르면 먼저 구입 내역과 계정을 확인한 뒤 다음 단계를 결정하세요. 복원 여부를 시험하려고 결제를 반복하지 마세요.

기기 호환성과 복원 범위

이 매뉴얼에서는 주로 iPhone과 iPad를 다룹니다. Mac, Apple TV, Apple Vision과의 호환성도 같은 App Store 페이지에서 확인할 수 있으며, 시스템 요구 사항과 구매 가능 여부는 App Store 페이지에 표시된 정보를 기준으로 합니다. 한 기기에서 다운로드할 수 있다는 이유만으로 다른 기기에서도 요구 사항을 충족한다고 단정하지 마세요. 기기를 바꾸기 전 대상 기기의 호환성, App Store 계정, 기존 구입 내역을 각각 확인하세요.

앱 복원과 설정 복원은 별개로 확인해야 합니다. 앱을 다시 설치해도 기존 서버, 구독, 규칙 파일이 자동으로 복원되는 것은 아닙니다. 앱을 삭제하기 전에 필요한 설정을 기록하고 구성을 안전하게 보관하세요. 다시 실행한 뒤에는 Home과 Config에서 실제로 복원된 내용을 확인해야 합니다. 가족 공유 적용 여부, 현재 스토어에서의 제공 상태, App Store에서 요구하는 인증 절차는 페이지와 시스템 안내를 따르세요. 한 번 복원에 성공했다고 해서 모든 계정과 기기에서 동일하게 적용된다고 볼 수는 없습니다.

이 장을 마치면 다음 세 가지를 확인할 수 있어야 합니다. 앱 정보가 정품과 일치하는지, 구매 기록이 어느 App Store 계정에 연결되어 있는지, 서버 정보가 어디에 저장되어 있는지입니다. 하나라도 확실하지 않다면 구독을 가져오기 전에 먼저 확인하세요. App Store 표시와 재설치에 관한 내용은 구입 항목 복원 안내에서 확인할 수 있습니다. 검색 결과에서 정품을 구별하는 방법은 정품 확인을 위한 세 가지 기준을 참고하세요.

02 / FIRST LAUNCH

첫 실행과 시스템 권한

처음 실행하면 먼저 각 화면의 역할을 확인하세요. 모든 설정을 바로 변경할 필요는 없습니다. Home에서는 서버를 확인하고 연결하며, Config에서는 규칙 구성을 관리하고, Data에서는 트래픽을 살펴보며, Settings에서는 클라이언트 옵션을 조정합니다. 기기, 표시 언어, 앱 상태에 따라 항목의 위치가 다를 수 있으므로 특정 버튼의 좌표만으로 찾지 마세요. 먼저 현재 화면을 확인한 뒤 추가, 전환, 삭제 작업을 진행하세요.

VPN 구성 추가 권한 이해하기

처음 연결을 시도할 때 시스템에서 VPN 구성 추가를 허용할지 물을 수 있습니다. 이는 클라이언트가 시스템 네트워크 연결을 설정하는 데 필요한 권한이며, 구독을 성공적으로 가져왔다는 뜻은 아닙니다. 직접 연결 스위치를 켠 뒤 시스템 안내를 읽고 요청한 앱이 Shadowrocket인지 확인한 다음 안내에 따라 인증하세요. 허용하지 않고 취소하면 앱으로 돌아왔을 때 연결 스위치가 켜진 상태로 유지되지 않을 수 있습니다. 이때는 서버 암호를 바꾸거나 같은 구독을 다시 가져오기 전에 권한이 완료되었는지 확인하세요.

시스템에 저장된 VPN 구성과 Home의 서버 목록은 서로 다른 항목입니다. VPN 구성은 시스템이 연결 기능을 사용할 수 있도록 하고, 서버 목록은 연결 대상과 프로토콜 매개변수를 제공합니다. 시스템 VPN 구성을 삭제해도 서버가 삭제되는 것은 아니며, 서버를 삭제해도 시스템에 저장된 구성이 반드시 제거되는 것은 아닙니다. 문제를 해결할 때는 먼저 어느 항목을 조정해야 하는지 구분하세요. ‘권한 다시 설정’을 하려다 ‘서버 전체 삭제’로 이어져 문제 범위를 넓히지 않도록 주의하세요.

카메라, 클립보드, 로컬 콘텐츠 사용 조건

Scan QR Code로 QR 코드를 스캔하면 시스템에서 카메라 권한을 요청할 수 있습니다. 실시간 스캔이 필요할 때만 이 권한을 사용합니다. 권한을 거부했다면 시스템 설정에서 Shadowrocket의 카메라 권한을 확인하거나, 텍스트 정보가 있다면 수동으로 추가할 수 있습니다. 아직 연결을 시도하지 않았다면 카메라 권한 문제를 서버 장애로 판단하지 마세요. QR 코드에 전체 인증 정보가 포함될 수 있으므로 스캔 전에 출처를 확인하고, 스캔 후에도 가져온 항목의 유형과 주소를 확인하세요.

클립보드에서 구성을 가져오기 전에 복사한 내용이 전체 링크 또는 구성 텍스트인지 확인하세요. 웹페이지 제목이나 설명 문단, 중간에 잘린 주소를 복사하면 안 됩니다. 붙여넣기 안내가 표시되는지는 현재 작업과 시스템 동작에 따라 다르므로 화면의 안내를 따르세요. 예상한 항목이 추가되지 않으면 원본 정보의 형식을 다시 확인하세요. 가져오기를 여러 번 누른 뒤 추가에 성공했다고 단정하지 마세요. Home이나 Config에 실제로 새 항목이 표시되는지 확인해야 합니다.

처음 사용할 때 확인 가능한 기준 만들기

처음 설정할 때는 테스트 대상을 하나로 정하는 것이 좋습니다. 직접 유효성을 확인한 서버 정보 하나를 추가하고, 현재 Global Routing 설정을 기록한 다음 연결 스위치를 켜세요. 이 단계에서는 DNS, On Demand, 복잡한 규칙을 동시에 바꾸지 마세요. 연결에 실패해도 권한, 서버 매개변수, 기본 네트워크 중 어디에서 문제가 생겼는지 범위를 좁힐 수 있습니다. 한 번에 하나씩만 변경하는 것이 이후 모든 문제 해결의 기본 원칙입니다.

기기에 다른 VPN 구성이 있다면 연결하기 전에 시스템에서 현재 어느 항목이 활성화되어 있는지 확인하세요. 여러 연결 설정이 서로 영향을 줄 수 있습니다. 시스템 설정의 연결 상태와 앱의 스위치를 함께 확인하세요. 상태 표시줄의 아이콘만으로 대상 웹사이트가 예상한 정책에 따라 연결되었다고 판단할 수는 없습니다. 시스템과 앱에서 스위치를 빠르게 반복해서 전환하지 마세요. 연결과 해제, 화면 갱신이 겹치면 어떤 조작이 결과를 만들었는지 파악하기 어렵습니다.

첫 권한 설정을 마친 뒤 Home으로 돌아가 서버가 남아 있는지, 올바른 항목이 선택되어 있는지 확인한 다음 다음 장으로 이동하세요. 스위치가 곧바로 꺼지면 권한 안내가 표시되었는지, 시스템 구성이 있는지, 구체적인 오류가 표시되었는지 기록하세요. ‘전혀 작동하지 않음’이라고만 적는 것보다 실제 현상을 기록하는 편이 문제 해결에 도움이 됩니다. 첫 사용 절차를 빠르게 진행하려면 사용 튜토리얼을 참고하세요. 권한과 시스템 상태에 관한 질문은 FAQ에서 확인할 수 있습니다. 이 장의 목표는 스위치가 켜진 것을 보는 데 그치지 않고 권한의 용도를 이해하는 것입니다.

03 / SERVER & SUBSCRIBE

서버 추가 및 구독 가져오기

가져오기 전에 보유한 정보의 유형부터 확인하세요. 단일 서버의 전체 매개변수인지, 서버 하나의 공유 링크인지, 구독 링크인지, 규칙 구성 파일인지 구분해야 합니다. 모두 텍스트처럼 보이더라도 서로 다른 대상이므로 같은 입력란에 넣을 수 없습니다. 서버 정보는 연결 대상을 지정하고, 구독은 여러 서버 항목을 가져와 업데이트하며, 규칙 구성은 요청을 어떻게 라우팅할지 결정합니다. 이 매뉴얼은 본인이 사용할 구독이나 서버 정보를 이미 보유하고 있다는 전제로 설명합니다. 관련 정보는 이용 중인 서비스 제공업체에서 받아야 합니다.

서버를 직접 추가할 때 매개변수 입력하기

Home에서 추가 메뉴를 열고 Add Server로 이동한 뒤 Type을 선택하고 해당 프로토콜에 필요한 항목을 입력하세요. 유형이 잘못되면 주소와 암호가 맞아 보여도 예상한 연결을 만들 수 없습니다. 서버 주소에는 주소만 입력하고 포트는 제공된 값 그대로 입력하세요. 암호, 사용자 ID, 암호화 방식, 전송 설정, TLS 매개변수도 원본 정보에 맞춰 작성해야 합니다. 메모는 항목을 구별하기 위한 것으로, 서버 주소 대신 사용할 수 없습니다.

Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard, Hysteria2는 입력 항목이 서로 다르며 모든 프로토콜에 적용되는 공통 매개변수 조합은 없습니다. 낯선 항목이 보이면 다른 서버의 값을 복사하지 말고 정보 출처를 확인하세요. 특히 연결 주소, TLS에 사용하는 서버 이름, 전송 계층 Host를 구분해야 합니다. 이 값들은 서로 다를 수 있으며 각자 다른 역할을 하므로, ‘값을 통일한다’는 이유로 모두 같은 내용으로 바꾸지 마세요.

구독 가져오기 및 업데이트 후 확인

구독을 가져오려면 추가 화면에서 Subscribe 유형을 선택하고 전체 구독 링크를 해당 주소 입력란에 넣은 다음 알아보기 쉬운 이름을 지정하세요. 저장한 뒤 불러오기가 끝날 때까지 기다리고 Home으로 돌아가 구독 그룹이 생성되었는지, 그룹 안에 서버가 표시되는지 확인하세요. 그룹 이름만 있고 사용할 수 있는 항목이 없다면 가져오기가 완료된 것이 아닙니다. 이후 연결을 시도하기 전에 링크가 완전한지, 응답이 정상인지, 구독 콘텐츠가 유효한지 확인하세요.

구독 링크에는 접근 인증 정보가 포함될 수 있습니다. 앞뒤 공백, 줄바꿈, 메신저에서 잘린 내용도 불러오기에 영향을 줍니다. 브라우저에서 페이지가 열린다고 해서 그 내용이 클라이언트에서 읽을 수 있는 구독 형식이라는 뜻은 아닙니다. 로그인 페이지, 일반 안내 페이지, 오류 메시지가 표시되면 원본 링크의 용도를 다시 확인하세요. 반환된 텍스트를 억지로 서버 매개변수에 나눠 입력하지 말고, 다른 사람에게 판단을 맡기겠다며 전체 링크를 공개하지도 마세요.

구독을 업데이트하면 원격 콘텐츠를 다시 읽으므로 항목 이름, 개수, 순서가 달라질 수 있습니다. 업데이트 후에는 현재 선택한 서버가 여전히 있는지 확인하세요. 업데이트가 끝났다는 표시만 보고 연결 대상이 그대로라고 단정하지 마세요. 직접 입력한 매개변수도 기록해 두어 임시 수정 내용을 구독의 영구 설정으로 오해하지 않도록 하세요. 메모와 구성을 장기간 유지해야 한다면 업데이트가 해당 내용을 덮어쓰는지 확인한 후 관리 방법을 정하세요.

QR 코드, 공유 링크, 구성 파일의 구분

Scan QR Code는 정보를 가져오는 방법일 뿐입니다. 가져온 뒤에도 프로토콜, 주소, 인증 항목을 확인해야 합니다. QR 코드에는 서버 정보나 구독 링크가 들어 있을 수 있으므로 스캔 성공 메시지만으로 어떤 항목인지 판단하지 마세요. 공유 링크도 전체 내용을 복사해야 합니다. 여러 항목이 추가되었다면 각각 출처와 용도를 확인하세요. 가져온 항목 수가 성공 기준은 아닙니다. 매개변수를 확인할 수 있고 선택 가능한 서버 하나가 최소한의 확인 기준입니다.

Config의 규칙 파일과 Home의 서버는 별도로 확인해야 합니다. 규칙을 가져왔다고 서버가 생기는 것은 아니며, 구독을 가져왔다고 현재 Config에 적절한 라우팅 구성이 포함되는 것도 아닙니다. 첫 테스트에서는 먼저 서버 매개변수를 확인하고, 라우팅 방식을 살펴본 뒤 규칙을 검증하세요. 프로토콜 필드에 관해 더 알아보려면 프로토콜 및 Type 안내를 참고하세요. 실제 연결 매개변수는 원본 정보를 기준으로 입력하고, 문서의 예시를 인증 정보 대신 사용하지 마세요.

04 / GLOBAL ROUTING

Global Routing 세 가지 모드와 규칙 순서

연결하기 전에 Global Routing을 확인하세요. Config, Proxy, Direct 세 가지 모드는 각각 구성, 프록시, 직접 연결 방식으로 요청을 처리합니다. 서버 프로토콜이나 속도 등급을 뜻하는 것은 아닙니다. 모드를 바꿔도 잘못된 암호, 만료된 구독, 연결할 수 없는 서버가 복구되지는 않습니다. 바뀌는 것은 라우팅 결정 방식입니다. 문제를 확인할 때 현재 모드를 기록하세요. 기록하지 않으면 같은 요청이 전후에 서로 다른 경로로 처리되어 서버 상태가 갑자기 달라진 것처럼 보일 수 있습니다.

Config, Proxy, Direct 선택하기

Config는 현재 활성화된 구성과 규칙에 따라 요청을 처리하므로 라우팅 대상을 명확히 정한 뒤 일상적으로 사용하는 데 적합합니다. 규칙에 따라 일부 요청은 프록시로, 일부는 직접 연결로 보내거나 특정 요청을 차단할 수 있습니다. Proxy는 프록시를 주된 처리 경로로 삼으므로 규칙의 영향을 줄여 서버가 요청을 처리할 수 있는지 확인할 때 유용합니다. Direct는 직접 연결 방식으로 처리하므로, 이 모드에서 접속에 성공했다고 해서 프록시 서버가 작동한다고 볼 수는 없습니다. 세 모드 모두 대상 요청과 시스템 상태를 함께 살펴야 합니다.

Proxy에서 Config로 전환한 뒤 결과가 달라지면 서버가 갑자기 작동하지 않는다고 판단하기 전에 규칙과 정책 대상을 확인하세요. 반대로 Config에서 웹사이트에 접속할 수 있다고 해서 프록시가 작동한다고 단정할 수도 없습니다. 해당 사이트가 DIRECT 규칙에 일치했을 수 있습니다. 올바르게 테스트하려면 먼저 요청이 어떤 경로로 처리되어야 하는지 정한 뒤 실제로 적용된 정책을 확인하세요. 테스트가 끝나면 일상적으로 사용할 모드로 되돌려 문제 해결을 위해 임시로 바꾼 설정이 계속 남지 않도록 하세요.

위에서 아래 순서로 규칙 읽기

규칙은 일반적으로 순서대로 확인하며, 먼저 일치한 항목이 이후 처리를 결정하므로 구체적인 규칙을 포괄적인 규칙보다 앞에 두어야 합니다. DOMAIN은 전체 도메인을, DOMAIN-SUFFIX는 도메인 접미사를, DOMAIN-KEYWORD는 도메인에 포함된 키워드를 기준으로 일치 여부를 판단합니다. IP-CIDR과 IP-CIDR6은 IP 주소 대역을 대상으로 하며, GEOIP는 IP 주소의 지역 정보를 사용합니다. FINAL은 앞선 규칙에 일치하지 않은 요청을 처리합니다. 규칙 키워드는 일치 조건을, 마지막 정책은 처리 방향을 나타내므로 각각 나누어 살펴보세요.

[Rule]
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.org,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

위 내용은 학습용 .conf 규칙 예시이며 완성된 구성 파일이 아니고 모든 네트워크에 적합한 것도 아닙니다. 첫 번째 행은 지정한 전체 도메인만 일치시키고, 두 번째 행은 해당 도메인 접미사를 포함합니다. 세 번째 행은 사설 IP 대역과 no-resolve 작성 방식을 보여 줍니다. 마지막으로 FINAL이 나머지 요청을 처리합니다. example.com과 example.org는 예시 도메인이므로 붙여넣기 전에 각 규칙의 의미를 이해하세요. 기존 파일을 수정할 때는 같은 규칙이나 더 넓은 범위의 규칙이 이미 있는지도 먼저 확인해야 합니다.

정책 대상과 규칙 적용 확인

PROXY, DIRECT, REJECT는 각각 프록시, 직접 연결, 거부 방향으로 처리한다는 뜻입니다. 규칙에서 사용자 지정 정책 이름을 사용한다면 현재 구성에 해당 정책이 정의되어 있어야 합니다. 서버 메모를 임의로 정책 이름으로 입력하고 클라이언트가 올바른 대상을 자동으로 찾으리라 기대하지 마세요. 규칙을 확인할 때는 일치 조건뿐 아니라 일치한 규칙의 정책이 최종적으로 어디를 가리키는지도 살펴야 합니다. 규칙에 일치하는지와 연결에 성공하는지는 별도로 검증해야 합니다.

Config를 수정한 뒤에는 현재 활성화된 파일을 편집했는지 확인하고 저장한 다음, 화면 안내에 따라 다시 불러오거나 재연결해 새 상태에서 테스트하세요. 기존 연결은 이전 경로를 계속 사용할 수 있고 앱 캐시가 변경 결과를 가릴 수 있으므로 새로운 요청을 보내 확인해야 합니다. 자세한 키워드 설명은 규칙 문법 기초에서, 낯선 용어는 용어집에서 확인하세요. 매번 조정하기 전에 원본 파일을 보관하고 결과를 확인한 뒤 규칙을 더 추가하세요.

05 / CONNECTIVITY

연결 및 단계별 검증

연결 확인은 기본 네트워크, 서버 선택, 시스템 권한, 테스트 요청, 규칙 일치 순서로 진행하세요. 스위치가 켜져 있다는 것은 클라이언트와 시스템이 연결 상태에 들어갔다는 뜻일 뿐, 모든 대상에 접근할 수 있다는 증거는 아닙니다. Home에 서버가 있다는 것도 항목이 저장되었다는 뜻입니다. 각 상태를 따로 확인하면 웹사이트가 열리지 않을 때 구성을 모두 삭제하거나 앱을 다시 구매하는 식의 잘못된 대응을 피할 수 있습니다.

선택한 서버부터 확인하기

Home에서 테스트할 서버를 찾아 선택 표시가 나타나는지 확인하세요. 구독 그룹에 항목이 많다면 그룹 이름을 실제 연결 대상으로 착각하지 않도록 이번에 사용할 서버를 먼저 정하세요. 방금 구독을 업데이트했다면 선택한 항목이 여전히 유효한지도 확인해야 합니다. 그런 다음 Global Routing을 살펴보고 현재 모드가 Config, Proxy, Direct 중 무엇인지 기록하세요. Config에서 사용자 지정 정책을 쓴다면 정책이 예상한 대상을 최종 선택하는지 확인하세요.

상단의 연결 스위치를 켜고 시스템에서 요청하는 권한을 승인한 뒤 상태가 안정될 때까지 기다렸다가 테스트하세요. 스위치가 바로 꺼지면 권한, 시스템 VPN 상태, 앱에 표시된 오류 안내를 먼저 확인하세요. 스위치는 켜져 있지만 요청이 실패한다면 서버와 네트워크를 계속 점검해야 합니다. 이 두 현상을 같은 문제로 취급하지 마세요. 연결 과정이 끝나기 전에 스위치를 반복해서 빠르게 전환하지 마세요. 연결과 새 연결 시도가 겹치면 안내 메시지와 실제 요청을 대응하기 어려워집니다.

Connectivity Test로 확인할 수 있는 항목

Connectivity Test는 해당 테스트 조건에서 연결이 가능한지 확인하는 기능입니다. 결과는 현재 라우팅 모드, 테스트 대상, 선택한 서버를 함께 고려해 살펴보세요. 한 번의 테스트 성공을 모든 웹사이트와 앱이 정상이라는 뜻으로 확대 해석하면 안 됩니다. 테스트 방식에 따라 사용하는 경로와 프로토콜이 다를 수 있으며, 단일 수치로 실제 서비스 요청을 대신할 수 없습니다. 첫 테스트에서는 서버, 네트워크, 대상을 고정하고 변수 하나만 바꿔 반복해서 비교하세요.

먼저 Connectivity Test를 실행한 다음, 정상적으로 이용할 수 있다고 확실히 아는 대상을 열어 페이지 전체가 로드되는지 확인하세요. 제목만 표시되는 것으로는 충분하지 않습니다. 테스트는 성공했지만 대상에 접근하지 못한다면 대상 자체, DNS, 규칙, 인증서, 앱 캐시 등이 원인일 수 있습니다. 테스트와 여러 대상 모두 실패한다면 기본 네트워크와 서버 매개변수를 다시 확인하세요. TCP 유형 요청과 다른 전송 방식도 구분해야 합니다. 일반 웹페이지 하나가 열렸다고 모든 통신 방식이 검증된 것은 아닙니다.

현상에 따라 문제 범위 좁히기

연결을 끊은 뒤 먼저 기기 자체에서 정상적인 대상에 접근할 수 있는지 확인하세요. Wi-Fi 로그인이 완료되지 않았거나 셀룰러 네트워크를 사용할 수 없거나 네트워크가 일시적으로 끊긴 상황을 배제해야 합니다. 기본 네트워크가 복구되면 같은 서버에 연결해 비교하세요. 특정 네트워크에서만 실패하면 해당 네트워크 환경과 전송 조건을 중점적으로 살펴보세요. 여러 네트워크에서 모두 실패하면 서버 주소, 포트, 인증 정보, TLS 매개변수를 확인하세요. 네트워크 전환은 한 가지 변수만 바꾸는 작업이므로 규칙 수정과 동시에 진행하지 말고 테스트 기록에 남기세요.

Proxy에서는 테스트할 수 있지만 Config에서 실패한다면 현재 구성 파일, 일치한 규칙, 정책이 가리키는 대상을 먼저 확인하세요. 도메인 하나만 이상하다면 더 앞에 있는 규칙에 의해 처리되지 않았는지, 도메인 해석 결과가 예상과 일치하는지 살펴보세요. 모든 항목에 동시에 문제가 생겨도 모든 서버가 작동하지 않는다고 바로 단정하지 마세요. 기본 네트워크, 시스템 시간, 공통 구독 상태, 최근 변경한 공통 설정도 확인해야 합니다. 여러 항목이 같은 요소에 의존할 수 있으므로 항목 수가 많다고 서로 독립적인 것은 아닙니다.

검증 후 마무리

연결에 성공하면 일상적으로 사용할 Global Routing 모드로 되돌린 뒤 같은 대상으로 다시 테스트하세요. 임시 모드에서만 성공한 것은 아닌지 확인할 수 있습니다. Data에서 새 요청과 정책이 일치하는지 살펴보고 임시 DNS나 디버깅 옵션이 남아 있지 않은지 확인하세요. 계속 실패한다면 재현 절차를 정리한 뒤 FAQ의 연결 문제 해결을 참고하세요. 단계별 조작 방법은 첫 연결 확인 안내에서 볼 수 있지만, 자신의 매개변수 확인은 생략하지 마세요.

이 장의 완료 기준은 우연히 한 번 연결에 성공하는 것이 아닙니다. 현재 어떤 대상을 사용하고, 어떤 모드로 요청을 처리하며, 결과를 어떻게 재현해 확인할지 설명할 수 있어야 합니다. 이 기반이 안정되어야 다음 장의 Data 분석과 Settings 조정을 비교할 기준도 마련됩니다. 그렇지 않으면 설정을 계속 추가해 불확실성만 커질 수 있습니다.

06 / DATA

Data에서 트래픽 관찰 및 요청 확인

Data에서는 클라이언트에 기록된 트래픽 활동을 살펴볼 수 있습니다. 테스트 중 요청이 발생했는지, 어떤 대상과 지속해서 통신하는지, 처리 방향이 예상과 일치하는지 확인할 때 유용합니다. 서비스 제공업체의 과금 내역이 아니며 기기의 모든 네트워크 활동을 기록한 전체 이력도 아닙니다. 데이터를 보기 전에 통계 범위, 현재 연결 상태, 테스트 시간을 확인하세요. 누적량이 증가했다고 해서 방금 연 페이지가 그 데이터를 사용했다고 단정할 수는 없습니다. 백그라운드 동기화나 기존 연결이 동시에 발생했을 수 있습니다.

관찰 구간부터 정하기

테스트를 준비할 때 현재 통계값이나 목록 상태를 기록하고, 당장 필요하지 않은 앱의 작업을 중지한 다음 페이지 열기나 새로고침처럼 분명한 동작 하나만 실행하세요. 누적량을 보고 추측하는 대신 Data로 돌아가 새로 발생한 변화를 살펴보세요. 통계를 지우려면 어떤 항목이 지워지는지와 안내 메시지를 먼저 확인하고 중요한 정보는 따로 기록해 두세요. 로컬 통계를 지워도 원격 사용량이 지워지는 것은 아니며 구독 기간이나 서비스 제공업체의 기록도 바뀌지 않습니다.

업로드와 다운로드를 살펴볼 때 요청 자체에도 연결 설정, 요청 헤더, 앱에서 전송한 내용 등 업로드 데이터가 포함된다는 점을 알아두세요. 웹페이지를 읽기만 해도 업로드가 0이 되는 것은 아닙니다. 프로토콜 오버헤드, 캐시, 재시도, 압축으로 인해 다운로드량과 파일에 표시된 크기가 달라질 수 있습니다. 한 번의 테스트에서 생긴 미세한 수치 차이만으로 이상 여부를 판단하지 마세요. 같은 조건에서 동일한 동작을 반복했을 때 뚜렷하게 다른 양상이 계속 나타나는지 비교하는 편이 더 유용합니다.

요청, 규칙, 정책을 함께 살펴보기

현재 화면에 요청이나 연결 상세 정보가 표시된다면 트래픽 크기만 보지 말고 대상, 처리 정책, 시간을 확인하세요. Config 모드에서는 한 페이지가 메인 도메인, 이미지 도메인, API 도메인과 기타 리소스를 동시에 요청하며 각각 다른 규칙에 일치할 수 있습니다. 페이지는 열리지만 이미지가 표시되지 않는다면 리소스마다 다른 경로로 처리되었을 수 있으며, 서버 전체가 작동하지 않는다고 볼 수는 없습니다. 먼저 실패한 리소스의 대상을 확인한 뒤 Config에서 해당 조건과 일치하는 규칙을 찾아보세요.

DIRECT가 표시되면 먼저 직접 연결이 원래 예상한 결과인지 확인하세요. PROXY가 표시되면 실제로 어떤 대상으로 연결되는지까지 확인해야 합니다. 웹사이트의 표시 언어, 화면 모양, 로딩 속도로 적용된 정책을 추측할 수는 없습니다. 도메인이 항상 전부 표시되는 것도 아니며 일부 연결에는 주소 정보만 주로 나타날 수 있습니다. 이미 연결된 항목에는 이전 판단이 계속 적용될 수도 있습니다. 규칙을 바꾼 뒤에는 기존 연결이 즉시 바뀌는지 지켜보기보다 새 요청을 보내 기록을 확인하는 편이 더 정확합니다.

트래픽, 속도, 안정성 구분하기

누적 전송량은 지금까지 처리한 데이터의 양을 나타내고, 순간적인 변화는 짧은 시간 동안의 활동을 나타냅니다. 어느 쪽도 장기적인 안정성과 같지 않습니다. 웹페이지를 열어 둔 상태에서 새 트래픽이 없는 것은 로딩이 끝났기 때문일 수 있고, 짧은 시간 동안 트래픽이 크게 늘어도 백그라운드 작업 때문일 수 있습니다. 안정성을 확인하려면 같은 동작을 반복해 오류가 재현되는지 살펴보고 연결 상태와 함께 판단하세요. 순간적인 수치가 더 크게 나오는 것만을 목표로 삼지 마세요.

네트워크별 결과도 따로 기록해야 합니다. Wi-Fi와 셀룰러 네트워크는 연결 설정과 전송 환경에 영향을 주므로 두 번의 테스트를 하나의 누적 통계로 합쳐 바로 비교할 수 없습니다. 특정 설정 때문에 재연결이 반복된다고 의심되면 관찰 내용을 기록한 뒤 해당 설정 하나만 되돌려 다시 테스트하세요. 통계를 지우고 구독을 업데이트하면서 규칙까지 동시에 바꾸지 마세요. 결과가 개선되어도 어떤 변경이 효과를 냈는지 알 수 없습니다.

진단 데이터의 개인정보 보호

트래픽과 요청 기록에는 도메인, 경로, 기기 사용 습관, 인증 관련 정보가 포함될 수 있습니다. 공유하기 전에 문제 해결에 필요한 내용만 남기고 계정 정보, 구독 인증 정보, 전체 서버 인증 항목, 개인 요청 매개변수를 삭제하세요. 무작위 문자열처럼 보이는 값도 유효한 인증 정보일 수 있습니다. 용도를 모른다고 그대로 공개하지 마세요. 테스트가 끝나면 필요에 따라 추가 기록을 중지해 현재 문제와 관계없는 데이터를 장기간 보관하지 않도록 하세요.

이 장의 목표는 확인 가능한 근거를 연결하는 것입니다. 테스트 동작을 정하고 새 요청을 찾은 뒤 처리 정책을 확인하여 서버, 규칙, 대상 중 어디를 점검할지 결정하세요. Data는 관찰 자료를 제공할 뿐 판단을 대신하지 않습니다. 이상 현상을 앞 장의 최소 테스트 기록과 함께 정리하면 누적량만 표시된 스크린샷 하나보다 문제 해결에 더 도움이 됩니다.

07 / SETTINGS

Settings의 주요 항목과 조정 범위

기본 연결을 확인한 뒤 Settings를 항목별로 조정하세요. 처음 실행하자마자 모든 스위치를 켜지 마세요. 설정마다 영향을 주는 범위가 다릅니다. 연결 시점에 영향을 주는 항목, 도메인 해석에 영향을 주는 항목, 테스트나 기록에 영향을 주는 항목이 있습니다. 변경하기 전에 해결하려는 현상을 기록하고 해당 항목의 설명과 현재 값을 확인하세요. 이 장에서 언급한 항목이 화면에 없다면 기기에 실제 표시된 내용을 기준으로 하세요. 이름이 비슷하다는 이유로 같은 기능이라고 추측하거나 다른 구성의 설정을 전부 적용하지 마세요.

On Demand: 서버 복구가 아닌 연결 조건

On Demand는 조건에 따라 연결을 시작하는 기능입니다. 실제 동작은 시스템 VPN 구성, 네트워크 변화, 기기 관리 상태에도 영향을 받습니다. 먼저 수동 연결이 안정적으로 작동하는지 확인한 뒤 활성화를 검토하세요. 기본 매개변수 오류에 자동 연결 동작까지 겹치면 연결이 반복되거나 스위치 상태가 바뀌고 네트워크 전환 후 결과가 달라져 원인을 구분하기 어려워질 수 있습니다. On Demand는 언제 연결을 시도할지 결정하며 작동하지 않는 서버를 복구하지 않습니다.

활성화하기 전에 원하는 동작을 정하세요. 어떤 네트워크에서 연결할지, 어떤 경우에 중지할지, 수동으로 연결을 끊은 뒤 어떻게 되기를 원하는지 확인해야 합니다. 변경한 뒤 앱을 사용 중일 때, 네트워크를 전환할 때, 기기를 다시 깨울 때처럼 실제 상황별로 테스트해 시스템의 동작을 확인하세요. 설정 화면에서 스위치가 켜져 있다는 것만으로 모든 조건이 적용된다고 볼 수는 없습니다. 자동 재연결 문제를 확인할 때는 우선 수동 연결 상태로 되돌리면 트리거 조건과 서버 자체를 구분하는 데 도움이 됩니다.

DNS: 이름 해석 오류와 연결 오류 구분하기

DNS는 도메인을 IP 주소로 변환합니다. 이름 해석에 성공해도 이후 연결을 위한 여러 조건 중 하나만 충족된 것입니다. 도메인을 해석하지 못하는 경우와 주소를 확인했지만 연결을 설정하지 못하는 경우는 구분해서 처리해야 합니다. 문제가 도메인 요청에서만 발생하는지 먼저 확인한 다음 현재 Config와 Settings에 DNS 관련 설정이 모두 포함되어 있는지 살펴보세요. 구성 파일과 화면 설정이 함께 최종 동작에 영향을 줄 수 있으므로 한쪽만 확인하고 다른 쪽은 영향이 없다고 단정하지 마세요. 현재 항목의 설명과 실제 요청 결과를 기준으로 판단하세요.

DNS 옵션은 많을수록 좋은 것도 아니고, 임의로 바꾸면 모든 접속이 빨라지는 것도 아닙니다. DNS 서비스 자체에 접근할 수 있어야 하며 반환된 주소도 이후 라우팅 방식과 맞아야 합니다. 설정을 바꾼 뒤 일부 대상만 문제가 생기면 도메인과 이전·현재 설정을 기록하고 원래 값으로 되돌려 비교하세요. IP 주소로 직접 연결되었다고 도메인 해석까지 정상이라고 볼 수는 없습니다. 테스트 페이지 하나에 콘텐츠가 표시되어도 앱의 실제 요청이 다른 도메인이나 캐시를 사용할 수 있다는 점을 고려하세요.

테스트, 기록, 인증서 관련 항목

연결 테스트 대상과 방법에 따라 Connectivity Test 결과의 의미가 달라집니다. 테스트 항목을 바꾸면 원래 값을 기록하고 용도를 확실히 아는 대상을 사용해 확인하세요. 테스트 대상 자체에 접근할 수 없다면 결과는 서버가 아니라 대상의 문제를 반영할 수 있습니다. 로그와 진단 기록은 구체적인 문제를 해결할 때만 임시로 사용하세요. 기록 시간이 길고 범위가 넓다고 분석이 쉬워지는 것은 아닙니다. 테스트 후 불필요한 상세 기록이 남아 있는지 확인하고 개인정보 보호 필요에 따라 기존 내용을 처리하세요.

인증서 및 HTTPS 관련 설정은 특히 주의해야 합니다. 일반 서버 연결이나 기본 규칙 라우팅만으로 트래픽 복호화 검사가 반드시 필요한 것은 아닙니다. 인증서 오류가 발생하면 기기 시간, 대상 도메인, 서버의 TLS 매개변수부터 확인하세요. 인증서 검증을 끄는 것을 일반적인 해결 방법으로 삼지 마세요. 인증서 기능의 영향을 잘 모른다면 기존 상태를 유지하고 현재 항목의 설명을 읽어보세요. 오류 안내를 없애려고 기기 전체의 신뢰 판단 방식을 바꾸지 마세요.

구성 적용 범위와 되돌리는 방법

설정을 바꿀 때마다 해당 값이 특정 서버에만 적용되는지, 특정 Config 파일에 적용되는지, 앱 전체 설정인지 확인하세요. 서버 하나의 전송 매개변수를 바꿔도 구독의 다른 항목까지 바뀌는 것은 아닙니다. Config를 전환한다고 모든 앱 설정이 복원되는 것도 아닙니다. 적용 범위를 간단히 기록해 두면 서버를 바꿔도 문제가 남는 이유나 구성 파일을 바꾼 뒤 결과가 달라진 이유를 파악하는 데 도움이 됩니다. 여러 항목에 공통으로 영향을 주는 문제라면 함께 적용되는 설정 단계부터 살펴보세요.

설정을 되돌릴 때는 변경한 순서의 반대로 한 항목씩 복원하고 다시 테스트하세요. 모든 내용을 한 번에 초기화하지 마세요. 초기화가 필요하다면 먼저 서버와 구성을 백업하고 민감한 정보의 저장 위치를 확인한 뒤 다시 입력해야 할 값을 기록하세요. Settings의 목표는 동작을 예측할 수 있게 만드는 것이지 옵션을 계속 늘리는 것이 아닙니다. 용도를 설명할 수 있는 변경 사항만 유지하세요. 화면의 용어가 이해되지 않는다면 용어집을 확인한 뒤 조정이 필요한지 판단하세요.

08 / MAINTENANCE

구독 업데이트, 백업, 일상 관리

일상 관리의 핵심은 검증된 상태를 보존하고 모든 변경 과정을 추적할 수 있게 하는 것입니다. 앱 업데이트, 구독 업데이트, 규칙 수정, 기기 교체는 서로 다른 작업입니다. 기록 없이 한꺼번에 진행하지 마세요. 문제가 생기면 최근에 바꾼 항목부터 확인하고 필요한 범위만 수정하세요. 기본 연결을 반복해서 검증할 수 있다면 한 부분의 문제 때문에 모든 서버와 구성을 삭제할 필요는 없습니다. 관리는 불확실성을 줄이는 과정이지 계속 처음부터 시작하는 과정이 아닙니다.

앱 업데이트와 구독 업데이트 분리하기

앱은 App Store에서 업데이트하며, 현재 호환성과 관련 안내는 App Store 페이지를 기준으로 확인하세요. 앱을 업데이트했다고 구독이 계속 유효하거나 원격 서버 상태가 변하지 않았다는 뜻은 아닙니다. 구독 업데이트는 서비스 제공업체가 제공하는 내용을 다시 읽는 작업으로, 앱 업데이트와 출처와 목적이 다릅니다. 먼저 현재 연결 결과를 기록한 뒤 둘 중 하나를 업데이트하고 다시 테스트하세요. 정상적으로 작동하는 것을 확인한 다음 다른 항목을 업데이트하면 문제와 변경 사항을 구분하기 쉽습니다.

구독을 업데이트하기 전에 유지해야 할 수동 변경 사항을 확인하고, 업데이트한 뒤에는 그룹 콘텐츠, 현재 선택한 항목, 규칙이 참조하는 대상을 살펴보세요. 이름이나 항목이 바뀌면 이름으로 구분해 둔 기록이 더 이상 정확하지 않을 수 있으므로 주소와 용도를 다시 확인해야 합니다. 업데이트에 실패해도 기존 그룹을 바로 삭제하지 마세요. 이전 항목으로 여전히 연결할 수 있는지 확인한 뒤 구독 링크, 기본 네트워크, 반환된 콘텐츠를 점검하세요. 사용할 수 있는 상태를 보존하면 가져오기 오류와 서버 오류를 구분하기 쉽습니다.

백업할 콘텐츠와 인증 정보를 구분하기

백업하기 전에 저장할 항목을 정하세요. 서버 정보, 구독 링크, Config 파일, 필요한 Settings의 이전 값, App Store 구매 계정 확인 기록이 포함될 수 있습니다. 앱에서 제공하는 내보내기나 시스템 파일 저장 기능을 사용한다면 먼저 내보내기 범위를 확인하세요. 특정 파일 하나에 모든 설정이 들어 있다고 가정하지 마세요. 작업을 마치면 파일을 찾을 수 있는지, 이름을 알아보기 쉬운지, 장기 보관에 적합한 위치인지 확인하세요. 백업 파일이 있어도 열 수 없다면 복원 준비를 완료한 것이 아닙니다.

구성 파일과 공유 자료에는 암호, 사용자 ID, 구독 인증 정보가 포함될 수 있으므로 일반 문서처럼 공개된 곳에 보관하면 안 됩니다. 문제를 논의할 때 사용할 사본에서는 민감한 항목을 제거하세요. 복원에 사용할 백업에는 필요한 정보를 보존하되 안전하게 보호해야 합니다. 두 파일의 용도는 다르므로 일부 항목을 삭제한 진단용 사본을 유일한 복원 파일로 사용하지 마세요. 인증 정보가 실수로 공개되었다면 서비스 제공업체에 적절한 대응을 확인하고 기존 정보가 여전히 유효한지 점검하세요.

기기 교체 및 재설치는 단계별로 복원하기

새 기기에서는 먼저 App Store에서 앱을 다시 찾으세요. 시스템 요구 사항과 구매 가능 여부는 App Store 페이지의 표시를 기준으로 확인한 뒤 앱을 열어 실제 상태를 살펴봅니다. 다음으로 서버 하나 또는 구독 하나를 복원하고 시스템 권한을 설정한 뒤 수동 연결을 테스트하세요. 기본 연결이 성공하면 Config와 일상적인 Settings를 복원하고 마지막으로 On Demand를 테스트하세요. 모든 내용을 한꺼번에 가져온 뒤 스위치가 켜졌다는 이유만으로 복원이 완료되었다고 판단하지 마세요. 오래된 설정의 영향이 네트워크 전환 후에야 나타날 수도 있습니다.

이전 기기에서 잘 작동하던 구성도 당시의 네트워크, 시스템 권한, 유효한 서버 정보에 의존했을 수 있습니다. 새 기기에서 결과가 다르다고 해서 파일이 손상되었다고 단정하지 마세요. 이전 기기에서 작동하던 기록을 보관하고 서버 매개변수, Global Routing, 현재 Config를 하나씩 비교하세요. 복원이 끝난 뒤 이전 기기에 남은 민감한 정보를 처리하세요. 구입 항목 복원 방법은 구입 항목 복원 안내에서 확인할 수 있습니다. App Store 구매 복원과 구성 이전을 하나의 단계로 취급하지 마세요.

일관된 점검 및 문제 해결 절차 만들기

중요한 설정을 바꿀 때마다 같은 항목을 반복해서 확인하세요. 현재 서버가 분명한지, Global Routing이 올바른지, Connectivity Test와 실제 대상 모두 검증되는지, Data의 정책이 예상과 일치하는지, 임시 디버깅 설정을 원래대로 되돌렸는지 살펴보세요. 문제가 다시 발생하면 변경을 이어가기 전에 잠시 멈추고 마지막으로 정상 작동한 상태와 처음 이상이 나타난 시점 사이에 무엇이 달라졌는지 기록하세요. 이런 기록은 문제 범위를 좁혀 주며, 임시 옵션을 켠 이유를 잊어 잘못된 전제에서 다시 점검하는 일도 막아 줍니다.

도움을 요청할 때는 기기 유형, 네트워크 환경, 라우팅 모드, 문제가 재현되는지, 이미 어떤 비교 테스트를 했는지, 인증 정보가 없는 오류 메시지를 제공하세요. ‘연결이 안 됨’이나 ‘느림’처럼 막연하게 설명하지 말고 전체 백업을 첫 자료로 보내지도 마세요. 문제가 발생한 단계에 따라 이 매뉴얼의 해당 장을 확인하세요. 가져오기 문제는 서버와 구독, 경로 문제는 Global Routing, 스위치나 요청 문제는 연결 확인, 자동 연결 문제는 Settings를 살펴보세요.

여기까지 살펴보면 하나의 사용 흐름을 구성할 수 있습니다. 정품 구매로 앱을 확인하고, 첫 권한 설정으로 시스템 연결 조건을 갖춘 뒤, 서버 정보로 연결 대상을 지정하고, Config로 라우팅을 결정합니다. 테스트와 Data로 근거를 확인하며 Settings로 동작을 조정하고, 백업과 기록으로 복원 가능성을 유지합니다. 일상적으로 사용할 때 모든 절차를 반복할 필요는 없습니다. 변경이 발생하면 영향을 받은 단계부터 확인하세요. 빠른 조작 절차는 사용 튜토리얼에서, 자주 묻는 질문은 FAQ에서 확인하고, 규칙 세부 사항은 사이트의 관련 안내를 계속 읽어보세요.