누구를 위한 글인가: 설치 글·YAML 글과 어떻게 나뉘나
이미 Apple Silicon용 macOS 앱을 깔고 구독까지 반영한 사용자라면, 다음 단계는 “클라이언트 안에서 노드 품질을 숫자로 비교하고, 이름이 많은 프록시 그룹 중 실제 출구를 고르는 것”입니다. 검색 결과에는 예전 ClashX·타 클라이언트 스크린숏이 섞여 메뉴 이름만으로는 금방 어긋납니다. Clash Verge Rev는 빌드마다 아이콘 위치가 조금 달라도, 내부 축은 프로필(구독) → 프록시·노드 목록 → 정책(그룹) 패널 → 연결·로그로 이어집니다. 네이티브 ARM 빌드를 쓰면 Rosetta 없이 메인 창 반응이 안정적인 경우가 많습니다.
이 글은 그 일상 조작에만 초점을 둡니다. 설치·프로필 가져오기·첫 실행까지는 Apple Silicon Mac 설치·구독 글을 먼저 마친 뒤 읽는 것이 자연스럽습니다. “자동 최저 지연”, “예비 노드 체인”처럼 파일 깊이를 파고들려면 정책 그룹·url-test·fallback이 맞고, 여기서는 YAML 없이 화면에서 끝내는 검색 의도—지연 측정, 정책 그룹, 수동 노드—에 맞춥니다.
Verge Rev 화면에서 봐야 할 네 가지 축
혼란을 줄이기 위해 화면을 네 축으로 나눠 보면 이후 단계가 단순해집니다. 첫째, 프로필 축입니다. 여러 구독을 두었다면 “지금 활성인 JSON/YAML 세트가 무엇인지”가 모든 그룹·노드의 출처입니다. 둘째, 프록시(노드) 목록 축입니다. 개별 서버·릴레이의 지연과 상태가 여기에 모입니다. 셋째, 프록시 그룹(정책 그룹) 축입니다. selector처럼 사용자가 고르는 그룹과, url-test처럼 주기적으로 잰 뒤 고르는 그룹이 같은 패널에 올라옵니다. 넷째, 연결·로그 축입니다. “화면에서는 빠른데 실사용은 다르다”일 때 도메인이 어느 그룹으로 갔는지 확인하는 안전벨트입니다.
macOS에서는 메뉴 막대(상단)의 Clash Verge Rev 아이콘, 독(Dock)의 실행 중 아이콘, 또는 메인 창이 서로 짧게 이어져 있습니다. 어떤 빌드는 메뉴 쪽에 모드·시스템 프록시 토글을 몰아 두고, 어떤 빌드는 메인 창의 프록시 탭이 중심입니다. 핵심은 “메뉴가 아무리 짧게 보여도, 실제로 규칙에 탄 그룹 이름은 메인 창의 프록시·정책 패널과 맞아야 한다”는 점입니다. 한국어 UI로 바꿔도 구독이 영문으로 올린 그룹 이름은 그대로인 경우가 많으니, 이름 암기보다 selector냐 자동(url-test)이냐부터 구분하는 편이 낫습니다.
지연 측정이 말해 주는 것(그리고 말해 주지 않는 것)
지연 측정·원클릭 측정은 대개 작은 테스트 URL에 HTTP 요청을 보내 왕복 시간을 잽니다. 숫자가 낮을수록 “그 순간, 그 테스트 대상에 대한 응답이 빨랐다”는 뜻이지, 영상 재생 버퍼나 대용량 다운로드 속도까지 보장하지는 않습니다. 또 측정 서버 위치가 사용자와 멀면 밀리초가 부풀어 보일 수 있어, 상대 비교용으로 쓰는 것이 안전합니다. “내 회선 전체 품질”이 아니라 “이 프로필 안에서 지금 노드들이 서로 비해 어떤가”에 가깝습니다.
측정이 timeout이면 노드가 죽었거나, macOS 방화벽·콘텐츠 필터·Little Snitch류 앱이 막았거나, DNS가 틀어졌거나, 공급자 일시 장애일 수 있습니다. 모든 노드가 동시에 timeout이면 로컬 쪽(시스템 날짜·시간, 다른 VPN·프록시 중첩, iCloud 프라이빗 릴레이, 회사 MDM)을 의심합니다. 몇 개만 살아 있으면 살아 있는 항목으로 먼저 붙여 실사용·로그를 함께 보는 것이 빠릅니다.
원클릭·일괄 지연 측정 실행과 표 해석
실제 동작은 빌드에 따라 “프록시” 탭의 일괄 테스트 또는 각 행의 지연 재기, 그룹 단위 측정으로 나뉩니다. Apple Silicon에서도 표 논리는 같습니다. 목록에서 측정을 누르면 행 옆 ms가 갱신되고, 실패는 timeout·회색으로 보이는 경우가 많습니다. 측정을 너무 촘촘히 연타하면 공급자나 로컬 보안 소프트웨어가 이상 트래픽으로 분류할 수 있으니 수 초 이상 간격을 두세요. 배터리 절전·Wi-Fi 전원 관리 직후에는 숫자가 한 번 튀었다가 안정되기도 합니다.
숫자가 갑자기 튀는 경우는 절전 복귀, Time Machine 백업, 대용량 iCloud 동기화가 겹친 타이밍에서도 흔합니다. 반복이면 timeout·TLS 로그 가이드로 갈무리하세요. 회사망·캠퍼스망에서는 테스트 URL이 필터링될 수 있습니다. 측정이 전부 실패일 때는 허용된 네트워크에서 재확인하는 것이 안전합니다.
측정 후에 할 일(짧은 체크리스트)
- 같은 시간대에 두세 번 재측정해 재현되는지 본다.
- 빠르게 나온 노드로 바꾼 뒤 실제 접속(브라우저와 문제 앱 둘 다)을 확인한다.
- 여전히 느리면 어느 그룹을 바꿨는지와 연결 로그의 도메인이 같은지 대조한다.
정책 그룹 읽기: selector·url-test·fallback을 UI에서 구분
구독 작성자는 보통 여러 프록시 그룹을 올려 둡니다. UI에서 이름 옆이나 부가 설명으로 유형이 비치기도 하고, 아니면 동작으로 역추적해야 합니다. selector 스타일은 목록에서 하나를 사용자가 직접 고르는 형태입니다. url-test는 일정 주기로 후보를 재어 가장 낮은 지연 쪽으로 붙는 패턴입니다. fallback은 우선순위를 타고 내려가며 살아 있는 다음 후보를 쓰는 패턴으로 이해하면 UI에서 혼동이 줄어듭니다. 이 구분은 파일에서 읽을 때도 같지만, 이 글에서는 “지금 클릭이 먹는 그룹인가, 코어가 알아서 고르는 그룹인가”만 구분해도 실사용이 편해집니다.
화면에 DIRECT·REJECT 같은 특수 항목이 보이면, “우회 없이 나간다/차단한다”는 뜻으로 받아들이면 됩니다. 특정 사이트가 열리지 않을 때 실수로 REJECT 계열 규칙을 탄 것은 아닌지, 혹은 DIRECT로 나가 로컬 DNS가 막힌 것은 아닌지 로그로 확인합니다. 규칙 전반의 감을 잡으려면 규칙 라우팅 모범 사례를 함께 보는 것이 좋습니다.
수동 노드 전환: 어느 그룹을 건드려야 체감이 바뀌나
수동 노드 선택은 “트래픽이 실제로 지나가는 그룹”을 골라야 의미가 있습니다. 이름에 Proxy·节点选择·Select·manual 비슷한 단어가 붙은 selector를 우선 눌러 보세요. 반대로 AUTO·自动·url-test 류는 클릭해도 곧 코어가 덮어쓸 수 있습니다. 어떤 구독은 최종 출구를 한 번 더 중첩해서, 바깥 그룹만 바꿔서는 안 바뀐 것처럼 느껴질 수 있습니다—이때는 연결 로그에 찍힌 체인을 함께 봅니다.
macOS에서 브라우저는 시스템 프록시를 따르는데, 앱이 자체 프록시 설정만 쓰거나 직접 연결만 고집하면 화면과 실사용이 어긋납니다. App Store 밖 앱·Electron 앱은 특히 그런 경향이 있습니다. Verge Rev가 시스템 프록시를 켜 두었는지, 메뉴 막대에서 모드가 규칙인지 확인한 뒤에도 체감이 다르면 TUN(패킷을 잡는 쪽) 전환을 검토합니다. 다만 다른 VPN·기업 보안 클라이언트와 동시에 켜면 충돌이 나므로 TUN·시스템 확장 충돌 글 순서를 먼저 읽는 편이 안전합니다. 종료 후에도 프록시가 남아 인터넷이 끊기는 증상은 프록시 잔류·복구에서 정리합니다.
글로벌·규칙·직접 연결: 모드와 그룹 선택의 관계
대부분의 사용자는 일상적으로 규칙 모드를 쓰고, 디버깅·일시 확인에만 글로벌을 켭니다. 직접 연결은 우회를 끄고 테스트할 때 유용합니다. UI에서 모드를 바꿔도 반응이 없다면 시스템 설정 > 네트워크에 다른 VPN 프로필이 붙잡고 있지 않은지, Verge Rev의 시스템 프록시 토글이 상충하지 않는지 확인합니다. 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. macOS를 올린 뒤 측정만 전부 실패해요.
소프트웨어 업데이트 이후 시스템 확장·방화벽·VPN 프로필이 리셋되는 일이 있습니다. Verge Rev를 완전히 종료했다가 다시 켜고, TUN·시스템 프록시를 순서대로 맞춘 뒤 프로필을 한 번 동기화해 보세요. 특정 포트가 잡혀 있으면 혼합 포트 충돌 가이드도 함께 확인합니다.
맺음말
Apple Silicon Mac에서 Clash Verge Rev를 쓸 때 검색이 갈리는 지점은 “같은 클라이언트의 Windows 글”과 “구독 설치 글” 사이의 일상 조작입니다. 이 글은 메뉴 막대와 메인 창만으로 지연 측정을 돌리고, 정책 그룹을 읽으며, 수동 노드를 고르는 순서를 macOS 맥락에 맞춰 정리했습니다. 습관을 만들려면 “프로필 동기화 → 일괄 측정 → selector 전환 → 연결 로그 대조”를 한 세트로 몇 번 반복하는 것이 가장 빠릅니다.
클라이언트마다 화면은 비슷해 보여도 로그 깊이·업데이트 주기·문서 품질은 크게 다릅니다. 구버전 UI만 덩그러니 남아 있으면 Meta·mihomo 쪽 변화를 따라가기 어렵고, “측정은 됐는데 이 도메인만 이상”을 혼자 풀기 힘듭니다. Clash V.CORE는 규칙·구독·연결 흐름을 한 사이트에서 묶어 설명하려는 방향과 맞닿아 있어, 화면에서 고른 노드가 로그·문서와 함께 읽히는 경험을 중시합니다. 플랫폼을 넘나들며 같은 조작을 유지하고 싶다면 다운로드 페이지에서 클라이언트를 고정해 보세요—macOS 설치 글·Windows 지연 글·정책 그룹 심화가 서로 닿는 사각 편이 됩니다.