Shadowrocket 문제 해결

연결 스위치가 켜지지 않음: 시스템 권한부터 확인

스위치가 켜진 상태를 유지하지 못한다면 ‘시스템에서 터널을 만들지 못한 경우’와 ‘터널은 만들어졌지만 접속에 실패한 경우’를 먼저 구분하세요. 전자는 켠 직후 꺼지거나, 권한 요청이 반복되거나, 시스템 설정의 VPN 상태가 바뀌지 않는 경우가 많습니다. 후자는 연결 상태는 유지되지만 콘텐츠를 불러오지 못합니다. 먼저 Home 화면에서 한 번의 연결 과정을 지켜보세요. 빠르게 반복해서 스위치를 누르면 정상적인 연결 과정도 응답이 없는 것처럼 보일 수 있습니다.

최초 권한 요청과 로컬 설정 확인

처음 활성화할 때 시스템에서 VPN 구성 추가를 허용하고 기기 암호나 시스템 인증으로 확인하라는 메시지가 표시될 수 있습니다. Shadowrocket에서 방금 직접 연결을 시도한 경우에만 권한 요청을 계속 진행하세요. 팝업을 취소했다면 앱으로 돌아와 다시 연결하면 됩니다. 앱 내 스위치 조작과 시스템 권한 승인은 별개의 단계입니다. 서버를 가져왔다고 해서 기기가 터널 생성을 허용한 것은 아닙니다. 권한을 승인한 뒤 시스템과 앱의 상태가 일치하는지 확인하세요.

시스템 설정에서 VPN 구성을 찾아 Shadowrocket에 해당하는 항목이 있는지 확인하세요. 설정 메뉴의 위치나 이름은 시스템 버전에 따라 달라질 수 있으므로, 고정된 경로를 찾기보다 설정 내 검색을 사용하세요. 네트워크 구성이 여러 개 있다면 이름과 용도를 먼저 기록한 다음 기기 트래픽을 처리할 수 있는 다른 연결을 잠시 중지하세요. 한꺼번에 삭제하지 마세요. 특히 회사나 학교에서 관리하는 기기의 구성은 관리 정책에 따라 다시 만들어질 수 있습니다.

Home에서 사용할 수 있는 서버가 선택되어 있는지 확인하세요. 목록에 항목이 있는지만 보지 말고 선택 표시가 있는지 살펴보세요. 해당 항목을 열어 Address, Port, 프로토콜 종류가 빠짐없이 저장되었는지 확인하세요. 방금 수정한 뒤 바로 나왔다면 다시 들어가 변경 내용이 저장되었는지 확인해야 합니다. 필드가 비어 있거나 구성을 해석할 수 없으면 연결 시작 단계에서 실패할 수 있습니다. 서버와 실제로 통신할 수 있는지는 다음 단계에서 확인하세요. 스위치가 꺼진 것만으로 원격 서버에 문제가 있다고 단정할 수는 없습니다.

On Demand와 시스템 제한 점검

수동으로 끈 뒤 다시 자동으로 켜진다면 On Demand부터 확인하세요. On Demand는 설정된 조건에 따라 연결을 시작하므로 사용자의 수동 조작과 함께 작동하면 스위치가 뜻대로 움직이지 않는 것처럼 느껴질 수 있습니다. 현재 조건을 기록한 뒤 On Demand를 잠시 끄고 수동 연결과 연결 해제를 비교 테스트하세요. 수동 상태가 안정적으로 유지되는 것을 확인한 다음 자동 조건을 하나씩 복원하세요. On Demand 규칙을 바꾸면서 서버까지 교체하지 마세요.

버튼을 조작할 수 없거나 권한 팝업이 계속 나타나지 않으면 기기가 조직에서 관리되는지, 시스템에서 VPN 변경을 제한하는지 확인하세요. 관리 정책에 따른 제한은 기기 관리자에게 문의해야 합니다. 앱을 반복해서 재설치해도 정책이 바뀌지는 않습니다. 개인 기기라면 네트워크를 사용하는 작업을 종료하고 기기를 정상적으로 재시동한 뒤 다시 테스트하세요. 재시동은 일시적인 상태를 초기화하는 방법이지 서버 설정이나 네트워크 조건을 고치는 방법은 아닙니다.

웹 로그인 인증이 필요한 Wi-Fi에서는 먼저 터널 연결을 해제하고 네트워크 인증을 완료한 다음 다시 연결하세요. 인증이 끝나지 않으면 Wi-Fi에 연결되어 있어도 외부 통신이 인증 페이지에서 차단될 수 있습니다. Wi-Fi 아이콘만 보지 말고 일반 웹페이지를 열어 기본 네트워크 연결이 복구되었는지 확인하세요. 이미 사용할 수 있는 다른 네트워크에서는 스위치가 안정적으로 유지된다면, 앱 데이터를 바로 지우기보다 기존 네트워크의 접속 조건을 점검하세요.

VPN 구성은 언제 다시 만들어야 하나요?

권한 기록에 문제가 있고 시스템과 앱 상태가 계속 일치하지 않으며 앞선 비교 테스트도 효과가 없을 때만 해당 VPN 구성을 다시 만드는 방안을 고려하세요. 먼저 서버 정보와 Config를 백업하고 연결과 On Demand를 중지하세요. 그런 다음 Shadowrocket에 해당하는 시스템 VPN 항목인지 확인한 뒤 삭제하고 앱으로 돌아가 권한을 다시 요청하세요. 시스템 VPN 항목 삭제와 앱 내 서버 삭제는 서로 다른 작업입니다. 확인 문구를 주의 깊게 읽고 필요한 자료를 잘못 삭제하지 않도록 하세요.

구성을 다시 만든 뒤에는 변수를 최소화해 테스트하세요. 확인된 서버 하나만 사용하고, 수동으로 연결하며, On Demand는 잠시 끕니다. 그래도 바로 연결이 끊기면 오류 메시지, 재현 순서, 시스템에 표시된 연결 상태를 기록하세요. 스위치는 안정적으로 유지되지만 접속할 수 없다면 다음 장으로 넘어가세요. 네트워크 설정 재설정을 처음부터 시도하지 마세요. 다른 네트워크 기록에도 영향을 주고 비교에 필요한 기존 환경을 없앨 수 있습니다.

연결 후 인터넷에 접속할 수 없음: 서버와 규칙을 따로 확인

연결 상태는 기기에서 해당 네트워크 터널이 시작되었다는 뜻일 뿐, 모든 요청이 목적지에 도달했다는 의미는 아닙니다. 문제를 확인할 때 정상적으로 접속할 수 있는 웹페이지 하나와 실제로 접속에 실패한 대상을 각각 선택하세요. 모든 앱에서 실패하는지, 특정 웹사이트만 실패하는지, 일부 리소스만 불러오지 못하는지 기록하세요. 브라우저의 일반 오류 메시지는 이름 확인, 연결, 인증서 문제를 모두 포함할 수 있습니다. 원래 표시된 메시지를 보존하고 곧바로 서버 이용 불가로 단정하지 마세요.

Global Routing으로 비교 테스트

먼저 현재 Global Routing 설정을 기록하고 세 가지 모드의 용도를 확인하세요. Config는 현재 구성의 규칙에 따라 정책을 선택합니다. Proxy는 프록시 경로로 처리할 수 있는 요청을 보내 비교하는 데 사용합니다. Direct는 직접 연결 경로를 비교합니다. 세 모드는 ‘성능이 좋은 순서’로 나열된 선택지가 아닙니다. 테스트가 끝나면 원래 설정으로 되돌리세요. 임시로 Proxy에서 접속에 성공했다고 해서 규칙 구성이 해결된 것은 아닙니다.

Direct에서는 접속되지만 Proxy에서 실패하면 기본 서버와 프로토콜 설정을 먼저 확인하세요. Proxy에서는 접속되지만 Config에서 실패하면 규칙 매칭과 정책 경로를 집중적으로 살펴보세요. 세 가지 모두 실패하면 먼저 연결을 완전히 해제하고 기본 네트워크를 테스트한 다음 DNS 장으로 넘어가세요. Direct 상태에서도 현재 네트워크의 처리 방식과 DNS 설정이 영향을 줄 수 있습니다. 따라서 ‘Direct로 전환’과 ‘연결 해제’는 별도의 비교 테스트로 기록하세요.

규칙 순서에 따라 요청 경로 확인

Config에서 이름이 비슷한 파일을 열어 본 것에 그치지 말고 현재 실제로 활성화된 파일을 확인하세요. 규칙은 보통 순서대로 매칭되며 앞쪽에서 이미 매칭된 항목이 뒤쪽 규칙의 처리 여부에 영향을 줍니다. 대상이 범위가 지나치게 넓은 DOMAIN-KEYWORD, 도메인 접미사 규칙 또는 IP 규칙에 먼저 걸리는지 확인하세요. 매칭된 정책이 실제로 존재하고 예상한 서버를 가리키는지도 살펴보세요. 규칙 내용이 맞아도 정책을 사용할 수 없으면 접속에 실패할 수 있습니다.

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

위 예시는 매칭과 기본 처리 관계만 보여주므로 기존 파일을 그대로 덮어쓰지 마세요. DOMAIN-SUFFIX는 예시 도메인과 하위 도메인에 적용됩니다. DOMAIN-KEYWORD는 범위가 더 넓으므로 수정 전에 잘못 매칭될 가능성을 고려하세요. FINAL은 앞선 규칙에 매칭되지 않은 요청을 처리합니다. 예시 도메인은 실제 대상에 맞게 바꾸고, PROXY가 현재 기본 서버를 사용하는지도 확인해야 합니다. 사용자 지정 정책 이름을 사용한다면 이름과 참조가 일치하는지 확인하세요. 철자 차이를 네트워크 문제로 오해하지 마세요.

페이지의 텍스트는 표시되지만 이미지, 로그인, 동영상이 실패한다면 주소창의 도메인만 확인하지 마세요. 하나의 페이지가 여러 도메인에서 리소스를 불러오거나 인증 과정에서 다른 주소로 이동할 수 있습니다. 한 번 재현한 뒤 앱에서 확인할 수 있는 요청 기록을 살펴보고 성공한 요청과 실패한 요청의 대상 및 정책을 비교하세요. 조정할 필요가 있다는 근거가 있는 규칙만 추가하세요. 리소스 하나가 실패했다고 범위가 넓은 키워드 규칙을 맨 위에 두면 수정 범위가 커져 실제 원인을 찾기 어려워집니다.

앱과 대상 서비스의 문제 범위 구분

앱 하나에서만 문제가 발생한다면 먼저 브라우저로 같은 서비스의 웹페이지에 접속해 비교하세요. 웹페이지가 정상이라고 앱 내부 API까지 정상이라는 뜻은 아니지만 문제 범위를 좁히는 데 도움이 됩니다. 앱에 이전 연결이 남아 있는지 확인하고, 정책을 바꾼 뒤 앱을 완전히 종료했다가 다시 열어 요청을 다시 보내세요. 기존 연결은 이전에 만들어진 경로를 계속 사용할 수 있습니다. 규칙을 수정했다고 모든 기존 연결의 정책이 즉시 바뀌는 것은 아닙니다.

로그인 제한, 계정 안내, 콘텐츠 권한 문제라면 대상 서비스가 반환한 메시지를 네트워크 시간 초과와 구분하세요. 연결 성공이 서버의 계정 상태를 바꾸지는 않습니다. 원래 설정으로 되돌린 뒤 특정 웹사이트에 적용할 규칙 작성법을 참고해 필요한 예외를 정리하세요. 대상 요청이 예상한 정책 경로를 안정적으로 이용하고 연결을 다시 만든 뒤에도 성공이 재현되어야 이번 규칙 점검을 마칠 수 있습니다.

서버 시간 초과: 연결 가능 여부와 프로토콜 인증 점검

서버 시간 초과가 발생하는 원인은 하나가 아닙니다. 주소 확인 실패, 대상 포트 연결 불가, 프로토콜 필드 불일치, TLS 검증 실패가 모두 일정 시간 기다린 뒤 오류로 나타날 수 있습니다. 먼저 앱에서 어떤 테스트를 실행했는지 구분한 뒤 실제 연결 중 어떤 일이 발생하는지 확인하세요. 지연 시간 테스트에서 결과가 나왔다는 것은 해당 테스트가 포함한 단계에서 응답을 받았다는 뜻일 뿐, 인증과 대상 요청, 지속적인 데이터 전송까지 정상이라는 보장은 없습니다.

서버 정보가 실제 설정과 일치하는지 확인

Home에서 현재 선택된 항목을 열고 본인이 보유한 원본 정보와 Type, Address, Port, 인증 필드를 하나씩 비교하세요. 주소를 복사할 때 앞뒤에 공백이 포함되거나, 전체 링크를 Address에 입력하거나, 구독 주소를 개별 서버 주소로 착각하기 쉽습니다. 포트에는 원본 정보에 명시된 숫자를 사용하세요. 프로토콜 이름만 보고 포트를 추측하지 마세요. QR 코드로 가져온 경우에도 가져온 뒤 항목을 열어 확인해야 합니다. 스캔 성공은 내용을 인식했다는 뜻일 뿐입니다.

서버 정보가 여전히 유효한지, 서버 측에서 접속 주소나 인증 정보를 변경했는지 확인하세요. 본인이 보유한 구독을 먼저 새로 고친 다음 새 항목과 기존 항목이 달라졌는지 비교할 수 있습니다. 직접 저장한 전용 매개변수가 있다면 업데이트로 덮어쓴 뒤 기억에 의존해 다시 입력하지 마세요. ‘원본 정보에 적힌 값’, ‘앱에 실제 저장된 값’, ‘현재 선택된 항목’을 함께 비교하면 매개변수 조합을 무작정 바꿔 보는 것보다 불일치를 찾기 쉽습니다.

현재 네트워크에서 먼저 테스트한 뒤 이미 사용할 수 있는 다른 네트워크에서도 같은 방식으로 테스트하세요. 두 네트워크 모두 실패하면 서버 상태와 설정을 우선 확인하세요. 한 네트워크에서만 실패한다면 해당 네트워크의 포트, 전송 유형 또는 접속 조건을 살펴보세요. 이 비교만으로 어느 쪽에 문제가 있다고 단정할 수는 없지만, 특정 네트워크의 조건을 설정 오류로 오해하는 일을 줄일 수 있습니다. 테스트하는 동안 같은 서버와 같은 방식을 유지해야 결과를 비교할 수 있습니다.

프로토콜별 주요 필드 확인

TLS를 사용하는 구성에서는 연결 주소와 인증서 이름이 서로 다른 역할을 할 수 있습니다. Address는 연결 대상이고 Peer/SNI는 서버 이름 및 인증서 처리에 관여합니다. 원본 정보에 이름이 명시되어 있다면 그대로 해당 필드에 입력하세요. 모든 필드를 같은 IP로 바꾸지 마세요. 기기의 날짜와 시간이 크게 틀려도 인증서 유효기간 확인에 영향을 줄 수 있습니다. 먼저 시간과 이름을 확인한 뒤 오류 메시지에 따라 점검을 이어가세요.

인증서 오류를 가리기 위해 Allow Insecure를 계속 켜 두지 마세요. 이 옵션은 검증 조건을 바꿉니다. 잠시 연결에 성공하더라도 서버 설정이 올바르다는 뜻은 아닙니다. 서버에서 제공한 도메인, 인증서 이름, TLS 요구 사항을 확인한 뒤 검증을 다시 활성화하세요. 정보가 충분하지 않다면 본인의 서비스 제공자에게 필요한 필드를 문의하세요. 매뉴얼의 예시가 실제 연결 매개변수를 대신할 수는 없습니다.

실제 요청으로 최종 확인

Connectivity Test를 실행한 다음 사용할 수 있는 것으로 확인된 웹페이지를 열어 콘텐츠가 제대로 표시되는지 확인하세요. 테스트 결과는 있지만 웹페이지가 열리지 않는다면 DNS와 규칙을 더 살펴보세요. 큰 요청만 실패한다면 속도 장에서 전송과 경로 문제를 확인하세요. 서로 다른 방식, 대상, 시간 초과 조건을 사용하는 테스트 결과를 직접 비교하지 마세요. 수치 차이가 같은 연결의 성능 변화를 뜻하지 않을 수 있습니다.

WireGuard에서는 Allowed IPs와 로컬 주소 범위도 확인해야 합니다. 이 항목은 대상 웹사이트를 입력하는 일반 규칙 목록이 아닙니다. 핸드셰이크 상태와 웹 접속은 나누어 살펴보세요. 라우팅 범위가 잘못되면 일부 대상에 접속할 수 없을 수 있습니다. 각 항목을 자세히 확인하려면 WireGuard 구성 필드 설명을 참고하세요. 본인에게 해당하지 않는 주소와 키를 그대로 복사하지 마세요.

문제 해결 기록에는 프로토콜, 테스트한 네트워크, 오류가 발생한 단계, 모든 서버에서 실패하는지 여부를 남기세요. 특정 항목만 실패하고 이미 보유한 다른 항목은 작동한다면 검증된 구성을 임시로 사용하면서 실패 항목은 본인의 서비스 제공자에게 확인하세요. 기록을 공유할 때 인증 값과 전체 서버 주소를 가리세요. 보통은 필드 이름과 오류 유형만으로도 문제를 설명할 수 있으므로 연결 정보를 통째로 공개할 필요는 없습니다.

구독 업데이트 실패: 요청·응답 내용·가져오기 결과 구분

Subscribe 업데이트에는 주소 읽기, 네트워크 요청 전송, 응답 수신, 내용 해석, 항목의 로컬 저장 등 여러 단계가 포함됩니다. 어느 단계에서든 실패할 수 있습니다. 먼저 오류 메시지 원문과 발생 시점을 기록하세요. 실패 메시지가 보인다고 기존 그룹을 바로 삭제하지 마세요. 이미 저장된 서버는 여전히 사용할 수 있을 수 있습니다. 그룹을 삭제하면 비교에 필요한 정보가 사라지고, 서버 측에서 반환한 오류가 해결되지 않을 수도 있습니다.

링크가 완전하고 올바른 출처의 정보인지 확인

본인의 서비스 제공자에게서 구독 주소를 다시 복사해 여러 번 전달되는 동안 텍스트가 잘리는 일을 방지하세요. 줄바꿈, 공백, 문장 끝의 구두점이 섞이지 않았는지 확인하고, 특히 쿼리 매개변수의 문자가 빠짐없이 포함되었는지 살펴보세요. 링크에 포함된 인증 매개변수는 민감한 정보입니다. 공개 스크린샷, 온라인 변환 페이지, 게시글에 올리지 마세요. 필드 구조만 확인할 때는 실제 주소 대신 예시 주소를 사용해 자격 증명이 불필요하게 공유되지 않도록 하세요.

계정 관리 페이지, 결제 내역 페이지, 로그인이 필요한 웹페이지가 아니라 구독 콘텐츠 주소인지 확인하세요. 브라우저에서 페이지가 열린다고 해서 앱에서 해석할 수 있는 서버 정보가 반환된다는 뜻은 아닙니다. 로그인 안내, 오류 메시지, 점검 페이지가 반환되면 앱은 보통 이를 서버 목록으로 가져올 수 없습니다. 이때는 프로토콜 필드를 계속 바꾸기보다 본인의 정보 출처에서 주소 유형을 확인하세요.

최초 가져오기와 정기 업데이트도 구분해서 판단하세요. 처음부터 실패했다면 주소, 응답 형식, 네트워크를 중점적으로 확인하세요. 이전에는 성공했지만 지금 실패한다면 구독 주소 변경, 인증 만료, 서버 측 콘텐츠 변경 여부도 살펴봐야 합니다. 로컬 그룹 이름만으로 주소가 같은지 판단하지 마세요. 그룹 이름은 그대로여도 실제 저장된 링크는 달라질 수 있습니다. 기록을 남기기 전에 전체 주소를 가리세요.

반복 가능한 업데이트 테스트 진행

현재 네트워크에서 먼저 수동 업데이트를 한 번 실행하고 결과가 분명해질 때까지 기다린 뒤 다음 조작을 하세요. 빠르게 여러 번 누르면 요청이 겹치거나 서버의 요청 제한이 적용될 수 있습니다. 일시적으로 요청할 수 없다는 메시지가 나오면 기존 항목을 유지하고 잠시 기다렸다가 한 번만 테스트하세요. 네트워크를 바꾸기 전에 연결 여부와 Global Routing 모드를 기록하세요. 업데이트 요청의 경로만 달라져 성공했을 수 있으므로 링크 내용이 해결된 것이라고 단정할 수 없습니다.

기존 연결이 구독 요청에 영향을 줄 수 있다면 기본 네트워크를 사용할 수 있는지 확인한 뒤 연결을 해제하고 다시 시도할 수 있습니다. 이미 작동하는 것으로 확인된 연결을 통해 비교 테스트를 할 수도 있습니다. 실제 요청 경로는 앱 내 관련 설정에 따라 달라지므로 기록을 기준으로 판단하세요. 모든 업데이트가 같은 경로를 이용한다고 가정하지 마세요. 특히 유일한 서버가 작동하지 않는데 업데이트 내용을 가져오려면 그 서버가 필요한 순환 의존이 생기지 않도록 주의하세요.

요청은 성공했지만 항목이 비어 있다면 응답에 유효한 서버 정보가 포함되어 있는지, 앱이 해당 형식을 지원하는지 확인하세요. 일부 항목만 나타났다면 누락된 항목의 프로토콜과 필드를 비교하세요. 기존 정보를 모두 바로 덮어쓰지 마세요. 본인의 정보 출처에서 단일 서버 정보를 얻을 수 있다면 한 항목을 직접 추가해 연결을 확인하세요. 이를 통해 서버 자체의 문제와 일괄 콘텐츠 해석 문제를 구분할 수 있습니다.

업데이트 후 선택된 항목과 로컬 수정 사항 확인

구독 업데이트가 완료되면 Home에서 기본 서버를 다시 확인하세요. 선택되어 있던 항목이 교체되거나 이름이 바뀌거나 삭제되면 현재 선택이 이전과 같은 접속 지점을 가리키지 않을 수 있습니다. 업데이트된 항목을 열어 주요 필드를 확인한 뒤 Connectivity Test와 실제 요청을 실행하세요. 목록의 항목 수가 정상이라는 것은 콘텐츠가 가져와졌다는 뜻일 뿐, 인증이 유효하거나 서버에 연결할 수 있거나 현재 규칙이 해당 항목을 선택한다는 보장은 없습니다.

구독에 포함된 서버 정보와 Config의 규칙 파일은 구분해야 합니다. Subscribe를 새로 고쳐도 Config의 규칙 순서가 반드시 수정되는 것은 아니며 Config를 다시 불러와도 만료된 구독이 복구되지는 않습니다. 구독 항목을 직접 수정했다면 업데이트 후 상위 콘텐츠와 다시 동기화될 수 있습니다. 계속 유지할 사용자 지정 설정은 저장 위치와 업데이트 동작을 먼저 확인한 뒤 관리 방법을 정하세요. 오류가 발생할 때마다 기억에 의존해 다시 입력하지 마세요.

복구할 때는 가능한 한 범위를 좁혀 확인하세요. 기존 그룹을 유지하면서 새 주소의 콘텐츠와 서버 하나를 검증한 뒤 문제가 없으면 중복 항목을 정리하세요. 삭제하기 전에 규칙이나 정책에서 해당 이름을 참조하는지 확인하세요. 가져오기 과정의 기본 조작은 시작하기를, 앱 구매와 기존 정보의 차이는 자주 묻는 질문을 참고하세요. 이 페이지는 사용자가 이미 보유한 정보를 처리하는 방법만 다루며 구독 출처를 추천하지 않습니다.

속도 저하와 잦은 끊김: 발생 단계별로 확인

먼저 어떤 상황에서 느린지 구체적으로 적으세요. 누른 뒤 응답이 오래 없는지, 첫 화면은 표시되지만 이미지가 늦게 뜨는지, 재생 중 끊기는지, 큰 데이터를 받다가 멈추는지에 따라 확인할 사항이 다릅니다. 지연 시간 테스트가 짧다고 지속 전송 속도가 빠른 것은 아닙니다. 웹페이지 한 번이 느리게 열린 것은 해당 서버의 응답이 느린 탓일 수도 있습니다. 먼저 같은 대상을 정해 반복 테스트한 뒤 모든 요청에 영향을 주는 일반적인 문제인지 판단하세요.

주소 확인·연결·데이터 전송을 분리해 확인

첫 방문은 느리지만 바로 다시 열었을 때 빨라지는 것은 DNS 캐시, 연결 재사용, 대상 서비스의 캐시 때문일 수 있습니다. 이것만으로 프록시 속도를 판단할 수는 없습니다. 서로 다른 서비스의 일반 웹페이지 두 개를 선택해 각각 처음 열었을 때와 다시 열었을 때의 결과를 기록하세요. 같은 네트워크와 서버를 유지하고 매회 연결을 다시 했는지도 적으세요. 비교 조건이 분명할수록 지연이 연결 전인지 데이터 전송을 시작한 뒤인지 판단하기 쉽습니다.

페이지 제목은 빠르게 표시되는데 이미지나 미디어가 계속 로딩된다면 관련 리소스가 다른 정책을 이용하는지 확인하세요. 웹페이지의 기본 도메인과 리소스 도메인이 서로 다른 경로를 사용할 수 있습니다. 기본 도메인에 규칙을 추가했다고 모든 콘텐츠가 프록시를 이용하는 것은 아닙니다. 먼저 실패한 리소스의 요청 경로를 살펴본 뒤 필요한 범위만 수정하세요. 경로가 같은 것을 확인한 다음 서버와 현재 네트워크의 지속적인 전송 성능을 비교하세요.

사진 동기화, 대용량 파일 업로드, 그 밖에 네트워크를 계속 사용하는 작업을 잠시 중지하세요. 업로드 대역폭이 가득 차면 일반 웹페이지도 응답이 느려질 수 있습니다. 이때 서버를 계속 바꿔도 기기 내부의 네트워크 경쟁은 해결되지 않습니다. 먼저 기기 하나와 작업 하나만으로 확인한 뒤 다른 작업을 하나씩 다시 시작하세요. 여러 성능 테스트를 동시에 실행하지 마세요. 서로 대역폭을 사용해 결과를 해석하기 어려워집니다.

네트워크 전환과 전송 조건 확인

Wi-Fi 신호가 강하다고 외부 연결까지 안정적이라는 뜻은 아닙니다. 기기 위치를 유지한 채 현재 네트워크에서 확인한 다음 이미 사용할 수 있는 다른 네트워크와 비교하세요. 특정 장소나 Wi-Fi에서만 끊긴다면 해당 네트워크의 접속 품질, 인증 상태, 다른 기기의 사용량을 확인하세요. 이동 중 Wi-Fi와 셀룰러 네트워크를 반복해 전환하면 기존 연결이 중단되고 다시 만들어질 수 있습니다. 정지 상태 테스트와 이동 중 테스트를 나누어 기록하세요.

특정 네트워크에서 일부 프로토콜만 문제를 일으킨다면 해당 프로토콜이 요구하는 전송 조건을 확인하세요. UDP를 사용하는 프로토콜은 현재 네트워크에서 실제로 지원되는지 확인해야 합니다. 다른 테스트에서 응답이 왔다고 모든 전송 방식이 사용 가능하다는 뜻은 아닙니다. 본인이 보유하고 매개변수가 완전한 구성을 사용해 비교하세요. 테스트를 위해 포트, 인증 정보, 전송 방식을 추측하지 마세요. 같은 네트워크에서 프로토콜만 바꿔 비교할 때도 실제로 서로 다른 서버를 사용했는지 기록해야 합니다.

작은 요청은 정상인데 큰 요청이 반복해서 멈춘다면 주소, 규칙, DNS, 인증을 확인한 뒤 경로와 MTU 관련 문제를 살펴볼 수 있습니다. MTU는 모든 상황에 적용되는 속도 향상 스위치가 아닙니다. 너무 작으면 오버헤드가 늘고, 너무 크면 일부 경로에서 단편화나 패킷 처리 문제가 발생할 수 있습니다. 사용 중인 프로토콜과 설정이 해당 항목을 명확히 지원할 때만 기존 값을 기록하고 관련 자료에 따라 변수를 하나씩 바꿔 테스트하세요. 전송 필드를 여러 개 동시에 수정하지 마세요.

제한된 테스트로 실행 가능한 결론 도출

서버를 비교할 때는 네트워크, 대상, 요청 유형, 대략적인 테스트 시간을 동일하게 유지하세요. 서버마다 연결되는 지역이나 서비스 진입점이 다르면 결과를 그대로 비교하기 어렵습니다. 가장 낮아 보이는 수치를 찾는 것이 목적이 아니라 본인이 보유한 구성이 실제 요청을 안정적으로 처리하는지 확인하는 것이 목적입니다. 짧은 시간에 서버를 계속 바꾸면 연결 재사용 조건이 달라져 기존 문제가 지속적인 끊김인지 판단하기 어려워집니다.

같은 조건에서 다른 대상은 정상인데 한 대상만 느리다면 먼저 대상 서비스와 리소스 경로를 확인하세요. 모든 대상이 느리다면 로컬 네트워크와 선택한 서버를 다시 점검하세요. 기존 서비스에는 자체 상태, 사용량, 동시 연결 제한이 있을 수 있으므로 본인의 서비스 정보를 확인하세요. 클라이언트 화면만 보고 추측하지 마세요. 앱의 일회성 구매와 서버 측 전송 조건은 별개의 문제입니다. 구매 상태가 정상이라고 원격 연결 경로가 항상 동일한 것은 아닙니다.

테스트를 마친 뒤 임시 모드, 테스트 규칙, 전송 매개변수를 원래대로 되돌리고 근거가 확인된 수정만 유지하세요. 유용한 기록에는 ‘어떤 조건에서 느렸는지, 어떤 비교에서 회복했는지, 무엇을 바꿨는지’가 드러나야 합니다. 네트워크와 대상 정보 없이 테스트 결과만 적으면 나중에 다시 확인하기 어렵습니다. 첫 연결도 아직 확인되지 않았다면 성능을 조정하기 전에 첫 연결 확인 방법을 살펴보세요.

DNS 문제: 응답 결과와 요청 경로부터 확인

DNS는 도메인을 후속 연결에 필요한 주소로 변환합니다. 도메인 접속 실패는 DNS 문제일 수 있지만, 인증서 오류, 연결 거부, 대상의 비정상 응답은 주소 확인이 성공한 뒤에도 발생할 수 있습니다. 오류 메시지와 기록에 주소 확인 실패가 있는지 먼저 살펴본 다음 DNS 설정을 바꾸세요. 특정 IP가 응답한다고 도메인 확인에 반드시 문제가 있다는 뜻은 아닙니다. IP에 직접 접속하면 대상 호스트 이름이 빠지거나 다른 인증서 또는 전혀 다른 서비스에 연결될 수 있습니다.

기본 네트워크와 설정 출처 확인

먼저 연결을 해제한 상태에서 일반 도메인을 테스트한 다음 현재 구성에서 같은 대상을 테스트하세요. 기본 네트워크에서도 주소 확인이 되지 않는다면 Wi-Fi 인증, 네트워크 접속 상태, 시스템에 이미 설정된 DNS를 확인하세요. 기본 네트워크는 정상이지만 연결 후 실패한다면 현재 Config와 앱의 DNS 설정을 집중적으로 살펴보세요. 구성 파일에서 가져온 설정과 나중에 직접 추가한 설정을 구분해 기록하세요. 한 곳만 수정해도 다른 설정의 영향을 받을 수 있습니다.

입력한 DNS 주소 형식이 선택한 방식과 맞는지 확인하세요. 일반 서버 주소와 암호화된 DNS 엔드포인트는 서로 바꿔 쓸 수 있는 문자열이 아닙니다. 설정에서 전체 엔드포인트를 요구한다면 도메인만 입력했을 때 필요한 경로가 빠질 수 있고, 주소만 받는 필드에 전체 URL을 넣어도 실패합니다. 여러 예시의 일부를 조합해 새 주소를 만들지 말고 현재 화면 안내와 본인의 설정 자료를 따르세요.

암호화된 DNS도 네트워크 연결이 필요합니다. 엔드포인트에 도메인을 사용하면 먼저 해당 엔드포인트의 주소를 찾는 방법도 고려해야 합니다. DNS 요청이 프록시에 의존하고 프록시 서버 주소는 같은 DNS 경로로 찾아야 한다면 연결 시작 단계에서 의존성이 순환할 수 있습니다. 문제를 확인할 때 ‘먼저 어떤 주소를 찾는지, 요청은 어디로 가는지, 해당 경로를 이미 사용할 수 있는지’를 분명히 하세요. DNS 서버 주소를 계속 추가해도 목록만 길어질 뿐 의존성 문제는 해결되지 않을 수 있습니다.

도메인 규칙과 IP 주소 규칙의 관계 이해

도메인 규칙은 대상 이름으로 판단하고 IP 규칙은 주소 범위로 판단합니다. IP 주소를 기준으로 판단할 때는 DNS 확인이 먼저 필요할 수 있습니다. 규칙을 확인할 때 요청에 포함된 정보, DNS 결과, 최종 정책을 함께 살펴보세요. GEOIP를 파일의 특정 위치에 두면 모든 도메인 규칙을 대신할 수 있다고 생각하지 마세요. 규칙 순서는 여전히 중요합니다. 앞에서 너무 일찍 매칭된 항목은 뒤쪽 규칙이 같은 요청을 처리하지 못하게 할 수 있습니다.

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

이 조각은 도메인 규칙, 지리적 IP 규칙, 기본 처리의 순서만 보여줍니다. 모든 네트워크에 적합한 완성된 구성은 아닙니다. GEOIP 판단은 사용하는 데이터와 실제로 확인된 주소에 영향을 받으며, 웹사이트 콘텐츠나 계정의 소재를 판단하지 않습니다. 수정 전에 원본 파일을 저장하고 PROXY가 사용하는 서버를 확인하세요. 도메인 하나에만 예외가 필요하다면 범위가 명확한 규칙을 우선 사용하세요. 해당 도메인 때문에 모든 요청의 기본 경로를 바꾸지 마세요.

같은 도메인에서도 여러 주소가 반환되거나 IPv4와 IPv6 결과가 함께 나올 수 있습니다. 일부 네트워크나 대상에서만 실패한다면 현재 네트워크가 해당 주소 체계로 실제 접속할 수 있는지, 실패한 연결이 어떤 주소를 사용했는지 확인하세요. IPv6를 끄는 것을 정답으로 고정하지 마세요. 기록을 남긴 임시 비교 테스트에만 사용하고, 테스트가 끝나면 실제 네트워크 지원 여부에 따라 기존 설정을 유지할지 결정하세요.

캐시를 지운 뒤 새 요청으로 확인

DNS 설정을 바꾼 뒤에도 이전 캐시와 이미 만들어진 연결이 테스트에 영향을 줄 수 있습니다. 먼저 앱에서 제공하는 캐시 삭제 기능을 사용하세요. 해당 메뉴가 없다면 연결을 중지했다가 다시 만들고, 대상 앱도 완전히 종료한 뒤 다시 여세요. 도메인 하나의 상태를 지우려고 앱 데이터를 모두 삭제하지 마세요. 테스트할 때마다 실패한 요청을 새로 보내야 합니다. 화면에 계속 표시된 이전 오류 페이지만 확인하지 마세요.

웹페이지의 일부 리소스만 실패한다면 기본 도메인, 리소스 도메인, 인증 도메인을 나누어 살펴보세요. 각 도메인은 서로 다른 DNS 결과와 규칙을 이용할 수 있으므로 한 도메인이 복구되어도 페이지 전체 경로가 정상이라는 뜻은 아닙니다. 앱에서 별도의 DNS 방식을 사용한다면 일반적인 시스템 요청과 다른 결과가 나타날 수도 있습니다. 관찰 가능한 기록을 기준으로 원인을 확인하세요. DNS 설정 하나만 바꿔 모든 앱의 주소 확인 방식이 달라진다고 보장할 수는 없습니다.

이 장의 점검은 대상 도메인에서 사용할 수 있는 결과를 얻고, 후속 연결이 예상한 경로를 사용하며, 연결을 다시 만든 뒤에도 성공할 때 완료됩니다. 주소 확인은 성공했지만 핸드셰이크에 실패한다면 프로토콜 장으로 돌아가세요. Config에서만 실패한다면 규칙 장을 확인하세요. 최종적으로 사용한 DNS 방식과 변경 이유를 기록해 두면 네트워크를 바꿨을 때 환경 변화인지 설정에 다시 생긴 의존성 문제인지 판단하기 쉽습니다.

배터리 소모와 업데이트 후 오류: 비교 기준부터 복구

배터리 소모와 업데이트 문제를 확인하려면 전후 조건이 비교 가능해야 합니다. 문제가 시작되기 전에 무엇이 바뀌었는지 기록하세요. 앱 업데이트, 시스템 업데이트, 구독 새로 고침, Config 수정, 네트워크 변경, 자동 연결 조건 추가 중 어느 것이 있었는지 확인합니다. 같은 날 여러 변화가 있었다고 특정 변화가 원인이라고 단정할 수는 없습니다. 현재 상태와 백업을 먼저 보존하고 앱을 바로 삭제하지 마세요. 로컬 정보가 사라질 수 있고 비교에 쓸 원래 조건도 잃게 됩니다.

백그라운드 전송과 연결 재시도 구분

시스템의 배터리 사용 통계에서 해당 시간대를 확인하고 화면 사용, 미디어 재생, 파일 동기화, 네트워크 전환 상황을 함께 기록하세요. VPN 앱은 기기의 네트워크 처리에 관여하므로 통계에 나타난 사용량을 모두 앱이 직접 발생시킨 트래픽으로 단순 해석할 수 없습니다. 다른 앱에서 업로드나 다운로드가 계속되면 네트워크 처리도 이어집니다. 비교하기 전에 대용량 작업을 멈추고 비슷한 화면 사용량과 네트워크 조건에서 확인하세요. 사용 환경이 전혀 다른 두 상황을 비교하지 마세요.

시간 초과와 자동 재연결이 반복되면 네트워크 활동이 증가할 수 있습니다. 특정 서버만 작동하지 않는지, 신호가 약한 곳에서 기기가 네트워크를 계속 전환하는지 확인하세요. 본인이 보유하고 이미 작동을 확인한 구성으로 바꾼 뒤 재시도가 줄어드는지 살펴보세요. 연결이 안정된 뒤 배터리 사용도 나아졌다면 실패한 항목을 더 점검하세요. 실패한 서버를 그대로 두고 다른 스위치로 문제를 가리려 하지 마세요. 배터리 잔량만 기록하기보다 재시도와 네트워크 변화가 발생한 시간을 함께 남기는 편이 유용합니다.

On Demand를 잠시 끄고 수동 연결 상태 유지와 수동 연결 해제가 안정적인지 확인하세요. 자동 조건이 너무 자주 실행되면 연결, 해제, 재시도가 반복될 수 있습니다. 문제 해결 후에는 조건을 하나씩 복원하고 한꺼번에 모두 켜지 마세요. 지속적인 진단 기록이나 잦은 수동 테스트를 사용 중이라면 필요한 정보를 얻은 뒤 중지하세요. 진단 작업 자체가 네트워크 활동을 늘릴 수 있으므로 부하를 계속 만들면서 대기 상태의 배터리 사용량을 평가하지 마세요.

업데이트 후 유지된 설정부터 확인

앱 업데이트 후에는 Home의 선택 항목, Global Routing, 현재 Config, On Demand 조건을 확인한 다음 연결을 다시 만드세요. 목록에 항목이 있다고 기본 선택이 유지되었다는 뜻은 아닙니다. 파일 이름이 같아도 활성화 상태는 다를 수 있습니다. 업데이트 전 기록을 기준으로 비교 환경을 복구한 뒤 확인된 서버 하나와 일반 대상 하나로 테스트하세요. 정상 작동하면 사용자 지정 규칙과 다른 설정을 하나씩 복원하세요. 모든 문제를 업데이트 탓으로 바로 돌리지 마세요.

같은 시기에 구독도 업데이트했다면 서버 정보가 바뀌었는지 확인하세요. 시스템도 업데이트했다면 VPN 권한과 다른 네트워크 구성의 상태를 다시 살펴보세요. 발생 시점이 가깝다는 사실은 단서일 뿐 원인을 입증하지는 않습니다. 기존 연결이 새로 만들어지지 않아 문제가 생겼다면 정상적으로 연결을 해제했다가 다시 연결하고 대상 앱을 다시 열어 확인할 수 있습니다. 시스템 상태가 계속 일치하지 않을 때는 스위치 장의 절차를 따르세요. 모든 구성을 바로 다시 만들지 마세요.

앱 업데이트는 App Store에서만 진행하세요. 앱을 확인할 때는 개발자 Shadow Launch Technology Limited, 공식 아이콘, 앱 ID 932747118을 기준으로 삼으세요. 시스템 요구 사항은 App Store 페이지 표기를 따릅니다. 재설치가 필요하다면 먼저 구입 항목 복원 안내를 읽어보세요. 구매 기록은 앱을 다시 받을 수 있는 권리를 복원하는 데 사용되며 로컬 서버, 규칙 파일, 사용자 지정 매개변수의 전체 백업을 의미하지는 않습니다.

백업·복원·오류 기록

백업할 때는 Config, 서버 정보, 보존할 다른 설정을 각각 확인하세요. 규칙 파일 하나만 내보내고 모든 정보가 저장되었다고 생각해서는 안 됩니다. 백업 파일을 열어 읽을 수 있는지 확인하고 각 파일의 용도와 복원 방법을 파악해 두세요. 인증 정보가 포함된 파일은 접근이 통제되는 위치에 보관하고 공개 공유 폴더에 두지 마세요. iCloud를 사용하는 경우 동기화 스위치가 켜져 있다는 이유만으로 기기의 원본을 삭제하지 말고 실제 동기화가 완료되었는지 확인하세요.

재설치가 꼭 필요하다면 먼저 백업과 구매 계정을 확인한 뒤 App Store의 구매 및 기기 호환성 안내에 따라 복원하세요. 처음에는 작동에 필요한 최소한의 자료만 가져오고 연결을 확인한 뒤 다른 구성을 단계적으로 복원하세요. 특정 파일을 복원한 직후 문제가 다시 발생한다면 그 파일과 의존 항목을 다음 점검 대상으로 삼으세요. 자세한 이전 순서는 Config 백업 및 새 기기에서 복원을 참고하세요.

문제가 계속 재현된다면 조작 순서, 현재 네트워크, 실패 단계, 특정 프로토콜에만 영향을 주는지, 비교 테스트 중 성공한 항목을 정리하세요. 기록을 제출할 때 구독 링크, 인증 값, 개인 요청 내용을 가리세요. 배터리 문제는 실제 사용 부하를 설명하고, 업데이트 문제는 함께 변경된 설정을 적으세요. 정상으로 돌아오면 임시 진단을 중지하고 검증된 백업을 보관해 다음 환경 변화 때 돌아갈 기준을 마련하세요.

iPad 문제: 계정·네트워크·설정 차이 분리

iPhone은 정상인데 iPad에서 문제가 생겨도 기기 모델을 바로 원인으로 지목하지 마세요. 두 기기는 네트워크, 구매 계정, 기본 서버, Config, DNS 설정이 서로 다를 수 있습니다. 먼저 확인할 대상이 앱을 받을 권리인지, 앱 실행인지, 연결 설정인지, 실제 접속인지 구분하세요. 한 번에 한 단계만 비교하고 정상 작동하는 기기를 기준으로 삼으세요. 백업 없이 다른 기기의 기존 전용 설정을 덮어쓰지 마세요.

앱을 받을 수 있는지와 권한 상태부터 확인

iPad에서도 App Store를 통해 앱을 받습니다. 이미 구매했다면 현재 App Store 구매에 사용하는 Apple ID가 기존 구매 기록과 일치하는지 확인한 뒤 구입 항목의 상태를 살펴보세요. 기기에 로그인한 iCloud 계정과 App Store 구매 계정은 서로 다를 수 있으므로 실제 구매 기록을 기준으로 판단해야 합니다. 시스템 요구 사항, 구매 적용 여부, 가족 공유 조건은 App Store 페이지 표기를 따르세요. 다른 기기에서 설치된다는 이유만으로 iPad에서도 가능하다고 추정하지 마세요.

앱을 정상적으로 받을 수 있다면 iPad의 VPN 권한도 확인하세요. 다른 기기에서 이미 권한을 승인했다고 해서 이 기기도 구성 추가를 허용한 것은 아닙니다. 처음 연결할 때 시스템 메시지를 확인하고 기기 인증을 완료하세요. 관리되는 iPad라면 조직 정책에서 해당 네트워크 구성을 허용하는지도 확인해야 합니다. 스위치가 유지되지 않는 문제는 첫 장의 절차를 따르세요. 구입 항목 복원으로 시스템 권한을 대체할 수 없으며 권한 문제를 구독 형식 문제로 오해해서도 안 됩니다.

창 크기, 화면 방향, 시스템 표시 방식에 따라 앱 화면이 달라질 수 있습니다. Home, Config, Settings를 확인할 때는 실제로 열린 페이지와 현재 선택된 항목을 먼저 확인하세요. 다른 기기의 버튼 위치를 그대로 기준 삼지 마세요. 수정 후 목록으로 돌아갔다가 다시 열어 저장되었는지 확인하세요. Split View에서는 확인하지 않은 편집 내용이 제출되지 않고 화면에 남아 있는지 특히 주의하세요.

두 기기를 최소 조건으로 비교

두 기기를 같은 Wi-Fi에 연결하고 이미 사용할 수 있는 동일 서버, 같은 Global Routing 설정, 같은 웹페이지를 사용해 확인하세요. 한 기기는 셀룰러 네트워크, 다른 기기는 Wi-Fi에 연결된 상태에서 결과를 바로 비교하지 마세요. 네트워크 이름이 같더라도 두 기기 모두 웹 인증이 필요한지 확인해야 합니다. 연결을 해제한 상태에서도 iPad의 기본 네트워크에 문제가 있다면 앱 문제를 살펴보기 전에 네트워크 접속부터 해결하세요.

iPad에서 개인용 핫스팟을 사용한다면 핫스팟을 제공하는 기기의 현재 네트워크와 연결 상태도 확인하고 iPad에서 일반 웹페이지를 열어 기본 접속을 테스트하세요. 핫스팟은 네트워크에 접속할 수 있게 해 주는 기능일 뿐, 제공 기기의 모든 규칙과 연결 설정이 iPad에 적용된다는 뜻은 아닙니다. iPad에서 실제로 만들어진 연결과 요청 기록을 기준으로 판단하세요. 제공 기기의 상태 아이콘만 보고 iPad 트래픽의 경로를 추측하지 마세요.

Type, Address, Port, 인증 필드, TLS 관련 필드를 하나씩 비교한 다음 현재 Config와 DNS 설정을 비교하세요. 동기화가 완료된 것과 연결 성공은 서로 다른 문제입니다. 두 기기에 파일이 있다고 실제로 같은 파일이 활성화되었다는 뜻은 아닙니다. 서버 이름은 같지만 내용이 다르면 각 필드의 값을 비교하세요. 내용이 같은데 결과가 다르면 시스템 네트워크 구성, 주소 체계별 접속 가능 여부, 현재 네트워크 조건을 계속 확인하세요.

백그라운드·잠자기·복귀 후 연결 확인

잠금 화면을 켠 뒤나 기기를 깨운 뒤에만 문제가 발생한다면 전후의 Wi-Fi 상태, 네트워크 전환 여부, On Demand 실행 여부를 기록하세요. 먼저 고정된 네트워크에서 수동 연결로 재현한 다음 화면 잠금과 깨우기를 추가해 보세요. 앱 화면에서 상태 변화가 계속 표시되지 않는다고 터널이 중단되었다고 단정하지 마세요. 실제 요청과 시스템 상태를 함께 확인해야 합니다. 반대로 시스템에 연결로 표시되어도 잠자기 전에 만들어진 원격 연결이 모두 유효하다는 보장은 없습니다.

기기를 깨운 뒤 첫 요청만 실패하고 다시 연결한 뒤 정상으로 돌아온다면 이전 연결이 제때 다시 만들어지지 않았거나 현재 네트워크가 바뀌었는지 확인하세요. 먼저 대상 앱을 완전히 종료했다가 다시 열고, 그다음 연결을 해제했다가 다시 만들어 어느 단계에서 복구되는지 기록하세요. 수동 절차가 안정적으로 작동한 뒤에만 On Demand 조건을 조정하세요. 자동 재연결을 계속 켜 두는 것으로 문제를 대신하지 마세요. 약한 신호, 만료된 인증, 특정 서버의 지속적인 실패를 가릴 수 있습니다.

구성을 이전한 뒤 Connectivity Test를 다시 실행하고 실제 웹페이지 접속도 확인한 다음 자주 사용하는 앱을 테스트하세요. 안정적인 것을 확인했다면 이 iPad의 검증된 백업을 보관하세요. 모든 기기의 설정을 글자 그대로 똑같이 맞출 필요는 없습니다. 네트워크 환경에 따라 근거 있는 조정이 필요할 수 있습니다. 앱을 받는 방법을 다시 확인하려면 iPad에서 앱 받기 안내를, 처음부터 연결하려면 시작하기에서 기본 절차를 따라가세요.