reference / terminology

Clash 용어집

설정 위치에 따라 커널, 구독, 규칙, DNS의 의미를 확인하세요.

먼저 분류를 고른 다음 용어 카드를 살펴보세요. 각 카드에서 개념과 기능, 헷갈리기 쉬운 구분점을 설명합니다. 낯선 항목을 발견했다면 카드 링크를 바로 공유할 수도 있습니다. 설정 설명은 mihomo를 기준으로 하며, 클라이언트에 따라 화면의 명칭이 조금씩 다를 수 있습니다.

config.yaml → 용어 → 작업 단계별로 첫 설정 완료하기 ›

커널 및 클라이언트

작업을 위한 인터페이스, 트래픽을 전달하는 커널, 트래픽이 커널로 들어가는 방식을 먼저 구분하세요.

mihomocore / 프록시 커널: 실제 연결을 처리하는 프로그램이라고 이해하면 됩니다. mihomo는 Clash Meta에서 이름이 바뀐 커널로, 설정을 읽고 DNS를 처리하며 규칙을 적용해 요청을 전달합니다. 클라이언트 업데이트와 커널 업데이트는 서로 다른 시점에 제공될 수 있습니다. 특정 항목의 지원 여부를 확인할 때는 앱 이름만 보지 말고 현재 실행 중인 커널과 버전을 확인하세요.

GUI 클라이언트graphical user interface / 그래픽 사용자 인터페이스: 구독을 가져오고, 프록시를 선택하고, 로그를 확인하는 등의 작업을 명령어를 직접 입력하지 않고 처리할 수 있습니다. GUI는 그래픽 사용자 인터페이스의 약자이며, 보통 인터페이스 뒤에서 프록시 커널도 실행됩니다. 같은 커널을 사용하는 클라이언트끼리도 설정 병합 방식, 권한 관리, 설정 저장 위치가 다를 수 있습니다.

시스템 프록시system proxy / 앱의 프록시 연결 설정: 시스템 설정을 따르는 앱이 로컬 프록시 포트로 연결되도록 할 때 사용합니다. 시스템 프록시를 켜면 보통 프록시 주소만 설정되며 모든 트래픽이 처리되는 것은 아닙니다. 일부 터미널 도구, 게임, 자체 네트워크 스택을 사용하는 앱은 이 설정을 따르지 않을 수 있습니다. 클라이언트를 종료한 뒤 네트워크에 문제가 생기면 시스템에 이전 프록시 주소가 남아 있는지 먼저 확인하세요.

TUN 모드virtual network interface / 가상 네트워크 인터페이스: 시스템 프록시 설정을 읽지 않는 앱의 트래픽을 처리해야 한다면 TUN 가상 네트워크 인터페이스 사용을 고려하세요. 시스템 라우팅과 연동해 연결을 커널로 전달하며, 보통 관리자 권한, 서비스 모드 또는 시스템 VPN 권한이 필요합니다. 스위치를 켰다고 해서 트래픽 처리가 보장되는 것은 아닙니다. 라우팅, DNS, 제외 항목을 확인하고 다른 VPN과의 충돌에도 유의하세요.

외부 컨트롤러 인터페이스external-controller / 관리 인터페이스: 클라이언트나 관리 대시보드가 이 인터페이스를 통해 상태를 확인하고, 정책을 전환하고, 연결을 관리할 수 있습니다. external-controller 항목에서 수신 주소를 지정합니다. 예: 127.0.0.1:9090. 브라우저에 입력하는 프록시 포트와는 다릅니다. 로컬에서만 관리할 때는 로컬 주소로 수신하고, 원격 접속이 필요하면 인증과 접근 범위를 별도로 설정하세요.

설정 파일 항목

파일 구조를 먼저 파악한 다음 현재 실제로 적용된 값을 확인하세요. 다운로드한 원본 파일만 수정해서는 안 됩니다.

YAMLconfig.yaml / 구조화된 텍스트: 설정을 편집할 때는 기존 들여쓰기 구조를 유지하세요. YAML은 config.yaml 같은 파일에 자주 사용되는 구조화된 텍스트 형식입니다. 들여쓰기로 항목의 계층을 나타내고, 하이픈으로 목록 항목을 표시합니다. 탭이 아닌 공백으로 들여써야 합니다. 특수 문자가 포함된 값은 따옴표로 묶어야 할 수 있습니다. 저장한 뒤에는 구문을 확인하고 설정을 다시 불러오세요.

mixed-portlistener / 혼합 수신 포트: 앱의 프록시 포트에는 이 항목의 실제 값을 입력하세요. mixed-port: 7890은 같은 포트에서 HTTP와 SOCKS 프록시 연결을 모두 받는다는 뜻입니다. 포트 번호는 변경할 수 있으며 모든 클라이언트가 같은 포트를 사용하는 것은 아닙니다. 다른 프로그램이 포트를 사용 중이면 커널이 정상적으로 수신하지 못할 수 있으니, 양쪽 설정을 바꾸기 전에 로그부터 확인하세요.

allow-lanlocal network / LAN 접속 허용: 같은 LAN에 있는 다른 기기에서 프록시를 사용해야 할 때만 활성화를 고려하세요. allow-lan: true는 LAN 연결을 허용하지만, 실제 접속 가능 여부는 수신 주소와 시스템 방화벽에도 달려 있습니다. 외부에 열기 전에 네트워크를 신뢰할 수 있는지 확인하고 필요에 따라 인증을 설정하세요. 이 항목은 이 기기의 일반적인 인터넷 연결에 필요한 설정이 아닙니다.

moderule / global / direct: 일반적으로는 먼저 mode: rule을 선택해 요청이 규칙에 따라 연결 경로를 정하도록 합니다. global은 연결을 전역 정책으로 보내고, direct는 프록시 없이 직접 연결합니다. 여기서 전역 모드가 처리하는 것은 커널로 들어온 트래픽입니다. 모드를 바꿔도 원래 커널을 거치지 않는 앱이 자동으로 프록시를 사용하게 되지는 않습니다.

log-levellogging / 로그 수준: 문제를 진단할 때 로그 상세도를 조절합니다. 자주 사용하는 값은 info, warning, error, debug입니다. 상세 로그는 파싱, 규칙, 연결 문제를 찾는 데 도움이 되지만 출력량이 늘어납니다. 로그를 공유하기 전에는 구독 주소, 인증 정보, 공개하고 싶지 않은 접속 기록을 삭제하세요.

프록시 프로토콜

앱이 로컬 프록시에 연결하는 방식과 커널이 원격 서버에 연결할 때 사용하는 프로토콜을 구분하세요.

HTTP 프록시HTTP / CONNECT: 수동 프록시 설정을 지원하는 앱에서 HTTP 프록시를 선택하고 수신 주소를 입력할 수 있습니다. HTTPS 사이트에 접속할 때는 보통 CONNECT 방식으로 터널을 만듭니다. 대상 사이트의 HTTPS 연결과 앱에서 프록시까지의 연결 암호화 여부는 별개의 문제입니다. 일반 HTTP 프록시가 모든 연결을 자동으로 암호화하지는 않으며, 범용 UDP 전달을 직접 대체할 수도 없습니다.

SOCKS5TCP / UDP ASSOCIATE: 앱이 지원한다면 SOCKS5를 사용해 연결을 로컬 프록시로 전달할 수 있습니다. 이 프로토콜은 TCP를 지원하고 UDP 처리 방식도 정의하지만, 앱과 클라이언트, 원격 연결 경로가 모두 해당 기능을 지원해야 합니다. 도메인을 로컬에서 조회할지 프록시 서버에서 조회할지는 앱의 동작 방식에 따라 다릅니다. SOCKS5를 선택했다고 해서 DNS가 반드시 프록시를 통해 전달되는 것은 아닙니다.

ShadowsocksSS / 암호화 프록시 프로토콜: 이 유형의 노드를 가져올 때는 서버 주소, 포트, 비밀번호, 암호화 방식을 확인하세요. Shadowsocks는 양쪽이 합의한 설정으로 프록시 트래픽을 전달하므로, 설정이 일치하지 않으면 연결이 제대로 이루어지지 않을 수 있습니다. 커널마다 지원하는 암호화 방식과 확장 기능이 다를 수 있으므로 노드 이름만으로 호환성이나 속도를 판단해서는 안 됩니다.

VMessUUID / 전송 설정: 설정할 때 사용자 식별자인 UUID와 전송 설정이 올바른지 함께 확인하세요. VMess는 다양한 전송 방식과 함께 사용할 수 있습니다. 주소와 포트가 맞더라도 경로, 호스트 이름, TLS 설정이 다르면 연결에 실패할 수 있습니다. 시스템 시간이 크게 틀어져도 인증에 영향을 줄 수 있으므로 시간 동기화 상태와 커널 로그도 확인하세요.

TrojanTLS / 서버 인증: 이 유형의 노드에 연결할 때는 비밀번호, 서버 이름, 인증서 요구 사항을 함께 확인하세요. Trojan은 보통 TLS 연결 안에서 프록시 트래픽을 전달하며, TLS는 전송을 보호하고 서버 신원을 확인하는 데 사용됩니다. 인증서 오류가 발생하면 인증서 검증을 건너뛰는 대신 시간, 도메인, 서버 설정을 먼저 확인하세요.

규칙 및 라우팅

먼저 매칭 조건을 확인하고, 다음으로 연결 출구 이름을 살펴보세요. 규칙 순서와 데이터 파일 모두 결과에 영향을 줍니다.

규칙 기반 라우팅rules / 조건에 따라 연결 경로 선택: 규칙 모드에서는 도메인, 대상 IP 등의 조건에 따라 요청을 어디로 보낼지 정합니다. 규칙은 보통 위에서부터 확인하며, 먼저 일치한 항목이 연결 경로를 결정합니다. 따라서 구체적인 예외 규칙을 포괄적인 규칙보다 앞에 두세요. 출구는 DIRECT 직접 연결이나 정책 그룹 중에서 선택할 수 있습니다. 그룹 이름은 설정에 정의된 이름과 일치해야 합니다.

DOMAIN-SUFFIXdomain matching / 도메인 접미사 매칭: 도메인과 하위 도메인을 함께 포함하려면 이 유형의 규칙을 사용하세요. 예를 들어 DOMAIN-SUFFIX,example.com,DIRECT는 example.com과 www.example.com에 매칭됩니다. 도메인 접미사의 경계를 기준으로 매칭하므로 다른 도메인에 같은 문자열이 포함되어 있다는 이유만으로 일치하지는 않습니다.

GeoIPGEOIP / IP 주소 분류: IP 주소가 속한 국가나 지역에 따라 라우팅하려면 GeoIP 데이터를 사용하세요. GEOIP,CN,DIRECT 규칙은 데이터베이스에서 CN으로 분류된 주소를 직접 연결로 보냅니다. 도메인 요청을 매칭할 때는 DNS 조회가 필요할 수 있습니다. 데이터베이스의 업데이트 시점과 분류 오차에 따라 결과가 달라질 수 있으므로, 주소의 지역 태그만으로 서버의 실제 위치를 단정할 수는 없습니다.

GeoSiteGEOSITE / 도메인 모음: 많은 도메인을 서비스나 카테고리별로 관리하려면 GeoSite 모음을 사용할 수 있습니다. IP를 분류하는 GeoIP와 달리, 관리된 도메인 목록을 기준으로 매칭합니다. 사용할 수 있는 카테고리는 불러온 데이터 파일에 따라 다릅니다. 규칙을 추가하기 전에 카테고리가 존재하는지 확인하고 현재 커널에 맞는 데이터 소스를 사용하세요.

MATCHfallback rule / 기본 규칙: 규칙 목록의 마지막에 MATCH를 두어 앞선 규칙과 일치하지 않은 요청의 연결 경로를 지정하세요. 예를 들어 MATCH,PROXY는 나머지 요청을 PROXY라는 정책으로 보냅니다. MATCH 자체는 웹사이트가 어느 지역에 속하는지 판별하지 않습니다. 너무 앞에 두면 뒤에 있는 규칙이 확인해야 할 요청까지 가로채게 됩니다.

DNS 및 네트워크

DNS 조회와 연결 설정을 따로 확인하세요. 네트워크 문제를 하나의 스위치만으로 설명하려고 하지 마세요.

DNSdomain name system / 도메인 이름 시스템: 도메인에 접속하기 전에 앱은 보통 DNS로 IP 주소 등의 레코드를 조회합니다. DNS 조회와 이후의 웹 연결은 별개의 단계이므로, 특정 IP에 접속할 수 있다고 해서 도메인 조회가 정상인 것은 아닙니다. 시스템, 브라우저, 프록시 커널이 모두 DNS 조회에 관여할 수 있습니다. 문제를 진단할 때는 먼저 어떤 구성 요소가 어떤 DNS 서버에 조회를 보내는지 확인한 다음 관련 설정을 조정하세요.

Fake-IPenhanced-mode / 가상 주소 매핑: 이 DNS 방식을 사용하면 커널이 먼저 앱에 가상 주소를 반환하고 주소와 도메인의 매핑을 저장합니다. 앱이 해당 주소에 연결하면 커널이 도메인 정보를 바탕으로 요청을 처리하므로, 화면에 보이는 주소는 웹사이트의 실제 공인 IP가 아닐 수 있습니다. 일부 앱이나 LAN 서비스에서는 호환성 문제가 생길 수 있습니다. 노드를 계속 바꾸기보다 해당 도메인을 필터링하도록 설정하세요.

nameserverupstream resolver / 상위 DNS 서버: mihomo의 dns 섹션에서 이 항목으로 상위 DNS 서버를 지정합니다. 목록에는 커널이 지원하는 주소 형식을 사용할 수 있습니다. 다만 실제 조회 경로는 도메인별 정책이나 프록시 노드의 DNS 설정 등 다른 항목의 영향을 받을 수 있습니다. 시스템의 모든 DNS 요청이 이 서버 하나를 통해 처리된다고 생각해서는 안 됩니다. 변경한 뒤에는 트래픽 처리 범위와 캐시도 확인하세요.

DNS 누출resolver path / 예상과 다른 DNS 경로: DNS 누출 여부를 판단하기 전에 예상하는 DNS 조회 경로를 먼저 확인하세요. 이 용어는 보통 웹 페이지는 프록시를 통하지만 도메인 조회는 로컬 네트워크로 전달되는 등, 조회가 의도한 경로를 벗어난 상황을 가리킵니다. 브라우저의 보안 DNS, 시스템 설정, TUN 처리 여부, 캐시를 함께 살펴보세요. DNS 서버의 위치가 다르다는 사실만으로 모든 트래픽의 경로를 단정할 수는 없습니다.

DNS 가로채기dns-hijack / TUN에서의 DNS 리디렉션: mihomo 설정에서 dns-hijack는 조건에 맞는 DNS 요청을 내장 DNS 모듈로 리디렉션하는 기능입니다. 일반적으로 말하는 악의적인 DNS 응답 변조와는 다른 의미입니다. TUN과 함께 사용하는 경우가 많지만 지정된 대상과 프로토콜만 처리합니다. 브라우저의 암호화된 DNS 요청까지 자동으로 감지해 처리한다고 가정해서는 안 됩니다.

구독 및 노드

설정의 출처, 개별 연결 정보, 연결 경로 선택 방식을 구분한 다음 테스트 결과를 확인하세요.

구독 링크subscription / 설정 가져오기 경로: 서비스 제공자가 안내한 구독 링크를 클라이언트에 가져와 설정이나 프록시 항목 목록을 불러옵니다. 링크에 따라 전체 YAML, 인코딩된 목록 등 다양한 형식이 반환될 수 있으므로 클라이언트의 가져오기 방식과 호환되는지 확인하세요. 링크에는 계정 접근 정보가 포함되는 경우가 많으니 인증 정보처럼 안전하게 보관하고, 스크린샷이나 문의 글에 공개하지 마세요. 업데이트 실패가 모든 노드의 사용 불가를 뜻하는 것은 아닙니다.

노드proxy entry / 프록시 연결 항목: 노드는 커널이 사용할 연결 설정 한 묶음입니다. 보통 서버 주소, 포트, 프로토콜, 인증 정보가 포함됩니다. 표시 이름은 설정 제공자가 정하므로 실제 위치나 연결 출구를 정확하게 나타내지 않을 수 있습니다. 특정 서비스에 연결할 수 있는지는 회선, 원격 출구, 대상 서비스의 제한에도 영향을 받으므로 이름만으로 판단하지 마세요.

지연 시간latency / 지정한 테스트에 걸리는 시간: 지연 시간 수치를 비교하기 전에 테스트 방식과 대상 주소를 확인하세요. 클라이언트 테스트는 보통 프록시를 통해 지정된 요청을 완료하는 데 걸린 시간을 나타내며, 네트워크 상태, 연결 설정, 대상 서버의 응답에 영향을 받습니다. 단순한 ICMP 왕복 시간과는 다릅니다. 지연 시간이 낮다고 다운로드 속도가 빠른 것은 아니며, 테스트 시간이 초과되더라도 테스트 대상에 연결할 수 없는 경우일 수 있습니다.

proxy-providersproxy collection / 프록시 모음의 출처: 설정에서 이 항목을 사용해 별도로 업데이트할 수 있는 프록시 모음을 지정합니다. 원격 주소나 로컬 파일을 가져올 수 있습니다. 정책 그룹에서 이 모음을 참조하면 노드를 사용할 수 있고, 설정에 따라 업데이트나 상태 확인을 수행할 수 있습니다. 일반적으로 프록시 항목만 관리하므로 DNS와 규칙 등을 포함한 전체 설정을 대체하지 않습니다. 따라서 모든 구독 링크를 여기에 그대로 입력할 수 있는 것은 아닙니다.

정책 그룹proxy-groups / 연결 출구 구성: 여러 노드 가운데 연결 출구를 선택해야 할 때 정책 그룹을 사용해 출구 이름을 통합하세요. select는 주로 수동 선택에, url-test는 테스트 결과에 따른 선택에, fallback은 순서대로 사용 가능한 항목을 찾는 데 쓰입니다. 구체적인 동작은 설정값에 따라 다릅니다. 규칙에서 그룹 이름을 참조한 뒤에도 그룹 내부의 선택이 실제 연결에 영향을 주므로, 문제를 진단할 때는 매칭된 규칙과 최종 노드를 함께 확인하세요.