왜 Clash Verge Rev인가

Clash Verge Rev는 Clash·Mihomo 코어를 감싼 크로스 플랫폼 GUI 클라이언트로, 구독 프로필 관리·프록시 그룹 전환·규칙 보기·연결 로그·TUN 모드까지 한 화면에서 다루기 쉽게 정리되어 있습니다. 단순히 “노드만 바꾸는 VPN”과 달리 rules 기반으로 국내 트래픽은 직접 연결·해외만 원하는 노드로 보내는 분할 라우팅을 구현할 때 유리합니다. Windows·macOS·Linux 모두에서 비슷한 작업 흐름을 유지할 수 있어, 한 기기에서 익숙해지면 다른 OS로 옮겨도 적응 비용이 적습니다.

이 글에서는 깨끗한 설치와 덮어쓰기 업데이트, 구독 URL을 통한 프로필 가져오기, 구성 파일 안의 프록시 그룹(Selector·URL-TEST·Fallback 등) 이해, 그리고 브라우저를 넘어 터미널·일부 데스크톱 앱까지 같은 정책을 쓰기 위한 TUN 전체 흐름을 순서대로 짚습니다. 버전마다 메뉴 명칭은 조금씩 다를 수 있으나, “프로필 → 그룹 선택 → 시스템 프록시 또는 TUN → 검증”이라는 축은 동일합니다.

다운로드, 설치, 덮어쓰기 업데이트

Windows·macOS·Linux에서 설치 방식 개요

Windows에서는 일반적으로 설치 패키지(MSI/EXE 등 배포 형식은 시기별로 다름)를 내려받아 안내에 따라 진행합니다. 이미 오래된 Verge가 있다면 그 위에 새 버전을 덮어 설치해도 대부분 구성 폴더는 유지되지만, 메이저 업데이트 전에는 profiles 폴더나 내보낸 YAML을 백업해 두면 마음이 편합니다. 설치 중 보안 소프트웨어가 실행 파일을 격리하면 TUN 드라이버·가상 어댑터 단계에서 막히므로, 예외 처리 또는 일시 중지가 필요할 수 있습니다.

macOS는 보통 .dmg 또는 패키지 설치 후, 첫 실행에서 개발자 서명·보안 관련 팝업이 뜹니다. 시스템 설정의 개인정보 보호에서 앱을 허용하거나, 공식 빌드인지 확인한 뒤 “열기”로 첫 실행을 완료하세요. 이후 단계에서 네트워크 확장·프록시·필터 권한을 요청하면 반드시 허용해야 시스템 프록시와 TUN이 실제 트래픽에 적용됩니다. 권한을 건너뛰면 메뉴에는 “켜짐”으로 보여도 일부 앱은 여전히 직접 연결될 수 있습니다.

Linux는 배포판에 따라 .AppImage·.deb·AUR 등 형태가 다양합니다. GUI가 없는 최소 설치라면 의존성·트레이 아이콘·PolicyKit(루트 없이 TUN을 허용하는 경우)을 확인하세요. Wayland·특정 데스크톱 환경에서는 트레이가 보이지 않아 “앱이 안 뜬다”로 오인하기 쉬우니, 프로세스 목록으로 실행 여부를 함께 확인하는 것이 좋습니다.

Mihomo 코어와 데이터 디렉터리

Verge Rev는 내부적으로 Clash 호환 Mihomo 코어를 사용하는 것이 일반적입니다. UI에서 보이는 “코어 버전” “프로필 경로”는 트러블슈팅 시 첫 확인 포인트입니다. 구독을 새로 고쳐도 노드가 비면, UI에 표시된 작업 디렉터리 안에 캐시된 원시 구독·로컬 YAML이 제대로 쓰이고 있는지, 다른 프로필을 가리키고 있지는 않은지 살펴보세요. 수동 편집을 했다면 문법 오류 한 줄이 전체 로드를 막을 수 있으니, 편집 후에는 반드시 유효성 검사(또는 로그의 parse error)를 확인합니다.

구독 링크와 프로필 가져오기

대부분의 상용·자체 호스팅 서비스는 사용자에게 Clash 형식 구독 URL을 제공합니다. Verge Rev에서는 보통 프로필 또는 서브스크립션·프로바이더 입력란에 URL을 붙여 넣고 새로고침·다운로드 버튼을 누릅니다. 자동 갱신 간격이 있다면 너무 짧게 두지 말고, 서비스 정책에 맞는 주기(예: 수 시간~하루)를 권장합니다. 과도한 폴링은 서버와 클라이언트 모두에 부담입니다.

구독이 수입되면 화면에 프록시 노드 목록과 함께, YAML 안의 proxy-groups·rules가 채워집니다. “링크는 맞는데 노드가 비었다”면 다음을 순서대로 점검합니다. 첫째, URL이 https://로 정상 응답하는지 브라우저나 curl -I로 확인합니다. 둘째, 회사·캠퍼스망에서 해당 도메인이 차단됐는지 봅니다. 셋째, Base64 원시 목록만 제공되는 서비스라면 Clash용 변환 URL이 따로 있는지 문서를 확인합니다. 넷째, 클라이언트 로그에 TLS·DNS 오류가 있는지 읽습니다.

프록시 그룹 이해하기: Selector, URL-TEST, Fallback

Clash 설정에서 프록시 그룹은 “여러 노드·다른 그룹을 묶어 정책 이름으로 노출하는 레이어”입니다. 사용자는 보통 상위 두세 단계의 이름만 바꿔도 국내·해외·스트리밍 전용 등으로 나눈 구성을 쓸 수 있습니다.

Selector는 사용자가 UI에서 하나를 고르는 수동 선택형입니다. “지금은 이 일본 노드”처럼 의도가 명확할 때 좋습니다. URL-TEST(또는 지연 테스트 유형)은 주기적으로 지연 시간을 재어 가장 빠른 노드로 바꿉니다. 네트워크 상태가 자주 바뀌는 환경에서 편하지만, 테스트 대상 URL·간격 설정이 잘못되면 엉뚱한 노드가 선택되기도 합니다. Fallback은 순서대로 죽었는지 검사하며 백업 라인을 쓰는 패턴에 가깝습니다. 제공자가 만든 기본 프로필마다 이름과 중첩 구조가 다르므로, “내가 바꿔야 할 핵심 그룹이 무엇인지” 한 번만 브리핑해 두면 이후 조작이 빨라집니다.

규칙(rules:)에서는 이러한 그룹 이름을 참조합니다. 예를 들어 GEOIP,CN,DIRECT 뒤에 해외 도메인을 PROXY 그룹으로 보내는 식입니다. 그룹을 바꿔도 규칙이 기대와 다르면 매칭 순서·Rule Provider 로딩 여부·DNS 모드를 함께 봐야 합니다. TUN을 켠다고 해서 규칙 품질이 자동으로 좋아지지는 않습니다. TUN은 트래픽을 코어로 가져오는 배관이고, 어느 노드로 보낼지는 여전히 규칙·그룹이 결정합니다.

연결 모드: 규칙·글로벌과 시스템 프록시

처음에는 규칙(Rule) 모드를 기본으로 두고, “국내는 직통·해외만 프록시” 같은 프로필을 쓰는 경우가 많습니다. 글로벌(Global)은 단순하지만 국내 사이트까지 전부 원격 노드를 타 느려질 수 있으니, 장기적으로는 규칙 기반을 익히는 편이 낫습니다. Verge Rev에서 시스템 프록시(System Proxy)를 켜면 OS에 HTTP(S) 프록시 힌트가 등록되고, 이를 존중하는 브라우저·일부 앱은 자동으로 로컬 혼합 포트로 붙습니다.

그러나 앞선 TUN 관련 글에서도 강조했듯, 터미널·많은 CLI·일부 게임은 시스템 프록시를 무시합니다. 그럴 때 필요한 것이 다음 절의 TUN입니다. 운영 관점에서는 “브라우저만 우선 확인 → 괜찮으면 시스템 프록시 유지, CLI까지 필요하면 TUN” 순서가 안전합니다.

TUN 모드 전체 흐름

TUN은 가상 네트워크 인터페이스를 만들어, 대부분의 TCP·UDP가 Clash 코어의 규칙·프록시 그룹을 거치도록 합니다. Verge Rev 설정에서 TUN 관련 토글을 켠 뒤, OS별로 요구되는 절차를 완료해야 합니다.

Windows

최초 TUN 활성화 시 UAC(관리자 권한)와 가상 어댑터 설치가 필요한 경우가 많습니다. 팝업을 건너뛰면 TUN이 불완전하게 동작합니다. Windows 방화벽이 Clash 실행 파일의 네트워크를 막고 있지 않은지, 다른 “전체 트래픽 VPN”과 라우팅이 충돌하지 않는지도 확인하세요. 회사 보안 에이전트가 필터 드라이버를 깔면 TUN과 싸울 수 있으니, 그런 환경에서는 IT 정책이 우선입니다.

macOS

네트워크 확장 승인이 빠지면 메뉴상 “프록시 사용 중”과 실제 패킷 경로가 어긋날 수 있습니다. 시스템 설정에서 관련 확장을 허용하고 비밀번호·지문 인증을 완료하세요. Apple Silicon·Intel 모두 동일하게 권한 플로우가 이어집니다.

Linux

배포판에 따라 tun 장치 권한·라우팅·nftables/iptables 연동을 수동으로 맞춰야 할 수 있습니다. GUI 패키지가 PolicyKit으로 루트 없이 TUN을 띄우기도 하지만, 실패하면 로그에 권한·모듈 오류가 남습니다.

TUN과 DNS 스택

TUN만 켠 채 DNS가 여전히 ISP 쪽으로 새 나가면, 도메인 기반 규칙이 기대와 다르게 매칭될 수 있습니다. Verge Rev와 코어 설정의 DNS 섹션(fake-ip·redir-host 등)을 프로필 작성자의 의도에 맞게 유지하세요. 문제가 생기면 “일단 TUN 끄고 시스템 프록시만으로 재현되는지”로 범위를 좁힐 수 있습니다.

검증과 트러블슈팅

연결이 잡혔는지는 클라이언트의 연결 목록·로그에서 가장 빨리 확인합니다. 어떤 규칙에 매칭됐는지, 어느 그룹·노드로 나갔는지를 보면 “왜 이 사이트만 안 되지?” 같은 질문에 답이 빨리 나옵니다. 간단한 검증으로는 브라우저에서 IP 확인 페이지를 열거나, 터미널에서 아래와 같은 명령을 쓸 수 있습니다(환경에 맞게 엔드포인트를 바꾸세요).

# 출구 공인 IP 확인 예시
curl -s https://api.ipify.org

# 응답 헤더만 빠르게 확인
curl -sI --max-time 15 https://www.example.com

지연이 튀면 지연 테스트 그룹의 테스트 URL·선택된 노드·해당 시간대의 패킷 손실을 함께 봅니다. 무엇보다 백업 프로필을 하나 두면, 실험적 YAML을 넣다가 망가져도 금방 되돌릴 수 있습니다.

자주 묻는 질문

Q. 시스템 프록시와 TUN을 동시에 켜도 되나요? 최신 클라이언트는 둘 다 켤 수 있는 경우가 많지만, 라우팅이 이중으로 겹치면 이상 증상이 날 수 있습니다. 문제가 있으면 한쪽만 켜 보세요.

Q. 구독을 바꿨는데 규칙이 이상해졌어요. 새 프로필이 다른 그룹 이름·Rule Provider를 쓰면 기존 습관과 충돌합니다. UI에서 활성 프로필이 무엇인지, 수동 편집 내용이 덮어써졌는지 확인하세요.

Q. 게임·음성 채팅만 끊겨요. UDP·특정 포트를 노드 정책이 막았거나, NAT 유형이 맞지 않을 수 있습니다. 전역이 아닌 규칙에서 해당 앱이 DIRECT로 나가게 할지, 별도 노드 그룹을 쓸지 프로필 설계를 조정해야 합니다.

정리: GUI·규칙·TUN을 한 흐름으로

범용 소비자 VPN 앱은 전체 트래픽을 한 스위치로 보내기 쉽지만, 국내 주민에게는 국내 서비스까지 느려지는 비용이 자주 따릅니다. 반면 일부 구형·비공개 빌드는 코어 업데이트가 멈춘 채 남아 최신 프로토콜·Rule Provider·대체 전송을 따라가기 어렵습니다. Clash·Mihomo 생태계에서는 Verge Rev 같은 클라이언트가 구독·그룹·규칙 편집·TUN을 묶어 주므로, “브라우저와 터미널이 같은 정책”이라는 개발·업무 시나리오에도 잘 맞습니다.

이 글의 순서대로 설치 → 구독 → 그룹·모드 → 시스템 프록시 확인 → 필요 시 TUN을 밟으면, 같은 구독이라도 디버깅 시간을 크게 줄일 수 있습니다. 아래 링크에서 OS에 맞는 Clash 계열 클라이언트를 받아, 프로필과 규칙을 손에 익혀 보시기 바랍니다.

Clash 클라이언트 무료 다운로드 →