Data는 트래픽 변화를 살펴보는 데 유용하지만, 특정 규칙이 적용됐다는 사실을 단독으로 입증하지는 못합니다. 기존 서비스 제공업체와 구독을 이용 중인 경우를 전제로, 누적 사용량과 실시간 속도를 구분하고 서버별·앱별 통계의 의미를 설명합니다. 마지막으로 동일한 네트워크에서 테스트 전후 수치와 요청 기록을 대조해 트래픽 분산을 확인합니다. 기기에 따라 표시되는 통계 항목이 다를 수 있으므로 현재 화면에 실제로 보이는 항목을 기준으로 확인하세요. 앱 식별 결과를 시스템 전체 트래픽 목록으로 간주해서는 안 됩니다.
통계 기준 먼저 확인하기: 업로드·다운로드와 속도
Shadowrocket의 Data를 확인할 때는 수치가 누적 바이트인지, 일정 시간 동안 전송된 양인지 먼저 구분하세요. 업로드는 기기에서 외부로 보낸 데이터, 다운로드는 기기가 받은 데이터를 뜻합니다. 파일을 누가 만들었는지가 아니라 기기 기준으로 나뉩니다. 웹페이지를 열 때도 요청, 확인 응답 등 데이터를 보내므로 업로드가 발생할 수 있습니다.
누적 사용량은 보통 KB, MB, GB와 같은 용량 단위로 표시되고, /s가 붙은 수치는 속도를 나타냅니다. 다운로드 누적량이 20 MB 늘었다고 해서 다운로드 속도가 20 MB/s라는 뜻은 아닙니다. 화면에 바이트 단위 속도가 표시되고 속도 측정 결과가 비트 단위라면 이론상 1 byte = 8 bits입니다. 실제로 비교할 때는 측정 시간과 단위 체계도 맞춰야 합니다.
통계는 집계 시작 시점과 범위에도 영향을 받습니다. 연결 시작, 앱 재시작, 수동 초기화가 같은 집계 기준이라고 단정하지 마세요. 먼저 현재 화면의 시간 범위나 초기화 상태를 기록하고, 명확한 안내가 없다면 같은 화면에서 같은 테스트 전후의 차이만 비교하세요. Data의 로컬 집계와 서비스 제공업체의 청구 내역은 서로 다른 계층에서 산출될 수 있으며, 프로토콜 오버헤드와 과금 방향, 정산 기준도 다를 수 있습니다. 이를 근거로 구독 잔여량을 추정할 수는 없습니다.
| 관찰된 현상 | 알 수 있는 내용 | 바로 단정할 수 없는 내용 |
|---|---|---|
| 누적 다운로드량 증가 | 집계 범위에서 데이터를 수신함 | 대상 웹페이지가 완전히 로드됐다는 사실 |
| 순간 속도가 0으로 표시됨 | 현재 측정 구간에 전송이 거의 없거나 없었음 | 서버를 사용할 수 없다는 사실 |
| 업로드량이 계속 증가함 | 기기에서 외부로 데이터가 계속 전송됨 | 사용자 파일을 업로드 중이라는 사실 |
| 로컬 통계와 청구 내역이 다름 | 두 통계의 집계 기준을 대조해야 함 | 둘 중 한쪽의 집계가 반드시 잘못됐다는 사실 |
서버별 통계: 출구를 확인하되 선택된 항목이 전체 트래픽이라고 보지 않기
서버별 집계로는 “어떤 서버의 수치가 변하고 있는지” 확인할 수 있습니다. Home에서 서버를 선택하면 관련 프록시의 현재 선택 상태를 뜻합니다. Config에서는 요청이 설정된 규칙에 따라 DIRECT, 프록시 정책 또는 다른 정책으로 처리됩니다. 따라서 선택한 서버의 사용량이 눈에 띄게 늘지 않아도 모든 네트워크 요청이 실패한 것은 아닙니다. 현재 접속이 직접 연결을 사용하거나 다른 정책에 일치했을 수도 있습니다.
이 흐름은 트래픽 분산을 이해하기 위한 것으로, 모든 통계 카운터가 같은 계층에 있다는 뜻은 아닙니다. 특정 서버를 확인할 때는 이름, 주소, 포트를 기록해 이름이 같은 항목 두 개를 같은 출구로 오인하지 않도록 하세요. 포트는 연결 설정값이지 통계 단위가 아닙니다. 예를 들어 설정에 포트가 443으로 표시돼도 포트만으로 실제 사용된 프로토콜을 판단할 수는 없습니다.
- Home에서 현재 연결 상태, 서버 선택, Global Routing을 확인합니다.
- Data를 열고 대상 서버에 표시된 업로드·다운로드 수치를 단위를 바꾸지 않고 기록합니다.
- 명확한 네트워크 작업을 한 번 수행한 뒤 같은 통계 항목으로 돌아와 증가량을 기록합니다.
- 증가량이 예상과 다르면 서버를 바로 바꾸지 말고 해당 요청에 실제 적용된 정책이나 규칙을 확인합니다.
기존 연결도 흔한 변수입니다. 서버를 바꾸거나 규칙을 수정해도 이미 수립된 연결이 새 조건으로 즉시 다시 연결되는 것은 아닙니다. 테스트할 때는 기존 네트워크 작업을 끝낸 후 새 요청을 시작하세요. 재연결해야 한다면 중요한 전송 작업이 진행 중인지 먼저 확인하고 중지하세요. 서버를 바꾼 뒤에도 계속 재생되는 동영상만으로 새 서버가 해당 연결을 처리한다고 단정할 수 없습니다.
앱별 통계: 앱의 출처, 도메인, 시스템 활동 구분하기
서버별 통계는 출구 기준이고 앱별 통계는 출처 기준입니다. 두 수치를 더해 전체 트래픽으로 볼 수는 없습니다. 같은 요청이 하나의 출처와 하나의 출구에 동시에 집계될 수 있습니다. 앱별 통계는 “테스트 중 어떤 식별 가능한 출처가 활발했는지”, 서버별 통계는 “어떤 출구에서 전송량이 변했는지” 확인하는 데 적합합니다. 두 통계는 동일한 시간 범위를 기준으로 살펴보세요.
iPhone과 iPad에서 터널이 확인할 수 있는 정보는 시스템의 배터리 또는 셀룰러 설정에 표시되는 앱별 정보와 같지 않습니다. Data에 설치된 앱마다 전체 업로드·다운로드 내역이 표시된다고 미리 가정하지 마세요. 현재 화면에 앱 분류가 있다면 먼저 해당 라벨의 의미를 확인하세요. 서버, 연결 또는 도메인 기록만 제공된다면 표시된 항목만으로 분석하고, 존재하지 않는 메뉴를 찾지 마세요.
| 관찰 기준 | 확인하기 좋은 내용 | 주요 한계 |
|---|---|---|
| 서버 | 어느 프록시 출구의 수치가 증가했는지 | 요청을 시작한 앱을 완전히 파악할 수 없음 |
| 앱 분류 | 식별 가능한 출처 중 어디에서 활동이 발생했는지 | 식별 범위는 시스템과 화면의 기능에 따라 다름 |
| 도메인 또는 대상 주소 | 요청이 어느 네트워크 대상에 접속했는지 | 하나의 대상을 여러 앱이 함께 사용할 수 있음 |
| 요청 및 규칙 기록 | 특정 요청에 어떤 정책이 적용됐는지 | 테스트 시각 및 대상과 대조해야 함 |
브라우저에서 페이지를 열면 기본 도메인뿐 아니라 이미지, 폰트, API 도메인에 접속할 수 있습니다. 다른 앱도 같은 콘텐츠 전송 주소를 사용할 수 있습니다. 따라서 특정 도메인이 보인다고 해서 한 앱만 사용한다고 단정할 수 없습니다. 백그라운드 동기화, 시스템 푸시, 캐시도 관찰 결과에 영향을 줍니다. 직접 조작하지 않아도 트래픽이 발생할 수 있고, 캐시된 페이지를 다시 열면 트래픽이 거의 없을 수도 있습니다.
결론: 출처와 출구를 따로 확인하기
먼저 단일 앱에서 새 요청을 한 번 만들어 관찰 범위를 좁힌 다음, 대상 주소와 적용된 정책을 확인해 출구를 파악하세요. 서버 전체 사용량이 증가했다는 이유만으로 증가분 전부를 방금 연 앱의 트래픽으로 돌리지 마세요.
Global Routing과 규칙 기록으로 트래픽 분산 확인하기
규칙을 확인하기 전에 Home에서 Global Routing 상태를 확인하세요. Proxy, Direct, Config, Scene은 서로 다른 상태입니다. Proxy는 프록시 라우팅, Direct는 직접 연결, Config는 현재 설정에 따른 처리, Scene은 선택된 장면의 구체적인 설정을 기준으로 합니다. Config에서 특정 규칙이 적용되는지 확인하려면 연결 스위치가 켜져 있는지만 볼 것이 아니라 현재 라우팅 모드가 Config인지 먼저 확인해야 합니다.
아래는 문법을 이해하기 위한 최소 예시이며 기존 설정을 그대로 바꾸라는 뜻은 아닙니다. example.com은 예시 도메인이고, 192.0.2.0/24는 문서용 예시 주소 대역으로 실제 연결 테스트 대상이 아닙니다. 수정하기 전에 기존 설정을 보관하고 설정에 지정된 정책 이름이 실제로 존재하는지 확인하세요.
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX는 지정된 도메인과 하위 도메인에 일치합니다. 기본 페이지와 리소스 도메인이 다르면 각각 다른 규칙에 일치할 수 있습니다.IP-CIDR은 대상 IP 주소 대역을 기준으로 일치합니다. 예시의no-resolve는 해당 IP 규칙 때문에 별도의 도메인 조회를 추가로 수행하지 않는다는 뜻이지, 연결에 DNS가 전혀 필요 없다는 뜻은 아닙니다.GEOIP는 대상 IP를 지리 데이터베이스에 따라 분류해 일치시키는 규칙입니다. 웹사이트에 표시된 언어나 도메인 접미사로 판단하는 것과는 다릅니다.FINAL은 앞선 규칙에 일치하지 않은 요청을 처리합니다. 문제를 확인할 때 예상한 규칙뿐 아니라 요청이 마지막 매칭 항목까지 도달했는지도 살펴보세요.
규칙은 일반적으로 설정 순서대로 확인되며, 앞쪽 규칙이 일치하면 뒤쪽 규칙은 해당 요청을 처리할 기회가 없을 수 있습니다. Data에 증가량만 표시되는 경우 어떤 규칙에 일치했는지는 역으로 알아낼 수 없습니다. 앱에서 제공하는 요청 또는 로그 기록에서 테스트 대상, 발생 시각, 일치한 규칙, 실제 적용 정책을 대조하세요. 구체적인 메뉴 위치는 현재 화면을 기준으로 확인하고, 통계 항목을 규칙 일치 로그로 간주하지 마세요.
재확인 가능한 테스트: 전체량 대신 차이 비교하기
같은 네트워크, 같은 서버 선택, 같은 설정을 유지한 채 전면에서 실행되는 앱 하나로 짧게 테스트하는 것이 좋습니다. 다른 다운로드나 동기화 작업은 잠시 멈추되 시스템의 백그라운드 통신이 계속될 수 있다는 점은 고려하세요. 목적은 기기를 완전히 통신이 없는 상태로 만드는 것이 아니라 대상 요청과 시간 범위를 명확히 해 기록과 대조할 수 있도록 하는 것입니다.
- 조건 기록: Wi-Fi 또는 셀룰러 네트워크, Global Routing, 현재 Config, 서버 항목, 연결 상태를 적어 둡니다. 이때 구독은 업데이트하지 않습니다.
- 시작 수치 기록: Data에서 대상 통계 항목의 업로드·다운로드 수치를 기록합니다. 화면에 초기화 기능이 있다면 사용해도 되지만, 전후 차이를 비교하는 데 초기화는 필요하지 않습니다.
- 새 요청 시작: 도메인을 확인할 수 있는 페이지를 열고 시각을 기록한 뒤 약 60초 동안 관찰합니다. 이 시간은 테스트 구간일 뿐 성능 기준이 아닙니다.
- 종료 수치 기록: 같은 통계 항목을 확인하고 집계 범위가 그대로인지, 중간에 재연결이나 네트워크 전환이 있었는지 점검합니다.
- 대조 확인: 대상 요청 기록의 출구를 Data 증가량과 대조합니다. 설정 하나를 바꿨다면 새 요청을 시작해 다시 테스트합니다.
예를 들어 서버의 다운로드 시작 수치가 120 MB이고 종료 수치가 128 MB라면 차이는 8 MB입니다. 이는 계산 예시일 뿐 실제 측정값이 아니며 페이지 본문 크기가 8 MB라는 뜻도 아닙니다. 이 시간 동안 백그라운드 활동이 있었다면 차이에 다른 트래픽도 포함됩니다. 통계가 정수 MB만 표시한다면 작은 요청은 한동안 눈에 띄지 않을 수도 있습니다.
결론: 한 번에 조건 하나만 바꾸기
먼저 설정을 고정해 출구를 확인한 다음 규칙 하나만 바꾸고 새 연결로 요청을 다시 시작하세요. 같은 테스트에서 구독 업데이트, 네트워크 전환, 서버 변경을 동시에 하지 마세요. 수치가 달라진 원인을 구분하기 어렵습니다.
구독 업데이트로 서버 항목이 달라질 수 있고 Config 변경으로 트래픽 분산 결과가 바뀔 수 있으므로 두 작업은 테스트와 분리해야 합니다. 기존 구독을 업데이트해야 한다면 업데이트를 마친 뒤 선택된 항목을 다시 확인하고 새로운 테스트 시작 수치를 기록하세요. 업데이트 전후에 이름이 같은 서버의 통계를 연속된 데이터로 간주하지 마세요.
자주 묻는 통계 질문과 확인 순서
웹페이지는 열리는데 서버 트래픽은 왜 거의 늘지 않나요?
먼저 Home에서 Global Routing을 확인한 다음 대상 요청이 DIRECT 또는 다른 정책을 사용하는지 살펴보세요. 이어서 새 네트워크 요청을 만들어 캐시의 영향을 배제하고, 다른 동명 항목이 아닌 대상 서버의 수치를 확인했는지 점검합니다. 웹페이지가 열린다는 사실만으로 현재 선택한 서버를 거쳤다고 판단하지 마세요.
앱을 열지 않았는데 업로드와 다운로드 수치가 계속 바뀌는 이유는 무엇인가요?
네트워크 조건을 그대로 유지하고 짧은 유휴 구간의 수치를 기록한 뒤, 단일 앱을 전면에서 조작했을 때와 비교하세요. 백그라운드 동기화, 시스템 통신, 기존 연결이 계속 데이터를 전송할 수 있습니다. 대상 주소와 시각을 함께 확인해 범위를 좁히되, 전체 수치의 변화만으로 특정 앱이 파일을 업로드 중이라고 판단하지 마세요.
앱별 통계 메뉴를 찾을 수 없는 이유는 무엇인가요?
먼저 현재 Data 화면에서 실제로 제공하는 그룹을 확인하고 서버 목록을 앱 목록으로 오해하지 마세요. 앱 출처를 표시하는 항목이 없다면 전면 앱 하나, 고정된 시간 구간, 대상 요청 기록을 이용해 관찰하세요. 시스템 자체의 사용량 통계는 별도의 집계 기준으로 확인해야 하며 터널 누적 수치와 바로 빼서 비교하면 안 됩니다.
Data 수치는 늘어나는데 웹페이지에 오류가 표시되는 이유는 무엇인가요?
데이터가 오갔다는 사실은 통신이 발생했다는 뜻일 뿐입니다. 먼저 실패한 요청의 오류 정보와 적용된 정책을 확인한 다음 대상에 연결할 수 있는지, DNS와 연결 설정이 올바른지 살펴보세요. 핸드셰이크, 오류 응답, 재시도에서도 사용량이 늘 수 있으므로 트래픽이 있다는 사실만으로 요청 성공이나 정상 속도를 입증할 수는 없습니다.
확인을 마친 뒤에는 테스트 시각, 네트워크 유형, 라우팅 모드, 대상 도메인, 출구 정책, 수치 차이 등 재확인에 필요한 최소한의 정보를 보관하세요. 진단 내용을 공유하기 전에 구독 주소, 액세스 토큰, 비밀번호, 개인 키를 가려야 합니다. 통계 화면이나 로그는 문제와 관련된 부분만 남기고 전체 설정을 공개할 필요는 없습니다.