Shadowrocket
가져오기 및 연결 방법
기존 설정 → 모드 선택 → 연결 → 확인 → 문제 해결
이 페이지는 iPhone과 iPad를 기준으로 처음 사용하는 순서에 따라 어디를 누르고 무엇을 확인해야 하는지 안내합니다. 스크린샷은 App Store 공식 이미지이며, 실제 화면은 기기에 표시되는 내용을 기준으로 확인하세요.
STEP 01 / IMPORT
서버 추가 및 구독 가져오기
먼저 보유한 정보가 어떤 유형인지 확인합니다. 서버 목록을 업데이트하는 전체 주소 하나만 있다면 보통 구독 링크입니다. 프로토콜 유형, 서버 주소, 포트 및 인증 정보가 포함되어 있다면 단일 서버로 추가할 수 있습니다. 두 방법을 중복해서 사용할 필요는 없습니다. 기존 구독이 있다면 같은 경로로 나중에 목록을 업데이트할 수 있도록 구독 가져오기를 우선 사용하세요. 서버 매개변수만 있다면 항목별로 입력합니다.
기존 구독: Subscribe 선택
Shadowrocket을 열고 Home으로 이동한 다음 오른쪽 위의 추가 버튼이나 목록의 Add Server를 누릅니다. 추가 화면에서 Type을 누르고 Subscribe를 선택한 뒤, 본인의 전체 구독 링크를 해당 URL 입력란에 넣고 저장합니다. 스크린샷은 단일 서버 입력 양식입니다. Type을 바꾸면 입력란도 유형에 따라 달라지므로, 구독 주소를 스크린샷의 Host에 입력하지 마세요.
붙여넣기 전후에 링크 전체가 올바른지 확인하세요. 특히 물음표 뒤의 매개변수와 끝부분의 문자, 메신저에서 복사할 때 들어갈 수 있는 공백이나 줄바꿈에 주의합니다. 구독 주소에는 접속 정보가 포함되는 경우가 많으므로 공개 댓글이나 스크린샷에 올리지 마세요. 저장 후 Home으로 돌아가 내용을 가져올 때까지 기다립니다. 구독 이름만 추가된 것이 아니라 구독 그룹 아래에 서버가 표시되는지 확인하세요.
목록이 계속 비어 있다면 구독 업데이트가 성공하는지, 주소가 유효한지, 현재 네트워크에서 해당 주소에 접근할 수 있는지 먼저 확인하세요. 업데이트 실패와 서버 연결 실패는 서로 다른 단계입니다. 전자는 아직 목록을 가져오지 못한 상태이므로 연결 스위치를 반복해서 켜도 해결되지 않습니다. 오류의 구체적인 의미는 문제 해결에서 확인할 수 있습니다.
기존 서버 정보 입력: Add Server
Add Server에서 먼저 보유한 정보에 맞는 Type을 선택한 다음 Host와 Port를 입력합니다. 스크린샷의 Password와 Method는 해당 유형에서 사용하는 항목 예시이며, 프로토콜에 따라 인증 또는 전송 항목이 다르게 표시될 수 있습니다. 양식을 채워 보이게 하려고 항목을 추측하지 말고, 한 프로토콜의 비밀번호를 다른 프로토콜에 그대로 사용하지 마세요.
Host에는 서버 도메인이나 주소를, Port에는 해당 포트를 입력합니다. 나머지 항목은 본인의 서비스 제공자 정보나 서버 설정과 하나씩 대조하세요. Trojan처럼 TLS 설정이 있는 유형은 서버 이름 등 관련 매개변수도 확인해야 합니다. 주소와 비밀번호만 확인해서는 충분하지 않습니다. QR 코드는 Scan QR Code로 인식할 수 있지만, 인식 후에도 Type과 대상 서버가 올바른지 확인하세요.
저장한 뒤 Home으로 돌아와 SERVER 목록에 새 항목이 있는지 확인합니다. 사용할 서버 하나를 선택하세요. 목록에 표시된다는 것은 정보가 저장되었다는 뜻일 뿐, 연결이 수립되었다는 뜻은 아닙니다. 이 단계를 마친 다음 요청을 어떤 모드로 처리할지 정합니다.
STEP 02 / ROUTING
Global Routing 선택
Home으로 돌아가 Global Routing을 누릅니다. 여기서는 요청에 적용할 연결 정책을 선택하며, 구독 출처를 고르는 곳이 아닙니다. 처음 사용할 때는 세 가지 모드인 Config(구성)/Proxy(프록시)/Direct(직접 연결)의 차이를 알아두세요. 어떤 모드를 선택할지는 이번에 확인하려는 대상에 따라 결정하며, 특정 모드가 항상 더 적합하다고 볼 수는 없습니다.
Config(구성): 현재 구성에 따라 처리
Config는 현재 구성의 규칙에 따라 요청을 처리합니다. 앱의 Config 페이지에서 사용할 구성 파일이 있는지, 선택되어 있는지 확인하세요. 서비스 제공자가 서버 구독을 제공한다고 해서 규칙 구성이 함께 가져와졌다고 볼 수는 없습니다. 서버 목록은 연결 대상을 제공하고, 구성 파일은 요청 처리 방법을 정의합니다.
오른쪽 공식 스크린샷에는 구성 편집 화면의 General, Rule, Hosts, URL Rewrite, HTTPS Decryption 섹션이 표시됩니다. 첫 연결을 위해 각 섹션을 수정할 필요는 없습니다. 특히 구독 링크를 Rule에 붙여넣거나 튜토리얼을 따라 하기 위해 현재 필요하지 않은 기능을 켜지 마세요.
예를 들어 아래 규칙은 “example.com과 그 하위 도메인에 일치하면 PROXY를 사용하고, 그 외 요청은 DIRECT로 처리”한다는 뜻입니다. 문법 이해를 위한 일부 예시일 뿐, 기존 파일을 대체할 수 있는 완전한 구성은 아니며 모든 웹사이트에 같은 정책을 적용해야 한다는 의미도 아닙니다.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTConfig 모드에서 일부 요청은 직접 연결되고 다른 요청은 프록시를 사용할 수 있습니다. 이는 규칙에 따른 정상적인 결과일 수 있습니다. 일치 순서, 정책 이름 또는 기본 규칙을 변경하려면 규칙 및 구성 참고 안내를 확인하세요. 첫 연결 때 전체 구성을 한꺼번에 수정하지 마세요.
Proxy(프록시)와 Direct(직접 연결)
Proxy는 일반 요청을 선택한 프록시로 전달하므로 문제 범위를 좁히는 임시 점검에 사용할 수 있습니다. 먼저 서버 자체로 접속할 수 있는지 확인한 뒤 Config로 돌아와 규칙 차이를 살펴보세요. Direct는 선택한 프록시 서버를 거치지 않고 직접 연결합니다. 따라서 연결 스위치가 켜져 있어도 해당 서버를 사용 중이라고 단정할 수 없습니다.
모드를 선택한 뒤 Home으로 돌아와 Global Routing에 방금 선택한 값이 표시되는지 확인합니다. 프록시 연결만 확인하려면 원래 모드를 기록해두고 Proxy를 임시로 선택할 수 있습니다. 확인이 끝나면 평소 사용할 Config로 되돌리세요. 다음 단계에서 연결을 시작합니다. 정보 저장, 모드 선택, 연결 수립을 한꺼번에 판단하지 않도록 순서대로 진행하세요.
STEP 03 / CONNECT
스위치 켜기 및 시스템 권한 승인
이제 Home으로 돌아와 SERVER에서 연결할 서버가 선택되어 있는지 확인합니다. 해당 항목의 편집 화면만 열려 있는 상태와 혼동하지 마세요. 이어서 Global Routing을 확인하고 마지막으로 상단 연결 스위치를 켭니다. 오른쪽 스크린샷의 Not Connected는 아직 연결되지 않은 상태를 나타내며, 스크린샷이 현재 기기의 상태를 보여주는 것은 아닙니다.
처음 연결을 설정할 때 시스템에서 VPN 구성을 추가하도록 허용할지 묻습니다. 시스템 팝업을 읽고 이번 작업으로 표시된 요청인지 확인한 뒤 안내에 따라 허용하고, 기기 암호나 시스템이 요구하는 인증을 완료하세요. 이는 앱이 시스템 네트워크 연결을 구성하도록 승인하는 절차이며 서버 비밀번호 입력과는 별개입니다. 시스템 인증은 시스템 화면에서 진행해야 하며 Add Server의 Password에 입력하지 마세요.
방금 시스템 권한 요청을 취소했다면 앱으로 돌아가 연결을 다시 시작하고 안내가 다시 표시되는지 확인하세요. 권한 승인이 완료되지 않았을 때 스위치가 자동으로 꺼지는 현상을 구독 오류로 오해하거나 모든 서버를 바로 삭제하지 마세요. 먼저 필요한 권한을 승인한 뒤 상태를 확인하면 불필요한 변경을 줄일 수 있습니다.
연결 상태는 Home으로 돌아와 확인
권한을 승인한 뒤 Shadowrocket으로 돌아가 상단 상태가 Not Connected에서 바뀌었는지, 스위치가 켜진 상태로 유지되는지, 오류 메시지가 표시되는지 확인하세요. 시스템의 VPN 표시는 터널 상태를 확인하는 데 도움이 될 수 있지만, 특정 웹페이지에 적용된 정책을 알려주거나 모든 서버 정보가 올바르다는 것을 증명하지는 않습니다.
스위치가 바로 꺼지면 표시된 안내를 기록하고 앱의 시스템 권한을 확인한 다음, 다른 VPN 연결이 이번 테스트에 영향을 주는지 살펴보세요. 스위치를 빠르게 연속해서 켰다 끄지 마세요. 연결이 안정되기 전에 구독 업데이트, 모드 변경, 구성 수정까지 동시에 하면 어떤 단계가 결과를 바꿨는지 확인하기 어렵습니다.
스위치가 켜진 상태로 유지되면 다음 단계의 확인이 끝날 때까지 선택한 서버와 모드를 그대로 둡니다. 연결을 중지하려면 Home으로 돌아와 같은 스위치를 끄세요. 첫 테스트가 끝날 때까지는 On Demand를 켤 필요가 없습니다. 조건에 따라 연결되도록 설정하면 수동 테스트의 상태를 판단하기 어려워질 수 있습니다.
STEP 04 / VERIFY
연결 및 실제 접속 확인
확인은 세 단계로 나눠야 합니다. 서버 테스트 결과가 있는지, 실제 웹페이지가 로드되는지, 요청이 예상한 정책으로 처리되는지를 각각 살펴보세요. 세 항목은 서로 연관되어 있지만 서로를 대신할 수는 없습니다. 스위치가 켜져 있거나 테스트 수치가 표시되는지만 보면 DNS 확인, 인증, 규칙 또는 대상 웹사이트 자체의 문제를 놓칠 수 있습니다.
먼저 Connectivity Test로 연결 확인
Home에서 Connectivity Test를 누르고 테스트가 끝날 때까지 기다린 뒤, 선택한 서버의 결과를 확인합니다. 이 기능은 현재 연결할 수 없는 대상을 찾는 데 도움이 되지만, 결과는 테스트 방법과 네트워크 환경에 영향을 받습니다. 수치가 낮아도 모든 웹페이지가 열린다는 뜻은 아니며, 테스트 실패만으로 구독 정보 전체가 무효라고 판단할 수도 없습니다. 실제 접속 결과와 함께 확인하세요.
같은 구독에 서버가 여러 대 있다면 네트워크, 모드, 구성을 그대로 둔 채 다른 서버를 선택해 다시 테스트할 수 있습니다. 이렇게 하면 여러 조건을 한꺼번에 바꾸지 않고 하나의 변수를 비교할 수 있습니다. 특정 테스트 수치를 얻으려고 프로토콜 항목을 자주 바꾸지 마세요. 매개변수는 본인의 서버 정보를 기준으로 확인해야 합니다.
실제 요청으로 접속 결과 확인
연결을 켠 상태로 브라우저를 열고 평소 이용하며 접근 권한이 있는 웹페이지를 방문해 제목뿐 아니라 본문까지 로드되는지 확인합니다. 이어서 평소 사용하는 다른 사이트에서도 비교해보세요. 한 사이트만 열리지 않는다면 사이트 자체, 계정 상태 또는 관련 규칙의 문제일 수 있으므로 전체 연결 실패로 바로 단정하지 마세요.
Config를 사용한다면 앱 내 요청 기록에서 대상 도메인, 일치한 규칙 및 정책을 확인합니다. 프록시를 사용해야 하는 요청은 해당 프록시 정책을 따라야 하며, 직접 연결이 예상되는 요청은 DIRECT와 일치할 수 있습니다. 기록에 표시되는 내용은 현재 앱 화면을 기준으로 확인하세요. Direct 모드에서 접속에 성공한 것을 프록시 서버 검증이 끝난 것으로 보지 마세요.
필요하면 현재 설정을 기록해두고 Proxy로 임시 전환해 같은 대상을 다시 확인한 다음 Config로 복원할 수 있습니다. Proxy에서는 성공하고 Config에서는 실패한다면 규칙, 정책 참조 및 DNS 확인의 차이를 우선 점검하세요. 두 모드 모두 실패하면 서버 정보와 네트워크를 먼저 확인합니다. 테스트가 끝나면 평소 사용할 모드로 되돌리고, 검증을 마친 구성을 이후 문제 해결의 기준으로 보관하세요.
STEP 05 / DIAGNOSE
연결 실패 시 문제 해결 순서
문제가 발생하면 먼저 어떤 현상인지 구체적으로 기록합니다. 구독 업데이트 실패인지, 스위치가 켜진 상태로 유지되지 않는지, Connectivity Test 결과가 없는지, 아니면 웹페이지가 열리지 않는지 구분하세요. 현상마다 발생 단계가 다릅니다. 아래 순서에 따라 하나씩 확인하고, 설정은 한 번에 하나만 변경한 뒤 네 번째 단계의 방법으로 다시 테스트하세요. 근거 없이 모든 항목을 새로 구성하지 마세요.
로컬 네트워크부터 확인한 다음 연결 정보 점검
Shadowrocket 연결을 끄고 현재 Wi-Fi 또는 셀룰러 네트워크에서 기본적인 인터넷 접속이 되는지 확인합니다. 로컬 네트워크를 사용할 수 없다면 네트워크 로그인, 신호 또는 연결 권한부터 해결하세요. 그런 다음 Home으로 돌아와 테스트할 서버가 선택되어 있는지 확인합니다. 구독 정보가 최근 변경되었다면 기존 구독을 업데이트하고 결과를 확인하세요. 같은 주소를 반복해서 추가해 중복 항목을 만들지 마세요.
단일 서버 방식이라면 Add Server로 돌아가 Type, Host, Port와 인증 정보를 하나씩 대조합니다. 복사한 내용에 공백이 들어갔거나 포트를 잘못 입력했거나 프로토콜을 다르게 선택하면 저장은 되어도 연결에 실패할 수 있습니다. TLS 또는 추가 전송 설정이 있는 서버는 해당 매개변수도 확인하세요. 오류를 피하려고 검증 기능을 임의로 끄지 말고, 먼저 서버 정보와 기기 시간이 올바른지 확인합니다.
테스트 결과는 있지만 웹페이지가 열리지 않음
현재 Global Routing을 기록한 뒤 같은 요청을 Proxy와 Config에서 비교합니다. Config에서만 실패하면 대상에 일치한 규칙, 사용 가능한 서버가 정책에 지정되어 있는지, FINAL 기본 규칙이 예상에 맞는지 확인하세요. 두 모드 모두 실패한다면 서버 유효성, DNS 확인 및 실제 접속 경로를 점검합니다. 테스트에 수치가 표시되었다고 해서 이러한 가능성을 배제하지 마세요.
DNS 문제와 규칙 문제는 비슷하게 나타날 수 있습니다. 오류 메시지와 요청 기록을 함께 확인해 주소가 확인되었는지, 연결 시간 초과가 발생했는지, REJECT 규칙에 일치했는지 살펴보세요. 온라인에서 본 DNS 설정 전체를 기존 파일에 그대로 덮어쓰지 마세요. 먼저 원래 구성을 저장하고 확인된 원인에 맞춰 최소한으로 수정합니다. 자세한 내용은 연결 및 DNS 문제 해결을 참고하세요.
Settings에서 확인하고 한꺼번에 변경하지 않기
Settings에는 Test Method, On Demand, Diagnostics와 Proxy, TCP, UDP 관련 항목이 있습니다. Test Method는 테스트 방식에 영향을 주므로 결과를 비교할 때는 같은 설정을 유지하세요. On Demand는 조건에 따른 연결과 관련이 있으므로 수동으로 문제를 확인할 때 연결을 다시 시작하는지 먼저 살펴봅니다. Settings의 Proxy 항목을 Global Routing의 Proxy 모드와 혼동하지 마세요.
추가 확인이 필요하다면 Diagnostics에 실제로 표시되는 항목을 따라 점검하세요. 오류 발생 시각, 현재 네트워크, 선택한 모드 및 재현 절차를 기록하면 단순히 “연결이 안 됨”이라고 적는 것보다 원인을 찾기 쉽습니다. 본인의 서비스 제공자에게 문의하기 전에 구독 주소, 인증 항목 및 기타 접속 정보를 가리고 문제와 관련된 상태와 오류만 전달하세요.
같은 조건에서 다른 서버는 작동하고 현재 서버만 계속 실패한다면, 작동한 결과를 보관한 뒤 이미 이용 중인 서비스 제공자에게 문제가 발생한 대상을 확인하세요. 모든 대상에 문제가 있다면 로컬 네트워크, 시스템 권한 및 현재 구성을 계속 점검합니다. 전체 문제 유형은 문제 해결에서, 규칙 작성법과 파일 구조는 구성 참고 안내에서 확인할 수 있습니다. 이 페이지에서 첫 가져오기, 연결 및 확인 절차를 마칩니다.
