오픈소스 프로젝트 · 전 플랫폼 클라이언트 지속 업데이트
Clash 공식 다운로드 · 전 플랫폼 클라이언트
규칙 기반 프록시 클라이언트로 mihomo 코어를 탑재해 구독 관리, 규칙 분기, TUN 모드를 한 곳에서 설정합니다.
- mihomo 코어
- GPL-3.0 오픈소스
- Windows · macOS · Linux
- Android · iOS
- 한국어 문서
오픈소스 프로젝트 · 전 플랫폼 클라이언트 지속 업데이트
규칙 기반 프록시 클라이언트로 mihomo 코어를 탑재해 구독 관리, 규칙 분기, TUN 모드를 한 곳에서 설정합니다.
왼쪽에서 기능을 선택하면 오른쪽 패널에 해결하는 문제와 실제 사양이 표시됩니다. 각 항목은 전체 매뉴얼의 해당 챕터에서 자세히 확인할 수 있습니다.
트래픽은 규칙 매칭 후 목적지가 결정됩니다: 도메인 접미사가 일치하면 직접 연결, 지리적 위치가 일치하면 우회, 나머지는 프록시 그룹이 처리합니다. 규칙은 위에서 아래로 하나씩 매칭되며 처음 일치한 규칙이 적용되고 마지막의 MATCH가 나머지를 처리합니다. IP나 도메인 하나만 기준으로 하는 일괄 프록시 방식에 비해, 규칙 분기는 직접 연결 트래픽이 우회하지 않고 프록시 트래픽도 빠지지 않게 합니다. RULE-SET으로 원격 규칙 집합을 참조하면 규칙이 GEO 데이터에 따라 자동 갱신되어 수천 줄의 목록을 수동으로 관리할 필요가 없습니다. 작성법과 디버깅 방법은 전체 매뉴얼의 규칙 챕터에서 자세히 다룹니다.
일부 애플리케이션은 시스템 프록시 설정을 읽지 않습니다. 명령줄 도구, 게임 클라이언트, 일부 UWP 앱은 직접 연결을 시도하므로 일반적인 HTTP/SOCKS 프록시로는 처리할 수 없습니다. TUN 모드는 시스템에 가상 네트워크 어댑터를 생성해 모든 아웃바운드 트래픽을 네트워크 계층에서 가로채 코어가 처리하도록 하므로, 애플리케이션의 협조 여부에 의존하지 않습니다. 활성화하면 auto-route가 라우팅 테이블을 자동으로 인계받고, 비활성화하면 자동으로 복원됩니다. Windows에서는 wintun 드라이버를 사용하고, macOS와 Linux는 시스템 기본 utun/tun 장치를 사용하며, 처음 활성화할 때는 관리자 또는 시스템 확장 권한이 필요합니다.
설정 파일(Profile)은 하나의 config.yaml로, 포트·DNS·프록시 노드·정책 그룹·규칙 다섯 가지 내용이 한 파일에 담겨 있습니다. 구독 링크는 이것의 원격 형태로, 클라이언트가 주기적으로 가져와 노드 목록을 자동 갱신하며, 로컬에서 수정한 내용은 오버라이드(Override)로 보존되어 업데이트에 덮이지 않습니다. 여러 설정을 동시에 둘 수 있어 가정용, 업무용, 테스트용을 각각 만들어 두고 클릭 한 번으로 전환할 수 있습니다. 가져오기는 URL 다운로드, 로컬 파일, 클립보드 붙여넣기를 지원합니다. 설정 구조와 다중 Profile 관리 방법은 입문 가이드와 블로그 전문에서 확인할 수 있습니다.
정책 그룹은 여러 노드를 하나의 선택 단위로 묶습니다: select 그룹은 수동 선택, url-test 그룹은 지연 시간을 기준으로 가장 빠른 노드를 자동 선택, fallback 그룹은 우선 노드가 실패하면 순서대로 전환, load-balance 그룹은 연결을 여러 노드에 분산시킵니다. 지연 테스트는 지정한 URL에 HTTP HEAD 요청을 한 번 보내 소요 시간을 기록하는 것으로, 이 값은 대역폭이 아니라 핸드셰이크 왕복 시간을 반영하므로 노드를 고를 때는 지역과 배율도 함께 고려해야 합니다. 그룹은 중첩할 수 있어 규칙이 그룹을 가리키고 그룹이 다시 노드를 가리키는 구조로, 구조가 명확하고 변경 범위가 국지적이어서 규칙을 일일이 수정할 필요가 없습니다.
전통적인 DNS는 실제 IP를 먼저 해석한 뒤 연결하는데, 해석 결과가 오염될 수 있고 연결 전에 도메인 정보가 사라지기도 합니다. Fake-IP 모드는 예약된 대역(기본값 198.18.0.0/16)에서 즉시 가상 주소를 반환하며, 애플리케이션은 이 가짜 IP로 연결을 시도하고 코어는 연결 단계에서 테이블을 조회해 원래 도메인을 복원한 뒤 도메인 규칙에 따라 정확히 분기합니다. 실제 해석 과정을 생략해 연결이 더 빠르고 도메인 규칙 적중률도 높아집니다. 실제 IP가 필요한 일부 상황(로컬 네트워크 탐색, 일부 게임)은 fake-ip-filter로 제외하면 됩니다.
mihomo는 Clash Meta 분기를 이어가는 코어로, 원본 개발이 중단된 뒤 유지보수를 이어받았습니다. 기존 코어에 비해 아웃바운드 프로토콜(VLESS, Hysteria2, TUIC 등)을 확장하고, 규칙 집합과 GEO 데이터의 온라인 업데이트를 지원하며, TUN 네트워크 스택을 개선하고 RESTful API를 강화했습니다. 현재 주요 클라이언트인 Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu는 모두 이 코어를 내장하고 있으며, 설정 문법은 기존 방식과 하위 호환되어 예전 설정도 대부분 그대로 사용할 수 있습니다. 코어 자체는 독립 바이너리로도 제공되어 서버와 라우터 환경에 배포할 수 있습니다.
5개 플랫폼 모두 관리되는 클라이언트가 있으며, 다운로드 센터에서 플랫폼별로 설치 파일, 시스템 요구 사항, 선택 가이드를 확인할 수 있습니다.
설치가 끝나면 구독 가져오기부터 연결 확인까지 세 단계면 충분합니다. 전체 가이드에는 각 단계의 화면 위치와 문제 해결 팁이 담겨 있습니다.
서비스 제공업체가 준 구독 URL을 복사해 클라이언트의 「설정 / Profiles」 페이지에 붙여넣어 가져옵니다. 클라이언트가 설정을 내려받아 모든 노드를 나열하고, 이후 지정한 주기에 따라 자동으로 업데이트합니다.
프록시 모드는 기본값인 「규칙」을 그대로 두면 됩니다. 「프록시 / Proxies」 페이지의 정책 그룹에서 지연 시간이 적절한 노드를 고르거나, url-test 그룹에 자동 선택을 맡기면 됩니다.
「시스템 프록시」 스위치를 켜고(전역으로 인계받아야 할 때는 TUN 모드로 전환), 규칙에 포함된 사이트에 접속해 연결을 확인한 뒤 연결 패널에서 트래픽이 규칙에 맞게 처리되는지 확인합니다.
Clash 프로젝트는 2018년부터 오픈소스로 개발되어 왔으며, 핵심 코드는 GPL-3.0 라이선스로 공개되어 있습니다. 원본 코어가 2023년 개발을 중단한 뒤 커뮤니티의 Meta 분기가 개발을 이어받아 mihomo로 이름을 바꾸었고, 지금은 사실상의 표준 코어가 되었습니다. 이 사이트에 수록된 모든 클라이언트는 이 코어를 기반으로 만들어졌습니다.
이 코어를 중심으로 활발한 클라이언트 생태계가 형성되었습니다. Clash Verge Rev, FlClash, Clash Nyanpasu 등 그래픽 클라이언트는 각각 독립적으로 개발되고 배포되며, 코드 저장소, 커밋 기록, 릴리스 로그가 모두 공개되어 누구나 구현 세부 사항을 검토하거나 기여할 수 있습니다. 이 사이트가 오픈소스이거나 공식 스토어에 등록된 클라이언트만 수록하는 이유도 여기에 있습니다. 출처를 확인할 수 있고 업데이트 경로가 분명하기 때문입니다.
코어와 각 클라이언트의 버전 갱신 주기는 다릅니다. 코어는 프로토콜과 규칙 데이터의 발전에 맞춰 자주 업데이트되고, 클라이언트는 각자의 일정에 따라 코어를 반영해 패키징하고 배포합니다. 이 사이트의 다운로드 센터에 있는 설치 파일 링크는 각 프로젝트의 현재 릴리스를 가리키며, 새 버전이 나오면 링크도 함께 최신 파일로 갱신되므로 버전 번호를 직접 추적할 필요가 없습니다.
코어 구현을 직접 살펴보거나 서버에 코어만 배포하려면 소스 코드부터 시작할 수 있습니다:
git clone https://github.com/MetaCubeX/mihomo.git
Clash for Windows가 업데이트를 중단했는데, 지금은 무엇을 설치해야 하나요?
데스크톱에서는 Clash Plus나 Clash Verge Rev를 추천합니다. 둘 다 mihomo 코어를 내장하고 계속 업데이트되며, 예전 설정과도 호환됩니다. 클라이언트 비교 보기 →
구독을 가져왔는데 노드가 표시되지 않으면 어떻게 하나요?
먼저 설정 페이지에서 수동으로 업데이트를 한 번 실행하고 구독 URL이 잘리지 않았는지 확인하세요. 그래도 실패하면 대부분 링크 만료나 형식 오류이며, 가이드 페이지에 단계별 점검 방법이 있습니다. 입문 가이드 보기 →
시스템 프록시와 TUN 모드 중 무엇을 선택해야 하나요?
브라우저 같은 일반 애플리케이션은 시스템 프록시로 충분합니다. 명령줄이나 게임처럼 시스템 프록시를 거치지 않는 프로그램은 TUN 모드가 네트워크 계층에서 처리해야 합니다. 전체 매뉴얼에서 읽기 →
지연 테스트 숫자가 작을수록 노드가 빠른 건가요?
지연 시간은 핸드셰이크 왕복 시간을 나타낼 뿐 대역폭과는 다릅니다. 노드를 고를 때는 지역, 배율, 프로토콜도 함께 봐야 하며, 블로그에 전체 노드 선택 과정이 정리되어 있습니다. 블로그 보러 가기 →
설정 원리, 선택 기준, 플랫폼별 세부 사항을 다루는 글을 최신순으로 모았습니다.