먼저 운영체제와 프로세서 아키텍처를 확인한 다음 설치 파일을 선택하세요. 데스크톱 GUI 클라이언트, 모바일 앱, 독립 실행형 코어는 사용 방법이 서로 다릅니다.
Clash Plus 같은 GUI 클라이언트부터 시작하세요. 설치 전에 시스템 아키텍처를 확인하고, TUN을 사용할 경우 클라이언트 안내에 따라 서비스를 설치하고 권한을 허용하세요.
다운로드로 이동 ›Apple Silicon용과 Intel용 설치 파일을 구분하세요. 처음 실행할 때 시스템 권한 안내를 확인하고, 연결 후 시스템 프록시와 네트워크 확장 상태를 점검하세요.
다운로드로 이동 ›기기 아키텍처에 맞는 앱 설치 파일을 선택하세요. 설정을 가져온 뒤 VPN 연결 요청을 허용하고, 백그라운드 실행 권한과 배터리 관리 설정을 확인하세요.
다운로드로 이동 ›다운로드 페이지에서 Clash Plus 스토어 링크를 확인하세요. 설치 후 구독을 추가하고 VPN 설정 생성을 허용하세요. 지원되는 옵션은 앱의 기능 범위를 확인해야 합니다.
다운로드로 이동 ›배포판에 맞는 패키지 형식을 선택하세요. 데스크톱에서는 GUI 클라이언트를 사용하고, 서버나 라우터에 배포할 때는 코어 프로세스와 네트워크 권한을 별도로 관리해야 합니다.
다운로드로 이동 ›클라이언트는 설정 가져오기, 프록시 선택, 시스템 연동을 담당하고 코어는 프록시 프로토콜과 분기 규칙을 실행합니다. 독립 코어만 다운로드하면 데스크톱 설정 창이 나타나지 않으며 시스템 프록시도 자동 설정되지 않습니다. 처음 사용하는 경우 GUI 클라이언트를 선택해 가이드에 따라 구독을 가져오고 연결을 확인한 뒤 투명 프록시나 라우터 배포를 검토하세요.
설치가 끝났다고 바로 사용할 수 있는 설정이 준비되는 것은 아닙니다. 구독 URL은 일반적으로 사용 중인 서비스에서 제공하며, 이 사이트에서는 노드나 구독을 생성하지 않습니다. 가져오기 전에 링크 출처를 확인하고, 접속 정보가 포함된 전체 URL을 공개 게시판에 올리지 마세요. 클라이언트를 바꿀 때는 기존 설정과 프록시 선택을 보존하세요. 새 클라이언트의 작동을 확인한 뒤 이전 클라이언트를 종료하면 같은 포트를 동시에 사용하는 충돌을 줄일 수 있습니다.
Clash for Windows를 이미 설치한 경우, 먼저 지원이 종료된 상태임을 확인하고 이전 여부를 검토하세요. 설정 파일을 보존해도 기존 옵션을 모두 그대로 사용할 수 있는 것은 아닙니다. mihomo를 사용하는 클라이언트로 옮긴 뒤에도 프록시 프로토콜, DNS 설정, 프록시 그룹 이름을 확인해야 합니다. 다운로드 페이지에서 플랫폼별 클라이언트를 확인하고, 시스템 요구 사항과 유지 관리 상태는 각 항목을 참고하세요.
필요한 작업에 맞춰 설정 옵션을 확인하세요. 아래 예시는 설정 구조를 설명하기 위한 것으로, 사용 전 현재 설정에 병합하고 참조 관계를 점검해야 합니다.
구독 관리는 설정의 출처와 지속적인 업데이트를 다루며, 네트워크 트래픽 처리 자체를 담당하지는 않습니다. 먼저 클라이언트의 설정 또는 구독 메뉴에서 URL을 추가하고, 업데이트가 완료되면 해당 설정을 선택한 뒤 프록시 그룹에 선택 항목이 표시되는지 확인하세요. URL이 반환하는 내용은 클라이언트가 지원하는 형식이어야 합니다. 노드 목록을 모두 완전한 YAML 설정으로 간주할 수는 없습니다. 노드를 하나씩 입력하는 것보다 구독을 이용하면 관리가 편리하지만, 원격 업데이트가 로컬 변경 사항을 덮어쓸 수도 있습니다. 개인 규칙은 클라이언트의 오버라이드 기능에 추가하는 것이 좋습니다. 업데이트에 실패하면 사용 가능한 설정을 반복해서 삭제하지 말고 다운로드 오류와 파싱 로그부터 확인하세요.
설정 참고 자료 보기 ›완전한 설정 파일에는 수신 포트, DNS, 프록시 그룹, 규칙을 함께 정의할 수 있습니다. 반면 프록시 목록은 프록시 항목만 제공하며, 일반적으로 proxy-providers로 불러옵니다. 두 파일의 역할이 다르므로 가져오는 메뉴도 다를 수 있습니다. 사용자 지정 분기 규칙을 유지하려면 기본 설정에서 프록시 목록을 참조하고, 프록시 그룹에서 use로 연결할 수 있습니다. 설정 전체를 교체하는 방식보다 노드 업데이트가 규칙 구조에 미치는 영향을 줄일 수 있지만, 이름과 경로, 프록시 그룹 참조는 직접 관리해야 합니다. 분리하기 전에 원본 파일을 백업하고 목록이 정상적으로 로드되는지 확인한 다음 한 항목씩 옮기세요. 한 번에 여러 계층을 수정하지 않는 것이 좋습니다.
규칙 모드에서는 목록 순서대로 연결을 확인하고, 일치하는 규칙을 지정된 정책에 전달합니다. 먼저 mode: rule인지 확인한 다음 범위가 명확한 도메인 규칙을 앞에 두고, 기본 처리용 MATCH는 마지막에 배치하세요. 규칙에 적은 프록시 그룹 이름은 정의된 이름과 완전히 일치해야 합니다. 그렇지 않으면 설정을 불러오지 못할 수 있습니다. 전역 모드와 달리 규칙 모드에서는 직접 연결과 프록시 연결을 함께 사용할 수 있지만, 실제로 적용되는지는 스위치만 볼 것이 아니라 연결에 적용된 규칙을 확인해야 합니다. 규칙을 추가할 때는 대상 하나씩 처리하고 도메인 및 하위 도메인의 범위를 확인해 다른 앱에까지 과도하게 적용되지 않도록 하세요.
규칙은 연결을 어떤 정책에 전달할지 정하고, 프록시 그룹은 실제로 사용할 출구를 결정합니다. 수동 선택 그룹은 직접 고정 선택할 때 적합하고, 자동 지연 테스트 그룹과 장애 조치 그룹은 각각의 조건에 따라 작동합니다. 먼저 그룹에서 참조하는 노드나 목록이 존재하는지 확인한 뒤 테스트 주소와 간격 등의 옵션을 조정하세요. 규칙에 노드를 직접 지정하는 것보다 프록시 그룹을 참조하면 규칙을 바꾸지 않고 출구를 변경할 수 있습니다. 단, 테스트 성공은 지정한 요청에 응답했다는 의미일 뿐 모든 사이트나 서비스가 정상이라는 뜻은 아닙니다. 접속 상태가 다르면 대상 도메인, 연결 로그, 출구의 지원 범위를 함께 확인하세요.
설정 참고 자료 보기 ›TUN은 가상 네트워크 인터페이스로 트래픽을 받아 시스템 프록시 설정을 읽지 않는 앱에 적합합니다. 먼저 클라이언트가 요구하는 서비스나 네트워크 구성 요소를 설치하고 권한이 있는지 확인한 다음 TUN을 켜고 라우팅과 DNS를 점검하세요. 시스템 프록시보다 처리 범위가 넓은 편이지만 운영체제, 라우팅 설정, 다른 네트워크 소프트웨어와의 호환성에 더 큰 영향을 받습니다. 켠 뒤 로컬 네트워크에 접속할 수 없다면 모든 프록시 노드를 바꾸기보다 라우팅 제외 설정과 DNS 결과부터 확인하세요. 데스크톱과 모바일 운영체제의 권한 처리 방식은 다르므로 한 플랫폼의 절차를 다른 플랫폼에 그대로 적용하지 마세요.
설정 참고 자료 보기 ›TUN을 켰다고 모든 연결이 프록시를 사용하는 것은 아닙니다. 처리된 트래픽도 현재 모드와 규칙에 따라 전달됩니다. 문제를 확인할 때는 먼저 대상 연결이 클라이언트의 연결 목록에 표시되는지 확인한 뒤 적용된 규칙과 최종 출구를 살펴보세요. 모드와 DNS, 노드를 한꺼번에 바꾸는 것보다 단계별로 확인해야 유효한 단서를 남기기 쉽습니다. 다른 VPN이나 가상 네트워크 어댑터를 사용 중이라면 여러 트래픽 처리 방식이 서로 덮어쓰지 않도록 기존 라우팅과 네트워크 상태를 기록하세요. TUN을 끈 뒤 접속이 복구된다면 프로토콜 옵션을 바꾸기 전에 인터페이스 선택, 라우팅 루프, 도메인 조회부터 확인하세요.
설정 참고 자료 보기 ›DNS는 도메인을 어떤 주소로 변환할지 결정하며 이후 규칙 판단에도 영향을 줍니다. 먼저 클라이언트 DNS가 활성화되어 있는지, 시스템이나 TUN의 요청이 클라이언트로 전달되는지 확인한 다음 상위 DNS 서버와 조회 모드를 점검하세요. 공용 DNS 주소 하나를 바꾸는 것보다 요청이 어떤 경로를 거치는지 파악하는 일이 더 중요합니다. 브라우저의 보안 DNS, 앱 자체 조회 기능, 시스템 캐시가 관찰 결과를 바꿀 수 있습니다. 변경 전에 기존 설정을 보존하고 동일한 도메인의 조회와 연결을 테스트해 어느 단계에서 실패하는지 기록하세요. 암호화 DNS를 사용하는 경우 상위 서버에 접근하는 네트워크 경로가 순환 의존성을 만들지 않는지도 확인해야 합니다.
설정 참고 자료 보기 ›Fake IP는 도메인과 연결 간의 연관성을 유지하는 기능이며 대상 서버의 실제 주소와 같지 않습니다. 일부 로컬 네트워크 서비스나 특수 앱에서 실제 조회 결과가 필요하다면 DNS 기능 전체를 끄기보다 필터 규칙을 검토하세요. 조회 모드를 전체적으로 바꾸는 것보다 범위를 명확히 한 예외가 영향을 관리하기 쉽습니다. 필터를 추가하기 전에 문제가 발생하는 도메인과 앱 동작을 확인하고, 수정 후 관련 캐시를 비운 뒤 다시 시도하세요. 규칙은 필요한 대상에만 적용해야 합니다. 로컬 네트워크 도메인 하나를 해결하려고 모든 사이트에 범위를 넓히면 기존 분기 판단에 필요한 도메인 정보가 사라질 수 있습니다.
설정 참고 자료 보기 ›여러 기기에서 사용할 때는 구독 출처와 규칙의 목적을 통일하고, 클라이언트 설정 전체를 그대로 복사하지 않는 것이 좋습니다. 데스크톱의 수신 포트, 서비스 설치 경로, TUN 권한 설정은 휴대폰에 그대로 적용하기 어렵습니다. 각 기기에서 같은 신뢰할 수 있는 출처의 구독을 가져온 다음 시스템 트래픽 처리 방식을 기기별로 설정하고 프록시 그룹 이름을 확인하세요. 앱 데이터를 통째로 동기화하는 것보다 공유 규칙과 기기별 옵션을 분리하는 편이 관리하기 쉽습니다. 클라이언트의 클라우드 동기화 지원 여부와 동기화되는 항목은 실제 기능을 확인하세요. 같은 구독을 사용해도 기기마다 프록시 선택이 자동으로 일치하지는 않으므로 변경 후 각각 확인해야 합니다.
설정 참고 자료 보기 ›구독 업데이트 과정에서 원격 설정이 다시 생성될 수 있으므로 개인 수정은 클라이언트가 지원하는 오버라이드나 병합 기능에 넣어야 합니다. 먼저 병합 방식이 목록을 어떻게 처리하는지 확인하세요. 어떤 기능은 전체를 교체하고, 어떤 기능은 앞에 삽입하거나 뒤에 추가하므로 동작이 모두 같다고 가정하면 안 됩니다. 구독 캐시 파일을 직접 수정하는 것보다 별도 오버라이드를 사용하면 이전이나 되돌리기가 편하지만, 프록시 그룹 참조가 유효한지는 확인해야 합니다. 기기 간에 복사할 때는 필요한 항목만 옮기고 로컬 경로나 컨트롤 인터페이스 설정은 포함하지 마세요. 업데이트가 끝나면 최종 적용 설정을 확인하고 새 규칙이 기본 규칙보다 앞에 있는지 검토한 다음 대상 연결에 실제로 적용되는지 테스트하세요.
설정 참고 자료 보기 ›클라이언트, 코어, 설정 출처를 구분해 이해하세요. 문제가 생기면 먼저 해당 동작을 담당하는 구성 요소를 확인하고 알맞은 문서와 문제 해결 방법을 찾아보세요.
Clash 생태계는 하나의 앱이 일괄적으로 업데이트되는 구조가 아닙니다. 과거의 Clash 코어와 이후 파생 프로젝트, 여러 GUI 클라이언트는 각각 다른 범위에서 배포 및 유지 관리됩니다. mihomo는 이 생태계에서 계속 개발 중인 코어 프로젝트이며, 많이 쓰이는 데스크톱 클라이언트는 코어에 설정 관리, 프록시 전환, 시스템 연동 인터페이스를 제공합니다. 화면이 비슷하더라도 코어 기능과 기본 설정까지 모두 같은 것은 아닙니다. 설정을 옮길 때는 실제로 실행 중인 코어와 클라이언트 문서를 기준으로 확인하세요.
GUI 클라이언트의 스위치는 코어 설정이나 운영체제 상태에 영향을 주는 경우가 많습니다. 예를 들어 시스템 프록시 스위치는 시스템의 프록시 설정을 바꾸고, TUN 스위치는 가상 네트워크 인터페이스와 라우팅에 영향을 줍니다. 일부 클라이언트는 실행 시 최종 설정을 생성하므로 디스크의 YAML 파일을 수정해도 화면에서 즉시 사용되지 않을 수 있습니다. 설정이 적용됐는지 판단하려면 현재 선택된 설정, 오버라이드 결과, 다시 불러온 로그를 함께 확인하세요. 파일 저장만 성공했다고 결론 내리면 안 됩니다.
오픈 소스 코드를 보면 구현 방식과 설정 변경 과정을 확인할 수 있지만, 일반 사용자가 앱을 설치할 때 저장소를 직접 이용할 필요는 없습니다. 처음 사용할 때는 다운로드 페이지에서 시스템에 맞는 클라이언트를 선택하면 됩니다. 하위 단계의 동작을 확인해야 할 때 mihomo 프로젝트 문서와 릴리스 정보 또는 관련 코드를 살펴보세요. 이 사이트는 한국어로 정보를 확인하는 경로와 옵션 설명을 제공하며, 서로 다른 클라이언트의 기능을 하나의 제품처럼 취급하거나 프로젝트 관리자를 대신해 호환성을 보장하지 않습니다.
Clash for Windows는 지원이 종료된 뒤에도 기존 환경에서 실행될 수 있지만, 이것만으로 새 운영체제나 프로토콜, 설정 옵션을 계속 지원한다고 볼 수는 없습니다. 이전할 클라이언트를 선택할 때는 유지 관리 상태, 사용 코어, 기기 아키텍처, 기존 설정의 기능 요구 사항을 확인하세요. 이름이 비슷하다는 이유만으로 프로그램을 바로 바꾸면 시스템 서비스, 설정 디렉터리, 시작 프로그램의 차이를 놓치기 쉽고 프록시 프로세스가 중복 실행될 수도 있습니다.
이전 전에 현재 설정을 내보내거나 백업하고 로컬 수신 포트, 사용 중인 프록시 그룹, 사용자 규칙을 기록하세요. 새 클라이언트를 처음 실행한 뒤에는 설정을 가져오되 모든 트래픽 처리 기능을 바로 켤 필요는 없습니다. 문법 검사가 끝나면 테스트 대상을 하나 정해 연결이 클라이언트에 표시되는지 확인하고 적용 규칙과 실제 출구를 살펴보세요. 이 연결이 검증된 후에 오버라이드, 로컬 네트워크 연결, TUN 등의 설정을 옮기세요.
포트가 이미 사용 중이라면 먼저 이전 클라이언트나 백그라운드 서비스가 계속 포트를 점유하고 있는지 확인한 다음 프로세스를 종료할지 포트를 바꿀지 결정하세요. 충돌을 해결하려고 기존 설정 디렉터리를 바로 삭제하지 마세요. mixed-port를 변경한 뒤에는 프록시 주소를 수동으로 설정한 앱도 함께 수정해야 합니다. 그렇지 않으면 코어는 정상적으로 시작되어도 앱은 계속 기존 포트에 연결합니다. 자주 발생하는 차이는 FAQ를 먼저 확인하고, 구체적인 작업 순서는 Clash 사용 가이드를 참고하세요.
코드가 오픈 소스라는 것은 구현을 확인할 수 있다는 뜻이지, 아무 구독이나 변환 서비스, 네트워크 출구를 신뢰해도 된다는 의미는 아닙니다. 클라이언트, 설정 제공자, 출구 서비스는 각각 다른 역할을 하며 클라이언트를 다운로드해도 원격 서비스가 자동으로 제공되지는 않습니다. 구독을 추가하기 전에 출처와 용도를 확인하고 설정에 어떤 프록시, 규칙, 상위 DNS 서버가 포함되어 있는지 파악하세요. 출처를 알 수 없는 완전한 설정은 트래픽 경로를 바꿀 수 있으므로 가져온 뒤에도 주요 옵션과 프록시 그룹을 확인해야 합니다.
구독 링크에는 접속 정보가 포함될 수 있으며 설정 파일에도 계정, 비밀번호, 전용 서버 정보가 들어갈 수 있습니다. 도움을 요청할 때는 클라이언트 이름, 운영체제, 오류 메시지, 민감한 정보를 삭제한 최소한의 설정만 제공하세요. 전체 설정 파일을 그대로 올리지 마세요. 스크린샷도 주소 표시줄, QR 코드, 로그에 민감한 정보가 없는지 확인해야 합니다. 규칙 문제를 설명할 때는 대개 규칙 순서와 관련 프록시 그룹 이름, 대상 연결에 적용된 결과만 있으면 충분합니다.
문제를 확인할 때는 테스트 조건을 가능한 한 일정하게 유지하세요. 먼저 대상 하나, 트래픽 처리 방식 하나, 출구 하나를 정한 뒤 DNS, 규칙, 연결 결과를 관찰하세요. 구독, 노드, 모드, DNS 방식을 한꺼번에 바꾸면 접속이 복구돼도 원인을 알아내기 어렵습니다. 작동하는 기준 설정을 보존하고 항목별로 바꾸며 결과를 기록하면 출처를 알 수 없는 옵션을 잔뜩 복사하는 것보다 장기적으로 관리하기 쉽습니다. 회사 네트워크나 관리 대상 기기를 사용하는 경우 해당 환경의 네트워크 사용 규칙도 따라야 합니다.
클라이언트, 코어, 구독, 규칙 리소스 업데이트는 각각 별개의 과정입니다. 앱을 업데이트해도 원격 구독이 갱신되는 것은 아니며, 구독을 업데이트했다고 코어가 새 옵션을 지원하는 것도 아닙니다. 특정 옵션을 파싱하지 못하면 먼저 어느 코어의 어떤 범위에서 사용하는 옵션인지 확인한 뒤 클라이언트가 실제로 실행 중인 코어 정보를 살펴보세요. 설정 파싱 오류를 노드 접속 불가로 단정하지 마세요. 두 문제는 서로 다른 단계에서 발생하므로 확인해야 할 근거도 다릅니다.
GeoIP나 규칙 리소스를 사용할 때는 설정에서 참조하는 데이터 형식과 저장 위치, 업데이트 메뉴를 확인하세요. 파일 이름만 바꿔서는 코어가 해당 파일을 읽는다고 보장할 수 없으며, 파일이 있어도 현재 규칙에 사용 중이라는 뜻은 아닙니다. 변경 후 설정을 다시 불러오고 로그에 리소스 로드 오류가 있는지 확인한 다음 대상 연결에 어떤 규칙이 적용됐는지 살펴보세요. 원격 규칙 목록을 쓴다면 리소스 다운로드 실패, 형식 오류, 규칙 순서 문제를 구분해야 합니다.
결과를 확인할 때 웹페이지가 열린 것은 첫 단계일 뿐입니다. 직접 연결해야 하는 로컬 네트워크 서비스, 시스템 프록시를 따르지 않는 앱, 기기가 절전 모드에서 깨어난 뒤의 연결도 확인하세요. 노드 지연 시간 테스트는 지정한 요청의 상태를 살펴보는 기능이며 실제 업무 서비스 테스트를 대신하지 않습니다. 문제가 발생하면 조건과 오류 메시지, 최근 변경 사항을 기록한 뒤 포트, DNS 조회, 규칙, 출구 순서로 범위를 좁히세요. 옵션별 설명과 YAML 예시는 설정 참고 자료에서 확인할 수 있습니다.
구체적인 문제에 맞는 작업 절차를 확인하세요. 먼저 트래픽이 지나가는 단계를 파악한 다음 관련 설정을 수정해 여러 변수를 동시에 바꾸지 않도록 하세요.
가상 네트워크 어댑터와 HTTP 프록시 설정, 두 가지 트래픽 처리 방식을 바탕으로 적용 범위, DNS 처리, 호환성을 비교해 상황에 맞는 방법을 선택할 수 있도록 안내합니다.
트래픽 처리 방식 비교 보기 ›라우터나 보조 라우터에서 mihomo 코어를 직접 실행하는 구조와 게이트웨이·DNS 지정 방법, 투명 프록시의 기본 설정을 정리합니다.
보조 라우터 배포 개요 보기 ›구독 URL 가져오기 메뉴와 업데이트 간격 설정, Clash YAML 및 Base64 노드 목록 등 자주 쓰이는 구독 형식의 차이와 호환성을 안내합니다.
구독 가져오기 안내 보기 ›