Clash 오리지널·Clash Meta·mihomo 커널 비교: 기능 차이와 설정 호환성

먼저 결론: Meta와 mihomo는 같은 프로젝트의 이름 변화입니다

새 설정을 선택할 때는 클라이언트 이름만 보지 말고 실제로 실행되는 커널부터 확인하세요. Clash 오리지널, Clash Premium, mihomo는 기능 범위가 서로 다릅니다. Clash Meta는 이후 mihomo로 이름이 바뀌었으므로 별도로 설치해야 하는 네 번째 커널이 아닙니다. 오래된 가이드의 ‘Meta 설정’은 대개 이 프로젝트의 설정 체계를 가리키지만, 세부 필드는 사용 중인 버전에 맞춰 확인해야 합니다.

기존 설정을 mihomo로 옮길 때 기본 노드, 정책 그룹, 일반적인 도메인 규칙은 대체로 그대로 사용할 수 있습니다. 다만 새 프로토콜, Premium 스크립트, DNS, TUN, 규칙 세트 형식은 별도로 점검해야 합니다. 반대 방향으로 옮기는 데는 제약이 더 큽니다. mihomo가 읽을 수 있는 설정이라고 해서 Clash 오리지널에서도 실행된다는 뜻은 아닙니다.

프로젝트 계보: Clash 오리지널, Premium, Meta, mihomo

Clash 오리지널과 Clash Premium

Clash 오리지널은 일반적으로 Dreamacro/clash의 오픈 소스 커널을 뜻합니다. Clash Premium은 원 프로젝트에서 제공한 비공개 강화 커널 브랜치로, 두 커널을 같은 기능을 갖춘 제품으로 보면 안 됩니다. 과거에는 TUN, 규칙 제공자, 스크립트 규칙 등이 Premium과 오픈 소스 오리지널의 차이를 보여주는 주요 기능이었습니다. 원 프로젝트는 2023년에 유지보수가 중단됐습니다. 기존 바이너리는 여전히 실행될 수 있지만, 새로운 프로토콜 지원을 계속 받기 위한 기반으로는 적합하지 않습니다.

Clash Meta와 mihomo

Clash Meta는 Clash 생태계에서 발전해 프로토콜과 라우팅 기능을 확장했으며, 이후 mihomo로 이름이 바뀌었습니다. 폴더명이나 구독 안내, 구형 화면에 Meta라는 이름이 남아 있다고 해서 커널이 반드시 오래된 것은 아닙니다. 실제 바이너리의 버전 정보와 해당 릴리스 노트를 기준으로 판단하세요.

Clash 오리지널: 기본 YAML, HTTP/SOCKS 인바운드, 규칙 기반 라우팅의 역사적 출발점입니다.
Clash Premium: 기존 설정에서 고급 규칙, TUN, 스크립트 기능을 제공했던 커널 중 하나입니다.
Clash Meta / mihomo: 같은 프로젝트의 이전·현재 이름으로, 더 많은 프로토콜과 설정 확장을 지원합니다.

클라이언트에서 커널을 바꿀 수 있더라도 실행 파일을 임의로 교체해도 된다는 뜻은 아닙니다. 커널 실행 인자, 제어 인터페이스, 서비스 권한, 설치 경로를 클라이언트가 관리할 수 있습니다. 클라이언트에서 제공하는 커널 업데이트 방법을 우선 사용하고, 공식 지원 커널 유형을 확인하세요.

기능 비교: 프로토콜, 규칙 세트, TUN을 나눠 살펴보기

기존 기능 범위와 이전 시 확인할 항목
확인 항목	Clash 오리지널 오픈 소스	Clash Premium	mihomo
주요 프록시 프로토콜	SS, VMess, Trojan 등을 지원하지만 구버전 구현의 제약이 있습니다	과거 버전의 기능을 기준으로 해야 하며, 새 프로토콜 지원을 가정하면 안 됩니다	VLESS, Hysteria2, TUIC 등으로 지원 범위가 확장됩니다
기본 규칙	도메인, IP 대역, GEOIP, 최종 매칭 등의 규칙을 지원합니다	기본 규칙과 확장 기능을 지원합니다	일반적인 규칙을 유지하면서 더 다양한 매칭 기능을 제공합니다
rule-providers	Premium 기능과 호환된다고 간주할 수 없습니다	지원합니다. 규칙 동작과 형식을 확인해야 합니다	지원합니다. 확장 형식은 대상 버전을 확인해야 합니다
TUN 연결	Premium의 내장 TUN 기능은 제공하지 않습니다	지원하며 플랫폼과 권한에 따라 달라집니다	지원합니다. 네트워크 스택과 설정 필드는 버전에 따라 다릅니다
Premium script	지원하지 않음	과거의 전용 기능	그대로 호환된다고 볼 수 없으며 이전 과정에서 다시 작성해야 합니다

프로토콜 이름이 같아도 전송 방식과 암호화 필드를 확인해야 합니다

노드에 VMess라고 표시되어 있어도 연결 매개변수가 모두 설정됐다는 뜻은 아닙니다. UUID, TLS, 서버 이름, WebSocket 경로와 요청 헤더 등의 설정을 확인해야 합니다. VLESS는 서버에서 사용하는 전송 방식과 보안 계층, 관련 매개변수도 확인하세요. type만 바꾼다고 프로토콜이 다른 종류로 변환되지는 않습니다.

Hysteria2와 TUIC는 UDP 네트워크 환경에 의존합니다. 커널이 노드를 읽었는데도 현재 네트워크에서 계속 시간 초과가 발생한다면 설정 형식 탓으로 단정하지 말고 UDP 연결 경로, 서버 포트, 인증서 매개변수를 확인하세요. 프로토콜을 지원한다는 것은 필요한 조건일 뿐, 실제 연결을 보장하지는 않습니다.

설정 호환성: 기본 구조는 유지하고 확장 필드는 따로 점검

일반적인 설정 파일에는 proxies, proxy-groups, rules가 있으며, proxy-providers와 rule-providers가 포함되기도 합니다. 이름은 비슷해 보여도 역할은 다릅니다. 전자는 외부에서 노드를 불러오고, 후자는 라우팅 규칙을 불러오므로 구독 주소를 서로 바꿔 쓸 수 없습니다.

규칙 순서와 정책 이름을 함께 확인하세요

아래 예시는 mihomo의 일반적인 설정 구조를 보여줍니다. 예시에서는 수동 선택 그룹이 DIRECT를 가리키므로 프록시 경유는 이루어지지 않습니다. 실제로 사용할 때는 직접 연결 옵션을 유지하면서 정상 작동하는 기존 노드나 올바른 노드 제공자 참조를 추가하세요.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxy-groups:
  - name: 수동 선택
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,수동 선택
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,수동 선택

mixed-port: 7890은 HTTP와 SOCKS 프록시가 함께 사용하는 수신 포트의 예시이며, 모든 클라이언트의 기본 포트라는 뜻은 아닙니다.
allow-lan: false는 우선 로컬에서 확인할 때 적합합니다. LAN에서 접속해야 한다면 수신 주소와 방화벽 범위를 추가로 점검하세요.
규칙은 순서대로 매칭됩니다. MATCH를 앞에 두면 뒤에 있는 규칙이 의도대로 적용되지 않습니다.
규칙에 지정한 ‘수동 선택’은 정책 그룹 이름과 공백 및 대소문자까지 정확히 일치해야 합니다.
no-resolve는 해당 IP 규칙을 처리할 때 도메인 조회를 새로 하지 않는다는 뜻이지, 커널 전체의 DNS를 끈다는 뜻은 아닙니다.

Premium 스크립트와 새 규칙 세트 형식은 별도로 이전해야 합니다

기존 설정의 script는 mihomo 호환 항목으로 그대로 사용할 수 없습니다. 스크립트가 실제로 수행하는 도메인, IP, 프로세스 판별을 나눠 대상 커널이 지원하는 규칙으로 다시 작성하세요. 동등하게 표현할 수 없는 로직은 새로 설계해야 합니다. 이전 후에는 구문 검사뿐 아니라 대표 요청이 실제로 어떤 규칙에 매칭되는지도 확인하세요.

규칙 제공자는 behavior와 파일 내용이 일치하는지도 확인해야 합니다. domain, ipcidr, classical은 서로 다른 규칙 내용을 사용합니다. YAML, 텍스트, mihomo의 MRS 형식은 파일 확장자만 바꿔 서로 변환할 수 없습니다. MRS 같은 확장 형식은 규칙 동작과 커널 버전의 제약도 받으므로, 구형 커널에서는 읽지 못할 수 있습니다.

DNS와 TUN: 실행은 되지만 사용할 수 없는 문제가 자주 생기는 부분

DNS 설정은 요청을 받는 경로와 상위 DNS 서버를 구분해 확인하세요

DNS 수신 주소, 상위 서버, Fake-IP 모드, 도메인 예외 목록은 각각 다른 문제를 해결합니다. enhanced-mode: fake-ip가 보인다고 해서 시스템 요청이 반드시 커널로 들어오는 것은 아닙니다. 시스템이 다른 DNS 경로를 사용할 수도 있고, 앱 자체에서 암호화 DNS를 켰을 수도 있습니다.

이전하기 전에 기존 nameserver, fallback, fake-ip-filter와 관련 정책을 저장해 두세요.
로컬 기기 이름이나 내부 도메인만 제대로 작동하지 않는다면 모든 상위 DNS 서버를 한꺼번에 바꾸지 말고, 먼저 LAN DNS 경로와 Fake-IP 예외 목록을 확인하세요.
로그에 상위 도메인 조회 실패가 표시되면 DNS 서버 자체의 도메인을 조회하는 부트스트랩 설정을 확인하세요.
설정을 바꾼 뒤 관련 앱을 재시작해 보세요. 시스템 DNS 캐시와 앱 캐시가 커널을 다시 불러올 때 항상 함께 비워지는 것은 아닙니다.

TUN은 트래픽을 받아올 뿐, 노드 설정 문제를 해결하지 않습니다

TUN은 가상 네트워크 인터페이스를 통해 트래픽을 받아오며, 보통 관리자 권한이나 해당 네트워크 권한이 필요합니다. Windows의 서비스 모드, Linux의 라우팅과 권한, macOS의 네트워크 확장 또는 가상 인터페이스 처리 방식은 클라이언트 구현에 따라 각각 확인해야 합니다. 일반 시스템 프록시가 이미 작동한다면 그다음 TUN을 테스트하는 편이 문제 범위를 좁히기 쉽습니다.

tun.auto-route, tun.auto-detect-interface, tun.dns-hijack은 각각 라우팅, 출구 인터페이스 감지, DNS 연결을 다룹니다. 서로 대체할 수 있는 ‘강화 옵션’이 아닙니다. 예시에 나온 any:53은 DNS 포트 매칭을 위한 설정이며, 앱 안의 모든 암호화 DNS를 가로챈다는 뜻은 아닙니다. 다른 VPN과 함께 사용할 때는 라우팅 우선순위와 가상 네트워크 어댑터 충돌도 점검해야 합니다.

기존 설정을 mihomo로 이전하기: 6단계 검증

기존 설정을 저장합니다. 구독 출처, 로컬 덮어쓰기 설정, 규칙 세트, 현재 설정 파일을 백업하세요. 그래픽 클라이언트에서 내보낸 파일은 덮어쓰기 설정이 이미 합쳐졌을 수 있으므로 편집 가능한 원본도 함께 보관해야 합니다.
커널 정보를 기록합니다. 클라이언트의 커널 정보나 로그에서 실제 버전을 확인하세요. 별도로 실행하는 경우 mihomo -v를 실행하고 출력 내용과 시스템 아키텍처를 기록합니다.
먼저 구문을 확인합니다. 단독 실행 환경에서는 mihomo -t -f config.yaml을 사용할 수 있습니다. 상대 경로를 사용하는 리소스는 실제 실행 환경과 동일한 작업 환경에서 확인하세요. 그래야 경로 오류를 형식 호환성 문제로 오해하지 않습니다.
로컬 프록시 포트를 먼저 테스트합니다. 설정에서 실제 수신 포트가 7890인지 확인한 뒤 아래 명령을 실행하세요. 포트가 다르면 명령도 함께 수정해야 합니다.
규칙 매칭을 확인합니다. 클라이언트의 연결 기록에서 대상 도메인, 매칭된 규칙, 정책 그룹, 최종 출구를 살펴보세요. 요청이 성공했다는 것은 해당 연결 경로가 작동했다는 뜻일 뿐, 모든 라우팅 규칙이 올바르다는 뜻은 아닙니다.
확장 기능을 하나씩 다시 적용합니다. 규칙 제공자, DNS 덮어쓰기, TUN, 시작 시 자동 실행을 순서대로 추가하세요. 단계마다 로그를 확인하고 설정을 다시 불러온 뒤에도 제대로 작동하는지 점검합니다.

mihomo -v
mihomo -t -f config.yaml
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

위의 연결 시간 초과 10초와 전체 시간 초과 20초는 진단을 위한 설정값이지 속도 지표가 아닙니다. Windows PowerShell에서는 시스템의 curl 프로그램을 명확히 호출하도록 curl.exe를 사용하세요. 테스트 전에 실행 중인 클라이언트가 7890 포트를 사용하고 있는지 확인하세요. 커널을 두 개 동시에 실행하면 포트 충돌이 생길 수 있습니다.

자주 발생하는 이전 문제: 오류 위치를 기준으로 범위 좁히기

구독은 가져왔지만 노드를 전부 사용할 수 없음

먼저 구독 내용이 완전한 Clash 설정 파일인지, 노드 제공자 데이터인지, 다른 클라이언트용 공유 링크 모음인지 확인하세요. 그래픽 클라이언트에 ‘가져오기 성공’이라고 표시되어도 주소만 저장된 상태일 수 있습니다. 다운로드 결과, 노드 파싱 로그, 프로토콜 지원 여부를 계속 확인하세요. 인증 정보가 포함된 구독 링크를 공개 변환 서비스나 게시글에 붙여 넣지 마세요.

설정 검사는 통과했지만 규칙이 적용되지 않음

실행 모드가 rule인지, 실제로 적용 중인 파일이 방금 수정한 파일인지 확인하세요. 구독을 업데이트한 뒤 클라이언트가 설정을 다시 생성했거나, 덮어쓰기 설정으로 더 앞에 규칙을 추가했을 수 있습니다. 변경 사항을 유지하려면 생성된 파일만 수정하지 말고 클라이언트가 지원하는 덮어쓰기 또는 병합 기능을 사용하세요.

시작할 때 포트가 이미 사용 중이라는 메시지가 표시됨

클라이언트 두 개가 동시에 실행 중인지, 백그라운드 서비스에 기존 커널 프로세스가 남아 있는지 확인하세요. 프록시 인바운드 포트와 제어 인터페이스 포트는 용도가 다릅니다. 예를 들어 7890은 로컬 프록시 포트, 9090은 제어 인터페이스 포트로 사용할 수 있지만 실제 설정을 기준으로 확인해야 합니다. 프록시 포트를 바꿨다면 시스템 프록시, 터미널 환경 변수, 앱에 직접 입력한 프록시 주소도 함께 변경하세요.

기존 커널을 계속 사용할까요, mihomo로 바꿀까요?

Hysteria2, TUIC, VLESS 또는 최신 규칙·DNS 기능이 필요하다면 해당 기능을 명확히 지원하는 mihomo 클라이언트를 선택하고 포함된 커널 버전을 확인하세요. 기존 환경에서 Premium 스크립트나 특정 구형 동작에 의존한다면 실제 사용 환경을 바꾸기 전에 별도 설정으로 이전을 검증하세요. 클라이언트 설치 파일은 선택 가이드를 참고하고, 기본 설정 절차는 사용 안내에서 확인할 수 있습니다.

최종적으로는 설정을 정상적으로 읽는지, 노드에 연결되는지, 규칙이 예상대로 적용되는지, 시스템 프록시 또는 TUN이 의도한 범위의 트래픽을 처리하는지 확인해야 합니다. 이름에 ‘Meta’나 ‘mihomo’가 들어간다는 이유만으로 이 네 가지 점검을 대신할 수는 없습니다.