Windows
데스크톱에서 일상적으로 사용하기에 적합하며 Clash Plus, Clash Verge Rev, FlClash 또는 Clash Nyanpasu를 선택할 수 있습니다. 설치 후에는 시스템 프록시 권한을 확인해야 합니다. UWP 앱을 사용할 때는 루프백 제한이 로컬 프록시 접근을 방해하는지도 점검하세요.
Clash 클라이언트 설치 파일, mihomo 코어 설정 및 YAML 규칙 기반 분기 자료를 한곳에 정리했습니다. 먼저 운영체제에 맞는 그래픽 클라이언트를 선택한 뒤 필드 설명에 따라 구독을 가져오고, DNS 동작을 점검한 다음 규칙 매칭 결과를 확인하세요.
Clash의 요청 처리는 단일 스위치가 아니라 수신 진입점, DNS, 규칙 매칭, 프록시 그룹과 아웃바운드 연결로 이어지는 처리 체인입니다. 아래 인덱스는 실제 설정 관계에 따라 내용을 나누어 설명하므로, 각 필드가 어느 계층에 속하고 변경 후 어떤 요청에 영향을 주는지 쉽게 파악할 수 있습니다.
rules는 위에서 아래로 실행되는 순서가 있는 목록입니다. 도메인, IP, 프로세스 이름과 규칙 세트를 매칭 조건으로 사용할 수 있습니다.
규칙이 하나라도 일치하면 코어는 해당 항목이 지정한 프록시 그룹, DIRECT 또는
REJECT로 요청을 전달하고 이후 항목은 더 이상 검사하지 않습니다. 따라서 구체적인 도메인 규칙은 앞에 배치하고, 범위가 넓은
GEOIP, GEOSITE 및 최종 대체 규칙은 뒤에 둡니다.
분기 결과를 점검할 때는 노드를 바로 바꾸기보다 먼저 요청이 실제로 매칭된 규칙을 확인한 다음, 해당 규칙이 가리키는 프록시 그룹을 점검해야 합니다.
흔한 오차 원인은 규칙 순서, 도메인 접미사 범위, 업데이트되지 않은 규칙 세트 또는 DNS 응답 결과가 IP 규칙의 예상과 다른 경우입니다.
설정 필드 페이지에서는 DOMAIN, DOMAIN-SUFFIX,
IP-CIDR, MATCH 등의 문법과 적용 범위도 자세히 설명합니다.
프록시 그룹은 규칙과 프록시 노드 사이에 위치합니다. 수동 선택 그룹은 고정된 출구가 필요한 경우에 적합합니다. 자동 테스트 그룹은 설정된 탐지 주소, 간격과 허용 오차에 따라 사용 가능한 항목을 선택하고, 장애 조치 그룹은 구성원 순서대로 연결 가능한 아웃바운드를 찾습니다. 프록시 그룹 안에 다른 프록시 그룹을 포함할 수도 있어 지역, 용도와 전환 방식을 명확한 계층으로 나누고 규칙 파일에서 노드 이름을 반복하는 일을 줄일 수 있습니다.
설정할 때는 type, 구성원 출처, 상태 검사와 참조 이름을 함께 확인해야 합니다. 규칙에 사용한 프록시 이름은
proxy-groups의 이름과 한 글자까지 일치해야 합니다. 구독 업데이트 후 그룹 구성원이 고정된 이름에 의존하면 이전 이름이 더 이상 작동하지 않을 수도 있습니다.
대부분의 그래픽 클라이언트에서는 일상적인 전환이 프록시 그룹의 현재 선택 항목만 바꾸며 원본 구독 내용은 다시 작성하지 않습니다.
DNS 모듈은 애플리케이션의 질의를 받아 업스트림 서버를 선택하고 도메인 결과를 이후 규칙 판단에 전달합니다. fake-ip를 활성화하면 코어가 먼저 예약 주소 풀에서 매핑 주소를 반환하고, 애플리케이션이 연결을 생성한 뒤 매핑 관계에 따라 원래 도메인을 복원합니다. 이를 통해 도메인 규칙에 필요한 정보를 유지할 수 있습니다. 일부 LAN 기기, 연결성 검사와 실제 주소가 필요한 프로그램은 fake-ip-filter로 예외를 지정할 수 있습니다.
DNS 문제는 보통 ‘도메인을 해석할 수 없음’과 ‘해석은 성공했지만 연결에 실패함’을 구분해야 합니다. 점검 순서는 수신 주소, 기본 리졸버, 프록시 서버 도메인의 해석 경로, 암호화 DNS 연결 가능 여부와 시스템이 여전히 다른 인터페이스로 질의를 보내는지 확인하는 것입니다. 업스트림 주소만 바꿔서는 문제가 해결되지 않을 수 있습니다. 시작 단계의 해석, 규칙 판단과 프록시 경로가 서로 다른 서버 집합을 사용할 수 있기 때문입니다.
DNS 및 Fake-IP 용어 읽기 →그래픽 클라이언트는 일반적으로 원격 구독, 로컬 설정 사본과 현재 실행 설정을 별도로 저장합니다. 구독 업데이트는 서비스 제공자가 배포한 노드와 기본 정책을 가져오고, 로컬 오버라이드는 DNS, 규칙 또는 인터페이스 관련 설정을 추가하며, 실행 설정은 클라이언트가 병합을 완료한 뒤 코어에 전달하는 최종 결과입니다. 세 항목은 같은 파일이 아니므로 캐시 사본을 직접 편집하면 다음 업데이트에서 교체될 수 있습니다.
설정을 관리할 때는 먼저 클라이언트가 지원하는 오버라이드 방식을 확인한 뒤 앞부분 병합, 뒷부분 병합 또는 필드 단위 병합을 선택해야 합니다. YAML 들여쓰기는 일관되게 유지해야 하며, 같은 이름의 키를 덮어쓰는 방식은 클라이언트 구현에 따라 다릅니다. 배열 필드도 추가가 아닌 교체 방식일 수 있습니다. 가져오기에 실패하면 먼저 최소 설정으로 문법을 검증한 뒤 프록시, 프록시 그룹, DNS와 규칙을 단계별로 복원하면 호환되지 않는 필드를 더 빠르게 찾을 수 있습니다.
오버라이드 및 병합 방법 보기 →홈에서는 플랫폼 진입점만 제공합니다. 설치 파일 형식, 클라이언트 차이, 시스템 요구 사항과 지원 종료 상태는 다운로드 페이지에 모아 두어 서로 다른 아키텍처의 파일을 한곳에 섞지 않았습니다. 해당 탭으로 이동한 다음 기기 아키텍처와 사용 방식에 맞는 클라이언트를 선택하세요.
데스크톱에서 일상적으로 사용하기에 적합하며 Clash Plus, Clash Verge Rev, FlClash 또는 Clash Nyanpasu를 선택할 수 있습니다. 설치 후에는 시스템 프록시 권한을 확인해야 합니다. UWP 앱을 사용할 때는 루프백 제한이 로컬 프록시 접근을 방해하는지도 점검하세요.
Apple Silicon과 Intel 기기는 각각 해당 아키텍처용 파일을 다운로드해야 합니다. 처음 실행할 때 시스템 설정에서 네트워크 확장 또는 프록시 권한을 승인해야 할 수 있습니다. 메뉴 막대에 연결 상태가 표시되지만 요청이 코어를 거치지 않는다면 시스템 프록시와 강화 모드 설정을 추가로 확인하세요.
Clash Plus, Clash Meta for Android, FlClash 또는 Surfboard를 선택할 수 있습니다. 구독을 가져오면 시스템에서 VPN 연결 생성을 요청합니다. 배터리 절약 정책, 백그라운드 제한과 제조사 네트워크 관리 기능이 상시 연결을 끊을 수 있으므로 기기별로 확인해야 합니다.
iPhone과 iPad에서는 App Store에서 Clash Plus를 받을 수 있습니다. 처음 연결할 때 VPN 구성 추가를 승인해야 합니다. 구독을 가져온 뒤 먼저 정책을 선택하고 연결을 시작하세요. 시스템 상태 막대의 VPN 표시는 터널이 설정되었다는 뜻일 뿐이며, 실제 접속 결과는 규칙과 아웃바운드에 따라 달라집니다.
데스크톱 환경에서는 Clash Verge Rev 또는 FlClash를 사용할 수 있으며, 서버, 라우터와 컨테이너 환경에서는 보통 mihomo 코어를 직접 배포합니다. 파일을 선택할 때는 패키지 형식과 CPU 아키텍처를 구분하고, 서비스 관리, 작업 디렉터리와 설정 파일 읽기 권한을 직접 구성해야 합니다.
현재 기기에 적합한 클라이언트인지 판단하려면 그래픽 인터페이스, 프록시 코어와 설정 형식이라는 세 계층을 구분해야 합니다. 이들은 서로 다른 프로젝트가 관리할 수 있지만 유사한 설정 구조와 제어 인터페이스를 통해 함께 작동합니다.
Clash 생태계는 널리 사용되는 설정 모델을 형성했습니다. 프록시 노드는 proxies로 정의하고, 정책 선택은
proxy-groups로 구성하며, 요청은 rules를 순서대로 매칭하고 DNS 모듈은 해석과 도메인 매핑을 담당합니다.
원래 Clash 프로젝트가 지속적인 개발을 중단한 뒤에도 커뮤니티 포크가 호환 필드를 계속 확장했으며, mihomo는 현재 유지 관리되는 대표적인 코어 중 하나입니다.
따라서 이름이 다른 여러 최신 클라이언트도 내부적으로는 유사한 설정 구조, 제어 인터페이스와 규칙 의미를 중심으로 작동합니다.
Clash Plus, Clash Verge Rev, FlClash 및 기타 그래픽 클라이언트는 주로 구독 관리, 설정 전환, 시스템 프록시 제어, 로그 확인과 코어 수명 주기를 담당합니다. 실제로 DNS 처리, 규칙 매칭과 아웃바운드 연결을 실행하는 것은 클라이언트에 내장되었거나 클라이언트가 호출하는 코어입니다. 문제가 발생하면 먼저 오류가 인터페이스 계층인지 코어 계층인지 판단하세요. 인터페이스에서 설정을 저장하지 못하는 문제는 클라이언트 동작에 해당하고, 설정 해석 실패는 보통 필드 또는 코어 호환성과 관련이 있습니다. 연결은 되었지만 특정 웹사이트가 계속 잘못된 출구를 사용한다면 규칙과 프록시 그룹을 확인해야 합니다.
오픈 소스 저장소의 커밋 기록, 릴리스, 이슈 논의와 설정 문서를 서로 대조할 수 있습니다. 클라이언트 이름만 보는 것보다 최근 커밋이 지속되는지, 설치 파일이 현재 아키텍처를 지원하는지, 코어 버전이 설정에 사용한 필드를 지원하는지, 주요 변경 사항에 마이그레이션 안내가 포함되어 있는지를 확인하는 편이 효과적입니다. Clash中文은 클라이언트 비교 페이지에서 유지 관리 중인 프로젝트와 보관된 프로젝트를 구분하며, 다운로드 페이지에서도 지원 종료 상태를 해당 카드에 직접 표시해 설치 전에 선택할 수 있도록 돕습니다.
클라이언트 업그레이드, 코어 업그레이드와 구독 업데이트는 서로 다른 세 가지 작업입니다. 클라이언트 업그레이드는 인터페이스나 오버라이드 방식을 바꿀 수 있고, 코어 업그레이드는 필드를 추가하거나 조정할 수 있으며, 구독 업데이트는 주로 노드와 서비스 제공자가 제공하는 규칙을 교체합니다. 변경하기 전에 현재 작동하는 설정을 내보내고 사용 중인 정책 모드를 기록한 다음 한 번에 한 계층만 업데이트해야 합니다. 해석 오류가 발생하면 이전 설정으로 돌아가 로그의 필드 위치를 기준으로 하나씩 수정하세요. 클라이언트, 코어와 구독을 동시에 교체해서는 안 됩니다.
아래 질문은 첫 번째 판단을 위한 안내입니다. 전체 필드, 클라이언트별 차이 또는 단계별 문제 해결이 필요하다면 관련 도움말 페이지로 이동하세요. 로그와 설정 맥락 없이 여러 설정을 한꺼번에 변경하는 일을 피할 수 있습니다.
Clash는 일반적으로 설정 모델과 관련 생태계를 가리키고, mihomo는 지속적으로 유지 관리되는 호환 코어 중 하나이며, Clash Plus, Clash Verge Rev, FlClash 등은 그래픽 클라이언트입니다. 그래픽 클라이언트는 설정과 시스템 통합을 담당하고 코어는 해석, 매칭과 연결을 담당합니다. 더 자세한 계층 설명은 용어 매뉴얼에서 확인할 수 있습니다.
먼저 기본 네트워크가 정상인지 확인한 뒤 클라이언트가 코어를 시작했는지, 시스템 프록시 또는 VPN 권한이 적용되었는지, 프록시 그룹에서 사용 가능한 아웃바운드를 선택했는지, DNS가 해석되는지와 요청이 최종적으로 어떤 규칙에 매칭되었는지를 순서대로 점검하세요. 처음부터 DNS, 모드와 구독을 동시에 변경하지 말고 계층별로 확인해야 유효한 단서를 보존하기 쉽습니다. 전체 순서는 도움말 센터 문제 해결에서 확인하세요.
규칙 모드는 설정 파일의 규칙에 따라 각 요청의 경로를 결정하므로 일반적인 사용에 적합합니다. 전역 모드는 대부분의 요청을 지정한 정책으로 전달하므로 프록시 경로를 임시로 확인할 때 유용합니다. 직접 연결 모드는 문제가 프록시 경로에서 발생했는지 확인하는 데 주로 사용합니다. 문제 해결이 끝나면 보통 규칙 모드로 돌아가 로그에서 주요 도메인이 예상한 정책에 매칭되었는지 확인하세요.
원격 구독을 업데이트하면 보통 로컬 캐시 사본이 교체됩니다. 장기간 유지해야 하는 DNS, 규칙 또는 정책 변경은 구독 캐시를 직접 편집하지 말고 클라이언트가 지원하는 오버라이드 파일이나 병합 설정에 기록해야 합니다. 클라이언트마다 배열 추가, 같은 이름의 키 덮어쓰기와 스크립트 오버라이드 지원 방식이 완전히 같지 않으므로 오버라이드 및 병합 장을 먼저 확인하세요.
설치, 구독, 부팅 시 자동 시작, Fake-IP 또는 UWP 루프백 문제를 계속 확인해야 한다면 도움말 센터에서 분류별 질문과 답변 보기 →
각 글은 구체적인 작업을 중심으로 작성했으며 재현 가능한 점검 순서, 필드 범위와 플랫폼별 차이를 중점적으로 다룹니다. 먼저 기본 점검을 완료한 뒤 로그와 설정 상태에 따라 해당 장으로 이동하세요.
링크 상태, 응답 내용, YAML 들여쓰기, 필드 호환성과 로컬 캐시를 차례로 확인해 구독 가져오기 실패 원인을 찾고, 서버 응답 오류와 클라이언트 해석 문제를 구분합니다.
전체 글 읽기 →iPhone과 iPad에서 클라이언트를 받고 설정을 가져온 뒤 VPN을 승인하고 정책을 선택해 첫 연결 상태를 확인하는 전체 과정을 설명합니다.
전체 글 읽기 →지연 시간 측정값과 실제 사용 가능성을 구분하고, 트래픽 배율, 목적 지역, 프로토콜 특성과 일정 기간의 안정성을 함께 고려해 노드를 선택합니다.
전체 글 읽기 →