Shadowrocket 완벽 사용 가이드

단계 01 / 구매

App Store 구매 및 정품 확인

Shadowrocket은 Apple 플랫폼에서 판매되는 유료 상용 폐쇄형 앱이며, 앱을 받을 수 있는 유일한 경로는 App Store입니다. 시작하기 전에 기기에서 사용하는 스토어 계정, 구매 기록, 사용 가능한 결제 수단을 확인하세요. 앱 구매와 서버 정보 준비는 별개의 과정입니다. 설치가 끝났다는 것은 앱을 실행할 준비가 됐다는 뜻일 뿐, 연결할 수 있는 서비스가 있다는 의미는 아닙니다. 이 사이트에서는 이미 보유한 정보를 가져와 사용하는 방법을 안내하며, 연결 서비스는 제공하지 않습니다.

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

정품 구매 안내를 열어 App Store 제품 페이지로 이동한 다음, 앱 이름 Shadowrocket과 개발자 Shadow Launch Technology Limited, 공식 아이콘, 앱 ID 932747118를 확인하세요. 이름은 우선 확인용으로만 참고하세요. 비슷한 이름의 검색 결과를 가려낼 때는 개발자와 앱 ID를 확인하는 편이 더 정확합니다. 앱 ID는 제품 링크 끝의 id932747118에 해당하며, 현재 앱 버전 번호가 아닙니다.

아이콘이 사이트 헤더에 표시된 공식 아이콘과 일치하는지 확인하세요. 검색 결과, 스토어 상세 페이지, 결제 확인 페이지 사이에서 화면이 전환될 수 있으므로 실제 구매를 확정하기 전에 제품 이름을 다시 확인해야 합니다. 페이지에 표시된 개발자가 다르면 현재 절차를 중단하고 정품 구매 안내에서 다시 이동하세요. 아이콘 색상이 비슷하다는 이유로 개발자 확인을 건너뛰거나 검색 순위를 확인 결과로 간주하지 마세요.

1회 구매와 지원 기기 범위 이해하기

Shadowrocket은 앱을 한 번 구매하는 방식이며, 실제 가격과 통화, 세금은 App Store 페이지에 표시된 내용을 따릅니다. 앱을 한 번 구매하는 것과 회선 요금제는 별개입니다. 앱 구매 비용에는 사용자가 보유한 서비스 비용이 포함되지 않으며, 서비스 유효 기간이나 데이터 한도, 계정 인증을 대신하지도 않습니다. 이후 연결에 실패하면 앱 상태와 서비스 상태를 따로 확인하세요. 앱을 구매했다는 이유만으로 서버가 정상 작동한다고 판단할 수 없습니다.

이 핸드북은 주로 iPhone과 iPad에서의 사용 방법을 설명합니다. Mac, Apple TV, Apple Vision의 호환성도 같은 App Store 페이지에서 확인할 수 있습니다. 시스템 요구 사항과 기기 지원 여부, 다른 기기에서의 공통 구매 적용 여부는 App Store 페이지에 표시된 내용을 따르세요. 기기마다 화면 배치와 입력 방식이 다를 수 있으므로 한 기기의 버튼 위치를 다른 기기의 조작 경로로 그대로 간주하지 마세요.

설치 후 구매 정보와 설정의 범위 구분하기

설치가 끝나면 기기의 홈 화면에서 Shadowrocket을 열어 정상적으로 실행되는지 확인한 뒤 정보를 가져오세요. App Store 구매 기록은 앱을 다시 받는 데 사용하고, 서버와 설정 데이터는 별도로 보관해야 합니다. 두 항목은 자동으로 연동되지 않습니다. 구매 기록을 복원해도 로컬 설정 전체가 복원되는 것은 아니며, 앱을 다시 설치해도 기존 구독 그룹, 수동 서버, 사용자 지정 규칙이 모두 돌아온다고 보장할 수 없습니다.

기기를 바꾸거나 앱을 다시 설치할 때는 App Store에서 기존 구매 계정의 구입 항목을 확인한 다음 구매 항목 복원 안내를 따르세요. 스토어에 다시 가격이 표시되면 서둘러 같은 작업을 반복하지 말고 계정과 구매 기록부터 확인하세요. 스토어에 구매 항목이 표시되는지는 현재 스토어 지역과 계정 상태의 영향을 받을 수도 있습니다. 이런 경우에는 클라이언트 연결 매개변수를 바꾸지 말고 스토어 절차부터 확인하세요.

단계 02 / 권한

최초 실행 및 시스템 VPN 구성

Shadowrocket을 처음 열면 Home, Config, Data, Settings가 각각 어떤 역할을 하는지 확인하세요. Home에서는 주로 서버와 연결 상태를 살펴보고, Config에서는 규칙 분기 설정을 관리합니다. Data에는 트래픽 관련 수치가 표시되고, Settings에서는 자주 사용하는 동작을 설정합니다. 세부 배치는 현재 앱 화면을 기준으로 확인하세요. 각 메뉴를 익힌 다음 하나씩 조작하면 여러 스위치를 동시에 바꾸는 것보다 문제 원인을 찾기 쉽습니다.

시스템에서 VPN 구성 추가를 요청하는 이유

서버 정보를 준비한 뒤 처음 연결을 켜면 시스템에서 VPN 구성 추가를 허용할지 물을 수 있습니다. 이는 Apple 시스템이 네트워크 확장 연결을 관리하도록 승인하는 절차로, 클라이언트가 시스템 네트워크 기능을 통해 트래픽을 처리할 수 있게 합니다. Config의 규칙 파일과는 별개입니다. 시스템 VPN 구성은 앱이 관련 네트워크 트래픽을 처리할 수 있는지를 정하고, Config는 처리 대상 요청을 어떻게 다룰지 정합니다.

방금 직접 시작한 Shadowrocket 작업에서 확인 창이 표시된 것이 맞는지 확인한 다음 시스템 안내에 따라 승인하세요. 기기 인증이 필요할 수도 있습니다. 승인이 끝나면 클라이언트로 돌아와 스위치와 상태를 확인하세요. VPN 구성 추가를 허용했다고 해서 서버 인증까지 성공한 것은 아닙니다. 시스템 승인은 주소, 비밀번호, UUID 또는 원격 서비스의 정상 여부를 확인하지 않습니다. 서버에 연결할 수 없어도 시스템 구성은 생성될 수 있습니다.

승인을 거절했거나 구성을 삭제했거나 안내가 반복될 때

방금 권한 요청을 거절했다면 앱으로 돌아가 서버 정보가 저장되어 있는지 확인한 뒤 연결을 다시 시도하고, 시스템에서 승인 절차를 다시 표시하는지 살펴보세요. 안내가 예상대로 나타나지 않으면 기기의 시스템 설정에서 VPN 관리 화면을 열어 해당 구성이 있는지 확인할 수 있습니다. 시스템 버전에 따라 메뉴 배치가 달라질 수 있으므로 고정된 경로를 그대로 따르기보다 VPN 항목 이름을 기준으로 찾으세요. 용도를 확인하기 전에는 다른 구성까지 삭제하지 마세요.

시스템 설정에서 Shadowrocket의 VPN 구성을 삭제했다면 다음 연결 시 다시 승인해야 할 수 있습니다. 먼저 연결을 끊은 다음 앱에서 새 연결 요청을 시작하세요. 승인을 반복해도 실패한다면 시스템 안내 원문, 기기 관리 제한 여부, 다른 VPN 연결이 실행 중인지 기록하세요. 권한 문제는 먼저 권한부터 해결하세요. 그와 동시에 프로토콜, DNS, 규칙을 바꾸지 마세요.

카메라·사진·네트워크 권한의 용도 구분하기

Scan QR Code를 사용할 때 카메라로 스캔하려면 카메라 권한이 필요합니다. 사진에서 QR 코드를 인식하는 경우에는 시스템 사진 선택 절차가 사용될 수 있습니다. 이런 권한은 가져오기 방법에만 관련되므로, Add Server에서 직접 입력할 때는 미리 QR 코드를 스캔할 필요가 없습니다. QR 코드에 인증 정보가 모두 포함되어 있을 수 있으니 스캔 전에 자신의 기존 서비스에서 받은 코드인지 확인하고, 스캔한 뒤에도 프로토콜, 주소, 포트를 점검하세요.

로컬 네트워크 접근 관련 안내가 표시되면 당시 기능의 용도를 확인하세요. 예를 들어 로컬 네트워크의 대상에 접근할 때 필요할 수 있으며, VPN 구성 승인을 대신하지는 않습니다. 알림 등 보조 권한 역시 연결 권한과는 다릅니다. 여러 확인 창이 나타나면 각 요청을 순서대로 읽으세요. 이미 허용을 눌렀다는 이유로 모든 권한이 승인됐다고 판단하지 마세요. 거절한 항목을 기록해 두면 나중에 복구할 대상을 명확히 알 수 있습니다.

재현 가능한 최초 연결 환경 만들기

처음 설정할 때는 안정적인 네트워크 환경을 유지하고 Wi-Fi와 Cellular를 번갈아 전환하지 않는 것이 좋습니다. 클라이언트 연결을 끊은 상태에서 일반 네트워크가 작동하는지 확인한 다음, 올바른 매개변수를 저장하고 시스템 승인을 완료해 클라이언트와 시스템 상태가 일치하는지 살펴보세요. 기기가 조직에서 관리되는 경우 정책에 따라 일부 네트워크 확장 기능이 제한될 수 있습니다. 기기 관리 정책을 따르고 이를 서버 문제로 오인하지 마세요.

이 단계가 끝나면 앱이 실행되고 시스템 승인 절차가 정상적으로 진행됐는지만 확인할 수 있습니다. 연결 후에는 대상 요청이 성공하는지, Global Routing이 예상대로 작동하는지 추가로 확인해야 합니다. 자세한 내용은 5장을 참고하세요. 권한 안내와 시스템 구성의 관계는 최초 연결 시 VPN 구성 안내에서 확인할 수 있습니다. 문제를 점검할 때는 단순히 ‘연결이 안 됨’이라고 적는 것보다 안내 원문을 남기는 편이 도움이 됩니다.

단계 03 / 가져오기

서버 추가 및 Subscribe 관리

가져오기 전에 받은 정보의 유형부터 확인하세요. 서버 매개변수 한 개, 서버 정보가 담긴 QR 코드, 구독 링크는 각각 입력 방법이 다릅니다. 일반 웹 주소를 구독 링크로 취급하거나 구독 링크를 단일 서버의 주소 필드에 넣지 마세요. 입력하는 정보는 모두 사용자가 이미 보유한 서비스에서 받아야 합니다. 이 장에서는 정확히 입력하고 확인하는 방법만 설명하며, 특정 서비스를 선택하도록 권하지 않습니다.

Add Server의 필드별 입력 방법

Add Server로 이동한 뒤 보유한 정보와 일치하는 프로토콜을 선택하고 주소와 포트를 입력하세요. 주소에는 보통 도메인이나 IP를 입력하며 임의로 경로를 덧붙이지 않습니다. 포트는 원격 서버에서 수신하는 포트와 일치해야 합니다. 이어서 해당 프로토콜에 필요한 인증 필드를 입력하세요. 빈칸이라고 해서 임의로 값을 추가하거나 안내 문구의 라벨까지 복사하지 마세요. 입력 후 저장하고 다시 열어 내용을 확인하세요.

인증에 성공해도 전송 설정까지 올바르다는 뜻은 아닙니다. TLS 서버 이름, WebSocket 경로, Host 필드는 서로 다른 항목이므로 보유한 매개변수에 따라 각각 입력하세요. 서버 주소가 비슷하다고 서로 대체할 수는 없습니다. 인증서 검증에 실패하면 이름, 기기 시간, 원격 인증서를 먼저 확인하세요. 검증을 끄는 것을 일상적인 해결 방법으로 삼지 마세요. VMess와 VLESS의 필드 차이는 프로토콜 매개변수 차이 안내에서 확인할 수 있습니다.

Subscribe: 가져오기와 업데이트는 다른 작업

구독을 가져오면 링크 응답 내용을 읽어 해당 서버 그룹을 만듭니다. 구독 업데이트는 링크에서 내용을 다시 받아 주소, 포트 및 기타 매개변수 변경 사항을 반영합니다. 가져오려면 앱에서 제공하는 구독 입력 방식으로 링크를 등록하고 저장한 뒤 요청이 완료될 때까지 기다리세요. 이후 그룹에 서버가 실제로 표시되는지 확인합니다. 그룹 이름만 있고 사용할 수 있는 항목이 없다면 응답 내용을 확인하세요. 이름이 표시된 것만으로 가져오기에 성공했다고 볼 수 없습니다.

구독 링크에는 개인 인증 정보가 포함되는 경우가 많으므로 공개 대화, 스크린샷, 문제 보고서에 올리지 마세요. 복사할 때 링크 끝부분이 빠지지 않았는지, 공백이 포함되지 않았는지, 서식 있는 텍스트에서 표시 문구만 복사된 것은 아닌지 확인하세요. 업데이트에 실패하면 구체적인 오류를 먼저 기록한 다음 일반 네트워크에서 구독 주소에 접근할 수 있는지, 서비스가 여전히 유효한지, 로그인 페이지나 오류 페이지가 반환되지는 않았는지 확인하세요. 업데이트 버튼을 계속 누르기보다 원인을 찾아야 합니다.

QR 코드 가져오기 후 결과 확인하기

Scan QR Code로 인식한 뒤 새 항목의 프로토콜, 메모, 주소가 예상과 일치하는지 확인하세요. QR 코드는 단일 서버를 나타낼 수도 있고 구독 진입점일 수도 있으므로, 가져오기 결과에서 앱이 생성한 항목을 확인해야 합니다. 인식은 성공했지만 예상한 내용이 표시되지 않으면 입력 유형부터 확인하고 링크를 곧바로 수동으로 조합하지 마세요. 출처가 불분명하거나 내용을 확인할 수 없다면 사용을 중단하고 본인의 올바른 정보를 다시 받으세요.

수동 수정과 구독 덮어쓰기의 범위

구독 항목은 구독 내용에 따라 관리되므로 매개변수를 수동으로 바꿔도 다음 업데이트에서 해당 필드가 덮어써질 수 있습니다. 임시로 확인해야 한다면 원래 값을 기록하고 별도의 테스트 항목을 유지해 그룹 전체가 추적하기 어려운 상태가 되지 않게 하세요. 서버 표시 이름은 메모일 뿐입니다. 이름이 같아도 같은 주소라는 뜻은 아니므로 실제 프로토콜, 주소, 포트로 중복 여부를 판단하세요.

가져오기가 끝나면 서버 항목 하나를 선택해 한 번만 확인하세요. 모든 항목을 바로 테스트할 필요는 없습니다. 기존 항목은 작동하고 새 항목만 작동하지 않으면 새 항목과 기존 항목의 매개변수 및 서비스 상태를 우선 비교하세요. 모든 항목이 실패한다면 시스템 권한, 로컬 네트워크, 가져오기 방법을 확인하세요. 기존 그룹을 삭제하기 전에 새 그룹으로 실제 접속이 되는지 확인해 되돌릴 수 있는 데이터를 미리 지우지 않도록 하세요.

단계 04 / 규칙 분기

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

Global Routing은 클라이언트가 처리하는 요청에 적용할 방식을 정합니다. Config는 현재 구성의 규칙에 따라 처리하고, Proxy는 관련 요청을 선택한 프록시로 보내며, Direct는 직접 연결 방식으로 처리합니다. 여기서 말하는 것은 클라이언트가 처리하는 범위의 요청입니다. 어느 모드든 기기의 모든 네트워크 활동이 반드시 같은 경로를 따른다는 뜻은 아닙니다. 시스템 기능, 앱 동작, 연결 유형에 따라 관찰 결과가 달라질 수 있습니다.

모드를 선택한 뒤 접속 결과를 확인하세요

평소 규칙에 따라 요청을 분기하려면 Config를 사용하고 현재 활성화된 구성을 확인하세요. 문제를 확인할 때는 Proxy와 Config를 잠시 비교할 수 있습니다. 같은 대상이 Proxy에서는 열리고 Config에서는 실패한다면 규칙, 정책 참조, DNS 처리를 먼저 확인할 만합니다. 다만 이 비교만으로 원인을 단정할 수는 없습니다. 두 요청 사이에 캐시나 연결 재사용, 네트워크 변화가 있었을 수 있으므로 비슷한 조건에서 반복 확인하세요.

규칙은 보통 위에서부터 순서대로 일치 여부를 확인합니다

규칙 파일에서는 구체적인 규칙을 포괄적인 규칙보다 앞에 두고, 앞선 규칙에 일치하지 않은 요청은 마지막의 FINAL로 처리하세요. DOMAIN은 특정 도메인에, DOMAIN-SUFFIX는 도메인 접미사에, IP-CIDR은 IP 주소 대역에 일치합니다. GEOIP는 IP 주소 위치 데이터베이스를 기준으로 판단합니다. 규칙 키워드와 정책 이름은 구분해야 합니다. 규칙 키워드는 무엇을 일치시킬지 정하고, 정책 이름은 일치한 요청을 어떻게 처리할지 정합니다.

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

다음은 규칙 순서를 설명하기 위한 Shadowrocket .conf 예시이며 모든 네트워크에 적합한 완성 설정이 아닙니다. 첫째 줄은 예시 도메인 접미사를 PROXY로 보내고, 둘째 줄은 지정된 사설 IP 대역을 DIRECT로 처리하며, 셋째 줄은 GEOIP에 따라 처리합니다. 마지막 줄은 앞선 규칙에 일치하지 않은 요청을 처리합니다. 실제로 사용할 때는 자신의 로컬 네트워크 주소와 대상, 현재 구성에서 사용 가능한 정책을 확인하세요. 예시를 복사하는 것만으로 규칙 분기가 완성된다고 볼 수 없습니다.

도메인 규칙과 IP 규칙의 결과가 달라질 수 있는 이유

도메인 규칙은 요청에서 도메인 정보를 식별할 수 있어야 일치하며, IP 규칙은 대상 주소에 적용됩니다. 일부 앱은 IP에 직접 연결하거나 캐시된 주소를 사용할 수 있으므로 도메인 규칙만 추가해서는 관련 요청을 모두 처리하지 못할 수 있습니다. 한 페이지가 여러 도메인에 요청을 보낼 수도 있습니다. 메인 페이지는 열리는데 이미지가 표시되지 않는다면 해당 리소스 요청을 더 확인하세요. 메인 도메인에 규칙 하나를 추가하는 것만으로 점검을 끝내지 마세요.

GEOIP 판단은 데이터베이스와 주소 확인 결과에 따라 달라지며 사이트의 언어, 브랜드 소재지 또는 사용자가 보는 콘텐츠와는 다릅니다. 대상이 여러 주소를 사용하거나 주소가 변경되면 일치 결과도 달라질 수 있습니다. 이런 경우 실제 요청 대상을 먼저 확인한 뒤 특정 도메인, 주소 대역 또는 다른 규칙 중 어떤 방식이 적절한지 판단하세요. 한 번의 접속 문제를 해결하려고 전체 주소 대역의 처리 범위를 임의로 넓히지 마세요.

Config를 수정한 뒤 다시 확인하기

먼저 기존 구성의 사본을 저장한 다음 목표가 명확한 규칙 하나를 수정하고, 저장 여부와 현재 수정한 구성을 사용 중인지 확인하세요. 구성 목록에 파일이 있다고 해서 적용 중인 것은 아닙니다. 파일 이름이 비슷할수록 적용 대상을 꼼꼼히 확인해야 합니다. 정책 이름 참조가 없거나 규칙 형식이 잘못됐거나 원격 리소스 업데이트에 실패했다면 네트워크 접속을 테스트하기 전에 구성 오류부터 해결하세요.

단계 05 / 연결 확인

연결 스위치, Connectivity Test, 실제 접속

연결을 확인할 때는 시스템에서 시작을 허용하는지, 서버 연결이 성립하는지, 대상 요청이 예상대로 완료되는지 세 가지를 함께 살펴보세요. 스위치가 켜져 있다는 것은 특정 상태만 보여 줄 뿐 웹 페이지가 정상적으로 열린다는 증거가 아닙니다. 마찬가지로 한 번의 테스트 시간 초과가 모든 네트워크 경로를 사용할 수 없다는 뜻도 아닙니다. 각 단계의 결과를 기록해야 ‘가끔 작동한다’는 표현에 가려진 차이를 파악할 수 있습니다.

비교를 위한 기준 환경 만들기

먼저 연결을 끊고 현재 Wi-Fi 또는 Cellular에서 일반적인 인터넷 접속이 되는지 확인하세요. 기본 네트워크에 로그인이 필요하거나 연결이 불안정하다면 먼저 해결해야 합니다. 그런 다음 확인을 마친 서버 하나와 Global Routing 모드 하나를 고정하고 연결을 켠 뒤 상태가 안정될 때까지 기다리세요. 확인 중에는 같은 대상을 사용하고, 네트워크와 서버를 바꾸면서 동시에 규칙까지 수정하지 마세요.

실제 접속에서는 대상 페이지가 끝까지 로드되는지, 리소스 응답이 계속 오는지, 새 요청도 반복해서 성공하는지 살펴보세요. 이미 열린 페이지는 캐시에서 표시될 수 있으므로 새로고침 아이콘이 멈추지 않는지만 보고 판단할 수 없습니다. 필요하다면 대상 앱의 기존 연결을 닫고 요청을 다시 보내거나, 새 요청이 명확한 다른 방식으로 교차 확인하세요. 확인을 위해 기기 데이터를 전부 지울 필요는 없습니다.

Connectivity Test 결과로 확인할 수 있는 것

Connectivity Test는 테스트 대상에 연결할 수 있는지 살펴보는 보조 기능입니다. 결과는 테스트 방식과 대상, 당시 네트워크 환경의 영향을 받습니다. 수치가 낮다고 다운로드 속도가 반드시 빠른 것은 아니며 모든 웹사이트 접속을 보장하지도 않습니다. 서버 테스트가 성공해도 실제 대상에 필요한 DNS, TLS, 앱 프로토콜, 리소스 도메인에서 문제가 생길 수 있으므로 테스트 결과와 실제 접속을 함께 확인하세요.

서버 두 개를 비교할 때는 테스트 방식과 네트워크 환경을 최대한 고정하세요. 조건이 다른 결과를 단순히 순위로 비교해서는 안 됩니다. 한 번의 시간 초과는 재시도해 확인할 수 있지만 모든 항목을 계속해서 촘촘히 테스트할 필요는 없습니다. 테스트를 지나치게 많이 하면 추가 요청이 발생하고 관찰을 방해할 수도 있습니다. 순간적인 수치 하나보다 대표적인 성공·실패 결과를 기록하는 편이 분석에 도움이 됩니다.

실패가 발생한 위치에 따라 범위 좁히기

스위치가 바로 꺼지면 시스템 VPN 구성, 권한, 앱 안내를 먼저 확인하세요. 스위치는 켜져 있지만 실제 요청이 모두 실패한다면 서버 주소, 포트, 인증, 전송 설정, 기본 네트워크를 점검하세요. 특정 대상만 실패하면 해당 대상의 도메인 확인, 규칙 일치 여부, 원격 상태를 살펴보세요. 인증 오류, 인증서 오류, 시간 초과는 서로 다른 의미이므로 원문을 보존하고 모두 ‘연결 안 됨’으로 뭉뚱그리지 마세요.

테스트는 정상인데 웹 페이지가 열리지 않는다면 먼저 DNS에서 유효한 결과를 받는지 확인하고 Config와 Proxy 모드에서 같은 요청을 비교하세요. 주소 확인에 성공했더라도 현재 연결 경로에서 접근할 수 없는 주소가 반환될 수 있으므로 이후 연결 오류도 함께 살펴봐야 합니다. 자세한 절차는 DNS 확인 실패 문제 해결에서 확인하세요. 운에 맡기듯 DNS 옵션을 한꺼번에 바꾸지 마세요.

속도 문제와 연결 문제는 따로 확인하세요

연결은 되지만 속도가 불안정하다면 연결을 처음 설정할 때 느린지, 단일 요청이 느린지, 데이터 전송이 계속 느린지 구분하세요. 처음 두 경우는 이름 확인이나 핸드셰이크와 관련될 수 있고, 지속적인 전송 속도는 원격 서버 부하, 로컬 신호 상태, 네트워크 혼잡, 대상의 제한에도 영향을 받습니다. 지연 시간은 여러 관찰 항목 중 하나일 뿐 전송 처리량으로 바로 환산할 수 없습니다. 네트워크를 바꾼 뒤 결과가 달라져도 로컬 연결 경로를 확인할 필요가 있다는 단서일 뿐입니다.

속도 저하 단계별 확인을 참고해 조건을 고정하고 비교할 수 있습니다. 임시 테스트가 끝나면 일상적으로 사용하던 모드로 되돌리세요. 특히 문제 해결을 위해 사용한 Proxy 또는 Direct를 필요에 맞지 않는 상태로 계속 두지 않도록 주의하세요. 원인을 찾지 못했다면 네트워크 유형, 프로토콜, 모드, 오류 원문, 재현 절차를 정리한 뒤 자주 묻는 질문에서 해당 항목을 살펴보세요.

단계 06 / 통계 확인

Data 트래픽 수치와 통계 범위

Data에서는 클라이언트가 집계할 수 있는 트래픽 활동을 확인할 수 있으며, 연결 중 요청과 데이터 전송이 있었는지 살펴보는 데 도움이 됩니다. 서비스 요금 내역이 아니며 모든 요청의 경로를 판단하는 유일한 기준도 아닙니다. 수치를 보기 전에 현재 통계 범위, 화면 분류, 단위, 시작·종료 시간을 확인하세요. 범위가 다른 숫자 두 개는 비슷해 보여도 단순히 빼서 결론을 내릴 수 없습니다.

업로드·다운로드·속도 수치 읽는 법

업로드와 다운로드는 기기를 기준으로 한 데이터 방향입니다. 업로드에는 요청과 제출 내용, 연결 과정의 상호 작용이 포함될 수 있고, 다운로드에는 반환 데이터와 응답 내용이 포함됩니다. 페이지를 열 때도 업로드가 발생하므로 업로드 수치가 0이 아니라고 해서 기기가 대용량 파일을 능동적으로 보내고 있다는 뜻은 아닙니다. 연결 설정, 재시도, 백그라운드 활동도 수치를 높일 수 있으므로 당시 작업을 함께 고려하세요.

속도는 특정 시간 동안 데이터가 변한 양을, 누적 트래픽은 특정 통계 구간의 전체 양을 나타냅니다. 순간 속도가 낮아진 것은 새 데이터가 들어오지 않는 상황일 수 있으므로 연결이 끊겼다고 단정할 수 없습니다. 누적 수치가 계속 증가해도 대상 페이지가 정상적으로 로드됐다는 뜻은 아닙니다. 화면의 단위가 바이트 계열인지 비트 계열인지 확인하세요. 단위가 다르면 수치가 크게 달라 보일 수 있습니다.

서버별·앱별 조회 시 유의할 점

서버별로 확인할 때는 현재 선택한 서버 이름만 보지 말고 같은 통계 구간에서 해당 서버가 처리한 데이터의 변화를 살펴보세요. 서버를 바꾼 뒤에는 이전 연결의 지속 시간과 수치가 어느 서버에 포함되는지 실제 화면을 기준으로 판단해야 합니다. 선택 항목을 바꾸면 과거 통계가 즉시 모두 다시 계산된다고 가정하지 마세요. 화면에 여러 보기가 있다면 현재 보기 제목과 분류 기준부터 확인하세요.

현재 화면에서 앱이나 프로세스별 정보가 제공되더라도 클라이언트가 식별할 수 있는 범위의 관찰 결과로 보아야 합니다. 기기의 모든 앱 트래픽을 완전히 기록한 자료는 아닙니다. 시스템에서 제공하는 정보, 공유 연결, 백그라운드 요청이 분류에 영향을 줄 수 있으며 식별할 수 없는 요청을 임의로 특정 앱에 귀속해서는 안 됩니다. 표시 범위는 현재 앱 화면을 기준으로 하세요. 특정 항목이 보이지 않는다고 해서 네트워크를 전혀 사용하지 않았다고 단정할 수 없습니다.

서비스 기록과 수치가 완전히 일치하지 않는 이유

클라이언트 통계와 사용자가 보유한 서비스의 관리자 기록은 시작·종료 시간, 정산 주기, 단위 환산, 프로토콜 오버헤드 기준이 다를 수 있습니다. 서버 측에는 같은 계정으로 연결한 다른 기기의 기록이 합산될 수 있지만 클라이언트는 이 기기에서 집계 가능한 활동만 표시할 수 있습니다. 전체 합계를 곧바로 비교하기보다 시간과 기기를 맞춘 다음 업로드·다운로드, 재전송, 추가 연결 오버헤드가 포함됐는지 확인하세요.

관찰을 시작할 때 이미 백그라운드 요청이 있었다면 초기 수치는 0을 기준으로 하지 않습니다. 테스트 도중 구독 자동 업데이트, 연결 테스트, 다른 앱 동기화로도 추가 활동이 발생할 수 있습니다. 소규모 비교가 필요하다면 시작과 종료 수치를 기록하고 테스트 시간과 대상을 통제하세요. ‘초기화’를 위해 통계 기록을 삭제하거나 모든 설정을 재설정하지 마세요.

범위를 정해 Data를 진단에 활용하기

연결을 켠 뒤 새 요청을 보냈는데 예상한 데이터 변화가 보이지 않는다면 먼저 요청이 현재 통계 범위에 포함되는지, 캐시가 사용됐는지 확인하세요. 업로드만 늘고 다운로드는 오랫동안 거의 변하지 않는다면 원격 응답을 추가로 확인할 단서가 될 수 있지만, 이것만으로 특정 인증 오류를 단정할 수는 없습니다. 연결 안내, DNS 결과, 규칙 처리 상태도 함께 살펴보세요.

테스트 시작 시간, 대상, 모드, 서버를 기록한 다음 관련 수치 변화를 살펴보세요. 이후 조건 하나만 바꿔 테스트를 반복하면 통계와 실제 동작을 연결해 분석할 수 있습니다. 자세한 수치 기준은 Data 트래픽 통계 안내에서 확인하세요. 문제를 제보할 때는 필요한 통계 요약만 남기고 서버 주소, 개인 식별 정보, 인증 내용을 가리세요. 전체 화면을 공개할 필요는 없습니다.

단계 07 / 설정

Settings, DNS, On Demand

Settings의 항목은 클라이언트 동작에 영향을 주며, Config의 항목은 현재 구성에서 요청을 처리하는 방식에 영향을 줄 수 있습니다. 각 기능의 위치는 현재 앱 화면을 기준으로 확인하세요. 설정을 바꾸기 전에 해결하려는 현상과 해당 항목이 전역 동작 또는 단일 구성 중 어디에 적용되는지 명확히 하세요. 적용 범위를 모른다면 기본값을 유지하고 먼저 의미를 확인하세요. 관련 있어 보이는 스위치를 모두 켜지 마세요.

On Demand: 자동 연결 조건과 수동 연결

On Demand는 시스템 조건에 따라 연결을 시작하거나 유지하도록 요청하는 기능입니다. 대표적인 조건으로 Wi-Fi와 Cellular가 있습니다. 서버가 정상 작동한다는 보장은 없으며 연결 실패 시 서버를 자동으로 바꿔 준다는 뜻도 아닙니다. 먼저 수동 연결이 안정적으로 작동하는지 확인한 뒤 어떤 네트워크 조건에서 연결을 시작할지 정하세요. 기본 연결 문제와 자동 실행 동작을 혼동하지 않도록 합니다.

한 네트워크에 고정해 규칙을 확인한 다음 다른 네트워크로 전환해 동작을 살펴보세요. 수동으로 끈 뒤 다시 연결되는지는 현재 조건과 시스템 상태를 함께 고려해야 합니다. 연결이 반복해서 시작된다면 주 스위치를 계속 켰다 끄기보다 On Demand 조건이 여전히 충족되는지 먼저 확인하세요. 일시적으로 사용을 중단할 때는 자동 실행 설정도 확인해 시스템 상태가 예상대로 유지되는지 살펴보세요.

Wi-Fi 이름 조건은 정확히 확인하세요. 이름이 비슷해도 같은 네트워크라는 뜻은 아닙니다. 웹 로그인이 필요한 Wi-Fi에 연결할 때는 먼저 기본 네트워크 인증을 완료하고 자동 연결을 확인하세요. 시스템은 절전 모드, 네트워크 재설정, 전환 상태에 따라 조건을 다시 확인할 수 있습니다. 일시적인 변화를 시간 흐름에 따라 살펴보고 한 번 전환해 본 결과로 모든 상황이 검증됐다고 판단하지 마세요.

DNS 설정은 주소보다 먼저 역할을 확인하세요

DNS는 도메인을 주소로 변환하지만 이름 확인 경로와 그 이후의 연결 경로는 별개의 문제입니다. DNS를 바꾸기 전에 실패가 이름 확인 단계에서 발생했는지 연결 단계에서 발생했는지 구분하세요. 도메인 결과가 없거나 오류가 반환되는 경우와 주소는 확인됐지만 연결 시간이 초과되는 경우는 점검 방향이 다릅니다. 웹 페이지가 열리지 않는다는 이유만으로 DNS를 바꾸면 단순한 문제에 변수가 더해질 수 있습니다.

사용자 지정 DNS 방식을 사용할 때는 현재 네트워크에서 해당 방식에 접근할 수 있는지, 요청이 어떻게 처리되는지 확인하세요. 로컬 네트워크 이름, 내부 도메인, 공개 도메인은 요구 사항이 다를 수 있으므로 하나의 설정이 모든 환경에 적합한 것은 아닙니다. 변경 후 새 요청을 보내고 캐시나 기존 연결 때문에 이전 결과가 잠시 유지될 수 있다는 점을 고려하세요. 결과가 한 번 바뀌지 않았다고 옵션을 계속 추가하지 마세요.

로그·테스트·개인정보

로그는 문제를 재현할 때 필요한 부분을 확인하는 데 유용합니다. 오류 원문, 시간, 대상, 반복 조건을 중심으로 기록하세요. 상세 로그를 오래 보관하면 로컬 저장 공간을 사용하고 접속 관련 정보가 쌓일 수 있습니다. 공유하기 전에는 전체 구독 링크, 인증 필드, 개인 식별 정보를 제거하세요. 도메인 목록도 사용 습관을 드러낼 수 있으므로 필요한 범위만 제공하세요.

연결 테스트 옵션은 테스트 대상이나 방식에 영향을 줍니다. 설정을 변경한 뒤에는 이전 조건에서 얻은 수치와 계속 직접 비교하지 마세요. 대상 자체가 불안정하면 테스트 결과도 달라질 수 있습니다. 문제를 확인할 때 테스트 조건을 고정하고 실제 대상 접속을 추가로 확인하세요. 더 낮은 수치를 얻으려고 설정을 계속 바꾸지 마세요.

설정을 바꾼 뒤 되돌릴 수 있도록 준비하기

Settings를 수정하기 전에 원래 값, 수정 이유, 예상 결과를 기록하세요. Config는 별도의 파일 사본으로 보관합니다. 앱에서 연결을 다시 설정해야 한다고 안내하면 현재 중요한 데이터 전송이 끝난 뒤 진행하세요. 수정 후 문제가 나아지지 않으면 원래 값으로 되돌린 뒤 다음 항목을 확인하세요. 설명할 수 없는 실험 설정을 여러 개 남겨두지 마세요.

단계 08 / 유지 관리

업데이트·백업·문제 기록

안정적으로 사용한 뒤에는 설정을 자주 바꾸기보다 복구 가능한 상태를 보관하고, 변화가 생겼을 때 무엇이 바뀌었는지 파악하는 것이 중요합니다. 클라이언트 업데이트, 구독 업데이트, Config 업데이트, 시스템 업데이트는 서로 다른 작업이며 각기 다른 계층에 영향을 줄 수 있습니다. 한 번에 중요한 변경 한 가지를 진행하고 확인을 마친 뒤 다음 작업을 하면 문제 발생 시 원인을 찾기 쉬워집니다.

클라이언트는 App Store에서 업데이트

App Store에서 Shadowrocket의 업데이트 기록과 현재 기기의 지원 조건을 확인하고 스토어 안내에 따라 업데이트하세요. 업데이트 전에 필요한 매개변수와 로컬 구성을 백업해 두세요. 업데이트 후에는 기존 서버와 모드로 먼저 확인하고, 모든 구성을 동시에 바꾸지 마세요. 동작이 달라졌다면 변경 전후의 작업과 앱 안내를 기록하세요. 특정 버전이 반드시 원인이라고 추측할 필요는 없습니다.

시스템 업데이트는 권한 안내, 네트워크 전환 동작, 화면 경로를 바꿀 수도 있습니다. 업데이트 후 최초 연결 시 다시 확인을 요청하면 안내를 읽고 해당 시스템 구성을 점검하세요. 모든 데이터를 곧바로 삭제하지 마세요. 시스템 요구 사항은 App Store 페이지에 표시된 내용을 따릅니다. 앱은 정상적으로 열리지만 연결에 문제가 있다면 권한, 서버, 규칙, DNS 순서로 계속 확인하세요.

실제로 도움이 되는 백업 항목

최소한 수동 서버에 필요한 매개변수, 구독 출처, 현재 Config 파일, 주요 Settings의 원래 값을 각각 저장하세요. 구독 링크만 보관한다고 해서 서버 정보가 장기간 그대로 유지되는 것은 아닙니다. 서비스 내용이 바뀐 뒤 다시 가져오면 결과가 달라질 수 있습니다. 백업에는 저장 시점과 용도를 기록하되 인증 정보를 공개 파일 이름, 스크린샷 제목, 공유 문서에 적지 마세요.

앱에서 제공하는 내보내기 또는 저장 기능을 사용할 때는 어떤 항목이 내보내지는지 확인하고 파일에 예상한 내용이 있는지 점검하세요. 내보내기 완료 안내만으로 복원까지 검증된 것은 아닙니다. 중요한 구성은 원본 데이터를 보존한 채 다시 읽을 수 있는지 확인하세요. 백업은 본인이 관리하며 접근이 제한된 위치에 보관합니다. 규칙 예시를 공유하려면 개인 서버와 구독 정보를 먼저 제거하세요.

구독과 Config는 따로 관리하기

구독 업데이트 후 항목 수와 주요 매개변수가 예상과 일치하는지 확인하고 실제 연결을 테스트하세요. 항목이 줄었다면 기존 정보를 바로 모두 삭제하지 말고 응답 내용과 서비스 상태부터 확인하세요. Config 업데이트에서는 규칙 순서, 정책 참조, 원격 리소스가 정상인지 확인해야 합니다. 두 종류의 업데이트를 동시에 진행하면 특히 이미 연결에 실패한 상황에서 원인을 구분하기 어려워집니다.

중복 항목을 정리할 때는 메모 이름만 보지 말고 실제 프로토콜, 주소, 포트로 구분하세요. 새 상태가 안정적인지 확인한 다음 오래된 파일을 정리할 수 있도록 검증된 복구용 구성을 하나 보관하세요. 출처나 용도가 명확하지 않은 구성을 무작정 추가하지 마세요. 파일이 많다고 기능이 더 완전한 것은 아닙니다. 현재 사용 중인 항목과 유효한 참조 관계를 명확히 유지하는 것이 목표입니다.

재현 가능한 문제 기록 정리하기

도움이 되는 기록에는 문제가 발생한 네트워크 유형, 직전 네트워크 전환 여부, 사용한 프로토콜, Global Routing 모드, 구체적인 오류 원문, 실패한 대상 범위, 마지막으로 정상 작동한 시점이 포함되어야 합니다. 시도한 설정 변경과 결과도 항목별로 적으세요. 그래야 모든 요청이 실패한 경우, 특정 대상만 실패한 경우, 테스트는 실패했지만 실제 접속은 정상인 경우를 구분할 수 있습니다.

기록에 비밀번호, UUID, 전체 구독 링크, 개인을 식별할 수 있는 정보는 포함하지 마세요. 필요하다면 실제 주소 대신 설명을 사용하고 프로토콜, 오류 유형, 발생 순서만 남기세요. FAQ를 확인하거나 시작 가이드로 돌아가 기본 절차를 살펴볼 때는 기록을 기준으로 하나씩 대조하세요. 다른 결과를 얻으려고 가져오기 과정을 처음부터 계속 반복하지 마세요.