Data는 클라이언트가 기록한 트래픽을 보여 주며, 서비스 제공업체의 요금제 사용량과는 다릅니다. 먼저 누적 사용량과 실시간 속도를 구분한 다음 서버별로 트래픽이 어느 출구를 거쳤는지, 앱별로 어떤 앱에서 발생했는지 확인하세요. 마지막으로 같은 시간대의 증가량과 연결 기록을 대조하면 규칙에 따른 분기를 점검할 수 있습니다. 구독을 가져온 뒤 통계 차이를 확인하거나 분기 결과를 점검하려는 사용자를 위한 안내입니다. 플랫폼마다 앱별 정보와 초기화 메뉴가 다를 수 있으므로 현재 화면을 기준으로 확인하세요.
사용량, 속도, 서비스 제공업체의 트래픽을 구분하세요
Shadowrocket Data에서 수치를 볼 때는 먼저 단위를 확인하세요. B, KB, MB, GB는 누적 데이터 사용량이고, B/s, KB/s, MB/s는 시간당 전송 속도입니다. 다운로드를 멈춘 뒤 속도는 낮아지고 누적 사용량은 그대로 남는 것이 정상입니다. 누적 20 MB를 현재 다운로드 속도로 오해하지 마세요.
Upload는 기기에서 외부로 보내는 데이터이고, Download는 기기가 받는 데이터입니다. 웹페이지를 열 때도 요청, 로그인 상태, 응답 확인 메시지를 보내므로 Upload가 발생합니다. 파일을 업로드할 때도 서버에서 응답을 받으므로 Download가 생깁니다. 화면에 Total이 표시된다면 먼저 해당 행의 송수신 합계인지, 현재 보기의 전체 합계인지 확인하세요. 상위 항목과 하위 항목을 중복해서 더하지 않도록 주의해야 합니다.
서비스 제공업체의 통계는 다른 지점에서 집계되며, 결제 주기와 배율, 프로토콜 오버헤드 산정 방식도 다를 수 있습니다. 클라이언트, 시스템의 셀룰러 데이터 사용량, 서비스 제공업체의 대시보드는 같은 기준으로 측정한 값이 아닙니다. 구독에 표시되는 잔여 데이터가 서비스 제공업체에서 전달된 정보라면 Data의 로컬 통계가 이어진 것으로 볼 수도 없습니다. 구독 링크는 이용 중인 서비스 제공업체에서 받으세요. 요금제 잔액과 결제 주기도 서비스 제공업체에 확인해야 합니다.
예를 들어 파일 크기가 100 MB라고 해서 Data, 시스템 설정, 서비스 제공업체 대시보드의 사용량이 모두 정확히 100 MB씩 늘어나는 것은 아닙니다. 프로토콜 오버헤드, 캐시, 재시도, 집계 범위가 결과에 영향을 줍니다. MB와 MiB의 환산 기준도 다를 수 있습니다. 먼저 시간 범위와 단위를 통일한 뒤 차이를 비교하세요.
서버별 수치: 실제로 데이터를 전달한 출구 확인하기
서버별 보기에서는 테스트 중 특정 서버 항목의 사용량이 얼마나 늘었는지 확인하세요. 과거 누적량 순위는 핵심 기준이 아닙니다. Home에서 현재 선택한 서버와 이미 연결된 세션이 사용하는 서버는 바로 바뀌지 않을 수 있습니다. 기존 연결을 재사용하거나 다운로드가 끝나지 않았다면 이전 서버 연결을 계속 사용할 수 있으므로 서버를 바꾼 뒤에는 새 요청을 보내 확인하세요.
| 확인 항목 | 의미 | 확인 방법 |
|---|---|---|
| 서버 이름 | 클라이언트가 트래픽을 기록할 때 연결한 서버 항목 | Home으로 돌아가 항목을 대조하고, 이름이 비슷하다는 이유만으로 판단하지 마세요 |
| Upload / Download | 해당 항목의 방향별 누적 사용량 또는 속도. 단위에 따라 다릅니다 | 시작값과 종료값을 기록하고 과거 누적량끼리 직접 비교하지 마세요 |
| Direct | 보기에 해당 항목이 있으면 기록된 Direct 트래픽을 나타냅니다 | Global Routing과 연결 기록을 함께 확인해 트래픽의 출처를 파악하세요 |
| 항목의 수치가 늘지 않음 | 테스트 트래픽이 해당 출구를 지나지 않았거나 새 연결이 생성되지 않았을 수 있습니다 | 캐시, 연결 재사용, 통계 갱신 여부와 실제로 적용된 정책을 확인하세요 |
서버 목록이 모든 네트워크 활동을 빠짐없이 보여 주는 것은 아닙니다. Direct 트래픽이 별도로 표시되는지, 과거 항목이 남는지는 현재 화면과 집계 범위에 따라 다릅니다. 선택한 서버의 사용량이 늘지 않았다고 해서 기기가 인터넷에 연결되지 않았다고 단정할 수는 없습니다. 요청이 Direct를 사용했거나 다른 정책에서 선택한 서버를 거쳤거나, 현재 통계 범위에 포함되지 않았을 수 있습니다.
- Home에서 현재 서버를 확인한 뒤 Data에서 해당 서버의 Upload와 Download 시작값을 기록합니다.
- 다른 대용량 작업을 잠시 멈추고 앱 하나에서 새 네트워크 요청을 한 번 실행합니다.
- 요청이 끝날 때까지 기다린 뒤 Data로 돌아가 같은 단위로 종료값을 기록합니다.
- 종료값에서 시작값을 빼 증가량을 구하고, 같은 시간대의 연결 기록과 대조합니다.
앱별 수치: 발생한 앱을 확인하고, 항목이 없다고 사용량이 0이라고 단정하지 마세요
앱별 보기에서는 “트래픽이 어디에서 발생했는지”를, 서버별 보기에서는 “어느 출구를 거쳤는지”를 확인합니다. 두 기준은 같은 데이터를 서로 다른 방식으로 분류할 수 있으므로 합산해 기기 전체 사용량을 구하면 안 됩니다. 한 앱이 여러 도메인에 접속해 각각 Direct와 프록시 정책을 따를 수 있고, 하나의 서버가 여러 앱의 연결을 동시에 처리할 수도 있습니다.
앱별 트래픽을 얼마나 확인할 수 있는지는 플랫폼 권한과 트래픽 처리 방식에 따라 달라집니다. 특히 iPhone / iPad에서는 시스템이 클라이언트에 앱별 정보를 모두 제공한다고 가정하면 안 됩니다. 현재 화면에 앱별 메뉴가 없거나 일부 연결의 앱을 확인할 수 없다면 서버별 증가량과 연결 기록을 이용해 점검하세요. 현재 화면에 없는 설정을 찾을 필요는 없습니다.
- 브라우저가 접속하는 곳은 하나의 도메인만이 아닙니다: 한 페이지가 이미지, 글꼴, 미디어, API를 함께 요청할 수 있으므로 앱 전체 사용량만으로 모든 요청이 같은 규칙을 따랐다고 볼 수 없습니다.
- 백그라운드로 전환해도 작업이 멈추는 것은 아닙니다: 동기화, 알림 관련 연결, 백그라운드 전송으로 데이터가 계속 발생할 수 있습니다. 테스트 중에는 다른 작업을 최대한 줄이세요.
- 화면에 0으로 표시되어도 접속이 없었다고 단정할 수 없습니다: 캐시 적중, 갱신 지연, 앱 정보 표시 제한으로 이번 측정에서 증가량이 보이지 않을 수 있습니다.
- 앱별 사용량과 서버별 사용량이 항목별로 일치하지 않을 수 있습니다: 분류 범위가 다를 수 있으므로 먼저 같은 시간대를 기준으로 비교하고, 구체적인 연결 기록을 확인하세요.
통계는 언제 초기화될까요? 먼저 집계 범위를 확인하세요
“연결을 끊으면 0으로 돌아가나요?”라는 질문은 어떤 카운터인지 확인하지 않고는 답할 수 없습니다. 현재 연결의 지속 시간이나 순간 속도는 Data에 저장된 누적 사용량과 다른 항목입니다. 연결을 끊으면 현재 세션은 종료되지만 과거 통계까지 모두 삭제되는 것은 아닙니다. Home으로 돌아가거나 Global Routing을 바꾸거나 구독을 갱신하는 동작도 통계를 일괄 초기화하는 방법으로 간주하면 안 됩니다.
| 동작 또는 시점 | 해석 방법 | 기록할 내용 |
|---|---|---|
| 연결 스위치 끄기 | 현재 세션은 종료되지만 누적 사용량이 함께 초기화된다고 보장할 수는 없습니다 | 연결을 끊기 전후에 같은 항목을 기록하세요 |
| 앱을 종료한 뒤 다시 열기 | 화면이 다시 로드되어도 저장된 통계가 삭제된 것은 아닙니다 | 다시 열기 전후의 수치와 집계 범위를 비교하세요 |
| 자정 또는 요금제 정산일 지나기 | 주기에 대한 명확한 안내가 없다면 로컬 통계가 자동으로 초기화된다고 가정하면 안 됩니다 | 화면에 날짜 범위가 표시되어 있는지 확인하세요 |
| 통계 삭제 작업 실행 | 현재 화면의 확인 안내를 따르세요. 지정된 범위에만 영향을 줄 수 있습니다 | 필요한 수치를 먼저 기록한 뒤 삭제 결과를 확인하세요 |
새로 집계하려면 먼저 Data에서 현재 플랫폼에 통계 삭제 또는 초기화 기능이 있는지 확인하세요. 확인 안내를 읽은 뒤 실행해야 합니다. 다른 플랫폼의 버튼 위치를 그대로 적용하거나 통계를 초기화하려고 서버, 구독, 앱 데이터를 삭제하지 마세요. 초기화 메뉴가 명확하지 않더라도 시작값과 종료값의 차이를 계산하면 신뢰할 수 있는 테스트 구간을 확인할 수 있습니다.
요약: 통계 초기화보다 증가량을 비교하세요
테스트할 때마다 시작 시각, 종료 시각, 서버 이름, 두 방향의 수치를 기록하세요. 과거 통계가 남아 있어도 이번 테스트에서 발생한 데이터만 분리할 수 있습니다. 초기화는 비교 기준을 바꿀 뿐, 서비스 제공업체의 청구 내역이나 요금제 잔액을 초기화하지 않습니다.
Data로 Config 규칙 확인하기: 조건을 고정한 뒤 매칭 결과를 점검하세요
Config 파일의 규칙을 점검하려면 Home → Global Routing에서 Config를 선택하고, Config에서 사용 중인 설정 파일을 확인하세요. Proxy와 Direct는 임시 비교에 쓸 수 있지만, 이 결과만으로 설정 파일의 규칙이 매칭되었다고 판단할 수는 없습니다. Scene을 사용한다면 현재 Scene에 실제로 적용된 라우팅 설정을 먼저 확인하세요. Scene 전환으로 달라진 결과를 규칙 오류로 오인하지 않도록 주의해야 합니다.
테스트 전 상태 기록
- Global Routing
- Config
- 설정 파일
- Config에서 선택된 파일 확인
- 서버
- Home에서 현재 선택된 서버 기록
- 자동 연결
- Settings → On Demand
On Demand 조건이 연결 상태를 바꾸는지 확인하고, 테스트 내내 네트워크 환경을 동일하게 유지하세요.
규칙 구문 예시
- DOMAIN-SUFFIX
- example.com,PROXY
- IP-CIDR
- 192.0.2.0/24,DIRECT,no-resolve
- GEOIP
- CN,DIRECT
- FINAL
- PROXY
예시 도메인과 네트워크 대역은 구문 설명용이며 실제 연결 테스트 대상이 아닙니다. FINAL은 마지막에 둡니다.
아래는 규칙 순서를 설명하기 위한 예시입니다. DOMAIN-SUFFIX는 지정한 도메인과 하위 도메인을 매칭합니다. IP-CIDR은 대상 IP 대역을 매칭하며, 예시의 no-resolve는 해당 규칙을 매칭하기 위해 별도로 도메인 조회를 하지 않는다는 뜻입니다. GEOIP는 대상 IP를 지리 데이터베이스 기준으로 분류하고, FINAL은 앞선 규칙에 매칭되지 않은 요청을 처리합니다. 규칙은 위에서 아래로 적용되므로 앞쪽 규칙이 최종 결과를 바꿀 수 있습니다.
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY
실제로 테스트할 때는 현재 규칙의 적용 대상이며 접속 가능한지 알고 있는 주소를 사용하세요. 예시를 일상적으로 사용하는 설정에 그대로 붙여 넣을 필요는 없습니다. 먼저 Data의 시작값을 기록한 뒤 대상을 열고 연결 기록에서 대상 도메인 또는 IP, 매칭된 규칙, 최종 정책을 확인합니다. HTTPS는 보통 대상 포트 443을 사용하지만 포트만으로 프록시 사용 여부를 판단할 수는 없습니다. 실제 매칭 결과와 아웃바운드를 기준으로 확인하세요.
- 기준값 기록: 연결이 켜져 있는지 확인하고 백그라운드 다운로드를 멈춘 뒤 서버와 앱별 수치를 기록합니다.
- 새 요청 실행: 캐시만으로 표시되는 페이지를 새로고침하는 데 그치지 마세요. 테스트 대상을 바꾸더라도 대상에 적용되는 정책은 동일하게 유지합니다.
- 연결 확인: 먼저 해당 시각과 대상을 찾고 규칙과 아웃바운드를 확인하세요. 서버의 전체 사용량만 보지 마세요.
- 증가량 확인: 통계가 갱신될 때까지 기다린 뒤 차이를 계산하세요. 결과가 예상과 다르면 먼저 규칙 순서와 기존 연결 재사용 여부를 확인합니다.
- 설정 복원: 비교를 위해 Proxy 또는 Direct로 잠시 전환했다면 테스트가 끝난 뒤 원래 Config 설정으로 되돌립니다.
요약: 트래픽 증가는 참고 정보, 연결 매칭 결과는 원인 파악의 기준
특정 서버의 Download가 12 MB에서 17 MB로 늘었다면 해당 항목이 약 5 MB 증가했다는 의미일 뿐입니다. 이것만으로 특정 도메인이 DOMAIN-SUFFIX에 매칭되었다고 확인할 수는 없습니다. 먼저 해당 연결을 특정한 다음 Data의 증가량으로 실제 데이터가 계속 전송되었는지 확인하세요.
자주 묻는 통계 질문과 해결 방법
다운로드를 하지 않는데 Upload가 계속 늘어나는 이유는 무엇인가요?
먼저 클라우드 동기화, 파일 업로드, 기타 백그라운드 작업을 멈추고 1분 동안 변화를 기록한 뒤 해당 시간대의 연결을 확인하세요. 웹 요청, 연결 유지 통신, 응답 확인 메시지도 Upload를 발생시킵니다. 업로드 수치가 늘었다는 사실만으로 파일이 업로드 중이라고 판단할 수 없습니다.
서버를 바꿨는데 이전 서버의 트래픽이 계속 늘어나는 이유는 무엇인가요?
먼저 기존 다운로드가 끝날 때까지 기다린 뒤 새 연결을 만들어 아웃바운드를 확인하세요. 이전 연결이 계속 데이터를 전송하고 있거나 정책에서 다른 서버를 선택했을 수 있습니다. 확인을 위해 이전 항목을 삭제하지 말고 연결 시각과 대상을 기준으로 요청을 구분하세요.
앱별 통계에서 방금 연 앱을 찾을 수 없다면 어떻게 해야 하나요?
먼저 현재 플랫폼에서 앱별 정보를 제공하는지 확인한 뒤 캐시된 수치만 보고 있는 것은 아닌지 살펴보세요. 새 요청을 실행해 서버별 증가량과 연결 기록을 대조합니다. 앱을 확인할 수 없는 트래픽은 알 수 없음으로 두고 특정 앱의 사용량이라고 추측하지 마세요.
Data와 서비스 제공업체 대시보드의 수치 차이가 큰데 규칙을 바꿔야 하나요?
먼저 시작 시각, 종료 시각, 단위를 통일하고 서비스 제공업체에 정산 주기와 과금 기준을 확인하세요. 규칙은 요청의 라우팅 방식을 결정할 뿐 두 통계의 수치를 일치시키지는 않습니다. 연결 기록의 아웃바운드가 예상과 다를 때만 Config를 추가로 확인하세요.
Data 수치는 늘어나는데 웹페이지가 열리지 않는 이유는 무엇인가요?
증가분은 다른 앱의 트래픽, 실패 전 핸드셰이크, 재시도 요청에서 발생했을 수 있습니다. 먼저 대상 연결이 성공했는지 확인한 뒤 DNS, 규칙 매칭, 아웃바운드 상태를 점검하세요. 원인을 더 찾아야 한다면 문제 해결 절차에 따라 하나씩 확인하고, 전체 트래픽 증가만으로 연결 성공 여부를 판단하지 마세요.
문제 해결 기록에는 기기 플랫폼, Global Routing, 설정 파일, 서버 이름, 테스트 대상, 시간 범위를 적어 두면 됩니다. 기록을 다른 사람에게 전달하기 전에는 구독 링크, 인증 정보, 개인적인 접속 내용을 가리세요. 연결 또는 구독 가져오기를 추가로 점검하려면 문제 해결과 빠른 시작을 각각 확인하세요.