Clash 오리지널·Meta·mihomo 커널 버전 차이 비교
Clash 오리지널 커널, Clash.Meta와 mihomo의 계보를 정리하고 프로토콜·규칙 유형·TUN 구현·설정 항목의 차이를 비교해 기존 설정을 그대로 사용할 수 있는지 확인합니다.
먼저 결론: Meta와 mihomo는 같은 계보입니다
마이그레이션할 때는 먼저 클라이언트에서 실제로 실행 중인 커널을 확인한 다음 구독 형식을 점검하세요. Clash.Meta는 이후 mihomo로 이름이 바뀌었으며, 서로 무관한 설정 체계가 아닙니다. 대부분의 기본 Clash YAML 설정은 마이그레이션의 출발점으로 사용할 수 있습니다. 반대로 mihomo 확장 필드를 사용하는 설정이 구형 Clash에서 작동한다고 보장할 수는 없습니다.
커널은 설정을 파싱하고 규칙을 매칭하며 프록시 연결을 수립합니다. 클라이언트는 화면, 구독 관리, 시스템 권한 등의 기능을 담당합니다. 같은 이름의 클라이언트라도 배포 버전에 따라 포함된 커널이 다를 수 있습니다. 따라서 “Clash를 설치했다”는 사실만으로 특정 프로토콜의 지원 여부를 판단할 수 없습니다.
이름·유지보수 현황·설정 호환 범위
| 이름 | 특징 및 상태 | 마이그레이션 시 확인할 사항 |
|---|---|---|
| Clash 오리지널 오픈소스 커널 | 초기 오픈소스 구현으로, 원 프로젝트는 유지보수가 중단되었습니다 | 기본 프로토콜과 기본 규칙 지원. 이후 추가된 프로토콜은 지원을 기대하기 어렵습니다 |
| Clash Premium | 과거의 비공개 기능 강화 배포판으로, 유지보수가 중단되었습니다 | TUN, 규칙 제공자, 스크립트 등 기존 기능의 마이그레이션 방법 |
| Clash.Meta | Clash에서 발전한 브랜치로, mihomo의 이전 이름입니다 | 구버전에서 설정에 사용된 새 필드를 지원하는지 여부 |
| mihomo | Meta 계보를 이어 프로토콜·규칙·네트워크 기능을 계속 확장합니다 | 실제 버전, 운영체제 플랫폼, 클라이언트의 덮어쓰기 동작 |
현재 실행 중인 커널 확인 방법
- 클라이언트의 ‘정보’, ‘커널’ 또는 시작 로그 화면을 확인하세요. 메뉴 이름은 클라이언트마다 다르며, 모든 휴대전화에 공통으로 적용되는 고정 경로는 없습니다.
- 커널 이름과 전체 버전 번호, 기기 운영체제, 클라이언트 버전을 기록하세요. 앱 스토어에 표시된 버전만 기록해서는 안 됩니다.
- 데스크톱 환경에서 커널을 직접 실행할 수 있다면
mihomo -v를 실행해 버전을 확인하세요. 이 명령은 지정한 실행 파일을 조회하며, 휴대전화 앱에 포함된 버전을 뜻하지는 않습니다.
구형 설정 메모의 ‘Meta 전용’은 보통 확장 기능에 의존한다는 뜻이지, Meta라는 이름의 구형 설치 파일을 찾아야 한다는 의미는 아닙니다. 이름이 일치하는지가 아니라 대상 mihomo 버전이 사용된 필드를 지원하는지 확인해야 합니다.
프로토콜 차이: 노드를 가져왔다고 연결까지 되는 것은 아닙니다
프로토콜은 클라이언트와 프록시 서버 간 통신 규약입니다. 오리지널 Clash에서 흔히 쓰는 설정에는 Shadowsocks, VMess, Trojan, SOCKS5, HTTP 프록시가 있습니다. mihomo는 여기에 VLESS, Hysteria2, TUIC, WireGuard 등을 추가로 지원하지만, 실제 기능은 커널 버전과 플랫폼에 따라 달라집니다.
새 프로토콜은 전송 매개변수도 확인해야 합니다
- VLESS와 Reality: VLESS는 프로토콜이고 Reality는 관련 TLS 보안 방식입니다.
type: vless만 확인해서는 부족합니다. 서버에서 요구하는 전송 방식,servername, Reality 공개 키 등의 매개변수도 확인하세요. - Hysteria2와 TUIC: 두 프로토콜 모두 UDP 기반 전송을 사용합니다. 네트워크에서 UDP가 차단되어 있다면 프로토콜을 지원하는 커널로 바꿔도 기본 연결 문제는 해결되지 않습니다.
- Shadowsocks: 프로토콜 이름뿐 아니라
cipher암호화 방식도 확인해야 합니다. 최신 암호화 방식은 모두 SS 노드라는 이유만으로 구형 커널에서 지원된다고 볼 수 없습니다.
‘지원하지 않는 프록시 유형’ 오류가 발생하면 설정의 type과 커널 버전을 먼저 확인하세요. 핸드셰이크 실패나 시간 초과가 발생하면 서버 주소, 포트, 기기 시간, 인증 매개변수, 네트워크 상태를 점검하세요. 모든 연결 실패를 커널 비호환 탓으로 돌리거나, 문제를 진단하는 대신 인증서 검증을 끄지 마세요.
규칙 차이: 기본 문법은 비슷하지만 확장 규칙은 항목별 확인이 필요합니다
규칙은 위에서 아래 순서로 매칭되며, 일치하는 규칙이 나오면 해당 정책으로 처리됩니다. DOMAIN은 지정한 도메인과 일치하고, DOMAIN-SUFFIX는 도메인과 하위 도메인에 일치합니다. IP-CIDR은 IP 대역에 일치하며 MATCH는 마지막 기본 규칙으로 사용됩니다. 이러한 기본 개념은 브랜치가 달라도 비교적 안정적입니다.
규칙 제공자는 단순한 규칙 링크가 아닙니다
rule-providers로 외부 규칙 모음을 선언한 뒤 RULE-SET으로 참조합니다. 과거 Premium과 mihomo 모두 관련 기능을 지원했지만, 그렇다고 모든 오리지널 오픈소스 빌드에서 읽을 수 있는 것은 아닙니다. 마이그레이션할 때는 제공자 유형, 파일 형식, 콘텐츠 유형을 함께 확인하세요.
behavior: domain은 도메인 규칙 모음을,ipcidr은 IP 대역 모음을 뜻합니다.classical에는 규칙 유형이 지정된 항목이 포함됩니다.- 기존 YAML 규칙 모음에서는
payload목록을 주로 사용합니다. 일반 텍스트 형식과 mihomo의 MRS 바이너리 형식은 대상 커널이 해당 형식을 지원해야 합니다. 파일 확장자만 바꿔서는 사용할 수 없습니다. - 프로세스 규칙은 시스템에서 프로세스 정보를 제공해야 작동합니다. Android에서는 앱별 트래픽 분기가 클라이언트의 VpnService 앱 목록으로 구현되기도 하며, 이는 데스크톱의 프로세스 규칙과 다릅니다.
Premium에서 마이그레이션할 때는 특히 script를 별도로 확인하세요. 구형 스크립트 설정을 mihomo에서 일반적으로 호환되는 인터페이스로 간주해서는 안 됩니다. 스크립트가 실제로 수행하는 조건 판단을 파악한 뒤, 대상 버전에서 지원하는 규칙·논리 규칙·하위 규칙으로 다시 작성하고 항목별로 테스트하는 편이 안전합니다.
TUN과 모바일 VPN: 커널 기능과 시스템 트래픽 처리는 따로 확인하세요
TUN은 네트워크 데이터를 가상 네트워크 인터페이스로 전달해 처리하는 방식입니다. 시스템 프록시 설정을 읽지 않는 앱의 트래픽도 프록시 커널로 보낼 수 있습니다. 과거에는 TUN이 Clash Premium과 Meta 등 기능 확장 계열의 주요 기능이었지만, 이를 근거로 오리지널 오픈소스 Clash의 모든 빌드에 같은 구현이 포함된다고 볼 수는 없습니다.
Android 클라이언트는 일반적으로 시스템에서 제공하는 VPN 인터페이스인 VpnService를 이용해 트래픽을 처리할 권한을 얻습니다. VPN 권한 요청이 표시되는지, 어떤 앱이 터널을 이용하는지, 백그라운드에서 계속 실행되는지는 클라이언트 구현과 시스템 제한의 영향을 모두 받습니다. 커널을 바꾼다고 이러한 권한이 자동으로 설정되지는 않습니다.
mihomo TUN 설정 예시 읽는 법
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
다음은 일반적인 데스크톱 환경을 위한 설정 항목 예시이며, 모바일에서 그대로 적용해야 하는 완전한 설정은 아닙니다. auto-route는 관련 라우트를 자동 설정하고, auto-detect-interface는 아웃바운드 인터페이스를 자동으로 찾으며, stack은 네트워크 스택 구현을 선택합니다. 권한, 라우팅 처리, 사용 가능한 옵션은 대상 시스템과 커널 버전에 따라 확인하세요.
설정 마이그레이션: 기본 파일을 먼저 실행한 다음 DNS와 덮어쓰기를 복원하세요
YAML은 들여쓰기로 구조를 표현하는 설정 형식입니다. 파일을 파싱할 수 있다는 것은 기본 구조를 읽을 수 있다는 뜻일 뿐입니다. 일부 알 수 없는 필드는 무시될 수 있으므로, 원하는 기능이 실제로 적용되었다고 단정할 수 없습니다. 마이그레이션 결과를 확인할 때는 시작 로그와 연결 기록, 실제 규칙 매칭 여부를 함께 살펴보세요.
1단계: 되돌릴 수 있는 설정 준비
- 기존 구독 주소와 현재 설정 사본, 클라이언트 덮어쓰기 내용을 보관하세요. 구독 주소는 민감 정보이므로 스크린샷이나 로그를 공유하기 전에 인증 정보를 가려야 합니다.
- 새 클라이언트에 별도의 설정을 추가하고, 기존 클라이언트에서 사용 중인 파일을 직접 덮어쓰지 마세요.
- 구독 서버가 Clash 또는 mihomo에서 인식할 수 있는 YAML을 반환하는지 확인하세요. 다른 클라이언트 형식이거나 공유 링크만 포함된 텍스트일 수 있습니다.
2단계: 기본 설정으로 문제 분리
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxies: []
proxy-groups:
- name: MANUAL
type: select
proxies:
- DIRECT
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- MATCH,MANUAL
이 예시는 설정 로드, 포트, 규칙 흐름을 확인하기 위한 것이며 모든 트래픽을 최종적으로 직접 연결합니다. 프록시 출구는 제공하지 않습니다. mixed-port: 7890은 하나의 수신 포트에서 HTTP와 SOCKS 프록시 연결을 모두 받는다는 뜻입니다. 휴대전화의 다른 앱이 이 포트를 거치는지는 VPN 트래픽 처리 여부나 앱 자체의 프록시 설정에 따라 달라집니다.
설정이 정상적으로 로드되면 클라이언트의 설정 병합·덮어쓰기 기능을 사용하거나 로컬 테스트 사본에 실제 노드와 정책 그룹을 추가하세요. 정책 그룹 이름은 규칙에서 참조하는 이름과 정확히 일치해야 합니다. 예를 들어 규칙에 PROXY가 있지만 설정에 MANUAL만 있다면 이름을 통일해야 합니다. 커널이 자동으로 이름을 추측해 주지는 않습니다.
3단계: DNS를 복원하고 한 번에 여러 항목을 바꾸지 않기
- 먼저 구독에 포함된
dns설정을 유지하고 기본 연결이 정상인지 확인한 다음 덮어쓸지 결정하세요. enhanced-mode: fake-ip를 사용한다면 커널에서 매핑하는 가상 주소를 반환한다는 점을 알아 두세요. 흔히 쓰는198.18.0.1/16주소 대역은 원격 서버의 실제 공인 IP가 아닙니다.nameserver와proxy-server-nameserver등의 필드는 용도가 다릅니다. 프록시 서버 도메인을 아직 구축되지 않은 프록시에 의존해 해석하면 순환 의존성이 생길 수 있습니다.- Fake-IP 모드를 변경한 뒤에는 필요에 따라 클라이언트 DNS 캐시를 비우고 테스트 앱을 다시 시작하세요. 이전 캐시가 실제 결과를 가리지 않도록 해야 합니다.
마이그레이션 확인: 오류 단계에 따라 점검
| 증상 | 우선 확인할 항목 | 다음 단계 |
|---|---|---|
| 설정을 시작할 수 없음 | YAML 들여쓰기, 노드 유형, 정책 이름, 커널 버전 | 로그의 행 번호를 기준으로 원인을 찾은 뒤 최소 설정으로 다시 테스트하세요 |
| 포트 수신 실패 | 7890 포트를 다른 인스턴스가 사용 중인지 확인 | 중복 인스턴스를 종료하거나 수신 포트와 앱 프록시 설정을 함께 변경하세요 |
| 지연 시간 테스트는 성공하지만 앱이 열리지 않음 | 테스트 URL과 실제 접속 대상의 차이, 규칙 출구, DNS, UDP | 해당 앱의 연결 기록에서 매칭된 규칙과 노드를 확인하세요 |
| 브라우저는 되지만 다른 앱은 실패 | 브라우저 프록시만 설정했는지, VPN 앱 제외 목록이 있는지 확인 | 시스템 VPN 상태와 클라이언트의 앱별 트래픽 분기 설정을 확인하세요 |
커널을 직접 실행할 수 있는 데스크톱 환경에서는 mihomo -t -f config.yaml으로 지정한 파일을 검사할 수 있습니다. 검사를 통과해도 서버에 연결할 수 있다는 뜻은 아니며, 클라이언트가 최종적으로 이 파일을 실행한다는 보장도 없습니다. 모바일에서는 ‘현재 활성화된 설정’과 구독 업데이트 후에도 덮어쓰기가 적용되는지 확인하세요.
마지막으로 최소 세 가지를 테스트하세요. 직접 연결되어야 하는 사이트, 프록시를 거쳐야 하는 대상, 화면을 잠근 뒤의 재연결을 각각 확인합니다. 규칙 매칭과 출구 선택, 백그라운드 연결 상태를 점검하세요. 새 프로토콜이나 확장 규칙이 필요하다면 커널 버전과 업데이트 기록이 명확한 클라이언트를 우선 선택하세요. 기본 설정만 사용하는 경우에도 기존 설정 사본을 보관하고 네트워크 설정을 한꺼번에 바꾸지 말고 단계적으로 마이그레이션하세요.