Shadowrocket 문제 해결
연결·구독·DNS 점검

01 · 연결이 설정되지 않음

스위치가 켜지지 않음: 권한과 연결 상태 확인

스위치가 전혀 반응하지 않는 경우, 누른 직후 꺼지는 경우, 연결 표시 후 끊기는 경우를 먼저 구분하세요. 앞의 두 경우는 기기 권한이나 설정 문제일 가능성이 높고, 마지막 경우는 네트워크 전환이나 On Demand 작동과 관련될 수 있습니다. 시스템 연결이 설정되기 전에 서버 비밀번호를 반복해서 바꾸지 마세요. 원격 서버 설정이 이번 실패에 관여하지 않았을 수도 있습니다. 먼저 팝업 문구, 발생 시각, 스위치 상태를 기록한 다음 시스템 설정에 해당 연결 기록이 있는지 확인하세요.

최초 권한 요청 및 기존 연결 기록

처음 켤 때 시스템에서 VPN 구성을 추가하도록 허용하고 기기 인증을 완료하라는 메시지가 표시될 수 있습니다. 이는 기기의 네트워크 연결을 제어하기 위한 권한이며 구독 로그인과는 다릅니다. 방금 직접 실행한 Shadowrocket에서 요청한 것이 맞는지 확인한 뒤 시스템 안내에 따라 진행하세요. 취소했다면 앱으로 돌아가 다시 켜고 요청을 확인하면 됩니다. 학교나 회사에서 관리하는 기기라면 관리 정책에 따라 제한될 수 있습니다. 구독을 변경해 우회하지 말고 기기 관리자에게 해당 네트워크 구성의 허용 여부를 확인하세요.

이미 권한을 허용했는데도 스위치가 즉시 꺼진다면, 네트워크를 제어 중인 다른 VPN 연결을 먼저 중단한 뒤 Shadowrocket에서 다시 테스트하세요. 시스템 목록에 여러 구성이 있어도 동시에 활성화된다는 뜻은 아니며 모두 삭제해야 한다는 뜻도 아닙니다. 현재 활성 항목과 출처를 확인하고, 출처가 분명하며 실제로 문제가 있는 항목만 처리하세요. 시스템 연결 기록을 삭제하기 전에는 앱 안의 구성을 보존하세요. 다시 연결을 만들 때는 앱에서 직접 권한 요청을 시작하고, 출처가 불분명한 프로파일은 설치하지 마세요.

목록이 아니라 현재 선택 항목 확인

Home에서 사용자가 보유한 유효한 서버 정보 하나가 선택되어 있는지 확인하세요. 목록에 여러 이름이 있다는 것만으로 현재 선택이 올바르다고 볼 수는 없습니다. 이어서 Config에서 실제로 활성화된 구성 파일을 확인하세요. 파일을 가져온 직후 문제가 발생했다면, 모든 규칙을 지우기보다 정상적으로 시작되던 이전 구성 사본으로 되돌린 다음 새로 추가된 정책 이름, 참조 관계, 문법을 비교하세요. 파싱 오류가 표시되면 오류가 난 줄 주변의 내용을 보존하고 불필요한 문장 부호나 미완성 구문이 있는지 살펴보세요.

스위치를 껐는데 다시 자동으로 켜진다면 On Demand가 계속 작동하는지 확인하세요. 원인을 분리하기 위해 관련 조건을 잠시 끄고 수동으로 연결해 볼 수 있습니다. 이는 작동 조건을 확인하기 위한 조치이지, 계속 비활성화하라는 뜻은 아닙니다. 수동 연결이 안정적이면 On Demand 설정을 복원하면서 네트워크 유형과 일치 조건을 하나씩 확인해 자동 재연결을 버튼 오류로 오해하지 않도록 하세요. 시스템의 다른 연결 구성에 자동 연결 조건이 설정되어 있는지도 함께 확인하세요.

재시작 및 연결 재설정이 필요한 경우

위 항목을 확인했는데도 시작되지 않으면 앱을 정상적으로 종료하고 기기를 재시작한 다음 안정적인 네트워크에서 다시 테스트하세요. 재시작으로 일시적인 상태는 해결될 수 있지만 잘못된 구성 문법까지 고쳐지지는 않습니다. 시스템 연결 기록을 다시 만들어야 한다면 구독, 개별 서버 항목, 현재 Config를 복원할 수 있는 사본으로 보존했는지 먼저 확인하세요. 앱 삭제를 첫 번째 조치로 삼지 마세요. 기기에만 저장된 개별 항목은 구독에서 다시 가져오지 못할 수 있고, 사진에 저장된 QR 코드도 더 이상 유효하지 않을 수 있습니다.

스위치가 꺼질 때 네트워크 전환, 화면 잠금 또는 시스템 안내가 함께 있었는지 기록하세요. 매번 같은 동작 직후 발생한다면 해당 경로를 중심으로 확인하고, 특정 구성에서만 발생하면 정상 작동하는 구성 파일을 비교용으로 보관하세요. 이 장의 점검 완료 기준은 시스템 연결이 설정되어 유지되는지 여부이지, 웹페이지가 반드시 열리는지가 아닙니다. 스위치가 안정적으로 연결되는데 요청이 실패한다면 권한 확인을 반복하지 말고 다음 장으로 넘어가세요.

02 · 연결됨

인터넷에 접속할 수 없음: 기본 네트워크, 경로, 요청을 나눠 점검

연결 상태는 기기에서 연결을 제어하기 시작했다는 뜻입니다. 선택한 서버가 대상에 연결될 수 있다거나 DNS, 규칙, 대상 서비스가 모두 정상이라는 뜻은 아닙니다. 먼저 연결을 중단하고 기존 네트워크에서 평소 직접 접속할 수 있던 페이지를 열어 Wi-Fi 로그인이 끝났는지, 셀룰러 데이터가 작동하는지 확인하세요. 연결을 꺼도 접속할 수 없다면 라우터, 신호 또는 네트워크 인증부터 해결하세요. 이때 프록시 설정을 반복해서 바꾸면 기본 네트워크 문제와 앱 문제를 구분하기 어려워집니다.

세 가지 모드로 제한 비교하기

Global Routing의 Config, Proxy, Direct는 각각 구성 규칙, 프록시 경로, 직접 연결을 뜻합니다. Config는 현재 구성의 규칙에 따라 경로를 선택하고, Proxy는 프록시 경로를 기준으로 비교하며, Direct는 직접 연결을 기준으로 비교합니다. 테스트 전에 원래 모드를 기록하고 같은 네트워크, 대상, 선택된 서버를 사용하세요. Proxy 모드라고 서버 문제가 해결되는 것은 아니며 Direct 모드라고 모든 대상에 접속할 수 있는 것도 아닙니다. 이 비교의 목적은 실패 범위를 좁히는 것입니다.

Proxy에서는 정상인데 Config에서 실패하더라도 규칙 문제를 가리기 위해 Proxy를 계속 사용하지 마세요. 요청 기록에서 방금 테스트한 대상 도메인을 찾아 최종 정책이 예상과 일치하는지 확인하세요. 규칙에서 참조하는 정책 이름이 실제로 있어야 하며, 이름이 비슷하다고 같은 항목으로 볼 수는 없습니다. 대상 페이지는 로그인, 이미지, API 등 여러 도메인에 의존할 수 있습니다. 주요 문서가 열렸다고 관련 요청도 모두 같은 경로를 사용한 것은 아닙니다.

전체 실패와 일부 실패 구분

특정 앱에서만 문제가 생기면 앱을 완전히 종료했다가 다시 열고 새 연결 기록이 생성되는지 확인하세요. 일부 앱은 기존 연결을 재사용하므로 규칙을 바꾼 직후 새로고침해도 새 정책이 적용되지 않을 수 있습니다. 브라우저는 정상인데 앱 하나만 실패한다면 해당 앱이 사용하는 도메인, 시스템 네트워크 권한, 서비스 상태를 확인하세요. 앱 하나의 오류만으로 서버 연결 전체가 끊겼다고 판단하지 말고, 특정 대상 때문에 모든 요청을 같은 경로로 고정하지도 마세요.

Wi-Fi와 셀룰러 네트워크를 한 번 비교하면 로컬 네트워크나 접속 경로의 차이를 찾는 데 도움이 됩니다. 네트워크를 바꿀 때는 먼저 연결을 중단하고 새 네트워크가 작동하는지 확인한 뒤 다시 연결해 같은 대상을 요청하세요. Wi-Fi에서만 문제가 생기면 인증 페이지, 라우터 DNS, 로컬 네트워크 제한, IP 주소 충돌을 확인하세요. 셀룰러에서만 문제가 생기면 앱의 셀룰러 데이터 권한과 신호 상태를 확인하세요. 비교 중에는 선택된 항목이 바뀌지 않도록 구독을 업데이트하지 마세요.

로그와 테스트 동작 연결하기

테스트 전에 시각을 기록하고 대상 요청을 한 번만 보낸 다음, 해당 시점 주변의 로그에서 도메인, 적용된 규칙, 최종 정책, 오류 발생 단계를 확인하세요. 로그에 DNS 조회 실패만 있다면 DNS 장으로 이동하세요. 원격 핸드셰이크가 시작됐다면 프로토콜 설정을 확인하세요. 대상에서 접근 거부나 로그인을 요구했다면 적어도 일부 데이터 전송은 이루어진 것이므로 인터넷에 전혀 연결되지 않는다고 단정할 수 없습니다. 오류 문구는 원인을 찾기 위한 단서이지 모든 설정을 바꾸라는 지시가 아닙니다.

복구할 때는 원래 Global Routing 모드로 되돌린 뒤 필요한 변경만 유지하세요. 규칙이나 자동 실행 조건을 임시로 껐다면 이유를 기록해 테스트 상태가 일상 설정으로 남지 않게 하세요. 원인을 찾기 어렵다면 민감한 정보를 가린 오류 요약과 네트워크 비교 결과를 정리한 뒤 자주 묻는 질문을 확인하세요. “연결됨, 그런데 작동하지 않음”이라고만 적는 것보다 이러한 정보가 문제가 발생한 단계를 파악하는 데 도움이 됩니다.

03 · 원격 연결 실패

서버 시간 초과: 테스트 방식과 프로토콜 설정을 나눠 확인

시간 초과는 작업이 제한 시간 안에 완료되지 않았다는 뜻입니다. 지연 시간 테스트, 전송 연결 설정, 프로토콜 핸드셰이크, 테스트 대상 접속 중 어느 단계에서 발생했는지는 다를 수 있습니다. 먼저 시간 초과가 Home의 테스트 결과인지 실제 사용 중 요청 로그에 기록된 것인지 확인하세요. 테스트 대상에 연결할 수 없어 항목이 실패로 표시되더라도 다른 서비스는 접속될 수 있습니다. 반대로 테스트에 응답이 왔다고 모든 서비스 요청이 정상인 것도 아닙니다. 테스트 결과를 실제 대상 요청과 함께 확인하세요.

서버 주소와 포트부터 확인

선택한 항목의 편집 화면을 열고 사용자가 보유한 원본 서버 정보와 주소 및 포트를 대조하세요. 주소 필드에 웹 경로, 앞뒤 공백, 포트 구분 기호가 잘못 들어가 있지 않아야 하며, 포트는 원본 설정과 일치해야 합니다. 흔히 쓰이는 숫자를 보고 추측하지 마세요. 서버가 도메인으로 지정되어 있다면 도메인 조회가 되는지 확인하고, IP 주소라면 주소 체계를 구분하세요. 서버 측에서 도메인이 변경된 직후라면 로컬 캐시나 기존 연결이 이전 주소를 유지할 수 있으므로 연결을 다시 설정한 뒤 확인하세요.

한 항목만 시간 초과되고 다른 기존 항목은 정상이라면 해당 항목의 설정이나 원격 서버 상태 문제일 가능성이 높습니다. 같은 출처의 모든 항목이 동시에 실패한다면 기본 네트워크, 구독 만료 여부, 원격 서버 변경 여부를 확인하세요. 이미 보유한 다른 항목으로 비교할 수는 있지만, 여러 항목을 연속으로 대량 테스트하는 것을 해결 방법으로 삼지 마세요. 지나치게 자주 테스트하면 부하가 늘고 실제 문제와 무관한 요청이 로그에 섞일 수 있습니다.

핸드셰이크 설정을 함께 확인

프로토콜 유형이 잘못 선택되면 주소와 포트가 정확해도 핸드셰이크가 완료되지 않을 수 있습니다. Shadowsocks의 암호화 방식과 비밀번호, VMess 및 VLESS의 인증 정보, Trojan 비밀번호, 전송 관련 항목을 원본 설정과 하나씩 대조하세요. 한 프로토콜의 항목을 다른 프로토콜에 그대로 옮기지 마세요. TLS나 특정 전송 방식을 사용한다면 서버 이름, 경로, 관련 헤더 필드도 함께 확인하세요. 도메인처럼 보이는 값 하나만 남겨서는 충분하지 않습니다.

로그에 인증서 관련 오류가 표시되면 먼저 기기의 날짜와 시간을 확인한 뒤 서버 이름이 설정 요구 사항과 일치하는지, 마지막으로 서버 인증서 상태를 확인하세요. 오류 메시지를 없애기 위해 검증 조건을 계속 완화하지 마세요. 설정에서 UDP 전송을 사용하는 경우 현재 네트워크가 해당 트래픽을 허용하는지도 결과에 영향을 줍니다. 현재 네트워크에서 특정 전송 방식이 실패한다고 프로토콜 이름만 바꾸면 해결되는 것은 아니며, 서버도 해당 설정을 실제로 지원해야 합니다.

실패 단계에 따라 다음 조치 선택

서버 도메인을 확인할 수 없다면 로컬 DNS 경로를 점검하세요. 도메인은 확인되지만 연결 설정이 시간 초과되면 접속 네트워크와 원격 서버의 수신 상태를 확인하세요. 연결이 즉시 거부되면 포트와 서버 상태를 먼저 확인하고, 연결은 됐지만 인증에 실패하면 인증 정보를 대조하세요. 구현 방식마다 로그 표현이 다를 수 있으므로 앞뒤 기록을 함께 보고 영어 단어 하나만으로 판단하지 마세요. 특정 네트워크에서만 오류가 발생한다면 네트워크 비교 결과를 보관하세요.

구독 관리에 포함된 항목을 직접 수정하면 다음 업데이트에서 원래 값으로 덮어쓸 수 있습니다. 임시 비교가 필요하다면 별도의 테스트 항목으로 복사해 알아보기 쉽게 이름을 지정하세요. 수정이 저장되지 않았다고 오해하는 일을 막을 수 있습니다. 확인이 끝나면 더 이상 필요 없는 테스트 사본을 삭제하고 출처가 분명한 정식 항목만 남기세요. 복구 기준은 필요한 서비스 요청이 성공하고 로그에 예상한 정책이 표시되는 것이지, 테스트 수치가 낮아지는 것이 아닙니다.

04 · 가져오기와 파싱을 나눠 확인

구독 업데이트 실패: 가져오기, 파싱, 덮어쓰기 구분

구독 업데이트 실패는 서로 다른 두 경로에서 발생할 수 있습니다. 앱이 응답을 받지 못했거나 응답은 받았지만 콘텐츠를 파싱하지 못한 경우입니다. 목록이 비어 있어도 필터, 접힌 그룹, 업데이트 후 이름 변경 때문일 수 있습니다. 기존 구독과 정상 작동하는 항목을 보존하고 삭제 후 다시 추가하는 일을 반복하지 마세요. 업데이트 전 그룹 상태, 오류 메시지, 현재 네트워크를 기록한 뒤 Home에서 수동 업데이트를 한 번 실행해 네트워크 요청 단계와 가져오기 단계 중 어디서 문제가 생기는지 확인하세요.

링크가 완전하고 용도에 맞는지 확인

사용자가 이용 중인 설정 제공자의 계정에서 구독 링크를 다시 복사하고 앞뒤 공백, 줄바꿈, 메신저가 덧붙인 문장 부호가 없는지 확인하세요. 접근 권한을 구분하는 매개변수가 빠지지 않았는지 확인하고, 특정 매개변수 뒤의 내용을 메모라고 생각해 삭제하지 마세요. 웹 관리 주소, 로그인 페이지 주소, 구독 주소는 용도가 다릅니다. 웹페이지가 열린다고 가져올 수 있는 구독 콘텐츠라는 뜻은 아닙니다. QR 코드에 구독 주소가 들어 있는지, 단일 서버 정보가 들어 있는지도 확인하세요.

오류 메시지가 인증, 권한 또는 콘텐츠 없음과 관련되어 있다면 기존 계정 페이지에서 링크가 유효한지, 접근 권한이 바뀌었는지, 새 링크가 필요한지 확인하세요. 새 링크로 바꾸면 이전 링크가 무효화될 수 있으므로 업데이트 전에 영향을 받는 기기를 확인하세요. 접근 매개변수가 포함된 주소를 공개 게시판, 온라인 변환 페이지, 출처 불명의 검사 도구에 붙여넣지 마세요. 다른 사람에게 문제를 설명할 때는 도메인, 오류 유형, 매개변수 이름만 남기고 매개변수 값은 가리세요.

응답을 받았다고 올바른 형식이라는 뜻은 아님

요청이 성공한 것처럼 보여도 본문이 실제로는 로그인 페이지, 접근 안내 또는 일반 웹페이지일 수 있습니다. 이 경우 네트워크 전송은 완료된 것이므로 DNS를 계속 바꿔 파싱 문제를 해결하려 하지 마세요. 지원되지 않는 형식이나 일부 항목을 인식할 수 없다는 메시지가 표시되면 제공된 콘텐츠가 Shadowrocket용인지 확인하고 단일 서버 공유 정보, 서버 목록, Config 구성 파일을 구분하세요. 가져오기 방식마다 용도가 다르므로 모두 텍스트라고 해서 서로 바꿔 쓸 수는 없습니다.

업데이트 후 일부 항목만 사라졌다면 해당 항목이 다른 프로토콜이나 새 설정을 사용하는지 확인한 뒤 원본 안내와 대조하세요. 이름이 바뀌면 이전 정책 그룹이 구 이름을 계속 참조해 목록에는 항목이 있지만 규칙에서 선택할 수 없는 상황이 생길 수 있습니다. 구독 콘텐츠, 그룹 필터, Config의 정책 참조를 나눠 점검하세요. 직접 필터를 설정했다면 필터를 잠시 해제해 전체 목록을 확인하고 하나씩 복원하세요. 원격 서버가 콘텐츠를 보내지 않았다고 바로 판단하지 마세요.

업데이트 요청이 사용하는 경로 확인

구독 주소도 네트워크 요청이므로 현재 네트워크와 설정에 따라 가져오기 경로가 달라질 수 있습니다. 선택한 서버가 이미 작동하지 않는데 업데이트 요청도 그 서버에 의존한다면 스스로 복구할 수 없는 상태가 될 수 있습니다. 먼저 기본 네트워크가 작동하는지 확인하고, 사용할 수 있다고 확인된 경로로 가져오기를 시도하면서 원래 모드를 기록하세요. 현재 경로가 요청을 막는다고 확인된 경우에만 임시로 전환하세요. 모든 구독을 특정 경로로 고정하거나 Direct 또는 Proxy에서 반드시 가져올 수 있다고 단정하지 마세요.

수동 업데이트가 성공한 뒤 항목이 모두 있는지, 현재 선택 항목이 유지됐는지, 구성의 이름 참조를 조정해야 하는지 확인하세요. 자동 업데이트가 문제라면 당시 기기가 오프라인이었는지, 앱이 업데이트를 실행할 수 있었는지, 시스템 제한이 있었는지도 확인하세요. 자동 업데이트가 실행되지 않은 경우와 서버가 빈 콘텐츠를 반환한 경우를 혼동하지 마세요. 업데이트 간격을 지나치게 줄여도 권한이나 형식 문제는 해결되지 않으며 같은 실패 요청만 반복될 수 있습니다.

구독을 다시 설정해야 한다면 먼저 개별 서버 항목과 현재 Config를 저장하고 기존 그룹의 용도를 기록하세요. 새 구독을 가져온 뒤 항목 하나로 연결을 확인하고 기존 정책 참조를 조정한 다음 중복 그룹을 제거하세요. 완전한 복구는 업데이트 버튼의 오류가 사라지는 데 그치지 않습니다. 예상한 항목이 나타나고 현재 선택이 올바르며 규칙에서 해당 항목을 참조할 수 있어야 합니다. 기본 가져오기 절차는 사용법 안내를 확인하고, 이 장에서는 각 실패 원인을 점검하세요.

05 · 요청이 완료될 수 있음

속도 저하 및 연결 끊김: 비교 가능한 조건부터 마련

속도 저하는 하나의 지표로 설명할 수 없습니다. 페이지가 처음 열릴 때 오래 기다리는 현상, 다운로드 속도 저하, 동영상 버퍼링, 연결 도중 끊김은 서로 다른 단계에서 발생할 수 있습니다. 가장 안정적으로 재현되는 증상을 정하고 익숙한 합법적 대상 하나를 선택해 같은 네트워크와 비슷한 시간대에 몇 차례만 테스트하세요. 서로 다른 웹사이트, 파일 크기, 화질의 결과를 바로 비교하지 말고 지연 시간 테스트만으로 장시간 전송 성능을 판단하지도 마세요.

DNS, 핸드셰이크, 전송 단계별로 대기 시간 확인

처음 열 때만 느리고 이후에는 정상이라면 DNS와 새 연결 설정을 먼저 확인하세요. 페이지는 빠르게 나타나지만 대용량 파일 전송이 계속 느리다면 대역폭, 혼잡, 대상 서비스 제한을 확인하세요. 일정 시간마다 멈췄다가 다시 작동한다면 네트워크 전환, 무선 신호, 장시간 연결 재설정을 살펴보세요. 로그에서 요청이 계속 재시도되는지는 확인할 수 있지만, 클라이언트 로그만으로 원격 경로 각 구간의 대역폭을 정확히 계산할 수는 없습니다.

테스트할 때 클라우드 동기화, 시스템 다운로드, 대용량 업로드처럼 점검과 무관한 대용량 작업을 일시 중지하세요. 업로드가 사용 가능한 회선을 가득 채우면 일반 페이지의 응답도 느려질 수 있습니다. 이어서 기기를 같은 위치에 두고 이미 보유한 다른 서버 정보 하나와 비교하세요. 항목만 바꾸고 DNS, 규칙, 프로토콜 설정은 동시에 수정하지 마세요. 모든 항목이 한꺼번에 느려진다면 서버를 모두 변경하기 전에 로컬 접속 네트워크를 확인하세요.

무선 네트워크와 대상 서비스를 각각 비교

Wi-Fi 신호가 강해 보여도 채널 혼잡, 라우터 부하, 업로드 회선이 정상이라고 단정할 수는 없습니다. 라우터 가까이에서 다시 테스트하고 가능하면 셀룰러 네트워크와 비교하세요. 네트워크를 바꾼 뒤에는 연결을 다시 설정해야 합니다. 이전 연결의 실패 결과로 새 네트워크를 평가하지 마세요. 특정 Wi-Fi에서만 느리다면 라우터나 네트워크 관리 제한을 확인하세요. 근거 없이 기기의 모든 네트워크 설정을 초기화하지 마세요.

특정 웹사이트만 느리고 비슷한 다른 요청은 정상이라면 콘텐츠 전송, 계정 상태 또는 현재 접속 경로에 대한 제한이 원인일 수 있습니다. 먼저 실패한 도메인에 실제로 어떤 정책이 적용됐는지 확인해 페이지 본문과 다른 경로로 잘못 전달되지 않았는지 살펴보세요. 미디어 리소스와 메인 페이지가 서로 다른 도메인을 사용할 수 있습니다. 규칙은 파악된 요청 특성에 따라 결정되며 페이지 모양만으로 어떤 리소스가 같은 경로를 써야 하는지 알 수 없습니다. 규칙을 변경한 뒤에는 새 연결을 만들어 확인하세요.

연결 끊김, UDP, 패킷 크기 문제

텍스트 페이지는 열리지만 실시간 서비스가 실패한다면 해당 서비스가 UDP에 의존하는지, 현재 프로토콜과 네트워크 경로가 필요한 트래픽을 지원하는지 확인하세요. 관련 옵션을 하나 켰다고 서버에서 지원하게 되는 것은 아닙니다. 짧은 요청은 정상인데 큰 요청에서 멈춘다면 패킷 크기와 경로 특성도 확인할 수 있지만, 출처를 모르는 수치를 그대로 고정값으로 사용하지 마세요. 설정을 실험할 때는 원래 값을 기록하고 한 번에 한 항목만 바꾼 뒤 즉시 되돌릴 수 있도록 준비하세요.

장시간 연결이 끊기는 원인은 화면 잠금, Wi-Fi 전환, 원격 서버 시간 초과, 시스템 리소스 부족 등일 수 있습니다. 끊기기 전후 시각과 기기 동작을 기록해 같은 조건에서 반복되는지 확인하세요. 접속 지점이 바뀔 때마다 끊긴다면 재연결 후 복구되는지 먼저 확인하세요. 사용 중 네트워크가 그대로인데도 계속 연결이 다시 설정된다면 원격 핸드셰이크와 대상 응답 오류를 확인하세요. 이런 상황을 모두 속도 저하라고만 부르면 실제 원인을 놓칠 수 있습니다.

복구 후에는 네트워크 유형, 현재 항목, Global Routing 모드, 대상 유형, 관찰된 증상을 기준선으로 기록하세요. 오랫동안 연속 테스트하거나 테스트를 위해 대량의 데이터를 반복해서 사용하지 마세요. 네트워크 외부 환경이나 대상 서비스 때문에 속도가 달라질 수 있으며 앱 설정만으로 이를 없앨 수 있는 것은 아닙니다. 이 장의 목표는 원인이 어디에 있는지 구분하고 설정으로 개선 가능한 부분을 찾는 것이지, 일정한 속도나 연결 시간을 보장하는 것이 아닙니다.

06 · DNS 조회 및 규칙 매칭

DNS 문제: 조회 결과를 확인한 뒤 규칙 경로 점검

DNS는 도메인을 IP 주소로 변환하고, 규칙은 요청에 적용할 정책을 정합니다. 서로 관련은 있지만 같은 단계는 아닙니다. 도메인 조회 실패, 예상과 다른 결과, 잘못된 경로를 통한 연결 모두 웹페이지가 열리지 않는 원인이 될 수 있습니다. 먼저 같은 실패 요청의 도메인과 오류 단계를 확인해 주소를 받지 못한 것인지, 주소를 받은 뒤 연결이 실패한 것인지 구분하세요. 한 번 페이지가 복구됐다고 특정 DNS 주소가 모든 네트워크에 적합하다고 단정하지 마세요.

DNS 경로가 자기 자신에 의존하지 않도록 확인

방금 편집한 파일만 보지 말고 현재 Config와 Settings에서 실제로 적용 중인 DNS 설정을 확인하세요. DNS 서버 자체가 도메인으로 지정되어 있다면 먼저 작동하는 기본 조회 경로가 필요합니다. DNS 요청이 아직 설정되지 않은 프록시를 거쳐야 한다면 시작 단계에서 의존성이 생길 수 있습니다. 점검할 때 기존 구성을 보존하고 DNS 서버 주소와 접근 경로에 연결할 수 있는지 확인하세요. 출처가 불분명한 DNS 구문을 여러 개 한꺼번에 추가하면 어느 설정이 다른 설정을 덮어쓰는지 알기 어려워집니다.

같은 도메인에서 IPv4 또는 IPv6 주소가 여러 개 반환될 수 있으며 네트워크에 따라 각 주소의 연결 가능 여부가 달라질 수 있습니다. 일부 요청만 실패한다면 한 가지 주소 체계를 전역으로 비활성화하기 전에 실제로 어떤 주소 체계가 사용됐는지 확인하세요. 서버 도메인 조회와 대상 서비스 도메인 조회도 구분해야 합니다. 서버 도메인 조회가 실패하면 프록시 연결 자체를 만들 수 없지만, 대상 도메인 조회가 실패하면 특정 서비스만 영향을 받을 수 있습니다. 변경 후에는 새로 연결해 이전 캐시가 변화를 가리지 않도록 하세요.

최소 규칙 예제로 매칭 방식 확인

아래 규칙은 순서를 설명하기 위한 예시이며 기존 파일을 그대로 덮어쓸 수 있는 완성된 구성은 아닙니다. PROXY가 가리키는 정책은 현재 구성에 존재하고 유효해야 합니다. 규칙은 위에서 아래로 적용되며, 앞선 규칙에 매칭되지 않을 때 처리할 항목으로 FINAL을 마지막에 둡니다. 앞쪽에 배치하면 뒤의 규칙이 적용되지 않을 수 있습니다. 도메인 예시는 문법 설명용이며 실제 서비스의 권장 경로를 뜻하지 않습니다.

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

요청이 REJECT에 매칭되면 먼저 의도된 구성인지 확인하세요. 도메인 규칙은 조건에 맞는 요청을 거부할 수 있지만 페이지의 모든 콘텐츠를 이해하지는 못하며 특정 리소스가 항상 같은 주소를 사용한다고 보장하지도 않습니다. 잘못 차단됐다면 모든 규칙을 삭제하지 말고 해당 규칙의 범위를 좁히세요. 규칙 순서와 기능의 범위는 REJECT 규칙 안내에서 확인하고 로그로 실제 매칭 항목을 검증하세요.

설정 복원 및 캐시 확인

DNS나 규칙을 변경한 뒤에는 연결을 중단했다가 다시 설정하고 테스트 앱도 다시 열어 새 요청이 발생했는지 확인하세요. 앱이 주소를 캐시하거나 기존 연결을 재사용할 수 있으므로 새로고침 한 번으로 새 설정이 적용됐다고 볼 수는 없습니다. 캐시를 지우기 위해 앱부터 삭제하지 말고 영향이 적은 재연결과 앱 재실행을 먼저 시도하세요. 특정 로컬 네트워크에서만 실패한다면 해당 네트워크에 별도의 DNS 설정이나 내부 도메인이 필요한지도 확인하세요.

검증하려면 DNS 조회가 완료되고 예상한 규칙에 매칭되며 대상 요청까지 성공해야 합니다. 변경 후 실패 단계가 DNS 조회에서 핸드셰이크로 옮겨갔다면 아직 해결되지는 않았지만 원인 파악은 진전된 것입니다. 변경 전후의 설정 차이를 보존하고 도움이 되지 않은 시도는 되돌려 서로 덮어쓰는 DNS 설정이 쌓이지 않게 하세요. 자주 쓰이는 키워드의 의미는 용어집에서, 설정 위치는 설정 안내에서 확인하세요.

07 · 상태 변화 후 발생한 오류

배터리 소모 및 업데이트 오류: 기준선을 보존하고 차이 비교

배터리 소모 증가와 업데이트 후 오류를 점검하려면 정상 작동 시점의 기준선이 필요합니다. 시스템 배터리 통계의 비율은 상대값이며 같은 사용 조건에서 실제로 얼마나 더 소모됐는지를 뜻하지 않습니다. 오류 전에 업데이트가 있었다고 해서 업데이트가 원인인 것도 아닙니다. 먼저 기기 사용 시간, 화면 상태, 네트워크 유형, 백그라운드 작업을 기록한 다음 마지막 정상 작동 시점의 구성, 구독, 시스템 변경 사항을 확인하세요. 구성을 되돌리고 구독을 다시 설정하고 네트워크까지 초기화하는 일을 동시에 하지 마세요. 원인을 판단할 근거가 사라질 수 있습니다.

정상 전송과 반복 실패 구분

지속적인 업로드, 동영상 재생, 클라우드 동기화는 네트워크 활동을 늘립니다. Shadowrocket이 트래픽을 처리하면 관련 활동이 시스템 통계에 나타날 수도 있습니다. 짧은 대기 상태와 하루 전체 통계를 단순 비교하지 말고 비슷한 사용 시간끼리 비교하세요. 화면이 꺼져 있을 때 주로 문제가 생긴다면 계속 실패하고 재시도하는 연결, 지나치게 잦은 테스트, 업데이트 작업이 있는지 확인한 뒤 로그로 반복 활동 여부를 살펴보세요.

디버그 수준 로그를 잠시 끄고 불필요한 연속 테스트를 중단하면 추가 부하를 줄이는 데 도움이 될 수 있습니다. 다만 현재 문제와 관련된 로그는 먼저 저장하세요. 불안정한 네트워크에서 On Demand가 반복적으로 재연결을 시도하는지, 기기가 Wi-Fi와 셀룰러 사이를 자주 오가는지도 확인하세요. 배터리 통계의 비율을 낮추기 위해 필요한 기능을 계속 중단하지 말고, 어떤 활동이 추가 소모와 지속적으로 관련되는지 확인한 다음 해당 조건만 조정하세요.

업데이트 후 세 가지 변화부터 확인

첫째, 앱이나 시스템 업데이트로 연결 상태가 달라져 권한을 다시 확인하거나 연결을 다시 설정해야 할 수 있습니다. 둘째, 구독 콘텐츠가 바뀌어 기존 항목이나 정책 이름이 더 이상 없을 수 있습니다. 셋째, Config가 업데이트되어 규칙, DNS, 외부 참조가 이전 파일과 달라졌을 수 있습니다. 실제로 어떤 변화가 있었는지 파악한 뒤 해당 장을 확인하세요. 특정 파일에서만 문제가 생겼다면 저장해 둔 구성 사본을 복원하는 것이 파일 차이에서 비롯된 문제인지 확인하는 데 재설치보다 효과적입니다.

업데이트 전에는 현재 Config, 개별 서버 항목, 필요한 그룹 관계를 저장하고 백업을 읽을 수 있는지 확인하세요. 구독 링크가 완전한 백업은 아닙니다. 개별 항목, 수동 규칙, 일부 기기 설정은 구독에 포함되지 않을 수 있습니다. 업데이트 후에는 기존 선택을 유지한 채 자주 쓰는 대상 하나를 확인하고 나서 자동 업데이트나 일괄 작업을 다시 활성화하세요. 문제가 생겨도 변경 범위가 작아 여러 설정이 한꺼번에 덮어쓴 상태가 아니라 항목별로 비교할 수 있습니다.

앱을 다시 설치할 때 확인할 사항

앱을 다시 받아야 한다면 iPhone / iPad에서는 App Store에서 개발자 Shadow Launch Technology Limited, 공식 아이콘, 앱 ID 932747118을 확인하세요. 시스템 요구 사항은 App Store 페이지 표기를 기준으로 합니다. Mac은 Apple 실리콘 또는 Intel을 확인해 해당 설치 파일을 선택하세요. 다른 플랫폼은 다운로드 가이드에서 안내하는 사이트 내 /dl/ 설치 파일을 이용하세요. 앱을 다시 받아도 원격 연결 문제가 해결된다는 보장은 없으므로 작업 전에 기기의 데이터를 보존하세요.

데스크톱과 Android에서 처음 실행할 때 시스템이 실행을 차단할 수 있습니다. 출처를 확인한 뒤 Mac에서는 “개인정보 보호 및 보안”에서 시스템 안내에 따라 “그래도 열기”를 선택할 수 있습니다. Windows SmartScreen에서는 출처를 확인한 뒤 “추가 정보”를 열고 “실행” 여부를 결정하세요. Android는 설치에 사용하는 출처에 대해서만 필요할 때 알 수 없는 앱 설치를 허용하고, 설치 후에는 권한을 회수할 수 있습니다. Linux는 선택한 패키지 형식에 맞게 설치하며 AppImage에는 실행 권한이 필요합니다. 자세한 제한 사항은 설치 차단 해제 안내를 확인하고 출처를 확인하지 않은 채 허용하지 마세요.

연결을 다시 설정하고 구성을 복원한 뒤에도 문제가 계속되면 업데이트 전후 차이와 최소 재현 절차를 정리하세요. 문제가 발생한 동작, 예상 결과, 실제 결과, 발생 빈도를 포함하되 전체 인증 정보는 넣지 마세요. 정상 작동하는 구성 사본을 보존하고 필요한 설정을 하나씩 다시 추가하세요. 특정 항목이 문제를 안정적으로 일으키면 더 이상 변경 범위를 넓히지 마세요. 이렇게 하면 작동 기준선을 복원하고 일시적인 복구를 모든 문제가 해결된 것으로 오해하지 않을 수 있습니다.

08 · 기기 및 네트워크 상황

iPad 점검: 네트워크 전환, 화면 잠금, 로컬 네트워크 확인

iPad 문제 해결의 핵심은 별도의 규칙을 만드는 것이 아니라 다른 기기와 비교해 환경이 어떻게 달라졌는지 확인하는 것입니다. 같은 구독이 iPhone에서는 정상이고 iPad에서만 실패해도 비교할 차이가 있다는 뜻일 뿐, iPad에 다른 프로토콜이 필요하다는 증거는 아닙니다. 먼저 두 기기가 같은 네트워크, 같은 항목, 같은 Config, 같은 Global Routing 모드를 사용하는지 확인한 뒤 요청 결과를 비교해 기기 차이와 설정 차이를 혼동하지 않도록 하세요.

Wi-Fi, 셀룰러, 핫스팟 전환

Wi-Fi만 사용할 수 있는 iPad와 셀룰러 연결이 가능한 기기는 비교할 수 있는 조건이 완전히 같지 않습니다. 개인용 핫스팟으로 테스트한다면 핫스팟은 별도의 접속 경로이므로 따로 기록하세요. 네트워크를 전환한 뒤에는 시스템이 사용할 수 있는 네트워크를 확보했는지 확인하고 Shadowrocket 연결을 다시 설정하세요. 네트워크에서 웹 인증이 필요하면 먼저 인증을 완료하세요. 기기에 이전 네트워크 이름이 계속 표시되거나 연결이 반복해서 바뀐다면 접속 안정성부터 해결하세요.

가정 네트워크에서 회사 네트워크로 이동하면 기존 연결이 잠시 작동하지 않을 수 있습니다. 화면에 연결됨으로 표시되어도 기존 연결이 새 네트워크로 정상적으로 전환됐다는 뜻은 아닙니다. 연결을 끄고 다시 설정한 뒤 같은 대상에 요청을 보내세요. 재연결만으로 복구되면 네트워크 전환 동작과 On Demand 조건을 기록하세요. 재연결해도 실패하면 기본 네트워크와 서버 연결 가능 여부를 다시 확인하세요. 네트워크 전환 중 한 번 실패했다고 모든 규칙을 계속 수정하거나 구독을 삭제하지 마세요.

화면 잠금, Split View, 앱 연결 재사용

화면 잠금 해제 후 앱이 기존 세션을 계속 사용하거나 새 연결을 시작할 수 있습니다. 문제가 해제 후 첫 요청에만 나타나는지, 이후 요청도 모두 실패하는지 확인하세요. 대상 앱을 다시 열었을 때 복구된다면 앱 세션 재사용 여부를 살펴볼 필요가 있습니다. 모든 앱에서 동시에 실패하면 시스템 연결 상태를 확인하세요. Split View로 앱 두 개를 함께 실행해도 같은 웹페이지를 표시한다는 이유만으로 요청 경로가 같다고 볼 수 없습니다. 각 앱이 사용하는 도메인을 따로 확인하세요.

백그라운드에서 전송이 계속될 수 있는지는 대상 앱과 시스템의 백그라운드 실행 조건에도 달려 있습니다. Shadowrocket의 연결 상태가 대상 앱에 백그라운드 실행 기회를 보장하지는 않으므로 다운로드가 멈춘 원인을 모두 규칙 탓으로 돌리지 마세요. 테스트할 때는 대상 앱을 전면에 두고 전송이 정상인지 확인한 뒤 화면을 잠갔을 때의 변화를 비교하세요. 기기 온도, 저전력 상태, 시스템 리소스 부족도 기록하되 관련 현상만으로 특정 설정에 문제가 있다고 단정하지 마세요.

로컬 네트워크 접속 및 기기 간 구성 비교

연결 후 프린터를 찾지 못하거나 로컬 관리 페이지에 접속할 수 없거나 로컬 네트워크 기기와 연결되지 않으면 먼저 연결을 중단하고 기본 상태와 비교하세요. 대상 기기와 iPad가 실제로 같은 로컬 네트워크에 있는지 확인하세요. 기기 이름 검색과 주소를 직접 입력해 접속하는 것은 서로 다른 요청이므로 검색에 실패했다고 모든 로컬 연결이 실패한 것은 아닙니다. 로컬 네트워크 권한, 실제 대상 주소, 적용된 정책을 확인한 뒤 기존 네트워크 구조에 맞게 설정하세요. 용도를 알 수 없는 파일에 모든 사설 IP 주소 범위를 그대로 추가하지 마세요.

다른 기기에서 구성을 복사한 뒤에는 정책 참조와 개별 항목이 모두 있는지 다시 확인하세요. 이름이 같아도 내부 설정까지 같다는 뜻은 아니며, 구성 파일이 정상적으로 읽혀도 기기에서 시스템 권한을 허용한 것은 아닙니다. 구독 업데이트로 항목 이름이 바뀌면 이전 규칙이 구 이름을 참조해 기기별로 다르게 작동할 수 있습니다. 처음 가져온 파일명이 아니라 현재 실제로 적용 중인 내용을 비교하세요. 필요하면 같은 백업을 복원해 조건을 통제한 상태로 테스트하세요.

이 장의 점검에서는 일상적인 세 가지 동작을 확인해야 합니다. 기기를 이동하지 않고 사용할 때 요청이 정상인지, 사용할 수 있는 네트워크로 전환한 뒤 다시 연결할 수 있는지, 화면 잠금 해제 후 새 요청이 발생하는지 확인하세요. 특정 단계에서 실패하면 설정 변경 범위를 넓히지 말고 발생 조건을 기록한 뒤 해당 장을 다시 확인하세요. 원인을 찾기 어려우면 민감한 정보를 가린 로그 요약, 모드, 네트워크 비교 결과를 보존하세요. 기본 사용법은 빠른 시작 안내에서, 용어는 용어집에서, 자주 묻는 내용은 질문과 답변에서 확인할 수 있습니다.