이 글은 Shadowrocket을 처음 사용하는 iPhone 및 iPad 사용자를 대상으로 합니다. 기존 설정 준비, 가져오기, 라우팅 선택, 연결, 확인, 문제 해결 순서로 자주 묻는 10가지 질문에 답합니다. 기본 설정을 직접 완료하고 문제가 설정, DNS, 로컬 네트워크 또는 원격 회선 중 어디에서 발생했는지 판단할 수 있습니다.
1. 시작하기: 기존 서버 추가와 구독 가져오기
질문 1: Shadowrocket을 처음 열 때 무엇을 먼저 준비해야 하나요?
Shadowrocket은 Apple 플랫폼용 유료 클라이언트이며, 유일한 공식 구매 경로는 App Store입니다. 구매 전에 개발자가 Shadow Launch Technology Limited인지, 앱 ID가 932747118인지 확인할 수 있습니다. iPhone과 iPad가 주요 사용 기기이며, Mac, Apple TV 및 Apple Vision의 호환 여부와 모든 시스템 요구 사항은 App Store 페이지 표기를 기준으로 합니다.
클라이언트와 네트워크 회선은 별개의 요소입니다. Shadowrocket을 일회성으로 구매해도 클라이언트 사용 권한만 제공되며 서버 주소, 포트, 비밀번호 또는 구독 URL이 자동으로 생성되지는 않습니다. 설정을 시작하기 전에 본인이 이용 중인 서비스 제공업체가 제공한 연결 매개변수나 구독 주소를 준비해야 합니다.
앱 확인
App Store에서 Shadowrocket 제품 페이지를 열고 개발자가 Shadow Launch Technology Limited인지, URL에 id932747118이 포함되어 있는지 확인합니다.
매개변수 준비
기존 설정이 Shadowsocks, VMess, VLESS, Trojan, Hysteria2 또는 WireGuard 중 어떤 프로토콜을 사용하는지 확인하고, 서비스 제공업체가 안내한 모든 필드를 기록합니다.
가져오기 방식 선택
단일 서버는 Home 오른쪽 위의 “+”에서 직접 입력할 수 있으며, 서비스 제공업체가 관리하는 여러 서버는 Subscribe를 사용할 수 있습니다.
첫 연결 완료
저장한 뒤 Home으로 돌아가 항목을 선택하고 상단 연결 스위치를 켠 다음, 시스템 안내에 따라 VPN 구성 추가를 허용합니다.
질문 2: 기존 서버 하나를 수동으로 추가하려면 어떻게 하나요?
Home으로 이동해 오른쪽 위의 “+”를 누르고, 먼저 기존 매개변수와 정확히 일치하는 프로토콜을 Type에서 선택합니다. 그런 다음 Address, Port, Password 또는 해당 프로토콜의 인증 필드를 입력합니다. 포트는 1에서 65535 사이의 정수여야 하지만 구체적인 값은 기존 서비스 설정에 따라 정해지므로 프로토콜 이름만 보고 추측해서는 안 됩니다.
VMess, VLESS, Trojan 등의 설정에는 TLS, SNI, Transport, Path 또는 WebSocket Host가 포함될 수 있습니다. WireGuard는 일반적으로 Private Key, Public Key, Address, DNS 및 Peer Endpoint를 사용합니다. 서버 주소와 포트만 입력하는 것으로는 이러한 필드를 대신할 수 없으며, 하나라도 일치하지 않으면 시간 초과 또는 핸드셰이크 실패로 나타날 수 있습니다.
- Type: 원본 설정의 프로토콜과 반드시 일치해야 합니다. 예를 들어 Shadowsocks와 Trojan은 서로 바꿔 사용할 수 없습니다.
- Address: 도메인 또는 IP 주소를 입력하고 불필요한 공백은 추가하지 않습니다.
- Port: 서비스 설정에 지정된 포트를 입력하며 웹페이지 포트를 연결 포트로 사용하지 않습니다.
- Remarks: 지역, 용도 또는 회선 이름을 입력할 수 있으며, 로컬에서 구분하기 위한 용도일 뿐 연결에는 사용되지 않습니다.
- TLS 및 SNI: 기존 설정에 따라 활성화하고 입력해야 하며, 이름이 잘못되면 대개 핸드셰이크가 실패합니다.
2. 구독 가져오기, 새로 고침 및 실패 원인 확인
질문 3: 기존 구독 링크는 어떻게 추가하나요?
Home에서 오른쪽 위의 “+”를 누르고 Type을 Subscribe로 설정한 다음, URL에 전체 구독 주소를 붙여 넣고 알아보기 쉬운 Remark를 입력합니다. 형식 예시는 https://example.com/sub?token=xxxx이며, example.com과 xxxx는 예시 값입니다.
저장한 뒤 Home으로 돌아오면 구독 그룹이 보통 콘텐츠를 가져오기 시작합니다. 목록에서 해당 구독을 업데이트할 수도 있습니다. 업데이트가 완료되면 그룹 안에 서비스 제공업체가 반환한 서버 항목이 표시됩니다. 항목을 선택하는 것만으로는 연결되지 않으므로 Home의 연결 스위치도 켜야 합니다.
Type: Subscribe
URL: https://example.com/sub?token=xxxx
Remark: 기존 구독
업데이트 순서: 저장 → Home으로 돌아가기 → 구독 새로 고침 → 항목 선택질문 4: 구독 업데이트 시간이 초과되거나 항목이 표시되지 않으면 어떻게 하나요?
먼저 URL이 완전한지 확인하고, 특히 물음표 뒤의 token 매개변수가 복사 과정에서 누락되지 않았는지 점검합니다. 브라우저에서 주소가 열린다고 해서 반환된 내용이 Shadowrocket에서 인식할 수 있는 구독 형식이라는 뜻은 아닙니다. 로그인 안내, 빈 텍스트 또는 오류 코드가 반환되면 서비스 제공업체가 안내한 원본 주소를 확인해야 합니다.
현재 네트워크에서 구독 주소에 직접 접근할 수 없다면, 먼저 정상 작동하는 설정으로 연결한 뒤 다시 업데이트를 시도할 수 있습니다. Settings의 Subscribe 업데이트 관련 옵션은 현재 Proxy를 통해 가져올지 결정할 수 있지만, 기존 연결 자체가 작동할 때만 도움이 됩니다.
구독 업데이트가 계속 시간 초과되나요?
먼저 Wi-Fi와 셀룰러 네트워크를 한 번 전환한 뒤 URL이 완전한지 확인합니다. 사용 가능한 연결이 있다면 연결을 켠 상태에서 업데이트를 다시 시도하고 Settings에서 Subscribe 업데이트 경로 설정을 확인합니다.
업데이트는 완료됐는데 서버가 없나요?
반환된 내용이 빈 그룹이 아닌지 확인하고 서비스 제공업체가 구독 주소를 변경했는지 확인합니다. 삭제하기 전에 원래 Remark를 보존해 같은 이름의 여러 그룹이 섞이지 않도록 합니다.
새로 고침 후에도 이전 항목이 남아 있나요?
먼저 올바른 구독 그룹을 조작했는지 확인합니다. 구독 업데이트는 일반적으로 원격 콘텐츠와 동기화되며, 수동으로 추가한 독립 항목은 다른 구독에서 자동으로 관리되지 않습니다.
붙여 넣은 뒤 형식 오류가 표시되나요?
주소 앞뒤의 공백과 줄바꿈을 삭제하고 완전한 HTTPS URL을 사용했는지 확인합니다. 서비스 제공업체의 웹사이트 첫 화면, 주문 페이지 또는 안내문을 구독 주소로 사용하지 마세요.
매번 수동으로 새로 고쳐야 하나요?
Settings에서 Subscribe 관련 업데이트 옵션을 확인할 수 있지만, 실제 새로 고침 결과는 구독 주소에 접근할 수 있는지와 원격 응답 내용에 따라 달라집니다.
3. Global Routing 선택과 연결 스위치 비활성화 문제
질문 5: Global Routing의 Config, Proxy, Direct, Scene은 어떻게 다른가요?
Global Routing은 트래픽을 어떤 방식으로 처리할지 결정합니다. Config는 현재 구성 파일의 규칙을 순서대로 매칭하고, Proxy는 모든 트래픽에 현재 Proxy 정책을 적용하며, Direct는 트래픽을 직접 연결합니다. Scene은 미리 설정한 네트워크 시나리오에 따라 정책을 전환합니다. 일상적으로 규칙 설정을 사용할 때는 보통 Config부터 시작합니다.
Config의 결과는 규칙 순서와 최종 규칙에 따라 달라집니다. 자주 사용되는 키워드로는 DOMAIN-SUFFIX, GEOIP, IP-CIDR 및 FINAL이 있습니다. Shadowrocket은 앞에서부터 규칙을 매칭하고, 일치하면 해당 줄에 지정된 정책을 실행합니다. 앞선 규칙에 매칭되지 않은 트래픽은 FINAL이 처리합니다.
Config
권장현재 Config의 규칙에 따라 Proxy, Direct 또는 Reject 등의 정책을 적용하므로 도메인과 IP 범위별로 서로 다른 경로를 사용할 수 있습니다.
적합: 기존 규칙 설정을 일상적으로 사용할 때
Proxy
규칙 판단을 건너뛰고 모든 트래픽을 현재 선택한 Proxy 항목으로 전달하므로, 문제가 규칙 매칭에서 비롯되었는지 확인하기 쉽습니다.
적합: Proxy 연결을 임시로 확인할 때
Direct
트래픽을 현재 Proxy 항목을 거치지 않고 직접 연결합니다. 잘못 선택하면 연결 스위치가 켜져 있어도 예상한 경로 변화를 확인하지 못할 수 있습니다.
적합: 로컬 직접 연결 결과와 비교할 때
Scene
미리 설정한 Wi-Fi, 셀룰러 네트워크 등의 시나리오에 따라 해당 정책을 적용합니다. 사용하기 전에 시나리오 조건을 먼저 설정해야 합니다.
적합: 고정된 네트워크 환경에서 자동 전환할 때
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY위 규칙은 문법을 설명하기 위한 예시입니다. 첫 번째 줄은 도메인 접미사로 매칭하고, 두 번째 줄은 지정된 사설 주소 범위를 Direct로 설정하며, 세 번째 줄은 GEOIP 데이터로 매칭합니다. 마지막 줄은 앞에서 매칭되지 않은 연결을 처리합니다. 실제 정책 이름은 현재 Config에 존재하는 정책과 일치해야 합니다.
질문 6: Home의 연결 스위치가 회색으로 표시되거나 켜지지 않으면 어떻게 하나요?
먼저 Home 목록에서 유효한 서버 항목을 선택했는지 확인합니다. 구독 그룹 이름만 있고 선택할 항목이 없거나, 수동 설정에 필수 필드가 빠졌거나, 현재 선택 항목이 구독 업데이트로 삭제된 경우에는 설정을 먼저 수정한 뒤 연결을 시도해야 합니다.
처음 연결을 켜면 시스템에서 VPN 구성 추가를 요청합니다. 시스템 확인을 완료한 뒤 Shadowrocket으로 돌아옵니다. 이전 연결이 정상적으로 종료되지 않았다면 스위치를 먼저 끄고 몇 초 기다린 다음 다시 켭니다. 그래도 응답이 없으면 로컬 네트워크를 차례로 전환한 뒤 클라이언트를 다시 엽니다.
선택 항목 확인
Home으로 돌아가 서버 항목 앞에 명확한 선택 상태가 표시되는지 확인합니다. 비어 있는 구독 그룹만 선택한 상태가 아니어야 합니다.
필드 확인
항목을 열어 Address, Port, 인증 필드와 TLS, SNI, Transport 등의 프로토콜 매개변수가 모두 입력되어 있는지 확인합니다.
시스템 요청 확인
처음 연결할 때 시스템에 표시되는 VPN 구성 확인을 완료한 뒤 Home으로 돌아가 스위치를 조작합니다.
연결 재설정
현재 연결을 끄고 몇 초 기다린 뒤 다시 켭니다. 이어서 Wi-Fi와 셀룰러 네트워크에서 각각 테스트해 특정 네트워크의 제한인지 확인합니다.
Log 확인
관련 진단 또는 Log 페이지에서 DNS failure, timeout, TLS handshake 등 오류가 발생한 단계를 구분합니다.
4. 연결 표시 후 트래픽이 예상대로 처리되는지 확인하기
질문 7: 연결 스위치를 켠 뒤 실제로 적용됐는지 어떻게 확인하나요?
스위치 색상만으로 판단하지 마세요. 먼저 Home에서 Connectivity Test를 사용해 기본 연결을 확인한 다음, 이전에 캐시되지 않은 웹페이지를 열어 결과를 확인합니다. Global Routing이 Config라면 테스트 도메인이 실제로 어떤 규칙에 매칭됐는지도 확인해야 합니다.
그다음 Data 또는 Log를 확인합니다. Data에서는 연결 중 업로드 및 다운로드 트래픽이 발생했는지 볼 수 있고, Log에는 도메인 조회, 규칙 매칭, 대상 주소와 연결 오류가 표시됩니다. 페이지는 열리지만 Log에 Direct가 표시된다면 프로토콜 매개변수를 계속 바꾸기보다 규칙을 확인해야 합니다.
- 1단계: Home에서 올바른 항목을 선택했는지, 연결 스위치가 계속 켜져 있는지 확인합니다.
- 2단계: Connectivity Test가 연결을 설정할 수 있는지, 지연 시간이 계속 시간 초과되는지 확인합니다.
- 3단계: Global Routing이 예상한 방식으로 설정되어 있는지, Config에 올바른 규칙이 로드되었는지 확인합니다.
- 4단계: Log에서 대상 도메인이 Proxy, Direct 또는 Reject 중 어디에 매칭되었는지 확인합니다.
- 5단계: Data에 실제 방문 활동과 일치하는 업로드 및 다운로드 변화가 나타나는지 확인합니다.
질문 8: 지연 시간은 표시되는데 웹페이지가 열리지 않는 이유는 무엇인가요?
지연 시간 테스트는 특정 탐색 단계에서 응답을 받았다는 것만 보여 줄 뿐, DNS 조회, TLS 핸드셰이크와 대상 웹페이지 요청이 모두 성공했다는 뜻은 아닙니다. 목록의 지연 시간은 정상인데 Log에 DNS failure가 나타날 수 있고, TCP 연결이 성립된 뒤 TLS 또는 전송 매개변수가 일치하지 않아 중단될 수도 있습니다.
문제 해결 시 먼저 Direct로 로컬 네트워크와 비교한 다음 Proxy로 Config 규칙을 임시로 우회합니다. Direct에서는 접속되지만 Proxy에서 실패하면 현재 서버와 프로토콜 필드를 중점적으로 확인합니다. Proxy에서는 접속되지만 Config에서 실패하면 규칙 순서, 정책 이름과 FINAL을 확인합니다. 둘 다 실패하면 로컬 네트워크와 DNS를 점검합니다.
| 실제 현상 | 우선 확인할 항목 | 다음 단계 |
|---|---|---|
| 지연 시간이 계속 timeout | Address, Port, 로컬 네트워크 | Wi-Fi와 셀룰러 네트워크를 전환하고 서비스 매개변수와 비교 |
| 지연 시간은 정상인데 DNS failure 표시 | Settings의 DNS 설정 | 정상 작동이 확인된 설정으로 되돌린 뒤 테스트 도메인을 다시 조회 |
| Proxy는 작동하지만 Config는 작동하지 않음 | 규칙 순서와 정책 이름 | Log에서 실제로 매칭된 규칙 확인 |
| 핸드셰이크 직후 연결 해제 | TLS, SNI, Transport, 인증 필드 | 원본 설정과 항목별로 대조하고 프로토콜 매개변수를 섞어 사용하지 않기 |
5. On Demand 사용법과 설정 오류 점검 순서
질문 9: On Demand란 무엇이며 왜 켜면 자동으로 연결되나요?
On Demand는 네트워크 조건에 따라 연결을 트리거하는 기능입니다. 경로는 Settings → On Demand입니다. 활성화하기 전에 수동 연결이 안정적으로 작동하는지 확인한 뒤 Wi-Fi 또는 셀룰러 네트워크 조건을 추가해야 합니다. 그렇지 않으면 자동 트리거가 기존 설정 오류를 반복해서 드러낼 뿐입니다.
설정 후에는 세 가지 상태를 각각 테스트합니다. 지정한 Wi-Fi에 연결한 상태, 해당 Wi-Fi를 벗어나 셀룰러 네트워크로 전환한 상태, 화면을 잠근 뒤 다시 깨운 상태입니다. 조건에 따라 Home 스위치와 시스템 연결 상태가 바뀌는지 확인합니다. 규칙이 예상과 반대로 작동하면 조건이 “일치할 때 연결”인지 “일치할 때 연결 해제”인지 확인합니다.
먼저 수동으로 확인
Home에서 서버를 선택하고 Config 또는 필요한 Global Routing 방식으로 설정한 뒤 웹페이지 접속과 Log가 모두 정상인지 확인합니다.
설정 열기
Settings → On Demand로 차례로 이동해 기존 조건이 있는지 확인합니다. 여러 조건이 서로 반대 결과를 내지 않도록 주의합니다.
조건 추가
필요에 따라 Wi-Fi 또는 셀룰러 네트워크 조건을 설정하고, 일치할 때 연결할지 연결 해제할지 명확히 지정합니다.
네트워크 전환
지정한 Wi-Fi와 셀룰러 네트워크 사이를 전환하고 시스템 네트워크 전환이 완료될 때까지 기다린 뒤 연결 상태를 확인합니다.
깨우기 확인
화면을 잠근 뒤 기기를 다시 깨워 On Demand가 기존 조건 때문에 연결과 연결 해제를 반복하지 않는지 확인합니다.
질문 10: 설정이 많을 때 오류가 발생한 계층을 빠르게 찾으려면 어떻게 하나요?
“최소 작동 설정”으로 점검합니다. 먼저 매개변수가 명확한 서버 하나만 남기고 Global Routing은 Proxy로 임시 설정하며, On Demand를 끕니다. Scene과 복잡한 규칙이 동시에 결과에 영향을 주지 않도록 합니다. 기본 연결을 확인한 뒤 Config, DNS 조정과 자동 트리거 조건을 하나씩 다시 활성화합니다.
Log는 시간 순서대로 읽어야 합니다. 조회 오류는 대상 연결을 설정하기 전에 발생합니다. timeout은 네트워크 접근성, 주소와 포트를 함께 확인해야 하는 경우가 많습니다. TLS handshake 오류는 TLS, SNI와 인증 정보를 점검해야 하며, 규칙 매칭 오류는 Config로 돌아가 DOMAIN-SUFFIX, GEOIP, IP-CIDR 및 FINAL의 순서를 확인해야 합니다.
프로토콜을 먼저 바꿔야 하나요, 아니면 Log를 먼저 봐야 하나요?
먼저 Log를 확인합니다. 프로토콜은 기존 서비스 설정에 따라 정해지므로 문제 해결을 위해 임의로 바꾸면 안 됩니다. timeout, DNS failure 또는 TLS handshake 등의 현상에 따라 관련 필드를 찾는 편이 효과적입니다.
Config를 로드한 뒤 모두 Direct로 연결되나요?
Global Routing이 실제로 Config로 선택되어 있는지 확인한 다음, 규칙 앞부분에 적용 범위가 지나치게 넓은 Direct 규칙이 있는지와 FINAL이 가리키는 정책을 확인합니다.
Wi-Fi에서는 작동하지만 셀룰러 네트워크에서는 시간 초과되나요?
같은 서버와 같은 Global Routing 방식으로 비교하고, On Demand가 셀룰러 네트워크에 다른 동작을 설정했는지 확인합니다.
구독 업데이트 후 기존 설정이 작동하지 않나요?
업데이트된 유효 항목을 다시 선택하고, 정책 그룹에서 참조하는 이름이 여전히 존재하는지와 서비스 제공업체가 반환한 프로토콜 필드가 완전한지 확인합니다.
위 10가지 점검을 마친 뒤에는 Home에서 유효한 항목을 선택하고, Global Routing은 검증된 Config를 사용하며, 구독은 필요할 때 업데이트하고, On Demand는 수동 연결이 안정된 후에만 활성화하는 상태로 유지할 수 있습니다. 문제가 발생하면 현재 네트워크, 선택 항목, 라우팅 방식과 Log 키워드를 먼저 기록한 뒤 한 번에 하나씩 조정합니다.