Clash는 모든 플랫폼에서 똑같이 동작하는 단일 앱이 아니라 프록시 도구 생태계입니다. 클라이언트는 설정 가져오기와 전환, 로그 확인을 위한 인터페이스를 제공하고, 코어는 프로토콜 연결과 규칙 실행을 담당하며, 설정 파일은 노드와 프록시 정책을 정의합니다. 클라이언트를 고를 때는 먼저 운영체제와 프로세서 아키텍처를 확인하고, 기존 설정을 코어가 지원하는지 살펴보세요. 인터페이스 이름이 비슷해도 설정 항목과 권한 요구사항은 다를 수 있습니다.
설정 화면에 서비스 제공업체가 안내한 구독 URL을 붙여 넣고 다운로드가 끝나면 해당 설정을 선택하세요. 그런 다음 프록시 화면에서 프록시 그룹에 사용할 수 있는 노드가 있는지 확인합니다. 가져오기에 성공했다는 것은 파일을 받은 것일 뿐, 시스템 트래픽이 프록시를 통과한다는 뜻은 아닙니다. 구독 URL에 접근 자격 증명이 포함될 수 있으므로 스크린샷, 로그, 문의 내용을 공유하기 전에 관련 정보를 삭제하세요.
일반적으로 규칙 모드부터 사용하는 것이 좋습니다. 요청은 대상 도메인이나 주소에 따라 규칙과 일치한 뒤 해당 프록시 그룹으로 전달됩니다. 수동 선택 그룹은 출구를 고정할 때, 자동 테스트 그룹은 설정된 조건에 따라 후보 노드를 고를 때 적합합니다. 특정 웹사이트에서 문제가 생기면 먼저 연결 화면에서 일치한 규칙과 실제 출구를 확인하세요. 곧바로 모든 트래픽을 전역 프록시로 바꿀 필요는 없습니다.
시스템 프록시는 시스템 프록시 설정을 따르는 앱에 주로 적용되고, TUN은 가상 네트워크 인터페이스를 통해 더 많은 트래픽을 처리합니다. 두 방식 모두 원격 회선 품질을 직접 개선하지는 않습니다. 문제를 진단할 때는 먼저 요청이 코어에 들어오는지 확인한 뒤 규칙, DNS 응답, 출구를 살펴보세요. 한 번에 설정 하나만 바꾸고 정상 작동하는 설정을 보존해야 변경 효과를 정확히 판단할 수 있습니다.
규칙은 위에서 아래로 확인하며, 일반적으로 처음 일치한 규칙에 따라 트래픽 경로가 결정됩니다. 구체적인 도메인 규칙을 포괄적인 규칙보다 앞에 두고, 마지막에 MATCH로 나머지 요청을 처리하세요. DOMAIN-SUFFIX는 도메인과 하위 도메인을 매칭하고, IP-CIDR은 IP 주소 대역을 매칭하며, GEOIP는 지리 데이터베이스를 사용합니다. 표의 PROXY는 예시 프록시 그룹 이름이므로 사용 전에 설정에 같은 이름의 그룹을 정의해야 합니다. 수정 후 설정을 다시 불러오고 연결 화면에서 실제로 매칭된 규칙을 확인하세요. 웹페이지가 열리는지만으로 결과를 판단하지 마세요.
프록시 그룹은 노드를 정리해 선택 가능한 출구로 만듭니다. select 그룹은 사용자가 직접 선택하고, url-test 그룹은 설정된 테스트 URL, 간격, 허용 오차를 바탕으로 후보 노드를 선택하며, fallback 그룹은 사용 가능 여부와 지정된 순서에 따라 전환합니다. 자동 선택이 실제 다운로드 속도를 항상 높여 주는 것은 아니며, 테스트 결과가 모든 웹사이트의 상태를 반영하지도 않습니다. 먼저 수동 선택 그룹으로 노드가 작동하는지 확인한 뒤 자동 정책을 사용하세요. 구독을 업데이트한 뒤에는 그룹 내 노드도 확인해 규칙이 삭제되거나 이름이 바뀐 그룹을 가리키지 않는지 살펴보세요.
| 유형 | 대상 | 정책 |
|---|---|---|
| DOMAIN-SUFFIX | github.com | PROXY |
| IP-CIDR | 192.168.0.0/16 | DIRECT |
| GEOIP | CN | DIRECT |
| MATCH | 나머지 요청 | PROXY |
이 예시는 규칙 매칭 관계를 설명하기 위한 것으로, 단독 실행 가능한 전체 설정이 아닙니다. 실제 네트워크에 맞춰 LAN 대역을 추가하고, 지리 규칙만으로 처리하지 말고 서비스 도메인을 명확히 지정하세요.
Clash 프록시 그룹 알아보기 →일부 명령줄 도구, 게임, 독립 네트워크 구성요소는 시스템 프록시를 사용하지 않습니다. 클라이언트가 TUN을 지원한다면 가상 네트워크 인터페이스와 라우팅 설정으로 해당 트래픽을 코어에 전달한 뒤 규칙에 따라 직접 연결하거나 프록시를 거치게 할 수 있습니다. 데스크톱에서는 서비스 모드나 관리자 권한이 필요할 수 있고, 모바일에서는 일반적으로 시스템 VPN 인터페이스를 사용합니다. 활성화하기 전에 일반 연결이 정상인지 확인한 다음 대상 앱을 따로 테스트하세요. TUN이 모든 트래픽을 처리하는 것은 아니며, 실제 범위는 라우팅 제외 설정, 플랫폼 권한, 다른 네트워크 소프트웨어에 따라 달라집니다.
DNS는 도메인을 IP 주소로 변환하며, 도메인 규칙에 필요한 정보를 얻는 데도 영향을 줍니다. Fake-IP 모드는 예약된 주소 대역을 사용해 도메인과 주소를 매핑하고 이후 연결을 도메인과 연결합니다. 실제 DNS 응답에 의존하는 기기나 앱에서는 코어 문서를 참고해 fake-ip-filter 설정을 검토할 수 있습니다. DNS 하이재킹, 시스템의 암호화 DNS, 앱 내장 DNS는 요청 경로를 바꿀 수 있습니다. 설정을 바꿀 때는 기존 값을 기록하고 한 번에 한 항목만 수정한 뒤 웹사이트 접속, LAN 서비스, 앱 로그인을 각각 테스트하세요.
TUN을 켠 뒤에는 버튼 상태만 확인하지 말고 코어 로그에 네트워크 인터페이스, 권한, 라우팅 오류가 있는지 살펴보세요. 데스크톱에서는 클라이언트 서비스가 올바르게 설치됐는지 확인하고, 모바일 기기에서는 VPN 권한이 해제되지 않았는지 확인합니다. 기존 VPN, 가상 머신 네트워크 인터페이스, 보안 소프트웨어가 기본 경로를 바꿀 수 있으므로 문제를 진단할 때 하나씩 비활성화해 비교하세요. 활성화 후 인터넷이 전혀 되지 않으면 먼저 TUN을 끄고 기본 연결을 복구한 다음 오류 정보를 저장하고 클라이언트 문서에 따라 권한과 라우팅 충돌을 해결하세요.
시스템 프록시와 TUN은 트래픽을 연결하는 방식이고, 규칙 모드는 출구를 선택하는 방식입니다. 서로 다른 계층에 해당하므로 TUN을 켜도 규칙 기반 라우팅을 사용할 수 있습니다.
네트워크 설정 전체 가이드 보기 →운영체제, 아키텍처, 권한 요구사항을 확인한 뒤 설치 방식을 선택하세요. 기존 설정이 있다면 사용하는 프로토콜과 코어 항목의 호환성도 확인해야 합니다.
처음 설정한다면 Clash Plus를 사용하거나 평소 사용 방식에 따라 Clash Verge Rev, FlClash 등을 선택할 수 있습니다. 다운로드 전에 시스템 설정에서 프로세서 아키텍처를 확인하세요. 컴퓨터 브랜드만으로 판단하면 안 됩니다. 설치 후 설정을 가져와 시스템 프록시를 활성화하고, 다른 앱의 트래픽까지 처리하려면 서비스 모드와 TUN 권한을 확인하세요.
브라우저는 접속되지만 일부 시스템 앱은 접속되지 않는다면 먼저 해당 앱이 시스템 프록시를 사용하는지 확인하세요. UWP 앱의 루프백 제한은 별도로 설정해야 하며, 노드 문제라고 단정할 수 없습니다. 클라이언트를 바꾸기 전에는 기존 클라이언트를 종료해 여러 프로그램이 같은 로컬 수신 포트를 점유하지 않도록 하세요.
다운로드 페이지로 이동Apple Silicon과 Intel 기기는 각 아키텍처에 맞는 설치 파일을 선택해야 합니다. Clash Plus, Clash Verge Rev, FlClash는 인터페이스와 설정 관리 방식이 다르므로 설치 전에 다운로드 페이지에서 비교해 보세요. 처음 실행할 때 시스템 안내에 따라 권한을 설정한 뒤 메뉴 막대에서 클라이언트가 실제로 실행 중인지 확인하세요.
시스템 프록시와 네트워크 확장은 권한 범위가 다르므로 트래픽 처리 방식을 변경한 뒤 대상 앱에서 다시 확인해야 합니다. 회사 네트워크가 자동 프록시나 특정 DNS에 의존한다면 기존 설정을 먼저 기록하세요. 클라이언트를 종료할 때 프록시를 정상적으로 끄지 않으면 시스템이 더 이상 연결을 받지 않는 로컬 포트를 계속 가리킬 수 있습니다.
다운로드 페이지로 이동설정 요구사항에 따라 Clash Plus, Clash Meta for Android, FlClash 중에서 선택할 수 있습니다. 설치 전에 기기의 아키텍처를 확인하고, 구독을 가져온 뒤 시스템 VPN 권한을 허용한 다음 프록시 그룹에서 출구를 선택하세요. Android VPN 인터페이스는 일반적으로 다른 VPN 앱과 동시에 사용할 수 없습니다.
화면을 잠근 뒤 연결이 끊긴다면 백그라운드 실행 권한, 배터리 최적화, 제조사별 절전 설정을 확인하세요. 모든 문제를 절전 정책 탓으로 돌리지 말고 모바일 데이터와 Wi-Fi를 비교하고, 구독이 만료되지 않았는지와 노드가 작동하는지 확인한 뒤 네트워크를 바꾸면 연결이 복구되는지도 살펴보세요.
다운로드 페이지로 이동다운로드 페이지에서 Clash Plus의 App Store 링크와 공식 웹사이트 clashplus.io를 확인할 수 있습니다. 설치 후 앱 안내에 따라 호환되는 설정을 가져오고 VPN 구성을 추가한 뒤 시스템 권한을 허용하세요. 처음 연결할 때 자주 사용하는 웹사이트를 테스트하고 앱에서 프록시 그룹과 연결 기록을 확인해 선택한 출구가 예상대로 작동하는지 살펴보세요.
모바일 운영체제는 백그라운드 실행과 네트워크 확장 기능을 제한하므로 데스크톱 가이드의 서비스 설치나 루프백 설정 절차를 그대로 적용할 수 없습니다. 구독을 불러오지 못한다면 시스템 VPN 구성을 반복해서 삭제하기보다 구독 형식과 클라이언트의 호환성을 먼저 확인하세요.
다운로드 페이지로 이동데스크톱 환경에서는 Clash Verge Rev와 FlClash를 비교하고 배포판에 맞는 패키지 형식과 시스템 의존성을 확인하세요. 터미널 프로그램은 데스크톱 프록시 설정을 자동으로 사용하지 않을 수 있습니다. 필요한 경우 현재 프로세스에 프록시 환경 변수를 설정하거나, 라우팅에 미치는 영향을 충분히 이해한 뒤 TUN을 활성화하세요.
서버와 라우터 사용자는 코어 섹션에서 Mihomo 패키지를 확인할 수 있습니다. 코어를 단독 실행할 때는 설정 경로, 서비스 권한, 로그를 직접 관리해야 합니다. 다른 기기의 네트워크 인터페이스 이름이나 라우팅 매개변수를 그대로 복사하지 마세요. 원격으로 설정을 변경하기 전에는 연결을 복구할 방법을 준비하세요.
다운로드 페이지로 이동프로젝트 출처, 클라이언트 유지 관리, 네트워크 서비스를 구분해야 업데이트와 문제 해결을 올바른 곳에서 진행할 수 있습니다.
Clash는 처음에 규칙 기반 프록시 코어를 중심으로 만들어졌으며, 이후 데스크톱 인터페이스, 모바일 클라이언트, 설정 도구를 포함하는 생태계로 확장됐습니다. 원본 프로젝트와 파생 프로젝트는 유지 관리 상태가 서로 다릅니다. 현재 Clash라는 이름은 코어, 설정 형식, 특정 클라이언트를 가리킬 수 있습니다. 따라서 호환성 문제를 논의할 때는 단순히 “Clash가 작동하지 않는다”고 하기보다 클라이언트 이름, 코어 종류, 운영체제 환경을 함께 기록하세요.
Clash 가이드는 클라이언트 다운로드 링크와 중국어 사용 안내를 정리한 사이트이며, 각 클라이언트의 개발팀이 아니고 프록시 노드 서비스도 제공하지 않습니다. 다운로드 페이지에서는 플랫폼별 클라이언트를 안내하고 유지 관리가 중단된 프로젝트를 표시합니다. 클라이언트를 선택할 때는 계속 유지 관리되고 기존 설정을 읽을 수 있는지 우선 확인하세요. 오래된 가이드의 화면 캡처와 항목 이름은 참고 자료로만 활용하고, 실제 사용법은 현재 클라이언트 문서를 따르세요.
Mihomo는 Clash 생태계에서 지속적으로 유지 관리되는 오픈 소스 코어로, 이전 이름은 Clash.Meta입니다. 코어는 프로토콜 처리, DNS, 규칙 매칭, 트래픽 전달을 담당하고 그래픽 클라이언트는 설정 관리, 시스템 통합, 사용자 인터페이스를 제공합니다. 인터페이스의 스위치 하나가 코어 매개변수와 시스템 설정을 함께 바꿀 수도 있습니다. 문제의 원인이 어느 계층에 있는지 확인하려면 먼저 설정이 불러와졌는지 확인하고 코어 로그를 살펴본 뒤 시스템 프록시와 라우팅을 점검하세요.
Clash 스타일 YAML과 호환된다고 해서 모든 코어가 같은 항목을 지원하는 것은 아닙니다. 최신 프로토콜, 규칙 제공자, DNS 옵션에는 특정 코어가 필요할 수 있습니다. 설정을 옮길 때는 원본 파일을 보존하고 새 클라이언트에 복사본을 가져오세요. 알 수 없는 항목이나 존재하지 않는 프록시 그룹 오류가 표시되면 설정 전체에서 DNS나 규칙을 지우지 말고 오류가 가리키는 위치를 확인하세요. 아래 명령은 Mihomo 소스 코드를 내려받기 위한 것으로 그래픽 클라이언트를 설치하거나 사용할 수 있는 노드를 만들지 않습니다.
클라이언트 업데이트는 시스템 통합과 인터페이스를 바꿀 수 있고, 코어 업데이트는 프로토콜과 네트워크 동작을 개선할 수 있으며, 구독 업데이트는 주로 노드, 프록시 그룹, 규칙을 새로 고칩니다. 서로 다른 업데이트입니다. 업데이트 전에 로컬 덮어쓰기 설정, 라우팅 규칙, 필요한 스크린샷을 저장하세요. 업데이트 후에는 설정이 계속 선택되어 있는지 확인하고 노드 목록과 트래픽 처리 방식을 점검합니다. 클라이언트, 구독, DNS를 한꺼번에 변경하면 문제가 어느 단계에서 시작됐는지 파악하기 어렵습니다.
구독 관리자가 직접 수정한 설정을 덮어쓸 수도 있습니다. 사용자 지정 규칙을 계속 유지해야 한다면 클라이언트가 덮어쓰기 또는 병합 기능을 지원하는지 확인하고 병합 후 최종 설정을 검토하세요. 해당 기능이 없다면 별도 사본이라도 보관해 다음 구독 갱신 때 설정이 사라지지 않도록 하세요. 부팅 시 자동 실행을 설정할 때는 클라이언트 자동 실행, 코어 시작, 프록시 복구를 각각 확인해야 합니다. 트레이 아이콘이 보이는지만 확인해서는 안 됩니다.
부팅 시 자동 실행 및 유지 관리 보기 →연결 화면에서는 요청 대상, 일치한 규칙, 출구 정책을 확인할 수 있고 로그 화면에서는 DNS 조회 실패, 핸드셰이크 실패, 권한 오류를 살펴보기 좋습니다. 속도 테스트에 표시되는 응답 시간은 특정 테스트 조건에서의 결과일 뿐, 대역폭이나 안정성 또는 모든 웹사이트의 접속 속도를 의미하지 않습니다. 비교 가능한 결과를 얻으려면 네트워크와 테스트 대상을 고정하고 후보 노드를 하나씩 바꿔 보세요.
문제 해결 정보를 공유할 때는 오류 유형, 발생 단계, 운영체제 환경, 관련 설정 항목을 남기되 구독 URL, 계정 정보, 노드 자격 증명은 삭제하세요. 브라우저는 정상인데 특정 앱만 문제가 있다면 트래픽 처리 범위를 먼저 확인하고, 모든 요청에 문제가 있다면 코어, DNS, 출구를 점검하세요. 여러 스위치를 연달아 바꾸기보다 변경 전후의 연결 기록을 비교하면 원인을 찾는 데 도움이 됩니다.
노드 속도 테스트 및 확인 방법 보기 →모바일 백그라운드 실행, DNS 모드, 속도 저하 원인을 주제별로 나눠 설정과 확인 방법을 안내합니다.
VPN 상시 알림, 백그라운드 제한, 제조사 절전 정책부터 확인하고 TUN 및 DNS 설정을 함께 살펴 배터리 소모 원인을 찾으세요. 지속적인 데이터 전송과 비정상적인 앱 깨우기를 구분한 뒤 백그라운드 권한을 조정해, 실제 트래픽을 고려하지 않고 실행 유지에만 집중하지 않도록 하세요.
글 읽기 →예약 주소와 도메인 매핑이 연결 처리에 어떻게 관여하는지 알아보고 두 DNS 모드의 동작 차이를 비교하세요. LAN 접속과 실제 IP 주소에 의존하는 앱을 고려해 예외 설정이 필요한지 판단하고 DNS 설정 전체를 무작정 바꾸지 마세요.
글 읽기 →노드 품질, 통신사 회선, 규칙 매칭, DNS 조회, 로컬 네트워크를 나눠 확인하세요. 다른 조건은 그대로 유지한 채 각 항목을 점검하고 반복 가능한 접속 결과를 비교해 높은 지연 시간, 낮은 처리량, 연결 실패를 구분하세요.
글 읽기 →