Clash 용어 사전

비교적 오래된 경량 암호화 프록시 프로토콜로, 대칭 암호화가 적용된 SOCKS5 변형이라 볼 수 있습니다. 구조가 단순하고 핸드셰이크 오버헤드가 적어 모바일 환경에서 배터리 소모가 적습니다. 거의 모든 Clash 계열 클라이언트와 코어가 기본 지원하며, 흔히 SS로 줄여 부릅니다.

V2Ray 프로젝트가 설계한 암호화 전송 프로토콜로, UUID 기반 사용자 인증과 시간 검증 메커니즘이 내장되어 있습니다. 시스템 시간에 민감해 로컬 시계가 약 90초 이상 어긋나면 핸드셰이크가 바로 실패하는데, 이것이 "모든 노드가 동시에 타임아웃" 되는 흔한 원인 중 하나입니다. 보통 WebSocket, TLS 등 전송 계층과 함께 사용됩니다.

"평범한 HTTPS 접속처럼 보이는 것"을 목표로 설계된 프로토콜로, 실제 TLS 인증서로 핸드셰이크를 진행합니다. 트래픽 특징이 일반 웹사이트 접속과 비슷하고 설정 항목이 적어 오류 발생 지점도 적습니다. 서버 측에 유효한 도메인과 인증서가 필요해 노드 설정에는 항상 SNI 필드가 포함됩니다.

VMess의 경량화 후속 프로토콜로, 프로토콜 자체의 암호화 레이어를 없애고 암호화를 전부 외부 TLS에 맡겨 이중 암호화로 인한 성능 낭비를 방지합니다. Reality 등 신형 전송 방식과 함께 자주 쓰입니다. 오리지널 Clash 코어는 이런 노드를 인식하지 못하므로 mihomo 계열 코어가 필요합니다.

QUIC(UDP) 위에 구축된 프록시 프로토콜로, 자체 혼잡 제어 알고리즘을 사용해 손실률이 높거나 거리가 먼 네트워크에서도 처리량이 뛰어납니다. UDP 포트를 사용하기 때문에 UDP를 제한하는 교내망 등에서는 아예 연결되지 않을 수 있습니다. mihomo 등 신형 코어에서만 지원됩니다.

역시 QUIC 기반의 프록시 프로토콜로, 0-RTT의 짧은 핸드셰이크 지연과 기본 UDP 포워딩 능력을 강점으로 내세워 연결 수립 속도가 중요한 상황에 적합합니다. Hysteria2와 마찬가지로 신세대 프로토콜에 속하므로, TUIC 노드가 포함된 구독을 가져오기 전 클라이언트 코어가 mihomo 계열인지 확인해야 합니다.

Clash 생태계 초기의 핵심 프로그램으로, 지금까지 이어지는 config.yaml 설정 형식과 규칙 분기 모델을 정의했습니다. 상위 저장소가 아카이브되어 업데이트가 중단되었고 VLESS, Hysteria2 등 신형 프로토콜을 지원하지 않습니다. 현재 남아있는 클라이언트 대부분이 mihomo 코어로 이전했습니다.

Clash Meta 프로젝트를 계승해 활발히 개발되는 코어로, 현재 생태계의 사실상 표준입니다. 오리지널 설정 형식을 그대로 지원하면서 신형 프로토콜, GEOSITE 도메인 데이터베이스, 더 완전한 TUN 구현을 추가했습니다. Clash Verge Rev, FlClash 등 주요 클라이언트가 기본으로 내장하고 있습니다.

Tauri 기반의 크로스 플랫폼 GUI 클라이언트로, Windows, macOS, Linux를 지원하며 mihomo 코어를 내장하고 있습니다. 구독 관리, TUN 전환, Merge/Script 설정 확장 등을 제공해 데스크톱에서 자주 선택됩니다. 설치 파일은 본 사이트의 클라이언트 페이지에서 받을 수 있습니다.

코어에 그래픽 인터페이스를 씌운 소프트웨어를 통칭하며, 구독 가져오기, 시스템 프록시 켜기/끄기, 노드 전환 같은 일상 작업을 담당합니다. 실제 트래픽 전달은 코어가 처리합니다. 클라이언트 버전과 코어 버전은 각각 독립적이므로, 프로토콜 미지원 오류가 나면 먼저 확인해야 할 것은 인터페이스 버전이 아니라 코어 버전입니다.

코어가 제공하는 로컬 HTTP 관리 인터페이스로, 설정 항목은 external-controller이며 보통 127.0.0.1:9090에서 대기합니다. 클라이언트 인터페이스와 웹 패널 모두 이를 통해 연결 목록을 읽고, 정책 그룹을 전환하고, 지연 측정을 실행합니다. 로컬 주소로만 대기할 경우 외부에는 노출되지 않습니다.

서비스 제공자가 주는 URL 하나로, 클라이언트가 주기적으로 여기서 노드 목록이나 전체 설정을 가져옵니다. 링크 만료, 트래픽 초과, 서버가 User-Agent를 기준으로 요청을 차단하는 경우 모두 "업데이트 실패"나 "업데이트 후 노드가 사라짐"으로 나타날 수 있습니다. 구체적인 판별 방법은 구독 오류 해결 글을 참고하세요.

즉 config.yaml로, 코어의 완전한 실행 설명서이며 포트, DNS, 노드(proxies), 정책 그룹(proxy-groups), 규칙(rules) 순서로 기술합니다. 클라이언트가 "구독을 가져온다"는 것은 결국 이런 파일을 내려받거나 생성해 코어에 전달하는 과정입니다.

들여쓰기로 계층 관계를 나타내는 순수 텍스트 데이터 형식으로, Clash 전 계열 설정이 이를 사용합니다. 공백에 매우 엄격한 문법을 갖고 있어, 들여쓰기는 오직 공백만 써야 하고 Tab은 쓸 수 없으며 콜론 뒤에는 반드시 공백 하나가 필요합니다. 수동으로 설정을 편집하다 "파싱 실패"가 뜨면 대부분 이 두 가지 문제입니다.

한 구독 형식을 다른 형식으로 바꿔주는 서비스나 도구로, 대표적인 용도는 범용 base64 노드 목록을 Clash의 YAML 구조로 변환하고 기존 규칙 템플릿을 함께 적용하는 것입니다. 변환 서비스는 노드 정보를 그대로 거치게 되므로, 공용 변환 사이트를 고를 때는 운영 주체가 믿을 만한지 확인해야 합니다.

설정 파일 안의 리소스 제공자 메커니즘으로, proxy-provider(노드 모음)와 rule-provider(규칙 모음) 두 종류로 나뉩니다. 노드나 규칙을 별도의 원격 파일로 분리해 설정된 간격으로 자동 업데이트할 수 있어, 여러 구독을 동시에 관리하거나 커뮤니티 규칙 세트를 참조할 때 유용합니다.

도메인, IP, 포트, 프로세스명 등의 조건에 따라 각 연결을 서로 다른 출구로 배분하는 메커니즘으로, Clash가 단순한 프록시 도구와 구별되는 핵심 기능입니다. 규칙은 위에서 아래로 순서대로 매칭되고 일치하면 즉시 멈추며, 목록 맨 끝의 MATCH 규칙이 매칭되지 않은 모든 트래픽을 처리합니다.

여러 노드를 하나의 선택 가능한 그룹으로 묶은 것으로, 규칙은 개별 노드가 아닌 그룹을 목적지로 지정합니다. 대표적인 유형: select 수동 선택, url-test 지연이 가장 낮은 노드 자동 선택, fallback 장애 조치, load-balance 로드 밸런싱. 노드를 바꿀 때는 그룹 안에서 전환만 하면 되고 규칙을 고칠 필요는 없습니다.

IP 주소의 소속 지역을 기준으로 매칭하는 규칙 유형으로, 코어에 포함된 지리 위치 데이터베이스에 의존합니다. GEOIP,CN,DIRECT는 중국 본토 IP를 직결시키는 대표적인 작성법입니다. 데이터베이스가 오래되면 소속 판정 오류가 발생할 수 있어, 클라이언트는 보통 데이터베이스 업데이트 기능을 제공합니다.

mihomo 코어가 지원하는 도메인 분류 데이터베이스로, 방대한 도메인을 사이트 카테고리별로 미리 묶어놓아 GEOSITE,category-ads-all,REJECT 규칙 한 줄로 해당 유형의 사이트 전체를 처리할 수 있습니다. DOMAIN 규칙을 하나씩 쌓는 것보다 설정이 짧고, 업데이트는 데이터베이스 관리자에게 맡길 수 있습니다.

모든 분기 규칙을 건너뛰고 전체 트래픽을 하나의 노드로만 보내는 실행 모드로, 규칙 모드(Rule), 직결 모드(Direct)와 함께 구분됩니다. "노드 문제인지 규칙 문제인지"를 임시로 확인할 때 유용하며, 일상적으로는 로컬 트래픽이 불필요하게 돌아가지 않도록 규칙 모드를 유지하는 것이 좋습니다.

두 가지 내장 특수 정책으로, DIRECT는 프록시를 거치지 않고 목적지에 직접 연결함을 뜻하고 REJECT는 해당 연결을 즉시 차단함을 뜻합니다. 광고 도메인을 REJECT로, 로컬 네트워크와 로컬 사이트를 DIRECT로 지정하는 것이 대부분의 규칙 템플릿에서 고정적으로 쓰이는 방식입니다.

실제로 사용 가능한 원격 프록시 서버 기록으로, 서버 주소, 포트, 프로토콜 종류, 인증 정보를 포함합니다. 구독의 각 줄이 하나의 노드에 해당하며, 노드 자체는 서비스 제공자가 관리하고 클라이언트는 정책 그룹에 따라 출구를 선택해 트래픽을 전달하는 역할만 합니다.

클라이언트가 지정된 테스트 주소(흔히 Google의 generate_204)로 요청을 보내 소요 시간을 밀리초 단위로 측정해 노드 응답 속도를 나타냅니다. 이 값은 왕복 시간만 반영할 뿐 다운로드 대역폭과는 다르며, 모든 노드가 동시에 타임아웃되면 가까운 것부터 순서대로 로컬 네트워크와 시스템 시간을 점검하는 것이 우선입니다.

운영체제 차원에서 등록되는 HTTP/SOCKS 프록시 진입점으로, 시스템 설정을 따르는 브라우저 등의 프로그램은 자동으로 이를 거쳐 전달됩니다. 일부 커맨드라인 도구나 게임 클라이언트는 이 설정을 읽지 않아 트래픽이 프록시로 들어가지 않으며, 이런 프로그램은 TUN 모드가 있어야 처리할 수 있습니다.

가상 네트워크 어댑터를 생성해 네트워크 계층에서 기기의 전체 트래픽을 처리하는 모드로, 시스템 프록시를 따르지 않는 애플리케이션까지 포괄할 수 있습니다. 활성화하려면 관리자 권한이나 시스템 확장 권한이 필요합니다. Windows에서는 보통 서비스 구성 요소를 먼저 설치해야 하고, macOS에서는 네트워크 확장 권한 알림창이 나타납니다.

코어가 사용하는 DNS 응답 방식 중 하나로, 예약된 대역(예: 198.18.0.0/16)의 가상 IP를 먼저 반환해 프로그램이 즉시 연결을 맺게 하고, 전달 시 실제 도메인으로 복원합니다. 실제 해석을 기다리는 시간을 줄여주고 도메인 기반 분기에도 유리하지만, 실제 IP에 의존하는 일부 프로그램(예: 로컬 네트워크 검색 서비스)은 fake-ip-filter 예외 목록에 추가해야 합니다.

도메인 해석 요청이 프록시를 거치지 않고 로컬 통신사 DNS로 직접 전달되는 현상을 말합니다. 트래픽 자체는 프록시를 거치더라도, 어떤 도메인에 접속했는지는 해석 단계에서 기록될 수 있습니다. 코어의 DNS 처리 기능(dns.enable: true)이나 TUN 모드를 활성화하고 시스템 네트워크 어댑터의 DNS 설정을 점검하면 이런 유출을 없앨 수 있습니다.

각 프록시 프로토콜의 등장 배경, 속도와 리소스 사용량 비교, 코어 계보 관계, 상황별 선택 가이드를 다룹니다. 프로토콜 가이드 바로가기 →

구독 가져오기부터 연결 확인까지 단계별로 설명하며, 용어 사전에 나온 명칭이 튜토리얼 속 실제 화면 위치와 대응됩니다. 튜토리얼 바로가기 →

기본 개념, 설치와 설정, 사용 팁, 문제 해결 네 가지로 정리한 Q&A 모음입니다. FAQ 바로가기 →