Clash Meta for Android 인터페이스 한눈에 보기: 프록시·구성·오버라이드·로그 기능 안내

먼저 클라이언트의 작업 구조부터 파악하기

Clash Meta for Android는 일반적으로 그래픽 인터페이스, mihomo 코어, 구성 파일의 세 부분으로 구성됩니다. 그래픽 인터페이스는 구독 가져오기, 정책 선택, 상태 확인을 담당하고, mihomo 코어는 DNS 확인, 규칙 매칭, 연결 전달을 수행합니다. 구성 파일에는 프록시 노드, 정책 그룹, 규칙, 실행 매개변수가 저장됩니다. 화면에서 한 번 클릭한 동작도 결국 코어 상태나 구성 내용의 변경으로 변환됩니다.

이 글은 일반적인 Clash Meta for Android 2.11.x 인터페이스를 기준으로 설명합니다. 빌드 버전에 따라 오버라이드가 구성 화면 오른쪽 상단, 사이드바 또는 설정 내부에 배치될 수 있으며, 로그와 연결이 별도 메뉴로 나뉘기도 합니다. 다만 각 영역의 역할은 대체로 같습니다. 처음 설치한 뒤에는 「구성 → 프록시 → 홈에서 시작 → 로그 확인」 순서로 진행하는 것이 좋습니다.

주요 다섯 영역의 역할

영역	주요 용도	자주 하는 작업
홈	서비스 상태와 실행 모드 확인	시작·중지, 규칙 모드 전환, 트래픽 확인
프록시	정책 그룹과 노드 관리	노드 선택, 지연 시간 테스트, 정책 그룹 펼치기
구성	구독과 로컬 YAML 관리	구성 가져오기·업데이트·전환·삭제
오버라이드	기기에서 일부 구성 매개변수 조정	DNS, 포트, 라우팅 및 TUN 관련 설정 변경
로그	코어 실행 기록 확인	DNS, 규칙 매칭, 연결 및 구성 오류 파악

홈: 코어 시작 및 모드·실행 상태 확인

홈은 실행을 제어하는 영역입니다. 구성을 가져와 선택한 다음 시작 버튼을 누르면 Android에서 VPN 연결 생성 권한을 요청합니다. 시스템 상태 표시줄에 열쇠 또는 VPN 아이콘이 나타나는 것은 기기의 VPN 인터페이스가 만들어졌다는 뜻일 뿐입니다. 실제로 원하는 웹사이트에 접속할 수 있는지는 노드 상태, 정책 그룹 선택, DNS, 규칙 매칭 결과에 따라 달라집니다.

시작 전 확인할 세 가지 상태

현재 구성: 홈에 표시된 구성 이름이 방금 가져온 구독과 일치하는지 확인해 이전 구성을 계속 사용하는 일을 방지합니다.
실행 모드: 일반적으로 「규칙」 또는 「Rule」을 선택해 규칙에 따라 직접 연결과 프록시 연결을 나눕니다. 전역 모드는 대부분의 연결을 지정된 정책으로 보내고, 직접 연결 모드는 프록시를 우회합니다.
VPN 권한: 처음 시작할 때 시스템의 VPN 요청을 허용합니다. Android VPN 인터페이스는 한 번에 하나의 앱만 사용할 수 있습니다.

일부 버전의 홈 화면에는 업로드 속도, 다운로드 속도, 누적 트래픽, 활성 연결 수가 표시됩니다. 속도 값은 코어를 통과하는 실시간 트래픽이며 노드의 최대 대역폭을 의미하지 않습니다. 화면에 2.4 MB/s가 표시된다면 현재 초당 약 2.4MB의 데이터가 통과한다는 뜻이지, 회선 속도가 그 수치로 제한된다는 의미는 아닙니다.

규칙·전역·직접 연결 모드

규칙 모드: 구성의 rules를 위에서부터 순서대로 매칭합니다. 업무용 사이트는 직접 연결하고 특정 도메인은 프록시 정책 그룹으로 보낼 수 있습니다.
전역 모드: 모든 연결을 전역 정책 그룹으로 보냅니다. 특정 노드가 작동하는지 임시로 확인할 때는 유용하지만, 세밀한 트래픽 분류를 장기간 대신하기에는 적합하지 않습니다.
직접 연결 모드: 연결이 대상 주소에 직접 접속합니다. 문제의 원인이 로컬 네트워크인지 프록시 경로인지 판단할 때 사용할 수 있습니다.

프록시: 정책 그룹·노드·지연 시간 결과 이해하기

프록시 화면은 단순한 서버 목록이 아닙니다. 화면 상단이나 그룹 카드에 표시되는 것은 정책 그룹이며, 그룹 안에 노드 또는 다른 정책 그룹이 들어 있습니다. 규칙 파일은 PROXY, Streaming, Final 같은 지정 그룹으로 연결을 전달합니다. 그룹 안에서 선택한 항목에 따라 해당 그룹이 연결을 처리할 때 사용할 경로가 결정됩니다.

자주 사용하는 정책 그룹 유형

화면 표시	구성 유형	동작
노드 하나를 직접 선택	`select`	구성이 업데이트되거나 다시 전환할 때까지 사용자의 선택 유지
자동으로 속도를 측정해 선택	`url-test`	테스트 URL과 설정된 주기에 따라 노드 평가
장애 발생 시 전환	`fallback`	목록에서 사용 가능한 첫 번째 노드를 우선 사용
연결 분산	`load-balance`	구성된 정책에 따라 여러 노드로 연결 분배

지연 시간 수치는 어떻게 봐야 할까

속도 측정 버튼을 누르면 클라이언트가 구성에 지정된 테스트 주소로 요청을 보냅니다. 자주 쓰이는 주소는 https://www.gstatic.com/generate_204이며, 정상 응답은 상태 코드만 반환하고 전체 웹페이지를 다운로드하지 않습니다. 86ms는 이번 탐색에 약 86밀리초가 걸렸다는 뜻이고, 시간 초과는 제한 시간 안에 요청을 완료하지 못했다는 의미입니다. 120ms와 135ms의 한 번씩 발생한 차이는 자주 전환할 이유가 되지 않습니다. 지속적인 시간 초과, 800ms 초과 또는 수백 밀리초 단위의 큰 변동이 있을 때 점검이 필요합니다.

속도 측정에 성공했다고 해서 모든 웹사이트에 접속할 수 있다는 뜻은 아닙니다. 테스트 주소, 대상 웹사이트, 노드의 출구가 서로 다른 경로를 사용할 수 있습니다. 먼저 노드를 선택한 뒤 로그 또는 연결 화면으로 돌아가 실제 대상 도메인이 어떤 규칙과 정책에 매칭됐는지 확인하는 것이 올바른 방법입니다.

노드 전환 표준 절차

「프록시」로 이동해 규칙에서 실제로 참조하는 정책 그룹(예: PROXY)을 찾습니다.
그룹 내에서 한 번 지연 시간을 측정해 지속적으로 시간 초과되는 노드를 제외합니다.
지연 시간이 안정적인 노드를 선택하고 선택 표시가 해당 항목으로 이동했는지 확인합니다.
홈으로 돌아가 서비스를 계속 실행한 뒤 대상 앱을 다시 엽니다.
앱이 이전 연결을 재사용한다면 앱을 강제 종료한 다음 다시 테스트합니다.

구성: 구독 가져오기·업데이트·전환

구성 화면에는 원격 구독과 로컬 파일이 저장됩니다. 원격 구독은 보통 URL에서 YAML 내용을 가져오며, 업데이트하면 프록시 노드, 정책 그룹, 규칙을 다시 다운로드합니다. 로컬 구성은 기기에 저장된 파일을 직접 읽습니다. 출처와 관계없이 한 번에 하나의 활성 구성을 명확히 선택해야 합니다.

구독 링크로 가져오기

「구성」 화면을 열고 추가 버튼을 누릅니다.
「URL」 또는 「링크에서 가져오기」를 선택합니다.
식별하기 쉬운 이름을 입력한 뒤 전체 구독 주소를 붙여 넣습니다.
저장하고 다운로드가 완료될 때까지 기다린 다음 구성 항목에 오류 표시가 없는지 확인합니다.
해당 구성을 눌러 현재 활성 구성으로 설정합니다.
홈으로 돌아가 서비스를 시작한 뒤 프록시 화면에서 정책을 선택합니다.

구독 업데이트와 구성 전환은 서로 다른 작업입니다. 업데이트는 해당 구독의 로컬 저장 내용을 바꾸고, 전환은 코어가 다음에 불러올 내용을 결정합니다. 업데이트 후에도 프록시 화면에 이전 노드가 표시된다면 먼저 활성 구성을 확인한 다음 코어를 중지하고 다시 시작해 보세요.

구성 목록에서 자주 사용하는 작업

업데이트: 구독 주소에 다시 요청합니다. 구독이 만료되었거나 인증에 실패했거나 네트워크에 연결할 수 없으면 HTTP 오류가 발생할 수 있습니다.
편집: 구성 이름, 구독 URL 또는 자동 업데이트 주기를 수정합니다. 편집 가능한 항목은 클라이언트 버전에 따라 다릅니다.
전환: 선택한 항목을 활성 구성으로 설정합니다. 전환 후에는 홈에 표시되는 구성 이름을 확인하는 것이 좋습니다.
삭제: 로컬에 저장된 항목을 제거합니다. 현재 구성을 삭제하기 전 다른 사용 가능한 구성으로 먼저 전환해야 합니다.

자동 업데이트 주기 설정 방법

노드 변경이 적다면 업데이트 주기를 1440분, 즉 하루 한 번으로 설정할 수 있습니다. 자주 업데이트해도 회선 속도가 빨라지지는 않으며, 구독 서비스에 일시적으로 연결할 수 없을 때 잘못 판단하게 만들 수 있습니다. 구성 제공자가 노드 변경을 알렸다면 「구성」→「현재 구독」→「업데이트」에서 수동으로 새로 고치면 됩니다.

오버라이드: 구독을 직접 수정하지 않고 로컬 매개변수 조정

오버라이드는 기기에서 구성을 불러올 때 매개변수를 추가 적용하는 기능입니다. 포트, DNS, IPv6, 라우팅 인터페이스 또는 TUN 옵션을 수정할 때 유용하며, 구독을 업데이트할 때마다 원본 YAML을 다시 편집하지 않아도 됩니다. 오버라이드 필드 지원 범위는 버전에 따라 다르므로 활성화하기 전에 해당 항목의 설명을 확인하고, 한 번에 하나의 매개변수 그룹만 변경하세요.

자주 사용하는 구성 필드

mixed-port: 7890
mode: rule
log-level: info
ipv6: false
external-controller: 127.0.0.1:9090

mixed-port: 7890: HTTP와 SOCKS 프록시가 7890 포트를 함께 사용하도록 합니다. Android에서는 대부분의 트래픽을 VPN 인터페이스가 처리하지만, LAN 도구나 수동 프록시는 이 포트를 사용할 수 있습니다.
mode: rule: 기본 실행 모드를 규칙 모드로 설정합니다. 화면에서 실행 모드를 임시로 바꾸면 실제 상태가 이 초기값을 덮어쓸 수 있습니다.
log-level: info: 일반 실행 정보를 기록합니다. 복잡한 문제를 점검할 때는 잠시 debug로 바꿀 수 있으며, 완료 후 로그 양을 줄이기 위해 원래대로 되돌리는 것이 좋습니다.
ipv6: false: 코어의 IPv6 처리를 비활성화합니다. 현재 네트워크와 구독이 모두 IPv6를 제대로 지원할 때만 DNS 설정과 함께 활성화해야 합니다.
external-controller: 코어 제어 인터페이스입니다. 127.0.0.1에 바인딩하면 로컬 기기에서만 접근할 수 있으며, 9090은 자주 사용되는 제어 포트입니다.

오버라이드 안전 적용 순서

「구성」 화면에서 원본 구독이 정상적으로 시작되는지 확인합니다.
「설정」→「오버라이드」로 이동해 테스트할 항목 하나만 활성화합니다.
서비스를 중지한 뒤 다시 시작해 코어가 구성을 새로 불러오도록 합니다.
로그에서 필드 유형, 포트 충돌 또는 DNS 초기화 오류가 발생했는지 확인합니다.
테스트가 끝나면 유효한 설정을 기록하고 더 이상 사용하지 않는 오버라이드 항목을 삭제합니다.

오버라이드를 활성화한 직후 클라이언트가 중지된다면 구독을 삭제하지 말고 방금 추가한 오버라이드를 먼저 끄세요. YAML 들여쓰기 오류, 필드 유형 오류, 이미 사용 중인 포트, 현재 코어 버전에서 지원하지 않는 이전 필드 등이 흔한 원인입니다. 예를 들어 포트는 숫자인 7890으로 작성해야 하며 설명 문구가 포함된 값으로 입력하면 안 됩니다.

로그: 연결 기록으로 문제 찾기

로그는 코어의 실제 동작을 확인하는 진입점입니다. 홈에 실행 중이라고 표시되는데 웹페이지가 열리지 않는다면 스위치만 반복해서 전환하지 마세요. 「로그」로 이동해 대상 웹사이트에 다시 접속한 다음 시간, 수준, 도메인, 규칙, 아웃바운드 정책을 기준으로 최근 기록을 확인하면 DNS, 규칙, 노드 문제를 빠르게 구분할 수 있습니다.

로그 수준의 의미

Info: 정상 시작, 연결 수립, 규칙 매칭 등 일반적인 기록입니다. 일상적인 점검에서는 우선 이 수준을 확인하세요.
Warning: 요청 재시도, 일부 기능 저하 또는 치명적이지 않은 구성 문제를 뜻합니다. 서비스는 계속 실행될 수 있습니다.
Error: 구성 로드 실패, DNS 요청 실패, 노드 연결 실패처럼 처리가 필요한 오류입니다.
Debug: 내부 처리 과정을 더 자세히 기록합니다. 짧은 시간 동안 문제를 재현할 때 적합하지만 기록량이 크게 늘어납니다.

연결 기록에서 확인할 필드

TCP 192.168.0.2:53142 → example.com:443
match DomainSuffix(example.com)
using PROXY[Node-A]

이 기록은 TCP 연결이 대상 도메인의 443 포트에 접속하고 도메인 접미사 규칙에 매칭된 뒤 PROXY 정책 그룹의 Node-A로 전달되었음을 나타냅니다. 프록시를 사용해야 하는데 DIRECT로 표시된다면 규칙 순서를 확인하세요. 정책은 올바르지만 연결 시간 초과가 발생한다면 노드나 회선을 테스트해야 합니다. 로그에 도메인 없이 IP만 표시된다면 DNS와 스니핑 설정을 계속 점검해야 합니다.

자주 발생하는 네 가지 오류의 점검 방향

로그 현상	우선 확인할 항목
`authentication failed`	노드 인증 정보, 구독 업데이트 여부, 시스템 시간이 정확한지 확인
`i/o timeout`	노드 연결 가능 여부, 로컬 네트워크, 방화벽, 회선 혼잡 확인
`no such host`	DNS 서버, 네트워크 권한, 도메인 확인 구성 확인
`address already in use`	7890, 9090 등의 포트를 다른 프로세스가 사용 중인지 확인

문제를 점검할 때는 먼저 로그를 지우거나 자동 스크롤을 일시 중지하고 현재 시간을 기록한 다음 문제를 한 번만 재현하세요. 이렇게 하면 수많은 백그라운드 연결 사이에서 대상 기록을 찾는 일을 줄일 수 있습니다. 로그에는 접속 도메인, LAN 주소, 노드 이름이 포함될 수 있으므로 화면을 공유하기 전 구독 주소, 인증 정보, 공개하지 않을 접속 기록을 가리세요.

설정 및 매개변수: DNS·TUN·앱별 트래픽 분류

설정 영역에서는 클라이언트 자체와 코어 실행 매개변수를 관리합니다. 일반적인 경로는 「설정」→「매개변수 설정」, 「설정」→「네트워크」, 「설정」→「앱별 트래픽 분류」입니다. 메뉴 이름은 버전에 따라 달라질 수 있지만 기능을 기준으로 찾을 수 있습니다.

TUN과 시스템 VPN 인터페이스

Android 클라이언트는 일반적으로 시스템 VPN API를 통해 가상 네트워크 인터페이스를 만들고 앱 트래픽을 mihomo 코어로 보냅니다. TUN을 활성화하면 TCP와 지원되는 UDP 트래픽을 같은 진입점에서 처리할 수 있습니다. 처음 시작할 때 VPN 권한을 허용해야 합니다. 다른 VPN, 네트워크 필터 또는 로컬 방화벽이 실행 중이라면 먼저 중지하세요. Android는 일반적으로 하나의 VPN 서비스만 활성 상태로 둘 수 있습니다.

DNS 설정에서 확인할 사항

현재 구성에서 DNS 기능이 활성화되어 있고 nameserver 주소에 현재 네트워크로 접근할 수 있는지 확인합니다.
fake-ip 모드에서는 도메인이 예약 주소 대역에 매핑된 뒤 코어가 도메인을 복원해 규칙을 매칭할 수 있습니다.
일부 LAN 기기, 은행 앱, 게임은 fake-ip과 잘 맞지 않을 수 있습니다. 필터 항목으로 제외할 수 있으며, 구체적인 항목은 로그를 바탕으로 결정해야 합니다.
도메인은 열리지 않지만 IP 주소로는 정상 접속된다면 모든 노드를 즉시 바꾸지 말고 먼저 로그에서 DNS 시간 초과를 확인하세요.

앱별 트래픽 분류 방법 두 가지

앱별 트래픽 분류는 패키지 이름에 따라 어떤 앱을 VPN에 포함할지 결정합니다. 허용 목록 모드는 선택한 앱만 처리하고, 차단 목록 모드는 선택한 앱을 제외합니다. 모드를 바꾼 뒤에는 대상 앱을 완전히 종료했다가 다시 열어야 합니다. 이전 연결이 전환 전 네트워크 경로를 계속 사용할 수 있기 때문입니다. 시스템 구성 요소, WebView, 대상 앱이 각각 요청을 보낼 수 있으므로 주 앱의 패키지 이름만 선택하면 로그인 페이지와 본문이 서로 다른 경로를 사용할 수 있습니다.

재사용 가능한 첫 설정 절차

인터페이스에 익숙해지면 초기 설정을 일정한 절차로 줄일 수 있습니다. 누락을 줄이고 휴대폰을 바꾸거나 다시 설치한 뒤에도 각 단계를 빠르게 확인하는 데 도움이 됩니다.

「구성」→「추가」→「URL」로 이동해 구독을 가져온 뒤 활성 구성으로 설정합니다.
구독을 한 번 업데이트해 다운로드 오류나 YAML 구문 분석 오류가 없는지 확인합니다.
「프록시」로 이동해 주요 정책 그룹의 지연 시간을 측정하고 사용 가능한 노드를 선택합니다.
홈으로 돌아가 실행 모드를 「규칙」으로 설정하고 시작을 누른 뒤 VPN 요청을 허용합니다.
대상 웹페이지를 하나 연 다음 로그 화면에서 도메인, 매칭된 규칙, 아웃바운드 정책을 확인합니다.
특정 앱을 우회해야 한다면 「설정」→「앱별 트래픽 분류」로 이동해 범위를 조정합니다.
기본 연결이 안정된 뒤에 DNS, TUN 또는 포트 오버라이드를 추가합니다.

연결 이상 시 계층별로 되돌려 점검하기

모든 노드가 시간 초과되는 경우: Wi-Fi와 모바일 네트워크를 전환해 구독 업데이트와 기본 네트워크를 확인합니다.
노드 하나만 실패하는 경우: 프록시 화면에서 같은 그룹의 다른 노드로 바꾸면 되며 전체 구성을 다시 만들 필요는 없습니다.
웹사이트 하나만 실패하는 경우: 해당 사이트의 규칙 매칭과 DNS 기록을 확인하고 잘못 직접 연결로 분류되었는지 점검합니다.
앱 하나만 실패하는 경우: 앱별 트래픽 분류, 이전 연결 캐시, IPv6, 시스템 절전 제한을 확인합니다.
오버라이드 활성화 후 실패하는 경우: 최근 추가한 오버라이드를 끄고 코어를 다시 시작한 뒤 로그 변화를 비교합니다.

인터페이스 조작의 핵심 관계는 다음과 같습니다. 구성 화면은 무엇을 불러올지 결정하고, 프록시 화면은 정책 그룹에서 현재 무엇을 사용할지 결정하며, 홈은 코어 실행 여부를 결정합니다. 오버라이드 화면은 로컬에서 무엇을 추가로 바꿀지 정하고, 로그 화면은 트래픽이 최종적으로 어디로 갔는지 검증합니다. 이 순서대로 진행하면 단순히 시작을 반복하거나 무작정 노드를 바꾸는 것보다 문제를 쉽게 찾을 수 있습니다.