이 글의 목차
안내서에서 서로 다른 프로젝트 이름을 보면 화면을 제공하는 앱, 프록시 코어, 예전 이름을 서로 대체할 수 있는 도구로 오해하기 쉽습니다. 설정이 현재 기기에 맞는지는 실제로 실행 중인 코어와 버전을 보고 판단해야 합니다. 이름의 관계를 알면 예전 문서를 이해하는 데 도움이 되지만, 호환성은 설정 검사와 실제 연결로 확인해야 합니다.
Clash Meta와 Mihomo는 같은 프로젝트의 서로 다른 시기 이름
Mihomo는 Clash Meta가 나중에 채택한 프로젝트 이름입니다. Original Clash는 보통 Dreamacro가 시작한 초기 Clash 코어를 뜻합니다. 과거 튜토리얼의 Meta와 현재 로그의 Mihomo가 선택해야 하는 별개 코어를 뜻하지는 않습니다.
더 혼동하기 쉬운 것은 클라이언트 이름입니다. Clash Verge Rev, FlClash, Clash Party는 구독, 시스템 프록시, 화면을 관리하는 그래픽 클라이언트이며 내부에서 실제로 실행되는 코어가 Mihomo일 수 있습니다. 파일 이름에 Clash가 들어 있다는 사실만으로 Original Clash를 사용한다고 볼 수는 없습니다.
이름별 계층
| 이름 | 일반적으로 뜻하는 것 | 현재 어떤 용도로 참고할 수 있나 |
|---|---|---|
| Original Clash | 최초의 Clash 코어와 기본 설정 모델 | 과거 설정과 구형 클라이언트 동작 이해 |
| Clash Meta | 기존 모델을 기반으로 확장한 후속 코어 이름 | 이전 문서, 로그, 구독 설명 읽기 |
| Mihomo | Clash Meta가 현재 사용하는 프로젝트 이름 | 새 배포 환경, 현재 필드, 유지 관리 중인 코어 |
| Clash 그래픽 클라이언트 | 코어를 관리하는 데스크톱 또는 모바일 앱 | 인터페이스, 플랫폼 지원, 실제 내장 코어 버전 확인 |
실제로 실행 중인 클라이언트와 코어 버전 확인
같은 구독이 두 컴퓨터에서 다르게 동작하면 실제로 불러온 설정, 코어, 버전을 확인하세요. 클라이언트의 “설정 → 정보”, “코어”, “실행 로그”에서 전체 이름과 버전을 기록합니다. 명령줄 환경에서는 다른 경로의 같은 이름 프로그램이 아니라 실제로 실행 중인 바이너리를 확인하세요.
mihomo -v
# 如果机器上运行的是旧名称的二进制，也应先看它自己的版本
clash -v기록할 때 "최신 버전"이라고만 쓰지 마세요
- 클라이언트 이름과 버전
- 코어 표시가 Mihomo, Clash Meta, Clash 중 무엇인지
- 코어의 정확한 버전 번호
- 운영체제와 CPU 아키텍처
- 오류 발생 시 실제로 불러온 설정 파일
설정 형식이 비슷해도 서로 다른 코어에서 그대로 오갈 수는 없습니다
Mihomo는 proxies, proxy-groups, rules 같은 핵심 구조를 이어받아 기본 설정이 익숙해 보입니다. 하지만 이후 프로토콜, DNS, TUN, 규칙 세트, 스니핑, 런타임 필드가 추가되거나 확장되었습니다.
구형 코어가 알 수 없는 내용을 만나면 unknown field, unsupported proxy type 오류를 내거나 일부 필드를 그대로 무시해 알아차리기 어려운 동작 차이를 남길 수 있습니다.
이전 설정을 새 코어로 옮길 때도 조정이 필요할 수 있습니다. 이전 설정에서 쓰던 동작, 스크립트 기능, 클라이언트 생성 필드가 바뀌었다면 Mihomo에서 다시 검증해야 합니다. YAML을 열 수 있다는 것만으로 호환성을 판단하지 마세요. 설정 검사를 통과하고 그룹 참조가 완전하며 규칙 일치와 DNS 결과가 예상과 같아야 합니다.
같은 구독에서 차이가 가장 쉽게 생기는 부분
| 구분 | Original Clash 환경 | Mihomo 환경 | 마이그레이션 방법 |
|---|---|---|---|
| 노드 프로토콜 및 전송 | 구형 코어와 버전에 따라 다르며 당시 지원하던 필드만 인식 | 더 다양한 프로토콜과 전송 옵션을 계속 추가하고 유지 관리 | unsupported proxy type이 나타나면 코어를 확인하고 억지로 맞추려고 노드 필드를 삭제하지 않기 |
| DNS | 서로 다른 오픈 소스/Premium 버전은 기능과 필드가 완전히 같지 않음 | 현재 문서에 완전한 DNS, Fake-IP, nameserver 옵션이 포함됨 | 최소 DNS 설정을 먼저 유지하고 Fake-IP 필터와 상위 서버를 하나씩 이전 |
| TUN | 사용 가능 여부는 구형 분기, 버전, 클라이언트 통합 방식에 따라 달라짐 | 현재 Mihomo와 주요 클라이언트에서 TUN을 일반적으로 제공 | 시스템 프록시로 먼저 검증한 뒤 TUN과 서비스 권한을 따로 활성화 |
| 규칙 및 Provider | 구형 코어는 자신이 인식하는 규칙 유형과 구조만 허용 | 현재 문서에 정의된 규칙, 규칙 세트, 확장 필드 지원 | rule-provider behavior, 정책 그룹 이름, 최종 병합 결과 확인 |
| 클라이언트 추가 필드 | 구형 GUI의 Mixin, Parsers 또는 스크립트가 생성했을 수 있음 | 새 클라이언트의 Merge, Script 또는 덮어쓰기가 생성 | 원래 용도에 맞게 다시 만들고 클라이언트 전용 설정을 통째로 복사하지 않기 |
unknown field
흔한 원인:현재 코어가 필드를 인식하지 못하거나 필드가 잘못된 계층에 있음
해결 방법:콜론을 지우며 시행착오를 겪지 말고 실제 코어 버전의 공식 문서와 대조하세요.
unsupported proxy type
흔한 원인:프로토콜 또는 전송 기능이 현재 코어 지원 범위를 벗어남
해결 방법:서비스 제공자가 요구하는 유지 관리 중인 코어로 업그레이드하거나 호환되는 노드를 사용하세요.
proxy/group not found
흔한 원인:정책 그룹, 규칙 또는 덮어쓰기가 참조하는 이름이 없음
해결 방법:원본 구독만 보지 말고 최종 병합 설정을 확인하세요.
불러오기는 되지만 규칙 동작이 다름
흔한 원인:DNS, 규칙 순서 또는 클라이언트 덮어쓰기가 실행 결과를 변경함
해결 방법:연결 기록에서 같은 도메인에 적용된 규칙과 출구를 비교하세요.
새 환경에는 유지 관리 중인 Mihomo를 우선 사용하고 구형 코어는 명확한 레거시 요구가 있을 때만 남기세요
지금 데스크톱 클라이언트, 라우터 플러그인 또는 서버 서비스를 새로 설치한다면 Mihomo 사용을 명시하고 공식 릴리스와 문제 추적이 계속되는 프로젝트를 우선 선택하세요. 이는 이름이 바뀌면 자동으로 빨라져서가 아니라 현재 시스템과의 호환성, 보안 수정, 문서 일관성을 확보하기 위한 선택입니다.
Original Clash를 유지할 합리적인 경우는 대체로 매우 제한적입니다. 특정 오프라인 환경이 동결되어 있고 설정이 기존 기능만 사용하며 업그레이드 위험이 이점보다 큰 경우입니다. 이때도 바이너리 출처, 버전, 롤백 방법을 기록하고 구형 코어를 인터넷에 공개된 제어 서비스로 계속 노출해서는 안 됩니다.
- OpenWrt 사용자
- LuCI 화면만 업그레이드하지 말고 플러그인 버전, Mihomo 코어 아키텍처, 사용 가능한 저장 공간을 함께 확인하세요.
- 서버 또는 컨테이너 배포
- 명확한 버전을 고정하고 시험용 디렉터리에서 설정 검사를 실행한 뒤 운영 인스턴스를 교체하세요.
- 레거시 원본 환경
- 격리와 롤백 가능성을 유지하고 새 프로토콜 구독을 구형 코어에 바로 전달하지 마세요.
기존 설정을 Mihomo로 이전하기: 백업, 설정 검사, 실제 연결 테스트
설정 하나를 안전하게 이전하는 순서
기존 설정 보관
기존 설정, 코어 버전, 반복해서 접속할 수 있는 시험 주소 모음을 백업합니다.
클라이언트 전용 항목 제거
구형 GUI의 창, 캐시, 서비스 설정을 Mihomo 설정으로 간주해 복사하지 마세요.
설정 검사부터 실행
실제로 선택한 Mihomo 바이너리로 별도의 테스트 디렉터리에서 후보 설정을 검사하세요. 명령 예시는 아래에 있습니다. 실제로 보고된 첫 번째 구문 분석, 자료형 또는 참조 오류부터 해결하고 한 구간을 통째로 삭제하지 마세요.
같은 노드로 고정
일상적인 사이트와 내부 도메인부터 비교하세요. 시스템 프록시를 읽지 않는 앱은 다음 단계에서 TUN을 켠 뒤 테스트합니다.
그다음 DNS와 TUN 확장 기능 활성화
한 번에 한 계층만 바꾸고 연결 기록, 규칙 일치, 종료 후 네트워크 복원을 살펴봅니다.
아래 명령은 Mihomo v1.19.32의 매개변수를 사용한 예시입니다. 바이너리와 두 절대 경로를 실제 위치로 바꾸세요. 테스트 디렉터리에는 후보 설정에 필요한 신뢰할 수 있는 Provider 및 데이터 파일 사본이 있어야 하며, 실행 중인 작업 디렉터리를 가리켜서는 안 됩니다.
-t는 설정 검사 후 종료하고 -d는 작업 디렉터리를, -f는 설정을 지정합니다. 초기화 과정에서 테스트 디렉터리에 쓰거나 필요한 리소스를 가져올 수 있으므로 완전한 읽기 전용은 아닙니다. 성공 메시지는 설정 검사를 통과했다는 뜻일 뿐이며 연결, 규칙, 종료 후 네트워크 복구는 별도로 확인해야 합니다. 검사를 통과해도 알 수 없는 필드나 이전 클라이언트 전용 필드가 지원된다는 뜻은 아니므로 해당 버전의 문서를 대조해야 합니다.
mihomo -t -d '/absolute/path/to/test-data' -f '/absolute/path/to/candidate.yaml'마이그레이션 완료 기준은 클라이언트에 "연결됨"이 표시되는지가 아닙니다. 기존 환경의 주요 트래픽이 새 코어에서 예상 규칙에 맞고, LAN과 내부 도메인이 계속 직접 연결되며, 시스템 프록시 또는 TUN을 끈 뒤 네트워크가 복원되어야 합니다. 이 결과를 확인한 다음 기존 바이너리와 서비스를 삭제하세요.