Clash Meta(Mihomo) 업그레이드 가이드: 신기능·마이그레이션

Clash Meta와 Mihomo 명칭 변경이란

Clash Meta는 MetaCubeX 팀이 유지 관리하는 Clash 코어의 확장판입니다. 원본 Clash의 공식 유지보수 종료 이후, 활발한 커뮤니티와 지속적인 업데이트 덕분에 Clash Meta는 가장 널리 쓰이는 대체 코어로 자리 잡았습니다. 2024년부터 GitHub 저장소 이름이 Mihomo로 바뀌었지만, 핵심 기능과 설정 형식은 이전과 완전히 호환되므로 기존 사용자는 마이그레이션 부담이 거의 없습니다.

이번 명칭 변경은 단순한 브랜딩이 아니라, 프로젝트가 「Clash 호환 코어」에서 보다 독립적이고 성숙한 프록시 도구 체계로 나아간다는 신호이기도 합니다. 최신 Mihomo는 예전 Clash 기능을 그대로 따라 하는 데 그치지 않고 차세대 프록시 프로토콜을 적극 수용하고, 규칙 엔진·DNS 하위 시스템·메모리 관리를 대폭 개편하여 초기 버전 대비 성능과 안정성이 눈에 띄게 좋아졌습니다.

아직 구형 Clash 코어를 쓰거나 오래된 Clash Meta 빌드에 머물고 있다면, 지금이 최신 Mihomo로 올릴 좋은 시점입니다. 이 글에서는 Windows, macOS, Android를 예로 들어 업그레이드 절차를 단계별로 안내하고, 새 버전이 가져온 세 가지 핵심 프로토콜 지원을 자세히 설명합니다. 기초 설정이 더 필요하면 Clash 사용 문서와 함께 보시면 이해가 빨라집니다.

업그레이드 전 준비

본격적으로 올리기 전에 몇 가지만 점검해 두면 전체 이전 과정이 훨씬 매끄럽습니다.

1. 기존 설정 파일 백업

현재 사용 중인 config.yaml과 연결된 규칙 파일 전체를 안전한 위치(바탕화면, 클라우드 등)에 복사해 두세요. 여러 프로필을 쓰는 경우에는 파일마다 버전이나 날짜를 붙여 구분해 두면 롤백할 때 찾기 쉽습니다.

2. GUI 클라이언트 버전 확인

그래픽 클라이언트마다 Mihomo 코어 지원 시점이 다릅니다. 업그레이드 전에 사용 중인 앱이 최신 Mihomo와 맞는지 확인하세요. 클라이언트 다운로드 페이지에서는 검증된 최신 패키지를 제공하므로, GUI와 코어를 함께 갱신하면 버전 불일치로 실행이 안 되는 문제를 줄일 수 있습니다.

3. 구독 링크 호환성

대부분의 서비스에서 제공하는 구독 URL 형식은 Mihomo와 그대로 호환됩니다. 다만 극히 일부 구형 포맷(예: 구버전 Shadowsocks만 포함)은 파싱 오류가 날 수 있습니다. 업그레이드 후 노드가 비어 있다면 아래 「자주 묻는 마이그레이션 질문」 절을 참고하세요.

참고: Mihomo는 정상적인 원본 Clash 설정 필드와 완전 하위 호환입니다. 기존 YAML을 필드 하나도 고치지 않고 그대로 새 버전에 넣어도 됩니다.

플랫폼별 업그레이드 절차

Windows

클라이언트를 연 뒤 「정보」 또는 「코어 설정」에서 현재 Mihomo 코어 버전을 적어 둡니다.
다운로드 페이지에서 최신 Windows용 설치 파일을 받습니다(최신 Mihomo 코어 포함).
실행 중인 Clash를 완전히 종료합니다(트레이 아이콘에서 종료).
설치 마법사를 따라 진행하면 코어 파일이 자동으로 교체되며, 수동으로 덮어쓸 필요가 없습니다.
설치 후 앱을 다시 켜 「정보」에서 버전이 올라갔는지 확인합니다.
「지연 테스트」나 연결 점검으로 노드가 정상인지 확인합니다.

macOS

ClashX Meta, Mihomo Party 등 GUI를 쓰는 경우, 사이트에서 받은 최신 .dmg를 열고 응용 프로그램 폴더에 덮어쓰기만 하면 됩니다.

Homebrew로 코어를 관리한다면 터미널에서 다음을 실행합니다.

# Stop the existing service
brew services stop mihomo
# Update package to latest version
brew upgrade mihomo
# Restart the service
brew services start mihomo

「개발자를 확인할 수 없음」이 뜨면 시스템 설정 → 개인 정보 보호 및 보안에서 「그래도 열기」를 선택합니다.
설정 파일은 수정 없이 그대로 사용할 수 있습니다.

Android

Android 사용자는 다운로드 페이지에서 최신 APK를 받아 덮어쓰기 설치하는 것이 가장 간단합니다. 대부분의 앱은 프로필과 구독을 유지하므로 다시 가져올 필요가 없습니다. 설치 후 「정보」에서 코어 버전이 최신인지 확인하세요.

주의: Android 14 이상에서는 알 수 없는 출처 앱 설치 권한이 꺼져 있으면 APK 설치가 차단될 수 있으니, 설치 전에 해당 권한을 켜 두세요.

Hysteria2: 고속·저지연에 강한 프로토콜

Hysteria2는 Mihomo에 들어온 뒤 인기가 높은 프로토콜 중 하나입니다. QUIC 위에서 동작하며, 높은 패킷 손실과 지연이 잦은 회선에 맞춰 튜닝되어 있습니다. 일부 환경에서는 기존 TCP 기반 프록시보다 처리량이 수 배까지 나오기도 해서, 국제 회선 품질이 들쭉날쭉할 때 특히 유리합니다.

Hysteria2의 장점

손실에 강함: UDP/QUIC 기반이라 패킷 손실률이 30%에 가까워도 체감 속도가 비교적 안정적입니다.
빠른 연결: QUIC의 0-RTT 특성으로 TLS over TCP 방식보다 세션 수립이 빠릅니다.
트래픽 특성: 겉보기에는 일반 HTTPS와 유사해 DPI에 덜 걸리기 쉽습니다.
네이티브 지원: 별도 플러그인 없이 config.yaml에 노드 타입만 선언하면 됩니다.

Hysteria2 설정 예시

config.yaml의 proxies 블록에 다음과 같이 추가합니다.

proxies:
  - name: "HY2-Node"
    type: hysteria2
    server: your-server.example.com
    port: 443
    password: "your-password"
    sni: your-server.example.com
    skip-cert-verify: false
    up: "100 Mbps"
    down: "200 Mbps"

up과 down은 클라이언트 상·하향 대역폭을 알려 주는 값으로, 실제 회선에 맞게 적어 두면 Hysteria2의 혼잡 제어에 도움이 됩니다.

TUIC v5: 짧은 연결이 많을 때 유리

TUIC(Transparent UDP in TCP Carrier) v5 역시 QUIC 계열의 현대적 프로토콜로, 핸드셰이크 지연이 낮고 연결 재사용 효율이 좋습니다. Hysteria2가 대역폭 극대화에 더 치중한다면, TUIC v5는 웹 탐색·메신저·동시 요청이 많은 앱처럼 짧은 연결이 반복되는 패턴에 잘 맞습니다.

Mihomo에서는 별도 확장 없이 아래 형식으로 바로 쓸 수 있습니다.

proxies:
  - name: "TUIC-Node"
    type: tuic
    server: your-server.example.com
    port: 443
    uuid: "your-uuid-here"
    password: "your-password"
    version: 5
    alpn:
      - h3
    congestion-controller: bbr
    udp-relay-mode: native

congestion-controller: bbr는 많은 환경에서 처리량이 좋은 BBR을 쓰도록 하고, udp-relay-mode: native는 게임·화상처럼 UDP 지연이 중요한 경우에 적합한 네이티브 릴레이 모드입니다.

VLESS + Reality: 은닉성을 중시할 때

VLESS+Reality는 검열 회피 관점에서 매우 강력한 조합으로 평가받습니다. 실제 웹사이트의 TLS 지문을 「빌려」 쓰기 때문에, 겉으로는 평범한 HTTPS 세션과 구분하기 어렵습니다.

전통적인 난독화와 달리 서버가 해당 도메인의 실제 인증서를 소유할 필요 없이, 마이크로소프트·Cloudflare 등 공개 TLS 지문과 X25519 키 쌍으로 인증을 마칩니다. 이 덕분에 트래픽이 일반 웹과 섞여 보이는 효과를 기대할 수 있습니다.

VLESS+Reality 설정 예시

proxies:
  - name: "VLESS-Reality"
    type: vless
    server: your-server.example.com
    port: 443
    uuid: "your-uuid-here"
    network: tcp
    tls: true
    udp: true
    flow: xtls-rprx-vision
    servername: www.microsoft.com
    reality-opts:
      public-key: "your-public-key"
      short-id: "your-short-id"

flow: xtls-rprx-vision는 XTLS Vision 경로를 켜는 필드이며, TLS 내부 패턴을 다듬어 탐지 위험을 줄이는 데 쓰입니다. servername에는 지문을 빌릴 정상 사이트 도메인을, public-key와 short-id는 서버에서 내려준 값을 넣습니다.

정리: 세 프로토콜은 용도가 조금씩 다릅니다. 회선이 거칠고 처리량이 필요하면 Hysteria2, 짧은 연결이 잦으면 TUIC v5, 은닉·우회 난이도가 최우선이면 VLESS+Reality를 우선 검토하면 됩니다.

규칙 엔진과 DNS 개선

프로토콜 외에도 Mihomo는 규칙 엔진과 DNS를 손봐서, 일상 사용에서 체감이 큰 경우가 많습니다.

규칙 매칭 성능

새 엔진은 해시 기반 매칭을 써서 수만 줄짜리 규칙 세트(예: Loyalsoldier 류)에서도 이전보다 빠르게 판정하고, 메모리 사용도 줄였습니다. 복잡한 규칙을 켜 두어도 시스템 부담이 상대적으로 작습니다.

세분화된 DNS 라우팅

도메인 접미사, geosite 집합, 사용자 규칙별로 서로 다른 업스트림 DNS를 지정할 수 있어, 혼합 환경에서의 DNS 오염·누락을 줄이기 쉽습니다. 아래는 참고용 DNS 템플릿입니다.

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - localhost.ptlogin2.qq.com
  nameserver:
    - https://223.5.5.5/dns-query
    - https://119.29.29.29/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    geosite:
      - gfw

예시에서는 nameserver에 상대적으로 가까운 DoH를 두고, fallback에 글로벌 DoH를 두었으며, fallback-filter가 GeoIP·GeoSite로 fallback 전환 시점을 조절합니다. 한국에서 주로 쓰신다면 nameserver를 신뢰하는 국내 또는 자주 쓰는 공용 DoH로 바꿔도 됩니다. 오픈소스 코어·이슈 트래커는 필요할 때 Mihomo GitHub 저장소에서 확인할 수 있으며, 설치 패키지는 여전히 사이트 다운로드 페이지를 우선하는 것이 편합니다.

GeoIP·GeoSite 데이터 갱신

Mihomo는 geoip.dat와 geosite.dat로 지역 기반 규칙을 판단합니다. 앱 업데이트와 함께 데이터도 갱신되므로, 가끔 최신 빌드로 올려 두면 국내 사이트가 잘못 프록시를 타거나 해외 서비스가 막히는 오판을 줄일 수 있습니다.

자주 묻는 마이그레이션 질문

구형 Clash나 이전 Clash Meta에서 Mihomo로 넘어올 때 자주 나오는 문제와 대응을 모았습니다.

Q: 업그레이드 후 「unknown config field」로 실행이 안 됩니다

특정 GUI 전용 필드(예: 원 Clash for Windows의 clash-for-windows 블록)가 남아 있으면 발생할 수 있습니다. 표준이 아닌 블록을 삭제하거나 주석 처리한 뒤 설정을 다시 불러오면 대부분 해결됩니다.

Q: 기존 구독을 그대로 써도 되나요?

대부분 그대로 사용 가능합니다. 구독 안에 구형 Shadowsocks 옵션이나 폐기된 VMess 매개변수가 섞여 있으면 일부 노드만 파싱 실패할 수 있으나, 나머지 노드는 정상입니다. 대량으로 실패하면 서비스에 포맷 업데이트를 요청하세요.

Q: Mihomo와 원본 Clash 설정 형식 차이는?

프록시·프록시 그룹·규칙·DNS·TUN 등 핵심 키는 동일하게 쓸 수 있고, Mihomo는 hysteria2, tuic, vless 타입과 reality-opts, 실험적 ssh 등을 추가로 지원합니다. 옛 설정은 통상 수정 없이 그대로 동작합니다.

Q: TUN 모드가 업그레이드 후 안 됩니다

Windows는 관리자 권한, Linux·macOS는 루트(또는 권한 부여)가 필요합니다. tun 블록도 아래처럼 맞는지 확인하세요.

tun:
  enable: true
  stack: system      # or "gvisor" as alternative
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - "any:53"

gvisor에서 문제가 나면 system으로 바꿔 보세요.

Q: 지금 쓰는 Mihomo 코어 버전은 어떻게 보나요?

GUI라면 「정보」 화면에서 확인할 수 있습니다. CLI만 쓴다면 mihomo -v 또는 mihomo version으로 전체 버전 문자열을 볼 수 있습니다. 보안 패치와 호환을 위해 안정 채널 최신에 맞추는 것을 권장합니다.

위 가이드를 따라 오시면 Mihomo의 변화를 개략적으로 파악하셨을 것입니다. 이론상 최신 코어는 GitHub에서 받아 직접 배치해도 되지만, 실제로는 파일 교체·GUI 호환·새 프로토콜 파라미터 오타를 스스로 잡아야 해서 생각보다 시간이 드는 경우가 많습니다.

이 사이트에서 묶어 드리는 클라이언트는 그런 마찰을 줄이기 위한 선택지입니다. GitHub에서 직접 받는 것과 비교했을 때 대략 이런 점이 낫습니다.

호환 검증: 코어가 나올 때마다 여러 플랫폼에서 GUI와의 조합을 확인해, 가능한 한 바로 켜서 쓸 수 있는 빌드를 제공합니다.
구독 붙여 넣기로 시작: 앱을 열고 구독 URL을 넣고 「업데이트」만 누르면 대부분의 설정이 끝나 YAML을 손으로 짤 필요가 적습니다.
신규 프로토콜 내장: Hysteria2, TUIC v5, VLESS+Reality 파싱이 기본 포함되어 있어 노드만 지원하면 클라이언트가 알아서 맞춥니다.
DNS 누출 완화: 비교적 안전한 DNS 방향을 기본에 가깝게 잡아, 모르는 사이에 로컬 DNS로 새어 나가는 위험을 줄입니다.
플랫폼 간 동일한 구독 흐름: Windows, macOS, Android, iOS, Linux용 빌드가 갖춰져 있어 같은 구독 링크를 기기마다 반복해서 넣기 쉽습니다.

클라이언트가 오래됐거나 연결이 자주 끊기고 프로토콜 미지원 메시지가 난다면, 다운로드 페이지에서 OS에 맞는 패키지를 고르고 무료로 받아 보세요. 다른 도구에 비해 설정 일관성과 안정성 면에서 Clash 계열이 여전히 편한 경우가 많습니다.

→ Clash를 무료로 내려받고, 더 매끄러운 연결을 직접 경험해 보세요

Clash Meta와 Mihomo 명칭 변경이란

업그레이드 전 준비

1. 기존 설정 파일 백업

2. GUI 클라이언트 버전 확인

3. 구독 링크 호환성

플랫폼별 업그레이드 절차

Windows

macOS

Android

Hysteria2: 고속·저지연에 강한 프로토콜

Hysteria2의 장점

Hysteria2 설정 예시

TUIC v5: 짧은 연결이 많을 때 유리

VLESS + Reality: 은닉성을 중시할 때

VLESS+Reality 설정 예시

규칙 엔진과 DNS 개선

규칙 매칭 성능

세분화된 DNS 라우팅

GeoIP·GeoSite 데이터 갱신

자주 묻는 마이그레이션 질문

Q: 업그레이드 후 「unknown config field」로 실행이 안 됩니다

Q: 기존 구독을 그대로 써도 되나요?

Q: Mihomo와 원본 Clash 설정 형식 차이는?

Q: TUN 모드가 업그레이드 후 안 됩니다

Q: 지금 쓰는 Mihomo 코어 버전은 어떻게 보나요?

왜 사이트에서 제공하는 Clash 클라이언트를 쓸까요