Clash·Clash Meta·mihomo 차이와 관계: 오픈소스 엔진 및 클라이언트 생태계 정리

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

Clash를 검색하면 엔진 저장소, 데스크톱 설치 파일, 모바일 앱, 구독 설정 안내가 한꺼번에 나옵니다. 이들은 모두 같은 종류가 아닙니다. 생태계를 이해하려면 이름에 Clash가 들어가는지보다 각 프로젝트가 어떤 역할을 맡는지 살펴보는 편이 좋습니다.

구분	역할	주요 항목
프록시 엔진	연결을 받고 DNS를 해석하며 규칙을 적용해 외부 연결을 생성	Clash、mihomo
그래픽 클라이언트	구독을 가져오고 정책을 선택하며 엔진과 시스템 연결을 관리	Clash Verge Rev、FlClash
설정 및 구독	노드, 정책 그룹, 규칙, 실행 옵션을 정의	YAML 설정, 원격 설정 주소, 프록시 모음

엔진은 네트워크 요청을 처리하는 실행 계층이고, 클라이언트는 버튼과 목록, 설정 화면을 제공합니다. 설정은 엔진이 연결을 처리하는 방식을 지정합니다. 클라이언트를 설치하면 보통 함께 제공되는 엔진도 설치되지만, 그렇다고 클라이언트 이름과 엔진 이름이 같다는 뜻은 아닙니다.

Clash·Clash Meta·mihomo의 계보

Clash: 원본 프로젝트이자 널리 쓰이는 통칭

좁은 의미의 Clash는 Dreamacro가 시작한 규칙 기반 프록시 엔진을 가리킵니다. YAML 설정으로 프록시 노드, 정책 그룹, DNS, 트래픽 분기 규칙을 구성하고, 그래픽 인터페이스는 제어 API를 통해 연결 정보를 확인하거나 정책을 전환할 수 있습니다. 일상적인 대화에서 “Clash”는 이런 유형의 클라이언트나 설정 형식까지 통칭하기도 합니다. 따라서 안내문에 “Clash 설치”라고 적혀 있어도 원본 엔진을 직접 실행하라는 뜻은 아닐 수 있습니다.

원본 오픈소스 Clash와 과거의 Clash Premium도 구분해야 합니다. Premium은 별도의 과거 배포 분기로, 기능 구성이 원본 오픈소스 엔진과 같지 않습니다. 오래된 안내에서 TUN, 스크립트, 규칙 공급자를 다룬다면 사용된 분기와 버전을 함께 확인해야 합니다. 특정 기능이 이름에 Clash가 들어가는 모든 프로그램에서 지원된다고 볼 수는 없습니다.

Clash Meta: Clash에서 파생된 엔진 프로젝트

Clash Meta는 Clash에서 발전한 커뮤니티 분기입니다. 기존 설정 구조를 상당 부분 유지하면서 프로토콜 지원, DNS, 라우팅, TUN 기능 등을 확장했습니다. 여기서 Meta는 엔진 프로젝트의 이름이지 별도로 구매해야 하는 클라이언트 버전이 아닙니다. 이름에 Meta가 들어간 모든 앱이 같은 팀에서 개발된다는 뜻도 아닙니다.

mihomo: Clash Meta가 이후 사용한 이름

Clash Meta는 이후 mihomo로 이름을 바꾸었고, 개발은 mihomo 프로젝트에서 이어지고 있습니다. 이전 문서와 설정 주석, 일부 클라이언트 화면에서는 여전히 “Meta 엔진”이라는 표현을 볼 수 있습니다. “Clash Meta 지원”과 “mihomo 사용”이라는 문구를 보았다면 먼저 실제 엔진 버전을 확인하세요. 대체로 같은 프로젝트 계보를 가리키며, 두 서비스를 모두 설치해야 한다는 뜻은 아닙니다.

프로젝트 계보: 원본 Clash → 커뮤니티 분기 Clash Meta → 이후 이름 mihomo.
클라이언트 관계: 서로 다른 인터페이스 프로젝트가 같은 엔진을 통합할 수 있으며, 설치 파일과 사용자 인터페이스는 각 프로젝트가 따로 관리합니다.
호환성 확인: 이름은 프로젝트를 파악하는 단서일 뿐입니다. 실제 지원 필드는 실행 중인 엔진 버전에 따라 달라집니다.

2023년 원본 프로젝트와 일부 클라이언트의 공개 유지보수에 변화가 생긴 뒤에도 새로운 커뮤니티 분기는 계속 발전했습니다. 이를 근거로 “모든 Clash 클라이언트의 업데이트가 중단됐다”고 볼 수는 없습니다. 새 클라이언트를 원본 프로젝트가 이름만 바꿔 이어받은 공식 후속작으로 간주해서도 안 됩니다. 유지보수 주체를 확인하려면 프로젝트 저장소와 릴리스 기록, 관리자의 안내를 살펴보세요.

Verge·Verge Rev·FlClash는 각각 어떤 역할일까요?

Clash Verge, Clash Verge Rev, FlClash는 모두 그래픽 클라이언트입니다. 인터페이스에서 설정을 가져오고 정책을 바꾸거나 로그를 확인할 수 있으며, 실제 프록시 처리는 클라이언트가 실행하는 엔진이 담당합니다.

프로젝트 또는 이름	생태계 내 역할	선택할 때 확인할 점
Clash Verge	과거 데스크톱 클라이언트 프로젝트	Rev의 릴리스 기록과 혼동하지 마세요
Clash Verge Rev	Verge의 방향을 이어가는 커뮤니티 데스크톱 클라이언트, mihomo 사용	시스템 요구 사항, 엔진 버전, 서비스 모드 안내
FlClash	Flutter 기반으로 개발된 멀티플랫폼 mihomo 클라이언트	대상 플랫폼 설치 파일과 플랫폼 권한
Clash for Windows	과거 데스크톱 클라이언트, 유지보수 중단	예전 안내와 현재 시스템 간 호환성 차이
Clash for Android	과거 Android 클라이언트, 원본 프로젝트 유지보수 중단	이후 등장한 커뮤니티 프로젝트와 혼동하지 마세요

클라이언트 이름에 플랫폼명이 들어가도 실제 배포 정보까지 알 수 있는 것은 아닙니다. 예를 들어 Clash for Windows의 과거 배포는 Windows에만 한정되지 않았고, 데스크톱 클라이언트가 Android 설치 파일을 제공한다는 보장도 없습니다. 다운로드할 때는 해당 릴리스에 명시된 운영체제와 아키텍처 목록을 기준으로 확인하세요.

같은 mihomo를 쓰는데 설정 화면이 다른 이유는 무엇일까요?

구독 저장 방식, 트레이 메뉴, 시작 프로그램 설정, 서비스 설치, 설정 덮어쓰기 기능은 클라이언트마다 다르게 구현됩니다. 엔진 버전이 같아도 두 클라이언트가 서로 다른 설정 폴더와 구독 업데이트 방식을 사용할 수 있습니다. 한 앱의 “설정” → “구독 업데이트” 경로를 다른 앱에 그대로 적용할 수는 없습니다. 같은 메뉴를 찾을 수 없다면 “설정”, “Profiles” 또는 해당 클라이언트 문서에서 안내하는 메뉴를 확인하세요.

설정 호환성 확인: 필드와 불러오기 방식을 살펴보세요

mihomo는 Clash 생태계에서 널리 쓰이는 YAML 구조를 이어받았지만, “가져올 수 있다”는 것이 “모든 필드가 적용된다”는 뜻은 아닙니다. 기본 프록시 그룹과 도메인 규칙은 비교적 쉽게 옮길 수 있지만, 새로운 프로토콜이나 DNS 확장, TUN 옵션은 버전 차이에 더 큰 영향을 받습니다. 오래된 엔진은 새 설정을 불러오지 못하거나 알 수 없는 항목을 무시할 수 있으므로 로그를 확인해야 합니다.

기본 필드로 설정 구조 파악하기

아래 예시는 일반적인 설정과 규칙만 보여 주며, 실제로 연결 가능한 노드는 포함하지 않습니다. 여기서는 로컬 혼합 프록시 포트를 7890으로 지정하고 로컬 기기에서만 사용할 수 있도록 제한했습니다. 이 값이 모든 클라이언트의 기본 포트인 것은 아닙니다.

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

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

mixed-port는 HTTP와 SOCKS를 함께 사용하는 프록시 포트를 제공합니다. mode: rule은 규칙에 따라 정책을 선택한다는 뜻입니다. 예시의 마지막 규칙은 직접 연결을 기본 처리로 사용하므로 프록시 연결이 자동으로 생기지는 않습니다. 실제 설정에서 Proxy라는 정책 그룹을 참조하려면 해당 그룹을 설정에 정의해야 하며, 이름과 대소문자도 일치해야 합니다.

전체 구독과 프록시 모음은 서로 다른 입력입니다

전체 설정 구독: proxies, proxy-groups, rules, DNS 설정이 함께 들어 있을 수 있으며, 보통 클라이언트의 설정 목록에 가져옵니다.
프록시 모음: 일반적으로 proxy-providers에서 불러와 기존 정책 그룹에 사용합니다. 그 자체만으로 완전한 실행 설정이 되는 것은 아닐 수 있습니다.
개별 노드 링크: 클라이언트가 링크 해석이나 변환을 지원해야 합니다. 임의의 공유 링크를 YAML 최상위에 그대로 붙여 넣을 수는 없습니다.

“같은 구독이 A에서는 작동하지만 B에서는 작동하지 않는” 경우, 먼저 B가 같은 입력 형식을 지원하는지 확인한 다음 엔진 버전을 비교하세요. 링크가 브라우저에서 다운로드된다고 해서 클라이언트가 바로 불러올 수 있는 완전한 설정이라고 단정해서는 안 됩니다.

시스템 프록시와 TUN: 트래픽 연결 방식이지, 또 다른 엔진이 아닙니다

시스템 프록시와 TUN은 “앱의 트래픽을 엔진으로 어떻게 전달할까?”를 해결하고, 규칙 모드는 “전달된 트래픽을 어떤 대상으로 처리할까?”를 결정합니다. 서로 다른 설정입니다. TUN을 켜도 규칙 모드를 사용할 수 있으며, 유효한 노드와 DNS, 라우팅 설정이 여전히 필요합니다.

시스템 프록시: 시스템 설정을 따르는 앱을 로컬 포트에 연결

Windows 11을 예로 들면 “설정” → “네트워크 및 인터넷” → “프록시”에서 프록시 상태를 확인할 수 있습니다. 클라이언트에서 실제로 사용하는 혼합 포트가 7890이라면 시스템 프록시도 해당 로컬 주소와 포트를 가리켜야 합니다. 이전 클라이언트의 7897이나 다른 값을 계속 사용해서는 안 됩니다. 이 숫자는 설정에 따라 달라질 수 있는 포트일 뿐이므로, 안내 화면의 캡처만 보고 현재 값을 추정하지 마세요.

모든 프로그램이 시스템 프록시를 따르는 것은 아닙니다. 브라우저는 연결되지만 특정 터미널 도구가 연결되지 않는다면, 엔진이 작동하지 않는다고 단정하기 전에 해당 도구의 프록시 옵션이나 환경 변수를 확인하세요.

TUN: 가상 네트워크 인터페이스와 라우팅으로 트래픽 연결

TUN은 시스템 프록시를 따르지 않는 트래픽도 더 폭넓게 연결할 수 있지만, 정상 작동 여부는 시스템 권한과 라우팅 설정, DNS 처리, 현재 네트워크 환경에 따라 달라집니다. 데스크톱 클라이언트는 서비스 설치나 권한 상승을 요구할 수 있습니다. Android는 보통 시스템 VPN 인터페이스를 사용하며 사용자가 권한을 승인해야 합니다. 플랫폼별 권한 설정 절차를 그대로 다른 플랫폼에 적용하지 마세요.

TUN으로 전환하기 전에 일반 프록시 연결과 노드가 정상인지 먼저 확인하세요. 두 가지 문제를 한꺼번에 해결하려 하지 않는 편이 좋습니다.
라우팅 충돌을 찾을 수 있도록 다른 VPN과 가상 네트워크 어댑터, 보안 소프트웨어의 상태를 기록해 두세요.
UDP 사용 가능 여부는 노드 프로토콜과 서버, 외부 연결 경로에도 달려 있습니다. TUN을 켠다고 자동으로 UDP가 지원되는 것은 아닙니다.

클라이언트 선택과 마이그레이션: 다음 다섯 단계 확인

플랫폼과 아키텍처를 확인합니다. 먼저 Windows, macOS, Linux, Android 중 어떤 플랫폼인지 확인한 다음 설치 파일에 표시된 x64, ARM64 등의 아키텍처를 살펴보세요. macOS에서는 Apple 메뉴 → “이 Mac에 관하여”에서 칩 정보를 확인할 수 있습니다.
프로젝트가 맞는지 확인합니다. 전체 프로젝트 이름과 저장소, 릴리스 기록을 비교하세요. 특히 Clash Verge와 Clash Verge Rev, 원본 모바일 프로젝트와 커뮤니티 분기를 구분해야 합니다.
클라이언트와 엔진 버전을 각각 기록합니다. “정보”, 엔진 관리 화면 또는 시작 로그에서 확인하세요. 화면 위치는 버전에 따라 달라질 수 있습니다. 클라이언트를 업데이트해도 엔진은 함께 업데이트되지 않을 수 있습니다.
설정을 가져온 다음 노드를 하나씩 테스트합니다. 설정이 정상적으로 불러와졌는지 확인하고, 로그에 알 수 없는 필드나 없는 정책 그룹, 포트 사용 중 안내가 있는지 살펴본 뒤 실제 웹사이트 접속을 테스트하세요.
마지막으로 자동화 설정을 옮깁니다. 기본 연결이 안정적으로 작동하는 것을 확인한 뒤 자동 업데이트와 시작 프로그램, 설정 덮어쓰기, TUN을 구성하세요. 한 번에 너무 많은 변수를 바꾸지 않는 것이 좋습니다.

엔진을 단독으로 실행하는 경우 터미널에서 아래 명령을 실행해 버전을 확인할 수 있습니다. 현재 디렉터리에 해당 실행 파일이 있어야 합니다. 그래픽 클라이언트를 사용한다면 버전 확인을 위해 엔진을 따로 설치할 필요는 없습니다.

# Linux / macOS: 엔진 파일이 있는 디렉터리에서 실행
./mihomo -v

# Windows PowerShell: 엔진 파일이 있는 디렉터리에서 실행
.\mihomo.exe -v

문제를 해결할 때는 “최신 버전”이라고만 적지 말고 실제 출력 내용을 기록하세요. 운영체제 버전과 설정 출처 유형, 연결 방식, 구체적인 오류도 함께 남겨야 합니다. 로그를 외부에 공유하기 전에 구독 주소의 토큰과 노드 비밀번호, 제어 API 키를 삭제하세요.

자주 묻는 질문: 이름이 비슷한 프로젝트 구분하기

mihomo를 설치하면 클라이언트도 필요한가요?

꼭 그렇지는 않습니다. 명령줄과 설정 파일에 익숙하다면 엔진을 직접 실행하고 시작 및 시스템 연결을 관리할 수 있습니다. 인터페이스에서 구독을 가져오거나 정책을 바꾸고 연결을 확인하고 싶다면 그래픽 클라이언트가 더 편리합니다. 두 가지는 서로 다른 사용 방식이지, 반드시 차례로 설치해야 하는 단계가 아닙니다.

엔진을 mihomo로 바꾸면 기존 설정을 반드시 사용할 수 있나요?

프로젝트 계보만으로 호환성을 보장할 수는 없습니다. 필드 호환성뿐 아니라 상대 경로와 규칙 파일 형식, 클라이언트의 설정 덮어쓰기, 권한도 확인해야 합니다. 마이그레이션한 뒤에는 실제 로드 로그와 규칙 적용 여부를 살펴보세요. 설정 목록에 이름이 표시되는 것만으로 성공했다고 판단하면 안 됩니다.

예전 이름인 “Meta”가 보이면 구독을 새로 받아야 하나요?

이름이 바뀌었다는 이유만으로 구독을 바꿀 필요는 없습니다. 현재 구독의 출력 형식이나 프로토콜, 필드가 사용하는 엔진과 호환되지 않을 때만 구독 출력이나 설정을 조정하면 됩니다. 불필요하게 변환을 시도하다 구독 인증 정보가 노출되지 않도록 먼저 구체적인 오류를 확인하세요.

클라이언트와 엔진을 혼동하지 않으려면 어떻게 해야 하나요?

클라이언트 전체 이름과 버전, 엔진 이름과 버전, 설정 유형, 로컬 프록시 포트, 시스템 프록시 또는 TUN 상태를 간단히 기록해 두세요. 프로그램을 바꾸거나 로그를 확인할 때 이 다섯 가지를 알면 “인터페이스 문제”, “설정 문제”, “네트워크 연결 문제”를 구분하기 쉽습니다.

더 읽을 때는 용어집에서 프록시 그룹이나 Fake-IP 같은 개념을 확인하거나, 설정 필드 안내에서 특정 옵션을 찾아보세요. 클라이언트는 플랫폼과 유지보수 상태를 기준으로 선택하고, 호환성 문제는 엔진과 실제 설정을 살펴보면 생태계의 여러 이름을 혼동하지 않는 데 도움이 됩니다.