Shadowrocket 문제 해결 가이드

1. 재현 가능한 문제 해결 기준 세우기

문제 해결의 첫 단계는 즉시 매개변수를 바꾸는 것이 아니라 문제가 어느 단계에서 발생하는지 확인하는 것입니다. Shadowrocket이 연결을 설정할 때는 현재 Wi-Fi 또는 셀룰러 네트워크, 시스템 VPN 구성, 선택한 서버, 프로토콜 매개변수, 규칙 일치, DNS 확인 및 대상 사이트 응답이 차례로 관여합니다. 어느 한 단계라도 실패하면 겉으로는 ‘웹페이지가 열리지 않음’으로 나타날 수 있습니다. 단계를 나누어 판단하지 않고 스위치만 반복해서 전환하면 하나의 명확한 문제가 여러 변수가 동시에 바뀌는 문제로 변하기 쉽습니다.

먼저 현상을 기록하고 기억에 의존하지 마세요

시작하기 전에 네 가지를 기록하세요. 문제가 Wi-Fi, 셀룰러 네트워크 또는 양쪽에서 발생하는지, Shadowrocket을 끈 뒤 일반 웹페이지에 접속할 수 있는지, 연결 스위치가 켜진 상태를 유지하는지, 문제가 모든 도메인·특정 도메인·특정 앱 유형 중 어디에서 발생하는지 확인합니다. 현재 Global Routing이 Config, Proxy 또는 Direct인지, 방금 구독을 업데이트했는지, Config를 수정했는지, 서버를 바꿨는지, DNS를 변경했는지도 기록하세요. 민감한 서버 내용은 저장할 필요가 없으며 작업 순서와 결과만 남기면 됩니다.

‘연결됨’과 ‘정상적으로 전송됨’은 같은 의미가 아닙니다. 시스템 상태 막대에 VPN 표시가 나타난다는 것은 시스템이 연결 구성을 수락했다는 뜻일 뿐, 서버에 반드시 연결된다는 뜻도 아니고 규칙이 요청을 예상한 정책으로 보낸다는 뜻도 아닙니다. 반대로 특정 웹사이트가 열리지 않는다고 전체 연결이 실패한 것은 아닙니다. 해당 도메인이 REJECT에 일치했거나, DNS 응답이 비정상이거나, 대상 사이트가 응답을 거부했거나, 현재 규칙이 사용할 수 없는 정책으로 요청을 보냈을 수 있습니다.

변수를 최소화해 네 가지 조건을 비교하세요

1. Shadowrocket을 끄고 현재 네트워크에서 평소 안정적으로 접속되는 페이지 두 개를 열어 로컬 네트워크 자체가 데이터를 전송할 수 있는지 확인합니다.
2. 같은 네트워크와 같은 서버를 유지한 채 Global Routing을 일시적으로 Proxy로 설정하고 문제가 계속되는지 확인합니다.
3. 다른 조건은 유지하고 Global Routing을 Direct로 바꿔 연결이 켜진 상태에서 시스템 기본 네트워크가 정상 작동하는지 판단합니다.
4. 매개변수가 확인된 서버 하나만 바꾼 뒤 테스트를 반복해 특정 서버 문제인지 전체 구성 문제인지 구분합니다.

네 가지 결과로 범위를 빠르게 좁힐 수 있습니다. Direct는 정상이고 Proxy가 비정상이면 서버와 프로토콜 매개변수를 확인하세요. Proxy는 정상이고 Config가 비정상이면 규칙, 정책 이름과 DNS를 확인하세요. 연결을 끄면 정상이고 Direct도 비정상이면 시스템 VPN 구성, On Demand 또는 다른 네트워크 확장 프로그램의 충돌을 확인하세요. 모든 상태가 비정상이면 먼저 현재 Wi-Fi 또는 셀룰러 네트워크를 복구해야 합니다. 비교가 끝나면 원래 Global Routing으로 되돌려 임시 테스트 상태를 정식 구성으로 남기지 마세요.

앱 출처와 사용 전제 확인

기기의 앱 출처, 구매 기록 또는 앱 식별 정보를 확인할 수 없다면 먼저 정품 확인 안내에서 개발자 Shadow Launch Technology Limited, 공식 아이콘 및 앱 ID 932747118을 확인하세요. Shadowrocket은 일회성 구매 클라이언트이지만 클라이언트의 일회성 구매는 회선 요금제가 아닙니다. 이후 연결에는 사용자가 직접 보유한 구독 또는 서버 정보가 필요합니다. 이 가이드는 클라이언트 내부의 진단 방법만 설명하며 서비스 출처를 평가하지 않습니다.

문제 해결 중에는 Config를 자주 삭제하거나 기존 데이터를 한꺼번에 덮어쓰지 마세요. 먼저 현재 선택한 서버와 구성 이름을 기록하고, 중요한 사용자 지정 규칙은 별도로 텍스트 사본을 저장한 뒤 항목별로 조정하는 방법이 안전합니다. 자신의 서비스 제공업체에 문의해야 한다면 최소한 문제 발생 시간, 네트워크 유형, 프로토콜 이름, Connectivity Test 결과와 특정 서버만 문제인지 여부를 전달하세요. 일반 스크린샷에는 비밀번호, 전체 구독 주소와 인증 정보를 포함하지 않아야 합니다.

2. 연결 스위치가 켜지지 않거나 즉시 꺼짐

Home의 연결 스위치가 켜진 상태를 유지하지 못하는 경우는 대개 시스템 VPN 구성 권한이 아직 부여되지 않았거나, 기존 네트워크 확장 상태가 비정상적이거나, On Demand가 반복해서 작동하거나, 앱 구성을 시스템이 수락하지 못할 때 발생합니다. 이는 서버 시간 초과와 다릅니다. 서버 시간 초과는 스위치가 켜진 상태를 유지하면서 요청만 완료하지 못하는 경우가 많지만, 스위치가 즉시 꺼지면 먼저 서버가 아니라 기기 측 연결 설정 과정을 확인해야 합니다.

최초 권한과 시스템 상태 확인

처음 연결을 켜면 시스템에서 VPN 구성 추가를 허용하라는 메시지가 표시되며 기기 암호, Touch ID 또는 Face ID 확인을 요구할 수 있습니다. 권한 부여 중 취소했다면 Home으로 돌아간 뒤 다시 켜서 확인 절차를 다시 표시하세요. 권한 부여가 끝나면 시스템 설정의 VPN 관련 화면에서 Shadowrocket에 해당하는 구성이 존재하는지 확인할 수 있습니다. 시스템별 메뉴 이름과 위치는 달라질 수 있으므로 특정 경로를 외우기보다 시스템에서 해당 연결 구성이 보이는지만 확인하면 됩니다.

시스템 페이지에 오랫동안 사용하지 않은 VPN 구성이 여러 개 있다면 현재 실제로 사용하는 항목을 먼저 확인하세요. 여러 연결 도구가 시스템 VPN 상태를 연속해서 차지하도록 하지 마세요. 다른 네트워크 확장 프로그램의 연결을 모두 끊은 뒤 Shadowrocket으로 돌아와 테스트합니다. 네트워크를 전환하거나 기기 잠금을 막 해제했거나 데이터 연결을 복구한 직후 시스템이 잠시 전환 상태일 수 있으므로 10~20초 기다린 뒤 조작하는 편이 스위치를 빠르게 반복해서 누르는 것보다 판단 가능한 결과를 얻기 쉽습니다.

On Demand를 수동 연결 문제와 분리

On Demand는 설정된 네트워크 조건에 따라 연결 시점을 결정합니다. 조건이 겹치거나 현재 Wi-Fi 이름이 바뀌었거나 규칙에 연결과 해제 동작이 함께 포함되면 스위치를 켠 직후 조건이 다시 적용되는 현상이 나타날 수 있습니다. 수동 스위치를 확인할 때는 Settings에서 On Demand를 일시적으로 끄고 Home의 수동 스위치만 테스트하세요. 수동 연결이 복구되면 시스템 권한과 기본 구성은 대체로 정상인 것이므로 서버를 다시 만들기보다 On Demand 조건을 하나씩 확인해야 합니다.

조건을 확인할 때는 가장 구체적인 네트워크 조건부터 시작하세요. 특정 Wi-Fi에 적용되는 조건이라면 공백과 대소문자를 포함해 이름이 완전히 일치하는지 확인합니다. 네트워크 유형을 기준으로 하는 조건이라면 기기가 실제로 해당 네트워크에 연결되어 있는지 확인하세요. 한 번에 하나의 조건만 활성화하고 잠근 뒤 다시 잠금 해제한 다음 Wi-Fi와 셀룰러 사이를 전환해 테스트합니다. 각 조건이 독립적으로 작동한 뒤에만 다시 조합해야 여러 조건이 서로 덮어쓰는 일을 피할 수 있습니다.

기존 데이터를 훼손하지 않고 시스템 연결 재구성

권한 부여가 완료되고 On Demand도 일시적으로 껐지만 스위치가 계속 즉시 꺼진다면 Shadowrocket을 정상적으로 종료한 뒤 다시 여세요. 그런 다음 비행기 모드를 한 번 전환해 시스템이 네트워크 인터페이스를 다시 만들도록 합니다. 특정 Wi-Fi에서만 문제가 발생한다면 해당 네트워크를 무시한 뒤 다시 연결해 DHCP 또는 LAN 상태가 남아 있는지 확인하세요. Wi-Fi와 셀룰러에서 동일하다면 시스템의 Shadowrocket VPN 구성을 다시 만드는 것을 고려합니다. 작업 전에 서버 정보와 Config의 신뢰할 수 있는 사본이 있는지 확인하세요.

시스템 연결 재구성의 목적은 시스템이 VPN 구성을 다시 수락하도록 하는 것이며 구독이나 서버를 하나씩 삭제하는 것이 아닙니다. 완료 후 On Demand를 끄고 매개변수가 명확한 서버 하나를 선택한 다음 Global Routing을 Proxy로 설정해 일반 페이지 하나만 테스트하세요. 스위치가 켜진 상태를 유지하면 ‘연결 후 인터넷에 접속할 수 없음’ 절로 이동합니다. 여전히 즉시 꺼지면 기기를 재시동한 뒤 다시 테스트하고, 기기가 VPN 변경을 제한하는 관리 상태인지 확인하세요.

기기 관리와 네트워크 제한 구분

조직에서 관리하는 기기는 VPN 구성 추가 또는 수정을 제한할 수 있으며, 시스템은 일반적으로 권한 부여 중 안내를 표시합니다. 이러한 제한은 Shadowrocket의 프로토콜 매개변수를 바꿔 해결할 수 없으며 기기 관리자가 허용된 네트워크 정책을 확인해야 합니다. 가정용 네트워크의 라우터 제한은 보통 스위치를 즉시 꺼지게 하기보다 연결 후 서버에 접근할 수 없는 형태로 나타나므로 스위치가 안정적으로 유지되는지에 따라 구분해야 합니다.

최종 검증에서는 조건을 단순하게 유지하세요. 기본 네트워크가 정상이고 On Demand는 꺼져 있으며 Global Routing은 Proxy이고 서버는 하나만 선택한 상태에서 연결이 안정될 때까지 기다립니다. 이 단계를 마친 뒤 스위치를 사용할 수 있다면 기존 설정을 하나씩 복원하고 항목을 복원할 때마다 테스트하세요. 이렇게 하면 전체 구성을 복원한 뒤 같은 문제를 다시 만나는 대신 스위치를 꺼지게 만든 설정을 정확히 찾을 수 있습니다.

3. 연결은 성공했지만 웹페이지와 앱에 접속할 수 없음

스위치는 켜져 있고 시스템에도 VPN 상태가 표시되지만 웹페이지와 앱에 데이터가 전달되지 않는 경우는 가장 혼동하기 쉽습니다. 사용할 수 없는 서버, 잘못된 프로토콜 매개변수, 모든 요청을 잘못된 정책으로 보내는 규칙, DNS 확인 실패 또는 LAN 주소의 잘못된 처리가 원인일 수 있습니다. 먼저 ‘모든 요청이 실패하는지’ 또는 ‘일부 요청만 실패하는지’를 판단한 뒤 Proxy, Config 또는 DNS를 확인하세요.

먼저 Direct와 Proxy로 문제 단계를 구분

Shadowrocket을 켠 상태에서 Global Routing을 Direct로 설정하세요. Direct에서도 일반 페이지에 접속할 수 없다면 시스템 네트워크 인터페이스, 로컬 네트워크 또는 연결 구성에 가까운 문제입니다. 먼저 Wi-Fi와 셀룰러를 전환해 원래 네트워크가 데이터를 전송할 수 있는지 확인하세요. Direct가 정상이면 Proxy로 바꿉니다. Proxy에서 모두 실패하면 현재 서버, 포트, 프로토콜 및 인증 매개변수를 중점적으로 확인하세요. Proxy는 정상이고 Config만 실패하면 서버 자체가 우선 원인이 아닐 가능성이 크므로 규칙과 정책 참조를 확인해야 합니다.

테스트 중에는 같은 대상 페이지를 사용하고 매번 다른 사이트를 선택하지 마세요. 브라우저가 캐시를 보유할 수 있고 일부 앱은 자동으로 재시도하므로 일반 HTTPS 페이지 두 개를 준비해 각 상태로 전환한 뒤 연결이 안정될 때까지 기다렸다가 새로 고침하세요. 한 페이지는 정상이고 다른 페이지만 실패한다면 실패 도메인을 기록하고 Data 또는 연결 로그에서 최종적으로 어떤 규칙에 일치했는지 확인하세요. 결과를 단순히 ‘네트워크가 들쭉날쭉하다’고 요약하지 마세요.

Config의 정책 이름과 규칙 순서 확인

Config는 규칙을 위에서 아래로 일치시키며 먼저 일치한 규칙이 처리 정책을 결정합니다. 규칙 끝의 PROXY, DIRECT, REJECT 또는 사용자 지정 정책 이름은 현재 구성에 실제로 존재하는 정책과 일치해야 합니다. 가져온 Config가 존재하지 않는 정책 그룹을 참조하면 요청이 예상대로 처리되지 않을 수 있습니다. 특히 구성을 교체한 뒤 서버가 여전히 존재한다고 해서 이전 구성의 정책 이름도 유효하다는 뜻은 아닙니다.

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

위 예에서는 특정 도메인을 먼저 PROXY로 보내고, LAN 주소는 직접 연결한 뒤 GEOIP를 처리하며 마지막에는 FINAL이 대체합니다. 실제 구성의 순서는 사용 목적에 맞춰 정해야 합니다. FINAL을 중간에 배치하면 뒤의 규칙은 일치할 기회를 얻지 못합니다. 자주 사용하는 도메인을 REJECT로 잘못 보내면 특정 사이트가 즉시 실패하고, LAN 주소에 Direct 규칙이 없으면 Shadowrocket을 켠 뒤 프린터, 라우터 관리 페이지 또는 다른 로컬 기기에 접근할 수 없게 될 수 있습니다.

요청이 실제로 전송되었는지 확인

Data에서 실패 요청을 관찰할 때는 전체 트래픽보다 도메인, 연결 결과, 일치한 규칙과 정책을 중점적으로 확인하세요. 기록이 전혀 없다면 앱이 요청을 보내지 않았거나 캐시가 직접 처리했거나 시스템 네트워크가 아직 복구되지 않았을 수 있습니다. 도메인은 있지만 확인에 실패하면 DNS 절로 이동하세요. 대상 IP는 있지만 연결 설정이 시간 초과되면 서버 또는 경로를 확인합니다. 즉시 거부 결과가 나타나면 REJECT와 대상 사이트 응답을 확인하세요.

일부 앱은 장시간 연결을 유지합니다. Global Routing이나 서버를 바꿔도 기존 연결이 즉시 다시 만들어지지 않을 수 있으므로 테스트할 때 대상 앱을 완전히 종료한 뒤 다시 열거나 새 세션을 만들 때까지 기다리세요. 브라우저에서 반복해서 새로 고침하는 것만으로 모든 앱의 동작을 대표할 수는 없습니다. 브라우저는 정상이고 특정 앱만 비정상이라면 해당 앱이 특수한 연결 방식을 사용하는지, 이전 DNS를 캐시하는지, Config에 해당 도메인 또는 USER-AGENT를 대상으로 한 규칙이 있는지 먼저 확인하세요.

LAN과 네트워크 전환 경계 처리

Wi-Fi에서 셀룰러로 전환하면 기존 연결은 네트워크 인터페이스 변화를 겪습니다. Shadowrocket은 보통 세션을 다시 만들지만 전송 중인 요청은 한 번 실패할 수 있습니다. 상태가 안정될 때까지 기다린 뒤 다시 테스트하고 전환 순간의 실패를 지속적인 문제로 판단하지 마세요. 전환할 때마다 복구되지 않는다면 On Demand 조건이 새 네트워크에서 다른 상태를 선택하는지, Config가 LAN과 셀룰러에 서로 다른 DNS를 사용하는지 확인하세요.

LAN 기기만 접근할 수 없다면 해당 주소 범위를 확인하고 적절한 IP-CIDR 규칙을 DIRECT로 보내세요. 규칙 범위를 임의로 넓히면 다른 정책으로 처리해야 할 공용 주소까지 포함될 수 있습니다. 수정 후 Config를 다시 불러오고 특정 LAN IP로 테스트하세요. 규칙의 위에서 아래로의 일치와 FINAL에 대한 자세한 설명은 사용자 지정 규칙과 우선순위를 참조하세요.

4. 서버가 시간 초과되거나 연결 테스트에 실패함

서버 목록의 시간 초과는 대개 테스트 요청이 제한 시간 내에 완료되지 않았다는 뜻이지만, ‘시간 초과’만으로 서버가 응답을 중지했다고 단정할 수는 없습니다. 도메인 확인 실패, 포트 접근 불가, 프로토콜 매개변수 불일치, 현재 네트워크의 패킷 손실, 서버 측 제한 또는 테스트 대상의 느린 응답도 비슷한 결과를 만들 수 있습니다. ‘확인 가능한가’, ‘포트에 도달하는가’, ‘프로토콜 상호 작용을 완료하는가’, ‘실제 요청이 전송되는가’를 나누어 판단해야 합니다.

Connectivity Test의 범위 이해

Connectivity Test는 현재 항목이 지정된 테스트를 완료할 수 있는지 빠르게 비교하는 기능이지만 테스트 수치가 전체 사용 경험을 의미하지는 않습니다. 한 번 높은 결과가 나와도 당시 네트워크 변동 때문일 수 있고, 한 번 시간 초과가 발생해도 일시적인 패킷 손실일 수 있습니다. 같은 네트워크에서 일정한 간격으로 여러 번 테스트해 지속적인 시간 초과인지 확인하고 실제 HTTPS 페이지로 재검증하세요. 목록 전체를 짧은 간격으로 계속 테스트하면 로컬 네트워크와 서버 연결을 동시에 사용해 결과 해석이 더 어려워질 수 있습니다.

하나의 항목만 계속 시간 초과되고 같은 구독의 다른 항목은 정상이라면 해당 항목의 서버 주소, 포트와 서버 상태를 먼저 확인하세요. 모든 항목이 동시에 시간 초과되면 기본 네트워크와 DNS를 확인한 뒤 다른 로컬 네트워크로 전환하세요. Wi-Fi에서만 모두 시간 초과되고 셀룰러는 정상이라면 현재 Wi-Fi, 라우터 또는 상위 경로에 문제가 있을 가능성이 큽니다. 두 네트워크에서 모두 같다면 가져온 내용이 완전한지와 서버 측에 공통 변경이 있었는지 확인하세요.

프로토콜 매개변수를 항목별로 확인

서버를 수동으로 추가할 때 SERVER, 포트, 비밀번호 또는 인증 정보, 프로토콜 유형과 추가 옵션은 사용자가 보유한 서버 정보와 일치해야 합니다. Shadowsocks는 암호화 방식과 비밀번호를 확인해야 합니다. VMess, VLESS, Trojan은 주소, 포트, 인증 정보와 TLS, 전송 방식, Host 등의 추가 필드에 주의하세요. WireGuard는 키, 주소와 라우팅 범위를 확인해야 하며 Hysteria2에는 해당 인증 및 전송 매개변수가 포함됩니다. 서로 다른 프로토콜의 필드를 경험에 의존해 임의로 적용하지 마세요.

Scan QR Code 또는 Import from Cloud JSON으로 가져온 뒤에도 항목을 열어 핵심 필드가 빠짐없이 입력되었는지 확인하세요. QR 코드를 인식할 수 있다는 것은 텍스트 형식을 해석할 수 있다는 뜻일 뿐 서버 매개변수가 여전히 유효하다는 뜻은 아닙니다. 서비스 제공업체가 서버 정보를 변경했다면 사용자가 직접 제공업체에서 받은 최신 내용을 기준으로 삼으세요. 의미를 모르는 상태에서 TLS를 임의로 켜거나 전송 방식을 바꾸거나 Host를 수정하지 마세요. 이런 변경은 거의 맞던 구성을 완전히 불일치하게 만들 수 있습니다.

지연 시간, 패킷 손실과 처리량 구분

지연 시간은 한 번 왕복하는 데 걸리는 시간을 나타내고, 패킷 손실은 재전송과 멈춤을 유발하며, 처리량은 서버 부하, 경로 용량, 프로토콜 오버헤드와 로컬 네트워크의 영향을 함께 받습니다. 지연 시간이 짧은 항목이 지속 전송에서 반드시 더 빠른 것은 아니며, 지연 시간이 긴 항목도 반드시 사용할 수 없는 것은 아닙니다. 따라서 선택할 때는 지속적인 시간 초과를 먼저 제외하고 같은 작업으로 안정성을 비교하세요. 자세한 방법은 지연 시간 테스트와 실제 사용 경험의 차이를 참조하세요.

테스트가 정상에서 갑자기 전체 시간 초과로 바뀌었다면 변화 전에 구독을 업데이트했는지, Config를 바꿨는지, DNS를 변경했는지 또는 네트워크를 교체했는지 되돌아보세요. 확인 가능한 이전 상태로 돌아간 뒤 변경 사항을 하나씩 다시 적용합니다. 주소와 매개변수가 정확한데도 여러 네트워크와 시간대에서 계속 시간 초과된다면 테스트 시간, 프로토콜 이름과 비식별화한 오류 현상을 자신의 서비스 제공업체에 전달해 서버 측을 확인하세요. 클라이언트의 무관한 규칙을 계속 수정하지 마세요.

5. Subscribe 업데이트 실패 또는 가져온 뒤 비어 있음

Subscribe는 사용자가 보유한 구독 주소에서 서버 목록을 읽어오는 기능입니다. 업데이트 실패는 주소 입력, HTTPS 접속, DNS, 서버 응답, 콘텐츠 형식 또는 로컬 목록 저장 단계에서 발생할 수 있습니다. 가져온 뒤 목록이 비어 있는 것은 요청이 실패했다는 뜻만은 아닙니다. Shadowrocket이 인식할 수 있는 항목이 응답에 없거나 기존 필터 조건 때문에 항목이 표시되지 않을 수도 있습니다. 문제를 확인할 때는 전용 인증 정보가 포함될 수 있는 구독 주소를 보호하세요.

먼저 주소가 완전한지 확인

Subscribe에서 해당 항목을 열고 주소의 시작 부분, 도메인, 경로와 쿼리 부분이 모두 포함되었는지 확인하세요. 복사할 때 흔한 문제는 앞뒤에 공백이 섞이거나, 채팅 도구가 긴 주소를 잘라내거나, 물음표 앞까지만 복사하는 것입니다. 실제 주소를 공개 테스트 사이트에 붙여 넣지 말고 스크린샷에도 전체 쿼리 내용을 노출하지 마세요. 서비스 제공업체에 문의할 때는 도메인과 오류 메시지만 표시하고 계정을 식별할 수 있는 경로 부분은 가리세요.

먼저 Shadowrocket 연결을 끄고 현재 기본 네트워크에서 구독 도메인에 접속해 도메인이 HTTPS 연결을 설정할 수 있는지 확인하세요. 이 단계는 공개 콘텐츠를 확인하려는 것이 아니라 로컬 네트워크와 도메인 확인을 점검하기 위한 것입니다. 연결을 끄면 접속되고 켜면 실패한다면 Config가 구독 도메인에 잘못된 정책을 적용하는지 확인하세요. 규칙 앞부분에서 해당 도메인에 정상 작동하는 정책을 지정한 뒤 다시 업데이트할 수 있지만, 알 수 없는 도메인을 넓은 범위의 규칙에 임의로 추가하지 마세요.

네트워크 실패와 형식 실패 구분

네트워크 실패는 일반적으로 시간 초과, 도메인 확인 불가 또는 연결 중단으로 나타납니다. 형식 실패는 요청이 빠르게 완료되지만 서버 항목이 생성되지 않거나 인식할 수 없는 콘텐츠라는 안내가 표시되는 형태일 수 있습니다. 전자는 DNS와 로컬 네트워크 방향으로 확인하고, 후자는 서버에서 Shadowrocket에 사용할 수 있는 최신 구독 형식을 반환하는지 확인해야 합니다. 클라이언트가 URL을 열 수 있다고 해서 반환된 텍스트에 가져올 수 있는 데이터가 포함된다는 뜻은 아닙니다.

같은 주소가 이전에는 업데이트되었는데 최근 갑자기 비어 있다면 먼저 기존 목록을 삭제하지 마세요. 기존 항목 수와 업데이트 시간을 기록한 뒤 수동으로 한 번 업데이트해 결과를 확인합니다. 새 콘텐츠가 비정상이라면 기존 데이터를 보존하는 것이 계속 검증하는 데 도움이 됩니다. 서버가 복구된 것을 확인한 뒤 업데이트하세요. 이미 덮어썼다면 다시 가져오기 전에 주소가 여전히 유효한지 확인해야 합니다. 구독 콘텐츠는 사용자의 서비스 제공업체가 관리하므로 클라이언트가 서버에서 반환한 빈 텍스트, 오류 페이지 또는 만료된 인증 정보를 수정할 수는 없습니다.

중복, 이름 변경과 필터 처리

같은 주소를 여러 번 추가하면 Subscribe 항목이 여러 개 생성되어 업데이트가 적용되지 않은 것처럼 보일 수 있으며, 실제로는 다른 목록을 보고 있을 수 있습니다. 구독 이름과 주소 도메인을 확인하고 필요한 항목만 남긴 뒤 수동으로 업데이트하세요. 메모, 정렬 또는 필터를 사용 중이라면 일시적으로 필터를 지워 새 항목이 저장되었는지 확인합니다. 이름이 바뀌면 익숙한 항목이 ‘사라진’ 것처럼 보일 수 있으므로 표시 이름만 보지 말고 서버 주소와 프로토콜 유형으로 확인하세요.

구독 업데이트는 서버 정보만 동기화하며 현재 Config의 모든 정책 이름이 새 목록과 일치하도록 자동으로 보장하지는 않습니다. 업데이트 후 서버는 존재하지만 Config가 참조하는 사용자 지정 정책에 사용할 수 있는 구성원이 없으면 Config 상태에서 여전히 인터넷에 접속할 수 없을 수 있습니다. 먼저 Proxy에서 새 항목 하나를 직접 선택해 테스트하고 항목 자체가 작동하는지 확인한 뒤 Config의 정책 관계를 처리하세요. 이렇게 하면 구독 저장 성공을 규칙 오류로 오해하거나 규칙 문제를 구독 문제로 오해하는 일을 피할 수 있습니다.

안정적인 업데이트 순서 세우기

기본 네트워크가 정상일 때 업데이트를 실행하는 것이 좋습니다. 먼저 연결을 끈 상태에서 일반 페이지에 접속할 수 있는지 확인하고, Subscribe 하나를 업데이트합니다. 업데이트가 끝나면 항목이 바뀌었는지 확인하고, 항목 하나를 선택해 Connectivity Test를 실행한 뒤 원래 Config를 활성화하세요. 자동 업데이트 간격을 너무 짧게 설정해 사용을 자주 방해하지 말고, 연결할 때마다 많은 요청을 동시에 처리하도록 의존하지도 마세요. 특정 네트워크에서만 업데이트가 실패한다면 네트워크 유형을 기록하고 DNS 절에서 계속 확인하세요.

스캔 또는 파일 가져오기에서 오류가 발생했다면 Scan QR Code에는 완전하고 선명한 내용이 필요하고, Import from Cloud JSON에는 앱이 인식할 수 있는 구조가 필요합니다. 파일을 선택할 수 있다고 해서 파일 내용이 올바른 것은 아닙니다. 가져오기 전에 원본 데이터를 보존하고 오류가 발생하면 정보 출처에서 유효한 내용을 다시 받으세요. 누락된 필드를 추측해 수동으로 입력하지 마세요. 전체 시작 경로는 사용 설명의 가져오기 단계를 참조하세요.

6. 속도 저하, 동영상 멈춤 또는 연결 불안정

속도 문제는 기기 로컬 네트워크, 서버 상태, 전송 경로, 프로토콜 특성, 대상 사이트의 다섯 단계로 나누어야 합니다. 한 번의 속도 측정 수치는 지속적인 사용 경험을 나타낼 수 없고, 특정 앱이 멈춘다고 서버 처리량 부족을 바로 의미하지도 않습니다. 효과적인 문제 해결에는 같은 기기, 같은 네트워크, 같은 시간대와 같은 테스트 작업을 사용하고 변수 하나만 바꾸면서 최소 두세 번 반복하는 과정이 필요합니다.

먼저 기본 네트워크의 한계 측정

Shadowrocket을 끄고 현재 Wi-Fi 또는 셀룰러 네트워크에서 기본 테스트를 한 번 수행하며 뚜렷한 변동이 있는지 확인하세요. 기본 네트워크 자체가 불안정하면 연결을 켠 뒤 재전송과 지연이 보통 더 커지므로 먼저 프로토콜을 조정하지 마세요. Wi-Fi에서는 라우터와의 거리, 주파수 대역 혼잡, 같은 네트워크의 다른 기기에서 발생하는 대량 트래픽, 기기의 시스템 동기화 여부도 확인하세요. 셀룰러로 전환해 다시 테스트하면 문제가 현재 Wi-Fi에만 해당하는지 빠르게 판단할 수 있습니다.

다운로드, 웹페이지 열기와 동영상 재생을 테스트할 때는 ‘응답 시작까지 걸린 시간’과 ‘지속 전송이 안정적인지’를 따로 기록하세요. 전자는 DNS, 핸드셰이크와 지연 시간의 영향을 더 많이 받고 후자는 처리량과 패킷 손실에 가깝습니다. 웹페이지 첫 화면은 느리지만 이후 전송이 정상이라면 확인 또는 핸드셰이크 경로가 길기 때문일 수 있습니다. 시작은 빠르지만 중간에 반복해서 멈춘다면 패킷 손실, 서버 부하와 경로 변동을 더 중점적으로 확인하세요.

서버 비교 시 다른 조건을 동일하게 유지

사용자가 보유하고 매개변수가 완전한 서버 두 개를 선택한 뒤 Global Routing을 일시적으로 Proxy로 설정하고 같은 네트워크에서 같은 작업을 테스트하세요. 서버를 바꾸면서 DNS나 프로토콜 옵션도 함께 바꾸지 마세요. 특정 서버 하나만 계속 느리다면 해당 서버 또는 경로에 가까운 문제입니다. 모든 서버가 느리고 연결을 끄면 정상이라면 관련 프로토콜의 전송 품질, DNS와 기기 상태를 확인하세요. 연결을 꺼도 느리면 기본 네트워크부터 처리해야 합니다.

서버 지역은 경로에 영향을 주는 요소 중 하나일 뿐이며 이름만으로 속도를 판단할 수 없습니다. 실제 경로는 네트워크 시간대, 서버 부하와 대상 사이트의 접속 위치에 영향을 받을 수 있습니다. Connectivity Test가 낮다는 것은 테스트 왕복이 빠르다는 뜻일 뿐 지속 처리량이 높다는 보장은 없습니다. 목록의 최소 수치만 추구하기보다 여러 번 테스트해 안정적이고 실제 작업이 연속되며 오류율이 낮은 항목을 우선 선택하세요.

프로토콜과 추가 매개변수의 일치 여부 확인

프로토콜 설정이 잘못되면 속도 저하뿐 아니라 재연결, 핸드셰이크 실패 또는 완전한 사용 불가가 함께 나타나는 경우가 많습니다. 연결은 되지만 불안정하다면 먼저 매개변수가 서버 측과 일치하는지 확인한 뒤 네트워크 특성을 검토하세요. 속도를 높이려고 암호화 방식, TLS, 전송 방식, UDP 관련 옵션 또는 WireGuard 라우팅 범위를 임의로 바꾸지 마세요. 클라이언트와 서버가 일치하지 않으면 어떤 ‘최적화’도 신뢰할 수 있는 기반을 갖지 못합니다.

일부 실시간 앱은 UDP에 의존하며 일부 네트워크에서는 UDP 성능이 TCP와 다를 수 있습니다. 웹페이지는 정상인데 실시간 음성, 게임 또는 영상 통화가 비정상이라면 앱 유형과 네트워크 유형을 기록하고, 자신의 서버 정보가 허용하는 범위에서 UDP 지원 여부를 확인하세요. 모든 옵션을 무작정 바꾸는 방식으로 판단하지 말고 프로토콜 요구 사항에 따라 하나씩 확인해야 합니다. 서버 측 기능을 확인할 수 없다면 자신의 서비스 제공업체에 현재 서버가 지원하는 매개변수를 문의하세요.

시간대별 변화와 전환 후 일시적 변동 처리

낮에는 정상이고 특정 시간대에 느려진다면 시간대를 달리해 비교하지 말고 같은 시간대에 기본 네트워크와 여러 서버를 비교하세요. 네트워크 혼잡은 시간대의 영향을 받는 경우가 많으므로 연결을 끈 결과도 함께 기록해야 로컬 접속 혼잡과 서버 경로 변화를 구분할 수 있습니다. Wi-Fi, 셀룰러 또는 서버를 전환한 뒤 기존 연결이 일정 시간 유지될 수 있으므로 대상 앱을 다시 열어 새 세션을 만든 뒤 판단하세요.

테스트가 끝나면 Config를 복원하고 속도 문제가 특정 유형의 도메인에만 영향을 주는지 확인하세요. Proxy는 정상이고 Config만 느리다면 해당 도메인이 Direct로 처리되었거나 DNS가 적절하지 않은 주소를 선택했을 수 있습니다. 이때 서버 테스트를 계속 추가하는 것은 의미가 없으며 규칙 일치와 DNS 결과를 확인해야 합니다. 더 자세한 단계별 사례는 속도 저하의 네 단계 진단 방법을 참조하세요.

7. DNS 확인 실패, 도메인 접속 불가 또는 비정상 결과

DNS는 도메인을 IP 주소로 변환합니다. DNS 오류는 도메인이 열리지 않거나 IP를 직접 입력하면 응답할 수 있고, 일부 도메인만 간헐적으로 작동하거나 네트워크를 전환한 뒤 잠시 이전 결과를 사용하는 형태로 나타납니다. 규칙과 함께 작동할 수도 있습니다. Shadowrocket은 먼저 도메인 또는 대상 주소를 확인한 뒤 DOMAIN-SUFFIX, GEOIP, IP-CIDR 등의 규칙에 따라 정책을 결정합니다. 확인과 트래픽 분기는 서로 다른 단계지만 최종 결과에는 서로 영향을 줍니다.

먼저 확인 문제인지 판단

실패하는 도메인 하나와 정상인 도메인 하나를 선택해 같은 상태에서 각각 테스트하세요. Data의 실패 요청에 확인 불가, 대상 IP 없음 또는 DNS 관련 오류가 빠르게 표시되면 확인 문제일 가능성이 높습니다. 대상 IP를 이미 얻었지만 연결 단계에서 시간 초과된다면 서버 또는 경로 문제로 돌아가야 합니다. 브라우저에 ‘서버를 찾을 수 없음’이라고 표시된다는 이유만으로 결론 내리지 마세요. 브라우저가 서로 다른 하위 오류를 하나의 안내로 표시할 수 있습니다.

Direct, Proxy와 Config의 결과를 비교하세요. Direct는 정상이고 Config만 비정상이면 구성의 DNS 설정 또는 규칙이 차이를 만들었을 수 있습니다. Proxy는 정상이고 Direct가 비정상이면 현재 로컬 네트워크의 DNS가 대상 도메인에 비정상적으로 응답할 수 있습니다. 세 상태가 모두 실패하면 도메인 자체, 기기 네트워크와 캐시를 확인하세요. 전환할 때마다 브라우저 탭을 새로 열고 필요하다면 네트워크를 잠시 바꿔 시스템이 새로운 확인 절차를 시작하도록 하세요.

Config의 DNS와 Host 확인

.conf의 General 섹션에는 DNS 관련 설정이 포함될 수 있고 Host 섹션에서는 특정 도메인에 매핑을 지정할 수 있습니다. 잘못된 Host 항목은 외부 DNS가 정상이어도 도메인을 항상 잘못된 주소로 보내 복구되지 않게 합니다. 확인할 때는 먼저 실패 도메인이 Host 섹션에 있는지 검색하고, General의 DNS 설정이 신뢰할 수 있으며 현재 접근 가능한 출처인지 확인하세요. 용도를 모르는 확인 옵션을 여러 개 동시에 추가하지 마세요.

[General]
dns-server = system

[Host]
router.example.com = 192.168.1.1

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

예시는 설명을 위해 system을 사용하고 LAN 예시 도메인에 주소를 지정합니다. 실제 구성은 자신의 네트워크 요구 사항에 따라 결정해야 합니다. Host 매핑은 명확한 우선 적용 효과가 있으므로 주소가 바뀐 뒤 수정하지 않으면 안정적이지만 잘못된 결과가 발생합니다. 알 수 없는 구성을 확인할 때는 먼저 사본을 저장하고 실패 도메인과 관련된 Host 항목을 일시적으로 제거해 다시 테스트하세요. 구성 파일의 섹션 구조는 General, Rule, Host 및 URL Rewrite 설명을 참조하세요.

도메인 규칙과 IP 규칙의 우선 관계 이해

DOMAIN, DOMAIN-SUFFIX와 DOMAIN-KEYWORD는 도메인을 기준으로 일치하고 IP-CIDR, IP-CIDR6와 GEOIP는 대상 주소를 기준으로 일치합니다. 도메인 규칙이 이미 일치했다면 이후 IP 규칙이 해당 요청을 결정하지 않는 경우가 많습니다. 도메인 규칙이 일치하지 않으면 확인된 IP가 계속 GEOIP 또는 IP-CIDR 판단에 참여할 수 있습니다. 규칙 순서가 부적절하면 요청이 예상하지 못한 정책으로 이동해 겉보기에는 DNS 오류처럼 보이지만 실제로는 일치 결과가 예상과 다른 것입니다.

특정 도메인을 확인할 때는 앞부분에 정확한 DOMAIN 또는 적절한 DOMAIN-SUFFIX 규칙을 임시로 추가하고 검증된 정책을 지정할 수 있습니다. 문제가 사라지면 기존 규칙 경로를 계속 확인해야 하며, 여전히 실패하면 DNS와 대상 연결을 확인하세요. 임시 규칙 검증이 끝나면 정식 구성으로 정리해 서로 덮어쓰는 예외 항목이 장기간 쌓이지 않도록 하세요.

캐시 삭제도 순서를 지켜 진행

시스템, 브라우저와 앱은 모두 DNS를 캐시할 수 있습니다. DNS를 바꾼 직후 한 번 새로 고침한다고 반드시 새로 확인되는 것은 아닙니다. 대상 앱을 종료하고 Shadowrocket 연결을 끊은 뒤 비행기 모드를 한 번 전환하고 다시 연결해 같은 도메인을 테스트하세요. 라우터 재시동, Config 삭제, 서버 변경과 앱 데이터 삭제를 동시에 하지 마세요. 여러 작업이 겹치면 복구되더라도 원인을 알 수 없습니다.

특정 Wi-Fi에서만 확인 오류가 발생한다면 라우터가 할당한 DNS, LAN의 사용자 지정 확인과 만료된 로컬 도메인 매핑이 있는지 확인하세요. 셀룰러가 정상이어도 Config가 반드시 올바르다는 뜻은 아닙니다. 여러 네트워크에서 같은 도메인이 비정상적으로 응답한다면 Host, 규칙과 도메인 자체를 확인하세요. 실패 도메인, 일치 정책, IP 획득 여부와 네트워크 유형을 기록하면 보통 확인 전, 확인 중, 확인 후 세 단계 중 어디에서 문제가 발생했는지 좁힐 수 있습니다.

8. 배터리 소모 이상 및 App Store 업데이트 후 오류

Shadowrocket은 네트워크 확장으로서 연결 중 트래픽을 계속 처리하므로 일정한 배터리 소모는 정상입니다. 확인해야 할 것은 같은 사용 환경에서 배터리 소모가 갑자기 크게 늘거나, 기기가 계속 뜨겁거나, 백그라운드 트래픽이 오랫동안 줄지 않거나, App Store 업데이트 후 기존 구성의 동작이 달라지는 경우입니다. 판단할 때는 특정 한 시간의 비율만 보지 말고 시스템 배터리 통계, Data의 트래픽 활동, 네트워크 품질과 최근 설정 변경을 함께 확인하세요.

클라이언트 처리와 앱 트래픽 구분

시스템 배터리 통계는 네트워크 확장을 통해 처리된 활동을 Shadowrocket에 포함할 수 있지만 실제로 지속적인 트래픽을 만드는 것은 전면 동영상, 클라우드 동기화, 사진 업로드 또는 다른 백그라운드 앱일 수 있습니다. 먼저 Data에서 연결에 계속 요청이 있는지 확인한 뒤 트래픽이 많은 앱을 하나씩 일시 중지하세요. 관련 앱을 중지한 후 트래픽과 발열이 빠르게 줄면 프로토콜을 즉시 수정하기보다 트래픽 출처를 확인해야 합니다.

네트워크 신호가 약하면 재전송과 무선 통신 작동 시간이 늘어납니다. 셀룰러 신호가 약하거나 Wi-Fi 가장자리 영역에 있거나 네트워크가 자주 전환되면 기기가 계속 연결을 다시 만들 수 있습니다. 안정적인 Wi-Fi에서 같은 서버와 Config를 사용해 일정 시간 다시 테스트하세요. 안정적인 네트워크에서 정상으로 돌아온다면 배터리 소모가 현재 접속 환경과 관련이 큰 것입니다. 계속 시간 초과되는 서버도 재시도를 유발하므로 먼저 사용 가능하다고 확인된 항목으로 바꾸세요.

On Demand와 빈번한 백그라운드 동작 확인

On Demand 조건이 반복해서 충족되고 해제되면 연결이 자주 설정되고 끊길 수 있습니다. 특정 Wi-Fi를 벗어났을 때, 잠금 해제 후 또는 네트워크를 전환한 뒤 문제가 집중되는지 확인하세요. 문제를 해결하는 동안 On Demand를 일시적으로 끄고 수동 연결을 사용합니다. 배터리 소모와 발열이 줄어들면 조건을 하나씩 다시 활성화하세요. 조건은 명확하고 서로 충돌하지 않아야 하며 같은 네트워크에서 연결과 해제 논리를 동시에 만족하게 만들지 마세요.

Subscribe 자동 업데이트, Connectivity Test와 많은 동시 요청도 짧은 시간 동안 활동을 발생시킵니다. 업데이트 간격을 지나치게 짧게 설정하지 말고 백그라운드에서 모든 서버를 연속 테스트하지도 마세요. Config에 복잡한 스크립트 처리나 많은 규칙이 있다면 단순화한 구성으로 먼저 다시 테스트해 특정 처리 경로와 관련된 문제인지 판단하세요. 단순화 테스트 전에 원래 구성의 사본을 보관하고 확인이 끝난 뒤 항목별로 복원해야 합니다.

업데이트 후 먼저 구성의 완전성 확인

Shadowrocket을 얻고 업데이트하는 유일한 경로는 App Store입니다. 업데이트 후 문제가 발생해도 먼저 모든 데이터를 삭제하지 마세요. 현재 서버가 여전히 선택되어 있는지, Subscribe 항목이 남아 있는지, Config가 원래 사용하던 항목인지, Global Routing이 테스트 상태로 바뀌지 않았는지, On Demand 조건이 현재 네트워크에 맞는지 차례로 확인하세요. 인터페이스 위치는 달라질 수 있지만 현재 앱 안에 표시되는 항목을 기준으로 확인해야 합니다.

그다음 최소 테스트를 진행하세요. On Demand를 끄고 Global Routing을 Direct로 설정해 기본 네트워크를 확인합니다. Proxy로 바꾸고 매개변수가 명확한 서버 하나를 선택한 뒤 마지막으로 Config를 복원하세요. Direct와 Proxy는 정상이고 Config만 비정상이면 구성 호환성과 규칙을 확인합니다. Proxy가 비정상이면 서버 매개변수를 다시 확인하고, 스위치가 켜진 상태를 유지하지 못하면 2장으로 돌아가 시스템 권한과 VPN 구성을 확인하세요. 이 순서를 따르면 업데이트 후 특정 항목의 변화와 전체 데이터 손상을 혼동하지 않을 수 있습니다.

재시동 또는 구성 재설정이 필요한 경우

업데이트 후 시스템 네트워크 확장 상태가 제대로 안정되지 않았다면 앱을 정상적으로 종료하고 기기를 재시동해 일시적인 상태를 지울 수 있습니다. 재시동 후에도 연결을 설정할 수 없다면 시스템 VPN 구성을 다시 만드는 것을 고려하되 서버와 구독을 먼저 삭제하지 마세요. 다시 만든 뒤 가장 단순한 조건으로 테스트하고 성공한 후 On Demand를 복원합니다. 기기가 관리 상태라면 관리 정책이 동시에 변경되지 않았는지도 확인하세요.

배터리 문제가 특정 프로토콜, 특정 서버 또는 특정 네트워크에서만 재현된다면 이 세 조건을 고정해 전후 결과를 비교하세요. 서로 다른 네트워크의 모든 구성에서 계속 문제가 발생한다면 시스템 배터리 통계의 시간대, Data 활동과 재현 절차를 기록한 뒤 App Store의 후속 업데이트 안내를 기다리세요. 이 사이트는 버전 번호나 출시일을 작성하지 않으며 실제 변경 내용은 App Store 페이지를 기준으로 합니다.

9. iPad 전용: 분할 화면, 네트워크 전환 및 구매 항목 복원

iPad의 Shadowrocket은 iPhone과 핵심 개념이 같지만 가로 화면 분할, 멀티태스킹, 키보드 조작, Wi-Fi 사용 비중과 백그라운드 상태 때문에 문제가 다르게 나타날 수 있습니다. 문제를 해결할 때 iPhone의 탭 위치를 그대로 따르지 말고 현재 가로 또는 세로 화면 레이아웃에서 Home, Config, Settings, Data와 서버 상세 정보가 있는 영역을 확인하세요. 시스템 요구 사항과 호환성은 항상 App Store 페이지 표기 기준입니다.

먼저 구매와 앱 식별 정보 확인

같은 Apple ID로 Shadowrocket을 구매했다면 iPad의 App Store 구매 항목에서 찾아 다시 다운로드할 수 있습니다. 스토어에 표시된 상태가 예상과 다르면 현재 로그인 계정, 스토어 지역, 개발자 Shadow Launch Technology Limited와 앱 ID 932747118을 먼저 확인하세요. 자세한 단계는 iPad 다운로드 안내와 구매 항목 복원 안내를 참조하세요.

Shadowrocket은 일회성 구매 클라이언트이지만 클라이언트의 일회성 구매는 회선 요금제가 아닙니다. iPad에서 앱을 다시 다운로드해도 서버 정보가 자동으로 생성되지는 않으며 사용자는 직접 보유한 구독 또는 서버 정보를 계속 사용해야 합니다. iPhone에 기존 구성이 있다면 앱이 지원하는 가져오기 방식을 사용하고 민감한 필드를 확인하세요. 긴 인증 정보와 프로토콜 추가 매개변수는 누락되기 쉬우므로 화면 스크린샷만 보고 다시 입력하지 마세요.

가로 화면 분할에서 ‘찾을 수 없음’ 이해

가로 화면에서는 목록과 상세 정보가 동시에 표시될 수 있으며 선택한 항목의 내용이 다른 열에 나타납니다. Config 또는 서버 목록을 눌렀는데 ‘열리지 않았다’고 생각된다면 오른쪽 상세 정보가 이미 바뀌었는지 확인하세요. 세로 화면에서는 같은 내용이 단계별 진입 방식으로 표시될 수 있으므로 뒤로 가는 경로도 다릅니다. 방향을 전환한 뒤 레이아웃이 즉시 갱신되지 않으면 화면 재배치를 잠시 기다린 다음 앱을 닫았다가 다시 여세요. 이 때문에 구성을 삭제할 필요는 없습니다.

외장 키보드와 트랙패드는 규칙 로직을 바꾸지 않지만 검색창이나 편집 필드에 포커스가 남아 스크롤과 단축 동작이 예상과 다르게 작동할 수 있습니다. 서버 매개변수를 편집한 뒤에는 저장을 완료하고 목록으로 돌아가 현재 항목이 계속 선택되어 있는지 확인하세요. iPad 화면에는 더 많은 필드가 동시에 표시되므로 상세 정보 열의 이전 항목을 현재 항목으로 착각하기 쉽습니다. 테스트 전에 Home으로 돌아가 실제 선택된 서버 이름을 확인하세요.

Split View와 백그라운드 복구 처리

Split View 또는 다른 멀티태스킹 상태에서는 앱 창 크기가 바뀌지만 네트워크 확장은 시스템이 계속 관리합니다. 창을 축소한다고 연결이 바로 끊기지는 않지만 대상 앱이 백그라운드로 이동하거나 네트워크가 Wi-Fi에서 전환되거나 시스템이 리소스를 회수하면 기존 세션을 다시 만들어야 할 수 있습니다. 분할 화면에서 특정 앱이 인터넷에 접속하지 못한다면 먼저 두 앱을 각각 전체 화면으로 테스트한 뒤 분할 화면으로 돌아가세요. 전체 화면은 정상이고 분할 화면만 비정상이면 Shadowrocket 규칙보다 대상 앱의 백그라운드 및 세션 복구를 확인해야 합니다.

iPad를 오랫동안 잠근 뒤 다시 열면 상태 막대에 이전 상태가 먼저 표시되고 네트워크가 복구된 뒤 갱신될 수 있습니다. Wi-Fi 아이콘과 VPN 상태가 안정될 때까지 기다린 뒤 테스트를 시작하세요. On Demand가 활성화되어 있다면 현재 Wi-Fi 조건에 따라 연결을 설정하는지 확인하고, 그렇지 않다면 On Demand를 일시적으로 끄고 수동으로 켜서 조건 판단과 연결 자체를 구분하세요. 보호 케이스를 자주 열고 닫아 잠금 상태가 반복되면 조건 구성이 부적절한 문제가 더 크게 나타날 수도 있습니다.

iPad의 일반적인 Wi-Fi 환경 확인

iPad는 고정된 Wi-Fi에서 장시간 사용하는 경우가 많아 DHCP 주소 변경, 라우터 재시동, 로컬 DNS 캐시와 LAN 기기 접근 문제가 누적되기 쉽습니다. Shadowrocket을 끄고 기본 네트워크를 테스트한 뒤 Direct로 시스템 연결을 확인하고 마지막으로 Proxy로 서버를 확인하세요. 프린터, 파일 장치 또는 라우터 페이지에만 접근할 수 없다면 원격 서버를 바꾸기보다 LAN IP-CIDR 규칙이 DIRECT로 전달되는지 확인하세요.

웹 로그인이 필요한 공용 Wi-Fi에서는 먼저 연결을 끄고 네트워크 자체의 로그인 절차를 완료한 뒤 일반 웹페이지가 작동하는지 확인하고 Shadowrocket을 켜세요. 로그인 페이지가 완료되지 않으면 서버 테스트가 일괄적으로 시간 초과되어 구독 또는 프로토콜 문제로 오해하기 쉽습니다. 한 Wi-Fi에서 같은 이름의 다른 Wi-Fi로 이동하면 On Demand가 이름을 기준으로 처리할 수 있지만 실제 환경은 다를 수 있으므로 주소와 접근 가능성을 함께 재검증하세요.

Config를 옮긴 뒤 단계별 검증

다른 Apple 기기에서 Config를 가져온 뒤 먼저 [General], [Rule], [Host]와 URL Rewrite가 iPad의 현재 네트워크에 맞는지 확인하세요. 고정 LAN 주소, 특정 Wi-Fi에만 해당하는 DNS 또는 원래 네트워크에서만 작동하는 Host 매핑은 iPad에서 다른 결과를 만들 수 있습니다. 모든 추가 처리를 한 번에 활성화하지 말고 먼저 서버, 기본 규칙, 마지막으로 Host와 재작성 항목을 확인하세요.

전체 검증 순서는 여전히 Direct, Proxy, Config입니다. iPad에서 브라우저는 정상인데 분할 화면의 특정 앱만 비정상이라면 해당 앱을 닫았다가 다시 열어 새 연결을 만들도록 하세요. 모든 앱이 비정상이면 Data에 요청과 규칙 일치 기록이 있는지 확인합니다. 연결 스위치가 꺼지면 시스템 권한을 확인하고 특정 도메인만 실패하면 DNS를 확인하세요. iPad 구매 항목 재다운로드와 레이아웃 차이에 대해서는 iPad 재다운로드 및 가로 화면 분할 안내를 계속 읽어보세요.

이 가이드로도 원인을 찾을 수 없다면 재현 가능한 절차를 정리하세요. 기기 유형, 네트워크 유형, Global Routing, 프로토콜 이름, 특정 서버만 영향을 받는지 여부, Connectivity Test 결과, 규칙 일치 내용과 오류 발생 시간을 포함합니다. 자신의 서비스 제공업체에 문의할 때는 비식별화한 정보만 제공하고 전체 구독 주소, 비밀번호 또는 인증 필드를 표시하지 마세요.