Shadowrocket
사용법

Shadowrocket을 열고 Home으로 이동해 Add Server를 찾습니다. 시작하기 전에 가지고 있는 정보가 구독 주소, 단일 서버 공유 정보, 전체 구성 파일 중 무엇인지 확인합니다. 구독은 여러 서버 항목을 관리하는 데 사용하고, 단일 서버 매개변수는 하나의 연결을 만듭니다. 구성 파일에는 규칙과 기타 설정이 포함될 수 있습니다. 각 정보의 용도는 서로 다르므로 전체 구성 내용을 Host에 입력하거나 웹 안내 페이지 주소를 구독 주소로 입력하지 마세요.

구독 링크가 있는 경우: Subscribe 선택

Add Server에서 Type을 누르고 Subscribe를 선택한 다음, 본인의 전체 구독 링크를 해당 주소 입력란에 붙여 넣고 내용을 확인한 뒤 저장합니다. 주소의 경로, 매개변수, 대소문자는 원본 그대로 유지해야 합니다. 복사하는 과정에서 공백, 줄바꿈, 한글 문장 부호가 섞이지 않았는지 특히 확인하세요. 구독 주소에 접속 정보가 포함될 수 있으므로 공개 댓글, 스크린샷 또는 공개 로그에 올리지 마세요.

저장한 뒤 Home으로 돌아가 구독 내용을 가져올 때까지 기다립니다. 해당 그룹에 서버 항목이 표시되는지 확인하세요. 구독 그룹만 보이고 선택 가능한 항목이 없다면 구독 업데이트 결과를 먼저 확인해야 합니다. 저장에 성공했다고 서버를 가져온 것까지 확인된 것은 아닙니다. 이후 구독을 업데이트하기 전에 항목에 적용한 로컬 변경 사항을 확인하세요. 원격 내용을 다시 가져오면 항목과 매개변수가 달라질 수 있습니다.

서버 정보가 있는 경우: Type에 맞게 항목 입력

단일 서버 매개변수가 있다면 Add Server의 Type에서 원본 정보와 일치하는 프로토콜을 선택한 다음 Host, Port 및 필요한 인증 항목을 입력합니다. 공식 스크린샷에는 Password와 Method가 포함된 양식이 표시되어 있지만, Type마다 필요한 항목이 다르며 모든 프로토콜에 같은 내용을 입력하는 것은 아닙니다. Host에는 일반적으로 서버 도메인이나 주소를 입력하며 웹 페이지 경로를 임의로 추가하지 마세요. Port는 원본의 숫자를 그대로 입력하고 Password, Method 등은 자료와 하나씩 대조합니다.

선택한 Type에 TLS, 전송 방식 또는 다른 매개변수가 필요한 경우에도 보유한 정보를 그대로 사용하세요. 이름만 보고 값을 추측하지 마세요. WireGuard처럼 항목 구성이 다른 프로토콜에 Password와 Method를 스크린샷대로 억지로 입력하지 마세요. QR 코드로 된 정보는 Scan QR Code를 사용할 수 있습니다. Import from Cloud JSON은 해당 형식의 기존 자료에만 사용하며, 임의의 링크를 붙여 넣는 일반 입력란이 아닙니다.

저장한 뒤 Home으로 돌아가 SERVER 또는 해당 구독 그룹에서 새 항목을 찾아 사용할 항목을 선택합니다. 이때 중복 항목을 여러 개 가져오거나 모든 매개변수를 동시에 변경하지 마세요. 출처가 명확하고 입력 항목을 확인할 수 있는 설정 하나를 유지하면 다음 단계에서 연결을 확인하기 쉽습니다. 가져온 결과가 예상과 다르면 라우팅 모드를 설정하기 전에 정보 유형이나 항목 입력 문제부터 해결하세요.

서버를 추가한 뒤 Home으로 돌아가 Global Routing을 누릅니다. 여기서 자주 사용하는 세 가지 모드는 구성(Config), 프록시(Proxy), 직접 연결(Direct)입니다. 먼저 이번 테스트의 목적을 정한 뒤 모드를 선택하세요. 서버를 선택한 상태와 모든 요청이 해당 서버를 통과하는 상태를 혼동하지 마세요. 모드에 따라 요청 처리 방식이 달라지므로 문제 해결 시 확인해야 할 주요 설정입니다.

Config: 현재 구성의 규칙에 따라 처리

평소 규칙에 따라 트래픽을 분기하려면 구성(Config)을 선택한 다음 Config 페이지에서 현재 사용 중인 구성 파일을 확인합니다. 구성 파일 목록과 파일 편집 페이지는 서로 다른 단계입니다. 먼저 현재 사용 중인 파일을 확인한 뒤 열어서 내용을 살펴보세요. 다른 파일을 편집해도 현재 연결에는 적용되지 않을 수 있습니다. 공식 스크린샷에는 General, Rule, Hosts, URL Rewrite, HTTPS Decryption 등의 섹션과 Add Rule이 표시된 구성 파일 편집 페이지가 나옵니다.

처음에는 Rule에 해당하는 규칙부터 확인하세요. 규칙은 보통 위에서 아래로 일치 여부를 확인하며, 일치하는 규칙의 정책을 적용합니다. 앞선 규칙에 하나도 일치하지 않을 때 FINAL로 처리를 마무리합니다. PROXY, DIRECT, REJECT는 각각 프록시 처리, 직접 연결, 요청 거부를 뜻합니다. 구성 파일에는 다양한 옵션이 들어갈 수 있지만 설정이 많다고 해서 모두 변경해야 하는 것은 아닙니다. 특히 첫 연결을 테스트할 때 목적과 관계없는 기능을 켜지 마세요.

# 독립적인 설명용 예시입니다. 이해한 뒤 본인의 구성에 반영하세요
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,DIRECT

위 예시는 example.com 및 하위 도메인을 PROXY로 보내고, 나열된 로컬 네트워크 대역은 DIRECT로 처리하며, 나머지 요청은 FINAL,DIRECT로 처리합니다. 규칙의 일치 순서를 설명하기 위한 예시이지, 현재 사용 중인 구성 파일 전체를 그대로 바꾸라는 뜻은 아닙니다. 예시 도메인은 연결할 서버가 아니며 PROXY가 서버 항목을 자동으로 만들지도 않습니다. 변경하기 전에 현재 파일을 백업해 기존 규칙을 덮어쓰지 않도록 하세요.

Proxy와 Direct: 차이 이해 및 비교 테스트

프록시(Proxy)는 라우팅 요청을 주로 프록시 방식으로 처리하므로 일반적인 분기 규칙이 테스트 결과에 미치는 영향을 일시적으로 제외할 때 유용합니다. 다만 이를 근거로 모든 시스템 트래픽이 반드시 프록시를 통과한다고 판단해서는 안 됩니다. 직접 연결(Direct)은 요청을 직접 연결 방식으로 처리하므로 선택한 프록시 서버가 정상이라는 증거로 사용할 수 없습니다. Proxy에서는 접속되지만 Config에서는 안 된다면 현재 구성과 적용된 규칙을 먼저 확인하세요. 두 모드에서 모두 실패한다면 서버 매개변수와 네트워크 상태를 확인합니다.

모드를 선택한 뒤 현재 사용 중인 구성 파일, 서버, Global Routing 모드를 기록해 둡니다. 이후 한 번에 조건 하나만 변경해야 원인을 파악하기 쉽습니다. 규칙 유형, 우선순위, 구성 섹션에 대한 자세한 설명은 규칙 및 구성 참고를 확인하세요. 이 페이지에서는 변경을 최소화하고 연결을 진행합니다.

앞의 두 단계를 마친 뒤 Home으로 돌아가 현재 선택된 서버 항목과 Global Routing을 다시 확인합니다. 구독에 항목이 여러 개 있으면 가져오기를 완료해도 예상한 서버가 선택되지 않았을 수 있습니다. 사용할 항목을 누르고 선택 상태를 확인한 다음 상단의 연결 스위치를 조작하세요. 서버를 바꾸고 규칙을 편집하면서 스위치를 반복해서 켜고 끄지 마세요. 어떤 단계에서 상태가 바뀌었는지 확인하기 어려워집니다.

최초 연결 시 표시되는 시스템 안내

상단에 Not Connected가 표시되면 연결 스위치를 켭니다. 처음 사용할 때 시스템에서 VPN 구성을 추가하라는 안내가 나타날 수 있습니다. Shadowrocket에서 직접 시작한 작업이 맞는지 확인하고 안내를 읽은 뒤 허용한 다음 시스템 요구에 따라 기기 인증을 완료합니다. 이 권한은 앱에 필요한 네트워크 터널을 만드는 데 사용됩니다. 구독을 가져오는 데 성공했다는 뜻도, 서버 검증이 완료됐다는 뜻도 아닙니다. 이전에 권한 요청을 취소했다면 연결을 다시 켤 때 시스템 안내가 다시 표시되는지 확인하세요.

스위치를 켜자마자 다시 꺼지면 먼저 처리하지 않은 시스템 팝업이 있는지 확인한 다음 현재 항목이 유효한지 살펴봅니다. 기기 시스템 설정의 VPN 관련 항목에서 구성이 있는지, 기기 관리 제한이 적용되는지 확인할 수도 있습니다. 익숙하지 않은 다른 구성은 함부로 삭제하지 마세요. 관리되는 기기라면 기기 관리 정책에 따라 처리해야 하며, 스위치를 반복해서 켜는 것만으로 권한 문제를 해결할 수는 없습니다.

연결 상태와 사용 가능 여부를 따로 확인

권한 설정을 마친 뒤 상태가 바뀔 때까지 기다립니다. 연결이 설정되는 동안 스위치를 연속해서 누르지 마세요. 시스템에 VPN 상태가 표시되거나 앱에서 연결이 켜진 것으로 보여도 해당 터널의 상태만 확인된 것입니다. 모든 대상에 접속할 수 있다는 뜻은 아닙니다. 프록시 인증 오류, 대상의 DNS 확인 실패, 예상과 다른 규칙 적용은 스위치가 켜진 상태에서도 발생할 수 있습니다. 따라서 다음 단계에서 Connectivity Test를 실행하고 실제 접속도 확인해야 합니다.

처음 확인할 때는 현재 네트워크를 안정적으로 유지하고 Wi-Fi와 셀룰러 네트워크를 일부러 오가며 전환하지 마세요. VPN 연결을 만드는 다른 기기 기능을 사용 중이라면 시스템에서 현재 어떤 기능이 실제로 연결되어 있는지 먼저 확인합니다. 연결이 대체된 상황을 서버 문제로 오해하지 않도록 주의하세요. 테스트 후 연결을 끄려면 Home으로 돌아가 상단 스위치를 끄고 연결 해제 상태로 바뀌었는지 확인합니다.

연결이 유지되면 다음 단계에서 실제 요청을 확인합니다. 계속 연결되지 않으면 문제 원인 확인으로 이동해 권한과 기본 설정부터 점검하세요. 연결이 설정되지 않은 상태에서는 규칙에 따른 분기가 예상대로 작동하는지 판단할 수 없으므로 Rule을 여러 개 변경하는 것은 첫 번째 해결 방법으로 적절하지 않습니다.

문제를 해결하기 전에 어느 단계에서 실패했는지 확인합니다. 항목을 가져오지 못했는지, 스위치가 켜진 상태를 유지하지 못하는지, 테스트와 실제 접속이 모두 실패하는지, 일부 대상만 실패하는지, 네트워크를 전환한 뒤 연결이 끊기는지 구분하세요. 증상을 나누어 확인하면 반복해서 삭제하고 다시 만드는 것보다 원인을 파악하기 쉽습니다. 아래 순서에 따라 기본 항목부터 구체적인 항목까지 확인하고, 이미 정상임을 확인한 단계는 매번 다시 변경할 필요가 없습니다.

가져오기 실패: 원본 정보부터 확인

Subscribe를 저장한 뒤에도 항목이 표시되지 않으면 링크가 완전한지, 해당 주소가 아직 유효한지, 현재 기본 네트워크에서 구독 내용을 가져올 수 있는지 확인합니다. 구독을 가져오는 과정과 서버에 연결하는 과정은 서로 별개입니다. 기존 항목으로 연결할 수 있다고 해서 업데이트 주소에도 접속할 수 있다는 뜻은 아닙니다. 직접 추가한 뒤 연결되지 않으면 Type, Host, Port, 인증 항목, 전송 매개변수를 원본 정보와 하나씩 대조하세요. 기억에 의존해 다시 입력하거나 Method를 무작위로 바꾸며 해결하려 하지 마세요.

연결 실패: 권한, 기본 네트워크, 매개변수 확인

스위치가 바로 꺼지면 시스템 VPN 권한 또는 구성 제한부터 확인합니다. 스위치가 켜져 있지만 모든 테스트에 실패한다면 먼저 연결을 끄고 기기 자체의 네트워크가 정상인지 확인한 뒤 다시 연결해 테스트합니다. 가능하다면 본인이 사용할 수 있는 다른 네트워크로 바꿔 비교해 보세요. 특정 네트워크에서만 실패한다면 그 차이를 기록하고 원래 정상인 매개변수를 모두 바꾸지 마세요. 서버 인증과 전송 조건은 본인이 가진 정보와 대조해야 합니다.

일부 대상만 실패: 모드와 규칙 확인

일부 대상에서만 문제가 생기면 먼저 Global Routing을 확인한 뒤 Config와 Proxy의 결과를 비교합니다. 현재 파일의 관련 DOMAIN, DOMAIN-SUFFIX, IP-CIDR, FINAL 규칙에서 순서와 정책을 확인하고, 특히 앞쪽 규칙이 먼저 일치하는지 살펴봅니다. DNS와 관련된 문제라면 현재 구성을 기록하고 오류 증상을 확인한 뒤 관련 설정을 살펴봅니다. DNS 변경이 모든 연결 문제를 해결하는 것은 아닙니다.

Settings: 테스트 조건과 자동 연결 동작 확인

Settings에서 Test Method를 열어 현재 문제를 확인하는 데 적합한 테스트 방법인지 살펴봅니다. 방법에 따라 결과가 다를 수 있습니다. 방법을 바꾼 뒤에는 테스트 조건이 달라졌다는 점을 기록하고, 두 결과를 같은 방식으로 측정한 값처럼 직접 비교하지 마세요. Language에서 화면 언어를 확인할 수 있습니다. Today Widget은 기본 연결을 설정하는 데 필요한 항목이 아니므로 시작 단계의 테스트에서 먼저 변경할 필요는 없습니다.

On Demand는 조건이 충족될 때 연결을 어떻게 시작할지 결정하며 서버 매개변수나 Rule을 대신하지 않습니다. 네트워크를 전환한 뒤 자동 연결 동작이 예상과 다르다면 기존 On Demand 조건을 확인합니다. 먼저 수동 연결로 기본 연결 경로가 정상인지 확인한 다음 자동 연결 조건을 조정하세요. 연결 실패 한 번을 해결하기 위해 모든 자동 동작을 동시에 켜지 마세요. 무엇이 재연결을 시작했는지 확인하기 어려워집니다.

Diagnostics에서 문제 해결 정보를 확인할 수 있습니다. 공유하기 전에 서버 주소, 접속 대상, 인증 관련 정보가 포함되어 있는지 살펴보세요. Settings의 Proxy, TCP, UDP는 추가 확인을 위한 항목이며 모두 변경해야 한다는 뜻은 아닙니다. 특정 프로토콜 관련 옵션은 본인의 구성 조건에 맞춰 확인하세요. 스크린샷에 옵션 이름이 표시되어 있다는 이유만으로 기본값을 변경하지 마세요.

정상 연결을 복구한 뒤 설정 정리

설정을 변경할 때마다 이전과 같은 대상과 방법으로 다시 테스트합니다. 개선되지 않으면 원래 설정으로 되돌린 뒤 다음 항목을 확인하세요. 효과가 있는 조정을 찾았다면 그 이유를 기록하고 테스트 중 만든 중복 항목을 정리한 뒤 Global Routing과 On Demand가 원래 예상한 상태로 돌아왔는지 확인합니다. 더 복잡한 구성 섹션, 규칙 우선순위, 정책 작성 방법은 규칙 및 구성 참고에서 확인하세요. 처음부터 작업 순서를 다시 확인하려면 추가 및 가져오기로 돌아가 이 페이지의 순서대로 점검합니다.