Clash 오픈소스 생태계 정리: mihomo 코어와 Mac 클라이언트의 관계

Clash 생태계의 세 가지 계층

Mac용 Clash를 검색하면 mihomo, Clash Meta, ClashX Meta, Clash Verge Rev 같은 이름을 함께 볼 수 있습니다. 이들은 같은 계층에 속하지 않습니다. 네트워크 트래픽을 처리하는 것, 설정 창을 제공하는 것, 도메인 및 IP 규칙만 제공하는 것이 각각 다릅니다. 클라이언트를 고르기 전에 계층을 구분하면 클라이언트를 바꿀지, 코어를 업그레이드할지, 설정을 조정할지 판단하기 쉽습니다.

계층	주요 역할	확인할 위치
프록시 코어	프록시 연결을 설정하고 DNS, 규칙 매칭, 정책 그룹 선택을 처리	코어 정보, 시작 로그, 실행 설정
GUI 클라이언트	구독 관리, 설정 전환, 시스템 프록시 설정, 연결 상태 표시	클라이언트 설정, 구독 관리, 서비스 관리
규칙 및 설정	매칭 조건, 노드 정의, 트래픽 출구 지정	YAML, 규칙 제공자, 구독 콘텐츠

일반적인 연결 흐름은 “앱 트래픽 → 시스템 프록시 또는 TUN → 코어 → 규칙 및 정책 그룹 → 출구”입니다. GUI는 이 흐름을 제어하지만, 창 자체가 프록시 프로토콜을 구현하는 것은 아닙니다. 같은 코어를 사용해도 클라이언트마다 설정 메뉴, 구독 덮어쓰기 방식, 권한 관리 방법이 다를 수 있습니다.

Clash 원본, Clash Meta, mihomo

Clash 원본 코어와 파생 프로젝트

Clash 원본의 공개 프로젝트는 2023년에 공개 유지보수를 중단했습니다. 과거 자료에는 Clash Premium도 등장하지만, 원본 오픈소스 코어와 기능 구성이 완전히 같지는 않습니다. 예전 튜토리얼에서 Premium으로 표시된 기능은 “Clash”라는 이름만 보고 현재 코어에서 지원하는지 판단할 수 없습니다.

Clash Meta는 Clash에서 파생된 브랜치로, 이후 mihomo라는 이름을 사용하게 됐습니다. 따라서 설정 안내의 “Meta 코어”와 프로젝트 문서의 “mihomo”는 같은 기술 계보를 가리키는 경우가 많습니다. 예전 클라이언트 이름에 “Meta”가 남아 있어도 포함된 코어가 최신이라고 단정할 수는 없습니다.

이름이 비슷해도 설정 항목이 호환되는 것은 아닙니다

mihomo는 proxies, proxy-groups, rules와 같은 Clash YAML 설정을 상당 부분 이어받고, 프로토콜과 규칙 기능을 확장했습니다. 다만 호환성에는 방향이 있습니다. 일반적인 기본 설정은 계속 사용할 수 있지만, mihomo 확장 항목을 사용하는 설정은 구형 코어에서 실행되지 않을 수 있습니다.

구독을 가져오지 못하면 먼저 로그에 알 수 없는 프록시 유형, 잘못된 필드, 존재하지 않는 정책 그룹 참조가 표시되는지 확인하세요.
설정 로드에 성공했다는 것은 현재 단계의 구문 분석을 통과했다는 뜻일 뿐입니다. 실제 요청에 어떤 규칙과 출구가 적용되는지도 확인해야 합니다.
특정 프로토콜, 규칙 형식 또는 TUN 기능이 필요하다면 사용 중인 코어의 문서와 실제 빌드를 기준으로 확인하세요.

GUI를 바꾸면 기능이 반드시 향상된다고 생각하지 마세요. 새 클라이언트가 다른 코어를 사용하거나 예전 실행 설정을 그대로 유지하면 같은 문제가 반복될 수 있습니다. 문제를 진단할 때는 클라이언트 이름, 코어 이름, 설정 출처를 각각 기록하세요.

Mac용 GUI 클라이언트의 역할과 범위

ClashX Meta, Clash Verge Rev, FlClash 등은 macOS용 GUI를 제공해 왔지만, 사용 방식과 설정 관리 모델은 서로 다릅니다. 아래 표는 역할을 이해하기 위한 자료이며, 현재 유지보수 상태나 전체 기능 목록을 보장하지 않습니다. 설치 전에는 각 프로젝트의 릴리스 노트와 시스템 요구 사항을 확인하세요.

클라이언트 유형	일반적인 사용 방식	선택 시 확인할 사항
ClashX Meta	macOS 메뉴 막대에서 프록시와 설정을 관리	번들 코어, 설정 메뉴, 권한 설치 방식
Clash Verge Rev	별도 창에서 구독, 연결, 실행 설정 관리	덮어쓰기 방식, 서비스 모드, 코어 설정
FlClash	크로스 플랫폼 GUI에서 mihomo 설정 관리	macOS 빌드 요구 사항, 설정 관리, TUN 메뉴

시스템 프록시는 클라이언트와 운영체제가 함께 동작합니다

macOS 시스템 프록시는 일반적으로 해당 설정을 지원하는 앱의 트래픽을 로컬 리스닝 포트로 전달합니다. macOS Ventura 이후 버전을 예로 들면, ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 서비스 → ‘세부사항’ → ‘프록시’에서 HTTP, HTTPS, SOCKS 항목을 확인할 수 있습니다. 포트는 코어가 실제로 리스닝하는 값과 일치해야 하며, 다른 기기의 설정을 그대로 복사하면 안 됩니다.

예를 들어 코어에서 mixed-port: 7890으로 설정했다면 로컬 프록시 주소는 127.0.0.1:7890을 가리킬 수 있습니다. 여기서 7890은 예시일 뿐 모든 클라이언트의 기본값은 아닙니다. 터미널 도구가 시스템 프록시를 사용하는지는 도구 자체에 따라 다르므로, 브라우저에서 접속된다는 이유만으로 터미널의 연결 경로도 정상이라고 판단할 수 없습니다.

TUN에는 코어 기능과 시스템 권한이 필요합니다

TUN은 가상 네트워크 인터페이스로 라우팅된 IP 트래픽을 받아들이므로 시스템 프록시와 적용 범위가 다릅니다. Mac에서는 클라이언트가 권한 승인, 라우팅 설정, DNS 연동도 처리해야 합니다. 코어가 TUN을 지원하더라도 모든 GUI에 같은 스위치, 서비스 설치 절차, 문제 복구 메뉴가 있는 것은 아닙니다.

구독, 룰셋, 정책 그룹은 어떻게 연결될까

구독 링크는 설정을 배포하는 경로이지, 고정된 콘텐츠 형식이 아닙니다. 전체 YAML, 노드 제공자 콘텐츠, 변환이 필요한 다른 구독 형식 등이 반환될 수 있습니다. 한 클라이언트에서 인식되는 구독이라도 다른 클라이언트에서 같은 방식으로 가져올 수 있다는 뜻은 아닙니다.

노드 제공자proxy-providers: 파일이나 원격 소스에서 노드 목록을 불러와 정책 그룹에서 참조하도록 합니다. 노드 연결 방식은 프로토콜 매개변수로 결정됩니다.
규칙 제공자rule-providers: 매칭 조건을 불러옵니다. 규칙은 요청의 특징을 판단할 뿐 프록시 노드를 제공하지는 않습니다.
정책 그룹proxy-groups: 노드나 다른 정책 그룹을 묶어 수동 선택, 자동 테스트, 장애 전환 등의 출구 선택 방식을 제공합니다.

예를 들어 도메인 룰셋에 업무 서비스 도메인이 들어 있고, RULE-SET이 일치하는 요청을 “업무용 출구” 정책 그룹으로 전달하면 정책 그룹이 사용할 노드를 선택합니다. 룰셋을 내려받는 것만으로 프록시 경로가 생기지는 않습니다. 규칙이 있어도 연결된 정책 그룹이나 노드가 없으면 흐름이 완성되지 않습니다.

룰셋 형식과 설정을 맞춰야 합니다

mihomo에서 규칙 제공자의 대표적인 behavior 값은 domain, ipcidr, classical입니다. 도메인 목록, IP 대역 목록, 규칙 유형이 포함된 목록은 서로 바꿔 쓸 수 없습니다. format은 YAML, 텍스트, MRS 등의 저장 형식을 나타냅니다. MRS에서 지원하는 동작 유형에도 제한이 있으므로 사용 중인 코어 문서를 확인하세요.

먼저 규칙 저장소의 파일 내용과 사용 방법을 확인한 다음 제공자 항목을 설정하세요.
규칙 저장소의 분류명은 정리 방식일 뿐, 개인의 사용 환경에 꼭 맞는다는 보장은 없습니다.
규칙은 순서대로 매칭됩니다. 앞쪽의 포괄적인 규칙이 뒤쪽의 세부 규칙보다 먼저 적용될 수 있습니다.
마지막 MATCH는 앞선 규칙에 일치하지 않은 요청의 경로를 결정하므로 대상 출구를 명확히 지정해야 합니다.

설정 하나로 살펴보는 코어와 클라이언트의 역할

아래는 로컬에서 확인하기 위한 최소 구성 예시입니다. DIRECT만 사용하므로 원격 프록시 연결을 만들지 않습니다. 리스닝 포트, 정책 그룹, 규칙의 관계를 확인하는 데 적합합니다. 원격 출구가 필요하면 신뢰할 수 있는 설정에 실제 노드를 추가하세요. 이 예시를 바로 사용할 수 있는 구독으로 간주하지 마세요.

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

proxy-groups:
  - name: 수동 출구
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,수동 출구
  - MATCH,DIRECT

mixed-port는 코어가 리스닝하며 하나의 포트에서 HTTP와 SOCKS 프록시 요청을 모두 받습니다. macOS 시스템 프록시를 자동으로 변경하지는 않습니다.
allow-lan: false는 로컬 네트워크에서 프록시 접속을 제한합니다. 공유가 꼭 필요하다면 리스닝 주소와 방화벽도 함께 확인하세요.
mode: rule은 규칙에 따라 출구를 선택한다는 뜻입니다. 클라이언트에서 모드를 바꾸면 실제 실행 상태가 원본 파일과 달라질 수 있습니다.
“수동 출구”는 정책 그룹 이름입니다. 규칙에서 참조하는 이름과 일치하지 않으면 설정을 불러오지 못할 수 있습니다.
MATCH,DIRECT는 기본 규칙입니다. 나머지 요청을 직접 연결하도록 설정한 것으로, 일반적인 원격 프록시 방식은 아닙니다.

클라이언트는 시작 전에 구독, 로컬 덮어쓰기, 화면 설정을 병합할 수 있으므로 “다운로드한 YAML”과 “코어가 최종적으로 받은 YAML”은 다를 수 있습니다. 문제를 해결할 때는 구독 원문만 확인하기보다 클라이언트에서 실행 설정을 미리 보거나 내보내는 메뉴를 찾아 로그와 대조하세요. 필드 설명은 YAML 설정 가이드에서 확인할 수 있습니다.

Mac 클라이언트 선택 및 전환 점검

실제 사용 목적에 맞춰 선택하기

주로 브라우저 사용: 먼저 시스템 프록시, 설정 전환, 종료 후 프록시 복구를 확인하세요. TUN을 켤 필요는 없을 수도 있습니다.
명령줄 도구와 개발 도구를 자주 사용: 도구의 프록시 옵션과 환경 변수 지원을 확인한 뒤 TUN으로 전체 트래픽을 처리할지 결정하세요.
구독이 여러 개이고 트래픽 분기가 복잡: 로컬 덮어쓰기, 규칙 제공자 관리, 실행 설정 확인, 로그 필터링 기능을 중점적으로 살펴보세요.
메뉴 막대에서 관리하고 싶다면: 자주 사용하는 정책 그룹과 설정을 바로 전환할 수 있는지 확인하고, 코어 정보를 확인할 방법도 남겨 두세요.

네 단계로 확인하는 클라이언트 전환

기존 설정과 로컬 변경 사항을 백업하세요. 규칙 순서, 정책 그룹 선택, 포트, DNS 설정을 기록하세요. 진단 자료를 공유할 때는 구독 토큰과 노드 인증 정보를 삭제하세요.
아키텍처와 시스템 요구 사항을 확인하세요. Apple 메뉴의 ‘이 Mac에 관하여’에서 칩과 macOS 정보를 확인하고, 프로젝트에서 제공하는 Apple Silicon, Intel 또는 Universal 빌드에 맞는 설치 파일을 선택하세요.
두 코어가 같은 포트를 놓고 경쟁하지 않도록 하세요. 먼저 이전 클라이언트를 종료하고 시스템 프록시나 TUN을 끈 다음 새 클라이언트를 실행하세요. 로그에 주소가 이미 사용 중이라고 나오면 이전 프로세스가 계속 리스닝 중인지 확인하세요.
기본 기능부터 확인하고 확장하세요. 먼저 설정 로드와 시스템 프록시를 확인한 뒤 TUN, DNS 덮어쓰기, 자동 업데이트를 활성화하세요. 한 번에 한 종류의 설정만 바꾸고 되돌릴 수 있는 설정을 보관하세요.

구독을 업데이트할 때 어떤 내용이 바뀌는지는 클라이언트의 설정 관리 방식에 따라 다릅니다. 내려받은 파일을 직접 수정하면 다음 업데이트에서 변경 사항이 사라질 수 있습니다. 계속 유지할 로컬 규칙은 클라이언트가 명시적으로 지원하는 덮어쓰기 계층에 넣고 병합 순서를 확인하세요.

오픈소스 프로젝트 출처와 문제 신고 대상

오픈소스 저장소, 클라이언트 설치 파일, 구독 서비스는 서로 별개의 출처입니다. 코어 소스 코드를 확인할 수 있다고 해서 같은 이름의 설치 파일도 해당 프로젝트에서 배포했다고 볼 수는 없습니다. 구독을 정상적으로 가져올 수 있어도 제공자와 클라이언트 개발자가 관련되어 있다는 뜻은 아닙니다. 다운로드할 때는 프로젝트 조직, 저장소 링크, 릴리스 노트, 설치 파일의 운영체제 대상이 맞는지 확인하세요.

증상	먼저 확인할 항목	문제 신고에 첨부할 내용
창이 열리지 않거나 구독 버튼에서 오류 발생	클라이언트 UI 및 설정 관리 계층	시스템 정보, 재현 단계, 개인정보를 가린 오류 내용
지원하지 않는 프로토콜 또는 설정 분석 실패	코어의 지원 범위와 설정 형식	코어 정보, 최소 설정, 시작 로그
특정 도메인이 잘못된 출구로 연결됨	규칙 순서, DNS 해석, 정책 그룹	적용된 규칙, 대상 주소, 선택된 출구
특정 노드만 연결 실패	노드 매개변수, 원격 서비스, 네트워크 경로	오류 유형, 연결 시각, 민감 정보를 가린 노드 유형

전체 설정을 공유하는 것보다 최소 재현 사례가 더 유용합니다. 정책 그룹 하나와 필요한 규칙만 남기고 관련 없는 덮어쓰기를 제거한 뒤 다시 시도하세요. 로그를 공개하기 전에 구독 링크, 인증 정보, 로컬 네트워크 주소, 접속 기록이 포함되어 있는지 확인하세요. 대개 이런 정보는 모두 공개할 필요가 없습니다.

최종 선택은 세 가지 질문으로 정리할 수 있습니다. 코어가 필요한 프로토콜과 규칙을 처리할 수 있는가, 클라이언트가 이 설정을 안정적으로 관리할 수 있는가, macOS가 의도한 대로 트래픽을 전달하고 있는가? 클라이언트 이름만 비교하기보다 세 계층을 따로 확인해야 재사용하기 좋은 설정을 찾을 수 있습니다.