Official Manual / Quick Start
Shadowrocket 사용법
기존 자료를 바탕으로 가져오기, 모드 선택, 연결, 확인을 차례로 진행합니다. 이 페이지에서는 처음 사용할 때 필요한 기본 절차를 안내합니다. 규칙 원리와 Settings 전체 항목은 설정 안내서에서 확인할 수 있습니다.
완료 기준은 스위치가 켜졌는지가 아닙니다. 자료가 저장되고, 모드가 용도에 맞으며, 테스트 대상에 접속할 수 있고, 요청에 적용된 정책이 예상과 일치해야 합니다. 처음 설정할 때는 먼저 서버 하나로 전체 절차를 확인한 뒤 나머지 항목을 정리하면 문제가 발생한 단계를 찾기 쉽습니다.
Step 01 / Add Server
서버 추가 또는 Subscribe 가져오기
Shadowrocket을 열고 Home으로 이동한 다음 SERVER 그룹 근처에서 Add Server를 찾습니다. 보유한 자료의 종류를 먼저 확인하세요. 서버 목록을 가져오는 구독 링크라면 Subscribe를 사용하고, 서버 주소·포트·프로토콜·인증 정보가 있다면 직접 추가합니다. 두 방법 모두 기존 자료를 앱에 저장하는 절차이며, 저장만으로 새로운 서비스를 만들 수는 없습니다.
구독 링크가 있다면: Subscribe 선택
Add Server에서 Type을 열고 Subscribe를 선택한 다음, 기존 구독 링크 전체를 URL에 입력하고 저장합니다. 붙여넣은 뒤 링크의 시작과 끝, 쿼리 매개변수가 온전한지 확인하세요. 복사 과정에서 공백이나 줄바꿈이 들어가거나 문자가 빠지지 않았는지도 살펴보세요. 구독 주소에는 접속 정보가 포함되는 경우가 많으므로 일반 웹 주소처럼 공개적으로 공유하거나 공개 게시판에 전체 주소를 올리지 마세요.
Home으로 돌아와 구독 정보가 불러와질 때까지 기다립니다. 구독 그룹은 표시되지만 서버 항목이 나타나지 않는다면 해당 그룹의 업데이트 기능을 사용하고 실패 안내가 있는지 확인하세요. URL을 저장할 수 있다는 것은 입력을 받아들였다는 뜻일 뿐, 원격 정보를 정상적으로 가져왔다는 의미는 아닙니다. 오류가 발생하면 원본 링크가 온전한지, 현재 네트워크에서 정보를 가져올 수 있는지, 기존 서비스가 여전히 유효한지 먼저 확인하세요. 같은 구독을 반복해서 추가하지 마세요.
서버 한 대의 정보가 있다면: 항목별로 입력
Add Server에서 보유한 정보에 맞는 Type을 선택하고 Host와 Port를 입력합니다. 프로토콜에 따라 화면에 표시되는 항목이 달라집니다. 스크린샷의 Password와 Method는 입력 양식의 한 예일 뿐, 모든 프로토콜에서 같은 항목을 사용하는 것은 아닙니다. 서비스 정보에 기재된 인증 방식, 암호화 방식 및 기타 필수 매개변수를 항목별로 입력하세요. 이름이 비슷하다는 이유로 프로토콜을 선택하거나 포트 번호를 Host에 입력하지 마세요.
가져올 수 있는 QR 코드가 있다면 Scan QR Code를 사용할 수 있습니다. 자료 형식이 실제로 해당 기능에 맞는 경우에만 Import from Cloud JSON을 사용하세요. 가져온 뒤에도 Type, 주소, 포트를 확인해야 합니다. QR 코드가 인식됐다고 해서 모든 항목이 올바른 것은 아닙니다. 저장한 뒤 Home으로 돌아와 테스트할 서버를 선택하고 선택 표시를 확인하세요. 이어서 Global Routing을 설정한 다음 연결을 시작하면 모드 문제를 가져오기 실패로 오해하는 일을 줄일 수 있습니다.
Step 02 / Global Routing
Global Routing 모드 선택
Home으로 돌아가 Global Routing을 엽니다. 처음 사용할 때는 세 가지 항목을 구분해야 합니다. 서버 항목에는 연결 정보가 저장되고, Config에는 규칙과 구성 매개변수가 저장되며, Global Routing은 현재 사용할 전체 처리 방식을 결정합니다. 구독을 가져왔다고 규칙 파일까지 가져온 것은 아닙니다. SERVER에서 항목 하나를 선택해도 어떤 웹사이트가 프록시를 사용할지 자동으로 정해지지는 않습니다.
- 구성(Config): 현재 활성화된 구성 파일의 규칙을 적용합니다. 대상과 정책을 구분해야 하는 일반적인 사용에 적합합니다.
- 프록시(Proxy): 일반 요청을 프록시 방식으로 처리합니다. 선택한 서버를 비교해 확인할 때 사용할 수 있지만, 모든 트래픽이 반드시 같은 경로로 나간다는 보장은 아닙니다.
- 직접 연결(Direct): 일반 요청을 직접 연결 방식으로 처리합니다. 기본 네트워크를 확인할 때 적합하며 프록시 서버의 정상 작동 여부를 검증하는 데는 사용할 수 없습니다.
규칙에 따라 트래픽을 분리하려면 구성(Config)을 선택한 뒤 Config로 이동해 현재 활성화된 파일을 확인하세요. 사용할 파일이 선택되어 있는지 확인합니다. 목록에 방금 가져왔지만 아직 활성화하지 않은 다른 파일을 보고 있는 것은 아닌지 살펴보세요. 스크린샷의 General, Rule, Hosts, URL Rewrite, HTTPS Decryption은 구성 편집 영역입니다. 처음 설정할 때는 Rule과 파일 선택부터 확인하면 됩니다. 연결을 시작하기 위해 모든 영역을 하나씩 수정할 필요는 없습니다.
규칙 하나부터 이해한 뒤 전체 구성 조정하기
규칙은 보통 순서대로 확인하며 일치하는 규칙이 있으면 해당 정책을 적용합니다. 다음은 구문 설명을 위한 예시입니다. example.com은 예시 도메인으로, 테스트 대상으로 방문하라는 의미가 아니며 완전한 구성을 대체할 수 있는 내용도 아닙니다. 첫 번째 줄은 해당 도메인과 하위 도메인에 PROXY를 사용하고, 마지막의 FINAL은 앞선 규칙과 일치하지 않는 요청에 DIRECT를 사용합니다.
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTAdd Rule로 규칙을 추가할 때는 구체적인 대상을 기본 처리 규칙보다 앞에 둡니다. 웹페이지가 열리지 않는다는 이유만으로 모든 규칙을 PROXY로 바꾸지 말고, 용도를 이해하지 못한 상태에서 HTTPS Decryption도 변경하지 마세요. 수정 전에는 기존 구성을 보관하고, 저장한 뒤 올바른 파일이 활성화되어 있는지 확인하세요. 구성 구조, DNS, 규칙 순서에 대한 자세한 설명은 Settings 및 구성 설정 안내서를 참고하세요. 이 단계를 마치면 Home으로 돌아가 연결을 준비합니다.
Step 03 / Home
연결을 시작하고 시스템 승인 확인
Home에서 서버 선택 표시와 현재 Global Routing 값을 다시 확인합니다. 스크린샷 상단의 Not Connected는 아직 연결되지 않았다는 뜻입니다. 상단 스위치를 눌러 연결을 시작하세요. 처음 사용할 때 시스템에서 VPN 구성을 추가하도록 허용할지 물을 수 있습니다. 이 VPN 구성은 기기의 관련 요청을 Shadowrocket이 처리하도록 전달하기 위한 것이며, 구매나 구독 갱신 절차가 아닙니다.
안내가 현재 작업에 대한 것인지 확인한 뒤 시스템의 요구에 따라 승인하세요. 기기 암호나 신원 확인을 추가로 요청할 수 있습니다. 완료되면 Shadowrocket으로 돌아와 스위치와 상태 문구가 바뀌었는지 확인합니다. 이전에 승인을 취소했다면 앱에서 다시 연결을 시작하고 시스템 안내에 따라 권한을 확인하세요. 같은 승인 문제를 해결하려고 앱을 반복해서 삭제하지 마세요.
스위치 상태와 서비스 이용 가능 여부는 따로 확인
연결 스위치가 켜진 상태를 유지하면 기기에서 해당 연결 절차가 시작된 것입니다. 하지만 이것만으로 서버에 접속할 수 있는지, 인증 정보가 유효한지, DNS가 정상인지, 규칙이 올바르게 적용됐는지를 확인할 수는 없습니다. 시스템에 VPN 상태가 표시되더라도 다음 단계에서 실제 접속을 확인해야 합니다. 상태가 곧바로 미연결로 돌아오면 화면에 표시된 안내를 기록하고 시스템 승인과 현재 구성을 불러올 수 있는지 확인한 다음 문제 해결 절차를 진행하세요.
첫 테스트에서는 네트워크 환경을 그대로 유지하고 Wi-Fi 전환, 규칙 수정, 서버 교체를 동시에 하지 마세요. 그래야 결과가 달라졌을 때 원인을 방금 수행한 작업으로 좁힐 수 있습니다. iPad와 iPhone은 화면 배치가 다를 수 있지만 Home, Global Routing, 연결 스위치 순서로 확인하면 됩니다. 연결한 뒤에는 우선 On Demand를 조정하지 마세요. 수동 연결이 정상인지 확인한 다음 자동 연결이 필요한지 결정하세요.
Step 04 / Connectivity Test
서버와 규칙의 적용 여부 확인
먼저 Home에서 Connectivity Test를 실행해 선택한 서버를 확인합니다. 테스트 결과는 Settings의 Test Method와 관련이 있습니다. 방식에 따라 확인하는 단계가 다르므로 한 번의 테스트 성공이 모든 웹사이트의 접속을 보장하지 않으며, 한 번의 실패만으로 인증 정보가 잘못됐다고 단정할 수도 없습니다. 테스트 대상이 현재 사용할 항목인지 확인한 다음 실제 접속 결과와 함께 판단하세요.
실제 요청으로 예상한 동작 확인
- 브라우저를 열고 정상적으로 접속할 수 있는 것으로 알려진 페이지에 방문합니다. 이전에 캐시된 페이지 내용만 보지 말고 이번 요청이 완료될 때까지 기다리세요. 필요한 경우 페이지를 새로고침하거나 아직 열어 본 적이 없는 페이지를 이용합니다.
- 구성(Config)을 사용한다면 PROXY를 사용해야 하는 대상과 DIRECT를 사용해야 하는 대상을 하나씩 테스트하세요. 한쪽만 테스트하고 전체 규칙이 적용됐다고 판단하지 마세요.
- 앱에서 확인할 수 있는 연결 기록이나 로그를 살펴보고 대상 도메인, 발생 시각, 적용 정책을 대조하세요. 기록이 있다면 이번 요청에 해당하는지 확인합니다. 이전 기록을 방금 적용된 결과로 착각하지 마세요.
- 페이지는 열리지만 정책이 예상과 다르다면 Config로 돌아가 현재 파일과 규칙 순서를 확인하세요. 정책은 예상대로 적용되지만 접속에 실패한다면 서버와 대상 서비스 자체를 점검합니다.
Data의 트래픽 변화는 데이터 활동이 있었다는 보조 단서일 뿐, 특정 도메인이 PROXY를 사용했다는 증거는 아닙니다. 기기의 다른 요청도 트래픽을 발생시킬 수 있으며, 출구 주소의 변화 역시 테스트한 요청의 결과만 보여줍니다. 규칙을 확인하려면 특정 대상을 정해 새 요청을 보내고 해당 요청에 적용된 정책을 확인하세요. 특정한 테스트 수치를 맞추는 데 집중할 필요는 없습니다.
완료 후 현재 네트워크, 선택한 서버, Global Routing, 활성화된 Config, 테스트 대상을 기록해 두세요. 이후 설정을 변경할 때 같은 대상으로 다시 테스트하면 달라진 점을 파악하기 쉽습니다. 결과가 예상과 일치하면 평소처럼 사용하면 됩니다. 테스트와 실제 접속 결과가 다르다면 고급 매개변수를 더 바꾸기 전에 아래 문제 해결 절차를 진행하세요.
Step 05 / Settings
일반적인 실패 원인을 순서대로 확인
문제를 해결할 때는 기본 사항을 먼저 확인하고 규칙은 나중에 살펴보며, 한 번에 하나씩만 변경하세요. 변경할 때마다 같은 테스트를 다시 실행해 결과를 확인한 다음 다음 단계로 넘어갑니다. 구독 교체, 서버 변경, DNS 및 규칙 수정을 한꺼번에 하면 접속이 복구되어도 원인을 알기 어렵고 이후 관리도 더 복잡해집니다.
자료가 표시되지 않음: 가져오기 결과 확인
Home에 예상한 서버가 없다면 저장된 구독으로 돌아가 URL과 업데이트 안내를 확인하세요. 서비스 정보가 여전히 유효하고 현재 네트워크에서 내용을 가져올 수 있는지도 살펴봅니다. 직접 추가한 항목은 Add Server로 돌아가 Type, Host, Port, 인증 항목을 확인하세요. Password 앞뒤에 공백이 없는지, 표시 이름을 서버 주소로 착각하지 않았는지도 확인합니다. 구독 문제에 대한 자세한 내용은 자주 묻는 질문을 참고하세요.
스위치는 켜졌지만 접속 실패: 네트워크와 모드 구분
먼저 연결을 잠시 끊고 같은 네트워크에서 정상적으로 열리는 것으로 알려진 페이지에 접속해 기본 네트워크가 작동하는지 확인하세요. 웹페이지에서 완료해야 하는 네트워크 접속 절차가 있다면 먼저 마칩니다. 그런 다음 다시 연결하고 현재 서버와 Global Routing을 확인하세요. Direct를 잘못 선택했다면 그 결과로 프록시가 정상 작동하는지 확인할 수 없습니다. Config를 선택했다면 다른 파일이 활성화되어 있지 않은지, 대상이 DIRECT 또는 REJECT 규칙에 일치하지 않았는지 확인하세요.
가능하고 영향을 이해하는 경우에는 같은 대상을 대상으로 Proxy로 잠시 전환해 비교한 뒤 원래 모드로 되돌릴 수 있습니다. Proxy에서는 접속되지만 Config에서 실패한다면 구성과 적용 정책을 우선 확인하세요. 둘 다 실패한다면 서버, 인증 정보, 대상 서비스도 점검해야 합니다. 이 비교 결과만으로 DNS 문제라고 단정할 수는 없습니다.
일부 대상만 실패: DNS와 테스트 방식 확인
일부 도메인만 실패한다면 대상 서비스 자체가 정상인지, 규칙 범위가 지나치게 넓지 않은지 먼저 확인한 다음 구성의 DNS 관련 매개변수를 살펴보세요. 인터넷에서 본 주소 목록을 기존 설정에 바로 덮어쓰지 마세요. 원래 값을 보관하고 한 항목만 수정한 뒤 다시 테스트합니다. Settings의 Test Method는 테스트 방식을 결정할 뿐 모든 웹사이트의 실제 요청 방식을 바꾸지는 않습니다. 테스트 방식만 바꿔 브라우저 접속 문제를 해결할 수는 없습니다.
연결이 자동으로 다시 시작됨: On Demand 확인
수동으로 연결을 끊은 뒤 다시 연결된다면 Settings의 On Demand와 설정된 트리거 조건을 확인하세요. 문제를 점검하는 동안에는 관련 자동 트리거를 잠시 중지한 뒤 수동으로 테스트할 수 있습니다. Today Widget은 바로가기로 사용할 수 있지만 Home에서 최종 상태를 확인하는 절차를 대신하지 않습니다. Proxy, TCP, UDP 영역에는 세부 동작 설정이 있으므로, 처음 연결할 때 명확한 필요가 없다면 기존 설정을 유지하세요.
원인을 찾기 어려움: 필요한 진단 정보만 보관
Diagnostics 또는 관련 로그 기능을 사용할 때는 문제가 발생한 직후 확인하고 시간, 대상, 모드, 오류 안내를 기록하세요. 기록을 저장하거나 전달하기 전에 구독 URL, 서버 인증 정보, 개인을 식별할 수 있는 내용을 가립니다. 문제 판단에 필요한 부분만 제공하고 전체 구성을 공개하지 마세요. 로그와 설정 항목에 관한 시스템 안내는 설정 안내서를 참고하세요. 특정 문제를 확인했다면 FAQ에서 해당 해결 방법을 찾아보세요.
Next / Keep a Working Baseline
사용 가능한 구성을 보관하고 항목별로 조정
처음 설정을 마친 뒤 정상 작동을 확인한 구성을 보관하고 선택한 서버와 Global Routing을 기록해 두세요. 구독을 업데이트한 뒤에는 서버 목록이 바뀌었는지 확인하고, 규칙을 수정한 뒤에는 정해 둔 대상으로 정책을 검증하세요. Settings를 변경할 때는 해당 항목이 영향을 미치는 범위를 먼저 확인합니다. 자료 유효성, 연결 여부, 규칙 적용 여부를 각각 따로 판단하면 불필요한 재가져오기와 수정을 줄일 수 있습니다.
평소에는 기존 서버만 바꾸면 전체 절차를 반복할 필요가 없습니다. 구성을 다시 가져오거나 자동 연결을 조정해야 할 때 해당 장으로 돌아오세요. 더 자세한 내용은 Settings 설정 항목 안내를 참고하고, 구체적인 오류가 발생하면 자주 묻는 질문 및 문제 해결 안내를 확인하세요.