Shadowrocket 문제 해결
연결, 규칙 및 DNS

1. 연결 스위치가 켜지지 않을 때: 시스템 연결 권한부터 확인

스위치가 작동하지 않는 경우, 켜자마자 다시 꺼지는 경우, 스위치는 켜져 있지만 요청이 실패하는 경우를 구분하세요. 세 증상은 서로 다른 단계에서 발생합니다. 앞의 두 경우에는 시스템 권한, 네트워크 확장 기능, 설정 유효성을 먼저 확인하세요. 세 번째 경우에는 연결 자체가 설정됐을 수 있으므로 서버, 라우팅, DNS를 점검해야 합니다. 상단 상태 아이콘만 보고 대상 사이트에 접속할 수 있다고 판단하지 마세요. 스위치가 한 번 꺼졌다고 서버 문제로 단정해서도 안 됩니다.

현재 상태를 기록하고 기본 네트워크 확인

현재 네트워크 종류, 선택한 서버, Global Routing 값, On Demand 활성화 여부를 기록하세요. 현재 Config를 저장하고 마지막으로 연결에 성공한 뒤 변경한 항목도 적어 둡니다. 그런 다음 Shadowrocket을 종료하고 브라우저에서 평소 바로 열리는 사이트에 접속해 보세요. 앱을 종료해도 접속되지 않으면 Wi-Fi 로그인 페이지, 모바일 데이터 권한, 라우터 또는 시스템 네트워크 제한부터 확인해야 합니다. 클라이언트 연결을 점검하기 전에 기기 자체가 인터넷에 연결되어 있어야 합니다.

공용 Wi-Fi는 먼저 웹 인증을 완료해야 할 수 있습니다. 무선 네트워크에 연결됐다고 인증까지 끝난 것은 아니며, 시스템에 이전 로그인 결과가 캐시되어 있을 수도 있습니다. 클라이언트를 종료한 상태에서 시스템이 제공하는 인증 페이지를 열고 네트워크가 정상적으로 작동하는지 확인한 다음 연결을 시도하세요. 기기에 회사나 학교에서 관리하는 프로파일이 설치되어 있다면 관련 네트워크 정책을 확인하세요. 용도를 모르는 관리 항목은 삭제하지 말고, 기기 관리자가 설정한 권한을 우회하려고 하지 마세요.

VPN 설정 및 동시 연결 확인

1. Home으로 돌아가 사용자가 직접 준비한 유효한 서버가 선택되어 있는지 확인하세요. 목록만 가져오고 서버를 선택하지 않은 상태일 수 있습니다.
2. 연결을 켜고 시스템에서 VPN 구성 추가 권한을 요청하는지 확인하세요. 요청이 표시되면 시스템 안내에 따라 승인합니다.
3. 시스템 설정의 VPN 관리 화면에서 연결 기록을 확인하고, 다른 연결이 반복해서 제어권을 가져가는지 살펴보세요.
4. On Demand를 잠시 끈 다음 수동으로 연결해 보세요. 수동 연결과 자동 연결 조건을 따로 확인할 수 있습니다.

이전에 권한 요청을 거부했다면 다시 시도하기 전에 시스템 설정에서 상태를 확인해야 할 수 있습니다. 설정을 백업하고 해당 항목이 Shadowrocket에 속한다는 점을 분명히 확인한 경우에만 기존 연결 기록을 제거한 뒤 앱에서 다시 생성하는 방법을 고려하세요. 시스템 연결 기록 삭제와 구독 삭제는 서로 다른 작업이지만, 여러 곳을 동시에 변경하면 원인을 파악하기 어려우므로 먼저 백업해야 합니다. 처음부터 기기의 네트워크 설정 전체를 재설정하지 마세요.

스위치가 즉시 꺼질 때의 확인 순서

먼저 권한 또는 설정 오류가 명확하게 표시되는지 확인한 뒤, 스위치를 누른 직후인지, 네트워크 전환 후인지, 잠금 해제 후인지 살펴보세요. 시작할 때마다 실패한다면 현재 설정을 정상적으로 읽을 수 있는지, 필수 서버 필드가 비어 있지 않은지 확인하세요. 네트워크 전환 때만 발생한다면 자동 연결 조건을 잠시 끄고 한 가지 네트워크에 고정해 다시 시도하세요. 매번 같은 동작을 기준으로 확인해야 합니다. 서버를 연달아 바꾸면 실제로 문제를 일으킨 조건을 찾기 어렵습니다.

서버 설정 오류로 연결 후 요청이 실패할 수 있지만, 모든 스위치 문제를 프로토콜 문제로 설명할 수는 없습니다. 화면에 표시된 오류 문구 전체를 기록하고 권한과 설정 읽기부터 확인하세요. 앱에서 관련 진단 기록을 제공한다면 오류 유형과 발생 단계를 복사하세요. 구독 주소, 인증 정보, 서버 식별자는 민감한 정보이므로 지원 담당자에게 보내기 전에 가려야 합니다. 스크린샷에 QR 코드, 전체 주소 또는 개인 계정 정보가 포함되어 있지 않은지도 확인하세요.

앱을 재시작한 뒤에도 문제가 반복된다면 작업을 저장하고 기기를 재시작한 다음 같은 네트워크와 설정으로 다시 확인하세요. 재시작은 일시적인 시스템 상태를 배제하기 위한 방법이지, 원인을 확정하는 절차는 아닙니다. 재현 기록에는 ‘어느 단계에서 실패했는지’, ‘어떤 안내가 표시됐는지’, ‘클라이언트를 종료하면 문제가 해결되는지’가 포함되어야 합니다. 이런 구체적인 정보가 단순히 ‘연결이 안 됨’이라고 적는 것보다 문제 해결에 도움이 됩니다.

2. 연결은 됐지만 인터넷이 안 될 때: 서버와 규칙 구분

스위치가 켜져 있으면 문제를 모든 요청의 실패, 일부 도메인만 실패, 특정 앱만 실패하는 경우로 나누세요. 바로 접속할 수 있는 사이트, 기존 서버를 통해 접속해야 하는 대상, 실제 문제가 발생한 앱을 각각 하나씩 선택해 확인합니다. 테스트 대상은 사용자가 직접 정하고 계속 동일하게 유지해야 합니다. 사이트를 자주 바꾸면 대상 서비스 상태, 캐시, 라우팅 차이가 뒤섞여 결과를 해석하기 어려워집니다.

Global Routing으로 비교하기

Global Routing의 Config, Proxy, Direct는 각각 현재 설정에 따른 경로, 프록시 경로, 직접 연결 경로를 뜻합니다. Config는 현재 Config의 규칙으로 경로를 결정하고, Proxy는 프록시 경로를 집중적으로 확인할 때 사용하며, Direct는 직접 연결 결과를 살펴볼 때 사용합니다. 모드 전환은 진단을 위한 방법이지, 특정 모드를 계속 사용하라는 뜻은 아닙니다. 테스트 중에는 서버를 고정하고 기존 웹페이지를 닫은 뒤 새 요청을 보내세요. 그래야 이전 경로로 이미 연결된 요청이 결과에 영향을 주지 않습니다.

Proxy에서는 접속되지만 Config에서 실패한다면 일치한 규칙, 적용된 정책, DNS 결과를 먼저 확인하세요. 서버를 바로 다시 설정하지 마세요. 두 모드에서 모두 실패하면 서버 인증, 프로토콜 매개변수, 네트워크 조건을 점검하세요. Direct에서 특정 사이트에 접속되지만 Proxy에서 실패한다면 현재 직접 연결 환경에서는 해당 사이트에 접속할 수 있다는 뜻입니다. 그렇다고 모든 프록시 요청에 문제가 있다고 단정할 수는 없습니다. 각 결론은 해당 시점의 네트워크, 대상, 모드 조건에 한정해야 합니다.

규칙 순서와 정책 대상 확인

Config에서 방금 수정한 파일이 현재 적용 중인지 확인하세요. 파일이 목록에 있다고 해서 적용 중인 것은 아닙니다. 원격 업데이트로 받은 사본이 직접 편집한 사본과 다를 수도 있습니다. 그런 다음 규칙 순서에 따라 대상 도메인을 확인하세요. 정확한 도메인, 도메인 접미사, 키워드, 최종 규칙이 각기 다른 정책으로 보낼 수 있습니다. 일반적으로 먼저 일치한 규칙이 결과를 결정하므로 뒤에 있는 올바른 규칙으로 앞에서 발생한 잘못된 일치를 바로잡을 수 없습니다.

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

위 예시는 규칙 문법을 설명하기 위한 것이며, 범용 설정을 권장하는 내용이 아닙니다. 첫 번째 규칙은 지정한 도메인과 하위 도메인을 PROXY로 보내고, 두 번째 규칙은 정확히 일치하는 도메인을 거부합니다. 사설 네트워크 대역 예시는 DIRECT로 보내며, 앞선 규칙에 일치하지 않은 요청은 FINAL에서 처리합니다. 복사하기 전에 적용 범위를 이해하고 자신의 네트워크 환경과 대조하세요. 특히 예시의 거부 규칙, 지역 규칙, 최종 정책을 사용 중인 Config 전체에 그대로 적용하지 마세요.

규칙이 사용자 지정 정책 그룹을 가리킨다면 그룹에 사용 가능한 서버가 있는지, 현재 선택이 예상한 것과 일치하는지도 확인해야 합니다. 그룹 이름이 맞더라도 내부에서 선택된 서버가 올바르다는 뜻은 아닙니다. 자동 선택과 수동 선택의 결과도 다를 수 있습니다. 점검 중에는 사용 가능한 기존 서버 하나를 임시로 고정해 정책 변경의 영향을 줄일 수 있습니다. 확인이 끝나면 원래 선택 방식으로 되돌리고 이번에 성공한 조건을 기록하세요.

특정 앱에서만 실패하는 경우

앱은 지속 연결을 재사용하거나 주소를 캐시하고 여러 도메인에 동시에 요청할 수 있습니다. 앱을 완전히 종료한 뒤 다시 열어 메인 화면, 로그인, 미디어 로딩이 각각 실패하는지 확인하세요. 웹페이지 하나가 정상이라고 해서 앱이 사용하는 모든 도메인이 정상이라는 뜻은 아닙니다. 진단 기록에 요청 경로가 표시된다면 실패한 도메인을 하나씩 확인하세요. 리소스 하나를 고치려고 전체 규칙을 광범위한 키워드 매칭으로 바꾸지 마세요.

LAN 서비스의 경우 로컬 네트워크 권한, 기기들이 같은 네트워크에 연결되어 있는지, 요청에 도메인과 사설 주소 중 무엇을 사용하는지도 확인해야 합니다. 인터넷은 되지만 프린터나 가정용 저장 장치에 접속할 수 없는 문제는 외부 서버 접속 실패와 다릅니다. 대상 요청으로 검증된 변경만 유지하세요. 어떤 규칙이 적용됐는지 확인할 수 없다면 백업을 복원하고 변경 사항을 최소화해 다시 시작하세요. 서로 덮어쓰는 임시 규칙이 쌓이지 않도록 합니다.

3. 서버 시간 초과와 속도 저하: 연결과 전송을 따로 확인

서버 시간 초과는 특정 테스트나 요청이 제한 시간 안에 완료되지 않았다는 뜻이지, 서버가 중단됐다는 증거는 아닙니다. 속도 저하는 DNS 확인, 핸드셰이크, 첫 바이트 수신, 지속 전송 중 어느 단계에서든 발생할 수 있습니다. Connectivity Test 결과가 나오지 않는지, 웹페이지가 오래 기다려도 열리지 않는지, 페이지는 열리지만 다운로드가 느린지 구체적으로 기록하세요. 단계마다 확인할 항목이 다르며 지연 시간 수치만으로 다운로드 속도를 판단할 수 없습니다.

서버 정보와 테스트 결과의 의미 확인

사용자가 이용 중인 서버의 정보 화면에서 주소, 포트, 프로토콜, 인증 필드를 하나씩 확인하세요. 서버 이름만 보고 지역이나 프로토콜을 판단하지 마세요. 이름은 단순한 메모일 수 있습니다. 복사 과정에서 공백, 누락된 문자, 잘못된 포트가 포함되지 않았는지도 살펴보세요. 구독에서 가져온 정보라면 원래 기록을 보존해 수동으로 수정한 서버와 다음 구독 업데이트 결과가 섞이지 않도록 하세요. 필요하면 전체 목록을 덮어쓰는 대신 같은 출처에서 비교용 항목 하나를 다시 가져오세요.

Connectivity Test 결과는 선택한 테스트 방식에 따라 해석해야 합니다. 테스트에 따라 연결 여부나 특정 대상만 확인할 수 있으므로 실제 서비스 요청을 대신할 수는 없습니다. 테스트는 시간 초과됐지만 웹페이지가 정상이라면 테스트 대상과 방식을 확인하세요. 사용 가능한 서버를 삭제할 필요는 없습니다. 테스트는 성공했지만 웹페이지가 열리지 않으면 대상 경로, 규칙, DNS를 계속 확인하세요. 테스트와 실제 요청의 대상이 다르면 결과가 달라도 모순이 아닙니다.

프로토콜 관련 필드를 함께 확인

Shadowsocks의 암호화 방식과 비밀번호는 서버 설정과 일치해야 합니다. VMess와 VLESS는 인증 정보 및 전송 설정이 서로 맞아야 하고, Trojan의 비밀번호와 TLS 관련 조건도 추측해서 입력하면 안 됩니다. 설정에 별도의 전송 경로, Host 또는 Server Name이 있다면 각 필드의 역할이 다르므로 이름이 비슷하다는 이유로 서로 바꾸지 마세요. 서버 주소는 연결 지점을 지정하지만 인증서 검증에 사용하는 이름은 다를 수 있으므로 사용자가 이용 중인 서비스에서 제공한 매개변수를 기준으로 해야 합니다.

인증서 또는 핸드셰이크 오류가 발생하면 기기 시간, 인증서에 지정된 이름, 매개변수를 직접 변경했는지부터 확인하세요. 오류를 숨기려고 인증서 검증을 끄지 마세요. 보안 조건이 달라지고 이후 결과를 비교하기도 어려워집니다. Hysteria2처럼 특정 전송 조건에 의존하는 프로토콜은 현재 네트워크도 함께 고려해야 합니다. 프로토콜 이름이 같다고 모든 서버의 포트, 인증 형식, 전송 옵션이 같다는 뜻은 아닙니다.

네트워크와 서버를 교차 비교

1. 대상과 서버를 동일하게 유지하고 Wi-Fi와 모바일 네트워크에서 각각 새 요청을 보내 결과를 기록하세요.
2. 네트워크는 그대로 두고 사용자의 기존 목록에서 다른 서버를 선택한 뒤 같은 대상에 요청을 보내세요.
3. 첫 접속, 페이지 리소스 로딩, 지속 전송을 각각 확인하세요. 세 단계를 한 가지 ‘속도’로 뭉뚱그리지 마세요.
4. 비슷한 시간대에 다시 테스트하고 백그라운드에서 대용량 파일을 동기화하는 작업을 종료해 기기 자체의 대역폭 사용을 배제하세요.

특정 네트워크에서만 실패한다면 해당 네트워크에서 서버까지의 경로, 무선 신호, 접속 제한을 우선 확인하세요. 특정 서버에서만 실패한다면 해당 서버와 서버 측 상태를 확인하는 편이 좋습니다. 여러 서버에서 동시에 실패해도 공통된 연결 지점이나 같은 매개변수를 사용하고 있을 수 있으므로 클라이언트 전체 문제로 단정할 수는 없습니다. 교차 테스트는 범위를 좁히는 방법이지, 어느 한쪽에 반드시 문제가 있다고 입증하는 방법은 아닙니다.

속도가 느려졌을 때 근거 없이 설정을 바꾸지 않기

먼저 클라이언트를 종료했을 때 같은 기기의 기본 전송 속도를 확인한 다음 프록시 경로에서 추가로 느려지는지 비교하세요. 무선 간섭, 모바일 신호, 서버 부하, 대상 사이트의 속도 제한, 백그라운드 동기화가 모두 영향을 줄 수 있습니다. 테스트 중 여러 대용량 작업을 동시에 실행하거나 요청을 계속 새로고침하지 마세요. 측정 조건이 달라지고 서버에 일시적인 제한이 걸릴 수 있습니다.

작은 웹페이지는 정상이지만 대용량 파일 전송이 멈춘다면 여러 대상에서도 문제가 재현되는지 기록한 뒤 현재 네트워크와 프로토콜의 전송 조건을 확인하세요. MTU 같은 매개변수는 패킷 전송에 영향을 주지만 모든 네트워크에 통용되는 값은 없습니다. 근거 없이 숫자를 연달아 바꾸지 마세요. 추가 지원이 필요하면 네트워크 종류, 프로토콜 유형, 실패 단계, 완료한 비교 테스트를 전달하되 비밀번호나 전체 구독 주소는 공유하지 마세요.

서버를 더 자세히 확인하는 방법은 지연 시간 테스트, 지역 및 프로토콜 유형을 참고하세요. 결과는 지연 시간 하나만 적는 대신 ‘이 네트워크와 서버 조합에서 같은 대상의 속도가 느려짐’처럼 작성하세요. 재현 가능한 조건은 일시적인 혼잡과 지속적인 설정 문제를 구분하는 데 도움이 되며, 관련 없는 변경을 일시적인 복구의 원인으로 오해하지 않도록 합니다.

4. 구독 업데이트 실패: 응답 내용부터 확인

구독 업데이트는 목록을 가져와 해석하는 작업이고, 서버 연결은 목록에 있는 항목을 사용하는 작업입니다. 업데이트에 실패했다고 저장된 서버가 모두 즉시 사용할 수 없게 되는 것은 아닙니다. 저장된 서버에 연결할 수 있다고 해서 구독 주소도 정상이라는 뜻은 아닙니다. 기존 목록을 보존하고 업데이트 안내, 실패 시간, 당시 네트워크 경로를 기록하세요. 한 번 업데이트에 실패했다고 설정을 모두 지우지 마세요. 삭제한 구독을 복구하려면 출처 정보를 다시 확인해야 할 수도 있습니다.

주소의 완전성과 응답 형식 확인

사용자가 이용 중인 서비스에서 구독 주소를 다시 복사해 시작 부분, 경로, 쿼리 매개변수가 모두 포함됐는지 확인하세요. 메신저, 줄바꿈, 수동 편집으로 주소 일부가 누락될 수 있습니다. 일부 화면은 주소를 줄여 표시하므로 생략된 표시를 전체 주소로 착각하지 마세요. 구독 주소에는 인증 정보가 포함되는 경우가 많으므로 비밀번호처럼 안전하게 보관해야 합니다. 공개 게시물, 온라인 분석 페이지, 타인이 제공한 검사 도구에 붙여 넣지 마세요.

개별 공유 링크와 구독 주소는 서로 다릅니다. ss://, vmess://, vless://, trojan://는 일반적으로 단일 서버 정보를 나타내며, 구독은 업데이트 가능한 항목 모음을 제공합니다. 단일 서버 정보를 잘못된 가져오기 화면에 입력하면 형식을 인식하지 못하거나 항목 하나만 가져올 수 있습니다. 차이는 공유 링크와 구독 링크 형식 안내에서 확인한 뒤 해당 화면에서 작업하세요.

실패한 단계에 따라 점검

HTTP 상태 정보가 있다면 상태 코드와 간단한 오류 유형을 보존하세요. 인증 실패, 과도한 요청, 서버 오류는 각각 다른 방법으로 처리해야 합니다. 클라이언트 DNS만 바꿔 모든 응답 오류를 해결할 수는 없습니다. 브라우저에서 주소가 열린다고 유효한 목록이 반환된다는 뜻도 아닙니다. 브라우저에 계정 로그인 페이지, 안내 페이지, 접속 거부 메시지가 표시될 수 있습니다. 이런 페이지를 저장해 서버 설정으로 가져오지 마세요.

업데이트 경로의 의존성 확인

현재 직접 연결 네트워크에서 구독 도메인에 접속할 수 없고, 선택된 서버도 이미 사용할 수 없는 경우 업데이트와 연결이 서로 의존할 수 있습니다. 기존 목록에 사용 가능한 서버가 남아 있는지 먼저 확인한 뒤 업데이트 요청이 어떤 경로를 사용하는지 살펴보세요. Global Routing을 전환하면 모든 업데이트 요청이 자동으로 같은 경로를 사용한다고 가정하지 마세요. 실제 설정과 이용 가능한 진단 정보, 결과를 함께 확인해야 합니다.

목록에 사용할 수 있는 서버가 없다면 주소를 노출하지 않도록 주의하면서 구독 출처에 접속 가능한 기존 네트워크로 전환하거나 서비스 제공처에 구독 상태를 문의할 수 있습니다. 출처를 알 수 없는 임시 서버를 찾아 업데이트에 사용하지 마세요. 수동 재시도 사이에는 간격을 두세요. 연속해서 요청해도 인증이나 형식 문제는 해결되지 않으며 요청 횟수 제한이 걸려 기존 오류와 새 제한이 겹칠 수 있습니다.

업데이트 후 목록도 확인

업데이트에 성공하면 먼저 서버 항목 수의 변화, 현재 선택, 프로토콜 필드를 확인한 뒤 기존 항목 하나로 대상 요청을 테스트하세요. 서비스 출처에서 이름, 연결 지점, 인증 정보가 변경됐을 수 있으며 기존 수동 선택이 더 이상 같은 항목을 가리키지 않을 수 있습니다. 서버 하나를 직접 수정했더라도 구독을 새로고침하면 변경 사항이 대체될 수 있습니다. 수동 메모, 구독 내용, 전체 Config는 별도로 관리해야 하며 하나의 백업으로 취급하면 안 됩니다.

구독 주소가 공개된 곳에 노출됐다면 원래 서비스 출처에 문의해 인증 정보를 변경한 뒤 클라이언트에 저장된 주소도 업데이트하세요. 채팅 메시지를 삭제해도 기존 주소가 무효화되는 것은 아닙니다. 점검 기록에는 필요한 도메인 부분, 오류 유형, 작업 순서만 남기세요. 전체 쿼리 매개변수를 스크린샷이나 공유 문서에 포함하면 안 됩니다. 문제가 해결됐는지 확인한 다음 자동 업데이트를 설정하세요. 원인이 불명확한 상태에서 백그라운드 요청을 반복하지 마세요.

5. DNS 문제: 확인 결과와 실제 연결 경로 점검

DNS는 도메인을 연결에 필요한 주소로 변환합니다. 도메인이 열리지 않거나 첫 로딩이 느리고 일부 리소스만 실패하는 경우 DNS가 원인일 수 있지만 TLS, 대상 서비스, 규칙 문제일 수도 있습니다. 오류가 주소 확인 전인지 후인지 먼저 살펴보세요. 주소를 받은 뒤에도 시간 초과가 발생한다면 DNS만 계속 확인해서는 안 됩니다. 주소 확인에 성공했다는 것은 연결 후보 주소를 얻었다는 뜻일 뿐, 현재 네트워크와 라우팅 조건에서 해당 주소에 접속할 수 있다는 뜻은 아닙니다.

도메인, 주소, 규칙을 구분해 기록

사이트 이름만 적지 말고 실패한 전체 호스트 이름을 기록하세요. 한 서비스에서도 로그인, 이미지, API에 서로 다른 도메인을 사용할 수 있습니다. 메인 페이지는 열리지만 이미지가 실패한다면 완전히 다른 요청일 수 있습니다. 진단 기록에 DNS 결과가 표시되면 주소 유형과 발생 시간도 함께 기록하세요. 전체 URL의 인증 매개변수를 공개하지 말고, 확인을 위해 신뢰할 수 없는 DNS 서비스에 사설 내부 도메인을 보내지 마세요.

현재 Config에서 사용자 지정 DNS, 도메인 매핑, DNS 관련 옵션이 설정되어 있는지 확인하세요. 먼저 적용 중인 파일을 확인한 다음 규칙을 살펴보세요. 비활성 사본만 수정해도 요청 결과는 바뀌지 않습니다. 원격 설정을 사용한다면 업데이트가 로컬 설정을 대체했는지도 확인해야 합니다. 비교를 위해 원본 파일을 보존하고 DNS 항목 하나만 수정하세요. 여러 항목을 한꺼번에 바꾸면 접속이 복구되더라도 어떤 변경이 효과가 있었는지 알 수 없습니다.

규칙이 DNS 확인을 유발하는 이유 이해

DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD는 도메인 정보를 기준으로 일치 여부를 확인합니다. IP-CIDR, IP-CIDR6, GEOIP는 주소 범위 또는 주소 지역 정보를 사용합니다. 도메인 요청이 주소 기반 규칙과 비교될 때는 특정 설정 조건에서 먼저 DNS 확인이 필요할 수 있습니다. 이 점을 알면 ‘규칙은 맞아 보이는데 첫 요청이 느린’ 상황을 설명할 수 있습니다. 기다림이 프록시 연결 단계가 아니라 주소 판별 단계에서 발생할 수 있습니다.

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

예시의 no-resolve는 해당 주소 규칙만을 위해 도메인을 적극적으로 확인하지 말라는 뜻입니다. 모든 DNS를 끄거나 모든 도메인을 특정 경로로 보내는 기능은 아닙니다. DNS 서버에 접속할 수 없는 문제를 해결하지 못하며 LAN 이름이 확인되도록 보장하지도 않습니다. 예시 규칙은 문법 관계를 보여줄 뿐입니다. 실제 적용 시 기존 규칙 순서, 내부 네트워크 범위, 대상 서비스를 고려해야 하며 전체 예시를 만능 해결책으로 사용하지 마세요.

IPv4, IPv6 및 네트워크 전환

하나의 도메인이 여러 주소를 반환할 수 있으며 현재 네트워크에서 IPv4와 IPv6의 접속 가능 여부가 다를 수 있습니다. 특정 Wi-Fi에서만 실패한다면 해당 네트워크의 주소 환경을 기록하고 다른 네트워크와 비교하세요. IPv6를 끈 뒤 한 번 접속이 복구됐다고 해서 모든 환경에서 IPv6를 꺼야 한다고 결론 내리지 마세요. 주소 선택이나 해당 경로를 추가로 확인해야 한다는 신호일 뿐입니다. 시스템 네트워크 조건을 바꾸기 전에 원래 값을 저장하고 복구 방법을 확인하세요.

Wi-Fi와 모바일 네트워크는 DNS 조건이 다를 수 있으며, 전환 후에도 캐시와 기존 연결이 유지될 수 있습니다. 매번 새 요청을 보내 비교하고 필요하면 대상 앱을 종료한 뒤 다시 여세요. 새로고침을 연속으로 눌러도 DNS 확인이 새로 실행된다는 보장은 없습니다. 주소창에 IP를 직접 입력하는 방식으로 모든 검증을 대신하지 마세요. HTTPS 인증서, 가상 호스트, 서비스 라우팅은 대개 도메인에 의존하므로 IP 주소로 접속되거나 실패한 결과가 오해를 일으킬 수 있습니다.

내부 도메인 및 캐시 범위

가정용 라우터, 회사 네트워크, LAN 서비스에서는 로컬 네트워크에서만 확인 가능한 도메인 이름을 사용할 수 있습니다. 다른 DNS 서버로 바꾸면 해당 내부 이름을 확인할 수 없게 되어 외부 사이트는 정상인데 로컬 서비스만 문제가 생길 수 있습니다. 먼저 기기가 같은 LAN에 연결되어 있는지, 해당 도메인에 로컬 DNS가 필요한지 확인하세요. 내부 도메인 오류를 PROXY 규칙 범위를 넓히는 방식으로 간단히 처리하지 마세요. 프록시 경로에서 해당 사설 주소에 접속할 수 있다는 보장은 없습니다.

브라우저, 앱, 시스템, 클라이언트가 각자 일부 데이터를 캐시할 수 있습니다. 설정을 바꾼 뒤에는 ‘기존 연결이 계속 작동하는 것’과 ‘새 요청이 복구된 것’을 구분해야 합니다. 테스트를 마친 뒤 처음 실패한 대상에 다시 요청하고 실제로 적용된 경로를 확인하세요. 특정 DNS 조건에서만 안정적으로 복구된다면 해당 조건과 적용 가능한 네트워크를 기록하세요. DNS 주소를 모든 기기에 그대로 적용하지 마세요. 설정이 올바른지는 현재 네트워크에서 실제 요청을 보내 확인해야 합니다.

6. 배터리 및 데이터 사용량 이상: 지속 활동의 원인 확인

배터리 소모 증가를 판단하려면 먼저 비교 조건을 마련해야 합니다. 기기 온도, 화면 밝기, 신호 강도, 백그라운드 동기화, 실제 데이터 전송량이 모두 배터리에 영향을 줍니다. 한 번 배터리가 줄었다고 Shadowrocket 문제라고 판단하지 마세요. 시스템 배터리 통계에서 같은 시간대의 활동을 확인하고 당시 파일 다운로드, 미디어 재생, 잦은 네트워크 전환이 있었는지 기록하세요. 날짜가 달라지면 사용 시간과 데이터 사용량도 다를 수 있으므로 결과를 직접 비교할 수 없습니다.

데이터 사용량과 활동 발생 주체 구분

프록시 연결은 다른 앱의 데이터를 전달합니다. 시스템 통계의 집계 방식에 따라 일부 네트워크 활동이 관련 프로세스에 집중되어 표시될 수 있습니다. 그렇다고 클라이언트가 같은 양의 요청을 직접 생성했다는 뜻은 아닙니다. 사진 백업, 파일 동기화, 앱 업데이트, 미디어 자동 재생이 실행 중인지 확인하고 해당 작업을 멈춘 뒤 데이터 사용량이 줄어드는지 살펴보세요. 통계 순위 하나만으로 실제 요청을 시작한 앱을 알 수는 없습니다.

화면에 Data 또는 연결 기록이 표시된다면 활동이 지속되는지 확인할 수 있지만, 집계 기준과 초기화 시점이 시스템 통계와 다를 수 있다는 점에 유의하세요. 누적 데이터 사용량, 실시간 속도, 특정 앱의 백그라운드 활동은 서로 다른 지표입니다. 점검을 시작하기 전에 초기 상태를 기록하고 일정한 시간 동안 관찰한 뒤 변화를 비교하세요. 누적값을 현재 순간의 전송량으로 보거나 관찰 시간이 다른 수치를 근거로 이상을 주장하지 마세요.

반복 연결 및 재시도 확인

신호가 약하거나 네트워크 전환이 잦거나 서버가 불안정하면 앱이 연결을 반복해서 시도할 수 있습니다. 페이지가 열리지 않아도 백그라운드에서 핸드셰이크, DNS 확인, 재시도가 계속될 수 있습니다. 신호가 안정적인 네트워크에 고정하고 사용자가 보유한 정상 서버 하나를 선택한 뒤 유휴 상태에서도 반복 활동이 많은지 확인하세요. 네트워크를 전환할 때만 문제가 발생한다면 모든 프로토콜 설정을 바로 바꾸기보다 전환 순서와 자동 연결 조건을 기록하세요.

On Demand는 조건에 따라 연결을 시작하는 기능이며 모든 상황에서 같은 방식으로 연결해야 한다는 뜻은 아닙니다. 잠시 끄고 수동으로 연결하면 연결이 계속 시작되고 종료되는 반복이 있는지 확인하는 데 도움이 됩니다. 테스트 전에 원래 조건을 기록하고 끝난 뒤 복원하세요. 결론을 얻으려고 스위치를 오랫동안 반복해서 조작하지 마세요. 스위치 조작 자체가 연결 활동을 만들고 백그라운드 앱에서 새 요청을 유발할 수 있습니다.

재현 가능한 유휴 상태 비교

1. 대용량 파일 작업을 끝내고 화면 밝기와 네트워크를 동일하게 유지한 뒤 일반 사용 상태를 기록하세요.
2. 설정을 저장하고 정상 작동이 확인된 서버 하나를 사용하세요. 불필요한 수동 테스트는 잠시 중단합니다.
3. 화면을 잠근 뒤 시스템 통계의 백그라운드 활동을 관찰하고 네트워크 전환이나 푸시 알림이 집중된 시간대가 있는지 기록하세요.
4. 클라이언트를 종료한 상태에서도 같은 방식으로 관찰해 현상이 계속되는지 비교하세요. 결과를 다른 네트워크 환경에 그대로 적용하지 마세요.

비교하는 동안 구독을 업데이트하거나 규칙을 바꾸거나 Connectivity Test를 대량으로 실행하지 마세요. 테스트 요청 자체가 네트워크 활동을 만들며, 집중적인 테스트는 유휴 상태를 유지하기 어렵게 합니다. 자동 업데이트 기능을 사용한다면 업데이트 간격이 실제 필요에 맞는지 확인하세요. 목록이 유효한지 확인하려고 계속 수동 새로고침을 할 필요는 없습니다. 업데이트에 실패하면 먼저 원인을 확인하세요. 반복 재시도는 문제를 해결하지 못한 채 백그라운드 활동만 늘릴 수 있습니다.

온도, 충전 및 연결 조건

충전, 시스템 백업 복원, 인덱스 정리, 부하가 큰 앱도 기기를 뜨겁게 만들 수 있습니다. 과열이 뚜렷하다면 먼저 부하가 큰 작업을 중단하고 기기가 정상 작동 온도로 돌아올 때까지 기다린 뒤 점검하세요. 충전하면서 연속 다운로드해 클라이언트의 배터리 사용량을 비교하지 마세요. 네트워크 신호가 약하면 연결을 유지하는 데 더 많은 전력이 들 수 있습니다. 이때 안정적인 네트워크로 바꿔 개선된 결과를 특정 규칙의 효과로 잘못 기록하지 마세요.

클라이언트를 종료한 뒤에도 과열이나 급격한 배터리 소모가 계속되면 시스템과 다른 앱을 확인하세요. 특정 설정, 서버, 자동 연결 조건에서만 재현된다면 해당 최소 조건을 저장하세요. 통계 수치를 낮추려고 인증서 검증을 끄거나 필요한 규칙을 임의로 삭제하지 마세요. 신뢰할 수 있는 해결 결과라면 정상 요청이 완료되고, 유휴 상태의 활동이 줄며, 원래 설정으로 되돌렸을 때 문제를 설명할 수 있어야 합니다.

7. 업데이트 후 문제: 변경 사항을 확인하고 성급히 원인으로 단정하지 않기

‘업데이트 후 발생’은 시간 순서를 설명할 뿐 업데이트가 원인이라는 뜻은 아닙니다. 앱 업데이트, 시스템 업그레이드, 구독 새로고침, 원격 Config 변경, 서버 조정이 비슷한 시기에 있었을 수 있습니다. 먼저 해당 변경 사항을 나열하고 확인된 내용과 추측을 구분한 뒤 문제 발생과 가장 가까운 작업부터 확인하세요. 기억에 의존해 버전 번호나 업데이트 시각을 적지 말고, 네트워크가 우연히 복구된 것을 원인을 찾았다는 증거로 보지 마세요.

변경 전후 상태 보존

작업 전에 현재 Config를 내보내고 사용자의 구독 출처, 선택된 서버, Global Routing을 기록하세요. 백업 파일에 서버 인증 정보가 포함될 수 있으므로 본인이 관리하는 안전한 위치에 보관해야 합니다. 업데이트 전 백업이 있다면 규칙 순서, 정책 대상, DNS, 프로토콜 필드를 비교하세요. 처음부터 기존 파일을 덮어쓰지 마세요. 현재 상태도 원인 파악에 중요한 증거이므로 덮어쓰면 재현하지 못할 수 있습니다.

먼저 기본 경로를 확인하세요. 클라이언트를 종료했을 때 직접 인터넷에 연결되는지, 수동 연결이 유지되는지, Proxy로 고정된 대상에 접속되는지, Config에서 결과가 달라지는지 점검합니다. 간단하고 동일한 테스트를 사용해 업데이트 후 문제를 권한, 서버, 규칙, DNS 중 해당하는 단계로 다시 분류하세요. 업데이트 전 기록이 충분하지 않더라도 ‘새 버전이 문제’라고 추측하는 대신 실제 실패 지점을 확인할 수 있습니다.

Config 업데이트와 앱 업데이트 구분

구독 업데이트는 서버 매개변수를 바꿀 수 있고 원격 Config 업데이트는 규칙과 정책을 조정할 수 있습니다. 앱 업데이트가 함께 필요한 것은 아닙니다. 원격 내용이 로컬에서 직접 수정한 항목을 덮어썼는지, 현재 적용 중인 파일이 바뀌었는지, 이전에 선택한 정책 그룹에 같은 항목이 남아 있는지 확인하세요. 서버 하나만 다시 선택해 작동한다면 해당 서버 정보를 계속 비교하세요. 출처를 알 수 없는 내용으로 Config 전체를 교체하지 마세요.

시스템 업그레이드 후에는 VPN 권한, 네트워크 연결 기록, 관련 자동 연결 조건도 다시 확인하세요. 시스템에서 명확한 권한 승인을 요청하면 안내에 따라 승인합니다. 연결 상태만 일치하지 않는 경우에는 먼저 연결을 끊고 수동으로 한 번 연결해 보세요. 시스템 연결 기록을 다시 만들기 전에 백업하고, Shadowrocket에 속한다고 확인된 항목만 처리하세요. 모든 네트워크 설정을 삭제하면 영향 범위가 커지므로 첫 점검 방법으로 적절하지 않습니다.

재설치 전에 복구 가능 여부 확인

재설치는 백업 방법이 아닙니다. 앱을 삭제하기 전에 Config, 구독, 필요한 서버 정보를 복원할 수 있는지, 어떤 항목이 로컬에만 저장되어 있는지 확인하세요. 내보낸 파일을 읽을 수 있는지 확인하고 수동 규칙과 서버 메모를 기록하세요. 구매 기록이 앱 설정까지 자동으로 복원된다고 가정하지 마세요. 특정 대상 하나만 접속되지 않는다면 먼저 해당 대상과 규칙을 점검하세요. 앱 전체를 삭제할 필요가 없는 경우가 많습니다.

설치 파일이 필요하면 다운로드 페이지의 플랫폼별 안내를 이용하세요. iPhone / iPad 버전은 App Store에서 받을 수 있으며 시스템 요구 사항은 App Store 페이지를 기준으로 합니다. Mac, Windows, Android, Linux 버전은 이 사이트의 설치 파일 링크를 이용하세요. iPhone / iPad 버전은 $2.99 일회성 결제이며 그 밖의 위 플랫폼 버전은 무료입니다. 앱 다운로드와 사용자가 이용 중인 서버 서비스 상태를 혼동하지 마세요.

재설치 시 시스템에서 실행 허용

데스크톱 및 Android 설치 파일은 코드 서명이 되어 있지 않아 처음 실행할 때 시스템이 차단할 수 있습니다. 파일이 이 사이트에서 제공된 것인지 확인한 뒤 Windows에서는 SmartScreen의 ‘추가 정보’에서 ‘실행’을 선택하세요. macOS에서는 ‘개인정보 보호 및 보안’에서 차단된 항목을 확인하고 ‘그래도 열기’를 선택하세요. Android에서는 시스템 안내에 따라 현재 출처의 알 수 없는 앱 설치를 허용하고, 설치가 끝나면 해당 출처의 설치 권한을 해제할 수 있습니다. 시스템에 따라 표시 문구가 조금 다를 수 있으니 실제 파일을 확인한 뒤 진행하세요.

macOS에서 앱이 손상됐다는 안내가 나오면 먼저 설치 파일이 완전하고 출처가 올바른지 확인한 뒤 설치 허용 안내에 따라 격리 속성을 확인하세요. Linux는 배포판과 패키지 형식에 맞게 설치 결과를 점검해야 하며 AppImage에는 실행 권한이 필요합니다. 파일을 실행하려고 시스템 보호를 전역으로 끄지 마세요. 실행 차단 문제와 연결 후 요청 실패는 서로 다른 단계에서 발생하므로 별도로 확인해야 합니다.

다시 확인할 수 있는 결론 작성

문제가 해결된 뒤 처음 실패했던 동작을 다시 실행하고 대상 요청, 규칙 일치, 네트워크 전환이 예상대로 작동하는지 확인하세요. 실제로 효과가 있었던 변경 사항, 예를 들어 유효한 서버를 다시 선택했거나 덮어쓴 규칙을 복원했거나 권한을 승인한 내용을 기록하세요. ‘재설치로 해결’이라고만 적지 마세요. 여전히 실패한다면 몇 단계로 재현할 수 있도록 작업을 간단히 정리하고 민감한 정보를 가린 오류 내용을 첨부하세요. 버전 정보는 앱 화면에서 확인하고 기억에 의존해 기록하지 마세요.

8. iPad 문제 해결: 구매 복원, 기기 이전, 가로 화면 확인

iPad 연결 문제도 권한, 서버, 규칙, DNS 순서로 점검합니다. 다만 구매 복원, 가로 화면 레이아웃, 설정 이전에서 혼동이 생기기 쉽습니다. 먼저 iPad에 Shadowrocket이 실제로 설치되어 있는지 확인한 뒤 Home에서 선택한 서버, 현재 Config, Global Routing을 확인하세요. 다른 기기에서 연결된다고 이 기기의 조건도 같다고 가정하지 마세요. 네트워크, 권한, 설정 사본, 연결 기록이 서로 다를 수 있습니다.

구매 복원과 설정 복원은 별개의 작업

iPhone / iPad 버전은 App Store에서 $2.99 일회성 결제로 제공되며 Mac, Windows, Android, Linux 버전은 무료입니다. iPhone / iPad 버전을 구매한 사용자는 App Store에서 구매 당시 계정으로 로그인한 뒤 구입 항목에서 다시 다운로드할 수 있습니다. 실제 다운로드 가능 여부는 App Store 기록을 기준으로 확인하세요. 앱 구매 자격이 구독, 서버, Config까지 자동으로 이전된다는 뜻은 아닙니다. 설치 후에도 로컬 데이터를 확인해야 합니다.

App Store에서 개발자 Shadow Launch Technology Limited, 공식 아이콘, 앱 ID 932747118을 확인하세요. 시스템 요구 사항은 App Store 페이지를 기준으로 합니다. 앱을 찾을 수 없다면 계정의 App Store 지역과 구입 항목을 먼저 확인하세요. 검색 결과에 표시되지 않는 문제를 클라이언트 연결 오류로 혼동하지 마세요. 같은 계정의 구매 및 화면 구성 안내는 iPad 공유 구매 및 가로 화면 인터페이스 차이를 참고하세요.

가로 화면 분할 보기에서 실제 선택 항목 확인

가로 화면 또는 분할 보기에서는 목록 선택과 오른쪽 상세 화면이 함께 표시될 수 있습니다. 특정 서버의 상세 정보가 보인다고 현재 연결에 해당 서버가 선택된 것은 아닙니다. Config 내용을 열어 봤다고 해당 파일이 적용 중인 것도 아닙니다. 수정한 뒤 연결 화면으로 돌아가 현재 선택 항목을 다시 확인하고 실제 요청으로 검증하세요. 상세 화면이 열려 있다는 이유만으로 어떤 서버나 규칙 파일이 사용 중인지 추측하지 마세요.

분할 화면, 창 크기, 시스템 디스플레이 설정에 따라 보이는 영역이 달라집니다. 버튼을 찾기 어렵다면 먼저 앱을 전체 화면으로 전환해 위치를 확인한 다음 원래 사용 방식으로 돌아가세요. 작업이 끝나기 전에 목록 항목을 연속으로 누르지 마세요. 특히 편집, 선택, 연결 동작이 서로 다른 영역에 있을 수 있습니다. 점검 기록에는 스크린샷의 한 열만 적지 말고 어떤 항목을 눌렀는지, 어디에 저장했는지, 마지막에 연결 화면에 어떤 상태가 표시됐는지 작성하세요.

데이터 유형별로 이전한 뒤 단계별 확인

이전하기 전에 서버 또는 구독, Config, 수동 규칙, 필요한 메모가 각각 저장되어 있는지 확인하세요. 전체 Config와 개별 공유 링크는 포함하는 범위가 다릅니다. 서버 하나를 가져와도 모든 규칙이 함께 이전되는 것은 아닙니다. 앱에서 제공하는 가져오기 및 내보내기 기능을 우선 사용하고 본인이 관리하는 기기 사이에서 전송하세요. 전송 파일이나 QR 코드에 인증 정보가 포함될 수 있으므로 공개 사진 앨범, 공유 문서, 공개 채팅에 보관하지 마세요.

iPad에서 먼저 사용자가 보유한 정상 서버 하나를 가져와 Proxy로 고정된 대상에 접속되는지 확인한 다음 이전할 Config를 활성화하세요. 이렇게 하면 서버 사용 가능 여부와 규칙 문제를 구분할 수 있습니다. 여러 설정을 한꺼번에 가져오고 자동 연결까지 켜면 실패 시 원인을 찾기 어렵습니다. 테스트가 성공한 다음 나머지 항목을 추가하고 구독 업데이트가 수동 변경 사항을 덮어쓰는지 확인하세요.

같은 Wi-Fi에서도 네트워크 조건 비교

두 기기에 같은 무선 네트워크 이름이 표시되더라도 권한이나 연결 경로가 같다는 보장은 없습니다. 게스트 네트워크 격리, LAN 접근 권한, 주소 유형, 캐시가 다를 수 있습니다. 가정용 저장 장치나 LAN 서비스에 접속하지 못하면 기기가 연결된 네트워크, 관련 권한, 대상 주소를 먼저 확인한 뒤 DIRECT 규칙을 살펴보세요. iPad에 모바일 데이터 기능이 없다면 비교를 위해 다른 네트워크가 있다고 가정하지 마세요. 접속할 수 있는 다른 Wi-Fi를 이용해 비교할 수 있습니다.

잠금 해제 후 실패한다면 잠금 해제 시 네트워크가 변경됐는지, 자동 연결이 다시 실행됐는지, 기존 앱 연결이 재사용됐는지 기록하세요. 요청을 새로 보내고 시스템 VPN 상태를 확인하세요. 이전된 데이터를 전부 삭제하지 마세요. 특정 앱에서만 문제가 생기면 2장으로 돌아가 해당 앱이 사용하는 도메인을 확인하세요. 모든 새 요청이 실패한다면 1장과 5장에 따라 권한 및 DNS 조건을 다시 점검하세요.

그래도 원인을 찾지 못했다면 민감한 정보를 가린 점검 기록을 정리하세요. 기기 종류, 네트워크 유형, 실패 단계, 오류 문구, 클라이언트를 종료했을 때의 결과, 조건을 하나씩 바꿔 비교한 내용을 포함합니다. 전체 구독 주소, QR 코드, 비밀번호는 첨부하지 마세요. 이 정보를 가지고 해당 장을 다시 확인하는 편이 전체 설정을 다시 가져오는 것보다 원인을 좁히기 쉽습니다. 첫 연결 절차를 아직 완료하지 않았다면 사용 가이드로 돌아가 단계별로 확인하세요.