OS · 01
Windows
구독, 프록시 그룹, 시스템 프록시를 GUI로 관리하려는 데스크톱 사용자에게 적합합니다. 다운로드 전에 시스템 아키텍처를 확인하고, 현재 유지 관리 중인 Clash Plus, Clash Verge Rev, FlClash 또는 Clash Nyanpasu를 우선 선택하세요. Clash for Windows는 과거 프로젝트를 확인하기 위한 보관 항목으로만 제공합니다.
다운로드 페이지로 이동운영체제에 맞는 유지 관리 상태가 확실한 클라이언트를 선택한 뒤 구독 가져오기, 규칙 매칭, 네트워크 가로채기의 세 경로를 따라 설정을 완료하세요. mihomo 코어, DNS, TUN 및 자주 발생하는 연결 문제를 확인할 수 있는 경로도 함께 정리했습니다.
Platform entry · Plate 02
동일한 Clash 설정은 여러 GUI 클라이언트나 mihomo 코어에서 읽을 수 있지만 설치 방법, 시스템 권한, 유지 관리 상태는 서로 다릅니다. 먼저 기기의 운영체제를 확인한 다음 다운로드 페이지에서 클라이언트를 비교하면 아키텍처 불일치, 중단된 구형 프로젝트, 설정 디렉터리 혼용 문제를 피할 수 있습니다.
OS · 01
구독, 프록시 그룹, 시스템 프록시를 GUI로 관리하려는 데스크톱 사용자에게 적합합니다. 다운로드 전에 시스템 아키텍처를 확인하고, 현재 유지 관리 중인 Clash Plus, Clash Verge Rev, FlClash 또는 Clash Nyanpasu를 우선 선택하세요. Clash for Windows는 과거 프로젝트를 확인하기 위한 보관 항목으로만 제공합니다.
다운로드 페이지로 이동OS · 02
Apple Silicon 및 Intel Mac에 적합합니다. 설치 파일은 프로세서 아키텍처에 맞아야 하며, 처음 실행할 때 시스템 네트워크 및 프록시 권한을 승인해야 합니다. GUI 클라이언트로 일상적인 정책 전환을 할 수 있고, 세밀한 제어가 필요할 때는 설정 디렉터리, 강화 모드, 시스템 확장 상태를 확인하세요.
다운로드 페이지로 이동OS · 03
스마트폰, 태블릿 및 일부 Android TV 기기에 적합합니다. 클라이언트는 일반적으로 시스템 VPN 인터페이스로 트래픽을 가로채므로 동시에 다른 VPN 앱이 같은 인터페이스를 사용할 수 없습니다. 구독을 가져온 뒤 먼저 정책 노드를 선택하고, 앱의 배터리 최적화 및 백그라운드 실행 제한을 확인하세요.
다운로드 페이지로 이동OS · 04
iPhone과 iPad는 시스템 네트워크 확장을 통해 프록시 연결을 설정합니다. 다운로드 페이지에서 Clash Plus의 App Store 링크와 공식 사이트 정보를 제공합니다. 설치가 끝나면 구독 주소나 설정 파일에서 콘텐츠를 가져오고, 시스템 권한 대화상자에서 네트워크 설정 추가를 승인하세요.
다운로드 페이지로 이동OS · 05
데스크톱 환경에서는 GUI 클라이언트를 사용할 수 있으며, 서버·소프트 라우터·헤드리스 시스템에는 mihomo를 직접 실행하는 방식이 더 적합합니다. 배포할 때 바이너리 아키텍처, 설정 디렉터리, 서비스 계정을 구분하고, 프로세스 수명 주체가 systemd인지 컨테이너인지 현재 터미널인지 명확히 하세요.
다운로드 페이지로 이동Rule chain atlas · Plate 03
Clash의 핵심은 프록시를 단순히 켜고 끄는 것이 아니라 도메인 해석, 규칙 판단, 정책 선택, 시스템 트래픽 가로채기를 점검 가능한 하나의 실행 흐름으로 연결하는 데 있습니다. 각 단계의 입력과 출력을 이해해야 설정 변경과 장애 분석을 반복적인 시행착오에 의존하지 않을 수 있습니다.
Reading order
일반 프록시 요청은 보통 로컬 리스닝 포트로 들어온 뒤 설정에 따라 DNS와 규칙이 처리됩니다. TUN 모드에서는 가상 네트워크 인터페이스가 더 많은 시스템 트래픽을 수신합니다. 규칙은 설정 파일에 작성된 순서대로 위에서 아래로 매칭되며, 처음 일치한 항목이 대상 프록시 그룹을 결정합니다. 이후 프록시 그룹은 수동 선택, 자동 테스트 또는 장애 조치 결과에 따라 실제 아웃바운드를 정합니다. 웹페이지가 열리지 않으면 모든 옵션을 동시에 바꾸기보다 가로채기, 해석, 매칭, 선택, 연결 순서로 단계별 점검을 진행하세요.
Specimen 01 · Matching
규칙은 설정 파일 상단부터 아래로 확인되며 일치하면 즉시 중단됩니다. 자주 사용하는 유형으로는 도메인 완전 일치, 도메인 접미사, 프로세스, IP 대역, 지역 데이터, 기본 규칙이 있습니다. 사용자 규칙은 트래픽을 먼저 가로챌 수 있는 포괄적인 규칙보다 앞에 배치해야 합니다. 그렇지 않으면 문법이 올바르더라도 적용되지 않습니다. 전역 스위치만 제공하는 프록시 도구와 달리 Clash에서는 사이트, 프로그램, 주소 대역별로 독립적인 정책을 지정하면서 매칭 기록도 추적할 수 있습니다.
수정할 때 먼저 대상 도메인을 기록한 뒤 연결 또는 로그 페이지에서 실제로 매칭된 규칙을 확인하세요. 결과가 예상과 다르면 규칙 위치, 규칙 세트 업데이트 여부, 도메인의 IP 변환 여부, 대상 프록시 그룹 이름의 존재 여부를 차례로 점검합니다. 처음부터 노드를 바꾸지 마세요. 노드 연결과 규칙 매칭은 서로 다른 단계입니다.
DOMAIN-SUFFIX,example.com,PROXY도메인 접미사 → 프록시 정책GEOIP,CN,DIRECT주소 지역 → 직접 연결MATCH,FALLBACK미매칭 요청 → 기본 정책Specimen 02 · Selection
규칙은 보통 특정 노드를 직접 가리키지 않고 select, url-test, fallback, load-balance 같은 프록시 그룹을 가리킵니다. 따라서 구독을 업데이트하거나 노드를 교체할 때 전체 규칙을 다시 작성할 필요가 없습니다. 수동 선택 그룹은 출구를 직접 지정해야 할 때 적합하고, 자동 테스트 그룹은 측정 결과에 따라 사용 가능한 항목을 선택합니다. 장애 조치 그룹은 순서대로 확인하다가 현재 출구를 사용할 수 없으면 다음 항목으로 전환합니다.
정책 문제를 점검할 때는 규칙이 가리키는 그룹 이름과 그룹 내부의 현재 선택 항목을 함께 확인해야 합니다. 일부 사이트만 열리고 다른 사이트는 시간 초과가 발생한다면 시스템 프록시 전체가 고장 난 것이 아니라 서로 다른 규칙이 다른 정책으로 분기된 결과일 수 있습니다. 프록시 그룹 이름은 대소문자와 공백을 구분하므로 참조 이름이 정의와 완전히 일치해야 합니다.
Specimen 03 · Resolution
DNS는 도메인을 주소로 변환하는 데 그치지 않고 도메인 규칙의 가시성, 주소 규칙의 판단 방식, 요청이 최종적으로 연결되는 위치에도 영향을 줍니다. mihomo에서는 리스닝 주소, 상위 리졸버, 보조 리졸버, 분기 정책, Fake-IP 모드를 설정할 수 있습니다. Fake-IP를 활성화하면 클라이언트가 먼저 예약 주소를 반환하고 내부에 도메인 매핑을 저장하므로 TUN 트래픽도 도메인 규칙에 따라 처리할 수 있습니다.
IP 주소로는 접속되지만 도메인 접속이 실패한다면 먼저 DNS 로그, 상위 리졸버 연결 가능 여부, 시스템이 여전히 이전 리졸버를 사용하는지 확인하세요. nameserver, fallback, nameserver-policy를 변경할 때는 항목별로 테스트하고 현재 작동하는 설정을 보존해야 합니다. 이렇게 해야 DNS 오류와 노드 연결 오류를 혼동하지 않을 수 있습니다.
Specimen 04 · Capture
일부 프로그램은 운영체제의 HTTP 또는 SOCKS 프록시 설정을 따르지 않으며, 게임·명령줄 도구·특정 시스템 서비스가 직접 연결을 만들 수도 있습니다. TUN 모드는 가상 네트워크 인터페이스로 이런 트래픽을 수신한 뒤 mihomo의 DNS, 규칙, 정책 흐름으로 전달합니다. 적용 범위가 넓은 만큼 관리자 권한, 라우팅 테이블, 네트워크 인터페이스 드라이버, 다른 네트워크 소프트웨어와의 호환성도 고려해야 합니다.
활성화하기 전에 일반 시스템 프록시가 정상 작동하는지 먼저 확인한 뒤 TUN만 별도로 켜세요. 활성화 후 전체 인터넷이 끊기면 가상 인터페이스 생성 여부, 기본 라우트 등록 여부, DNS가 코어의 리스닝 주소를 가리키는지, 방화벽이나 다른 VPN이 같은 경로를 점유하는지를 차례로 확인합니다. 클라이언트를 반복해서 재설치하는 것보다 단계별 검증이 원인을 찾기 쉽습니다.
하나의 포트에서 HTTP와 SOCKS5 프록시 연결을 동시에 받아 데스크톱 프로그램에 로컬 프록시 주소를 통일해 입력할 때 적합합니다.
규칙표에 따라 요청의 경로를 결정하는 일반적인 모드입니다. 일상적인 사용에서는 전역 모드보다 직접 연결과 프록시 범위를 관리하기 쉽습니다.
예약 주소로 도메인 매핑을 유지하여 TUN이 가로챈 연결에서도 도메인 정보를 보존하고 규칙 매칭에 참여하게 합니다.
제어판이 실행 상태를 읽고 정책을 변경하는 관리 인터페이스입니다. LAN에 공개하기 전 접근 제어를 설정해야 합니다.
Selected questions
먼저 증상을 실행 흐름의 구체적인 단계로 좁힌 뒤 한 번에 하나씩 수정하세요. 전체 작업 절차는 사용 문서에서 순서대로 확인할 수 있습니다.
먼저 구독 응답이 Clash 또는 mihomo에서 읽을 수 있는 YAML 설정인지 확인하세요. 일반 웹페이지, 로그인 페이지, 다른 클라이언트 전용 형식의 콘텐츠일 수 있습니다. 그런 다음 구독 업데이트 기록의 파싱 오류를 확인하고 들여쓰기, 프록시 그룹 참조, 노드 필드를 중점적으로 살펴보세요. 구독에 인증이 필요하다면 링크가 만료되지 않았는지도 확인해야 합니다. 구독 가져오기 단계에서 계속 확인할 수 있습니다.
연결 상태는 코어 프로세스가 실행 중이라는 뜻일 뿐입니다. 시스템 프록시 활성화 여부, 브라우저의 독립 프록시 설정 사용 여부, 현재 프록시 그룹에서 사용 가능한 출구를 선택했는지, DNS가 응답하는지를 추가로 확인하세요. 먼저 직접 연결 사이트에 접속한 다음 연결 로그에 요청이 기록되는지 살펴보면 문제가 트래픽 가로채기 이전인지 규칙 처리 이후인지 판단할 수 있습니다.
일상적인 사용에는 규칙 모드를 선택해 설정이 도메인, 주소, 프로세스에 따라 트래픽 경로를 결정하도록 하는 것이 좋습니다. 전역 모드는 가로챌 수 있는 요청을 하나의 정책으로 모아 임시로 노드를 확인할 때 적합합니다. 직접 연결 모드는 프록시를 우회하여 문제가 프록시 경로에서 발생했는지 판단할 때 사용할 수 있습니다. 세 모드는 트래픽 결정 방식만 바꾸며 구독이나 노드 자체의 문제를 해결하지는 않습니다.
대상 프로그램이 시스템 프록시를 사용하지 않거나 명령줄 프로그램을 가로채야 하거나 더 많은 시스템 트래픽을 한 번에 처리해야 할 때 TUN을 고려하세요. 먼저 일반 프록시 모드를 안정적으로 작동시킨 뒤 TUN을 별도로 활성화하고 인터페이스, 라우팅, DNS를 확인해야 합니다. 그래야 인터넷이 끊겨도 기본 설정 문제인지 가상 인터페이스 가로채기 문제인지 구분할 수 있습니다. 자세한 순서는 사용 문서를 참고하세요.
Open source record · Plate 04
클라이언트 이름은 비슷해도 GUI, 코어 프로그램, 설정 형식은 서로 다른 계층입니다. 프로젝트 간 관계를 이해해야 업데이트 출처, 호환 범위, 문제를 어디에 제보할지 정확히 판단할 수 있습니다.
Clash는 널리 사용되는 YAML 설정 구조, 규칙 유형, 프록시 그룹 개념을 만들었고 이후 다양한 플랫폼용 GUI 클라이언트가 등장했습니다. 원 프로젝트의 유지 관리가 중단된 뒤에도 생태계가 하나의 새 프로젝트로 자동 통합된 것은 아닙니다. 클라이언트마다 선택한 코어, UI 프레임워크, 출시 주기가 다릅니다. 따라서 이름에 Clash가 포함되어 있다고 해서 같은 관리자가 배포한 제품이라고 볼 수 없으며, 오래된 가이드만으로 현재 호환성을 판단해서도 안 됩니다.
클라이언트를 선택할 때는 GUI 프로젝트와 포함된 코어의 유지 관리 상태를 함께 확인하세요. 기존 설정은 대체로 이전할 수 있지만 확장 필드, 규칙 세트 형식, DNS 동작, TUN 구현에는 차이가 있을 수 있습니다. 다운로드 센터에서는 현재 유지 관리 중인 선택지를 플랫폼별로 소개하고, 유지 관리가 중단된 프로젝트는 보관용으로 명확히 표시합니다.
전체 실행 흐름은 보통 GUI 클라이언트, mihomo 코어, 구독 설정, 규칙 데이터로 구성됩니다. GUI 클라이언트는 설정 가져오기, 프록시 그룹 표시, 시스템 프록시 전환, 프로세스 관리를 담당합니다. 코어는 포트 리스닝, DNS 해석, 규칙 실행, 아웃바운드 연결을 처리하고 규칙 세트는 도메인·주소·애플리케이션 분류를 제공합니다. 어느 한 계층의 업데이트라도 실패하면 노드 누락, 규칙 미매칭, 요청 시간 초과로 나타날 수 있습니다.
오픈 소스 코드를 통해 설정 동작, 매개변수 정의, 변경 기록을 커뮤니티가 검토할 수 있습니다. 문제가 발생하면 먼저 GUI 조작 문제인지 코어 실행 문제인지 확인한 다음 해당 프로젝트의 문서와 로그를 살펴보세요. 모든 문제를 클라이언트 이름 탓으로 돌리면 실제 오류가 발생한 구성 요소를 놓칠 수 있습니다.
mihomo는 현재 Clash 생태계에서 널리 사용되는 지속 유지 관리 코어로, 규칙 세트, DNS, TUN, 도메인 스니핑, 외부 제어 기능을 확장했습니다. 많은 데스크톱 및 모바일 클라이언트가 이를 GUI 내부에 통합하며, 사용자가 시작 버튼을 누른 뒤 실제로 로컬 포트를 열고 연결을 처리하는 것은 코어 프로세스입니다. 서버와 소프트 라우터 환경에서는 GUI를 거치지 않고 코어를 직접 실행할 수도 있습니다.
설정의 사용 가능 여부는 현재 코어가 지원하는 필드를 기준으로 판단해야 합니다. 어떤 클라이언트가 파일을 가져올 수 있다고 해서 모든 필드가 예상대로 실행되는 것은 아닙니다. 반대로 코어가 지원하는 새 필드가 GUI에 시각적 설정으로 제공되지 않았을 수도 있습니다. 세밀한 설정이 필요하다면 실행 로그와 실제 생성된 설정 파일을 함께 대조하세요.
클라이언트 업데이트, 코어 업데이트, 구독 업데이트는 서로 독립적인 세 경로입니다. GUI 클라이언트를 업데이트하면 인터페이스 수정과 새 코어 버전이 포함될 수 있지만 구독 서비스가 제공하는 노드와 규칙이 자동으로 바뀌지는 않습니다. 구독 업데이트는 설정 내용을 교체하지만 로컬 프로그램을 업그레이드하지는 않습니다. 규칙 세트도 자체 일정에 따라 다운로드될 수 있으므로 문제를 분석할 때 어느 계층이 변경되었는지 구체적으로 기록해야 합니다.
업그레이드 전에는 현재 작동하는 설정과 사용자 정의 오버라이드를 보존하는 것이 좋습니다. 업그레이드 후에는 먼저 구독 읽기, 프록시 그룹 표시, 시스템 프록시, DNS를 확인하고 TUN이나 복잡한 오버라이드를 단계적으로 복원하세요. 이렇게 하면 호환성 차이를 명확한 단계로 좁혀 한 번의 업데이트에서 여러 변수를 동시에 마주치는 일을 피할 수 있습니다.
Repository command
다음 명령은 공개 저장소를 복제하며 설정 정의, 변경 기록, 빌드 설명을 확인할 때 사용할 수 있습니다. 일반 클라이언트 사용자는 일상적인 설치를 위해 소스 코드를 이용할 필요가 없습니다.
git clone https://github.com/MetaCubeX/mihomo.git
Field notes · Plate 05
글은 구체적인 작업별 범위로 나누어 Linux 배포, 실행 로그 확인, LAN 프록시 공유를 다룹니다. 읽을 때 현재 클라이언트의 메뉴 이름과 비교해 본문의 코어 필드를 해당 설정 항목에 대응시키면 됩니다.
Linux GUI 클라이언트, mihomo 명령줄 코어, 서비스 자동 시작, 설정 디렉터리의 전체 배포 방법을 설명하고 임시 실행과 장기 서비스 관리를 구분합니다.
글 읽기 →시작, 구독, DNS, 연결, 규칙 매칭 단계별로 로그를 분석하고, 오류 기록 하나에서 구체적인 설정 항목을 찾아가는 방법을 설명합니다. 노드와 설정을 동시에 바꾸지 않아도 됩니다.
글 읽기 →mixed-port, LAN 접근 허용, 리스닝 주소, 방화벽 허용 규칙의 관계를 설명하고 공유 기기에서 연결할 수 없을 때의 점검 순서를 제시합니다.
글 읽기 →