# 설정 진입 → 규칙 매칭 → 정책 출구
# proxy-groups
설정을 읽을 수 있다는 건 첫 단계일 뿐입니다. 다음으로 트래픽이 어떤 경로로 들어와 어떤 규칙에 걸리고, 최종적으로 어떤 정책 그룹을 사용하는지 확인해야 합니다. 아래에서는 실제 설정 순서에 따라 다섯 가지 항목을 살펴봅니다. 화면 예시는 항목 간 관계를 보여 주며 모든 클라이언트의 화면이 같다는 뜻은 아닙니다.
일상적인 사용에서는 먼저 규칙 모드를 선택하세요. mihomo는 설정의 rules를 위에서 아래로 확인하고, 처음 일치하는 규칙의 정책을 적용합니다. 앞쪽의 도메인 규칙에 걸리면 뒤에 있는 지역 규칙은 확인되지 않을 수 있습니다. 사용자 규칙은 기본 처리용 MATCH보다 앞에 두고, 규칙에서 참조하는 정책 그룹이 실제로 있는지 확인하세요. 전역 모드와 달리 규칙 모드에서는 사내 네트워크, 자주 쓰는 직접 연결 서비스, 프록시 요청을 서로 다른 경로로 보낼 수 있습니다. 변경 후에는 페이지가 열리는지만 확인하지 말고 연결 화면에서 적용된 규칙과 정책 경로를 살펴보세요.
mode: rule
rules:
- DOMAIN-SUFFIX,github.com,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXY시스템 프록시는 첫 연결을 확인할 때 적합합니다. 켜면 시스템 프록시 설정을 따르는 브라우저와 앱이 로컬 포트로 요청을 보냅니다. 일부 명령줄 도구, 게임, 자체 네트워크 스택을 사용하는 프로그램은 이 설정을 따르지 않으므로 필요에 따라 TUN을 검토하세요. TUN은 가상 네트워크 인터페이스와 라우팅으로 트래픽을 처리하며, 데스크톱에서는 서비스 모드나 관련 권한이 필요할 수 있습니다. 두 기능은 트래픽이 들어오는 경로를 다룰 뿐, 노드나 분기 규칙을 대신하지 않습니다. 먼저 시스템 프록시로 기본 연결을 확인한 뒤 TUN을 따로 테스트하면 권한, 라우팅, DNS 충돌을 더 쉽게 찾을 수 있습니다.
mixed-port: 7890
allow-lan: false
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: trueFake-IP 모드는 도메인에 가상 주소를 반환합니다. 코어는 매핑을 통해 도메인 정보를 복원한 뒤 트래픽을 분기하고 실제 연결을 설정합니다. 모든 도메인을 특정 노드로 보내는 기능도, 켜기만 하면 모든 DNS 요청을 처리하는 기능도 아닙니다. 설정할 때는 DNS 업스트림, TUN의 DNS 처리 여부, 브라우저 자체의 보안 DNS 설정을 함께 확인하세요. LAN 기기 검색, 기업 도메인, 특정 앱의 호환성 문제가 있다면 해당 도메인을 fake-ip-filter에 추가한 뒤 결과를 살펴보세요. 처음부터 전체 DNS 경로를 바꾸면 실제 문제 지점을 찾기 어려울 수 있습니다.
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "localhost"노드 테스트 결과는 클라이언트에서 지정한 테스트 주소에 접속한 결과이며, 모든 웹사이트의 실제 속도를 뜻하지는 않습니다. select 정책 그룹에서는 노드를 직접 선택하고, url-test 정책 그룹에서는 테스트 결과에 따라 후보 노드를 자동으로 선택합니다. 실제 동작은 테스트 간격, 허용 오차, 상태 확인 설정에도 영향을 받습니다. 처음 연결할 때는 수동 그룹에서 노드를 하나 선택해 필요한 서비스에 접속되는지 확인한 뒤 자동 선택을 사용하세요. 시간 초과가 발생하면 구독 유효성, 노드 프로토콜, 로컬 네트워크를 각각 확인하세요. 설정을 계속 바꾸거나 한 번의 테스트 실패만으로 코어 오류라고 판단하지 마세요.
proxy-groups:
- name: PROXY
type: select
proxies:
- AUTO
- DIRECT
- name: AUTO
type: url-test
use:
- subscription구독은 전체 설정을 제공할 수도 있고 노드 목록만 제공할 수도 있어 서로 같은 파일처럼 다룰 수 없습니다. 구독 업데이트 과정에서 클라이언트가 설정을 다시 받아 기존 설정을 바꿀 수 있으므로, 계속 사용할 사용자 규칙은 클라이언트가 지원하는 재정의·병합 기능이나 별도 규칙 세트로 관리하는 편이 좋습니다. 업데이트 후 현재 활성화된 설정, 정책 그룹 참조, 파싱 로그를 확인해 새 내용이 실제로 적용됐는지 살펴보세요. 구독 링크에는 보통 접근 정보가 포함되므로 공개 저장소나 온라인 변환 사이트에 올리지 마세요. 문제 해결 자료를 공유하기 전에는 링크, 노드 비밀번호와 기타 식별 정보를 삭제하세요.
설정 유형 전체 Clash YAML
구독 업데이트 간격 클라이언트 설정 따름
현재 설정 선택 여부 확인
로컬 규칙 별도 재정의 사용
업데이트 완료 후 로드 로그 확인# clients
다운로드 센터에서 플랫폼별 클라이언트, 아키텍처와 설치 안내를 확인할 수 있습니다. 먼저 GUI 클라이언트를 고른 다음 기기 칩과 운영체제 요구 사항을 확인하세요. mihomo 명령줄 코어는 주로 서버, 라우터, 프로세스를 직접 관리해야 하는 사용자를 위한 것입니다. 클라이언트마다 화면과 코어 통합 방식이 다르므로 이름만 보고 기능이 완전히 같다고 판단하지 마세요.
Clash Plus, Clash Verge Rev 등의 GUI 클라이언트부터 시작해 보세요. 설치 후 구독을 가져오고 규칙 모드를 선택한 다음 시스템 프록시를 켜면 됩니다. TUN이 필요하다면 클라이언트 안내에 따라 서비스 권한을 설정하세요. 프록시 도구를 여러 개 동시에 실행하면 포트가 충돌하거나 시스템 프록시 설정이 덮어써질 수 있습니다.
브라우저는 되는데 터미널에서 연결되지 않는다면 클라이언트를 다시 설치하기보다 터미널의 프록시 환경 변수를 먼저 확인하세요. 프로그램을 종료하기 전에 시스템 프록시가 원래 설정으로 복원됐는지도 확인해야 합니다.
다운로드 페이지로 이동 →먼저 ‘이 Mac에 관하여’에서 Apple Silicon인지 Intel인지 확인하고 알맞은 설치 파일을 선택하세요. 시스템 프록시, 네트워크 확장, 보조 서비스의 권한 설정 위치는 서로 다를 수 있습니다. 설치 후 시스템 안내를 읽고 클라이언트 문서에 따라 필요한 권한을 허용하세요.
네트워크 변경, 절전 모드 해제, 다른 VPN으로 전환한 뒤 연결에 문제가 생기면 현재 네트워크 서비스의 프록시 설정부터 확인하세요. 보관된 클라이언트는 호환성을 확인할 때 참고하고, 일상적인 사용에는 계속 유지 관리되는 클라이언트를 우선 고려하세요.
다운로드 페이지로 이동 →Clash Plus, Clash Meta for Android 등의 클라이언트를 선택하고 기기 아키텍처에 맞게 설치할 수 있습니다. 처음 연결할 때 VpnService 권한을 요청합니다. 이는 앱이 로컬 VPN 인터페이스를 만들도록 시스템이 허용하는 절차이며, 원격 노드 서비스가 제공된다는 뜻은 아닙니다.
화면을 잠근 뒤 연결이 끊긴다면 배터리 최적화, 자동 시작, 백그라운드 제한을 함께 확인하세요. 기기에 다른 VPN이 연결되어 있다면 두 앱을 동시에 사용할 수 있는지 먼저 살펴보세요. 연결 아이콘만으로 실제 접속이 되는지 확인할 수는 없습니다.
다운로드 페이지로 이동 →다운로드 센터에서 Clash Plus의 App Store 링크와 공식 웹사이트 clashplus.io를 확인할 수 있습니다. 설치 후 앱에서 지원하는 방법으로 구독이나 설정을 가져오고, 시스템 VPN 권한을 허용한 뒤 정책 그룹을 선택해 연결을 테스트하세요.
iOS의 트래픽 처리는 시스템 네트워크 확장 기능으로 관리되므로 데스크톱의 시스템 프록시 스위치 안내를 그대로 적용할 수 없습니다. 설정 호환 범위, 백그라운드 연결 동작, 사용 가능한 기능은 현재 앱의 안내를 확인하세요.
다운로드 페이지로 이동 →데스크톱에서는 Clash Verge Rev 또는 FlClash를 사용할 수 있으며, 배포판에 맞는 패키지를 선택하세요. 데스크톱 프록시 설정이 터미널, 컨테이너, 백그라운드 서비스에 자동으로 적용되지는 않을 수 있으니 각각의 네트워크 경로를 확인해야 합니다.
명령줄 코어를 사용한다면 설정 디렉터리, 실행 권한, 서비스 로그를 직접 관리해야 합니다. TUN을 켜기 전에 기존 라우팅, DNS 관리자, 컨테이너 네트워크 대역을 확인하고 네트워크를 복구할 수 있는 로컬 접근 경로를 확보하세요.
다운로드 페이지로 이동 →# quickstart
먼저 최소한의 연결 경로를 구성한 뒤 복잡한 규칙을 추가하세요. 클라이언트 설치, 노드 서비스, 시스템 트래픽 처리는 서로 별개의 단계입니다. 앱을 설치했다고 노드가 생기는 것도, 노드가 있다고 모든 앱이 프록시를 사용하는 것도 아닙니다.
서비스 제공자가 준 Clash 호환 구독을 준비한 뒤 클라이언트의 설정 또는 구독 페이지에서 링크 가져오기를 선택하세요. 로컬 YAML 파일이 있다면 파일로 가져와도 됩니다. 다운로드가 완료되면 해당 설정을 선택하고 프록시 화면에 정책 그룹이 표시되는지 확인하세요. 파싱 오류가 나면 구독 형식, 링크 유효성, 파일 들여쓰기를 먼저 점검하세요. 일반 웹페이지 주소를 구독 링크로 사용하지 마세요. 노드 링크만으로는 전체 설정을 불러오지 못할 수도 있습니다.
구독 링크 가져오기 →프록시 화면에서 규칙 모드를 선택하고 실제 프록시 출구 역할을 하는 정책 그룹으로 이동해 노드를 하나 직접 선택하세요. 데스크톱에서는 먼저 시스템 프록시를 켜고, 모바일에서는 시스템 안내에 따라 VPN 권한을 허용하세요. 첫 테스트에서는 DNS, 규칙, TUN을 한꺼번에 바꾸지 마세요. 한 번에 하나씩 변경해야 결과를 비교하기 쉽습니다. 포트 사용 중 알림이 나오면 다른 프록시 프로세스를 종료하거나 로컬 수신 포트와 해당 포트를 사용하는 앱 설정을 명확히 조정하세요.
시스템 프록시 설정 방법 →먼저 클라이언트에서 노드를 테스트한 다음 프록시를 사용해야 하는 서비스를 열고 연결 화면에서 대상 도메인, 적용된 규칙, 최종 출구를 확인하세요. 이어서 직접 연결되어야 하는 서비스에도 접속해 설정과 일치하는지 비교합니다. 지연 시간 테스트에 성공해도 실제 앱에서의 연결은 별도로 확인해야 합니다. 브라우저만 되고 다른 앱은 실패한다면 트래픽 처리 범위를 다시 살펴보세요. 연결이 코어에 도달했는데도 계속 실패한다면 노드와 원격 서비스를 확인하세요.
노드 테스트 및 연결 확인 →# source & maintenance
Clash Meta는 프로젝트의 변천을 이해할 때 자주 쓰이는 이름이며, 현재 코어 프로젝트는 mihomo라는 이름을 사용합니다. 다운로드 사이트에서는 관련 링크와 설정 정보를 정리합니다. 코어 소스 코드, 클라이언트 릴리스 안내, 노드 서비스 상태는 각각 해당 프로젝트나 서비스 제공자의 정보를 확인하세요.
Clash Meta를 검색하면 이전 이름, 모바일 클라이언트 이름, mihomo 코어 문서가 함께 나오는 경우가 많습니다. 서로 생태계상 관련은 있지만 같은 설치 파일은 아닙니다. mihomo는 Clash 호환 설정 체계를 이어받아 규칙, 프로토콜, DNS 등의 기능을 발전시켰습니다. 이 관계를 이해하면 설정 필드 오류가 발생했을 때 데스크톱 앱 이름만 보지 않고 실제로 실행 중인 코어와 지원 범위를 먼저 확인할 수 있습니다.
프로토콜과 설정 필드의 동작은 프로젝트 문서를 기준으로 확인하세요. 오래된 온라인 가이드는 과거의 기본값을 사용하는 경우가 있으므로 설정 조각을 복사하기 전에 현재 환경에도 적용되는지 확인하고 되돌릴 수 있는 설정 사본을 보관하세요.
mihomo의 소스 코드, 커밋 기록, 이슈는 MetaCubeX의 공개 저장소에서 확인할 수 있습니다. 소스 공개는 구현과 변경 사항을 추적하는 데 도움이 되지만, GUI 클라이언트에는 자체 구독 관리, 서비스 프로세스, 설정 재정의 로직이 포함될 수 있습니다. 화면 조작 오류와 코어 파싱 오류는 따로 확인하세요. 제보할 때는 작업 순서, 시스템 환경, 민감 정보를 제거한 최소 설정을 함께 제공하는 편이 연결 실패 화면만 첨부하는 것보다 유용합니다.
문제 해결 로그에 도메인, 노드 주소, 구독 인증 정보가 포함될 수 있습니다. 공개 이슈를 등록하기 전에 민감한 내용을 삭제하고 재현에 꼭 필요한 설정 필드와 오류 정보만 남기세요.
GUI 클라이언트는 보통 구독 가져오기, 설정 전환, 시스템 프록시 설정, 연결 표시를 담당합니다. mihomo 코어는 불러온 설정에 따라 요청을 해석하고 규칙을 매칭해 연결을 만듭니다. 화면의 스위치가 설정 필드를 생성하거나 덮어쓸 수 있으므로 파일을 수정한 뒤에는 클라이언트가 변경 사항을 유지하는지 확인하세요. iOS 등의 플랫폼은 각기 다른 앱 통합 방식을 사용합니다. Clash 형식 지원만으로 코어 구현까지 완전히 같다고 단정할 수는 없습니다.
구독 서비스는 노드와 관련 설정을 제공하며 클라이언트와는 별개의 계층입니다. 노드 만료, 사용량 초과, 서버 장애는 구독 제공자에게 문의해야 하며 소프트웨어를 다시 설치해도 해결되지 않습니다.
클라이언트, 코어, 구독은 각각 따로 업데이트해야 합니다. 클라이언트 업데이트는 화면이나 권한 요구 사항을 바꿀 수 있고, 코어 업데이트는 프로토콜이나 설정 필드 동작에 영향을 줄 수 있으며, 구독 업데이트는 노드와 서비스 제공자 설정을 갱신합니다. 업데이트 전에 로컬 규칙과 필요한 설정을 저장하고 릴리스 안내를 읽으세요. 업데이트 후에는 첫 연결 절차에 따라 시스템 프록시, DNS, 규칙 적용을 다시 확인해 이전 설정의 잔여 문제를 새 프로그램 오류로 오해하지 않도록 하세요.
장기간 유지할 규칙은 변경 사항을 추적할 수 있는 재정의 방식으로 관리하세요. 전체 플랫폼 설치 절차는 준비 및 설치 문서에서 확인할 수 있습니다. 설정 파싱, 권한, 라우팅 문제는 설정 FAQ를 참고하세요.
# MetaCubeX / mihomo
아래 명령은 소스 코드 저장소를 복제하며 GUI 클라이언트를 설치하지 않습니다. 빌드, 실행, 라이선스 정보는 저장소 안내를 확인하세요.
mihomo 오픈소스 저장소 보기 ↗git clone https://github.com/MetaCubeX/mihomo.git# technical-notes
iOS에서 Clash 설정을 지원하는 클라이언트를 App Store에서 설치하고, 구독 링크·파일·QR 코드로 설정을 가져와 VPN을 켜는 전체 과정을 안내합니다.
기술 노트 읽기 →자주 쓰이는 구독 형식의 구조와 차이, 클라이언트별 지원 형식, 로컬에서 구독을 변환할 때 확인할 설정 필드와 보안 사항을 살펴봅니다.
기술 노트 읽기 →규칙 매칭 순서부터 살펴보고 세 가지 프록시 모드에서 트래픽이 실제로 이동하는 경로를 비교합니다. 웹 브라우징, 게임, 업무 등 상황별 모드 선택 방법도 안내합니다.
기술 노트 읽기 →