Shadowrocket
문제 해결 가이드

스위치가 켜지자마자 꺼지는 경우와 켜진 상태로 요청이 실패하는 경우를 구분하세요. 전자는 VPN 설정과 시스템 관리 제한을 먼저 확인하고, 후자는 다음 장으로 이동하세요. 앱을 반복해서 삭제할 필요는 없습니다.

반복해서 확인할 수 있는 기준점 만들기

Shadowrocket 연결 스위치를 끄고 네트워크를 제어하는 다른 VPN 설정은 잠시 중지한 뒤, 브라우저에서 평소 직접 접속할 수 있던 웹페이지를 엽니다. 공용 Wi-Fi는 인터넷을 사용하기 전에 로그인 인증이 필요할 수 있습니다. Wi-Fi 아이콘이 표시된다고 해서 인터넷에 연결된 것은 아닙니다. 기본 네트워크에서 접속할 수 없다면 먼저 인증을 완료하거나 네트워크에 다시 연결하고, 필요하면 네트워크 관리자에게 문의하세요. 이 단계에서 서버를 바꾸거나 규칙을 수정해도 근본적인 연결 문제는 해결되지 않습니다. Wi-Fi와 셀룰러 중 어떤 네트워크를 사용하는지, 문제가 생기기 전에 네트워크를 바꾸거나 설정을 복원 또는 변경했는지 기록하세요.

최소한의 점검 기록을 준비하세요. 기기 종류, 네트워크 종류, 스위치가 켜진 상태를 유지하는지, 오류가 발생한 구체적인 동작, 표시된 오류 문구를 적습니다. 단순히 “작동하지 않음”이라고만 기록하지 마세요. 가져오기, 연결, 웹페이지 오류는 각각 점검 경로가 다릅니다. 테스트 중에는 이미 보유한 서버 하나와 대상 웹페이지 하나를 정해 사용하고 불필요한 다운로드는 중지하세요. 서버, 설정, 네트워크를 한꺼번에 바꾸면 문제가 해결되어도 원인을 알 수 없어 다음에 같은 문제가 생겼을 때 처음부터 다시 확인해야 합니다.

VPN 설정 권한 다시 확인

iPhone 또는 iPad에서 처음 연결을 켜면 시스템이 VPN 설정 추가를 요청합니다. 기기 사용자가 안내를 읽고 권한을 승인해야 합니다. 이전에 취소했다면 Shadowrocket으로 돌아와 다시 켜고 시스템 대화상자가 나타나는지 확인하세요. 그런 다음 시스템 Settings에서 VPN 설정을 찾아 해당 항목이 목록에 있는지 확인합니다. 설정 경로는 시스템 버전에 따라 다를 수 있으므로 설정 검색을 이용하세요. 오래된 가이드에 나온 메뉴 이름만 보고 설정이 없다고 판단하지 마세요. 회사나 학교에서 관리하는 기기는 구성 프로파일이 VPN 추가를 제한할 수 있으므로 관리자에게 권한을 확인해야 합니다. 반복해서 재설치해 관리 정책을 우회하려고 하지 마세요.

권한을 승인한 뒤에도 스위치가 바로 꺼지면 기기를 재시동하고 다시 확인하세요. 이전 VPN 항목이 Shadowrocket에 속하며 앱 내 자료를 백업했다는 점을 확인한 경우에만 시스템 설정에서 해당 항목을 제거한 뒤 앱이 다시 생성하도록 할 수 있습니다. 시스템 VPN 설정과 앱의 서버, Subscribe, Config는 서로 다른 계층의 항목입니다. 하나를 삭제해도 다른 자료가 백업되는 것은 아닙니다. 프로파일을 한꺼번에 모두 제거하거나 용도를 알 수 없는 인증서와 기기 관리 항목을 삭제하지 마세요.

자동 연결과 연결 충돌 확인

On Demand가 네트워크 조건에 따라 자동으로 연결하거나 연결을 끊고 있는지 확인하세요. 자동 정책의 영향을 배제하려면 기존 조건을 기록한 뒤 자동 연결을 잠시 중지하고 수동 스위치만으로 테스트합니다. 수동 연결이 정상이라면 조건을 하나씩 다시 적용하면서 특정 Wi-Fi 이름이나 네트워크 전환 시에만 문제가 생기는지 확인하세요. 시스템에 VPN 항목이 여러 개 저장되어 있을 수 있으므로 실제로 어떤 항목이 활성화되어 있는지 확인해야 합니다. 상태 막대의 연결 아이콘만으로 Shadowrocket이 요청을 정상적으로 처리한다고 판단하지 마세요.

앱이 열리지 않거나 실행 직후 종료된다면 먼저 내보낼 수 있는 설정을 저장하고 기기의 여유 공간을 확인한 다음 앱 다운로드 페이지에서 설치 경로를 확인하세요. iPhone / iPad 버전은 App Store에서 받으며, 시스템 요구 사항은 App Store 페이지에 표시된 내용을 기준으로 합니다. Mac, Windows, Android, Linux의 설치 방법과 시스템에서 실행을 허용하는 절차도 다운로드 페이지에서 확인할 수 있습니다. 연결 문제를 점검하는 중에 출처를 알 수 없는 설치 파일로 바꾸지 마세요. 앱이 안정적으로 열리고 스위치가 켜진 상태를 유지하면 네트워크 점검으로 넘어갑니다.

먼저 Direct와 Proxy의 결과를 비교한 다음 Config에서만 실패하는지 확인하세요. 연결 아이콘은 시스템에 VPN 세션이 있다는 뜻일 뿐 모든 대상 요청이 완료된다는 뜻은 아닙니다.

세 가지 모드로 문제 범위 좁히기

현재 Config를 복사해 보관하고, 사용자가 이미 보유했으며 설정을 확인할 수 있는 서버 하나를 선택하세요. Global Routing에서 Config, Proxy, Direct를 차례로 테스트하고 모드를 바꿀 때마다 같은 웹페이지를 다시 요청합니다. Direct는 선택한 프록시 서버를 거치지 않는 경로의 접속 결과를 확인하고, Proxy는 해당 서버가 요청을 처리하는지 확인하며, Config는 규칙 판단을 경로에 포함합니다. 이 비교는 진단을 위한 방법이지 특정 모드를 계속 사용하라는 뜻이 아닙니다. 테스트를 마치면 실제 사용 목적에 맞는 설정으로 되돌리세요.

Direct는 정상인데 Proxy가 실패한다면 서버 상태, 프로토콜 설정, 원격 연결 기능을 먼저 확인하세요. Proxy는 정상인데 Config가 실패한다면 설정 활성화 여부, 규칙 순서, 정책 대상을 확인하세요. 세 모드 모두 실패한다면 대상 웹페이지 자체가 작동하는지 먼저 확인한 뒤 기본 네트워크와 DNS를 점검합니다. 일부 앱은 기존 연결을 재사용하므로 모드를 바꾼 뒤 기존 페이지를 닫고 다시 여세요. 필요하면 해당 앱의 현재 세션을 종료하고 테스트해 이전 연결이 현재 모드와 다른 결과를 내는 일을 방지하세요.

설정 목록이 아니라 현재 사용 중인 설정 확인

Config에서 실제로 활성화된 설정을 확인하세요. 목록에 파일이 있다고 해서 해당 파일이 사용 중인 것은 아닙니다. 구독에서 서버를 가져왔다고 해서 원하는 규칙 설정으로 전환된 것도 아닙니다. 현재 파일을 열고 Rule 항목을 위에서 아래 순서로 확인하세요. 일반적으로 먼저 일치하는 규칙이 요청 경로를 결정하므로, 범위가 넓은 규칙이 앞에 있으면 뒤의 세부 규칙이 적용되지 않을 수 있습니다. 수정 전에 파일을 복사하고 원본과 테스트용 파일을 구분할 수 있는 이름을 사용하세요.

아래 예시는 일치 순서를 이해하기 위한 것입니다. 지정한 도메인은 PROXY로 보내고, 로컬 네트워크 주소는 DIRECT로 처리하며, 나머지 요청은 FINAL로 처리합니다. PROXY가 가리키는 실제 서버나 정책은 현재 환경에서 작동해야 합니다. 이 예시만으로 서버가 만들어지는 것은 아닙니다. GEOIP 판단에는 주소와 관련 데이터가 필요하므로 모든 네트워크에서 도메인이 같은 결과를 얻는다고 단정할 수 없습니다. 필수 로컬 규칙이 포함된 전체 설정을 예시로 덮어쓰지 마세요.

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

일부 웹페이지에서만 실패하면 규칙 적용 기록 확인

대부분의 웹페이지는 정상인데 특정 도메인이나 앱에서만 실패한다면 해당 요청에 실제로 적용된 규칙, 최종 정책, 오류 정보를 확인하세요. 한 페이지가 기본 도메인, 이미지 도메인, API 도메인을 함께 요청할 수 있습니다. 페이지의 글은 표시되지만 이미지가 계속 로딩된다면 이를 “연결이 완전히 끊김”으로 단정하기 어렵습니다. 먼저 어떤 도메인에서 실패했는지 확인한 뒤 개별 규칙을 조정할지 판단하세요. REJECT가 적용되면 규칙의 의도를 확인하고 모든 차단 규칙을 바로 삭제하지 마세요. 원래 설정은 특정 유형의 요청을 차단하기 위한 것일 수 있습니다.

로컬 네트워크 기기, 프린터, 내부 웹페이지는 대상 주소가 현재 네트워크에 속하는지 먼저 확인하고 원격 프록시로 전송되는지도 점검하세요. Wi-Fi의 기기 간 통신 차단 기능이 접속을 막을 수도 있으며, 이 제한은 DIRECT 규칙 하나를 추가한다고 반드시 해결되지 않습니다. 특정 앱만 네트워크 오류를 표시한다면 시스템 네트워크 권한과 앱 자체 서비스 상태도 확인해야 합니다. 복구 후 같은 대상으로 Config를 다시 테스트하고 진단 목적으로 추가한 임시 규칙은 제거하세요. 최종적으로 필요한 최소한의 변경만 남깁니다.

시간 초과는 테스트가 정해진 시간 안에 완료되지 않았다는 뜻입니다. 주소 조회, 전송 연결, 프로토콜 핸드셰이크, 원격 요청 단계 중 어디서 발생했는지 확인하려면 테스트 종류와 실제 오류 문구를 먼저 살펴보세요.

서버 하나만 실패하는지 전체 서버가 실패하는지 확인

Home에서 이미 등록된 서버에 Connectivity Test를 실행하고 실패한 항목을 기록한 다음, 그중 하나로 실제 웹페이지에 접속해 보세요. 테스트 방법마다 확인하는 단계가 다릅니다. 포트 연결에 성공해도 인증 정보가 올바르다는 뜻은 아니며, 웹페이지 테스트 한 번에 성공해도 모든 요청이 정상이라는 뜻은 아닙니다. 서버 하나만 실패하면 해당 서버 설정과 원격 상태를 먼저 확인하세요. 모든 서버가 동시에 실패하면 현재 네트워크, 도메인 조회, 기기 시간, 공통 전송 설정을 확인하고 서버를 하나씩 모두 다시 만들지는 마세요.

가능하다면 같은 기기에서 정상 작동이 확인된 다른 네트워크로 전환하고 서버와 테스트 대상을 그대로 유지하세요. 네트워크를 바꾸자 결과가 달라진다면 로컬 네트워크와 서버 사이의 경로나 해당 네트워크의 전송 방식 처리에서 문제가 생겼을 가능성이 큽니다. 한 번 전환에 성공했다고 설정 전체가 올바르다고 판단하지 마세요. 기존 네트워크의 인증 필요 여부, 라우터 필터링 여부, 네트워크 사용량이 많은 시간에만 실패하는지 기록하세요. 우연한 성공보다 반복해서 확인되는 차이가 진단에 더 유용합니다.

기존 설정의 항목별 값 대조

Add Server에 해당하는 편집 화면을 열고 사용자가 이미 보유한 서버 정보를 기준으로 프로토콜 유형, 주소, 포트, 인증 정보를 하나씩 확인하세요. 서버 주소에는 호스트 이름이나 주소 필드가 요구하는 값을 입력하고 웹 링크의 경로를 함께 붙여 넣지 마세요. 포트는 서버에서 실제로 대기 중인 포트와 일치해야 합니다. 비밀번호, UUID, 키 등 인증 항목은 프로토콜마다 용도가 다르며 서로 바꿔 쓸 수 없습니다. 복사한 값의 앞뒤 공백, 줄바꿈, 전각 문장 부호를 확인하세요. 채팅이나 문서에서 복사할 때는 모양이 비슷한 문자 하나만 달라도 핸드셰이크가 실패할 수 있습니다.

VMess, VLESS, Trojan 등의 설정은 실제 서버 요구 사항에 따라 TLS, 전송 방식, 관련 항목을 확인해야 합니다. 모든 설정에 같은 옵션이 필요한 것은 아닙니다. WebSocket을 사용하는 경우 경로와 Host가 서버 설정과 일치해야 하며 경로의 대소문자와 앞쪽 슬래시도 그대로 유지해야 합니다. Hysteria2 또는 WireGuard를 사용할 때는 현재 네트워크가 UDP를 어떻게 처리하는지도 확인하세요. TCP 테스트 결과만으로 UDP 데이터 전송도 원활하다고 판단할 수 없습니다. 필요한 항목을 모를 때는 기존 설정 제공자에게 확인하고 다른 서버의 설정을 추측해 입력하지 마세요.

시스템 시간과 핸드셰이크 조건 확인

시스템 날짜와 시간대가 잘못되면 인증서 유효 기간 확인이나 시간 기반 인증 절차에 문제가 생길 수 있습니다. 시스템에서 날짜와 시간 자동 설정을 켜고 표시가 정확한지 확인한 뒤 다시 연결하세요. 인증서 이름 불일치나 만료 오류가 발생하면 검증을 끄지 말고 서버 이름, SNI, 원격 인증서를 확인하세요. 주소 연결은 되지만 핸드셰이크가 계속 실패한다면 단순 시간 초과보다 더 많은 단서를 제공할 수 있습니다. 오류에 인증서, 인증, 전송 응답 중 어떤 내용이 표시되는지 그대로 기록하세요.

로컬 설정을 모두 확인했는데도 한 서버가 여러 정상 네트워크에서 계속 실패한다면 프로토콜 유형, 실패 단계, 테스트 시간대, 민감 정보를 제거한 오류 내용을 기존 서비스 제공자에게 전달해 대기 포트, 인증, 서비스 상태를 확인해 달라고 요청할 수 있습니다. 비밀번호, UUID, 전체 구독 주소, 설정 QR 코드를 공개하지 마세요. 자세한 점검 순서는 서버 시간 초과·프로토콜 설정·시스템 시간 점검에서 확인할 수 있습니다. 변경이 효과가 있는지 확인한 다음 저장해 실패한 시도를 설정에 계속 남기지 마세요.

구독 업데이트는 주소 요청, 콘텐츠 수신, 형식 인식, 목록 갱신 단계로 진행됩니다. 업데이트 성공이 서버 사용 가능을 뜻하지는 않으며, 서버 연결 실패가 구독 주소가 만료됐다는 뜻도 아닙니다.

주소 전체와 접근 권한 확인

사용자가 이미 이용 중인 서비스 제공자의 관리 페이지에서 구독 주소를 다시 복사하고, 쿼리 매개변수가 빠졌거나 채팅 앱에서 잘렸거나 앞뒤에 공백이 들어가지 않았는지 확인하세요. 주소에 포함된 토큰은 보통 접근 자격 정보와 같으므로 공개 스크린샷, 문의 제목, 웹페이지 댓글에 노출하지 마세요. 구독 주소를 재설정했다면 이전 주소는 더 이상 유효하지 않을 수 있습니다. 이전 항목을 반복해서 업데이트하지 말고 본인 계정에서 현재 제공하는 주소로 바꾸세요. 앱에 붙여 넣은 뒤 입력 내용을 확인하고 개인 토큰이 들어 있는 주소를 온라인 변환·검사 사이트에 보내지 마세요.

요청에 인증되지 않음 또는 접근 금지 응답이 나타나면 계정 로그인 상태, 접근 권한, 구독 주소 재생성 여부를 확인하세요. 리소스를 찾을 수 없다는 안내가 나오면 경로가 완전한지 확인합니다. 응답 상태는 점검 방향을 알려 줄 뿐이며 정확한 의미는 사용자가 이미 이용 중인 서비스 제공자의 안내를 따르세요. 임시 리디렉션 주소라면 복사한 내용이 구독 데이터가 아니라 로그인 페이지일 수 있습니다. 브라우저에서 페이지가 열린다는 이유만으로 Subscribe가 해당 주소를 인식한다고 단정하지 마세요. 브라우저 세션과 앱 요청에 포함된 상태 정보는 다를 수 있습니다.

콘텐츠를 가져오지 못하면 접근 경로 확인

업데이트가 계속 대기하거나 네트워크 오류가 표시되면 구독 도메인을 조회할 수 있는지, 현재 Global Routing에서 해당 요청이 어떤 경로로 전달되는지 먼저 확인하세요. 현재 목록의 서버가 모두 작동하지 않으면 업데이트에 연결이 필요하고 연결에 업데이트가 필요한 순환 문제가 생길 수 있습니다. 처리 전에 기존 목록을 보관하고 사용자가 이미 보유했으며 작동이 확인된 연결 방식을 선택하거나 구독 주소에 직접 접속할 수 있는 네트워크에서 업데이트하세요. 이 문제를 해결하려고 출처를 알 수 없는 설정을 가져오지 마세요.

기기 시간과 HTTPS 인증서 오류도 확인하세요. 공용 Wi-Fi에서만 실패한다면 연결을 끄고 네트워크 인증을 완료한 뒤 다시 가져오세요. 네트워크가 인증 웹페이지를 반환하면 앱이 받은 것은 구독 데이터가 아닙니다. 응답이 비어 있는지, 리디렉션되는지, 웹페이지 문구가 반환되는지 기록할 수 있지만 서버 주소와 인증 정보가 들어 있을 수 있으므로 전체 응답을 그대로 공개하지 마세요. 네트워크 경로가 정상화되면 한 번 더 업데이트하면 됩니다. 빠르게 연속해서 누른다고 원격 권한이나 콘텐츠 문제가 해결되지는 않으며 결과를 파악하기만 더 어려워집니다.

콘텐츠가 있지만 인식되지 않으면 형식 확인

가져올 항목은 서버 구독, 단일 서버 공유 정보, 전체 설정 파일일 수 있으며 각각 용도가 다릅니다. 콘텐츠 유형에 맞는 가져오기 메뉴를 사용하고 Shadowrocket용으로 서비스 제공자가 제공한 형식을 기준으로 하세요. 로그인 페이지, 계정 안내, 오류 설명 또는 현재 메뉴에서 인식하지 못하는 텍스트가 반환되면 다운로드가 완료되어도 가져오기에 실패합니다. 이해하기 어려운 접두어를 수동으로 지우거나 인코딩을 임의로 바꿔 “수정”하지 마세요. 올바른 인증 정보가 손상될 수 있고 이후 점검에 필요한 원본도 사라질 수 있습니다.

업데이트 후 서버 일부만 표시된다면 기존 구독에 원래 해당 항목만 포함되어 있었는지 확인한 다음 현재 설정에서 인식하지 못하는 항목이나 필터 조건이 있는지 살펴보세요. 이름이 같아도 설정값까지 같다고 볼 수 없습니다. 특히 수동 항목과 구독 항목을 함께 사용하는 경우 현재 선택된 항목이 방금 업데이트한 서버인지 확인하세요. 구독에서 생성된 서버를 수정하기 전에는 별도의 테스트 항목으로 복사하세요. 이후 업데이트에서 수동 변경 사항이 덮어써질 수 있으므로 임시 수정이 원격 구독에도 반영됐다고 오해하지 마세요.

업데이트가 성공해도 서버 하나를 선택해 Connectivity Test를 실행한 뒤 실제 웹페이지로 확인해야 합니다. 가져오기와 형식 인식은 정상인데 모든 서버 연결이 실패한다면 구독 메뉴를 계속 바꾸지 말고 프로토콜 설정이나 원격 서비스 상태를 다시 확인하세요. 앱의 일회성 구매는 연결 서비스 요금제가 아닙니다. 앱 구매 비용과 기존 서비스 이용 권한은 별개입니다. iPhone / iPad 버전은 App Store에서 $2.99 일회성으로 구매하며 Mac / Windows / Android / Linux 버전은 무료입니다. 앱을 구매해도 가져올 구독이 자동으로 제공되지는 않습니다.

지연 시간, 웹페이지 첫 로딩 시간, 지속 다운로드 속도는 서로 다른 지표입니다. 지연 시간 하나만으로 속도를 판단하지 말고 여러 조건을 동시에 바꾼 상태에서 결과를 비교하지 마세요.

‘느림’을 확인 가능한 단계로 나누기

먼저 구체적인 증상을 설명하세요. 주소를 입력한 뒤 화면이 오래 비어 있는지, 글은 표시되지만 이미지가 늦게 뜨는지, 다운로드가 처음엔 빠르다가 점점 느려지는지, 화면을 잠그거나 네트워크를 바꾸면 연결이 끊기는지 구분합니다. 첫 접속 지연은 DNS, 연결 설정, TLS 핸드셰이크와 관련이 있을 수 있습니다. 지속적인 전송 속도 저하는 대역폭, 패킷 손실, 원격 서버 부하, 대상 서비스와 관련될 가능성이 큽니다. 한 앱이나 웹사이트에서만 느리다면 다른 대상으로 비교하세요. 대상 서비스의 속도 제한, 계정 제한, 페이지 리소스 문제를 모두 Shadowrocket 탓으로 돌리지 마세요.

기기, 네트워크, 서버, Global Routing, 테스트 파일을 고정하고 다른 기기나 앱에서 대용량 작업을 중지한 뒤 몇 차례 테스트하세요. Direct와 Proxy 경로를 비교할 때는 두 경로 모두 접속할 수 있는 대상을 선택해야 합니다. 그렇지 않으면 실패 결과를 속도 비교에 활용할 수 없습니다. 대략적인 시간대와 증상을 기록하고 한 번의 결과로 하루 전체의 상태를 단정하지 마세요. Wi-Fi 간섭, 가정 내 네트워크 사용량, 원격 서버 부하는 시간에 따라 달라질 수 있습니다. 테스트의 목적은 병목을 찾는 것이지 보기 좋은 단일 수치를 만드는 것이 아닙니다.

로컬 네트워크, 전송 경로, 원격 대상을 나눠 확인

먼저 연결을 끄고 로컬 네트워크가 안정적인지 확인한 뒤 Wi-Fi 신호가 좋은 곳에서 다시 테스트하세요. 벽, 혼잡한 채널, 라우터 부하의 영향을 피합니다. 같은 기기에서 Direct 경로도 눈에 띄게 느리다면 로컬 네트워크부터 점검하세요. Proxy 경로만 느리다면 대상을 그대로 둔 채 사용자가 이미 보유한 다른 서버와 비교합니다. 여러 서버에서 같은 대상만 느리다면 대상 서비스의 제한도 고려해야 합니다. 휴대폰 발열, 저전력 모드, 대량의 백그라운드 동기화도 사용 경험에 영향을 주므로 비슷한 기기 상태에서 비교하세요.

지연 시간이 짧다고 처리량이 높은 것은 아닙니다. 짧은 테스트는 적은 양의 데이터만 주고받으므로 장시간 전송에서 발생하는 혼잡과 재전송을 보여 주지 못할 수 있습니다. 반대로 거리가 먼 서버는 핸드셰이크가 느려도 지속 전송 속도는 더 나을 수 있습니다. 최저 테스트 수치를 얻으려고 서버를 자주 바꾸면 앱 연결이 계속 새로 만들어집니다. 동영상, 실시간 통화, 파일 다운로드는 버퍼링, 연속성, 실제 전송 상태를 각각 확인하세요. 한 종류의 결과를 모든 용도에 그대로 적용하지 마세요.

연결이 끊기는 조건별로 확인

Wi-Fi에서 셀룰러로 바꿀 때만 연결이 끊긴다면 기존 연결을 이어서 사용할 수 없어 새 요청을 다시 설정해야 할 수 있습니다. 연결이 복구될 때까지 기다린 다음 대상 페이지를 다시 여세요. 전환할 때마다 복구되지 않으면 스위치 상태, On Demand 조건, 서버 연결 오류를 기록하고 해당 항목을 점검하세요. 특정 Wi-Fi에서만 끊긴다면 네트워크가 주기적으로 재인증하는지, 절전 상태로 들어가는지, 장시간 연결을 제한하는지 확인하세요. “시간이 지나면 끊김”만으로 비밀번호 오류라고 판단하지 마세요. 인증 오류는 보통 연결 설정 단계에서 나타납니다.

작은 요청은 정상인데 큰 파일이나 특정 페이지가 계속 멈춘다면 패킷 손실, 전송 방식, 경로의 패킷 분할 문제를 더 확인할 수 있습니다. 온라인에서 본 MTU 고정값을 그대로 적용하지 마세요. 네트워크, 프로토콜, 터널 캡슐화에 따라 필요한 값이 다르므로 부적절한 변경은 원래 정상인 트래픽까지 영향을 줄 수 있습니다. 재현 조건을 기록하고 기본값을 저장하며 설정 용도를 이해한 경우에만 하나씩 비교하세요. 개선되지 않으면 원래 값으로 되돌려 설명하기 어려운 설정을 장기간 남기지 마세요.

규칙 기록으로 ‘일부 콘텐츠가 느림’ 설명

Config 모드에서는 페이지 본문, 이미지, API가 각각 다른 정책을 적용받을 수 있으므로 느린 요청의 도메인과 최종 경로를 확인하세요. 특정 규칙에 연결된 정책만 느리다면 모든 요청을 Proxy로 바꾸지 말고 해당 정책이 가리키는 서버가 여전히 작동하는지 확인하세요. 연결 기록에 반복해서 나타나는 실패, 재시도, 재조회가 단일 속도 테스트보다 체감 지연을 더 잘 설명할 수 있습니다. 진단이 끝나면 불필요한 부하 테스트를 중지하고 일상 설정으로 되돌리세요. 속도 테스트를 동시에 여러 개 실행하면 대역폭을 사용하고 이후 관찰 결과도 왜곡됩니다.

DNS 문제는 주소가 반환되는지만 확인해서는 안 됩니다. 누가 조회를 요청하는지, 어떤 경로로 조회하는지, 어떤 주소가 반환되는지, 최종 연결에서 어느 주소를 선택하는지도 함께 확인해야 합니다.

DNS 조회 실패를 보여 주는 증거부터 확인

브라우저에서 서버를 찾을 수 없다고 표시되거나 연결 기록에 도메인 조회 실패가 나타나면 도메인 철자, 기본 네트워크, 현재 설정의 DNS 항목부터 확인하세요. 서로 관련 없는 여러 도메인이 동시에 실패하면 DNS 서버 접근 가능성을 먼저 확인합니다. 도메인 하나만 실패한다면 해당 도메인의 DNS 레코드, 캐시, 도메인 규칙을 확인하세요. IP 주소로는 접속되지만 도메인으로는 실패하는 현상은 단서일 뿐 완전한 결론은 아닙니다. HTTPS 서비스는 올바른 호스트 이름과 인증서가 필요한 경우가 많으며, 브라우저에 주소를 직접 입력하면 다른 결과가 나올 수 있습니다. 이것만으로 서버가 정상 또는 비정상이라고 단정하지 마세요.

Config에서 직접 추가한 DNS 항목, 정적 매핑, 특정 도메인에 대한 별도 처리가 있는지 확인하세요. 먼저 사본을 저장하고 원본 설정과 비교합니다. 용도를 모르는 설정을 한 번에 모두 바꾸지 마세요. 시스템 DNS 프로파일, 라우터 설정, 앱의 DNS 경로가 동시에 적용될 수도 있으므로 특정 조회를 실제로 처리한 주체는 기록을 통해 확인해야 합니다. 시스템에 DNS 서버가 입력되어 있다고 해서 모든 프록시 요청이 반드시 그 서버를 이용하는 것은 아닙니다. 마찬가지로 앱 설정이 기기의 모든 요청에 적용되는 것도 아닙니다.

DNS 조회와 연결 간 의존성 확인

DNS 서버 자체를 도메인으로 찾아야 하고 해당 DNS 서버에 접속하려면 아직 설정되지 않은 프록시 경로가 필요한 경우 시작 단계에서 의존성 순환이 생길 수 있습니다. 먼저 서버 주소를 어떻게 조회하는지 확인한 뒤 DNS 서버에 어떻게 접속하는지, 마지막으로 대상 도메인 조회가 어떤 경로를 사용하는지 점검하세요. 확인 과정에서는 작동이 검증된 기본 설정으로 돌아가고 암호화 DNS 옵션 여러 개와 복잡한 분할 설정을 한꺼번에 추가하지 마세요. DNS 서버마다 네트워크 접근 조건이 있습니다. 주소를 더 추가한다고 반드시 안정성이 높아지는 것은 아니며 실패가 불규칙하게 나타날 수도 있습니다.

암호화 DNS를 사용한다면 프로토콜, 주소 형식, 포트, 인증서 이름이 설정 요구 사항과 일치하는지 확인하고 현재 네트워크에서 해당 서버에 접속할 수 있는지도 확인하세요. 일반 HTTPS 웹페이지가 열린다고 특정 DNS 엔드포인트도 작동하는 것은 아닙니다. 요청이 프록시를 이용한다면 지정된 정책도 이미 작동 중이어야 하며 Direct 경로를 사용한다면 직접 연결을 확인해야 합니다. 시간 오류나 이름 불일치를 해결하려고 인증서 검증을 끄지 마세요. 먼저 기기 시간과 주소를 수정한 뒤 문제가 사라지는지 확인하세요.

주소 체계, 규칙, 캐시를 구분해 확인

하나의 도메인에서 IPv4와 IPv6 주소가 모두 반환될 수 있습니다. 한 주소 체계의 경로에 문제가 있으면 첫 요청이 오래 대기하거나 일부 요청만 실패할 수 있습니다. 실제로 선택된 주소와 오류를 확인해 DNS 조회 단계와 연결 단계 중 어느 쪽에서 실패했는지 구분하세요. 문제가 발생했다고 IPv6를 영구적으로 끄지 마세요. 규칙의 IP-CIDR과 IP-CIDR6은 서로 다른 주소 체계에 해당합니다. 주소 판단에 의존하는 규칙은 DNS 결과에 따라 적용 상태가 달라질 수 있으므로 도메인 규칙만 확인해서 전체 경로를 설명하기는 어렵습니다.

DNS나 규칙을 바꿔도 이전 캐시와 재사용 연결이 결과에 영향을 줄 수 있습니다. 새 요청을 보내고 필요하다면 VPN에 다시 연결하거나 테스트 중인 앱을 재시작한 뒤 기록을 비교하세요. 캐시가 갱신되기 전에 여러 설정을 연달아 바꾸지 마세요. 로컬 네트워크의 내부 도메인은 해당 네트워크의 DNS 서버에서만 조회될 수 있습니다. 외부 DNS 경로를 강제로 사용하면 오히려 실패할 수 있습니다. 가정이나 사무실 내부 서비스는 DNS 조회와 로컬 네트워크 경로를 함께 확인해 현재 네트워크에서 조회된 내부 주소에 실제로 접근할 수 있는지 점검하세요.

마지막으로 일반 웹페이지, 이전에 문제가 있었던 도메인, 접속해야 하는 내부 서비스를 각각 확인하세요. 대상별로 DNS 조회 성공 여부, 최종 정책, 접속 결과를 기록합니다. 복구를 확인한 뒤 테스트용 정적 매핑과 임시 규칙을 정리해 주소 변경 후 다시 문제가 생기지 않도록 하세요. DOMAIN-SUFFIX, IP-CIDR, FINAL 설정의 관계는 설정 가이드에서 확인할 수 있습니다. 흔한 오류의 의미만 확인하려면 문제 해결을 참고하세요.

배터리 소모 원인을 판단하기 전에 같은 시간대의 화면 사용, 네트워크 활동, 연결 오류를 확인하세요. 시스템 배터리 사용 내역의 앱별 표시가 해당 앱에서 추가로 소비한 전체 배터리량과 정확히 같지는 않습니다.

비교 가능한 관찰 시간대 선택

시스템의 배터리 사용 화면에서 문제가 발생한 시간대를 확인하고 화면이 켜져 있을 때의 높은 사용량과 대기 중 지속 활동을 구분하세요. 동영상 재생, 파일 다운로드, 사진 동기화, 앱 업데이트는 모두 네트워크 트래픽을 발생시킵니다. VPN을 통과하는 네트워크 작업도 시스템이 활동을 분류하는 방식에 영향을 줄 수 있습니다. 특정 비율만 보고 결론 내리지 마세요. 선택한 시간대에서의 상대적 비중일 수 있으며 기기 전체 배터리가 같은 비율만큼 줄었다는 뜻은 아닙니다. 기기 발열, 신호 강도, 실제 사용 내용을 기록해야 의미 있는 비교가 가능합니다.

비교할 때는 화면 밝기, 네트워크, 앱 사용, 시간을 최대한 비슷하게 유지하고 연결을 켰을 때와 껐을 때를 각각 관찰하세요. 아무것도 하지 않고 대기한 상황과 동영상을 오래 본 상황을 비교하지 말고 테스트를 위해 화면을 계속 켜 두거나 속도 테스트를 반복하지 마세요. 셀룰러 신호가 약하거나 Wi-Fi가 자주 끊기거나 백그라운드 작업이 많은 경우 배터리 사용량이 크게 늘 수 있습니다. 연결을 끈 뒤에도 문제가 계속되면 규칙을 더 바꾸기보다 시스템과 다른 앱을 포함해 확인 범위를 넓히세요.

반복 실패를 먼저 확인하고 설정 복잡성은 다음에 점검

같은 도메인 요청이 계속 실패하는지, 서버가 반복해서 재연결되는지, 구독 업데이트가 계속 반복되는지 확인하세요. 짧은 시간 동안 재시도가 많이 발생하면 네트워크와 처리 리소스를 모두 소모할 수 있습니다. 서버 인증 만료, DNS 요청 실패, 차단된 주소에 계속 접속하는 앱 등 재시도를 일으키는 근본 원인을 먼저 해결하세요. 기록을 숨기는 것만으로는 재시도가 멈추지 않습니다. 요청이 많은 앱을 잠시 종료한 뒤 연결 활동이 눈에 띄게 줄어드는지 확인하면 트래픽 출처를 파악하는 데 도움이 됩니다.

불필요하게 잦은 테스트, 과도한 자동 업데이트, 추가 진단 기록이 켜져 있는지 확인하세요. 테스트 주기와 기록 옵션은 실제 필요에 맞춰 설정해야 하며 모든 기기에 통하는 고정된 최적값은 없습니다. 점검이 끝나면 문제 파악을 위해 임시로 켠 상세 기록을 끄세요. 장기간 데이터를 쌓고 처리량을 늘릴 필요는 없습니다. 필요한 정보를 내보낸 뒤 안전한 곳에 보관하고 개인 주소가 포함된 임시 파일은 삭제하세요. 기기 저장 공간이 부족하다면 시스템 저장 공간 문제도 해결해야 합니다. 앱 반응이 느린 현상을 모두 네트워크 사용에 따른 배터리 소모로 단정하지 마세요.

네트워크 조건에 따른 On Demand 확인

On Demand는 조건에 따라 연결을 시작합니다. 설정이 적절하지 않으면 네트워크가 바뀌거나 여러 조건이 번갈아 충족될 때 반복해서 작동할 수 있습니다. 먼저 각 조건의 대상, 순서, 동작을 기록한 다음 자동 연결을 잠시 중지하고 비슷한 사용 상황에서 수동으로 연결해 관찰하세요. 수동 연결은 안정적인데 특정 조건을 되살린 뒤 재연결이 잦아진다면 해당 조건이 다른 조건과 겹치는지, 자주 변하는 네트워크 상태에 의존하는지 확인하세요. 여러 조건을 동시에 추가하거나 삭제하면 어떤 조건이 영향을 줬는지 파악하기 어렵습니다.

연결을 장시간 유지해야 한다면 자동 연결로 계속 실패하는 연결을 보완하기보다 평소 사용하는 네트워크에서 선택한 서버가 안정적인지 먼저 확인하세요. 귀가, 사무실 네트워크 이탈, Wi-Fi에서 셀룰러로의 전환은 중점적으로 살펴볼 상황입니다. 전환 후 스위치가 켜져 있는지, 요청이 복구되는지, 반복 재시도가 발생하는지 기록하세요. 관리 대상 기기나 네트워크에서는 시스템 정책에 따른 연결 해제와 재설정도 고려해야 합니다. 자동으로 바뀌는 모든 현상을 앱 설정 탓으로 돌리지 마세요.

점검을 멈추고 원래 설정으로 복구할 조건 정하기

문제를 일으키는 앱의 요청을 중지하거나 서버 오류를 수정하거나 자동 연결 조건 하나를 조정한 뒤 기기 온도와 대기 상태가 정상으로 돌아왔다면 같은 조건에서 다시 확인해 개선이 반복되는지 살펴보세요. 배터리 소모가 계속 비정상적이면 기기를 재시동하고 시스템의 백그라운드 작업을 확인합니다. 재시동 직후의 짧은 변동을 장기적인 결과로 간주하지 마세요. 충전 중 발열은 시스템 충전과 작업 스케줄링 때문일 수도 있으므로 충전하지 않은 상태에서 사용량이 비슷한 상황과 구분해 기록하세요.

점검을 마치면 필요한 규칙과 연결 정책을 복구하고 임시로 설정한 전체 프록시, 상세 진단 기록, 잦은 테스트를 해제하세요. 문제 시간대, 관련 요청, 효과가 있었던 변경, 재테스트 결과만 간단히 정리해 두면 됩니다. 반복해서 확인되는 근거가 없다면 전체 설정을 지우거나 기기 설정을 초기화하지 마세요. 비용이 많이 들고 문제 파악에 필요한 정보까지 삭제할 수 있습니다. 추가 문의가 필요하면 다음 장의 민감 정보 제거 기록 목록을 활용하고 전체 구독이 포함된 백업 파일은 보내지 마세요.

업데이트 후에는 현재 사용하는 서버, Config, 시스템 권한을 확인하세요. iPad에서 다른 기기와 결과가 다르다면 네트워크와 설정값을 비교하고 같은 계정이라고 해서 각 기기의 상태까지 같다고 가정하지 마세요.

업데이트 전후를 비교하고 재설치는 서두르지 않기

설정을 변경하기 전에 저장 가능한 서버와 설정 자료를 내보내고 백업 파일의 용도를 알아볼 수 있는지 확인한 뒤 현재 설정의 사본을 보관하세요. 백업에는 민감 정보가 포함될 수 있으므로 본인이 관리하는 위치에 저장하고 공개 업로드하지 마세요. 업데이트 후에는 선택된 서버가 바뀌었는지, Global Routing이 예상대로인지, 현재 Config가 원본 파일인지, 시스템 VPN 설정이 존재하는지 먼저 확인합니다. 업데이트와 구독 자동 변경을 같은 원인으로 보지 마세요. 두 일이 비슷한 시점에 발생했더라도 각각 따로 확인해야 합니다.

업데이트 후 기존 설정에 문제가 생겼다면 사용자가 이미 보유하고 설정을 확인할 수 있는 서버 하나로 최소 연결 테스트를 하세요. 최소 테스트가 성공하면 기본 연결은 작동할 수 있다는 뜻입니다. 이후 원래 설정의 규칙, DNS, 자동 연결 조건을 하나씩 복구하세요. 최소 테스트도 실패하면 시스템 권한, 기본 네트워크, 프로토콜 설정으로 돌아가 확인합니다. 복잡한 설정을 확인하려고 여러 파일을 연달아 덮어쓰지 말고 언제든 되돌릴 수 있는 원본을 남기세요. 현재 테스트 중인 파일 이름도 명확히 기록합니다.

다운로드 경로와 최초 실행 허용 확인

iPhone / iPad 버전은 App Store에서 업데이트하거나 다시 받습니다. 개발자가 Shadow Launch Technology Limited인지, 공식 아이콘과 앱 ID 932747118이 맞는지 확인하세요. 시스템 요구 사항은 App Store 페이지에 표시된 내용을 기준으로 하며 재설치 전 자료를 백업하세요. iPhone / iPad 버전은 App Store에서 $2.99에 일회성으로 구매하고 Mac / Windows / Android / Linux 버전은 무료입니다. 구매 내역 복원과 계정 지역 문제는 다시 다운로드 안내를 확인하세요. 앱을 받을 수 있는 상태와 기존 구독의 이용 권한을 혼동하지 마세요.

다른 플랫폼의 설치 파일은 다운로드 페이지에서 사이트 내 /dl/shadowrocket/ 경로로 제공합니다. Mac에서는 ‘이 Mac에 관하여’에서 Apple 칩 또는 Intel을 확인한 뒤 해당 설치 파일을 선택하세요. 개발자를 확인할 수 없다는 안내가 처음 나타나면 시스템의 개인정보 보호 및 보안에서 내용을 확인한 뒤 ‘그래도 열기’를 선택합니다. Windows에서 SmartScreen이 표시되면 사이트 내 다운로드 경로를 확인한 뒤 ‘추가 정보’와 ‘실행’을 선택할 수 있습니다. 관리 대상 기기는 조직 정책을 따라야 합니다. Android에서는 시스템 안내에 따라 사용하는 브라우저의 알 수 없는 앱 설치를 허용하고 설치가 끝나면 해당 권한을 다시 해제할 수 있습니다. 자세한 절차는 설치 허용 안내를 확인하세요.

iPad 점검: 네트워크, 설정, 사용 환경 비교

같은 구독이 iPhone에서는 정상인데 iPad에서만 문제가 생기면 두 기기가 실제로 같은 네트워크에 연결되어 있는지 먼저 확인하세요. 한 기기는 셀룰러를 사용하고 다른 기기는 Wi-Fi를 사용할 수 있습니다. 공용 네트워크는 기기마다 별도로 인증해야 할 수 있으므로 휴대폰에서 인증을 완료했다고 태블릿까지 인증된 것은 아닙니다. 선택된 서버, 프로토콜 항목, Global Routing, 현재 Config를 비교해 한 기기는 이전 목록을 사용하고 다른 기기는 업데이트된 목록을 사용하지 않는지 확인하세요. 일부 자료가 기기 간에 동기화되더라도 모든 로컬 설정과 시스템 권한이 항상 같다는 뜻은 아닙니다.

Wi-Fi 전용 iPad는 셀룰러 네트워크와 직접 비교할 수 없습니다. 가능하다면 정상 작동이 확인된 다른 Wi-Fi에 연결하거나 본인이 소유한 기기의 핫스팟을 사용하세요. 서버와 대상 웹페이지를 그대로 두고 문제가 네트워크에 따라 달라지는지 확인합니다. 화면 분할을 사용할 때 한쪽 앱이 정상이라고 해서 다른 쪽 앱이 같은 도메인이나 연결 경로를 사용한다고 단정할 수 없습니다. 실제 접속 대상을 각각 기록하세요. 내부 웹페이지나 프린터에 연결할 때는 현재 Wi-Fi에서 기기 간 통신을 허용하는지도 확인해 로컬 네트워크 격리를 규칙 오류로 오해하지 않도록 합니다.

화면을 잠근 뒤, 오랫동안 사용하지 않은 뒤, 다시 깨운 뒤에만 실패한다면 스위치가 켜진 상태인지, 네트워크 재인증이 필요한지, On Demand가 기기를 깨운 뒤 다시 작동하는지 확인하세요. 이전 페이지에 남아 있는 로딩 표시만 보고 판단하지 말고 새 요청을 보내 확인합니다. VPN 설정을 다시 만들어야 한다면 먼저 백업을 완료하고 용도가 분명한 항목만 처리하세요. iPad 전용 프로토콜 설정을 따로 추측할 필요는 없습니다. 같은 서버는 기존 서비스 정보와 일치해야 하며 차이는 기기의 네트워크와 로컬 상태에서 하나씩 찾아야 합니다.

재현에 필요한 민감 정보 제거 기록 정리

문제가 해결되지 않으면 기기와 시스템 종류, 네트워크 종류, 스위치 상태, Global Routing, 문제를 일으킨 동작, 원래 표시된 오류 문구, 비교 테스트 결과를 정리하세요. “언제 시작됐는지, 어떤 대상에 영향을 주는지, 연결을 끄면 해결되는지”를 설명하면 업데이트 후 작동하지 않는다고만 말하는 것보다 도움이 됩니다. 스크린샷에서는 구독 토큰, 인증 정보, QR 코드, 공개하지 않을 서버 주소를 가리고 전체 백업 파일도 보내지 마세요. 복구한 뒤 빠른 시작 가이드에 따라 가져오기, 연결, 테스트를 다시 진행하고 효과가 있었던 절차를 다음에 참고할 수 있도록 기록해 두세요.