공식 가이드 · 문제 진단

Shadowrocket 문제 해결 가이드

먼저 문제가 발생한 단계를 확인한 다음 해당 설정을 점검하세요. 이 페이지에서는 증상별로 확인하는 절차를 안내합니다. 아직 첫 연결을 완료하지 않았다면 빠른 시작 가이드를 따라 진행한 뒤, 확인한 결과를 바탕으로 해당 항목을 살펴보세요. 아래 내용은 이미 본인의 구독 정보나 서버 정보를 보유한 경우를 전제로 하며, 서버나 구독을 제공·판매·추천하지 않습니다.

iPhone / iPad에 적용됩니다. 시스템 요구 사항은 App Store 페이지를 기준으로 확인하세요. 화면에 표시되는 용어는 영어로 유지했으며, 메뉴 위치와 사용 가능한 옵션은 기기에 실제로 표시되는 내용을 따릅니다. 이 페이지의 테스트 결과는 문제 범위를 좁히기 위한 것으로, 연결 경로의 사용 가능성을 보장하지 않습니다.

[General]

연결 스위치가 켜지지 않거나 바로 꺼지거나 반복해서 연결됨

시스템 권한 문제와 서버 문제를 먼저 구분하세요

Home에서 연결 스위치를 켰을 때 시스템에서 VPN 구성을 추가할지 묻는다면 안내를 읽고 본인의 의사에 따라 허용한 뒤 기기 인증을 완료하세요. 이 과정은 연결에 필요한 구성을 시스템에 추가하는 절차이며, 구매 확인이나 구독 가져오기가 아닙니다. 이전에 안내를 취소했다면 앱으로 돌아가 연결을 다시 시도하세요. 기기가 관리 대상이라면 시스템에서 VPN 추가를 제한할 수 있습니다. 이 경우 서버 주소를 반복해서 바꾸지 말고 기기 관리 담당자에게 확인하세요.

스위치가 실제로 어떻게 작동하는지 살펴보세요. 연결 상태로 전환되지 않으면 권한과 기기 제한을 먼저 확인합니다. 잠시 연결 상태가 되었다가 꺼지면 설정 내용, 네트워크 연결 가능 여부 또는 연결 과정의 오류일 수 있습니다. 연결이 유지되지만 웹페이지를 열 수 없다면 다음 장으로 이동하세요. 시스템 상태 막대의 표시는 연결 상태 일부만 보여 줄 뿐, 요청이 대상 서버에 도달했다는 뜻은 아닙니다. 막연히 “안 돼요”라고 기록하기보다 현상을 구분해 두면 원인을 찾기 쉽습니다.

시스템 연결 상태와 자동 연결 조건 확인

시스템 Settings에서 VPN을 검색해 Shadowrocket에 해당하는 구성이 있는지, 다른 VPN 연결이 사용 중인지 확인하세요. 필요하지 않은 연결은 먼저 직접 끊은 다음 Home으로 돌아가 테스트합니다. 시스템 네트워크 구성을 모두 한꺼번에 삭제하지 마세요. 업무나 학교에서 사용하는 설정이 포함되어 있을 수 있습니다. VPN 항목을 편집할 수 없거나 관리 대상이라고 표시되거나, 구성 추가를 시스템에서 거부하면 Config를 계속 바꾸기보다 기기 관리 제한부터 확인하세요.

스위치를 껐는데 저절로 다시 켜진다면 On Demand가 활성화되어 있는지, 현재 네트워크가 해당 연결 조건에 맞는지 확인하세요. 수동 테스트의 기준을 세우려면 On Demand를 잠시 끄고 직접 연결을 제어합니다. 테스트가 끝나면 기록해 둔 원래 상태로 되돌리세요. 자동 연결 조건과 수동 스위치가 동시에 작동하면 연결이 반복해서 켜지는 현상이 반드시 앱 오류인 것은 아닙니다. 시스템에 자동 연결 조건이 따로 설정되어 있는지도 확인하세요.

변경을 최소화해 반복 가능한 테스트 진행

먼저 연결을 끊은 상태에서도 기기가 정상적으로 인터넷에 접속되는지 확인하세요. 웹 인증이 필요한 Wi-Fi라면 먼저 인증 페이지를 완료합니다. 그런 다음 Home으로 돌아가 설정이 완전한 기존 서버 하나를 직접 선택하고 연결을 시도하세요. 설정을 불러오는 중 오류가 표시되면 안내 내용과 현재 Config부터 확인하고, 스위치를 반복해서 눌러 오류를 덮으려 하지 마세요. 확인된 간소화 설정이 있다면 비교용으로 잠시 사용할 수 있지만, 원본 설정 파일은 보관하고 전환 전후의 이름과 Global Routing 상태를 기록하세요.

Wi-Fi에서만 실패한다면 셀룰러 네트워크 사용이 허용되어 있고 데이터 사용량에 유의할 수 있는 경우, 같은 서버로 다시 테스트하세요. 반대의 경우도 마찬가지입니다. 서버, 설정, 테스트 대상을 그대로 두고 네트워크만 바꿨을 때 결과가 달라진다면 접속 네트워크를 우선 점검하세요. 두 네트워크에서 같은 단계에 실패한다면 서버 설정과 서비스 상태를 확인합니다. 구독 업데이트, 설정 전환, 네트워크 변경을 동시에 하지 마세요. 문제가 해결되어도 어떤 조치가 효과가 있었는지 알 수 없습니다.

시스템 구성을 다시 만들 시점

위 항목을 모두 확인했는데도 연결되지 않으면 연결을 끊고 앱을 정상적으로 종료한 뒤 다시 실행하세요. 필요하다면 기기를 재시동한 후 다시 테스트합니다. 시스템 VPN 구성이 비정상임을 확인했고 백업과 복구 방법을 파악한 경우에만 Shadowrocket에 해당하는 구성을 제거한 뒤 앱에서 다시 추가를 요청하는 방법을 고려하세요. 시스템 구성을 제거해도 서버, 구독, 규칙이 반드시 백업되는 것은 아닙니다. 권한을 다시 설정하는 일을 구성 복원으로 착각하지 마세요. 재인증 후에도 Home에서 선택된 항목을 다시 확인해야 합니다.

[Rule]

연결됨으로 표시되지만 모든 요청 또는 일부 요청이 실패함

기본 네트워크부터 확인한 다음 요청 경로를 점검하세요

먼저 Shadowrocket 연결을 끊고 같은 기기와 네트워크에서 평소 접속할 수 있는 페이지를 여세요. 여전히 접속되지 않으면 Wi-Fi 인증, 셀룰러 네트워크 권한, 라우터 또는 접속 네트워크 문제부터 해결해야 합니다. 기본 네트워크가 복구된 뒤 연결을 켜야 접속 문제를 규칙 문제로 오인하지 않습니다. 특정 앱에서만 문제가 발생한다면 브라우저에서 다른 대상을 열어 비교하세요. 앱마다 세션 캐시, 도메인 목록 또는 연결 방식이 다를 수 있으므로 한 앱의 문제만으로 전체 네트워크가 작동하지 않는다고 판단하지 마세요.

Home으로 돌아가 목록에 사용 가능한 항목이 있는지만 보는 대신 현재 선택된 서버를 확인하세요. 목록을 업데이트한 뒤에는 기존 선택 항목이 달라졌을 수 있으며, 이름이 비슷해도 설정이 같다는 뜻은 아닙니다. 이어서 Global Routing을 확인하세요. Config는 Config에 해당하고 프록시는 Proxy, 직접 연결은 Direct에 해당합니다. 이 세 가지 상태는 주된 요청의 처리 방식을 결정하지만, 어느 하나도 모든 DNS, 시스템 동작 또는 대상 웹사이트 상태를 완전히 증명하지는 않습니다.

상태	점검 목적	결과 해석 시 유의점
설정 / Config	현재 Config에 따라 규칙과 정책을 확인합니다.	실제로 활성화된 Config와 규칙 적용 기록을 함께 확인해야 합니다.
프록시 / Proxy	Config와 비교해 서버 경로를 확인합니다.	정상 작동해도 기존 Config의 모든 규칙이 올바르다는 뜻은 아닙니다.
직접 연결 / Direct	프록시 서버를 거치지 않는 요청의 동작을 비교합니다.	VPN을 완전히 끄거나 모든 DNS 설정을 원래대로 되돌린다는 뜻은 아닙니다.

상태별 비교로 문제 범위 좁히기

같은 테스트 페이지와 서버를 사용하고 먼저 Config 상태의 결과를 기록한 다음 Proxy로 잠시 전환해 다시 시도하세요. Proxy에서는 접속되지만 Config에서는 안 된다면 바로 서버를 바꾸기보다 해당 요청에 적용된 규칙과 최종 정책을 먼저 확인합니다. 두 상태 모두 실패하면 서버 연결, DNS, 대상 자체의 상태를 점검하세요. 테스트 후에는 원래 상태로 되돌리고 페이지를 다시 여세요. 기존 연결이 계속 재사용될 수 있으므로 한 번 새로고침했다고 새 경로로 요청이 전송되었다고 단정할 수 없습니다.

Direct에서는 접속되지만 Proxy에서는 실패한다면 서버 경로를 우선 살펴볼 수 있습니다. 다만 도메인 해석 차이와 프로토콜 설정 오류도 확인해야 합니다. 같은 대상에 Direct와 Proxy 모두 접속할 수 없지만 다른 대상은 정상이라면 대상 웹사이트 문제일 수도 있고, 해당 대상의 공통 의존 서비스 문제일 수도 있습니다. 서로 독립적인 대상을 추가로 확인하세요. 같은 로그인 서비스나 리소스 도메인에 의존하는 여러 페이지를 독립적인 사례로 착각하지 마세요.

실제 적용된 규칙을 확인해 Config 점검

Config에서 예상한 파일이 현재 활성화되어 있는지 확인한 뒤 실패한 요청의 도메인, 적용된 규칙과 처리 정책을 살펴보세요. 규칙은 보통 순서대로 검사하므로 앞쪽 규칙이 일치하면 뒤쪽의 더 구체적인 규칙이 적용되지 않을 수 있습니다. 범위가 넓은 DOMAIN-KEYWORD, 큰 IP-CIDR 범위, 의도치 않게 REJECT로 지정된 항목을 특히 주의하세요. 다음 예시는 규칙 순서를 설명하기 위한 것으로, 사용할 수 있는 서버 정보는 포함하지 않습니다. 현재 사용 중인 전체 설정을 그대로 대체하는 용도로 사용해서는 안 됩니다.

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

이 순서에서는 api.example.com이 먼저 DOMAIN 규칙에 따라 DIRECT로 처리되고, example.com 접미사에 해당하는 다른 도메인은 이어서 PROXY에 매칭됩니다. LAN 주소와 GEOIP 항목은 서로 다른 매칭 유형을 보여 주며, FINAL은 앞선 규칙과 일치하지 않은 경우의 마지막 처리입니다. 실제 결과는 요청에서 확인할 수 있는 도메인 정보, 해석 결과, Config의 다른 내용에도 영향을 받습니다. 대상 이름만으로 특정 규칙이 반드시 적용된다고 판단하지 말고 현재 요청 기록을 근거로 확인하세요.

일부 페이지에서만 이미지가 보이지 않거나 로그인에 실패함

하나의 페이지도 여러 도메인을 사용할 수 있습니다. 첫 화면의 텍스트는 보이지만 이미지, 인증 또는 로그인이 실패한다면 첫 화면의 도메인에만 규칙을 추가하지 말고 실패한 리소스 요청을 각각 확인하세요. 먼저 REJECT 규칙이 적용되었는지 확인한 다음 관련 도메인에 서로 다른 정책이 적용되는지 살펴봅니다. 필요한 규칙만 확인된 요청에 추가해 다른 요청에 영향을 주는 과도하게 넓은 키워드는 피하세요. 규칙 용어의 의미를 모르겠다면 용어집을 확인하고, 첫 연결을 검증하려면 빠른 시작 가이드로 돌아가세요.

[General]

서버 시간 초과, 테스트 실패 및 프로토콜 설정 불일치

테스트 결과와 실제 접속 결과를 구분하세요

Connectivity Test 결과는 테스트 방식과 대상, 현재 네트워크, 서버 상태에 따라 달라집니다. 실패했다고 해서 모든 요청이 실패한다는 뜻은 아니며, 성공했다고 해서 모든 웹페이지나 전송 방식이 사용 가능하다는 뜻도 아닙니다. 먼저 선택된 항목을 확인한 다음 명확한 대상에 실제로 접속해 테스트 결과와 비교하세요. 테스트 대상 자체에 접속할 수 없다면 테스트는 실패해도 일부 서비스는 정상일 수 있습니다. 결과만 보고 서버 항목을 삭제하기보다 테스트 설정을 먼저 확인하세요.

연결 시간 초과, 연결 거부, 인증 실패, 인증서 관련 안내를 구분하세요. 시간 초과는 정해진 대기 시간 안에 필요한 응답을 받지 못했다는 뜻이지만, 이것만으로 서버가 오프라인인지, 포트에 연결할 수 없는지, 도메인 해석이 잘못됐는지, 중간 네트워크에서 패킷이 손실됐는지 알 수는 없습니다. 연결 거부와 인증 실패는 서로 다른 단서를 제공합니다. 원래 표시된 오류 문구를 기록하세요. 자세한 오류가 화면에 없다면 즉시 실패했는지, 잠시 기다린 뒤 실패했는지도 기록해 비교에 활용할 수 있습니다.

공통 항목부터 확인한 뒤 프로토콜별 항목을 점검하세요

해당 항목의 편집 화면이나 Add Server를 열고 기존 서비스 제공업체가 전달한 원본 정보와 비교해 유형, Address, Port부터 확인하세요. 주소 필드에 불필요한 경로, 앞뒤 공백, 다른 프로토콜 링크 내용이 들어가면 안 됩니다. 포트는 해당 서비스에 지정된 값이어야 합니다. 서버 표시 이름은 구분용일 뿐이며 이름을 바꿔도 주소나 인증 문제는 해결되지 않습니다. 자동으로 가져온 항목도 가져온 뒤 필드를 확인하세요. 스캔이나 구독 가져오기에 성공했다고 해서 설정 조합까지 반드시 정상인 것은 아닙니다.

프로토콜	중점 확인 항목	흔한 오해
Shadowsocks	Address, Port, Password, Method.	Password가 맞더라도 Method가 일치하지 않으면 실패할 수 있습니다.
VMess / VLESS	UUID, 전송 방식, TLS 및 서버에서 요구하는 추가 필드.	다른 항목의 전송 설정을 그대로 사용해도 전체 설정이 맞는 것은 아닙니다.
Trojan	인증 정보, TLS, 서버 이름 및 전송 설정.	연결 주소와 인증서 검증용 이름을 같은 값으로 취급하는 것.
Hysteria2	인증 정보, TLS 및 현재 네트워크에서 UDP에 연결할 수 있는지 여부.	일반 웹페이지에 접속된다고 관련 UDP 경로도 사용 가능하다는 뜻은 아닙니다.

UUID, Password, Method, Host, Path, 서버 이름 등의 값은 모두 하나의 유효한 설정에서 가져와야 합니다. 서로 다른 항목의 값을 조합하지 마세요. 일부 전송 방식에는 지정된 경로나 호스트 이름이 필요하며, 이 값들은 임의의 메모가 아닙니다. 대소문자, 슬래시, TLS 사용 여부도 연결에 영향을 줄 수 있습니다. VMess와 VLESS 필드의 차이는 프로토콜 필드 비교 가이드를 참고하되, 최종적으로는 기존 서버의 설정 요구 사항을 따르세요.

인증서와 시간 오류를 우회하지 마세요

TLS 관련 오류가 발생하면 먼저 기기의 날짜와 시간이 정확한지 확인한 다음 서버 이름이 인증서와 일치하는지 살펴보세요. 연결 주소, TLS 검증용 이름, 전송 계층의 Host는 서로 다른 역할을 할 수 있으므로 모든 필드를 같은 값으로 바꾸지 마세요. 인증서가 만료됐거나 이름이 일치하지 않으면 기존 서비스 제공업체에 서버 상태를 확인해야 합니다. 인증서 검증을 끄면 보안 범위가 달라지므로 일반적인 해결 방법으로 사용해서는 안 되며, 그렇게 했다고 기존 설정이 올바르다는 뜻도 아닙니다.

테스트를 반복하기보다 네트워크와 항목을 교차 확인하세요

같은 항목을 그대로 둔 채 사용 가능한 두 네트워크에서 각각 한 번씩 테스트하세요. 그런 다음 같은 네트워크에서 설정이 확인된 다른 기존 항목을 비교합니다. 모든 항목이 한 네트워크에서만 실패하면 해당 네트워크의 전송 제한이나 품질을 우선 확인하세요. 한 항목만 여러 네트워크에서 실패하면 해당 항목의 설정과 서비스 상태를 먼저 점검합니다. UDP를 사용하는 프로토콜은 해당 네트워크의 조건도 따로 확인해야 합니다. 일반 웹페이지가 열린다고 전송 경로까지 정상이라고 볼 수는 없습니다.

기존 서비스 제공업체에 문의할 때는 프로토콜 유형, 실패 단계, 네트워크 종류, 민감 정보를 가린 오류 문구만 전달하세요. 전체 구독 정보, UUID, 비밀번호, QR 코드, 인증 정보가 포함된 링크는 공개하지 마세요. 구독 업데이트 후 문제가 시작됐다면 먼저 변경된 필드를 비교한 다음 기존 항목 복원이나 서버 측 조치를 결정하세요. 테스트에서 일관된 결과를 얻었다면 잦은 재시도를 멈추고 재현 가능한 사례를 보관하세요. 반복 테스트만으로 원격 인증이나 포트 설정이 수정되지는 않습니다.

[General]

구독 가져오기 실패, 업데이트 결과 없음, 중복 서버

구독 주소, 서버 링크, Config를 구분하세요

구독은 보통 서버 항목을 가져오거나 업데이트하는 데 사용하고, Config는 규칙과 관련 설정에 사용합니다. 모두 텍스트라는 이유로 같은 가져오기 메뉴를 사용할 수는 없습니다. 먼저 보유한 정보가 구독 주소, 단일 서버 링크, QR 코드, 설정 파일 중 무엇인지 확인한 다음 앱에서 해당 형식에 맞는 메뉴를 사용하세요. 가져오기에 성공했다는 것은 현재 단계에서 내용을 받아들였다는 뜻일 뿐, 네트워크 연결이나 서버 인증이 확인됐다는 뜻은 아닙니다. 처음 추가하는 방법이 익숙하지 않다면 빠른 시작 가이드를 따라 한 가지 가져오기 방법을 완료하세요.

서비스 제공업체에서 전체 주소를 다시 복사하고 줄바꿈, 한글 문장 부호, 공백, 설명 문구가 섞이지 않았는지 확인하세요. 링크의 인증 정보는 민감하므로 공개 스크린샷이나 공개 텍스트 처리 도구로 확인하지 마세요. 주소가 빠짐없이 복사됐는지만 확인하고 물음표 뒤의 매개변수를 임의로 삭제하지 마세요. 구독 인증 정보의 일부일 수 있습니다. 주소가 만료됐다면 기존 서비스 제공업체의 계정 페이지에서 상태를 확인하세요. 인증 내용을 추측하거나 임의로 수정하지 마세요.

요청 실패와 응답 내용을 해석할 수 없는 경우를 구분하세요

구독 주소에 연결할 수 없다면 현재 네트워크에서 해당 구독 서비스에 접속할 수 있는지 먼저 확인하세요. 요청은 성공했지만 해석 오류가 표시된다면 응답 내용을 살펴봐야 합니다. 로그인 페이지, 오류 안내, 계정 상태 알림도 웹페이지 형식으로 반환될 수 있으므로 요청에 성공했다고 구독 데이터가 반환된 것은 아닙니다. 응답 상태가 정상처럼 보여도 오류 문구를 함께 확인하세요. HTML 페이지를 설정 파일로 저장해 다시 가져오지 마세요. 처음의 가져오기 실패가 형식 오류로 바뀌어 원래 문제를 가릴 뿐입니다.

구독을 가져올 때 기존의 사용 가능한 연결이 필요한 경우, 먼저 어떤 경로를 사용 중인지 확인한 다음 구독 하나만 업데이트하세요. 현재 목록에 사용할 수 있는 항목이 남아 있다면 먼저 삭제하지 마세요. 반대로 구독 요청이 이미 사용할 수 없는 서버를 거치도록 설정되어 있다면 업데이트가 완료되지 않을 수 있습니다. 규칙과 네트워크 조건을 확인한 뒤 사용 가능한 경로로 비교할 수 있지만, Direct와 Proxy를 무작정 반복해서 전환하지 마세요. 테스트할 때마다 실제 상태와 선택된 항목을 기록하세요.

업데이트 결과가 비어 있으면 기존 데이터를 먼저 보관하세요

한 번 업데이트한 뒤 항목 수가 크게 줄거나 목록이 비었다면 계속 진행하기 전에 안내, 구독 출처, 계정 상태부터 확인하세요. 구독이 일시적으로 빈 내용을 반환했거나 제공업체가 항목을 변경했을 수 있습니다. 반복해서 새로고침하면 문제를 확인할 단서가 사라집니다. 기존에 사용 가능한 항목과 설정 사본을 보관한 뒤 기존 서비스 제공업체에 이번 응답이 정상인지 확인하는 편이 안전합니다. 구독 내용은 유효하지만 항목 설정이 바뀌었다면 이전 이름을 믿고 사용하지 말고 Home에서 선택된 항목을 다시 확인하세요.

구독 이름과 서버 이름은 서비스가 유효하다는 증거가 아닙니다. 이름이 같아도 포트, 프로토콜, 인증 정보가 다를 수 있고 이름이 달라도 같은 서비스를 가리킬 수 있습니다. 업데이트 후 처음 연결할 때는 실제 항목을 열어 프로토콜 유형, TLS, 전송 관련 설정을 확인하세요. 앱에서 특정 유형이나 필드를 처리할 수 없다는 안내가 표시되면 현재 앱의 지원 범위와 서비스 제공업체가 제공한 형식을 확인하세요. 모든 해석 실패를 네트워크 품질 탓으로 돌리지 마세요.

중복 항목과 여러 구독 관리

같은 구독을 중복으로 추가하거나 수동 항목과 구독 항목이 함께 있거나 여러 구독에 동일한 서버가 포함되면 중복 표시가 생길 수 있습니다. 먼저 각 항목의 출처를 확인한 뒤 중복을 정리하세요. 이름만 보고 여러 항목을 한꺼번에 삭제하면 유일하게 사용 가능한 설정까지 제거할 수 있습니다. 항목을 하나 삭제해도 원격 구독에는 영향을 주지 않아 다음 업데이트 때 다시 나타날 수 있습니다. 지속적으로 정리하려면 유지할 구독 출처를 정한 뒤 출처별로 업데이트와 삭제를 관리하세요. 여러 곳에서 같은 정보를 반복 관리하지 않는 것이 좋습니다.

구독이 여러 개라면 출처와 용도를 구분할 수 있는 이름을 사용하고 하나씩 업데이트한 뒤 결과를 확인하세요. 모든 구독을 한 번에 업데이트하면 편리하지만 어느 구독에서 문제가 반환됐는지 판단하기 어렵습니다. 자세한 정리 방법은 여러 구독 관리 가이드를 참고하세요. 구독은 업데이트되지만 모든 항목이 연결되지 않는다면 설정 확인 항목으로 이동하세요. 업데이트 경로와 서버 연결 경로는 별개의 문제이므로 전자가 성공해도 후자를 확인해야 합니다.

[Rule]

속도 저하, 첫 연결 대기, 간헐적 연결 끊김

속도가 느린 단계부터 구분하세요

‘느리다’는 현상을 여러 유형으로 나누세요. 처음 열기 전 대기 시간이 긴 경우, 페이지 본문은 나타나지만 리소스 로딩이 느린 경우, 전송 속도가 계속 느린 경우, 일정 시간 사용한 뒤 멈추는 경우, 네트워크 전환 후 잠시 접속할 수 없는 경우가 있습니다. 각각 DNS 해석, 연결 수립, 대상 리소스, 전송 품질, 기존 연결 복구와 관련될 수 있습니다. 가장 쉽게 재현할 수 있는 현상 하나를 먼저 기록하고 테스트 수치 하나만 비교하지 마세요. Connectivity Test에 걸린 시간은 지속적인 전송 능력으로 환산할 수 없으며 모든 대상에 접속할 때의 성능을 나타내지도 않습니다.

연결을 끊은 상태에서 기본 네트워크를 확인하고 정상적으로 접속할 수 있는 같은 대상, 동일한 콘텐츠, 비슷한 시간대를 기준으로 비교하세요. 대용량 파일을 전송하면서 동시에 테스트하지 말고, 화질이나 페이지 크기가 다른 대상을 같은 부하로 간주하지도 마세요. 셀룰러 네트워크를 테스트할 때는 데이터 사용량과 신호 변화를 유의하고, Wi-Fi에서는 거리, 간섭, 다른 기기의 사용량을 살펴보세요. 기본 네트워크 자체가 불안정하다면 규칙을 바꿔도 접속 경로의 변동을 해결하기 어렵습니다.

변수를 고정해 서버와 네트워크 비교

설정이 정확하다고 확인된 기존 서버 하나를 선택하고 같은 네트워크에서 서로 독립적인 대상 두 곳에 접속하세요. 한 대상만 느리다면 대상 서비스나 해당 대상까지의 경로를 먼저 살펴봅니다. 여러 대상이 모두 느리다면 다른 기존 서버로 바꿔 비교하세요. 그런 다음 서버를 그대로 두고 네트워크를 바꿔 다시 테스트합니다. 이 방법으로 서버, 대상, 접속 네트워크와 관련된 차이를 구분할 수 있습니다. 각 조건에서 필요한 횟수만 테스트하세요. 잦은 속도 측정은 추가 부하를 만들고 일시적인 혼잡을 지속적인 패턴처럼 보이게 할 수 있습니다.

Config에서는 느리지만 Proxy에서는 정상이라면 규칙 적용 결과와 사용 중인 정책을 확인하세요. 바로 프로토콜을 바꾸지 마세요. 리소스에 따라 다른 경로를 사용하면 페이지 본문은 빠르지만 로그인이나 이미지 로딩은 느릴 수 있습니다. Direct는 빠르고 Proxy는 느리더라도 현재 비교에서 프록시 경로에 추가 요인이 있다는 뜻일 뿐, 클라이언트 자체에 문제가 있다는 증거는 아닙니다. 해당 항목의 서비스 상태, 전송 방식, 네트워크 조건을 점검한 뒤 장기적으로 사용할 기존 항목을 바꿀지 결정하세요.

DNS 대기, 연결 수립, 지속적인 전송 속도 구분

처음에는 오래 기다리지만 같은 페이지가 다음에는 눈에 띄게 빨리 열리면 DNS 캐시, 연결 재사용, 대상 캐시와 관련이 있을 수 있습니다. 다음 장에서 DNS 해석과 라우팅을 각각 확인하고, 캐시를 비운 뒤의 한 번의 접속을 지속적인 속도 기준으로 삼지 마세요. 새 연결을 만들 때마다 느리다면 TLS와 전송 설정을 확인하세요. 지속적인 전송 중에만 끊긴다면 네트워크 전환 여부, 서버 연결 종료 여부, 특정 유형의 트래픽에만 문제가 있는지 살펴보세요. 현상별로 기록하고 모든 문제를 시간 초과로 묶지 마세요.

전송 방식에 따라 필요한 네트워크 조건이 다릅니다. 특히 UDP를 사용하는 경우 접속 네트워크의 연결 가능성과 안정성이 결과에 영향을 줄 수 있습니다. 하지만 프로토콜 이름만 보고 속도를 판단할 수는 없으며 기존 서버 설정과 일치해야 합니다. 더 빠른 수치를 얻으려고 임의로 다른 유형을 선택하거나 대역폭 및 연결 관련 설정을 바꾸지 마세요. 잘못된 설정으로 원래 사용 가능한 항목까지 작동하지 않을 수 있습니다. 서비스 제공업체가 해당 설정을 명확하게 제공한 경우에만 전체 필드를 사용해 별도의 비교 항목을 만드세요.

네트워크 전환, 백그라운드 앱, 장시간 연결

Wi-Fi에서 셀룰러 네트워크로 전환하면 기존 연결을 다시 설정해야 할 수 있습니다. 네트워크 상태가 안정될 때까지 기다린 뒤 테스트 페이지를 다시 열거나 앱에서 요청을 다시 보내세요. 기존 페이지가 계속 실패한다고 해서 새 경로도 실패한다고 볼 수는 없습니다. 새 요청도 모두 복구되지 않는다면 On Demand 조건이 바뀌었는지 기록한 뒤 연결을 한 번 끊었다가 다시 연결해 확인하세요. 네트워크와 스위치를 빠르게 반복 전환하지 마세요. 연결 설정과 취소, 시스템 네트워크 변경이 겹쳐 명확한 결과를 얻기 어려워집니다.

특정 시간대에만 속도가 느리다면 당시 네트워크, 서버, 대상을 기록하고 다른 시간대에 같은 테스트를 반복하면 됩니다. 장시간 연속 측정할 필요는 없습니다. 특정 앱에서만 문제가 발생하면 앱이 동기화 중인지, 기존 세션을 재사용하는지 확인하세요. 상태를 전환한 뒤에는 요청을 새로 보내야 합니다. 서로 무관한 데이터를 많이 제공하는 것보다 차이가 재현되는 비교 결과 하나를 남기는 편이 유용합니다. 기존 서버나 대상 경로 문제로 확인되면 민감 정보를 가린 결과를 해당 서비스 제공업체에 전달하세요.

[Host]

DNS 해석 문제, LAN 접속 불가, 규칙 미적용

먼저 실제로 DNS 해석에 실패했는지 판단하세요

웹페이지에 서버를 찾을 수 없다는 메시지가 표시되거나 앱이 연결을 시작하기 전에 실패하거나 기록에 DNS 오류가 나타나면 DNS를 점검할 수 있습니다. 하지만 TLS 오류, 인증 실패, 대상 서버의 오류 응답은 DNS 장애와 다릅니다. 서로 독립적인 여러 도메인으로 비교해 한 도메인이나 내부 이름에만 문제가 있는지 확인하세요. 도메인을 IP 주소로 바꿔 접속하는 것은 대개 유효한 확인 방법이 아닙니다. HTTPS의 인증서, 서버 이름, 가상 호스트가 여전히 도메인을 필요로 할 수 있으므로 IP로 바꾼 뒤 실패해도 원래 DNS가 정상이라는 증거가 되지 않습니다.

기본 네트워크가 정상인지 확인한 다음 현재 Config의 DNS 관련 설정, [Host] 내용, 시스템에서 별도의 DNS 구성을 사용하는지 살펴보세요. 설정이 여러 곳에 있으면 먼저 각 설정의 출처를 기록하고 한꺼번에 삭제하지 마세요. 앱, 시스템, 특정 앱 자체의 DNS 해석 방식은 서로 다를 수 있습니다. 요청 기록에 도메인이 표시되지 않는다고 해서 DNS 해석이 전혀 없었다고 단정할 수도 없습니다. 요청 유형, 실제 대상, 연결 결과를 함께 살펴보고 필드 하나가 보이지 않는다는 이유만으로 설정을 크게 바꾸지 마세요.

DNS 서버에 연결할 수 있는 경로 확인

사용자 지정 DNS 주소는 현재 네트워크와 연결 상태에서 실제로 접속할 수 있어야 합니다. DNS 서버에 도달하려면 특정 프록시 경로가 필요한데, 그 경로를 만들려면 아직 해석되지 않은 서버 도메인이 필요하다면 의존성 문제가 생길 수 있습니다. 점검할 때는 먼저 접속 가능성을 확인한 기존 설정을 기준으로 삼고 DNS 관련 옵션을 한 번에 하나씩만 바꾸세요. 출처가 불분명한 DNS 주소를 여러 개 추가하지 마세요. 주소가 많아도 모든 요청에 신뢰할 수 있는 경로가 생기는 것은 아닙니다.

네트워크를 전환한 뒤 문제가 발생했다면 기존 네트워크 전용 DNS 서비스를 계속 사용하고 있는지 확인하세요. 예를 들어 내부 이름은 특정 Wi-Fi의 DNS 환경에서만 의미가 있어 셀룰러 네트워크에서는 같은 결과를 얻지 못할 수 있습니다. 서버에서 요구하는 Host나 서버 이름을 DNS 주소로 잘못 입력하지 않았는지도 확인하세요. 설정을 바꾼 뒤 관련 요청을 다시 보내고, 필요하다면 기존 세션의 영향을 제외하기 위해 연결을 끊었다가 다시 연결하세요. 단, 반복해서 재연결한다고 모든 캐시가 확실히 지워지는 것은 아닙니다.

규칙은 순서대로 검사하며 도메인과 주소를 구분해야 합니다

DOMAIN은 전체 도메인 일치, DOMAIN-SUFFIX는 도메인 접미사, IP-CIDR과 IP-CIDR6은 주소 범위에 적용됩니다. FINAL은 앞선 규칙과 일치하지 않을 때 마지막으로 적용됩니다. 각 규칙은 서로 다른 정보를 기준으로 작동하므로 도메인 규칙이 적용되지 않았다면 먼저 요청에 매칭할 도메인이 포함되어 있는지, 앞선 규칙이 요청을 처리했는지 확인하세요. 모든 도메인 규칙을 IP 범위로 바꾸지 마세요. 같은 도메인이 여러 주소로 해석될 수 있고 하나의 주소를 여러 서비스가 공유할 수도 있어 범위를 지나치게 넓히면 다른 대상에 영향을 줄 수 있습니다.

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,blocked.example.com,REJECT
IP-CIDR,192.168.0.0/16,DIRECT
IP-CIDR6,fc00::/7,DIRECT
FINAL,PROXY

이 예시는 의도적으로 규칙 순서 문제를 보여 줍니다. blocked.example.com은 앞의 DOMAIN-SUFFIX 규칙에 따라 PROXY로 처리되므로 뒤에 있는 같은 도메인의 REJECT 규칙은 예상대로 적용되지 않습니다. 이 도메인만 따로 처리하려면 더 구체적인 DOMAIN 항목을 접미사 규칙보다 앞에 배치하세요. 설정 사본에서 수정한 뒤 실제 요청이 해당 규칙에 적용되는지 확인합니다. 예시 도메인은 문법 설명용이며 테스트 서비스가 아닙니다. 주소 범위 규칙도 실제 네트워크와 기존 정책에 맞는지 확인해야 합니다.

LAN 기기와 내부 도메인 점검

프린터, 네트워크 저장 장치, 내부 서비스에 연결한 뒤 사용할 수 없다면 연결을 끊고 해당 기기에 직접 접속되는지 확인하세요. 대상이 IP 주소인지 내부 도메인인지도 구분합니다. 주소로는 접속되지만 이름으로는 안 된다면 DNS를 우선 확인하세요. 둘 다 접속되지 않으면 LAN 주소의 처리 정책, 네트워크 격리, 앱 권한을 살펴봅니다. 브로드캐스트나 멀티캐스트를 통한 검색은 일반적인 유니캐스트 요청과 다릅니다. DIRECT 규칙을 하나 추가한다고 자동 검색이 복구되는 것은 아니므로 주소를 알고 직접 접속하는 방법과 기기 검색 기능을 따로 테스트하세요.

시스템 Settings에서 해당 앱의 로컬 네트워크 권한을 확인하고 기기가 같은 LAN에 연결되어 있는지 살펴보세요. 게스트 Wi-Fi나 네트워크 격리 때문에 기기끼리 보이지 않을 수도 있습니다. [Host] 고정 매핑을 사용한다면 특히 네트워크를 전환하거나 라우터에서 주소를 다시 할당한 뒤 해당 주소가 여전히 예상한 기기를 가리키는지 확인하세요. 접속을 잠시 복구하려고 확인되지 않은 주소를 영구적으로 등록하지 마세요. 수정한 뒤 기존 DNS 설정을 하나씩 복구해 어떤 변경이 효과가 있었는지 확인하고 서로 중복되는 임시 설정을 계속 사용하지 않도록 하세요.

[General]

배터리 소모 증가, 발열, 백그라운드 재연결 반복

비슷한 사용 조건에서 비교하고 백분율만 보지 마세요

시스템 배터리 화면의 비율은 선택한 기간의 상대적인 사용량이며, 특정 앱이 고정된 양의 배터리를 소모했다는 뜻은 아닙니다. 기기 전체 사용량, 화면 밝기, 신호 상태, 백그라운드 동기화, 다른 앱의 활동도 비율에 영향을 줍니다. 먼저 시스템 Settings의 배터리 정보에서 활동 시간대를 확인한 다음 문제가 발생했을 때 실제로 무엇을 했는지 비교하세요. 목록에 Shadowrocket이 표시된다는 이유만으로 이상을 단정할 수 없으며, 사용 조건이 크게 다른 두 시간대를 직접 비교해서도 안 됩니다.

짧게 비교할 때는 네트워크, 화면 상태, 전면 앱, 사용 콘텐츠를 가능한 한 비슷하게 유지하고 대용량 데이터 전송, 구독 업데이트, 진단 중이었는지 기록하세요. 연결을 끊은 뒤에도 뚜렷한 발열이 계속되면 규칙만 바꾸기보다 다른 지속적인 작업과 기본 네트워크부터 확인하세요. 배터리 상태, 기기 온도, 충전 상태도 사용 경험에 영향을 줍니다. 반복 가능한 변화를 찾는 것이 목적이지, 한 번의 관찰로 클라이언트의 고정적인 배터리 사용량을 계산하는 것이 아닙니다.

약한 신호와 반복 재연결부터 확인

신호가 약하거나 Wi-Fi 경계 구역에 있거나 네트워크가 자주 전환되면 연결이 반복해서 다시 설정될 수 있습니다. 기기가 여러 네트워크 사이를 오간다면 먼저 안정적인 네트워크 하나에 고정해 확인하세요. 특정 서버만 계속 실패하면 설정이 확인된 다른 기존 항목과 비교합니다. 연결 자체가 완료되지 않을 때는 반복 시도로 추가 네트워크 활동이 발생할 수 있으므로 실패 원인을 먼저 해결하세요. 겉으로 연결 상태를 유지하려고 재시도 간격을 줄이지 말고 사용하지 않는 테스트를 백그라운드에서 장시간 반복하지도 마세요.

현재 네트워크 조건에서 On Demand가 계속 작동하는지, 수동으로 껐는데 자동으로 다시 연결되는지 확인하세요. 기준을 세우려면 On Demand를 잠시 끄고 수동으로 연결해 테스트한 뒤 필요한 조건을 복원합니다. 자동 연결 규칙은 실제 사용 방식에 맞게 설정해야 하며, 문제를 찾으려고 모든 네트워크에서 계속 연결되도록 만든 뒤 복원하는 것을 잊지 마세요. 시스템에 다른 자동 VPN 연결 조건이 있다면 함께 기록해 두세요. 서로 다른 출처의 동작을 앱 하나의 반복 재연결로 오인할 수 있습니다.

실제 요청을 관찰해 백그라운드 트래픽을 오류로 오해하지 마세요

전면 앱을 종료한 뒤에도 시스템 동기화, 메시지 연결, 기타 백그라운드 요청이 계속될 수 있습니다. 사용할 수 있는 연결 기록에 활동이 계속 표시되면 요청 출처와 시간을 확인하고 사진, 파일, 기타 동기화 작업과 겹치는지 살펴보세요. 트래픽이 계속 있다는 사실만으로 연결 구성 요소의 오류를 증명할 수는 없습니다. 요청이 반복해서 실패하고 계속 재시도되는 경우에만 해당 도메인, 규칙, 서버 경로를 조사하세요. 표시되는 요청을 줄이려고 여러 요청을 한꺼번에 REJECT하지 마세요. 필요한 요청이 차단되면 오히려 재시도가 늘어날 수 있습니다.

일부 진단 설정은 기록 작업량을 늘릴 수 있습니다. 점검에 필요할 때만 잠시 켜서 문제를 한 번 재현하고 민감 정보를 가린 기록을 저장한 뒤 평소 설정으로 되돌리세요. 상세 기록, 연속 테스트, 잦은 수동 구독 새로고침을 장기간 유지하지 마세요. 기록 파일에는 도메인, 주소 등 개인 네트워크 정보가 포함될 수 있으므로 공유 전에 내용을 확인하세요. 특정 진단 기능을 켠 뒤에만 문제가 생긴다면 다른 변수는 그대로 두고 해당 기능만 꺼서 비교하세요. 판단에 필요한 조건을 유지하는 것이 중요합니다.

규칙, 사용 부하, 복구 순서

특정 앱을 사용할 때만 배터리 소모가 뚜렷하게 늘어난다면 먼저 해당 앱이 많은 부하를 발생시키는지 확인한 뒤 관련 요청이 반복해서 실패하는지 살펴보세요. Config의 부적절한 REJECT 규칙이나 경로 선택 때문에 앱에서 재연결을 반복할 수 있지만, 규칙이 적을수록 배터리를 덜 쓴다고 단정할 수는 없습니다. 실패가 확인된 요청과 관련된 항목 하나만 조정한 뒤 기능과 요청이 복구되는지 관찰하세요. 현재 배터리 문제보다 영향 범위가 훨씬 큰 설정인 전체 규칙 파일 제거 또는 필요한 TLS 검증 해제를 임의로 하지 마세요.

효과적인 비교 기록에는 시작 상태, 사용한 콘텐츠, 연결 여부, 현재 네트워크, 마지막에 관찰된 현상이 포함되어야 합니다. 전체 사용 기록을 공개할 필요는 없습니다. 안정적인 네트워크와 사용 가능한 것으로 확인된 서버, 일반적인 설정에서도 문제가 재현된다면 간소화된 Config 사본으로 테스트하고 특정 작업에서만 발생하는지 기록할 수 있습니다. 기기 발열이 계속 심하면 고부하 작업과 연속 진단을 중단하고 시스템 안내에 따라 온도를 관리하세요. 상태가 정상으로 돌아온 다음 점검을 이어가고 테스트 자체가 추가 부하를 만들지 않도록 하세요.

[General]

업데이트 후 문제, 설정 복원, iPad 전용 점검

변경된 것이 앱인지 시스템인지 설정인지 먼저 확인하세요

업데이트 뒤 문제가 발생했다고 해서 업데이트 자체가 원인이라고 단정할 수는 없습니다. 같은 시기에 구독을 업데이트하거나 Config를 전환하거나 네트워크를 바꾸거나 시스템 권한을 변경했는지 먼저 떠올려 보세요. 앱 업데이트, 시스템 변경, 설정 내용의 변화를 각각 기록하고 앞에서 설명한 절차에 따라 최소한의 테스트를 진행하세요. 확인되지 않은 원인을 지어내거나 백업하지 않은 상태에서 앱을 연속으로 다시 설치하지 마세요. 특정 Config와 오류의 관련성이 분명하다면 구매 상태부터 조사하지 말고 설정 내용을 비교하세요.

앱의 다운로드와 업데이트는 App Store에서만 진행하세요. 제품을 확인하려면 정품 확인 안내에서 공식 아이콘, 개발자 Shadow Launch Technology Limited, 앱 ID 932747118을 확인하세요. 시스템 요구 사항은 App Store 페이지를 기준으로 확인하세요. 앱은 정상적으로 열리지만 서버 연결에 실패한다면 연결 설정과 서비스 상태도 살펴봐야 합니다. 구매 기록이 정상이어도 구독이 유효하거나 원격 서버를 계속 사용할 수 있다는 뜻은 아닙니다.

복구 전에 백업하고 되돌릴 수 있는 방법부터 사용하세요

설정을 변경하거나 복구하기 전에 서버 항목, 구독 출처, Config에 각각 사용 가능한 사본이 있는지 확인하세요. Config를 내보냈다고 서버 인증 정보까지 모두 백업된 것은 아닙니다. 동기화가 켜져 있는지, 어떤 항목이 동기화되는지도 실제 화면과 복원 결과를 기준으로 확인하세요. 백업에는 민감한 정보가 포함될 수 있으므로 본인이 관리할 수 있는 위치에 보관하세요. 작업 순서는 Config 백업 및 이전 가이드를 참고하되, 진행 전에 현재 기기에 실제로 표시되는 옵션을 확인하세요.

복구할 때는 설정이 명확한 기존 서버 항목 하나를 먼저 만들고 시스템 권한을 허용한 뒤 기본 연결을 확인하세요. 이어서 Config를 복원하고 나머지 설정을 하나씩 복원합니다. 오래된 내용을 모두 한꺼번에 가져오면 문제가 생겼을 때 원인을 구분하기 어렵습니다. 항목 유형을 하나 복원할 때마다 같은 테스트 대상을 확인하고 결과를 기록하세요. 문제가 다시 발생하면 가장 최근에 복원한 범위부터 살펴봅니다. 모든 데이터를 삭제한 뒤 기억에 의존해 다시 입력하는 것보다 되돌리기 쉽고, 계속 사용할 수 있는 정보도 보호할 수 있습니다.

iPhone 테스트 결과만으로 iPad를 판단하지 마세요

같은 정보를 사용해 iPhone에서는 되지만 iPad에서는 실패한다면 먼저 두 기기가 실제로 같은 네트워크에 연결되어 있는지 확인하세요. iPhone은 셀룰러 네트워크를 사용하는데 iPad는 인증이 필요한 Wi-Fi에 연결되어 있을 수 있습니다. 셀룰러 연결을 지원하는 iPad라면 실제 연결 상태와 권한도 확인하세요. 네트워크 조건이 같다는 것을 확인한 다음 Home에서 선택한 항목, Global Routing, 사용 중인 Config를 비교하세요. 항목 이름만 비교하지 말고 주소, 포트, 인증, 전송 관련 필드를 살펴보세요.

iPad는 화면 방향, 분할 화면, 창 레이아웃에 따라 메뉴 위치가 iPhone과 다를 수 있지만, 그렇다고 기능이 없다고 판단하지 마세요. 스크린샷의 위치를 그대로 따라 하기보다 Home, Config, Settings 등 화면에 표시된 용어로 해당 항목을 찾으세요. VPN을 처음 추가할 때 필요한 시스템 권한은 각 기기에서 따로 허용해야 합니다. 다른 기기에서 이미 허용했더라도 현재 iPad가 승인된 것은 아닙니다. 시스템 Settings의 로컬 네트워크 권한과 기기 관리 제한도 iPad에서 각각 확인하세요.

기기 변경 후 구매 복원과 설정 복원은 따로 진행하세요

기기를 바꾼 뒤에는 App Store에서 기존 구매 계정으로 구입 항목을 확인하고 화면에 표시된 방법에 따라 다시 받으세요. 사용 가능 여부, 호환성, 구매 권한은 App Store 페이지에 표시된 내용을 기준으로 확인하세요. 앱이 다시 설치되어도 기존 서버, 구독, Config가 모두 자동으로 복원되는 것은 아닙니다. 구매 복원 방법은 구입 항목 복원 안내를 확인하고, 설정은 본인이 보관한 사본을 하나씩 비교하세요. 연결 문제를 해결하려고 반복 결제하지 말고 앱 구매 권한이 필요한지 사용 설정 자료가 필요한지 먼저 확인하세요.

iPad에서 프린터나 내부 기기에 접속할 때만 실패한다면 DNS 및 LAN 항목으로 돌아가 권한, 네트워크 격리, 내부 이름 해석을 확인하세요. 화면 잠금이나 네트워크 전환 후에만 문제가 발생한다면 배터리 및 On Demand 점검 절차를 살펴보세요. 마지막으로 기기 유형, 네트워크 종류, 연결 수립 여부, 사용한 상태, 오류 단계, 변수를 하나씩 바꿔 비교한 결과를 민감 정보 없이 정리하세요. 오류 문구는 남기되 비밀번호, UUID, 전체 구독 정보, QR 코드는 제외하면 인증 정보를 노출하지 않으면서 재현 가능한 문제 설명을 만들 수 있습니다.