이 글의 목차
업무용, 일상용, 테스트용 구독을 한 클라이언트에 저장하면 방금 업데이트한 구성과 실제 실행 중인 구성을 혼동하기 쉽습니다. 전환 전에 용도를 확인하고 업데이트 뒤에는 실제 노드와 규칙을 점검하세요. 직접 만든 덮어쓰기도 복원 가능한 백업으로 보관하면 구성이 늘어도 관리하기 쉽습니다.
원격 구독, 로컬 Profile, 덮어쓰기의 역할
구성 목록에서 현재 선택된 Profile을 확인한 뒤 덮어쓰기가 계속 활성화되어 있는지 살펴보세요. Profile을 전환해도 전역 덮어쓰기가 적용될 수 있으며 원격 구독이 정상적으로 로드됐다고 병합 결과까지 올바른 것은 아닙니다.
세 가지 설정 유형은 역할이 다릅니다
| 유형 | 적합한 내용 | 업데이트 방식 | 가장 흔한 오해 |
|---|---|---|---|
| 원격 Profile | 서비스 제공자가 제공하는 노드, 정책 그룹, 규칙 | URL에서 수동 또는 예약 가져오기 | 업데이트 성공은 현재 설정으로 전환되었다는 뜻 |
| 로컬 Profile | 고정 시험, 오프라인 롤백 또는 직접 작성한 전체 설정 | 수동 편집 및 백업 | 구독처럼 자동 새로 고침됨 |
| Merge / Script / 덮어쓰기 | 소수의 장기 사용자 지정 규칙과 필드 | 클라이언트 로드 시 적용 | 특정 Profile 하나에만 적용됨 |
명확히 이름을 붙이고 덮어쓰기 없는 정상 구성 보관
업무용, 일상용, 시험용, 예비 구독을 모두 Profile 1, Profile 2처럼 부르면 일주일 뒤 어떤 항목을 삭제해도 되는지 알기 어렵습니다. 이름에는 출처나 용도와 식별하기 쉬운 환경을 넣으세요. 예를 들어 "업무 | 회사 규칙", "일상 | 주 구독", "시험 | 로컬 덮어쓰기"처럼 지정합니다. 완전한 구독 도메인, 계정 또는 token은 이름에 넣지 마세요.
자동 업데이트를 시작하기 전에 현재 가장 안정적인 원격 구독을 선택하고 추가 Merge 또는 Script 없이 수동으로 업데이트한 뒤 바로 불러오세요. 사용 가능한 노드 하나를 고정하고 브라우저, 자주 쓰는 앱, 내부 도메인, DNS가 모두 정상인지 확인합니다.
덮어쓰기가 없는 이 Profile을 보관하고 비슷한 이름의 사본을 여러 개 만들지 마세요. 나중에 어떤 덮어쓰기에서 group not found가 발생하면 이 항목으로 돌아가 원본 구독이 계속 사용 가능한지 확인할 수 있습니다. 이것도 실패하면 다운로드, 구문 분석 또는 서버 측 변경을 확인하세요.
이 원본 설정의 조건
- 임시 스크립트나 온라인 변환 사이트에 의존하지 않음
- Windows에서는 클라이언트 종료 후 네트워크가 복구됨
- 구독 URL을 안전하게 백업함
업데이트 간격은 실제 변경 주기에 맞추세요. 짧다고 더 안정적인 것은 아닙니다
구독은 보통 노드, 트래픽 정보 또는 규칙이 바뀔 때만 다시 가져오면 됩니다. 간격이 너무 짧으면 서버 요청, 전력 소모, 실패 알림이 늘고 작업 도중 현재 설정이 일시적인 오류 응답으로 교체될 수도 있습니다. 일상용 구독은 넉넉한 주기로 시작하고 변경이 잦은 시험용 소스만 별도로 줄이세요.
Clash Verge Rev의 Profile 세부 정보나 구독 설정에서 자동 업데이트를 조정할 때 단위와 다음 실행 시각부터 확인하세요. 버전이나 가져오기 방식에 따라 표시되는 옵션이 다를 수 있으므로 다른 사람의 캡처 이미지에 나온 숫자를 그대로 따르지 마세요. 수동 업데이트 메뉴를 유지하고 마지막 성공 시각과 실패 원인을 확인할 수 있어야 합니다.
- 일상용 주 구독
- 안정성을 우선하고 서비스 제공자의 업데이트 빈도에 맞추며 몇 분마다 가져올 필요는 없습니다.
- 업무용 설정
- 업데이트 전에 회의, 원격 연결, 고정 출구를 고려해 작업 도중 전환되지 않게 합니다.
- 시험용 구독
- 더 자주 업데이트할 수 있지만 자동 시작 기본값으로 지정하거나 확인된 주 설정을 덮어쓰지 않습니다.
- 로컬 Profile
- 수동으로 수정하고 버전 기록을 남긴 뒤 변경이 적용됐는지 확인하세요. 원격 주소에서 가져오는 구독으로 취급하지 마세요.
업데이트 결과 확인 후 사용 중인 Profile 전환
“업데이트 성공”은 다운로드와 해석에서 즉시 오류가 나지 않았다는 뜻일 뿐입니다. 실제 요청으로 노드 사용 가능 여부를 확인하세요.
업데이트 후 노드가 수십 개에서 하나도 남지 않거나 정책 그룹이 갑자기 사라지거나 본문이 로그인 페이지라면 계속 전환하지 마세요. 이전에 실행 중이던 설정을 유지하고 HTTP 상태와 구문 분석 로그를 확인합니다. 자동 업데이트도 같은 원칙을 따라야 합니다. 실패했을 때 마지막으로 사용 가능한 캐시를 계속 사용하고 오류 응답을 새 설정으로 간주하지 마세요.
통제 가능한 업데이트 한 번
업데이트 전 상태 기록
Profile 이름, 현재 업데이트 시각, 주요 정책 그룹을 기록합니다.
이 항목만 업데이트
여러 소스가 동시에 바뀌지 않도록 먼저 "모두 업데이트"를 누르지 않습니다.
결과 확인
다운로드 상태, 구문 분석 오류, 노드와 정책 그룹의 완전성을 확인합니다.
전환 후 노드 고정
연결 페이지에서 자주 쓰는 도메인의 규칙과 출구를 검증합니다.
롤백 항목 유지
실제 작업을 마치기 전에는 이전에 사용 가능하던 설정을 삭제하지 않습니다.
Profile을 전환하면 덮어쓰기에 오류가 나는 이유는 무엇인가요?
전역 Merge에서 "PROXY", "노드 선택" 같은 고정 그룹 이름을 참조하면 다른 업체의 구독으로 전환했을 때 해당 그룹이 없어 proxy group not found가 발생할 수 있습니다. 덮어쓰기 내용은 최대한 적게 유지하고 모든 Profile에 존재하는 필드와 그룹 이름만 참조하세요.
출처마다 그룹 이름과 구조가 크게 다르면 덮어쓰기를 따로 관리하고 같은 스크립트로 모든 구독을 처리하지 마세요.
덮어쓰기를 조정한 뒤 최종 생성된 YAML을 확인하세요. DNS, rules, proxy-groups의 실제 내용과 그룹 이름 및 규칙 참조가 현재 Profile에 맞는지 점검해야 합니다. 덮어쓰기로 이 내용이 교체될 수 있으므로 원본 구독만 봐서는 판단할 수 없습니다.
모든 덮어쓰기를 끄고 원본 구독을 불러올 수 있는지 확인한 다음 하나씩 활성화하세요. 여러 오류를 한꺼번에 읽는 것보다 어떤 항목이 실패 원인인지 쉽게 찾을 수 있습니다.
업데이트는 성공하지만 전환할 때 group not found 발생
흔한 원인:덮어쓰기가 이 Profile에 없는 그룹 이름을 참조함
해결 방법:덮어쓰기를 끄고 최종 설정의 실제 그룹 이름과 비교하세요.
서로 다른 Profile로 전환해도 DNS가 계속 같음
흔한 원인:전역 Merge가 각 구독의 dns를 덮어씀
해결 방법:의도한 설계인지 확인하고 아니라면 덮어쓰기 범위를 줄이세요.
업데이트할 때마다 수동 편집 내용이 사라짐
흔한 원인:원격 구독 캐시를 직접 편집함
해결 방법:장기 수정 사항을 영구 덮어쓰기 또는 별도 로컬 Profile로 옮기세요.
백업할 내용과 복원 후 실제 테스트
여러 설정 작업 흐름을 복원할 수 있는 백업에는 최소 네 부분이 필요합니다. 원격 구독 주소, 직접 관리하는 로컬 YAML, Merge 또는 Script 파일, 그리고 클라이언트 버전, 포트, 현재 Profile 같은 소수의 설정입니다. 구독 주소는 비밀번호 관리자에, 로컬 설정과 덮어쓰기는 암호화 압축 파일에 저장하고 버전과 설정은 별도의 안내 문서 한 페이지에 기록할 수 있습니다.
Clash Verge Rev 캐시 디렉터리 전체만 복사하지 마세요. 캐시에는 만료된 구독, 실행 상태, 구형 커널이 들어 있을 수 있어 새 설치 환경을 그대로 덮으면 문제도 함께 복원됩니다. 롤백이 필요할 때는 최근 검증한 로컬 스냅샷 하나를 가져와 주 Profile을 덮어쓰지 않은 상태에서 불러올 수 있는지 확인하세요.
예비 구성은 독립적이고 신뢰할 수 있는 출처에서 마련하는 것이 좋습니다. 주 구성과 예비 구성이 같은 서비스와 변환 절차를 사용하고 동시에 자동 업데이트되면 출처에 문제가 생겼을 때 둘 다 실패해 예비 구성으로도 복구할 수 없습니다. 로컬 스냅샷에는 노드 인증 정보가 있으므로 암호화해 저장하고 보관 기간을 정하세요.
복원 가능한 백업 구성
- 비밀번호 관리자에 원격 구독 URL 저장
- 로컬 YAML과 Merge/Script를 암호화해 저장
- Clash Verge Rev와 Mihomo 버전 기록
- mixed-port, 현재 Profile, 필수 스위치 기록
- 시험용 Profile에서 복원 검증 한 번 수행
클라이언트를 시작하고 현재 Profile을 확인하세요. 수동 업데이트 후 실제 작업을 완료하고 예비 구성으로 전환했다가 돌아온 뒤 종료하여 시스템 프록시 복구를 확인하세요. 재시작 후에도 현재 구성과 자동 업데이트 계획이 올바른지 확인하세요.