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

1. 먼저 Data의 두 가지 통계 기준 구분하기

Shadowrocket의 Data에서는 트래픽 통계를 확인할 수 있습니다. 서버별 보기는 ‘어떤 프록시 서버가 트래픽을 처리했는지’를, 앱별 보기는 ‘어떤 앱에서 발생한 것으로 분류할 수 있는 트래픽인지’를 보여줍니다. 같은 네트워크 활동을 서로 다른 기준으로 보는 것이므로 두 수치를 단순 합산하면 중복 계산될 수 있습니다.

Data를 열면 먼저 현재 보기가 서버별인지 앱별인지 확인한 다음 목록의 누적 수치를 살펴보세요. 목록의 첫 항목을 현재 연결된 서버라고 단정하거나, 앱이 별도 항목으로 표시되지 않는다고 해서 네트워크를 사용하지 않았다고 판단하면 안 됩니다. 시스템이 앱별 정보를 제공하는지, 연결이 현재 통계 범위에 포함되는지에 따라 표시 결과가 달라집니다.

서버별 통계에서는 하나의 앱이 시간에 따라 서로 다른 서버를 사용할 수 있습니다. 앱별 통계에서는 한 앱이 직접 연결과 프록시 연결을 동시에 사용할 수도 있습니다. 따라서 ‘앱에서 사용한 양’과 ‘서버에서 사용한 양’이 일대일로 대응할 필요는 없습니다. 비교할 때는 서로 다른 시점의 총량을 대조하지 말고 같은 시간대를 기준으로 확인하세요.

2. 업로드·다운로드, 누적량, 속도 구분하기

업로드는 기기를 기준으로 바깥으로 전송하는 데이터이고, 다운로드는 기기가 받는 데이터입니다. 웹페이지를 열 때는 보통 다운로드가 많지만 검색어, 요청 헤더, 확인 응답을 보내면서 업로드도 발생합니다. 사진을 올릴 때는 업로드가 주로 발생하지만 서버 확인과 페이지 응답도 받으므로 반대 방향의 트래픽이 0이 되는 것은 아닙니다.

파일 크기와 통계 증가량이 정확히 일치하지 않는 것은 정상입니다. 요청, 암호화 캡슐화, 연결 설정, 재전송으로 데이터가 추가될 수 있으며 캐시, 압축, 분할 요청에 따라 실제 전송량도 달라집니다. 측정 위치에 따라 포함되는 오버헤드가 다를 수 있으므로 하나의 수치만으로 모든 트래픽이 같은 기준으로 계산된다고 단정할 수 없습니다.

대문자 B와 소문자 b를 구분하세요. B는 바이트, b는 비트이며 1 B는 8 b입니다. 1 MB/s를 대역폭 단위로 환산하면 약 8 Mbps이지만 MB와 MiB의 차이, 프로토콜 오버헤드도 고려해야 합니다. Data의 누적 바이트 수는 속도 측정 결과가 아닙니다.

3. 서버별 통계: 전후 차이로 실제 출구 확인하기

서버별 수치는 ‘이번 요청이 예상한 서버를 사용했는지’를 확인할 때 유용합니다. Home에서 서버를 선택했다는 것은 프록시 출구 대상을 지정했다는 뜻일 뿐입니다. 실제 처리는 Global Routing과 규칙의 영향을 받습니다. Global Routing이 Direct이면 요청은 직접 연결되므로 서버를 선택했더라도 해당 서버의 프록시 트래픽이 계속 늘어날 것으로 기대하면 안 됩니다.

1. Home에서 연결 상태, 현재 서버, Global Routing을 확인하세요. 규칙 라우팅을 점검하려면 Config 모드를 사용하고 Config에서 현재 활성화된 구성 파일을 확인합니다.
2. Data를 열고 대상 서버의 현재 업로드량, 다운로드량과 기록 시각을 적어 둡니다. 백그라운드 트래픽을 줄이도록 다른 다운로드, 클라우드 동기화, 스트리밍 재생을 일시 중지하세요.
3. 재현 가능한 작업 하나만 수행하세요. 예를 들어 접근 권한이 있는 웹페이지에서 크기를 알고 있는 파일 하나를 다운로드합니다. 서버를 바꾸거나 규칙을 수정하는 작업을 동시에 하지 마세요.
4. 작업이 끝나면 Data로 돌아와 수치가 갱신될 때까지 기다린 뒤 새 값을 기록하세요. ‘작업 후 값 - 작업 전 값’으로 증가량을 계산합니다.
5. 그다음 해당 연결의 대상, 일치한 규칙, 실제 라우팅 방식을 확인하세요. 서버별 증가량은 참고 자료이며, 개별 연결 기록을 통해 구체적인 요청을 확인할 수 있습니다.

예를 들어 다음은 계산 방법을 보여주는 가상의 사례이며 실제 측정 결과가 아닙니다. 한 서버의 다운로드량이 120 MB에서 132 MB로, 업로드량이 8 MB에서 8.4 MB로 늘었다면 관찰 시간대의 증가량은 각각 12 MB와 0.4 MB입니다. 이 서버에서 트래픽이 발생했다는 뜻이지, 12 MB 전부가 방금 연 페이지에서 발생했다는 증거는 아닙니다.

4. 앱별 통계: 앱 분류와 연결 방식을 구분하기

앱별 보기는 백그라운드 다운로드, 자동 재생, 동기화 작업에서 발생한 트래픽을 찾을 때 유용합니다. 대상 앱을 찾아 같은 시간대의 업로드·다운로드 변화를 확인하세요. 앱에 트래픽이 표시되더라도 모든 요청이 프록시를 사용하는 것은 아닙니다. 하나의 페이지가 기본 도메인, 이미지 도메인, 동영상 도메인, 통계 API를 각각 요청할 수 있으며 각 요청에 서로 다른 규칙이 적용될 수 있습니다.

앱 이름은 시스템에서 제공하는 정보에 따라 표시됩니다. 앱을 특정할 수 없는 항목은 그 한계를 그대로 받아들이고 대상 도메인만으로 앱을 추측하지 마세요. 브라우저의 여러 탭을 앱 전체 통계만으로 구분하기도 어렵습니다. 특정 페이지를 확인하려면 테스트 시간을 짧게 잡고 해당 대상에 대한 연결 기록을 살펴보세요.

• 앱을 사용하지 않는데도 수치가 증가하는 경우: 백그라운드 동기화, 미리 로드, 자동 업데이트, 재생 중인 미디어를 확인하세요. 작업을 일시 중지한 뒤 증가량을 다시 기록합니다.
• 페이지를 열어도 수치가 거의 변하지 않는 경우: 캐시에서 페이지를 불러왔거나 현재 앱별 통계 범위에 해당 트래픽이 포함되지 않을 수 있습니다. 네트워크 요청이 확실히 발생하는 새 작업으로 확인하세요.
• 앱별 총량과 서버별 총량이 다른 경우: 먼저 같은 시간 범위를 기준으로 맞춘 다음 직접 연결 요청, 다른 서버, 앱에 귀속되지 않은 트래픽이 섞였는지 확인하세요. 항목별 수치를 억지로 일치시키지 마세요.

기기에 예상한 앱별 항목이 표시되지 않는다고 해서 설치 오류라고 단정할 수는 없습니다. 현재 플랫폼에서 제공하는 통계 항목을 확인하세요. 앱별 정보가 충분하지 않더라도 서버별 증가량과 연결 기록으로 라우팅을 검증할 수 있습니다.

5. Data로 Config 규칙 라우팅 확인하기

Data에서는 전송 결과의 변화를 볼 수 있지만 각 규칙이 일치한 이유까지 설명하지는 않습니다. 규칙을 확인하려면 먼저 Home → Global Routing이 Config인지 확인한 다음 Config에서 현재 구성을 점검하세요. Proxy, Direct, Scene은 서로 다른 라우팅 모드이므로 다른 모드에서 얻은 결과를 현재 규칙 파일의 검증 결과로 간주하면 안 됩니다.

규칙 한 줄은 규칙 유형, 일치 값, 정책으로 구성되며 FINAL은 기본 정책을 직접 지정합니다. 다음은 문법 예시일 뿐 모든 네트워크 환경에서 바로 사용할 수 있는 라우팅 설정이 아닙니다. IP-CIDR에는 실제 서비스에 잘못 연결되지 않도록 문서용 예약 주소 대역을 사용합니다.

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

규칙은 위에서 아래로 검사하며 처음 일치하는 규칙에서 처리가 끝납니다. DOMAIN-SUFFIX는 도메인 접미사를, IP-CIDR은 주소 대역을 기준으로 일치합니다. IP-CIDR의 no-resolve는 해당 IP 규칙을 위해 도메인 조회를 능동적으로 실행하지 않는다는 뜻이지, 앱의 모든 DNS 조회를 중지한다는 뜻은 아닙니다. FINAL은 앞선 규칙과 일치하지 않은 요청을 처리하므로 우선 적용할 규칙 뒤에 배치해야 합니다.

1. 접근 권한이 있는 실제 대상을 사용하고, 도메인 규칙이 더 넓은 규칙에 먼저 일치하지 않도록 앞쪽에 배치하세요.
2. 수정 사항을 저장하고 변경한 Config가 현재 사용 중인지 확인하세요. 이전 페이지를 닫거나 기존 연결을 종료한 뒤 새 요청을 보내 이전 연결의 영향을 피합니다.
3. 연결 기록에서 대상과 일치한 정책을 확인한 다음 Data의 서버별 증가량과 대조하세요. DIRECT가 예상되는 경우 페이지가 열렸다는 사실만으로 프록시가 적용됐다고 판단할 수 없습니다.
4. 테스트가 끝나면 기존 구성으로 복원하세요. 원래 Scene을 사용했다면 선택 조건을 기록해 두어 복원 후 라우팅 변화와 통계 오류를 혼동하지 않도록 합니다.

6. 트래픽 수치 불일치와 연결 해제 후 증가 등 자주 묻는 문제

문제를 확인할 때 프로토콜, DNS, 규칙, 서버를 한꺼번에 변경하지 마세요. 한 번에 하나만 바꾸고 테스트 시각, 네트워크 유형, 라우팅 모드, 전후 수치, 연결 결과를 기록합니다. 그래야 ‘백그라운드 트래픽’, ‘규칙 선택’, ‘통계 범위’ 문제를 구분하고 이후에도 같은 조건으로 재현할 수 있습니다.