Clash Verge Rev v2.5.4-rc로 업그레이드해야 할까요?

Clash Verge Rev v2.5.4-rc는 2026년 9월 17일 19:36(Asia/Shanghai)에 공개되었으며 GitHub Release에 Pre-release로 명시되어 있습니다. 같은 시점에도 프로젝트의 Latest 안정 버전은 v2.5.2입니다. v2.5.4라는 버전 번호가 보인다고 해서 이미 정식 버전을 대체한 것은 아닙니다.

이번 RC와 롤링 AutoBuild에는 시스템 프록시, 서비스 모드, 구독 편집, 노드 선택, 포트 충돌 회피, TUN 관련 수정 사항이 여러 개 포함되었으며 포터블 모드는 제거되고 시스템 앱 데이터 디렉터리로 통합되었습니다. 전체 백업을 보관하고 데스크톱 네트워크를 검증할 수 있으며 즉시 롤백할 수 있는 사용자에게 적합합니다. 단지 버전 번호가 더 크다는 이유로 일상적으로 쓰는 유일한 환경을 바로 덮어쓰려는 사용자에게는 적합하지 않습니다.

현재 v2.5.2가 정상이고 Release 설명의 특정 수정 사항을 검증할 필요가 없다면 안정 버전을 계속 사용하는 것도 완전한 선택입니다. 시스템 프록시 전환 실패 후 UI 상태가 잘못 표시되거나, 서비스 모드 작업이 시간 초과되거나, Windows system/mixed TUN이 트래픽을 처리하지 못하거나, 포터블 모드 마이그레이션을 미리 검증해야 한다면 롤백 시간을 확보한 테스트를 진행하세요.

Release 설명에는 많은 수정 사항이 나열되어 있지만 업그레이드 전에는 자신이 재현할 수 있는 목표 하나만 선택해야 합니다. 예를 들어 시스템 프록시 전환 실패 후 UI 상태가 잘못 표시된다면 스위치 상태, 실제 시스템 프록시 값, 실제 요청 하나를 기록하세요. 서비스 모드 작업이 시간 초과된다면 첫 번째 오류와 이후 작업에서도 이상이 계속되는지 기록하세요.

최근 issue #7915의 범위는 매우 좁습니다. Windows 서비스 모드의 특정 v2.5.4 AutoBuild에서 system 또는 mixed TUN 스택을 사용할 때 트래픽이 흐르지 않았고, gVisor는 정상이며 v2.5.2로 롤백하면 복구되었습니다.

이후 Service IPC는 %ProgramData%에 임시 저장된 코어에 대한 방화벽 규칙을 보완했고, 메인 저장소는 이 수정이 포함된 2.7.0으로 업그레이드되었습니다. v2.5.4-rc의 Release 설명에도 이 수정 사항이 포함되어 있습니다.

그렇다고 모든 TUN 무트래픽 문제가 방화벽 때문이라는 뜻은 아니며 사용자가 Windows 방화벽을 수동으로 꺼서도 안 됩니다. 버전, Windows 서비스 모드, 스택 차이, 무트래픽 현상이 모두 일치할 때만 RC로 업그레이드할 근거 중 하나로 삼으세요.

포터블 모드 사용자의 첫 번째 목표는 네트워크 검증이 아니라 설정을 어디에서 읽는지 확인하는 것입니다. v2.5.4는 포터블 모드를 제거하고 시스템 앱 데이터 디렉터리로 통합한다고 명시합니다. 기존 설치가 프로그램 주변, Scoop 디렉터리 또는 사용자 지정 위치에 데이터를 저장했다면 이전 디렉터리를 먼저 찾아 별도로 보관해야 합니다.

Scoop은 공식 문서에 나온 커뮤니티 유지 관리 배포 방식입니다. 문서에는 설정 디렉터리를 바꾸거나 포터블 환경이 필요할 때 사용할 수 있다고 되어 있지만 프로젝트는 하위 배포 채널 문제를 지원하지 않는다고도 명시합니다. 이는 v2.5.4 앱의 ‘포터블 모드 제거’와 동일한 보장이 아닙니다. Scoop을 사용한다면 Scoop 자체의 영구 보관 디렉터리와 업그레이드 동작도 확인해야 합니다.

먼저 Clash Verge Rev를 완전히 종료하고 트레이 프로세스와 서비스 작업이 끝났는지 확인한 뒤 앱 데이터 디렉터리를 복사하세요.

공식 개인정보 보호 문서에는 Windows 디렉터리가 %APPDATA%\io.github.clash-verge-rev.clash-verge-rev, macOS 디렉터리가 ~/Library/Application Support/io.github.clash-verge-rev.clash-verge-rev로 나와 있습니다.

Linux는 $XDG_DATA_HOME/io.github.clash-verge-rev.clash-verge-rev 경로를 사용하며 일반적으로 ~/.local/share에 있습니다.

디렉터리의 verge.yaml, config.yaml, profiles.yaml, profiles/는 설정, 구독, Profile을 복구하는 데 중요합니다. logs/, service-logs/, cache.db, Geo 데이터도 비교에 도움이 되지만 설정을 빠뜨린 채 로그만 저장해서는 안 됩니다.

백업은 앱 작업 디렉터리 밖에 저장하고 시스템, 아키텍처, 기존 버전, 시간을 표시해야 합니다. verge.yaml에는 WebDAV 주소, 사용자 이름, 비밀번호가 평문으로 저장될 수 있고 Profile에는 구독 token, 노드 비밀번호, UUID가 포함될 수 있습니다. 원본 백업을 공개 클라우드 드라이브에 업로드하거나 Issue에 바로 첨부하지 마세요.

v2.5.4 Release 설명은 ‘포터블 모드 제거 및 시스템 앱 데이터 디렉터리 통합’만 확인할 뿐 모든 서드파티 포터블 패키지나 사용자 지정 디렉터리를 자동으로 찾는다고 보장하지 않습니다. 따라서 기존 파일을 먼저 삭제하지 말고, 자동으로 기존 설정을 읽을 것이라고 기대하며 새 프로그램을 이전 프로그램 디렉터리에 바로 압축 해제하지 마세요.

이전 버전을 아직 열 수 있을 때 현재 Profile 이름, 구독 출처, 오버라이드와 스크립트, 시스템 프록시, TUN, 서비스 모드, 포트를 먼저 기록하세요. 그런 다음 이전 프로그램 주변의 데이터 디렉터리와 공식 시스템 앱 데이터 디렉터리를 모두 백업합니다. RC를 설치한 후에는 새 시스템 데이터 디렉터리를 생성해 사용하게 한 뒤 앱이 제공하는 가져오기 또는 백업 복원 기능으로 복원하세요.

수동으로만 복원할 수 있다면 새 버전을 먼저 종료하고 방금 생성된 디렉터리의 사본을 보관한 뒤 백업한 전체 설정 파일 모음을 한 번에 복사하세요. profiles.yaml 하나만 고르거나 profiles/만 복사하거나 서로 다른 버전의 verge.yaml을 섞지 마세요. 이 파일들의 참조 관계와 현재 선택 상태가 서로 맞지 않을 수 있습니다.

Clash Verge Rev 공식 문서에 따르면 현재 프로젝트는 GitHub Release를 통해서만 배포됩니다. v2.5.4-rc를 테스트할 때는 해당 RC의 공식 Release를 열고 페이지에 Pre-release 표시가 있는지, 대상 커밋이 c7ffb212인지 확인하세요. 게시 시각과 자산 파일명을 기록한 뒤 시스템과 아키텍처에 맞는 자산을 선택합니다.

일반적인 Windows 기기는 보통 x64를 선택하고 ARM Windows는 arm64를 선택합니다. 시스템에 WebView2가 없고 설치할 수도 없거나 일반 패키지로 UI가 열리지 않을 때만 파일명에 fix_webview2가 포함된 대용량 버전을 고려하세요. macOS에서는 Apple 칩과 Intel을 구분하고, Linux에서는 배포판 패키지 형식과 CPU 아키텍처를 모두 맞춰야 합니다.

설치 전 자산 파일명과 다운로드 시간을 저장하세요. 서드파티 ‘포터블 버전’을 사용하거나 검색 광고에서 동명 설치 파일을 받지 말고, 안정 버전과 RC의 리소스 디렉터리를 섞지 마세요. 운영 환경이 하나뿐이라면 테스트 설치를 시작하기 전에 공식 v2.5.2 설치 파일과 전체 데이터 백업을 준비해야 합니다.

v2.5.4 Release의 첫머리에는 중요한 안내가 있습니다. 서비스 모드에서는 설정 디렉터리의 규칙 집합과 프록시 집합 파일이 캐시 사본일 뿐이라 수동으로 수정해도 실행 중인 코어에 반영되지 않습니다. 직접 유지 관리할 파일은 서비스가 생성한 캐시를 계속 편집하지 말고 설정에서 type: file을 사용해야 합니다.

이번 AutoBuild에는 서비스 모드의 다중 사용자 격리와 기존 서비스 업그레이드 마이그레이션도 추가되었고, 작업 시간 초과 후에도 오류가 계속되거나 상태가 비정상인 문제도 수정되었습니다. 업그레이드 후에는 UI에서 서비스 설치 상태와 현재 사용자를 먼저 확인한 뒤 앱 로그와 service-logs를 점검하세요. 이전 캐시가 남아 있다는 이유만으로 새 코어가 수동 수정 내용을 불러왔다고 판단하지 마세요.

기존 설정이 provider 캐시의 수동 수정에 의존한다면 먼저 백업을 복원하고, 실제로 유지 관리해야 하는 규칙 집합이나 프록시 집합을 명시적인 로컬 file provider로 바꾸세요. 한 번에 파일 하나만 마이그레이션하고, 다시 불러온 뒤 연결 기록이나 규칙 일치 결과로 검증해 서비스 마이그레이션, provider 마이그레이션, 구독 업데이트를 동시에 진행하지 않도록 합니다.

Profile을 복원한 뒤 TUN을 먼저 끄고 시스템 프록시만 켜세요. 같은 노드로 실제 HTTPS 요청을 한 번 수행하고 Connections에서 대상, 규칙, 아웃바운드를 확인합니다. 그런 다음 시스템 프록시를 끄고 운영체제의 프록시 상태도 함께 복원되는지 확인하세요. 이 단계는 Release 설명에 나온 시스템 프록시 상태 및 복원 수정 사항을 검증하기 위한 것입니다.

시스템 프록시가 안정된 뒤 서비스를 설치하거나 업그레이드하고 TUN을 켜세요. Windows에서 기존 문제가 system 또는 mixed 스택에서만 발생했다면 동일한 노드와 테스트 대상으로 다시 확인합니다. gVisor, DNS, 포트, 오버라이드를 동시에 바꾸지 마세요. macOS와 Linux에서는 권한 부여 절차, 우회 규칙, 서비스 로그에 기존 권한 오류가 계속 나타나지 않는지를 중점적으로 확인합니다.

v2.5.4에는 TUN의 Mips 스택 옵션이 추가되었으며 Release에는 Mihomo v1.19.31 이상이 필요하다고 명시되어 있습니다. 이 코어 버전이 없거나 분명한 테스트 목적이 없다면 새 옵션이라는 이유만으로 스택을 바꾸지 마세요.

버전 번호가 맞고 UI가 열린다는 사실은 설치 완료만 증명할 뿐 마이그레이션 성공을 증명하지 않습니다. 시스템과 Clash Verge Rev를 한 번 다시 시작한 뒤 업그레이드 전에 저장한 동일한 Profile, 동일한 노드, 동일한 HTTPS 대상으로 앱 시작, 시스템 프록시, 서비스 모드, TUN을 차례로 검증하세요.

시스템 앱 데이터 디렉터리에 새 변경 사항이 실제로 저장되고, 재시작 후 Profile, 선택한 노드, 오버라이드, 포트가 이전 값으로 돌아가지 않는지도 확인하세요. 로컬 type: file 규칙 집합이나 프록시 집합을 사용할 때는 실행 설정이 서비스 캐시 사본이 아니라 원본 파일을 참조하는지도 확인해야 합니다.

테스트 중에는 기존 포터블 디렉터리, v2.5.2 설치 파일, 업그레이드 전 백업을 삭제하지 마세요. 최소 한 번의 재시작과 프록시를 끈 뒤 직접 연결이 복구되는 과정까지 완료한 후 RC를 계속 사용할지 결정하세요.

RC가 시작되지 않거나 설정 마이그레이션이 불완전하거나 시스템 프록시 또는 TUN에 새 회귀 문제가 생기면 먼저 TUN과 시스템 프록시를 끄고 앱을 완전히 종료한 뒤 운영체제가 직접 연결로 돌아왔는지 확인하세요. 비정상 상태에서 구독을 계속 업데이트하거나 데이터 디렉터리를 반복해서 덮어쓰지 마세요.

v2.5.4의 장애 현장 사본을 하나 보관한 뒤 공식 v2.5.2 설치 파일로 프로그램을 복원하고 업그레이드 전 전체 데이터 백업을 하나의 묶음으로 복원하세요. 실행 파일만 이전 버전으로 바꾸면서 새 버전이 일부 다시 쓴 설정을 계속 사용해서는 안 되며 새 리소스 파일과 이전 리소스 파일을 섞어서도 안 됩니다.

롤백 후 버전과 Profile을 먼저 확인한 다음 시스템 프록시, 서비스 모드, TUN 순서로 검증하세요. 기존 포터블 버전이 원래 안정적이었다면 이전 프로그램과 이전 데이터 디렉터리를 임시로 복원할 수 있지만 시스템 데이터 디렉터리와 분리해 두고 이후 정식 버전의 명확한 마이그레이션 안내를 기다리세요.

2026년 9월 17일 현재 v2.5.4-rc와 AutoBuild는 모두 Pre-release이며 v2.5.2가 여전히 Latest 안정 버전입니다. 이후에는 프로젝트의 정식 Release 페이지에서 새 안정 버전이 공개되었는지, 포터블 모드 제거와 데이터 디렉터리 안내가 유지되는지를 기준으로 판단하세요. Pre-release 버전 번호만 보고 정식 버전 공개일을 추측하지 마세요.

정식 버전이 나온 뒤에도 동일한 마이그레이션 검증을 한 번 수행해야 합니다. 전체 백업, 시스템 데이터 디렉터리 확인, Profile 복원, 시스템 프록시 테스트, 서비스 모드와 TUN 테스트, 마지막 롤백 검증 순서입니다. AutoBuild 테스트 성공이 정식 버전 재검증을 대신할 수는 없습니다.

문제를 제출해야 한다면 시스템, 아키텍처, 설치 채널, 이전 버전과 새 버전, 이전 데이터 디렉터리와 새 시스템 디렉터리, 첫 번째 관련 로그, 최소 재현 단계를 제공하세요. 공개 전에 구독 token, 노드 자격 증명, WebDAV 정보, 접속 도메인, 전체 로컬 경로를 삭제하세요.