설치 전에 플랫폼과 아키텍처 확인
데스크톱 설치 패키지, 모바일 앱, 독립형 코어는 각각 사용 조건이 다릅니다. 먼저 기기를 선택한 다음 설정 관리와 트래픽 가로채기 방식을 비교하세요.
먼저 시스템 정보에서 프로세서 아키텍처를 확인하세요. Clash Plus부터 살펴본 뒤 Clash Verge Rev와 FlClash의 설정 관리 방식을 비교할 수 있습니다. 과거 클라이언트는 기존 설정 환경을 파악하는 용도로만 사용하세요.
처음에는 시스템 프록시가 실제로 적용되는지 확인하세요. 시스템 프록시를 따르지 않는 프로그램까지 가로채야 한다면 TUN에 필요한 서비스와 권한을 점검하세요. 시작부터 모든 기능을 동시에 켤 필요는 없습니다.
다운로드로 이동기기 아키텍처에 맞는 설치 패키지를 선택하고 시스템 버전 요구 사항을 확인하세요. 다운로드 페이지에는 Clash Plus, Clash Meta for Android, FlClash, Surfboard가 정리되어 있습니다. 설정 형식의 호환성은 확장자만으로 판단할 수 없습니다.
연결을 시작할 때 시스템 VPN 권한 안내를 읽으세요. 화면을 잠근 뒤 연결이 끊기면 백그라운드 활동과 배터리 제한을 먼저 확인하세요. 다른 VPN이 실행 중이라면 가로채기 충돌 여부도 점검해야 합니다.
다운로드로 이동다운로드 페이지에서 Clash Plus의 App Store 상세 페이지로 이동해 현재 시스템 요구 사항과 앱 설명을 확인하세요. 프로젝트 웹사이트는 clashplus.io이며, 설치 전에 지원 범위를 비교할 수 있습니다.
가져올 때 앱이 전체 설정을 받는지 노드 정보만 받는지 확인한 뒤 시스템 안내에 따라 VPN 설정을 추가하세요. 데스크톱의 서비스 설치나 포트 수신 단계는 휴대폰에 그대로 적용하면 안 됩니다.
다운로드로 이동‘이 Mac에 관하여’에서 Apple Silicon 또는 Intel을 확인한 뒤 해당 설치 패키지를 선택하세요. Clash Plus, Clash Verge Rev, FlClash를 비교 출발점으로 삼을 수 있으며, 보관된 프로젝트는 유지 관리 상태를 별도로 평가해야 합니다.
네트워크 확장이나 보조 서비스를 사용할 때는 시스템 권한 안내를 항목별로 읽으세요. 실행할 수 없다는 메시지가 나타나면 설치 출처, 아키텍처, 시스템 호환성을 먼저 확인하고 시스템 보안 기능을 끄는 것을 일반적인 해결책으로 삼지 마세요.
다운로드로 이동데스크톱 사용자는 Clash Verge Rev와 FlClash를 비교하고 배포판에 맞는 패키지를 선택할 수 있습니다. 설치 전에 아키텍처, 데스크톱 환경, 의존성을 확인하세요. 패키지 형식이 다르다고 프록시 프로토콜 지원 능력까지 같거나 달라지는 것은 아닙니다.
서버와 라우터 사용자는 Mihomo 독립형 코어를 추가로 살펴볼 수 있습니다. 코어 자체는 그래픽 클라이언트가 아니므로 설정 경로, 서비스 시작, 로그 보관, 네트워크 권한은 사용자가 직접 관리해야 합니다.
다운로드로 이동클라이언트를 다운로드하는 것은 도구를 준비하는 단계일 뿐, 사용할 수 있는 프록시 서비스가 자동으로 제공되는 것은 아닙니다. 설정 전에 신뢰할 수 있는 출처의 유효한 구독 또는 노드 정보가 있어야 합니다. 기존 설정을 저장한 뒤 이전하고, 여러 클라이언트가 동시에 시스템 프록시를 수정하지 않도록 하세요. 그렇지 않으면 하나를 종료한 뒤에도 인터넷에 연결되지 않을 수 있습니다.
설정 항목 — 설정 필드
자주 사용하는 네 가지 설정을 하나의 설정 흐름으로 설명합니다. 설명과 예시를 한 줄씩 비교할 수 있어 여러 페이지를 오가며 필드 의미를 추측할 필요가 없습니다.
Clash 규칙 기반 라우팅은 도메인과 대상 주소 등의 일치 조건을 처리 방식과 연결합니다. 규칙 모드를 선택하면 연결을 규칙 순서대로 검사하며, 일반적으로 앞쪽의 구체적인 조건이 먼저 적용되고 마지막에 기본 처리를 둡니다. 규칙의 대상은 프록시 그룹, 노드 또는 내장 동작일 수 있으므로 mode 필드만으로 연결 문제를 해결할 수는 없습니다.
전역 모드는 코어에 들어온 연결이 출구를 선택하는 방식을 바꿀 뿐, 기기의 모든 앱이 가로채진다는 뜻은 아닙니다. 화면의 모드 이름만 바꾸기보다 연결 기록에서 적용된 규칙과 실제 출구를 확인한 뒤 순서를 조정하는 편이 안정적입니다.
mode: rule
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- MATCH,DIRECT규칙 구조만 보여 주는 예시입니다. 여기서는 모두 직접 연결하며 프록시 노드를 포함하지 않으므로 실제로 권장되는 라우팅 구성을 의미하지 않습니다.
mode: global모드 필드만 보여 주는 예시입니다. 실제 출구는 전역 정책에서 선택해야 하며, 앱이 코어에 들어오는지는 시스템 프록시나 다른 가로채기 방식에 따라 달라집니다.
DNS는 도메인을 연결에 필요한 주소 정보로 변환하며, 코어가 도메인 기준으로 규칙을 적용할 수 있는지에도 영향을 줍니다. Fake-IP 모드는 가상 주소 매핑으로 도메인 연결을 유지하지만, 앱의 조회와 이후 연결이 해당 처리 경로로 들어가야 합니다. DNS 필드만 설정한다고 운영체제, 브라우저 또는 LAN 기기가 자동으로 이를 사용하는 것은 아닙니다.
Clash DNS 누수를 점검할 때는 시스템 리졸버, 브라우저 보안 DNS, TUN의 DNS 가로채기, 업스트림 요청의 출구를 각각 확인해야 합니다. LAN 서비스가 실제 주소에 의존한다면 현상에 맞춰 제외 항목을 설정하세요. 오류 하나를 없애기 위해 모든 도메인을 필터 목록에 넣어서는 안 됩니다.
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
nameserver:
- 1.1.1.1업스트림 주소는 목록 작성 방법을 설명하기 위한 예시일 뿐이며, 실제 네트워크와 개인정보 보호 요구 사항에 맞게 선택해야 합니다. 이 조각에는 시스템 DNS 가로채기와 업스트림 연결 정책이 포함되어 있지 않습니다.
프록시 그룹은 규칙의 대상을 받아 그룹에서 선택한 노드나 동작으로 연결을 넘깁니다. 따라서 노드를 바꿀 때마다 규칙을 하나씩 수정하지 않고도 규칙이 같은 그룹 이름을 계속 참조할 수 있습니다. 수동 선택 그룹은 설정을 먼저 검증할 때 적합합니다. 자동 테스트나 장애 조치 그룹에는 테스트 주소, 주기, 상태 확인 조건도 필요하며 유형 이름만 바꿔서는 충분하지 않습니다.
Clash 프록시 그룹의 이름은 규칙에서 참조하는 이름과 완전히 일치해야 합니다. 공백, 대소문자, 중복 이름 모두 인식에 영향을 줍니다. 테스트 결과는 지정한 테스트 대상에 도달할 수 있는지를 보여 줄 뿐, 모든 웹사이트에 연결된다는 증명은 아닙니다. 처음 가져올 때는 그룹 안에 선택 가능한 항목이 실제로 있는지 확인한 다음 선택 항목이 예상과 맞는지 점검하세요.
proxy-groups:
- name: 수동 선택
type: select
proxies:
- DIRECT
rules:
- MATCH,수동 선택이 예시는 이름 참조 관계를 보여 주기 위해 내장 직접 연결 동작만 사용합니다. 실제로 프록시를 사용하려면 유효한 노드를 별도로 정의하거나 코어 문법에 따라 프록시 그룹을 연결해야 합니다.
구독을 업데이트하면 다운로드한 설정이 교체될 수 있으므로 구독 원문을 직접 수정해도 오래 유지되지 않을 수 있습니다. 클라이언트가 로컬 오버라이드를 지원한다면 포트와 모드 같은 개인 설정을 별도로 저장하고 실행 설정을 생성할 때 적용할 수 있습니다. 이는 설정 관리 기능이며 모든 클라이언트가 따르는 통일된 코어 문법은 아닙니다.
병합 규칙은 특히 확인해야 합니다. 스칼라 필드는 교체될 수 있고 매핑은 재귀적으로 병합될 수 있으며 목록은 전체 교체되거나 순서대로 삽입될 수 있습니다. 홈페이지에서는 단순한 필드만 보여 주므로 노드와 규칙 목록도 같은 방식으로 병합된다는 뜻이 아닙니다. 수정 후 최종 적용 설정을 확인하고 구독 업데이트 뒤에도 사용자 설정이 남아 있는지 점검하세요.
# 로컬 오버라이드 조각, 클라이언트에서 처리
mode: rule
allow-lan: falseallow-lan: false는 LAN에서 들어오는 프록시 접근을 제한하지만 완전한 방화벽 정책을 의미하지는 않습니다. 수신 주소와 시스템 권한도 별도로 확인해야 합니다.
설정 파일에서 연결 확인까지
먼저 설명 가능한 연결 경로를 만든 뒤 복잡한 규칙을 추가하세요. 전체 절차는 빠른 시작 페이지에 정리하고, 여기서는 각 단계의 확인 목표만 안내합니다.
클라이언트의 설정 또는 구독 관리 메뉴에 신뢰할 수 있는 출처의 URL을 추가하거나 로컬 YAML을 가져오세요. 구독 링크, 단일 노드 공유 링크, 전체 설정은 서로 다른 입력 형식입니다. 메뉴가 맞지 않으면 형식을 먼저 확인하고 여러 곳에 반복해서 붙여 넣으며 추측하지 마세요.
가져오기가 끝나면 설정이 선택되었는지, 프록시 그룹이 표시되는지, 노드 필드가 인식되는지 확인하세요. 다운로드 성공은 콘텐츠를 받았다는 뜻일 뿐 코어가 이미 로드되었다는 의미는 아닙니다. 구독 URL에 접근 자격 증명이 포함될 수 있으므로 스크린샷, 로그, 문의 내용에서 민감한 부분을 먼저 삭제하세요.
먼저 규칙 모드를 사용하고 프록시 그룹에서 예상한 출구를 선택하세요. 데스크톱에서는 시스템 프록시부터 확인하고, 모바일에서는 앱 절차에 따라 VPN 권한을 부여합니다. 시스템 프록시는 해당 설정을 따르는 앱에만 영향을 줍니다. TUN은 가로채기 범위를 넓히지만 라우팅, 권한, DNS 설정이 함께 필요합니다.
‘LAN 접근 허용’을 로컬 기기의 인터넷 연결에 필요한 스위치로 오해하지 마세요. 같은 연결을 테스트하기 위해 여러 프록시 클라이언트를 동시에 실행하지도 마세요. 먼저 가로채기 경로 하나만 남기고 현재 설정을 기록한 뒤, 이후에는 한 번에 한 항목만 바꿔야 변화의 원인을 판단할 수 있습니다.
먼저 프록시를 끈 상태에서 기본 네트워크가 정상인지 확인한 다음 새로운 테스트 요청을 보내 클라이언트 연결 기록의 대상, 규칙, 출구를 관찰하세요. 브라우저에서 웹페이지 하나가 열렸다고 모든 앱이 가로채졌다는 뜻은 아닙니다. 기존 장시간 연결은 잠시 이전 경로를 유지할 수도 있습니다.
시간 초과가 발생하면 로컬 인터넷 연결, 구독 유효성, 노드 매개변수, DNS, 가로채기 방식 순서로 확인하세요. 네트워크를 바꾼 뒤 다시 검증해 테스트 주소에 접근할 수 없는 상황을 노드 장애로 잘못 판단하지 않도록 하세요. 사용을 마치면 시스템 프록시나 VPN을 정상적으로 끄고 직접 연결이 복구되었는지 확인하세요.
프로젝트 출처와 유지 관리 범위
프로젝트 이름이 비슷하다고 같은 팀이 관리하는 것은 아닙니다. 다운로드 선택, 설정 호환성, 문제 제보는 모두 구체적인 프로젝트와 실제 실행 구성 요소를 기준으로 확인해야 합니다.
Clash의 규칙과 YAML 설정 방식은 여러 클라이언트에서 이어졌고, 이후 다양한 코어 분기와 인터페이스 프로젝트가 등장했습니다. Mihomo는 이 생태계의 오픈 소스 코어 프로젝트입니다. 과거 자료의 Clash Meta라는 명칭과 관련이 있지만, Clash 이름이 들어간 모든 앱이 같은 코어를 사용한다고 단정할 수는 없습니다.
기존 가이드의 필드가 새로운 환경에서 오류를 내면 먼저 코어 문서와 변경 사항을 확인한 뒤 클라이언트가 설정을 다시 작성하는지 점검하세요. 특정 파일을 가져올 수 있다고 해서 모든 프로토콜, DNS 옵션, 실험적 필드를 실행할 수 있다는 뜻은 아닙니다. 같은 구독도 두 클라이언트에서 서로 다른 실행 설정이 될 수 있습니다.
클라이언트 업데이트는 구독 편집, 시스템 서비스, 오버라이드 로직을 바꿀 수 있고 코어 업데이트는 프로토콜 구현과 규칙 동작에 영향을 줄 수 있습니다. 업데이트 전에 원본 설정, 오버라이드 파일, 필요한 로그를 저장하고 업데이트 후 주요 연결을 다시 확인하세요. 백업 없이 클라이언트, 코어, 구독 형식을 동시에 바꾸는 것은 권장하지 않습니다.
오픈 소스 코드는 구현을 이해하고 문제를 추적하는 출발점을 제공하지만 저장소의 활동량을 연결 품질로 바로 환산해서는 안 됩니다. 유지 관리 상태는 프로젝트 공지, 릴리스 정보, 알려진 문제를 함께 보고 판단하세요. 보관된 소프트웨어가 실행되더라도 시스템 업그레이드 후의 호환성과 유지 관리 위험을 고려해야 합니다.
확인 경로도 문제 계층에 따라 나눠야 합니다. 설치와 권한 문제는 클라이언트 설명을 먼저 보고, 필드 파싱 실패는 코어 문서를 확인하며, 구독 업데이트 오류는 서비스 출처를 점검하세요. 웹사이트 접근성은 DNS와 연결 로그를 함께 살펴 판단해야 합니다. 계층을 나누면 반복적인 재설치나 낯선 전체 설정을 그대로 가져오는 것보다 원인을 찾기 쉽습니다.
주제별 안내 · 게시일순
기본 절차를 완료한 뒤 실제로 겪은 문제에 맞는 주제를 읽어 보세요. 먼저 현상이 어느 계층에서 발생했는지 정한 다음 조정할 설정을 선택하세요.
DNS 조회와 연결 수립 과정을 따라 가상 주소 매핑을 설명하고 Fake-IP의 적용 조건, LAN 호환성 문제, fake-ip-filter 설정 범위를 안내합니다.
Fake-IP 설정 안내 읽기 →인터페이스 충돌과 코어 시작 실패를 구분하고 시스템 아키텍처, 실행 의존성, 권한, 설정 파일을 차례로 확인합니다. 로그와 백업을 보존한 뒤 설정을 복구하는 방법도 설명합니다.
실행 오류 문제 해결 읽기 →로컬 인터넷 연결, 구독 유효성, 노드 매개변수, DNS, 프록시 가로채기를 단계별로 확인하고 테스트 주소 접근 불가와 실제 연결 실패를 구분해 반복적인 재설치를 피합니다.
연결 시간 초과 진단 읽기 →