첫 연결 시에는 서버 선택, VPN 연결 설정, 테스트 및 실제 접속 상태를 차례로 확인해야 합니다. Shadowrocket에 직접 보유한 서버 정보나 구독을 이미 가져온 사용자를 위해 Home에서 연결하는 순서를 설명하고, ‘목록에 서버가 있음’, ‘스위치가 켜짐’, ‘요청이 실제로 정상 처리됨’을 각각 구분해 확인합니다.
1. 가져오기, 선택, 연결 상태 구분하기
서버가 Home 목록에 표시되는 것은 연결 정보가 앱에 저장되었다는 뜻일 뿐, 현재 사용할 기본 서버로 선택되었거나 VPN이 연결되었다는 뜻은 아닙니다. 처음 사용할 때는 항목별로 확인하세요. 서버를 선택하지 않은 채 구독을 반복해서 새로 고치거나, 테스트에 응답이 왔다는 이유만으로 모든 앱에서 접속할 수 있다고 판단하지 않도록 합니다.
이 글은 사용자가 이미 자체 서비스와 구독을 보유하고 있다는 전제에서 설명합니다. 클라이언트 구매와 회선 서비스는 별개이며, Shadowrocket 일회성 구매에는 회선 요금제가 포함되지 않습니다. 보유한 구독은 서버 정보를 제공하고, 앱은 해당 정보에 따라 연결을 설정하고 현재 라우팅 설정을 적용합니다.
Home에서는 서버 선택과 연결을 제어하고, Config에서는 구성 파일을 관리하며, Settings에는 On Demand 같은 앱 설정이 있습니다. 첫 연결은 Home에서 기본적인 확인을 마치세요. 규칙, DNS, 자동 연결 설정을 동시에 변경할 필요는 없습니다.
2. Home에서 기본 서버를 선택하고 스위치 켜기
Home 목록에서 서버가 있는 행을 탭하고 왼쪽에 선택 표시가 나타나는지 확인합니다. 행 끝의 세부 정보 버튼은 보통 정보를 확인하거나 편집하는 기능이며, 해당 서버를 선택하는 동작과는 다릅니다. 서버 이름은 직접 지정할 수 있으므로 현재 선택된 서버인지는 이름에 ‘기본’이 포함되어 있는지가 아니라 선택 표시로 판단하세요.
-
목록 확인
Home을 열고 가져온 구독 그룹이나 서버 항목이 표시되는지 확인합니다. 목록이 비어 있다면 먼저 가져오기 결과를 점검하세요. 구독 URL 자체는 바로 연결할 수 있는 서버 정보가 아닙니다.
-
서버 선택
기존 그룹을 펼친 다음 테스트할 서버 행을 탭하고 왼쪽에 선택 표시가 나타나는지 확인합니다. 서버 이름을 기록해 두고 이후 테스트에서도 같은 항목을 사용하세요.
-
라우팅 확인
Home → Global Routing으로 이동해 현재 선택된 항목을 확인합니다. 신뢰할 수 있는 규칙 구성이 이미 있다면 Config를 사용하세요. 규칙의 영향을 임시로 점검하려면 Proxy로 비교한 뒤 테스트가 끝나면 원래 설정으로 되돌릴 수 있습니다.
-
스위치 켜기
Home으로 돌아가 상단의 연결 스위치를 켭니다. 처음 연결할 때 시스템에서 VPN 구성을 추가하라는 메시지가 표시되면 요청 앱이 Shadowrocket인지 확인한 뒤 Allow를 선택하고, 시스템 안내에 따라 기기 인증을 완료합니다.
-
연결 확인
Home으로 돌아와 연결 상태를 확인합니다. 스위치가 바로 꺼지거나 연결이 계속 설정되지 않는다면 먼저 권한과 연결 오류를 확인하세요. 스위치를 막 켠 순간만으로 연결이 성공했다고 판단하면 안 됩니다.
이미 권한을 허용했다면 이번에는 안내 메시지가 다시 나타나지 않을 수 있으며, 이는 정상입니다. 기기가 관리 정책의 제한을 받는 경우 VPN 구성 추가가 허용되는지 먼저 확인하세요. 문제를 해결하려고 구성을 계속 삭제하며 시험하지 마세요.
3. Global Routing 설정에 따라 테스트 결과가 달라지는지 확인하기
같은 서버라도 Global Routing 설정에 따라 실제 요청이 서로 다른 경로를 사용할 수 있습니다. 특히 Direct에서는 웹페이지가 열려도 서버가 정상 작동한다는 뜻이 아닙니다. Config에서는 웹페이지 요청이 DIRECT 규칙과 일치할 수도 있습니다. 아래 내용은 Shadowrocket의 라우팅 모드별 차이를 비교하며, 권장 항목은 사용 가능한 규칙 구성을 이미 갖추고 일상적으로 사용하는 경우를 전제로 합니다.
Config
권장현재 활성화된 구성의 규칙에 따라 요청을 처리합니다. 규칙은 DIRECT, REJECT 또는 해당 프록시 정책으로 요청을 보낼 수 있습니다. 앞선 규칙과 일치하지 않는 요청은 일반적으로 FINAL이 처리하며, 이를 단순히 ‘나머지는 모두 직접 연결’로 이해해서는 안 됩니다.
적합한 경우: 구성을 확인했고 규칙에 따라 일상적으로 트래픽을 분배하려는 경우.
Proxy
앱이 처리하는 요청을 프록시 모드로 전달합니다. 규칙 기반 분배를 우회해도 문제가 계속되는지 확인할 수 있습니다. 서버 정보 점검을 대신하지 않으며, 특정 네트워크 서비스의 정상 작동을 보장하지도 않습니다.
적합한 경우: 규칙이나 정책 선택의 문제를 좁히기 위해 Config와 임시로 비교하려는 경우.
Direct
요청을 직접 연결 방식으로 처리합니다. 이때 접속 결과는 주로 현재 로컬 네트워크의 직접 연결 상태를 보여주므로, 선택한 프록시 서버의 사용 가능 여부를 확인하는 데 적합하지 않습니다.
적합한 경우: 프록시 경로에서만 문제가 발생하는지 로컬 네트워크와 비교하려는 경우.
Scene
미리 설정한 시나리오 조건에 따라 해당 설정을 적용합니다. 첫 연결 시 아직 시나리오 내용을 확인하지 않았다면, 환경 변화로 테스트 조건이 함께 달라지지 않도록 먼저 명확한 고정 모드로 확인하세요.
적합한 경우: 시나리오를 구성했고 실행 조건과 작동 방식을 이해하는 사용자.
Proxy에서는 접속되지만 Config에서는 실패한다면 Config로 돌아가 현재 사용 중인 구성과 적용된 정책을 확인하세요. 특히 규칙이 요청을 어떤 경로로 보내는지 살펴봅니다. 두 테스트에서 서버 인증 정보가 같을 수 있으므로 곧바로 서버 비밀번호를 변경하지 마세요.
4. Connectivity Test를 실행하고 실제 접속 확인하기
Home에서 Connectivity Test를 찾아 탭한 뒤 테스트가 끝날 때까지 기다리고, 서버 항목 옆에 표시되는 결과를 확인합니다. 테스트는 현재 네트워크에서의 도달 가능성이나 응답 상태를 확인하는 데 유용합니다. 다만 결과는 테스트 방식과 대상에 따라 달라지므로, 표시된 밀리초 값을 웹페이지 전체가 열리는 시간으로 해석해서는 안 됩니다.
VPN 연결이 설정되기 전에도 일부 테스트를 실행할 수 있습니다. 따라서 Connectivity Test 결과와 Home의 연결 스위치가 VPN을 정상적으로 설정했는지는 각각 따로 확인해야 합니다. 여러 서버를 일괄 테스트한 뒤에도 선택 표시를 다시 확인하세요. 테스트가 현재 기본 서버를 자동으로 바꾼다고 가정하면 안 됩니다.
| 확인된 현상 | 판단할 수 있는 내용 | 다음 단계 |
|---|---|---|
| 밀리초 값이 표시됨 | 이번 테스트에서 응답을 받았다는 뜻이며, 모든 요청이 성공한다는 의미는 아닙니다. | 같은 서버를 선택했는지 확인하고 VPN 상태를 점검한 뒤, 실제로 이용할 페이지를 엽니다. |
| 시간 초과 또는 실패 표시 | 현재 테스트 조건에서는 예상한 응답을 받지 못했습니다. | 설정값을 유지한 채 네트워크를 바꿔 다시 테스트하고, 테스트 대상과 서버 연결 상태를 확인합니다. |
| 테스트는 정상이지만 웹페이지가 열리지 않음 | 테스트 경로와 실제 서비스 요청 경로가 다를 수 있습니다. | Global Routing, 규칙 정책, DNS, 서버 인증 정보를 확인합니다. |
| 웹페이지는 열리지만 특정 앱에서 실패 | 특정 도메인이나 프로토콜 또는 앱 자체의 네트워크 상태가 원인일 수 있습니다. | 실패한 요청에 적용된 정책을 확인합니다. 한 앱의 결과만으로 전체 회선 상태를 단정하지 마세요. |
기본 확인 순서
- Home에서 대상 서버 왼쪽의 선택 표시가 유지되는지 확인합니다.
- 연결 상태가 안정적인지 확인한 뒤 Connectivity Test를 실행하고 결과를 기록합니다.
- 프록시 경로를 확인할 수 있는, 정상 작동이 확인된 HTTPS 페이지를 열어 제목만 캐시되어 표시되는 것이 아니라 본문까지 불러오는지 살펴봅니다.
- 실제로 사용할 앱으로도 확인합니다. Config를 사용한다면 요청 기록에서 해당 요청에 적용된 정책을 함께 확인하세요.
일반 HTTPS 웹사이트는 보통 TCP 443을 사용하지만, 프록시 서버의 포트는 기존 서비스 설정에 따라 다르며 두 설정은 서로 다릅니다. 웹사이트가 443을 사용한다고 해서 서버 포트도 443으로 변경해야 하는 것은 아닙니다. Hysteria2처럼 UDP 전송을 사용하는 프로토콜은 네트워크에서 UDP 통신도 허용해야 합니다. 웹페이지 테스트 성공만으로 UDP 경로가 정상이라고 단정할 수 없습니다.
5. 연결에 실패하면 증상에 따라 원인을 좁히고 한 번에 하나씩 변경하기
점검할 때는 ‘같은 서버, 같은 라우팅 모드, 같은 테스트 대상’을 유지하고 한 번에 조건 하나만 바꾸세요. 먼저 연결 스위치가 켜진 상태를 유지하지 못하는지, 아니면 연결은 됐지만 요청이 실패하는지 구분합니다. 두 증상은 점검 순서가 다릅니다.
증상별 점검 순서
연결 스위치가 켜진 상태를 유지하지 못함
- 시스템에서 VPN 구성 권한을 허용했는지 확인합니다.
- Home에 표시된 연결 오류를 확인하고 원래 메시지를 기록해 둡니다.
- 다른 VPN 연결이 사용 중이어서 테스트에 영향을 주는지 확인합니다.
- 서버 주소, 포트, 프로토콜에 필요한 정보를 확인합니다.
연결되지만 요청이 실패함
- 예상한 서버가 선택되어 있는지 확인합니다.
- Global Routing을 확인하고, 필요한 경우 Proxy와 Config를 비교합니다.
- 도메인 확인, 테스트 대상, 실제 페이지를 각각 점검합니다.
- 네트워크를 바꿔 다시 테스트해 로컬 네트워크 문제와 서버 경로 문제를 구분합니다.
변경 전 상태를 먼저 기록한 뒤 한 항목만 수정하세요. 개선되지 않으면 원래대로 되돌려 새로운 변수가 문제에 더해지지 않도록 합니다.
Wi-Fi에서는 시간 초과가 발생하지만 셀룰러 네트워크에서는 정상이라면, 우선 두 네트워크 환경의 결과가 다르다는 점만 알 수 있습니다. 서버가 손상되었다고 바로 단정할 수는 없습니다. 네트워크를 바꾼 뒤 시스템 연결이 안정될 때까지 기다리고, 같은 서버와 테스트 방식으로 다시 확인하세요. 셀룰러 네트워크 테스트는 모바일 데이터를 사용하므로 먼저 데이터 사용 조건을 확인합니다.
구독을 업데이트한 뒤 문제가 생겼다면 이전에 선택한 서버가 여전히 있는지, 주소·포트·인증 정보가 바뀌었는지 확인하세요. 구독 업데이트는 서버 정보를 새로 고치는 작업이지 연결 성공을 보장하는 표시가 아닙니다. 문의할 때 전체 구독 URL, 비밀번호, UUID 또는 기타 인증 정보를 공개하지 마세요. 오류 유형, 네트워크 환경, 이미 수행한 비교 테스트만 기록하면 됩니다.
6. 첫 연결을 확인한 뒤 On Demand 설정하기
Settings → On Demand에서는 필요에 따라 연결 조건을 설정할 수 있습니다. Home에서 연결 스위치를 직접 켜는 것과는 다른 기능입니다. 처음 문제를 점검할 때 자동 연결이 계속 개입하면 ‘수동으로 연결을 끊었는데 왜 다시 연결되는지’ 판단하기 어려울 수 있습니다. 먼저 수동 연결을 확인한 다음, 실제 사용 조건에 맞춰 On Demand를 설정하세요.
- 정상 작동을 확인한 서버와 구성을 유지하고, 정상 작동 시 사용한 Global Routing 모드를 기록해 둡니다.
- Settings → On Demand로 이동해 현재 조건을 먼저 확인한 뒤 사용할지 결정합니다. 이 기능을 켜는 것이 시간 초과 문제를 해결해 준다고 생각하지 마세요.
- 설정을 바꾼 뒤 Wi-Fi와 셀룰러 네트워크 간 전환 시 실제 연결이 어떻게 동작하는지 각각 확인합니다.
- 연결을 중단하려면 Home 스위치와 On Demand 설정을 모두 확인하세요. 한 번 수동으로 연결을 끊어 본 것만으로 판단하지 않도록 합니다.
첫 연결이 완료되었다고 볼 기준은 VPN 아이콘만 표시되는 것이 아닙니다. ‘대상 서버가 선택되어 있고, 시스템 연결이 안정적이며, 테스트 결과를 설명할 수 있고, 실제 요청이 현재 정책에 맞게 처리되는지’를 확인해야 합니다. 이후 문제가 생기면 전체 구성을 다시 가져오기보다 같은 순서로 점검하는 편이 원인을 찾기 쉽습니다. 규칙 매칭과 정책에 관한 자세한 내용은 규칙 매뉴얼을 참고하세요.