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

먼저 Clash Verge Rev v2.5.2 재시작 후 사라진 내용을 확인하세요. 여러 구독, 로컬 Profile 또는 전역 Merge/Script가 함께 사라지고 덮어쓰기가 빈 템플릿으로 돌아갔는지 봅니다. Profile은 앱이 저장한 구성입니다. 이 조건에 해당하면 시작 로그에서 파일 삭제를 확인하고 구독 하나의 업데이트 실패나 빈 노드 목록은 별도로 확인하세요.

공식 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가 포함될 수 있습니다.

공식 v2.5.2는 profiles 디렉터리, config.yaml, verge.yaml, 선택적 DNS 설정과 profiles.yaml을 같은 ZIP에 넣습니다. issue #7804의 보고자는 사흘 전 auto-script ZIP에서 전역 스크립트를 복구했습니다. 이 백업에는 스크립트뿐 아니라 전체 설정이 들어 있을 수 있습니다.

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

v2.5.8의 고정 소스에서는 시작 시 Profile을 정리하는 호출을 제거했으며, 설정 인덱스를 불러오지 못해도 파일을 보존합니다. 업데이트하려면 공식 v2.5.8 Release에서 플랫폼에 맞는 설치 패키지를 받으세요. 전체 백업은 계속 보관해야 합니다. 백업 없이 이미 삭제된 내용은 업데이트로 복구할 수 없습니다.

설치 후에는 먼저 앱 버전을 확인하세요. 사라진 내용은 뒤의 절차에 따라 백업이나 원래 출처에서 복구하세요. 복구 후 Profile 개수와 실제 연결을 확인한 다음 앱을 완전히 종료하고 다시 실행해 재확인하세요. 현재 백업은 계속 보관해야 합니다.

시스템 프록시와 TUN을 끈 상태로 설정 → Verge 고급 설정 → 백업 설정 → 로컬 백업 → 기록 보기로 이동하세요. 문제가 발생하기 전의 백업을 선택해 앱 데이터 폴더 밖으로 내보낸 다음 복원을 누르고 확인하세요. 앱이 자동으로 다시 시작할 때까지 기다리며 강제 종료하지 마세요. 재시작 후 Profile을 확인한 뒤 프록시를 켜세요.

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

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

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

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

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

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

복원 후 앱이 시작되지 않거나 Profile 수가 줄거나 설정 검사가 실패하면 트레이에서 완전히 종료하고 관련 프로세스가 끝났는지 확인하세요. 여러 ZIP을 연달아 시도하지 마세요. 이번에 복원한 디렉터리와 로그를 따로 저장하고 처음 보관한 전체 디렉터리 사본으로 되돌리되 알 수 없는 백업을 섞지 마세요.

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

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

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