이 글의 목차
구독 업데이트가 검증에 실패했는데 기존 연결은 작동한다면 바로 재시작할 경우 마지막 정상 실행 상태까지 잃을 수 있습니다. 원본 데이터와 오류를 보관하고 새 내용을 별도 후보 파일로 검사한 뒤 정상 구성을 복원하세요. 앱 업데이트는 이후 업데이트를 보호할 수 있지만 이미 덮어쓴 파일을 자동으로 복구하지는 않습니다.
구독은 다운로드됐지만 Mihomo가 새 구성을 거부함
Clash Party 2.0에서 이전에 정상 작동한 Profile, 업데이트 후 최종 구성, 전체 검증 오류를 기록하세요. 공식 issue #2047에서는 새 파일을 다운로드했고 YAML도 파싱됐지만 Mihomo가 거부해 핫 리로드나 재시작이 불가능해졌습니다. 이를 다운로드 시간 초과로 다루면 안 됩니다.
구독 주소가 401, 403, HTML 페이지, 빈 내용 또는 Invalid YAML을 반환한다면 더 앞 단계에서 실패한 것입니다. 구독 응답과 YAML 문법부터 확인하세요. 다운로드가 성공해 Profile이 변경된 뒤 Mihomo가 로드를 거부하는 경우에만 갱신된 최종 구성을 점검합니다.
아직 인터넷이 된다면 실행 중인 구성 보존
구성 핫 리로드가 실패해도 실행 중인 Mihomo는 잠시 이전의 정상 구성을 계속 사용할 수 있습니다. 이때 코어를 서둘러 재시작하거나 앱을 종료하거나 구독을 다시 새로 고치지 마세요. 이런 동작은 아직 작동하는 기존 실행 상태를 없앨 수 있지만 디스크에 이미 기록된 새 파일을 자동으로 고쳐 주지는 않습니다.
복구 가능성 보존
현재 실행 상태 유지
Profile을 전환하거나 코어를 재시작하거나 Clash Party를 다시 시작하지 말고, 현재 웹페이지가 기존 노드를 통해 계속 열리는지 먼저 확인합니다.
오류와 버전 정보 저장
검증 오류를 복사하고 Clash Party, Mihomo, Profile과 업데이트 시각을 기록하세요. 키가 포함된 전체 로그는 내보내지 않습니다.
정상 백업 복사
최근 정상 작동을 확인한 Profile을 별도 디렉터리에 복사하고 원본 파일은 그대로 둡니다. 백업이 없다면 제공업체에 수정된 구성을 먼저 요청하세요.
추가 덮어쓰기 중단
수동 갱신과 자동 업데이트를 중단하고 기존 업데이트 간격을 기록하세요. 후보 파일이 선택한 코어의 전체 검증을 통과하기 전에는 다운로드한 내용을 현재 Profile에 붙여 넣지 마세요. 유일한 백업 파일로 시험하지 마세요.
YAML이 열린다고 해서 Mihomo가 실행되는 것은 아닙니다
YAML 파서는 들여쓰기, 목록과 키-값 구조가 유효한지만 판단하며 모든 정책 그룹 참조의 존재를 보장하지 않습니다. 아래 예시는 문법상 유효하지만 '手动选择'에서 정의되지 않은 정책 그룹을 참조합니다. 따라서 Mihomo는 로드할 때 여전히 이 구성을 거부합니다.
Clash Party는 원격 구독에 전역 덮어쓰기, 개별 Profile 덮어쓰기, 규칙과 관리 설정을 결합해 최종 실행 구성을 만듭니다. 원격 파일만 보면 정상이어도 병합 후 중복 이름, 누락된 참조 또는 지원되지 않는 필드가 생길 수 있습니다. 따라서 YAML을 열어 보는 데 그치지 말고 최종 후보를 검증해야 합니다.
proxies:
- name: 节点 A
type: socks5
server: 127.0.0.1
port: 1080
proxy-groups:
- name: 手动选择
type: select
proxies:
- 不存在的策略组
rules:
- MATCH,手动选择오류에서 특정 proxy group이 없다고 표시됨
해당 이름이 proxies 또는 proxy-groups에 실제로 있는지 확인하고 공백, 대소문자와 전각 기호까지 대조합니다.
특정 덮어쓰기를 끄면 검증 통과
문제는 병합 결과에 있습니다. 관련 없는 노드는 바꾸지 말고 덮어쓰기의 이전 그룹 이름이나 필드를 수정하세요.
원본 구독과 모든 덮어쓰기를 결합해도 계속 실패
민감 정보를 제거한 정확한 오류를 구독 제공업체에 전달하고 업스트림 생성 구성을 수정해 달라고 요청합니다.
같은 파일이 다른 코어 버전에서는 통과
두 버전과 전체 오류를 보존하고 실제로 사용할 Mihomo 버전을 기준으로 판단하세요. 다른 코어로 검수를 대신하면 안 됩니다.
마지막 유효한 오류에 따라 해결 방법 선택하기
| 표시된 결과 | 장애 단계 | 조치를 시작할 곳 |
|---|---|---|
| 401, 403, 시간 초과 또는 웹페이지 반환 | 구독 요청에서 구성을 받지 못함 | 링크, 인증, 네트워크와 제공업체 상태 확인 |
| Invalid YAML, 들여쓰기 또는 따옴표 오류 | 파일이 아직 YAML 파싱을 통과하지 못함 | 형식을 수정하고 기존 Profile은 더 이상 덮어쓰지 않음 |
| YAML은 읽히지만 proxy group not found 등의 오류가 발생 | Mihomo 의미 검증 실패 | 노드, 정책 그룹, 규칙과 덮어쓰기 사이의 참조 확인 |
| 업데이트는 성공했지만 특정 노드만 연결 실패 | 구성은 로드되었으며 문제는 노드 또는 프로토콜에 있음 | 노드, TLS, UDP 또는 네트워크 점검으로 전환 |
새 구독을 후보 파일로 분리해 검증
후보 구성은 별도의 임시 위치에 저장하고 현재 Profile을 덮어쓰지 마세요. token이 포함된 링크를 온라인 변환 사이트에 제출하지 마세요.
명령줄에 익숙한 사용자는 임시 사본에 Mihomo 테스트 모드를 실행할 수 있습니다. 명령이 성공적으로 종료되었다는 것은 이 후보를 해당 코어가 파싱하고 초기화할 수 있다는 뜻일 뿐입니다. 노드 연결을 보장하지 않으며 이후의 실제 요청도 대신할 수 없습니다. 유일한 원본 구성 파일을 직접 수정하지 마세요.
명령의 mihomo는 앱이 실제로 선택한 실행 파일이어야 합니다. 이름이 같은 다른 프로그램으로 대신하지 마세요. candidate.yaml은 실제 덮어쓰기를 반영한 임시 사본을 가리켜야 합니다. 코어와 후보 파일의 위치를 확인하기 전에는 테스트를 실행하지 마세요.
후보 파일에서 가져올 수 있는 구성까지
원격 원본 보존
이번에 다운로드한 내용을 임시 디렉터리에 두고 비교용으로 민감 정보를 제거한 사본을 하나 더 저장합니다. 구독 URL은 명령 기록이나 지원 요청에 남기지 마세요.
참조 관계 확인
검증 오류에서 지목한 그룹부터 시작해 proxies, proxy-groups, rules와 rule-providers를 확인하고 존재하지 않거나 이름이 바뀐 대상을 수정합니다.
실제 덮어쓰기 적용
전역 덮어쓰기와 해당 Profile의 덮어쓰기를 검사에 포함합니다. 병합한 뒤에만 실패한다면 같은 구독을 반복해서 다운로드하지 말고 덮어쓰기를 수정해야 합니다.
선택한 코어로 테스트
임시 최종 구성에 테스트 모드를 실행하고 종료 코드와 오류를 저장합니다. 성공적으로 종료된 경우에만 가져오기 단계로 진행하세요.
mihomo -t -f candidate.yaml- 원격 구독 후보임시 파일에만 쓰고 현재 Profile은 덮어쓰지 않음
- 규칙과 덮어쓰기 병합Clash Party가 실제 실행할 최종 구성 생성
- 선택한 Mihomo -t그룹 참조, 필드와 코어 호환성 확인
- 성공한 뒤 저장실패하면 임시 파일을 정리하고 마지막 정상 구성 유지
PR #2048에서는 저장 동작을 Mihomo 검증 뒤로 옮겼습니다. v2.0.0에는 아직 이 보호 기능이 없고 v2.0.1에 정식 포함되었습니다. 업그레이드해도 이전에 덮어쓴 Profile은 자동으로 복구되지 않습니다.
코어가 시작되지 않으면 이전에 작동하던 Profile 복원하기
코어가 이미 중지되었다면 시스템 프록시와 TUN을 먼저 끄고 운영체제의 직접 연결이 되는지 확인해 모든 다운로드가 작동하지 않는 로컬 포트를 계속 향하지 않도록 합니다. 그런 다음 미리 백업한 정상 구성을 새 Profile로 가져옵니다. 손상된 Profile은 오프라인 비교용으로만 보관하고 다시 현재 구성으로 선택하지 마세요.
백업이 없다고 Clash Party 데이터 디렉터리 전체를 삭제하며 운에 맡기지 마세요. 구독 제공업체에 구성을 수정하도록 요청하고 임시 위치에서 의미 검증을 마친 뒤 새 이름으로 가져오세요. 그러면 기존 덮어쓰기, 오류 근거와 롤백 단서를 계속 보존할 수 있습니다.
롤백 가능한 순서로 복구
시스템 직접 연결 복구
시스템 프록시와 TUN을 끄고 브라우저가 작동하지 않는 로컬 프록시 포트에 더 이상 연결하지 않는지 확인합니다. 기존 스위치 상태를 기록하고 복구 뒤 하나씩 다시 켭니다.
마지막 정상 사본 가져오기
새 이름으로 Profile을 만들고 장애가 난 구성은 아직 삭제하지 않으며 자동 업데이트도 켜지 않습니다.
코어를 시작하고 노드 하나 테스트
정상이라고 확인한 노드를 선택해 일반 웹페이지 하나를 연 뒤 연결 기록에서 요청이 새 Profile로 실제 유입되는지 확인합니다.
검증 후 자동 업데이트 복원
수동 업데이트, 다시 로드, 앱 재시작이 모두 성공한 뒤에만 기존 업데이트 간격을 복원하세요. 다시 활성화하기 전에 새로 확인한 정상 구성의 백업을 저장하세요.
저장 전 검증은 구성을 어떻게 보호하며 왜 v2.0.3 이상의 안정 버전으로 업그레이드해야 하나요?
Clash Party v2.0.1은 2026년 8월 11일에 출시되었습니다. 공식 릴리스 노트는 ‘원격 구독 업데이트 전에 설정을 검증하지 않아 잘못된 내용이 기존의 정상 구독을 덮어쓸 수 있는 문제’의 수정을 명시합니다. v2.0.0에는 여전히 이 보호 기능이 없습니다.
2026년 9월 23일 기준 공식 최신 안정 버전은 v2.0.3이며, 악의적인 rule-providers 설정으로 임의 명령이 실행될 수 있는 문제도 수정했습니다. 구버전 사용자라면 먼저 정상 작동하는 Profile을 백업하고 공식 릴리스에서 업데이트하세요.
v2.0.1은 원격 구독을 후보로 두고 관리 구성, 규칙과 덮어쓰기를 적용한 뒤 선택한 Mihomo의 -t 모드로 임시 파일을 검증합니다. 검증에 실패하면 저장된 Profile을 바꾸거나 코어를 리로드하지 않으며 임시 파일은 이후 정리합니다. 이 보호 기능은 이후 업데이트만 제한하며 업그레이드 전에 이미 덮어쓴 기존 구성을 자동으로 되찾아 주지는 않습니다.
현재 선택 가능한 방법
| 선택 | 적합한 사용자 | 적용 범위 |
|---|---|---|
| v2.0.3 또는 이후 안정 버전으로 업데이트 | 업데이트 전 검증을 원하는 사용자 | Profile을 먼저 백업한 뒤 실패하는 후보 설정으로 기존 설정이 바뀌지 않는지 확인하세요. v2.0.3은 rule-providers 보안 문제도 수정합니다. |
| 당장 업데이트할 수 없음 | 현재 Profile을 먼저 보관해야 하는 사용자 | 자동 업데이트를 일시 중지하고 후보 설정을 직접 검증하세요. 구버전은 정상 Profile을 덮어쓸 수 있고 v2.0.3의 보안 수정도 포함하지 않으므로 가능한 빨리 업데이트해야 합니다. |
| 이전 버전 앱으로 다운그레이드 | 구성 복원에 권장하지 않는 방법 | 이미 덮어쓴 Profile을 복원할 수 없고 v2.0.3의 보안 수정도 잃게 됨 |
잘못된 구독이 이전 구성을 덮어쓰나요? 정상 구독은 업데이트되나요?
공식 v2.0.3 또는 이후 안정 버전으로 업데이트한 뒤에는 백업 환경에서 업데이트를 두 번 테스트하세요. 첫 번째는 민감 정보를 제거한 잘못된 후보 설정으로 Clash Party가 검증 오류를 반환하면서도 기존 Profile 내용, 현재 코어 실행 상태, 노드 연결이 그대로인지 확인하세요. 두 번째는 검증된 정상 후보 설정으로 저장, 다시 불러오기, 실제 접속이 모두 성공하는지 확인하세요.
“업데이트 완료” 메시지만으로는 충분하지 않습니다. 잘못된 업데이트는 이전의 정상 구성을 보존하고 유효한 업데이트는 정상 적용되어야 합니다. Clash Party를 종료하고 다시 시작한 뒤에도 정책 그룹을 선택할 수 있고 새 연결 기록이 생성되어야 하며 시스템 프록시나 TUN도 정상적으로 끄고 복구할 수 있어야 합니다. 연결 기록의 규칙과 출구도 예상과 일치해야 합니다.