먼저 세 가지를 구분하세요. 설정 파일은 설정을 저장하고, 규칙은 연결을 판별하며, 프록시 그룹은 연결 경로를 선택합니다. 서로 참조하지만 같은 스위치는 아닙니다.
규칙 기반 라우팅은 도메인이나 주소 등의 조건에 따라 연결 경로를 선택하는 방식입니다. 규칙은 보통 위에서 아래로 확인하며, 처음 조건에 맞는 규칙에 따라 해당 프록시 그룹으로 연결을 전달합니다. DOMAIN-SUFFIX는 도메인 접미사를, GEOIP는 주소의 국가·지역을 기준으로 매칭하고, MATCH는 앞선 규칙에 해당하지 않은 연결을 처리합니다. 문제를 확인할 때는 먼저 연결 기록에서 적용된 규칙을 찾고, 해당 규칙이 참조하는 프록시 그룹을 살펴보세요. 노드만 바꿔도 규칙 매칭 결과는 달라지지 않을 수 있습니다. 그림의 PROXY는 예시 그룹 이름이며, 실제 설정에서는 같은 이름의 프록시 그룹을 먼저 정의해야 합니다.
먼저 어떤 규칙이 적용됐는지 확인한 뒤 연결 경로를 바꿀지 판단하세요.YAML은 들여쓰기로 구조를 표현하는 텍스트 형식입니다. 최상위 필드마다 설정 종류가 다르고, 목록 앞의 하이픈은 항목 하나를 나타냅니다. 읽을 때는 포트와 모드를 먼저 확인한 다음 proxies, proxy-groups, rules 사이의 참조 관계를 살펴보세요. 처음부터 모든 필드를 외울 필요는 없습니다. 수정 전에 원본 파일을 저장하고 공백으로 들여쓰며 같은 단계의 항목을 맞춰 정렬하세요. 구독을 업데이트하면 설정 파일이 다시 생성될 수 있으므로, 변경 내용을 유지하려면 구독 원문을 계속 편집하기보다 클라이언트의 오버라이드 기능을 우선 사용하세요. 각 필드의 지원 여부는 현재 사용 중인 코어를 기준으로 확인해야 합니다.
구조부터 읽고 필드를 수정하세요. 한 번에 한 곳만 바꾸세요.프록시 그룹은 규칙에서 참조하는 연결 옵션의 묶음이라고 이해하면 됩니다. select는 보통 사용자가 직접 선택하고, url-test는 설정된 테스트 결과에 따라 연결을 선택하며, fallback은 연결 가능 여부에 따라 전환합니다. 그룹에는 노드뿐 아니라 다른 프록시 그룹도 포함할 수 있어, 화면의 버튼 하나가 서버 하나에 직접 대응하지 않을 수도 있습니다. 처음에는 수동 선택을 사용하고 연결이 정상인지 확인한 뒤 자동 그룹을 시도하세요. 테스트 결과는 특정 테스트 주소에서의 상태만 나타내며 모든 사이트에서 같은 결과를 보장하지 않습니다. 설정을 바꾸기 전에는 그룹 이름이 규칙에 적힌 이름과 정확히 일치하는지도 확인하세요.
규칙은 그룹을 지정하고, 그룹은 사용할 연결을 선택합니다.클라이언트는 조작 화면이고 코어는 실제로 연결을 처리하는 프로그램입니다. 같은 설정이라도 코어 기능이나 클라이언트의 오버라이드 방식에 따라 동작이 달라질 수 있습니다. 필드 오류가 발생하면 먼저 사용 중인 코어를 확인하고 해당 필드를 찾아보세요. 화면에 표시된 이름만으로 호환 여부를 판단하지 마세요. 첫 화면의 터미널에 표시된 내용은 독립된 규칙 예시이며, 프록시 노드가 포함된 완전한 구독 설정은 아닙니다.
YAML 안내서에서 필드 찾아보기 →먼저 운영체제를 고른 다음 프로세서 아키텍처를 확인하세요. 클라이언트 설치는 첫 단계일 뿐입니다. 이후 신뢰할 수 있는 구독이나 로컬 설정을 직접 준비해야 합니다. 다운로드 링크만으로 프록시 서비스를 이용할 수 있는 것은 아닙니다.
데스크톱에서 시작한다면 Clash Plus를 먼저 살펴보고, 사용 방식에 따라 Clash Verge Rev, FlClash 등과 비교해 보세요. 다운로드 전에 시스템 설정의 ‘시스템 정보’에서 기기 유형을 확인하고, 일반적인 x64 기기와 ARM 기기를 구분하세요. 설치 파일 이름이 비슷하다는 이유만으로 실행하지 마세요.
처음 테스트할 때는 시스템 프록시를 사용해 시스템 설정을 따르는 브라우저로 연결해 보세요. 일부 앱은 자체 네트워크 설정을 사용해 시스템 프록시를 따르지 않을 수 있습니다. 이 경우 안내에 따라 TUN 모드, 즉 가상 네트워크 인터페이스로 트래픽을 처리하는 방식을 검토하세요. 설치 및 권한 안내는 항목별로 확인하세요.
다운로드 Windows 클라이언트먼저 ‘이 Mac에 관하여’에서 Apple Silicon인지 Intel인지 확인한 뒤 알맞은 설치 파일을 선택하세요. 다운로드 페이지에는 클라이언트별 지원 파일이 정리되어 있습니다. 처음 사용하는 경우 Clash Plus를 먼저 살펴볼 수 있습니다. 기존 설정을 옮긴다면 새 클라이언트가 기존 필드를 인식하는지도 확인해야 합니다.
시스템 프록시와 네트워크 확장은 역할이 다르므로 구체적인 활성화 방법은 클라이언트 화면에서 확인하세요. 프록시 도구 여러 개가 동시에 네트워크를 제어하지 않도록 하세요. 클라이언트를 바꾸기 전에는 기존 도구를 종료하고 시스템 프록시 설정을 해제한 다음 새 설정을 가져오면 포트 충돌과 트래픽 경로 혼선을 줄일 수 있습니다.
다운로드 macOS 클라이언트모바일에서는 Clash Plus를 먼저 살펴보거나 Clash Meta for Android, FlClash, Surfboard와 비교해 보세요. 최근 기기는 대부분 ARM64를 사용하지만 기기 정보를 기준으로 확인해야 합니다. 클라이언트마다 지원하는 설정 형식이 다르므로 모든 구독을 범용 설정처럼 가져올 수는 없습니다.
연결 중 VPN 권한 요청이 표시되는 것은 클라이언트가 시스템의 트래픽 처리 인터페이스를 사용해야 한다는 뜻입니다. 시스템이 원격 노드를 자동으로 제공한다는 의미는 아닙니다. 화면을 잠근 뒤 연결이 끊긴다면 백그라운드 실행 및 배터리 제한을 확인하세요. 기본 연결을 먼저 테스트한 다음 백그라운드 설정을 하나씩 조정하세요.
다운로드 Android 클라이언트iPhone 및 iPad 사용자는 다운로드 페이지에서 Clash Plus의 App Store 링크와 공식 웹사이트 clashplus.io를 확인할 수 있습니다. 설치 후에는 클라이언트의 가져오기 안내를 읽고 구독 형식을 확인한 뒤 VPN 설정 추가를 허용하세요. 설치 전에는 App Store 상세 페이지의 시스템 요구 사항을 확인하세요.
모바일에서는 연결 스위치, 주문형 연결, 프록시 선택 메뉴가 서로 다른 화면에 있을 수 있습니다. 가져오기가 끝나면 설정을 현재 항목으로 선택한 뒤 연결을 시작하세요. 다른 네트워크 도구도 설치되어 있다면 다른 VPN 설정이 작동 중인지 확인해 도구 간 전환을 노드 문제로 오해하지 않도록 하세요.
다운로드 iOS 클라이언트데스크톱에서는 Clash Verge Rev와 FlClash를 비교하고 배포판에 맞는 패키지 형식을 선택할 수 있습니다. 설치 방법을 정하기 전에 배포판, 프로세서 아키텍처, 데스크톱 환경을 확인하세요. 서버나 라우터에서는 코어를 별도로 배포하는 경우가 많아 데스크톱 클라이언트 설치와 절차가 다릅니다.
브라우저, 데스크톱 환경, 명령줄 프로그램이 반드시 같은 프록시 설정을 사용하는 것은 아닙니다. 먼저 프록시를 지원하는 앱 하나로 테스트한 뒤 터미널 환경 변수, 서비스 권한, 라우팅을 확인하세요. 가상 네트워크 인터페이스를 활성화하기 전에는 기존 네트워크 설정을 살펴보고, 원격 기기에서는 연결을 복구할 방법을 미리 마련하세요.
다운로드 Linux 클라이언트검증 가능한 연결 절차를 먼저 완료하세요. 여기서는 핵심 순서만 다루며, 전체 가이드에서는 각 단계의 화면 위치와 확인 방법, 실패 시 대처 방법을 자세히 설명합니다.
Profile은 필요에 따라 전환해 사용할 수 있는 설정을 뜻합니다. ‘프로필’ 또는 ‘구독’ 화면에서 신뢰할 수 있는 링크를 추가하거나 로컬 YAML 파일을 가져오세요. 가져온 항목이 목록에 표시되는 것뿐 아니라 현재 설정으로 선택되었는지도 확인하세요.
실패 메시지가 표시되면 먼저 네트워크 다운로드 오류인지 내용 형식 오류인지 확인하세요. 브라우저에서 링크가 열려도 호환되는 설정이 반환된다는 보장은 없습니다. 로그인 페이지나 오류 안내 페이지는 구독으로 가져올 수 없습니다. 구독 링크에 접근 정보가 포함될 수 있으므로 공개 스크린샷에 노출하지 마세요.
규칙 모드는 설정된 조건에 따라 연결을 처리하므로 트래픽 분산을 이해하기에 좋습니다. 프록시 또는 프록시 그룹 화면에서 규칙이 참조하는 기본 그룹을 찾아 사용 가능한 연결 경로를 선택하세요. 중첩 그룹이 있다면 그룹 안에서 최종적으로 선택된 연결까지 확인하세요.
변수를 한꺼번에 많이 바꾸지 않도록 DNS와 기타 네트워크 옵션은 우선 기본값으로 두세요. 전역 모드는 트래픽의 정책 선택 방식을 바꾸는 기능이지 노드 오류를 해결하는 기능이 아닙니다. 직접 연결 모드로는 원격 프록시가 정상인지 확인할 수 없습니다. 모드를 확인한 뒤 시스템 프록시나 클라이언트가 요구하는 연결 스위치를 켜세요.
테스트할 웹사이트를 연 다음 클라이언트의 연결 기록에서 대상, 적용된 규칙, 연결 경로를 확인하세요. 테스트 주소에 접속할 수 있는지와 트래픽이 클라이언트로 들어오는지는 따로 판단해야 합니다. 해당 요청의 연결 기록이 있어야 현재 처리 경로에 요청이 들어왔음을 확인할 수 있습니다.
목록에 기록이 없다면 먼저 앱의 프록시 설정을 확인하세요. 기록은 있지만 접속에 실패한다면 선택한 연결 경로, DNS 확인 결과, 로그 오류를 살펴보세요. 테스트 시간과 오류 키워드를 기록하고 한 번에 한 항목만 바꿔 다시 테스트하면 변경 전후를 명확히 비교하고 원래 설정으로 되돌리기 쉽습니다.
이름이 비슷하다고 같은 프로젝트는 아닙니다. 코어, 인터페이스, 설정 출처를 구분하면 어떤 환경에 적용되는 안내인지 더 정확히 판단할 수 있습니다.
Clash의 규칙 설정 방식은 이후 여러 프로젝트에서 이어졌습니다. 원래 Clash 프로젝트의 유지 관리가 중단된 뒤에도 커뮤니티에서는 다양한 코어와 클라이언트가 계속 개발되고 있습니다. mihomo는 지속적으로 발전하는 오픈 소스 코어 중 하나이며, 프로젝트의 계보는 Clash.Meta와 관련이 있습니다. 이전 안내서에 나온 이름과 현재 인터페이스에 표시되는 이름이 다를 수 있습니다. 자료를 읽을 때는 Clash라는 이름이 붙은 모든 소프트웨어를 같은 제품으로 보지 말고 어떤 프로젝트를 가리키는지 먼저 확인하세요.
클라이언트는 설정 가져오기, 프록시 그룹 표시, 스위치와 로그 관리 등을 담당하고 코어는 설정을 해석해 연결을 처리합니다. 일부 클라이언트에는 코어가 포함되어 있으며 코어 전환이나 업데이트 기능을 제공하기도 합니다. 화면에 옵션이 있다고 해서 현재 코어가 해당 필드를 지원하는 것은 아닙니다. 반대로 코어가 지원하는 기능이 모두 인터페이스에 표시되는 것도 아닙니다. 호환성 문제가 발생하면 ‘Clash 오류’라고만 설명하기보다 클라이언트 이름과 코어 정보를 기록하는 편이 문제 해결에 도움이 됩니다.
오픈 소스 프로젝트의 코드, 문서, 이슈 논의를 통해 기능의 출처를 확인할 수 있습니다. 안내서를 볼 때는 먼저 해당 프로젝트 문서의 필드 정의를 확인한 뒤 구체적인 커뮤니티 사례를 참고하세요. 릴리스 노트는 설정 변경 이유를 설명하고 이슈 논의는 재현 조건을 제공하지만, 한 사용자의 해결 방법이 모든 기기에 적용되는 것은 아닙니다. 아래에는 소스 코드나 코어 동작을 확인하려는 사용자를 위해 mihomo 공개 저장소를 안내합니다. 일반적인 사용을 위해 프로그램을 직접 빌드할 필요는 없습니다.
클라이언트 업데이트, 코어 업데이트, 구독 업데이트, GeoIP 데이터 업데이트는 서로 다른 작업입니다. 구독 업데이트는 규칙과 노드를 교체할 수 있고, GeoIP 데이터는 IP 주소의 국가·지역 판정에 영향을 주며, 프로그램 업데이트는 지원 필드나 시스템 연동 방식을 바꿀 수 있습니다. 업데이트 전에 로컬에서 수정한 내용과 작동하는 설정을 저장하고 변경 사항을 확인한 뒤 각 항목을 따로 업데이트하세요. 문제가 생기면 변경을 계속 추가하기보다 정상 작동했던 설정과 상태로 먼저 되돌려 원인을 좁히세요.
Clash 입문 가이드는 한국어 입문 자료와 다운로드 목록을 제공하며, 생태계 프로젝트의 개발팀을 대표하지 않고 프록시 노드나 구독 서비스도 운영하지 않습니다. 이 사이트의 안내는 공통적인 사용 원리를 다룹니다. 권한, 시스템 지원 범위, 구체적인 필드 동작은 사용하는 클라이언트와 코어 문서를 함께 확인하세요. 또한 거주 지역의 법률과 네트워크 이용 규정을 준수해야 합니다.
Git을 사용할 수 있다면 명령어를 실행해 소스 코드를 내려받을 수 있습니다. 이 명령어는 저장소 내용을 가져올 뿐, 프로그램을 자동 설치하거나 프록시 설정을 변경하지 않습니다.
git clone https://github.com/MetaCubeX/mihomo.git기본 연결을 마친 뒤 실제 문제에 맞춰 더 자세히 살펴보세요. 모든 설정을 한꺼번에 바꾸지 말고 증상에 해당하는 글부터 확인하세요. 실행 실패, 앱에서 프록시가 작동하지 않는 문제, 설정 문법 오류는 각각 따로 점검해야 합니다.
로그 파일 위치부터 시작해 포트 충돌, 설정 문법 오류, 코어 파일 누락 등 실행 중 종료되는 원인을 차례로 확인하고 안전한 설정 복원 및 완전 재설치 방법을 안내합니다.
기술 노트 읽기 →완성된 config.yaml 파일을 위에서 아래로 살펴보며 각 항목의 역할, 항목 간 참조 관계, 자주 틀리는 위치를 설명합니다.
기술 노트 읽기 →UWP 네트워크 격리가 로컬 루프백 연결을 차단하는 이유를 설명하고, 클라이언트 내장 도구와 CheckNetIsolation 명령어로 스토어 앱 제한을 해제하는 방법을 안내합니다.
기술 노트 읽기 →설치, 설정, 연결 경로, 트래픽 처리를 구분한 뒤 증상에 맞게 확인하세요. 아래 질문을 펼쳐 볼 수 있으며, 다른 분류는 FAQ에서 확인할 수 있습니다.
클라이언트는 설정과 연결을 관리하는 기능을 제공할 뿐, 원격 프록시 노드를 자동으로 만들지는 않습니다. 신뢰할 수 있는 구독이나 로컬 설정을 준비해 가져온 뒤 현재 설정으로 선택하고, 프록시 그룹에서 연결 경로를 확인하세요. 화면에 연결 스위치가 있어도 처리 절차를 시작할 수 있다는 뜻일 뿐, 설정에 사용 가능한 노드가 있다는 의미는 아닙니다. 자세한 순서는 사용 안내를 참고하세요.
설정을 처음 익힐 때는 규칙 모드로 시작해 요청에 어떤 규칙이 적용되는지 확인하세요. 전역 모드는 보통 코어에 들어온 연결을 전역 정책으로 처리하지만, 원래 클라이언트에 들어오지 않던 앱 트래픽까지 자동으로 가져오거나 작동하지 않는 노드를 복구하지는 않습니다. 모드를 바꾼 뒤 결과가 달라졌다면 모드 이름만으로 원인을 추측하지 말고 연결 경로와 기록을 비교하세요. 규칙 구조는 YAML 안내서에서 확인할 수 있습니다.
노드 테스트는 특정 테스트 요청만 확인하므로 대상 웹사이트에 접속할 수 있다는 뜻은 아닙니다. 먼저 웹페이지 요청이 연결 목록에 표시되는지 확인한 다음 적용된 규칙과 실제 연결 경로를 살펴보세요. 요청이 클라이언트에 들어왔다면 DNS 확인 결과와 로그 오류를 추가로 확인하세요. 브라우저 캐시, 대상 사이트의 제한, 앱 자체 프록시 설정도 결과에 영향을 줄 수 있습니다. 반복해서 재설치하기보다 문제 해결 분류에 따라 하나씩 확인하세요.
그럴 수 있습니다. 원격 구독을 업데이트하면 설정을 다시 가져오는 경우가 많아 구독에서 생성된 파일을 직접 수정해도 내용이 유지되지 않을 수 있습니다. 먼저 원본 파일을 백업하고 클라이언트에서 오버라이드, 병합, 규칙 별도 관리 기능을 지원하는지 확인하세요. 변경 내용을 장기간 유지하려면 지속 저장이 명확히 지원되는 위치에 반영하고, 업데이트 후 실제 적용된 설정을 확인하세요. 동작은 클라이언트마다 다르므로 파일 이름만으로 판단하지 말고 설정 오버라이드 및 병합 안내부터 살펴보세요.