Clash 커널 버전 차이: 기본형·Meta·mihomo 설정 호환성

클라이언트 설정, 설정 저장소와 구독 안내에서는 Clash, Clash.Meta, Meta, mihomo가 자주 함께 등장합니다. 이 이름들이 서로 독립적인 네 가지 설정 체계를 뜻하는 것은 아니지만, 단순히 같은 프로그램의 표기만 다르다고 보기도 어렵습니다. YAML을 불러올 수 있는지 판단할 때는 파일 확장자뿐 아니라 실제로 실행되는 커널, 커널 버전, 클라이언트의 설정 전처리 방식, 구독 서비스가 출력한 확장 필드를 함께 확인해야 합니다.

기본 설정의 상당 부분은 이러한 커널 간에 재사용할 수 있습니다. 예를 들어 수신 포트, 프록시 노드, 정책 그룹과 일반적인 도메인 규칙이 그렇습니다. 하지만 TUN, 트래픽 스니핑, 신규 프로토콜, 규칙 집합, DNS 확장과 프로세스 매칭 기능에는 뚜렷한 차이가 있습니다. 커널을 잘못 선택하면 파일 전체를 읽지 못하기보다 일부 필드가 거부되거나, 특정 노드를 생성하지 못하거나, 규칙이 예상대로 적용되지 않거나, 그래픽 클라이언트에 해당 옵션 자체가 표시되지 않는 경우가 흔합니다.

Clash, Clash.Meta와 mihomo의 이름 관계

기본형 Clash

일반적으로 “기본형 Clash”는 초기 오픈 소스 Clash 커널과 기존 설정 문법을 가리킵니다. 현재도 널리 사용되는 기본 구조인 proxies, proxy-groups, rules, dns, mixed-port, external-controller 등의 필드를 정립했습니다. 많은 구독 변환 도구와 클라이언트 설정 템플릿도 이 구조를 공통 기반으로 사용합니다.

기본 프로젝트는 더 이상 지속적으로 유지보수되지 않습니다. 따라서 구형 기기나 기존 클라이언트에서 계속 정상 작동할 수는 있지만, 새로운 프로토콜이나 플랫폼 네트워크 인터페이스 변경, 이후 추가된 확장 필드를 지원하지는 않습니다. HTTP, SOCKS5, Shadowsocks, Trojan 등 기존 기능만 사용하는 오래된 설정이라면 단기간에는 차이를 느끼지 못할 수 있습니다. 하지만 구독에 최신 노드 유형이 추가되거나 새로운 규칙 기능에 의존하게 되면 호환성의 한계가 드러납니다.

Clash.Meta

Clash.Meta는 Clash 설정 체계를 바탕으로 발전한 분기입니다. 많은 기본 필드를 유지하면서 프록시 프로토콜, TUN, DNS, 스니핑, 규칙 유형과 플랫폼 호환 기능을 확장했습니다. 일부 클라이언트는 커널을 직접 “Meta”로 표시했고, 설정 문서에서도 “Meta 전용 필드”라는 표현을 자주 사용했기 때문에 이 이름은 지금도 구독 템플릿과 오류 로그에 등장합니다.

mihomo

mihomo는 Clash.Meta가 이후 채택한 프로젝트 이름입니다. 발전 과정으로 보면 일상적으로 말하는 최신 Meta와 mihomo는 서로 변환해야 하는 두 가지 설정 형식이라기보다, 같은 계열의 지속적인 커널 개발 흐름을 가리키는 경우가 많습니다. 다만 실제 판단에서는 버전 번호를 확인해야 합니다. 초기 Clash.Meta와 현재 mihomo 사이에는 필드 추가, 기본 동작 조정과 프로토콜 구현 업데이트가 있었기 때문입니다.

따라서 “Meta 지원”을 곧바로 “현재 mihomo의 모든 설정 지원”으로 볼 수는 없습니다. 구형 클라이언트에 Meta 커널이 내장되어 있어도 나중에 추가된 노드 매개변수를 인식하지 못할 수 있습니다. 반대로 최신 mihomo는 대체로 기본 Clash 설정을 읽을 수 있지만, 기존 필드의 동작과 기본값, 권장 작성 방식은 달라졌을 수 있습니다.

유지보수 상태·프로토콜·규칙 기능 비교

프로토콜 지원은 가장 쉽게 확인할 수 있는 차이입니다. 구독의 각 노드는 type과 관련 매개변수를 선언합니다. 커널이 노드 유형을 인식하지 못하면 보통 설정 검사나 시작 로그에 파싱 오류가 표시됩니다. 프로토콜은 인식하지만 특정 매개변수를 지원하지 않는 경우에도 필드 오류가 발생할 수 있습니다. 이런 문제는 정책 그룹 이름을 바꾼다고 해결되지 않으므로, 먼저 클라이언트에 내장된 커널 버전과 노드 프로토콜 요구 사항을 대조해야 합니다.

규칙 기능의 차이는 더 눈에 잘 띄지 않습니다. DOMAIN-SUFFIX, DOMAIN, IP-CIDR, GEOIP, MATCH 같은 기본 규칙은 호환성이 높습니다. 규칙 집합 동작, 프로세스 이름, 네트워크 유형, 인바운드 태그 또는 논리 조합을 사용하는 설정은 mihomo의 구체적인 버전에 더 크게 의존합니다. 설정이 실행된다고 해서 확장 규칙이 작성자의 의도대로 적용된다는 뜻은 아니므로, 마이그레이션 후에는 연결 기록에서 실제 매칭 항목을 확인해야 합니다.

일반적으로 호환되는 YAML 필드

다음 구조는 버전 간 호환 설정의 기반으로 사용하기 좋습니다. 실제 서버 인증 정보는 포함하지 않고 필드 관계만 보여 줍니다.

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

proxies:
  - name: Example-Node
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - Example-Node
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

mixed-port는 HTTP와 SOCKS 프록시 진입점을 동시에 제공합니다. mode: rule은 규칙에 따라 연결 경로를 결정한다는 뜻입니다. 정책 그룹 이름은 규칙 끝에서 참조하는 대상과 반드시 일치해야 합니다. 예를 들어 규칙은 Proxy를 가리키는데 실제 정책 그룹 이름이 PROXY라면, 이는 커널 분기와 관계없는 오류이며 어떤 커널도 두 이름을 같은 그룹으로 자동 인식하지 않습니다.

노드 필드는 호환성 검사의 첫 단계입니다. proxies 목록 자체가 일반적인 구조라도 목록 안의 프로토콜 유형, 전송 계층 매개변수, TLS 지문, UDP 동작과 인증 옵션은 특정 버전에서만 지원될 수 있습니다. 구독 서비스가 노드 템플릿을 업데이트한 뒤 구형 클라이언트가 갑자기 시작되지 않는다면, 구독 출력 형식보다 커널 버전이 오래된 경우가 많습니다.

DNS는 두 번째 단계입니다. 기본적인 enhanced-mode: fake-ip, 기본 리졸버와 보조 리졸버는 널리 알려져 있지만, nameserver-policy, 프록시 서버 도메인 해석, Fake-IP 제외 목록과 업스트림별 전송 형식은 커널 버전에 따라 달라질 수 있습니다. 최신 mihomo 예시를 구형 Clash에 복사하기 전에는 오류가 난 첫 줄만 삭제하지 말고 커널 문서를 항목별로 확인해야 합니다.

TUN·스니핑·규칙 집합에서 문제가 생기기 쉬운 이유

TUN은 단순한 스위치가 아닙니다

TUN 모드는 커널이 가상 네트워크 인터페이스를 통해 트래픽을 받아 시스템 프록시 설정을 따르지 않는 앱에도 적용할 수 있게 합니다. mihomo 설정에서는 tun 블록과 enable, stack, auto-route, auto-detect-interface 등의 매개변수를 자주 사용합니다. 정상 작동 여부는 운영체제 권한, 라우팅 테이블, 기존 VPN, 가상 머신 네트워크와 클라이언트가 서비스 구성 요소를 올바르게 시작했는지에 따라서도 달라집니다.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

이 설정을 기본형 또는 구형 Meta 커널에 넣으면 알 수 없는 필드 오류가 발생하거나 플랫폼 구현 차이로 인터페이스를 만들지 못할 수 있습니다. 커널이 지원하더라도 그래픽 클라이언트가 시작 과정에서 TUN 설정을 다시 쓸 수 있습니다. 따라서 커널 버전 확인, 설정 검사 결과 확인, 시작 로그 확인, 시스템 권한 점검, 라우팅 충돌 확인 순서로 문제를 추적해야 합니다.

스니핑은 도메인 정보를 복원합니다

트래픽 스니핑은 HTTP, TLS 또는 기타 식별 가능한 트래픽에서 대상 도메인을 추출하여 IP 연결로만 보이는 요청도 도메인 규칙 매칭에 참여할 수 있게 합니다. mihomo는 스니핑 프로토콜, 포트 범위, 강제 도메인과 제외 도메인을 세밀하게 제어할 수 있습니다. 구형 커널은 이러한 필드를 직접 처리하지 못하며, 잘못된 설정은 로컬 네트워크 서비스, 게임 연결 또는 특수 핸드셰이크를 사용하는 앱에도 영향을 줄 수 있습니다.

규칙 집합은 형식과 동작을 함께 확인해야 합니다

원격 규칙 집합에는 다운로드 주소, 캐시 갱신, 규칙 동작 유형과 콘텐츠 형식이 관련됩니다. 커널과 버전에 따라 Rule Provider 또는 Rule Set의 필드 이름, 페이로드 형식과 갱신 방식이 다를 수 있습니다. 규칙 파일 다운로드가 성공한 것만으로는 충분하지 않습니다. 대상 규칙에서 실제로 참조되는지, 집합의 동작이 콘텐츠와 일치하는지도 확인해야 합니다. 예를 들어 도메인 집합을 IP 대역 집합과 같은 방식으로 해석할 수는 없습니다.

규칙 목록은 위에서 아래로 매칭됩니다. 어떤 커널을 사용하든 너무 앞에 광범위한 규칙을 두면 뒤의 매칭이 중단됩니다. MATCH는 일반적으로 마지막에 배치해야 하며, 로컬 네트워크와 사설 주소의 직접 연결 규칙은 적절한 위치에 둬야 합니다. Fake-IP를 활성화했다면 DNS 매핑과 규칙 판단을 연결 로그와 함께 확인해야 합니다. 커널 업그레이드가 잘못된 규칙 순서를 자동으로 고쳐 주지는 않습니다.

클라이언트 이름과 실제 커널 확인 방법

그래픽 클라이언트는 보통 앱 디렉터리에 커널 파일을 포함하고, 제어 인터페이스를 통해 프록시 그룹, 연결, 로그와 설정 상태를 읽습니다. 설정에서 커널을 전환할 수 있는 클라이언트도 있고 특정 분기를 고정 사용하는 클라이언트도 있으며, 앱 업그레이드와 함께 커널을 업데이트하는 경우도 있습니다. 실제 환경은 다음 순서로 확인할 수 있습니다.

1. 정보 페이지 또는 로그의 첫 줄을 확인합니다. 시작 로그에는 대개 커널 이름, 버전과 빌드 정보가 표시되므로 클라이언트 소개 페이지보다 현재 실행 상태를 더 정확히 보여 줍니다.
2. 클라이언트의 설정 검사 기능을 사용합니다. 먼저 YAML 문법을 확인한 다음, 오류가 알 수 없는 필드·노드 유형·유효하지 않은 값 중 어디를 가리키는지 살펴봅니다.
3. 오버라이드와 구독 변환을 확인합니다. 클라이언트가 로드 전에 로컬 설정을 병합할 수 있으므로 디스크에 저장된 구독 원문이 커널이 최종적으로 받은 설정과 다를 수 있습니다.
4. 제어 인터페이스 호환성을 확인합니다. mihomo는 많은 Clash API 구조를 이어받았지만, 확장 기능이 구형 인터페이스에 모두 표시된다고 보장할 수는 없습니다.
5. 커널 전환이 실제로 적용됐는지 확인합니다. 파일을 교체한 뒤에는 기존 프로세스를 완전히 종료하고 다시 시작하여, 화면이 백그라운드에 남은 인스턴스에 계속 연결되지 않도록 해야 합니다.

클라이언트 인터페이스에 특정 옵션이 없다고 해서 커널에 해당 기능이 없는 것은 아닙니다. 아직 설정 화면을 제공하지 않을 뿐일 수 있습니다. 반대로 인터페이스에 오래된 스위치가 남아 있어도 현재 커널이 같은 기본값을 사용한다는 보장은 없습니다. 고급 필드는 YAML 또는 오버라이드 파일에서 직접 편집하고, 시작 후 최종 설정과 로그를 확인하는 방법이 가장 안전합니다.

모바일과 데스크톱은 시스템 기능에도 차이가 있습니다. 데스크톱 클라이언트는 시스템 프록시 또는 TUN으로 트래픽을 제어하는 경우가 많고, 모바일 운영체제는 대개 시스템이 제공하는 VPN 인터페이스에 의존합니다. 같은 mihomo 설정을 여러 플랫폼에 복사할 수는 있지만, 인바운드 포트, TUN 라우팅, 로컬 네트워크 접근과 DNS 제어 설정은 플랫폼에 맞게 조정해야 합니다.

기본형 Clash에서 mihomo로 마이그레이션하는 단계

구형 커널에서 마이그레이션할 때 처음부터 모든 새 기능을 한꺼번에 추가하는 것은 권장하지 않습니다. 먼저 기존 설정이 새 커널에서 안정적으로 작동하게 한 뒤 DNS, TUN, 스니핑과 규칙 집합을 단계적으로 활성화해야 문제를 쉽게 좁힐 수 있습니다.

1. 기존 설정과 클라이언트 설정을 보존합니다. 구독 원문, 로컬 오버라이드, 정책 그룹 선택과 DNS 설정을 각각 백업하여 여러 출처의 설정이 되돌리기 어려운 하나의 파일로 섞이지 않게 합니다.
2. 최소 실행 설정을 만듭니다. 사용 가능한 노드 하나, 선택 정책 그룹 하나와 소수의 규칙만 남겨 커널이 시작되고 연결을 수립하는지 확인합니다.
3. 전체 노드와 정책 그룹을 복원합니다. 그룹 내부의 참조 이름, 자동 속도 측정 주소, 필터 표현식과 프로토콜 매개변수를 중점적으로 확인합니다.
4. 규칙을 복원합니다. 먼저 기본 도메인 및 IP 규칙을 추가한 뒤 원격 집합을 연결하고, 변경할 때마다 규칙 매칭과 로그를 확인합니다.
5. DNS를 설정합니다. 기본 해석, 프록시 노드 도메인 해석과 Fake-IP 제외 항목을 확인한 다음 로컬 네트워크 도메인과 특수 앱을 점검합니다.
6. 마지막으로 TUN과 스니핑을 활성화합니다. 두 기능은 시스템 트래픽 진입점과 대상 식별 방식을 바꾸므로 브라우저, 터미널, 게임과 로컬 네트워크 접근을 각각 테스트해야 합니다.

마이그레이션 후 “브라우저는 되지만 터미널은 안 되는” 경우에는 터미널이 시스템 프록시를 읽는지, 환경 변수가 설정되어 있는지, TUN이 필요한지를 확인해야 합니다. “노드는 연결되지만 도메인이 열리지 않는” 경우에는 DNS 업스트림, Fake-IP 모드와 노드 서버 도메인 해석을 점검합니다. “일부 웹사이트의 정책이 잘못 적용되는” 경우에는 모든 노드를 바로 교체하지 말고 실제 매칭 규칙부터 확인해야 합니다.

새 커널에서 필드 사용 중단 알림이 표시되면 호환 처리에 계속 의존하지 말고 현재 버전 문서에 따라 필드를 바꾸세요. 설정 파일은 지속적으로 실행되는 인프라이므로 의미를 잃은 필드를 남겨 두면 이후 업그레이드 비용이 커집니다. 구독에서 생성되는 필드는 구독 템플릿이나 변환 규칙을 우선 수정하여, 업데이트 때마다 수동으로 고치지 않도록 해야 합니다.

사용 시나리오별 커널 선택

기존 구형 환경 계속 사용

기기가 장기간 오프라인이고 설정과 노드 프로토콜이 고정되어 있으며 클라이언트와 시스템 버전도 더 이상 바뀌지 않는다면 기본형 Clash로 기존 용도를 유지할 수 있습니다. 다만 이는 현 상태를 유지하기 위한 선택이며 새로운 배포의 기준으로 삼기에는 적합하지 않습니다. 구독에 새 프로토콜이나 매개변수가 추가되는 순간 구형 커널의 호환성 한계가 드러날 수 있습니다.

신규 설치 및 지속적으로 갱신되는 구독

신규 설치, 잦은 구독 업데이트, TUN 사용 또는 최신 규칙 기능이 필요한 환경이라면 최신 mihomo가 내장된 클라이언트를 우선 선택하세요. 클라이언트를 고를 때는 인터페이스 모양만 비교하지 말고 커널 업데이트 방식, 설정 디렉터리, 로그 위치, 시스템 프록시 제어와 TUN 서비스 설치 방식도 함께 확인해야 합니다.

여러 기기에서 설정 공유

여러 기기에서 사용할 설정은 호환성이 높은 기본 계층을 중심으로 구성하고 플랫폼별 오버라이드를 추가해야 합니다. 노드와 정책 그룹은 같은 구독에서 가져오고, 데스크톱에는 TUN과 프로세스 규칙을 추가하며, 모바일에는 시스템 VPN 인터페이스에 맞는 설정을 유지하고, 서버에서는 명령줄 서비스와 환경 변수 요구 사항에 맞게 처리할 수 있습니다. 이렇게 하면 특정 플랫폼 전용 필드 때문에 다른 기기에서 설정을 불러오지 못하는 문제를 피할 수 있습니다.

서버 또는 명령줄 배포

Linux 서버, 소프트 라우터 또는 컨테이너에서 커널을 직접 실행한다면 mihomo의 지속적인 유지보수는 적합한 배포 기반이 됩니다. 설정 문법뿐 아니라 통제 가능한 버전 업데이트 절차도 고정하고, 설정 디렉터리, 작업 디렉터리, Geo 데이터 위치, 제어 포트와 서비스 권한을 명확히 해야 합니다. 업그레이드 전에는 설정 검사를 실행하고, 이후 서비스를 재시작한 다음 로그를 확인하여 문법 문제를 네트워크 장애로 잘못 판단하지 않도록 하세요.

자주 발생하는 호환성 문제