Windows
데스크톱 업무, 브라우저 프록시와 TUN 가로채기가 필요한 프로그램에 적합합니다. 다운로드 페이지에서 그래픽 클라이언트를 한눈에 확인하고 현재 유지 관리되는 프로젝트와 보관된 프로젝트를 구분할 수 있습니다. 설치 후 먼저 구독을 가져오고 필요할 때만 시스템 프록시를 켜세요. 시스템 프록시를 읽지 않는 앱에서만 추가로 TUN 설정이 필요합니다.
다운로드 페이지로 이동코어 세대교체 비교표
시스템 트래픽 가로채기부터 DNS 해석 경로까지, 자주 쓰는 설정은 단순한 전달을 넘어섭니다. 왼쪽 기능을 선택하면 해결하는 문제와 설정 위치, 사용 범위를 확인할 수 있습니다.
TUN 모드는 시스템 프록시 설정을 읽지 않는 앱의 트래픽을 가로채는 기능입니다. 일부 게임 런처, 명령줄 도구와 독립 네트워크 프로그램이 여기에 해당합니다. 활성화하면 코어가 가상 네트워크 인터페이스를 통해 트래픽을 한곳에서 받은 뒤 규칙 시스템으로 직접 연결, 프록시 또는 거부 여부를 판단합니다. 시스템 프록시만 켜는 방식보다 적용 범위가 넓지만 관리자 권한, 라우팅 설정과 DNS 연동에 더 크게 의존합니다. 처음에는 mixed 스택을 사용하고 로컬 네트워크가 계속 직접 연결되는지 확인하세요. LAN 기기에 접근할 수 없다면 노드를 계속 바꾸기보다 라우팅 제외 항목을 먼저 점검하는 편이 좋습니다.
tun:
enable: true
stack: mixed
auto-route: true
strict-route: false
규칙 모드는 도메인, IP, 프로세스와 네트워크 유형을 설정 파일에 따라 순서대로 판단하고, 프록시 그룹이 실제로 사용할 노드를 결정합니다. 모든 트래픽을 같은 경로로 보내 발생하는 우회 문제를 해결하는 방식입니다. 로컬 서비스는 직접 연결하고 특정 사이트는 프록시 그룹으로 보내며, 일치하지 않는 트래픽은 마지막 규칙이 처리합니다. 설정할 때는 더 구체적인 규칙을 앞에, 최종 대체 규칙을 뒤에 배치해야 합니다. 프록시 그룹 이름은 규칙 대상과 정확히 일치해야 합니다. 단순한 전역 프록시보다 장기 실행에 적합하고, 특정 요청이 어느 규칙에 걸렸는지도 쉽게 확인할 수 있습니다.
proxy-groups:
- name: 수동 선택
type: select
proxies:
- DIRECT
rules:
- DOMAIN-SUFFIX,example.com,수동 선택
- MATCH,DIRECT
DNS를 한곳에서 처리하면 시스템 해석 결과와 프록시 규칙이 서로 어긋나는 상황을 줄일 수 있습니다. 클라이언트가 DNS 질의를 가로채면 도메인 유형에 따라 해석 서버를 선택하고 Fake-IP 매핑과 연결 기록을 일치시킬 수 있습니다. 핵심은 단순히 더 빠른 응답을 얻는 것이 아니라 도메인 규칙 판단과 실제 연결 대상이 같은 경로에 있도록 하는 데 있습니다. 설정할 때는 LAN 도메인, 시간 동기화 서비스와 일부 게임 도메인에 대한 필터 규칙을 유지하세요. 코어 DNS를 끄는 경우 시스템, 브라우저와 다른 보안 프로그램이 암호화 DNS를 별도로 활성화했는지도 함께 확인해야 여러 해석 경로가 서로 덮어쓰는 문제를 피할 수 있습니다.
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
respect-rules: true
mihomo는 여러 프록시 프로토콜을 하나의 설정 체계로 통합하므로, 클라이언트가 구독 내용을 코어에 전달하기만 하면 프로토콜마다 별도의 연결 프로그램을 설치할 필요가 없습니다. 다만 프로토콜 호환이 모든 매개변수의 혼용을 의미하지는 않습니다. 전송 계층, TLS, 서버 이름, 사용자 식별자와 포트는 제공업체가 안내한 정보와 일치해야 합니다. 가져오기에 실패했다면 먼저 구독 내용이 완전한지 확인한 뒤 클라이언트가 mihomo 코어를 올바르게 호출하는지 점검하세요. 기존 코어에 의존하는 클라이언트보다 새 생태계가 계속 발전하는 프로토콜 필드를 다루기 좋지만, 잘못된 필드는 시작 로그에 명확히 나타나므로 로그를 따라 하나씩 수정해야 합니다.
구독을 업데이트하면 원격 설정이 보통 교체됩니다. 개인 규칙을 구독 원문에 직접 추가하면 다음 새로고침 때 사라질 수 있습니다. 덮어쓰기와 병합 기능은 로컬 포트, DNS, 규칙과 프록시 그룹 변경을 별도 계층에 저장한 뒤 구독 내용과 합쳐 실행 설정을 생성합니다. 고정 LAN 설정을 유지하거나 직접 연결 규칙을 추가하고 프록시 그룹 이름을 바꾸려는 사용자에게 적합합니다. 사용할 때는 ‘추가’와 ‘덮어쓰기’를 구분하세요. 추가 규칙은 순서의 영향을 받고, 같은 이름의 필드를 덮어쓰면 기존 값이 교체됩니다. 수정 후에는 덮어쓰기 조각만 보지 말고 최종 생성된 YAML을 확인해야 합니다.
mode: rule
mixed-port: 7890
allow-lan: false
log-level: info
클라이언트 다운로드
그래픽 클라이언트는 구독 가져오기, 프록시 전환과 시스템 프록시 제어를 담당하고, mihomo 코어는 실제 연결과 규칙 판단을 담당합니다. 먼저 기기의 운영체제에 맞는 다운로드 페이지로 이동한 뒤 설치 방식과 사용 습관에 따라 클라이언트를 선택하세요.
데스크톱 업무, 브라우저 프록시와 TUN 가로채기가 필요한 프로그램에 적합합니다. 다운로드 페이지에서 그래픽 클라이언트를 한눈에 확인하고 현재 유지 관리되는 프로젝트와 보관된 프로젝트를 구분할 수 있습니다. 설치 후 먼저 구독을 가져오고 필요할 때만 시스템 프록시를 켜세요. 시스템 프록시를 읽지 않는 앱에서만 추가로 TUN 설정이 필요합니다.
다운로드 페이지로 이동Apple Silicon 및 Intel Mac에 적합합니다. 설치 패키지를 고를 때 먼저 프로세서 아키텍처를 확인하고, 처음 실행할 때는 시스템 네트워크 확장 또는 프록시 권한을 허용해야 합니다. 메뉴 막대 클라이언트는 일상적인 전략 전환에 편리하고, 데스크톱형 클라이언트는 연결 기록, 규칙 일치와 구독 내용을 확인하는 데 더 적합합니다.
다운로드 페이지로 이동Android 클라이언트는 일반적으로 시스템 VPN 인터페이스를 통해 앱 트래픽을 가로채므로 앱마다 프록시를 설정할 필요가 없습니다. 설정을 가져온 뒤 앱별로 프록시 경유 여부를 지정할 수 있습니다. 백그라운드에서 연결이 끊기면 노드만 조정하지 말고 시스템 절전 정책, VPN 권한과 백그라운드 실행 제한을 확인하세요.
다운로드 페이지로 이동iPhone과 iPad는 시스템 네트워크 확장을 통해 프록시 연결을 구성합니다. 설치 후 VPN 설정 추가를 허용하고 클라이언트에서 구독을 가져와야 합니다. 모바일 네트워크와 Wi-Fi를 전환하면 시스템이 연결을 다시 구성할 수 있습니다. 규칙이 예상대로 적용되지 않으면 먼저 설정을 다시 불러온 뒤 현재 프록시 그룹을 확인하세요.
다운로드 페이지로 이동데스크톱 사용자는 그래픽 인터페이스가 있는 클라이언트를 선택할 수 있고, 서버, 소프트 라우터와 컨테이너 환경에서는 mihomo 코어를 직접 실행하는 경우가 많습니다. 코어를 직접 실행할 때는 설정 경로, 실행 권한, 로그와 자동 시작을 직접 관리하고 투명 프록시에 필요한 라우팅 및 방화벽 규칙을 명확히 설정해야 합니다.
다운로드 페이지로 이동빠른 시작 미리보기
처음부터 모든 설정을 수정할 필요는 없습니다. 먼저 클라이언트를 설치하고 구독을 가져온 뒤 기본 연결이 정상인지 확인하고, 이후 프록시 그룹, DNS와 TUN을 차례로 설정하세요.
다운로드 페이지에서 현재 운영체제를 선택한 다음 프로세서 아키텍처와 사용 목적에 맞는 클라이언트를 고르세요. Windows와 macOS 사용자는 보통 그래픽 클라이언트로 시작하고, Android와 iOS는 시스템 VPN 권한을 허용해야 하며, Linux 서버 사용자는 코어를 직접 사용할 수 있습니다. 설치가 끝나면 먼저 클라이언트를 열어 화면이 정상적으로 표시되는지 확인하세요. 설정을 가져오기 전에는 시스템 프록시를 반복해서 전환하지 않는 것이 좋습니다.
설정 또는 구독 페이지에 서비스 제공업체가 발급한 구독 주소를 붙여넣고 업데이트한 뒤 방금 가져온 설정을 선택하세요. 이어서 프록시 또는 전략 페이지에서 선택 그룹에 사용 가능한 노드가 표시되는지 확인합니다. 구독 주소는 일반 웹페이지 링크가 아니므로 브라우저에서 내용이 완전한지 확인해서는 안 됩니다. 클라이언트에서 구문 분석 실패가 표시되면 복사 과정에서 공백이 들어갔는지, 주소가 만료되지 않았는지, 설정 내용이 YAML 구조에 맞는지 확인하세요.
먼저 규칙 모드를 선택한 다음 시스템 프록시 또는 모바일 VPN을 활성화하세요. 연결 기록을 열어 요청이 예상한 프록시 그룹으로 들어가는지 확인하고, 로컬 서비스에 접속해 직접 연결 규칙이 계속 적용되는지도 확인합니다. 일반 브라우저는 연결되지만 독립 앱에 트래픽이 없다면 TUN 활성화를 고려하세요. 도메인 해석에 문제가 있으면 DNS 설정으로 돌아가 향상된 모드와 필터 목록을 점검합니다. 이 순서대로 확인하면 노드, 규칙, 시스템 가로채기와 DNS 문제를 분리해 찾을 수 있습니다.
오픈 소스 생태계와 코어 전환
클라이언트 인터페이스와 프록시 코어는 서로 독립된 두 계층입니다. 이 관계를 이해해야 업데이트가 어디에서 비롯됐는지 판단하고, 문제가 발생했을 때 올바른 로그와 설정 위치를 찾을 수 있습니다.
Clash는 처음부터 YAML 설정, 규칙 목록과 프록시 그룹을 중심으로 한 사용 방식을 구축했으며 많은 데스크톱 및 모바일 클라이언트가 이 구조를 바탕으로 개발되었습니다. 기존 코어의 개발이 중단된 뒤에도 사용자가 보유한 구독 형식, 규칙 사용 습관과 클라이언트 조작 방식이 함께 사라진 것은 아닙니다. mihomo는 일반적인 Clash 설정과의 호환성을 바탕으로 코어 기능을 계속 유지 관리하고 있습니다. 따라서 오늘날 많은 ‘Clash Meta 클라이언트’는 본질적으로 그래픽 인터페이스가 mihomo를 호출해 연결, DNS, 규칙 일치와 트래픽 가로채기를 수행하는 형태입니다.
이 전환 덕분에 보통 처음부터 설정을 다시 작성할 필요는 없지만, 기존 필드를 모두 그대로 유지해도 된다는 뜻은 아닙니다. 오랫동안 업데이트되지 않은 템플릿에는 이미 의미가 없어진 옵션이나 기존 클라이언트 전용 필드가 포함되어 있을 수 있습니다. 이전할 때는 원래 설정을 먼저 가져오고 시작 로그를 확인한 다음 DNS, TUN과 프록시 그룹을 하나씩 정리하는 편이 안전합니다. 많은 덮어쓰기 내용을 한꺼번에 복사하는 방식은 피하세요.
mihomo 코어는 네트워크 연결과 규칙 실행을 담당하고, Clash Plus, Clash Verge Rev, FlClash 등의 클라이언트는 그래픽 조작, 시스템 통합과 설정 관리를 담당합니다. 규칙 세트 프로젝트는 재사용 가능한 도메인 또는 IP 분류를 제공합니다. 각 구성요소는 서로 다른 일정으로 업데이트할 수 있으며, 사용자는 플랫폼에 맞춰 인터페이스를 바꾸면서도 비슷한 설정 방식을 유지할 수 있습니다. 인터페이스 충돌, 트레이 기능 오류 또는 시스템 프록시 전환 불가 문제는 먼저 클라이언트를 확인해야 합니다. 설정 해석, 프로토콜 연결과 규칙 일치 문제는 코어 로그를 확인하세요.
계층화된 구조는 단일 클라이언트에 대한 의존성도 줄여 줍니다. 데스크톱 설정을 mihomo를 호출하는 다른 클라이언트로 옮길 수 있고, 서버 설정도 경로와 권한을 명확히 한 뒤 코어에 직접 맡길 수 있습니다. 다만 클라이언트마다 덮어쓰기 스크립트, 설정 저장 방식과 시스템 서비스 구현이 다르므로 이전 전에 로컬 규칙을 내보내고 현재 사용하는 DNS와 프록시 설정을 기록해야 합니다.
Clash 설정은 주로 포트, 프록시 노드, 프록시 그룹, DNS와 규칙을 선언합니다. 클라이언트는 설정을 읽은 뒤 구독과 로컬 덮어쓰기를 먼저 병합하고 최종 결과를 mihomo에 전달할 수 있습니다. 실제 연결 방향을 결정하는 것은 구독 원문이나 특정 덮어쓰기 조각이 아니라 병합된 실행 설정입니다. 문제를 확인할 때는 클라이언트가 생성한 최종 설정을 찾아 로그와 함께 판단해야 하며, 구독 편집기만 바라보는 것보다 훨씬 신뢰할 수 있습니다.
규칙은 순서대로 일치하므로 앞쪽의 구체적인 조건이 뒤쪽의 포괄적인 조건보다 우선하는 경우가 많습니다. 프록시 그룹은 일치 후 사용할 노드를 결정합니다. DNS 해석은 도메인 규칙과 IP 규칙이 바라보는 대상에 영향을 주고, TUN은 어떤 앱 트래픽이 코어로 들어갈 수 있는지를 결정합니다. 네 요소는 서로 연결되어 있으므로 ‘노드를 바꿔도 해결되지 않는다’고 해서 곧바로 노드 문제라고 단정할 수 없습니다. 요청이 코어에 들어오지 않았거나 더 앞선 규칙이 다른 프록시 그룹으로 보냈을 수도 있습니다.
클라이언트 업데이트와 코어 업데이트는 해결하는 문제가 다릅니다. 클라이언트 업데이트는 설치 방식, 인터페이스 배치, 시스템 서비스와 구독 관리를 바꿀 수 있고, 코어 업데이트는 프로토콜 구현, DNS 동작, 규칙 문법과 네트워크 스택에 영향을 줄 가능성이 큽니다. 업데이트 후 기본 연결이 정상이라면 보통 즉시 설정을 다시 작성할 필요는 없습니다. 로그에 필드 사용 중단이나 해석 실패가 나타나거나 기존 네트워크 동작이 명확히 달라진 경우에만 관련 문서를 확인하고 해당 부분을 조정하세요.
장기간 사용할 때는 구조가 단순한 기본 설정을 하나 보관하는 것이 좋습니다. 실행 모드, 포트, DNS, 프록시 그룹과 마지막 규칙을 명확히 정한 뒤 규칙 세트나 덮어쓰기로 필요한 기능을 확장하세요. 설정이 복잡할수록 업데이트 후 어느 계층에서 충돌이 발생했는지 판단하기 어려워집니다. 기본 연결이 작동하는지 먼저 확인하고 사용자 규칙을 하나씩 추가하는 방식이 기존 코어에서 새 코어로 이전할 때 유지 관리 비용이 적습니다.
설정 및 문제 해결 문서
DNS 작동 원리, 인증서 오류부터 라우터 배포까지 구체적인 문제별로 설정 경로를 분석합니다. 클라이언트는 연결되지만 동작이 예상과 다를 때 다음 원인을 찾아보는 데 도움이 됩니다.
DNS 질의가 코어로 들어오는 단계부터 가상 주소 풀이 도메인 매핑을 저장하는 방식, 연결 단계에서 대상을 복원하는 과정까지 살펴봅니다. 브라우저, 게임과 LAN 서비스에 어떤 필터 전략이 적합한지도 설명합니다. 또한 Redir-Host의 해석 경로를 함께 다뤄 문제가 주소 매핑에서 비롯됐는지 상위 DNS에서 비롯됐는지 판단할 수 있도록 돕습니다.
본문 전체 보기 →인증서 오류는 시스템 시간, 브라우저 캐시, 노드 경로, 로컬 보안 프로그램 또는 복호화 설정에서 발생할 수 있습니다. 오류가 나타나는 범위에 따라 단계적으로 확인합니다. 먼저 특정 사이트에만 영향을 주는지 판단하고 직접 연결 결과, 시스템 인증서 상태와 프록시 로그를 대조해 모든 인증서 문제를 노드 탓으로 돌리지 않도록 합니다.
본문 전체 보기 →메인 라우터에서 직접 실행하는 구조와 바이패스 라우터가 트래픽을 가로채는 구조를 비교하고, 바이너리 아키텍처, 설정 디렉터리, 투명 프록시, DNS 전달과 부팅 시 자동 시작의 관계를 설명합니다. 배포 전 아키텍처 판단에 초점을 맞춰 어떤 트래픽이 코어를 통과하는지, 기존 라우터가 DHCP와 게이트웨이 역할을 계속 맡는지 확인할 수 있도록 구성했습니다.
본문 전체 보기 →