Shadowrocket
문제 해결 가이드

연결 스위치가 켜지지 않거나 연결이 바로 중단됨

먼저 두 가지 증상을 구분하세요. Home에서 연결 스위치를 눌러도 연결 상태로 바뀌지 않는 경우와, 연결된 뒤 몇 초 만에 자동으로 끊기는 경우입니다. 전자는 시스템 권한, 기기 제한, 설정 유효성을 먼저 확인하고, 후자는 다른 VPN 설정, On Demand 조건, 네트워크 전환도 점검해야 합니다. 스위치를 누른 뒤 표시된 안내 문구, 시스템 확인 창이 나타났는지, 스위치가 언제 원래대로 돌아오는지 기록하세요. 단순히 ‘켜지지 않는다’는 이유만으로 서버 문제라고 단정할 수 없습니다. 시스템에서 로컬 VPN 세션을 만들지 못한 상태라면 서버를 계속 바꿔도 해결되지 않는 경우가 많습니다.

시스템 권한과 기기 제한 확인

처음 연결할 때 시스템에서 VPN 설정 추가를 허용하고 기기 암호나 시스템 인증으로 확인하도록 요청할 수 있습니다. 현재 실행 중인 Shadowrocket에서 표시한 요청인지 확인한 뒤 진행하세요. 방금 취소했다면 앱으로 돌아가 연결을 다시 시도하고 권한 요청이 다시 나타나는지 확인합니다. 시스템 Settings의 VPN 관리 화면에서 해당 설정이 있는지도 확인하세요. 메뉴 이름과 위치는 시스템 버전에 따라 다를 수 있으므로 시스템 설정 검색을 이용해도 됩니다. 설정이 표시된다는 것은 시스템에 연결 정보가 저장됐다는 뜻일 뿐, 서버 인증이 성공했다는 의미는 아닙니다.

기기가 회사나 학교의 관리 대상이라면 관리 정책에 따라 VPN 설정 변경이 제한될 수 있습니다. 관리 관련 안내가 있는지 확인하고 기기 관리자에게 허용된 사용 방법을 문의하세요. 익숙하지 않은 관리 설정은 삭제하지 마세요. 개인 기기에서도 다른 VPN 서비스가 연결 중인지 확인해야 합니다. 해당 서비스의 설정에서 먼저 연결을 중지한 다음 Shadowrocket을 테스트하세요. 점검 전 상태를 기록해 업무용 네트워크 설정을 실수로 지우지 않도록 합니다. 시스템 설정의 스위치도 즉시 꺼진다면 규칙을 계속 수정하기보다 시스템 안내 문구를 먼저 확인하세요.

최소한의 변경으로 설정 문제와 자동 연결 구분

On Demand를 잠시 끄고 기존 조건을 기록하세요. 네트워크가 바뀐 뒤 자동으로 다시 연결되면 ‘수동으로 끊어도 다시 연결되는’ 현상이 스위치 오류처럼 보일 수 있습니다. 그런 다음 Home에서 필요한 서버가 선택되어 있는지, 서버 정보가 빠짐없이 입력됐는지 확인하고 Config에서 현재 설정 파일을 정상적으로 읽을 수 있는지 살펴보세요. 설정을 수정한 직후 문제가 생겼다면 먼저 파일을 복사한 뒤 마지막으로 정상 작동한 사본을 복원하세요. 확인하지 않은 큰 설정 내용을 유일한 사본에 덮어쓰지 마세요. 규칙, DNS, 재작성 설정은 각각 따로 복원해야 연결에 영향을 준 항목을 찾을 수 있습니다.

현재 작업을 마친 뒤 앱을 닫았다가 다시 열어 한 번 더 시도하세요. 그래도 실패하면 작업 내용을 저장한 다음 기기를 재시동해 일시적인 시스템 네트워크 확장 상태 문제인지 확인할 수 있습니다. 재시동은 서버 문제를 해결하는 방법이 아닙니다. 재시동 후 잠시만 정상 작동한다면 Wi-Fi에서 셀룰러 네트워크로 전환할 때, 화면을 잠갔다가 다시 켰을 때, 또는 다른 VPN 서비스가 연결을 시작할 때처럼 문제를 유발하는 조건을 계속 찾아야 합니다. 각 조건을 따로 테스트하고 발생 시각과 증상을 기록해 서로 다른 문제를 한데 묶지 마세요.

복구 상태가 안정적인지 확인

스위치가 계속 켜져 있으면 평소 이용하는 웹사이트에 접속한 다음 화면을 잠갔다가 다시 열어 재접속해 보세요. 스위치 색상만 보고 실제 요청을 보내지 않으면 ‘세션은 연결됐지만 인터넷이 되지 않는’ 문제를 놓칠 수 있습니다. 스위치는 안정적으로 켜져 있는데 웹페이지가 열리지 않는다면 다음 장을 확인하세요. 시스템 권한 오류가 다시 나타나면 안내 문구를 기록하고 기기 권한을 확인합니다. 앱을 다시 받아야 한다면 구입 항목 복원 안내를 따르세요. 앱 업데이트와 복원은 App Store에서 진행하며, 시스템 요구 사항은 App Store 페이지를 기준으로 확인하세요.

문제를 다른 사람에게 설명할 때는 ‘수동 연결 직후 중단’인지 ‘네트워크 전환 후 중단’인지 구체적으로 적고 시스템 안내 문구도 요약해 첨부하세요. 설정 이름, 네트워크 종류, On Demand 사용 여부를 기록하면 같은 상황을 재현하는 데 도움이 됩니다. 서버 암호, 구독 주소, 인증 정보가 보이는 화면은 공개하지 마세요. 이 기록은 나중에 비교할 기준이기도 합니다. 같은 네트워크와 같은 조건에서 다시 테스트해야 해결 여부를 확인할 수 있습니다.

연결됨으로 표시되지만 웹이나 앱에서 인터넷을 사용할 수 없음

연결 표시는 시스템 VPN 세션이 만들어졌다는 뜻이지 모든 요청이 목적지까지 도달한다는 뜻은 아닙니다. 요청 처리에는 DNS, 규칙 매칭, 서버 연결, 대상 사이트의 응답이 포함될 수 있습니다. 먼저 Shadowrocket 연결을 잠시 끊고 같은 웹페이지에 접속해 보세요. 연결을 끊어도 열리지 않는다면 Wi-Fi 로그인 인증, 셀룰러 데이터 권한, 라우터, 대상 사이트 상태를 먼저 확인하세요. 공용 Wi-Fi는 시스템 인증 페이지에서 먼저 로그인해야 할 수 있습니다. 기본 네트워크가 인터넷에 연결되지 않은 상태에서 PROXY나 DIRECT 규칙을 바꾸면 확인할 변수만 늘어납니다.

Global Routing으로 문제 범위 확인

기존 Global Routing 설정을 기록한 뒤 짧게 바꿔가며 비교하세요. Config는 현재 설정 파일의 규칙에 따라 요청을 처리합니다. Proxy는 일반 요청을 선택한 프록시 경로로 보내는 데 사용합니다. Direct는 기본 네트워크를 확인할 때 사용합니다. 이 세 가지는 점검을 위한 설정이지 서로 다른 서버가 아닙니다. 시스템 트래픽, 설정 파일의 별도 처리, 기능별 동작이 결과에 영향을 줄 수 있으므로 한 번의 비교로 모든 요청의 경로를 단정하지 마세요. 설정을 바꿀 때마다 캐시된 페이지를 보는 데 그치지 말고 새 요청을 보내야 합니다.

Proxy에서는 접속되지만 Config에서는 실패한다면 현재 실제로 사용 중인 설정을 열어 대상 도메인에 어떤 규칙이 먼저 적용되는지 확인하세요. 구체적인 규칙보다 범위가 넓은 규칙이 위에 있거나, 정책이 이미 사라진 이름을 가리키거나, REJECT 규칙이 앱에 필요한 리소스를 차단하는 경우가 흔합니다. 홈페이지 도메인만 검색하지 마세요. 앱을 열면 인증, 이미지, API 등 여러 도메인에 요청할 수 있습니다. 요청 기록에서 실제 실패 항목을 확인하는 편이 모든 트래픽을 계속 Proxy로 보내는 것보다 원인을 찾는 데 도움이 됩니다.

키워드만 찾지 말고 규칙 순서 확인

아래 예시는 매칭 순서를 설명하기 위한 것이며 사용자의 전체 설정을 대신할 수 없습니다. 규칙은 일반적으로 위에서 아래로 확인하고, 먼저 일치한 규칙이 요청 처리를 결정합니다. 앞선 규칙에 해당하지 않는 요청은 FINAL에서 처리합니다. 예시의 사설 네트워크 대역은 LAN 직접 연결을 설명하기 위한 것으로, 실제 기기 네트워크와 설정 요구 사항도 확인해야 합니다. IP 판정 규칙은 도메인 해석과 관련될 수 있으므로 완전히 독립된 설정으로 취급하지 마세요.

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

Config와 Proxy에서 모두 실패하지만 Direct에서는 정상이라면 선택한 서버와 프록시 경로를 먼저 확인하세요. 한 사이트만 실패한다면 대상 서비스 오류, 부적절한 DNS 응답, 잘못된 규칙 매칭, 서버 측 접근 거부를 차례로 구분해야 합니다. 브라우저에서 열린다고 다른 앱도 정상이라고 단정할 수 없습니다. 앱마다 사용하는 도메인, 연결 방식, 캐시가 다를 수 있습니다. 서로 관련 없는 웹사이트 두 곳과 자주 쓰는 앱 하나를 비교하면 단일 서비스 문제를 전체 네트워크 장애로 오해하지 않을 수 있습니다.

기존 설정을 복원하고 실제 요청 확인

점검을 마친 뒤 원래 Global Routing 설정을 복원하고 필요성이 확인된 규칙만 남기세요. 다시 연결한 다음 새 요청을 보내 웹페이지 본문과 관련 리소스가 모두 로드되는지 확인하고, 로그인이나 이미지 업로드처럼 이전에 실패했던 동작도 테스트합니다. 문제가 계속되면 도메인, 적용된 규칙과 정책, 오류 유형을 기록하고 규칙 라우팅 안내에서 의미를 확인하세요. 예외 규칙을 한꺼번에 많이 추가하지 마세요. 임시 Direct 설정도 확인된 대상에만 적용해 다른 요청의 처리 경로를 바꾸지 않도록 합니다.

‘도메인은 열리지 않지만 테스트 결과는 표시되는’ 경우에는 라우팅 설정만 계속 바꾸지 말고 DNS 문제 장을 확인하세요. 연결 테스트와 실제 웹페이지 접속은 서로 다른 경로를 확인합니다. 테스트가 성공해도 테스트에서 확인한 구간만 정상이라는 의미입니다.

서버 시간 초과, 연결 거부 또는 프로토콜 핸드셰이크 실패

오류 유형을 먼저 기록한 뒤 서버 정보를 확인하세요. 시간 초과는 테스트 대기 시간 안에 예상한 응답을 받지 못했다는 뜻이며, 기본 네트워크, 서버 포트, 프로토콜 핸드셰이크, 대상 요청 단계에서 발생할 수 있습니다. 연결 거부는 대상 포트에서 연결을 받아들이지 않는 경우에 더 가깝고, 인증 실패라면 인증 정보를 먼저 확인해야 합니다. 테스트 방법에 따라 결과의 의미가 다르므로 서로 바꿔 해석할 수 없습니다. Connectivity Test 결과는 테스트 방법과 함께 기록하세요. 숫자 하나만으로 모든 프로토콜 기능이 정상이라고 판단할 수 없습니다.

잘못된 항목 선택과 주소 오류부터 확인

Home으로 돌아가 현재 선택된 서버를 확인하세요. 최근에 열어 본 편집 화면만 확인해서는 안 됩니다. 구독 업데이트 후 이름이 비슷한 항목이 생기거나 이전 항목이 목록에 남아 있을 수 있습니다. 해당 항목의 편집 정보를 열고 프로토콜, 서버 도메인, 포트를 각각 비교하세요. 복사할 때 들어간 공백이나 전각 기호, 서버 주소 입력란에 전체 공유 링크를 잘못 넣지 않았는지도 확인합니다. 도메인과 포트는 서로 다른 역할을 하므로 각각의 입력란에 맞게 입력해야 합니다. 이름에 적힌 지역이나 메모만 보고 실제 연결 주소를 판단하지 마세요.

같은 항목이 Wi-Fi에서는 시간 초과되고 셀룰러 네트워크에서는 정상이라면 접속 네트워크나 서버까지의 경로가 영향을 준다는 뜻이지만, 서버가 완전히 정상이라고 단정할 수는 없습니다. 두 네트워크 모두 일반 웹사이트에 접속되는지 확인한 뒤 비슷한 시간대에 비교해 시간에 따른 부하 차이가 결과에 섞이지 않도록 하세요. 같은 네트워크에서 기존 항목이 모두 실패하고 다른 네트워크에서는 정상이라면 라우터 제한, 네트워크 인증, UDP 사용 가능 여부를 확인하세요. 모든 항목의 암호를 한꺼번에 바꿔보는 식으로 추측하지 마세요.

프로토콜 핸드셰이크에 필요한 항목 확인

TLS를 사용하는 설정이라면 서버가 제공한 도메인 관련 항목, 기기 시간, 인증서 유효성을 확인하세요. 기기 시간이 크게 어긋나면 인증서 판정에 영향을 줄 수 있으므로 먼저 시간을 바로잡고 다시 테스트합니다. 인증서 검증을 끄는 것은 일반적인 해결 방법이 아닙니다. 연결 상대를 확인하는 범위가 달라지기 때문입니다. 전송 계층 설정이 있는 프로토콜에서는 Host, Path, TLS 관련 이름이 각각 다른 계층에서 사용될 수 있으므로 값이 비슷하다고 서로 바꾸지 마세요. 각 항목의 의미는 프로토콜 및 입력 항목 안내를 참고하세요.

공유 링크에서 가져온 뒤에는 파싱 결과가 완전한지도 확인해야 합니다. 원본 정보에 전송 파라미터가 빠져 있다면 가져오기에 성공했더라도 설정을 사용할 수 있다고 볼 수 없습니다. 다른 항목의 설정을 보고 임의로 채우지 말고 원본 정보를 제공한 곳에 확인하세요. 구독에서 생성된 항목을 직접 수정하기 전에는 사본을 만들어 두세요. 다음 업데이트에서 변경 사항이 덮어써져 문제가 다시 생길 수 있습니다. ‘파라미터를 바꿈’이라고만 기록하는 것보다 ‘기존 서버 안내와 비교해 Path를 수정함’처럼 근거를 함께 적으면 나중에 확인하기 쉽습니다.

실제 서비스에 접속해 확인하고 테스트를 반복하지 않기

정보를 확인한 항목을 선택해 한 번 테스트한 뒤 실제로 필요한 웹사이트에 접속하세요. 계속 실패하면 오류 요약과 네트워크 상태를 저장한 후 잠시 뒤 다시 테스트합니다. 짧은 간격으로 여러 항목을 대량 테스트하면 요청 부담이 커지고 간헐적인 오류를 관찰하기도 어렵습니다. 특정 서버 항목만 계속 실패한다면 오류 유형, 발생 시각, 비교 결과를 정리해 이용 중인 서비스 제공업체에 상태를 문의하세요. 문의 전에 인증 정보, 키, 전체 구독 주소를 제거하세요. 진단에 필요한 것은 증상과 파라미터 종류이지 공개된 인증 정보가 아닙니다.

핸드셰이크는 성공하지만 큰 페이지나 업로드가 실패한다면 속도 장에서 지속 전송, 패킷 손실, MTU 관련 문제를 확인하세요. 모든 문제를 서버 시간 초과라고 부르며 점검을 이어가지 마세요. 장애가 발생한 구간을 확인해야 적절한 해결 절차를 고를 수 있습니다.

구독 업데이트 실패, 가져온 목록이 비어 있음 또는 항목 중복

구독 처리는 주소 확인, 서버 요청, 콘텐츠 수신, 형식 분석, 로컬 목록 저장 등 여러 단계를 거칩니다. 업데이트에 실패했다고 기존 항목까지 사용할 수 없는 것은 아닙니다. 기존 항목은 계속 연결되지만 업데이트 요청만 실패했을 수 있습니다. 먼저 기존 항목의 개수와 이름을 기록하고 복원할 수 있는 사본을 저장한 다음 업데이트를 한 번 실행해 안내 문구를 확인하세요. 구독은 이용 중인 서비스 제공업체에서 받아야 합니다. 출처가 불분명한 주소로 기존 구독을 바꾸거나 인증 정보가 포함된 전체 링크를 공개된 곳에 붙여 넣지 마세요.

가져올 콘텐츠와 입력 위치가 맞는지 확인

단일 서버 공유 링크, 서버 목록 구독, 전체 설정 파일은 서로 다른 형식입니다. 공유 링크는 한 항목의 정보를 담고, 목록 구독은 여러 항목을 지속적으로 가져오며, 설정 파일에는 규칙과 DNS가 포함될 수 있습니다. 웹페이지 주소나 설정 파일 주소를 맞지 않는 입력란에 넣으면 ‘요청에는 성공했지만 인식할 수 있는 항목이 없음’으로 처리될 수 있습니다. 원본 제공자의 형식 및 입력 위치 안내를 확인한 뒤 시작하기의 절차를 따르세요. 공유 링크 구조와 구독 주소의 차이는 공유 링크와 구독 링크의 차이에서 확인할 수 있습니다.

주소를 복사할 때 화면에 보이는 제목만 복사하지 않았는지, 물음표 뒤의 매개변수가 빠지지 않았는지, 메시지 앱이 줄바꿈을 넣지 않았는지 확인하세요. 주소의 대소문자와 인코딩 문자를 임의로 바꾸지 말고 반각 기호를 전각 문장 부호로 바꾸지 마세요. 링크를 다시 받아야 한다면 기존 서비스 제공업체에서 받아 용도를 확인하세요. 구독 주소에는 접속 인증 정보가 포함되는 경우가 많습니다. 시스템 클립보드, 스크린샷, 방문 기록에도 주소가 남을 수 있으므로 진단이 끝난 뒤 불필요한 사본을 정리하고 여러 앱에 반복해서 공유하지 마세요.

네트워크 오류, 응답 오류, 파싱 오류 구분

요청이 시간 초과되면 구독 도메인 해석과 현재 네트워크에서의 접속 가능 여부부터 확인하세요. 인증서 오류는 기기 시간, 도메인, 인증서 상태를 점검합니다. HTTP 상태 코드가 명확하게 표시되면 서버 응답이 일정 단계까지 도달했다는 뜻입니다. 401이나 403은 인증, 권한, 접근 제한과 관련되는 경우가 많지만 구체적인 원인은 서버 측 확인이 필요합니다. 404는 경로가 바뀌었거나 주소가 불완전할 수 있고, 429는 요청 빈도 제한을 뜻하므로 연속 새로고침을 멈추고 응답 안내에 따라 기다려야 합니다. 처음 발생한 유효한 오류를 반복 클릭으로 가리지 마세요.

로그인 페이지, 안내 페이지, 네트워크 인증 페이지로 연결되면 클라이언트가 예상한 구독 데이터 대신 HTML을 받았을 수 있습니다. 따라서 ‘브라우저에서 열림’이 ‘구독으로 파싱 가능함’을 의미하지는 않습니다. 원본 서비스에서 보호된 콘텐츠의 응답 형식을 확인하는 방법을 제공한다면 안내에 따라 확인하세요. 구독 인증 정보를 낯선 온라인 변환 페이지에 입력하지 마세요. 일부 구독 서비스는 클라이언트별 출력 형식을 제공합니다. 주소의 확장자만 보고 판단하지 말고 Shadowrocket에서 인식할 수 있는 형식이 선택됐는지 확인하세요.

중복 항목과 업데이트 후 변경 사항 처리

중복 항목이 보이면 먼저 ‘같은 구독을 여러 번 추가한 경우’인지 ‘서버 측에 이름이 같은 항목이 있는 경우’인지 구분하세요. 전자라면 백업과 소속을 확인한 뒤 하나만 남길 수 있습니다. 후자라면 이름만 보고 삭제하지 말고 주소, 포트, 프로토콜을 비교해야 합니다. 구독 업데이트 과정에서 이전 항목이 삭제되거나 이름이 바뀌면 기존 선택 항목도 달라질 수 있습니다. 업데이트가 끝나면 Home으로 돌아가 현재 선택 항목이 남아 있고 정보가 완전한지 확인한 뒤 실제로 접속해 보세요. 목록에 새 이름이 보인다는 이유만으로 업데이트가 완전히 정상이라고 판단하지 마세요.

로컬 항목을 직접 수정했다면 업데이트 전에 별도 항목으로 복사하고 용도를 표시하세요. 구독에서 생성된 내용과 개인 수정 내용을 분리하면 나중에 덮어쓰기 때문에 문제가 반복되는 일을 줄일 수 있습니다. 업데이트 요청만 실패하고 기존 항목은 정상이라면 현재 작동 상태를 유지하고 오류와 응답 시간을 기록한 뒤 서비스 제공업체에 확인하세요. 해결 여부는 오류 문구가 사라지는 것뿐 아니라 업데이트 완료, 항목 인식, 올바른 항목 선택, 실제 접속 성공까지 확인해야 합니다.

연결은 되지만 속도가 느리거나 전송이 불안정함

‘느리다’는 증상을 재현할 수 있도록 구체적으로 나눠 보세요. 처음 열 때 오래 걸리는지, 페이지가 열리기 시작한 뒤 계속 느린지, 동영상이 끊기는지, 대용량 업로드가 멈추는지 확인합니다. 첫 연결 지연은 DNS 해석이나 핸드셰이크와 관련될 가능성이 높고, 지속적인 전송 속도는 접속 네트워크, 서버 부하, 대상 서비스, 패킷 손실, 전송 방식의 영향을 받습니다. 지연 시간이 짧다고 처리량이 높은 것은 아니며 짧은 연결 테스트로 장시간 전송 성능을 예측할 수 없습니다. 한 번의 Connectivity Test 순위만으로 모든 서비스에서 더 빠른 서버라고 단정하지 마세요.

같은 조건에서 비교하기

합법적으로 이용할 수 있고 콘텐츠와 크기가 비교적 일정한 테스트 대상을 정해 같은 기기, 같은 네트워크, 비슷한 시간대에 비교하세요. 다른 대용량 작업은 일시 중지하고 Wi-Fi 신호와 셀룰러 데이터 상태를 확인한 뒤 기본 네트워크와 현재 프록시 경로를 각각 테스트합니다. 평균 숫자 하나만 기록하지 말고 처음 대기 시간, 지속 로딩 상태, 중단 여부를 기록하세요. 테스트는 데이터 사용량을 발생시키고 서버 부하에도 영향을 줄 수 있습니다. 재현에 필요한 횟수만 테스트하면 되며 여러 작업을 동시에 계속 실행할 필요는 없습니다.

모든 사이트가 느리면 접속 네트워크와 선택한 서버를 먼저 확인하세요. 특정 서비스만 느리다면 해당 서비스의 리소스 도메인, 라우팅 경로, 서버 응답을 확인합니다. 페이지 본문은 빨리 열리지만 이미지나 동영상이 느린 경우 리소스마다 도메인과 경로가 다를 수 있습니다. 요청 기록에서 지연이 발생하는 부분을 찾아 Config에서 규칙을 확인하세요. 복잡한 설정 파일로 전체를 바꾸면 DNS, 규칙, 기타 처리 방식이 동시에 바뀌어 비교 기준을 잃게 됩니다.

핸드셰이크, 반복 연결, 전송 조건 확인

연결을 자주 끊었다 다시 연결하면 TLS 또는 다른 프로토콜의 핸드셰이크가 반복되어 짧은 요청도 느리게 로드될 수 있습니다. 속도가 느릴 때 시간 초과, 연결 종료, 네트워크 전환이 함께 발생하는지 확인하세요. 엘리베이터 안이나 이동 중, 신호가 약한 Wi-Fi에서만 문제가 생긴다면 접속 환경부터 개선해야 합니다. 안정적인 네트워크에서는 정상이라면 규칙 수정이 우선이 아닙니다. UDP에 의존하는 전송은 현재 네트워크가 필요한 통신 방식을 지원하는지 확인하세요. 일반 웹페이지가 열린다고 UDP 경로까지 정상이라는 뜻은 아닙니다.

작은 페이지는 정상인데 큰 파일 전송이 멈춘다면 패킷 손실, 경로 MTU, 서버 측 제한이 원인일 수 있지만 증상만으로 확정할 수는 없습니다. 여러 곳에 서로 다른 MTU 값을 임의로 입력하지 마세요. 현재 프로토콜에서 관련 설정을 명시적으로 제공하고 원본 서버 안내나 재현 가능한 근거가 있을 때만 사본에서 한 항목을 바꿔 비교하세요. WireGuard 등은 허용 주소 범위와 실제 라우팅도 확인해야 합니다. 기본값이나 원래 설정으로 되돌릴 수 있도록 변경 내용을 기록하세요.

설정 처리로 인한 추가 지연 확인

복잡한 규칙, 원격 리소스, 요청 재작성은 처리 단계를 늘릴 수 있지만 이것만으로 모든 기능이 문제라고 단정할 수는 없습니다. 현재 설정을 복사한 뒤 사본에서 최근 추가한 처리 항목 하나만 비활성화하고 같은 작업을 테스트하세요. 개선되면 범위를 하나씩 좁혀 갑니다. HTTPS 검사나 재작성 설정은 처리 방식을 바꿀 수 있으므로 용도와 인증서 검증 범위를 정확히 이해한 뒤 사용하세요. 속도를 높이려고 처리 범위를 넓히지 마세요. 전체 설정 파일의 각 구간은 설정 파일 구간 안내를 참고하세요.

규칙이 원래 LAN에서 접속해야 하는 서비스를 프록시로 보내거나 특정 경로가 필요한 리소스를 직접 연결로 보내지 않는지도 확인하세요. LAN 프린터, 파일 접근 문제는 일반 웹사이트 문제와 같은 방식으로 진단할 수 없습니다. 확인된 대상에 맞춰 규칙을 수정한 다음 원래 Global Routing 설정으로 돌아가 확인하세요. Proxy를 계속 사용하는 것은 규칙 문제를 우회했을 뿐 설정을 제대로 고친 것이 아닐 수 있습니다. 설정 사본은 변수를 분리하기 위한 것이지 여러 파일에 정리되지 않은 역할을 동시에 맡기기 위한 것이 아닙니다.

마지막으로 페이지 로드, 일정 시간 연속 재생, 파일 업로드 등 실제 작업을 완료해 같은 중단 현상이 남아 있는지 확인하세요. 특정 시간대에만 느리다면 시간, 접속 네트워크, 오류 요약을 기록해 서비스 제공업체에 확인합니다. 한 번 빨랐다는 이유만으로 해결됐다고 판단하지 말고 대상 사이트의 속도 제한을 클라이언트 설정 문제로 오해하지 마세요.

DNS 조회 실패 및 특정 도메인 접속 오류

DNS는 도메인을 접속 가능한 주소로 변환합니다. 서버 연결, 규칙 판정, 대상 서비스 접속도 DNS에 의존할 수 있습니다. 서버 도메인을 조회할 수 없거나, 웹페이지에 주소를 찾을 수 없다는 오류가 표시되거나, 일부 리소스가 빠지거나, Connectivity Test 결과는 있지만 실제 웹페이지가 열리지 않는 증상이 나타날 수 있습니다. 먼저 서버 도메인과 대상 웹사이트 도메인 중 어느 쪽에서 문제가 발생하는지 확인하세요. 두 문제는 서로 다른 단계에서 발생합니다. 서버 도메인을 조회하지 못하면 프록시 연결 자체가 만들어지지 않을 수 있지만, 대상 도메인 문제는 세션 연결 후에 나타날 수 있으므로 같은 설정 하나로 모두 해결할 수는 없습니다.

현재 적용되는 DNS 확인

Config에서 실제로 사용 중인 파일을 확인한 뒤 [General] 구간과 관련 DNS 설정을 살펴보세요. 시스템 DNS, 설정 파일의 DNS, 암호화 DNS가 요청 종류에 따라 함께 영향을 줄 수 있습니다. 한 줄에 system이라고 적혀 있다는 이유로 모든 조회가 같은 경로를 사용한다고 단정하지 마세요. 기존 값을 기록하고 현재 앱에서 해당 항목이 무엇을 의미하는지 확인한 다음 한 항목씩 비교합니다. 아래 예시는 키와 값의 작성 형식을 보여줄 뿐 모든 네트워크에 권장되는 설정이 아닙니다. 사용자의 전체 파일을 덮어쓰는 데 사용하지 마세요.

[General]
bypass-system = true
dns-server = system
ipv6 = false

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

DNS를 바꾼 직후 문제가 생겼다면 설정 사본에서 이전에 정상 작동한 값으로 먼저 되돌린 뒤 다시 연결하고 새 요청을 보내세요. 브라우저, 시스템, 앱이 결과를 캐시할 수 있으므로 이전 페이지가 계속 실패하거나 기존 연결이 계속 성공하더라도 변경이 적용되지 않았다고 단정할 수는 없습니다. 기존 요청을 종료한 뒤 다시 접속하고 필요한 경우 문제가 있는 앱을 재시작하세요. 기기 설정 전체를 초기화하는 방법을 일반적인 캐시 정리 절차로 사용하지 마세요. 매번 DNS 출처나 관련 항목 하나만 바꾸고 되돌릴 수 있는 방법을 남겨 두세요.

시간 초과, 레코드 없음, 주소 접속 가능 여부 구분

DNS 시간 초과는 정해진 시간 안에 응답을 받지 못했다는 뜻이므로 DNS 서비스에 연결되는 경로를 확인해야 합니다. 해당 레코드가 없다는 응답이 명확하다면 도메인 철자, 레코드 종류, 대상 서비스 상태를 확인하세요. 주소가 조회됐지만 해당 주소로 연결할 때 시간 초과가 발생하면 문제는 라우팅이나 대상 서비스 쪽에 있을 수 있습니다. 이 경우 DNS를 계속 바꿔도 해결되지 않을 수 있습니다. 암호화 DNS를 사용한다면 DNS 서비스 주소를 어떻게 조회하고 연결하는지, 아직 연결되지 않은 프록시 경로가 먼저 필요한지 확인하세요. 연결 시작 단계가 서로 의존하는 순환 구조를 만들지 않도록 주의합니다.

IPv6를 켠 뒤에만 문제가 나타난다면 현재 네트워크에 사용할 수 있는 IPv6 경로가 있는지, 대상이 반환한 주소와 실제 라우팅이 일치하는지 확인하세요. 사본에서 IPv6를 끄고 한 번 비교해 볼 수 있지만 모든 네트워크에서 IPv6를 꺼야 한다는 뜻은 아닙니다. 설정을 되돌린 뒤 실제 서비스도 다시 테스트하세요. 네트워크가 특정 주소 변환 방식에 의존한다면 숫자 주소에 직접 접속하거나 한 주소 계열만 테스트하는 결과가 오해를 낳을 수 있습니다. 막연히 ‘DNS 문제’라고 쓰기보다 ‘특정 네트워크에서 특정 주소 계열만 실패’라고 기록하는 편이 정확합니다.

로컬 주소 매핑과 규칙 연동 확인

[Host]의 로컬 주소 매핑이 정상적인 DNS 응답을 덮어쓰면 특정 도메인만 계속 열리지 않을 수 있습니다. 설정에서 해당 도메인의 매핑과 관련 규칙을 검색해 과거 테스트 흔적이 남아 있지 않은지 확인하세요. 삭제하기 전에 사본을 저장하고 원래 용도를 기록합니다. 도메인 규칙과 IP 규칙의 적용 순서도 중요합니다. 일부 IP 판정은 먼저 DNS 응답을 받아야 합니다. 앞선 규칙에서 도메인이 일치했다면 뒤에 있는 GEOIP 또는 IP-CIDR 규칙이 같은 요청에 일반적인 후속 규칙으로 계속 적용되지 않습니다.

사이트에서 임시로 조회된 주소를 [Host]에 장기간 고정하지 마세요. 콘텐츠 전송이나 동적 주소를 사용하는 서비스는 네트워크와 시간에 따라 다른 주소를 반환할 수 있습니다. 주소를 고정하면 서버 선택이 제대로 되지 않거나 인증서 및 리소스, 연결 가능성에 문제가 생길 수 있습니다. HTTPS 사이트를 IP 주소로 직접 여는 것도 동등한 테스트가 아닙니다. 인증서의 도메인 이름과 서버 측 가상 호스트 선택에 도메인이 필요할 수 있습니다. 테스트에서 DNS 조회, 포트 연결, 전체 서비스 접속 중 무엇을 확인했는지 구분해서 기록하세요.

문제를 해결한 뒤 서버 도메인, 이전에 실패한 웹사이트, 관련 리소스를 각각 확인하고 Config에서 평소 사용하던 설정으로 돌아가세요. 특정 Wi-Fi에서만 문제가 생긴다면 라우터 DNS와 네트워크 인증 상태도 점검해야 합니다. 추가 점검 사례는 DNS 조회 실패 문제 해결을 참고하세요. 기록에는 도메인 유형, DNS 오류, 적용된 정책만 남기고 민감한 매개변수가 포함된 전체 요청 주소는 공개하지 마세요.

배터리 소모 증가, 발열 또는 비정상적인 백그라운드 활동

시스템 배터리 화면에 Shadowrocket의 활동량이 많이 표시되더라도 앱 자체의 특정 기능이 모든 소모를 일으켰다고 단정할 수 없습니다. VPN은 다른 앱의 네트워크 트래픽도 처리하며 시스템 통계는 화면 사용, 백그라운드 통신, 연결 시간의 영향을 받습니다. 같은 기기와 비슷한 시간대, 비슷한 작업을 기준으로 비교하면서 화면 사용, 네트워크, 충전 상태, 전송 중인 작업을 기록하세요. 동영상 재생 중 통계와 기기를 가만히 둔 상태의 통계를 직접 비교하면 추가 소모의 원인을 찾기 어렵습니다.

비교 가능한 관찰 시간 정하기

기기의 배터리 잔량과 온도가 비교적 안정적일 때 평소 사용 시간대를 정해 관찰하고 시스템 배터리 및 데이터 사용량 통계를 확인하세요. 특정 배터리 소모 비율을 목표로 삼을 필요는 없습니다. 비슷한 작업끼리 비교했을 때 뚜렷한 차이가 있는지가 중요합니다. 대용량 파일 동기화, 장시간 동영상 재생, 개인용 핫스팟처럼 데이터 사용량이 많은 작업을 먼저 중지하고 시스템 업데이트나 사진 처리 작업이 동시에 진행되는지도 확인하세요. 관찰하는 동안 같은 네트워크를 유지하는 것이 좋습니다. 셀룰러 신호가 약하면 무선 통신에 드는 전력이 규칙 처리보다 우선 확인할 원인일 수 있습니다.

연결 스위치가 자주 바뀌거나 요청 기록에 실패와 재시도가 계속 표시되면 연결 문제를 먼저 해결하세요. 재연결, 재조회, 반복적인 핸드셰이크는 활동량을 늘려 백그라운드 작업이 계속되는 것처럼 보이게 할 수 있습니다. 서로 다른 자동 연결 조건이 영향을 주는지, 네트워크 전환 후 On Demand가 반복 실행되는지, 기기가 신호가 불안정한 Wi-Fi 경계에 오래 머무는지 확인하세요. 자동 연결을 끄고 짧게 비교할 때는 원래 설정을 기록합니다. 진단이 끝나면 실제 사용에 필요한 설정을 복원하고 테스트 상태로 두지 마세요.

진단 작업과 지속적인 네트워크 요청 확인

Connectivity Test 대량 실행, 잦은 구독 업데이트, 상세 요청 기록, 장시간 디버깅은 모두 추가 작업을 발생시킵니다. 점검을 마친 뒤 더 이상 필요하지 않은 테스트를 중지하고 기록 범위를 평소 수준으로 복원한 다음 시스템 통계가 안정되는지 확인하세요. 배터리 소모를 확인하려고 여러 테스트를 동시에 실행하지 마세요. 진단 작업 자체가 부하 원인이 됩니다. 로그는 문제를 찾는 데 필요한 범위만 보관하세요. 긴 기록에는 방문 도메인과 요청 정보가 포함될 수 있으므로 내보내거나 공유하기 전에 민감한 내용이 있는지 확인해야 합니다.

기기를 사용하지 않을 때도 데이터가 계속 오간다면 다른 앱의 백그라운드 동기화인지 먼저 확인하세요. 시스템에서 허용하는 범위 안에서 관련 백그라운드 작업을 하나씩 일시 중지하고 데이터 변화량을 비교할 수 있습니다. 확인 없이 모든 앱 권한을 한꺼번에 끄지 마세요. 특정 앱을 열었을 때만 재시도가 계속된다면 실패한 리소스와 규칙 경로를 확인하고 인터넷 연결 및 DNS 문제 해결 장을 참고하세요. 요청 실패를 해결하는 편이 앱의 백그라운드 활동을 단순히 제한하는 것보다 원인에 가깝습니다. 그렇지 않으면 해당 앱이 계속 요청을 다시 보낼 수 있습니다.

설정 사본으로 추가 처리 분리

새 설정을 추가한 직후 문제가 생겼다면 현재 파일을 복사하고 사본에서 최근 변경한 항목 하나만 되돌리세요. 예를 들어 새 재작성 설정이나 복잡해진 요청 처리를 한 번에 한 그룹씩 확인합니다. 서버, Global Routing, 테스트 작업은 동일하게 유지한 채 발열과 활동량을 비교하세요. 서버, DNS, 설정을 동시에 바꾸면 결과가 좋아져도 원인을 알 수 없습니다. 설정의 복잡성은 줄 수만으로 판단할 수 없습니다. 현재 트래픽에 실제로 적용되는 처리 항목과 그 항목이 새 요청이나 재시도를 반복해서 일으키는지 확인해야 합니다.

특정 프로토콜의 이름만 보고 배터리를 더 적게 쓰거나 더 많이 쓴다고 단정하지 마세요. 네트워크 품질, 재전송, 연결 수, 작업 종류에 따라 결과가 달라집니다. 사용자가 이미 보유한 여러 항목을 비교해야 한다면 같은 작업에서 하나씩 테스트하고 각 항목이 요청을 안정적으로 완료하는지 확인하세요. 계속 실패하는 연결과 정상 연결 사이의 배터리 차이는 우선 사용 가능성의 차이를 보여주는 것이지 프로토콜 자체의 고정된 특성을 의미하지 않습니다.

평소 사용하는 조건에서 최종 확인해 비정상적인 백그라운드 활동이 계속되는지 살펴보고 임시 기록을 중지한 뒤에도 네트워크 기능이 정상인지 확인하세요. 지원을 요청할 때는 시스템 배터리 화면의 시간 범위, 주요 작업, 충전 여부, 네트워크 종류, 재연결 증상을 알려 주세요. 배터리 비율만 나온 스크린샷 하나만 제출하지 마세요. 사용 조건이 빠진 통계로는 앱 처리, 다른 앱의 트래픽, 무선 네트워크 사용량을 정확히 구분할 수 없습니다.

업데이트 후 문제 및 iPad 전용 점검

업데이트 직후 처음 문제가 발견됐더라도 업데이트와 시간상 가까웠다는 뜻일 뿐, 업데이트가 유일한 원인이라는 증거는 아닙니다. 앱, 시스템, 구독 내용, 접속 네트워크가 같은 시기에 바뀌었을 수 있습니다. 앱 업데이트 여부, 시스템 재시동, 구독 자동 갱신, 설정 파일 교체 여부 등 실제 변경 사항을 먼저 기록한 뒤 같은 동작으로 문제를 재현하세요. 업데이트 기록과 시스템 요구 사항은 App Store 페이지를 기준으로 확인하고 특정 버전에서 어떤 동작이 바뀌었는지 기억에만 의존해 추측하지 마세요.

기존 설정을 보존하고 현재 선택 확인

현재 설정 파일과 필요한 개인 항목 정보를 먼저 복사하고 인증 정보가 포함된 사본은 안전하게 보관하세요. Home에서 현재 서버를 확인하고 Config에서 활성화된 파일을 확인한 다음 Global Routing과 On Demand 설정을 살펴봅니다. 목록에 항목이 있다고 해서 현재 선택이 이전과 같다는 뜻은 아닙니다. 구독 업데이트로 이름이 바뀌거나 항목이 삭제되고 파라미터가 변한 일이 앱 업데이트와 우연히 같은 시기에 발생했을 수 있습니다. 전체 설정을 바로 초기화하는 것보다 로컬 사본과 현재 내용을 구간별로 비교하는 편이 실제 차이를 찾기 쉽습니다.

이전 설정에서만 문제가 생긴다면 사본에서 최근 변경 사항을 되돌리거나 이미 검증된 최소 설정부터 단계적으로 복원하세요. 설정을 읽을 때 오류가 명확하게 표시되면 해당 행의 문법, 구간, 정책 참조를 먼저 수정하세요. 안내를 무시한 채 다른 설정을 계속 추가하지 마세요. 앱 안내를 확인할 때는 화면의 영어 설정 용어를 그대로 사용해 번역 표현 때문에 메뉴를 잘못 찾지 않도록 합니다. 설정을 복원한 뒤 실제 요청도 다시 확인해야 합니다. Config 화면이 열리는 것만으로 모든 항목이 현재 네트워크에 적합하다고 볼 수 없습니다.

같은 구매 내역과 같은 네트워크 설정은 별개

iPad에서 구매할 때 사용한 Apple ID로 App Store에 로그인해 구입 상태를 확인하세요. 복원 방법은 iPad 이용 안내와 구입 항목 복원을 참고하세요. 구매 내역은 앱을 받을 수 있는 권한을 확인하는 것으로, 기기에 저장된 서버, 구독, 설정이 모두 자동으로 복원된다는 뜻은 아닙니다. 앱에 가져오기나 동기화 메뉴가 있다면 출처, 내용, 실제로 적용 중인 파일을 확인하세요. 기기에 앱 이름이 표시된다고 두 기기의 네트워크 설정까지 같다고 판단하지 마세요.

iPhone과 iPad를 비교할 때는 두 기기를 같은 Wi-Fi와 동일한 기존 서버, 동등한 설정으로 맞춘 뒤 같은 대상에 접속하세요. 한 기기는 셀룰러 네트워크, 다른 기기는 Wi-Fi를 사용하면 먼저 네트워크 경로 차이부터 고려해야 합니다. iPad에 키보드, 도킹 스테이션, 이더넷 액세서리가 연결되어 있는지, 시스템에서 다른 네트워크 서비스를 사용 중인지도 확인하세요. 액세서리로 접속 경로가 바뀌면 DNS, LAN 접속, On Demand 조건도 기존 Wi-Fi 환경과 달라질 수 있습니다.

분할 화면 조작, 잠자기, LAN 접속 확인

iPad의 분할 화면이나 넓은 화면에서는 목록과 세부 정보를 동시에 볼 수 있습니다. 파일을 편집했다고 해서 반드시 현재 설정으로 선택된 것은 아니며, 서버 정보를 열어 봤다고 해서 해당 서버로 연결되는 것도 아닙니다. 조작 후 Home과 Config로 돌아가 실제 선택 상태를 확인하세요. 멀티태스킹을 사용할 때는 ‘앱 창이 다시 표시됨’과 ‘연결이 다시 설정됨’을 구분해야 합니다. 창이 앞에 보이는지만으로 연결 상태를 판단하지 말고 실제 스위치, 시스템 상태, 요청 결과를 함께 확인하세요.

잠자기에서 깨어난 뒤에만 문제가 생긴다면 잠들기 전후의 네트워크, 로그인 인증 여부, On Demand 상태를 기록하세요. 먼저 수동으로 연결해 복구되는지 확인한 다음 같은 조건에서 자동 연결이 실행되는지 살펴봅니다. LAN 파일, 프린터, 기기 검색이 실패하면 해당 접근에 필요한 시스템 권한과 대상 기기가 같은 네트워크 구간에 있는지 확인하세요. 일부 검색 기능은 멀티캐스트에 의존하므로 일반 웹사이트가 열린다고 LAN 검색도 정상이라는 뜻은 아닙니다. 한 LAN 대상 문제를 해결하려고 모든 라우팅 규칙을 삭제하지 마세요.

재설치는 백업과 설정 비교를 마친 뒤 꼭 필요한 경우에만 진행하세요. 앱을 재설치하면 로컬 내용이 지워질 수 있지만 서버 파라미터나 구독 권한이 자동으로 해결되지는 않습니다. 앱은 App Store에서만 받아야 합니다. 정품 확인 시 개발자 Shadow Launch Technology Limited, 공식 아이콘, 앱 ID 932747118을 확인할 수 있습니다. 조치 후에는 수동 연결, 화면 잠금 후 다시 열기, 네트워크 전환, 이전에 실패했던 작업을 각각 테스트하세요. 효과가 확인된 단계는 간단히 기록하고 나머지 설정은 그대로 두어 이후 문제를 재현할 수 있는 기준을 남기세요.