mihomo 코어와 오리지널 Clash 코어의 차이 총정리: 신규 프로토콜과 규칙 기능 분석

코어란 무엇이며, 클라이언트 화면과는 어떤 관계인가

Clash 생태계에서 "클라이언트"와 "코어"는 서로 독립된 두 부분입니다. 코어(core)는 그래픽 인터페이스가 없는 실행 프로그램으로, 설정 파일을 해석하고, 프록시 연결을 수립하고, 분기 규칙을 실행하고, DNS 조회를 처리하며, 로컬 HTTP API(보통 127.0.0.1:9090에서 대기)를 통해 상태와 제어 인터페이스를 외부에 노출합니다. 클라이언트(Clash Plus, Clash Verge Rev, FlClash 등)는 이 코어를 감싸는 그래픽 인터페이스로, 구독 관리, 노드 표시, 스위치 전환을 담당하며, 실제 프록시 작업은 모두 코어로 전달되어 처리됩니다.

이 계층 구조가 의미하는 중요한 사실이 하나 있습니다. 클라이언트는 껍데기를 바꾸기 쉽지만, 코어는 세대교체가 쉽지 않습니다. 사용자가 평소 체감하는 "화면이 편한가"는 클라이언트 층의 차이이고, "어떤 프로토콜을 지원하는가", "어떤 규칙을 작성할 수 있는가"는 전적으로 코어 버전에 달려 있습니다. 이것이 바로 Clash 생태계를 논할 때 코어를 별도로 떼어내 분석할 필요가 있는 이유입니다.

오리지널 Clash 코어의 현재 상태: 업데이트 중단과 아카이브

커뮤니티가 관리하던 초창기 오리지널 Clash 코어(저장소 이름은 보통 Clash 또는 Clash Premium)는 업데이트가 중단되었고, 저장소는 아카이브(archived) 상태로 전환되어 새로운 이슈나 PR을 받지 않으며, 더 이상 새 버전도 배포되지 않습니다. 이유는 Clash for Windows 그래픽 클라이언트가 내려간 배경과 비슷하게, 원 제작자 계정과 관련 저장소가 내려간 것과 관련이 있습니다.

오리지널 코어가 업데이트를 멈춘 시점의 기능 수준은 대략 다음과 같습니다.

• 프로토콜 지원: Shadowsocks, ShadowsocksR, VMess, Trojan, Snell 등 주요 프로토콜을 지원하며, Hysteria, TUIC 등 이후에 등장한 프로토콜은 포함하지 않습니다.
• 규칙 유형: DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD, IP-CIDR, GEOIP, MATCH 등 기본 규칙만 지원하며, rule-providers 원격 규칙셋 메커니즘이나 프로세스 단위 규칙은 없습니다.
• DNS 기능: 기본적인 DNS 포워딩과 오염 방지 기능만 제공하며, Fake-IP 세밀 관리와 스니핑(sniffer) 기능은 없습니다.
• TUN 모드: 초기 버전은 지원하지 않거나 지원 범위가 매우 제한적이었고, 플랫폼 간 일관성도 낮았습니다.

일반 사용자 입장에서 오리지널 코어는 여전히 기존 설정 파일을 실행할 수 있고, 흔히 쓰는 노드에도 연결할 수 있어 갑자기 못 쓰게 되는 것은 아닙니다. 다만 새로운 기능은 더 이상 추가되지 않고, 발견되는 버그도 공식적으로 수정되지 않으므로, 장기간 사용할 경우 기능이 뒤처질 위험이 있습니다.

mihomo(Clash Meta)란 무엇이며 오리지널과 어떤 관계인가

mihomo의 전신은 커뮤니티 포크 프로젝트인 Clash Meta로, 오리지널 코어 개발이 멈춘 뒤 다른 기여자 그룹이 오리지널 코드를 기반으로 개발을 이어가며 새 프로토콜, 새 규칙 유형, 성능 최적화를 계속 병합했고, 이후 정식으로 mihomo라는 독립된 이름을 갖게 되었습니다. 현재 시장에서 활발히 업데이트되는 데스크톱·모바일 클라이언트 — Clash Plus, Clash Verge Rev, FlClash, Clash Meta for Android의 후속 포크를 포함해 — 는 거의 전부 밑단에서 mihomo 코어를 구동하며, 오리지널 코어를 쓰지 않습니다.

혼동하기 쉬운 부분을 짚어두자면, mihomo는 완전히 새로 시작한 프로젝트가 아니라, 설정 파일 문법이 오리지널 코어와 높은 호환성을 유지하고 있습니다. 대부분의 오리지널 설정 필드(port, mode, proxies, proxy-groups, rules 등)는 그대로 유지할 수 있으며, mihomo는 이를 기반으로 "확장"을 한 것이지 "교체"를 한 것이 아닙니다. 이것이 바로 기존 설정 파일을 mihomo 코어 기반 클라이언트로 옮길 때 대부분의 경우 설정을 다시 쓸 필요 없이, 새로 추가된 필드만 보충하면 새로운 기능을 바로 사용할 수 있는 이유입니다.

프로토콜 지원 차이: 오리지널 코어가 처리할 수 없는 프로토콜들

프로토콜 지원은 두 코어의 가장 직관적인 차이입니다. mihomo는 오리지널 프로토콜을 기반으로 이후 등장한 여러 전송 프로토콜을 새로 지원하며, 이들 프로토콜은 지연 시간과 검열 회피 능력에서 각각 다른 강점을 지닙니다.

구독 노드 목록에 Hysteria2나 TUIC 유형 노드가 있으면, 오리지널 코어에서는 파싱에 바로 실패하거나 건너뛰어져 "노드 목록에서 몇 개가 빠졌다" 혹은 클라이언트에서 설정 오류가 뜨는 식으로 나타납니다. 이런 문제의 근본 원인은 대부분 설정 파일이 잘못된 것이 아니라 코어 버전이 오래된 것이므로, mihomo 기반 클라이언트로 바꾸면 해결됩니다.

규칙 기능 차이: rule-providers와 더 세밀한 매칭

규칙 시스템은 mihomo가 오리지널 코어에 비해 가장 크게 개선한 부분 중 하나입니다. 오리지널 코어의 rules 필드는 고정 규칙을 하나씩 나열하는 방식만 지원해, 규칙이 많아질수록 설정 파일이 극도로 방대해지고 관리하기 어려워집니다. mihomo는 rule-providers 메커니즘을 도입해 규칙셋을 별도의 원격 파일로 분리할 수 있게 했으며, 메인 설정에서는 참조만 하면 됩니다.

rule-providers:
  reject:
    type: http
    behavior: domain
    url: "https://example.com/rules/reject.txt"
    path: ./rules/reject.txt
    interval: 86400

rules:
  - RULE-SET,reject,REJECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

규칙셋 파일은 interval에 지정된 주기에 따라 자동으로 갱신되며, 규칙 관리자가 분류 규칙을 업데이트하면 사용자 단말이 백그라운드에서 조용히 동기화하므로 설정 파일 전체를 수동으로 바꿀 필요가 없습니다. 이것이 바로 현재 주류인 "원클릭 구독" 설정 방식이 장기간 규칙 정확성을 유지할 수 있는 기술적 토대입니다.

이 외에도 mihomo는 오리지널에는 없던 규칙 유형을 새로 추가했습니다.

• PROCESS-NAME / PROCESS-PATH: 연결을 시작한 프로세스의 이름이나 경로로 분기해, "이 앱만 프록시를 타게 하고 나머지는 직결"하는 식의 세밀한 제어가 가능합니다.
• IP-CIDR6: IPv6 주소 대역 매칭으로, 오리지널의 IPv6 지원 공백을 보완합니다.
• SCRIPT(일부 구현): 간단한 스크립트 로직으로 분기 조건을 판단할 수 있어 복잡한 상황에 적합합니다.
• SUB-RULE: 하위 규칙셋을 중첩 참조할 수 있어, 방대한 규칙표를 재사용 가능한 모듈로 분리하기 좋습니다.

대부분의 가정용 사용자에게 프로세스 단위 규칙의 의미는 "어떤 프로그램이 프록시를 타는지"를 정확히 제어할 수 있다는 데 있으며, 규칙 단위가 도메인/IP 수준에 머물러 발생하는 오판 문제를 피할 수 있습니다.

DNS와 Fake-IP 기능 차이

DNS 처리는 체감 차이가 뚜렷한 또 다른 영역입니다. 오리지널 코어의 DNS 모듈은 기능이 비교적 기본적이며, 주로 "DNS 오염으로 잘못된 IP로 해석되는" 문제를 해결하는 데 초점이 맞춰져 있습니다. mihomo는 이를 기반으로 Fake-IP 메커니즘과 스니핑 기능을 보완했습니다.

• Fake-IP 모드: 도메인에 가상 IP 대역 내의 주소를 할당해, 앱이 연결을 시작할 때 먼저 가짜 IP를 받고, 실제 연결 단계에서 코어가 원래 도메인을 복원해 분기 여부를 판단합니다. 이는 전통적인 DNS 모드에서 "먼저 조회·해석하고, 그다음 분기를 판단"하는 왕복 지연을 줄여주며, 도메인 기반 분기 규칙에 특히 유리합니다.
• 스니핑(sniffer): IP-CIDR나 GEOIP 규칙을 설정했지만 대응하는 도메인 정보가 없는 연결에 대해, mihomo는 TLS SNI나 HTTP Host 필드에서 목적지 도메인을 스니핑해낸 뒤 도메인 기반 규칙을 적용할 수 있어, Fake-IP와 규칙이 서로 맞지 않는 일부 상황을 보완합니다.
• DNS 분기: 서로 다른 네트워크 환경(중국 본토/해외)에 맞춰 각각 다른 상위 DNS 서버를 설정하고, fallback-filter로 결과의 신뢰도를 판단할 수 있습니다. 오리지널 코어는 이 부분에서 설정 가능한 항목이 뚜렷하게 적습니다.

API 기능과 클라이언트 연동 차이

코어가 외부에 노출하는 HTTP API는 클라이언트가 어떤 실시간 상호작용 기능을 구현할 수 있는지를 결정합니다. 오리지널 코어의 API는 노드 목록, 연결 상태, 로그 전송 등 기본 기능을 다룹니다. mihomo는 이를 기반으로 조회·제어 가능한 인터페이스를 더 많이 확장했으며, 다음을 포함합니다.

• 프록시 그룹 단위로 지연 측정 결과를 조회하고, 여러 정책 그룹을 동시에 측정할 수 있습니다.
• 연결 단위의 상세 트래픽 통계로, 업로드/다운로드 바이트 수와 실시간 속도를 구분해 보여줍니다.
• 규칙 매칭 추적 기능으로, 특정 연결이 정확히 어떤 규칙에 매칭되어 어떤 프록시를 탔는지 확인할 수 있습니다.
• 설정 즉시 반영(hot reload) 인터페이스로, 구독을 전환하거나 규칙을 수정한 뒤 코어를 재시작하지 않고도 바로 적용됩니다.

이것이 바로 요즘 클라이언트들이 "연결 상세 화면에서 각 트래픽의 규칙 매칭 상황을 실시간으로 갱신"할 수 있는 이유이기도 합니다. 이런 화면 기능은 밑단 API가 해당 데이터를 제공하는지에 완전히 의존하며, 오리지널 코어의 API 범위로는 이런 화면을 지원하기에 부족합니다.

기존 설정 파일을 mihomo로 옮길 때 다시 작성해야 하는가

mihomo가 필드 수준에서 오리지널과 양호한 하위 호환성을 유지하고 있으므로, 대부분의 기존 설정 파일은 그대로 가져와 바로 실행할 수 있으며, 흔히 필요한 작업은 "재작성"이 아니라 "보충"입니다.

1. 바로 가져와서 테스트

   구독 링크나 로컬 설정 파일을 그대로 mihomo 기반 클라이언트에 추가해, 정상적으로 연결되고 분기되는지 먼저 확인합니다. 대부분의 기본 필드는 수정할 필요가 없습니다.

2. 프로토콜 파싱 오류 확인

   로그에서 특정 노드의 파싱 실패가 나타난다면, 대개 프로토콜 유형이 너무 새롭거나 오래되어 필드가 맞지 않는 경우입니다. 해당 노드는 일단 건너뛰고 나머지가 정상인지 점검하면 됩니다.

3. 신규 필드 보충

   필요에 따라 rule-providers, sniffer, tun 등 mihomo 고유 필드를 추가해, "일단 돌아가기만 하면 된다"는 최소 기준에 머무르지 말고 새 코어의 기능을 충분히 활용합니다.

4. 정책 그룹 속도 측정 로직 확인

   mihomo의 url-test와 fallback 정책 그룹은 타임아웃 판정과 헬스 체크 방식이 개선되었으므로, interval과 tolerance 파라미터가 여전히 원하는 값인지 확인하는 것이 좋습니다.

재작성이 아니라 그냥 옮기기가 불가능한 유일한 경우는, 설정 파일에서 오리지널이 지원한 적 없는, 서드파티 커스텀 포크가 만든 독자 필드를 쓴 경우입니다. 이런 경우는 흔치 않으며, 마주쳤을 때는 mihomo 공식 문서의 필드 설명을 기준으로 하나씩 대조하면 됩니다.

어떻게 선택할까: 코어 관점의 실질적인 조언

위 차이를 한 문장으로 정리하면, 오리지널 코어는 이미 아카이브되어 업데이트가 멈춘 시점의 기능 수준에 머물러 있고 새 프로토콜이나 새 규칙 기능이 추가될 일은 없습니다. mihomo는 현재 활발히 관리되며 프로토콜과 규칙 기능이 계속 확장되고 있는 코어이면서도 오리지널 설정과의 호환성을 유지하고 있습니다. 따라서 코어 선택의 관점에서 볼 때 "오리지널로 돌아가겠다"고 새 기능을 포기할 이유는 없으며, 처음부터 mihomo 기반 클라이언트를 선택하는 것이 더 마음 편한 길입니다.

구체적으로는 다음 몇 가지로 현재 사용 중인 클라이언트의 코어 상태를 빠르게 확인할 수 있습니다.

• 클라이언트의 "정보" 또는 "버전 정보" 화면을 확인하면 보통 코어 이름과 버전 번호가 표시되어 있으며, mihomo나 Meta라는 표기가 있으면 신규 코어입니다.
• Hysteria2나 TUIC 노드를 추가해 보고, 정상적으로 인식되고 지연 시간이 표시되면 신규 프로토콜을 지원하는 코어라는 뜻입니다.
• rule-providers나 규칙셋 자동 업데이트 설정 항목이 있는지 확인하면, 규칙 시스템이 mihomo 계열인지 직접적으로 판단할 수 있습니다.

대부분의 사용자에게 코어 차이는 수동으로 개입할 필요가 없으며, 클라이언트를 선택할 때 밑단이 지속적으로 업데이트되는 mihomo에 의존하는지 확인하기만 하면, 이후 프로토콜과 규칙의 발전은 클라이언트 업데이트와 함께 자동으로 반영되므로 코어 자체의 업그레이드 속도를 따로 신경 쓸 필요는 없습니다.