Shadowrocket 완전 사용 설명서: App Store에서 받는 방법부터 일상 관리까지

Shadowrocket은 App Store의 유료 앱이며, 다른 취득 경로는 없습니다. 이 장에서는 세 가지를 정리합니다. 스토어에서 자신이 연 페이지가 정품인지 확인하는 방법, 1회 구매로 무엇을 사는지, 그리고 어떤 기기에 설치할 수 있는지입니다.

Shadowrocket을 App Store에서 검색하면 이름이 비슷한 앱이 여러 개 나타납니다. 판단 기준은 이름이 아니라 스토어 페이지의 세 가지 정보입니다. 개발자 항목에 Shadow Launch Technology Limited가 적혀 있는지, 앱 아이콘이 흰 바탕에 파란-보라 그라데이션 테두리의 로켓 모양인지, 스토어 페이지 주소에 앱 ID 932747118이 들어 있는지입니다. 세 가지가 모두 맞아야 구매해야 할 그 앱입니다.

앱 ID를 따로 기억해 둘 이유

앱 ID는 App Store에서 각 앱을 구분하는 고유 번호입니다. 이 사이트에서 스토어로 연결되는 모든 링크는 https://apps.apple.com/kr/app/shadowrocket/id932747118 하나로 통일되어 있으며, 주소창에서 보이는 id932747118과 스토어 페이지 정보의 앱 ID는 같은 값입니다. 어떤 페이지가 제시한 링크에 다른 번호가 들어 있다면, 그것이 가리키는 것은 Shadowrocket이 아닙니다.

1회 구매로 사는 것은 무엇인가

Shadowrocket은 1회 구매 방식의 유료 앱입니다. 미국 스토어 기준 가격은 약 2.99달러이며, 다른 스토어에서는 현지 통화로 표시됩니다. 정확한 금액은 스토어 페이지를 열었을 때 보이는 표기를 기준으로 하세요. 구매 대상은 클라이언트 자체, 즉 iPhone과 iPad에서 실행되는 이 앱입니다. 구매 후 월 구독료가 따로 없고, 기능을 열기 위해 다시 결제할 필요도 없습니다.

지원 기기 범위와 시스템 요구 사항

Shadowrocket은 iPhone과 iPad가 중심이며, 동시에 같은 App Store 스토어 페이지의 호환성 항목에도 올라 있어 Mac, Apple TV, Apple Vision을 아우릅니다. 특정 기기에 설치할 수 있는지는 그 기기에 로그인된 Apple ID가 이 앱을 이미 구매했는지, 그리고 스토어 페이지에 현재 표기된 호환성에 따라 결정됩니다. 시스템 버전 요구 사항은 항상 App Store 페이지 표기를 기준으로 하세요. 앱은 시스템 업데이트에 맞춰 최소 버전을 조정하므로, 가이드에 박아 둔 숫자는 곧 지나간 정보가 됩니다.

구매 후: 구입 항목과 업데이트

구매가 끝나면 앱은 해당 Apple ID의 구입 항목에 들어갑니다. 기기를 바꾸거나 다시 설치할 때 같은 Apple ID로 App Store의 구입 항목에서 다시 내려받으면 되고, 추가 결제는 필요하지 않습니다. 가족 공유가 이 앱에 적용되는지도 스토어 페이지 표기를 기준으로 하세요.

업데이트는 App Store가 일괄 배포하며, 앱 안에 별도의 업데이트 채널이 있거나 파일을 직접 교체할 필요도 없습니다. App Store의 자동 업데이트를 켜 두거나, 가끔 계정 페이지에서 수동으로 한 번 업데이트하면 충분합니다. 이 사이트는 어떤 설치 파일도 제공하지 않으며, 제공할 수도 없습니다—설치 파일을 제공한다고 주장하는 출처는 모두 정품과 무관합니다.

구매 전에 준비할 두 가지

구매 버튼을 누르기 전에 두 가지를 준비해 두는 것이 좋습니다. 하나는 서버 정보 또는 구독 링크(서비스 제공업체에서 받음)이고, 다른 하나는 기기에 로그인된 Apple ID가 평소 쓰는 계정인지 확인하는 것입니다. 전자는 구매 후 바로 쓸 수 있는지를, 후자는 나중에 기기를 바꿀 때 문제없이 되찾을 수 있는지를 좌우합니다. 화면만 먼저 익히고 싶다면 서버가 하나도 없어도 앱은 열리지만, 연결 스위치로 터널을 세울 수는 없습니다.

Shadowrocket을 처음 열면 시스템 권한 창이 연달아 뜹니다. 각 창이 무엇을 담당하는지, 허용해야 하는지, 잘못 눌렀을 때 어떻게 복구하는지가 이 장의 내용입니다. 겸사겸사 메인 화면의 탭 몇 개도 익혀 둡니다.

처음 실행할 때 가장 먼저 나타나는 것은 보통 VPN 구성 승인 팝업입니다. iOS는 요청한 앱의 이름을 분명히 표시하고 VPN 구성을 추가할지 묻습니다. 허용을 선택하면 시스템이 Shadowrocket을 위한 로컬 터널 구성을 만들고, 이후의 연결 스위치는 이 구성을 기반으로 동작합니다.

VPN 구성 권한이 필요한 이유

iPhone과 iPad에서 앱이 트래픽을 자체 처리 로직을 거치게 하려면 시스템이 제공하는 네트워크 확장 프레임워크를 써야 합니다. Shadowrocket은 서버 파라미터와 규칙을 시스템 수준 VPN 구성으로 변환하고, 트래픽은 시스템에서 이 터널로 들어와 앱이 규칙에 따라 프록시로 보낼지 직접 연결할지 결정한 뒤 다시 시스템에 넘겨 전송됩니다. 시스템 '설정'에서 해당 VPN 구성 항목이 보이는 것도 이 때문입니다. 그것은 시스템 차원에 실제로 존재하는 항목이며, 앱 내부의 흉내 낸 스위치가 아닙니다.

세 팝업은 각각 무엇인가

• VPN 구성 승인(Add VPN Configurations): 기능상 필수입니다. 거부하면 연결 스위치가 작동하지 않습니다.
• 알림 권한: 연결 상태 변화 같은 알림을 표시하는 데 쓰입니다. 허용 여부는 프록시 기능에 영향을 주지 않습니다.
• 로컬 네트워크(Local Network): 같은 LAN에 있는 다른 기기가 이 기기의 프록시 포트에 접근해야 할 때만 필요합니다. 그런 용도가 없다면 거부해도 됩니다.

세 팝업 중 필수는 첫 번째뿐입니다. '허용 안 함'을 잘못 눌러도 앱을 지우고 다시 설치할 필요는 없습니다. 연결 스위치를 다시 켜면 시스템이 다시 물어보며, 그래도 팝업이 뜨지 않으면 시스템 '설정'의 VPN 항목에서 관련 구성이 이미 있는지 확인하세요.

메인 화면의 탭 몇 가지

Shadowrocket의 메인 화면은 하단 탭으로 구성되며, 이후의 모든 작업은 여기에서 시작합니다:

• Home: 서버 목록과 연결 스위치. 상단에는 현재 Global Routing 모드가 표시되고, 가운데는 노드 목록, 하단은 메인 스위치입니다.
• Config: 구성 파일과 규칙. 가져온 .conf 파일과 규칙 목록을 여기에서 확인하고 편집합니다.
• Data: 트래픽 통계. 서버별과 앱별 두 가지 수치를 제공하며 7장에서 자세히 다룹니다.
• Settings: 전역 설정. On Demand, DNS, 구독 자동 업데이트 같은 옵션이 여기에 있으며 8장에서 다룹니다.

인터페이스 용어는 영어 원문을 유지합니다: Home, Config, Data, Settings, Add Server, Subscribe, Global Routing, On Demand. 한국어 설명에 이 단어들이 나오면 화면에 있는 그 버튼이나 라벨을 가리킵니다. 원문을 유지하는 이유는 하나씩 대조할 수 있게 하기 위해서이며, 비슷한 뜻의 한국어로 바꾸기 위해서가 아닙니다.

권장 초기 설정 순서

처음 설정할 때는 아래 순서대로 한 번 따라가는 편이, 스위치를 아무렇게나 눌러 보는 것보다 문제를 찾기 쉽습니다:

1. 먼저 Settings에서 Global Routing 모드를 확인합니다. 기본값인 Config로 두면 됩니다.
2. Home으로 돌아가 Add Server 또는 Subscribe로 서버 정보를 입력합니다.
3. 노드에 대해 지연 시간 테스트를 한 번 해서 파라미터가 제대로 들어갔는지 확인합니다.
4. 마지막으로 메인 스위치를 켜고 Connectivity Test로 한 번 검증합니다.

순서의 논리는 이렇습니다. 스위치는 '터널을 세우는' 일만 하고, 터널 안이 통하는지는 서버 파라미터와 규칙이 이미 자리를 잡았는지에 달려 있습니다. 정보를 먼저 채우고 스위치를 켜면, 실패했을 때 문제를 파라미터나 네트워크로 좁힐 수 있습니다. 권한, 파라미터, 규칙 세 가지를 동시에 의심하지 않아도 됩니다. 참고로 처음 열 때 언어나 테마를 설정할 필요는 없습니다. 화면은 시스템 언어와 다크 모드를 따르며, 별도의 테마 옵션이 없습니다.

Shadowrocket에 서버 정보를 넣는 경로는 두 가지입니다. Add Server로 한 개씩 직접 입력하거나, Subscribe로 구독 전체를 가져오는 것입니다. 두 경로는 함께 쓸 수 있으며, 이 장에서는 각각의 필드 의미, 업데이트 방식, 자주 틀리는 부분을 정리합니다.

Add Server: 서버 한 개 직접 추가

Home 페이지에서 Add Server를 눌러 파라미터 양식으로 들어갑니다. 첫 항목은 Type이며, 이 선택에 따라 이후에 채워야 할 필드가 달라집니다:

표는 흔한 조합을 보여 주는 예시일 뿐입니다. 필드는 Type과 선택한 전송 방식에 따라 달라지므로 서비스 제공업체가 준 대로 입력하세요. 더 넣거나 덜 넣거나, 다른 화면의 이름을 보고 추측해서 넣는 것이 연결 실패의 가장 흔한 원인입니다. 저장하면 노드가 Home 목록에 나타납니다.

Type 외에도 놓치기 쉬운 부분이 몇 가지 있습니다. Remark(비고)는 표시 이름에만 영향을 주므로 알아보기 쉬운 이름이면 충분합니다. TLS 스위치와 SNI, Path, Host 같은 필드는 서비스 제공업체가 명확히 알려 준 경우에만 채우면 됩니다. 제공업체가 공유 링크나 QR 코드를 준다면 Scan QR Code로 스캔해 가져오는 편이 직접 옮겨 적는 것보다 실수가 적습니다.

Subscribe: 구독 가져오기

구독은 서비스 제공업체가 여러 서버를 하나의 링크로 묶어 제공하고 클라이언트가 주기적으로 가져오는 방식입니다. 진입점은 Home 페이지의 Subscribe입니다. 구독 링크를 붙여 넣고 비고를 적은 뒤 저장하고 Update를 눌러 첫 가져오기를 마칩니다. 가져오기에 성공하면 노드가 그룹 형태로 목록에 나타납니다.

구독 링크는 서비스 제공업체에서 받으며, https://example.com/sub?token=xxxx 같은 형태의 주소입니다. 보통 신원 식별자가 붙어 있어 계정 자격 증명과 같으므로, 공개된 곳에 올리거나 관계없는 사람에게 전달하지 마세요. 이 사이트는 어떤 구독 링크도 제공하지 않으며, 본문에 나오는 주소는 모두 설명용 가짜 값입니다.

구독과 수동 추가의 차이는 업데이트 방식에 있습니다. 구독은 전체를 새로 고칠 수 있어 제공업체가 노드를 조정하면 Update를 한 번 더 누르기만 하면 됩니다. 수동으로 추가한 노드는 자동으로 바뀌지 않으므로 제공업체가 주소를 바꾸면 직접 고쳐야 합니다. 두 방식을 함께 쓸 수 있으며, 보통 자주 쓰는 노드를 수동으로 위에 고정하고 구독 그룹을 아래에 두는 식으로 정리합니다.

구독 업데이트 시점

구독 업데이트에는 두 가지 시점이 있습니다. 수동 업데이트와 Settings에서 켜는 자동 업데이트입니다. 수동 업데이트는 구독 그룹에서 할 수 있으며, 그룹 상세를 열면 Update가 보입니다. 자동 업데이트는 구독 내용이 자주 바뀌는 사용자에게 맞지만, 앱을 실행할 때마다 네트워크 요청이 한 번 더 발생합니다.

업데이트가 실패하면 먼저 '가져오지 못하는 것'인지 '가져왔는데 쓸 수 없는 것'인지 구분하세요. 전자는 보통 링크 만료, token 변경, 또는 현재 네트워크에서 구독 도메인에 접근할 수 없는 경우입니다. 후자는 구독 내용 자체가 바뀐 것이므로 제공업체의 공지를 확인해야 합니다. 전체 점검 순서는 9장에 있습니다.

파일에서 구성 가져오기

한 줄씩 입력하는 방법 외에 Shadowrocket은 구성 파일 가져오기도 지원합니다. .conf 파일을 받은 뒤 시스템 공유 메뉴에서 Shadowrocket을 선택하면 Config 페이지로 가져올 수 있습니다. 구성 파일에는 서버 목록, 규칙, 일반 파라미터가 함께 들어 있을 수 있어 완성된 구성이 이미 있는 사용자에게 적합합니다. 가져온 뒤에는 Config 페이지 상단의 선택 상태를 확인하세요. 구성이 여러 개 있을 때는 선택된 하나만 적용됩니다.

또 하나의 진입점인 Import from Cloud JSON은 클라우드 JSON에서 구성을 복원하는 데 씁니다. 직접 저장해 둔 구성 내용을 읽는 것이며, 노드 구독과는 다른 일입니다.

지연 시간 테스트와 노드 선택

노드 목록의 각 항목에는 지연 시간 수치가 표시되며, 한 번 누르면 다시 측정합니다. 이 숫자는 왕복 한 번에 걸린 시간으로, 같은 시점의 노드를 가로로 비교하는 데만 쓸 수 있고 실제 속도를 나타내지는 않습니다. 대역폭도, 장시간 안정성도 측정하지 않습니다. Connectivity Test는 더 완전한 점검을 수행하며, 결과는 이름 해석, 연결 같은 단계를 구분해 보여 줍니다.

목록은 정렬과 상단 고정을 지원합니다. 일상에서는 안정적인 노드 두세 개를 맨 위에 두면 긴 목록을 매번 뒤지지 않아도 됩니다.

Global Routing은 터널 안 트래픽이 '기본적으로 어디로 갈지'를 결정하며, Shadowrocket에서 가장 잘못 설정하기 쉽고 가장 먼저 이해할 가치가 있는 항목입니다. 모드는 Config, Proxy, Direct 세 가지뿐입니다.

세 가지 관계는 이렇게 이해하면 됩니다. 메인 스위치는 '터널을 열지 말지'를, Global Routing은 '터널 안에서 어떻게 갈지'를 결정합니다. Direct로 바꿔도 인터넷이 끊기지는 않으며, 프록시 서버를 거치는 트래픽이 없어질 뿐입니다. Proxy로 바꿔도 시스템 자체에는 영향이 없고, Bypass 목록에 있는 LAN 주소는 여전히 직접 연결됩니다.

Config 모드: 규칙이 결정한다

Config는 일상 사용에서 유일하게 장기간 유지할 모드입니다. 이 모드에서 Shadowrocket은 Config 페이지의 규칙을 위에서 아래로 읽고, 처음 걸린 규칙이 이 연결을 PROXY, DIRECT, REJECT 중 어디로 보낼지 결정하며 이후 규칙은 관여하지 않습니다. 규칙 작성법과 순서는 5장에서 다룹니다.

Config 모드로 전환하기 전에 Config 페이지에 선택된 구성이 있는지 확인하세요. 구성 파일이 없거나 구성 파일에 규칙이 없으면 Config 모드의 동작은 전적으로 최종 규칙에 맡겨져 결과가 예상과 어긋나기 쉽습니다. '프록시를 켰는데 특정 사이트가 열리지 않는다'는 흔한 원인 중 하나입니다.

Proxy와 Direct: 두 가지 임시 모드

Proxy 모드는 '오늘은 전부 프록시로 보내겠다'는 상황에 맞습니다. Bypass되지 않은 모든 트래픽이 현재 선택된 서버로 나가며 규칙은 판단에 끼지 않습니다. 부작용도 분명합니다. 원래 직접 연결해야 할 LAN 접속, 트래픽을 아껴야 할 근거리 요청까지 한 바퀴 돌게 되어 속도와 데이터 사용량이 모두 달라집니다.

Direct 모드는 '구성을 유지한 채 끈 상태'로 이해하면 됩니다. 터널은 그대로 세워지지만 어떤 트래픽도 프록시로 들어가지 않습니다. 프록시를 잠시 멈추고 싶지만 현재 노드 선택은 유지하고 싶을 때 적합합니다. 쓰고 나면 Config로 되돌리는 것을 잊지 마세요. 그렇지 않으면 다음 연결도 Direct를 그대로 이어 갑니다.

On Demand와의 역할 분담

On Demand(조건부 연결)는 '언제 자동으로 켜고 언제 자동으로 끌지'를, Global Routing은 '켠 뒤에 어떻게 갈지'를 담당합니다. 둘은 서로 직교합니다. On Demand가 셀룰러에서 자동 연결하게 하고, 동시에 Global Routing은 Config 모드로 두어 규칙에 따라 라우팅하게 할 수 있습니다. 이 두 항목을 뒤섞어 조정하는 것이 설정이 점점 엉키는 흔한 출발점입니다.

현재 모드를 확인하는 방법

Home 페이지 상단에 현재 Global Routing 모드가 표시됩니다. 메인 스위치를 켠 뒤 상태 표시줄에 VPN 아이콘이 나타나는 것은 터널이 세워졌다는 뜻일 뿐, 트래픽이 반드시 프록시를 거쳤다는 뜻은 아닙니다. 실제로 프록시를 거쳤는지는 Data 페이지 수치에서 확인합니다(7장).

실용적인 자체 점검 습관 하나: Global Routing이나 규칙을 조정한 뒤에는 규칙에 분명히 적어 둔 도메인을 열고, Data 페이지로 돌아가 그 트래픽이 어느 그룹 수치에 잡히는지 확인한 다음 계속 고칠지 결정하세요.

흔한 오설정 세 가지

• Direct를 '앱 끄기'처럼 오래 켜 두면 구독 업데이트와 노드 속도 측정에 이상이 생깁니다.
• Proxy를 '더 철저한 라우팅'으로 착각하지만, 실제로는 모든 규칙을 우회합니다.
• Config 모드에 최종 규칙이 없으면 어떤 규칙에도 걸리지 않은 트래픽의 경로를 예측하기 어려워집니다.

규칙은 Config 페이지의 구성 파일에 작성하며, 형식은 '유형, 파라미터, 정책' 세 부분으로 통일되어 있습니다. 이 장에서는 각 유형이 무엇을 매칭하는지, 순서가 왜 중요한지 설명하고, 그대로 복사해 쓸 수 있는 최소 조각을 제시합니다.

규칙은 무엇으로 구성되는가

규칙의 기본 구조는 유형, 파라미터, 정책입니다. 유형은 무엇을 기준으로 비교할지 정하고, 파라미터는 비교의 근거이며, 정책은 매칭된 뒤 어떻게 보낼지 결정합니다. 정책은 세 가지입니다. PROXY는 프록시로, DIRECT는 직접 연결, REJECT는 차단입니다. 예를 들어 DOMAIN-SUFFIX,example.com,PROXY는 example.com 및 그 하위 도메인의 요청을 모두 프록시로 보낸다는 뜻입니다.

자주 쓰는 규칙 유형 대조

DOMAIN과 DOMAIN-SUFFIX의 차이는 따로 기억해 둘 만합니다. 전자는 적어 둔 그 도메인 하나만 매칭하고, 후자는 그 하위 도메인까지 함께 매칭합니다. example.com과 www.example.com은 DOMAIN-SUFFIX에서는 규칙 한 줄로 덮이지만, DOMAIN에서는 두 줄을 써야 합니다.

순서: 위에서 아래로, 먼저 매칭된 것이 먼저 적용

규칙 목록에는 순서가 있습니다. Shadowrocket은 첫 줄부터 하나씩 대조하고, 처음 매칭된 규칙이 이 연결의 경로를 결정하며 이후 규칙은 관여하지 않습니다. 여기서 실천 원칙 두 가지가 나옵니다. 첫째, 구체적인 규칙을 넓은 규칙보다 앞에 둡니다. 예를 들어 DOMAIN을 DOMAIN-KEYWORD보다 앞에 둡니다. 둘째, 최종 규칙 FINAL은 반드시 마지막 줄에 두어야 합니다. 그렇지 않으면 뒤의 모든 규칙을 가로막습니다.

GEOIP 규칙은 대상 IP를 먼저 알아야 소속을 판단할 수 있으므로 보통 도메인 계열 규칙 뒤에 옵니다. 도메인으로 판단할 수 있는 것은 먼저 판단하고, 판단할 수 없는 것을 IP 계층에 넘기는 방식입니다. 규칙 순서에서 가장 자주 나오는 질문이 바로 이 부분입니다.

그대로 복사할 수 있는 최소 조각

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,DIRECT
IP-CIDR,203.0.113.0/24,DIRECT
IP-CIDR6,2001:db8::/32,DIRECT
USER-AGENT,Example*,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

이 구성이 표현하는 정책은 이렇습니다. example.com 및 그 하위 도메인은 프록시로 보내되, api.example.com과 example 키워드가 들어간 요청은 예외로 직접 연결합니다. 예시 대역 두 개는 직접 연결, 한국 IP는 직접 연결, 나머지는 모두 프록시로 보냅니다. 도메인과 대역을 자신의 대상으로 바꾸기만 하면 되고 형식은 고칠 필요가 없습니다.

소수의 대상만 프록시로 보내고 나머지를 모두 직접 연결하려면, 최종 규칙을 FINAL,DIRECT로 바꾸고 앞부분에 프록시로 보낼 도메인을 나열하세요:

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,DIRECT
GEOIP,CN,DIRECT
FINAL,DIRECT

두 가지 방식에 우열은 없고 사용 습관에 따라 달라집니다. 전자는 '기본은 프록시, 예외는 직접 연결', 후자는 '기본은 직접 연결, 예외는 프록시'입니다. 하나를 정하면 규칙 목록이 훨씬 명확해집니다.

REJECT와 차단의 경계

REJECT 정책은 매칭된 연결을 막으며, 주로 특정 도메인을 차단하는 데 씁니다. 경계를 분명히 해 둘 필요가 있습니다. 매칭할 수 있는 도메인이나 IP에만 적용됩니다. HTTPS 연결이 막히면 연결 실패나 로딩 시간 초과로 나타나지, '내용이 걸러진' 형태로 나타나지 않습니다. 앱이 자체적으로 보내는 요청, 도메인 프런팅이나 자체 해석을 쓰는 요청은 규칙을 완전히 우회할 수 있습니다. 따라서 REJECT를 범용 차단 수단으로 여기지 마세요. 규칙 수준의 스위치일 뿐입니다. 더 자세한 설명은 이 사이트 블로그 Shadowrocket REJECT 정책: 차단 원리와 경계에 있습니다.

규칙을 수정한 뒤

규칙 변경을 저장한 뒤에는 구성을 다시 불러오게 해야 합니다. Global Routing을 한 번 전환하거나, 메인 스위치를 껐다 켜면 됩니다. 변경량이 많을 때는 새 규칙 하나를 좁은 범위에서 먼저 검증하고, 매칭을 확인한 뒤 일괄 추가하는 편이 좋습니다. 수십 줄을 한꺼번에 쓰고 나서 되짚어 보는 비용이 훨씬 큽니다.

정보를 채우고 규칙이 자리를 잡았다면 연결과 검증이 마지막 단계입니다. 이 장에서는 스위치와 상태를 어떻게 보는지, Connectivity Test가 무엇을 확인하는지, 연결되지 않을 때 어떤 순서로 점검하는지 다룹니다.

연결 켜기와 상태 표시

Home 페이지 하단의 스위치가 메인 스위치입니다. 켜면 시스템 상태 표시줄에 VPN 표시가 나타나고, 앱 안의 스위치도 켜진 상태가 됩니다. 이 두 표시는 터널이 세워졌다는 것만 알려 줄 뿐, 트래픽이 프록시를 거쳤는지는 알려 주지 않습니다. 후자는 Data 페이지 수치와 현재 모드로 확인합니다.

노드 선택은 목록에서 합니다. 노드 행이나 앞의 원을 누르면 현재 노드에 뚜렷한 표시가 붙습니다. 노드를 바꿀 때 스위치를 다시 켤 필요는 없으며, 터널이 새 노드로 다시 세워집니다.

Connectivity Test가 확인하는 것

Connectivity Test는 몇 가지를 순서대로 확인합니다. 도메인 해석이 정상인지, 선택한 서버에 연결할 수 있는지, 그리고 서버를 거쳐 외부 주소에 접근하는 것이 성공하는지입니다. 결과에는 각 단계의 상태가 따로 표시되며, 실패하면 문제가 생긴 첫 단계에서 멈춥니다.

결과를 보는 방법은 위에서 아래로 읽는 것입니다. 해석 실패는 DNS 단계에 문제가 있다는 뜻이고, 연결 실패는 서버 주소, 포트, 프로토콜 파라미터가 맞지 않는다는 뜻입니다. 해석과 연결은 모두 성공했는데 외부 접근이 실패한다면 서버 측 상태 문제일 가능성이 크므로 서비스 제공업체가 제공한 정보를 기준으로 하세요.

라우팅이 실제로 적용되는지 확인하는 방법

라우팅 검증에는 별도 도구가 필요 없고 Data 페이지로 끝낼 수 있습니다:

1. PROXY로 분명히 적어 둔 도메인을 열고, Data 페이지로 돌아가 트래픽이 현재 서버 수치에 잡히는지 봅니다.
2. DIRECT로 분명히 적어 둔 도메인을 열고, 서버 수치가 늘지 않는지 확인합니다.
3. 2단계에서 수치가 함께 오른다면 Config 페이지로 돌아가 규칙 순서를 확인하고, 더 앞선 규칙이 먼저 매칭되지 않았는지 점검합니다.

이 3단계 자체 점검으로 '규칙을 쓴 것 같은데 적용되지 않는다'는 대부분의 상황을 걸러낼 수 있습니다.

연결 실패 시 점검 순서

연결되지 않을 때는 아래 순서대로 하나씩 배제하는 편이 앱을 반복해서 다시 설치하는 것보다 훨씬 효과적입니다:

1. 권한: VPN 구성 승인이 거부되지 않았는지, 시스템 '설정'의 VPN 항목에 해당 구성이 있는지 확인합니다.
2. 파라미터: Address, Port, Password 또는 UUID가 서비스 제공업체가 준 정보와 한 글자씩 일치하는지 대조합니다. 대소문자와 불필요한 공백에 주의하세요.
3. 프로토콜 세부 사항: Type을 제대로 골랐는지, TLS, SNI, Path, Host 같은 필드를 제공업체 설명대로 채웠는지 확인합니다.
4. 시간: 기기 시간이 크게 어긋나면 TLS 핸드셰이크에 영향을 주므로 시간 설정을 자동으로 바꿉니다.
5. 모드: Global Routing이 Direct에 멈춰 있지 않은지 확인합니다.
6. 구독 상태: 노드가 구독에서 온 것이라면 먼저 구독을 한 번 업데이트한 뒤 판단합니다.
7. 네트워크 환경: 다른 네트워크로 바꿔(예: Wi-Fi에서 셀룰러로) 다시 시도해 현재 네트워크의 VPN 제한을 배제합니다.

일곱 단계 중 앞의 네 단계가 대부분의 실패 사례를 덮습니다. 전부 확인해도 안 된다면 Connectivity Test 결과를 서비스 제공업체와 대조하세요. 문제는 대개 서버 측이나 계정 상태에 있으며, 이미 클라이언트가 처리할 수 있는 범위를 벗어난 것입니다.

간헐적 끊김

연결은 되지만 때때로 끊긴다면 보통 네트워크 전환, 노드 부하, 규칙 충돌과 관련이 있습니다. 먼저 끊김이 나타나는 시점을 관찰하세요. Wi-Fi와 셀룰러를 전환할 때 끊긴다면 네트워크 전환으로 터널이 다시 세워지는 경우가 많습니다. 특정 시간대에 끊긴다면 노드 측 문제일 수 있습니다. 특정 앱을 쓸 때만 끊긴다면 그 앱의 도메인이 REJECT에 걸렸는지, 또는 잘못 직접 연결로 지정됐는지 규칙에서 찾아보세요.

Data 페이지는 터널을 지난 트래픽을 두 가지 기준으로 집계합니다. 서버별과 앱별입니다. 이 장에서는 두 수치가 각각 무엇을 집계하는지, 시스템 통계와 왜 맞지 않는지, 그리고 이상 트래픽을 찾는 순서를 설명합니다.

두 가지 수치의 의미

서버별 그룹은 각 노드가 처리한 업로드와 다운로드 트래픽을 집계하며, '트래픽이 어느 회선으로 나가는지' 판단하는 데 씁니다. 여러 노드 중에서 고를 때 가장 직관적입니다. 앱별 그룹은 각 앱이 만든 트래픽을 집계하며, '누가 트래픽을 쓰는지' 판단하는 데 씁니다.

두 수치의 단위는 B, KB, MB, GB이며 1024진법으로 환산하고, 화면에는 보통 업로드와 다운로드를 나눠 표시합니다. 여기서 집계하는 것은 Shadowrocket 터널을 지난 트래픽이며, 기기 네트워크 인터페이스의 전체 송수신이 아니라는 점에 유의하세요.

시스템 통계와 맞지 않는 이유

시스템 '설정'의 셀룰러 통계와 Data 페이지 수치는 자주 일치하지 않는데, 이유는 세 가지입니다:

• 기준이 다름: 시스템 통계는 네트워크 인터페이스 계층의 송수신으로 모든 직접 연결 트래픽과 시스템 자체 요청을 포함합니다. Data 페이지는 터널로 들어온 부분만 집계합니다.
• 집계 구간이 다름: 시스템 통계는 요금 청구 주기나 수동 초기화 구간으로 누적되고, Data 페이지 카운트는 마지막 초기화 또는 설치 시점부터 시작합니다.
• 처리 방식이 다름: 일부 프로토콜은 트래픽을 추가로 캡슐화하므로 터널 안 카운트와 실제 네트워크 인터페이스 카운트 사이에 정상적인 차이가 생깁니다.

세 가지가 겹치면 두 숫자가 다른 것이 정상이며, 이를 보고 '통계가 고장 났다'고 판단할 필요는 없습니다. 요금제 사용량을 판단할 때는 서비스 제공업체 패널의 수치를 기준으로 하세요. Data 페이지는 상대 비교에 더 적합합니다.

이상 트래픽을 찾는 순서

트래픽 소비가 이상하다고 느껴질 때는 '총량 → 서버 → 앱 → 규칙' 순서로 봅니다:

1. 먼저 총량 증가 속도를 보고, 이상이 계속 나타나는지 아니면 특정 기간에 몰려 있는지 확인합니다.
2. 다음으로 서버별 수치를 보고 트래픽을 가장 많이 처리한 노드를 찾습니다.
3. 이어서 앱별 수치를 보고 구체적인 앱을 특정합니다.
4. 마지막으로 Config 페이지로 돌아가, 그 앱의 도메인이 원래 DIRECT로 가야 하는데 앞선 규칙에 걸려 프록시로 끌려가지 않았는지 확인합니다.

4단계는 가장 건너뛰기 쉽지만 가장 성과가 나기 쉬운 단계입니다. '트래픽이 갑자기 늘었다'는 상황의 뿌리는 대개 넓은 규칙 하나가 원래 직접 연결해야 할 요청을 프록시로 끌어들인 것입니다. 관련 수치에 대한 더 자세한 설명은 이 사이트 블로그 Shadowrocket Data 페이지 트래픽 통계 보는 법에 있습니다.

초기화와 기록

Data 페이지에는 초기화 진입점이 있으며, 초기화하면 카운트가 0부터 시작합니다. 규칙을 조정하기 전후에 한 번씩 초기화하고 두 구간의 수치를 비교하면, 누적 숫자를 들여다보는 것보다 변경이 적용됐는지 알아보기 쉽습니다.

마지막으로 한 가지. Data 페이지의 트래픽 통계와 회선 요금제 사용량은 별개입니다. 요금제 잔여량, 청구 주기, 초과 정책은 모두 서비스 제공업체가 정하며 제공업체 패널을 기준으로 하세요. 클라이언트 쪽에서는 자신을 지난 부분만 볼 수 있습니다.

Settings 페이지에는 노드에 따라 변하지 않는 전역 옵션이 모여 있습니다. 이 장에서는 일상에서 실제로 건드릴 만한 몇 가지를 골라, 각각 어떤 문제를 해결하고 언제 바꿔야 하는지 정리합니다.

On Demand: 조건부 연결

On Demand는 앱이 어떤 네트워크 조건에서 자동으로 연결하고 끊을지 결정하며, 트리거 조건은 세 가지로 나뉩니다:

• Wi-Fi: 현재 연결된 Wi-Fi 이름으로 매칭하며, 특정 네트워크에서는 자동 연결, 특정 네트워크에서는 자동 해제를 지정할 수 있습니다.
• 셀룰러: 셀룰러 데이터에서 자동 연결하며, '외출하면 자동으로 켜기' 용도로 자주 씁니다.
• 도메인: 특정 도메인에 접근할 때 연결을 트리거하며, 네트워크가 아니라 목적지 기준으로 판단하는 상황에 맞습니다.

세 가지 조건은 조합할 수 있고, 조합하면 'OR' 관계가 됩니다. 어느 하나만 만족해도 트리거됩니다. 흔한 오설정은 서로 모순되는 두 조건을 넣는 것입니다. 예를 들어 Wi-Fi에서는 해제하라고 하면서 동시에 도메인 기준으로 연결하라고 하면 연결 상태가 반복해서 바뀝니다. 설정을 마친 뒤에는 실제 네트워크 전환 상황에서 한 번 검증해 보세요. 더 자세한 파라미터 설명은 이 사이트 블로그 Shadowrocket On Demand 조건부 연결: Wi-Fi, 셀룰러, 도메인 트리거 설정법에 있습니다.

DNS

DNS 설정은 도메인 해석이 어느 경로로 갈지 결정합니다. 기본값인 시스템 따르기로 대부분의 상황을 충족합니다. 해석 서버를 지정해야 할 때는 이 항목에 주소를 넣을 수 있습니다. DNS를 바꾸면 도메인 계열 규칙의 판단 결과에 직접 영향을 주므로, 바꾼 뒤에는 6장의 3단계 자체 점검으로 한 번 확인하세요.

한 가지 짚어 둘 점. DNS와 라우팅은 두 계층의 논리입니다. 먼저 도메인에 대응하는 주소를 해석하고, 그다음 규칙에 따라 이 연결이 어떻게 갈지 결정합니다. 해석 단계에 문제가 있으면 규칙을 아무리 정확히 써도 적용되지 않습니다.

Bypass와 LAN

Bypass 목록에 있는 주소는 절대 터널로 들어가지 않으며, 흔한 예가 LAN 대역과 로컬 주소입니다. 기본값이 이미 자주 쓰는 사설 대역을 포함하고 있으므로, 분명히 접근해야 할 LAN 서비스가 없다면 바꿀 필요가 없습니다. 공인 주소를 실수로 Bypass에 넣으면 원래 프록시로 가야 할 트래픽이 그대로 나가 버립니다.

구독 자동 업데이트

이 항목은 구독 새로 고침 시점을 제어합니다. 켜면 자동 업데이트, 주기적 자동 업데이트입니다. 구독 내용이 자주 바뀌는 사용자는 켜 두는 편이 좋고, 구독이 안정적인 사용자는 꺼서 앱 실행 시의 네트워크 요청을 줄일 수 있습니다. 스위치 상태와 무관하게 수동 Update는 항상 쓸 수 있습니다.

프록시 포트와 LAN 공유

Shadowrocket은 기기에서 프록시 포트를 열어 같은 LAN의 다른 기기가 쓰게 할 수 있습니다. 켜면 로컬 네트워크 권한을 허용해야 합니다(2장에서 언급한 세 번째 팝업). 사용 목적이 분명한 기능이므로, 정말 다른 기기에 프록시를 제공해야 할 때만 켜고 쓰고 나면 끄세요.

로그와 진단

로그 스위치는 연결 과정을 기록하는 데 씁니다. 까다로운 문제를 점검할 때 켜고, 한 번 재현한 뒤 다시 끄고, 로그 내용을 서비스 제공업체와 대조하세요. 평소에는 꺼 두면 됩니다. 오래 켜 두면 공간만 차지합니다.

iCloud 동기화와 백업

구성은 iCloud를 통해 기기 간에 동기화할 수 있습니다. 켜 두면 기기를 바꿀 때 규칙을 다시 정리할 필요가 없고, 켜지 않아도 사용에는 지장이 없으며 수동으로 내보내기와 가져오기를 하면 됩니다. 어느 방식이든 괜찮지만, 하나를 정해 일관되게 유지해 두 기기의 규칙 버전이 서로 덮어쓰지 않게 하세요.

건드릴 필요 없는 항목

Settings에는 외관, 알림, 실험적 기능과 관련된 스위치도 있습니다. 대부분 합리적인 기본값을 가지고 있으므로, 분명한 필요가 없을 때는 기본값을 유지하는 것이 설정을 예측 가능하게 지키는 가장 간단한 방법입니다. 항목을 바꾸기 전에 '이것이 어떤 문제를 해결하는가'를 먼저 생각해 보세요. 답이 나오지 않는 변경은 보통 몇 주 뒤 새로운 혼란이 됩니다.

마지막 장에서는 일상 관리를 다룹니다. 구독 업데이트 실패는 어떻게 확인하는지, 노드가 작동하지 않을 때 어떻게 처리하는지, 기기를 바꿀 때 어떻게 옮기는지, 그리고 하지 않아도 되는 작업은 무엇인지입니다.

구독 업데이트 실패 점검 순서

1. 링크 자체: 구독 링크에 빠진 글자가 없는지, 만료되지 않았는지, 제공업체가 현재 제공하는 것과 일치하는지 확인합니다.
2. 네트워크 도달 가능성: 구독 도메인 자체가 프록시를 거쳐야 접근할 수 있는 경우가 있으므로, 쓸 수 있는 노드에 먼저 연결한 뒤 업데이트합니다.
3. 반환 형식: 업데이트는 성공했는데 노드 목록이 비어 있다면 반환 내용이 클라이언트가 인식할 수 있는 형식이 아니라는 뜻이므로 제공업체와 확인합니다.
4. 계정 상태: 서비스 제공업체 패널의 상태를 기준으로 하세요. 클라이언트에서는 계정 측 정보를 볼 수 없습니다.

네 단계를 거쳐도 실패한다면 업데이트할 때 본 메시지를 그대로 서비스 제공업체에 보내세요. '안 된다'고 설명하는 것보다 훨씬 효과적입니다. 관련된 흔한 원인은 이 사이트 블로그 Shadowrocket 구독 업데이트: 수동 업데이트, 실행 시 자동 업데이트와 실패 원인에 더 자세히 정리되어 있습니다.

노드가 작동하지 않을 때와 전환

개별 노드에 연결되지 않을 때는 먼저 지연 시간을 한 번 측정하고, 다른 노드로 바꿔 비교합니다. 같은 구독의 여러 노드가 동시에 작동하지 않으면 노드 파라미터를 하나씩 점검하기보다 구독 업데이트가 필요하거나 계정 상태가 바뀌었을 가능성을 먼저 의심하세요. 여러 노드를 자주 오가며 전환하는 것은 안정성을 개선하지 못합니다. 쓸 만한 노드 두세 개를 고정하고 나머지는 예비로 두는 편이 훨씬 수월합니다.

규칙과 구성 관리

규칙은 구성에서 군더더기가 가장 쌓이기 쉬운 부분입니다. 일정 기간마다 한 번씩 정리하는 것을 권합니다. 더 이상 접속하지 않는 도메인 규칙을 지우고, 중복 항목을 합치고, 최종 규칙이 여전히 마지막 줄에 있는지 확인합니다. 수정 전에 현재 구성을 내보내 사본을 남겨 두세요. 구성 파일 자체가 작아 백업 비용은 거의 없습니다.

규칙이 원격 목록을 참조한다면 목록 자체의 업데이트 주기를 살펴보세요. 원격 내용에 접근할 수 없을 때도 로컬에 있는 규칙은 계속 동작하며 연결이 끊기지는 않습니다. 규칙 작성법에 대한 체계적인 설명은 이 사이트 블로그 Shadowrocket 규칙 작성법: DOMAIN, GEOIP, IP-CIDR, FINAL은 각각 무엇을 매칭하는가에 있습니다.

기기 교체와 재설치

새 기기로 옮길 때는 먼저 새 기기에서 같은 Apple ID로 App Store의 구입 항목에서 Shadowrocket을 다시 내려받고, iCloud 동기화나 이전에 백업한 구성 가져오기를 한 뒤, 마지막으로 구독 링크를 다시 입력합니다(구독 링크는 계정 자격 증명에 해당하므로 동기화 범위는 자신의 백업 방식에 따릅니다).

앱을 다시 설치하기 전에 구성이 이미 내보내졌는지 확인하세요. 삭제하면 로컬 구성도 함께 지워지며, 이 단계에는 되돌릴 여지가 없습니다.

앱 업데이트와 시스템 업그레이드

앱 업데이트는 App Store를 통해 이뤄지며 일반 앱과 다르지 않습니다. 시스템 메이저 버전 업그레이드 후 연결 동작이 달라졌다면, 먼저 VPN 구성 승인이 여전히 유효한지 확인하고 6장의 일곱 단계 순서로 한 번 점검하세요. 업그레이드 후 권한이 초기화되는 것은 흔한 현상이며, 앱에 문제가 생긴 것이 아닙니다.

흔한 오해 세 가지

• 클라이언트를 회선으로 착각하기: 앱을 구매했다고 해서 어떤 트래픽도 얻는 것이 아니며, 노드와 구독은 항상 서비스 제공업체에서 옵니다.
• '연결 성공'을 '회선 사용 가능'으로 착각하기: 상태 표시줄 아이콘은 터널이 세워졌다는 뜻일 뿐이고, 실제로 통하는지는 검증 결과를 봐야 합니다.
• 규칙을 만능 스위치로 착각하기: 규칙은 트래픽이 어떻게 갈지 결정할 뿐, 서버 측 상태를 바꾸지도, 서비스 제공업체가 제공하는 서비스를 대신하지도 못합니다.

다음으로 볼 것

이 페이지는 전체 흐름을 다룹니다. 빠르게 실행만 해 보고 싶다면 사용 튜토리얼의 5단계 흐름으로 돌아가세요. 구체적인 문제가 있다면 자주 묻는 질문 페이지에 '정품 확인과 구매 / 설치와 최초 실행 / 구독과 노드 가져오기 / 규칙 라우팅과 문제 해결' 네 가지로 정리된 문답이 있습니다. 특정 주제를 깊이 보고 싶다면 블로그에서 주제별 글을 찾아보세요.