Shadowrocket Data 트래픽 통계 확인법: 서버별·앱별 사용량 보기

이 글의 핵심

이 글은 Shadowrocket에 본인이 이미 보유한 구독을 추가하고 트래픽 경로를 확인하려는 사용자를 위한 안내입니다. 먼저 서버와 앱이라는 두 가지 관점을 구분하고, 테스트 전후의 업로드·다운로드 차이로 활동을 파악한 뒤 Global Routing과 연결 기록을 함께 확인합니다. Data는 클라이언트에서 활동을 살펴보는 화면이며, 서비스 제공자의 요금제 잔여량이 아닙니다. 누적 수치 하나만으로 요청에 적용된 규칙을 단정할 수도 없습니다.

Data 통계 범위: 방향, 총량, 속도 구분하기

Shadowrocket의 Data는 클라이언트에 기록된 네트워크 활동을 확인하는 화면입니다. 업로드는 기기에서 원격지로 전송되는 데이터이고, 다운로드는 원격지에서 기기로 전달되는 데이터입니다. 웹페이지를 열면 보통 두 수치가 모두 늘어납니다. 요청, 응답 확인, 앱 동기화에도 업로드가 필요하므로 파일을 보낼 때만 업로드 트래픽이 발생하는 것은 아닙니다.

먼저 수치의 단위를 확인하세요. KB, MB, GB는 데이터 용량이며, /s가 붙으면 전송 속도입니다. 누적 다운로드가 120 MB라고 해서 지금도 다운로드 중이라는 뜻은 아닙니다. 특정 시점에 0 B/s로 표시되어도 이전에 전송된 데이터가 없었다는 의미는 아닙니다. 아래 수치는 계산 방법을 설명하기 위한 예시이며, 성능 테스트 결과나 요금제 과금 기준이 아닙니다.

2가지 방향

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

2가지 관점

서버별로는 출구를, 앱별로는 출처를 확인

전후 2회 측정

테스트 후 수치에서 테스트 전 수치를 빼면 관찰한 증가량을 알 수 있습니다

Data는 기기 전체의 모든 네트워크 활동을 빠짐없이 기록하는 장부가 아닙니다. 통계에는 클라이언트의 처리 경로를 거친 연결, 시스템에서 제공하는 정보, 현재 화면의 분류 범위가 반영됩니다. 해당 처리 경로에 들어오지 않은 활동이 Data에 표시된다고 보장할 수 없으며, 시스템의 셀룰러 데이터 통계와 수치가 일치하지 않을 수도 있습니다.

서버별 보기: 어떤 출구에서 트래픽이 늘었는지 확인

서버별 화면에서는 누적값이 가장 큰 행만 찾기보다 서버 항목별 업로드·다운로드의 변화를 살펴보세요. 오래된 항목에는 장기간의 사용 기록이 남아 있을 수 있고, 현재 선택한 서버에도 새 요청이 한동안 없을 수 있습니다. 이름이 비슷한 항목은 Home에서 구체적인 서버를 확인해 동명 서버를 같은 출구로 오인하지 않도록 하세요.

Home에서 현재 선택된 서버를 확인하고, Global Routing이 Proxy, Direct, Config, Scene 중 어떤 모드인지 기록합니다.
Data로 이동해 대상 서버를 찾고 테스트 전 업로드·다운로드 수치와 시간을 기록합니다.
브라우저에서 본인이 접속할 수 있는 테스트 페이지를 여는 것처럼, 확인 가능한 작업을 한 번만 수행하고 로딩이 끝날 때까지 기다립니다.
Data로 돌아와 수치가 갱신될 때까지 기다린 뒤 같은 행의 값을 기록하고 전후 차이를 비교합니다.

예를 들어 항목의 다운로드가 120 MB에서 128 MB로 늘었다면, 화면에 표시된 정밀도를 기준으로 관찰 증가량은 약 8 MB입니다. 이는 관찰 시간 동안 해당 항목에서 다운로드 활동이 있었다는 뜻이지, 8 MB 전부가 방금 연 페이지에서 발생했다는 증거는 아닙니다. 백그라운드 동기화, 다른 앱의 요청, 페이지에 포함된 여러 리소스가 동시에 같은 출구를 이용했을 수 있습니다.

앱별 보기: 앱의 출처와 목적지는 다릅니다

앱별 화면은 “어떤 식별 가능한 출처에서 트래픽이 발생했는지”를 보여주고, 서버별 화면은 “어떤 출구가 트래픽을 처리했는지”를 보여줍니다. 같은 활동을 서로 다른 관점에서 보는 것이므로 두 화면의 합계를 다시 더하면 안 됩니다. 하나의 앱이 여러 도메인에 요청하면서 PROXY와 DIRECT를 함께 사용할 수 있고, 하나의 서버가 여러 앱의 요청을 처리할 수도 있습니다.

앱 요청터널 연결규칙 매칭아웃바운드 선택통계 분류

앱 분류는 시스템에서 제공하는 정보에 따라 달라집니다. 명확한 앱 이름이 없거나 다른 항목과 통합되어 표시되거나 연결 정보만 보이는 기록은 도메인만으로 특정 앱의 요청이라고 단정하지 마세요. 공유 서비스, 웹페이지에 포함된 리소스, 시스템 백그라운드 활동이 비슷한 주소에 접속할 수도 있습니다. Data는 시스템의 앱별 트래픽 감사 기능과도 다릅니다.

출처 확인: 다른 앱의 전면 작업을 잠시 멈추고 대상 앱 행의 수치를 기록한 다음, 해당 앱에서만 새로고침을 한 번 실행합니다.
경로 확인: 서버의 증가량과 해당 연결 기록을 함께 확인하세요. 앱 행의 수치가 늘었다는 사실만으로 프록시와 직접 연결을 구분할 수는 없습니다.
정보가 비어 있는 경우: 기기에 앱 출처가 표시되지 않으면 이름을 임의로 붙이지 말고 요청 시간, 대상 도메인, 실제 적용된 정책을 연관 지어 판단하세요.
오해 방지: 앱을 백그라운드로 전환해도 네트워크 활동이 즉시 멈추는 것은 아닙니다. 테스트를 끝낸 뒤에도 잠시 수치가 늘어날 수 있습니다.

Global Routing과 규칙 기록을 함께 확인해 PROXY·DIRECT 판별하기

통계를 해석하기 전에 Home → Global Routing부터 확인하세요. Proxy는 프록시 라우팅 모드, Direct는 직접 연결 모드입니다. Config는 현재 설정의 규칙에 따라 트래픽을 분기하고, Scene은 선택한 장면에 설정된 조건과 동작을 따릅니다. Scene을 항상 모든 트래픽을 프록시로 보내는 고정 모드로 보면 안 됩니다. 규칙 파일을 확인하려면 Config를 사용하고, 검사할 설정이 실제로 Config에서 활성화되어 있는지 확인하세요.

Global Routing 확인

모드: Home → Global Routing
Proxy: 프록시 라우팅 모드이며, 규칙별 분기를 확인하는 용도는 아닙니다
Direct: 직접 연결 모드이며, 프록시 서버의 증가량을 성공 기준으로 삼지 않습니다
Config: 현재 설정의 규칙 결과를 적용합니다
Scene: 현재 장면의 조건과 라우팅 설정을 확인합니다

테스트 중에는 모드를 바꾸지 않아 전환 전후의 수치가 섞이지 않도록 하세요.

간단한 규칙 예시

DOMAIN-SUFFIX: example.com,PROXY
IP-CIDR: 192.168.0.0/16,DIRECT,no-resolve
GEOIP: CN,DIRECT
FINAL: PROXY

문법을 설명하기 위한 예시입니다. example.com은 예시 도메인이므로 사용 중인 전체 설정을 그대로 덮어쓰지 마세요.

설정의 [Rule] 섹션에서는 각 규칙을 완전한 한 줄로 작성해야 합니다. 규칙은 일반적으로 위에서 아래로 확인되며, 먼저 일치한 규칙의 정책이 적용됩니다. FINAL은 마지막에 기본 규칙으로 둡니다. 여기서 no-resolve는 이 IP 규칙을 위해 도메인 조회를 별도로 시작하지 않는다는 뜻입니다. GEOIP는 대상 IP의 위치 정보를 판별하며, 웹페이지의 문구나 도메인 접미사로 지역을 추측하는 기능이 아닙니다.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

한 번의 접속 결과를 확인하려면 연결 기록에서 해당 시간과 대상을 찾아 실제로 일치한 규칙, 정책, 아웃바운드 정보를 살펴보세요. PROXY가 정책 그룹을 가리킨다면 그룹에서 실제로 사용된 서버도 확인해야 합니다. DNS, 리디렉션, 페이지의 하위 리소스가 추가 연결을 만들 수 있으므로 한 번의 페이지 로딩에 하나의 정책 결과만 나타난다고 볼 수는 없습니다.

결론: 규칙 결과와 트래픽 증가량을 함께 확인

특정 요청이 PROXY를 거쳤는지 확인하려면 먼저 해당 요청의 매칭 결과와 실제 출구를 찾고, 같은 시간대 서버의 증가량으로 뒷받침해야 합니다. DIRECT 여부도 요청 기록을 확인하세요. 프록시 서버의 수치가 늘지 않았다는 사실만으로 결론을 내릴 수 없습니다.

통계 범위와 초기화 시점: 기준값을 기록한 뒤 테스트

초기화는 새로운 관찰 구간을 시작할 때 유용하지만 라우팅 문제를 해결해 주지는 않습니다. 연결 해제 후 재연결, 서버 전환, Subscribe 업데이트, Config 재선택만으로 모든 누적값이 반드시 초기화된다고 볼 수 없습니다. 화면에 따라 누적 데이터의 범위가 다를 수 있으므로 조작 전에 어떤 범위를 보고 있는지 확인하세요.

기준값 기록: 시간, 서버 이름, 라우팅 모드, 업로드·다운로드 수치를 기록하세요. 문제를 해결할 때는 관련 연결 기록도 함께 보관합니다.
범위 먼저 확인: Data에서 초기화 기능을 사용해야 한다면 현재 화면의 안내를 읽고 대상이 현재 항목인지 전체 통계인지 확인하세요. 범위가 명확히 표시되지 않으면 전후 수치를 빼서 비교하는 편이 좋습니다.
백그라운드 트래픽 줄이기: 제어할 수 있는 대용량 전송과 미디어 재생을 일시 중지하되, 모든 백그라운드 활동이 즉시 멈춘다고 가정하지 마세요.
같은 시간 구간 유지: 테스트를 한 번 완료한 뒤 수치를 기록하세요. 테스트 도중 구독을 업데이트하거나 서버를 전환하거나 설정을 바꾸지 마세요.
결과 보관: 관찰한 증가량과 규칙 기록을 함께 정리한 다음, 다음 초기화 테스트를 시작할지 결정하세요.

클라이언트 수치를 초기화해도 서비스 제공자가 기록한 사용량이나 요금제 주기가 초기화되지는 않습니다. 양쪽 모두 업로드와 다운로드를 집계하더라도 프로토콜 오버헤드, 재전송, 집계 지점, 표시 단위, 업데이트 시점에 따라 차이가 날 수 있습니다. 비교할 때는 먼저 기간과 단위를 맞춘 뒤 서비스 제공자의 과금 기준을 확인하세요. 서로 다른 기간의 합계를 비교해 이상 여부를 판단하지 마세요.

자주 발생하는 통계 문제: 현상을 파악한 뒤 한 가지씩 재시험

웹페이지는 열리는데 서버 통계가 거의 변하지 않습니다. Shadowrocket을 거치지 않은 건가요?

그렇다고 단정할 수는 없습니다. Home → Global Routing을 확인한 뒤 해당 요청에 DIRECT가 적용됐는지 살펴보세요. 캐시된 페이지는 주요 리소스를 다시 다운로드하지 않을 수 있고, 작은 요청은 표시 정밀도 때문에 변화가 보이지 않을 수 있습니다. 새 요청을 확실히 발생시키는 작업을 다른 방식으로 해 보고 연결 기록에서 클라이언트 처리 경로를 거쳤는지 확인하세요.

파일을 직접 업로드하지 않았는데 업로드 수치가 계속 늘어나는 이유는 무엇인가요?

웹 요청, 연결 확인, 앱 동기화에서도 업로드가 발생할 수 있습니다. 미디어 재생과 제어 가능한 전송을 멈추고 1분간의 관찰 구간을 기록한 뒤 새 연결의 대상과 시간을 확인하세요. 지속적인 증가를 구체적인 요청과 연결해야 정상적인 백그라운드 활동인지 앱 동작을 조정해야 하는지 판단할 수 있습니다.

새 서버를 선택했는데 이전 서버의 수치가 조금씩 늘어나는 이유는 무엇인가요?

전환 전에 만들어진 연결이 아직 유지되고 있거나 설정의 정책 그룹이 다른 출구를 선택했을 수 있습니다. 연결 시작 시간, 적용된 정책, 실제 서버를 확인하세요. 테스트 연결을 분리해 다시 확인하려면 업무 중단을 감수할 수 있는 상황에서 현재 테스트 연결을 종료한 다음 요청을 새로 보내세요. Home의 선택 상태만으로 기존 연결 전체의 경로를 판단하지 마세요.

연결을 종료했는데 잠시 뒤 트래픽이 다시 나타나면 어떻게 해야 하나요?

먼저 시스템의 VPN 상태와 Settings → On Demand를 확인해 자동 연결 조건으로 연결이 다시 설정되는지 살펴보세요. 수치가 늦게 갱신된 것인지도 확인합니다. 문제를 일시적으로 점검할 때는 기존 설정을 기록한 뒤 On Demand를 중지하고, 테스트가 끝나면 다시 활성화하세요. 자동 재연결을 통계 기록이 멈추지 않은 것으로 오해하지 않도록 합니다.

앱별 합계와 서버별 합계가 다르면 어느 쪽을 기준으로 봐야 하나요?

두 화면의 분류 범위가 다를 수 있고, 출처가 식별되지 않은 활동이나 DIRECT 연결도 비교에 영향을 줍니다. 먼저 같은 관찰 시간대를 기준으로 맞춘 뒤 요청별로 연결해 보세요. 서비스 잔액을 확인하려는 목적이라면 본인이 이용 중인 서비스의 계정 기록을 확인해야 합니다. Data의 합계를 청구 금액으로 간주하면 안 됩니다.

다시 확인할 수 있도록 트래픽 테스트 기록 저장하기

유효한 점검이라면 세 가지 질문에 답할 수 있어야 합니다. 어떤 앱이 어떤 요청을 보냈는지, 규칙이 어떤 정책을 적용했는지, 해당 출구의 증가량이 예상에 부합하는지입니다. 아래는 수동 기록 양식이며 수치는 계산 예시일 뿐 고정된 트래픽을 뜻하지 않습니다. 테스트 도메인은 본인이 합법적으로 접속할 수 있고 관찰하기 쉬운 대상으로 바꾸세요. 기록에 구독 인증 정보를 포함하지 마세요.

같은 테스트 시간대의 기록 예시
기록 항목	테스트 전	테스트 후 또는 확인 결과
Global Routing	Config	Config 유지
대상 서버 업로드	12 MB	13 MB, 약 1 MB 증가
대상 서버 다운로드	120 MB	128 MB, 약 8 MB 증가
요청 결과	대상과 시작 시간 기록	일치한 규칙, 정책, 실제 출구 확인

현상을 다시 확인하기 어렵다면 같은 작업을 먼저 반복하고 프로토콜, 서버, 규칙을 동시에 바꾸지 마세요. 문제 해결 자료를 공유하기 전에 구독 주소, 토큰, 비밀번호, 키, 개인 접속 기록을 가리세요. Data는 판단을 위한 단서를 제공합니다. 출처, 규칙, 출구, 증가량을 같은 시간대에 함께 기록해야 다시 확인할 수 있는 결론을 내릴 수 있습니다.