Shadowrocket
전체 사용 설명서
구입, 가져오기, 트래픽 분기, 연결 확인 및 관리
이 페이지에서는 실제 사용 순서에 따라 Shadowrocket 조작법, 설정의 범위와 문제 해결 방법을 설명합니다. 특정 단계에서 막혔을 때 다시 찾아볼 수 있습니다. 처음 연결한다면 빠른 시작 가이드를 먼저 읽고 전체 과정을 따라 해 보세요. 이 매뉴얼은 각 단계의 이유, 임의로 추측해서는 안 되는 설정값, 문제가 생겼을 때 원인을 좁히는 방법을 보충합니다. 두 페이지는 동일한 인터페이스 용어를 사용하므로 서로 대조해 보기 편리합니다.
이 안내는 주로 iPhone과 iPad를 대상으로 하며, 사용자가 이미 자신의 구독 또는 서버 정보를 보유하고 있다고 전제합니다. 인터페이스 용어는 영어 원문을 유지하며, 실제 위치와 사용 가능한 옵션은 현재 앱 화면을 기준으로 확인하세요. 시스템 요구 사항, 기기 호환성 및 유니버설 구입 적용 여부는 App Store 페이지에 표시된 정보를 기준으로 합니다.
1. App Store에서 구입하고 정품 확인하기
먼저 앱이 맞는지 확인한 뒤 구입하세요. Shadowrocket은 Apple 플랫폼용 유료 상용 앱이며, App Store에서만 구입할 수 있습니다. App Store로 이동하기 전에 정품 확인 안내를 읽고 개발자, 공식 아이콘, 앱 ID를 확인하세요. 검색 결과에 표시된 이름이나 비슷한 아이콘만으로는 앱을 판별할 수 없습니다. 제품 상세 페이지를 열어 여러 항목을 함께 확인한 다음, 시스템의 구입 절차를 진행하세요.
개발자, 아이콘 및 앱 ID 확인
개발자 이름은 Shadow Launch Technology Limited, 앱 ID는 932747118이어야 합니다. 제품 페이지 주소에 포함된 id932747118로 앱 ID를 확인할 수 있습니다. 아이콘은 이 사이트에서 사용하는 공식 아이콘, 즉 흰색 배경에 파란색과 보라색 테두리의 그림과 일치해야 합니다. 이 세 가지 항목을 함께 확인해 앱을 판별하세요. 검색 순위, 이름에 덧붙은 설명이나 이미지의 홍보 문구를 확인 기준으로 삼지 마세요. 앱을 확인한 뒤 가격, 호환성 및 구입 버튼을 살펴보세요.
가격, 호환성, 업데이트 기록 및 구입 안내는 App Store 페이지에 표시된 정보를 기준으로 확인하세요. 기기 요구 사항은 App Store 페이지에 따라 달라질 수 있으므로 본문에는 최소 시스템 버전을 고정해 적지 않습니다. 이 매뉴얼은 주로 iPhone과 iPad를 대상으로 합니다. Mac, Apple TV, Apple Vision에서 사용할 수 있는지도 같은 제품 페이지의 호환성 항목에서 확인하세요. 시스템 요구 사항 및 유니버설 구입 적용 여부는 App Store 페이지에 표시된 정보를 기준으로 합니다.
앱 구입과 연결 서비스 구분하기
1회 구입은 앱을 구입하는 방식을 뜻하며, 서버, 구독 링크 또는 서비스 트래픽이 함께 제공된다는 의미는 아닙니다. 구입을 마친 뒤에도 자신의 서버 정보를 준비하거나 기존 서비스 제공업체에서 구독을 받아야 합니다. 앱을 열 수 있는지, 구입이 완료되었는지, 서버에 연결할 수 있는지는 서로 다른 점검 항목입니다. 예를 들어 앱이 설치되어 있지만 목록이 비어 있다면 가져오기 절차를 진행해야 할 수 있습니다. 이 사실만으로 구입이 무효라고 판단할 수는 없습니다.
가격은 구입 확인 화면에 표시되는 현지 통화 금액을 기준으로 하세요. 미국 스토어의 참고 가격은 2.99달러이며, 최종 가격은 App Store 페이지를 확인하세요. 계정 지역, 결제 조건 및 스토어 표시는 Apple의 구입 절차에서 처리됩니다. App Store에서 구입을 완료할 수 없다면 먼저 시스템에 표시된 구체적인 안내를 확인하세요. Shadowrocket의 네트워크 설정을 반복해서 변경하지 마세요. 앱의 서버 설정으로는 스토어 계정이나 결제 문제를 해결할 수 없습니다.
구입한 앱 다시 받기, 재설치 및 기기 이전
이전에 구입한 적이 있다면 현재 App Store에 로그인된 계정이 원래 구입 계정인지 먼저 확인한 다음, 계정의 구입 항목에서 Shadowrocket을 찾으세요. 제품 페이지에 여전히 가격이 표시되더라도 바로 다시 구입하지 말고 계정, 구입 내역 및 스토어 안내부터 확인하세요. 구입 항목의 이름과 위치는 시스템에 따라 달라질 수 있으므로 기기에 현재 표시되는 내용을 기준으로 합니다. 다른 기기에서 다시 받을 수 있는지도 해당 기기의 호환성과 스토어에 표시된 적용 조건을 함께 확인하세요.
앱을 다시 받는 것과 앱 내 자료를 복원하는 것은 별개의 절차입니다. 스토어는 앱 구입 자격을 확인하며, 기존 구독, 구성 파일, 사용자 규칙 및 통계 기록의 복원 여부는 기기 이전이나 백업 복원 상태에 따라 달라집니다. 앱을 삭제하기 전에 필요한 자료를 저장하세요. ‘나중에 구입 항목에서 다시 받을 수 있다’는 것이 ‘모든 설정이 자동으로 복원된다’는 뜻은 아닙니다. 가족 공유 적용 여부는 제품 페이지와 Apple 계정에 실제로 표시되는 내용을 기준으로 확인하고, 구성 가져오기 단계에서 미리 단정하지 마세요.
앱 업데이트도 App Store에서 진행합니다. 업데이트하기 전에 현재 작동하는 서버와 설정을 기록해 두고, 업데이트한 뒤 이 매뉴얼 5장의 절차에 따라 다시 확인하세요. 구입 및 다시 받기에 관한 주요 질문은 구입 항목 복원과 가격 및 1회 구입 안내를 참고하세요. 이 장에서는 앱의 신원과 구입 범위를 다룹니다. 연결 설정은 다음 장부터 다루므로 두 문제를 구분하면 잘못된 단계에서 불필요한 시도를 반복하지 않을 수 있습니다.
2. 첫 실행 및 시스템 권한
처음 실행하면 먼저 조작 영역을 확인하고, 모든 옵션을 서둘러 변경하지 마세요. Home에서는 서버를 확인하고 연결 대상을 선택한 뒤 연결을 제어합니다. Config에서는 구성 파일을 관리하고, Data에서는 트래픽과 연결 관련 기록을 확인하며, Settings에서는 앱 설정을 조정합니다. 구체적인 화면 배치는 기기에 표시되는 현재 화면을 기준으로 확인하세요. 영어 용어를 확인해야 한다면 인터페이스 영어 용어 안내를 함께 참고하고, 아이콘 모양만으로 메뉴를 추측하지 마세요.
VPN 구성 권한은 언제 승인하나요?
앱이 연결을 설정하려고 할 때 시스템에서 VPN 구성을 추가하도록 허용해 달라는 메시지가 표시될 수 있습니다. 이 메시지는 네트워크 확장 구성에 대한 시스템 권한 요청이지, 서버를 추가하거나 별도의 서비스를 구입하는 절차가 아닙니다. 현재 사용 중인 Shadowrocket에서 나온 메시지인지 확인한 뒤 시스템 안내에 따라 승인하세요. 승인 후에도 사용할 서버 설정과 올바른 작동 방식이 필요합니다. 권한 승인이 이러한 준비를 대신하지는 않습니다.
권한 요청을 닫았다면 앱으로 돌아가 연결 스위치 상태를 확인한 다음, 정상적인 연결 절차를 다시 진행하세요. 요청이 언제 표시되는지 헷갈리지 않도록 스위치를 연속해서 빠르게 누르지 마세요. 시스템에 구성 관리 제한 또는 추가 실패 안내가 표시되면 기기의 관련 설정과 관리 상태를 먼저 확인하세요. 관리되는 기기의 제한은 앱에서 해제할 수 없을 수도 있습니다. 문제를 해결할 때는 모든 권한 실패를 서버 문제로 단정하지 말고 안내 문구를 원문 그대로 기록하세요.
필요한 권한만 허용하기
Scan QR Code를 사용할 때 시스템에서 카메라 접근 권한을 요청할 수 있습니다. 자신의 연결 정보를 카메라로 스캔할 경우에만 이 요청을 처리하면 됩니다. 카메라 권한을 거부해도 서버를 직접 추가하거나 기존 구독을 가져올 수 있습니다. 나중에 QR 코드를 스캔하려면 시스템 설정에서 앱의 권한을 확인하세요. 화면에 QR 코드가 여러 개 보인다면 인식 결과가 원하는 연결 정보에 해당하는지 확인하세요.
클립보드에서 링크를 붙여넣거나 파일 위치에서 구성을 선택하는 등 다른 가져오기 방법을 이용할 때도 관련 시스템 안내가 표시될 수 있습니다. 권한은 현재 작업에 맞춰 처리하세요. 붙여넣는 중에는 붙여넣기 요청을, 파일을 선택하는 중에는 파일 출처를 확인하면 됩니다. ‘미리 준비해 두기’ 위해 현재 작업과 무관한 권한까지 허용할 필요는 없습니다. 가져오기가 진행되지 않았다면 시스템 선택 창을 취소했는지 먼저 확인한 다음 콘텐츠 형식을 점검하세요.
시스템 연결 상태와 앱 상태를 구분해서 확인하기
시스템에 VPN 연결됨이라고 표시되더라도 해당 네트워크 구성이 연결된 상태라는 뜻일 뿐, 원격 서버, DNS 또는 대상 웹사이트가 모두 정상이라는 의미는 아닙니다. 반대로 Home에서 유효한 서버를 선택하지 않았다면 VPN 구성 추가를 허용했더라도 원하는 프록시 연결을 완료할 수 없습니다. 처음에는 ‘정보 가져오기 완료, 대상 선택, 모드 확인, 스위치 켜기’ 순서로 점검하고, 단일 상태 표시만으로 최종 결론을 내리지 마세요.
기기에서 네트워크 확장을 사용하는 다른 앱이나 시스템 구성을 사용 중이라면 현재 실제로 작동하는 연결 대상을 먼저 확인하세요. 한 번의 테스트에서 네트워크 도구 여러 개와 시스템 설정 여러 항목을 동시에 바꾸면 구성 전환으로 인한 중단을 Shadowrocket 설정 오류로 오해하기 쉽습니다. 용도를 모르는 시스템 구성은 바로 삭제하지 마세요. 먼저 이름, 출처 및 기기 관리 요구 사항을 확인한 다음 비활성화할지 또는 관리자에게 문의할지 결정하세요.
첫 사용 시 점검 기준 세우기
첫 실행 단계에서는 세 가지를 기록해 두는 것이 좋습니다. Home 화면이 정상적으로 표시되는지, VPN 구성 추가가 성공했는지, 현재 Wi-Fi와 셀룰러 네트워크 중 무엇을 사용하는지 확인하세요. 비밀번호나 전체 구독 주소를 기록할 필요는 없습니다. 이 기본 정보는 문제가 앱 실행 전, 시스템 권한 승인 단계 또는 원격 연결 단계 중 어디에서 발생했는지 파악하는 데 도움이 됩니다. 앱은 정상적으로 열리지만 네트워크 요청에 실패한다면 반복해서 재설치하기보다 연결 정보를 확인하는 편이 더 유용합니다.
권한 처리가 끝난 뒤에도 서버 목록이 비어 있다면 다음 장에서 기존 정보를 추가하세요. 목록이 복원되었다면 이전 기기의 상태를 기억에 의존하지 말고 선택된 대상과 Global Routing을 다시 확인하세요. 기기 이전으로 일부 데이터가 유지될 수는 있지만, 네트워크 환경과 시스템 권한은 새 기기에서 직접 점검해야 합니다. 첫 실행의 목적은 명확한 출발점을 만드는 것이지 모든 고급 설정을 한 번에 마치는 것이 아닙니다.
3. 기존 서버 및 Subscribe 가져오기
가져오기 전에 정보의 종류를 세 가지로 구분하세요. 개별 서버 설정값은 하나의 연결 항목을 만들 때 사용하고, 구독 주소는 서버 목록을 가져오고 업데이트할 때 사용합니다. 구성 파일은 DNS, 규칙 및 기타 작동 설정을 지정합니다. 이 정보들이 하나의 안내문에 함께 포함될 수 있지만 용도는 서로 다릅니다. 구독 주소를 서버 주소 입력란에 넣거나 구성 파일을 서버 비밀번호로 취급하면 올바른 결과를 얻을 수 없습니다. 먼저 정보의 종류를 확인한 뒤 해당하는 메뉴를 선택하세요.
Add Server에서 직접 입력
Add Server로 추가할 때는 먼저 기존 정보와 일치하는 Type을 선택한 다음 주소, 포트 및 인증 항목을 입력하세요. 주소에는 요구된 서버 호스트 이름 또는 주소만 입력하고, 포트에는 제공된 숫자를 사용하세요. 프로토콜 접두사가 포함된 전체 링크를 일반 주소 입력란에 붙여넣지 마세요. 입력한 뒤 각 항목을 대조하고, 복사 과정에서 앞뒤에 공백이 들어갔는지, 중국어 문장 부호가 포함되었는지, 영문 대소문자가 정확한지 특히 확인하세요. 저장이 완료되어도 서버 항목이 만들어졌다는 의미일 뿐, 연결 확인은 별도로 해야 합니다.
| 항목 | 확인할 내용 | 임의로 추정하면 안 되는 부분 |
|---|---|---|
| Type | 기존 정보와 프로토콜이 일치하는지 | 포트 번호만으로 프로토콜을 판단할 수 없음 |
| 주소 및 포트 | 호스트 이름, 숫자 및 공백 | 웹페이지 주소로 서버 주소를 대신할 수 없음 |
| 인증 | 비밀번호, UUID 또는 키 관련 항목 | 프로토콜마다 항목이 달라 서로 바꿔 쓸 수 없음 |
| TLS 및 전송 | 정보에 따라 이름, 경로 등의 옵션 확인 | 연결을 시도하려고 검증을 임의로 해제하면 안 됨 |
Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard, HTTP 및 SOCKS5는 입력 항목이 서로 완전히 같지 않습니다. 한 프로토콜에 비밀번호가 필요하다고 해서 다른 프로토콜에도 같은 정보를 입력해야 하는 것은 아닙니다. UUID, 키, TLS 이름 또는 전송 경로가 있다면 해당 항목에 맞게 입력하세요. 정보에 설명되지 않은 고급 옵션은 다른 프로토콜의 설정을 그대로 따라 하지 말고 기존 서비스 제공업체에 확인하세요.
Subscribe 주소 및 그룹 업데이트
기존 구독은 자신의 서비스 제공업체에서 받아 앱이 지원하는 구독 가져오기 메뉴로 추가하세요. Add Server에서 Subscribe 유형을 사용하는 경우 화면 안내에 따라 구독 주소와 알아보기 쉬운 이름을 입력하세요. 저장한 다음 업데이트를 실행해 원하는 서버가 표시되는지 확인하세요. 구독을 내려받는 것과 서버에 연결하는 것은 별도의 확인 단계입니다. 첫 단계에서는 목록을 가져올 수 있는지 확인하고, 다음 단계에서는 목록에 있는 개별 서버의 연결 여부를 확인해야 합니다.
구독 업데이트에 실패하면 주소가 완전한지, 줄바꿈이 포함되었는지, 현재 네트워크에서 해당 주소에 접근할 수 있는지 먼저 확인하세요. 로그인 페이지, 안내 페이지 또는 지원되지 않는 데이터가 반환되면 앱이 서버 목록을 만들지 못할 수 있습니다. 기존 서비스 만료, 링크 변경 또는 인증 정보 만료도 업데이트에 영향을 줄 수 있습니다. 앱에 표시된 오류를 서비스 제공업체가 알려 준 구독 상태와 대조하세요. 목록의 항목 수가 달라졌다는 이유만으로 항목을 반복해서 삭제하고 다시 만들지 마세요.
QR 코드, 링크 및 구성 가져오기의 범위
Scan QR Code는 자신이 보유한 QR 코드 정보를 가져올 때 적합합니다. 인식이 끝난 뒤에도 Type, 이름 및 주요 설정값이 예상과 일치하는지 확인하세요. QR 코드는 정보를 담는 수단일 뿐, 정보가 정확하거나 유효하다는 것을 보장하지 않습니다. 링크 가져오기도 마찬가지입니다. 접근 자격 정보가 포함된 QR 코드, 전체 구독 주소 및 공유 링크는 민감한 정보로 취급해야 하며 공개 스크린샷, 댓글 또는 문제 해결 기록에 노출하지 마세요.
Config의 구성 파일과 Subscribe 업데이트로 받은 서버 목록은 별도로 관리하세요. 규칙이 포함된 파일을 가져온 뒤에는 현재 구성으로 선택되었는지 확인해야 합니다. 구독을 업데이트한 뒤에도 기본 서버가 남아 있는지 확인하세요. 일부 자료에는 서버와 설정이 함께 포함될 수 있지만, 파일 확장자나 이름만 보고 용도를 단정하지 말고 앱에서 실제로 인식한 내용을 확인하세요.
가져오기가 끝나면 Home으로 돌아가 서버 하나를 명확히 선택하고, 편집 화면을 열어 보기만 한 것이 아니라 왼쪽 선택 표시가 해당 항목에 있는지 확인하세요. 이름이 비슷한 항목은 혼동하기 쉬우므로 직접 만든 항목에는 용도를 알 수 있는 메모를 추가하되 비밀번호는 적지 마세요. 중복 항목을 정리할 때는 먼저 출처 그룹을 확인하세요. 구독으로 생성된 항목은 다음 업데이트 때 다시 나타날 수 있으므로 개별 결과만 삭제하기보다 구독 출처를 중심으로 관리해야 합니다.
이 장의 완료 기준은 ‘정보가 올바르게 인식되었고 현재 선택한 서버를 명확히 말할 수 있음’이지 ‘목록에 항목이 많이 있음’이 아닙니다. 다음으로 Global Routing을 선택하고 연결을 확인하세요. 구독 업데이트에 문제가 있다면 오류 원문과 발생 단계를 먼저 보관한 뒤 8장의 관리 순서에 따라 처리하세요. 목록을 가져오지 못한 문제와 개별 서버에 연결할 수 없는 문제를 혼동하지 않도록 합니다.
4. Global Routing 및 규칙 순서
Global Routing은 현재 트래픽을 어떤 방식으로 처리할지 결정합니다. 구성에 따라 처리, 프록시, 직접 연결의 세 가지 방식은 인터페이스에서 각각 Config, Proxy, Direct로 표시됩니다. 규칙에 따라 트래픽을 분기하는 일반적인 사용에는 보통 Config를 선택합니다. Proxy와 Direct는 명확한 상황이나 비교 테스트에 사용할 수 있습니다. 이 설정은 서버를 변경하거나 다른 구성 파일을 선택하는 기능이 아니므로 모드, 현재 구성 및 선택된 연결 대상을 각각 확인하세요.
세 가지 방식의 제어 대상
| 인터페이스 용어 | 주요 동작 | 중점적으로 확인할 사항 |
|---|---|---|
| Config | 현재 구성의 규칙에 따라 경로 결정 | 파일 선택 여부, 규칙 일치 여부 |
| Proxy | 트래픽을 프록시로 처리 | 선택한 서버 및 연결 조건 |
| Direct | 트래픽을 직접 연결로 처리 | 현재 네트워크 자체의 연결 가능 여부 |
세 가지 방식은 앱의 시스템 우회 설정, 트래픽 처리 범위 및 실제 구성과 함께 이해해야 합니다. 기기의 모든 시스템 통신이 동일한 경로를 사용한다고 단정할 수는 없습니다. 문제 해결을 위해 Proxy로 전환하면 특정 분기 규칙과 관련이 있는지 확인할 수 있지만, 모든 연결 실패를 해결하는 스위치는 아닙니다. Direct로 전환해도 DNS, 원격 웹사이트 또는 현재 네트워크 연결이 정상이라고 증명되지는 않습니다.
.conf 파일을 순서대로 읽기
다음 구성 조각은 문법 설명을 위한 예시이며 모든 네트워크 환경에 적합한 완성형 구성이 아닙니다. [General]에는 일반 설정을, [Rule]에는 규칙을 작성합니다. 규칙은 일반적으로 위에서 아래로 일치 여부를 확인하며, 먼저 일치한 항목이 처리 방식을 결정합니다. PROXY, DIRECT, REJECT는 처리 정책을 나타내며 서버 프로토콜 이름이 아닙니다. 수정하기 전에 원본 파일을 저장하고 한 번에 한 항목만 변경하세요.
[General]
bypass-system = true
dns-server = system
skip-proxy = 192.168.0.0/16, localhost
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,DIRECT
IP-CIDR,10.0.0.0/8,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY
이 예시에서는 example.com과 접미사 조건에 해당하는 하위 도메인이 먼저 DOMAIN-SUFFIX 규칙에 적용되므로 뒤에 있는 DOMAIN-KEYWORD 규칙에는 도달하지 않습니다. 그 외에 해당 키워드가 포함된 도메인만 다음 줄에 일치할 수 있습니다. IP-CIDR은 주소 범위에 사용하고 GEOIP는 주소 위치 데이터에 따라 판단하며, FINAL은 앞선 규칙에 하나도 일치하지 않을 때 최종 처리에 사용합니다. 범위가 넓은 규칙을 앞에 두면 별도로 처리하려던 뒤쪽 대상이 해당 규칙에 가려질 수 있습니다.
도메인 규칙과 주소 규칙은 서로 바꿔 쓸 수 없음
DOMAIN은 완전한 도메인 일치에, DOMAIN-SUFFIX는 접미사 범위에, DOMAIN-KEYWORD는 키워드 범위에 사용합니다. 키워드 범위는 예상보다 넓을 수 있으므로 새 규칙을 추가할 때 이름은 비슷하지만 용도가 다른 대상까지 영향을 받지 않는지 확인하세요. IP-CIDR과 IP-CIDR6은 각각 해당 주소 범위를 설명하며 특정 웹사이트를 직접 지정하지 않습니다. 하나의 서비스가 여러 도메인과 주소를 사용할 수 있으므로 규칙 하나가 일치한다고 해서 페이지의 모든 요청이 같은 경로를 이용한다는 뜻은 아닙니다.
GEOIP는 주소 위치 데이터와 실제 주소 해석 결과에 따라 달라지므로 웹페이지의 언어나 회사 소재지만 보고 규칙이 적용될지 추정할 수 없습니다. DNS 해석은 이후 주소 기반 규칙에서 확인할 수 있는 대상에 영향을 줄 수 있지만, DNS 설정 자체는 트래픽 분기 규칙이 아닙니다. USER-AGENT 등의 조건을 사용할 때는 현재 앱이 지원하는 범위와 실제로 확인할 수 있는 정보를 먼저 점검하세요. 모든 암호화된 요청을 안정적으로 식별할 수 있는 조건으로 취급해서는 안 됩니다.
규칙 수정 후 확인 방법
먼저 현재 Global Routing이 Config인지 확인한 뒤, 방금 수정한 파일이 현재 구성으로 선택되어 있는지 확인하세요. 명확한 대상 하나에 요청을 보내고 확인 가능한 기록에서 도메인, 일치한 규칙 및 정책 정보를 살펴보세요. 기록에 이전 경로가 계속 표시된다면 앱에서 구성을 다시 불러오거나 연결을 다시 설정해야 하는지 확인하고, 대상 앱이 기존 연결을 재사용했을 가능성도 고려하세요. 페이지가 열리는지만 보고 새 규칙이 적용되었다고 판단하지 마세요. 캐시된 콘텐츠로 페이지가 정상처럼 보일 수 있습니다.
로컬 네트워크 접근에 문제가 있다면 공용 웹사이트가 정상인지 여부만 확인하지 말고 실제 주소 범위, 관련 우회 설정 및 규칙 순서를 확인하세요. DNS 관련 원리는 DNS 설정 안내에서, 간단한 용어 설명은 용어 빠른 확인에서 더 알아볼 수 있습니다. 이 장의 핵심은 ‘모드, 구성, 규칙, 정책’을 차례로 확인하는 것입니다. 특정 키워드만 기억하는 것으로 전체 경로를 판단할 수는 없습니다.
5. 연결, Connectivity Test 및 문제 해결
연결은 세 단계로 확인하세요. 앱이 연결을 설정했는지, 선택한 서버를 사용할 수 있는지, 실제 대상에 대한 요청이 예상대로 완료되는지 확인합니다. Home 상단의 스위치, Connectivity Test 및 실제 접속은 각각 다른 정보를 제공하므로 서로 대신할 수 없습니다. 시작하기 전에 현재 네트워크가 작동하는지, 기존 정보가 유효한지, 서버 하나가 명확히 선택되었는지 확인하세요. 테스트 중에 구독 업데이트, DNS 변경 및 구성 교체를 동시에 하지 마세요.
정해진 순서로 연결하기
Home에서 대상 서버를 선택하고 왼쪽 선택 표시가 해당 항목에 있는지 확인한 다음 Global Routing을 점검하세요. 연결 스위치를 켜고 시스템에서 VPN 구성 권한을 요청하면 2장의 절차에 따라 처리하세요. 상태가 안정될 때까지 기다린 뒤 테스트를 시작합니다. 목록에 이름이 같은 항목이 있다면 그룹과 Type을 함께 확인해 구분하세요. 한 항목을 편집한 뒤 실제로는 다른 기존 항목에 연결하는 상황을 피할 수 있습니다.
Connectivity Test를 실행한 뒤 성공, 실패 또는 시간 초과 등 실제 결과를 기록하고 실제 접속도 한 번 시도하세요. 테스트 결과는 해당 테스트 대상과 방식에 관련된 조건만 보여 주므로 모든 대상 서비스가 정상이라고 보장하지 않습니다. 테스트는 실패했지만 실제 접속이 가능하다면 테스트 대상 자체에 별도의 접근 제한이 있는지 확인하세요. 반대로 테스트는 성공했지만 특정 페이지가 열리지 않는다면 해당 페이지의 도메인, DNS 및 규칙을 계속 점검해야 합니다.
지연 시간 수치와 실제 접속의 차이
지연 시간 테스트는 같은 조건에서 응답 차이를 비교하는 데 유용하지만 대역폭, 지속적인 안정성 또는 특정 콘텐츠 서비스의 성능을 직접 나타내지는 않습니다. 테스트 시간, 접속 네트워크, 대상 및 방법이 달라지면 수치를 단순 비교할 수 없습니다. 지연 시간이 한 번 낮게 나왔다고 해서 인증, 전송 설정 및 장시간 연결이 정상이라고 볼 수는 없습니다. 기존 구독의 서버를 선택할 때는 지연 시간, 지역 및 프로토콜 안내를 참고해 수치가 의미하는 범위를 확인하세요.
증상에 따라 문제 범위 좁히기
| 증상 | 우선 확인할 항목 | 다음 단계 |
|---|---|---|
| 스위치를 켜도 연결이 유지되지 않음 | 시스템 권한, 선택된 대상, 오류 안내 | 구성 불러오기 문제와 원격 연결 오류 구분 |
| 모든 테스트가 시간 초과됨 | 현재 네트워크, 주소와 포트, 서비스 유효 여부 | 기존의 다른 서버 항목과 비교 |
| 일부 웹사이트에서만 문제 발생 | 대상 도메인, 적용 정책, DNS | Config와 통제된 테스트 결과 비교 |
| 네트워크를 전환한 뒤 문제 발생 | 새 네트워크의 연결 가능 여부 및 연결 상태 | 안정적인 네트워크에서 연결 다시 설정 |
모든 대상에 연결할 수 없다면 먼저 기본 네트워크를 확인한 다음, 선택한 서버의 주소, 포트, 인증 및 TLS 설정을 점검하세요. 현재 네트워크에서 일반 서비스에도 접속할 수 없다면 네트워크 연결 문제부터 해결해야 합니다. 서버 하나만 실패한다면 사용자가 이미 보유한 다른 서버를 선택해 비교해 볼 수 있습니다. 다른 서버가 성공하면 문제 범위를 좁힐 수 있지만, 한 번의 결과만으로 원래 서버를 영구적으로 사용할 수 없다고 단정해서는 안 됩니다.
일부 대상에만 연결할 수 없다면 구체적인 대상과 발생 시간을 기록하고 관련 요청에 어떤 규칙이 적용되었는지 비교하세요. 웹페이지는 보통 기본 문서, 이미지, API 및 인증 등에 여러 도메인을 사용하므로 도메인 하나의 경로가 잘못되어도 일부 기능에 문제가 생길 수 있습니다. Proxy로 전환하는 것은 잠깐 비교해 보는 용도로만 사용하고 테스트가 끝나면 원래 모드로 복구하세요. 전환 후 문제가 해결되었다면 구성 전체를 바로 삭제하지 말고 트래픽 분기와 주소 해석을 확인하세요.
네트워크 전환 후 연결 다시 설정하기
Wi-Fi에서 셀룰러 네트워크로 전환하면 기존 연결을 다시 설정해야 할 수 있습니다. 먼저 기기의 네트워크가 안정될 때까지 기다린 다음 연결 스위치를 껐다가 다시 켜고 같은 테스트를 반복하세요. 접속 네트워크가 원인인지 판단하려면 대상과 서버를 그대로 유지해야 합니다. 서버, 구성 및 네트워크를 동시에 바꾸면 문제가 해결되더라도 어떤 변경이 효과가 있었는지 알 수 없습니다.
TLS 또는 인증 관련 오류는 기존 정보와 기기 시간을 항목별로 대조하세요. 인증서 검증을 끄는 것을 기본 해결책으로 삼지 마세요. 연결 확인 조건이 달라져 도메인이나 시간 설정의 오류를 감출 수도 있습니다. 판단하기 어려운 항목은 기존 서비스 제공업체에 확인하세요. 문제를 알릴 때는 오류 유형, 프로토콜, 작업 순서 및 네트워크 유형을 설명하면 됩니다. 전체 비밀번호, 키 및 구독 주소를 공개 기록에 올리지 마세요.
확인이 끝나면 현재 네트워크, 선택한 서버, Global Routing, 사용 중인 구성 및 실제 테스트 결과를 설명할 수 있어야 합니다. 이 간단한 기준 정보는 ‘연결됨으로 나오지만 작동하지 않음’이라는 설명보다 문제를 진단하는 데 유용합니다. 다음으로 Data를 확인하는 이유는 방금 보낸 요청을 더 자세히 이해하기 위해서이지 누적 트래픽 수치로 연결 테스트 결과를 대신하기 위해서가 아닙니다.
6. Data 트래픽 통계 및 요청 기록
Data에서는 앱에 기록된 트래픽과 연결 정보를 확인할 수 있습니다. 테스트 중 요청이 발생했는지, 어떤 대상에서 문제가 생겼는지, 경로가 규칙에 맞는지 등을 파악하는 데 도움이 됩니다. 그러나 서비스 제공업체의 계정 청구 내역이 아니며 기기의 모든 네트워크 활동을 합산한 수치도 아닙니다. 수치를 해석하기 전에 집계 대상과 기간을 확인하세요. 범위가 다른 통계를 바로 빼서 앱이나 서비스의 문제라고 판단하지 마세요.
통계 범위를 먼저 확인한 뒤 수치 살펴보기
트래픽을 확인할 때 화면의 수치가 현재 연결, 특정 통계 기간 또는 누적 기록 중 무엇을 나타내는지 확인하고 업로드와 다운로드도 구분하세요. 재연결, 통계 재설정, 앱 데이터 복원 및 사용 중인 설정에 따라 집계 범위가 달라질 수 있으므로 현재 화면의 안내를 기준으로 합니다. 수치를 기록할 때는 측정 시작 및 종료 시간도 함께 적으세요. 그렇지 않으면 변화가 테스트 요청 때문인지 그동안 발생한 다른 백그라운드 활동 때문인지 판단하기 어렵습니다.
클라이언트와 서비스 제공업체는 서로 다른 방식으로 사용량을 측정할 수 있습니다. 프로토콜 오버헤드, 집계 기준, 연결 재시도, 기간 및 단위에 따라 차이가 생길 수 있습니다. Data에 트래픽이 표시되어도 서비스 제공업체의 계정에 같은 수치로 청구된다는 의미는 아닙니다. 서비스 제공업체에 표시된 잔여량을 로컬 누적 수치만으로 역산할 수도 없습니다. 기존 서비스의 용량과 이용 기간은 해당 서비스 제공업체의 계정 정보를 확인하세요.
독립적인 요청 한 건으로 관찰 기준 세우기
문제를 해결할 때는 동시에 진행하는 작업을 최소화하세요. 현재 상태를 기록하고 명확한 대상 하나를 열어 본 다음 Data로 돌아가 해당 시간대의 변화를 확인합니다. 여러 앱이 동시에 새로 고침되면 기록에 테스트와 무관한 요청이 포함될 수 있습니다. 시스템 백그라운드 통신도 기록될 수 있으므로 낯선 도메인을 보더라도 방금 연 페이지에서 발생했다고 바로 단정하지 마세요. 시간, 대상 및 반복 테스트 결과를 함께 고려해 관련성을 판단하세요.
현재 화면에 대상 도메인, 주소, 정책, 일치한 규칙 또는 오류 정보가 표시된다면 각 항목을 확인하세요. 대상 도메인은 어디에 접속했는지, 정책은 어떻게 처리했는지, 오류 정보는 어느 단계에서 실패했는지를 나타냅니다. 세 가지 정보를 연결해서 읽어야 합니다. 요청 하나에 DIRECT가 적용되었다고 해서 자동으로 규칙 오류인 것은 아닙니다. 설정한 요구 사항과 맞지 않을 때만 현재 구성에서 일치한 이유를 확인하세요.
기록을 바탕으로 규칙 및 DNS 확인하기
대상에 예상과 다른 정책이 적용되었다면 먼저 Global Routing이 Config인지 확인한 다음, 구성 파일과 규칙의 순서를 점검하세요. 대상이 주소 형태로 표시된다면 DNS 및 앱 자체의 접속 방식도 고려해야 합니다. 기록에 나온 주소 하나를 무작정 넓은 주소 범위 규칙으로 만들지 마세요. 하나의 주소가 여러 서비스를 처리할 수 있으므로 범위를 함부로 넓히면 정상적인 다른 요청에 영향을 줄 수 있습니다.
도메인 이름 해석에 실패했다면 DNS 관련 조건에 주의를 기울이세요. 주소는 해석되었지만 원격 연결이 시간 초과되었다면 서버, 라우팅 및 대상에 접근할 수 있는지 계속 확인해야 합니다. 두 문제는 서로 영향을 줄 수 있지만 해결 순서는 다릅니다. 기록의 오류는 진단을 위한 단서이므로 실제 작업과 연결해 해석해야 하며, 발생 상황과 분리해 결론을 내릴 수는 없습니다. 주소 해석 설정은 7장을 참고하고, Data 기록을 반복해서 지우지 마세요.
재설정, 기록 보관 및 민감 정보
통계를 재설정하면 다음 비교를 위한 명확한 기준을 만들 수 있지만 서버를 고치거나 규칙을 변경하거나 서비스 제공업체의 집계량을 재설정하지는 않습니다. 재설정하기 전에 비교할 수치와 시간을 저장해 유일한 문제 해결 단서를 잃지 않도록 하세요. 짧은 테스트만 관찰하려는 경우에는 모든 과거 데이터를 지우지 않고 테스트 전후 차이를 기록해도 됩니다.
기록을 공개하기 전에 전체 대상 주소, 쿼리 매개변수, 구독 인증 정보, 인증 항목 또는 개인 접속 내역이 포함되어 있는지 확인하세요. 스크린샷에 비밀번호가 보이지 않더라도 토큰이 포함된 링크가 노출될 수 있습니다. 오류 유형과 필요한 항목만 발췌하고 관련 없는 개인 정보를 가리는 방식으로 전달하는 것이 좋습니다. 정보를 가린 뒤에도 항목 간 관계는 유지해야 상대방이 DNS 실패, 인증 실패 또는 원격 시간 초과 중 무엇인지 구분할 수 있습니다.
장기간 관찰할 때는 일정한 시간 범위와 같은 테스트 방법을 사용해야 의미 있는 비교가 가능합니다. 간헐적인 트래픽 급증은 정상적인 백그라운드 작업 때문일 수 있으므로 한 번의 변화만 보고 모든 구독을 다시 가져오지 마세요. 문제가 반복되면 네트워크 전환, 구성 업데이트 및 오류 발생 시간을 간단한 타임라인으로 보관하세요. 이렇게 기록하면 사용 동작과 결과를 연결할 수 있으며 다음 장의 설정 변경에도 참고할 수 있습니다.
7. Settings, DNS 및 On Demand
Settings는 명확한 필요에 맞춰 조정해야 하며 모든 옵션을 한꺼번에 변경하지 마세요. 처음에는 작동하는 기준 설정을 유지한 뒤 DNS, On Demand 또는 진단 관련 설정을 필요한 만큼 조정하세요. 일부 설정은 앱 화면에 있고 다른 설정은 구성 파일에 있으므로 현재 선택된 구성과 함께 확인해야 합니다. 현재 화면에 표시되지 않는 옵션을 다른 스크린샷의 위치만 보고 찾거나 비슷한 이름을 입력하지 마세요.
시스템 DNS 및 사용자 지정 DNS
DNS는 도메인 이름을 이후 연결에 사용할 주소로 변환하고, 트래픽 분기 규칙은 요청을 어떻게 처리할지 결정합니다. 둘은 관련이 있지만 서로 다른 기능입니다. dns-server = system은 해당 항목에서 시스템 DNS 설정을 사용한다는 뜻이며, 구성의 동작을 이해하기 위한 출발점 중 하나입니다. 하지만 모든 네트워크 환경에서 결과가 같다고 보장하지는 않습니다. Wi-Fi와 셀룰러 네트워크 사이에서 기기를 전환하면 시스템이 제공하는 주소 해석 조건도 달라질 수 있습니다.
[General]
dns-server = system
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY
사용자 지정 DNS 또는 DNS over HTTPS를 사용하려면 먼저 주소 해석 서비스에 현재 네트워크에서 접근할 수 있는지 확인한 다음 앱에서 지원하는 입력 형식을 점검하세요. 주소 해석 서비스에도 연결할 수 있어야 합니다. 해당 서비스의 연결 조건이 충족되지 않으면 설정을 변경한 뒤 더 많은 대상에서 문제가 생길 수 있습니다. DNS 변경이 서버 인증을 바꾸는 것은 아니며, 암호화된 주소 해석만으로 모든 연결 문제를 자동 해결할 수도 없습니다.
설정을 변경한 뒤에는 같은 대상을 사용해 확인하고 캐시의 영향도 고려하세요. 대상 앱이 이전에 얻은 주소나 기존 연결을 재사용할 수 있으므로 잠깐 동안 변화가 보이지 않더라도 설정이 적용되지 않았다고 단정할 수 없습니다. 먼저 구성이 불러와졌는지 확인한 다음 필요에 따라 연결을 다시 설정하세요. 주소 해석 설정을 연속해서 여러 개 교체하지 마세요. 자세한 내용은 시스템 DNS, 사용자 지정 DNS 및 DNS over HTTPS 안내를 참고하세요.
On Demand는 연결 조건이지 서버 복구 기능이 아님
On Demand는 설정한 조건에 따라 연결을 시작하는 기능이며, 수동 연결이 안정적으로 작동한 뒤 설정하는 것이 좋습니다. 네트워크 유형, Wi-Fi 이름 또는 도메인 조건은 현재 화면의 규칙에 따라 입력하고 각각 확인하세요. On Demand는 연결이 시작되는 시점을 바꿀 뿐 잘못된 비밀번호, 만료된 구독 또는 연결할 수 없는 서버를 자동으로 고쳐 주지 않습니다. 수동 연결도 실패한다면 자동 연결을 설정하기 전에 연결 자체부터 해결하세요.
설정하기 전에 ‘지정한 네트워크 조건에서 연결 시작’처럼 원하는 동작을 분명히 작성한 다음 범위가 겹치는 조건이 있는지 확인하세요. 여러 조건의 우선순위를 기억에 의존해 추측하지 말고 앱 내 안내와 실제 테스트를 기준으로 판단하세요. 테스트할 때 조건에 해당하는 환경과 해당하지 않는 환경에 각각 연결해 예상대로 작동하는지 확인해야 합니다. 한 가지 네트워크에서만 테스트하면 조건이 지나치게 넓은지 알 수 없고 이후 잘못된 자동 연결이 발생한 이유도 설명할 수 없습니다.
수동으로 연결을 끈 뒤 곧바로 다시 연결된다면 스위치가 고장 났다고 단정하기 전에 On Demand가 켜져 있는지 확인하세요. 임시로 문제를 해결하는 동안에는 자동 연결을 중지한 뒤 수동 테스트 기준을 세울 수 있습니다. 조건을 장기적으로 조정하려면 Wi-Fi, 셀룰러 네트워크 및 도메인별 On Demand 설정을 참고하세요. 연결 조건과 서버 정보를 동시에 변경하지 마세요.
진단 스위치 및 고급 설정의 범위
로그 또는 진단 관련 옵션은 필요한 경우에만 켜고, 기록에 접속 대상과 연결 정보가 포함될 수 있다는 점에 유의하세요. 문제 해결이 끝나면 필요에 따라 원래 설정으로 되돌리세요. 기록을 더 많이 남긴다고 연결이 더 안정적으로 유지되는 것은 아닙니다. 기록의 목적은 판단에 필요한 근거를 제공하는 것입니다. 시스템 시간, 인증서 검증 및 전송 설정 등이 연결에 영향을 준다면 기존 서비스 안내에 따라 확인하세요. 보안 검증 항목을 일반적인 속도 조정 옵션으로 취급하지 마세요.
익숙하지 않은 고급 설정은 먼저 앱 내 안내를 읽고 기존 값을 기록한 뒤 한 항목씩 시험하세요. 변경 후 문제가 생기면 원래 값으로 되돌리고 같은 방식으로 다시 확인하세요. ‘도움이 될지도 모르는’ 옵션을 계속 추가하지 마세요. 구성 파일의 비슷한 항목도 현재 작동 상태에 영향을 주는지 확인해야 합니다. 파일을 편집했다는 이유만으로 앱이 해당 설정을 사용한다고 단정할 수 없습니다. 설정 변경과 구성 선택을 함께 기록하는 것이 좋습니다.
처음 연결하는 것이 목적이라면 Settings에서 모든 고급 설정을 완료할 필요는 없습니다. 먼저 5장으로 돌아가 작동 결과를 명확히 확인한 뒤 필요한 항목을 하나씩 추가하세요. 인터페이스 용어와 프로토콜 설정 설명은 용어 빠른 확인에서, 세 가지 작동 방식에 관한 설명은 프록시 모드에서 확인할 수 있습니다. 이 장의 핵심은 특정 설정값을 고정하는 것이 아니라 모든 설정 변경에 검증 가능한 목적을 두는 것입니다.
8. 구독 업데이트, 백업 및 일상 관리
일상적인 관리는 세 가지 목표를 중심으로 진행합니다. 기존 정보를 유효하게 유지하고, 복원 가능한 설정을 보존하며, 문제가 생겼을 때 원인을 찾을 수 있도록 합니다. 구독 업데이트, 앱 업데이트 및 규칙 수정은 서로 다른 작업이므로 한 번의 문제 해결 과정에서 동시에 하지 않는 것이 좋습니다. 연결이 정상이라면 새 옵션이 보인다는 이유만으로 바로 변경하지 마세요. 실제 변경이 필요할 때는 현재 상태를 기록하고 명확한 순서에 따라 진행하세요.
구독 업데이트 전후 확인하기
업데이트하기 전에 구독 출처와 그룹을 확인하고 현재 선택한 서버와 사용 중인 구성을 기록하세요. 업데이트한 뒤 오류 안내가 있는지, 항목이 예상대로 표시되는지, 이전에 선택했던 서버가 남아 있는지 살펴보세요. 서비스 제공업체가 이름, 항목 수 또는 설정값을 바꿀 수 있으므로 목록이 달라졌다는 사실만으로 앱 오류라고 볼 수는 없습니다. 기존 항목이 교체되었다면 사용 가능한 대상을 다시 선택한 뒤 실제 연결을 확인하세요.
업데이트에 실패하더라도 기존 구독을 바로 삭제하지 마세요. 네트워크, 링크의 완전성, 서비스의 유효 여부와 반환된 콘텐츠가 여전히 인식 가능한 구독 데이터인지 확인하세요. 기존 목록으로 현재 연결은 가능할 수 있지만, 구독 주소가 아직 유효하다는 뜻은 아닙니다. 반대로 새 목록을 성공적으로 받아도 모든 서버가 사용 가능하다는 보장은 없습니다. 목록 가져오기와 서버 확인을 별도로 기록해야 자신의 서비스 제공업체에 어느 단계에서 문제가 발생했는지 정확히 설명할 수 있습니다.
백업에 포함할 자료
현재 앱에서 지원하는 내보내기 또는 백업 범위에 따라 필요한 구성 파일, 사용자 지정 규칙, 구독 출처 및 직접 추가한 정보를 저장하세요. 규칙만 내보내면 모든 서버 정보도 함께 보관된다고 가정하지 마세요. 시스템 이전으로 앱 데이터 전체가 반드시 복원된다고 가정해서도 안 됩니다. 백업 후 파일의 내용과 용도를 알아볼 수 있는지 확인하고, 기존 서비스 제공업체에서 다시 받아야 하는 정보가 무엇인지 기록하세요.
백업에는 비밀번호, 키, 전체 구독 주소 또는 다른 인증 정보가 포함될 수 있으므로 접근을 통제할 수 있는 저장 공간에 보관하세요. 도움을 요청할 때 사용할 사본은 민감한 항목을 별도로 제거해야 하며 원본 백업을 그대로 공개하면 안 됩니다. 파일 이름에는 용도와 개인 백업 날짜를 표시할 수 있지만 인증 정보를 넣지 마세요. 사본이 여러 개라면 사용 가능한지 확인한 파일을 표시해 시험 중인 구성을 잘못 복원하지 않도록 하세요.
기기 변경, 재설치 및 앱 업데이트
기기를 바꿀 때는 먼저 App Store에서 구입한 앱을 다시 받은 다음 자료를 복원하고, 새 기기에서 VPN 구성 권한 승인과 연결 확인을 진행하세요. 구입 자격, 앱 데이터 및 시스템 권한은 각각 복원 절차가 다르므로 한 항목이 완료되었다고 나머지도 끝났다고 판단할 수 없습니다. 설정값을 비교하기 위해 이전 기기를 당분간 보관할 수 있지만, 두 기기에서 같은 기존 서비스를 동시에 사용할 수 있는지는 해당 서비스의 실제 이용 조건을 따르세요.
앱 업데이트 후 동작이 달라졌다면 먼저 현재 서버, Global Routing 및 구성 파일을 확인한 다음 앱 내 안내와 App Store의 업데이트 설명을 살펴보세요. 재설치는 자료 복원 작업을 늘리고 유용한 문제 해결 단서를 잃을 수 있으므로 첫 번째 조치로 삼지 마세요. 재설치가 꼭 필요하다면 구입 계정, 사용 가능한 백업 및 필요한 인증 정보를 먼저 준비한 뒤 진행하세요.
복구 가능한 문제 해결 순서 만들기
먼저 기본 네트워크를 확인한 다음 시스템 권한과 연결 상태, 선택된 서버, 작동 모드, 현재 구성, DNS 및 규칙을 차례로 확인하세요. 단계마다 한 항목만 변경하고 테스트한 뒤 그대로 유지할지 원래대로 되돌릴지 결정합니다. 간헐적으로 발생하는 문제는 모든 작업을 반복하는 것보다 네트워크 전환, 기기 절전, 구독 업데이트 및 오류 발생 순서를 기록하는 편이 더 도움이 됩니다. 타임라인을 만들어야 문제가 특정 조건을 계속 따라다니는지 확인할 수 있습니다.
| 관리 작업 | 보존해야 할 기준 정보 | 완료 후 확인 |
|---|---|---|
| 구독 업데이트 | 출처 그룹 및 기존에 선택한 대상 | 목록 확인, 서버 다시 선택, 실제 연결 |
| 규칙 수정 | 기존 구성 및 대상 경로 | 모드가 올바르고 적용 정책이 예상과 일치함 |
| 기기 변경 | 구입 내역 및 필요한 백업 | 자료 복원, 권한 승인 완료, 정상 접속 |
| Settings 조정 | 기존 값, 변경 목적 및 테스트 조건 | 같은 테스트를 반복하고 차이 기록 |
문제를 전달해야 한다면 기기 유형, 현재 네트워크 유형, 프로토콜, 작동 방식, 오류 원문 및 재현 단계를 정리하세요. 앱 버전 정보는 개인 문제 해결 기록에 실제 표시된 내용을 그대로 적을 수 있지만, 확실하지 않은 정보를 추측해서 작성하지 마세요. 가림 처리한 주요 항목만 제공하고 전체 구독 링크, 비밀번호, 키 및 개인 접속 기록은 공개하지 마세요. 구체적인 단계를 설명할수록 문제를 정확히 판단하는 데 도움이 됩니다.
이제 전체 사용 과정에는 정품 구입, 권한 승인, 가져오기, 모드 선택, 연결 확인 및 관리 기록이 포함되어야 합니다. 조작 과정을 다시 확인하려면 빠른 시작 가이드로 돌아가세요. 구입 및 복원에 관한 질문은 App Store 정품 구입 안내의 FAQ를 확인하고, 용어 설명은 용어 빠른 확인을 이용하세요. 모든 문제를 ‘연결할 수 없음’으로 뭉뚱그리는 것보다 해당 단계에서 해결하면 지속적으로 관리하기가 쉽습니다.