CLASH / CONCEPT REFERENCE
코어, 프로토콜, 규칙, DNS, 구독 관련 개념을 설정 파일에서 찾아보세요. 이름은 비슷하지만 역할이 다른 설정도 구분할 수 있습니다.
처음 설정한다면 Clash 설정 가이드를 먼저 확인하세요. 프로토콜과 코어 기능을 비교하려면 프로토콜 참고 자료를 참조하세요. 이 페이지는 개념을 설명하며, 특정 클라이언트의 설정 안내를 대신하지 않습니다.
CORE & CLIENT
연결을 처리하는 코어와 인터페이스를 제공하는 앱부터 구분하세요.
Clash 생태계 초기에 사용된 규칙 기반 프록시 코어로, 연결 설정과 DNS 처리, 규칙 매칭을 담당합니다. 그래픽 인터페이스는 보통 다른 프로젝트에서 제공합니다. 원래의 오픈 소스 버전은 이후의 Meta, mihomo와 프로토콜 및 필드 지원이 다르므로, 이전 가이드의 기능이 모든 계열에서 작동한다고 볼 수 없습니다. 설정 파일의 사용 가능 여부는 클라이언트 이름에 Clash가 포함됐는지가 아니라 코어 유형을 확인해 판단해야 합니다.
관련 항목: Clash Meta →Clash를 바탕으로 프록시 프로토콜, 규칙, 네트워크 기능을 확장한 코어 계열로, 이후 mihomo라는 이름으로 발전했습니다. 이전 설정 안내, 다운로드 패키지, 클라이언트 인터페이스에는 여전히 Meta라는 표기가 남아 있을 수 있습니다. 이는 대개 코어 계열을 가리키며 특정 데스크톱 앱을 뜻하지 않습니다. Meta라고만 표시된 기능은 해당 코어 버전에서 지원되는지 확인해야 합니다.
관련 항목: mihomo →Clash Meta에서 발전한 규칙 기반 프록시 코어로, 다양한 프록시 프로토콜과 규칙 세트, DNS 기능을 지원합니다. 그래픽 클라이언트에서 호출하거나 서버 및 라우터 환경에서 독립 프로그램으로 실행할 수 있습니다. 클라이언트 인터페이스와 코어 버전은 서로 다를 수 있으므로, 설정이 실제로 적용되는지는 실행 중인 코어 버전과 빌드의 기능을 기준으로 확인해야 합니다.
프로토콜 및 코어 참고 자료 보기 →구독 가져오기, 정책 선택, 로그 확인, 시스템 연동 등의 인터페이스를 제공하는 앱입니다. 예를 들어 Clash Verge Rev가 있습니다. 클라이언트는 조작 환경을 구성하고 코어는 연결을 처리하므로 둘은 서로 다른 개념입니다. 같은 코어라도 클라이언트마다 설정 메뉴가 다를 수 있으며, 클라이언트가 생성한 오버라이드 설정으로 인해 실제 적용 내용이 구독 원본과 달라질 수도 있습니다.
클라이언트 비교 보기 →운영체제의 프록시 설정을 통해 해당 설정을 따르는 앱이 로컬 HTTP 또는 SOCKS 프록시 포트에 연결하도록 합니다. 일부 게임, 명령줄 도구, 자체 네트워크 스택을 사용하는 앱은 시스템 프록시를 무시할 수 있으므로, 옵션을 켰다고 모든 연결이 가로채지는 것은 아닙니다. 시스템 프록시를 꺼도 TUN 등 다른 가로채기 방식은 계속 작동할 수 있으니 각각의 상태를 확인해야 합니다.
비교: TUN 모드 →PROXY PROTOCOLS
프로토콜 이름은 확인의 시작일 뿐입니다. 인증, 전송 방식, TLS 조건도 모두 일치해야 합니다.
암호화 프록시 프로토콜로, 노드 설정에는 보통 서버, 포트, 암호화 방식, 비밀번호가 포함됩니다. 클라이언트와 서버가 같은 암호화 방식을 지원해야 하며, 이전 방식에서 새 방식으로 옮길 때 이름만 바꾸는 것으로는 충분하지 않습니다. 가져온 뒤 연결되지 않는다면 먼저 암호화 방식과 인증 정보를 확인하고, UDP 전달 및 추가 기능이 현재 코어에서 지원되는지도 살펴보세요.
프로토콜 선택 가이드 보기 →V2Ray 생태계의 프록시 프로토콜로, 보통 UUID로 사용자를 식별하며 시스템 시간도 연결에 영향을 줍니다. VMess와 WebSocket 같은 전송 방식은 서로 다른 계층이므로 가져올 때 프로토콜 인증 정보와 전송 매개변수를 모두 유지해야 합니다. 서버 주소에 연결할 수 있지만 핸드셰이크에 실패한다면 노드 이름만 바꾸지 말고 시스템 시간, UUID, 경로, TLS 설정을 확인하세요.
비교: VLESS →대개 TLS 연결에서 비밀번호 인증을 사용하는 프록시 프로토콜로, 서버 인증서와 서버 이름이 연결 조건에 포함됩니다. 주소, 포트, 비밀번호만 복사하면 SNI 같은 필수 매개변수가 빠질 수 있습니다. 인증서 오류가 발생하면 도메인, 시스템 시간, 인증서 신뢰 체인을 먼저 확인하세요. 인증서 검증을 건너뛰는 방식은 일반적인 해결책이 아닙니다.
관련 항목: 노드 설정 →UUID를 사용자 식별자로 사용하는 경량 프록시 프로토콜입니다. 프로토콜 자체는 데이터를 암호화하지 않으며, 연결 보안은 보통 TLS, REALITY 등의 보완 수단에 달려 있습니다. VLESS가 특정 전송 방식 하나를 뜻하는 것은 아니며, 같은 이름의 노드라도 구성은 다를 수 있습니다. 클라이언트를 선택할 때는 코어가 전송 방식, 보안 메커니즘, 관련 확장 매개변수를 지원하는지 함께 확인해야 합니다.
프로토콜 호환성 안내 보기 →QUIC 기반 프록시 프로토콜로, 연결을 설정하려면 하위 네트워크에서 UDP를 사용할 수 있어야 합니다. UDP가 제한된 네트워크에서는 정상 작동하지 않을 수 있습니다. 실제 속도는 패킷 손실, 혼잡, 서버 리소스, 기기 성능에 따라 달라지므로 프로토콜 이름만으로 예측할 수 없습니다. Hysteria 1세대와 2세대는 설정을 서로 바꿔 쓸 수 없으니 가져오기 전에 세대를 확인하세요.
비교: TUIC →QUIC 기반 프록시 프로토콜로 TCP와 UDP 트래픽을 전달할 수 있으며, 하위 네트워크에서 해당 UDP 통신을 허용해야 합니다. Hysteria2와는 다른 프로토콜이므로 인증 필드, 연결 동작, 혼잡 제어 설정을 서로 적용할 수 없습니다. 연결하기 전에 서버 프로토콜 버전, 인증 정보, TLS 매개변수를 확인한 다음 현재 네트워크와 모바일 기기에서의 성능을 살펴보세요.
관련 항목: 지연 시간과 실제 사용 환경 →RULES & POLICIES
매칭 조건에 따라 적용할 정책이 정해지고, 정책에 따라 실제 트래픽 출구가 결정됩니다.
도메인, 대상 주소, 프로세스 등의 조건에 따라 연결에 직접 연결, 프록시, 차단 등의 처리 방식을 지정합니다. 규칙 모드에서는 보통 목록을 위에서 아래로 확인하며, 먼저 일치한 규칙이 적용되므로 구체적인 조건을 포괄적인 조건보다 앞에 두는 것이 일반적입니다. 전역 모드나 직접 연결 모드로 바꾸면 기존 규칙의 매칭 결과를 기준으로 연결 동작을 예상할 수 없습니다.
규칙 분류 실전 가이드 보기 →노드나 다른 정책을 논리적인 출구로 묶어 규칙에서 이름으로 참조할 수 있게 합니다. select는 수동 선택에, url-test와 fallback은 각각 자동 테스트와 장애 조치에 사용됩니다. 실제 동작은 그룹 설정에 따라 달라집니다. 규칙이 그룹 하나를 지정한다고 해서 그룹에 속한 모든 노드가 연결을 동시에 처리하는 것은 아닙니다.
IP 주소의 지역 정보 데이터베이스를 기준으로 매칭하는 방식입니다(예: GEOIP,CN,DIRECT). 데이터베이스에 기록된 지역은 서비스 운영자의 소재지나 사용자의 위치를 뜻하지 않습니다. CDN 때문에 같은 도메인도 서로 다른 지역의 IP 주소를 반환할 수 있습니다. 해석 결과, 데이터베이스 갱신, 규칙 순서에 따라 매칭 결과가 달라집니다. no-resolve를 추가하면 DNS 해석을 건너뛰므로 그 영향도 이해해야 합니다.
매칭 조건을 로컬 또는 원격 파일에 모아 rule-providers로 정의한 다음 RULE-SET 규칙에서 참조합니다. 도메인이나 주소 등의 매칭 조건을 제공할 뿐, 프록시 노드를 제공하지는 않습니다. 규칙 세트 형식, behavior 유형, 갱신 방식이 코어에서 지원되는지 확인해야 합니다. 파일 다운로드에 성공했다고 규칙이 올바르게 매칭에 사용되는 것은 아닙니다.
앞선 규칙에 모두 일치하지 않은 트래픽을 처리하는 마지막 매칭 규칙으로, 보통 rules 목록의 맨 끝에 둡니다. MATCH,PROXY는 남은 연결을 PROXY라는 정책에 전달한다는 뜻이며, 설정에 해당 이름의 정책이 있어야 합니다. MATCH를 앞에 두면 뒤에 있는 규칙은 보통 매칭될 기회가 없습니다. 또한 클라이언트를 전역 모드로 전환하는 설정은 아닙니다.
DNS & NETWORK STACK
연결 가로채기, 도메인 해석, 출구 선택은 서로 다른 단계이므로 각각 확인해야 합니다.
도메인을 IP 주소 등의 레코드로 변환하는 시스템입니다. 앱, 운영체제, 프록시 코어가 모두 이 과정에 관여할 수 있습니다. 대상 웹사이트의 도메인과 프록시 서버 자체 도메인은 서로 다른 경로로 해석될 수 있으며, 암호화 DNS를 사용해도 요청이 반드시 프록시를 통과하는 것은 아닙니다. 문제가 발생하면 먼저 누가 해석을 요청하는지, 어떤 리졸버를 사용하는지, 결과가 캐시되었는지 확인하세요.
관련 항목: Fake-IP →코어가 앱에 예약 주소를 반환하고 내부에서 해당 주소와 도메인의 매핑을 관리합니다. 이후 연결은 이 매핑을 통해 대상 도메인을 복원합니다. 이 주소는 대상 서버의 실제 공인 IP가 아니며 서비스를 이전했다는 뜻도 아닙니다. 실제 해석 결과에 의존하는 앱에는 필요에 따라 fake-ip-filter를 설정할 수 있습니다. 모든 이상 현상을 매핑 방식 탓으로 돌리지 않도록 필터 모드와 다른 DNS 규칙도 함께 확인하세요.
가상 네트워크 인터페이스와 라우팅 설정으로 IP 트래픽을 가로채며, 시스템 프록시를 따르지 않는 연결을 처리할 때 사용할 수 있습니다. TUN은 트래픽을 받아들이는 방식이지 노드 프로토콜이 아니며, 가로챈 모든 연결이 반드시 프록시를 사용한다는 뜻도 아닙니다. 활성화하기 전에 권한, 라우팅, DNS 가로채기 설정을 확인하세요. 다른 VPN과 함께 사용하면 라우팅 충돌과 로컬 네트워크 접근성도 점검해야 합니다.
비교: 시스템 프록시 →지원되는 연결의 초기 데이터에서 도메인 단서를 찾아 코어의 도메인 규칙 매칭을 돕습니다. HTTPS 내용을 임의로 복호화하는 기능은 아니며, 인식 여부는 프로토콜, 암호화 방식, 확인 가능한 핸드셰이크 정보에 따라 달라집니다. 일부 설정은 연결 대상 정보도 조정할 수 있습니다. 기능을 켠 뒤 호환성 문제가 생기면 로그와 관련 오버라이드 옵션을 함께 확인하세요.
관련 항목: 도메인 규칙 분류 →DNS 요청이 예상한 해석 경로를 벗어나는 현상입니다. 예를 들어 코어가 처리해야 할 요청을 앱이 다른 리졸버에 직접 보낼 수 있습니다. 누수인지 여부는 설정한 정책을 기준으로 판단해야 하며, 테스트 페이지에 특정 지역 이름이 표시된다는 이유만으로 결론을 내려서는 안 됩니다. 앱 자체 DNS, 브라우저의 암호화 DNS, IPv6, 시스템 리졸버, 실제 요청 경로를 점검해 해석 결과와 네트워크 경로를 구분하세요.
돌아가기: DNS 해석 담당 주체 →SUBSCRIPTION & CONFIG
가져온 콘텐츠의 형식을 먼저 확인한 다음 노드, 정책, 규칙 간 참조를 점검하세요.
주소를 통해 노드 정보나 설정 파일을 가져오고 갱신하는 배포 방식입니다. 콘텐츠에는 전체 YAML이 들어 있을 수도 있고 노드 목록만 포함될 수도 있습니다. 형식에 맞는 클라이언트 메뉴나 신뢰할 수 있는 변환 방법을 사용해야 하며, 가져오기에 성공해도 모든 프로토콜과 규칙을 지원하는 것은 아닙니다. 구독 주소에 접근 자격 증명이 포함될 수 있으므로 로그나 스크린샷을 공유하기 전에 주소의 민감한 부분을 삭제하세요.
구독 가져오기 안내 보기 →프록시 연결을 설정하는 매개변수 모음으로, 보통 서버 주소, 포트, 프로토콜, 인증 정보를 포함하며 일부 프로토콜은 전송 및 TLS 설정도 필요합니다. 노드 이름은 화면에 표시되는 라벨일 뿐이며, 이름에 적힌 지역이나 용도가 실제 출구와 연결 상태를 보장하지 않습니다. 노드 사용 가능 여부는 서버 상태, 인증 유효성, 로컬 네트워크 경로에도 달려 있으므로 클라이언트 설치만으로 보장되지 않습니다.
관련 항목: 정책 그룹 →클라이언트가 지정된 테스트 대상에 요청을 보내 측정한 소요 시간입니다. 연결 설정, 핸드셰이크, 응답 과정 등이 포함될 수 있으며, 반드시 ICMP ping을 뜻하지는 않습니다. 테스트 주소와 시간 제한, 네트워크 상태에 따라 결과가 달라지므로 지연 시간으로 다운로드 속도를 바로 계산할 수 없습니다. 테스트 시간이 초과되어도 노드를 전혀 사용할 수 없다는 뜻은 아닙니다. 실제 서비스 연결과 실행 로그를 함께 확인하세요.
로그로 문제를 찾는 방법 보기 →Clash 설정에 흔히 쓰이는 구조화 텍스트 형식으로, 들여쓰기로 계층을 표현하고 목록과 키-값으로 노드, 규칙, DNS 설정을 구성합니다. 편집할 때는 공백으로 들여쓰기를 통일하고 탭 문자가 섞이지 않도록 주의하세요. 특수 문자를 따옴표로 처리해야 할 수도 있습니다. YAML 문법이 올바르다는 것은 파일을 파싱할 수 있다는 뜻일 뿐입니다. 필드 지원 여부와 정책 이름의 존재 여부는 현재 코어에서 확인해야 합니다.
관련 항목: 규칙 세트 필드 →노드 모음을 별도로 불러오고 갱신하는 방식입니다. 원격 또는 로컬 소스를 사용할 수 있으며, 정책 그룹에서 use로 참조합니다. 매칭 조건을 제공하는 rule-providers와는 역할이 다르며, 노드 모음이 기본 설정 파일 전체를 대체하는 것도 아닙니다. 사용할 때는 데이터 형식, 프로바이더 이름, 갱신 설정을 확인해 원격 갱신으로 직접 관리하는 기본 설정의 로직이 덮어쓰이지 않도록 하세요.