Shadowrocket 문제 해결 가이드

01 / 시스템 연결 단계

연결 스위치가 켜지지 않을 때: VPN 구성과 시스템 제한 확인

스위치를 켜자마자 꺼짐, 연결 중 상태가 계속됨, 시스템에서 예상한 권한 요청이 표시되지 않음은 서로 다른 증상입니다. 바로 꺼진다면 시스템이 VPN 구성을 허용하는지 먼저 확인하세요. 연결 중이라면 오류 기록을 살펴 서버 연결이 시작됐는지 판단해야 합니다. 권한 요청이 나타나지 않는 경우에는 이미 허용했거나 기기 관리 정책의 제한을 받고 있을 수 있습니다. 스위치를 조작한 뒤 나타난 상태를 먼저 기록하고 빠르게 반복해서 켜고 끄지 마세요. 이전 실패와 재연결 기록이 뒤섞일 수 있으며, 반복 조작은 권한 확인을 대신할 수 없습니다.

최초 권한 요청과 기존 구성 구분

처음 Home에서 연결을 켜면 시스템에서 VPN 구성을 추가하도록 요청할 수 있습니다. 방금 실행한 Shadowrocket의 요청인지 확인한 뒤 시스템 안내에 따라 허용하고, 기기에서 요구하는 본인 인증을 완료하세요. 이 권한은 앱이 시스템 네트워크 터널을 만들도록 허용하는 것이며, 서버 정보가 유효하다거나 앱 구매에 연결 서비스가 포함된다는 뜻은 아닙니다. 권한 요청을 취소했다면 앱으로 돌아가 연결을 다시 시작하세요. 요청을 다시 표시하려고 다른 네트워크 설정부터 삭제하지 마세요. 권한에 문제가 없는데도 연결되지 않으면 이 장의 뒷부분에서 구성과 네트워크 상태를 점검하세요.

이미 사용한 기기라면 시스템 설정에서 VPN을 검색해 관련 구성이 있는지, 현재 어떤 구성이 연결을 설정하는지 확인하세요. 시스템 설정의 메뉴 위치는 버전에 따라 달라질 수 있으므로 고정된 경로를 따르기보다 검색을 이용하는 편이 좋습니다. 다른 VPN이 작동 중이라면 먼저 중지한 다음 Shadowrocket만 따로 테스트하세요. 업무나 학교에서 관리하는 구성은 임의로 제거하지 마세요. 기기 관리, 콘텐츠 필터, 네트워크 확장이 함께 연결에 영향을 줄 수 있습니다. 관리 정책에 따른 제한은 기기 관리자에게 확인해야 합니다.

순서대로 연결 충돌 확인

먼저 Shadowrocket 연결을 끄고 On Demand를 일시 중지한 다음, 시스템에서 다른 VPN이 자동으로 켜지지 않는지 확인하세요. 현재 설정 화면을 닫고 Home으로 돌아가 실제 선택된 SERVER가 예상한 항목인지 확인한 뒤 다시 연결합니다. 스위치는 유지되지만 웹페이지가 열리지 않는다면 문제는 접속 단계에 있으므로 다음 장을 확인하세요. 스위치가 바로 꺼진다면 발생 시각에 해당하는 오류 메시지를 살펴 권한 거부, 구성 생성 실패, 서버 핸드셰이크 실패를 구분하세요. 스위치 색상만으로 원인을 판단해서는 안 됩니다.

시스템 구성이 비정상적으로 남아 있는 것으로 보인다면 먼저 앱 내 서버와 설정 파일을 저장한 뒤 연결과 자동 실행 조건을 끄세요. Shadowrocket에 속한다고 확인할 수 있는 VPN 구성만 제거한 다음 앱에서 시스템 권한 요청을 다시 시작합니다. 시스템 VPN 구성을 제거하는 것과 앱 내 설정을 삭제하는 것은 다른 작업입니다. 전자는 시스템 연결 항목을 다시 만드는 것이고, 후자는 규칙과 설정값을 잃을 수 있습니다. 관리되는 기기에서 구성을 삭제하거나 추가할 수 없다는 메시지가 표시되면 반복 조작을 멈추고 관리 요구 사항부터 확인하세요.

네트워크가 준비되지 않았다면 앱을 재설치하지 마세요

웹 로그인 절차가 필요한 Wi-Fi에서는 먼저 VPN 연결을 끄고 네트워크에 로그인한 뒤 일반 웹페이지가 열리는지 확인하세요. 네트워크에 연결된 것으로 표시된다고 실제 인터넷 접속이 가능한 것은 아닙니다. 라우터가 주소를 할당하지 못했거나 로그인 상태가 만료됐거나 현재 네트워크에서 접속을 제한하면 연결이 멈출 수 있습니다. 사용할 수 있는 다른 네트워크에서도 테스트하세요. 원래 네트워크에서만 실패한다면 앱 설정은 유지하고 해당 네트워크를 점검하세요. 모든 네트워크에서 실패한다면 시스템 권한, 서버 설정, 기기 날짜와 시간을 확인하세요.

이 장의 점검을 마치려면 시스템이 VPN 구성을 허용하고, 연결을 시도했을 때 확인 가능한 결과가 나타나며, 터널이 설정되지 않은 경우와 터널 설정 후 접속에 실패한 경우를 구분할 수 있어야 합니다. 앱의 출처, 시스템 요구 사항 또는 구매 복원을 확인하려면 정품 확인 안내를 참고하세요. 시스템 요구 사항은 App Store 페이지의 표기를 기준으로 합니다. 처음 실행할 때 각 영역의 기능은 Home 및 VPN 구성 권한 안내에서 확인해 구독 문제와 시스템 권한 문제를 혼동하지 않도록 하세요.

02 / 접속 및 라우팅 단계

연결은 됐지만 인터넷에 접속할 수 없을 때: 세 가지 모드로 범위 좁히기

연결 상태가 표시된다는 것은 시스템 터널이 설정됐다는 뜻일 뿐, 도메인 조회, 서버의 트래픽 전달, 대상 웹사이트가 모두 정상이라는 의미는 아닙니다. 먼저 연결을 끊고 평소 이용하는 웹사이트에 접속해 기본 네트워크가 작동하는지 확인하세요. 이어서 연결한 뒤 같은 주소에 접속하고 전후 차이를 기록합니다. 연결을 끊어도 접속이 안 된다면 현재 네트워크나 대상 웹사이트부터 점검하세요. 모든 원인을 규칙 파일에서 찾으려 하지 마세요. 특정 앱이나 웹사이트만 실패한다면 해당 도메인, 오류 메시지, 재현 절차를 따로 기록해 전체 인터넷이 끊긴 문제와 구분하세요.

Global Routing을 점검에 활용하는 방법

Home에서 Global Routing을 확인하세요. Config 모드는 현재 적용 중인 설정에 따라 트래픽을 처리하며, Proxy와 Direct 모드는 비교 테스트에 사용할 수 있습니다. 모드 이름은 규칙의 PROXY 및 DIRECT 키워드와 관련이 있지만 같은 설정 위치를 가리키는 것은 아닙니다. 진단할 때는 네트워크와 선택한 서버를 고정한 다음 모드를 하나씩 바꾸고, 매번 대상에 새로 접속하세요. 여기서는 테스트 결과만 비교하고 임시 테스트 모드를 일상 설정으로 그대로 두지 마세요. 로컬 주소, 특수 규칙, 시스템 트래픽은 실제 기록과 함께 판단해야 합니다.

Proxy에서는 접속되지만 Config에서 실패한다면 선택한 서버를 통한 대상 접속은 가능하므로 현재 설정에서 해당 트래픽이 DIRECT, REJECT 또는 다른 정책으로 처리되는지 확인하세요. 반대로 Direct는 정상이고 Proxy에서 실패한다면 선택한 서버의 설정, 상태, 외부 연결 경로를 먼저 점검합니다. 세 모드 모두 실패한다면 테스트 대상 자체가 정상인지 확인한 다음 DNS와 현재 네트워크를 살펴보세요. 한 번 성공했다고 모든 트래픽이 정상인 것은 아니며, 한 번 실패했다고 특정 규칙에 문제가 있다고 단정할 수도 없습니다. 접속 기록과 반복 테스트를 함께 확인하세요.

편집 내용만 보지 말고 실제 적용 중인 설정을 확인하세요

Config에서 현재 실제로 사용 중인 설정 파일이 방금 점검한 파일인지 확인하세요. 한 파일을 편집하고 다른 파일을 계속 사용하면 규칙을 올바르게 작성했는데도 효과가 없는 상황이 생길 수 있습니다. 원본 파일을 보존하고 별도의 테스트 설정을 만들어 소수의 규칙으로 대상을 확인한 뒤 기존 규칙을 조금씩 추가하세요. 규칙은 위에서부터 순서대로 적용되며, 먼저 일치하는 규칙이 적용됩니다. 앞쪽의 포괄적인 규칙은 뒤에 있는 구체적인 규칙이 적용되지 않게 할 수 있습니다. 일치 유형, 도메인 범위, 정책 이름, FINAL 위치를 함께 확인하세요.

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

위 예시는 구조를 설명하기 위한 것입니다. 예시 도메인과 하위 도메인은 PROXY로 보내고, 지정된 사설 네트워크 대역은 DIRECT로 처리하며, 나머지 요청은 FINAL이 처리합니다. 모든 네트워크에 적합한 완전한 설정이 아니며 기존 설정의 DNS와 다른 매개변수를 대신하지도 않습니다. 실제 문제를 테스트할 때는 대상 도메인을 확인하려는 도메인으로 바꾸고 서버가 사용 가능한지 먼저 확인하세요. 기존에 정책 그룹을 사용했다면 정의를 확인하지 않은 채 이름을 바꾸지 마세요. 규칙 문제가 정책 참조 문제로 바뀔 수 있습니다.

접속 기록으로 원인 확인을 마무리하세요

대상 페이지를 다시 열고 앱에서 확인할 수 있는 연결 또는 진단 기록에서 같은 시각의 요청을 찾아 실제 도메인, 적용된 규칙, 정책, 오류 정보를 확인하세요. 한 페이지에서 로그인, 이미지, API 등 여러 도메인을 요청할 수 있습니다. 첫 화면은 표시되지만 로그인이 실패한다면 첫 화면 도메인이 아니라 두 번째 요청을 점검해야 할 수 있습니다. 확인을 마친 뒤 정상적인 Config로 되돌리고 임시 테스트 설정을 끄세요. 모드 설명은 Global Routing 세 가지 모드 안내를, 규칙 범위는 규칙 유형 자세히 보기를 참고하세요.

접속 기록에서 예상한 정책으로 요청을 보냈는데도 대상 서버가 거부하거나 로그인 오류를 반환한다면 대상 계정, 브라우저 세션, 서버 외부 연결 조건을 추가로 확인하세요. 모든 웹사이트 문제를 해결하려고 Proxy 규칙 범위를 계속 넓히지 마세요. 명확한 근거를 먼저 저장한 뒤 서버 시간 초과 또는 DNS 항목을 확인하세요.

03 / 서버 및 프로토콜 단계

서버 시간 초과: 주소, 핸드셰이크, 트래픽 전달을 각각 확인

Connectivity Test에 시간 초과가 표시돼도 서버 장애가 확정된 것은 아닙니다. 테스트 방식, 대상, 현재 네트워크, 서버 설정이 결과에 영향을 줍니다. 어떤 테스트를 사용했는지 확인하고 실제 웹 접속 결과와 비교하세요. 포트에 연결할 수 있다고 프로토콜 인증까지 성공한 것은 아니며, 테스트 대상이 응답한다고 모든 웹사이트에 접속할 수 있는 것도 아닙니다. 테스트 결과는 단서로 활용하고, 특정 수치나 시간 초과 표시만으로 결론을 내리지 마세요. 비교 기준을 만들려면 같은 서버, 같은 네트워크, 같은 테스트 대상을 유지해야 합니다.

먼저 서버 정보가 빠짐없이 일치하는지 확인하세요

현재 SERVER 항목의 편집 정보를 열고 사용자가 보유한 서버 자료와 항목별로 비교하세요. 주소, 포트, 프로토콜 유형, 인증 정보, 전송 설정이 서로 맞는 조합이어야 합니다. 직접 복사할 때 앞뒤 공백, 누락된 문자, 줄바꿈이 없는지 확인하고 설명 문구를 필드에 함께 붙여 넣지 마세요. 서버 주소에 도메인을 입력했다면 해당 도메인을 조회할 수 있는지도 확인하세요. 주소를 입력한 뒤에도 연결되지 않는다고 인증서와 서버 이름 점검을 건너뛰어서는 안 됩니다. 필드가 비슷해 보인다는 이유만으로 확인을 마쳤다고 판단하지 마세요.

오류가 발생한 단계에 따라 다음 조치 선택

기록에 도메인 조회 실패가 나타나면 DNS 항목을 확인하세요. 연결 거부라면 단순한 응답 대기 시간 초과와 다른 상황이므로 주소, 포트, 서버의 수신 상태를 점검합니다. 연결 후 인증 오류가 발생하면 암호나 ID 정보를 확인하세요. TLS 관련 오류는 기기 날짜와 시간, 서버 이름, 인증서 상태도 점검해야 합니다. 오류 문구는 프로토콜에 따라 달라질 수 있으므로 문제를 보고할 때는 ‘연결 안 됨’이라고만 쓰기보다 원문을 남기는 편이 유용합니다. 다만 민감 정보가 포함될 수 있으므로 해당 부분은 가리세요.

TLS 연결에서는 연결 주소, 서버 이름, 전송 계층의 Host가 서로 다를 수 있습니다. 기존 서버 자료에 맞춰 입력해야 하며, 필드를 줄이려고 모두 같은 값으로 바꾸면 안 됩니다. WebSocket 등 전송 방식을 사용한다면 경로, 대소문자, 관련 요청 헤더 설정도 확인하세요. 경로의 문자 하나만 달라도 올바른 호스트에 연결하고 원하는 서비스로 진입하지 못할 수 있습니다. 서버 이름 오류를 숨기려고 인증서 검증을 끄지 마세요. 근본 원인을 설명하지 못하며 정상적인 검증 범위를 바꾸게 됩니다.

네트워크 비교로 앱 문제와 경로 문제 구분

같은 서버 설정을 유지한 채 사용 가능한 네트워크 두 곳에서 각각 테스트하세요. 한쪽에서는 정상이고 다른 쪽에서는 계속 시간 초과가 발생한다면 원래 네트워크의 외부 연결 제한, 로그인 상태, 해당 프로토콜 전송 지원 여부를 먼저 확인하세요. 두 곳 모두 실패한다면 기존에 보유한 같은 구독의 다른 항목과 비교합니다. 특정 항목만 실패한다면 해당 서버나 설정의 문제일 가능성이 높습니다. 모든 항목이 함께 실패한다면 구독 전체 변경 여부, 인증 만료 여부, 기기의 공통 설정 변경 여부를 추가로 확인하세요.

포트, 프로토콜, 인증 필드를 운에 맡겨 연달아 바꾸지 마세요. 서버 정보가 사용 중인 서비스 제공업체에서 관리된다면 테스트 시각, 네트워크 유형, 오류 단계, 민감 정보를 가린 설정 차이를 전달해 해당 항목의 요구 사항이 바뀌었는지 문의하세요. 서버를 직접 관리한다면 해당 시각의 서버 기록을 확인해 연결 도달 여부, 인증 수락 여부, 후속 요청 전송 여부를 살펴보세요. 클라이언트가 응답을 받지 못한 경우와 서버가 인증을 명확히 거부한 경우는 대응 방법이 다릅니다.

수정을 마친 뒤 항목을 저장하고 다시 선택해 새 연결을 시작하세요. 이전 연결의 결과를 계속 확인하지 않도록 합니다. 안정적으로 접속되는지 확인한 다음 일상적인 자동 연결과 규칙 설정을 복원하세요. 프로토콜 필드의 의미는 용어 안내에서 확인할 수 있습니다.

04 / Subscribe 데이터 단계

구독 업데이트 실패: 데이터 가져오기와 가져온 내용 적용을 구분하세요

Subscribe 업데이트에 실패하면 현재 사용할 수 있는 항목부터 보존하고 구독 전체를 바로 삭제하지 마세요. 구독 업데이트는 주소 요청, 응답 수신, 내용 분석, 항목 갱신 단계를 거칩니다. 어느 단계에서든 실패하면 최종적으로 업데이트 실패로 표시될 수 있습니다. 먼저 구체적인 메시지와 업데이트 시각을 기록하고 기존 항목으로 여전히 연결할 수 있는지 확인하세요. 업데이트는 실패했지만 기존 항목이 작동한다면 모든 서버 설정을 바꾸기보다 구독을 가져오는 경로나 내용부터 점검하세요.

주소의 출처와 전체 내용 확인

구독 주소는 사용자가 보유한 서비스 정보에서 확인해야 합니다. 복사할 때 전체 쿼리 매개변수를 유지하고 공백, 따옴표, 줄바꿈, 안내 문구가 섞이지 않았는지 확인하세요. 일부 서비스는 관리 페이지, 안내 페이지, 구독 주소를 각각 제공하므로 브라우저에서 열리는 페이지가 가져올 수 있는 구독 데이터라는 보장은 없습니다. 로그인 페이지 주소를 Subscribe 주소로 사용하지 말고, 링크가 길다는 이유로 끝부분 매개변수를 삭제하지 마세요. 구독 주소에 인증 정보가 포함될 수 있으므로 화면 캡처나 진단 기록을 공유하기 전에 민감한 부분 전체를 가리세요.

서비스 정보의 주소가 변경됐다면 기존 관리 경로에서 먼저 확인한 뒤 앱의 기록을 수정하세요. 전달받은 메시지에 포함된 오래된 주소를 그대로 사용하지 마세요. 브라우저 접속은 로그인 페이지, 오류 페이지, 리디렉션 여부를 확인하는 데 도움이 될 수 있지만 브라우저와 앱의 요청 환경은 다를 수 있습니다. 따라서 브라우저에서 열린다고 앱에서도 가져올 수 있는 것은 아닙니다. 브라우저에 로그인 상태가 남아 있으면 표시된 내용이 세션에 의존할 수 있지만 구독 요청은 별도로 가져올 수 있고 지원되는 형식의 데이터가 필요합니다.

응답 결과에 따라 점검 항목 선택

HTTP 상태를 확인할 수 있다면 인증 관련 오류는 구독 인증 정보와 계정 상태를 먼저 점검하고, 리소스를 찾을 수 없다는 오류는 경로가 바뀌었는지 확인하세요. 요청이 너무 잦다는 메시지가 나오면 업데이트를 반복하지 말고 서비스 요구 사항에 따라 기다리세요. 서버 오류는 구독 관리자가 확인해야 합니다. 연결 시간 초과는 내용 형식 오류와 다르므로 현재 네트워크와 구독 도메인 조회를 먼저 점검하세요. 재테스트할 때는 같은 주소를 사용해야 합니다. 네트워크와 링크를 동시에 바꾸면 결과를 판단하기 어렵습니다.

파싱 오류에 가까운 메시지가 나타나면 응답 내용이 프로토콜 항목인지, 설정 파일인지, 웹페이지 텍스트인지 확인하세요. 구독과 Config에서 사용하는 완전한 설정 파일은 서로 다른 객체입니다. 둘 다 링크 형태라는 이유만으로 같은 입력란에 넣지 마세요. 일부 항목에 현재 앱에서 지원하지 않는 필드 조합이 포함될 수 있습니다. 일부만 가져오기에 실패한다면 전체 주소가 사용할 수 없다고 단정하지 말고 실패한 항목의 프로토콜과 설정을 확인하세요. 지원 범위는 현재 앱 안내를 기준으로 합니다.

기존 항목을 보존해 업데이트로 연결 수단을 잃지 않도록 하세요

구독 주소에 접속할 때 현재 연결 경로가 필요할 수 있습니다. 먼저 서버를 모두 삭제한 뒤 구독을 업데이트하면 기존에 사용할 수 있던 가져오기 경로를 잃을 수 있습니다. 기존 설정과 사용 가능한 항목을 먼저 저장한 다음 업데이트 요청이 예상한 경로로 전송되는지 확인하세요. 방금 연 웹페이지와 구독 요청이 같은 연결을 사용한다고 단정하지 마세요. 선택한 서버가 더 이상 작동하지 않는다면 사용자가 보유한 다른 항목과 사용 가능한 네트워크만 비교하세요. 출처를 확인할 수 없는 데이터를 가져와 점검을 우회하지 마세요.

업데이트가 성공한 뒤 항목 수가 바뀌었는지만 확인하는 것은 첫 단계일 뿐입니다. 현재 선택한 항목이 남아 있는지, 주요 설정값이 덮어써졌는지, 이름이 중복돼 다른 항목을 선택하지 않았는지도 확인하세요. 직접 조정한 항목이 있다면 다음 구독 업데이트에서 필드가 덮어써지는지 확인하고, 필요하면 비교용으로 별도 복사본을 보관하세요. ‘업데이트 완료’를 ‘서버 연결 가능’과 같다고 보지 마세요. 데이터 가져오기와 실제 서버 연결은 각각 검증해야 합니다.

이 장의 점검을 마치면 주소 오류, 가져오기 경로 실패, 응답 이상, 형식 불일치 중 어디에 해당하는지 구분할 수 있어야 합니다. 가져오기 기본 절차는 빠른 시작 가이드를 참고하세요. 규칙 설정을 가져온 경우에는 설정 파일 각 섹션 안내를 확인하고 서버 구독과 규칙 파일을 혼용하지 마세요. 복구 후 필요한 업데이트와 연결 테스트를 한 번만 실행해 반복 새로고침으로 새로운 제한이 생기지 않도록 하세요.

05 / 성능 및 경로 단계

속도 저하: 첫 화면 대기, 전송 지연, 일부 기능 멈춤을 나눠 확인

‘속도가 느리다’는 증상은 최소 세 가지로 나뉩니다. 페이지가 열리기 전 대기 시간이 길거나, 페이지 로딩이 시작된 뒤 전송이 느리거나, 특정 앱이나 웹사이트에서만 멈칫하는 경우입니다. 어느 단계에서 느린지 먼저 설명한 다음 테스트를 선택하세요. 첫 화면 대기에는 DNS, 핸드셰이크, 리디렉션이 영향을 줄 수 있습니다. 전송 속도는 경로 용량과 혼잡의 영향을 더 많이 받고, 일부 기능만 느리다면 특정 도메인, 프로토콜, 대상 서비스의 문제일 수 있습니다. Connectivity Test 응답 시간은 특정 테스트 결과일 뿐 지속적인 다운로드 성능을 직접 나타내지 않으며 실제 사용 테스트를 대신할 수 없습니다.

반복 가능한 테스트 조건 만들기

기기, 네트워크, 서버, 모드, 테스트 대상을 먼저 고정하세요. 대용량 동기화, 시스템 다운로드, 기타 지속적인 전송 작업을 일시 중지하고 현재 요청이 끝난 뒤 다시 테스트합니다. 테스트 시각과 저전력 상태, 핫스팟 공유, 약한 신호 여부를 기록하세요. 시간과 대상이 다른 한 번의 결과를 비교하거나 여러 속도 테스트를 동시에 실행하지 마세요. 동시 테스트는 대역폭을 나눠 써서 정상 경로도 불안정해 보이게 할 수 있습니다. 한 번의 최고 기록을 노리기보다 짧은 간격으로 몇 차례 테스트해 추세를 확인하는 편이 유용합니다.

같은 네트워크에서 먼저 연결을 끊고 대상에 직접 접속한 결과를 확인한 뒤, 연결하고 Proxy 모드로 서버 경로를 점검합니다. 마지막으로 Config에서 평소 라우팅을 확인하세요. Proxy는 정상인데 Config에서 느리다면 대상의 일부 리소스가 다른 정책으로 처리되는지 확인합니다. 두 모드 모두 느리고 다른 기존 서버는 정상이라면 현재 서버 경로의 문제일 가능성이 높습니다. 모든 방식이 느리다면 Wi-Fi 신호, 네트워크 혼잡, 대상 서비스부터 점검하세요. 설정을 대규모로 수정하지 마세요.

페이지에서 느린 요청 찾기

한 페이지는 텍스트, 이미지, 스크립트, 동영상, 로그인 API를 동시에 요청할 수 있습니다. 메인 페이지가 로드됐다고 모든 관련 도메인이 정상인 것은 아닙니다. 이미지가 느리거나 로그인이 계속 진행 중이거나 재생이 시작된 뒤 멈춘다면 같은 시간대의 연결 기록을 살펴 지속적으로 실패하거나 반복 재시도되는 요청을 찾으세요. 첫 화면 도메인에만 규칙을 추가하면 실제로 멈춘 리소스를 처리하지 못할 수 있습니다. 반대로 편의를 위해 너무 넓은 도메인 범위에 규칙을 적용하면 원래 정상인 접속 경로도 바뀔 수 있습니다. 실제 요청을 근거로 규칙을 조정하세요.

처음 접속할 때마다 느리고 이후에는 눈에 띄게 개선된다면 DNS 조회, 연결 설정, 캐시 영향을 확인하세요. 장시간 전송 중 주기적으로 멈춘다면 네트워크 전환, 패킷 손실, 경로 혼잡, 서버 리소스 경쟁을 고려합니다. 캐시는 비교 결과에 영향을 줄 수 있고 브라우저를 새로고침해도 기존 연결이 사용될 수 있습니다. 재테스트할 때는 가능하면 새 접속을 시작하고 첫 요청인지 기록하세요. 테스트를 위해 앱 데이터를 모두 지울 필요는 없으며, 데이터 삭제를 일반적인 속도 개선 방법으로 삼지 마세요.

프로토콜과 MTU는 근거를 확인한 뒤 조정하세요

전송 방식이 복잡할수록 빨라지는 것은 아닙니다. 적절한 프로토콜은 서버 설정과 현재 네트워크 조건에 따라 달라집니다. 특정 전송 방식이 제한되는 것으로 의심된다면 사용자가 이미 보유한, 설정이 올바른 항목끼리 먼저 비교하세요. 앱에서 프로토콜 이름만 단독으로 바꾸지 마세요. MTU 등의 설정도 웹 문서에 적힌 고정값을 근거 없이 적용해서는 안 됩니다. 작은 요청은 정상인데 큰 요청이 멈추고 반복 비교 결과도 뒷받침할 때 해당 항목을 점검하세요. 변경 전에 기존 값을 저장하고 한 번에 하나씩 바꾼 뒤 같은 대상으로 재테스트하세요. 효과가 분명하지 않으면 원래대로 되돌리세요.

대상 서비스는 로그인 상태, 리소스 유형, 외부 연결 조건에 따라 다르게 작동할 수 있습니다. 다른 웹사이트는 정상인데 특정 대상만 계속 느리다면 대상 서비스 상태와 서버에서 대상까지의 경로를 각각 확인하세요. 이것만으로 앱 전체 성능이 부족하다고 결론 내릴 수는 없습니다. 기기 과열, 백그라운드 작업 집중, 약한 신호로 인한 재전송도 체감 속도에 영향을 줍니다. 기기가 정상 작동 상태로 돌아온 뒤 다시 테스트해 일시적인 시스템 부하를 규칙 설정 문제로 오인하지 않도록 하세요.

원인을 확인한 뒤 문제를 설명하고 개선하는 데 필요한 변경만 남기고 임시 테스트 규칙을 삭제하세요. 평소 Config로 돌아가 다시 확인합니다. 특정 웹사이트만 Proxy로 보내는 방법은 지정 도메인 라우팅 안내를 참고하세요. DNS 조회 단계가 느리다면 모든 서버를 바꾸는 대신 다음 장에서 DNS를 점검하세요.

06 / 도메인 조회 단계

DNS 문제: 서버 도메인과 대상 도메인 조회를 구분하세요

DNS 문제는 모든 도메인이 열리지 않는 경우에만 나타나는 것이 아닙니다. 서버 주소를 조회할 수 없거나 특정 하위 도메인만 실패하거나, 처음 접속이 매우 느리거나, 네트워크 전환 후 문제가 생길 수도 있습니다. 실패가 서버 연결 전인지 연결 후인지 먼저 확인하세요. 서버 도메인 조회에 실패하면 프로토콜 연결이 차단되고, 대상 도메인 조회에 실패하면 터널이 설정된 뒤 문제가 발생할 수 있습니다. 두 단계는 사용하는 경로와 조건이 다를 수 있으므로 DNS 설정 하나만 바꾸고 모든 문제가 해결됐다고 판단하지 마세요.

오류 기록으로 조회 단계 확인

문제 발생 시각의 오류 기록에서 서버 주소와 접속 대상 중 무엇이 표시되는지 비교하세요. 서버 도메인에서 사용할 수 있는 주소를 얻지 못했다면 기본 네트워크가 정상인지 확인한 뒤 도메인 입력, 현재 설정의 조회 방식, 시스템 네트워크 상태를 점검합니다. 서버에 이미 연결됐고 특정 대상만 실패한다면 여러 모드에서 해당 도메인의 결과를 비교하고 실제 요청이 규칙에 따라 예상한 정책으로 전달됐는지 살펴보세요. 도메인 조회 성공은 주소를 얻었다는 뜻일 뿐 해당 주소의 서비스에 접속할 수 있다는 뜻은 아닙니다. 이후 연결도 별도로 확인해야 합니다.

‘웹사이트 주소를 직접 입력해 열리는지’만으로 판단하지 마세요. 많은 웹사이트는 도메인에 따른 사이트 선택, 인증서 검증, 요청 헤더에 의존합니다. 주소로 직접 접속되지 않는다고 네트워크가 끊겼다고 볼 수 없으며, 특정 주소가 응답한다고 원래 도메인이 올바르게 조회된다는 뜻도 아닙니다. 원래 도메인을 유지한 상태로 같은 대상과 네트워크에서 조회 및 연결 기록을 비교하는 편이 정확합니다. 앱에서 관련 진단 정보를 제공한다면 결과 유형, 소요 시간, 오류 단계를 기록하세요. 이상해 보이는 주소 하나만 잘라 캡처하지 마세요.

조회 경로에 순환 의존성이 있는지 확인

암호화된 DNS를 사용하더라도 DNS 서버의 도메인을 먼저 조회하고 연결해야 합니다. 조회 경로가 아직 설정되지 않은 Proxy에 의존하고 Proxy 서버의 도메인 역시 해당 DNS 서버에 의존한다면 서로 기다리는 순환 상태가 생길 수 있습니다. 설정을 바꾸기 전에 세 단계를 정리하세요. 서버 도메인을 누가 조회하는지, DNS 서버에는 누가 연결하는지, 대상 도메인은 누가 조회하는지 확인합니다. 이미 작동이 확인된 DNS 설정으로 먼저 복구한 다음 사용자 지정 설정을 하나씩 추가하세요. DNS 서버를 여러 개 동시에 설정해 두고 어느 설정이 적용되는지 추측하지 마세요.

설정 파일의 DNS 매개변수, 시스템 네트워크의 조회 설정, 다른 네트워크 확장이 함께 결과에 영향을 줄 수 있습니다. 먼저 현재 적용 중인 Config를 확인한 다음 [Host]의 로컬 매핑이나 다른 재정의 설정이 있는지 살펴보세요. 오래된 로컬 매핑은 일반 조회를 건너뛰고 더 이상 적합하지 않은 주소를 도메인에 고정할 수 있습니다. 매핑을 유지해야 한다면 용도를 기록하고 정기적으로 확인하세요. 출처를 모르는 항목은 먼저 복사본을 저장하고 전체 설정 파일을 삭제하는 대신 해당 매핑만 따로 비활성화해 테스트하세요.

[Host]
example.com = 192.0.2.10

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

위 내용은 구조를 보여주는 예시이며 문서에 사용된 예시 주소를 실제 접속 대상으로 사용해서는 안 됩니다. [Host]는 도메인과 주소의 매핑에 영향을 주고 도메인 규칙과 주소 규칙은 이후 라우팅 방식을 결정합니다. 예시의 no-resolve는 해당 주소 규칙을 위해 도메인 조회를 적극적으로 시작하지 않게 하는 설정입니다. 모든 요청에서 DNS를 사용하지 않는다는 뜻도, 도메인이 서버 측에서 조회된다는 보장도 아닙니다. 이 옵션 하나를 일반적인 DNS 복구 스위치처럼 사용하지 말고 현재 규칙 순서와 실제 연결 경로를 함께 고려하세요.

듀얼 스택 네트워크와 캐시 변화를 확인하세요

같은 도메인도 주소 유형이 다르게 반환될 수 있으며 현재 네트워크에서 각 주소에 접속할 수 있는지도 달라질 수 있습니다. 한 네트워크에서는 정상이고 다른 네트워크에서는 실패한다면 실제 사용된 주소 유형과 연결 오류를 비교하세요. 특정 네트워크 기능을 바로 끄지 마세요. 일부 주소만 접속할 수 없다면 경로나 서버 측 문제일 수 있으며 조회 방식을 바꾸는 것은 선택되는 주소를 변경할 뿐 근본 원인을 해결하지 못할 수 있습니다. 네트워크 전환 직후의 일시적인 문제는 이전 캐시나 기존 연결 때문일 수도 있습니다. 영향을 받은 요청을 종료하고 새로 연결한 뒤 판단하세요.

복구 여부를 확인할 때는 서버 연결, 문제가 발생한 도메인, 원래 정상인 도메인 하나 이상을 테스트해 일부 문제를 고치면서 다른 접속이 깨지지 않았는지 살펴보세요. 차이를 만든 조회 설정이나 매핑을 기록한 뒤 임시 테스트 항목을 복원합니다. 설정 구간의 역할은 [General], [Rule], [Host] 안내에서 확인할 수 있습니다. 도메인 규칙과 주소 규칙의 범위를 이해하려면 용어 안내를 참고하세요. 조회 결과의 주소와 접속 기록도 개인 정보에 해당할 수 있으므로 공유할 때는 진단에 필요한 정보만 남기세요.

07 / 실행 상태 및 변경 단계

배터리 소모 및 업데이트 후 문제: 최근 변경 사항을 기준으로 재테스트

배터리 소모 증가와 업데이트 후 연결 변화는 모두 시간순으로 살펴보세요. 문제가 언제 시작됐는지, 직전에 무엇을 변경했는지, 당시 어떤 네트워크를 사용했는지, 지속적인 전송이 있었는지 기록합니다. 시스템의 배터리 사용 목록에 Shadowrocket이 표시된다고 모든 소모가 특정 설정 때문이라고 단정하지 마세요. VPN 확장이 다른 앱의 트래픽을 처리하므로 시스템의 사용량 분류와 실제 사용 환경이 통계에 영향을 줍니다. 화면 사용 시간, 네트워크 활동, 반복 가능한 비교 결과를 함께 살펴보고 사용 시간이 다른 두 구간의 백분율만 비교하지 마세요.

배터리 소모가 늘었다면 반복 재시도와 지속 활동을 먼저 확인

사용 조건이 비슷한 상황에서 안정적으로 연결된 때와 연결을 반복하는 때의 사용량을 각각 살펴보세요. 서버 연결이 계속 실패하거나 네트워크 신호가 약하거나 네트워크를 자주 전환하거나 다른 앱이 실패한 리소스를 계속 요청하면 네트워크 활동이 늘 수 있습니다. 반복되는 연결 오류가 있는지 확인한 다음 계속 실패하는 도메인이나 백그라운드 요청을 찾으세요. 특정 앱에서 동기화가 계속 진행 중이라면 모든 규칙을 끄기보다 해당 작업을 일시 중지해 변화를 확인하는 편이 원인을 찾기 쉽습니다. 테스트를 위해 배터리를 다 쓸 필요는 없으며 비슷한 시간대와 부하를 비교하면 됩니다.

On Demand가 의도한 대로 작동하는지, 특히 네트워크 조건이 바뀐 뒤 연결을 반복해서 실행하는지 확인하세요. 자동 실행을 잠시 끄고 수동으로 안정적인 연결을 만든 뒤 변화를 살펴봅니다. 문제가 크게 줄었다면 조건을 하나씩 다시 활성화하세요. On Demand는 연결을 시작하는 조건을 제어하며 트래픽 라우팅과는 별개입니다. 이를 수정해도 규칙 문제를 해결할 수는 없습니다. 연결이 끊긴 뒤 계속 다시 시작된다면 자동 실행인지 실패 후 재연결인지 먼저 구분하세요. 실행 원인을 확인하지 않은 채 시스템 설정과 앱에서 스위치만 반복해 끄고 켜지 마세요.

진단에 필요한 기록만 유지하고 완료 후에는 일상적인 로그 설정으로 복원해 불필요한 상세 기록을 오래 남기지 마세요. 기기 온도, 모바일 네트워크 신호, 핫스팟 공유, 백그라운드 백업도 함께 고려해야 합니다. 연결을 끊은 뒤에도 기기가 계속 뜨겁거나 배터리가 비정상적으로 소모된다면 시스템과 다른 앱을 확인하세요. 인증서 검증을 포기하거나 프로토콜 설정을 무작위로 바꾸거나 시스템 구성을 삭제하는 방식으로 배터리를 아끼려 하지 마세요. 배터리 소모 원인과 개선 효과를 연결하는 근거가 없는 조치입니다.

업데이트 후 문제는 실제 변경 범위부터 확인

앱 업데이트, 시스템 업데이트, 구독 업데이트, 원격 설정 업데이트가 비슷한 시기에 이루어질 수 있지만 변경되는 내용은 서로 다릅니다. 화면 위치만 바뀌었는지, 특정 항목이 작동하지 않는지, 모든 연결이 실패하는지, 규칙 적용 결과가 달라졌는지 먼저 확인하세요. App Store의 앱 설명과 업데이트 기록을 살펴보고 사용 중인 구독과 설정도 같은 시기에 바뀌었는지 확인합니다. 앱과 시스템의 호환성 요구 사항은 App Store 페이지의 표기를 기준으로 하세요. 다른 기기의 오래된 화면 캡처만으로 현재 기기에도 적용된다고 추정하지 마세요.

업데이트 전 사용할 수 있었던 설정의 복사본을 보존하고 현재 내용과 프로토콜 설정, 정책 이름, DNS, 로컬 매핑, 규칙 순서를 비교하세요. 같은 설정 파일이 원격 업데이트로 덮어써졌다면 변경된 내용을 먼저 확인하세요. 모든 변화를 앱 자체의 문제로 돌리지 마세요. 오래된 필드가 더 이상 맞지 않는다면 현재 앱 안내에 따라 조정하세요. 기존 동작을 복원하려고 출처가 불분명한 여러 설정값을 한꺼번에 추가하지 마세요. 간단한 테스트 설정으로 기준을 만들면 문제가 설정 자체인지 공통 실행 환경인지 구분하는 데 도움이 됩니다.

되돌릴 수 있는 조치부터 복구를 시작하세요

먼저 연결을 끄고 앱을 다시 연 다음 확인된 서버와 최소한의 설정으로 테스트하세요. 필요하면 기록을 저장한 뒤 기기를 재시동합니다. 기존 설정에서만 실패한다면 구간별로 복원해 문제를 유발하는 항목을 찾으세요. 모든 설정에서 실패한다면 시스템 VPN 상태와 네트워크 조건을 계속 확인합니다. 앱을 삭제하면 로컬 데이터에 영향을 줄 수 있으며 다시 받아도 기존 서버와 규칙이 자동으로 복원되는 것은 아닙니다. 백업을 마치고 복원 가능 여부를 확인하며 다른 원인을 배제한 뒤에만 고려하세요. 구매 복원 방법은 구매 항목 복원 및 재설치 안내를 참고하세요.

복구를 확인한 뒤 이전에 사용하던 On Demand, 일상 설정, 백그라운드 작업을 하나씩 다시 활성화하세요. 특정 항목을 복원한 뒤에만 문제가 재현된다면 해당 조건을 명확히 기록해 계속 점검하세요. 재현되지 않는다면 일시적으로 복구된 상태로 기록하고 관찰을 이어가세요. 근본 원인을 찾았다고 단정하지 마세요.

08 / 기기 및 사용 환경 단계

iPad 점검: 네트워크, 설정, 절전 후 복귀 비교

iPad와 iPhone은 같은 방식으로 문제를 점검할 수 있지만 기기별 네트워크, 시스템 권한, 앱 화면 구성, 백그라운드 사용 환경은 다를 수 있습니다. 한 기기에서 정상이라고 다른 기기의 시스템 설정을 그대로 복사하지 마세요. 비교를 위해 다른 기기의 구독 인증 정보를 공개하지도 마세요. 두 기기가 동일하게 유효한 서비스 정보를 사용하고, 같은 대상과 비슷한 네트워크 조건에서 테스트하는지 먼저 확인하세요. 앱 구매 범위, 호환성, 시스템 요구 사항은 App Store 페이지의 표기를 기준으로 합니다. 다운로드 경로 안내는 iPad 다운로드 및 첫 실행을 참고하세요.

‘같아 보이는’ 설정 차이 확인

실제로 선택된 SERVER, Global Routing 모드, 현재 Config를 각각 확인하세요. 표시 이름이 같아도 내용은 다를 수 있습니다. 오래된 구독 항목이 같은 이름을 유지하면서 다른 주소나 설정값을 사용할 수도 있습니다. 목록 제목만 보지 말고 주요 필드와 실제 적용 중인 파일을 비교하세요. iPad의 넓은 화면에서는 목록과 편집 내용이 동시에 표시될 수 있습니다. 항목을 수정해 저장한 뒤 실제 사용 대상으로 선택됐는지 확인하세요. 편집 화면에서 선택한 상태를 연결이 전환된 것으로 착각하지 마세요.

시스템 VPN 권한은 각 기기에서 따로 확인해야 합니다. 다른 기기에서 이미 허용했더라도 이 기기의 권한을 대신하지 않습니다. iPad의 스위치가 바로 꺼진다면 첫 번째 장에 따라 시스템 VPN 구성, 다른 연결, 기기 관리 정책을 확인하세요. 학교나 업무용 iPad는 관리 정책의 적용을 받을 수 있습니다. 구성을 추가, 수정, 삭제할 수 없다는 메시지가 나타나면 관리자에게 먼저 문의하세요. 관리 기기와 개인 기기의 차이를 곧바로 앱 문제라고 판단하거나 관리 항목을 임의로 제거하지 마세요.

Wi-Fi와 핫스팟 환경을 각각 테스트

Wi-Fi만 사용할 수 있는 기기라면 이용 가능한 다른 Wi-Fi나 개인 핫스팟에서 비교 테스트할 수 있습니다. 핫스팟 테스트는 기본 네트워크 경로도 바꾸므로 기기만 달라지는 테스트는 아닙니다. 두 기기가 같은 라우터에 연결돼도 주파수 대역, 격리 정책, 로그인 상태가 다를 수 있습니다. 먼저 VPN을 끄고 iPad에서 네트워크 로그인을 완료했는지, 일반 접속이 정상인지 확인한 다음 연결을 켜세요. 특정 Wi-Fi에서만 실패한다면 서버 설정은 유지하고 해당 네트워크를 점검하세요. 모든 항목을 새로 만들지 마세요.

프린터, 로컬 웹페이지, 가정용 기기에 접속할 수 없다면 시스템의 로컬 네트워크 권한과 라우팅 규칙을 구분하세요. 관련 권한을 요청받았다면 실제 사용 목적에 따라 확인합니다. 규칙을 사용한다면 실제 로컬 네트워크 대역에 맞는 경로를 지정해야 합니다. 모든 라우터가 같은 사설 네트워크 대역을 사용하는 것은 아니므로 현재 네트워크 정보에서 주소 범위를 확인하세요. 로컬 서비스가 도메인 주소를 사용한다면 로컬 DNS 조회와 기기 검색 방식에도 의존할 수 있습니다. 외부 DNS가 반환하는 주소가 로컬 접속에 적합하지 않을 수 있으므로 포괄적인 규칙 하나만 추가해 해결하려 하지 마세요.

[Rule]
DOMAIN,localhost,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
FINAL,PROXY

위 설정 조각은 사설 주소 범위와 기본 처리 정책의 관계를 보여주는 예시이며 일상 설정을 그대로 덮어쓰라는 뜻은 아닙니다. 사용하기 전에 현재 네트워크, 기존 정책, 원격 서비스에서도 사설 주소를 사용하는지 확인하세요. Proxy를 통해 접속해야 하는 사설 네트워크가 있다면 모두 Direct로 보내는 설정은 해당 환경에서 문제를 일으킬 수 있습니다. 구체적인 규칙은 더 포괄적인 규칙보다 앞에 두고 실제 로컬 접속으로 규칙 적용 결과를 확인하세요. 첫 번째 일치 규칙과 FINAL의 의미는 규칙 유형 안내를 다시 참고하세요.

화면 잠금 해제 후 새로 생긴 변화만 확인

화면을 잠그기 전에는 연결이 정상이었지만 잠금 해제 후 문제가 생겼다면 먼저 깨어난 시점에 네트워크가 바뀌었는지 기록한 뒤 On Demand와 연결 기록을 확인하세요. 시스템이 절전 상태에서 돌아오면서 기존 연결이 끊겼을 수 있으므로 기존 페이지가 계속 로딩되기를 기다리기보다 새 페이지를 열어 확인하는 편이 낫습니다. 여러 창 중 특정 앱만 멈춰도 모든 네트워크가 실패한 것은 아닙니다. 같은 기기의 다른 접속 결과를 비교한 뒤 연결을 다시 설정할지 결정하세요. 백그라운드 연결을 유지하려고 최근 앱 목록에서 앱을 반복해서 제거하지 마세요.

점검을 마친 뒤 이 기기의 권한 문제, 설정 차이, 특정 네트워크 제한, 로컬 네트워크 라우팅, 절전 후 연결 복구 문제 중 어디에 해당하는지 설명할 수 있어야 합니다. 추가 지원이 필요하면 두 기기의 비교 조건과 민감 정보를 가린 오류 기록을 정리해 공유하고 구독 전체를 보내지 마세요. 일상적으로 다시 사용하기 전에 가이드의 기본 절차에 따라 연결과 라우팅을 다시 확인하세요. 기능 범위와 On Demand의 역할은 기능 안내에서 확인할 수 있습니다. 검증된 설정의 복사본을 보관해 다음 문제가 생겼을 때 같은 기준에서 점검을 시작하세요.