이 글의 목차
다운로드는 성공했지만 코어가 거부한 뒤 장애가 발생했는지 확인
이 글은 범위가 명확한 Clash Party 2.0 문제를 다룹니다. 기존 Profile은 사용할 수 있었지만 원격 구독을 새로 고친 뒤 구성 검증 실패가 표시되고, 핫 리로드 또는 코어 재시작까지 실패하는 경우입니다. 공식 issue #2047에 기록된 문제는 다운로드 시간 초과가 아닙니다. 새 파일은 다운로드되었고 YAML도 파싱되지만 최종 구성이 Mihomo 검증을 통과하지 못합니다.
구독 주소가 401, 403, HTML 페이지, 빈 내용 또는 Invalid YAML을 반환한다면 장애는 더 앞 단계에서 발생한 것입니다. 구독 응답과 YAML 문법부터 점검하세요. 다운로드가 성공하고 Profile이 이미 다시 작성된 뒤 Mihomo가 로드를 거부하는 경우에만 이 글을 계속 적용할 수 있습니다.
마지막 유효 오류를 기준으로 분기
| 표시된 결과 | 장애 단계 | 처리 시작점 |
|---|---|---|
| 401, 403, 시간 초과 또는 웹페이지 반환 | 구독 요청에서 구성을 받지 못함 | 링크, 인증, 네트워크와 제공업체 상태 확인 |
| Invalid YAML, 들여쓰기 또는 따옴표 오류 | 파일이 아직 YAML 파싱을 통과하지 못함 | 형식을 수정하고 기존 Profile은 더 이상 덮어쓰지 않음 |
| YAML은 읽히지만 proxy group not found 등의 오류가 발생 | Mihomo 의미 검증 실패 | 노드, 정책 그룹, 규칙과 덮어쓰기 사이의 참조 확인 |
| 업데이트는 성공했지만 특정 노드만 연결 실패 | 구성은 로드되었으며 문제는 노드 또는 프로토콜에 있음 | 노드, TLS, UDP 또는 네트워크 점검으로 전환 |
인터넷을 사용할 수 있을 때 실행 중인 기존 구성을 먼저 보존
구성 핫 리로드가 실패해도 실행 중인 Mihomo는 잠시 이전의 정상 구성을 계속 사용할 수 있습니다. 이때 코어를 서둘러 재시작하거나 앱을 종료하거나 구독을 다시 새로 고치지 마세요. 이런 동작은 아직 작동하는 기존 실행 상태를 없앨 수 있지만 디스크에 이미 기록된 새 파일을 자동으로 고쳐 주지는 않습니다.
구독 카드의 새로 고침 버튼을 누르는 일을 중단하세요. 이 Profile에 자동 업데이트가 설정되어 있다면 일시적으로 끄고 기존 간격을 기록합니다. 그런 다음 기존 백업에서 마지막으로 정상 작동한 Profile을 찾거나 구독 제공업체에 업스트림 구성을 먼저 수정해 달라고 요청하세요. 유일한 백업을 실험 파일로 직접 사용하면 안 됩니다.
복구 가능성 보존
현재 실행 상태 유지
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 버전을 기준으로 판단하세요. 다른 코어로 검수를 대신하면 안 됩니다.
새 구독을 후보 파일로 분리해 검증
수정할 때 새 구독을 임시 사본으로 먼저 저장하고 현재 Profile을 덮어쓰지 마세요. token이 포함된 링크를 온라인 변환 사이트에 제출해서도 안 됩니다. 각 규칙의 대상, 각 정책 그룹의 구성원과 모든 덮어쓰기 참조가 존재하는지 하나씩 확인한 뒤 Clash Party에서 실제 선택한 Mihomo 코어로 이 최종 후보를 테스트합니다.
명령줄에 익숙한 사용자는 임시 사본에 Mihomo 테스트 모드를 실행할 수 있습니다. 명령이 성공적으로 종료되었다는 것은 이 후보를 해당 코어가 파싱하고 초기화할 수 있다는 뜻일 뿐입니다. 노드 연결을 보장하지 않으며 이후의 실제 요청도 대신할 수 없습니다. 유일한 원본 구성 파일을 직접 수정하지 마세요.
후보 파일에서 가져올 수 있는 구성까지
원격 원본 보존
이번에 다운로드한 내용을 임시 디렉터리에 두고 비교용으로 민감 정보를 제거한 사본을 하나 더 저장합니다. 구독 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.1에 저장 전 검증이 정식 포함됨
Clash Party v2.0.1은 2026년 8월 11일에 출시되었으며 공식 출시 안내에는 '원격 구독 업데이트 전에 구성을 검증하지 않아 비정상 내용이 기존 정상 구독을 덮어쓸 수 있음'에 대한 수정이 명시되어 있습니다. v2.0.0에는 이 보호 기능이 없으며 현재 안정 버전은 v2.0.2까지 올라갔습니다. 이전 버전을 사용하는 사용자는 정상 Profile을 먼저 백업한 뒤 공식 Release에서 업그레이드해야 합니다.
v2.0.1은 원격 구독을 후보로 두고 관리 구성, 규칙과 덮어쓰기를 적용한 뒤 선택한 Mihomo의 -t 모드로 임시 파일을 검증합니다. 검증에 실패하면 저장된 Profile을 바꾸거나 코어를 리로드하지 않으며 임시 파일은 이후 정리합니다. 이 보호 기능은 이후 업데이트만 제한하며 업그레이드 전에 이미 덮어쓴 기존 구성을 자동으로 되찾아 주지는 않습니다.
현재 선택 가능한 방법
| 선택 | 적합한 사용자 | 적용 범위 |
|---|---|---|
| v2.0.1 이상 안정 버전으로 업그레이드 | 업데이트 전 검증을 원하는 사용자 | 현재 안정 버전은 v2.0.2입니다. Profile을 먼저 백업한 뒤 실패 후보를 사용해 기존 구성이 다시 작성되지 않는지 확인하세요. |
| v2.0.0을 당분간 유지 | 현재 업그레이드 일정을 잡기 어려운 사용자 | 자동 업데이트를 중단하고 후보를 수동으로 검증하세요. 이전 버전은 여전히 정상 Profile을 덮어쓸 수 있습니다. |
| 이전 버전 앱으로 다운그레이드 | 다른 명확한 버전 회귀에만 사용 | 이미 덮어쓴 Profile을 복구할 수 없으며 같은 업데이트 경로를 피한다고 보장할 수도 없음 |
실패 후보와 유효 후보로 검수 완료
v2.0.1 이상 안정 버전(현재 v2.0.2)으로 업그레이드한 뒤 백업 환경에서 두 번 업데이트해야 합니다. 첫 번째는 민감 정보를 제거한 잘못된 후보를 사용해 Clash Party가 검증 오류를 반환하지만 기존 Profile 내용, 현재 코어 실행과 노드 연결은 바뀌지 않는지 확인합니다. 두 번째는 검증된 정상 후보로 바꿔 저장, 리로드와 실제 접속이 모두 성공하는지 확인합니다.
'업데이트 완료' 안내만 보는 것으로는 부족합니다. 잘못된 업데이트가 마지막 정상 구성을 손상하지 않고 정상 업데이트는 적용되며, Clash Party를 종료하고 다시 시작한 뒤에도 정책 그룹을 선택하고 연결 기록을 만들 수 있어야 합니다. 시스템 프록시 또는 TUN도 정상적으로 끄고 복원할 수 있어야 검증이 완료됩니다.
v2.0.1 업데이트 보호 검증 목록
- Clash Party를 공식 v2.0.1 또는 해당 수정이 명확히 포함된 이후 안정 버전으로 업그레이드함
- 잘못된 후보에서 Mihomo의 구체적인 검증 오류가 표시됨
- 잘못된 후보가 저장된 마지막 정상 Profile을 다시 작성하지 않음
- 검증 실패 시 현재 Mihomo가 리로드되거나 중지되지 않음
- 정상 후보를 저장할 수 있고 예상한 노드와 정책 그룹이 표시됨
- 실제 웹페이지 요청이 연결 기록에 나타나고 규칙과 외부 경로가 예상과 일치함
- 앱을 종료하고 다시 열어도 인터넷을 사용할 수 있고 시스템 프록시와 TUN을 정상적으로 복원할 수 있음
- 자동 업데이트를 다시 켜기 전에 새 정상 백업을 저장함