Data는 트래픽 변화를 살펴보는 데 유용하지만, 특정 규칙의 매칭 여부나 회선 요금을 단독으로 판단하는 기준은 아닙니다. 연결 설정을 마친 iPhone·iPad 사용자를 대상으로, 업로드와 다운로드 및 집계 기준을 구분하고 동일한 시간대에 증분을 비교하는 방법을 안내합니다. Global Routing, Config, 연결 기록을 함께 확인해 트래픽 경로를 파악할 수 있습니다.
1. 누적 데이터 사용량과 실시간 속도 구분하기
Shadowrocket의 Data 수치는 단위와 함께 확인해야 합니다. 업로드는 기기에서 외부로 보내는 데이터이고, 다운로드는 기기가 받는 데이터입니다. 웹 페이지를 열 때도 브라우저가 요청과 연결 협상 정보를 보내므로 업로드가 발생합니다. 다운로드가 많다고 업로드가 0이어야 하는 것은 아니며, 업로드가 늘어도 파일을 전송 중이라는 뜻은 아닙니다.
용량을 나타내는 KB, MB, GB와 시간 단위가 붙은 KB/s, MB/s는 서로 다른 개념입니다. 앞의 단위는 일정 범위에서 누적된 데이터양을, 뒤의 단위는 전송 속도를 나타냅니다. 누적량이 크다는 것은 이전에 데이터를 많이 전송했다는 의미일 뿐, 현재 속도가 빠르다는 증거는 아닙니다. 페이지 로딩이 끝나도 속도가 낮아졌다고 누적량이 줄어들지는 않습니다.
위의 60초는 테스트 방법일 뿐, Data의 고정 새로고침 주기가 아닙니다. 통계가 유지되는지, 언제 갱신되는지, 어떤 그룹이 표시되는지는 현재 기기의 화면을 기준으로 확인하세요. 비교를 시작하기 전에 시간, 단위, 그룹을 기록해 두면 어제의 누적값과 오늘의 웹 요청을 잘못 비교하는 일을 피할 수 있습니다.
2. 서버별·앱별 통계: 두 분류의 수치를 바로 더하지 마세요
서버별 보기에서는 관찰 시간 동안 특정 서버 항목의 업로드와 다운로드가 늘었는지 확인합니다. 이 수치로 알 수 있는 것은 관련 아웃바운드 통계의 변화이지, 어떤 앱 하나가 전체 트래픽을 독점했는지는 아닙니다. 여러 앱이 같은 서버를 사용할 수 있고, 정책이 바뀌면 한 앱의 연결마다 다른 아웃바운드가 적용될 수도 있습니다.
앱별 보기에서는 화면에서 식별해 해당 항목에 분류할 수 있는 트래픽을 확인합니다. Apple 플랫폼에서는 출처 식별에 한계가 있으므로 이 화면을 시스템의 모든 앱을 빠짐없이 감사하는 기능으로 해석하면 안 됩니다. 시스템 서비스, 백그라운드 작업, 출처를 명확히 구분할 수 없는 연결은 예상한 앱 이름으로 표시되지 않을 수 있습니다. 이름을 추측하기보다는 실제 표시된 분류를 기준으로 판단하세요.
| 관찰 기준 | 확인할 수 있는 내용 | 이 정보만으로 판단할 수 없는 내용 |
|---|---|---|
| 서버별 | 이번 회차에 트래픽이 늘어난 서버 항목 | 증가한 트래픽이 모두 특정 앱에서 발생했다는 것 |
| 앱별 | 식별 가능한 출처 항목에 새 전송이 있었는지 여부 | 해당 앱의 모든 요청에 같은 규칙이 적용됐다는 것 |
| 업로드 및 다운로드 | 송신량과 수신량의 증가분 | 서비스 제공업체의 과금 트래픽과 바이트 단위로 일치하는지 여부 |
확인 방법: 증분을 각각 비교하고 두 분류의 수치를 합산하지 않기
먼저 같은 그룹에서 테스트 전후 수치를 비교한 다음, 다른 그룹에서 변화 방향을 확인하세요. 서버별 보기와 앱별 보기는 트래픽을 관찰하는 서로 다른 기준입니다. 두 화면의 수치를 더하면 중복 계산될 수 있으므로 더 정확한 총량을 얻을 수 없습니다.
3. 집계 기준과 초기화: 기록을 남긴 뒤 기준값 설정하기
Data, 시스템 네트워크 사용량, 서비스 제공업체의 청구 내역은 집계 시작·종료 시각, 포함 범위, 프로토콜 오버헤드, 단위 환산 방식이 서로 다를 수 있습니다. 같은 다운로드를 관찰해도 세 곳의 수치가 완전히 같을 필요는 없습니다. 특히 클라이언트의 다운로드량을 구독 잔여량으로 간주하지 마세요. 제공업체가 안내하는 정보에서 사용량 한도와 청구 주기를 확인해야 합니다.
초기화는 관찰 구간을 짧게 설정하기 위한 것이며, 연결 문제를 해결하는 데 반드시 필요한 절차는 아닙니다. 연결을 끊었다가 다시 연결하거나 앱을 종료하거나 구독을 업데이트해도 통계가 반드시 초기화되는 것은 아닙니다. 현재 Data 화면에 초기화 기능이 있다면 실행 전에 특정 항목만 초기화되는지, 전체 통계 범위가 초기화되는지 확인하고 필요한 기록을 보관하세요. 아이콘 위치만 보고 적용 범위를 추측하지 마세요.
- 먼저 기록: 현재 서버 이름, 업로드·다운로드 수치, 기록 시각, 이번 회차의 Global Routing 설정을 저장합니다.
- 기준값 설정: 기록을 보존해야 한다면 초기화하지 말고 현재 수치를 시작값으로 사용하세요. 새 관찰 구간이 필요할 때는 화면에 실제로 제공되는 초기화 기능을 사용합니다.
- 결과 확인: 초기화한 뒤 대상 그룹을 다시 확인하세요. 백그라운드 연결이 있으면 수치가 곧 다시 증가할 수 있으므로 오랫동안 0으로 유지되기를 기대해서는 안 됩니다.
- 조건 통일: 다음 회차에서도 같은 네트워크, 같은 테스트 리소스, 같은 시간을 사용하세요. Wi-Fi와 셀룰러 네트워크를 전환했다면 새 회차로 기록해야 합니다.
4. 규칙 기반 라우팅 확인: 먼저 Global Routing 확인하기
Data는 트래픽 변화를 보여 주고 규칙은 요청의 경로를 정하므로, 서로를 대신할 수 없습니다. Home에서 Global Routing 설정을 확인하세요. Config를 사용 중일 때만 현재 설정의 규칙을 기준으로 매칭 결과를 살펴봐야 합니다. Proxy 또는 Direct를 사용 중이라면 Config 안의 특정 도메인 규칙으로 현상을 설명하지 마세요. Scene을 사용한다면 테스트 전에 현재 Scene과 적용 중인 설정을 확인하세요.
아래는 규칙 문법을 설명하기 위한 예시이며, 전체 내용을 기존 Config에 덮어쓰라는 뜻이 아닙니다. 예시의 PROXY는 현재 Config에서 실제로 사용할 수 있는 정책이어야 합니다. example.com은 설명용 도메인이므로 이를 기준으로 실제 서비스의 라우팅 결과를 검증할 수는 없습니다.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX: 도메인 접미사로 매칭합니다. 같은 페이지의 이미지, 동영상, API가 다른 도메인에서 제공될 수도 있습니다.IP-CIDR: 대상 IP 대역으로 매칭합니다. 예시의no-resolve는 이 IP 규칙을 위해 도메인 이름을 별도로 조회하지 않는다는 뜻입니다.GEOIP: IP의 지리적 위치를 기준으로 매칭합니다. 웹사이트에 표시된 언어만으로 규칙이 매칭됐는지 판단할 수 없습니다.FINAL: 앞선 규칙에 매칭되지 않은 요청에 적용되는 기본 규칙입니다. 해당 규칙보다 앞에서 먼저 매칭되는 규칙이 있는지도 확인하세요.
Config에서 현재 사용 중인 설정과 규칙 순서를 확인한 뒤 새 연결을 시작하세요. 규칙을 수정하기 전에 이미 만들어진 장시간 연결은 기존 아웃바운드를 계속 사용할 수 있습니다. 따라서 Data만 새로고침해도 요청이 다시 매칭된다고 보장할 수 없습니다. 기존 테스트 작업을 중단하고 새 요청을 보낸 다음, 확인 가능한 연결 기록에서 대상 도메인 또는 IP, 매칭 규칙, 아웃바운드 정책을 대조하세요.
5. 60초 비교 테스트: 증분으로 원인 범위 좁히기
테스트 전에 대용량 작업을 일시 중지하고, 접근 권한이 있으며 반복 요청할 수 있는 리소스를 선택하세요. Home의 연결 상태와 서버 선택을 그대로 유지하고 Data의 시작값을 기록한 뒤 60초 동안 관찰합니다. 구독 업데이트, 프로토콜 변경, 규칙 수정을 동시에 하지 마세요. 수치가 달라져도 어떤 요인 때문인지 파악하기 어려워집니다.
| 수치 예시 | 테스트 전 | 테스트 후 | 이번 회차 증분 |
|---|---|---|---|
| 서버 다운로드 | 120 MB | 132 MB | 12 MB |
| 서버 업로드 | 8 MB | 9 MB | 1 MB |
표의 수치는 계산 방법을 보여 주기 위한 예시이며 실제 성능 측정값이 아닙니다. 다운로드 증분 12 MB를 60초로 나누면 이 구간의 평균은 약 0.2 MB/s입니다. 대기 시간도 포함되므로 다운로드 중 최고 속도와는 다릅니다. 화면에 표시된 값이 반올림된 경우 차이도 근삿값이므로 소량의 요청을 비교하는 데 적합하지 않습니다.
다음 단계: 통계 변화와 개별 연결을 함께 확인하기
대상 서버의 수치가 증가하고 테스트 리소스가 정상적으로 로드됐다면 이번 회차에 해당 서버에서 데이터가 전송됐다고 볼 수 있습니다. 특정 도메인의 라우팅이 올바른지 확인하려면 해당 요청의 규칙과 아웃바운드도 확인해야 합니다. 수치가 변하지 않았다면 먼저 캐시와 기존 연결을 제외한 뒤 규칙이나 Config 문제를 살펴보세요.
Direct 경로와 프록시 경로를 비교하려면 회차를 나누고 매번 기준값을 새로 설정한 뒤 조건 하나만 바꾸세요. 브라우저 캐시에 있는 페이지를 사용하면 새 다운로드가 거의 발생하지 않을 수 있습니다. 다시 요청했는지 확인할 수 있는 자체 테스트 리소스를 사용할 수 있지만, 의미 없는 대량 전송으로 요금제 데이터를 소모하지 마세요.
6. 자주 묻는 통계 관련 질문과 점검 순서
웹 페이지를 열지 않았는데 Data 수치가 왜 계속 늘어나나요?
먼저 동기화, 미디어 재생 등 알고 있는 작업을 일시 중지하고 일정한 시간 동안 관찰하세요. 백그라운드 요청, 연결 유지 작업, 시스템 서비스에서도 트래픽이 발생할 수 있습니다. Settings → On Demand에서 주문형 연결을 설정했다면 현재 해당 조건으로 연결이 시작됐는지도 확인하세요. 수치가 조금 늘었다는 이유만으로 비정상 전송이라고 판단할 수는 없습니다.
웹 페이지는 열리는데 선택한 서버의 수치가 그대로입니다. 라우팅에 실패한 건가요?
먼저 Home에서 Global Routing 설정과 서버 선택을 확인한 다음 Config에서 적용 중인 설정을 살펴보세요. 리소스가 캐시에서 제공됐거나 Direct로 접속했거나 다른 정책이 선택한 서버를 사용했을 수 있습니다. 스위치를 반복해서 바꾸기보다 새 요청을 보내고 연결 기록을 확인하는 편이 더 유용합니다.
앱별 목록에서 사용 중인 앱을 찾을 수 없습니다. 어떻게 해야 하나요?
앱 이름이 없다고 해서 네트워크에 연결되지 않았다고 판단하지 마세요. 같은 시간대의 전체 변화와 서버 증분을 먼저 확인하고, 해당 요청의 대상과 시각을 함께 살펴 연결을 파악하세요. 출처를 정확히 구분할 수 없는 항목은 불확실한 상태로 두고, 식별되지 않은 트래픽을 특정 앱에 억지로 배정하지 마세요.
구독을 업데이트한 뒤 트래픽 수치가 달라졌습니다. 다시 초기화해야 하나요?
먼저 서버 항목, 정책 참조, 현재 선택이 바뀌었는지 확인하세요. 구독 업데이트와 통계 초기화는 서로 다른 작업입니다. 이전 기록을 보관한 뒤 시작값을 새로 설정하면 테스트를 이어갈 수 있습니다. 항목이 교체됐다면 표시 이름이 같다는 이유만으로 이전과 이후의 수치를 동일한 연속 기록으로 간주하지 마세요.
점검이 끝나면 필요한 라우팅 설정을 원래대로 복원하고 ‘시간, 네트워크, Config, 서버, 시작·종료값, 대상 요청’ 여섯 가지를 기록해 두세요. Data는 변화를 찾고, 연결 기록은 트래픽 경로를 설명하며, 서비스 제공업체 정보는 사용량 한도를 확인하는 데 쓰입니다. 각 정보의 역할을 구분하면 반복해서 초기화하는 것보다 문제를 재현하기 쉽습니다. 기본 사용법은 Global Routing 사용법을, 도메인 이름 조회 문제는 DNS 문제 해결을 참고하세요.