Shadowrocket 문제 해결 가이드

연결 스위치가 켜지지 않음: 먼저 시스템 연결 상태 확인

Home에서 스위치를 켠 직후 다시 꺼진다면 연결 설정 과정이 완료되지 않은 것입니다. 스위치는 켜져 있지만 웹페이지가 열리지 않는 문제와는 다릅니다. 먼저 VPN 구성을 추가하라는 시스템 권한 요청이 표시되는지, 구체적인 오류가 있는지, 스위치를 누른 뒤 어느 단계에서 다시 꺼지는지 확인하세요. 상태 표시줄 아이콘만으로 연결 성공 여부를 판단하지 마세요. 기기에 따라 시스템 레이아웃이 달라 아이콘 위치가 다를 수 있습니다. Home의 상태와 오류 원문을 함께 확인하고 스위치를 빠르게 반복해서 누르지 마세요.

권한 미승인, 구성 충돌, 연결 실패 구분하기

처음 활성화할 때는 시스템에서 VPN 구성 추가를 승인해야 합니다. 승인을 취소했다면 Shadowrocket으로 돌아가 다시 시도하고, 시스템 안내에 따라 권한을 허용하세요. 기기 암호는 시스템 화면에서 처리합니다. 그런 다음 시스템 Settings에서 VPN 구성이 있는지, 현재 어떤 항목이 활성화되어 있는지 확인하세요. 기기에 VPN 구성이 여러 개 있어도 반드시 문제가 되는 것은 아니지만, 다른 연결이 동시에 실행되면 현재 연결이 끊길 수 있습니다. 다른 VPN을 먼저 중지한 뒤 Shadowrocket만 단독으로 테스트하세요. 모든 네트워크 설정을 바로 삭제하지 마세요.

기기가 학교나 회사에서 관리되는 경우 권한 스위치를 조작할 수 없거나 구성을 추가하지 못하거나 시스템에서 관리 제한을 명확히 알릴 수 있습니다. 이때는 기기 관리자에게 정책을 확인하세요. 앱을 삭제해도 이런 제한은 해제되지 않으며 로컬 설정만 사라질 수 있습니다. 개인 기기라면 자동 연결 규칙이 설정되어 있는지 먼저 확인하세요. 수동으로 끈 직후 다시 켜진다고 해서 버튼이 고장 난 것은 아닙니다. On Demand가 작동 중일 수 있습니다. 조건을 기록하고 관련 자동 연결을 잠시 끈 뒤 배터리 소모 및 On Demand 항목을 확인하세요.

최소 구성으로 문제 범위 확인하기

Home에서 설정이 완전한 서버가 하나 있는지 확인하고 기본 서버로 명확히 선택하세요. 목록만 가져오고 기본 항목을 선택하지 않았다면 충분한 테스트 조건이 아닙니다. 규칙 파일의 영향을 줄이려면 Global Routing을 잠시 Proxy로 설정한 뒤 연결을 시도하세요. 그래도 즉시 꺼진다면 권한, 시스템 네트워크 확장 상태, 서버 항목 오류를 우선 확인하세요. 계속 켜져 있다면 기존 Config 설정이나 정책 참조를 점검해야 합니다. 테스트가 끝나면 원래 라우팅 설정으로 되돌리세요.

현재 .conf 파일과 필요한 서버 정보를 저장한 뒤 앱 연결을 정상적으로 끊고 앱을 다시 열어 테스트할 수 있습니다. 네트워크 전환 후 문제가 발생했다면 현재 Wi-Fi 로그인이 완료되었는지, 또는 셀룰러 데이터로 일반 웹페이지에 직접 접속할 수 있는지 확인하세요. 시스템 로그인 절차가 필요한 네트워크에서는 로그인 전에 프록시 연결이 먼저 시도되어 실패할 수 있습니다. 먼저 연결을 끊고 로그인을 마친 다음 Shadowrocket을 시작하세요. 로그인 페이지가 열리지 않는다고 서버가 고장 났다고 단정하지 말고, 불분명한 안내 화면에 구독 인증 정보를 입력하지 마세요.

시스템 구성을 다시 만들 때

네트워크가 정상이고 기본 서버가 명확하며 권한 절차가 계속 실패하는 경우에만 Shadowrocket에 해당하는 시스템 VPN 구성을 다시 만들지 고려하세요. 작업 전 앱 내 설정을 백업하고 연결과 On Demand를 끈 다음, 시스템 설정에서 정확한 항목을 확인하세요. 해당 항목을 제거한 뒤 앱으로 돌아와 연결을 시작하고 시스템 권한 요청을 다시 진행합니다. 이 작업은 시스템 연결 구성 문제만 해결합니다. 잘못된 주소, 포트, 암호는 수정하지 않으므로 모든 문제에 무조건 적용하는 첫 단계로 삼지 마세요.

시스템 업데이트 후 처음 문제가 발생했다면 연속해서 앱을 재설치하기보다 기기를 재시동하고 최소 구성으로 다시 테스트하세요. “권한 요청 표시 여부, 구성 생성 여부, 연결 유지 여부”를 기록하면 이후 원인을 찾기 쉽습니다. 복구한 뒤 기존 규칙, 자동 연결, 추가 설정을 하나씩 다시 활성화하고 매번 테스트하세요. 특정 항목을 켠 직후 문제가 재발하면 해당 설정의 의존 항목과 구성 내용을 다시 확인할 수 있도록 기록을 남기세요. 권한 관련 질문은 FAQ에서도 확인할 수 있습니다.

연결되었지만 인터넷에 접속할 수 없음: 네 단계로 차례대로 확인

연결 스위치가 켜져 있다는 것은 시스템 연결이 작동 중이라는 뜻일 뿐, 현재 서버가 트래픽을 전달할 수 있다는 의미는 아닙니다. Shadowrocket 연결을 끊고 같은 네트워크에서 평소 접속할 수 있는 웹페이지를 열어 기본 네트워크, Wi-Fi 인증, 셀룰러 데이터 권한이 정상인지 확인하세요. 다시 연결한 뒤 기본 서버, Global Routing, DNS, 규칙 적용 순으로 점검합니다. 매 단계에서 같은 대상을 사용하고 실패 양상이 대기 시간 초과인지, 이름 확인 실패인지, 인증서 안내인지, 서버 오류 응답인지 기록하세요. 각 증상에 따라 확인할 부분이 다릅니다.

먼저 서버를 확인하고 세 가지 라우팅 모드 비교하기

Home에서 기본 서버가 예상한 항목을 가리키는지 확인하세요. 특히 구독 업데이트, 기존 항목 삭제, 그룹 전환 후에는 다시 살펴봐야 합니다. Connectivity Test로 연결 결과를 확인하되, 테스트 수치 하나만으로 모든 서비스가 정상이라고 단정하지 마세요. 테스트에 성공해도 대상 경로, DNS, 전송 프로토콜 차이로 웹페이지가 열리지 않을 수 있습니다. 이미 사용 가능한 다른 서버가 있다면 기본 서버만 바꾸어 비교하세요. 서버를 바꾼 뒤 연결을 새로 설정해 이전 연결의 결과를 새 서버의 결과로 오인하지 않도록 합니다.

세 가지 모드를 테스트하는 목적은 특정 모드를 계속 사용하는 것이 아니라 비교 가능한 조건을 만드는 것입니다. Direct는 되고 Proxy는 안 된다면 서버 매개변수와 네트워크 연결 가능 여부를 확인하세요. Proxy는 되고 Config는 안 된다면 규칙 순서, 정책 이름, 현재 활성화된 파일을 점검하세요. 세 모드 모두 문제가 있다면 규칙을 더 추가하지 말고 기본 네트워크와 DNS부터 확인하세요. 원인을 찾은 뒤 실제 용도에 맞는 Config로 되돌리고, 참조된 정책이 존재하는지 확인합니다.

키워드만 찾지 말고 규칙 적용 순서 확인하기

[Rule]은 일반적으로 순서대로 확인되므로 앞에 있는 포괄적인 규칙이 뒤의 구체적인 규칙보다 먼저 적용될 수 있습니다. 아래 예시는 순서를 설명하기 위한 것으로, example.com은 예시 도메인이며 전체 구성 대신 사용할 수 없습니다. DOMAIN-SUFFIX는 해당 도메인과 하위 도메인에 적용됩니다. GEOIP는 대상 IP의 위치 정보에 따라 판단합니다. FINAL은 앞의 규칙에 모두 해당하지 않을 때 적용되는 기본 규칙입니다. DNS 결과, 규칙의 적용 범위, 실제 정책을 함께 확인해야 합니다. 파일에 PROXY가 있다는 이유만으로 요청이 반드시 프록시를 거친다고 단정할 수 없습니다.

[General]
bypass-system = true
dns-server = system

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

사용자 지정 정책 그룹을 쓴다면 그룹 이름의 철자가 일치하는지, 그룹에 사용 가능한 항목이 있는지, 구독 업데이트 후 현재 선택 항목이 바뀌었는지 확인하세요. 파일을 수정하기 전에 사본을 저장해 복구할 기준을 남기세요. 특정 사이트만 실패한다면 해당 도메인에 대한 임시 규칙 하나로 원인을 확인할 수 있습니다. 확인 후 정식 구성에 반영할지 결정하세요. 포괄적인 DOMAIN-KEYWORD로 문제를 덮거나 FINAL을 앞쪽으로 옮겨 뒤의 규칙을 무효화하지 마세요.

브라우저 캐시와 시스템 상태를 따로 확인하기

브라우저에 이전 페이지, 기존 연결, 이전 DNS 결과가 남아 있을 수 있습니다. 모드를 전환한 뒤 기존 로딩 화면만 보지 말고 새 요청을 보내세요. 실패한 페이지를 닫았다가 다시 열고, 필요하면 이전에 방문하지 않은 테스트 대상을 사용해 다른 앱의 결과와 비교하세요. 사이트 하나만 문제가 있다면 해당 사이트의 상태와 인증서를 먼저 확인하세요. 이를 근거로 모든 연결을 초기화하지 마세요. 여러 도메인이 실패하지만 기존 연결은 작동한다면 다음 단계에서 DNS를 확인하세요. 자세한 판단은 DNS 문제 항목을 참고하세요.

서버 시간 초과: 매개변수와 전송 경로 확인

시간 초과는 정해진 시간 안에 예상한 응답을 받지 못했다는 뜻입니다. 암호가 틀렸거나 서버가 중지되었다는 뜻은 아닙니다. DNS 조회, 주소 연결, 포트 연결, TLS 핸드셰이크, 프로토콜 인증 중 어느 단계에서든 멈출 수 있습니다. 먼저 테스트 유형과 오류 원문을 보관하고 Connectivity Test에서 시간 초과가 발생했는지 실제 웹페이지에서 발생했는지 확인하세요. 일부 서버는 특정 탐지 방식에 응답하지 않을 수 있으므로 탐지 실패는 실제 요청 결과와 함께 판단해야 합니다. 목록의 상태 한 줄만 보고 기존 구성을 삭제하지 마세요.

기존 서버 정보를 항목별로 대조하기

Add Server에서 해당 항목을 열고 서비스 제공자가 안내한 정보와 하나씩 비교하세요. 서버 주소에 경로, 공백, 프로토콜 접두사를 섞어 넣지 마세요. 포트는 해당 접속 항목에 맞아야 합니다. 암호, UUID 등 인증 필드는 대소문자와 문자를 그대로 유지하고, 복사할 때 끝에 줄바꿈이 들어가지 않았는지 확인하세요. 비슷해 보인다는 이유로 필드를 서로 바꾸지 말고 구독 주소를 서버 주소 입력란에 넣지 마세요. QR 코드로 가져온 뒤에도 프로토콜 유형과 주요 매개변수를 확인해야 합니다. 가져오기에 성공했다는 것은 내용이 인식되었다는 뜻이지 현재 네트워크에서 매개변수가 유효하다는 뜻은 아닙니다.

이 표는 확인 방향을 안내하기 위한 것이며 모든 서버에 적용할 입력 템플릿이 아닙니다. 각 필드의 입력 여부는 기존 서버 구성에 따라야 합니다. 자세한 프로토콜 설명은 프로토콜 및 매개변수 개요를 참고하세요. 서버 정보가 구독에서 제공된다면 먼저 정상적으로 업데이트한 뒤 항목을 비교하세요. 구독으로 생성된 항목을 직접 수정하면 다음 업데이트에서 변경 내용이 덮어써져 잠시 해결된 문제가 다시 발생할 수 있습니다.

TLS, 전송 유형, UDP를 따로 확인하기

TLS 핸드셰이크나 인증서 오류가 발생하면 기기의 날짜와 시간이 정확한지, 서버 이름이 서버에서 제공한 정보와 일치하는지 확인하세요. 연결 주소와 인증서 확인 이름은 다를 수 있으므로 실제 구성에 따라 입력해야 합니다. 인증서 확인을 끄고 오류를 계속 우회하지 마세요. 이름 오류, 인증서 만료, 잘못된 연결 대상이 가려질 수 있습니다. 특정 전송 방식을 사용한다면 Host와 경로 등의 매개변수도 서버 설정과 일치해야 합니다. 주소와 인증 정보만 확인해서는 진단이 끝나지 않습니다.

일반 웹페이지가 열린다는 사실은 해당 웹페이지 경로가 작동한다는 것만 보여 주며 모든 UDP 환경을 확인해 주지는 않습니다. 같은 서버로 웹페이지는 정상적으로 열리지만 실시간 통신이나 UDP 기반 기능에 문제가 있다면 프로토콜 지원 여부, 서버 조건, 현재 네트워크의 관련 전송 허용 여부를 확인하세요. 이미 사용 가능한 다른 구성과 비교할 때는 변수 하나만 바꾸세요. 예를 들어 같은 네트워크에서 서버만 바꾸거나, 같은 서버에서 네트워크만 바꿉니다. 프로토콜, 네트워크, DNS를 한꺼번에 바꾼 뒤 문제가 해결되어도 실제 원인을 알 수 없습니다.

네트워크 비교로 문제 범위 좁히기

Wi-Fi에서 시간 초과가 발생하지만 셀룰러 데이터에서는 정상이라면 현재 Wi-Fi의 DNS 조회, 포트, 전송 조건이 원인일 수 있습니다. 두 네트워크에서 서로 다른 주소를 선택했을 가능성도 있습니다. 결론을 내리기 전에 DNS 결과와 연결 대상을 확인하세요. 여러 네트워크에서 특정 서버만 실패하고 다른 기존 서버는 정상이라면 서비스 제공자에게 해당 접속 항목이 변경되었는지 문의해야 합니다. 프로토콜 유형, 오류 원문, 재현 조건만 전달하세요. 암호, 키, 구독 토큰, 전체 항목이 담긴 QR 코드는 보내지 마세요.

서버 매개변수가 올바른지 확인한 뒤 로컬 테스트를 다시 진행하세요. 기본 항목을 선택하고 Proxy를 잠시 사용한 다음 연결을 끊었다가 다시 연결해 같은 대상을 여세요. 정상으로 돌아오면 Config와 자동 연결을 하나씩 복구합니다. 계속 실패한다면 “기본 네트워크 정상, 다른 서버 정상, 해당 서버는 두 네트워크에서 모두 시간 초과”라는 결과를 기록하세요. 계속 대기 시간을 늘리는 것보다 이 정보가 문제 진단에 도움이 됩니다. 대기 시간을 늘려도 오류 표시만 늦어질 뿐 연결할 수 없는 주소, 잘못된 포트, 맞지 않는 전송 매개변수는 해결되지 않습니다.

구독 업데이트 실패: 다운로드와 구문 분석 구분

구독 업데이트는 최소 두 단계로 이루어집니다. 먼저 원격 내용을 가져오고, 다음으로 해당 내용을 서버 항목으로 변환합니다. 구독 주소에 접속할 수 없는 문제, 인증 만료, 내용 형식 불일치는 각각 따로 확인해야 합니다. 시작하기 전에 현재 사용 가능한 항목과 설정을 보관하고 오류 원문, 기존 항목이 남아 있는지, 수동 업데이트와 자동 업데이트 중 어느 쪽에서 실패했는지 기록하세요. 재시도 전에 구독 전체를 삭제하지 마세요. 원격 접속이 일시적으로 불가능한 상황에서 로컬 내용을 지우면 마지막으로 사용할 수 있던 연결 수단까지 잃을 수 있습니다.

주소가 완전한지와 가져오기 조건 확인하기

구독 주소는 본인이 이용하는 서비스 제공자에게서 받아야 하며, 로그인 페이지나 도움말 페이지, 계정 페이지 주소가 아니라 클라이언트 가져오기용 주소인지 확인하세요. 복사할 때 앞부분, 경로, 쿼리 매개변수가 모두 포함되었는지 확인하고 화면에 보이는 일부만 복사하지 않도록 합니다. 구독 토큰은 접근 권한을 부여할 수 있으므로 검색창, 공개 메모, 공개 스크린샷에 넣지 마세요. 주소가 화면에서 줄바꿈되어 보여도 반드시 문제가 있는 것은 아니지만, 복사 과정에서 공백이 들어가거나 매개변수가 빠지거나 구두점이 함께 포함되면 실패할 수 있습니다.

로그인 페이지, 접근 확인 페이지, 일반 웹페이지가 반환된다면 요청이 예상한 구독 내용이 아닌 다른 페이지에 도달한 것입니다. 이때는 Shadowrocket에서 프로토콜을 반복해서 바꾸지 말고 서비스 제공자가 안내한 가져오기 방식과 계정 상태를 확인하세요. 인증 오류가 표시되면 주소가 초기화되었거나 만료되었는지도 확인하세요. 클라이언트는 원격 서비스에서 철회된 토큰을 복구할 수 없습니다. 서비스 제공자에게 문의할 때는 오류 상태와 발생 시간대만 알리고 전체 접속 주소를 공개 게시판에 올리지 마세요.

현재 연결이 있어야 업데이트되는지 확인하기

일부 구독 주소는 현재 기본 네트워크에서 직접 접속할 수 없지만, 사용 가능한 기존 연결을 통해서는 내용을 가져올 수 있습니다. 연결을 끊은 상태와 연결한 상태에서 업데이트 결과를 비교하고 당시 기본 서버를 기록하세요. 연결한 뒤에만 업데이트된다면 구독 다운로드 경로의 문제일 수 있습니다. 연결을 끊은 뒤에만 성공한다면 프록시 경로나 DNS 조회가 다운로드에 영향을 주는 것일 수 있습니다. 이 결과를 모든 구독에 적용하지 말고 현재 네트워크에서 해당 주소가 실제로 어떻게 작동하는지 기준으로 판단하세요.

순환 의존성이 생긴 경우 특히 주의하세요. 원격 구독에 일시적으로 접속할 수 없고 로컬 항목도 모두 유효하지 않다면 업데이트를 반복해서 눌러도 새 연결 정보가 만들어지지 않습니다. 보유한 서버 정보로 명확히 유효한 항목을 복구하거나 기존 서비스 제공자에게 접속 조건을 확인하세요. Shadowrocket은 이미 보유한 정보를 사용하는 앱이며 회선을 제공하지 않습니다. 업데이트 정책을 설정하기 전에 수동 업데이트가 가능한지 확인하고 자동 업데이트 실행 조건을 점검하세요. 자동 업데이트 실패가 곧 구독 내용 전체의 손상을 뜻하지는 않습니다.

다운로드는 성공했지만 목록이 올바르지 않다면 형식 확인하기

내용은 가져왔지만 파싱할 수 없거나 항목이 비어 있거나 프로토콜 필드가 누락된다면 구독 형식과 가져오기 경로가 맞는지 확인하세요. 서버 구독과 .conf 구성 파일은 용도가 다릅니다. 전자는 주로 서버 정보를 제공하고, 후자는 라우팅, DNS, 기타 설정도 포함할 수 있습니다. 둘을 서로 바꾸어 사용하거나 확장자가 비슷하다는 이유로 경로를 선택하지 마세요. 내용을 직접 확인할 때 인증 정보가 들어 있을 수 있으므로 구조만 살펴보고 전체 내용을 외부 도구에 복사하지 않도록 주의하세요.

업데이트 후 항목 수나 이름이 달라졌다고 해서 반드시 오류는 아닙니다. 원격 내용이 변경되었을 수 있습니다. 새 목록에 필요한 항목이 있는지 확인한 다음 기본 서버와 사용자 지정 정책 그룹이 여전히 유효한지 점검하세요. 규칙에서 이미 사라진 이름을 참조한다면 업데이트는 성공했지만 인터넷에 접속할 수 없을 수 있습니다. 이때는 다운로드를 반복하지 말고 라우팅 문제 해결을 확인하세요. 업데이트 전후 차이를 먼저 기록한 뒤 유효한 참조를 복구하면 연이어 발생한 두 문제를 하나로 오인하지 않을 수 있습니다.

문제를 해결한 뒤 복구 가능한 구성 파일 사본을 보관하고 본인의 구독 출처 정보도 안전하게 저장하세요. 백업은 공개 문서와 섞이지 않도록 보호된 위치에 보관합니다. 전체 구독 주소를 공개한 적이 있다면 기존 서비스 제공자에게 토큰 변경을 요청한 뒤 클라이언트의 주소도 업데이트하세요. 공개 스크린샷을 삭제하는 것만으로 기존 인증 정보가 무효화되지는 않습니다. 전체 가져오기 절차는 사용 안내를 참고하세요. 이 항목에서는 다운로드, 파싱, 참조 과정에서 생기는 문제를 다룹니다.

속도 저하 및 간헐적 연결 끊김: 비교 가능한 조건부터 설정

속도 저하는 첫 페이지가 열릴 때까지 오래 걸리는 현상, 낮은 다운로드 속도, 동영상의 반복적인 버퍼링, 네트워크 전환 시 일시적인 끊김을 가리킬 수 있습니다. 각각 다른 문제이므로 먼저 어떤 현상인지 구체적으로 확인한 뒤 테스트하세요. Connectivity Test의 지연 시간은 대용량 파일 전송 속도와 같지 않으며, 웹페이지가 빨리 열린다고 장시간 연결이 안정적이라고 볼 수도 없습니다. 정상적으로 접속할 수 있는 테스트 대상을 하나 정해 비슷한 조건에서 비교하세요. 서로 다른 시간, 사이트, 네트워크의 결과를 섞어 서버 성능을 판단하지 마세요.

로컬 네트워크, 서버, 대상 사이트를 나누어 확인하기

연결을 끊은 뒤 현재 Wi-Fi나 셀룰러 네트워크도 느린지 확인하세요. Wi-Fi 신호 막대는 무선 상태 일부만 보여 줄 뿐 업로드 대역폭, 혼잡, 패킷 손실까지 보장하지 않습니다. 액세스 포인트 가까이 이동하고 다른 기기의 대용량 작업을 잠시 중지한 다음 같은 대상으로 다시 테스트하세요. 직접 연결도 느리다면 먼저 로컬 네트워크를 점검해야 합니다. 이때 프록시 프로토콜을 바꾸거나 규칙을 수정해도 무선 간섭, 부족한 기본 대역폭, 완료되지 않은 네트워크 로그인을 해결하기는 어렵습니다.

기본 네트워크가 정상이라면 네트워크와 대상을 그대로 두고 이미 보유한 다른 유효 서버로만 바꿔 보세요. 서버 하나만 느리다면 해당 서버 경로, 부하, 서버 측 제한을 확인하세요. 모든 서버에서 같은 대상이 느리다면 대상 자체 또는 공통 경로 문제일 수 있습니다. 서비스 제공자에게 문의할 때 네트워크 유형, 대상 분류, 특정 접속 항목만 문제인지 알리면 됩니다. 전체 인증 정보를 보낼 필요는 없습니다. 테스트를 한꺼번에 많이 실행하면 대역폭을 차지해 결과에 영향을 줄 수 있습니다.

DNS 조회 대기, 핸드셰이크 대기, 전송 속도 구분하기

처음 열 때는 느리고 두 번째부터 빨라지는 경우 DNS 캐시, 연결 재사용, 대상 사이트 캐시의 영향일 수 있으므로 곧바로 대역폭 문제라고 단정하지 마세요. 대기가 페이지를 열기 전인지, 페이지가 로드되기 시작한 뒤인지 살펴보세요. 새 도메인 여러 개에서 시작 단계가 지연된다면 DNS를 확인하세요. DNS 조회가 끝난 뒤에도 오래 기다려야 한다면 서버 연결과 TLS 설정을 점검하세요. 로딩은 빨리 시작하지만 전송이 계속 느린 경우에는 혼잡, 서버 처리량, 대상의 제한을 확인하는 것이 적절합니다.

Config와 Proxy를 비교하면 원인을 찾는 데 도움이 됩니다. Proxy에서는 정상인데 Config에서 특정 대상만 느리다면 규칙이 요청을 다른 경로로 보내거나 사용자 지정 정책 그룹이 다른 항목을 선택했을 수 있습니다. 현재 파일과 정책 참조를 확인하세요. 기본 서버 이름이 같은지만 확인해서는 부족합니다. 대상이 DIRECT 규칙에 적용되면 목록에서 선택한 프록시 서버가 해당 요청에 사용되지 않을 수 있습니다. 기존 장기 연결이 이전 경로를 계속 사용해 잘못 판단하지 않도록 비교할 때 새 요청을 보내세요.

네트워크 전환과 장기 연결 끊김 처리하기

Wi-Fi에서 셀룰러 데이터로 전환하면 기기 주소와 네트워크 경로가 바뀔 수 있어 기존 장기 연결이 유지되지 않을 수 있습니다. 일시적인 복구 지연과 계속 재연결할 수 없는 상태는 구분해야 합니다. 전환 후 새 웹페이지는 열리지만 기존 세션만 멈췄다면 해당 세션을 다시 시작하세요. 모든 요청이 멈췄다면 Shadowrocket 연결을 끊었다가 다시 연결합니다. 네트워크 전환 때마다 반복되는지 기록하고 On Demand 조건이 두 네트워크 사이에서 계속 실행되는지 확인하세요.

실시간 통신, 게임 또는 특정 서비스에서만 끊긴다면 해당 서비스가 UDP에 의존하는지, 서버와 프로토콜, 현재 네트워크가 관련 조건을 충족하는지 확인하세요. 웹페이지가 정상이라는 이유로 전송 방식의 차이를 배제하지 마세요. 근거 없이 MTU나 기타 하위 매개변수를 바꾸지도 마세요. 조정할 이유가 있다면 기존 값을 먼저 기록하고 한 번에 하나만 변경한 뒤 같은 서비스로 테스트하세요. 개선을 확인할 수 없다면 원래 값으로 되돌려 다른 상황에 장기적인 부작용이 남지 않도록 합니다.

테스트 결과를 “같은 Wi-Fi와 같은 대상에서 서버 A만 전송이 지속적으로 실패함” 또는 “새 도메인은 처음 접속할 때 오래 걸리지만 연결 후 속도는 정상임”처럼 명확한 문장으로 정리하세요. 이런 결론은 다음에 확인할 항목을 좁혀 줍니다. 가장 빠른 수치 하나만 기록하는 것은 큰 의미가 없습니다. 반복 테스트의 안정성, 재연결 여부, 백그라운드 작업의 영향도 살펴보세요. 테스트가 끝나면 임시 탐지를 끄고 원래 Config로 복구해 진단 트래픽이 일상 사용에 영향을 주지 않도록 합니다.

DNS 문제: 이름 확인과 연결의 경계부터 확인

DNS는 도메인 이름을 연결에 필요한 주소로 변환합니다. 서버 자체가 도메인 이름을 사용할 수도 있고 대상 웹사이트가 도메인 이름을 사용할 수도 있으므로 DNS 실패는 프록시 서버 연결을 막거나 특정 웹사이트에만 영향을 줄 수 있습니다. 새 도메인이 열리지 않거나 기존 연결은 계속 작동하거나 같은 서버가 네트워크에 따라 다르게 동작하는 것이 흔한 증상입니다. 브라우저 오류 메시지는 단서가 될 수 있지만 “열리지 않음”만으로 DNS 문제라고 단정하면 안 됩니다. 먼저 기본 네트워크와 서버 포트 연결 가능 여부를 확인하세요.

정상적인 DNS 기준 상태부터 복구하기

수정 전에 현재 구성을 저장하고 [General]의 DNS 관련 기존 설정을 기록하세요. 아래 예시는 시스템 DNS를 진단의 출발점으로 사용할 뿐 모든 네트워크에 적합하거나 모든 도메인에서 정상 작동한다는 뜻은 아닙니다. 현재 네트워크에서 시스템 DNS가 정상인지 먼저 확인한 뒤 계속 사용할지 결정하세요. 확인되지 않은 DNS 설정을 여러 개 동시에 추가하지 마세요. 구성이 복잡할수록 요청이 어떤 경로를 거치는지, 실패가 DNS 서버에서 비롯되었는지 DNS 서버 연결에서 비롯되었는지 판단하기 어렵습니다.

[General]
bypass-system = true
dns-server = system

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

기존 구성에 원격 DNS, 암호화 DNS, 특정 도메인 처리 설정이 포함되어 있다면 되돌릴 때 설정 간 의존 관계를 고려해야 합니다. 한 줄만 바꾸어도 다른 구역이 계속 영향을 주면 기준 상태가 복구되지 않을 수 있습니다. 익숙하지 않은 옵션은 먼저 파일을 복사하고 테스트 구성을 별도로 만든 뒤 하나씩 제거하거나 복구하세요. 구성 구조는 .conf 파일 섹션 설명을 참고하세요. 적용 범위를 모르는 상태에서 여러 출처의 설정을 바로 합치지 마세요.

브라우저에서 IP에 직접 접속한 결과만으로 판단하지 않기

HTTPS 웹사이트는 올바른 도메인, 인증서 이름, 요청 정보가 필요할 수 있습니다. 브라우저에 IP를 직접 입력해 실패하더라도 그 사실만으로 DNS가 정상인지 비정상인지 알 수 없습니다. 특정 IP가 열려도 원래 도메인의 DNS 조회가 올바르다는 의미는 아닙니다. 앱에서 확인할 수 있는 요청이나 진단 정보를 함께 살펴 이름 조회 오류와 연결 설정 오류를 구분하고 여러 대상을 교차 확인하는 편이 안전합니다. 로그에 접속 도메인이 포함될 수 있으므로 공유할 때 필요한 부분을 가리세요.

같은 도메인에서 여러 IPv4 또는 IPv6 주소가 반환될 수 있고 네트워크에 따라 결과도 달라질 수 있습니다. 특정 네트워크에서만 계속 실패한다면 사용된 주소 유형과 연결 결과를 기록한 뒤 해당 경로를 확인하세요. IPv6가 보인다는 이유만으로 원인이라고 단정하거나 특정 주소 유형을 전역에서 비활성화하는 것을 기본 해결책으로 삼지 마세요. 진단 목적의 변경에는 비교 결과와 복구 기록이 있어야 합니다. 특정 대상의 주소 하나만 연결할 수 없다면 모든 요청을 바꾸기보다 해당 경로를 우선 확인하세요.

Host 재정의, 규칙, 캐시 영향 확인하기

[Host]에 정적 매핑이 있으면 외부 DNS가 변경된 뒤에도 특정 도메인이 이전 주소를 계속 사용할 수 있습니다. 몇몇 도메인만 문제가 있다면 관련 매핑이 있는지, 출처와 용도가 무엇인지 확인하세요. 한 번의 오류를 피하려고 장기간 사용할 IP 매핑을 임의로 추가하지 마세요. 대상 주소가 바뀔 수 있고 인증서 및 서비스 라우팅에도 영향을 줄 수 있습니다. 매핑을 잠시 제거하기 전에 백업하고, 테스트 결과가 개선되는지 확인한 뒤 영구 변경 여부를 결정하세요.

규칙도 DNS 조회 후 연결 경로를 바꿀 수 있습니다. DOMAIN 계열 규칙은 도메인으로 매칭하고 GEOIP 및 IP-CIDR 계열 규칙은 주소 관련 정보를 기준으로 판단하므로 적용 조건이 다릅니다. 도메인이 예상하지 못한 주소 범위로 확인되면 이후 정책도 달라질 수 있습니다. 따라서 “어떤 주소로 확인되었는지”와 “최종적으로 어떤 정책을 거치는지”를 함께 확인하세요. GEOIP 규칙이 있다는 이유만으로 모든 대상이 같은 방식으로 분기된다고 단정하거나, 포괄적인 규칙으로 아직 확인하지 않은 DNS 문제를 덮지 마세요.

조정 후에는 새 요청을 보내 확인해야 합니다. 기존 연결이나 캐시에 이전 결과가 잠시 남아 있을 수 있습니다. 연결을 다시 설정하고 테스트 페이지를 다시 열어 이전에 방문하지 않은 도메인과 비교하세요. 매번 기기의 네트워크 설정 전체를 초기화할 필요는 없습니다. 새 요청이 안정적인지 확인한 뒤 필요한 사용자 지정 DNS 옵션을 복구하세요. 최종 구성에는 목적이 분명한 최소한의 설정만 남기고 각 설정이 해결한 문제를 기록해 다음에 구성을 옮길 때 오래된 임시 해결책까지 함께 가져오지 않도록 합니다.

배터리 소모 및 On Demand: 지속적인 활동 원인 확인

시스템 배터리 사용량에 Shadowrocket의 활동이 표시된다고 해서 앱이 비정상 작업을 계속 수행한다고 단정할 수는 없습니다. 프록시 연결 중에는 다른 앱의 네트워크 트래픽도 해당 경로를 거치므로 사용 시간, 트래픽 양, 신호 상태, 연결이 반복해서 다시 설정되는지 함께 확인해야 합니다. 대기, 동영상 재생, 파일 전송, 네트워크 전환 중 언제 배터리 소모가 발생하는지 기록하고 비슷한 조건과 비교하세요. 날짜별 사용 환경이 크게 다를 수 있으므로 배터리 비율만으로 앱의 추가 소모량을 계산할 수 없습니다.

재연결, 탐지, 대용량 작업 먼저 확인하기

신호가 약한 네트워크에서 기기가 자주 재연결되면 연결 설정, DNS 조회, 세션 복구가 반복될 수 있습니다. 규칙을 최적화하기 전에 연결이 안정적인지 살펴보세요. 비교 테스트는 신호가 안정된 네트워크에서 진행하고, 같은 기존 서버를 사용하며, 불필요한 다운로드와 클라우드 동기화를 일시 중지하세요. 진단 중 켠 연속 탐지도 끕니다. 배터리 사용량을 확인하려고 속도 테스트를 여러 개 동시에 실행하지 마세요. 테스트 자체가 실제 트래픽을 발생시켜 관찰 조건을 바꾸므로 일상적인 대기 상태를 보여 주지 못합니다.

지속적인 로그 기록, 잦은 연결 테스트, 반복되는 연결 실패도 확인해야 합니다. 문제를 찾기 위해 기록 수준을 높였다면 진단 후 일상 설정으로 되돌리고 민감한 내용이 담긴 로그를 안전하게 처리하세요. 백그라운드에서 특정 앱이 실패하는 도메인에 계속 요청을 보내는지, 연결 불안정으로 동기화 작업이 반복되는지 살펴보세요. 이때 프록시 스위치만 원인이라고 단정하지 말고 해당 네트워크 문제를 먼저 해결해야 합니다. 요청을 발생시킨 앱과 활동 시간을 대조해야 어느 계층을 조정할지 판단할 수 있습니다.

On Demand와 수동 스위치의 관계

On Demand는 조건에 따라 연결 동작을 실행합니다. 수동으로 끈 뒤 곧바로 다시 켜진다면 스위치가 고장 났다고 보기 전에 여전히 충족되는 실행 조건이 있는지 확인하세요. 현재 규칙의 네트워크 조건과 기기가 네트워크를 자주 전환하는지 기록합니다. 비교를 위해 On Demand를 잠시 끄고 다른 설정은 그대로 둔 채 수동 연결이 안정적인지 확인할 수 있습니다. 테스트 후 필요에 따라 다시 켜고, 문제 해결 뒤 자동 연결이 꺼진 채로 남지 않도록 주의하세요.

조건을 다시 설정해야 한다면 단순하고 이해하기 쉬운 규칙부터 시작하세요. 대상 네트워크에서는 실행되고 대상이 아닌 조건에서는 실행되지 않는지 확인한 다음 조건을 추가합니다. 규칙이 서로 겹치면 예상과 시스템의 실제 판단이 달라질 수 있습니다. 네트워크 이름, 실행 동작, 서버 선택을 한꺼번에 바꾸지 마세요. 어떤 변경이 개선을 가져왔는지 알 수 없습니다. 학교나 회사에서 관리하는 기기라면 관리 정책도 확인해 시스템 강제 동작과 개인 On Demand 설정을 혼동하지 않도록 합니다.

재현 가능한 배터리 비교 테스트 진행하기

비슷한 시간대에 화면 사용량, 네트워크 유형, 서버, 백그라운드 작업을 가능한 한 동일하게 유지하고 연결 안정성, 발열 여부, 시스템에 표시되는 활동을 각각 기록하세요. 모든 기기에 적용할 수 있는 특정 비율보다 같은 양상이 반복되는지가 중요합니다. 특정 서버에서만 재연결이 잦다면 서버 시간 초과 항목을 확인하세요. Wi-Fi 전환 때만 발생한다면 네트워크 전환과 자동 연결을 점검하면 됩니다. 먼저 모든 구성을 바꿀 필요는 없습니다.

지나치게 포괄적인 규칙은 직접 처리할 수 있는 요청까지 원격 경로로 보낼 수 있지만, 조정하기 전에 기존 규칙의 의도를 파악해야 합니다. 자주 사용하는 서비스의 규칙 적용 결과를 확인하고 명백한 분기 오류를 수정하세요. 트래픽을 줄이려고 모든 요청을 임의로 DIRECT로 바꾸지 마세요. 개인정보 보호나 접속 경로가 중요한 서비스에는 필요에 맞는 정책을 유지해야 합니다. 성능 개선의 목적은 의미 없는 재시도와 잘못된 경로를 줄이는 것이지 정확성을 희생해 일시적으로 보기 좋은 통계를 만드는 것이 아닙니다.

연결을 끊은 뒤에도 발열이나 배터리 소모가 계속된다면 시스템 업데이트 작업, 다른 앱의 활동, 배터리 상태 등 시스템 측면을 확인해야 할 수 있습니다. Shadowrocket 스위치가 켜져 있는 동안 배터리 소모가 발생했다는 사실만으로 인과관계를 입증할 수는 없습니다. 안정적인 네트워크, 적은 트래픽, 진단 탐지를 끈 조건에서도 문제가 반복된다면 발생 조건과 민감한 내용을 가린 기록을 보관하고 마지막 항목에 따라 구성을 되돌리세요. 기록 없이 여러 번 재설치하는 것보다 재현 가능한 비교 한 번이 더 도움이 됩니다.

업데이트 후 오류 및 iPad: 기준 설정을 보존한 뒤 복구

“업데이트 후 문제가 시작되었다”는 것은 발생 순서를 설명할 뿐 업데이트 자체가 원인이라는 뜻은 아닙니다. 같은 시기에 구독 새로고침, 시스템 업그레이드, 기본 서버 변경, 네트워크 전환이 있었을 수 있습니다. 실제로 바뀐 항목을 나열하고 현재 구성과 오류 원문을 보관한 뒤 최소 구성으로 다시 테스트하세요. 백업 없이 앱을 삭제하지 마세요. 로컬 서버, 구성, 개인 설정이 사라질 수 있고 재설치해도 복구되지 않을 수 있습니다. 되돌릴 수 있는 작업부터 진행하고 재설치는 마지막에 고려하세요.

앱, 시스템, 구성 변경을 하나씩 분리하기

먼저 기본 네트워크가 정상인지 확인하고 이미 유효하다고 알고 있는 서버를 다시 선택한 뒤 Proxy를 잠시 사용해 실제 요청을 보내세요. 최소 구성에서 작동하면 Config, 사용자 지정 정책, DNS, On Demand를 하나씩 복구합니다. 어느 항목을 복구한 뒤 문제가 다시 발생하는지 확인하고 해당 설정을 우선 점검하세요. 최소 구성에서도 작동하지 않으면 이 페이지 앞부분의 권한, 시간 초과, DNS 진단 경로를 확인하세요. 확인되지 않은 문제가 다시 들어오지 않도록 이전 구성을 통째로 덮어쓰지 마세요.

iPhone / iPad 앱 업데이트는 App Store에서 진행하며, 시스템 요구 사항은 App Store 페이지에 표시된 내용을 따릅니다. 다시 다운로드해야 한다면 개발자 Shadow Launch Technology Limited, 공식 아이콘, 앱 ID 932747118을 확인하세요. iPhone / iPad 버전은 App Store에서 $2.99 일회성 결제로 제공되며, Mac / Windows / Android / Linux 버전은 무료입니다. 기존 구매 복원 및 플랫폼별 다운로드는 구매 항목 복원 안내를 참고하세요. 구매 상태와 로컬 설정 백업은 별도로 확인해야 합니다.

데스크톱 및 Android 재설치 시 시스템 허용 절차

Mac, Windows, Android, Linux에서 설치 파일을 다시 받아야 한다면 전체 플랫폼 다운로드로 이동해 기기를 선택하세요. 설치 파일은 사이트의 /dl/shadowrocket/ 경로에서 제공됩니다. Mac에서는 먼저 “이 Mac에 관하여”에서 칩을 확인해 Apple 실리콘과 Intel을 구분하세요. 외관만으로 판단하지 마세요. 다시 다운로드하기 전에 기존 구성을 보관하고 다운로드 출처와 대상 파일을 확인하세요. 매개변수 문제를 점검하기도 전에 설치 파일을 바꾸어 서버 문제를 해결하려고 하지 마세요.

이 플랫폼의 설치 파일에는 코드 서명이 없어 처음 실행할 때 시스템에서 차단될 수 있습니다. Windows에서 SmartScreen이 표시되면 파일이 이 사이트에서 제공된 것인지 확인한 뒤 “추가 정보 → 실행”을 선택하세요. Mac에서는 “개인정보 보호 및 보안”에서 해당 앱의 “그래도 열기”를 선택할 수 있습니다. Android에서는 실제 설치에 사용하는 앱에 대해서만 “알 수 없는 앱 설치”를 허용하고 완료 후 권한을 해제할 수 있습니다. Linux AppImage에는 실행 권한이 필요합니다. 자세한 안내와 명령은 설치 허용 안내표를 참고하세요. 파일 하나의 안내를 해결하려고 시스템 보호 기능을 전역에서 끄지 마세요.

iPad 가로 화면, 구매 상태, 설정 이전

iPad를 가로로 사용하면 목록과 상세 정보가 나란히 표시될 수 있습니다. 편집 중인 항목과 현재 기본 서버가 같은지 먼저 확인하세요. 항목의 상세 정보를 열었다고 해서 해당 항목이 기본 서버로 선택된 것은 아닙니다. 세로와 가로 화면을 전환한 뒤에도 Home에 표시된 실제 선택 항목과 연결 상태를 기준으로 판단하세요. 상세 화면이 어떤 항목에 열려 있는지만 보고 연결 대상을 추측하지 마세요. 레이아웃이 바뀌어 기능을 찾기 어렵다면 목록 단계로 돌아간 뒤 빠른 시작 안내에 따라 하나씩 확인하세요.

iPhone에서 이미 구매했다면 iPad의 App Store에서 최초 구매에 사용한 Apple ID로 구매 항목을 확인하세요. 앱 구매 복원만으로 서버 정보와 .conf 파일이 모두 자동 이전되는 것은 아닙니다. 두 기기에서 연결이 가능한지는 각 기기의 구독, 기본 서버, 라우팅 모드, 시스템 권한을 따로 확인해야 합니다. 다른 기기에서 정상이라고 해서 현재 기기의 권한 및 네트워크 진단을 건너뛰지 마세요. 설정을 이전할 때 필요한 항목만 먼저 가져와 연결을 테스트한 뒤 추가 설정을 복구하세요. 알 수 없는 차이를 한꺼번에 옮기지 않도록 합니다.

같은 Wi-Fi에서 iPad와 iPhone의 결과가 다르다면 두 기기가 실제로 사용하는 구성과 DNS 설정을 먼저 비교한 다음 셀룰러 데이터, 자동 연결 조건, 시스템 관리 정책이 다른지 확인하세요. 구성이 일치하는지 확인한 뒤 같은 서버와 같은 대상으로 다시 테스트합니다. 설정 파일과 QR 코드에 인증 정보가 포함될 수 있으므로 보호된 개인 전송 수단을 사용하고 완료 후 임시 복사본을 삭제하세요. 화면 구성과 구매 관련 자세한 내용은 iPad 사용 및 설정 이전 안내를 참고하세요.