Shadowrocket문제 해결 가이드

01 / CONNECTION SWITCH

연결 스위치가 켜진 상태로 유지되지 않음

스위치를 누른 직후 꺼지는 경우, 시스템 승인이 완료되지 않은 경우, 연결이 잠시 표시된 뒤 끊기는 경우는 서로 다른 현상입니다. 먼저 Shadowrocket을 열고 Home 화면에서 모든 매개변수가 입력된 서버를 선택했는지 확인하세요. 비어 있는 구독 그룹만 선택한 것은 아닌지도 살펴보세요. 스위치가 꺼지기 전에 안내 메시지가 표시됐는지, 시스템 설정에서 해당 VPN의 연결 상태가 어떻게 표시되는지 기록하세요. 터널이 아직 설정되지 않았으므로 DNS를 바꾸거나 규칙을 한꺼번에 수정하지 마세요. 이런 설정은 현재 문제의 원인을 설명하기 어렵습니다.

시스템 승인과 선택 항목 확인

처음 연결할 때 시스템에서 VPN 구성을 추가하도록 허용하고 기기 잠금 해제 방식으로 확인하라는 메시지가 표시될 수 있습니다. 요청을 취소하거나 팝업을 닫거나 확인을 완료하지 않으면 연결이 진행되지 않을 수 있습니다. 앱으로 돌아가 다시 시도하고, 시스템 안내를 끝까지 읽은 뒤 허용 여부를 결정하세요. 관련 구성이 이미 저장되어 있다면 시스템 설정에서 VPN을 검색해 구성이 있는지, 이번에 사용하는 앱에 해당하는지 확인하세요. 시스템 설정의 경로는 버전에 따라 달라질 수 있으므로 기기에 실제로 표시되는 항목을 기준으로 확인하세요.

승인 메시지가 표시되지 않는다면 앱이 저장하지 않은 편집 화면에 머물러 있지는 않은지 먼저 확인하세요. Home으로 돌아가 이미 등록된 서버를 다시 선택한 뒤 연결을 시도하세요. 한 번 실패한 기록만으로 설정이 손상됐다고 판단하기는 어렵습니다. 현재 네트워크 종류, 방금 다른 네트워크에서 전환했는지, 기기 시간이 자동으로 설정되어 있는지도 함께 기록하세요. 시간이 크게 어긋나면 이후 인증서 확인에 영향을 줄 수 있지만, 이 문제를 우회하려고 인증서 검증을 끄지는 마세요.

자동 연결 및 구성 충돌 확인

On Demand를 일시적으로 끈 뒤 스위치를 수동으로 조작해 보세요. On Demand는 조건에 따라 연결을 시작하는 기능입니다. 문제를 점검하는 동안 계속 작동하면 수동으로 연결을 끊은 뒤 다시 연결되어 스위치가 오작동하는 것처럼 보일 수 있습니다. 기기에서 다른 VPN 구성이나 조직이 관리하는 네트워크 정책이 작동 중인지도 확인하세요. 직접 확인했고 조정 권한이 있는 연결만 중지하세요. 출처를 알 수 없는 관리 프로파일은 삭제하지 마세요. 관리 기기라면 관리 담당자에게 사용할 수 있는 네트워크 설정을 확인해야 합니다.

현재 서버를 그대로 둔 채 인터넷이 정상적으로 연결되는 Wi-Fi와 셀룰러 네트워크에서 각각 다시 시도하세요. 웹 인증이 필요한 특정 Wi-Fi에서만 문제가 발생한다면 Shadowrocket 연결을 끊고 해당 네트워크에 로그인하거나 이용 약관에 동의한 다음 앱으로 돌아와 연결하세요. 모든 네트워크에서 같은 단계에 실패하고 시스템 승인도 완료됐다면 현재 서버 매개변수, 설정 해석 안내, 앱 기록을 확인하세요. 네트워크를 바꾸는 것만으로 문제가 해결됐다고 판단하지 마세요.

마지막 수단으로 시스템 구성을 다시 설정

먼저 현재 연결을 완전히 종료한 뒤 앱을 다시 여세요. 문제가 계속되면 기기를 재시동한 뒤 다시 확인할 수 있습니다. 해당 VPN 구성을 제거하고 다시 추가해야 한다면 기존 서버와 설정을 안전하게 저장했는지, 승인을 다시 완료할 수 있는지 먼저 확인하세요. 시스템 VPN 항목을 제거해도 구독이 복구되지는 않으며 서버 측 문제도 해결되지 않습니다. 재설치를 첫 단계로 삼지 마세요. 로컬 데이터가 자동으로 복원되지 않을 수 있고, 재설치하면 문제를 확인하는 데 유용한 기록이 사라질 수 있습니다.

이 단계의 통과 기준은 수동 연결 시 스위치가 바로 꺼지지 않고, 시스템에서 해당 연결 상태가 유지되며, 승인 요청이 반복해서 표시되지 않는 것입니다. 계속 실패한다면 ‘누른 뒤 몇 초 만에 꺼지는지, 팝업 원문, 네트워크 종류, 자동 연결 사용 여부’를 간단히 기록하세요. 두 종류의 네트워크에서 같은 오류가 반복된다는 기록은 ‘스위치가 안 켜진다’는 설명보다 원인을 찾는 데 도움이 됩니다. 구매나 설치 경로에 관한 질문은 정품 확인 안내를 참고하세요.

02 / CONNECTED BUT OFFLINE

연결됨으로 표시되지만 인터넷에 접속할 수 없음

시스템에서 VPN 연결됨으로 표시되지만 웹페이지가 열리지 않는다면 ‘터널이 연결된 상태’와 ‘요청이 성공한 상태’를 구분해야 합니다. 웹페이지에 접속할 때는 도메인 조회, 규칙 매칭, 서버 연결, 대상 서비스 응답이 차례로 이루어질 수 있으며, 어느 단계에서든 실패하면 로딩이 계속될 수 있습니다. 평소 정상적으로 열리는 페이지 하나를 테스트 대상으로 정하고 전체 오류 유형을 기록하세요. 웹사이트를 계속 바꾸면 매번 대상과 접속 조건이 달라져 결과를 비교하기 어렵습니다.

직접 연결과 프록시를 비교해 확인

먼저 Shadowrocket 연결을 끊고 현재 네트워크에서 테스트 페이지에 접속할 수 있는지 확인하세요. 연결을 끊어도 실패한다면 Wi-Fi 로그인, 셀룰러 데이터 권한, 라우터 또는 대상 서비스 문제부터 확인해야 합니다. 기본 네트워크가 정상이라면 연결한 뒤 Global Routing을 확인하세요. 임시 테스트에서는 서버를 그대로 두고 해당 설정 하나만 변경하세요. 테스트가 끝나면 원래 필요한 모드로 되돌려 임시 상태를 계속 사용하지 않도록 합니다.

Proxy에서는 접속되지만 Config에서는 안 된다면 현재 활성화된 Config, 매칭 규칙, 해당 정책을 먼저 확인하세요. 바로 서버가 작동하지 않는다고 단정하지 마세요. Direct에서는 접속되지만 Proxy에서 실패한다면 선택한 서버, 프로토콜 매개변수, 프록시 경로를 확인해야 합니다. 연결된 상태에서 Direct로 테스트하는 것과 앱 연결을 완전히 끊는 것은 같지 않습니다. DNS 설정 등 조건이 다를 수 있으므로 보조 근거로만 활용하고 기본 네트워크 테스트를 대신하지 마세요.

실제로 매칭된 규칙 확인

Config 목록에서 방금 가져왔지만 선택하지 않은 파일이 아니라 예상한 파일이 실제로 활성화되어 있는지 확인하세요. 규칙은 보통 순서대로 매칭되며 앞에서 매칭된 항목이 이후 처리에 영향을 줍니다. 따라서 파일 맨 아래에 규칙을 추가해도 기존 매칭 결과가 바뀌지 않을 수 있습니다. 요청 기록에서 대상 도메인, 매칭된 규칙, 최종 정책을 함께 확인하세요. 설정에 정책 그룹이 있다면 그룹 안에서 현재 선택된 항목도 확인해야 합니다. 그룹 이름이 맞더라도 사용 가능한 서버를 가리킨다는 보장은 없습니다.

아래는 규칙 순서를 이해하기 위한 간단한 예시이며, 완전한 설정이 아니므로 현재 사용하는 파일을 그대로 덮어쓰지 마세요. 첫 번째 규칙은 예시 도메인만 매칭하고, 두 번째 규칙은 지정한 사설 주소 범위를 처리하며, 마지막 규칙은 앞선 규칙에 매칭되지 않은 요청을 처리합니다. 실제 문제를 점검할 때는 백업 복사본에서 최소한으로 수정하고, 변경 사항이 현재 활성화된 설정에 적용되는지 확인하세요.

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

모든 요청 실패와 특정 서비스 실패 구분

모든 페이지에서 문제가 발생한다면 서버, DNS, 기본 정책 등 공통 경로를 먼저 확인하세요. 특정 서비스만 문제가 있다면 해당 서비스의 도메인, 로그인 상태, 대상 서비스의 제한, 서비스가 사용하는 다른 연결을 확인해야 합니다. 하나의 페이지가 여러 도메인에 요청할 수 있으므로 첫 화면이 열려도 이미지, 로그인 API, 미디어 요청이 같은 경로를 사용한다는 뜻은 아닙니다. 페이지의 본문이 표시된다는 이유만으로 모든 규칙이 올바르다고 판단하지 마세요.

매번 테스트할 때 대상 연결을 새로 설정하세요. 필요하면 해당 페이지를 닫았다가 다시 열어 기존 연결을 재사용해 생길 수 있는 오판을 줄이세요. 대상 페이지와 주요 기능을 사용할 수 있고, 기록된 정책이 예상한 것과 일치하며, 다시 테스트해도 성공하는 것이 정상 복구의 기준입니다. 특정 앱에서만 문제가 발생한다면 앱의 네트워크 권한과 캐시를 먼저 확인한 뒤 Shadowrocket을 점검하세요. 일반적인 개념은 자주 묻는 질문에서 확인해 앱 로그인 오류를 연결 문제로 오인하지 않도록 하세요.

03 / SERVER TIMEOUT

서버 시간 초과 및 프로토콜 매개변수

Connectivity Test 결과는 어떤 방식으로 테스트했는지와 함께 살펴봐야 합니다. 시간 초과는 제한된 조건에서 이번 테스트가 기대한 응답을 받지 못했다는 뜻이지, 서버를 영구적으로 사용할 수 없다는 증거는 아닙니다. 응답이 확인됐다고 실제 웹페이지 접속까지 성공하는 것도 아닙니다. 테스트 방식과 오류 메시지를 기록한 다음 같은 서버로 실제 요청을 보내세요. 테스트는 성공하지만 서비스가 작동하지 않으면 대상, 규칙, DNS를 확인하세요. 테스트와 실제 요청이 모두 실패하면 서버 주소와 프로토콜 매개변수를 하나씩 점검하세요.

주소, 포트, 인증 정보부터 확인

해당 항목의 편집 화면을 열고 주소, 포트, 프로토콜 유형을 본인이 보유한 서버 원본 정보와 하나씩 비교하세요. 주소 입력란에 해당 필드에 속하지 않는 경로나 불필요한 공백이 들어가면 안 되며, 포트는 서버에서 실제로 수신 대기 중인 포트와 일치해야 합니다. 구독으로 가져온 항목은 링크 만료나 정보 변경으로 오래된 상태일 수도 있습니다. 클라이언트를 계속 수정하다 우연히 한 번 성공하기를 기대하기보다 원본 정보가 여전히 유효한지 먼저 확인하세요.

인증 필드는 현재 프로토콜에 맞게 정확히 입력해야 합니다. Shadowsocks는 암호화 방식과 비밀번호를 확인하세요. VMess, VLESS 등은 사용자 식별 정보와 서버에서 요구하는 전송 설정을 확인해야 합니다. Trojan은 비밀번호와 보안 연결 관련 매개변수를 점검하세요. 프로토콜마다 비슷해 보이는 필드라도 서로 바꿔 사용할 수 없습니다. 복사할 때 전각 기호, 줄바꿈, 앞뒤 공백에 유의하되 전체 인증 정보를 다른 사람에게 보내지 마세요. 각 필드가 일치하는지만 설명하세요.

TLS 오류와 전송 오류 구분

서버 주소, TLS에서 사용하는 이름, 전송에 필요한 호스트 필드는 서로 다를 수 있지만, 추측해서 입력하지 말고 서버 원본 정보에 따라야 합니다. 인증서 오류가 발생하면 먼저 기기 시간을 맞추고 이름과 서버 인증서 상태를 확인하세요. 검증 건너뛰기를 일반적인 해결 방법으로 사용하지 마세요. 오류 메시지만 바뀔 뿐 인증 정보 불일치의 근본 원인은 해결되지 않으며 보안 연결의 신뢰도도 낮아집니다.

서버에서 특정 전송 유형을 사용한다면 클라이언트의 경로, 호스트 필드, 관련 옵션이 서버 설정과 일치해야 합니다. 필드 하나가 빠져도 접속은 되지만 이후 핸드셰이크가 실패할 수 있습니다. 여러 경로나 보안 옵션을 한꺼번에 시도하지 말고 원본 정보의 매개변수로 되돌린 뒤 테스트하세요. 오류가 시간 초과에서 명확한 인증 또는 핸드셰이크 안내로 바뀌었다면 유의미한 진전입니다. 실패 단계가 달라졌다는 뜻입니다.

네트워크 경로와 서버 측 범위 확인

서버 항목은 그대로 두고 네트워크를 바꿔 보세요. 한 네트워크에서만 실패한다면 네트워크 종류와 프로토콜 전송 특성을 기록하세요. 일부 프로토콜은 UDP에 의존하며 네트워크마다 이런 트래픽을 다르게 처리할 수 있지만, 한 번 실패한 것만으로 원인을 확정할 수는 없습니다. Hysteria2에 대한 배경은 Hysteria2 프로토콜 기초에서 확인하세요. 실제 오류와 반복 가능한 네트워크 비교를 기준으로 점검해야 합니다.

본인이 사용하는 다른 유효한 항목은 같은 네트워크에서 정상인데 현재 항목만 여러 네트워크에서 실패한다면 기존 서비스 제공자에게 서버 수신 상태, 인증 정보, 서비스 상태를 확인하세요. 클라이언트 기록만으로 원격 프로세스가 실행 중인지 확인하거나 서버 설정을 수정할 수는 없습니다. 문의할 때는 민감한 정보를 가린 실패 단계, 발생 조건, 테스트 결과만 전달하면 됩니다. 구독 내용 전체를 공개할 필요는 없습니다. 문제가 해결된 뒤에는 실제 요청으로 다시 테스트하고 재연결도 성공하는지 확인해 한 번의 우연한 성공을 복구로 오인하지 마세요.

04 / SUBSCRIBE

구독 가져오기 및 업데이트 실패

구독 업데이트는 보통 링크 내용 가져오기, 형식 인식, 로컬 항목 교체의 여러 단계로 이루어집니다. 내용을 가져오지 못한 경우, 형식을 인식하지 못한 경우, 업데이트에 성공했지만 서버를 사용할 수 없는 경우는 서로 다른 문제입니다. 먼저 안내 메시지가 어느 유형에 해당하는지 확인하고 해당 단계를 점검하세요. 구독 링크는 본인이 보유한 원본 정보에서 가져와야 합니다. 구독은 설정 데이터를 가져오는 경로이지 앱 구매 증명이 아닙니다. 구독 업데이트와 Shadowrocket 앱 업데이트도 별도로 진행해야 합니다.

인증 정보를 공개하지 않고 링크 확인

Subscribe 항목의 주소가 온전한지, 특히 물음표 뒤의 매개변수를 확인하세요. 공유 과정에서 링크가 잘리거나 끝에 한글 문장 부호, 설명, 줄바꿈이 붙을 수 있습니다. 원본에서 다시 복사해 현재 저장된 내용과 부분별로 비교하세요. 도메인이 같다고 주소도 같다고 판단하지 마세요. 경로나 매개변수가 달라지면 전혀 다른 내용을 가리킬 수 있습니다. 아래 주소는 구조를 보여주기 위한 예시일 뿐 실제 서비스에 사용할 수 없으며, 클릭해서 가져오는 링크도 아닙니다.

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

완전한 구독 링크는 접근 권한을 포함할 수 있으므로 비밀번호처럼 주의해서 다루세요. 낯선 변환 페이지에 입력하지 말고 문의용 스크린샷에도 표시하지 마세요. 링크가 만료됐는지 확인해야 한다면 본인의 서비스 관리 페이지를 확인하거나 기존 서비스 제공자에게 문의하세요. 링크를 다시 복사한 뒤 기존 구독을 업데이트하고 결과를 확인하세요. 같은 이름의 그룹을 여러 개 만들면 현재 선택된 것이 기존 데이터인지 새 데이터인지 구분하기 어려워집니다.

가져오기·형식·항목, 세 단계로 점검

가져오기 단계에서 실패하면 현재 기본 네트워크, 도메인 조회, 링크 접근 조건을 확인하세요. 일부 링크는 특정 네트워크 경로에서만 접근할 수 있습니다. 업데이트 당시 연결이 끊긴 상태였는지 연결된 상태였는지 기록하고 다른 조건은 그대로 둔 채 비교하세요. 웹페이지에서 로그인 화면이 열린다고 해서 구독 API가 앱에서 필요한 내용을 반환하는 것은 아닙니다. 실제 응답이 웹페이지, 오류 안내, 인증 화면이라면 계속 재시도해도 서버 목록으로 바뀌지 않습니다.

형식을 인식하지 못한다면 구독 주소가 아니라 관리 페이지 주소나 웹 공유 주소를 복사한 것은 아닌지 확인하세요. 응답 내용의 인코딩을 임의로 바꾸거나 모르는 필드를 삭제하지 마세요. 기존 서비스 제공자가 제공한 형식이 Shadowrocket에서 지원되는지 먼저 확인해야 합니다. 가져오기는 되지만 항목 일부만 나타난다면 데이터 형식, 항목 유효성, 매개변수 인식 문제일 수 있습니다. 기존 데이터를 보존하고 하나씩 비교하세요. 그룹 전체를 바로 삭제하지 마세요.

업데이트 후 선택 항목과 참조 확인

업데이트로 서버 이름, 그룹 내용, 선택 가능한 항목이 바뀔 수 있습니다. 현재 선택 항목이 이미 삭제된 항목을 참조하면 ‘업데이트 후 작동하지 않는’ 것처럼 보일 수 있습니다. Home으로 돌아가 현재 선택 항목을 확인하고 Config에서 이름을 참조하는 정책이나 그룹이 있는지 살펴보세요. 업데이트 후 유효한 항목으로 직접 테스트를 먼저 완료한 다음 복잡한 규칙을 다시 적용하면 데이터 변경과 규칙 참조 오류를 구분할 수 있습니다.

수동 업데이트가 안정적으로 작동한 뒤 앱을 열 때 자동 업데이트하는 설정 등을 고려하세요. 자동 업데이트를 켜도 앱을 열 때마다 새 데이터를 가져온다고 보장할 수는 없습니다. 네트워크, 링크 유효 기간, 응답 내용에 영향을 받습니다. 업데이트를 자주 반복하면 기존 서비스에서 요청을 제한할 수 있으므로 제공된 갱신 안내를 따르세요. 실패하면 안내를 보관하고 적절한 시간 간격을 두세요. 계속 누르는 것으로 진단을 대신하지 마세요. 자세한 방법은 구독 업데이트 가이드를 참고하세요.

이 장의 확인 절차는 올바른 링크 저장, 수동 업데이트 완료, 항목 변경 확인, 서버 재선택, 대상 서비스 실제 접속까지 한 번에 진행하는 것입니다. 기존 항목은 작동하지만 업데이트에 실패했다면 사용 가능한 상태를 유지하면서 업데이트 경로를 점검하세요. 업데이트는 정상인데 모든 연결이 실패한다면 서버 시간 초과 장을 확인하세요. 문의할 때 ‘가져오기 실패’, ‘형식 인식 실패’, ‘업데이트 후 연결 실패’로 구체적으로 설명하면 ‘구독에 문제가 있다’고만 하는 것보다 원인을 찾기 쉽습니다.

05 / PERFORMANCE

속도 저하 및 연결 불안정

속도 저하는 첫 페이지가 느리게 열리는 경우, 전송이 계속 느린 경우, 동영상이 간헐적으로 멈추는 경우, Wi-Fi 전환 후 잠시 연결이 끊기는 경우를 모두 가리킬 수 있습니다. 서로 다른 현상을 한데 묶지 마세요. 먼저 ‘처음 열 때는 오래 걸리지만 전송이 시작된 뒤에는 정상’처럼 증상을 한 문장으로 정리하고 해당하는 점검 방향을 선택하세요. 응답 시간, 전송 속도, 안정성은 서로 다른 지표이며 Connectivity Test 한 번으로 전체 사용 경험을 판단할 수 없습니다.

비교 가능한 테스트 조건 만들기

기기, 네트워크, 서버, 대상 콘텐츠를 동일하게 유지하고 대량의 백그라운드 전송은 중지한 뒤 같은 작업을 반복하세요. 기본 네트워크 테스트는 Shadowrocket 연결을 끊은 상태에서 먼저 진행해야 합니다. 이때도 느리다면 신호, 라우터 부하, 네트워크 자체를 우선 확인하세요. 시간대별로 비교할 때는 조건 변화를 기록하세요. 대상 서비스와 원격 경로의 부하도 달라질 수 있습니다. 서로 다른 시간에 다른 웹사이트에서 나타난 속도를 같은 서버의 성능 평가에 직접 사용하지 마세요.

Wi-Fi에서만 느리다면 액세스 포인트에 가까이 가서 다시 테스트하고, 신호가 약하거나 혼잡한 환경인지 확인하세요. 셀룰러 네트워크는 안정적인데 같은 Wi-Fi에서 자주 끊긴다면 액세스 네트워크 범위로 점검을 좁히세요. 반대의 경우 셀룰러 신호, 기기의 데이터 설정, 네트워크 전환 시점을 확인하세요. 처음부터 모든 네트워크 설정을 재설정하지 마세요. 조건이 너무 많이 바뀌고 기존 네트워크 정보가 삭제되어 이후 비교가 어려워질 수 있습니다.

지연이 발생하는 단계에 따라 점검

처음 열 때만 느리고 이후에는 정상이라면 DNS 조회와 연결 설정 과정을 먼저 살펴보세요. 새 도메인마다 대기 시간이 길지만 같은 페이지를 새로고침하면 빨라지는 경우 DNS나 최초 핸드셰이크와 관련이 있을 수 있습니다. 다만 캐시도 비슷한 차이를 만들 수 있으므로 여러 번 확인해야 합니다. 페이지가 빠르게 로드되기 시작하지만 대용량 파일 전송이 계속 불안정하다면 DNS 설정만 조정하지 말고 패킷 손실, 원격 서버 부하, 대상 서비스의 속도 제한, 로컬에서 동시에 사용 중인 트래픽을 확인하세요.

특정 앱에서만 느리다면 앱이 실제로 요청하는 대상과 매칭된 규칙을 확인하세요. 미디어, 이미지, 로그인 API가 서로 다른 도메인을 사용할 수 있어 한 과정이 다른 정책으로 처리되면 전체 사용 경험이 불안정해질 수 있습니다. Global Routing을 잠시 바꿔 비교할 때는 대상 연결을 새로 설정해 기존 세션이 이전 경로를 계속 사용하지 않도록 하세요. Proxy는 안정적이지만 Config에서는 속도가 달라진다면 정책 그룹이 자동으로 전환되는지, 같은 서비스의 여러 도메인이 서로 다른 경로로 처리되는지 확인하세요.

통계는 참고 자료로 활용하고 결과로 단정하지 않기

Data를 통해 서버별 또는 앱 관련 관점에서 트래픽이 발생한 위치를 살펴볼 수 있지만, 통계 범위, 연결 재사용, 시스템 동작이 측정값에 영향을 줍니다. ‘요청이 예상한 경로를 거쳤는지’를 확인하는 데는 유용하지만 숫자 하나만으로 원격 대역폭을 판단하기에는 적합하지 않습니다. 자세한 의미는 Data 페이지 통계 안내를 참고하세요. 트래픽을 기록할 때는 측정 시간도 함께 적어 이전 연결의 누적값을 이번 테스트 결과로 오인하지 않도록 하세요.

‘더 빠를 것 같다’는 이유로 프로토콜 매개변수를 임의로 바꾸지 마세요. 먼저 서버에서 요구하는 전송 방식, 암호화 방식, 보안 설정과 일치해야 합니다. 특히 UDP를 사용하는 프로토콜은 현재 네트워크에서 해당 트래픽을 안정적으로 처리할 수 있는지 확인해야 합니다. 모든 네트워크에 적용되는 최적 설정은 없습니다. 특정 네트워크에서 특정 프로토콜만 반복해서 실패한다면 같은 네트워크에서 다른 유효한 연결을 테스트한 결과를 기록한 뒤 기존 서비스 제공자에게 확인하세요.

실제 사용 환경에서 연속으로 비슷한 페이지를 열거나 파일을 전송하거나 네트워크 전환 후 다시 접속하는 방식으로 최종 확인하세요. 순간적으로 높은 측정값이 나오는 것만으로 테스트 성공이라고 판단해서는 안 됩니다. 작업을 반복해도 뚜렷한 지연이 없는지 확인해야 합니다. 문제가 특정 시간대나 대상에 집중된다면 시간대와 대상 유형만 기록하세요. 클라이언트 설정을 계속 늘릴 필요는 없습니다. 원격 서버나 기본 네트워크의 제한을 확인했다면 로컬 규칙을 더 수정해도 근본 원인을 해결하기 어렵습니다.

06 / DNS AND ROUTING

DNS 조회 및 규칙 경로

DNS는 도메인을 연결 가능한 주소로 변환하지만 도메인을 조회할 수 있다고 해당 주소에 접속할 수 있는 것은 아닙니다. 주소에 접속할 수 있어도 보안 연결이나 앱 요청까지 성공한다는 보장은 없습니다. 도메인 조회 오류, 첫 접속 지연, 일부 도메인만 접속 실패, 예상하지 못한 규칙 적용 등이 흔한 증상입니다. 오류가 DNS와 명확히 관련 있는지 기록하고 현재 활성화된 설정과 DNS 설정의 출처를 확인하세요. 웹페이지를 열 수 없는 모든 상황을 DNS 문제로 단정하지 마세요.

현재 적용 중인 DNS 출처 확인

현재 Config와 관련 DNS 설정을 확인해 시스템 DNS를 사용하는지, 사용자 지정 DNS를 쓰는지, DNS over HTTPS를 포함하는 방식을 사용하는지 살펴보세요. 방금 편집한 파일만 보지 말고 실제로 활성화된 파일인지도 확인해야 합니다. 설정에 DNS 항목이 여러 개 있으면 변경하기 전에 우선순위와 덮어쓰기 관계를 파악하세요. 기기에 조직이 관리하는 DNS 설정이 있는지도 확인합니다. 여러 출처가 겹쳐 있으면 한 항목만 바꾼 것처럼 보여도 실제 요청 경로는 달라지지 않을 수 있습니다.

원래 설정을 먼저 저장한 다음, 작동 여부가 확인된 가장 간단한 DNS 방식으로 기준 상태를 만드세요. DNS over HTTPS는 해당 서비스의 엔드포인트에 접속해야 하므로 정상적인 연결과 올바른 이름 확인이 필요합니다. 아직 설정되지 않은 프록시 경로를 통해 DNS 서비스에 접속하도록 구성하면 서로 의존하는 상황이 생길 수 있습니다. 도메인 하나가 실패했다고 DNS 주소를 계속 추가하지 마세요. 그러면 시간 초과와 대체 처리 과정을 파악하기 더 어려워집니다.

도메인 규칙과 주소 규칙 구분

DOMAIN, DOMAIN-SUFFIX 등의 규칙은 도메인 정보를 기준으로 매칭하고 IP-CIDR, IP-CIDR6, GEOIP 등은 주소를 기준으로 매칭합니다. 두 유형의 조건은 사용 시점이 다릅니다. 주소 규칙이 적용됐다고 앞서 있는 도메인 규칙이 올바르게 작성됐다는 뜻은 아닙니다. 반대로 도메인 규칙에 매칭돼도 최종 주소가 현재 경로에 적합하다는 보장은 없습니다. 요청 기록에서 실제로 어떤 규칙에 매칭됐는지 확인한 뒤 DNS 조회 결과의 문제인지, 규칙이 요청을 부적절한 정책으로 보냈는지 판단하세요.

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

이 예시는 규칙 유형과 순서를 설명하기 위한 것으로 모든 환경에 적합한 설정은 아닙니다. 여기서는 정확한 도메인 규칙과 접미사 규칙이 서로 영향을 줄 수 있으므로 실제 설정에는 꼭 필요한 항목만 남기세요. FINAL은 마지막 처리 정책이지 DNS 오류를 해결하는 스위치가 아닙니다. 문제를 점검할 때 복사본에서 대상과 관련된 최소한의 규칙만 남기고 대상 경로를 확인하세요. 원래 규칙은 한 번에 한 그룹씩 복원하면서 매번 테스트해 충돌을 쉽게 찾을 수 있도록 합니다.

동일하지 않은 테스트로 결론을 내리지 않기

브라우저에 주소를 직접 입력하는 것으로 원래 도메인에 접속하는 테스트를 대체할 수는 없습니다. 보안 연결에는 올바른 호스트 이름이 필요한 경우가 많고, 웹사이트도 이름에 따라 서비스를 구분할 수 있습니다. 따라서 ‘주소를 직접 입력했더니 실패했다’는 것만으로 네트워크가 끊겼다고 단정할 수 없습니다. 다른 기기에서 조회한 주소를 설정에 계속 입력해 두지도 마세요. 원격 주소가 바뀔 수 있고 네트워크마다 사용할 수 있는 경로도 다를 수 있습니다. 실제 요청 오류와 DNS 조회 기록을 우선 확인하세요.

DNS를 변경해도 기존 연결과 캐시가 결과에 영향을 줄 수 있습니다. 먼저 연결을 끊었다가 다시 연결하고 대상 페이지를 닫은 뒤 재시도하세요. 필요한 경우 해당 앱도 재시작합니다. 페이지를 한 번 새로고침해 변화가 없다고 수정이 효과 없다고 단정하지 말고 기기 전체의 설정을 계속 지우지도 마세요. 도메인 하나만 실패한다면 철자, 대상 서비스 상태, 다른 네트워크에서의 결과를 확인하세요. 모든 도메인이 실패한다면 DNS 서비스에 접속할 수 있는지와 설정 출처를 살펴보세요.

로컬 네트워크 이름, 기기 검색, 조직 내부 도메인을 사용하는 경우 현재 네트워크가 제공하는 DNS로만 조회할 수 있는지도 고려해야 합니다. 모든 DNS 요청을 다른 경로로 보내면 외부 웹페이지는 열려도 내부 서비스에 접속하지 못할 수 있습니다. 모든 규칙을 끄는 대신 필요한 범위에만 예외를 설정하세요. 시스템 DNS, 사용자 지정 DNS, DNS over HTTPS의 차이는 DNS 설정 비교 안내에서 확인한 뒤 같은 대상을 기준으로 이 장의 점검을 이어가세요.

07 / BATTERY AND BACKGROUND

배터리 소모 이상 및 백그라운드 연결

배터리 소모를 점검할 때는 지속적인 데이터 전송, 반복 재연결, 단순 연결 유지를 먼저 구분해야 합니다. 시스템 배터리 화면에 표시되는 앱 비율은 특정 통계 기간의 상대적인 값이지, 어떤 스위치가 항상 일정량의 배터리를 소모한다는 뜻은 아닙니다. 화면 사용 시간, 신호 품질, 백그라운드 활동이 모두 영향을 줍니다. 이상이 발생한 시간대, 기기 발열 여부, 대량 동기화 직후인지 기록한 뒤 Shadowrocket의 연결 동작과 배터리 소모가 동시에 일어나는지 확인하세요.

동일한 조건에서 관찰 시간 설정

비슷한 사용 방식을 선택해 연결을 켰을 때와 껐을 때의 기기 상태를 각각 기록하세요. 화면 밝기, 네트워크, 백그라운드 작업, 사용 시간을 가능한 한 동일하게 유지하세요. 대기 상태와 미디어를 계속 재생하는 상황을 비교해서는 안 됩니다. 연결을 끊어도 기기가 계속 뜨거우면 시스템 업데이트 후 처리, 사진 동기화, 대용량 파일 전송 등 다른 활동을 확인하세요. VPN 연결이 트래픽을 전달한다고 해서 트래픽의 출처도 반드시 프록시 클라이언트라는 뜻은 아닙니다.

Data와 요청 기록을 확인해 기기를 사용하지 않을 때도 대량 요청이 계속 발생하는지, 같은 대상에 대한 요청이 짧은 시간 동안 반복 실패하는지 살펴보세요. 자동 새로고침, 클라우드 동기화, 다른 앱의 백그라운드 작업으로 연결이 계속 사용될 수 있습니다. 먼저 트래픽을 발생시킨 작업을 파악한 뒤 해당 앱의 백그라운드 동작을 조정할지 결정하세요. 통계 비율을 낮추려고 사용 중인 설정을 바로 삭제하면 실제 트래픽 경로를 판단할 근거가 사라집니다.

현상을 숨기지 말고 반복 재연결 해결

기록에서 연결이 계속 설정됐다가 끊기는 것이 확인되면 네트워크 신호와 현재 서버의 안정성을 먼저 확인하세요. 신호가 약한 환경에서의 반복 재시도는 사용 경험에 영향을 줄 뿐 아니라 기기의 작업량도 늘립니다. 설정을 그대로 둔 채 안정적인 Wi-Fi에서 확인하세요. 정상으로 돌아온다면 기존 네트워크의 신호와 전환 동작을 점검하세요. 여러 네트워크에서 계속 끊긴다면 서버 시간 초과 장에 따라 인증, 전송, 원격 상태를 확인하세요. 이를 단순한 배터리 문제로만 보지 마세요.

On Demand는 조건이 충족되면 연결을 다시 시작할 수 있으므로 수동으로 연결을 끊은 뒤 다시 연결되어도 반드시 이상은 아닙니다. 비교 테스트를 해야 한다면 관련 자동 연결 조건을 일시적으로 끄고 원래 설정을 기록하세요. 테스트가 끝나면 다시 복원합니다. 조건이 서로 다른 두 상태 사이에서 계속 바뀌면 연결이 반복해서 시작될 수 있습니다. 서로 충돌하는 조건을 함께 설정하기보다 어떤 네트워크에서 연결하고 어떤 네트워크에서는 끊을지 명확히 정하세요.

진단 부담과 불필요한 요청 줄이기

상세 기록은 단기간 문제를 찾는 데 유용하지만 해결된 뒤에도 필요 이상의 고강도 진단을 계속 켜 둘 필요는 없습니다. 추가 기록이나 반복 테스트를 직접 활성화했다면 필요한 증거를 확보한 뒤 일반적인 사용 상태로 되돌리세요. 구독 자동 업데이트, 정책 테스트, 직접 설정한 예약 동작이 지나치게 자주 실행되는지도 확인하세요. 이런 기능은 필요한 정보를 얻기 위한 것이지 자주 새로고침할수록 더 안정적으로 작동하는 것은 아닙니다.

화면이 잠긴 뒤에도 데이터가 전송된다면 시스템이 필요한 연결을 유지하는 것은 정상일 수 있습니다. 예상한 작업이 없는데도 실패 요청이 계속 대량으로 발생한다면 요청 출처나 오류 재시도 반복을 확인하세요. 한 번 실패한 뒤 소량의 재연결이 발생하는 것과 지속적인 이상은 다르므로 관찰 시간을 두고 판단해야 합니다. 순간적인 기기 온도나 배터리 잔량 변화만으로 앱이 장시간 배터리를 소모한다고 결론 내리지 마세요.

변경을 마친 뒤 기준 상태와 같은 네트워크 및 사용 조건에서 한 차례 더 관찰하세요. 재연결 횟수가 줄고 이상 요청이 멈췄으며 실제 접속이 정상인지 확인해야 합니다. 클라이언트를 종료한 뒤에도 같은 배터리 소모가 계속되면 시스템이나 다른 작업으로 점검 범위를 옮기세요. 지원을 요청할 때 통계 기간, 화면 사용량, 네트워크 종류, 민감한 정보를 가린 활동 특징을 제공할 수 있습니다. 전체 인터넷 사용 기록이나 인증 정보가 포함된 설정 파일을 공개하지 마세요.

08 / CHANGE AND RECOVERY

업데이트 후 오류 및 설정 복구

‘업데이트 후 작동하지 않는다’고 할 때는 무엇을 업데이트했는지 먼저 구분해야 합니다. App Store의 앱, 시스템, 구독 내용, Config 파일 가운데 어떤 항목인지 확인하세요. 변화가 같은 날 일어났더라도 영향을 주는 단계는 서로 다릅니다. 앱 업데이트가 만료된 구독을 자동으로 복구하지 않으며 구독 업데이트가 규칙 참조까지 유효하게 유지한다는 보장도 없습니다. 마지막으로 정상적으로 사용한 시점부터 문제가 처음 발생한 시점까지 실제로 변경한 내용을 적으세요. 시점이 가깝다는 이유만으로 특정 변경을 원인으로 단정하지 마세요.

현재 상태를 보존한 뒤 최소 구성으로 테스트

계속 수정하기 전에 현재 설정의 복사본, 선택한 서버 이름, Global Routing 상태를 저장하세요. 백업 파일에는 민감한 정보가 포함될 수 있으므로 본인이 관리하는 위치에 보관해야 합니다. 백업이 있다면 어느 시점의 것인지, 무엇이 포함되어 있는지도 확인하세요. 서버 목록, 규칙 파일, 시스템 VPN 승인은 서로 다른 자료입니다. 한 항목을 백업했다고 전체 작동 상태를 복구할 수 있다고 가정하지 마세요.

앱을 재시작하고 연결을 다시 설정해 문제가 계속되는지 확인하세요. 그런 다음 유효한 서버는 그대로 두고 간단한 경로로 실제 접속을 테스트하세요. Proxy는 정상인데 기존 Config에서 실패한다면 설정 해석, 규칙 순서, 정책 그룹 참조를 집중적으로 확인합니다. 모든 경로에서 실패한다면 서버, 승인, 기본 네트워크를 점검하세요. 최소 테스트는 변수를 줄이기 위한 것이지, 모든 요구를 대신하는 설정을 장기간 새로 만들기 위한 것이 아닙니다.

변경 유형에 따라 각각 확인

구독 업데이트 후 문제가 발생했다면 업데이트된 목록에 현재 선택 항목이 남아 있는지, 기존 정책 그룹이 변경된 이름을 참조하는지 먼저 확인하세요. Config 업데이트 후 문제가 생겼다면 가져오기 안내, 활성화된 파일, 마지막 규칙을 확인하고 새 파일이 활성화되지 않은 별도 복사본으로 저장되지는 않았는지 살펴보세요. 본인이 사용하던 기존 출처의 설정이라면 이전 버전과 새 버전을 함께 보관해 비교할 수 있습니다. 손상된 내용을 통째로 덮어쓰지 않도록 설정을 한 번에 일부씩만 복원하세요.

앱이나 시스템 업데이트 후 문제가 발생했다면 시스템의 VPN 승인이 계속 정상적으로 작동하는지, 기기에서 업데이트 후 처리 작업이 진행 중인지 먼저 확인하세요. 연결 한 번 실패했다고 모든 네트워크 설정을 바로 지우지 마세요. 문제가 반복되면 재현 절차와 오류 원문을 기록하고 App Store 페이지에서 현재 앱 설명과 관련 정보를 확인하세요. 앱 구매와 업데이트는 App Store를 통해 진행합니다. 앱 출처 확인은 정품 구매 안내를 참고하세요.

한꺼번에 덮어쓰지 말고 항목별로 복구

백업을 복원하기 전에 백업에 포함된 서버 정보가 여전히 유효한지 확인하세요. 이전 설정의 구문이 올바르더라도 주소, 인증 정보, 참조 대상이 바뀌었을 수 있습니다. 먼저 필요한 서버를 복원해 테스트한 뒤 핵심 규칙을 복원하고, 마지막으로 자동 연결과 선택 기능을 복원하는 것이 좋습니다. 각 단계가 끝날 때 상태를 기록하세요. 다음 단계에서 실패하면 처음부터 모든 설정을 추측하지 않고 방금 복원한 항목으로 범위를 좁힐 수 있습니다.

필요한 정보를 저장하고 복구 방법을 이해했으며 일반적인 점검으로 해결할 수 없을 때만 재설치를 고려하세요. 재설치로 원격 서버의 작동 중단이나 만료된 링크를 복구할 수는 없습니다. 구매 항목 복원과 로컬 설정 복원은 따로 처리해야 합니다. 전자는 App Store 구매 기록과 관련되고 후자는 본인이 만든 백업에 달려 있습니다. 앱을 다시 받으면 모든 로컬 설정도 자동으로 돌아온다고 생각하지 마세요.

문제가 계속되면 최소한의 재현 정보를 정리하세요. 기기 종류, 네트워크 종류, 마지막으로 정상 작동한 상태, 발생한 변경, 간소화한 설정에서의 결과를 기록하면 됩니다. 인증 정보와 관계없는 과거 기록은 빼고 일상적인 전체 트래픽 기록을 보내지 마세요. 앱을 다시 열어 연결하기, 네트워크 전환 후 재연결하기, 대상 서비스 정상 작동, 자동 연결 조건이 의도한 대로 적용되기까지 확인해야 복구가 완료된 것입니다. 현재 세션에서 잠시 작동하는 것만으로는 충분하지 않습니다.

09 / IPAD CHECKLIST

iPad 점검 및 복구 확인

iPad의 기본 연결 과정은 iPhone과 같지만 큰 화면에서의 멀티태스킹, 다양한 Wi-Fi, 로컬 네트워크 기기, 기기 간 이전 등 사용 환경이 다를 수 있습니다. 문제가 발생해도 다른 기기에서 얻은 결론을 그대로 적용하지 마세요. 다른 기기에서 같은 구독이 작동하더라도 일부 조건이 정상일 수 있다는 뜻일 뿐, 이 iPad에서 같은 설정이 활성화되어 있다는 의미는 아닙니다. 시스템 요구 사항, 호환성, 구매 적용 여부는 App Store 페이지에 표시된 내용을 기준으로 확인하세요. 기기 외관만으로 지원 여부를 추측하지 마세요.

앱 구매와 설정 이전 구분

먼저 iPad에 올바른 Shadowrocket이 설치되어 있는지 확인하세요. 정품 여부는 개발자 Shadow Launch Technology Limited, 공식 아이콘, 앱 ID 932747118로 확인할 수 있습니다. 구체적인 경로는 iPad 구매 안내를 참고하세요. 구매 기록에서 앱을 받을 수 있다고 해서 다른 기기의 구독, 현재 선택 항목, 규칙, 자동 연결 조건이 함께 동기화되는 것은 아닙니다. 이전 후 항목별로 확인하세요. 목록이 비어 있다고 구매가 적용되지 않았다고 오해하지 마세요.

본인 백업에서 설정을 가져오는 경우 파일이 온전한지 먼저 확인하고 이 기기에서 실제로 활성화된 항목도 살펴보세요. 서버 이름이 목록에 있다고 현재 선택된 것은 아니며, Config를 가져왔다고 자동으로 활성화되는 것도 아닙니다. iPad에서 유효한 항목 선택, 수동 연결, 고정된 대상 접속을 포함한 기본 절차를 다시 완료한 뒤 규칙과 자동 연결을 복원하는 것이 좋습니다. 최초 승인은 반드시 해당 기기에서 완료해야 합니다. 다른 기기에서 이미 승인됐다고 대신할 수 없습니다.

이 기기의 네트워크 및 권한 차이 확인

일부 iPad는 Wi-Fi로만 연결되므로 셀룰러 네트워크와 비교할 수 없는 경우가 있습니다. 사용 권한이 있는 다른 네트워크에서 테스트할 수 있지만 해당 네트워크 자체가 정상인지 먼저 확인해야 합니다. 학교, 직장, 공공 Wi-Fi에 연결하는 경우 Shadowrocket 연결을 끊고 필요한 웹 인증을 완료하세요. 관리 기기에는 조직 설정이 적용될 수 있으므로 관련 구성을 직접 삭제하지 말고 관리 담당자에게 확인하세요.

웹페이지는 정상인데 로컬 네트워크 기기에 연결할 수 없다면 대상 주소가 현재 로컬 네트워크에 속하는지, 관련 앱에 필요한 로컬 네트워크 권한이 있는지 확인하세요. 프린터, 화면 미러링, 기기 검색은 일반적인 웹 요청만으로 작동하지 않을 수 있습니다. 외부 웹페이지 접속 결과만으로 대신 테스트할 수 없습니다. 해당 사설 주소에 적절한 경로를 적용하도록 규칙이 설정되어 있는지 확인하세요. 주소 규칙 하나를 추가해도 검색 방식이나 기기 자체의 권한 요건까지 모두 해결된다는 보장은 없습니다.

멀티태스킹 및 네트워크 전환 문제

화면 분할이나 앱 전환 후 문제가 발생하면 이전에 표시된 화면만 보고 판단하지 말고 Shadowrocket으로 돌아가 실제 연결 상태를 확인하세요. 페이지에 예전 내용이 남아 있거나 대상 앱이 기존 세션을 재사용할 수 있습니다. 요청을 새로 보내고 기록에 나타나는지, 어떤 정책이 적용되는지 확인하세요. 새 요청이 없다면 대상 앱이 계속 로딩 중인지 또는 일시 정지됐는지 살펴보세요. 앱에서 요청을 보내지 않은 것을 프록시가 전달하지 않은 문제로 오인하지 않도록 합니다.

잠금 해제 후, Wi-Fi 전환 후, 액세스 포인트에서 벗어난 뒤 잠시 접속이 안 된다면 네트워크가 안정될 때까지 기다린 다음 대상 연결을 다시 설정하세요. 잠금을 해제할 때마다 연결이 끊긴다면 On Demand가 활성화되어 있는지, 기존 네트워크에서 다시 인증해야 하는지, 같은 네트워크의 기본 접속은 정상인지 기록하세요. 자동 연결을 잠시 끄고 수동으로 비교한 뒤에는 원래 조건으로 복원해야 합니다. 점검을 이유로 사용 목적에 맞지 않는 상태를 계속 유지하지 마세요.

이 기기에서 전체 절차를 확인한 뒤 평소 상태로 복원

먼저 Safari에서 고정된 테스트 페이지로 기본 접속을 확인한 뒤 문제가 발생한 앱을 테스트하고, 마지막으로 로컬 네트워크나 멀티태스킹 환경을 확인하세요. 단계별로 성공 조건을 기록하세요. 특정 유형의 작업이 실패하면 앞서 확인한 기준 상태는 유지하고 해당 항목만 계속 점검하세요. 개념은 용어 안내에서 확인하고 전체 설정 절차를 다시 진행하려면 빠른 시작 가이드로 돌아가세요.

최종 확인에는 이 기기에서 앱 다시 열기, 수동 재연결, 실제 서비스 접속, 자주 사용하는 네트워크로 전환한 뒤 재접속하는 과정이 포함됩니다. 이 iPad에서만 문제가 발생한다면 기기의 승인, 네트워크, 설정, 권한 차이를 기록하세요. 본인이 사용하는 여러 기기에서 같은 서버가 동시에 실패한다면 서버나 구독 상태를 우선 확인해야 합니다. 이 순서대로 근거를 정리하면 반복해서 가져오거나 재설치하는 일을 줄이고, 이후 문의에서도 처리 가능한 문제 단계를 명확히 전달할 수 있습니다.