Clash 오픈소스 생태계 총정리: mihomo 코어와 GUI 클라이언트의 역할

코어·클라이언트·설정의 3단 구조

Clash 생태계의 여러 이름은 같은 계층에 속하지 않습니다. mihomo는 네트워크 트래픽을 처리하는 코어이고, Clash Verge Rev와 FlClash는 조작 화면을 제공하는 클라이언트입니다. YAML은 노드, 정책 그룹, 규칙을 정의하는 설정 형식입니다. 소프트웨어를 고르기 전에 이 세 계층을 구분해야 특정 기능을 코어 문서에서 찾아야 할지, 클라이언트 설정에서 확인해야 할지 판단할 수 있습니다.

계층	주요 역할	대표 항목
코어	프로토콜 연결, DNS 처리, 규칙 매칭, 트래픽 전달	mihomo, 구형 Clash 코어
GUI 클라이언트	구독 가져오기, 정책 선택, 시스템 프록시, 서비스 관리, 로그 표시	Clash Verge Rev、FlClash
설정 및 구독	노드 매개변수, 정책 그룹, 규칙, 원격 리소스 정의	YAML 파일, 구독 URL, 규칙 세트

코어는 데스크톱 창 없이도 실행할 수 있습니다. 예를 들어 서버에서 YAML 파일을 읽고 로컬 프록시 포트를 열 수 있습니다. 클라이언트는 설정 가져오기, 프로세스 시작, 시스템 설정 변경 같은 작업을 버튼으로 제공하죠. 둘을 함께 설치하는 경우가 많아 화면에 표시된 버전 번호를 코어 버전으로 착각하기 쉽습니다.

원조 Clash, Clash Meta, mihomo의 변천사

2023년 11월, 원조 Clash와 여러 관련 프로젝트의 공개 저장소가 삭제되거나 보관 처리되는 등 변화가 생기면서 기존 상류 프로젝트의 유지 관리가 중단됐습니다. 과거 자료에서 말하는 오픈소스 Clash, Clash Premium, GUI 클라이언트도 각각 다른 배포 대상입니다. Clash Premium은 추가 기능을 제공했던 비공개 코어 분기였고, Clash for Windows는 클라이언트였습니다.

Clash Meta는 Clash를 바탕으로 발전한 오픈소스 분기로, 이후 mihomo로 이름이 바뀌었습니다. 따라서 오래된 가이드의 'Meta 코어'와 새 문서의 'mihomo 코어'는 프로젝트의 계보로 이어져 있으며, 서로 무관한 두 설정 체계를 뜻하지 않습니다. 일부 앱 이름, 저장소 이름, 구독 페이지에는 여전히 Meta라는 표기가 남아 있습니다. 이름이 바뀌지 않았다고 해서 실제로 어떤 버전의 코어를 쓰는지 단정할 수는 없습니다.

설정 호환성은 항목별로 확인하세요

기본 구조: proxies, proxy-groups, rules 등의 필드는 Clash 설정 구조를 이어받았지만, 모든 버전에서 모든 하위 필드를 지원한다는 뜻은 아닙니다.
신규 프로토콜: type: vless 또는 type: hysteria2 같은 항목을 사용하려면 실제 코어에 해당 기능이 구현되어 있어야 합니다. 클라이언트 이름에 Clash가 들어간다는 이유만으로 지원 여부를 판단하면 안 됩니다.
확장 기능: 트래픽 스니핑, DNS 정책, TUN 관련 필드는 버전에 따라 달라질 수 있으므로 현재 실행 중인 코어의 문서를 확인해야 합니다.
다른 생태계: sing-box JSON은 Clash YAML과 다른 형식입니다. 클라이언트 화면이 비슷해도 설정 파일을 서로 바꿔 쓸 수 있는 것은 아닙니다.

mihomo를 '계승자'라고 부르는 것은 커뮤니티의 사용 흐름과 기능 개발이 이어졌다는 뜻이지, 원조 프로젝트가 공식 업그레이드 패키지를 배포했다는 뜻은 아닙니다. 기존 클라이언트도 구독 주소만 바꾼다고 새 코어의 프로토콜을 지원하게 되지는 않습니다.

Verge Rev·FlClash·Android 클라이언트의 역할

아래 비교는 각 프로젝트의 목적을 중심으로 정리했으며, 수시로 바뀌는 배포 현황을 고정된 버전 번호 하나로 대신하지 않습니다. 설치 패키지 제공 여부와 패키지에 포함된 코어는 해당 프로젝트의 릴리스 노트를 확인하세요. 같은 프로젝트라도 배포 경로에 따라 업데이트 주기가 다를 수 있습니다.

프로젝트	주요 플랫폼	코어와의 관계	선택 시 확인할 항목
Clash Verge Rev	Windows、macOS、Linux	mihomo 기반 데스크톱 GUI 관리 기능 제공	서비스 모드, TUN 권한, 설정 병합, 코어 버전
FlClash	Android、Windows、macOS、Linux	mihomo 중심의 크로스 플랫폼 클라이언트	플랫폼별 배포 패키지, 백그라운드 실행, 설정 처리 방식
Clash Meta for Android	Android	Meta/mihomo 계열 기능을 Android 앱에 통합	앱 패키지 출처, 코어 버전, VPN 권한, 유지 관리 현황
Clash for Windows	과거 데스크톱 클라이언트	이름에 Windows가 들어가도 코어 이름을 뜻하지는 않습니다	과거 프로젝트이므로 현재 mihomo 기능 목록을 그대로 적용할 수 없습니다

데스크톱 클라이언트: 시스템 통합 기능이 핵심 차이

Verge Rev와 FlClash는 비슷한 버전의 mihomo를 사용하더라도 사용 경험이 다를 수 있습니다. 시작 프로그램 등록, 트레이 메뉴, 시스템 프록시 복구, 서비스 설치, 설정 덮어쓰기, 오류 안내는 주로 클라이언트 계층의 기능입니다. 노드 목록의 배치만 비교하지 말고 '프로그램을 종료한 뒤 프록시가 복구되는가', '구독을 업데이트해도 로컬 규칙이 남는가' 같은 동작을 확인하세요.

Android 클라이언트: VPN 연결과 백그라운드 제한

Clash Meta for Android 같은 앱은 보통 Android VPN 인터페이스를 통해 트래픽을 처리하며, 이때 사용자의 허용이 필요합니다. VPN 인터페이스는 시스템이 트래픽을 넘기는 방식일 뿐, 구독 서비스가 반드시 기존 VPN 프로토콜을 사용한다는 뜻은 아닙니다. Android에서는 일반 VPN 서비스를 한 번에 하나만 활성화할 수 있어 다른 VPN 방식의 방화벽이나 필터링 앱과 충돌할 수 있습니다.

Android의 배터리 절약 설정, 백그라운드 프로세스 관리, 앱별 분할 라우팅도 클라이언트 선택 시 고려해야 합니다. 데스크톱에서 문제없이 실행되는 YAML이라도 휴대전화에서는 수신 주소, 포트, 라우팅 관련 설정을 조정해야 할 수 있습니다. 여러 플랫폼을 지원한다고 해서 운영체제별 동작까지 완전히 같다는 뜻은 아닙니다.

트래픽 경로: 시스템 프록시·제어 인터페이스·TUN

앱 아이콘을 외우는 것보다 트래픽 경로를 이해하는 편이 문제를 찾는 데 도움이 됩니다. 일반적인 시스템 프록시 경로는 '앱이 시스템 프록시 설정을 따름 → 로컬 프록시 포트에서 수신 → 코어가 규칙을 매칭 → 노드 또는 직접 연결로 전달'입니다. 시스템 프록시 설정을 따르지 않는 프로그램은 이 경로를 거치지 않을 수 있습니다.

혼동하면 안 되는 세 가지 인터페이스

프록시 수신 포트: 브라우저나 명령줄 도구 등이 프록시 요청을 보내는 포트입니다. 예: 127.0.0.1:7890.
제어 인터페이스: 클라이언트나 대시보드가 상태를 조회하거나 정책을 전환할 때 사용합니다. 예: 127.0.0.1:9090. 브라우저가 인터넷에 연결할 때 사용하는 프록시 포트는 아닙니다.
TUN 가상 네트워크 인터페이스: 라우팅된 트래픽을 시스템 네트워크 계층에서 수신합니다. 실제 적용 범위는 라우팅, 제외 항목, DNS, 권한 설정에 따라 달라집니다.

아래 예시는 포트와 제어 인터페이스의 역할을 설명하기 위한 것으로, 노드가 포함된 완전한 설정이 아닙니다. 포트 값은 예시이며 모든 클라이언트의 기본값을 뜻하지 않습니다. GUI 클라이언트가 시작 시 해당 필드를 덮어쓸 수도 있습니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

mixed-port는 하나의 수신 포트에서 HTTP와 SOCKS 프록시 요청을 모두 받을 수 있게 합니다. mode: rule은 규칙에 따라 트래픽을 처리한다는 의미이지, 시스템의 모든 프로그램이 자동으로 프록시를 사용한다는 뜻은 아닙니다. 제어 인터페이스에는 관리 권한이 있으므로 신뢰할 수 있는 범위 안에서만 사용하세요. 원격 접근이 꼭 필요하다면 인증과 네트워크 접근 제한도 설정해야 합니다.

구독에서 실행 설정까지: 클라이언트가 처리하는 작업

구독 다운로드가 성공했다는 것은 클라이언트가 원격 데이터를 가져왔다는 뜻일 뿐입니다. 이후 형식 분석, 로컬 설정 병합 또는 덮어쓰기, 실행 설정 생성 과정을 거쳐 코어에 전달해야 합니다. 구독 원본 파일, 클라이언트 편집기에 표시된 파일, 코어가 실제로 사용하는 파일은 서로 다를 수 있습니다.

서로 다른 두 가지 원격 업데이트

전체 설정 구독: 원격 YAML에 노드, 정책 그룹, 규칙이 모두 들어 있을 수 있습니다. 업데이트 과정에서 로컬 변경 사항을 유지하는 방식은 클라이언트의 설정 관리 구조에 따라 다릅니다.
노드 제공자: proxy-providers가 참조하는 원격 리소스는 주로 노드를 제공합니다. 정책 그룹과 노드 사용 방법은 상위 설정에서 별도로 정의해야 합니다.
규칙 제공자: rule-providers는 규칙 세트를 제공하며 노드 구독을 대체하지 않습니다. 규칙 세트는 규칙 항목에서 참조해야 합니다.

예를 들어 프록시 그룹이 작업 출구라는 노드를 참조하는데 구독을 업데이트한 뒤 해당 이름이 사라지면, 설정을 불러오지 못하거나 노드 선택에 문제가 생길 수 있습니다. 이는 설정 간 참조 관계의 문제이지 클라이언트 창의 렌더링 오류가 아닙니다. 문제를 해결할 때는 앱을 반복해서 재설치하기보다 생성된 설정 파일과 커널 오류 로그를 확인하세요.

클라이언트를 옮길 때는 앱 내부 데이터베이스만 복사하지 말고 구독 주소, 로컬 규칙, 덮어쓰기 로직부터 보관하세요. 특히 스크립트 덮어쓰기는 클라이언트마다 제공하는 객체와 실행 방식이 다를 수 있습니다. 한 클라이언트에서 실행되는 스크립트라고 해서 mihomo 코어의 공통 기능인 것은 아닙니다. 필드별 세부 내용은 YAML 설정 핸드북을 참고하세요.

클라이언트 선택 및 이전 점검 절차

운영체제, 필요한 프로토콜, 트래픽 처리 방식부터 확인하면 클라이언트를 고르기 쉽습니다. 브라우저 프록시만 필요한 데스크톱 사용자는 먼저 시스템 프록시 경로를 확인하세요. 더 많은 앱의 트래픽을 처리해야 한다면 TUN과 서비스 권한을 추가로 점검하면 됩니다. Android 사용자는 VPN 권한, 백그라운드 실행, 앱별 분할 라우팅이 실제 사용 환경에 맞는지 먼저 확인하세요.

플랫폼과 아키텍처를 확인합니다. Windows, macOS, Linux, Android를 구분하고 x64, ARM64 등 설치 패키지 아키텍처를 확인하세요. Apple Silicon Mac과 Intel Mac은 파일명에 macOS가 들어간다는 이유만으로 같은 패키지를 선택하면 안 됩니다.
버전을 각각 기록합니다. 클라이언트의 정보 화면, 코어 설정, 시작 로그에서 클라이언트 버전과 mihomo 버전을 따로 확인하세요. 메뉴 위치는 클라이언트 버전에 따라 달라질 수 있으므로 실제 화면을 기준으로 확인해야 합니다.
가져온 뒤 로그를 확인합니다. 먼저 YAML이 정상적으로 파싱되는지, 노드와 정책 그룹이 있는지 확인한 다음 시스템 프록시나 TUN을 켜세요. 설정 오류를 네트워크 장애로 오해하는 일을 줄일 수 있습니다.
트래픽 처리 경로는 하나만 실행합니다. 이전 작업을 시작하기 전에 기존 클라이언트의 시스템 프록시, TUN, 백그라운드 서비스를 끄고 새 클라이언트를 실행하세요. 포트 점유와 라우팅 충돌을 줄일 수 있습니다.
실제 요청을 확인합니다. 연결 화면에서 프로세스, 대상 주소, 매칭된 규칙, 적용된 출구 정책을 살펴보세요. 노드 지연 시간 테스트에 성공해도 해당 테스트 요청만 정상이라는 뜻일 뿐, 모든 앱의 트래픽 경로가 제대로 작동한다고 볼 수는 없습니다.
업데이트 후 동작을 확인합니다. 구독을 직접 한 번 업데이트한 뒤 로컬 규칙이 남아 있는지, 정책 그룹 참조가 유효한지, 실행 설정에 예상한 수신 포트가 적용됐는지 확인하세요.

두 클라이언트가 같은 7890 수신 포트를 사용하면 나중에 시작한 쪽에서 주소 사용 중 오류가 날 수 있습니다. 기존 클라이언트를 종료한 뒤에도 시스템 프록시가 127.0.0.1:7890을 가리키면 브라우저가 연결되지 않을 수 있습니다. 두 문제 모두 원격 노드의 온라인 여부와 직접적인 관련은 없습니다.

자주 하는 오해: 이름이 비슷해도 기능은 다를 수 있습니다

mihomo를 설치하면 GUI 클라이언트가 필요 없나요?

꼭 그렇지는 않습니다. 명령줄, 서비스 관리, 설정 파일에 익숙하다면 코어를 단독으로 실행할 수 있습니다. 트레이 메뉴, 구독 관리, 시스템 설정 연동이 필요하다면 GUI 클라이언트를 사용하는 편이 일상적인 관리에 편리합니다. 같은 코어를 쓰는 경우 프로토콜 지원은 주로 코어 버전에 달려 있고, 시스템 연동 기능은 클라이언트 구현에 달려 있습니다.

구형 Clash YAML을 새 클라이언트에서 바로 사용할 수 있나요?

기본 설정은 이어서 쓸 수 있는 경우가 많지만, 먼저 로드해 확인해야 합니다. 파일에 지정된 프로토콜 유형, 외부 리소스 경로, 규칙 대상 이름과 클라이언트가 추가한 DNS 또는 TUN 설정을 점검하세요. 구형 파일이 파싱되더라도 현재 기기에 적합한 네트워크 정책이라는 보장은 없습니다.

GUI와 코어 중 무엇을 선택해야 하나요?

먼저 코어 기능을 기준으로 필요한 프로토콜과 규칙을 정하고, 클라이언트 기능을 기준으로 조작 방식을 고르세요. 플랫폼 지원, 설정 덮어쓰기, 백그라운드 서비스, 업데이트 방식을 비교하려면 클라이언트 비교 리뷰를 참고하세요. 처음 사용하는 경우에는 빠른 시작 가이드에 따라 설정을 가져오고 동작을 확인하면 됩니다. 코어, 화면, 설정을 세 계층으로 나눠 기록해 두면 이후 업데이트와 문제 해결이 한결 명확해집니다.