Shadowrocket 문제 해결 가이드

02　연결됐지만 인터넷이 되지 않음: 모드와 규칙 구분

VPN 표시가 나타난 것은 기기에 로컬 통로가 설정되었다는 뜻이지, 모든 연결이 대상까지 정상적으로 전달된다는 뜻은 아닙니다. 선택한 서버, Global Routing 모드, 현재 Config와 DNS가 결과에 영향을 줍니다. 원래 접속할 수 있어야 하는 테스트 대상 두 개를 준비하세요. 하나는 로컬 네트워크 확인용, 다른 하나는 기존 서버의 전달 여부 확인용입니다. 두 대상 모두 익숙한 일반 페이지를 사용하고, 특정 앱의 콘텐츠 로딩만으로 판단하지 마세요.

서버를 고정한 뒤 세 가지 모드를 비교하세요

Home으로 돌아가 SERVER에서 실제 선택된 항목을 확인하세요. 목록에 표시된다고 선택된 것은 아니며, 구독 업데이트 후 항목 순서가 바뀌어 잘못 선택했다고 착각할 수도 있습니다. 선택된 항목에서 Connectivity Test를 실행하고 결과를 기록하세요. 테스트에 수치가 나타나도 해당 경로에서 응답을 받았다는 뜻일 뿐, 모든 웹사이트와 전송 방식, DNS 조회가 정상이라는 의미는 아닙니다.

이어서 Global Routing을 확인하세요. Config 모드는 현재 Config에 따라 트래픽을 처리하고, Proxy 모드는 현재 서버를 통한 접속을 확인하며, Direct 모드는 로컬 네트워크 경로와 비교할 때 사용합니다. 문제를 찾기 위한 임시 전환은 장기적인 해결책이 아닙니다. 기존 모드를 기록한 뒤 전환하고, 매번 같은 테스트 대상을 사용하세요. 테스트가 끝나면 원래 모드로 복원합니다.

Proxy에서는 접속되지만 Config에서는 되지 않는다면 비밀번호를 계속 확인할 상황은 아닙니다. Config에서 현재 활성화된 파일을 확인하고, 대상이 REJECT에 일치했는지, 존재하지 않거나 올바르게 설정되지 않은 정책으로 지정됐는지 살펴보세요. Direct는 정상이지만 Proxy가 실패하더라도 곧바로 규칙 문제라고 단정할 수는 없습니다. 서버 시간 초과와 DNS 항목을 확인해 원인을 더 구분하세요.

실제로 일치한 결과를 바탕으로 규칙 순서 확인

규칙은 보통 순서대로 일치하므로 앞쪽의 포괄적인 규칙이 연결을 먼저 처리할 수 있습니다. DOMAIN-SUFFIX는 지정된 도메인과 하위 도메인에 적용되고, IP-CIDR은 IP 주소 대역에 적용되며, FINAL은 앞에서 일치하지 않은 연결을 처리합니다. 문제를 찾을 때는 파일에서 관련 있어 보이는 규칙만 찾지 말고 실제 대상과 규칙 일치 결과를 확인하세요. 한 웹페이지도 여러 하위 도메인에 요청을 보낼 수 있으므로, 메인 페이지가 열린다고 이미지와 로그인 API까지 정상이라는 뜻은 아닙니다.

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

위 내용은 규칙 순서의 예시이며 모든 네트워크에 적용되는 완전한 설정은 아닙니다. 더 구체적인 ads.example.com을 포괄적인 example.com보다 앞에 두어야 앞의 접미사 규칙이 먼저 처리하지 않습니다. GEOIP는 주소의 지역 정보를 사용하므로 모든 도메인 규칙을 대신할 수 없습니다. 이 예시를 현재 사용하는 Config에 통째로 덮어쓰지 마세요. Config를 복사한 뒤 문제가 확인된 규칙 하나만 수정하세요.

앱 문제와 네트워크 문제 구분

Safari에서는 접속되는데 특정 앱만 실패한다면 해당 앱이 별도 도메인, 실시간 통신 또는 추가 전송 방식을 사용하는지 확인하세요. 앱을 다시 열면 새 연결을 만들 수 있지만 로그인 정보를 바로 삭제하지는 마세요. 페이지 콘텐츠가 캐시에서 제공되면 오래된 내용이 보여도 테스트가 성공한 것은 아닙니다. 새로고침해 새 요청이 완료됐는지 확인한 뒤 연결 기록에서 해당 시각과 대상을 확인하세요.

규칙을 하나 수정할 때마다 같은 요청을 다시 보내 오류가 사라졌는지 확인하세요. 네트워크를 바꾼 뒤에만 정상화된다면 그 조건을 기록하고 로컬 네트워크와 DNS 조회를 계속 확인하세요. 우연히 복구된 현상을 마지막으로 한 무관한 수정의 결과로 보지 마세요. 더 짧은 점검 목록은 스위치는 켜졌지만 인터넷이 안 될 때 단계별 점검을 확인하세요. 처음 연결하는 방법은 사용 설명서를 참고하세요.

04　구독 업데이트 실패: 가져오기와 내용 해석 구분

구독을 가져오려면 최소 두 단계가 필요합니다. 주소에서 내용을 받아온 다음, 그 내용을 서버 항목으로 해석해야 합니다. 주소가 열려도 유효한 구독 내용이 반환된다는 뜻은 아니며, 항목을 가져와도 현재 연결할 수 있다는 뜻은 아닙니다. 주소 조회, 반환 내용, 항목 해석, 서버 연결 중 어느 단계에서 실패했는지 먼저 확인하세요. 기존 서버를 사용할 수 없을 때 문제를 무조건 구독 업데이트 탓으로 돌리지 마세요.

주소와 계정 상태부터 확인

사용자 본인의 서비스 제공업체에서 구독 주소를 다시 복사한 뒤 시작 부분, 끝 부분과 쿼리 매개변수가 완전한지 확인하세요. 계정을 식별하는 인증 정보가 포함된 주소는 문자 하나만 빠져도 접속 거부가 반환될 수 있습니다. 복사할 때 안내 문구, 따옴표 또는 끝의 문장 부호가 주소 항목에 들어가지 않도록 하세요. 길어 보이는 쿼리 매개변수도 임의로 삭제하지 마세요. 긴 주소는 비공개 환경에서 확인하고 공개 게시판에 붙여 넣지 마세요.

페이지에서 먼저 로그인하라고 하거나 계정 관련 안내를 반환한다면, 바로 읽을 수 있는 구독 내용과는 다른 접근 방식입니다. 서비스 제공업체가 클라이언트용으로 안내한 구독 주소를 사용하고 관리 페이지 주소를 대신 쓰지 마세요. 구독 내용은 여러 인코딩이나 형식을 사용할 수 있으므로 브라우저에 텍스트가 보인다는 이유만으로 오류라고 판단할 수 없습니다. 웹페이지 본문을 저장해 Config 파일처럼 가져오지 마세요.

사용자가 이미 이용 중인 서비스의 유효 기간과 사용 제한도 확인하세요. 앱의 일회성 구매와 원격 서비스 요금은 별개이며, 앱을 한 번 구매해도 회선 요금제가 포함되지는 않습니다. 앱 구매에 성공해도 서버 정보가 자동 생성되지는 않습니다. 이 사이트는 가져오기와 점검 방법만 안내하며 구독 주소를 제공하지 않습니다. 계정 상태나 주소 유효성은 사용자가 본인의 서비스 제공업체에 확인해야 합니다.

반환 결과에 따라 다음 단계를 결정하세요

업데이트 중 네트워크 시간 초과가 발생하면 기본 네트워크를 확인한 뒤 구독 도메인의 조회 및 접속 경로를 점검하세요. 인증 오류라면 주소가 만료되었는지, 인증 정보가 재설정되었는지 먼저 확인하세요. 해석 실패가 나타나면 반환 내용이 구독 형식인지, 로그인 페이지나 안내 페이지 또는 빈 내용으로 바뀌지 않았는지 확인합니다. 모든 오류를 ‘서버 노드 문제’로 단정하지 마세요. 서버 목록을 가져오기도 전에 실패하는 경우도 있습니다.

사용 가능한 연결이 이미 있을 때는 현재 연결 상태, 라우팅과 DNS 조회가 구독 요청에 영향을 줄 수 있습니다. 주소는 그대로 둔 채 연결을 끊은 상태와 현재 연결이 사용 가능한 상태에서 각각 한 번씩 시도하고 차이를 기록하세요. 이 테스트는 주소에 접속하는 경로를 확인하기 위한 것이지 특정 모드를 계속 사용하라는 뜻이 아닙니다. 두 상태 모두 실패하면 기본 네트워크를 바꿔 재시험하세요. 새로고침만 계속하는 방식으로 비교를 대신하지 마세요.

짧은 시간 동안 업데이트를 반복하면 원격 요청 제한이 걸릴 수 있습니다. 제한 안내가 나타나면 서비스 제공업체가 안내한 조건에 따라 기다리고, 같은 주소를 계속 삭제하고 다시 추가하지 마세요. 다시 가져오기 전에 구독 기록을 수정해야 한다면 기존 기록 이름과 필요한 설정을 먼저 저장하고, 이전 항목을 다른 Config에서 참조하는지 확인하세요. 무턱대고 목록을 비우면 정상적으로 사용할 수 있던 선택 관계까지 함께 깨질 수 있습니다.

가져온 뒤 목록과 선택된 항목 확인

업데이트가 끝나면 항목 수와 이름이 예상한 대로인지 확인한 뒤 현재 선택된 SERVER를 살펴보세요. 이전 항목이 삭제되거나 이름이 바뀌면 기존 선택이 원하는 접속 지점을 가리키지 않을 수 있습니다. 사용자가 보유한 항목 하나를 선택해 Connectivity Test를 실행한 뒤 실제 페이지를 요청하세요. 목록 업데이트, 올바른 항목 선택, 연결 성공의 세 단계가 모두 통과해야 업데이트 목적을 달성했다고 볼 수 있습니다.

구독으로 생성된 항목을 직접 수정하면 다음 업데이트 때 변경 내용이 덮어써질 수 있습니다. 차이를 유지해야 한다면 별도로 기록하고, 필요하면 원래 구독에 영향을 주지 않는 복사본에서 확인하세요. 구독은 보통 서버 정보를 관리하고 Config는 규칙과 기타 설정을 제어하므로, 둘은 서로를 자동으로 대체하지 않습니다. 서버를 가져온 뒤에도 기존 사용 방식에 맞는 Config와 Global Routing인지 확인해야 합니다.

06　DNS 문제: 도메인 조회와 연결을 따로 확인

DNS는 도메인을 주소로 변환합니다. 서버 지연 테스트 결과는 있지만 웹페이지에서 호스트를 찾을 수 없다고 표시되거나 로딩이 오래 걸리고 일부 리소스가 보이지 않는다면 도메인 조회를 별도 단계로 확인하세요. 브라우저의 인증서 오류와 도메인 조회 실패는 서로 다른 문제라는 점도 기억하세요. 구체적인 도메인, 오류 문구와 발생 당시 연결 모드를 기록한 뒤 요청이 주소를 받았는지, 어떤 유형의 주소를 받았는지 확인하세요.

현재 Config와 조회 경로부터 확인

Config에서 실제로 활성화된 파일을 확인하고 DNS에 영향을 주는 설정을 찾으세요. 활성화되지 않은 파일만 수정하면 실제 동작은 바뀌지 않습니다. 사용자 지정 DNS 서비스, Host 매핑 또는 기타 DNS 관련 재정의가 있다면 원래 값을 먼저 기록하고 현재 요청을 어떤 계층에서 처리하는지 구분하세요. 시스템, 라우터와 앱 내 설정이 함께 관여할 수 있으므로 매번 같은 DNS 경로를 사용한다고 가정하지 마세요.

문제가 발생한 전체 도메인 하나를 정상 도메인 하나와 비교하세요. 앱에서 사용할 수 있는 진단 기능과 연결 기록을 통해 DNS 결과가 있는지, 시간 초과가 발생했는지, 후속 연결이 진행되는지 살펴봅니다. 도메인이 주소를 받았지만 이후 TCP 또는 TLS에서 실패한다면 문제는 이미 네트워크와 핸드셰이크 단계로 넘어간 것입니다. DNS를 반복해서 바꾸면 대상 주소만 달라질 뿐 실제 장애는 해결되지 않을 수 있습니다.

사용자 지정 DNS 서비스에도 네트워크 연결이 필요합니다. 해당 주소를 조회하는 과정이 아직 완료되지 않은 DNS 조회에 의존한다면 시작 단계에서 의존성 문제가 발생할 수 있습니다. 설정에서 DNS 요청이 실제로 어디로 향하는지, 연결 전후에 동작이 달라지는지 확인하세요. DNS 서비스 변경, Global Routing 수정과 규칙 삭제를 동시에 진행하면 어느 단계에서 조회 경로가 바뀌었는지 알 수 없습니다.

Host, IPv6와 네트워크 차이 확인

오래된 Host 매핑은 도메인을 예전 주소로 고정해 정상적인 DNS 변경을 가릴 수 있습니다. 먼저 Config 복사본에서 문제 도메인과 관련된 매핑을 비활성화한 뒤 다시 요청하세요. 콘텐츠 배포를 사용하는 사이트는 주소를 고정하면 현재 네트워크에 맞는 접속 위치를 선택하지 못할 수도 있습니다. 우연히 작동한 주소를 계속 고정하지 말고, 직접 주소에 접속한 결과를 도메인 전체 접속 테스트 대신 사용하지 마세요.

일부 네트워크는 IPv6 주소를 반환해도 IPv6 연결이 안정적이지 않을 수 있습니다. 특정 네트워크에서만 문제가 발생한다면 실패한 연결이 실제로 IPv4와 IPv6 중 어느 쪽을 사용했는지 확인하고 기본 네트워크 테스트 결과와 함께 살펴보세요. 특정 유형의 주소가 반환됐다는 이유만으로 DNS 오류라고 단정하지 마세요. 주소 체계 관련 설정을 임시로 조정한다면 원래 값을 기록하고 네트워크를 바꾼 뒤에도 다시 확인하세요. 한 환경의 문제를 해결하면서 다른 환경을 망가뜨리지 않도록 해야 합니다.

로컬 네트워크 기기 이름, 내부 도메인과 공용 도메인에는 서로 다른 DNS 경로가 필요할 수 있습니다. 공용 DNS 서비스는 로컬 기기 이름을 알지 못할 수 있으며, 회사나 가정의 내부 리소스는 현재 네트워크의 DNS 정보에 의존할 수 있습니다. 내부 리소스만 실패하면 로컬 네트워크와 접속 경로를 먼저 확인한 뒤 해당 도메인이 원격으로 잘못 전달되는지 살펴보세요. 모든 도메인을 같은 DNS 서비스로 보내는 것이 항상 맞는 방법은 아닙니다.

도메인 규칙과 주소 규칙의 차이 이해

DOMAIN과 DOMAIN-SUFFIX는 도메인에 직접 적용되고 IP-CIDR과 GEOIP는 주소를 대상으로 합니다. 일부 주소 규칙은 DNS 결과를 바탕으로 판단하므로 규칙 일치와 DNS는 완전히 독립적이지 않습니다. 점검할 때는 먼저 구체적인 도메인 규칙으로 정책을 확인하고 주소 규칙이 결과를 바꾸는지 살펴보세요. 대상 도메인을 확인하기도 전에 범위가 넓은 키워드 규칙을 계속 추가하면 관련 없는 요청까지 영향을 받을 수 있습니다.

[Rule]
DOMAIN,portal.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,10.0.0.0/8,DIRECT
FINAL,PROXY

이 예시는 구체적인 규칙을 포괄적인 규칙보다 먼저 배치해야 한다는 점을 설명할 뿐, 실제 네트워크 구성 방법을 대신하지 않습니다. portal.example.com은 설명용 도메인이며 실제 서비스 주소가 아닙니다. 수정한 뒤 새 연결에서 새 결과가 적용되도록 요청을 다시 보내세요. 시스템과 앱의 캐시 때문에 이전 결과가 한동안 유지될 수 있습니다. 저장 직후 변화가 없다고 설정이 적용되지 않았다고 단정하지 마세요.

DNS 조회가 정상이라고 판단하려면 도메인에서 적절한 주소를 얻고, 요청이 예상한 정책을 따르며, 실제 페이지가 로드되어야 합니다. 자세한 내용은 DNS 설정 및 조회 실패 점검을 참고하세요. 용어가 익숙하지 않다면 먼저 용어 빠른 확인을 읽고 현재 문제가 발생한 도메인으로 돌아와 점검하세요. DNS 설정 전체를 한 번에 다시 작성할 필요는 없습니다.

08　업데이트 후 문제와 iPad: 기기별 차이 확인

업데이트 후 문제가 발생했다면 먼저 어느 단계에서 변화가 있었는지 확인하세요. 앱 업데이트, 시스템 업데이트, 구독 새로고침, Config 교체 또는 네트워크 변경이 원인일 수 있습니다. 같은 날 발생했다고 해서 원인이 같다고 단정할 수는 없습니다. 마지막으로 정상 사용했을 때의 서버, 모드와 네트워크를 기록하고 현재 상태와 비교하세요. 목표는 동작 차이를 찾아내는 것이지, 검증하지 않은 이전 Config로 모든 설정을 덮어쓰는 것이 아닙니다.

자료를 보존한 뒤 최소 범위로 다시 테스트

먼저 현재 Config, 사용자 지정 규칙과 필요한 서버 정보를 저장하세요. 어떤 정보가 구독에서 가져온 것이고 어떤 항목을 직접 입력했는지 확인해 재구성 후 복구할 수 있도록 합니다. 그런 다음 앱을 재시동하고 기존 설정으로 테스트하세요. 필요하다면 기기도 재시동해 시스템 네트워크 상태를 다시 설정합니다. 문제가 계속되면 Config 복사본을 만들어 필요한 규칙과 사용자가 보유한 서버 하나만 남겨 비교하세요. 정상적인 자료부터 지우지 마세요.

최소 Config는 정상인데 원래 Config에서 실패한다면 기존 규칙과 설정을 그룹별로 복원해 차이를 찾으세요. 복원할 때마다 같은 대상으로 다시 테스트하고 모든 내용을 한꺼번에 되돌리지 마세요. 두 Config 모두 실패하면 시스템 VPN 권한, 기본 네트워크와 서버 매개변수를 확인하세요. 오류 문구가 Config 문법을 가리킨다면 수정한 줄만 보지 말고 오류 근처의 구분자, 정책 이름과 항목을 먼저 확인하세요.

업데이트 기록과 시스템 요구 사항은 App Store 페이지의 표기를 기준으로 확인하세요. 앱을 확인하려면 정품 확인 안내를 참고해 개발자 Shadow Launch Technology Limited, 공식 아이콘과 앱 ID 932747118이 일치하는지 확인하세요. Shadowrocket은 Apple 플랫폼 전용 폐쇄형 상용 앱이며 업데이트와 재다운로드는 App Store를 통해 진행됩니다. 앱을 다시 구매하는 것은 네트워크 설정 문제의 해결 방법이 아닙니다.

iPad와 iPhone의 차이를 항목별로 확인

같은 서버 정보를 iPhone에서는 사용할 수 있지만 iPad에서는 사용할 수 없다면 두 기기가 실제로 같은 네트워크에 연결되어 있는지 먼저 확인하세요. iPhone은 셀룰러 데이터를 사용하는데 iPad는 Wi-Fi에 연결되어 있을 수 있습니다. 네트워크 이름이 비슷해 보여도 실제 연결을 확인해야 합니다. iPad에서 Wi-Fi만 사용할 수 있다면 다른 사용 가능한 네트워크에서도 다시 테스트하세요. 현재 기기에서 사용할 수 없는 셀룰러 데이터 점검 절차를 그대로 적용하지 마세요.

앱 구매 기록만으로 두 기기의 로컬 설정이 모두 같다는 것을 확인할 수는 없습니다. 두 기기에서 선택한 SERVER, Global Routing, 활성화된 Config, DNS 관련 항목과 On Demand 조건을 확인하세요. 직접 입력한 항목은 특히 하나씩 대조해야 합니다. Config를 복사할 때 현재 사용하는 파일을 복사했는지, 이전에 저장한 파일을 복사한 것은 아닌지 확인하세요. 항목 이름만 비교해서는 충분하지 않습니다. 이름이 같아도 주소와 매개변수는 다를 수 있습니다.

iPad에서는 화면 방향, 창 크기 또는 멀티태스킹 상태에 따라 레이아웃이 달라질 수 있습니다. 목록과 편집 영역이 함께 표시될 수도 있으므로 버튼이 화면의 왼쪽이나 오른쪽에 있는지만 보고 찾지 말고 Home, Config, Settings 같은 화면 이름으로 현재 위치를 확인하세요. 긴 주소를 입력할 때 키보드가 공백이나 문장 부호를 자동으로 넣지 않았는지 확인하고 저장 전에 내용을 다시 검토하세요.

절전 후 복귀, 로컬 네트워크와 재설치 범위

iPad를 오랫동안 대기 모드로 둔 뒤에만 문제가 발생한다면 먼저 깨어난 후 네트워크가 복구됐는지 확인하고 연결을 한 번 끊었다가 다시 연결하세요. 다시 연결한 뒤 정상화된다면 네트워크 전환이나 On Demand 조건 변화가 함께 있었는지 기록하고 재연결과 DNS 조회를 계속 확인하세요. 깨어날 때마다 모든 Config를 다시 만드는 것을 정해진 절차로 삼지 마세요. 실제 복구 시점 문제를 가리고 점검 자료도 잃기 쉽습니다.

로컬 네트워크 기기, 가정 내 페이지 또는 프린터 기능만 작동하지 않는다면 관련 시스템 권한과 대상 트래픽이 예상대로 Direct를 사용하는지 확인하세요. 내부 주소 대역, 내부 도메인과 공용 인터넷 대상에는 서로 다른 처리 조건이 적용되므로 실제 주소와 DNS 결과를 바탕으로 판단해야 합니다. 로컬 대상 하나를 해결하기 위해 모든 트래픽을 계속 Direct로 바꾸거나, 범위가 지나치게 넓은 주소 규칙을 추가해 다른 연결에 영향을 주지 마세요.

재설치가 꼭 필요하다면 Config 백업을 읽을 수 있는지, 직접 추가한 항목을 복구할 수 있는지, 사용자 본인이 구독 주소를 어디에 저장했는지 먼저 확인하세요. 구입 항목 복원과 일반적인 구매 가능 여부는 App Store 페이지의 표기를 기준으로 확인하세요. 자세한 내용은 iPad 이용 안내와 기기 변경 후 복원 안내를 참고하세요. 구입 항목 복원은 앱을 다시 받는 절차일 뿐 사용자가 보유한 서버와 규칙을 자동으로 복원하지 않습니다.