Clash Meta 설정 용어집

별칭: Meta 코어

mihomo는 Clash의 확장과 발전을 이어 온 프록시 코어의 명칭으로, 설정을 읽고 로컬 포트를 열며 원격 연결을 수립하고 규칙을 매칭합니다. GUI 클라이언트는 구독 관리, 정책 전환과 로그 확인을 화면으로 제공하지만 실제 트래픽 처리는 여전히 코어가 담당합니다.

클라이언트마다 포함된 코어의 출시 시점이 다를 수 있어 같은 설정도 필드 호환성에 차이가 생길 수 있습니다. 알 수 없는 필드나 시작 실패가 발생하면 먼저 클라이언트가 사용하는 코어 유형과 업데이트 상태를 확인하세요.

관련 용어: mihomo, Meta 설정

Clash Meta는 처음에는 Clash를 기반으로 프로토콜, DNS와 트래픽 가로채기 기능을 확장한 코어 분기를 가리켰으며, 해당 코어를 중심으로 형성된 클라이언트 생태계를 뜻하기도 합니다. 현재 기술 문서에서 Meta 코어라는 표현은 문맥에 따라 구체적으로 mihomo를 가리키는지 확인해야 합니다.

Clash Meta는 특정 GUI 클라이언트 하나만을 가리키는 전용 명칭이 아닙니다. Windows, macOS, Android, iOS와 Linux 클라이언트는 서로 다른 화면을 사용할 수 있지만, 기본 설정 개념은 대체로 통합니다.

영문: Graphical User Interface Client

GUI 클라이언트는 프록시 코어에 그래픽 조작 계층을 제공하며, 구독 가져오기, 정책 그룹 선택, 프록시 모드 전환, 시스템 프록시 활성화와 로그 확인 등을 지원합니다. 설정 파일을 직접 편집할 필요를 줄여 주지만 설정 필드 자체의 의미를 바꾸지는 않습니다.

화면의 스위치는 최종적으로 코어 매개변수나 시스템 설정으로 변환됩니다. 클라이언트를 비교할 때는 버튼 이름만으로 기능이 같다고 판단하지 말고 화면 기능, 코어 버전, 플랫폼 지원과 설정 호환성을 각각 살펴봐야 합니다.

설정 키: mixed-port

Mixed Port는 HTTP와 SOCKS5 요청을 모두 받는 로컬 리스닝 포트입니다. 앱은 이 포트 하나에 연결하면 되며, 코어가 요청 유형에 따라 처리하므로 포트 설정 수를 줄이고 싶은 데스크톱 환경에 적합합니다.

원격 노드 포트와는 다른 개념입니다. Mixed Port는 로컬에서 앱 연결을 기다리고, 노드 포트는 원격 서비스에 연결할 때 사용됩니다. 로컬 포트를 다른 프로그램이 사용 중이면 코어가 리스닝을 시작하지 못하고 로그에 바인딩 실패를 기록할 수 있습니다.

관련 용어: 가상 네트워크 인터페이스, 라우팅 가로채기

TUN 모드는 가상 네트워크 인터페이스로 시스템 트래픽을 받은 뒤 코어가 규칙에 따라 출구를 결정하는 방식입니다. 시스템 프록시 설정을 읽지 않는 앱에도 적합하며, 일반 HTTP 프록시보다 넓은 범위의 연결을 처리할 수 있습니다.

TUN을 활성화하려면 보통 시스템 권한, 라우팅 테이블과 DNS 설정이 필요하며 일부 플랫폼에서는 서비스 구성 요소 설치도 요구됩니다. 인트라넷 접속 불가, 네트워크 끊김 또는 도메인 해석 이상이 발생하면 TUN 라우팅, 인터페이스 제외 항목과 DNS 동작 모드를 함께 확인하세요.

영문: Proxy Node

노드는 설정에서 정책 그룹이 선택할 수 있는 프록시 연결 항목으로, 일반적으로 이름, 서버 주소, 포트, 프로토콜 유형과 인증 정보를 포함합니다. 노드 이름은 화면에서 식별하기 위한 것이므로 실제 회선 품질이나 위치가 이름과 반드시 일치하는 것은 아닙니다.

노드가 목록에 표시된다는 것은 설정이 해석되었다는 뜻일 뿐, 연결 검증까지 성공했다는 의미는 아닙니다. 사용 가능 여부를 확인하려면 DNS, 핸드셰이크, 인증서, 인증 정보와 원격 서비스 상태도 점검해야 합니다.

관련 용어: 인증, 전송, 암호화

프록시 프로토콜은 클라이언트와 원격 서비스가 프록시 연결을 수립할 때 따르는 통신 규격입니다. 프로토콜마다 필요한 인증 필드, 암호화 방식과 전송 설정이 다르므로 서버 주소가 같아도 프로토콜 유형을 임의로 바꿀 수 없습니다.

구독 변환이나 수동 설정 편집 과정에서 핵심 필드 하나만 빠져도 핸드셰이크가 실패할 수 있습니다. 로그의 시간 초과, 인증 실패와 인증서 오류는 서로 다른 단계의 문제이므로 해당 프로토콜에 맞춰 하나씩 확인하세요.

약어: SS

Shadowsocks는 널리 쓰이는 암호화 프록시 프로토콜로, 설정에 보통 서버 주소, 포트, 비밀번호와 암호화 방식이 포함됩니다. 클라이언트와 서버가 같은 암호화 방식을 사용해야 하며 필드가 맞지 않으면 유효한 세션을 수립할 수 없습니다.

일부 설정에는 플러그인이나 전송 옵션도 포함되며, 이러한 확장 매개변수는 클라이언트 코어의 지원이 필요합니다. 가져온 뒤 노드를 사용할 수 없다면 변환 과정에서 구독의 플러그인 필드가 빠지지 않았는지 확인하세요.

일반적인 조합: Trojan + TLS

Trojan은 일반적으로 TLS 연결 위에서 프록시 통신을 전달하며, 설정의 핵심 항목은 서버 주소, 포트, 비밀번호, 서버 이름과 인증서 검증입니다. 서버 이름은 TLS 핸드셰이크에 사용되며 노드 표시 이름이나 연결 주소와 다를 수 있습니다.

인증서 오류를 단순히 노드 지연 문제로 분류해서는 안 됩니다. 시스템 시간, 서버 이름, 인증서 체인과 중간 네트워크 개입이 TLS 검증에 영향을 줄 수 있으므로 로그의 구체적인 오류를 함께 확인해야 합니다.

관련 전송: TCP, WebSocket, gRPC

VMess와 VLESS는 널리 쓰이는 두 프록시 프로토콜로, TCP, WebSocket, gRPC와 TLS 등의 전송 조합을 사용할 수 있습니다. 이름이 비슷해도 필드를 서로 바꿔 쓸 수 없으며 사용자 식별자, 암호화 옵션, 흐름 제어와 전송 설정을 각각 처리해야 합니다.

이 유형의 노드를 점검할 때는 먼저 프로토콜 본체를 확인한 다음 전송 계층 경로, 호스트 이름과 TLS 설정을 살펴보세요. 포트나 정책 그룹만 바꾸는 것으로는 필드 불일치로 인한 연결 실패를 해결하기 어렵습니다.

영문: Rule-based Routing

규칙 기반 라우팅은 도메인, 대상 IP, 출발지 IP, 프로세스 또는 외부 규칙 집합에 따라 연결 출구를 결정하는 과정입니다. 매칭된 연결은 프록시 정책 그룹으로 보내거나 직접 연결할 수 있으며, 설정에 따라 차단할 수도 있습니다.

라우팅 결과는 규칙 순서와 클라이언트가 실제로 확보한 정보에 따라 달라집니다. 도메인이 시스템 외부에서 이미 IP로 해석되면 일부 도메인 규칙에 필요한 조건이 부족할 수 있으므로 DNS 모드와 함께 확인해야 합니다.

화면에서 흔히 표시되는 항목: Rule

규칙 모드는 설정의 rules 목록을 위에서 아래로 검사하며, 일반적으로 처음 매칭된 규칙이 정책을 결정합니다. 모든 트래픽을 하나의 노드로 보내지 않고 직접 연결, 프록시와 다른 출구를 함께 유지할 때 적합합니다.

규칙 모드로 전환해도 정책 그룹 내부의 노드 선택은 계속 적용됩니다. 규칙은 어느 그룹으로 보낼지를 결정하고, 정책 그룹은 해당 그룹에서 사용할 노드나 동작을 결정하므로 서로 다른 계층입니다.

설정 키: proxy-groups

정책 그룹은 여러 노드나 다른 정책을 하나의 논리적 출구로 묶으며, 규칙은 보통 개별 노드가 아니라 정책 그룹 이름을 참조합니다. 대표적인 유형으로 수동 선택, 자동 테스트, 장애 조치와 부하 분산이 있습니다.

정책 그룹은 다른 그룹을 다시 참조할 수 있어 설정이 여러 단계의 선택 구조를 이룰 수 있습니다. 그룹 이름을 바꿀 때는 rules와 다른 정책 그룹의 참조도 함께 확인해야 하며, 그렇지 않으면 설정 로드에 실패하거나 예상과 다른 출구로 되돌아갈 수 있습니다.

관련 용어: Rule Provider

RULE-SET은 주 규칙 목록에서 독립된 규칙 모음을 참조하고, 매칭된 연결을 지정된 정책으로 전달할 때 사용합니다. 대규모 도메인 또는 IP 목록을 주 설정에 모두 작성하지 않고 별도로 관리할 수 있습니다.

규칙 모음은 먼저 Provider 영역에서 원본, 동작 유형과 업데이트 주기를 선언해야 합니다. 원격 파일을 내려받지 못하거나 형식과 behavior가 맞지 않거나 참조 이름이 잘못되면 해당 RULE-SET이 예상대로 작동하지 않습니다.

예시 의미: GEOIP,CN,DIRECT

GeoIP는 대상 IP가 지리 데이터베이스에서 어느 지역에 속하는지 기준으로 매칭합니다. 도메인 문자열 자체가 아니라 IP를 처리하므로 DNS 해석 주소, 데이터베이스 버전과 콘텐츠 전송 네트워크의 라우팅에 영향을 받습니다.

같은 도메인도 네트워크 환경에 따라 서로 다른 지역의 주소로 해석될 수 있어 GeoIP 결과가 달라집니다. 도메인별로 정확히 제어하려면 일반적으로 관련 GeoIP 규칙보다 도메인 규칙을 앞에 배치해야 합니다.

역할: 최종 기본 규칙

MATCH는 보통 규칙 목록 마지막에 위치하며, 앞선 규칙에 매칭되지 않은 연결을 처리합니다. 알 수 없는 트래픽의 기본 출구를 결정하므로 규칙 설정을 점검할 때 빠뜨려서는 안 됩니다.

MATCH를 너무 앞에 두면 뒤의 규칙이 매칭에 참여할 기회를 잃습니다. 많은 연결이 MATCH로 들어간다면 앞선 규칙이 정상적으로 로드되었는지, 도메인 정보를 사용할 수 있는지와 규칙 유형이 현재 트래픽에 맞는지 확인하세요.

일반적인 형태: 원격 URL

구독은 서비스 제공자가 게시하고 주기적으로 업데이트할 수 있는 설정 원본으로, 노드, 정책 그룹, 규칙 또는 변환된 전체 YAML을 포함할 수 있습니다. 클라이언트는 구독 주소를 저장한 뒤 수동 조작이나 설정된 주기에 따라 콘텐츠를 다시 요청합니다.

브라우저에서 구독이 열린다고 해서 반환된 콘텐츠가 현재 클라이언트에 적합한 것은 아닙니다. 파싱에 실패하면 응답 형식, 필드 호환성, 접근 권한과 중간 변환 서비스의 출력도 확인해야 합니다.

설정 확장자: .yaml 또는 .yml

YAML은 Clash 설정에서 흔히 사용하는 텍스트 직렬화 형식으로, 들여쓰기로 계층을 표현하고 콜론, 하이픈과 목록으로 필드를 구성합니다. 들여쓰기와 문자 구조에 민감하므로 복사 중 탭이 섞이거나 공백 계층이 깨지면 파싱에 실패할 수 있습니다.

문법이 올바르다는 것은 문서를 파싱할 수 있다는 뜻일 뿐, 모든 필드가 현재 코어에서 지원된다는 의미는 아닙니다. 설정을 편집한 뒤에는 먼저 로드 로그를 확인하고 정책 그룹, DNS와 규칙이 정상적으로 나타나는지 검증하세요.

설정 키: proxy-providers

Proxy Provider는 노드 목록을 주 설정에서 분리해 독립된 원본으로 관리하며, 로컬 파일이나 원격 주소를 사용하고 업데이트 주기와 상태 확인을 설정할 수 있습니다. 정책 그룹은 use 필드로 Provider의 노드를 참조합니다.

Provider 업데이트가 성공했다고 해서 주 구독도 교체된 것은 아니며, 둘은 각자의 업데이트 경로를 가집니다. 노드 목록이 오래된 경우 현재 노드가 주 설정에서 왔는지 특정 Provider에서 왔는지 확인해야 합니다.

클라이언트 화면에서 흔히 부르는 이름: Profile

설정 파일은 포트, DNS, 노드, 정책 그룹과 규칙 등의 설정을 저장하는 YAML 문서입니다. 클라이언트에 여러 설정을 저장할 수 있지만, 일반적으로 현재 선택한 설정만 코어에 로드됩니다.

설정을 전환하면 전체 정책과 리스닝 매개변수가 바뀌며, 단순히 노드만 바꾸는 것과는 다릅니다. 수정 사항이 적용되지 않으면 현재 설정을 편집했는지 확인하고 필요한 경우 설정을 다시 로드하거나 코어를 재시작하세요.

일반적인 단위: 초, 분 또는 시간

자동 업데이트 주기는 클라이언트나 Provider가 원격 콘텐츠를 다시 요청하기 전 기다리는 시간입니다. 주기가 짧으면 변경 사항을 빠르게 받을 수 있지만 요청 횟수가 늘고, 길면 노드와 규칙이 오래된 상태로 더 오래 남을 수 있습니다.

업데이트 주기를 바꿔도 이미 만료된 구독 주소가 복구되지는 않습니다. 수동 업데이트도 실패한다면 링크 연결 가능 여부, 응답 상태, 프록시 루프와 구독 형식을 먼저 확인한 뒤 주기 조정을 결정하세요.

영문: Domain Name System

DNS는 도메인을 IP 주소로 변환합니다. Clash Meta는 업스트림 DNS 서버, 대체 해석 경로와 라우팅 동작을 설정해 도메인 조회가 프록시 규칙과 함께 작동하도록 할 수 있습니다.

도메인을 해석할 수 있는지, 조회 요청이 어느 경로를 거치는지와 연결이 최종적으로 어느 출구를 사용하는지는 서로 관련 있지만 다른 문제입니다. DNS를 변경한 뒤에는 설정을 다시 로드하고 새 연결을 만들어 기존 캐시의 영향을 피해야 합니다.

설정 값: enhanced-mode: fake-ip

Fake-IP 모드는 앱에 예약 주소를 반환하고 코어에서 예약 주소와 원래 도메인 사이의 매핑을 유지합니다. 해당 주소로 연결되면 코어가 도메인 정보를 복원한 뒤 도메인 규칙과 실제 해석을 수행할 수 있습니다.

일부 LAN 기기, 특수 도메인 또는 실제 해석 결과에 의존하는 앱은 필터 목록에 추가해야 할 수 있습니다. LAN 검색, 로그인 인증 또는 특정 앱에 이상이 생기면 DNS 설정 전체를 삭제하기보다 fake-ip-filter를 확인해 보세요.

진단 대상: 해석 경로

DNS 누수는 도메인 조회가 예상한 설정 해석 경로를 거치지 않고 다른 네트워크 인터페이스, 시스템 DNS 또는 사용 예정이 아니었던 업스트림으로 전달되는 현상입니다. 조회 경로가 벗어난 것을 뜻하며 모든 연결이 프록시를 우회한다는 의미는 아닙니다.

진단할 때는 시스템 DNS, 브라우저 보안 DNS, TUN 설정과 Clash 로그를 함께 살펴봐야 합니다. 검사 페이지에 특정 DNS 서비스가 표시된다는 사실만으로 누수 원인을 단정할 수 없으며 현재 네트워크와 업스트림 설정을 대조해야 합니다.

일반적인 단위: ms

지연 시간은 테스트 요청을 보낸 뒤 응답을 받을 때까지 걸린 시간입니다. 클라이언트에 표시되는 값은 보통 지정된 테스트 주소를 기준으로 하며, 당시의 경로, 핸드셰이크와 대상 응답 상태만 반영합니다.

지연 시간이 짧다고 대용량 파일 전송 속도가 더 빠르다는 보장은 없으며 모든 웹사이트가 같은 경로를 사용한다는 뜻도 아닙니다. 노드를 선택할 때는 연결 안정성, 패킷 손실, 대역폭과 대상 서비스의 실제 접속 결과도 확인해야 합니다.

관련 용어: HTTP, HTTPS, SOCKS

시스템 프록시는 운영체제의 프록시 설정을 Clash 로컬 리스닝 포트로 지정해 해당 설정을 따르는 앱의 요청을 코어로 전달합니다. 시스템 설정을 무시하는 앱에는 보통 적용되지 않으며 모든 UDP 트래픽을 자동으로 처리하지도 않습니다.

클라이언트를 종료하기 전에 시스템 프록시 상태를 복원하면 더 이상 리스닝하지 않는 로컬 포트를 시스템이 계속 가리키는 일을 막을 수 있습니다. 브라우저는 되지만 다른 앱이 되지 않는다면 해당 앱의 시스템 프록시 지원 여부를 확인하거나 TUN 모드가 필요한지 검토하세요.

일반적인 증상: 업데이트 시간 초과, 반복 연결

프록시 루프는 프록시 요청이 같은 프록시 진입점으로 다시 전달되어 경로에서 반복 중계되는 비정상 상태입니다. 구독 업데이트, 노드 연결이나 로컬 서비스가 시스템 프록시를 잘못 상속하면 루프가 생길 수 있습니다.

점검할 때는 시스템 프록시를 잠시 끄고 구독 요청이 프록시를 거치는지 확인한 뒤 앱 제외 항목과 TUN 라우팅을 검토하세요. 로그에 같은 대상과 로컬 포트로 반복 연결이 계속 나타나는 것은 루프를 판단하는 중요한 단서입니다.