Shadowrocket
사용법 완벽 가이드

01 / ACQUIRE

다운로드 및 설치: 플랫폼과 출처 확인

설정을 시작하기 전에 앱 설치와 연결 서비스 준비를 별도로 진행하세요. Shadowrocket은 클로즈드 소스 상용 앱입니다. 설치가 끝나면 기기에서 프록시 연결과 규칙을 처리할 수 있지만, 사용할 수 있는 서버가 자동으로 만들어지는 것은 아닙니다. iPhone / iPad 버전은 App Store에서 $2.99 일회성 결제이며, Mac / Windows / Android / Linux 버전은 무료입니다. 기존 구독의 유효 기간, 계정 상태와 데이터 제한은 해당 서비스에 따라 결정되며 앱을 받는 방법과는 별개입니다.

iPhone / iPad: App Store 등록 정보 확인

다운로드 페이지의 iPhone / iPad 링크를 통해 App Store로 이동한 뒤 제품명 Shadowrocket, 개발자 Shadow Launch Technology Limited, 공식 아이콘, 앱 ID 932747118을 확인하세요. 검색 결과에 표시된 이름만으로 판단하지 마세요. 이름이 비슷해도 같은 앱이라는 뜻은 아닙니다. 시스템 요구 사항은 App Store 페이지에 표시된 내용을 기준으로 확인하세요. 스토어의 호환성 안내를 오래된 문서의 시스템 정보보다 우선해야 합니다.

스토어에서 앱을 찾을 수 없다면 먼저 현재 Apple ID의 국가 또는 지역과 해당 지역에서 앱을 이용할 수 있는지 확인하세요. 중국 본토 App Store에는 이 앱이 없습니다. 기기의 표시 언어나 시스템 지역을 변경해도 구매 계정의 스토어 지역은 바뀌지 않습니다. 계정 지역을 변경하려면 계정 설정의 국가 또는 지역 변경 절차를 확인하고 잔액, 기존 구독 및 결제 수단 제한을 살펴보세요. 영향을 정확히 알기 전에 계정을 반복해서 변경하지 말고, 검색 결과에 앱이 없다는 이유로 설치 파일이 손상됐다고 판단하지 마세요.

PC와 Android: 플랫폼에 맞는 설치 파일 선택

그 외 플랫폼은 모두 전체 플랫폼 다운로드 페이지에서 받을 수 있으며, 설치 파일은 사이트의 /dl/shadowrocket/ 경로를 통해 제공됩니다. Mac에서는 먼저 ‘이 Mac에 관하여’를 열어 Apple 실리콘인지 Intel 프로세서인지 확인한 다음 해당 dmg 파일을 선택하세요. Windows에서는 페이지에 제공된 64비트 설치 파일을 선택하세요. Android에서는 arm64 설치 파일을 선택하고, 현재 브라우저나 파일 관리자에서 설치를 허용할 수 있는지 확인하세요. 파일 확장자가 비슷하다는 이유만으로 기기 아키텍처 확인을 생략하지 마세요.

PC와 Android 설치 파일에는 코드 서명이 없어 첫 실행 시 시스템이 차단할 수 있습니다. Mac에서 ‘개발자를 확인할 수 없음’이 표시되면 파일이 이 사이트에서 제공된 것이 맞는지 확인한 뒤 시스템 설정의 ‘개인정보 보호 및 보안’에서 ‘그래도 열기’를 선택하세요. Windows에서 SmartScreen 안내가 표시될 때도 출처를 먼저 확인하고 ‘자세한 정보’에서 ‘실행’ 옵션이 제공되는지 살펴보세요. 이 조치는 해당 파일에 대한 판단이며 시스템의 모든 보호 기능을 끌 필요는 없습니다. 조직에서 관리하는 기기라면 관리자 정책을 따르세요.

Mac에서 ‘손상됨’이라는 메시지가 표시되면 완료되지 않은 다운로드를 삭제하고 올바른 아키텍처의 파일을 다시 받으세요. 앱이 Applications 폴더에 있고 출처가 신뢰할 수 있음을 확인한 뒤에만 아래 명령을 사용해 해당 앱의 격리 속성을 제거하는 방법을 고려하세요. 이 명령은 시스템이 해당 앱을 격리하는 방식을 변경합니다. 출처를 알 수 없는 파일에 사용하거나 경로를 디스크 전체로 지정하지 마세요. 다른 상황은 Mac 및 Windows 설치 안내를 참고하세요.

xattr -cr /Applications/Shadowrocket.app

Linux: 배포판별 파일 형식과 실행 권한

Debian / Ubuntu에서는 일반적으로 deb 파일을 사용하고 apt로 의존성을 처리합니다. Fedora 계열에서는 rpm과 dnf를 사용합니다. AppImage는 먼저 실행 권한을 부여한 뒤 실행해야 합니다. 명령에 입력하는 로컬 파일명은 실제로 다운로드한 파일명과 일치해야 합니다. 예시만 보고 설치 파일명을 추정하지 마세요. 다운로드 불완전, 아키텍처 불일치, 실행 의존성 누락은 서로 다른 문제이므로 터미널 출력을 각각 확인해야 합니다. 자세한 내용은 Linux 설치 안내를 참고하세요.

설치가 끝난 뒤 다음 장으로 넘어가세요. 앱을 정상적으로 실행하기 전에는 자료를 한꺼번에 가져오지 마세요. 기기를 바꾸거나 앱을 다시 설치할 때 iPhone / iPad에서는 기존 구매 계정으로 구입 항목을 확인하세요. 그 외 플랫폼은 사이트에서 해당 설치 파일을 다시 받으면 됩니다. 오래된 설치 파일보다 기존 설정의 백업을 보관하는 것이 중요합니다. 서버 인증 정보, 규칙과 로컬 설정은 앱을 다시 다운로드해도 자동으로 복원되지 않습니다.

02 / PERMISSIONS

첫 실행과 권한: 확인 가능한 기준점 만들기

Shadowrocket을 처음 열면 Home에 서버가 있는지, Global Routing에서 무엇이 선택되어 있는지, 연결 스위치가 꺼져 있는지 먼저 확인하세요. 이때 Settings를 전부 바꿀 필요는 없습니다. 재현하기 쉬운 시작 조건은 시스템 네트워크로 일반 웹페이지를 열 수 있고, 앱 연결은 꺼져 있으며, 다른 VPN 설정이 작동하지 않는 상태입니다. 이렇게 시작하면 나중에 문제가 생겼을 때 기존 네트워크 문제와 앱 설정 문제를 구분할 수 있습니다.

VPN 구성 권한의 의미

iPhone / iPad에서 처음 연결할 때 시스템이 VPN 구성을 추가하도록 요청하며 기기 암호나 생체 인증을 요구할 수 있습니다. 이 권한은 앱이 시스템 네트워크 확장을 통해 해당 트래픽을 처리하도록 허용하는 것으로, 연결 서비스를 구매했다는 뜻도 모든 요청이 원격 서버를 거친다는 뜻도 아닙니다. 요청이 PROXY 또는 DIRECT 중 어느 쪽으로 처리되는지는 Global Routing과 현재 구성에 따라 달라집니다. 시스템 안내에 표시된 앱 이름을 확인한 다음 기기에서 권한을 승인하세요.

권한 요청을 거부했다면 앱으로 돌아가 연결을 다시 시도하고 시스템 안내가 표시되는지 확인하세요. 팝업이 나타나지 않으면 시스템 설정의 VPN 상태와 기기에 관리 정책이 적용되어 있는지 살펴보세요. 처음부터 모든 네트워크 설정을 삭제하지 마세요. 저장된 Wi-Fi 정보와 다른 연결 설정까지 함께 지워질 수 있습니다. 먼저 앱이 권한을 요청할 수 있는지, 구성을 저장할 수 있는지 확인한 뒤 기존 Shadowrocket VPN 구성을 제거하고 다시 승인할 필요가 있는지 판단하세요.

네트워크 확장 간의 영향 확인

기기에 다른 VPN, 기업용 네트워크 연결, 네트워크 필터 또는 시스템 관리 기능이 설치되어 있을 수 있습니다. 문제를 확인할 때는 동일한 트래픽을 처리하는 기능을 먼저 중지한 뒤 Shadowrocket만 단독으로 테스트하세요. 함께 사용할 수 있는지는 시스템 동작과 실제 구성에 따라 달라지므로 아이콘만 보고 판단할 수 없습니다. 기업 구성이나 프로파일을 삭제하면 업무 네트워크에 영향을 줄 수 있습니다. 관리 대상 기기에서는 관리자에게 먼저 문의하고, 테스트를 위해 조직 정책을 직접 제거하지 마세요.

시스템 상태 표시줄에 VPN 표시가 있어도 해당 터널 상태가 존재한다는 뜻일 뿐 서버 인증, DNS, 대상 웹사이트와 규칙이 모두 정상이라는 의미는 아닙니다. 반대로 홈 화면에서 앱이 보이지 않는다고 연결이 종료된 것도 아닙니다. 단일 아이콘만으로 연결 성공을 판단하지 말고 Home의 연결 상태와 이후 실제 요청 기록을 함께 확인하세요.

카메라, 사진 및 로컬 네트워크 권한은 필요할 때 설정

Scan QR Code를 사용할 때 카메라 권한은 QR 코드를 읽는 데 필요합니다. 이미지에서 정보를 가져오는 경우 사진 접근 권한도 필요할 수 있습니다. 해당 가져오기 방식을 사용할 때만 권한을 설정하세요. QR 코드를 사용하지 않아도 Add Server에서 직접 입력할 수 있습니다. 사진 접근을 허용할 때는 가져오기에 필요한 범위만 선택하세요. QR 코드에는 전체 인증 정보가 포함될 수 있으므로 사진 앱에 저장하거나 다른 사람과 공유할 때 주의해야 합니다.

시스템에서 로컬 네트워크 접근을 요청하면 LAN 기기나 관련 네트워크 기능에 실제로 접근해야 하는지 먼저 확인하세요. 권한과 라우팅 정책은 서로 다른 계층입니다. 로컬 네트워크 접근을 허용해도 모든 LAN 주소가 자동으로 DIRECT를 사용하지는 않으며, 규칙이 올바르더라도 운영체제가 명시적으로 거부한 권한을 우회할 수는 없습니다. LAN 기기에 접근할 수 없다면 권한, IP 주소, 서브넷, 현재 Wi-Fi의 클라이언트 격리 설정을 각각 확인하세요.

기본 네트워크 상태를 기록하고 한 번에 하나씩 변경

처음 설정하기 전에 현재 Wi-Fi 또는 셀룰러 네트워크 중 무엇을 사용하는지, 웹 인증이 필요한지, 일반 웹페이지가 바로 열리는지 기록해 두세요. 공용 Wi-Fi의 인증 페이지는 보통 앱 연결 전에 완료해야 합니다. 그렇지 않으면 무선 네트워크에 연결된 것처럼 보여도 인터넷에 접속할 수 없습니다. 셀룰러 네트워크에서는 시스템이 앱의 네트워크 접근을 제한하는지, 현재 데이터 연결이 실제로 작동하는지도 확인하세요.

처음 연결에 성공할 때까지 On Demand를 끄고 복잡한 DNS나 고급 설정은 변경하지 않는 것이 좋습니다. 한 번에 한 가지 문제만 처리하세요. 먼저 앱의 시스템 권한을 승인하고, 유효성이 확인된 자료를 가져온 뒤 연결 테스트를 진행합니다. 앱이 백그라운드에 들어간 뒤 상태가 바뀌면 그때의 네트워크 전환과 시스템 안내를 기록하고 유지 관리 장에서 원인을 확인하세요. 여러 스위치를 한꺼번에 바꾸면 새로운 변수가 생깁니다.

이 장을 마쳤을 때 앱이 정상적으로 열리고, 시스템에서 VPN 구성을 추가할 수 있으며, 기본 네트워크가 작동하고, 연결을 직접 끄는 방법을 알고 있어야 합니다. 권한이 계속 차단된다면 FAQ의 ‘플랫폼별 설치 및 첫 실행’ 항목에서 확인하세요. 권한 문제가 해결되기 전에 규칙을 디버깅하지 마세요. 증상은 비슷해도 해결 방법은 전혀 다를 수 있습니다.

03 / CONNECTION MATERIAL

서버 및 Subscribe 추가: 정보 종류 구분

이 장은 이미 본인 소유의 구독 정보나 서버 정보를 가지고 있다는 전제로 설명합니다. 받은 정보가 단일 서버 매개변수인지, 단일 공유 링크인지, QR 코드인지, 서버 목록을 갱신하는 Subscribe 주소인지 먼저 구분하세요. 모두 텍스트로 표시될 수 있지만 용도는 다릅니다. 구독 주소를 서버 주소 입력란에 넣거나 전체 공유 링크를 비밀번호로 입력해도, URL처럼 보인다는 이유로 올바른 구성으로 자동 변환되지는 않습니다.

Add Server: 기존 매개변수에 맞춰 입력

직접 추가하려면 Home의 추가 메뉴에서 Add Server로 이동해 서버와 동일한 프로토콜을 선택한 뒤 주소와 포트를 입력하세요. 주소에는 호스트 이름이나 IP를 입력하며 웹 경로를 임의로 덧붙이지 마세요. 포트는 서버에서 제공한 값을 사용해야 합니다. 메모는 기기에서 항목을 구분하기 위한 것으로 인증에 사용되지 않습니다. 비밀번호, UUID, 키 등의 인증 정보는 원문 그대로 입력하고 복사할 때 공백, 줄바꿈, 한글 문장 부호가 추가되지 않았는지 확인하세요.

프로토콜 이름을 맞추는 것은 첫 단계일 뿐입니다. 같은 프로토콜도 전송 방식, TLS, SNI, 경로가 다를 수 있으므로 ‘서버가 응답한다’는 이유로 해당 필드를 생략하지 마세요. SNI는 TLS 핸드셰이크에서 사용하는 이름이며 임의의 메모를 넣는 칸이 아닙니다. WebSocket의 path와 Host에도 각각 정해진 용도가 있습니다. 해당 매개변수를 받지 못했다면 기존 서비스 정보를 확인하세요. 필드 오류를 가리기 위해 인증서 검사를 끄지 마세요.

공유 링크와 QR 코드: 가져온 뒤에도 확인

클립보드 가져오기나 Scan QR Code를 사용하면 직접 입력할 때 생기는 오류를 줄일 수 있지만, 가져오기에 성공했다는 것은 앱이 정보를 해석할 수 있다는 뜻일 뿐 원격 서비스가 여전히 유효하다는 증거는 아닙니다. 가져온 뒤 항목 상세 정보에서 프로토콜, 서버 주소와 포트가 원본 정보와 일치하는지 확인하세요. QR 코드가 압축되었거나 가려져 있거나 여러 내용을 포함하면 읽지 못할 수 있습니다. 이때는 같은 흐릿한 이미지를 반복해서 스캔하지 말고 선명한 원본을 다시 받거나 원문 텍스트를 사용하세요.

스캔 결과가 구독 주소라면 개별 서버가 아니라 Subscribe로 저장하세요. 스캔 메뉴와 입력란의 위치는 화면 변경에 따라 달라질 수 있지만, 판단 기준은 언제나 정보의 내용입니다. 인증 정보가 포함된 QR 코드를 공개 인식 서비스에 업로드하거나 전체 공유 링크를 공개 피드백에 붙여 넣지 마세요. 문제를 설명할 때는 프로토콜과 필드 이름만 언급하고 인증 정보는 숨기세요.

Subscribe: 서버 목록을 업데이트

기존 Subscribe를 추가할 때는 서비스에서 받은 전체 주소를 입력하고 저장한 뒤 업데이트를 실행해 결과를 확인하세요. 주소의 경로와 쿼리 매개변수가 인증에 사용될 수 있으므로 끝부분을 삭제하면 요청이 실패할 수 있습니다. 업데이트 결과가 비어 있음, 인증 실패, 형식 해석 불가, 네트워크 시간 초과는 서로 다른 문제입니다. 먼저 주소가 온전하고 여전히 유효한지 확인하고, 기본 네트워크에서 해당 주소에 접속할 수 있는지 살펴본 뒤, 콘텐츠가 앱에서 인식할 수 있는 구독 형식인지 확인하세요.

첫 업데이트 후 목록에 표시된 그룹 이름과 알아보기 쉬운 서버 메모를 기록하세요. 구독 업데이트로 항목이 추가, 삭제 또는 이름 변경될 수 있으므로 업데이트 후 달라진 내용을 모두 앱 오류로 보지 마세요. 구독에서 생성된 서버를 직접 수정하면 다음 업데이트에서 변경 사항이 덮어쓰여질 수 있습니다. 매개변수를 고정해야 한다면 이름을 명확히 지정한 별도 항목을 만들고 기존 구독을 유지하세요. 비슷한 정보가 섞여 현재 선택 항목을 구분하기 어려워지는 일을 방지할 수 있습니다.

서버, 구독, Config는 서로 다른 계층

서버 항목은 연결할 대상을 설명하고, Subscribe는 여러 항목의 출처를 관리하며, Config는 트래픽이 규칙과 정책에 어떻게 매칭되는지 결정합니다. 서버를 추가해도 모든 상황에 맞는 규칙이 자동으로 만들어지지는 않습니다. Config를 다운로드해도 사용할 수 있는 서버 인증 정보가 포함되어 있지 않을 수 있습니다. 가져온 뒤 Home에서 서버 선택을 확인하고 Config에서 현재 구성을 따로 확인하세요. 어느 한 목록에 내용이 있다는 이유만으로 준비가 모두 끝났다고 판단하지 마세요.

최종적으로는 유효한 연결 정보, 현재 서버를 알아볼 수 있는 항목, 용도를 알고 있는 Config로 구성된 단순한 최소 집합을 마련하세요. 비슷한 구독이나 Config를 연달아 가져오지 마세요. 중복 내용이 많으면 잘못된 항목을 선택하기 쉬워지고 문제가 생겼을 때 정보의 출처를 파악하기도 어려워집니다. 처음 가져오기만 완료하면 된다면 빠른 시작으로 돌아가 기본 순서에 따라 진행하고, 필드 확인과 업데이트 동작은 이 장을 참고하세요.

04 / GLOBAL ROUTING

Global Routing: 세 가지 트래픽 처리 방식 이해

Global Routing은 앱이 트래픽을 처리하는 기본 방식을 결정합니다. 구성, 프록시, 직접 연결은 화면의 Config, Proxy, Direct에 해당합니다. 이는 서버나 서비스 등급이 세 가지라는 뜻이 아닙니다. 이 선택을 바꾸면 요청이 규칙을 따르는지, 프록시를 사용하는지가 달라집니다. 규칙을 조정하기 전에 현재 방식을 확인하세요. 같은 Config라도 방식에 따라 다르게 동작하므로 규칙이 적용되지 않는 것처럼 보일 수 있습니다.

Config, Proxy, Direct의 차이

세밀한 트래픽 분기에 Config를 주로 사용합니다. 규칙의 PROXY는 일반적으로 Config에서 정의했거나 앱에서 현재 사용하는 프록시 정책을 가리키고, DIRECT는 직접 연결, REJECT는 매칭된 요청을 거부합니다. 규칙에 적힌 정책 이름은 실제 Config에서 정의된 정책과 연결되어야 합니다. 임의의 메모를 유효한 정책으로 사용할 수는 없습니다. Proxy를 선택하면 규칙 매칭의 영향을 확인할 수 있지만 비밀번호, TLS 또는 원격 서비스 문제를 해결해 주지는 않습니다.

Direct도 앱 연결을 완전히 끈 상태에서의 기준 테스트를 대신할 수는 없습니다. 앱이 DNS 등의 네트워크 처리에 계속 관여할 수 있기 때문입니다. 시스템 네트워크 자체의 문제인지 확인하려면 먼저 연결을 완전히 끊고 동일한 대상에 접속하세요. 비교할 때는 같은 네트워크와 URL을 사용하고 테스트 시간도 비슷하게 맞추세요. Wi-Fi를 바꾸면서 처리 방식까지 변경하면 결과를 일으킨 요인이 무엇인지 알기 어렵습니다.

규칙은 위에서 아래로 확인하며, 먼저 매칭된 규칙이 적용됩니다

규칙 파일의 순서는 실제 동작에 영향을 줍니다. 대체로 더 구체적인 도메인 조건을 넓은 조건보다 앞에 두고, FINAL은 마지막에 기본 처리 규칙으로 배치합니다. 아래 예시는 문법과 순서를 보여 줍니다. 지정한 도메인 접미사는 PROXY, LAN 주소는 직접 연결, GEOIP,CN에 해당하는 주소는 직접 연결하고 나머지는 PROXY로 처리합니다. 모든 네트워크에 적용할 수 있는 완성된 Config는 아니므로 실제 사용 시 서버와 정책 정의를 확인하세요.

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

DOMAIN은 특정 도메인 하나와 매칭됩니다. DOMAIN-SUFFIX는 해당 도메인과 하위 도메인에 사용됩니다. DOMAIN-KEYWORD는 도메인에 포함된 키워드로 매칭하므로 범위가 더 넓고 의도하지 않은 사이트까지 포함할 수 있습니다. IP-CIDR과 IP-CIDR6은 주소 대역에 사용합니다. GEOIP는 웹페이지 언어나 사이트 브랜드가 아니라 IP 주소의 지역 정보에 의존합니다. 규칙 유형을 선택할 때는 가장 짧아 보이는 표현을 고르기보다 ‘확인할 수 있는 정보가 도메인인가, 주소인가?’를 먼저 생각하세요.

도메인 규칙, DNS 조회, 연결 기록을 함께 확인

하나의 페이지가 여러 도메인에서 콘텐츠를 불러올 수 있습니다. 본문, 이미지, 로그인, API가 반드시 같은 호스트를 사용하는 것은 아닙니다. 홈페이지 도메인에만 규칙을 추가해도 일부 리소스가 다른 정책을 사용하는 것은 흔한 일입니다. 현재 요청 기록에서 불러오지 못한 리소스의 대상을 확인한 다음 정확한 규칙을 추가할지 결정하세요. 넓은 키워드 규칙 하나로 페이지 전체를 처리하면 수정은 간단하지만 관련 없는 도메인까지 프록시를 사용할 수 있습니다.

주소 규칙은 매칭에 DNS 조회 결과가 필요할 수 있습니다. 예시의 no-resolve는 해당 주소 규칙이 도메인 조회를 직접 유발하지 않도록 제한하는 데 쓰이며, 모든 DNS를 끄는 설정은 아닙니다. DNS 캐시, 앱이 기존 연결을 재사용하는 동작, 대상이 여러 주소를 사용하는 경우가 모두 결과 확인에 영향을 줄 수 있습니다. 규칙을 변경한 뒤에는 테스트 요청을 새로 보내고, 필요하면 대상 앱을 완전히 종료한 뒤 다시 열어 변경 전 연결로 변경 후 Config를 판단하지 않도록 하세요.

‘일부 웹사이트는 PROXY, 나머지는 DIRECT’를 원한다면 지정한 도메인 조건을 앞에 두고 마지막 규칙으로 FINAL,DIRECT를 사용하세요. 이는 위의 기본 처리 예시와 방향이 반대이므로 두 종류의 마지막 규칙을 함께 그대로 복사하지 마세요. 전체 예시는 DOMAIN-SUFFIX 및 FINAL 규칙 작성법을 참고하세요. Config를 저장한 뒤 작동이 확인된 이전 사본을 보관하세요. 잘못 매칭되면 먼저 이전 사본으로 되돌린 뒤 조건을 하나씩 좁히세요.

05 / VERIFICATION

연결 및 확인: 시스템 상태부터 실제 요청까지

서버 정보와 라우팅 방식을 정한 다음 처음 연결을 시도하세요. 먼저 Home에서 알아볼 수 있는 서버를 선택하고 Global Routing이 테스트 대상에 적합한지 확인한 뒤 연결 스위치를 켭니다. 처음 연결할 때는 시스템 안내에 따라 권한을 승인하세요. 스위치가 바뀌자마자 실패로 판단하지 마세요. 연결과 첫 요청이 처리될 시간을 두고 앱에 명확한 오류가 표시되는지 확인하세요. 계속 스위치를 켰다 껐다 하면 재연결만 반복될 수 있습니다.

세 단계로 나눠 확인

첫 번째는 시스템에서 VPN 구성이 정상적으로 시작됐는지, 두 번째는 앱이 선택한 서버와 유효하게 통신하는지, 세 번째는 대상 웹사이트의 실제 요청이 예상대로 완료되는지 확인하는 것입니다. 앞 단계의 성공이 다음 단계까지 보장하지는 않습니다. VPN 상태가 표시되는데 웹페이지가 열리지 않으면 인증, DNS, TLS, 원격 서버 출구 또는 규칙 문제일 수 있습니다. 연결 스위치가 곧바로 꺼진다면 시스템 권한, Config 로드 여부와 앱에 표시된 오류부터 확인하세요.

테스트할 때는 반복해서 접속할 수 있는 익숙한 일반 웹페이지 하나를 선택한 뒤 현재 규칙에서 PROXY를 사용해야 하는 대상을 테스트하세요. Config를 사용하는 경우 예상대로 DIRECT로 처리되는 대상도 확인해 모든 요청이 같은 정책으로 처리되지 않는지 살펴보세요. 이전에 열었던 페이지는 캐시에서 표시될 수 있으므로 새로고침하고 새 요청을 확인하세요. 캐시된 제목이나 이미지만 보이는 것은 현재 네트워크가 연결되었다는 증거가 아닙니다.

Connectivity Test로 확인할 수 있는 내용

Connectivity Test 결과는 실제 테스트 방식에 따라 달라집니다. 응답을 받았다면 해당 테스트 요청에서 그때 응답이 있었다는 뜻일 수 있지만, 모든 프로토콜 기능이나 대상 사이트, 장시간 전송이 정상이라는 의미는 아닙니다. 지연 시간이 짧다고 처리량이 높은 것도 아닙니다. 연결 대역폭, 혼잡도, 원격 서버 부하와 앱이 사용하는 구체적인 경로가 모두 사용 경험에 영향을 줄 수 있습니다. 서로 다른 테스트 방식에서 얻은 수치를 직접 비교해 순위를 매기지 마세요.

본인이 이미 보유한 서버 중 몇 개만 골라 동일한 방식으로 반복 테스트한 뒤 실제 필요한 웹사이트를 열어 확인하세요. 항목 테스트는 실패했는데 웹페이지는 정상이라면 테스트 대상과 방식에 제한이 있는지 점검하세요. 테스트는 성공했지만 웹페이지가 실패한다면 DNS, 규칙과 대상 사이트를 확인하세요. 수치 해석의 범위는 지연 시간 테스트와 서버 선택 안내를 참고하세요. 단일 수치만을 기준으로 판단하지 마세요.

오류가 발생한 계층부터 단계적으로 확인

모든 대상에서 실패하면 먼저 앱 연결을 끊고 기본 네트워크가 작동하는지 확인한 다음 서버 주소, 포트와 인증 정보를 살펴보세요. TLS 오류가 발생하면 인증서를 건너뛰지 말고 시스템 시간, 인증서의 이름과 SNI를 확인하세요. UDP에 의존하는 프로토콜을 사용한다면 현재 네트워크에서 UDP를 사용할 수 있는지도 고려해야 합니다. 한 네트워크에서 실패했다고 정보가 잘못됐다고 단정할 수는 없습니다. 허용되는 다른 네트워크에서 동일한 매개변수를 유지해 비교하세요.

웹사이트 하나에서만 문제가 발생하면 해당 대상의 규칙과 요청 결과부터 확인하세요. Config 전체를 먼저 바꾸지 마세요. 웹사이트 서버 오류, 계정 로그인 제한, 지역별 콘텐츠 차이가 앱 연결 실패를 뜻하지는 않습니다. ‘연결을 설정할 수 없음’, ‘요청 시간 초과’, ‘웹사이트에서 거부 응답을 받음’을 나눠 기록하세요. 각 증상은 서로 다른 점검 방향을 가리킵니다.

네트워크 전환 후 다시 테스트

Wi-Fi에서 셀룰러로 전환하면 기존 연결을 다시 설정해야 할 수 있으며 진행 중인 요청이 중단될 수도 있습니다. 시스템 네트워크가 안정될 때까지 기다렸다가 대상을 새로고침하세요. 그래도 실패하면 연결을 한 번 수동으로 끊었다가 다시 연결한 뒤 확인하세요. 네트워크를 바꾼 직후 서버, 규칙과 DNS를 동시에 수정하면 복구에 영향을 준 조치를 알기 어렵고 문제도 재현하기 힘듭니다.

유효한 검증 결과는 다음처럼 설명할 수 있어야 합니다. 특정 네트워크에서 특정 서버와 Global Routing 방식을 사용했고, 대상에서 새 요청을 보내 예상한 정책으로 응답을 받았습니다. 이렇게 기록하는 것이 단순히 ‘작동함’이라고 적는 것보다 유용합니다. 문제를 찾지 못했다면 FAQ에서 증상별로 확인하세요. 민감한 정보를 가린 오류 문구, 네트워크 유형과 재현 절차를 준비하되 구독 주소나 전체 서버 인증 정보를 공개하지 마세요.

06 / DATA

Data: 트래픽 및 요청 기록으로 증상 파악

Data는 앱이 처리한 트래픽과 연결을 확인하는 기능이며 서버 측 사용량 내역을 대신하지 않습니다. Data를 열면 현재 화면에 실시간 연결, 요청 기록, 집계 데이터 중 무엇이 표시되는지와 통계 범위를 먼저 살펴보세요. 업로드, 다운로드, 연결 수와 요청 지속 시간은 서로 다른 지표입니다. 단위와 범위를 확인하지 않으면 일정 시간 동안 누적된 값을 현재 속도로 오해하기 쉽습니다.

앱 통계와 구독 사용량은 다를 수 있음

로컬 통계는 재연결, 기록 삭제, 앱 재시작 및 통계 시작 시점에 영향을 받을 수 있습니다. 서버는 자체 주기와 과금 기준으로 기록합니다. 프로토콜 오버헤드, 연결 재시도, 같은 서비스를 사용하는 다른 기기 때문에 두 수치가 정확히 일치하지 않을 수도 있습니다. 따라서 로컬 다운로드량만으로 구독 잔여 데이터를 추정할 수 없습니다. 남은 사용량은 원래 서비스에서 제공하는 기록을 확인하고, 앱 통계는 이 기기의 동작을 파악하는 데 활용하세요.

업로드와 다운로드는 보통 기기를 기준으로 합니다. 기기에서 외부로 보내는 데이터가 업로드이고, 받는 콘텐츠가 다운로드입니다. 웹페이지를 열 때도 다운로드만 발생하는 것은 아닙니다. DNS, TLS 핸드셰이크, 요청 헤더와 확인 데이터도 업로드량을 만듭니다. 동영상 재생에는 미리 가져온 캐시 데이터가 포함될 수 있습니다. 페이지에서 동작을 멈춘 뒤에도 소량의 트래픽이 발생한다면 곧바로 오류로 판단하지 말고 백그라운드 앱, 동기화 또는 지속 연결이 있는지 확인하세요.

대상, 정책, 결과를 연결해 근거 확인

규칙 문제를 확인할 때는 기록에서 방금 보낸 요청을 찾고, 확인 가능한 대상 도메인이나 주소, 매칭 규칙, 최종 정책 및 연결 결과를 살펴보세요. 화면에 따라 제공되는 필드가 다를 수 있으므로 현재 기록에 실제로 표시된 내용을 기준으로 판단하세요. 대상 필드에 IP가 표시된다고 웹사이트에 도메인이 없다는 뜻은 아닙니다. 앱이 IP 주소를 직접 사용하거나 캐시된 연결을 재사용했거나, 앱에서 관찰할 수 있는 단계에 도메인 정보가 남지 않았을 수 있습니다.

일반적으로 웹페이지 하나에는 여러 연결이 포함됩니다. 맨 위 항목 하나만 보고 사이트 전체 정책을 판단하지 마세요. 테스트하기 전에 관련 없는 앱을 닫고 시작 시간을 기록한 뒤 대상 페이지를 한 번만 새로고침하세요. 기록을 지워야 한다면 주요 증상을 먼저 저장하세요. 기록 삭제는 확인하기 쉬운 환경을 만들 뿐 서버나 DNS 문제를 자동으로 고치지는 않습니다. 기록 수가 줄어들면 실패한 리소스가 메인 페이지와 다른 도메인 및 정책을 사용하는지 확인하세요.

자주 보이는 증상 해석

같은 도메인에 여러 주소가 표시되면 로드 밸런싱, 서로 다른 DNS 응답 또는 여러 리소스 연결 때문일 수 있습니다. 이를 즉시 모든 IP를 고정하는 규칙으로 만들지 마세요. 서비스 변경으로 고정 주소가 작동하지 않을 수 있고, 같은 주소를 공유하는 다른 사이트에 영향을 줄 수도 있습니다. 대상을 정확히 설명할 수 있는 도메인 규칙을 우선 사용하세요. IP-CIDR은 주소 대역의 용도를 명확히 이해한 경우에만 사용하고, 변경 후 매칭 결과를 다시 확인하세요.

연결이 오래 유지되지만 트래픽이 적다면 이벤트를 기다리는 장시간 연결일 수 있습니다. 트래픽이 갑자기 늘었다면 시스템 동기화나 앱의 사전 로딩 때문일 수 있습니다. 연결 지속 시간이나 총량만으로 이상 여부를 판단하지 말고 연결을 시작한 앱, 대상 및 작업 시간을 함께 확인하세요. 특정 앱을 닫았을 때 현상이 사라지고 다시 열면 재현된다면 규칙을 무작정 삭제하는 것보다 원인을 좁히는 데 도움이 됩니다.

시간 초과 기록은 해당 요청이 정해진 대기 시간 안에 완료되지 않았다는 뜻이지만 원인은 로컬 네트워크, 서버, 대상 사이트 또는 응답 경로일 수 있습니다. 인증 오류, DNS 조회 실패, 시간 초과도 서로 구분해야 합니다. 앞 장의 단계별 방법을 사용해 기본 네트워크부터 확인한 뒤 매개변수는 유지한 채 다른 서버나 네트워크와 비교하세요. Data는 증상을 파악하는 근거를 제공할 뿐 어느 쪽에 문제가 있는지 자동으로 판단하지는 않습니다.

기록에 포함된 개인정보와 공유 범위

요청 기록에는 접속 도메인, LAN 주소, 사용 시간과 앱 동작이 드러날 수 있습니다. 공유하기 전에 문제와 직접 관련된 부분만 남기고 구독 주소, 인증 정보와 개인적인 대상을 숨기세요. 비밀번호가 보이지 않아도 전체 접속 기록은 민감한 정보일 수 있습니다. 도움을 요청하려고 기록 전체를 내보내지 마세요. 보통 대상 유형, 정책, 오류 문구와 재현 절차만으로도 점검을 시작할 수 있습니다.

로그나 상세 기록은 수가 많아질수록 저장 및 처리 자원을 더 많이 사용합니다. 문제 해결을 마치면 일상적으로 사용하기에 적합한 기록 수준으로 되돌리고 현재 화면에서 제공하는 방법으로 불필요한 기록을 정리하세요. 변경 결과를 비교하려면 정리 전에 두 테스트의 조건을 기록해 두세요. 그렇지 않으면 나중에 통계 수치가 작아졌다는 이유만으로 새 Config가 더 효과적이었다고 증명할 수 없습니다.

이 장의 목적은 모든 요청을 일일이 확인하는 것이 아니라 문제가 생겼을 때 재현 가능한 근거를 몇 가지 추려내는 것입니다. ‘명확한 요청 보내기—해당 기록 찾기—정책과 결과 설명하기’를 완료하면 평소 사용으로 돌아가도 됩니다. 대상이 PROXY를 사용해야 하는데 DIRECT와 매칭되면 Global Routing 장으로 돌아가세요. 정책은 올바른데 요청이 실패한다면 연결 확인 장을 참고하세요.

07 / SETTINGS

Settings: 문제에 맞춰 조정하고 일괄 적용하지 않기

Settings의 옵션은 적용 범위가 서로 다릅니다. 앱 환경설정, 네트워크 동작을 바꾸는 설정, Config 파일에도 지정될 수 있는 설정이 있습니다. 변경하기 전에 기존 값을 기록하고 현재 활성화된 Config와 해당 설정이 Config에서 덮어쓰이는지 확인하세요. 다른 사람의 설정 화면을 보편적인 정답으로 받아들이지 마세요. 네트워크 환경, 서버 매개변수와 규칙 대상이 다르면 같은 스위치 조합도 반대 결과를 낼 수 있습니다.

DNS: 어디에서 조회하는지 먼저 확인

DNS는 도메인 이름을 IP 주소로 변환하며 조회 결과는 이후 연결과 주소 규칙에 영향을 줍니다. 문제를 확인할 때는 ‘도메인에서 사용할 수 있는 결과를 받지 못함’과 ‘주소를 받은 뒤 연결 실패’를 구분하세요. IP를 직접 사용한 테스트는 성공하고 도메인 요청만 실패한다면 DNS 조회 경로를 점검할 이유가 있습니다. HTTPS 인증서의 도메인 이름 요구 사항도 고려해야 합니다. 임의의 IP에 접속한 결과를 원래 웹사이트에 접속한 결과와 같다고 볼 수는 없습니다.

로컬에서 수행하는 DNS 조회와 프록시를 통해 조회 서비스에 접근하는 방식은 경로가 다릅니다. 현재 Config와 설정에 따라 어떤 방식을 사용하는지 확인하세요. DNS를 변경한 뒤에는 새 요청을 보내고 캐시와 기존 연결을 고려해야 합니다. 많은 DNS 서버 주소를 한꺼번에 추가한다고 문제가 자동으로 해결되지는 않습니다. 각 주소의 용도와 네트워크 접근 가능 여부, 설정 문법을 확인한 뒤 원인을 설명할 수 있는 최소한의 변경만 유지하세요.

암호화 DNS는 해당 DNS 조회 경로를 보호할 뿐 모든 앱 연결이 프록시를 사용하게 만들거나 대상 연결의 TLS 보호를 대신하지 않습니다. LAN의 내부 도메인은 현재 네트워크가 제공하는 DNS에 의존할 수 있으므로 외부 DNS로 바꾸면 내부 리소스에 접근하지 못할 수 있습니다. 회사, 학교, 가정용 저장 장치 환경에서는 내부 도메인과 일반 웹사이트를 각각 확인하세요. 공용 인터넷 사이트 하나만 테스트해서는 충분하지 않습니다.

On Demand: 자동 연결과 라우팅을 구분

On Demand는 조건에 따라 연결 동작을 자동으로 실행하며, Global Routing은 연결 후 요청을 처리하는 방식을 정합니다. 자동 연결을 설정해도 트래픽 분기 규칙이 만들어지지는 않으며, 규칙을 끄더라도 On Demand가 꺼지는 것은 아닙니다. 처음 사용할 때는 수동 연결을 확인한 다음 지정한 Wi-Fi 환경에 적용하는 것처럼 이해하기 쉬운 조건 하나를 추가하세요. 여러 조건을 동시에 설정한 뒤 어떤 조건이 작동했는지 추측하지 마세요.

수동으로 연결을 끊은 뒤 다시 자동 연결되면 앱을 바로 재설치하지 말고 먼저 On Demand와 시스템의 관련 자동 연결 상태를 확인하세요. 네트워크 조건이 여러 개라면 조건의 적용 범위와 순서를 각각 살펴보세요. Wi-Fi 이름은 현재 네트워크와 일치해야 하며 셀룰러 조건은 실제로 전환한 뒤 확인해야 합니다. 예시는 On Demand 조건별 연결 설정을 참고하세요.

TLS, UDP, IPv6 설정의 적용 범위

TLS 문제는 시스템 시간, SNI, 서버 인증서와 전송 매개변수를 먼저 확인하세요. 인증서 검사를 끄면 보안 범위가 달라지므로 일반적인 속도 개선이나 문제 해결 방법으로 사용하지 마세요. 서버 도메인이 바뀌었다면 이전 SNI나 인증서 이름이 더 이상 맞지 않을 수 있습니다. 기존 매개변수를 그대로 두고 검사를 계속 완화하지 말고 원래 받은 정보를 확인해 갱신하세요. Config의 서버 주소와 TLS 이름이 다를 수는 있지만 서버의 요구 사항에 맞아야 합니다.

UDP 사용 가능 여부는 프로토콜 기능, 서버 구성과 현재 네트워크의 영향을 모두 받습니다. 앱에서 관련 옵션을 켠다고 모든 네트워크에서 UDP 연결을 사용할 수 있는 것은 아닙니다. IPv6도 별도의 단일 스위치로만 결정되지 않습니다. 기기, DNS 결과, 네트워크 출구와 규칙이 모두 영향을 줄 수 있습니다. IPv6 주소를 반환하는 대상에서만 문제가 생기면 관련 기록을 저장하고 조건을 통제해 비교하세요. 모든 연결 문제를 바로 IPv6 탓으로 돌리지 마세요.

MTU와 같은 매개변수는 패킷 크기와 전송 경로에 영향을 주므로 처음 설정할 때 임의로 바꾸지 않는 것이 좋습니다. 특정 네트워크에서 전송 문제가 반복되고 조정할 근거가 있을 때만 단계적으로 테스트하세요. 한 번에 값 하나만 변경하고 변경 전후의 네트워크와 대상을 기록하세요. 인터넷에서 본 고정값을 그대로 적용하면 문제가 잠시 달라지는 대신 다른 연결에 영향을 줄 수 있습니다.

앱 환경설정과 네트워크 설정은 따로 기록

표시 방식, 정렬과 테스트 환경설정은 주로 사용 경험에 영향을 줍니다. DNS, 라우팅 및 연결 설정은 요청 처리에 직접 영향을 줍니다. 두 종류의 변경 사항을 구분해 기록하세요. 목록을 정리하기 위해 메모를 수정하는 것과 서버 주소를 수정하는 것은 성격이 다릅니다. 문제를 확인할 때는 최근에 바꾼 네트워크 설정부터 살펴보고 화면 환경설정은 그다음에 확인하세요. 목록 순서가 바뀌었다고 서버 정보가 초기화됐다고 판단하지 마세요.

현재 화면에 특정 옵션이 없다면 다른 화면에서 같은 이름의 스위치를 억지로 찾지 마세요. 해당 옵션이 현재 Config의 매개변수인지 서버 상세 정보에 속하는지 먼저 확인하세요. 플랫폼과 화면 구성에 따라 위치가 다를 수 있으므로 이 가이드는 특정 위치를 유일한 기준으로 삼지 않습니다. 설정의 용도, 영향 범위와 되돌리는 방법을 설명할 수 있어야 조정을 마친 것입니다. 다른 사람과 같은 상태로 스위치를 바꾸는 것만으로는 충분하지 않습니다.

08 / MAINTENANCE

일상적인 유지 관리: 유효한 설정과 문제 기록 보관

안정적으로 사용하게 된 뒤에는 설정을 자주 바꾸기보다 어떤 정보가 변경되는지, 무엇을 백업해야 하는지, 문제가 발생했을 때 확인된 작동 상태로 돌아가는 방법을 파악하는 것이 중요합니다. 서버 목록, Config, 앱 환경설정과 시스템 VPN 권한은 서로 다른 계층에 속하며 어느 계층이 바뀌어도 사용 환경에 영향을 줄 수 있습니다. 간단한 유지 관리 습관을 들이면 서비스 만료, 구독 업데이트와 규칙 변경을 한꺼번에 처리하는 일을 피할 수 있습니다.

구독 업데이트와 Config 업데이트를 각각 확인

Subscribe를 업데이트한 뒤 콘텐츠를 가져오는 데 성공했는지, 자주 사용하는 서버가 삭제되거나 이름이 바뀌었는지 확인하세요. 목록의 항목 수만으로 업데이트 품질을 판단하지 마세요. 기존 서비스가 서버 배치를 조정했을 수 있고 로컬에 남아 있는 오래된 항목이 계속 표시될 수도 있습니다. 업데이트 후 연결에 문제가 생기면 현재 선택한 항목이 유효한 서버인지 먼저 확인한 뒤 인증 매개변수와 서비스 상태를 살펴보세요. 앱 전체를 바로 초기화할 필요는 없습니다.

Config 업데이트는 규칙, DNS, 정책 이름 또는 다른 설정을 변경할 수 있어 서버 목록만 업데이트하는 것보다 영향 범위가 넓습니다. 업데이트 전에 현재 작동하는 사본을 저장하고, 업데이트 후에는 몇 가지 고정된 대상으로 PROXY, DIRECT 및 LAN 동작을 확인하세요. 정책 이름이 바뀌면 기존에 연결된 선택 항목도 다시 확인해야 할 수 있습니다. 자동 업데이트는 수동 작업을 줄여 주지만 중요한 구성 변경 내용을 파악하는 일까지 대신하지는 않습니다.

백업에 용도와 민감 정보 포함 여부 기록

최소한 현재 사용 중인 Config, 자주 쓰는 서버가 어느 기존 구독에서 왔는지, 어떤 로컬 변경을 했는지 알고 있어야 합니다. 현재 화면의 내보내기 기능으로 저장할 때 파일에 서버 비밀번호, 구독 주소, 키 또는 다른 인증 정보가 포함되는지 확인하세요. 설정 파일은 일반 텍스트여도 계정 비밀번호와 비슷한 수준으로 민감할 수 있으므로 공개 폴더에 저장하거나 공개적으로 공유하지 마세요.

백업 이름에는 구분하기 어려운 숫자만 쓰기보다 ‘일상 분기’, ‘디버깅 전 사본’처럼 용도를 나타내세요. 복원할 때는 먼저 사본을 가져와 현재 존재하는 정책과 서버를 참조하는지 확인한 뒤 수동으로 연결하세요. 이전 백업의 서버 매개변수는 이미 유효하지 않을 수 있으므로 ‘가져오기 성공’이 ‘복원 후 정상 작동’을 보장하지는 않습니다. 연결 확인 장의 절차에 따라 다시 테스트하세요.

앱 업데이트, 기기 변경 및 재설치

iPhone / iPad 앱 업데이트는 App Store에서 진행합니다. 다시 받기 전에 기존 구매 계정의 구입 항목을 확인하세요. iPhone / iPad 버전은 App Store에서 $2.99 일회성 결제이며, Mac / Windows / Android / Linux 버전은 무료입니다. 이 두 가지 앱 제공 방식은 연결 서비스가 별도라는 점을 바꾸지 않습니다. 기기를 바꾸기 전에 본인의 Config와 구독 정보를 저장하세요. 앱을 설치하면 모든 로컬 정보가 자동으로 나타난다고 가정해서는 안 됩니다.

PC와 Android에서 업데이트하려면 다운로드 페이지에서 해당 플랫폼의 설치 파일을 다시 받고 설치 시 시스템 안내에 따라 진행하세요. Mac에서는 Apple 실리콘과 Intel을 구분해야 합니다. Linux에서는 현재 배포판에 맞는 패키지 형식을 선택하세요. 업데이트 전에 앱을 종료하고 로컬 변경 사항을 저장하세요. 업데이트 후 기존 설정이 유지됐는지 확인한 다음 필요한 정보만 가져와 같은 내용을 중복으로 만들지 않도록 하세요.

재현 가능한 문제 설명 작성

문제 기록은 다섯 가지 항목으로 정리할 수 있습니다. 발생 당시 네트워크, 선택한 서버, Global Routing, 영향을 받은 대상 유형, 앱에 표시된 오류입니다. 최근 Subscribe, Config 또는 앱을 업데이트했는지, 앱 연결을 끊은 뒤 기본 네트워크가 정상인지도 추가하세요. 이렇게 기록하면 권한, 연결 정보, 라우팅과 원격 서비스 중 어디부터 확인할지 분명해집니다. ‘갑자기 안 됨’이라고만 적는 것보다 문제를 구분하기 쉽습니다.

정해 둔 순서대로 확인하세요. 기본 네트워크, 서버 유효성, 현재 Config와 매칭된 정책을 확인한 뒤 마지막으로 고급 설정을 살펴봅니다. 잠시 Proxy로 전환하면 규칙의 영향을 분리할 수 있지만 테스트가 끝나면 평소 사용 방식으로 되돌리세요. 네트워크를 여러 번 바꿔야 간혹 성공한다면 성공한 사례만 남기지 말고 매번의 조건을 기록하세요. 간헐적인 문제일수록 비교 자료가 중요합니다.

• 재현 가능: 같은 조건에서 반복되면 변경 사항과 대상을 최소화하세요.
• 특정 네트워크에서만 발생: 매개변수는 그대로 두고 사용할 수 있는 다른 네트워크와 비교하세요.
• 업데이트 후에만 발생: 이전에 작동하던 Config를 복원하고 변경점을 하나씩 비교하세요.
• 특정 대상에서만 발생: 대상 요청과 정책을 확인하고 모든 정보를 먼저 초기화하지 마세요.

기록 정리 및 이전 상태 복원의 완료 기준

오래 사용하지 않은 단독 서버와 중복 Config는 정리할 수 있지만, 먼저 어떤 정책에서 참조하고 있는지 확인하세요. 삭제 전에 필요한 백업을 보관하고 삭제 후 자주 사용하는 환경에서 다시 연결해 보세요. 구독에서 생성된 항목은 업데이트 때 다시 나타날 수 있으므로 반복해서 직접 삭제하기보다 출처를 관리하세요. 서비스를 더 이상 사용하지 않을 때는 인증 정보를 복사해 둔 파일과 필요 없는 QR 코드 이미지도 정리하세요.

이전 상태 복원의 성공 기준은 목록이 원래대로 돌아왔는지가 아니라, 명확한 네트워크 조건에서 대상 요청이 다시 완료되고 라우팅 방식을 설명할 수 있는지입니다. 정상 작동을 확인한 뒤 임시 상세 기록을 끄고 평소에 필요한 On Demand 조건을 복원한 다음 최종적으로 작동하는 Config를 보관하세요. 같은 문제가 다시 생기면 이 확인 순서를 먼저 활용하세요. 간단한 절차는 빠른 시작, 구체적인 문답은 FAQ를 참고하세요. 매번 모든 설정을 삭제하는 것부터 시작하지 마세요.