Clash Verge Rev 코어 업데이트가 막힐 때
Windows·macOS에서 Mihomo(verge-mihomo) 수동 교체하기

1 자동 코어 업데이트가 실패할 때 흔한 배경

Clash Verge Rev는 UI 뒤에서 Mihomo(구 Clash Meta) 엔진을 verge-mihomo·verge-mihomo-alpha 같은 이름의 사이드카 바이너리로 실행합니다. 앱이 GitHub 등에서 새 코어를 받아 오지 못하면 «다운로드 실패»·«업데이트 오류»만 뜨고 끝나는데, 원인은 단순히 노드 품질만이 아닙니다. 회사 프록시·SSL 검사가 중간에서 끊는 경우, 백신이 임시 폴더의 실행 파일을 격리하는 경우, 혹은 사용자 계정이 Program Files 아래 파일을 덮어쓸 권한이 없는 경우가 대표적입니다. 또 완전 오프라인 환경에서는 애초에 자동 채널이 의미가 없으므로, IT 정책상 허용된 경로로 미리 받아 둔 패키지를 수동으로 맞추는 편이 현실적입니다.

이 글의 목표는 «최신 기능을 무조건 쓴다»가 아니라, 지금 설치된 클라이언트가 실제로 어떤 경로의 어떤 파일을 실행 중인지를 사용자 눈으로 확인하고, 그 파일만 교체해도 동일한 UI에서 다시 기동할 수 있게 하는 것입니다. 구성 데이터는 보통 %APPDATA% 또는 macOS의 Application Support 아래 io.github.clash-verge-rev.clash-verge-rev 트리에 있으므로, 코어 바이너리만 바꿔도 프로필·구독은 그대로인 경우가 많습니다. 백업·이전에 대한 전체 그림은 백업·이전 가이드와 함께 두면 안전합니다.

2 가장 먼저: 서비스 로그에서 bin_path 읽기

수동 교체 전에 해야 할 일은 추측으로 경로를 적는 것이 아니라, 이미 성공적으로 한 번이라도 뜬 코어가 어디를 가리키는지 로그로 고정하는 것입니다. Verge Rev는 서비스 모드나 일반 모드에서 기동할 때 start service 한 줄에 JSON 형태로 bin_path, config_dir, core_type을 남기는 경우가 많습니다. Windows에서는 %APPDATA%\io.github.clash-verge-rev.clash-verge-rev\logs\service\ 아래 날짜별 로그, macOS에서는 ~/Library/Application Support/io.github.clash-verge-rev.clash-verge-rev/logs/service/ 쪽을 연 뒤 bin_path 문자열을 검색해 보세요.

여기서 얻은 경로가 곧 덮어써야 할 실행 파일의 전체 경로입니다. 예를 들어 Windows 일반 설치에서는 C:\Program Files\Clash Verge\verge-mihomo.exe 또는 Alpha 채널의 verge-mihomo-alpha.exe로 잡히는 사례가 흔하고, macOS에서는 /Applications/Clash Verge.app/Contents/MacOS/verge-mihomo 또는 verge-mihomo-alpha처럼 앱 번들의 Contents/MacOS 아래에 놓인 바이너리를 가리키는 경우가 많습니다. 로그가 없다면 앱 설정의 앱 디렉터리 열기·진단 메뉴를 활용해 실제 구성이 쓰는 홈 경로부터 역추적합니다.

start service
bin_path
core_type
verge-mihomo

3 Windows: 표준 설치에서의 코어 위치와 교체 순서

Microsoft Store가 아닌 일반 설치형을 썼다면, 코어는 종종 설치 루트에 놓입니다. 커뮤니티 로그에서 반복적으로 보이는 패턴은 C:\Program Files\Clash Verge\verge-mihomo.exe와 verge-mihomo-alpha.exe 두 종입니다. 작업 전에 트레이에서 Clash Verge Rev를 완전히 종료하고, 작업 관리자에 verge-mihomo·clash-verge·관련 서비스 프로세스가 남아 있지 않은지 확인합니다. 파일이 잠겨 있으면 복사가 0바이트로 끝나거나 손상된 실행 파일이 남을 수 있으므로, 반드시 프로세스가 사라진 뒤에 덮어씁니다.

안전을 위해 기존 .exe를 같은 폴더에 verge-mihomo.exe.bak-20260414처럼 날짜를 붙여 복사해 두세요. 새 파일은 동일한 파일 이름으로 두어야 앱이 그대로 찾습니다. Alpha와 Stable을 바꿔 쓰는 설정이라면, 지금 UI에서 선택한 채널과 로그의 core_type이 가리키는 파일이 일치하는지 함께 확인합니다. Program Files 아래 쓰기가 막히면 탐색기를 관리자 권한으로 열거나, 한 단계 위 폴더 권한을 점검해야 합니다.

C:\Program Files\Clash Verge\verge-mihomo.exe
C:\Program Files\Clash Verge\verge-mihomo-alpha.exe

zip 기반 포터블 배포는 설치 루트가 사용자 지정일 수 있습니다. 이 경우 로그의 bin_path가 D:\Tools\Clash.Verge\verge-mihomo.exe처럼 나오기도 하니, 위 예시 경로에 집착하지 말고 본인 환경 값을 따르세요. Windows 전체 설치 흐름은 Windows 설치 튜토리얼과 맞물려 있습니다.

4 Windows 서비스 모드·TUN과 파일 잠금

서비스 모드로 코어를 띄우면, 일반 종료만으로는 서비스 프로세스가 남아 파일 핸들을 붙잡는 경우가 있습니다. 이때는 Verge UI에서 서비스 중지·코어 중지를 명시적으로 시도한 뒤, 여전히 남으면 작업 관리자에서 해당 이미지 이름을 종료하거나, 신중하게 서비스 콘솔에서 중지하는 절차가 필요합니다. TUN·시스템 프록시 관련 도우미 실행 파일이 같은 폴더의 resources에 함께 있는 배포도 있으므로, 코어만 교체하고 다른 파일은 건드리지 않는 편이 업데이트 실패를 줄입니다.

백신·EDR이 verge-mihomo.exe를 행동 탐지로 격리하면, 자동 업데이트도 수동 복사도 같은 이유로 막힙니다. 예외 경로를 허용할 수 있는지 보안 정책 담당자와 조율하고, 격리함에 잡힌 파일이 있다면 복구 후 다시 시도하세요. 회사 네트워크에서 GitHub 릴리스 자체가 차단되었다면, 허가된 내부 미러에서 동일 버전의 아티팩트를 받아 오프라인으로 복사하는 방식이 유일한 해법인 경우가 많습니다.

5 macOS: Clash Verge.app 안의 사이드카 바이너리

macOS에서는 코어가 앱 번들 내부에 붙어 나오는 경우가 많습니다. 로그 예시로 자주 등장하는 형태는 /Applications/Clash Verge.app/Contents/MacOS/verge-mihomo 및 verge-mihomo-alpha입니다. 교체 절차는 Windows와 같이 앱 완전 종료 → 프로세스 소멸 확인 → 기존 바이너리 백업 → 동일 이름으로 교체 → 앱 재실행 순입니다. Finder에서 앱 아이콘을 우클릭해 «패키지 내용 보기»로 들어가 Contents/MacOS까지 이동할 수 있습니다.

번들 내부 실행 파일을 사용자가 덮어쓰면 코드 서명 관점에서 앱 무결성 검사나 Gatekeeper 동작이 달라질 수 있습니다. 공식 패키지에 포함된 바이너리와 동일 출처의 파일을 쓰거나, 가능하면 앱 전체를 신뢰할 수 있는 채널에서 재설치해 코어를 함께 맞추는 방법이 더 안전한 경우도 있습니다. 그럼에도 불구하고 폐쇄망에서 반드시 파일 단위로 올려야 한다면, 교체 후 첫 실행에서 차단 메시지가 나오는지 확인하고, 조직 정책에 맞게 notarize·서명된 배포물만 사용하세요.

지리 데이터(Country.mmdb, geoip.dat 등)는 로그상 /Applications/Clash Verge.app/Contents/Resources/resources/에서 사용자 데이터 쪽으로 복사·동기화되는 흔적이 함께 찍히기도 합니다. 코어 문제와 지오 데이터 문제를 섞어 해석하면 원인 추적이 꼬이므로, 규칙 오판만 있다면 GeoIP·Geosite 수동 갱신 글을 별도로 참고하세요. Mac 기본 설치 절차는 macOS 설치 가이드에 정리되어 있습니다.

/Applications/Clash Verge.app/Contents/MacOS/verge-mihomo
/Applications/Clash Verge.app/Contents/MacOS/verge-mihomo-alpha

6 교체용 바이너리는 어디서 가져오나

실무에서는 두 가지 축이 있습니다. 하나는 Clash Verge Rev 자체 릴리스 패키지에서 동일 버전의 앱을 받아, 그 안에 포함된 사이드카를 추출해 기존 설치에 맞추는 방식입니다. 다른 하나는 상위 Mihomo 프로젝트가 배포하는 플랫폼별 바이너리를 받아, 파일 이름을 verge-mihomo 계열로 맞추어 넣는 방식입니다. 후자는 커뮤니티에서 오래 쓰여 왔지만, 빌드 플래그·버전 조합에 따라 GUI가 기대하는 기능과 미세하게 어긋날 여지가 있으므로, 가능하면 앱 제작자가 같은 파이프라인으로 올린 코어를 우선합니다.

아키텍처를 반드시 맞추세요. Windows 64비트 PC는 amd64, Apple Silicon Mac은 arm64, Intel Mac은 amd64 macOS 빌드가 각각 다릅니다. 잘못된 아키텍처를 넣으면 실행 단계에서 바로 실패하며, 이는 프록시 규칙 문제가 아니라 순수 바이너리 호환성 문제입니다. Alpha 채널을 켠 상태라면 Stable 바이너리 이름으로 덮어쓰는 실수가 흔하니, UI에서 선택한 채널·로그의 core_type·실제 파일 이름을 한 줄에 적어 두고 작업하면 혼선이 줄어듭니다.

오픈 소스 릴리스 페이지·이슈 트래커는 신뢰와 변경 이력을 확인하는 데 유용하지만, 일상적인 설치 패키지의 첫 진입점으로는 사이트의 다운로드 허브를 쓰는 편이 버전 관리에 유리합니다. 코어 원본만 따로 받아야 할 때는 공식 Mihomo 저장소의 릴리스 자산을 참고하되, 실행 파일 출처를 항상 기록해 두세요.

7 교체 후 버전 검증과 재시작 루틴

파일을 바꾼 뒤에는 곧바로 대형 구독 갱신을 돌리기보다, 앱을 다시 켜서 코어가 기동하는지와 설정 화면에 표시되는 코어 버전 문자열이 기대와 일치하는지부터 확인합니다. Windows에서는 PowerShell이나 명령 프롬프트에서 교체한 실행 파일에 -v 같은 버전 플래그를 지원한다면(빌드에 따라 다름) 직접 출력을 볼 수도 있습니다. macOS는 터미널에서 동일하게 전체 경로를 지정해 실행해 볼 수 있으나, Gatekeeper 경고가 뜰 수 있으니 조직 맥락에 맞게 진행하세요.

그다음 단계에서 시스템 프록시나 TUN을 켠 상태로 간단한 사이트 접속·지연 테스트를 해 보고, 로그에 이전에 보이던 다운로드 오류가 사라졌는지 확인합니다. 문제가 지속되면 코어가 아니라 구독 URL·DNS·규칙 쪽으로 시선을 옮겨야 하므로, TUN 모드 가이드와 DNS 관련 문서를 함께 보는 것이 좋습니다. 재시작 순서는 «UI 종료 → (서비스 중지) → 바이너리 교체 → 앱 시작 → 코어 기동 로그 확인»으로 고정해 두면 다음번에도 같은 실수를 줄일 수 있습니다.

8 코어와 지오 데이터 문제를 분리하기

사용자는 «업데이트가 안 된다»고 말하지만 실제로는 geoip.dat·Country.mmdb 같은 지오 데이터만 오래된 경우가 많습니다. 이때는 코어 exe를 여러 번 바꿔도 GEOIP 규칙이 계속 엇나갑니다. 앱 로그에 geodata 로더 모드나 파일 경로가 찍히므로, 코어 교체와 별도로 어떤 복사본을 읽는지 추적하세요. 수동으로 지오 파일을 맞추는 절차는 GeoIP·Geosite 수동 업데이트 글의 흐름을 따르면 됩니다.

반대로 지오 데이터는 최신인데 특정 프로토콜만 깨진다면 코어 버전이 실제로 낮아서 새 트랜스포트를 이해하지 못하는 경우도 있습니다. 이때는 로그의 코어 버전과 공급자 문서가 요구하는 최소 버전을 비교해 보세요. 두 축—바이너리와 데이터—을 표로 나누어 적으면, 불필요한 재설치 루프에서 벗어나기 쉽습니다.

9 자주 묻는 질문

• 자동 업데이트만 실패하고 예전 코어는 돌아갑니다: 네트워크·권한 이슈일 가능성이 큽니다. 로그에 TLS 오류·타임아웃이 있는지 먼저 보고, 수동으로 동일 버전 파일을 넣어 재현성을 확보하세요.
• 교체 후 앱이 아예 안 뜹니다: 잘못된 아키텍처·0바이트 파일·불완전 복사를 의심합니다. 백업 파일 이름을 되돌려 복구한 뒤 다시 시도합니다.
• Alpha와 Stable을 왔다 갔다 합니다: 파일 이름 쌍이 각각 따로 있으므로, UI에서 고른 채널과 실제 덮어쓴 파일이 짝이 맞는지 확인합니다.
• macOS에서 수정 후 보안 경고가 납니다: 번들 무결성이 바뀌었기 때문일 수 있습니다. 조직 정책에 맞게 공식 패키지 재설치를 검토하세요.

10 정리

Clash Verge Rev에서 Mihomo 코어 자동 업데이트가 막혀도, 할 일은 단순합니다. 로그의 bin_path로 실제 실행 파일을 확인하고, Windows에서는 Program Files 또는 포터블 루트의 verge-mihomo*.exe, macOS에서는 Clash Verge.app/Contents/MacOS/ 아래 사이드카를 끄고 교체한 뒤 버전을 검증합니다. 서비스 모드·백신·코드 서명 같은 주변 요소만 정리되면 같은 절차는 오프라인 환경에서도 반복할 수 있습니다. 규칙 덮어쓰기·구독 유지보수는 mixin·구독 오버라이드 같은 다른 글과 역할이 나뉘므로, 이 문서는 «엔진 파일」에만 집중했습니다.

상용 VPN 앱이 한 번에 해 주는 업데이트를 Clash 계열에서도 비슷하게 느끼려면, GUI가 안정적으로 유지보수되는지·코어를 얼마나 빨리 따라가는지가 중요합니다. Verge Rev는 그 균형이 잘 잡힌 편이라, 이번에 손본 수동 절차는 특수한 망에서만 간헐적으로 필요할 뿐 평소에는 자동 채널로 충분한 경우가 많습니다. 다만 한 번 경로와 백업 습관을 익혀 두면 장애 시 복구 시간이 확 줄어듭니다.

→ Clash 무료 다운로드로 최신 클라이언트를 맞춘 뒤 코어를 다시 동기화해 보세요