Shadowrocket 완벽 사용 설명서

1. App Store 구입 및 정품 확인

먼저 올바른 앱을 구입했는지 확인한 다음 연결 정보를 준비하세요. Shadowrocket은 Apple 플랫폼용 상용 앱이며 App Store에서만 구입할 수 있습니다. 앱을 구입하면 클라이언트를 사용할 수 있지만, 보유 중인 구독이나 서버의 이용 조건은 별도로 확인해야 합니다. 이 두 가지를 구분하면 설치 후 사용할 서버가 없을 때 구입이 잘못된 것으로 오해하는 일을 줄이고, 계정 구입 문제와 네트워크 연결 문제도 따로 파악할 수 있습니다.

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

이 사이트의 정품 확인 안내를 통해 제품 페이지로 이동한 뒤, 앱 이름 Shadowrocket, 개발자 Shadow Launch Technology Limited, 제품 페이지 주소의 앱 ID 932747118를 차례로 확인하세요. 사이트 상단에 표시된 공식 앱 아이콘과도 대조하세요. 검색 결과에 이름이 비슷한 앱이 있다고 해서 확인을 대신할 수는 없습니다. 같은 제품 페이지에서 앱을 확인한 뒤 구입 버튼, 호환성 및 앱 설명을 살펴보세요.

스토어 페이지의 아이콘, 개발자, 앱 ID는 제품을 식별하는 기준입니다. 검색 순위나 이름에 포함된 별칭만으로 판단하지 마세요. 페이지에서 확인한 개발자가 다르면 확인 단계로 돌아가세요. 이후 권한 설정이나 구입 절차를 같은 앱의 단계로 간주해 진행하지 마세요. 확인할 때 앱 이름과 개발자 이름은 서로 다른 항목이라는 점도 유의하세요.

가격, 기기 및 구입 범위

Shadowrocket은 일회성 구입 앱이며, 미국 스토어 가격은 약 2.99달러입니다. 실제 금액과 통화, 세금은 App Store 페이지에 표시된 내용을 기준으로 하세요. 구입 전 App Store에 사용하는 Apple 계정과 스토어 국가 또는 지역을 확인하고, 구입을 마친 뒤에는 시스템에서 제공하는 구입 기록을 보관하세요. 가격은 연결 품질을 나타내는 지표가 아니며, 특정 서버의 이용 기간이나 사용 가능한 트래픽, 연결 가능 지역을 의미하지 않습니다.

이 설명서는 주로 iPhone / iPad 사용을 기준으로 합니다. Mac, Apple TV, Apple Vision에서도 같은 제품 페이지의 호환성 항목을 확인할 수 있습니다. 시스템 요구 사항과 구입 적용 범위는 App Store 페이지에 표시된 내용을 기준으로 하세요. 한 기기에서 설치에 성공했다고 해서 다른 기기에서도 반드시 사용할 수 있다고 단정하지 마세요. 두 번째 기기에서 사용하기 전에 기기의 시스템, 계정의 구입 기록, 제품 페이지의 호환성 정보를 각각 확인하세요.

설치, 구입 항목 복원 및 업데이트

구입을 마치면 App Store에서 앱을 설치합니다. 앱을 다시 설치하거나 기기를 교체할 때는 먼저 기존 구입 계정으로 구입 항목을 확인한 다음 스토어에서 제공하는 절차에 따라 복원하세요. 페이지에 여전히 구입 금액이 표시되면 바로 다시 결제하지 말고 현재 스토어 계정, 구입 기록, 제품이 서로 일치하는지 확인하세요. 다른 시스템 서비스에 사용하는 계정과 스토어 구입 계정은 다를 수 있으므로 실제 구입 기록을 기준으로 판단하세요.

앱 복원과 연결 설정 복원은 별개의 작업입니다. 스토어에서 구입한 앱은 다시 받을 수 있지만, 서버 주소, 구독 내용, 현재 선택된 Config 파일, 로컬 규칙은 원래 저장한 방식에 따라 별도로 확인해야 합니다. 앱을 다시 설치하면 이전 연결 정보가 모두 복원된다고 생각하지 마세요. 가족 공유가 적용되는지도 App Store 페이지와 계정에 실제로 표시된 내용을 기준으로 판단하세요. 다른 앱의 구입 경험을 그대로 적용해서는 안 됩니다.

업데이트도 App Store에서 진행합니다. 업데이트 전에 사용 중인 서버, Global Routing 상태, Config 파일 이름을 기록하세요. 중요한 로컬 수정 사항은 먼저 백업하세요. 업데이트 후에는 기존 연결을 확인한 뒤 설정을 조정하세요. 이렇게 하면 차이가 생겼을 때 정보 변경, 네트워크 변경, 이번 작업 중 무엇이 원인인지 파악하기 쉽습니다. 스토어의 업데이트 기록에서 변경 사항을 확인할 수 있으며, 이 문서에는 앱 버전을 고정해 기재하지 않습니다.

다음 장으로 넘어가기 전에 앱이 정상적으로 열리는지 확인하고, 자신의 서버 정보나 구독을 준비하세요. 구입 기록, 기기 호환성, 앱 설치를 모두 확인한 다음 권한 설정과 가져오기를 진행하세요. 계정 복원, 구입 가격, 기기별 구입 방법에 관한 자주 묻는 질문은 구입 항목 복원 및 가격 안내에서 확인할 수 있습니다.

2. 첫 실행 및 VPN 구성 권한

처음 실행하면 먼저 화면 구성을 익힌 다음 시스템 권한을 설정하세요. Home에서는 보유한 서버를 확인하고 연결 대상을 선택하거나 연결을 제어합니다. Config에서는 구성 파일을 관리합니다. Data에서는 트래픽과 요청을 살펴봅니다. Settings에서는 앱 동작을 조정합니다. 기기나 앱 업데이트에 따라 화면 배치가 달라질 수 있으므로, 이전 스크린샷의 버튼 위치만 보고 조작하지 말고 영어 항목 이름을 확인하세요. 첫 연결의 목표는 확인 가능한 기본 상태를 만드는 것이지, 모든 설정을 한꺼번에 활성화하는 것이 아닙니다.

시스템 VPN 권한의 의미

Shadowrocket은 연결을 설정할 때 시스템의 VPN 구성 기능을 사용합니다. 처음 관련 작업을 실행하면 시스템에서 VPN 구성을 추가하도록 허용할지 묻고, 기기 인증을 요청할 수 있습니다. 이는 클라이언트가 시스템 네트워크 경로에서 작동하도록 허용하는 절차입니다. 서버 정보가 올바른지 확인한 것이 아니며 원격 서비스 로그인이 성공했다는 뜻도 아닙니다. 앱 설치, 시스템 권한 승인, 서버 인증은 서로 다른 단계이므로 문제를 확인할 때 각각 구분해야 합니다.

권한을 승인하기 전에 안내가 시스템에서 표시된 것인지 확인하고, 현재 열려 있는 앱이 확인을 마친 Shadowrocket인지 확인하세요. 승인한 다음 앱으로 돌아가 연결 상태를 살펴보세요. 안내를 취소했다면 다시 연결을 시도하고 현재 시스템에 표시되는 안내에 따라 진행하세요. 한 번 취소했다는 이유로 앱을 반복해서 삭제하지 마세요. 필요한 경우 시스템 Settings의 VPN 관련 항목에서 기존 구성을 확인하세요. 메뉴 위치는 기기에 설치된 시스템에 표시되는 내용을 기준으로 합니다.

첫 연결 전 기본 상태 확인

연결을 시작하기 전에 기기 자체가 평소 사용하는 웹사이트에 접속할 수 있는지 확인하세요. Wi-Fi 인증이 끝나지 않았거나 셀룰러 데이터가 꺼져 있거나 네트워크가 일시적으로 끊긴 상황을 먼저 배제해야 합니다. 기본 웹페이지도 열리지 않는다면 현재 네트워크부터 해결하세요. 클라이언트는 기존 네트워크를 통해 서버에 연결합니다. 시스템에 VPN 표시가 나타나도 기본 네트워크 연결을 대신하지 않으며 공용 Wi-Fi 로그인을 자동으로 완료하지도 않습니다.

그다음 Home에 알고 있는 서버 항목이 있는지 확인하세요. 목록이 비어 있다면 아직 정보를 추가하지 않았다는 뜻일 뿐, 설치에 실패했다는 의미는 아닙니다. 기존 항목도 자신의 기록에서 가져온 것인지 확인하세요. 특히 기기를 복원했거나 이전 백업을 가져온 경우 주의가 필요합니다. 먼저 정보가 완전하고 용도가 분명한 항목 하나를 테스트 대상으로 선택하세요. 첫 연결을 시험하는 동안 여러 불확실한 설정을 동시에 적용하지 마세요.

첫 테스트에서는 On Demand의 현재 상태를 먼저 확인하는 것이 좋습니다. 온디맨드 연결이 활성화되어 있으면 네트워크 조건에 따라 다시 연결을 시도할 수 있어 수동으로 연결을 끊은 뒤 상태를 파악하기 어려울 수 있습니다. 테스트를 명확하게 진행하려면 기존 설정을 기록한 다음 자동 연결 조건을 잠시 꺼두세요. 테스트가 끝나면 필요한 조건을 복원하세요. 기록 없이 모든 자동화 설정을 바꾸지 마세요.

그 밖의 권한은 용도에 맞게 처리

Scan QR Code를 사용하면 시스템에서 카메라 권한을 요청할 수 있습니다. 직접 입력하거나 기존 링크로 가져오는 경우 카메라 권한은 연결에 필요한 조건이 아닙니다. 로컬 기기에 접근하는 작업에서는 관련 네트워크 권한 안내가 표시되는지도 확인하세요. 권한 안내가 나타나면 방금 실행한 작업과 연관 지어 판단하세요. 현재 작업과 무관한 권한 변경을 연결 문제의 일반적인 해결 절차로 취급하지 마세요.

VPN 구성 권한 승인이 인증서 설치를 뜻하는 것은 아닙니다. 일반적인 서버 연결에 HTTPS 복호화를 반드시 활성화해야 한다고 해석해서는 안 됩니다. 특정 구성에 인증서, 재작성 또는 그 밖의 고급 처리가 포함되어 있다면 용도와 적용 범위를 먼저 파악한 뒤 별도로 검토하세요. 웹페이지가 열리지 않는다는 이유만으로 인증서 신뢰를 추가하지 마세요. 첫 연결의 일반적인 절차로 인증서 검증을 끄는 것도 피하세요. 이는 기존 보안 경계를 변경합니다.

연결 스위치를 켜자마자 꺼지면 아직 처리하지 않은 시스템 안내가 있는지 먼저 확인하고, 설정이 완전한지도 살펴보세요. 스위치가 켜진 상태인데 웹페이지가 응답하지 않는다면 연결 확인 장으로 이동하세요. 문제가 권한 승인 전, 승인 후, 대상 요청 중 어느 시점에 발생했는지 기록하면 원인을 좁히기 쉽습니다. 스위치를 연속해서 빠르게 켰다 끄면 진행 상황을 파악하기 어려워집니다. 각 작업 후 상태가 안정될 때까지 기다린 다음 다음 항목을 확인하세요.

이 장을 마치려면 앱의 정체를 확인했고, 기본 네트워크를 사용할 수 있으며, 시스템 권한 안내를 처리했고, 자동 연결 조건의 현재 상태를 알고 있어야 합니다. 그다음 서버나 구독을 가져오세요. 가장 짧은 절차로 설정하려면 사용 안내로 돌아가 계속 진행하세요. 가져오기 항목과 구성의 관계를 확인하려면 다음 장을 읽어보세요.

3. 기존 서버 및 구독 추가

먼저 서버 항목, 구독, 구성 파일을 구분하세요. 서버 항목은 특정 원격 서버에 연결하는 방법을 설명합니다. 구독은 서버 항목을 일괄로 가져오고 업데이트하는 데 사용합니다. Config 파일은 주로 트래픽 처리 방식과 관련 매개변수를 지정합니다. 세 가지는 함께 사용할 수 있지만 서로 대체할 수는 없습니다. 목록에 서버가 있다고 해서 원하는 라우팅 규칙이 활성화된 것은 아닙니다. 규칙 파일을 가져왔다고 해서 사용할 수 있는 서버가 반드시 포함되어 있는 것도 아닙니다.

Add Server와 수동 입력 항목

Home에서 Add Server를 열고, 보유한 정보에 맞는 프로토콜 유형을 선택한 다음 각 항목을 입력하세요. 프로토콜을 잘못 선택하면 다른 항목이 비슷해 보여도 연결되지 않을 수 있습니다. 주소에는 정보에 기재된 호스트 이름이나 IP를 입력하고, 포트는 원래 값 그대로 입력하세요. 주소 입력란에는 일반적으로 웹페이지 경로나 설명을 함께 넣지 않습니다. 관리 페이지 주소를 서버 주소로 사용하지 말고, 이름에 있는 숫자를 보고 포트를 추측하지도 마세요.

인증 항목은 프로토콜에 따라 달라집니다. 비밀번호, UUID, 암호화 방식, 키는 원본 정보를 사용하세요. 다른 항목의 입력 방식을 보고 빠진 정보를 임의로 채우지 마세요. 복사한 뒤 앞뒤 공백과 줄바꿈은 확인하되, 대소문자를 바꾸거나 특수 문자를 삭제하지 마세요. 메모는 항목을 식별하는 데만 사용되며 주소, 인증 정보, 전송 매개변수를 수정해 주지 않습니다. 필수 정보가 누락되었다면 흔히 쓰는 값을 임의로 입력하지 말고 원본 자료를 먼저 확인하세요.

TLS를 사용하는 경우 연결 주소, 인증서 검증 이름, 전송 과정의 Host 또는 경로가 각각 다른 역할을 할 수 있습니다. 기존 설정에 따라 각 항목을 정확히 대응시키세요. 값이 같은 경우도 있지만 항상 서로 바꿔 쓸 수 있다고 볼 수는 없습니다. 특히 가져오기는 완료되었지만 핸드셰이크에 실패했다면 검증 조건을 완화하기 전에 이 항목들이 모두 입력되었는지 확인하세요. 고급 옵션이 화면에 표시된다고 해서 모든 프로토콜에서 수정해야 하는 것은 아닙니다.

Subscribe 및 일괄 업데이트

보유한 구독은 앱의 Subscribe 관련 메뉴에서 추가한 다음 구독 주소 전체를 붙여넣으세요. 구독 주소에는 접근 권한 정보가 포함되는 경우가 많으므로 비공개 자료로 취급하고, 공개 스크린샷이나 공개 노트에 붙여넣지 마세요. 가져오기 전에 공백, 줄바꿈, 한글 문장 부호가 포함되지 않았는지 확인하세요. 구독 주소와 서버 주소는 용도가 다르므로 구독 주소 전체를 개별 서버의 주소 입력란에 넣어서는 안 됩니다.

구독 업데이트는 서버 항목 정보를 다시 가져오는 작업이며, 기존 서비스 이용 기간을 연장하지 않습니다. 업데이트가 끝나면 현재 선택한 서버가 남아 있는지, 이름이 바뀌었는지, 수동 편집 내용이 새 정보로 덮어쓰였는지 다시 확인하세요. 업데이트에 실패해도 기존 항목은 남아 있을 수 있지만, 남아 있다고 해서 설정이 여전히 유효한 것은 아닙니다. 정보를 가져오지 못한 경우, 내용을 해석하지 못한 경우, 서버 자체에 연결할 수 없는 경우를 구분하세요. 세 문제는 해결 방법이 다릅니다.

구독 결과가 비어 있다면 먼저 주소가 완전한지 확인한 다음 현재 네트워크에서 구독 엔드포인트에 접근할 수 있는지, 앱에 어떤 안내가 표시되는지 확인하세요. 결과가 비어 있다고 해서 기존 항목을 모두 바로 삭제하지 마세요. 비교할 기준을 잃지 않도록 필요한 정보를 먼저 보관하세요. 같은 주소가 다른 네트워크에서는 다르게 표시된다면 모든 서버가 사용할 수 없다고 단정하지 말고 구독을 가져오는 경로의 차이로 기록하세요.

QR 코드 가져오기 및 가져온 정보 확인

Scan QR Code로 가져올 때 QR 코드에는 서버 하나 또는 다른 구성 정보가 들어 있을 수 있으므로 실제로 해석된 결과를 확인하세요. 가져오기 전에 정보가 자신의 기록에서 나온 것인지 확인하고, 가져온 후에는 항목을 열어 프로토콜, 주소, 포트, 인증 정보를 점검하세요. Import from Cloud JSON과 같은 메뉴도 요구하는 자료 형식에 맞춰야 합니다. 파일 이름이나 확장자만 보고 내용이 적합하다고 판단하지 마세요.

가져온 뒤에는 예상한 개수와 이름이 표시되는지 확인하고, 사용할 항목을 하나 이상 점검한 다음 직접 선택해 연결을 확인하세요. 이름에 포함된 지역 설명이 실제 연결 경로를 보장하지는 않습니다. 지연 시간 테스트 결과도 실제 서비스 이용 성공을 의미하지 않습니다. 기존 항목을 선택하는 방법은 지연 시간 테스트와 서버 선택 노트를 참고하세요.

수동 수정 사항을 유지해야 한다면 먼저 수정한 항목을 기록한 뒤 이후 구독 업데이트로 덮어쓰도록 둘지 결정하세요. 이름이 같은 여러 항목 사이에서 선택한 대상을 기록하지 않은 채 번갈아 테스트하면 한 항목의 성공 결과를 다른 항목의 결과로 오해하기 쉽습니다. 이 장을 마치면 현재 어떤 항목을 사용하고 있는지, 정보 출처가 어디인지, 다음 업데이트가 어떤 항목에 영향을 미치는지 명확히 알 수 있어야 합니다.

4. Global Routing 및 규칙 매칭

Global Routing은 트래픽 전체에 적용할 처리 방식을 결정합니다. 한국어로는 구성에 따른 처리, 프록시, 직접 연결로 설명할 수 있으며, 인터페이스 용어는 각각 Config, Proxy, Direct입니다. 구체적인 규칙을 살펴보기 전에 먼저 현재 모드를 확인하세요. 그렇지 않으면 Proxy 상태에서 규칙을 수정하면서 라우팅 결과가 달라지기를 기대하는 등 잘못된 판단을 내릴 수 있습니다. 서버 항목은 연결 방식을 담당하고 Global Routing은 전체 라우팅 선택을 담당하므로 두 가지를 모두 확인해야 합니다.

Config, Proxy, Direct의 역할

세 가지 모드는 경로를 비교하기 위한 것이지, 서로 다른 서버 세 개를 뜻하지 않습니다. 모드를 바꾼 뒤에는 새 요청으로 다시 테스트하세요. 필요하면 기존 페이지를 닫았다가 다시 여세요. 이미 설정된 연결은 새 선택에 따라 다시 연결되지 않을 수 있습니다. Direct는 앱 연결 스위치를 끄는 것과 다릅니다. 시스템 터널과 요청 처리 방식은 서로 다른 계층입니다. 완전히 연결하지 않은 기본 네트워크 상태와 비교하려면 스위치 상태를 별도로 기록하세요.

Config를 사용하기 전에 Config에서 현재 활성화된 파일 이름과 내용을 확인하세요. 목록에 파일이 있다고 해서 현재 사용 중인 파일이라는 뜻은 아닙니다. 복사본을 편집했다고 해서 실행 중인 구성이 자동으로 변경되는 것도 아닙니다. 저장한 다음 인터페이스 안내에 따라 파일을 활성화하고 새 요청으로 확인하세요. 파일 이름이 비슷하다면 용도를 구분할 수 있는 메모를 추가해 어떤 복사본을 수정했는지 혼동하지 않도록 하세요.

규칙은 순서대로 매칭되며 FINAL은 마지막 조건을 처리합니다

[Rule] 섹션의 규칙은 위에서 아래로 확인하고, 일치하는 규칙을 찾으면 해당 정책을 적용합니다. 따라서 범위가 좁은 예외 규칙은 보통 범위가 넓은 규칙보다 앞에 배치하고, 마지막에 기본 규칙을 둡니다. DOMAIN은 특정 도메인에, DOMAIN-SUFFIX는 도메인과 하위 도메인에 적용됩니다. DOMAIN-KEYWORD는 범위가 더 넓으므로 의도하지 않은 도메인까지 매칭될 수 있는지 고려한 뒤 사용하세요.

[General]
bypass-system = true
skip-proxy = 192.168.0.0/16, 10.0.0.0/8, localhost
dns-server = system

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

다음 예시는 규칙 문법을 이해하기 위한 것이며 모든 사용자에게 적합한 완성된 구성은 아닙니다. PROXY는 프록시 처리를, DIRECT는 직접 연결을, REJECT는 요청 거부를 의미합니다. 예시에 나온 도메인은 매칭 방식을 설명할 뿐, 실제 서비스가 작동하는지 확인하는 데 사용할 수 없습니다. FINAL,PROXY는 앞선 규칙과 일치하지 않은 트래픽에 적용됩니다. 예상한 동작과 맞는지 확인한 후 적절한 정책을 사용하세요.

IP-CIDR와 IP-CIDR6은 IP 주소 범위를 대상으로 하고, GEOIP는 IP 주소의 지역 정보를 기준으로 판단합니다. 도메인을 직접 매칭하는 규칙과 기준이 다릅니다. 도메인 요청에는 DNS 조회 과정이 포함될 수 있으며, no-resolve는 해당 IP 규칙만을 위해 도메인을 조회하지 않도록 하는 옵션입니다. 이를 앱 전체의 DNS를 끄는 기능으로 이해하지 마세요. 지역 정보 데이터 역시 실제 요청을 관찰하는 일을 대신할 수 없습니다.

최소한으로 수정한 뒤 매칭 결과 확인

특정 대상의 문제를 확인할 때는 기존 구성의 복사본에 적용 범위가 명확한 규칙을 추가하고, 해당 대상을 포함할 수 있는 광범위한 규칙보다 앞에 배치하세요. 한 번에 조건 하나만 조정하고 저장한 뒤 새 요청을 보내 실제 대상과 정책을 확인하세요. 서버 교체, DNS 변경, 규칙 순서 조정을 동시에 하지 마세요. 문제가 해결되어도 어떤 변경이 영향을 주었는지 알 수 없고, 다음에 같은 문제를 재현하기도 어려워집니다.

로컬 네트워크 관련 설정은 실제 네트워크 주소 범위에 맞춰 확인해야 합니다. 예시는 일부 사설 IP 주소 범위만 보여 주며, 사용 중인 네트워크가 반드시 같은 주소를 사용한다는 뜻은 아닙니다. 자신의 네트워크 정보를 확인하세요. 로컬 서비스에 계속 접속할 수 없다면 검색 방식, 기기 권한, 현재 네트워크의 격리 여부도 살펴봐야 합니다. 직접 연결 규칙 하나만으로 모든 로컬 통신이 복구된다고 판단할 수는 없습니다.

Config 모드에서 올바른 파일을 활성화하고 새 요청이 실제로 규칙과 일치한 경우에만 해당 규칙의 효과를 평가할 수 있습니다. 규칙 순서 예시는 규칙 우선순위와 FINAL 기본 처리에서, 키워드 의미는 용어집에서 확인하세요.

5. 연결 및 단계별 확인

연결은 단계별로 확인해야 합니다. 기본 네트워크가 작동하는지, 클라이언트 연결이 유지되는지, 서버 연결을 사용할 수 있는지, 대상 요청이 예상대로 처리되는지 살펴보세요. 아이콘 하나나 테스트 숫자 하나만으로 이 네 단계를 모두 판단할 수는 없습니다. 테스트를 시작하기 전에 현재 네트워크, 선택된 서버, Global Routing, Config 파일을 기록한 다음 한 번에 변수 하나만 바꾸세요. 그래야 ‘조금 전에는 됐는데 지금은 안 된다’는 상황을 재현 가능한 조건으로 구체화할 수 있습니다.

기준 테스트를 순서대로 진행하기

먼저 연결하지 않은 상태에서 평소 접속할 수 있는 페이지를 열어 기기 자체가 인터넷에 연결되어 있는지 확인하세요. 그런 다음 확인이 끝난 서버를 선택하고 Global Routing 모드를 정한 뒤 Home의 연결 스위치를 켜세요. 상태가 안정될 때까지 기다리고, 처리되지 않은 시스템 안내가 있다면 완료하세요. 연결이 즉시 중단되면 웹페이지를 계속 새로고침하지 말고 이번 작업에서 표시된 안내나 로그를 먼저 확인하세요. 아직 대상 사이트에 접근하는 단계에 도달하지 않았을 수 있습니다.

연결이 유지되면 새 페이지를 열어 용도가 분명한 대상 한두 곳을 테스트하세요. 평소 이용하며 결과를 판단하기 쉬운 페이지를 우선 사용하고, 대량 다운로드나 여러 동영상 앱을 동시에 실행하지 마세요. 먼저 페이지가 완전히 로드되는지 확인하고 이미지, 로그인, 기타 작업도 살펴보세요. 페이지 제목이 표시되었다고 해서 일부 리소스만 성공한 것일 수 있으며, 전체 서비스가 정상이라고 판단할 수는 없습니다.

Config를 테스트할 때는 대상에 실제로 적용된 정책을 확인하세요. Proxy를 테스트한다면 프록시 경로를 확인하는 것인지 분명히 하세요. Direct의 결과는 현재 네트워크로 직접 연결했을 때의 비교 자료로 보세요. 어떤 대상이 직접 연결에서는 성공하고 프록시에서는 실패한다면 두 경로의 결과가 다르다는 뜻입니다. 그래도 서버, 인증, DNS, 대상의 제한을 각각 확인해야 합니다. 이 현상만 보고 특정 설정 항목이 잘못되었다고 단정하지 마세요.

Connectivity Test의 의미와 한계

Connectivity Test나 관련 지연 시간 테스트는 특정 탐지 방식에서의 연결 가능성과 소요 시간을 확인하는 기능입니다. 구체적인 테스트 방식과 대상은 앱의 현재 설정을 기준으로 합니다. 숫자가 표시되어도 모든 서비스가 작동한다는 뜻은 아니며, 시간 초과가 발생해도 모든 연결이 실패했다는 의미는 아닙니다. 탐지 대상을 먼저 확인한 다음 실제 웹페이지 접속 결과와 함께 판단하세요. 테스트 방식이 다른 결과를 같은 기준으로 정렬해서는 안 됩니다.

낮은 지연 시간은 특정 테스트 과정의 왕복 또는 응답 특성만 나타내며, 지속적인 전송 속도, 연결 안정성, 동영상 로딩 상태를 직접 보여 주지는 않습니다. 기존 서버 중에서 선택할 때는 테스트 시간, 네트워크 환경, 실제 서비스 이용 결과, 프로토콜 정보를 함께 고려하세요. 한 번의 숫자 변화만으로 서버를 자주 바꾸지 마세요. 기존 세션이 끊기고 이후 기록에 여러 서버의 결과가 섞일 수 있습니다.

문제가 발생한 단계에 따라 범위 좁히기

DNS 문제가 의심되더라도 모든 DNS 항목을 곧바로 낯선 주소로 바꾸지 마세요. 먼저 도메인이 올바른지, 기본 네트워크에서 인증이 필요한지, 실패 기록이 어느 단계에서 멈췄는지 확인하세요. IP 주소로 직접 접속하는 것은 도메인 접속을 대신하지 못합니다. TLS, 가상 호스트, 콘텐츠 전송 경로가 도메인에 의존할 수 있기 때문입니다. IP 접속에 실패했다고 해서 해당 도메인의 DNS 조회가 반드시 잘못되었다고 결론 내릴 수는 없습니다.

인증 또는 TLS 오류가 발생하면 원래 서버 정보로 돌아가 비밀번호, UUID, 인증서 이름, 전송 매개변수, 기기 시간을 확인하세요. 시간이 크게 어긋나면 인증서 확인에 영향을 줄 수 있습니다. 정보 오류를 가리기 위해 검증을 끄지 말고, 모든 핸드셰이크 실패를 네트워크 속도 문제로 돌리지도 마세요. 구독을 방금 업데이트했다면 현재 선택한 항목이 이전에 테스트한 항목과 같은지 특히 확인하세요.

네트워크를 전환한 뒤 문제가 생겼다면 Wi-Fi와 셀룰러 네트워크에서 같은 짧은 테스트를 진행하고 전후 결과를 기록하세요. 한 네트워크에서는 실패하고 다른 네트워크에서는 정상이라면 기본 연결 경로가 다를 수 있습니다. 비교하려면 서버와 구성을 바꾸지 마세요. 공용 네트워크에서 먼저 로그인해야 한다면 네트워크 인증을 완료한 뒤 클라이언트 연결을 다시 시작하세요. 인증 페이지 문제와 서버 문제를 섞지 않도록 합니다.

유용한 연결 확인 기록에는 테스트 시간, 네트워크 유형, 항목 메모, 모드, 대상, 표시된 오류가 포함되어야 하며 인증 정보는 숨겨야 합니다. 원인을 찾지 못했다면 가장 최근에 발생한 명확한 실패 사례를 보관한 뒤 Data에서 관련 요청을 확인하세요. 먼저 기록을 지우고 나중에 기억을 더듬지 마세요. 구독 주소 전체, 비밀번호, 키가 포함된 로그를 공개하지 마세요.

6. Data 트래픽 및 요청 확인

Data를 사용하면 ‘페이지에 문제가 있다’는 상황을 구체적인 요청과 트래픽 변화로 좁힐 수 있습니다. 앱에서 처리한 네트워크 활동을 확인하는 데 도움이 되지만 모든 서비스 오류의 원인을 자동으로 알려 주지는 않습니다. 기록을 읽을 때는 요청 대상, 적용된 정책, 연결 상태, 전송 통계를 구분하세요. 화면이나 보기에 따라 표시되는 항목이 다를 수 있으므로 현재 앱에서 실제로 표시되는 내용을 기준으로 합니다. 막연하게 기록을 훑기보다 확인할 문제를 정한 다음 Data를 여세요.

한 가지 동작으로 관련 요청 찾기

기록을 확인하기 전에 불필요한 백그라운드 접근을 중지하거나 대량 트래픽이 발생하는 작업을 일시 중지하세요. 현재 시간을 기록한 뒤 대상 앱에서 특정 페이지 열기처럼 명확한 작업을 한 번 실행합니다. 그다음 해당 시간 전후로 추가된 요청을 확인하세요. 여러 앱을 새로고침하면서 어떤 기록이 문제와 관련 있는지 추측하지 마세요. 하나의 작업에서도 여러 도메인 요청이 발생할 수 있으며, 다른 백그라운드 활동이 있으면 구분하기가 더 어려워집니다.

기록이 많으면 대상 도메인, 발생 시간, 앱의 필터 기능을 이용해 범위를 좁히세요. 문제와 직접 관련된 요청을 찾은 다음 앞뒤 활동을 확인합니다. 웹페이지 주소창의 기본 도메인은 진입점일 뿐일 수 있습니다. 이미지, 스크립트, 로그인, API가 각각 다른 대상에 요청할 수 있습니다. 메인 페이지는 열리는데 특정 기능만 실패한다면 페이지를 처음 연 기록만 보지 말고 해당 기능을 실행한 뒤 새로 추가된 요청을 확인하세요.

규칙 매칭과 트래픽 경로를 구분해 확인

확인할 수 있는 기록에서 대상 요청에 PROXY, DIRECT, REJECT 중 어떤 정책이 적용되었는지 확인하고 규칙의 예상 결과와 비교하세요. 대상이 REJECT로 처리되었다면 범위가 너무 넓은 키워드나 기존 규칙 때문인지 확인하세요. 예상과 달리 DIRECT로 처리되었다면 현재 모드와 활성화된 파일을 먼저 확인하세요. 모든 거부 규칙을 바로 삭제하지 말고, 범위가 명확한 예외 규칙으로 확인한 다음 기존 규칙의 매칭 범위를 조정할지 결정하세요.

한 페이지에서 여러 정책이 적용되는 것은 규칙 분기의 정상적인 결과일 수 있습니다. 일부 리소스는 직접 연결하고 나머지는 프록시를 사용하는 것이 반드시 구성 충돌을 의미하지는 않습니다. 중요한 것은 이런 선택이 의도에 맞고 서비스가 정상적으로 작동하는지입니다. 반대로 모든 요청이 같은 경로를 사용해도 규칙이 작동하지 않는다는 뜻은 아닙니다. 현재 모드, 규칙 범위, 기본 정책이 원래 같은 결과를 선택했을 수 있습니다.

업로드 또는 다운로드 바이트가 표시된다는 것은 해당 범위에서 데이터가 오갔다는 뜻일 뿐, 서비스 작업이 성공했다는 의미는 아닙니다. 인증 실패 페이지, 재시도 요청, 오류 응답도 트래픽을 발생시킵니다. 로그인, 파일 전송, 미디어 재생이 완료되었는지 확인하려면 서비스 화면의 결과와 관련 요청을 함께 살펴보세요. 기록에 연결 종료가 표시되어도 정상적인 짧은 연결일 수 있으므로 종료 상태만 보고 문제로 판단하지 마세요.

통계 기준과 과금 범위 이해

Data의 누적값, 특정 세션의 수치, 서비스 계정에 표시되는 사용량은 서로 다른 기준으로 계산될 수 있습니다. 직접 연결 트래픽이 특정 화면의 통계에 포함되는지, 집계가 언제부터 시작되는지, 프로토콜 오버헤드가 포함되는지는 해당 화면의 실제 정의를 확인해야 합니다. 클라이언트에 표시된 총량을 기존 구독의 잔여 사용량으로 간주하지 마세요. 누적 숫자 하나만으로 원격 서비스의 청구 내역이 잘못되었다고 판단할 수도 없습니다.

특정 작업의 트래픽 변화를 확인하려면 시작값, 종료값, 테스트 시간을 기록하고 다른 네트워크 활동을 최대한 줄이세요. 삭제나 초기화 기능을 사용한다면 어떤 기록에 영향을 미치는지 먼저 확인하세요. 기록을 삭제해도 서버 인증이 수정되거나 규칙 매칭이 바뀌거나 원격 사용량이 복구되지는 않습니다. 주로 로컬에서 확인할 자료가 달라지는 것이므로 문제를 확인하는 동안에는 유용한 사례를 보관하세요.

기록을 확인한 뒤 검증 가능한 변경으로 이어가기

메인 페이지는 정상인데 이미지가 로드되지 않는다고 가정해 보겠습니다. 먼저 이미지 요청의 대상이 무엇인지 찾고, 거부되었거나 다른 정책이 적용되었는지 확인하세요. 다음으로 구성 복사본에서 해당 대상의 처리 방식만 바꾼 뒤 같은 동작을 다시 시도합니다. 문제가 해결되면 경로 변경이 결과에 영향을 주었다는 뜻입니다. 이후에도 규칙 범위가 너무 넓거나 다른 대상에 영향을 주는지 확인하세요. 테스트용 구성을 바로 최종 설정으로 사용해서는 안 됩니다.

기록상 요청이 예상한 프록시 경로로 처리되었는데도 서비스가 실패한다면, 이미 올바른 규칙을 반복해서 수정하지 말고 원격 연결 상태, TLS, 대상의 응답을 확인하세요. 관련 요청을 전혀 찾을 수 없다면 관찰 시간, 필터 조건, 현재 연결 상태부터 확인하세요. 앱 캐시 때문에 동작을 실행해도 요청이 다시 전송되지 않았을 수 있습니다. 클라이언트가 해당 앱의 트래픽을 처리하지 않는다고 바로 판단하지 말고 새로운 요청을 발생시키는 동작을 시도하세요.

진단 정보를 내보내거나 공유하기 전에 구독 주소의 접근 정보, 서버 인증 항목, 키, 불필요한 개인용 도메인을 제거하세요. 문제 해결에 가장 유용한 자료는 전체 기록이 아니라 짧은 시간 범위, 명확한 대상 하나, 예상 정책, 실제 오류입니다. 필요한 맥락은 남기면서 민감한 정보는 줄이면 다음 단계의 확인에 집중할 수 있고, 복구 후 결과와 비교하기도 쉽습니다.

7. Settings, DNS 및 On Demand

Settings의 옵션은 구체적인 필요에 맞춰 조정하세요. 자동 연결, DNS 조회, 테스트, 기록 보관 중 무엇을 해결하려는지 먼저 정한 다음 관련 항목을 변경합니다. 옵션이 많다고 연결이 더 안정적인 것은 아닙니다. 자동화나 설정이 겹치면 오히려 원인을 파악하기 어려워질 수 있습니다. 조정 전에 현재 정상 작동하는 상태를 기록하세요. 특히 Config에서 가져온 값, 앱 설정의 값, 현재 세션에서만 임시로 선택한 값을 구분해야 합니다.

On Demand의 트리거와 수동 스위치

On Demand는 설정한 조건에 따라 연결하거나 연결을 끊는 기능입니다. 서버를 제공하거나 잘못된 인증 정보를 수정해 주지는 않습니다. 온디맨드 조건에는 Wi-Fi, 셀룰러 네트워크, 도메인이 포함될 수 있으며 실제 선택 항목은 현재 인터페이스를 기준으로 합니다. 설정하기 전에 수동 연결이 안정적으로 작동하는지 확인하세요. 그렇지 않으면 자동화가 같은 실패를 반복해 배터리 사용량과 관찰 기록만 늘고 근본적인 연결 문제는 해결되지 않습니다.

Wi-Fi 조건을 설정할 때는 네트워크 이름과 기대하는 동작을 확인하세요. 이름이 같은 네트워크, 네트워크 전환, 일시적인 연결 끊김에도 특히 유의해야 합니다. 셀룰러 조건은 기기가 Wi-Fi에서 전환될 때 원하는 동작이 이루어지는지 고려하세요. 도메인 조건은 연결을 시작하는 조건이지 Config에서 요청의 경로를 정하는 규칙이 아닙니다. 하나는 언제 연결을 설정할지, 다른 하나는 연결 후 트래픽을 어떻게 처리할지 담당합니다.

설정을 마치면 조건이 충족되는 경우와 충족되지 않는 경우를 각각 테스트하고 수동으로 연결을 끊은 뒤의 동작도 확인하세요. 연결을 끈 직후 다시 연결된다면 스위치가 고장 난 것으로 단정하지 말고 On Demand가 다시 연결을 트리거했는지 살펴보세요. 테스트할 때는 이해하기 쉬운 조건 하나만 남기고 결과를 확인한 뒤 복잡성을 추가하세요. 조건을 자세히 설명한 내용은 On Demand 온디맨드 연결 노트를 참고하세요.

DNS와 구성의 적용 범위

DNS는 도메인을 IP 주소로 변환하지만 조회에 성공했다고 해당 주소에 연결할 수 있다는 뜻은 아닙니다. 주소에 연결할 수 있어도 서비스 인증까지 성공한 것은 아닙니다. 도메인 접속에 문제가 있으면 DNS 조회 단계와 이후 연결 단계를 먼저 구분하세요. 모든 접속 문제를 DNS 탓으로 돌리지 말고, 기존 값을 기록하지 않은 채 여러 DNS 설정을 연속해서 바꾸지도 마세요. 그러면 같은 대상의 캐시, 주소, 연결 경로가 동시에 바뀔 수 있습니다.

구성 예시의 dns-server = system은 해당 시스템의 DNS 설정을 사용한다는 뜻입니다. 실제로 어떤 방식을 사용할지는 기존 구성, 네트워크 조건, 신뢰 범위를 고려해 결정하세요. 앱 설정과 Config 파일에 관련 항목이 모두 있다면 현재 어떤 값이 적용되는지 확인해야 합니다. 한 곳에 값이 표시된다는 이유만으로 모든 요청이 그 값을 사용한다고 단정할 수 없습니다. 변경 후 상태가 안정될 때까지 기다린 다음 새 요청으로 확인하세요.

DNS 조회와 라우팅 판단은 서로 연관될 수 있습니다. 예를 들어 IP 규칙은 주소 정보가 필요하고, 도메인 규칙은 도메인을 직접 기준으로 판단할 수 있습니다. 네트워크에 따라 조회 결과가 달라지면 최종 경로도 달라질 수 있습니다. 문제를 좁히려면 가능하면 같은 서버, 같은 구성, 같은 대상을 유지하고 DNS 설정 하나만 비교하세요. 주소 규칙을 추가하면서 DNS 방식도 동시에 바꾸면 각각의 영향을 구분하기 어렵습니다.

연결 테스트, 로그 및 보안 경계

Connectivity Test의 대상이나 방식을 변경할 수 있다면 수정 전후 값을 기록하세요. 방식이 다른 테스트의 소요 시간은 직접 비교할 수 없으며, 더 작은 숫자를 얻기 위해 실제 필요와 무관한 대상을 선택해서도 안 됩니다. 일상적인 테스트는 기존 항목을 더 확인할 필요가 있는지 판단하는 용도로 사용하고, 최종적으로는 실제 서비스 이용 결과를 기준으로 삼으세요. 테스트를 지나치게 자주 하면 네트워크 요청만 늘어나므로 작은 변동을 모두 문제로 간주할 필요는 없습니다.

로그 관련 설정은 명확한 문제 해결 과정에 맞춰 사용하세요. 자세한 기록이 필요하면 적절한 수준의 로그를 켜고, 문제를 재현한 뒤 필요한 부분을 저장한 다음 평소 설정으로 되돌리세요. 기록을 계속 많이 보관하면 관리가 번거로워지고 개인 네트워크 정보도 쌓일 수 있습니다. 공유하기 전에 민감한 정보를 가리고 서버 인증 정보, 구독 접근 정보, 불필요한 접속 기록이 내보내기에 포함되는지 확인하세요.

TLS 검증, 인증서, 재작성 또는 그 밖의 고급 처리와 관련된 옵션은 각각의 설명을 따로 확인하세요. 일반적인 연결을 유지하려고 검증 요구 사항을 임의로 낮추어서는 안 됩니다. 검증 범위를 바꿔야만 연결된다면 서버 정보, 인증서 이름, 시간 설정을 다시 확인하세요. 용도를 이해하지 못하는 옵션은 현재 정상적으로 작동하는 값을 유지하세요. 다른 구성의 옵션을 하나씩 따라 켜는 것보다 안정적으로 관리하기 쉽습니다.

설정 확인에는 첫 연결, 수동 연결 해제, 네트워크 전환, 기기를 다시 사용한 뒤의 상태가 포함되어야 합니다. 특히 On Demand는 현재 Wi-Fi에서 한 번 테스트했다고 완료된 것이 아닙니다. 동작이 안정적인지 확인한 다음 용도를 함께 적은 간결한 설정 기록을 보관하세요. 값만 나열하지 말고 해당 옵션을 사용하는 이유를 기록하면 다음에 문제를 확인할 때 현재 환경에 여전히 적합한지 판단하기 쉽습니다.

8. 구성 백업, 업데이트 및 일상적인 유지 관리

유지 관리의 목표는 정상 작동하는 기준 상태를 보존하고 변경 사항을 기록하는 것입니다. 클라이언트 업데이트, 구독 업데이트, 규칙 수정, 네트워크 변경, 계정 복원은 각각 다른 작업이므로 가능하면 별도로 진행하세요. 여러 가지를 한꺼번에 바꾸면 문제가 생겼을 때 원인을 찾기 어렵습니다. 평소에 모든 설정을 자주 초기화할 필요는 없습니다. 먼저 정보를 보관하고, 범위를 좁힌 뒤, 작은 단위로 확인하는 편이 문제를 복구하고 이해하기 쉽습니다.

되돌릴 수 있는 기준 상태 만들기

연결이 정상일 때 현재 선택한 서버 메모, Global Routing, Config 파일 이름, 주요 설정, 마지막으로 확인한 방법을 기록하세요. 로컬에서 수정한 구성은 복사본으로 저장하고 용도를 구분할 수 있는 이름을 사용하세요. 백업은 파일을 복사하는 것만으로 끝나지 않습니다. 복원할 때 어떤 파일의 내용을 활성화해야 하는지 알 수 있어야 합니다. 인증 정보가 포함된 자료는 관리되는 안전한 위치에 보관하고 대조하기 편하다는 이유로 공개 노트에 넣지 마세요.

구성 백업, 구독 주소, 서버 인증 정보는 서로 다른 자료입니다. Config 파일을 복원하면 규칙은 돌아올 수 있지만 서버 항목 전체가 복구되는 것은 아닐 수 있습니다. 구독 주소를 보관해도 원격 콘텐츠가 계속 동일하다는 보장은 없습니다. 앱에서 제공하는 내보내기나 동기화 기능을 사용한다면 실제로 어떤 항목이 포함되는지 먼저 확인하고 두 번째 기기에서 복원 결과를 점검하세요. 가져오기 오류가 없었다는 이유만으로 기존 기기의 상태가 전부 옮겨졌다고 단정하지 마세요.

구독과 규칙을 따로 업데이트

구독을 업데이트하기 전에 현재 사용하는 항목과 필요한 로컬 수정 사항을 기록하세요. 업데이트 후에는 항목이 삭제, 교체, 이름 변경되었는지 확인하고 짧게 테스트하세요. 구독 내용이 바뀌었다면 새 정보를 기준으로 확인하고 이전 값을 억지로 다시 입력하지 마세요. 장기간 수동으로 유지할 정보가 있다면 별도의 관리 방법을 정해 두세요. 업데이트 때마다 모르는 사이에 덮어쓰이지 않도록 해야 합니다.

규칙 파일을 업데이트할 때는 매칭 범위, 순서, 기본 정책, 새로 추가된 고급 처리를 확인하세요. 외부에서 받은 구성이 익숙한 이름이라는 이유만으로 바로 활성화하지 말고 자신의 필요와 관련된 부분을 먼저 읽어보세요. 특히 최종 정책, 거부 규칙, DNS, 인증서 관련 항목은 동작을 크게 바꿀 수 있습니다. 기존 파일은 보관하고 복사본에서 확인한 뒤 교체 여부를 결정하세요. 문제가 생기면 바로 이전 상태로 되돌릴 수 있습니다.

업데이트 후 특정 대상 하나만 실패한다면 모든 서버 업데이트를 바로 취소하지 말고 해당 대상의 규칙과 기록을 비교하세요. 반대로 여러 대상에서 인증 단계가 실패한다면 웹사이트마다 예외를 추가하기보다 서버 정보를 먼저 확인하세요. 문제를 정보, 경로, 규칙, 서비스 응답으로 구분하면 임시 수정 사항이 하나의 구성에 계속 쌓이는 일을 줄일 수 있습니다.

기기 교체, 재설치 및 iPad로 이전

기기를 교체할 때는 먼저 기존 구입 계정으로 App Store에서 앱을 다시 받고 자신의 정보를 복원하세요. 시스템 요구 사항과 구입 적용 범위는 App Store 페이지에 표시된 내용을 기준으로 합니다. 처음 앱을 열었을 때 VPN 구성 권한, 현재 서버, 활성화된 파일을 다시 확인하세요. 구입 항목을 복원했다고 해서 연결 확인을 건너뛰지 마세요. 시스템 백업에 일부 상태가 포함될 수 있지만 새 기기에서 실제로 표시되는 내용과 테스트 결과를 기준으로 판단해야 합니다.

iPhone에서 iPad로 옮기면 가로 화면, 분할 화면, 넓어진 레이아웃에 따라 조작 영역이 달라질 수 있습니다. Home, Config, Data, Settings 등 이름을 기준으로 항목을 찾으세요. 기존 서버 하나의 연결을 확인한 다음 규칙과 온디맨드 조건을 차례로 복원하세요. 두 기기는 네트워크와 사용 환경이 다를 수 있으므로 화면을 똑같이 만들기 위해 모든 설정을 동일하게 적용할 필요는 없습니다. iPad 구입 항목 복원 및 레이아웃 안내도 참고하세요.

문제 사례를 보관하고 연속적인 초기화 피하기

연결이 갑자기 불안정해지면 마지막으로 정상 사용한 시점과 처음 문제가 생긴 시점 사이에 어떤 변화가 있었는지 기록하세요. 구독을 업데이트했는지, 네트워크를 바꿨는지, 규칙이나 시스템 설정을 수정했는지 확인합니다. 현재 표시된 오류와 최근 요청을 보관한 다음 확인된 기준 상태로 되돌려 보세요. 전체 내용을 초기화하면 단서와 정상 작동 설정이 모두 사라집니다. 백업에서 복구할 수 있다는 점을 확인했고 좁은 범위의 점검으로 해결되지 않은 경우에만 큰 범위의 정리를 고려하세요.

오랫동안 사용하지 않은 항목은 더 이상 필요하지 않은지 확인한 뒤 정리할 수 있습니다. 다음 업데이트 때 같은 이름의 복사본이 다시 생기지 않도록 수동 항목과 구독에서 관리하는 항목을 구분하세요. 규칙도 중복, 지나치게 넓은 매칭, 더 이상 필요하지 않은 예외가 있는지 정기적으로 확인해야 합니다. 한 번에 한 종류씩 정리하고 나서 자주 사용하는 대상을 테스트하세요. 삭제한 항목의 개수가 아니라 동작을 더 명확히 이해하고 쉽게 복원할 수 있는지가 유지 관리의 기준입니다.

다른 사람에게 문제를 설명할 때는 기기 유형, 현재 네트워크, 작업 단계, Global Routing, 대상, 오류 유형을 알려주고 서버 정보와 구독, 로그의 민감한 정보는 가리세요. 항목의 의미는 용어집에서 확인할 수 있습니다. 첫 연결 절차를 다시 진행하려면 빠른 사용 안내를 참고하세요. 초보자가 자주 혼동하는 조작은 초보자를 위한 10가지 질문에서 확인할 수 있습니다.

유지 관리를 마친 뒤에는 일정한 짧은 테스트를 진행해 자주 사용하는 페이지, 필요한 로컬 접속, 네트워크 전환 동작을 확인하고 기준 기록을 업데이트하세요. 나중에 결과가 달라지면 모든 설정을 처음부터 추측하지 말고 이 기록과 비교하세요. 매뉴얼의 각 장은 따로 읽을 수 있지만, 앱 구입, 권한, 정보, 라우팅, 확인, 관찰 순서로 진행하면 각 단계의 입력과 결과를 명확히 파악할 수 있습니다.