자신이 이용하는 서비스의 설정 정보를 갖고 있고, 트래픽이 어디로 전달되는지 확인하려는 사용자에게 적합한 글입니다. 먼저 누적 데이터량과 실시간 전송 속도를 구분한 다음 서버별·앱별 활동의 증가량을 각각 살펴보고, 같은 시간대의 서비스 제공업체 사용량과 비교합니다. Data는 클라이언트에서 관찰한 기록이며 요금제 잔여량이 아니고, 기기의 전체 네트워크 사용량으로 볼 수도 없습니다.
1. Data의 업로드·다운로드와 누적량은 무엇을 뜻하나요?
Shadowrocket의 Data에서는 클라이언트가 기록한 트래픽을 확인할 수 있습니다. 업로드와 다운로드는 기기를 기준으로 구분합니다. 기기에서 외부로 보내는 데이터가 업로드이고, 외부에서 기기로 돌아오는 데이터가 다운로드입니다. 웹 페이지를 열 때도 요청, 확인 정보 및 기타 데이터가 전송되므로 ‘웹만 봤다’고 해서 업로드가 0이 되는 것은 아닙니다. 사진을 업로드할 때도 서버에서 응답을 받습니다.
수치는 단위를 함께 확인해야 합니다. MB와 GB는 데이터량을 나타내고, KB/s와 MB/s는 단위 시간당 전송 속도를 나타냅니다. 연결이 켜져 있어도 매초 데이터가 전송되는 것은 아닙니다. 짧은 시간 동안 속도가 0으로 떨어졌다고 해서 연결에 문제가 있다고 단정할 수도 없습니다. 구체적인 항목과 그룹, 통계 기록 보존 방식은 기기에 표시되는 실제 화면을 기준으로 확인하세요.
| 수치 유형 | 알 수 있는 내용 | 바로 판단할 수 없는 내용 |
|---|---|---|
| Upload / 업로드 | 기기에서 외부로 전송한 데이터량 | 사용자가 직접 업로드한 파일의 실제 크기 |
| Download / 다운로드 | 외부에서 기기로 전송된 데이터량 | 사진 앱이나 파일 앱에 최종 저장된 크기 |
| Total / 합계 | 해당 범위의 업로드와 다운로드 합계 | 서비스 제공업체 요금제의 잔여량 |
| /s가 붙은 수치 | 현재 측정 구간의 전송 속도 | 이번 달 누적 사용량 |
모든 수치가 매월 1일부터 누적된다고 가정하거나, 연결을 끊으면 반드시 초기화된다고 생각하지 마세요. 현재 수치가 연결 중에만 집계된 데이터인지, 계속 보존되는 누적 기록인지 먼저 확인해야 합니다. 화면에 집계 시작 시점이 표시되지 않는다면 총량으로 기간을 추측하지 말고 테스트 전후의 차이를 비교하세요.
2. 서버별 통계: 연결이 향한 곳의 기록이지 계정 전체 내역이 아닙니다
서버별 그룹은 ‘이 시간 동안 어느 서버 항목에서 데이터가 발생했는가’를 확인할 때 유용합니다. 서버별 통계와 서비스 제공업체 계정은 서로 다른 범위입니다. 하나의 계정을 여러 기기에서 사용할 수도 있고, 계정 하나에 여러 서버 주소가 연결될 수도 있습니다. 기기에 기록된 항목은 클라이언트에서 관찰하고 분류할 수 있는 데이터만 나타냅니다. 표시 이름이 같아도 실제 주소가 같다고 할 수 없으므로 주소와 포트, 프로토콜을 함께 확인하세요.
Home → Global Routing에서 현재 동작 방식을 확인하세요. Proxy는 프록시를 통해 처리하고, Direct는 직접 연결하며, Config는 현재 구성된 규칙에 따라 트래픽을 분기합니다. Scene을 사용하는 경우 현재 Scene에서 실제로 어떤 방식이 적용되는지도 확인해야 합니다. 해당 서버를 아웃바운드로 실제 이용한 트래픽만 그 서버의 사용량과 비교할 수 있습니다. 기기의 모든 네트워크 활동을 현재 선택한 서버의 사용량으로 간주하면 안 됩니다.
- Home에서 현재 선택된 서버를 확인하고, 표시 이름만 기록하지 말고 주소와 포트, 프로토콜도 함께 확인합니다.
- Data에서 해당 서버의 업로드·다운로드 시작 수치를 기록합니다. 테스트 중에는 같은 아웃바운드를 유지하고 서버나 정책을 바꾸지 않습니다.
- 명확한 작업을 한 번 수행한 뒤 종료 수치를 기록하고, 종료 수치에서 시작 수치를 빼 증가량을 계산합니다.
- 서버 사용량은 늘었는데 특정 웹 페이지 트래픽이 해당 서버를 거치지 않았다면 다른 백그라운드 요청을 확인하세요. 웹 페이지는 열리는데 서버 사용량이 늘지 않았다면 먼저 Direct 경로로 연결됐는지 살펴봅니다.
예를 들어 Config의 DOMAIN-SUFFIX,example.com,DIRECT는 해당 접미사와 일치하는 요청을 Direct로 보내고, FINAL,PROXY는 앞선 규칙에 일치하지 않은 요청을 처리합니다. 도메인은 규칙 구문을 설명하기 위한 예시일 뿐 실제 구성에 추가할 필요는 없습니다. 통계 수치를 늘리려고 기존 규칙을 함부로 삭제하지 마세요.
3. 앱별 활동: 먼저 앱을 구분할 수 있는 근거를 확인하세요
‘앱별’ 통계는 어떤 앱에서 발생한 활동인지 살펴보고, ‘서버별’ 통계는 어떤 아웃바운드를 거쳤는지 살펴봅니다. 같은 활동을 서로 다른 관점에서 본 것이므로 두 통계의 합계를 더하면 안 됩니다. 플랫폼의 제한도 고려해야 합니다. iPhone/iPad의 시스템 네트워크 확장 기능이 모든 연결에 앱 이름과 직접 연결할 수 있는 식별 정보를 제공하는 것은 아닙니다. 도메인이나 연결 분류를 정확한 앱별 사용 내역으로 간주하지 마세요.
현재 Data 화면에 앱 관련 그룹이 표시된다면 그룹 이름과 제공되는 정보를 먼저 확인하세요. 서버 또는 연결 기록만 표시된다면 앱 하나씩 테스트해 보되, 반드시 존재한다고 가정한 특정 메뉴를 찾으려 하지 마세요. 하나의 앱이 여러 도메인에 접속할 수 있고 여러 앱이 같은 콘텐츠 전송 도메인을 이용할 수도 있으므로, 도메인 이름만으로 앱을 정확히 판단할 수 없습니다.
서버별 확인
- 확인 대상
- 실제로 사용한 서버 항목
- 식별 기준
- 주소, 포트, 프로토콜, 아웃바운드 선택
- 테스트 조건
- 서버와 Global Routing 방식 고정
- 확인에 적합한 질문
- 어떤 아웃바운드에서 트래픽이 발생했나요?
같은 앱의 요청도 규칙에 따라 서로 다른 아웃바운드로 전달될 수 있습니다.
앱 활동별 확인
- 확인 대상
- 목적이 분명한 전면 작업 한 번
- 식별 기준
- 작업 시각, 연결 기록, 사용량 증가분
- 테스트 조건
- 다른 다운로드와 백그라운드 동기화 일시 중지
- 확인에 적합한 질문
- 어떤 종류의 작업에서 트래픽이 늘었나요?
앱을 확인할 수 없는 트래픽은 억지로 배정하지 말고 미분류로 남겨 두세요.
실제로 확인할 때는 동영상 재생, 클라우드 동기화, 다른 다운로드를 먼저 중지하세요. 1분 동안 아무 작업도 하지 않았을 때의 증가량을 기록한 다음 앱 하나만 열어 작업을 한 번 수행합니다. 같은 작업을 두 번째 반복했을 때 증가량이 크게 줄었다면 통계 오류로 단정하기보다 먼저 로컬 캐시를 확인하세요. 앱의 사전 로딩과 백그라운드 작업이 테스트에 섞일 수 있으므로 이 방법은 트래픽 발생 경로를 찾는 데 쓰고 정확한 사용량 정산에는 사용하지 않습니다.
4. 전후 수치로 이번 사용량 계산하기
아래는 계산 방법을 보여 주는 예시이며 실제 제품 측정 결과가 아닙니다. 테스트 전후 화면이 같은 MB 단위를 사용하고, 그 사이 기록을 초기화하거나 서버를 바꾸거나 통계 범위를 변경하지 않았다고 가정합니다. 차이를 계산하면 이전 누적 데이터의 영향을 제외할 수 있습니다. 서비스 제공업체의 사용량과 비교할 수 있도록 테스트 시간도 함께 기록하세요.
| 항목 | 10:00 시작값 | 10:05 종료값 | 이번 증가량 |
|---|---|---|---|
| 업로드 | 12 MB | 15 MB | 3 MB |
| 다운로드 | 240 MB | 300 MB | 60 MB |
| 업로드 및 다운로드 합계 | 252 MB | 315 MB | 63 MB |
이번 합계는 (15 - 12) + (300 - 240) = 63 MB입니다. 종료 시점의 315 MB를 이번 사용량으로 보면 안 됩니다. 표시된 단위만 기준으로 계산하면 5분간 평균 다운로드 속도는 60 ÷ 300 = 0.2 MB/s입니다. 이는 전체 관찰 구간의 평균이며 전송 중 최고 속도나 회선의 최대 속도를 뜻하지 않습니다.
판단 기준: 사용량을 대조할 때는 증가량부터 계산하고 단위를 맞추세요
먼저 클라이언트와 서비스 제공업체 기록을 같은 시간대의 증가량으로 바꾼 다음 단위와 과금 기준을 비교하세요. 누적 총량만 비교하면 수치가 비슷하더라도 통계 범위가 같다는 근거가 되지 않습니다.
단위 환산으로도 차이가 생길 수 있습니다. 십진법 기준 1 GB는 1,000,000,000바이트이고, 이진법 기준 1 GiB는 1,073,741,824바이트입니다. 같은 바이트 수라도 어떤 단위를 쓰느냐에 따라 표시되는 값은 달라집니다. 화면에 GB만 표시되고 기준이 설명되어 있지 않다면 환산 방식을 임의로 정하지 말고 관련 안내를 확인하거나 이용 중인 서비스 제공업체에 문의하세요.
5. Data와 서비스 제공업체 사용량이 다른 이유
클라이언트와 서비스 제공업체는 네트워크 경로의 서로 다른 지점에서 데이터를 집계할 수 있습니다. 실제 데이터가 프로토콜에 캡슐화되면 연결 설정과 암호화 기록 같은 추가 데이터도 포함됩니다. 재전송을 포함하는지, 어느 계층에서 집계하는지도 측정 지점에 따라 달라집니다. 모든 차이를 일정 비율로 설명할 수는 없으며, 차이만으로 비정상적인 사용량이라고 단정해서도 안 됩니다.
- 과금 방향이 다름: 서비스 제공업체는 업로드와 다운로드를 합산할 수도 있고 다른 기준을 적용할 수도 있습니다. 과금 안내를 먼저 확인하고 클라이언트의 Download만 서비스 제공업체의 합계와 비교하지 마세요.
- 집계 범위가 다름: 서비스 제공업체는 다른 기기에서 계정을 사용한 내역까지 합산할 수 있지만, 이 기기의 Data에는 다른 기기의 로컬 기록이 포함되지 않습니다.
- 시간대가 다름: 사용량 반영이 지연될 수 있으며 정산 기간의 시작 시점, 시간대, 새로 고침 시점도 서로 다를 수 있습니다. 양쪽 수치의 기준 시각을 기록해 두세요.
- 배수 적용 및 차감 기준이 다름: 이용 중인 서비스의 약관에 배수 적용이 명시되어 있다면 서비스 제공업체의 차감량이 실제 전송 바이트와 다를 수 있습니다. 공개된 기준에 따라 확인하고 임의로 추측하지 마세요.
- 로컬 기록의 시작 시점이 다름: 통계를 초기화했거나 구성을 변경했거나 기록 보존 범위가 바뀌면 기기의 누적값을 전체 정산 기간의 사용량과 바로 비교할 수 없습니다.
- 트래픽 경로가 다름: Direct 트래픽은 해당 프록시 서버를 통과하지 않습니다. 시스템의 다른 연결에서 관찰되는 범위도 클라이언트 통계와 동일하다고 볼 수 없습니다.
예를 들어 이번 테스트에서 클라이언트의 업로드가 3 MB, 다운로드가 60 MB 늘고 서비스 제공업체 기록이 나중에 63 MB 늘었다면, 적어도 해당 시간대에는 양방향 합산 기준과 맞습니다. 서비스 제공업체 기록이 126 MB라면 2배 과금 규정이 명시되어 있는지 또는 다른 기기에서 사용했는지 먼저 확인하세요. 이 예시는 확인 순서를 설명하기 위한 것이며 실제 서비스의 과금 방식을 단정하는 근거가 아닙니다.
6. 수치가 예상과 다를 때 확인할 순서
먼저 통계 범위와 테스트 조건을 확인한 다음 연결과 구성을 살펴보세요. 구독을 업데이트하면 서버 항목이나 설정값이 달라질 수 있습니다. 한 번의 대조 과정에서 구독 업데이트, 프로토콜 변경, 규칙 조정을 동시에 하지 마세요. 한 번에 조건 하나만 바꿔야 어떤 조작이 수치에 영향을 줬는지 확인할 수 있습니다.
“앱을 열지 않았는데 트래픽이 계속 늘어나는 이유는 무엇인가요?”
먼저 클라우드 동기화, 미디어 재생, 자동 다운로드를 중지하고 1분간 유휴 상태에서 늘어난 양을 기록하세요. 그런 다음 Settings → On Demand에서 연결이 시작되는 조건을 확인합니다. 이 기능은 조건에 따라 연결을 설정할 수 있지만 모든 트래픽이 On Demand 자체에서 발생한다는 뜻은 아닙니다. 백그라운드 작업, 알림, 기존 연결도 데이터를 전송할 수 있습니다.
“웹 페이지는 열리는데 서버 통계가 늘지 않는 이유는 무엇인가요?”
먼저 Home → Global Routing에서 현재 동작 방식을 확인한 다음 Config에서 해당 요청에 적용된 규칙과 아웃바운드를 살펴보세요. Direct 규칙이 적용됐거나, 브라우저가 로컬 캐시를 사용했거나, 다른 서버 항목의 통계를 확인했을 수 있습니다. 이런 경우 대상 서버의 수치는 늘지 않을 수 있습니다.
“Data 수치가 갑자기 줄었는데 트래픽이 반환된 건가요?”
먼저 그룹이나 서버, 통계 범위를 바꿨는지 확인하고 기록을 초기화한 적이 있는지 살펴보세요. 클라이언트 표시값이 줄었다고 해서 서비스 제공업체의 잔여량이 바뀐 것은 아닙니다. 요금제 잔여량은 이용 중인 서비스 제공업체의 계정 화면에서 별도로 확인해야 합니다.
“앱별 사용량을 더해도 서버 합계와 맞지 않는 이유는 무엇인가요?”
먼저 양쪽의 시간 범위가 같은지 확인한 뒤 미분류 트래픽, Direct 경로, 백그라운드 활동을 살펴보세요. 앱을 정확히 식별할 수 없다면 차이를 특정 앱에 억지로 배정하지 마세요. 앱 하나만 사용했을 때의 전후 증가량을 비교해 가장 크게 늘어난 원인을 찾으세요.
- 서버 하나와 Global Routing 방식 하나를 고정하고 시작 수치와 시각을 기록합니다.
- 다른 네트워크 활동을 중지한 뒤 반복 가능한 전면 작업을 한 번 수행합니다.
- 종료 수치를 기록하고 업로드, 다운로드, 합계의 증가량을 각각 계산합니다.
- 서비스 제공업체의 사용량이 반영될 때까지 기다린 다음 같은 시간대, 같은 계정 범위, 같은 단위로 비교합니다.
- 차이가 계속되면 민감 정보를 가린 기록을 준비해 이용 중인 서비스 제공업체에 과금 방향, 배수 적용, 통계 갱신 주기를 문의하세요.
Data는 ‘트래픽이 언제 늘었는지, 얼마나 늘었는지, 주로 어느 아웃바운드를 거쳤는지’를 확인하는 데 가장 유용합니다. 정확한 앱별 사용량이나 계정 과금 내역을 판단할 때는 실제 화면에서 확인할 수 있는 정보와 서비스 제공업체의 기준을 함께 살펴보세요. 단일 수치를 기기 전체 트래픽이나 최종 청구 금액으로 확대 해석하지 마세요.