Shadowrocket 완벽 사용 가이드

정품 구매 및 구매 내역 확인

구매하기 전에 앱이 맞는지 먼저 확인하세요. Shadowrocket은 Apple 플랫폼용 유료 상용 클라이언트이며, 주 사용 기기는 iPhone과 iPad입니다. 공식 구매 경로는 App Store뿐입니다. Mac, Apple TV, Apple Vision 호환 여부도 같은 제품 페이지에서 확인할 수 있으며, 시스템 요구 사항과 유니버설 구매 적용 여부는 App Store 페이지의 안내를 따릅니다. 이후 내용은 iPhone과 iPad를 기준으로 설명하며, 다른 기기의 화면 구성이 동일하다고 가정하지 않습니다.

앱 이름·개발자·앱 ID 확인

정품 확인 페이지에서 App Store 안내로 이동한 다음 앱 이름 Shadowrocket, 개발자 Shadow Launch Technology Limited, 제품 링크의 앱 ID 932747118를 차례로 확인하세요. 이어서 App Store 아이콘과 사이트 상단의 공식 아이콘을 비교하세요. 이름이 비슷하다고 같은 앱은 아닙니다. 검색 결과의 순위나 추가 설명, 페이지 색상만으로 판단하지 말고 제품 페이지에 표시된 정보를 기준으로 확인하세요.

App Store 페이지에서는 가격, 호환성, 업데이트 내역을 확인할 수 있습니다. 구매 전 호환성 정보를 펼쳐 현재 기기에 설치할 수 있는지 확인하세요. 가격은 현재 선택된 스토어와 계정의 결제 화면에 표시된 금액을 기준으로 합니다. 글에 나온 가격 예시를 최종 결제 금액으로 간주하거나, 특정 제품군에 속한다는 이유만으로 지원 여부를 판단하지 마세요. 같은 모델이라도 시스템 상태에 따라 스토어에서 이용할 수 있는 작업이 다를 수 있습니다.

클라이언트 구매와 연결 서비스 구분

Shadowrocket은 일회성 구매 앱으로, 미국 스토어 가격은 약 2.99달러이며 각 스토어에서 현지 통화로 표시됩니다. 실제 금액은 App Store 페이지를 확인하세요. 구매 대상은 클라이언트 사용 권한입니다. 서버 주소, 인증 정보, 서비스 이용 기간과 데이터 용량은 사용자가 이미 보유한 서비스 설정에 따라 제공되며, 앱을 구매한다고 자동으로 생성되지 않습니다. 설치 후 목록이 비어 있다면 앱을 다시 구매하는 대신 보유한 구성을 가져오세요.

구매 전에는 현재 사용 중인 App Store 계정을 확인하고 시스템에 기록된 구매 내역을 보관하세요. 일부 기기에서는 시스템 계정과 스토어 구매 계정을 별도로 관리할 수 있으므로, 기기 상단에 표시된 이름만으로 구매 계정을 판단할 수 없습니다. 기기를 바꾸거나 앱을 다시 설치하고 결제 내역을 확인할 때는 앱 내부의 서버 이름, 구성 메모, 연결 상태가 아니라 원래 구매 내역을 확인하세요.

설치·복원·업데이트 범위

App Store에서 구매하고 설치한 뒤 앱을 한 번 열어 기본 화면에 진입할 수 있는지 확인한 다음 구독과 권한을 설정하세요. 스토어에서 다시 결제하라는 메시지가 표시되면 결제를 확정하기 전에 계정과 구매 내역이 일치하는지 확인하세요. 같은 구매 계정으로 다시 받는 경우와 다른 기기에서 이용할 수 있는 권한은 스토어 페이지와 실제 계정 내역을 함께 확인해야 합니다. 가족 공유 적용 여부도 페이지 안내와 계정 설정을 기준으로 판단하세요.

기기를 바꿀 때는 앱 구매 권한 복원과 앱 내 데이터 복원을 별도로 준비하세요. 구입 항목에서 앱을 다시 받더라도 서버, 구독 링크, 로컬 구성이 자동으로 함께 복원되는 것은 아닙니다. 기기 교체 전 사용할 수 있는 구성 백업이 있는지 확인하고, 보유한 서비스의 원본 정보를 저장하세요. 서버 메모만으로는 연결을 다시 만들기 어려울 수 있습니다. 메모에는 프로토콜, 포트, 인증 매개변수가 들어 있지 않기 때문입니다.

앱 업데이트는 App Store에서 관리합니다. 업데이트 전에 사용 중인 구성과 필요한 연결 매개변수를 저장하세요. 업데이트 후에는 기본 서버, Global Routing, 현재 활성화된 구성이 예상대로 유지되는지 확인하세요. 스토어에서 설치가 진행되지 않으면 계정, 결제, 기기 저장 공간, 시스템 호환성 등 스토어 측 문제부터 확인하세요. 이 단계는 원격 서버에 연결하기 전이므로 DNS나 규칙을 바꿔도 구매·설치 문제는 해결되지 않습니다.

이 장의 목표는 App Store에서 동일한 제품을 확인하고, 구매 계정을 식별하고, 앱을 정상적으로 열며, 보유한 연결 정보가 어디에 저장되어 있는지 아는 것입니다. 홈 화면에 아이콘이 생겼다고 준비가 모두 끝난 것은 아닙니다. 앱 구매와 데이터 복원의 범위를 구분해야 이후 연결이 실패했을 때 앱 상태, 매개변수 문제, 원격 서비스 문제를 정확히 나눠 볼 수 있습니다.

첫 실행 및 VPN 구성 권한

처음 실행하면 먼저 Home 화면을 살펴본 뒤 연결을 시작하세요. Home에는 연결 스위치, Global Routing, Connectivity Test, SERVER 목록이 모여 있습니다. 기기와 앱 상태에 따라 화면 배치가 달라질 수 있으므로 고정된 위치를 외우기보다 영문 이름으로 기능을 확인하세요. 자세한 화면 설명은 첫 실행 및 Home 화면 안내를 참고하세요. 이 장에서는 권한과 연결 상태의 관계를 설명합니다.

Home 화면에서 확인할 네 가지

연결 스위치는 현재 연결을 시작하거나 중지합니다. Not Connected는 아직 연결 상태가 만들어지지 않았다는 뜻이며, 앱 구매에 실패했다는 의미는 아닙니다. Global Routing은 트래픽을 구성 규칙에 따라 처리할지, 프록시 정책을 사용할지, 직접 연결할지 결정합니다. SERVER 목록에는 선택 가능한 서버 항목이 저장됩니다. 항목을 열어 편집하는 것과 기본 서버로 선택하는 것은 서로 다른 작업이므로 각각 확인하세요.

Connectivity Test는 목록에 있는 서버의 연결 상태를 확인합니다. 결과를 통해 문제 범위를 좁힐 수는 있지만 실제 접속을 완전히 검증하는 것은 아닙니다. 처음 실행했을 때 목록이 비어 있으면 유효한 서버 테스트 결과를 얻을 수 없습니다. 목록에 항목이 있다고 모두 사용할 수 있는 것도 아닙니다. 먼저 3장에서 매개변수를 확인한 뒤 테스트 결과를 참고하세요. 필요한 정보가 없는 상태에서 스위치만 반복해서 바꾸지 마세요.

앱에 표시되는 상태와 시스템에 저장된 구성을 구분하세요. 시스템에 이전에 추가한 VPN 구성이 남아 있어도 앱은 현재 연결되어 있지 않을 수 있습니다. 앱이 정상적으로 열려도 시스템이 연결을 허용한다는 뜻은 아닙니다. 상태를 확인할 때는 먼저 앱에서 선택된 항목과 스위치를 살펴본 다음 시스템의 VPN 상태를 확인하세요. 상태 표시줄의 아이콘 하나만 보고 모든 트래픽의 경로를 판단하지 마세요.

VPN 구성 추가에 대한 시스템 안내

앱이 필요한 네트워크 연결을 설정하려고 하면 시스템에서 VPN 구성을 추가할지 확인합니다. 이는 Apple 시스템이 연결 권한을 관리하는 절차이지, 구매 확인이나 구독 로그인 절차가 아닙니다. Shadowrocket에서 직접 작업하던 중 표시된 안내인지 확인한 뒤 시스템의 설명에 따라 허용하고 기기에서 요구하는 인증을 완료하세요. 확인 전에 진행 중인 작업을 저장하면 앱을 전환한 뒤 안내가 어느 단계에서 나왔는지 놓치는 일을 줄일 수 있습니다.

이전에 권한을 취소했다면 앱으로 돌아가 연결을 다시 요청할 수 있는지 확인하고 현재 시스템 안내에 따라 진행하세요. 시스템 설정의 경로는 화면 구성에 따라 달라질 수 있으므로 설정 검색에서 VPN을 찾아 Shadowrocket 구성이 있는지와 현재 상태를 확인하세요. 용도를 모르는 구성을 여러 개 추가하지 말고, 재시도하려고 현재 사용하는 다른 네트워크 구성을 삭제하지도 마세요. 먼저 어떤 구성인지 확인한 후 처리하세요.

조직에서 관리하는 기기는 네트워크 구성이 관리 정책에 의해 제한될 수 있습니다. 안내 내용을 확인할 수 없거나 구성을 추가할 수 없는 경우, 또는 스위치를 켜도 바로 원래 상태로 돌아가는 경우에는 기기 제한 여부를 확인하고 기기 관리자에게 허용되는 설정을 문의하세요. 구독을 반복해서 가져와도 시스템 정책은 바뀌지 않습니다. 문제를 확인할 때는 “반응이 없다”는 막연한 설명보다 정확한 시스템 안내 문구를 기록하는 편이 도움이 됩니다.

첫 설정의 기준 상태 만들기

처음 설정할 때는 수동 연결을 유지하고 On Demand는 아직 활성화하지 마세요. 서버 준비, 기본 항목 선택, 라우팅 방식 확인, 연결 시작, 접속 확인 순서로 작업하세요. 상태가 바뀌면 직전에 한 작업과 연관 지을 수 있습니다. 자동 연결을 동시에 켜고 구성을 수정하고 구독까지 업데이트하면 연결이 복구되거나 끊긴 원인을 찾기 어렵고, 변경 사항이 실제로 적용됐는지도 확인하기 힘듭니다.

첫 권한 설정을 마친 뒤 앱이 계속 켜져 있는지, 시스템에 해당 연결이 표시되는지 기록하세요. 스위치가 켜진 상태를 유지하지 못하면 권한, 구성 유효성, 오류 메시지를 먼저 확인하세요. 스위치는 유지되지만 접속에 실패한다면 연결 확인 절차로 넘어가세요. 두 경우는 서로 다른 문제 해결 경로입니다. “권한 허용”, “스위치 켜짐”, “목표 접속 성공”을 하나의 성공 조건으로 묶지 마세요.

이 장을 마치면 Home에서 연결, 라우팅, 테스트, 서버 선택 영역을 구분하고 시스템 권한이 승인됐는지 확인할 수 있어야 합니다. 아직 모든 대상에 접속할 필요는 없지만 서버 정보, 권한 확인, 연결 검증 중 무엇이 남았는지는 파악해야 합니다. 가장 빠른 순서로 진행하려면 사용 튜토리얼로 돌아가세요. 매개변수의 출처와 가져오기 범위를 이해하려면 다음 장으로 이어가세요.

서버 및 구독 가져오기

가져오기 전에 받은 정보가 단일 서버 정보인지, 서버 공유 정보인지, 구독 링크인지, 구성 파일인지 확인하세요. 각 항목의 용도는 다릅니다. 서버 항목에는 한 번 연결하는 데 필요한 매개변수가 저장되고, 구독은 여러 서버 목록을 업데이트하며, 구성 파일은 라우팅과 관련 설정을 관리합니다. 구성 파일 주소를 구독 입력란에 넣거나 일반 웹 주소를 서버 주소 입력란에 넣으면 파싱에 실패하거나 예상과 다른 내용이 표시될 수 있습니다.

수동 추가 및 프로토콜 매개변수 확인

Add Server로 직접 추가할 때는 프로토콜을 선택하고 주소와 포트를 입력한 다음 인증 및 전송 매개변수를 확인하세요. 각 항목에는 사용자가 이미 보유한 서비스 정보를 입력해야 하며 이름만 보고 추측하면 안 됩니다. 같은 도메인이라도 포트가 다를 수 있고 같은 포트에서 서로 다른 프로토콜을 사용할 수도 있습니다. 입력란을 모두 채웠다고 조합이 정확한 것은 아닙니다. 저장 후 편집 화면을 다시 열어 항목별로 확인하세요. 복사 과정에서 공백, 줄바꿈, 전각 문자가 들어가지 않았는지도 살펴보세요.

이 표는 확인 방향만 안내하며 모든 프로토콜에 같은 항목을 입력해야 한다는 뜻은 아닙니다. 서비스 정보에 전송 경로, 호스트 이름, TLS 서버 이름이 있다면 각각의 용도에 맞게 입력하세요. 모두 주소 입력란에 복사하지 마세요. 서버 주소는 연결할 엔드포인트를 지정하고 TLS 관련 이름은 해당 인증에 사용됩니다. 두 값은 같을 수도, 서비스 설정에 따라 다를 수도 있으며 서로 대신 사용할 수 없습니다.

기존 구독 가져오기 및 결과 확인

이미 구독이 있다면 앱의 추가 메뉴에서 Subscribe를 선택하고 전체 구독 주소를 입력한 뒤 저장하세요. 이후 해당 업데이트 작업을 실행합니다. 구독 링크에는 접근 인증 정보가 포함되는 경우가 많으므로 복사할 때는 전체 내용을 유지하되 공개 채팅, 스크린샷, 문의 내용에 노출하지 마세요. 가져오기가 끝나면 SERVER 목록으로 돌아가 예상한 그룹과 항목이 표시되는지 확인하세요. 구독 이름만 보인다고 서버 내용을 가져온 것은 아닙니다.

목록이 비어 있다면 업데이트가 완료되지 않은 것인지, 요청이 실패한 것인지, 응답 내용을 인식하지 못한 것인지 먼저 확인하세요. 링크의 시작과 끝, 쿼리 매개변수가 온전한지 확인하고 계정 관리 웹페이지가 아니라 구독 주소를 받은 것이 맞는지 살펴보세요. 그런 다음 원래 서비스 제공자에게 구독 상태와 지원하는 형식을 문의하세요. 같은 주소를 연속해서 추가하면 이름이 같은 그룹이 여러 개 생겨 이후 업데이트와 삭제가 더 복잡해질 수 있습니다.

구독을 업데이트하면 서버 항목이 추가·삭제되거나 수정될 수 있으므로 단순히 화면을 새로 고치는 작업이 아닙니다. 업데이트 전에 현재 기본 서버가 속한 그룹을 기록하고, 업데이트 후 선택이 여전히 유효한지 확인하세요. 서버 이름이 바뀌었다면 이전 메모만 보고 항목이 사라졌다고 판단하지 말고 그룹과 서비스 제공자 안내를 함께 확인하세요. 빈 목록이나 파싱 오류에 대해서는 구독 파싱 실패 자가 점검을 참고하세요.

공유 정보·QR 코드·구성 파일 가져오기

Scan QR Code로 가져올 때는 QR 코드가 본인이 보유한 서비스의 신뢰할 수 있는 자료에서 나온 것인지 먼저 확인하고, 가져온 뒤 표시되는 프로토콜, 주소, 메모를 살펴보세요. QR 코드 스캔은 직접 입력을 줄여 줄 뿐 원격 서비스의 품질이나 매개변수의 유효성을 확인해 주지는 않습니다. QR 코드가 같은 기기에 표시되어 있다면 앱에서 제공하는 적절한 가져오기 방법을 사용하세요. 인증 정보가 포함된 이미지를 공개 QR 코드 인식 서비스에 넘기지 마세요.

공유 정보를 가져온 뒤 저장된 항목이 단일 서버인지 구독인지 확인하세요. 단일 항목은 이후 자동 업데이트를 보장하지 않지만 구독에 포함된 항목은 업데이트 중 바뀔 수 있습니다. 가져온 뒤 편집 화면의 값이 원본 자료와 다르면 원본을 보관하고 프로토콜 지원 여부와 매개변수 대응을 항목별로 확인하세요. 비교 기준을 잃지 않도록 바로 기존에 작동하던 서버를 덮어쓰지 마세요.

구성 파일을 가져온 뒤 Config에서 현재 활성화된 파일이 무엇인지 확인하세요. 파일을 저장한 것과 활성화한 것은 서로 다른 상태입니다. 규칙이 포함된 구성을 가져오기 전에 전략 참조, 최종 규칙, DNS 설정을 살펴보고 추가 규칙 리소스에 의존하는지 확인하세요. 존재하지 않는 전략을 참조하는 파일은 열리기만 한다고 라우팅 로직이 완전한 것이 아닙니다. 다음 장에서는 이러한 규칙과 Global Routing의 관계를 설명합니다.

이 장을 마치면 목록에서 서버를 식별할 수 있고, 정보의 출처가 분명하며, 주요 매개변수를 원본 자료와 대조할 수 있고, 구독 업데이트 결과를 확인할 수 있어야 합니다. 마지막으로 기본 서버를 별도로 선택하세요. 편집을 마친 화면에 머물러 있다고 선택된 것은 아닙니다. 작동하는 매개변수를 복구 기준으로 남겨 둔 뒤 라우팅을 설정하면 가져오기 문제와 라우팅 문제를 구분할 수 있습니다.

라우팅 방식 세 가지와 규칙 순서

Global Routing에는 Config, Proxy, Direct 세 가지 방식이 있습니다. 각 방식은 연결에 적용할 라우팅 판단 기준을 바꾸지만 서버 비밀번호를 채워 주거나 원격 서비스 오류를 해결하지는 않습니다. 문제를 확인하기 전에 현재 방식을 살펴보세요. 특히 서버 테스트 결과는 있지만 특정 앱에서 예상대로 접속되지 않을 때는 규칙이 다른 정책을 선택했을 수 있으며, 기본 서버가 작동하지 않는다고 단정할 수 없습니다.

트래픽 경로를 결정하는 항목 확인

Config는 대상별로 연결을 처리하는 데 적합하지만, 현재 구성의 내용이 명확해야 합니다. Proxy는 프록시 경로가 기본적으로 작동하는지 확인할 때 쓸 수 있지만 모든 특수 트래픽과 시스템 동작이 똑같이 처리된다고 볼 수는 없습니다. Direct도 앱을 “중지”한다는 뜻은 아닙니다. 현재 연결을 끝내려면 연결 스위치를 사용하고, 라우팅의 영향을 비교하려면 Global Routing을 전환하세요.

위에서 아래로 규칙 읽기

규칙은 보통 순서대로 확인하며 먼저 일치하는 적용 규칙이 해당 정책을 결정합니다. 구체적인 조건은 앞에, 범위가 넓은 조건은 뒤에 두고, 마지막에는 일치하지 않는 연결을 처리하는 FINAL을 둡니다. 범위가 넓은 규칙을 너무 앞에 두면 뒤의 구체적인 규칙이 적용되지 않을 수 있습니다. 문제를 확인할 때 도메인 이름이 규칙에 있는지만 검색하지 말고, 앞선 규칙과 각 규칙이 참조하는 정책도 읽어보세요.

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

아래는 문법 예시이며 모든 환경에 적용할 수 있는 완성 구성은 아닙니다. DOMAIN은 지정한 도메인에, DOMAIN-SUFFIX는 도메인 접미사에, DOMAIN-KEYWORD는 도메인에 포함된 키워드에, IP-CIDR은 IP 주소 대역에 적용됩니다. GEOIP는 해당 IP 데이터에 의존하므로 대상 서비스의 소속을 절대적으로 판단하는 기준으로 삼을 수 없습니다. FINAL은 마지막 기본 규칙이며 사용자가 예상하는 기본 경로와 일치해야 합니다.

예시에서는 정확한 도메인 규칙이 키워드 규칙보다 앞에 있습니다. 따라서 키워드에 example이 포함되어 있다는 이유만으로 관련된 모든 요청이 직접 연결된다고 단정할 수 없습니다. 마찬가지로 도메인 규칙과 주소 규칙은 서로 다른 정보를 기준으로 합니다. 실제 연결에서 어떤 매칭 정보를 제공하는지도 결과에 영향을 줍니다. 브라우저 주소창에 표시된 페이지 이름만 보고 그 페이지의 모든 요청이 단일 도메인을 사용한다고 판단하지 마세요.

규칙·정책·현재 구성 구분

PROXY, DIRECT, REJECT는 규칙에서 자주 사용하는 정책 키워드이며 각각 기능이 다릅니다. 규칙이 사용자 지정 정책 이름을 참조한다면 해당 정책 정의가 실제로 존재하는지, 최종적으로 어느 서버를 사용하는지 확인하세요. 파일 문법이 올바르더라도 정책 이름의 철자가 다르면 예상대로 작동하지 않을 수 있습니다. 수정할 때는 대소문자, 구분 기호, 필드 순서를 유지하고 영문 쉼표를 전각 쉼표로 바꾸지 마세요.

Config에는 여러 파일이 저장될 수 있습니다. 파일을 수정했다면 먼저 저장하고, 현재 사용 중인 파일이 맞는지 확인한 다음 앱 안내에 따라 연결에 새 구성을 적용하세요. 파일 이름만 바꿔도 규칙 내용은 바뀌지 않으며 원격 구성 업데이트가 로컬 수정 사항을 덮어쓸 수 있습니다. 사용자 지정 규칙을 계속 유지해야 한다면 관리 위치를 분명히 하고 업데이트 전에 사본을 보관하세요. 출처가 불분명한 파일에 모든 변경 사항을 쌓아 두지 마세요.

특정 대상에서만 문제가 생기면 먼저 Proxy와 Config 결과를 임시로 비교하세요. 프록시 경로는 정상인데 구성 경로에서 실패한다면 규칙과 정책을 중점적으로 확인하세요. 두 방식 모두 실패한다면 서버와 원격 상태를 다시 살펴보세요. 비교가 끝나면 원래 필요한 방식으로 되돌려 임시 점검 상태를 장기 설정으로 남기지 마세요. 테스트할 때는 한 번에 조건 하나만 바꾸고 변화를 기록해야 원인과 결과를 파악할 수 있습니다.

규칙 매칭은 한 번 설정하면 영구히 동일한 결과를 내는 것이 아닙니다. 대상 서비스는 여러 도메인과 주소, 연결 방식을 사용할 수 있으며 구성 업데이트로 규칙 순서가 바뀔 수도 있습니다. 예시 규칙이 있다는 것만 확인하고 끝내지 말고 실제 사용 상황에서 검증하세요. DNS와 주소 판단에 관한 내용은 7장을 참고하고, 흔한 증상은 자주 묻는 질문에서 확인하세요.

연결 확인 및 단계별 문제 해결

연결 성공 여부는 여러 단계로 나눠 확인해야 합니다. 기본 네트워크 사용 가능 여부, 서버 매개변수 유효성, 시스템의 연결 허용 여부, 현재 라우팅의 적합성, 실제 대상의 요청 완료 여부를 각각 살펴보세요. 어느 한 단계에 문제가 있어도 “연결 안 됨”으로 보일 수 있지만 해결 방법은 다릅니다. 먼저 스위치가 유지되지 않는지, 테스트가 시간 초과되는지, 특정 대상만 실패하는지, 네트워크를 바꾼 뒤 문제가 생겼는지 등 증상을 구체적으로 정리한 다음 적절한 확인 절차를 선택하세요.

재현 가능한 연결 절차

먼저 현재 Wi-Fi 또는 셀룰러 네트워크에서 정상적으로 인터넷을 사용할 수 있는지 확인하세요. 네트워크 연결을 위해 별도 인증이 필요하다면 먼저 절차를 완료하세요. 그런 다음 Home으로 돌아가 SERVER 목록에서 확인할 서버를 선택하고 기본 선택 표시가 해당 항목에 있는지 확인합니다. 항목을 눌러 상세 정보에 들어간 것을 기본 서버 선택으로 착각하지 마세요. 그룹이 다르면 이름이 같은 서버가 있을 수 있으므로 메모만 보고 판단해서도 안 됩니다.

다음으로 Global Routing을 확인하세요. 첫 연결을 테스트할 때는 명확한 프록시 경로를 선택하고 연결을 켠 다음 시스템 권한 안내에 따르세요. 상태가 안정되면 Connectivity Test를 실행하고 브라우저나 실제로 사용할 앱에서 새 요청을 보내세요. 기본 서버 선택과 첫 테스트를 이어서 진행하는 방법은 첫 연결 및 테스트 안내를 참고하세요.

테스트할 때는 네트워크, 서버, 대상을 가능한 한 동일하게 유지하고 한 번에 모두 바꾸지 마세요. 페이지가 캐시되어 있거나 앱이 이전 연결을 재사용할 수 있으므로 실제로 새 요청이 생성됐는지 고려해야 합니다. 이미 로드된 페이지를 보는 것만으로 네트워크가 정상이라고 오판할 수 있습니다. 명확한 동작을 다시 실행하고 연결 기록에 대상과 일치하는 새 활동이 있는지 확인하세요.

테스트 결과와 실제 접속 결과 구분

Connectivity Test 결과는 현재 테스트 조건에서의 연결 상태를 보여 줄 뿐 원격 서비스 전체의 동작을 보장하지 않습니다. 테스트 결과는 있지만 실제 대상에 접속되지 않는다면 대상 자체, DNS, 규칙, 앱의 연결 방식이 원인일 수 있습니다. 테스트가 시간 초과돼도 저장한 모든 항목이 잘못됐다고 바로 판단할 수는 없습니다. 먼저 다른 보유 서버와 비교하고, 같은 서버를 다른 기본 네트워크에서 테스트해 문제 범위를 좁히세요.

연결 스위치가 바로 꺼지면 앱 안내와 시스템 VPN 상태를 먼저 보고 권한과 구성이 유효한지 확인하세요. 스위치는 켜져 있지만 모든 요청이 실패한다면 기본 서버, 프로토콜, 포트, 인증 정보를 확인한 다음 원격 서비스 상태를 살펴보세요. Config에서만 실패한다면 현재 활성 파일과 규칙 정책을 확인하세요. 특정 앱에서만 문제가 생기면 전체 구성을 바로 초기화하지 말고 해당 앱의 도메인과 요청을 살펴보세요.

일시적인 끊김과 반복 재현되는 문제도 구분하세요. 잠금 화면에서 돌아오거나 네트워크가 바뀌거나 원격 연결이 다시 설정되는 동안 일시적인 상태가 나타날 수 있습니다. 현재 동작이 끝날 때까지 기다린 뒤 새 테스트를 진행하세요. 같은 단계에서 문제가 반복된다면 발생 조건을 기록하고, 간헐적인 문제라면 여러 하위 매개변수를 한꺼번에 바꾸지 마세요. 변경을 계속 쌓으면 문제가 잠시 가려질 수 있지만 재현 조건이 사라져 이후 관리가 어려워집니다.

최소한의 변경으로 문제 단계 찾기

보유한 서버 여러 개에서 문제가 발생한다면 공통 조건부터 확인하세요. 같은 기본 네트워크, 같은 구성 파일, 같은 DNS 설정, 같은 시스템 제한을 공유하는지 살펴보세요. 서버 하나에서만 문제가 생긴다면 해당 항목의 매개변수와 원격 상태를 중점적으로 확인해야 합니다. 이런 식으로 그룹을 나눠 판단하는 편이 항목을 무작정 수정하는 것보다 효율적입니다. 비교를 위해 정상 작동을 확인한 항목 하나를 기준으로 남겨 두고, 기존 값을 기록하기 전에 인증 매개변수를 덮어쓰지 마세요.

TLS 또는 인증 오류가 발생하면 기기 시간, 서버 이름 요구 사항, 원본 매개변수를 확인하세요. 확인을 건너뛰기 위해 인증 기능을 임의로 끄지 마세요. 도메인 해석 오류가 발생하면 서버 도메인을 해석할 수 없는 것인지, 접속 대상 도메인 처리에 문제가 있는지 먼저 구분해야 합니다. 시간 초과가 발생하면 네트워크, 포트, 원격 상태를 함께 살펴보세요. 같은 오류 문구가 항상 같은 원인을 뜻하지는 않습니다.

추가 도움을 요청할 때는 개인 정보를 가린 증상, 프로토콜 종류, 네트워크 종류, Global Routing 방식, 이미 완료한 비교 테스트를 제공하세요. 구독 주소 전체, 비밀번호, UUID, 키, 쿼리 매개변수가 포함된 주소는 공개하지 마세요. 오류 메시지에서 원인과 관련된 부분은 남겨도 되지만 서버 식별 정보는 가려야 합니다. 원래 서비스 제공자에게 문의할 때는 전체 구성을 보내기보다 어떤 항목과 네트워크에서 재현되는지 설명하는 편이 명확합니다.

이 장을 마칠 때는 기본 연결이 정상인지, 아니면 문제가 권한·매개변수·라우팅·해석·대상 서비스 중 어느 단계로 좁혀졌는지 확인할 수 있어야 합니다. 연결이 정상이라면 필요한 Config 방식으로 되돌린 뒤 주요 대상이 예상대로 작동하는지 확인하세요. 다음으로 Data에서 실제 트래픽을 살펴보세요. 한 번의 테스트 수치를 장기적인 연결 품질의 전체 증거로 간주하지 마세요.

트래픽 통계 및 연결 확인

Data에서는 앱이 제공하는 트래픽 정보와 관련 연결 활동을 확인할 수 있습니다. “트래픽이 발생했는지”, “어떤 작업으로 변화했는지”, “통계 범위가 무엇인지” 파악하는 데 유용합니다. 단, 서비스 제공자의 계정 정산 기록과 같은 측정 시스템은 아닙니다. 수치를 살펴보기 전에 화면의 시간 범위, 통계 대상, 단위를 확인하세요. 범위가 다른 데이터를 바로 비교하지 말고 증가 여부를 판단해야 합니다.

비교 전 통계 기준 확인

업로드와 다운로드는 데이터 전송 방향을 각각 나타내며, 순간 속도와 누적 데이터 양도 서로 다릅니다. 속도는 특정 시간 구간의 전송 속도이고 누적량은 해당 범위에서 전송된 데이터의 총량입니다. 화면의 순간적인 변화만으로 한 달 사용량을 계산할 수 없습니다. 반대로 일정 시간 동안 속도가 눈에 띄지 않았다고 해서 그 전에 백그라운드 전송이 없었다고 단정할 수도 없습니다. 관찰 시작·종료 시간과 실제 작업을 함께 고려하세요.

클라이언트 통계, 시스템의 셀룰러 데이터 통계, 서비스 제공자 기록은 측정 범위, 세션, 갱신 시점, 프로토콜 오버헤드가 달라 서로 차이가 날 수 있습니다. 서비스 용량을 확인할 때는 보유한 서비스 계정 기록과 측정 안내를 기준으로 하세요. 수치가 다르면 차이만 보고 어느 한쪽의 오류라고 단정하지 말고 동일한 기간, 기기, 연결 범위를 비교하는지 먼저 확인하세요.

통계를 초기화하거나 정리할 예정이라면 현재 필요한 관찰 결과를 먼저 저장하고 어떤 로컬 기록에 영향을 주는지 확인하세요. 클라이언트 수치를 초기화해도 원격 계정의 용량이 복구되거나 이미 전송된 데이터가 바뀌지 않습니다. 숫자를 0으로 보이게 하려고 반복해서 지우면 기간별 비교의 기준이 사라집니다. 장기간 기록이 필요하다면 시간, 네트워크, 사용 상황도 함께 적어 두세요.

단일 작업으로 트래픽 변화 관찰

특정 작업이 예상한 트래픽을 발생시키는지 확인하려면 현재 수치를 기록하고 다른 앱의 활동을 잠시 줄인 다음 페이지 새로고침처럼 범위가 분명한 작업 하나를 실행하세요. 작업이 끝나면 Data로 돌아가 관련 기록이 어떻게 바뀌었는지 비교합니다. 미디어 재생, 사진 동기화, 앱 업데이트를 동시에 하면 총량 증가의 원인을 특정 페이지로 돌리기 어렵고 수치의 문제 해결 가치도 떨어집니다.

백그라운드 동기화, 알림, 앱 자체 새로고침도 연결을 발생시킬 수 있습니다. 사용자가 직접 누르지 않았다고 해서 기기의 네트워크 활동이 전혀 없는 것은 아닙니다. 트래픽이 계속 증가하면 구체적인 연결 기록을 분석하기 전에 시스템과 앱에서 진행 중인 작업부터 확인하세요. 미디어 캐시와 미리 불러오기로 실제 전송량이 화면에 현재 보이는 콘텐츠보다 많을 수도 있습니다. 이런 현상은 사용 상황을 고려해 해석해야 합니다.

라우팅이 올바른지 확인할 때 트래픽 증가는 전송이 있었다는 사실만 보여 줄 뿐 예상한 규칙이 적용됐다는 증거는 아닙니다. 구체적인 대상, 연결 기록, 라우팅 정책을 함께 확인하세요. 특히 Config에서는 페이지를 한 번 불러와도 여러 도메인에 요청이 발생할 수 있고 요청마다 다른 정책이 적용될 수 있습니다. 총량 변화로 4장의 규칙 확인을 대신할 수 없으며 앱 전체가 항상 같은 경로를 사용한다고 단정해서도 안 됩니다.

연결 정보 확인 및 기록 보호

앱의 연결 정보에 대상, 정책, 오류 같은 항목이 표시된다면 특정 요청을 기준으로 살펴보세요. 먼저 작업이 발생한 시간을 확인하고 해당 대상을 찾은 다음 적용된 정책과 결과를 확인합니다. 백그라운드 요청이 동시에 발생할 수 있으므로 목록 첫 번째 항목이 방금 연 페이지와 관련 있다고 단정하지 마세요. 대상이 공유 도메인이나 주소를 사용한다면 이름 일부만 보고 특정 앱의 요청이라고 판단해서도 안 됩니다.

기록에는 접속 도메인, 주소, 시간 및 기타 네트워크 세부 정보가 포함될 수 있으므로 내보내거나 스크린샷을 찍기 전에 내용을 확인하세요. 문제를 공유할 때는 오류와 관련된 항목만 남기고 개인 서비스 정보와 인증 정보를 가리세요. 전체 로그에 무관한 활동이 노출된다면 오류가 발생한 시간과 필요한 필드만 추려서 제공하세요. 문제 해결에는 원본 데이터의 양보다 명확한 맥락이 중요합니다.

실패한 연결이 계속 많이 발생하면 같은 대상, 정책, 시간대에 집중되는지 먼저 확인하세요. 동일한 대상에 반복 요청이 발생해 기록이 빠르게 늘어날 수 있지만, 그만큼 유효한 데이터가 전송됐다는 뜻은 아닙니다. 기록 수만 보고 서버 부하를 판단하지 말고 대상과 라우팅 단계로 돌아가 원인을 확인하세요. 통계 기준이 분명해야 항목 수와 데이터 양을 비교할 수 있습니다.

관찰이 끝나면 임시 테스트와 일상 사용을 구분해 기록하세요. 장기 관리에는 주요 오류, 변경 전후 결과, 필요한 기준값만 보관하면 됩니다. 모든 세부 정보를 계속 모을 필요는 없습니다. Data에 활동이 정상적으로 표시되는데도 대상에 문제가 있다면 응답 성공 여부, 콘텐츠 완전성, 앱 자체 상태를 계속 확인하세요. 데이터가 전송됐다는 사실은 연결에서 활동이 있었다는 뜻일 뿐 요청이 완료됐다는 의미는 아닙니다.

자주 사용하는 설정 및 자동 연결

Settings를 변경하기 전에 수동 연결이 정상적으로 작동하는지 확인하세요. 해결하려는 문제를 명확히 정하고 해당 설정만 조정한 뒤 기존 값을 보관하세요. 앱 설정, 현재 구성 파일, 시스템 네트워크 설정이 같은 연결에 각각 영향을 줄 수 있으므로 문제 해결 기록에는 수정한 계층을 적어야 합니다. “DNS 변경”이나 “자동 연결 켬”이라고만 적지 말고 위치, 변경 전 상태, 검증 결과를 기록하세요.

DNS: 이름 해석이 이뤄지는 위치 이해

DNS는 도메인 이름을 이후 연결에 필요한 주소 정보로 변환합니다. 연결 실패는 해석 전, 해석 중, 주소를 얻은 후에 발생할 수 있으므로 DNS를 바꾼다고 모든 시간 초과가 해결되지는 않습니다. 해석되지 않는 것이 서버 도메인인지 접속 대상 도메인인지 먼저 확인한 다음 현재 구성의 관련 설정을 살펴보세요. 서버 주소를 해석할 수 없으면 연결할 엔드포인트가 정해지지 않은 상태입니다. 대상 도메인에 문제가 있다면 현재 라우팅과 해석 경로를 함께 분석해야 합니다.

시스템 DNS, 사용자 지정 DNS, DNS over HTTPS는 작동 방식이 다릅니다. 선택할 때는 현재 네트워크에서 해당 해석 서비스를 사용할 수 있는지 고려하세요. 암호화 전송은 DNS 요청을 보내는 방법 중 하나일 뿐 모든 네트워크 조건에 적합하다는 뜻은 아닙니다. DNS 설정을 바꾼 뒤에는 같은 대상과 같은 서버로 결과를 비교하세요. 네트워크까지 동시에 바꾸면 원인을 판단하기 어렵습니다. 자세한 원리는 DNS 설정 비교 안내를 참고하세요.

[General]
dns-server = system

이 예시는 구성 파일에서 시스템 DNS를 설정하는 위치를 보여 줍니다. 완전한 구성도 아니고 모든 환경에 적용할 수 있는 정답도 아닙니다. General 섹션에 속하는 설정이므로 Rule 섹션에 넣지 마세요. 현재 파일에 같은 이름의 설정이 있다면 값을 비롯해 관련 항목을 먼저 읽고 수정 여부를 결정하세요. 중복 정의는 설정을 이해하기 어렵게 만들 수 있습니다. 저장 후 해당 파일이 활성화되어 있는지 확인하고 앱 안내에 따라 다시 검증하세요.

캐시는 짧은 시간 동안의 비교 결과에 영향을 줄 수 있습니다. 같은 대상이 이미 받아 둔 결과를 계속 사용하거나 앱이 기존 연결을 재사용할 수 있습니다. 설정을 바꾼 직후 이전 페이지가 표시된다고 적용되지 않았다고 판단하지 말고 새 요청과 연결 기록을 함께 확인하세요. 특정 대상 하나에서만 문제가 생긴다면 전체 DNS 정책을 복잡하게 바꾸기보다 해당 대상 기록과 규칙을 먼저 살펴보세요.

On Demand: 수동 연결 확인 후 자동 실행

On Demand는 설정한 조건에 따라 연결을 관리합니다. 서버 상태를 복구하는 기능도, 첫 수동 권한 설정을 대신하는 기능도 아닙니다. 활성화하기 전에 선택한 서버가 작동하고 Config 동작이 올바른지 확인한 다음 앱에서 제공하는 조건 옵션을 읽어보세요. 설명할 수 있는 조건만 추가하고, 조건을 충족하는 경우와 충족하지 않는 경우의 상태를 각각 확인해 자동 연결이 예상과 다르게 작동하는 원인을 놓치지 않도록 하세요.

자동 실행을 확인할 때는 현재 네트워크, 연결 상태, 트리거 동작을 기록하세요. 예를 들어 네트워크가 바뀐 뒤 앱이 설정대로 동작하는지 관찰하고 실제 접속도 확인합니다. 스위치가 다시 켜졌다는 이유만으로 원격 연결이 성공했다고 판단하지 마세요. 수동으로 연결을 끊은 뒤 다시 연결되면 시스템 구성을 반복해서 삭제하기보다 On Demand가 여전히 활성화되어 있는지, 현재 조건이 다시 충족됐는지 먼저 확인하세요.

연결 관련 옵션과 변경 원칙

프로토콜의 TLS, 전송 방식, 기타 매개변수는 보유한 서비스의 요구 사항에 따라 설정해야 합니다. 임의로 조정해도 되는 일반 최적화 옵션이 아닙니다. 호환성 문제를 해결하려면 서버 측 지원 범위를 먼저 확인하세요. 오류를 조사하려면 기존 매개변수를 보관하고 오류가 어떻게 바뀌는지 기록하세요. 이름에 네트워크가 들어 있다는 이유만으로 옵션을 켜면 기존 연결 조건이 바뀌어 원래 문제와 새 문제가 뒤섞일 수 있습니다.

구성 파일과 화면 설정에 관련 항목이 모두 있더라도 우선순위가 항상 같다고 가정하지 마세요. 현재 파일, 앱 안내, 실제 연결 결과를 확인해 어떤 설정이 적용되는지 파악하세요. 원격 구성을 업데이트한 뒤에는 이전에 사용하던 설정이 유지되는지도 확인해야 합니다. 용도를 모르는 옵션은 검증된 상태로 유지하는 편이 일괄 변경보다 관리하기 쉽습니다. 설정을 바꿔야 한다면 사본을 만들어 범위를 제한해 검증하세요.

변경할 때마다 기존 값, 목적, 결과, 되돌리는 방법만 기록하면 됩니다. 목적은 막연히 속도를 높이는 것이 아니라 특정 도메인이 해석되는지 확인하는 것처럼 구체적이어야 합니다. 결과는 재현 가능해야 하며 순간적인 페이지 로딩 느낌만으로 판단하지 마세요. 개선되지 않으면 다음 항목을 시도하기 전에 기존 값으로 되돌리세요. 이렇게 하면 이유를 모르는 설정이 쌓이는 것을 막고 다음 장의 유지 관리에 필요한 기준을 마련할 수 있습니다.

백업·업데이트·일상적인 유지 관리

일상적인 유지 관리의 목표는 설정을 계속 늘리는 것이 아니라 이해하고 복구할 수 있는 상태를 유지하는 것입니다. 현재 기본 서버, 구독 출처, 활성 Config, Global Routing 방식, 자동 연결 조건을 파악해 두세요. 문제가 생기면 최근에 무엇이 바뀌었는지 판단하는 데 도움이 되고, 기기를 바꿀 때는 복원 목록으로도 사용할 수 있습니다. 앱 화면 스크린샷 하나만으로는 전체 상태를 복원하기 어렵습니다.

서버·구독·구성별 백업

백업하기 전에 대상을 구분하세요. 서버 매개변수는 연결 엔드포인트와 인증 방식을 정하고, 구독 링크는 서버 목록을 다시 가져오는 데 사용하며, 구성 파일은 라우팅과 관련 설정을 저장합니다. 한 종류의 내보내기 파일에 다른 데이터가 모두 포함된다고 볼 수 없으므로 실제 백업 내용을 확인하세요. 앱에서 제공하는 내보내기 또는 백업 기능을 사용할 때는 안내를 읽고 민감 정보 포함 여부와 계정 등 추가 복원 조건이 필요한지 확인하세요.

백업은 직접 관리할 수 있는 보호된 위치에 저장하고 공개 링크로 공유하지 마세요. 구독 주소, 비밀번호, UUID, 키는 모두 민감 정보로 취급해야 합니다. 백업이 어떤 구성과 사용 상황에 해당하는지 알아볼 수 있게 설명을 덧붙이되 파일 이름에 인증 정보를 전부 적지는 마세요. 서비스 정보가 바뀌었다면 이전 백업이 더 이상 유효하지 않을 수 있습니다. 복원할 때 잘못 사용하지 않도록 필요한 변경 이력을 남겨 두세요.

기기를 바꾸기 전에 한 번 복원 절차를 점검하는 것이 좋습니다. 원래 구매 내역을 찾을 수 있는지, 보유한 구독이나 서버 정보를 찾을 수 있는지, 구성 파일의 정책 참조를 이해할 수 있는지 확인하세요. 현재 데이터를 삭제할 필요는 없으며 사본으로 점검하면 됩니다. “전에 내보낸 적이 있다”는 기억만으로 준비가 끝났다고 여기지 말고 실제 복원에 필요한 자료가 있는지 확인하세요. 기기를 잃어버린 뒤 기기에만 저장된 링크 하나를 찾으려 하면 복구 방법이 없어질 수 있습니다.

업데이트 후 일정한 순서로 확인

업데이트는 앱, 구독, 구성 업데이트로 나뉩니다. 앱 업데이트는 App Store에서 관리하고, 구독 업데이트는 서버 목록을 바꿀 수 있으며, 구성 업데이트는 규칙·정책·해석 설정을 바꿀 수 있습니다. 한 번의 문제 해결 과정에서 세 가지를 모두 업데이트하지 마세요. 어떤 변경이 결과에 영향을 줬는지 확인하기 어렵습니다. 한 종류의 업데이트를 마칠 때마다 다음 작업 전에 기본 연결과 주요 대상을 확인하세요.

구독을 업데이트한 뒤에는 기본 서버가 여전히 있는지 확인한 다음 그룹과 항목의 변화를 살펴보세요. 구성을 업데이트한 뒤에는 활성 파일, 최종 규칙, 사용자 지정 정책을 확인하고 로컬 수정 사항이 유지됐는지 점검하세요. 앱 업데이트 후에는 권한 상태, 연결 스위치, 자동 실행 조건을 확인하세요. 모든 웹사이트를 테스트할 필요는 없지만 일상적으로 사용하는 주요 대상과 직접 연결이 필요한 로컬 네트워크 사용 환경은 확인해야 합니다.

문제가 생기면 기록된 변경 사항 중 가장 최근 항목부터 되돌리세요. 구독 내용이 바뀌었다면 원래 서비스 제공자에게 상태를 확인하세요. 기존 항목으로 새 목록 전체를 억지로 덮어쓰지 마세요. 구성 규칙이 바뀌어 문제가 생겼다면 저장해 둔 사본과 차이를 비교하세요. 롤백은 확인된 상태로 복구하고 원인을 찾기 위한 것이지, 이전 내용이 무기한 유효하다는 뜻은 아닙니다. 원격 서버가 더 이상 작동하지 않는다면 클라이언트에서 이전 설정으로 되돌려도 복구되지 않습니다.

구성 정리 및 문제 해결 기록

중복 구독, 용도를 알 수 없는 구성, 사용할 수 없는 항목을 주기적으로 정리하되 삭제 전에 아직 사용 중인지 확인하세요. 특히 이름이 같은 파일이나 서버는 이름만 보고 현재 유효한 항목을 삭제하지 않도록 주의해야 합니다. 테스트용과 일상용 구성은 식별하기 쉬운 메모로 구분하고 출처와 용도를 기록하세요. 사본마다 알아보기 어려운 번호를 붙이지 마세요. 용도가 분명한 복구용 사본을 몇 개만 남기는 편이 과거 파일을 전부 쌓아 두는 것보다 관리하기 쉽습니다.

문제 해결 기록에는 판단에 필요한 정보만 남기세요. 발생 조건, 오류 증상, 기본 서버 종류, 라우팅 방식, 최근 변경 사항, 비교 테스트 결과를 기록하면 됩니다. 구독 인증 정보와 개인 접속 세부 정보는 삭제하세요. 변경으로 문제가 해결됐다면 최종적으로 유지한 설정을 적고 더 이상 필요 없는 임시 변경은 정리하세요. 몇 주 뒤 “여러 곳을 바꿨다”는 기억만 남아 원인과 결과를 재구성하지 못하는 일을 막을 수 있습니다.

앱을 다시 설치해야 한다면 먼저 연결을 중지하고 On Demand 상태를 확인한 다음 데이터가 안전하게 저장됐는지 확인하세요. 이후 App Store에서 다시 받습니다. 설치 후에는 이 매뉴얼 순서대로 권한 설정, 보유 정보 가져오기, 기본 서버 선택, 구성 활성화, 연결 확인, 자동 실행 복원을 진행하세요. 과거 파일을 한꺼번에 모두 가져온 뒤 바로 연결하면 중복 항목과 오래된 규칙이 같은 문제를 다시 일으킬 수 있습니다.

이제 일상적인 유지 관리 절차가 완성됩니다. 기준 상태를 보관하고, 한 번에 하나씩 변경하고, 단계별로 검증하고, 결과를 기록한 뒤 필요하면 되돌리세요. 연결 절차를 빠르게 다시 진행하려면 사용 튜토리얼을 참고하세요. 구매나 가져오기 관련 질문은 자주 묻는 질문에서 확인하고, App Store에서 앱 확인 및 구매 항목 복원이 필요하면 정품 구매 및 복원 안내로 돌아가세요. 이 페이지는 각 단계의 범위를 설명합니다. 실제 매개변수는 항상 앱 내 옵션과 사용자가 보유한 서비스 정보를 기준으로 하세요.