오픈소스 프로젝트 · mihomo 코어 클라이언트 지속 업데이트

Clash 클라이언트전 플랫폼 다운로드

운영체제에 맞는 클라이언트를 선택하고 mihomo 코어로 프록시 연결을 처리하세요. 규칙 기반 라우팅으로 요청을 관리하고 한국어 문서를 따라 설정할 수 있습니다.

  • 단일 인바운드 HTTP와 SOCKS가 혼합 포트를 함께 사용
  • 필요한 방식으로 연결 시스템 프록시와 TUN을 각각 설정
  • 한눈에 보이는 설정 구독, 프록시 그룹, 규칙을 계층별로 관리

MIHOMO 코어 · GPL-3.0 오픈소스 · 규칙 기반 라우팅

규칙 기반 라우팅TUN 모드구독 관리
PLATFORMS 운영체제에 맞는 설치 파일 선택
COREmihomo프로토콜 및 규칙 엔진
LICENSEGPL-3.0코어 소스 코드 공개
CONFIGURATIONYAML 설정인바운드 / 프록시 그룹 / 규칙
PROTOCOLS / CORE

프로토콜 종류와 코어 지원호환성을 먼저 확인한 뒤 선택하세요

프로토콜 이름은 연결 방식을 나타낼 뿐, 속도가 정해져 있다는 뜻은 아닙니다. 서버 매개변수와 네트워크 경로, 클라이언트 코어가 서로 맞아야 합니다. 구독을 가져온 뒤에는 현재 코어가 프로토콜 항목을 인식하는지 먼저 확인하세요.

기존 구독이 있는 경우

서버에서 제공한 프로토콜과 전송 매개변수를 그대로 사용하세요. 클라이언트가 설정을 읽을 수 있는 것은 첫 단계일 뿐입니다. TLS, 전송 계층, 프록시 그룹 참조가 모두 올바른지 확인해야 합니다.

모바일 네트워크

네트워크 전환 후 연결이 복구되는지, 백그라운드 제한이 있는지 확인하세요. QUIC 기반 프로토콜은 UDP 사용 가능 여부에 영향을 받으므로, 프로토콜 이름만으로 배터리 소모나 연결 안정성을 판단할 수 없습니다.

데스크톱 및 서버 배포

데스크톱은 GUI 조작과 시스템 연동이 중요하고, 서버는 서비스 관리와 유지보수하기 쉬운 설정이 중요합니다. 프로토콜 및 코어 기술 참고 자료 보기 →

01 / CLIENT SELECTION

Clash 전 플랫폼 클라이언트운영체제와 프로세서에 맞게 선택

GUI 클라이언트는 구독 관리, 프록시 전환, 시스템 연동을 담당하고 코어는 규칙을 해석해 연결을 설정합니다. 기기에 맞는 설치 파일을 선택한 다음, 설정에 필요한 프로토콜을 지원하는지 확인하세요.

Windows

Clash Plus, Clash Verge Rev, FlClash 등의 GUI 클라이언트를 사용할 수 있습니다. 먼저 시스템 정보에서 프로세서 아키텍처를 확인하세요. 설치 후에는 시스템 프록시부터 테스트하고, 시스템 프록시를 사용하지 않는 프로그램까지 연결해야 한다면 가이드에 따라 TUN 서비스를 설정하세요.

다운로드 Windows 클라이언트→

macOS

Apple Silicon 또는 Intel에 맞는 빌드를 선택하세요. 시스템 프록시와 네트워크 확장 권한은 설정 위치가 다르므로, 처음 실행할 때 시스템 안내에 따라 허용하면 됩니다. 클라이언트를 업데이트하기 전에는 설정을 백업하세요. 구독이나 규칙 문제를 해결할 때 재설치부터 할 필요는 없습니다.

다운로드 macOS 클라이언트→

Android

Clash Plus, Clash Meta for Android, FlClash, Surfboard 중에서 선택할 수 있습니다. 기기의 아키텍처와 설정 형식을 확인하고, 처음 연결할 때 VPN 연결을 허용하세요. 앱을 전환한 뒤 연결이 끊긴다면 백그라운드 실행 및 배터리 관리 제한을 확인하세요.

다운로드 Android 클라이언트→

iOS

App Store에서 Clash Plus를 설치하세요. 공식 웹사이트는 clashplus.io입니다. 설정을 가져온 뒤 VPN 구성을 추가하도록 허용하고 프록시 그룹을 선택하세요. 앱 화면은 데스크톱 버전과 다를 수 있으므로 연결 상태, 활성 설정, 규칙 일치 여부를 기준으로 문제를 확인하세요.

다운로드 iOS 클라이언트→

Linux

데스크톱 환경에서는 Clash Verge Rev 또는 FlClash를 사용할 수 있으며, 배포판에 맞는 패키지를 선택하세요. GUI가 없는 서버에서는 mihomo를 직접 실행하고 서비스 관리자로 프로세스를 유지할 수 있습니다. 설정 디렉터리 권한, 리스닝 주소, 서비스 로그도 함께 확인하세요.

다운로드 Linux 클라이언트→
02 / CONFIGURATION WORKBENCH

인바운드, 규칙, 프록시 그룹연결 경로를 따라 설정 이해하기

요청은 로컬 인바운드, 규칙 일치, 아웃바운드 선택 순으로 처리됩니다. 이 경로를 따라 설정하면 여러 스위치를 한꺼번에 바꾸는 것보다 결과를 확인하기 쉽습니다.

규칙 기반 라우팅
TUN 모드
혼합 포트 · LAN 공유
mixed-port: 7890
allow-lan: false
구독 업데이트
노드 속도 테스트
외부 컨트롤
로그 확인
설정 오버라이드 · 규칙 순서
DOMAIN-SUFFIX,github.com,PROXY
GEOIP,CN,DIRECT
MATCH,DIRECT
DNS 설정
프록시 그룹
여러 설정 간 전환

규칙은 순서대로 일치 여부를 확인하고, 프록시 그룹은 아웃바운드를 결정합니다

규칙 모드는 모든 연결을 하나의 노드로 보내는 방식이 아닙니다. 코어는 도메인, 주소 또는 규칙 세트를 위에서 아래로 확인하고, 조건에 맞으면 해당 정책으로 요청을 전달합니다. 정책은 직접 연결일 수도 있고 프록시 그룹일 수도 있습니다. 설정을 조정할 때는 구체적인 조건을 앞쪽에 두고 기본 처리 규칙인 MATCH를 마지막에 배치하세요. 규칙에서 참조하는 그룹 이름이 실제로 존재하는지도 확인해야 합니다. 전역 모드와 달리 규칙 모드에서는 서비스마다 연결 경로를 다르게 유지할 수 있지만, 결과는 규칙 내용에 따라 달라집니다. 특정 앱이 잘못된 경로로 연결된다면 모든 노드를 계속 바꾸기보다 연결 목록에서 적용된 규칙을 확인하고 해당 조건을 수정하세요.

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

속도 테스트 결과와 실제 다운로드 속도는 구분하세요

노드 속도 테스트는 보통 지정된 주소에 대한 연결 응답 시간을 측정하며, 지속적인 다운로드 속도를 측정하는 테스트는 아닙니다. 응답이 빠른 노드도 대역폭, 서버 부하, 대상 사이트 제한에 영향을 받을 수 있습니다. 같은 네트워크와 테스트 대상, 비슷한 시간대에 비교하고 한 번에 하나의 변수만 바꾸세요. 브라우저는 정상인데 터미널에서 실패한다면 노드 문제로 단정하지 말고 터미널이 프록시 환경 변수를 읽는지 먼저 확인하세요.

로그는 실패 단계를 찾는 데 활용하세요

구독 다운로드, 설정 파싱, 도메인 조회, 대상 연결 중 어느 단계에서 실패했는지 먼저 구분한 뒤 관련 설정을 확인하세요. 문제를 찾을 때는 로그 상세 수준을 잠시 높여도 도움이 됩니다. 로그를 공유하기 전에는 구독 링크, 인증 정보, 개인 주소를 삭제하세요. 활성 설정, 모드, 재현 절차를 기록해 두면 반복해서 재설치하는 것보다 문제 해결에 도움이 됩니다.

03 / FIRST CONNECTION

구독 가져오기와 연결 확인재현 가능한 연결부터 하나씩 확인

처음 설정할 때는 기본 포트를 유지하고 현재 필요한 네트워크 모드만 활성화하세요. 각 단계를 마칠 때마다 상태를 확인한 다음 진행하세요.

STEP 01

구독을 가져와 활성화

클라이언트의 구독 또는 설정 화면에서 구독 주소를 추가하고, 다운로드가 완료되면 해당 설정을 선택하세요. 파일 파싱이 정상적으로 끝났는지, 프록시 그룹에 선택 가능한 항목이 있는지 확인한 뒤 다음 단계로 넘어가세요. 구독 주소에는 보통 접속 정보가 포함되므로 공개 게시판에 올리지 마세요. 가져오는 중 오류가 발생하면 먼저 응답이 설정 파일인지 오류 페이지인지 확인하세요.

STEP 02

모드와 아웃바운드 선택

일반적으로 규칙 모드로 시작하고 주요 프록시 그룹에서 사용할 수 있는 노드를 선택하세요. 데스크톱에서는 시스템 프록시를 켜고, 모바일에서는 시스템 안내에 따라 VPN 연결을 허용하세요. 여러 프록시 앱을 동시에 실행하지 말고, 기본 연결을 확인하기 전에는 DNS, 포트, 라우팅 등 여러 설정을 한꺼번에 바꾸지 마세요.

STEP 03

대상에 접속해 연결 확인

확인하려는 앱을 열고 연결 목록에서 해당 도메인이나 프로세스를 찾아 적용된 규칙과 실제 아웃바운드를 확인하세요. 스위치가 켜져 있다는 사실만으로 요청이 코어에 전달되었다고 볼 수는 없습니다. 앱의 연결 기록이 없다면 프록시 진입 경로를 확인하세요. 기록은 있지만 연결에 실패한다면 DNS 결과, 노드 연결, 대상 서비스 순으로 살펴보세요.

전체 가이드 보기 →

04 / OPEN SOURCE CONTEXT

Clash 생태계와 mihomo 코어클라이언트 UI 너머의 프로젝트 관계

여기서 Clash는 설정 방식을 공유하는 클라이언트와 코어 생태계를 뜻하며, 모든 앱이 같은 팀에서 개발되었다는 의미는 아닙니다. 화면이 비슷해도 프로토콜 지원과 설정 동작까지 완전히 같다고 볼 수 없습니다.

원본 설정 모델에서 mihomo까지

Clash는 YAML로 프록시, 프록시 그룹, 규칙을 정의하며 GUI 클라이언트는 이를 바탕으로 가져오기, 전환, 시스템 연동 기능을 제공합니다. 원본 프로젝트의 유지 관리가 중단된 뒤에도 생태계의 여러 프로젝트는 계속 발전해 왔습니다. Clash Meta와 후속 프로젝트인 mihomo는 프로젝트 계보상 관련이 있어 예전 가이드에서는 두 이름이 함께 등장합니다. 기능 지원 여부를 확인할 때는 앱 이름에 Meta가 있는지만 보지 말고 현재 실행 중인 코어를 확인하세요.

오픈소스 범위와 라이선스는 따로 확인하세요

mihomo 코어는 GPL-3.0 라이선스를 사용하며, 소스 코드와 이슈, 커밋 기록은 프로젝트 저장소에서 확인할 수 있습니다. GUI 클라이언트, 시스템 서비스 구성 요소, 설정 도구는 각각 별도의 저장소와 라이선스를 사용할 수 있으므로 코어 라이선스를 모든 소프트웨어에 그대로 적용해서는 안 됩니다. 코드를 수정, 배포, 통합하려면 해당 프로젝트의 라이선스 파일과 의존성 안내를 확인하세요. 일상적인 연결이 목적이라면 다운로드 페이지에서 유지 관리 상태와 시스템 요구 사항부터 살펴보면 됩니다.

설정 호환성이 모든 항목의 완전한 동일성을 뜻하지는 않습니다

기존 설정의 기본 규칙과 일부 프록시 필드는 계속 사용할 수 있지만, 새 프로토콜과 규칙 유형, 고급 DNS 필드는 해당 코어의 지원이 필요합니다. 설정을 다른 클라이언트에 복사하기 전에는 전체 YAML을 받는지 노드 구독만 받는지 확인하고, 클라이언트가 기본 설정을 자동으로 병합하는지도 살펴보세요. 파싱 오류가 발생하면 로그에 표시된 필드를 하나씩 처리하세요. 파일을 읽히게 하려고 낯선 설정을 한꺼번에 삭제하는 것은 권장하지 않습니다.

클라이언트, 코어, 구독은 각각 따로 업데이트됩니다

클라이언트 업데이트는 주로 UI, 플랫폼 연동, 패키징된 구성 요소를 바꾸고, 코어 업데이트는 프로토콜 구현과 규칙 파싱에 영향을 줍니다. 구독 업데이트는 원격에서 제공하는 노드나 설정을 바꿉니다. 세 가지 업데이트는 해결하는 문제가 서로 다릅니다. 업데이트 전에는 복구할 수 있도록 설정을 보관하고, 업데이트 후에는 활성 설정, 리스닝 포트, 시스템 프록시 상태를 확인하세요. 사용 중인 연결에 변화가 생겼다면 먼저 업데이트 내용을 확인한 뒤 설정을 되돌릴지 조정할지 결정하세요.

05 / TECHNICAL NOTES

Clash 설정 및 문제 해결 글증상에 맞는 설정을 찾아보세요

빠른 시작 가이드는 첫 연결을 돕고, 기술 참고 자료는 프로토콜과 코어를 설명하며, 주제별 글은 특정 문제를 확인하는 방법을 안내합니다. 증상을 기록한 뒤 알맞은 수준의 가이드를 선택하세요.

전체 글 보기 →