Windows, macOS, Android, iOS 및 Linux 클라이언트를 한곳에서 찾고, mihomo 코어, 설정 파일, 규칙 분기 및 문제 해결 안내를 계속 확인하세요.
영구 무료오픈 소스다중 플랫폼한국어 문서
핵심 기능
설정 가져오기부터 규칙 매칭까지
Clash 클라이언트는 코어 기능을 조작하기 쉬운 화면으로 정리합니다. 아래 네 영역은 일상적으로 가장 자주 확인하는 항목이며, 설정할 때 주의할 범위도 함께 설명합니다.
01 · RULES
도메인, IP, 기본 규칙을 순서대로 매칭
규칙 모드에서 중요한 것은 규칙의 수가 아니라 매칭 순서입니다. 도메인 규칙은 일반적으로 IP 계열 규칙보다 앞에 배치하며, 광고 분류, 지정 도메인, 로컬 네트워크 주소를 우선 처리한 뒤 마지막에 MATCH로 매칭되지 않은 연결을 처리합니다. 클라이언트의 규칙 페이지에서는 현재 설정에 어떤 규칙이 포함되어 있는지 확인하고, 연결이 최종적으로 어느 정책 그룹으로 들어갔는지 살펴볼 수 있습니다.
설정을 수정할 때는 규칙 이름과 정책 그룹 이름이 완전히 일치하는지도 함께 확인해야 합니다. 존재하지 않는 정책 그룹을 가리키는 규칙은 로드 실패를 일으킬 수 있고, 앞부분에 너무 포괄적인 규칙이 있으면 뒤의 규칙이 작동하지 않을 수 있습니다. 단순히 켜고 끄는 기능만 제공하는 일반 프록시 도구와 달리, Clash의 규칙 체인은 도메인, 지리 데이터, 프로세스 등의 조건을 조합해 명확하고 검토 가능한 트래픽 경로를 만들 수 있습니다.
시스템 프록시는 로컬 프록시 주소를 운영체제 설정에 기록하므로 브라우저와 시스템 프록시를 자동으로 읽는 데스크톱 앱에 적합합니다. 터미널 프로그램, 일부 게임, 자체적으로 네트워크 연결을 관리하는 소프트웨어는 이 설정을 무시할 수 있습니다. 브라우저에서는 연결되지만 명령줄에서는 작동하지 않는다면 먼저 해당 앱이 시스템 프록시를 따르는지 확인한 뒤, 환경 변수를 설정할지 더 넓은 범위를 처리하는 TUN 모드를 사용할지 결정하세요.
TUN 모드는 가상 네트워크 인터페이스를 통해 트래픽을 가로채므로 더 많은 앱을 통합 처리해야 하는 상황에 적합하지만, 권한과 라우팅, DNS 설정의 영향을 더 크게 받습니다. 두 방식을 동시에 반복해서 켜고 끌 필요는 없습니다. 먼저 시스템 프록시로 시작해 설정과 노드가 정상적으로 작동하는지 확인한 다음, 앱 적용 범위에 따라 TUN을 활성화하면 문제 원인을 더 쉽게 좁힐 수 있습니다.
규칙이 도메인을 조건으로 사용할 때 DNS 처리 방식은 매칭 결과에 직접 영향을 줍니다. 클라이언트는 조회를 코어에 맡기고 규칙에 따라 해석 경로를 선택할 수 있습니다. 운영체제, 브라우저, 클라이언트가 서로 다른 방식으로 도메인을 해석하면 예상과 다른 도메인 매칭, 프록시 우회, 갱신되지 않은 해석 캐시가 발생할 수 있습니다.
Clash DNS 누수를 확인할 때는 테스트 페이지 하나만 확인해서는 안 됩니다. 먼저 현재 모드, 설정의 DNS 옵션, 브라우저의 보안 DNS 설정, 시스템 캐시를 확인한 뒤 로그에 해당 조회가 나타나는지 살펴보세요. nameserver, fallback, fake-ip 관련 설정을 변경했다면 설정을 다시 로드하고 기존 연결을 종료한 뒤 재시험해야 합니다. 그래야 오래된 캐시, 브라우저의 독립적인 DNS 해석, 코어 설정 문제를 구분할 수 있습니다.
로그 페이지에서는 세 가지 질문에 답할 수 있습니다. 요청이 코어에 들어갔는지, 어떤 규칙과 매칭되었는지, 최종적으로 어떤 정책이 사용되었는지입니다. 문제를 확인할 때는 먼저 로그 수준을 일반 정보 범위로 유지한 채 한 번 재현해 보세요. 디버그 행이 많다고 해서 결론이 더 명확해지는 것은 아니며, 오히려 중요한 연결을 묻을 수 있습니다. 시간, 도메인, 오류 키워드로 범위를 좁히는 편이 대체로 더 효과적입니다.
로그에 대상 연결이 전혀 없다면 문제는 대부분 트래픽이 Clash에 들어오기 전에 발생한 것입니다. 시스템 프록시, TUN 권한, 앱 자체의 프록시 설정을 확인하세요. 로그에 규칙 매칭은 올바르게 표시되지만 연결에 실패한다면 정책 그룹 선택, 구독 상태, 대상 네트워크를 점검해야 합니다. 진입, 매칭, 출구를 세 단계로 나누어 확인하면 노드를 반복해서 바꾸는 것보다 안정적인 원인을 찾기 쉽습니다.
설정 페이지에 구독 주소를 붙여 넣거나 로컬 YAML 파일을 가져오세요. 업데이트가 완료되면 해당 설정을 선택하고 클라이언트에 로드 오류가 표시되지 않는지 확인하세요. 업데이트에 실패하면 링크의 유효성과 네트워크 접근성을 먼저 점검하고, 동일한 구독을 연속해서 다시 추가하지 마세요.
02
정책 선택
프록시 페이지에서 설정이 제공하는 정책 그룹을 확인하세요. 그룹을 수동으로 선택하면 출구를 직접 지정할 수 있고, 자동 선택 및 장애 조치 그룹은 설정에 정의된 테스트 로직을 사용합니다. 노드 이름과 수량은 구독에서 제공하며 클라이언트는 이를 읽어 표시할 뿐입니다.
03
연결 및 검증
먼저 시스템 프록시를 활성화한 뒤 프록시가 필요한 대상에 접속하면서 연결 페이지와 로그 페이지를 함께 확인하세요. 요청이 코어에 들어가고 예상한 규칙과 매칭되며 올바른 정책을 사용하는지 확인해야 기본 연결이 완료됩니다. 터미널 프로그램은 프록시 환경 변수를 별도로 점검해야 합니다.
오픈 소스 생태계
코어, 클라이언트, 설정 형식
Clash는 하나의 설치 패키지 이름이 아니라 규칙 분기, 정책 그룹, 프록시 프로토콜을 중심으로 구성된 오픈 소스 프로젝트군입니다. 프로젝트 간 관계를 이해하면 클라이언트 화면, 코어 기능, 구독 내용을 서로 혼동하는 일을 피할 수 있습니다.
프로젝트 발전 과정
초기 Clash는 설정 파일, 정책 그룹, 규칙 체인의 기본 사용 방식을 정립했습니다. 이후 여러 커뮤니티 프로젝트가 데스크톱 인터페이스, 모바일 지원, 코어 기능을 계속 발전시켰습니다. 현재 널리 쓰이는 클라이언트는 서로 다른 기술 스택을 사용할 수 있지만 설정, 프록시, 규칙, 연결, 로그, 시스템 프록시처럼 많은 설정은 여전히 비슷한 개념을 공유합니다.
mihomo 코어와의 관계
mihomo는 Clash Meta의 기능 방향을 이어가는 대표적인 호환 코어 중 하나입니다. Clash 형식의 설정을 읽고 더 다양한 프로토콜, 규칙 유형, DNS 동작, TUN 옵션을 제공합니다. 클라이언트는 설정을 다운로드하고 코어를 시작하며 상태를 표시하고, 실제 규칙 매칭과 연결 처리는 코어가 담당합니다. 특정 기능의 사용 가능 여부는 클라이언트가 진입점을 제공하는지, 코어가 지원하는지, 설정이 올바르게 활성화되었는지를 함께 확인해야 합니다.
구독과 클라이언트는 서로 독립적
구독은 일반적으로 서비스 제공자가 생성하며 프록시 정보, 정책 그룹, 규칙을 포함합니다. 클라이언트가 누락된 내용을 자동으로 보완하지는 않으며, 모든 구독 형식을 바로 로드할 수 있다고 보장할 수도 없습니다. 클라이언트를 바꿀 때는 화면 외관보다 설정 호환성, 정책 그룹 이름, 전용 필드를 우선 확인하세요. 스크립트, 규칙 세트, 지리 데이터가 포함된 설정은 리소스 경로에 접근할 수 있는지도 확인해야 합니다.
업데이트 방식
그래픽 클라이언트, mihomo 코어, 구독 내용, 지리 데이터베이스는 각각 독립적인 업데이트 주기를 가집니다. 클라이언트를 업데이트한다고 구독까지 업데이트되는 것은 아니며, 구독을 새로 고쳐도 코어가 자동으로 변경되지는 않습니다. 기능 차이가 발생하면 먼저 어느 계층에서 변화가 생겼는지 확인하세요. 안정적으로 사용하는 설정은 자주 바꿀 필요가 없으며, 업그레이드할 때는 프로젝트 릴리스 노트를 먼저 읽고 복구 가능한 설정 사본을 보관하세요.
mihomo 소스 코드 받기git clone https://github.com/MetaCubeX/mihomo.git
클라이언트 선택
현재 시스템 지원 여부, 코어 업데이트 방식, 설정 호환성, 일상적인 작업 흐름을 우선 고려하세요. 유지 관리가 중단된 프로젝트는 이전 설정을 이해하는 데 사용할 수 있지만, 새 설치의 기본 선택으로 삼아서는 안 됩니다.
설정 읽기
YAML은 들여쓰기와 데이터 형식에 민감합니다. 수정하기 전에 포트, DNS, 정책 그룹, 규칙의 네 영역을 구분하고, 변경 후 다시 로드해 오류 메시지를 확인하세요.
문제 원인 찾기
문제를 설정 로드 여부, 트래픽 진입 여부, 규칙 매칭 여부, 출구 사용 가능 여부의 네 단계로 나누세요. 한 번에 하나의 변수만 바꾸면 결론의 신뢰도가 높아집니다.
사용 팁
최근 설정 및 문제 해결 글
화면 조작에서 코어 데이터, 구독 새로 고침, 최초 연결 검증까지 단계별로 확장합니다. 각 글은 구체적인 문제를 출발점으로 삼고, 단계마다 확인해야 할 결과를 설명합니다.