Shadowrocket
문제 해결 가이드

01 / VPN CONFIGURATION

스위치가 켜지지 않거나 바로 꺼질 때

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

Home의 연결 스위치가 켜진 상태를 유지하지 못한다면, 먼저 시스템에서 VPN 구성을 허용하는지 확인하세요. 처음 연결할 때 시스템에서 VPN 구성 추가를 확인하고 기기 암호나 시스템 인증으로 권한을 승인해야 할 수 있습니다. 이 절차는 앱이 네트워크 터널을 만들도록 허용할 뿐, 원격 서버 인증이 완료되었다는 뜻은 아닙니다. 확인 창을 취소했다면 앱으로 돌아가 다시 연결을 시도하고 승인을 마치세요. 서버 비밀번호를 반복해서 바꾸지는 마세요. 스위치가 확인 전에 꺼지는지, 잠시 켜졌다가 꺼지는지 먼저 기록하세요. 두 경우는 점검 방향이 다릅니다.

시스템 Settings를 열고 VPN 관련 설정에서 Shadowrocket 구성이 있는지 확인하세요. 시스템 버전에 따라 메뉴 위치가 달라질 수 있으므로 설정 검색을 이용할 수 있습니다. 다른 VPN 세션이 실행 중인지도 확인하세요. 일반적인 개인 VPN 연결은 여러 개를 동시에 유지하지 못하는 경우가 많습니다. 다른 세션을 종료한 뒤 Shadowrocket에서 다시 테스트하세요. 용도를 모르는 상태에서 모든 네트워크 구성을 삭제하지 마세요. 특히 업무용 또는 학교 기기의 관리 대상 구성은 필요한 접근 제어에 사용될 수 있습니다.

되돌릴 수 있는 순서로 남은 상태를 정리하세요

1. 현재 연결을 중지하고 시스템의 VPN 상태가 해제될 때까지 기다린 뒤 Shadowrocket을 다시 여세요.
2. 시스템 자동 연결과 수동 테스트가 번갈아 실행되지 않도록 On Demand를 잠시 끄세요.
3. 기존 서버가 선택되어 있는지 확인하고 설정을 저장한 뒤 연결 테스트를 한 번만 진행하세요.
4. 계속 바로 종료된다면 기기를 재시동한 뒤 같은 네트워크에서 다시 테스트하고 결과를 기록하세요.

시스템에 구성이 남아 있는데도 앱이 세션을 계속 만들지 못한다면, 구성 백업이 온전한지 확인한 뒤 Shadowrocket에 해당하는 VPN 구성만 삭제하고 앱에서 다시 요청할 수 있습니다. 여기서 삭제하는 것은 시스템의 네트워크 권한 기록입니다. 원격 계정을 초기화하는 방법이 아니며 서비스 만료나 설정 오류를 해결하지도 않습니다. 작업 전에 기존 구성을 다시 가져올 수 있는지 확인하세요. 앱 재설치를 첫 단계로 삼지 마세요. 로컬 서버, Config 및 진단 기록이 함께 사라질 수 있습니다.

시스템 제한과 연결 조건을 확인하세요

관리 대상 기기에서는 새 VPN 추가, 네트워크 설정 변경 또는 특정 네트워크 확장 실행이 제한될 수 있습니다. 시스템 버튼을 편집할 수 없거나 조직에서 관리한다는 안내가 표시되거나 구성이 자동으로 복구된다면 기기 관리자에게 정책을 확인하세요. 기기 암호, 스크린 타임 제한, 관리 정책은 서로 다른 수준의 문제입니다. 원격 서버 정보로 이러한 제한을 바꿀 수는 없습니다. 개인 기기라면 시스템 저장 공간이 부족한지, 다른 앱에서도 이상이 나타나는지 먼저 확인한 뒤 네트워크 확장 시작 실패 여부를 판단하세요.

On Demand는 설정한 조건에 따라 연결을 시작하므로, 껐는데 다시 자동으로 켜진다고 해서 반드시 스위치 오류인 것은 아닙니다. 먼저 On Demand를 끄고 수동 연결이 안정적으로 유지되는지 확인한 다음 트리거 조건을 하나씩 다시 설정하세요. Wi-Fi 전환, 화면 잠금 또는 특정 네트워크에서 벗어날 때만 문제가 생긴다면 구체적인 동작을 기록하세요. 단순히 ‘가끔 끊김’이라고만 적지 마세요. 조건을 고정하고 같은 설정으로 반복 테스트해야 시스템의 세션 재생성과 앱의 예기치 않은 종료를 구분할 수 있습니다.

계속 켜지지 않는다면 기기 모델, 시스템 요구 사항 확인 결과, 권한 확인 창의 내용, 관리 대상 여부, 재시동 후 재현 절차를 정리하세요. 앱 구매 및 시스템 요구 사항은 정품 확인 안내를 참고하고, 시스템 요구 사항은 App Store 페이지에 표시된 내용을 확인하세요. 최초 오류 메시지를 숨기려고 구성을 연달아 삭제하지 마세요. 처음 표시된 메시지가 마지막 시도보다 원인을 파악하는 데 더 유용한 경우가 많습니다.

02 / REQUEST PATH

연결은 되었지만 웹페이지가 열리지 않을 때

먼저 연결을 끈 상태와 비교하세요

먼저 Shadowrocket을 중지하고 현재 Wi-Fi 또는 셀룰러 네트워크에서 평소 정상적으로 열리던 페이지에 접속하세요. 연결을 끈 상태에서도 실패한다면 Wi-Fi에 웹 인증이 필요한지, 라우터가 인터넷에 연결되어 있는지, 셀룰러 데이터 사용이 허용되어 있는지, 기기의 신호가 불안정한 위치인지 등 네트워크 자체를 확인하세요. 공용 Wi-Fi 인증 페이지는 연결을 중지한 상태에서 완료해야 할 수 있습니다. 인증을 마친 뒤 다시 테스트하세요. 기본 네트워크가 작동하지 않는 상태에서 규칙을 계속 바꾸면 변수가 늘어날 뿐입니다.

연결을 끄면 정상이고 켜면 실패한다면 오류가 발생하는 범위를 확인하세요. 서로 다른 대상 두 곳을 테스트해 모든 요청이 실패하는지, 특정 앱만 실패하는지, 특정 도메인만 실패하는지 구분합니다. 같은 페이지와 같은 동작으로 비교해 한쪽은 캐시된 내용을 표시하고 다른 쪽은 새 네트워크 요청을 하는 상황을 피하세요. 브라우저에 이전 페이지가 표시된다고 연결이 정상인 것은 아닙니다. 네트워크가 필요한 콘텐츠를 새로고침하고 앱의 요청 기록에 해당 접근이 나타나는지 확인하세요.

Global Routing으로 문제 위치를 확인하세요

Global Routing은 전체 요청이 다음 처리 단계로 어떻게 전달되는지 결정합니다. Config 상태에서는 현재 규칙에 따라 매칭되고, Proxy 상태에서는 선택된 서버의 경로를 점검하며, Direct 상태에서는 프록시 정책을 거치지 않는 접근을 확인합니다. 이 세 가지 상태는 잠깐 비교할 때 사용하며, 모든 문제를 해결하는 공통 스위치가 아닙니다. 테스트가 끝나면 필요한 원래 상태로 되돌리고 현재 활성화된 Config가 의도한 파일인지 확인하세요. 설정 목록에 파일이 있는지만 확인해서는 충분하지 않습니다.

Proxy에서는 정상인데 Config에서는 실패한다면 요청이 어떤 규칙에 매칭되었는지, 마지막에 어떤 정책이 적용되었는지 확인하세요. 범위가 넓은 DOMAIN-KEYWORD, 너무 앞에 있는 REJECT, 예상과 다른 DIRECT가 요청 경로를 바꿀 수 있습니다. 규칙은 일반적으로 순서대로 판정되므로 실제로 매칭된 행을 찾은 다음 그 앞에 더 넓은 조건이 있는지 확인하세요. 요청이 앞선 규칙에 이미 매칭되었을 수 있으므로 Config 끝에 올바른 규칙을 추가하는 것만으로 해결하려 하지 마세요.

최소 규칙으로 판정 방식을 확인하고 기존 설정은 덮어쓰지 마세요

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

여기서 example.com은 문법 설명에만 사용하는 예시이며 연결 테스트 서비스가 아닙니다. DOMAIN-SUFFIX는 지정 도메인과 하위 도메인에 매칭됩니다. GEOIP는 주소의 소재지를 기준으로 판단합니다. FINAL은 그때까지 매칭되지 않은 요청에 기본 정책을 적용합니다. 시험하려면 기존 Config를 복사해 테스트 파일로 별도 저장하고 원본은 유지하세요. 이 세 줄을 모든 상황에 적용할 수 있는 완성된 설정으로 간주하지 마세요. 기존 DNS, 정책 및 기타 필수 설정까지 함께 삭제하지 마세요.

Proxy와 Config에서 모두 실패하지만 Direct에서는 정상이라면 서버 설정, 원격 서비스 상태, 프록시 경로의 DNS를 확인하세요. 특정 앱만 실패한다면 독립적인 연결 방식을 사용하는지, 이전 세션을 유지하고 있는지, 시스템에서 셀룰러 데이터 사용을 허용하는지 확인하세요. 필요하면 해당 앱을 완전히 종료한 뒤 다시 열어 새 연결로 테스트하세요. 대상 앱 재시작과 VPN 세션 재생성은 각각 따로 진행해야 어느 단계에서 결과가 달라졌는지 알 수 있습니다.

REJECT에 매칭된 항목이 있으면 먼저 해당 도메인의 용도를 확인하고 의심되는 규칙 하나만 잠시 비활성화해 다시 테스트하세요. 모든 차단 규칙을 한꺼번에 삭제하지 마세요. 한 페이지가 여러 도메인에 의존할 수 있어 요청 하나만 거부되어도 일부 화면이 비거나 로그인이 실패할 수 있습니다. 관련 내용은 REJECT 규칙 작성 안내를 참고하세요. 모든 상태에서 실패하고 기본 네트워크는 정상이라면 실패한 요청의 시간과 오류 유형을 기록하고 다음 장을 확인하세요.

03 / SERVER PARAMETERS

서버 시간 초과와 프로토콜 핸드셰이크 실패

먼저 테스트 결과를 단계별로 해석하세요

Connectivity Test 또는 서버 지연 시간 테스트는 해당 시점의 네트워크에서 특정 테스트 방식이 완료되었는지만 보여줍니다. 브라우저의 모든 요청 결과를 의미하지는 않습니다. 테스트 실패는 서버 주소 확인, 포트 연결, 프로토콜 핸드셰이크 또는 테스트 대상과 관련될 수 있습니다. 성공하더라도 원격 서버를 통해 모든 대상에 접속할 수 있다고 보장하지 않습니다. 사용한 테스트 방법을 기록한 뒤 실제로 실패한 페이지를 열어 확인하세요. 결과를 비교할 때는 같은 방법을 사용하고 서로 다른 테스트의 수치를 직접 비교하지 마세요.

서버 주소를 확인할 때 복사 과정에서 공백, 줄바꿈 또는 문장 부호가 들어갔는지 살펴보세요. 주소 필드는 기존 서비스 정보와 일치해야 하며 포트도 현재 프로토콜의 접속 지점에 맞아야 합니다. 도메인 이름이 확인된다고 포트에 연결할 수 있다는 뜻은 아니며, 포트 연결이 된다고 인증이 성공하는 것도 아닙니다. 기존 정보에 여러 포트나 전송 방식이 있다면 해당되는 항목끼리 맞춰 입력하세요. 한 접속 지점의 주소와 다른 접속 지점의 TLS 또는 전송 설정을 섞지 마세요.

프로토콜 필드 간의 조합을 확인하세요

TLS 인증서 검증에 사용하는 서버 이름과 실제 연결을 설정하는 주소는 서로 다른 역할을 할 수 있습니다. 기존 설정에서 제공한 정보를 기준으로 확인하세요. 전송 계층의 Host, 경로 및 기타 필드도 이름만 보고 추측하지 마세요. 서버 설정이 변경되었다면 기존 구독을 가져올 수는 있어도 핸드셰이크에 실패할 수 있습니다. 먼저 자신의 구독을 업데이트해 성공 여부를 확인한 뒤 업데이트 전후의 필드 차이를 비교하세요. 이름이 비슷한 항목 중 오래된 항목을 잘못 선택하지 않도록 주의하세요.

시스템 날짜, 시간 및 시간대를 확인하고 시스템 자동 설정을 우선 사용하세요. 시간이 크게 어긋나면 인증서 확인이나 시간 제한이 있는 인증에 영향을 줄 수 있습니다. 인증서 오류가 발생해도 검증을 끄는 것을 고정 해결책으로 삼지 마세요. 서버 이름, 기기 시간, 원격 인증서 상태를 확인해야 합니다. 검증을 우회하면 실제 원인을 가릴 뿐 아니라 설정을 고친 것인지 오류를 건너뛴 것인지 구분할 수 없게 됩니다. 올바른 검증을 복구한 뒤 다시 테스트해야 점검이 완료됩니다.

네트워크를 비교해 경로 문제를 확인하세요

서버와 설정은 그대로 두고 Wi-Fi와 셀룰러 네트워크에서 각각 테스트하세요. 한 네트워크에서만 실패한다면 해당 네트워크의 접근 제한, UDP 처리 차이 또는 주소 체계 차이를 확인하세요. 이 결과는 문제 범위를 네트워크 경로로 좁힐 뿐, 특정 기기 고장을 바로 의미하지는 않습니다. 같은 구독에서 사용자가 보유한 다른 서버는 정상인데 서버 하나만 실패한다면 클라이언트 설정을 전부 다시 만들기 전에 원래 서비스 제공자에게 해당 접속 지점의 상태를 문의할 수 있습니다.

WireGuard를 사용하는 경우 Peer가 통신할 수 있는지와 AllowedIPs가 터널을 통과시키려는 대상 범위를 포함하는지 모두 확인해야 합니다. 핸드셰이크와 라우팅은 별개의 문제이므로 전자가 정상이라고 후자까지 올바른 것은 아닙니다. 개인 키와 원격 공개 키는 서로 바꿔 쓸 수 없으며 진단 정보를 공유할 때 개인 키를 노출해서도 안 됩니다. 필드의 의미는 WireGuard 설정 설명에서 확인하세요. 경로 문제를 해결하려고 키를 무작위로 바꾸지 마세요.

점검이 끝나면 ‘특정 네트워크에서 특정 프로토콜의 핸드셰이크가 시간 초과되고 다른 네트워크에서는 어떤 결과가 나오는지’처럼 문제를 설명하고, 확인한 필드의 종류를 덧붙이세요. 전체 인증 정보는 보내지 마세요. 정해진 순서대로 더 자세히 점검하려면 서버 시간 초과 점검 목록을 참고하세요. 짧은 간격으로 계속 재시도해도 원격 상태가 해결되는 것은 아니며, 서로 다른 시점의 결과만 혼란스러워질 수 있습니다. 반복 가능한 결과를 확보한 뒤 다음 조치를 정하세요.

04 / SUBSCRIPTION UPDATE

Subscribe 가져오기 실패 또는 업데이트 오류

가져오기 실패와 콘텐츠 해석 실패를 구분하세요

구독 업데이트는 주소 가져오기, 서버 요청, 응답 수신, 콘텐츠 해석 등 여러 단계를 거칩니다. ‘업데이트 실패’는 결과일 뿐이므로 먼저 어느 단계에서 멈췄는지 확인해야 합니다. 응답을 받지 못한 경우와 콘텐츠를 받았지만 인식하지 못하는 경우는 해결 방법이 다릅니다. 전자는 네트워크, 주소, 인증을 확인하고 후자는 응답이 Shadowrocket에서 인식할 수 있는 구독 콘텐츠인지 확인합니다. 비교에 사용할 기존 항목을 보존하세요. 업데이트가 실패할 때마다 구독 그룹 전체를 삭제하면 이전 설정과 비교할 수 없게 됩니다.

자신의 서비스 정보에서 전체 구독 주소를 다시 복사하고 앞뒤 공백, 줄바꿈, 누락된 쿼리 부분, 잘못 들어간 문장 부호가 있는지 확인하세요. 구독 주소에는 접근 자격 증명이 포함되는 경우가 많으므로 공개 스크린샷, 대화 기록 또는 진단 첨부 파일에 넣지 마세요. 요청 구조를 보여줘야 한다면 도메인과 필드 이름만 남기고 필드 값은 삭제하세요. 테스트를 위해 전체 주소를 여러 웹페이지에 반복해서 붙여 넣지 마세요. 다른 사람이 주소를 알게 되면 계정이나 서비스 사용에 위험이 생길 수 있습니다.

응답에 따라 점검 경로를 선택하세요

인증 실패, 권한 부족 또는 접근 거부가 표시되면 원래 서비스 제공자가 운영하는 계정 페이지에서 구독 상태, 주소 재설정 여부, 접근 제한을 먼저 확인하세요. 클라이언트를 다시 구매해도 원격 인증이 복구되지는 않습니다. 클라이언트의 일회성 구매와 서비스 회선 구독은 별개입니다. 앱 구매 기록과 사용자가 보유한 서비스의 인증 정보도 서로 다른 정보입니다. 구매 관련 내용은 가격 및 일회성 구매 안내를 참고하세요. App Store에서 구매한 상태라고 구독이 여전히 유효한 것은 아닙니다.

응답이 로그인 페이지, 점검 안내 또는 다른 웹페이지라면 요청 자체가 완료되었더라도 구독 업데이트가 성공한 것은 아닙니다. 클라이언트에 필요한 것은 브라우저에 표시할 수 있는 임의의 콘텐츠가 아니라 인식 가능한 구독 데이터입니다. 리디렉션이 발생한다면 최종 응답이 예상한 서비스 절차 안에 있는지도 확인하세요. 해석 오류를 해결하려고 주소에서 인증 부분을 직접 삭제하지 마세요. 대개 요청이 로그아웃 상태로 바뀌어 원래 문제에서 더 멀어집니다.

현재 연결을 사용할 수 없다면 구독 요청도 실패하는 프록시 경로로 전달될 수 있습니다. 기존 항목을 보존한 채 연결을 중지했을 때와 사용 가능한 기존 연결을 이용했을 때의 업데이트 결과를 비교하고, 현재 Config에서 구독 도메인이 어떻게 처리되는지도 확인하세요. 모든 업데이트 요청이 같은 경로를 사용한다고 가정하지 마세요. 브라우저에서 서비스 페이지가 열린다고 앱의 구독 요청도 반드시 성공하는 것은 아닙니다. 두 요청은 세션, 인증, 응답 내용이 서로 다를 수 있습니다.

업데이트 성공 후에도 실제 변경 사항을 확인하세요

1. 작업이 성공했다는 응답이 돌아왔는지 확인하고, 안내 문구만 보지 말고 구독 그룹에 서버가 실제로 추가되었는지 살펴보세요.
2. 현재 선택된 항목이 이전 접속 지점을 가리키고 있는지 확인하고 필요하면 새 항목을 선택하세요.
3. 이름이 비슷한 서버가 어느 구독 그룹에 속하는지 확인해 남아 있는 다른 설정을 테스트하지 않도록 하세요.
4. 연결 테스트가 통과한 뒤 이전 항목을 정리하고, 나중에 확인할 수 있도록 설정 사본을 보관하세요.

업데이트 후 항목 수가 줄었다고 해서 가져오기에 실패한 것은 아닙니다. 원래 서비스에서 항목, 계정 권한 또는 구독 콘텐츠를 변경했거나 필터 조건 때문에 일부 항목이 표시되지 않을 수 있습니다. 실제 응답과 그룹에 표시된 결과를 비교해 원본 콘텐츠에 예상 항목이 있는지 먼저 확인하세요. 이름이 바뀌었다고 서버 설정 전체가 달라진 것은 아니며, 이름이 같다고 주소, 포트, 인증 정보까지 그대로라는 뜻도 아닙니다. 목록의 모양만 비교하지 말고 필드를 확인하세요.

직접 추가한 서버와 구독으로 관리하는 서버는 구분해야 합니다. 구독 항목을 직접 수정하면 다음 업데이트 때 원격 콘텐츠로 덮어써질 수 있습니다. 설정을 임시로 검증하려면 원래 값을 먼저 보관하고 수정 이유를 기록하세요. 매번 업데이트 후 필드를 다시 고치는 방식으로 장기 관리하지 마세요. 원격에서 계속 잘못된 설정을 제공한다면 원래 서비스 제공자에게 확인하세요. 클라이언트의 임시 변경은 확인을 위한 근거일 뿐 구독 원본을 고치지는 못합니다.

가져오기 절차 자체가 명확하지 않다면 시작 가이드에서 기존 구독 추가 방법을 확인하세요. 계정과 구매 개념이 혼동된 경우에는 자주 묻는 질문을 참고할 수 있습니다. 먼저 오류가 발생한 단계를 파악한 다음 설정을 조정하세요. 주소, 규칙, 서버를 한꺼번에 바꾸는 것보다 정확한 결론을 얻기 쉽습니다.

05 / PERFORMANCE BASELINE

속도 저하, 로딩 지연 및 네트워크 전환

속도 문제를 증상별로 나누세요

‘느리다’는 첫 페이지를 여는 데 오래 걸림, 다운로드 속도가 낮음, 동영상이 간헐적으로 멈춤, 네트워크 전환 후 복구가 늦음 등 여러 증상을 가리킬 수 있습니다. 각각 DNS, 연결 설정, 지속 전송량, 세션 재생성과 관련될 수 있으므로 지연 시간 숫자 하나로 설명할 수 없습니다. 먼저 어느 단계에서 느려지는지 적고 해당 상황에 맞는 테스트를 선택하세요. 페이지 전송이 시작된 뒤의 속도와 요청을 보내기 전 대기 시간은 따로 확인해야 합니다. 그렇지 않으면 DNS 문제를 대역폭 부족으로 오인할 수 있습니다.

비교할 때는 기기 위치, 대상 콘텐츠, 네트워크, 테스트 시간대를 가능한 한 동일하게 유지하세요. 먼저 연결을 중지해 기본 네트워크를 확인한 뒤 같은 기존 서버로 테스트합니다. 그다음 사용자가 보유한 다른 접속 지점 하나만 바꿔 비교하세요. 네트워크를 바꾸면서 프로토콜까지 수정하면 어떤 변수가 결과에 영향을 주었는지 알 수 없습니다. 실제 문제와 비슷한 콘텐츠를 사용하세요. 짧은 요청 한 번이 정상이라고 긴 연결이나 대용량 전송도 정상이라는 뜻은 아닙니다.

지연 시간, 패킷 손실, 전송량을 각각 확인하세요

연결이 빠르게 설정되었다는 것은 현재 테스트의 왕복 통신과 핸드셰이크가 원활했다는 뜻일 뿐 지속 전송 성능을 보장하지는 않습니다. 원격 서버 부하, 회선 혼잡, 대상 서비스 제한, Wi-Fi 간섭이 전송량에 영향을 줄 수 있습니다. 여러 번 테스트할 때 대기 시간이 크게 달라진다면 기기가 이동 중인지, 신호가 변하는지, 다른 액세스 포인트로 자동 전환되는지 확인하세요. 라우터에서 멀리 떨어져 있다면 클라이언트 규칙보다 무선 재전송 증가를 먼저 살펴볼 수 있습니다.

같은 경로를 사용하는 다른 대상은 정상인데 특정 대상만 느리다면 해당 대상의 접근 경로, 콘텐츠 캐시, 서비스 상태를 확인하세요. 페이지에 본문이 먼저 표시된 뒤 추가 도메인의 리소스를 기다리는 경우도 있습니다. 부가 요청이 잘못된 정책을 적용받거나 REJECT에 차단되면 계속 로딩되는 것처럼 보일 수 있습니다. 이때는 연결 전체의 속도가 느리다고 단정하지 말고 요청 기록에서 마지막으로 대기하거나 실패한 도메인을 확인하세요. 해당 규칙을 비교한 뒤 같은 페이지를 다시 테스트하세요.

설정에 따라 요청마다 다른 정책을 사용할 수 있으므로 같은 기기에서도 앱별 사용 경험이 다를 수 있습니다. Proxy와 Config를 잠시 비교해 규칙 경로 차이인지 확인할 수 있지만 테스트 후에는 필요한 Config 상태로 되돌려야 합니다. Proxy에서 나아졌다면 구체적으로 어떤 규칙이 매칭되었는지 더 확인하세요. 프록시 상태를 모든 상황에 적용할 고정 답으로 삼지 마세요. 두 상태 모두 느리다면 규칙을 계속 추가하지 말고 서버와 네트워크를 비교하세요.

근거가 있을 때만 MTU와 장시간 연결을 조정하세요

작은 요청은 정상인데 큰 전송이 멈추거나 특정 네트워크에서 특정 프로토콜이 계속 끊길 때 MTU 및 경로 문제를 확인할 수 있습니다. MTU는 전송 가능한 패킷 크기에 영향을 줍니다. 값이 클수록 빠른 것도, 작을수록 안정적인 것도 아닙니다. 기존 설정에 지정된 값이나 앱의 기본 동작을 우선 사용하세요. 테스트가 필요하면 한 번에 하나의 값만 바꾸고 전후 결과를 기록하세요. 프로토콜과 네트워크마다 적합한 설정이 다르므로 모든 항목에 같은 값을 복사하지 마세요.

Wi-Fi에서 셀룰러로 전환하면 기존 연결이 끊겨 세션을 다시 만들어야 할 수 있습니다. 전환 후 기존 페이지에서만 멈추고 새 요청은 정상이라면 대상 앱의 연결을 먼저 새로고침하세요. 새 요청도 모두 실패한다면 Shadowrocket 세션을 다시 만드세요. On Demand는 자동 복구 시점에 영향을 줄 수 있으므로 먼저 수동 연결을 확인한 뒤 자동 연결 조건을 점검하세요. 전환 전후에 어떤 네트워크를 사용했는지 기록하고 짧은 간격으로 반복 전환하지 마세요.

테스트 중에는 다른 대용량 전송, 시스템 백업, 앱 업데이트를 줄여 결과를 비교하기 쉽게 하세요. 저데이터 모드, 대상 앱의 데이터 설정, 기기 온도도 확인합니다. 기기가 많이 뜨거우면 정상 작동 온도로 돌아올 때까지 기다린 뒤 지속 전송을 테스트하세요. 속도를 확인하려고 진단 기능이나 자동 테스트를 더 많이 켜지 마세요. 추가 활동 자체가 네트워크와 배터리 사용량에 영향을 주어 원래 증상을 더 복잡하게 만들 수 있습니다.

새 도메인에 처음 접속할 때 주로 느리다면 DNS 장을 확인하세요. 연결이 자주 다시 설정된다면 서버 시간 초과 장으로 돌아가세요. 여러 차례 같은 조건으로 비교한 뒤에도 특정 접속 지점에서만 문제가 발생한다면 민감한 정보를 삭제한 시간, 대상 유형, 재현 조건을 원래 서비스 제공자에게 문의할 수 있습니다. 클라이언트 설정을 무작위로 계속 바꾸지 마세요.

06 / NAME RESOLUTION

DNS 조회 실패 및 도메인 접속 문제

이름 확인, 연결 설정, 암호화 검증은 서로 다른 단계입니다

도메인에 접속하려면 일반적으로 대상 주소를 확인한 뒤 연결을 설정하고 상위 프로토콜 통신을 완료해야 합니다. 페이지가 열리지 않는 문제는 어느 단계에서나 발생할 수 있으며 DNS만 원인인 것은 아닙니다. 기록에 DNS 시간 초과, 사용 가능한 주소 없음 또는 비정상적인 조회 결과가 명확히 나타날 때 이 장을 확인하세요. 웹페이지의 도메인을 IP 주소로 바꾸는 방법은 일반적인 테스트로 적합하지 않습니다. HTTPS는 인증서 이름과 도메인에 따라 콘텐츠를 선택하는 서버 동작도 관련되므로, 주소를 바꾼 뒤 나타난 오류가 원래 문제와 무관할 수 있습니다.

먼저 모든 새 도메인에서 실패하는지, 특정 도메인에서만 실패하는지, Config 상태에서만 실패하는지 확인하세요. 이미 접속한 적이 있는 대상은 캐시를 사용할 수 있으므로 짧은 시간 안에 다시 열어보는 것만으로 조회가 계속 정상이라고 판단할 수 없습니다. 같은 도메인을 반복 테스트할 때 앱과 시스템이 각각 캐시를 보관할 수 있다는 점을 고려하세요. 세션을 다시 만들어도 모든 계층의 캐시가 지워지는 것은 아닙니다. 페이지 새로고침 속도만 보지 말고 실제 요청 기록도 확인하세요.

현재 경로에서 DNS 리졸버에 접근할 수 있는지 확인하세요

현재 Config에서 DNS 관련 설정을 확인하고 어떤 구성 파일에서 가져온 것인지 살펴보세요. 구독의 서버 항목과 Config의 조회 설정이 반드시 함께 업데이트되는 것은 아니므로 구독만 업데이트해도 DNS 설정이 바뀐다고 볼 수 없습니다. 사용자 지정 리졸버를 사용한다면 현재 네트워크와 정책에서 해당 리졸버에 접근할 수 있는지 확인하세요. 암호화 DNS는 리졸버 도메인의 최초 조회, TLS 검증, 요청 경로와도 관련될 수 있습니다. 주소가 온전해 보인다는 이유만으로 작동한다고 단정하지 마세요.

사용자 지정 DNS를 끈 뒤 정상으로 돌아왔다면 사용자 지정 조회 경로가 문제일 수 있지만, 리졸버 서비스 자체의 오류라고 단정할 수는 없습니다. 서로 다른 네트워크에서 리졸버에 접근할 수 있는지, 요청에 잘못된 정책이 적용되었는지, 관련 설정이 현재 Config의 다른 부분과 맞는지 계속 확인하세요. 먼저 이미 검증한 설정으로 되돌린 뒤 사용자 지정 항목을 하나씩 추가하세요. 출처를 모르는 주소를 여러 개 한꺼번에 입력하면 요청이 실패한 순서와 실제로 사용된 대상을 추적하기 어렵습니다.

도메인 규칙과 주소 규칙의 차이를 확인하세요

도메인 규칙과 주소 규칙은 서로 다른 정보를 사용하며, 주소 규칙의 동작은 조회가 발생했는지와 관련 옵션에 따라서도 달라질 수 있습니다. 모든 요청이 같은 방식으로 매칭된다고 가정하지 말고 요청에 실제로 포함된 도메인과 주소, 매칭된 규칙 행을 확인하세요. 한 도메인에서 여러 주소가 반환되고 그중 일부 경로에 연결할 수 없다면 간헐적으로 성공할 수 있습니다. 이때는 조회 결과와 연결 실패를 함께 확인하고 성공 사례 하나만 기록하지 마세요.

IPv4와 IPv6의 연결 가능성은 다를 수 있습니다. 네트워크에서 IPv6를 지원한다고 안내하더라도 현재 서버, 대상 또는 중간 경로 전체에서 해당 연결을 원활히 처리한다는 뜻은 아닙니다. 주소 체계와 관련된 문제라면 다른 조건은 그대로 두고 조회 결과와 실제 연결 동작을 비교하세요. 근거 없이 특정 주소 체계를 끄고 장기 해결책으로 삼지 마세요. 변경 후 정상으로 돌아왔다면 어떤 경로가 해결되었는지, 원래 가능했던 다른 접속에 영향이 있는지도 기록해야 합니다.

로컬 네트워크 이름과 트래픽 분기 범위

가정이나 업무 네트워크의 로컬 기기 이름은 로컬 조회 또는 기기 검색 방식에 의존할 수 있습니다. 모든 DNS 요청을 원격 리졸버로 보내면 원격 측에서는 로컬 네트워크 안에서만 존재하는 이름을 확인하지 못할 수 있습니다. 외부 웹페이지는 정상인데 로컬 기기에 접속할 수 없다면 로컬 네트워크 권한, 내부 경로, 관련 도메인의 처리 방식을 확인하세요. 외부 리졸버를 계속 바꾸지는 마세요. 로컬 이름 조회와 기기 주소에 대한 접근 허용 여부도 각각 확인해야 합니다.

문제를 해결한 뒤 처음 실패했던 도메인, 새 연결, 대상 앱에서 각각 확인하고 임시로 끈 진단 설정은 되돌리세요. 브라우저만 정상이고 다른 앱은 계속 실패한다면 해당 앱이 이전 세션을 유지하는지, 자체 조회 방식을 사용하는지 확인하세요. DNS 조정은 모든 연결 오류에 적용되는 공통 해결책이 아닙니다. 도메인 조회가 성공한 것을 확인했다면 포트, TLS, 정책을 점검하고 캐시를 반복해서 지우지 마세요.

07 / ENERGY AND LIFECYCLE

배터리 소모, 발열 및 반복 연결

같은 사용 조건에서 달라진 점을 먼저 확인하세요

배터리 소모 이상은 실제 사용 환경과 함께 판단해야 합니다. 지속적인 데이터 전송, 약한 셀룰러 신호, 잦은 네트워크 전환, 동영상 재생, 화면 켜짐 상태가 모두 에너지 사용을 늘릴 수 있습니다. 시스템 배터리 화면은 특정 통계 기간의 사용량을 보여줍니다. 특정 앱의 비중이 높다고 해서 그 앱만 추가 소모를 일으켰다고 바로 판단할 수는 없습니다. 비슷한 시간, 같은 네트워크, 비슷한 동작을 기준으로 비교한 뒤 Shadowrocket 연결이나 설정 변경과 관련이 있는지 확인하세요.

문제가 시작되기 전에 변경한 설정을 기록하세요. 예를 들어 On Demand 조건 추가, 상세 진단 활성화, 다른 기존 서버로 변경, 새 Config 가져오기 등이 있습니다. 한 번에 한 항목만 이전 상태로 되돌리고 충분히 관찰하세요. 몇 분 동안 잠시 사용하지 않은 결과로 하루 전체의 배터리 성능을 판단하지 마세요. 충전하면서 대용량 전송을 하는 상황을 충전하지 않고 가볍게 사용하는 상황과 비교하지도 마세요. 테스트 조건이 크게 다르면 수치 변화를 설명하기 어렵습니다.

반복 연결과 계속 실패하는 요청을 확인하세요

연결이 계속 만들어졌다 끊기면 네트워크 활동이 늘어날 수 있습니다. VPN 세션이 안정적인지, 화면 잠금 후나 Wi-Fi에서 벗어난 뒤 또는 신호가 약해진 뒤에 문제가 집중되는지 확인하세요. 서버 설정 오류로 실패가 이어진다면 먼저 연결 문제를 해결하세요. 진단 표시를 줄이는 것만으로 겉으로 드러난 현상을 처리하지 마세요. 같은 앱이 실패한 요청을 계속 재시도할 수도 있으므로 요청을 시작한 앱과 실패 원인도 함께 확인해야 합니다.

On Demand는 연결을 시작하는 조건이며 연결 후 요청에 적용되는 규칙 매칭과는 다른 단계입니다. 트리거 조건이 실제 사용 상황과 맞지 않으면 필요하지 않을 때 세션이 자주 만들어지거나 네트워크 변경 후 반복 복구될 수 있습니다. 먼저 On Demand를 끄고 수동으로 켰을 때 안정적인지 확인한 다음 조건을 하나씩 복원하세요. 항목을 추가할 때마다 화면 잠금과 네트워크 전환을 포함한 일반적인 사용 상황에서 테스트하세요. 모든 조건을 한꺼번에 복원한 뒤 원인을 추측하지 마세요.

문제 해결에 필요한 시간에만 진단 기능을 사용하세요

상세 로그, 잦은 Connectivity Test, 지속적인 요청 기록 확인은 짧은 시간 동안 원인을 찾는 데 적합합니다. 오류가 걱정된다는 이유로 계속 실행하지 마세요. 문제를 재현할 수 있는 기록을 확보한 뒤 일상적인 사용에 필요한 진단 수준으로 되돌리세요. 로그에는 대상 도메인, 주소, 사용 시간이 포함될 수 있으므로 저장하거나 공유할 때도 최소한의 범위만 유지하세요. 추가 진단을 끈 뒤에도 같은 상황에서 다시 테스트해 실제 사용량을 줄인 효과와 구분하세요.

Config에 자주 실행되는 자동 작업이나 외부 리소스에 의존하는 처리가 있다면 계속 실패하는지, 실제로 필요한지 확인하세요. 설정을 복사해 비교한 다음 새로 추가한 부분만 잠시 끄고 핵심 연결과 규칙은 유지하세요. Config 전체를 비운 뒤 배터리 소모가 줄었다고 특정 규칙의 문제라고 단정하지 마세요. 데이터 경로와 사용 방식도 함께 달라질 수 있습니다. 하나의 구성 요소까지 범위를 좁히고 해당 요소를 복원했을 때 같은 현상이 반복되는지 확인해야 합니다.

유휴 연결과 실제 전송을 구분하세요

VPN 표시가 계속 나타난다고 기기가 항상 같은 수준으로 작동하는 것은 아닙니다. 유휴 연결과 대량 데이터 처리의 에너지 사용량은 다르며 백그라운드 앱 동기화로 기기가 가만히 있는 것처럼 보여도 데이터가 전송될 수 있습니다. 화면을 잠근 뒤에도 계속 발열한다면 시스템 배터리와 네트워크 활동을 확인하고 불필요한 백그라운드 작업을 하나씩 중지해 보세요. 확인하려고 계속 화면을 켜고 테스트 페이지를 새로고침하지 마세요. 이러한 동작 자체가 일상적인 유휴 상태에 들어가는 것을 방해할 수 있습니다.

프로토콜, 네트워크, 서버 경로의 조합이 배터리 소모에 영향을 줄 수 있지만 프로토콜 이름만으로 일괄 판단할 수는 없습니다. 서비스 접속 지점과 다른 설정을 가능한 한 동일하게 유지한 비교만 의미가 있습니다. 사용자가 보유한 서로 다른 접속 지점에는 원격 위치, 부하, 전송 설정 차이도 있을 수 있습니다. 확인할 수 있는 반복 연결, 실패 요청, 약한 신호부터 해결한 뒤 세부 설정을 조정하세요. 원인을 파악하기 전에 모든 백그라운드 연결을 끄면 정상적인 알림이나 동기화에 영향을 줄 수 있습니다.

효과적인 배터리 문제 기록에는 관찰 시간, 화면 사용 여부, 네트워크 유형, 충전 여부, On Demand 상태, 연결 재생성 여부가 포함되어야 합니다. 업데이트나 기기 변경 후 문제가 시작되었다면 이 조건을 보존하고 다음 장을 확인하세요. 시스템의 에너지 사용량 분석에는 통계상 한계가 있습니다. 배터리 화면 캡처 한 장만으로는 반복 가능한 비교를 대신할 수 없으며, 일정한 배터리 소모를 보장한다고 결론 내릴 수도 없습니다.

08 / RECOVERY AND IPAD

업데이트 후 문제와 iPad 점검

업데이트 후에는 설정을 보존하고 세션을 다시 만드세요

시스템 또는 앱 업데이트 후 문제가 생겼다면 업데이트 이후 처음 관찰한 조건을 기록하세요. 업데이트가 모든 설정을 바꿨다고 바로 단정하지 마세요. 원격 서비스, 현재 네트워크, 구독 콘텐츠도 같은 시기에 변경되었을 수 있습니다. 먼저 기존 세션을 종료하고 앱을 다시 연 뒤 연결을 설정하세요. 문제가 계속되면 선택된 서버, Global Routing, 현재 Config를 확인하세요. 업데이트 전에 정상 작동했던 설정 사본을 보관하면 선택 상태와 설정 내용 중 무엇이 달라졌는지 판단하는 데 도움이 됩니다.

복구를 위한 전체 순서는 기본 네트워크 확인, 현재 선택 항목 확인, On Demand 일시 중지, 수동 재연결, 이 페이지의 해당 장에 따른 오류 점검으로 진행할 수 있습니다. 기기를 재시동하면 일시적인 상태를 정리하는 데 도움이 되지만 설정 검증을 대신하지는 않습니다. 재시동 후 잠시만 정상이라면 다시 실패하기 전에 발생한 화면 잠금, 네트워크 전환, 구독 업데이트 등을 기록하세요. 단순히 ‘재시동해도 안 됨’이라고 적는 것보다 정상 상태가 얼마나 지속되었는지와 어떤 동작이 원인이 되었는지가 범위를 좁히는 데 더 유용합니다.

앱 업데이트와 재다운로드는 App Store를 통해 진행하며, 시스템 요구 사항은 App Store 페이지에 표시된 내용을 확인하세요. 구매 및 복원 방법은 구매 항목 복원 안내를 참고하세요. 재설치 전에 로컬 서버, Config, 필요한 기록을 안전하게 보관했는지, 기존 서비스 정보를 다시 확인할 수 있는지 확인하세요. 앱 구매 기록은 로컬 설정 백업과 다릅니다. 구매한 앱을 복원해도 모든 사용자 지정 설정이 자동으로 원래 상태로 돌아오지는 않습니다.

iPad에서는 선택 상태와 네트워크 권한을 먼저 확인하세요

iPad에서 같은 기존 구독을 사용하더라도 현재 선택된 서버와 Config를 각각 확인하세요. iPhone에서 정상이라고 두 기기의 상태가 같다고 가정하지 마세요. 화면이 넓으면 목록과 상세 정보가 동시에 표시될 수 있지만 항목 상세 화면을 보고 있다고 해서 해당 항목이 현재 연결에 사용되고 있다는 뜻은 아닙니다. Home으로 돌아가 실제 선택 항목을 확인한 다음 새 세션을 설정하세요. 목록의 위치나 마지막으로 열어 본 상세 화면으로 연결 대상을 추측하지 말고 현재 화면의 표시를 기준으로 확인하세요.

iPad가 Wi-Fi와 셀룰러 중 어떤 네트워크를 사용 중인지 확인하세요. 기기마다 네트워크 경로가 다를 수 있습니다. 셀룰러 기능이 있는 모델은 앱의 데이터 사용이 시스템에서 허용되어 있는지도 확인해야 합니다. 로컬 네트워크 기기에 접속할 때만 실패한다면 로컬 네트워크 권한과 관련 규칙을 살펴보세요. iPhone과 iPad를 비교할 때는 같은 네트워크에 연결하고 같은 설정과 대상을 사용하세요. 조건이 다르면 기기 차이와 네트워크 차이가 섞여 앱 문제의 원인을 찾기 어렵습니다.

화면 잠금, 멀티태스킹 및 설정 이전

멀티태스킹이나 분할 화면에서 앱이 전면에 표시되는지와 시스템 VPN 세션이 계속 실행되는지는 서로 다른 문제입니다. 창이 새로고침되는지만 보지 말고 시스템 상태와 새 요청 결과를 확인하세요. 화면을 잠근 뒤 복구에 문제가 생긴다면 기존 앱 연결과 새로 시작한 요청을 각각 테스트하세요. 기존 연결만 실패하면 먼저 대상 앱을 새로고침하고 모든 요청이 실패하면 VPN을 다시 설정하세요. 이렇게 하면 앱 세션 문제를 기기 연결 전체가 중단된 것으로 오인하지 않을 수 있습니다.

설정을 이전할 때 서버 정보, Config, 시스템 VPN 권한을 각각 구분해 처리하세요. 서버 정보와 Config는 가져온 내용과 선택 상태를 확인해야 하고, 시스템 VPN 권한은 보통 새 기기에서 다시 승인해야 합니다. 인증 정보가 포함된 설정은 직접 관리하는 안전한 방식으로 보관하고 일반 예시처럼 공개하지 마세요. 이전을 마친 뒤 기존 서버 하나를 먼저 검증하고 규칙과 자동 연결을 확인한 다음 나머지 사용자 지정 설정을 복원하세요. 모든 항목을 한 번에 가져오면 문제의 원인을 찾기 어렵습니다.

다른 사람에게 전달할 수 있는 문제 기록을 작성하세요

같은 설정이 한 기기에서는 정상이고 다른 기기에서는 문제가 생긴다면 시스템 권한, 네트워크, 시간, 앱 설정, 실제 요청 기록을 항목별로 비교하세요. 시스템 네트워크 설정 전체를 그대로 복사하거나 문제와 관련 없는 기기 관리 구성을 삭제하지 마세요. iPad에서 앱을 가져오고 처음 여는 방법은 iPad 안내를 참고하세요. 새 기기로 바꾼 뒤 구매 항목을 복원하는 방법은 기기 변경 후 앱 복원 안내에서도 확인할 수 있습니다.

마지막으로 문제를 재현하는 가장 짧은 절차를 정리하세요. 어떤 네트워크에서 어떤 상태로 어떤 동작을 했을 때 어떤 오류가 발생하는지, 어떤 비교 테스트는 정상인지, 최근에 바꾼 항목은 무엇인지 기록합니다. 민감한 정보를 제거한 오류 유형과 시간만 첨부하고 모든 과거 기록을 보낼 필요는 없습니다. 복구 후 같은 증상이 다시 나타나면 이전에 확인한 순서대로 점검하세요. 증상이 달라졌다면 해당 장에서 기준을 다시 세우고, 한 번 효과가 있었던 복구 방법을 항상 적용되는 해결책으로 간주하지 마세요.