Clash 원본·Clash Meta·mihomo 차이점 비교: 버전 계보와 기능

이름과 계보: Clash 원본, Premium, Meta 브랜치

먼저 선택 기준부터 살펴보겠습니다. Clash Meta와 mihomo는 같은 브랜치에서 사용된 이전 이름과 현재 이름으로, 서로 무관한 별개의 코어가 아닙니다. Clash 원본은 이 기술 계보의 상류 프로젝트입니다. 클라이언트를 선택할 때는 앱 이름에 Clash가 포함됐는지만 볼 것이 아니라 실제 실행 중인 코어의 이름과 버전을 확인해야 합니다.

Clash Premium도 별도로 구분해야 합니다. 오래된 튜토리얼에서는 오픈소스 원본 코어와 Premium 코어를 모두 “Clash”라고 부르는 경우가 많아 “원본도 당연히 TUN을 지원한다”, “예전 설정은 그대로 옮겨 쓸 수 있다”는 오해가 생기기 쉽습니다. 기능을 판단하려면 다음 네 가지 이름을 구분해야 합니다.

Clash 오픈소스 원본 코어: 일반적으로 Dreamacro/clash 프로젝트의 오픈소스 버전을 가리킵니다. 로컬 프록시 엔드포인트, 프록시 그룹, 규칙 매칭, DNS 등의 기본 기능을 제공합니다.
Clash Premium: 원 프로젝트에서 별도로 배포한 비공개 강화 코어입니다. TUN, 규칙 세트, 스크립트 등의 확장 기능을 제공한 적이 있으며, 모든 기능을 오픈소스 원본 코어의 기능으로 간주해서는 안 됩니다.
Clash Meta: 커뮤니티가 Clash를 기반으로 발전시킨 브랜치로, 프로토콜·규칙·네트워크 트래픽 처리 기능을 확장했습니다.
mihomo: Clash Meta가 이후 사용하게 된 프로젝트 이름입니다. 현재 문서와 실행 파일, 로그에서 흔히 볼 수 있으며, 일부 클라이언트나 구독 서비스에서는 여전히 Meta라는 이름을 사용합니다.

클라이언트와 코어: 앱 버전이 곧 기능 버전은 아닙니다

클라이언트는 구독 관리, 설정 전환, 시스템 프록시 설정, 로그 표시를 담당하고, 코어는 설정을 해석하고 연결을 수립하며 규칙과 DNS를 처리합니다. 같은 클라이언트라도 특정 코어가 내장돼 있을 수도 있고 코어를 바꿀 수도 있습니다. 따라서 앱이 업데이트됐다고 해서 기반 네트워크 기능까지 업데이트됐다고 단정할 수 없습니다.

실행 중인 코어를 확인하는 세 가지 방법

클라이언트의 ‘정보’ 또는 ‘코어’ 화면에서 클라이언트 버전과 코어 버전을 각각 확인하세요. 메뉴 이름은 클라이언트마다 다르므로 앱 버전 번호를 코어 버전으로 착각하지 않도록 주의해야 합니다.
시작 로그에서 코어 이름과 버전, 설정 로드 결과를 확인하세요. 코어를 바꾼 뒤에는 파일만 교체하고 프로세스를 재시작하지 않은 상황이 아닌지 로그를 다시 확인해야 합니다.
로컬 컨트롤 인터페이스를 활성화했다면 /version을 요청할 수 있습니다. 반환 내용은 코어 버전에 따라 다르므로 버전 필드와 브랜치 표기를 확인하세요.

예를 들어 컨트롤 인터페이스가 external-controller: 127.0.0.1:9090으로 설정돼 있다면 로컬에서 다음 명령을 실행할 수 있습니다. 인터페이스에 인증 키를 설정했다면 올바른 인증 요청을 사용해야 합니다. 401 응답은 인증 실패를 뜻할 뿐, 코어가 버전 조회를 지원하지 않는다는 의미는 아닙니다.

curl http://127.0.0.1:9090/version

여기서 9090은 컨트롤 인터페이스 포트이며 브라우저 프록시 포트가 아닙니다. 컨트롤 인터페이스는 실행 상태를 변경할 수 있으므로 로컬 주소에서만 수신하도록 유지하세요. 패널 연결을 위해 외부에서 접근 가능한 주소로 바꾸지 마세요.

기능 비교: 프로토콜·규칙 세트·TUN·DNS

아래 비교는 기능의 전반적인 방향을 보여주는 것으로, 각 과거 버전의 전체 기능 목록은 아닙니다. 원 프로젝트와 Premium 배포 계열은 더 이상 원 프로젝트에서 유지보수되지 않습니다. mihomo의 세부 설정 항목은 사용 중인 버전의 문서를 확인하세요. 특히 신규 프로토콜 매개변수, DNS 옵션, 플랫폼별 기능은 주의가 필요합니다.

비교 항목	Clash 오픈소스 원본	Clash Premium	Meta / mihomo
주요 프록시 프로토콜	Shadowsocks, VMess, Trojan 등을 지원하며, 사용할 수 있는 매개변수는 버전에 따라 다릅니다.	원본 프로토콜 체계를 따르며, mihomo의 확장 프로토콜까지 지원한다고 볼 수는 없습니다.	VLESS, Hysteria2, TUIC 등을 추가 지원하며, 버전과 매개변수를 확인해야 합니다.
기본 규칙	도메인, IP 대역, GEOIP, MATCH 등 일반적인 규칙을 지원합니다.	기본 규칙과 함께 규칙 세트 등의 강화 기능을 제공합니다.	기본 규칙과 규칙 세트, 다양한 로직 및 매칭 조건을 지원합니다.
TUN 트래픽 처리	Premium과 같은 내장 TUN 기능은 제공하지 않습니다.	TUN을 제공하지만 지원 여부는 시스템과 배포 버전에 따라 다릅니다.	TUN을 제공하며, 프로토콜 스택과 라우팅 옵션은 버전과 플랫폼에 따라 다릅니다.
DNS 및 Fake-IP	DNS와 Fake-IP의 기본 기능을 지원합니다.	DNS와 Fake-IP를 지원합니다.	DNS 정책, 업스트림 선택, DNS 응답 제어 기능을 계속 확장합니다.
마이그레이션 시 주의 사항	브랜치에서 새로 추가된 프로토콜과 설정 항목을 인식하지 못합니다.	Premium 스크립트가 mihomo에서 그대로 실행된다고 단정할 수 없습니다.	기본 설정 상당 부분을 재사용할 수 있지만, 확장 설정 항목은 하나씩 검증해야 합니다.

프로토콜 이름이 같아도 전송 방식과 TLS 매개변수를 확인하세요

특정 프로토콜을 지원한다고 해서 모든 조합을 지원하는 것은 아닙니다. 예를 들어 VLESS는 프록시 프로토콜이고 REALITY는 관련 TLS 보안 설정 기능이며, WebSocket과 gRPC는 전송 방식입니다. 서버가 특정 조합을 요구한다면 클라이언트 코어도 해당 설정 항목을 지원해야 합니다. “VLESS 지원”만으로 연결에 필요한 조건이 모두 충족됐다고 볼 수는 없습니다.

마찬가지로 Hysteria와 Hysteria2는 표시 이름만 바꿔 서로 호환되는 설정이 아닙니다. 구독에 type: hysteria2가 있다면 구형 코어에서 유형을 hysteria로 바꿔도 호환되지 않습니다. 오류가 난 설정 항목을 하나씩 지우기보다는 호환되는 코어와 구독 출력을 선택하세요.

규칙 호환성: 기본 문법은 재사용할 수 있지만 확장 기능은 확인이 필요합니다

기본적인 트래픽 분기는 대부분 “위에서부터 규칙을 확인하고, 일치하면 지정된 정책을 적용한다”는 방식으로 동작합니다. DOMAIN-SUFFIX, IP-CIDR, MATCH 등의 규칙은 여러 코어에서 공통으로 사용할 수 있지만, 규칙이 참조하는 프록시 그룹이 존재해야 하고 그룹 안의 프록시 이름도 실제 리소스와 일치해야 합니다.

아래 규칙 조각은 순서를 설명하기 위한 예시이며 완전한 구독 설정이 아닙니다. DIRECT는 내장 직접 연결 정책입니다. 실제로 사용할 때는 프록시가 필요한 규칙을 기존 프록시 그룹에 연결하세요. 모두 직접 연결하도록 그대로 복사하지 마세요.

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,DIRECT

마지막 기본 규칙: MATCH는 보통 맨 마지막에 둡니다. 앞에 배치하면 뒤에 있는 규칙은 매칭될 기회를 잃습니다.
규칙 세트 선언: RULE-SET을 사용할 때는 해당하는 rule-providers의 이름, 형식, 동작 유형을 확인하세요. 규칙 참조 행만 복사해서는 안 됩니다.
DNS 조회 관련 효과: no-resolve는 해당 IP 규칙에서 도메인 조회가 발생하지 않도록 하는 옵션입니다. 연결 과정 전체에 DNS가 필요 없다는 뜻은 아닙니다.
Premium 스크립트: script가 포함된 구형 설정을 옮길 때는 대상 코어가 해당 기능을 지원하는지 확인하세요. 필요하면 규칙과 프록시 그룹을 사용하는 방식으로 다시 작성해야 합니다.

설정을 불러오는 데 성공했는데 트래픽 분기가 예상과 다르다면 먼저 현재 모드가 rule인지 확인하세요. 전역 모드에서는 일반적인 규칙 목록에 따라 분기되지 않으며, 직접 연결 모드로는 프록시 규칙이 올바른지 검증할 수 없습니다.

TUN과 DNS: 기능 지원이 곧 트래픽 처리 완료를 뜻하지는 않습니다

시스템 프록시와 TUN은 서로 다른 트래픽 경로를 처리합니다

시스템 프록시는 일반적으로 시스템 프록시 설정을 따르는 앱이 127.0.0.1:7890 같은 로컬 HTTP 또는 SOCKS 엔드포인트로 연결하도록 합니다. 모든 프로그램의 트래픽을 처리하는 것은 아니며, 임의의 UDP 트래픽이 모두 코어를 통과한다는 뜻도 아닙니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 더 많은 IP 트래픽을 처리하므로 적용 범위와 구현 방식이 다릅니다.

mihomo가 TUN을 지원하더라도 설정에 enable: true를 입력하기만 하면 반드시 작동하는 것은 아닙니다. 클라이언트에 필요한 권한이 있는지, 시스템에서 인터페이스 생성을 허용하는지, 라우팅이 올바른지, 다른 VPN 또는 투명 프록시와 충돌하지 않는지 확인해야 합니다. 문제를 해결할 때는 라우팅 루프와 DNS 중복 가로채기를 줄이도록 네트워크 트래픽 처리 방식을 하나만 남겨 두세요.

Fake-IP는 DNS 동작 방식이지 프록시 프로토콜이 아닙니다

Fake-IP는 도메인에 매핑 주소를 할당하고, 연결 단계에서 코어가 원래 도메인을 찾아 트래픽을 분기하도록 합니다. 일반적인 설정 예시에서는 198.18.0.1/16 주소 풀을 사용합니다. 대상 웹사이트가 실제로 해당 주소에 있다는 뜻이 아니며, 이 주소로 노드 위치를 판단할 수도 없습니다.

아래 설정 조각은 관련 항목만 보여줍니다. 1053은 사용자가 지정한 로컬 DNS 수신 포트로, 시스템에서 일반적으로 사용하는 53 포트를 자동으로 대체하지 않습니다. 시스템 DNS 요청을 코어로 전달하려면 클라이언트의 트래픽 처리, TUN DNS 가로채기 또는 그 밖의 명시적인 설정이 필요합니다.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

DNS 설정 항목과 트래픽 처리 순서는 전체 가이드의 DNS 설명을 참고하세요. Fake-IP의 개념과 범위는 용어 가이드에서 확인할 수 있습니다.

마이그레이션 점검: 구형 Clash 설정을 mihomo로 전환하기

마이그레이션의 핵심은 설정 파일에서 Clash라는 글자를 mihomo로 바꾸는 것이 아니라 프로토콜, 규칙, 시스템 트래픽 처리가 모두 정상인지 검증하는 것입니다. 다음 순서대로 진행하고 각 단계가 확인된 뒤 다음 기능을 추가하세요.

기존 설정 보관: 구독 URL, 현재 YAML, 로컬 오버라이드, 프록시 그룹 선택을 백업하세요. 구독 URL에는 접근 인증 정보가 포함될 수 있으므로 공개 로그나 스크린샷에 노출하지 마세요.
구독 대상 확인: 서비스 제공자가 Clash와 Meta 출력을 구분한다면 선택한 출력에 대상 코어가 인식할 수 있는 프로토콜과 설정 항목이 포함됐는지 먼저 확인하세요. Base64 노드 목록은 파일 확장자만 바꿔 완전한 YAML 설정으로 만들 수 없습니다.
문법 검사: 대상 코어로 설정을 테스트하세요. 일반적인 명령은 mihomo -t -f config.yaml입니다. Windows에서는 mihomo.exe -t -f config.yaml을 사용할 수 있으며, 실제 실행 파일 경로는 설치 위치에 따라 다릅니다.
로컬 프록시부터 확인: TUN을 잠시 끄고 로컬 엔드포인트 포트, 프록시 그룹, 프록시 연결이 정상인지 확인한 다음 규칙 모드를 테스트하세요.
그다음 트래픽 처리 활성화: 필요한 권한에 따라 TUN을 켜고 로그에서 인터페이스, 라우팅, DNS 상태를 확인하세요. 브라우저와 시스템 프록시 설정을 따르지 않는 앱을 각각 테스트해야 합니다.
마지막으로 자동 업데이트 복구: 구독을 한 번 업데이트한 뒤에도 로컬 오버라이드가 적용되는지 확인하세요. 원격 설정 파일을 직접 수정하면 다음 업데이트에서 변경 내용이 덮어써질 수 있습니다.

예를 들어 설정에 mixed-port: 7890이 있으면 아래 명령으로 HTTPS 요청이 이 로컬 HTTP 프록시 엔드포인트를 통과하는지 확인할 수 있습니다. 명령이 성공해도 해당 엔드포인트와 요청 대상이 작동한다는 것만 확인된 것이며, 모든 앱이나 UDP, TUN까지 정상이라는 뜻은 아닙니다.

curl -I -x http://127.0.0.1:7890 https://example.com

포트 사용 중 오류가 나오면 구형 코어나 다른 클라이언트가 실행 중인지 확인하세요. 지원하지 않는 프록시 유형이라는 오류가 나오면 코어와 구독 형식을 먼저 확인하세요. 문법 검사는 통과했지만 연결 시간이 초과되면 서버 설정, 네트워크 연결 상태, DNS를 점검하세요. 이 세 가지 문제를 구분하면 설정을 계속 바꾸는 것보다 원인을 쉽게 찾을 수 있습니다.

선택 기준: 구독 프로토콜과 실행 플랫폼에 맞춰 결정하세요

신규 프로토콜이나 확장 규칙이 필요한 경우: mihomo를 명확히 통합하고 유지보수하는 클라이언트를 우선 선택하고, 내장 코어 버전이 설정 요구 사항을 충족하는지 확인하세요.
기본 프로토콜과 도메인 분기만 사용하는 경우: 복잡한 설정이 필요하지 않을 수 있지만, 새로 구성할 때는 오래된 튜토리얼이 익숙하다는 이유만으로 구형 코어를 고집하기보다 유지보수 상태와 시스템 호환성을 우선 고려하세요.
TUN이 필요한 경우: 코어 지원 여부뿐 아니라 클라이언트의 권한 관리, 시스템 아키텍처, 라우팅 처리 기능도 확인하세요. 특히 모바일에서는 앱이 실제로 사용하는 코어와 시스템 VPN 인터페이스 구현을 기준으로 판단해야 합니다.
Premium 설정을 마이그레이션하는 경우: 스크립트, 규칙 세트, TUN 설정 항목을 먼저 검토하세요. “가져올 수 있다”는 것이 “모든 동작이 동일하다”는 뜻은 아닙니다.

마지막으로 세 가지 업데이트 경로를 구분해 관리하세요. 구독 업데이트는 프록시 리소스와 규칙을 바꾸고, 코어 업데이트는 프로토콜 및 네트워크 기능을 바꾸며, 클라이언트 업데이트는 인터페이스와 통합 방식을 바꿉니다. 지원하지 않는 설정 항목은 구독만 새로고침해도 해결되지 않을 수 있고, 서버 주소가 더 이상 유효하지 않다면 코어만 바꿔도 해결되지 않습니다. 먼저 문제가 어느 계층에 속하는지 확인한 뒤 적절한 조치를 선택하세요.