자주 쓰는 설정 항목의 실제 관계
시스템 프록시는 운영체제의 프록시 설정을 따르는 앱을 클라이언트로 연결하고, TUN 모드는 더 다양한 시스템 트래픽을 가로채는 데 사용됩니다. 규칙 모드는 코어에 들어온 요청이 어떤 정책을 선택할지 결정하며, DNS 설정은 도메인 해석 과정에 영향을 줍니다. 네 항목은 서로 다른 단계에 있으므로 연결에 문제가 생기면 모든 스위치를 동시에 바꾸기보다 트래픽 경로를 따라 단계별로 확인해야 합니다.
Rule Observatory
클라이언트에서 헷갈리기 쉬운 설정 관계를 네 가지 관점으로 나눠 살펴봅니다. 먼저 요청이 규칙과 어떻게 일치하는지 확인한 뒤, 코어·구독·플랫폼 클라이언트의 역할을 구분합니다.
규칙 모드는 모든 연결을 하나의 노드로 보내는 방식이 아닙니다. 클라이언트는 설정의 rules 섹션을 읽고 도메인, 키워드, IP 대역, 프로세스 또는 규칙 집합 조건을 순서대로 확인한 다음 해당 규칙이 지정한 정책 그룹으로 요청을 전달합니다. 더 구체적이고 우선순위가 높은 조건은 보통 앞에 배치하며, 마지막의 MATCH는 앞선 규칙에 일치하지 않은 트래픽을 처리합니다.
라우팅을 조정할 때는 규칙 순서와 정책 그룹의 실제 선택 결과를 함께 확인해야 합니다. 규칙 이름만 보고 최종적으로 어떤 노드를 사용했는지 판단할 수는 없습니다. 정책 그룹은 직접 연결, 프록시 노드, 다른 정책 그룹 또는 차단 정책을 가리킬 수 있습니다. 실제 경로는 연결 페이지의 기록과 규칙 페이지의 검색으로 확인하는 것이 좋습니다.
데스크톱 클라이언트는 설정 가져오기, 시스템 프록시 전환, 정책 그룹 선택, 로그 및 연결 상태 확인을 담당하고, mihomo 코어는 설정 해석, 연결 수립, DNS 처리 및 규칙 매칭을 담당합니다. 두 구성 요소의 역할이 다르므로 문제를 진단할 때는 인터페이스 상태, 설정 내용, 코어 실행 단계 중 어디에서 문제가 발생했는지 먼저 구분해야 합니다.
mihomo는 Clash 설정 체계를 이어받으면서 규칙 집합, 프로토콜 및 DNS 기능을 확장했습니다. 기존 설정은 대체로 마이그레이션의 출발점으로 사용할 수 있지만, 전용 필드나 스크립트, 구식 provider 문법이 포함된 경우에는 현재 코어 문서를 기준으로 항목별 확인이 필요합니다. 클라이언트 업그레이드가 모든 기존 설정의 재작성으로 이어지는 것은 아니므로, 안정적으로 작동하는 설정은 우선 유지한 뒤 필요에 따라 조정할 수 있습니다.
구독 주소는 보통 완전한 YAML 설정이나 변환된 노드 목록을 반환합니다. 가져오기에 성공했다는 것은 클라이언트가 내용을 받아 해석했다는 뜻일 뿐입니다. 정책 그룹, 규칙 집합, DNS 및 노드 필드가 모두 포함되는지는 구독 출력 형식에 달려 있습니다. 노드는 있지만 규칙이 없는 경우에는 시스템 프록시를 반복해서 전환하기보다 먼저 설정 내용을 확인해야 합니다.
구독을 업데이트하기 전에 로컬 수정 사항의 출처를 기록해 두면 원격 업데이트로 수동 설정이 덮어쓰이는 일을 줄일 수 있습니다. 여러 구독을 함께 사용할 때는 용도별로 설정 파일을 나누어 저장하고, 출처가 다른 규칙과 정책 그룹을 직접 합치지 않는 것이 좋습니다. provider 방식의 외부 리소스는 리소스 주소, 업데이트 간격 및 참조 이름이 서로 일치하는지도 확인해야 합니다.
Clash Verge Rev는 주로 Windows, macOS 및 Linux 데스크톱 환경을 대상으로 합니다. Android에서는 Clash Plus, Clash Meta for Android, FlClash 또는 Surfboard를 선택할 수 있으며, iOS에서는 App Store를 통해 Clash Plus를 사용할 수 있습니다. 클라이언트마다 인터페이스 구조, 시스템 통합 방식 및 설정 확장 지원 범위가 완전히 같지는 않습니다.
기기 간에 설정을 옮길 때는 먼저 프로토콜, 정책 그룹 및 기본 규칙을 대상 클라이언트가 인식하는지 확인한 다음 TUN, DNS 또는 시스템 서비스와 같은 플랫폼별 설정을 조정해야 합니다. 설정을 가져올 수 있다고 해서 모든 동작이 동일한 것은 아닙니다. 특히 모바일 운영체제의 백그라운드 정책, 배터리 관리 및 VPN 권한은 연결 유지 방식에 영향을 줍니다.
시스템 프록시는 운영체제의 프록시 설정을 따르는 앱을 클라이언트로 연결하고, TUN 모드는 더 다양한 시스템 트래픽을 가로채는 데 사용됩니다. 규칙 모드는 코어에 들어온 요청이 어떤 정책을 선택할지 결정하며, DNS 설정은 도메인 해석 과정에 영향을 줍니다. 네 항목은 서로 다른 단계에 있으므로 연결에 문제가 생기면 모든 스위치를 동시에 바꾸기보다 트래픽 경로를 따라 단계별로 확인해야 합니다.
일반적인 데스크톱 사용은 구독 가져오기, 규칙 모드 및 시스템 프록시부터 시작하면 됩니다. 시스템 프록시를 사용하지 않는 앱까지 연결해야 할 때 TUN을 검토하고, 여러 기기에서 설정을 공유할 때는 프로토콜과 정책 그룹 구조를 단순하게 유지하는 것이 좋습니다. 서버나 라우터 환경에는 mihomo 코어를 직접 배포하고 설정 파일, 서비스 권한 및 시작 방식을 별도로 관리하는 편이 적합합니다.
Platform Entry
홈페이지에서는 플랫폼별 진입 경로만 제공합니다. 설치 패키지 유형, 클라이언트 유지 관리 상태 및 시스템 요구 사항은 다운로드 페이지에 정리되어 있으므로 해당 탭으로 이동한 뒤 적합한 클라이언트를 선택하세요.
Clash Verge Rev, Clash Plus, FlClash 또는 Clash Nyanpasu를 사용하려는 데스크톱 사용자에게 적합합니다. 다운로드 전에 시스템 아키텍처를 확인하고, 처음 실행한 후 가이드에 따라 설정을 가져오세요.
Apple Silicon 및 Intel 기기별 다운로드 경로를 제공합니다. 설치 후에는 시스템 안내에 따라 네트워크 확장, 시스템 프록시 또는 백그라운드 서비스 권한을 설정해야 합니다.
인터페이스 선호도와 설정 호환성에 따라 Clash Plus, Clash Meta for Android, FlClash 또는 Surfboard를 선택하고, 시스템의 백그라운드 제한에도 유의하세요.
iPhone 및 iPad 사용자는 App Store에서 Clash Plus를 받을 수 있습니다. 구독을 가져온 뒤 시스템 VPN 권한을 승인하고 정책 그룹을 선택하면 연결을 시작할 수 있습니다.
데스크톱 환경에서는 Clash Verge Rev 또는 FlClash를 선택할 수 있으며, 서버·소프트 라우터·명령줄 환경에서는 다운로드 페이지에서 mihomo 코어 패키지를 확인할 수 있습니다.
Open Source Context
Clash 클라이언트를 장기간 사용하기에 적합한지 판단하려면 화면 디자인만 비교하지 말고 코드 출처, 코어 의존성, 설정 호환 방식 및 릴리스 주기를 함께 확인해야 합니다.
Clash Verge Rev는 Clash Verge 계열을 이어가는 커뮤니티 프로젝트로, Windows, macOS 및 Linux 데스크톱 환경을 중점적으로 지원합니다. 설정 파일, 정책 그룹, 규칙, 연결 기록, 로그 및 시스템 프록시 제어를 그래픽 인터페이스에 통합해 데스크톱에서 mihomo 설정을 직접 관리하려는 사용자에게 적합합니다. 클라이언트는 관리와 상호작용 계층을 담당하며, 실제 네트워크 처리는 코어가 수행합니다.
이러한 계층 구조는 문제를 구분해 진단하는 데 도움이 됩니다. 인터페이스에 설정이 표시되지 않으면 구독 가져오기와 설정 파일을 확인하고, 코어가 시작되지 않으면 설정 문법, 포트 사용 여부 및 권한을 점검해야 합니다. 특정 요청의 출구가 예상과 다르면 규칙 순서, 정책 그룹 선택 및 연결 기록으로 돌아가야 합니다. 문제를 계층별로 나누면 여러 스위치를 연속해서 바꾸는 것보다 안정적인 결론에 도달하기 쉽습니다.
mihomo는 현재 Clash 생태계에서 널리 사용되는 오픈 소스 코어 중 하나로, YAML 설정 읽기, 다양한 프로토콜 연결 수립, 규칙 매칭, DNS 처리 및 그래픽 클라이언트를 위한 제어 인터페이스를 담당합니다. Clash Verge Rev는 이러한 기능을 조작 가능한 데스크톱 인터페이스로 구성하지만, 프로토콜 지원 여부, 필드 해석 방식 및 규칙 집합 로딩 방식은 최종적으로 코어의 지원 범위에 달려 있습니다.
원본 Clash, Clash Meta 및 mihomo 사이에는 설정 상속 관계가 있지만 기능 확장에는 차이가 있습니다. 일반적인 프록시 노드, 정책 그룹 및 기본 규칙은 마이그레이션하기 쉽지만, 확장 프로토콜, 규칙 집합 형식, DNS 고급 옵션 또는 특정 provider 필드가 포함된 경우에는 현재 코어 문서를 기준으로 확인해야 합니다. 기술 참고 페이지에서 프로토콜과 코어 계열에 따른 차이를 더 자세히 설명합니다.
프로젝트 코드, 이슈 논의 및 릴리스 기록이 공개되어 있으면 기능 변경, 알려진 문제 및 수정 과정을 직접 확인할 수 있고, 개발자는 특정 플랫폼의 오류를 재현하기도 쉽습니다. 오픈 소스라고 해서 모든 설정이 자동으로 호환되는 것은 아니므로 운영체제, 코어 버전, 구독 형식 및 사용 시나리오를 함께 고려해야 합니다. 안정적으로 사용 중인 기기라면 바로 덮어 설치하기보다 업그레이드 전에 릴리스 노트를 읽는 편이 안전합니다.
클라이언트와 코어가 별도로 릴리스된다는 점도 고려해야 합니다. 클라이언트 업데이트는 인터페이스, 설치 방식 또는 시스템 통합에 변화를 줄 수 있고, 코어 업데이트는 프로토콜 구현, 규칙 동작, DNS 처리 및 설정 필드에 영향을 줄 수 있습니다. 업데이트 후 차이를 진단할 때는 클라이언트 버전, 코어 버전 및 현재 설정 출처를 기록해 여러 변수를 한 번에 판단하지 않도록 하세요.
애플리케이션 설치 패키지 업데이트는 클라이언트 프로그램을 교체하고, 구독 업데이트는 노드, 정책 그룹 또는 원격 설정을 새로 고칩니다. 두 작업은 서로 다릅니다. 클라이언트를 업데이트해도 기존 설정은 대개 로컬에 남지만, 구독 업데이트는 원격 출처가 관리하는 내용을 덮어쓸 수 있습니다. 설정에 직접 작성한 규칙이 있다면 원격 파일과 로컬 파일을 명확히 구분해 업데이트 시 서로 덮어쓰는 일을 줄이세요.
규칙 집합과 프록시 목록은 각각 별도의 업데이트 주기를 사용할 수도 있습니다. 구독이 새로 고쳐졌다고 해서 모든 원격 provider가 다시 다운로드된 것은 아닙니다. 규칙이 바뀌지 않거나, 노드 목록이 예상과 다르거나, 원격 리소스 로딩에 실패했다면 메인 설정 업데이트 시간, provider 상태, 로그 메시지 및 리소스 주소를 차례로 확인하세요. 홈페이지의 연결 버튼만 확인해서는 충분하지 않습니다.
처음 다운로드하고 설정할 때 가장 헷갈리기 쉬운 부분을 정리했습니다. 전체 분류는 자주 묻는 질문 페이지에서 계속 확인할 수 있습니다.
아닙니다. Clash Verge Rev는 설정 관리와 시스템 통합을 담당하는 데스크톱 그래픽 클라이언트이고, mihomo는 프로토콜 연결, DNS 처리 및 규칙 매칭을 실행하는 코어입니다. 두 구성 요소가 협력해 완전한 데스크톱 사용 환경을 제공합니다.
구독은 보통 노드와 정책 구조를 함께 제공합니다. 규칙은 요청을 특정 정책 그룹으로 전달하지만, 정책 그룹 안에서는 구체적인 노드, 자동 선택 방식 또는 직접 연결 출구를 다시 선택해야 할 수 있습니다. 따라서 가져온 뒤 주요 정책 그룹의 현재 선택 항목을 확인해야 합니다.
일반적인 사용은 규칙 모드에서 시작하는 것이 좋습니다. 요청마다 설정에 따라 다르게 처리할 수 있기 때문입니다. 전역 모드는 트래픽을 지정한 정책으로 일괄 전달하고, 직접 연결 모드는 프록시 경로를 잠시 중지하거나 시스템 네트워크를 점검할 때 주로 사용합니다. 구체적인 차이는 사용 가이드와 기술 노트에서 확인할 수 있습니다.
Windows 데스크톱 사용자는 Clash Verge Rev, Clash Plus, FlClash 또는 Clash Nyanpasu를 검토할 수 있습니다. 이전하기 전에 기존 구독 출처와 로컬 규칙을 저장하고, 대상 클라이언트가 기존 설정 필드를 지원하는지 확인하세요.
Technical Notes
모드 선택, YAML 구조 및 실제 라우팅 사례를 중심으로 사용 가이드에서 반복해서 확인해야 하는 설정 세부 사항을 보완합니다.
세 가지 프록시 모드의 트래픽 처리 방식, 적합한 사용 상황 및 전환 원칙을 설명해 처음 사용하는 사람도 모드 변경이 모든 연결에 영향을 주는 이유를 이해할 수 있도록 합니다.
본문 전체 읽기 →설정 순서에 따라 기본 설정, 프록시 노드, 정책 그룹, 규칙 집합 및 DNS 섹션을 나누어 살펴보고 이름 참조, 처리 순서 및 자주 수정하는 범위를 설명합니다.
본문 전체 읽기 →일반적인 지역별 라우팅 요구를 바탕으로 규칙 매칭 순서와 정책 그룹 구성 방식을 설명하고, 수정 후 연결 기록으로 실제 경로를 확인하는 방법을 안내합니다.
본문 전체 읽기 →