칩과 시스템 요구 사항 확인
Apple 메뉴에서 ‘이 Mac에 관하여’를 열고 칩 또는 프로세서 이름을 확인하세요. Apple Silicon과 Intel은 아키텍처에 맞는 설치 파일이 각각 필요합니다. 다운로드 페이지에서 클라이언트의 최소 시스템 요구 사항도 확인하세요. 앱을 실행하기 전에 ‘응용 프로그램’ 폴더로 옮기고, 디스크 이미지에서 바로 실행한 채 사용하지 마세요.
시스템 프록시 연결부터 규칙 기반 라우팅까지, Mac 칩에 맞는 클라이언트를 선택하고 YAML 설정 및 TUN 사용 방법을 확인하세요.
기능은 클라이언트 구현과 사용 중인 코어에 따라 다릅니다. 설정 이름은 실제 UI를 기준으로 확인하세요.
시스템 프록시는 현재 네트워크 서비스의 HTTP, HTTPS, SOCKS 연결을 로컬 수신 포트로 지정합니다. 먼저 브라우저에서 Clash를 사용하려는 경우 적합합니다. 설정을 가져와 코어를 실행한 다음 클라이언트에서 시스템 프록시를 켜세요. 포트는 실행 중인 설정과 일치해야 합니다. Safari는 일반적으로 시스템 설정을 따르지만 터미널 도구는 프록시를 별도로 지정해야 할 수 있습니다. 시스템 프록시는 앱이 프록시 설정을 따르는 경우에만 적용되므로, 모든 프로세스를 자동으로 처리하거나 최종 연결 경로를 대신 결정하지는 않습니다. TUN과의 차이는 트래픽을 연결하는 방식에 있습니다.
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
TUN은 가상 네트워크 인터페이스로 트래픽을 받아 시스템 프록시 설정을 읽지 않는 앱에도 사용할 수 있습니다. mihomo 기반 클라이언트에서는 보통 먼저 서비스를 설치하거나 권한을 부여한 뒤 TUN을 켜고, 라우팅 및 DNS 설정을 함께 구성해야 합니다. 시스템 프록시보다 더 많은 트래픽을 처리할 수 있지만 다른 VPN, 가상 머신 네트워크, 기업 네트워크 정책과 충돌할 가능성도 큽니다. 처음 설정할 때는 일반 프록시가 작동하는지 먼저 확인하고 TUN은 따로 테스트하세요. 인터넷이 끊기면 TUN을 끄고 로그를 보관한 뒤 라우팅을 점검하세요. 여러 설정을 한꺼번에 바꾸지 마세요.
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
규칙 기반 라우팅은 요청의 특성에 따라 직접 연결, 차단 또는 지정된 정책 그룹을 선택합니다. 규칙 모드에서는 코어가 목록 순서대로 도메인, 대상 IP 등의 조건을 확인하고, 일치하는 규칙의 연결 경로를 사용합니다. 목록 마지막에는 기본 처리 규칙을 둡니다. 전역 모드와 달리 규칙 모드에서는 로컬 서비스와 프록시가 필요한 요청을 따로 처리할 수 있습니다. 정책 그룹은 연결 경로를 선택하고 규칙은 어떤 요청을 해당 그룹으로 보낼지 결정하므로 서로 대체할 수 없습니다. 변경 후에는 웹페이지가 열리는지만으로 판단하지 말고 연결 기록에서 적용된 규칙을 확인하세요.
mode: rule
rules:
- DOMAIN-SUFFIX,local,DIRECT
- IP-CIDR,127.0.0.0/8,DIRECT
- MATCH,DIRECT
설정 오버라이드는 로컬 환경에 맞춘 설정을 원격 구독과 분리해 저장하는 기능입니다. 예를 들어 수신 포트를 고정하거나 로컬 네트워크 직접 연결 규칙을 추가하고 로그 수준을 조정할 수 있습니다. 구독 파일을 직접 수정하면 다음 업데이트에서 변경 사항이 덮어써질 수 있습니다. 오버라이드를 지원하는 클라이언트는 실행 설정을 생성할 때 로컬 내용을 병합할 수 있습니다. 모든 Clash 코어에 공통으로 적용되는 스위치는 아니며, 클라이언트마다 객체, 배열, 스크립트를 처리하는 방식이 다릅니다. 사용 전 원본 설정을 백업하고 병합 순서를 확인한 다음 최종 실행 설정을 살펴보세요. 특히 규칙이 추가되는 위치와 같은 이름의 정책 그룹이 교체되는지 확인해야 합니다.
mixed-port: 7890
allow-lan: false
log-level: info
먼저 일반 시스템 프록시 연결을 확인한 뒤, 앱에 필요한 경우 TUN과 오버라이드를 추가하세요. 각 단계의 변경 사항을 쉽게 파악할 수 있습니다.
Apple 메뉴에서 ‘이 Mac에 관하여’를 열고 칩 또는 프로세서 이름을 확인하세요. Apple Silicon과 Intel은 아키텍처에 맞는 설치 파일이 각각 필요합니다. 다운로드 페이지에서 클라이언트의 최소 시스템 요구 사항도 확인하세요. 앱을 실행하기 전에 ‘응용 프로그램’ 폴더로 옮기고, 디스크 이미지에서 바로 실행한 채 사용하지 마세요.
신뢰할 수 있는 출처의 구독 URL 또는 로컬 YAML 파일을 사용하세요. 설정을 가져온 뒤 해당 설정이 선택되어 있는지 확인하고 정책 그룹에서 연결 경로를 고르세요. 클라이언트 설치와 설정 제공처는 별개입니다. 앱을 설치해도 사용할 원격 노드가 자동으로 생성되거나 네트워크 서비스가 제공되는 것은 아닙니다.
코어를 실행한 다음 시스템 프록시를 켜고 브라우저에서 필요한 사이트에 접속해 보세요. 이어서 연결 기록에서 대상, 적용된 규칙, 정책 그룹을 확인하세요. 브라우저는 되지만 터미널에서 연결되지 않는다면 터미널의 프록시 설정부터 살펴보세요. 곧바로 노드 문제라고 단정하거나 클라이언트를 재설치하지 마세요.
처음 연결할 때는 트래픽 처리 방식을 하나만 활성화하는 것이 좋습니다. 다른 VPN이나 프록시 도구도 실행 중이라면 용도를 기록하고 테스트 중에는 일시 중지해 라우팅과 DNS를 두 프로그램이 번갈아 바꾸지 않도록 하세요. 테스트가 끝나면 클라이언트를 정상적으로 종료하고 시스템 프록시가 원래 상태로 돌아왔는지 확인하세요. 자세한 권한 설정과 문제 복구 방법은 설치 가이드에서 확인할 수 있습니다.
운영체제를 선택해 클라이언트 목록으로 이동하세요. 설치 파일, 아키텍처 및 시스템 요구 사항은 다운로드 페이지에서 한눈에 확인할 수 있습니다.
여러 기기에서 사용하더라도 설정 문법이 비슷하다고 모든 기능이 동일한 것은 아닙니다. 먼저 클라이언트가 사용하는 코어를 확인한 다음 프로토콜, 규칙 세트 형식, DNS 설정 항목을 지원하는지 살펴보세요. Mac의 시스템 프록시 스위치, 모바일 기기의 VPN 권한, 데스크톱 클라이언트의 서비스 설치는 플랫폼마다 연결 방식이 다르므로 한 기기의 UI 조작을 다른 기기에 그대로 적용할 수 없습니다. 구독을 공유할 수 있더라도 로컬 수신 포트, 파일 경로, UI 설정은 기기별로 관리하세요.
먼저 Apple Silicon 또는 Intel에 맞는 설치 파일을 선택한 뒤 Clash Plus, Clash Verge Rev, FlClash의 설정 관리 방식을 비교하세요. 메뉴 막대 기능이나 TUN이 필요하다면 UI 구현 여부와 서비스 권한을 각각 확인하세요. 특정 클라이언트의 옵션을 모든 Mac 클라이언트에 공통으로 제공되는 기능이라고 가정하지 마세요.
다운로드 페이지로 이동 macOS 클라이언트Clash Plus, Clash Verge Rev 등의 GUI 클라이언트를 살펴보고 운영체제 및 아키텍처 요구 사항을 확인하세요. Clash for Windows 대안을 찾는다면 먼저 구독과 로컬 규칙을 백업한 뒤 설정을 옮기세요. 스토어 앱에서 루프백 접속 문제가 발생하면 가이드의 Windows 관련 내용을 확인할 수 있습니다.
다운로드 페이지로 이동 Windows 클라이언트기기의 프로세서 아키텍처에 맞는 설치 파일을 선택하고, 처음 연결할 때 표시되는 시스템 VPN 권한 안내를 읽으세요. 모바일 운영체제의 백그라운드 제한은 연결 유지에 영향을 줄 수 있습니다. 네트워크를 전환한 뒤에는 DNS 조회와 연결 상태를 다시 확인하세요. 데스크톱의 시스템 프록시 문제 해결 방법을 그대로 적용할 수는 없습니다.
다운로드 페이지로 이동 Android 클라이언트다운로드 페이지에서 Clash Plus의 App Store 링크와 공식 웹사이트 clashplus.io를 확인할 수 있습니다. 설정을 가져온 뒤 시스템 안내에 따라 VPN 구성을 추가하고 사용할 앱에서 연결을 확인하세요. Mac과 구독을 공유하기 전에 모바일 클라이언트가 해당 프로토콜과 설정 항목을 지원하는지 확인하고, 기기별 로컬 설정은 따로 유지하세요.
다운로드 페이지로 이동 iOS 클라이언트데스크톱 환경에서는 Clash Verge Rev 또는 FlClash를 선택하고 배포판에 맞는 패키지 형식을 확인하세요. 서버 및 라우터 사용자는 코어 섹션에서 mihomo를 확인할 수 있습니다. 코어만 실행하는 경우 설정 디렉터리, 프로세스 관리, 네트워크 권한을 직접 처리해야 하며 데스크톱 메뉴를 통한 트래픽 연결 기능은 사용할 수 없습니다.
다운로드 페이지로 이동 Linux 클라이언트포트와 트래픽 연결 방식. 이 페이지의 팝업은 로컬 프록시 연결 지점을 보여 주며 원격 노드 주소가 아닙니다. 클라이언트에서 다른 포트를 사용한다면 시스템 네트워크 설정과 명령줄 매개변수도 함께 바꿔야 합니다. YAML의 포트만 수정하고 설정을 다시 불러오지 않으면 실행 중인 프로세스는 이전 값을 계속 사용할 수 있습니다. 먼저 로그와 현재 수신 포트를 확인한 뒤 요청을 테스트하세요.
구독과 로컬 변경 사항. 구독 URL에는 접근 자격 증명이 포함될 수 있으므로 민감 정보로 취급하세요. 공개 스크린샷이나 저장소에 올리지 마세요. 클라이언트를 바꿀 때는 먼저 로컬 규칙과 오버라이드를 내보낸 다음 구독을 다시 가져오세요. 앱 데이터 디렉터리 전체를 복사하면 이전 경로, 캐시, 호환되지 않는 UI 설정까지 함께 옮겨질 수 있습니다.
Clash 생태계는 하나의 이름 아래 동일한 UI를 제공하는 단일 소프트웨어가 아닙니다. 설정을 파싱하고 규칙을 실행해 연결을 만드는 것은 코어의 역할이며, 구독 관리와 시스템 프록시 스위치, 메뉴 막대, 업데이트 화면은 GUI 클라이언트가 담당합니다. 이 역할 구분을 알면 ‘UI에 옵션이 없음’, ‘설정 항목이 지원되지 않음’, ‘트래픽 연결이 적용되지 않음’을 서로 다른 문제로 나눠 해결할 수 있어 불필요한 재설치와 무작정 설정을 바꾸는 일을 줄일 수 있습니다.
원본 Clash 프로젝트의 업데이트가 중단된 뒤에도 커뮤니티는 파생 코어와 GUI 클라이언트를 계속 개발했습니다. mihomo는 Clash Meta 브랜치의 기술 방향을 이어받았으며, 익숙한 설정 항목을 유지하면서 자체 기능도 추가했습니다. 이전 설정을 읽을 수 있다고 해서 새 프로토콜, 규칙 세트 형식, DNS 옵션이 모두 구형 코어에서 작동하는 것은 아닙니다. 파싱 오류가 나면 앱 아이콘이나 설치 파일 이름만 보지 말고 실제 실행 중인 코어 이름을 확인한 뒤 해당 문서를 살펴보세요.
오래된 가이드에는 현재와 달라진 메뉴 이름이나 권한 설정 절차가 나올 수 있습니다. 참고할 때는 ‘현재 네트워크 서비스의 프록시 설정 열기’, ‘최종 실행 설정 확인’처럼 작업의 목적을 파악한 뒤 사용 중인 클라이언트에서 해당 메뉴를 찾으세요. 보관된 클라이언트는 이전 설정을 이해하는 데 도움이 될 수 있지만, 선택할 때는 현재 운영체제와의 호환성 및 프로젝트 안내를 확인해야 합니다. 예전 스크린샷이 현재 UI를 보장하지는 않습니다.
같은 mihomo를 기반으로 한 클라이언트라도 오버라이드 방식, 구독 업데이트 방법, 시스템 서비스 관리 절차가 다를 수 있습니다. 코어가 특정 설정 항목을 지원한다고 해서 UI에 해당 버튼이 있는 것은 아닙니다. UI에 TUN 스위치가 있어도 서비스 권한 설정까지 완료된 것은 아닙니다. 문제를 확인할 때는 먼저 설정 생성 여부, 코어 실행 여부, 운영체제가 트래픽을 올바른 연결 지점으로 보내는지를 순서대로 살펴보세요. 여러 스위치를 한꺼번에 바꾸기보다 단계별로 확인하는 편이 결과를 재현하기 쉽습니다.
이 페이지의 YAML 예시는 설정 항목의 위치를 설명하기 위한 것이며, 그대로 연결할 수 있는 완전한 구독 설정은 아닙니다. 실제 설정에는 노드, 정책 그룹, 사용 환경에 맞는 규칙이 필요합니다. 예시를 기존 파일에 병합하기 전에 들여쓰기와 설정 계층을 확인해 최상위 키가 중복되지 않도록 하세요. 수정 후에는 먼저 클라이언트의 설정 검사 기능을 사용하고 실행 설정을 다시 불러오세요. 문제가 생기면 되돌릴 수 있도록 수정 전 파일을 백업해 두세요.
mihomo의 소스 코드와 문서에서 설정 항목의 의미, 플랫폼 제한, 변경 이력을 확인할 수 있습니다. 코어 저장소와 GUI 클라이언트 저장소를 구분해서 살펴보세요. 프록시 프로토콜, 규칙 적용, DNS 동작은 보통 코어 문서에서 확인하고, 구독 목록, 메뉴 막대, 서비스 설치는 해당 클라이언트 문서를 참고해야 합니다. 코드 공개는 구현을 추적하는 데 도움이 되지만 설정 출처와 로컬 권한을 판단하는 일을 대신하지는 않습니다.
프로젝트에 문제를 제보할 때는 필요한 시스템 정보, 코어 종류, 최소 재현 설정을 남기세요. 로그에 방문 도메인, 구독 URL, 노드 정보가 포함될 수 있으므로 공개하기 전에 민감 정보를 가리세요. ‘어떤 작업을 했는지, 예상한 결과는 무엇인지, 실제로 어떤 문제가 발생했는지’를 구체적으로 설명하고 평소 사용하는 설정 파일 전체는 올리지 마세요. 유지 관리자가 원인을 찾기 쉬워지고 불필요한 정보 노출도 줄일 수 있습니다.
클라이언트 업데이트, 코어 업데이트, 구독 업데이트는 서로 별개의 과정입니다. 클라이언트 업데이트는 설정 관리나 권한 절차를 바꿀 수 있고, 코어 업데이트는 설정 항목의 동작에 영향을 줄 수 있으며, 구독 업데이트는 노드와 규칙을 바꿀 수 있습니다. 업데이트 전에 현재 트래픽 연결 방식과 로컬 오버라이드를 기록하세요. 업데이트 후에는 브라우저, 명령줄, 로컬 네트워크 서비스를 각각 확인하세요. 앱이 실행된다는 이유만으로 모든 네트워크 경로가 정상이라고 판단하지 마세요.
업데이트 후 문제가 생기면 먼저 최종 실행 설정과 로그를 비교한 다음 어느 단계의 변경을 되돌릴지 결정하세요. 원격 구독이 덮어써졌다면 앱을 재설치하기보다 로컬 규칙을 복원하는 편이 간단합니다. 시스템 프록시가 남아 있다면 네트워크 서비스 설정을 확인하세요. TUN이 시작되지 않는다면 서비스 권한과 충돌하는 프로그램을 점검하세요. 한 번에 한 항목씩 변경 범위를 좁히면 문제의 원인을 추적하기 쉽습니다.
구현과 변경 이력을 살펴볼 때 사용하세요. 일반적인 설치에는 저장소를 복제하거나 코어를 직접 빌드할 필요가 없습니다.
git clone https://github.com/MetaCubeX/mihomo.git
로컬 연결 문제부터 정책 그룹 선택까지, 필요한 주제를 이어서 확인하세요.
노드 품질, 연결 경로, Mac 설정을 차례로 점검하세요. DNS 모드, TUN 스택 선택, Wi-Fi 절전 간섭까지 살펴 macOS 속도 저하 원인을 찾습니다.
전체 글 읽기 →세 가지 자동 정책 그룹의 속도 측정 방식, 전환 시점, interval 및 tolerance 설정을 비교합니다. YAML 예시와 각 방식에 적합한 사용 환경도 확인하세요.
전체 글 읽기 →원본 코어의 업데이트 중단부터 mihomo의 이어받기까지, 코어와 GUI 클라이언트, 규칙 세트 프로젝트의 역할을 살펴보고 macOS에 맞는 클라이언트 구성을 선택할 수 있도록 안내합니다.
전체 글 읽기 →