Clash Verge Rev 트래픽·연결 로그 사용법: 실시간 모니터링과 간단 트리아지 (2026)

1. 이 글이 다루는 범위와 아닌 것

Clash Verge Rev는 GUI이고 실제 패킷 처리와 규칙 매칭은 내부의 mihomo(Clash Meta 계열) 코어가 담당합니다. 사용자 입장에서 「브라우저는 되는데 게임만 안 된다」「속도는 나오는데 특정 사이트만 하얀 화면이다」처럼 모호한 증상은, 곧바로 YAML을 뜯기보다 대시보드 숫자가 살아 있는지, 연결 행에 어떤 호스트가 찍히는지, 로그에 handshake나 DNS 타임아웃이 있는지 세 갈래로 나누어 보는 편이 빠릅니다. 여기서 말하는 「실시간 모니터링」은 바로 그 세 화면을 가리킵니다.

반대로 첫 설치, 시스템 프록시와 TUN 중 무엇을 켤지, 구독 URL이 403으로 막히는지 같은 주제는 각각 전용 튜토리얼이 있습니다. 윈도우 예열은 Windows 10 Verge Rev 첫 설정·Windows 11 버전, 맥은 macOS Verge Rev 글을 먼저 밟고 이 페이지로 오면 흐름이 끊기지 않습니다.

2. 실시간 트래픽·통계 화면 찾기

앱을 켠 직후 보이는 메인 패널 주변에 초당 업로드·다운로드 속도가 숫자나 그래프로 표시되는 경우가 많습니다. 최신 빌드마다 탭 이름이 「대시보드」「개요」「트래픽」「통계」처럼 조금씩 다를 수 있으나, 공통점은 현재 활성 프로필 기준으로 코어가 처리 중인 바이트량을 보여 준다는 것입니다. 아무 웹페이지도 열지 않았을 때는 거의 0에 가깝고, 동영상을 재생하거나 대용량 파일을 받으면 즉시 치솟아야 정상입니다.

숫자가 전혀 움직이지 않는데 브라우저만 빠르다면, 브라우저가 시스템 프록시를 무시하고 다른 경로(보안 DNS, 자체 VPN 확장 등)를 쓰고 있을 가능성이 있습니다. 반대로 대시보드는 도는데 특정 앱만 느리다면 그 앱의 트래픽이 Clash를 타지 않는지 의심합니다. 이때 다음 절의 연결 목록에서 해당 앱이 만든 흐름이 보이는지가 결정적인 단서가 됩니다.

일부 화면에는 프로필별·노드별 누적 사용량이나 간단한 차트가 붙어 있습니다. 월간 데이터 한도를 맞추려는 사용자에게는 이 요약이 유용하고, 트리아지 관점에서는 「특정 아웃바운드로만 트래픽이 몰리는지」를 한눈에 보는 용도로 쓰입니다. 고급 사용자는 동일한 정보를 REST로 받아 시각화하기도 하는데, 그 경우가 바로 external-controller 경로이며 로컬 바인딩·토큰 노출은 반드시 보안 가이드와 함께 다뤄야 합니다.

3. 연결 목록으로 무엇을 읽나

연결(Connections) 뷰는 지금 열려 있거나 막 종료된 세션을 행 단위로 보여 줍니다. 각 행에는 보통 목적지 호스트 또는 IP, 프로토콜·포트, 매칭된 규칙 이름이나 정책 그룹 선택 결과, 사용 중인 프록시 체인 같은 열이 있습니다. 문제 재현 절차는 단순합니다. 브라우저에서 실패하는 사이트를 새로 고친 직후 목록을 보고, 같은 초에 추가된 행의 목적지가 무엇인지 확인합니다.

행이 DIRECT로만 나오고 우회 노드를 타지 않는다면, 규칙 순서상 해당 도메인이 국내·직결 매칭에 걸렸거나 DNS가 예상과 다른 IP를 준 상황일 수 있습니다. 반대로 원하는 노드 이름으로 체인이 이어지는데도 페이지가 열리지 않으면 노드 품질·SNI·UDP 처리 문제로 넘어가야 합니다. HTTPS 스니핑이나 SNI 관련 로그 패턴을 더 깊게 보고 싶다면 스니퍼·로그 글을 참고하면 같은 용어를 매칭하기 쉽습니다.

게임·음성·P2P처럼 UDP가 섞이는 앱은 TCP 행만 보고 판단하면 빗나가기 쉽습니다. 연결 목록에 UDP 소켓이 따로 찍히는지, 특정 포트가 막혔는지 함께 봅니다. 또 일부 OS에서는 프로세스 이름 대신 IP만 보일 때가 있는데, 그럴 때는 같은 시각의 로그에 찍힌 다이얼 메시지와 호스트 문자열을 대조합니다.

4. 코어 로그 레벨과 검색 포인트

Verge Rev의 로그(Log) 창은 코어가 출력하는 텍스트 스트림을 보여 줍니다. 레벨은 보통 info가 기본이고, 문제 재현 시에만 잠시 debug로 올립니다. debug는 출력량이 매우 커서 디스크와 CPU를 잠깐이라도 부담스럽게 만들 수 있으므로, 원인을 좁힌 뒤에는 다시 낮추는 습관이 좋습니다.

검색할 때 자주 쓰는 키워드는 다음과 같습니다. DNS 타임아웃이나 NXDOMAIN은 이름 해석 경로를 의심하게 하고, dial·proxy 관련 줄은 실제로 어떤 아웃바운드로 붙으려 했는지 알려 줍니다. TLS·certificate 메시지는 회사 중간 프록시나 노드 인증서 교체와 연결되기 쉽습니다. 구독 URL 자체가 실패할 때 나오는 HTTP 코드 패턴은 구독 전용 글의 체크리스트와 1:1로 대응시키면 이해가 빠릅니다.

# Example keywords to scan for in log viewer (illustrative)
# dial tcp / i/o timeout / TLS handshake / GeoIP / RULE-MATCH

로그와 연결 목록을 같은 타임스탬프로 묶어 보면 「어떤 호스트에 어떤 규칙으로 다이얼을 시도했고, 어디에서 실패했는지」가 한 줄로 이어집니다. 반복 재현이 어려우면 문제 행동 직전에 로그를 비우고(clear) 한 번에 재현하는 방식이 디버깅 비용을 줄입니다.

5. 증상별 간단 트리아지 순서

현장에서 통하는 순서를 하나로 묶으면 다음과 같습니다. 첫째, Verge Rev 상단이나 설정에서 시스템 프록시와 TUN 중 무엇이 켜져 있는지, 혼합 상태가 의도와 같은지 확인합니다. 둘째, 활성 프로필과 선택된 노드가 만료·실패 표시가 없는지 봅니다. 셋째, 트래픽 숫자가 반응하는지로 「코어가 트래픽을 만지고 있는지」를 판별합니다.

넷째, 문제 행동 직후 연결 목록에 해당 호스트가 나타나는지, 어떤 규칙과 아웃바운드가 붙었는지 확인합니다. 다섯째, 같은 구간의 로그에서 DNS·dial·TLS 중 어디에서 끊기는지 읽습니다. 여기까지 왔는데도 원인이 갈리지 않으면 글로벌 모드나 다른 노드로 A/B 테스트하고, 그래도 안 되면 프로필의 DNS·fake-ip·fallback 설정을 의심합니다. 이후 단계는 이미 「설정 파일 튜닝」 영역이므로 규칙 라우팅 가이드나 제공자 문서를 펼칩니다.

CFW에서 넘어온 사용자는 용어 맵만 맞추면 같은 절차를 그대로 적용할 수 있습니다. 클라이언트 이름은 바뀌었지만 연결·로그·통계의 역할 분담은 거의 동일합니다. 마이그레이션 맥락은 CFW 대체 가이드와도 맞물립니다.

6. Windows와 macOS에서 달라지는 점

Windows에서는 방화벽 프로필·다른 보안 제품·회사 가입 상태 관리가 로컬 루프백 포트나 Wintun 어댑터에 간섭하는 경우가 있습니다. 트래픽 숫자가 멈추고 연결 목록이 비정상적으로 비면, 잠시 보안 제품을 끄거나 예외 규칙을 두고 같은 재현을 한 번 더 해 보는 것이 비용 대비 효과가 큽니다. UWP 앱은 시스템 프록시만으로 부족할 때가 많아 TUN을 함께 쓰는 사례가 흔합니다.

macOS에서는 시스템 프록시를 존중하지 않는 CLI·샌드박스 앱이 많아, 동일한 연결 목록을 봐도 「행은 있는데 앱은 여전히 직결」처럼 보이는 착시가 생길 수 있습니다. 이때는 TUN 활성화 여부와 시스템 확장 승인 상태를 다시 확인하고, 터미널 도구에는 환경 변수 프록시를 병행하는 패턴이 현실적입니다. 자세한 모드 비교는 앞서 인용한 macOS Verge Rev 글의 체크리스트와 같은 순서로 맞추면 됩니다.

두 OS 모두에서 공통인 원칙은, GUI 통계는 코어가 실제로 처리한 바이트를 반영한다는 점입니다. 따라서 숫자와 연결 목록이 동시에 멈추면 코어 프로세스·프로필 로드·포트 충돌 쪽을 의심하고, 숫자만 살아 있고 특정 앱만 문제면 앱별 네트워크 스택을 의심합니다.

7. 자주 묻는 질문