DESKTOP / 01
Windows
트레이 제어, 시스템 프록시 전환, 그래픽 구독 관리를 원하는 데스크톱 사용자에게 적합합니다. 다운로드 전에 “설정 → 시스템 → 시스템 정보”에서 x64 기기인지 확인하세요. 설치가 시스템에 의해 차단되면 파일 출처와 보안 경고 내용을 먼저 확인하고, 전체 보안 기능을 끄지는 마세요.
CONFIG TRIAGE
Clash의 인터페이스, 코어, 구독, 규칙, 시스템 네트워크 설정은 서로 다른 계층입니다. 문제가 생기면 먼저 범위를 좁힌 뒤 설정을 수정하세요. 한 번에 변수 하나만 바꿔야 어떤 단계가 실제로 효과가 있었는지 알 수 있습니다.
DOMAIN-SUFFIX
규칙 분기는 특정 요청을 어느 정책 그룹으로 보낼지 결정합니다. 문제를 확인할 때는 먼저 연결 기록에서 대상 도메인을 찾고, 일치한 규칙 유형과 대상 정책을 확인하세요. 요청이 지나치게 넓은 규칙에 먼저 걸리면 뒤의 세부 규칙은 실행되지 않습니다. 설정을 바꿀 때는 더 구체적인 도메인 규칙을 GEOIP 또는 MATCH 같은 포괄적인 규칙보다 앞에 배치하고, 규칙이 가리키는 정책 그룹 이름이 실제로 존재하는지 확인해야 합니다. 규칙은 올바른데 출구가 예상과 다르다면 문제는 대개 정책 그룹 계층에 있으므로 도메인 규칙을 계속 반복해서 수정할 필요가 없습니다.
DOMAIN-SUFFIX,youtube.com,PROXY
PROXY-GROUP
정책 그룹은 규칙이 배정한 트래픽을 받아 직결, 고정 노드, 자동 선택, 장애 조치 중 하나를 결정합니다. 웹페이지에 접속할 수 없다면 먼저 연결 기록이 예상한 정책 그룹으로 들어갔는지 확인한 뒤, 해당 그룹의 출구를 수동으로 바꿔 비교 테스트를 진행하세요. 하나의 노드만 실패하면 노드나 회선 문제일 가능성이 높고, 같은 그룹의 모든 노드가 실패하면 구독 상태, 프로토콜 매개변수, 로컬 네트워크를 확인해야 합니다. 정책 그룹 이름을 바꿨다면 규칙의 참조도 함께 점검하세요. 그렇지 않으면 요청이 마지막 기본 정책으로 넘어갈 수 있습니다.
- name: PROXY · type: select · proxies: [AUTO, DIRECT]
PROFILE
구독 관리는 원격 설정을 가져와 로컬 설정 파일로 저장합니다. 업데이트에 실패하면 먼저 구독 유효 기간과 주소가 완전한지 확인한 뒤, 직결 네트워크에서 해당 주소에 접속되는지 테스트하세요. 브라우저에서는 열리지만 클라이언트에서 실패한다면 현재 사용할 수 없는 프록시를 통해 구독을 업데이트하고 있지는 않은지, 시스템 시간이 정확한지, 설정 디렉터리에 쓰기 권한이 있는지 점검해야 합니다. 업데이트가 성공한 뒤에는 새 설정이 현재 활성화되어 있는지도 확인하세요. 다운로드만 완료되고 설정을 전환하지 않았다면 노드와 규칙은 계속 이전 상태로 유지됩니다.
profiles → update → activate → reload
CLIENT / CORE
Windows, macOS, Android, iOS, Linux의 클라이언트 인터페이스는 서로 다르지만 핵심 흐름은 같습니다. 설정 가져오기, 코어 시작, 모드 선택, 시스템 프록시 또는 VPN 인계 활성화 순서입니다. 플랫폼을 옮길 때 인터페이스의 버튼 위치를 그대로 따라 하지 말고, 먼저 클라이언트가 지원하는 코어와 설정 필드를 확인한 다음 새 플랫폼에서 네트워크 권한을 다시 부여하세요. 데스크톱에서는 시스템 프록시와 방화벽이, 모바일에서는 VPN 권한과 배터리 절전 제한 및 백그라운드 실행 상태가 주요 원인인 경우가 많습니다.
client UI → mihomo core → system proxy / VPN
PLATFORM ROUTES
먼저 운영체제와 프로세서 아키텍처를 확인한 다음 해당 플랫폼의 클라이언트를 선택하세요. 데스크톱 설치 패키지, 모바일 앱, 명령줄 코어는 용도가 다르므로 파일명이 비슷하다는 이유만으로 혼용하면 안 됩니다.
DESKTOP / 01
트레이 제어, 시스템 프록시 전환, 그래픽 구독 관리를 원하는 데스크톱 사용자에게 적합합니다. 다운로드 전에 “설정 → 시스템 → 시스템 정보”에서 x64 기기인지 확인하세요. 설치가 시스템에 의해 차단되면 파일 출처와 보안 경고 내용을 먼저 확인하고, 전체 보안 기능을 끄지는 마세요.
DESKTOP / 02
먼저 “이 Mac에 관하여”에서 Apple 실리콘인지 Intel 프로세서인지 확인한 뒤 알맞은 설치 패키지를 선택하세요. 처음 실행할 때 시스템 설정에서 앱 권한을 승인해야 할 수 있습니다. 시스템 프록시는 켜져 있지만 브라우저가 계속 직결된다면 클라이언트 코어가 실제로 실행 중인지 확인하세요.
다운로드 페이지로 이동MOBILE / 03
Android 클라이언트는 시스템 VPN 인터페이스를 통해 트래픽을 인계받습니다. 처음 연결할 때 VPN 권한을 승인하고, 배터리 최적화 대상에서 클라이언트를 제외하세요. 화면을 잠근 뒤 연결이 끊기는 경우는 대개 시스템이 백그라운드 프로세스를 종료했기 때문이므로, 먼저 구독이나 규칙을 수정할 필요는 없습니다.
다운로드 페이지로 이동MOBILE / 04
iOS 클라이언트는 처음 연결할 때 VPN 구성을 추가해 달라고 요청합니다. 이는 시스템이 네트워크 터널을 만들기 위해 필요한 권한입니다. 구독을 가져온 뒤 노드가 보이지 않으면 먼저 구독 내용이 현재 클라이언트와 호환되는지 확인한 다음 셀룰러 데이터 권한과 VPN 상태를 점검하세요.
다운로드 페이지로 이동DESKTOP / SERVER / 05
데스크톱 환경에서는 그래픽 클라이언트를 선택할 수 있고, 서버·라우터·컨테이너 환경에서는 보통 Mihomo 코어를 직접 사용합니다. 설치 전에 배포판, CPU 아키텍처, 패키지 형식을 확인하세요. 서비스가 시작된 뒤에는 먼저 로그와 수신 포트를 확인하고 시스템 서비스 및 부팅 자동 시작을 설정해야 “프로세스가 실행되지 않음”을 규칙 문제로 잘못 판단하는 일을 피할 수 있습니다.
FIRST CONNECTION
처음 설정에서는 핵심 흐름만 처리하세요. 설정 출처, 출구 정책, 시스템 인계가 대상입니다. 고급 DNS, TUN, 규칙 재정의는 기본 연결이 확인된 뒤 조정하는 것이 좋습니다.
클라이언트의 설정 또는 구독 페이지를 열고 완전한 구독 주소를 붙여 넣은 뒤 업데이트를 실행하세요. 설정 이름, 정책 그룹, 노드 목록이 표시되면 해당 설정을 현재 활성 항목으로 지정합니다. 업데이트 실패 메시지가 나타나면 먼저 구독이 만료되지 않았는지 확인하고, 시스템 프록시를 끈 상태에서 주소에 접속되는지 테스트하세요. 같은 주소를 계속 가져와 중복 설정을 여러 개 만들면 나중에 어떤 설정을 사용 중인지 확인하기 어려워집니다.
PROFILE → IMPORT → ACTIVATE
새 설정에는 보통 규칙 모드와 몇 개의 정책 그룹이 이미 포함되어 있습니다. 먼저 규칙 모드는 그대로 두고 기본 정책 그룹에서 사용할 수 있는 출구 하나를 선택하세요. 노드 상태가 확실하지 않다면 하나씩 바꾸며 짧게 연결을 테스트할 수 있습니다. 전역 모드는 규칙 문제인지 임시로 판단할 때 유용하지만, 장기적인 문제 해결 방법으로 삼기에는 적합하지 않습니다. 전역 모드에서는 연결되지만 규칙 모드에서는 연결되지 않는다면 연결 기록으로 돌아가 어떤 규칙과 일치했는지 확인하세요.
MODE: RULE · GROUP: PROXY
데스크톱에서는 시스템 프록시를 켜고 모바일에서는 VPN 권한을 확인하세요. 시스템 프록시를 따르지 않는 앱까지 인계해야 할 때만 TUN 모드를 검토합니다. 연결 후 직결 사이트 하나와 프록시가 필요한 사이트 하나에 접속하고, 클라이언트 연결 기록에서 두 요청의 정책을 확인하세요. 테스트가 끝난 뒤 특정 앱 하나만 작동하지 않는다면 바로 클라이언트를 재설치하지 말고, 해당 앱이 별도 프록시나 자체 DNS를 사용하는지 확인하세요.
SYSTEM PROXY / VPN → CONNECTIONS
OPEN SOURCE CONTEXT
Clash는 하나의 설치 패키지를 가리키는 이름이 아닙니다. 실제 사용 환경은 그래픽 클라이언트, 프록시 코어, 구독 설정, 시스템 네트워크 인터페이스가 함께 구성합니다. 각 계층의 역할을 알아야 잘못된 위치에서 같은 시도를 반복하지 않을 수 있습니다.
git clone https://github.com/MetaCubeX/mihomo.git
초기 Clash는 규칙 매칭, 정책 그룹, 프록시 프로토콜, 제어 인터페이스 등의 기본 기능을 제공했습니다. 원 프로젝트의 상태가 바뀌면서 커뮤니티에는 계속 유지 관리되는 코어 포크와 다양한 그래픽 클라이언트가 등장했습니다. 오늘날 사용자가 말하는 “Clash”는 하나의 프로그램이 아니라 설정과 클라이언트 전체 생태계를 뜻하는 경우가 많습니다. 소프트웨어를 선택할 때는 이름에 Clash가 포함되었는지만 보지 말고 클라이언트의 유지 관리 상태, 사용 코어, 대상 플랫폼을 함께 확인해야 합니다.
클라이언트마다 구독, 프록시 그룹, 로그, 시스템 프록시 등의 조작 메뉴를 다르게 구성하지만, 내부에서는 여전히 YAML 설정, 규칙 매칭, 제어 인터페이스를 중심으로 작동합니다. 이러한 분업 덕분에 데스크톱, 모바일, 서버 환경에서 서로 다른 외형을 선택할 수 있지만, 특정 인터페이스의 튜토리얼을 모든 클라이언트에 버튼 단위로 그대로 적용할 수는 없습니다. 플랫폼을 옮길 때는 먼저 필드와 트래픽 경로를 이해한 뒤 해당 인터페이스의 위치를 찾으세요.
Mihomo는 현재 Clash 생태계에서 널리 사용되는 지속 유지 관리 코어입니다. 그래픽 클라이언트는 설정 다운로드, 정책 표시, 제어 인터페이스 호출, 시스템 권한 관리를 담당하고, 실제 연결 수립과 규칙 실행, DNS 처리 및 트래픽 전달은 코어가 담당합니다. 클라이언트가 열렸다고 해서 코어가 정상적으로 시작된 것은 아니며, 노드 목록이 있다고 해서 프록시 경로가 작동하는 것도 아닙니다. 문제가 생기면 인터페이스의 막연한 안내보다 코어 로그가 장애 지점에 더 가깝습니다.
클라이언트 업데이트는 인터페이스 기능과 플랫폼 호환성 문제를 해결하고, 코어 업데이트는 프로토콜·규칙·네트워크 처리 능력과 관련됩니다. 구독 업데이트는 노드와 서비스 제공자가 배포한 정책 내용을 교체합니다. 세 가지는 같은 업데이트 경로가 아닙니다. “업데이트 후 작동하지 않음”을 점검할 때는 어느 계층을 업데이트했는지 기록하고, 비교를 위해 이전에 작동하던 설정을 보관하세요. 설정 필드의 호환성이 바뀌었다면 먼저 클라이언트 안내를 읽고 로컬 재정의를 항목별로 옮기세요.
FAULT ORDER
첫째, 구독을 확인합니다. 유효 기간, 업데이트 결과, 현재 활성 설정을 점검하세요. 둘째, 코어를 확인합니다. 정상적으로 시작했는지, 포트가 사용 중인지, 로그에 설정 해석 오류가 있는지 살펴봅니다. 셋째, 정책을 확인합니다. 연결 기록으로 대상 요청이 어떤 규칙과 정책 그룹에 일치했는지 판단하세요. 넷째, 시스템 인계를 확인합니다. 데스크톱은 시스템 프록시, 모바일은 VPN 권한, TUN 사용자는 가상 네트워크 어댑터와 권한을 점검합니다. 다섯째가 DNS입니다. 도메인 해석 실패, 해석 결과 불일치, 연결 단계 실패를 구분하세요.
각 단계를 완료할 때마다 같은 테스트를 수행하고 결과를 기록하세요. 직결 네트워크 자체가 작동하지 않으면 먼저 기본 네트워크를 복구합니다. 특정 노드만 시간 초과되면 우선 노드를 바꾸세요. 모든 노드가 실패하지만 구독은 업데이트된다면 시스템 시간, 프로토콜 매개변수, 네트워크 제한을 확인합니다. 브라우저는 작동하지만 특정 앱만 작동하지 않으면 해당 앱이 시스템 프록시를 우회하는지 점검하세요. 이 순서를 따르면 같은 현상을 검증 가능한 문제로 나눌 수 있습니다.
QUICK ANSWERS
먼저 구독 유효 기간과 주소가 완전한지 확인한 다음 현재 시스템 프록시를 끄고 직결 네트워크에서 구독 주소를 테스트하세요. 브라우저에서는 접속되지만 클라이언트에서 계속 실패한다면 시스템 시간, 설정 디렉터리 쓰기 권한, 클라이언트가 만료된 프록시를 통해 업데이트를 시도하고 있는지 확인하세요. 관련 필드의 의미는 용어집에서 계속 확인할 수 있습니다.
일부 앱은 시스템 프록시를 읽지 않거나 독립적인 네트워크 스택과 자체 DNS를 사용합니다. 먼저 연결 기록에서 클라이언트가 해당 앱의 요청을 감지했는지 확인하세요. 기록이 전혀 없다면 문제는 시스템 인계 계층에 있으므로 TUN 모드를 검토할 수 있습니다. 기록은 있지만 정책이 잘못되었다면 규칙과 프로세스 매칭을 확인하세요.
특정 노드만 시간 초과되면 보통 노드 상태나 해당 회선 문제입니다. 모든 노드가 동시에 시간 초과되면 구독 만료, 로컬 네트워크, 시스템 시간, 코어 미실행, 프로토콜 매개변수와 관련이 있을 가능성이 큽니다. 먼저 직결 네트워크에서 일반 웹페이지가 열리는지 확인한 뒤 코어 로그를 살펴보세요. 처음부터 DNS와 규칙을 일괄 수정하지는 마세요.
이는 기본 프록시 경로가 이미 구성되었을 가능성이 높다는 뜻입니다. 다음으로 규칙 모드에서 대상 도메인과 일치한 규칙 및 정책 그룹을 확인하세요. 포괄적인 규칙이 요청을 먼저 가로채지는 않았는지, 규칙이 참조하는 정책 그룹이 존재하는지, 해당 그룹에서 선택한 출구가 작동하는지를 중점적으로 점검합니다.
FIELD NOTES
각 글은 구체적인 증상에 맞춰 판단 기준을 먼저 제시한 뒤 작업 순서를 안내합니다. 노드 시간 초과, 최초 설치, 모바일 구독 가져오기 문제는 해당 상황에서 바로 시작할 수 있습니다.
먼저 모든 노드의 시간 초과인지 특정 노드만의 문제인지 구분한 뒤 구독, 직결 네트워크, 시스템 시간, 코어 상태, 프로토콜 매개변수를 차례로 확인하세요. 각 단계에는 명확한 중단 기준이 있어 여러 설정을 동시에 바꾸는 일을 피할 수 있습니다.
전체 글 읽기 →클라이언트 설치, 최초 VPN 권한 승인, 구독 가져오기의 전체 순서를 설명하고 구독 링크와 로컬 설정 파일이라는 두 가지 진입 경로를 구분합니다. 가져온 뒤 노드가 보이지 않으면 호환성과 네트워크 권한을 기준으로 계속 원인을 좁혀갈 수 있습니다.
전체 글 읽기 →설치 패키지 선택부터 구독 가져오기, 시스템 프록시 활성화까지 5개 플랫폼에 공통되는 설정 흐름을 정리합니다. 설치 차단, 구독 가져오기 실패, 프록시 미적용 문제는 각각 해당 계층에서 처리합니다.
전체 글 읽기 →