Mac용 Clash 클라이언트 비교: Clash Verge Rev·ClashX Meta·FlClash

사용 방식에 맞춰 고른 뒤 설치 패키지 확인

세 클라이언트 모두 Mac에서 프록시 설정을 관리할 수 있지만, 주로 사용하는 기능은 서로 다릅니다. Clash Verge Rev는 데스크톱 통합 관리 화면에 중점을 두고, ClashX Meta는 메뉴 막대 중심으로 작동하며, FlClash는 크로스 플랫폼 인터페이스에서 설정·프록시·연결 정보를 관리합니다. 일상적으로 연결 상태를 확인하고, 정책 그룹을 수정하거나 여러 구독을 관리해야 하는지 먼저 살핀 다음 화면 구성을 비교하세요.

구독 하나를 가져와 메뉴 막대에서 노드만 바꾸는 정도라면 복잡한 대시보드가 꼭 더 편한 것은 아닙니다. 규칙 적용 여부를 자주 확인하거나 터미널 트래픽까지 처리해야 한다면 연결·로그·TUN 상태를 한곳에서 볼 수 있는 클라이언트가 유용합니다. 인터페이스 취향과 코어 호환성은 따로 판단해야 하며, 창 크기만으로 프록시 기능을 가늠할 수는 없습니다.

비교 항목	Clash Verge Rev	ClashX Meta	FlClash
인터페이스 중심	설정·연결·환경설정을 한곳에서 관리하는 통합 데스크톱 화면	빠른 전환에 적합한 macOS 메뉴 막대	페이지별로 기능을 구성한 크로스 플랫폼 창
기술 구성	Tauri 데스크톱 프레임워크, mihomo 코어 사용	macOS 기본 메뉴 막대 방식, Meta 계열 코어 사용	Flutter 인터페이스, mihomo 코어 사용
구독 관리	여러 설정 관리와 오버라이드 작업에 적합	메뉴에서 설정을 선택하고 업데이트하는 방식	통합 화면에서 설정과 정책 그룹을 관리하기에 적합
TUN 선택 시 확인할 점	서비스 모드·권한·TUN 설정 확인	해당 배포 패키지의 강화 모드와 보조 구성 요소 확인	데스크톱 서비스·권한·TUN 설정 확인
먼저 사용해 볼 사용자	로그·연결 상태를 자주 확인하고 오버라이드 설정을 관리하는 사용자	주로 메뉴 막대를 사용하고 기본 창은 자주 열지 않는 사용자	플랫폼이 달라도 일관된 조작 방식을 선호하는 사용자

코어 버전 확인: 인터페이스가 비슷해도 설정 기능은 다를 수 있습니다

그래픽 클라이언트는 설정 가져오기, 노드 표시, 시스템 프록시 제어와 백그라운드 서비스 호출을 담당합니다. mihomo 코어는 설정을 해석하고 규칙을 적용해 아웃바운드 연결을 만듭니다. Clash Meta는 mihomo의 이전 명칭으로, 오래된 가이드나 설정, 프로젝트 이름에는 여전히 Meta라는 표현이 남아 있을 수 있습니다. 이름이 비슷하다고 해서 설치 패키지에 포함된 코어 버전까지 같다는 뜻은 아닙니다.

비교할 때는 ‘클라이언트 버전’과 ‘코어 버전’을 따로 기록하세요. 클라이언트 업데이트는 화면이나 서비스 설치 절차만 바꿀 수 있지만, 코어 업데이트는 프로토콜 지원, DNS 동작, 설정 항목에 영향을 줄 수 있습니다. 새 설정 항목을 다른 클라이언트에서 가져오지 못한다면 구독이 잘못됐다고 단정하기 전에 설정 해석 로그부터 확인하세요.

설치 후 확인할 네 가지

클라이언트의 ‘정보’ 또는 버전 정보 화면에서 앱 버전을 확인하고, 코어 정보나 시작 로그에서 mihomo 버전을 기록하세요.
‘설정’ 화면에서 실제로 사용 중인 구독을 확인해 세 클라이언트가 서로 다른 설정을 실행하는 일이 없도록 하세요.
설정의 proxy-groups, rules, dns, tun 항목을 확인하고 가져온 뒤 설정 해석 오류가 없는지 점검하세요.
구독에 최신 프로토콜이나 설정 항목이 포함되어 있다면 클라이언트 소개의 ‘Clash 설정 지원’ 문구만 보지 말고 해당 코어 버전의 설정 문서를 확인하세요.

기본 YAML 설정은 대체로 옮기기 쉽지만, 클라이언트별 스크립트 오버라이드, 병합 규칙, 설정 선택 기록과 키 저장 방식은 그대로 이전되지 않을 수 있습니다. 앱을 바꾸기 전에 원본 설정을 내보내고 로컬 수정 사항을 기록하세요. 한 클라이언트의 데이터 폴더 전체를 다른 클라이언트에 덮어쓰지 마세요.

인터페이스와 구독 관리: 메뉴 막대의 빠른 조작과 통합 관리 화면

Clash Verge Rev: 설정을 자주 조정하는 경우

구독, 정책 그룹, 연결, 로그를 오가며 확인해야 한다면 통합 창에서 관련 정보를 함께 보는 편이 편리합니다. Clash Verge Rev의 설정 관리와 오버라이드 기능을 활용하면 제공업체의 구독과 로컬 설정을 분리할 수 있습니다. 예를 들어 구독은 노드 목록을 제공하고 로컬 오버라이드는 수신 대기 포트나 추가 규칙을 관리합니다. 실제 사용 전 현재 버전의 설정 병합 순서를 확인하세요.

구독에서 내려받은 YAML 파일에 직접 규칙을 수정하는 방식은 피하세요. 다음 업데이트에서 수정 내용이 덮어써질 수 있습니다. 클라이언트가 제공하는 영구 오버라이드 기능을 사용하고, 업데이트 후 최종 적용 설정에서 로컬 규칙이 원하는 위치에 유지되는지 확인하는 편이 안전합니다.

ClashX Meta: 메뉴 막대 중심으로 사용하는 경우

ClashX Meta의 장점은 자주 쓰는 기능을 메뉴 막대에서 바로 사용할 수 있다는 점입니다. 시스템 프록시를 켜고 끄거나 설정을 전환하고 정책 그룹을 선택하는 일이 대부분이라면 조작 단계가 짧습니다. 반면 복잡한 설정을 바꾸려면 설정 파일이나 별도의 제어 화면을 열어야 하는 경우가 많으므로, 통합 데스크톱 화면의 메뉴 경로를 그대로 적용할 수는 없습니다.

‘로컬 설정 파일 선택’과 ‘원격 구독 추가’는 구분해야 합니다. 원격 설정이 자동으로 업데이트되는지, 업데이트 간격을 어디서 설정하는지는 사용 중인 버전에서 확인하세요. 이름이 비슷한 원격 설정이 여러 개라면 노드가 바뀌지 않는 문제를 살피기 전에 현재 선택된 설정부터 확인하세요.

FlClash: 여러 플랫폼에서 일관된 조작 방식을 원하는 경우

FlClash는 Flutter로 인터페이스를 구성하며, 이미 페이지 구성에 익숙한 사용자에게 적합합니다. 플랫폼 간에 일관된 것은 주요 조작 방식이지 시스템 권한 처리 방식이 아닙니다. macOS의 시스템 프록시, 백그라운드 서비스, TUN 권한은 별도로 설정해야 하므로 다른 플랫폼의 절차를 그대로 따라서는 안 됩니다.

구독이 하나뿐이라면 업데이트가 정상적으로 되는지, 노드를 편리하게 전환할 수 있는지 확인하세요.
설정이 세 개 이상이라면 이름, 업데이트 상태, 현재 선택된 설정 표시를 확인하세요.
로컬 규칙이 필요하다면 구독을 업데이트한 뒤에도 오버라이드가 유지되는지, 최종 규칙 순서가 올바른지 확인하세요.

TUN과 시스템 프록시: 먼저 트래픽 처리 범위 확인

시스템 프록시는 프록시 주소를 macOS 네트워크 설정에 등록하며, 해당 설정을 따르는 앱에 주로 적용됩니다. 터미널 프로그램, 자체 네트워크 스택을 사용하는 소프트웨어, 일부 게임은 시스템 프록시를 사용하지 않을 수 있습니다. TUN은 가상 네트워크 인터페이스와 라우팅 설정으로 대상 트래픽을 처리하며, 일반적으로 보조 서비스 설치나 관리자 권한이 필요합니다.

Clash Verge Rev와 FlClash의 macOS 배포판에는 보통 TUN 관련 설정이 있습니다. ClashX Meta의 강화 모드 지원 여부와 설치 방법은 배포 패키지별로 확인해야 합니다. 코어가 TUN을 지원하더라도 그래픽 클라이언트에서 서비스 설치, 권한 관리, 라우팅 설정까지 완료됐다는 뜻은 아닙니다.

반복해서 사용할 수 있는 확인 순서

다른 프록시 앱, VPN, 기존 클라이언트의 자동 실행을 끄고 테스트할 클라이언트 하나만 남기세요.
TUN은 끄고 시스템 프록시만 켜세요. ‘시스템 설정’→‘네트워크’→현재 네트워크 서비스→‘세부사항’→‘프록시’에서 주소와 포트를 확인합니다. macOS 버전에 따라 항목 이름이 조금 다를 수 있습니다.
클라이언트에서 실제로 사용하는 수신 대기 포트를 확인하세요. 아래의 로컬 혼합 포트 7890은 설정 예시일 뿐이며, 세 클라이언트의 공통 기본값이 아닙니다.
명시적 프록시 요청이 성공하는지 확인한 뒤 클라이언트 안내에 따라 보조 서비스를 설치하거나 활성화하고 TUN을 켜세요. 시작 로그에서 인터페이스, 라우팅 또는 DNS 오류가 없는지 확인합니다.
시스템 프록시를 끄고 터미널의 프록시 환경 변수를 지운 다음 테스트 요청을 보내세요. 클라이언트 연결 목록에서 트래픽이 처리됐는지, 어떤 규칙이 적용됐는지 확인합니다.

# HTTP 프록시를 명시해 로컬 수신 포트 확인
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com

# 일반적인 프록시 환경 변수를 제외하고 curl 프록시 옵션은 사용하지 않음
env -u http_proxy -u https_proxy -u all_proxy \
    -u HTTP_PROXY -u HTTPS_PROXY -u ALL_PROXY \
    curl --noproxy '*' --connect-timeout 10 -I https://example.com

두 번째 명령은 애플리케이션 계층 프록시의 영향을 배제하는 한 가지 테스트일 뿐이며, 요청이 성공했다고 해서 TUN이 작동한다고 단정할 수는 없습니다. 대상 사이트에 직접 연결할 수 있는 경우도 있기 때문입니다. 연결 기록에서 프로세스, 대상 주소, 아웃바운드 정책을 함께 확인하세요. 필요하면 테스트용 규칙을 임시로 추가하고 확인이 끝나면 삭제합니다.

시스템 리소스 사용량: 같은 설정으로 측정하고 프레임워크만으로 순위를 매기지 마세요

‘기본 메뉴 막대 앱이 항상 메모리를 가장 적게 쓴다’거나 ‘특정 프레임워크가 무조건 더 빠르다’고 단정할 수는 없습니다. 그래픽 인터페이스, 코어, 보조 서비스는 서로 다른 프로세스이며 규칙 수, 연결 수, 로그 수준, 구독 업데이트, TUN 설정도 리소스 사용량을 바꿉니다. 메인 창 프로세스의 메모리만 캡처하면 실제 트래픽을 처리하는 백그라운드 프로세스를 놓칠 수 있습니다.

다음 조건을 동일하게 맞춰 테스트하세요

기기 및 시스템: 같은 Mac에서 차례로 테스트하고 Apple Silicon 또는 Intel 여부, 메모리 용량, ‘이 Mac에 관하여’에 표시된 전체 macOS 버전을 기록하세요.
설정: 같은 구독 스냅샷, 같은 노드, 동일한 규칙과 DNS 설정을 사용하세요. 먼저 모든 클라이언트에서 TUN을 끈 상태로 비교한 다음 TUN 테스트를 별도로 진행합니다.
유휴 상태: 실행 후 2분간 기다린 다음 5분 동안 연속으로 관찰하며 CPU, 메모리, 깨우기 상태를 기록하세요.
부하 상태: 같은 테스트 파일을 60초 동안 다운로드하고 동일한 웹페이지 10개를 확인하세요. 각 테스트를 3회 반복하고 시간과 네트워크 환경을 기록합니다.
창 상태: 메인 창을 닫았을 때와 열었을 때의 결과를 각각 기록하세요. 세 클라이언트의 로그 수준도 동일하게 맞춥니다.

‘응용 프로그램’→‘유틸리티’→‘활성 상태 보기’를 열고 ‘보기’에서 ‘모든 프로세스’를 선택한 다음 ‘CPU’, ‘메모리’, ‘에너지’를 각각 확인하세요. 앱, mihomo 코어, 관련 보조 서비스를 기록하고 웹 렌더링 보조 프로세스도 빠뜨리지 마세요. CPU 백분율은 시간에 따라 달라지는 지표이므로 같은 샘플링 구간끼리 비교해야 합니다. 메모리는 단일 수치만 낮은지 볼 것이 아니라 시스템 메모리 압력도 함께 확인하세요.

위에 제시한 숫자는 테스트 시간과 조작 조건이지 세 클라이언트의 실측 결과가 아닙니다. 기기, 버전, 설정을 통일하지 않았다면 고정된 MB 순위를 제시하는 것은 적절하지 않습니다. 노트북 사용자는 한 번 캡처한 수치보다 덮개를 닫기 전 CPU 사용량이 계속 높은지, 유휴 상태에서 자주 깨어나는지, 창을 닫은 뒤 백그라운드가 정상 작동하는지를 확인하는 편이 더 유용합니다.

Apple Silicon과 Intel: 설치 전 아키텍처와 시스템 요구 사항 확인

먼저 Apple 메뉴→‘이 Mac에 관하여’를 여세요. ‘칩’ 항목에 Apple M 시리즈가 표시되면 arm64 또는 aarch64로 표시된 설치 패키지를 우선 선택하세요. Intel 프로세서라고 표시되면 x64 또는 x86_64 패키지를 선택합니다. Universal 패키지에는 두 아키텍처가 모두 포함될 수 있지만, 배포 패키지 안내를 확인해야 합니다.

Apple Silicon에서 Rosetta를 통해 Intel 앱을 실행한다고 해서 프록시 구성 요소 전체가 네이티브 아키텍처로 작동하는 것은 아닙니다. 그래픽 앱, 코어, 보조 서비스의 아키텍처를 모두 확인하세요. ‘활성 상태 보기’에 ‘종류’ 열을 표시하면 프로세스가 Apple용인지 Intel용인지 확인하는 데 도움이 됩니다. 최소 macOS 요구 사항도 버전별로 살펴봐야 합니다. Mac을 지원한다는 이유만으로 오래된 시스템에도 설치할 수 있다고 판단하지 마세요.

새 클라이언트를 설치하기 전에 기존 클라이언트의 시스템 프록시 상태, 수신 대기 포트, 로그인 시 자동 실행 설정을 기록하세요.
두 앱이 동시에 127.0.0.1:7890을 사용하지 않도록 하세요. 주소 사용 중 오류가 나면 계속 재설치하기보다 기존 코어를 먼저 종료하세요.
마이그레이션이 끝나면 기존 클라이언트를 종료하고 시스템 프록시 설정을 다시 쓰거나 TUN을 재활성화하지 않는지 확인하세요.
클라이언트를 종료한 뒤 브라우저에서 인터넷에 연결할 수 없다면 시스템 프록시가 중지된 로컬 포트를 가리키고 있는지 먼저 확인하세요.

사용 사례에 맞춰 후보를 고른 뒤 마이그레이션을 검증하세요

여러 설정을 관리하고 연결 로그를 자주 확인하며 로컬 오버라이드를 유지해야 한다면 Clash Verge Rev를 먼저 사용해 보세요. 메뉴 막대를 주로 사용하고 설정이 안정적이며 통합 화면을 자주 열지 않는다면 ClashX Meta를 고려할 수 있습니다. FlClash의 설정 및 정책 그룹 화면에 익숙하고 기기 간에 비슷한 조작 방식을 원한다면 FlClash를 먼저 사용해 보세요.

터미널, 개발 도구 또는 게임의 트래픽을 처리하는 것이 가장 중요하다면 인터페이스 취향보다 TUN 권한, 라우팅, DNS 검증을 먼저 확인하세요. 브라우저만 사용한다면 시스템 프록시부터 테스트하면 되며, ‘기능이 더 많다’는 이유로 TUN을 바로 켤 필요는 없습니다. 규칙 모드는 설정에 따라 아웃바운드를 선택하고, 전역 모드는 일반적으로 연결을 지정된 전역 정책으로 보냅니다. 두 모드는 TUN을 켰는지 여부와 별개의 설정입니다.

정식 전환 전 확인할 다섯 가지

구독을 수동으로 업데이트할 수 있고, 업데이트 후 노드·정책 그룹·규칙 수가 예상과 일치합니다.
구독 업데이트 후에도 로컬 오버라이드가 적용되며 민감한 구독 주소를 공개 로그나 스크린샷에 노출하지 않았습니다.
브라우저와 실제로 사용하는 터미널 도구를 모두 테스트했고 연결 기록의 정책이 예상과 일치합니다.
클라이언트 종료, 재시작, 잠자기 후 깨우기를 거친 뒤 네트워크 설정이 복구되거나 예상대로 다시 트래픽을 처리합니다.
기존 클라이언트를 삭제하기 전에 일상적인 작업 주기 동안 리소스 사용량을 관찰합니다.

클라이언트를 선택할 때는 설정 호환성, 명확한 조작 경로, 검증 가능한 트래픽 처리 범위, 종료 후 네트워크 상태 제어를 기준으로 삼으세요. 복구할 수 있는 원본 설정을 보관한 뒤 항목별로 옮기면 클라이언트를 여러 개 설치하고 프록시를 반복해서 켰다 끄는 것보다 문제를 쉽게 찾을 수 있습니다.