Shadowrocket 사용법 전체 가이드

01 / APP STORE

App Store 정식 구매 및 구매 정보 확인

앱을 먼저 확인한 뒤 구매하세요

Shadowrocket은 Apple 플랫폼에서만 제공되는 유료 클라이언트이며, 유일한 공식 구매 경로는 App Store입니다. 시작하기 전에 사이트의 App Store 정식 앱 확인 페이지에서 앱 이름, 개발자, 앱 ID를 확인한 다음 App Store에서 구매하세요. 검색 결과에 표시된 이름만으로 앱을 판단하지 마세요. 이름이나 아이콘이 비슷하더라도 제품 페이지 정보로 확인해야 합니다. 현재 구매 조건은 App Store에 표시된 설명, 호환성, 가격 및 구매 확인 화면을 기준으로 판단하세요.

정식 앱인지 확인하려면 세 가지를 모두 살펴보세요. 개발자는 Shadow Launch Technology Limited, 앱 ID는 932747118이며 아이콘은 이 사이트에서 사용하는 공식 아이콘과 일치해야 합니다. 제품 페이지 주소 끝의 id932747118로 앱 ID를 확인할 수 있습니다. 개발자 이름은 검색 요약이나 다른 페이지의 설명이 아니라 App Store 제품 페이지에서 확인하세요. 확인을 마친 뒤 현재 로그인한 구매 계정과 결제 확인 화면에 표시된 금액을 살펴보세요. 앱 확인과 계정 확인을 한 단계로 혼동하지 않는 것이 좋습니다.

일회성 구매에 포함되는 범위

클라이언트 일회성 구매 ≠ 회선 요금제. Shadowrocket을 구매하면 클라이언트를 사용할 수 있지만, 연결하려면 사용자가 이미 보유한 구독 또는 서버 정보가 필요합니다. 이 매뉴얼은 정보 가져오기, 설정 및 문제 해결 방법만 설명하며 서버나 구독을 제공하거나 판매하거나 추천하지 않습니다. 클라이언트는 매개변수를 읽고 연결을 설정하며 라우팅 규칙을 적용합니다. 원격 서버의 가용성, 인증 유효성, 연결 용량은 별개의 조건이므로 앱을 구매했다고 해서 이를 보장하는 것은 아닙니다.

미국 App Store의 가격은 약 2.99달러이며 일회성 결제입니다. 실제 금액, 통화 및 구매 조건은 App Store 페이지 표기를 기준으로 확인하세요. App Store 국가나 지역에 따라 표시 가격과 구매 가능 여부가 다를 수 있으므로 결제 전 현재 계정의 구매 확인 화면을 기준으로 판단해야 합니다. 구독 링크의 유효 기간과 클라이언트 구매를 혼동하지 마세요. 전자는 원격 접속 권한의 유효 기간이고 후자는 앱 구매 기록과 관련이 있습니다. 두 항목의 기록을 따로 보관하고 문제도 각각 확인하세요.

기기 호환성 및 App Store 지역 확인

이 매뉴얼은 주로 iPhone과 iPad 조작을 안내합니다. Mac, Apple TV, Apple Vision의 호환성도 같은 App Store 제품 페이지의 호환성 항목에서 확인할 수 있으며, 시스템 요구 사항과 구매 적용 범위는 모두 App Store 페이지 표기를 기준으로 합니다. Apple ID가 같다는 이유만으로 모든 기기와 시스템 조합이 조건을 충족한다고 단정하지 마세요. 기기를 변경할 때는 대상 기기에서 제품 페이지의 호환 여부를 먼저 확인한 뒤, 현재 App Store 구매에 사용하는 계정에 구매 기록이 있는지 확인하세요.

앱을 검색할 수 없다면 먼저 ‘검색 결과가 없음’과 ‘현재 스토어에서 제품 페이지를 이용할 수 없음’ 안내를 구분하세요. 계정의 App Store 지역을 확인하고 올바른 제품 페이지를 다시 연 다음 표시된 안내 문구를 기록하세요. 네트워크 설정을 반복해서 바꾸어도 App Store 지역 문제는 대개 해결되지 않습니다. 계정의 스토어 지역과 기기 언어는 서로 다른 설정이므로, 인터페이스 언어를 바꿔도 구매 스토어가 바뀌는 것은 아닙니다. 자세한 확인 방법은 App Store 지역 및 스토어 표시 여부 안내를 참고하세요.

설치 후 확인 사항

설치가 끝나면 앱이 정상적으로 실행되는지 먼저 확인한 뒤 권한과 연결을 설정하세요. 구매를 완료해도 구독이 자동으로 가져와지거나 시스템 연결이 설정되는 것은 아닙니다. 두 작업은 이후 별도로 진행해야 합니다. 앱 업데이트는 App Store에서 관리하며 업데이트 기록도 스토어에서 확인할 수 있습니다. 처음 사용할 때는 여러 설정을 서둘러 변경하지 마세요. 초기 상태를 유지하고 App Store에서 구매, 앱 실행, 서버 가져오기, 실제 연결을 각각 확인하면 이후 문제가 발생했을 때 어느 단계에서 비롯됐는지 정확히 파악할 수 있습니다.

02 / PERMISSIONS

최초 실행 및 시스템 연결 권한

앱 스위치와 시스템 권한 구분하기

처음 실행한 뒤 Home에 서버 항목이 있는지 확인하세요. 목록이 비어 있는 것은 아직 정보를 가져오지 않은 정상적인 상태이며, 앱에 문제가 있다는 뜻이 아닙니다. Shadowrocket이 시스템 수준의 연결을 설정하려면 시스템에서 제공하는 VPN 구성 기능을 사용해야 합니다. 처음 연결을 시도할 때 VPN 구성을 추가할지 묻는 시스템 확인 창이 나타날 수 있습니다. 이 확인은 기기에서 네트워크 터널을 만들도록 허용하는 절차이지, 원격 서버 로그인 화면이 아니며 사용 가능한 서버나 구독을 제공하는 것도 아닙니다.

시스템 확인 창이 나타나면 현재 사용하는 Shadowrocket과 관련된 요청인지 확인한 뒤 기기의 안내에 따라 승인하거나 본인 인증을 완료하세요. 시스템 암호, 생체 인증, 서버 암호는 각각 용도가 다르므로 서로 대신 입력하면 안 됩니다. 이전에 권한을 거부했다면 앱에서 연결을 다시 시도하고 시스템 확인 창이 다시 나타나는지 살펴보세요. 기존 구성을 확인하려면 시스템 설정에서 VPN 관련 항목을 찾을 수 있습니다. 메뉴 경로는 시스템 인터페이스에 따라 달라지므로 기기에 표시되는 내용을 기준으로 확인하세요.

권한 오류는 발생 위치부터 확인

앱 스위치가 곧바로 꺼진다면 완료되지 않은 시스템 확인 요청, 기기 관리 제한, 다른 VPN 연결이 진행 중인지 먼저 살펴보세요. 이 현상을 구독 만료로 바로 단정하면 안 됩니다. 원격 서버에 접속하는 단계까지 아직 진행되지 않았을 수 있습니다. 관리 대상 기기의 네트워크 권한은 관리 정책에 따라 제한될 수 있으므로 제한이 있다면 먼저 기기 정책을 확인하세요. 스위치를 연속으로 눌러 재시도하지 말고 현재 연결 요청을 종료한 뒤 시스템 상태가 안정될 때까지 기다리고 구체적인 안내 문구를 기록하세요.

시스템 구성이 이미 있는데도 앱에서 권한 문제가 표시된다면 연결을 끊고 시스템의 해당 구성이 Shadowrocket에 속하는지, 다른 구성을 잘못 선택하지 않았는지 확인하세요. 시스템 구성을 변경하거나 제거하기 전에는 서버 및 구성 자료를 저장하고 제거 후 권한을 다시 승인해야 한다는 점을 확인하세요. 앱 전체를 삭제하는 것은 권한 문제 해결의 첫 단계가 아닙니다. 앱의 로컬 데이터와 시스템 구성은 수명 주기가 다르므로 섣불리 재설치하면 간단한 권한 문제가 자료 복구 문제로 커질 수 있습니다.

필요한 기능에만 추가 권한 허용

Scan QR Code를 사용할 때 시스템에서 카메라 접근 권한을 요청할 수 있습니다. QR 코드 스캔으로 정보를 가져올 때만 이 권한이 필요합니다. 이전에 카메라 접근을 거부했다면 반복해서 스캔하지 말고 시스템의 앱 권한 설정에서 확인하세요. 사진 앱의 이미지를 스캔하는 경우와 카메라를 직접 사용하는 경우에는 접근 안내가 다를 수 있으므로 현재 작업에 필요한 권한을 기준으로 판단하세요. QR 코드에는 전체 연결 매개변수가 포함될 수 있으므로 출처를 확인한 뒤 가져오고, 문제 해결을 이유로 원본 QR 코드를 공개적으로 전송하지 마세요.

구독 링크를 붙여넣을 때 시스템에서 클립보드 관련 안내가 표시될 수 있습니다. 클립보드에 가져올 내용이 있는지 확인하고 채팅 문구, 줄바꿈 또는 불필요한 문장 부호가 복사되지 않도록 주의하세요. 로컬 파일이나 클라우드 파일을 읽어야 한다면 시스템 파일 선택 화면에서 대상 파일을 찾은 뒤 가져온 결과를 확인하세요. 권한은 해당 리소스에 접근하도록 허용할 뿐 파일 내용이 올바른지 검증하지는 않습니다. 권한을 허용한 뒤에도 서버 수, 이름, 주요 매개변수가 예상과 맞는지 확인해야 합니다.

최초 사용 시 기준 상태를 명확히 설정

처음 설정할 때는 안정적인 로컬 네트워크에서 진행하고, 복잡한 On Demand 조건을 동시에 활성화하거나 DNS를 여러 개 변경하지 마세요. 먼저 식별하기 쉬운 서버 항목 하나를 준비한 뒤 Global Routing을 선택하고 연결을 시도하세요. 이렇게 하면 ‘가져오지 못함’, ‘시스템 연결을 설정하지 못함’, ‘연결 후 요청 실패’를 구분해 처리할 수 있습니다. 기기에 네트워크 필터나 다른 VPN 구성이 있다면 현재 상태를 기록하고, 테스트 중에는 이번 확인에 필요한 연결 조건만 유지하세요.

권한 승인 후에는 특정 아이콘 하나가 시스템에 표시되는지보다 앱 연결 상태, 시스템 VPN 상태, 실제 요청 결과가 일치하는지 확인하세요. 기기마다 상태 표시 방식이 다를 수 있으므로 상태 표시줄에 아이콘이 계속 보이지 않는다는 이유만으로 실패라고 판단하지 마세요. 이때의 네트워크 유형, 선택한 서버, 권한 승인 결과를 기록해 두면 이후 정보를 더 가져온 뒤에도 이 기준 상태와 비교하여 변화가 새 데이터 때문인지 시스템 설정 때문인지 판단할 수 있습니다.

03 / SERVER & SUBSCRIBE

서버 추가 및 기존 구독 가져오기

보유한 자료의 유형부터 확인

가져오기 전에 보유한 자료가 단일 서버 매개변수인지, 공유 링크인지, QR 코드인지, 여러 서버 항목을 반환하는 구독 링크인지 확인하세요. 겉모양이 비슷하다고 서로 바꿔 쓸 수 있는 것은 아닙니다. 서버 주소는 연결 대상을 나타내고 구독 주소는 여러 항목을 가져오는 데 사용되며 구성 파일에는 규칙과 기타 설정도 포함될 수 있습니다. 구독 주소를 서버 주소 입력란에 넣으면 주소 전체를 입력했더라도 예상대로 작동하지 않습니다. 자료의 용도가 불분명하면 모든 입력란에 하나씩 시험해 보기보다 원래 안내를 먼저 확인하세요.

Add Server로 직접 추가할 때는 보유한 자료와 일치하는 프로토콜 유형을 먼저 선택한 다음 해당 필드를 입력하세요. 주소에는 일반적으로 호스트 이름이나 IP만 입력하고 포트는 별도 필드에 입력합니다. 웹 경로를 주소에 덧붙이지 마세요. 암호, UUID, 암호화 방식 및 기타 옵션을 하나씩 대조하고 대소문자, 앞뒤 공백, 입력기에서 바뀐 문장 부호를 확인하세요. 용도를 구분할 수 있는 이름을 지정해 여러 항목을 잘못 선택하지 않도록 하세요. 이름은 항목을 식별하기 위한 것으로 잘못된 연결 매개변수를 수정해 주지 않습니다.

프로토콜별 필수 매개변수 확인

프로토콜 유형에 따라 각 필드의 의미가 달라집니다. 포트 번호나 암호가 같다고 해서 서로 다른 프로토콜에서 그대로 사용할 수 있는 것은 아닙니다. Shadowsocks는 암호화 방식과 암호가 일치해야 합니다. VMess와 VLESS는 인증 정보와 전송 조건을 함께 확인해야 하며 Trojan은 암호와 TLS 조건을 확인해야 합니다. HTTP와 SOCKS5 인증 정보는 보유한 자료에 따라 입력하고 다른 프로토콜의 필드 의미를 그대로 적용하지 마세요. WireGuard, Hysteria2 등의 유형도 마찬가지로 전체 원본 매개변수를 기준으로 확인하고 이름만 보고 기본값을 추측하지 마세요.

Subscribe 가져오기 및 결과 확인

기존 구독을 가져오려면 추가 화면에서 Subscribe를 선택하고 전체 구독 주소를 입력한 뒤 저장하고 업데이트를 실행하세요. 예상한 서버 항목이 생성되었는지 확인해야 합니다. 구독 주소의 쿼리 매개변수는 접근 자격 정보의 일부인 경우가 많으므로 임의로 삭제하거나 순서를 바꾸거나 대체하지 마세요. 복사할 때 끝 문자가 누락되지 않았는지, 메신저가 링크를 잘라내지 않았는지, 앞뒤에 설명 문구가 붙지 않았는지 특히 주의하세요. 가져오기에 성공한 뒤에는 목록에 항목이 표시된다는 이유만으로 전체 항목이 검증됐다고 보지 말고 하나를 선택해 먼저 테스트하세요.

구독 업데이트에 실패하면 주소에 접근할 수 없는지, 응답 내용을 인식하지 못하는지, 원격 인증이 만료됐는지 먼저 구분하세요. 오류 안내를 보관하고 전체 링크를 확인한 뒤 현재 네트워크에서 구독 내용을 가져올 수 있는지 비교하세요. 기존 서버는 연결되지만 구독 업데이트만 일시적으로 실패할 수도 있습니다. 업데이트 요청과 기존 항목을 통한 연결은 별개의 과정이기 때문입니다. 전체 그룹을 즉시 삭제하지 마세요. 작동하는 항목을 보존한 상태에서 구독 가져오기 조건을 확인해야 사용 가능한 연결과 문제 해결 단서를 함께 잃지 않습니다.

QR 코드 스캔, 업데이트 및 자료 보호

Scan QR Code로 가져온 뒤에도 프로토콜, 주소, 포트 및 인증 필드를 확인하세요. QR 코드 인식에 성공했다는 것은 텍스트를 읽었다는 뜻일 뿐 내용이 완전하거나 여전히 유효하다는 의미는 아닙니다. 구독 업데이트로 항목 이름, 수량 또는 순서가 바뀔 수 있으므로 목록 위치만 기억해 자주 쓰는 서버를 찾지 마세요. 항목을 직접 수정하려면 다음 구독 업데이트에서 변경 사항이 덮어써지는지 먼저 확인하세요. 필요한 경우 별도 사본을 저장하고 알아보기 쉬운 이름을 지정해 임시 수정 사항을 구독 원본에 영구 반영된 것으로 오해하지 않도록 하세요.

구독 링크, 공유 링크, QR 코드에는 접근 권한 정보가 포함될 수 있으므로 자격 증명처럼 취급하세요. 문제를 설명할 때는 프로토콜, 오류 유형, 발생 단계를 공유하되 전체 암호, UUID 또는 구독 쿼리 매개변수는 공개하지 마세요. 가져오기 완료 후 최소한 목록의 출처가 명확하고 주요 매개변수가 원본 자료와 일치하며 대상 항목 하나 이상이 선택되어 있는지 확인하세요. 다음으로 Global Routing을 설정하세요. 전체 작업 과정을 한 번에 따라 하고 싶다면 빠른 시작의 Subscribe 가져오기 안내로 이동하세요.

04 / GLOBAL ROUTING

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

모드를 정한 다음 규칙 일치 결과 확인

Global Routing은 요청을 처리하는 방식을 결정합니다. 인터페이스에 표시되는 세 가지 모드는 Config, Proxy, Direct이며 각각 설정 규칙에 따른 처리, 프록시 처리, 직접 연결을 의미합니다. Config에서는 현재 구성된 규칙에 따라 처리 정책을 선택합니다. Proxy에서는 해당 처리 범위에 들어오는 요청을 현재 선택한 서버로 보냅니다. Direct에서는 직접 연결합니다. 세 가지 모드는 요청 처리 방식이지 서버 세 종류를 뜻하거나 원격 계정 자체를 바꾸는 기능이 아닙니다. 문제를 해결할 때는 먼저 현재 모드를 기록하세요. 모드가 다르면 같은 규칙도 적용되지 않는 것처럼 보일 수 있습니다.

평소 Config를 사용할 때는 Config 목록에 파일이 있는지만 보지 말고 현재 어떤 구성이 활성화되어 있는지 확인하세요. 파일 저장, 편집, 활성화는 각각 별도의 작업입니다. 규칙을 변경한 뒤 앱에서 제공하는 방식으로 저장하고 적용한 다음 새 테스트 요청을 보내세요. 기존 연결은 이전 상태를 계속 사용할 수 있습니다. Proxy는 일부 규칙 문제를 분리해 확인하는 데 도움이 될 수 있지만 테스트가 끝나면 원래 필요한 모드로 되돌려 임시 문제 해결 상태를 장기간 유지하지 마세요.

규칙은 순서대로 평가하며 마지막 규칙이 기본 처리를 담당

일반 규칙은 구성에 적힌 순서대로 평가되므로 더 구체적인 대상을 넓은 범위의 규칙보다 앞에 두세요. DOMAIN은 전체 도메인, DOMAIN-SUFFIX는 도메인 접미사와 하위 도메인, DOMAIN-KEYWORD는 도메인에 포함된 키워드를 기준으로 일치 여부를 판단합니다. IP-CIDR과 IP-CIDR6은 주소 범위를 처리하고 GEOIP는 IP 지리 분류 데이터를 기준으로 판단합니다. 규칙 유형은 어떤 대상을 비교할지 결정하며, 정책은 규칙과 일치한 요청을 어떻게 처리할지 결정합니다. 정책 이름과 일치 조건을 혼동하지 마세요.

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

위 예시는 규칙 순서를 설명하기 위한 것으로 모든 네트워크에 적합한 완전한 구성은 아닙니다. api.example.com에 접속하면 첫 번째 규칙과 일치하므로 두 번째 접미사 규칙은 해당 요청을 처리하지 않습니다. 그 밖에 example.com에 속하는 대상은 두 번째 규칙으로 처리될 수 있습니다. 마지막의 FINAL은 앞선 규칙과 일치하지 않을 때 사용할 정책을 뜻하며 맨 끝에 두어야 합니다. 예시 도메인은 설명용이므로 복사하기 전에 실제로 처리할 대상을 확인하세요. 예시를 검증된 업무용 규칙으로 간주해서는 안 됩니다.

정책, 해석 및 규칙 적용 범위 이해

PROXY, DIRECT, REJECT는 일반적으로 사용되는 처리 정책입니다. 규칙에서 구성에 정의된 정책 그룹을 참조할 수도 있습니다. 참조하는 이름은 실제 정의와 일치해야 합니다. 존재하지 않는 이름만 적어도 정책 그룹이 자동으로 만들어지지 않습니다. 특정 대상을 거부해야 한다면 먼저 일치 범위를 좁히고 해당 대상이 로그인, 인증 또는 다른 리소스도 함께 제공하는지 확인해 정상 기능에 영향을 주지 않도록 하세요. 문제를 해결할 때는 키워드나 넓은 주소 범위로 확대하기보다 구체적인 도메인을 먼저 사용하세요.

도메인 규칙과 주소 규칙은 서로 다른 정보에 의존합니다. 요청에 도메인이 포함되어 있으면 도메인 기준으로 판단할 수 있지만 주소 정보만 있으면 주소 관련 규칙으로 처리될 수 있습니다. 일부 규칙에는 추가 DNS 조회가 필요할 수도 있습니다. DNS 응답 주소, 캐시, 요청 유형이 관찰 결과에 영향을 주므로 대상 이름만 보고 반드시 어떤 규칙과 일치한다고 단정할 수 없습니다. USER-AGENT 등의 조건도 적용 범위가 있으므로 모든 암호화 요청에서 같은 애플리케이션 계층 정보를 확인할 수 있다고 가정하지 마세요.

구성이 복잡해질수록 복구 가능한 기본 파일을 보관하는 것이 중요합니다. 한 번에 규칙 하나씩 추가하고 예상하는 대상과 실제 적용 정책을 기록한 뒤 다음 규칙을 추가하세요. 문제가 발생하면 파일 활성화 여부, 규칙 순서, 정책 이름을 먼저 확인하고 수정 범위를 넓히는 것은 마지막으로 고려하세요. 규칙을 많이 쌓는 것보다 요청이 특정 규칙과 일치한 이유를 설명할 수 있어야 유지 관리에 도움이 됩니다.

05 / CONNECT & VERIFY

연결 설정 및 단계별 확인

반복 가능한 테스트 한 번 설정

연결 전에 선택한 서버, Global Routing 모드, 현재 로컬 네트워크의 세 가지 조건을 고정하세요. 서버가 유효한 보유 자료에 있는지 확인하고 모드를 선택한 뒤 연결 스위치를 켜고 미완료된 시스템 권한 확인을 처리하세요. 테스트 도중 서버를 바꾸거나 구독을 업데이트하거나 DNS를 변경하지 마세요. 요청이 복구되더라도 어떤 단계가 영향을 주었는지 알기 어렵습니다. 재현할 수 있는 요청을 몇 개만 사용해 기준 상태를 설정하면 이후 비교가 의미를 갖습니다.

한 번의 전체 확인에는 최소 세 단계가 포함됩니다. 시스템 연결이 설정되었는지, 대상 요청이 완료되는지, 실제 처리 정책이 예상과 일치하는지 확인하세요. 시스템에 연결됨으로 표시되는 것은 로컬 터널이 작동 중이라는 뜻일 뿐 원격 서버가 인증을 완료하거나 대상에 접속할 수 있음을 보장하지 않습니다. 웹페이지가 열리더라도 선택한 서버를 거쳤다는 뜻은 아닙니다. Config에서 해당 요청이 DIRECT와 일치했을 수 있습니다. 따라서 확인 결과에는 ‘접속 가능 여부’와 ‘적용된 처리 정책’을 함께 기록하고 성공 또는 실패만 남기지 마세요.

Connectivity Test 결과 활용 방법

Connectivity Test는 항목별 기본 연결 상태를 비교하는 데 도움이 되지만 먼저 선택한 테스트 방법이 무엇인지 확인해야 합니다. 방법에 따라 연결 설정, 특정 대상의 응답 또는 일부 프로토콜 단계만 확인할 수 있으므로 결과를 일상적인 다운로드 속도와 동일하게 해석해서는 안 됩니다. 한 번의 테스트에서 시간 초과가 발생하더라도 테스트 대상, 일시적인 네트워크 변화 또는 서버의 테스트 방식 처리와 관련된 문제일 수 있습니다. 동일한 네트워크와 테스트 조건에서 몇 차례만 반복한 뒤 실제 요청 결과와 함께 판단하세요.

지연 시간이 짧다고 처리량이 높은 것은 아니며 연결 설정에 성공해도 모든 요청이 정상이라는 뜻은 아닙니다. 기본 테스트는 정상이지만 특정 페이지가 실패한다면 전체 서버를 바로 문제로 판단하지 말고 대상 도메인, 규칙, DNS 및 관련 리소스를 확인하세요. 반대로 독립된 여러 대상이 모두 실패하고 Proxy 모드에서도 요청이 완료되지 않으면 주소, 포트, 인증 정보, 원격 상태를 먼저 확인하는 편이 좋습니다. 테스트 도구는 단서를 제공할 뿐 실패 단계를 구분하는 작업을 대신하지 않습니다.

실패 증상에 따라 다음 단계 선택

인터넷에 접속할 수 없다면 먼저 연결을 끊은 상태에서 로컬 네트워크가 정상 요청을 처리하는지 확인한 뒤 같은 서버로 다시 연결해 비교하세요. 로컬 네트워크에 웹 페이지 인증이 필요하다면 먼저 인증을 완료해야 합니다. Proxy와 Config를 비교할 때는 모드만 변경하세요. Proxy는 정상이지만 Config에서 실패하면 규칙, 정책 참조, 구성 활성화 여부를 먼저 확인합니다. 둘 다 실패한다면 서버와 연결 조건을 확인하세요. 이 비교로 모든 원인을 찾을 수 있는 것은 아니지만 문제 범위를 크게 좁힐 수 있습니다.

‘속도 저하’와 ‘연결 실패’ 구분하기

속도 문제는 연결이 이미 작동하는 상태에서 확인해야 합니다. 테스트 대상과 시간대를 고정한 뒤 원격 서버, 로컬 네트워크, 전송 조건, 대상 서비스 자체의 제한을 구분하세요. 대용량 전송과 짧은 웹 요청은 중요하게 보는 지표가 다르므로 작은 요청의 응답 시간만으로 지속 전송 성능을 판단할 수 없습니다. 비교할 때는 다른 기기나 앱이 동시에 네트워크를 사용하지 않도록 하고, 측정 중 프로토콜 옵션을 반복해서 변경해 비교 가능성을 없애지 마세요.

확인이 끝나면 최종 서버, 모드, 구성 이름, 네트워크 유형을 기록하고 일상적으로 사용할 설정으로 되돌린 뒤 요청을 한 번 더 보내세요. 추가로 확인해야 한다면 연결되었지만 인터넷에 접속할 수 없을 때 확인할 항목을 참고하세요. 속도가 계속 느리다면 서버, 회선, 프로토콜, 로컬 네트워크별 점검 방법을 확인하세요. 기록에는 증상과 조건을 남기되 전체 접근 자격 정보는 포함하지 마세요.

06 / DATA

Data 트래픽 및 요청 기록 읽기

통계 범위와 시간 구간부터 확인

Data에서는 앱에서 확인 가능한 트래픽 및 연결 정보를 살펴볼 수 있습니다. 수치를 읽기 전에 현재 화면에 표시된 데이터가 이번 연결에 대한 것인지, 특정 시간 범위의 것인지, 누적 데이터인지 확인하고 초기화 기능이 있는지도 살펴보세요. 통계 기준이 다르면 단순히 뺄셈으로 비교할 수 없으며, 다시 연결했다고 해서 모든 기록이 지워진다고 볼 수도 없습니다. 앱 인터페이스의 구체적인 항목은 실제 화면을 기준으로 확인하세요. 다른 기기의 스크린샷만 보고 자신의 기기에도 같은 통계 화면이나 보존 방식이 있다고 추정하지 마세요.

업로드와 다운로드는 전송 방향을 나타내며 파일 업로드와 다운로드 작업만 뜻하지 않습니다. 웹페이지를 열 때도 요청을 보내며 파일을 보낼 때도 확인 응답을 받습니다. 프로토콜 오버헤드, 재전송, 연결 유지, 도메인 조회로 트래픽이 발생하므로 화면 통계가 파일 크기와 일치하지 않을 수 있습니다. 특정 작업으로 수치가 얼마나 바뀌는지 알아보려면 다른 네트워크 활동이 적을 때 작업 전후 데이터를 기록할 수 있습니다. 다만 이는 대략적인 관찰일 뿐 원격 서비스의 정확한 과금 기록은 아닙니다.

클라이언트 통계는 원격 계정 기록을 대체하지 않음

Shadowrocket의 통계는 클라이언트에서 확인 가능한 활동을 나타내지만 원격 구독의 요금 및 사용량 산정 방식은 다를 수 있습니다. 기기에서 다른 직접 연결을 사용하거나 여러 기기가 같은 원격 계정을 함께 사용하거나 통계 시간이 다르면 두 수치를 단순 비교하기가 더 어렵습니다. 구독에 표시되는 잔여 트래픽은 원격에서 전달된 정보일 수도 있으며 갱신 주기는 클라이언트의 실시간 집계와 다를 수 있습니다. 차이가 발생하면 먼저 시간 구간과 기기 범위를 비교한 뒤 데이터에 이상이 있는지 판단하세요.

특정 앱이 예상한 정책을 사용하는지 확인하려면 총 트래픽 증가량만 보지 말고 요청 대상과 규칙 일치 정보를 함께 살펴보세요. 총량 변화는 네트워크 활동이 있었다는 것만 알려 줄 뿐 특정 작업 때문이라고 단정할 수 없습니다. 시스템 백그라운드 동기화, 페이지 미리 로드, 다른 앱 새로 고침이 동시에 발생할 수 있습니다. 방해 요소를 줄이려면 불필요한 활동을 멈춘 뒤 짧고 명확한 작업을 수행하고 시간을 기록한 다음 해당 시간대의 요청과 정책을 확인하세요.

요청 정보를 이용해 규칙 및 DNS 문제 확인

현재 화면에서 연결 또는 요청 상세 정보를 제공한다면 대상 도메인이나 주소, 적용 정책, 연결된 서버, 오류 발생 단계를 중점적으로 확인하세요. 도메인과 주소는 서로 다른 근거입니다. 도메인은 도메인 규칙을 확인하는 데 도움이 되고 주소는 주소 범위와 DNS 결과를 확인하는 데 도움이 됩니다. 한 페이지는 여러 대상을 요청할 수 있으므로 기본 문서가 정상적으로 열려도 이미지, 로그인 인증, 다른 리소스는 같은 경로로 처리되지 않을 수 있습니다. 일부 리소스만 누락되면 페이지 기본 도메인만 추가하지 말고 실패한 구체적인 리소스를 찾으세요.

규칙을 수정한 뒤에는 새 요청을 보내 결과를 확인하세요. 브라우저의 기존 연결, 앱 캐시, DNS 캐시 때문에 이전 상태가 이어져 새 규칙이 적용되지 않은 것처럼 보일 수 있습니다. 현재 테스트 작업을 끝낸 뒤 필요하면 해당 요청을 종료하고 다시 시작하여 새 기록을 확인하세요. 기록을 지우기 전에는 유용한 오류 단계와 시간 정보를 저장하세요. 기록을 바로 삭제한 뒤 다시 시도했을 때 문제가 일시적으로 사라지면 장애를 설명할 유일한 단서를 잃을 수 있습니다.

트래픽 증가 및 백그라운드 활동 확인

백그라운드 트래픽이 계속 증가한다면 연결 유지 시간, 기기의 동기화 작업, On Demand 조건을 먼저 확인하세요. 연결이 계속 유지되면 관리 통신이 발생할 수 있지만 총량 증가만으로 특정 설정에 문제가 있다고 판단할 수는 없습니다. 재현하기 쉬운 짧은 시간 구간을 정해 화면 사용, 백그라운드 동기화, 네트워크 전환이 변화와 일치하는지 비교하세요. 배터리 소모도 트래픽 수치만으로 설명할 수 없으며 연결 유지, 무선 네트워크 상태, 기기 작업과 관련될 수 있으므로 각각 따로 기록해야 합니다.

다른 사람에게 문제를 설명할 때는 정리한 시간, 대상 유형, 정책, 오류 문구를 우선 제공하세요. 요청 기록에는 사용 패턴, 전체 주소, 쿼리 매개변수, 인증 정보가 포함될 수 있으므로 공유 전에 불필요한 내용을 삭제하세요. 편의를 위해 전체 기록과 구독 정보를 함께 보내지 마세요. 진단이 끝나면 추가로 켠 상세 기록을 일상적으로 필요한 수준으로 되돌리세요. 이후 기록을 확인하기 쉬워지고 불필요한 정보가 쌓이는 것도 줄일 수 있습니다.

07 / SETTINGS

Settings, DNS 및 On Demand 설정

설정이 적용되는 계층부터 구분

Settings의 모든 옵션이 같은 범위에 적용되는 것은 아닙니다. 일부는 앱 동작에, 일부는 현재 연결에, 나머지는 Config 파일이나 개별 서버 항목에 영향을 줍니다. 변경하기 전에 설정 대상과 기존 값을 기록하세요. 구성에 관련 내용이 이미 있다면 다른 화면의 설정이 이를 반드시 덮어쓴다고 단정하지 마세요. 현재 옵션 설명을 확인하고 실제 요청으로 검증해야 합니다. 여러 유용해 보이는 옵션을 한꺼번에 켜기보다 작동하는 기준 상태를 유지하는 것이 중요합니다.

설정은 세 그룹으로 나누어 처리하는 것이 좋습니다. 먼저 연결에 필요한 항목을 설정하고, 다음으로 On Demand와 이름 조회를 조정한 뒤, 마지막으로 특정 네트워크에 필요한 고급 옵션을 확인하세요. 매번 논리적으로 관련된 한 그룹만 변경하고 저장한 다음 같은 대상을 테스트하세요. 결과가 나빠지면 다른 변경 사항을 추가해 보완하려 하지 말고 해당 그룹의 원래 값으로 되돌리세요. 용도를 이해하지 못한 스위치는 추측으로 조정하기보다 현재 작동하는 설정을 유지하는 편이 관리하기 쉽습니다.

DNS는 이름을 조회하며 연결 인증을 대신하지 않음

DNS의 기본 역할은 도메인 이름을 요청에 필요한 주소로 변환하는 것입니다. 이름 조회 실패, 예상과 다른 주소 반환, DNS 서버에 접근할 수 없는 상황은 웹페이지가 열리지 않는 원인이 될 수 있지만 서버 암호 오류와는 다른 단계의 문제입니다. 문제를 확인할 때는 조회 전과 후 중 어느 단계에서 실패했는지 먼저 살펴보고 수정할 계층을 결정하세요. 특정 IP로 연결할 수 있어도 해당 서비스의 모든 도메인 요청이 정상이라는 뜻은 아닙니다. 많은 서비스가 도메인, 인증서, 여러 리소스 도메인에 의존하므로 IP 주소 접속만으로 전체 동작을 확인할 수 없습니다.

DNS를 선택하거나 변경할 때는 현재 연결 조건에서 조회 서비스에 접근할 수 있는지와 DNS 요청 경로가 어떻게 설정되어 있는지 함께 고려해야 합니다. 접근 경로는 확인하지 않고 주소만 바꾸거나 출처가 불분명한 주소를 계속 추가하지 마세요. 테스트 시 도메인, 반환 결과, 시간을 기록하고 다른 조건은 그대로 유지하세요. 암호화 DNS를 활성화해도 모든 요청이 동일한 출구를 사용한다는 뜻은 아닙니다. DNS 경로와 실제 요청의 처리 정책을 각각 검증해야 하며 하나의 설정만으로 전체 연결 경로를 추정할 수 없습니다.

조건에 따라 연결하는 On Demand

On Demand는 설정한 조건에 따라 연결을 시작하거나 유지할 시점을 결정하는 기능이지 원격 서버 문제를 자동으로 해결하는 기능이 아닙니다. 설정하기 전에 필요한 동작을 명확히 정하세요. 특정 네트워크에 들어갈 때 연결할지, 나간 뒤에도 유지할지, 어떤 상황에서 로컬 네트워크를 직접 사용할지 결정해야 합니다. 사용할 수 있는 조건은 앱의 현재 화면을 기준으로 확인하고 조건별 순서와 일치 범위를 하나씩 살펴보세요. 이름이 비슷한 네트워크라도 같은 조건으로 간주하지 말고 실제로 네트워크를 전환하면서 저장된 설정을 확인하세요.

스위치를 끈 뒤에도 자동으로 다시 연결된다면 수동 스위치가 고장 났다고 보기 전에 On Demand가 활성화되어 있는지 확인하세요. 요청이 새로 발생하거나 네트워크가 바뀌면 조건에 따라 다시 연결될 수 있습니다. 문제를 확인하는 동안 관련 조건을 잠시 비활성화하고 수동 연결을 확인한 뒤 하나씩 복원할 수 있습니다. 웹 페이지 인증이 필요한 네트워크에서는 먼저 로컬 인증을 완료한 다음 On Demand 조건이 적절한지 확인하세요. 연결이 시작되는 시점이 초기 네트워크 접속을 방해하지 않도록 주의해야 합니다.

연결 방식 선택 및 고급 옵션

On Demand 연결과 지속 연결은 사용 편의성, 백그라운드 활동, 네트워크 전환 후 복구 방식에서 서로 다른 장단점이 있으며 모든 기기에 통용되는 하나의 정답은 없습니다. 조건에 자주 진입하거나 이탈하면 연결을 새로 설정하는 작업이 늘어날 수 있습니다. 배터리 소모를 판단할 때는 비슷한 사용 시간과 네트워크 환경을 비교하고 한 번의 시스템 통계만 보지 마세요. 더 자세한 비교 방법은 On Demand 설정과 백그라운드 배터리 사용량의 균형을 참고한 뒤 실제 사용 방식에 따라 결정하세요.

IPv6, UDP, 연결 시간 초과 또는 기타 네트워크 매개변수를 조정할 때는 증상이 해당 옵션과 실제로 관련 있는지 먼저 확인하세요. 요청 하나가 실패했다는 이유만으로 특정 기능을 전역에서 비활성화할 필요는 없습니다. 변경 범위가 넓을수록 정상적인 요청에도 영향을 줄 수 있습니다. 가능한 한 좁은 범위에서 테스트하고 변경 전후 결과를 저장하세요. 설정을 마친 뒤에는 연결을 다시 설정하는 경우와 네트워크를 전환하는 경우를 각각 한 번 이상 확인해 현재 종료되지 않은 연결에서만 정상으로 보이는 것은 아닌지 점검하세요.

08 / MAINTENANCE

일상적인 유지 관리, 기기 변경 및 문제 기록

앱, 구독, 구성을 따로 관리

일상적인 유지 관리에서는 앱 업데이트, 구독 업데이트, Config 파일 변경을 각각 구분해 처리하세요. 앱 업데이트는 App Store에서 이루어지고 구독 업데이트는 사용자가 보유한 주소에서 서버 항목을 가져오며 구성 변경은 규칙과 관련 동작을 바꿉니다. 세 작업이 서로 영향을 줄 수는 있지만 같은 작업은 아닙니다. 원인을 찾기 쉽도록 한 번의 테스트 전에 모든 업데이트를 동시에 진행하지 마세요. 먼저 현재 연결이 작동하는지 확인하고 상태를 기록한 다음 단계별로 작업하며 각 단계가 끝날 때 간단히 검증하세요.

구독 업데이트 후에는 항목 수, 자주 사용하는 서버가 남아 있는지, 현재 선택된 항목이 바뀌었는지 확인하세요. 이름이 같다고 매개변수도 바뀌지 않았다고 단정하지 말고 목록 순서가 달라졌다고 항목이 삭제된 것으로 오해하지 마세요. 구독이 관리하는 항목을 직접 수정하면 다음 업데이트에서 덮어써질 수 있으므로 임시 테스트 항목과 일상적으로 사용하는 항목을 구분하세요. 중복되거나 사용할 수 없으며 더 이상 필요하지 않다고 확인된 기록은 주기적으로 정리하되 문제가 해결되기 전에 자료를 한꺼번에 삭제하지 마세요.

복구 가능한 구성 및 자료 보관

Config를 변경하기 전에 작동하는 사본을 저장하고 이름에는 용도만 표시하세요. 구분하기 어려운 ‘최종’ 표시를 계속 덧붙일 필요는 없습니다. 백업에는 규칙 텍스트뿐 아니라 서버 항목에서 가져온 매개변수와 구독 업데이트로 제공된 항목도 구분해 두어야 합니다. 암호, UUID, 전체 구독 주소가 포함된 자료는 보호된 위치에 보관하고 공개 메모에 넣지 마세요. 복구할 때는 적용 범위를 먼저 확인하고 한 기기의 모든 설정을 검토 없이 다른 기기에 그대로 적용하지 마세요.

기기를 변경하기 전에 앱 구매 계정, 보유한 서버 자료, 구성 파일을 각각 다시 가져올 수 있는지 확인하세요. App Store 구매 복원과 앱 내부 자료 복원은 별개의 작업입니다. 전자는 클라이언트를 다시 받을 수 있는지와 관련되고 후자는 기존 연결 조건을 되찾을 수 있는지와 관련됩니다. 기존 구매 계정으로 App Store의 구입 항목에서 Shadowrocket을 찾으세요. 시스템 요구 사항과 구매 적용 범위는 App Store 페이지 표기를 기준으로 합니다. 자세한 단계는 구입 항목 복원 안내를 참고하세요.

재설치 전에 최소한의 문제 해결 기록 작성

문제가 생기면 발생 시간, 기기의 네트워크 유형, Global Routing 모드, 구성 이름, 서버 프로토콜, 오류 발생 단계를 먼저 기록하세요. 구독 업데이트가 안 되는지, 시스템 연결을 설정하지 못하는지, 연결 후 특정 대상만 실패하는지 설명해야 합니다. ‘모두 초기화하고 확인하기’보다 재현 가능한 작업 하나로 범위를 좁힌 뒤 비교 테스트를 진행하는 편이 유용한 결과를 얻기 쉽습니다. 기록에서 서버를 구분할 때는 임의의 이름을 사용해 실제 주소와 인증 정보를 공개하지 마세요.

재설치는 일반적인 첫 단계가 아닙니다. 앱을 제거하면 로컬 자료, 기록, 저장된 문제 해결 단서를 더 이상 확인할 수 없게 될 수 있으며 원격 인증 오류, 네트워크 조건, 규칙 논리 문제는 재설치로 해결되지 않을 수도 있습니다. 먼저 최근에 작동했던 구성으로 복구하고 임시로 추가한 조건을 끈 다음 연결 장의 순서대로 확인하세요. 정말 재설치해야 한다면 작업 전에 필요한 자료를 모두 다시 가져올 수 있는지 확인하세요. App Store에서 앱을 다시 받을 수 있다고 해서 앱 내부 구성이 백업된 것은 아닙니다.

반복 가능한 유지 관리 절차 만들기

유지 관리 작업은 기준 상태 확인, 자료 저장, 변경 한 가지 적용, 대표 대상 테스트, 실제 정책 확인, 결과 기록 순서로 정리할 수 있습니다. 대표 대상은 무관한 페이지를 많이 여는 대신 실제로 필요한 접근 유형을 포함해야 합니다. 정상적인 결과도 간단히 기록해 두세요. 다음에 문제가 생기면 이전에 어떤 조건에서 정상적으로 사용했는지 알아야 합니다. 테스트 중 Proxy로 잠시 전환했다면 끝날 때 평소 모드로 되돌리고 On Demand 조건이 원래 계획과 일치하는지도 확인하세요.

문제 해결 정보를 공유하기 전에 스크린샷, 로그, 복사한 텍스트에 민감한 내용이 들어 있는지 다시 확인하세요. 특히 구독 쿼리 매개변수, 인증 정보, 접속 기록을 살펴야 합니다. 상대방에게 필요한 것은 대개 오류 발생 단계와 재현 조건이지 전체 계정 자료가 아닙니다. 기기를 변경하거나 재설치한 뒤 구매 기록을 찾을 수 없다면 기기 변경 또는 재설치 후 구입 항목을 복원하는 방법을 참고하세요. 처음 다시 설정할 때는 빠른 시작 가이드로 돌아가 기본 흐름에 따라 연결을 설정한 뒤 개인 설정을 하나씩 복원하세요.