Data는 Shadowrocket이 기록한 트래픽을 확인하는 기능입니다. 이동통신사 요금 내역이 아니며, 특정 웹사이트에 어떤 정책이 적용됐는지를 단독으로 증명하지도 않습니다. 자체적으로 이용 중인 서비스와 구독이 있고 연결할 수 있는 사용자를 대상으로 서버별 집계와 앱별 집계의 차이를 설명하고, ‘기준값 기록 → 요청 전송 → 증가량 확인 → 규칙 대조’ 순서로 점검하는 방법을 안내합니다. Apple 플랫폼과 화면에 따라 집계 기준이 다를 수 있으므로 현재 페이지에 실제로 표시되는 항목만으로 판단하세요.
1. 누적 트래픽·실시간 속도·요금 산정 트래픽 구분하기
Shadowrocket은 App Store에서 판매되는 Apple 플랫폼용 유료 앱으로, 주로 iPhone과 iPad에서 사용합니다. 제품 페이지에서 개발자 Shadow Launch Technology Limited와 앱 ID 932747118을 확인할 수 있습니다. 시스템 요구 사항은 App Store 페이지의 안내를 기준으로 확인하세요. Data에 표시되는 수치는 앱에서 관찰한 결과이며, 이동통신사나 사용 중인 서비스의 요금 기록을 대신할 수 없습니다.
항목을 확인할 때는 먼저 이름, 단위, 집계 범위를 살펴보세요. 업로드는 일반적으로 기기에서 외부로 보내는 데이터, 다운로드는 기기가 받는 데이터를 뜻합니다. 원격 서버 기준이 아니라 기기 기준으로 이해해야 합니다. 초당 단위가 붙은 값은 속도이며, 바이트 단위만 표시된 값은 데이터 양입니다. ‘현재 연결’이나 시간 범위가 명확히 표시되지 않는다면 누적값을 임의로 일일 사용량으로 해석하지 마세요.
연결이 유휴 상태여도 누적량은 늘어날 수 있습니다. 백그라운드 동기화, 알림, DNS 조회, 연결 유지, 재시도 등에서 데이터가 발생할 수 있지만, 요청 세부 정보가 없다면 이 수치만으로 원인을 특정할 수 없습니다. 반대로 웹페이지가 이미 표시됐는데 다운로드 증가량이 작다면 로컬 캐시가 사용됐을 수도 있습니다.
2. 서버별 통계: 특정 아웃바운드의 집계 확인하기
서버별로 확인할 때는 먼저 Home에서 현재 사용 중인 서버와 대조하세요. 이름이 같아도 연결 설정까지 동일하다고 볼 수는 없습니다. 이름 변경, 서버 전환, 기존 구독 업데이트 후 기록을 비교할 때는 주소와 포트, 실제로 선택된 항목도 확인해야 합니다. 서버별 통계는 ‘클라이언트가 이 아웃바운드에 얼마나 많은 트래픽을 집계했는가’를 보여주며, ‘휴대폰의 모든 앱이 사용한 트래픽 총량’을 뜻하지 않습니다.
| 확인 항목 | 판단할 수 있는 내용 | 이것만으로 판단할 수 없는 내용 |
|---|---|---|
| 특정 서버의 업로드 증가량 | 집계 범위 내에서 해당 아웃바운드로 전송된 데이터가 증가했습니다. | 증가분이 모두 포그라운드 앱에서 발생했습니다. |
| 특정 서버의 다운로드 증가량 | 집계 범위 내에서 해당 아웃바운드를 통해 받은 데이터가 증가했습니다. | 증가량이 특정 파일의 표시 용량과 같습니다. |
| 이전 서버에 누적값이 남아 있음 | 페이지에 해당 항목의 과거 통계가 표시되고 있습니다. | 현재 요청이 여전히 이전 서버를 사용하고 있습니다. |
| 서버 통계에 변화가 없음 | 관찰한 동안 해당 항목에서 확인 가능한 증가분이 없었습니다. | 요청이 반드시 DIRECT로 라우팅됐거나 연결이 반드시 끊겼습니다. |
요청이 DIRECT로 라우팅되면 프록시 서버를 거칠 필요가 없습니다. 따라서 특정 프록시 서버의 통계를 직접 연결 트래픽의 총량으로 보면 안 됩니다. 화면의 총합과 개별 서버 통계는 집계 범위가 다를 수도 있습니다. 시간 범위, 필터 조건, 초기화 시점을 확인해 일치하는 경우에만 비교하거나 합산하세요.
3. 앱별 통계: 앱 식별 여부를 확인한 뒤 사용량 해석하기
앱별 통계와 서버별 통계는 집계 기준이 다릅니다. 앱별 통계는 ‘어떤 출처에서 데이터가 발생했는가’를, 서버별 통계는 ‘데이터가 어떤 아웃바운드를 거쳤는가’를 확인하는 데 도움이 됩니다. 한 앱이 여러 도메인에 접속하거나 일부 요청은 직접 연결하고 일부는 프록시를 사용할 수 있으므로 앱 누적량이 특정 서버의 누적량과 같을 필요는 없습니다.
특히 iPhone과 iPad에서는 터널에서 확인되는 네트워크 트래픽을 완전한 프로세스 식별 정보와 동일시할 수 없습니다. 현재 Data 화면에 앱 목록이 없다면 모든 환경에 공통으로 적용되는 ‘앱별’ 스위치를 찾을 필요가 없습니다. 앱별 집계가 표시되더라도 페이지에서 실제로 식별된 결과만 기준으로 삼으세요. 출처를 식별하지 못했거나 명확히 귀속할 수 없는 기록을 방금 연 앱의 트래픽으로 임의 지정해서는 안 됩니다.
- 앱 이름과 도메인은 다릅니다: 하나의 앱이 로그인, 이미지, 동영상, 텔레메트리 등 여러 도메인에 연결될 수 있습니다. 대표 사이트 도메인만 확인해서 전체 트래픽을 추정하지 마세요.
- 포그라운드 앱만 트래픽을 만드는 것은 아닙니다: 브라우저 테스트 중에도 다른 앱이 백그라운드에서 동기화될 수 있습니다. 테스트 시간은 짧게 유지하고 유휴 상태의 기준값도 확인하세요.
- 집계값은 요금 청구액과 다릅니다: 앱 데이터, 프록시 전송 오버헤드, 시스템의 셀룰러 통계는 서로 다른 계층의 값일 수 있으므로 바이트 단위까지 일치할 필요는 없습니다.
- 목록에 없다고 사용량이 0인 것은 아닙니다: 앱 이름이 표시되지 않는 이유는 귀속 기능이나 표시 범위가 제한적이기 때문일 수 있습니다. 이를 근거로 해당 앱이 네트워크에 연결되지 않았다고 단정할 수 없습니다.
특정 앱이 셀룰러 네트워크를 사용했는지 확인하려면 시스템의 ‘설정 → 셀룰러’에서 해당 앱의 통계도 확인하고 집계 기간을 대조하세요. 시스템의 셀룰러 통계에는 같은 범위의 Wi-Fi 사용량이 포함되지 않습니다. Data는 당시의 연결 상태와 화면의 집계 기준을 함께 고려해 해석해야 하며, 두 통계는 같은 요금 내역이 아닙니다.
4. PROXY와 DIRECT 판단하기: 라우팅 모드와 규칙 적용 결과 확인
Data는 결과를 보여주고, Global Routing은 요청의 라우팅 방식을 결정합니다. 규칙을 점검할 때는 먼저 Home → Global Routing에서 현재 모드를 확인한 다음 Config에서 실제 활성화된 설정을 확인하세요. Proxy와 Direct는 각각 전역 프록시와 전역 직접 연결의 기본 용도입니다. Config에서는 설정에 정의된 규칙에 따라 트래픽이 분류됩니다. Scene은 선택된 장면의 설정을 함께 확인해야 하며, 이름만 보고 Config와 같은 방식이라고 판단하면 안 됩니다.
아래는 규칙의 적용 순서를 설명하기 위한 최소 예시이며, 완전한 설정 파일이 아닙니다. example.com은 예시 도메인이므로 실제로 확인하려는 대상 대신 사용할 수 없습니다. PROXY를 통한 전송에는 이미 설정되어 있고 정상적으로 사용할 수 있는 프록시 아웃바운드가 필요합니다.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,DIRECT규칙 예시 읽기
- DOMAIN-SUFFIX
- example.com,PROXY: 이 도메인과 하위 도메인에 매칭됩니다.
- IP-CIDR
- 192.168.0.0/16,DIRECT,no-resolve: 해당 IP 주소 대역에 매칭되며, 이 규칙을 위해 도메인을 별도로 조회하지 않습니다.
- FINAL
- DIRECT: 앞선 규칙이 모두 매칭되지 않을 때 직접 연결합니다.
규칙은 위에서 아래 순서로 평가됩니다. 이 예시는 설명용이므로 수정하기 전에 원래 설정을 보관하세요.
실행 조건 확인
- Home → Global Routing
- 규칙 테스트에는 Config를 사용하고, Scene 전환 여부도 확인하세요.
- Config
- 테스트 규칙이 포함된 파일이 실제 선택되어 있는지 확인하세요.
- Settings → On Demand
- 자동 연결 조건이 테스트 중 터널 상태에 영향을 주는지 확인하세요.
On Demand는 조건에 따라 연결을 처리하는 기능이며, 웹사이트가 PROXY 또는 DIRECT를 사용했다는 증거가 아닙니다.
더 확실한 근거는 대상 요청에 적용된 규칙과 실제 아웃바운드 기록입니다. 현재 화면에서 연결 또는 요청 세부 정보를 제공한다면 도메인, 대상 주소, 시간으로 같은 요청을 찾아 적용된 규칙과 정책을 확인하세요. 서버 통계의 증가는 보조 근거로만 활용할 수 있습니다. 같은 시간에 다른 요청도 해당 서버를 사용했을 수 있기 때문입니다.
5. 전후 차이로 재현 가능한 트래픽 테스트하기
먼저 과거 통계를 모두 지울 필요는 없습니다. 테스트 전후의 값을 기록하면 참고 데이터를 삭제할 필요가 없고, 화면에 초기화 버튼이 있는지에 좌우되지 않습니다. 아래 절차는 사용자가 이미 보유하고 접근 권한이 있는 대상을 사용하며, 서비스를 바꾸거나 새로 추가할 필요가 없습니다.
- 환경 고정: Wi-Fi 또는 셀룰러 중 하나를 선택하고 테스트 중에는 네트워크를 바꾸지 마세요. 진행 중인 대용량 전송을 일시 중지하고 Home에서 현재 서버와 Global Routing 모드를 기록하세요.
- 기준값 기록: Data로 이동해 대상 서버의 업로드·다운로드 수치와 단위를 적어 두세요. 앱별 통계가 있다면 해당 앱의 값도 기록합니다. 약 30초 기다리며 유휴 상태에서도 눈에 띄게 증가하는지 확인하세요.
- 한 가지 작업만 수행: 대상 웹페이지 하나를 열거나 보유 중인 테스트 파일을 읽으세요. 여러 테스트를 동시에 진행하지 말고 시작·종료 시간을 기록한 뒤 리디렉션된 도메인도 확인하세요.
- 증가량 확인: 페이지 통계가 갱신될 때까지 기다린 다음 종료 값에서 시작 값을 빼세요. 표시 정밀도가 낮으면 작은 요청의 변화가 바로 보이지 않을 수 있으므로 곧바로 트래픽이 0이라고 판단하지 마세요.
- 교차 확인: 대상 요청의 매칭 규칙, 실제 아웃바운드, 통계 증가량을 함께 확인하세요. 설정을 바꿔야 한다면 조건 하나만 변경한 뒤 테스트를 반복하고, 완료 후 원래 설정으로 되돌리세요.
6. 자주 묻는 통계 질문과 해결 방법
웹페이지는 열리는데 서버 트래픽이 늘지 않습니다. 프록시를 사용하지 않은 건가요?
먼저 페이지 캐시가 사용되지 않았는지 확인한 다음 Home → Global Routing과 Config에서 활성 규칙을 점검하세요. 실제로 DIRECT 규칙이 적용됐다면 프록시 서버 통계가 늘지 않는 것이 정상입니다. PROXY가 적용됐다면 다른 서버 항목을 보고 있지는 않은지, 통계가 아직 갱신되지 않았는지, 요청이 실제로 다시 전송됐는지 확인하세요.
Data의 수치가 다운로드한 파일 크기보다 큰 이유는 무엇인가요?
다른 전송을 일시 중지하고 전후 차이로 다시 테스트하세요. 파일에 표시된 크기는 파일 내용만 나타내지만, 통계에는 다른 요청, 요청 헤더, 연결 유지 또는 재시도가 함께 포함될 수 있습니다. 어느 계층까지 집계되는지는 화면의 기준을 따르세요. 일정한 비율을 적용해 파일 크기를 역산할 수는 없습니다.
서버를 바꾼 뒤에도 이전 서버에 수치가 남아 있습니다. 삭제해야 하나요?
먼저 누적값과 새로 발생한 값을 구분하세요. 이전 항목의 수치를 기록하고 기다린 뒤 명확한 요청을 한 번 보내 변화가 있는지 확인합니다. 이전 값이 그대로라면 과거 기록일 뿐일 수 있습니다. 화면의 값을 ‘0’으로 만들기 위해 기존 서버나 설정을 삭제하지 마세요.
시스템의 셀룰러 통계와 Data가 크게 다릅니다. 요금제 사용량은 어느 쪽을 기준으로 봐야 하나요?
이동통신사 요금제 사용량은 통신사의 요금 기록을 기준으로 확인하세요. 먼저 시스템의 ‘설정 → 셀룰러’에서 집계 기간을 확인하고, Wi-Fi 사용량, 초기화 시점 차이, 백그라운드 데이터를 구분하세요. Data는 클라이언트에서 확인할 수 있는 트래픽 분포를 점검하는 기능이지, 요금제 잔여량을 알려주는 기능이 아닙니다.
앱별 목록에서 대상 앱을 찾을 수 없습니다. 도메인 기준으로 그 앱에 사용량을 배정해도 되나요?
그렇게 바로 귀속할 수는 없습니다. 여러 앱이 같은 도메인을 사용할 수 있고, 웹페이지가 제3자 리소스를 불러올 수도 있습니다. 먼저 하나의 앱만 사용하고 짧은 시간 동안 테스트를 반복하세요. 그래도 화면에서 출처를 확인할 수 없다면 서버 증가량을 해당 앱에 전부 배정하지 말고 ‘명확히 귀속할 수 없음’으로 기록하세요.
7. 점검 기록을 저장할 때 집계 기준을 남기고 민감 정보 숨기기
재현 가능한 기록에는 테스트 시간, 네트워크 종류, Global Routing 모드, 활성 Config, 대상 도메인, 동일 항목의 전후 차이가 포함되어야 합니다. 이용 중인 서비스 제공자에게 문제를 설명해야 한다면 오류 증상과 실제 적용된 정책도 덧붙이세요. 시간 범위 없이 누적 총량만으로는 대개 특정 요청을 찾아낼 수 없습니다.
- MB 또는 KB/s와 같이 통계 단위와 표시 정밀도를 기록하고, 데이터 양과 속도를 혼동하지 마세요.
- 테스트 중 네트워크, 서버, 설정을 바꿨는지와 자동 재연결이 발생했는지 기록하세요.
- 기존 구독의 전체 URL, token, 비밀번호 및 기타 인증 정보는 숨기세요. 트래픽 진단을 위해 이런 정보를 공개할 필요는 없습니다.
- 요청 한 번이 성공했다고 앱 전체가 항상 같은 경로를 사용한다고 추정하지 마세요. 앱에서 사용하는 도메인은 각각 확인해야 합니다.
결론은 ‘이번 테스트 시간 동안 해당 요청에 특정 규칙이 적용됐고, 대응하는 아웃바운드의 통계가 증가했다’처럼 작성하세요. ‘Data에 수치가 있으므로 모든 트래픽이 프록시를 거쳤다’고 단정하지 마세요. 규칙 근거와 통계 근거를 따로 기록해야 라우팅 오류, 캐시 영향, 백그라운드 사용량, 집계 기준 차이를 구분할 수 있습니다.