연결 상태
스위치가 켜져 있으면 로컬 연결 상태가 바뀐 것입니다. 실제 요청을 추가로 확인해야 합니다.
공식 매뉴얼 · 첫 설정
iPhone / iPad 화면을 기준으로 “가져오기 → 모드 → 연결 → 확인 → 문제 해결” 순서에 따라 기본 설정을 진행합니다. 각 단계의 결과를 확인한 다음 다음 단계로 넘어가세요.
설정 추가부터 시작진행 순서
보유한 정보를 먼저 가져오기
먼저 보유한 정보의 종류를 구분합니다. 구독 링크 하나, 서버 공유 링크 하나, 또는 항목별로 정리된 서버 매개변수일 수 있습니다. 구독 링크는 여러 항목을 가져오는 데 사용하고, 수동 매개변수는 서버 하나의 정보를 나타냅니다. 두 가지 입력 경로는 비슷하지만 서로 섞어 입력할 수 없습니다. Shadowrocket을 열고 Home의 SERVER 그룹 근처에서 Add Server를 찾거나 화면의 추가 항목을 사용합니다. 페이지를 연 다음 Type을 먼저 확인하고, 구독 링크 전체를 Host에 붙여넣지 마세요.
Add Server에서 Type을 열고 Subscribe를 선택한 뒤, 사용자가 보유한 전체 구독 링크를 해당 URL 필드에 입력합니다. 복사할 때 물음표 뒤의 매개변수도 포함하고, 채팅 메시지에 포함된 따옴표, 공백 또는 줄바꿈은 섞지 마세요. 링크가 잘린 경우 기억에 의존해 보완하지 말고 원본에서 다시 복사합니다. 메모는 출처를 구별하기 위한 항목이므로 알아보기 쉬운 이름을 쓸 수 있지만, 인증 정보를 메모에 입력하지 마세요.
저장한 뒤 Home으로 돌아가 해당 구독을 업데이트하고 목록이 로드될 때까지 기다립니다. 가져오기가 완료되면 구독 이름만 있는 것이 아니라 실제 서버 항목이 표시되어야 합니다. 이름만 보이고 내용이 표시되지 않으면 먼저 업데이트가 완료되었는지 확인한 뒤 실패 지점 확인을 참고합니다. 나중에 구독을 업데이트하면 항목이 추가되거나 삭제될 수 있으므로, 업데이트 후 현재 선택한 서버가 목록에 있는지도 확인하세요.
수동으로 추가할 때는 먼저 정보에 맞는 Shadowsocks, VMess, VLESS, Trojan 등의 Type을 선택한 다음 Host, Port 및 해당 유형에 표시되는 인증 필드를 하나씩 확인합니다. 공식 스크린샷은 여러 필드 조합 중 하나를 보여줍니다. 모든 프로토콜에 Password와 Method가 함께 표시되는 것은 아니며, 한 프로토콜의 매개변수를 다른 프로토콜에 그대로 적용할 수도 없습니다. TLS, 전송 방식 또는 추가 필드가 있다면 보유한 서버 정보를 따르고, 확실하지 않은 필드는 임의로 바꾸지 마세요.
기존 QR 코드가 있다면 Scan QR Code로 가져온 다음 Type과 대상 주소를 확인합니다. Import from Cloud JSON은 다른 종류의 가져오기 경로이므로, 호환되는 정보가 있을 때만 사용합니다. 일반 구독 입력란으로 사용해서는 안 됩니다. 서버 공유 링크도 해당 가져오기 방법으로 처리하고, 추측한 매개변수로 나누어 입력하지 마세요. 저장 전에 포트, 인증 정보와 공백을 다시 확인하고, 저장 후 Home으로 돌아가 사용할 항목을 선택합니다.
이 단계의 완료 기준:Home에 선택 가능한 서버가 있고 현재 어떤 항목을 선택했는지 확인할 수 있습니다. 아직 연결 스위치를 켤 필요는 없습니다. 다음 단계에서 요청을 규칙에 따라 분리할지, 한 가지 방식으로 처리할지 결정합니다. 구독 링크에는 접근 자격 증명이 포함될 수 있으므로 스크린샷이나 진단 기록을 공유하기 전에 전체 링크와 인증 필드를 가리세요.
요청 처리 방식을 먼저 결정
Home으로 돌아가 Global Routing을 엽니다. 여기에는 Config / Proxy / Direct 세 가지 모드가 있습니다. 요청이 이후 처리 과정으로 전달되는 방식을 결정하며, 세 가지 서버 프로토콜을 뜻하지 않습니다. 서버를 선택하는 것은 “어떤 기존 연결 정보를 사용할지”를 결정하고, Global Routing을 선택하는 것은 “요청을 어떻게 처리할지”를 정합니다. 두 항목을 각각 확인해야 합니다.
도메인, IP 등의 규칙에 따라 경로를 정하려면 Config를 선택하고 Config에서 현재 활성화된 구성 파일을 확인합니다. 구독을 가져오는 것은 보통 서버 목록을 관리하기 위한 작업이며, 규칙 구성까지 완료되었다는 뜻은 아닙니다. 현재 사용하는 구성을 열어 General, Rule 등의 구간을 확인합니다. 파일이 여러 개라면 편집하기 전에 선택된 파일을 확인해, 다른 파일을 수정하고도 변경 사항이 보이지 않는 상황을 피하세요.
Rule의 항목은 순서대로 매칭되며 먼저 일치하는 규칙이 다음 정책을 결정합니다. 앞선 규칙에 매칭되지 않았을 때는 FINAL이 마무리 역할을 합니다. 규칙에서 PROXY 또는 정책 그룹을 참조한다면 현재 구성에 해당 이름의 정의와 사용 가능한 선택 항목이 있는지도 확인합니다. 아래는 구조를 보여주는 한 줄의 예시이며, 현재 파일을 그대로 대체할 수 있는 완성된 구성은 아닙니다.
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-SUFFIX는 규칙 키워드, example.com은 예시 도메인, PROXY는 정책 참조입니다. 규칙을 추가하기 전에 현재 구성의 사본을 보관하고, 첫 연결을 완료하기 위해 Hosts, URL Rewrite, HTTPS Decryption을 동시에 수정하지 마세요. 처음 설정할 때는 기존 구성을 사용 중인지, 규칙 참조가 빠지지 않았는지만 확인하면 됩니다. 구체적인 키워드의 의미는 용어집에서 확인하고, 복잡한 매칭 문제는 문제 해결 가이드를 참고하세요.
Proxy는 선택한 서버가 실제 요청을 처리할 수 있는지 잠시 비교할 때 유용합니다. Direct는 요청을 직접 접속하게 하여 로컬 네트워크 상태를 비교하는 데 사용할 수 있습니다. 모드를 바꿔도 잘못된 서버 암호가 수정되거나 누락된 구성이 자동으로 보완되지는 않습니다. Proxy에서는 접속되는데 Config에서는 되지 않는다면, 서버를 모두 다시 가져오기보다 규칙과 정책 참조를 먼저 확인합니다.
이 단계의 완료 기준:현재 모드와 Config에서 사용 중인 구성을 설명할 수 있어야 합니다. 테스트가 끝나면 원래 사용하려던 모드로 돌아가세요. 임시로 선택한 Proxy 또는 Direct를 장기 설정으로 두고 복원하는 것을 잊지 않도록 주의합니다.
선택을 확인한 다음 연결
Home으로 돌아가 SERVER 그룹에서 선택된 항목을 확인한 다음 Global Routing을 확인합니다. 처음 사용할 때는 서버 하나를 고정해 전체 확인 절차를 진행하는 것이 좋습니다. 테스트할 때마다 서버를 바꾸면 변화가 서버, 모드 또는 로컬 네트워크 중 어디에서 비롯되었는지 판단하기 어렵습니다. 구독을 방금 업데이트했다면 선택 항목을 다시 확인하고, 특히 이름이 같은 항목이나 업데이트로 삭제된 항목에 주의하세요.
상단에 Not Connected가 표시되면 연결 스위치를 켭니다. 처음 연결할 때는 시스템에서 VPN 구성을 추가하도록 허용하고 기기 암호 또는 생체 인증을 요청할 수 있습니다. 방금 연 Shadowrocket에서 시작한 작업인지 확인한 뒤 시스템 안내에 따라 승인합니다. 승인을 취소했다면 앱으로 돌아가 다시 시작하면 됩니다. 시스템 확인 창을 처리하기 전에 스위치를 연속해서 누르지 마세요.
승인 후 상태가 업데이트될 때까지 기다립니다. 스위치가 켜지고 앱의 연결 상태가 바뀌면 로컬 터널이 연결을 시도한 것입니다. 원격 서버로 모든 대상에 접속할 수 있다거나 Config의 모든 규칙이 올바르다는 뜻은 아닙니다. 상태가 바뀌면 현재 서버와 모드를 유지하고 다음 단계의 테스트를 진행합니다. 스위치가 바로 꺼지면 Rule을 계속 수정하기보다 먼저 시스템 안내를 기록하세요.
기기에서 다른 VPN 연결이나 네트워크 확장을 함께 사용하는 경우 이번 연결에 영향을 줄 수 있습니다. 현재 필요하지 않은 VPN 세션을 종료한 다음 Shadowrocket으로 돌아와 재현 가능한 연결 테스트를 한 번 진행합니다. 관리되는 기기에서 VPN 추가가 제한되어 있다면 기기 관리 정책을 확인하거나 관리자에게 문의하세요. 용도를 알 수 없는 프로파일을 반복해서 삭제하지 마세요.
직접 연결을 끊으려면 Home으로 돌아가 스위치를 끕니다. 껐는데도 자동으로 다시 연결된다면 Settings에서 On Demand 활성화 여부와 조건을 확인합니다. 자동 연결의 원인을 먼저 파악한 뒤 기능을 일시적으로 끌지 결정하세요. 이 단계의 완료 기준:스위치 상태가 유지되고 현재 서버 및 Global Routing을 기록한 다음 실제 요청으로 확인할 수 있어야 합니다.
테스트 결과와 실제 사용을 구분
연결한 뒤 Home에서 Connectivity Test를 실행하고, 사용할 서버가 현재 테스트 방식에 따라 테스트를 완료할 수 있는지 확인합니다. 테스트 결과는 해당 테스트 조건에서의 연결 여부만 확인합니다. 대역폭 측정이 아니며 모든 웹사이트, 프로토콜 및 앱을 사용할 수 있다는 증거도 아닙니다. 이름이 비슷한 항목이 여러 개라면 목록의 다른 항목이 아니라 현재 선택한 항목에 해당하는 결과인지 확인하세요.
그다음 브라우저를 열어 평소 사용하며 결과를 명확히 확인할 수 있는 페이지에 접속하고 요청을 새로 보냅니다. 이미 로드된 페이지나 로컬 캐시만 보지 마세요. 페이지를 새로고침하고 “열림”, “오래 대기”, “이름 확인 실패” 등의 구체적인 상태를 기록할 수 있습니다. 평소 사용하는 앱도 하나 더 확인해 단일 앱의 문제인지 모든 요청의 문제인지 구분합니다. 페이지에 내용이 표시되었다는 사실만으로 프록시를 통과했다고 판단할 수는 없습니다. Config에서 해당 요청이 DIRECT로 처리될 수 있기 때문입니다.
규칙 분기를 확인하려면 먼저 대상이 어떤 규칙과 일치해야 하는지 정한 뒤, 현재 앱에서 확인할 수 있는 요청 기록이나 진단 정보를 살펴봅니다. 시스템의 VPN 표시만 보는 것보다 도메인, 일치한 항목 및 정책 선택을 확인하는 편이 유용합니다. 대상 도메인이 다른 도메인으로 리디렉션될 수 있으므로 최초 주소와 이후 요청이 같은 규칙과 일치하지 않을 수 있습니다. 이 경우 실제 요청 도메인을 먼저 기록하고 범위가 넓은 규칙을 한꺼번에 추가하지 마세요.
Config에서 실패하면 같은 서버를 유지한 채 잠시 Proxy로 전환해 같은 요청을 다시 테스트합니다. Proxy에서는 성공하고 Config에서 실패한다면 규칙, 정책 그룹 선택 또는 관련 DNS 설정을 계속 확인해야 합니다. Direct에서는 성공하고 Proxy에서 실패한다면 서버 연결 정보와 원격 서버의 사용 가능 여부를 먼저 확인합니다. 비교할 때는 모드 하나만 변경하고 네트워크 변경, 서버 변경, DNS 수정은 동시에 하지 마세요. 그래야 결과를 해석할 수 있습니다.
이 단계의 완료 기준:서버 테스트와 실제 접속을 각각 한 번 이상 완료하고, 두 결과가 각각 무엇을 의미하는지 알 수 있어야 합니다. 기록한 뒤 계획한 Global Routing 모드로 돌아갑니다. 결과가 예상과 다르다면 모든 설정을 처음부터 지우지 말고 구체적인 실패 지점을 확인해 다음 단계를 진행하세요.
스위치가 켜져 있으면 로컬 연결 상태가 바뀐 것입니다. 실제 요청을 추가로 확인해야 합니다.
Connectivity Test는 테스트 조건에서의 연결 상태를 확인합니다. 규칙 적용 여부는 일치 항목과 정책도 확인해야 합니다.
가장 먼저 실패한 지점부터 확인
문제 해결 순서는 “구독 내용을 가져올 수 있는가 → 서버 테스트가 되는가 → VPN 연결이 유지되는가 → 실제 요청이 완료되는가”입니다. 가장 먼저 실패한 항목을 해결한 다음 진행합니다. Settings를 열면 Test Method, On Demand, Diagnostics 등의 항목을 볼 수 있습니다. 이 페이지에서는 첫 연결에 필요한 점검만 다루며 Proxy, TCP, UDP의 모든 옵션을 수정할 필요는 없습니다.
먼저 다운로드 실패와 파싱 후 항목이 없는 상황을 구분합니다. 다운로드에 실패했다면 로컬 네트워크에서 일반 페이지에 정상적으로 접속할 수 있는지, 구독 링크가 완전한지, 기존 인증 정보가 아직 유효한지 확인합니다. 다운로드는 완료됐지만 목록이 비어 있다면 링크가 호환되는 구독 내용을 반환하는지, 로그인 페이지나 오류 안내를 반환하는지 확인합니다. 공개된 페이지에 전체 링크를 붙여넣어 도움을 요청하지 마세요. 원본 정보 제공자에게 확인해야 한다면 필요한 오류 안내와 자격 증명을 가린 스크린샷만 보내세요.
Settings에서 Test Method를 확인해 현재 테스트 조건을 파악한 다음 Home으로 돌아가 같은 항목을 다시 테스트합니다. 시간 초과는 테스트 방식, 서버 주소, 포트 또는 사용 중인 네트워크와 관련이 있을 수 있습니다. 한 번의 결과만으로 모든 구성이 작동하지 않는다고 판단할 수 없습니다. 수동으로 추가한 항목은 Type, Host, Port 및 인증 필드를 다시 대조합니다. 구독 항목은 먼저 업데이트한 다음 선택된 항목이 바뀌지 않았는지 확인합니다. 다른 로컬 네트워크에서 테스트한다면 그 변경 사항을 별도로 기록하세요.
스위치가 바로 꺼지면 시스템의 VPN 승인, 다른 VPN 세션 및 기기 관리 제한을 먼저 확인합니다. 스위치 상태는 유지되지만 접속할 수 없다면 앞 절을 참고해 Config, Proxy 및 Direct를 비교한 뒤 서버, 규칙 또는 DNS 중 무엇을 확인할지 결정합니다. 도메인이 열리지 않는다고 DNS 옵션을 모두 바로 수정하지 마세요. 오류가 도메인 요청에서만 발생하는지, 규칙 또는 정책 참조에 불일치가 있는지 먼저 살펴봅니다.
스위치를 끈 뒤 자동으로 다시 연결된다면 On Demand의 트리거 조건을 확인합니다. 특정 앱에서만 오류가 발생한다면 이전 세션을 그대로 사용 중인 것이 아니라 해당 앱이 새 연결을 설정했는지 확인하세요. 진단이 필요하다면 Diagnostics를 열고 실패 시점의 작업, 선택된 모드 및 오류 정보를 기록합니다. 진단 기록에는 대상 도메인, 서버 주소 또는 인증 관련 정보가 포함될 수 있으므로 공유 전에 항목별로 확인하고 민감한 내용을 가리세요.
한 번에 설정 하나만 변경하고 같은 대상을 다시 테스트합니다. 개선되지 않으면 원래 값으로 되돌려 임시 변경이 새로운 문제를 만들지 않도록 합니다. 문제가 해결되면 현재 작동하는 구성의 사본을 보관한 다음 고급 기능을 하나씩 추가합니다. 더 많은 증상별 절차는 문제 해결 가이드, 구매 및 복구 관련 내용은 질문과 답변, 프로토콜과 규칙 용어는 용어집을 확인하세요. 처음 설정하는 과정은 여기서 마칠 수 있으며 모든 기능을 한꺼번에 설정할 필요는 없습니다.