Shadowrocket 완벽 사용 매뉴얼

구매 및 정식 앱 확인: 앱을 먼저 확인하고 연결 정보를 준비하세요

Shadowrocket은 Apple 플랫폼용 유료 클라이언트이며, 주 사용 기기는 iPhone과 iPad입니다. 유일한 구매처는 App Store입니다. Mac, Apple TV, Apple Vision의 호환 여부도 같은 제품 페이지에서 확인할 수 있으며, 시스템 요구 사항과 일반적인 구매 조건은 App Store 페이지에 표시된 내용을 기준으로 합니다. 이후 매뉴얼은 iPhone과 iPad를 중심으로 설명하며, 다른 기기의 화면 구성을 모바일 기기에 그대로 적용하지 않습니다. 구매하기 전에 대상 기기에서 해당 스토어 페이지를 열 수 있는지 확인하고, 호환성 및 구매 정보를 살펴보세요. 계정 문제와 연결 설정 문제를 혼동하지 않는 데 도움이 됩니다.

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

구매 가이드의 정식 앱 확인 안내에서 확인 절차를 시작하세요. 앱 이름은 Shadowrocket, 개발자는 Shadow Launch Technology Limited, 앱 ID는 932747118이어야 합니다. 아이콘이 이 사이트 페이지 상단의 공식 아이콘과 같은지도 확인하세요. 앱 이름은 첫 단계에서 식별하는 기준일 뿐입니다. 검색 결과에 비슷한 이름의 앱이 있더라도 개발자와 앱 ID를 확인해야 합니다. 제품 링크 끝부분의 id932747118에서 앱 ID를 확인할 수 있습니다. 스토어 검색 결과가 명확하지 않으면 구매 가이드의 제품 페이지 링크로 돌아가세요. 이름이 비슷하다는 이유만으로 구매를 진행하지 마세요.

상세 페이지에 들어간 뒤에는 제품 정보와 현재 계정 상태를 구분해야 합니다. 가격 버튼, 다시 다운로드 아이콘, 호환성 안내는 각각 구매, 기존 구매 기록, 현재 기기의 사용 조건을 나타냅니다. 한 항목에 문제가 있다고 해서 나머지 두 항목에도 문제가 있다고 단정할 수는 없습니다. 예를 들어 구매 기록이 있는데도 일시적으로 설치할 수 없다면, 같은 이름의 다른 제품을 찾기보다 기기와 계정 관련 안내를 먼저 확인하세요. 구매 전에 개발자와 앱 ID를 기록해 두면 다른 기기에서 확인할 때도 같은 정보를 이용할 수 있습니다.

구매 대상은 클라이언트이며 연결 서비스가 아닙니다

Shadowrocket은 1회 구매 방식이며, 미국 스토어 가격은 약 2.99달러입니다. 각 스토어에는 현지 통화로 표시되며, 실제 가격과 구매 조건은 App Store 페이지에 표시된 내용을 기준으로 합니다. 결제하면 앱 사용 권한을 얻지만, 서버 주소, 인증 정보 또는 구독 링크가 자동으로 제공되는 것은 아닙니다. 클라이언트 1회 구매 ≠ 연결 서비스 요금제. 구독 정보는 이용 중인 서비스 제공업체에서 받고, Shadowrocket에 맞는 가져오기 방식을 확인하세요. 필요한 정보가 아직 없다면 앱을 설치하고 화면을 살펴볼 수는 있지만, 서버 목록이 비어 있다는 이유로 구매에 실패했다고 판단해서는 안 됩니다.

기기 조건과 계정 조건을 따로 확인하세요

iPhone에서는 먼저 시스템 요구 사항을 확인한 다음 스토어에서 구매하고 설치하세요. iPad에서 같은 구매 계정을 사용하더라도 다시 다운로드할 수 있는지와 구매 권한의 적용 범위는 App Store 페이지에 표시된 내용을 기준으로 합니다. 두 기기의 화면 배치가 다르다는 이유로 확인되지 않은 설정을 새로 만들지 마세요. 스토어 노출 여부, 결제 수단 및 구매 기록은 모두 현재 스토어 계정 상태에 따라 달라집니다. 제품 페이지를 일시적으로 사용할 수 없다면 시스템 안내를 확인하고 현재 스토어와 계정에서 구매할 수 있는지 살펴본 뒤 다음 단계로 진행하세요. 설정을 반복해서 바꾸는 것이 모든 문제에 통하는 해결책은 아닙니다.

기기를 바꾸거나 앱을 다시 설치할 때는 먼저 App Store의 계정 및 구입 항목에서 Shadowrocket을 찾아 해당 항목을 구매한 계정인지 확인하세요. 앱을 다시 다운로드한 뒤에도 기존 서버, 구독 및 구성이 기기로 복원되었는지는 별도로 확인해야 합니다. 앱이 다시 표시된다고 해서 모든 연결 정보가 복원되었다고 가정하지 마세요. 앱을 연 다음 서버 목록, 현재 구성 및 라우팅 상태를 각각 확인하고 내용이 온전한지 살펴본 뒤 최초 연결 테스트를 진행하세요. 구매 복원 절차는 구입 항목 복원 안내를 참고하세요.

다음 장으로 넘어가기 전에 본인만 확인할 자료 목록을 준비하는 것이 좋습니다. 구독 출처, 서버 프로토콜, 인증 방식, 구성 출처, 설정이 필요한 기기를 기록하세요. 비밀번호 전체를 저장할 필요는 없으며 자료를 보관한 위치만 적어도 됩니다. 확실하지 않은 항목은 비워 두고 자료 제공업체에 확인하는 편이 흔히 쓰이는 값을 추측하는 것보다 안전합니다. 이후 가져오기, 업데이트 또는 문제 해결 시에는 이 목록으로 출처를 다시 확인하세요. 앱 설치가 완료되었다는 것은 구매 단계가 끝났다는 뜻일 뿐 연결 정보가 유효하다는 뜻은 아닙니다.

최초 실행 및 권한: VPN 구성과 Home 화면 이해하기

Shadowrocket을 처음 열면 연결 스위치를 서두르지 말고 먼저 Home 화면을 살펴보세요. Home은 연결 작업의 주요 시작점입니다. 연결 상태, Global Routing, Connectivity Test, SERVER 목록은 각각 상태 표시, 라우팅 선택, 연결 테스트 및 서버 선택을 담당합니다. 이 항목들은 서로 다른 기능입니다. 목록에 서버가 있다고 선택된 것은 아니고, 서버를 선택했다고 연결이 성립한 것도 아닙니다. 시스템에 VPN 상태가 표시되어도 모든 대상에 접근할 수 있다는 뜻은 아닙니다. 각각의 상태를 구분해 이해하면 상단 스위치만 보고 성공 여부를 판단하는 실수를 줄일 수 있습니다.

VPN 구성을 추가하도록 허용한다는 의미

처음 연결을 시도하는 등 시스템 구성을 만들어야 하는 작업을 할 때 VPN 구성을 추가할지 묻는 메시지가 표시될 수 있습니다. Shadowrocket에서 방금 시작한 작업으로 나타난 안내인지 확인한 뒤 시스템 요청에 따라 승인하세요. 기기 암호나 다른 본인 인증이 필요할 수 있습니다. 이 단계는 앱이 시스템의 네트워크 확장 기능을 사용해 관련 트래픽을 처리할 수 있게 합니다. 특정 서버를 자동으로 신뢰하도록 설정하거나 인증 정보를 대신 입력하는 절차는 아닙니다. 승인한 뒤에도 실제 통신을 위해 올바른 서버, 라우팅 및 구성이 필요합니다.

이전에 안내를 거부했다면 앱으로 돌아와 연결 작업을 다시 실행하고, 시스템에 메시지가 표시되면 그에 따라 처리하세요. 예상한 안내가 나타나지 않는다면 스위치를 연속해서 누르지 말고 시스템 설정에서 VPN 구성이 이미 있는지 먼저 확인하세요. 관리 대상 기기에서는 조직 정책에 따라 구성 생성이나 네트워크 확장 기능 사용이 제한될 수 있습니다. 이 경우 기기 관리자에게 확인하세요. 다른 목적으로 사용하는 시스템 구성을 함부로 삭제하지 마세요. 특히 업무용이나 학습용 기기에서는 용도와 복구 방법을 확인한 뒤 삭제해야 합니다.

Home 화면의 네 가지 상태 확인하기

1. 먼저 SERVER에서 사용하려는 서버가 있는지, 선택 표시가 되어 있는지 확인하세요.
2. 다음으로 Global Routing에서 현재 Config, Proxy, Direct 중 무엇을 사용하는지 확인하세요.
3. 상단 연결 스위치를 켠 뒤 앱을 바로 닫지 말고 상태가 전환되는지 확인하세요.
4. Connectivity Test를 실행한 다음 실제 요청을 하나 보내 추가로 확인하세요.

연결이 성립되지 않으면 Not Connected가 표시될 수 있습니다. 이 상태는 현재 연결 상황만 나타내며 실패 원인을 단독으로 설명하지는 않습니다. 서버 목록이 비어 있거나, 인증 정보가 잘못되었거나, 시스템 구성을 아직 승인하지 않았거나, 네트워크를 사용할 수 없는 경우 등은 각각 다른 단계에서 확인해야 합니다. 반대로 상단 상태가 바뀌었더라도 연결 기능이 작동하기 시작했다는 의미일 뿐입니다. 서버가 트래픽을 전달하는지, 도메인이 확인되는지, 규칙이 예상한 정책을 선택하는지는 따로 점검해야 합니다. 자세한 화면 안내는 최초 실행 및 Home 화면 구성 안내를 참고하세요.

그 밖의 권한은 필요한 작업에 맞춰 허용하세요

Scan QR Code를 사용하려면 카메라 권한이 필요합니다. 권한을 거부했다면 시스템 설정에서 해당 권한을 확인한 뒤 다시 스캔하세요. 직접 입력하거나 링크를 가져오기만 한다면 미리 사용해 보려는 목적으로 카메라 권한을 켤 필요는 없습니다. 파일 선택기에서 구성을 가져올 때는 선택한 파일의 출처와 내용을 확인하세요. 클립보드에서 정보를 읽을 때는 방금 복사한 연결 정보가 들어 있는지 확인하세요. 권한 안내는 앱이 어떤 시스템 리소스에 접근하려는지 알려줄 뿐, 자료의 출처를 판단해 주지는 않습니다.

최초 실행 시에는 한 번에 한 가지 작업만 진행하는 것이 좋습니다. 먼저 출처가 확실한 정보를 하나 가져오고, 목록 내용을 확인한 뒤 연결하세요. 권한 안내가 끝나기 전에 네트워크를 바꾸거나 구독을 업데이트하고 라우팅까지 변경하지 마세요. 문제가 생기면 원인을 찾기 어려워집니다. 시스템에서 다시 승인하라는 메시지가 나타나면 당시 수행한 작업과 안내 문구를 기록한 다음, 기존 VPN 구성이 현재 앱에 해당하는지 확인하세요. 연결이 한 번 실패했다는 이유만으로 앱을 삭제하면 백업하지 않은 로컬 정보가 사라질 수 있고, 권한 승인과 자료 가져오기를 다시 해야 할 수도 있습니다.

이 단계에서는 기기 자체가 인터넷에 연결되어 있는지도 확인해야 합니다. 평소 접근할 수 있는 페이지를 열어 현재 네트워크의 로그인이나 확인 절차가 필요한지 살펴보세요. 앱이 인터넷에 연결되지 않은 기기에 기본 연결을 만들어 줄 수는 없습니다. 공용 네트워크에서 로그인 페이지가 나타나면 네트워크 요구 사항을 먼저 처리한 다음 Shadowrocket을 테스트하세요. 네트워크를 제어할 수 있는 기능이 기기에 여러 개 있다면 각 기능의 역할을 파악하고 통제 가능한 조건에서 하나씩 비교하세요. 이러한 확인을 마쳐야 다음 장에서 가져오기 결과를 안정적으로 테스트할 수 있습니다.

서버 및 구독: 개별 서버 정보, Subscribe, Config 구분하기

가져오기 전에 보유한 자료가 무엇인지 먼저 확인하세요. 개별 서버 정보는 하나의 연결 종점을 설명하며 보통 프로토콜, 주소, 포트 및 인증 항목을 포함합니다. 구독 링크는 서버 목록을 가져오고 업데이트하는 데 사용됩니다. Config 구성 파일은 주로 규칙과 관련 설정을 담으며 정책 이름을 참조할 수도 있습니다. 세 자료는 링크 모양만 보고 서로 바꿔 사용할 수 없습니다. 구독 정보는 이용 중인 서비스 제공업체에서 받으세요. 형식이 명확하지 않다면 먼저 어느 항목으로 가져와야 하는지 확인한 뒤 작업하세요. 서비스 설명 페이지의 주소를 구독 주소로 사용하지 마세요.

Add Server에서 직접 추가하기

Add Server로 이동한 뒤 보유한 정보와 일치하는 프로토콜을 먼저 선택하고 해당 프로토콜에 필요한 항목을 입력하세요. 주소에는 실제 서버 도메인이나 주소를 입력하고, 포트에는 제공된 값을 그대로 입력합니다. 인증에는 Password, UUID 또는 키가 사용될 수 있으며 서로 대체할 수 없습니다. 입력기에서 공백, 전각 문장 부호 또는 줄바꿈이 추가되지 않았는지 확인하고 복사한 텍스트의 앞뒤 공백도 살펴보세요. 표시 이름은 서버를 알아보기 쉽게 지정하는 용도일 뿐 연결 매개변수가 아닙니다. 이름을 바꿔도 잘못된 주소, 인증 정보 또는 전송 설정은 수정되지 않습니다.

같은 프로토콜도 서로 다른 전송 방식을 사용할 수 있으므로 프로토콜 이름이 같다는 사실만으로 충분하지 않습니다. TLS가 필요한 연결을 예로 들면 실제 연결 주소와 인증서 확인 이름이 다를 수 있고, Host와 SNI도 각각 다른 의미를 가집니다. 오류를 해결하려고 모든 도메인 항목에 같은 값을 넣지 마세요. 자료에 특정 항목이 설명되어 있지 않다면 기본값을 유지하거나 제공업체에 확인하세요. 프로토콜에 대한 간단한 설명은 지원 프로토콜 및 매개변수 개요를 참고하세요. 실제 입력값은 본인의 서버 정보를 기준으로 해야 합니다.

Subscribe로 가져오고 업데이트하기

구독을 추가할 때는 해당 Subscribe 항목에 전체 링크를 입력해 저장한 뒤 업데이트를 실행하세요. 링크의 경로와 쿼리 부분이 인증에 사용될 수 있으므로 일부를 누락하면 오류 페이지가 표시되거나 결과가 비어 있을 수 있습니다. 주소를 짧게 만들려고 매개변수를 삭제하지 말고, 인증 정보를 공개된 문의에 붙여 넣지 마세요. 업데이트 후 SERVER로 돌아가 예상한 항목이 생성되었는지 확인한 다음 하나를 선택해 연결하세요. 구독 이름은 알아보기 쉽게 바꿔도 되지만, 나중에 업데이트할 그룹을 확인할 수 있도록 출처를 식별할 정보는 남겨 두세요.

구독 업데이트가 성공했다는 것은 이번에 내용을 가져와 해석했다는 뜻일 뿐, 모든 서버를 현재 사용할 수 있다는 보장은 아닙니다. 업데이트에 실패했다고 해서 서버 전체를 사용할 수 없는 것도 아닙니다. 현재 기본 네트워크, 링크의 완전성, 인증 유효성 및 응답 형식을 각각 확인하세요. 기존에 사용 가능한 목록이 있다면 우선 유지하고 실패 안내를 기록한 뒤 처리하세요. 구독 그룹 전체를 먼저 삭제하지 마세요. 업데이트에 따라 항목이 추가, 삭제 또는 이름 변경될 수 있으므로 업데이트 후 현재 선택된 서버가 여전히 존재하는지도 확인해야 합니다.

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

Scan QR Code는 인식 가능한 연결 정보를 가져올 때 유용하지만, QR 코드는 정보를 담는 수단일 뿐 유효성의 증거는 아닙니다. 스캔한 뒤 프로토콜과 주소를 확인하고 저장하세요. 결과가 일반 웹페이지라면 자료 출처로 돌아가 올바른 QR 코드인지 확인하세요. 클립보드나 파일에서 가져올 때도 같은 원칙을 따르세요. 성공 안내가 표시되었는지만 보지 말고 실제로 어떤 항목이 생성되었는지 확인하세요. Import from Cloud JSON과 같은 특정 항목은 보유한 자료에서 해당 기능을 사용하도록 명시한 경우에만 사용하세요. 형식이 맞지 않는 파일을 여러 항목에 반복해서 가져오지 마세요.

Config와 구독은 따로 관리해야 합니다. 서버 목록을 업데이트한다고 필요한 규칙이 자동으로 만들어지는 것은 아니며, 구성을 바꿔도 구독 업데이트를 대신할 수 없습니다. 규칙이 사용자 지정 정책 이름을 참조한다면 현재 환경에서 해당 이름을 인식할 수 있는지 확인해야 합니다. 원본 자료를 보관한 뒤 로컬에서 수정하고, 개별 서버, 구독 그룹, 구성 파일 중 어느 항목을 변경했는지 기록하세요. 이렇게 항목별로 구분하면 목록이 바뀌어도 자료를 다시 가져와야 하는지, 구독만 업데이트하면 되는지, 현재 구성만 수정하면 되는지 정확히 판단할 수 있습니다.

Global Routing: Config, Proxy, Direct와 규칙 순서

Global Routing은 현재 적용할 전체 라우팅 방식을 결정합니다. 구성은 Config, 프록시는 Proxy, 직접 연결은 Direct로 표시되며 실제 화면에는 영어 원문이 나타납니다. 세 항목은 서버 프로토콜이나 연결 속도 등급이 아닙니다. Config는 현재 구성의 규칙에 따라 처리 정책을 선택합니다. Proxy는 현재 연결에서 처리할 수 있는 요청을 선택된 프록시 정책으로 보냅니다. Direct는 직접 연결을 사용합니다. 문제를 확인하기 전에 이 항목을 먼저 확인하세요. 같은 서버를 사용하더라도 라우팅 방식에 따라 요청이 전혀 다른 경로로 처리될 수 있습니다.

라우팅 방식으로 먼저 문제 범위를 좁히세요

Proxy에서는 같은 요청이 완료되지만 Config에서 실패한다면 인증 정보를 바로 바꾸기보다 규칙 적용과 정책 참조를 먼저 확인하세요. 두 방식 모두 실패하면 기본 네트워크, 서버 및 이름 확인을 계속 점검하세요. Direct 결과는 직접 연결 경로를 비교하는 자료일 뿐 프록시 경로가 정상임을 증명하지 않습니다. 테스트가 끝나면 필요한 라우팅 방식으로 되돌리세요. 특히 한 번 진단한 뒤 임시 설정을 계속 사용하면 이후 통계와 접근 동작이 예상과 달라질 수 있습니다.

규칙은 위에서 아래로 확인합니다. 구체적인 조건을 먼저 배치하세요

규칙에서 중요한 요소는 조건, 정책 및 순서입니다. 일반적으로 위에서 아래로 일치 항목을 찾고, 먼저 일치한 규칙이 처리 방식을 결정합니다. 따라서 구체적인 예외를 포괄적인 조건보다 앞에 두고, 마지막에는 기본 처리용으로 FINAL을 배치하세요. DOMAIN은 전체 도메인과 일치하고, DOMAIN-SUFFIX는 도메인 접미사와 일치하며, DOMAIN-KEYWORD는 도메인에 포함된 키워드와 일치합니다. IP-CIDR과 IP-CIDR6은 각각 주소 범위에 사용하며 GEOIP는 주소의 위치 정보에 의존합니다. 익숙한 키워드라는 이유만으로 규칙을 복사하지 마세요. 대상 요청에서 해당 규칙이 요구하는 일치 정보를 얻을 수 있는지 확인해야 합니다.

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

이 예시는 먼저 특정 도메인 전체를 직접 연결하고, 같은 접미사에 해당하는 다른 요청은 PROXY를 사용하도록 합니다. 사설 주소 범위에는 DIRECT를 적용하고, 다음으로 GEOIP를 사용해 주소 위치를 처리한 뒤 마지막에 FINAL로 기본 처리합니다. 문법과 순서를 보여 주기 위한 예시이며 모든 네트워크에 적합한 것은 아닙니다. 특히 GEOIP 규칙은 도메인 규칙을 대체하지 않으며, 매 요청에 필요한 주소 정보가 항상 있다는 보장도 없습니다. 실제 구성에 적용하기 전에 기존 규칙, 정책 정의 및 로컬 네트워크 요구 사항을 확인하세요. 예시 전체를 기존 파일에 덮어쓰는 용도로 사용하지 마세요.

정책 이름과 화면의 라우팅 방식을 혼동하지 마세요

규칙의 PROXY, DIRECT, REJECT는 처리 정책 키워드이며 Global Routing의 Proxy, Direct와는 개념상 다른 계층에 속합니다. 구성은 정의된 정책 그룹이나 특정 이름을 참조할 수도 있으므로 철자와 참조가 일치해야 합니다. 규칙 문법이 올바르더라도 대상 정책이 존재한다고 보장할 수 없고, 정책이 존재해도 내부에서 선택한 서버를 사용할 수 있다는 보장은 없습니다. 구성을 점검할 때는 어떤 규칙과 일치했는지, 해당 규칙이 무엇을 가리키는지, 정책이 최종적으로 무엇을 선택하는지 차례로 확인하세요. 규칙 조건만 읽어서는 충분하지 않습니다.

복잡한 페이지에서는 여러 요청을 고려해야 합니다. 한 페이지가 페이지 도메인, 리소스 도메인 및 API 도메인에 동시에 접근하며 각각 다른 규칙과 일치할 수 있습니다. 페이지는 열리지만 일부 콘텐츠가 표시되지 않는다면 실패한 요청의 실제 대상부터 확인한 다음 규칙을 추가할지 판단하세요. DOMAIN-KEYWORD가 너무 포괄적이면 관련 없는 도메인에도 영향을 줄 수 있으므로 대상 범위를 정확하게 표현하는 조건을 우선 사용하세요. 규칙을 한 번에 소량씩 추가하고 로컬 예외의 용도를 간단히 기록해 두면 이후 구독이나 구성 업데이트 뒤에도 필요한 규칙인지 쉽게 확인할 수 있습니다.

구성을 가져온 뒤 현재 사용할 파일을 명확히 선택하세요. 파일을 편집했다고 해서 그 내용이 적용된 것은 아닙니다. 저장 후 구성을 사용할 수 있는지 확인하고, 이전 연결의 영향을 배제해야 한다면 다시 연결한 뒤 같은 대상으로 테스트하세요. 오랫동안 유지된 연결은 페이지를 다시 여는 것만으로 새 정책을 확인하기 어려울 수 있습니다. 테스트할 앱의 실제 동작에 맞춰 요청을 새로 보내세요. 구성 선택, 규칙 순서 및 요청 지속 시간을 함께 고려해야 규칙을 변경했는데 결과가 달라지지 않는 이유를 정확히 파악할 수 있습니다.

연결 및 확인: 서버 선택부터 실패 단계 파악까지

연결하기 전에 Home으로 돌아가 SERVER에서 예상한 서버가 실제로 선택되어 있는지 확인하세요. 해당 서버의 편집 화면에 들어간 적이 있는지만으로는 충분하지 않습니다. 이번 테스트 목적에 맞는 Global Routing인지 확인한 뒤 상단 스위치를 켜세요. 테스트를 시작하기 전에 시스템과 앱 상태가 어떻게 바뀌는지 살펴보고 연결 절차가 끝날 때까지 기다리세요. 첫 확인에서는 정보가 명확한 서버 하나와 고정된 대상 하나를 선택하세요. 구독 업데이트, 규칙 변경 및 여러 테스트를 동시에 진행하지 마세요. 반복 가능한 테스트 조건은 우연한 한 번의 성공보다 더 유용합니다.

연결 성공 여부를 세 단계로 나눠 확인하세요

첫 번째 단계는 시스템 연결 상태로, 네트워크 확장 기능이 작동하는지를 보여줍니다. 두 번째는 서버 경로로, 현재 엔드포인트가 필요한 통신을 설정할 수 있는지를 확인합니다. 세 번째는 실제 서비스 요청으로, 대상 도메인, 이름 확인, 규칙 및 대상 서비스 자체가 관여합니다. 세 단계의 결과는 서로 다를 수 있습니다. 예를 들어 시스템 상태가 정상이지만 페이지가 실패하는 것은 모순이 아닙니다. 서버 포트에 응답이 있더라도 인증이나 이후 트래픽 전달까지 성공했다는 뜻은 아닙니다. 문제를 점검할 때는 구체적으로 어느 단계에서 실패했는지 기록하세요. 모든 현상을 ‘연결 안 됨’으로 뭉뚱그리지 마세요.

Connectivity Test는 빠른 확인에 유용하지만 결과는 테스트 방식, 대상 및 현재 네트워크 조건에 따라 달라집니다. 테스트에서 나온 수치는 특정 시점의 특정 경로만 나타내므로 일상적인 접속 품질을 비교하는 절대 기준으로 사용할 수 없습니다. 먼저 테스트를 실행한 다음 대상이 분명한 실제 요청을 보내 페이지나 요청이 완전히 완료되는지 확인하세요. 테스트와 실제 결과가 다르면 어느 하나를 절대적인 결론으로 취급하지 말고 두 테스트의 대상, 프로토콜 및 정책을 비교하세요. 작업 순서는 서버 선택 및 Connectivity Test로 확인하기를 참고하세요.

기본 네트워크, 엔드포인트, 이름 확인, 규칙 순으로 점검하세요

1. 기기의 기본 네트워크를 사용할 수 있고 현재 네트워크의 로그인 또는 확인 절차가 완료되었는지 확인하세요.
2. 선택한 서버의 주소, 포트, 인증 정보 및 필요한 전송 매개변수를 확인하세요.
3. 도메인 확인이 가능한지 살펴보고 주소에 접근할 수 없는 경우와 이름 확인에 실패한 경우를 구분하세요.
4. 라우팅 방식, 현재 구성 및 실패한 요청에 적용된 실제 정책을 확인하세요.
5. 마지막으로 대상 서비스의 응답과 계정 조건을 확인하세요.

시간 초과가 발생하면 먼저 이미 보유하고 있고 사용 가능하다고 확인한 다른 서버와 비교한 다음, 제어 가능한 다른 네트워크와 비교하세요. 원인을 파악할 수 있도록 비교 중에는 대상과 구성을 그대로 유지해야 합니다. 네트워크를 바꾼 뒤 같은 엔드포인트가 다시 작동한다면 기존 네트워크의 제한, 접속 상태 또는 경로 조건을 더 살펴보세요. 모든 네트워크에서 특정 엔드포인트만 실패한다면 해당 엔드포인트 정보와 서비스 상태를 먼저 확인하세요. 근거 없이 포트, 비밀번호, TLS, DNS를 한꺼번에 바꾸지 마세요. 문제가 해결되더라도 실제 원인을 알 수 없게 됩니다.

인증 또는 TLS 관련 안내가 나타나면 원본 자료를 보며 한 글자씩 확인하세요. 인증 실패는 보통 규칙을 추가해서 해결할 수 없으며, 인증서 이름이 일치하지 않는 문제를 검증 기준을 임의로 낮춰 덮어서는 안 됩니다. 기기의 날짜와 시간이 정확한지 확인하고 SNI, 연결 도메인 및 인증서 요구 사항의 관계를 살펴본 뒤 예상 매개변수를 자료 제공업체에 문의하세요. 오류 안내가 자료 형식을 가리킨다면 같은 항목을 계속 테스트하기보다 가져온 자료를 먼저 수정하세요. 오류 문구를 그대로 기록하면 인증, 핸드셰이크 및 대상 응답 단계의 문제를 구분하는 데 도움이 됩니다.

일부 요청만 실패하면 요청 자체를 확인하세요

특정 페이지나 앱 기능 하나만 실패한다면 먼저 같은 조건에서 다른 대상은 정상인지 확인하세요. 그런 다음 실패한 대상이 추가 도메인, 다른 전송 방식 또는 지속 연결을 사용하는지 살펴보세요. 브라우저 캐시, 앱 내부 캐시 및 이전 연결이 기존 결과를 유지할 수 있습니다. 규칙을 수정한 뒤에는 요청을 새로 보내 비교하세요. 대상 서비스의 로그인 상태, 지역 설정 또는 계정 조건도 응답에 영향을 줄 수 있습니다. 이런 결과를 모두 클라이언트 문제로 볼 수는 없습니다. 실패 범위를 좁혀야 기록에 있는 정보를 쉽게 해석할 수 있습니다.

기록이 필요하다면 문제를 재현하는 데 필요한 짧은 구간만 수집하세요. 테스트 시간, 대상, 현재 서버 및 라우팅 방식을 기록한 다음 요청을 한 번 실행하고 관련 기록을 확인하세요. 공유하기 전에 구독 링크, 인증 항목, 전체 키 및 문제와 무관한 접근 정보를 삭제하세요. 오류 유형, 프로토콜 이름 및 이미 수행한 비교 테스트는 제공해도 되지만 전체 연결 정보를 공개하지 마세요. 일반적인 상태 설명과 해결 방법은 FAQ에서 확인할 수 있습니다.

확인을 마친 뒤 같은 요청을 최소 한 번 더 반복하고 업데이트 작업으로 구성이나 서버 선택이 바뀌지 않았는지 확인하세요. 장기간 사용할 환경이라면 네트워크가 바뀐 뒤의 동작도 살펴보되, 네트워크 전환 테스트를 최초 연결 테스트와 같은 과정으로 취급하지 마세요. 사용하는 네트워크, 서버, 라우팅 방식 및 성공한 대상을 간단히 기준으로 기록해 두세요. 다음에 문제가 생기면 모든 매개변수를 처음부터 다시 입력하기보다 이 기준을 재현하는 편이 더 빠르고 기존에 작동하던 설정을 망가뜨릴 가능성도 줄어듭니다.

Data 트래픽: 통계 범위를 이해하고 요청 경로 확인하기

Data는 앱에서 기록한 트래픽을 살펴보는 기능이지, 독립적인 네트워크 품질 판정이 아닙니다. 숫자를 확인하기 전에 현재 표시되는 통계 범위, 대상 및 기간을 확인하세요. 서버별로 보면 각 연결 엔드포인트가 처리하는 트래픽을 살펴볼 수 있고, 앱별로 보면 앱에 귀속되는 통신을 확인할 수 있습니다. 보기마다 귀속 방식과 포함 범위가 다를 수 있으므로 두 화면의 수치가 다르다고 해서 통계 오류라고 단정하지 마세요. 먼저 현재 보기의 레이블을 읽고 데이터를 방금 수행한 작업과 연결해 해석하세요.

업로드와 다운로드가 각각 나타내는 것

업로드는 기기에서 전송한 데이터이고 다운로드는 기기가 받은 데이터입니다. 페이지를 열 때는 보통 다운로드가 많지만 요청 헤더, 인증, 확인 및 제어 통신에도 업로드가 발생합니다. 콘텐츠를 업로드하면 업로드량이 눈에 띄게 늘 수 있습니다. 수치의 크기는 사용하는 서비스에 따라 달라지므로 한 방향의 증가가 느리다는 이유만으로 문제라고 판단해서는 안 됩니다. 연결 유지, 재시도 및 백그라운드 활동에서도 트래픽이 발생할 수 있어 화면을 사용하지 않는 동안에도 통계가 바뀔 수 있습니다. 테스트 구간을 짧게 설정해야 대상 작업으로 인한 증가분을 더 쉽게 구분할 수 있습니다.

총량과 전송 속도도 구분해서 이해해야 합니다. 누적 총량은 선택한 통계 구간의 데이터 양이고 순간 또는 단기 속도는 일정 시간 동안의 전송 변화를 나타냅니다. 이미 쌓인 총량은 현재 연결을 중단해도 자동으로 사라지지 않으므로 총량이 남아 있다는 사실만으로 연결이 계속 작동한다고 볼 수 없습니다. 반대로 잠시 속도가 표시되지 않는 것은 요청이 이미 완료되었기 때문일 수 있습니다. 한 번의 작업을 관찰할 때는 특정 시점의 수치만 보는 대신 시작 전과 끝난 후의 변화를 기록하세요.

총량을 추측에 이용하지 말고 증가분으로 확인하세요

1. 현재 서버, Global Routing 및 구성을 확인하고 관련 없는 대용량 작업은 잠시 멈추세요.
2. 대상 통계 항목의 현재 값을 기록하고 이번 관찰 범위에 포함되는지 확인하세요.
3. 반복 가능한 대상 작업을 한 번만 실행한 뒤 완료되거나 명확한 오류가 나타날 때까지 기다리세요.
4. Data로 돌아가 변화를 확인하고 요청 기록과 함께 정책을 점검하세요.

특정 서버의 통계가 증가했다면 해당 항목에 통신이 집계되었다는 뜻일 수 있지만, 모두 방금 연 페이지에서 발생했다고 볼 수는 없습니다. 백그라운드 동기화, 알림 또는 다른 앱의 활동도 동시에 일어날 수 있습니다. 증가가 없다면 요청이 DIRECT와 일치했는지, 이전 연결을 사용했는지, 캐시된 내용을 불러왔는지, 올바른 대상을 보고 있는지 확인하세요. Data는 관찰 단서를 제공하는 기능입니다. 실제 규칙 적용 여부는 현재 구성 및 관련 요청 기록과 함께 확인해야 하며, 통계 화면에 직접 나타나지 않는 의미까지 판단하도록 해서는 안 됩니다.

서버별 및 앱별 보기를 교차 확인하세요

서버별 보기는 엔드포인트를 바꾼 뒤 새로운 통신이 시작되었는지 확인하거나 더 이상 사용하지 않는 항목에 활동이 남아 있는지 점검하는 데 적합합니다. 앱별 보기는 특정 앱 작업과 함께 트래픽이 증가하는지 확인하는 데 유용하지만, 표시 방식은 현재 시스템과 앱에서 얻을 수 있는 정보에 따라 달라집니다. 정확히 귀속하기 어려운 트래픽을 특정 앱에 억지로 포함해서는 안 됩니다. 두 보기는 문제 범위를 좁히는 데 도움이 되지만 서로 정확히 일치하는 두 개의 사용 명세서로 취급해서는 안 됩니다. 집계 기준이 다르므로 수치를 단순히 더하거나 빼도 의미가 없을 수 있습니다.

Config를 사용하면 일부 요청은 규칙에 따라 직접 연결되고 일부는 PROXY를 사용하므로 서버 트래픽과 기기 전체 사용량은 보통 같은 개념이 아닙니다. 서비스 제공업체가 표시하는 사용량에도 자체 측정 기준, 정산 기간 또는 트래픽 처리 방식이 적용될 수 있습니다. 앱 통계, 시스템 네트워크 통계 및 서버 측 통계는 시작·종료 시간, 프로토콜 오버헤드 및 집계 범위가 달라 서로 다른 수치를 기록할 수 있습니다. 비교하기 전에 시간과 대상을 맞추세요. 한 번의 차이만으로 자료에 문제가 있다고 판단하지 마세요.

통계 초기화와 장기 관찰

현재 화면에 통계 초기화 기능이 있다면 실행하기 전에 영향을 받는 대상과 범위를 확인하세요. 로컬 통계를 지워도 서비스 제공업체의 사용량이 초기화되거나 서버가 삭제되지는 않으며 구독 업데이트를 대신하지도 않습니다. 과거 기록과 비교해야 한다면 새 테스트를 시작하기 전에 관련 결과를 기록하세요. 장기간 관찰할 때는 비슷한 네트워크와 같은 라우팅 방식에서 동일한 종류의 작업을 수행하는 등 조건을 일정하게 유지하세요. 조건이 크게 달라지면 모든 결과를 하나의 추세로 해석하지 말고 각각 따로 기록해야 합니다.

통계와 실제 사용 경험이 다르면 이전 장의 단계별 점검으로 돌아가세요. 트래픽이 있는데 페이지가 실패한다면 인증 이후의 대상 요청, 리소스 도메인 또는 응답 내용에 문제가 있을 수 있습니다. 페이지가 정상인데 대상 서버의 통계가 바뀌지 않는다면 직접 연결이나 캐시 때문일 수 있습니다. 통계를 즉시 지우거나 서버를 반복해서 바꾸기보다 이런 가능성을 남겨 두는 편이 낫습니다. 각 보기에 대한 자세한 설명은 Data 화면의 서버별 및 앱별 수치 안내를 참고하세요. 실제 화면에 표시된 레이블을 기준으로 읽어야 합니다.

자주 사용하는 Settings: On Demand, DNS 및 진단 기능의 범위

Settings는 필요가 분명한 항목만 조정하고 모든 스위치를 한꺼번에 켜지 마세요. 일부 설정은 시스템의 연결 시작 조건에 영향을 주고, 일부는 이름 확인이나 기록에 영향을 주며, 그 밖의 동작은 현재 Config에서 결정됩니다. 수정하기 전에 해당 설정이 현재 서버, 현재 구성 또는 앱 전체 동작 중 어디에 영향을 주는지 확인하세요. 앱이 업데이트되면 화면 구성이 달라질 수 있으므로 영어 항목 이름과 실제 설명을 기준으로 찾으세요. 현재 화면에 없는 설정을 다른 기기의 스크린샷에서 본 위치를 근거로 억지로 찾지 마세요.

On Demand: 연결을 시작하는 조건과 규칙 분기는 다릅니다

On Demand는 설정된 조건에 따라 연결을 시작하는 기능입니다. 연결을 언제 요청할지 결정하는 기능이지, 특정 도메인에 어떤 정책을 적용할지 정하는 기능은 아닙니다. 규칙 분기는 여전히 Global Routing 및 현재 구성에 따라 결정됩니다. 두 기능은 함께 사용할 수 있지만 서로 대체할 수는 없습니다. 자동 연결을 켜기 전에 수동 연결이 안정적으로 작동하는지 확인하세요. 해결되지 않은 문제를 자동 연결로 더 파악하기 어렵게 만들 수 있습니다. 자동 동작이 필요하다면 어떤 네트워크 조건에서 연결을 시작하고 어떤 조건에서 연결을 끊을지 먼저 정한 다음 하나씩 설정해 테스트하세요.

On Demand를 테스트할 때는 네트워크가 바뀌는 전체 과정을 살펴보세요. 변경 전 연결 상태를 기록하고 예상한 조건을 만든 다음 시스템이 연결을 시작하는지, 실제 요청이 성공하는지 확인하세요. 스위치가 켜져 있다는 사실만으로 조건이 올바르게 설정되었다고 판단하지 마세요. 수동으로 연결을 끊은 뒤 다시 연결되는 것은 이미 설정된 조건 때문일 수 있으며, 앱이 연결 해제를 처리하지 못한다는 뜻은 아닙니다. 자동 연결을 잠시 멈추려면 먼저 On Demand 상태와 조건을 확인한 뒤 수동으로 연결을 끊으세요. 작업을 마치면 원래 의도에 맞게 설정을 복원하세요.

On Demand
Global Routing
Config
Connectivity Test

여기에는 확인할 설정 이름만 나열되어 있으며 가져올 수 있는 구성은 제공하지 않습니다. 자동 연결을 점검할 때는 On Demand를 먼저 살펴보고, 요청 경로를 확인할 때는 Global Routing 및 Config를 확인하세요. 실제 연결 상태는 Connectivity Test와 실제 서비스 요청으로 점검해야 합니다. 항목별로 변경 내용을 기록하면 자동 재연결 문제를 규칙 수정으로 해결하려 하거나, 특정 도메인의 정책 오류를 자동 연결 해제로 처리하는 일을 막을 수 있습니다. 모든 변경은 하나의 명확한 질문에 답할 수 있어야 합니다.

DNS: 구성이 아니라 이름 확인 문제인지 먼저 판단하세요

DNS는 도메인을 이후 연결에 필요한 주소 정보로 변환하며 그 결과는 주소 기반 규칙과 연결 과정에 영향을 줄 수 있습니다. 다른 요청은 정상인데 도메인에 접근할 수 없다면 이름 확인을 점검할 수 있지만, 원인이 그것뿐이라고 단정할 수는 없습니다. 먼저 현재 구성에서 같은 도메인의 주소를 확인할 수 있는지 살펴보고 연결 오류와 함께 다음 단계를 판단하세요. 구성마다 이름 확인 관련 설정이 이미 들어 있을 수 있으므로 여러 위치를 동시에 바꾸면 어떤 설정이 적용되는지 불분명해집니다. 현재 적용 중인 구성을 확인하고 기존 설정을 기록한 뒤 한 번에 하나씩 비교하세요.

아무 이름 확인 서비스 주소나 만능 해결책처럼 사용하지 마세요. 이름 확인 경로, 서버 접근 가능성, 암호화 방식 및 규칙을 함께 고려해야 합니다. 한 네트워크에서 작동한 값이 모든 네트워크에도 적합하다는 보장은 없습니다. 수정한 뒤에는 요청을 새로 보내고 필요하다면 이전 이름 확인 결과나 연결의 영향을 배제한 다음 같은 대상을 비교하세요. 개선되지 않으면 기존 설정으로 되돌린 뒤 계속 점검하세요. 시도한 값을 계속 추가하지 마세요. 사설 네트워크의 이름 확인은 로컬 조건에 의존할 수 있으므로 변경 시 해당 요구 사항을 유지해야 합니다.

기록, 인증서 및 필요할 때 사용하는 기능

문제 해결에 필요할 때만 진단 기록을 켜고, 충분한 정보를 얻은 뒤 계속 보관할 필요가 있는지 확인하세요. 상세 기록에는 접근한 도메인, 시간 및 연결 정보가 포함될 수 있으므로 내보내거나 보내기 전에 민감한 내용을 삭제하세요. 암호화된 트래픽 처리 방식에 영향을 주는 인증서 관련 기능은 신뢰 범위, 적용 대상 및 복구 절차를 먼저 이해해야 합니다. 일반적인 서버 연결과 규칙 분기의 기본 과정에서는 설정을 완벽하게 갖추려는 이유만으로 별도의 인증서를 설치할 필요가 없습니다. 명확한 디버깅 목적이 있을 때만 사용하고 관련 앱과 서비스에서 해당 방식을 허용하는지 확인하세요.

UDP, IPv6 등의 동작을 확인할 때도 클라이언트 한쪽 설정만 바꾸지 말고 서버 프로토콜과 현재 네트워크의 지원 여부부터 점검하세요. 특정 서비스가 특정 전송 방식을 요구한다면 다른 조건을 그대로 둔 상태에서 관련 기능을 테스트할 수 있습니다. 서버가 지원하지 않는 기능을 임의의 스위치로 보완할 수는 없습니다. IPv6 주소 규칙에는 해당 유형을 사용하고 실제 이름 확인 결과와 함께 살펴보세요. 한 네트워크에서만 문제가 생긴다면 구성을 바꾸기 전에 네트워크 기능과 경로 차이를 비교하세요.

설정을 마친 뒤 Home으로 돌아가 현재 서버가 올바른지, Global Routing이 의도한 상태인지, 대상 파일이 현재 구성으로 선택되어 있는지 확인하세요. 그런 다음 일반 요청과 특별한 설정이 필요한 요청을 각각 한 번씩 테스트하세요. 이렇게 마무리하면 한 기능을 고친 뒤 임시 설정 때문에 일상 연결이 달라지는 일을 발견할 수 있습니다. 안정적인 사용에 필요한 것은 설정의 개수가 아니라, 활성화한 항목마다 분명한 목적과 검증 가능한 결과, 알려진 복구 방법이 있는지 여부입니다. 실제 필요가 없는 항목은 기존 상태로 두세요.

일상적인 관리: 업데이트, 백업, 기기 변경 및 반복 가능한 문제 해결

안정적으로 사용할 수 있게 되면 관리의 초점은 ‘어떻게 연결할까’에서 ‘변경 사항을 어떻게 추적할까’로 옮겨갑니다. 앱 업데이트, 구독 업데이트, 구성 업데이트 및 서버 선택은 서로 다른 작업이므로 각각 기록하세요. 앱은 App Store에서 업데이트하고, 구독 업데이트는 서버 정보를 가져옵니다. 구성 업데이트는 규칙이나 관련 설정을 바꾸며 서버 선택은 현재 사용하는 대상을 바꿉니다. 한 항목의 업데이트가 성공했다고 해서 나머지 내용도 모두 동기화되었다고 가정하지 마세요. 문제가 생기면 최근에 어느 항목을 변경했는지 먼저 확인하면 점검 범위를 크게 줄일 수 있습니다.

업데이트 전 기준을 기록하고 업데이트 후 항목을 확인하세요

구독을 업데이트하기 전에 현재 링크 출처와 사용 가능한 기존 항목을 확인하고, 필요하다면 현재 사용 중인 서버 이름을 기록하세요. 업데이트 후 목록에서 항목이 추가, 삭제 또는 이름 변경되었는지, 현재 선택된 항목이 예상한 대상인지 확인하세요. 목록 변경으로 사용자 지정 정책 참조가 작동하지 않는다면 앱의 데이터를 전부 다시 가져오기보다 규칙이나 정책 관계를 수정해야 할 수 있습니다. 구독 인증, 유효 기간 또는 응답 내용 문제는 서비스 제공업체에 문의하세요. 이 매뉴얼은 이미 보유한 자료를 가져오고 관리하는 방법만 안내합니다.

구성을 업데이트하기 전에 되돌릴 수 있는 사본을 보관하고 원격 내용과 로컬 수정 사항을 구분하세요. 업데이트로 덮어쓰일 수 있는 구성에 사용자 지정 규칙을 추가했다면 각 규칙의 용도와 위치를 기록하고, 업데이트 후 그대로 남아 있는지 하나씩 확인하세요. 이전 구성의 내용을 검토 없이 모두 새 파일에 다시 붙여 넣지 마세요. 더 이상 적합하지 않은 설정이 복원될 수 있습니다. 업데이트 후 기본 동작을 먼저 확인하고 필요한 로컬 예외를 소량씩 추가한 다음 각 항목을 고정된 대상으로 다시 테스트하는 것이 안전합니다.

파일 하나만 저장하지 말고 구성 간 관계까지 백업하세요

유용한 백업 기록에는 서버나 구독의 출처, 현재 구성 이름, Global Routing 방식, 필요한 로컬 규칙 및 주요 설정이 포함되어야 합니다. 구성 파일 하나만 저장해도 인증 정보가 모두 포함되는 것은 아니며, 구독 링크만 저장해도 로컬 수정 사항이나 시스템 권한 상태까지 보존되는 것은 아닙니다. 앱에서 제공하는 내보내기 또는 백업 기능을 사용할 때는 실제로 어떤 항목이 포함되는지 확인한 뒤 별도로 기록할 내용이 있는지 결정하세요. 백업 파일에는 민감한 정보가 포함될 수 있으므로 접근을 통제할 수 있고 보호 기능이 있는 위치에 보관하세요.

기기를 바꾼 뒤 파일이 없다는 사실을 알게 되지 않도록 백업이 끝나면 읽을 수 있는지 확인하세요. 파일이 존재하는지, 형식이 올바른지, 주요 항목이 모두 들어 있는지 살펴보면 됩니다. 확인을 위해 현재 사용 중인 환경을 덮어쓸 필요는 없습니다. 키, 비밀번호 및 전체 구독 주소를 공개 메모나 스크린샷에 직접 기록하지 마세요. 문제 해결 기록에는 전체 인증 정보 대신 자료 이름이나 보관 위치를 적으세요. 민감한 링크가 공개된 사실을 발견하면 자료 제공업체에 교체 또는 취소 방법을 확인한 뒤 로컬 참조도 업데이트하세요.

기기를 바꾼 뒤 구매, 가져오기, 권한, 확인 절차를 다시 진행하세요

새 기기에서는 먼저 App Store에서 Shadowrocket을 복원한 다음 백업이나 기기 복원으로 어떤 내용이 옮겨졌는지 확인하세요. 서버 목록, 구성 파일 및 시스템 VPN 승인은 각각 확인해야 합니다. 이전 기기의 시스템 상태가 그대로 이전되었다고 가정하지 마세요. 자료를 가져온 뒤 자동 동작을 복원하기 전에 수동으로 연결하고 고정된 대상을 확인하세요. iPhone과 iPad 사이의 차이는 현재 화면과 선택한 항목을 중심으로 확인하고 이전 기기에서 보던 화면 위치만 보고 기계적으로 탭하지 마세요. 시스템 요구 사항과 구매 범위는 App Store 페이지에 표시된 내용을 기준으로 합니다.

새 기기에서 확인이 끝날 때까지 기존 기기를 보관해 두면 매개변수를 비교할 수 있습니다. 단, 비교 과정에서 양쪽 기기의 자료를 잘못 변경하지 않도록 주의하세요. 새 기기가 정상 작동하는 것을 확인한 뒤 필요에 따라 기존 기기의 인증 정보, 구독 및 백업 파일을 정리하세요. 앱 재설치는 일반적인 문제 해결의 첫 단계가 되어서는 안 됩니다. 로컬 구성이 삭제되고 추가 권한 작업이 필요할 수 있습니다. 환경을 새로 구성해야 할 이유가 분명하고 자료를 복원할 수 있음을 확인한 경우에만 고려하세요. 구매 복원 문제는 구입 항목 복원 장을 참고하세요.

최소한의 문제 해결 기록 남기기

장기적인 관리를 위해 발생 시각, 네트워크 유형, 대상 요청, 서버, 라우팅 방식, 구성 이름, 원래 오류 문구 및 마지막으로 정상 작동했을 때의 변경 사항을 간단히 기록해 두세요. 방문한 페이지나 인증 정보는 기록하지 않아도 되며 조건을 재현할 수 있으면 충분합니다. 문제가 생길 때마다 알려진 기준 상태를 먼저 재현하고 최근 변경 사항과 비교하세요. 한 번에 하나씩 수정하고 성공 기준을 정한 다음 테스트 후 효과가 없는 변경은 되돌리세요. 이런 기록은 ‘여러 방법을 시도했다’는 메모보다 다시 활용하기 쉽고 같은 문제가 반복될 때도 불필요한 작업을 줄여 줍니다.

연결 절차를 빠르게 다시 진행하려면 빠른 시작 가이드를 참고하세요. 구체적인 질문은 FAQ에서 확인하고, 구매 및 앱 정보를 확인하려면 App Store 구매 가이드로 돌아가세요. 이 페이지의 장 순서는 관리 체크리스트로도 사용할 수 있습니다. 먼저 앱과 자료의 출처를 확인하고 권한과 가져오기를 점검한 다음 라우팅 및 연결을 확인하고 마지막으로 통계와 설정을 살펴보세요. 각 단계를 명확히 구분하면 반복해서 초기화하거나 추측하지 않고 확인된 사실에 따라 일상적인 설정을 조정할 수 있습니다.