Clash / mihomo · 용어 색인

Clash 용어 정리

구독과 노드부터 규칙 기반 라우팅, TUN, 설정 항목까지 살펴봅니다. 각 용어가 속한 계층을 기준으로 찾아보고, 먼저 역할을 구분한 뒤 어떤 설정을 변경할지 판단하세요.

이 페이지에는 용어 25개가 정리되어 있습니다. 용어 카드 제목 옆의 링크를 누르면 해당 항목으로 이동하므로 저장하거나 인용하기 편리합니다.

코어, 설정, 연결 대상

핵심 개념

클라이언트는 조작 화면을 제공하고, 코어는 네트워크 처리를 수행하며, 구독은 설정 내용을 제공합니다. 이들은 서로 다른 대상입니다.

mihomo 코어 #mihomo core: mihomo는 프록시 연결, DNS 처리, 규칙 매칭을 담당하는 네트워크 코어로, Clash Meta의 기술 방향을 이어갑니다. 그래픽 클라이언트는 구독 관리와 UI, 시스템 설정을 담당하고, 코어는 실제 실행 설정을 처리합니다. 특정 프로토콜이나 항목을 사용할 수 있는지 확인하려면 클라이언트 이름만 볼 것이 아니라 실제로 통합된 코어 버전을 확인해야 합니다.

구독 #Subscription: 구독은 보통 원격 노드나 전체 설정을 가져오는 데 사용하는 주소이며, 프록시 연결 자체와는 다릅니다. 응답 내용은 YAML 설정일 수도 있고 노드 목록만 포함할 수도 있으므로 클라이언트에서 지원하는 형식인지 확인해야 합니다. 구독을 갱신하면 기존 내용이 바뀔 수 있으니, 계속 유지할 수정 사항은 클라이언트가 지원하는 오버라이드 위치에 저장하세요. 구독 주소에는 인증 정보가 포함되는 경우가 많으므로 공개적으로 공유하지 마세요.

노드 #Proxy node: 노드는 프록시 서버와 연결 방식을 나타내는 매개변수 모음으로, 보통 주소, 포트, 프로토콜, 인증 정보를 포함합니다. 노드 이름에 붙은 지역 표기는 라벨일 뿐 실제 출구 위치나 경로를 증명하지 않습니다. 노드를 선택할 때는 이름이나 한 번의 속도 테스트에만 의존하지 말고 실제 서비스 연결 여부, 출구 IP, 지속적인 전송 성능을 함께 확인하세요.

설정 파일 #Profile / config.yaml: 설정 파일에는 프록시, 프록시 그룹, 규칙, DNS 등의 네트워크 설정이 저장되며, 흔히 사용하는 파일 이름은 config.yaml입니다. Profile은 보통 클라이언트가 관리하는 설정 항목을 뜻하며 로컬 파일이나 원격 구독에서 가져올 수 있습니다. 최종 실행 설정은 병합, 오버라이드, UI 옵션의 영향을 받을 수 있으므로 원본 파일을 편집한 뒤 수정 내용이 현재 실행 설정에 반영됐는지 확인하세요.

지연 시간 #Latency / URL test: 클라이언트에 표시되는 지연 시간은 보통 노드를 통해 지정된 테스트 주소에 접속하는 데 걸린 시간이며, ICMP ping 결과가 아닐 수도 있습니다. 테스트 대상, 연결 재사용, 시간 제한, 당시 네트워크 상태가 모두 수치에 영향을 줍니다. 지연 시간이 낮다고 다운로드 속도가 빠른 것은 아니며, 테스트가 시간 초과됐다고 모든 사이트에 접속할 수 없는 것도 아닙니다. 대상 서비스와 연결 로그를 추가로 확인하세요.

노드와 서버 간 데이터 전송 방식

프록시 프로토콜

프로토콜 이름에 따라 연결 매개변수의 해석 방식이 달라집니다. 클라이언트와 서버에서 같은 프로토콜을 지원해야 하며, 이름을 바꾸는 것만으로 프로토콜을 변환할 수는 없습니다.

Shadowsocks #SS: Shadowsocks는 암호화 프록시 프로토콜로, 노드에는 보통 서버 주소, 포트, 암호화 방식, 비밀번호를 입력해야 합니다. 양쪽에서 호환되는 암호화 방식을 사용해야 하며, 일부 방식은 키 형식도 맞춰야 합니다. UDP 지원 여부와 플러그인 필요 여부는 별도의 기능과 설정이므로 Shadowsocks라는 이름만으로 설정이 완전한지 판단할 수 없습니다.

VMess와 VLESS #VMess / VLESS: VMess와 VLESS는 서로 다른 프로토콜입니다. 흔히 두 프로토콜의 설정에 UUID가 포함되지만 인증 및 전송 요구 사항은 같지 않습니다. VLESS 자체는 데이터를 암호화하지 않으며, 실제 보안 수준은 TLS, REALITY 등의 전송 보안 설정에 따라 달라집니다. 가져올 때는 전송 유형, 서버 이름, 경로 등의 매개변수도 확인해야 하며, 노드 유형의 이름만 바꿔 사용할 수는 없습니다.

Trojan #TLS-based proxy protocol: Trojan은 보통 TLS로 프록시 데이터를 전송하고 비밀번호로 인증합니다. 연결에는 인증 매개변수뿐 아니라 서버 인증서, 서버 이름, 네트워크 연결 가능 여부도 영향을 줍니다. 인증서 오류가 발생하면 먼저 도메인, 시스템 시간, 서버 인증서를 확인하세요. 인증서 검증을 건너뛰는 방법을 일반적인 해결책으로 사용해서는 안 됩니다.

Hysteria2 #QUIC-based proxy protocol: Hysteria2는 QUIC 기반 프록시 프로토콜로, 하위 네트워크의 UDP 연결에 의존합니다. 클라이언트와 서버 모두 2세대 프로토콜을 지원해야 하며, 1세대 설정이 호환된다고 볼 수 없습니다. 대역폭 매개변수, 혼잡 제어, 네트워크 제한이 성능에 영향을 줍니다. 대역폭 수치를 높게 입력해도 실제 네트워크 용량이 늘어나지는 않습니다.

TUIC #QUIC transport: TUIC는 QUIC 기반 프록시 프로토콜로, TCP 및 UDP 프록시 트래픽을 전달하고 다중화를 통해 연결을 구성할 수 있습니다. 사용할 때는 프로토콜 버전, 인증 정보, 서버 매개변수가 일치하는지 확인해야 합니다. 하위 네트워크에서 UDP를 제한하면 연결이 설정되지 않을 수 있으므로, QUIC 지원이 모든 네트워크에서 더 빠르거나 안정적이라는 뜻은 아닙니다.

매칭 조건과 대상 정책

규칙 및 라우팅

규칙은 연결이 어떤 조건에 일치하는지 정하고, 정책은 연결을 어디로 보낼지 정합니다. 라우팅 문제를 확인할 때는 먼저 일치한 규칙을 보고, 다음으로 최종 선택된 노드를 확인하세요.

규칙 기반 라우팅 #Rule-based routing: 규칙 기반 라우팅은 도메인, 대상 IP, 포트, 프로세스 등의 조건에 따라 코어에 들어온 연결의 처리 정책을 선택합니다. 규칙은 보통 위에서 아래로 매칭되며, 먼저 일치하는 유효한 규칙이 연결 경로를 결정합니다. 따라서 구체적인 조건을 포괄적인 조건보다 앞에 두는 것이 일반적입니다. 규칙을 추가한 뒤에는 설정 파일이 저장됐는지만 볼 것이 아니라 연결 기록에서 실제로 어떤 규칙이 적용됐는지 확인하세요.

프록시 그룹 #proxy-groups: 프록시 그룹은 여러 노드나 다른 프록시 그룹을 하나의 정책 진입점으로 묶으므로, 규칙이 특정 노드에 직접 연결되지 않아도 됩니다. select는 직접 선택할 때, url-test는 테스트 결과에 따라 자동 선택할 때 사용하며 두 방식의 결정 과정은 다릅니다. 규칙에서 참조하는 그룹 이름이 실제로 존재해야 하며, 그룹 내에서 사용할 수 있는 노드는 구성원 노드와 테스트 대상에 따라 달라집니다.

GeoIP #IP geolocation database: GeoIP는 IP 지리 정보 데이터베이스를 사용해 대상 주소를 판별합니다. 예를 들어 GEOIP,CN,DIRECT는 해당 주소와 일치하는 연결을 직접 연결 정책으로 전달한다는 뜻입니다. 데이터베이스 업데이트가 늦을 수 있으며, IP 귀속 정보가 서비스 소유자의 소재지를 뜻하지는 않습니다. 도메인 연결에 IP 규칙을 적용하면 DNS 조회가 발생할 수도 있습니다. no-resolve를 사용하면 이런 능동적인 조회를 제한할 수 있습니다.

규칙 세트 #rule-providers / RULE-SET: 규칙 세트는 여러 도메인, IP 또는 일반 규칙을 모아 관리하므로 별도로 업데이트하고 재사용하기 편리합니다. rule-providers에서 정의한 뒤 RULE-SET으로 규칙 목록에서 참조하고 대상 정책을 지정할 수 있습니다. 데이터 형식은 behavior와 일치해야 합니다. 규칙 세트의 업데이트 성공 여부도 따로 확인해야 하며, 기본 구독의 업데이트 시각만으로 판단해서는 안 됩니다.

DIRECT, REJECT 및 MATCH #Built-in policies / final rule: DIRECT와 REJECT는 각각 직접 연결과 연결 거부를 뜻하는 기본 정책입니다. MATCH는 나머지 모든 연결과 일치하는 규칙 유형이며 노드나 프록시 그룹이 아닙니다. 자주 사용하는 MATCH,PROXY는 남은 연결을 PROXY라는 정책으로 전달한다는 뜻이며, 해당 이름이 설정에 실제로 존재해야 합니다.

트래픽 처리와 도메인 조회

네트워크 모드

시스템 프록시와 TUN은 트래픽이 코어에 들어오는 방식을 정하고, 규칙 모드와 전역 모드는 들어온 트래픽의 처리 방식을 정합니다. DNS도 별도로 확인해야 합니다.

시스템 프록시 #System proxy: 시스템 프록시는 시스템이나 앱에 로컬 HTTP 또는 SOCKS 프록시 진입점을 제공합니다. 해당 설정을 따르는 프로그램만 이를 사용합니다. 일부 터미널 도구는 환경 변수를 읽고, 일부 앱은 자체 프록시 옵션을 사용합니다. 시스템 프록시를 켠 뒤에도 특정 프로그램이 직접 연결한다면, 규칙이 작동하지 않는다고 단정하기 전에 해당 프로그램이 어떤 네트워크 설정을 사용하는지 확인하세요.

TUN 모드 #Virtual network interface: TUN 모드는 가상 네트워크 인터페이스와 라우팅 설정을 통해 더 많은 IP 트래픽이 코어에서 처리되도록 합니다. 특정 앱의 트래픽을 처리할 수 있는지는 권한, 라우팅, 제외 항목, DNS 설정에 따라 달라지므로 켰다고 해서 모든 연결이 반드시 포함되는 것은 아닙니다. 규칙 모드와 함께 사용할 수 있습니다. 다른 VPN과 충돌하면 노드를 반복해서 바꾸기보다 라우팅과 인터페이스부터 확인하세요.

규칙 모드, 전역 모드, 직접 연결 모드 #rule / global / direct: 규칙 모드는 rules에 따라 트래픽을 라우팅하고, 전역 모드는 코어에 들어온 트래픽을 전역 선택기로 전달하며, 직접 연결 모드는 직접 연결 정책을 사용합니다. 전역 모드에서도 전역 선택기에서 적절한 노드나 정책을 선택해야 프록시를 통해 나갈 수 있습니다. 이 모드들은 코어에 들어오지 않은 앱 트래픽을 자동으로 처리하지 않으며, 시스템 프록시나 TUN 설정을 대신하지도 않습니다.

DNS 누수 #DNS leak: DNS 누수는 도메인 조회 요청이 사용자가 설정한 조회 방식에서 벗어나 의도하지 않은 경로를 통해 DNS 리졸버로 전송되는 현상을 말합니다. 시스템 DNS, 브라우저 내장 DoH, 앱 자체 조회 방식이 실제 경로를 바꿀 수 있습니다. 검사 사이트에 표시되는 리졸버 위치는 참고 정보일 뿐입니다. 지역 이름만으로 결론을 내리지 말고 DNS 설정, 조회 방식, 연결 기록을 함께 확인하세요.

Fake-IP #Synthetic DNS address: Fake-IP는 DNS 조회에 가상 주소를 할당한 뒤 연결이 코어에 들어올 때 원래 도메인으로 매핑해 도메인 식별과 라우팅을 돕습니다. 이 주소는 대상 서버의 실제 IP가 아니므로, 가상 주소가 보인다고 해서 DNS 조회에 문제가 있는 것은 아닙니다. 실제 주소에 의존하는 앱은 fake-ip-filter에 추가해야 할 수 있습니다. 문제를 확인할 때는 시스템과 앱에 남아 있는 오래된 DNS 캐시도 살펴보세요.

실행 설정에서 자주 쓰는 항목

설정 항목

설정 항목 이름은 원문 그대로 유지해야 합니다. 수정하기 전에 원본 구독, 클라이언트 오버라이드, 최종 실행 설정을 구분해 적용되지 않는 파일을 편집하지 않도록 하세요.

YAML #Configuration syntax: YAML은 구조화된 텍스트 형식입니다. Clash 설정은 들여쓰기로 객체 계층을 나타내고 하이픈으로 목록 항목을 표시합니다. 들여쓰기에는 공백을 사용하고 수준을 일관되게 유지해야 하며, 특수 문자가 포함된 문자열은 따옴표로 감싸야 할 수 있습니다. 문법 분석에 성공해도 의미가 올바른 것은 아닙니다. 항목 이름의 오타, 중복 키, 존재하지 않는 정책 참조는 설정 로드 실패나 예상과 다른 동작을 일으킬 수 있습니다.

mixed-port #Mixed HTTP / SOCKS listener: mixed-port는 HTTP와 SOCKS 프록시 요청을 모두 받는 로컬 수신 포트를 설정하며, 원격 노드의 서버 포트와는 다릅니다. 브라우저, 터미널, 기타 앱에서 프록시를 직접 설정할 때는 현재 실행 설정과 일치하는 주소와 포트를 입력해야 합니다. 다른 프로세스가 포트를 사용 중이면 수신에 실패할 수 있습니다. 문제 해결 방법은 Clash 포트 설정을 참고하세요.

proxy-providers #Proxy node providers: proxy-providers는 원격 주소나 로컬 파일에서 불러올 노드 모음을 정의하며, 프록시 그룹은 use로 해당 모음을 참조할 수 있습니다. 노드만 제공하는 기능이므로 규칙, DNS, 프록시 그룹을 포함한 전체 설정과는 다릅니다. 원격 콘텐츠는 제공자가 지원하는 구조를 따라야 합니다. 업데이트에 실패하면 콘텐츠 형식, 요청 주소에 접속할 수 있는지, 캐시 파일 상태를 확인하세요.

nameserver #Upstream DNS resolvers: nameserver는 dns 설정 아래에 있으며 내장 DNS가 사용할 상위 리졸버를 지정합니다. 실제 리졸버 선택에는 nameserver-policy 등의 항목이 영향을 줄 수 있으며, 노드 서버 도메인에는 별도의 조회 설정을 사용할 수도 있습니다. DoH 주소를 입력해도 모든 앱의 조회가 해당 리졸버를 통과하는 것은 아닙니다. 트래픽 처리 방식과 앱이 내장 DNS를 우회하는지 확인해야 합니다.

external-controller #Controller API listener: external-controller는 연결 상태를 확인하거나 정책을 전환하는 데 클라이언트 UI나 대시보드가 사용하는 코어 제어 인터페이스의 수신 주소를 설정합니다. 프록시 트래픽 진입점을 제공하는 mixed-port와는 용도가 다르므로 서로 대체할 수 없습니다. 일반적으로 로컬에서만 접근할 수 있도록 제한해야 합니다. 원격 관리가 꼭 필요한 경우 인증과 네트워크 접근 제한을 함께 설정하고, 인터넷에 그대로 공개하지 마세요.

Clash 최신 버전 다운로드