설정 항목 · 개념 구분 · 관련 문서

Clash 용어 정리

Clash 다운로드 설치 및 사용 가이드

설정이 속한 계층을 기준으로 용어를 찾아보세요. 먼저 클라이언트와 커널을 구분한 다음 설정, 규칙, 트래픽 처리, DNS를 살펴봅니다. 각 용어 제목 옆의 앵커를 사용해 개별 항목을 공유할 수 있습니다.

설정은 어디서 오나요? 트래픽은 어떻게 들어오나요? 연결은 어디로 나가나요?

CORE / PROTOCOL

커널과 프로토콜

클라이언트 UI, 커널 기능, 원격 서버는 각각 역할이 다릅니다. ‘지원하지 않는 프로토콜’ 오류가 나면 실제로 실행 중인 커널부터 확인하세요.

mihomo: core · mihomomihomo는 Clash Meta 이후 사용되는 커널 이름으로, 프록시 프로토콜·규칙 매칭·DNS·연결 처리를 담당합니다. Clash Verge Rev 같은 GUI 클라이언트는 커널을 조작할 수 있는 화면을 제공하지만, 둘은 서로 다른 프로젝트입니다. 설정 항목을 확인할 때는 클라이언트 이름만 보지 말고 현재 사용 중인 커널 버전을 기준으로 살펴보세요.

클라이언트와 커널: GUI / core클라이언트는 구독 관리, 트레이 메뉴, 시스템 프록시, 설정 표시를 담당하고 커널은 네트워크 처리를 실행합니다. 클라이언트 UI의 스위치는 설정을 생성하거나 시스템 서비스를 호출할 수 있습니다. 문제를 확인할 때 클라이언트 이름과 커널 정보를 따로 기록하면 UI 동작을 커널 제한으로 오해하지 않을 수 있습니다.

노드: proxies노드는 프록시 서버 연결을 정의한 항목으로, 보통 서버 주소·포트·프로토콜·인증 정보가 포함됩니다. 노드 이름은 구분을 위한 라벨일 뿐이므로 이름만으로 출구 위치, 대역폭, 이용 가능한 서비스를 판단할 수 없습니다. 연결 로그, 대상 사이트 접속 여부, 서버 상태를 함께 확인해야 노드 사용 가능 여부를 판단할 수 있습니다.

프록시 프로토콜: type · Shadowsocks / VMess / Trojan프록시 프로토콜은 클라이언트와 프록시 서버가 데이터를 주고받는 방식을 정합니다. 노드의 type은 프로토콜 종류를 지정합니다. 프로토콜, 전송 방식, TLS는 서로 다른 계층이므로 하나를 설정했다고 다른 항목을 대체할 수는 없습니다. 가져오기에 실패하면 커널의 지원 범위와 서버에서 제공한 전체 설정을 함께 확인하세요.

노드 지연 시간: URL test · timeout클라이언트에 표시되는 지연 시간은 보통 노드를 통해 테스트 주소에 접속하는 데 걸린 시간입니다. 단순한 ICMP 왕복 시간과는 다를 수 있습니다. 테스트 대상, 연결 핸드셰이크, 네트워크 경로가 결과에 영향을 주며 지연 시간이 짧다고 다운로드 속도가 빠른 것은 아닙니다. 시간 초과는 해당 테스트가 제한 시간 안에 끝나지 않았다는 뜻입니다. 확인 방법은 지연 시간 테스트 가이드를 참고하세요.

PROFILE / STRUCTURE

설정 파일 구조

현재 활성화된 Profile을 확인한 다음 구독 업데이트와 로컬 변경 사항의 병합 관계를 살펴보세요.

Profile 설정 파일: config.yaml · ProfileProfile은 커널이 불러오는 전체 설정으로, 일반적으로 프록시 정의·프록시 그룹·라우팅 규칙·DNS 설정을 포함합니다. 클라이언트에 여러 Profile을 저장할 수 있지만 실제 실행에는 현재 선택한 설정과 오버라이드 결과가 적용됩니다. 설정을 바꾼 뒤에는 목록의 선택 표시만 보지 말고 프록시 그룹과 규칙도 함께 바뀌었는지 확인하세요.

YAML: mapping · sequence · indentationYAML은 Clash 설정에 흔히 사용하는 데이터 형식으로, 들여쓰기로 계층을 나타내고 하이픈으로 목록 항목을 표시합니다. 들여쓰기에는 공백을 사용하고 같은 계층의 항목은 정렬해야 합니다. 특수 문자가 포함된 문자열은 따옴표로 감쌀 수 있습니다. 저장하기 전에 중복 키, 불리언 값, 목록 위치를 확인하세요. 문법 분석에 성공해도 설정 항목의 의미가 올바르다는 보장은 없습니다.

구독: remote profile · update interval구독은 원격 주소에서 노드나 설정을 가져와 업데이트합니다. 응답은 전체 Profile일 수도 있고 노드 목록만 포함할 수도 있습니다. 업데이트 간격은 다음으로 내용을 가져올 시점을 정할 뿐, 노드가 계속 온라인 상태임을 보장하지 않습니다. 구독 링크에는 계정 접근 정보가 포함될 수 있으므로 로그나 화면 캡처를 공유하기 전에 관련 주소를 삭제하세요.

프록시 제공자: proxy-providers · useproxy-providers로 노드 출처를 별도로 정의하고 프록시 그룹에서 use로 제공자 이름을 참조합니다. 이렇게 하면 노드 목록을 업데이트하면서 로컬 프록시 그룹과 규칙 구조를 유지할 수 있습니다. 제공자 파일은 전체 Profile과 구조가 다릅니다. 전체 구독 주소를 제공자 주소에 입력하기 전에 응답 형식이 맞는지 확인하세요.

로컬 오버라이드: override · merge · patch로컬 오버라이드는 원격 설정과 별도로 변경 사항을 유지하는 방식으로, 포트·DNS·사용자 지정 규칙에 주로 사용합니다. 구독에서 내려받은 파일을 직접 수정하면 다음 업데이트 때 변경 사항이 사라질 수 있으며, 오버라이드 유지 여부는 클라이언트 구현에 따라 다릅니다. 수정 후에는 최종 실행 설정을 확인하고, 특히 목록 항목이 추가·대체·재정렬되는지 살펴보세요.

RULES / OUTBOUND

라우팅 규칙

규칙은 대상을 판단하고 프록시 그룹은 아웃바운드를 선택합니다. 매칭 조건과 아웃바운드 이름을 따로 확인하세요.

규칙 기반 라우팅: rules · MATCH규칙 모드는 설정된 순서대로 연결을 확인하며, 일반적으로 처음 일치한 규칙이 아웃바운드를 결정합니다. 규칙 끝에 지정한 프록시 그룹 이름이 실제로 존재해야 합니다. DIRECT와 REJECT는 기본 제공 아웃바운드입니다. MATCH를 마지막에 두면 앞선 규칙과 일치하지 않은 연결을 처리할 수 있습니다. 너무 앞에 두면 뒤의 규칙이 적용되지 않습니다.

프록시 그룹: proxy-groups · select / url-test / fallback프록시 그룹은 여러 아웃바운드를 규칙에서 참조할 수 있는 하나의 이름으로 묶습니다. select는 수동 선택, url-test는 테스트 결과에 따른 자동 선택, fallback은 일반적으로 순서대로 사용 가능한 항목을 선택합니다. 프록시 그룹을 중첩할 때는 순환 참조에 주의하세요. 자세한 설정은 프록시 그룹 고급 설정을 참고하세요.

DOMAIN-SUFFIX: DOMAIN-SUFFIX,github.com,PROXY이 규칙은 도메인 접미사로 매칭합니다. github.com을 입력하면 와일드카드 없이 해당 도메인과 하위 도메인에 적용됩니다. 지정한 도메인만 매칭하는 DOMAIN이나 문자열 포함 여부로 매칭하는 키워드 규칙과는 다릅니다. 연결에 IP만 있고 도메인 정보가 연결되지 않으면 도메인 규칙이 적용되지 않을 수 있습니다.

GeoIP: GEOIP,CN,DIRECTGeoIP는 대상 IP의 지리 정보 데이터베이스 분류를 기준으로 매칭하며 웹페이지 언어를 기준으로 하지 않습니다. 데이터베이스가 최신이 아닐 수 있고, CDN을 사용하는 사이트는 DNS 응답에 따라 분류가 달라질 수 있습니다. GeoIP는 연결 대상을 판단하는 데 쓰이며 프록시 노드의 실제 출구 국가를 직접 증명하지는 않습니다. 문제를 확인할 때 대상 IP와 일치한 규칙을 함께 살펴보세요.

규칙 세트: rule-providers · RULE-SET · behavior규칙 세트는 여러 도메인, IP 대역, 규칙을 별도로 관리합니다. rule-providers로 정의한 다음 rules에서 참조합니다. behavior는 세트 내용을 domain, ipcidr, classical 등의 형식으로 해석하며 실제 내용과 일치해야 합니다. 규칙 세트를 업데이트해도 참조 순서는 바뀌지 않으며, 우선순위는 기본 규칙 목록의 배치 순서로 결정됩니다.

CAPTURE / LISTENER

트래픽 처리 방식

‘트래픽이 커널에 들어왔는가’와 ‘들어온 트래픽이 어떤 아웃바운드로 나가는가’는 별도로 확인해야 합니다. 하나의 스위치로 두 문제를 설명할 수 없습니다.

시스템 프록시: system proxy · HTTP / SOCKS시스템 프록시는 운영체제에 프록시 주소와 포트를 등록해 해당 설정을 따르는 앱에서 사용하도록 합니다. 일부 명령줄 프로그램, 게임, 자체 네트워크 설정을 사용하는 앱은 이를 자동으로 따르지 않습니다. 따라서 시스템 프록시를 켰다고 모든 트래픽이 처리되는 것은 아닙니다. 확인할 때는 브라우저에서 새 연결을 만든 다음 클라이언트 연결 화면에 기록이 남는지 확인하세요. 자세한 단계는 시스템 프록시 설정을 참고하세요.

TUN 모드: tun · auto-route · dns-hijackTUN은 가상 네트워크 장치와 라우팅을 통해 IP 트래픽을 처리하므로 시스템 프록시를 따르지 않는 일부 앱도 지원할 수 있습니다. 일반적으로 관련 시스템 권한이 필요하며 라우팅 제외, DNS 처리 설정과 함께 작동합니다. 켠 뒤 인터넷이 끊기면 노드를 반복해서 바꾸기보다 서비스 권한, 라우팅, DNS 조회 경로를 차례로 확인하세요.

TUN stack: stack: system / gvisor / mixedstack은 TUN 패킷에 사용할 네트워크 스택 구현을 지정합니다. system, gvisor, mixed 등을 선택할 수 있습니다. 사용 가능한 옵션과 호환성, 구체적인 동작은 플랫폼과 커널 버전에 따라 달라지므로 모든 기기에 통하는 최적값은 없습니다. 설정을 바꿀 때는 다른 항목은 그대로 두고 문제가 발생한 앱의 연결을 다시 확인하세요.

혼합 프록시 포트: mixed-port: 7890mixed-port는 하나의 수신 포트에서 HTTP와 SOCKS 프록시 연결을 받습니다. 7890은 흔히 사용하는 설정 예시일 뿐입니다. 앱에 프록시를 직접 입력할 때는 주소와 포트가 현재 실행 중인 설정과 일치해야 합니다. LAN 연결을 허용하려면 수신 주소와 방화벽 규칙도 확인해야 합니다. 이 기기에서 접속할 수 있다고 다른 기기에서도 접속할 수 있는 것은 아닙니다.

아웃바운드 모드: mode: rule / global / direct규칙 모드는 규칙 목록에 따라 아웃바운드를 선택하고, 전역 모드는 일반적으로 전역 프록시 그룹을 사용하며, 직결 모드는 커널에 들어온 트래픽을 직접 연결합니다. 이 모드는 아웃바운드 선택을 제어할 뿐 앱의 트래픽을 커널로 전달하지는 않습니다. 따라서 전역 모드가 모든 기기 트래픽을 처리한다는 뜻은 아닙니다. 차이는 아웃바운드 모드 안내에서 확인하세요.

DNS / DOMAIN MAPPING

DNS 조회

도메인을 조회하는 주체와 요청이 전달되는 경로를 먼저 확인한 뒤 Fake-IP와 도메인 스니핑을 조정하세요.

DNS 조회: dns · nameserverDNS 조회는 도메인을 IP 주소 등의 레코드로 변환하는 과정입니다. 앱, 운영체제, 커널, 프록시 서버가 모두 조회 과정에 관여할 수 있습니다. 브라우저에서 별도의 암호화 DNS를 사용하면 시스템 설정과 다른 경로로 조회될 수 있습니다. 접속에 실패하면 DNS 조회 실패, 연결 실패, 규칙 선택 오류를 구분해야 합니다. 웹페이지가 열리지 않는다는 이유만으로 노드를 사용할 수 없다고 단정하지 마세요.

Fake-IP: enhanced-mode: fake-ipFake-IP 모드는 앱에 매핑 주소를 반환하고 커널에 해당 주소와 도메인의 연결 정보를 저장합니다. 앱이 이후 매핑 주소에 연결하면 커널이 도메인을 복원해 라우팅 규칙을 적용합니다. 이 주소는 웹사이트의 실제 서버 주소가 아닙니다. 이후 트래픽도 커널로 올바르게 전달되어야 하므로 DNS 응답만 바꿔서는 트래픽을 처리할 수 없습니다.

Fake-IP 필터: fake-ip-filter · fake-ip-filter-modefake-ip-filter는 필터 모드와 함께 도메인에 실제 DNS 결과를 사용할지 제어합니다. LAN 서비스나 실제 주소가 필요한 앱의 호환성 문제에 주로 사용합니다. 목록의 의미는 현재 필터 모드에 따라 달라지므로 도메인이 목록에 있는지만 확인해서는 안 됩니다. 호환성 문제가 발생하면 먼저 해당 도메인을 찾고, 범위를 좁혀 설정한 다음 다시 테스트하세요.

DNS 누수: resolver path · encrypted DNSDNS 누수는 도메인 조회가 예상과 다른 경로로 전달되는 현상입니다. 예를 들어 프록시를 거쳐야 할 조회가 로컬 DNS 서버로 전송될 수 있습니다. 테스트 페이지에 표시되는 DNS 서버 이름은 참고 정보일 뿐입니다. 브라우저의 암호화 DNS, 시스템 설정, 클라이언트 로그를 함께 확인하세요. 일부 도메인은 원래 로컬 DNS로 직접 조회하도록 설정할 수 있으므로 이를 곧바로 설정 오류로 판단해서는 안 됩니다.

도메인 스니핑: sniffer · HTTP Host · TLS SNI도메인 스니핑은 HTTP Host나 노출된 TLS SNI처럼 지원되는 프로토콜의 연결 메타데이터에서 도메인 정보를 보완합니다. 확인한 도메인은 규칙 매칭에 활용할 수 있지만, 연결 전체를 복호화하는 기능은 아니며 모든 암호화 트래픽에서 동작한다고 보장할 수도 없습니다. 원래 대상 정보를 덮어쓸지, 어떤 포트를 처리할지는 필요에 맞게 설정해 영향 범위를 불필요하게 넓히지 마세요.