Windows
데스크톱 GUI, 시스템 프록시 제어와 시작 시 실행 관리가 필요한 사용자에게 적합합니다. 다운로드 페이지에는 Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu와 보관 클라이언트를 차례로 정리하고 각각의 사용 범위를 안내합니다.
클라이언트 다운로드 · 플랫폼 선택 · 한국어 설정 자료
운영체제, 프로세서 아키텍처와 사용 환경에 맞춰 클라이언트를 선택하고, 무료 사용, 오픈 소스 코드 및 한국어 문서를 통해 규칙 기반 분배, 구독 가져오기와 mihomo 코어의 설정 범위를 알아보세요.
Platform entries
홈에서는 플랫폼만 안내합니다. 구체적인 클라이언트, 프로세서 아키텍처, 시스템 요구 사항과 설치 패키지 링크는 중복 링크 관리를 피하기 위해 다운로드 페이지에 통합했습니다.
데스크톱 GUI, 시스템 프록시 제어와 시작 시 실행 관리가 필요한 사용자에게 적합합니다. 다운로드 페이지에는 Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu와 보관 클라이언트를 차례로 정리하고 각각의 사용 범위를 안내합니다.
설치 전에 “이 Mac에 관하여”에서 Intel 또는 Apple Silicon 칩을 확인하세요. 같은 클라이언트의 두 빌드는 서로 바꿔 사용할 수 없으므로 다운로드 페이지에서 아키텍처별 링크를 나누어 제공합니다. 최초 실행, 시스템 프록시와 권한 확인 절차도 함께 안내합니다.
모바일 기기는 일반적으로 ARM64 빌드를 우선 선택합니다. 아키텍처를 확인하기 어렵다면 다운로드 페이지의 범용 패키지 설명을 참고하세요. 클라이언트는 시스템 VPN 인터페이스로 트래픽을 제어하므로 연결 상태, 백그라운드 제한과 절전 정책이 지속 실행에 직접 영향을 줍니다.
iPhone과 iPad에서는 Clash Plus로 해당 설정을 사용하며, 다운로드 링크는 App Store로 연결됩니다. 공식 정보는 clashplus.io를 기준으로 확인하세요. 최초 연결 시 시스템에서 VPN 구성 추가를 요청하며, 권한을 허용한 뒤 클라이언트로 돌아와 정책 그룹을 선택합니다.
데스크톱 환경에서는 GUI 클라이언트를, 서버·소프트 라우터·컨테이너 환경에서는 mihomo 코어를 직접 실행하는 방식을 선택할 수 있습니다. 두 방식은 설정 형식이 비슷하지만 서비스 관리, 권한, 로그 위치와 트래픽 전달 경로는 크게 다릅니다.
어떤 클라이언트를 선택할지 모르겠다면 먼저 클라이언트 선택 가이드를 읽은 뒤 해당 플랫폼의 다운로드 페이지로 이동하세요.
Configuration lanes
자주 사용하는 기능을 5개의 설정 트랙으로 나눴습니다. 왼쪽 항목을 선택하면 오른쪽에서 관련 문제, 사용 방법과 주의할 범위를 확인할 수 있습니다.
Clash는 설정에 정의된 규칙을 위에서 아래로 적용해 도메인, 대상 IP, 프로세스 또는 규칙 세트를 매칭한 뒤 연결을 직접 연결, 거부 또는 지정된 정책 그룹으로 보냅니다. 모든 요청을 하나의 출구로 고정하는 것이 아니라 트래픽 유형별 처리 방식을 나누는 기능입니다. 사용 전 현재 모드가 규칙 모드인지 확인하고, 실제로 적용된 규칙과 정책 그룹을 점검해야 합니다.
단일 스위치만 제공하는 프록시 도구와 달리 규칙 체계는 분류 로직을 지속적으로 관리할 수 있다는 장점이 있지만, 규칙 순서도 명확해야 합니다. 지나치게 넓은 규칙을 앞에 두면 뒤의 항목이 가려지므로 문제를 점검할 때는 노드를 반복해서 바꾸기보다 실제 매칭 결과를 확인하세요. 일시적으로 모든 트래픽을 같은 방식으로 처리해야 한다면 전역 모드를 사용하고, 확인이 끝나면 규칙 모드로 되돌립니다.
데스크톱·모바일 클라이언트는 주로 설정 가져오기, 정책 전환, 시스템 인터페이스 제어와 로그 표시를 담당하며, 설정을 실제로 해석하고 연결을 처리하는 것은 코어입니다. 원본 Clash가 설정 구조를 확립했고, Clash Meta가 프로토콜과 규칙 기능을 확장했으며, 이후 프로젝트는 mihomo라는 이름으로 유지 관리되고 있습니다. 클라이언트를 선택할 때는 해당 GUI 프로그램에 어떤 코어가 포함되거나 지원되는지도 확인해야 합니다.
대부분의 기본 필드는 같은 설정 체계에서 사용할 수 있지만, 새 코어의 확장 필드를 구형 클라이언트가 인식하지 못할 수 있습니다. 설정을 이전할 때는 먼저 원본 파일을 보존하고 클라이언트 로그에서 필드 해석 관련 메시지를 확인하세요. 서버나 라우터 사용자는 mihomo를 직접 실행할 수 있고, 일반 데스크톱 사용자는 코어가 통합된 GUI 클라이언트로 시스템 프록시와 업데이트를 관리하는 편이 더 쉽습니다.
Windows와 macOS 데스크톱 클라이언트는 일반적으로 시스템 프록시를 통해 프록시 설정을 따르는 앱의 트래픽을 제어하며, 코어와 권한이 허용하면 TUN 모드로 더 많은 연결을 처리할 수도 있습니다. Android와 iOS는 시스템 VPN 인터페이스에 의존하므로 최초 연결 시 시스템 권한 승인 메시지가 표시됩니다. Linux는 데스크톱 프록시, 환경 변수, 투명 전달 또는 서비스 단위 배포를 사용할 수 있습니다.
플랫폼 차이는 문제 증상에 직접 영향을 줍니다. 예를 들어 브라우저는 접속되지만 명령줄 도구가 연결되지 않는다면 명령줄이 시스템 프록시를 상속하지 않았을 가능성이 큽니다. 모바일에서 화면을 잠근 뒤 연결이 끊기면 백그라운드 실행과 절전 제한을 확인해야 합니다. 선택할 때는 화면 모양뿐 아니라 운영체제 버전, 프로세서 아키텍처, 트래픽 제어 방식과 유지 관리 비용도 확인하세요.
구독 주소는 설정 내용을 가져오는 데 사용되며, 클라이언트는 그 안의 프록시 항목, 정책 그룹, 규칙과 DNS 설정을 해석합니다. 구독에서 생성된 설정을 직접 수정하면 편리하지만 다음 업데이트에서 로컬 변경 사항이 덮어써질 수 있습니다. 더 안정적인 방법은 원본 구독을 보존하고 장기적인 변경을 클라이언트가 지원하는 오버라이드, 스크립트 또는 별도 설정 사본에 기록하는 것입니다.
구독 업데이트에 실패하면 주소가 완전한지, 현재 네트워크에서 원본에 접근할 수 있는지, 응답이 유효한 설정인지, 캐시 파일이 손상되지 않았는지를 순서대로 확인하세요. 한 번에 주소·코어·규칙·DNS를 모두 바꾸지 말고 조건 하나만 변경해야 문제가 다운로드, 파싱 또는 실행 단계 중 어디에서 발생했는지 판단할 수 있습니다.
DNS는 도메인을 IP로 변환하는 기능만 담당하지 않습니다. Clash의 향상된 모드, nameserver, fallback, 도메인 규칙과 시스템 DNS 제어가 함께 해석 결과와 규칙 매칭에 영향을 줍니다. 웹페이지가 열리지 않거나 일부 도메인에서만 문제가 발생하거나 연결 시간이 반복해서 초과되면 먼저 요청이 Clash로 들어갔는지 확인한 뒤 어떤 리졸버를 사용했는지와 결과가 예상에 맞는지 점검하세요.
문제 해결은 단순한 설정에서 시작하세요. 확실히 접근 가능한 주 DNS 서버 하나를 남기고 복잡한 필터 조건을 잠시 줄인 다음 fallback과 규칙을 하나씩 복원합니다. 노드만 바꾸는 것으로는 DNS 경로 문제가 해결되지 않는 경우가 많습니다. 모바일에서는 시스템 비공개 DNS를, 데스크톱에서는 브라우저 보안 DNS와 클라이언트 DNS 제어가 서로 다른 경로를 만들고 있지 않은지도 확인하세요.
Quick start
먼저 가장 짧은 실행 경로를 완료한 다음 규칙, DNS와 자동 업데이트를 설정하세요. 이렇게 하면 설치 문제와 설정 문제를 나누어 판단할 수 있습니다.
다운로드 페이지에서 먼저 운영체제를 선택한 뒤 프로세서 아키텍처를 확인하세요. Windows 사용자는 일반적으로 x64 데스크톱 클라이언트를 선택하고, macOS는 Intel과 Apple Silicon을 구분해야 합니다. Android 기기는 ARM64가 가장 흔하며, Linux 사용자는 GUI를 사용할지 mihomo 코어를 직접 배포할지 결정해야 합니다.
설치가 끝나면 먼저 클라이언트를 실행해 코어가 정상적으로 로드되는지 확인하고, 곧바로 고급 옵션을 대량으로 변경하지 마세요. 시스템에서 네트워크, VPN 또는 방화벽 권한을 요청하면 해당 플랫폼에 맞게 승인해야 합니다. 권한이 없으면 클라이언트 화면은 열려도 트래픽이 코어로 전달되지 않을 수 있습니다.
설정 또는 구독 페이지에 유효한 주소를 붙여 넣고 클라이언트가 내용을 다운로드해 파싱할 때까지 기다리세요. 성공하면 설정 이름, 정책 그룹과 규칙 정보가 표시됩니다. 가져온 뒤 목록이 비어 있다면 같은 주소를 여러 설정으로 반복 추가하지 말고 먼저 파싱 로그를 확인하세요. 민감한 정보가 포함된 구독 주소는 공개해서는 안 됩니다.
설정을 활성화한 뒤 정책 그룹으로 이동해 제공되는 항목을 선택하세요. 처음에는 도메인과 IP 규칙이 트래픽 경로를 결정하도록 규칙 모드를 유지하는 것이 좋습니다. 전역 모드는 짧은 시간 동안 출구를 확인할 때 유용하지만 기존 분류 로직을 우회하므로 모든 문제의 고정 해결책으로 사용해서는 안 됩니다.
시스템 프록시를 켜거나 플랫폼에 맞게 VPN 연결을 설정한 뒤 안정적인 사이트에 접속하고 클라이언트 로그에 요청 기록이 나타나는지 확인하세요. 요청은 보이지만 연결에 실패한다면 트래픽이 이미 코어에 들어간 것이므로 정책과 연결 설정을 계속 점검합니다. 로그가 전혀 없다면 시스템 프록시, VPN 권한 또는 앱 자체의 프록시 설정을 먼저 확인하세요.
기본 연결이 정상임을 확인한 뒤 구독 업데이트 주기, 시작 동작과 DNS 옵션을 설정하세요. 변경할 때마다 한 항목만 수정하고 되돌릴 수 있는 설정 사본을 보존하세요. 그러면 업데이트 후 문제가 발생했을 때 구독 내용, 클라이언트 업그레이드와 로컬 설정 중 무엇이 원인인지 빠르게 판단할 수 있습니다.
Open source context
프로젝트 간 계승 관계를 이해하면 클라이언트 이름만 보는 것보다 설정 호환성, 업데이트 출처와 문제 발생 계층을 더 정확히 판단할 수 있습니다.
Clash는 YAML 설정, 정책 그룹과 규칙 기반 분배를 중심으로 한 사용 방식을 확립했고, 이후 데스크톱·모바일·라우터 배포를 아우르는 클라이언트 생태계가 형성되었습니다. 클라이언트마다 인터페이스 프레임워크와 릴리스 주기는 다를 수 있지만, 일반적인 설정 구조, 규칙 개념과 정책 조작은 같은 기술 계보에서 비롯됩니다. 원본 프로젝트의 지속적인 유지 관리가 중단된 뒤에도 기존 클라이언트는 실행할 수 있으며, 생태계의 유지 관리 중심은 점차 후속 코어와 신규 클라이언트로 이동했습니다.
오픈 소스 저장소에는 코드 변경, 이슈 논의와 릴리스 안내가 공개되어 있어 기능 범위와 버전 변화를 확인하는 데 유용합니다. 클라이언트를 다운로드할 때는 ‘인터페이스 프로젝트’, ‘코어 프로젝트’와 ‘설정 제공자’를 구분해야 합니다. 인터페이스는 조작 진입점을, 코어는 네트워크 처리를, 설정 내용은 사용자가 선택한 출처를 담당합니다. 셋은 같은 프로젝트가 아니므로 문제가 발생하면 로그와 동작을 바탕으로 어느 계층을 점검할지 판단해야 합니다.
Clash Meta는 원본 Clash의 프로토콜, 규칙과 DNS 기능을 확장했으며 이후 mihomo라는 이름으로 유지 관리되고 있습니다. 많은 신규 클라이언트가 mihomo를 내장 코어로 사용하므로 일반적인 Clash 설정과 일부 확장 필드를 읽을 수 있습니다. 하지만 호환된다고 해서 모든 버전에서 모든 필드가 완전히 같은 것은 아닙니다. 새 프로토콜이나 고급 DNS 설정을 사용하기 전에 클라이언트가 실제로 로드한 코어와 지원 범위를 확인하세요.
클라이언트 버전, 코어 버전과 구독 내용은 각각 독립적으로 업데이트됩니다. 인터페이스 업그레이드가 내장 코어를 교체할 수 있고, 구독 업데이트가 정책 그룹과 규칙을 바꿀 수 있으며, 로컬 오버라이드는 새 설정에도 계속 적용될 수 있습니다. 안정적인 유지 관리의 핵심은 이 세 가지 변화를 기록하고 문제가 발생했을 때 모두 한꺼번에 업데이트하지 않는 것입니다. 다운로드 페이지는 릴리스 목록에서 현재 설치 링크를 제공하고, 기술 문서는 주제별로 이전과 문제 해결 방법을 설명합니다.
Selected questions
플랫폼, 코어와 트래픽 제어 방식을 먼저 확인하면 설치 후 클라이언트를 반복해서 바꾸는 수고를 줄일 수 있습니다.
일반적인 데스크톱 GUI가 필요하다면 다운로드 페이지에서 우선 추천 클라이언트부터 확인하세요. 현재 설정이 mihomo 확장 필드에 의존한다면 클라이언트에 통합된 코어 유형을 확인해야 합니다. 선택할 때는 화면만 보지 말고 운영체제 버전, 프로세서 아키텍처, 업데이트 상태와 설정 이전 방식도 함께 고려하세요.
전체 클라이언트 비교 보기먼저 클라이언트 로그에 앱 요청이 나타나는지 확인하세요. 요청이 없다면 시스템 프록시, VPN 권한 또는 TUN 상태를 점검하고, 요청은 있지만 연결에 실패한다면 현재 정책 그룹, 설정 유효성과 DNS 경로를 확인합니다. 문제를 해결하는 동안 한 번에 하나의 조건만 변경해야 실제 원인을 파악할 수 있습니다.
문제 해결 Q&A 보기규칙 모드는 도메인, IP와 규칙 세트에 따라 요청을 여러 정책으로 나누므로 일상적인 사용에 적합합니다. 전역 모드는 대부분의 요청을 하나의 정책으로 보내 특정 출구의 사용 가능 여부를 짧게 확인할 때 유용합니다. 전역 모드는 규칙 문제를 대신 해결하지 않으므로 테스트가 끝나면 설정 목적에 맞는 원래 모드로 돌아가야 합니다.
모드 설정 단계 보기대부분의 경우 그럴 필요가 없습니다. 먼저 구독 주소가 완전하고 여전히 접근 가능한지 확인한 다음, 응답 내용을 현재 코어가 파싱할 수 있는지와 로컬 캐시 및 시스템 시간을 점검하세요. 클라이언트 파일 손상이나 버전 호환성 문제가 명확히 확인된 경우에만 재설치 또는 버전 변경을 고려하면 됩니다.
구독 업데이트 문제 해결 순서 보기Latest references
DNS, 시작 오류와 라우터 배포의 세 방향으로 더 알아보세요. 문서는 문제 해결 순서에 따라 조건과 한계를 설명하며, 모든 환경에 하나의 설정을 적용하지 않습니다.
Clash DNS 요청 경로, 주·보조 리졸버의 역할, fallback 필터 조건과 일반적인 오류의 점검 순서를 정리합니다.
손상된 설정, 권한 제한, 코어 파일과 시스템 구성 요소의 네 가지 방향에서 클라이언트가 시작되지 않는 원인을 찾습니다.
주 라우터와 보조 라우터 방식을 비교하고 아키텍처 선택, 장치 리소스, 전달 경로와 일상적인 유지 관리 범위를 설명합니다.