Clash·mihomo·Verge의 관계는? 오픈소스 생태계 프로젝트 한눈에 보기

먼저 세 계층을 구분하세요: 코어, GUI 클라이언트, 설정

Clash 생태계를 이해하는 가장 좋은 방법은 비슷한 이름을 외우는 것이 아니라 소프트웨어를 먼저 세 계층으로 나누어 보는 것입니다. 가장 아래에는 프록시 코어가 있어 YAML 설정을 읽고, 프록시 연결을 만들며, 규칙을 매칭하고, DNS 조회를 수행하고, 시스템 트래픽을 가로챕니다. 중간 계층인 GUI 클라이언트는 구독 관리, 트레이 메뉴, 시스템 프록시 전환, 로그 표시와 업데이트를 담당합니다. 가장 위에는 노드, 프록시 그룹, 규칙, DNS 매개변수가 들어 있는 설정과 구독이 있습니다.

오리지널 Clash와 mihomo는 코어 계층에 속합니다. Clash Verge, Clash Verge Rev, ClashX, FlClash 같은 이름은 일반적으로 GUI 클라이언트를 가리킵니다. 구독 링크는 설정의 출처일 뿐 코어도, 특정 클라이언트의 고정 구성 요소도 아닙니다. 같은 기본 설정을 여러 클라이언트에서 불러올 수 있지만, 정상적으로 모두 실행되는지는 사용된 필드를 하위 코어가 지원하는지에 달려 있습니다.

프록시 코어: 설정을 해석하고 트래픽을 전달합니다. 대표적인 이름으로 오리지널 Clash, Clash.Meta, 이후의 mihomo가 있습니다.
GUI 클라이언트: 코어에 창, 트레이, 구독 관리, 시스템 프록시와 TUN 전환 기능을 제공합니다. 클라이언트 자체가 프록시 프로토콜 구현을 의미하는 것은 아닙니다.
구독 및 설정: YAML 또는 구독 응답 형식으로 노드, 프록시 그룹, 규칙, DNS와 트래픽 가로채기 매개변수를 제공합니다.

오리지널 Clash에서 mihomo로 이어진 프로젝트 흐름

오리지널 Clash: 설정 문법과 규칙 모델의 출발점

Dreamacro가 개발한 오리지널 Clash는 오늘날에도 널리 사용되는 설정 구조를 마련했습니다. proxies로 노드를 정의하고, proxy-groups로 선택 및 자동 테스트를 구성한 다음, rules를 순서대로 적용해 트래픽의 경로를 결정합니다. 흔히 사용하는 DOMAIN-SUFFIX, IP-CIDR, GEOIP와 마지막의 기본 처리 규칙도 모두 이 모델에서 비롯되었습니다.

오픈소스 오리지널 Clash에서 흔히 언급되는 최종 버전은 v1.18.0입니다. 별도로 공개된 Clash Premium 빌드의 공개 버전으로는 2023.08.17이 있습니다. 원 프로젝트는 2023년 지속적인 유지보수를 중단했지만, 설정 호환성을 이해하는 데에는 여전히 중요합니다. 다만 새 프로토콜, 새로운 규칙 기능과 최신 플랫폼 수정 사항을 확인하는 유일한 기준으로 삼기에는 적합하지 않습니다.

Clash.Meta: 호환성을 바탕으로 한 기능 확장

Clash.Meta는 처음에는 Clash 설정 체계와 호환되는 확장 코어로 이해할 수 있습니다. 기존의 프록시 그룹과 규칙 문법을 유지하면서 TUN, DNS, 규칙 집합과 프로토콜 지원을 계속 확장했습니다. 여러 설정에서 사용하는 rule-providers, fake-ip-filter, 프로세스 매칭과 세부 네트워크 스택 옵션은 Meta 계열 코어에서 더욱 적극적으로 유지보수되었습니다.

여기서 ‘호환’된다고 해서 모든 방향으로 서로 바꿔 쓸 수 있다는 뜻은 아닙니다. 기본 Clash 설정은 대체로 mihomo에서 읽을 수 있지만, mihomo 확장 필드를 사용하는 설정을 구버전 오리지널 Clash에서 열면 ‘필드를 인식할 수 없음’, ‘프록시 유형을 지원하지 않음’ 또는 설정 로드 실패가 발생할 수 있습니다. 마이그레이션할 때는 구문 호환성이 구형에서 신형 코어로 갈 때 더 원활하다고 이해해야 하며, 양방향으로 완전히 동일하다고 보면 안 됩니다.

mihomo: Clash.Meta의 후속 명칭

Clash.Meta는 이후 mihomo로 이름을 바꾸었으며 MetaCubeX 커뮤니티가 계속 유지보수하고 있습니다. 이름이 바뀌었다고 해서 완전히 다른 설정 체계가 된 것은 아닙니다. 여러 클라이언트, 설정 변환 도구와 로그 화면에는 여전히 Meta, Clash Meta 또는 Meta Core 같은 이전 명칭이 남아 있습니다. 이런 용어를 볼 때는 서로 무관한 세 코어로 나누기보다 구체적인 버전 번호와 함께 판단해야 합니다.

따라서 현재 흔히 볼 수 있는 흐름은 다음과 같습니다. 오리지널 Clash가 기본 설정 모델을 제공하고, Clash.Meta가 호환성을 바탕으로 기능을 확장했으며, mihomo가 Clash.Meta의 개발을 이어 갑니다. 클라이언트에 ‘mihomo 코어’라고 표시되어 있다면 현재도 업데이트되는 이 계열을 대상으로 한다는 의미인 경우가 많습니다.

Verge·ClashX·Clash for Windows는 각각 무엇인가요?

프로젝트	계층	대표 플랫폼	핵심 관계	선택 시 확인할 점
Clash	코어	명령줄 및 멀티플랫폼 빌드	오리지널 프로젝트	지속적인 유지보수가 중단되어 기본 호환성을 이해하는 용도로 주로 사용
Clash.Meta / mihomo	코어	Windows, macOS, Linux, 모바일	Meta가 이후 mihomo로 이름 변경	버전 업데이트, 설정 확장, TUN 및 DNS 기능
Clash Verge	데스크톱 GUI 클라이언트	Windows、macOS、Linux	코어를 통해 프록시 기능 실행	원 프로젝트의 유지보수 상태와 후속 브랜치를 따로 확인해야 함
Clash Verge Rev	데스크톱 GUI 클라이언트	Windows、macOS、Linux	대개 mihomo와 함께 사용	코어 버전, 서비스 모드, TUN 권한과 시스템 호환성
ClashX	macOS GUI 클라이언트	macOS	Clash 계열 코어를 패키징	시스템 버전, 코어의 출시 시기와 설정 필드 호환성
Clash for Windows	데스크톱 GUI 클라이언트	Windows、macOS、Linux	과거 Clash 계열 코어를 통합	마지막으로 널리 알려진 버전은 0.20.39이며 프로젝트는 업데이트가 중단됨

Clash Verge와 Clash Verge Rev

Clash Verge는 데스크톱 웹 기술로 구축된 크로스 플랫폼 GUI 클라이언트로, 구독, 프록시 그룹 선택, 시스템 프록시와 설정 편집을 담당합니다. 오리지널 Clash Verge 프로젝트의 활동이 줄어든 뒤에는 Clash Verge Rev가 후속 유지보수 브랜치로 비슷한 사용 방식을 이어 왔습니다. 두 이름은 비슷하지만 릴리스 저장소, 버전 체계와 유지보수 상태는 다르므로 다운로드할 때 앱 아이콘만 보고 판단해서는 안 됩니다.

Clash Verge Rev에서는 보통 ‘설정’ → ‘Clash 설정’에서 포트, 외부 컨트롤러와 코어 관련 매개변수를 확인할 수 있고, ‘설정’ → ‘시스템 설정’에서 시작 시 실행이나 서비스 모드를 관리할 수 있습니다. 버전에 따라 번역은 조금 다를 수 있지만, 실제 기능을 판단할 때는 패키지 이름보다 ‘설정’ 화면에 표시된 코어 버전이 더 정확합니다. TUN을 활성화하려면 Windows에서는 대개 서비스 모드를 설치하고 시작해야 하며, macOS에서는 시스템 권한 승인을 완료해야 합니다.

ClashX: macOS용 메뉴 막대 클라이언트

ClashX의 핵심은 macOS 메뉴 막대 사용 경험입니다. 설정 전환, 프록시 그룹 선택, 시스템 프록시와 로그 메뉴를 상태 표시줄에 배치해 시스템 프록시를 주된 트래픽 가로채기 방식으로 사용하는 환경에 적합합니다. ClashX, ClashX Pro와 커뮤니티 후속 버전은 이름만으로 기능을 판단할 수 없으므로 코어 유형, 마지막 업데이트 시점과 현재 macOS 지원 여부를 각각 확인해야 합니다.

구버전 ClashX는 여러 클래식 Clash 설정을 읽을 수 있지만, mihomo에서만 지원하는 프로토콜, 규칙 집합 동작이나 DNS 필드를 만나면 설정을 완전히 불러오지 못할 수 있습니다. 구독 안내에서 Meta 또는 mihomo 코어를 명시적으로 요구한다면, 필드를 반복해서 삭제해 구형 클라이언트를 억지로 실행하기보다 해당 코어를 명확히 통합한 클라이언트를 선택해야 합니다.

Clash for Windows: 역사적 영향은 크지만 업데이트는 중단됨

Clash for Windows는 흔히 CFW로 줄여 부르며, 많은 사용자가 처음 접한 데스크톱 클라이언트입니다. Profiles, Proxies, Connections, Logs, Settings 등의 화면을 제공했고, ‘구독을 가져온 뒤 프록시 그룹을 바로 전환하는’ 데스크톱 사용 방식을 널리 알렸습니다. 마지막으로 널리 알려진 릴리스 버전은 0.20.39이며 프로젝트는 2023년에 업데이트를 중단했습니다.

한 가지 더 짚어야 할 점이 있습니다. Clash for Windows는 완전한 오픈소스 GUI 클라이언트가 아니므로 이름에 Clash가 들어 있다고 해서 오리지널 오픈소스 코어와 같은 프로젝트로 보면 안 됩니다. 지금도 구형 설치 패키지를 사용하면 최신 시스템 대응, 코어 기능과 버그 수정이 멈춰 있다는 제약이 있습니다. 새로 설치하는 환경이라면 유지보수 기록이 남아 있고 사용하는 코어를 명확히 설명하는 클라이언트를 선택하는 편이 좋습니다.

같은 구독이 클라이언트마다 다르게 작동하는 이유

구독을 가져올 수 있는지는 첫 단계일 뿐입니다. 클라이언트가 구독 내용을 받은 뒤에는 코어가 이를 해석해야 합니다. 두 화면 모두 ‘Clash 설정’으로 표시되더라도 하위 코어 버전, 오버라이드 로직, DNS 구현과 트래픽 가로채기 방식이 다르면 최종 결과도 달라질 수 있습니다. 차이는 주로 다음 네 가지에서 발생합니다.

설정 필드와 프록시 프로토콜 지원

mixed-port, proxies, proxy-groups, rules 같은 기본 필드는 호환 범위가 비교적 넓습니다.
새 프로토콜 매개변수, 규칙 모음 동작과 고급 DNS 옵션은 대개 최신 mihomo 코어를 요구합니다.
클라이언트는 구독 원문에 로컬 오버라이드를 추가할 수 있습니다. 예를 들어 포트를 바꾸거나, LAN 접근을 허용하거나, TUN 설정을 삽입할 수 있습니다.
같은 이름의 프록시 그룹은 구독에서 생성될 수도 있고 클라이언트 스크립트가 수정할 수도 있습니다. 문제를 확인할 때는 원격 원문과 최종 실행 설정을 구분해야 합니다.

시스템 프록시와 TUN의 가로채기 범위 차이

시스템 프록시는 일반적으로 HTTP와 SOCKS 프록시 주소를 운영체제 설정에 기록합니다. 흔히 사용하는 로컬 혼합 포트는 127.0.0.1:7890이며, 애플리케이션이 시스템 프록시를 읽거나 해당 포트를 직접 지정해야 트래픽이 코어로 들어갑니다. 게임, 일부 명령줄 프로그램과 자체 네트워크 스택을 사용하는 앱은 시스템 프록시를 우회할 수 있습니다.

TUN 모드는 가상 네트워크 장치를 통해 더 많은 IP 트래픽을 가로챕니다. 따라서 시스템 권한, 라우팅 테이블, DNS 하이재킹과 네트워크 스택 설정에 더 크게 의존합니다. 두 클라이언트가 같은 mihomo 버전을 사용하더라도 한쪽만 서비스 구성 요소 설치에 성공하고 다른 쪽이 권한을 얻지 못했다면 TUN 동작은 달라집니다. 문제를 판단할 때는 먼저 로그에 TUN 장치 생성 성공이 기록되었는지 확인한 다음 규칙 매칭을 점검하세요. 권한 실패를 노드 장애로 오해해서는 안 됩니다.

mixed-port: 7890
external-controller: 127.0.0.1:9090
secret: "change-this-controller-secret"

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

위에서 7890은 프록시 진입 포트이고 9090은 외부 제어 인터페이스라 용도가 다릅니다. 외부 제어 인터페이스는 클라이언트 화면에서 연결을 조회하고 프록시 그룹을 전환하는 데 사용되며, 브라우저가 HTTP 프록시 포트로 사용해서는 안 됩니다. 클라이언트가 제어 키를 자동으로 생성했다면 생성된 값을 유지해 화면과 코어의 연결이 끊기지 않도록 하세요.

DNS 정책이 규칙 매칭 결과를 바꾸는 이유

Clash 계열 코어는 도메인, IP 주소와 규칙 순서에 따라 트래픽 경로를 결정할 수 있습니다. fake-ip 모드에서는 코어가 먼저 앱에 예약 주소를 반환한 뒤 도메인 매핑을 유지해 후속 규칙 매칭을 수행합니다. 클라이언트가 enhanced-mode, nameserver 또는 fake-ip-filter를 변경하면 같은 규칙도 다른 결과를 낼 수 있습니다.

문제를 확인할 때는 클라이언트의 ‘로그’ 화면에서 레벨을 info로 설정하고, 한국 국내 도메인 하나, 프록시가 필요한 도메인 하나, 순수 IP 주소 하나에 각각 접속해 보세요. 최소 30초 동안 연속으로 관찰하면서 세 종류의 요청이 예상한 프록시 그룹과 정책에 매칭되는지 확인합니다. 도메인 규칙은 정상인데 순수 IP 트래픽만 우회한다면 TUN 또는 시스템 프록시의 가로채기 범위를 먼저 확인하세요. 모두 기본 처리 규칙으로 들어간다면 규칙 순서와 DNS 매핑을 점검해야 합니다.

현재 사용해도 괜찮은 프로젝트인지 판단하는 방법

프로젝트 이름은 출처만 알려 줄 뿐 현재 상태를 직접 보장하지 않습니다. 클라이언트를 선택할 때는 릴리스 기록, 코어 출처, 시스템 대응과 설정 호환성을 함께 확인해야 합니다. 화면이 여전히 열린다고 해서 현재 구독의 모든 필드를 제대로 처리할 수 있다는 뜻은 아닙니다.

최근 릴리스 기록을 확인하세요. 저장소에 접속할 수 있는지만 보지 말고 정식 버전의 출시일, 변경 사항과 지원 시스템을 확인하세요.
코어 이름과 버전을 확인하세요. ‘설정’ → ‘정보’ 또는 ‘설정’ → ‘Clash 설정’에서 mihomo 버전을 명확히 표시하는 클라이언트를 우선 선택하세요.
운영체제 아키텍처를 확인하세요. Windows는 일반적으로 x64와 ARM64를 구분하고, macOS는 Apple Silicon과 Intel을 확인해야 하며, Linux는 AppImage, deb, rpm 또는 명령줄 배포 방식을 추가로 확인해야 합니다.
권한 방식을 확인하세요. TUN이 필요하다면 클라이언트가 서비스 모드, 관리자 권한 안내 또는 macOS 네트워크 확장 승인 절차를 제공하는지 확인하세요.
구독 요구 사항을 확인하세요. 설정 제공자가 mihomo, Meta 또는 특정 프로토콜 지원을 명시했다면 구버전 오리지널 Clash만 통합한 클라이언트는 선택하지 마세요.
되돌릴 수 있는 설정을 보관하세요. 클라이언트나 코어를 업데이트하기 전에 현재 정상 작동하는 설정을 내보내고 시스템 프록시 포트, 오버라이드 항목과 DNS 설정을 기록하세요.

구형 클라이언트에서 mihomo 클라이언트로 마이그레이션하기

Clash for Windows, 구형 ClashX 또는 초기 Verge에서 마이그레이션할 때는 구독과 로컬 설정을 분리해 처리하는 것이 가장 안전합니다. 먼저 새 클라이언트에 원본 구독을 가져와 기본 프록시가 작동하는지 확인한 뒤 오버라이드, TUN, LAN 접근과 사용자 지정 규칙을 항목별로 복원하세요. 구형 설정 디렉터리 전체를 그대로 복사하면 캐시, 오래된 코어 경로와 더 이상 유효하지 않은 컨트롤러 설정까지 함께 옮겨질 수 있습니다.

마이그레이션 전에 기록할 다섯 가지

현재 구독 주소와 마지막 업데이트 시각을 기록하고, 구독이 여전히 정상적으로 새로고침되는지도 확인하세요.
프록시 진입 포트입니다. 흔히 혼합 포트 7890을 사용하지만 HTTP 7890과 SOCKS 7891을 각각 지정할 수도 있습니다.
현재 모드가 Rule, Global, Direct 중 무엇인지와 기본 프록시 그룹 선택을 기록하세요.
TUN, LAN 연결, IPv6와 사용자 지정 DNS가 활성화되어 있는지 확인하세요.
로컬에서 추가한 규칙, 스크립트 또는 설정 오버라이드입니다. 이런 내용은 일반적으로 원격 구독에 포함되지 않습니다.

세 차례 테스트로 마이그레이션 결과 확인하기

1차 테스트에서는 시스템 프록시만 켜세요. TUN을 끄고 Rule 모드를 선택한 다음 한국 국내 사이트와 프록시가 필요한 사이트를 각각 열어 로그에 해당 규칙과 프록시 그룹이 표시되는지 확인하세요.
2차 테스트에서는 구독 새로고침을 확인하세요. 설정을 한 번 수동으로 업데이트하고 화면에 업데이트 시각이 표시될 때까지 기다린 뒤 프록시 그룹 선택이 예기치 않게 초기화되지 않았는지 확인하세요.
3차 테스트에서 TUN을 활성화하세요. 서비스 모드를 시작하거나 시스템 승인을 완료한 뒤 시스템 프록시를 읽지 않는 명령줄 프로그램을 테스트하세요. curl --connect-timeout 10 https://example.com을 사용하면 연결 시간 제한을 10초로 설정할 수 있으며, 클라이언트 연결 목록과 대조해 확인할 수 있습니다.

1차 테스트는 성공했지만 3차 테스트가 실패한다면 문제는 대개 TUN 권한, 라우팅 또는 DNS에 있으므로 구독을 다시 바꿀 필요가 없습니다. 설정을 가져오는 단계에서 이미 오류가 발생했다면 첫 번째 파싱 오류를 확인해 해당 필드에 mihomo가 필요한지 판단하세요. 특정 노드만 실패한다면 프로토콜 매개변수와 서버 상태를 비교해 보세요.

관계도 한 장으로 전체 생태계 기억하기

Clash 생태계는 ‘하나의 소프트웨어가 여러 이름으로 바뀐 것’이 아니라, 설정 철학을 공유하면서도 서로 다른 팀이 유지보수하는 프로젝트 묶음입니다. 오리지널 Clash는 기본 코어이고, Clash.Meta는 그 설정 모델을 바탕으로 기능을 확장했으며, 이후 mihomo라는 이름으로 개발을 이어 가고 있습니다. Clash Verge Rev, ClashX 같은 프로젝트는 GUI 클라이언트 계층에 있으며 코어를 통합해 실제 프록시 기능을 수행합니다. 구독은 설정 계층에 속하며 호환되는 클라이언트 사이에서 옮겨 쓸 수 있습니다.

구독 및 YAML 설정
        │
        ▼
GUI 클라이언트
Clash Verge Rev / ClashX / 기타 클라이언트
        │
        ▼
프록시 코어
mihomo（구 Clash.Meta）
        │
        ▼
규칙 매칭 / DNS / 시스템 프록시 / TUN / 연결 전달

선택할 때는 질문을 세 가지로 줄여 보세요. 클라이언트가 아직 유지보수되고 있는가, 어떤 코어를 통합했는가, 현재 구독이 해당 코어의 확장 기능에 의존하는가입니다. 이 세 가지에 답하면 이름이 비슷해서 생기는 혼란이 크게 줄어듭니다. 새로 설치하는 환경이라면 릴리스 기록이 남아 있고 mihomo를 명확히 통합했으며 현재 운영체제의 권한 체계에 대응하는 클라이언트를 우선 고려하세요. 이미 안정적으로 사용하는 환경이라면 먼저 설정과 포트를 기록한 뒤 단계적으로 마이그레이션하는 것이 좋습니다.