이 글이 맞는 독자

Windows 11 노트북이나 데스크톱을 준비했고, 검색창에 «클래시 버지 레브 설치 방법», «Clash Verge Rev 다운로드», «윈11 UAC 프록시 앱»처럼 쳐서 들어온 경우가 대표적입니다. GUI 없이 커맨드만 익숙한 사용자라면 이 글은 다소 장황할 수 있습니다. 반대로 터미널 경험이 적고 «일단 화면에 노드 이름이 나오면 된다»는 수준이면 방향이 정확히 맞습니다. 이미 YAML을 손으로 짜는 단계라면 규칙·정책 그룹 글과 짝을 이루는 보조 자료로 쓰면 됩니다.

Clash 계열 앱은 이름이 비슷한 포크가 많습니다. 이 글에서 말하는 Clash Verge Rev는 활발히 유지되는 Verge 계열 가지 중 하나로, 저장소·릴리스 페이지의 공지를 기준으로 버전 확인 습관을 들이는 것이 중요합니다. 지금 읽는 시점의 정확한 다운로드 URL은 문서에 박아 두기보다 공식 채널을 여는 편이 낫습니다.

먼저 기억할 한 줄 설치 파일 출처가 맞고, 구독 링크가 살아 있으며, 방화벽이 로컬 루프백 포트를 막지 않는 세 가지가 맞으면 대부분 «첫 실행에서 노드가 보이는 상태»까지 갈 수 있습니다.

Clash Verge Rev와 Mihomo를 한 번에 이해하기

Clash Verge Rev는 앞단의 그래픽 인터페이스이고, 실제로 TCP·UDP를 어떻게 흘려보낼지 결정하는 엔진은 보통 Mihomo(구 Clash Meta 계열, 커뮤니티에서 Meta 코어라고 부르는 축)입니다. 예전 «Clash for Windows» 같은 이름과 헷갈리기 쉬운데, 지금 시점에 새로 설치하는 사용자는 Meta/Mihomo 계열 코어가 규칙 문법·프로토콜 지원 면에서 유리한 경우가 많습니다. 그래서 Verge Rev처럼 코어 업데이트를 메뉴 몇 번으로 처리할 수 있는 클라이언트가 검색량도 함께 붙는 패턴입니다.

GUI는 구독 URL을 넣고, 받아온 proxies 목록에서 노드를 고르고, 시스템 프록시나 TUN 스위치를 켜는 일을 시각화합니다. 반대 말로, 구독 자체가 깨졌거나 노드 서버가 모두 응답하지 않으면 화면이 아무리 화려해도 «전부 타임아웃」으로 끝납니다. 그런 증상은 설치 문제가 아니라 출구 품질·규칙 문제에 가깝습니다. 코어만 최신으로 올리고 싶다면 Meta·Mihomo 코어 업그레이드 글의 절차와도 연결됩니다.

Windows 11에서 설치 전에 손볼 것

관리자 계정이 아니라도 일반 사용자로 설치 자체는 되는 경우가 많지만, 나중에 TUN 가상 어댑터를 켤 때는 승격이 필요해 UAC 창을 자주 보게 됩니다. 회사나 학교 장비라면 정책상 가상 어댑터나 시스템 프록시 조작이 막혀 있을 수 있으니, 설치 전에 IT 가이드를 확인하는 편이 시간을 아낍니다.

백신·엔드포인트 제품은 «행위 기반 차단»에서 방금 받은 설치 파일을 한동안 격리하는 일이 있습니다. 이때는 격리 로그에 찍힌 근거와 파일 해시를 확인하고, 공식 릴리스 페이지의 동일 버전과 대조하세요. 임의의 집계 사이트에서 내려받은 미러는 체크섬 검증이 어려운 경우가 많아 피하는 것이 좋습니다.

이미 다른 VPN이나 필터 드라이버가 올라와 있다면 TUN을 켤 때 라우팅이 겹칩니다. 우선 Verge Rev만 단독으로 켜서 재현하는 것이 원인 분리에 유리하고, 공존이 필요하면 TUN·시스템 프록시 종합 가이드에서 «전체 단절» 절차를 참고하는 편이 안전합니다.

공식 채널에서 Windows 설치 패키지 받기

가장 확실한 방법은 프로젝트의 GitHub Releases 페이지에서 .exe 설치형이나 .msi 패키지를 고르는 것입니다. 자산 목록에 여러 파일이 있을 때는 CPU 아키텍처(대부분의 최신 PC는 x64)에 맞는 항목을 고릅니다. ARM 기기라면 arm64 빌드가 분리되어 있는지 릴리스 노트를 읽어야 합니다.

브라우저가 「자주 받은 파일」 정도로만 표시하고 서명 정보를 잘 보여 주지 않을 때가 있으므로, 파일을 받은 뒤 속성 대화상자의 디지털 서명 탭에서 발행자 이름을 확인하는 습관이 좋습니다. 서명이 없거나 발행자가 엉뚱하면 공식 빌드가 아닐 가능성을 의심해야 합니다. 릴리스 페이지 외의 직접 링크는 북마크만으로 재방문하기보다 검색으로 매번 공식 저장소를 여는 편이 안전합니다.

winget으로 같은 빌드를 설치하는 방법

winget은 Windows 패키지 관리자로, 매니페스트가 공식 릴리스를 가리키면 사용자 입장에선 한 줄로 재현 가능한 설치가 됩니다. PowerShell이나 터미널에서 winget search verge처럼 검색해 퍼블리셔패키지 ID가 프로젝트와 일치하는지 먼저 확인하세요. 커뮤니티에 올라온 예시 명령을 그대로 복사하기보다, 자기 PC에서 검색 결과를 보고 고르는 습관이 중요합니다.

winget 설치 후 버전은 winget list로 확인할 수 있고, 앱 내부의 «정보» 화면에 표시되는 버전 문자열과 맞는지 대조하면 업데이트가 꼬였는지 빠르게 알 수 있습니다. 조직 단위로 패키지 캐시를 거치는 경우에는 내부 프록시나 TLS 검사 때문에 다운로드가 실패할 수 있으니, 그때는 IT에 예외 경로를 요청해야 합니다.

주의 패키지 ID가 비슷한 이름으로 여러 개 나오면, 스타 수가 아니라 공식 게시자명·프로젝트 URL로 가려야 합니다. 잘못 고르면 광고성 번들이 섞인 비공식 빌드를 설치할 위험이 있습니다.

설치 마법사와 UAC 동작

설치 마법사는 대부분 «사용자별 설치 vs 전체 사용자 설치», «시작 메뉴 바로가기», «자동 실행» 같은 옵션을 묻습니다. 처음에는 기본값으로 설치한 뒤에 동작을 확인하고, 필요하면 재설치로 옵션을 바꿔도 늦지 않습니다. 전체 사용자 설치를 고르면 이후 UAC 빈도가 늘 수 있지만, 여러 Windows 계정에서 같은 앱을 쓰려는 가정이면 합리적입니다.

사용자 계정 컨트롤(UAC) 창은 설치 프로그램이 시스템 폴더나 서비스 등록처럼 민감한 영역을 건드릴 때 뜹니다. 여기서 발행자가 신뢰할 만한지 확인하는 것이 첫 방어막입니다. “발행자를 알 수 없음” 상태에서 무조건 승인하는 습관은 다른 앱에서도 폭넓은 피해로 이어질 수 있습니다.

첫 실행: 스마트 스크린·Defender와의 만남

처음 executable을 실행하면 Microsoft Defender의 스마트 스크린이 “잘 알려지지 않은 앱”이라며 막는 경우가 있습니다. 이때는 무작정 ‘실행’을 누르기보다 발행자·파일 출처를 다시 확인하세요. Verge 계열은 오픈소스 커뮤니티에서 빠르게 버전이 바뀌기 때문에, 상용 소프트웨어보다 평판 점수가 낮게 찍히는 현상이 종종 있습니다. “추가 정보”를 눌러 상세 패널에서 서명·버전을 보는 것이 안전한 순서입니다.

실행 직후 방화벽 프롬프트가 뜨면, 로컬 루프백과 원격 대역에 대한 접근 범위를 신중히 고릅니다. 불필요하게 «공용 네트워크에서 허용»까지 켜 두면 카페 와이파이 같은 환경에서 공격 면적이 넓어질 수 있습니다. 우선 «개인 네트워크» 범위만 허용하고, 필요할 때만 범위를 넓히는 편이 좋습니다.

구독 URL로 프로필 가져오기

서비스 제공자가 준 구독 링크를 Verge Rev의 프로필·구독 입력란에 붙여 넣고 새로고침합니다. 대부분의 경우 원격 서버가 YAML 또는 Base64로 인코딩된 구성을 돌려주고, 클라이언트가 이를 파싱해 노드 목록을 채웁니다. 링크에 토큰이 포함돼 있다면 다른 사람과 공유하지 말고, 노트 앱에 평문으로 장기 저장하는 것도 피하세요.

«자동 업데이트» 주기를 너무 짧게 잡으면 공급자 측에서 빈도 제한을 걸어 403·429 응답을 돌려줄 수 있습니다. 반대로 너무 길게 잡으면 서버에서 노드를 내렸을 때 화면과 실제가 어긋납니다. 기본값이 있으면 그것부터 쓰고, 문제가 생기면 간격을 조정하는 방식이 보수적입니다. 갱신 실패 패턴 전체는 구독 자동 업데이트 문제 해결 글에 정리되어 있습니다.

클립보드에서 규칙 덩어리를 바로 붙여 넣는 흐름을 지원한다면, 그 내용이 신뢰할 수 있는지 더 엄격히 봐야 합니다. 타인이 준 «테스트용 설정」에 external-controller가 열려 있거나 의심스러운 스크립트 다운로드가 섞여 있으면 그대로 실행하지 마세요.

Mihomo 코어와 내장 업데이터

Verge Rev는 대개 앱 번들 안에 Mihomo 바이너리를 들고 있거나, 실행 시 최신 채널에서 내려받습니다. 설정 화면에서 코어 버전릴리시 채널(stable vs prerelease)을 확인하고, 릴리스 노트에 호환성 경고가 없는지 읽습니다. 베타 채널은 새 프로토콜을 빨리 쓰고 싶을 때 유용하지만, 규칙 호환 문제로 갑자기 기존 프로필이 깨질 수도 있습니다.

수동으로 코어 파일만 교체하는 고급 시나리오는 초보 단계에서 필수는 아닙니다. 다만 장기 사용자는 GitHub의 Meta/Mihomo 릴리스와 앱 내 업데이터가 서로 다른 타이밍을 가질 수 있다는 점만 기억해 두면, «업데이트를 눌렀는데도 특정 프로토콜이 없다»는 질문에 빠르게 답할 수 있습니다.

시스템 프록시부터: TUN은 다음 과제로 미루기

처음 연결을 확인할 때는 시스템 프록시만 켜고 시작하는 편이 단순합니다. Verge Rev에서 토글을 켠 뒤 Windows 설정 앱의 네트워크 및 인터넷 > 프록시 화면에 127.0.0.1과 앱이 안내한 포트가 찍히는지 확인하세요. Chrome·Edge 같은 브라우저는 기본적으로 이 경로를 따라가므로 지역 테스트 사이트만 열어도 노드 전환이 반영되는지 볼 수 있습니다.

TUN 모드는 가상 NIC와 라우팅을 통해 앱이 시스템 프록시를 무시하는 경우에도 트래픽을 끌고 오는 데 유리합니다. 다만 드라이버 설치·UAC·다른 VPN과의 충돌 이슈가 커져 «설치 직후 첫 과제»로는 부담이 큽니다. TUN을 켠 뒤 전체 인터넷이 끊기면 우선 TUN부터 끄고 복구하는 흐름을 외워 두세요. 자세한 점검 순서는 TUN 종합 가이드가 본문입니다.

Microsoft Store 앱이나 일부 UWP만 트래픽이 이상하면 UWP·localhost 루프백 이슈일 수 있습니다. 이 경우 시스템 프록시만으로는 부족하고 TUN이나 별도 예외가 필요할 때가 많습니다. 설치 직후에는 데스크톱 브라우저부터 정상인지 가르는 것이 디버깅 속도를 올립니다.

연결 검증과 간단 체크리스트

노드를 바꾼 뒤에는 같은 탭을 새로고침하기보다 시크릿 창을 열어 캐시·확장 영향을 줄입니다. 지역 표시 페이지를 볼 때는 DNS와 IP가 서로 다른 지역으로 보이는 DNS 누설 패턴이 없는지 함께 봅니다. Fake-IP 모드를 쓰는 프로필이라면 내부 사이트가 열리지 않는 부작용이 있을 수 있으니 Fake-IP vs Redir-Host 글의 표를 참고하세요.

로그 창에서 특정 도메인이 DIRECT로만 나온다면, 구독이 아니라 규칙 쪽을 의심합니다. 반대로 프록시 그룹을 타는데 지연만 크다면 노드 품질·UDP 지원 여부·지역 혼잡이 원인일 때가 많습니다. 첫 설치 단계에서 규칙을 대대적으로 고치기보다, 기본 프로필이 의도대로 작동하는지부터 확인하는 편이 스트레스가 적습니다.

자주 막히는 지점과 바로 옆 문서

구독은 받아지는데 노드가 전부 빨간불이면 Ping RTT 표시가 오해를 부를 수 있습니다. 실제 애플리케이션 트래픽은 다른 프로토콜·포트를 쓰므로, 브라우저에서 실 사이트를 열어 확인하세요. 회사 SSL 검사 장비가 중간에 끼면 TLS 핸드셰이크 단계에서만 실패하는 경우도 있어, 같은 증상은 TLS·SNI 문제 해결 글과 맞물립니다.

Windows 방화벽에서 로컬 포트 인바운드를 막아 두면 브라우저가 프록시에 연결 자체를 못 합니다. 다른 PC에서 이 PC의 Clash 포트를 쓰는 시나리오까지 염두에 둔다면 LAN 공유·방화벽 글도 같이 읽는 것이 좋습니다. 잘못 연 기기만 공격 면이 넓어질 수 있으니 «필요한 범위까지만» 여는 원칙을 지키세요.

개발 도구까지 같이 쓸 계획이면 터미널 프록시 환경 변수(`HTTP_PROXY` 등)와 Clash 포트를 맞추는 별도 절차가 필요합니다. WSL2 환경에서는 WSL2·Windows Clash 연동 글이 직접적인 연장선입니다.

자주 묻는 질문

winget으로 설치한 Clash Verge Rev는 공식 파일과 동일한가요?

winget 매니페스트가 공식 릴리스 자산을 그대로 가리키면 바이너리가 같습니다. 패키지 ID·퍼블리셔 필드를 항상 확인하고, 의심스러운 동복 이름이 있으면 설치를 멈추세요.

UAC 창이 자주 뜨는데 정상인가요?

설치 직후나 TUN·서비스 등록 시에만 제한적으로 뜨는 것이 보통입니다. 평상시 웹 서핑마다 반복된다면 실행 파일과 자동 실행 항목을 점검해야 합니다.

구독은 살아 있는데 노드 목록이 비어요.

파싱 오류·인코딩 문제·중간 필터의 응답 변조 가능성을 봅니다. 앱 로그와 브라우저에서 같은 URL을 연 결과를 비교하면 원인이 빨리 좁혀집니다.

Mihomo와 예전 Premium 코어를 섞어 쓸 수 있나요?

한 클라이언트 프로세스 안에서 무작정 섞기보다 Verge Rev가 로드하는 단일 코어 버전을 기준으로 두는 편이 안전합니다. 실험이 필요하면 테스트 VM을 분리하세요.

정리와 다음 단계

지금까지의 흐름을 따르면 «윈11에 Clash Verge Rev를 깔고, 공식·winget 출처를 검증하며, UAC와 스마트 스크린을 통과한 뒤 구독 URLMihomo 기반 노드까지 띄우는」 최소 루프를 완성할 수 있습니다. 이후에는 규칙 커스터마이징·TUN·DNS 모드 등 난이도를 한 단계씩 올리면 됩니다.

한편 이름만 비슷한 구형 클라이언트나 업데이트가 끊긴 포크는 설치 화면은 단순해 보여도 코어가 예전이라 최신 프로토콜·보안 패치를 따라오지 못하는 case가 많습니다. 설정 파일 포맷이 들쭉날쭉하면 커뮤니티 자료와도 안 맞아 검색만 해도 시간을 잃기 쉽습니다. ClashNote가 여러 포크를 비교해 안정적인 빌드 채널과 한국어 설치·트러블슈팅 글을 한곳에 모아 두었기 때문에, Clash Verge Rev처럼 지금 활발히 관리되는 GUI와 Mihomo 조합을 기준 축으로 잡으면 앞으로 같은 증상을 다시 만났을 때도 주변 문서로 바로 연결됩니다. 무료 클라이언트라도 출처 검증·구독 보안은 직접 책임져야 하니, 습관만큼은 상용 제품 못지않게 잡아 두는 것이 장기적으로 가장 경제적입니다.

설치가 끝났다면 YAML·정책 그룹·규칙 순서까지 손대고 싶은지, 아니면 기본 프로필만으로 스트리밍·업무 트래픽을 나눌지 로드맵을 정하세요. 규칙 전반이 궁금하면 앞서 인용한 YAML 가이드로 넘어가면 흐름이 끊기지 않습니다.

Clash 무료 다운로드 페이지에서 Windows용 추천 클라이언트와 릴리스 채널을 한 번에 확인한 뒤, 오늘 설명한 순서대로 Verge Rev를 맞춰 보세요.