Clash 코어·mihomo·클라이언트 관계도: 오픈소스 생태계 한눈에 보기

먼저 구분할 세 가지: 코어, 클라이언트, 설정

Clash는 모든 설치 파일을 아우르는 단일 제품명이 아닙니다. 기존 Clash는 프록시 코어이고, mihomo는 Clash Meta에서 발전한 코어 프로젝트입니다. Clash Verge Rev와 FlClash 등은 코어를 기반으로 만든 GUI 클라이언트입니다. 기능 지원 여부를 판단할 때는 클라이언트 버전, 실제 실행 중인 코어, 최종적으로 불러온 설정을 함께 확인해야 합니다.

가장 쉽게 구분하는 방법은 각 구성 요소의 역할을 살펴보는 것입니다. 코어는 YAML을 해석하고 연결을 처리하며 DNS와 분기 규칙을 실행합니다. 클라이언트는 구독을 관리하고 정책 그룹을 표시하며 시스템 프록시를 전환하고, 코어 프로세스와 서비스를 시작합니다. 구독 제공자는 노드 정보나 완성된 설정을 제공합니다. 서로 연관되어 있지만 관리 주체는 각각 다릅니다.

계층	대표 항목	주요 역할
프록시 코어	Clash、mihomo	포트 수신, 설정 해석, 규칙 매칭, 상위 서버 연결
GUI 클라이언트	Clash Verge Rev、FlClash	설정 가져오기, 정책 선택, 시스템 연동, 로그 표시
설정 및 구독	YAML 파일, 구독 URL	노드·정책 그룹·규칙 및 업데이트 경로 제공

프로젝트의 발전: 기존 Clash, Clash Meta, mihomo

기존 코어의 유지보수 중단이 생태계 전체의 중단을 뜻하지는 않습니다

2023년 11월 무렵 기존 Clash 프로젝트의 공개 유지보수가 중단됐습니다. 그보다 앞서 생태계에는 오픈소스 원본과 기능이 완전히 같지 않은 비공개 분기인 Clash Premium도 있었습니다. 예전 안내에서 단순히 “Clash는 TUN을 지원한다”고만 쓴 경우 구체적인 분기와 플랫폼 조건이 빠져 있는 일이 많으므로, 임의의 구버전에 그대로 적용해서는 안 됩니다.

유지보수가 중단되면 이후 프로토콜 대응, 시스템 호환성 개선, 문제 수정이 원 프로젝트에서 계속 제공된다고 기대할 수 없습니다. 기존 프로그램이 실행될 수는 있지만, ‘실행 가능’과 ‘일상적인 네트워크 구성 요소로 계속 사용하기에 적합함’은 별개의 문제입니다. 전환할 때는 설치 파일 이름이 익숙한지만 볼 것이 아니라 현재 유지보수 상태를 확인해야 합니다.

Clash Meta는 mihomo의 이전 프로젝트명입니다

Clash Meta는 Clash 생태계의 분기 개발 프로젝트로 시작해 이후 mihomo로 이름이 바뀌었습니다. 예전 문서의 ‘Meta 코어’와 최근 문서의 ‘mihomo 코어’는 대개 같은 프로젝트의 발전 과정을 가리키며, 두 구성 요소를 함께 설치해야 한다는 뜻이 아닙니다. 프로젝트명 변경 직후 모든 구형 필드, 실행 파일 이름, 클라이언트 화면의 표기가 한꺼번에 바뀌는 것도 아닙니다.

mihomo는 Clash 스타일의 YAML 설정과 제어 인터페이스를 이어받으면서 프로토콜과 라우팅 기능을 확장했습니다. 다만 ‘계승’은 생태계의 유지보수와 기능 발전을 뜻할 뿐, 기존 개발팀에서 공식적으로 넘겨받았다는 의미가 아닙니다. 새 설정과 기존 설정이 100% 호환된다고 단정할 수도 없습니다.

프로젝트 발전 과정:
기존 Clash ── 분기 개발 ── Clash Meta ── 이름 변경 ── mihomo

통합 관계:
Clash Verge Rev ── 관리 및 호출 ── mihomo
FlClash         ── 통합 및 호출 ── mihomo

데이터 입력:
구독 또는 로컬 YAML ── 클라이언트 처리 ── 런타임 설정 ── 코어 로드

이 그림은 프로젝트와 구성 요소의 관계를 보여줄 뿐, 클라이언트들이 같은 화면 코드를 공유한다는 뜻은 아닙니다. 비슷한 코어를 사용하더라도 두 클라이언트의 설정 병합 과정, 서비스 관리 방식, 플랫폼 대응 로직은 서로 다를 수 있습니다.

클라이언트의 역할: Verge Rev와 FlClash의 범위

Clash Verge Rev: 데스크톱 UI와 시스템 연동

Clash Verge Rev는 Windows, macOS, Linux용 데스크톱 클라이언트로, mihomo 코어를 사용합니다. 구독 목록, 트레이 메뉴, 정책 그룹 선택, 연결 기록 등은 클라이언트 UI에서 담당합니다. 실제 연결에 사용할 프록시와 규칙의 일치 여부는 실행 중인 코어가 처리합니다.

클라이언트의 ‘서비스 모드’는 보통 백그라운드 구성 요소에 필요한 권한을 부여해 코어나 네트워크 기능을 관리하는 데 쓰입니다. 프록시 프로토콜의 한 종류가 아니며, 켠다고 모든 트래픽이 자동으로 프록시를 통과하는 것도 아닙니다. 트래픽이 실제로 전달되는지는 시스템 프록시, TUN, 라우팅, 각 앱의 연결 방식에 따라 달라집니다.

FlClash: 크로스 플랫폼 UI와 모바일 연동

FlClash는 Flutter로 개발하고 mihomo 코어를 사용하는 클라이언트 프로젝트로, 데스크톱과 Android 등의 플랫폼을 지원합니다. Android에서는 시스템 VPN 인터페이스를 통해 트래픽을 처리하므로 시스템 프록시를 변경하는 데스크톱의 방식과 다릅니다. 화면의 시작 버튼은 비슷해 보여도 필요한 시스템 권한은 서로 다릅니다.

FlClash, FlClashs처럼 이름이 비슷한 프로젝트가 있다면 이름만으로 같은 프로젝트라고 판단하지 말고 프로젝트 출처, 관리 주체, 릴리스 기록을 각각 확인하세요. 지원 플랫폼도 해당 프로젝트의 배포 목록을 기준으로 살펴봐야 합니다. 이름이 비슷한 다른 분기의 기능 설명을 그대로 적용해서는 안 됩니다.

예전 클라이언트 이름만으로 코어를 판단할 수 없습니다

Clash for Windows: 유지보수가 중단됐습니다. 과거 설치 파일에는 서로 다른 코어가 포함됐을 수 있으므로 현재 mihomo 클라이언트와 동일시해서는 안 됩니다.
Clash for Android: 원 프로젝트의 유지보수가 중단됐습니다. Android VPN 권한은 트래픽을 연결하기 위한 조건일 뿐, 구형 코어에 없는 프로토콜 기능을 보완하지는 않습니다.
기타 데스크톱 래퍼: 먼저 프로젝트 문서에서 코어 종류를 확인한 뒤, 현재 설치 파일에 실제로 포함된 코어 버전을 살펴보세요. 이름에 Clash가 들어 있는지만 확인해서는 안 됩니다.

클라이언트를 고를 때는 먼저 클라이언트 비교를 확인한 다음, 운영체제에 맞는 다운로드 페이지로 이동하세요. ‘현재 플랫폼에서 실행 가능’, ‘코어가 설정을 지원함’, ‘시스템 연동 방식이 적합함’이라는 세 가지 조건을 모두 충족해야 합니다.

구독의 YAML이 코어에 전달되는 과정

구독 URL은 설정을 가져오는 경로이지 프록시 프로토콜이 아닙니다. URL에서 내려받는 내용은 완성된 YAML일 수도 있고 노드 목록이나 다른 형식일 수도 있습니다. 클라이언트에서 바로 가져올 수 있는지는 입력 형식 지원 여부에 달렸고, 코어가 불러올 수 있는지는 생성된 설정이 해당 코어의 필드와 프로토콜 요구 사항에 맞는지에 달렸습니다.

콘텐츠 가져오기: 클라이언트에서 구독을 다운로드하거나 로컬 YAML 파일을 읽습니다.
설정 처리: 클라이언트가 덮어쓰기, 병합, 스크립트, 전역 설정을 적용해 실제 실행 파일을 만들 수 있습니다.
코어 로드: 코어가 최종 설정을 읽고 수신기를 열어 프록시, DNS, 규칙을 초기화합니다.
트래픽 연결: 앱이 프록시 포트에 연결하거나 TUN 같은 진입점을 통해 트래픽을 코어로 보냅니다.
분기 규칙 실행: 규칙 모드에서는 코어가 규칙을 순서대로 확인하고 대상 정책에 따라 연결을 처리합니다.

아래는 필드의 담당 범위를 설명하기 위한 최소 설정 예시이며, 원격 프록시 노드는 포함되어 있지 않습니다. 모든 일반 트래픽은 최종적으로 직접 연결되므로 원격 프록시가 작동한다는 증거로 사용할 수 없습니다. 포트 7890과 9090은 예시일 뿐, 모든 클라이언트의 기본값은 아닙니다.

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

external-controller: 127.0.0.1:9090
secret: "local-doc-demo-rotate-before-use"

proxy-groups:
  - name: Route
    type: select
    proxies:
      - DIRECT
      - REJECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,Route

mixed-port는 HTTP와 SOCKS를 함께 사용하는 프록시 진입점입니다. 앱 트래픽이 이 포트를 통해 코어에 들어올 수 있습니다.
external-controller는 상태 조회와 선택 변경에 사용하는 제어 API의 수신 주소입니다. 브라우저에 설정하는 프록시 포트가 아닙니다.
proxy-groups는 정책 그룹을 정의합니다. 클라이언트는 선택 항목을 표시하고 코어는 현재 선택을 저장해 실행합니다.
rules는 규칙의 매칭 순서를 정의합니다. 마지막의 MATCH는 앞선 규칙에 일치하지 않은 연결을 처리합니다.

구독 원본의 포트가 7890인데 클라이언트가 다른 포트에서 수신한다면 먼저 클라이언트의 전역 설정이나 덮어쓰기를 확인하세요. 다음 업데이트 때 덮어써질 구독 파일을 계속 수정하기보다는 런타임 설정을 확인해야 합니다. 필드 설명은 YAML 매뉴얼에서 확인할 수 있습니다.

시스템 프록시, TUN, 프로토콜 지원은 각각 누가 결정할까요?

시스템 프록시는 앱의 진입점이지 코어 기능을 업그레이드하는 방법이 아닙니다

시스템 프록시를 켜면 시스템 프록시 설정을 따르는 앱만 지정된 포트로 요청을 보냅니다. 직접 연결을 만드는 프로그램, 시스템 프록시 설정을 읽지 않는 명령줄 도구, 일부 게임 트래픽은 처리 대상에서 빠질 수 있습니다. 이때 GUI 테마를 바꾸거나 같은 구독을 다시 가져와도 앱의 네트워크 연결 방식은 대개 달라지지 않습니다.

TUN은 코어 기능뿐 아니라 클라이언트와 시스템 권한에도 좌우됩니다

TUN은 가상 네트워크 인터페이스를 통해 IP 트래픽을 연결합니다. 코어가 해당 기능을 지원해야 하며, 클라이언트도 인터페이스를 올바르게 만들고 권한과 라우팅을 관리하며 DNS를 조정해야 합니다. Windows 서비스 권한, Linux 네트워크 관리 권한, Android VPN 권한은 모두 이 과정에 필요한 플랫폼별 조건입니다.

TUN을 켠다고 ‘모든 연결이 원격 노드를 통과하는 것’은 아닙니다. 트래픽이 코어에 들어온 뒤에도 규칙에 따라 DIRECT가 선택될 수 있고, 라우팅 제외나 앱별 분기 설정의 영향을 받을 수도 있습니다. TUN 스위치가 켜졌는지만 볼 것이 아니라 트래픽 처리 범위와 규칙 적용 결과를 함께 확인해야 합니다.

새 프로토콜은 주로 코어를 확인하고, 설정 입력 방법은 클라이언트를 확인하세요

특정 노드 유형을 사용할 수 있는지는 먼저 코어의 지원 여부와 노드 매개변수가 올바른지에 달려 있습니다. 구형 코어에서 새 프로토콜을 사용하면 지원하지 않는 프록시 유형이라는 오류가 나거나 설정 로드에 실패할 수 있습니다. GUI 클라이언트를 업그레이드할 때 코어도 함께 업데이트되는 경우가 있지만, 클라이언트 버전과 코어 버전은 서로 다른 번호 체계입니다.

반대로 코어가 특정 필드를 지원하더라도 클라이언트 편집기에 해당 설정 버튼이 있다는 보장은 없습니다. 일부 기능은 YAML에 직접 입력하거나 덮어쓰기 설정으로 추가해야 합니다. 화면에서 저장할 때 설정을 다시 작성하는 클라이언트라면 사용자 정의 필드가 삭제되지 않는지도 확인하세요.

선택과 문제 해결: 구성 요소별로 차례로 확인하기

‘같은 구독이 다른 클라이언트에서는 작동한다’고 해서 곧바로 노드 품질 문제라고 단정하지 마세요. 두 클라이언트의 코어, 덮어쓰기 설정, DNS 설정이 다를 수 있고, 트래픽 진입 방식 자체가 다를 수도 있습니다. 아래 순서대로 비교하면 차이를 찾기 쉽습니다.

두 가지 버전 기록: 클라이언트 버전과 코어 버전을 각각 기록하세요. ‘정보’, 코어 관리 화면, 시작 로그에서 확인할 수 있으며 메뉴 이름은 배포 버전에 따라 다를 수 있습니다.
로드 결과 확인: 먼저 설정 구문 오류, 알 수 없는 프록시 유형, 존재하지 않는 정책 이름이 있는지 확인하세요. 설정 로드가 성공하지 않았다면 외부 IP를 테스트해도 진단에 도움이 되지 않습니다.
진입 방식 확인: 시스템 프록시와 TUN 중 무엇을 사용하는지 확인하세요. 명시적 프록시로 테스트한다면 안내 문서의 포트를 그대로 복사하지 말고 실제 수신 포트에 맞춰야 합니다.
정책 확인: 연결 로그에서 일치한 규칙, 정책 그룹, 최종 노드를 살펴보세요. 규칙이 직접 연결을 가리킨다면 외부 IP가 로컬 주소로 유지되는 것이 정상입니다.
마지막으로 DNS와 네트워크 비교: 설정이 같아도 DNS 결과, IPv6 라우팅, 상위 네트워크가 다르면 접속 결과가 달라질 수 있습니다.

실제 혼합 포트가 7890이라면 터미널에서 프록시를 명시해 앱이 시스템 프록시를 따르는지 여부를 제외하고 테스트할 수 있습니다. Windows에서 curl이 다른 명령으로 해석된다면 curl.exe를 사용하세요.

curl --proxy http://127.0.0.1:7890 --head --max-time 15 https://example.com

이 명령은 지정한 HTTP 프록시 진입점을 통해 요청 한 번을 보낸 결과만 확인합니다. TUN이 다른 앱의 트래픽까지 처리하는지 보여주지는 않으며, 원격 노드를 사용했다는 사실도 단독으로 증명하지 못합니다. 코어의 연결 기록도 함께 확인하세요. DIRECT에 매칭됐다면 요청은 로컬 네트워크를 통해 대상에 직접 연결됩니다.

기존 설정 이전하기: 필요한 필드를 유지하고 기능을 하나씩 복구

유지보수가 중단된 클라이언트에서 mihomo 클라이언트로 옮길 때는 먼저 기존 설정과 사용자 정의 규칙을 백업한 다음, 유효한 구독으로 최소한의 연결을 구성하는 것이 좋습니다. 새 클라이언트의 실행 디렉터리 전체를 덮어쓰거나 예전 서비스 파일과 새 코어 실행 파일을 섞어 사용하지 마세요.

먼저 프로토콜 확인: 구독 결과가 현재 코어용인지, 노드 이름과 정책 그룹 참조가 서로 일치하는지 확인하세요.
그다음 규칙 이전: 명확한 규칙 몇 개부터 복구하고 매칭 결과를 확인한 뒤, 규칙 세트와 복잡한 분기 설정을 추가하세요.
마지막으로 DNS와 TUN 이전: 이 두 기능은 운영체제와 로컬 네트워크 환경의 영향을 많이 받으므로 예전 설정을 무작정 그대로 가져오지 마세요.
이중 적용 방지: 새 클라이언트를 테스트할 때는 예전 클라이언트를 종료하고, 기존 서비스가 프록시 포트를 계속 점유하거나 가상 인터페이스를 유지하지 않는지 확인하세요.

생태계에서 중요한 것은 이름이 완전히 같은 대체품을 찾는 일이 아니라 각 구성 요소의 역할을 구분하는 것입니다. 코어 기능으로 프로토콜과 설정 호환성을 판단하고, 클라이언트 기능으로 플랫폼 연동 경험을 살피며, 런타임 설정과 로그로 실제 동작을 확인하세요. 세 계층을 구분하면 프로젝트명 변경, 클라이언트 분기, 설정 이전도 같은 점검 절차로 다룰 수 있습니다.