Clash 코어 버전 차이: 클래식, Meta, mihomo 기능 및 호환성 비교

1. 클래식 Clash, Clash.Meta, mihomo의 관계

Clash는 특정 데스크톱 창이나 모바일 앱 하나를 뜻하지 않습니다. 일반적인 사용 구조는 네트워크 처리를 담당하는 코어, 조작 화면을 제공하는 클라이언트, 로컬 파일이나 구독 서비스에서 생성되는 YAML 설정의 세 계층으로 이루어집니다. 코어는 프록시 노드, 규칙, 정책 그룹을 해석하고 DNS, 시스템 프록시, TUN 연결을 실행합니다. 클라이언트는 코어 실행, 구독 업데이트, 로그 표시, 정책 전환을 담당합니다.

클래식 Clash는 proxies, proxy-groups, rules, proxy-providers, rule-providers와 같은 일반적인 설정 구조를 정립했습니다. 오늘날에도 많은 구독 변환 도구가 이 구조를 기반으로 합니다. 그러나 클래식 프로젝트는 더 이상 지속적으로 유지보수되지 않으므로 새로운 프로토콜, 운영체제 네트워크 변화, 장기간 누적된 문제를 계속 반영하지 못합니다. 기존 설정을 실행할 수 있다는 사실만으로 새 환경의 기본 코어로 적합하다고 보기는 어렵습니다.

Clash.Meta는 처음에 Clash 설정 체계를 확장하는 유지보수 분기로 시작해 더 많은 프록시 프로토콜, 규칙 기능, DNS 옵션, 투명 프록시 관련 기능을 추가했습니다. 이후 이 프로젝트는 현재 명칭으로 mihomo를 사용하게 되었습니다. 따라서 “Meta 코어”와 “mihomo 코어”는 대개 동시에 발전하는 완전히 별개의 현대 코어가 아닙니다. 전자는 과거 버전, 클라이언트 호환성 표기, 오래된 문서에서 주로 보이고, 후자는 현재의 유지보수 명칭입니다.

일부 클라이언트는 여전히 “Clash Meta”로 표시하지만, 코어 파일명과 로그의 시작 줄, 프로젝트 문서에는 mihomo라고 적혀 있을 수 있습니다. 이러한 명칭 차이만으로 클라이언트가 오래되었다고 판단할 수는 없습니다. 코어 버전 날짜, 배포 출처, 지원 설정 필드, 업데이트 정상 여부를 확인해야 하며, 화면의 한 라벨만으로 결론을 내려서는 안 됩니다.

2. 프로토콜 지원 차이: 먼저 구독 노드 유형 확인하기

프로토콜 지원은 코어를 선택할 때 가장 직접적인 판단 기준입니다. 클래식 Clash는 유지보수 당시 구현되어 있던 Shadowsocks, SOCKS, HTTP, VMess, Trojan 등의 일반적인 프록시 유형을 처리할 수 있지만, 이후 Meta 계열에 추가된 모든 프로토콜과 확장 매개변수까지 지원하지는 못합니다. 구독에 VLESS, Reality, Hysteria2, TUIC 또는 최신 WireGuard 사용 방식이 포함되어 있다면 일반적으로 최신 mihomo 코어가 필요하며, 노드 제공자가 지정한 구체적인 필드를 현재 버전이 지원하는지도 함께 확인해야 합니다.

프로토콜 이름이 같다고 해서 호환성이 보장되는 것은 아닙니다. 예를 들어 Shadowsocks는 암호화 방식도 관련되고, VMess와 VLESS는 WebSocket, gRPC, TLS, Reality 등의 전송 매개변수와 조합될 수 있습니다. Hysteria2와 TUIC는 인증서, 혼잡 제어, 포트 범위, UDP 네트워크 조건의 영향도 받습니다. 코어는 노드 유형뿐 아니라 해당 노드에 사용된 매개변수 조합까지 인식하고 해석할 수 있어야 합니다.

구독을 가져온 뒤 노드가 바로 사라지거나 설정 로드에 실패하거나 로그에 필드 해석 오류가 나타난다면 먼저 원본 설정의 type, network, cipher, reality-opts 등의 필드를 확인한 다음 코어 버전을 대조하세요. 시스템 프록시를 반복해서 전환하는 것부터 시작하지 마세요. 설정이 아직 정상적으로 로드되지 않았다면 시스템 프록시 상태를 바꿔도 프로토콜 해석 문제는 해결되지 않습니다.

프로토콜 요구 사항에 따른 코어 선택

• 기존 노드와 기본 규칙만 사용: 오래된 코어에서도 실행될 수 있지만, 새 기기에서 굳이 유지보수가 중단된 클래식 Clash를 선택할 이유는 없습니다.
• 구독에 VLESS 또는 Reality 포함: 최신 mihomo를 선택하고, 클라이언트가 링크 가져오기만 지원하는 것이 아니라 실제로 해당 코어를 호출하는지 확인하세요.
• Hysteria2, TUIC 등 UDP 관련 프로토콜 필요: 코어 지원 여부뿐 아니라 로컬 네트워크, 라우터, 서버의 포트 정책도 확인해야 합니다.
• 구독 변환으로 설정 생성: 변환 대상은 mihomo 또는 Clash.Meta 형식에 맞춰야 하며, 도구가 클래식 Clash용으로 확장 필드를 삭제하지 않도록 주의하세요.

3. 규칙, 정책 그룹, DNS 기능의 차이

기본 규칙 작성 방식은 세 명칭이 가리키는 코어 체계에서 상당한 연속성을 유지합니다. 일반적인 DOMAIN, DOMAIN-SUFFIX, IP-CIDR, GEOIP, MATCH는 여전히 설정의 뼈대이며, select, url-test, fallback, load-balance 등의 정책 그룹도 Clash의 설계 방식을 이어갑니다. 따라서 대부분의 기본 구독은 클래식 구조에서 mihomo로 이전할 수 있습니다.

차이는 주로 확장 규칙, 규칙 집합 형식, 스니핑, DNS 라우팅, 정책 그룹의 추가 매개변수에서 나타납니다. mihomo는 더 풍부한 규칙 표현을 지원하며 규칙 집합, 프로세스 정보, 네트워크 유형, 논리 조건을 결합해 트래픽을 라우팅할 수 있습니다. 구체적인 필드는 버전에 따라 발전하므로 복잡한 규칙을 사용할 때는 해당 버전의 문서를 기준으로 삼고, 수년 전 예시를 현재 설정에 그대로 복사하지 마세요.

DNS 측면에서 클래식 Clash도 fake-ip와 같은 기본 기능을 제공하지만, mihomo는 도메인 확인 정책, 지정 DNS 서버, 규칙 연동, Fake IP 제외 기능을 더 세밀하게 제어할 수 있습니다. 설정이 복잡할수록 DNS 요청을 누가 처리하는지, 도메인을 언제 확인하는지, 규칙 매칭에 도메인과 대상 IP 중 무엇을 사용하는지 명확히 해야 합니다. 그렇지 않으면 노드 자체는 연결되지만 특정 웹사이트의 DNS 조회가 실패하거나, 로컬 도메인이 작동하지 않거나, 앱이 예상한 정책을 우회하는 문제가 발생할 수 있습니다.

proxy-groups:
  - name: 자동 선택
    type: url-test
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 300

rules:
  - DOMAIN-SUFFIX,example.com,자동 선택
  - GEOIP,CN,DIRECT
  - MATCH,자동 선택

위 예시는 흔히 사용하는 기본 구조이지만, proxy-providers에 provider-main이라는 프록시 집합이 이미 정의되어 있어야 합니다. 테스트 주소, 간격, 정책 이름도 실제 네트워크에 맞게 조정해야 합니다. 기존 설정을 이전한다면 먼저 단순한 규칙만 남겨 연결을 확인하고, 이후 규칙 집합, DNS 정책, 논리 조건을 단계적으로 추가하는 편이 복잡한 설정을 한 번에 로드하는 것보다 문제를 찾기 쉽습니다.

규칙을 이전할 때 확인할 항목

1. 각 규칙 대상이 실제로 존재하는 정책 그룹 또는 프록시 노드에 연결되는지 확인하세요.
2. 원격 규칙 집합의 형식, 유형, 다운로드 주소가 현재 코어의 요구 사항과 일치하는지 확인하세요.
3. 정책 그룹이 참조하는 프록시 집합이 정상적으로 업데이트되었는지 확인해 그룹 안에 실제로 사용 가능한 노드가 없는 상황을 피하세요.
4. MATCH를 규칙 목록의 마지막에 두어 앞선 규칙에 매칭되지 않은 연결을 처리하게 하세요.
5. DNS 모드를 변경한 뒤 필요한 시스템 DNS 캐시를 삭제하고, 도메인 접속과 IP 접속을 각각 테스트하세요.

4. 설정 호환성: 기본 호환이 양방향 호환을 뜻하지는 않습니다

mihomo는 클래식 Clash의 많은 필드를 이어받았기 때문에 클래식 설정을 mihomo로 이전하는 작업은 대체로 순조롭습니다. 하지만 반대 방향도 가능하다고 단정해서는 안 됩니다. 새 프로토콜, 확장 규칙, 강화된 DNS 필드, 최신 TUN 매개변수를 사용한 설정이라면 클래식 코어가 로드를 거부하거나 인식하지 못하는 부분을 무시할 수 있습니다. “Clash 설정 호환”이라는 표현은 일반적으로 기본 구조와의 호환을 뜻하며, 모든 버전이 같은 파일을 차이 없이 읽는다는 의미는 아닙니다.

코어 설정과 클라이언트 설정도 구분해야 합니다. YAML의 프록시 포트, 규칙, DNS는 보통 코어가 읽지만, 시작 시 자동 실행, 트레이 동작, 구독 갱신 주기, 인터페이스 테마, 시스템 서비스 권한은 클라이언트 설정에 속합니다. 한 클라이언트의 설정 디렉터리 전체를 다른 클라이언트에 복사하면 경로, 데이터베이스, 서비스 상태 문제까지 함께 옮겨질 수 있습니다. 이전할 때는 구독을 다시 가져오거나 검토가 끝난 코어 YAML만 옮기는 방법이 더 안전합니다.

일부 클라이언트는 구독 파일 외에 TUN, DNS, 제어 포트, 로컬 규칙을 삽입하기 위한 오버라이드 설정을 추가로 생성합니다. 화면에 표시되는 설정과 실제 코어에 전달되는 최종 설정이 다를 수 있습니다. 호환성 문제를 해결할 때는 구독 원문만 보지 말고 클라이언트가 제공하는 “실행 설정”, “병합 후 설정”, 코어 로그를 확인해야 합니다.

기존 코어에서 mihomo로 이전하는 순서

1. 현재 사용할 수 있는 클라이언트, 코어 버전, 수신 대기 포트, 시스템 프록시 상태를 기록하세요.
2. 필요한 로컬 규칙과 정책 그룹 구성을 내보내되 클라이언트 실행 디렉터리를 그대로 복사하지 마세요.
3. 새 클라이언트에서 원본 구독을 가져오고, 먼저 사용자 지정 오버라이드를 끈 상태에서 노드 연결을 확인하세요.
4. 규칙, DNS, TUN 설정을 하나씩 복원하고 변경할 때마다 시작 로그를 확인하세요.
5. 브라우저, 명령줄 프로그램, 스토어 앱, UDP가 필요한 앱을 각각 테스트해 연결 범위가 예상과 일치하는지 확인하세요.

5. TUN 모드와 운영체제 트래픽 연결 범위

시스템 프록시는 운영체제의 프록시 설정을 따르는 앱에 주로 영향을 주므로 브라우저와 일반적인 데스크톱 소프트웨어에 적합합니다. 일부 게임, 명령줄 도구, 스토어 앱, 자체 네트워크 스택을 사용하는 프로그램은 시스템 프록시를 읽지 않을 수 있습니다. TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 트래픽을 처리하므로 TCP와 UDP를 통합적으로 연결해야 하는 상황에서 자주 사용됩니다.

mihomo는 TUN, DNS 하이재킹, 자동 라우팅 설정, 트래픽 스니핑을 비교적 완전하게 구현하지만, 실제 결과는 클라이언트가 권한을 요청하고 서비스를 설치하며 시스템 라우팅을 설정하는 방식에 따라 달라집니다. Windows에서는 서비스 모드나 관리자 권한이 필요할 수 있고, macOS에서는 네트워크 확장 관련 권한을 요청합니다. Linux에서는 장치 권한, 라우팅 테이블, 방화벽이 관련됩니다. 모바일 클라이언트는 일반적으로 시스템 VPN 인터페이스를 사용하며, 백그라운드 제한이 연결 유지에 영향을 줄 수도 있습니다.

TUN 모드는 켠다고 해서 반드시 더 빨라지는 기능이 아닙니다. 연결 범위를 넓히는 대신 DNS, 라우팅, 루프백 처리의 복잡성도 증가합니다. 브라우저가 시스템 프록시만으로 충분하다면 단순한 설정을 유지하는 편이 관리하기 쉽습니다. 게임의 UDP, 터미널 프로그램, 특정 앱이 시스템 프록시를 통과하지 못할 때 TUN을 활성화하고 항목별로 확인하는 방식이 더 적절합니다.

클래식 코어에서 이전할 때 기존 TUN 예시를 그대로 복사해서는 안 됩니다. 버전에 따라 네트워크 스택 옵션, 자동 라우팅 필드, DNS 연동 방식이 달라질 수 있습니다. 클라이언트에 TUN 스위치가 있다면 먼저 클라이언트가 생성한 설정을 사용하고, 로그를 확인하면서 제외할 네트워크 대역, 로컬 네트워크 접근, DNS 정책을 보완하세요.

6. 리소스 사용량과 성능: 실제 설정으로 측정하기

“기능이 많다”는 사실만으로 리소스 사용량이 반드시 높다고 단정할 수는 없습니다. 코어 부하는 동시 연결 수, 규칙 수, 규칙 집합 크기, 로그 수준, DNS 캐시, 프로토콜 암호화 방식, TUN 트래픽, 클라이언트 인터페이스가 함께 결정합니다. 같은 기기에서도 간결하게 구성한 mihomo가 많은 규칙과 지속적인 디버그 로그를 사용하는 기존 설정보다 안정적일 수 있습니다.

데스크톱 클라이언트에 표시되는 메모리 사용량에는 그래픽 인터페이스, WebView, 구독 데이터베이스, 업데이트 서비스도 포함되므로 전부 코어 탓으로 돌려서는 안 됩니다. 코어를 비교하려면 같은 노드, 같은 규칙, 같은 연결 모드, 비슷한 트래픽 조건에서 독립 코어 프로세스를 관찰해야 합니다. 시작 직후의 유휴 상태, 지속 다운로드, 연결 수 증가, 규칙 업데이트 후의 변화를 함께 기록해야 의미 있는 비교가 됩니다.

모바일 기기에서는 지속적인 깨우기, 불안정한 네트워크에서의 재연결, 백그라운드 실행 시간에 특히 주의해야 합니다. 정책 그룹의 테스트 간격이 너무 짧으면 테스트 주소에 주기적으로 접속합니다. 자동 업데이트되는 프록시 집합과 규칙 집합이 많아도 네트워크 활동이 증가합니다. 상태 확인과 업데이트 주기를 적절히 늘리고, 장시간 디버그 로그를 끄며, 사용하지 않는 규칙 집합을 삭제하는 편이 기존 코어로 되돌리는 것보다 대개 효과적입니다.

일반적인 성능 최적화 순서

• 먼저 로그 수준을 일상적인 사용에 필요한 수준으로 낮추고, 문제를 해결할 때만 상세 로그를 활성화하세요.
• 중복 규칙과 사용하지 않는 원격 규칙 집합을 줄여 업데이트마다 같은 데이터를 여러 번 처리하지 않도록 하세요.
• url-test, 프록시 집합 상태 확인, 구독 업데이트 간격을 적절히 늘리세요.
• 비정상적인 사용량이 코어 프로세스에서 발생하는지 클라이언트 인터페이스에서 발생하는지 확인한 뒤 업그레이드, 초기화, 클라이언트 교체 여부를 결정하세요.
• TUN과 시스템 프록시를 번갈아 테스트해 문제가 연결 범위와 관련 있는지 판단하세요.

7. 상황별 코어 선택 가이드

새 사용자 또는 새 기기: 최신 mihomo 코어가 내장되어 있고 코어 버전과 설정 로그를 표시하는 클라이언트를 선택하세요. 최신 구독에서 흔히 사용하는 프로토콜과 규칙 형식을 폭넓게 지원하고 이후 업데이트도 편리합니다. 클라이언트 이름에 Clash가 포함되어 있는지는 핵심 조건이 아니며, 실제 코어와 유지보수 상태가 더 중요합니다.

아직 클래식 Clash를 사용하는 기존 환경: 현재 설정이 안정적이고 업무상 변경할 필요가 없다면 먼저 실행 환경을 기록한 뒤 이전을 계획해도 됩니다. 업무 중에 서둘러 교체할 필요는 없습니다. 다만 새 프로토콜, 새로운 운영체제 대응, 보안 및 안정성 수정이 필요해지는 즉시 유지보수 중인 mihomo로 전환해야 합니다. 이전 전에는 정책 그룹 이름, DNS, 규칙 집합, TUN 필드를 중점적으로 확인하세요.

Clash.Meta 다운로드 항목이 보일 때: 먼저 출시일과 코어 로그를 확인하세요. 최신 클라이언트가 사용자 식별을 위해 Meta라는 이름을 계속 사용할 수도 있지만 실제로는 mihomo를 실행할 수 있습니다. 반대로 오랫동안 업데이트되지 않은 설치 파일에는 이전 버전의 Meta 코어가 포함되어 있을 수 있습니다. 이름이 같아도 유지보수 상태는 완전히 다를 수 있습니다.

기본 구독과 시스템 프록시만 사용하는 경우: mihomo가 여전히 적합합니다. 새 코어를 선택한다고 해서 모든 고급 기능을 활성화해야 하는 것은 아닙니다. 간단한 노드, 정책 그룹, 규칙만 계속 사용할 수 있습니다. 이해하지 못한 옵션을 새 기능이라는 이유로 덧붙이기보다 설정 범위를 명확히 유지하는 편이 더 안정적입니다.

복잡한 라우팅, 최신 프로토콜, TUN이 필요한 경우: 최신 mihomo를 우선 사용하고 시스템 서비스, 권한, 설정 오버라이드를 올바르게 관리할 수 있는 클라이언트를 선택하세요. 문제가 발생하면 “설정이 로드되었는가, 노드가 연결되는가, 규칙이 매칭되는가, 시스템 트래픽이 연결되었는가”의 순서로 확인해 여러 항목을 동시에 수정하지 않도록 하세요.