Clash 오리지널·Meta·mihomo의 관계는? 커널 버전 차이와 선택 가이드

클라이언트·커널·설정 파일부터 구분하기

Clash 버전을 이야기할 때 가장 자주 혼동하는 개념은 “클라이언트”와 “커널”입니다. 데스크톱 창, 트레이 메뉴, 구독 버튼은 그래픽 클라이언트에 해당하고, 프록시 연결을 만들고 규칙을 매칭하며 DNS를 처리하고 트래픽을 가로채는 실행 프로그램이 커널입니다. Clash Verge Rev, Mihomo Party 같은 이름은 보통 클라이언트를 가리키며, Clash, Clash.Meta, mihomo는 클라이언트 내부에서 호출하는 커널을 뜻합니다.

설정 파일은 세 번째 계층입니다. 일반적인 YAML 파일에는 수신 포트, 프록시 노드, 프록시 그룹, 규칙, DNS 설정이 들어갑니다. 클라이언트가 설정을 내려받고 편집한 뒤 커널에 전달하면, 커널이 필드를 읽어 동작을 시작합니다. 따라서 인터페이스가 비슷한 두 클라이언트에 같은 구독을 넣어도 결과가 다를 수 있습니다. 한쪽은 오리지널 Clash를 사용하고 다른 쪽은 mihomo를 사용한다면, 인식할 수 있는 프로토콜과 필드가 완전히 같지 않기 때문입니다.

그래픽 클라이언트: 구독 관리, 시스템 프록시 전환, 노드 선택, 로그 확인, 커널 업데이트 등의 화면을 제공합니다.

프록시 커널: YAML 설정을 해석하고 연결을 만든 뒤, 규칙 매칭·DNS 조회·TUN 트래픽 처리를 수행합니다.

구독 변환: 서버에서 제공한 노드 정보를 특정 커널이 읽을 수 있는 설정 형식으로 정리할 뿐, 커널의 기능을 새로 만들어 내지는 못합니다.

규칙 세트: 도메인, IP, 프로세스 또는 네트워크 조건에 따라 요청을 프록시 그룹으로 보낼지, 직접 연결할지, 차단할지 결정합니다.

Clash 오리지널·Clash.Meta·mihomo의 관계

오리지널 Clash: 규칙 기반 프록시 체계의 출발점

일반적으로 말하는 “오리지널 Clash”는 Dreamacro가 유지 관리한 Clash 프로젝트를 뜻합니다. 이 프로젝트는 현재도 널리 사용되는 설정 구조를 정립했으며, 여기에는 proxies, proxy-groups, rules, proxy-providers, rule-providers가 포함됩니다. 기본 예시에서 HTTP 프록시 포트는 보통 7890, 외부 제어 인터페이스는 9090을 사용하며, 이러한 관례는 이후 많은 클라이언트에도 남아 있습니다.

오리지널 프로젝트는 2023년 11월 공개 유지 관리가 중단되었고, 관련 코드 저장소도 이후 아카이브되었습니다. 오리지널의 마지막 단계에서 흔히 보이는 버전 표기는 v1.18.0입니다. 유지 관리가 중단되었다고 해서 기존 설치가 즉시 작동을 멈추는 것은 아닙니다. 이전 프로토콜, 기본 도메인 규칙, 일반적인 시스템 프록시는 계속 작동할 수 있지만, 새로운 프로토콜과 규칙 필드, 이후 운영체제의 네트워크 변경에는 더 이상 대응하지 않습니다.

역사적으로 Clash Premium도 존재했습니다. 오리지널을 기반으로 향상된 규칙과 TUN 관련 기능 등 더 많은 기능을 제공했지만, 오늘날 mihomo의 예전 이름은 아닙니다. 오래된 튜토리얼에서 “Premium 커널”이라는 표현을 보더라도 특정 과거 분기로 이해해야 하며, 현재의 mihomo와 곧바로 동일시해서는 안 됩니다.

Clash.Meta: Clash 설정과 호환되는 커뮤니티 확장 커널

Clash.Meta는 커뮤니티가 Clash 설정 체계를 바탕으로 계속 확장해 온 커널입니다. 오리지널의 많은 필드를 유지해 기존 규칙과 프록시 그룹을 적은 비용으로 이전할 수 있고, 동시에 더 많은 프록시 프로토콜과 규칙 유형, DNS 제어, TUN 기능을 추가했습니다. 사용자 관점에서 “Meta 설정”은 대개 오리지널에 정의되지 않은 확장 필드를 설정에 사용했다는 의미입니다.

여기서 말하는 호환성은 “mihomo가 오리지널 설정의 대부분을 읽을 수 있다”는 의미에 가깝지, 양방향 완전 호환을 뜻하지는 않습니다. DOMAIN-SUFFIX, IP-CIDR, GEOIP, MATCH 같은 기본 규칙만 사용할 때는 차이가 작지만, 설정에 VLESS, Hysteria2, TUIC, GEOSITE 또는 mihomo 전용 인바운드 필드가 들어가면 오리지널 커널이 오류를 내거나 해당 설정을 무시할 수 있습니다.

mihomo: Clash.Meta의 명칭 변경 이후 이어진 이름

mihomo는 Clash.Meta 다음에 등장한 낯선 별도의 커널이 아니라, Clash.Meta 프로젝트가 이름을 바꾼 뒤 사용하게 된 명칭입니다. 구형 클라이언트와 구독 변환 도구, 과거 문서에는 여전히 Clash.Meta로 표시될 수 있으며, 최신 배포 패키지와 로그, 설정 문서는 대체로 mihomo라는 이름을 사용합니다. “Meta 커널”과 “mihomo 커널”을 보았다면 우선 같은 커뮤니티 프로젝트의 서로 다른 시기 명칭으로 이해해야 하며, 둘 중 하나를 골라야 하는 별도 제품으로 볼 필요는 없습니다.

프로토콜·규칙·DNS·TUN 기능 차이

커널은 “웹페이지를 열 수 있는가”만으로 선택해서는 안 됩니다. 프로토콜 지원 여부는 노드 연결 가능성을 결정하고, 규칙 기능은 트래픽을 정확히 분배할 수 있는지를 결정하며, DNS와 TUN은 애플리케이션 적용 범위와 도메인 조회 경로에 영향을 줍니다. 아래는 실제 설정을 기준으로 정리한 차이입니다.

비교 항목	오리지널 Clash	mihomo
유지 관리 상태	원 프로젝트는 아카이브되었으며, 일반적으로 알려진 마지막 단계 버전은 v1.18.0입니다	커뮤니티에서 계속 유지 관리하며, 클라이언트도 보통 안정 버전을 따라 업데이트할 수 있습니다
기본 프로토콜	Shadowsocks, VMess, Trojan, HTTP, SOCKS5 등 주요 유형 지원	다양한 기본 유형과 호환되며 VLESS, TUIC, Hysteria2 등의 설정을 확장 지원
규칙 유형	도메인, IP, 포트, 프로세스 이름, 규칙 세트, MATCH 등 기본 매칭 지원	GEOSITE, IP-ASN, 네트워크 유형, 인바운드 유형 등 더 세분화된 조건 추가
DNS	nameserver, fallback, fake-ip 등 일반적인 메커니즘 제공	nameserver-policy, 규칙 연동 및 더욱 세밀한 조회 제어 확장
TUN	구형 분기마다 기능이 달랐으며, 과거 튜토리얼은 Premium에 의존하는 경우가 많습니다	지속적으로 유지 관리되는 TUN 구현을 제공하며 DNS 하이재킹과 라우팅 자동 설정을 함께 사용할 수 있습니다
최신 설정 대응	확장 필드를 만나면 실행되지 않을 수 있습니다	현재 구독과 계속 업데이트되는 규칙 템플릿에 더 적합합니다

프로토콜 지원: 노드 이름이 같아도 형식은 다를 수 있습니다

Shadowsocks, VMess, Trojan 같은 프로토콜은 오리지널과 mihomo 모두에서 폭넓게 사용되지만, 구체적인 암호화 방식과 전송 계층 매개변수, 확장 옵션은 설정 필드를 기준으로 확인해야 합니다. VLESS, Reality, Hysteria2, TUIC 같은 최신 노드 형식은 일반적으로 mihomo에서 처리해야 합니다. 구독을 가져온 뒤 노드 수가 눈에 띄게 줄거나 로그에 unsupported proxy type이 표시되면 먼저 커널이 너무 오래되지 않았는지 확인하세요.

구독 변환은 텍스트 구조만 바꿀 수 있습니다. 예를 들어 노드를 YAML의 proxies 목록으로 정리할 수는 있지만, 오리지널 커널이 갑자기 Hysteria2를 이해하게 만들 수는 없습니다. 노드 유형이 커널의 지원 범위를 벗어났다면 해당 프로토콜을 지원하는 커널이나 클라이언트로 바꾸는 것이 올바른 해결 방법이며, 구독 주소를 반복해서 수정할 문제는 아닙니다.

규칙 기능: 기본 규칙은 공통, 확장 규칙은 커널에 따라 다름

오리지널 Clash만으로도 대부분의 도메인 및 IP 분류를 처리할 수 있습니다. 다음은 흔히 사용하는 기본 규칙 예시입니다. 특정 도메인 접미사는 프록시 그룹으로 보내고, 사설 네트워크 주소는 직접 연결하며, 나머지 요청은 최종 정책으로 보냅니다.

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

mihomo는 여기에 더 세밀한 매칭 조건을 추가합니다. 예를 들어 GEOSITE는 도메인 분류 데이터를 참조하고, IP-ASN은 자율 시스템 번호로 매칭하며, NETWORK는 TCP와 UDP를 구분하고, IN-TYPE은 인바운드 유형에 따라 트래픽을 처리합니다. 복잡한 분류에는 유용하지만, 이러한 설정을 오리지널 커널에 넣었을 때 정상 작동한다고 보장할 수는 없습니다.

rules:
  - GEOSITE,category-ads-all,REJECT
  - NETWORK,udp,UDP-Proxy
  - IP-ASN,13335,Proxy,no-resolve
  - MATCH,Final

규칙은 위에서 아래로 매칭되며, 일치하면 이후 판단을 멈춥니다. 어떤 커널을 사용하든 구체적인 규칙을 포괄적인 규칙보다 앞에 배치하고 MATCH는 마지막에 두어야 합니다. 그렇지 않으면 커널이 고급 규칙을 지원하더라도 앞의 포괄적인 조건이 먼저 일치해 실행 기회를 얻지 못할 수 있습니다.

DNS: 서버 주소보다 조회 경로를 확인하기

오리지널 Clash는 이미 nameserver, fallback, fallback-filter, enhanced-mode 같은 핵심 설정을 제공합니다. mihomo는 이 필드들을 이어받고 도메인별 정책과 규칙 연동을 더욱 세밀하게 지원합니다. 실제로 이전할 때는 fake-ip와 redir-host 모드, 수신 주소, IPv6 활성화 여부, TUN 환경의 DNS 하이재킹 설정을 특히 확인해야 합니다.

일반적인 혼합 프록시 수신 포트는 7890이고, DNS 수신 예시는 0.0.0.0:1053을 사용할 수 있습니다. 포트는 고정된 표준이 아니므로 최종적으로 설정 파일과 클라이언트 화면을 기준으로 확인하세요. 로컬 프로그램이 이미 7890, 9090 또는 1053을 사용 중이면 커널 로그에 보통 address already in use가 표시됩니다. 이때는 충돌하는 포트를 변경해야 하며, 문제를 구독 탓으로 돌려서는 안 됩니다.

TUN: 더 많은 애플리케이션을 가로챌 수 있는지 결정

시스템 프록시는 프록시 설정을 직접 읽는 애플리케이션에 주로 적용되며, 일부 게임과 명령줄 프로그램, UDP 트래픽은 이를 우회할 수 있습니다. TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 시스템 트래픽을 가로채므로 커널의 네트워크 스택, 라우팅 설정, DNS 연동에 더 크게 의존합니다. 현재 TUN을 사용할 때는 mihomo를 선택하는 경우가 많습니다.

활성화 경로는 클라이언트마다 다릅니다. 일반적으로 「설정」→「네트워크 설정」→「TUN 모드」에 있거나, 메인 화면의 「서비스 모드」 및 「TUN」 스위치로 제공됩니다. Windows에서 처음 활성화할 때는 보통 관리자 권한이 필요하고, macOS에서는 네트워크 확장 승인 과정이 필요할 수 있으며, Linux에서는 올바른 CAP_NET_ADMIN 권한을 부여하거나 적절한 서비스 방식으로 실행해야 합니다. 활성화한 뒤에는 브라우저 페이지 하나만 확인하지 말고 로컬 네트워크 접근, DNS 조회, 절전 모드 복귀도 함께 점검해야 합니다.

기존 설정을 mihomo로 이전할 때 확인할 항목

오리지널에서 mihomo로 이전하는 작업은 보통 역방향보다 수월하지만, “실행된다”는 것은 첫 단계일 뿐입니다. 구독 제공자와 클라이언트, 로컬 오버라이드가 설정을 수정할 수 있으므로 정해진 순서에 따라 점검하는 것이 좋습니다.

먼저 실제 커널을 확인하세요. 클라이언트에서 「설정」→「커널」 또는 「설정」→「정보」를 열고 이름, 버전 번호, 아키텍처를 기록합니다. 명령줄 환경에서는 mihomo -v를 실행할 수 있으며, 구형 오리지널 실행 파일은 보통 clash -v를 사용합니다.
기존 설정 사본을 보관하세요. YAML, 규칙 세트 주소, 로컬 오버라이드, 직접 만든 프록시 그룹을 백업하세요. 구독 링크만 저장하면 로컬에서 추가한 규칙이 포함되지 않을 수 있습니다.
먼저 구문을 테스트하세요. mihomo에서는 mihomo -t -f config.yaml을 사용해 설정을 검사할 수 있습니다. 테스트 통과는 구조를 읽을 수 있다는 뜻일 뿐, 모든 원격 규칙 세트와 프록시 노드가 연결된다는 의미는 아닙니다.
프록시 그룹 참조를 확인하세요. 각 규칙 끝의 정책 이름은 proxy-groups에 존재해야 합니다. 예를 들어 규칙에 Proxy라고 적었는데 설정에는 “노드 선택”만 있다면 커널이 해당 정책을 찾지 못했다는 오류를 보고합니다.
외부 리소스를 점검하세요. proxy-providers, rule-providers, GEOIP 및 GEOSITE 데이터는 다운로드되어 캐시 디렉터리에 저장될 수 있어야 합니다. 업데이트에 실패하면 「설정」→「로그」를 열어 HTTP 상태 코드, 시간 초과 메시지, 파일 권한을 확인하세요.
마지막에 TUN을 활성화하세요. 먼저 시스템 프록시로 7890 수신, 노드 연결, 규칙 분류를 검증한 다음 TUN을 켜세요. 이렇게 하면 노드 문제와 시스템 라우팅 문제를 분리할 수 있습니다.

기본 설정의 호환성을 높게 유지하는 방법

여러 디바이스에서 설정을 공유해야 한다면 공통 부분은 기본 필드로 제한하고, mihomo 확장 기능은 별도의 오버라이드에 넣는 것이 좋습니다. 아래 골격은 혼합 포트 7890, 로컬 제어 인터페이스 127.0.0.1:9090, 규칙 모드를 사용하며 설정 구조를 점검하는 출발점으로 적합합니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - DIRECT

rules:
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

이 예시에는 실제 프록시 노드가 없으므로 Proxy 그룹에는 일단 DIRECT만 포함되어 있습니다. 실제로 사용할 때는 구독이나 로컬 설정을 통해 노드를 추가해야 합니다. 인터넷에서 받은 설정의 제어 인터페이스를 0.0.0.0:9090으로 바로 변경하지 마세요. LAN에서 제어해야 한다면 접근 키를 설정하고 방화벽 허용 범위도 제한해야 합니다.

2026년에 클라이언트를 설치할 때 어떤 커널을 선택해야 할까

새로 설치한다면 계속 유지 관리되고 mihomo 사용을 명확히 밝힌 클라이언트를 우선 선택하세요. 이름이 최신이어서가 아니라 현재의 노드 프로토콜, 규칙 데이터, DNS 동작, 운영체제 네트워크 변화에 계속 대응할 수 있기 때문입니다. 특히 구독에 VLESS, Reality, Hysteria2, TUIC이 포함되어 있거나 TUN, GEOSITE, IP-ASN을 사용할 계획이라면 mihomo가 설정의 기대 동작에 더 잘 맞습니다.

mihomo를 바로 선택하기 좋은 경우

Clash 계열 클라이언트를 처음 설치하고 이후 커널 수정과 기능 업데이트를 정상적으로 받고 싶은 경우
구독에 VLESS, Reality, Hysteria2 또는 TUIC 노드가 포함된 경우
TUN으로 게임, 명령줄 도구, UDP 또는 시스템 프록시를 읽지 않는 애플리케이션까지 가로채야 하는 경우
규칙에서 GEOSITE, IP-ASN, NETWORK, IN-TYPE 등의 확장 조건을 사용하는 경우
도메인별로 서로 다른 DNS 업스트림을 설정하거나 더 세밀한 fake-ip 제외 정책을 사용해야 하는 경우

여전히 오리지널을 유지할 수 있는 경우

격리된 환경에서 기존 설정이 안정적으로 실행되고 기본 프로토콜과 기본 규칙만 사용하는 경우
특정 구형 클라이언트와 자동화 스크립트가 오리지널 명령줄 매개변수에 고정적으로 의존하며, 이전 전에 호환성 테스트가 필요한 경우
단기간 동안 과거 문제를 재현해야 해 당시와 동일한 커널 및 설정 동작을 유지해야 하는 경우

이런 경우에는 오리지널을 새 디바이스의 기본 선택으로 삼기보다 “일단 유지하되 이전을 계획하는” 편이 적절합니다. 기존 환경의 클라이언트 버전, 커널 버전, 설정 출처, 포트 사용 현황을 최소한 기록해 두어야 기기 재설치 후에도 복원할 수 있습니다.

클라이언트 선택 시 확인할 여섯 가지

커널 이름과 버전: mihomo를 명확히 표시하고 「설정」→「커널」에서 현재 버전을 확인할 수 있어야 합니다.
설정 관리: 구독 원문, 로컬 오버라이드, 런타임 설정을 구분해 구독 업데이트가 수동 변경 사항을 덮어쓰지 않도록 해야 합니다.
로그 메뉴: 최소한 info, warning, error 수준을 제공하고 노드, DNS, 규칙 세트, 포트 오류를 확인할 수 있어야 합니다.
TUN 관리: 단순한 스위치만 제공하지 말고 서비스 상태, 필요한 권한, 실패 원인을 표시해야 합니다.
플랫폼 아키텍처: Windows는 x64와 ARM64를, macOS는 Apple Silicon과 Intel을 구분하고, Linux는 amd64·arm64 및 설치 방식을 확인해야 합니다.
업데이트 범위: 클라이언트 업데이트, 커널 업데이트, GEO 데이터 업데이트, 구독 업데이트를 각각 확인할 수 있어야 어느 계층에서 변경이 발생했는지 추적하기 쉽습니다.

자주 하는 오해와 점검 결론

“설정을 가져올 수 있다”가 “모든 필드가 적용된다”는 뜻은 아닙니다

YAML 구문이 올바르다는 것은 들여쓰기와 구조를 해석할 수 있다는 뜻일 뿐입니다. 일부 클라이언트는 가져오기 단계에서 알 수 없는 필드를 삭제하거나 로컬 오버라이드로 구독 내용을 대체하기도 합니다. 기능이 실제로 적용되었는지는 런타임 설정과 커널 로그를 확인해야 합니다. 예를 들어 GEOSITE를 입력했는데 규칙 매칭 기록이 전혀 없다면 규칙 데이터가 로드되었는지, 규칙 순서가 올바른지, 실제 커널이 해당 유형을 지원하는지 확인해야 합니다.

“Meta”와 “mihomo”는 병렬로 업그레이드되는 두 계열이 아닙니다

현재의 맥락에서 mihomo는 Clash.Meta가 이름을 바꾼 뒤 사용하는 프로젝트 명칭입니다. 다운로드할 때 이른바 “Meta 버전과 mihomo 버전의 성능 비교”를 찾을 필요는 없습니다. 실제로 확인해야 할 것은 출시일, 버전 번호, 프로세서 아키텍처, 그리고 클라이언트가 수년간 업데이트되지 않은 커널 파일을 계속 호출하고 있는지 여부입니다.

버전이 최신이어도 먼저 설정을 테스트해야 합니다

지속적으로 유지 관리되는 커널은 문제를 해결하지만 기본 동작을 조정하거나 필드를 폐기하고 설정 검사를 강화할 수도 있습니다. 업그레이드 전에는 설정을 내보내고, 업그레이드 후에는 구독 업데이트, 프록시 그룹, DNS, 시스템 프록시, TUN을 차례로 테스트해야 합니다. 기업 네트워크, 학교 네트워크, 로컬 DNS를 사용하는 환경에서는 특히 내부 도메인과 LAN 대역이 계속 직접 연결되는지도 확인하세요.

최종 선택은 한 문장으로 정리할 수 있습니다

새 디바이스와 새 설정에는 mihomo를 우선 사용하고, 기존 오리지널 환경에 업무상 의존성이 있다면 버전을 기록한 뒤 단계적으로 이전하세요. Clash.Meta와 mihomo는 주로 이름을 바꾸기 전후의 관계이며, 클라이언트 이름은 겉모습일 뿐입니다. 실제 프로토콜, 규칙, DNS, TUN 기능을 결정하는 것은 현재 실행 중인 커널입니다.