Shadowrocket Data 탭 트래픽 통계 보는 법: 서버별·앱별 데이터 읽기

핵심 내용

Shadowrocket의 Data 탭은 클라이언트가 기록한 트래픽을 확인하는 곳으로, 서비스 제공업체의 요금제 사용량 내역과는 다릅니다. 서버 구성이 이미 있다면 먼저 업로드·다운로드와 누적량을 구분하고, 서버별·앱별 활동을 각각 살펴본 뒤, 통제된 접속 전후의 차이로 분할 라우팅을 확인할 수 있습니다. 이 글에서는 집계 시작 시점, 백그라운드 트래픽, 수치가 서로 맞지 않을 때 확인할 순서도 설명합니다.

1. 트래픽 양과 연결 속도 구분하기

Data 탭의 트래픽 수치는 전송된 데이터의 양을 나타냅니다. 업로드는 기기에서 외부로 보내는 데이터이고, 다운로드는 외부에서 기기로 받는 데이터입니다. 웹페이지를 열면 요청을 보내면서 업로드가 발생하고 텍스트·이미지·동영상을 받으면서 다운로드가 발생합니다. 사진을 업로드할 때는 보통 업로드량이 더 두드러집니다. 주로 다운로드하는 상황에서도 연결 설정, 요청, 확인 응답에 데이터가 필요하므로 업로드량이 0이 아닐 수 있습니다.

먼저 수치 옆의 단위를 확인한 다음 값을 살펴보세요. KB, MB, GB는 데이터 양을 나타내며, 초당 단위가 붙어야 속도를 뜻합니다. 누적 다운로드량이 많다는 것은 관찰한 기간 동안 받은 데이터가 많다는 의미일 뿐, 현재 속도를 판단하거나 Connectivity Test 결과를 대신할 수는 없습니다.

2가지 방향

업로드: 기기에서 전송 · 다운로드: 기기로 수신

2가지 관점

서버별 트래픽과 앱별 활동 확인

2회 기록

접속 전후에 각각 기록해 차이 계산

트래픽 통계만으로 접속 성공 여부를 알 수는 없습니다. 요청이 데이터를 전송한 뒤 이름 확인, 핸드셰이크 또는 원격 응답 문제로 실패할 수 있습니다. 반대로 로컬 캐시에서 불러온 페이지는 정상적으로 표시되더라도 새로 발생한 트래픽은 적을 수 있습니다. Data 수치와 실제 접속 결과를 함께 확인하세요.

2. 서버별 통계와 앱별 통계로 알 수 있는 것

서버별 통계에서는 특정 서버 항목이 집계 기간 동안 처리한 트래픽 양을 확인합니다. 앱별 통계에서는 어떤 앱 활동에서 식별 가능한 트래픽이 발생했는지 살펴봅니다. 같은 네트워크 활동을 서로 다른 관점으로 보는 것이므로, 두 수치를 별개의 요금제 사용량처럼 더해서는 안 됩니다.

관찰 관점	확인할 수 있는 내용	이것만으로는 확인할 수 없는 내용
서버별	특정 서버 항목의 누적량 또는 관찰 중 증가량	모든 앱이 해당 서버를 사용했는지 여부
앱별	식별 가능한 앱의 트래픽 분포와 증가 추이	해당 앱의 모든 요청에 같은 정책이 적용됐는지 여부
업로드와 다운로드	송신 데이터와 수신 데이터의 양 차이	실시간 대역폭, 지연 시간 또는 요금제 잔여량

앱별 트래픽을 구분하는 범위는 시스템이 제공하는 정보와 현재 통계 기능에 따라 달라집니다. 어느 앱에 속하는지 명확하지 않은 기록이 있더라도 곧바로 알 수 없는 앱이나 비정상 프로그램이라고 단정하지 마세요. 하나의 앱이 여러 도메인에 접속하거나 직접 연결과 프록시 요청을 함께 사용할 수 있으므로, ‘앱에서 트래픽 발생’과 ‘특정 서버에서 트래픽 발생’은 일대일로 대응하지 않습니다.

요약: 같은 시간대에 두 관점 비교하기

먼저 서버와 대상 앱의 현재 수치를 기록한 다음, 앱 하나만 사용하세요. 같은 시간대의 증가량끼리 비교하고, 서버의 과거 누적량과 앱에서 방금 발생한 소량의 활동을 비교하지 마세요.

3. 집계는 언제 시작되며, 왜 요금제 사용량과 다른가

관련 트래픽이 Shadowrocket을 거쳐 처리되고 기록되어야 통계에 반영됩니다. 앱 설치 시점, 구매 시점, 구독 가져오기 시점이 Data의 현재 수치 집계 시작 시점이라고 볼 수는 없습니다. 모든 항목을 ‘화면을 연 뒤부터의 사용량’으로 해석해서도 안 됩니다. 현재 연결 데이터와 보존되는 누적 기록은 구분해서 확인해야 합니다.

집계 시작 시점을 확인하려면 현재 화면에 기간, 연결 시간 또는 초기화 상태가 명시되어 있는지 먼저 살펴보세요. 시점이 분명하게 표시되지 않았다면 해당 수치를 ‘오늘 사용량’이나 ‘이번 달 사용량’이라고 부르지 마세요. 연결이 끊긴 뒤 특정 수치가 유지되는지는 해당 항목이 실제로 변하는지 확인해야 합니다. 다시 연결할 때마다 모든 기록이 초기화된다고 가정해서는 안 됩니다.

일정 시간 동안의 접속을 측정하려면: 접속 전에 수치와 시간을 기록하고, 접속 후 다시 기록해 직접 비교할 구간을 정하세요.
서버를 전환했다면: 전환 전후 기록을 각각 남기고, 이전 서버의 누적량을 현재 서버에서 이번에 사용한 양으로 보지 마세요.
기록을 삭제하거나 초기화했다면: 작업한 시점을 새로운 비교 기준으로 삼고, 초기화 전 누적량과 바로 비교하지 마세요.
잔여량을 확인하려면: 서비스 제공업체의 사용량 페이지에서 확인하세요. 청구 주기와 차감 기준은 제공업체 안내를 따릅니다.

클라이언트와 서비스 제공업체는 서로 다른 지점에서 트래픽을 집계할 수 있습니다. 프로토콜 오버헤드, 통계 갱신 주기, 트래픽 배수, 청구 주기 등이 최종 수치에 영향을 주므로 두 값이 정확히 일치하지 않을 수 있습니다. 기기의 셀룰러 데이터 통계는 또 다른 기준이며, Shadowrocket이 처리하지 않은 시스템 활동도 포함될 수 있습니다. 집계 범위를 확인하지 않은 채 세 화면의 수치를 서로 대신 사용하지 마세요.

4. 다섯 단계로 다시 확인할 수 있는 트래픽 관찰하기

아래 절차에서는 서버 설정을 변경하거나 구독을 다시 가져올 필요가 없습니다. 이미 보유한 구성을 사용하세요. 아직 구독이 없다면 서비스 제공업체에서 받으세요. 테스트는 Safari에서 캐시되지 않은 페이지를 여는 것처럼 명확한 동작 하나만 선택하세요. 동영상 재생, 앱 업데이트, 대량 사진 동기화 등을 동시에 하면 안 됩니다.

연결 확인

Home으로 이동해 SERVER 목록에서 현재 선택된 서버를 확인하고, 화면 상단의 연결 스위치를 켠 뒤 Connectivity Test를 실행하세요. 테스트 결과는 연결 상태를 파악하는 단서일 뿐이므로 대상 페이지도 직접 열어봐야 합니다.
라우팅 모드 확인

Home → Global Routing으로 이동해 현재 모드가 Config, Proxy, Direct, Scene 중 무엇인지 기록하세요. Config를 사용한다면 Config에서 현재 활성화된 구성도 확인하고, 테스트 도중에는 전환하지 마세요.
기준 수치 기록

Data를 열어 대상 서버와 대상 앱의 업로드·다운로드 수치 및 시간을 각각 기록하세요. 다른 앱의 다운로드는 잠시 중단하고, 백그라운드 동기화가 계속될 수 있다는 점에 유의하세요.
접속 실행

Safari로 돌아가 페이지에 한 번 접속하고 시작 및 종료 시간을 기록하세요. Wi-Fi, 셀룰러 네트워크 또는 서버를 동시에 전환하면 트래픽 귀속 변화를 해석하기 어렵습니다.
증가량 비교

Data로 돌아와 수치가 갱신될 때까지 기다린 뒤 같은 항목을 다시 기록하세요. 나중 수치에서 이전 수치를 빼고 접속 성공 여부, 현재 라우팅 모드, 요청 기록을 함께 살펴보세요.

아래는 차이 계산 예시일 뿐, 실제 측정 결과나 성능 보장이 아닙니다. 단위는 동일하게 맞추세요. 화면 수치가 반올림되어 표시되면 적은 양의 트래픽은 뚜렷한 변화가 없을 수 있습니다. 곧바로 기록 기능이 작동하지 않는다고 판단하기보다 관찰 시간을 늘려 보세요.

항목	접속 전	접속 후	해당 구간 증가량
서버 다운로드	100 MB	120 MB	20 MB
서버 업로드	10 MB	11 MB	1 MB

5. Global Routing으로 분할 라우팅이 예상대로인지 확인하기

Data는 결과를 확인하는 단서를 제공하고, 트래픽 처리 방식은 Global Routing과 현재 구성에 따라 결정됩니다. 서버 수치가 증가했는지 보기 전에 현재 라우팅 모드를 먼저 확인하세요. 특히 Proxy 모드에서 트래픽을 관찰한 결과만으로 Config의 특정 규칙이 적용됐다고 판단하면 안 됩니다.

Config

권장

현재 구성의 규칙에 따라 정책을 선택합니다. 분할 라우팅을 확인할 때는 대상 요청, 일치한 규칙, 최종 정책을 함께 확인하세요. 어떤 규칙에도 일치하지 않은 요청이 반드시 직접 연결된다고 가정해서는 안 됩니다.

적합한 용도: 기존 구성의 분할 라우팅이 예상대로인지 확인

Proxy

처리 대상 트래픽을 프록시 경로로 보내 연결 상태를 비교할 때 적합합니다. 하지만 Config의 특정 DOMAIN-SUFFIX 또는 IP-CIDR 규칙이 유효하다는 증거는 아닙니다.

적합한 용도: 서버 문제와 규칙 문제를 일시적으로 구분

Direct

직접 연결 경로를 사용합니다. 서버의 프록시 트래픽이 증가하지 않는 것은 현재 모드와 일치하는 결과일 수 있으므로, 서버 수치가 0이라는 이유만으로 연결 오류라고 판단하지 마세요.

적합한 용도: 대상이 직접 연결 경로에서 접속되는지 비교

Scene을 사용한다면 현재 Scene에 적용되는 설정과 활성화 조건을 먼저 확인하세요. Scene을 Proxy 또는 Direct와 동일한 고정 경로로 간주하면 안 됩니다. 테스트 전후에 같은 Scene을 유지해야 증가량을 비교할 수 있습니다.

Config에서는 규칙 순서도 중요합니다. DOMAIN-SUFFIX는 도메인 접미사로, GEOIP는 IP 지리 데이터베이스로, IP-CIDR은 주소 대역으로 일치 여부를 판단합니다. 앞선 규칙에 일치하지 않은 요청은 FINAL에서 처리됩니다. 최종 경로는 앱 이름이 아니라 일치한 규칙이 지정한 정책으로 결정됩니다.

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

아래 내용은 규칙 문법을 설명하기 위한 예시입니다. example.com과 하위 도메인은 DIRECT에 일치하고, 나머지 요청은 FINAL을 통해 PROXY로 전달됩니다. 테스트 전에 구성에서 참조한 정책을 지원하는지 확인하세요. 트래픽 관찰을 위해 기존 구성을 그대로 덮어쓰지 마세요. 실제 웹페이지는 다른 도메인의 리소스도 요청할 수 있으므로, 기본 도메인이 직접 연결되더라도 일부 프록시 트래픽이 보일 수 있습니다.

요약: 트래픽 증가는 데이터가 전송됐다는 뜻일 뿐

대상이 예상한 규칙에 일치했는지 확인하려면 한 번의 접속에서 요청 기록의 대상, 일치한 규칙, 최종 정책을 함께 확인하고 Data 증가량을 보조 지표로 활용하세요. 페이지 전체의 총량으로 개별 요청을 판단하지 마세요.

6. 수치가 예상과 다를 때 증상별로 확인하기

설정을 바꾸기 전에 먼저 현재 상황을 기록하세요. 관찰 시간, 네트워크 유형, Global Routing 모드, 접속 대상을 남겨두면 반복해서 다시 연결하는 것보다 원인을 찾기 쉽습니다. 한 번에 조건 하나만 바꾸고, 접속을 한 차례 마친 뒤 Data를 다시 기록해 여러 변경의 영향을 뒤섞지 마세요.

웹페이지는 열리는데 서버 트래픽이 늘지 않는 이유는?

먼저 Home → Global Routing이 Direct인지 확인하고, 이어서 Config에서 대상이 DIRECT에 일치하는지 살펴보세요. 그런 다음 캐시되지 않은 콘텐츠에 다시 접속하고 Data가 갱신될 때까지 기다리세요. 캐시된 콘텐츠, 단위 반올림, 잘못 선택한 서버 항목 때문에 증가량이 잘 보이지 않을 수 있습니다.

아무것도 하지 않았는데 트래픽이 계속 늘어나는 이유는?

먼저 클라우드 동기화, 미디어 재생, 앱 업데이트를 일시 중지한 뒤 앱별 증가량을 살펴보세요. 다음으로 Settings → On Demand가 활성화되어 있는지, 어떤 조건이 설정되어 있는지 확인해 자동으로 연결이 시작될 수 있는 상황인지 점검하세요. Home으로 돌아가 실제 연결 상태를 확인하고, 이전에 스위치를 껐다는 기억만으로 판단하지 마세요.

앱 수치와 서버 수치가 맞지 않는 이유는?

관찰 시작과 종료 시점을 다시 맞추고 다른 앱 활동은 중지하세요. 해당 앱에서 직접 연결과 프록시 요청이 함께 발생할 수 있고, 서버는 다른 앱의 트래픽도 처리할 수 있습니다. 앱 식별 범위와 표시 반올림도 비교 결과에 영향을 주므로 두 누적 수치가 같아야 한다고 기대하지 마세요.

서비스 제공업체의 사용량이 Data보다 많다면?

먼저 요금제 청구 주기를 맞춘 다음 서비스 제공업체가 안내한 트래픽 배수와 갱신 지연, 같은 계정에 연결된 다른 기기의 사용량을 확인하세요. Data는 클라이언트에서 관찰하는 용도이며, 잔여량은 서비스 제공업체의 청구 내역을 기준으로 확인해야 합니다. 문의 자료를 보낼 때 구독 링크나 인증 정보는 첨부하지 마세요.

마지막으로 한 번의 점검을 네 가지 기록으로 정리하세요. 현재 연결 상태, 현재 라우팅 모드, 접속 전후 차이, 대상 요청의 최종 정책입니다. Connectivity Test와 실제 접속이 모두 실패하면 네트워크 또는 서버 연결 상태부터 확인하세요. 접속은 정상인데 경로가 예상과 다르면 Config로 돌아가 규칙 순서를 확인하세요. Data는 확인 과정의 한 부분이지, 단독으로 장애 원인을 확정하는 수단은 아닙니다.