TRACK 01
Windows
Windows 데스크톱 환경에 적합합니다. 다운로드 페이지에는 Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu 및 보관 클라이언트를 순서대로 정리하고, 우선 추천 항목과 지원 아키텍처를 표시했습니다. 설치 후에는 보통 시스템 트레이에서 메인 화면을 열고 구독 또는 YAML 파일을 가져옵니다.
라우팅 규칙 · 클라이언트 및 설정 문서
운영체제에 맞는 클라이언트를 선택하고 구독 또는 로컬 설정을 가져온 뒤, 규칙으로 트래픽 경로를 결정하세요. 이 사이트에서는 멀티플랫폼 클라이언트, YAML 설정, 문제 해결 자료를 한곳에 정리해 설치부터 포트, DNS, 정책 그룹, 규칙 순서까지 이어서 확인할 수 있습니다.
Platform entrance
홈에서는 플랫폼 진입점만 제공하며, 실제 클라이언트, 지원 아키텍처, 유지보수 상태와 설치 패키지 유형은 다운로드 페이지에 정리되어 있습니다. 먼저 현재 기기의 운영체제와 프로세서를 확인한 다음 그래픽 클라이언트 또는 명령줄 커널을 선택하면 패키지 불일치와 설정 디렉터리 혼동을 줄일 수 있습니다.
TRACK 01
Windows 데스크톱 환경에 적합합니다. 다운로드 페이지에는 Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu 및 보관 클라이언트를 순서대로 정리하고, 우선 추천 항목과 지원 아키텍처를 표시했습니다. 설치 후에는 보통 시스템 트레이에서 메인 화면을 열고 구독 또는 YAML 파일을 가져옵니다.
TRACK 02
Intel 및 Apple Silicon Mac에 적합합니다. 설치 패키지를 선택할 때 x64와 ARM 아키텍처를 구분해야 하며, 처음 실행하면 시스템 보안 확인, 네트워크 확장 승인 또는 시스템 프록시 권한 요청이 나타날 수 있습니다. 다운로드 페이지에서 아키텍처별 진입점을 나누어 ‘이 Mac에 관하여’에 표시된 정보에 맞게 선택할 수 있습니다.
TRACK 03
스마트폰, 태블릿 및 일부 Android TV 기기에 적합합니다. 클라이언트는 보통 시스템 VPN 인터페이스로 트래픽을 처리하므로 처음 연결할 때 VPN 요청을 승인해야 합니다. 기기 아키텍처가 확실하지 않다면 먼저 범용 패키지를 확인하고, 더 작은 설치 패키지가 필요할 때 ARM64 또는 ARM 버전을 선택하세요.
TRACK 04
iPhone 및 iPad 사용자는 App Store에서 Clash Plus 페이지로 이동할 수 있습니다. 설치 후 클라이언트 화면에서 구독을 가져오고, 처음 연결할 때 시스템 VPN 설정을 승인하세요. 다운로드 페이지에는 앱 스토어 진입점과 clashplus.io 공식 사이트를 함께 표시해 제품 정보를 확인하기 쉽게 했습니다.
TRACK 05
데스크톱 사용자는 그래픽 인터페이스가 있는 클라이언트를 선택할 수 있으며, 서버, 소프트웨어 라우터 및 컨테이너 환경에는 보통 mihomo 커널이 더 적합합니다. 다운로드 전에 배포판, CPU 아키텍처와 설치 형식을 확인하고, 실행 후에는 설정 디렉터리, 로그 위치와 서비스 관리 방식을 명확히 해야 합니다.
클라이언트 차이를 잘 모르겠다면 플랫폼별 우선 추천 항목을 먼저 확인한 뒤 TUN, 시스템 프록시, 트레이 관리 또는 명령줄 실행이 필요한지에 따라 선택하세요.
모든 클라이언트 보기 →Rule switchyard
Clash는 설정에 작성된 규칙 순서대로 요청을 하나씩 매칭합니다. 규칙에 일치하면 트래픽은 직접 연결, 프록시 또는 차단 정책으로 전달됩니다. 일치하지 않으면 최종 대체 규칙에 도달할 때까지 다음 규칙을 계속 확인합니다. 이 처리 흐름을 이해하면 특정 클라이언트의 버튼만 외우는 것보다 문제를 훨씬 쉽게 진단할 수 있습니다.
RULE ENTRY
규칙 순서가 결과를 직접 결정합니다. 구체적인 도메인 및 프로세스 규칙은 앞에 두고, 지역 규칙과 일반 규칙은 뒤에 배치하며, 마지막에는 MATCH로 기본 정책을 지정합니다.
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXY
DIRECT
직접 연결 정책은 프록시 노드를 거치지 않고 현재 기기의 네트워크로 대상에 접속합니다. LAN 주소, 로컬 서비스, 접속 지역이 중요한 사이트와 프록시가 필요 없다고 확인된 도메인에 적합합니다. 일반적인 설정에서는 사설 주소를 먼저 매칭한 다음 한국 국내 지역 IP 또는 도메인 목록을 매칭합니다. 직접 연결도 규칙을 건너뛰는 것은 아닙니다. 요청은 여전히 Clash의 매칭 과정을 거치며 최종 출구만 로컬 네트워크로 선택됩니다. 프록시 모드에서 특정 사이트의 로그인에 문제가 생기거나 다운로드 속도가 오히려 느려지고 LAN 기기에 접근할 수 없다면 해당 대상이 DIRECT로 처리되어야 하는지 먼저 확인하세요. 변경 후에는 연결 로그에서 규칙 이름과 정책 결과를 확인해야 하며, 웹페이지가 열리는지만 봐서는 안 됩니다.
PROXY
프록시 정책은 보통 하나의 노드 이름이 아니라 정책 그룹입니다. 규칙이 PROXY에 일치하면 클라이언트는 정책 그룹 유형에 따라 수동 선택, 자동 테스트, 장애 조치 또는 부하 분산 결과를 사용합니다. 이를 통해 ‘어떤 요청에 프록시가 필요한가’와 ‘프록시 요청에 어떤 노드를 사용할 것인가’를 두 계층으로 나눌 수 있어, 노드를 바꿀 때 전체 규칙을 다시 작성할 필요가 없습니다. 웹페이지는 열리지만 앱이 연결되지 않는다면 규칙 일치 여부, 정책 그룹 존재 여부, 그룹 내 노드 사용 가능 여부, 시스템 프록시 또는 TUN이 해당 앱을 처리하는지를 차례로 확인하세요. 연결 로그의 규칙 이름, 정책 이름과 대상 주소가 경로를 파악하는 핵심 근거입니다. 단순히 전역 모드를 반복해서 전환하면 원래 문제를 가릴 수 있습니다.
REJECT
차단 정책은 추적 도메인, 비정상 요청 또는 접속을 원하지 않는 대상처럼 특정 연결을 명확히 종료할 때 사용합니다. 로컬 규칙 단계에서 실패 결과를 반환하므로 해당 요청에 직접 연결이나 프록시 출구를 선택하지 않습니다. 차단 규칙은 대상을 명확히 하고 이를 덮어쓸 수 있는 넓은 규칙보다 앞에 배치해야 합니다. 지나치게 큰 도메인 목록이나 잘못된 와일드카드 규칙은 로그인, 인증 코드, 푸시 알림과 앱 업데이트에 영향을 줄 수 있습니다. 페이지 본문은 정상인데 이미지, 버튼 또는 로그인 과정이 사라졌다면 로그에서 REJECT 일치 항목을 잠시 확인한 뒤 해당 도메인에 맞춰 규칙을 조정하세요. 브라우저 확장 기능과 비교하면 Clash의 규칙은 시스템 프록시나 TUN으로 처리되는 더 많은 앱에 적용되지만, 매칭 범위를 더욱 신중하게 관리해야 합니다.
A / 원리
규칙은 요청이 어느 범주에 속하는지 판단하고, 정책은 실제 출구를 결정합니다. 둘을 섞어 이해하면 노드가 바뀔 때마다 규칙을 계속 수정하게 되지만, 분리해 관리하면 정책 그룹 구성원이나 선택 결과만 조정하면 됩니다.
B / 상황
문제를 진단할 때는 먼저 요청이 클라이언트에 의해 처리되는지 확인하고, 어떤 규칙에 일치했는지 확인한 다음 해당 정책과 노드를 점검하세요. 이 순서로 확인하면 포트, DNS, 규칙과 상위 연결 문제를 구분할 수 있습니다.
C / 설정
규칙 목록의 마지막에는 명확한 기본 경로가 있어야 합니다. 기본 규칙이 없거나 존재하지 않는 정책 그룹을 참조하거나, 범위가 넓은 규칙을 너무 앞에 배치하면 앞서 정교하게 작성한 도메인 규칙이 제대로 작동하지 않습니다.
Quick start
아래 절차는 작동하는 기본 환경을 빠르게 구성하기 위한 것입니다. 클라이언트마다 버튼 위치는 조금 다를 수 있지만 처리 순서는 대체로 같습니다. 먼저 설치 패키지와 시스템이 호환되는지 확인하고, 유효한 설정을 가져온 뒤 로그와 실제 요청으로 처리 범위를 검증하세요.
Windows 사용자는 보통 x64 데스크톱 설치 패키지를 선택합니다. Apple Silicon Mac은 ARM 버전, Intel Mac은 x64 버전을 사용해야 하며, Android 기기는 프로세서 아키텍처에 맞는 설치 패키지를 선택할 수 있습니다. 설치가 끝나면 클라이언트를 먼저 실행해 메인 화면, 설정 디렉터리와 로그 영역이 정상적으로 열리는지 확인하세요. 시스템에서 네트워크 확장, VPN 또는 방화벽 권한을 요청하면 현재 클라이언트 기능에 필요한 권한인지 확인해 승인해야 합니다. 그렇지 않으면 시스템 프록시나 TUN이 트래픽을 처리하지 못할 수 있습니다.
구독 방식은 서버에서 노드와 규칙을 지속적으로 관리하는 환경에 적합하고, 로컬 YAML은 직접 작성하고 버전 관리할 때 유용합니다. 가져온 뒤 클라이언트에 문법 오류가 표시되는지 확인하고 정책 그룹, 노드, 포트 및 DNS 필드가 인식되었는지 점검하세요. 구독 업데이트에 실패해도 기존 설정을 바로 삭제하지 마세요. 주소가 완전한지, 네트워크에서 구독 원본에 접근할 수 있는지, 응답 내용이 실제 설정 텍스트인지 확인한 뒤 로그에서 네트워크 오류와 YAML 파싱 오류를 구분하세요.
데스크톱 브라우저는 먼저 시스템 프록시로 검증할 수 있습니다. 시스템 프록시 설정을 읽지 못하는 앱은 TUN을 고려하세요. 연결 후 클라이언트 로그 또는 연결 목록에서 대상 도메인이 예상한 DIRECT, PROXY 또는 REJECT 정책으로 처리되는지 확인합니다. 브라우저는 되지만 다른 앱이 되지 않는다면 처리 방식을 중점적으로 확인하세요. 모든 앱이 연결되지 않으면 수신 포트, 설정 로드 상태와 정책 그룹을 먼저 점검하고, 특정 도메인만 이상하면 규칙 순서와 DNS 해석 결과를 다시 확인하세요.
Open source context
Clash 관련 명칭은 원래 커널, 후속 커널 구현체, 그래픽 클라이언트와 범용 설정 형식을 동시에 가리킬 수 있습니다. 이러한 계층을 이해하면 특정 필드를 어느 구성 요소가 지원하는지, 문제를 인터페이스 계층에서 처리할지 커널 계층에서 처리할지 판단하기 쉬워집니다.
01 / 프로젝트 역사
Clash는 YAML 설정, 정책 그룹과 순서가 있는 규칙을 중심으로 한 사용 모델을 정립했습니다. 원본 프로젝트의 유지보수가 중단된 뒤에도 생태계의 클라이언트와 설정이 하나의 업데이트 경로를 따르지는 않았습니다. 현재 많은 데스크톱 및 모바일 클라이언트가 mihomo 커널을 사용하며 DNS, TUN, 규칙 제공자, 프록시 프로토콜과 네트워크 스택 관련 기능을 계속 확장하고 있습니다. 튜토리얼을 볼 때는 문서가 대상으로 하는 커널과 클라이언트 버전을 확인해야 합니다. 이전 필드는 호환될 수 있지만 새로운 필드는 구형 커널에서 인식되지 않을 수 있습니다. 같은 설정이 기기마다 다르게 작동한다면 설정 자체가 무효라고 단정하지 말고 양쪽 클라이언트 이름, 커널 이름과 설정 로드 로그를 먼저 기록하세요.
02 / 오픈 소스 생태계
그래픽 클라이언트는 주로 설정 관리, 구독 업데이트, 시스템 프록시 전환, TUN 권한, 로그 표시와 커널 수명 주기를 담당하고, 커널은 수신 포트, 설정 파싱, 연결 생성, DNS 처리와 규칙 매칭을 담당합니다. 두 구성 요소는 서로 다른 프로젝트에서 관리될 수 있으므로 인터페이스 업데이트가 커널 필드의 동기화를 의미하지 않으며, 커널이 특정 기능을 지원해도 모든 클라이언트에 해당 스위치가 제공되는 것은 아닙니다. 이 사이트의 다운로드 목록은 플랫폼별로 클라이언트를 분류하고, 설정 문서는 가능한 한 필드 이름으로 하위 동작을 설명합니다. 고급 기능을 확인할 때는 화면에 특정 옵션이 보이는지만 보지 말고 클라이언트의 커널 정보와 설정 로드 결과를 함께 확인하세요.
03 / 커널 관계
수신 포트, 실행 모드, 프록시 노드, 정책 그룹과 규칙 같은 기본 필드는 구현체가 달라도 대체로 식별하기 쉽습니다. 반면 DNS 정책, TUN 네트워크 스택, 규칙 집합 형식과 특정 프로토콜 필드는 커널 버전의 영향을 더 크게 받습니다. 서버 환경은 파일 권한, 서비스 사용자, 작업 디렉터리와 시스템 라우팅의 영향도 받으며, 데스크톱 환경에서는 시스템 프록시가 꺼져 있거나 TUN 권한을 승인하지 않았거나 다른 네트워크 도구가 포트를 점유하는 경우가 흔합니다. 설정을 마이그레이션하기 전에는 최소 실행 파일부터 시작해 포트와 기본 규칙이 정상인지 확인한 다음 DNS, 규칙 제공자와 오버라이드 내용을 단계적으로 추가하세요. 복잡한 설정 전체를 한 번에 불러오는 것보다 문제를 훨씬 쉽게 찾을 수 있습니다.
04 / 업데이트 방식
클라이언트, 커널, 구독 콘텐츠와 사용자 오버라이드는 각각 따로 업데이트될 수 있습니다. 클라이언트 업그레이드 후 문제가 생기면 커널도 함께 변경되었는지 먼저 판단하세요. 구독 업데이트 후 정책 그룹이 사라졌다면 원격 설정 내용과 로컬 오버라이드 순서를 확인하고, 규칙 집합 업데이트 후 접속 경로가 달라졌다면 실제로 일치한 규칙을 확인해야 합니다. 정상 작동이 확인된 기본 설정을 하나 보관하고 복잡한 필드는 모듈 단위로 수정하세요. 변경할 때마다 설정을 다시 로드하고 오류 행 번호를 확인한 뒤 대상 요청을 한 번 실행하는 것이 좋습니다. 안정적인 되돌리기 지점을 유지하면 여러 업데이트가 동시에 발생한 뒤 처음부터 추측하는 대신 최근 변경 사항으로 문제 범위를 좁힐 수 있습니다.
SOURCE REFERENCE
아래 명령은 공개 소스 코드 저장소를 복제할 때 사용합니다. 구현을 읽거나 커널을 빌드하거나 설정 필드의 동작을 확인하려는 사용자에게 적합합니다. 일반적인 데스크톱 사용자는 다운로드 페이지에서 그래픽 클라이언트를 바로 선택할 수 있습니다.
git clone https://github.com/MetaCubeX/mihomo.git
Configuration notes
글에서는 실제 설정 작업을 중심으로 멀티 디바이스 동기화, Linux 배포와 서로 다른 커널 명칭의 관계를 설명합니다. Fake-IP, 지역별 라우팅과 규칙 순서를 다뤄야 한다면 블로그에서 전체 예제를 확인할 수 있습니다.
구독 링크, 오버라이드 파일과 비공개 저장소라는 세 가지 동기화 경로를 비교하고 자격 증명 분리, 충돌 처리와 업데이트 순서를 설명합니다. 공유하기 적합한 규칙 내용과 단일 기기에 남겨야 하는 로컬 포트, 경로 및 인증 정보를 구분하는 데 초점을 맞췄습니다.
전체 글 읽기 →데스크톱 환경부터 그래픽 없는 서버까지 설정 디렉터리, 실행 명령, systemd 서비스와 터미널 프록시 변수를 정리하고, 로그, 수신 포트와 서비스 상태로 시작 실패 또는 설정 경로 오류를 진단하는 방법을 설명합니다.
전체 글 읽기 →유지보수 상태, 설정 필드, 규칙 기능과 클라이언트 호환 관계를 기준으로 원본 Clash, Clash Meta 및 mihomo라는 명칭의 변화를 설명하고, 설정을 마이그레이션할 때 우선 확인해야 할 필드 범위를 제시합니다.
전체 글 읽기 →