먼저 기본 접속 확인
브라우저에서 접속 가능 여부를 이미 알고 있는 페이지를 연 다음, 이번에 확인하려는 대상도 열어보세요. 한때 콘텐츠가 표시됐는지만 보지 말고 페이지가 실제로 로드되는지 비교해야 합니다. 네트워크에 문제가 있어도 캐시된 페이지가 표시될 수 있습니다.
공식 매뉴얼 · iPhone / iPad
먼저 기존 연결 정보를 추가한 다음 라우팅 방식을 선택합니다. 연결 후에는 실제 접속과 연결 기록으로 결과를 확인하세요.
처음 사용하는 경우 순서대로 읽어보세요. 연결은 됐지만 접속에 문제가 있다면 결과 확인 및 문제 점검으로 바로 이동할 수 있습니다.
단계 01 · 연결 정보 준비
수동 입력, 구독, QR 코드 가져오기는 각각 다른 메뉴입니다. 보유한 정보에 맞는 방법 하나를 선택하면 되며, 중복으로 가져올 필요는 없습니다.
Shadowrocket을 열고 Home으로 이동해 아래쪽의 SERVER 그룹을 확인합니다. 서버 주소, 포트, 인증 정보가 있다면 Add Server에서 직접 추가하세요. 기존 서비스에서 제공한 서버 여러 개를 갱신할 수 있는 구독 링크가 있다면 Subscribe 메뉴를 사용합니다. 단일 서버의 공유 링크나 QR 코드라면 해당 가져오기 메뉴를 이용하세요. 링크가 https://로 시작한다는 이유만으로 구독 링크라고 판단하지 마세요. 일반 안내 웹페이지는 구독 정보로 가져올 수 없습니다.
Home에서 Add Server를 누르고 Type을 열어 보유한 서버 정보와 일치하는 프로토콜을 선택합니다. Type에 따라 입력 항목이 달라집니다. 화면에는 Host, Port, Password, Method가 있는 양식이 표시되지만 모든 프로토콜이 같은 항목을 사용하는 것은 아닙니다. 서버 주소는 Host에, 연결 포트는 Port에 입력하고 인증 정보는 원본 정보에 맞춰 입력하세요. Host에는 보통 도메인이나 주소만 입력하며 웹페이지 경로까지 붙여 넣지 않습니다. Method는 기존 설정과 일치해야 하며 이름이 비슷하다고 임의로 바꾸면 안 됩니다.
Trojan, VMess 또는 다른 프로토콜을 선택했다면 해당 Type에 실제로 표시되는 인증, 전송, TLS 관련 매개변수도 확인하세요. 한 프로토콜의 Password를 다른 프로토콜의 식별 필드로 사용하지 마세요. 입력을 마치면 화면의 저장 기능을 사용하고 Home으로 돌아와 SERVER 아래에 새 항목이 표시되는지 확인하세요. 항목 이름이 사용할 서버와 일치하는지도 살펴봅니다. 필드의 의미가 불분명하다면 임의로 입력을 반복하지 말고 용어 매뉴얼의 프로토콜 및 인터페이스 용어를 먼저 확인하세요.
기존 구독 링크가 있다면 Add Server의 Type에서 Subscribe를 선택하고 양식에 구독 주소를 입력한 뒤 저장합니다. 서버 구독과 Config 페이지에서 관리하는 원격 구성은 용도가 다릅니다. Config에 Subscribe 메뉴가 보이면 먼저 어떤 유형의 콘텐츠를 받는지 확인하세요. 서버 목록 구독 링크와 전체 구성 파일 주소를 혼동하면 안 됩니다. 메뉴 이름이나 위치가 다를 경우 현재 화면의 안내를 따르세요. 가져오기가 제대로 됐는지는 주소가 저장됐는지가 아니라 Home에 예상한 서버가 표시되는지로 확인합니다.
기존 QR 코드가 있다면 Scan QR Code를 사용하고 시스템 안내에 따라 필요한 카메라 권한을 허용한 뒤 인식된 내용을 확인하세요. Import from Cloud JSON은 요구되는 형식의 JSON을 가져오는 기능이며, 모든 구독 링크에 쓸 수 있는 메뉴가 아닙니다. 공유 링크가 있다면 앱에서 제공하는 클립보드 가져오기 안내를 따르세요. 인식 전에 클립보드에 링크 전체가 들어 있는지, 설명 문구나 줄바꿈으로 잘린 부분, 채팅에 붙은 문장부호가 없는지 확인합니다. 인증 정보가 포함된 링크를 공개 페이지에 붙여 넣지 마세요.
완료한 뒤 Home으로 돌아와 해당 그룹을 펼치고 서버를 선택합니다. 목록이 비어 있다면 구독에서 인식 가능한 콘텐츠가 반환됐는지, 만료되지는 않았는지, 그룹이 접혀 있지는 않은지 먼저 확인하세요. 같은 주소를 반복해서 추가해도 콘텐츠 형식 오류는 해결되지 않습니다. 각 메뉴의 차이는 구독 가져오기 방법 안내에서 자세히 확인할 수 있습니다. 선택할 서버가 있는지 확인한 다음 다음 단계로 진행하세요.
단계 02 · 트래픽 처리 방식 결정
서버는 연결할 경로를 정하고, Global Routing은 트래픽을 어떤 방식으로 처리할지 정합니다. 두 항목을 각각 확인해야 합니다.
Home으로 돌아와 Global Routing을 누르고 현재 선택된 모드를 확인합니다. 세 가지 옵션은 Config, Proxy, Direct입니다. 처음 설정할 때는 먼저 원하는 동작을 정한 다음 알맞은 항목을 선택하세요. Home에서 서버를 선택했다고 해서 모든 요청이 해당 서버를 통과하는 것은 아닙니다.
| 모드 | 처리 방식 | 확인할 항목 |
|---|---|---|
| Config | 현재 구성에 설정된 규칙에 따라 요청의 정책을 결정합니다. | 활성화된 구성, 규칙 순서, 최종 정책 |
| Proxy | 트래픽을 프록시 모드로 처리하며, 개별 규칙에 따른 분기를 주된 판단 기준으로 사용하지 않습니다. | 선택한 서버의 사용 가능 여부와 실제 접속 결과 |
| Direct | 트래픽을 대상에 직접 연결합니다. | 이 모드로는 선택한 프록시 서버가 정상 작동하는지 확인할 수 없습니다. |
규칙에 따라 요청을 구분하려면 Config를 선택한 다음 하단의 Config 페이지에서 현재 사용 중인 구성 파일을 확인하세요. 구성 편집 화면에는 General, Rule, Hosts 등의 섹션이 표시됩니다. 화면에 보이는 것은 구성 내용 편집 화면이지 서버 구독 목록이 아닙니다. 기존 서비스에서 제공하는 서버 정보에 규칙 전체가 포함되지 않을 수 있습니다. 따라서 서버를 가져온 것과 규칙 기반 트래픽 분기를 설정한 것은 별개의 작업입니다.
Rule에서 기존 항목을 확인합니다. 규칙은 보통 순서대로 적용되므로 특정 도메인이나 주소 조건은 기본 규칙 앞에 두어야 합니다. FINAL은 앞선 규칙과 일치하지 않는 요청에 적용됩니다. PROXY, DIRECT, REJECT는 정책 키워드이지 서버 세 대를 뜻하지 않습니다. 아래에는 문법 설명을 위한 예시 도메인만 사용하며 연결 가능한 서버 정보가 아닙니다. 기존 설정을 잘 모른다면 Rule 섹션 전체를 바로 덮어쓰지 마세요.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY
기존 서버의 연결 여부만 먼저 확인하려면 Proxy로 잠시 전환해 비교 테스트한 뒤 Config로 돌아오세요. Proxy에서는 접속되지만 Config에서 안 된다면 구독을 바로 다시 가져오기보다 규칙과 구성의 정책 참조를 먼저 확인하세요. DOMAIN-SUFFIX, IP-CIDR, FINAL의 자세한 의미는 용어 매뉴얼에서 확인할 수 있습니다. 이 페이지에서는 연결 확인까지 다루며 복잡한 규칙 작성 방법은 설명하지 않습니다.
기존 구성을 수정하기 전에 복사본을 보관하고, 한 번에 조건 하나만 바꾸세요. 저장한 뒤 Home으로 돌아와 Global Routing에 방금 선택한 모드가 표시되는지 확인한 다음 연결합니다.
단계 03 · 연결하기
서버를 선택하고 라우팅 모드를 확인한 다음 스위치를 켜세요. 시스템 승인은 서비스 인증과 별개입니다.
Home으로 돌아와 SERVER에서 사용할 서버를 선택하고 선택 표시가 원하는 항목에 있는지 확인하세요. 구독으로 여러 항목을 가져왔다면 그룹 이름만 보지 말고 실제 선택한 서버를 확인해야 합니다. 해당 서버가 이후 연결에 사용됩니다. 매개변수를 수정했다면 먼저 저장한 뒤 Home으로 돌아와 조작하세요. 저장하지 않은 양식 내용을 적용된 설정으로 착각하지 않도록 주의합니다.
Global Routing을 확인한 뒤 상단의 Not Connected 옆에 있는 연결 스위치를 켭니다. 처음 연결하면 시스템에서 VPN 구성을 추가하라는 메시지가 표시될 수 있습니다. 이는 클라이언트가 시스템 네트워크 기능을 사용하기 위해 필요한 권한입니다. 현재 작업 중인 Shadowrocket에서 요청한 안내인지 확인하고 시스템 지침에 따라 승인하세요. 기기에 따라 암호나 생체 인증이 필요할 수 있습니다. 이 승인은 기존 서비스 계정에 로그인하는 절차가 아니며, 구독 암호를 기기 암호 입력란에 입력할 필요도 없습니다.
승인한 뒤 Home으로 돌아와 앱 상태가 업데이트될 때까지 기다립니다. Connected가 표시되면 연결 상태가 설정된 것입니다. 그렇다고 모든 대상에 접속할 수 있다는 뜻은 아닙니다. 다음 단계에서 서버, 대상, 규칙 조합을 확인해야 합니다. 스위치가 곧바로 Not Connected로 돌아가면 승인을 취소하지 않았는지, 시스템에서 다른 VPN 구성을 사용 중인지, 기기 관리 정책이 구성 변경을 제한하는지 먼저 확인하세요. 결과가 헷갈리지 않도록 스위치를 빠르게 반복해서 켜고 끄지 마세요.
iPad에서는 화면 너비에 따라 배치가 스크린샷과 다를 수 있지만 작업 순서는 같습니다. 선택한 서버와 Global Routing을 확인한 뒤 연결 스위치를 조작하세요. 서버 매개변수나 구성을 변경할 때는 먼저 연결을 끊고 저장을 마친 다음 다시 연결하며, 변경 사항을 기록해 두세요. 사용을 마치면 Home에서 연결 스위치를 끄면 됩니다. 연결을 정상적으로 끊기 위해 구독을 삭제하거나 구성을 지울 필요는 없습니다.
On Demand를 활성화했다면 트리거 조건에 따라 연결 동작이 달라질 수 있습니다. 처음 확인할 때는 명확한 수동 연결 절차를 사용하세요. 결과를 파악한 뒤 On Demand를 별도로 설정하면 여러 변수가 동시에 개입하는 일을 줄일 수 있습니다. 연결 상태를 유지한 채 다음 단계에서 실제 접속을 확인하세요.
단계 04 · 실제 결과 확인
Home에서 Connectivity Test를 누르고 현재 테스트가 완료될 때까지 기다립니다. 테스트는 지정한 방식의 연결 상태를 확인하며, 결과는 테스트 대상, Test Method, 현재 네트워크, 서버 상태에 따라 달라집니다. 한 번 시간 초과가 발생했다고 모든 서비스에 접속할 수 없다고 단정할 수는 없습니다. 반대로 테스트 결과가 표시됐다고 모든 앱과 도메인이 같은 경로를 사용한다는 뜻도 아닙니다. 목록의 숫자 하나만으로 판단하지 말고 결과가 일관적인지 확인한 다음 브라우저에서 접속해 보세요.
브라우저에서 접속 가능 여부를 이미 알고 있는 페이지를 연 다음, 이번에 확인하려는 대상도 열어보세요. 한때 콘텐츠가 표시됐는지만 보지 말고 페이지가 실제로 로드되는지 비교해야 합니다. 네트워크에 문제가 있어도 캐시된 페이지가 표시될 수 있습니다.
Global Routing과 활성화된 구성을 다시 확인하세요. 특정 요청이 예상대로 PROXY 또는 DIRECT를 사용하는지 확인하려면 시스템 VPN 표시만 보지 말고 해당 연결 기록과 일치한 규칙을 함께 살펴봅니다.
Config에서는 도메인마다 적용되는 정책이 다를 수 있으므로 한 페이지에 접속됐다고 다른 대상도 프록시를 사용한다고 볼 수 없습니다. 같은 서버를 유지한 채 Proxy와 Config를 잠시 비교해 보세요. 모드만 바꾸고 요청을 다시 실행합니다. 차이가 일관되게 나타나면 대상 도메인과 일치한 규칙을 기록한 뒤 Rule을 확인하세요. 확인이 끝나면 계속 사용할 모드로 되돌리고 임시 테스트 상태를 잊지 말고 복구하세요.
브라우저에서는 정상인데 특정 앱만 문제가 있다면 앱에서 연결을 다시 설정해야 하는지, 별도 네트워크 설정이 있는지 확인하세요. 모든 대상에 접속할 수 없다면 다음 단계에서 기본 네트워크부터 점검합니다. 직접 관리하거나 접근 권한이 있는 대상만 확인하세요. 연결 상태를 증명하기 위해 모르는 웹사이트에 구독 링크, 인증 정보, 전체 구성을 제출할 필요는 없습니다.
단계 05 · 한 번에 조건 하나씩 변경
기본 네트워크 → 가져온 콘텐츠 → 서버 매개변수 → 라우팅 및 DNS 순으로 점검하고, 재현 가능한 조건을 기록하세요.
먼저 연결을 끄고 현재 네트워크에서 기존 서비스에 필요한 페이지에 정상적으로 접속할 수 있는지 확인합니다. 이어 구독 주소가 완전한지, 불필요한 공백이 있는지, 서비스 이용 권한이 유효한지 살펴보세요. 구독 이름이 저장됐다고 서버 목록을 가져온 것은 아닙니다. 업데이트 안내를 확인한 뒤 Home으로 돌아와 항목이 표시되는지 확인하세요. 서버에서 로그인 페이지나 오류 안내를 반환하면 클라이언트는 이를 서버 데이터로 사용할 수 없습니다. 인증 정보가 포함될 수 있으므로 전체 구독 주소를 공개 댓글에 올리지 마세요.
Add Server로 돌아가 원본 정보와 Type, Host, Port, 인증 매개변수를 하나씩 비교하세요. 도메인 철자, 포트 자릿수, 비밀번호 앞뒤 공백을 각각 확인할 필요가 있습니다. TLS 서버 이름도 임의로 바꾸면 안 됩니다. 같은 그룹에서 특정 항목만 실패하고 동일한 네트워크의 다른 기존 항목은 작동한다면 해당 항목과 연결된 서비스 상태를 먼저 점검하세요. 네트워크를 바꾼 뒤에만 복구된다면 Wi-Fi와 셀룰러 네트워크의 차이를 기록하세요. 프로토콜, 포트, 규칙을 한꺼번에 바꾸지 마세요.
먼저 Direct 모드에 머물러 있지 않은지 확인한 다음 Proxy와 Config를 비교하세요. Config에서만 문제가 발생하면 올바른 구성이 선택됐는지, 규칙이 예상대로 적용되는지, 정책이 유효한 대상을 참조하는지 확인합니다. 두 모드 모두 실패한다면 서버와 DNS를 점검하세요. 도메인 접속 실패가 반드시 DNS 문제인 것은 아닙니다. 오류 안내를 함께 확인하고 DNS를 임의로 바꾸는 것을 모든 문제의 해결책으로 여기지 마세요.
Settings에서 Test Method를 확인하세요. 테스트 방식마다 확인하는 범위가 다르고 테스트 대상 자체가 일시적으로 접속 불가일 수도 있습니다. 테스트 방법을 동일하게 유지한 뒤 비교하고 실제 접속 결과도 함께 확인하세요. Settings의 Proxy, TCP, UDP 설정은 서로 다른 동작에 영향을 줍니다. 처음 사용하는 경우 여러 항목을 동시에 바꾸지 않는 것이 좋습니다. 변경 전 기존 값을 기록해 두면 문제가 생겼을 때 되돌릴 기준이 생깁니다.
수동으로 끈 뒤 자동으로 다시 연결된다면 모든 구성을 삭제하지 말고 Settings에서 On Demand 조건을 확인하세요. 원인을 찾기 어렵다면 Diagnostics를 열어 확인 가능한 진단 정보를 살펴보고 발생 시각, 현재 네트워크, Global Routing 모드, 선택한 서버, 오류 현상을 기록합니다. 기록을 공유하기 전에 구독 주소, 비밀번호, 인증 식별 정보, 개인 네트워크 정보를 삭제하고 문제 파악에 필요한 부분만 남기세요.
이 절차는 처음 연결할 때 빠르게 확인하는 데 적합합니다. 지속적인 시간 초과, DNS 확인, 배터리 소모, 업데이트 후 이상, iPad 관련 문제는 문제 해결 매뉴얼을 참고하세요. 구성 항목의 의미는 용어 매뉴얼에서 확인할 수 있습니다. 마지막으로 정상 작동했던 구성의 복사본을 보관하면 알 수 없는 설정을 계속 추가하는 것보다 문제 재현과 복구에 도움이 됩니다.