트래픽이 코어에 어떻게 들어오는지 먼저 이해한 다음, 규칙에 따라 어디로 보낼지 정하세요. 클라이언트는 조작 창구를, 코어는 설정 실행을 담당합니다. 화면이 비슷해도 모든 설정 항목을 서로 바꿔 쓸 수 있는 것은 아닙니다.
규칙 기반 라우팅: 목적지에 따라 출구 선택
규칙 모드는 일상적인 사용에 적합합니다. 코어는 설정된 순서대로 도메인, 주소, 규칙 세트를 확인하고 일치하는 항목의 지정된 출구로 트래픽을 보냅니다. 구체적인 도메인을 앞에 두고 기본 규칙은 마지막에 배치해, 범위가 넓은 조건이 요청을 먼저 가로채지 않도록 하세요. 문제를 확인할 때는 연결 기록에서 실제로 일치한 규칙을 살펴보세요. 브라우저에서 페이지가 열리는지만 확인해서는 부족합니다. 아래 예시는 직접 연결 규칙만 보여 주며 프록시 서버는 포함하지 않습니다. 프록시 출구가 필요하면 전체 설정에 해당 노드나 프록시 그룹을 먼저 정의한 뒤 규칙에서 참조하세요.
프록시 그룹은 여러 출구를 규칙에서 참조할 수 있는 하나의 대상으로 묶습니다. 직접 선택하려면 select, 테스트 결과에 따라 선택하려면 url-test를 사용하고, 장애 전환이 필요하면 fallback을 고려하세요. 자동 테스트는 지정한 주소의 응답 성능을 측정하는 것으로 다운로드 속도와는 다릅니다. 테스트 주소와 제한 시간, 네트워크 환경에 따라 결과가 달라집니다. 아래 예시에서는 직접 연결을 구성원으로 넣고 규칙에서 참조할 '자동 선택' 그룹을 정의합니다. 실제로 사용할 때는 전체 설정에 존재하는 노드 이름으로 바꾸세요. 그룹 이름만 복사한다고 프록시 연결이 생기지는 않습니다.
proxy-groups:
- name: 자동 선택
type: url-test
proxies:
- DIRECT
url: https://www.gstatic.com/generate_204
interval: 300
rules:
- MATCH,자동 선택
TUN 전역 트래픽 처리: 시스템 프록시의 범위 보완
시스템 프록시 설정을 읽지 않는 프로그램은 시스템 프록시만으로 연결을 처리할 수 없습니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 이런 트래픽까지 처리하며, 보통 관리자 권한이나 클라이언트 서비스가 필요합니다. TUN은 트래픽이 코어로 들어오는 방식을 바꾸지만, 규칙 모드를 자동으로 전역 프록시로 바꾸지는 않습니다. 먼저 일반 연결이 되는지 확인한 다음 TUN을 켜고 라우팅, DNS, 다른 가상 네트워크 인터페이스와의 충돌을 하나씩 점검하세요. 아래는 mihomo 설정 예시입니다. 프로토콜 스택과 권한은 클라이언트 및 운영체제에 맞게 조정해야 합니다.
전체 설정 구독에는 보통 노드, 프록시 그룹, 규칙이 포함됩니다. 가져온 뒤에도 해당 설정을 선택해야 적용됩니다. proxy-providers는 노드 목록을 불러오는 기능으로, 전체 설정을 대신할 수 없습니다. 업데이트하기 전에 로컬 규칙과 오버라이드를 보존해 두세요. 직접 수정한 내용이 다음 구독 업데이트에서 덮어써질 수 있습니다. 아래는 로컬 provider 구조 예시입니다. 지정한 경로에 파일이 실제로 있어야 하며, provider 형식에 맞는 proxies 목록이 포함되어야 합니다. 전체 설정의 프록시 그룹에서도 use로 해당 provider를 참조해야 합니다. 원격 구독 주소에 접근 인증 정보가 포함될 수 있으니 공개하지 마세요.
컨트롤 인터페이스를 사용하면 연결을 확인하고 프록시 그룹을 전환하며 실행 상태를 관리할 수 있어 서버나 독립 코어 배포에 적합합니다. 데스크톱 클라이언트에는 관리 화면이 기본으로 통합된 경우가 많아 일상적인 사용을 위해 인터페이스를 별도로 열 필요는 없습니다. 수신 주소는 우선 로컬 루프백으로 제한하세요. 원격 접속이 꼭 필요하다면 인증과 통제된 네트워크 경로를 함께 설정해야 합니다. 아래 예시는 로컬 수신 주소만 보여 줍니다. 포트는 혼합 포트와 중복되면 안 됩니다. 컨트롤 인터페이스를 설정해도 웹 패널이 배포되는 것은 아닙니다. 패널 파일과 접속 방식, 인증은 별도로 설정해야 합니다.
external-controller: 127.0.0.1:9090
log-level: info
시스템 프록시, 프록시 모드, 포트는 각각 따로 살펴보기
시스템 프록시는 앱이 요청을 클라이언트로 보낼지 결정합니다. 규칙, 전역, 직접 연결은 코어가 요청을 받은 뒤 어떻게 처리할지 결정합니다. 혼합 포트는 이 기기에서 HTTP와 SOCKS 연결을 받는 수신 창구입니다. 세 설정은 서로 다른 문제를 해결합니다. 브라우저가 시스템 프록시를 사용하지 않으면 프록시 그룹을 바꿔도 달라지는 것이 없을 수 있습니다. 규칙이 직접 연결을 지정했다면 노드를 바꿔도 해당 요청의 출구는 바뀌지 않습니다. 여러 설정을 한꺼번에 바꾸기보다 트래픽 진입점부터 출구까지 차례로 확인하세요.
화면의 설정 창은 정적인 예시입니다. 7897은 흔히 쓰이는 혼합 포트의 예일 뿐, 모든 클라이언트의 고정값은 아닙니다. 실제 포트는 현재 클라이언트 설정을 기준으로 확인하세요. 브라우저나 다른 앱의 프록시를 직접 설정한다면 주소는 보통 로컬 루프백이며, 포트는 클라이언트 설정과 일치해야 합니다. 포트를 변경한 뒤에는 시스템 프록시와 앱에 별도로 저장된 프록시 설정도 함께 확인하세요. LAN 공유에는 수신 주소와 방화벽 설정이 추가로 필요합니다. 일반적인 로컬 사용이라면 공유를 먼저 켤 필요가 없습니다.
운영체제와 프로세서에 맞는 클라이언트를 고른 다음 필요한 기능을 확인하세요. Clash Plus를 여러 플랫폼에서 사용할 수 있는 우선 추천 클라이언트로 소개합니다. 데스크톱에서는 Clash Verge Rev, FlClash 등과 비교해 볼 수 있습니다. 다운로드 페이지에서 설치 파일과 시스템 요구 사항을 확인하세요.
브라우저와 일반 데스크톱 앱은 먼저 시스템 프록시를 사용해 보세요. 프록시 설정을 따르지 않는 프로그램까지 처리해야 한다면 클라이언트 서비스와 TUN 권한을 확인하세요. Clash Plus를 먼저 살펴보거나 Clash Verge Rev, FlClash, Clash Nyanpasu의 설정 관리 방식을 비교해 보세요.
설치 전에 시스템 설정에서 아키텍처를 확인하고, 데스크톱 설치 파일과 독립 코어 압축 파일을 혼동하지 마세요. 구형 Clash for Windows 다운로드는 지원이 중단된 보관용 항목입니다. 이전할 때는 구독, 규칙, 스크립트를 먼저 백업한 뒤 새 클라이언트가 기존 설정 항목을 지원하는지 확인하세요.
먼저 '이 Mac에 관하여'에서 Apple Silicon인지 Intel인지 확인한 다음 알맞은 설치 파일을 선택하세요. Clash Plus, Clash Verge Rev, FlClash를 비교해 볼 수 있습니다. 브라우저 연결을 먼저 확인하려면 시스템 프록시를 사용하고, TUN을 쓸 때는 권한과 라우팅 설정을 추가로 점검하세요.
실행 전에 시스템에서 표시하는 앱 출처 안내를 읽고 프로젝트의 배포 안내에 따라 진행하세요. 앱 하나를 열기 위해 시스템 보호를 계속 꺼 두지 마세요. 기존에 ClashX Meta를 사용했다면 다운로드 페이지에서 보관 상태를 확인할 수 있습니다. 이전할 때는 구독 형식, 프록시 그룹 선택, 로컬 오버라이드를 중점적으로 확인하고 이전 화면의 설정을 전부 그대로 복사하지 마세요.
모바일 기기는 대개 시스템 VPN 인터페이스로 트래픽을 처리하며, 처음 연결할 때 권한을 승인해야 합니다. 먼저 Clash Plus를 살펴보고 Clash Meta for Android, FlClash와 비교해 보세요. 설치 파일 아키텍처는 기기에 맞아야 하며, 백그라운드 실행은 시스템의 배터리 관리 정책에 영향을 받을 수 있습니다.
휴대전화에 다른 VPN 앱이 설치되어 있다면 먼저 현재 어떤 앱이 연결을 설정했는지 확인하세요. 연결 충돌을 노드 문제로 오해할 수 있습니다. Surfboard도 다운로드 페이지에서 선택할 수 있지만 설정 형식은 Clash YAML과 다릅니다. 구독을 바로 가져올 수 있는지는 제공 형식으로 확인해야 하며, 링크 끝부분만 보고 호환 여부를 판단할 수 없습니다.
우선 추천 클라이언트는 Clash Plus입니다. 다운로드 페이지에서 App Store 링크와 공식 사이트 clashplus.io를 확인할 수 있습니다. 설치한 뒤 기존 구독을 가져오고 앱 안내에 따라 VPN 설정 권한을 승인하세요. 시스템의 VPN 상태는 트래픽 처리 연결이 설정되었다는 뜻일 뿐, 구독에 포함된 모든 출구로 연결할 수 있다는 의미는 아닙니다.
모바일의 권한 모델은 데스크톱과 다르므로 데스크톱의 혼합 포트나 시스템 프록시 설정을 그대로 따라 할 필요는 없습니다. 확인할 때는 분명한 대상 페이지를 하나 열고 앱의 연결 기록과 프록시 선택을 확인하세요. 구독 업데이트 실패와 연결 실패는 따로 다뤄야 합니다. 전자는 링크와 서비스 상태를 먼저 확인하고, 후자는 규칙과 출구를 살펴보세요.
데스크톱 사용자는 Clash Verge Rev와 FlClash 중에서 배포판과 패키지 형식에 맞는 클라이언트를 선택할 수 있습니다. 데스크톱 환경마다 시스템 프록시 지원이 다르며, 터미널 프로그램은 데스크톱 프록시 설정을 사용하지 않을 수도 있습니다. 환경 변수, 앱별 프록시, TUN이 각각 어떤 트래픽을 처리하는지 확인하세요.
서버나 라우터에서는 독립 mihomo 코어를 고려해 볼 수 있습니다. 코어를 직접 배포하면 설정 경로, 서비스 실행, 권한, 로그를 직접 관리해야 하며 데스크톱 화면이 이를 대신 처리해 주지 않습니다. 먼저 포그라운드에서 설정을 불러올 수 있는지 확인한 뒤 서비스 관리자를 연결하세요. 문제가 생기면 반복해서 재설치하기보다 시작 로그를 보존하는 편이 도움이 됩니다.
설치했다고 바로 연결할 수 있는 것은 아닙니다. 먼저 설정을 가져오고, 트래픽 처리 방식을 확인한 다음 연결 기록으로 결과를 검증하세요. 처음 설정할 때는 기본값을 유지하고 한 번에 한 항목씩만 변경하는 것이 좋습니다.
01 / 설정 가져오기
구독을 가져와 현재 설정으로 선택
클라이언트의 구독 또는 설정 페이지를 열고 기존 구독 링크를 붙여 넣은 뒤 저장하고 다운로드가 끝날 때까지 기다리세요. 설정 항목이 나타나면 현재 설정으로 지정하고 프록시 그룹이 제대로 불러와졌는지 확인합니다. 링크는 신뢰할 수 있는 제공업체에서 받아야 합니다. 클라이언트가 사용 가능한 프록시 서비스를 자동으로 만들어 주지는 않습니다.
로컬 YAML 파일을 받았다면 파일 가져오기 메뉴를 사용하세요. 다운로드에 실패하면 링크가 온전한지, 만료되지 않았는지, 응답 내용이 실제 설정인지 먼저 확인하세요. 로그인 페이지나 오류 페이지를 설정 파일로 가져오면 안 됩니다. 가져오기 전에 원본 파일을 보관해 두면 복구하기 쉽습니다.
02 / 트래픽 진입점
규칙 모드를 선택하고 트래픽 처리 켜기
먼저 규칙 모드를 선택하고 수동 선택이 필요한 프록시 그룹에서 사용할 수 있는 출구를 지정하세요. 데스크톱에서는 시스템 프록시를 켜고, 모바일에서는 안내에 따라 VPN 권한을 승인합니다. 특별한 이유가 없다면 LAN 공유는 꺼 둬 불필요한 수신과 접근 범위를 늘리지 마세요.
프로그램이 연결 목록에 나타나지 않으면 시스템 프록시를 따르지 않는 프로그램인지 확인하세요. 필요한 경우에만 TUN을 켜고 관리자 권한, 클라이언트 서비스, DNS 설정을 점검합니다. 전역 모드는 일시적인 비교와 문제 확인에 적합하며 모든 문제의 기본 해결책으로 사용해서는 안 됩니다.
03 / 연결 확인
연결을 확인하고 단계별로 점검
대상 페이지를 열면서 클라이언트 연결 기록을 확인해 요청이 코어에 들어왔는지, 예상한 규칙과 일치했는지, 올바른 출구를 사용했는지 살펴보세요. 지연 시간 테스트는 특정 테스트 주소의 응답을 참고하는 용도입니다. 실제 페이지, 다운로드, 화상 회의 앱의 연결 상태를 대신 검증하지는 못합니다.
실패하면 발생 시각, 대상, 로그 정보를 기록하고 구독 불러오기, 프록시 진입점, DNS, 규칙, 출구 순서로 확인하세요. 클라이언트를 종료하기 전에 시스템 프록시를 끄세요. 그렇지 않으면 앱이 이미 수신을 중단한 로컬 포트에 연결을 시도해 클라이언트를 종료한 뒤에도 네트워크가 작동하지 않을 수 있습니다.
클라이언트의 장기 사용 적합성은 공개 코드, 유지 관리 기록, 설정 동작을 설명할 수 있는지 확인해 판단할 수 있습니다. 프로젝트의 역사, 코어 구현, 그래픽 클라이언트, 구독 서비스를 구분해 하나의 제품처럼 혼동하지 않도록 안내합니다.
프로젝트 역사: 이전 이름과 새 유지 관리 분기
Clash 생태계는 규칙 기반 프록시를 중심으로 발전하면서 여러 코어 분기와 그래픽 클라이언트를 만들었습니다. 기존 Clash 프로젝트와 일부 초기 클라이언트의 유지 관리가 중단된 뒤에도 계속 관리되는 분기에서는 프로토콜 지원, DNS, 라우팅 기능이 발전해 왔습니다. mihomo는 Clash.Meta의 기술 흐름을 이어받았기 때문에 자료에 Clash, Clash Meta, mihomo라는 이름이 함께 등장할 수 있습니다. 가이드를 읽을 때는 먼저 어떤 코어를 설명하는지 확인하고 설정 항목이 현재 클라이언트에도 적용되는지 살펴보세요.
이전 가이드의 화면 캡처는 메뉴 위치를 파악하는 데 참고할 수 있지만 현재 기능 지원 여부를 보여 주는 근거는 아닙니다. 클라이언트 메뉴, 서비스 설치 방식, 기본 포트는 달라졌을 수 있습니다. 특히 유지 관리가 중단된 소프트웨어에서 이전할 때는 구독 원본, 로컬 규칙, 스크립트, 설정을 각각 백업하세요. 새 클라이언트에서 최소한의 연결부터 확인한 뒤 고급 기능을 하나씩 복원해야 이전 설정을 한꺼번에 가져와 차이를 찾기 어려워지는 일을 피할 수 있습니다.
코어와 클라이언트: 실행 기능과 조작 화면
mihomo 코어는 설정을 해석하고 규칙을 적용하며 DNS를 처리하고 연결을 만듭니다. 그래픽 클라이언트는 설치, 구독 관리, 시스템 프록시, 조작 화면을 담당합니다. 클라이언트에 특정 스위치가 있는지와 코어가 특정 설정 항목을 지원하는지는 별개의 문제입니다. 데스크톱 소프트웨어는 높은 권한이 필요한 기능을 서비스 프로세스로 처리할 수 있고, 모바일은 시스템 네트워크 확장이나 VPN 인터페이스의 제약을 받습니다.
따라서 같은 YAML 파일도 클라이언트에 따라 수정이 필요할 수 있습니다. 코어 차이뿐 아니라 클라이언트가 DNS, 포트, TUN 설정을 덮어쓰는지, provider 경로를 어떻게 해석하는지도 확인하세요. 원래 구독 파일만 살펴보지 말고 최종 적용된 설정을 확인해야 합니다. 문제를 제보할 때는 'Clash가 안 돼요'라고만 하기보다 클라이언트 이름, 운영체제, 트래픽 처리 방식, 관련 설정 항목을 함께 적어야 재현에 도움이 됩니다.
오픈소스 커뮤니티: 코드와 문서로 동작 확인
mihomo는 GPL-3.0 라이선스로 배포되며 코드, 이슈, 릴리스 기록은 프로젝트 저장소에서 확인할 수 있습니다. 오픈소스 라이선스는 코드 사용과 배포 조건을 설명할 뿐, 모든 서드파티 클라이언트에 같은 라이선스가 적용된다는 뜻은 아니며 유지 관리 상태를 대신 판단해 주지도 않습니다. 설정 항목을 확인할 때는 현재 코어 문서를 우선 참고하세요. 버그가 의심되면 공개 이슈에 같은 상황이 보고되어 있는지 검색해 보세요.
이 사이트는 확인할 수 없는 다운로드 수, 평점, 연결 성능을 표시하지 않습니다. 추천은 플랫폼, 설정 방식, 사용 목적을 기준으로 하며 근거 없는 통계로 뒷받침하지 않습니다. 저장소의 문제 제보도 소프트웨어 품질 순위로 볼 수 없습니다. 기기와 설정, 네트워크 환경은 사용자마다 다릅니다. 재현 절차, 로그 시간대, 최소 설정이 문제의 원인이 코어인지 화면인지 서비스 제공업체인지 판단하는 데 도움이 됩니다.
소프트웨어 업데이트는 클라이언트나 코어를 변경하고, 구독 업데이트는 노드와 설정 내용을 변경하며, 규칙 세트 업데이트는 매칭 조건을 변경합니다. 서로 다른 작업이며 업데이트 주기도 같지 않을 수 있습니다. 업그레이드 전에 정상 작동하는 설정과 로컬 오버라이드를 저장하고 변경 사항을 읽은 뒤 DNS, TUN, provider가 계속 예상대로 동작하는지 확인하세요. 구독을 새로고침한 뒤 프록시 그룹 항목이 바뀌었다고 해서 반드시 클라이언트 업데이트 때문인 것은 아닙니다.
구독 주소에 계정 접근 정보가 포함될 수 있으니 화면 캡처나 로그를 공유하기 전에 전체 링크와 민감한 항목을 제거하세요. 다른 사람에게 점검을 요청할 때는 문제와 관련된 설정 부분만 제공하세요. 전체 구독을 공개 이슈에 올리거나 낯선 사람의 설정으로 기존 설정을 덮어쓰지 마세요. 규칙에서 참조하는 프록시 그룹, provider 파일, 스크립트는 함께 있어야 합니다. 문법 일부만 복사해서는 작동하는 설정을 만들 수 없습니다.
mihomo 소스 코드 받기
아래 명령은 코어를 살펴보거나 개발할 때 사용하는 것으로, 그래픽 클라이언트 설치 절차가 아닙니다. 일반 사용자는 다운로드 페이지로 이동하세요. 직접 빌드하려면 저장소 문서에 따라 도구 체인과 대상 아키텍처를 준비하면 됩니다.
git clone https://github.com/MetaCubeX/mihomo.git
자주 묻는 개념: 용어를 확인한 뒤 설정 변경
규칙 모드에서는 일부 웹사이트만 프록시를 사용하나요? 모드 이름 자체가 아니라 현재 규칙에 따라 달라집니다. TUN을 켜면 모든 요청이 프록시를 거치나요? TUN은 트래픽을 처리하지만 출구는 규칙과 프록시 그룹에 따라 결정됩니다. 노드 테스트에 응답이 있으면 실제 앱에서도 사용할 수 있나요? 테스트 대상과 실제 대상은 다르므로 대상에 직접 연결해 확인해야 합니다. 구독과 설정 파일은 같은 것인가요? 구독은 내용을 가져오는 방식이며, 응답은 전체 설정일 수도 노드 목록일 수도 있습니다. 이런 개념을 더 확인하려면 개념 빠른 참조를 살펴본 뒤 설정 화면으로 돌아가 작업하세요.
Clash 설정 및 문제 해결 글
이전, 포트, 트래픽 처리라는 세 가지 구체적인 상황을 더 살펴보세요. 먼저 문제가 발생한 계층을 파악한 뒤 해당하는 작업을 수행해 소프트웨어 교체, 규칙 수정, 시스템 네트워크 초기화를 한꺼번에 진행하지 않도록 하세요.