OFFICIAL MANUAL / DIAGNOSTICS

Shadowrocket
문제 해결 가이드

증상을 바탕으로 연결, 구독, 설정 문제를 찾아보세요. 한 번에 변수 하나만 변경하고 원래 설정을 보존한 뒤 같은 조건에서 결과를 확인합니다.

이 페이지는 공식 매뉴얼의 문제별 점검 편입니다. 기존 구독을 가져오고 Global Routing을 선택해 연결하는 순서는 사용 방법을 참고하세요. 설정을 마친 뒤 문제가 생겼다면 아래 목차에서 해당 항목을 선택하면 됩니다.

01 / CONNECTION SWITCH

연결 스위치가 켜지지 않거나 바로 꺼짐

스위치가 켜진 상태를 유지하지 못하는 문제와, 스위치를 켠 뒤 웹 페이지가 열리지 않는 문제는 서로 다릅니다. 전자는 시스템에서 VPN 설정을 추가할 수 있는지, 다른 연결 설정이 사용 중인지, 현재 설정을 정상적으로 불러올 수 있는지부터 확인하세요. 이때 DNS나 규칙을 계속 바꿔도 유용한 단서를 얻기 어렵습니다. 스위치가 권한 확인 전, 확인 후, 또는 연결 후 몇 초 뒤에 꺼지는지 기록하고 그 시점을 기준으로 다음 단계를 선택하세요.

권한 승인 문제와 연결 문제를 먼저 구분하세요

처음 연결을 켤 때 시스템에서 VPN 설정 추가를 허용하고 기기 인증을 하라는 메시지가 표시될 수 있습니다. 이는 시스템 권한 승인 절차이지 구독 인증이 아닙니다. 팝업에 표시된 앱을 확인하고 출처를 확인한 뒤 승인하세요. 앞서 팝업을 취소했다면 Home으로 돌아가 다시 연결을 시도할 수 있습니다. 기기에서 제한 안내가 표시되면 기기 관리 정책을 확인하고 스위치를 반복해서 눌러 제한을 우회하려 하지 마세요.

Shadowrocket 연결을 끈 다음 시스템 Settings로 이동해 VPN 관련 항목에서 다른 설정이 이미 연결 중인지 확인하세요.
사용자가 직접 켠 다른 VPN 연결이나 자동 연결 기능을 잠시 중지한 뒤 Shadowrocket으로 돌아와 한 번만 연결을 시도하세요.
여전히 바로 꺼진다면 Home에서 실제로 존재하는 서버를 선택했는지 확인하고 Config의 현재 설정을 읽을 수 있는지 점검하세요.
시스템 안내와 앱 내부 오류를 기록한 다음 권한, 설정 복원, 서버 매개변수 중 무엇을 확인할지 결정하세요.

기기에 VPN 설정이 여러 개 있다고 해서 모두 삭제해야 하는 것은 아닙니다. 분리해서 확인할 대상은 동시에 작동하는 연결이나 자동 재연결 동작입니다. 회사나 학교에서 관리하는 설정은 정책에 따라 보호될 수 있고, 삭제하면 정상적인 접속에도 영향을 줄 수 있으므로 먼저 관리 담당자에게 확인하세요. 한 연결을 중지하자 다른 연결이 곧바로 다시 시작된다면 앱 스위치 고장을 의심하기보다 양쪽의 On Demand 또는 시스템 자동 연결 설정을 확인하세요.

최소한의 변경으로 설정이 시작되는지 확인하세요

설정을 가져온 뒤 문제가 시작됐다면 원본 파일을 보관하고, 이전에 정상적으로 시작된 설정으로 되돌리세요. 서버, 네트워크, 규칙을 동시에 바꾸거나 VPN을 새로 만들지 마세요. 복구되더라도 어떤 변경이 효과가 있었는지 알 수 없습니다. 설정 불러오기 오류는 섹션 제목, 옵션 철자, 정책 참조 또는 파일 내용 누락 때문일 수 있습니다. 실제 오류 위치를 확인하고 모든 시작 실패를 서버 접속 불가 탓으로 돌리지 마세요.

스위치가 켜진 상태를 유지하지만 트래픽이 없다면 다음 장을 확인하고, 스위치는 유지되지만 서버 테스트가 시간 초과되면 서버 시간 초과 장으로 이동하세요. 스위치 색상이나 시스템의 연결 표시는 연결 상태의 일부만 보여 줄 뿐 실제 요청을 대신 검증하지 않습니다. 테스트할 웹 페이지 하나를 정해 연결이 성립하는지 확인한 뒤 앱 내에 해당 요청 기록이 생기는지도 살펴보세요. 아이콘만 보고 결론을 내리지 마세요.

설정을 바꿔도 문제가 계속되면 기기를 정상적으로 재시동한 뒤 한 번 더 재현해 보세요. 재시동은 일시적인 실행 상태를 정리할 수 있지만 잘못된 암호나 서버 매개변수를 수정하지는 않습니다. 로컬 정보를 백업했고 계정 복구 방법을 확인했으며 일반 재시동과 설정 전환으로 해결되지 않았을 때만 사용자 VPN 설정 재구성을 고려하세요. 시스템 네트워크 설정 재설정은 영향 범위가 크므로 첫 단계로 삼지 마세요.

복구 후 확인할 항목

연결이 안정적으로 켜지면 현재 네트워크를 그대로 둔 채 웹 페이지 열기, Home으로 돌아가기, 화면 잠금 후 다시 잠금 해제하기를 차례로 수행해 새로운 연결 종료 안내가 없는지 확인하세요. 그런 다음 실제로 필요한 On Demand 조건을 복원하고 반복 연결을 일으키는지 살펴보세요. 잠금 후에만 문제가 발생한다면 당시 Wi-Fi에서 셀룰러 네트워크로 전환됐는지 기록하세요. 단순히 “백그라운드에서 연결이 끊김”이라고 적는 것보다 원인을 찾는 데 도움이 됩니다.

02 / TRAFFIC PATH

연결은 켜졌지만 인터넷에 접속할 수 없음

연결이 켜졌다는 것은 시스템에 관련 네트워크 처리 경로가 설정됐다는 뜻이지 서버, DNS, 규칙, 대상 웹 사이트가 모두 정상이라는 뜻은 아닙니다. 먼저 문제가 모든 앱에 해당하는지, 브라우저에만 해당하는지, 특정 도메인에만 해당하는지 확인하세요. 페이지가 전혀 열리지 않는 경우와 글자는 표시되지만 이미지나 로그인이 실패하는 경우도 구분해야 합니다. 후자는 여러 도메인에 서로 다른 정책이 적용될 수 있으므로 전체 연결이 끊긴 것으로 단정할 수 없습니다.

기본 네트워크를 확인한 뒤 라우팅 모드를 분리해 점검하세요

Shadowrocket 연결을 끄고 같은 기기에서 평소 정상적으로 열리는 웹 페이지에 접속해 보세요. 기본 네트워크에서도 접속이 안 된다면 Wi-Fi 로그인 인증, 셀룰러 데이터 권한 또는 라우터 연결부터 확인하세요. 공용 네트워크의 인증 페이지는 연결을 끈 상태에서 완료해야 할 수 있습니다. 기본 네트워크가 복구된 후 연결을 켜야 인터넷에 접속할 수 없는 네트워크를 설정 오류로 오인하지 않습니다.

기본 네트워크가 정상이면 현재 Global Routing 옵션을 기록하세요. Config 모드에서는 현재 설정의 규칙에 따라 경로가 결정됩니다. Proxy 모드는 선택한 서버가 요청을 처리할 수 있는지 임시로 확인할 때 유용합니다. Direct 모드는 연결 안에서 직접 연결 경로를 비교할 수 있지만, 연결을 끈 뒤 기본 네트워크를 확인하는 절차를 대신하지는 않습니다. 테스트가 끝나면 원래 사용하던 모드로 되돌리세요. 특정 웹 페이지 하나를 열기 위해 모든 트래픽의 처리 방식을 계속 바꾸지 마세요.

Global Routing	문제 해결 시 용도	이 결과만으로는 확인할 수 없는 점
Config(설정)	설정 규칙에 따라 실제로 적용되는 경로와 정책을 확인	대상 하나가 정상이어도 모든 규칙이 올바르다는 뜻은 아님
Proxy(프록시)	규칙 라우팅 요소를 잠시 분리해 선택한 서버를 확인	요청이 정상이어도 Config 모드의 정책 참조가 올바르다는 뜻은 아님
Direct(직접 연결)	현재 연결에서 직접 연결 처리 경로를 비교	연결을 끈 뒤 기본 네트워크를 확인하는 절차를 대신할 수 없음

실패한 요청에서 규칙과 정책을 역추적하세요

Proxy에서는 접속되지만 Config에서는 실패한다면 해당 도메인이 실제로 어떤 규칙과 일치했는지, 그 규칙의 정책이 예상한 서버를 가리키는지 먼저 확인하세요. 규칙은 순서대로 적용되므로 더 포괄적인 규칙이 앞에 있으면 요청을 먼저 처리할 수 있습니다. 예상한 규칙 하나만 확인하지 말고 해당 요청의 기록에서 실제 결과를 확인하세요. 특히 DIRECT, REJECT, 마지막의 FINAL을 살펴보세요.

아래 규칙은 순서를 설명하기 위한 예시이며 그대로 교체해 사용할 수 있는 완전한 설정이 아닙니다. example.com은 문서용 도메인입니다. 실제 설정에는 PROXY에 해당하는 유효한 정책이 있어야 합니다. 첫 번째 규칙은 해당 도메인과 하위 도메인을 처리하고, 두 번째 규칙은 지리 데이터베이스를 기준으로 주소를 매칭하며, 마지막 규칙은 앞서 일치하지 않은 요청을 처리합니다. 실제 설정은 본인의 접속 요구에 맞게 구성하고 사용 중인 정책 이름을 확인하세요.

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

Proxy에서도 실패한다면 기존에 보유하고 있으며 정상 작동을 확인한 다른 서버로 먼저 비교 테스트하세요. 모든 서버가 실패하면 DNS, 현재 네트워크, 공통 설정을 계속 확인하고 하나만 실패하면 서버 시간 초과 장으로 이동하세요. 이 단계에서 모든 설정을 한꺼번에 업데이트하지 마세요. 여러 변경 사항이 동시에 생기면 기존 정상 상태와 비교할 기준이 없어져 문제 범위가 더 커집니다.

웹 사이트 문제와 클라이언트 경로 문제를 구분하세요

웹 사이트 하나만 실패한다면 로그인, 동영상 또는 첨부 파일 도메인만 접속되지 않는지 확인하세요. 웹 페이지는 보통 여러 도메인에 요청하므로 기본 페이지가 열려도 리소스 도메인이 모두 정상이라는 뜻은 아닙니다. 시스템 시간, 인증서 안내, 대상 서비스 자체 상태도 살펴보세요. 인증서 경고가 나타나면 검증을 바로 끄지 마세요. 기기 시간이 잘못됐는지, 인증 페이지가 요청을 가로챘는지, 서버 매개변수의 이름이 일치하지 않는지 먼저 확인하세요.

조정이 끝나면 같은 대상을 반복 테스트하고 현재 네트워크, 모드, 서버, 적용된 정책을 기록하세요. 그런 다음 다른 정책을 사용하는 대상도 확인해 한 곳을 해결하다 다른 접속이 망가지지 않았는지 살펴보세요. 규칙 매칭 원리는 규칙 키워드와 매칭 순서에서 더 확인할 수 있습니다. 일반적인 연결 관련 질문은 자주 묻는 질문을 참고하세요.

03 / SERVER REACHABILITY

서버 시간 초과, 인증 실패 및 연결 끊김

서버 테스트 시간 초과는 현재 테스트가 제한 시간 안에 완료되지 않았다는 뜻일 뿐, 서버를 영구적으로 사용할 수 없다는 증거는 아닙니다. 테스트 방법, 도메인 확인, 전송 핸드셰이크, 대상 요청이 결과에 영향을 줄 수 있습니다. 먼저 테스트 이름과 원문 오류를 기록한 뒤 실제 웹 페이지 접속 결과와 비교하세요. 테스트는 실패했지만 실제 접속이 정상이라면 테스트 대상과 방법을 확인하고 기존 서버를 바로 삭제하지 마세요.

주소, 포트, 인증, 전송 설정을 단계별로 확인하세요

기존 서버의 편집 화면에서 본인이 가진 원본 정보를 항목별로 대조하세요. 복사 과정에서 공백, 줄바꿈, 전각 문장 부호가 섞이지 않았는지도 확인하세요. 주소 필드에는 해당 필드에 필요한 서버 주소만 입력해야 하며 전체 공유 링크를 넣으면 안 됩니다. 포트는 서버 측 설정과 일치해야 합니다. 서버 이름은 로컬에서 구분하기 위한 표시에 불과합니다. 이름을 바꿔도 주소나 인증 정보가 수정되지는 않으며 서버 식별 매개변수로 사용할 수도 없습니다.

매개변수 항목	중점 확인 사항	흔히 나타나는 증상
주소와 포트	주소 철자, 포트, 현재 네트워크에서의 접속 가능 여부	주소 확인 실패, 연결 시간 초과 또는 연결 거부
인증 정보	암호, UUID, 암호화 방식, 서버 요구 사항	핸드셰이크 후 실패, 인증 오류 또는 연결 종료
TLS	서버 이름, 인증서, 기기 시간	인증서 확인 또는 핸드셰이크 실패
전송 설정	전송 유형, Host, Path 등의 관련 매개변수	기본 포트에는 연결되지만 앱 요청을 설정할 수 없음

프로토콜마다 사용하는 필드는 서로 다릅니다. Shadowsocks는 암호와 암호화 방식을 함께 확인해야 합니다. VMess와 VLESS는 해당 프로토콜의 인증 정보 및 전송 설정을 확인하세요. Trojan은 암호와 TLS 관련 매개변수를 확인해야 하며 Hysteria2는 UDP 기반 전송 조건도 관련됩니다. 서버 주소가 같다는 이유로 한 프로토콜의 매개변수를 다른 프로토콜에 통째로 복사하지 마세요. 본인이 가진 서버 정보를 기준으로 확인하고 오류 안내만 보고 암호를 추측하지 마세요.

통제된 비교로 네트워크와 서버의 경계를 확인하세요

현재 네트워크에서 본인이 보유한 다른 정상 서버를 먼저 테스트한 다음, 원래 서버를 다른 사용 가능한 네트워크에서 다시 시도하세요. 첫 번째 방법은 네트워크를 유지하고 서버만 바꾸며, 두 번째는 서버를 유지하고 네트워크만 바꿉니다. 같은 서버가 특정 네트워크에서만 실패하면 해당 네트워크의 접속 제한, 인증 상태 또는 UDP 조건을 확인하세요. 여러 네트워크에서 해당 서버만 실패하고 다른 서버는 정상이라면 서버나 계정 상태의 문제일 가능성이 큽니다.

테스트 중에는 여러 속도 측정 작업을 동시에 실행하지 마세요. 짧은 시간에 연결을 반복해서 만들면 서버 측 동시 연결 제한이 작동할 수 있고 기기 부하와 네트워크 혼잡도 바뀌어 테스트 조건이 달라집니다. 한 번의 테스트가 끝난 뒤 다음 테스트를 시작하고, 오류 사례를 하나 이상 온전히 기록하세요. 네트워크를 바꾼 뒤에는 연결을 새로 설정해 이전 연결이 복구되지 않은 상태를 새 네트워크의 안정성으로 오인하지 않도록 하세요.

인증 실패는 보통 원본 인증 정보, 계정 유효 상태, 서버 측 변경 여부를 확인해야 합니다. DNS만 바꿔서는 잘못된 암호를 고칠 수 없습니다. 연결 거부와 연결 시간 초과도 서로 다른 오류입니다. 전자는 대상 포트에서 예상한 서비스가 제공되지 않을 때 나타날 수 있고 후자는 그보다 앞선 경로나 핸드셰이크 단계에서 발생할 수 있습니다. 로그의 오류는 원인을 찾기 위한 단서일 뿐이므로 재현 가능한 비교 결과와 함께 살펴보세요. 특정 문구만으로 결론을 내리지 마세요.

검증 기준을 낮춰 원인을 감추지 마세요

인증서 문제는 먼저 기기 날짜, 서버 이름, 원래 설정을 확인하세요. 인증서 검증을 임의로 건너뛰면 서버 신원을 확인하는 절차가 사라지고 실제 이름 설정 오류가 계속 남을 수 있습니다. 서버에서 특수한 인증서 구성을 사용한다면 본인이 보유한 배포 정보를 기준으로 처리하세요. 신뢰할 만한 정보가 없다면 현재 상태를 유지하고 기존 서비스 관리자에게 오류를 전달하세요. 보안 옵션을 일반적인 속도 향상 스위치처럼 사용하지 마세요.

04 / SUBSCRIPTION UPDATE

구독 가져오기 실패, 업데이트 실패 또는 목록 이상

구독 업데이트는 주소에서 콘텐츠 가져오기, 콘텐츠 형식 인식, 서버 목록 저장의 세 단계 이상을 포함합니다. 가져오기 오류가 서버 자체에 접속할 수 없다는 뜻은 아닙니다. 마찬가지로 구독이 업데이트되더라도 목록의 모든 서버가 사용 가능한 것은 아닙니다. 어느 단계에서 실패했는지 먼저 확인하세요. 요청에 응답이 없었는지, 오류 페이지가 반환됐는지, 콘텐츠는 받아왔지만 형식을 인식하지 못했는지에 따라 해결 방법이 다릅니다.

링크가 어떤 종류의 콘텐츠인지 먼저 확인하세요

단일 공유 링크, 서버 목록 구독, 전체 설정 파일은 용도가 서로 다릅니다. 단일 공유 링크는 서버 하나를 나타내고 구독 주소는 갱신 가능한 목록을 가져오는 데 사용됩니다. 설정 파일에는 규칙, DNS, 정책이 포함될 수도 있습니다. 링크 모양만으로 용도를 판단하지 말고 본인이 가진 자료의 설명을 확인하세요. 가져오기 화면이 맞지 않으면 같은 내용을 계속 붙여 넣어도 콘텐츠 종류는 바뀌지 않으며 목록에 구분하기 어려운 중복 항목이 생길 수 있습니다.

주소를 복사할 때 채팅 앱에서 붙은 끝 문장 부호, 줄바꿈, 표시용 생략 기호가 포함되지 않았는지 확인하세요. 일부 주소에는 쿼리 매개변수가 포함되어 있어 문자 하나만 빠져도 인증에 실패할 수 있습니다. 주소의 프로토콜, 경로, 매개변수를 익숙해 보이는 형식으로 임의 변경해서도 안 됩니다. 구독 주소 자체가 접속 권한을 가질 수 있으므로 인증 정보처럼 안전하게 보관하세요. 도움을 요청하려고 전체 주소를 공개 페이지에 올리지 마세요.

현재 서버 그룹 이름과 항목 수가 대략 어떻게 달라졌는지 기록하고 업데이트 전 정상 작동한 콘텐츠를 보존하세요.
본인의 원본 구독 주소가 완전한지, 해당 콘텐츠 종류에 맞는 가져오기 화면을 사용했는지 확인하세요.
한 번 수동으로 업데이트하고 오류 안내를 확인해 네트워크 실패, 인증 실패, 형식 인식 실패를 구분하세요.
업데이트가 완료되면 현재 선택된 서버와 정책 참조를 확인한 뒤 실제 연결을 테스트하세요.

구독 요청의 네트워크 경로를 확인하세요

업데이트 중 도메인 확인 실패나 연결 시간 초과가 발생하면 기본 네트워크가 정상인지 확인한 다음 구독 요청이 현재 사용할 수 없는 연결에 의존하는지 살펴보세요. 주소에 따라 직접 연결 경로와 기존 연결 경로에서 결과가 다를 수 있습니다. 업데이트 버튼을 계속 누르지 말고 한 번씩 조건을 바꿔 확인하세요. 구독을 가져올 때 기존의 정상 연결이 꼭 필요하다면 본인이 사용 가능하다고 확인한 서버를 먼저 사용하세요. 서로 의존하는 상태가 되지 않도록 합니다.

로그인 페이지, 인증 페이지, 접속 오류 안내가 반환되면 클라이언트는 이를 서버 목록으로 정상적으로 해석할 수 없습니다. 브라우저에 페이지가 표시됐다는 사실은 콘텐츠를 받았다는 뜻일 뿐 유효한 구독이라는 증거가 아닙니다. 페이지를 저장한 텍스트를 설정으로 억지로 가져오지 마세요. 계정 상태, 주소 유효성, 원본 자료를 확인하고 필요하다면 기존 서비스 관리자에게 해당 주소가 어떤 종류의 콘텐츠를 반환하는지 문의하세요.

업데이트 후 목록이 비거나 항목이 크게 바뀌었다면 계속 업데이트하지 말고 다른 주소를 가져왔는지, 기존 구독이 취소됐는지, 서버에서 반환 목록을 변경했는지 확인하세요. 업데이트 전 기록이 남아 있다면 그룹 이름과 서버 이름을 비교할 수 있지만, 이름만으로 연결 매개변수가 동일하다고 판단하지 마세요. 이름이 같아도 주소나 인증 정보가 바뀔 수 있으므로 실제 연결을 테스트해야 합니다.

중복 항목과 유효하지 않은 참조를 처리하세요

직접 추가한 서버와 구독에서 생성된 서버가 함께 있을 수 있습니다. 정리하기 전에 출처를 확인해 유지해야 할 수동 항목까지 삭제하지 않도록 하세요. 규칙 정책이 특정 서버 이름을 직접 참조하는 경우 구독 업데이트로 이름이 바뀌면 참조가 유효하지 않게 될 수 있습니다. 목록에 서버가 많이 남아 있는지만 보지 말고 정책이 실제로 무엇을 가리키는지 확인하세요. 참조를 먼저 수정한 다음 중복 항목을 정리할지 결정하세요.

클라이언트 목록, 구독 서비스 계정 상태, 설정의 규칙은 서로 다른 영역입니다. 서버 목록을 업데이트해도 모든 규칙이 업데이트되는 것은 아니며 직접 수정한 DNS가 자동으로 복구된다고 볼 수도 없습니다. 복구 후에는 업데이트 시각이나 결과 안내, 목록 내용, 현재 선택 항목, 실제 접속을 확인하세요. 콘텐츠 종류가 여전히 헷갈린다면 공유 링크와 구독의 차이를 참고하세요.

05 / PERFORMANCE

지연 시간은 정상인데 속도가 느리거나 동영상이 끊김

지연 시간, 처리량, 웹 페이지 로딩 시간은 서로 다른 지표입니다. 지연 시간 테스트는 특정 상호작용에 걸린 시간을 주로 보여 주며 지속적인 다운로드 속도로 바로 환산할 수 없습니다. 동영상 재생은 대상 서비스, 캐시, 비트레이트, 분할 요청에도 영향을 받습니다. 먼저 “느리다”는 표현을 처음 열 때 오래 기다림, 처음에는 빠르다가 멈춤, 큰 파일만 느리게 전송됨처럼 관찰 가능한 현상으로 구체화한 뒤 알맞은 테스트를 선택하세요.

반복 가능한 비교 조건을 마련하세요

같은 네트워크, 기기, 대상, 서버를 유지하고 다른 대용량 작업을 끝낸 뒤 한 번 더 테스트하세요. 테스트 사이트와 서버를 동시에 바꾸면 결과를 비교하기 어렵습니다. 웹 캐시는 두 번째 페이지 로딩 속도에도 영향을 주므로 처음 불러온 것인지 다시 불러온 것인지 기록하세요. 동영상은 재생 위치를 이동한 뒤에만 끊기는지도 적으세요. 대상 서비스 자체의 부하도 결과에 영향을 주므로 한 번의 결과만으로 전체 경로를 판단하지 마세요.

먼저 연결을 끈 상태에서 기본 네트워크 속도를 비교한 다음 연결을 켜고 대상이 예상한 정책을 사용하는지 확인하세요. 기본 네트워크 자체가 느리다면 Wi-Fi 신호, 라우터 부하, 셀룰러 수신 상태부터 살펴보세요. Wi-Fi에 연결됐다고 해서 신호 품질과 외부 대역폭까지 양호한 것은 아닙니다. 라우터에서 멀리 떨어져 있거나 접속 지점이 자주 바뀌거나 다른 기기가 네트워크를 함께 사용하면 연결 테스트는 간혹 정상이어도 지속적인 전송은 불안정할 수 있습니다.

백그라운드 백업, 앱 업데이트, 기타 전송 작업을 잠시 중지하고 기기가 뜨거워지는지도 기록하세요.
같은 대상을 사용해 기본 네트워크와 연결을 켠 상태를 비교하고 Global Routing 및 적용된 정책을 확인하세요.
본인이 보유한 다른 정상 서버로만 바꾸고 나머지 조건은 유지한 채 요청을 다시 테스트하세요.
마지막으로 네트워크를 바꾸고 문제가 서버, 대상, 네트워크 중 무엇을 따라 변하는지 비교하세요.

DNS 확인 대기, 핸드셰이크 대기, 지속적인 전송을 구분하세요

처음에는 화면이 오래 비어 있다가 콘텐츠가 빠르게 나타난다면 DNS나 연결 핸드셰이크가 관련됐을 수 있습니다. 페이지가 조금씩 계속 로드된다면 처리량, 재전송, 리소스 요청 문제에 더 가까울 수 있습니다. 체감만으로 모든 설정을 바꾸지 말고 요청 기록에서 실패한 도메인, 연결 성립 여부, 오류를 확인하세요. 기본 페이지는 정상인데 이미지가 느리다면 이미지 도메인에 다른 정책이 적용되는지 살펴보고 전체 속도 측정보다 규칙을 먼저 확인하세요.

서버의 지리적 위치, 당시 부하, 대상 웹 사이트와의 연결 품질, 경로 혼잡도가 모두 성능에 영향을 줍니다. 지연 시간이 짧은 서버가 현재 대상에서 더 높은 처리량을 보장하지는 않습니다. 같은 서버도 웹 사이트에 따라 결과가 다를 수 있습니다. 문제 해결을 위해 서비스를 새로 추가할 필요 없이 기존 서버로 비교하면 됩니다. 같은 조건에서 여러 차례 일관된 결과가 나올 때 해당 경로가 현재 용도에 맞지 않는다고 판단하세요.

UDP를 사용하는 앱이나 프로토콜은 별도로 확인하세요. 일부 네트워크에서는 UDP를 일반 웹 연결과 다르게 처리하므로 웹 페이지가 열린다고 실시간 오디오·비디오나 UDP 기반 전송도 정상이라는 뜻은 아닙니다. 전송 프로토콜, 포트, 고급 매개변수를 한꺼번에 바꾸지 마세요. 먼저 서버가 지원하는 조건을 확인한 뒤 변경 사항을 기록하며 하나씩 테스트하세요. 대역폭 매개변수를 더 큰 값으로 입력해도 실제 외부 전송 용량이 늘어나지 않으며 혼잡이 더 두드러질 수 있습니다.

고급 설정 변경 범위를 제한하세요

MTU 같은 네트워크 매개변수는 일반적인 속도 향상 옵션이 아닙니다. 큰 요청만 멈추고 작은 요청은 반복해서 성공한다면 구체적인 재현 절차와 네트워크 비교 결과를 먼저 수집한 뒤 확인된 환경 요구에 따라 조정하세요. 변경 전 원래 값을 기록하고 같은 실패 요청을 다시 테스트하세요. 개선되지 않으면 원래 값으로 되돌리세요. 명확한 증상이 없다면 검증되지 않은 설정을 여러 개 추가하는 것보다 기본값을 유지하는 편이 관리하기 쉽습니다.

테스트 중 기기가 과열됐거나 배터리가 부족하거나 화면 녹화를 계속하고 있으면 실제 사용 경험이 달라질 수 있습니다. 기기가 정상 온도로 돌아온 뒤 짧게 비교하세요. 일상적인 웹 페이지 문제를 확인하려고 네트워크를 장시간 최대 부하로 사용하지 마세요. 복구 여부는 한 번의 테스트 수치가 좋아졌는지가 아니라 이전에 실패하던 작업이 안정적으로 완료되는지를 기준으로 판단해야 합니다. 주된 문제가 첫 DNS 확인 지연이라면 DNS 장을 확인하고, 지속적인 발열이 동반된다면 배터리 소모 장을 살펴보세요.

06 / NAME RESOLUTION

DNS 확인 실패와 특정 도메인 접속 불가

DNS는 도메인을 이후 연결에 필요한 주소로 변환합니다. 서버 지연 시간 테스트는 정상이지만 웹 페이지가 열리지 않는다면 테스트와 웹 페이지가 서로 다른 도메인, DNS 경로, 규칙을 사용했을 수 있습니다. 먼저 DNS 확인 단계에서 실패했는지, 주소를 받은 뒤 연결에 실패했는지 확인하세요. 두 경우 모두 브라우저가 기다리는 것처럼 보일 수 있지만 해결 방향은 다릅니다. 앱에서 확인할 수 있는 오류와 요청 기록은 빈 화면 하나보다 더 유용합니다.

구체적인 도메인 하나부터 확인하세요

반복해서 실패하는 도메인을 하나 정하고 실패 시각과 현재 네트워크를 기록하세요. 평소 정상인 도메인 하나를 비교 대상으로 삼아 모든 DNS 확인이 실패하는지 살펴보세요. 모든 도메인에 문제가 있으면 설정의 DNS 주소가 잘못됐는지, 해당 DNS 서비스에 예상한 경로로 접속할 수 있는지 먼저 확인하세요. 특정 도메인만 실패한다면 도메인 자체의 레코드, 캐시, 라우팅, 주소 계열 차이를 살펴보고 DNS 설정 전체를 바로 교체하지 마세요.

설정에는 시스템 DNS, 지정된 DNS 서비스, 요청 경로별 처리 방식이 함께 포함될 수 있습니다. 현재 실제로 적용되는 Config부터 확인해 수정 중인 파일이 비활성 상태가 아닌지 살펴보세요. 서버 주소 자체가 도메인이라면 먼저 해당 도메인을 확인해야 합니다. DNS 경로가 아직 연결되지 않은 서버에 의존한다면 순환 의존 문제가 생길 수 있습니다. 문제를 점검할 때 “서버 도메인 확인”과 “대상 웹 사이트 도메인 확인”을 따로 기록하세요.

규칙을 바탕으로 DNS 확인과 연결의 관계를 살펴보세요

도메인 규칙과 주소 규칙은 서로 다른 대상을 매칭합니다. DOMAIN은 특정 도메인과 일치하고 DOMAIN-SUFFIX는 도메인 접미사 및 해당 하위 도메인과 일치합니다. IP-CIDR은 IP 주소 대역으로 매칭하며 GEOIP는 IP 주소와 데이터베이스 정보를 사용합니다. 요청에 어떤 정책이 적용됐는지는 실제 매칭 결과를 확인해야 합니다. 설정에 특정 도메인이 들어 있다는 이유만으로 앞선 다른 규칙보다 먼저 적용된다고 볼 수 없습니다.

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

이 조각은 매칭 대상을 보여 주기 위한 예시일 뿐입니다. 예시 네트워크 대역은 문서용 주소이며 사용할 수 있는 서비스를 나타내지 않습니다. no-resolve는 해당 주소 규칙을 매칭하기 위해 도메인 확인을 능동적으로 시작하지 않는다는 뜻이지 모든 DNS를 끈다는 뜻은 아닙니다. 이 차이를 이해하지 못한 채 주소 규칙에 해당 매개변수를 일괄 추가하면 DNS 결과에 의존하는 기존 판단이 예상대로 작동하지 않을 수 있습니다. 전체 규칙은 기존 정책과 실제 대상에 맞게 구성해야 합니다.

DNS 설정을 바꾸기 전에 원래 설정을 보존하고 DNS 출처나 관련 옵션 하나만 변경한 다음 연결을 새로 설정해 동일한 요청을 재현하세요. 브라우저, 앱, 시스템, 연결 내부에 각각 캐시가 있을 수 있으므로 변경 직후에도 이전 결과가 잠시 나타날 수 있습니다. 그렇다고 새 설정이 무효라고 단정할 수는 없습니다. 반대로 환경 전체를 계속 비우지도 마세요. 먼저 대상 앱을 종료했다가 다시 열고, 필요하면 기기를 정상적으로 재시동한 뒤 기록된 DNS 확인과 연결 결과를 비교하세요.

주소 계열, 암호화 DNS, 대상 서비스 문제를 구분하세요

IPv4와 IPv6 레코드가 모두 있을 때는 네트워크마다 접속 가능 여부가 다를 수 있습니다. 특정 네트워크에서만 대기 현상이 나타난다면 도메인이 존재하지 않는다고 바로 결론 내리지 말고 최종적으로 사용한 주소와 연결 오류를 확인하세요. IP 주소를 직접 입력해 웹 페이지를 여는 방법도 신뢰할 만한 대체 테스트가 아닙니다. 웹 사이트가 호스트 이름, 인증서 이름, 가상 호스트에 의존할 수 있기 때문입니다. IP 접속 실패만으로 원래 도메인의 DNS가 잘못됐다고 단정할 수 없습니다.

암호화 DNS를 사용할 때도 접속 가능한 연결 경로가 필요하며 인증서와 시스템 시간이 관련될 수 있습니다. 암호화를 켰다고 모든 네트워크에서 DNS 확인이 성공하는 것은 아닙니다. 변경 후 모든 도메인 확인이 실패하면 이전에 정상 작동한 설정으로 되돌리고 DNS 서비스에 접속할 수 있는지, 경로 의존 문제가 있는지 확인한 뒤 하나씩 조정하세요. DNS 연결의 신원 확인 문제를 감추려고 인증서 검증을 끄지 마세요.

같은 도메인이 다른 정상 네트워크에서도 확인되지 않는다면 도메인 자체가 문제일 수 있습니다. 주소는 확인되지만 연결에 실패한다면 서버와 규칙 장으로 돌아가세요. 수정 후에는 이전에 실패한 도메인, 정상 비교용 도메인, 현재 서버 도메인을 각각 확인해 한 단계만 해결된 것은 아닌지 살펴보세요. 증상별 상세 비교는 DNS 확인 실패 점검 노트를 참고하세요.

07 / BATTERY AND ACTIVITY

배터리 소모 이상, 발열, 백그라운드 반복 연결

시스템 배터리 사용량의 비율은 통계 기간과 기기 전체 사용량을 함께 고려해야 합니다. 특정 앱의 비율이 높아진 것은 다른 앱의 사용량이 줄었기 때문일 수도 있고, 연결을 통해 처리된 트래픽, 지속적인 재시도, 화면에서 실행한 진단 때문일 수도 있습니다. 백분율 하나만 보고 배터리 소모 이상을 판단하지 마세요. 충전 여부, 화면 사용량, 네트워크 유형, 실제 발열을 기록한 뒤 비슷한 조건끼리 비교하세요.

유휴 상태의 배터리 소모와 전송 중 소모를 구분하세요

파일 다운로드, 고화질 동영상 재생, 클라우드 동기화, 개인용 핫스팟은 지속적인 네트워크 활동을 일으킵니다. 연결이 해당 트래픽을 처리하면서 기기 작업량이 늘 수 있지만 실제 요청을 시작한 앱이 Shadowrocket이 아닐 수도 있습니다. 본인이 알고 있는 대용량 작업을 잠시 중단하고 다른 사용 습관은 그대로 둔 채 유휴 상태에서도 발열이 계속되는지 관찰하세요. 집중 테스트를 실행하면서 배터리 변화를 보고 평소 대기 상태의 소모량을 판단하지 마세요.

시스템 Settings의 배터리 기록에서 문제가 발생한 시간대에 맞춰 전경·백그라운드 활동과 다른 앱의 동시 실행 여부를 확인하세요. 기기가 충전 중이었거나 시스템 업데이트 직후였거나 사진을 처리 중이었다면 따로 기록하세요. 이런 조건은 온도와 배터리 소모에 영향을 주므로 함께 비교하면 원인을 분리하기 어렵습니다. 기록에는 “같은 네트워크, 화면 잠금, 동기화 중지 후에도 반복 연결”처럼 구체적인 내용을 적으세요. “배터리가 더 빨리 닳는 느낌”만으로는 부족합니다.

On Demand와 네트워크 전환을 확인하세요

On Demand는 조건에 따라 연결을 설정하는 기능이지 문제 해결을 위해 항상 켜 두어야 하는 필수 조건은 아닙니다. 연결을 끈 뒤 다시 자동으로 켜지는 문제가 있다면 본인의 On Demand 조건과 시스템의 다른 자동 연결 설정을 먼저 확인하세요. 관련 자동 동작을 잠시 중지하고 수동 연결로 비교한 뒤 안정성을 확인하고 하나씩 복원하세요. 여러 조건이 동시에 영향을 주어 연결이 반복해서 시작되거나 중지되지 않도록 합니다.

약한 Wi-Fi 신호, Wi-Fi 범위에 자주 들어오고 나가는 상황, 셀룰러 신호 변화는 연결 재설정을 일으킬 수 있습니다. 이때 지속적인 재시도 자체가 기기 자원을 사용하고 웹 페이지가 잠시 끊길 수도 있습니다. 신호가 안정적인 곳에 기기를 두고 테스트한 뒤 이동 중 결과와 비교하세요. 네트워크 전환 때만 문제가 생긴다면 연결 전후의 네트워크를 기록하세요. 모든 백그라운드 활동을 바로 클라이언트 문제로 판단하지 마세요.

시스템 배터리 통계의 시간대, 현재 네트워크, 기기 온도를 기록하고 능동적인 속도 테스트를 중지하세요.
확인된 대용량 작업을 잠시 중단하고 유휴 상태에서도 요청이 계속 발생하는지 관찰하세요.
On Demand를 잠시 중지하고 수동 연결에서도 반복 연결이 발생하는지 비교하세요.
본인이 보유한 안정적인 서버 하나로만 바꿔 재시도와 발열이 함께 줄어드는지 확인하세요.
필요한 기능을 복원한 뒤 다시 확인하고 문제를 재현하는 데 필요한 최소 조건을 기록하세요.

불필요한 진단 부하를 줄이세요

상세 진단 기록을 장시간 켜 두거나 Connectivity Test를 계속 실행하거나 모든 구독을 반복 업데이트하면 네트워크와 기기 처리 작업이 추가됩니다. 문제를 점검할 때 필요한 기록을 잠시 켜고 유효한 실패 사례를 한 번 확보한 뒤 중지하세요. 진단 작업을 백그라운드에 계속 두고 연결 상태 표시처럼 사용하지 마세요. 일반 설정으로 복구한 뒤에도 다른 자동화 과정이 테스트나 요청을 반복 실행하지 않는지 확인하세요.

특정 서버에서 핸드셰이크가 계속 실패하면 연결 재시도에 안정적인 연결보다 더 많은 자원이 들 수 있습니다. 이때는 로그를 줄이는 데 그치지 말고 서버 시간 초과 장을 참고해 주소, 인증, 네트워크 조건부터 해결하세요. 특정 대상 앱에서만 요청이 계속 실패한다면 해당 앱에 적용된 규칙과 DNS도 확인하세요. 잘못된 정책 때문에 요청이 반복되어 배터리 소모가 늘 수 있지만 근본 원인은 대상의 연결 경로에 있을 수 있습니다.

기기가 눈에 띄게 뜨거워지면 부하가 큰 작업을 중지하고 통풍이 되는 정상적인 환경에 두어 온도가 내려간 뒤 짧게 테스트하세요. 비정상적인 온도에서 오랜 시간 반복 측정하지 마세요. 기기 성능과 네트워크 동작이 이미 달라졌을 수 있습니다. 짧은 시간의 배터리 변화량을 하루 종일의 소모량으로 단순 환산하지 마세요. 비슷한 시간, 네트워크, 사용량으로 기록한 결과끼리 비교해야 판단에 의미가 있습니다.

08 / RECOVERY AND IPAD

업데이트 후 문제 및 iPad 복구

업데이트 후 문제가 생겼다면 실제로 무엇이 바뀌었는지 먼저 확인하세요. 앱 업데이트, 시스템 업데이트, 구독 업데이트, 설정 전환이 비슷한 시기에 이뤄졌을 수 있으므로 모두 앱 탓으로 돌릴 수는 없습니다. 마지막으로 정상 사용한 환경과 현재 환경의 차이를 기록한 뒤 앞 장의 절차에 따라 증상을 확인하세요. 가격, 시스템 요구 사항, 기기 호환성은 App Store 페이지에 표시된 내용을 기준으로 합니다. 앱은 App Store에서 받아 업데이트하며 정품 확인은 다운로드 안내를 참고하세요.

먼저 백업한 뒤 영향 범위에 따라 복구하세요

현재 설정, 직접 추가한 서버 정보, 필요한 구독 주소를 보존하고 백업을 본인이 관리할 수 있는 위치에 저장하세요. 암호나 구독 매개변수가 포함된 파일을 공개적으로 공유하지 마세요. 그런 다음 기기를 정상적으로 재시동하고 기존 네트워크와 대상으로 한 번 더 재현하세요. 정상으로 돌아왔다면 일시적인 실행 상태였는지 지켜보세요. 계속 실패하면 기본 네트워크, 연결 스위치, 서버, 규칙, DNS를 각각 확인하고 모든 데이터를 바로 지우지 마세요.

설정 편집 직후 문제가 생겼다면 이전에 정상 작동한 설정 사본으로 먼저 복원하세요. 구독 업데이트 직후라면 서버 변경과 정책 참조를 확인하세요. 시스템 업그레이드 후 VPN 권한 상태에만 문제가 있다면 시스템 Settings에서 본인의 VPN 설정을 확인하세요. 알려진 변경 사항을 단계별로 되돌리세요. 재설치, 설정 삭제, 네트워크 재설정을 연속으로 한꺼번에 실행하지 마세요.

앱을 다시 받기 전에 구매 당시 사용한 Apple 계정과 구매 내역을 확인하세요. 앱 구매 내역은 서버 정보 백업이 아니며 앱을 다시 받아도 만료된 구독이 자동으로 복구되지는 않습니다. 구매 항목 복원 절차와 주의 사항은 기기 변경 및 재설치 후 복원을 참고하고 기존 계정으로 구매 복원하기도 확인할 수 있습니다. 연결 문제를 해결하려고 먼저 계정에서 로그아웃해 변수를 추가하지 마세요.

iPad에서 구매, 설정, 실제 연결을 구분하세요

iPad에서는 앱을 받을 수 있는지, 본인의 설정을 가져왔는지, 연결이 실제로 켜졌는지 각각 확인해야 합니다. 이 세 가지는 서로를 대신하지 않습니다. 같은 구매 계정으로 구입한 앱을 받을 수 있는지와 범용 구매 적용 범위는 App Store 페이지에 표시된 내용을 기준으로 합니다. 앱을 성공적으로 받았더라도 본인의 구독, 서버, 규칙은 별도로 확인해야 합니다. 다른 기기에서 정상 작동한다고 해서 이 기기에도 같은 설정이 있다고 가정하지 마세요.

가로 모드, 세로 모드, 화면 분할에 따라 화면 안에서 메뉴 위치가 달라질 수 있지만 문제 해결 순서는 바뀌지 않습니다. 편집 전에 현재 선택된 서버 그룹과 Config를 확인해 분할 화면에서 다른 항목을 수정하지 않도록 하세요. 창을 전환한 뒤 옵션이 예상과 다르면 Home으로 돌아가 현재 선택을 다시 확인한 뒤 실제 요청을 테스트하세요. 창의 위치나 마지막으로 열었던 화면만으로 현재 적용 상태를 판단하지 마세요.

Wi-Fi만 연결할 수 있는 iPad와 셀룰러 연결도 가능한 기기는 비교할 수 있는 네트워크 조건이 다릅니다. 셀룰러 네트워크로 전환할 수 없다면 본인이 사용할 권한이 있는 다른 정상 Wi-Fi 네트워크에서 테스트하세요. 같은 설정이 두 기기에서 다르게 작동한다면 네트워크, 시스템 권한, Global Routing, 현재 서버, 실제 설정 내용을 비교하세요. 서버 이름만 비교하면 매개변수 차이를 놓치기 쉽습니다.

잠금 화면, 네트워크 전환, 특정 앱 문제를 확인하세요

iPad에서 화면을 잠근 뒤 접속 복구가 느리다면 먼저 Wi-Fi가 다시 연결되는지 확인한 다음 VPN 연결이 재설정되는지 살펴보세요. 상태 표시만 보고 판단하지 마세요. 화면 환경에 따라 표시되는 정보가 다를 수 있습니다. 잠금을 해제한 뒤 고정된 웹 페이지로 재현하고 첫 요청이 실패하는지, 이후 자동으로 복구되는지 기록하세요. 특정 네트워크에서만 발생한다면 해당 네트워크의 연결 안정성과 자동 인증 조건을 먼저 확인하세요.

외장 키보드, 브라우저의 여러 창, 다른 앱의 웹 페이지는 서로 다른 캐시와 세션을 사용할 수 있습니다. 창 하나에서만 문제가 생기면 해당 창을 닫고 대상을 다시 열어 로그인이나 캐시 문제인지 확인하세요. 다른 앱이 정상이라면 기기 전체의 네트워크 설정을 바로 재구성할 필요는 없습니다. 모든 앱에서 실패할 때 기본 네트워크와 전역 라우팅을 다시 확인하고 좁은 범위에서 전체 범위 순서로 처리하세요.