오픈 소스 Clash 생태계 기반
먼저 설정 출처, 아웃바운드 규칙, 트래픽 진입점을 구분하세요. 클라이언트는 조작 화면을 제공하고 코어는 설정을 실행합니다. 클라이언트마다 메뉴 이름은 다를 수 있지만 설정 원리는 서로 참고할 수 있습니다.
YAML은 키 이름과 계층 구조가 명확해 설정을 항목별로 찾아보기 쉽습니다.
규칙 매칭 결과와 실행 로그를 함께 확인해 실제 아웃바운드 경로를 점검하세요.
mode: rule
rules:
- DOMAIN-SUFFIX,apple.com,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXY규칙 기반 라우팅은 연결을 위에서 아래 순서로 검사하며, 처음 일치하는 규칙이 아웃바운드 정책을 결정합니다. 예시에서는 지정한 도메인을 먼저 직접 연결하고, 목적지 주소의 지역을 기준으로 판단한 뒤 나머지 연결은 MATCH로 처리합니다. PROXY는 기본 제공되는 만능 출구가 아니므로 설정에 실제 노드나 정책 그룹이 있어야 합니다. 구독을 가져온 후 규칙 모드를 선택하고 연결 기록을 열어 매칭된 규칙과 실제 출구를 확인하세요. 특정 사이트만 문제가 생기면 전체 설정을 전역 모드로 바꾸기보다 규칙 순서, 도메인 인식, DNS 결과부터 점검하세요.
https://example.com/sub?token=xxxx설정 가져오기 → 설정 선택 → 구독 업데이트
지원 형식은 클라이언트 안내를 확인하세요구독을 가져오면 서비스 제공자의 설정이 클라이언트에 다운로드됩니다. URL에 접근 인증 정보가 포함되는 경우가 많으므로 비공개 정보로 안전하게 보관하세요. URL 전체를 복사한 뒤 설정 또는 구독 페이지에서 원격 설정을 추가하고, 다운로드가 끝나면 해당 설정을 선택해야 코어에서 실제로 불러옵니다. 로컬 YAML은 파일 스냅샷이므로 제공자가 내용을 바꿔도 자동으로 업데이트되지 않습니다. Base64 노드 문자열도 완전한 설정 파일로 바로 사용할 수 있는 것은 아닙니다. 업데이트에 실패하면 먼저 응답 상태와 콘텐츠 형식을 확인하고 링크가 만료되지 않았는지 점검하세요. 형식 변환이 필요하다면 신뢰할 수 있는 로컬 도구를 우선 사용하고, 출처가 불분명한 서비스에 구독 정보를 넘기지 마세요.
시스템 프록시는 운영체제의 프록시 진입점을 설정합니다. 브라우저와 해당 설정을 따르는 앱에 적합하지만 모든 프로그램이 프록시를 사용한다고 보장할 수는 없습니다. TUN은 가상 네트워크 인터페이스로 트래픽을 처리해 더 넓은 범위를 다루지만 라우팅, DNS, 시스템 권한도 고려해야 합니다. 처음 설정할 때는 시스템 프록시가 작동하는지 먼저 확인하고, 여러 조건을 동시에 바꾸지 않도록 그다음에 TUN이 필요한지 판단하세요. 전환 전 다른 VPN이나 프록시 앱이 실행 중인지 확인하고, 로컬 네트워크, 가상 머신, 회사 네트워크의 라우팅 충돌도 살펴보세요. 두 방식은 규칙 모드를 결정하지 않습니다. 트래픽이 코어에 들어온 뒤에는 현재 설정에 따라 출구가 선택됩니다.
mihomo는 Clash 생태계의 프록시 코어로, 설정을 읽고 도메인을 조회하며 규칙을 매칭해 아웃바운드 연결을 만듭니다. 그래픽 클라이언트는 코어 바깥에서 구독 관리, 모드 전환, 메뉴 막대 메뉴, 권한 서비스 등을 제공합니다. 이름이 비슷한 클라이언트라도 사용하는 코어와 지원하는 설정 항목이 완전히 같다고 볼 수 없습니다. 문서를 참고할 때는 현재 클라이언트가 실제로 어떤 코어를 사용하는지 확인한 다음 해당 설정 옵션을 쓸 수 있는지 판단하세요. 인터페이스 업데이트와 코어 업데이트가 따로 배포되는 경우도 있습니다. 설정 파싱에 실패하면 화면 모양만 보고 호환성을 판단하지 말고 오류가 난 항목과 줄 번호부터 확인하세요.
플랫폼 및 설치 안내
먼저 운영체제와 프로세서 아키텍처를 확인한 뒤 알맞은 클라이언트를 선택하세요. 설치 파일이 실행된다고 해서 앱 설치만 완료된 것입니다. 연결을 사용하려면 유효한 설정, 사용할 수 있는 아웃바운드 노드, 올바른 트래픽 진입점도 필요합니다. 다운로드 페이지에서 플랫폼별 클라이언트, 설치 요구 사항, 보관 프로젝트를 확인할 수 있습니다. 처음부터 여러 클라이언트를 동시에 설치할 필요는 없습니다.
Clash Plus를 먼저 살펴보고 Clash Verge Rev, FlClash 등도 비교해 보세요. 설치 전에 시스템 아키텍처를 확인하고, 처음 실행할 때 혼합 포트가 다른 프로그램에서 사용 중인지 점검하세요. 우선 시스템 프록시로 연결을 확인하고, TUN이 필요하면 클라이언트 안내에 따라 서비스를 설치하거나 필요한 권한을 부여하세요.
브라우저는 연결되지만 특정 앱만 연결되지 않으면 해당 앱이 시스템 프록시를 사용하는지 먼저 확인하세요. 스토어 앱의 루프백 액세스 문제는 노드 오류와 다르므로 UWP 루프백 안내를 참고해 별도로 해결해야 합니다.
다운로드 페이지로 이동 Windows 클라이언트→‘이 Mac에 관하여’에서 Apple Silicon 또는 Intel을 확인한 뒤 알맞은 설치 파일을 선택하세요. 앱을 ‘응용 프로그램’ 폴더로 옮겨 실행하고, 필요에 따라 프록시 보조 서비스나 네트워크 권한을 설정하세요. 클라이언트마다 요청하는 권한이 다르므로 모든 앱에 시스템 확장이 필요하다고 미리 가정하지 마세요.
권한 요청 창이 나타나면 앱 이름과 출처, 실제 수행하려는 작업을 확인하세요. 권한을 거부한 뒤 복구해야 한다면 반복해서 재설치하기보다 시스템 설정의 개인정보 보호 및 보안 항목과 관련 네트워크 설정을 확인하세요.
다운로드 페이지로 이동 macOS 클라이언트→Clash Plus, Clash Meta for Android, FlClash 등에서 클라이언트를 선택할 수 있습니다. 먼저 기기 아키텍처와 설치 요구 사항을 확인하고 구독을 가져온 뒤 해당 설정을 선택하세요. 다음으로 시스템 VPN 연결 요청을 확인합니다. 이 권한은 기기의 트래픽 진입점을 만드는 데 쓰이며, 구독 서비스가 이미 사용 가능하다는 뜻은 아닙니다.
화면을 잠근 뒤 연결이 끊기면 배터리 최적화, 백그라운드 실행 제한, 다른 VPN의 사용 여부를 확인하세요. 제조사마다 설정 메뉴 위치가 다르므로 한 번에 하나씩 바꾸고 연결이 복구되는지 확인하는 것이 좋습니다.
다운로드 페이지로 이동 Android 클라이언트→다운로드 페이지에서 Clash Plus의 App Store 링크와 공식 사이트 clashplus.io를 확인할 수 있습니다. 설치 후 지원되는 구독 형식인지 확인하고, 구독 가져오기와 노드 선택, 시스템 VPN 설정 권한 부여를 진행하세요. 연결 아이콘이 표시되더라도 실제 접속을 테스트해 규칙과 출구가 올바른지 확인해야 합니다.
Wi-Fi에서 모바일 네트워크로 전환한 뒤 연결에 문제가 생기면 앱의 네트워크 접근 권한과 설정 상태부터 확인하세요. 클라이언트는 연결을 관리하며 구독 내용, 노드의 유효 기간, 서비스 범위는 설정 제공자가 결정합니다.
다운로드 페이지로 이동 iOS 클라이언트→데스크톱에서는 Clash Verge Rev와 FlClash를 확인하고 배포판에 맞는 패키지 형식을 선택하세요. 데스크톱 환경의 시스템 프록시, 터미널 프록시 환경 변수, TUN은 서로 다른 진입점입니다. 브라우저가 연결된다고 해서 명령줄 도구도 같은 설정을 사용한다고 볼 수는 없습니다.
서버나 라우터에서 사용하려면 mihomo 코어 안내를 추가로 확인하세요. 배포할 때는 수신 주소, 파일 권한, 서비스 관리, 방화벽을 각각 점검하고 로컬 전용 제어 인터페이스를 공용 네트워크에 노출하지 마세요.
다운로드 페이지로 이동 Linux 클라이언트→첫 연결 단계
‘설정을 불러올 수 있는지, 노드에 연결되는지, 앱에서 접속되는지’ 순서대로 확인하면 문제를 해당 단계로 좁힐 수 있습니다. 처음 설정할 때는 기본 포트와 규칙 모드를 유지하고 DNS 변경, 규칙 추가, 여러 트래픽 처리 방식의 동시 활성화는 서두르지 마세요. 아래 세 단계는 설치 후 점검 목록으로 활용할 수 있으며, 전체 가이드에서 각 단계의 조작 방법을 확인할 수 있습니다.
구독 또는 설정 메뉴에서 전체 URL을 추가하거나 이미 있는 로컬 YAML 파일을 선택하세요. 다운로드가 끝나면 해당 설정을 선택하고 파싱 결과를 확인합니다. 목록에 이름이 표시된다고 해서 설정이 정상적으로 로드된 것은 아닙니다. 항목 오류가 있으면 로그에 표시된 줄 번호를 먼저 확인하세요. 예시 URL은 형식 설명용이며 실제 구독을 대신할 수 없습니다.
일상적으로 사용할 때는 규칙 모드를 선택하고 해당 정책 그룹에서 사용할 수 있는 노드를 고르세요. 정책 그룹에서 선택한 노드는 이를 참조하는 규칙에만 영향을 주며 모든 트래픽을 바꾸지는 않습니다. 지연 시간 테스트는 특정 탐지 조건에서 연결 가능성을 확인하는 기능이지 다운로드 속도 측정이 아닙니다. 테스트에 실패하면 실제 접속 결과와 로그도 함께 살펴보세요.
데스크톱에서는 먼저 시스템 프록시를 사용하고, 모바일에서는 안내에 따라 VPN 설정을 허용하세요. 직접 연결될 것으로 예상되는 대상과 프록시를 사용할 대상으로 각각 접속해 보고 연결 기록에서 매칭된 규칙과 출구를 확인하세요. 새 연결 기록이 전혀 없다면 트래픽 진입점을 먼저 점검하세요. 기록이 생긴 뒤 오류가 발생한다면 DNS, 노드, 대상 네트워크를 계속 확인하세요.
원격 구독을 업데이트하면 직접 편집한 내용이 덮어써질 수 있습니다. 사용자 지정 규칙에는 클라이언트에서 지원하는 덮어쓰기 또는 병합 기능을 사용하세요. 변경 전에 기존 설정을 기록하고 문제가 생기면 검증된 상태로 되돌린 뒤 한 항목씩 다시 확인하세요. 여러 값을 한 번에 바꾸지 마세요.
프로젝트 관계 및 소스 코드
Clash는 규칙 기반 프록시 코어와 그 설정 방식으로 사용자 기반을 형성했고, 이후 여러 운영체제용 그래픽 클라이언트와 코어 파생 프로젝트, 설정 관리 도구가 등장했습니다. 지금 Clash를 검색하면 이름은 비슷하지만 유지 관리 상태가 서로 다른 여러 프로젝트를 볼 수 있습니다. 선택할 때는 아이콘이나 이름만으로 기능을 판단하지 말고 클라이언트, 사용 코어, 설정 형식을 각각 확인하세요.
이 페이지의 생태계 로고는 관련 프로젝트의 관계를 설명하기 위한 것입니다. 프로젝트들이 하나의 설치 패키지를 함께 배포하거나 제3자 프로젝트가 이 사이트를 인증한다는 뜻은 아닙니다. 다운로드 페이지에서는 현재 선택할 수 있는 클라이언트와 보관 프로젝트를 따로 표시해 기존 설정과의 호환성을 유지할지, 계속 관리되는 도구를 사용할지 판단할 수 있도록 했습니다.
mihomo는 Clash 생태계의 설정 및 규칙 기능을 이어받아 확장했습니다. 그래픽 클라이언트는 그 바깥에서 구독 설정, 트레이 메뉴, 연결 확인, 시스템 서비스 등을 제공할 수 있지만 이러한 인터페이스 기능이 모두 코어에 포함되는 것은 아닙니다. 구독 버튼이 작동하지 않는 문제는 클라이언트 관리 계층, 설정 파싱 오류는 코어에서 지원하는 항목, 시스템 프록시가 적용되지 않는 문제는 시스템 통합 계층과 관련될 수 있습니다.
오픈 소스 저장소에서 프로젝트 설명, 라이선스, 설정 문서, 공개된 문제 기록을 확인할 수 있습니다. mihomo는 GPL-3.0 라이선스를 사용하며 다른 클라이언트의 라이선스는 각 저장소의 안내를 확인하세요. 소스 코드를 확인한다고 해서 직접 빌드해야 하는 것은 아닙니다. 일반 사용자는 현재 문제와 관련된 문서와 릴리스 노트부터 읽는 편이 더 실용적입니다.
규칙, DNS 또는 코어 동작을 살펴보려면 프로젝트 저장소에서 시작하세요. 다음 명령은 소스 코드를 복제할 뿐 그래픽 클라이언트를 설치하거나 구독을 제공하지 않으며 네트워크 설정도 자동으로 바꾸지 않습니다.
git clone https://github.com/MetaCubeX/mihomo.gitLinux 펭귄 그래픽 출처: Font Awesome Tux, CC BY 4.0 라이선스. 이 사이트에서는 인라인 벡터로 표시합니다.
클라이언트 업데이트, 코어 업데이트, 구독 업데이트, 규칙 데이터 업데이트는 서로 다른 작업입니다. 구독을 업데이트하면 설정 제공자가 배포하는 내용이 바뀌고, 코어 업데이트는 설정 항목 지원과 실행 동작에 영향을 줄 수 있습니다. 규칙 데이터는 지역 또는 분류별 매칭에 사용됩니다. 업데이트 후 문제가 생기면 먼저 어느 부분을 업데이트했는지 기록하고 관련 안내를 확인하세요. 모든 변화를 막연히 ‘노드를 사용할 수 없음’으로 묶지 마세요.
클라이언트를 옮길 때는 기존 설정과 필요한 로컬 덮어쓰기 파일을 보관하고 새 클라이언트가 같은 규칙과 프로토콜을 지원하는지 확인하세요. 보관된 프로젝트가 실행된다고 해서 이후 시스템 변경에도 계속 대응할 수 있다는 뜻은 아닙니다. 실제 요구 사항, 유지 관리 상태, 알려진 문제를 고려해 계속 사용할지 판단하세요.
일반적으로는 적절한 수준의 로그를 유지하면 충분합니다. 문제를 찾을 때는 오류가 발생한 시간, 대상 유형, 매칭된 규칙, 오류 메시지를 기록한 다음 잠시 동안 로그 상세도를 높이세요. 공개적으로 도움을 요청하기 전에는 구독 URL, 노드 비밀번호, 액세스 토큰 등 비공개 정보를 삭제하고 문제를 재현하는 데 필요한 최소한의 설정만 공유하세요.
문제를 제대로 확인하려면 로컬 수신, DNS 조회, 규칙 선택, 원격 연결을 구분해야 합니다. 먼저 트래픽이 코어로 들어오는지 확인한 다음 규칙이 예상한 출구를 선택했는지, 마지막으로 노드와 대상 서비스에 문제가 없는지 점검하세요. 계층별로 확인하면 클라이언트를 반복해서 바꾸는 것보다 재현 가능한 원인을 찾기 쉽습니다. 자세한 예시는 사용 문서와 자주 묻는 질문에서 확인할 수 있습니다.
문제별 가이드
첫 연결을 완료한 뒤 실제 문제에 맞춰 더 자세히 살펴보세요. 설치 단계에서는 포트, 모드, 시스템 진입점을 확인하고 앱 호환 문제는 DNS와 네트워크 처리 방식을, 구독 가져오기 오류는 입력 형식을 먼저 확인하세요. 한 번에 검증 가능한 문제 하나만 다루고 변경 전후 차이를 기록하면 어떤 설정이 영향을 미쳤는지 파악하기 쉽습니다.
각 플랫폼에서 첫 실행 후 확인할 포트 사용 여부, 규칙 및 전역 모드 선택, 시스템 프록시 설정, 방화벽 허용을 정리해 초보자가 자주 겪는 문제를 예방합니다.
글 읽기 →가상 주소 풀 할당과 도메인 역조회부터 살펴보고, TUN 모드에서 Fake-IP가 갖는 장점, fake-ip-filter 작성법과 자주 발생하는 호환성 문제를 분석합니다.
글 읽기 →원격 구독, 로컬 설정 파일, Base64 노드 문자열의 차이를 비교하고 가져오기 메뉴, 자동 업데이트 간격, 형식이 호환되지 않을 때의 변환 방법을 설명합니다.
글 읽기 →연결 실패: 포트 수신과 시스템 프록시를 먼저 확인한 다음 오류 메시지를 바탕으로 원인을 찾으세요. 자주 묻는 질문 보기 →
개념이 헷갈릴 때: 설정을 바꾸기 전에 노드, 정책 그룹, 규칙, DNS를 구분하세요. 용어집 보기 →
플랫폼 간 이전: 시스템 권한과 트래픽 진입점을 확인하고 이전 기기의 스위치 상태를 그대로 따라 하지 마세요. 사용 문서 보기 →