Windows
기기 아키텍처와 시스템 요구 사항을 확인한 다음 클라이언트 카드에서 설치 파일을 선택하세요. 설치 후 ‘설정’에서 구독을 가져오고 시스템 프록시가 켜져 있는지 확인합니다. 일부 앱이 계속 직접 연결된다면 시스템 프록시 설정을 따르는 앱인지 먼저 확인하세요.
Windows 다운로드 →설정 파일, 수신 대기 포트, 분기 규칙은 각각 다른 트래픽을 처리합니다. 문제가 어느 단계에서 생겼는지 먼저 확인한 뒤 해당 설정만 바꾸면, 노드를 계속 바꾸는 것보다 원인을 찾기 쉽습니다.
노드, 정책 그룹, 규칙을 처음부터 구성할 때는 들여쓰기와 필드명이 코어 문법에 맞아야 합니다. 설정을 불러오지 못한다고 구독 링크가 반드시 잘못된 것은 아닙니다. 먼저 클라이언트의 설정 오류 메시지를 확인하고 파일 구조를 살펴보세요.
설정에서 mixed-port를 지정했는데 시스템 프록시가 다른 포트를 가리키면 브라우저가 프록시를 거치지 않고 연결하거나 오류가 날 수 있습니다. 수신 대기 포트를 바꿨다면 운영체제의 프록시 주소도 함께 확인하세요.
규칙 모드는 위에서부터 순서대로 요청을 확인합니다. 앞쪽의 범위가 넓은 규칙이 요청을 먼저 처리할 수 있습니다. 규칙이 가리키는 정책 그룹 이름과 클라이언트가 현재 규칙 모드인지도 확인하세요.
일상적인 켜기·끄기는 인터페이스에서, 재사용할 규칙은 설정 파일에서 관리합니다. 두 가지를 함께 활용하세요. 먼저 클라이언트에서 연결을 확인한 뒤 필요한 YAML 설정만 수정하고, 처음부터 모든 옵션을 한꺼번에 바꾸지는 마세요.
서비스 제공자가 안내한 구독 주소를 붙여 넣고 설정이 정상적으로 로드됐는지 확인한 다음 ‘프록시’에서 정책 그룹을 선택하세요. 가져오기에 성공했다는 것은 클라이언트가 설정을 읽었다는 뜻일 뿐, 시스템 트래픽이 프록시를 통과한다는 의미는 아닙니다.
먼저 설정의 혼합 포트는 그대로 두고 클라이언트에서 시스템 프록시를 켜세요. 다른 프로그램이 포트를 사용 중이라면 포트를 변경한 뒤 프록시 주소도 함께 업데이트해야 클라이언트와 시스템의 포트가 일치합니다.
규칙 모드로 전환한 뒤 연결 기록에서 대상 도메인에 어떤 규칙이 적용됐고 어느 정책 그룹으로 연결됐는지 확인하세요. 특정 앱에만 트래픽이 표시되지 않을 때 TUN 모드 사용을 검토하면 됩니다.
mixed-port: 7890
mode: rule
proxy-groups:
- name: 직접 선택
type: select
proxies:
- DIRECT왼쪽에서 주제를 선택해 구체적인 설정 방법을 확인하세요. 아래 예시는 필드 간 관계를 보여 주며, 실제 노드와 구독 내용은 사용 중인 설정을 기준으로 해야 합니다.
클라이언트의 ‘설정’ 탭에서 구독 주소를 붙여 넣고 가져오기를 실행하세요. 설정이 목록에 표시되면 현재 설정으로 지정합니다. 일반적인 전체 YAML에는 노드, 정책 그룹, 규칙이 함께 포함됩니다. 노드 목록만 제공하는 링크라면 서비스 제공자에게 Clash 호환 형식이 있는지 문의해야 할 수 있습니다. 구독을 업데이트하기 전에 현재 선택된 설정을 기록해 두고, 업데이트 후 정책 그룹이 정상적으로 표시되는지 확인하세요. 구독 주소는 비공개 정보이므로 로그 캡처나 공개 문의 게시물에 올리지 마세요. 설정을 가져온 다음 시스템 프록시를 켜면 설정 문제와 네트워크 트래픽 처리 문제를 따로 점검할 수 있습니다.
설정 → 구독 링크 가져오기 → 현재 설정으로 지정
프록시 → 정책 그룹 선택규칙 모드는 위에서 아래로 요청을 확인하고, 일치하는 규칙을 찾으면 해당 정책 그룹에서 처리합니다. 도메인 규칙은 특정 사이트에, IP 규칙은 해석된 주소에 적용됩니다. 마지막 기본 규칙은 앞에서 일치하지 않은 요청을 처리합니다. 수정하기 전에 정책 그룹 이름이 실제로 존재하는지 확인하고, 범위가 좁은 규칙을 넓은 규칙보다 위에 배치하세요. 문제를 잠시 확인할 때는 전역 모드와 결과를 비교할 수 있지만, 평소에는 규칙 모드로 되돌려야 합니다. 웹페이지가 열리는지만 보는 것보다 클라이언트 연결 기록에서 실제 규칙 적용 결과를 확인하는 편이 정확합니다.
mode: rule
rules:
- DOMAIN-SUFFIX,example.com,직접 선택
- MATCH,DIRECT규칙에는 구체적인 노드 대신 정책 그룹 이름을 지정합니다. select는 사용자가 직접 출구를 선택하고, url-test는 주기적으로 테스트해 사용 가능한 후보를 고르며, fallback은 후보 순서에 따라 다음 항목으로 전환합니다. 먼저 수동 선택 그룹으로 연결을 확인한 다음 자동 선택을 고려하세요. 그래야 구독, 규칙, 테스트 주소 문제를 구분하기 쉽습니다. 그룹 이름을 바꾸면 해당 그룹을 참조하는 규칙도 함께 수정해야 합니다. 그룹 안에서 다른 그룹을 참조하는 경우에도 이름이 일치하는지 확인하세요. 전체 매개변수 설명은 고급 설정 가이드에서 확인할 수 있습니다.
proxy-groups:
- name: 직접 선택
type: select
proxies:
- DIRECT시스템 프록시는 시스템 프록시 설정을 따르는 프로그램에서 주로 사용됩니다. 일부 앱은 자체적으로 연결을 만들어 이 경로를 거치지 않습니다. TUN은 가상 네트워크 인터페이스를 통해 더 많은 트래픽을 처리하며, 사용하려면 보통 운영체제 권한이 필요합니다. 먼저 시스템 프록시로 기본 연결을 확인한 뒤, 실제 앱 사용에 필요할 때 TUN을 켜세요. 로컬 네트워크, 다른 VPN, 방화벽 사이의 라우팅 관계도 확인해야 합니다. TUN을 끈 뒤 앱이 정상화된다면 구독을 바로 바꾸기보다 DNS와 라우팅 설정부터 살펴보세요. 플랫폼별 권한 화면은 현재 클라이언트의 안내를 따르세요.
시스템 프록시 → 기본 연결
TUN 모드 → 필요할 때 켜기
확인 → 권한 / 라우팅 / DNS도메인 규칙이 예상대로 작동하는지는 클라이언트가 인식하는 도메인과 DNS 응답에 영향을 받습니다. DNS 재정의는 코어가 사용할 DNS 해석 방식을 지정하고, Fake-IP는 연결을 처리하기 위한 가상 IP를 도메인에 할당합니다. 변경하기 전에 현재 설정을 저장하고 시스템 DNS, 클라이언트 DNS, TUN 상태를 각각 기록하세요. 한 번에 하나만 변경한 뒤 로그와 연결 기록을 확인합니다. LAN 도메인, 내부 서비스, 실제 IP에 의존하는 앱은 별도 설정이 필요할 수 있습니다. 복사한 DNS 설정을 전체 설정 파일에 그대로 덮어쓰지 말고, 기존 규칙과의 관계부터 확인하세요.
dns:
enable: true
enhanced-mode: fake-ip외부 제어 인터페이스는 클라이언트 UI나 별도 패널이 코어 상태를 확인하고 정책 그룹을 전환할 때 사용합니다. 프록시 트래픽을 받는 수신 대기 포트와는 다릅니다. 로컬에서만 사용할 경우 루프백 주소에 바인딩하는 것이 안전합니다. LAN에서 접근하려면 수신 주소, 접근 제한, 기기 간 네트워크 경계를 함께 고려해야 하며 공개 예시를 그대로 복사해서는 안 됩니다. 패널 연결에 실패하면 코어가 실행 중인지, 제어 인터페이스 주소가 올바른지, 접근 인증 정보가 일치하는지 각각 확인하세요. 패널을 사용할 수 없어도 프록시는 작동할 수 있으므로, 패널 오류를 구독 연결 실패로 오해하지 마세요.
external-controller: 127.0.0.1:9090
secret: "your-password"매개변수별 설명이 필요하면 고급 설정 가이드 →를 확인하세요. 규칙 세트, 정책 그룹, DNS, TUN, 로컬 재정의를 각각 다루므로 첫 실행 때 전부 설정할 필요는 없습니다.
먼저 운영체제를 선택한 다음 다운로드 페이지에서 같은 플랫폼의 클라이언트를 비교하세요. 설치 파일 형식, CPU 아키텍처, 권한 요구 사항은 대상 기기에 맞춰 확인해야 합니다. 코어만 필요한 서버나 라우터 사용자는 다운로드 페이지의 mihomo 섹션을 확인하세요.
기기 아키텍처와 시스템 요구 사항을 확인한 다음 클라이언트 카드에서 설치 파일을 선택하세요. 설치 후 ‘설정’에서 구독을 가져오고 시스템 프록시가 켜져 있는지 확인합니다. 일부 앱이 계속 직접 연결된다면 시스템 프록시 설정을 따르는 앱인지 먼저 확인하세요.
Windows 다운로드 →Apple Silicon과 Intel 기기에 맞는 설치 파일을 선택하세요. 클라이언트를 처음 실행할 때 시스템 안내에 따라 권한을 허용합니다. 메뉴 막대에 연결됨으로 표시되는데도 브라우저가 프록시를 사용하지 않는다면 클라이언트에서 현재 설정과 시스템 프록시 상태를 확인하세요.
macOS 다운로드 →설정을 가져온 뒤 시스템 팝업에 따라 VpnService 권한을 허용해야 클라이언트가 기기에 VPN 인터페이스를 만들 수 있습니다. 화면을 잠근 뒤 연결이 자주 끊긴다면 구독을 반복해서 삭제하지 말고 배터리 최적화, 자동 시작, 백그라운드 실행 권한을 확인하세요.
Android 다운로드 →다운로드 페이지에서 Clash Plus의 App Store 페이지로 이동하세요. 설치 후 앱 안내에 따라 설정을 가져오고, 처음 연결할 때 시스템 VPN 권한을 허용합니다. 규칙이나 정책 그룹을 바꾸려면 클라이언트 화면에서 설정하세요.
iOS 다운로드 →데스크톱 사용자는 GUI 클라이언트의 배포 패키지 형식을 비교하고, 서버나 라우터 사용자는 독립 코어를 확인하세요. 설치 전에 배포판, 프로세서 아키텍처, 실행 방식을 확인하고 설정 파일을 읽고 쓸 수 있는 경로를 준비하세요.
Linux 다운로드 →하나의 구독이 모든 클라이언트에서 작동하는 것은 아닙니다. 먼저 서비스 제공자가 제공하는 설정 형식을 확인하고, 대상 클라이언트가 해당 프로토콜과 규칙 문법을 지원하는지 살펴보세요. 기기를 바꿀 때는 해당 기기의 네트워크 권한과 시스템 프록시 설정도 다시 확인해야 합니다.
Clash는 규칙 기반 프록시 도구 생태계를 가리키는 이름입니다. GUI 클라이언트는 설정 가져오기, 전환, 연결 확인을 위한 인터페이스를 제공하고, 코어는 설정을 해석하고 연결을 만들며 규칙을 실행합니다. 설치 파일을 선택할 때는 운영체제를 확인한 뒤 코어가 지원하는 설정 문법을 살펴보세요.
기존 Clash, Clash Meta, 이후의 mihomo는 각각 유지 관리 단계가 다릅니다. 화면에 비슷한 이름이 표시되더라도 같은 코어를 사용한다고 볼 수는 없습니다. 새로운 프로토콜, 규칙 유형, DNS 매개변수는 특정 코어에서만 지원될 수 있습니다. 설정을 불러오는 중 오류가 발생하면 앱 이름만으로 호환성을 판단하지 말고, 클라이언트에 표시된 코어와 구독에 사용된 문법을 먼저 확인하세요.
mihomo는 오픈 소스 코어로 공개된 소스 코드와 라이선스 정보를 제공합니다. GPL-3.0은 소프트웨어의 사용, 수정, 재배포 조건을 설명하며 노드 서비스 제공을 보장하지 않습니다. GUI 클라이언트를 선택할 때는 해당 클라이언트 프로젝트의 안내도 별도로 확인하세요. 코어가 오픈 소스라는 사실과 GUI 클라이언트의 유지 관리 상태는 별개의 문제입니다.
클라이언트는 설정을 읽고 상태를 표시하며, 구독 내용은 일반적으로 사용 중인 서비스 제공자가 관리합니다. 구독은 가져왔지만 노드를 사용할 수 없다면 설정 업데이트 시각, 정책 그룹 옵션, 연결 기록을 확인하세요. 클라이언트 설치에 실패했다면 패키지 형식과 시스템 요구 사항을 점검해야 합니다. 두 문제를 구분하면 해결 과정을 더 명확하게 정리할 수 있습니다.
클라이언트를 업데이트하기 전에 사용 중인 설정과 주요 로컬 재정의를 기록해 두세요. 업데이트 후에는 먼저 코어가 시작되는지 확인하고, 구독, 정책 그룹, 규칙 모드, 시스템 프록시를 점검합니다. 코어를 바꾸거나 유지 관리가 오래 중단된 버전으로 이동했다면 기존 설정의 규칙 제공자, DNS, TUN 필드를 특히 확인하세요. 기존 설정이 항상 호환된다고 가정하지 마세요.
git clone https://github.com/MetaCubeX/mihomo.git명령 복사는 공개 소스 코드를 로컬에서 확인할 때만 사용하며 GUI 클라이언트 설치에는 필요하지 않습니다. 일반 사용자는 설치 파일 페이지에서 기기에 맞는 클라이언트를 선택하면 됩니다. 규칙이나 DNS를 수정해야 한다면 고급 설정 가이드를 참고해 항목별로 설정하세요.
설정 로드, 트래픽 처리, 규칙 적용 순서로 점검하세요. 한 번에 하나의 설정만 변경해야 어떤 변경이 연결에 영향을 줬는지 파악하기 쉽습니다.
가져오기는 설정을 불러오는 단계일 뿐입니다. 해당 설정이 현재 설정으로 지정됐는지 확인한 다음 규칙 모드와 정책 그룹을 선택하고 시스템 프록시를 켜세요. 이어서 연결 기록에 브라우저 요청이 표시되는지 확인합니다. 기록이 없다면 시스템 프록시 스위치와 포트를 먼저 점검하세요. 가이드에 따라 차례로 확인하기 →
일상적인 사용에는 설정의 규칙에 따라 요청을 처리하는 규칙 모드를 선택하세요. 전역 모드는 문제를 비교해 볼 때 잠시 사용할 수 있습니다. 전역 모드에서는 정상인데 규칙 모드에서 예상대로 작동하지 않는다면 규칙 순서와 정책 그룹 이름을 확인하세요. 테스트가 끝나면 원하는 모드로 되돌리세요. 모드 전환 방법 보기 →
새 포트를 다른 프로그램이 사용 중인지 확인하고 운영체제나 앱의 프록시 주소가 이전 포트를 계속 가리키는지도 살펴보세요. 설정 파일을 수정한 뒤에는 클라이언트를 다시 로드해야 합니다. YAML만 바꾸고 시스템 프록시를 업데이트하지 않으면 두 설정이 일치하지 않습니다. 연결 점검 단계로 돌아가기 →
먼저 시스템 프록시로 기본 연결을 확인하세요. 대상 앱이 시스템 프록시를 따르지 않고 더 많은 트래픽을 처리해야 하는 경우에만 클라이언트 안내에 따라 TUN 사용에 필요한 시스템 권한을 허용하세요. 켠 뒤 LAN 접근에 문제가 생기면 라우팅과 DNS 설정을 각각 확인합니다. TUN 설정 안내 보기 →
아래 글은 게시일 순으로 정리했습니다. 구독 형식, Android 백그라운드 연결, 코어 선택 등 첫 설정 후 자주 이어지는 문제를 다룹니다.
전체 YAML 설정, Base64 노드 목록, 단일 노드 공유 링크의 차이를 알아보고, 같은 주소를 클라이언트마다 다르게 가져오는 이유와 변환 과정에서 누락될 수 있는 필드를 확인하세요.
글 읽기 →화면을 잠근 뒤 연결이 끊기는 문제는 시스템 권한, 배터리 최적화, 자동 시작, 백그라운드 잠금 순서로 확인하세요. 먼저 클라이언트의 VPN 권한을 확인한 다음 시스템이 프로세스를 종료했는지, 구독 자체를 사용할 수 없는지 구분합니다.
글 읽기 →코어별 유지 관리 상태, 프로토콜 지원, 규칙 문법을 비교하고 GUI 클라이언트와 코어의 관계를 설명합니다. 알 수 없는 설정 필드를 발견하면 먼저 코어별 차이를 확인하세요.
글 읽기 →