설정 읽기 / 항목 비교

Clash 용어 정리

클라이언트부터 네트워크 스택까지, 각 용어의 이름과 용도, 적용 조건을 구분해 보세요. 먼저 용어를 확인한 다음 실행 설정과 비교하면 됩니다.

커널과 클라이언트

커널은 연결을 처리하고, 클라이언트는 조작 인터페이스를 제공하며, 시스템 설정은 앱이 프록시에 연결되는 방식을 결정합니다. 문제를 해결할 때는 먼저 이 세 계층을 구분하세요.

Clash 커널Proxy engine: 커널은 설정을 읽고 프록시 연결을 수립하며 규칙 매칭과 DNS 처리를 담당하는 네트워크 엔진입니다. GUI는 커널을 관리하는 여러 방법 중 하나일 뿐입니다. 원본 Clash와 이후 파생 커널은 지원하는 설정 항목이 완전히 같지 않습니다. 이전 설정을 가져올 수 있어도 모든 기능이 적용되는 것은 아닙니다. 설정 항목 오류가 발생하면 현재 실행 중인 커널을 먼저 확인한 뒤 해당 커널의 설정 문서를 살펴보세요.

mihomoFormerly Clash Meta: mihomo는 Clash Meta 프로젝트를 이어받아 개발된 오픈소스 프록시 커널로, 규칙 기반 라우팅, TUN, Fake-IP, 다양한 프로토콜을 지원합니다. 독립 실행할 수도 있고 Clash Verge Rev 같은 GUI 클라이언트에서 실행할 수도 있습니다. 클라이언트를 비교할 때는 인터페이스와 커널 호환성을 따로 살펴보세요. 제품명에 Clash가 들어가는지만으로 판단해서는 안 됩니다.

GUI 클라이언트GUI client: GUI 클라이언트는 구독 가져오기, 프록시 그룹 전환, 로그 확인, 시작 시 자동 실행 등 일상적인 작업을 지원하며, 일반적으로 커널 프로세스와 시스템 프록시도 관리합니다. 화면의 스위치는 먼저 클라이언트 자체 설정에 저장된 뒤 실행 설정에 반영될 수 있어, 원본 구독 파일에서 같은 이름의 항목을 찾지 못할 수도 있습니다. 운영체제별 클라이언트 목록을 확인하고 원하는 기능의 설정 위치를 살펴보세요.

시스템 프록시System proxy: 시스템 프록시는 운영체제가 앱에 제공하는 프록시 주소 설정으로, 보통 로컬 커널이 수신하는 HTTP 또는 SOCKS 포트를 가리킵니다. 브라우저처럼 이 설정을 따르는 앱은 프록시를 사용하지만, 직접 네트워크 연결을 만들거나 시스템 설정을 무시하는 프로그램은 사용하지 않을 수 있습니다. 시스템 프록시를 켠 뒤에도 일부 앱이 직접 연결된다면 노드가 고장 난 것이 아닐 수 있습니다. 앱 자체의 프록시 설정을 확인하거나 TUN으로 트래픽을 처리하는 방법을 알아보세요.

혼합 포트mixed-port: mixed-port는 HTTP와 SOCKS 프록시 연결을 모두 받는 로컬 수신 포트를 지정합니다. 흔히 7890을 예시로 들지만 반드시 이 번호를 사용해야 하는 것은 아닙니다. 앱에 입력한 포트는 커널 설정과 일치해야 하며, 같은 주소의 포트를 다른 프로세스가 사용 중이어서는 안 됩니다. 원격 노드 포트가 아닌 로컬 연결 지점입니다. 자세한 설정은 포트 설정을 확인하세요.

프록시 프로토콜

프로토콜은 연결을 수립하는 방식을 정합니다. 서버 주소, 인증 정보, 전송 방식, 인증서 설정을 함께 확인해야 합니다.

노드Proxy outbound: 노드는 프록시 아웃바운드에 필요한 설정 묶음으로, 일반적으로 server, port, type과 인증 정보를 포함하며 proxies에 정의할 수 있습니다. 노드 이름은 설정에서 구분하기 위한 식별자일 뿐, 서버 위치나 대역폭, 사용 가능 여부를 보장하지 않습니다. 노드와 프록시 그룹도 다른 개념입니다. 노드는 연결을 정의하고 프록시 그룹은 사용할 아웃바운드를 선택합니다.

Shadowsockstype: ss: Shadowsocks는 암호화 프록시 프로토콜입니다. mihomo에서는 type: ss로 지정하며, 보통 암호화 방식인 cipher와 비밀번호가 필요합니다. 암호화 방식, 서버 포트, 비밀번호는 서버 설정과 일치해야 하며, 추가 플러그인 매개변수가 필요한 구성도 있습니다. 주소와 포트만 복사해서는 가져오기를 완료할 수 없습니다. 프로토콜 설정이 빠지면 연결이나 핸드셰이크에 실패할 수 있습니다.

VMesstype: vmess: VMess는 UUID로 사용자를 식별하는 프록시 프로토콜입니다. 설정 유형은 vmess이며 WebSocket 같은 전송 방식을 함께 사용할 수 있습니다. uuid 외에도 network, TLS, 요청 경로, 호스트 이름 등의 항목을 확인해야 합니다. 전송 방식별 설정을 임의로 섞어 쓰지 마세요. 인증이나 핸드셰이크 오류가 발생하면 표시 이름을 계속 바꾸기보다 노드 설정 전체를 대조해야 합니다.

VLESStype: vless: VLESS는 설정에서 type: vless로 지정하는 경량 프록시 프로토콜이며, 보통 UUID로 사용자를 식별합니다. 프로토콜 자체는 트래픽을 암호화하지 않으므로 TLS, REALITY 등 실제 보안 설정을 확인해야 합니다. 서버 이름, 전송 방식, 인증 매개변수도 그대로 유지해야 합니다. 다른 프로토콜 설정에서 유형 이름만 바꿔 사용하는 것은 적절하지 않습니다.

Trojantype: trojan: Trojan은 일반적으로 TLS를 통해 전송하고 비밀번호로 인증하는 프로토콜이며, 설정에서는 type: trojan으로 지정합니다. 비밀번호뿐 아니라 올바른 sni와 서버 인증서가 필요할 수 있고, 구성에 따라 별도의 전송 설정을 사용하기도 합니다. 인증서 오류가 발생하면 먼저 시스템 시간, 서버 이름, 설정 출처를 확인하세요. 인증서 검증을 끄는 것은 장기적인 해결책으로 권장하지 않습니다.

규칙과 라우팅

규칙은 연결을 매칭하고, 프록시 그룹은 아웃바운드를 선택합니다. 연결이 어디로 향하는지는 모드와 규칙 순서, 그룹에서 선택한 항목에 따라 결정됩니다.

규칙 기반 라우팅mode: rule / rules: 규칙 모드에서는 rules를 위에서 아래로 확인해 연결을 매칭합니다. 규칙에 걸리면 지정된 아웃바운드나 프록시 그룹을 사용합니다. 구체적인 도메인 규칙은 기본 처리용 MATCH보다 앞에 두어야 합니다. 예를 들어 DOMAIN-SUFFIX,example.com,DIRECT는 해당 도메인과 하위 도메인을 직접 연결합니다. DIRECT는 해당 연결의 아웃바운드 선택일 뿐 클라이언트를 종료하지 않습니다. 글로벌 모드에서는 규칙 모드와 같은 방식으로 연결 경로를 판단할 수 없습니다.

GeoIPGEOIP: GeoIP는 대상 IP의 데이터베이스상 지리적 위치를 기준으로 매칭합니다. 예를 들어 GEOIP,CN,DIRECT와 같이 설정할 수 있습니다. 데이터 업데이트와 대상 주소에 따라 결과가 달라지며, CDN이나 여러 지역에 분산된 서버, 데이터베이스 오류로 예상과 다른 결과가 나올 수 있습니다. no-resolve를 추가하면 규칙이 도메인 조회를 직접 유발하지 않도록 할 수 있지만, 연결에 사용할 수 있는 IP가 없으면 이 조건으로 매칭되지 않을 수도 있습니다.

GeoSiteGEOSITE: GeoSite는 미리 분류해 둔 도메인 목록으로 서비스나 사이트를 매칭합니다. IP의 지리적 위치를 기준으로 하는 GeoIP와는 다릅니다. 규칙에서 사용하는 분류 이름은 실제로 불러온 데이터에 포함되어 있어야 하며, 데이터 출처에 따라 제공되는 태그와 도메인 범위가 달라질 수 있습니다. 실시간 사이트 분류 서비스가 아니므로 도메인이 매칭되지 않으면 노드만 바꾸기보다 데이터 내용과 업데이트 상태, 앞선 규칙을 확인하세요.

규칙 세트rule-providers / RULE-SET: 규칙 세트는 많은 매칭 조건을 별도 파일로 관리합니다. rule-providers로 파일을 불러온 뒤 RULE-SET 규칙으로 참조합니다. 제공자의 behavior에 따라 내용을 해석하는 방식이 달라지며, 일반적인 유형으로 domain, ipcidr, classical이 있습니다. 규칙 세트는 매칭 조건을 제공할 뿐이며, 실제 아웃바운드와 우선순위는 기본 설정의 rules에서 결정됩니다.

프록시 그룹proxy-groups: 프록시 그룹은 proxy-groups에서 정의하는 아웃바운드 선택 로직으로, 노드나 다른 그룹, 내장 아웃바운드를 포함할 수 있습니다. select는 직접 선택할 때, url-test는 테스트 결과에 따라 자동 선택할 때, fallback은 사용 가능 여부에 따라 대체 경로를 선택할 때 사용합니다. 자동 선택이 모든 용도에 적합한 것은 아니며 테스트 주소와 조건에 따라 결과가 달라집니다. 실제 설정 방법은 프록시 그룹 선택 가이드를 확인하세요.

DNS와 네트워크 스택

도메인 해석, 트래픽 처리, 아웃바운드 선택은 각각 다른 단계입니다. TUN과 Fake-IP는 함께 사용할 수 있지만 서로 대체할 수는 없습니다.

DNSDomain Name System: DNS는 도메인을 IP 주소 등의 레코드로 변환합니다. mihomo에서는 dns 항목에서 상위 DNS 서버와 처리 방식을 설정할 수 있습니다. nameserver는 일반 조회에 사용할 DNS 서버를 지정하고, proxy-server-nameserver는 프록시 서버 도메인을 조회할 때 별도로 사용할 수 있습니다. DNS 설정을 추가했다고 모든 조회가 커널을 거치는 것은 아니므로, 운영체제와 브라우저, TUN의 실제 해석 경로도 확인해야 합니다.

Fake-IPdns.enhanced-mode: fake-ip: Fake-IP는 도메인 조회에 매핑 주소를 반환합니다. 이후 연결이 커널에 도달하면 매핑 정보를 이용해 도메인을 복원하고 규칙을 매칭합니다. dns.enhanced-mode: fake-ip로 활성화하며, 반환된 주소는 웹사이트의 실제 서버 주소가 아닙니다. 실제 DNS 응답에 의존하는 앱은 호환성을 고려해 fake-ip-filter를 설정할 수 있습니다. 필터링 방식부터 이해한 뒤 사용하고, 모든 도메인을 무조건 제외하지는 마세요.

TUN 모드tun.enable / auto-route: TUN은 가상 네트워크 어댑터와 라우팅 설정을 통해 더 많은 앱의 트래픽을 커널로 전달하므로 시스템 프록시를 따르지 않는 프로그램에 유용합니다. tun.enable은 활성화 항목이며, auto-route와 stack 등의 설정도 트래픽 처리 방식에 영향을 줍니다. 일반적으로 서비스 모드나 시스템 권한이 필요합니다. 트래픽이 커널에 들어온 뒤에는 모드와 규칙에 따라 라우팅되므로, TUN을 켰다고 모든 연결이 원격 프록시를 거치는 것은 아닙니다.

도메인 스니핑sniffer: 도메인 스니핑은 HTTP, TLS, QUIC 등 지원되는 프로토콜의 핸드셰이크 정보에서 도메인을 추출해 대상 IP만 있는 연결에도 도메인 규칙을 적용하도록 돕습니다. sniffer 설정으로 제어하며, 인식 여부는 트래픽 형식과 커널 지원에 따라 달라집니다. 애플리케이션 본문을 복호화하는 기능은 아닙니다. 원래 대상과 스니핑한 도메인이 다르다면 설정을 바꾸기 전에 override-destination의 역할을 확인하세요.

DNS 누수DNS leak: DNS 누수는 조회가 의도한 경로를 따르지 않고 통신사나 다른 DNS 해석기로 전달되는 현상을 말합니다. 웹 연결이 프록시를 통해 전달된다는 사실만으로 DNS 조회도 같은 경로를 사용한다고 볼 수는 없습니다. 브라우저의 보안 DNS, IPv6, 다른 네트워크 도구가 테스트 결과에 영향을 줄 수 있습니다. 점검할 때는 확인 페이지와 시스템 DNS, 브라우저 설정, 커널 로그를 함께 살펴보고 DNS 해석기와 실제 조회 전송 경로를 구분하세요.

구독과 설정

구독은 설정 내용을 제공하고, 클라이언트는 이를 가져와 병합하며, 커널은 최종 설정을 실행합니다. 업데이트 전후에 설정이 교체되는지, 로컬 수정 사항이 유지되는지 확인하세요.

구독Subscription: 구독은 클라이언트가 설정이나 노드 목록을 주기적으로 가져오는 URL인 경우가 많습니다. 전체 Clash YAML을 반환할 수도 있고 Base64로 인코딩된 노드 링크를 제공할 수도 있습니다. 두 형식이 같은 가져오기 메뉴에서 지원되지는 않을 수 있으므로 클라이언트가 지원하는 형식인지 확인하세요. 링크에 접근 자격 정보가 포함될 수 있으니 민감한 정보로 취급하고, 화면을 공개하거나 신뢰할 수 없는 변환 서비스에 붙여 넣지 마세요. 업데이트에 실패해도 기존 노드가 바로 사용할 수 없게 되는 것은 아닙니다.

YAMLconfig.yaml: YAML은 Clash 설정에 널리 쓰이는 텍스트 직렬화 형식으로, 들여쓰기로 계층을 표현하며 목록 항목은 보통 -로 시작합니다. 편집할 때는 탭 대신 공백을 사용하고 항목의 들여쓰기 단계를 유지하세요. 특수 문자는 따옴표로 감싸야 할 수 있습니다. 문법이 파싱된다는 것은 텍스트 구조가 유효하다는 뜻일 뿐, 현재 커널이 해당 항목을 지원하거나 프록시 그룹 이름과 규칙 참조가 일치한다는 뜻은 아닙니다.

프록시 제공자proxy-providers: proxy-providers는 노드 목록을 별도로 관리하는 기능입니다. 가져올 주소, 캐시 경로, 업데이트 주기, 상태 확인을 설정할 수 있으며 프록시 그룹에서 use로 참조합니다. 전체 설정 구독과 달리 노드 목록을 업데이트하면서 기본 설정의 라우팅 구조를 유지할 수 있습니다. 프록시 제공자는 아웃바운드를 제공하고 rule-providers는 매칭 조건을 제공하므로 서로 바꿔 쓸 수 없습니다.

로컬 오버라이드Local override / merge: 로컬 오버라이드는 원격 구독에 로컬 설정을 병합하거나 수정하는 방식으로, 포트, DNS, TUN, 사용자 지정 규칙을 유지할 때 주로 사용합니다. 클라이언트에 따라 메뉴 이름이 오버라이드, 병합, 스크립트 등으로 다를 수 있으며, 목록을 교체하거나 추가하는 방식도 다릅니다. 내려받은 구독 파일을 직접 수정하면 다음 업데이트에서 덮어쓸 수 있으므로, 클라이언트가 지원하는 지속 설정 방식을 사용하고 편집기 내용만이 아니라 최종 실행 설정을 확인하세요.

노드 지연 시간Latency test / url-test: 클라이언트에 표시되는 지연 시간은 일반적으로 지정된 테스트 주소에 접속하는 데 걸린 시간입니다. DNS 조회, 연결 수립, 프로토콜 핸드셰이크가 포함될 수 있으며 ICMP Ping과 반드시 같지는 않습니다. 테스트 주소와 제한 시간, 네트워크 상태에 따라 결과가 달라지고, 수치가 낮다고 다운로드 속도가 더 빠른 것도 아닙니다. 노드를 비교할 때는 가능한 한 동일한 조건으로 테스트한 뒤 실제 사용 환경에서도 확인하세요. 시간 초과는 이번 테스트가 완료되지 않았다는 뜻일 뿐, 모든 서비스에 접속할 수 없다는 증거는 아닙니다.

외부 컨트롤러external-controller: external-controller는 커널 관리 API가 수신할 주소를 지정합니다. 대시보드에서 연결을 조회하거나 프록시 그룹을 전환하고 일부 실행 상태를 변경할 때 사용할 수 있습니다. HTTP나 SOCKS 프록시 연결 지점이 아니므로 앱의 프록시 설정에 이 포트를 입력하면 안 됩니다. 일반적으로 로컬에서만 접근하도록 제한하세요. 원격 관리가 필요하다면 수신 범위, 인증, 방화벽을 함께 고려해야 하며, 연결 편의를 위해 공개 네트워크에 그대로 노출해서는 안 됩니다.