Shadowrocket Data 트래픽 통계 해설: 서버별·앱별 사용량 확인

이 글의 핵심

이 글은 Shadowrocket에 직접 구독을 추가하고 트래픽 경로를 확인하려는 사용자를 위한 안내입니다. 서버별 집계와 앱별 분류를 구분하고, 통계 구간을 고정한 뒤 단일 요청, 규칙 일치 기록, 트래픽 증가량을 함께 확인합니다. Data의 누적량은 실시간 속도가 아니며 서비스 제공업체의 청구 내역을 그대로 대신하지도 않습니다. 앱별 분류 범위는 실제 화면과 시스템에서 제공하는 정보에 따라 달라집니다.

1. 먼저 Data의 집계 기준 확인하기

Data를 열었을 때 가장 큰 숫자부터 보지 마세요. 먼저 현재 항목이 서버, 연결 대상, 앱 중 무엇을 나타내는지, 값이 업로드인지 다운로드인지 또는 합계인지, 통계가 언제부터 시작됐는지 확인합니다. 두 곳 모두 MB로 표시되더라도 집계 대상이나 시작·종료 시점이 다르면 수치가 같아야 할 이유는 없습니다. 구체적인 분류와 항목, 초기화 위치는 실제 앱 화면을 기준으로 확인하세요.

업로드는 일반적으로 기기에서 외부로 보내는 데이터이고, 다운로드는 기기가 받는 데이터입니다. 웹페이지를 볼 때도 요청, 연결 협상, 확인 정보가 전송되므로 업로드가 0이 아니라고 해서 파일을 직접 보내고 있다는 뜻은 아닙니다. 누적 트래픽은 일정 기간 전송된 데이터의 양을 나타냅니다. 속도는 KB/s처럼 시간 단위가 분모로 들어갑니다. 누적 20 MB를 ‘현재 속도 20 MB’로 해석하면 잘못된 결론에 이르게 됩니다.

2개 방향

업로드와 다운로드를 따로 기록해 합계만 보지 않습니다

60초

이 글에서 권장하는 단일 관찰 구간이며, 앱에 고정된 주기는 아닙니다

기준값 3개

시작 시각, 업로드 누적값, 다운로드 누적값을 기록합니다

이번 작업으로 발생한 트래픽을 확인하려면 누적 총량 두 개를 비교하는 대신 종료값에서 시작값을 뺍니다. 중간에 통계를 초기화하거나 통계 범위를 바꾸거나 연결을 다시 설정했다면 기준값을 다시 기록하세요. 앱 내부 카운터, 시스템 셀룰러 데이터 사용량, 서비스 제공업체 청구 내역은 각각 집계 기준이 다르므로 수치가 다르다는 이유만으로 이상이라고 판단할 수 없습니다.

2. 서버별 통계는 출구를, 앱별 통계는 출처를 보여줍니다

서버별 집계는 ‘어느 서버 항목을 통해 데이터가 처리됐는가’를 보여줍니다. 여러 앱이 같은 서버를 동시에 사용하면 수치가 합산됩니다. 하나의 앱이 여러 대상에 접속할 때도 규칙에 따라 서로 다른 출구를 사용할 수 있습니다. 따라서 서버 트래픽이 증가했다는 사실만으로 특정 앱의 모든 요청이 그 서버를 거쳤다고 단정할 수 없습니다.

앱 요청 터널 수신 규칙 일치 출구 선택 트래픽 집계

앱별 통계는 ‘어느 앱에서 트래픽이 발생했는가’를 보여주려는 것입니다. 하지만 앱과 도메인은 같은 개념이 아닙니다. 하나의 앱이 콘텐츠, 이미지, 로그인, 푸시 등 서로 다른 도메인에 연결될 수 있고, 하나의 도메인에 여러 앱이 접속할 수도 있습니다. 특정 대상 도메인의 누적 트래픽을 특정 앱의 전체 사용량으로 간주해서는 안 됩니다.

특히 iPhone과 iPad에서는 VPN 터널이 얻는 패킷 정보가 시스템 프로세스 정보를 모두 포함하지 않습니다. 현재 Data 화면에 앱 분류 항목이 없다면 서버 이름만으로 앱별 순위를 추정할 수 없습니다. 식별할 수 없거나 앱에 연결되지 않은 기록이 화면에 표시된다면, 그 불확실성을 그대로 두세요. 셀룰러 네트워크에서 앱별 사용량을 확인하려면 시스템의 Settings → Cellular에서 통계 기간을 확인할 수 있습니다. 이 데이터에는 Wi-Fi 사용량이 포함되지 않습니다.

관찰 대상	확인할 수 있는 내용	이것만으로는 확인할 수 없는 내용
서버 항목	현재 구간에 해당 항목에서 발생한 전송량 변화	특정 앱의 모든 요청이 이 서버를 거쳤는지 여부
앱 분류 정보	식별 가능한 범위의 트래픽 출처	기기의 모든 앱이 빠짐없이 분류됐는지 여부
대상 도메인 또는 IP	요청이 연결된 대상	요청이 특정 앱에서 발생했는지 여부
시스템 셀룰러 데이터 사용량	시스템 통계 기간에 사용한 셀룰러 데이터	같은 앱의 Wi-Fi 사용량

3. 구간을 고정해 반복 가능한 트래픽 테스트하기

테스트 전에 Home에서 연결이 설정됐는지 확인하고, Global Routing의 현재 선택 항목과 Config에서 활성화된 구성 파일을 기록합니다. 이 글은 사용자가 이미 서버와 구독을 보유한 상황을 전제로 하며, 통계를 확인하기 위해 별도의 연결 서비스를 추가할 필요는 없습니다. 테스트 중에는 구독을 업데이트하거나 서버를 바꾸지 마세요. 이름이 같은 항목이 바뀌면 전후 비교에 영향을 줄 수 있습니다.

방해 요인 줄이기: 대용량 파일 전송, 동영상 재생, 클라우드 동기화를 일시 중지합니다. 다른 앱의 전면 작업을 멈추되, 모든 백그라운드 트래픽까지 사라진다고 가정하지는 마세요.
시작값 기록: Data에서 대상 서버의 업로드·다운로드 누적값과 시각을 적습니다. 기존 기록은 그대로 두어도 됩니다. 매번 모든 통계를 초기화할 필요는 없습니다.
작업 하나만 실행: 앱 하나만 열고 확인된 페이지에 접속하거나 명확한 작업 하나를 수행합니다. 여러 페이지를 동시에 새로고침하지 말고 약 60초 동안 관찰합니다.
종료값 기록: Data로 돌아가 같은 항목과 같은 기준의 누적값을 확인하고 업로드·다운로드 증가량을 각각 계산합니다.
요청 확인: 확인 가능한 연결 기록에서 대상 도메인, 일치한 규칙, 출구 정보를 살펴봅니다. 세부 정보가 충분하지 않다면 결론을 신중하게 내리고, 증가량 하나만으로 판단하지 마세요.
한 번 더 반복: 설정을 바꾸지 않고 다시 테스트합니다. 두 번째에는 캐시가 사용될 수 있으므로 첫 번째와 바이트 수가 완전히 같을 필요는 없습니다.

설정 두 가지를 비교하려면 매번 변수 하나만 바꾸세요. 예를 들어 서버는 그대로 두고 Global Routing만 Proxy에서 Config로 바꾼 뒤 테스트 연결을 새로 설정합니다. 서버, DNS, 규칙을 동시에 바꾸면 수치가 달라져도 무엇이 원인인지 알기 어렵습니다.

4. 트래픽 증가량과 규칙 일치 결과 대조하기

Home → Global Routing에서 Proxy, Direct, Config, Scene은 서로 다른 라우팅 방식입니다. Proxy는 프록시 경로를 기준으로 비교할 때, Direct는 직접 연결을 기준으로 비교할 때 사용할 수 있습니다. Config는 현재 구성의 규칙에 따라 경로를 판단합니다. Scene은 선택한 장면의 구체적인 설정을 함께 확인해야 하며, 항상 프록시 또는 항상 직접 연결하는 방식으로 이해해서는 안 됩니다.

규칙 기반 라우팅을 확인할 때는 먼저 Config를 선택하고, Config에서 현재 활성화된 파일을 확인하세요. 규칙은 일반적으로 위에서 아래 순서로 적용되므로 먼저 일치하는 항목이 결과에 영향을 줍니다. FINAL은 기본 처리 규칙입니다. 편집기에서 DOMAIN-SUFFIX 항목을 확인했더라도 이번 연결이 그 규칙에 일치했거나 다른 규칙보다 먼저 적용됐다는 뜻은 아닙니다.

테스트 전 기록

연결 위치: Home
라우팅 위치: Home → Global Routing
라우팅 방식: Config
구성 확인: Config에서 현재 활성화된 파일

기억에 의존하지 말고 실제 선택 상태를 기록하세요.

규칙 예시의 의미

DOMAIN-SUFFIX: example.com,PROXY
IP-CIDR: 192.0.2.0/24,DIRECT,no-resolve
FINAL: DIRECT
일치 순서: 위에서 아래로 확인하고, 일치하면 해당 정책을 적용합니다

아래 예시는 예약 도메인과 문서용 주소 대역을 사용하며, 문법 설명만을 위한 것으로 테스트 대상이 아닙니다.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,DIRECT

위 예시에서 example.com과 하위 도메인은 PROXY에 일치합니다. 문서용 주소 대역은 DIRECT에 일치하며, no-resolve는 해당 IP 규칙 때문에 별도의 도메인 조회를 실행하지 않는다는 뜻입니다. 그 밖의 요청은 최종적으로 DIRECT로 처리됩니다. 이는 규칙 일부의 예시일 뿐 완전한 구성 파일을 대신하지 않습니다. 실제 사용 시에는 현재 구성에서 사용할 수 있는 정책 이름과 설정한 대상을 확인하세요.

판단 방법: 요청 하나에 증거 한 묶음

대상이 PROXY를 거칠 것으로 예상된다면 해당 요청에 일치한 규칙, 실제 출구, 해당 서버의 트래픽 증가량을 함께 확인하세요. 누적값만 늘고 요청과 연결되는 정보가 없다면 앱 하나만 사용해 테스트를 반복하세요. 규칙 전체를 바로 수정하지 마세요.

5. 수치가 예상과 다르게 보이는 이유

차이가 생기는 가장 흔한 원인은 규칙 오류가 아니라 집계 범위의 차이입니다. 기기에서는 특정 처리 단계에서 데이터를 집계하고, 서비스 제공업체는 서버 측에서 자체 기준으로 계산할 수 있습니다. 전송 캡슐화, 연결 협상, 재전송, 업로드·다운로드 과금 방식, 시간 구간도 차이를 만들 수 있습니다. HTTPS는 일반적으로 TCP 443 포트를, HTTP/3는 주로 UDP 443 포트를 사용하지만, 포트가 같다고 해서 앱의 출처가 같거나 모든 요청이 같은 전송 방식을 사용한다는 뜻은 아닙니다.

페이지 캐시: 페이지가 로컬 캐시에서 표시되면 업데이트 확인 요청만 소량 발생할 수 있습니다. 화면이 바뀌었다고 해서 전체 콘텐츠를 다시 내려받은 것은 아닙니다.
백그라운드 활동: 알림, 동기화, 기타 연결 때문에 테스트 앱을 사용하지 않는 동안에도 서버 누적값이 계속 증가할 수 있습니다.
직접 연결 트래픽: DIRECT로 처리된 요청은 프록시 서버 항목에 포함될 것으로 기대하면 안 됩니다. 다른 합계에 표시되는지는 현재 화면의 통계 범위를 확인하세요.
기존 연결이 이전 경로를 계속 사용: 규칙을 바꾼 뒤에도 이미 설정된 연결은 기존 경로를 사용할 수 있습니다. 테스트 작업을 끝내고 연결을 새로 설정한 다음 새 규칙을 확인하세요.
집계와 새로고침: 표시값의 반올림, 새로고침 간격, 초기화, 통계 구간 변경은 적은 트래픽을 비교할 때 영향을 줍니다. 차이를 계산하기 전에 이런 요인을 먼저 확인하세요.
항목 변경: 직접 구독을 업데이트하면 서버 이름, 주소, 그룹이 바뀔 수 있습니다. 업데이트 전후에 이름이 같은 기록이라도 하나의 연속된 기록처럼 바로 합쳐서는 안 됩니다.

On Demand도 관찰 구간에 영향을 줍니다. 테스트 중 자동으로 연결이 끊기거나 다시 연결되면 Settings → On Demand에서 실행 조건을 확인하고 실제 연결 상태를 기록하세요. On Demand는 연결 동작을 관리하는 기능입니다. 이것만으로 특정 요청이 PROXY 또는 DIRECT에 일치했다고 단정할 수는 없습니다. 라우팅 판단은 Global Routing과 요청 기록을 함께 확인해야 합니다.

6. 자주 묻는 통계 문제와 확인 순서

앱을 열었는데 서버 트래픽은 왜 늘지 않나요?

먼저 페이지가 캐시에서 표시된 것은 아닌지 확인한 뒤 Home에서 연결 상태와 Global Routing을 살펴보세요. 현재 Direct를 선택했거나 Config 규칙에서 해당 대상을 DIRECT로 보냈다면 프록시 서버 항목이 증가하지 않아도 정상일 수 있습니다. 네트워크 작업을 한 번 더 실행하고 해당 요청의 대상과 출구를 확인하세요.

앱을 모두 닫았는데 Data 수치가 계속 올라요. 규칙이 잘못된 건가요?

먼저 다른 전송 작업을 멈추고 연속된 60초 구간 두 번의 증가량을 기록한 다음, 백그라운드 연결이나 계속 전송 중인 연결이 있는지 확인하세요. 앱을 사용하지 않는다는 이유만으로 트래픽이 비정상이라고 판단할 수는 없습니다. 규칙을 조정하기 전에 대상과 연결을 먼저 확인하세요.

앱별 수치를 더한 값이 서버 합계와 왜 다른가요?

먼저 시간 구간, 네트워크 종류, 업로드·다운로드 집계 기준을 확인하세요. 앱 분류가 완전한지, 분류되지 않은 기록이 있는지, DIRECT 트래픽이 포함됐는지도 살펴봐야 합니다. 시스템 셀룰러 통계와 Data를 비교하는 경우 두 값이 같을 필요는 없습니다. 차이를 특정 앱의 사용량으로 모두 돌려서도 안 됩니다.

규칙을 수정했는데 통계는 계속 이전 서버를 가리키는 것 같아요.

먼저 Config에서 수정한 파일이 활성화됐는지 확인한 다음 Home → Global Routing에서 Config를 선택하세요. 기존 연결을 종료하고 다시 시도합니다. 그래도 결과가 다르면 앞에 있는 규칙과 FINAL을 확인하세요. 필요한 경우 연결을 다시 설정하되, 재연결 전후의 누적값을 섞어 계산하지 않도록 테스트 기준값을 먼저 보관하세요.

문제를 재현할 수 있는 기록에는 테스트 시각, 네트워크 종류, Global Routing 선택 항목, 활성 구성 파일, 대상 요청, 업로드·다운로드 증가량이 포함되어야 합니다. 추가 확인이 필요하다면 문제 해결 가이드에서 연결과 규칙을 살펴보거나 용어 가이드에서 정책 키워드를 확인하세요. Data는 추세를 살펴보고 가설을 검증하는 데 유용합니다. 최종 라우팅 판단은 구체적인 요청과 실제 출구를 근거로 내려야 합니다.