Windows
데스크톱에서 일상적으로 사용하기에 적합합니다. 설치 전에 운영체제 버전과 프로세서 아키텍처를 확인하세요. 다른 프록시 도구를 사용 중이라면 먼저 종료한 뒤 클라이언트의 시스템 프록시를 켜는 것이 좋습니다. 포트가 이미 사용 중이라면 반복해서 재설치하지 말고 어떤 프로세스가 포트를 점유했는지 확인하세요.
다운로드 페이지로 이동 →데스크톱에서 일상적으로 사용하기에 적합합니다. 설치 전에 운영체제 버전과 프로세서 아키텍처를 확인하세요. 다른 프록시 도구를 사용 중이라면 먼저 종료한 뒤 클라이언트의 시스템 프록시를 켜는 것이 좋습니다. 포트가 이미 사용 중이라면 반복해서 재설치하지 말고 어떤 프로세스가 포트를 점유했는지 확인하세요.
다운로드 페이지로 이동 →Apple Silicon 또는 Intel에 맞는 설치 파일을 선택하세요. 처음 실행한 뒤에는 시스템에서 요구하는 권한을 허용하고, 구성을 가져와 시스템 프록시가 작동하는지 먼저 테스트하세요. 더 많은 앱의 트래픽을 처리하려면 서비스 구성 요소와 TUN 모드에 필요한 권한도 확인하세요.
다운로드 페이지로 이동 →휴대폰과 태블릿에서는 모바일 클라이언트를 사용해야 합니다. Clash Verge Rev는 데스크톱용입니다. 다운로드 센터에서 이용 가능한 앱을 확인하고 호환되는 구독을 가져온 다음 VPN 권한을 허용하세요. 백그라운드 연결을 유지하려면 시스템의 배터리 관리 설정도 살펴보세요.
다운로드 페이지로 이동 →iPhone 또는 iPad에서 Clash Plus 앱 스토어 페이지를 확인하세요. 모바일 인터페이스는 데스크톱과 다르므로 구독을 가져오기 전에 지원되는 형식인지 확인해야 합니다. 연결할 때 시스템 안내에 따라 VPN 구성을 추가한 뒤 규칙과 정책 그룹을 선택하세요.
다운로드 페이지로 이동 →배포판의 패키지 형식에 맞는 데스크톱 설치 파일을 선택하고, 설치 전에 필요한 종속성을 확인하세요. 그래픽 데스크톱에서는 클라이언트로 구성을 관리할 수 있습니다. 서버나 라우터 환경에서는 다운로드 센터의 Mihomo 커널 섹션을 참고해 서비스와 권한을 별도로 설정하세요.
다운로드 페이지로 이동 →클라이언트, 구독, 프록시 서비스는 서로 다른 요소입니다. 클라이언트를 설치하면 실행 환경이 준비되고, 구독은 노드와 정책 그룹, 규칙 등의 설정을 제공합니다. 실제 연결 여부는 서비스가 사용 가능한지에 달려 있습니다. 설치 파일을 고를 때는 먼저 운영체제, 다음으로 아키텍처를 확인하세요. 구독은 형식과 필요한 커널 기능을 기준으로 선택해야 합니다.
기존 클라이언트에서 옮겨오는 경우 먼저 설정을 내보내고 포트, 프록시 모드, 로컬 변경 사항을 기록해 두세요. 새 클라이언트를 처음 실행할 때는 구성 하나만 활성화하고 정상 연결을 확인한 뒤 오버라이드와 사용자 규칙을 옮기는 것이 좋습니다. 문제가 생겨도 설치 환경, 구독 내용, 로컬 설정 중 어디에서 발생했는지 구분하기 쉽습니다.
설정 항목별로 인터페이스 일부를 살펴봅니다. 예시의 스위치는 설명용이며 실제 설정은 클라이언트에서 변경해야 합니다.
인터페이스 / 구성 / 구독 관리
구성 페이지에 구독 링크를 붙여 넣고 가져오세요. 다운로드가 완료되면 해당 구성을 선택한 다음 프록시 페이지에서 정책 그룹을 확인합니다. 커널 파일을 직접 편집하는 것보다 그래픽 인터페이스에서 구독 출처와 현재 활성화 상태를 한눈에 확인할 수 있어 여러 구성을 관리하기 편리합니다. 가져오기에 성공했다고 연결까지 정상이라는 뜻은 아니므로 구독 형식, 노드 정보, 정책 그룹 선택도 확인해야 합니다. 원격 구독을 업데이트하면 원본 내용이 바뀔 수 있으니 계속 사용할 규칙은 로컬 오버라이드로 관리하세요. 화면을 공유할 때는 구독 주소에 포함된 개인 식별 정보를 가려야 합니다.
구독 가져오기 단계 보기 →인터페이스 / 설정 / 시스템 프록시
시스템 프록시는 해당 설정을 지원하는 앱이 클라이언트의 수신 주소를 사용하도록 연결합니다. 혼합 포트는 HTTP와 SOCKS 프록시 연결을 모두 받으며, 예시 포트는 7897입니다. 실제 포트는 설정 페이지에서 확인하세요. 처음에는 시스템 프록시를 켠 뒤 브라우저로 대상 사이트에 접속해 테스트합니다. 터미널이나 프록시를 별도로 설정한 앱은 추가 설정이 필요할 수 있습니다. TUN 모드와 비교하면 트래픽을 처리하는 범위가 명확해 처음 문제를 확인하기에도 편리합니다. 포트를 변경했다면 앱 내부의 프록시 주소도 함께 확인하고, 클라이언트를 종료하기 전에 시스템 프록시가 원래대로 복구됐는지 확인하세요.
시스템 프록시 설정 보기 →인터페이스 / 규칙 / 매칭 순서
규칙 모드는 구성에 지정된 순서대로 연결을 확인하며, 일반적으로 먼저 일치하는 규칙에 따라 처리 방식이 결정됩니다. 규칙이 가리키는 정책 그룹에서 실제 노드를 선택하므로 두 단계는 구분해야 합니다. 모든 트래픽을 같은 경로로 보내는 대신 규칙 분기를 사용하면 도메인별로 직접 연결 또는 프록시 사용을 지정할 수 있습니다. 규칙을 추가할 때는 대상 도메인을 확인하고, 정책 그룹이 실제로 존재하는지 확인한 뒤 구체적인 규칙을 기본 규칙보다 앞에 배치하세요. 접속 결과가 예상과 다르면 연결 페이지에서 일치한 규칙과 정책 경로를 확인하세요. 웹페이지가 열리는지만으로 설정 적용 여부를 판단하지 마세요.
규칙 및 정책 그룹 설정 보기 →인터페이스 / 설정 / TUN 모드
TUN 모드는 가상 네트워크 인터페이스를 통해 트래픽을 처리하므로 시스템 프록시를 따르지 않는 앱에 적합합니다. 시스템 프록시와의 차이는 트래픽을 연결하는 방식에 있으며, 구독을 대체하거나 노드를 자동으로 제공하는 기능은 아닙니다. 활성화하기 전에 일반 프록시 연결이 정상인지 확인하고, 클라이언트 안내에 따라 서비스 구성 요소와 권한을 준비하세요. 기기에서 다른 VPN이나 가상 네트워크 인터페이스, 기업용 네트워크 도구를 함께 사용하는 경우 라우팅 충돌에 유의해야 합니다. 네트워크가 끊기면 먼저 TUN을 끄고 비교한 다음 DNS, 자동 라우팅, 인터페이스 선택을 확인하세요. 한 번에 하나씩 변경하고 정상 연결을 복구할 수 있도록 기존 설정을 기록해 두세요.
TUN 및 Fake-IP 설명 보기 →구성 / dns / enhanced-mode
DNS는 도메인 이름을 해석하는 방식을 결정하며 대상 IP에 의존하는 규칙의 판단에도 영향을 줍니다. Mihomo의 DNS 설정은 실제 트래픽 처리 방식과 시스템 DNS 설정을 함께 고려해야 합니다. 상위 DNS 서버 주소만 바꿨다고 문제가 해결되는 것은 아닙니다. Fake-IP는 도메인에 가상 주소를 할당하며, 실제 주소를 반환하는 일반적인 DNS 해석과 동작 방식이 다릅니다. 설정을 바꾸기 전에 확장 모드, 상위 서버, 필터 항목을 기록하고 같은 도메인으로 결과를 비교하세요. 일부 앱에서만 문제가 발생한다면 앱 자체의 암호화 DNS와 캐시부터 확인하세요. 복잡한 매개변수의 용도와 관계는 고급 설정에서 항목별로 살펴볼 수 있습니다.
DNS 설정 최적화 보기 →인터페이스 / 연결 및 로그 / 문제 확인
연결 페이지에서는 트래픽이 커널에 전달됐는지, 어떤 규칙과 일치했는지 확인할 수 있습니다. 로그 페이지에서는 구성 로드, 파싱 실패, 연결 오류를 살펴볼 수 있습니다. 노드를 반복해서 바꾸기보다 이 두 곳의 정보를 확인하면 원인 범위를 좁히기 쉽습니다. 문제가 발생한 시간과 대상 도메인을 기록한 뒤 한 번 재현하고 해당 기록을 찾으세요. 필요하면 로그 수준을 잠시 높이고, 기록을 수집한 뒤에는 평소 설정으로 되돌려 로그가 지나치게 많아지지 않도록 합니다. 문제를 외부에 보고하기 전에는 구독 주소, 인증 정보, 개인 접속 기록을 삭제하고 재현 단계와 시도한 조치를 함께 적으세요.
자주 발생하는 로그 오류 보기 →먼저 재현 가능한 연결 경로를 하나 완성하세요. 기본 설정이 정상인지 확인한 뒤 오버라이드, 규칙 세트, TUN 설정을 추가하세요.
클라이언트를 설치하고 실행한 다음 구성 페이지에서 서비스 제공자가 안내한 구독 링크를 붙여 넣으세요. 가져오기가 완료되면 해당 구성을 선택합니다. 링크가 가리키는 내용은 클라이언트와 호환되어야 하며 웹페이지 공유 주소가 구독 주소와 다를 수 있습니다. 로컬 파일을 사용하는 경우 노드 목록만 담긴 파일이 아니라 완전한 Clash YAML 구성인지 먼저 확인하세요.
첫 테스트에서는 명확하게 활성화된 구성 하나만 사용하세요. 파싱에 실패하면 오류에 표시된 필드나 줄 번호부터 확인하고 들여쓰기와 형식을 점검하세요. 포트, DNS, 규칙을 동시에 바꾸지 마세요.
프록시 페이지에서 구독의 정책 그룹이 표시되는지 확인한 다음 직접 선택해야 하는 그룹에 노드를 지정하세요. 처음에는 규칙 모드를 유지하고 설정 페이지에서 시스템 프록시를 켭니다. 정책 그룹의 이름과 구성은 구독마다 다를 수 있으므로 이름만 보고 실제 연결 경로를 판단할 수는 없습니다.
먼저 시스템 프록시를 따르는 브라우저로 테스트하세요. 앱 자체에 프록시 설정이 있다면 이전 클라이언트의 포트를 가리키고 있지 않은지 확인합니다. 문제를 단계별로 파악하기 쉽도록 추가 네트워크 처리 기능은 일단 켜지 않는 것이 좋습니다.
대상 사이트에 접속한 뒤 연결 페이지를 열어 도메인, 일치한 규칙, 정책 경로를 확인하세요. 사이트가 열렸다는 사실은 이번 접속이 완료됐다는 뜻일 뿐, 요청이 예상한 경로로 전달됐음을 단독으로 입증하지는 않습니다. 해당 연결이 보이지 않으면 앱이 시스템 프록시를 따르는지, 클라이언트가 방금 가져온 구성을 사용 중인지 확인하세요.
연결 기록은 있는데 접속에 실패했다면 로그에서 DNS 해석 또는 연결 오류를 확인하세요. 테스트 대상은 같은 도메인으로 유지하고 설정을 한 번에 하나씩 바꿔야 문제가 규칙, 노드, 로컬 환경 중 어디에서 발생하는지 판단할 수 있습니다.
Clash Verge Rev는 Clash Verge의 데스크톱 클라이언트 방향을 이어받아 그래픽 인터페이스에서 구독, 프록시 정책, 연결, 설정을 관리합니다. 프로젝트를 이해할 때는 클라이언트 인터페이스와 프록시 커널을 구분해야 합니다. 구성 페이지는 구성 출처를 관리하고 설정 페이지는 데스크톱 환경과 연동하며, 네트워크 요청의 규칙 매칭과 프로토콜 처리는 주로 커널이 담당합니다. 예전 가이드와 현재 인터페이스에서 버튼 위치가 다를 수 있으므로 화면 캡처의 좌표를 따라가기보다 작업 항목을 기준으로 기능을 찾으세요.
Mihomo는 Clash 구성 생태계에 속하며 프록시 프로토콜, 정책 그룹, 규칙, DNS 등의 기능을 제공합니다. 클라이언트는 이러한 기능을 데스크톱 작업 흐름에 연결하지만, 구성의 모든 필드가 별도의 스위치로 제공되는 것은 아닙니다. 일부 설정은 구독 원본에서 오고, 일부는 클라이언트가 실행 구성에 생성하며, 나머지는 로컬 오버라이드의 영향을 받을 수 있습니다. 구성과 인터페이스의 표시가 다르면 현재 활성화된 구성을 먼저 확인하고 병합된 결과를 점검하세요. Clash Meta 가이드를 볼 때도 커널의 발전 과정과 필드 지원 여부를 확인해야 합니다. 서로 다른 클라이언트의 화면 조작 절차를 그대로 적용할 수는 없습니다.
프로젝트는 GPL-3.0 라이선스로 소스 코드를 공개합니다. 기능 구현 방식을 확인하려면 저장소의 문서, 소스 코드, 이슈 기록부터 살펴보세요. 수정하거나 재배포할 때는 라이선스의 구체적인 의무를 읽어야 합니다. 오픈 소스는 코드를 살펴보고 논의하며 개선에 참여할 수 있는 기반을 제공하지만, 모든 네트워크 환경에서 동일하게 작동한다는 뜻은 아닙니다. 실제 사용 시에는 운영체제, 서비스 구성 요소, 구성 출처, 네트워크 환경을 확인해야 합니다. 프로젝트에 문제를 보고할 때는 단순히 “연결 실패”라고 설명하는 것보다 재현 단계와 민감 정보를 삭제한 로그를 제공하는 편이 도움이 됩니다.
클라이언트 업데이트, 커널 업데이트, 원격 구독 업데이트는 서로 다른 계층에서 이루어집니다. 클라이언트 업데이트는 인터페이스나 시스템 연동을 바꿀 수 있고, 커널 업데이트는 프로토콜과 구성 필드에 영향을 줄 수 있으며, 구독 업데이트는 노드, 규칙, 정책 그룹을 바꿉니다. 업데이트 전에 현재 정상 작동하는 구성을 보관하고 릴리스 노트를 읽은 뒤 로컬 오버라이드, 포트, 서비스 설정을 기록하세요. 업데이트 후에는 기존 사용 경로부터 확인하고 규칙 매칭과 앱 연결이 정상인지 검증한 다음 새 기능을 시도하세요. 특정 구독에서만 문제가 생기면 모든 구성 요소를 바로 롤백하지 말고 해당 구성 내용부터 확인하세요.
프로젝트 소스 코드 및 릴리스 노트 보기 →소스 저장소 / git clone
git clone https://github.com/clash-verge-rev/clash-verge-rev.git
일상적인 사용이라면 다운로드 센터에서 설치 파일을 선택하면 됩니다. 저장소 복제는 구현을 읽거나 수정 사항을 제출하거나 직접 빌드할 때 사용하는 방법이며, 복제만으로 설치가 완료되지는 않습니다. 소스 빌드에는 프로젝트 문서에 따른 도구 체인, 종속성, 시스템 환경이 필요합니다. 현재 저장소의 문서를 기준으로 빌드 절차를 확인하세요.
구독에는 노드, 정책 그룹, 규칙 등이 포함되며 업데이트 시 원본 내용이 덮어써질 수 있습니다. 사용자 지정 트래픽 분기를 계속 유지해야 한다면 클라이언트의 오버라이드 방식을 먼저 확인하세요. 업데이트할 때마다 수동으로 다시 수정하는 일을 피할 수 있습니다. 규칙에서 참조하는 정책 그룹은 실제로 존재해야 하며, 여러 구성을 합칠 때는 같은 이름의 그룹, 중복 노드, 규칙 순서도 고려해야 합니다. 구성을 수정한 뒤에는 정상적으로 불러왔는지 확인하고 연결 페이지에서 실제 규칙 매칭 결과를 검증하세요.
문제를 확인할 때 운영체제, 네트워크 연결 방식, 활성화된 프록시 모드, 오류 발생 시간을 기록해 두면 좋습니다. 구성 파일과 로그에는 구독 링크, 서버 주소, 인증 정보, 접속 도메인이 포함될 수 있으므로 공개하기 전에 항목별로 민감 정보를 삭제하세요. 문제를 설명할 최소 구성에는 꼭 필요한 필드만 남기세요. 개인 구독 전체를 공개 게시판에 올리지 말고, 일시적으로 사용한 디버깅 설정을 일상 구성에 계속 남겨 두지 마세요.
고급 설정 가이드 보기 →문제에 맞는 가이드를 선택하세요. 구독 형식이 헷갈리면 구독 안내를, 구성을 불러오지 못하면 YAML 안내를, 실행에 문제가 있으면 포트 안내를 먼저 확인하세요.
일반 포트, dns, proxies, proxy-groups, rule-providers, rules 각 항목의 의미를 순서대로 살펴보고 자주 발생하는 들여쓰기 오류 예시도 소개합니다.
구독 가져오기를 마치고 원본 구성을 읽으려는 사용자에게 적합합니다. 먼저 최상위 필드와 목록의 계층을 파악한 다음 수신 포트, DNS 해석 방식, 규칙 참조 중 무엇을 바꿔야 하는지 확인하세요. 관련 설정을 빠뜨린 채 일부 내용만 복사하지 않도록 주의해야 합니다.
글 읽기 →Windows, macOS, Linux에서 명령어로 포트를 점유한 프로세스를 찾는 방법을 안내합니다. 클라이언트 설정에서 혼합 포트를 변경하고 시스템 프록시 주소를 함께 맞추는 방법도 다룹니다.
수신에 실패하거나 클라이언트를 바꾼 뒤 연결되지 않을 때 참고하세요. 먼저 포트를 점유한 프로세스를 확인하고 종료할지 판단한 다음 포트를 변경합니다. 마지막으로 브라우저, 터미널, 다른 앱이 기존 프록시 주소를 계속 사용하고 있지 않은지 확인하세요.
글 읽기 →URL 붙여넣기, 로컬 파일 가져오기, QR 코드 스캔 등 세 가지 방법을 설명하고 Clash YAML 구성과 Base64 노드 목록 형식의 차이, 업데이트 간격 설정을 비교합니다.
클라이언트마다 구독을 가져오는 메뉴와 방법이 다를 수 있습니다. 현재 앱에서 지원하는 방법을 먼저 확인한 뒤 구독 주소가 실제로 어떤 내용을 반환하는지 살펴보세요. 링크를 열었을 때 웹페이지나 오류 메시지가 나타난다면 파일 확장자를 반복해서 바꾸기보다 구독 출처부터 바로잡아야 합니다.
글 읽기 →