변경 범위 이해하기: 프로젝트, UI, 파일명이 동시에 바뀌지는 않는다

Mihomo Party를 검색했는데 Clash Party가 나온다면 아이콘이나 파일명만 보고 별도 클라이언트라고 판단하지 마십시오. 현재 1차 진입점은 mihomo-party-org/clash-party 공식 저장소이며 저장소 이름과 설명이 Clash Party를 사용합니다. 조직과 저장소를 따라가면 제3자 다운로드 페이지가 제목만 바꿔서는 증명할 수 없는 프로젝트 정체성을 확인할 수 있습니다.

이름 변경은 모든 표면에 동시에 반영되지 않습니다. 저장소, 창 제목, 설치 파일, 운영체제 앱 목록, 데이터 디렉터리, 자동 업데이트 메타데이터, 이전 문서가 버전마다 다른 이름을 남길 수 있습니다. mihomo-party 접두사가 곧 가짜라는 뜻은 아니고, clash-party도 이름만으로 진본이 되지 않습니다. 같은 공식 Release에 있는지, 플랫폼과 아키텍처가 맞는지, 체크섬이 연결되는지 확인합니다.

앱과 코어는 다른 계층입니다. Clash Party는 데스크톱 클라이언트 프로젝트 이름이고 Mihomo는 사용하는 코어 이름입니다. UI 이름이 바뀌었다고 구성의 Mihomo 문자열을 모두 교체하면 안 됩니다.

이름만으로 라이선스, 데이터 위치, 호환성이 바뀌었다고 추정하지 마십시오. Release나 코드가 명시한 내용만 사실 근거가 됩니다. 안정적인 기존 설치는 새 이름을 보기 위해 급히 올릴 필요가 없으며, 다른 업데이트 이유가 있을 때 일반 소프트웨어 이전처럼 출처와 롤백을 관리합니다.

파일명 검색 대신 공식 저장소에서 Releases로 이동하기

URL의 조직이 mihomo-party-org이고 저장소가 clash-party인지 먼저 확인한 뒤 그 안에서 Releases를 엽니다. 대상 태그, 게시 맥락, 정확한 자산 이름, 크기, SHA-256 파일을 기록합니다. 사용 안내서는 메뉴 이해에 도움을 줄 수 있지만 실행 파일의 유일한 출처가 되어서는 안 됩니다.

  1. 공식 저장소에서 조직, 저장소 이름, 설명을 확인합니다.
  2. 저장소 내부 Releases에서 명확한 버전을 선택합니다.
  3. 운영체제, CPU 아키텍처, 설치 형식으로 자산을 좁힙니다.
  4. 선택한 자산의 SHA-256 파일을 받아 로컬에서 비교합니다.
  5. Release URL과 원래 파일명을 설치 기록에 남깁니다.

확장자는 패키지 형식을 알려 주지만 CPU를 보장하지는 않습니다. Windows는 설치형과 압축형, macOS는 Intel과 Apple 칩, Linux는 여러 패키지와 아키텍처가 있을 수 있습니다. 장치 정보를 먼저 결정하십시오. 미러가 빠르거나 파일명이 짧고 크기가 작다는 이유는 적합한 빌드라는 증거가 아닙니다.

재배포처가 자동으로 공식 미러가 되지는 않습니다. 프로젝트가 명시적으로 연결한 배포 위치만 1차 출처 체인을 유지합니다. 같은 이름의 외부 파일도 별도 검증이 필요합니다.

한 Release에 두 접두사가 있으면 플랫폼·자산·해시를 짝짓기

공식 v2.0.2 Release는 전환기의 구체적 예입니다. Assets에는 clash-party-와 mihomo-party-로 시작하는 파일이 Windows, macOS, Linux용으로 함께 있고 관련 .sha256도 나열됩니다. 두 계열이 같은 공식 태그에 있으므로 접두사만으로 서로 무관한 두 제품이라고 말할 수 없습니다.

관찰근거 있는 해석근거 없는 비약
clash-party현재 프로젝트 이름 자산항상 새 데이터 경로 사용
mihomo-party전환 또는 호환 이름항상 구형이거나 악성
같은 v2.0.2한 Release가 함께 게시외부 동명 파일도 신뢰 가능
.sha256로컬 내용 일치 확인출처 확인 불필요

접두사 해석보다 OS와 아키텍처를 먼저 맞추고 해당 태그 설명을 읽습니다. 같은 플랫폼용 두 계열이 있어도 둘을 겹쳐 설치하지 말고, 백업 뒤 Release와 체크섬에 완전히 연결되는 한 자산을 선택합니다. 설명되지 않은 차이는 공식 토론에서 확인하고 임의 기능 차이를 만들지 않습니다.

SHA-256은 다운로드 중단이나 변경을 찾지만 예상 값이 신뢰할 수 있는 Release에서 왔을 때만 유효합니다. 원래 파일명을 유지하고 전체 로컬 결과를 비교합니다. 파일 크기나 앞 몇 글자만 맞는 것은 완전한 검증이 아닙니다.

사용자 데이터를 백업하고 실행 성공과 이전 성공 구분하기

이름이 바뀐 빌드가 기존 데이터를 바로 읽을 수도 있고 패키지 식별자나 버전 차이 때문에 다른 곳을 볼 수도 있습니다. 자동 이전을 가정하거나 데이터 폴더를 미리 개명하지 마십시오. 작동 중인 이전 클라이언트에서 전체 버전, 프로필 이름, 선택 모드, 주요 오버라이드, 코어 상태를 기록하고 내장 내보내기를 사용합니다. 데이터 디렉터리는 앱을 완전히 종료한 뒤 복사하며 구독 토큰을 비밀로 취급합니다.

프로그램 복구와 사용자 데이터 복구를 따로 준비합니다. 이전 설치 파일이나 수정하지 않은 포터블 폴더는 앱을 되돌리고, 내보내기와 전체 스냅샷은 작업 상태를 되돌립니다. 둘은 서로 대체하지 못합니다. 새 빌드의 데이터 읽기를 확인하기 전에 사용자 데이터 삭제 옵션으로 구버전을 제거하지 마십시오.

  1. 이전 표시 이름, 정확한 버전, 원래 다운로드 출처를 기록합니다.
  2. 설정을 내보내고 앱 종료 상태에서 실제 데이터 디렉터리를 복사합니다.
  3. 프로필, 선택 그룹, 주요 오버라이드의 민감 정보를 가린 기준을 남깁니다.
  4. 백업 파일이 존재하고 비어 있지 않으며 앱 밖에 있는지 확인합니다.
  5. 시스템에 맞는 한 자산만 설치하고 첫 실행에서는 구독을 갱신하지 않습니다.
  6. 기준과 비교한 뒤 자동 업데이트와 일반 사용을 복원합니다.

새 빌드가 빈 목록으로 열리면 쓰기 전에 종료합니다. 신·구 프로세스가 실제로 읽는 위치를 찾고 내장 가져오기 또는 한 개의 완전한 스냅샷을 선택합니다. 한 버전의 인덱스와 다른 버전의 개별 YAML을 섞으면 중복, 오버라이드 손실, 존재하지 않는 파일 참조가 생길 수 있습니다.

버전·코어·데이터·프록시를 확인한 뒤 이전 파일 정리하기

첫 실행 후 About에서 앱 버전과 선택한 Release를 대조하고 Clash Party 또는 전환 이름 중 무엇이 보이는지 기록합니다. 이어서 코어 버전, 프로필 목록, 정책 그룹, 로그를 봅니다. 새 이름만으로 이전 성공이 되지 않고 이전 이름이 일부 남았다고 설치 오류도 아닙니다. 추적 가능한 정체성, 온전한 데이터, 정상 동작이 핵심입니다.

  • 앱: 버전, 플랫폼 아키텍처, 선택한 자산이 맞습니다.
  • 데이터: 프로필, 오버라이드, 모드와 주요 환경설정이 있습니다.
  • 코어: 시작 후 충돌 반복 없이 계속 실행됩니다.
  • 프록시: 고정 노드와 rule 모드에서 설명 가능한 연결이 생깁니다.
  • 롤백: 이전 앱과 비공개 데이터 백업이 남아 있습니다.

업데이터가 여전히 Mihomo Party라고 해도 요청 저장소와 버전을 확인합니다. Clash Party 문구에도 같은 URL 검증이 필요합니다. 브랜드는 시각 단서이고 조직, 저장소, 태그, 자산, 해시가 출처 체인을 만듭니다.

정리 기준: 닫고 다시 열기, 구성 로드, 실제 연결을 마치고 일정 기간 백업을 보존합니다. 롤백이 필요 없을 때만 중복 설치 파일과 시험 폴더를 제거합니다.

전환을 설명할 때는 “이전 Mihomo Party 프로젝트가 현재 Clash Party 이름을 사용한다”와 공식 저장소 링크를 제시합니다. 두 접두사를 별도 공식 클라이언트로 부르거나 미래 Release에도 이전 이름이 항상 남는다고 약속하지 마십시오.

공식 자료와 버전 범위

버전 번호, 파일 이름, 화면 문구는 업데이트로 바뀔 수 있습니다. 작업 전에 연결된 공식 문서를 확인하세요.