Clash Verge Rev 재시작 후 Profiles가 사라졌을 때: 설정 복구와 백업

이 글은 다음과 같은 명확한 증상만 다룹니다. Clash Verge Rev v2.5.2에 구독, 로컬 Profile 또는 전역 Merge/Script가 있었는데, 정상 종료하거나 시스템을 종료·재시작한 뒤 다시 열었을 때 설정 목록에 일부 항목만 남고 기존 오버라이드도 빈 템플릿으로 돌아가는 경우입니다.

공식 issue #7577에는 macOS 시작 시 Profile 파일 32개 중 30개가 삭제된 사례가 기록돼 있습니다. issue #7804에는 Fedora를 정상 종료한 뒤 다음 시작 시 파일 20개 중 18개가 삭제된 사례가 있으며, 후속 댓글에는 Windows와 macOS 사례도 나옵니다. 이 기록들은 구독 서비스가 모든 노드를 동시에 비운 것이 아니라 시작 단계의 고아 파일 정리를 가리킵니다.

먼저 앱 로그를 열어 Removed file, Profile 파일 정리 완료 메시지, 한 번의 시작 과정에서 비정상적으로 많은 파일이 삭제됐는지 확인하세요. 디스크에 Profile이 남아 있고 프록시 페이지만 비었다면 코어 통신부터 점검해야 합니다. 파일은 있지만 Invalid YAML 오류가 난다면 형식이나 필드를 먼저 수정하세요. 구독 하나만 업데이트에 실패하고 다른 Profile은 남아 있다면 앱 전체 백업을 바로 복원하지 마세요.

백업을 복원하면 아카이브의 config.yaml, verge.yaml, profiles.yaml 및 profiles 디렉터리가 앱 데이터 디렉터리에 다시 기록됩니다. 먼저 현재 디렉터리 전체와 clash-verge-rev-backup 하위 디렉터리를 다른 위치에 복사하세요.

현재 디렉터리가 이미 불완전해 보여도 먼저 복사본을 보관하세요. 잘못된 백업을 선택하거나 이전 설정이 새 변경 사항을 덮어썼을 때 원래 상태로 돌아갈 수 있습니다.

일반 설치에서는 보통 시스템 데이터 디렉터리 아래의 io.github.clash-verge-rev.clash-verge-rev 폴더에 데이터를 저장하고, 포터블 버전은 실행 파일 옆의 .config 디렉터리에 저장합니다. 위치가 확실하지 않다면 클라이언트 설정의 앱 디렉터리 열기 기능으로 확인하고, 이름이 비슷하다는 이유만으로 데이터를 삭제하지 마세요.

Clash Verge Rev v2.5.2의 로컬 백업은 앱 데이터 디렉터리 안의 clash-verge-rev-backup에 저장됩니다. 자동 백업 파일 이름에는 -auto-scheduled, -auto-merge 또는 -auto-script가 포함될 수 있습니다.

issue #7804의 제보자는 사흘 전 auto-script ZIP에서 전역 스크립트를 복구했습니다.

공식 v2.5.2 백업 구현은 profiles 디렉터리, config.yaml, verge.yaml, 선택적 DNS 설정 및 profiles.yaml을 하나의 ZIP에 저장합니다.

ZIP이 열린다는 이유만으로 바로 복원하지 마세요. 먼저 복사본을 만든 뒤 아카이브에 profiles.yaml과 profiles/가 모두 있는지 확인하고, 장애가 발생하기 전의 백업 중 가장 최신 시점을 선택하세요.

시스템 프록시와 TUN을 끈 상태에서 설정의 “백업 설정”을 열고, “로컬 백업” 아래에서 “기록 보기”를 선택하세요. 문제가 생기기 전 백업을 찾아 먼저 내보내기 버튼으로 별도 저장한 뒤, 복구를 클릭하고 확인하세요. 공식 UI는 복구가 끝나면 앱을 재시작합니다.

ZIP을 다른 위치로 옮겼다면 먼저 “백업 가져오기”를 사용해 사본을 로컬 백업 목록에 추가한 다음 기록에서 복구하세요. 실행 중인 앱 디렉터리에 ZIP을 직접 압축 해제하지 마세요. 내장 복구는 파일을 쓴 뒤 config, profiles, UI 설정을 다시 불러오지만, 수동 덮어쓰기는 디스크 파일과 메모리 상태를 어긋나게 만들기 쉽습니다.

사용 가능한 ZIP이 없다면 profiles.yaml 참조를 임의로 만들거나 무작위 파일명을 함부로 바꾸지 마세요. 저장해 둔 구독 URL로 원격 Profile을 다시 가져오세요. 직접 작성한 로컬 설정은 문제 발생 전에 복사해 둔 profiles 파일을 하나씩 확인하고, 새 로컬 Profile을 만든 뒤 내용을 붙여 넣어 클라이언트가 인덱스 관계를 다시 생성하게 하세요.

전역 Merge.yaml과 Script.js의 이전 사본이 남아 있다면 오프라인 사본에서 먼저 비교한 뒤 클라이언트의 전역 확장 편집 화면을 통해 복구하세요. 백업에 이전 내용이 없을 때만 다시 작성하세요. 키나 내부 도메인이 들어 있을 수 있는 전체 규칙을 공개 스크린샷만 보고 역추정하지 마세요.

구독 URL도 사라졌다면 브라우저 기록, 공개 로그 또는 다른 사람의 설정에서 token을 짜 맞추지 말고 원래 서비스 제공자에게서 다시 발급받거나 재설정하세요. 한 출처를 복구할 때마다 상태를 한 번씩 저장해야, 모든 내용을 한꺼번에 가져온 뒤 어느 단계에서 문제가 생겼는지 알 수 없는 상황을 피할 수 있습니다.

앱이 재시작돼도 TUN을 바로 켜지 마세요. Profile 수, 이름, 유형, 현재 선택된 항목을 확인한 다음 Merge와 Script를 각각 열어 핵심 규칙이 빈 템플릿이 아닌지 확인하세요. 원격 구독은 수동으로 업데이트할 수 있어야 하고, 로컬 Profile은 설정 검증을 통과해야 합니다.

그다음 정상 동작이 확인된 노드 하나를 고정하고 시스템 프록시만 켠 상태에서 실제 HTTPS 요청을 보내세요. 연결 기록에서 도메인, 규칙, 아웃바운드를 확인합니다. 마지막으로 앱을 완전히 종료했다가 다시 열고 Profile 수와 로그를 다시 확인하세요. 두 번째 실행에서도 비정상 삭제가 없어야 복구가 안정적으로 끝난 것입니다.

복구 후 앱이 시작되지 않거나 Profile 수가 더 줄었거나 새 설정 검증에 실패했다면 먼저 앱을 종료하고 여러 ZIP을 연달아 시도하지 마세요. 복구 후의 앱 데이터 디렉터리를 별도로 저장한 다음, 처음 보관해 둔 현장 사본으로 변경 전 상태를 복원하세요.

먼저 기기에서 TUN과 시스템 프록시를 꺼 둬야 합니다. 롤백 후에도 클라이언트를 사용할 수 없다면 당분간 실행하지 말고 로그, 백업 ZIP, 디렉터리 사본을 보관하세요. 그런 다음 공식 issue에 버전, 운영체제, 삭제 수, 첫 번째 오류를 민감 정보 없이 제출하세요. 설정을 고치겠다고 가상 네트워크 어댑터를 제거하거나 시스템 네트워크 전체를 재설정하거나 앱 데이터 전체를 삭제하지 마세요.

2026년 9월 2일, 관리자는 issue #7804에서 commit 44f6f6e가 신뢰할 수 없는 정리 로직을 제거했음을 확인하고 issue를 닫았습니다. commit 제목은 “preserve files until explicit deletion”이며, 코드는 시작 시 cleanup_orphaned_files 호출과 자동 삭제 구현 전체를 직접 제거했습니다.

2026년 9월 3일 기준 공식 Releases의 최신 안정 버전은 여전히 2026년 7월 19일에 출시된 v2.5.2이며, Release 노트에는 이 후속 수정이 포함돼 있지 않습니다. 따라서 “issue가 닫혔다”를 “v2.5.2에서 수정됐다”로 표현해서는 안 되며, 위험을 피하려는 이유만으로 일상 기기를 개발 빌드로 전환해서도 안 됩니다.

안전한 방법은 먼저 백업과 복구를 마치고 불필요한 반복 실행을 줄인 채 44f6f6e가 포함됐다고 공식적으로 명시된 안정 버전을 기다리는 것입니다. 새 안정 버전이 나온 뒤에도 현재 백업을 유지하고 Release를 확인한 다음, 완전 종료·재시작·실제 연결로 회귀 검증을 한 번 수행하세요.

복구가 끝나면 백업 설정에서 예약 로컬 백업을 켜고 “중요 변경 시 자동 백업”도 유지하세요. v2.5.2 구현은 예약 시각과 전역 Merge/Script 변경 후에 아카이브를 만들며, 자동 아카이브는 최대 20개까지 보관합니다. 이 제한이 있으므로 로컬 디렉터리는 영구 기록 저장소가 아닙니다.

검증한 ZIP을 최소 한 개는 앱 데이터 디렉터리 밖으로 내보내거나, 직접 관리하는 WebDAV를 설정하세요. 구독 오버라이드를 크게 바꾸거나 클라이언트를 이전하거나 업그레이드하기 전에는 매번 수동으로 백업을 만들고 내보내세요. 복구 연습은 롤백 사본이 있을 때만 진행하세요.