노드 목록 오른쪽 밀리초는 "이 노드가 쓸 만한가"의 유일한 근거로 쓰이기 쉽습니다. 숫자가 낮으면 빠를 것 같지만, 페이지·영상에서는 비례하지 않는 일이 많습니다. 섞이기 쉬운 지연·대역·지터를 나누고, 테스트 숫자가 체감의 어느 부분인지 설명합니다.
목록에서 테스트를 누른 뒤의 밀리초는 지연입니다. 클라이언트가 노드에 작은 요청을 보내고 응답까지 시간입니다. "인사에 몇 밀리초 걸리는가"이지, 대량 데이터를 흘릴 때의 속도가 아닙니다. 지연이 낮다는 것은 왕복이 빠르다는 뜻일 뿐, 영상·방송을 많은 사람이 동시에 쓸 때의 처리량은 알 수 없습니다.
| 지표 | 쉽게 말하면 | 어떤 체감에 영향 |
|---|---|---|
| 지연(Latency) | 메시지를 보내고 답이 오기까지 왕복 시간. 단위는 밀리초 | "탭한 뒤 반응이 시작되기까지"에 영향. 게임·통화 같은 실시간에서 차이가 잘 납니다 |
| 대역(Bandwidth) | 단위 시간에 흘릴 수 있는 데이터량 상한. 수도관 굵기에 가깝습니다 | 대용량 다운로드나 고화질 영상의 상한 속도에 영향. 테스트의 "밀리초"에는 전혀 안 나옵니다 |
| 지터(Jitter) | 지연 자체가 안정적인지. 빨라졌다 느려졌다 하지 않는지 | 지터가 크면 평균 지연이 괜찮아 보여도 통화·영상이 끊기기 쉽습니다 |
| 패킷 손실(Packet Loss) | 보낸 데이터 중 중간에 사라지고 재전송이 필요한 비율 | 손실이 높으면 지연이 낮아도 페이지가 중간에 멈추고, 영상이 반복 버퍼링됩니다 |
목록 테스트는 첫째 항목(지연)만 잽니다. 대역·지터·패킷 손실은 이 숫자에 안 들어갑니다. "수십 밀리초인데 영상이 끊기는" 가장 흔한 이유입니다. 지연이 낮아도 대역은 부족할 수 있고, 연결 중 안정도 보장하지 않습니다.
낮에는 괜찮은데 밤 피크만 느리면, 대개 대역을 동시 이용자가 나눠 쓰는 상태입니다. 서버 총대역은 고정이고 인원이 늘면 1인당이 줄어듭니다. 지연과 직접 관계가 없어, 테스트는 정상인데 실제 전송량은 떨어집니다. 이용자가 적거나 "저부하"로 적힌 노드로 바꾸는 편이 테스트를 반복하는 것보다 낫습니다.
하나 더: Shadowrocket가 재는 것은 클라이언트에서 노드까지 지연입니다. 노드에서 실제 사이트까지의 품질도 체감에 영향을 주지만, 테스트 숫자에는 전혀 안 들어갑니다.
있습니다. 다만 잴 수 있는 범위뿐입니다. "붙는지, 응답이 제때인지" 판단, 특히 같은 묶음에서 뚜렷한 이상(지연이 극단적이거나 타임아웃)을 걸러낼 때 유용합니다. 노드 전체 품질의 유일한 기준으로 쓰지 마세요. 자주 쓰는 사이트를 실제로 여는 편이 더 믿을 만합니다.
참고: 지표 정의는 일반적인 네트워크 지식입니다. Shadowrocket나 특정 사업자 실측이 아닙니다. 숫자는 회선과 노드에 따라 달라집니다.
관련 글: 속도 테스트 이상 문제 해결