이미 자신의 서버에 연결했는데 Data 페이지에서 서버별 수치와 앱별 수치가 서로 맞지 않거나, iOS 설정의 사용량 통계와 차이가 나는 경우가 있습니다. 이 글은 '진입 경로 → 단위 → 두 그룹의 집계 기준 → 차이의 원인 → 점검 순서' 순으로 각 수치의 의미를 짚고, 재현 가능한 확인 절차를 제시합니다. 구독 가져오기를 마치고 수치로 트래픽 흐름을 판단하려는 독자에게 적합합니다. 글 전체는 이미 자신의 서비스 제공자와 구독이 있다는 전제로 쓰였으며, 본문에 나오는 서버 이름과 숫자는 배치를 보여주기 위한 예시일 뿐입니다.
Data 페이지는 어디에 있고, 두 그룹은 각각 무엇을 집계하는가
Shadowrocket을 열면 하단 탭 바의 Data가 트래픽 통계 페이지입니다. 페이지 상단에는 해당 기간의 총량이 업로드와 다운로드로 나뉘어 표시되고, 그 아래에 그룹별 세부 내역이 나옵니다. 페이지 상단에서 그룹을 전환하면 '서버별'과 '앱별' 두 관점을 오갈 수 있습니다. 연결 스위치가 꺼져 있으면 트래픽이 터널을 지나지 않아 페이지의 숫자가 늘지 않으므로, 수치가 멈춰 있다면 먼저 Home으로 돌아가 상단의 연결 스위치 상태를 확인하세요.
두 그룹이 집계하는 대상은 서로 다릅니다. '서버별'은 특정 서버 항목에 귀속된 연결의 바이트 수를 집계하며, 실제로 그 서버를 거쳐 전달된 연결만 이 목록에 잡힙니다. '앱별'은 연결을 시작한 App을 기준으로 집계하며, 연결이 터널을 거쳤다면 최종적으로 프록시를 타든 DIRECT로 처리되든 해당 항목에 기록됩니다. 따라서 같은 기간이라도 두 그룹의 합계는 대개 일치하지 않으며, 차액은 DIRECT로 처리된 연결과 DNS 조회, REJECT된 연결에서 나옵니다.
어느 그룹을 먼저 볼지는 답하려는 질문에 따라 달라집니다. 트래픽이 어느 서버로 갔는지 알고 싶으면 서버별을, 트래픽을 누가 발생시켰는지 알고 싶으면 앱별을 봅니다. 두 그룹을 함께 봐야 '특정 앱'과 '특정 서버'를 연결지을 수 있습니다.
단위와 읽는 법: 업로드·다운로드·총량 맞추기
각 수치는 업로드와 다운로드로 나뉩니다. 업로드는 기기가 보낸 바이트, 다운로드는 기기가 받은 바이트이며 두 값은 하나로 합쳐지지 않습니다. 점검할 때 의미가 서로 다르기 때문입니다. 다운로드가 비정상이면 보통 콘텐츠를 내려받거나 동기화하고 있다는 뜻이고, 업로드가 비정상이면 업로드나 백업, 하트비트 요청과 관련이 있을 가능성이 큽니다.
단위는 1024진법으로 B, KB, MB, GB 순으로 단계마다 환산되며, 표시할 때 알맞은 단위가 자동으로 선택되므로 같은 행이 시점에 따라 MB로도 GB로도 나타날 수 있습니다. 수치의 기준은 터널 내부의 바이트 수로, 암호화와 캡슐화에 따른 오버헤드가 포함되어 실제 콘텐츠 크기보다 보통 조금 큽니다. 1 MB 파일을 내려받았는데 수치가 1.0x MB로 표시되는 것은 정상입니다.
전체 ↑ 15.6 MB ↓ 412.3 MB
서버별 Server A ↑ 12.4 MB ↓ 386.2 MB
서버별 Server B ↑ 1.8 MB ↓ 24.9 MB
앱별 Safari ↑ 3.1 MB ↓ 208.7 MB
위 배치는 예시일 뿐이며 숫자는 실제 측정값이 아닙니다. 실제 목록에서는 각 행에 전체 대비 비율도 함께 표시되어 어느 항목이 가장 큰지 빠르게 판단할 수 있습니다. 비율과 절대값을 함께 보면 총량만 볼 때보다 이상 징후를 찾기 쉽습니다.
서버별 수치: 트래픽이 어느 서버로 갔는가
'서버별' 목록의 각 행은 Home 페이지 서버 목록의 항목 하나에 대응하며, 이름도 Home에 표시되는 것과 같습니다. 서버를 바꾸면 새 트래픽은 새 항목에 기록되고, 이전 항목의 기록은 Data 페이지에서 직접 초기화하거나 해당 항목을 삭제하지 않는 한 자동으로 0이 되지 않습니다.
이 그룹은 두 가지 질문에 곧바로 답합니다. 현재 트래픽이 의도한 서버로 가고 있는가, 그리고 조작하지 않았는데도 특정 서버에서 트래픽이 계속 발생하고 있는가. 전자는 Global Routing과 Config 규칙이 의도대로 동작하는지 확인하는 데 쓰고, 후자는 설정에서 잊고 있던 항목을 찾아내는 데 씁니다.
| 수치 그룹 | 집계 대상 | 포함 | 미포함 |
|---|---|---|---|
| 서버별 | 특정 서버 항목에 귀속된 연결 | 해당 서버를 거쳐 전달된 업로드·다운로드 바이트 | DIRECT로 처리된 연결, DNS 조회, REJECT된 연결 |
| 앱별 | 연결을 시작한 App | 해당 App이 터널을 통해 처리한 모든 연결(DIRECT로 처리된 부분 포함) | 연결 스위치가 꺼져 있는 동안 발생한 트래픽 |
목록에 모르는 항목이 보이면 먼저 Home으로 돌아가 서버 목록을 확인하세요. 항목 이름은 Home과 같으며, 보통 직접 가져온 설정이나 수동으로 추가한 서버에서 비롯됩니다. 항목이 저절로 생기지는 않습니다.
앱별 수치: 트래픽이 어느 App에서 나가는가
'앱별' 목록은 트래픽을 연결을 시작한 프로세스에 귀속시킵니다. 같은 도메인에 대한 요청이라도 다른 App이 보내면 각각 따로 기록되므로 '누가 트래픽을 쓰고 있는가'에 답할 수 있습니다. 시스템 수준 통계로는 할 수 없는 일입니다. 시스템 사용량 통계는 네트워크 인터페이스 단위로만 집계할 뿐 바이트를 특정 App에 귀속시키지 못합니다.
Global Routing의 상태는 두 그룹 수치의 분포를 곧바로 바꿉니다. Config 상태에서는 규칙에 매칭된 연결이 해당 서버에 집계되고 DIRECT로 처리된 연결은 앱별 목록에만 나타납니다. Proxy 상태에서는 모든 연결이 현재 선택된 서버로 모여 서버별 목록에서 거의 한 행만 늘어납니다. Direct 상태에서는 서버별 수치가 사실상 멈추고 앱별 수치는 계속 누적됩니다.
설정(Config)
권장규칙에 따라 분기: 규칙에 매칭된 연결은 해당 서버로 가고 그 서버에 집계되며, DIRECT로 처리된 연결은 앱별 목록에만 나타납니다.
적합: 일상 주력, 어떤 트래픽이 프록시를 타는지 확인할 때
프록시(Proxy)
모든 연결이 현재 선택된 서버로 전달되어 서버별 목록이 한 행에 집중되므로 총량과 터널 오버헤드를 확인하기 좋습니다.
적합: 임시 전체 프록시, 수치 총량 확인
직접 연결(Direct)
모든 연결이 직접 나가므로 서버별 수치는 더 늘지 않고 앱별 수치는 계속 누적되어 두 수치의 차이가 가장 뚜렷해집니다.
적합: 규칙 오매칭 검증, 임시 대조
규칙이 잘못 매칭되는지 확인할 때 Direct 상태는 깨끗한 대조군이 됩니다. Direct로 전환한 뒤 같은 작업을 한 번 더 했을 때 앱별 수치의 증가분이 이전과 같다면, 그 트래픽은 원래 직접 연결이었고 규칙과는 무관하다는 뜻입니다.
iOS 시스템 통계와 왜 맞지 않는가
iOS의 '설정 → 셀룰러'에서는 현재 청구 기간의 셀룰러 데이터 사용량을 볼 수 있습니다. 이는 셀룰러 인터페이스의 모든 바이트를 집계한 값으로, 터널을 거쳤는지와 상관없이 모든 App의 연결이 포함됩니다. Shadowrocket의 Data 페이지는 터널을 거친 바이트를 집계하며 Wi-Fi와 셀룰러를 모두 포함합니다. 두 값은 측정 지점과 범위가 다르므로 숫자가 다른 것은 당연합니다.
흔한 차이 원인은 다음과 같습니다.
- 집계 범위: 시스템 사용량은 인터페이스의 모든 네트워크 활동을 포함하지만 Data 페이지는 터널을 거친 부분만 포함합니다. 연결 스위치가 꺼져 있는 동안의 트래픽은 Data 페이지에 전혀 집계되지 않습니다.
- 인터페이스 범위: 셀룰러 데이터 사용량은 셀룰러 인터페이스만 집계하지만 Data 페이지는 Wi-Fi와 셀룰러를 함께 집계하므로, Wi-Fi 환경에서 두 값의 차이가 가장 크게 벌어집니다.
- 초기화 시점: 시스템 사용량은 청구 기간이나 수동 재설정으로 0이 되고, Data 페이지에는 자체 초기화 기능이 있어 두 값이 동시에 0이 되지 않습니다.
- 프로토콜 오버헤드: 터널 내부의 바이트에는 암호화와 캡슐화 헤더가 포함되므로, 같은 콘텐츠라도 Data 페이지 수치가 원래 페이로드보다 보통 조금 큽니다.
- 귀속 방식: 시스템은 인터페이스 사용량을 App별로 집계하고, Data 페이지는 서버와 앱이라는 두 축으로 그룹화합니다. 그룹 기준이 달라 행 단위로 맞춰볼 수 없습니다.
결론: Data 페이지는 상대 비교에만 사용
Data 페이지의 절대값은 시스템 통계와 일치할 필요가 없습니다. 이 페이지의 가치는 같은 기간 안에서의 상대적 분포에 있습니다. 이상 여부를 판단할 때 보는 것은 총량이 시스템의 숫자와 같은지가 아니라, 특정 행의 증가분이 자신의 조작과 맞아떨어지는지입니다.
Data 페이지로 비정상 트래픽을 찾는 순서
아래 순서는 '특정 앱이 몰래 트래픽을 쓰고 있는가'라는 질문에 답하기 위한 것입니다. 두 가지 전제에 기댑니다. 먼저 깨끗한 기준선을 세우고, 조작은 한 번만 해서 여러 변수가 섞이지 않게 합니다.
연결이 켜져 있는지 확인
Home 상단에서 연결 스위치가 켜져 있는지 확인합니다. 꺼져 있으면 트래픽이 터널을 지나지 않아 Data 페이지에 새 수치가 생기지 않으므로 이후 단계가 모두 무의미해집니다.
기준선 초기화
Data 페이지에서 두 그룹의 수치를 초기화하고, 시스템 사용량과 비교할 수 있도록 초기화 시각을 기록해 둡니다.
조작은 한 번만
관찰하려는 App으로 돌아가 한 가지 명확한 작업을 합니다. 예를 들어 페이지 하나를 열고 로딩이 끝날 때까지 기다리는 식이며, 다른 App은 건드리지 않습니다.
먼저 앱별 보기
앱별 그룹으로 전환해 어느 행의 증가분이 가장 큰지 봅니다. 그 행이 이번 작업을 시작한 주체입니다.
다음으로 서버별 보기
서버별 그룹으로 전환해 증가분이 의도한 서버에 기록됐는지 확인합니다. 증가분이 전혀 없다면 이번 연결이 DIRECT로 처리됐다는 뜻입니다.
라우팅 상태와 대조
증가분이 예상 밖의 서버에 나타났다면 Home으로 돌아가 Global Routing 상태와 Config 규칙을 확인하고, 규칙이 앞에서 먼저 매칭되지 않았는지 점검합니다.
3~5단계를 두세 번 반복합니다. 매번 증가분이 같은 행에 나타난다면 트래픽 출처를 사실상 확인한 셈입니다. 증가분이 들쭉날쭉하다면 App의 백그라운드 새로 고침이나 푸시가 동시에 연결을 맺고 있을 수 있으므로, App을 백그라운드로 보낸 뒤 한 번 더 관찰합니다.
결론: 먼저 규모로 분류하고, 무엇을 확인할지 정한다
두 그룹 수치가 맞지 않을 때는 먼저 차액의 규모를 봅니다. 차액이 몇 MB라면 보통 DNS 조회와 REJECT된 연결에서 비롯됩니다. 차액이 수백 MB에 이른다면 특정 App의 트래픽이 DIRECT로 처리됐을 가능성이 큽니다. 분류를 먼저 하고 움직여야 하며, 순서를 뒤집으면 정상 현상을 고장으로 오해하게 됩니다.
자주 묻는 질문
서버별 합계가 총량보다 적은데, 데이터가 유실된 건가요?
아닙니다. 총량은 터널 내부의 모든 바이트를 집계하고, 서버별은 특정 서버에 귀속된 부분만 집계합니다. DIRECT로 처리된 연결과 DNS 조회, REJECT된 연결은 모두 앱별 쪽에만 나타납니다. 앱별 합계와 총량을 비교하면 보통 더 가깝습니다.
Data 페이지 숫자가 계속 0인데, 어떻게 움직이게 하나요?
먼저 Home으로 돌아가 연결 스위치가 켜져 있는지 확인하고, Global Routing이 Direct에 멈춰 있지 않은지도 확인합니다. 둘 다 정상이라면 아무 웹페이지나 열어 연결을 한 번 발생시키면 수치가 곧 나타납니다.
서버를 바꾸면 이전 서버의 수치가 자동으로 0이 되나요?
아닙니다. 수치는 서버 항목별로 따로 누적되며, 서버를 바꾸면 새 트래픽이 새 항목에 기록될 뿐입니다. 초기화하려면 Data 페이지에서 직접 재설정하거나 해당 항목을 삭제해야 합니다.
앱별 목록에 모르는 항목이 있는 이유는 무엇인가요?
일부 연결은 시스템 서비스나 백그라운드 프로세스가 시작하며, 귀속시킬 포그라운드 앱이 없어 시스템 또는 알 수 없음 항목으로 표시됩니다. 이런 항목은 보통 양이 매우 적습니다. 특정 항목이 계속 늘어난다면 Home으로 돌아가 서버 목록과 Config 규칙을 확인하세요.