Clash
ClashClash는 처음에는 규칙에 따라 네트워크 트래픽을 처리하는 프록시 코어를 가리켰으며, 현재는 설정 형식과 클라이언트 생태계 전반을 뜻하기도 합니다. 원 프로젝트와 이후 포크는 관리 주체가 서로 다르며, 이름이 비슷하다고 기능까지 같은 것은 아닙니다. 가이드를 참고할 때는 문서에서 다루는 클라이언트, 코어, 설정의 작성 시점을 함께 확인하세요. 이름만으로 호환성을 판단할 수는 없습니다.
클라이언트별 차이 확인용어 빠른 검색 / 용어 25개
코어, 연결, 규칙, 설정 파일의 용어와 역할을 정리했습니다.
개념이 속한 계층별로 용어를 확인하세요. 영문 명칭은 클라이언트 인터페이스, 로그, YAML 필드와 대조할 때 유용합니다. 각 카드에는 저장하거나 공유할 수 있는 고유 앵커가 있습니다. 필드 지원 범위는 실제로 사용하는 코어와 버전에 따라 달라집니다. 구체적인 사용 방법은 빠른 시작 가이드, 매개변수 세부 정보는 YAML 핸드북을 참고하세요.
Kernel / Client
네트워크 처리를 담당하는 코어, 조작 인터페이스를 제공하는 클라이언트, 앱 트래픽이 프록시에 연결되는 방식을 먼저 구분하세요.
Clash는 처음에는 규칙에 따라 네트워크 트래픽을 처리하는 프록시 코어를 가리켰으며, 현재는 설정 형식과 클라이언트 생태계 전반을 뜻하기도 합니다. 원 프로젝트와 이후 포크는 관리 주체가 서로 다르며, 이름이 비슷하다고 기능까지 같은 것은 아닙니다. 가이드를 참고할 때는 문서에서 다루는 클라이언트, 코어, 설정의 작성 시점을 함께 확인하세요. 이름만으로 호환성을 판단할 수는 없습니다.
클라이언트별 차이 확인mihomo는 Clash Meta의 계보를 잇는 오픈소스 프록시 코어로, 프록시 연결, 규칙 매칭, DNS 등 저수준 작업을 담당합니다. 그래픽 인터페이스의 이름은 아니며, 그래픽 클라이언트 하나에서 코어를 바꿔 사용할 수도 있습니다. 특정 필드의 사용 가능 여부는 클라이언트 설치 파일 이름이 아니라 현재 실행 중인 코어와 버전으로 확인해야 합니다.
코어 설정 구조 확인그래픽 클라이언트는 설정 가져오기, 정책 선택, 연결 확인, 로그 보기 등의 인터페이스를 제공하고, 사용자 조작을 코어 설정이나 제어 요청으로 변환합니다. 시스템 프록시, 백그라운드 서비스, 설정 덮어쓰기를 관리하기도 하므로 인터페이스의 설정을 YAML 필드와 동일하게 볼 수는 없습니다. 같은 코어를 사용해도 클라이언트마다 설정 저장 위치와 업데이트 방식이 다를 수 있습니다.
클라이언트 선택 가이드 확인외부 제어 인터페이스를 통해 그래픽 인터페이스나 제어 패널에서 코어 상태를 확인하고, 정책을 전환하거나 연결을 살펴볼 수 있습니다. 이는 관리용 인터페이스이며 브라우저나 다른 앱이 프록시에 연결하는 트래픽 포트가 아닙니다. 관리 기능이 신뢰할 수 없는 네트워크에 노출되지 않도록 수신 범위를 제한하고 인증을 적용하세요. 인터페이스가 코어에 연결되지 않으면 인터페이스 주소와 인증 설정이 일치하는지 확인하세요.
공통 설정 필드 확인시스템 프록시는 운영체제가 앱에 제공하는 프록시 서버 설정으로, 모든 트래픽을 강제로 가져오는 기능은 아닙니다. 해당 설정을 따르는 앱만 지정된 프록시 포트에 연결하며, 자체적으로 네트워크에 접속하는 프로그램은 별도 설정이나 TUN이 필요할 수 있습니다. 활성화한 뒤에는 주소와 포트가 현재 코어 설정과 일치하는지 확인하세요. 클라이언트를 종료한 후에도 시스템에 작동하지 않는 프록시 설정이 남아 있지 않은지 살펴보세요.
프록시 연결 및 확인 절차 보기Protocol / Transport
노드는 연결 매개변수의 모음입니다. 프록시 프로토콜, 전송 방식, 암호화 핸드셰이크는 각각 서로 다른 단계를 제어합니다.
프록시 노드는 원격 연결 대상과 인증 방식을 지정하는 매개변수 모음으로, 일반적으로 프로토콜, 서버 주소, 포트, 인증 정보를 포함합니다. 노드 이름은 인터페이스에 표시하거나 정책에서 참조하는 용도일 뿐이며, 이름에 포함된 지역명만으로 실제 출구 위치를 알 수는 없습니다. 연결에 실패하면 노드 이름을 바꾸거나 같은 설정을 반복해서 가져오는 대신 전체 매개변수와 원격 서비스 상태를 확인해야 합니다.
프록시 노드 필드 확인프록시 프로토콜은 클라이언트와 서버가 데이터를 인증·캡슐화·전달하는 방식을 정합니다. 예를 들면 Shadowsocks, VMess, VLESS, Trojan이 있습니다. 프로토콜과 전송 방식은 서로 다른 계층의 개념이며, 같은 프로토콜도 전송 방식에 따라 구성이 달라질 수 있습니다. 노드의 type과 인증 필드는 해당 프로토콜의 요구 사항에 맞아야 합니다. 유형 이름만 바꿔서는 프로토콜을 변환할 수 없습니다.
전송 방식은 프록시 프로토콜의 데이터를 전달하는 연결 형태를 뜻하며, TCP, WebSocket, gRPC 등이 있습니다. 경로, 요청 헤더, 서비스 이름 등의 매개변수는 서버 설정과 일치해야 하며, 모든 프록시 프로토콜이 모든 전송 방식을 지원하는 것은 아닙니다. 설정을 옮길 때 서버와 인증 정보만 남기고 전송 옵션을 빠뜨리면 핸드셰이크 실패나 요청 시간 초과가 발생할 수 있습니다.
전송 관련 설정 확인TLS는 통신 암호화와 상대방 인증을 제공합니다. 인증서 검증 및 서버 이름 설정은 핸드셰이크 결과에 영향을 줍니다. 연결 대상 주소와 핸드셰이크에 사용하는 서버 이름이 서로 다를 수 있으므로, 서버 요구 사항에 맞게 입력해야 합니다. 임의로 바꾸지 마세요. 인증서 검증을 끄는 것은 연결 오류를 해결하는 일반적인 방법이 아닙니다. 시스템 시간과 인증서의 적용 도메인도 확인하세요.
TLS 설정과 관련 내용 확인클라이언트의 지연 시간 테스트는 보통 특정 출구를 통해 테스트 주소에 요청을 보내는 데 걸리는 시간을 측정합니다. ICMP 핑이나 다운로드 속도와는 다릅니다. 테스트 주소, 네트워크 경로, 핸드셰이크 과정, 시간 초과 기준에 따라 결과가 달라지므로 클라이언트별 수치를 직접 비교하기 어려울 수 있습니다. 시간 초과는 테스트가 제한 시간 안에 끝나지 않았다는 뜻일 뿐입니다. 로그와 실제 접속 결과를 함께 확인하며 단계적으로 문제를 살펴보세요.
연결 문제 FAQ 확인Policy / Rules
규칙은 연결을 처리할 대상을 정하고, 정책 그룹은 사용할 출구를 정합니다. 모드는 규칙에 따라 처리할지를 결정합니다.
정책 그룹은 노드나 다른 정책 그룹을 묶고, 그룹 유형에 따라 사용할 출구를 결정합니다. 수동 선택 그룹 select와 자동 속도 테스트 그룹 url-test는 선택 방식이 다르며, 인터페이스에 표시된 현재 노드가 계속 유지되는 것은 아닙니다. 규칙에서 그룹 이름을 지정하면 트래픽 분류와 출구 선택을 따로 관리할 수 있습니다. 참조하는 이름은 정의한 이름과 일치해야 합니다.
규칙 기반 트래픽 분기는 도메인, 대상 IP, 프로세스 등의 조건에 따라 연결 처리 방식을 선택합니다. 규칙은 보통 위에서 아래로 확인하며 가장 먼저 일치한 규칙이 적용됩니다. 따라서 세부 규칙은 적절한 위치에 두고, MATCH 같은 기본 규칙은 대개 목록 끝에 배치합니다. 트래픽 분기 결과를 확인할 때는 웹사이트 이름만으로 추측하지 말고 실제로 일치한 규칙과 최종 정책을 살펴보세요.
작동 모드는 코어가 규칙, 전역, 직접 연결 등의 기본 처리 방식 중 무엇을 사용할지 결정합니다. 규칙 모드는 규칙에 따라 정책을 선택하고, 전역 모드는 전역 정책을 적용하며, 직접 연결 모드는 기본적으로 프록시를 거치지 않고 연결합니다. 전역 모드라고 해서 모든 앱의 트래픽이 코어에 전달되는 것은 아닙니다. 트래픽이 처리되는지는 시스템 프록시, 앱 설정, TUN 라우팅에 따라 달라집니다.
모드 선택 절차 확인GeoIP 데이터는 IP 주소를 국가나 지역 등의 범주에 연결하며, IP 규칙의 매칭에 사용됩니다. 데이터베이스 갱신, 주소 할당, 콘텐츠 전송 네트워크에 따라 결과가 달라질 수 있으므로 웹사이트 운영 주체의 실제 위치를 정확히 나타내지는 않습니다. 도메인 규칙과 GeoIP 규칙이 서로 다른 결과를 낼 수 있습니다. 일치 원인을 파악하려면 규칙 순서, 실제로 조회된 주소, 데이터베이스 출처를 함께 확인하세요.
IP 규칙 대조규칙 세트는 여러 매칭 조건을 모아 관리합니다. rule-providers로 출처를 정의하고 RULE-SET 규칙에서 참조합니다. 규칙 세트는 노드 구독과 다르므로 두 주소를 서로 바꿔 쓸 수 없습니다. 내용과 형식, 매칭 방식은 선언과 일치해야 합니다. 규칙 세트를 참조해도 순차 매칭 방식은 그대로이므로 목록에서 먼저 일치하는 규칙이 우선 적용됩니다.
DNS / Network Stack
DNS 조회 경로와 트래픽 경로는 각각 확인해야 합니다. 특정 옵션을 켰다고 모든 앱이 같은 경로를 사용하는 것은 아닙니다.
DNS 조회는 도메인을 IP 주소 등의 레코드로 변환하며, 결과는 연결 대상과 일부 규칙 매칭에 영향을 줍니다. 코어, 앱, 운영체제가 각각 DNS 조회를 수행할 수 있으므로 실제 요청이 어떤 경로를 거치는지 먼저 확인해야 합니다. DNS 서버를 바꿔도 트래픽 출구가 반드시 바뀌는 것은 아닙니다. 한 계층의 캐시를 삭제해도 앱, 운영체제, 코어의 캐시가 모두 갱신되는 것은 아닙니다.
DNS 필드 확인Fake-IP 모드는 앱에 매핑용 가상 IP를 반환하고, 코어는 해당 매핑으로 도메인을 복원해 연결을 처리합니다. 가상 주소는 원격 서버의 실제 주소가 아니므로 시스템 DNS 조회 결과만으로 최종 연결 위치를 판단할 수 없습니다. 실제 DNS 결과에 의존하는 앱에는 예외 규칙이 필요할 수 있습니다. 조회 모드를 바꾼 뒤에는 앱 캐시와 기존 연결이 이전 주소를 계속 사용하는지도 확인하세요.
DNS 조회 모드 안내 확인DNS 누수는 도메인 조회가 예상한 경로를 벗어나 의도하지 않은 DNS 서버나 로컬 네트워크에 노출되는 현상을 말합니다. 판단할 때는 앱, 운영체제, IPv6, 코어 설정을 함께 살펴봐야 하며 출구 IP만으로 추정해서는 안 됩니다. 테스트 페이지에 표시된 DNS 서버 위치는 단서일 뿐입니다. 브라우저의 암호화 DNS, 시스템의 대체 DNS, 프록시 서버 도메인의 DNS 조회 등 각 경로도 확인해야 합니다.
DNS 설정 적용 범위 확인TUN 모드는 가상 네트워크 인터페이스와 라우팅 규칙을 통해 IP 트래픽을 코어에 전달하므로, 시스템 프록시를 따르지 않는 일부 프로그램의 트래픽도 처리할 수 있습니다. 실제로 전달되는 범위는 라우팅, 권한, 제외 항목, 다른 네트워크 소프트웨어와의 상호작용에 따라 달라집니다. 활성화한 뒤 네트워크가 끊기면 가상 인터페이스, 기본 경로, DNS 처리 상태를 확인하세요. 문제 원인을 파악하기 어려워지지 않도록 여러 옵션을 한꺼번에 바꾸지 마세요.
TUN 설정 확인스니핑은 규칙 매칭을 돕기 위해 연결 초기 데이터에서 도메인 정보를 추출합니다. 예를 들어 TLS 핸드셰이크의 서버 이름을 확인할 수 있습니다. 암호화된 본문을 복호화하는 기능은 아니며, 추출 가능한 정보는 프로토콜과 핸드셰이크 암호화 방식에 따라 제한됩니다. 활성화해도 모든 연결에서 도메인을 확인할 수 있는 것은 아닙니다. 연결 세부 정보에서 추출 결과를 확인하고, 특정 트래픽에 예외가 필요한지도 살펴보세요.
네트워크 관련 필드 확인Subscription / Configuration
원격 설정 출처, 텍스트 형식, 클라이언트 프로필, 최종 실행 설정을 구분해야 변경 사항이 어디에 적용되는지 알 수 있습니다.
구독은 보통 URL에서 노드나 설정을 가져와 주기적으로 갱신하는 방식입니다. 출처에 따라 전체 YAML, 노드 목록, 인코딩된 노드 링크 등이 반환될 수 있습니다. 구독 주소에 접근 인증 정보가 포함될 수 있으므로 공개하거나 공개 로그에 그대로 붙여 넣지 마세요. 가져오기 전에 클라이언트가 해당 형식을 지원하는지 확인하세요. 내용을 가져오는 데 성공해도 모든 노드의 연결이 보장되는 것은 아닙니다.
구독 가져오기 절차 확인YAML은 매핑, 목록, 스칼라 등의 데이터를 표현하는 텍스트 형식이며, Clash 설정은 YAML로 필드를 구성합니다. 들여쓰기에는 공백을 사용하고 같은 계층의 들여쓰기를 일관되게 유지해야 합니다. 특수 문자가 포함된 텍스트는 문법에 맞게 따옴표로 묶어야 합니다. 문법 검사를 통과했다는 것은 텍스트를 파싱할 수 있다는 뜻일 뿐, 필드 이름과 데이터 유형, 노드와 정책 그룹 사이의 참조가 코어 요구 사항에 맞는다는 뜻은 아닙니다.
YAML 구조 개요 확인설정 프로필은 클라이언트가 관리하는 로컬 또는 원격 설정 항목으로, 여러 설정을 전환할 때 사용할 수 있습니다. 편집기 내용, 클라이언트의 병합 결과, 코어가 실제로 불러온 내용은 서로 다를 수 있으며 파일을 저장해도 설정이 다시 로드되지 않을 수 있습니다. 변경 사항이 적용됐는지 확인하려면 현재 활성화된 프로필, 실행 로그, 클라이언트에서 제공하는 최종 설정 화면을 살펴보세요.
설정 활성화 절차 확인노드 제공자는 proxy-providers를 통해 별도의 노드 모음을 불러오고 정책 그룹에서 참조하므로, 노드 업데이트를 로컬 규칙과 분리해 관리할 수 있습니다. 이는 설정 메커니즘을 뜻하며 네트워크 서비스를 제공하는 업체와 같은 의미가 아닙니다. 제공자 파일은 전체 설정과 구조가 다르므로, DNS나 규칙 등의 최상위 필드가 포함된 구독을 노드 목록으로 그대로 사용할 수 있다고 가정해서는 안 됩니다.
설정 덮어쓰기는 기본 설정에 로컬 설정을 추가하거나 교체 또는 병합하며, 보통 클라이언트가 설정을 불러오기 전에 실행됩니다. DNS나 규칙을 별도로 조정할 때 유용합니다. 클라이언트마다 목록, 같은 이름의 필드, 실행 순서를 처리하는 방식이 다를 수 있으므로 모든 내용이 유지된다고 가정해서는 안 됩니다. 수정 후에는 최종 설정을 확인하고, 구독을 갱신하기 전에 변경 사항이 별도 덮어쓰기 설정에 저장되어 있는지도 확인하세요.
덮어쓰기 및 병합 안내 확인