Shadowrocket 문제 해결 가이드

연결 스위치가 켜지지 않거나 자동으로 꺼짐

먼저 스위치가 어느 단계에서 멈추는지 확인하세요

연결을 눌러도 반응이 없거나, 잠깐 켜졌다가 꺼지거나, 켜진 뒤 계속 재연결되는 현상은 서로 다릅니다. 먼저 Home 화면에서 조작 후 시스템 권한 요청이 표시되는지 확인하고, 시스템 설정에서 VPN 상태를 살펴보세요. 시스템 권한 승인은 연결에 필요한 구성을 생성하도록 허용한다는 뜻일 뿐, 서버 인증이나 대상 사이트 접속이 성공했다는 뜻은 아닙니다. 권한 요청이 화면에 표시되어 있다면 내용을 확인하고 승인을 완료하세요. 요청 창 뒤에서 앱 스위치를 반복해서 누르면 권한 대기 상태를 연결 멈춤으로 오인할 수 있습니다.

처음 연결할 때는 VPN 구성 추가를 허용해야 하며 기기 암호나 시스템 인증을 요청할 수 있습니다. 이전에 권한 요청을 취소했다면 앱에서 다시 연결을 시도하세요. 시스템 설정의 메뉴 이름은 시스템 버전에 따라 다를 수 있으므로 VPN을 검색해 구성을 확인할 수 있습니다. Shadowrocket에 해당하는 항목인지 확인된 경우에만 점검하고, 회사·학교 또는 기기 관리 정책상 유지해야 하는 구성은 함부로 삭제하지 마세요. 관리 기기에서 VPN 구성이 제한되어 있다면 관리자에게 확인해야 합니다. 서버 설정을 바꿔도 시스템 정책 제한은 해제되지 않습니다.

로컬 네트워크와 연결 설정을 나눠 확인하세요

먼저 연결을 끄고 브라우저에서 평소 열리는 페이지에 접속해 Wi-Fi 또는 셀룰러 네트워크가 작동하는지 확인하세요. 공용 Wi-Fi는 웹 로그인 절차를 먼저 완료해야 할 수 있습니다. 기기에 연결 표시가 있더라도 인터넷에 접속할 수 있다는 뜻은 아닙니다. 네트워크 인증을 완료한 뒤 다시 연결하세요. 기본 네트워크도 작동하지 않으면 신호, 네트워크 계정 상태 또는 라우터 연결부터 점검하고 Config는 동시에 바꾸지 마세요. 다른 사용 가능한 네트워크로 전환해 다시 테스트하면 문제가 현재 접속 환경에 한정되는지 확인할 수 있습니다.

기본 네트워크가 정상이라면 Home에서 서버 하나가 실제로 선택되어 있는지 확인하세요. 구독 그룹 이름만 표시되는 상태와는 다릅니다. 선택한 항목을 열고 기존 서비스 제공자가 안내한 프로토콜, 주소, 포트 및 인증 정보를 대조하세요. 먼저 현재 Config 사본을 저장한 다음, 사용 가능하다고 확인된 설정과 비교해 보세요. 특정 Config를 활성화하자마자 연결이 종료되고 다른 Config는 계속 켜져 있다면 해당 설정의 문법과 참조 관계를 우선 점검하세요. 유일한 사본을 바로 덮어쓰면 문제 당시 상태와 되돌릴 기준을 모두 잃을 수 있습니다.

자동 연결과 반복 실행 확인하기

스위치가 꺼졌다가 다시 켜진다면 On Demand가 활성화되어 있는지, 현재 네트워크가 연결 조건을 충족하는지 확인하세요. 문제를 진단하는 동안에는 On Demand를 잠시 끄고 수동으로 테스트하면 자동 규칙이 연결 상태를 바꾸는 일을 막을 수 있습니다. 기기에서 VPN 구성을 사용하는 다른 기능도 현재 연결에 영향을 줄 수 있습니다. 일시 중지가 가능하고 해당 기능임을 확인한 경우에만 잠시 중지한 뒤 다시 테스트하세요. Wi-Fi 전환, 화면 잠금 또는 앱을 다시 여는 동작 등 상태를 바꾼 정확한 동작을 기록하세요. 막연히 ‘가끔 끊김’이라고만 적지 마세요.

스위치가 잠시 켜졌다가 바로 꺼지면 앱에 표시되는 오류 설명이나 연결 기록을 확인하세요. Config 구문 오류, 필수 항목 누락, 확장 기능 실행 중단, 원격 서버 시간 초과는 각각 해결 방법이 다릅니다. 먼저 연결을 중지하고 홈 화면으로 나갔다가 앱을 다시 연 뒤 한 번 통제된 테스트를 진행하세요. 그래도 복구되지 않을 때 기기를 재시동하세요. 재시동은 일시적인 시스템 상태를 초기화할 수 있지만 잘못된 비밀번호, 유효하지 않은 서버 주소 또는 Config 구문 오류를 고치지는 못합니다. 복구된 뒤에도 같은 절차를 반복해 문제가 잠시 숨겨진 것뿐은 아닌지 확인하세요.

스위치는 켜져 있지만 인터넷에 연결되지 않음

반복 가능한 접속 테스트를 준비하세요

스위치가 켜져 있다는 것은 로컬 연결이 실행 중이라는 뜻일 뿐, 원격 서버, DNS와 규칙이 모두 정상임을 보장하지 않습니다. 평소 접속 가능한 용도가 서로 다른 대상 두 곳을 선택하고 페이지 전체가 열리지 않는지, 이미지만 표시되지 않는지, 특정 앱만 네트워크에 연결되지 않는지 각각 기록하세요. 연결을 끈 뒤 같은 대상에 접속해 기본 네트워크와 비교하세요. 연결을 꺼도 문제가 계속되면 대상 사이트 장애, 네트워크 로그인 상태와 기기 네트워크 문제부터 확인하세요. 존재하지 않는 원인을 프록시 규칙에서 찾으려 하지 마세요.

테스트할 때는 같은 브라우저와 페이지를 비슷한 시간에 사용해 캐시 적중을 복구로 오인하지 않도록 하세요. 필요하면 페이지를 다시 열거나 한 번도 방문하지 않은 일반 페이지를 선택하세요. 앱의 첫 화면에 콘텐츠가 표시된다는 이유만으로 네트워크가 정상이라고 판단하지 마세요. 로컬 캐시를 보여 주는 것일 수 있습니다. 브라우저는 정상인데 특정 앱만 문제가 있다면 그 앱의 셀룰러 데이터 권한, 백그라운드 작업 여부, 로그인을 다시 연결해야 하는지 확인하세요. 전체 기기의 문제로 확대하기 전에 살펴보세요.

Global Routing으로 규칙과 연결 경로를 구분하세요

Global Routing에서 현재 Config, Proxy 또는 Direct 중 무엇을 사용 중인지 확인하세요. 진단을 위해 설정을 잠시 바꿀 때는 원래 값을 기록하세요. Direct는 기본 네트워크 경로를, Proxy는 현재 서버를 거치는 접속을, Config는 현재 설정의 규칙에 따른 접속을 확인하는 데 사용합니다. 세 가지는 서버 종류나 속도 설정이 아닙니다. Proxy는 규칙 문제를 분리해 확인하는 데 도움이 되지만 모든 대상이 같은 서버를 계속 거쳐야 한다는 뜻은 아닙니다.

Proxy는 정상인데 Config에서 실패하면 대상이 DIRECT, REJECT 또는 사용할 수 없는 정책 그룹으로 지정되어 있는지 확인하세요. Config를 앞에서부터 살펴보며 일치하는 규칙을 찾고, 특히 범위가 넓은 DOMAIN-KEYWORD, 네트워크 대역 규칙, 앞쪽에 있는 기본 처리 규칙을 주의 깊게 확인하세요. Direct는 정상인데 Proxy가 실패한다면 도메인 규칙을 서둘러 수정하지 말고 현재 서버부터 확인하세요. 비교를 마치면 원래 설정으로 되돌린 뒤 다음 항목을 변경해 테스트 설정이 일상적인 사용 환경에 남지 않도록 하세요.

적용된 규칙과 관련 요청 확인하기

하나의 페이지는 주소 표시줄의 도메인뿐 아니라 이미지, 스크립트, 로그인 및 API 도메인에도 요청을 보낼 수 있습니다. 메인 페이지는 정상인데 로그인이 실패한다면 앱에서 확인할 수 있는 연결 기록을 열고 실패 시점의 요청 및 정책을 찾아보세요. 기록에서 대상에 REJECT가 적용된 것이 확인되면 먼저 해당 규칙의 의도를 확인하고 사본에서 범위를 좁혀 조정하세요. 이미지 요청 하나 때문에 규칙 그룹 전체를 삭제하지 말고, 도메인 이름만 보고 용도를 추측하지 마세요. 실제 실패 기록과 서비스 안내를 우선 참고하세요.

아래 예시는 규칙 구문과 순서만 보여 줍니다. 예시 도메인은 PROXY를 사용하고, 지리 데이터베이스와 일치하는 주소는 DIRECT를 사용하며, 나머지 트래픽은 FINAL로 전달됩니다. 이 예시는 그대로 사용할 수 있는 완성된 Config가 아닙니다. PROXY가 실제 Config 환경에서 사용 가능한 정책을 올바르게 가리켜야 합니다. 규칙을 테스트하기 전에 현재 활성화된 Config를 편집 중인지 확인하세요. 저장한 뒤 필요에 따라 연결을 다시 설정하고 같은 대상으로 재시험하세요. 활성화되지 않은 파일을 수정해도 현재 실행 결과는 바뀌지 않습니다.

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

두 경로 모두 연결되지만 도메인 접속만 실패하면 DNS를 확인하세요. 특정 서버에서만 실패한다면 시간 초과 항목을 참고하세요. 브라우저에 표시된 모든 네트워크 오류를 규칙 문제로 단정하지 마세요. 인증서, 대상 서비스 점검 및 계정 로그인도 접속 중단의 원인일 수 있습니다. 도움을 요청할 때는 스위치 화면만 보내기보다 ‘대상, 설정, 서버, 결과’를 모두 기록해 전달하세요. 스위치는 켜져 있지만 인터넷에 연결되지 않을 때 확인할 항목과 비교해 점검 순서를 다시 살펴볼 수 있습니다.

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

테스트 결과로 확인할 수 있는 범위를 구분하세요

지연 시간 테스트, 프로토콜 연결 설정, 실제 웹페이지 열기는 서로 다른 단계입니다. 테스트에서 응답을 받았다는 것은 해당 테스트 경로가 그 시점에 작동했다는 뜻일 뿐, 모든 웹 요청이 성공한다는 뜻은 아닙니다. 반대로 테스트가 시간 초과로 표시되어도 테스트 방식이나 대상의 영향일 수 있으므로 수치 하나만으로 서버가 영구적으로 중단됐다고 판단하지 마세요. 사용한 테스트 방법을 먼저 기록한 뒤 같은 서버로 고정된 대상에 접속하고, 실제 오류와 함께 연결 전·인증 중·요청 전달 후 어느 단계에서 문제가 발생하는지 확인하세요.

여러 서버가 동시에 시간 초과되면 먼저 기본 네트워크를 바꿔 비교하세요. 같은 네트워크에서 항목 하나만 실패한다면 해당 항목의 설정과 원격 상태를 우선 확인하세요. 테스트 중에는 반복적인 일괄 속도 측정을 중단해 추가 요청이 상황을 혼란스럽게 하지 않도록 하세요. 매번 사용 가능하다고 확인된 항목 하나와 실패 항목 하나만 비교하면 됩니다. 기존 서비스 제공자가 점검이나 계정 상태를 안내했다면 관련 정보를 확인하세요. 이 가이드는 Config 사용법을 설명하며 서버 제공처를 안내하거나 추천하지 않습니다.

주소, 인증, 전송 순서로 항목 확인하기

먼저 서버 주소에 프로토콜 접두사, 경로, 공백 또는 줄바꿈이 잘못 포함되지 않았는지, 포트가 안내받은 값과 일치하는지 확인하세요. 호스트 이름을 입력하는 칸에 구독 링크 전체를 붙여 넣으면 안 됩니다. 복사 과정에서 비밀번호나 식별 정보에 전각 문장 부호가 들어가면 값이 같아 보여도 인증에 실패할 수 있습니다. 경험에 따라 포트나 암호화 방식을 바꾸지 말고 원래 설정을 항목별로 대조하세요. 민감한 항목은 기기에서만 확인하고 공개 화면을 캡처할 때는 전체 비밀번호, 식별 정보와 구독 인증 정보를 가리세요.

다음으로 프로토콜에 필요한 인증 및 전송 매개변수를 확인하세요. Shadowsocks는 비밀번호와 암호화 방식이 일치해야 합니다. VMess와 VLESS는 UUID, 전송 방식, TLS 관련 항목을 서로 혼용하면 안 됩니다. Trojan은 일반적으로 비밀번호와 TLS 정보도 함께 확인해야 합니다. Hysteria2와 WireGuard에도 각각 필수 항목이 있으므로 다른 프로토콜의 설정을 그대로 적용하지 마세요. 프로토콜 이름이 같아도 모든 서버가 같은 옵션을 사용하는 것은 아닙니다. 실제 설정은 사용자가 보유한 서비스의 Config를 기준으로 확인하세요.

TLS, 시간 및 네트워크 차이 확인하기

TLS를 사용하는 연결은 서버에서 요구하는 이름을 확인해야 합니다. 서버 주소, SNI와 전송 계층의 Host는 서로 다른 용도로 쓰일 수 있으므로 이름이 다르다고 모두 같은 값으로 바꾸지 마세요. 기기의 시간이 크게 틀리면 인증서 유효 기간 확인에도 영향을 줄 수 있으므로 시스템 날짜와 시간대가 올바른지 살펴보세요. 인증서 오류가 발생하면 이름, 시간 및 서버 설정부터 확인하세요. 인증서 검증 건너뛰기를 일반적인 해결 방법으로 사용하지 마세요. 검증 기준을 바꾸고 발견해야 할 설정 또는 인증서 문제를 감출 수 있습니다.

Wi-Fi에서는 실패하지만 셀룰러 네트워크에서는 정상인 경우, 또는 그 반대라면 접속 네트워크의 차이를 추가로 확인해야 합니다. 일부 전송 방식은 UDP를 사용하며 네트워크 장비가 UDP를 일반적인 웹 연결과 다르게 처리할 수 있습니다. 먼저 서비스 제공자가 제공하고 지원을 확인해 준 Config로 비교하세요. 프로토콜 이름을 임의로 바꾸거나 MTU를 무작정 조정하지 마세요. 프로토콜, 인증 및 경로가 올바른 것을 확인하고 작은 패킷은 정상이지만 큰 요청은 실패하는 현상을 재현할 수 있을 때 경로와 패킷 분할 관련 문제를 추가로 살펴보세요.

구독 업데이트 실패 또는 가져오기 결과 이상

링크 유형과 실패 단계를 먼저 확인하세요

구독은 서버 목록을 가져오는 주소이며 단일 서버나 Config 파일과는 다릅니다. 먼저 기존 서비스 제공자가 준 정보가 어떤 유형인지 확인한 다음 알맞은 방법으로 가져오세요. 웹페이지 주소, 계정 관리 페이지 주소 또는 개별 공유 정보를 구독 입력란에 넣으면 예상한 목록을 가져오지 못할 수 있습니다. 점검할 때는 링크 구조와 출처 안내만 확인하고 전체 링크를 공개 대화에 붙여 넣지 마세요. 쿼리 매개변수에 접속 인증 정보가 포함되는 경우가 많아 유출되면 계정 이용에 영향을 줄 수 있습니다.

업데이트 실패를 요청 시작 불가, 오류 응답 수신, 콘텐츠 파싱 실패, 목록 업데이트 후 연결 불가의 네 가지로 나눠 보세요. 요청할 수 없다면 네트워크와 도메인 확인을 먼저 점검하세요. 계정 또는 링크가 만료됐다는 안내가 나오면 원래 서비스 계정과 링크 상태를 확인하세요. 파싱에 실패한다면 응답 내용이 앱에서 지원하는 구독 형식인지 살펴보세요. 목록이 바뀌었지만 연결할 수 없다면 정보 가져오기는 완료됐을 수 있으므로 업데이트를 계속 누르지 말고 서버 항목이나 원격 상태를 확인하세요.

구독 요청의 네트워크 경로 분리하기

먼저 기본 네트워크로 정상 접속할 수 있는지 확인한 뒤 수동으로 한 번 업데이트하세요. 현재 연결이 작동하지 않고 구독 요청도 그 연결에 의존한다면 업데이트도 복구도 할 수 없는 상황이 반복될 수 있습니다. 기존 목록은 보존한 채 현재 연결을 중지하고 사용 가능한 네트워크에서 다시 시도한 다음 각 상태의 결과를 기록하세요. 모든 구독이 같은 요청 경로를 사용한다고 가정하거나 한 번 실패했다고 원래 링크를 덮어쓰지 마세요. 사용 중인 서비스 제공자의 접속 안내와 실제 비교 결과에 따라 처리하세요.

공용 Wi-Fi에서 로그인을 완료하지 않으면 요청이 로그인 페이지로 연결될 수 있습니다. 서비스에 문제가 있을 때도 서버 목록 대신 웹페이지 안내가 반환될 수 있습니다. 브라우저에서 표시된다고 해서 구독 형식이 올바르다는 뜻은 아닙니다. 파싱 오류가 나타나면 응답이 어떤 내용인지 먼저 확인하세요. 웹페이지 전체를 Add Server에 복사하지 마세요. 추가 확인이 필요하다면 기존 서비스 제공자에게 앱에 표시된 오류 유형을 설명하고 민감한 정보만 가려 전달하세요. 계정 정보가 포함된 응답 본문을 공개적으로 제출하지 마세요.

업데이트 전후의 그룹과 선택 상태 비교하기

업데이트 전에 현재 그룹, 선택된 서버 이름과 직접 추가한 항목을 기록하고 필요하다면 별도 사본을 저장하세요. 구독 업데이트는 해당 구독이 관리하는 항목을 교체할 수 있으며, 직접 수정한 값도 새 콘텐츠로 덮어쓸 수 있습니다. 따라서 구독 항목을 임시로 수정해 장기간 보관하는 방법으로 삼지 마세요. 업데이트 후에는 항목 수와 그룹이 예상과 일치하는지 확인하고 현재 선택한 항목이 남아 있는지도 살펴보세요. 이름 변경, 중복 이름 또는 서버 삭제로 인해 익숙한 선택이 더 이상 같은 연결을 가리키지 않을 수 있습니다.

업데이트 후 일부 항목만 남았다면 데이터가 누락됐다고 판단하기 전에 필터, 그룹 접기 또는 표시 범위가 바뀌었는지 확인하세요. 이름이 같은 항목의 설정이 다르다면 이름만 보지 말고 프로토콜과 주소를 확인하세요. 구독을 성공적으로 가져왔더라도 계정 서비스가 정상이라는 뜻은 아닙니다. 서비스 기간, 원격 점검 및 인증 정보는 각각 확인해야 합니다. 그룹 전체를 반복해서 삭제한 뒤 다시 가져와도 서버에서 반환된 콘텐츠 문제는 해결되지 않는 경우가 많습니다. 오히려 비교 자료를 잃어 원인 파악이 어려워질 수 있습니다.

확인 가능한 구독 상태로 복구하기

복구할 때는 출처가 명확한 구독 그룹 하나를 보존하고 먼저 수동 업데이트를 진행하세요. 목록이 정상적으로 사용되는지 확인한 뒤 자동 업데이트 옵션을 살펴보세요. 자동 업데이트 메뉴와 사용 조건은 현재 앱 화면을 기준으로 확인해야 하며, 유효하지 않은 링크를 고치는 방법으로 사용하면 안 됩니다. 앱을 열 때마다 새로 고침되어 임시 수정 사항이 덮어써진다면 관련 자동 업데이트 설정을 확인한 뒤 테스트 항목을 별도로 저장할지 결정하세요. 테스트가 끝나면 중복으로 가져온 그룹을 정리해 나중에 잘못 선택하지 않도록 하세요.

연결은 정상인데 속도가 느리거나 간헐적으로 끊김

먼저 ‘느림’이 어떤 상황인지 구체적으로 정하세요

페이지를 처음 열 때 오래 기다리는 현상, 다운로드 속도 저하, 동영상 간헐적 버퍼링, 게임 반응 지연은 하나의 지연 시간 수치로 설명할 수 없습니다. 연결 설정이 느린지 실제 전송이 느린지, 모든 대상에서 느린지 특정 앱에서만 느린지, 계속 발생하는지 특정 시간대에만 나타나는지 기록하세요. 첫 접속만 느리고 이후 요청은 정상이라면 DNS, 핸드셰이크와 캐시를 살펴보세요. 연결은 빠르게 완료되지만 대용량 파일 전송이 계속 멈춘다면 테스트 목록의 숫자만 보지 말고 경로 안정성, 처리량과 원격 서버 부하를 확인하세요.

테스트 중에는 대상, 서버와 접속 네트워크를 고정하고 시스템 업데이트, 사진 동기화 등 대량 전송을 잠시 중단한 뒤 같은 작업을 관찰하세요. 여러 속도 측정 작업을 동시에 실행하지 마세요. 대역폭을 함께 사용해 결과를 비교하기 어려워집니다. 가능한 한 비슷한 시간대에 비교해 아침과 저녁의 네트워크 부하 차이를 설정 효과로 오인하지 않도록 하세요. 서비스 제공자가 데이터 사용량이나 속도 조건을 안내했다면 현재 계정 상태를 확인하세요. 앱 설정만으로 원격 서비스의 실제 용량을 대신할 수는 없습니다.

기본 네트워크, 서버, 대상 순으로 비교하세요

먼저 연결을 끈 상태에서 기본 네트워크로 접속할 수 있는 고정된 대상을 열고 Wi-Fi 신호, 라우터의 업링크와 다른 기기의 네트워크 사용량을 확인하세요. 신호 막대가 많아도 무선 환경이 안정적이라고 단정할 수 없습니다. 간섭, 거리와 접속 장치의 부하가 전송에 영향을 줄 수 있습니다. 그다음 대상을 그대로 둔 채 현재 서버로 다시 테스트하세요. 사용자가 보유하고 사용 가능하다고 확인한 다른 서버로 전환해 특정 경로만 느린지 비교하세요. 서버를 바꾸는 동시에 DNS도 바꾸면 무엇이 개선에 영향을 줬는지 알 수 없습니다.

같은 서버에서 대부분의 대상은 정상인데 특정 대상만 느리다면 대상 사이트의 부하, 콘텐츠 전송 위치 또는 양쪽 사이의 경로가 원인일 수 있습니다. 먼저 Config에서 해당 도메인이 예상한 정책을 사용하는지 확인하세요. 특히 메인 사이트와 이미지·동영상 도메인이 서로 다른 방식으로 처리되는지 살펴보세요. 필요하면 Proxy로 잠시 비교 테스트한 뒤 원래 설정으로 되돌리세요. 특정 동영상 하나가 예상한 화질로 재생되지 않는다고 전체 연결에 문제가 있다고 볼 수는 없습니다. 재생 서비스의 적응형 처리, 계정 권한과 캐시 상태도 확인해야 합니다.

지연 시간, 패킷 손실과 처리량을 구분하세요

지연 시간은 왕복 또는 특정 테스트 과정에서 기다린 시간이고 처리량은 단위 시간 동안 실제로 전송된 데이터의 양입니다. 서로 연관은 있지만 같은 의미는 아닙니다. 경로 응답이 빠르더라도 지속적인 전송은 제한될 수 있으며, 응답이 다소 느려도 다운로드가 안정적으로 이어질 수 있습니다. 앱의 Connectivity Test는 도달 가능성을 살펴보는 데 도움이 되지만 모든 사용 상황을 평가하는 점수로 볼 수 없습니다. 서버를 선택할 때는 실제로 자주 하는 작업의 결과를 함께 고려하세요. 표시 수치를 낮추려고 계속 전환하면 재연결과 핸드셰이크 비용이 늘어납니다.

간헐적인 끊김은 연결이 얼마나 지속되는지 살펴봐야 합니다. 짧은 시간 동안 상태가 반복해서 바뀐다면 Wi-Fi 로밍, 셀룰러 전환, 화면 잠금 해제 또는 백그라운드 대용량 작업과 동시에 발생하는지 기록하세요. UDP에 의존하는 서비스는 웹페이지 접속 여부와 해당 서비스의 작동 여부를 따로 확인해야 합니다. 웹페이지의 주요 경로가 정상이라고 모든 전송이 똑같이 처리되는 것은 아닙니다. 테스트를 위해 MTU, 동시 연결 수 또는 전송 항목을 임의로 바꾸지 마세요. 명확한 근거와 원래 설정이 있을 때만 사본을 수정하고 되돌릴 수 있도록 비교 테스트를 진행하세요.

최적화 옵션을 늘리기보다 안정적인 설정을 유지하세요

문제 원인이 규칙 우회였다면 규칙 범위를 수정한 뒤 다른 자주 사용하는 대상도 다시 확인해 한 곳의 개선이 새로운 접속 문제를 만들지 않도록 하세요. 특정 네트워크에서만 발생하면 해당 네트워크와 다른 네트워크의 비교 기록을 보존하고 접속 장치를 추가로 점검하세요. 여러 네트워크에서 같은 서버가 느리다면 서버 상태와 원격 경로를 중점적으로 살펴보세요. 이유를 모르는 옵션을 모두 켜지 마세요. 최적화 옵션이 많아질수록 어떤 항목이 연결 동작을 바꿨는지 파악하기 어려워집니다.

DNS 확인 실패와 규칙 적용 결과 불일치

DNS 확인, 연결, 인증서 오류를 구분하세요

DNS는 도메인 이름을 이후 연결에 사용할 주소로 변환합니다. 도메인을 확인할 수 없는 문제, 주소를 받았지만 연결에 실패한 문제, 연결 후 인증서가 맞지 않는 문제는 서로 다른 단계에서 발생합니다. 오류가 도메인 확인과 관련되어 있는지 먼저 살펴본 뒤 여러 도메인에서 결과를 비교하세요. 특정 사이트의 주소로 도메인을 대체해 전체 과정을 확인하려 하지 마세요. HTTPS는 올바른 호스트 이름과 인증서가 필요한 경우가 많으므로 주소로 직접 접속하지 못한다고 네트워크 경로가 도달 불가하다고 단정할 수 없습니다.

여러 앱에서 새 도메인을 열 때 대기하지만 기존 연결은 계속 사용할 수 있다면 DNS 경로를 먼저 확인하세요. 특정 대상 하나만 문제가 있다면 대상 자체의 상태와 관련 규칙을 먼저 살펴보세요. 브라우저, 앱과 시스템은 각자 캐시를 보유할 수 있으므로 설정을 바꾼 뒤 결과가 항상 즉시 일치하지는 않습니다. 테스트 전에 원래 설정을 기록하고 연결을 다시 설정한 뒤 같은 접속을 반복하세요. 새로 시작한 요청과 기존 연결을 재사용하는 페이지를 구분해 캐시 차이를 무작위 오류로 오해하지 않도록 하세요.

현재 Config의 DNS 경로를 확인하세요

현재 활성화된 Config를 열고 DNS 설정이 실제 실행 중인 파일의 설정인지 확인하세요. 원래 Config에서 어떤 경로로 도메인을 확인하려는지 파악한 다음 DNS 서버에 연결할 수 있는지 살펴보세요. 익숙한 주소로 바꾸기만 한다고 현재 네트워크에 적합하다는 보장은 없습니다. 정상적으로 작동하던 경로가 오히려 중단될 수도 있습니다. 암호화 DNS를 사용하는 경우 해당 연결에도 네트워크, 올바른 시간 설정과 적절한 핸드셰이크 조건이 필요합니다. ‘암호화’가 모든 네트워크에서 자동으로 작동한다는 뜻은 아닙니다.

순환 의존성에 특히 주의하세요. 현재 서버 주소를 먼저 확인해야 하는데 DNS 요청은 아직 연결되지 않은 경로로만 처리할 수 있다면 연결 시작 단계에서 멈출 수 있습니다. 문제를 점검할 때는 기존 Config 안내에 따라 초기 DNS 경로를 확인하세요. 서버 도메인과 DNS 설정을 동시에 바꾸지 마세요. 서비스 제공자가 연결 주소와 핸드셰이크 이름을 따로 제공한다면 각 항목에 맞게 입력해야 합니다. DNS를 피하려고 조회한 주소를 임의로 영구 적용하지 마세요. 원격 주소가 변경되거나 전송 조건에 영향을 줄 수 있습니다.

도메인 규칙과 주소 규칙의 차이 이해하기

DOMAIN은 전체 도메인을 일치시키고 DOMAIN-SUFFIX는 지정된 도메인과 하위 도메인을 일치시킵니다. DOMAIN-KEYWORD는 더 넓은 범위에서 일치합니다. IP-CIDR, IP-CIDR6와 GEOIP는 주소 또는 주소 데이터베이스를 기준으로 판단합니다. 요청이 도메인 정보를 사용해 규칙에 일치하는지는 요청 출처, DNS 처리 과정과 현재 Config에 따라 달라집니다. 모든 연결이 반드시 도메인 규칙에 일치한다고 가정하지 마세요. 주소 표시줄만 보고 규칙 적용 결과를 추측하기보다 실제 기록을 먼저 확인하세요.

[Rule]
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.org,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
FINAL,PROXY

예시에 나온 두 네트워크 대역은 문서용 예시 주소이며 확인되지 않은 넓은 실제 대역으로 바꾸면 안 됩니다. no-resolve는 해당 주소 규칙을 적용하기 위해 추가 도메인 조회를 하지 않도록 하는 옵션이지, 모든 DNS를 끄거나 연결할 수 없는 DNS 서버를 고치는 기능은 아닙니다. 규칙은 순서대로 처리되므로 앞쪽의 범위가 지나치게 넓은 규칙이 뒤에 있는 구체적인 규칙보다 먼저 적용될 수 있습니다. 수정할 때는 범위를 최소화한 대상으로 먼저 확인한 뒤 확장 여부를 결정해 특정 문제를 다른 앱까지 확대하지 마세요.

IPv6 및 기기에서 적용되는 추가 설정 확인하기

같은 도메인이 서로 다른 유형의 주소를 받을 수 있고 Wi-Fi와 셀룰러 네트워크의 IPv6 조건도 다를 수 있습니다. 특정 네트워크에서만 실패한다면 관련 기능을 바로 모두 끄지 말고 주소 유형과 현재 경로의 지원 여부를 확인하세요. 시스템 프로파일, 네트워크 필터 또는 다른 DNS 설정도 실제 동작을 바꿀 수 있습니다. 본인이 확인할 수 있는 설정만 점검하고 관리 기기는 관리자에게 문의하세요. 설정을 바꾼 뒤에는 연결을 다시 설정해 이전 세션으로 인한 오판을 줄이세요.

배터리 소모 증가, 발열 및 백그라운드 활동 문제

먼저 통계 기간과 실제 사용량을 확인하세요

시스템 배터리 화면에 표시되는 비율은 선택한 기간을 기준으로 한 상대적인 값이며 앱이 어떤 상황에서나 동일한 전력을 사용한다는 뜻은 아닙니다. 다른 앱의 사용량이 적은 날에는 같은 연결 활동도 더 높은 비율로 표시될 수 있습니다. 이상 여부를 판단하기 전에 통계 기간, 화면 사용 시간, 실제 배터리 감소량과 지속적인 데이터 전송 여부를 기록하세요. 특정 비율만으로 정상적인 장시간 네트워크 전달, 기본 네트워크 신호 불량, 연결 실패 반복으로 인한 추가 활동을 구분할 수는 없습니다.

비슷한 조건에서 비교하세요. 같은 네트워크, 비슷한 화면 밝기, 비슷한 작업과 사용 시간이 적절합니다. 동영상 재생, 클라우드 동기화와 개인용 핫스팟 사용은 기기 전체의 부하를 바꾸므로 서로 다른 날의 작업을 그대로 비교하면 안 됩니다. 충전 중 발열과 단독 사용 중 발열도 구분하세요. 기기가 눈에 띄게 뜨겁거나 시스템 온도 경고가 표시되거나 배터리가 비정상적으로 빨리 줄어든다면 먼저 부하가 큰 작업을 중단하고 기기가 정상 상태로 돌아온 뒤 짧고 통제된 진단을 진행하세요.

연결 재시도 반복과 백그라운드 대량 전송 확인하기

연결이 불안정하면 DNS 조회, 핸드셰이크 및 세션 재설정이 반복되어 활동량이 늘어날 수 있습니다. 스위치와 시스템 VPN 상태가 자주 바뀌는지 확인하고 특정 서버나 네트워크에서만 문제가 발생하는지 살펴보세요. 서버가 계속 시간 초과되는데 자동 재시도를 유지해도 원격 상태가 고쳐지지는 않습니다. 연결을 일시 중지하고 기본 네트워크를 확인한 뒤 사용자가 보유한 다른 사용 가능 항목으로 비교하세요. 이상 원인을 파악하려면 단순한 연결 시간보다 실패 횟수와 발생 조건이 더 유용합니다.

사진 동기화, 콘텐츠 업데이트 또는 데이터 복구를 진행 중인 앱도 확인하세요. 연결을 켠 뒤 네트워크를 기다리던 백그라운드 작업이 시작될 수 있으므로 배터리 사용량 변화가 반드시 연결 자체 때문은 아닙니다. 시스템에서 허용하는 범위 안에서 관련 작업을 잠시 중지하고 상태를 살펴보세요. 통계 수치를 낮추려고 필요한 보안 설정을 끄거나 앱 데이터를 반복해서 지우지 마세요. 데이터 전송량과 배터리 변화를 같은 시간대 기준으로 비교해 정상적인 데이터 처리를 문제로 오인하지 않도록 하세요.

On Demand 및 진단 작업 확인하기

On Demand는 설정된 조건에 따라 연결을 시작합니다. 네트워크 환경이 계속 바뀌고 조건이 반복해서 충족되거나 해제되면 연결이 계속 재설정될 수 있습니다. 문제를 점검하는 동안에는 먼저 규칙을 기록한 뒤 On Demand를 잠시 끄고 수동으로 안정적인 연결을 유지해 보세요. 활동이 뚜렷하게 줄어든다면 기능 자체가 작동하지 않는다고 단정하지 말고 구체적인 트리거 조건과 현재 네트워크 변화를 확인하세요. 복구할 때는 조건을 하나씩 활성화하고 화면 잠금, 네트워크 전환 및 앱 재실행 시 동작이 예상과 일치하는지 확인하세요.

속도 일괄 테스트를 계속 실행하거나 상세 진단 기록을 오래 보관하거나 구독을 반복 업데이트하면 네트워크 또는 기기 처리량이 늘어날 수 있습니다. 진단이 끝나면 불필요한 테스트를 중단하고 문제를 파악하는 데 필요한 정보만 민감한 내용을 가려 보관하세요. Config가 복잡하다면 먼저 사본을 저장한 뒤 현재 테스트와 관련 없는 추가 처리를 일시 중지하고 차이를 확인하세요. 모든 규칙을 바로 삭제하지 마세요. 규칙을 줄여 배터리가 나아지더라도 직접적인 관련이 있다고 볼 수 없습니다. 지속적인 활동이나 반복 실패를 유발하는 항목을 확인해야 합니다.

조건별 비교로 변경 효과 확인하기

세 차례로 나눠 확인할 수 있습니다. 기본 네트워크에서 일반적인 작업, 수동 연결을 안정적으로 유지한 상태에서 같은 작업, On Demand를 다시 활성화한 상태에서 같은 작업을 진행하세요. 매회 작업 시간과 내용을 비슷하게 유지하고 배터리 변화와 연결 재설정 여부를 기록하세요. 특정 Wi-Fi에서만 이상이 뚜렷하면 신호와 라우터를 점검하세요. 여러 네트워크에서 같은 Config로 반복된다면 Config 사본과 발생 조건을 보관하세요. 재시동 직후 잠시 나아진 것만으로 해결됐다고 보지 말고 문제가 잘 발생하던 사용 환경에서 다시 확인하세요.

앱 또는 시스템 업데이트 후 문제 발생

먼저 무엇이 실제로 변경됐는지 확인하세요

업데이트 후 문제가 발생했다고 해서 업데이트 자체가 원인이라고 단정할 수는 없습니다. 같은 시기에 구독 자동 업데이트, 서버 점검, 네트워크 전환 또는 Config 변경이 있었을 수 있습니다. 마지막으로 정상 작동한 시점부터 처음 실패한 시점까지의 변경 사항을 정리하고 앱을 업데이트했는지 시스템을 업데이트했는지, 구독도 함께 업데이트했는지 확인하세요. 기존 Config를 보존하세요. 재설치, 데이터 삭제, 재가져오기를 연속으로 진행하면 여러 변경이 겹쳐 무엇이 영향을 줬는지 확인하기 어렵고 문제를 진단할 때 필요한 상태도 잃습니다.

앱 업데이트 후 Home을 열어 서버 목록, 현재 선택한 항목과 활성화된 Config가 예상대로인지 확인하세요. 메뉴 위치가 바뀌었다고 기존 콘텐츠가 사라진 것은 아닙니다. 먼저 그룹과 현재 파일을 확인한 뒤 다시 가져올지 결정하세요. 메뉴 이름이나 위치만 달라졌다면 이전 화면 캡처를 추측에 이용하지 말고 현재 인터페이스에 따라 조작하세요. 앱 구매와 업데이트는 App Store를 통해 진행해야 합니다. 구매 확인이나 복원 절차는 구매 항목 복원 안내를 참고하고 다른 방법으로 앱을 구하려 하지 마세요.

시스템 상태, Config, 원격 서버 순서로 다시 테스트하세요

먼저 연결을 끄고 기본 네트워크를 확인한 뒤 수동 연결을 한 번 다시 설정하세요. 시스템에서 VPN 권한을 다시 요청하면 내용을 확인하고 승인하세요. 기기 관리 제한이 적용되어 있다면 관리자에게 정책을 확인하세요. 시스템 업데이트 후 연결 문제가 생겼다면 연결을 중지하고 기기를 재시동한 뒤 같은 테스트를 진행할 수 있습니다. 다만 재시동 직후 잠시 성공했다고 해결된 것으로 판단하지 마세요. 화면 잠금 해제나 Wi-Fi 전환 등 이전에 문제가 발생했던 동작도 반복해 같은 조건에서 연결이 유지되는지 확인하세요.

그다음 같은 서버로 Direct, Proxy와 Config를 통제된 조건에서 비교한 뒤 원래 설정으로 되돌리세요. Config에서만 문제가 발생한다면 구문, 정책 참조와 규칙 순서를 확인하세요. 서버를 거치는 모든 접속이 실패한다면 주소, 인증과 전송 항목을 다시 확인하세요. 오래된 Config는 특정 항목 관계에 엄격하게 의존할 수 있습니다. 문제 발생 후에는 기존 서비스 제공자의 최신 설정 안내와 대조해 확인하세요. 잘 모르는 항목을 무작정 추가하거나 모든 검증 조건을 완화하지 마세요.

설정 이전 및 구독 덮어쓰기 처리하기

구독 새로 고침 직후 문제가 생겼다면 새로 고침 전에 저장한 사본과 현재 항목을 비교하세요. 프로토콜, 주소, 포트, TLS 및 전송 항목을 중점적으로 확인하세요. 이름이 그대로라도 내부 설정은 달라질 수 있습니다. 구독에서 관리하는 항목을 직접 수정했다면 새로 고침 과정에서 구독 내용으로 되돌아갈 수 있습니다. 이때 정상 작동이 확인된 테스트 설정은 별도로 저장하고 기존 서비스 제공자에게 차이를 확인하세요. 같은 구독 항목을 반복해서 수정한 뒤 곧바로 업데이트하지 마세요. 매번 다른 설정으로 테스트하게 될 수 있습니다.

Config를 이전할 때는 파일 선택과 정책 참조도 확인해야 합니다. 예상한 파일이 현재 활성화되어 있는지 먼저 확인하고, 해당 파일이 참조하는 정책에 대상 항목이 있는지 살펴보세요. 파일을 복사해도 외부 의존 항목까지 모두 복사되는 것은 아니며 가져오기에 성공했다고 모든 참조가 작동한다는 뜻도 아닙니다. 파싱 오류가 발생하면 구체적인 오류와 해당 줄 주변의 민감한 내용을 가린 부분을 보관하고 원인을 설명할 수 있는 부분만 수정하세요. 확인되지 않은 출처의 Config 전체를 바꿔 넣어 ‘테스트’하지 마세요. 분기, DNS와 처리 방식이 한꺼번에 바뀝니다.

마지막으로 구성 재설정과 앱 다시 받기 검토하기

서버 정보, 구독 출처와 Config 사본을 안전하게 저장하고 복구 방법을 알고 있을 때만 앱의 VPN 구성을 다시 만들거나 앱을 다시 받는 방법을 고려하세요. 다시 받기 전에 원래 구매에 사용한 계정을 확인해 App Store 계정 문제와 연결 문제를 혼동하지 않도록 하세요. 외부에 저장한 파일도 파일 이름만 보지 말고 실제로 열 수 있는지 확인하세요. 앱 내부의 이전 상태가 완전히 복구되지 않을 수도 있습니다. 이전 상태를 바탕으로 문제를 진단하려면 데이터를 정리하기 전에 필요한 기록을 먼저 남기세요.

iPad 연결, 복원 및 기기 간 차이

먼저 구매 상태와 Config 상태를 구분하세요

같은 구매 계정으로 앱을 받는 것과 기기에 서버 설정을 구성하는 것은 별개입니다. iPad의 App Store에서 앱 구매 상태를 확인하세요. 시스템 요구 사항, 호환성 및 통합 구매 여부는 App Store 페이지를 기준으로 확인해야 합니다. 앱을 다시 받을 수 있어도 iPhone의 구독, 서버 선택 및 Config가 iPad에 자동으로 나타나는 것은 아닙니다. 처음 앱을 연 뒤 실제 콘텐츠를 확인하고 빠른 시작 가이드에 따라 사용자가 보유한 정보를 가져오세요. 구매가 완료됐다는 사실만으로 연결 전 확인 절차를 생략하지 마세요.

App Store에 표시된 구매 상태가 예상과 다르면 시스템 상단의 계정 이름만 보지 말고 App Store에서 사용하는 계정을 확인하세요. 앱 ID는 932747118, 개발자는 Shadow Launch Technology Limited입니다. 복원 절차는 iPad 앱 받기 안내를 참고하세요. 구매 문제는 먼저 App Store에서 해결하고, 서버 인증이나 접속 문제는 이 페이지의 절차에 따라 점검해야 합니다. 한쪽이 다른 쪽을 대신 해결해 주지는 않습니다. 앱을 한 번 구매하면 앱 사용 권한을 얻는 것이며 서버 서비스는 포함되지 않습니다.

두 기기의 실제 설정을 비교하세요

iPhone은 정상인데 iPad에서 실패한다면 먼저 두 기기를 같은 사용 가능한 Wi-Fi에 연결하고 비슷한 시간에 같은 대상에 접속하세요. 선택한 서버, Global Routing, 현재 Config와 DNS 조건을 비교하되 서버 이름만 비교하지 마세요. 구독을 업데이트한 시점이 다르거나 이름이 같은 항목의 설정이 바뀌었거나 활성 파일이 다른 경우 결과가 달라질 수 있습니다. 비교할 때는 두 기기 모두 기록된 테스트 상태로 맞추고 매회 한 기기의 설정 한 항목만 바꾸세요. 양쪽을 동시에 바꾸면 기준을 잃습니다.

설정을 옮길 때는 본인이 확인할 수 있고 통제된 방법을 사용하세요. 가져온 뒤 주소, 포트, 프로토콜 및 필요한 인증 항목을 하나씩 확인하세요. 전체 구독 링크를 공개 문서나 이미지로 전달하지 말고 QR 코드에 민감한 정보가 없다고 가정하지 마세요. 동기화 방법이 Config 파일만 옮긴다면 해당 파일이 참조하는 서버나 정책이 존재하는지도 확인해야 합니다. 파일이 열린다고 모든 의존 항목이 준비된 것은 아닙니다. 알 수 없는 정책이 표시되면 임의로 다른 이름으로 바꾸지 말고 먼저 참조 관계를 채우세요.

iPad의 네트워크 및 시스템 제한 확인하기

일부 iPad는 Wi-Fi만 사용할 수 있으므로 셀룰러 네트워크 비교 절차를 그대로 따를 수 없습니다. 대신 사용할 수 있고 신뢰할 수 있는 다른 Wi-Fi에서 확인하세요. 셀룰러 네트워크를 지원하는 기기라면 네트워크 권한과 현재 데이터 연결을 각각 점검하세요. 휴대전화 핫스팟을 사용할 때 iPad는 핫스팟이 제공하는 네트워크 환경에 연결되므로 기본 네트워크가 정상인지도 확인해야 합니다. iPhone에서 접속할 수 있다고 핫스팟에 연결된 iPad도 같은 경로를 사용할 수 있다고 추정하지 마세요. 공유 연결, 신호와 세션 조건이 다를 수 있습니다.

학교, 직장 또는 가정에서 관리하는 iPad는 VPN, 계정 또는 네트워크 정책의 제한을 받을 수 있습니다. 처음 연결할 때 VPN 구성을 추가할 수 없다면 시스템 안내를 확인하고 관리자에게 문의하세요. 관리 정책상 유지해야 하는 항목을 삭제하려 하지 마세요. 공용 네트워크에서 웹 로그인이 필요하다면 연결을 시작하기 전에 기본 네트워크 인증을 완료하세요. 특정 앱 하나만 실패한다면 해당 앱의 네트워크 권한과 계정 상태를 확인하세요. 모든 앱이 실패할 때 서버, DNS 및 규칙 순서로 점검해 개별 앱의 권한 문제를 전체 문제로 확대하지 않도록 하세요.

화면 잠금, 멀티태스킹 및 장시간 사용 확인하기

iPad는 화면 분할, 멀티태스킹, 장시간 대기 상태를 오갈 수 있습니다. 앱이 백그라운드에 있다고 연결이 중단된 것은 아닙니다. 앱 창이 앞에 표시되는지만 보지 말고 시스템 VPN 상태와 실제 요청을 함께 확인하세요. 화면 잠금 해제 후 실패한다면 다시 깨어나기 전후의 Wi-Fi, On Demand 조건과 스위치 상태를 기록한 뒤 수동으로 연결을 다시 설정해 비교하세요. 자동 조건에서만 재현되면 조건 규칙을 우선 확인하세요. 수동 연결도 실패한다면 기본 네트워크와 서버 도달 가능성을 점검하세요.