누구를 위한 글인가: 설치 글·YAML 글과 어떻게 나뉘나
이미 Windows 11에서 실행 파일을 깔고 구독까지 넣은 사용자라면, 다음 단계는 “지금 쓰는 노드가 느린지 빠른지를 클라이언트 안에서 확인하고, 이름 섞인 프록시 그룹를 이해한 뒤, 클릭 몇 번으로 갈아타는 것”입니다. 검색 결과에는 과거 Clash for Windows 화면이나 Meta 코어 설정 파일 단편이 섞여 있어, 메뉴 이름만 보고 따라 하면 금방 엇나갑니다. Clash Verge Rev는 빌드마다 표기가 조금씩 달라도, 구조는 프로필(구독) → 프록시·노드 목록 → 정책(그룹) 패널 → 연결·로그로 이어집니다.
이 글은 그 중간 고리를 전제로 합니다. 처음부터 TUN까지 필요하면 Win11 설치·TUN 가이드를 먼저 보고 오면 흐름이 끊기지 않습니다. 반대로 “자동 최저 지연”, “예비 노드 체인”처럼 구성 파일 레벨을 파고들고 싶다면 정책 그룹·지연 자동화 글이 검색 의도에 더 가깝습니다. 여기서는 YAML 편집 없이 화면에서 끝내는 검색어에 초점을 맞춥니다.
Verge Rev 화면에서 봐야 할 네 가지 축
혼란을 줄이기 위해 화면을 네 축으로 나눠 보면 이후 단계가 단순해집니다. 첫째, 프로필 축입니다. 여러 구독을 두었다면 “지금 활성인 JSON/YAML 세트가 무엇인지”가 모든 그룹·노드의 출처입니다. 둘째, 프록시(노드) 목록 축입니다. 개별 서버·릴레이의 지연과 상태가 여기에 모입니다. 셋째, 프록시 그룹(정책 그룹) 축입니다. selector처럼 사용자가 고르는 그룹과, url-test처럼 주기적으로 잰 뒤 고르는 그룹이 같은 패널에 올라옵니다. 넷째, 연결·로그 축입니다. “화면에서는 빠른데 실사용은 다르다”일 때 도메인이 어느 그룹으로 갔는지 확인하는 안전벨트입니다.
Windows 트레이 아이콘 메뉴에는 자주 쓰는 전환이 모여 있는 빌드도 있고, 메인 창에서만 조작하는 빌드도 있습니다. 핵심은 “트레이가 아무리 짧게 보여도, 근본적인 그룹 이름과 노드 연결은 메인 창의 프록시 패널과 일치해야 한다”는 점입니다. 표시 언어를 한국어로 바꿔도 영문 그룹 이름은 구독 원본을 그대로 보여 주는 경우가 많으니, 이름을 외우기보다 역할로 기억하는 편이 낫습니다.
지연 측정이 말해 주는 것(그리고 말해 주지 않는 것)
지연 측정·원클릭 측정은 대개 작은 테스트 URL에 HTTP 요청을 보내 왕복 시간을 잽니다. 숫자가 낮을수록 “그 순간, 그 테스트 대상에 대한 응답이 빨랐다”는 뜻이지, 영상 재생 버퍼나 대용량 다운로드 속도까지 보장하지는 않습니다. 또 측정 서버 위치가 사용자와 멀면 밀리초가 부풀어 보일 수 있어, 상대 비교용으로 쓰는 것이 안전합니다. “내 회선 전체 품질”이 아니라 “이 프로필 안에서 지금 노드들이 서로 비해 어떤가”에 가깝습니다.
측정이 timeout이면 노드가 죽었거나, 방화벽이 막았거나, DNS가 틀어졌거나, 공급자 쪽 일시 장애일 수 있습니다. 모든 노드가 동시에 timeout이면 로컬 쪽(시스템 시간·보안 소프트웨어·다른 VPN·프록시 중첩)을 의심합니다. 몇 개만 살아 있으면 살아 있는 항목으로 먼저 붙여 실사용·로그를 함께 보는 것이 빠릅니다.
원클릭·일괄 지연 측정 실행과 표 해석
실제 동작은 빌드에 따라 “프록시” 탭 상단의 일괄 테스트 아이콘, 컨텍스트 메뉴의 지연 재기, 또는 그룹 단위 측정으로 나뉩니다. 공통 패턴은 다음과 같습니다. 프록시 목록에서 측정을 실행하면 각 행 옆 숫자가 갱신되고, 실패 행은 timeout·대시·회색으로 표시되는 경우가 많습니다. 측정 직후 곧바로 노드를 바꿔도 되지만, 너무 짧은 간격으로 연타하면 공급자나 로컬 백신이 이상 트래픽으로 볼 여지가 있으니 수 초에서 수십 초 간격을 두는 습관이 좋습니다.
숫자가 갑자기 튀는 경우는 Wi-Fi 절전, 절전 모드 복귀 직후, 백그라운드 업데이트가 겹친 타이밍에서 흔합니다. 한 번만 이상하면 재측정하고, 반복이면 timeout·TLS 로그 가이드 순서로 원격·로컬을 가릅니다. 회사망에서는 테스트 URL 자체가 필터링되어 전부 실패로 보일 수 있습니다—이때는 허용된 네트워크에서 다시 확인하거나 IT 정책을 따르는 것이 안전합니다.
측정 후에 할 일(짧은 체크리스트)
- 같은 시간대에 두세 번 재측정해 재현되는지 본다.
- 빠르게 나온 노드로 바꾼 뒤 실제 접속(브라우저와 문제 앱 둘 다)을 확인한다.
- 여전히 느리면 어느 그룹을 바꿨는지와 연결 로그의 도메인이 같은지 대조한다.
정책 그룹 읽기: selector·url-test·fallback을 UI에서 구분
구독 작성자는 보통 여러 프록시 그룹을 올려 둡니다. UI에서 이름 옆이나 부가 설명으로 유형이 비치기도 하고, 아니면 동작으로 역추적해야 합니다. selector 스타일은 목록에서 하나를 사용자가 직접 고르는 형태입니다. url-test는 일정 주기로 후보를 재어 가장 낮은 지연 쪽으로 붙는 패턴입니다. fallback은 우선순위를 타고 내려가며 살아 있는 다음 후보를 쓰는 패턴으로 이해하면 UI에서 혼동이 줄어듭니다. 이 구분은 파일에서 읽을 때도 같지만, 이 글에서는 “지금 클릭이 먹는 그룹인가, 코어가 알아서 고르는 그룹인가”만 구분해도 실사용이 편해집니다.
화면에 DIRECT·REJECT 같은 특수 항목이 보이면, “우회 없이 나간다/차단한다”는 뜻으로 받아들이면 됩니다. 특정 사이트가 열리지 않을 때 실수로 REJECT 계열 규칙을 탄 것은 아닌지, 혹은 DIRECT로 나가 로컬 DNS가 막힌 것은 아닌지 로그로 확인합니다. 규칙 전반의 감을 잡으려면 규칙 라우팅 모범 사례를 함께 보는 것이 좋습니다.
수동 노드 전환: 어느 그룹을 건드려야 체감이 바뀌나
수동 노드 선택은 “트래픽이 실제로 지나가는 그룹”을 골라야 의미가 있습니다. 이름에 Proxy·节点选择·Select·manual 비슷한 단어가 붙은 selector를 우선 눌러 보세요. 반대로 AUTO·自动·url-test 류는 클릭해도 곧 코어가 덮어쓸 수 있습니다. 어떤 구독은 최종 출구를 한 번 더 중첩해서, 바깥 그룹만 바꿔서는 안 바뀐 것처럼 느껴질 수 있습니다—이때는 연결 로그에 찍힌 체인을 함께 봅니다.
Windows에서 브라우저와 게임이 다른 경로를 탄다면, 브라우저 쪽 확장 프로그램 프록시나 앱 자체 프록시 설정이 겹쳤는지도 확인합니다. Verge Rev가 시스템 프록시를 켜 두었는데 앱이 직접 연결만 사용하면 화면과 실사용이 어긋납니다. 이런 때는 TUN 모드를 검토하는 편이 나은 경우가 많습니다만, 회사 PC·다른 VPN과의 충돌은 항상 먼저 살핍니다.
글로벌·규칙·직접 연결: 모드와 그룹 선택의 관계
대부분의 클라이언트는 규칙 모드를 기본으로 두고, 특정 순간만 글로벌로 올려 모든 트래픽을 한 그룹으로 보내는 식으로 씁니다. 직접 연결(또는 comparable)은 우회를 끄고 로컬 회선으로만 나가게 하며, 문제를 “노드 vs 회선”으로 가를 때 유용합니다. UI에서 모드를 바꿔도 반응이 없다면, 다른 앱이 시스템 프록시를 다시 덮어쓰는지, 혹은 관리자 권한 없이 TUN이 반쯤만 켜진 상태인지 점검합니다.
초보 사용자에게 가장 비싼 실수는 “글로벌 모드에 놓아 두고 규칙 파일을 정성껏 유지하는 것”입니다. 테스트할 때는 잠깐 켜도 되지만, 평소에는 규칙으로 두고 selector 그룹만 전환하는 편이 안전합니다. 예외는 테스트·특정 앱만 빠르게 확인할 때입니다.
자주 막히는 증상: 전부 timeout, 한 노드만 느림, 화면과 실제 불일치
모든 노드 timeout: 먼저 인터넷 자체가 살아 있는지, 시스템 시간이 맞는지, 다른 VPN/보안 툴이 가로막는지 확인합니다. 이어서 구독 자동 갱신과 만료 여부를 보고, 프로필을 다시 동기화합니다. 한 노드만 유난히 큰 숫자: 원격 서버·특정 프로토콜 조합 문제일 수 있어 인근 지역 후보로 바꿔 재현을 봅니다.
화면은 빠른데 체감은 느림: 브라우저 캐시·DNS·대상 CDN 지역·앱 자체 우회 설정을 의심합니다. 이때 연결 로그에 찍힌 SNI와 체인이 UI에서 고른 그룹과 같은지 몇 줄만 대조하면 원인이 갈립니다. 지연은 낮은데 로딩만 길다: 측정 URL과 실제 콘텐츠 서버가 다른 경우가 많습니다. 이건 지연 수치만으로는 판단이 어려워, 노드 바꿔 A/B 정도가 필요합니다.
대응 순서 요약(메모용)1) 프로필 동기화 → 2) 일괄 지연 재측정 → 3) selector 그룹에서 후보 전환
→ 4) 연결 로그로 도메인 경로 확인 → 5) 필요 시 모드·TUN 재점검자주 묻는 질문
Q1. “원클릭”이 구독 전체를 다 고치나요?
아니요. 지연 측정은 측정과 선택을 돕는 UI 동작이지, 공급자 서버나 규칙 파일을 원격으로 수정하지 않습니다. 체감이 변하려면 측정 뒤 실제로 어떤 그룹·노드를 택했는지가 중요합니다.
Q2. 가장 낮은 ms인데 왜 영상은 끊김 없이 안 나오나요?
측정은 종종 가벼운 객체를 대상으로 하고, 스트리밍은 지역·CDN·혼잡에 더 민감합니다. 지연과 대역·지역 일치는 별개입니다. 필요하면 같은 노드로 브라우저와 문제 앱을 동시에 시험해 보세요.
Q3. 정책 그룹 이름이 너무 많을 때 최소한만 보고 싶어요.
우선 selector형 그룹과, 화면 상단에서 바꿀 수 있는 모드(규칙/글로벌)부터 고정합니다. 나머지 url-test형은 “자동”으로 두고, 로그로 이탈이 있을 때만 만집니다. 공급자 문서에 권장 순서가 있으면 그 순서를 따르는 것이 가장 빠릅니다.
Q4. Windows 업데이트 직후 UI만 이상해졌어요.
가상 어댑터·방화벽 프로필이 리셋되는 일이 있습니다. 클라이언트를 한 번 종료 후 재실행하고, TUN·시스템 프록시 토글을 순서대로 다시 맞추면 회복되는 경우가 많습니다. 반복되면 WinTun·보안 소프트웨어 예외를 다시 확인합니다.
맺음말
Windows 11에서 Clash Verge Rev를 쓸 때 검색이 갈리는 지점은 “설치”와 “YAML 깊이” 사이의 일상 조작입니다. 이 글은 그 틈을 메우기 위해 그래픽 화면만으로 지연 측정을 돌리고, 정책 그룹의 역할을 읽으며, 수동 노드를 안전하게 고르는 순서를 정리했습니다. 반복해서 빠르게 적응하려면, 한 번은 느리게라도 “프로필 동기화 → 일괄 측정 → selector 전환 → 로그 대조”를 같은 세트로 연습해 두는 것이 좋습니다.
물론 생태계에는 화면은 단순해 보이지만 내부 규칙을 숨기거나, 구독 편집을 까다롭게 만드는 클라이언트도 있습니다. 업데이트가 늦으면 Meta 계열 변화를 따라가지 못하고, 로그·정책 패널이 약하면 “측정은 됐는데 왜 이 도메인만 이상하지?”를 홀로 풀기 어렵습니다. Clash V.CORE는 규칙·구독·연결 흐름을 한 제품 맥락에서 정리하려는 방향과 맞닿아 있어, 화면에서 고른 선택이 로그와도 잘 맞물리는 경험을 중시합니다. 지금 환경에서 노드만 자주 갈아끼운다면, 다음은 다운로드 페이지에서 클라이언트를 고정하고 동일한 조작 습관을 유지해 보시길 권합니다—설치 글·정책 글·이 글이 서로 다른 검색 의도를 이어 주는 삼각 편이 될 것입니다.