설정 읽기 · 개념 빠른 참조
Clash 용어집
구독, 노드, 규칙 기반 라우팅, 프로토콜, 코어, DNS 설정에서 자주 쓰이는 용어를 한곳에서 설명합니다. 각 항목은 개념 자체와 실제 용도, 혼동하기 쉬운 경계를 함께 다뤄 튜토리얼을 읽거나 설정을 점검할 때 빠르게 참고할 수 있습니다.
5개 분류
26개 용어
설정 및 네트워크 개념
01
핵심 개념
먼저 설정의 출처, 연결 대상, 실행 상태를 구분해 보세요. 이 용어들은 클라이언트 홈 화면, 구독 관리, 문제 해결 단계에서 반복해서 등장합니다.
- 구독
- 서비스 제공자가 발행하는 원격 설정 주소로, 일반적으로 노드, 프록시 그룹 또는 규칙 정보를 포함합니다. 클라이언트는 구독 URL에서 내용을 가져온 뒤 업데이트 후 사용할 수 있는 설정을 다시 생성합니다. 구독을 업데이트하면 해당 출처가 관리하는 내용이 덮어써지므로 로컬 설정을 변경하기 전에 클라이언트가 오버라이드를 지원하는지 확인해야 합니다.
- 노드
- 클라이언트가 연결을 설정할 수 있는 프록시 엔드포인트입니다. 일반적으로 서버 주소, 포트, 프로토콜 유형, 인증 매개변수를 포함합니다. 목록에 노드가 표시된다고 해서 반드시 연결할 수 있는 것은 아니며, 상태는 설정값과 네트워크 경로, 서버 작동 여부에 따라 달라집니다.
- 지연 시간
- 클라이언트가 테스트 요청을 보낸 후 응답을 받을 때까지 걸리는 시간으로, 보통 밀리초로 표시합니다. 지연 시간이 짧으면 대체로 상호작용 응답이 빠르지만 대역폭, 안정성, 실제 다운로드 속도를 단독으로 나타내지는 않습니다. 테스트 주소에 따라 결과가 달라질 수도 있습니다.
- 설정 파일
- 포트, 프록시 노드, 프록시 그룹, DNS 및 라우팅 규칙을 정의하는 구조화된 파일입니다. Clash 생태계에서는 주로 YAML 형식을 사용하며, 필드 계층과 들여쓰기가 로딩 결과에 직접 영향을 줍니다. 설정은 구독에서 가져오거나 사용자가 로컬에서 직접 관리할 수 있습니다.
- 실행 설정
- 클라이언트가 현재 코어에 전달해 실행하는 완전한 설정입니다. 로컬 설정, 구독 내용, 스크립트, 오버라이드 규칙이 병합되어 만들어질 수 있으므로 원본 구독 파일과 내용이 완전히 같지 않을 수 있습니다. 규칙이나 DNS 문제를 해결할 때는 실제 실행 설정을 우선 확인해야 합니다.
02
프로토콜과 전송
프로토콜은 클라이언트와 서버가 인증하고 데이터를 교환하는 방식을 결정하며, 전송 매개변수는 연결을 운반하는 방식을 설명합니다. 이름이 같아도 모든 매개변수 조합을 서로 바꿔 사용할 수 있는 것은 아닙니다.
- Shadowsocks(SS)
- 비교적 간결한 구조의 암호화 프록시 프로토콜로, 일반적으로 SS라고 줄여 부릅니다. 설정할 때 서버 주소, 포트, 암호화 방식, 비밀번호를 서로 일치시켜야 합니다. 암호화 알고리즘 사용 가능 여부는 현재 코어의 지원 범위에도 좌우됩니다.
- VMess
- V2Ray 생태계의 프록시 프로토콜로, 보통 사용자 식별자, 전송 방식, 보안 관련 매개변수를 포함합니다. WebSocket, HTTP 등의 전송 방식과 조합할 수 있으며, 클라이언트마다 기존 필드와 전송 조합의 호환 범위가 다를 수 있습니다.
- Trojan
- TLS 연결 형태를 기반으로 설계된 프록시 프로토콜입니다. 서버, 포트, 비밀번호, 서버 이름이 주요 필드이며, 클라이언트는 보통 인증서 검증과 ALPN 등의 옵션도 처리합니다. 서버 이름이나 인증서 관련 매개변수가 일치하지 않으면 연결이 정상적으로 설정되지 않는 경우가 많습니다.
- VLESS
- 인증과 구체적인 전송 기능을 분리해 다루는 프로토콜로, TLS, Reality, WebSocket, gRPC 등과 함께 사용하는 경우가 많습니다. 노드 이름에 VLESS만 적어서는 전체 연결 방식을 설명할 수 없습니다. 실제 호환성은 코어 버전과 각 전송 매개변수가 모두 갖춰졌는지에 따라 달라집니다.
- UDP
- 데이터그램을 대상으로 하는 전송 프로토콜로, TCP처럼 먼저 신뢰성 있는 바이트 스트림을 설정하지 않습니다. 음성 통화, 게임, 일부 DNS 요청에서 UDP를 사용할 수 있습니다. 노드, 프록시 그룹, 코어가 해당 기능을 지원해야 관련 트래픽이 예상대로 전달됩니다.
03
규칙과 라우팅
규칙은 연결을 식별하고 프록시 그룹은 출구를 결정합니다. 매칭 순서와 최종 규칙을 이해하는 것은 Clash의 규칙 기반 라우팅을 조정하는 기본입니다.
- 규칙 기반 라우팅
- 도메인, IP, 프로세스 또는 규칙 집합을 기준으로 연결을 직접 연결할지, 거부할지, 지정된 프록시 그룹으로 보낼지 판단합니다. 규칙은 보통 위에서 아래로 매칭되며, 먼저 일치한 항목이 연결의 경로를 결정합니다. 규칙 모드와 글로벌 모드의 핵심 차이는 이 순차적인 판단을 실행하는지 여부입니다.
- 프록시 그룹
- 여러 노드나 다른 정책을 하나의 논리적 출구로 묶어 규칙에서 참조할 수 있게 합니다. 프록시 그룹은 수동으로 선택하거나 지연 시간 테스트, 장애 순서, 부하 방식에 따라 자동으로 결정할 수 있습니다. 규칙이 그룹 이름을 가리키면 최종 노드는 그룹의 현재 상태에 따라 정해집니다.
- DOMAIN-SUFFIX
- 지정한 도메인 접미사와 그 하위 도메인을 매칭하는 규칙 유형입니다. 예를 들어
example.com에 대한 접미사 규칙은 일반적으로www.example.com도 매칭할 수 있습니다. 같은 주 도메인 아래의 여러 서비스를 포괄하는 데 적합합니다.
- GEOIP
- 대상 IP의 지리 데이터베이스상 소속을 기준으로 매칭하는 규칙 유형입니다. 결과는 로컬 GeoIP 데이터의 내용과 업데이트 시점에 따라 달라집니다. 이 규칙은 조회된 IP의 소속을 처리하며 도메인 자체를 분류하는 것과는 다릅니다.
- MATCH
- 앞선 규칙에 하나도 매칭되지 않은 연결을 처리하며, 보통 규칙 목록의 마지막에 배치합니다. 전체 규칙의 기본 출구에 해당합니다. MATCH가 너무 앞에 있으면 뒤의 구체적인 규칙은 매칭에 참여할 기회를 얻지 못합니다.
- 규칙 집합
- 같은 유형의 매칭 조건을 독립적으로 관리하고 참조할 수 있는 데이터 집합으로 정리한 것입니다. 원격 규칙 집합은 별도로 업데이트해 주 설정 파일의 중복 항목을 줄일 수 있습니다. 형식과 동작 유형, 참조 이름은 현재 코어의 요구 사항에 맞아야 합니다.
04
클라이언트와 코어
그래픽 인터페이스, 프록시 코어, 설정 형식은 서로 다른 계층에 속합니다. 이 계층을 구분하면 특정 기능을 인터페이스가 제공하는지 코어가 제공하는지 판단하기 쉽습니다.
- mihomo
- Clash Meta 이후에 사용되는 코어 이름으로, 설정을 해석하고 프록시 연결을 설정하며 규칙을 실행하고 DNS를 처리합니다. 그래픽 클라이언트는 보통 mihomo 위에 구독 관리, 활성화 전환, 상태 시각화 기능을 제공합니다. 프로토콜 지원 여부를 판단할 때는 대개 인터페이스 버전보다 코어 버전이 중요합니다.
- Clash Meta
- Clash 생태계의 확장 코어 브랜치 이름으로, 더 많은 프로토콜과 DNS, 네트워크 가로채기 기능을 추가했습니다. 이후 프로젝트는 mihomo라는 이름으로 유지되고 있어 기존 문서에는 여전히 Clash Meta가 자주 등장합니다. 두 이름은 서로 다른 시점의 문맥에서 같은 발전 계통을 가리킬 수 있습니다.
- 그래픽 클라이언트
- 프록시 코어를 감싸 창, 메뉴, 시스템 연동 기능을 제공하는 데스크톱 또는 모바일 애플리케이션입니다. 클라이언트는 구독 가져오기, 활성화 전환, 상태 표시를 담당하며 실제 트래픽 처리는 대개 코어가 수행합니다. 인터페이스 버전과 코어 버전은 별도로 업데이트될 수 있습니다.
- YAML
- Clash 설정에서 자주 사용하는 텍스트 직렬화 형식으로, 들여쓰기로 계층을 표현합니다. 공백 수, 목록 기호, 콜론 위치가 모두 문법적 의미를 가집니다. 탭 문자, 잘못된 계층, 필요한 공백 누락으로 설정 로딩이 실패할 수 있습니다.
05
네트워크와 DNS
이 용어들은 트래픽이 코어로 들어오는 방식과 도메인이 조회되는 방식을 설명합니다. 시스템 프록시와 TUN은 트래픽을 가로채는 계층이 다르며, DNS 경로도 별도로 확인해야 합니다.
- 시스템 프록시
- 운영체제의 HTTP 또는 SOCKS 프록시 설정을 Clash의 로컬 수신 포트로 지정합니다. 시스템 프록시 설정을 따르는 애플리케이션은 해당 요청을 클라이언트로 전달합니다. 일부 앱은 별도의 네트워크 스택을 사용하므로 시스템 프록시만 켜서는 모든 트래픽이 처리되지 않을 수 있습니다.
- TUN 모드
- 가상 네트워크 인터페이스로 시스템 트래픽을 받은 다음 코어가 라우팅과 전달을 수행합니다. 일반적으로 시스템 프록시보다 더 많은 애플리케이션과 비HTTP 트래픽을 처리할 수 있습니다. 사용할 때는 시스템 권한, 라우팅, 인터페이스 충돌, DNS 설정을 올바르게 구성해야 합니다.
- Mixed Port
- 하나의 로컬 포트에서 HTTP와 SOCKS 프록시 연결을 동시에 수신하는 방식입니다. 설정 필드는 보통
mixed-port로 작성하며, 흔히 사용하는 로컬 포트 예시는 7890입니다. 다른 앱에서 프록시 주소를 입력할 때는 수신 주소와 포트도 함께 확인해야 합니다.
- Fake-IP
- DNS 모듈이 애플리케이션에 매핑된 주소를 반환하고, 연결이 발생하면 매핑 관계를 바탕으로 대상 도메인을 복원합니다. 도메인 규칙을 일찍 적용하고 먼저 조회한 뒤 매칭할 때 생기는 정보 손실을 줄이는 데 유리합니다. LAN 장치, 연결성 검사, 특수 도메인은 필터 목록에 추가해야 할 수 있습니다.
- DNS 누수
- 애플리케이션의 도메인 조회가 예상한 DNS 처리 경로를 우회해 다른 리졸버로 직접 전달되는 현상입니다. 점검할 때는 시스템 DNS, 브라우저 보안 DNS, TUN 적용 범위, 설정의 nameserver를 함께 확인해야 합니다. 프록시 연결 성공 여부만으로는 DNS 경로를 완전히 판단할 수 없습니다.
- Nameserver
- DNS 설정에서 일반 도메인 조회를 담당하는 업스트림 서버 목록입니다. fallback, default-nameserver 등의 필드와 용도가 다르므로 이름만 보고 서로 바꿔 사용할 수 없습니다. 실제 요청 경로는 DNS 모드, 도메인 규칙, 코어 설정의 영향도 받습니다.
설정 자료 더 살펴보기
용어를 실제 작업 흐름에 적용하려면 시작 가이드부터 확인하세요. 프로토콜, 코어, 호환성을 비교하려면 프로토콜 참고 자료를 살펴보세요.