5개 플랫폼 클라이언트, 구독 및 규칙 설정, 시스템 연동 문제 해결을 한곳에서 확인하세요. 먼저 운영체제와 프로세서 아키텍처를 확인한 뒤 해당 플랫폼에서 설치 파일과 설정 절차를 확인하세요.
홈에서는 플랫폼을 찾는 데 집중합니다. 설치 파일 유형, 클라이언트 유지보수 상태, 프로세서 아키텍처와 실제 다운로드 버튼은 다운로드 페이지에서 한 번에 확인할 수 있습니다.
Windows 10 및 Windows 11 데스크톱 환경에 적합합니다. 다운로드 페이지에서 먼저 시스템 비트를 확인한 다음 Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu 등 원하는 클라이언트를 선택하세요. 설치 후 시스템 프록시를 사용하거나, 권한과 트래픽 적용 범위에 맞춰 TUN 모드를 설정할 수 있습니다.
다운로드 페이지로 이동macOS 설치 파일은 Intel과 Apple Silicon을 구분해야 합니다. M1, M2, M3, M4 등 칩은 일반적으로 ARM 아키텍처를 선택하고, 구형 Intel Mac은 x64를 선택합니다. 처음 실행할 때는 시스템 안내에 따라 네트워크 확장, 프록시 설정 또는 보조 권한을 허용해야 하므로 파일 이름만 보고 설치 성공 여부를 판단하면 안 됩니다.
다운로드 페이지로 이동Android 페이지에서는 휴대전화와 태블릿에 맞는 클라이언트 다운로드 경로를 제공합니다. 최근 출시된 기기는 대부분 ARM64를 사용하며, 구형 기기는 ARM 또는 범용 패키지가 필요할 수 있습니다. 구독을 가져오면 시스템에 VPN 연결 확인 창이 표시됩니다. 사용자가 권한을 승인해야만 클라이언트가 규칙 엔진으로 앱 트래픽을 전달할 수 있습니다.
다운로드 페이지로 이동iPhone과 iPad에서는 App Store를 통해 Clash Plus를 설치합니다. 다운로드 페이지에서 스토어 링크와 공식 사이트 clashplus.io를 확인할 수 있습니다. 처음 설정을 활성화하면 iOS에서 VPN 구성 추가를 요청합니다. 시스템 인증을 완료한 뒤 클라이언트로 돌아가 구독, 정책 그룹과 연결 모드를 선택하세요.
다운로드 페이지로 이동Linux 데스크톱에서는 Clash Verge Rev 또는 FlClash를 선택할 수 있으며, 서버·소프트웨어 라우터·컨테이너 환경에서는 보통 mihomo 커널을 직접 배포합니다. 데스크톱 설치 전 deb, rpm 및 배포판 유형을 확인하세요. 명령줄 배포에서는 설정 디렉터리, 서비스 권한, 부팅 시 자동 시작과 프록시 환경 변수를 추가로 설정해야 합니다.
다운로드 페이지로 이동운영체제 이름이 같다고 설치 파일을 서로 바꿔 쓸 수 있는 것은 아닙니다. macOS는 Intel과 Apple Silicon을 구분해야 하고, Android에서는 ARM64, ARM, 범용 패키지가 흔히 사용됩니다. Linux에서는 AMD64, ARM64, ARMv7과 배포판별 패키지 형식까지 고려해야 합니다. 아키텍처가 맞지 않으면 설치 프로그램이 실행되지 않거나 지원되지 않는 파일이라는 메시지가 표시되고, 커널이 시작된 직후 종료될 수도 있습니다.
일반적인 데스크톱과 모바일 기기에서는 그래픽 인터페이스가 있는 클라이언트를 우선 선택하세요. 구독 업데이트, 정책 그룹 전환, 시스템 프록시와 로그 확인을 모두 화면에서 처리할 수 있습니다. 서버와 라우터에는 mihomo를 직접 실행하고 설정 파일, systemd 또는 컨테이너로 프로세스를 관리하는 방식이 적합합니다. 두 배포 방식은 규칙 개념이 비슷하지만 설치 경로와 문제 해결 지점은 다릅니다.
클라이언트 설치가 끝났다고 네트워크가 자동으로 연동되는 것은 아닙니다. 사용 가능한 구독 또는 로컬 YAML 설정을 가져오고, 설정을 업데이트한 뒤 정책 그룹을 선택해야 합니다. 기기 환경에 맞춰 시스템 프록시나 TUN 모드도 활성화하세요. 연결에 문제가 생기면 먼저 클라이언트 로그를 확인하고, DNS·포트·규칙·프록시 모드를 한꺼번에 변경하지 마세요. 어떤 설정이 영향을 주었는지 판단하기 어려워집니다.
요청이 클라이언트에 들어오는 순간부터 규칙 매칭, 구독 업데이트, 시스템 연동과 커널 호환의 범위를 단계별로 확인하세요.
규칙 모드는 모든 연결을 하나의 노드로 보내는 방식이 아닙니다. 클라이언트는 설정에 정의된 순서에 따라 도메인, IP, 프로세스, 포트 또는 규칙 제공자를 확인하고, 일치하면 지정된 정책 그룹으로 연결을 전달합니다. 정책 그룹은 특정 노드를 고정하거나 자동 테스트, 장애 조치, 부하 분산 방식으로 출구를 결정할 수 있습니다. 마지막의 MATCH는 앞에서 일치하지 않은 요청을 처리하므로 규칙 순서와 기본 정책이 실제 결과에 직접 영향을 줍니다.
잘못된 규칙 분기를 조사할 때는 먼저 로그에서 요청이 어떤 규칙에 일치했는지 확인한 다음 해당 규칙이 가리키는 정책 그룹과 현재 선택 항목을 점검하세요. 모든 연결을 전역으로 처리하는 도구와 달리 Clash 규칙 체계는 직접 연결, 프록시, 차단과 서로 다른 경로를 하나의 설정에 담을 수 있지만, 설정 관리자가 우선순위를 명확히 정해야 합니다. 수정할 때는 한 번에 한 규칙 그룹만 바꿔 상위 규칙이 하위 규칙을 가리지 않도록 하세요.
구독 링크는 일반적으로 원격 설정 파일이나 노드 목록을 반환합니다. 클라이언트가 다운로드를 마친 뒤에도 YAML을 파싱하고 로컬 사본을 저장한 다음, 프록시·정책 그룹·규칙·DNS 설정을 커널에 불러와야 합니다. 페이지에 업데이트 성공이라고 표시되는 것은 원격 콘텐츠를 가져왔다는 뜻일 뿐입니다. 사용 가능한 노드가 있는지, 현재 커널이 설정 문법을 인식하는지, 정책 그룹 참조가 완전한지는 설정 목록과 실행 로그로 다시 확인해야 합니다.
안정적으로 관리하려면 업데이트 시간, 업데이트 결과, 현재 활성화된 설정을 기록해 두세요. 구독에 실패하면 링크가 완전한지, 네트워크에서 구독 주소에 접근할 수 있는지, 응답이 유효한 설정인지, 클라이언트가 파싱 오류를 보고하는지를 순서대로 확인합니다. 앱 데이터를 통째로 반복 삭제하지 말고, 먼저 로컬 변경 사항을 내보낸 뒤 원격 설정 문제와 클라이언트 네트워크 문제를 구분하세요.
시스템 프록시는 운영체제의 HTTP, HTTPS 또는 SOCKS 프록시 설정을 주로 변경하며, 시스템 프록시를 따르는 앱은 요청을 클라이언트의 수신 포트로 전달합니다. 일부 명령줄 프로그램, 게임, 가상 머신과 자체 네트워크 스택을 사용하는 소프트웨어는 이 설정을 무시할 수 있습니다. TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 IP 트래픽을 처리합니다. 더 많은 앱에 적용할 수 있지만 추가 권한이 필요하고 DNS 및 라우팅 문제를 확인하는 경로도 달라집니다.
모드를 선택할 때는 모든 옵션을 동시에 켜기보다 어떤 트래픽을 연동할지부터 정하세요. 브라우저와 일반적인 데스크톱 앱은 먼저 시스템 프록시로 테스트할 수 있습니다. 프록시 설정을 따르지 않는 프로그램이 확인되면 TUN을 검토하세요. 활성화 후 인터넷에 연결되지 않으면 커널 로그, 가상 네트워크 카드 권한, 기본 라우팅, DNS 수신 포트와 다른 VPN 소프트웨어의 충돌을 먼저 확인하고, 노드 시간 초과와 시스템 연동 실패를 같은 문제로 취급하지 마세요.
Clash 생태계의 데스크톱·모바일 클라이언트는 주로 인터페이스, 설정 관리, 시스템 통합과 프로세스 제어를 담당하며, 실제로 규칙을 해석하고 연결을 전달하는 것은 하위 커널입니다. 클라이언트마다 포함된 커널 버전이 다를 수 있고 커널 교체를 지원하는 경우도 있습니다. 현재 널리 유지되는 분기는 mihomo이며 Clash Meta의 설정 기능을 계승하고 확장합니다. 원본 Clash와 일부 구형 클라이언트는 유지보수가 중단되었으므로 기존 설정을 사용할 수는 있어도 모든 새 필드가 호환된다고 가정해서는 안 됩니다.
클라이언트를 이전할 때는 현재 포트, DNS 모드, 규칙 제공자, 정책 그룹과 TUN 설정을 먼저 기록한 뒤 대상 커널이 지원하는 필드를 확인하세요. 그래픽 인터페이스의 이름이 비슷해도 설정 디렉터리와 시작 매개변수까지 같은 것은 아닙니다. 서버 배포에서는 커널 로그와 서비스 상태를 직접 확인해야 합니다. 인터페이스, 설정, 커널 문제를 계층별로 나누면 원인 범위를 크게 줄일 수 있습니다.
시스템 프록시 요청은 보통 클라이언트의 HTTP, SOCKS 또는 mixed-port에 도착하고, TUN 트래픽은 먼저 가상 네트워크 인터페이스로 들어갑니다. 앱의 요청이 로그에 전혀 나타나지 않는다면 노드를 바꾸기 전에 적용 경로, 수신 주소와 시스템 설정을 먼저 확인하세요.
도메인은 시스템에서 확인될 수도 있고 클라이언트 DNS 모듈로 전달될 수도 있습니다. fake-ip, redir-host, 원격 확인과 폴백 정책에 따라 조회 경로가 달라집니다. 도메인은 실패하지만 IP로 접속할 수 있다면 조회 체인을 따라 확인하고 노드 상태만 살펴보지 마세요.
로그의 규칙 이름, 정책 그룹과 최종 노드는 하나의 완전한 판정 기록을 구성합니다. 요청이 잘못된 출구로 나가면 더 앞선 규칙에 먼저 일치했는지 확인한 뒤 규칙 제공자의 업데이트 시간과 정책 그룹의 현재 선택을 점검하세요.
규칙이 올바르게 일치했는데도 연결이 시간 초과된다면 그때부터 노드 접근성, 프로토콜 매개변수, 로컬 방화벽과 대상 사이트를 중점적으로 확인하세요. 단계별로 원인을 좁히면 규칙, DNS, 시스템 연동과 노드 설정을 무작정 오가는 일을 줄일 수 있습니다.
클라이언트 이름, 그래픽 인터페이스와 프록시 커널은 서로 다른 프로젝트일 수 있습니다. 다운로드하거나 문제를 해결하기 전에 문제가 어느 계층에 속하는지 먼저 확인하세요.
Clash는 YAML 설정, 규칙 매칭, 정책 그룹과 다중 프로토콜 프록시를 기반으로 한 핵심 사용 방식을 처음 구축했습니다. 원본 프로젝트의 유지보수가 중단된 뒤에도 생태계는 하나의 소프트웨어로 통합되지 않았고, 여러 커널 분기와 그래픽 클라이언트가 계속 발전했습니다. 기존 튜토리얼을 읽을 때는 원본 Clash, Clash Meta, mihomo 또는 특정 클라이언트 중 무엇을 가리키는지 확인해야 합니다. 같은 이름의 설정도 버전에 따라 필드와 기본값이 다를 수 있습니다.
Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu, ClashX Meta 등의 이름은 보통 서로 다른 플랫폼 구현이나 그래픽 클라이언트를 가리킵니다. 클라이언트는 구독 관리, 정책 선택, 시스템 프록시 전환, 로그 확인과 업데이트 경로를 제공하고, mihomo 같은 커널은 수신 포트, DNS 로직, 규칙 매칭과 아웃바운드 연결을 담당합니다. 인터페이스는 열리지만 프록시가 작동하지 않는다면 커널이 정상적으로 시작되었는지 확인해야 합니다.
mihomo는 Clash Meta의 유지보수 방향을 이어가면서 규칙, DNS, 터널과 프로토콜 기능을 더 확장했습니다. 호환된다고 해서 모든 기존 설정을 그대로 복사할 수 있는 것도 아니고, 새 설정을 구형 커널에서 실행할 수 있다는 뜻도 아닙니다. 이전할 때는 로그 수준, 포트, 프록시 그룹, 규칙 제공자, DNS와 TUN 설정을 항목별로 불러오세요. 각 계층을 적용할 때마다 테스트하면 파싱 오류가 발생했을 때 문제 필드를 쉽게 찾을 수 있습니다.
이 사이트의 다운로드 페이지는 버전 목록을 통해 클라이언트 버전과 다운로드 주소를 표시하며, 버전 정보가 없으면 노출하지 않습니다. 프로젝트가 계속 유지되는지는 릴리스 기록, 커밋 활동과 공지를 함께 확인해야 하며 소프트웨어 이름이 널리 사용되는지만으로 판단할 수 없습니다. 유지보수가 중단된 클라이언트는 다운로드 목록에서 보관용으로 표시됩니다. 새로 설치할 때는 지속적인 릴리스 기록이 있고 현재 운영체제와 커널 설정을 지원하는 클라이언트를 우선 선택하세요.
아래 질문은 문제 해결 방향을 빠르게 정하는 데 도움이 됩니다. 용어 정의와 관련 개념은 용어 설명 페이지에서 이어서 확인할 수 있습니다.
먼저 설정이 정상적으로 로드되었는지, 정책 그룹에 사용 가능한 선택 항목이 있는지, 시스템 프록시가 켜져 있는지 확인하세요. 브라우저 요청이 클라이언트 로그에 나타나지 않는다면 대개 시스템 프록시나 트래픽 적용 경로의 문제입니다. 로그에 요청이 있다면 규칙 일치와 노드 연결을 계속 확인하세요. 용어 설명에서 시스템 프록시, 혼합 포트와 TUN의 차이도 확인할 수 있습니다.
업데이트 성공은 요청에 응답이 돌아왔다는 뜻일 수 있습니다. 응답이 유효한 설정인지, 클라이언트가 해당 필드를 파싱할 수 있는지, 프록시 목록이 비어 있지 않은지, 방금 업데이트한 설정이 현재 활성화되어 있는지를 추가로 확인해야 합니다. 업데이트 로그에서 YAML 파싱, 필드 호환성 또는 정책 그룹 참조 오류를 찾고, 용어 설명에서 구독과 로컬 설정의 관계를 확인하세요.
브라우저와 시스템 프록시를 따르는 데스크톱 프로그램은 설정 경로가 더 단순한 시스템 프록시부터 사용해 보세요. 게임, 명령줄 프로그램 또는 시스템 프록시를 무시하는 앱까지 적용하려면 TUN 모드를 검토합니다. TUN은 가상 네트워크 카드, 라우팅, 권한과 DNS 경로에 영향을 주므로 활성화한 뒤 이 항목들을 함께 확인해야 합니다. 관련 용어는 용어 설명에서 확인할 수 있습니다.
규칙 일치는 분기 단계가 완료되었다는 뜻일 뿐 아웃바운드 연결 성공을 보장하지 않습니다. 정책 그룹의 현재 선택, 노드 매개변수, 대상 주소 접근성, 로컬 방화벽과 네트워크 제한을 계속 확인하세요. 같은 노드가 모든 대상에서 실패한다면 노드와 프로토콜을 중점적으로 점검하고, 특정 도메인만 실패한다면 DNS, 대상 사이트와 세부 규칙 조건을 확인하세요. 용어 간 관계는 용어 설명에서 확인할 수 있습니다.
재현 가능한 네트워크 경로를 중심으로 점검 방법, 로그 분석, 설정 범위와 복구 절차를 각각 기록합니다.
테스트 결과, 시스템 조회 경로와 클라이언트 로그부터 확인하고 fake-ip, 원격 조회와 폴백 정책을 항목별로 설정합니다. 브라우저에 표시되는 결과, 운영체제 조회와 클라이언트 DNS 모듈을 구분해 단 한 번의 웹 테스트만으로 결론 내리지 않도록 설명합니다.
세 커널 분기의 프로젝트 관계, 설정 호환 범위와 유지보수 상태를 정리하고 그래픽 클라이언트와 커널을 어떻게 조합하는지 설명합니다. 설정을 이전하기 전에 다시 확인해야 할 필드와 현재 환경에 맞지 않는 오래된 튜토리얼을 판단하는 데 활용할 수 있습니다.
앱 요청부터 프록시 커널까지 이어지는 두 모드의 전체 경로를 비교하고 권한, 가상 네트워크 카드, DNS와 라우팅 문제를 해결하는 방법을 설명합니다. 일부 앱이 프록시를 거치지 않거나 TUN 활성화 후 인터넷이 끊기거나 시스템 프록시가 적용되지 않는 문제에 적합합니다.