Clash 오리지널, Clash Meta, mihomo의 차이: 코어 기능, 프로토콜 지원 및 설정 문법 비교
세대별 코어의 계보를 살펴보고 프로토콜 지원, 규칙 유형, TUN 기능을 비교합니다. 기존 설정을 mihomo로 옮길 때 수정해야 할 항목도 정리했습니다.
먼저 구분할 것: 클라이언트, 코어, 구독 설정
“Clash가 특정 프로토콜을 지원하는지”는 프로그램 창에 표시된 이름만으로 판단할 수 없습니다. GUI 클라이언트는 구독 관리, 설정 전환, 시스템 프록시 제어, 로그 표시를 담당합니다. 코어는 YAML을 파싱하고 프록시 연결을 수립하며, 분기 규칙을 적용하고 DNS를 처리합니다. 클라이언트 인터페이스가 비슷해도 내부에서 같은 코어가 실행된다는 뜻은 아닙니다.
구독은 설정을 제공하는 출처입니다. proxies, proxy-groups, rules가 포함된 전체 설정을 반환할 수도 있고, proxy-providers에서 불러올 프록시 항목만 반환할 수도 있습니다. 링크에서 데이터를 정상적으로 다운로드했다는 사실만으로 현재 코어가 모든 노드와 규칙을 해석할 수 있는 것은 아닙니다.
- 클라이언트 선택: 운영체제, 설치 방식, 권한 관리, 설정 오버라이드 기능을 확인하세요.
- 코어 선택: 필요한 노드 프로토콜, 규칙 문법, DNS 및 TUN 기능을 확인하세요.
- 구독 형식 선택: 제공업체가 전체 Clash 설정을 반환하는지, 특정 코어용 확장 설정을 반환하는지 확인하세요.
계보: 오리지널, Premium, Meta, mihomo
Clash 오리지널과 Clash Premium
일반적으로 Clash 오리지널은 Dreamacro/clash 오픈 소스 프로젝트를 가리킵니다. Clash Premium은 같은 역사적 생태계에서 나온 비공개 강화 코어로, TUN, 규칙 제공자, 스크립트 등의 추가 기능을 제공했습니다. Premium 기능을 오픈 소스 오리지널의 기능으로 간주해서는 안 되며, 이름에 Premium이 들어간다고 해서 특정 GUI 클라이언트의 유료 버전이라는 뜻도 아닙니다.
2023년 11월, 오리지널 Clash 프로젝트와 Premium의 정기적인 공개 유지보수가 중단됐습니다. 이전 바이너리는 여전히 실행될 수 있지만, 이후 프로토콜 변화와 시스템 호환성 개선, 버그 수정을 지속적으로 기대하기는 어렵습니다. 기존 환경을 비교 테스트용으로 보존하는 것과 일상적인 네트워크 연결에 계속 사용하는 것은 별개의 선택입니다.
Clash Meta와 mihomo
Clash Meta는 Clash의 오픈 소스 포크에서 시작해 기존 설정 모델에 프로토콜과 규칙 기능을 추가했습니다. 프로젝트는 2023년 말 mihomo로 이름을 바꿨습니다. 이전 문서의 Meta, Clash.Meta와 현재의 mihomo는 대체로 서로 무관한 세 코어가 아니라 같은 프로젝트의 발전 과정을 가리킵니다.
이름이 바뀌었다고 해서 과거의 모든 버전에서 기능이 완전히 같아지는 것은 아닙니다. 구독 안내에 “Meta용”이라고 적혀 있다면 대략 같은 설정 생태계를 대상으로 한다는 뜻일 뿐입니다. 최신 프로토콜 필드를 사용할 수 있는지는 실제 실행 버전을 확인해야 합니다. 클라이언트 다운로드 페이지에 표시된 버전도 코어 버전과 다를 수 있습니다.
- 클라이언트의 ‘정보’, 코어 관리 메뉴 또는 시작 로그에서 코어 이름과 버전을 확인하세요.
- 독립 바이너리를 사용하는 경우
mihomo -v를 실행하고 출력 결과를 기록하세요. - 클라이언트 설치 파일 이름만 적어 두지 말고, 확인한 코어 정보를 구독 요구사항 및 기능 문서와 대조하세요.
기능 비교: 프로토콜, 규칙, TUN
아래 표는 마이그레이션 방향을 판단하기 위한 것으로, 버전별 전체 기능 목록은 아닙니다. 특히 프로토콜의 전송 방식, 암호화 방식, 인증 필드는 해당 버전에서 따로 확인해야 합니다. 같은 프로토콜이라도 매개변수가 맞지 않으면 연결에 실패할 수 있습니다.
| 기능 | Clash 오픈 소스 오리지널 | Clash Premium | mihomo／Meta 계열 |
|---|---|---|---|
| 일반적인 프록시 유형 | SS, VMess, Trojan, SOCKS5, HTTP 등 지원 | Clash에서 일반적으로 사용하는 기존 프록시 유형 지원 | 기존 유형을 유지하고 VLESS, Hysteria2, TUIC 등을 추가 지원 |
| VLESS 및 REALITY | 지원하지 않음 | 지원하지 않음 | 관련 설정 지원. REALITY는 관련 TLS 핸드셰이크 설정이지 별도의 노드 유형이 아닙니다. |
| 기본 규칙 | DOMAIN, DOMAIN-SUFFIX, IP-CIDR, GEOIP, MATCH 등 | 기본 규칙을 지원하며 추가 기능 제공 | 기본 규칙과 함께 GEOSITE, 논리 규칙 등을 지원 |
| rule-providers 및 RULE-SET | Premium 기능을 사용할 수 있다고 간주해서는 안 됨 | 지원. 규칙 세트 형식 확인 필요 | 지원하며 더 다양한 형식과 동작 옵션 제공 |
| TUN | Premium 방식의 내장 TUN 기능은 제공하지 않음 | 지원. 플랫폼 및 빌드 시점에 따른 제한이 있을 수 있음 | 지원. 플랫폼 권한과 네트워크 환경에 따라 달라짐 |
| Premium script | 지원하지 않음 | 스크립트 기반 분기 기능 제공 | Premium 스크립트를 호환 설정으로 바로 불러올 수 없음 |
프로토콜을 지원한다고 모든 노드를 가져올 수 있는 것은 아닙니다
예를 들어 VLESS 노드에는 uuid, network, TLS 매개변수, REALITY 공개 키 등이 필요할 수 있습니다. 노드의 type만 vless로 바꿔도 필요한 매개변수가 채워지지는 않습니다. Hysteria2와 기존 Hysteria도 이름이 비슷하다는 이유만으로 설정을 서로 바꿔 쓸 수 없습니다.
알 수 없는 프록시 유형이 나타나면 먼저 구독이 mihomo 형식으로 생성된 것인지 확인한 뒤 코어 버전을 살펴보세요. 오류를 피하려고 인증 필드를 삭제하거나 인증서 검증을 끄지 마세요. 설정 파싱, 원격 핸드셰이크, 실제 요청 성공 여부는 각각 따로 확인해야 합니다.
기존 YAML 마이그레이션: 유지할 항목과 점검할 항목
대부분의 기본 설정 구조는 그대로 사용할 수 있습니다. 로컬 수신 포트, 프록시 항목, 프록시 그룹, 순서 규칙은 여전히 쓰입니다. 마이그레이션의 핵심은 파일 이름을 전부 바꾸는 것이 아니라 코어 전용 필드를 정리하고 클라이언트가 코어에 실제로 전달하는 실행 설정을 확인하는 것입니다.
자주 쓰는 필드 처리 표
| 기존 설정 항목 | 마이그레이션 처리 | 확인할 사항 |
|---|---|---|
mixed-port、mode |
대체로 유지 가능. 클라이언트가 덮어쓰는지 확인 | 실제 수신 주소와 포트, 현재 모드가 rule인지 확인 |
proxies、proxy-groups |
프로토콜 필드와 그룹 내 참조 이름 확인 | 대소문자, 공백, 제공자 이름이 완전히 일치하는지 확인 |
rule-providers |
behavior, format, 페이로드 구조 확인 | 텍스트 규칙 세트와 YAML payload는 서로 다른 방식으로 파싱해야 함 |
Premium의 script 및 script 모드 |
대상 코어에서 지원하는 규칙, 규칙 세트 또는 논리 규칙으로 바꾸기 | 스크립트를 삭제하는 것만으로 분기 동작이 유지된다고 볼 수 없음 |
tun、dns |
대상 코어와 운영체제에 맞춰 다시 확인 | 라우팅, DNS 가로채기, 로컬 네트워크 이름 확인이 예상대로 동작하는지 확인 |
필드 이름보다 규칙 순서를 놓치기 쉽습니다
규칙은 일반적으로 위에서 아래 순서로 평가되며, 일치하는 항목을 만나면 해당 정책이 적용됩니다. MATCH를 앞에 두면 뒤에 있는 일반 규칙이 적용될 기회가 없습니다. RULE-SET에서 참조하는 이름은 rule-providers에 있어야 합니다. 규칙이 가리키는 정책 이름도 유효한 프록시, 프록시 그룹 또는 내장 정책이어야 합니다.
proxy-providers는 프록시 노드를 제공하고 rule-providers는 매칭 규칙을 제공합니다. 서로 바꿔 쓸 수 없습니다. 마이그레이션 후 ‘제공자를 찾을 수 없음’ 오류가 발생하면 두 구독 주소를 임의로 맞바꾸지 말고 참조 관계부터 확인하세요.
최소 설정과 마이그레이션 검증 명령
먼저 되돌리기 쉬운 설정으로 코어를 검증한 다음 실제 구독을 추가하세요. 아래는 mihomo 기본 구조의 예입니다. 로컬의 7890 혼합 포트를 수신하고 rule 모드를 사용하며 TUN은 끕니다. 프록시 그룹에는 DIRECT만 포함되어 있으므로 구조와 규칙 로드 여부를 확인하는 용도이며 원격 프록시 연결은 수립하지 않습니다.
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxies: []
proxy-groups:
- name: PROXY
type: select
proxies:
- DIRECT
rules:
- DOMAIN-SUFFIX,example.com,PROXY
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- MATCH,PROXY
tun:
enable: false파일을 config.yaml로 저장한 뒤 별도 터미널에서 확인할 수 있습니다. 아래 명령은 mihomo가 PATH에 등록된 환경에서 사용할 수 있습니다. Windows에서는 로컬 실행 파일에 맞게 명령어 이름을 .\mihomo.exe로 바꾸면 됩니다.
mihomo -v
mkdir clash-test
mihomo -t -d ./clash-test -f ./config.yaml-t는 현재 코어가 설정을 불러올 수 있는지 확인하며, 원격 노드에 연결할 수 있다는 점까지 증명하지는 않습니다. 테스트 디렉터리는 캐시와 리소스 파일이 서로 영향을 주지 않도록 일상적으로 사용하는 클라이언트의 데이터 디렉터리와 분리하세요. 설정에서 외부 규칙이나 지리 데이터 파일을 참조한다면 해당 파일 또는 다운로드 경로도 사용 가능한지 확인해야 합니다.
- 기존 설정을 복사해 보관하고, 이전 코어 버전과 포트, 활성화된 오버라이드 항목을 기록하세요.
- 실제 구독을 대상 클라이언트에 가져온 뒤 TUN을 끄고 일반 프록시 연결부터 확인하세요.
- 시작 로그에서 알 수 없는 유형, 누락된 파일, 잘못된 참조, 포트 사용 중 오류를 확인하세요.
- 대상 클라이언트의 연결 기록에서 적용된 규칙과 실제 출구를 확인한 뒤 DNS, 규칙 세트, TUN을 하나씩 다시 활성화하세요.
로컬 HTTP 프록시 연결을 확인하려면 curl -x http://127.0.0.1:7890 https://example.com/을 실행하세요. 이 명령은 프록시 포트를 명시적으로 지정하므로 시스템 프록시 설정이 적용됐는지는 확인할 수 없습니다. 위 예시 설정을 그대로 사용하면 최종 연결은 직접 연결됩니다.
TUN과 DNS: 기존 스위치를 그대로 복사하지 마세요
시스템 프록시는 일반적으로 시스템 프록시 설정을 읽는 앱에만 영향을 줍니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 트래픽을 처리하므로 더 많은 앱의 트래픽을 다뤄야 할 때 적합합니다. 다만 TUN을 켠다고 모든 트래픽이 반드시 프록시를 통과하는 것은 아닙니다. 코어는 규칙에 따라 직접 연결, 프록시, 차단 여부를 결정하며 라우팅 제외 항목과 다른 VPN도 결과에 영향을 줍니다.
먼저 권한과 라우팅을 해결하세요
- Windows: 클라이언트가 요구하는 서비스 모드 또는 관리자 권한을 확인하세요. 구체적인 설정 위치는 해당 클라이언트 버전에 따라 다릅니다.
- Linux: TUN 장치, 프로세스 권한 또는 root 권한, 기존 라우팅 테이블을 확인하세요.
- macOS: 클라이언트 보조 서비스와 시스템 권한을 확인하고, 라우팅을 두고 충돌할 수 있는 VPN을 여러 개 동시에 켜지 마세요.
mihomo의 TUN 설정에는 auto-route, auto-detect-interface, stack, dns-hijack 등이 포함될 수 있습니다. 플랫폼별 설정을 고려해야 하며 한 플랫폼에서 잘 작동한 설정을 모든 시스템의 기본값으로 간주해서는 안 됩니다. 변경 전에 기존 값을 기록하고 기능을 한 묶음씩 조정해야 권한 문제와 DNS 문제를 구분할 수 있습니다.
DNS가 작동해도 트래픽 분기가 올바르다는 뜻은 아닙니다
fake-ip 모드는 주소를 매핑해 도메인을 다시 확인하는 데 도움을 주고, redir-host는 실제 DNS 응답을 반환하는 데 중점을 둡니다. 두 방식은 도메인 인식과 앱 호환성에 서로 다른 영향을 줍니다. 마이그레이션할 때는 enhanced-mode, fake-ip-filter, 상위 DNS 서버, 로컬 네트워크 도메인 처리 설정을 함께 확인하세요.
일반적인 DNS 가로채기 대상은 일반 DNS의 53 포트입니다. 앱에 내장된 DoH는 보통 HTTPS의 443 포트를 통해 전송되므로 53번 포트 대상 규칙이 자동으로 적용된다고 볼 수 없습니다. 브라우저와 다른 앱에서 결과가 다르면 노드를 계속 바꾸기보다 브라우저의 보안 DNS, 캐시, 코어 연결 로그를 확인하세요.
선택 가이드와 최종 점검 목록
새 설정에 VLESS, REALITY, Hysteria2, TUIC 또는 확장 규칙 기능이 필요하다면 해당 기능을 지원한다고 명시된 mihomo 버전을 선택하고 클라이언트가 실제로 그 코어를 사용하는지 확인하세요. 기존 SS, VMess, Trojan 설정만 옮기는 경우 기본 구조는 대체로 유지할 수 있지만 DNS, 스크립트 기반 분기, TUN은 각각 별도로 검증해야 합니다.
오리지널과 Premium은 과거 설정을 이해하고 기존 동작을 재현하는 데 적합합니다. mihomo로 옮겼을 때의 실질적인 이점은 해당 프로토콜과 규칙 기능, 계속 발전하는 코어를 사용할 수 있다는 점입니다. 그렇다고 만료된 구독, 잘못된 인증 정보, 연결할 수 없는 서버까지 자동으로 해결되는 것은 아닙니다.
- 버전: 클라이언트 버전만이 아니라 실제 코어 이름과 버전을 기록했습니다.
- 설정: 문법 검사를 통과했고 노드, 프록시 그룹, 규칙 제공자 참조가 모두 유효합니다.
- 포트: 로컬 포트와 앱 설정이 일치하며 기존 클라이언트가 7890 등의 포트를 동시에 사용하지 않습니다.
- 분기: 직접 연결 요청과 프록시 요청을 각각 하나 이상 확인하고 로그에 표시된 정책이 예상과 일치합니다.
- TUN: 권한, 라우팅, DNS를 확인한 뒤 장기간 사용하고 클라이언트를 종료한 후 네트워크가 복구되는지 확인합니다.
- 업데이트: 구독을 한 번 수동 업데이트하고 사용자 지정 오버라이드가 유지되는지 확인한 다음 자동 업데이트를 켭니다.
필드의 의미는 프로토콜 참고 자료에서 확인할 수 있습니다. 가져오기 실패, 포트 충돌, 시스템 프록시 오류가 발생하면 도움말 센터에서 증상별로 해결 방법을 찾아보세요. 사용할 코어를 정한 뒤에는 먼저 일반 프록시 연결을 검증하고 TUN과 복잡한 규칙을 추가하면 문제 범위를 더 명확히 좁힐 수 있습니다.