Shadowrocket
문제 해결 가이드

켜지지 않는 경우와 켜진 뒤 꺼지는 경우를 구분하세요

스위치가 켜진 상태로 유지되지 않는다면 서버 비밀번호를 바꾸기보다 먼저 시스템에서 VPN 구성을 허용하는지 확인하세요. Home에서 기존 서버를 선택하고 편집 화면에 머물러 있지 않은지 확인한 뒤 연결을 시도합니다. 처음 연결을 요청하면 기기에 VPN 구성을 추가할지 묻는 시스템 확인 창이 표시될 수 있습니다. 사용 중인 Shadowrocket에서 요청한 것이 맞는지 확인한 경우에만 시스템 안내에 따라 승인하세요. 이전에 창을 취소했다면 앱으로 돌아가 다시 연결을 요청하고 확인 창이 다시 나타나는지 살펴보세요.

증상을 세 가지로 나누어 기록하세요. 탭해도 아무 변화가 없는 경우, 시스템 확인 창은 나타났지만 완료되지 않은 경우, 스위치가 잠시 켜졌다가 자동으로 꺼지는 경우입니다. 첫 번째는 앱이 다른 동작에 정상적으로 응답하는지도 확인해야 합니다. 두 번째는 기기 권한을, 세 번째는 연결 실패 시 앱에 표시되는 안내를 확인하세요. 단순히 “켜지지 않음”이라고만 기록하지 마세요. 각각 화면 응답, 시스템 권한, 연결 설정 과정과 관련되어 있어 해결 순서가 다릅니다.

화면이 잠시 응답하지 않으면 진행 중인 가져오기나 테스트가 끝날 때까지 기다린 다음 Home으로 돌아가 다시 시도하세요. 앱을 정상적으로 종료한 뒤 다시 열면 일시적인 화면 멈춤을 배제할 수 있지만, 서버 문제까지 해결되는 것은 아닙니다. 스위치를 반복해서 누르면 여러 연결 시도가 뒤섞여 오류 메시지를 특정 동작과 연결하기 어려워집니다. 여러 번 켜고 끄기보다 한 번의 시도 결과를 온전히 기록하는 편이 진단에 도움이 됩니다.

시스템 구성 및 On Demand 확인

기기의 Settings에서 VPN 구성 관리 화면을 열어 Shadowrocket 관련 구성이 있는지 확인하고, 다른 네트워크 터널이 연결 중인지 살펴보세요. 관리 메뉴 위치는 시스템 화면에 따라 달라질 수 있으므로 Settings의 검색 기능으로 찾을 수 있습니다. 다른 활성 터널을 먼저 연결 해제한 뒤 앱으로 돌아와 수동 연결을 한 번 테스트하세요. 학교, 직장 또는 기기 관리 정책으로 설치된 구성일 수 있으니 정체를 모르는 구성을 바로 삭제하지 마세요.

스위치를 껐는데 다시 자동으로 켜지거나 네트워크를 바꿀 때 상태가 반복해서 바뀐다면 On Demand를 확인하세요. 설정된 조건에 따라 다시 연결을 요청할 수 있으므로 일반적인 수동 스위치 문제와는 다릅니다. 기존 조건을 기록한 뒤 On Demand를 잠시 끄고 수동 연결이 안정적인지 확인하세요. 수동 연결이 정상이라면 조건을 하나씩 복원하면서 어떤 네트워크 조건이 연결 또는 해제를 유발하는지 확인합니다.

관리 대상 기기는 시스템 정책에 따라 VPN 구성 추가나 수정이 제한될 수 있습니다. 권한 옵션을 선택할 수 없거나 시스템에서 구성이 제한되었다고 명시하면, 앱을 반복해서 다시 설치하지 말고 기기 관리자에게 허용된 설정 범위를 확인하세요. 앱 내부 설정으로 기기 관리 정책을 우회할 수는 없습니다. 시스템에서 연결 구성을 허용하는지 확인한 뒤에야 서버 주소, 프로토콜, 규칙을 점검할 수 있습니다.

자료를 보존한 뒤 복구 작업을 진행하세요

스위치가 잠시 켜졌다가 꺼지면 먼저 현재 서버 정보가 완전한지 확인하세요. 주소와 포트가 비어 있지 않은지, 프로토콜 유형이 올바른지, 가져온 항목이 이미 사용할 수 없는 서버를 가리키고 있지 않은지 살펴봅니다. 이름만 보고 설정 내용을 추측하지 말고 서비스 제공업체가 준 정보와 항목별로 대조하세요. 오류에 이름 확인, 인증 또는 인증서가 언급되면 해당 절을 확인하세요. 이 경우 시스템 권한 승인은 이미 끝났을 수 있으므로 VPN 구성을 반복해서 처리할 필요가 없습니다.

시스템 VPN 구성을 다시 만들기 전에는 필요한 구성 파일과 서버 정보를 저장하고, 서비스 제공업체에서 구독 정보를 다시 받을 수 있는지 확인하세요. 시스템 VPN 구성을 제거하는 것과 앱을 삭제하는 것은 영향 범위가 다른 작업입니다. 백업하지 않은 상태에서 두 작업을 함께 진행하지 마세요. 구성을 다시 만든 뒤에는 확인이 끝난 서버 하나로 수동 연결을 테스트하고, 기본 연결 복구 여부를 판단할 수 있도록 복잡한 규칙과 On Demand는 일단 복원하지 마세요.

마지막으로 “시스템 확인 완료, 다른 터널 연결 해제, 수동 연결 후에도 꺼짐”처럼 구체적인 결과를 기록하세요. 기기를 재시동한 뒤에도 재현된다면 앱에 표시된 오류 정보와 함께 원인을 계속 확인할 수 있습니다. 구매나 앱 출처에 관한 질문은 App Store 정품 확인 안내에서 별도로 확인하세요. 앱을 받는 문제와 연결 설정 문제를 혼동하지 마세요. 시스템 요구 사항은 App Store 페이지의 안내를 기준으로 합니다.

먼저 기본 네트워크를 확인한 뒤 모드를 비교하세요

연결은 되었지만 접속할 수 없다면 Shadowrocket 연결을 잠시 끊고 같은 기기와 네트워크에서 평소 정상적으로 열리는 페이지에 접속해 보세요. 연결을 끊은 상태에서도 실패한다면 Wi-Fi, 셀룰러 데이터, 라우터 또는 네트워크 로그인 인증을 먼저 확인해야 합니다. 공용 네트워크는 로그인 페이지에서 인증을 완료해야 할 수 있습니다. 기본 네트워크 접속이 되지 않는 상태에서는 프록시 규칙을 바꾸어도 대개 해결되지 않습니다. 인증을 완료한 뒤 다시 연결해 보세요.

기본 네트워크가 정상이라면 동일한 대상 페이지와 서버를 고정한 채 Global Routing의 Config, Proxy, Direct를 차례로 비교하세요. 각각 구성, 프록시, 직접 연결에 해당하는 화면상의 영문 이름입니다. 모드를 바꿀 때마다 새 요청을 만들어 테스트하고 이미 열린 페이지의 상태만 관찰하지 마세요. 일부 앱은 기존 연결을 재사용하므로 새 라우팅 결정이 기존 연결에 즉시 적용되지 않을 수 있습니다.

비교 테스트 결과는 원인을 설명하는 데 사용해야 하며, 특정 모드를 영구적인 해결책으로 간주해서는 안 됩니다. Direct는 정상이고 Proxy는 실패한다면 직접 경로는 사용할 수 있지만 서버 경로를 더 확인해야 합니다. Proxy는 정상이고 Config가 실패한다면 규칙 매칭, 정책 지정, DNS를 우선 점검하세요. 모든 모드가 실패하면 대상 자체, 기기 네트워크 권한, 이름 확인 결과를 다시 살펴보고 서로 다른 단계의 문제를 하나의 원인으로 뭉뚱그리지 마세요.

영향 범위에 따라 규칙을 확인하세요

일부 페이지나 앱만 실패한다면 먼저 성공한 대상 하나와 실패한 대상 하나를 기록하세요. 실패한 요청에서 실제로 사용한 도메인과 예상한 정책을 거쳤는지 확인합니다. 한 페이지가 여러 도메인에 요청을 보낼 수 있으므로 본문은 열리지만 이미지나 로그인이 실패한다면 관련 리소스 요청도 확인해야 합니다. 한 페이지를 고치려고 전체 구성을 광범위한 프록시 또는 직접 연결 규칙으로 바꾸지 마세요.

Config의 규칙은 일반적으로 순서에 따라 매칭되므로, 앞쪽의 범위가 넓은 규칙이 뒤쪽의 구체적인 규칙을 가릴 수 있습니다. 사용자 지정 규칙의 위치와 정책 이름, 마지막의 FINAL을 확인하세요. 요청을 직접 거부하는 REJECT와 연결 실패도 구분해야 합니다. 전자는 규칙에 따른 결정이고, 후자는 결정 이후의 접속 경로가 성공하지 못한 경우입니다. 앱 기록에 거부 정책이 적용되었다고 명확히 표시되면 먼저 해당 규칙이 원래 의도에 맞는지 확인하세요.

아래 예시는 매칭 순서만 설명하며 기존 구성을 대체할 수 있는 완전한 파일이 아닙니다. 도메인 접미사 규칙을 먼저 적용하고, 지정된 지역의 주소를 처리한 다음, 매칭되지 않은 요청에 정책을 지정합니다. 예시 도메인은 문법 설명용입니다. 실제 점검에는 확인된 대상을 사용하세요. FINAL을 바꾸면 매칭되지 않은 많은 요청에 영향을 주므로 기존 값을 기록하지 않은 채 함부로 수정하면 안 됩니다.

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

새 요청과 실제 복구 범위를 확인하세요

모드를 바꾼 뒤 실패한 페이지의 기존 요청을 종료하고 대상을 다시 여세요. 브라우저에서는 새 탭으로 테스트하고, 다른 앱에서는 관련 화면을 나갔다가 다시 들어가세요. 캐시된 내용만 보이고 새로 고침에 실패한다면 네트워크가 복구된 것으로 볼 수 없습니다. 페이지의 주요 내용, 이미지 리소스, 네트워크가 필요한 실제 작업을 각각 확인해 로컬 캐시나 기존 세션을 전체 접속 성공으로 오인하지 마세요.

브라우저는 정상인데 특정 앱만 실패한다면 해당 앱의 셀룰러 데이터 사용 권한, 특정 지역 접속 요구 사항, 별도 연결 또는 계정 상태 의존 여부도 확인해야 합니다. 앱에서 반환한 접속 제한은 터널 장애와 다릅니다. 로그인을 추가로 확인하게 만들 수 있으니 서버를 계속 바꾸지 마세요. 오류 문구를 먼저 보존하고 연결 단계에서 실패했는지, 서버 응답을 받은 뒤 실패했는지 확인하세요.

복구한 뒤 Global Routing을 원래 필요한 모드로 되돌리고 이전에 실패한 대상을 다시 확인하세요. Proxy에서만 일시적으로 작동하고 Config에서는 여전히 실패한다면 규칙을 계속 수정해야 합니다. 임시 비교 결과를 완전한 해결로 기록하지 마세요. 처음 설정이 익숙하지 않다면 Global Routing 튜토리얼을 다시 확인하세요. 간단한 질문이나 구매 관련 문의는 자주 묻는 질문을 참고할 수 있습니다.

테스트 실패를 점검 가능한 단계로 나누세요

Connectivity Test 실패는 해당 테스트가 예상대로 완료되지 않았다는 뜻일 뿐, 서버를 영구적으로 사용할 수 없다고 단정할 수는 없습니다. 먼저 테스트 대상이 현재 선택한 서버인지 확인하고 어떤 방식으로 테스트했는지 기록하세요. 테스트 방식마다 확인하는 단계가 다릅니다. 포트에 도달할 수 있어도 프로토콜 인증 성공을 뜻하지 않으며, 인증이 완료되어도 특정 페이지에 접속할 수 있다는 의미는 아닙니다. 테스트 결과는 실제 요청 결과와 함께 해석해야 합니다.

먼저 주소와 포트를 확인하고 주소 입력란에 프로토콜 접두사, 공백, 줄바꿈 또는 호스트 이름에 속하지 않는 경로가 섞이지 않았는지 살펴보세요. 구독 주소를 서버 주소로 사용하거나 웹 관리 페이지 주소를 Add Server에 입력하지 마세요. 주소가 도메인이라면 기기에서 해당 도메인을 확인할 수 있는지도 점검해야 합니다. 서버에 연결하기 전에 이름 확인이 실패한다면 인증 정보를 반복해서 바꾸기보다 DNS부터 확인하세요.

그다음 같은 구성에서 기본 네트워크를 한 번 바꿔 보세요. 예를 들어 Wi-Fi에서 셀룰러 데이터로 전환합니다. 한 네트워크에서만 시간 초과가 발생하면 로컬 네트워크, 라우팅 경로 또는 네트워크의 전송 방식 제한을 중점적으로 확인하세요. 두 네트워크 모두 실패하면 서비스 제공업체에 서버 상태와 포트, 설정이 바뀌었는지 문의합니다. 비교할 때 서버와 대상을 동일하게 유지해야 네트워크 차이가 유효한 근거가 됩니다.

프로토콜에 맞게 설정을 확인하고 필드를 혼용하지 마세요

Shadowsocks에서는 암호화 방식과 비밀번호를 확인하고, VMess와 VLESS에서는 ID 및 서버가 요구하는 전송 설정을 확인하세요. Trojan에서는 비밀번호와 TLS 관련 필드를 중점적으로 살펴봅니다. 프로토콜마다 필드의 의미가 다르므로 주소가 같다는 이유로 모든 옵션을 복사하면 안 됩니다. 가져오기에 성공했다는 것은 텍스트를 해석할 수 있다는 뜻일 뿐, 가져온 내용이 서버의 현재 설정과 일치한다는 의미는 아닙니다.

TLS를 사용하는 연결에서는 서버 이름, 인증서 유효성, 기기 시간도 확인해야 합니다. SNI는 서버 제공 정보에 따라 설정해야 하며, 접속할 수 있는 도메인이라고 해서 임의로 입력하면 안 됩니다. 인증서 오류가 발생하면 먼저 기기의 날짜와 시간이 정확한지 확인한 뒤 도메인, SNI, 서버 인증서를 대조하세요. 인증서 검증을 끄는 것은 일반적인 해결 방법이 아닙니다. 이름이나 인증서 설정 오류를 감추고 연결 상대 확인도 약화시킵니다.

서버에서 WebSocket 등의 전송 방식을 사용하는 경우 경로, Host, TLS 설정이 서로 맞는지도 확인해야 합니다. 경로는 대소문자를 구분할 수 있고 맨 앞의 슬래시를 유지해야 할 수 있습니다. 안내에 있는 주석까지 양식에 복사하지 마세요. 확실하지 않은 항목은 여러 값을 추측해 연속으로 시도하지 말고 서비스 제공업체의 원본 자료와 대조하세요. 그래야 문제를 다시 재현할 수 있습니다.

지속적인 오류와 간헐적인 시간 초과를 구분하세요

특정 시간대에만 시간 초과가 발생한다면 실패 화면만 저장하지 말고 발생 시각, 네트워크, 서버, 테스트 대상을 기록하세요. 일시적인 네트워크 혼잡, 네트워크 전환, 서버 부하 변화가 한 번의 테스트에 영향을 줄 수 있습니다. 횟수를 제한하고 간격을 두어 비교하세요. 고빈도로 테스트를 계속하면 간섭이 늘어나 간헐적인 문제가 지속되는 것처럼 보일 수 있습니다.

테스트는 완료되지만 실제 페이지가 실패한다면 접속이 확인된 작은 페이지로 “서버 연결”과 “서버를 통한 대상 접속” 단계를 구분하세요. 대상 측 제한, 이름 확인 차이, 규칙 지정이 두 번째 단계의 실패 원인일 수 있습니다. 반대로 테스트 대상 자체를 사용할 수 없어도 앱에서는 정상적으로 접속될 수 있으므로 테스트 하나만으로 서버를 삭제하지 마세요.

서비스 제공업체에 문의할 때는 프로토콜, 오류 유형, 네트워크 비교 결과, 재현 절차를 설명하되 비밀번호, ID, 전체 구독 링크는 공개하지 마세요. Trojan 필드의 의미는 Shadowrocket Trojan 설정 항목별 안내에서 확인할 수 있습니다. 설정을 확인했는데도 원격 서버에 접속할 수 없다면 서버 측 확인을 기다리세요. 관련 없는 로컬 규칙을 바꿔 문제 범위를 넓히지 마세요.

가져오기 실패, 해석 실패, 항목 접속 불가를 구분하세요

Subscribe 업데이트가 실패하면 먼저 어느 단계에서 문제가 발생했는지 확인하세요. 원격 콘텐츠를 가져오지 못했는지, 가져온 콘텐츠를 해석하지 못했는지, 업데이트는 완료됐지만 서버에 연결할 수 없는지 구분해야 합니다. 세 경우에 같은 해결 방법을 적용할 수 없습니다. 구독 업데이트는 원격 정보를 앱에 가져오는 기능이지 모든 원격 서버의 현재 접속을 보장하는 기능은 아닙니다. 서버 시간 초과는 구독 업데이트 결과를 보존한 뒤 이전 절차에 따라 별도로 확인하세요.

구독 링크는 이용 중인 서비스 제공업체에서 받으세요. 복사할 때 전체 주소와 쿼리 매개변수를 유지하고, 긴 링크가 채팅 화면에서 줄바꿈되거나 잘리거나 앞뒤에 공백이 들어가지 않았는지 확인하세요. 무작위 문자처럼 보이는 부분도 인증에 사용될 수 있으므로 삭제하지 마세요. 서비스 제공업체의 계정 페이지, 안내 페이지, 구성 표시 페이지를 구독 주소로 사용하지 마세요. 브라우저에 글자가 표시된다고 해서 앱에서 인식할 수 있는 데이터라는 뜻은 아닙니다.

현재 구독 그룹과 사용할 수 있는 항목을 기록한 뒤 수동 업데이트를 한 번 실행하고 안내 메시지를 확인하세요. 사용할 수 있는 서버가 남아 있다면 정보를 보존하고 재시도하려고 그룹 전체를 삭제하지 마세요. 일부 업데이트 방식은 항목 이름, 순서, 내용을 바꿀 수 있으므로 연결 전에 현재 선택된 항목을 다시 확인해야 합니다. 기존 이름이 사라진 것과 구독 전체가 무효가 된 것은 다른 문제입니다. 항목이 교체되거나 다른 그룹으로 이동했는지 먼저 살펴보세요.

접속 경로와 반환된 내용을 확인하세요

가져오기 단계에서 실패하면 현재 기본 네트워크로 구독이 제공되는 서비스에 접속할 수 있는지 확인하세요. 필요하다면 연결을 끊은 경우와 기존에 사용 가능한 연결을 이용한 경우의 업데이트 결과를 비교하되, 한 번에 접속 경로 하나만 바꾸세요. 업데이트 요청은 일반 페이지 요청과 완전히 같은 경로를 사용하지 않을 수 있으므로 앱에 표시된 결과를 기준으로 판단해야 합니다. 서비스 제공업체가 특정 접속 조건을 요구한다면 안내를 확인하세요. 오류를 우회하려고 구독 주소의 도메인이나 프로토콜을 임의로 바꾸지 마세요.

인증 실패나 접속 거부가 표시되면 구독이 초기화되었는지, 계정 권한이 바뀌었는지, 링크가 최신 유효 주소인지 확인하세요. 이미 만료된 인증 링크를 반복해서 요청해도 대개 권한은 복구되지 않습니다. 응답에 요청이 너무 잦다고 표시되면 업데이트를 계속 시도하지 말고 서비스 제공업체 안내에 따라 기다리세요. 앱 구매 상태와 원격 구독 권한은 별개입니다. 앱을 다시 구매해도 만료된 구독은 자동으로 복구되지 않습니다.

콘텐츠는 가져왔지만 해석에 실패했다면 서비스 제공업체가 제공한 형식과 가져오기 메뉴가 맞는지 확인하세요. 반환된 내용이 서버 정보가 아니라 로그인 페이지, 오류 안내 또는 점검 페이지일 수 있습니다. 페이지에 글자가 있다고 해서 형식이 올바른 것은 아닙니다. 웹페이지 전체를 구성 파일에 복사하거나 인코딩된 내용의 문자를 수동으로 삭제하지 마세요. 서비스 제공업체에 반환 형식을 확인하고 현재 가져오기 메뉴에 맞는 자료를 요청하세요.

업데이트 후 선택 항목과 적용 상태를 확인하세요

업데이트가 성공하면 Home으로 돌아가 현재 선택한 서버가 남아 있는지, 올바른 그룹에 속해 있는지 확인한 뒤 항목 하나의 연결을 테스트하세요. 새 항목이 모두 실패하면 프로토콜과 서비스 제공업체 상태를 중점적으로 확인합니다. 일부 항목만 실패한다면 이름과 오류 정보를 보존해 문의하세요. 그룹의 항목 수가 달라졌다고 바로 앱 오류로 단정하지 마세요. 원격 콘텐츠 변경도 로컬 결과에 영향을 줍니다.

구독 항목을 수동으로 수정하기 전에 다음 업데이트에서 수정 내용이 덮어써지는지 확인하세요. 필드 하나를 검증하려면 먼저 원래 값을 저장하고, 필요하다면 별도의 수동 테스트 항목을 만들어 구독 항목과 비교하세요. 같은 서버를 여러 그룹에 복사해 동시에 수정하지 마세요. 나중에 원본 항목과 임시 복사본 중 무엇에 연결했는지 확인하기 어려워집니다. 검증이 끝나면 임시 항목을 정리하고 이름을 명확하게 지정하세요.

오랫동안 업데이트가 없었다면 먼저 앱이 업데이트 시 필요한 네트워크 조건을 갖추었는지 확인하고 업데이트 설정을 살펴보세요. 백그라운드 실행은 시스템 일정에 영향을 받으므로 예상한 시점에 업데이트되지 않았다고 구독이 무효라고 단정하면 안 됩니다. 수동 업데이트는 성공했지만 백그라운드 업데이트가 예상대로 되지 않는다면 기기 사용 환경과 시스템 제한을 우선 확인하세요. 서버 설정을 전부 다시 만들 필요는 없습니다.

마지막으로 링크 출처 확인 여부, 가져오기 성공 여부, 해석 성공 여부, 업데이트 후 연결되는 항목을 하나의 기록으로 정리하세요. 원인을 파악하기 어렵다면 인증 정보를 제거한 오류 문구와 문제가 발생한 단계를 서비스 제공업체에 전달하고, 공개 토론 공간에 전체 링크를 보내지 마세요. 구독 관련 간단한 문답은 자주 묻는 질문에서, 처음 가져오는 절차는 사용 튜토리얼에서 확인할 수 있습니다.

먼저 느린 동작이 무엇인지 구분하세요

“속도가 느리다”는 증상을 페이지 첫 로딩 지연, 전송 중 속도 저하, 동영상 버퍼링, 간헐적 멈춤, 네트워크 전환 후 연결 끊김으로 나누어 확인하세요. 첫 로딩은 주로 이름 확인, 연결 설정, 핸드셰이크와 관련되고, 지속적인 전송은 대역폭, 혼잡, 대상 서비스의 영향을 받습니다. 두 현상을 지연 시간 하나로 설명할 수는 없습니다. 반복하기 쉬운 동작 하나를 정해 초기 단계와 지속 단계의 증상을 각각 기록한 뒤 점검할 단계를 결정하세요.

먼저 같은 기기에서 기본 네트워크 상태를 확인하고 대용량 파일 동기화, 시스템 업데이트, 여러 앱의 지속적인 전송이 동시에 진행 중이지 않은지 살펴보세요. Data의 트래픽 변화는 활동을 파악하는 데 도움이 될 수 있지만 트래픽이 많다고 특정 서버가 빠른 것은 아니며, 적다고 연결이 실패한 것도 아닙니다. 다른 앱이 네트워크를 많이 사용 중이면 작업이 끝날 때까지 기다린 뒤 비교해 기기의 전체 부하를 프록시 성능 문제로 오인하지 마세요.

테스트 대상, 서버, Global Routing 모드를 고정하고 비슷한 시간대에 횟수를 제한해 반복 테스트하세요. 네트워크, 서버, 프로토콜을 한꺼번에 바꾸고 개선을 특정 옵션의 효과로 돌리지 마세요. 먼저 같은 서버를 두 네트워크에서 비교한 뒤 네트워크를 고정하고 이미 보유한 두 서버를 비교할 수 있습니다. 매 단계에서 변수 하나만 바꿔야 결과가 구체적인 병목을 가리킵니다.

로컬 네트워크, 서버, 대상별로 나누어 비교하세요

특정 Wi-Fi 환경에서만 느리다면 신호 세기, 기기와 액세스 포인트 사이의 거리, 라우터 부하, 네트워크 로그인 상태를 먼저 확인하세요. 신호가 안정적인 위치로 옮겨 다시 테스트하는 편이 프로토콜 설정을 바로 바꾸는 것보다 원인을 파악하기 쉽습니다. 셀룰러 데이터와 비교할 때도 신호와 네트워크 유형 변화를 고려하세요. 이동 중 한 번의 테스트 결과는 한 장소에서의 정상 상태를 대표하지 않습니다.

같은 네트워크에서 특정 서버 하나만 느리고 다른 기존 서버는 정상이라면 서버 부하와 해당 서버까지의 경로를 중점적으로 확인하세요. 여러 서버가 모두 느리지만 Direct 비교는 정상이라고 해서 곧바로 앱 자체 문제라고 단정할 수는 없습니다. 서버들이 비슷한 경로나 원격 출구를 공유할 수 있기 때문입니다. 대상, 시간대, 프로토콜을 추가로 비교해 변화가 일관적인지 확인한 뒤 재현 가능한 정보를 서비스 제공업체에 전달하세요.

특정 웹사이트나 서비스만 느리다면 같은 서버로 다른 대상에 접속했을 때는 어떤지 먼저 확인하세요. 대상의 콘텐츠 전송 방식, 계정 제한, 서비스 상태, 접속 지역이 결과를 바꿀 수 있습니다. 테스트 파일의 전송량은 모든 웹사이트의 로딩 경험을 나타내지 않습니다. 다운로드가 빠른 연결이라도 짧은 연결의 핸드셰이크가 원활하다는 뜻은 아닙니다. 보기 좋은 숫자를 찾기보다 실제 문제가 발생한 동작을 기준으로 테스트하세요.

전송 특성을 확인하고 무작정 설정을 바꾸지 마세요

일부 프로토콜은 UDP에 의존하므로 네트워크에 따라 이러한 트래픽의 도달 가능성과 지속적인 전송 성능이 다를 수 있습니다. Hysteria2 또는 WireGuard를 사용한다면 관련 전송 방식을 네트워크와 서버가 지원하는지 먼저 확인한 뒤 프로토콜 설정을 점검하세요. 다른 TCP 연결이 작동한다고 UDP 경로도 정상이라고 단정할 수 없습니다. 프로토콜은 서버 설정에 맞춰 선택해야 하며 클라이언트 유형만 바꾸고 기존 설정을 그대로 두지 마세요.

MTU, 동시 연결 수, 연결 유지 설정은 첫 번째로 시도할 항목이 아닙니다. 특정 경로의 단편화나 패킷 손실은 작은 요청은 성공하지만 대용량 전송이 멈추는 현상으로 나타날 수 있습니다. 그러나 비슷한 증상은 혼잡이나 대상 제한으로도 생깁니다. 비교 근거 없이 MTU를 낮추면 다른 앱에 영향을 줄 수 있습니다. 테스트가 꼭 필요하다면 기존 값을 기록하고 한 번에 한 항목만 조정하세요. 개선되지 않으면 원래 값으로 복구합니다.

네트워크를 바꾼 뒤에만 멈춤이 생긴다면 시스템이 새 네트워크 연결을 완료할 때까지 기다린 다음 요청을 다시 시작하세요. 일부 앱은 기존 연결을 유지할 수 있어 전환 후 직접 다시 연결해야 합니다. 그렇다고 모든 트래픽을 계속 사용할 수 없다는 뜻은 아닙니다. 브라우저에서 새 요청을 보내고 기존 앱 세션과 비교하면 기본 터널 문제인지 앱 세션 복구 문제인지 구분하는 데 도움이 됩니다. 연결을 반복해서 켜고 끄거나 네트워크를 바꾸지 마세요. 재연결 과정을 방해할 수 있습니다.

개선 여부를 확인하려면 이전에 느렸던 전체 동작을 다시 실행하고 안정적으로 유지되는지 확인하세요. 한 번 빨리 열렸다는 이유만으로 검증되지 않은 설정을 여러 개 저장하지 마세요. 어떤 변수를 바꾸었을 때 개선되었는지, 원래 값으로 되돌렸을 때 다시 느려지는지 기록합니다. 단계별 점검 방법은 속도 저하 단계별 진단 안내에서, 통계 기준은 Data 페이지 트래픽 통계 안내에서 확인할 수 있습니다.

문제가 실제로 이름 확인 단계에서 발생했는지 확인하세요

DNS 문제는 서버 도메인을 확인할 수 없음, 일부 대상에서 주소를 찾을 수 없음, 네트워크를 바꾼 뒤 같은 도메인의 접속 결과가 달라지는 증상으로 나타날 수 있습니다. 서버 주소를 확인할 수 없는 경우와 대상 도메인을 확인할 수 없는 경우를 먼저 구분하세요. 전자는 프록시 연결을 막을 수 있고 후자는 연결이 설정된 뒤에 발생할 수 있습니다. 구체적인 도메인과 오류가 발생한 단계를 기록해야 로컬 네트워크, 앱 DNS 설정, 서버 경로 중 어디를 확인할지 결정할 수 있습니다.

대상 IP에 브라우저로 직접 접속하는 방식으로 모든 이름 확인 테스트를 대신하지 마세요. 많은 서비스는 TLS와 가상 호스트 매칭을 위해 올바른 도메인이 필요합니다. IP로 접속이 실패했다고 네트워크가 끊긴 것은 아닙니다. 마찬가지로 IP에 연결할 수 있어도 도메인으로 해당 페이지에 접속할 수 있다는 뜻은 아닙니다. 앱에 표시되는 이름 확인 또는 요청 기록을 살펴 도메인에 결과가 반환되는지, 이후 어떤 정책으로 처리되는지 확인하는 편이 정확합니다.

확인된 정상 대상 하나를 사용하고 현재 네트워크를 그대로 유지하세요. 도메인 하나만 실패한다면 철자, 도메인 자체의 상태, 서비스 제공업체가 안내한 서버 주소를 확인합니다. 서로 관련 없는 도메인이 여러 개 동시에 실패할 때는 이름 확인 서비스나 해당 서비스에 접속하는 경로를 우선 살펴보세요. 일부 서비스의 오류 응답, 계정 인증 실패, 빈 화면까지 모두 DNS 문제라고 부르지 마세요.

이름 확인 경로, 캐시, 주소 유형을 확인하세요

현재 Config에서 DNS 관련 설정을 확인하고 기기에 추가 DNS 설정이나 네트워크 관리 정책이 있는지도 살펴보세요. 먼저 이름 확인에 영향을 줄 수 있는 설정을 목록으로 정리한 다음 테스트할 항목을 정합니다. 이름 확인 서비스를 바꾸기 전에는 선택한 주소의 프로토콜과 네트워크 경로를 사용할 수 있는지 확인하세요. 접속할 수 없는 이름 확인 서비스를 입력하면 원래 특정 대상에만 있던 문제가 모든 도메인의 실패로 확대될 수 있습니다.

암호화된 이름 확인을 사용하는 경우 서버 이름, 인증서, 접속 경로도 확인해야 합니다. 암호화된 이름 확인 연결을 시작할 때도 서버 이름을 먼저 확인해야 할 수 있으므로 의존 관계가 잘못되면 시작 단계에서 실패합니다. “암호화”라는 이유만으로 이름 확인 경로가 올바르다고 볼 수는 없습니다. 사용 중인 구성 안내에 따라 확인하고 일반 DNS 주소, 암호화된 이름 확인 주소, 웹 주소를 서로 바꿔 쓸 수 있는 값으로 취급하지 마세요.

설정을 바꾼 뒤에는 캐시와 기존 연결도 고려해야 합니다. 시스템, 앱, 대상 앱이 이전 결과를 저장할 수 있으므로 즉시 새로 고침을 한 번 해도 새 이름 확인이 이루어지지 않을 수 있습니다. 관련 요청을 종료하고 연결을 다시 설정한 뒤 테스트하세요. 필요하다면 대상 앱도 재시작합니다. 결과를 기록하지 않은 채 이름 확인 서비스를 연달아 바꾸면 캐시가 갱신되기 전에 본 현상을 방금 수정한 설정 탓으로 잘못 판단할 수 있습니다.

IPv4와 IPv6 경로가 일관적인지도 확인하세요. 일부 네트워크는 두 유형의 주소를 모두 반환하지만 한쪽 경로가 불안정할 수 있고, 특정 주소 유형에 의존하는 서비스도 있습니다. 대상 하나를 해결하려고 IPv6 관련 기능을 전부 끄지 마세요. 네트워크, 구체적인 도메인, 실패한 주소 유형을 비교해 범위를 확인한 다음 현재 구성에서 지원하는 옵션을 최소한으로 조정하세요.

이름 확인 결과와 규칙 순서를 함께 확인하세요

도메인 규칙과 주소 규칙은 서로 다른 대상을 확인합니다. DOMAIN은 전체 도메인, DOMAIN-SUFFIX는 도메인 접미사, IP-CIDR과 IP-CIDR6은 주소 범위를 대상으로 합니다. 요청이 범위가 넓은 규칙에 먼저 매칭되면 뒤의 구체적인 항목은 적용되지 않을 수 있습니다. 이름 확인 결과가 달라지면 주소 규칙의 매칭도 바뀔 수 있습니다. 따라서 “DNS 결과가 있음”과 “올바른 규칙에 매칭됨”은 각각 따로 검증해야 합니다.

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

위 규칙 예시는 서로 다른 매칭 대상을 설명하기 위한 것으로 완전한 구성이 아닙니다. 이 예시에서는 전체 도메인 항목이 같은 정책의 접미사 항목에 이미 포함되지만 문법을 비교하기 위해 두 줄을 남겨 두었습니다. 실제 구성에서는 불필요한 중복을 피하세요. 사설 주소 규칙은 해당 주소 범위에 일치하는 요청만 처리하며, 한 줄만으로 모든 LAN 검색이나 기기 통신 문제가 해결된다는 뜻은 아닙니다. LAN 문제는 마지막 절의 점검도 함께 진행해야 합니다.

복구한 뒤 서버 도메인을 확인할 수 있는지, 실패한 대상 도메인도 확인되는지, 새 요청에 예상한 정책이 적용되는지, 실제 페이지에 접속할 수 있는지 각각 확인하세요. 항목 하나라도 여전히 이상하면 새 이름 확인 주소를 계속 추가하지 말고 해당 단계의 문제를 더 점검합니다. 서비스 제공업체에 문의할 때는 민감한 정보를 가린 도메인, 오류 유형, 네트워크 비교 결과를 전달하세요. 계정 식별자가 포함된 전용 주소나 전체 구성 파일은 공개하지 마세요.

지속적인 데이터 전송과 재연결 여부를 먼저 확인하세요

배터리 소모가 비정상적이라면 기기의 Settings에 있는 배터리 사용 기록, 화면 사용 시간, 당시 네트워크 활동을 함께 살펴보세요. VPN 연결은 다른 앱의 네트워크 트래픽을 전달하므로 시스템에 표시된 사용 내역이 특정 앱에서 직접 발생한 모든 활동을 정확히 나타내지는 않을 수 있습니다. 배터리 비율 하나만 보고 구성이 잘못되었다고 판단하지 마세요. 먼저 이상이 나타난 시간대를 기록하고 동영상 재생, 동기화, 업로드, 장시간 네트워크 전송이 동시에 있었는지 확인합니다.

기기를 사용하지 않을 때와 사용할 때로 나누어 점검하세요. 사용하지 않을 때 비교하려면 같은 네트워크, 비슷한 배터리 잔량, 비슷한 관찰 시간을 유지하고 충전, 다운로드, 위치 이동을 피합니다. 사용 중 비교할 때는 같은 동작을 실행하고 지속 시간을 기록하세요. 짧은 시간의 배터리 표시는 온도와 시스템 추정치의 영향을 받으므로 정확한 소모량을 판단하기 어렵습니다. 지속적인 데이터 전송이나 반복 연결처럼 직접 관찰할 수 있는 단서를 우선 확인하세요.

연결이 불안정하면 계속 재시도하면서 네트워크 활동이 늘어날 수 있습니다. Wi-Fi와 셀룰러 데이터 사이를 반복해서 전환하는지, 신호가 약한 장소인지, On Demand가 비슷한 조건 사이에서 반복해서 작동하는지 확인하세요. 먼저 기본 네트워크를 안정시키고 On Demand를 잠시 끈 뒤 수동 연결을 비교합니다. 재연결이 멈춘 후 배터리 문제가 완화된다면 기능을 모두 끄기보다 조건을 하나씩 복원하세요.

진단으로 인한 간섭을 줄이되 정상적인 검증은 유지하세요

문제를 확인하는 동안 상세 기록을 임시로 켜거나 Connectivity Test를 자주 실행할 수 있습니다. 필요한 증거를 확보한 뒤에는 기존 기록 수준으로 되돌리고 반복 테스트를 중단하세요. 진단 활동 자체가 일상적인 부하로 오인될 수 있습니다. Data가 계속 증가한다면 다른 앱의 현재 동작도 함께 확인하세요. 클라우드 동기화, 미디어 업로드, 백그라운드 전송은 화면이 꺼진 뒤에도 계속될 수 있으므로 기기가 가만히 있는 것처럼 보인다고 트래픽이 없다고 판단하지 마세요.

기기가 눈에 띄게 뜨거우면 고부하 테스트를 중단하고 온도가 안정될 때까지 기다린 뒤 연결 상태를 비교하세요. 온도 변화는 시스템 성능과 무선 통신에 영향을 줄 수 있으며, 충전하면서 지속적으로 데이터를 전송하면 간섭이 늘어날 수 있습니다. 더 많은 데이터를 얻으려고 부하 테스트를 계속하지 마세요. 일상적인 문제 해결의 목적은 실제 문제를 재현하고 개선 여부를 확인하는 것이지 기기나 네트워크의 한계를 측정하는 것이 아닙니다.

배터리 문제는 기기 전체 상태도 확인해야 합니다. 연결을 끊은 뒤에도 같은 배터리 소모 문제가 있다면 프록시 설정을 계속 바꾸기보다 시스템 배터리 기록과 다른 앱의 활동을 살펴보세요. 특정 네트워크와 특정 서버 조합에서만 문제가 발생한다면 연결 재시도와 전송 안정성을 우선 조사합니다. 재현 가능한 조합으로 관찰 범위를 좁혀야 기기의 배터리 상태를 단일 앱 설정 문제로 오해하지 않습니다.

업데이트 후에는 최소한의 구성부터 복원하세요

업데이트 후 문제가 생기면 앱 업데이트, 시스템 업데이트, 구독 업데이트, Config 내용 업데이트를 먼저 구분하세요. 이 작업들은 비슷한 시점에 발생해도 영향을 받는 대상은 다를 수 있습니다. 마지막으로 정상 사용한 시점의 네트워크와 구성을 기록하고 현재 서버, Global Routing, 구성 파일이 여전히 기존 선택과 같은지 확인하세요. 구독 이름 변경, 정책 대상 변경, 시스템 권한 상태 변화로 인해 앱 업데이트가 직접 원인인 것처럼 보일 수 있습니다.

앱을 정상적으로 다시 열고 필요하다면 기기를 재시동한 다음, 확인된 서버 하나와 간단한 접속 대상으로 테스트하세요. 직접 추가한 복잡한 규칙, 조건부 연결 설정, 기타 확장 구성은 원본을 저장한 뒤 잠시 비활성화합니다. 설정을 하나 복원할 때마다 테스트하세요. 기본 연결은 정상인데 특정 항목을 추가한 뒤 실패한다면 앱 데이터를 전부 삭제하지 않고도 점검 범위를 해당 항목으로 좁힐 수 있습니다.

Config에서 유효하지 않은 정책 참조, 삭제된 서버 이름, 형식 오류를 확인하세요. 기존 구성을 저장할 수 있다고 해서 참조된 대상이 여전히 존재하는 것은 아닙니다. 명확한 해석 오류가 표시되면 안내에 따라 해당 줄을 찾고 수정 전후의 차이를 보존하세요. 단일 오류를 고치려고 여러 출처의 설정을 대량으로 이어 붙이지 마세요. 구성 간 의존 관계 때문에 각각 올바른 조각도 조합한 뒤에는 작동하지 않을 수 있습니다.

자료를 백업했고 필요성이 분명한 경우에만 시스템 구성을 제거하거나 앱을 다시 설치하는 방안을 고려하세요. 앱 다운로드와 업데이트는 App Store를 통해 진행합니다. 구매 복원과 기기 호환성은 구매 항목 복원 안내에서 확인할 수 있으며 시스템 요구 사항은 App Store 페이지의 안내를 기준으로 합니다. 복구한 뒤에는 기본 연결부터 확인하고 자료를 단계적으로 다시 가져오세요. 검증되지 않은 “업데이트 후 고장”이라는 설명보다 완전한 재현 절차가 문제 파악에 더 도움이 됩니다.

기기를 비교하기 전에 네트워크와 자료 조건을 맞추세요

같은 구독이 iPhone에서는 정상이고 iPad에서는 실패한다면 두 기기가 실제로 같은 네트워크를 사용하는지 먼저 확인하세요. iPhone은 이미 셀룰러 데이터로 전환했지만 iPad는 인증이 필요하거나 신호가 약한 Wi-Fi에 연결되어 있을 수 있습니다. 실제 네트워크 상태를 확인한 뒤 선택한 서버, Global Routing, Config, 구독 업데이트 시점을 대조하세요. 서버 표시 이름만 비교하는 것으로는 충분하지 않습니다. 이름이 같아도 항목의 설정은 다를 수 있습니다.

두 기기에서 같은 대상, 같은 서버, 같은 모드를 사용해 각각 새 요청을 보내세요. 한 기기에서 이미 버퍼링된 페이지와 다른 기기에서 처음 접속하는 결과를 비교하지 마세요. 조건을 맞춘 뒤에도 iPad에서만 실패한다면 해당 기기의 VPN 권한, 날짜와 시간, 기기 관리 정책, 추가 네트워크 구성을 확인하세요. 다른 기기에서 서버가 작동해도 이 기기의 권한이나 설정 차이가 배제되는 것은 아닙니다.

앱 구매와 구성 이전도 별도로 처리해야 합니다. 같은 계정으로 구매 항목을 이용할 수 있는지, 기기 호환성과 시스템 요구 사항은 App Store 페이지의 안내를 기준으로 확인하세요. 앱이 설치되어 있어도 서버 정보가 자동으로 모두 표시되는 것은 아닙니다. 먼저 iPad 앱 받기 안내에 따라 앱을 확인한 다음 서비스 제공업체에서 구독을 받아 가져오기를 완료하세요. 그 후 연결 상태를 비교해야 구성이 없는 문제를 구매 복원 실패로 오해하지 않습니다.

멀티태스킹, 잠자기, 네트워크 복구를 확인하세요

iPad에서 Split View나 멀티태스킹을 사용하면 앱이 좁은 영역에 표시되어 일부 설정 메뉴를 펼치거나 스크롤해야 보일 수 있습니다. 창이 좁아져도 설정 항목의 의미는 바뀌지 않지만 아래쪽에 숨겨진 필드를 놓치기 쉽습니다. Add Server를 확인할 때는 항목별로 스크롤하고 저장한 뒤 해당 항목을 다시 열어 확인하세요. 편집 화면 위쪽만 맞다고 해서 모든 설정이 제대로 저장되었다고 판단하지 마세요.

화면을 덮거나 오랫동안 사용하지 않은 뒤, 또는 네트워크를 바꾼 뒤 문제가 생기면 시스템 네트워크 복구, VPN 연결 상태, 대상 앱 세션을 각각 확인하세요. 먼저 기기가 기본 네트워크에 정상적으로 접속할 수 있는지 확인한 다음 Shadowrocket 연결을 살펴보고 마지막으로 대상 페이지를 다시 여세요. 새 요청은 정상이지만 기존 동영상, 파일 전송, 세션이 계속 멈춘다면 대상 앱이 기존 연결을 복구하지 못한 문제일 수 있습니다. 서버 구성을 전부 다시 만들 필요는 없습니다.

iPad에서도 실제 네트워크 조건별로 On Demand를 확인해야 합니다. 기기가 같은 Wi-Fi에 오래 연결되어 있어도 중간에 잠자기 상태에 들어가거나 인증이 만료되거나 액세스 포인트가 바뀔 수 있습니다. 먼저 수동 연결로 기본 작동을 확인하고 On Demand를 복원한 뒤 기기를 깨울 때, 네트워크를 벗어날 때, 다시 연결할 때의 동작을 각각 테스트하세요. 한 번 깨어났을 때 성공했다고 모든 네트워크 조건이 확인된 것은 아닙니다. 실제 사용 상황에 대한 테스트 기록을 남기세요.

LAN 주소, 기기 검색, 프록시 경로를 구분하세요

집에 있는 저장 장치, 프린터 또는 다른 LAN 서비스에 접속할 수 없다면 먼저 연결을 끊어 비교하고 기기들이 실제로 서로 통신할 수 있는 같은 네트워크에 있는지 확인하세요. 게스트 Wi-Fi, 액세스 포인트 격리, 서로 다른 서브넷 자체가 기기 간 통신을 막을 수 있습니다. 연결을 끊어도 접속할 수 없다면 라우터나 기기 권한부터 확인하세요. 기본 LAN 경로가 정상일 때만 Config의 라우팅 규칙을 살펴보면 됩니다.

LAN 기기 검색과 알고 있는 주소로 직접 접속하는 것은 서로 다른 동작입니다. 주소를 직접 입력하면 정상인데 자동 검색이 실패한다면 검색 패킷, 네트워크 격리, 시스템의 로컬 네트워크 권한이 원인일 수 있습니다. 도메인 규칙 하나를 추가하는 것만으로 해결할 수는 없습니다. 관련 앱에 로컬 네트워크 권한이 필요하다면 기기의 Settings에서 허용 상태를 확인하세요. 모든 검색 문제를 DNS 탓으로 돌리거나 네트워크 전체에 광범위한 정책을 임의로 추가하지 마세요.

특정 사설 주소 범위를 직접 연결해야 한다면 실제 서브넷을 확인하고 해당하는 IP-CIDR 또는 IP-CIDR6 규칙을 사용하세요. 이 규칙을 가릴 수 있는 범위가 넓은 규칙보다 앞에 배치합니다. 예시 서브넷을 실제 가정 네트워크 정보로 그대로 사용하지 마세요. 도메인과 주소를 함께 사용하는 서비스라면 도메인이 어디로 해석되는지도 확인해야 합니다. 원격 주소로 연결되는 도메인을 그대로 둔 채 로컬 사설 주소 규칙만 바꾸는 실수를 피하세요.

테스트할 때는 확인된 주소로 직접 접속, 도메인 접속, 기기 검색을 각각 검증하고 결과를 기록하세요. 검색만 실패한다면 검색 메커니즘을 더 조사하고, 도메인은 실패하지만 주소는 정상이면 DNS 절을 확인하세요. 모든 LAN 대상이 실패한다면 네트워크 격리와 규칙 순서를 살펴봅니다. 이렇게 구분하면 한 가지 접속 방식을 고치려다 다른 모든 경로를 바꾸고 새 문제를 만드는 일을 방지할 수 있습니다.

마지막으로 기기 유형, 현재 네트워크, 연결 모드, 대상 유형, 오류 문구, 비교 결과를 포함한 재현 기록을 작성하세요. 공유하기 전에 구독 주소, 인증 필드, 계정 정보를 가리세요. 기본 연결을 복구한 뒤 사용 튜토리얼로 돌아가 일상적인 접속을 확인하세요. 흔한 결론을 빠르게 확인하려면 자주 묻는 질문을 참고하세요. 이 기록을 보관하면 다음에 비슷한 증상이 생겼을 때 모든 설정을 다시 바꾸지 않고 검증된 단계부터 이어서 점검할 수 있습니다.