Shadowrocket 문제 해결 총정리

점검 기준 세우기: 스위치가 켜지지 않거나 바로 꺼지는 경우

먼저 “스위치 실패”와 “서버 연결 실패”를 구분하세요

Shadowrocket의 Home 스위치는 시스템에 VPN 구성을 생성하도록 요청합니다. 스위치가 켜진 상태를 유지하지 못한다면 대개 트래픽이 서버에 도달하기 전 단계에서 문제가 발생한 것입니다. 반면 서버 시간 초과는 시스템 통로는 이미 만들어졌지만 서버 연결 과정이 완료되지 않았다는 뜻입니다. 두 경우의 점검 경로는 다릅니다. 확인할 때 웹페이지가 열리는지만 보지 말고 Home 스위치 상태, 시스템 상태 표시줄의 VPN 표시, 현재 선택한 서버, Global Routing 상태를 함께 기록하세요. 스위치를 누른 직후 바로 원래 상태로 돌아가면 먼저 시스템 권한과 구성 충돌을 확인하고, 스위치가 켜진 상태인데 웹페이지가 실패하면 다음 장에서 서버, DNS 및 규칙을 점검하세요.

처음 실행하거나 시스템에서 권한을 다시 확인할 때 기기에 VPN 구성 추가 권한 창이 나타날 수 있습니다. 기기 인증을 완료해야 Shadowrocket이 해당 구성을 생성할 수 있습니다. 이전에 권한을 거부했다면 시스템 Settings에서 VPN 구성이 있는지 확인한 뒤 Shadowrocket으로 돌아와 다시 시도하세요. 이때 앱을 반복해서 삭제할 필요는 없습니다. 먼저 권한 흐름을 확인하면 시스템 권한 문제를 서버 문제로 잘못 판단하는 일을 줄일 수 있습니다. 기기에 조직 관리, 콘텐츠 제한 또는 자녀 보호가 적용되어 있으면 VPN 구성 변경이 제한될 수도 있습니다. 이 경우 시스템에 표시되는 안내를 확인하고 기기 관리자에게 정책을 문의하세요.

동시에 발생하는 연결 충돌 정리

Apple 플랫폼에서는 같은 시점에 시스템 조건을 충족하는 네트워크 확장 하나만 해당 트래픽을 처리할 수 있습니다. 시스템 Settings에 다른 VPN 구성이 연결 중이거나 반복적으로 자동 실행되고 있으면 Shadowrocket 스위치가 “연결 중”에 머물다가 다시 꺼질 수 있습니다. 점검할 때는 먼저 다른 VPN 구성을 끄고 Shadowrocket의 On Demand도 잠시 끈 다음 Home 스위치를 수동으로 한 번 조작하세요. On Demand의 조건이 현재 Wi-Fi, 셀룰러 네트워크 또는 도메인 조건과 맞지 않으면 사용자가 연결을 끈 직후 시스템이 다시 연결을 시작하거나, 수동으로 켠 뒤 조건을 재평가하는 현상이 나타날 수 있습니다.

On Demand를 끄는 것은 기준 상태를 만들기 위한 조치일 뿐, 기능 자체에 문제가 있다는 뜻은 아닙니다. 수동 연결이 복구되면 트리거 조건을 하나씩 확인하세요. 현재 네트워크 이름이 올바른 분기에 포함되어 있는지, 셀룰러 네트워크 조건이 예상과 일치하는지, 조건이 “모두 충족”인지 “하나라도 충족”인지, 규칙이 삭제된 구성을 참조하고 있지는 않은지 확인합니다. 항목을 하나 바꿀 때마다 네트워크를 전환하거나 시스템이 다시 평가할 때까지 기다리세요. 여러 조건을 동시에 수정하면 어느 항목 때문에 연결이 복구되었는지 알 수 없습니다.

최소 변수 방식으로 연결 복구

기준 테스트에서는 정보가 완전한 서버 하나만 남기고 On Demand를 끄며, 프로토콜 매개변수는 잠시 변경하지 말고 안정적인 Wi-Fi에서 먼저 연결하세요. 실패하면 셀룰러 네트워크로 전환해 비교합니다. 같은 구성이 두 로컬 네트워크에서 서로 다른 결과를 보이면 라우터, 네트워크 접속 또는 DNS 환경의 문제일 가능성이 높습니다. 두 네트워크 모두 실패할 때 서버 주소, 포트, 인증 정보 및 프로토콜 매개변수를 확인하세요. 한 번의 테스트에서 서버, DNS, Global Routing 및 규칙 파일을 동시에 바꾸지 마세요. 변수가 여러 개 바뀌면 실제 원인을 파악하기 어렵습니다.

App Store의 구매 기록, 앱 ID 또는 개발자 정보를 다시 확인해야 한다면 정품 확인 세 가지 항목을 참고하세요. Shadowrocket은 일회성 구매 클라이언트이지만, 클라이언트 일회성 구매 ≠ 회선 요금제입니다. 연결에 필요한 구독 또는 서버 정보는 사용자가 이미 이용 중인 서비스 출처에서 제공해야 하며, 앱 구매 상태가 특정 서버의 사용 가능 여부를 결정하지는 않습니다.

스위치는 켜졌지만 웹페이지와 앱에서 인터넷에 접속할 수 없음

세 가지 Global Routing 상태로 범위를 좁히기

Global Routing의 Config, Proxy, Direct는 “연결은 성공했지만 네트워크가 되지 않는” 문제를 구분하는 핵심 기준입니다. Config는 Config의 규칙 순서에 따라 각 요청의 경로를 결정하고, Proxy는 트래픽을 현재 서버로 통일하며, Direct는 트래픽을 직접 전송합니다. 테스트할 때는 먼저 원래 상태를 기록한 뒤 잠시 Direct로 전환하세요. Direct에서도 접속할 수 없다면 시스템 통로, 로컬 네트워크 또는 DNS의 문제일 수 있으며 프록시 서버의 문제는 아닐 가능성이 있습니다. Direct는 정상이고 Proxy가 실패하면 서버 접근성과 매개변수를 확인하세요. Proxy는 정상이고 Config가 실패하면 규칙 순서, 정책 이름 및 FINAL 결과를 중점적으로 확인합니다.

상태 전환은 진단용으로만 사용해야 하며 Proxy를 장기간 사용해 규칙 문제를 가리는 방법으로 삼아서는 안 됩니다. Config에 이상이 있으면 규칙 자체를 수정하세요. 규칙은 위에서 아래로 매칭되고 첫 번째로 일치한 뒤에는 추가 판단을 중단합니다. 따라서 범위가 좁은 DOMAIN, DOMAIN-SUFFIX, IP-CIDR은 일반적으로 범위가 넓은 규칙보다 앞에 배치하고 FINAL은 마지막에 둡니다. 너무 앞에 있는 REJECT, DIRECT 또는 범위가 넓은 DOMAIN-SUFFIX 하나만으로도 뒤의 규칙이 영원히 매칭되지 않을 수 있습니다.

읽기 쉬운 최소 규칙 집합 만들기

다음 조각은 규칙 순서를 설명하기 위한 예시이며 실제 서비스 정보를 나타내지 않습니다. 정책 이름은 Config에 존재하는 정책 또는 앱이 지원하는 결과 이름과 일치해야 합니다. 테스트할 때는 사용자가 보유한 구성의 올바른 정책 이름으로 PROXY를 바꾸고 FINAL이 마지막에 오도록 하세요. 로컬 네트워크 주소에는 DIRECT를 사용하면 라우터나 로컬 기기에 접근할 때 원격 서버를 우회할 수 있습니다. 명확한 도메인 규칙은 GEOIP와 FINAL보다 앞에 두면 Data 또는 요청 기록에서 매칭 결과를 확인하기 쉽습니다.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

Config 파일을 가져온 뒤 정책을 찾을 수 없거나 규칙이 유효하지 않거나 전체 트래픽이 실패하면 쉼표로 구분된 필드가 완전한지, 정책 이름의 대소문자가 일치하는지, 보이지 않는 문자가 섞이지 않았는지, 참조한 정책 그룹이 실제로 존재하는지 확인하세요. 파일을 가져올 수 있다는 이유만으로 구성이 유효하다고 판단하지 마세요. 가져오기는 텍스트가 받아들여졌다는 뜻일 뿐, 모든 서버·정책 그룹·규칙이 실행 가능하다는 뜻은 아닙니다. 먼저 규칙을 소량만 남겨 확인한 뒤 복잡한 규칙을 구간별로 복원하세요.

시스템 시간, 네트워크 로그인 페이지 및 IPv6 차이 확인

기기의 날짜와 시간이 크게 틀리면 TLS 인증서 검증이 실패해 대부분의 HTTPS 페이지가 열리지 않고 일부 로컬 페이지만 접속되는 현상이 나타날 수 있습니다. 시스템 Settings에서 날짜와 시간 자동 설정을 켠 뒤 다시 연결하세요. 호텔, 학교 또는 공용 Wi-Fi는 먼저 네트워크 로그인 페이지 인증을 요구하는 경우가 많습니다. Shadowrocket을 연결하기 전에 스위치를 잠시 끄고 브라우저에서 일반 페이지를 열어 로그인 페이지를 표시한 뒤 인증을 완료하세요. Wi-Fi는 정상인데 셀룰러 네트워크가 실패하거나 그 반대라면 두 네트워크의 DNS와 IPv6 접근성을 각각 확인하세요. 한 네트워크의 제한을 모든 서버를 사용할 수 없는 문제로 단정하지 마세요.

일부 앱은 이전 연결을 캐시할 수 있습니다. Config, DNS 또는 서버를 수정한 뒤 Shadowrocket에서 연결을 끊었다가 다시 연결하고, 문제가 발생한 앱을 완전히 종료한 다음 다시 여세요. 그래도 실패하면 비행기 모드를 한 번 전환해 시스템 네트워크 인터페이스를 재구성할 수 있습니다. 기기 재시동은 권한, 상태, 규칙, DNS 및 네트워크 비교를 마친 뒤에 수행하세요. 재시동은 임시 상태를 정리할 수 있지만 잘못된 서버 매개변수나 규칙 순서를 고치지는 못합니다.

문제가 “스위치가 켜진” 상태에서만 발생한다면 서버 상태, Global Routing, DNS 및 규칙별 점검을 이어서 읽어 보세요. 현장에서 빠르게 확인할 수 있는 체크리스트를 제공합니다.

서버 시간 초과, 핸드셰이크 실패 및 Connectivity Test 이상

“시간 초과”를 주소, 포트 및 프로토콜 단계로 나누기

시간 초과에는 하나의 원인만 있는 것이 아닙니다. 먼저 서버 주소를 IP로 확인하고, 다음으로 포트까지 전송 연결을 수립한 뒤, Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard 또는 Hysteria2 등의 프로토콜로 인증과 핸드셰이크를 완료합니다. 앞 단계가 실패하면 뒤 단계는 진행되지 않습니다. Connectivity Test 결과는 같은 시각, 같은 로컬 네트워크에서 여러 기존 서버를 비교하는 데 유용하지만 한 번의 실패만으로 서버를 영구적으로 사용할 수 없다고 판단할 수는 없습니다. 로컬 네트워크 변동, 일시적인 DNS 실패, 서버 점검 또는 매개변수 불일치도 비슷한 결과를 만들 수 있습니다.

Add Server 또는 기존 항목에서 SERVER, 포트, 비밀번호 또는 식별자, 프로토콜 유형 및 전송 관련 필드를 먼저 확인하세요. 정보를 복사할 때 흔히 생기는 오류는 주소 앞뒤의 공백, 빠진 포트, 바뀐 대소문자, 메모를 서버 주소로 착각하는 경우, 만료된 QR 코드 또는 클립보드 내용입니다. 매개변수는 사용자가 이용 중인 서비스 출처에서 제공한 정보와 항목별로 일치해야 하며, 경험만으로 암호화 방식, 전송 유형 또는 TLS 값을 바꾸면 안 됩니다. 프로토콜 이름이 같아도 매개변수를 서로 바꿔 쓸 수 있다는 뜻은 아닙니다.

네트워크 비교로 로컬 차단과 원격 이상 구분

Wi-Fi에서 시간 초과가 발생하면 Shadowrocket 연결을 끊은 뒤 일반 웹페이지가 열리는지 확인하고, 셀룰러 네트워크로 전환해 같은 서버를 테스트하세요. 이후 정상적으로 확인된 다른 Wi-Fi에서도 재검사할 수 있습니다. 같은 서버가 특정 접속 네트워크에서만 실패한다면 라우터 DNS, IPv6, 게스트 네트워크 격리, 조직 네트워크 정책 또는 로그인이 필요한 네트워크 포털을 우선 확인하세요. 여러 네트워크에서 모두 시간 초과가 발생하지만 같은 구독의 다른 서버는 정상이라면 해당 서버의 주소, 포트 또는 원격 상태 문제일 가능성이 높습니다. 모든 서버가 모든 네트워크에서 동시에 실패하면 구독 내용, 시스템 시간, DNS 및 구성이 전체적으로 바뀌었는지 다시 확인하세요.

테스트 순서는 고정해야 합니다. 먼저 현재 서버를 테스트하고, 같은 구성의 다른 서버를 테스트한 다음, 로컬 네트워크를 바꾸고, 마지막에 프로토콜 매개변수를 수정하세요. 이렇게 해야 두 가지 비교 축을 만들 수 있습니다. 서버만 바꾼 뒤 복구되면 시스템 통로와 앱 권한은 대체로 정상이라는 뜻입니다. 로컬 네트워크만 바꾼 뒤 복구되면 서버가 적어도 다른 네트워크에서는 접근 가능하다는 뜻입니다. 모든 조합에서 실패하면 잘못된 DNS, 만료된 구성, 시스템 VPN 상태 또는 서비스 출처의 전체 변경과 같은 공통 요인을 확인해야 합니다.

지연 테스트와 실제 사용 가능성의 차이 이해

지연 수치는 특정 테스트 요청이 당시 네트워크 조건에서 왕복한 결과일 뿐, 웹페이지 로딩·영상 전송·대용량 파일 처리량과 같지 않습니다. 서버가 테스트 결과를 반환한다고 해서 현재 규칙에 따라 모든 대상 도메인에 접속할 수 있는 것은 아닙니다. 반대로 원격에서 테스트 요청을 제한해도 실제 서비스 연결은 응답할 수 있습니다. 따라서 Connectivity Test를 실제 요청 기록과 함께 확인하세요. 요청이 전송되었는지, 어떤 정책에 매칭되었는지, 시간 초과·연결 거부·이름 확인 실패 중 어떤 결과였는지 살펴봅니다. 오류 메시지마다 해당 계층이 다르므로 모든 문제를 “서버 변경”으로 처리해서는 안 됩니다.

WireGuard 및 Hysteria2 등의 프로토콜은 더 구체적인 키, 주소, MTU 또는 전송 매개변수에 의존할 수 있습니다. 연결은 되지만 일부 페이지가 멈춘다면 모든 값을 먼저 임의로 높이거나 낮추지 마세요. 서비스 출처에서 제공한 전체 필드를 확인한 뒤 기본값 또는 명시된 값을 사용해 테스트하세요. MTU가 맞지 않으면 작은 요청은 정상인데 큰 응답이 멈출 수 있지만, 같은 증상은 DNS, 경로 품질 또는 서버 제한에서도 나타날 수 있습니다. 로컬 네트워크를 바꾸고 다른 서버와 비교해 교차 확인하세요.

서버 정보가 서비스 출처에 의해 변경된 것으로 확인되면 최신 정보에 따라 기존 항목 또는 구독을 업데이트하세요. 이 안내서는 클라이언트에서 가져오기, 테스트 및 점검하는 방법만 설명하며 서버나 구독 내용을 제공하지 않습니다.

Subscribe 가져오기 또는 업데이트 실패

주소에 접근할 수 없는 경우, 내용이 유효하지 않은 경우, 업데이트가 적용되지 않은 경우 구분

구독 실패는 최소 세 가지로 나뉩니다. 첫째는 Subscribe 주소에 접근할 수 없는 경우로, 시간 초과·DNS 실패·비정상 HTTP 상태가 흔한 증상입니다. 둘째는 주소가 내용을 반환하지만 Shadowrocket이 인식할 수 있는 형식이 아닌 경우입니다. 셋째는 화면에 업데이트 완료가 표시되지만 서버 목록이 예상대로 바뀌지 않는 경우입니다. 점검할 때는 어디에서 실패했는지 먼저 확인하고 반복해서 삭제하거나 다시 추가하지 마세요. 사용자는 기존 서비스 출처에서 제공한 완전한 구독 주소를 사용해야 하며, 링크의 쿼리 매개변수도 주소의 일부인 경우가 많으므로 복사할 때 잘리지 않도록 주의하세요.

Subscribe 항목에서 주소 앞뒤에 공백이 추가되지 않았는지, 프로토콜 헤더가 완전한지, 채팅 앱에서 문자가 줄바꿈되지 않았는지, 서비스 출처가 링크를 교체하지 않았는지 먼저 확인하세요. 예시 주소는 구조를 이해하기 위한 것이며 실제 서버를 생성하지 않습니다:

https://example.com/sub?token=xxxx

같은 주소가 이전에는 업데이트되다가 갑자기 실패하면 먼저 로컬 네트워크를 바꿔 테스트하고 시스템 날짜와 DNS를 확인하세요. 공용 Wi-Fi의 로그인 페이지, 라우터 필터 또는 일시적인 이름 확인 이상이 구독 요청에 영향을 줄 수 있습니다. 여러 네트워크에서 주소가 모두 명확한 오류를 반환한다면 원래 서비스 출처에 주소 상태를 확인하세요. 출처가 불분명한 페이지로 구독 내용을 변환하지 말고, 접근 자격 증명이 포함된 링크를 낯선 도구에 제출하지 마세요.

업데이트 정책과 로컬 항목의 관계 확인

구독 업데이트는 해당 구독이 관리하는 서버를 추가·수정 또는 삭제할 수 있습니다. 사용자가 직접 만든 Add Server 항목과 Subscribe가 관리하는 항목은 점검할 때 나누어 관찰해야 하며, 로컬 수동 항목을 구독 업데이트 결과로 착각하지 않도록 하세요. 업데이트 전에 구독 그룹의 서버 수를 기록하는 것은 장기적인 확인 방법으로 신뢰하기 어렵습니다. 서비스 출처가 내용을 조정할 수 있기 때문입니다. 대신 명확한 서버 이름이나 업데이트 시간 표시를 기록하고, 업데이트 후 해당 Subscribe 항목의 상태와 현재 선택한 서버가 여전히 존재하는지 확인하세요.

업데이트 후 Home에 이미 삭제되었거나 매개변수가 바뀐 기존 항목이 계속 선택되어 있다면 구독에 있는 유효한 서버를 다시 선택한 뒤 Connectivity Test를 실행하세요. Config의 정책 그룹이 서버 이름으로 항목을 참조한다면 이름 변경으로 정책이 비어 있을 수도 있습니다. 이때 서버 목록뿐 아니라 Config의 정책 그룹 구성원과 규칙 결과도 확인해야 합니다. 구독 업데이트 성공은 데이터가 기록되었다는 뜻일 뿐, 기존 Config가 새 데이터를 계속 올바르게 참조한다는 뜻은 아닙니다.

형식 오류와 일부 데이터 문제 처리

반환 내용 중 일부 항목의 필드만 잘못된 경우 앱이 일부 내용을 건너뛰거나 전체 가져오기 결과가 예상과 달라질 수 있습니다. 빠진 필드를 임의로 추측해 입력하지 마세요. 기존 Subscribe 항목과 현재 사용할 수 있는 구성을 보존하고, 원래 서비스 출처에 제공 형식이 Shadowrocket에 적합한지 확인하세요. 서비스 출처에서 QR 코드를 함께 제공한다면 Scan QR Code로 가져올 수 있지만, QR 코드는 전달 방식이 다를 뿐입니다. 스캔 결과에서도 서버 주소, 프로토콜 및 메모를 확인해야 하며, “스캔 가능”하다는 이유만으로 매개변수가 올바르다고 판단해서는 안 됩니다.

Import from Cloud JSON은 사용자가 직접 저장한 해당 데이터를 가져오는 데 적합하지만 클라우드 파일이 현재 구성보다 오래되었을 수 있습니다. 가져오기 전에 백업 복원과 구독 업데이트를 구분하세요. 백업은 특정 시점의 로컬 구조를 기기로 되돌리고, 구독 업데이트는 원래 주소에서 최신 내용을 가져옵니다. 오래된 백업으로 현재 데이터를 덮어쓴 뒤에는 Subscribe 주소, 서버 선택, Config 및 On Demand 조건을 다시 확인하세요. 서버 목록이 나타나는지만 확인해서는 안 됩니다.

구독은 Shadowrocket 구매 항목이 아닙니다. 클라이언트 일회성 구매 ≠ 회선 요금제입니다. App Store 구매는 클라이언트를 이용하기 위한 것이고, Subscribe의 데이터는 사용자가 이미 이용 중인 서비스 출처가 관리합니다. 새 기기로 옮길 때는 구성 백업 및 기기 변경 복원 절차를 함께 참고하고, 먼저 앱 구매를 복원한 뒤 로컬 구성과 구독 상태를 확인하세요.

속도 저하, 로딩 멈춤 및 앱별 동작 차이

로컬 네트워크, 서버, 경로 및 프로토콜을 계층별로 측정

속도 저하는 먼저 구체적인 증상으로 정의해야 합니다. 페이지를 처음 열 때 오래 기다리는지, 지속 전송 속도가 낮은지, 이미지나 영상만 끊기는지, 특정 앱만 이상한지 구분하세요. 증상에 따라 DNS, 연결 수립, 처리량, 패킷 손실 및 규칙 매칭 등 관련 계층이 다릅니다. 점검 전에 대량 동기화나 다운로드를 중지하고 테스트 대상과 시간을 고정하세요. 먼저 Shadowrocket을 끈 상태에서 로컬 네트워크를 측정한 뒤 켜고 현재 서버를 테스트합니다. 서로 다른 시간과 사이트에 대한 주관적인 느낌만 비교해서는 신뢰할 만한 결론을 얻을 수 없습니다.

첫 번째 계층은 로컬 Wi-Fi 또는 셀룰러 네트워크입니다. Shadowrocket을 끈 상태에서도 로컬 네트워크에 패킷 손실, 잦은 네트워크 전환 또는 약한 신호가 있다면 이후 연결에서 변동이 더 크게 나타납니다. 라우터 가까이 이동하거나 품질이 낮은 Wi-Fi를 끄고 셀룰러 네트워크로 바꾸거나, 다른 안정적인 네트워크에서 재검사하면 기본 접속이 주요 원인인지 확인할 수 있습니다. 두 번째 계층은 현재 서버와 경로입니다. 사용자가 가진 구성의 여러 서버를 Connectivity Test로 비교하고 같은 대상 페이지를 실제로 열어 보세요. 한 번의 지연 결과만으로 서버를 선택하지 마세요. 낮은 지연이 지속적인 처리량 안정성을 의미하지는 않습니다.

세 번째 계층은 프로토콜과 매개변수입니다. 프로토콜마다 네트워크 조건에 따른 성능이 다를 수 있지만 매개변수는 기존 서버 정보에서 가져와야 하며 인증, 전송 또는 TLS 설정을 속도만 보고 임의로 바꾸면 안 됩니다. 서비스 출처에서 여러 항목을 제공한다면 같은 네트워크, 같은 시간, 같은 대상에서 비교하세요. 네 번째 계층은 규칙입니다. 같은 앱의 도메인이 서로 다른 정책으로 배정될 수 있습니다. 본문은 PROXY를 사용하지만 이미지 도메인은 DIRECT 또는 REJECT를 사용하면 텍스트는 먼저 표시되고 리소스는 오래 빈 화면으로 남을 수 있습니다.

요청 기록으로 규칙 분리 확인

Data 또는 해당 요청 기록에서 문제가 발생한 시점의 도메인, 매칭 규칙 및 최종 정책을 확인하세요. 기본 도메인, 정적 리소스 도메인, 로그인 도메인 및 콘텐츠 전송 도메인이 같은 경로로 처리되는지 중점적으로 살펴봅니다. 일부 도메인이 지나치게 넓은 DOMAIN-KEYWORD에 매칭되면 더 정확한 DOMAIN 또는 DOMAIN-SUFFIX로 바꾸세요. GEOIP가 먼저 매칭되어 예상과 다른 결과가 나오면 명확한 도메인 규칙을 GEOIP보다 앞에 배치할 수 있습니다. 규칙을 수정한 뒤 연결을 끊었다가 다시 연결하고 대상 앱도 다시 열어 이전 경로를 재사용하지 않도록 하세요.

속도 문제를 모든 트래픽을 장기간 Proxy로 보내는 방식으로 가려서는 안 됩니다. Proxy는 “규칙이 문제에 관여하는지” 확인할 때 사용할 수 있습니다. Proxy는 정상이고 Config가 느리다면 Config로 돌아가 규칙을 수정하세요. 둘 다 느리고 Direct가 정상이라면 서버와 경로를 확인하세요. 세 상태 모두 느리다면 먼저 로컬 네트워크, DNS 및 기기 상태를 확인합니다. 이 세 상태 비교는 두 번째 장과 같지만, 이 장에서는 완전히 접속할 수 없는 문제가 아니라 연결된 상태에서의 성능 차이를 다룹니다.

대용량 응답 멈춤과 MTU 단서 처리

작은 웹페이지는 정상인데 큰 이미지나 지속 전송이 자주 멈춘다면 MTU 또는 경로 분할 문제를 후보로 둘 수 있지만 바로 원인으로 단정해서는 안 됩니다. 먼저 서로 다른 로컬 네트워크와 서버를 비교하세요. 특정 네트워크 조합에서만 발생하면 경로 특성이 관련되었을 가능성이 높고, 모든 조합에서 발생하면 프로토콜 매개변수, 기기의 절전 상태 및 대상 서비스도 확인해야 합니다. MTU 설정을 명확히 제공하는 구성이라면 사용자가 보유한 서비스 정보 또는 프로토콜 요구 사항을 기준으로 하고, 한 번에 하나의 값만 조정해 같은 테스트의 전후 결과를 기록하세요. 무작정 반복해서 바꾸면 불안정성이 커질 수 있습니다.

테스트는 최소 두 시점에 걸쳐 진행해 일시적인 혼잡을 안정적인 결론으로 착각하지 않도록 하세요. 로컬 네트워크 유형, 서버 이름, Global Routing, 대상 앱 및 증상이 발생한 단계를 기록한 뒤 결과를 비교합니다. 같은 서버가 시간대에 따라 크게 다르게 동작하면 원격 부하나 경로 변화와 관련될 수 있습니다. 모든 서버가 특정 Wi-Fi에서만 느리다면 라우터와 접속 네트워크를 우선 점검하세요. 더 자세한 네 계층 점검은 서버, 경로, 프로토콜 및 로컬 네트워크 단계별 점검을 참고하세요.

DNS 이름 확인 실패, 비정상 결과 및 일부 도메인 접속 불가

막연한 인터넷 끊김이 아닌 DNS 장애인지 확인

DNS는 도메인 이름을 연결 가능한 주소로 변환합니다. 대표적인 DNS 장애는 도메인을 입력하면 열리지 않지만 알고 있는 IP에 직접 접속하면 응답하는 경우, 일부 도메인에서 계속 서버를 찾을 수 없다고 표시되는 경우, Wi-Fi를 바꾸면 같은 도메인이 복구되는 경우, 첫 요청은 매우 느리지만 캐시 기간에는 정상인 경우입니다. TLS, 규칙 REJECT, 서버 시간 초과도 비슷한 증상을 만들 수 있으므로 요청 기록의 오류 유형과 함께 판단해야 합니다. 기록에 도메인 이름 확인 실패가 표시되면 먼저 DNS를 처리하세요. 대상 IP를 이미 받았는데 연결이 시간 초과되면 서버 또는 경로 계층으로 이동해 점검합니다.

Shadowrocket에서 DNS의 실제 동작은 Config, 시스템 네트워크, IPv4, IPv6 및 규칙 설정의 영향을 받습니다. 점검할 때는 현재 DNS 구성을 먼저 기록하고 모든 필드를 바로 비우지 마세요. 현재 구성에 적합하다고 확인된 DNS 방식을 잠시 사용해 테스트하고 Wi-Fi와 셀룰러 네트워크에서 각각 관찰합니다. 특정 Wi-Fi에서만 실패한다면 라우터가 전달하는 DNS, 네트워크 로그인 페이지 또는 로컬 네트워크 가로채기가 관련되었을 수 있습니다. 모든 네트워크에서 실패한다면 Config가 접근할 수 없는 주소, 형식이 잘못된 구성 또는 현재 규칙과 맞지 않는 확인 경로를 참조하는지 확인하세요.

no-resolve와 IP 규칙의 관계 이해

IP-CIDR, IP-CIDR6 및 GEOIP는 대상 IP를 기준으로 판단합니다. 일부 규칙에 no-resolve가 있으면 해당 규칙을 실행하기 위해 도메인 이름 확인을 추가로 요청하지 않는다는 뜻입니다. 불필요한 조회를 줄일 수 있지만 이미 IP 정보가 있을 때만 규칙이 매칭될 수 있습니다. 모든 IP 규칙이 도메인을 능동적으로 확인한다고 생각하면 규칙이 매칭되지 않은 이유를 잘못 판단할 수 있습니다. DOMAIN, DOMAIN-SUFFIX 및 DOMAIN-KEYWORD는 도메인을 직접 기준으로 매칭하므로 정확한 분류가 필요한 IP 계열 규칙보다 보통 앞에 배치합니다.

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

위의 로컬 네트워크 규칙은 매칭 방식을 설명하기 위한 것입니다. 기기가 라우터, 저장 장치 또는 프린터 서비스에 접근해야 한다면 DIRECT를 사용해 트래픽이 원격 서버로 전달되는 것을 막을 수 있지만 실제 접근 여부는 Wi-Fi 격리와 로컬 네트워크 권한의 영향을 받습니다. 로컬 네트워크 IP에 접근할 수 없다고 해서 반드시 DNS 문제인 것은 아닙니다. IP를 직접 사용하면 도메인 이름 확인이 진행되지 않기 때문입니다. 먼저 접근 대상이 도메인인지 IP인지 구분한 다음 실패한 계층을 확인하세요.

캐시, IPv6 및 암호화 DNS의 상호 영향 처리

DNS를 수정한 뒤에도 이전 결과가 앱, 시스템 또는 연결 캐시에 남아 있을 수 있습니다. Shadowrocket 연결을 끊고 다시 연결한 뒤 대상 앱을 완전히 종료했다가 여세요. 필요하면 비행기 모드를 한 번 전환하세요. 여러 DNS를 연속으로 바꾼 직후 결론을 내리지 마세요. 캐시 때문에 변경 전후 결과가 섞일 수 있습니다. 특정 도메인이 IPv4와 IPv6를 모두 제공하고 현재 네트워크의 IPv6 경로가 불안정하면 이름 확인은 성공하지만 연결이 느리거나 시간 초과될 수 있습니다. 이때 서로 다른 접속 네트워크를 비교하고 실패한 요청이 어떤 주소 유형을 사용했는지 확인하세요. DNS가 결과를 반환하지 않았다고 단순히 판단해서는 안 됩니다.

암호화 DNS를 구성할 때는 서버 도메인을 처음 어떻게 확인하는지, 해당 DNS 엔드포인트로 가는 경로가 현재 규칙의 영향을 받는지도 고려해야 합니다. DNS 엔드포인트 자체가 아직 만들어지지 않은 경로를 통해서만 접근 가능하면 시작 의존성이 생길 수 있습니다. 점검할 때는 구성에서 명확히 지원하는 기본 방식으로 잠시 돌아가 일반 이름 확인이 정상인지 확인한 뒤 암호화 DNS 설정을 단계적으로 다시 추가하세요. 변경할 때마다 이전에 안정적으로 실패하던 도메인 하나와 정상인 도메인 하나를 테스트해야 전체 DNS 장애인지 특정 도메인 결과 이상인지 판단할 수 있습니다.

비정상적인 배터리 소모, 백그라운드 활동 및 업데이트 후 이상

배터리 소모가 지속적인 트래픽 때문인지 연결 재시도 때문인지 확인

Shadowrocket이 연결된 상태에서는 시스템 네트워크 확장을 통과하는 트래픽을 처리해야 하므로 배터리 소모가 기기 신호, 전송량, 프로토콜, 규칙 복잡도, 로그 기록 및 연결 안정성의 영향을 함께 받습니다. 먼저 시스템 Settings의 배터리 사용량 페이지에서 관찰 시간 동안 Shadowrocket의 전경 및 백그라운드 활동을 비교하고, 사진 동기화·클라우드 백업·미디어 재생 또는 다른 앱의 지속적인 전송이 있는지도 확인하세요. 다른 앱이 네트워크 트래픽을 발생시키면 Shadowrocket이 해당 연결을 처리하면서 백그라운드 활동을 보일 수 있으므로 비율만 보고 클라이언트 자체의 이상이라고 판단해서는 안 됩니다.

기기가 뜨거워지고 서버 시간 초과가 반복되거나 Home 상태가 자주 바뀌거나 On Demand가 계속 실행되면 연결 재시도를 중점적으로 확인하세요. 먼저 On Demand를 끄고 이미 사용 가능하다고 확인된 서버 하나를 선택해 안정적인 Wi-Fi에서 수동으로 연결한 뒤 관찰합니다. 정상으로 돌아오면 Wi-Fi와 셀룰러 네트워크 전환 시 On Demand 조건이 서로 충돌하는지 확인하세요. 신호가 약하면 셀룰러 네트워크가 연결을 유지하기 위해 더 많은 전력을 사용할 수 있습니다. 같은 구성이 안정적인 Wi-Fi에서는 정상이고 신호가 약한 환경에서만 발열이 심하다면 접속 네트워크도 중요한 변수입니다.

로그, 규칙 및 백그라운드 작업의 영향 줄이기

점검 중에는 불필요한 장시간 상세 기록을 줄이고 Data에서 특정 앱이 대량의 요청을 계속 생성하는지 확인할 수 있습니다. 재시도 오류가 발생한 도메인은 짧은 간격으로 반복될 수 있어 트래픽을 늘리고 네트워크를 계속 깨울 수 있습니다. 먼저 요청을 생성한 앱, 매칭된 규칙 및 반환된 오류를 확인한 뒤 규칙이나 대상 앱의 백그라운드 동작을 처리하세요. 비슷한 도메인을 모두 넓은 REJECT로 차단하지 마세요. 지나치게 넓은 DOMAIN-KEYWORD는 정상 기능에 영향을 주고 새로운 재시도를 만들 수 있습니다.

복잡한 규칙 파일 자체가 유일한 배터리 소모 원인인 경우는 드물지만, 중복되거나 서로 덮어쓰거나 순서가 불합리한 규칙은 진단을 어렵게 만들 수 있습니다. 현재 Config를 복사해 간소화된 버전을 만들고 필요한 로컬 네트워크 규칙, 명확한 도메인 규칙, GEOIP 및 FINAL만 남긴 뒤 같은 시간대의 연결 안정성을 관찰하세요. 간소화 후 문제가 사라지면 원래 규칙을 구간별로 다시 추가해 반복 요청이나 잘못된 트래픽 분류를 일으킨 부분을 찾습니다. 모든 구성을 한 번에 삭제하는 것보다 안전하며 복구 경로도 남길 수 있습니다.

업데이트 후 먼저 상태 이전을 확인하고 전체 구성을 바로 다시 만들지 않기

App Store에서 업데이트한 뒤 스위치 실패, 서버 선택 불가, 규칙 동작 변화 또는 화면 상태 이상이 나타나면 먼저 Shadowrocket 연결을 재시작하세요. Home을 끄고 시스템 VPN 표시가 사라질 때까지 기다린 다음 다시 켭니다. 이어서 현재 서버, Global Routing, Config, DNS 및 On Demand가 업데이트 전에 사용하던 항목과 같은지 확인하세요. 시스템 업데이트로 네트워크 확장 권한이 다시 평가될 수도 있으므로 시스템 Settings에서 VPN 구성이 존재하고 사용할 수 있는지 확인해야 합니다. 시스템 요구 사항과 호환 범위는 App Store 페이지의 표기를 기준으로 합니다.

구성 내용은 그대로인데 특정 구독이나 서버만 실패한다면 구독 및 시간 초과 장에 따라 처리하고 모든 문제를 앱 업데이트 탓으로 돌리지 마세요. 모든 구성이 같은 방식으로 실패하면 먼저 현재 중요한 설정을 내보내거나 기록한 뒤 기기와 네트워크를 재시작하세요. 로컬 데이터의 복구 가능한 백업이 있고 구매 기록을 App Store에서 되찾을 수 있으며 구독 주소도 사용자가 보관하고 있을 때에만 큰 범위의 재구성을 고려하세요. 성급하게 데이터를 지우면 일시적인 시스템 상태 문제가 구성 복구 문제로 바뀔 수 있습니다.

Shadowrocket을 이용할 수 있는 유일한 경로는 App Store 제품 페이지입니다. 페이지에서 개발자 Shadow Launch Technology Limited와 앱 ID 932747118을 확인할 수 있습니다. 앱 업데이트도 App Store에서 관리되므로 온라인에 유통되는 버전 설명으로 스토어 페이지 정보를 대신해서는 안 됩니다.

iPad 전용: 화면 분할, 키보드, 로컬 네트워크 및 기기 변경 복원

먼저 iPad의 구매 및 구성 출처 확인

iPad의 Shadowrocket은 iPhone과 같은 App Store 제품 페이지를 사용합니다. 동일한 Apple ID로 이미 구매했다면 App Store의 구입 항목에서 찾아 복원할 수 있습니다. 구체적인 호환 범위와 시스템 요구 사항은 App Store 페이지의 표기를 기준으로 합니다. 처음 실행할 때는 VPN 구성 추가에 대한 시스템 권한이 필요합니다. iPhone에서는 정상인데 iPad의 스위치가 켜지지 않는다면 iPad의 VPN 권한, 기기 관리 정책, On Demand 조건 및 현재 네트워크를 별도로 확인하세요. 두 기기의 시스템 네트워크 상태가 완전히 같다고 가정하지 마세요.

iCloud, Config 내보내기 또는 Import from Cloud JSON으로 구성을 복원한 뒤에는 “파일이 나타남”과 “구성으로 연결 가능함”을 나누어 확인해야 합니다. 먼저 서버 항목과 Subscribe 주소를 확인하고 현재 서버를 선택한 뒤 Global Routing과 DNS를 점검하고 마지막으로 Home을 켜세요. 백업 시점이 오래되었다면 구독이 관리하는 항목을 다시 업데이트해야 할 수 있습니다. 정책 그룹이 참조하는 서버 이름이 바뀌었다면 Config도 함께 확인하세요. 전체 순서는 구성 백업 및 기기 변경 이전 안내를 참고하세요. 기존 기기에서 iPad로 옮길 때도 같은 방식으로 확인할 수 있습니다.

화면 분할, 여러 창 및 키보드로 인한 화면 차이 처리

iPadOS의 화면 분할과 여러 창은 사용 가능한 너비를 바꾸므로 Home, Config, Settings 또는 Data의 목록과 상세 화면 배치가 달라질 수 있습니다. 버튼이 보이지 않으면 먼저 좁은 화면 분할을 종료하거나 사이드바를 펼치세요. iPhone의 고정된 위치를 기준으로 찾지 마세요. 연결 상태는 시스템 네트워크 확장이 유지하므로 Shadowrocket 창 하나를 닫는다고 Home 연결이 끊기는 것은 아닙니다. 앱 또는 시스템 VPN 상태로 돌아가 확인하세요. 여러 창을 동시에 열었다면 Config를 수정한 뒤 현재 보고 있는 구성이 같은 파일이고 최신 상태인지 확인하세요.

외장 키보드로 Subscribe 주소, SERVER, 비밀번호 또는 규칙을 붙여넣을 때 전각 문장 부호, 스마트 따옴표, 자동 공백 및 줄바꿈에 주의하세요. 규칙 문법에는 영문 쉼표가 필요하며 정책 이름은 기존 이름과 일치해야 합니다. 서식 있는 텍스트에서 길게 눌러 복사한 내용에는 보이지 않는 문자가 섞일 수 있습니다. 겉보기에는 같지만 연결되지 않는다면 일반 텍스트 환경에서 다시 확인한 뒤 필드별로 입력하세요. Scan QR Code로 가져온 뒤에도 결과를 확인해야 하며 스캔이 완료되었다는 사실만으로 충분하지 않습니다.

로컬 네트워크 기기 접근 및 Wi-Fi 환경

iPad는 로컬 네트워크 저장 장치, 프린터 또는 가정용 서비스에 자주 사용됩니다. Shadowrocket을 켠 뒤 로컬 리소스에 접근할 수 없다면 먼저 IP 주소로 테스트해 이름 확인 문제와 네트워크 접근성 문제를 구분하세요. 일반적인 로컬 네트워크 대역에 DIRECT 규칙이 있고 FINAL보다 앞에 배치되어 있는지 확인합니다. IP로는 접속되지만 로컬 이름으로 실패한다면 라우터 DNS 또는 로컬 이름 확인을 점검하세요. IP로도 접속할 수 없다면 Wi-Fi의 게스트 격리 설정, 두 기기가 같은 서브넷에 있는지, 대상 기기가 현재 네트워크의 접근을 허용하는지 확인합니다.

[Rule]
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

학교, 회의 장소 또는 호텔 Wi-Fi에서는 iPad가 먼저 로그인 페이지 인증을 요구할 수 있습니다. Home을 끄고 브라우저를 열어 네트워크 로그인 페이지를 표시한 뒤 일반 페이지에 접속되는지 확인하고 다시 연결하세요. 화면 분할 상태의 브라우저에 로그인 페이지가 나타나지 않으면 잠시 전체 화면으로 열거나 시스템 Wi-Fi 상세 화면에서 네트워크에 다시 연결하세요. 로그인 상태가 만료되면 Shadowrocket은 연결된 것으로 보이지만 모든 요청이 실패할 수 있습니다. 이때는 서버 매개변수를 바로 바꾸지 말고 네트워크 포털을 다시 확인하세요.

iPhone과 iPad를 독립적으로 비교하기

같은 구성에서 iPhone은 정상이고 iPad만 이상하다면 두 기기를 같은 Wi-Fi에 연결하고 같은 서버, 같은 Config 및 같은 Global Routing을 선택한 뒤 결과를 비교하세요. iPad만 실패하면 iPad의 시스템 시간, DNS, VPN 구성, 기기 관리 및 개인 네트워크 관련 설정을 확인합니다. 두 기기 모두 실패하면 서버, 구독 또는 현재 Wi-Fi의 공통 문제일 가능성이 높습니다. 한 기기는 셀룰러 네트워크, 다른 기기는 Wi-Fi를 사용하게 하지 마세요. 접속 네트워크의 차이가 결론에 함께 영향을 주기 때문입니다.

iPad가 셀룰러 네트워크를 지원한다면 Wi-Fi와 셀룰러 네트워크를 각각 테스트하고 On Demand 조건이 두 네트워크에 서로 다른 동작을 설정했는지도 확인하세요. 네트워크를 전환한 뒤 시스템 상태가 안정될 때까지 기다리고 VPN 표시가 바뀌는 동안 Home을 연속해서 누르지 마세요. Wi-Fi에서만 실패하면 라우터와 로그인 페이지를 확인하고, 셀룰러 네트워크에서만 실패하면 셀룰러 신호·데이터 권한 및 해당 On Demand 조건을 확인하세요. 둘 다 실패할 때는 서버 매개변수, DNS 및 시스템 VPN 구성으로 돌아가 점검합니다.

iPad의 App Store 이용, 구입 항목 복원 및 최초 권한 부여 절차를 다시 확인해야 한다면 iPad 이용 안내를 참고하세요. Mac, Apple TV 및 Apple Vision의 호환 정보도 같은 App Store 페이지의 표기를 기준으로 합니다. 이 페이지의 점검 초점은 여전히 iPhone과 iPad입니다.