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

이 글은 9월 17일의 사전 출시 버전을 다룹니다. 공식 GHSA-99qg-xv7m-jf4v는 Windows 서비스 <= 2.5.4를 영향 범위로 지정하고 수정 빌드를 v2.5.4+autobuild.0908.bbab52d로 명시합니다. Windows 사용자는 v2.5.2 서비스를 안전한 복구 수단으로 삼아서는 안 됩니다.

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 변경을 각각 기록하세요. 포터블 모드를 없애고 시스템 앱 데이터 디렉터리로 통합하는 이전도 확인해야 합니다. 전체 백업이 있고 데스크톱 연결을 검증하며 즉시 되돌릴 수 있을 때만 테스트하고 유일한 일상 환경을 바로 덮어쓰지 마세요.

시스템 프록시 상태 오류, 서비스 모드 시간 초과, Windows system/mixed TUN의 트래픽 미처리 문제를 해결 중이거나 포터블 모드 이전을 검증해야 한다면 현재 공식 릴리스와 보안 권고를 먼저 확인한 후 백업을 갖춘 상태에서 테스트하세요.

2026년 9월 17일 기준 v2.5.4-rc와 AutoBuild는 모두 사전 출시 버전이었고, 당시 v2.5.2가 최신 안정 버전이었습니다. 이는 과거의 출시 상태이지 현재 설치 권고가 아닙니다. 9월 22일에 v2.5.5 정식 버전이 출시되었지만 Windows 서비스 위험은 GHSA의 수정 빌드와도 대조해야 합니다.

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

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

Service IPC는 이후 %ProgramData%에 임시 저장되는 코어에 방화벽 규칙을 추가했으며, v2.5.4-rc 릴리스 노트에도 이 수정이 포함되어 있습니다. 해당 태그의 Cargo.toml은 Service IPC 의존성 v2.7.1을 사용합니다. 이는 백그라운드 구성 요소의 의존성 버전이며 설치할 클라이언트 버전이 아닙니다.

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

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

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

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

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

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

이전 버전을 아직 열 수 있을 때 현재 Profile 이름, 구독 출처, 덮어쓰기와 스크립트, 시스템 프록시, TUN, 서비스 모드와 포트를 기록하세요. 이전 프로그램 옆의 데이터 디렉터리와 공식 시스템 앱 데이터 디렉터리를 모두 보관하세요.

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

일반적인 Windows 기기는 x64, ARM Windows는 arm64를 선택하세요. WebView2가 없고 설치할 수도 없거나 일반 패키지로 화면을 열 수 없는 경우에만 파일 이름에 fixed_webview2가 포함된 대용량 버전을 고려하세요.

macOS에서는 Apple 칩과 Intel을 구분하고, Linux에서는 배포판 패키지 형식과 CPU 아키텍처를 모두 맞춰야 합니다.

설치 전에 배포 파일명과 다운로드 시각을 저장하세요. 서드파티 ‘포터블 재패키징’이나 검색 광고의 동명 설치 파일을 사용하지 말고, 안정 버전과 RC의 리소스 디렉터리를 섞지 마세요. 운영 환경이 하나뿐이라면 먼저 전체 데이터 백업과 영향받는 Windows 서비스에 의존하지 않는 연결 복구 경로를 준비하세요.

이전 버전을 완전히 종료해 두 UI나 코어가 같은 데이터 디렉터리를 동시에 수정하지 않게 합니다.

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

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

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

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

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

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

Windows에서는 전체 빌드, 설치 출처, 실제 서비스 구성 요소에 GHSA 수정 증거가 있을 때만 서비스 모드와 TUN을 테스트하세요. 증거가 부족하면 서비스를 중지하고 시스템 프록시만 검증하세요. 기존 문제가 system 또는 mixed 스택에서 발생했다면 안전 조건을 충족한 뒤 원래 스택으로 다시 테스트하세요.

테스트 중 같은 노드와 대상을 유지하고 gVisor, DNS, 포트, 덮어쓰기를 함께 변경하지 마세요. macOS, Linux는 기존 권한 승인 절차에 따라 우회 규칙과 서비스 로그를 확인하고 이전 권한 오류가 계속 나타나지 않는지 확인하세요.

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

시스템과 Clash Verge Rev를 재시작하고 업데이트 전과 같은 Profile, 노드, HTTPS 대상으로 시작과 시스템 프록시를 검증하세요. Windows 서비스 모드와 TUN은 전체 빌드와 실제 서비스 모두에 GHSA 수정 증거가 있을 때만 검증하고 그렇지 않으면 중지 상태로 유지하세요. macOS, Linux는 기존 권한 승인 절차를 따르세요.

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

테스트 중에는 이전 포터블 디렉터리나 업데이트 전 백업을 삭제하지 말고 영향받는 Windows 구버전 서비스를 다시 켜지도 마세요. 최소한 한 번 재시작하고 프록시를 끈 뒤 직접 연결이 복구되는지 확인한 후 현재 빌드를 계속 사용할지 결정하세요.

AutoBuild 테스트에 성공해도 정식 버전에서 같은 조건으로 이전과 네트워크 복구를 다시 확인해야 합니다.

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

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

오류가 발생했을 때의 데이터 디렉터리 사본을 저장한 뒤 신뢰할 수 있는 전체 구성 백업을 보관하세요. Windows에서 <= 2.5.4의 이전 서비스를 다시 설치하거나 켜서는 안 됩니다. 해당 서비스에 의존하지 않는 시스템 프록시나 다른 신뢰할 수 있는 클라이언트로 필요한 연결을 복구한 뒤 GHSA에 명시된 수정 빌드를 확인하세요.

복구 후에는 Profile과 실제 HTTPS 요청부터 확인하세요. 설치 출처, 전체 빌드 번호, 실제 서비스 구성 요소에 대한 수정 증거를 모두 확보한 경우에만 서비스 모드와 TUN을 다시 켜세요. 증거가 부족하면 중지 상태를 유지하고 오류를 유지 관리자에게 알리세요.