Shadowrocket 사용 가이드

Global Routing 모드 선택

서버 항목은 프록시 연결에 사용할 매개변수를 정하고, Global Routing은 요청이 어떤 경로를 선택할지 정합니다. 두 항목을 따로 확인해야 합니다. 목록에서 서버를 선택했다고 해서 모든 요청이 해당 서버를 거치는 것은 아닙니다. Home으로 돌아가 Global Routing을 누르고 현재 옵션을 확인한 뒤 이번 테스트 목적에 따라 구성(Config), 프록시(Proxy) 또는 직접 연결(Direct)을 선택하세요. 변경 후 Home으로 돌아와 모드 이름을 다시 확인해 메뉴만 열고 선택을 완료하지 않은 상황을 방지합니다.

구성(Config): 현재 구성에 따라 요청 처리

일상적으로 규칙에 따라 트래픽을 분기하려면 구성(Config)을 사용합니다. 현재 활성화된 구성을 읽고 규칙 일치 순서에 따라 요청을 프록시로 보내거나 직접 연결하거나 다른 동작을 실행합니다. 따라서 Config를 선택하기 전에 Config 메뉴에서 현재 사용 중인 구성을 확인해야 합니다. 목록에 파일이 하나 있다는 사실만으로는 충분하지 않습니다. 방금 가져온 파일과 실제 활성화된 파일은 다를 수 있으며, 잘못된 파일을 수정해도 현재 연결 동작은 바뀌지 않습니다.

본인의 구성이 있다면 먼저 백업한 뒤 활성화하고, 인터넷에서 가져온 규칙을 무작정 끝에 덧붙이지 마세요. DOMAIN-SUFFIX, GEOIP, FINAL 같은 규칙 키워드는 일치 범위가 서로 다릅니다. 앞쪽 규칙에서 요청을 이미 처리했다면 뒤쪽 규칙은 더 이상 일치 여부를 확인하지 않습니다. 이 페이지에서는 활성화 여부와 기본 경로만 확인합니다. 구문과 개념은 용어 가이드에서 자세히 확인할 수 있습니다.

프록시(Proxy)와 직접 연결(Direct): 경로 비교

프록시(Proxy)는 선택한 프록시 경로가 작동하는지 임시로 확인할 때 적합하며, 일반 규칙을 하나씩 적용해 경로를 결정하지 않습니다. 서버에 반드시 연결할 수 있다는 뜻도 아니고 모든 앱 동작이 같은 방식으로 처리된다는 보장도 없습니다. 직접 연결(Direct)은 요청을 직접 연결 경로로 보내 로컬 네트워크 결과와 비교할 때 사용합니다. Direct를 선택한 상태에서 앱 스위치가 켜져 있다는 이유만으로 요청이 프록시를 사용한다고 판단하면 안 됩니다.

처음 문제를 점검할 때는 Proxy를 사용해 명확한 대상 하나를 비교할 수 있습니다. 프록시 경로를 확인한 뒤 Config로 돌아가 트래픽 분기를 확인합니다. 임시 점검 모드를 규칙 설정이 완료된 상태로 오해하고 계속 사용하지 마세요. 모드를 변경할 때마다 같은 페이지를 다시 테스트하고 차이를 기록하면 이후 문제가 생겼을 때 서버 자체의 오류인지 규칙이 다른 경로를 선택한 것인지 구분하기 쉽습니다.

연결 스위치를 켜고 시스템 권한 승인

Home에서 예상한 서버가 선택되어 있고 Global Routing이 이번 테스트에 맞는지 확인한 뒤 Home 상단의 연결 스위치를 켭니다. 처음 연결할 때 iPhone / iPad에 VPN 구성 추가를 묻는 시스템 안내가 표시될 수 있습니다. 안내가 Shadowrocket에서 시작된 것인지 확인한 뒤 추가를 허용하고, 시스템 요구에 따라 기기 암호나 인증을 사용해 완료합니다. 시스템 권한은 연결을 설정하는 데 필요한 것으로, 구매 확인이 아니며 서버에서 누락된 항목을 채우지도 않습니다.

권한 승인이 끝나면 Shadowrocket으로 돌아와 스위치가 계속 켜져 있는지 확인합니다. 스위치가 바로 꺼지거나 연결 중 상태가 지속되거나 권한 안내가 다시 나타나면 반복해서 누르지 마세요. 안내 문구를 확인해 이전 시스템 승인이 실제로 완료되었는지 점검합니다. 이전에 취소했다면 연결을 다시 시작하고 권한을 승인하면 됩니다. 용도를 모르는 상태에서 기기 구성을 삭제하지 마세요. 특히 회사나 학교에서 관리하는 기기라면 먼저 관리 제한 사항을 확인해야 합니다.

연결을 테스트하는 동안 시스템 VPN 연결을 사용할 수 있는 다른 서비스를 중지한 다음 Shadowrocket만 켜서 서비스 간 전환으로 인한 간섭을 줄입니다. 시스템 설정의 연결 상태와 앱 상태가 동기화되지 않으면 먼저 앱에서 연결을 끄고 상태가 복구될 때까지 기다린 뒤 다시 켭니다. 각 조작 사이에 상태가 전환될 시간을 두세요. 스위치를 빠르게 연속으로 전환하면 실패 위치를 파악하기 더 어려워질 수 있습니다.

시스템의 VPN 표시는 해당 네트워크 연결이 설정되었음을 나타낼 뿐, 대상 페이지가 예상한 규칙을 통해 처리되었다는 사실까지 증명하지는 않습니다. 기기마다 상태 표시의 위치와 방식이 다를 수 있으므로 아이콘을 찾으려고 반복해서 재연결할 필요는 없습니다. 스위치 색상만 확인하지 말고 앱 테스트와 실제 요청을 함께 확인하세요.

처음 확인할 때는 On Demand를 추가로 조정하지 마세요. On Demand는 조건에 따라 연결을 시작하는 기능이며 서버 주소, 인증 정보 또는 규칙 오류를 수정하지 않습니다. 먼저 수동으로 켜고 끄는 흐름을 확인한 다음 본인의 네트워크 사용 방식에 맞게 자동 연결 조건을 설정하세요. 그래야 이후 자동 연결에 문제가 생겼을 때 확인된 수동 연결 과정과 비교할 수 있습니다.

Connectivity Test와 실제 요청으로 확인

연결을 켠 상태로 Home에서 Connectivity Test를 실행해 선택한 서버에 기본적으로 연결할 수 있는지 확인합니다. 테스트 결과로 명확한 실패를 찾을 수 있지만 테스트 방식과 대상은 실제 앱의 접근 방식과 완전히 같지 않습니다. 따라서 테스트가 성공해도 모든 웹사이트가 열리는 것은 아니며, 실패한 경우에도 실제 요청과 함께 판단해야 합니다. 한 번의 결과만으로 구독 전체를 삭제하지 마세요.

그다음 브라우저를 열어 평소 사용하는 페이지 중 로딩 완료 여부를 분명히 판단할 수 있는 곳에 접속합니다. 먼저 페이지의 주요 콘텐츠가 표시되는지 확인한 뒤 사이트 내부의 링크를 누르거나 새로고침해 보세요. 캐시된 내용만 보고 연결에 성공했다고 단정하지 마세요. 테스트 대상 자체가 점검 중이라면 정상 작동하는 것으로 알려진 다른 대상으로 다시 테스트합니다. 출처가 불분명한 검사 페이지를 사용하거나 구독 링크 및 서버 인증 정보를 검사 서비스에 제출하지 마세요.

규칙 분기를 확인하려면 Config로 돌아가 현재 활성화된 구성을 확인한 다음 새로운 요청을 보냅니다. 앱에서 확인할 수 있는 요청 기록을 함께 살펴 대상 도메인, 일치한 규칙 및 실제 처리 경로를 확인합니다. 직접 연결이 예상되는 요청은 DIRECT 처리와 일치해야 하고, 프록시가 예상되는 요청은 현재 구성의 프록시 동작과 일치해야 합니다. 규칙이 정책을 참조한다면 규칙 이름만 보지 말고 정책에서 최종적으로 선택된 항목도 확인하세요.

“연결을 끈 상태의 로컬 결과, Proxy 결과, Config 결과”를 비교할 수 있습니다. 매번 조건 하나만 바꾸고 기기, 네트워크, 테스트 대상을 동일하게 유지하세요. Proxy는 정상인데 Config에서 실패하면 규칙과 구성을 먼저 확인합니다. 둘 다 실패하면 규칙을 계속 추가하는 대신 서버 매개변수와 네트워크를 점검하세요. 비교를 마친 뒤 일상적으로 필요한 모드로 되돌립니다.

마지막으로 연결을 끄고 다시 켜서 확인합니다. 먼저 연결을 끄고 로컬 네트워크가 여전히 정상인지 확인한 뒤 다시 활성화해 실제 접속을 반복합니다. 처음에는 정상이었지만 네트워크를 전환한 뒤 실패한다면 Wi-Fi와 셀룰러 네트워크 중 어느 쪽에서 문제가 발생했는지 기록하세요. 속도와 안정성은 사용 환경에 따라 판단해야 합니다. Connectivity Test의 단일 결과를 다운로드 속도로 환산하거나 장기적인 안정성의 결론으로 삼아서는 안 됩니다.

실패 지점별로 점검하고 한 번에 하나만 변경

문제 해결은 앱 재설치가 아니라 로컬 네트워크 확인부터 시작합니다. Shadowrocket 연결을 끄고 기기 자체가 정상적으로 인터넷에 연결되는지 확인하세요. Wi-Fi에서 네트워크 인증이 끝나지 않았다면 먼저 인증 페이지를 완료한 뒤 다시 연결합니다. 로컬 연결 자체가 실패했다면 서버 비밀번호, 규칙 또는 DNS 변경으로 근본 원인을 해결하기 어려울 수 있습니다. 셀룰러 네트워크 사용이 가능하다면 한 번 전환해 비교하되 데이터 사용량을 확인하세요.

가져오기 실패: 콘텐츠와 업데이트 결과 확인

Subscribe로 저장한 뒤 서버가 보이지 않으면 링크가 잘리지 않았는지, 공백이 포함되지 않았는지, 서비스 상태가 업데이트를 허용하는지 다시 확인합니다. 기존 그룹에 이전 항목이 표시되어 있어도 이번 업데이트가 성공했다는 뜻은 아닙니다. 업데이트 안내를 확인하고 콘텐츠가 예상한 것과 일치하는지 점검하세요. 링크가 로그인 페이지나 오류 문구를 반환한다면 먼저 링크에 접근할 수 있는 조건을 해결합니다. 서비스 제공자에게 문의할 때는 오류와 발생 시각을 설명하고 공개된 곳에 개인 URL 전체를 올리지 마세요.

연결 실패: 항목을 대조한 뒤 네트워크 확인

특정 서버만 실패하면 해당 기록을 열고 보유한 정보를 기준으로 프로토콜, 주소, 포트, 비밀번호 또는 기타 인증 항목을 확인합니다. TLS를 사용하는 경우 서버가 요구하는 관련 이름과 전송 옵션도 확인해야 합니다. 모든 선택 옵션을 켜는 방식으로 시도하지 마세요. 같은 구독의 여러 항목이 동시에 실패하면 먼저 서로 다른 로컬 네트워크에서 결과를 비교한 뒤 필요한 경우 기존 서비스 제공자에게 문의합니다. 한 번의 테스트 실패만으로 항목을 반복해서 삭제하고 다시 추가하지 마세요.

스위치는 켜졌지만 페이지가 열리지 않음: 규칙과 DNS 구분

먼저 Global Routing이 Direct가 아닌지 확인한 다음 Proxy와 Config의 결과를 비교합니다. Config에서만 실패한다면 올바른 구성이 활성화되어 있는지, 대상이 앞선 규칙에서 처리되었는지, 참조하는 정책을 사용할 수 있는지 확인하세요. 도메인을 확인할 수 없는 경우 여러 주소를 임의로 입력하지 말고 현재 DNS 설정과 네트워크 조건을 점검합니다. 변경 전에 원래 값을 저장하고 한 번에 하나씩만 수정하세요. 값을 되돌렸을 때 같은 문제가 재현되는지도 변경 효과를 판단하는 데 도움이 됩니다.

브라우저는 정상인데 특정 앱만 실패한다면 앱 자체의 캐시, 연결 재사용, 서비스 상태 및 접근 요구 사항도 고려해야 합니다. 대상 앱을 완전히 종료한 뒤 다시 열어 새로운 요청을 보내세요. 전체 연결에 문제가 있다고 바로 판단하지 마세요. 반대로 모든 대상에서 실패한다면 특정 앱 설정만 계속 확인하기보다 서버, 시스템 권한, 로컬 네트워크라는 기본 조건으로 돌아가 점검합니다.

재현 가능한 정보를 기록한 뒤 추가 점검

유용한 점검 기록에는 Wi-Fi와 셀룰러 네트워크 중 사용한 연결, 현재 Global Routing, 가져오기와 실제 접속 중 어느 단계에서 실패했는지, 모든 서버에서 같은 문제인지, 최근 변경한 항목이 무엇인지가 포함됩니다. 기록을 공유하기 전에 구독 인증 정보, 비밀번호 및 개인을 식별할 수 있는 정보를 가리세요. 오류 안내에 관한 추가 설명은 문제 해결 가이드에서 확인할 수 있습니다. 여러 구독을 정리하고 업데이트와 백업을 관리하려면 구독 가이드를 참조하세요.

이 다섯 단계를 마치면 현재 어떤 서버가 선택되어 있는지, 어떤 모드를 사용하는지, 시스템 연결이 설정되었는지, 실제 요청이 예상한 대로 처리되는지 설명할 수 있어야 합니다. 이후 구성을 수정하거나 구독을 업데이트할 때도 같은 순서로 다시 확인하세요. 여러 설정을 한꺼번에 바꾸기보다 정상 작동을 확인한 구성을 먼저 저장하면 안정적인 기준 상태를 유지하기 쉽습니다.