Windows
트레이 제어, 시스템 프록시 전환과 TUN 모드가 필요한 데스크톱 사용자에게 적합합니다. 다운로드 페이지에는 Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu와 보관된 Clash for Windows가 순서대로 나열되며, 현재 유지보수 중인 프로젝트와 과거 클라이언트를 구분합니다.
다운로드 페이지로 이동운영체제에 맞는 GUI 클라이언트를 선택한 뒤, 실제 설정 용어를 기준으로 구독 가져오기, 규칙 라우팅 및 시스템 프록시를 구성하세요. mihomo 코어, 다중 프로토콜 호환성과 중국어 사용 문서를 중점적으로 다룹니다.
홈에서는 플랫폼별 분류만 제공하며, 구체적인 클라이언트 모델, 시스템 아키텍처, 설치 패키지 형식과 유지보수 상태는 다운로드 페이지에 한곳에 정리되어 있습니다. 플랫폼을 선택하면 해당 탭이 바로 열려 여러 설치 패키지를 반복해서 찾을 필요가 없습니다.
트레이 제어, 시스템 프록시 전환과 TUN 모드가 필요한 데스크톱 사용자에게 적합합니다. 다운로드 페이지에는 Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu와 보관된 Clash for Windows가 순서대로 나열되며, 현재 유지보수 중인 프로젝트와 과거 클라이언트를 구분합니다.
다운로드 페이지로 이동Intel 및 Apple 칩 기기에 적합합니다. 다운로드 페이지에 들어간 뒤 먼저 프로세서 아키텍처를 확인하고 Clash Plus, Clash Verge Rev, FlClash 또는 보관된 ClashX Meta를 선택하세요. 아키텍처가 다른 설치 패키지를 혼용하지 않도록 주의해야 합니다.
다운로드 페이지로 이동휴대폰, 태블릿 및 일부 TV 기기에 적합합니다. 다운로드 페이지에서 Clash Plus, Clash Meta for Android, FlClash와 Surfboard를 비교할 수 있습니다. 설치 전 기기 아키텍처에 맞춰 arm64, arm 또는 범용 패키지를 선택해야 합니다.
다운로드 페이지로 이동iPhone 및 iPad 사용자는 다운로드 페이지에서 Clash Plus의 App Store 페이지로 이동하고 공식 사이트 clashplus.io를 확인할 수 있습니다. 구독을 가져오면 시스템에서 VPN 구성을 확인하도록 요청하며, 연결 상태는 클라이언트와 시스템 설정에서 모두 확인할 수 있습니다.
다운로드 페이지로 이동데스크톱 환경에서는 Clash Verge Rev 또는 FlClash를 선택할 수 있으며, 서버·소프트 라우터·자동화 환경에서는 대개 mihomo 코어를 직접 사용합니다. 다운로드 페이지에서 배포판, CPU 아키텍처와 필요한 패키지 형식을 먼저 확인한 뒤 GUI 클라이언트와 명령줄 코어 중 하나를 선택하세요.
다운로드 페이지로 이동클라이언트 모델이 확실하지 않다면 각 클라이언트 카드의 지원 플랫폼, 유지보수 상태와 사용 목적을 먼저 확인하세요.
전체 클라이언트 보기 →왼쪽 목차에서는 주제를 전환하고, 가운데에서는 실제 설정 로직을 설명하며, 오른쪽에서는 지원 플랫폼·관련 프로토콜·다음 단계로 가는 경로를 제공합니다. 여러 개념을 하나의 기능 태그로 뭉뚱그리지 않고, 설정 파일을 읽는 단계부터 적용되는 순서에 따라 구성했습니다.
Clash Plus, Clash Verge Rev, FlClash 등의 프로젝트는 주로 인터페이스, 설정 관리, 트레이 제어와 시스템 통합을 제공합니다. mihomo는 YAML을 읽고 프록시 연결을 수립하며 DNS를 처리하고 규칙에 따라 정책을 선택합니다. 클라이언트를 고를 때는 운영체제와 유지보수 상태를 먼저 확인한 다음, 내장 코어가 설정에 사용된 프로토콜과 필드를 지원하는지 점검해야 합니다. 화면 모양만 비교하면 호환성을 실제로 결정하는 코어 버전을 놓치기 쉽습니다.
데스크톱 사용자는 구독 업데이트, 시스템 프록시 전환, 프록시 그룹 변경과 로그 확인을 한 화면에서 처리할 수 있어 대체로 GUI 클라이언트가 편리합니다. 서버나 라우터 환경에서는 리소스 제어, 서비스 관리와 설정 재현성이 더 중요하므로 mihomo를 직접 실행하는 편이 systemd, 컨테이너 또는 자동화 스크립트와 연동하기 쉽습니다. 두 형태의 핵심 개념은 같지만 설치 방식, 권한 범위와 문제 해결 경로는 서로 다릅니다.
구독 주소는 완전한 Clash 설정을 반환할 수도 있고, 프록시 노드 목록만 포함할 수도 있습니다. 완전한 설정에는 대개 proxies, proxy-groups, rules와 DNS 섹션이 포함되어 가져온 뒤 바로 라우팅 구조를 구성할 수 있습니다. 노드 목록만 있는 경우에는 클라이언트나 변환 서비스가 프록시 그룹과 규칙을 보완해야 합니다. 가져오기는 성공했지만 정책이 비어 있다면 시스템 프록시를 반복해서 전환하기보다 먼저 설정 콘텐츠의 유형을 확인하세요.
설정 업데이트는 구독 관리 범위에 속한 내용을 덮어쓰므로 로컬에서 임시로 수정한 내용이 오래 유지되지 않을 수 있습니다. 사용자 규칙이 필요하다면 클라이언트의 오버라이드, 병합 설정 또는 rule-providers 기능을 우선 사용해 개인 규칙과 상위 구독을 분리하세요. 그러면 노드 업데이트를 계속 받을 수 있고, 업데이트할 때마다 YAML을 다시 편집하는 수고도 줄어듭니다. 직접 편집할 때는 들여쓰기, 목록 계층과 현재 코어가 해당 필드를 지원하는지도 확인해야 합니다.
규칙 모드는 도메인, 도메인 접미사, IP 대역, 프로세스 또는 규칙 집합을 차례로 확인하며, 가장 먼저 매칭된 규칙이 연결을 어느 프록시 그룹으로 보낼지 결정합니다. 더 구체적인 규칙은 앞에, 범위가 넓은 규칙은 뒤에 배치하고, 마지막에는 MATCH가 아직 매칭되지 않은 연결을 처리합니다. 포괄적인 규칙을 앞에 두면 뒤의 세부 규칙은 문법이 올바르더라도 적용되지 않습니다. 이는 “규칙은 추가했지만 트래픽이 예상대로 라우팅되지 않는” 흔한 원인입니다.
대규모 설정은 규칙을 rule-providers로 분리해 독립 파일에서 관리하고 필요할 때 업데이트하는 방식이 적합합니다. 문제를 해결할 때는 규칙 제공자가 정상적으로 로드되었는지, 동작 유형이 일치하는지, 대상 프록시 그룹이 존재하는지, DNS 해석 결과가 IP 규칙에 영향을 주는지를 함께 확인해야 합니다. 규칙은 많을수록 좋은 것이 아닙니다. 명확한 우선순위, 안정적인 출처와 이해하기 쉬운 최종 매칭이 중복 항목을 쌓는 것보다 관리하기 쉽습니다.
select 그룹은 선택권을 사용자에게 맡기므로 고정된 출구나 명확한 전환 대상이 필요할 때 적합합니다. url-test는 테스트 결과에 따라 더 적절한 응답을 보이는 멤버를 선택하고, fallback은 현재 멤버가 작동하지 않을 때 다음 멤버로 전환하는 가용성에 초점을 둡니다. load-balance는 여러 멤버에 연결을 분산합니다. 이들은 같은 기능을 부르는 다른 이름이 아니며, 선택 방식·안정성·연결 일관성에서 뚜렷한 차이가 있습니다.
자동 프록시 그룹에는 테스트 주소, 탐색 간격과 허용 오차를 설정해야 합니다. 간격이 너무 짧으면 백그라운드 활동이 늘고, 허용 오차가 너무 작으면 전환이 잦아질 수 있습니다. 로그인 상태나 장시간 연결을 사용하는 앱에서는 출구 변경이 세션에 미치는 영향도 고려해야 합니다. 프록시 그룹을 만들 때는 수동 제어, 장애 인계 또는 연결 분산 중 목표를 먼저 정한 뒤 그룹 유형을 선택하고, 규칙에서는 장기간 안정적인 그룹 이름만 참조하세요.
시스템 프록시는 운영체제의 프록시 설정을 따르는 앱에 주로 영향을 줍니다. 켜고 끄는 방법이 직관적이어서 처음 설정할 때 검증 경로로 적합합니다. 일부 명령줄 프로그램, 게임 또는 자체 네트워크 스택을 사용하는 앱은 시스템 프록시를 무시할 수 있으므로 브라우저는 접속되더라도 다른 프로그램은 직접 연결할 수 있습니다. 문제를 해결할 때는 클라이언트 수신 포트, 시스템 프록시 상태와 해당 앱이 프록시 설정을 읽는지를 각각 확인하세요.
TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 트래픽을 가로채며, 추가 권한이 필요하고 라우팅·DNS·방화벽의 협력이 요구되는 경우가 많습니다. 더 많은 앱을 처리할 수 있지만 다른 VPN, 가상 머신 네트워크와 보안 소프트웨어가 충돌할 가능성도 커집니다. 먼저 시스템 프록시로 기본 동작을 확인한 뒤 실제 적용 범위에 따라 TUN을 활성화하세요. 문제가 생기면 권한, 라우팅, DNS, 충돌 소프트웨어 순서로 하나씩 점검하는 것이 좋습니다.
Clash는 코어, GUI 클라이언트, 규칙 집합과 설정 도구가 함께 구성하는 프로젝트 생태계입니다. Clash라는 이름이 붙은 모든 소프트웨어를 하나의 제품으로 보는 것보다 각 계층의 역할을 이해하는 편이 선택과 문제 해결에 도움이 됩니다.
원본 Clash는 YAML 설정, 프록시 그룹과 규칙 라우팅이라는 널리 쓰이는 모델을 정립했고, 많은 데스크톱·모바일 클라이언트가 이 모델을 바탕으로 GUI를 제공했습니다. 원 프로젝트가 보관 상태로 전환되면서 커뮤니티의 유지보수는 점차 후속 분기로 이동했습니다. Clash.Meta는 프로토콜, DNS, 규칙과 실행 기능을 확장했으며 이후 mihomo라는 이름으로 계속 유지되고 있습니다. 오늘날 “Clash 클라이언트”는 같은 저장소의 다른 설치 패키지가 아니라, 여러 GUI 프로젝트가 호환 코어와 설정 형식을 조합한 결과인 경우가 많습니다.
이 관계는 선택에 직접 영향을 줍니다. 과거 클라이언트는 계속 실행될 수 있지만 새로운 시스템 변화와 설정 필드에 지속적으로 대응하지 못할 수 있습니다. 활발히 유지되는 클라이언트는 내장 코어, 설치 방식과 시스템 통합 기능을 보통 업데이트합니다. 마이그레이션할 때 모든 설정을 한 번에 다시 작성할 필요는 없습니다. 먼저 구독 주소와 필요한 로컬 오버라이드를 복사한 뒤, 프록시 그룹·규칙 제공자·DNS·TUN 설정이 새 클라이언트에서 올바르게 인식되는지 하나씩 확인하세요.
GUI 클라이언트는 설정 프로필, 트레이 메뉴, 시작 프로그램 등록, 코어 제어와 시스템 프록시 전환을 담당합니다. mihomo 코어는 프로토콜 연결, 트래픽 탐색, DNS 처리, 규칙 매칭과 정책 실행을 담당합니다. 규칙 집합은 도메인이나 IP가 어느 프록시로 들어갈지 설명하고, 구독은 노드 또는 완전한 설정을 배포합니다. 어느 한 계층에서 문제가 발생해도 겉으로는 비슷한 증상이 나타날 수 있지만 해결 방법은 완전히 다릅니다.
예를 들어 “구독 업데이트 후 연결할 수 없음”은 구독 콘텐츠가 유효하지 않거나, 클라이언트가 설정을 올바르게 저장하지 못했거나, 코어가 특정 필드를 지원하지 않거나, 프록시 그룹이 존재하지 않는 멤버를 참조하거나, 시스템 트래픽이 애초에 클라이언트로 들어오지 않아서 발생할 수 있습니다. 무작정 재설치하기보다 계층별로 확인하는 편이 효과적입니다. 먼저 설정을 파싱할 수 있는지 보고, 다음으로 코어가 실행되는지 확인한 뒤 프록시 그룹과 로그를 점검하고, 마지막으로 시스템 프록시 또는 TUN의 가로채기 상태를 확인하세요.
mihomo는 Clash에서 널리 사용된 설정 구조를 이어받으면서 더 많은 프로토콜, DNS 옵션, 규칙 기능과 실행 매개변수를 추가했습니다. 기본 필드는 대체로 쉽게 옮길 수 있지만 tun, sniffer, geodata, rule-providers, profile 또는 실험 기능을 사용하는 설정은 현재 문서를 기준으로 확인해야 합니다. 클라이언트는 원본 YAML 외에도 자체 오버라이드 파일, 스크립트 또는 GUI 설정을 관리할 수 있으므로 설정 파일 하나만 내보낸다고 모든 로컬 상태가 포함되는 것은 아닙니다.
호환성을 판단할 때는 “클라이언트 버전이 어떤 코어를 지원하는가, 코어가 어떤 필드를 지원하는가, 현재 구독이 실제로 어떤 내용을 사용하는가”를 기준으로 삼아야 합니다. 이름만으로 기능을 추측하거나 특정 클라이언트 GUI의 옵션을 모든 플랫폼에 존재하는 공통 설정으로 간주하지 마세요. 프로토콜 핸드북에서는 SS, VMess, Trojan, VLESS, Hysteria2와 TUIC의 설계 중점, 그리고 서로 다른 코어와 구독 형식에서 이를 표현하는 방식도 비교합니다.
클라이언트 업데이트는 대개 인터페이스, 설치, 권한 또는 시스템 호환성 문제를 수정합니다. 코어 업데이트는 프로토콜 구현, 규칙 엔진, DNS와 설정 필드에 영향을 줍니다. 구독 업데이트는 노드, 프록시 그룹 또는 규칙 콘텐츠를 변경합니다. 세 업데이트의 시점은 서로 다릅니다. 문제가 발생했을 때 최근에 어떤 변화가 있었는지 기록하면 문제 해결 범위를 크게 좁힐 수 있습니다. 방금 구독을 업데이트했다면 설정 차이를 먼저 확인하고, 클라이언트를 업그레이드했다면 코어와 권한을 점검하세요. 네트워크만 바꿨다면 DNS, 라우팅과 연결 가능성을 우선 확인해야 합니다.
안전한 업데이트 절차는 현재 작동하는 설정을 보존하고 새 버전의 변경 사항을 읽은 다음, 업데이트 후 설정 로드와 기본 연결을 먼저 검증하고 TUN·오버라이드·자동 정책을 단계적으로 복원하는 것입니다. 장기 실행 서버에서는 설정을 버전 관리에 포함하고 서비스 관리자로 재시작을 제어하세요. 데스크톱 사용자는 클라이언트의 설정 백업과 로그 화면을 활용해 마이그레이션 근거를 남길 수 있습니다.
이 질문들은 다음에 읽을 경로를 정하기 위한 것이며, 전체 튜토리얼을 대신하지 않습니다. 먼저 최소한의 작동 설정을 완성한 뒤 복잡한 규칙과 트래픽 가로채기 방식을 단계적으로 추가하세요.
먼저 운영체제에 맞는 다운로드 페이지로 이동해 현재 유지보수 중이며 사용 중인 시스템 아키텍처에 맞는 설치 패키지를 제공하는 클라이언트를 우선 확인하세요. 통합된 인터페이스를 원한다면 Clash Plus를 먼저 살펴보고, 데스크톱 오픈 소스 작업 흐름을 선호한다면 Clash Verge Rev와 FlClash를 비교해 보세요. 설치 후에는 먼저 설정을 가져와 시스템 프록시로 확인하고, 처음부터 모든 고급 설정을 수정할 필요는 없습니다. 전체 시작 절차 보기 →
구독 콘텐츠가 proxy-groups와 rules를 포함한 완전한 Clash 설정이 아니라 노드 목록만 제공하는 경우가 있습니다. 설정 파싱에 실패해 일부 콘텐츠만 남았을 수도 있습니다. 먼저 클라이언트의 설정 오류 메시지와 구독 유형을 확인한 다음, 클라이언트 템플릿·구독 변환 또는 로컬 병합 설정을 사용할지 결정하세요. 출처가 불분명한 페이지에 민감한 정보가 포함된 구독 주소를 제출하지 마세요.
이는 대개 트래픽 가로채기 범위와 관련이 있습니다. 시스템 프록시는 시스템 설정을 읽는 앱에만 영향을 주며, 일부 프로그램은 자체 네트워크 설정을 사용합니다. 먼저 대상 앱이 HTTP 또는 SOCKS 프록시를 지원하는지 확인하고, 필요한 경우 TUN 모드를 검토하세요. TUN을 활성화하기 전에 권한, DNS, 라우팅과 다른 VPN 소프트웨어와의 충돌 가능성을 파악해야 합니다. 튜토리얼에 따라 시스템 프록시 확인 →
일반적인 업그레이드에서는 설정이 보존되지만, 클라이언트 간 마이그레이션, 제거 과정에서의 정리 또는 설정 디렉터리 변경이 있으면 다시 가져와야 할 수 있습니다. 작업 전에는 구독 주소, 오버라이드 규칙, 프록시 선택과 TUN 설정을 기록하세요. 업그레이드 후에는 설정 프로필이 존재하고 정상적으로 로드되는지 먼저 확인한 다음 코어, 시스템 프록시와 시작 시 자동 실행 상태를 점검하세요. 여러 변수를 동시에 변경하지 않는 것이 좋습니다.
최근 콘텐츠에서는 모바일 백그라운드 실행, Clash 오픈 소스 프로젝트의 관계와 프록시 그룹 선택을 다룹니다. 글은 다시 확인할 수 있는 설정 용어를 중심으로 구성되어 기본 설치를 마친 뒤 읽기 좋습니다.
백그라운드 유지, 시스템 배터리 제한, 규칙 복잡도와 연결 모드부터 확인해 모바일 배터리 소모 증가와 클라이언트의 잦은 재시작 원인을 찾습니다. 시스템 제한, 클라이언트의 지속적인 활동과 네트워크 재연결이라는 세 가지 현상을 구분하고 단계별 점검 경로를 제시합니다.
전체 글 읽기 →원본 Clash, Meta, mihomo와 주요 GUI 클라이언트의 관계를 정리하고 프로젝트의 목적, 유지보수 상태와 선택 범위를 설명합니다. 과거 클라이언트에서 마이그레이션하거나 설정 호환성 계층을 판단하려는 사용자에게 적합합니다.
전체 글 읽기 →세 가지 자동 프록시 그룹의 선택 로직, 전환 조건과 적합한 네트워크를 비교하고 테스트 간격, 허용 오차, 장애 인계와 연결 일관성의 관계를 설명해 안정적이고 예측 가능한 규칙 라우팅 구성을 돕습니다.
전체 글 읽기 →전체 목록에는 Windows UWP 루프백 제한과 서로 다른 Clash 코어 버전의 호환성 비교도 포함되어 있습니다.
전체 글 보기 →