Shadowrocket 문제 해결가이드

연결 실패가 발생하는 단계를 확인하세요

iPhone/iPad에서 Home의 Not Connected는 연결이 아직 설정되지 않았다는 뜻이며, 구독에 반드시 문제가 있다는 의미는 아닙니다. 먼저 자동 재연결 조건을 끄고 스위치를 한 번 수동으로 조작해 시스템에서 VPN 구성을 추가하라는 요청이 표시되는지 확인하세요. 권한 확인 창이 아직 처리되지 않았다면 시스템 안내에 따라 인증을 완료하세요. 스위치가 잠시 켜졌다가 돌아오면 유지된 시간을 기록하고 직후 표시된 오류를 확인하세요. 연속해서 반복 탭하지 마세요.

그다음 클라이언트 연결을 끊고 브라우저에서 평소 접속할 수 있는 페이지를 여세요. 기본 네트워크도 작동하지 않으면 Wi-Fi 로그인, 셀룰러 데이터 또는 네트워크 재연결부터 확인하세요. 웹 인증이 필요한 공용 Wi-Fi는 연결을 끊은 상태에서 먼저 인증한 뒤 테스트해야 합니다. 기기가 무선 액세스 포인트에 연결되었다는 사실만으로 인터넷 접속까지 가능하다고 볼 수는 없습니다.

VPN 구성과 시스템 관리 제한 확인

iPhone/iPad에서는 시스템 설정에서 VPN을 검색해 해당 구성이 있는지, 다른 VPN이 연결 중인지 확인할 수 있습니다. 충돌하는 연결을 먼저 중지한 다음 Shadowrocket에서 다시 시도하세요. 이름만 보고 회사, 학교 또는 기기 관리자가 배포한 구성을 삭제하지 마세요. 관리되는 기기는 VPN 추가가 제한될 수 있으므로 허용되는 연결 방식은 기기 관리자에게 확인해야 합니다. 앱에서 서버를 다시 가져와도 시스템 제한은 해제되지 않습니다.

이전에 권한 요청을 거부했다면 연결을 다시 시작하고 시스템 안내를 확인하세요. 시스템에 더 이상 유효하지 않은 Shadowrocket VPN 구성이 있다면 앱 내부 자료를 저장한 뒤 앱에 해당하는 기존 구성만 제거하고 앱에서 다시 요청할 수 있습니다. 시스템 구성과 서버 항목은 서로 다른 데이터입니다. 구독과 규칙까지 함께 지우지 않도록 삭제 대상을 먼저 확인하세요. 완료 후에는 자동 조건을 복원하기 전에 수동 연결부터 테스트하세요.

권한 부족과 구성 오류를 따로 점검하세요

Mac, Windows, Android, Linux에서는 앱이 정상적으로 시작되는지, 네트워크 터널을 만드는 데 필요한 시스템 권한이 승인되었는지 확인하세요. Android에서는 VPN 연결 확인과 앱 배터리 제한을 살펴보세요. 데스크톱에서는 현재 계정 권한과 보안 소프트웨어의 차단 기록을 확인하세요. Shadowrocket에 필요한 권한만 조정하고, 문제 해결을 위해 시스템 보호를 장시간 끄거나 모든 앱의 권한을 완화하지 마세요.

시스템에서 연결을 허용했는데도 스위치가 바로 되돌아오면 저장해 둔 최소 구성으로 테스트하고, 이미 보유한 서버 항목 중 매개변수가 완전한 것 하나만 남기세요. 사용자 지정 스크립트, Rewrite, 복잡한 정책 그룹은 잠시 비활성화한 뒤 다시 연결합니다. 이는 오류가 구성 로드에서 비롯되는지 확인하기 위한 테스트이지, 서버가 사용 가능하다는 증명은 아닙니다. 최소 구성에서 연결이 유지되면 확장 항목을 하나씩 복원해 어느 항목에서 문제가 생기는지 확인하세요.

On Demand와 다른 연결의 충돌 확인

On Demand는 시스템 조건에 따라 연결을 시작하므로 수동으로 끈 뒤에도 상태가 자동으로 되돌아오는 것처럼 보일 수 있습니다. 점검 전에 기존 조건을 기록하고 On Demand를 잠시 끈 다음 수동 연결 요청을 한 번만 실행하세요. 동시에 다른 VPN, 네트워크 필터 또는 터널 기능도 중지해 테스트가 끝난 뒤 각각 복원합니다. 네트워크를 가로채는 구성 요소를 여러 개 동시에 실행하면 권한과 라우팅을 판단하기 어려워집니다.

잠금 화면에서나 네트워크 전환 시에만 종료된다면 서버를 계속 삭제하기보다 배터리 및 iPad 장으로 이동하세요. 시작할 때마다 구성을 해석할 수 없다는 명확한 오류가 표시되면 구성의 섹션 이름, 문장 부호, 참조된 정책을 확인하세요. 오류 원문과 마지막으로 연결에 성공한 구성을 비교하면 앱을 재설치하는 것보다 단서를 보존하기 쉽고, 민감한 인증 정보를 반복 입력하는 일도 피할 수 있습니다.

반복 가능한 접속 비교 테스트

모든 플랫폼에서 연결되었는데 페이지가 열리지 않으면 테스트할 페이지 하나와 브라우저 하나를 정하세요. 연결을 끊었을 때, 연결한 뒤, 서버를 바꾼 뒤의 결과를 순서대로 기록하고 네트워크와 구성을 동시에 바꾸지 마세요. 연결을 끊은 상태에서도 열리지 않으면 대상이나 기본 네트워크에 문제가 있을 수 있습니다. 특정 앱만 이상하다면 해당 앱의 캐시, 로그인 상태, 시스템 네트워크 권한도 확인해야 합니다. 모든 트래픽의 문제라고 바로 단정하지 마세요.

Home에서 실제로 선택된 SERVER를 확인하세요. 구독 목록이 새로고침되었는지만 보지 마세요. 구독에 항목이 여러 개 있으면 목록이 갱신되어도 현재 선택 항목은 바뀌지 않을 수 있습니다. 이어서 Global Routing에서 Config, Proxy, Direct 중 무엇이 선택되어 있는지 확인하세요. 연결 버튼은 네트워크 확장이 시작되었다는 뜻일 뿐, 모든 요청이 같은 서버를 통과하거나 규칙이 예상한 정책에 일치한다는 뜻은 아닙니다.

Global Routing으로 규칙 영향 분리하기

잠시 Proxy로 전환한 뒤 같은 대상으로 다시 테스트하세요. Proxy는 성공하고 Config는 실패하면 구성, 규칙 일치 순서, 정책 참조를 중점적으로 살펴보세요. 둘 다 실패하면 서버 매개변수, DNS, 대상 서비스로 범위를 넓힙니다. Direct는 직접 연결 경로를 비교하는 데 쓸 수 있지만 클라이언트가 완전히 비활성화된 상태는 아닙니다. 필요한 경우 연결을 끊은 상태에서도 기본 네트워크를 비교하세요.

규칙 순서와 마지막 정책 확인

Config에서는 규칙을 위에서 아래로 확인하세요. 먼저 일치한 규칙이 이후 처리를 좌우할 수 있습니다. 범위가 넓은 DOMAIN-KEYWORD 규칙이나 앞쪽의 기본 규칙 때문에 예상한 세부 규칙이 실행되지 않을 수 있습니다. 규칙에서 참조하는 정책이 실제로 존재하는지, 방금 편집한 구성이 아닌 같은 이름의 다른 사본이 활성화된 것은 아닌지 확인하세요. 수정 후 연결을 다시 설정하고 새 요청을 보내 이전 연결이 기존 경로를 계속 사용하는 상황을 피하세요.

아래 예시는 규칙 섹션과 순서를 보여 줄 뿐, 기존의 완전한 구성을 대체하지 않습니다. PROXY는 정책 참조이므로 현재 구성에서 사용할 수 있는 정책과 일치해야 합니다. 로컬 네트워크 예시는 실제 네트워크에 맞게 조정하세요. FINAL은 나머지 요청의 기본 처리로 마지막에 배치해야 하며, 계속 일치 여부를 확인해야 하는 세부 규칙보다 앞에 두면 안 됩니다. 테스트할 때 한 번에 규칙 하나만 조정하고 기존 순서를 저장하세요.

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

로그로 오류가 발생한 계층 확인

앱에서 연결 기록을 제공한다면 먼저 요청이 표시되는지, 그다음 일치한 정책, 대상, 오류를 확인하세요. 기록이 없다고 해서 요청이 현재 경로로 들어오지 않았거나, 앱이 기존 연결을 사용 중이거나, 기록 기능이 꺼져 있을 가능성도 있습니다. 빈 목록만으로 앱이 작동하지 않는다고 단정하지 마세요. 테스트 페이지를 닫았다가 다시 열고 새 요청을 보내세요. 로그를 공유하기 전에 도메인과 인증 정보를 숨기고 오류 유형과 시간만 남기면 됩니다.

기록에 서버 연결이 성립한 것으로 나오는데 대상에서 오류가 반환된다면 대상 서비스, 계정 제한, 대상 측 응답을 확인하세요. 로컬 VPN 권한을 계속 바꿀 상황은 아닙니다. 도메인 하나만 실패하면 DNS 장으로, 프록시를 통과하는 모든 요청이 시간 초과되면 서버 시간 초과 장으로 이동하세요. 일상 사용으로 돌아가기 전에 임시 Proxy 상태를 원래 설정으로 되돌리고 Config에서 실제 동작을 다시 확인하세요.

시간 초과, 연결 거부, 인증 오류 구분

모든 플랫폼에서 서버 시간 초과가 발생하면 먼저 오류 원문을 보존하세요. 시간 초과는 대기 시간 내 예상 응답을 받지 못했다는 뜻이며, 도메인 확인, 연결 수립, 핸드셰이크, 대상 접속 중 어느 단계에서나 발생할 수 있습니다. 연결 거부는 대상 주소가 응답했지만 포트에서 연결을 받지 않는 경우가 일반적입니다. 인증 실패는 사용자 정보를 우선 확인해야 합니다. 세 오류는 점검 순서가 다릅니다. 실패했다고 비밀번호를 무조건 다시 입력하거나 모든 원인을 네트워크 속도 부족으로 돌리지 마세요.

서버 주소에 프로토콜 접두사나 공백, 복사 중 들어간 줄바꿈이 없는지 확인하고 포트는 구독 또는 서버 설정에 적힌 값과 비교하세요. 이름이 비슷하다는 이유로 다른 항목의 포트와 인증 정보를 조합하지 마세요. 구독에 표시되는 이름은 메모일 뿐 프로토콜을 결정하지 않습니다. 항목 이름을 바꿔도 실제 프로토콜, 주소, 전송 매개변수는 바뀌지 않으므로 상세 정보에서 하나씩 확인해야 합니다.

프로토콜별 매개변수 확인

Shadowsocks는 암호화 방식과 비밀번호를 확인하세요. VMess와 VLESS는 사용자 식별자와 서버가 요구하는 추가 매개변수를 확인해야 합니다. Trojan은 비밀번호와 TLS 관련 설정을 확인하세요. WireGuard의 키, 주소, 피어 정보도 다른 프로토콜의 필드와 바꿔 쓸 수 없습니다. 사용자가 보유한 서버 정보를 기준으로 설정하세요. 여러 안내에서 흔히 쓰는 값이라는 이유로 기존 항목을 덮어쓰지 마세요.

TLS 이름과 연결 주소 구분

TLS를 사용하는 항목에서는 연결 주소, 핸드셰이크에 사용하는 서버 이름, 전송 계층의 Host가 각각 다른 역할을 할 수 있습니다. 도메인을 IP로 바꾸면 포트 연결은 성공해도 인증서 이름이 일치하지 않아 실패할 수 있습니다. 먼저 서버가 요구하는 이름으로 되돌린 다음 기기의 날짜와 시간이 정확한지 확인하세요. 시간이 크게 틀리면 인증서 유효기간 판단에 영향을 주어 매개변수 오류와 비슷한 증상이 나타날 수 있습니다.

인증서 검증을 끄는 방법을 장기 해결책으로 삼지 마세요. 인증서 오류가 발생하면 주소, 이름, 시스템 시간, 서버 인증서 상태부터 확인하세요. 정보가 구독에만 있다면 먼저 새로고침하고 별도의 테스트 항목을 가져와 필드 차이를 비교하세요. 기존 항목에 추측한 값을 연달아 입력하지 마세요. 서버 측 매개변수를 확인할 수 없다면 무작위 조합을 시도하는 대신 기존 서비스의 관리자에게 문의하세요.

교차 테스트로 네트워크와 서버 구분

같은 항목을 유지한 채 Wi-Fi와 셀룰러 데이터에서 각각 테스트한 다음, 같은 네트워크에서 이미 보유한 다른 사용 가능 항목을 시험하세요. 한 네트워크에서만 실패하면 해당 네트워크의 인증, 포트, UDP 접근 가능 여부를 확인해야 합니다. 여러 네트워크에서 동일 항목만 실패한다면 서버 상태와 매개변수를 우선 살펴보세요. Hysteria2처럼 UDP를 사용하는 경로는 일반 웹페이지가 열린다는 사실만으로 해당 전송도 사용 가능하다고 볼 수 없습니다.

Connectivity Test 결과는 테스트 방식에 따라 다릅니다. 접근 가능으로 표시되어도 실제 서비스 요청 성공을 뜻하지는 않습니다. 포트 연결, 핸드셰이크, 대상 페이지 열기는 각각 서로 다른 단계를 확인합니다. 실제 요청도 테스트하세요. 서버 로그를 볼 수 있다면 같은 테스트 시간에 연결 수신 여부, 인증 거부 여부, 대상 접속 성공 여부를 확인해 클라이언트의 일반적인 시간 초과 메시지만으로 원인을 단정하지 마세요.

주소 문제인지 네트워크 문제인지 먼저 판단

모든 플랫폼에서 기존 구독 업데이트가 실패하면 링크가 완전한지 확인하세요. 특히 물음표 뒤의 쿼리 매개변수를 살펴보세요. 메신저, 이메일 줄바꿈, 텍스트 수동 선택 과정에서 주소가 잘릴 수 있습니다. 구독 메모 이름을 보고 링크를 다시 조합하거나 서비스 제공자의 로그인 페이지를 구독 주소로 사용하지 마세요. 복사한 주소는 기기에서만 확인하고, 접근 정보가 포함될 수 있으므로 공개 스크린샷이나 오류 제목에 넣지 마세요.

업데이트할 때의 네트워크와 연결 상태를 기록하세요. 현재 선택한 서버가 작동하지 않고 구독 업데이트가 그 서버를 거친다면 새 항목을 가져올 수 없는 순환 상황이 생길 수 있습니다. 기본 네트워크를 사용할 수 있는 상태에서 먼저 업데이트를 시도하고, 필요하면 이미 보유한 다른 사용 가능 연결 경로를 사용하세요. 원격 서버가 요청 빈도를 제한할 수 있으므로 연속해서 반복 탭하지 마세요. 잠시 기다린 뒤 같은 조건에서 재시도해야 일시적인 응답 실패인지 판단할 수 있습니다.

성공 메시지만 보지 말고 응답 내용을 확인하세요

응답을 받았다고 해서 해석 가능한 서버 목록을 받았다는 뜻은 아닙니다. 원격 서버가 계정 로그인 페이지, 만료 안내, 접근 확인 페이지 또는 오류 문구를 반환할 수 있습니다. 앱에서 형식 오류를 표시하면 응답 상태와 오류 설명을 함께 보고 내용의 유형을 확인하세요. 응답 전체를 Add Server에 그대로 붙여 넣지 마세요. 브라우저에서 링크의 텍스트가 보이더라도 해당 형식이 현재 가져오기 기능에서 지원된다는 의미는 아닙니다.

권한 없음 또는 접근 거부가 반환되면 계정 상태, 재설정된 링크 여부, 누락된 쿼리 매개변수를 먼저 확인하세요. 주소를 찾을 수 없다는 오류가 나오면 오래된 주소를 복사했는지 살펴보세요. 원격 서버 오류라면 잠시 후 다시 시도하고 기존 서비스의 관리자에게 문의하세요. 클라이언트 업데이트로 원격 계정 제한을 해결할 수 없으며, 로컬 구성을 반복해서 삭제해도 구독 요청에 대한 서버의 권한 판단은 바뀌지 않습니다.

자료 형식에 맞는 가져오기 메뉴 선택

Subscribe는 구독 주소, Add Server는 서버 정보를 직접 입력할 때 사용합니다. Scan QR Code와 클립보드 인식은 실제로 제공된 내용에 따라 사용할 수 있습니다. QR 코드에는 서버 항목 하나가 들어 있을 수도 있고 웹 주소만 있을 수도 있습니다. 스캔에 성공했다고 연결 가능한 구성이 가져와진 것은 아닙니다. Import from Cloud JSON도 모든 링크에 사용할 수 있는 메뉴가 아닙니다. 이름이 비슷하다는 이유만으로 서로 바꿔 쓰지 말고 제공된 자료 형식에 맞춰 선택하세요.

구독, 서버 목록, 전체 구성 파일은 용도가 서로 다릅니다. 구독은 주로 서버 항목을 업데이트하며, 구성 파일에는 규칙, DNS, 정책도 포함될 수 있습니다. 규칙 파일을 서버 구독으로 가져오면 목록이 비어 있을 수 있습니다. 서버를 가져왔다고 해서 새 라우팅 구성까지 활성화된 것은 아닙니다. 메뉴별 비교는 Subscribe, Add Server, QR 코드 및 클립보드 안내를 확인한 뒤 자료에 맞는 방법을 선택하세요.

# 구독 주소 형식 예시이며 연결에는 사용할 수 없음
https://example.com/sub?token=xxxx

기존 항목을 보존하고 업데이트 결과 확인

구독을 수정하기 전에 기존 구성과 계속 사용할 수 있는 항목을 보존하고 별도 테스트 그룹이나 사본을 만들어 업데이트를 살펴보세요. 업데이트 뒤 항목 수 변화, 선택한 SERVER의 존재 여부, 직접 조정한 매개변수가 덮어써졌는지 확인하세요. 업데이트 과정에서 항목이 새로 생성될 수 있습니다. 로컬 수정 사항은 별도로 기록하고 원격 새로고침 때마다 그대로 유지된다고 가정하지 마세요. 백업 없이 전체를 삭제하지 마세요.

가져온 뒤 목록이 비어 있다면 검색어, 접힌 그룹, 필터가 항목을 숨기고 있는지도 확인하세요. 일부 항목만 누락되었다면 해당 항목의 프로토콜과 필드가 완전한지 비교해 원본에서 반환하지 않은 것인지 해석 과정에서 제외된 것인지 판단하세요. 새 항목 하나의 상세 정보를 열어 실제 요청을 보내고 가져오기, 선택, 연결이 모두 완료되었는지 확인한 뒤 테스트 결과를 일상 구성에 반영하세요.

‘느림’을 관찰 가능한 증상으로 구체화

모든 플랫폼에서 속도 문제를 점검할 때는 구체적인 상황부터 설명하세요. 웹페이지 로딩이 시작되기까지 오래 걸리는지, 다운로드가 계속 느린지, 동영상 재생이 중단되는지, 첫 접속만 느린지 확인합니다. 시작 전 대기는 DNS, 핸드셰이크, 서버 연결과 관련될 수 있고 지속 전송은 경로 용량과 대상 응답의 영향을 더 받습니다. 증상마다 원인이 다르므로 테스트 수치 하나로 모두 설명하거나 서버 이름과 위치 메모만으로 경로 품질을 판단하지 마세요.

같은 대상을 유지하고 비슷한 크기의 콘텐츠로 테스트하세요. 먼저 연결을 끊은 상태의 기본 네트워크를 기록한 다음 같은 항목을 시험합니다. 파일을 내려받으면서 웹페이지를 테스트하지 말고 시스템 업데이트, 클라우드 동기화, 다른 기기의 네트워크 사용량도 확인하세요. 네트워크, 시간대, 서버를 함께 기록합니다. 한 번 우연히 빨라지거나 느려진 결과만으로 특정 매개변수가 계속 유효하다고 볼 수 없으며, 모든 설정을 자주 바꾸는 근거로 삼기에도 부족합니다.

지연 시간과 처리량은 서로 다릅니다

Connectivity Test는 지정된 테스트 과정의 결과를 보여 줄 뿐 다운로드 속도와 같지 않습니다. 응답이 빠른 항목도 지속 전송 중에는 용량이나 혼잡의 영향을 받을 수 있습니다. 첫 응답이 다소 늦어도 연결이 성립된 후 안정적인 처리량을 낼 수 있습니다. 목록의 숫자만으로 순위를 정하지 말고 실제 웹페이지 접속과 지속 전송을 각각 테스트해 첫 응답 대기인지 전송 중 문제인지 확인하세요.

특정 대상만 느리다면 같은 서버에서 다른 대상은 어떤지 비교하세요. 대상 사이트의 부하, 콘텐츠 전달 경로, 로그인 상태, 앱의 자체 재시도도 체감 속도에 영향을 줍니다. 모든 대상이 동시에 느려지면 로컬 네트워크와 서버 측 리소스를 확인하세요. 한 대상 때문에 모든 규칙을 같은 정책으로 바꾸면 정상적인 요청 경로까지 달라져 새로운 문제를 만들면서 기존 문제는 설명하지 못할 수 있습니다.

Wi-Fi, 셀룰러, 전송 경로 확인

Wi-Fi에서는 액세스 포인트 가까이 이동하고 대용량 작업을 중지해 신호와 로컬 네트워크 혼잡에 따라 끊김이 달라지는지 살펴보세요. 셀룰러에서는 신호 변화와 이동 여부를 확인합니다. 같은 항목으로 네트워크를 바꾸는 편이 같은 네트워크에서 항목을 계속 바꾸는 것보다 로컬 경로를 판단하는 데 도움이 됩니다. 공용 네트워크는 일부 포트나 UDP를 다르게 처리할 수 있으므로 일반 웹페이지가 열린다고 모든 프로토콜의 지속 전송도 안정적이라고 볼 수 없습니다.

UDP를 사용하는 프로토콜이나 앱만 이상하다면 네트워크 전환 결과와 함께 UDP 경로를 점검하고 대역폭 매개변수를 무작정 높이지 마세요. 서버 구성과 클라이언트 매개변수는 서로 맞아야 합니다. 더 큰 숫자를 입력해도 실제 용량이 늘어나지는 않습니다. MTU를 조정하려면 패킷 단편화나 특정 크기 요청 실패 같은 근거를 확보하고 기존 값을 보존하세요. 반복 가능한 증상이 없다면 인터넷에서 본 고정값을 모든 네트워크에 적용하지 않는 편이 좋습니다.

규칙, 재시도, 진단으로 인한 추가 부하 줄이기

간단한 구성에서는 정상인데 복잡한 구성에서 뚜렷하게 느려진다면 정책 그룹, DNS, 사용자 지정 스크립트, Rewrite를 하나씩 복원해 어느 단계에서 달라지는지 확인하세요. 잦은 상태 검사, 실패 재시도, 대량의 진단 기록은 추가 요청을 만들거나 짧은 테스트 결과를 왜곡할 수 있습니다. 업무에 필요한 항목만 남기고 빈번한 테스트를 일시 중지한 뒤 같은 대상으로 확인하세요. 규칙을 삭제하기 전에 다른 기능이 해당 규칙에 의존하는지 살펴보세요.

오래 사용한 뒤에만 멈춘다면 경로만 문제라고 판단하지 말고 기기 온도, 남은 저장 공간, 백그라운드 작업도 확인하세요. 기기가 과열되면 브라우저, 디코딩, 네트워크 처리까지 영향을 받을 수 있습니다. 부하가 큰 작업을 멈추고 온도가 정상으로 돌아온 뒤 다시 테스트하세요. 문제가 해결되면 원래 진단 수준으로 되돌리고 실제로 효과가 있었던 변경 사항을 기록하세요. 안정적으로 재현되지 않는다면 로그와 조건을 보존하고 우연의 일치를 확실한 해결책으로 간주하지 마세요.

도메인 확인과 연결 실패의 경계 구분

모든 플랫폼에서 도메인만 열리지 않거나 첫 접속 대기가 길거나 로그에 이름 확인 오류가 있으면 DNS를 먼저 점검하세요. DNS는 이름을 주소로 바꾸고, 연결은 그 주소를 사용해 통신을 시작합니다. 이름 확인에 성공했다고 대상 포트를 사용할 수 있는 것은 아니며, 연결 시간 초과가 반드시 DNS 오류인 것도 아닙니다. 기록에서 이름 확인 전, 연결 중, TLS 핸드셰이크 중 어느 단계에서 실패했는지 구분해 모든 문제를 한 종류로 묶지 마세요.

‘IP 주소로 바꾸니 열린다’는 결과만으로 판단하지 마세요. 많은 HTTPS 서비스는 인증서 확인과 사이트 선택에 도메인을 사용하므로 브라우저에 IP를 직접 입력하면 다른 페이지가 나오거나 인증서 오류가 날 수 있습니다. 앱 기록에 나온 조회 결과와 이후 연결 오류를 비교하고, 같은 도메인이 기본 네트워크와 현재 구성에서 다르게 동작하는지 확인하세요. 테스트 중에는 원래 대상 이름을 그대로 사용하세요.

시스템 DNS 기준 상태에서 하나씩 복원

현재 DNS 설정을 저장하고 구성에 여러 출처가 동시에 지정되어 있는지, 사용자 지정 Host가 있는지, 오래된 도메인 매핑이 있는지 확인하세요. 아래 예시는 시스템 DNS를 사용하는 점검 기준일 뿐 모든 네트워크에 적합하다고 보장하지 않으며 기존 전체 구성을 대체하지도 않습니다. 기준 상태로 되돌린 뒤 문제가 사라지면 사용자 지정 항목을 하나씩 복원해 어느 항목이 문제를 일으키는지 확인하세요. 모든 주소를 한꺼번에 바꾸지 마세요.

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

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

암호화 DNS를 사용한다면 해당 확인 서비스가 어떻게 연결되는지도 고려해야 합니다. 서비스 도메인이 먼저 다른 확인 경로에 의존할 수 있고, 요청 역시 라우팅 정책의 영향을 받을 수 있습니다. 현재 연결되지 않은 서버를 통해 이름을 확인해야 하는데 서버 도메인도 그 확인에 의존하면 순환 의존성이 생길 수 있습니다. 먼저 시작 가능한 최소 경로를 복구하고 앱에서 지원하는 설정으로 이름 확인과 연결 관계를 명확히 하세요. 여러 기본 대체 설정을 임의로 겹쳐 두지 않는 것이 좋습니다.

규칙 유형과 확인 시점 점검

DOMAIN, DOMAIN-SUFFIX, IP-CIDR, GEOIP는 서로 다른 대상을 처리합니다. 도메인 규칙은 이름을 직접 대상으로 삼지만 IP 규칙은 판정 전에 주소 확인 결과가 필요할 수 있습니다. no-resolve가 있는 IP 규칙은 해당 규칙을 위해 적극적으로 주소를 확인하지 않도록 할 수 있지만, 실제 연결에 DNS가 전혀 필요 없다는 뜻은 아닙니다. 규칙 내용과 해당 시점에 요청 대상 주소가 이미 있는지를 함께 확인하세요. 도메인만 보고 일치 결과를 추측하지 마세요.

캐시, IPv6, 로컬 네트워크 이름 처리

DNS를 변경한 뒤에도 이전 요청은 캐시나 기존 연결을 계속 사용할 수 있습니다. 테스트 페이지를 닫고 클라이언트 연결을 다시 설정한 다음 새 요청을 보내세요. 앱에 명확한 캐시 삭제 메뉴가 있을 때만 사용하고 DNS를 새로고침하려고 모든 구성을 지우지 마세요. IPv4는 정상인데 IPv6에서 오류가 나면 규칙에 이름을 추가하는 데 그치지 말고 서버, 시스템, 실제 네트워크에 일관된 IPv6 경로가 있는지 확인하세요.

프린터, 로컬 네트워크 서비스, 내부 도메인은 현재 Wi-Fi가 제공하는 DNS에 의존할 수 있으므로 모두 원격 DNS로 바꾸면 찾지 못할 수 있습니다. 외부 도메인은 복구되었는데 내부 이름이 작동하지 않는다면 로컬 주소, 시스템 권한, 내부 확인 경로를 따로 점검하세요. 로컬 네트워크에서만 적용되는 조건을 유지하고 내부 이름을 관련 없는 확인 경로로 보내지 마세요. 복구 후에는 외부 페이지와 실제로 필요한 로컬 서비스 모두 테스트하세요.

시스템 배터리 통계 올바르게 확인하기

iPhone/iPad와 Android에서 배터리 소모가 걱정된다면 먼저 시스템 배터리 페이지의 통계 기간, 화면 사용 시간, 백그라운드 활동을 확인하세요. 배터리 비율은 해당 기간의 앱별 상대 소모량이지 클라이언트가 전체 배터리의 같은 비율을 계속 사용했다는 뜻은 아닙니다. 비교하는 두 기간의 네트워크 환경이 Wi-Fi와 신호가 약한 셀룰러로 다르거나 한쪽에서 데이터 전송이 많았다면 비율만 보고 구성 오류라고 단정할 수 없습니다.

네트워크 터널은 통과하는 데이터를 처리합니다. 시스템 통계에서 네트워크 처리 비용 일부가 관련 프로세스에 표시될 수 있지만 앱별 트래픽 비용을 정확히 나눠 보여 주는 것은 아닙니다. 사용 습관이 비슷한 두 기간을 골라 네트워크, 연결 시간, 주요 작업을 기록한 뒤 차이를 비교하세요. 점검 중 프로토콜 변경, 네트워크 변경, 백그라운드 권한 해제를 동시에 하지 마세요. 배터리가 나아져도 어떤 요인이 효과를 냈는지 알기 어렵습니다.

지속적인 실패와 재시도 여부 확인

안정적으로 유휴 상태를 유지하는 연결보다 반복적인 연결 실패를 먼저 살펴볼 필요가 있습니다. 앱에서 연결이 자주 바뀌는지, 구독이 짧은 간격으로 반복 업데이트되는지, 정책 그룹이 사용할 수 없는 항목을 자주 테스트하는지 확인하세요. 연결 로그에 같은 오류가 계속 쌓인다면 배터리 소모를 평가하기 전에 기본 네트워크, 인증, 이름 확인 문제를 해결하세요. 진단 기록의 상세도를 낮추기만 해서는 반복 실패 요청이 해결되지 않으며 중요한 증거가 사라질 수 있습니다.

On Demand 조건은 실제 사용 목적에 맞아야 합니다. 이동 중 Wi-Fi와 셀룰러를 자주 전환하거나 신호 경계에서 연결을 반복하면 시스템이 연결을 계속 재설정할 수 있습니다. 자동 조건을 잠시 끄고 안정적인 네트워크에서 수동 연결을 한 번 유지해 오류가 멈추는지 확인하세요. 테스트 후 필요한 조건을 복원하고 모든 자동 동작을 계속 취소해 두지 마세요. 특정 무선 네트워크에서만 문제가 생기면 해당 네트워크부터 확인하세요.

무조건 백그라운드 실행을 강제하지 말고 제한을 점검하세요

Android에서는 특히 잠금 화면 뒤에만 연결이 끊기는 경우 시스템이 Shadowrocket의 백그라운드 네트워크 사용이나 배터리 사용을 제한하는지 확인하세요. 시스템에서 제공하는 앱별 옵션을 조정하면 되며 모든 앱을 제한 없음으로 설정할 필요는 없습니다. iPhone/iPad VPN 연결은 시스템 네트워크 기능이 관리하므로 기본 앱을 백그라운드로 보낸 것을 연결 종료와 동일하게 볼 수 없습니다. 시스템 VPN 상태, 로그, 네트워크 전환 시점을 함께 확인하세요.

Mac, Windows, Linux에서는 화면 꺼짐, 절전, 시스템 깨우기를 구분하세요. 기기가 절전 상태에 들어가면 네트워크 경로가 끊길 수 있고, 깨어난 뒤에도 기존 연결을 계속 사용할 수 없을 수 있습니다. 먼저 시스템 인터넷이 정상적으로 복구되었는지 확인한 뒤 클라이언트 연결을 다시 설정하세요. 테스트를 유지하려고 컴퓨터의 절전 기능을 장시간 끄지 마세요. 배터리 전원에서만 문제가 발생하면 시스템 전원 모드와 네트워크 어댑터 절전 설정이 바뀌었는지 확인하세요.

스크립트, 기록, 기타 백그라운드 작업 분리

복잡한 스크립트, Rewrite, 잦은 확인, 장시간의 상세 로그는 처리 부하를 늘릴 수 있지만 비교 없이 특정 기능을 원인으로 단정할 수는 없습니다. 구성을 복사한 뒤 불필요한 항목을 일시 중지하고 같은 사용 상황에서 테스트한 다음 하나씩 복원하세요. 클라우드 동기화, 대용량 업로드, 시스템 업데이트, 미디어 처리도 확인해야 합니다. 이런 작업은 트래픽을 늘리고 클라이언트의 네트워크 처리 부담도 높여 발열과 배터리 소모가 동시에 나타날 수 있습니다.

기기 온도가 크게 올라가면 부하가 큰 작업을 먼저 멈추고 온도가 정상으로 돌아온 뒤 테스트하세요. 발열과 네트워크 끊김이 함께 나타나면 안정적인 결과를 얻으려고 부하 테스트를 반복하거나 충전 중 높은 부하를 유지하지 마세요. 최소 구성에서도 비슷한 조건에서 문제가 계속되면 배터리 페이지, 시스템 상태, 민감 정보를 가린 로그를 정리하고 발생 시간을 기록하세요. 재설치 전에 다른 네트워크에서도 같은 현상이 재현되는지 확인하세요.

앱, 시스템, 구독 업데이트 구분

모든 플랫폼에서 업데이트 후 연결이 안 되면 업데이트한 대상이 Shadowrocket, 운영체제, 구독, 구성 파일 중 무엇인지 확인하세요. 같은 시기에 발생했더라도 서로 다른 계층에 영향을 줍니다. 마지막으로 정상 사용한 네트워크와 구성을 기록하고 이후의 변경 사항을 정리하세요. 모든 문제를 곧바로 앱 탓으로 돌리지 마세요. 구독 항목 교체, 시스템 권한 초기화, 규칙 변경은 앱 업데이트 뒤에 처음 드러날 수도 있습니다.

앱을 한 번 재시작하고 연결을 다시 설정해 시스템 기본 네트워크가 사용 가능한지 확인하세요. 시스템 업데이트에서 필수 재시작이 남아 있다면 먼저 완료해야 합니다. 기존 연결만 끊기고 새 요청은 정상이라면 네트워크 상태가 제때 복구되지 않았을 수 있습니다. 연결할 때마다 같은 오류가 안정적으로 재현된다면 로그를 보존하고 원인을 계속 확인하세요. 단서를 가리도록 반복 재시작하거나 백업 없이 앱 데이터를 지우지 마세요.

구성 사본으로 호환성 범위 확인

현재 구성과 사용 가능한 이전 사본을 저장한 뒤 섹션, 정책 이름, DNS, 추가 기능을 비교하세요. 구성을 더 엄격하게 해석하면 이전에 드러나지 않았던 오타나 참조 오류가 명확히 표시될 수 있습니다. 실제 오류에 따라 하나씩 수정하고 출처가 불분명한 구성을 통째로 복사해 기존 자료를 덮어쓰지 마세요. 기존 서버 항목 하나와 최소 규칙으로 연결한 다음 기본 기능을 확인하고 정책 그룹과 확장 설정을 복원하세요.

구독 업데이트로 항목 식별자, 이름, 매개변수가 바뀌어 기존 정책 참조가 대상을 찾지 못할 수도 있습니다. 현재 SERVER가 남아 있는지, 정책 그룹이 비어 있지 않은지, 참조된 이름이 완전히 일치하는지 확인하세요. 같은 이름의 항목이 여러 개라면 어느 항목이 선택되었는지 확인해야 합니다. 이전 구성을 복원해도 원격 서버 상태까지 되돌아가는 것은 아닙니다. 실제 요청도 반드시 확인하세요. 구성 파일이 성공적으로 로드되는 것만으로는 충분하지 않습니다.

앱을 다시 받을 때 시스템 보안 경계를 유지하세요

재설치가 필요하면 앱 다운로드에서 해당 플랫폼을 선택하세요. iPhone/iPad는 App Store에서 받으며 시스템 요구 사항은 App Store 페이지 표기를 따릅니다. Mac, Windows, Android, Linux 설치 파일은 이 사이트의 /dl/ 경로에서 제공합니다. Mac에서는 먼저 ‘이 Mac에 관하여’에서 Apple 칩인지 Intel인지 확인하세요. 기기 외관만 보고 설치 파일을 고르면 안 됩니다. 플랫폼이나 아키텍처가 맞지 않는 것은 서버 구성 오류가 아닙니다.

데스크톱 및 Android 설치 파일에는 코드 서명이 없어 처음 실행할 때 시스템 차단 안내가 표시될 수 있습니다. Windows SmartScreen에서는 출처를 확인한 뒤 ‘추가 정보’를 열고 ‘실행’을 선택할 수 있습니다. Mac에서 개발자를 확인할 수 없다는 안내가 나오면 ‘개인정보 보호 및 보안’에서 해당 앱의 ‘그래도 열기’를 확인하세요. 명확히 다운로드한 Shadowrocket에만 적용하고 설치를 위해 전역 보안 확인을 끄거나 보호 설정을 장기간 낮추지 마세요.

Android에서는 시스템 설정에서 설치를 실행하는 브라우저나 파일 관리자에 ‘알 수 없는 앱 설치’를 허용하세요. 설치가 끝나면 필요에 따라 권한을 다시 거둘 수 있습니다. WeChat 안에서 다운로드할 수 없다면 시스템 브라우저를 사용하세요. Linux에서는 배포판에 맞는 deb, rpm, AppImage를 선택하고 설치 안내에 따라 권한을 처리하세요. 자세한 절차는 Mac 및 Windows 설치 안내와 Android 설치 안내를 확인하세요.

하나씩 복원하고 추적 가능한 기록 남기기

재설치 전에 백업에서 서버, 규칙, 필요한 설정을 복원할 수 있는지 확인하세요. 민감한 정보는 본인의 안전한 위치에만 보관해야 합니다. 앱을 삭제해도 모든 데이터가 남는다고 가정하지 말고 시스템 VPN 구성을 전체 앱 백업으로 보지 마세요. 복원할 때는 먼저 항목 하나를 가져와 연결한 뒤 구독과 규칙, 마지막으로 자동 연결 조건을 복원하세요. 매 단계에서 같은 대상으로 확인하면 문제가 다시 발생한 시점을 정확히 찾을 수 있습니다.

새 시스템이나 특정 구성 조합에서만 재현된다면 최소 재현 절차, 시스템 정보, 오류 원문, 민감 정보를 제거한 최소 구성을 정리하세요. 전체 구독이나 실제 비밀번호를 첨부할 필요는 없으며 공개하면 오히려 위험이 커집니다. 원인을 찾지 못했다면 사용 가능하다고 확인된 구성 사본을 보존하고 변경을 계속 쌓지 마세요. 복구의 목적은 기능을 이해 가능한 방식으로 되살리는 것이지 모든 설정을 다르게 만드는 것이 아닙니다.

iPhone은 정상인데 iPad에서 실패할 때 비교하는 방법

같은 구독이 iPhone에서는 작동하는데 iPad에서 연결되지 않으면 먼저 두 기기를 같은 Wi-Fi에 연결하고 같은 서버 항목을 선택한 뒤 Global Routing과 활성 구성을 확인하세요. 구독 이름만 같아서는 충분한 비교가 아닙니다. 두 기기에서 서로 다른 항목을 선택했거나 한쪽에서 이전 규칙을 사용할 수 있습니다. 확인 후 같은 대상으로 요청을 보내고 연결 아이콘만 비교하지 말고 실제 결과를 기록하세요.

그다음 iPad의 날짜, 시간, VPN 권한, 기본 네트워크를 확인하세요. Wi-Fi 전용 iPad에는 전환할 셀룰러 네트워크가 없으므로 휴대전화의 전환 절차를 그대로 적용할 수 없습니다. 권한이 허용되는 경우 다른 네트워크나 개인용 핫스팟으로 비교할 수 있습니다. 셀룰러 모델은 시스템에서 앱의 셀룰러 데이터 사용을 허용했는지도 추가로 확인하세요. 네트워크 출처만 한 번에 하나씩 바꾸고 구성은 그대로 유지해야 문제가 네트워크를 따라가는지 알 수 있습니다.

공용 Wi-Fi, 핫스팟, 로컬 네트워크 접속

공용 Wi-Fi에서 인증이 필요하면 Shadowrocket 연결을 끊고 먼저 웹 로그인 인증을 완료한 뒤 다시 연결하세요. 인증 페이지가 자동으로 나타나지 않으면 시스템 Wi-Fi 설정에서 연결 상태를 확인하고 네트워크가 제공하는 일반적인 방식으로 인증하세요. 핫스팟 연결에도 별도의 상위 네트워크 조건이 있습니다. 휴대전화에서 대상에 접속할 수 있어도 iPad에 공유된 경로가 휴대전화 앱과 완전히 같다는 뜻은 아니므로 iPad에서 기본 접속을 별도로 확인하세요.

프린터, 화면 미러링 기기, 로컬 네트워크 서비스 접속에 문제가 있으면 시스템의 로컬 네트워크 권한, 두 기기가 같은 서브넷에 있는지, 무선 네트워크에서 클라이언트 격리를 사용 중인지 확인하세요. 구성에서 로컬 주소를 실수로 프록시로 보내는지도 살펴보세요. 아래 예시는 일반적인 사설 주소 규칙만 보여 줍니다. 실제 네트워크 대역을 기준으로 설정하세요. 로컬 서비스를 사용하려면 해당 네트워크가 제공하는 DNS가 필요할 수 있습니다.

[Rule]
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

잠금 화면 해제 후 및 멀티태스킹 중 연결 확인

iPad 잠금 화면을 해제한 뒤에는 시스템에서 Wi-Fi를 다시 연결했는지 먼저 확인하고 클라이언트 상태를 살펴보세요. 네트워크 복구 중 잠시 실패한 것만으로 구독이 무효라고 단정할 수는 없습니다. 기본 네트워크가 정상화될 때까지 기다렸다가 연결을 다시 설정하고 새 요청으로 테스트하세요. 잠금 해제 때마다 같은 문제가 반복되면 잠금 전후의 네트워크, On Demand 조건, 오류 시간을 기록하고 배터리 장에서 백그라운드 및 재연결을 점검하세요. 같은 구독을 반복해서 가져오지는 마세요.

화면 분할, Stage Manager, 외장 키보드는 조작 방식만 바꿀 뿐 다른 기기의 서버 선택을 자동으로 동기화하지 않습니다. 점검할 때 Shadowrocket과 테스트 앱을 차례로 열어 수정 사항이 저장되고 적용되었는지 확인하세요. 여러 구성 편집 창에서 사본을 혼동하지 마세요. 멀티태스킹 중 앱이 이전 연결을 유지하는 경우 해당 요청을 먼저 끝낸 뒤 다시 시도해야 이전 세션 경로를 새 규칙이 적용되지 않은 것으로 오해하지 않습니다.

자료 동기화, 기기 제한, 문제 전달 방법

iPhone에서 iPad로 구성을 옮긴 뒤 서버 상세 정보, 정책 참조, 시스템 권한을 각각 확인하세요. 파일 복사로 파일 내용은 옮길 수 있어도 다른 기기의 VPN 권한까지 승인되지는 않습니다. 현재 네트워크에 의존하는 로컬 도메인과 주소도 새 기기에서 사용할 수 없을 수 있습니다. 기존 서비스에서 동시 연결 수를 제한한다면 비교를 위해 다른 기기 연결을 끊고 원래 서비스 관리자에게 정책을 확인하세요. 클라이언트는 원격 계정 제한을 바꿀 수 없습니다.

앱에서만 문제가 발생하고 같은 기기의 브라우저는 정상이라면 해당 앱의 네트워크 권한과 접속 대상도 확인하세요. 브라우저가 성공했다고 모든 서비스가 성공해야 하는 것은 아닙니다. 학교나 회사에서 관리하는 기기라면 관리 구성을 유지하고 관리자에게 문의하세요. 제한을 임의로 제거하지 마세요. 문제를 전달할 때 iPad 네트워크 유형, 잠금 화면 해제 후 발생 여부, 선택한 구성, 오류 원문을 적고 구독 주소, 사용자 식별자, 비밀번호는 숨기세요.