Shadowrocket
시스템 가이드와 설정 참고

01 / APP STORE

정품 구매와 구매 범위

먼저 제품을 확인한 다음 구매와 설치를 진행하세요. Shadowrocket은 Apple 플랫폼용 유료 클라이언트이며, 유일한 구매 경로는 App Store입니다. 이름이 비슷한 앱이 검색되더라도 한국어 별칭만으로 판단하지 마세요. 사이트의 정품 구매 및 확인 페이지에서 개발자, 공식 아이콘, 앱 ID를 하나씩 대조한 뒤 구매를 진행하세요.

제품 페이지에서 확인할 세 가지 정보

개발자 이름은 Shadow Launch Technology Limited여야 하며, 제품 페이지 주소의 앱 ID는 932747118이어야 합니다. 앱 이름은 검색에 도움이 되지만, 이름만으로 정품 여부를 판단할 수는 없습니다. 검색 결과 요약보다 상세 페이지의 개발자 항목을 확인하는 편이 정확합니다. 정보가 일치하지 않으면 구매를 중단하고 올바른 제품 페이지를 다시 찾으세요.

아이콘은 사이트 상단에 표시된 공식 아이콘과 같아야 합니다. 흰색 바탕에 파란색과 보라색 윤곽선이 있는 형태입니다. 아이콘은 세 가지 확인 항목 중 하나일 뿐, 개발자와 앱 ID 확인을 대신하지 않습니다. App Store 링크를 저장할 때는 전체 제품 주소를 보존하고, 나중에 브라우저 북마크에서 다시 열 때도 주소와 페이지 내용을 확인해 비슷한 앱을 같은 제품으로 혼동하지 않도록 하세요.

구매 전에 제품 페이지에서 호환 기기와 구매 안내를 확인하세요. 이 매뉴얼은 주로 iPhone과 iPad 사용을 다룹니다. Mac, Apple TV, Apple Vision의 호환 여부도 같은 App Store 페이지에서 확인할 수 있습니다. 시스템 요구 사항과 구매 적용 범위는 App Store 페이지에 표시된 내용을 기준으로 하며, 다른 기기에서 설치된 결과만으로 현재 기기에서도 사용할 수 있다고 판단하지 마세요.

클라이언트 비용과 연결 설정 구분하기

Shadowrocket은 일회성 구매 앱입니다. 미국 스토어 기준 가격은 약 2.99달러이며, 실제 결제 금액은 구매 시 App Store 페이지에서 확인하세요. 각 스토어는 현지 통화로 가격을 표시합니다. 클라이언트 비용은 앱 판매 채널에 지불하는 금액입니다. 서버의 유효성, 구독 만료일, 사용할 수 있는 연결 매개변수는 기존에 이용 중인 서비스에 해당하며, 앱 구매만으로 결정되지 않습니다.

클라이언트 일회성 구매 ≠ 연결 서비스 요금제. 설치 후 사용할 수 있는 서버 항목이 없더라도 구매에 실패한 것은 아닙니다. 연결 정보를 아직 가져오지 않은 상태일 뿐입니다. 먼저 구독 주소나 서버 매개변수를 보유하고 있는지 확인한 뒤 3장으로 이동하세요. 정보가 없다면 화면과 규칙 관련 장을 먼저 읽어도 됩니다. 앱을 반복해서 다시 설치할 필요는 없습니다.

구매 계정과 구성 데이터는 별개로 생각해야 합니다. App Store 구매 기록은 앱을 다시 받을 수 있는 자격을 확인하는 데 쓰이고, 앱 안의 서버와 규칙은 별도의 데이터입니다. 기기를 바꾼 뒤 클라이언트를 다시 받을 수 있더라도 구독, 직접 추가한 항목, 로컬 구성이 함께 복원된다는 뜻은 아닙니다. 구매 복원과 구성 복원은 각각 확인해야 하며, 한 번의 확인으로 처리할 수 없습니다.

설치 완료 후 시작하기

다운로드가 끝나면 기기의 홈 화면에서 Shadowrocket을 열고 정상적으로 실행되는지 먼저 확인한 다음 연결을 시도하세요. 이 매뉴얼을 처음 읽을 때는 기기 종류, 사용 중인 네트워크, 기존 구성의 출처와 취득 방법을 기록해 두는 것이 좋습니다. 이 정보는 업로드할 필요가 없으며 이후 문제를 진단하기 위한 기준으로만 사용합니다. 문제가 생겼을 때 설치, 가져오기, 연결 중 어느 단계에서 발생했는지 구분하는 데 도움이 됩니다.

App Store에 구매 완료로 표시되는데 현재 기기에서 결제를 요구한다면, 먼저 App Store 구매에 사용 중인 계정이 원래 구매 기록과 같은지 확인한 다음 구입 항목을 살펴보세요. 기기의 로그인 상태와 스토어의 구매 상태를 같은 의미로 간주하지 마세요. 결제, 이용 가능한 지역, 구매 기록 문제는 App Store에 표시되는 안내에 따라 처리해야 합니다.

앱 업데이트도 App Store에서 진행합니다. 업데이트 전에 중요한 구성을 보관하고, 업데이트 후에는 기존에 사용하던 연결을 먼저 확인하세요. 프로토콜, 규칙, DNS를 한꺼번에 바꾸지 마세요. 스토어의 업데이트 설명으로 기능 변경 사항을 확인할 수 있습니다. 이 매뉴얼은 특정 앱 버전의 화면 위치를 고정해 안내하지 않으므로 옵션 배치가 다르면 현재 앱에 표시된 이름과 설명을 기준으로 확인하세요.

02 / PERMISSION

첫 실행과 VPN 권한

처음 실행할 때는 화면 구성을 먼저 확인하고, 연결을 준비할 때 시스템 권한을 처리하세요. Shadowrocket으로 연결하려면 기기에서 VPN 구성을 추가하도록 허용해야 합니다. 이 권한은 서버 계정의 유효성과 별개입니다. 권한 팝업을 확인하고 승인했다는 것은 시스템이 앱의 해당 연결을 허용한다는 뜻일 뿐, 원격 서버, 규칙, DNS까지 검증되었다는 의미는 아닙니다.

Home, Config, Data, Settings 알아보기

Home에서는 서버 항목을 확인하고 연결 대상을 선택하거나 연결을 제어합니다. Config에서는 현재 규칙 구성을 관리합니다. Data에서는 트래픽과 요청 관련 정보를 확인하고, Settings에는 자주 사용하는 동작 설정이 모여 있습니다. 각 영역의 역할을 먼저 파악하고, 다른 기기와 버튼 위치가 완전히 같을 것이라고 기대하지 마세요. 실제 화면 배치는 기기 크기와 앱 UI 변경에 따라 달라질 수 있습니다.

연결 전에 Home에서 자신의 서버 항목이 있는지 확인하세요. 목록이 비어 있다면 연결 스위치를 반복해서 누르지 마세요. 스위치를 켜도 서버 정보가 생성되지는 않습니다. 추가 또는 가져오기 절차를 거친 뒤 저장한 항목을 다시 열어 확인할 수 있는지 살펴보고 Home으로 돌아오세요. 이렇게 하면 정보가 저장되지 않은 문제와 연결을 설정하지 못하는 문제를 구분할 수 있습니다.

Config에 구성 이름이 표시되어도 그 안의 규칙이 활성화되었다는 뜻은 아닙니다. 먼저 현재 선택된 구성 파일을 확인한 다음 Global Routing 상태를 살펴보세요. 서버 선택, 구성 파일 선택, 트래픽 분기 방식은 서로 별개입니다. 세 가지 요소를 구분해야 같은 기기에서도 요청마다 처리 방식이 달라지는 이유를 설명할 수 있습니다.

시스템 권한이 의미하는 것

처음 연결을 켤 때 시스템에서 VPN 구성을 추가하도록 허용하고 기기 인증을 거치라는 안내가 나타날 수 있습니다. 팝업을 읽고 Shadowrocket에서 직접 연결을 시작한 뒤 표시된 것인지 확인한 다음 시스템 안내에 따라 진행하세요. 권한 허용은 기기 수준의 설정 변경입니다. 시스템 인증 단계에 서버 비밀번호를 입력할 필요는 없습니다. 서버 인증 정보는 해당 연결 항목의 필드에만 입력하세요.

이전에 취소를 눌렀다면 앱으로 돌아가 연결을 다시 시작하고 시스템에서 권한을 다시 요청하는지 확인하세요. 팝업이 나타나지 않거나 스위치가 바로 원래 상태로 돌아가면 시스템 설정의 VPN 상태와 관련 안내를 먼저 살펴보세요. 관리 기기에는 추가 제한이 있을 수 있습니다. 명확한 관리 정책 안내가 표시되면 구성을 반복해서 삭제하며 확인하지 말고 해당 기기에서 이 연결을 허용하는지 먼저 확인하세요.

권한을 허용한 뒤에도 유효한 서버를 선택하고 네트워크에서 서버 주소에 접근할 수 있는지 확인해야 합니다. 시스템에 연결 상태가 표시되는 것은 로컬 연결 절차의 일부입니다. 웹 페이지 로딩 여부는 규칙, 서버 인증, 도메인 확인, 대상 사이트의 상태에도 영향을 받습니다. 따라서 ‘권한 허용’, ‘연결됨’, ‘요청 성공’을 각각 별도의 확인 항목으로 기록하세요.

설정을 모두 지우기보다 충돌을 정리하세요

기기에 다른 VPN 구성이 이미 있다면 테스트를 시작하기 전에 현재 어떤 항목이 연결을 관리하는지 확인하세요. 관련 스위치를 여러 개 바꾼 뒤 바로 결과를 판단하지 마세요. 먼저 현재 연결을 중단하고 시스템 상태가 예상대로 돌아왔는지 확인한 다음 Shadowrocket을 시작하세요. 기존 구성의 이름과 용도를 보존하고, 영향 범위를 모르는 상태에서 업무·학교·기기 관리에 필요한 항목을 삭제하지 마세요.

첫 검증에서는 On Demand 활성화를 미루세요. 자동 실행은 네트워크를 바꾸거나 도메인에 접근할 때 연결 상태를 변경할 수 있어, 직접 조작이 반영되지 않은 것처럼 보이게 할 수 있습니다. 먼저 수동으로 연결하고 해제하는 과정을 한 번 완료해 기준을 세우세요. 서버가 정상적으로 작동하는 것을 확인한 다음 자동 연결 조건을 하나씩 추가하면 각 설정의 영향을 파악하기 쉽습니다.

iPhone과 iPad의 권한 처리 원리는 같지만, 가로 화면·분할 화면·창 너비에 따라 화면 배치가 달라집니다. 옵션을 찾지 못했다면 먼저 너무 좁은 분할 화면에서 나와 앱 전체 창을 띄운 뒤 해당 영문 이름을 찾아보세요. 화면 위치가 바뀌었다고 구독을 다시 가져오지 마세요. 표시 방식의 변화만으로 구성 데이터가 손상되었다고 볼 수는 없습니다.

시스템에서 VPN 구성을 삭제해도 앱 내부의 서버 항목이 삭제되는 것은 아니며, 앱을 다시 설치해도 모든 권한 문제가 해결되는 것은 아닙니다. 시스템에서 구성 오류를 명확히 보고하고 복원할 데이터를 보관한 경우에만 관련 항목을 다시 만드는 방안을 고려하세요. 조치 후에는 권한 설정과 수동 연결 절차를 다시 진행하고, 삭제 전의 상태를 현재 결과 판단에 그대로 적용하지 마세요.

03 / SERVER & SUBSCRIBE

서버 추가와 기존 구독 가져오기

가져오기 전에 보유한 자료의 종류부터 확인하세요. 개별 서버 정보는 하나의 연결 대상을 설명하고, 구독 주소는 보통 여러 서버를 가져오거나 업데이트하는 데 사용합니다. .conf 구성 파일에는 주로 규칙과 관련 동작이 담깁니다. 이 세 가지는 함께 사용할 수 있지만, 구독 주소를 서버 호스트 이름으로 입력해서는 안 됩니다. 규칙 파일을 가져왔다고 유효한 서버까지 확보된 것은 아닙니다.

Add Server: 프로토콜 매개변수 확인

수동으로 추가하려면 Home에서 Add Server를 열고 보유한 정보와 같은 프로토콜을 선택한 다음 서버 주소, 포트, 인증 정보를 입력하세요. 프로토콜마다 필요한 필드가 다릅니다. 두 프로토콜 모두 비밀번호를 요구한다는 이유로 한쪽의 매개변수를 다른 쪽 양식에 입력하지 마세요. 저장하기 전에 원본 정보와 항목을 하나씩 대조하고, 복사 과정에서 공백이나 줄바꿈이 추가되지 않았는지 특히 주의하세요.

서버 주소 필드에는 제공받은 호스트 이름이나 IP 주소를 입력하고 포트는 별도 필드에 입력하세요. 전체 웹 주소와 경로를 호스트 필드에 함께 넣지 마세요. 표시 이름은 항목을 알아보기 위한 메모일 뿐, 호스트·포트·인증 오류를 해결하지 않습니다. 식별하기 쉬운 이름을 붙이면 이후 서버를 전환하거나 Data에서 확인할 때 잘못 선택할 가능성을 줄일 수 있습니다.

Shadowsocks에서는 보통 암호화 방식과 비밀번호를 확인해야 합니다. VMess와 VLESS에는 UUID 및 해당 전송 필드가 필요한 경우가 많습니다. Trojan의 인증 정보와 TLS 정보는 원본 자료대로 입력하세요. Hysteria2와 WireGuard는 매개변수 구조가 또 다릅니다. 제공되지 않은 필드는 이름만 보고 추측하지 말고, 한 프로토콜의 매개변수 규칙을 모든 연결 유형에 그대로 적용하지 마세요.

Subscribe 및 Scan QR Code

기존 구독은 앱의 구독 가져오기 기능으로 추가할 수 있습니다. 실제 화면에서 Subscribe 또는 해당 유형을 선택하고 서비스 제공자에게 받은 주소를 입력하세요. 구독 링크에는 개인을 식별할 수 있는 정보가 포함될 수 있으므로 비밀번호처럼 안전하게 보관해야 합니다. 가져온 뒤 항목 이름, 개수 변화, 프로토콜 유형을 확인하세요. 항목이 여러 개 표시된다는 이유만으로 모든 연결이 유효하다고 판단하지 마세요.

구독 업데이트에 실패하면 먼저 주소 형식 오류와 가져오기 과정의 실패를 구분하세요. 복사한 내용이 온전한지, 따옴표나 줄바꿈이 들어갔는지 확인한 다음 구독이 여전히 유효한지 살펴보세요. 가져오는 단계에서 오류가 발생했다면 서버 연결 테스트 전일 수 있습니다. 이때 노드 비밀번호를 반복해서 바꾸는 것은 적절한 해결 방법이 아닙니다. 먼저 업데이트 안내를 확인하고 구독 주소에 접근할 수 있는 조건을 점검하세요.

Scan QR Code는 이미 보유한 연결 정보를 가져올 때 유용하지만, 스캔은 입력 방법일 뿐 내용의 신뢰성을 추가로 확인해 주지는 않습니다. 스캔 전에 QR 코드의 출처를 확인하고, 스캔 후 생성된 항목의 프로토콜, 주소, 주요 필드를 살펴본 다음 저장하세요. 카메라나 사진 접근을 요청받으면 현재 작업에 필요한 권한만 처리하고, 항목 하나를 가져오기 위해 관련 없는 데이터까지 허용할 필요는 없습니다.

구독 업데이트와 Config의 역할 구분

구독 항목은 업데이트 후 교체·삭제·이름 변경이 일어날 수 있으므로 구독이 자동으로 관리하는 필드를 장기 메모 공간으로 사용하지 않는 편이 좋습니다. 수정한 테스트 항목을 보존해야 한다면 별도의 복사본으로 저장할 수 있는지 확인하고 출처를 기록하세요. 백업 없이 자주 쓰는 구독을 덮어쓰지 마세요. 업데이트 후 수동 변경 사항과 원격 변경 사항을 구분하기 어려워질 수 있습니다.

Config의 파일은 선택 여부와 규칙에서 참조하는 정책이 존재하는지 별도로 확인해야 합니다. 파일을 가져오는 데 성공했다는 것은 내용을 수신했다는 뜻일 뿐, 모든 규칙이 사용 환경에 적합하다는 의미는 아닙니다. 익숙하지 않은 구성은 먼저 General과 Rule을 읽고 예상하지 못한 처리 정책이 없는지 확인한 뒤 활성화하세요. 이해하기 어려운 복잡한 부분은 일단 그대로 두고 관련 안내를 참고해도 됩니다.

가져온 다음에는 항목 하나를 선택해 연결을 확인하고, 그 후에 그룹과 업데이트 주기를 정리하세요. 이렇게 하면 입력 오류와 일괄 관리 문제를 구분할 수 있습니다. 프로토콜 필드는 지원 프로토콜과 매개변수 간단 안내에서, 구성 구조는 .conf 섹션 설명에서 확인하세요. 반복해서 가져오는 것으로 확인 작업을 대신하지 마세요.

04 / GLOBAL ROUTING

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

Global Routing은 현재 전체 트래픽에 적용할 처리 방식을 결정합니다. 구성 모드는 Config, 프록시 모드는 Proxy, 직접 연결 모드는 Direct입니다. 화면에서 조작할 때는 이 영문 이름을 기준으로 하세요. 세 가지 모드는 서버 프로토콜이나 속도 등급이 아닙니다. 전체 연결을 확인하는 중인지 특정 규칙을 확인하는 중인지 먼저 정한 다음 모드를 선택하면 잘못된 테스트 조건으로 결과를 해석하는 일을 줄일 수 있습니다.

Config, Proxy, Direct에서 각각 확인할 항목

Config는 현재 선택된 구성에 따라 요청의 처리 방향을 판단하므로, 평소 트래픽 분기가 필요한 상황에 적합합니다. 구성의 규칙과 정책, 참조된 서버 간 관계가 모두 올바르게 설정되어야 합니다. Config에서 특정 대상에 접근할 수 없다면 서버가 바로 사용할 수 없다고 판단하지 말고 실제로 일치한 규칙을 먼저 확인하세요. 해당 대상이 Direct로 처리되거나 명시적으로 REJECT 처리되었을 수 있습니다.

Proxy는 트래픽을 프록시 방식으로 처리합니다. 규칙의 영향을 줄여 확인하는 테스트 조건으로 사용할 수 있지만, 유효한 서버와 올바른 인증 정보, 사용 가능한 네트워크가 여전히 필요합니다. DNS 문제, 원격 서버 접근 불가, 대상 자체의 오류를 해결해 주지는 않습니다. 테스트할 때는 이 항목만 바꾸고 같은 대상의 결과가 달라지는지 관찰하세요. 서버도 동시에 바꾸면 트래픽 분기 방식만 따로 비교할 수 없습니다.

Direct는 트래픽을 직접 연결 방식으로 처리하며, 앱 연결을 끊는다는 뜻은 아닙니다. 직접 연결을 테스트할 때도 시스템 연결 상태와 앱 설정을 확인하세요. Direct에서 특정 대상에 접근할 수 있다는 것은 현재 네트워크에서 그 대상에 접근할 수 있다는 뜻일 뿐, 다른 도메인이나 포트 또는 프록시 서버에도 접근할 수 있다는 의미는 아닙니다. 규칙 전체를 곧바로 평가해서도 안 됩니다.

구체적인 조건부터 FINAL까지 Rule 확인

규칙은 순서대로 읽으세요. 구체적인 도메인과 네트워크 대역 조건을 먼저 확인하고, 범위가 넓은 조건을 살펴본 뒤 마지막으로 FINAL을 확인합니다. 앞쪽 규칙이 처리 방식을 결정하면 뒤에 있는 유사 규칙은 해당 요청의 결과를 바꾸지 못하는 경우가 많습니다. 새 규칙을 추가하기 전에 기존 항목을 검색하세요. 예외 규칙이 범위가 넓은 규칙 뒤에 놓이면 내용은 있어도 계속 일치하지 않을 수 있습니다.

DOMAIN은 전체 도메인, DOMAIN-SUFFIX는 도메인 접미사, DOMAIN-KEYWORD는 도메인에 포함된 키워드를 기준으로 일치시킵니다. 세 규칙의 적용 범위는 서로 다릅니다. 특히 키워드 규칙은 의도하지 않은 다른 도메인에도 일치할 수 있으므로 주의해서 사용하세요. 규칙의 도메인에는 보통 웹 페이지 경로를 포함하지 않으며, 페이지 전체 주소를 그대로 복사하지도 않습니다.

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

이 내용은 Rule의 구조를 보여 주는 예시이며 모든 기기에서 바로 사용할 수 있는 완전한 구성은 아닙니다. 첫 번째 도메인 규칙이 뒤에 나오는 네트워크 대역 또는 지역 조건보다 먼저 결과를 결정할 수 있습니다. 로컬 네트워크 대역 규칙은 IP-CIDR의 작성 방법을 보여 주기 위한 것입니다. PROXY, DIRECT, REJECT는 정책 키워드이고, 화면 모드인 Proxy, Direct와는 대소문자가 다릅니다. 이를 필드 이름으로 혼동하지 마세요.

도메인 규칙과 주소 규칙의 차이

IP-CIDR과 IP-CIDR6은 각각 해당 주소 범위를 대상으로 하며, GEOIP는 주소 분류 데이터에 의존합니다. 이 규칙들이 참조하는 정보는 도메인 규칙과 다릅니다. 대상 주소를 확인한 뒤에야 해당 주소 조건을 판단할 수 있습니다. 하나의 도메인이 여러 주소로 해석되거나 네트워크 환경에 따라 결과가 달라지면 실제 규칙 일치 결과도 바뀔 수 있으므로, 문제를 확인할 때 도메인과 주소를 함께 기록하세요.

FINAL은 앞선 규칙에 일치하지 않은 트래픽을 처리하므로 규칙 맨 끝에 두어야 합니다. FINAL을 앞쪽으로 옮기면 뒤에 있는 규칙이 예상대로 작동하지 않습니다. 예외를 추가할 때는 어떤 기존 규칙에 적용할 예외인지 먼저 확인한 다음 알맞은 위치에 배치하세요. 단순히 ‘우선 적용’하려고 새 항목을 전부 맨 위에 쌓아 두면 나중에 규칙 간 관계를 파악하기 어렵습니다.

수정한 뒤에는 구체적인 대상 하나로 확인하고, 페이지가 열리는지만 보지 말고 Data에서 적용된 정책도 확인하세요. 웹 페이지는 여러 도메인에 의존할 수 있으므로 본문이 표시되어도 이미지, 로그인, API 요청이 같은 방식으로 처리된다고 볼 수 없습니다. 키워드가 궁금하면 용어 빠른 확인을 참고하세요. 규칙 확인을 마치면 평소 사용하는 모드로 되돌려 임시 테스트 상태가 계속 유지되지 않도록 하세요.

05 / CONNECTIVITY

연결, 지연 시간 테스트, 결과 확인

연결을 확인할 때는 로컬 네트워크부터 시작해 서버, 프로토콜, 규칙, 대상 접근을 단계별로 확인하세요. 지연 시간 테스트에서 숫자가 나왔다는 것은 당시 해당 테스트 방식으로 응답을 받았다는 뜻일 뿐, 실제 서비스 요청 전체를 검증한 것은 아닙니다. 비교를 시작하기 전에 서버 하나, Global Routing 모드 하나, 고정 테스트 대상 하나를 정하세요. 여러 조건을 동시에 바꾸면 결과를 해석하기 어렵습니다.

반복 가능한 테스트 기준 만들기

먼저 현재 Wi-Fi 또는 셀룰러 네트워크 자체가 정상인지 확인하세요. 로그인 페이지를 거쳐야 하거나 일시적인 제한이 있는 네트워크라면 Shadowrocket 연결을 끈 상태에서 먼저 처리합니다. 기본 네트워크 접근이 되지 않는 상황에서 서버 프로토콜을 바꾸는 것은 의미가 없습니다. 연결을 시작하기 전에 네트워크 유형을 기록하세요. 테스트 중 네트워크를 바꿨다면 이전 결과를 이어서 해석하지 말고 새로운 조건으로 취급해야 합니다.

Home에서 선택된 서버가 테스트하려는 항목인지 확인하고, 해당 구독이 여전히 유효한지와 최근 업데이트로 인증 정보가 바뀌지 않았는지 살펴보세요. 그런 다음 Global Routing과 현재 구성을 확인합니다. 서버 이름이 비슷하면 목록에서 선택된 위치만 믿지 말고 상세 정보를 열어 주소를 확인하세요. 가져오기나 업데이트로 항목 순서가 바뀔 수 있습니다.

연결을 켠 뒤 앱 안내와 시스템 상태를 확인하고 새로운 대상 요청을 보내세요. 브라우저에 이미 열려 있는 페이지는 캐시에서 표시될 수 있고, 화면이 그대로 보인다고 새 요청이 성공했다고 볼 수도 없습니다. 고정된 대상을 다시 불러온 다음 Data에서 해당 시각의 기록을 찾아 조작 시간, 요청 결과, 실제 처리 정책을 연결해 기록하면 반복 가능한 확인 절차를 만들 수 있습니다.

Connectivity Test와 실제 접근 구분하기

Connectivity Test는 테스트 방식과 대상 설정에 따라 결과가 달라집니다. 서로 다른 방식으로 측정한 지연 시간은 그대로 나열해 비교하지 마세요. 어떤 검사는 연결 설정을 중심으로 하고, 다른 검사는 요청과 응답 과정까지 포함합니다. 먼저 현재 사용 중인 방식을 확인한 다음 결과가 안정적인지 살펴보세요. 한 번 나온 숫자가 더 작다고 모든 웹 페이지나 앱의 전체 접근 속도가 더 빠르다는 뜻은 아닙니다.

테스트 시간 초과도 실제 요청 결과와 함께 판단해야 합니다. 서버가 특정 탐지 방식에 응답하지 않더라도 필요한 서비스 요청을 처리할 수 있고, 반대로 탐지에 응답하더라도 인증이나 전달 단계에서 실패할 수 있습니다. 두 결과가 다르면 테스트 방식 이름과 오류 메시지를 기록한 뒤 같은 서버로 실제 접근을 시도하세요. 목록의 단일 결과만 보고 모든 항목을 삭제하지 마세요.

모든 항목이 동시에 실패한다면 현재 네트워크, 구독 유효성, 테스트 대상, 설정 변경 등 공통 조건을 먼저 의심하세요. 한 항목만 실패한다면 해당 항목의 프로토콜, 주소, 포트, 인증 정보를 확인합니다. 전체 실패와 개별 실패는 점검 범위가 다릅니다. 암호화 방식이나 DNS를 무작정 바꾸기보다 문제 범위를 좁혀 확인하는 편이 근거가 있습니다.

오류가 발생한 단계에 따라 범위 좁히기

도메인 확인에 실패했다면 먼저 확인 경로를 점검하고, 연결 시간 초과라면 서버 접근 가능성을 확인하세요. 인증 실패는 자격 증명을 확인하고, 인증서 관련 오류는 서버 이름, 기기 시간, 원래 TLS 매개변수를 점검해야 합니다. 오류 메시지는 서로 다른 단계에서 발생할 수 있으므로 원문을 보관하고 모두 ‘네트워크 문제’로 묶지 마세요. 서버 이름이 일치하지 않는 문제를 인증서 확인 해제로 덮어서는 안 됩니다.

Proxy에서는 사용할 수 있지만 Config에서 실패한다면 규칙 일치 결과와 참조 정책을 중점적으로 살펴보세요. 두 모드에서 모두 실패한다면 공통 서버와 도메인 확인 조건을 점검합니다. 이러한 비교는 문제 범위를 좁히는 데 도움이 될 뿐 원인을 바로 입증하지는 않습니다. 테스트 전후에 같은 대상, 네트워크, 서버를 사용해야 차이를 해석할 수 있습니다.

연결은 되지만 속도가 불안정하다면 네트워크 전환, 대상 응답, 서버 상태, 지속적인 데이터 전송을 각각 살펴보세요. 대용량 파일, 실시간 통신, 짧은 웹 페이지는 서로 다른 결과를 보일 수 있으므로 하나의 상황으로 모든 사용 사례를 판단하지 마세요. 가장 자주 발생하는 실패 동작을 먼저 재현하고, 한 번에 한 항목만 바꾸며 테스트한 뒤 결과를 기록하고 다음 조치를 결정하세요.

확인을 마친 뒤 연결을 한 번 직접 끊고 다시 연결해 같은 결과가 반복되는지 확인하세요. 처음 성공한 것이 기존 세션이 계속 작동한 결과라면 재연결 과정에서 실제 문제가 드러날 수 있습니다. 재연결도 안정적이면 On Demand 같은 자동 동작을 하나씩 복원하세요. 가장 짧은 조작 경로는 사용법에서 확인할 수 있습니다. 이 장에서는 각 확인 항목을 따로 검증해야 하는 이유를 설명합니다.

06 / DATA

Data 트래픽과 요청 기록

Data에서는 현재 연결을 통해 처리된 트래픽과 요청 단서를 살펴볼 수 있지만, 누적 숫자를 서비스 요금과 바로 동일시해서는 안 됩니다. 앱 통계, 시스템 통계, 기존 서비스의 사용량 집계는 범위와 기간이 다를 수 있습니다. 이 장을 읽기 전에 확인하려는 내용을 먼저 정하세요. 특정 요청의 처리 방향을 확인하려는지, 실패 단계를 찾으려는지, 일정한 조작으로 데이터가 얼마나 변했는지 비교하려는지 구분하면 됩니다.

한 번의 조작을 관련 기록과 연결하기

확인 전에 현재 시각, 네트워크, 서버, Global Routing을 기록한 다음 고정된 페이지를 다시 불러오는 것처럼 반복 가능한 동작을 하나만 실행하세요. 여러 앱을 동시에 연 뒤 어떤 요청이 어떤 동작에 해당하는지 추측하지 마세요. 백그라운드 동기화도 트래픽을 만들 수 있으므로 시간대가 비슷하다는 점만으로는 부족합니다. 도메인이나 대상 주소와 함께 판단하세요.

하나의 페이지에는 본문, 이미지, API, 기타 리소스 요청이 포함되는 경우가 많으므로 여러 도메인이 표시되는 것은 이상한 일이 아닙니다. 실패한 기능과 직접 관련된 요청을 먼저 찾으세요. 화면이 비어 있다면 본문 요청, 로그인에 실패했다면 인증 API, 이미지가 누락됐다면 리소스 도메인을 확인합니다. 페이지 주소만 검색해 사이트 전체 상태를 단정하기보다 요청을 나눠 확인하는 편이 정확합니다.

기록에서 확인할 수 있는 필드는 현재 화면에 표시되는 내용을 기준으로 하되, 대상, 처리 정책, 일치 규칙, 연결 상태, 오류를 중점적으로 살펴보세요. 요청마다 표시되는 정보가 다를 수 있으므로 어떤 필드가 비어 있다는 이유만으로 앱이 요청을 처리하지 않았다고 단정하지 마세요. 필요하면 요청을 다시 보내 현재 연결과 구성이 적용된 뒤 생성된 기록인지 확인하세요. 이전 세션의 기록일 수도 있습니다.

규칙 결과를 바탕으로 구성 확인하기

요청이 실제로 DIRECT 처리되었다면 어떤 규칙이 결정했는지 먼저 찾고, 결과가 예상에 맞는지 판단하세요. PROXY로 처리되었다면 최종적으로 어떤 서버나 정책 객체가 사용되었는지 확인합니다. REJECT가 표시되면 서버 비밀번호를 바꾸기보다 거부를 결정한 조건을 먼저 확인하세요. 거부 정책은 원격 서버에 연결하기 전에 이미 요청 결과를 결정할 수 있습니다.

도메인 정보와 IP 주소는 함께 살펴봐야 합니다. 하나의 도메인이 여러 주소로 해석될 수 있고, 하나의 주소에서 여러 서비스가 실행될 수도 있습니다. 주소만으로 접근의 전체 의미를 파악할 수는 없습니다. 일부 연결 기록에는 도메인 규칙에 사용할 정보가 없을 수 있으므로, 당시 실제로 확인할 수 있었던 정보의 범위를 고려하세요. 나중에 확인한 도메인이 원래 요청에 포함되어 있었다고 단정하지 마세요.

규칙을 수정한 뒤에는 새 연결을 만들어 결과를 확인하세요. 기존 연결은 설정 당시의 처리 경로를 계속 사용할 수 있으므로 ‘구성을 바꿨는데 이전 기록이 달라지지 않았다’고 해서 저장에 실패한 것은 아닐 수 있습니다. 관련 요청을 중단하고 필요하면 다시 연결한 뒤 같은 동작을 반복하세요. 새 기록과 이전 기록의 규칙 일치 결과를 비교해야 변경 사항이 이후 처리에 영향을 주었는지 알 수 있습니다.

누적 트래픽과 데이터 보호 이해하기

트래픽 통계를 확인하기 전에 현재 연결, 특정 시간대, 앱에 저장된 누적 데이터 등 표시 범위와 집계 시작 조건을 살펴보세요. 구체적인 기준은 화면 설명을 따릅니다. 통계 기간이 같지 않다면 두 숫자를 바로 비교해 결론을 내리지 마세요. 재연결, 기록 정리, 표시 필터 변경도 관찰 범위를 바꿀 수 있으므로 비교 전에 조건을 기록해야 합니다.

업로드와 다운로드는 전송 방향을 나타낼 뿐, 사용자가 직접 콘텐츠를 봤는지를 뜻하지는 않습니다. 백그라운드 새로고침, 자동 백업, 페이지 미리 로드, 재시도도 데이터를 사용할 수 있습니다. 사용량이 갑자기 늘었다면 먼저 짧은 시간대로 범위를 좁히고 앱 하나만 확인하며, 다른 눈에 띄는 전송을 멈춘 뒤 변화를 관찰하세요. 누적 트래픽이 늘었다는 이유만으로 특정 서버 항목에 문제가 있다고 판단하지 마세요.

서비스 측 사용량과 로컬 표시가 다를 때는 프로토콜 오버헤드, 집계 기간과 범위, 다른 기기의 사용 등 여러 요인이 있을 수 있습니다. 모든 바이트가 정확히 일치하도록 하기보다 각 측정 방식의 안내를 확인하세요. 로컬 Data는 연결 동작을 파악하는 데 유용하지만, 남은 사용량·유효 기간·집계 방식에 관한 기존 서비스의 안내를 대신하지 않습니다.

요청 기록에는 방문한 도메인, 주소, 시각, 개인 활동 단서가 노출될 수 있습니다. 내보내거나 화면을 캡처하기 전에 문제와 관련된 부분만 남기고 구독 주소, 인증 정보, 관련 없는 접근 기록을 가리세요. 기록을 지우기 전에 재현에 필요한 오류 원문을 보관하세요. 삭제한 뒤에는 이전 문제를 다시 찾기 어려울 수 있으므로 진단을 마친 다음 정리하는 것이 좋습니다.

Data 기록과 브라우저 표시가 다르면 캐시, 기존 연결, 요청을 정확히 찾았는지부터 고려한 뒤 점검 범위를 넓히세요. 시스템의 다른 활동도 관찰 결과에 영향을 줄 수 있으므로 모든 기록을 현재 앞에 열린 페이지의 요청으로 간주하지 마세요. 고정된 동작, 짧은 관찰 시간, 반복 테스트로 관계를 확인하는 것이 Data를 이해하는 기본입니다.

07 / SETTINGS

Settings, DNS, On Demand

Settings는 연결이 안정적으로 작동하는 상태에서 항목별로 조정하세요. 설정이 도메인 확인, 실행 조건, 연결 동작 중 무엇에 영향을 주는지 파악한 뒤 원래 값과 변경 목적을 기록해야 합니다. 화면 옵션은 기기와 앱 업데이트에 따라 달라질 수 있으므로 실제 표시되는 이름과 적용 범위를 기준으로 확인하세요. 모든 기능을 켜거나 복잡한 구성을 사용해야 연결이 성공하는 것은 아닙니다.

DNS: 먼저 도메인 확인 경로 살펴보기

DNS는 도메인을 주소로 변환하고, 규칙 분기는 요청을 어떻게 처리할지 결정합니다. 서로 연관되어 있지만 같은 기능은 아닙니다. 도메인 확인에 실패하면 브라우저가 정상적인 연결 단계까지 진행하지 못할 수 있습니다. 이때 프록시 서버만 바꿔도 해결되지 않을 수 있습니다. 먼저 현재 DNS 설정이 앱, 활성 구성, 네트워크 환경 중 어디에서 비롯되는지 확인한 뒤 수정할 위치를 정하세요.

Config의 General과 Settings의 관련 항목이 함께 실제 동작에 영향을 줄 수 있으므로 현재 앱의 안내를 기준으로 적용 관계를 확인하세요. 여러 곳에 서로 다른 값을 입력한 뒤 하나만 기억하는 상황을 피해야 합니다. 수정 전에 원래 설정을 기록하고 구성 복사본을 보관하세요. 테스트할 때는 설정 출처 하나만 바꾸고 새 요청의 도메인 확인과 접근 결과를 관찰한 다음 변경 사항을 유지할지 결정하세요.

도메인 확인 서버는 많을수록 좋은 것이 아닙니다. 확인 경로에 따라 서로 다른 주소가 반환될 수 있으며, 현재 네트워크나 프록시를 통해 접근해야 할 수도 있습니다. 문제를 진단할 때는 먼저 사용 중인 확인 서비스가 현재 조건에서 접근 가능한지 살펴본 다음 대상 요청에 적합한지 판단하세요. DNS를 반복해서 바꾸는 것은 일반적인 해결책이 아니며, 잘못된 비밀번호·서버 포트·거부 규칙은 바로잡을 수 없습니다.

도메인 결과가 캐시될 수 있으므로 설정을 바꾼 뒤 이전 주소가 잠시 표시된다고 해서 반드시 변경이 적용되지 않은 것은 아닙니다. 새 요청을 보내고 관련 연결을 다시 설정해 실제 도메인 확인 단서를 살펴보세요. 웹사이트에 IP 주소로 직접 접속하는 것도 동일한 테스트가 아닙니다. TLS 이름과 사이트 라우팅에 도메인이 필요할 수 있습니다. 테스트 방식을 바꿨다면 그 방법으로 확인할 수 있는 조건의 범위를 분명히 하세요.

On Demand: 수동 연결 기준에서 자동 실행으로

On Demand는 조건에 따라 연결 관련 동작을 실행할 때 사용하며, 수동 연결이 안정적으로 작동한 다음 설정하는 것이 좋습니다. 어떤 네트워크 조건에서 연결하고 어떤 조건에서는 연결하지 않을지 먼저 정한 뒤 규칙을 하나씩 만드세요. 처음부터 모든 Wi-Fi, 셀룰러 네트워크, 도메인 조건을 적용하면 자동 실행과 수동 스위치가 서로 영향을 줄 때 어떤 조건이 작동했는지 파악하기 어렵습니다.

Wi-Fi 이름으로 설정할 때는 실제 네트워크 이름을 확인하고 비슷한 이름, 게스트 네트워크, 기기의 자동 전환에 유의하세요. 네트워크 이름 일치는 실행 조건을 나타낼 뿐, 그 네트워크가 항상 같은 접근 기능을 제공한다는 뜻은 아닙니다. 테스트할 때 다른 조건은 그대로 둔 채 대상 네트워크로 전환하고 상태가 바뀔 때까지 기다린 다음 앱과 시스템 상태에서 실제 결과를 확인하세요.

셀룰러 네트워크나 도메인을 기준으로 실행할 때도 실행 시점과 규칙 순서를 확인해야 합니다. 요청이 발생했는지, 도메인이 조건에 맞는지, 시스템에서 현재 연결을 허용하는지에 따라 관찰 결과가 달라집니다. 자동 연결은 서버가 계속 작동한다는 보장이 아닙니다. 원격 서버에 접근할 수 없다면 실행 조건이 일치해도 실제로 접근하지 못할 수 있으므로 ‘조건 일치’와 ‘서비스 이용 가능’을 나눠 기록하세요.

On Demand를 끈 뒤에도 현재 연결이 유지되는지, 시스템 상태가 예상과 일치하는지 확인하세요. 자동 실행 규칙을 끄는 것과 기존 세션을 종료하는 것은 별개의 동작입니다. 스위치만 보고 모든 연결이 끊겼다고 판단하지 마세요. 조건을 더 체계적으로 구성하는 방법은 On Demand 연결 조건 설정에서 확인할 수 있습니다.

기타 자주 쓰는 동작 설정의 범위

로컬 네트워크 접근에 문제가 생기면 관련 설정을 확인하기 전에 대상이 로컬 네트워크 대역에 속하는지, 현재 규칙에서 어떻게 처리되는지 살펴보세요. 가정용 기기, 프린터 서비스, 관리 페이지는 로컬 장치 검색에 의존할 수 있으므로 모든 트래픽에 같은 정책을 적용해서는 안 됩니다. 네트워크 관련 옵션을 수정했다면 구체적인 로컬 대상을 이용해 확인하고, 일반 웹 페이지가 열리는 것으로 로컬 접근을 대신 판단하지 마세요.

IPv6 관련 문제가 보이면 먼저 현재 네트워크와 대상이 실제로 어떤 주소 유형을 사용하는지 확인한 다음 IP-CIDR6 등 규칙 적용 범위를 살펴보세요. 특정 주소 기능을 끄는 것은 증상만 바꿀 뿐 원인을 설명하지 못할 수 있습니다. 원래 값을 보존하고 같은 대상의 결과를 조건별로 비교하세요. 변경이 문제와 관련 있다는 점을 확인한 뒤 장기 적용 여부를 결정해야 합니다.

기본 연결을 위해 Rewrite나 인증서 관련 기능을 일괄 활성화하지 마세요. 각 기능은 별도의 용도와 영향 범위가 있으므로 내용을 이해하고 명확한 권한을 확인한 뒤 적용 대상을 제한해야 합니다. 간단한 구성으로도 일반 서버 가져오기, Global Routing, 연결 확인을 진행할 수 있습니다. 추가 기능과 관련 없는 문제라면 원래 상태를 유지하는 편이 진단에 도움이 됩니다.

08 / MAINTENANCE

일상적인 유지 관리, 기기 변경, 문제 해결 마무리

일상적인 유지 관리의 목표는 구성을 자주 초기화하는 것이 아니라 이해하고 복원할 수 있는 상태로 유지하는 것입니다. 앱 구매 기록, 보유한 구독 자료, 서버 항목, 활성 구성, 직접 수정한 내용을 각각 보관하면 문제가 생겨도 해당 부분만 처리할 수 있습니다. 정리를 마친 뒤 연결을 다시 확인해 평소 사용하는 서버, Global Routing, 규칙 처리 방향이 바뀌지 않았는지 확인하세요.

업데이트 전후에 사용 가능한 기준 보관하기

앱 업데이트는 App Store에서 진행하고, 구독 업데이트는 기존 구독에서 서버 정보를 가져오는 작업입니다. 문제 기록에서 두 작업을 모두 ‘업데이트’라고 부르지 마세요. 앱 업데이트, 구독 새로고침, 규칙 수정을 동시에 하면 문제가 발생한 원인을 파악하기 어렵습니다. 가능한 한 작업을 분리하고 각 단계 후 고정된 대상 하나를 테스트해 안정적인지 확인한 다음 다음 단계로 넘어가세요.

구독을 업데이트하기 전에 별도로 보관해야 할 항목과 메모를 저장하고, 활성 서버 항목이 교체될 수 있는지 확인하세요. 업데이트 후에는 항목 이름의 변경, 현재 선택 상태, 연결 결과를 확인하세요. 업데이트 완료 안내만 확인해서는 충분하지 않습니다. 새 항목은 실패하지만 기존에 별도로 보관한 항목이 작동한다면 앱 전체를 즉시 지우기보다 프로토콜 필드와 원격 변경 사항을 먼저 비교하세요.

구성 파일을 수정할 때는 검증된 복사본을 보관하고, 일상용과 테스트용을 용도가 분명한 이름으로 구분하세요. 유일하게 사용할 수 있는 구성을 실험용으로 사용하지 마세요. 복잡한 변경은 도메인 규칙, 네트워크 대역 규칙, General 설정 단계로 나누고 한 번에 한 단계씩 확인하세요. 그러면 전체를 다시 구성하지 않고 변경한 부분만 되돌릴 수 있습니다.

기기 변경 후에는 세 단계로 나눠 복원 확인하기

첫 번째는 앱을 다시 받을 수 있는 자격입니다. 새 기기의 App Store에서 기존 구매 계정으로 구입 항목을 확인하세요. 시스템 요구 사항과 구매 적용 범위는 App Store 페이지에 표시된 내용을 기준으로 합니다. 클라이언트를 다시 받은 것은 앱 복원만 완료한 것입니다. 다음으로 앱을 열어 로컬 자료를 확인해야 하며, 스토어의 구매 완료 표시를 서버 구성이 이전되었다는 증거로 간주해서는 안 됩니다.

두 번째는 서버와 구독 자료입니다. 직접 보관한 주소나 매개변수를 사용해 복원한 다음 여전히 유효한지 다시 확인하세요. 이전 기기에서 구독을 사용할 수 있었다고 해서 지금도 주소가 유효하다는 뜻은 아닙니다. 수동으로 추가한 항목은 필드가 복사 과정에서 빠져 실패할 수도 있습니다. 복원 후에는 자주 사용하는 항목 하나를 먼저 테스트하고, 연결이 확인되기 전에는 자동 실행 조건을 추가하지 마세요.

세 번째는 활성 구성과 개인 설정입니다. 규칙 파일을 복원한 뒤 선택 상태, Global Routing, DNS, On Demand를 확인하고 첫 연결에 필요한 시스템 권한도 살펴보세요. 이전 기기에서 허용한 권한은 새 기기의 확인 절차를 대신하지 않습니다. iPad에서 구매를 복원하고 화면 배치를 확인하는 방법은 iPad 구매 복원과 사용 시 확인 사항에서 알아볼 수 있습니다.

기기 이동에 사용하는 구성에는 서버 주소, 구독 인증 정보 또는 기타 개인 정보가 포함될 수 있으므로 직접 관리할 수 있는 안전한 위치에 보관하세요. 내보낸 뒤 파일 내용과 복원 방법을 먼저 확인하고, 백업을 시험한다는 이유로 유일하게 작동하는 복사본을 곧바로 삭제하지 마세요. 이전이 성공하고 연결까지 확인된 다음 필요에 따라 사용하지 않는 임시 복사본을 정리하세요.

최소한의 기록으로 문제 해결 마무리하기

문제 기록에는 발생 시각, 기기 종류, 현재 네트워크, 서버 프로토콜, Global Routing, 활성 구성, 오류 원문을 포함하세요. 마지막으로 성공했던 조건과 최근 수정한 항목을 더하면 대체로 문제 범위를 좁힐 수 있습니다. 비밀번호, 키, 전체 구독 주소, 개인 접근 기록은 가리고 문제를 이해하는 데 필요한 구조만 남기세요.

문제가 생기면 먼저 재현한 뒤 어느 단계인지 파악하세요. 앱 실행 여부, 권한 설정, 자료 가져오기, 서버 접근, 규칙, 대상 서비스 상태를 순서대로 확인합니다. 각 단계에서는 해당 단계의 질문만 확인하고 모든 문제를 앱 재설치로 해결하려 하지 마세요. 증거가 로컬 데이터나 설치 상태를 가리킬 때만 복구 조치를 고려하고, 먼저 사용할 수 있는 자료를 보관하세요.

수정한 뒤에는 반대 방향으로도 확인해야 합니다. 평소 사용하는 모드로 되돌리고 다시 연결한 다음 처음 실패했던 동작을 반복하며 Data에서 규칙과 정책이 예상대로인지 확인하세요. 임시 테스트 모드에서만 성공했다면 문제 해결이 끝난 것이 아닙니다. 결과가 안정적인 것을 확인한 뒤 진단 기록을 정리하고 최종 변경 사항을 적어 두면 같은 문제가 다시 생겼을 때 빠르게 비교할 수 있습니다.

장기적으로 유지 관리할 때는 설명할 수 없는 구성을 쌓아 두기보다 더 이상 사용하지 않는 테스트 항목을 삭제하세요. 용도가 분명한 기준 항목을 소수만 보관하고 구독의 유효성과 구매 기록의 복원 가능성을 주기적으로 확인하면 됩니다. 일상적인 조작은 빠른 사용 안내에서, 용어는 용어 빠른 확인에서 살펴보세요. 구매와 설치 문제는 정품 구매 페이지의 구매 복원 안내를 참고하세요.