공식 매뉴얼 / 시작 안내
Shadowrocket 사용법
기존 구독 가져오기, Global Routing 선택 및 연결 확인 방법을 안내합니다. 먼저 확인 가능한 연결을 한 번 설정한 다음 규칙과 자동 연결 설정을 조정합니다.
기본 순서는 “추가 → 연결 방식 선택 → 연결 → 확인 → 문제 해결”입니다. 공식 스크린샷은 항목과 메뉴 위치를 확인하기 위한 자료입니다. 실제 화면은 기기와 앱에 따라 다를 수 있으므로 영어 인터페이스 용어를 기준으로 찾아보고, 스크린샷에 나온 연결 정보를 그대로 복사하지 마세요.
01 / Add Server · Subscribe
서버 추가 및 기존 구독 가져오기
보유한 정보가 구독 링크인지 서버 매개변수인지 먼저 확인하세요. 정보 유형에 따라 입력 방법이 다릅니다.
Shadowrocket을 열고 Home에서 SERVER 그룹과 Add Server 메뉴를 찾습니다. 기존 구독 링크가 있다면 먼저 기존 서비스 제공처에서 전체 링크를 복사한 뒤 Add Server를 누르고 Type에서 Subscribe를 선택합니다. 추가 화면으로 돌아오면 링크를 해당 URL 항목에 입력합니다. 링크의 시작 부분, 경로, 끝부분의 매개변수가 모두 포함되었는지 확인한 다음 저장합니다. 구독 링크에는 보통 인증 정보가 포함되므로 개인 연결 정보로 취급하고 공개 댓글이나 스크린샷에 붙여 넣지 마세요.
구독을 저장한 뒤 로딩이 끝날 때까지 기다리고 Home으로 돌아가 SERVER에 구독 그룹과 서버 항목이 표시되는지 확인합니다. 구독 이름만 표시되고 선택할 항목이 없다면 가져오기 또는 업데이트 중 표시된 오류를 먼저 확인하세요. 곧바로 연결 스위치를 켜지 마세요. 목록이 비어 있는 원인으로는 링크 누락, 만료된 구독, 현재 네트워크에서 구독을 읽을 수 없는 경우, 요구 형식에 맞지 않는 응답 등이 있습니다. 같은 링크를 반복해서 추가하면 중복 그룹만 늘어날 수 있으며, 기존 읽기 문제는 해결되지 않습니다.
Add Server에 직접 입력하기
서버 주소, 포트 및 인증 매개변수를 보유한 경우 Add Server의 Type에서 해당 정보가 지정하는 프로토콜을 선택합니다. Subscribe를 선택하지 마세요. 그런 다음 Host, Port와 해당 프로토콜에 필요한 항목을 하나씩 확인합니다. 예를 들어 Shadowsocks에서는 Password와 Method를 확인해야 합니다. 다른 프로토콜에는 다른 인증 또는 전송 설정이 표시될 수 있습니다. 모든 항목에 공통으로 적용되는 기본값은 없으므로 한 프로토콜의 비밀번호, 암호화 방식 또는 전송 옵션을 다른 프로토콜에 그대로 적용하지 마세요.
Host에는 서버 정보에 지정된 주소를 입력하고 Port에는 해당 정보의 포트 번호를 입력합니다. 복사할 때 앞뒤 공백, 줄바꿈, 전각 문장 부호에 특히 주의하세요. 비밀번호의 대소문자와 특수 문자도 원래대로 유지해야 합니다. 정보에 TLS, 서버 이름 또는 추가 전송 매개변수가 기재되어 있으면 해당 옵션도 확인해야 합니다. 주소와 포트만 입력했다고 설정이 완료되는 것은 아닙니다. 확인되지 않은 항목은 옵션을 무작정 바꾸기 전에 원래 정보를 제공한 곳에 문의하세요.
가져올 수 있는 QR 코드가 있다면 Scan QR Code를 사용할 수 있습니다. 호환되는 Cloud JSON이 명시적으로 제공된 경우에만 Import from Cloud JSON을 사용하세요. 저장한 뒤 Home으로 돌아가 SERVER에서 사용할 서버 항목을 누르고 선택 표시가 해당 항목에 있는지 확인합니다. 구독 그룹이 표시되는 것만으로 서버가 선택된 것은 아닙니다. 항목이 표시되면 추가는 완료된 것이며, 다음으로 연결에 사용할 Global Routing 방식을 선택해야 합니다.
02 / Global Routing · Config
연결 방식 및 규칙 구성 선택
서버는 연결 경로를 결정하고 Global Routing은 요청을 처리하는 방식을 정합니다. 구독을 가져왔다고 적절한 규칙 구성이 함께 적용되는 것은 아닙니다.
Home으로 돌아가 Global Routing을 눌러 현재 선택을 확인합니다. 연결 방식은 Config, Proxy, Direct 세 가지입니다. Config는 현재 구성 파일의 규칙에 따라 동작을 정합니다. Proxy는 해당 요청을 선택된 프록시 경로로 보내 서버를 집중적으로 확인할 때 사용할 수 있습니다. Direct는 현재 네트워크를 통해 요청을 직접 보냅니다. 이 설정들은 요청 처리 방식만 바꾸며, 만료된 서버 인증 정보를 보완하거나 연결할 수 없는 서버 주소를 수정하지는 않습니다.
처음 연결을 확인할 때 이미 검증한 구성 파일이 있다면 Config를 선택한 다음 실제로 사용 중인 Config 파일을 확인합니다. 규칙이 올바른지 확인되지 않았다면 Proxy를 임시로 사용해 기존 서버를 테스트한 뒤 Config로 돌아와 트래픽 분할을 확인할 수 있습니다. Direct는 기본 네트워크와 비교할 때 유용하지만, Direct 경로에서 접속에 성공해도 해당 요청이 직접 연결 경로에서 동작한다는 의미일 뿐 프록시 서버가 정상 작동한다는 증거는 아닙니다.
Config를 확인하고 모든 규칙을 서둘러 바꾸지 마세요
Config로 이동해 현재 구성 파일을 확인합니다. 편집 화면에서 General, Rule, Hosts, URL Rewrite, HTTPS Decryption 항목을 확인할 수 있습니다. 처음에는 Rule과 현재 선택된 구성에 집중하고 모든 기능을 하나씩 켤 필요는 없습니다. 구독은 일반적으로 서버 항목을 관리하고 Config는 연결 처리 방식을 정의합니다. 두 항목이 모두 기존 자료에서 제공되었더라도 각각 확인해야 합니다. SERVER에 서버가 표시된다고 해서 Rule 설정까지 완료된 것은 아닙니다.
규칙은 일반적으로 위에서 아래 순서로 일치 여부를 확인하며, 먼저 일치한 규칙이 연결 동작을 결정합니다. PROXY는 프록시 정책으로 전달하고, DIRECT는 직접 연결하며, REJECT는 요청을 거부합니다. 아래는 문법 예시일 뿐 모든 사용자에게 적합한 완전한 구성은 아니며 사용할 수 있는 서버 정보도 포함하지 않습니다. 특히 PROXY가 참조하는 정책은 실제 구성에서 사용할 수 있어야 합니다. 규칙 몇 줄만 복사해도 프록시 경로가 자동으로 만들어지지는 않습니다.
DOMAIN-SUFFIX,example.comPROXYGEOIP,CNDIRECTDOMAIN-KEYWORD,adsREJECT
Add Rule을 사용하기 전에 현재 Config를 내보내거나 사본을 보관하고, 한 번에 하나씩 수정하면서 목적을 기록하세요. 연결 확인이 끝나기 전에 Rule, Hosts, HTTPS Decryption을 동시에 변경하면 문제 원인을 찾기 어렵습니다. DOMAIN-SUFFIX, GEOIP 및 기타 키워드의 일치 범위는 용어 설명에서 확인할 수 있습니다. 연결 방식과 구성을 확인한 뒤 Home으로 돌아가 처음 연결을 시도합니다.
03 / Home · Not Connected
연결 스위치 켜고 시스템 허용 완료
연결하기 전에 서버와 Global Routing을 다시 확인하세요. 스위치 상태와 서버 사용 가능 여부는 각각 확인해야 합니다.
Home으로 돌아가 SERVER에서 선택된 항목이 이번에 테스트할 서버인지 확인한 다음 Global Routing이 앞 단계에서 선택한 상태인지 확인합니다. 점검을 마치면 상단의 Not Connected 옆 연결 스위치를 켭니다. 처음 연결할 때 시스템에서 VPN 구성을 추가하라는 메시지가 표시될 수 있습니다. 안내를 읽고 허용한 다음 기기 안내에 따라 시스템 확인을 완료하고 Shadowrocket으로 돌아옵니다. 시스템 확인이 끝나기 전에 스위치를 연달아 누르면 한 번의 승인 과정을 연결 실패로 잘못 판단할 수 있습니다.
시스템 VPN 구성은 지정된 범위의 트래픽을 앱으로 전달하는 데 사용됩니다. 구성을 추가하도록 허용해도 서버 인증이 성공했다는 의미는 아닙니다. Home으로 돌아간 뒤 상단 연결 상태가 바뀌었는지, 스위치가 켜진 상태로 유지되는지 먼저 확인합니다. 방금 켰는데 바로 꺼진다면 표시된 안내를 기록하고 시스템 구성이 추가되었는지, 기기가 관리 제한을 받는지, 네트워크를 제어하는 다른 VPN 연결이 있는지 확인하세요. 재시도를 위해 기기의 모든 네트워크 설정을 한꺼번에 삭제하지 마세요.
연결 상태가 유지된다면 매개변수를 더 변경하지 마세요. 현재 서버, 연결 방식, 네트워크 조건을 그대로 유지하고 다음 단계에서 확인합니다. 나중에 비교할 수 있도록 선택한 서버 이름과 Global Routing을 기록해도 되지만 비밀번호나 전체 구독 링크는 기록하지 마세요. 스위치가 켜져 있다는 것은 앱의 연결 상태가 설정되었다는 의미입니다. 원격 서버의 응답, 웹페이지 접속 가능 여부, 규칙 일치 여부는 실제 요청으로 확인해야 합니다.
04 / Connectivity Test · Data
테스트 결과 및 실제 요청 확인
세 가지를 확인합니다. 앱의 연결 유지, 서버 경로의 응답, 대상 요청에 예상한 동작 적용 여부입니다.
Home에서 Connectivity Test를 누르고 이번 테스트가 끝날 때까지 기다립니다. 테스트 결과는 특정 테스트 방식과 대상의 연결 상태를 확인하기 위한 것이며 모든 웹사이트와 앱에 접속할 수 있다는 뜻은 아닙니다. 한 번 시간 초과가 발생했다고 서버가 영구적으로 작동하지 않는다고 단정할 수도 없습니다. 현재 조건을 그대로 둔 채 한 번 더 테스트해 결과가 일치하는지 확인합니다. Test Method를 바꾸면 별도의 테스트로 취급하고, 두 테스트에 표시된 수치를 같은 지표로 직접 비교하지 마세요.
그런 다음 브라우저를 열어 정상적으로 접속할 수 있을 것으로 예상되는 페이지를 방문하고 새로고침합니다. 로컬 캐시만 표시되는 상황을 피하려면 가능한 한 새 요청을 사용하세요. 이어서 앱으로 돌아와 Data의 연결 기록을 확인하고 요청 시간과 대상 도메인을 바탕으로 방금 접속한 기록을 찾습니다. 기록에 일치한 규칙이나 정책 정보가 표시되면 구성 의도와 맞는지 확인합니다. 직접 연결을 예상한 요청은 DIRECT를 사용했는지, 프록시 연결을 예상한 요청은 PROXY로 전달되었는지, REJECT가 먼저 일치하지 않았는지 살펴봅니다.
Proxy에서는 접속되지만 Config에서 같은 대상에 접속되지 않는다면 구독을 바로 다시 가져오기보다 Rule 순서, 정책 참조, 도메인 확인을 먼저 점검합니다. 두 연결 방식에서 모두 실패하면 서버와 네트워크 경로를 계속 확인합니다. 페이지의 일부 리소스만 완전히 로드되지 않는다면 해당 리소스의 개별 도메인도 살펴보세요. 메인 페이지 접속과 모든 리소스 접속은 같은 결과가 아닙니다.
Data의 트래픽 수치가 증가하는 것은 요청이 기록되거나 처리되었다는 의미일 뿐, 특정 요청이 올바른 경로를 통과했다는 것을 단독으로 증명하지는 않습니다. 확인이 끝나면 정상 작동이 확인된 구성을 보관하고 일상적으로 필요한 연결 방식으로 단계적으로 되돌립니다. 자동 연결이 필요하다면 On Demand의 조건을 살펴보세요. 먼저 수동 연결을 확인한 뒤 자동 실행을 추가하면 실행 조건 문제와 서버 문제를 구분하기 쉽습니다.
05 / Settings · Diagnostics
문제가 발생한 단계별로 확인
한 번에 하나의 변수만 변경하세요. 오류 메시지와 재현 조건을 보존하면 모든 구성을 반복해서 삭제하는 것보다 원인을 찾기 쉽습니다.
가져온 뒤 서버가 표시되지 않는 경우
먼저 연결을 끄고 기본 네트워크에서 정상 페이지에 접속할 수 있는지 확인한 다음 기존 구독의 URL 전체가 입력되었는지, 만료되지 않았는지, 공백이 포함되지 않았는지 확인합니다. 구독 업데이트 실패와 서버 연결 실패는 서로 다른 단계의 문제입니다. 전자는 아직 항목을 읽어오지 못한 상태이고, 후자는 항목은 있지만 사용 가능한 연결 경로를 만들지 못한 상태입니다. 서버 항목이 없을 때 Global Routing부터 조정하지 마세요. 기존 정보를 다시 발급받거나 접근을 복구해야 한다면 원래 정보 제공처에 문의하고, 전체 구독 링크를 모르는 사람에게 보내지 마세요.
항목은 있지만 테스트가 계속 시간 초과되는 경우
항목 편집 화면을 열어 원래 정보와 Type, Host, Port 및 인증 항목이 일치하는지 확인하고 프로토콜에 필요한 Method, TLS 또는 전송 매개변수도 점검합니다. 기기의 시스템 시간이 정확한지 확인하세요. 시간 차이가 크면 보안 연결에 영향을 줄 수 있습니다. 그런 다음 가능한 경우 Wi-Fi와 셀룰러 네트워크에서 같은 항목을 각각 테스트합니다. 매번 네트워크만 바꾸고 프로토콜은 동시에 변경하지 마세요. 특정 네트워크에서만 실패하면 해당 네트워크 경로를 먼저 확인하고, 모든 네트워크에서 실패하면 매개변수와 원격 서버의 사용 가능 상태를 중점적으로 확인합니다.
스위치는 켜졌지만 대상에 접속할 수 없는 경우
Global Routing을 다시 확인합니다. Direct를 잘못 선택하면 스위치가 켜져 있어도 프록시가 필요한 요청이 자동으로 프록시를 사용하지 않습니다. Config를 사용하는 경우 앞선 REJECT 규칙에 일치했는지, 사용할 수 없는 정책으로 전달되었는지 확인합니다. Proxy로 잠시 전환해 비교한 다음 테스트가 끝나면 원래 연결 방식으로 돌아갈 수 있습니다. 문제를 가리기 위해 모든 규칙을 바로 끄지 말고, 한 대상에 접속할 수 없다는 이유만으로 앱 전체가 작동하지 않는다고 판단하지 마세요.
Settings에서 문제 해결 단서 확인
Settings로 이동해 먼저 Test Method가 현재 테스트 목적에 맞는지 확인합니다. 추가 단서가 필요하면 Diagnostics의 진단 정보를 살펴봅니다. On Demand, Proxy, TCP, UDP 등의 설정은 각각 다른 단계에 영향을 줍니다. 처음 문제를 해결할 때 여러 설정을 동시에 바꾸지 마세요. 연결이 반복해서 자동으로 켜진다면 기존 On Demand 조건을 먼저 확인합니다. 특정 트래픽 유형만 실패한다면 모든 설정을 초기화하는 대신 해당 항목을 중심으로 확인합니다.
기록에는 “어느 단계에서 실패했는지, 당시 연결 방식, 사용한 네트워크, 표시된 원래 안내, 이미 시도한 비교 방법”을 명확히 적습니다. 진단 스크린샷을 공유하기 전에 구독 주소, 비밀번호, 인증 매개변수와 개인 연결 정보를 가리세요. 세부 문제는 자주 묻는 질문에서 확인할 수 있으며, 스토어 지역, 구매 및 재설치는 App Store 안내를 참고하세요. 문제 해결을 마치면 정상 작동이 확인된 구성으로 복원하고 불필요한 변경을 더하지 마세요.