하나의 설정 파일로 연결마다 서로 다른 출구를 사용할 수 있습니다. 먼저 mode를 rule로 설정한 다음, 구체적인 규칙부터 넓은 규칙 순서로 rules를 작성하세요. 도메인 접미사 규칙은 관련 사이트를 묶을 때, IP 주소 규칙은 특정 대상 대역을 지정할 때 유용합니다. 마지막에는 나머지 연결을 처리하도록 MATCH를 둡니다. 규칙 하나가 일치하면 지정된 정책을 적용하며, 뒤에 있는 같은 유형의 규칙을 계속 확인하지 않습니다. 전역 모드와 달리 규칙 모드에서는 연결 유형별로 처리할 수 있습니다. 분기가 예상과 다르면 노드를 바로 바꾸기보다 연결 기록에서 일치한 규칙을 확인하고 순서를 조정하세요.
mode: rule
rules:
- DOMAIN-SUFFIX,github.com,Proxy
- GEOIP,CN,DIRECT
- MATCH,Proxy프록시 그룹을 사용하면 규칙의 대상과 실제 노드를 분리할 수 있습니다. 규칙은 변경이 적은 그룹 이름만 가리키므로 노드를 바꿔도 분기 목록을 일일이 수정할 필요가 없습니다. select는 직접 선택할 때, url-test는 지정한 테스트 주소의 결과에 따라 후보를 자동 선택할 때 적합합니다. 두 그룹을 중첩하면 바깥 그룹에서 수동으로 제어하고 안쪽 그룹에서 자동으로 노드를 선택할 수 있습니다. 예시의 노드A와 노드B는 실제로 등록된 노드 이름으로 바꿔야 합니다. 테스트 결과는 특정 요청의 응답을 나타내며 파일 다운로드 속도와는 다릅니다. 후보를 비교할 때는 대상 서비스, 연결 안정성, 구독 데이터 제한도 함께 고려하세요.
proxy-groups:
- name: Proxy
type: select
proxies: [Auto, DIRECT]
- name: Auto
type: url-test
proxies: [노드A, 노드B]
url: https://www.gstatic.com/generate_204
interval: 300클라이언트의 구독 설정과 코어의 proxy-providers는 서로 다른 계층입니다. 클라이언트 구독은 보통 전체 설정을 업데이트하고, 코어의 provider는 설정에 따라 노드 목록을 가져온 뒤 프록시 그룹의 use로 참조합니다. 먼저 서비스에서 전체 설정을 제공하는지 노드 목록만 제공하는지 확인한 후 가져올 위치를 정하세요. interval은 가져오기 간격을 초 단위로 지정하며 연결 테스트 주기를 뜻하지 않습니다. 계속 사용할 사용자 규칙은 클라이언트가 지원하는 오버라이드나 병합 위치에 저장해 업데이트로 덮어쓰이지 않게 하세요. 구독 주소에는 접근 정보가 포함될 수 있습니다. 로그나 스크린샷을 공유하기 전에는 전체 주소를 가리고, 신뢰할 수 없는 변환 서비스에 입력하지 마세요.
proxy-providers:
local:
type: file
path: ./providers/local.yaml
proxy-groups:
- name: Proxy
type: select
use:
- localDNS는 도메인 이름을 IP 주소로 변환하고, TUN은 가상 네트워크 인터페이스를 통해 트래픽을 연결합니다. 두 기능의 역할은 다릅니다. 시스템 프록시만 켜면 설정을 읽지 않는 일부 프로그램은 직접 연결될 수 있으므로, 이런 연결까지 처리해야 할 때 TUN 사용을 검토하세요. 예시에는 흔히 쓰이는 필드 조합을 보여 주며 모든 운영체제에 그대로 적용할 수 있다는 뜻은 아닙니다. 활성화하기 전에 서비스 권한과 라우팅 설정을 확인하고 기존 VPN과 충돌하는지 살펴보세요. 그런 다음 dns-hijack과 DNS 처리 정책을 점검합니다. 웹사이트는 열리지만 앱 연결이 실패한다면 연결 기록과 DNS 로그를 함께 확인하세요. 브라우저만 보고 모든 트래픽이 연결됐다고 판단하지 마세요.
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
- https://dns.alidns.com/dns-query
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53운영체제를 선택한 다음 CPU 아키텍처와 설치 파일 형식을 확인하세요. 다운로드 페이지에서 클라이언트, 시스템 요구 사항, 설치 경로를 한눈에 볼 수 있습니다. 홈페이지는 플랫폼 안내만 제공하며 설치 파일을 모아 보여 주지는 않습니다.
데스크톱에서 사용할 클라이언트는 먼저 Clash Plus를 살펴본 뒤 Clash Verge Rev, FlClash, Clash Nyanpasu의 설정 관리 방식을 비교해 보세요. 다운로드하기 전에 시스템 설정의 ‘시스템 종류’에서 CPU 아키텍처를 확인하세요. 컴퓨터 브랜드만 보고 설치 파일을 고르면 안 됩니다.
처음 실행할 때 기존 구독을 가져와 설정을 선택한 뒤 시스템 프록시를 켜세요. TUN이 필요하다면 선택한 클라이언트의 안내에 따라 서비스 구성 요소를 설치하거나 활성화하세요. 시작 시 자동 실행과 프록시 자동 활성화는 보통 별개의 설정입니다. 각각 확인하고, 종료한 뒤 시스템 프록시가 원래대로 복구됐는지도 살펴보세요.
다운로드 페이지에서 Windows 클라이언트 보기먼저 ‘이 Mac에 관하여’를 열고 칩 정보를 확인해 Apple Silicon 또는 Intel용 설치 파일을 선택하세요. 다운로드 페이지에서 Clash Plus, Clash Verge Rev, FlClash를 비교할 수 있습니다. 유지 관리가 중단된 ClashX Meta는 보관 프로젝트로 별도 표시해 현재 유지 관리 상태를 확인할 수 있습니다.
설치한 클라이언트를 응용 프로그램 폴더로 옮긴 다음 처음 실행하고 필요한 시스템 권한을 허용하세요. 메뉴 막대형과 창형 클라이언트는 실행 경로가 다르지만, 설정 가져오기, 프록시 그룹 선택, 연결 방식 활성화 순서는 같습니다. 시스템에서 차단 알림이 표시되면 출처와 권한 안내를 먼저 확인하고 시스템 보안 기능을 바로 끄지 마세요.
다운로드 페이지에서 macOS 클라이언트 보기휴대폰과 태블릿에서는 필요에 따라 Clash Plus, Clash Meta for Android, FlClash, Surfboard를 선택할 수 있습니다. 설치 파일은 기기 아키텍처와 일치해야 합니다. 확실하지 않다면 기기 정보와 다운로드 페이지의 안내를 먼저 확인하고, 아키텍처가 다른 파일을 반복해서 설치하며 시험하지 마세요.
처음 연결할 때는 보통 시스템 VPN 권한이 필요하며, 다른 VPN 앱이 동시에 영향을 줄 수도 있습니다. 가져오기가 끝나면 설정을 선택하고 연결을 시작해야 합니다. 구독 목록에 표시된 것만으로는 연결되지 않습니다. 화면을 잠근 뒤 연결이 끊긴다면 배터리 최적화, 백그라운드 실행, 네트워크 전환 설정을 확인하세요. 제조사마다 설정 이름은 다를 수 있습니다.
다운로드 페이지에서 Android 클라이언트 보기iPhone과 iPad 사용자는 다운로드 페이지의 Clash Plus 앱 스토어 링크를 이용할 수 있습니다. 제품 정보는 공식 사이트 clashplus.io에서도 확인할 수 있습니다. 설치 방법과 시스템 호환성은 현재 스토어 안내를 따르세요. 구독 서비스 이용과 클라이언트 설치는 별도로 진행해야 합니다.
사용 가능한 구독이나 로컬 설정을 준비한 뒤 가져오기와 VPN 권한 설정을 진행하세요. 설정은 표시되지만 연결되지 않는다면 구독 만료 여부, 노드 상태, 다른 VPN 연결 여부를 먼저 확인하세요. 클라이언트를 설치해도 노드가 자동으로 추가되지는 않습니다. 기존 구독도 직접 선택하고 활성화해야 합니다.
다운로드 페이지에서 iOS 클라이언트 보기데스크톱 환경에서는 Clash Verge Rev와 FlClash를 살펴보고 배포판에 맞는 DEB, RPM 등 지원되는 설치 형식을 선택하세요. 서버, 라우터, 보조 라우터에서는 다운로드 페이지의 코어 항목을 확인하고 CPU 아키텍처와 실행 환경에 맞는 mihomo를 선택할 수 있습니다.
그래픽 인터페이스가 실행된다고 시스템 트래픽까지 연결된 것은 아닙니다. 데스크톱 프록시 설정, 터미널 환경 변수, TUN 라우팅은 각각 다른 경로이므로 사용 목적에 맞춰 확인해야 합니다. 코어를 단독 실행한다면 설정 디렉터리, 파일 권한, 서비스 실행도 직접 관리해야 합니다. 처음 배포할 때는 먼저 포그라운드에서 실행해 오류를 확인한 뒤 서비스 관리자를 통해 유지하세요.
다운로드 페이지에서 Linux 클라이언트 보기인터페이스, 코어, 설정 출처를 구분하면 클라이언트 선택과 문제 해결이 쉬워집니다. 이 사이트에서는 다운로드 경로와 중국어 설정 안내를 정리합니다. 각 클라이언트는 해당 프로젝트에서 관리하며 지원 기능과 업데이트 주기는 서로 다릅니다.
Clash 생태계에서는 규칙 기반 프록시를 중심으로 여러 코어와 그래픽 클라이언트가 발전했습니다. 초기 설정 규약은 지금까지 이어져 여러 프로젝트에서 비슷한 필드 이름을 볼 수 있습니다. Clash Meta는 이후 mihomo라는 이름으로 발전했습니다. 익숙한 Clash 이름이 보여도 모든 제품이 같은 프로토콜과 필드를 지원한다고 가정하지 말고 실제 사용 중인 코어를 확인하세요. 특히 이전 설정을 옮길 때는 파싱 성공만으로 충분하지 않습니다. 프록시 그룹 참조, 규칙 데이터, DNS 동작도 점검해야 합니다.
그래픽 클라이언트는 설정 목록, 프록시 선택, 로그, 시스템 연결 설정을 표시하고 코어는 연결과 트래픽 분기를 실행합니다. 두 구성 요소의 업데이트 시점은 다를 수 있으므로, 클라이언트 화면에 옵션이 있다고 해서 모든 코어 기능이 지원된다고 볼 수는 없습니다. 필드를 인식하지 못하거나 동작이 다르면 현재 클라이언트의 코어 안내와 프로젝트 문서를 확인한 뒤 설정을 수정할지 클라이언트를 업데이트할지 결정하세요. 이 사이트의 설정 안내는 mihomo에서 자주 쓰이는 필드를 중심으로 하며, 서로 다른 코어의 문법을 하나의 공통 규격처럼 다루지 않습니다.
mihomo의 코드, 프로젝트 안내, 이슈 논의는 공개 저장소에서 확인할 수 있습니다. 오픈 소스의 실질적인 장점은 필드 정의와 변경 기록을 살펴보고 재현 가능한 문제를 구현 내용과 연결해 추적할 수 있다는 점입니다. 다운로드 페이지의 짧은 설명에만 의존하지 않아도 됩니다. 규칙 유형이나 DNS 옵션을 확인하려면 먼저 공식 문서의 적용 범위를 살펴보고 저장소의 논의로 세부 조건을 확인하세요. 이슈를 등록할 때 운영체제, 연결 방식, 최소 재현 설정, 관련 로그를 준비하면 재현 가능한 현상에 집중해 논의할 수 있습니다.
저장소를 복제하면 소스 코드와 문서를 살펴볼 수 있지만 그래픽 클라이언트가 설치되는 것은 아닙니다. 일상적인 연결만 필요하다면 다운로드 페이지를 이용하세요. 코어를 연구하거나 변경 내역을 추적하고 직접 빌드하려면 오른쪽 명령으로 소스 코드를 가져오면 됩니다. 최소 설정을 공유하기 전 구독 주소, 계정 정보, 노드 인증 정보는 삭제하고 필드 구조와 문제를 재현하는 규칙만 남기세요. 공개된 논의에 개인 설정 파일 전체를 붙여 넣지 마세요.
클라이언트 업데이트는 인터페이스와 연동 기능을 바꾸고, 코어 업데이트는 프로토콜과 설정 동작에 영향을 주며, 구독 새로고침은 서비스 제공자가 반환하는 내용을 갱신합니다. 서로 다른 작업입니다. 구독 업데이트가 성공해도 설치 파일 호환성 문제는 해결되지 않으며, 클라이언트를 업데이트해도 구독 기간이 자동 연장되지 않습니다. 문제를 진단하기 전에 어떤 항목을 업데이트했는지 기록한 다음 네트워크 요청, 형식 파싱, 권한 문제를 확인하세요. 계속 사용할 사용자 규칙은 별도로 백업하고 구독을 새로고침한 뒤에도 오버라이드가 적용되는지 점검하세요.
업데이트하기 전에 현재 사용 가능한 설정과 필요한 옵션을 보관하세요. 업데이트 후에는 기본 연결을 확인한 다음 사용자 지정 분기, 자동 선택 프록시 그룹, DNS를 점검하세요. 보관용 클라이언트는 다운로드 페이지에 유지 관리 상태를 명확히 표시해 이전 환경을 옮길 때 구분할 수 있습니다. 새로 설치할 때는 현재도 유지 관리 중인 옵션을 우선 비교하는 것이 좋습니다. 홈페이지에는 특정 릴리스 번호를 고정해서 보여 주지 않습니다. 설치 경로와 제품 정보는 다운로드 페이지에서 확인할 수 있어 여러 페이지를 오가며 비교할 필요가 없습니다.
연결 스위치가 켜졌다는 것은 클라이언트가 실행 중이라는 뜻일 뿐, 대상 앱이 예상한 출구를 사용한다는 증거는 아닙니다. 먼저 확실한 대상 사이트를 열고 연결 목록에서 도메인, 일치한 규칙, 선택된 정책을 확인하세요. 다음으로 시스템 프록시를 사용하지 않는 앱을 테스트해 TUN이 필요한지 살펴보세요. 브라우저는 정상인데 다른 앱이 실패하면 연결 경로를 먼저 확인하고, 모두 실패한다면 노드와 기본 네트워크를 점검하세요. 한 번에 하나씩만 바꾸면 DNS, 노드, 규칙 문제를 구분하기 쉽습니다.
자세한 사용 방법은 사용 문서부터 확인하세요. 필드 구조를 찾으려면 설정 파일 레퍼런스로 바로 이동할 수 있습니다. 구독 변환은 형식과 서비스의 신뢰성을 고려해야 하므로, 진행하기 전에 구독 변환 안내를 읽어 보세요. 부팅 후 자동 연결되지 않는다면 시작 시 자동 실행과 프록시 시작 설정을 각각 확인하세요. 두 옵션을 같은 상태로 취급하지 마세요.
노드 선택, 여러 설정 관리, 라우터 배포 등 구체적인 문제에 필요한 사용 배경을 설명합니다. 기본 가져오기 절차는 사용 문서에서 다루고, 이 글에서는 선택 기준과 적용 범위, 문제 해결 순서를 중점적으로 안내합니다.
메인 라우터에서 직접 실행, 보조 라우터를 게이트웨이로 사용, 투명 프록시 구성 등 세 가지 배포 방식을 비교하고 하드웨어 아키텍처 선택, 코어 파일 배치, LAN 기기 연결의 기본 원칙을 설명합니다.
배포 방식 읽기 →Profile과 구독, 로컬 YAML의 관계를 설명합니다. 여러 설정을 함께 사용할 때 이름 지정, 전환, 백업하는 방법을 살펴보고 다음 업데이트에서 변경 사항이 덮어써지는 상황을 방지합니다.
설정 관리 방법 읽기 →지연 시간의 안정성, 트래픽 배수, 대상 서비스의 지역, 프로토콜 유형을 기준으로 일상적인 웹 탐색, 스트리밍, 개발 환경에 적합한 노드를 고르는 순서를 안내합니다.
노드 선택 순서 읽기 →