Shadowrocket 문제 해결 가이드

01 연결 스위치가 켜지지 않을 때: VPN 구성 권한 확인

먼저 세 가지 상황을 구분하세요. 스위치를 누른 뒤 시스템 권한 요청이 표시되는 경우, 스위치가 잠시 켜졌다가 꺼지는 경우, 화면에는 켜짐으로 표시되지만 시스템 연결이 안정적으로 유지되지 않는 경우입니다. 각각 권한 설정 미완료, 연결 프로세스 종료, 연결 상태 재확인이 원인일 수 있습니다. 이 세 가지를 모두 ‘서버 문제’로 단정하지 마세요. 작동 중인 다른 VPN 연결을 종료하고 Shadowrocket의 Home으로 돌아가 유효한 서버가 선택되어 있는지 확인한 다음 다시 시도하세요. 화면에 표시된 안내 문구도 그대로 기록합니다.

권한 요청이 표시되면 시스템 확인을 완료하세요

처음 연결할 때는 시스템에서 VPN 구성을 추가하도록 허용해야 합니다. 이 요청은 시스템이 관리하는 연결 구성을 생성하기 위한 것이며, 서버에 접속할 수 있다는 의미는 아닙니다. 안내에 표시된 앱 이름을 확인하고, 방금 실행한 Shadowrocket에서 요청한 것이 맞는지 확인한 다음 시스템 안내에 따라 기기 인증을 완료하세요. 이전에 요청을 취소했다면 앱으로 돌아가 연결을 다시 시도하세요. 인증이 끝나기 전에 다른 설정을 반복해서 변경하면 권한 부여 전후 어느 단계에서 문제가 생겼는지 파악하기 어렵습니다.

이후 시스템 Settings에서 VPN 관련 화면을 열어 해당 구성이 있는지 확인하세요. 시스템 버전에 따라 메뉴 이름이나 위치가 달라질 수 있으므로 Settings에서 VPN을 검색해 찾을 수 있습니다. 구성이 있다는 것은 시스템에 연결 항목이 저장되었다는 뜻일 뿐, 현재 서버를 사용할 수 있다는 뜻은 아닙니다. 구성이 보이지 않으면 권한 요청을 다시 시작하세요. 기기가 조직에서 관리되고 관련 옵션을 사용할 수 없다면 서버 비밀번호를 바꾸려 하지 말고 기기 관리자에게 제한 사항을 확인하세요.

스위치가 바로 꺼질 때는 시스템 문제와 구성 문제를 나눠 확인하세요

먼저 On Demand를 끈 상태에서 수동으로 연결해 바로 끊기는지 확인하세요. 네트워크가 바뀌면 On Demand 조건에 따라 연결 상태가 다시 결정될 수 있습니다. 이를 끄면 자동 동작의 영향을 배제하는 데 도움이 됩니다. 사용 중인 Config 이름을 기록하고, 최근에 해석할 수 없는 내용을 편집했거나 존재하지 않는 정책을 참조했거나 필수 항목을 빠뜨렸는지 확인하세요. 출처를 알 수 없는 설정 전체로 교체하기보다 직접 저장해 둔 이전의 정상 구성을 복원하는 것이 우선입니다.

이전에는 정상 작동했지만 시스템 VPN 구성을 삭제한 뒤 문제가 생겼다면, 필요한 구성의 백업이 있는지 확인한 후 앱에서 시스템 권한 요청을 다시 시작할 수 있습니다. 시스템 구성을 삭제하는 것은 우선적으로 권장되는 단계가 아닙니다. 잘못된 서버 매개변수를 고치거나 구독 정보를 복원해 주지도 않습니다. 재구성이 필요하다면 먼저 연결을 중지하고 On Demand 상태를 기록한 뒤 Shadowrocket에 해당하는 구성만 처리해 다른 업무용 시스템 항목을 잘못 건드리지 않도록 하세요.

확인 가능한 상태를 기준으로 점검을 마무리하세요

권한 설정을 마친 뒤 앱을 전면에 둔 상태로 시스템 VPN 연결이 안정적으로 유지되는지 확인하고, 이전에 접속할 수 있었던 일반 웹페이지를 열어 보세요. 스위치는 안정적으로 켜져 있지만 웹페이지가 열리지 않는다면 다음 항목에서 라우팅과 서버를 점검하고, 권한 설정을 반복해서 삭제하지 마세요. 스위치가 계속 바로 꺼진다면 오류 문구, 모든 서버에서 같은 문제가 발생하는지, 기기를 재시동한 뒤에도 재현되는지를 기록하세요. 앱을 강제 종료하기를 반복하는 것보다 기기를 정상적으로 재시동한 뒤 다시 확인하는 편이 원인을 파악하기 쉽습니다.

시스템 제한도 별도로 확인하세요. 스크린 타임, 기기 관리 정책 또는 다른 네트워크 구성은 VPN 연결에 영향을 줄 수 있습니다. 자신의 기기에 적용된 권한 상태만 확인하고 조직에서 설정한 구성을 임의로 제거하지 마세요. 기기 자체의 일반 네트워크도 사용할 수 없다면 먼저 Wi-Fi 또는 셀룰러 연결을 복구해야 합니다. VPN 권한이 정상이어도 기본 네트워크를 대신할 수는 없습니다. 권한 요청에 관한 자세한 설명은 VPN 구성 추가 요청 안내를 참조하세요.

02 연결은 됐지만 인터넷이 되지 않을 때: 라우팅과 기본 네트워크를 따로 확인

시스템에 VPN 연결됨으로 표시되어도 연결 확장 기능이 작동 중이라는 뜻일 뿐, 모든 요청이 목적지에 정상적으로 도달한다는 의미는 아닙니다. Shadowrocket 연결을 끄고 같은 네트워크에서 접속이 확인된 웹페이지를 열어 보세요. 연결을 꺼도 페이지가 열리지 않는다면 Wi-Fi에서 웹 인증이 필요한지, 셀룰러 데이터가 작동하는지, 라우터가 인터넷에 연결되어 있는지 먼저 확인하세요. 공용 Wi-Fi에서는 네트워크 자체의 로그인이나 이용 약관 확인을 완료한 뒤 연결하세요. 인증 페이지가 열리지 않는 문제를 규칙 오류로 오인하지 않도록 주의해야 합니다.

Global Routing을 비교해 문제 발생 단계를 확인하세요

기본 네트워크가 정상인지 확인한 다음 현재 Global Routing 설정을 기록하고 같은 대상으로 잠시 비교 테스트를 진행하세요. Config 모드는 현재 규칙에 따라 트래픽을 분기합니다. Proxy 모드는 선택한 서버가 요청을 처리할 수 있는지 확인하는 데 적합합니다. Direct 모드는 프록시 서버를 거치지 않을 때의 연결 상태를 비교하는 데 사용합니다. 모드 변경은 진단을 위한 것이지 영구적인 해결책이 아닙니다. 각 테스트가 끝나면 원래 설정으로 되돌려 이후 앱 요청이 임시 설정으로 다른 경로를 사용하지 않도록 하세요.

세 모드에서 같은 대상을 테스트하세요. 모드마다 서로 다른 웹사이트를 열면 비교가 되지 않습니다. 특정 사이트 하나가 실패했다고 전체 연결이 끊겼다고 단정하지 마세요. 사이트 자체의 문제이거나 콘텐츠가 다른 도메인에 의존할 수 있습니다. 서로 독립적인 대상 하나를 추가로 테스트하고, 페이지가 전혀 열리지 않는지, 이미지에만 문제가 있는지, 로그인 단계에서 실패하는지 기록하세요. Proxy는 작동하고 Config만 실패한다면 서버 프로토콜을 계속 바꾸지 말고 요청이 어떤 규칙에 적용됐는지 확인하세요.

규칙은 위에서 아래로 적용됩니다. 실제로 적용된 규칙부터 확인하세요

최근에 편집한 파일만 확인하지 말고 현재 활성화된 Config를 확인하세요. 규칙은 일반적으로 위에서 아래 순서로 적용되며, 먼저 일치한 항목이 처리 방식을 결정합니다. 뒤에 있는 포괄적인 규칙으로는 앞에서 이미 잘못 적용된 정책을 바로잡을 수 없습니다. 특히 범위가 넓은 DOMAIN-KEYWORD, 의도치 않게 차단하는 REJECT, 기대한 대로 작동하는지 여부를 FINAL에서 확인하세요. 아래 내용은 규칙 문법과 순서를 설명하는 예시일 뿐이므로 기존 구성을 통째로 바꾸지 마세요.

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

로그를 확인할 수 있다면 방금 요청을 한 번 실행하고 대상 도메인, 적용된 규칙, 최종 정책 및 오류 결과를 대조하세요. 목록에서 선택된 서버 이름만 봐서는 안 됩니다. 규칙이나 정책 그룹이 실제 트래픽의 출구를 바꿀 수 있습니다. 요청에 REJECT가 적용됐다면 차단하려던 도메인이 맞는지 먼저 확인하세요. 업무에 필요한 도메인이 차단된 경우 해당하는 좁은 범위의 항목만 조정하고 기존 값을 보관하세요. 한 페이지를 열기 위해 규칙 전체를 지우지 마세요.

재현 결과에 따라 다음 항목을 선택하세요

모든 모드에서 실패하지만 연결을 끄면 정상이라면 DNS와 연결 프로세스를 추가로 확인하세요. Proxy에서만 실패한다면 서버 시간 초과 항목으로 이동하세요. Config에서만 실패한다면 규칙과 정책 참조를 중심으로 원인을 좁히세요. 로컬 프린터나 라우터 관리 페이지에 접속할 수 없다면 대상 주소가 실제 로컬 네트워크에 속하는지, 기존 IP-CIDR 규칙이 해당 주소를 포함하는지도 확인하세요. 예시에 나온 사설 네트워크 대역이 모든 가정용 네트워크를 빠짐없이 포함한다고 가정하지 마세요.

최종 확인에는 원래 실패했던 작업을 포함해야 합니다. 웹페이지 제목만 표시되는지 확인하는 것으로 끝내지 마세요. 페이지를 새로고침하고 필요한 일반 요청을 한 번 수행한 다음 시스템 연결이 계속 안정적인지 확인하세요. 로그인이나 결제와 관련된 작업이라면 먼저 사이트 주소가 올바른지 확인한 후 연결을 테스트하세요. 웹페이지 오류를 해결하려고 인증서 확인을 끄지 마세요. 원인을 판단하기 어렵다면 FAQ에서 같은 증상을 확인하되, 이번에 테스트한 세 가지 모드의 결과를 기록해 처음부터 반복하지 않도록 하세요.

03 서버 시간 초과: 주소·전송 방식·인증을 단계별로 확인

시간 초과는 정해진 시간 안에 예상한 응답을 받지 못했다는 뜻이지, 문제 발생 지점을 바로 알려 주지는 않습니다. 서버 도메인을 해석하지 못했거나, 대상 포트에 접근할 수 없거나, 프로토콜 핸드셰이크가 일치하지 않을 수 있습니다. Connectivity Test에 사용하는 테스트 대상이 일시적으로 작동하지 않는 경우도 있습니다. 테스트한 위치, 오류 문구, 특정 서버에서만 실패하는지, 실제 웹 요청도 실패하는지 먼저 기록하세요. 테스트 결과는 단서일 뿐 서버 상태를 완전히 증명하지는 않습니다.

먼저 Add Server의 기본 항목을 확인하세요

기존 서버 항목을 열고 직접 보유한 원본 정보를 대조해 Type, Server, Port 및 인증 항목을 하나씩 확인하세요. Server 항목에 경로, 공백 또는 프로토콜 접두사처럼 해당 필드에 속하지 않는 내용이 섞이지 않도록 하세요. Port는 서버에서 실제로 수신하는 포트와 일치해야 합니다. 직접 입력할 때 표시 이름을 서버 주소로 착각하거나, 구독 주소를 단일 서버 항목에 넣기 쉽습니다. 내용을 수정하기 전에 정보의 종류부터 확인해 잘못된 입력란에 반복해서 붙여 넣지 않도록 하세요.

주소가 도메인이라면 도메인 해석이 실패해 연결이 시작되지 않을 수 있습니다. 같은 네트워크에서 다른 도메인도 정상적으로 해석되는지 확인한 다음 DNS 항목으로 이동하세요. 임의로 찾은 IP 주소로 도메인을 바꾸지 마세요. 서버는 SNI, 인증서 도메인 또는 특정 라우팅에 의존할 수 있습니다. 서버와 주소의 대응 관계를 직접 알고 있고 올바른 TLS 매개변수를 유지할 수 있는 경우에만 주소 비교 테스트를 통해 의미 있는 결과를 얻을 수 있습니다.

프로토콜이 같아도 추가 매개변수까지 같은 것은 아닙니다

Shadowsocks에서는 암호화 방식과 비밀번호를 확인하세요. VMess 및 VLESS에서는 식별자 항목과 사용하는 전송 방식을 확인하세요. Trojan에서는 비밀번호, TLS, SNI를 확인하세요. Hysteria2에서는 현재 네트워크가 필요한 UDP 통신을 지원하는지 살펴보세요. WebSocket 등의 전송 방식을 사용한다면 Host와 Path도 서버 측 설정과 일치해야 합니다. Type만 바꾼다고 서로 다른 프로토콜이 호환되는 것은 아닙니다. 포트 번호만 보고 프로토콜 종류를 추측하지도 마세요.

인증서 관련 오류가 나타나면 먼저 기기 날짜, SNI, 인증서 도메인이 일치하는지 확인한 다음 서버 인증서가 유효한지 살펴보세요. Allow Insecure를 만능 해결책처럼 사용하지 마세요. 검증을 우회하면 잘못된 주소나 비정상 인증서를 알아채지 못할 수 있습니다. TLS로 특정 포트에 연결됐다는 사실만으로 인증이 성공했거나 요청이 예상한 서버에 도달했다고 볼 수는 없습니다. 각 항목의 의미는 Trojan 매개변수 및 TLS 확인 안내를 참조하세요.

최소한의 비교로 문제가 발생하는 네트워크 구간을 확인하세요

가능하다면 같은 서버 구성을 유지한 채 Wi-Fi와 셀룰러 네트워크에서 각각 테스트하세요. 특정 네트워크에서만 실패한다면 인증 정보를 전부 새로 만드는 대신 해당 네트워크 환경이나 연결 경로를 먼저 확인해야 합니다. 반대로 같은 네트워크에서 특정 서버만 실패한다면 그 서버 항목의 주소, 포트, 서버 상태를 살펴보는 편이 좋습니다. 네트워크를 바꾼 뒤 연결 상태가 안정될 때까지 기다렸다가 같은 요청을 수행하세요. 전환 순간의 끊김을 지속적인 오류로 기록하지 않도록 합니다.

직접 추가한 항목은 작동하지만 구독에 포함된 같은 항목은 작동하지 않는다면 두 항목의 필드를 하나씩 비교하세요. 구독을 업데이트하면 로컬에서 수정한 내용이 덮어써질 수 있습니다. 기존 서버가 모두 실패하더라도 클라이언트가 손상됐다고 바로 단정할 수는 없습니다. 여러 항목이 같은 도메인, 인증 정보 또는 서버 진입점을 공유할 수 있습니다. 자신의 서비스 제공자에게 문의할 때는 발생 시각, 네트워크 종류, 프로토콜, 인증 정보를 가린 오류 내용을 전달하세요. 공개 게시판에 전체 인증 정보를 올리지 마세요. 수정 후에는 테스트 목록에 숫자가 표시되는지에 그치지 말고 실제 요청을 확인하세요.

04 Subscribe 업데이트 실패: 가져오기·해석·덮어쓰기를 구분하세요

구독 문제는 최소 세 단계로 나눠 확인해야 합니다. 클라이언트가 내용을 가져올 수 있는지, 응답을 인식할 수 있는지, 가져온 항목이 목록에 예상대로 추가됐는지 확인하세요. 첫 단계에서 실패했다면 서버 프로토콜을 반복해서 바꿔도 도움이 되지 않습니다. 내용은 가져왔지만 연결되지 않는다면 앞 항목을 확인하세요. 이 항목은 사용자가 자신의 구독을 보유하고 있다는 전제에서 설명합니다. 구독 링크는 접근 인증 정보의 일부입니다. 일반 URL처럼 보여도 스크린샷, 공개 로그, 다른 사람이 복사할 수 있는 설명에 노출하지 마세요.

주소가 완전한지 확인한 다음 가져오기 경로를 살펴보세요

Config의 Subscribe 관련 메뉴에서 보유한 주소를 확인하고, 복사 과정에서 쿼리 매개변수가 빠지거나 끝부분이 잘리거나 줄바꿈이 들어가지 않았는지 확인하세요. 앱에 구독 항목 편집 및 업데이트 메뉴가 있다면 현재 화면에 표시된 문구를 기준으로 진행하세요. 메뉴 이름과 위치는 설치된 앱 화면에서 확인해야 합니다. 서비스 안내 페이지, 계정 로그인 페이지, 단일 서버 공유 내용을 구독 주소로 사용하지 마세요. 현재 정보가 어떤 종류인지 원본 정보를 제공한 곳에 먼저 확인하세요.

업데이트가 한 번 실패했다면 연결을 끈 상태와 켠 상태 중 어느 때 실패했는지 기록하세요. 구독을 가져오는 요청도 네트워크를 사용하므로 현재 서버가 작동하지 않으면 업데이트 요청이 도달하지 못할 수 있습니다. 기본 네트워크가 정상인 상태에서 연결을 잠시 끄고 다시 업데이트해 볼 수 있습니다. 기존에 검증된 연결 경로를 사용해야만 구독을 가져올 수 있다면 직접 확인을 마친 항목을 먼저 선택하세요. 임시 제한과 원래 문제를 겹치게 만들 수 있으므로 짧은 시간에 계속 재시도하지 마세요.

요청이 성공했다고 해서 응답이 유효한 구독이라는 뜻은 아닙니다

네트워크 요청에 응답이 오더라도 로그인 페이지, 만료 안내, 인증 페이지 또는 오류 설명일 수 있습니다. 이때 ‘해석할 수 없음’은 클라이언트에서 임의의 형식 변환이 필요하다는 뜻이 아니라 응답 내용이 예상한 서버 항목이 아닐 수 있다는 뜻입니다. 구독이 아직 유효한지, 주소가 바뀌었는지, 제공자가 응답 형식을 변경했는지 확인하세요. 알 수 없는 웹페이지 내용을 현재 사용하는 Config에 덮어쓰지 말고, 구독 인증 정보를 모르는 온라인 변환 페이지에 입력하지 마세요.

일부 항목만 가져오고 나머지가 누락됐다면 누락된 항목의 프로토콜 유형, 필드 완성도, 현재 앱의 지원 여부를 비교하세요. 비밀번호나 인증 식별자를 임의로 만들어 넣지 말고 인코딩을 반복해서 바꾸며 추측하지도 마세요. 원본 응답을 공개하는 대신 인증 정보를 가린 필드 이름과 오류 문구로 상황을 설명하세요. 가져오기 방법의 차이는 Subscribe, Add Server, QR 코드 및 클립보드 입력 안내를 참조하세요.

업데이트 전에 로컬 편집 내용을 보호하고, 업데이트 후 선택 상태를 확인하세요

구독에는 일반적으로 원격에서 관리하는 정보가 포함되므로 업데이트 후 이름, 정렬 순서, 주소 또는 항목 수가 바뀔 수 있습니다. 로컬에서 임시로 수정한 매개변수가 계속 유지된다는 보장은 없습니다. 업데이트 전에 수정한 필드를 기록하고 필요한 경우 앱에서 지원하는 구성 백업을 저장하세요. 업데이트 후에는 이전에 선택한 서버가 아직 있는지 확인한 다음 Global Routing과 현재 Config를 점검하세요. 목록이 성공적으로 새로고침됐다고 해서 사용 중인 항목까지 사용할 수 있게 된 것은 아닙니다.

업데이트 후 목록이 비었다고 해서 모든 기존 항목을 바로 삭제하지 마세요. 업데이트 대상이 잘못 선택됐는지, 구독 응답에 내용이 없는지, 계정 상태가 바뀌었는지, 복원할 수 있는 로컬 기록이 있는지 먼저 확인하세요. 직접 추가한 항목 중 사용할 수 있는 것이 있다면 확인 기준으로 남겨 두세요. 전체 원본 정보를 보유하고 내용을 다시 가져올 수 있는지 확인한 경우에만 삭제 후 재추가를 고려하세요. 모든 해석 오류에 통하는 방법은 아닙니다.

마지막으로 업데이트된 서버 항목 하나를 선택해 필수 매개변수를 확인한 뒤 같은 일반 웹페이지를 테스트하세요. 구독 업데이트는 성공했지만 서버 시간 초과가 발생한다면 Subscribe를 반복해서 다시 시도하지 말고 연결 매개변수 항목으로 이동하세요. 자동 업데이트만 실패하고 수동 업데이트는 정상이라면 실패 당시의 네트워크 상태와 시간 조건을 확인하세요. 백그라운드 기능이 손상됐다고 먼저 추측하지 마세요. 앱 일회성 구매와 보유한 구독의 유효 기간은 별개이므로 앱을 다시 구매해도 구독 주소가 만료된 문제는 해결되지 않습니다.

05 속도가 느릴 때: 핸드셰이크·전송량·대상 서비스를 구분하세요

‘느리다’는 것은 페이지를 열기 전에 오래 기다리는 경우일 수도 있고, 페이지는 바로 뜨지만 큰 파일 전송이 느린 경우일 수도 있으며, 이미지나 동영상 또는 특정 앱에서만 문제가 생기는 경우일 수도 있습니다. 같은 대상을 처음 열 때 걸리는 시간, 다시 열었을 때 나아지는지, 네트워크를 바꾸면 달라지는지를 재현 가능한 방식으로 설명하세요. Connectivity Test 결과를 다운로드 속도로 간주하지 마세요. 짧은 요청의 왕복 시간과 지속적인 전송 능력은 서로 다른 지표입니다. 한 번의 테스트로 혼잡, 패킷 손실, 대상 서비스 부하를 모두 확인할 수는 없습니다.

비교 가능한 테스트 환경을 마련하세요

가능한 한 같은 기기, 같은 네트워크, 같은 대상을 선택하고 비슷한 시간대에 비교하세요. 네트워크를 사용하는 클라우드 동기화, 대용량 파일 전송, 앱 업데이트는 잠시 멈춰 다른 작업이 대역폭을 점유하지 않도록 하세요. 현재 서버와 Global Routing을 기록한 다음 첫 방문과 재방문을 각각 확인하세요. 처음에는 느리지만 다시 열면 뚜렷하게 빨라지는 경우 DNS, TLS 핸드셰이크 또는 콘텐츠 캐시가 원인일 수 있습니다. 계속 전송하는 내내 느리다면 경로 품질, 혼잡, 서버의 실제 처리 능력을 살펴보세요.

서버, DNS, 규칙을 한꺼번에 바꾼 뒤 비교하지 마세요. 속도가 개선돼도 어떤 변경이 영향을 줬는지 알 수 없습니다. 직접 관리하는 서버가 여러 개 있다면 한 번에 하나씩만 바꾸고 같은 요청을 다시 테스트하세요. 네트워크 전환 중의 일시적인 끊김을 안정적인 속도로 기록하지도 마세요. Wi-Fi 또는 셀룰러 연결이 안정될 때까지 기다리고 시스템의 네트워크 인증이 진행 중이지 않은지 확인한 다음 다음 테스트를 시작해야 결과를 해석할 수 있습니다.

일부 콘텐츠만 느리다면 도메인과 정책을 확인하세요

하나의 페이지는 메인 사이트, 정적 리소스, 이미지, API 등 여러 도메인에 요청할 수 있습니다. 메인 페이지는 빠르지만 리소스가 느리다면 리소스 도메인에 다른 정책이 적용됐거나 범위가 너무 넓은 규칙으로 출구가 바뀌었을 수 있습니다. 방금 발생한 요청 기록에서 느린 요청의 실제 도메인과 적용된 정책을 확인하세요. 오류가 확인된 도메인에만 규칙을 조정하고 관련 도메인 전체를 같은 방식으로 처리하지 마세요. 대상 서비스는 지역, 계정 또는 캐시에 따라 콘텐츠를 다르게 제공할 수 있습니다. 서버 테스트가 정상이라는 이유만으로 대상 서비스 차이를 배제하지 마세요.

Config가 느리고 Proxy는 정상이라면 정책 그룹, 규칙 순서, DNS 조회 경로를 확인하세요. 두 모드 모두 느리고 같은 대상에 Direct로 접속하면 정상이라면 현재 서버 경로를 추가로 살펴보세요. 하지만 특정 대상에서 Direct 접속이 실패했다고 해서 서버가 더 빠르거나 느리다는 증거가 되지는 않습니다. 두 경로의 접속 가능 여부가 다를 수 있기 때문입니다. 비교하려면 두 방식 모두에서 같은 작업을 완료할 수 있는 대상이어야 합니다.

UDP, MTU, 전송 매개변수를 근거 없이 바꾸지 마세요

실시간 통신, 일부 스트리밍 서비스, 특정 프로토콜은 UDP에 의존할 수 있으므로 일반 웹페이지가 열린다고 UDP 경로까지 정상이라고 볼 수는 없습니다. 이런 기능만 문제가 있다면 서버 지원 여부와 현재 네트워크 제한을 먼저 확인하세요. Hysteria2 등의 프로토콜에서는 대역폭 항목을 바꾸는 것으로 기본 연결 여부를 대신 확인할 수 없습니다. 더 큰 값을 입력해도 실제 전송 속도가 빨라지는 것은 아닙니다. 직접 보유한 서버의 설정 안내를 기준으로 기존 값을 보존하면서 한 번에 한 항목씩 테스트하세요.

작은 요청은 정상인데 큰 요청이 멈춘다면 경로 MTU를 추가 조사 대상으로 고려할 수 있지만 근거 없이 반복해서 변경하지 마세요. 패킷 손실, 대상 서비스의 속도 제한, 연결 재설정도 비슷한 증상을 일으킬 수 있습니다. 특정 네트워크에서만 발생하는지, 특정 프로토콜에 한정되는지, 이미 사용 가능한 다른 서버로 바꾸면 사라지는지 먼저 확인하세요. 관련성이 확인되고 복구 방법을 알고 있는 경우에만 서버 설정에 맞춰 매개변수를 조정하세요.

기기 발열도 실제 사용 경험에 영향을 줄 수 있습니다. 장시간 고부하 전송, 켜 둔 화면, 백그라운드 작업이 동시에 진행될 수 있습니다. 테스트를 잠시 멈춰 기기가 정상 상태로 돌아오게 한 뒤 짧은 요청을 다시 확인하세요. 기기 온도가 뚜렷하게 올라간 상태에서 속도 테스트를 반복하지 마세요. 최종 판단은 테스트 화면의 숫자만 좇지 말고 원래 작업으로 돌아가 웹페이지가 제때 열리는지, 동영상이 계속 버퍼링되는지, 파일이 안정적으로 전송되는지를 확인해야 합니다.

06 DNS 문제: 조회 출처와 요청 경로 확인

DNS는 도메인을 연결에 사용할 수 있는 주소로 변환합니다. 도메인을 해석할 수 없으면 프록시 핸드셰이크가 시작되지 않을 수 있습니다. 도메인을 해석했더라도 현재 경로에 적합하지 않은 주소라면 시간 초과가 발생하거나 잘못된 곳에 접속될 수 있습니다. 여러 도메인이 동시에 실패하거나, 처음 열 때 오래 기다리거나, 네트워크를 바꾼 뒤 일부 대상에 접속할 수 없는 것이 단서가 될 수 있습니다. ‘특정 IP 주소로 접속된다’는 이유만으로 DNS 문제라고 단정하지 마세요. HTTPS에는 도메인, SNI, 인증서 검증도 관련됩니다.

기억에 의존하지 말고 현재 Config를 확인하세요

현재 실제로 사용 중인 구성을 열어 General의 dns-server와 주소 해석에 영향을 주는 매핑 또는 규칙이 있는지 확인하세요. 아래 예시는 시스템이 제공하는 DNS를 사용한다는 의미로, 문법을 설명하기 위한 것이며 모든 네트워크에 적합한 것은 아닙니다. 수정 전에 현재 값을 저장하세요. 특히 기존의 분할 DNS 설정을 하나의 주소로 덮어쓰지 마세요. 시스템 DNS의 실제 출처는 Wi-Fi, 셀룰러 네트워크, 기기 관리 설정에 따라 달라질 수 있으므로 고정된 값으로 간주하면 안 됩니다.

[General]
dns-server = system

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

수동 Host 매핑이나 오래된 주소가 있는지 확인하세요. 이런 항목은 조사 중인 일반 DNS 경로를 우회하므로 dns-server를 바꿔도 달라진 점이 없어 보일 수 있습니다. 특정 도메인이 만료된 주소에 고정되어 있다면 직접 보유한 원래 구성과 대조한 뒤 제거하거나 수정하세요. 공개 게시물에서 본 주소를 매핑에 그대로 입력하지 마세요. 도메인과 주소의 대응 관계는 지역, 서비스 배포, 시간에 따라 달라질 수 있습니다.

암호화된 DNS도 기본 연결 경로에 접근할 수 있어야 합니다

암호화된 DNS를 사용해도 DNS 서비스 자체에 연결할 수 있어야 합니다. DNS에 접속하려면 먼저 프록시를 연결해야 하는데 프록시 서버 주소는 같은 경로로 해석해야 한다면 초기 연결 단계에서 의존성 문제가 생길 수 있습니다. 문제를 확인할 때는 먼저 서버 도메인을 처음 해석할 수 있는지 확인하고 그다음 대상 도메인을 살펴보세요. DNS 서비스와 프록시 주소를 동시에 바꾸면 DNS가 복구된 것인지 서버 경로가 달라진 것인지 구분하기 어렵습니다.

일부 공용 Wi-Fi는 지정된 DNS 및 인증 절차만 허용할 수 있습니다. 인증이 완료되기 전에는 DNS 설정을 바꿔도 도움이 되지 않을 수 있습니다. 먼저 연결을 끄고 네트워크 로그인을 완료한 다음 기존 구성으로 다시 테스트하세요. 특정 네트워크에서만 문제가 발생한다면 같은 구성을 자신이 사용할 수 있는 다른 네트워크에서도 비교하세요. 구성을 그대로 둔 상태에서 결과가 달라진다면 모든 도메인 규칙을 바로 수정하지 말고 해당 네트워크가 DNS 요청을 처리하는 방식을 우선 확인하세요.

IPv4·IPv6과 규칙 적용을 함께 확인하세요

같은 도메인에서도 IPv4와 IPv6 주소가 모두 반환될 수 있으며, 기기에서 실제로 선택하는 경로는 네트워크 성능에 따라 달라집니다. IPv6를 지원하는 네트워크에서만 문제가 발생한다면 관련 기능을 바로 전역으로 끄지 말고 해석 결과의 주소 유형, 실제 연결 대상, 실패 방식을 기록하세요. IP-CIDR과 IP-CIDR6는 서로 다른 주소 체계를 처리하므로 IPv4만 대상으로 하는 로컬 규칙으로 IPv6까지 포함되지 않을 수 있습니다. 도메인 규칙과 주소 규칙은 적용 시점도 다르므로 수정하기 전에 요청이 실제로 어떤 규칙에 적용됐는지 확인하세요.

GEOIP는 주소의 위치 정보에 따라 판단하며, 모든 도메인의 용도를 정확히 표현하는 것은 아닙니다. CDN 주소는 바뀔 수 있고 하나의 주소가 여러 도메인에서 공유될 수도 있습니다. 범위가 명확한 소수의 업무 요구 사항이라면 주소 범위를 계속 넓히기보다 더 구체적인 DOMAIN 또는 DOMAIN-SUFFIX 규칙으로 표현할 수 있는지 확인하세요. 설명 가능한 기본 규칙으로 FINAL을 유지하고 정책이 현재 사용 목적에 맞는지 확인하세요.

설정을 바꾼 뒤 실패했던 요청을 다시 실행하고 앱이나 시스템에 캐시가 남아 있을 수 있다는 점을 고려하세요. 관련 페이지를 닫았다가 다시 열어 새 요청을 확인하세요. 재연결이 필요하다면 연결을 끊기 전후의 설정도 기록하세요. 검증 대신 모든 기기를 반복해서 재시동하지 마세요. 성공 여부는 대상 도메인이 합리적인 결과를 반환하고, 요청이 예상한 정책을 거쳐 실제로 완료되는지로 판단해야 합니다. DNS 테스트 하나만 성공했다고 충분한 것은 아닙니다. 용어 설명은 용어 해설을 참조하세요.

07 배터리 소모·발열·잦은 재연결: 활동 원인 확인

VPN을 장시간 유지한다고 해서 반드시 비정상적으로 배터리를 많이 소모하는 것은 아닙니다. 실제로 확인할 것은 전송량, 재연결 횟수, 기기 온도, 같은 시간대에 다른 앱이 얼마나 활동했는지입니다. 시스템 배터리 화면은 일정 기간의 통계를 보여 주며 단일 요청의 정확한 전력 소모량을 나타내지는 않습니다. 문제가 시작된 시각, 당시 네트워크와 사용 앱을 먼저 기록한 뒤 비슷한 작업을 비슷한 시간 동안 수행했을 때와 비교하세요. 특정 통계에서 비중이 높게 나타났다고 해서 클라이언트가 계속 최대 부하로 작동했다고 단정하지 마세요.

지속적인 전송과 백그라운드 작업을 먼저 확인하세요

사진 동기화, 대용량 파일 전송, 동영상 재생, 앱 업데이트가 진행 중인지 확인하세요. 이런 작업이 연결을 거치면 네트워크 확장 기능이 계속 트래픽을 처리할 수 있으므로 업무 앱과 연결 확장 기능의 통계를 함께 살펴봐야 합니다. 관련 작업을 멈추고 다른 조건을 그대로 유지한 채 일정 시간 동안 발열이 계속되는지 관찰하세요. 배터리 소모를 테스트하면서 Connectivity Test를 대량으로 실행하지 마세요. 테스트 자체가 연결과 데이터 전송을 발생시킵니다.

시스템 배터리 화면에 표시되는 백그라운드 활동은 실제 사용 환경과 함께 해석해야 합니다. 화면이 계속 켜져 있거나 셀룰러 신호가 약한 경우, 핫스팟을 공유하거나 주변 온도가 높은 경우에도 배터리 소모가 커질 수 있습니다. 기기를 정상 온도와 안정적인 네트워크 환경에 둔 뒤 비교하면 잘못 판단할 가능성이 줄어듭니다. 연결을 끈 뒤에도 계속 발열한다면 기기 상태와 다른 앱의 활동을 먼저 확인하고 모든 문제를 Shadowrocket 규칙 구성 탓으로 돌리지 마세요.

On Demand 동작과 네트워크 전환을 따로 확인하세요

On Demand는 시스템 조건에 따라 연결을 시작합니다. Wi-Fi와 셀룰러 네트워크가 자주 전환되거나 액세스 포인트 연결이 잠시 끊기면 연결과 해제가 여러 번 발생할 수 있습니다. 먼저 On Demand 조건을 기록한 다음 잠시 끄고 같은 네트워크에서 수동 연결해 재연결이 줄어드는지 확인하세요. 실제로 줄어든다면 조건이 서로 겹치는지, 네트워크가 안정적인지 다시 살펴보세요. 자신이 이해하지 못하는 연결 조건을 계속 켜 둔 채 사용하는 것으로 해결하지 마세요.

기기가 잠자기 상태에서 깨어나거나 Wi-Fi 범위를 벗어나거나 네트워크 인증을 진행할 때는 환경 변화로 연결이 잠시 재구성될 수 있습니다. 네트워크가 안정된 뒤에도 반복되는 경우가 문제입니다. 로그를 확인해 시스템이 연결을 시작했는지, 서버 핸드셰이크가 실패했는지, 업무 요청이 계속 재시도되고 있는지 구분하세요. 그래야 On Demand를 조정할지, 서버를 확인할지, 요청을 계속 보내는 앱을 점검할지 판단할 수 있습니다. 상태 아이콘이 깜빡이는 것만으로는 충분하지 않습니다.

로그·규칙·연결 실패에 따른 부담

문제 해결을 위해 자세한 로그를 켰다면 필요한 기록을 수집한 뒤 평소 사용하는 기록 수준으로 되돌리세요. 자세한 기록을 오랫동안 유지하면 저장 공간과 처리 부담이 늘고 개인정보가 남을 수 있습니다. 로그는 짧은 시간 동안 한 번의 문제를 재현할 때 수집하면 되며, 일상적인 요청을 전부 계속 저장할 필요는 없습니다. 공유하기 전에 도메인에 포함된 식별 정보, 서버 주소, 인증 내용을 가리고 원인 파악에 필요한 오류 맥락만 남기세요.

작동하지 않는 서버로 연결하면 업무 요청이 반복해서 대기하거나 재시도될 수 있습니다. 현재 규칙에서 일상 트래픽의 상당 부분을 사용할 수 없는 정책으로 보내고 있다면 백그라운드 배터리 소모처럼 보여도 실제 원인은 반복되는 연결 실패일 수 있습니다. 먼저 현재 사용하는 서버가 작동하는지 확인하고 특정 도메인이 잘못 차단되어 요청을 반복하는지도 살펴보세요. 규칙이 많다는 사실만으로 배터리 소모의 원인이라고 판단할 수는 없습니다. 실제 요청, 실패 빈도, 설정 변경 전후의 비교 결과를 근거로 삼으세요.

현재 네트워크에서 특정 프로토콜만 계속 재연결된다면 보유한 다른 사용 가능 구성을 같은 대상과 작업으로 비교하세요. 프로토콜, 서버, 작업 부하를 한꺼번에 바꾼 뒤 특정 설정의 문제라고 단정하지 마세요. WireGuard처럼 구체적인 배포 매개변수에 의존하는 항목의 Keepalive 관련 값도 임의로 바꾸지 마세요. 필요 여부와 적절한 값은 서버와 네트워크 환경을 함께 고려해 판단해야 합니다.

관찰을 마친 뒤 로그를 평소 수준으로 되돌리고 On Demand가 예상한 상태인지 확인한 다음 기기 온도와 배터리 변화가 개선됐는지 기록하세요. 작업을 멈추고 네트워크를 안정화하고 사용 가능한 서버를 선택해도 문제가 계속된다면, 인증 정보를 가린 기록을 남겨 업데이트 후 문제를 확인하세요. 시스템 배터리 데이터에는 통계 기간이 있으므로 설정을 변경한 뒤 비교 가능한 사용 시간이 지나야 합니다. 스위치를 몇 초 바꿨다고 이전 통계 비율이 즉시 바뀌지는 않습니다.

08 업데이트 후 및 iPad 문제: 기준 상태를 복원하고 차이를 확인

업데이트 직후 문제가 생겼더라도 업데이트가 유일한 원인이라고 단정할 수는 없습니다. 앱 업데이트, 시스템 업데이트, 구독 새로고침, 서버 변경, 네트워크 전환이 비슷한 시기에 일어났을 수 있습니다. 마지막으로 연결에 성공한 시점과 처음 실패한 시점 사이에 바뀐 사항을 적은 다음 변수를 최소화해 다시 테스트하세요. 현재 Config와 원본 서버 정보를 보관하고 모든 데이터를 바로 지우지 마세요. 구매 복원은 앱을 사용할 자격을 복원하는 절차일 뿐 사용자가 직접 편집한 모든 로컬 내용을 자동으로 복원하지는 않습니다.

업데이트 후에는 현재 선택 항목과 시스템 권한을 먼저 확인하세요

Home을 열고 선택된 서버, Global Routing, 시스템 연결 상태를 확인한 다음 현재 활성화된 Config가 예상한 파일인지 확인하세요. 정책 그룹을 사용했다면 그룹 안의 선택 항목도 바뀌지 않았는지 살펴보세요. 구성 목록에 파일이 있다고 해서 현재 적용 중이라는 뜻은 아닙니다. 이름이 비슷해도 내용이 같다는 보장은 없습니다. 직접 저장해 둔 정상 상태의 구성을 우선 대조해 차이를 확인한 뒤 수정하세요. 원인을 찾는 대신 모든 설정을 기본값으로 초기화하지 마세요.

시스템 VPN 구성이 제거됐거나 기기를 옮긴 뒤 권한을 다시 허용해야 한다면 첫 번째 항목의 시스템 안내를 따르세요. 앱은 열리지만 모든 연결에 실패하는 경우에는 현재 네트워크에서 연결을 끄고 기본 접속이 가능한지 확인한 뒤 기존에 사용하던 서버로 테스트하세요. 필요한 경우 기기를 정상적으로 재시동한 뒤 한 번 더 확인하고 결과를 기록하세요. 업데이트 내역과 시스템 요구 사항은 App Store 페이지에서 확인하세요. 오래된 온라인 문서의 스크린샷만 보고 현재 화면에 기능이 ‘없다’고 판단하지 마세요.

iPad와 iPhone을 비교할 때는 테스트 조건부터 맞추세요

같은 구독이 iPhone에서는 작동하고 iPad에서는 작동하지 않는다면 두 기기가 정말 같은 서버, 같은 프로토콜 매개변수, 같은 Config를 사용하고 있는지 먼저 확인하세요. 구독 이름이 같아도 최근 업데이트된 내용이 두 기기에서 같다는 보장은 없습니다. 특히 한 기기에서 로컬 편집을 했다면 Global Routing과 DNS도 비교하세요. 항목별로 확인하기 전에 iPad에만 발생하는 호환성 문제라고 단정하지 마세요.

네트워크 조건도 다를 수 있습니다. iPad는 Wi-Fi에만 연결되어 있고 iPhone은 실제로 셀룰러 데이터를 사용 중일 수 있습니다. 두 기기를 같은 Wi-Fi에 연결하고 같은 대상을 테스트한 다음 결과를 각각 확인하세요. iPad에서만 실패한다면 VPN 권한, 기기 관리 제한, 네트워크 인증 상태, 시스템 날짜를 살펴보세요. 두 기기 모두 실패한다면 공유 서버, 구독 또는 라우터를 확인하고 태블릿 화면 배치 문제를 더 조사할 필요는 없습니다.

iPad의 가로 화면, 분할 화면, 창 배치에 따라 메뉴 위치는 달라질 수 있지만 이름이 같은 항목의 서버 매개변수가 달라지는 것은 아닙니다. Home, Config, Settings 같은 인터페이스 문구를 기준으로 기능을 찾으세요. 화면 공간이 부족하면 조작하기 편한 전체 창으로 전환해 확인하세요. 메뉴가 휴대전화 스크린샷과 같은 위치에 보이지 않는다고 중복 구성을 새로 만들지 마세요. 기본 사용 방법은 시작하기를 참조하고, 이 페이지에서는 차이와 문제를 다룹니다.

앱을 다시 받기 전에 백업과 구매 범위를 확인하세요

앱을 다시 받아야 한다면 App Store만 이용하세요. 먼저 기존 구매 계정과 구입 항목을 확인하고 구체적인 절차는 구입 항목 복원 안내를 참조하세요. 정품 여부는 개발자 Shadow Launch Technology Limited, 공식 아이콘, 앱 ID 932747118을 확인하세요. Shadowrocket은 클로즈드 소스 상용 앱입니다. 시스템 요구 사항과 기기별 이용 가능 여부는 App Store 페이지에 표시된 내용을 기준으로 하며 오래된 안내를 근거로 모든 기기에서 사용할 수 있다고 추측하지 마세요.

다시 설치하기 전에 기존 구독 주소, 직접 추가한 서버 매개변수, 로컬 Config를 직접 복원할 수 있는 방식으로 안전하게 저장했는지 확인하세요. 백업에는 비밀번호, 개인 키, 접근 인증 정보가 포함될 수 있으므로 자신이 관리하는 저장 공간을 이용하고 공개 페이지에 게시하지 마세요. 앱 구매 기록, 시스템 VPN 구성, 사용자가 보유한 연결 데이터는 서로 다른 항목입니다. 앱 구매를 복원할 수 있다고 해서 나머지 두 항목까지 복원됐다는 뜻은 아닙니다. 앱을 다시 연 뒤에도 처음 권한을 설정하고 연결을 확인하는 절차를 따르세요.

재현 가능한 문제 기록을 작성하세요

직접 점검해도 문제가 해결되지 않으면 기기 종류, 시스템과 앱에 표시되는 정보, 네트워크 종류, 문제가 발생한 메뉴, 인증 정보를 가린 오류 문구, 마지막으로 정상 작동한 작업, 이미 비교한 결과를 간단히 기록하세요. 스위치가 꺼지는지, 도메인 해석이 실패하는지, 핸드셰이크가 실패하는지, 특정 요청에서 시간 초과가 발생하는지 명확히 구분하세요. ‘업데이트 후 안 됨’이라고만 적지 말고 관련 없는 스크린샷을 한꺼번에 많이 보내 실제로 실패한 단계가 묻히지 않도록 하세요.

서버 인증, 구독 유효성, 서버 측 프로토콜 매개변수 문제는 자신이 정보를 받은 곳에 확인하세요. 시스템 권한이나 기기 관리 제한은 기기 설정에서 해결해야 합니다. 문제가 해결되면 On Demand, Global Routing, 로그 수준, 임시 테스트 규칙이 예상한 상태로 돌아왔는지 확인하세요. 문제 해결은 우연히 웹페이지 하나가 열린 시점이 아니라 기록된 정상 구성에서 원래 실패했던 작업을 반복해서 완료할 수 있을 때 끝납니다.