Shadowrocket의 Data 페이지를 열고 먼저 통계 대상, 누적 트래픽, 실시간 속도를 구분하세요. 같은 시간 구간의 시작값과 종료값을 비교하면 연결 상태를 확인할 수 있습니다. 이미 이용 중인 서비스 제공업체와 구독이 있고 서버 사용량을 확인하거나 규칙에 따른 라우팅 결과를 점검하려는 사용자를 위해, 서버별·앱별 통계의 범위와 초기화 전 기록 방법, Data와 연결 기록을 교차 확인하는 방법을 설명합니다.
1. Data 페이지와 수치 읽기: 누적량과 속도를 구분하세요
Shadowrocket 메인 화면에서 Data를 열고 현재 표시되는 통계 항목을 확인하세요. 서버별 보기에서는 해당 서버의 전송·수신·합계 수치를 살펴봅니다. 앱별 보기에서는 목록이 실제로 앱 기준으로 분류된 것인지 확인하고, 대상 도메인이나 연결 이름을 앱 이름으로 간주하지 마세요. 기기와 화면에 따라 제공되는 분류가 다를 수 있으므로, 앱별 통계에 관한 설명은 해당 항목이 실제로 표시되는 경우에만 적용됩니다.
누적 트래픽은 “이 통계 구간에 데이터가 얼마나 전송됐는지”를 나타내며, 보통 KB, MB, GB 등으로 표시됩니다. 초당 단위가 붙은 수치는 “현재 전송 속도가 얼마인지”를 나타냅니다. 두 수치는 직접 비교할 수 없습니다. 앱이 백그라운드로 전환된 뒤 속도가 0으로 표시될 수 있지만, 이미 누적된 바이트 수까지 사라졌다고 해석해서는 안 됩니다.
- 전송: 일반적으로 기기에서 외부로 보내는 데이터를 뜻합니다. 요청, 업로드한 콘텐츠와 관련 통신 데이터가 포함되며, 업로드 파일 크기와 같지는 않습니다.
- 수신: 일반적으로 기기가 받은 데이터를 뜻합니다. 웹 리소스, 미디어 조각, 응답 내용 등이 포함됩니다.
- 합계: 먼저 화면의 항목 정의를 확인하세요. 합계를 전송 및 수신 수치에 다시 더하면 중복 계산됩니다.
2. 서버별 통계: 실제로 트래픽을 발생시킨 연결 확인
서버별 보기는 “현재 테스트가 예상한 서버를 거쳤는가?”를 확인할 때 유용합니다. 서비스 제공업체의 잔여 데이터 확인 화면도, 휴대전화 전체 네트워크 사용량의 합계도 아닙니다. 서버 이름은 항목을 식별하기 위한 기준일 뿐입니다. 이름이 같더라도 구독을 업데이트한 뒤 새로 생성된 항목은 통계상 완전히 동일한 항목이 아닐 수 있습니다. 비교하기 전에 서버 주소, 포트, 소속 그룹을 함께 확인하세요.
Home에서 특정 서버를 선택했다고 해서 모든 연결이 반드시 그 서버를 거치는 것은 아닙니다. Global Routing이 Config로 설정되어 있으면 현재 구성의 규칙과 정책에 따라 연결이 처리됩니다. 규칙이 다른 정책을 선택하거나 DIRECT를 사용할 수 있습니다. 따라서 선택한 서버의 수치가 늘지 않는다면 통계 오류라고 단정하기 전에 대상 연결의 실제 아웃바운드를 확인하세요.
| 관찰된 현상 | 가능한 원인 | 다음 확인 사항 |
|---|---|---|
| 선택한 서버의 트래픽이 늘지 않음 | 연결이 DIRECT를 사용하거나 다른 정책을 따름, 또는 요청이 캐시됨 | 해당 대상 연결의 규칙과 아웃바운드 기록 확인 |
| 다른 서버의 트래픽은 계속 증가함 | 정책이 해당 서버를 선택했거나 기존 장시간 연결이 유지 중임 | 기존 테스트 연결을 종료하고 새 연결로 확인 |
| 수신량이 전송량보다 훨씬 많음 | 웹 탐색, 다운로드, 콘텐츠 재생은 주로 수신 데이터를 발생시킴 | 고정된 시간 구간의 증가량을 비교하고, 이 수치만으로 이상 여부를 판단하지 않음 |
| 직접 웹을 탐색하지 않아도 소량의 트래픽이 증가함 | 백그라운드 앱, 동기화, 연결 유지 또는 점검 기능이 통신 중일 수 있음 | 먼저 유휴 상태의 기준값을 기록한 뒤 작업 하나만 따로 테스트 |
결론: 새로 발생한 트래픽으로 서버를 확인하고, 과거 누적량으로 현재 선택을 판단하지 마세요
대상 서버의 전송 및 수신 값을 먼저 기록한 다음 새 요청을 한 번 보내세요. 테스트 구간 동안의 변화만 해당 요청의 아웃바운드 기록과 비교할 수 있습니다.
3. 앱별 통계: 앱 분류는 기기 전체의 사용량 청구서가 아닙니다
앱별 보기는 식별된 앱의 트래픽 분포를 확인하는 데 사용할 수 있지만, 시스템 수준의 앱별 사용량 목록으로 간주해서는 안 됩니다. 앱 분류는 클라이언트와 시스템이 제공하는 정보의 범위에 따라 달라집니다. 일부 연결은 앱 이름을 명확히 확인할 수 없어 미확인 항목으로 표시될 수 있습니다. 특정 앱 이름이 보이지 않는다고 해서 해당 앱이 네트워크를 사용하지 않았다는 뜻은 아닙니다.
앱 하나가 로그인, 이미지, 동영상, 통계 등 여러 도메인에 동시에 연결할 수 있으며, 그중 일부는 프록시를 거치고 나머지는 DIRECT를 사용할 수 있습니다. 반대로 하나의 도메인을 여러 앱이 이용할 수도 있습니다. 따라서 도메인 목록, 앱별 목록, 서버별 목록은 서로 다른 기준이며, 도메인 기록 하나만으로 앱 전체의 아웃바운드를 판단할 수 없습니다.
- 테스트에 사용하지 않는 전면 앱을 닫고, 눈에 띄는 백그라운드 다운로드를 중지한 다음 테스트 시작 시간을 기록하세요.
- 대상 앱 하나만 열고 콘텐츠 새로고침처럼 명확한 작업을 한 번 수행하세요. 미디어 재생이나 사진 동기화 등을 동시에 하지 마세요.
- Data로 돌아가 해당 앱 또는 미확인 항목에 트래픽이 새로 발생했는지 확인한 다음 서버별 증가량과 비교하세요.
- 화면에 앱별 보기 항목이 없다면 연결 기록의 대상 주소, 시간, 아웃바운드를 기준으로 확인하세요. 도메인 이름을 앱 분류인 것처럼 사용하지 마세요.
4. 통계 기간과 초기화: 기준값을 저장한 뒤 초기화하세요
Data가 매달 자동으로 초기화된다고 가정하거나 VPN에 한 번 연결한 시점을 모든 통계의 시작점으로 간주하지 마세요. 화면에 세션, 날짜 범위, 누적 기간이 표시되어 있다면 해당 표기를 기준으로 삼으세요. 시작 시점이 명확하지 않다면 지금부터 추적 가능한 기준값을 기록하세요. 연결 해제, 앱 종료, 구독 업데이트는 신뢰할 수 있는 초기화 방법이 아닙니다.
초기화하려면 Data 페이지에서 Reset 또는 해당 통계 초기화 기능을 찾으세요. 페이지 작업 메뉴에 기능이 있다면 메뉴를 연 뒤 확인 메시지에서 적용 범위를 살펴보세요. 화면에 초기화 기능이 없다면 구성을 삭제하거나 앱을 다시 설치할 필요 없이, 초기화 전후의 수치를 빼서 이번 테스트 결과를 계산하면 됩니다. 서버 삭제, 연결 기록 삭제, 통계 초기화를 같은 작업으로 혼동하지 마세요.
- 이전 수치 저장: 날짜와 시간, 분류, 서버 식별 정보, 전송 및 수신 수치를 기록하세요. 기록을 보관해야 한다면 먼저 로컬에 저장하세요.
- 테스트 트래픽 중지: 다운로드나 재생을 멈추세요. Settings → On Demand의 트리거 조건을 확인해 예상치 못한 자동 연결이 측정을 방해하지 않도록 하세요. 테스트가 끝나면 원래 설정으로 되돌리세요.
- 초기화 범위 확인: 확인 메시지를 읽고 현재 분류, 단일 항목, 전체 통계 중 어디에 적용되는지 구분하세요. 실제 메시지에 안내된 범위만 실행하고 모든 분류가 함께 초기화된다고 가정하지 마세요.
- 즉시 다시 확인: 같은 분류로 돌아가 결과를 확인하고 새로운 시작값을 기록하세요. 초기화 직후 소량의 수치가 보이면 반복해서 초기화하지 말고 먼저 백그라운드 통신을 확인하세요.
테스트 구간: 시작 수치부터 종료 수치까지
전송 증가량 = 종료 전송 수치 - 시작 전송 수치
수신 증가량 = 종료 수신 수치 - 시작 수신 수치
총 증가량 = 전송 증가량 + 수신 증가량계산하기 전에 단위를 통일하세요. 다음은 계산 예시일 뿐 실제 측정 결과가 아닙니다. 시작 수신량이 120 MB이고 종료 수신량이 128 MB라면 해당 구간의 수신 증가량은 8 MB입니다. 중간에 통계를 초기화했거나 항목이 교체되어 수치가 줄었다면 이 값을 그대로 빼면 안 됩니다. 기준값을 다시 기록하세요.
5. Data로 규칙 기반 라우팅 확인: 규칙 기록과 트래픽 증가량을 함께 대조
트래픽 증가는 데이터가 전송되었다는 사실만 보여 줄 뿐, 어떤 규칙이 적용됐는지는 단독으로 증명하지 못합니다. 제대로 확인하려면 Global Routing, 현재 구성, 대상 연결에 적용된 규칙, 실제 아웃바운드를 모두 확인해야 합니다. Global Routing의 Proxy, Direct, Config, Scene은 통계 분류가 아닙니다. 구성 규칙을 확인할 때는 Config를 선택하고, Scene을 사용하는 경우에는 해당 장면의 실제 설정을 먼저 확인하세요.
- Home → Global Routing으로 이동해 Config를 선택하세요. 그런 다음 Config에서 현재 사용 중인 구성 파일을 확인합니다. 활성화되지 않은 파일만 수정한 것은 아닌지 주의하세요.
- Data에서 예상 서버의 현재 수치를 기록하고 대상 앱의 기존 테스트 연결을 종료하세요. 규칙 변경 결과를 명확히 확인하려면 보통 새 연결이 필요합니다.
- 확인할 대상을 하나 정해 요청을 보낸 뒤 연결 기록에서 대상 도메인이나 IP, 일치한 규칙, 실제 아웃바운드를 확인하세요. 연결 기록의 위치는 현재 화면을 기준으로 찾으세요.
- Data로 돌아와 같은 서버의 증가량을 비교하세요. 다른 서버의 트래픽도 함께 확인하고 백그라운드 트래픽을 제외하세요.
- 비교 테스트를 하려면 한 번에 조건 하나만 바꾸세요. 예를 들어 대상 규칙만 변경하고 서버, 네트워크, DNS 설정을 동시에 바꾸지 마세요.
아래는 규칙 구조의 예시로, 예약된 예시 도메인을 사용하며 실제로 이용할 수 있는 서비스를 뜻하지 않습니다. 현재 구성에 PROXY라는 이름의 사용 가능한 정책이 실제로 있는 경우에만 이 정책 이름을 참조할 수 있습니다. 기존 구성에서 다른 정책 이름을 사용한다면 이름을 그대로 유지하세요. 통계 테스트를 위해 구성 전체를 덮어쓰지 마세요.
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT이 예시에서는 example.com과 그 하위 도메인에 일치하는 연결을 PROXY로 보내고, 나머지 연결은 FINAL을 통해 DIRECT로 보냅니다. 실제 구성에서는 DOMAIN-SUFFIX, GEOIP, IP-CIDR 등의 규칙이 순서대로 적용됩니다. 앞에서 일치한 규칙이 있으면 뒤의 규칙은 실행되지 않을 수 있습니다. 파일에 특정 키워드가 있는지만 확인하지 말고 실제 연결 기록을 살펴보세요.
결론: 규칙 일치 여부, 실제 아웃바운드, 통계 증가량을 함께 확인하세요
아웃바운드 기록은 예상과 일치하는데 서버 증가량이 뚜렷하지 않다면 테스트 시간을 늘리고 캐시를 제외하세요. 아웃바운드가 예상과 다르다면 규칙이나 정책 선택을 먼저 수정하세요. 통계를 초기화해 구성 문제를 덮어서는 안 됩니다.
6. Data와 서비스 제공업체의 사용량은 다릅니다: 기준을 맞춘 뒤 비교하세요
서비스 제공업체의 청구 데이터는 과금 기간, 송수신량 계산 방식, 배수, 갱신 주기가 다를 수 있습니다. Data는 클라이언트에서 집계할 수 있는 로컬 데이터를 보여 줍니다. 프로토콜 오버헤드, 통계가 집계되는 위치, 단위 변환 때문에 차이가 생길 수도 있습니다. 양쪽에 GB라고 표시되어 있어도 바이트 환산 방식과 과금 기준이 완전히 같다고 볼 수 없습니다.
- 시간 기준 맞추기: 같은 시작 시간과 종료 시간을 사용해 비교하세요. Data의 과거 누적량에서 서비스 제공업체의 이번 달 사용량을 바로 빼지 마세요.
- 기기 범위 맞추기: 서비스 제공업체 계정은 다른 기기의 사용량까지 합산할 수 있지만, 현재 기기의 Data에는 해당 트래픽이 표시되지 않습니다.
- 방향 기준 맞추기: 서비스 제공업체가 수신량, 전송량, 또는 둘의 합계를 계산하는지와 명시된 과금 배수가 있는지 확인하세요.
- 갱신 시점 맞추기: 로컬 수치가 늘어난 뒤에도 서비스 제공업체 페이지의 사용량은 아직 반영되지 않았을 수 있습니다. 안내된 갱신 주기가 지난 뒤 비교하세요.
구독 항목 옆에 표시되는 요금제 한도나 만료 정보가 기존 서비스 제공업체에서 전달된 것이라면, 이는 서비스 제공업체가 제공하는 데이터이지 Data의 로컬 통계가 아닙니다. 구독을 업데이트해도 Data가 초기화된다고 보장할 수 없고, Data를 초기화해도 서비스 제공업체에 기록된 사용량은 바뀌지 않습니다. 두 정보는 따로 기록하고 각각 판단하세요.
7. 자주 묻는 질문: 0으로 표시되는 수치, 백그라운드 사용량, 초기화 후 변화
웹페이지는 열리는데 서버 트래픽이 0인 이유는 무엇인가요?
먼저 Home → Global Routing을 확인하세요. Direct를 사용하거나 Config에서 해당 대상이 DIRECT 규칙과 일치하면 선택한 프록시 서버의 증가량이 없는 것이 정상일 수 있습니다. 페이지가 캐시를 사용하는지도 확인하고 새 요청 하나의 연결 기록을 살펴보세요. 확인 대신 서버를 반복해서 전환하지 마세요.
서버를 바꿨는데 이전 서버의 트래픽이 계속 증가하는 이유는 무엇인가요?
재생, 다운로드, 지속적인 동기화를 진행 중인 연결을 먼저 종료한 뒤 테스트를 다시 시작하세요. 기존의 장시간 연결은 원래 아웃바운드를 계속 사용할 수 있고, Config의 정책이 이전 서버를 계속 선택할 수도 있습니다. 연결 시각과 실제 아웃바운드를 비교해 원인을 확인한 뒤 새로운 통계 구간의 수치를 비교하세요.
앱별 목록에서 이름을 찾을 수 없을 때 도메인으로 앱을 판단해도 되나요?
그렇게 단정할 수 없습니다. 대상 앱만 실행하고 짧은 시간 동안 새 연결이 생기는지 관찰한 뒤 대상 도메인, 서버 증가량, 확인 가능한 앱 분류를 함께 살펴보세요. 앱을 식별할 수 없다면 미확인으로 남겨 두고, 여러 앱이 공유하는 도메인을 특정 앱에 억지로 연결하지 마세요.
통계를 초기화하면 서비스 제공업체의 잔여 데이터도 복구되나요?
아니요. 통계 초기화는 로컬에서 관찰을 시작할 기준점을 만드는 기능이며, 기존 서비스 제공업체의 과금 기록을 변경하지 않습니다. 요금제 잔여량을 확인하려면 서비스 제공업체의 계정 정보를 확인하고 기간, 기기 범위, 갱신 시점을 먼저 확인하세요.
웹 탐색을 멈춘 뒤에도 수치가 늘어나는데 On Demand를 계속 꺼 두어야 하나요?
그럴 필요는 없습니다. 먼저 Settings → On Demand의 트리거 조건을 확인한 다음 백그라운드 동기화와 지속 연결을 살펴보세요. 테스트를 위해 설정을 임시로 변경했다면 끝난 뒤 원래대로 복원하세요. On Demand는 연결이 시작되는 조건을 제어하는 기능이지 모든 앱의 네트워크 연결을 중지하거나 통계를 초기화하는 기능이 아닙니다.