Clash Meta 설치 및 설정 가이드

공통 준비: 구독, 코어, 설정 범위

클라이언트·코어·구독의 역할 구분

클라이언트는 설정 관리, 화면 조작, 권한 요청과 시스템 연동을 담당합니다. mihomo 코어는 포트를 열고 규칙을 해석해 아웃바운드를 선택한 뒤 연결을 전달합니다. 구독은 노드 또는 전체 설정을 제공합니다. 클라이언트를 설치했다고 바로 사용할 수 있는 프록시 서비스가 생기는 것은 아닙니다. 시작하기 전에 유효한 구독이 있고 구독 제공처에 접속할 수 있는지, 구독에 전체 설정이 포함되는지 노드 목록만 제공되는지 확인하세요.

전체 설정에는 보통 프록시 노드, 정책 그룹, 규칙, DNS 설정이 포함됩니다. 노드 목록만 제공되는 경우 나머지 설정은 클라이언트의 설정 템플릿으로 보완해야 합니다. 둘 다 YAML 형식일 수 있으므로 파일 확장자만 보고 유형을 판단하지 마세요. 가져온 뒤 노드는 보이지만 선택할 정책 그룹이 없다면 가져오기 방식과 템플릿부터 확인하고, 노드 서버 주소를 바로 수정하지 마세요. 구독 관리 웹페이지 주소와 구독 API 주소는 다릅니다. 제공처에서 클라이언트용으로 안내한 구독 링크를 복사하세요.

구독 링크는 계정에 접근할 수 있는 권한을 담고 있는 경우가 많으므로 민감 정보로 취급해야 합니다. 공개 변환 사이트, 스크린샷, 공개 게시판에 붙여 넣지 마세요. 설정을 공유할 때는 노드 비밀번호, 구독 주소, 컨트롤 인터페이스 키를 삭제하세요. 유출이 확인되면 구독 제공처에서 링크를 새로 발급받으세요. 문제 해결용 스크린샷에는 오류 유형, 설정 항목 이름, 비식별 처리한 도메인만 남기고, 전체 로그도 확인한 뒤 전송하세요.

복구 가능한 테스트 환경 만들기

설치 전에 운영체제 버전, 프로세서 아키텍처, 현재 네트워크, 기존 프록시·VPN 소프트웨어를 기록하세요. 첫 테스트에서는 다른 트래픽 처리 프로그램을 종료해 네트워크 경로를 단순하게 유지하세요. 조직에서 관리하는 기기는 정책에 따라 제한될 수 있으므로 권한을 높여 조직의 요구사항을 우회하지 마세요. 관리자 권한이 필요한 서비스 설치, 가상 네트워크 어댑터, 라우팅 변경은 필요한 이유를 확인한 뒤 진행하세요.

먼저 기본 규칙 모드에서 시스템 프록시를 켜고 브라우저 접속을 확인한 다음, 필요할 때 TUN을 추가하세요. 문제가 생기면 기본 아웃바운드와 트래픽 처리 중 어느 단계에서 발생했는지 구분하기 쉽습니다. 정상 작동하는 설정 사본과 기존 시스템 프록시 상태를 기록하고, 설정 항목은 한 번에 하나씩 변경하세요. DNS, 규칙, 라우팅 설정을 한꺼번에 덮어쓰면 이후 로그와 비교할 기준을 잃게 됩니다.

설정 파싱을 확인한 뒤 연결 여부 확인

아래는 mihomo가 시작되어 로컬 포트를 열 수 있는지 확인하기 위한 최소 진단 설정입니다. 직접 연결만 지원하며 프록시 노드는 포함하지 않으므로 구독을 대신할 수 없습니다. 혼합 포트는 HTTP와 SOCKS를 모두 지원합니다. LAN 액세스를 끄면 로컬 기기에서만 접속하도록 범위를 제한할 수 있습니다. 기존 클라이언트가 같은 포트를 사용 중이라면 해당 인스턴스를 종료하거나 테스트용으로 비어 있는 다른 포트를 지정하세요.

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

코어 설정 검사 명령을 실행하면 문법과 일부 참조 관계가 올바른지 확인할 수 있지만, 구독의 서버에 연결할 수 있는지는 알 수 없습니다. GUI 클라이언트는 실제 실행 설정을 생성할 수 있으므로 검사 대상은 구독 캐시가 아니라 코어가 최종적으로 불러오는 파일일 수 있습니다. 로그에 들여쓰기 오류나 알 수 없는 필드가 나오면 표시된 설정 위치부터 앞쪽을 확인하세요. 원인이 바로 위 줄에 있을 수도 있습니다.

mihomo -t -f config.yaml

YAML은 공백으로 들여쓰고 탭을 섞어 쓰지 마세요. 규칙에 적힌 정책 이름은 정의된 정책 그룹 또는 노드 이름과 대소문자 및 공백까지 정확히 일치해야 합니다. 원격 규칙 세트, 노드 제공자, 지리 데이터베이스를 사용한다면 해당 리소스를 다운로드할 수 있어야 합니다. 전체 설정을 성공적으로 불러왔더라도 이러한 의존 항목을 사용할 수 없으면 문제가 발생할 수 있습니다. 문제 해결 시 설정 파싱, 리소스 로드, 요청 전달의 세 단계를 구분하세요.

Windows: 설치, 시스템 프록시, 서비스 권한

설치 파일 선택 및 첫 실행

Windows 클라이언트 다운로드에서 Clash Plus를 선택하세요. 다른 선택지로 Clash Verge Rev, FlClash, Clash Nyanpasu가 있습니다. Clash for Windows는 더 이상 유지 관리되지 않으므로 보관된 설치 파일은 기존 환경을 이해하는 용도로만 참고하고 새로 설치할 때는 기본 선택지로 권장하지 않습니다. 시스템 정보에서 프로세서와 시스템 종류를 확인한 뒤 다운로드 페이지의 아키텍처 및 시스템 요구 사항을 확인하세요. 다른 플랫폼용 설치 파일을 호환되는 파일로 간주하지 마세요.

설치 후에는 먼저 클라이언트를 일반 권한으로 실행하세요. 처음부터 전체 화면을 관리자 권한으로 실행할 필요는 없습니다. 서비스 구성 요소 설치가 필요한 경우 클라이언트의 서비스 관리 메뉴를 사용하고, 시스템 권한 요청을 확인하세요. 제한된 계정으로 서비스를 설치할 수 없다면 먼저 시스템 프록시로 기본 연결을 테스트할 수 있습니다. 서비스 설치 실패와 구독 사용 불가는 서로 다른 문제이므로 구독을 반복해서 가져와도 해결되지 않습니다.

시스템 보안 경고로 실행이 차단되면 다운로드 출처, 파일 속성, 조직의 보안 정책을 확인한 뒤 조치 여부를 결정하세요. 특정 클라이언트를 실행하려고 시스템 보안 기능을 계속 꺼 두지 마세요. 설치 디렉터리, 설정 디렉터리, 코어 실행 디렉터리는 서로 다를 수 있습니다. 기존 설정을 옮길 때는 클라이언트의 가져오기 기능을 사용하고, 기존 코어나 캐시 디렉터리 전체를 새 설치에 덮어쓰지 마세요.

구독을 가져오고 현재 정책 선택

설정 관리 화면에서 원격 구독을 추가하고 전체 링크를 붙여 넣은 뒤 저장하세요. 다운로드가 완료되면 해당 설정을 현재 설정으로 지정하고 프록시 페이지에 정책 그룹이 표시되는지 확인하세요. 구독이 리디렉션을 사용하거나 특정 접속 조건을 요구한다면 실패 로그는 YAML 오류가 아니라 네트워크 오류일 수 있습니다. 응답 내용을 먼저 확인하고, 로그인 페이지를 설정 파일로 오인해 가져오지 마세요.

주요 프록시 정책 그룹에서 사용할 수 있는 노드를 선택하고 클라이언트의 연결 또는 지연 시간 테스트를 실행하세요. 테스트가 성공해도 해당 테스트 요청만 완료된 것이며 모든 웹사이트, UDP, 터미널 트래픽이 처리된다는 뜻은 아닙니다. 자동 선택 그룹은 이후 아웃바운드를 바꿀 수도 있습니다. 문제 해결 단계에서는 노드를 하나로 고정해 같은 대상을 테스트한 뒤 자동 선택으로 되돌리세요. 여러 변수를 동시에 바꾸지 마세요.

규칙 모드를 켠 다음 시스템 프록시를 활성화하고 Windows의 네트워크 프록시 설정에서 주소와 포트가 클라이언트 설정과 일치하는지 확인하세요. 혼합 포트, 컨트롤 인터페이스 포트, 구독 주소는 서로 바꿔 쓸 수 없습니다. 시스템 프록시는 보통 현재 사용자에게만 적용됩니다. 다른 사용자 세션, 시스템 서비스, 일부 독립 앱은 이를 따르지 않을 수 있으므로 브라우저에서 접속된다고 기기 전체의 트래픽이 코어를 통과한다고 볼 수 없습니다.

명령줄과 TUN을 따로 확인

터미널 도구는 환경 변수를 읽을 수도 있고 프록시를 직접 지정해야 할 수도 있습니다. 아래 명령은 이번 요청에만 로컬 프록시를 지정합니다. 포트는 실제 실행 설정과 일치해야 합니다. 먼저 이 방법으로 프록시 연결을 확인한 뒤 터미널 환경 변수를 설정할지 결정하세요. 변수를 장기간 유지하려면 도구가 대소문자별 변수명, 프록시 프로토콜, 예외 목록을 어떻게 지원하는지 확인하세요. 클라이언트를 종료한 뒤에도 터미널이 이전 포트로 연결을 시도할 수 있습니다.

curl.exe --proxy http://127.0.0.1:7890 -I https://example.com

시스템 프록시를 읽지 않는 프로그램까지 처리해야 할 때 클라이언트의 TUN 모드를 켜세요. 서비스가 정상인지 확인하고 가상 네트워크 인터페이스 생성 권한을 허용한 뒤, 코어 로그에 인터페이스나 라우팅 오류가 있는지 확인하세요. 자동 라우팅을 사용할 때는 사내 네트워크, LAN 프린터, 다른 VPN에 대한 접속도 점검해야 합니다. 충돌이 발생하면 제외 라우트나 처리 범위를 조정하고 네트워크 가속 도구를 추가로 켜지 마세요.

TUN을 켠 뒤에도 연결되지 않으면 TUN을 끄고 시스템 프록시로 다시 테스트하세요. 브라우저 연결이 복구되면 가상 인터페이스, 기본 경로, DNS, 다른 VPN을 집중적으로 확인하세요. 두 방식 모두 실패한다면 노드와 설정을 다시 점검하세요. 절전 모드에서 복귀하거나 네트워크를 바꾼 뒤 문제가 생겨도 같은 방식으로 비교하고, 인터페이스 상태를 먼저 확인한 뒤 코어나 서비스를 재시작하세요.

종료, 업데이트, 시스템 프록시 설정 잔류

Windows에서는 창의 닫기 버튼을 눌러도 트레이로 최소화될 수 있으므로 코어가 중지됐다고 단정할 수 없습니다. 제거하거나 다른 클라이언트로 전환하기 전에 시스템 프록시와 TUN을 끈 뒤 트레이 메뉴에서 정상 종료하세요. 예기치 않게 종료한 뒤에도 브라우저가 로컬 프록시에 연결하려 한다면 시스템 프록시 설정이 남아 있는지 확인하세요. 기존 상태를 복구한 뒤 클라이언트를 실행하세요. 프로그램을 닫은 뒤 인터넷이 되지 않는다고 구독이 만료됐다고 단정하지 마세요.

업데이트 전에 사용자 지정 규칙과 오버라이드 설정을 내보내세요. 업데이트 후에는 현재 설정, 정책 그룹 선택, 서비스 상태를 확인하세요. 이전 서비스가 여전히 포트를 점유하거나 이동한 코어 경로를 가리킬 수 있습니다. 포트 충돌이 발생하면 작업 관리자나 클라이언트 로그에서 점유 프로세스를 확인하고 필요한 인스턴스 하나만 남기세요. 브라우저와 터미널 관련 추가 점검은 시스템 프록시가 작동하지 않을 때의 문제 해결을 참고하세요.

macOS: 아키텍처, 네트워크 서비스, 백그라운드 구성 요소

프로세서에 맞는 클라이언트 설치

macOS 다운로드에서 Clash Plus를 우선 선택하세요. 사용 방식에 따라 Clash Verge Rev 또는 FlClash를 선택할 수도 있습니다. ClashX Meta는 더 이상 유지 관리되지 않으므로 보관용으로 사용하는 경우와 계속 유지 관리되는 클라이언트를 구분하세요. 이 Mac에 관하여에서 Apple Silicon인지 Intel인지 확인한 뒤 맞는 설치 파일을 선택하세요. 호환성 계층에서 실행된다고 해서 백그라운드 구성 요소나 가상 네트워크 어댑터 의존 항목까지 현재 시스템과 호환되는 것은 아닙니다.

설치 파일이 디스크 이미지 형식이라면 이미지를 마운트한 뒤 앱을 응용 프로그램 폴더로 옮겨 실행하세요. 이미지 안에서 계속 실행하지 마세요. 실행 전 다운로드 출처를 확인하고 시스템 보안 경고가 표시되면 시스템에서 제공하는 앱 열기 절차를 따르세요. 시스템의 보안 검사를 통째로 끄는 명령은 사용하지 마세요. 이전 클라이언트가 설치되어 있다면 먼저 정상 종료해 여러 메뉴 막대 앱이 프록시 설정을 동시에 변경하지 않도록 하세요.

클라이언트가 보조 도구, 백그라운드 서비스, 네트워크 권한을 요청하면 요청한 앱과 현재 작업이 일치하는지 확인하세요. 일부 기능은 특권 보조 프로그램을 통해 라우팅을 설정하지만, 일반 프록시 화면을 계속 높은 권한으로 실행할 필요는 없습니다. 권한이 거부됐다면 클라이언트의 서비스 상태와 시스템 설정의 관련 항목을 확인하세요. 권한 문제를 진단하는 대신 연결 버튼을 반복해서 누르지 마세요.

구독 가져오기 및 네트워크 서비스 확인

설정 페이지에서 구독을 추가하고 파싱이 완료되면 현재 설정으로 지정하세요. 프록시 페이지에서 주요 정책 그룹을 확인한 뒤 노드 하나를 고정해 요청을 테스트하세요. 다른 클라이언트에서 설정을 옮길 때는 상대 경로, 규칙 세트 캐시, 제공자 파일을 특히 확인하세요. 이전 클라이언트에서 이미 다운로드한 파일은 가져오기에 포함되지 않을 수 있으므로 새 클라이언트에서 의존 리소스를 다시 받아야 합니다.

시스템 프록시를 켠 뒤 현재 사용 중인 네트워크 서비스를 확인하세요. macOS는 Wi-Fi, 이더넷 및 다른 인터페이스의 설정을 각각 저장할 수 있으므로 클라이언트가 변경한 서비스가 실제 인터넷 연결에 사용되는 인터페이스와 다를 수 있습니다. 도킹 스테이션, 유선 네트워크 어댑터, 네트워크 위치를 바꾼 뒤에는 상태 막대 아이콘만 보지 말고 설정을 다시 확인하세요. 시스템 프록시 주소는 로컬 리스닝 포트를 가리켜야 하며 컨트롤 인터페이스 주소를 입력하면 안 됩니다.

아래의 읽기 전용 명령으로 현재 시스템 프록시 설정을 확인한 뒤 프록시를 명시한 요청과 비교할 수 있습니다. 출력에 프록시 정보가 있어도 앱이 반드시 이를 따르는 것은 아닙니다. 브라우저 확장 프로그램, 앱 자체 설정, 터미널 환경 변수가 다른 경로를 만들 수 있습니다. 문제를 해결할 때 시스템 설정과 앱 설정을 각각 기록하세요. 한쪽만 변경하고 모든 프로그램에 즉시 적용되기를 기대하지 마세요.

scutil --proxy
curl --proxy http://127.0.0.1:7890 -I https://example.com

TUN과 다른 네트워크 확장의 적용 범위

시스템 프록시를 읽지 않는 앱까지 처리해야 할 때 TUN을 켜고 클라이언트의 백그라운드 구성 요소가 정상적으로 설치됐는지 확인하세요. 설치 및 권한 부여 방식은 클라이언트마다 다르므로 현재 표시되는 안내를 따르세요. 실행 후 인터페이스와 라우팅 관련 로그를 확인해 화면의 스위치만 바뀐 것은 아닌지 확인하세요. 기업 VPN, 네트워크 필터링 도구, 다른 프록시 클라이언트를 함께 실행 중이라면 각 프로그램의 라우팅 범위를 먼저 확인하세요.

LAN 접속에 문제가 있으면 대상이 로컬 네트워크에 있는지, 해당 요청에 실제로 어떤 규칙이 적용됐는지 확인하세요. 시스템 프록시의 우회 목록은 해당 설정을 읽는 프로그램에만 적용되며 TUN의 라우트 제외나 코어 규칙을 대신하지 않습니다. 사내 도메인과 인트라넷 주소에 필요한 DNS 및 직접 연결 경로를 유지하세요. 사설 IP 주소에 접속할 수 없는 문제를 모두 노드 장애로 단정하지 마세요.

덮개를 닫았다가 열거나 절전 모드에서 복귀한 뒤, 또는 Wi-Fi에서 유선 네트워크로 전환한 뒤에는 기존 연결이 이전 네트워크 경로를 계속 사용할 수 있습니다. 대상 요청을 새로 보내고 새로운 연결 기록이 생성되는지 확인하세요. 필요한 경우 클라이언트를 다시 연결하거나 코어를 재시작하되, 설정 전체를 삭제하지 마세요. 기존 페이지에서만 실패하고 새 연결은 정상이라면 구독보다 연결 재사용이나 네트워크 전환이 원인일 가능성이 높습니다.

터미널 환경 및 제거 후 복구

터미널의 프록시 환경 변수는 해당 프로세스와 자식 프로세스에만 적용되며 시스템 전체를 자동으로 변경하지 않습니다. 기존 변수가 어떤 용도로 쓰이는지 모른 채 셸 설정을 덮어쓰지 마세요. 장기간 설정하려면 삭제 방법도 함께 마련하고 인트라넷 대상에 적절한 예외를 설정하세요. GUI에서 실행한 앱이 터미널 환경 변수를 이어받지 않을 수 있으므로 터미널과 브라우저의 연결은 각각 확인해야 합니다.

제거하기 전에 시스템 프록시, TUN, 로그인 시 자동 실행을 끈 뒤 클라이언트에서 제공하는 방법으로 보조 서비스를 제거하세요. 앱을 휴지통으로 옮기는 것만으로는 백그라운드 구성 요소나 이전 프록시 설정이 남을 수 있습니다. 새 클라이언트로 옮긴 뒤에는 활성 상태 보기에서 이전 코어가 실행 중이지 않은지 확인하고 현재 포트, 설정, 실제 아웃바운드를 점검하세요. 두 가지 트래픽 처리 방식의 원리는 TUN과 시스템 프록시의 단계별 비교에서 확인할 수 있습니다.

Android: VPN 권한, 앱별 분할, 백그라운드 실행

설치 전 아키텍처 및 설정 호환성 확인

Android 다운로드에서 Clash Plus를 우선 선택하세요. 다른 선택지로 Clash Meta for Android, FlClash, Surfboard가 있습니다. 먼저 기기 아키텍처와 클라이언트의 최소 시스템 요구 사항을 확인한 뒤 맞는 앱을 설치하세요. 설치 파일 출처 권한은 이번 설치에 필요한 브라우저나 파일 관리자에만 허용하고, 설치 후에는 원래 설정으로 되돌릴 수 있습니다. 회사에서 관리하는 기기라면 앱 설치 정책도 따라야 합니다.

클라이언트가 같은 프록시 생태계에 속한다고 해서 설정 형식까지 완전히 동일한 것은 아닙니다. Clash Plus, Clash Meta for Android, FlClash의 구체적인 지원 범위는 각 구현을 기준으로 확인하세요. Surfboard는 다른 설정 체계를 사용하므로 임의의 mihomo 전체 설정을 그대로 가져와도 모든 규칙이 적용되는 것은 아닙니다. 구독 제공처가 여러 형식을 제공한다면 대상 클라이언트에 맞는 형식을 선택하세요.

기존 앱에서 옮길 때는 유지할 사용자 지정 설정을 먼저 내보낸 뒤 새 앱을 설치하세요. Android에서는 패키지명이 다른 앱을 기존 앱 위에 바로 설치할 수 없는 경우가 많으며, 기존 앱을 삭제하면 앱 전용 설정과 캐시도 사라질 수 있습니다. 클립보드만 믿고 구독 정보를 보관하지 마세요. 신뢰할 수 있는 위치에 가져오기 정보를 저장하고 새 클라이언트에서 설정을 불러올 수 있는지 확인한 뒤 기존 환경을 제거하세요.

구독 가져오기 및 VPN 연결 설정

설정 목록에서 원격 구독을 추가하고 다운로드가 완료될 때까지 기다린 다음 해당 설정을 활성 설정으로 선택하세요. 정책 그룹이 표시되고 노드 테스트가 가능한지 확인한 뒤 시작을 누르세요. 처음 실행하면 시스템 VPN 권한 대화상자가 표시될 수 있습니다. 권한을 허용하면 앱이 로컬 트래픽 처리용 연결을 만들 수 있지만, 원격 노드의 신뢰성을 시스템이 확인했다거나 모든 앱 요청이 프록시 아웃바운드를 거친다는 뜻은 아닙니다.

Android에서는 일반적으로 같은 사용자 프로필에서 활성 VPN 서비스를 하나만 사용할 수 있습니다. 다른 VPN, 방화벽, 로컬 VPN 기반 필터링 도구가 충돌하면 연결이 대체되거나 시작 직후 끊기고 특정 앱의 네트워크가 차단될 수 있습니다. 테스트할 때는 충돌할 수 있는 프로그램을 끄고 트래픽 처리용 앱 하나만 실행하세요. 업무용 프로필과 개인 프로필에는 서로 다른 제한이 적용될 수 있으므로 실제 실행 중인 프로필을 각각 확인하세요.

모바일 기기의 VPN 트래픽 처리와 데스크톱의 시스템 프록시는 서로 다른 설정 방식입니다. 보통 Wi-Fi 설정에서 프록시를 따로 입력할 필요가 없습니다. 로컬 기기를 가리키는 Wi-Fi 프록시를 추가하면 경로를 추적하기 어려워질 수 있습니다. 시스템에 VPN 연결됨으로 표시되어도 터널 서비스가 실행 중임을 보여줄 뿐입니다. 연결 로그에서 요청에 적용된 규칙, 정책 그룹, 실제 아웃바운드를 확인하세요.

앱별 분할 전에 목록의 의미 확인

앱별 분할을 켜기 전에 목록이 선택한 앱만 프록시하는 방식인지, 선택한 앱을 프록시에서 제외하는 방식인지 확인하세요. 같은 체크 상태라도 두 모드의 의미는 반대일 수 있습니다. 먼저 브라우저 하나로 테스트하고 기존 페이지를 닫은 다음 새 연결을 만들어 로그를 확인하세요. 목록을 바꾼 뒤 적용하려면 VPN을 다시 연결해야 하는 클라이언트도 있습니다. 체크 표시만 보고 시스템의 처리 범위가 바뀌었다고 판단하지 마세요.

앱 목록은 어떤 트래픽이 클라이언트로 들어오는지 결정하고, 규칙은 들어온 트래픽이 어떤 정책을 따를지 결정합니다. 두 단계는 서로 대체할 수 없습니다. 제외된 앱의 트래픽은 보통 코어 규칙 평가를 거치지 않으며, 포함된 앱도 규칙에 따라 직접 연결될 수 있습니다. 특정 앱이 프록시를 사용하는지 확인하려면 처리 대상 목록, 일치한 규칙, 최종 아웃바운드를 모두 확인하세요. 기본 화면의 연결 버튼만 보지 마세요.

백그라운드 실행, 배터리, 네트워크 전환 문제

화면이 켜져 있을 때는 정상인데 잠금 후 연결이 끊기면 시스템의 백그라운드 실행, 배터리 사용, 자동 시작 제한부터 확인하세요. 기기 제조사의 설정에서 클라이언트에 필요한 백그라운드 권한을 허용하되 배터리 소모가 늘 수 있다는 점을 고려하세요. 백그라운드 알림은 서비스 실행 여부를 확인하는 데 도움이 되므로 알림을 숨기려고 시스템 요구사항을 무시하지 마세요. 기기를 재시작한 뒤에는 화면만 복원된 것이 아니라 연결도 실제로 다시 설정됐는지 확인하세요.

Wi-Fi에서 모바일 데이터로 전환하면 기존 연결이 끊기고 앱이 요청을 다시 보내야 할 수 있습니다. 모바일 데이터 사용 권한과 새 네트워크에서 현재 노드에 연결할 수 있는지 확인한 다음 VPN이 여전히 활성 상태인지 확인하세요. 항상 켜져 있는 VPN 또는 VPN 없이 연결 차단을 설정한 경우 클라이언트가 끊기면 시스템 정책에 따라 네트워크가 차단될 수 있습니다. 이는 보호 기능이므로 의도에 맞게 설정하세요.

구독 업데이트에 실패하면 휴대폰 시간, 구독 유효성, 현재 네트워크, 저장 공간을 확인하세요. 업데이트만 실패하고 기존 노드는 연결되는지도 확인하세요. 특정 앱만 이상하다면 클라이언트 데이터를 모두 지우지 말고 앱별 분할 설정, 별도 DNS, UDP 사용 여부, 앱 캐시를 점검하세요. 조치를 마친 뒤 해당 앱을 다시 실행해 새 연결을 만들어야 변경 사항이 새 요청에 적용됐는지 확인할 수 있습니다.

iOS: 앱 설치, 설정 가져오기, VPN 연결 확인

클라이언트 설치 및 구독 형식 확인

iPhone과 iPad에서는 Clash Plus를 우선 사용하세요. 이 사이트의 iOS 클라이언트 안내를 확인하거나 Clash Plus App Store 페이지를 바로 열 수 있습니다. 클라이언트 공식 웹사이트는 clashplus.io입니다. 설치 전에 앱 스토어에 표시된 시스템 호환성, 기능 설명, 권한 안내를 확인하고 데스크톱 메뉴 경로를 모바일에 그대로 적용하지 마세요.

iOS의 네트워크 트래픽 처리는 시스템에서 제공하는 네트워크 확장 기능을 사용하며, 데스크톱용 mihomo 실행 파일을 설치하는 방식이 아닙니다. 규칙, 구독 형식, 확장 필드의 지원 여부는 클라이언트 구현에 따라 달라집니다. 데스크톱에서 불러올 수 있는 설정이라도 모든 필드가 모바일에서 똑같이 작동한다고 볼 수 없습니다. 옮기기 전에 필요한 노드 프로토콜, 규칙 유형, DNS 기능을 지원하는지 확인하세요.

구독 제공처에서 특정 클라이언트용 링크를 제공한다면 해당 클라이언트에 맞는 링크를 우선 사용하세요. 관리 웹페이지, QR 코드, 공유 버튼만 제공되는 경우에는 연결된 주소가 설정 내용인지 계정 페이지인지 구분해야 합니다. QR 코드는 주소를 전달하는 수단일 뿐 설정 형식을 자동 변환하지 않습니다. 가져온 뒤 설정 목록, 정책 그룹, 노드 내용을 확인하세요. 새 설정 이름이 목록에 표시되는 것만으로 가져오기가 완료됐다고 판단하지 마세요.

원격 구독과 로컬 파일을 구분해 관리

원격 구독은 보통 설정 페이지에서 링크를 추가한 뒤 저장하고, 다운로드와 파싱이 끝나면 현재 설정으로 선택합니다. 로컬 파일은 클라이언트에서 지원하는 파일 가져오기 또는 시스템 공유 메뉴를 통해 엽니다. 파일 가져오기는 그 시점의 내용만 복사하며 이후 업데이트가 연결되지 않을 수 있습니다. 노드를 계속 업데이트해야 한다면 같은 이름의 파일을 반복해서 가져오는 대신 클라이언트에 원격 출처가 등록됐는지 확인하세요.

파일 앱에서는 파일이 보이는데 가져올 수 없다면 실제 설정 텍스트인지, 클라우드에서 아직 다운로드되지 않았는지, 대상 클라이언트가 해당 형식을 지원하는지 확인하세요. 이메일 첨부나 웹 다운로드 파일은 압축 파일, 오류 페이지, 다른 형식의 문서일 수 있습니다. 확장자만 바꿔 해결하려 하지 마세요. 구독 제공처에서 올바른 내용을 다시 받은 뒤 가져오기 오류 메시지를 확인하세요.

가져온 뒤 연결을 시작하기 전에 정책 그룹에서 노드 하나를 선택해 테스트하세요. 자동 정책 그룹의 테스트 대상과 실제 서비스 요청 대상은 다를 수 있습니다. 테스트는 성공했지만 특정 앱이 실패하면 노드를 계속 바꾸지 말고 해당 앱의 연결 기록과 규칙을 확인하세요. 노드를 하나로 고정하면 비교 기준을 만들기 쉽습니다. 검증을 마친 뒤 일상적으로 사용할 정책으로 되돌리세요.

VPN 권한과 시스템 트래픽 처리 범위 이해

처음 실행할 때 시스템에서 VPN 구성을 추가하고 기기 인증을 요구할 수 있습니다. 요청을 보낸 앱이 방금 설치한 클라이언트인지 확인한 뒤 권한을 허용하세요. 권한 허용과 연결 성공은 별개의 단계입니다. 시스템에 다른 VPN 구성이 이미 있다면 현재 어떤 VPN이 활성 상태인지 확인하세요. 연결 버튼이 켜진 뒤에도 실제 요청을 보내 클라이언트에 해당 연결 기록이 남는지 확인해야 합니다.

iOS에서 데스크톱 시스템 프록시 설정 방식을 그대로 따라 하지 마세요. 명확한 LAN 프록시 테스트를 하는 경우가 아니라면 Wi-Fi의 수동 프록시 설정을 추가로 바꿀 필요가 없습니다. 규칙 모드에서는 요청마다 직접 연결 또는 프록시를 선택할 수 있으므로 VPN 아이콘이 표시돼도 모든 대상이 같은 프록시 노드를 사용한다는 뜻은 아닙니다. 앱 자체의 네트워크 구현에 따라 로그에서 확인할 수 있는 도메인과 프로토콜도 달라질 수 있습니다.

시스템 관리 정책이 적용된 기기에는 앱별 VPN, 관리 네트워크, 접근 제한이 설정될 수 있습니다. 일반 개인용 클라이언트는 이러한 정책을 임의로 덮어쓸 수 없습니다. 특정 업무용 앱이 계속 다른 경로를 사용한다면 먼저 기기 관리 범위를 확인하고 해당 관리자에게 문의하세요. 프록시 동작을 통일하려고 조직의 설정을 삭제하지 마세요. 업무 계정이나 보안 정책에 영향을 줄 수 있습니다.

잠금 해제 후 연결 복구 및 앱별 문제

잠금을 해제하고 앱으로 돌아온 뒤에는 네트워크가 복구될 때까지 기다린 다음 새 요청을 보내세요. 기존 연결이 시간 초과됐다고 네트워크 확장 기능이 종료된 것은 아닙니다. 메인 화면을 계속 앞에 띄워 둘 필요도 없습니다. Wi-Fi와 셀룰러 네트워크를 자주 전환한다면 문제가 발생한 네트워크 유형, 현재 정책, VPN 상태를 기록해 각각 다시 테스트하세요. 조건을 한 번에 하나씩 바꾸면 네트워크 전환 문제를 구독 오류로 오해하지 않을 수 있습니다.

브라우저나 특정 앱에서만 문제가 생기면 앱에 이전 연결이 남아 있는지, 별도 DNS 확인 방식을 쓰는지, 직접 연결 규칙이 적용됐는지 확인하세요. 대상 앱을 정상 종료한 뒤 다시 열어 새 연결을 확인해도 됩니다. 시스템 네트워크 설정 전체를 초기화하는 것부터 시작하지 마세요. 다른 네트워크 정보까지 영향을 받지만 원격 노드, 규칙 참조, 설정 형식 오류는 해결되지 않을 수 있습니다.

클라이언트를 업데이트하거나 삭제하기 전에 구독 출처와 사용자 지정 규칙을 저장하세요. 기기 백업을 복원한 뒤에도 현재 설정과 VPN 권한을 다시 확인하세요. 캐시, 구독, 시스템 권한이 모두 같은 상태로 복원된다고 가정하지 마세요. 전체 설치 및 가져오기 순서는 iPhone 클라이언트 설치 및 설정 가져오기 안내를 참고하세요. 설정이 적용됐는지는 실제 연결 로그와 대상에 접속한 결과로 확인해야 합니다.

Linux: 데스크톱 클라이언트 및 mihomo 서비스 설치

데스크톱과 서버 중 사용 환경 선택

데스크톱 환경은 Linux 다운로드에서 Clash Verge Rev 또는 FlClash를 선택하고 배포판과 다운로드 페이지에 맞는 형식으로 설치하세요. 서버, 라우터 또는 프로세스를 세밀하게 관리해야 하는 환경에서는 mihomo 코어를 사용할 수 있습니다. 바이너리를 선택할 때 프로세서 아키텍처, 배포판 환경, 필요한 명령어 세트를 함께 확인하세요. 파일 압축이 풀린다고 현재 기기에서 사용할 수 있다는 뜻은 아닙니다.

데스크톱 클라이언트에서 구독을 가져오고 설정과 정책을 선택하는 과정은 다른 데스크톱 플랫폼과 비슷하지만 시스템 프록시 설정은 데스크톱 환경에 따라 달라집니다. 브라우저, 터미널, 컨테이너, 백그라운드 서비스가 서로 다른 설정을 참조할 수 있으므로 데스크톱의 프록시 스위치가 시스템 전체의 라우팅을 바꾼다고 생각하면 안 됩니다. 첫 테스트에서는 프록시를 명시한 요청을 사용한 뒤 앱 환경 변수, 데스크톱 프록시, TUN 중 적절한 방식을 선택하세요.

네이티브 코어를 설치할 때는 압축을 풀고 신뢰할 수 있는 바이너리에 실행 권한을 부여한 뒤 사용할 위치에 둡니다. 아래 예시에서는 실행 파일을 /usr/local/bin/mihomo에 설치하고 설정 파일은 현재 사용자 디렉터리에 둡니다. 기본 프록시를 먼저 일반 사용자 권한으로 실행하세요. 처음부터 루트 권한을 사용하지 마세요. 설정 파일과 참조하는 로컬 규칙 파일은 실행 사용자가 읽을 수 있어야 하며 캐시를 기록하는 디렉터리에는 쓰기 권한도 필요합니다.

mkdir -p ~/.config/mihomo
/usr/local/bin/mihomo -t -d ~/.config/mihomo
/usr/local/bin/mihomo -d ~/.config/mihomo

구독 내용을 셸 명령으로 실행하지 마세요

네이티브 코어에는 GUI 클라이언트의 구독 관리 화면이 없습니다. 전체 설정은 작업 디렉터리의 config.yaml로 저장하세요. 노드 목록만 있다면 정책 그룹, 규칙, 기타 필수 항목을 직접 보완하거나 클라이언트에서 관리해야 합니다. 신뢰할 수 있는 경로로 다운로드한 뒤 파일 내용과 문법을 확인하세요. 원격 응답을 셸에 직접 전달해 실행하지 말고 명령 기록에 민감한 구독 링크가 남지 않도록 하세요.

자동 업데이트는 임시 파일을 먼저 다운로드해 성공 여부를 확인한 다음 교체하고, 이전에 사용할 수 있었던 설정도 보관하세요. 코어 설정 검사를 통과한 뒤 제어된 방식으로 다시 불러오거나 재시작하세요. 원격 응답으로 활성 파일을 바로 덮어쓰면 네트워크 오류 시 오류 페이지가 설정 파일로 저장될 수 있습니다. 원격 노드 제공자를 사용한다면 제공자 이름, 캐시 경로, 업데이트 간격, 참조하는 정책 그룹도 서로 일치하는지 확인하세요.

시작한 뒤 로그를 확인하고 로컬 혼합 포트로 요청을 보내세요. 다른 LAN 기기에서 프록시를 사용해야 할 때만 리스닝 주소, 방화벽, 접근 제어를 조정하세요. 프록시 포트나 컨트롤 인터페이스를 모든 네트워크에 기본 공개하지 마세요. 원격 서버에서는 로컬 루프백, 사설 네트워크 주소, 공인 주소를 구분하세요. 테스트에 편리한 설정이 장기간 공개된 접속 지점으로 남지 않도록 해야 합니다.

사용자 서비스로 프로세스 관리

systemd 사용자 서비스를 지원하는 배포판에서는 상위 디렉터리를 먼저 만든 다음 아래 내용을 ~/.config/systemd/user/mihomo.service로 저장할 수 있습니다. 이 서비스는 앞서 설명한 설치 경로와 일반 프록시 리스닝을 전제로 하며 TUN에 필요한 추가 권한을 부여하지 않습니다. 서비스는 코어 실행만 담당하도록 하세요. 구독 업데이트와 권한 설정은 별도로 설계해 모든 유지 관리 작업을 시작 명령에 넣지 마세요.

[Unit]
Description=Mihomo user proxy

[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d %h/.config/mihomo
Restart=on-failure
RestartSec=5

[Install]
WantedBy=default.target

systemctl --user daemon-reload
systemctl --user enable --now mihomo.service
systemctl --user status mihomo.service
journalctl --user -u mihomo.service -n 80 --no-pager

사용자 서비스는 일반적으로 사용자 세션에 연결되어 실행되며 로그아웃 뒤에도 계속 실행되는지는 시스템의 사용자 관리 설정에 따라 달라집니다. 상시 실행이 필요한 서버라면 배포 정책에 맞는 시스템 서비스나 사용자 세션 유지 방식을 선택하세요. 서비스를 활성화했다고 부팅 후에도 영구 실행되는 것은 아닙니다. 설정을 수정한 뒤에는 먼저 검사하고 재시작한 다음 서비스 상태와 최근 로그를 확인하세요. 시작 명령에서 오류가 나오지 않았다는 이유만으로 설치가 성공했다고 판단하지 마세요.

TUN, DNS, 컨테이너의 적용 범위

Linux에서 TUN을 사용하려면 가상 네트워크 장치와 관련 네트워크 관리 권한이 필요합니다. 일반 사용자 서비스가 이 권한을 자동으로 얻는 것은 아닙니다. 활성화 전에 클라이언트나 서비스가 권한을 얻고 라우트를 설정한 뒤 종료 시 상태를 복구하는 방식을 확인하세요. 아래는 일반적인 설정 항목일 뿐이며 기존에 작동하는 설정에 병합해야 합니다. 노드를 제공하지 않고 호스트 권한 준비를 대신하지도 않으므로 전체 설정 파일을 그대로 덮어쓰지 마세요.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

DNS를 확인할 때는 시스템 확인자, 코어 DNS, 앱 자체의 암호화 DNS를 구분하세요. systemd-resolved를 사용하는 기기에서는 로컬 스텁 확인자와 리스닝 주소의 충돌도 확인해야 합니다. 컨테이너는 독립 네트워크 네임스페이스를 사용하므로 컨테이너의 루프백 주소가 호스트를 가리키지 않습니다. 호스트 프록시가 작동해도 컨테이너에는 별도의 접속 경로, 프록시 환경 변수, 라우팅 설정이 필요할 수 있습니다.

서비스를 중지하거나 설정을 되돌린 뒤 관련 라우트, DNS 설정, 환경 변수가 의도한 상태로 복구됐는지 확인하세요. 연결 문제는 프록시를 명시한 요청과 TUN의 결과를 비교한 다음 인터페이스와 방화벽을 점검하세요. 규칙을 먼저 전부 초기화하지 마세요. 원격으로 관리할 때는 별도의 관리 연결을 유지하세요. 라우팅을 한 번 바꿨다가 현재 세션이 끊기면 로그를 확인하고 되돌릴 수 없습니다.

설정 관련 자주 묻는 질문: 요청 경로별 진단

구독 업데이트 실패와 설정 로드 실패

먼저 다운로드 실패, 응답 내용 오류, 설정 파싱 실패를 구분하세요. 다운로드 실패는 네트워크, 주소, 계정 상태, 인증서, 기기 시간부터 확인해야 합니다. 응답은 성공했지만 웹페이지가 반환된다면 링크가 여전히 구독 인터페이스를 가리키는지 확인하세요. 파싱 실패라면 YAML 위치, 필드 유형, 코어 호환성을 점검하세요. 오류 유형마다 해결 방법이 다르므로 업데이트 버튼을 계속 눌러도 누락된 설정 항목은 보완되지 않습니다.

기존 설정으로 연결할 수 있지만 업데이트만 되지 않는다면 현재 상태를 유지하면서 구독을 가져오는 경로를 따로 점검하세요. 구독 도메인은 직접 연결이 필요할 수도 있고 현재 네트워크에서 차단됐을 수도 있습니다. 아직 불러오지 못한 정책 그룹에 업데이트 요청을 의존시켜 순환 문제가 생기지 않도록 하세요. 업데이트에 사용할 프록시 방식을 변경하기 전에 기존 설정을 기록하고, 성공한 뒤 로컬 규칙과 정책 그룹 선택이 잘못 덮어써지지 않았는지 확인하세요.

규칙 세트나 지리 데이터베이스 오류가 발생하면 모든 규칙을 먼저 삭제하지 말고 참조 이름, 다운로드 위치, 관련 로그를 확인하세요. GEOIP는 IP 데이터에, GEOSITE는 도메인 데이터 또는 해당 설정 지원에 의존합니다. 리소스가 없는 문제와 규칙 적용 결과가 예상과 다른 문제는 서로 다릅니다. 리소스를 업데이트한 뒤 대상에 새로 연결하고 실제로 일치한 기록을 확인하세요. 기존 연결은 새 규칙을 검증하는 신뢰할 만한 기준이 아닙니다.

규칙 순서, 정책 참조, DNS

규칙은 위에서 아래로 평가되며 가장 먼저 일치한 항목이 정책을 결정합니다. 구체적인 도메인 규칙을 범위가 넓은 규칙보다 위에 두고 기본 규칙은 마지막에 배치하세요. 아래 예시의 PROXY는 proxy-groups에 이미 정의되어 있어야 하며 GEOIP에는 사용 가능한 데이터베이스가 필요합니다. 이 코드는 규칙 예시일 뿐 완전하게 연결할 수 있는 설정이 아닙니다. 구독의 이름이 다르면 참조도 함께 수정해야 하며, 오류를 무시한 채 그대로 붙여 넣지 마세요.

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

규칙 모드, 글로벌 모드, 직접 연결 모드에 따라 정책을 평가하는 경로가 달라집니다. 문제를 해결할 때 현재 모드를 먼저 확인하세요. rules를 수정해도 글로벌 모드라면 변경 내용이 적용되지 않습니다. 자동 테스트 그룹, 장애 조치 그룹, 수동 선택 그룹은 의사 결정 조건도 다릅니다. 그룹 이름만으로 실제 동작을 알 수는 없습니다. 중국 본토와 해외 트래픽을 분리하는 자세한 규칙은 mihomo 규칙 분기 실전 가이드를 참고하세요.

fake-ip는 합성 주소와 매핑 기록으로 도메인을 연결하므로 테스트용 대역 주소가 보인다고 바로 DNS 오염으로 판단할 필요는 없습니다. 앱이 이전 매핑을 캐시하거나 코어를 우회해 DNS를 조회하거나 암호화 DNS를 직접 사용하면 규칙에서 확인할 수 있는 정보가 달라질 수 있습니다. 먼저 DNS 조회 경로를 확인하고 클라이언트에서 지원하는 방법으로 관련 캐시를 새로 고치세요. 근본 원인을 숨기려고 모든 도메인을 필터 목록에 넣지 마세요. 도메인 분기의 동작을 이해하기 어려워질 수 있습니다.

노드 테스트는 성공하지만 대상에 접속할 수 없는 경우

지연 시간 테스트는 특정 대상과 프로토콜을 사용하므로 성공은 해당 테스트가 완료됐다는 뜻일 뿐입니다. 실제 웹사이트는 대상 서버의 제한을 받거나 다른 포트, UDP, 지역 조건을 요구할 수 있습니다. 노드를 하나로 고정하고 브라우저나 명령줄에서 같은 대상에 접속한 뒤 연결 로그를 확인하세요. 실패한 요청이 코어에 들어왔는지, 어떤 규칙에 일치했는지, 최종적으로 어떤 아웃바운드를 선택했는지 비교하면 테스트 주소를 계속 바꾸는 것보다 원인을 찾기 쉽습니다.

브라우저는 되지만 터미널이 실패한다면 프록시를 명시해 테스트하세요. 터미널은 되지만 브라우저가 실패한다면 브라우저 확장 프로그램, 별도 프록시 설정, 캐시를 확인하세요. 모든 앱에서 실패할 때는 코어 리스닝, 노드 연결, DNS를 점검하세요. TUN만 실패한다면 권한, 인터페이스, 라우팅을 우선 확인하세요. 첫 연결을 검증하는 자세한 순서는 노드 선택 및 프록시 적용 확인을 참고하세요.

유효한 증거와 복구 경로 유지

문제를 기록할 때 운영체제 종류, 클라이언트 이름, 활성 설정, 트래픽 처리 방식, 실패한 대상, 재현 단계를 적고 최근 변경 사항도 표시하세요. 필요한 경우 로그 수준을 잠시 높여 문제를 재현한 뒤 원래대로 돌리세요. 민감한 정보가 장기간 쌓이지 않도록 주의해야 합니다. 재설치로 원격 구독, 대상 서비스, 잘못된 규칙 문제가 해결되는 경우는 드뭅니다. 요청 경로를 따라 범위를 먼저 좁히고 변경 사항이 효과가 있는지 확인한 뒤 새 설정 기준으로 저장하세요.