공식 매뉴얼 · iPhone 및 iPad

Shadowrocket 사용법:
구독 가져오기 및 첫 연결

처음 사용할 때는 5단계로 진행합니다. 기존 정보를 Home에 추가하고, Global Routing을 선택한 다음 시스템 승인을 완료하고 실제 접속을 확인합니다. 먼저 연결을 정상적으로 설정한 뒤 규칙, DNS, On Demand를 조정하면 각 설정의 영향을 파악하기 쉽습니다.

이 페이지에서는 첫 연결에 필요한 작업 순서를 안내합니다. 구성 파일의 각 항목과 전체 규칙 작성법은 구성 항목 참고에서 확인하고, 구체적인 증상에 따른 해결 방법은 문제 해결을 참고하세요. iPhone과 iPad에서 같은 순서로 진행할 수 있으며, 화면 배치는 기기에 실제 표시되는 내용을 기준으로 합니다.

1단계: Add Server로 추가하거나 Subscribe로 가져오기

먼저 보유한 정보의 종류를 확인합니다. 구독 링크는 여러 서버 항목을 가져오는 데 사용되며, 일반적으로 원래 서비스 제공자가 내용을 갱신할 수 있습니다. 개별 서버 정보에는 프로토콜, 주소, 포트, 인증 항목이 포함됩니다. 두 방식을 중복해서 추가할 필요는 없으므로 보유한 정보에 맞는 방법 하나를 선택하세요. 시작 전에 원본 정보가 완전한지 확인하세요. 특히 웹페이지 소개 주소를 구독 링크로 사용하거나 구성 파일 주소와 서버 구독 주소를 혼동하지 않도록 합니다.

기존 구독 링크가 있다면 Subscribe 선택

Shadowrocket을 열고 Home으로 이동한 뒤 추가 버튼을 눌러 Add Server를 엽니다. 유형 목록에서 Subscribe를 찾아 기존 구독 링크 전체를 URL에 입력하고, 알아보기 쉬운 이름을 지정한 다음 저장합니다. Home으로 돌아가 가져오기가 완료될 때까지 기다린 뒤 구독 그룹에 서버 항목이 표시되는지 확인합니다. 구독 이름만 표시되고 항목이 아직 없다면 연결 스위치를 켜기 전에 가져오기가 완료됐는지 확인하세요.

링크를 복사할 때 물음표 뒤의 매개변수도 포함하고 따옴표, 공백, 줄바꿈은 추가하지 마세요. 일부 링크에는 개인 접속 정보가 포함되어 있으므로 본인 기기에서만 사용하고, 전체 링크를 공개 스크린샷이나 문의 내용에 올리지 마세요. 저장 후 오류가 발생하면 편집 화면으로 돌아가 원본 링크와 대조합니다. 같은 구독을 반복해서 만들면 주소 오류가 해결되지 않고 나중에 항목을 선택하기만 더 복잡해질 수 있습니다. 구독 내용을 갱신하려면 기존 구독을 업데이트한 다음 결과가 바뀌었는지 확인하세요.

기존 서버 정보가 있다면 실제 프로토콜에 맞게 입력

개별 서버 정보를 받은 경우 Add Server에서 정보와 일치하는 프로토콜 유형을 선택하고 주소, 포트, 해당 인증 항목을 입력합니다. 예를 들어 Shadowsocks, VMess, VLESS, Trojan은 인증 정보가 서로 다르므로 주소가 비슷하다는 이유로 다른 프로토콜의 항목을 적용하면 안 됩니다. TLS나 기타 전송 매개변수가 포함된 정보라면 관련 항목도 확인하세요. 해당 값은 원본 정보에서 확인해야 하며 추측으로 입력하지 않습니다.

서버 주소에는 해당 항목에서 요구하는 호스트 이름이나 주소를 입력하고, 포트는 포트 항목에 입력합니다. 사용자 이름, 비밀번호, UUID, TLS 이름은 각각 용도가 다르므로 서로 바꿔 사용할 수 없습니다. 정보가 QR 코드로 제공됐다면 Scan QR Code로 읽을 수 있습니다. 가져온 뒤에도 항목을 열어 유형과 주요 정보를 확인하고 내용이 완전한지 살펴본 다음 저장하세요. QR 코드에도 구독 링크와 마찬가지로 인증 정보가 포함될 수 있으므로 공개하지 마세요.

추가를 마치면 Home으로 돌아가 SERVER 목록에서 이번에 사용할 항목을 선택합니다. 항목이 저장된 것과 선택된 것은 다릅니다. 서버가 여러 개라면 다음 연결 단계에서 사용할 항목을 명확히 선택해야 합니다. 선택한 항목의 이름을 기억해 두고, 다음 단계에서 Global Routing을 전환하고 결과를 확인할 때 같은 서버를 유지하세요. 여러 조건을 동시에 바꾸지 않도록 합니다.

2단계: Global Routing 모드 선택

서버를 추가하고 선택한 다음 Home에서 Global Routing을 엽니다. Global Routing은 요청을 전반적으로 어떤 방식으로 처리할지 결정하며, 서버 정보를 대신 입력해 주지는 않습니다. 첫 연결에서는 이 설정도 꼭 확인해야 합니다. 서버 정보를 올바르게 입력했더라도 다른 모드로 요청을 처리하면 실제 결과가 예상과 다를 수 있습니다. 이 가이드에서는 세 가지 모드를 Config / Proxy / Direct로 표기합니다. 기기에서는 영문 인터페이스 이름으로 확인하세요.

서버 구독만 있고 규칙 구성이 아직 준비되지 않았다면 Proxy를 선택해 통제된 테스트를 먼저 진행할 수 있습니다. 이렇게 하면 규칙 선택에 따른 변수를 일시적으로 줄일 수 있지만, 모든 앱과 시스템 요청이 똑같이 처리된다는 뜻은 아닙니다. 테스트할 때는 대상을 명확히 정하고 실제 접속과 연결 기록을 함께 확인하세요. 모드 이름만으로 특정 요청이 서버를 경유했다고 판단할 수 없습니다.

Config를 사용할 준비가 되면 먼저 Config로 이동해 실제로 적용 중인 구성 파일을 확인합니다. Global Routing의 Config는 라우팅 모드이고, 하단의 Config 페이지는 구성 파일 관리 메뉴입니다. 두 기능은 관련되어 있지만 같은 작업은 아닙니다. 서버 구독을 가져왔다고 해서 규칙 구성까지 전환된 것은 아닙니다. 트래픽 분기가 예상과 다르면 서버를 반복해서 추가하지 말고 현재 적용 중인 파일을 확인하세요.

규칙은 일반적으로 순서대로 일치 항목을 찾고, 규칙에 맞으면 해당 정책을 적용합니다. 우선 이 점을 문제 해결 원칙으로 기억하면 됩니다. 첫 연결 전에 전체 규칙을 편집할 필요는 없습니다. PROXY, DIRECT, REJECT, FINAL의 의미를 확인하려면 규칙 및 구성 참고에서 하나씩 살펴보세요. 모드를 선택한 뒤 Home으로 돌아가 방금 선택한 서버가 그대로 선택되어 있는지 확인하고 연결 스위치를 켭니다.

3단계: 스위치를 켜고 시스템 승인 완료

다음 세 가지를 확인합니다. Home에 사용할 수 있는 서버 항목이 있고, 이번에 사용할 항목이 선택되어 있으며, Global Routing이 방금 정한 모드로 설정되어 있어야 합니다. 확인을 마치면 Home에서 연결 스위치를 켭니다. 해당 기기에서 처음 연결할 때는 시스템에 VPN 구성 추가를 허용하는 안내가 표시될 수 있습니다. 이는 시스템 네트워크 연결 구성을 만드는 단계이며 Subscribe로 서버 목록을 가져오는 작업과는 다릅니다.

시스템 안내를 읽고, 방금 Shadowrocket에서 시작한 작업인지 확인한 다음 허용을 선택하고 시스템 지시에 따라 기기 인증을 완료합니다. 시스템 승인이 끝나면 앱으로 돌아와 연결 스위치와 상태가 연결됨으로 유지되는지 확인하세요. 이전에 안내를 취소했다면 연결을 다시 시작하고 승인 절차를 진행합니다. 스위치를 연속해서 눌러도 완료되지 않은 시스템 확인 절차를 대신할 수는 없습니다.

스위치를 켠 직후 다시 꺼진다면 앱이나 시스템에 표시된 오류 메시지를 먼저 확인하세요. 이 경우 구성 생성이 정상적으로 완료됐는지, 다른 네트워크 연결 구성이 현재 연결을 제어하고 있는지, 기기 관리 정책이 관련 작업을 제한하는지 점검하는 것이 좋습니다. 상황을 기록하기 전에 모든 구성을 삭제하지 마세요. 사용 중인 다른 연결을 정상적으로 끈 다음 Shadowrocket만 단독으로 테스트하면 상태 전환에 따른 간섭을 줄일 수 있습니다.

시스템에 VPN 연결이 표시된다는 사실만으로 관련 네트워크 구성이 작동 중이라는 점은 알 수 있지만, 원격 서버 인증이 성공했거나 모든 웹페이지에 접속할 수 있다는 뜻은 아닙니다. 이 단계가 끝나면 대상 요청도 확인해야 합니다. 특히 Config에서는 규칙에 따라 일부 대상이 DIRECT로 처리될 수 있습니다. 이를 연결 스위치가 작동하지 않은 것과 동일하게 판단하지 마세요.

처음 문제를 점검하는 동안에는 수동으로 연결 스위치를 조작하고 On Demand는 함께 변경하지 마세요. On Demand는 조건에 따라 연결의 시작이나 복구에 영향을 줄 수 있습니다. 조건을 이해하지 못한 상태에서는 연결을 껐는데 다시 켜지는 상황을 작업 실패로 오해하기 쉽습니다. 다음 단계에서 안정적으로 결과를 확인한 뒤 실제 사용 방식에 맞춰 On Demand 기능 안내를 읽어보세요. 테스트를 끝내려면 Home으로 돌아가 연결 스위치를 끄고 상태가 변경됐는지 확인합니다.

4단계: Connectivity Test 및 실제 접속 확인

연결이 설정되면 먼저 Connectivity Test를 실행하고 결과가 반환되는지와 오류 메시지를 기록한 다음 Safari에서 접속이 확인된 페이지를 엽니다. 테스트와 실제 접속은 별개의 확인 절차입니다. 전자는 테스트 방식과 대상에 따른 결과를 보여 주고, 후자는 대상 도메인의 DNS 확인, 연결, TLS, 페이지 리소스 로딩까지 포함합니다. 테스트에 수치가 표시돼도 모든 대상에 접속할 수 있다는 뜻은 아니며, 한 번 시간 초과가 발생했다고 모든 요청이 실패한다고 단정할 수도 없습니다.

반복 가능한 비교 기준 만들기

대상을 명확히 정하고 사용 중인 네트워크, 서버, Global Routing을 기록합니다. 페이지가 완전히 로드될 때까지 기다린 다음 한 번 새로 고침하거나 접속이 확인된 다른 페이지를 열어 결과가 반복되는지 확인하세요. 테스트 중에는 구독을 업데이트하거나 서버를 전환하거나 DNS를 수정하지 마세요. 결과가 바뀌어도 원인을 찾기 어려워집니다. Wi-Fi와 셀룰러 네트워크를 비교하려면 먼저 현재 네트워크에서 기록을 마친 뒤 네트워크 조건만 바꾸고 다시 테스트합니다.

Proxy에서는 정상적으로 접속되지만 Config에서 같은 대상에 문제가 생기면 서버는 그대로 두고 현재 구성과 규칙 일치 여부를 먼저 확인합니다. 반대로 두 모드에서 모두 실제 접속이 되지 않는다면 규칙 전체를 다시 작성하기보다 서버 정보, 원격 측의 이용 가능 여부, 로컬 네트워크를 점검하세요. Direct는 로컬에서 직접 접속한 결과를 비교하는 데 쓸 수 있지만, Direct 접속 성공이 프록시 경로의 정상 작동을 증명하지는 않습니다.

전체 상태만 보지 말고 요청별 결과 확인

특정 대상에 어떤 정책이 적용됐는지 확인하려면 앱의 연결 기록을 열고 대상 도메인이나 주소로 해당 요청을 찾아 표시된 정책, 규칙, 오류 정보를 확인합니다. 버전에 따라 기록 메뉴 위치와 표시 항목이 달라질 수 있으므로 실제 인터페이스를 기준으로 확인하세요. 먼저 대상이 분명한 새 요청을 실행한 뒤 관련 기록을 찾아보면 많은 과거 기록을 보고 추측하는 것보다 비교하기 쉽습니다.

DIRECT가 표시되면 현재 규칙에 맞는 처리인지 먼저 확인합니다. REJECT가 표시되면 의도한 차단 규칙에 일치했는지 살펴봅니다. PROXY를 사용했다면 선택한 서버와 연결 결과를 추가로 확인하세요. 페이지에서는 여러 도메인에 동시에 요청할 수 있으므로 메인 페이지가 열려도 이미지, 로그인, 기타 리소스는 정상적으로 로드되지 않을 수 있습니다. 일부만 실패했다면 사이트 전체를 이용할 수 없다고 단정하지 말고 실패한 리소스의 도메인을 기록하세요.

확인이 끝나면 Global Routing을 일상적인 사용 목적에 맞게 조정합니다. Config를 사용한다면 확인을 마친 서버와 구성 파일을 유지하고 이후에는 한 번에 한 항목만 변경하세요. 이제 첫 연결 절차가 완료되었습니다. 문제가 계속되면 다음 절에서 문제 발생 지점에 가장 가까운 항목부터 점검합니다.

5단계: 실패한 지점에 따라 문제 점검

먼저 어느 단계에서 실패했는지 구분한 뒤 해당 설정을 점검하세요. 구독 내용을 가져오지 못하는 경우, 연결 스위치가 켜진 상태로 유지되지 않는 경우, 테스트 시간이 초과되는 경우, 웹페이지가 일부만 로드되는 경우는 서로 다른 문제입니다. 모두 ‘연결이 안 됨’으로 묶으면 이미 올바른 항목을 반복해서 변경할 수 있습니다. 아래 순서에 따라 로컬 네트워크부터 확인 범위를 좁히고, 각 항목을 점검할 때마다 같은 대상으로 다시 테스트하세요.

구독을 가져오지 못하거나 목록에 항목이 없는 경우

먼저 기기가 접속 가능한 네트워크에 연결되어 있는지 확인합니다. 현재 연결 때문에 네트워크 상태를 판단하기 어렵다면 Shadowrocket을 정상적으로 끈 뒤 기본 접속 상태를 비교해 보세요. 다음으로 구독 링크가 완전한지, 아직 유효한지, 반환된 내용이 읽을 수 있는 구독 데이터인지 확인합니다. 웹페이지가 열린다고 해서 구독 주소에서도 반드시 올바른 내용이 반환되는 것은 아닙니다.

링크가 본인의 원본 정보에서 가져온 것이며 복사 과정에서 안내 문구가 포함되지 않았는지 확인하세요. 서비스 제공자가 링크를 변경했다면 기존 구독의 URL을 새 주소로 업데이트하고, 이전 주소를 반복해서 새로 고치지 마세요. 업데이트한 다음 그룹에 실제 항목이 표시되는지 확인하고 서버를 선택합니다. 가져오기가 실패했다면 이후 Global Routing을 전환해도 이 문제는 대개 해결되지 않습니다.

서버를 추가했지만 인증 또는 테스트에 실패하는 경우

현재 선택한 항목을 열어 프로토콜 유형, 주소, 포트, 인증 항목, TLS 및 전송 설정을 원본 정보와 대조합니다. 비밀번호 끝에 공백이 없는지, UUID가 완전한지, TLS 이름을 올바른 항목에 입력했는지 특히 확인하세요. 표시 이름만 바꿔도 연결 매개변수는 변경되지 않으며, 항목 이름을 다시 지정해도 인증 오류가 해결되지 않습니다.

같은 원본 정보에 사용 가능한 다른 항목이 명시되어 있다면 다른 설정은 그대로 둔 채 서버만 바꿔 비교할 수 있습니다. 여러 항목이 모두 실패한다면 로컬 네트워크의 변화와 원래 서비스 제공자가 안내한 상태를 추가로 확인하세요. 테스트를 통과하기 위해 인증서 확인을 임의로 끄지 마세요. 먼저 기기 시간, 대상 이름, 원본 TLS 설정이 일치하는지 확인해야 합니다.

연결되고 테스트 결과도 있지만 웹페이지가 열리지 않는 경우

먼저 도메인 확인 실패, 연결 시간 초과, 규칙에 따른 거부를 구분합니다. 현재 구성의 DNS 설정이 원래 사용하려던 값인지 확인한 다음 연결 기록에서 해당 도메인을 찾으세요. 특정 도메인 하나만 열리지 않고 다른 페이지는 정상이라면 연결 전체가 실패했다고 바로 판단하지 마세요. 여러 도메인의 주소 확인이 모두 실패한다면 DNS 경로와 현재 네트워크 조건을 우선 점검합니다.

출처를 알 수 없는 DNS 주소를 한 번에 여러 개 입력하지 마세요. 기존 값을 기록하고, 사용 가능하다고 확인된 설정으로 되돌린 뒤 요청을 다시 실행해 결과를 비교합니다. Proxy에서는 정상인데 Config에서 문제가 생긴다면 규칙이 해당 대상을 DIRECT 또는 REJECT로 보내는지, FINAL이 의도한 기본 정책으로 적용되는지 확인하세요. 상세 설정과 증상별 안내는 DNS 및 연결 문제 해결에서 확인할 수 있습니다.

변경 후 원인 파악이 어려워졌다면 마지막으로 정상 작동했던 상태로 되돌리기

원본 구독 정보와 정상 작동하는 구성의 사본을 보관하고 방금 변경한 항목을 되돌린 다음 테스트를 반복합니다. 구독 업데이트는 서버 목록을 바꿀 수 있고, 구성 전환은 정책에 영향을 줄 수 있으며, 네트워크 전환은 주소 확인 결과를 바꿀 수 있습니다. 변경된 순서대로 확인하면 앱을 바로 다시 설치하는 것보다 원인을 찾기 쉽습니다. 앱을 다시 받아야 한다면 App Store 구입 항목 복원 안내를 따르세요. 재설치를 일반적인 네트워크 문제 해결 방법으로 사용하지 마세요.

첫 연결 확인을 완료하려면 네 가지를 확인할 수 있어야 합니다. 서버 정보가 올바르게 저장되고 선택되어 있는지, 라우팅 모드가 이번 사용 목적에 맞는지, 시스템 연결이 설정되었는지, 대상 요청 결과를 설명할 수 있는지 확인합니다. 확인을 마친 뒤 On Demand나 세부 트래픽 분기 설정을 하나씩 추가하면 이후 상태가 바뀌어도 같은 순서로 다시 점검할 수 있습니다.