Shadowrocket 사용법

01 · Add Server: 추가 및 가져오기

Shadowrocket을 열고 Home으로 이동한 다음 SERVER 영역에서 Add Server를 찾거나 화면의 추가 버튼을 사용합니다. 먼저 보유한 정보의 종류를 확인하세요. 구독 링크는 여러 서버를 가져오고 관리하는 데 사용하며, 단일 서버 정보는 프로토콜과 인증 설정을 각각 입력해야 합니다. 둘은 입력 방식이 다르므로 구독 URL을 서버의 Host에 입력하지 마세요.

기존 서버 정보가 있는 경우: 먼저 Type 선택

Add Server를 연 다음 Type을 눌러 보유한 정보와 일치하는 프로토콜을 선택합니다. 이어서 Host와 Port를 입력하고, 선택한 Type에 표시되는 인증 항목을 채웁니다. 예를 들어 Shadowsocks는 일반적으로 Password와 Method를 확인해야 합니다. 다른 프로토콜은 필요한 항목이 다르므로 이전 프로토콜의 입력 방식을 그대로 적용하지 마세요.

Host에는 서버 도메인이나 주소를, Port에는 해당 포트를 입력하고 인증 정보는 원래 설정 그대로 빠짐없이 복사합니다. 앞뒤 공백, 줄바꿈, 대소문자를 확인하세요. TLS, 전송 방식, 서버 이름 등의 항목도 기존 설정에 따라 입력해야 하며, 이름이 비슷하다는 이유로 임의로 추측하지 마세요. 입력을 마치면 저장하고 Home으로 돌아가 SERVER 목록에 새 항목이 표시되는지 확인합니다. 항목이 보인다는 것은 저장이 완료됐다는 뜻일 뿐이므로, 다음 단계에서 연결을 테스트해야 합니다.

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

서비스 제공업체에서 받은 구독 링크가 있다면 추가 화면에서 Type을 Subscribe로 설정하고 해당 URL 입력란에 전체 링크를 입력합니다. 알아보기 쉬운 메모를 추가한 뒤 저장하세요. 경로와 쿼리 매개변수도 URL의 일부이므로 도메인만 복사하면 안 됩니다. 계정 관리 페이지 주소는 일반적으로 구독 가져오기에 사용할 수 없습니다. 저장 후 Home으로 돌아가 구독을 가져올 때까지 기다린 다음 해당 그룹과 서버 항목을 확인합니다.

QR 코드가 있다면 Scan QR Code를 사용하세요. 코드를 읽은 뒤 저장하기 전에 해석된 유형과 내용을 확인합니다. Import from Cloud JSON은 별도의 가져오기 메뉴이며, 아무 웹 주소나 사용할 수 있다는 뜻은 아닙니다. 보유한 자료 형식에 맞는 방법만 선택하고, 가져오기를 성공시키려고 관련 없는 유형을 반복해서 바꾸지 마세요.

이 단계가 끝나면 Home에서 선택할 수 있는 서버가 하나 이상 보여야 합니다. 목록이 비어 있으면 연결 실패를 VPN 승인 문제로 여기지 말고 먼저 구독 가져오기 실패 문제 해결을 확인하세요. 구독 링크에는 계정 식별 정보가 포함될 수 있으므로 개인적으로 안전한 곳에 보관하고, 공개 스크린샷이나 게시물, 공유 문서에는 올리지 마세요.

02 · Global Routing: 연결 방식 선택

서버를 저장한 다음 Home으로 돌아가 Global Routing을 엽니다. 여기서는 요청을 처리할 방식을 선택합니다. SERVER 목록에서 서버를 선택하는 것과는 별개의 설정입니다. 단일 서버를 테스트할지 기존 규칙을 적용할지 먼저 정한 뒤 구성(Config), 프록시(Proxy), 직접 연결(Direct) 중 하나를 선택하세요.

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

Config를 선택하면 현재 적용 중인 구성과 규칙에 따라 요청 경로가 결정됩니다. Config 화면에서 선택된 구성 파일을 확인한 다음 규칙 내용을 살펴보세요. 공식 스크린샷의 General, Rule, Hosts 등은 서로 다른 구성 항목입니다. 파일이 목록에 표시된다고 해서 선택되어 적용 중이라는 뜻은 아닙니다.

처음 사용할 때는 Rule의 규칙 순서, 정책 이름, 마지막 기본 처리 방식을 중점적으로 확인하세요. 예를 들어 DOMAIN-SUFFIX는 도메인 접미사를 기준으로 일치 여부를 판단하고, FINAL은 앞선 규칙에 일치하지 않은 요청을 처리합니다. 규칙이 DIRECT를 지정하면 요청은 선택한 프록시 서버를 거치지 않고, REJECT를 지정하면 요청이 거부됩니다. 이런 결과를 곧바로 서버 장애로 판단해서는 안 됩니다.

프록시(Proxy)와 직접 연결(Direct): 테스트 목적 구분

Proxy를 선택하면 프록시로 처리되는 요청이 선택한 프록시 경로를 사용하므로, 문제를 점검할 때 규칙 분기의 영향을 줄이는 데 도움이 됩니다. 실제 동작은 앱 설정과 시스템 트래픽 범위에도 영향을 받습니다. Direct는 직접 연결에 사용되며 선택한 서버의 사용 가능 여부를 확인하는 방법은 아닙니다. 연결 스위치가 켜져 있어도 모든 요청이 프록시를 사용하는 것은 아니므로 Global Routing과 실제 정책을 함께 확인하세요.

이 안내에서는 먼저 현재 연결 방식을 기록할 것을 권장합니다. 보존해야 할 규칙이 없다면 Proxy로 단일 서버를 확인한 뒤 필요에 따라 Config로 돌아가세요. 정상적으로 사용 중인 구성이 있다면 기존 파일을 유지하고 덮어쓴 뒤 복구하려고 하지 마세요. 일반 연결을 확인하기 위해 HTTPS Decryption을 켜거나 인증서를 추가로 설정할 필요는 없습니다. 이 안내에 필수적인 단계가 아닙니다. 프로토콜 설정과 선택 기준은 프로토콜 안내서에서 확인할 수 있습니다.

03 · Home: 연결 켜기

이제 Home으로 돌아가 SERVER 목록에서 사용할 서버를 선택하고, 선택 표시가 원하는 항목에 있는지 확인합니다. 구독 그룹에 항목이 여러 개라면 그룹 이름을 실제 서버로 착각하지 마세요. 이어서 Global Routing을 다시 확인해 앞에서 선택한 방식과 일치하는지 살펴본 다음 화면 상단의 스위치를 켭니다.

처음 연결할 때 시스템에서 VPN 구성을 추가하도록 허용할지 묻는 메시지가 표시될 수 있습니다. 시스템 알림을 읽고 Shadowrocket이 시작한 요청인지 확인한 다음 안내에 따라 허용하고 기기에서 요구하는 인증을 완료하세요. 이는 시스템이 VPN 구성을 관리하도록 승인하는 절차이며, 서버의 Password 입력란에 기기 암호를 입력하는 것이 아닙니다. 승인을 취소하면 Home으로 돌아와도 연결이 예상대로 설정되지 않습니다. 다시 시도해 승인을 완료해야 합니다.

승인한 뒤 앱으로 돌아와 상단 상태가 Not Connected에서 바뀌는지, 스위치가 켜진 상태로 유지되는지 확인합니다. 곧바로 연결이 끊기면 안내 메시지를 기록하고 문제 해결 단계로 이동하세요. 스위치를 빠르게 반복해서 켜고 끄지 마세요. 연결 상태로 표시되면 다음 단계에서 확인합니다. 이 시점에서 알 수 있는 것은 연결 절차가 시작됐다는 사실뿐이며, 대상 서비스가 사용 가능하다고 단정할 수는 없습니다.

기기에서 다른 VPN 연결이 실행 중이라면 먼저 어떤 구성이 시스템 연결을 처리하는지 확인하세요. 다른 연결의 상태를 이번 테스트 결과로 오인하지 않도록 주의합니다. 테스트 중에는 네트워크 환경을 일정하게 유지하고 Wi-Fi 전환, 프로토콜 설정 변경, 서버 교체를 동시에 하지 마세요. 첫 확인을 마칠 때까지 On Demand의 기존 설정을 유지하세요. 자동 연결 조건은 수동 연결이 정상적으로 작동하는 것을 확인한 뒤 별도로 설정해야 합니다. 자세한 내용은 On Demand 안내를 참고하세요.

04 · Connectivity Test: 작동 여부 확인

스위치가 켜진 상태에서 Home의 Connectivity Test로 테스트 결과를 확인합니다. 먼저 테스트 방법을 확인한 뒤 결과를 해석하세요. 테스트 방법마다 확인하는 네트워크 계층과 대상이 다릅니다. 지연 시간이 표시되더라도 인증, TLS, 대상 서비스에 대한 모든 요청이 성공했다는 뜻은 아닙니다. 반대로 한 번의 시간 초과는 테스트 대상, 당시 네트워크 또는 테스트 방법 때문일 수 있으므로 구성 전체를 바로 삭제하지 마세요.

이어서 실제로 사용할 앱이나 페이지를 열고 페이지 새로고침처럼 확인할 작업을 하나 수행합니다. 이전에 캐시된 내용만 확인하지 마세요. 페이지를 한꺼번에 여러 개 열면 실패한 요청과 기록을 연결하기 어렵습니다. Config를 사용 중이라면 대상이 어떤 정책과 일치해야 하는지 확인한 다음 앱에서 확인 가능한 연결 기록과 실제 경로를 비교하세요. 대상이 규칙에 따라 DIRECT로 처리된다면 페이지가 열리더라도 프록시 경로가 정상이라는 증거가 되지 않습니다.

Data: 트래픽 변화 확인

앱의 Data 관련 화면을 열고 테스트 전후의 업로드 및 다운로드 통계를 확인합니다. 기록된 시간과 함께 살펴보면 새 요청이 있었는지 판단하는 데 도움이 됩니다. 트래픽 변화는 클라이언트가 데이터를 처리 중임을 확인하는 보조 정보이지, 특정 페이지가 성공적으로 열렸다는 직접적인 증거는 아닙니다. 백그라운드 앱, 재시도, 다른 요청도 통계에 포함될 수 있습니다. 누적 트래픽을 현재 서비스 제공업체의 잔여 데이터로 간주하지 마세요. 집계 범위와 요금 계산 기준이 다를 수 있습니다.

다음 순서로 확인해 보세요. 서버와 연결 방식을 기록하고, Connectivity Test를 실행한 뒤 실제 대상을 열어 관련 트래픽과 연결 기록을 살펴보고 결과를 적습니다. 특정 대상만 실패하고 나머지는 정상이라면 전체 구독을 다시 가져오기보다 해당 대상의 규칙, DNS 또는 서비스 상태를 확인하세요. 모든 대상이 실패한다면 서버 설정과 기본 네트워크를 점검합니다.

05 · Settings: 일반적인 실패 원인

문제 해결은 어느 단계에서 실패했는지 확인하는 것부터 시작합니다. 목록에 서버가 없으면 가져오기 문제이고, 스위치가 켜진 상태를 유지하지 못하면 연결 또는 시스템 구성 문제입니다. 연결은 됐지만 요청이 실패한다면 서버, DNS, 트래픽 분기를 점검해야 합니다. 변경하기 전에 실패 당시의 네트워크, 서버, Global Routing, 표시된 메시지를 기록하세요. 한 번에 하나씩만 바꾸고 네 번째 단계를 다시 확인해야 변경 효과를 판단할 수 있습니다.

Subscribe: 가져오기 실패 또는 목록이 비어 있음

먼저 기본 네트워크에서 기기가 정상적으로 인터넷에 연결되는지 확인한 다음 구독 링크 전체를 복사했는지, 불필요한 공백이 없는지, 복사한 주소가 실제 구독 URL인지 확인합니다. 로그인 페이지, 오류 문구 또는 빈 내용이 반환된다면 서버 Type을 바꿔도 해결되지 않습니다. 기존 서비스 제공업체의 안내를 확인해 링크 상태, 지원 형식, 계정 유효성을 점검하세요. 전체 구독 주소가 포함된 오류 화면을 공개하지 마세요.

기존 항목이 남아 있다고 해서 방금 업데이트가 성공한 것은 아닙니다. 이번 가져오기 결과를 확인하고 그룹 안의 서버 목록을 살펴보세요. 가져오기에 실패했더라도 유일하게 사용할 수 있는 기존 구독을 먼저 삭제하지 마세요. 비교할 수 있도록 현재 상태를 유지하고 원인을 확인합니다.

구독 업데이트: 먼저 업데이트한 뒤 다시 선택

기존 구독을 새로고침하려면 Home에서 해당 구독 그룹을 찾아 그룹의 업데이트 기능을 사용합니다. 결과가 표시될 때까지 기다린 다음 서버 목록을 확인하세요. 업데이트로 항목 이름, 개수, 설정이 바뀔 수 있으므로 완료 후 선택된 서버를 다시 확인해야 합니다. 이전에 사용하던 서버가 그대로 선택되어 있다고 가정하지 마세요. 서비스 제공업체가 구독 링크를 변경했다면 안내에 따라 기존 항목의 주소를 수정해야 합니다. 이전 주소를 계속 새로고침해도 새 내용을 가져올 수는 없습니다.

구독에서 생성된 서버 설정을 직접 수정하기 전에 다음 업데이트가 해당 변경 사항을 덮어쓸 수 있다는 점을 고려하세요. 특정 항목을 확인해야 한다면 원래 값을 기록하고 수정 이유를 적어 둡니다. 테스트 후 원래대로 돌리거나, 영향 범위를 정확히 알고 있는 경우 별도의 테스트 항목으로 저장하세요. 구독은 서버 정보를 관리하고 Config는 구성과 규칙을 관리하므로, 구독 업데이트가 성공해도 Config의 규칙까지 업데이트된 것은 아닙니다.

서버 연결: 지연 시간만 보지 말고 항목별로 확인

목록은 정상인데 연결되지 않는다면 Add Server에서 해당 항목을 열어 Type, Host, Port, 인증 정보, 전송 방식, TLS 설정 순서로 확인하세요. 도메인과 서버 이름은 용도가 다를 수 있으므로 문자열이 비슷해 보여도 서로 바꿔 쓰지 마세요. 기기의 시스템 시간도 정확해야 합니다. 시간이 크게 어긋나면 인증서 확인에 영향을 줄 수 있습니다. 원래 서버 정보가 불완전하다면 기존 서비스 제공업체에 필요한 항목을 문의하고, 추측한 값을 모든 입력란에 채우지 마세요.

네트워크를 바꾼 뒤 결과가 달라졌다면 설정과 대상을 그대로 둔 채 다시 테스트해 현재 네트워크 경로와 구성 오류를 구분하세요. Settings의 Test Method는 테스트 결과의 의미에 영향을 줍니다. Diagnostics에서 추가로 확인할 수 있는 진단 정보를 살펴볼 수 있습니다. TCP나 UDP가 표시된다고 해서 항목을 임의로 끄지 마세요. 해당 전송 방식이 필요한지는 구성 안내를 기준으로 판단해야 합니다.

DNS: 연결은 되지만 도메인에 접속할 수 없음

DNS는 도메인 이름을 IP 주소로 변환합니다. 연결 상태는 정상인데 특정 도메인이 열리지 않는다면 같은 문제가 반복되는지 먼저 확인하고, 확인 가능한 기록에 DNS 관련 오류가 있는지 살펴보세요. Config를 사용한다면 현재 구성의 DNS 설정, Hosts 항목, 대상 규칙을 확인합니다. 적용되지 않은 다른 파일만 수정하지 않도록 주의하세요. 원래 설정을 기록한 다음 해당 설정의 안내에 따라 조정하세요. 여러 설정을 계속 덧붙이면 현재 실제로 어떤 설정이 적용 중인지 판단하기 어려워집니다.

일부 대상의 실패는 규칙에서 REJECT에 일치하거나, 정책이 사용할 수 없는 서버를 지정하거나, 대상 서비스 자체에 문제가 있어서 발생할 수도 있습니다. Global Routing을 잠시 Proxy로 변경하면 규칙의 영향을 비교하는 데 도움이 됩니다. 테스트 후에는 원래 연결 방식으로 되돌리세요. Proxy에서는 성공하고 Config에서는 실패한다면 구성을 먼저 확인하고 트래픽 분기를 점검해야 합니다. 모든 규칙을 삭제해야 한다는 뜻은 아닙니다. 프로토콜 설정의 자세한 내용은 Shadowrocket 프로토콜 안내서를 참고하세요. 이 페이지에서는 처음 설정에 필요한 확인 순서만 다룹니다.

점검 완료 후: 평소 설정으로 복원

실제 대상에 접속할 수 있는지 확인한 뒤 평소 사용할 Global Routing으로 되돌리고 한 번 더 테스트합니다. 테스트 중 On Demand를 끄거나 Test Method를 변경했다면 최종 설정도 각각 확인하세요. 연결을 끊으려면 Home으로 돌아가 상단 스위치를 끄고 상태가 바뀌는지 확인합니다. 이후 자동으로 다시 연결된다면 수동으로 계속 끊기보다 On Demand 조건을 확인하세요.

처음 설정이 완료됐다는 기준은 설정을 많이 바꾸는 것이 아닙니다. 보유한 서버 정보가 정확하고, 현재 구성이 분명하며, 연결 승인이 완료되고, 대상 요청 결과가 정책과 일치하면 됩니다. 간단한 점검 기록을 남겨 두되 암호, 전체 구독 링크, 기타 인증 정보는 포함하지 마세요. 이후 문제가 생기면 모든 항목을 다시 입력하기보다 마지막으로 정상 작동했을 때와 그 뒤 달라진 점부터 확인하는 편이 원인을 찾기 쉽습니다.