Shadowrocket문제 해결 가이드

연결 스위치가 켜지지 않을 때와 VPN 설정 권한

스위치를 켜자마자 다시 꺼진다면 구독을 바꾸기 전에 시스템에서 VPN 설정을 허용했는지 확인하세요. 서버에 연결할 수 없는 문제는 대개 연결이 설정된 뒤 요청을 보내는 단계에서 발생합니다. 시스템 설정이 아직 승인되지 않았다면 서버 정보가 정확해도 정상적으로 트래픽을 전달할 수 없습니다. 먼저 연결을 끄고 기기에서 일반 웹페이지에 접속할 수 있는지 확인하세요. 그런 다음 스위치를 다시 켤 때 시스템 승인, 인증 또는 관리 제한 안내가 표시되는지 살펴보고 전체 메시지를 기록하세요.

최초 승인 및 실수로 거부했을 때의 조치

iPhone 또는 iPad에서 처음 연결을 시작하면 VPN 설정 추가를 요청하는 시스템 메시지가 나타날 수 있습니다. 방금 실행한 Shadowrocket에서 표시된 메시지인지 확인한 뒤 추가를 허용하고 시스템 안내에 따라 기기 인증을 완료하세요. 추가를 허용했다는 것은 시스템이 네트워크 확장 설정을 허용했다는 뜻일 뿐, 구독이 유효하거나 서버가 온라인이라는 의미는 아닙니다. 이전에 거부했다면 앱으로 돌아가 다시 시도하세요. 메시지가 더 이상 나타나지 않으면 시스템 설정의 VPN 관리 항목에서 해당 설정이 있는지 확인하세요.

시스템 설정의 메뉴 구조는 업데이트에 따라 달라질 수 있습니다. 설정 검색으로 VPN을 찾아보세요. 설정 이름과 연결된 앱을 확인해 다른 용도의 설정을 Shadowrocket 설정으로 오인하지 않도록 하세요. 해당 항목이 손상되었거나 중복된 경우 먼저 앱 내 설정을 저장하고 연결을 끈 다음, Shadowrocket에 속한 것이 확실한 문제 항목만 제거하고 앱에서 다시 승인을 요청하세요. 학교, 직장 또는 기기 관리자가 배포한 설정은 함께 삭제하지 마세요. 관리 정책의 적용을 받을 수 있으므로 기기 사용 권한을 먼저 확인해야 합니다.

스위치가 꺼짐, 자동 재연결 및 설정 충돌

승인 후에도 스위치가 바로 꺼진다면 VPN 인터페이스를 사용하는 네트워크 필터링 도구를 포함해 다른 VPN 연결이 네트워크를 제어하고 있는지 확인하세요. 다른 연결을 잠시 중지한 뒤 테스트하고, DNS와 규칙은 동시에 변경하지 마세요. 스위치를 끈 뒤 저절로 다시 켜진다면 먼저 On Demand 및 시스템의 해당 자동 연결 설정을 확인하세요. 연결 트리거와 수동 조작이 겹친 것일 수 있으므로 스위치 변화만으로 앱이 충돌했다고 판단해서는 안 됩니다.

관리 대상 기기는 VPN 추가나 네트워크 확장 설정 변경이 제한될 수 있습니다. 이 경우 앱을 반복해서 재설치해도 정책이 해제되지 않으며 기존 설정을 잃을 수 있습니다. 시스템에 관리 프로파일이 표시되는지 확인한 뒤 제한 안내를 기기 관리자에게 전달하세요. 일반 개인 기기라면 설정을 저장하고 한 번 재시동해 네트워크 확장이 일시적으로 해제되지 않은 상태인지 확인할 수 있습니다. 재시동 후 최소 설정과 기존 서버 하나로 먼저 테스트해 스위치가 유지되는지 확인한 다음 On Demand 등의 자동화 조건을 복구하세요.

권한 문제와 앱 종료 구분하기

앱이 백그라운드로 이동했다고 연결이 중단된 것은 아닙니다. 시스템의 VPN 상태와 실제 요청으로 확인하세요. 반면 특정 설정을 열 때 앱이 종료된다면 해당 설정을 별도로 복사해 보관하고 최근 추가한 규칙, 외부 리소스, 비정상적으로 긴 설정 내용을 살펴보세요. 같은 파일을 연속으로 가져와 복사본을 더 만들지 마세요. 이전에 정상 작동했던 설정을 선택해 다시 테스트할 수 있습니다. 이전 설정은 정상이고 새 설정만 문제가 있다면 설정 간 차이를 확인해야 하며, 계정이나 구독 유효기간부터 확인할 필요는 없습니다.

데스크톱이나 Android에서 처음 실행할 때 차단되면 먼저 다운로드 페이지의 설치 허용 안내에 따라 시스템 확인을 완료한 뒤 연결 문제를 진단하세요. Mac에서는 개인정보 보호 및 보안에서 “그래도 열기”를 확인할 수 있습니다. Windows에서는 설치 파일 출처를 확인한 뒤 SmartScreen의 추가 정보를 살펴보세요. Android에서는 실제 설치를 실행하는 앱에 알 수 없는 앱 설치를 허용해야 합니다. 설치 단계에서 실행되지 않는 문제와 연결 단계에서 인터넷에 접속할 수 없는 문제는 서로 다르므로 각각 기록하세요. 설치 허용 절차를 네트워크 문제 해결로 혼동하지 마세요.

연결되었는데 인터넷에 접속할 수 없을 때: 먼저 라우팅 모드 구분하기

시스템에 VPN 연결됨으로 표시되는 것은 네트워크 확장이 작동 중이라는 뜻일 뿐, 모든 요청이 목적지에 성공적으로 도달한다는 의미는 아닙니다. 모든 웹페이지가 열리지 않는다면 먼저 Shadowrocket을 끄고 같은 네트워크에서 평소 직접 접속되던 페이지를 열어 보세요. 꺼도 접속되지 않으면 Wi-Fi, 셀룰러 데이터, 네트워크 인증 또는 시스템 시간을 먼저 확인하세요. 껐을 때 접속이 복구된다면 선택한 서버, Global Routing, DNS를 차례로 비교하세요. 테스트마다 같은 대상을 사용해 웹사이트 자체의 변경이 섞이지 않게 하세요.

세 가지 모드로 비교하기

Global Routing의 Config는 현재 설정에 따라 트래픽을 처리합니다. Proxy는 해당 요청을 프록시 경로로 보내는 데 사용하고, Direct는 직접 연결과 비교할 때 사용합니다. 문제 해결을 위해 임시로 전환할 수 있지만, 먼저 원래 모드와 선택된 설정을 기록하세요. Proxy는 정상인데 Config가 실패한다면 규칙 매칭, 정책 대상, 설정 리소스를 먼저 확인하세요. Proxy는 실패하고 Direct는 정상이라면 서버 또는 프록시 경로를 우선 점검하세요. 두 모드 모두 실패하면 기본 네트워크, DNS, 대상 서비스부터 다시 확인해야 합니다.

위 결과는 문제를 좁히는 단서이지 확정적인 증거는 아닙니다. 특정 대상은 현재 직접 연결 경로로 접속할 수 없을 수 있으므로 Direct가 실패해도 비교에 의미가 없을 수 있습니다. 앱이 기존 연결을 재사용해 모드를 전환한 직후에도 이전 경로로 요청을 보낼 가능성도 있습니다. 모드를 바꾼 뒤 대상 앱의 기존 페이지를 닫고 새 요청을 보내세요. 필요한 경우 Shadowrocket 연결을 끊었다가 다시 연결하세요. 오랫동안 열어 둔 페이지 하나만 새로고침하고 결론 내리지 말고, VPN 아이콘을 실제 접속 테스트 대신 사용하지 마세요.

규칙 순서와 최종 정책 확인

Config에서 파일 목록에 방금 가져온 이름이 있는지만 보지 말고 실제로 선택된 파일을 확인하세요. 규칙은 보통 순서대로 매칭됩니다. 앞쪽에 범위가 넓은 항목이 있으면 먼저 매칭될 수 있으며, 마지막의 FINAL은 앞에서 매칭되지 않은 요청의 처리 방식을 결정합니다. 아래는 구문 예시이며 현재 설정을 그대로 대체할 수 있는 완성 파일이 아닙니다. 예시 도메인은 설명용입니다. 수정하기 전에 설정에서 PROXY와 DIRECT가 각각 어떤 방식으로 처리되는지 확인하세요.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

특정 웹사이트만 실패한다면 해당 사이트에 적용되는 DOMAIN, DOMAIN-SUFFIX 또는 REJECT 항목이 있는지 확인하고 요청이 실제로 어떤 규칙에 매칭됐는지 살펴보세요. 웹사이트는 로그인, 이미지, API에 서로 다른 도메인을 사용할 수 있으므로 홈페이지가 열린다고 모든 종속 서비스에 올바른 정책이 적용된 것은 아닙니다. 규칙 파일 전체를 삭제하지 말고 실패한 요청의 도메인부터 추적하세요. 매칭된 정책이 존재하지 않는 정책 이름이나 사용할 수 없는 서버를 참조한다면 참조 관계를 수정한 뒤 다시 테스트하세요.

근거가 있을 때만 설정 수정하기

기존 설정을 보관하고 필요한 규칙만 포함한 테스트용 복사본을 만든 뒤 기존 서버 하나로 비교해 보세요. 테스트용 복사본에서 정상 작동한다면 복잡한 규칙, 리소스 참조 또는 추가 설정이 원인일 가능성이 높습니다. 두 설정 모두 실패한다면 서버와 이름 확인을 다시 점검하세요. 설정, 구독, 시스템 네트워크 설정을 한꺼번에 바꾸지 마세요. 문제가 해결되어도 원인을 알 수 없게 됩니다. 세 가지 모드의 사용 범위는 Global Routing의 세 가지 모드 안내를 참고하세요.

문제를 해결한 뒤에는 평소 사용하는 Config로 돌아가 이전에 실패한 페이지, 일반 직접 연결 페이지, 자주 사용하는 앱을 다시 확인하세요. Proxy 임시 테스트가 통과했다고 라우팅 문제가 해결된 것은 아닙니다. 어떤 규칙, 정책 또는 DNS 설정을 변경했는지 기록한 다음 테스트용 임시 항목을 제거하세요. 최소한의 재현 절차를 보관해 두면 같은 문제가 생겼을 때 설정 전체를 다시 추측하지 않고 바로 비교할 수 있습니다.

서버 시간 초과 및 프로토콜 설정 불일치

서버 시간 초과는 주소 확인, 포트 연결, 프로토콜 핸드셰이크, 대상 요청의 네 단계로 나눠 판단해야 합니다. Connectivity Test에서 결과가 돌아오지 않는다고 서버가 완전히 오프라인인 것은 아닙니다. 테스트 대상에 연결할 수 없거나 테스트 방식이 맞지 않거나 프로토콜 핸드셰이크가 실패해도 비슷하게 표시될 수 있습니다. 먼저 단일 서버에서만 실패하는지, 서버 그룹 전체에서 발생하는지, 특정 네트워크에서만 나타나는지 기록하세요. 서버 정보는 이용 중인 서비스 제공업체에서 받은 최신 자료를 기준으로 확인하고 이름만 보고 프로토콜을 추측하지 마세요.

주소와 포트에 도달할 수 있는지 먼저 확인

서버 세부 정보에서 주소에 공백, 줄바꿈, 프로토콜 접두사가 섞이지 않았는지, 포트가 서버 측 설정과 일치하는지 확인하세요. 주소 입력란에는 보통 호스트 이름이나 IP를 입력해야 하며 전체 웹 주소를 그대로 넣지 않습니다. 도메인을 사용한다면 정상적으로 확인되는지 먼저 판단하세요. IP를 사용하더라도 TLS에 사용할 서버 이름을 별도로 입력해야 할 수 있습니다. 특정 Wi-Fi에서만 실패하고 셀룰러 네트워크에서는 정상이라면 해당 네트워크의 로그인 인증, UDP 지원 여부, 외부 연결 제한을 확인하세요. 모든 서버를 바로 초기화하지 마세요.

서버 그룹 전체에서 동시에 시간 초과가 발생한다면 같은 도메인, 같은 구독 또는 같은 네트워크 출구를 사용하는지 확인하세요. 이름이 달라도 실제 기본 주소를 공유할 수 있습니다. 이전에 작동했던 것으로 확인된 항목과 먼저 비교한 뒤 서버 점검 여부와 이용 권한의 유효성을 확인하세요. 테스트를 무한히 반복하지 마세요. 동시에 여러 연결을 탐색하면 네트워크 부하가 늘고 서버 제한이 발생할 수도 있습니다. 이전 테스트가 끝날 때까지 기다리고 대표 사례를 몇 개만 보관하면 패턴을 파악하기 쉽습니다.

핸드셰이크 조건을 항목별로 확인

포트에 도달하지만 실제 요청이 실패한다면 인증, 암호화 방식, 전송 설정을 집중적으로 확인하세요. Shadowsocks의 암호화 방식과 비밀번호는 서버 설정과 일치해야 합니다. VMess와 VLESS의 사용자 ID 및 전송 설정도 서버와 일치해야 하며, Trojan은 비밀번호와 TLS 조건을 확인해야 합니다. 서버 주소가 같다는 이유만으로 예전 항목의 설정을 그대로 사용하지 마세요. 구독 업데이트로 전송 방식이 바뀌었을 수 있지만 수동으로 만든 항목은 자동으로 변경되지 않습니다. 최신 자료와 항목별로 비교하세요.

인증서 오류가 표시되면 먼저 기기의 날짜, 시간, 시간대를 확인한 뒤 서버 이름과 인증서가 일치하는지 살펴보세요. 인증서 검증을 건너뛰는 방법을 일반적인 해결책으로 사용하지 마세요. 연결 상대의 신원을 확인하는 보안이 약해지며 주소 오류나 서버 인증서 만료도 해결되지 않습니다. WebSocket을 사용하는 경우 연결 주소, Host, 경로의 역할을 각각 구분하세요. 일부 항목이 중복처럼 보여도 임의로 삭제해서는 안 됩니다. 포괄적인 시간 초과 결과보다 오류 메시지의 핸드셰이크, 인증, 인증서 관련 내용이 진단에 더 유용합니다.

테스트 결과와 실제 접속을 교차 확인

지연 시간 테스트는 특정 테스트 방식에서의 응답을 보여줄 뿐, 페이지 로딩, 지속적인 다운로드, 동영상 재생이 모두 정상이라는 뜻은 아닙니다. 테스트는 실패하지만 실제 접속이 정상이라면 테스트 대상과 방식을 먼저 확인하세요. 테스트는 정상인데 웹페이지가 실패한다면 DNS, 규칙, 대상 서비스를 계속 점검해야 합니다. 같은 네트워크, 같은 대상, 같은 설정으로 기존 서버 여러 개를 비교해야 변수를 좁힐 수 있습니다. 서버 선택 방법은 지연 시간 테스트, 지역 및 프로토콜 유형 안내를 참고하세요.

서비스 제공업체에 문의할 때는 프로토콜 유형, 실패한 네트워크, 오류가 발생한 시간대, 모든 서버에 영향을 주는지, 민감한 정보를 가린 오류 내용을 전달하세요. 전체 구독 링크, 사용자 ID, 비밀번호, 개인 키는 보내지 마세요. 클라이언트에서 설정 항목의 일치 여부와 문제 범위를 확인할 수 있지만 서버 로그를 대신할 수는 없습니다. 여러 네트워크에서 같은 핸드셰이크 단계에 실패한다면 관련 없는 항목을 계속 바꾸기보다 서버 측에서 인증, 수신 포트, 인증서를 확인해야 합니다.

Subscribe 업데이트 실패, 빈 목록 및 중복 항목

Subscribe 가져오기 실패와 구독에 포함된 서버를 사용할 수 없는 문제는 서로 다릅니다. 전자는 구독 콘텐츠를 다운로드하거나 인증하거나 해석하는 과정에서 발생하고, 후자는 가져온 항목으로 연결할 때 발생합니다. 기존 목록은 보관하고 업데이트 오류 원문을 기록한 다음 구독 주소에 접속할 수 없는지, 응답 상태에 문제가 있는지, 콘텐츠를 해석할 수 없는지 확인하세요. 한 번 업데이트에 실패했다고 아직 사용할 수 있는 기존 항목을 삭제하지 마세요. 삭제 후 다시 추가하면 비교에 필요한 설정 차이까지 사라질 수 있습니다.

링크가 완전한지 및 접근 경로 확인

구독 링크는 이용 중인 서비스 제공업체에서 받아야 하며 복사할 때 모든 쿼리 매개변수를 포함해야 합니다. 채팅 앱의 자동 줄바꿈, 끝에 붙은 문장 부호, 앞뒤 공백, 문자 엔티티를 원래 기호로 착각해 붙여넣는 행동은 링크를 바꿀 수 있습니다. 예시에 나오는 token은 형식 설명용이며 실제 업데이트에 사용할 수 없습니다. 공개 스크린샷, 문의 제목, 브라우저 공유 기록에 실제 링크를 노출하지 마세요. 링크에 개인 서버 목록을 조회할 수 있는 인증 정보가 포함되는 경우가 많습니다.

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

호스트 이름 확인, TLS 또는 시간 초과 관련 오류라면 먼저 연결을 끄고 기본 네트워크가 정상인지 확인한 뒤 기기 시간을 점검하세요. 그런 다음 현재 업데이트 요청이 이미 사용할 수 없게 된 프록시 경로에 의존하는지 살펴보세요. 프록시를 켰을 때만 업데이트에 실패한다면 기존 설정을 기록한 뒤 사용할 수 있는 네트워크 경로를 임시로 이용해 다시 시도할 수 있습니다. 구독 업데이트가 항상 특정 Global Routing 동작을 따른다고 가정하지 마세요. 현재 설정, 요청 기록, 실제 테스트 결과를 기준으로 판단하세요.

인증 실패와 콘텐츠 형식 오류 구분

인증되지 않음, 접근 금지 또는 주소가 존재하지 않는다는 응답이 돌아오면 먼저 서비스 제공업체에서 받은 정보로 링크가 취소, 초기화 또는 만료되었는지 확인하세요. 계속 새로고침해도 만료된 인증은 복구되지 않습니다. 로그인 페이지, 네트워크 인증 페이지, 오류 안내 문구가 반환된 경우 네트워크 요청 자체는 성공했더라도 클라이언트가 가져올 수 있는 서버 데이터는 아닙니다. 공용 Wi-Fi에서 인증을 완료하지 않은 경우 특히 이런 문제가 발생하기 쉽습니다. 연결을 끈 상태에서 네트워크 로그인을 완료한 다음 다시 가져오세요.

요청은 완료됐지만 가져온 항목이 없다면 제공된 형식이 현재 가져오기 방식에 맞는지 확인하세요. Subscribe, 단일 서버 링크, QR 코드, Config 파일은 각각 용도가 다르므로 서로 대체해서는 안 됩니다. 파일 확장자만으로 콘텐츠를 판단하지 말고 웹 안내 페이지 주소를 구독 주소로 사용하지 마세요. 자료에 여러 형식이 있다면 서비스 제공업체가 표시한 Shadowrocket용 항목을 선택하세요. 설명이 없다면 같은 주소를 모든 가져오기 메뉴에서 반복 시도하지 말고 먼저 형식을 문의하세요.

업데이트 후 항목이 사라지거나 중복되고 수동 변경 사항이 사라질 때

업데이트 후 서버 수가 달라졌다면 원격 목록 변경, 필터 조건 변화, 기존 항목 교체 때문일 수 있으며 클라이언트가 잘못 삭제했다고 단정할 수 없습니다. 먼저 Subscribe에 해당하는 그룹을 확인하고 수동 항목과 구독 항목이 같은 화면에 섞여 있는지 살펴보세요. 구독으로 관리되는 항목은 다음 업데이트 때 원격 콘텐츠로 덮어쓸 수 있습니다. 개별 변경 사항을 유지해야 한다면 관리 방식을 먼저 확인하고, 필요하면 이름을 명확하게 지정한 수동 복사본을 만든 뒤 구독 업데이트를 자동으로 따르지 않는다는 점을 기록하세요.

중복 항목은 같은 링크를 여러 번 추가했거나 여러 구독에 동일한 서버가 포함되었거나 수동 복사본과 자동 업데이트 목록이 함께 있을 때 주로 생깁니다. 정리하기 전에 각 그룹의 출처와 업데이트 시간을 확인하세요. 표시 이름만 보고 삭제하지 마세요. 유효한 Subscribe 항목 하나를 남긴 뒤 중복 출처를 하나씩 제거하세요. 새 목록이 이전 설정을 덮어쓴 뒤 연결에 실패한다면 아직 삭제하지 않은 복사본의 주소, 포트, TLS, 전송 항목을 비교하고 명확한 차이를 서비스 제공업체에 문의하세요.

복구한 뒤에는 불필요한 수동 새로고침을 멈추고 실제 필요한 경우에 업데이트하며 마지막으로 정상 작동한 설정 복사본을 보관하세요. 다시 가져오려면 Subscribe 가져오기 단계를 먼저 읽고 같은 메뉴에서 올바른 형식을 사용하세요. QR 코드로 받은 항목은 Scan QR Code 사용 안내를 참고하세요. 인증 링크가 유출된 것 같다면 로컬 표시 이름만 바꾸지 말고 서비스 제공업체에서 인증을 초기화한 뒤 클라이언트 정보를 업데이트하세요.

속도 저하, 웹페이지 지연 및 연결 끊김

속도가 느리다면 먼저 어떤 상황에서 느린지 구체적으로 확인하세요. 처음 열 때 오래 기다리는지, 이미지가 계속 늦게 로드되는지, 대용량 파일 전송 속도가 낮은지, 일정 시간 후 연결이 끊기는지에 따라 DNS, 핸드셰이크, 지속 대역폭, 패킷 손실, 네트워크 전환이 원인일 수 있습니다. 발생 당시 네트워크, 대상, 선택한 서버, 다른 다운로드 진행 여부를 기록하고 Shadowrocket을 끈 상태에서 같은 작업과 비교하세요. 한 번의 지연 시간 수치로 전체 경로의 처리량을 추측하지 말고 대상 웹사이트의 속도 제한을 클라이언트 성능 문제로 오인하지 마세요.

반복 가능한 테스트 조건 만들기

평소 안정적으로 이용하는 대상을 하나 선택해 같은 장소, 같은 네트워크에서 반복 테스트하세요. 대역폭 경합을 프록시 문제로 오인하지 않도록 테스트 중에는 시스템 업데이트, 클라우드 동기화, 기타 대용량 작업을 일시 중지하세요. Wi-Fi 신호 막대 수만으로 전송 품질을 판단할 수 없습니다. 혼잡한 무선 환경, 라우터 부하, 업로드 대역폭 포화도 지연을 일으킬 수 있습니다. 먼저 라우터 가까운 곳과 원래 위치를 비교한 다음 Wi-Fi와 셀룰러 네트워크를 비교하면 로컬 네트워크와 원격 경로의 영향을 구분할 수 있습니다.

기존 서버 여러 개를 비교할 때는 대상, 프로토콜 사용 방식, 테스트 시간을 최대한 동일하게 유지하세요. 서버 이름에 표시된 지역만으로 경로 길이를 알 수는 없으며 지연 시간이 낮아도 혼잡 시간대에 사용할 수 있는 대역폭이 충분하다는 보장은 없습니다. 최초 응답과 지속 전송의 두 단계를 모두 관찰하세요. 최초 응답은 느리지만 이후 안정적이라면 이름 확인과 핸드셰이크를 살펴보세요. 최초 응답은 빠르지만 이후 계속 멈춘다면 패킷 손실, 서버 부하, 대상 제한을 중점적으로 확인하세요. 테스트 결과는 당시 조건에서만 유효하므로 고정 순위를 매기는 데 사용하지 마세요.

라우팅 및 연결 재사용으로 생기는 착시 확인

페이지의 리소스마다 서로 다른 규칙이 적용될 수 있으며 일부 요청이 실패하면 페이지 전체 로딩이 지연될 수 있습니다. 홈페이지 도메인만 테스트하지 말고 멈춘 리소스의 도메인을 확인하세요. Config는 실패하지만 임시 Proxy에서는 정상이라면 규칙과 정책을 점검하세요. 두 모드 모두 느리다면 서버와 기본 네트워크를 비교하세요. 서버를 바꾼 뒤에도 이미 열린 장기 연결은 기존 경로를 계속 사용할 수 있으므로 관련 세션을 닫고 요청을 새로 보내세요. 새 연결의 결과로만 전환이 적용됐는지 판단할 수 있습니다.

통화, 게임 또는 기타 실시간 앱에서 연결이 끊긴다면 UDP가 필요한지, 현재 프로토콜과 네트워크에서 해당 트래픽을 허용하는지 별도로 확인하세요. 웹페이지가 열린다고 UDP도 정상인 것은 아닙니다. UDP를 사용하는 프로토콜도 특정 Wi-Fi에서는 연결되지 않을 수 있습니다. MTU나 전송 설정을 무작위로 바꾸지 말고 문제가 특정 유형의 패킷이나 네트워크에서만 발생하는지 먼저 확인하세요. 조정이 필요하다면 서버 측 권장값을 기준으로 하고 원래 값을 보관한 뒤 하나씩 테스트해 다른 문제까지 생기지 않도록 하세요.

Data와 요청 기록으로 원인 범위 좁히기

Data를 볼 때는 먼저 통계 범위와 시간대, 현재 연결 상태를 확인하세요. 특정 서버의 트래픽이 증가하면 해당 서버가 데이터를 처리했다는 뜻이지만 대상의 모든 콘텐츠가 로드됐다는 의미는 아닙니다. 앱별 통계를 볼 때는 시스템 서비스, 백그라운드 새로고침, 캐시를 고려해야 합니다. 캐시에서 열린 페이지도 실제 속도 테스트에 사용할 수 없습니다. 기준값을 기록한 뒤 명확한 요청을 한 번 보내고 트래픽 증가량이 요청 기록과 일치하는지 확인하세요. 자세한 내용은 Data 페이지 트래픽 통계 안내를 참고하세요.

화면을 끄거나 Wi-Fi에서 벗어나거나 셀룰러 네트워크로 전환한 뒤에만 연결이 끊긴다면 먼저 네트워크 전환 문제로 기록하세요. 다시 연결하자마자 복구된다면 모든 서버를 계속 바꾸지 말고 On Demand 조건과 기존 세션이 만료되었는지 확인하세요. 이동 중에는 네트워크 주소가 자주 바뀌며 일부 장기 연결은 다시 설정해야 합니다. 기존 세션 유지 여부보다 새 요청이 정상적으로 작동하는지가 현재 설정의 유효성을 더 잘 보여줍니다. 정지된 환경에서 다시 테스트해 이동에 따른 영향을 제외할 수 있습니다.

원인 파악을 마치면 테스트용으로 추가한 임시 규칙과 특수 설정을 제거하고 일상 설정으로 복구한 뒤 웹 탐색, 지속 전송, 네트워크 전환을 다시 확인하세요. 서로 겹치는 “최적화” 설정을 여러 개 계속 유지하지 마세요. 추가 설정 자체가 문제 진단을 어렵게 할 수 있습니다. 어떤 변경이 어떤 증상을 해결했는지 명확히 기록해야 다음에도 활용할 수 있는 해결 기록이 됩니다. 한 번의 테스트에서 우연히 빨라진 것만으로는 충분하지 않습니다.

DNS 확인 실패 및 규칙 매칭 이상

DNS 문제는 도메인이 열리지 않거나 첫 접속이 오래 걸리거나 일부 리소스만 실패하거나 같은 웹사이트의 접속 결과가 네트워크마다 다른 증상으로 나타날 수 있습니다. 확인할 점은 이름 확인이 완료됐는지, 반환된 주소에 접속할 수 있는지, 확인 요청이 어떤 경로를 이용했는지입니다. “도메인 접속은 실패하지만 IP를 직접 입력하면 성공”만으로 판단하지 마세요. HTTPS 인증서, 가상 호스트, 웹사이트 라우팅은 도메인에 의존하는 경우가 많습니다. IP로 직접 접속하면 전혀 다른 서비스가 표시될 수 있어 신뢰할 만한 비교가 되지 않습니다.

이름 확인 시간 초과와 확인 후 연결 실패 구분하기

먼저 요청 기록에서 오류가 발생한 단계를 확인하세요. 주소를 받기 전에 시간 초과가 발생한다면 DNS 서버에 도달할 수 있는지와 요청 경로를 확인하세요. 주소를 받은 뒤 연결이 실패한다면 대상 연결, 규칙, IPv6 경로를 점검해야 합니다. 여러 도메인에서 동시에 문제가 생기면 이름 확인 경로를 우선 살펴보세요. 특정 도메인만 실패한다면 해당 도메인의 레코드, 인증서, 서비스 상태도 고려해야 합니다. 홈페이지 도메인과 API 하위 도메인을 혼동하지 않도록 실패한 전체 호스트 이름을 기록하세요.

기기에는 시스템 DNS, Wi-Fi 수동 DNS, 앱 내 설정, 다른 네트워크 필터 설정이 동시에 적용될 수 있습니다. 먼저 각 항목의 기존 값을 기록한 뒤 실제로 어느 설정이 적용되는지 확인하세요. 시스템과 앱에서 여러 주소를 연속으로 바꾸지 마세요. 그러면 테스트 결과를 해석하기 어렵습니다. 암호화 DNS를 사용한다면 해당 호스트 이름 자체를 확인할 수 있고 TLS 연결이 성립하는지도 확인해야 합니다. 한 이름 확인 프로토콜을 다른 프로토콜로 바꿔도 이름 확인 서버까지의 네트워크 문제가 자동으로 해결되지는 않습니다.

DNS와 라우팅이 서로 의존하는지 확인

일부 설정은 프록시를 만들기 전에 서버 도메인을 확인해야 하지만, 아직 연결되지 않은 프록시 경로를 통해 이름 확인 요청을 보내도록 설정되어 있으면 의존성 순환이 생길 수 있습니다. 시작 단계에서 이름 확인이 실패한다면 웹사이트 도메인뿐 아니라 서버 주소의 확인 경로도 살펴보세요. 이전에 정상 작동한 설정과 비교해 어떤 요청이 시스템 DNS를 사용하고 어떤 요청이 설정 내 DNS를 사용하는지 확인하세요. 수정할 때는 먼저 연결을 시작할 수 있는 최소 경로를 복구하고 서버 연결이 성립한 뒤 다른 DNS 조건을 하나씩 되돌리세요.

도메인 기반 규칙과 주소 기반 규칙은 서로 다른 대상을 처리합니다. DOMAIN-SUFFIX는 지정된 도메인과 하위 도메인을 매칭할 수 있습니다. IP-CIDR, IP-CIDR6, GEOIP는 주소를 기준으로 합니다. no-resolve가 있는 주소 규칙을 추가하는 것은 보통 해당 규칙의 매칭을 위해 도메인 확인을 별도로 시작하지 않는다는 뜻이지 클라이언트 전체에서 DNS를 끈다는 뜻은 아닙니다. 아래는 규칙 구조를 보여주는 예시일 뿐입니다. 문서용 예약 주소와 example.com은 설명을 위한 자료이며 실제 로컬 네트워크 범위나 서비스 요구사항을 나타내지 않습니다.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
FINAL,PROXY

IPv6, 캐시, 로컬 네트워크 범위

도메인이 IPv4와 IPv6 주소를 함께 반환하면 두 경로의 연결 가능 여부가 다를 수 있습니다. 특정 네트워크에서만 오래 기다린다면 사용할 수 없는 주소 경로를 우선 시도하는지 확인하세요. 기존 설정을 보관한 뒤 관련 IPv6 옵션을 임시로 조정해 비교할 수 있지만 IPv6를 영구적으로 끄는 것이 일반적인 해결책이라고 단정하지 마세요. 새 요청이 정상화되는지 확인하고 다른 네트워크에서도 다시 테스트하세요. 그렇지 않으면 특정 네트워크에서만 임시로 우회해 설정과 실제 네트워크 기능이 맞지 않는 문제를 가릴 수 있습니다.

DNS를 바꾼 뒤에도 이전 캐시와 이미 설정된 연결이 계속 사용될 수 있습니다. 연결을 끊었다가 다시 연결하고 대상에 새 요청을 보내세요. 필요한 경우 대상 앱을 재시작하세요. 캐시를 지우려고 Shadowrocket을 반복해서 재설치하지 마세요. 로컬 기기 이름, 프린터 검색, 직장 내부 도메인은 로컬 이름 확인에 의존할 수 있으므로 모두 원격에서 확인하도록 하면 오히려 실패할 수 있습니다. 실제로 필요한 로컬 이름과 네트워크에 올바른 경로를 유지하고 신뢰할 수 있는 네트워크에서만 내부 주소를 테스트하세요. 민감한 이름을 공개 문의에 포함하지 마세요.

최종 확인에는 일반 도메인, 이전에 실패한 도메인, 필요한 로컬 서비스를 모두 포함해야 합니다. 규칙 매칭과 이름 확인 결과가 예상대로인지 확인한 뒤 임시 비교 설정을 제거하세요. “특정 네트워크에서만 이름 확인 시간 초과, 다른 네트워크에서는 정상”이라는 차이를 안정적으로 재현할 수 있다면 해당 네트워크 또는 서버 관리자에게 전달하세요. 웹페이지 오류 스크린샷 하나만으로는 문제가 이름 확인, 핸드셰이크, 대상 응답 중 어디에서 발생했는지 알기 어렵습니다.

비정상적인 배터리 소모, 발열 및 백그라운드 반복 연결

배터리 소모를 판단할 때는 시스템 배터리 목록의 백분율만 보지 말고 사용 상황과 관찰 시간을 함께 확인하세요. VPN 관련 처리에는 네트워크 확장을 이용하는 다른 앱의 작업량도 포함될 수 있습니다. 특정 항목의 비율이 높아져도 같은 시간대에 다른 앱의 배터리 사용량이 줄었기 때문일 수 있습니다. 데이터가 계속 전송되고 있었는지, 신호가 약한 곳이었는지, 기기를 충전 중이었는지, 어느 설정을 변경한 뒤 문제가 시작됐는지 기록하세요. 시스템 업데이트, 데이터 복원, 클라우드 동기화 직후의 짧은 발열을 바로 프록시 문제로 판단하지 마세요.

정상적인 지속 작업과 비정상적인 재시도 구분

네트워크가 안정되고 기기 온도가 정상인 상태에서 연결을 켜고 적게 사용하는 경우, 계속 다운로드하는 경우, 연결을 끈 경우를 비슷한 시간대에 각각 관찰하세요. 화면 밝기, 앞에 표시된 앱, 네트워크를 최대한 동일하게 맞춰야 의미 있는 비교가 됩니다. 데이터 전송량이 많을 때만 배터리 소모가 증가한다면 무선 통신과 암호화 처리의 영향일 수 있습니다. 거의 아무것도 하지 않는데 계속 발열한다면 프로토콜 설정을 먼저 바꾸지 말고 백그라운드 앱, 연결 재시도, 로그 기록, 자동 업데이트 작업을 확인하세요.

요청 기록에서 같은 실패가 촘촘하게 반복되는지 확인하세요. 같은 호스트가 계속 시간 초과되거나 구독을 반복해서 새로고침하거나 서버 인증이 거듭 실패하면 기기가 연결을 계속 만들 수 있습니다. 가장 먼저 발생한 오류부터 해결하세요. 뒤따르는 재시도도 줄어들 수 있습니다. 모든 시간 초과 값을 낮추는 방식으로 배터리를 절약하려 하지 마세요. 대기 시간을 너무 짧게 설정하면 재연결이 더 늘어날 수 있습니다. Connectivity Test를 전체 서버에 자주 실행하지 마세요. 광범위한 탐색 자체가 네트워크 활동을 늘려 배터리 관찰에 영향을 줍니다.

On Demand 및 네트워크 전환 확인

On Demand는 실제 사용 환경에 맞게 설정해야 합니다. Wi-Fi 신호가 약한 경계 지점, 셀룰러 네트워크 전환, 잘못 설정된 네트워크 이름 조건은 연결이 계속 시작되고 중지되는 원인이 될 수 있습니다. 먼저 트리거 조건을 기록한 뒤 자동 연결을 잠시 끄고 수동 연결 상태를 일정 시간 유지해 비교하세요. 배터리 소모와 잦은 재연결이 함께 줄어든다면 조건을 하나씩 복구해 반복 연결을 일으키는 항목을 찾으세요. 앱 화면만 닫았다고 백그라운드 연결이 중단된 것은 아닙니다. 시스템의 VPN 상태를 확인하세요.

두 Wi-Fi 사이를 자주 이동하거나 기기가 잠자기 상태에서 깨어난 뒤 네트워크에 다시 연결하면 기존 세션이 무효화되어 새로 설정될 수 있습니다. 이런 경우 매번 새 연결을 비정상으로 판단하지 말고 재연결 후 빠르게 안정되는지 먼저 확인하세요. 계속 실패하거나 짧은 시간 안에 반복적으로 전환되거나 데이터 이용이 없는데도 기기가 오랫동안 작동하는 경우에는 점검이 필요합니다. 한 장소와 한 네트워크에서 다시 테스트하세요. 고정된 환경에서는 정상이고 이동 중에만 문제가 생긴다면 무선 신호 범위, 네트워크 전환, 자동 연결 조건을 우선 확인하세요.

진단 중 불필요한 부하 줄이기

문제 해결을 위해 켠 상세 로그, 장시간 트래픽 기록, 다수의 테스트는 필요한 정보를 확보한 뒤 평소 설정으로 되돌리세요. 문제를 재현할 수 있는 기록을 소량 보관하면 충분하며 모든 요청을 계속 쌓아 둘 필요는 없습니다. 설정에 예약 업데이트나 주기 작업이 있다면 실행 주기와 실패 후 재시도 횟수를 하나씩 확인하고 불필요한 항목을 먼저 중지해 비교하세요. 한 번에 작업 하나만 바꾸고 비슷한 상황에서 온도와 배터리 변화를 관찰하세요. 모든 기능을 동시에 중지하면 원인을 찾기 어렵습니다.

프로토콜, 전송 방식, 네트워크 품질에 따라 처리 비용이 달라질 수 있지만 서버 조건을 고려하지 않고 임의로 전환해서는 안 됩니다. 먼저 현재 설정이 유효하고 연결이 안정적인지 확인한 뒤 사용할 수 있는 서버 여러 개를 비교하세요. 신호가 약한 상태에서의 반복 전송, 패킷 손실 후 재전송, 작은 요청이 많은 상황은 프로토콜 이름보다 더 큰 영향을 줄 수 있습니다. 맥락 없이 정해진 배터리 소모량을 목표로 삼지 마세요. 기기 배터리 상태, 화면 사용량, 주변 온도가 결과에 영향을 주므로 같은 기기에서 변경 전후를 비교하는 것이 좋습니다.

Shadowrocket을 꺼도 같은 상황에서 문제가 지속된다면 구독을 반복해서 가져오지 말고 시스템 배터리 기록, 백그라운드 동기화, 네트워크 신호를 확인하세요. 특정 설정에서만 문제가 생긴다면 원본 파일을 보관하고 최소 테스트 설정으로 재현해 자동 작업, 연결 트리거, 실패 후 재시도를 비교하세요. 해결한 뒤에는 유휴 상태와 일반 사용 상황을 각각 한 번 이상 확인해 계속 재연결되지 않는지 살펴보세요. 시스템 배터리 통계에는 집계 시간이 적용되므로 변경 직후 바로 결과가 완전히 반영되지는 않습니다.

배터리 문제를 문의할 때는 기기 종류, 시스템 환경, 사용 네트워크, 연결 유지 시간, 주요 작업을 적고 민감한 정보를 가린 실패 기록을 첨부하세요. 배터리 사용 비율 스크린샷만 보내면 트래픽 양과 관찰 시간이 없어 판단하기 어렵습니다. Data의 트래픽 증가량도 함께 기록하면 문의를 받는 사람이 “데이터를 많이 전송함”과 “트래픽은 적지만 계속 재시도함”을 구분해 서로 다른 점검 방향을 선택할 수 있습니다.

업데이트 후 문제 및 iPad 전용 점검

업데이트 후 문제가 발생하면 발생 시점이 가깝다는 이유만으로 원인이라고 단정하지 말고 클라이언트, 시스템, 설정, 구독 중 무엇이 바뀌었는지 먼저 확인하세요. 마지막으로 정상 사용했을 때의 네트워크와 설정을 기록한 뒤 현재 환경에서 재현하세요. 클라이언트 업데이트로 이미 만료된 서버 인증이 복구되지는 않습니다. 반대로 구독 업데이트와 동시에 설정이 바뀌어 앱 업데이트가 원인인 것처럼 보일 수도 있습니다. 초기화나 재설치를 고려하기 전에 현재 파일, 그룹, 필요한 스크린샷을 보관해 차이를 확인할 수 있는 자료를 잃지 않도록 하세요.

모든 설정을 초기화하지 말고 문제 발생 경로에 따라 복구

iPhone 및 iPad 앱은 App Store에서 구매하고 업데이트하세요. 시스템 요구 사항은 App Store 페이지에 표시된 내용을 기준으로 확인하세요. iPhone 및 iPad 버전은 App Store에서 $2.99 일회성 결제이며, Mac(Apple 실리콘 및 Intel), Windows, Android, Linux 버전은 무료입니다. 기타 플랫폼의 설치 파일은 이 사이트의 다운로드 페이지에서 제공하며 이 사이트의 /dl/ 경로를 통해 받습니다. 클라이언트 일회성 구매 ≠ 회선 요금제입니다. 클라이언트를 다시 설치해도 서비스 제공업체에서 취소한 구독 권한은 자동으로 복구되지 않습니다.

iPhone 및 iPad 앱을 확인할 때는 개발자가 Shadow Launch Technology Limited인지, 공식 아이콘과 앱 ID 932747118이 맞는지 확인하세요. 기기를 바꾸거나 재설치한 뒤에는 원래 구매 계정으로 구입 항목을 찾으세요. 자세한 절차는 구매 항목 복원 안내를 참고하세요. 앱을 복원한 뒤에도 구독, 서버, Config가 모두 있는지 확인해야 합니다. 시스템 백업만으로 현재 설정이 전부 복원됐다고 볼 수 없으며 비밀번호, 개인 키, 인증 정보도 하나의 기기에만 보관하지 않는 것이 좋습니다.

업데이트 후에는 최소한 세 가지를 먼저 확인하세요. 시스템 기본 네트워크가 정상인지, VPN 설정 권한이 유지되는지, 기존 서버 하나가 단순화한 설정에서 작동하는지 확인합니다. 기존 설정은 실패하지만 단순화한 설정은 정상이라면 규칙과 외부 리소스를 하나씩 복구하세요. 모든 설정에서 실패한다면 권한, DNS, 서버 설정을 다시 확인하세요. 원래 단서를 덮어쓸 수 있으므로 모든 설정을 무차별적으로 다시 저장하지 마세요. 앱이 종료된다면 “업데이트 후 작동하지 않음”이라고만 적지 말고 종료를 유발한 동작을 기록하세요.

iPad의 Wi-Fi, 핫스팟 및 멀티태스킹 환경

Wi-Fi 전용 iPad에서는 라우터 문제와 프록시 문제를 먼저 구분하세요. 사용할 수 있는 다른 네트워크나 개인용 핫스팟으로 비교할 수 있습니다. 셀룰러 기능이 있는 모델이라면 Wi-Fi와 셀룰러 네트워크를 각각 테스트하세요. 학교, 직장, 공용 Wi-Fi는 웹페이지 인증이 필요할 수 있습니다. 먼저 연결을 끄고 인증을 완료한 뒤 Shadowrocket을 켜세요. iPhone에서는 정상인데 iPad에서만 실패한다고 구독 문제로 단정해서는 안 됩니다. 두 기기가 서로 다른 DNS, Config, 시스템 VPN 설정을 사용할 수 있습니다.

분할 화면이나 여러 창을 함께 사용하면 “현재 보고 있는 설정”과 “실제로 적용 중인 설정”을 혼동하기 쉽습니다. Shadowrocket으로 돌아가 선택된 서버, Global Routing, Config를 확인한 뒤 대상 앱에서 새 요청을 보내세요. 두 기기의 표시 이름이 같다는 이유만으로 비교하지 마세요. 이름이 같은 항목도 포트, TLS, 전송 설정이 다를 수 있습니다. 기기 설정을 모두 지우고 다시 시도하는 것보다 실제 설정 항목을 하나씩 비교하는 편이 문제를 찾기 쉽고 정상 작동 중인 앱의 네트워크 상태도 유지할 수 있습니다.

외장 키보드로 구독이나 서버 정보를 붙여넣을 때 앞뒤 공백, 스마트 문장 부호, 줄바꿈을 확인하세요. 기기 간 클립보드를 사용했다면 최신 내용을 복사했는지도 확인해야 합니다. Scan QR Code로 가져온 뒤에는 해석된 항목의 유형을 살펴보세요. QR 코드 인식에 성공했다고 설정 항목 확인을 생략하지 마세요. iPad 화면을 껐다 켠 뒤에도 이전 페이지가 그대로 보인다면 연결이 끊겼다고 판단하기 전에 새 요청을 보내세요. 이전 페이지와 장기 연결은 복귀 후의 실제 네트워크 상태를 나타내지 않을 수 있습니다.

일상 설정 복원 및 문제 기록 마무리

재설치가 필요하다면 복원할 수 있는 Config와 서버 정보를 먼저 저장하고 서비스 제공업체에서 구독 링크를 다시 받을 수 있는지 확인하세요. 내보낸 파일에 민감한 설정이 포함될 수 있으므로 접근이 통제된 곳에 보관하고 공개 파일 공유로 전송하지 마세요. 컴퓨터와 Android에서 앱을 다시 받은 뒤 시스템 차단 메시지가 나타나면 다운로드 페이지의 설치 허용 안내를 따르세요. Mac의 “그래도 열기”, Windows의 “추가 정보”, Android의 설치 권한은 앱을 실행하는 문제만 해결합니다. 이후 연결과 규칙을 다시 확인해야 합니다.

문제 해결을 마치면 일상적으로 사용할 Global Routing, On Demand, 필요한 규칙을 복원하고 임시 DNS 설정과 테스트 항목을 제거하세요. 확인할 항목에는 원래 실패했던 작업, 일반 네트워크 요청 하나, 화면을 끄거나 네트워크를 전환한 뒤의 새 요청이 포함되어야 합니다. 마지막으로 문제 범위, 원인, 실제 변경 사항, 재테스트 결과를 기록하세요. 해결되지 않았다면 기기 모델만 설명하지 말고 재현 가능한 정보를 정리해 문의하세요. 처음 설정하는 과정에서 빠뜨린 단계가 있는지 빠른 시작 가이드에서 다시 확인할 수 있습니다.