Official Manual / Quick Start
Shadowrocket 사용법
기존 정보 가져오기 → 라우팅 선택 → 연결 → 확인 → 문제 해결
이 페이지는 iPhone과 iPad의 사용 순서에 맞춰 구성했습니다. 먼저 연결 상태를 확인한 다음 규칙과 On Demand를 설정하세요. 프로토콜 항목에 대한 자세한 설명은 프로토콜 참조를 확인하세요.
- 화면 용어는 영어 그대로
- 한 번에 한 항목만 변경
- 먼저 기록한 뒤 조정
Step 01 / Add Server
서버 추가 또는 기존 구독 가져오기
먼저 보유한 정보의 종류를 확인하세요. 서버 목록을 가져오는 구독 링크라면 Subscribe를 사용하고, 개별 서버의 주소와 포트, 인증 정보라면 해당 Type을 선택해 직접 입력합니다. 두 방법 중 하나만 선택하면 됩니다. 구독 링크를 Host와 Password로 나누어 입력하거나 일반 웹사이트 주소를 구독 주소로 사용하지 마세요. 정보가 불분명하면 입력하기 전에 기존 서비스 제공자에게 확인하세요.
Subscribe로 가져오기
Shadowrocket을 열고 Home에서 Add Server를 찾습니다. 들어가서 Type을 누른 뒤 Subscribe를 선택합니다. 추가 화면으로 돌아와 본인이 보유한 구독 링크 전체를 URL에 입력하고 알아보기 쉬운 메모를 적은 다음 화면의 저장 기능을 사용합니다. 복사할 때 링크의 쿼리 매개변수를 유지하고 앞뒤에 잘못 포함된 공백이나 줄바꿈은 제거하세요. 링크에 접근 인증 정보가 포함될 수 있으므로 댓글, 채팅 스크린샷 또는 공개 문서에 게시하지 마세요.
저장하고 콘텐츠를 가져온 뒤 Home으로 돌아가 구독 그룹과 서버 항목을 확인합니다. 그룹 이름만 있고 항목이 없다면 먼저 구독 콘텐츠를 정상적으로 가져왔는지 확인하고, 바로 연결을 시도하지 마세요. 정보가 업데이트되었다면 구독 항목의 업데이트 기능으로 다시 가져온 뒤 예상한 항목이 표시되는지 확인합니다. 가져오기는 연결 매개변수를 클라이언트에 저장하는 과정일 뿐 서버의 사용 가능 여부를 보장하지 않습니다. 연결은 다음 단계에서 별도로 확인해야 합니다.
Add Server에서 직접 입력
Add Server에서 먼저 Type을 선택한 다음 보유한 정보에 맞춰 Host, Port 및 해당 유형의 인증 항목을 입력합니다. 예를 들어 Shadowsocks는 Password와 Method를 확인해야 합니다. 다른 유형은 인증, 전송 또는 TLS 항목이 다를 수 있습니다. 항목 이름이 비슷하다고 서로 바꿔 입력하지 말고 Host에 경로가 포함된 웹 링크를 입력하지 마세요. 서버 주소, 포트, 대소문자 및 암호화 방식은 원본 정보와 일치해야 합니다.
해당 QR 코드가 있다면 Scan QR Code로 정보를 읽을 수 있습니다. Import from Cloud JSON은 해당 형식의 정보를 실제로 보유한 경우에만 사용하세요. 가져온 후에도 항목을 열어 Type과 주요 필드를 확인합니다. 저장한 뒤 Home으로 돌아가 SERVER에서 항목을 찾을 수 있는지 확인하고, 메모를 사용해 다른 항목과 구분하세요. 원본 정보는 그대로 보관하고 다음 단계에서 라우팅을 설정한 뒤 서버를 선택해 연결합니다.
Step 02 / Global Routing
Global Routing 방식 선택
서버 정보를 저장한 뒤 Home으로 돌아가 Global Routing을 누릅니다. 여기서는 트래픽을 어떻게 라우팅할지 결정하며 서버 매개변수를 수정하지는 않습니다. 자주 사용하는 세 가지 방식은 Config(설정)/Proxy(프록시)/Direct(직접 연결)입니다. 현재 목적에 맞는 방식을 선택한 뒤 연결을 켜세요. 서버를 선택했다고 해서 모든 요청이 서버를 거치는 것은 아닙니다.
Config: 현재 설정의 규칙에 따라 매칭
규칙에 따라 라우팅하려면 Config를 선택한 뒤 Config 화면으로 이동해 실제로 사용 중인 구성 파일을 확인합니다. 구성을 열어 Rule과 마지막 기본 규칙을 살펴보세요. 규칙은 일반적으로 순서대로 매칭되므로 구체적인 도메인 규칙을 더 포괄적인 규칙보다 앞에 배치해야 합니다. 앞선 규칙에 매칭되지 않은 요청은 FINAL이 처리합니다. 활성화되지 않은 구성 파일을 수정해도 현재 연결의 라우팅 결과는 바뀌지 않으므로 파일을 먼저 확인한 뒤 내용을 편집하세요.
다음 규칙 예시는 매칭 관계를 설명합니다. example.com과 하위 도메인은 PROXY에 매칭되고, 나머지 요청은 FINAL,DIRECT로 전달됩니다. 규칙 문법만 보여 주는 예시이며 서버 정보는 포함하지 않습니다. 전체 구성 파일을 이 예시로 대체하지 마세요. PROXY의 실제 아웃바운드 선택은 본인의 구성과 Home에서 확인해야 하며, DIRECT는 해당 규칙이 직접 연결을 지정한다는 뜻입니다.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTProxy와 Direct: 현재 경로를 명확히 확인
Proxy는 현재 라우팅을 프록시 방식으로 처리하므로 규칙의 영향을 잠시 배제하고 선택한 서버로 실제 접속이 가능한지 확인할 때 사용할 수 있습니다. Direct는 직접 연결 방식으로 처리하므로 접속에 성공해도 서버가 사용 가능하다는 증거가 되지 않습니다. 테스트 전에는 원래 방식을 기록하고 테스트 후 복원하세요. 그렇지 않으면 ‘방금은 됐는데 규칙을 바꿔도 달라지지 않는다’고 잘못 판단할 수 있습니다.
처음 사용할 때는 DNS, HTTPS Decryption 및 여러 규칙을 동시에 변경하지 않아도 됩니다. 기존 설정을 유지한 채 연결과 확인을 한 번 완료한 다음 항목별로 조정하세요. Shadowsocks, VMess, VLESS, Trojan, WireGuard 또는 Hysteria2의 필드 차이를 비교하려면 프로토콜 참조를 확인하세요. 이 페이지에서는 가져와서 확인을 마친 정보를 계속 사용합니다.
Step 03 / Home
서버 선택 및 연결 켜기
Home으로 돌아가 SERVER 그룹에서 앞서 확인한 서버를 선택하고 선택 표시가 원하는 항목에 있는지 확인합니다. 구독에 여러 항목이 있어도 클라이언트가 사용 가능 여부를 자동으로 판단해 주는 것은 아닙니다. 쉽게 다시 확인할 수 있도록 첫 테스트에서는 항목 하나만 선택하고 메모, 현재 네트워크 및 Global Routing 방식을 기록하세요.
첫 VPN 구성 권한 승인
Home 상단의 연결 스위치를 켭니다. 처음 연결을 설정할 때 시스템에서 VPN 구성을 추가하도록 요청합니다. 시스템 안내를 읽고 Shadowrocket을 대상으로 작업 중인지 확인한 뒤 안내에 따라 허용하고 기기 인증을 완료하세요. 이 권한은 앱이 시스템 네트워크 터널을 설정하는 데 필요하며 구매 상태나 구독 콘텐츠와는 별개의 항목입니다. 권한을 허용한 뒤 앱으로 돌아와 상단 상태가 Not Connected에서 바뀌는지 확인합니다.
방금 시스템 안내를 취소했다면 앱으로 돌아가 연결을 다시 시도하고 권한을 승인하세요. 스위치를 연속해서 반복해서 누르지 마세요. 시스템 설정의 VPN 구성에서도 권한이 설정되었는지 확인할 수 있으며, 메뉴 위치는 시스템 화면에 따라 다를 수 있습니다. 기기가 관리 대상이거나 다른 VPN 연결이 이미 있다면 기기에서 허용하는 구성과 현재 연결 상태도 확인하세요. 모르는 시스템 구성을 바로 삭제하지 마세요.
연결 상태와 접속 확인은 다릅니다
상단에 연결 상태가 바뀌어 표시되더라도 클라이언트의 연결 절차가 해당 상태에 도달했다는 뜻일 뿐, 모든 대상에 접속할 수 있다는 의미는 아닙니다. 서버 인증, 대상 사이트, 규칙 매칭 및 이름 확인은 각각 실패할 수 있습니다. 따라서 스위치를 켠 뒤에는 현재 설정을 유지하고 규칙을 추가하지 않은 채 다음 단계에서 Connectivity Test와 실제 접속을 확인하세요.
스위치를 켠 직후 꺼진다면 당시 안내 문구와 발생 시점을 기록하세요. 시스템 권한을 승인하기 전인지, 승인한 후인지, 연결된 뒤 끊어졌는지 구분합니다. 이 순서를 통해 권한 문제와 연결 매개변수 문제를 구별하는 데 도움이 됩니다. On Demand는 아직 켜지 마세요. 먼저 수동 연결을 확인해 자동 연결 동작이 테스트에 영향을 주지 않도록 합니다.
Step 04 / Connectivity Test
연결 및 규칙 적용 여부 확인
먼저 Home에서 Connectivity Test를 실행하고 테스트가 끝날 때까지 기다린 뒤 결과를 확인합니다. 테스트 성공은 해당 시점의 조건에서 테스트 대상에 요청을 보낼 수 있었다는 뜻이며, 모든 웹사이트와 프로토콜, 서버가 검증되었다는 의미는 아닙니다. 테스트 실패도 서버가 작동하지 않는다는 결론으로 바로 이어지지 않습니다. 테스트 대상, 네트워크 상태 및 라우팅 방식을 함께 살펴보세요.
테스트 결과를 실제 접속으로 확인
선택한 서버와 Global Routing을 그대로 유지한 채 브라우저에서 결과를 확인할 수 있는 대상 페이지를 열고 새로고침해 새로운 콘텐츠가 표시되는지 확인합니다. 새 요청이 발생하지 않은 페이지가 캐시 때문에 정상적으로 보일 수 있으므로 이미 표시된 페이지만으로 연결 성공을 판단하지 마세요. 테스트 중에는 무선 네트워크, 서버, 라우팅 방식을 동시에 바꾸지 마세요. 어떤 항목이 결과를 바꿨는지 알기 어려워집니다.
비교 테스트가 필요하면 먼저 현재 문제를 기록한 뒤 조건 하나만 바꾸고 같은 요청을 다시 실행합니다. 예를 들어 서버는 그대로 두고 Config에서 Proxy로 잠시 전환합니다. 결과가 달라지면 모든 인증 정보를 다시 입력하기보다 규칙, 구성 및 해당 설정의 의존 항목을 확인하세요. 비교를 마친 뒤 원래 방식으로 복원하고 예상한 사용 방식으로 다시 테스트합니다.
Config에서 PROXY와 DIRECT를 각각 확인
Config를 사용할 때는 PROXY로 라우팅될 것으로 예상되는 대상과 DIRECT로 라우팅될 것으로 예상되는 대상을 각각 하나 이상 확인합니다. Data에서 해당 시점에 생성된 새 연결 기록을 열고 기록에 표시된 대상 주소, 매칭 규칙 및 실제 정책을 확인하세요. 요청 직후 기록을 찾으면 오래된 연결 기록을 보고 추측하는 것보다 원인을 파악하기 쉽습니다. 필요한 경우 테스트 시간과 대상 도메인을 기록하세요.
정책이 예상과 다르면 먼저 현재 파일이 실제로 적용 중인지 확인한 다음 더 앞에 있는 포괄적인 규칙이 먼저 매칭되는지 살펴봅니다. 도메인 규칙은 웹페이지 제목이 아니라 요청에 연결된 도메인에 매칭됩니다. 한 페이지에서 여러 도메인에 요청할 수도 있으므로 페이지가 열린다고 해서 모든 리소스가 예상대로 라우팅되었다는 뜻은 아닙니다. 확인을 마치면 성공한 서버, 라우팅 방식 및 구성 이름을 기록해 이후 조정의 기준으로 삼으세요.
검증을 마치면 답할 수 있어야 할 세 가지
- 현재 Home에서 선택한 서버는 무엇이며 Global Routing 방식은 무엇인가요?
- Connectivity Test와 실제 페이지 접속 결과는 각각 어떠했나요?
- Config를 사용한다면 연결 기록의 정책이 현재 규칙과 일치하나요?
Step 05 / Settings
문제가 발생한 단계부터 설정 확인
모든 설정을 처음부터 다시 하지 말고 방금 멈춘 단계부터 확인하세요. 현재 구성을 저장하고 오류 메시지와 재현 조건을 기록한 뒤 한 번에 한 항목만 변경합니다. 변경 후에는 같은 테스트를 반복하세요. Settings에서 Test Method, On Demand, Diagnostics 등을 확인할 수 있지만, 이런 설정이 서버 측의 올바른 매개변수를 대신하지는 않습니다. 모든 스위치를 한꺼번에 조정하지 마세요.
구독 가져오기 실패 또는 항목이 표시되지 않음
Add Server로 돌아가 Type이 Subscribe인지, URL 전체가 정확한지, 공백이나 줄바꿈이 들어갔거나 매개변수가 누락되지는 않았는지 확인합니다. 현재 네트워크에서 구독 콘텐츠를 가져올 수 있는지 확인하고 서비스 제공자가 안내한 정보가 여전히 유효한지도 확인하세요. 구독 주소와 구독에 포함된 서버의 연결 주소는 서로 다릅니다. 구독 업데이트에 실패해도 저장된 서버가 모두 사용할 수 없는 것은 아니며, 기존 항목으로 연결할 수 있다고 해서 업데이트 주소에 접속할 수 있다는 뜻도 아닙니다.
스위치가 꺼지거나 연결 시간 초과
스위치가 꺼지면 시스템 VPN 권한과 현재 VPN 상태를 먼저 확인합니다. 연결 시간이 초과되면 기기의 기본 네트워크가 정상인지 확인한 다음 Type, Host, Port 및 인증 항목을 하나씩 점검하세요. TLS 또는 특정 전송 방식을 사용하는 항목은 원본 정보와 해당 항목을 비교해야 합니다. 비밀번호만 확인해서는 충분하지 않습니다. 인증서나 인증 판단에 영향을 주지 않도록 시스템 날짜와 시간이 정확한지도 확인하세요.
Settings에서 Test Method를 확인해 현재 테스트 방식을 파악한 뒤 결과를 비교합니다. 특정 테스트는 실패했지만 실제 요청은 성공했다면 테스트 대상과 방식을 먼저 분석하고, 한 가지 결과만으로 정보를 삭제하지 마세요. 단서를 더 확인하려면 Diagnostics에서 방금 재현한 작업과 관련된 진단 정보를 살펴봅니다. 서버 하나만 실패한다면 해당 항목의 정보와 서버 상태를 추가로 확인하세요.
연결은 되었지만 접속 또는 라우팅 결과가 예상과 다름
먼저 Home으로 돌아가 Global Routing을 확인하세요. Direct 상태인데 요청이 Proxy를 거칠 것으로 기대하고 있지 않은지 살펴봅니다. Config를 사용한다면 활성화된 파일, 규칙 순서 및 FINAL의 정책을 확인한 뒤 Data의 기록을 함께 살펴보세요. 특정 대상만 실패하면 대상 주소와 발생 시간을 기록합니다. 모든 대상이 실패하면 도메인 규칙을 추가하기 전에 기본 네트워크와 서버 연결부터 확인하세요.
수동 스위치 동작이 예상과 다르면 On Demand가 켜져 있는지, 자동 연결 조건이 설정되어 있는지 확인합니다. 처음 문제를 해결할 때는 수동 연결 방식으로 돌아가 결과가 안정적인지 확인한 뒤 필요에 따라 On Demand를 설정하세요. 문제 해결을 위해 Proxy, TCP, UDP 등의 여러 항목을 동시에 변경하지 마세요. 각 항목이 영향을 주는 범위가 다르므로 변경할수록 원인을 파악하기 어려워집니다.
정보를 보존한 뒤 추가 확인
기존 서비스 제공자에게 확인할 때는 프로토콜 유형, 오류 증상, 테스트 시간 및 이미 확인한 내용을 전달하면 됩니다. 스크린샷이나 진단 정보를 공유하기 전에 구독 링크, 비밀번호, 인증 식별자 및 기타 연결 인증 정보를 가리세요. 자세한 프로토콜 매개변수는 프로토콜 참조에서 확인하세요. 연결 절차를 다시 확인하려면 추가 및 가져오기로 돌아가되, 이미 올바른 것으로 확인한 항목은 유지하고 모든 항목을 반복해서 다시 만들 필요는 없습니다.
