Shadowrocket 사용법

01 · Add Server: 서버 추가 또는 구독 가져오기

먼저 보유한 정보가 여러 서버를 포함하고 업데이트할 수 있는 구독 링크인지, 아니면 단일 서버의 주소·포트·인증 정보인지 확인하세요. 두 종류의 정보를 앱에 입력하는 방법은 다릅니다. 구독 URL을 서버 주소 입력란에 넣지 마세요. Shadowrocket을 열고 Home으로 이동한 다음 오른쪽 위의 추가 버튼을 눌러 Add Server를 엽니다. 저장하기 전에 Type을 확인하세요. 선택한 유형에 따라 입력 항목이 달라집니다.

기존 구독이 있는 경우: Subscribe 사용

Add Server의 Type에서 Subscribe를 선택하고 전체 구독 링크를 URL에 입력한 다음 알아보기 쉬운 이름을 지정합니다. 붙여넣은 링크의 앞뒤와 쿼리 매개변수가 모두 포함되었는지 확인하세요. 메신저에서 복사할 때 공백, 줄바꿈 또는 설명 문구가 함께 들어가지 않았는지도 살펴봅니다. 구독 링크에는 접속 정보가 포함될 수 있으므로 원문을 그대로 보관하되 게시판이나 스크린샷에 공개하지 마세요.

입력을 마치면 저장하고 앱이 구독 내용을 가져와 처리할 때까지 기다린 다음 Home으로 돌아가 결과를 확인합니다. 구독 그룹과 그 안의 서버가 보여야 선택 가능한 연결 항목이 생성된 것입니다. 구독 이름만 저장된 상태는 내용 가져오기에 성공했다는 뜻이 아닙니다. 그룹에 서버가 없다면 구독 응답과 유효성을 먼저 확인하고 다음 연결 단계로 넘어가지 마세요. 구독 업데이트는 연결 정보를 새로 고치는 기능이며, 서비스 제공업체 측의 이용 권한이나 유효 기간을 대신하지 않습니다.

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

단일 서버 정보를 받은 경우 Add Server에서 해당 프로토콜의 Type을 선택하고 주소, 포트 및 인증 정보를 항목별로 입력합니다. 프로토콜마다 필요한 정보가 다릅니다. 예를 들어 Shadowsocks에서는 암호화 방식과 비밀번호를 확인하고, VMess 및 VLESS에서는 UUID를 확인해야 하는 경우가 많으며, Trojan에서는 비밀번호와 TLS 관련 매개변수를 확인해야 합니다. 항목 이름이 비슷해도 서로 바꿔 쓸 수 있는 것은 아닙니다. 한 프로토콜의 정보를 다른 프로토콜 입력 양식에 넣지 마세요.

서비스 제공업체가 전송 방식, 경로, Host 또는 SNI 정보도 제공했다면 원래 안내에 따라 입력합니다. 서버 주소와 TLS 인증에 사용하는 이름이 다를 수 있으므로 양식의 값이 같아 보이도록 임의로 바꾸지 마세요. 매개변수를 확인하는 대신 인증서 검증을 끄는 방법도 사용하지 마세요. 저장한 다음 Home으로 돌아가 새 서버가 표시되는지 확인하고 사용할 항목을 선택합니다. 이 단계는 정보 입력을 마친 것일 뿐, 연결이 작동한다는 확인은 아닙니다.

공유 링크나 QR 코드가 있다면 해당하는 클립보드 가져오기 기능이나 Scan QR Code를 사용할 수도 있습니다. 가져온 뒤에도 항목을 열어 프로토콜과 주소를 확인하세요. QR 코드 스캔과 항목별 설명은 QR 코드 스캔 및 가져오기 관리에서, 프로토콜 개념은 용어 매뉴얼에서 확인할 수 있습니다. 사용할 서버를 명확하게 선택한 다음 트래픽 처리 방식을 설정하세요.

02 · Global Routing: 트래픽 처리 방식 선택

Home에서 Global Routing을 열고 현재 목적에 따라 Config, Proxy 또는 Direct를 선택합니다. 이 옵션은 요청을 처리하는 방식을 정하며, 프로토콜이나 속도 등급을 뜻하지 않습니다. 서버를 선택했다고 해서 모든 요청이 해당 서버를 통과하는 것은 아닙니다. 선택한 방식이 예상과 다르면 연결 스위치가 켜져 있어도 대상 요청이 다른 경로로 처리될 수 있습니다.

Config: 구성 파일의 규칙에 따라 처리

일상적으로 규칙에 따라 트래픽을 분기하려면 Config를 사용합니다. 먼저 Config로 이동해 사용할 구성 파일이 선택되어 있는지 확인한 다음 Global Routing으로 돌아가 Config를 선택하세요. 두 항목은 서로 다른 기능입니다. Config 화면에서는 구성 파일을 관리하고, Global Routing의 Config 옵션에서는 선택한 구성에 따라 요청을 처리합니다. 서버 구독을 가져왔다고 해서 규칙 구성 파일도 자동으로 가져오거나 활성화한 것은 아닙니다.

규칙은 일반적으로 순서대로 확인하며, 일치하는 규칙에 따라 PROXY, DIRECT 또는 REJECT로 처리됩니다. 요청이 DIRECT와 일치하면 연결 스위치가 켜져 있어도 직접 접속할 수 있습니다. REJECT와 일치하면 요청이 거부됩니다. 마지막 규칙만 보고 모든 요청의 경로를 판단하지 마세요. 규칙 예시와 키워드 설명은 규칙 분기 안내에서 확인할 수 있습니다.

Proxy: 선택한 프록시 경로 확인

서버 작동 여부를 처음 점검할 때는 일시적으로 Proxy를 선택해 해당 방식이 적용되는 요청을 프록시 경로로 처리할 수 있습니다. 그러면 규칙 분기가 결과에 미치는 영향을 줄일 수 있습니다. Proxy를 선택한 뒤에도 Home에서 대상 서버가 선택되어 있는지 확인하세요. Proxy는 잘못된 비밀번호, 사용할 수 없는 서버 또는 제한된 전송 환경을 해결하지 않습니다. 트래픽 처리 방식만 바꾸는 기능이므로 서버가 작동한다는 보장은 되지 않습니다.

Direct: 직접 접속

Direct는 직접 접속할 때 사용하며 프록시 서버가 작동하는지 확인하는 용도에는 적합하지 않습니다. 현재 Direct가 선택된 상태에서 대상 페이지가 열리더라도 해당 조건에서 직접 접속이 가능했다는 뜻일 뿐입니다. 로컬 네트워크와 프록시 경로를 비교할 때는 대조 조건으로 사용할 수 있습니다. 다만 각 테스트에서 선택한 방식을 기록해 서로 다른 조건의 결과를 혼동하지 마세요.

선택을 마치면 Home으로 돌아가 현재 Global Routing 값이 무엇인지 다시 확인합니다. 이후 연결과 테스트는 이 조건을 유지한 상태에서 진행하세요. 문제를 점검하느라 Proxy를 일시적으로 사용했다면 확인 후 필요한 Config로 되돌리고 분기 결과를 다시 테스트합니다.

03 · Home: 연결 켜기 및 시스템 권한 승인

Home으로 돌아가 앞서 확인한 서버를 선택한 다음 상단의 연결 스위치를 켭니다. 구독에 이름이 비슷한 항목이 여러 개 있으면 화면에 최근 표시된 이름만 보지 말고 선택 표시가 어느 항목에 있는지 확인하세요. 구독을 업데이트한 뒤에도 현재 선택한 서버를 다시 확인해야 다른 서버의 결과를 방금 테스트한 항목의 결과로 착각하지 않습니다.

처음 연결할 때 시스템에 VPN 구성을 추가할지 묻는 권한 안내가 나타날 수 있습니다. 이 단계는 앱이 해당 네트워크 연결을 설정하도록 시스템이 허용하는 절차이며, 앱 구매나 구독 가져오기와는 별개입니다. 안내를 읽고 Shadowrocket에서 요청한 것인지 확인한 뒤 시스템 지침에 따라 승인하거나 인증을 완료하세요. 권한 승인을 마치지 않아 앱으로 돌아왔을 때 스위치가 꺼져 있더라도 서버 매개변수 오류라고 단정할 수 없습니다.

권한 승인 후 앱으로 돌아와 연결 스위치가 켜진 상태로 유지되는지 확인합니다. 시스템의 VPN 상태와 앱의 스위치 상태는 연결 기능이 시작되었는지 확인하는 데 도움이 되지만, 대상 서비스에 접속할 수 있다는 증거는 아닙니다. 서버 인증 실패, DNS 조회 오류 또는 규칙 불일치는 연결 스위치가 켜진 후에도 발생할 수 있으므로 다음 단계에서 실제 접속을 확인해야 합니다.

스위치가 곧바로 꺼지면 먼저 시스템 권한 승인이 완료되었는지, 기기에서 다른 VPN 연결을 사용 중인지 확인합니다. VPN 구성끼리 연결 상태를 두고 충돌할 수 있으므로 점검할 때 현재 실행 중인 연결이 무엇인지 먼저 파악하세요. 관리되는 기기에는 조직에서 설정한 제한이 있을 수 있습니다. 시스템 안내에 따라 처리하고, 기기 정책을 우회하기 위해 앱을 반복해서 삭제하지 마세요.

첫 테스트에서는 다른 설정을 그대로 두고 On Demand 같은 자동 연결 조건은 변경하지 마세요. 자동 연결 설정은 이후 사용 방식에 맞춰 조정하는 항목이지, 수동 연결 성공에 필요한 조건은 아닙니다. 수동 연결 스위치, 서버 선택 및 처리 방식이 맞는지 확인한 다음 테스트를 진행하세요. 이렇게 하면 문제가 발생했을 때 어느 단계부터 예상과 달라졌는지 파악하기 쉽습니다.

04 · Connectivity Test: 테스트와 실제 요청 확인

연결을 켠 다음 Home에서 Connectivity Test를 실행해 서버를 확인합니다. 먼저 현재 선택한 항목을 테스트하고, 필요할 때 다른 항목과 비교하세요. 시작부터 여러 항목을 한꺼번에 테스트하면 실제로 어떤 서버를 선택했는지 놓칠 수 있습니다. 테스트 결과는 사용한 테스트 방식과 함께 해석해야 합니다. 방식에 따라 확인하는 연결 단계가 다를 수 있으므로 어떤 수치든 전체 서비스 접속 성공으로 해석해서는 안 됩니다.

응답이 왔다면 당시 조건에서 해당 테스트 단계가 완료되었다는 뜻입니다. 다운로드 속도를 직접 나타내거나 모든 대상 서비스에 접속할 수 있음을 보장하지는 않습니다. 시간 초과는 정해진 대기 시간 안에 테스트가 완료되지 않았다는 뜻이며, 원인은 서버, 로컬 네트워크 또는 테스트 대상 자체일 수 있습니다. 한 번의 결과는 문제를 파악하는 단서로 활용하고 전체 경로에 대한 영구적인 결론으로 삼지 마세요. 테스트 방식과 정렬 방법은 지연 시간 테스트 및 서버 정리에서 자세히 확인할 수 있습니다.

이어서 접속하려는 웹사이트나 앱을 열고 같은 페이지 새로고침처럼 반복하기 쉬운 작업을 해 봅니다. 페이지가 열리는지, 일부 리소스만 실패하는지, 문제가 발생한 네트워크 환경은 무엇인지 기록하세요. 앱의 스위치나 시스템 VPN 표시만으로 성공을 판단하지 마세요. 확인해야 할 것은 대상 요청이 예상대로 완료되는지, 현재 선택한 방식에 맞는 경로로 처리되는지입니다.

Config를 사용할 때는 실제 요청 기록에서 일치한 규칙과 처리 결과도 확인해야 합니다. 대상 요청이 DIRECT와 일치하더라도 프록시가 고장 났다는 뜻은 아닙니다. 구성에서 의도한 결과일 수 있습니다. REJECT와 일치했다면 먼저 해당 규칙의 목적을 확인하세요. 규칙이 원인인지 확인하려면 서버와 로컬 네트워크를 그대로 둔 채 Proxy로 잠시 전환해 같은 요청을 다시 실행한 다음 Config로 돌아와 결과를 비교합니다. 비교하는 동안 서버를 바꾸거나 DNS를 수정하지 마세요. 결과를 해석하기 어려워집니다.

이번 테스트 결과를 간단히 기록해 두면 좋습니다. 선택한 서버 이름, Global Routing 값, 로컬 네트워크, 대상 작업과 성공 또는 실패 증상을 적으세요. 구독 URL, 비밀번호 또는 UUID 전체를 기록할 필요는 없습니다. 실제 요청이 정상임을 확인한 다음 일상적으로 사용할 설정을 하나씩 복원하세요. 설정 하나를 복원할 때마다 같은 테스트를 반복해야 이후 문제가 어떤 변경으로 발생했는지 파악할 수 있습니다.

05 · 자주 발생하는 문제: 오류가 생긴 단계부터 점검

문제를 단계별로 나누어 확인하고 여러 매개변수를 한꺼번에 바꾸지 마세요. “가져온 정보가 완전한가 → 시스템이 연결을 설정했는가 → 서버 테스트에 응답이 있는가 → 실제 요청이 규칙대로 처리되는가” 순서로 확인해 처음 실패한 단계를 찾습니다. 기존에 작동하던 설정은 보존하고 한 번에 한 항목만 변경한 뒤 네 번째 단계에서 했던 동일한 작업을 다시 테스트하세요. 다음 순서는 처음 사용할 때뿐 아니라 구독 업데이트나 로컬 네트워크 변경 후에도 유용합니다.

구독을 저장했지만 서버가 표시되지 않음

구독 항목으로 돌아가 Type이 Subscribe인지, URL에 서비스 제공업체의 관리 페이지 주소가 아닌 전체 구독 주소를 입력했는지 확인하세요. 따옴표나 공백이 포함되었거나 쿼리 매개변수가 누락되지 않았는지 살펴보고 앱에 표시된 가져오기 또는 처리 안내도 확인합니다. 브라우저에서 웹페이지가 열린다고 해서 그 응답이 가져올 수 있는 구독 내용이라는 뜻은 아닙니다. 내용이 비어 있거나 권한이 만료된 경우 서비스 제공업체에 원래 링크를 확인하세요. 임의로 매개변수를 바꿔 문제를 해결하려고 하지 마세요.

연결 스위치가 켜진 상태로 유지되지 않음

먼저 시스템의 VPN 구성 권한과 기기 관리 제한을 확인한 다음 다른 VPN 연결의 상태를 점검합니다. 앱에 구성 오류 안내가 표시되면 최근에 변경한 구성으로 돌아가 구체적인 문제를 확인하세요. 시스템 연결 자체가 설정되지 않은 상태라면 서버를 여러 개 바꾸는 것으로 원인을 파악하기 어렵습니다. 스위치가 정상적으로 켜진 다음에 서버 인증 및 전송 매개변수를 확인하세요.

Connectivity Test 시간 초과 및 실제 접속 실패

먼저 기기에서 현재 네트워크를 정상적으로 사용할 수 있는지 확인한 다음 서버 주소, 포트, 비밀번호 또는 UUID, TLS 및 전송 설정을 다시 살펴봅니다. 입력한 정보에 문자가 하나만 더 들어가도 인증이나 핸드셰이크에 실패할 수 있습니다. 서버 이름만 보지 말고 서비스 제공업체가 제공한 원본 정보와 항목별로 대조하세요. Wi-Fi와 셀룰러 네트워크를 바꿔 한 번 비교해 볼 수도 있습니다. 결과가 로컬 네트워크에 따라서만 달라진다면 전체 구성을 바로 바꾸기보다 해당 네트워크의 접속 조건을 확인하세요.

테스트는 응답하지만 일부 서비스만 작동하지 않음

이 경우 “서버 테스트에 응답이 있음”과 “대상 서비스 이용 가능”을 구분해야 합니다. 먼저 Global Routing을 확인한 다음 해당 요청에 적용된 규칙과 DNS 관련 증상을 살펴보세요. Proxy에서는 정상인데 Config에서 실패한다면 현재 구성 파일, 규칙 순서 및 정책 대상을 먼저 확인합니다. 두 방식 모두 실패하면 대상 서비스 상태, 서버의 외부 연결 조건과 프로토콜 매개변수를 점검하세요. 일부 요청이 실패한다고 모두 지연 시간이 높아서라고 단정하지 마세요.

구독 업데이트 또는 네트워크 전환 후 발생한 문제

업데이트한 다음에는 선택한 서버가 여전히 목록에 있는지, 매개변수가 바뀌었는지, 이름이 비슷한 항목이 그룹에 새로 추가되었는지 확인합니다. 네트워크를 바꾼 경우에는 같은 서버를 다시 테스트해 이전 네트워크에서 얻은 결과를 현재 판단에 적용하지 않도록 하세요. 반복 업데이트와 여러 항목의 일괄 전환은 잠시 중단하고 조건을 일정하게 유지한 채 실제 요청을 한 번 끝까지 확인하면 연결 정보와 로컬 환경 중 어느 쪽이 달라졌는지 파악하기 쉽습니다.

기본 연결을 확인한 다음 구독 업데이트, 여러 구독 정리, 서버 삭제 및 백업 등의 방법은 서버 관리 매뉴얼에서 확인할 수 있습니다. 익숙하지 않은 프로토콜이나 규칙 키워드가 있다면 매개변수를 변경하기 전에 용어 매뉴얼을 먼저 참고하세요. 이 튜토리얼을 마치면 어떤 서버를 선택했는지, 요청이 어떤 방식으로 처리되는지 설명하고 반복할 수 있는 실제 접속으로 결과를 확인할 수 있어야 합니다.