Mihomo(Clash Meta) 코어란 무엇인가요?
Mihomo는 과거 커뮤니티에서 Clash Meta로 불리던 프록시 엔진의 후속 명칭으로 이해하시면 됩니다. 상용 Clash Premium과 달리, 오픈소스 생태계를 중심으로 빠르게 프로토콜 확장·DNS·라우팅 기능이 갱신되는 쪽이 바로 Meta 계열 코어입니다. 대부분의 최신 GUI 클라이언트(예: Clash Verge 계열, FlClash 등)는 기본 또는 선택 옵션으로 Mihomo 바이너리를 함께 배포하며, 사용자는 설정 파일(YAML)과 구독만 맞으면 동일한 UI 경험을 유지한 채 코어만 교체할 수 있습니다.
이름이 Meta에서 Mihomo로 바뀐 이유는 상표·브랜딩 측면의 정리 때문이며, 사용자 입장에서는 구성 키 이름·지원 프로토콜·릴리스 채널이 조금씩 진화했다고 보면 됩니다. 본 가이드에서는 익숙한 표현인 「Clash Meta」와 공식 쪽에서 강조하는 「Mihomo」를 같은 계열 코어로 통칭해 설명합니다.
왜 지금 코어 업그레이드를 고려해야 할까요?
첫째, 구독 제공자가 새 프로토콜(예: VLESS + REALITY, Hysteria2, TUIC v5 등)을 도입할 때 레거시 Clash 코어는 단순히 해당 아웃바운드 스키마를 해석하지 못해 프로필 로딩 단계에서 실패하는 경우가 많습니다. 둘째, DNS 스니핑·가짜 IP 필터링·규칙 세트(rule-set) 같은 기능은 최신 코어에서 의미 있게 동작하는 경우가 많아, 동일한 YAML이라도 구버전에서는 기대한 대로 트래픽이 나뉘지 않을 수 있습니다. 셋째, TUN·스택 모드 등 시스템 레벨 프록시를 쓰는 환경에서는 코어 버그 수정과 커널·OS 업데이트에 맞춘 패치가 빠른 쪽이 유지보수 부담을 줄여 줍니다.
반대로, 아주 오래된 단말이나 기업 정책으로 인해 서명된 바이너리만 허용되는 환경이라면, GUI가 Mihomo를 번들로 넣더라도 실행 자체가 막힐 수 있습니다. 이때는 IT 정책과 충돌하지 않는지 먼저 확인한 뒤 전환 일정을 잡는 것이 안전합니다.
핵심 신기능과 체감 포인트
아래는 Mihomo 코어를 쓰면서 실사용에서 자주 언급되는 변화입니다. 세부 키 이름은 릴리스마다 조정될 수 있으므로, 최종 확인은 사용 중인 클라이언트가 끌어오는 코어 버전의 공식 문서·릴리스 노트를 함께 보시기 바랍니다.
| 영역 | 설명 |
|---|---|
| 프로토콜·전송 | VLESS, REALITY, Hysteria2, TUIC 등 최신 스택에 대한 파서·다이얼 업데이트가 상대적으로 빠릅니다. |
| DNS | 분기 DNS, DOH/DOT, fake-ip와 규칙 연동, 스니핑 기반의 도메인 복원 등 세밀한 튜닝이 가능합니다. |
| 규칙·데이터소스 | 대용량 GEO·도메인 목록을 rule-set 형태로 외부에서 가져와 캐시하는 패턴이 보편화되어, 단일 YAML 비대화를 줄입니다. |
| TUN·스택 | 가상 인터페이스 기반 전역 라우팅과 게임·UDP 시나리오에서의 안정성 개선이 이슈 트래커 기준으로 활발합니다. |
| 관측·디버깅 | 내장 API·로그 토픽을 통해 어떤 규칙에 매칭됐는지 추적하기 쉬워, 「직접 연결로 새 나가는」 원인 분석이 수월해집니다. |
마이그레이션 전 준비: 백업과 호환성 점검
코어를 바꾸기 전에 반드시 작동 중인 프로필 전체를 별도 경로에 복사해 두세요. GUI를 쓰는 경우보내기 기능이 있으면 JSON·YAML 원본을 함께 저장하고, 수동 편집 중이라면 구독 URL·로컬 오버라이드 파일·규칙 프로바이더 캐시 디렉터리까지 포함하는 것이 좋습니다. Windows에서는 사용자 프로필 아래 앱 데이터 폴더, macOS에서는 ~/Library 계열, Linux에서는 ~/.config 등 클라이언트별 경로가 다르므로 공식 FAQ를 한 번 확인하십시오.
호환성 측면에서는 다음을 순서대로 점검합니다. (1) proxies·proxy-groups에 쓰인 타입 문자열이 현재 코어에서 지원되는지, (2) rules와 rule-providers URL이 만료·차단되지 않았는지, (3) 커스텀 스크립트나 외부 전처리기(일부 포크 전용)에 의존하는지입니다. 세 번째가 있다면 Mihomo 단독으로는 동일 동작을 보장하기 어려우므로, 해당 확장을 대체할 수 있는지 먼저 검토해야 합니다.
단계별 마이그레이션 절차
-
1단계: 클라이언트에서 코어 종류를 Mihomo로 지정
설정 화면의 「Core」「클러스터」「실행 파일」 등에 해당하는 메뉴에서 Meta/Mihomo 번들을 선택합니다. 이미 최신 GUI라면 기본값이 Meta 계열인 경우가 많습니다. 수동으로 바이너리를 교체하는 고급 모드는 체크섬·서명 검증 후 진행하세요. -
2단계: 프로필 검증(드라이 런)
실제로 시스템 프록시나 TUN을 켜기 전에, 로컬 API 또는 내장 검사기로 YAML 파싱 오류가 없는지 확인합니다. 오류 메시지에 나오는 줄 번호를 기준으로 스키마를 수정합니다. -
3단계: DNS 블록부터 좁은 범위로 전환
기존 설정이redir-host계열이었다면fake-ip로 즉시 바꾸기보다, 먼저 DNS 질의 경로만 Mihomo 쪽 리졸버로 옮기고 앱별 이상 여부를 봅니다. 사내 포털·은행·스트리밍 등 예민한 도메인이 있다면 예외 규칙을 미리 추가합니다. -
4단계: TUN·스택 모드는 마지막에
시스템 프록시만으로 충분한 사용자는 TUN을 켜지 않아도 됩니다. 게임·터미널 도구까지 한 번에 넣고 싶을 때 TUN을 켜며, 이때는 방화벽 허용·DNS 하이재킹·라우팅 테이블 충돌을 순서대로 확인합니다. -
5단계: 구독 갱신과 캐시 정리
구독 노드가 갱신되면서 이전 캐시 규칙이 남아 충돌하는 경우가 있습니다. rule-provider 캐시를 비우고 앱을 재시작하면 깨끗한 상태에서 다시 받아옵니다.
YAML에서 자주 걸리는 차이점
구버전 예제를 그대로 가져오면 다음과 같은 지점에서 막히는 경우가 많습니다. 첫째, 특정 프록시 필드 이름이 새 스키마에서 바뀌었거나 필수값이 추가된 경우입니다. 둘째, rule-providers의 behavior와 실제 파일 형식이 맞지 않으면 로딩에 실패합니다. 셋째, 정책 그룹의 use·proxies 나열 순서가 잘못되면 UI에서는 보이지만 실제 매칭 경로가 의도와 다를 수 있습니다. 넷째, 로컬에서만 쓰던 비표준 주석 블록이 일부 파서에서 경고를 내는 경우가 있어 CI나 자동 검증 파이프라인이 있다면 경고를 오류로 취급할지 정책을 맞춰야 합니다.
이런 문제를 줄이려면 공개 템플릿을 가져올 때 발행일과 코어 버전을 함께 기록하고, 분기별로 한 번씩 diff를 보는 습관이 좋습니다. 더 익숙한 단계가 되면 문서 허브의 고급 설정 파트와 대조해 자신만의 「허용된 키 목록」을 만들어 두면 팀 단위 운영에도 도움이 됩니다.
문제 해결 체크리스트
증상: 프로필이 로드되지 않고 파싱 오류가 난다
로그에 표시된 키를 기준으로 해당 proxies 항목을 최소 구성으로 줄여 보면서 다시 로드해 보세요. 외부에서 가져온 긴 파일이라면 문제 구간을 이진 탐색처럼 절반씩 주석 처리해 범위를 좁힙니다.
증상: 규칙상 프록시인데 특정 앱만 직통한다
앱이 시스템 프록시를 무시하는 경우가 흔합니다. TUN을 켤 수 있는 환경이라면 TUN으로 옮기고, 아니면 해당 앱만 별도 SOCKS/HTTP 프록시 환경 변수를 지정합니다. DNS가 로컬 리졸버를 고집한다면 스니핑·리다이렉트 설정을 함께 봐야 합니다.
증상: 첫 연결만 유난히 느리다
대형 rule-set을 cold start 할 때 지연이 생길 수 있습니다. 프로바이더 URL의 응답 속도·디스크 캐시 위치·백그라운드 업데이트 주기를 조정하고, 불필요하게 중복된 GEO 규칙 세트를 여러 번 불러오지 않도록 정리합니다.
오픈소스 저장소와 설치 패키지
Mihomo·관련 GUI는 커뮤니티가 GitHub 등에서 소스와 이슈 트래커를 공개하는 경우가 많아, 변경 이력과 보안 공지를 직접 추적할 수 있습니다. 다만 일반 사용자가 실행 파일을 받는 주 경로는 여전히 신뢰할 수 있는 배포 채널을 쓰는 것이 안전합니다. 본 사이트에서는 플랫폼별 클라이언트를 한곳에 모아 두었으므로, 코어 버전 확인·재설치·업데이트는 다운로드 페이지를 우선 참고하시고, 라이선스·소스 코드는 별도 단락에서 안내하는 저장소 링크를 통해 보시면 혼선이 적습니다.
정리: 업그레이드 이후에 얻는 실사용 이점
Mihomo로 코어를 맞춰 두면 동일한 구독이라도 신규 전송 방식·세밀한 DNS·대규모 규칙 세트를 안정적으로 소화할 수 있어, 「갑자기 노드가 안 잡힌다」류의 장애 빈도를 줄이는 데 도움이 됩니다. 마이그레이션은 한 번에 모든 실험적 옵션을 켜기보다, 백업과 단계적 검증을 전제로 천천히 옮기는 편이 결과적으로 시간을 아낍니다.
다른 경량 클라이언트를 쓰다가 설정 분산이나 업데이트 지연 때문에 피로감을 느꼈다면, 코어를 최신으로 유지하면서 UI·멀티 플랫폼 지원이 정돈된 배포를 쓰는 쪽이 운영 면에서 유리한 경우가 많습니다. 실제 체감은 환경마다 다르지만, 규칙 기반 분기와 TUN을 함께 다룰 수 있는 쪽이 장기적으로 확장 여지가 큽니다. 동일한 구독이라도 Mihomo 최신 빌드와 잘 맞는 클라이언트를 쓰면 장애 대응 시간이 줄고, DNS·규칙 튜닝 여지도 넓어집니다.