Shadowrocket
문제 해결 가이드

01 / 연결 시작

연결 스위치가 켜지지 않음

시스템 연결을 설정하기 전부터 문제가 발생하는지, 연결 직후 종료되는지 먼저 확인하세요. 전자의 경우 시스템 권한 승인이 완료되지 않았거나 설정이 저장되지 않았거나 기기 관리 정책의 제한을 받는 경우가 많습니다. 후자라면 오류 메시지와 연결 기록을 확인해야 합니다. 스위치 문제를 모두 서버 오류로 단정하지 마세요. 원격 서버에 연결할 수 없어도 요청에만 영향을 주고 로컬 연결 시작은 막지 않을 수 있습니다. 버튼을 반복해서 누르기보다 누른 뒤 나타나는 상태를 기록하는 편이 원인을 파악하는 데 도움이 됩니다.

시스템 권한 승인 확인

iPhone 또는 iPad에서 처음 활성화하면 시스템이 VPN 구성 추가를 허용할지 묻습니다. 현재 작업과 관련된 안내인지 확인한 뒤 시스템 절차에 따라 승인하고, 메시지를 취소했다면 Shadowrocket으로 돌아가 다시 시도한 후 기기 인증을 완료하세요. 다음으로 시스템 설정의 VPN 관리 화면에서 해당 구성이 추가되었는지 확인합니다. OS 버전에 따라 설정 메뉴 위치가 달라질 수 있으므로 고정된 경로를 찾기보다 설정에서 VPN을 검색하면 됩니다.

학교나 조직에서 관리하는 기기라면 관리 정책에 따라 네트워크 구성을 추가하지 못할 수 있습니다. 이 경우 설정을 반복해서 삭제하지 말고 기기 관리 안내를 확인하거나 관리자에게 해당 기능의 사용 가능 여부를 문의하세요. 시스템 제한, 자녀 보호 기능, 조직 관리 설정은 서버 매개변수 문제가 아닙니다. 다른 네트워크 연결 구성을 사용하는 기기라면 Shadowrocket을 시작하기 전에 현재 연결을 정상적으로 끊어 두 서비스의 상태가 뒤섞이지 않게 하세요.

로컬 설정 및 충돌 확인

Home으로 돌아가 선택 가능한 서버가 있는지 확인하세요. 메모만 입력하고 필수 매개변수를 빠뜨린 상태는 아닌지도 살펴보세요. 이어서 Config에서 현재 활성화된 파일이 실제로 존재하는지, 최근 파일 내용을 변경했는지 확인합니다. 설정 구문 오류, 존재하지 않는 정책 이름 참조, 불완전한 가져오기 파일은 시작 단계에서 오류를 일으킬 수 있습니다. 먼저 변경 전 사본으로 복원하세요. 사본이 없다면 원본을 보존하고 항목이 적은 설정으로 검증하세요. 모든 자료를 바로 지우지는 마세요.

스위치가 잠깐 켜졌다 꺼진다면 먼저 오류 메시지를 확인해 설정 로드 실패, 시스템 서비스 시작 실패, 외부 연결 조건에 따른 연결 해제 중 무엇인지 구분하세요. On Demand를 잠시 비활성화하고 수동으로 시작해 다시 테스트하면 자동 조건으로 인한 영향을 줄일 수 있습니다. 테스트가 끝난 뒤 원래 조건을 복원하세요. 자동 연결을 켠 채 시스템 구성을 삭제하면 구성이 다시 나타날 수 있어 삭제가 적용되지 않은 것처럼 보일 수 있습니다.

시스템 연결 구성을 다시 만들기 전에 먼저 백업하세요. 연결을 끄고 구독, 수동 서버, Config를 복원할 수 있는 사본이 있는지 확인한 뒤 시스템 설정에서 Shadowrocket에 해당하는 이전 연결 구성만 제거하세요. 앱을 다시 열고 안내에 따라 권한을 승인한 다음 테스트합니다. 무엇인지 확인된 항목만 처리하세요. 조직 관리 자료를 삭제하지 말고, 저장된 네트워크 정보까지 함께 지울 수 있는 네트워크 설정 전체 재설정을 첫 단계로 삼지 마세요.

데스크톱 및 Android 시작 문제

앱이 아예 열리지 않는 문제라면 연결 문제를 살펴보기 전에 설치 및 실행 허용 안내를 확인하세요. Mac에서는 Apple 실리콘용과 Intel용 설치 파일이 기기에 맞는지 확인합니다. 개발자를 확인할 수 없다는 메시지가 나오면 개인정보 보호 및 보안에서 출처를 확인한 뒤 그래도 열기를 선택하세요. Windows에서 SmartScreen이 표시되면 사이트에서 받은 파일인지 확인한 후 추가 정보를 열고 그래도 실행을 선택하세요. 시스템 보호 기능 전체를 끄지는 마세요.

Android 설치 중에는 시스템 안내에 따라 현재 다운로드 앱의 알 수 없는 앱 설치를 허용하고, 설치가 끝난 뒤 필요한 경우 권한을 다시 해제하세요. 이는 연결 시 VPN 권한 승인과는 별개의 단계입니다. Linux에서 앱이 시작되지 않으면 먼저 설치 형식, 실행 권한, 데스크톱 환경의 오류를 확인하세요. 각 플랫폼 설치 파일은 다운로드 페이지에서 사이트의 /dl/shadowrocket/ 경로를 통해 제공됩니다. 출처가 불분명한 파일로 기존 프로그램을 교체하지 마세요.

02 / 요청 경로

연결 후 인터넷에 접속할 수 없음

먼저 연결을 끊은 상태에서 기준 테스트를 하세요. Shadowrocket을 끄고 브라우저에서 평소 바로 접속할 수 있는 웹페이지를 엽니다. 이때도 실패한다면 Wi-Fi 로그인 인증, 모바일 데이터 권한 또는 라우터 연결부터 확인하세요. 공용 네트워크는 인증 페이지에서 확인 절차를 마쳐야 할 수 있으며, 완료 전에는 다른 요청도 실패합니다. 기본 네트워크가 정상이어야 Config, Proxy, Direct를 비교할 수 있습니다. 그렇지 않으면 네트워크 단절을 규칙 문제로 오인할 수 있습니다.

세 가지 모드로 원인 범위 좁히기

같은 네트워크와 기기, 서버, 대상에서 Global Routing의 세 가지 모드를 차례로 비교하세요. 모드를 바꿀 때마다 요청을 새로 보내고, 필요하면 대상 앱을 완전히 종료한 뒤 다시 열어 기존 연결을 재사용하지 않도록 합니다. 테스트는 차이를 확인하기 위한 것이며 특정 모드를 모든 상황의 장기 해결책으로 삼으면 안 됩니다. 특히 대상에 직접 접속할 수 없는 환경이라면 Direct 실패만으로 기본 네트워크에 문제가 있다고 판단할 수 없습니다.

Proxy에서는 접속되지만 Config에서 실패한다면 서버를 바로 바꾸지 말고 대상 도메인이 Rule에서 어떤 규칙과 일치하는지 확인하세요. 범위가 넓은 DIRECT 또는 REJECT 규칙이 위쪽에 있어 뒤에 있는 더 구체적인 항목을 덮는 경우가 많습니다. 규칙은 일반적으로 위에서 아래로 적용되므로 구체적인 예외를 범위가 넓은 규칙보다 앞에 두세요. 변경 전에 현재 활성화된 Config를 확인해 비활성 파일을 편집한 뒤 규칙 변경이 적용되지 않는다고 오해하지 않도록 합니다.

정책 및 규칙 순서 확인

아래 규칙 조각은 적용 순서를 설명하기 위한 예시이며 완전한 설정 파일이 아니고 서버를 생성하지도 않습니다. 예시 도메인은 구문 설명용이므로 실제 대상과 기존 설정에 맞게 조정하세요. 테스트를 위해 파일 전체를 덮어쓰지 마세요. 특히 기존 정책 그룹과 필요한 설정을 삭제하지 않도록 주의하세요. 실제 적용 정책은 현재 구성 구조의 영향을 받으므로 규칙을 확인할 때 해당 정책이 존재하고 사용 가능한 서버를 가리키는지도 함께 확인하세요.

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

DOMAIN-SUFFIX는 도메인 접미사를, IP-CIDR은 IP 주소 범위를, GEOIP는 IP 주소의 지역 정보를 기준으로 판단하며 FINAL은 앞선 규칙과 일치하지 않은 요청을 처리합니다. 각 규칙이 확인하는 대상이 다르므로 이름만 보고 특정 요청이 반드시 일치한다고 단정할 수 없습니다. 대상 앱은 로그인 도메인, 리소스 도메인, 콘텐츠 전송 도메인에 동시에 연결할 수 있습니다. 홈페이지 도메인만 처리하면 로그인이나 이미지 요청은 누락될 수 있습니다. 실패한 요청의 실제 대상을 확인한 뒤 규칙 범위를 결정하세요.

모든 모드에서 실패하지만 연결을 끊으면 정상 접속된다면 연결 중 사용하는 DNS, 시스템 연결 충돌, Config의 일반 설정을 확인하세요. 최근 정상 작동한 사본으로 복원하고 네트워크를 동시에 제어하는 다른 서비스를 중지한 뒤 다시 테스트하세요. DNS, 경로, 서버를 한꺼번에 바꾸지 마세요. 정상화되더라도 원인을 파악하기 어렵습니다. 도메인 확인 방법은 DNS 문제 장을 참고하세요.

전반적인 문제와 특정 앱 문제 구분

브라우저는 정상이지만 특정 앱만 실패한다면 로그인, 미디어, 실시간 통신 요청을 별도로 살펴봐야 할 수 있습니다. 먼저 해당 앱이 현재 네트워크를 사용하도록 허용되어 있는지 확인한 뒤 완전히 종료하고 다시 여세요. 로그인만 실패한다면 기기 시간, 시스템 인증서 오류, 계정 상태를 확인하세요. 로컬 네트워크 기기에만 접속할 수 없다면 로컬 주소가 원격으로 전달되도록 규칙이 잘못 설정되지 않았는지 확인하세요. 문제를 숨기려고 전체 구성을 Direct로 바꾸지는 마세요.

수정이 끝나면 연결 아이콘만 보는 데 그치지 말고 처음 실패한 동작을 최소 한 번 다시 테스트하세요. 웹페이지 첫 화면이 열려도 이미지, 로그인, 파일 전송까지 모두 복구된 것은 아닙니다. 한 번 성공한 경우에도 캐시가 사용되었을 수 있습니다. 최종적으로 효과가 있었던 설정 변경을 기록하고 문제 해결을 위해 임시로 바꾼 불필요한 항목은 원래대로 돌리세요. 규칙 유형은 DOMAIN-SUFFIX, GEOIP, FINAL 규칙 자세히 알아보기에서 확인할 수 있습니다.

03 / 원격 연결

서버 연결 시간 초과

시간 초과는 특정 테스트가 제한 시간 안에 완료되지 않았다는 뜻일 뿐, 어느 단계에서 실패했는지 바로 알려주지는 않습니다. DNS 조회, 서버 포트 연결, 프로토콜 핸드셰이크, 테스트 대상 접속에 각각 시간이 걸릴 수 있습니다. 먼저 오류가 Connectivity Test에서 발생했는지 실제 앱 요청에서 발생했는지 기록한 다음, 같은 서버를 여러 네트워크에서 비교하세요. 시간 초과라는 문구만 보고 구독을 전부 다시 가져오면 유용한 비교 조건을 잃을 수 있습니다.

주소 및 프로토콜 항목 확인

해당 서버의 편집 정보를 열고 사용자가 보유한 서비스에서 받은 원래 매개변수와 하나씩 대조하세요. 서버 주소에 웹 경로, 공백, 불필요한 프로토콜 접두사가 포함되지 않도록 하고 포트는 서버 설정과 일치해야 합니다. QR 코드와 공유 링크에는 추가 필드가 포함될 수 있어 직접 옮겨 적을 때 빠뜨리기 쉽습니다. 메모는 로컬에서 표시하는 이름일 뿐이며 같은 메모를 가진 항목도 서로 다른 주소를 가리킬 수 있습니다. 표시 이름이 아니라 실제 매개변수를 비교하세요.

프로토콜 유형은 서버 측 설정과 일치해야 하며 테스트를 통과시키려고 임의로 바꾸면 안 됩니다. Shadowsocks의 암호화 방식과 비밀번호, VMess 또는 VLESS의 인증 정보, Trojan의 비밀번호와 TLS 조건은 각각 역할이 다릅니다. WireGuard에는 키, 주소, 피어 설정이 필요하며 Hysteria2에서는 인증 및 전송 조건을 확인해야 합니다. 누락된 항목은 사용 중인 서비스의 관리자에게 문의하세요. 다른 항목의 정보를 조합해 그럴듯한 매개변수를 만들지 마세요.

네트워크 교차 테스트

서버 매개변수는 그대로 두고 사용할 수 있는 Wi-Fi와 모바일 네트워크에서 각각 테스트하세요. 특정 네트워크에서만 실패하면 계정이 만료됐다고 단정하기보다 해당 네트워크의 인증 상태, 포트 연결 가능 여부, 전송 조건을 먼저 확인하세요. 같은 네트워크에서 사용자가 보유한 다른 서버는 정상이라면 특정 원격 서비스 쪽으로 원인 범위를 좁힐 수 있습니다. 모든 서버가 실패하면 기본 네트워크, 시스템 권한, DNS 단계로 돌아가 확인하세요.

Connectivity Test 결과는 선택한 테스트 방법과 대상에 대해서만 유효합니다. 포트 연결에 성공해도 프로토콜 인증이 성공한다는 보장은 없습니다. 테스트용 웹페이지가 응답해도 다른 웹사이트에 접속된다는 뜻은 아닙니다. 테스트는 실패하지만 실제 앱은 정상이라면 테스트 대상에 접근할 수 없거나 현재 서비스에 테스트 방법이 맞지 않을 수 있습니다. 확인된 실제 요청으로 다시 검증하고 목록의 테스트 결과를 보기 좋게 만들기 위해 기존 서버를 반복해서 변경하지 마세요.

서버 이름과 연결 주소는 서로 다를 수 있지만 둘 다 원래 설정과 일치해야 합니다. IP로 연결해도 TLS에 올바른 서버 이름이 필요할 수 있으므로 도메인을 IP로 바꾸면 인증서가 일치하지 않을 수 있습니다. 기기의 날짜와 시간이 틀려도 인증서 유효성 판단에 영향을 줍니다. 인증서 오류가 발생하면 시간을 바로잡고 이름을 확인하세요. 검증 건너뛰기를 일반적인 해결 방법으로 사용하지 마세요.

다음 확인을 누구에게 요청할지 판단

같은 항목이 사용 가능한 여러 네트워크에서 계속 실패하는데 다른 기존 항목은 정상이라면 원래 서비스 관리자에게 주소, 포트, 인증 상태, 서버 운영 여부를 확인하세요. 민감한 내용을 가린 오류 메시지와 재현 조건을 전달하면 충분합니다. 공유 링크나 구독 주소 전체를 공개하지 마세요. 원격 서비스의 매개변수가 최근 바뀌었다면 해당 항목을 업데이트하고, 실제로 새 항목이 선택되었는지도 확인하세요. 목록에 남은 이전 항목을 계속 사용하지 않도록 주의합니다.

웹페이지는 열리지만 대용량 파일이나 특정 앱에서 계속 연결이 끊긴다면 단순히 서버 시간 초과로 분류하지 마세요. 전송 경로, UDP 지원, 패킷 분할 조건과 관련된 증상일 수도 있습니다. 안정적인 네트워크에서 같은 작업으로 비교하세요. 고급 네트워크 매개변수는 서버 측 요구 사항을 기준으로 삼고, 변경 전에 백업한 뒤 한 번에 하나만 조정하세요. 명확한 근거 없이 전송 방식과 여러 하위 매개변수를 동시에 변경하면 호환성 문제가 더 생길 수 있습니다.

04 / 콘텐츠 가져오기

Subscribe 업데이트 실패

구독 실패는 주소에 접근할 수 있는지, 응답 내용을 해석할 수 있는지, 가져온 결과를 올바르게 사용하고 있는지 세 단계로 나눠 확인하세요. 각 단계의 해결 방법은 다릅니다. 업데이트 버튼에서 오류가 나더라도 현재 작동하는 항목을 보존하고 구독을 바로 삭제하지 마세요. 기존 서버에 연결할 수 있다는 사실은 해당 연결이 유효하다는 뜻일 뿐 구독 서버에도 접근할 수 있다는 뜻은 아닙니다. 반대로 구독 업데이트에 성공해도 포함된 모든 서버가 현재 연결된다는 보장은 없습니다.

주소 및 접속 조건 확인

사용자가 보유한 서비스의 관리 페이지에서 구독 주소 전체를 다시 복사하고 웹페이지 제목이나 설명을 복사하지 않았는지, 링크가 잘리지 않았는지 확인하세요. 링크의 쿼리 매개변수에 인증 정보가 들어 있을 수 있어 일부가 누락되면 작동하지 않을 수 있습니다. 복사한 주소 앞뒤에 공백이나 줄바꿈이 있는지 확인하되 주소를 짧게 만들려고 매개변수를 직접 삭제하지 마세요. 구독 주소는 민감한 연결 정보이므로 공개 댓글이나 스크린샷에 올리지 마세요.

업데이트 시 네트워크 경로를 비교하세요. 연결을 끊으면 업데이트되지만 연결 후 실패한다면 현재 요청 경로나 DNS 조건이 구독 서버에 맞지 않을 수 있습니다. 반대의 경우에는 사용자가 이미 보유한 정상 연결을 통해 업데이트해 보세요. 경로 차이만 확인할 수 있도록 같은 구독 주소를 유지하고 연결 상태만 바꿔 테스트하세요. 버튼을 반복해서 눌러도 잘못된 주소가 수정되지는 않으며 서버의 요청 횟수 제한이 작동할 수 있습니다.

인증, 권한, 요청 횟수 제한과 관련된 오류가 표시되면 원래 서비스 페이지에서 링크 상태와 접근 제한을 확인하세요. 웹페이지가 열린다고 구독 API에 접근 권한이 있는 것은 아닙니다. 관리 페이지와 구독 주소에 서로 다른 인증 방식이 적용될 수 있습니다. 브라우저 테스트는 응답 수신 여부를 확인하는 보조 수단일 뿐이며, 응답 페이지를 다른 사람에게 전달하지 마세요. 로그인 화면이 표시된다면 웹페이지 주소를 Subscribe에 넣어도 실제 구독 주소를 대신할 수 없습니다.

가져오기 성공과 파싱 성공 구분

내용을 받았는데도 가져오기에 실패한다면 응답이 클라이언트가 지원하는 구독 데이터인지 확인하세요. 로그인 페이지, 오류 안내, 전체 설정 파일은 구독 데이터가 아닙니다. 일부 API는 비활성화된 상태에서도 브라우저에서 읽을 수 있는 웹페이지를 반환하므로 텍스트가 보인다는 사실만으로 형식이 올바르다고 판단할 수 없습니다. 오류 메시지를 확인해 내용 형식, 빈 결과, 누락 필드 중 어떤 문제인지 파악한 뒤 사용 중인 서비스 관리자에게 설명하세요. 인코딩 방식을 추측해 임의로 바꾸지 마세요.

Subscribe에서 관리하는 서버 목록과 Config에서 관리하는 규칙 설정은 서로 다른 종류의 자료입니다. 전체 규칙 파일을 서버 구독으로 가져오거나 서버 공유 정보를 설정 파일로 활성화하면 파싱 오류가 발생할 수 있습니다. 자료의 용도를 확인한 뒤 올바른 메뉴를 선택하세요. 가져온 후에는 항목이 예상한 그룹에 표시되는지, 개수가 크게 달라지지 않았는지, 직접 추가한 기존 항목이 남아 있는지 확인하세요.

1. 기존 구독과 현재 사용할 수 있는 서버를 보존하고 이번 업데이트의 오류 메시지를 기록하세요.
2. 주소 전체를 다시 복사한 뒤 같은 네트워크에서 한 번만 시도해 오류가 동일한지 확인하세요.
3. 가져오기, 인증, 파싱 중 어느 단계에서 발생한 문제인지에 따라 해당 절차를 이어가세요.
4. 업데이트에 성공하면 그룹과 실제 매개변수를 확인하고 사용할 서버를 다시 선택해 요청을 테스트하세요.

업데이트 후 목록 변경 확인

업데이트 후 이름이 같은 항목이 여러 개 보인다면 메모를 기준으로 일괄 삭제하지 말고 소속 구독과 실제 주소를 확인하세요. 구독이 달라도 같은 이름 규칙을 사용할 수 있고 직접 추가한 항목이 구독 항목과 이름이 같을 수도 있습니다. 정리하기 전에 현재 선택한 항목의 출처와 Config 정책이 여전히 유효한 대상을 참조하는지 확인하세요. 서버 측에서 항목이 삭제되었다면 이전 선택 상태로 새 연결을 만들지 못할 수 있으므로 사용할 항목을 다시 선택해야 합니다.

업데이트에 성공했는데도 이전 매개변수가 계속 사용된다면 올바른 구독 항목을 업데이트했는지 확인한 다음 현재 선택한 서버가 별도로 만든 수동 복사본인지 살펴보세요. 같은 링크를 반복해서 가져오면 중복 출처만 늘어날 수 있습니다. 출처를 구분할 수 있도록 메모를 남기고 구독을 하나씩 업데이트한 뒤 주소나 필드가 바뀌었는지 비교하는 편이 안전합니다. 새 항목이 작동하는지 확인하기 전에는 삭제하지 마세요.

구독 및 서버 이용 조건은 사용자가 이미 보유한 서비스에서 정하며 클라이언트가 이를 대신하지 않습니다. 클라이언트 일회성 구매 ≠ 서버 이용 요금제. 이 사이트는 서버나 구독을 제공·판매·추천하지 않으며 기존 자료의 가져오기와 문제 해결 방법만 안내합니다. 처음부터 올바르게 가져오는 순서를 확인하려면 시작 가이드로 돌아가세요. 개념이나 사용법에 관한 간단한 질문은 자주 묻는 질문에서 확인할 수 있습니다.

05 / 성능 비교

연결 속도 저하

먼저 ‘느리다’는 증상을 재현 가능한 형태로 구체화하세요. 웹페이지가 처음 열릴 때 오래 걸리는지, 이미지가 하나씩 로드되는지, 파일 전송이 계속 느린지, 동영상이 간헐적으로 멈추는지 확인합니다. 각 증상은 서로 다른 단계와 관련이 있습니다. 처음 열 때만 느리고 이후에는 정상이라면 DNS 조회와 연결 설정을 먼저 살펴보세요. 장시간 전송 내내 느리다면 기본 네트워크, 원격 서버의 출구, 대상 서비스의 차이를 비교해야 합니다. Connectivity Test 한 번의 결과로 모든 사용 환경의 속도를 판단하지 마세요.

공정한 비교 조건 설정

같은 기기와 장소, 비슷한 시간대에 같은 대상을 이용해 비교하세요. 다른 대용량 작업을 종료하고 시스템 업데이트와 클라우드 동기화를 일시 중지해 백그라운드 사용량이 현재 요청에 영향을 주지 않도록 합니다. 연결을 끊은 상태의 결과를 기록한 다음 사용자가 보유한 서버끼리 비교하세요. 대상 파일, 앱 동작, 네트워크 유형을 동일하게 유지해야 합니다. 조건이 다르면 빠르거나 느린 이유가 콘텐츠 전송 서버 또는 캐시 상태 차이일 수 있습니다.

Wi-Fi 신호가 강하게 표시되어도 연결이 안정적이라고 볼 수는 없습니다. 거리, 같은 주파수 대역의 간섭, 라우터 부하, 업로드 사용량이 실제 성능에 영향을 줍니다. 라우터 가까이에서 다시 테스트하고 모바일 네트워크와도 비교해 보세요. 네트워크를 바꾼 뒤 같은 서버의 속도가 눈에 띄게 회복되면 로컬 네트워크를 우선 확인하세요. 테스트 중 모바일 데이터 사용량에 유의하고 대용량 파일을 반복해서 내려받지 마세요. 원래 증상을 재현하는 최소한의 작업으로도 충분합니다.

기존 서버 여러 개를 비교할 때도 동일한 방법을 사용해야 합니다. 연결 설정 시간이 짧다고 지속적인 전송 능력도 더 좋은 것은 아닙니다. 한 대상의 응답이 빠르다고 모든 대상에서 빠르다는 뜻도 아닙니다. 매개변수가 명확하고 정상 연결되는 기존 항목 두 개를 선택해 같은 작업을 각각 수행하세요. 모든 요청은 정상인데 특정 대상에서만 느리다면 대상 서비스 자체와 해당 요청 경로를 우선 확인하세요.

규칙 문제와 전송 문제 구분

Config와 Proxy를 비교해 Rule에 따라 처리할 때만 느려지는지 확인하세요. Proxy는 정상이지만 Config에서 느리다면 대상 요청이 실수로 Direct를 거치는지, 예상과 다른 정책을 참조하는지, 관련 리소스 도메인의 경로가 다른지 확인합니다. 한 페이지에서 여러 도메인으로 요청할 수 있으므로 본문은 정상인데 이미지가 느리다고 서버 전체가 느리다고 결론 내리지 마세요. 실제로 지연되는 리소스를 먼저 찾으세요.

모든 요청이 처음 열릴 때 느리고 이후 정상이라면 연결 기록을 살펴 DNS 조회, 핸드셰이크, 대상 응답 중 어느 단계에 시간이 걸리는지 확인하세요. 속도를 높이려고 DNS와 서버를 동시에 바꾸지 마세요. 서버를 고정한 상태에서 DNS 조건만 비교한 뒤 원래대로 돌리고 다음 항목을 테스트하세요. 특정 대상에서 효과가 있었던 변경이 전체 구성에 적합하다는 뜻은 아닙니다. 비교 결과를 기록하고 출처가 불분명한 ‘최적화 설정’을 쌓아 두지 마세요.

실시간 통신, 일부 게임, UDP를 사용하는 앱은 일반 웹페이지와 다른 전송 방식이 필요할 수 있습니다. 웹페이지가 열린다고 해당 전송도 정상이라는 뜻은 아닙니다. 사용자가 보유한 서비스가 해당 전송을 지원하는지 확인한 뒤 서버 항목과 Config의 관련 조건을 살펴보세요. 프로토콜 이름만으로 속도가 보장되는 것은 아니며 MTU 같은 하위 설정을 임의로 변경하지 마세요. 이런 조정에는 명확한 증상과 재현 가능한 테스트가 필요합니다.

최소한의 변경으로 복구

서버 측에서 특정 전송 매개변수를 안내했다면 다른 서비스의 설정을 참고하지 말고 현재 항목과 하나씩 비교하세요. TLS 또는 다른 핸드셰이크가 오래 걸리는 경우 기기 시간, 서버 이름, 네트워크 안정성을 먼저 확인합니다. 인증서 검사를 무시하는 것은 성능 개선 방법이 아닙니다. 네트워크를 바꾼 뒤 대상 앱이 계속 느리다면 앱을 종료하고 다시 연결해 이전 경로에 의존하는 기존 연결을 해제하세요.

장시간 전송 중 주기적으로 멈춘다면 기기가 절전 상태에 들어가는지, 백그라운드 활동이 제한되는지, 무선 네트워크가 전환되는지 확인하세요. 컴퓨터에서 시스템 프록시를 사용하는 경우 대상 앱이 실제로 해당 경로를 사용하는지도 확인해야 합니다. 클라이언트가 실행 중인지만 확인해서는 충분하지 않습니다. 결과는 ‘특정 네트워크, 대상, 모드에서 복구됨’처럼 기록하고 어떤 설정이 모든 기기에서 더 빠르다고 일반화하지 마세요.

06 / 도메인 조회

DNS 문제

DNS 문제 해결의 목적은 도메인에서 사용할 수 있는 주소를 얻었는지, 요청이 예상한 조회 경로를 사용했는지 확인하는 것입니다. 도메인에 접속할 수 없다고 반드시 DNS 문제인 것은 아닙니다. 이후 연결, TLS, 규칙에서도 실패할 수 있습니다. 먼저 DNS 조회 단계와 연결 단계 중 어느 곳에서 오류가 발생했는지 확인한 뒤 시스템 네트워크와 연결 내부의 동작을 비교하세요. 흔히 쓰이는 DNS 주소로 바꾸는 것만으로 원인을 확인할 수는 없으며, 원래 정상 작동하던 로컬 네트워크 이름이 조회되지 않을 수도 있습니다.

서버 도메인과 대상 도메인 구분

조회 대상은 적어도 두 종류입니다. 프록시 서버 자체의 도메인과 브라우저 또는 앱이 접속하려는 대상 도메인입니다. 전자의 조회에 실패하면 모든 프록시 요청을 설정하지 못할 수 있고, 후자는 일부 웹사이트에만 영향을 줄 수 있습니다. 먼저 오류가 어느 이름을 가리키는지 확인하세요. 대상 웹페이지에 접속할 수 없다고 서버 주소부터 바꾸지 마세요. 표기 오류를 확인할 때는 전체 도메인을 유지하고 구독 주소의 경로를 서버 이름으로 착각하지 않도록 주의하세요.

기본 네트워크가 정상일 때 서버 도메인을 조회할 수 있는지 먼저 확인한 다음 연결 내에서 대상 도메인의 결과를 확인하세요. 서버 주소가 IP여도 TLS 이름 검증이 필요할 수 있으므로 모든 문제를 우회하려고 도메인을 IP로 바꾸면 안 됩니다. 웹사이트의 IP 주소로 직접 접속하는 것도 일반적인 테스트 방법이 아닙니다. 많은 웹사이트는 올바른 호스트 이름과 인증서가 필요하므로 IP 접속 실패는 정상일 수 있으며 네트워크에 도달할 수 없다는 뜻은 아닙니다.

아래 General 조각은 시스템 DNS를 사용하는 설정 방식의 예시로, 기본 확인용일 뿐 모든 네트워크에 적합한 완전한 설정은 아닙니다. 수정 전에 현재 파일에 같은 이름의 설정이 있는지 확인해 서로 충돌하는 정의를 추가하지 않도록 하세요. 원본을 보존한 다음 비교할 항목 하나만 조정하고 요청을 새로 만드세요. 특정 조회 방식이 필요한 네트워크라면 해당 네트워크와 사용자가 보유한 서비스의 안내를 따르세요.

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

규칙과 함께 조회 결과 확인

도메인을 대상으로 하는 규칙과 IP 주소를 대상으로 하는 규칙에는 서로 다른 판단 조건이 필요합니다. DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD는 이름을 확인하고 IP-CIDR, IP-CIDR6, GEOIP는 주소를 확인합니다. 모든 실패를 규칙 순서 탓으로 돌리거나 도메인 규칙이 있다는 이유만으로 DNS가 무관하다고 판단하지 마세요. 실제 요청 기록에서 대상, 일치한 규칙, 적용된 정책을 확인한 뒤 살펴볼 단계를 결정하세요.

특정 Wi-Fi에서만 내부 이름이나 로컬 기기에 접속할 수 없다면 해당 네트워크가 자체 DNS에 의존하는지 먼저 확인하세요. 모든 조회를 외부 경로로 보내면 로컬 이름을 찾지 못할 수 있습니다. 프린터나 저장 장치 같은 로컬 네트워크 리소스는 주소 범위, 네트워크 격리, 관련 DIRECT 규칙도 확인해야 합니다. 기기를 찾을 수 있지만 서비스에 연결할 수 없다면 포트나 기기 권한 문제일 수 있으므로 DNS만 계속 변경하지 마세요.

IPv4와 IPv6의 연결 가능 여부가 다르면 조회에서 주소가 정상적으로 반환되어도 이후 경로에 도달하지 못할 수 있습니다. 특정 네트워크, 대상, 주소 유형에서만 문제가 발생하는지 먼저 비교하세요. 근거 없이 특정 주소 유형을 전역에서 비활성화하지 마세요. 네트워크 전환, 라우터 설정, 원격 서비스가 결과에 영향을 줄 수 있습니다. 기본 시스템 상태를 비교 기준으로 유지한 뒤 명확히 확인된 실패 경로에 한해 제한적으로 조정하세요.

캐시 및 재검증

설정을 바꾼 후에도 브라우저, 대상 앱, 시스템, 원격 서버가 이전 결과를 보유하고 있을 수 있습니다. 기존 요청을 종료하고 대상 앱을 닫았다가 다시 연 뒤 필요한 경우 연결을 끊었다가 다시 연결하고 새 기록을 확인하세요. 페이지를 한 번 새로고침해도 기존 연결이 재사용되면 새 DNS 설정의 적용 여부를 확인할 수 없습니다. 기기를 반복해서 재시작하는 것으로 원인 판단을 대신하지 마세요. 재시작으로 상태가 일시적으로 초기화될 수는 있지만 어떤 설정이 문제를 일으켰는지는 알 수 없습니다.

같은 도메인이 한 기기에서만 실패한다면 라우터 전체를 바꾸기 전에 기기 시간, 시스템 네트워크 설정, 현재 Config를 비교하세요. 같은 네트워크의 여러 기기에서 같은 문제가 발생하면 네트워크의 조회 조건을 먼저 확인해야 합니다. 결과를 기록할 때 네트워크 유형, 대상 이름, 오류 단계, 사용한 모드를 포함하되 구독 주소나 인증 정보를 공개할 필요는 없습니다. 내부 도메인이 포함된 기록도 먼저 적절히 가리세요.

07 / 백그라운드 실행

배터리 소모 및 백그라운드 실행 문제

배터리 사용량에서 차지하는 비율과 기기의 실제 배터리 소모량을 구분하세요. 다른 앱의 사용량이 줄어 특정 앱의 비율만 높아진 것일 수 있으므로 해당 앱의 소모량이 갑자기 증가했다고 단정할 수 없습니다. 화면 밝기, 신호, 사용 시간, 네트워크 조건이 비슷한 상태에서 비교하고 기기 온도, 백그라운드 작업, 시스템 업데이트도 확인하세요. 연결이 다른 앱의 네트워크 요청을 처리하면 해당 활동이 통계에 포함될 수 있으므로 백분율 하나만 보고 클라이언트 문제라고 판단하지 마세요.

반복 연결 및 백그라운드 요청 확인

연결이 불안정하면 세션을 반복해서 설정하는 과정에서 무선 통신과 처리 부담이 늘어날 수 있습니다. 잦은 연결 해제, 네트워크 전환, 인증 실패가 있는지 확인하고 안정적인 네트워크에서 비교하세요. 고정된 네트워크에서 같은 서버가 계속 다시 연결된다면 원격 연결 문제부터 해결해야 합니다. 테스트 횟수를 줄이면 추가 활동은 감소하지만 반복 연결의 근본 원인은 해결되지 않습니다. 신호가 약한 장소에 있었는지도 별도로 기록하세요.

On Demand는 조건을 충족하면 연결을 자동으로 설정할 수 있으므로 수동으로 끈 뒤 연결이 다시 나타나도 스위치 오류라고 단정할 수 없습니다. 현재 네트워크와 관련된 조건이 설정되어 있는지, 서로 겹치는 자동 규칙이 여러 개 있는지 확인하세요. 문제를 살펴보는 동안 기존 조건을 기록한 뒤 자동 연결을 잠시 끄고 수동으로 비교하세요. 동작 방식을 확인한 뒤 필요한 조건만 복원하세요. 자동 연결을 계속 요구하면서 연결이 다시 설정될 때마다 오류로 판단하지 마세요.

사진을 계속 업로드하거나 파일을 동기화하고, 메시지를 새로고침하거나 오프라인 콘텐츠를 내려받는 앱이 있는지 확인하세요. 백그라운드 요청이 발생하면 브라우저를 열지 않아도 연결이 계속 활성 상태일 수 있습니다. 같은 네트워크에서 해당 작업을 잠시 일시 중지하고 대기 중 상태를 확인한 다음 하나씩 다시 켜세요. 여러 시스템 기능을 한꺼번에 끄고 문제가 해결됐다고 판단하지 마세요. 실제 영향을 준 항목을 알 수 없고 일상적인 알림과 동기화에 문제가 생길 수 있습니다.

문제 해결 도구로 인한 영향 줄이기

Connectivity Test, 반복 새로고침, 상세 로그도 추가 요청과 기록 작업을 발생시킵니다. 문제 해결이 끝나면 더 이상 필요하지 않은 반복 테스트를 중단하고 앱에서 제공하는 옵션에 따라 일반적인 기록 수준으로 돌리세요. 로그를 보관해야 한다면 재현 시간을 제한하고 시작과 종료 동작을 기록한 뒤 필요한 부분만 수집하세요. 기록을 너무 오래 쌓으면 검토가 어려워지고 공개하면 안 되는 접속 대상이나 연결 정보가 포함될 수 있습니다.

배터리 소모를 판단할 때는 연결을 막 켠 직후의 순간적인 변화가 아니라 비슷한 작업을 포함하는 일정한 관찰 시간을 사용하세요. 충전 상태, 기기 발열, 시스템의 백그라운드 정리 작업이 결과를 흐릴 수 있습니다. 먼저 평소 사용 상황을 비교한 뒤 대기 상태도 확인하세요. 고부하 전송 중에만 배터리 소모가 늘어난다면 실제 전송량을 함께 고려해야 합니다. 요청이 거의 없는데도 계속 비정상적으로 소모된다면 재연결, 백그라운드 작업, 진단 활동을 중점적으로 확인하세요.

Android의 배터리 관리가 백그라운드 앱 실행을 제한하면 화면을 잠근 뒤 연결이 끊겼다가 잠금을 해제하면 복구될 수 있습니다. 먼저 시스템에서 Shadowrocket의 백그라운드 활동을 제한하고 있는지 확인하고 기기 사용에 필요한 범위에서 관련 설정을 조정하세요. 처음부터 모든 앱의 제한을 해제할 필요는 없습니다. 시스템마다 옵션 이름이 다를 수 있으므로 현재 기기의 안내를 따르세요. 조정 후 알림, 대기 상태, 연결 유지 여부를 비교하고 화면을 켠 상태의 웹페이지 테스트만으로 판단하지 마세요.

기기 온도와 절전 문제 별도 확인

컴퓨터가 절전 모드에서 깨어난 직후에는 네트워크가 아직 복구되지 않아 연결이 다시 설정될 수 있습니다. 시스템 네트워크가 준비될 때까지 기다린 뒤 원래 요청을 다시 보내고 문제가 절전 해제 후에만 발생하는지 확인하세요. 절전 후 매번 앱을 다시 열어야 한다면 절전 전후의 네트워크 유형과 오류를 기록하고 네트워크 인터페이스가 바뀌었는지 확인합니다. 문제를 숨기려고 기기의 절전을 계속 금지하지 마세요. 전력 사용 기준만 달라지고 연결 복구 절차는 해결되지 않습니다.

기기가 뚜렷하게 뜨거워지면 고부하 전송을 중지하고 정상 온도로 돌아온 뒤 성능을 판단하세요. 온도 관리는 처리 속도에 영향을 주므로 속도 저하와 배터리 소모가 같은 부하에서 비롯된 증상일 수 있습니다. 연결을 끊어도 계속 뜨겁다면 규칙을 변경하지 말고 시스템과 다른 앱의 활동을 확인하세요. 배터리 상태, 충전 환경, 무선 신호도 결과를 바꿀 수 있으므로 클라이언트 설정과 별도로 고려해야 합니다.

08 / 변경 사항 복구

업데이트 후 오류

업데이트 후 문제가 생겼다고 앱 업데이트만이 원인이라고 단정할 수는 없습니다. 같은 시기에 구독 내용, Config, 시스템 버전, 네트워크가 함께 변경되었을 수도 있습니다. 마지막으로 정상 작동했던 시점부터 처음 실패한 시점까지의 변경 사항을 정리한 뒤 확인 순서를 정하세요. 앱 삭제, 구독 초기화, 네트워크 재설정을 한꺼번에 하지 마세요. 비교에 필요한 원래 상태가 사라지고 제한적인 문제가 전체 재설정이 필요한 복잡한 문제로 바뀔 수 있습니다.

자료를 보존한 뒤 영향 범위 확인

현재 Config, 수동 서버, 필요한 구독 정보를 백업하고 사본을 로컬에서 찾을 수 있는지 확인하세요. 백업 파일에는 비밀번호, 인증 정보, 전체 구독 주소가 들어 있을 수 있으므로 안전한 위치에 보관하고 공개하지 마세요. 그런 다음 앱 실행 실패, 연결 직후 종료, 모든 요청 실패, 특정 대상만 실패 중 어떤 문제인지 구분하세요. 각각 시작, 권한, 연결, 규칙 단계에 해당하므로 모두 재설치로 해결하려고 하지 마세요.

앱 업데이트 후 처음 실행할 때 새로운 시스템 권한 안내가 나타나면 안내 출처를 확인하고 필요한 권한을 승인한 뒤 다시 테스트하세요. 시스템 업데이트로 기존 권한 상태가 바뀌었을 수 있습니다. 연결 구성이 남아 있더라도 권한 조건까지 그대로라고 단정할 수 없습니다. 특정 Config만 불러올 수 없다면 오류 메시지를 보존하고 최근에 정상 작동한 로컬 사본을 활성화해 보세요. 사본이 작동한다면 서버를 계속 바꾸기보다 설정 내용을 비교해야 합니다.

최근 Subscribe와 앱을 모두 업데이트했다면 먼저 현재 선택된 서버의 실제 매개변수가 바뀌었는지 확인한 뒤 Config의 정책 참조가 여전히 유효한지 살펴보세요. 이전 이름이 제거되었거나 그룹이 바뀌었거나 항목이 교체되면 업데이트 후 연결 오류처럼 보일 수 있습니다. 사용자가 보유한 매개변수가 명확한 항목 하나로 테스트하면 목록 변경의 영향을 줄일 수 있지만 백업 없이 전체 구독을 삭제하지 마세요.

플랫폼별 설치 및 실행 허용 확인

iPhone과 iPad 앱 업데이트는 App Store에서 진행하며 시스템 요구 사항은 App Store 페이지에 표시된 내용을 기준으로 합니다. 다시 설치하기 전에 백업과 원래 구매 계정을 확인하세요. 앱을 삭제하면 로컬 설정도 함께 삭제될 수 있으며 스토어의 구매 내역은 설정 백업과 다릅니다. 정품 여부를 확인할 때는 공식 아이콘, 개발자 Shadow Launch Technology Limited, 앱 ID 932747118을 확인하세요. 자세한 절차는 정품 확인을 참고하세요.

Mac, Windows, Android, Linux용 최신 설치 파일은 사이트 다운로드 페이지에서 받을 수 있으며 페이지의 동적 링크가 /dl/shadowrocket/ 경로로 연결됩니다. Mac에서는 이 Mac에 관하여에서 Apple 실리콘 또는 Intel을 확인하세요. Windows는 페이지 안내에 따라 설치 파일을 선택하고 Linux는 배포판에 맞는 형식을 선택합니다. 업데이트 문제를 해결하려고 다른 아키텍처나 출처가 불분명한 파일을 섞어 사용하지 마세요. 별도의 시작 오류가 생길 수 있습니다.

처음 실행할 때 차단되면 Mac은 출처를 확인한 뒤 개인정보 보호 및 보안에서 그래도 열기를 선택할 수 있습니다. Windows는 SmartScreen의 추가 정보에서 확인한 뒤 그래도 실행을 선택하세요. Android는 안내에 따라 현재 다운로드 앱의 알 수 없는 앱 설치를 허용하고 설치 후 필요한 경우 권한을 해제합니다. Mac에서 앱이 손상되었다는 메시지가 표시되면 먼저 다운로드가 완료되었는지와 출처를 확인하고 설치 페이지의 해당 안내를 참고하세요. 전체 보안 설정을 끄지는 마세요.

xattr -cr /Applications/Shadowrocket.app

아래 명령은 파일 출처를 확인했고 앱이 해당 경로에 있을 때 Mac 파일의 확장 속성을 처리하는 용도입니다. 모든 실행 오류를 해결하는 명령은 아닙니다. 앱을 종료한 뒤 실행하고 경로가 실제 설치 위치와 일치하는지 확인하세요. Linux의 AppImage에는 실행 권한이 필요하며 deb와 rpm은 해당 패키지 관리 절차에 따라 종속성을 확인해야 합니다. 설치 단계의 처리가 끝난 뒤 연결 및 요청 테스트로 돌아가 두 종류의 문제를 혼동하지 마세요.

복구 확인 및 문의 내용 정리

한 가지 변경을 완료할 때마다 처음 실패했던 작업을 다시 실행하고 업데이트 전 정상 작동한 사본과 비교하세요. 새로 추가한 설정에서만 실패한다면 차이만 보존하세요. 같은 네트워크에서 모든 설정이 실패한다면 시스템 네트워크와 권한 변경을 확인해야 합니다. 메인 화면이 열린다는 사실만으로 복구를 단정하지 말고 연결, DNS 조회, 대상 앱을 모두 테스트하세요. 복구 후에는 문제 해결용 임시 파일과 실제 활성화할 파일을 구분해 다음에 테스트 사본을 잘못 선택하지 않도록 하세요.

문의에는 기기 OS, 설치 경로, 문제가 발생한 단계, 오류 메시지, 최소 재현 절차를 포함하세요. 버전 정보가 필요하면 현재 앱에 표시된 값을 확인하고 오래된 스크린샷으로 추측하지 마세요. 서버 인증 정보와 구독 링크를 가린 뒤 필요한 기록을 제공하세요. Mac 및 Windows의 칩 종류 선택과 첫 실행 절차는 데스크톱 설치 및 실행 허용 안내에서 확인할 수 있습니다.

09 / 기기별 문제

iPad 문제 해결

iPad 문제도 네트워크, 서버, 설정, 요청 순서로 확인하되 Wi-Fi 전용 모델인지, 모바일 네트워크를 지원하는 모델인지, 멀티태스킹 상태에서 앱이 어떻게 동작하는지도 구분해야 합니다. iPhone에서 같은 메모의 서버가 연결된다고 iPad 문제라고 바로 판단하지 마세요. 두 기기의 네트워크, Config, 실제 매개변수가 다를 수 있습니다. 먼저 테스트 조건을 맞춘 뒤 기기 간 차이를 비교해야 환경 차이를 플랫폼 문제로 오인하지 않습니다.

두 기기의 비교 조건 맞추기

iPhone과 비교할 때는 두 기기를 같은 정상 Wi-Fi에 연결하고 매개변수가 같은 기존 서버를 선택한 뒤 활성화된 Config 내용과 Global Routing이 같은지 확인하세요. 그런 다음 브라우저에서 같은 요청을 실행합니다. 서버 이름만 비교해서는 부족합니다. 같은 이름의 항목도 서로 다른 구독이나 업데이트 시점에서 가져왔을 수 있습니다. 설정 파일 이름만 비교하는 것도 충분하지 않으므로 실제 규칙 내용과 최근 변경 사항을 확인하세요.

Wi-Fi 전용 iPad는 Wi-Fi를 끄는 방식으로 모바일 네트워크와 비교할 수 없으므로 상황이 허용된다면 이미 사용 가능한 다른 네트워크에 연결하세요. 휴대폰 핫스팟을 사용한다면 원래 Wi-Fi를 반복 테스트하는 것이 아니라 새로운 네트워크 경로라는 점을 유의하세요. 모바일 네트워크 지원 모델은 데이터 연결이 정상인지, 대상 앱이 해당 네트워크를 사용할 수 있는지도 확인해야 합니다. 연결을 시작하기 전에 기본 네트워크가 정상인지 먼저 확인하세요.

화면 분할 또는 다른 멀티태스킹 상태에서 대상 앱이 이전 세션을 유지할 수 있습니다. Global Routing을 바꾼 뒤 진행 중인 요청을 종료하고 대상 페이지를 다시 여세요. 필요한 경우 대상 앱을 종료하고 재시도합니다. 분할 화면에 이전 페이지가 계속 표시된다고 네트워크가 정상이라고 판단하지 마세요. 캐시된 내용일 수 있습니다. 반대로 백그라운드 앱이 일시적으로 새로고침되지 않는다고 연결이 끊어진 것도 아닐 수 있으므로 실제 요청을 새로 보내 확인하세요.

화면 잠금 및 네트워크 전환 문제

화면을 잠근 뒤에만 문제가 발생한다면 잠금을 해제했을 때 시스템 네트워크가 복구되었는지, 클라이언트 연결이 유지되는지, 대상 앱을 다시 열면 복구되는지 기록하세요. 백그라운드에서 앱이 멈추는 것과 시스템 연결이 사용 가능한지는 서로 다른 문제입니다. 브라우저에서 새 요청을 보내 확인한 뒤 특정 앱의 세션 복구 문제인지 판단하세요. 스위치를 반복해서 누르면 복구 중인 연결이 다시 설정되어 정상적으로 완료될 수 있는 복구 과정을 방해할 수 있습니다.

학교, 회사, 공용 Wi-Fi는 정기적인 재인증을 요구하거나 기기별로 권한을 부여할 수 있습니다. iPhone에서 인증을 완료했더라도 iPad가 자동으로 같은 조건을 갖는 것은 아닙니다. 연결을 끊고 인증 페이지를 열어 네트워크 사용 권한을 확인한 뒤 Shadowrocket에 다시 연결하세요. 조직에서 관리하는 iPad는 VPN 구성이나 네트워크 사용이 제한될 수 있으므로 관리자에게 허용되는 사용 방식을 확인하세요. 무엇인지 알 수 없는 관리 자료를 삭제하지 마세요.

로컬 프린터, 저장 장치, 기타 로컬 네트워크 서비스에 접근해야 한다면 iPad와 대상 기기가 서로 통신할 수 있는 네트워크에 있는지 확인한 다음 Config에서 로컬 주소가 어떻게 처리되는지 살펴보세요. 로컬 네트워크 권한, 네트워크 격리, 규칙 경로 모두 결과에 영향을 줄 수 있습니다. 연결을 끊은 상태에서 접근되는지 확인한 뒤 Config와 Direct를 비교하세요. 로컬 기기 하나에 접근하려고 모든 요청을 계속 직접 연결로 바꾸지 마세요. 필요한 부분만 정확히 조정하는 편이 관리하기 쉽습니다.

구매 복원 및 데이터 이전

iPhone/iPad용은 App Store에서 $2.99 일회성으로 구매하며 두 기기에서 같은 구매 계정으로 구입한 앱을 복원할 수 있습니다. Mac, Windows, Android, Linux용은 무료입니다. 가격과 플랫폼별 제공 방식은 각각 구분해야 하며 데스크톱 버전은 모바일 스토어 구매 절차에 포함되지 않습니다. iPad의 구체적인 시스템 요구 사항은 App Store 제품 페이지에 표시된 내용을 기준으로 하며 다른 기기에 설치할 수 있는지를 근거로 추정하지 마세요.

기기를 바꾸거나 앱을 다시 설치할 때는 먼저 원래 구매 계정으로 로그인했는지 확인한 다음 구입 항목에서 앱을 찾으세요. 앱을 복원해도 모든 수동 설정이 자동으로 복구되는 것은 아니므로 이전하기 전에 사용자가 보유한 구독 정보와 Config를 저장해야 합니다. 앱은 복원됐는데 목록이 비어 있다면 다시 구매하지 말고 자료 이전 문제로 확인하세요. 자세한 절차는 구입 항목 복원 안내를 참고하고, 처음부터 다시 가져오려면 시작 가이드를 따르세요.

마지막으로 원래 사용 환경에서 점검하세요. 연결 후 새 웹페이지 요청을 보내고, 이전에 실패한 앱을 열고, 화면을 잠갔다 해제한 뒤 다시 테스트하며 필요한 경우 로컬 네트워크 서비스도 확인합니다. ‘iPad가 안 돼요’라는 설명보다 어떤 단계에서 복구되었는지, 어떤 조건에서 문제가 계속되는지 기록하는 편이 원인을 좁히기 쉽습니다. 개념에 관한 질문은 자주 묻는 질문에서 확인하세요. 명확한 오류가 있다면 전체 설정을 다시 지우지 말고 이 페이지의 해당 항목으로 돌아가 같은 근거를 따라 확인하세요.