설정 개념 · 필드 비교

Clash 용어 가이드

개념별로 설정 문제를 찾아보세요. 먼저 클라이언트와 커널을 구분한 뒤 프록시 프로토콜, 규칙, DNS, 업데이트 필드를 확인하면 됩니다.

자주 쓰이는 용어 25개를 정리했습니다. 설명은 Clash 생태계와 mihomo의 일반적인 설정을 기준으로 합니다. 실제 지원 여부는 실행 중인 커널과 클라이언트의 안내에서 확인하세요. 각 카드에는 고유한 앵커가 있어 해당 항목을 바로 공유할 수 있습니다.

커널과 클라이언트

클라이언트는 조작 메뉴를 제공하고, 커널은 네트워크 처리를 담당하며, 구독은 설정을 배포합니다. 호환성 문제를 해결하려면 이 세 계층을 각각 확인해야 합니다.

클라이언트Client / GUI: 설정 가져오기, 프록시 켜기·끄기, 로그 확인, 업데이트 메뉴를 제공하는 애플리케이션입니다. 실제 네트워크 처리는 대개 커널이 담당합니다. 같은 클라이언트에서 커널을 바꿔 사용할 수도 있으므로 화면에 표시된 앱 이름이 같다고 프로토콜 지원까지 동일한 것은 아닙니다. 문제를 문의할 때는 앱 이름만 적거나 화면 캡처만 보내지 말고 클라이언트 이름, 커널 이름과 각각의 버전을 함께 기록하세요.

커널Core: 설정을 읽고 프록시 프로토콜을 처리하며 규칙을 적용해 연결을 전달하는 프로그램입니다. 필드의 적용 여부는 설정 화면에 해당 스위치가 있는지만으로 결정되지 않고 커널과 버전에 따라 달라집니다. 클라이언트 업그레이드, 커널 업그레이드, 구독 업데이트는 서로 다른 작업입니다. 구독만 새로고침해서 새 프로토콜을 지원하게 할 수는 없습니다.

mihomoClash Meta의 후속 프로젝트 이름: Clash Meta 프로젝트에서 발전한 프록시 커널로, 규칙 기반 라우팅, 리소스 제공자, TUN, DNS 등의 기능을 제공합니다. 특정 데스크톱 인터페이스에만 속하는 이름은 아닙니다. 그래픽 클라이언트에서 관리하거나 단독으로 실행할 수 있습니다. 설정을 복사하기 전에 필요한 기능이 현재 버전에서 지원되는지 확인하세요. 버전 발전 관계는 커널 차이 안내를 참고하세요.

Clash Meta이전 이름이자 생태계 표기: Clash 생태계에서 사용되던 커널 분기 이름이며, 후속 프로젝트는 mihomo라는 이름으로 유지 관리됩니다. 예전 가이드와 설정 주석, 일부 클라이언트 이름에는 Meta가 남아 있을 수 있으므로 이름만 보고 설정이 오래됐다고 판단하지 마세요. 필드 해석 오류가 발생하면 실제 실행 중인 커널의 버전과 오류 위치를 확인한 뒤 커널을 업데이트할지 설정을 수정할지 결정하세요.

구독Subscription: 원격 URL에서 설정이나 프록시 리소스를 가져와 업데이트하는 배포 방식입니다. 링크는 전체 YAML 설정을 반환할 수도 있고 프록시 목록만 반환할 수도 있으므로 둘을 같은 형식으로 보면 안 됩니다. 전체 설정을 업데이트하면 규칙과 정책 그룹이 교체될 수 있으니, 변경 사항을 유지하려면 클라이언트가 지원하는 오버라이드 기능을 사용하세요. 구독 링크에는 접속 정보가 포함될 수 있으므로 공개 화면 캡처나 로그, 온라인 변환 서비스에 올리지 마세요.

프록시 프로토콜

프로토콜은 클라이언트와 서버가 통신하는 방식을 정합니다. 서버 주소, 인증 정보, 전송 방식, TLS 설정이 함께 맞아야 연결을 구성할 수 있습니다.

노드Proxy entry: 프록시 연결 설정을 가리킬 때 흔히 쓰는 말로, 보통 서버 주소, 포트, 프로토콜, 인증 정보와 전송 매개변수가 포함됩니다. 노드 이름은 화면에 표시되는 라벨일 뿐, 위치나 대역폭, 사용 가능 여부를 보장하지 않습니다. 가져온 뒤 연결되지 않으면 목록에 이름이 보이는지만 확인하지 말고 설정이 완전한지, 커널이 해당 프로토콜을 지원하는지, 이 기기에서 서버에 접속할 수 있는지 살펴보세요.

Shadowsockstype: ss: 널리 쓰이는 프록시 프로토콜입니다. 설정에서는 보통 ss 유형을 사용하며 서버 주소, 포트, 암호화 방식, 비밀번호 등이 필요합니다. 클라이언트와 서버가 같은 암호화 방식을 지원하고 사용해야 하며, 일부 설정은 플러그인이나 추가 옵션에도 의존합니다. 프로토콜 이름이 같아도 모든 구현이 같은 확장 기능을 지원하는 것은 아니므로 설정을 옮길 때 항목별로 확인하세요.

VMesstype: vmess: 사용자 식별자 등의 매개변수로 인증하는 프록시 프로토콜이며, 다양한 전송 방식과 TLS 설정을 함께 사용할 수 있습니다. 가져오기에 성공했다는 것은 설정을 읽을 수 있다는 뜻일 뿐 식별자, 경로, 서버 이름이 올바르다는 보장은 아닙니다. 인증이나 핸드셰이크가 실패하면 서버 설정과 시스템 시간을 함께 확인하세요. DNS만 바꿔서는 인증 정보 불일치가 해결되지 않는 경우가 많습니다.

VLESStype: vless: 간단한 인증에 중점을 둔 프록시 프로토콜입니다. 자체적으로 전송을 암호화하지 않으며 TLS나 REALITY 같은 기능과 함께 사용하는 경우가 많습니다. 사용자 식별자를 입력하는 것만으로 연결되는 것은 아니며 전송 방식, 서버 이름, 핸드셰이크 매개변수도 맞아야 합니다. 커널 버전에 따라 지원되는 조합이 다를 수 있으므로 다른 클라이언트의 필드를 확인 없이 YAML에 붙여 넣지 마세요.

Trojantype: trojan: 일반적으로 TLS 연결을 사용하는 프록시 프로토콜입니다. 설정에는 보통 서버, 포트, 비밀번호, 서버 이름이 포함됩니다. 인증서 검증 오류는 이름 불일치, 인증서 체인 문제, 기기 시간 오류 때문일 수 있으므로 먼저 원인을 확인하세요. 인증서 검증을 건너뛰면 연결의 보안 조건이 달라지므로 모든 핸드셰이크 오류에 일괄 적용하지 마세요.

규칙과 라우팅

규칙은 연결의 경로를 판단하고 정책 그룹은 실제 출구를 정합니다. 설정을 반복해서 바꾸기보다 규칙 적용 기록을 확인하면 라우팅 문제를 더 쉽게 찾을 수 있습니다.

규칙 기반 라우팅rules / DOMAIN-SUFFIX / MATCH: 도메인이나 대상 IP 등의 조건에 따라 직접 연결, 프록시, 차단 등의 처리 방식을 선택하는 기능입니다. 규칙은 보통 위에서 아래로 확인하며, 일치하면 해당 정책을 실행합니다. 따라서 범위가 넓은 규칙이 앞에 있으면 뒤의 세부 규칙이 적용되지 않을 수 있습니다. 문제를 확인할 때는 먼저 규칙 모드인지 확인하고 어떤 규칙이 연결에 적용됐는지 살펴보세요. 기본 처리 규칙인 MATCH는 보통 목록 맨 아래에 둡니다.

정책 그룹proxy-groups: 여러 프록시나 정책을 하나의 출구로 묶어 규칙에서 일관된 그룹 이름을 참조하도록 합니다. select는 보통 사용자가 직접 선택하고, url-test는 테스트 결과에 따라 출구를 선택하며, fallback은 순서에 따라 사용 가능한 출구를 선택합니다. 자동 선택은 테스트 대상과 검사 주기에 따라 달라지며 실제 다운로드 속도가 가장 빠른 회선을 찾아준다는 뜻은 아닙니다.

규칙 세트rule-providers / RULE-SET: 여러 조건을 별도 파일에 모아 업데이트와 재사용을 쉽게 하는 방식입니다. 보통 rule-providers에 선언한 뒤 RULE-SET으로 참조합니다. 규칙 세트의 behavior와 format은 파일 내용과 일치해야 합니다. 리소스 다운로드에 성공해도 라우팅에 자동으로 적용되는 것은 아니므로 참조 이름, 규칙 순서, 대상 정책을 확인하세요.

GeoIPGEOIP: IP 지리정보 데이터베이스를 바탕으로 대상을 분류해 규칙을 적용하는 방식으로, 도메인 규칙이 다루지 못하는 연결을 보완하는 데 적합합니다. 데이터베이스에 표시된 지역이 서버의 실제 위치와 정확히 일치하는 것은 아니며 CDN, 주소 할당 변경, 데이터베이스 업데이트 시점이 결과에 영향을 줄 수 있습니다. 도메인 연결에 이 규칙을 적용하면 DNS 조회가 발생할 수 있습니다. no-resolve를 사용하면 규칙 매칭 때문에 발생하는 DNS 조회를 제한할 수 있지만, 장단점을 이해한 뒤 설정하세요.

지연 시간Latency / URL test: 클라이언트가 지정된 테스트 대상으로 연결을 확인하는 데 걸리는 시간을 나타냅니다. 구체적인 의미는 테스트 URL, 프로토콜, 연결 재사용, 네트워크 환경에 따라 달라집니다. 테스트 값이 낮다고 다운로드 속도가 빠르거나 특정 사이트에 접속할 수 있다고 단정할 수 없습니다. 같은 조건에서 비교한 뒤 실제 앱으로도 확인하세요. 결과가 이상하면 지연 시간 문제 해결 안내에 따라 항목별로 살펴보세요.

DNS와 네트워크 스택

트래픽이 커널로 들어가는지, 도메인을 어떤 DNS가 해석하는지, 해석 결과를 규칙에 어떻게 사용하는지는 서로 다른 문제입니다. 스위치 하나를 켜는 것만으로 전체 경로를 확인할 수는 없습니다.

TUN 모드tun: 가상 네트워크 인터페이스와 라우팅 설정으로 트래픽을 처리해 시스템 프록시를 따르지 않는 일부 앱의 연결도 다룰 수 있습니다. 추가 권한이 필요한 경우가 많으며, 실제 적용 범위는 자동 라우팅, 라우팅 제외 항목, 시스템 네트워크 환경에 따라 달라집니다. TUN을 켰다고 모든 DNS나 모든 앱의 트래픽을 처리하는 것은 아닙니다. 다른 VPN과 함께 사용할 때는 라우팅 충돌과 인터페이스 충돌을 특히 확인하세요.

DNSDomain Name System: 도메인을 IP 주소 등의 레코드로 변환하며, 해석 결과는 이후 규칙 판단에도 쓰일 수 있습니다. 운영체제 DNS, 클라이언트 내장 DNS, 브라우저 암호화 DNS는 서로 다른 경로를 사용할 수 있으므로 한 곳을 변경해도 다른 경로에는 영향이 없을 수 있습니다. 설정을 확인할 때는 DNS 서버 주소, DNS 요청의 전송 경로, 캐시를 구분하세요. 자세한 설정 순서는 전체 가이드의 DNS 장을 참고하세요.

Fake-IPenhanced-mode: fake-ip: 앱에 가상 주소를 반환하고 커널이 가상 주소와 도메인의 매핑을 관리하는 DNS 방식입니다. 이후 도메인 기반 라우팅을 적용하기 쉽습니다. 앱에 표시되는 가상 주소는 대상 서버의 실제 주소가 아니므로 서버 위치를 판단할 수 없습니다. 실제 DNS 응답에 의존하는 앱은 fake-ip-filter에 추가해야 할 수 있습니다. 설정을 바꾼 뒤에는 기존 캐시를 비우고 연결을 다시 설정하세요.

DNS 누출DNS leak: DNS 조회가 예상 경로를 벗어나 의도하지 않은 DNS 서버에 도달하는 현상입니다. 문제가 있는지 판단하려면 먼저 어떤 조회가 어떤 경로를 사용해야 하는지 정해야 합니다. TUN, Fake-IP, 암호화 DNS를 켰다고 해석 경로가 예상대로라고 단정할 수는 없습니다. 시스템 설정, 브라우저 자체 DNS, 클라이언트 로그, 테스트 결과를 함께 확인하세요. 테스트 페이지에 표시된 DNS 서버의 지역만으로 누출 여부를 판단할 수도 없습니다.

Redir-Hostenhanced-mode: redir-host: 보통 앱에 실제 DNS 응답 주소를 반환하는 DNS 강화 모드로, 가상 주소를 반환하는 Fake-IP 방식과 다릅니다. 실제 주소에 의존하는 일부 앱에는 더 적합할 수 있지만 도메인과 연결을 연결하는 조건도 달라집니다. 모드를 바꾼 뒤 운영체제나 앱에 이전 DNS 캐시가 남아 있을 수 있으므로 캐시를 지우거나 관련 앱을 다시 시작한 뒤 비교하세요.

설정 파일 필드

필드를 볼 때는 이름과 설정 위치, 단위를 함께 확인하세요. 같은 ‘업데이트 간격’처럼 보여도 전체 설정, 프록시 리소스, 상태 확인을 각각 제어할 수 있습니다.

YAMLconfig.yaml: Clash 설정에 자주 쓰이는 데이터 직렬화 형식입니다. 들여쓰기로 계층을 표시하고 키-값과 목록으로 필드를 구성합니다. 들여쓰기에는 탭이 아닌 공백을 사용하세요. 특수 문자가 포함된 문자열은 문법에 따라 따옴표로 감쌀 수 있습니다. YAML 문법이 올바르더라도 커널이 모든 필드를 인식하는 것은 아닙니다. 수정한 뒤에는 먼저 설정 검사 결과를 확인하고 적용하며, 원래 설정을 복구할 수 있도록 보관하세요.

moderule / global / direct: 커널의 작동 모드를 지정하는 최상위 필드입니다. 흔히 쓰는 값은 rule, global, direct이며 각각 규칙, 전역, 직접 연결 모드에 해당합니다. 커널에 들어온 연결의 경로를 정할 뿐 앱 트래픽을 자동으로 커널에 보내지는 않습니다. 전역 모드라고 시스템의 모든 앱이 프록시를 사용하는 것은 아니므로 시스템 프록시나 TUN이 대상 앱을 처리하는지 확인하세요.

proxy-providers프록시 리소스 제공자: 프록시 리소스의 출처를 선언하는 설정으로, 원격 주소나 로컬 파일에서 프록시 목록을 읽고 설정에 따라 새로고침합니다. 전체 설정 구독과는 다릅니다. 리소스 목록만으로 전체 규칙과 DNS 설정이 정해지는 것은 아니며, 불러온 뒤 정책 그룹에서 참조해야 합니다. 리소스 업데이트가 실패하면 주소 접속 가능 여부, 응답 형식, 로컬 캐시 경로, 참조 관계를 각각 확인하세요.

interval필드 위치와 시간 단위: 간격을 나타내지만 의미는 설정 위치에 따라 달라집니다. 제공자의 interval은 보통 리소스 새로고침 주기를, health-check.interval은 연결 상태 확인 주기를 제어하며 일반적으로 단위는 초입니다. 클라이언트의 전체 설정 업데이트 화면은 분을 단위로 사용할 수 있으므로 숫자를 그대로 옮기면 안 됩니다. 간격을 줄여도 형식이나 인증 오류는 해결되지 않습니다. 업데이트가 실패하면 먼저 구독 업데이트 문제 해결을 확인하세요.

mixed-portHTTP / SOCKS 공용 수신 포트: 하나의 포트에서 HTTP와 SOCKS 프록시를 제공해 앱이 공통 로컬 수신 포트를 사용하도록 합니다. 다른 프로그램이 해당 포트를 사용 중이면 커널이 수신을 시작하지 못할 수 있으므로 로그를 확인하세요. 시스템 프록시 주소만 바꾸는 것으로는 해결되지 않을 수 있습니다. 로컬 네트워크에서 사용하려면 수신 주소, 방화벽, 접근 제어도 설정해야 하며 다른 기기에 포트 번호만 입력한다고 접속이 완료되는 것은 아닙니다.