먼저 테스트 응답 확인
Home에서 Connectivity Test를 실행하고 이번 테스트가 완료될 때까지 기다립니다. 테스트 결과는 Test Method, 테스트 대상, 로컬 네트워크, 서버 상태에 따라 달라집니다. 한 번의 응답은 해당 시점의 테스트 결과만 보여 줄 뿐 모든 앱과 웹사이트에서 사용할 수 있다는 뜻은 아닙니다.
공식 가이드 / 시작하기
「추가 → 모드 선택 → 연결 → 확인 → 문제 해결」 순서로 진행하세요. 각 단계의 결과를 확인한 뒤 다음 단계로 넘어가세요. 프로토콜 매개변수와 규칙 원리는 프로토콜 참고 자료에서 확인할 수 있습니다.
시작 전: App Store에서 Shadowrocket을 설치했고 본인의 구독 링크나 서버 정보를 보유해야 합니다. 이 사이트는 노드, 구독 또는 연결 서비스를 제공하거나 판매하거나 추천하지 않습니다. 앱은 한 번 구매하는 방식이며 회선 요금제가 아닙니다. 앱을 구매해도 연결에 필요한 서버 정보가 자동으로 제공되지는 않습니다.
아직 설치하지 않았다면 먼저 App Store 정품 확인 및 구매 안내를 확인하세요. 이 가이드는 iPhone / iPad를 기준으로 설명합니다. 시스템 요구 사항은 App Store 페이지에 표시된 내용을 따르세요.
이미지는 App Store 공식 스크린샷으로, 화면과 입력 항목을 확인하는 데 사용됩니다. 실제 조작 시에는 기기에 표시되는 화면을 기준으로 하세요. 스크린샷의 예시 내용을 그대로 입력할 필요는 없습니다.
단계 01 / 사용할 항목 준비
Shadowrocket을 열고 Home으로 이동합니다. 보유한 정보가 서버 매개변수, 단일 서버 공유 링크, QR 코드, 구독 링크 중 무엇인지 먼저 확인하세요. 정보 유형마다 가져오는 방법이 다릅니다. 구독 링크는 여러 항목을 가져오고 업데이트하는 데 사용하고, 서버 매개변수는 하나의 항목을 만드는 데 사용합니다. 링크가 HTTPS로 시작한다는 이유만으로 구독 링크라고 단정하지 마세요.
Home의 SERVER 영역에서 Add Server를 찾아 추가 화면을 엽니다. 먼저 Type을 눌러 보유한 정보에 해당하는 프로토콜 유형을 선택한 다음 Host와 Port를 입력합니다. Host는 서버 도메인 또는 IP 주소이고 Port는 서버에서 지정한 포트입니다. 공유 링크 전체를 Host에 입력하거나 주소의 경로와 쿼리 매개변수를 서버 이름으로 입력하지 마세요.
Type에 따라 이후 입력 항목이 달라집니다. 스크린샷에는 Password, Method 등의 항목이 있지만 모든 프로토콜이 같은 매개변수를 사용하는 것은 아닙니다. Password, UUID, Method, TLS 관련 매개변수와 전송 설정은 원본 정보에 맞춰 각각 입력해야 합니다. 다른 프로토콜의 항목으로 대신할 수 없습니다. 포트나 인증 정보의 문자 하나만 달라도 저장은 되지만 연결되지 않을 수 있습니다. 입력 후 저장하고 Home으로 돌아가 SERVER에 추가한 항목이 표시되는지 확인하세요.
QR 코드가 있으면 Add Server에서 Scan QR Code를 선택하고 시스템 안내에 따라 카메라 사용을 허용한 뒤 QR 코드를 화면에 온전히 맞춥니다. 인식 후 Type, 주소, 포트를 확인하고 저장하세요. QR 코드는 정보를 담는 수단일 뿐, 내용이 올바르다는 보장은 아닙니다. 카메라가 인식하지 못하면 화면이 선명한지, QR 코드가 잘리지 않았는지, 클라이언트가 인식할 수 있는 설정이 포함되어 있는지 확인하세요.
단일 서버 공유 링크가 있다면 전체 내용을 복사하고 앱으로 돌아가 표시되는 가져오기 안내에 따라 진행할 수 있습니다. 안내가 표시되지 않으면 복사한 내용에 불필요한 설명이 포함되어 있는지 확인하세요. Import from Cloud JSON은 해당 JSON 정보에 사용하는 기능이지, 일반 구독 가져오기 기능이 아닙니다. 형식을 알 수 없는 내용은 반복해서 Type을 바꿔 입력하지 말고, 먼저 정보를 제공한 곳에 형식을 확인하세요.
Add Server의 Type에서 Subscribe를 선택하고 본인의 구독 링크 전체를 URL 항목에 입력한 다음 저장하고 가져오기가 완료될 때까지 기다립니다. Home으로 돌아가 구독 그룹과 항목이 표시되는지 확인하세요. 구독 주소에는 비공개 접근 식별 정보가 포함될 수 있으므로 쿼리 매개변수를 모두 유지하되 스크린샷, 토론 게시판 또는 공개 문서에 공유하지 마세요.
구독 그룹만 표시되고 서버 항목이 하나도 없다면 먼저 현재 네트워크에서 해당 주소에 접근할 수 있는지, 구독 내용이 여전히 유효한지 확인하세요. 빈 그룹을 가져오기 완료로 간주하지 마세요. 구독을 업데이트하면 항목이 추가되거나 삭제될 수 있으므로 이름을 바꾸거나 정리하기 전에 원본 정보를 보관하세요. 우선 원본과 일치하는 항목이 하나 이상 있는지 확인하고, 다음 단계에서 트래픽 처리 방식을 선택하세요.
단계 02 / 트래픽 처리 방식 선택
항목을 추가한 뒤 Home으로 돌아가 Global Routing을 누릅니다. 여기서는 클라이언트가 처리하는 연결을 어떤 방식으로 다룰지 결정합니다. 서버를 선택하는 화면이 아닙니다. 세 가지 모드는 구성(Config), 프록시(Proxy), 직접 연결(Direct)입니다. 모드를 선택하기 전에 테스트 목적을 명확히 하세요. 현재 모드를 모르는 상태에서 웹페이지 결과만으로 서버 상태를 판단하지 마세요.
구성(Config)은 현재 활성화된 구성 파일에 따라 요청을 처리합니다. Config로 이동해 목록에 파일이 있는지만 확인하지 말고 실제로 어떤 파일이 선택되어 있는지 확인하세요. 서버 추가와 구성 파일 추가는 별개의 작업입니다. 구독에 서버 항목이 표시된다고 해서 필요한 라우팅 규칙까지 가져오거나 활성화된 것은 아닙니다. 이미 구성 파일이 있다면 출처와 내용을 확인한 다음 선택해 사용하세요.
공식 스크린샷에는 구성 편집 화면의 General, Rule, Hosts, URL Rewrite, HTTPS Decryption 섹션이 표시되어 있습니다. 처음 사용할 때는 Rule을 중점적으로 확인하세요. 규칙은 일반적으로 위에서 아래 순서로 검사하며, 규칙이 일치하면 해당 정책이 적용됩니다. DIRECT는 직접 연결, PROXY는 프록시 정책 사용, REJECT는 거부를 뜻합니다. 범위가 넓은 규칙이 너무 앞에 있으면 뒤의 구체적인 규칙이 검사되지 않을 수 있습니다.
이 가이드에서는 HTTPS Decryption을 수정하거나 재작성 기능을 켤 필요가 없습니다. 이해하기 쉬운 기본 구성으로 먼저 연결을 확인하고, 복잡한 설정은 기본 확인을 마친 뒤 진행하세요. 현재 파일의 정책이 어디로 향하는지 확실하지 않다면 원본 파일을 보존한 다음 프로토콜 참고 및 매개변수 안내와 규칙과 라우팅 관련 문제를 확인하세요. 첫 연결을 위해 여러 섹션을 한꺼번에 수정하지 마세요.
프록시(Proxy)는 클라이언트가 처리하는 연결을 프록시 방식으로 처리하며, 구성(Config)과 통제된 조건으로 비교할 때 사용할 수 있습니다. 모든 대상 서비스에 접속할 수 있다고 보장하지 않으며 서버 매개변수 확인을 대신하지도 않습니다. 프록시(Proxy)에서는 접속되지만 구성(Config)에서는 같은 대상에 접속되지 않는다면 서버를 바로 삭제하지 말고 현재 구성 파일과 일치한 정책부터 확인하세요.
직접 연결(Direct)은 트래픽을 직접 연결 방식으로 처리하며 현재 로컬 네트워크에서 대상에 접속되는지 확인할 때 사용할 수 있습니다. 선택한 서버를 통해 프록시 연결이 성공했다는 뜻은 아닙니다. 모드를 비교할 때는 같은 대상 페이지와 같은 로컬 네트워크를 유지하고, 매번 모드 하나만 바꾼 뒤 새 요청을 보내세요. 비교가 끝나면 실제로 필요한 모드로 되돌린 다음 연결 단계로 진행하세요.
단계 03 / 클라이언트 연결
Home으로 돌아가 SERVER 목록에서 사용할 서버를 누르고 선택 표시가 원하는 항목에 있는지 확인합니다. 구독 그룹에는 이름이 비슷한 항목이 여러 개 있을 수 있으므로 주소나 기존 메모를 참고해 구분하세요. 목록에 항목이 있다는 것은 정보가 저장되었다는 뜻일 뿐, 선택되었거나 클라이언트가 연결 중이라는 뜻은 아닙니다.
Global Routing에 표시된 모드를 다시 확인한 다음 상단의 Not Connected에 해당하는 연결 스위치를 켭니다. 처음 사용할 때 시스템에서 VPN 구성을 추가할지 물어볼 수 있습니다. 이는 Shadowrocket이 시스템 네트워크 구성을 만들도록 허용하는 절차입니다. 연결 서비스를 구매하는 과정이 아니며 서버 매개변수를 대신 입력하지도 않습니다. 직접 시작한 작업인지 확인한 후 시스템 안내에 따라 허용하고 기기에서 요구하는 본인 인증을 완료하세요.
방금 권한 요청을 취소했다면 앱으로 돌아가 연결 스위치를 다시 켜고 실제로 표시되는 시스템 안내에 따라 진행하세요. 기기 관리 정책에 제한이 있으면 권한을 직접 변경하지 못할 수 있으므로 먼저 기기 관리 요구 사항을 확인하세요. 권한 문제를 해결하려고 앱을 반복해서 삭제하지 마세요. 로컬 설정이 손실될 위험이 커집니다. 권한 승인과 서버 인증은 별개의 절차입니다. VPN 구성 추가를 허용해도 잘못된 Host, Port, Password가 수정되지는 않습니다.
권한을 승인한 후 Home으로 돌아가 상단 연결 상태가 Not Connected에서 바뀌는지 확인합니다. 스위치가 바로 꺼지거나 상태 변경이 지연되면 반복해서 전환하지 말고 현재 모드, 선택한 항목, 안내 문구를 기록하세요. 서버를 바꾸거나 매개변수를 수정할 때는 먼저 연결을 끄고 변경을 완료한 뒤 다시 연결하는 것이 좋습니다. 그러면 이번 테스트에 사용된 정보가 무엇인지 확인하기 쉽습니다.
시스템에 VPN 표시가 나타나는 것은 시스템 수준의 VPN 연결 상태만 보여 줍니다. 대상 웹사이트에 접속할 수 있다거나 규칙이 예상대로 적용되었다는 사실을 단독으로 증명하지는 않습니다. Home에서 연결 상태를 확인한 뒤 현재 항목과 모드를 유지하고 다음 단계에서 실제 요청을 테스트하세요. 수동 테스트 중 다른 조건으로 연결이 다시 시작되지 않도록 지금은 추가 자동 연결 조건을 켜지 마세요.
단계 04 / 연결 상태와 접속 결과 구분
Home에서 Connectivity Test를 실행하고 이번 테스트가 완료될 때까지 기다립니다. 테스트 결과는 Test Method, 테스트 대상, 로컬 네트워크, 서버 상태에 따라 달라집니다. 한 번의 응답은 해당 시점의 테스트 결과만 보여 줄 뿐 모든 앱과 웹사이트에서 사용할 수 있다는 뜻은 아닙니다.
같은 서버와 모드를 유지한 채 브라우저에서 새 페이지를 열어 알려진 대상에 접속합니다. 페이지 본문과 필요한 리소스가 로드되는지 확인하세요. 기존 탭, 캐시된 페이지, 이미 연결된 세션은 설정 변경 결과를 가릴 수 있으므로 모드를 비교할 때는 새 요청을 사용하세요.
Connectivity Test에 응답이 있지만 웹페이지가 열리지 않는다고 해서 바로 서버를 사용할 수 없는 것으로 판단하지 마세요. 테스트 대상과 웹페이지 대상은 다르며 도메인 확인, TLS 핸드셰이크, 대상 사이트 상태, 규칙 정책도 서로 다를 수 있습니다. 먼저 모든 페이지가 실패하는지 특정 도메인만 실패하는지 기록하세요. 그런 다음 현재 구성에서 해당 도메인이 DIRECT와 PROXY 중 어떤 정책을 적용받아야 하는지 확인합니다. 필요하면 앱의 실제 요청 기록에서 대상, 일치한 규칙, 최종 정책을 확인하세요.
구성(Config)의 동작을 확인하려면 규칙이 명확한 대상을 선택해 새 요청을 보낸 다음 해당 기록을 살펴보세요. 페이지가 열린 속도만으로 프록시 사용 여부를 판단하거나, 하나의 외부 IP 확인 페이지만으로 모든 트래픽 처리 방식을 추론하지 마세요. 규칙에 따라 도메인마다 적용되는 정책이 다를 수 있으므로 구체적인 대상을 기준으로 확인해야 합니다.
클라이언트 연결을 끄고 같은 로컬 네트워크에서 동일한 대상에 접속해 기준 결과와 비교할 수도 있습니다. 연결을 꺼도 접속되지 않는다면 로컬 네트워크나 대상 자체의 문제도 확인해야 합니다. 구성(Config)에서만 실패하고 프록시(Proxy)에서는 같은 요청이 성공한다면 구성 규칙부터 살펴보세요. 테스트 중 Wi-Fi, 서버, 모드를 동시에 바꾸면 어떤 변경이 결과에 영향을 줬는지 파악하기 어렵습니다.
첫 확인에서는 세 가지만 보면 됩니다. Home에서 연결이 유지되는지, 실제 대상에 요청을 완료할 수 있는지, 모드와 규칙이 사용 목적에 맞는지 확인하세요. 속도와 장시간 안정성은 실제 사용 조건에서 별도로 살펴봐야 하며, 한 번의 Connectivity Test만으로 결론을 내릴 수 없습니다. 확인을 마친 뒤 필요한 일상 모드로 되돌리고, 문제가 있으면 아래 단계별 점검을 진행하세요.
단계 05 / 한 번에 하나씩 변경
먼저 문제가 발생한 단계를 기준으로 원인을 좁히세요. 가져온 내용이 없으면 정보 형식을 확인하고, 항목은 있지만 연결되지 않으면 매개변수와 권한을 확인하며, 연결되지만 접속되지 않으면 DNS, 규칙, 대상을 확인합니다. 이렇게 하면 구독 가져오기 실패 시 Rule을 반복해서 수정하거나 인증 항목 오류와 무관한 시스템 설정을 바꾸는 일을 피할 수 있습니다.
원본 정보가 완전한지 다시 확인하세요. 특히 구독 URL의 쿼리 매개변수, 공유 링크의 접두 부분, QR 코드 가장자리를 살펴봅니다. 현재 네트워크에서 구독을 가져올 수 있는지, 설정 내용 대신 로그인 페이지나 일반 웹페이지가 반환되는지 확인하세요. 비공개 구독 주소를 출처가 불분명한 온라인 변환 페이지에 입력하지 마세요. 형식을 확인한 뒤 한 번 더 가져오고 Home에서 항목을 확인하세요. 그래도 문제가 있으면 정보를 제공한 곳에 내용이 유효한지 문의하세요.
먼저 시스템 VPN 구성 권한을 확인한 다음 선택한 항목의 Type, Host, Port, 인증 항목을 확인하세요. TLS나 특정 전송 매개변수가 필요한 항목은 서버 이름과 관련 설정도 확인해야 합니다. Password만 확인해서는 안 됩니다. 신뢰할 수 있는 다른 로컬 네트워크에서 결과가 달라진다면 그 차이를 기록하되, 특정 프로토콜이 반드시 문제를 해결한다고 단정하지 마세요. 프로토콜 항목의 자세한 의미는 프로토콜 참고 자료에서 확인할 수 있습니다.
Settings에서 Test Method를 확인하고 Connectivity Test가 사용하는 방식을 파악한 다음 실제 웹페이지 요청과 구분하세요. 이어서 현재 구성의 DNS 설정과 Rule을 확인합니다. 도메인으로 접속되지 않지만 다른 테스트에는 응답이 있다면 도메인 확인도 점검할 항목 중 하나입니다. 다만 이 현상만으로 원인을 단정할 수는 없습니다. 인증서와 사이트 선택에도 도메인이 필요하므로 HTTPS 도메인 대신 IP 주소를 임의로 사용하지 마세요.
Settings에서 On Demand를 확인하세요. 설정된 조건에 따라 연결을 시작하는 기능이며 잘못된 서버 매개변수를 자동으로 수정하지는 않습니다. 문제를 확인하는 동안 On Demand를 잠시 꺼서 수동 스위치의 실제 동작을 살펴볼 수 있습니다. 수동 연결과 대상 요청이 모두 정상인지 확인한 뒤 필요한 조건을 하나씩 복원하고 로컬 네트워크를 바꿨을 때 예상대로 동작하는지 확인하세요.
Settings의 Diagnostics에서 확인 가능한 진단 정보를 볼 수 있습니다. 단순히 「작동하지 않음」이라고만 설명하기보다 문제가 발생한 상황, 현재 Global Routing, 테스트 방식, 오류 안내를 기록하면 원인을 좁히는 데 도움이 됩니다. 기록을 공유하기 전에 서버 개인 주소, 구독 URL, 인증 항목과 기타 식별 정보를 숨기세요. 전체 구성을 공개할 필요는 없습니다.
한 번에 하나만 변경하고 4단계에서 진행한 동일한 검증을 반복하세요. 변경 전 원래 구성을 보관하고, 복구할 수 있는지 확인한 뒤 다음 시도를 진행합니다. 구독 상태, 서버 인증서, 인증 정보에 관한 문제는 해당 정보를 제공한 곳에 확인하세요. 구매, 기기 호환성 또는 구매 항목 복원 문제는 구매 항목 복원 안내를 확인하세요. 그 밖의 상황은 자주 묻는 질문에서 확인할 수 있습니다. 한 가지 실패 현상을 해결하려고 모든 설정을 동시에 바꾸지 마세요.
기본 조작을 마친 뒤 필요에 따라 프로토콜 항목이나 규칙 세부 내용을 확인하세요. 복구할 수 있는 구성을 보관하고 이후에도 「항목 하나 변경 → 새 요청 → 결과 비교」 순서를 따르세요.