코어, 프록시 모드, 규칙, DNS를 개념별로 확인하세요. 설정을 바꾸기 전에 각 항목의 역할부터 파악할 수 있습니다.
이 페이지는 클라이언트 선택과 설정 자료를 위한 용어 안내입니다. 각 카드에는 공유할 수 있는 고유 앵커가 있습니다. 처음 설정한다면 빠른 시작을, 매개변수 조합과 활용 예시는 설정 심화 가이드를 확인하세요.
인터페이스는 조작을, 코어는 연결을 담당합니다. 노드는 원격 연결 매개변수이고 포트는 로컬 또는 원격의 수신 지점이므로 혼동하지 마세요.
프록시 코어 · 구 Clash Meta
mihomo는 Clash Meta에서 발전한 프록시 코어로, 설정을 읽고 규칙을 매칭하며 DNS를 처리하고 연결을 전달합니다. Clash Verge Rev 같은 GUI 클라이언트는 조작 인터페이스를 제공합니다. 클라이언트에 특정 옵션이 있다고 해서 모든 코어 버전이 같은 설정 문법을 지원하는 것은 아닙니다. 필드 오류가 발생하면 클라이언트에서 실제로 사용하는 코어와 문서를 먼저 확인한 뒤 설정을 조정하세요.
GUI client
GUI 클라이언트는 구독 가져오기, 프록시 선택, 로그 확인, 시스템 프록시 설정을 조작 가능한 인터페이스로 제공합니다. 실제 연결 처리는 대개 코어가 담당합니다. 같은 코어를 사용하더라도 클라이언트마다 오버라이드 방식, 서비스 설치 절차, 권한 요청 위치가 다를 수 있습니다. 클라이언트를 선택할 때는 운영체제 지원과 설정 관리 방식을 함께 확인하고 클라이언트 비교에서 세부 내용을 살펴보세요.
proxy · 원격 연결 매개변수
노드는 원격 프록시 연결을 설명하는 매개변수 모음으로, 일반적으로 프로토콜 유형, 서버 주소, 포트, 인증 정보를 포함하며 일부 프로토콜은 전송 계층이나 TLS 매개변수도 필요합니다. 노드 자체가 클라이언트는 아니므로 앱을 설치한 뒤 사용할 수 있는 설정을 가져와야 합니다. 연결에 실패하면 매개변수 오류, 서버 접속 불가, 로컬 네트워크 문제를 구분하세요. 노드 이름이나 테스트 결과만으로 서비스 상태를 판단해서는 안 됩니다.
mixed-port
혼합 포트는 하나의 로컬 수신 포트에서 HTTP 프록시와 SOCKS 프록시 요청을 받아 여러 앱이 같은 진입점을 사용하도록 합니다. 원격 노드의 서버 포트와는 다릅니다. 로컬에서만 사용할 경우 앱은 보통 루프백 주소와 해당 포트로 연결합니다. 포트 번호를 바꾼 뒤에는 시스템 프록시와 앱에 직접 입력한 프록시 주소도 함께 변경하세요. 자세한 방법은 Clash 포트 설정을 참고하세요.
latency · 요청 응답 시간
클라이언트는 보통 프록시를 통해 지정된 테스트 주소에 접속하고 요청 시간을 기록해 특정 조건에서의 응답 속도를 비교합니다. 결과는 테스트 사이트, 핸드셰이크 과정, 연결 재사용, 당시 네트워크 상태에 따라 달라지며 다운로드 대역폭이나 동영상 재생 성능을 의미하지 않습니다. 실제 사용 문제를 확인하려면 대상 앱으로 직접 테스트하고 로그에서 연결 실패, 패킷 손실, 혼잡 여부를 살펴보세요. 가장 낮은 밀리초 값만 보고 선택하지 마세요.
규칙·전역·직결 모드는 트래픽이 어디로 나갈지를 정하고, 시스템 프록시와 TUN은 트래픽이 어떻게 코어로 들어오는지를 정합니다. 서로 다른 종류의 설정입니다.
mode: rule
규칙 모드는 설정의 규칙에 따라 아웃바운드 대상을 선택하므로 도메인이나 주소별로 직결, 프록시, 차단을 다르게 적용할 수 있습니다. 규칙은 보통 순서대로 매칭해 조건에 맞는 대상을 실행하므로 구체적인 조건을 포괄적인 조건보다 앞에 두세요. 처음 사용하는 경우 일상적으로 규칙 모드를 선택해도 좋지만, 실제 동작은 규칙 내용과 정책 그룹 정의에 따라 달라집니다. 누락된 라우팅 규칙을 자동으로 보완하지는 않습니다.
mode: global
전역 모드에서는 코어로 들어온 모든 연결을 전역 정책에서 선택한 대상으로 보내므로 특정 프록시의 연결 여부를 임시로 확인하기 편리합니다. 여기서 전역은 아웃바운드 선택을 뜻할 뿐, 시스템 트래픽 전체를 가로채는 것은 아닙니다. 시스템 프록시를 사용하지 않는 프로그램은 여전히 클라이언트를 우회할 수 있습니다. 전환하기 전에 전역 정책에서 실제로 선택된 대상을 확인하고, 점검이 끝나면 원래 모드로 되돌려 규칙 문제가 해결된 것으로 착각하지 않도록 하세요.
mode: direct · DIRECT
직결 모드에서는 코어로 들어온 연결이 원격 프록시 서버를 거치지 않고 목적지에 직접 접속합니다. 규칙의 DIRECT는 개별 규칙에서 지정할 수 있는 직결 대상입니다. 두 설정의 적용 범위는 다르므로 직결 규칙 하나만으로 전체 설정이 직결된다고 볼 수 없습니다. 직결 모드에서도 앱은 계속 실행되며 시스템 프록시, TUN, 코어 DNS가 작동할 수 있습니다.
system proxy
시스템 프록시는 운영체제 설정에 프록시 주소와 포트를 등록해 해당 설정을 따르는 앱의 요청을 로컬 클라이언트로 전달합니다. 브라우저는 대체로 시스템 프록시를 사용할 수 있지만 일부 게임, 명령줄 프로그램, 자체 네트워크 스택을 쓰는 앱은 이 설정을 따르지 않을 수 있습니다. 처음 연결할 때는 시스템 프록시를 켜고 브라우저에서 확인하세요. 앱이 여전히 연결되지 않으면 앱 자체 프록시 옵션을 확인하거나 TUN 사용을 고려하세요.
tun · 가상 네트워크 인터페이스
TUN은 가상 네트워크 인터페이스와 라우팅 설정을 통해 트래픽을 프록시 코어로 전달해 시스템 프록시를 따르지 않는 일부 프로그램까지 처리합니다. 보통 관련 시스템 권한이나 클라이언트 서비스가 필요하며, 적용 범위는 라우팅, 제외 설정, 다른 네트워크 소프트웨어의 영향을 받습니다. TUN이 연결을 반드시 프록시로 보내는 것은 아닙니다. 코어에 들어온 뒤에는 현재 모드에 따라 아웃바운드가 선택됩니다. 설정 방법은 TUN 설정을 참고하세요.
규칙은 이 연결이 어떤 유형인지 판단하고, 정책 그룹은 해당 유형의 연결이 어떤 출구를 사용할지 결정합니다. 참조하는 이름은 전체 설정에 정의된 이름과 일치해야 합니다.
rules · 조건 매칭
규칙 기반 라우팅은 도메인, 대상 IP 또는 기타 조건에 따라 연결을 지정된 정책 그룹, 직결 대상, 차단 대상으로 보냅니다. 일반적인 도메인 규칙에는 DOMAIN과 DOMAIN-SUFFIX가 있으며, 마지막에는 남은 연결을 처리하는 MATCH를 두는 경우가 많습니다. 규칙을 수정할 때는 조건뿐 아니라 앞선 포괄 규칙에 먼저 매칭되는지, 참조한 정책 그룹 이름이 실제로 있는지도 확인하세요.
proxy-groups
정책 그룹은 여러 노드나 다른 정책 대상을 묶어 규칙에서 안정적인 이름 하나로 참조할 수 있게 합니다. select는 수동 선택, url-test는 테스트 결과에 따른 최적 선택, fallback은 순서에 따른 사용 가능 대상 전환에 쓰입니다. 각 유형이 해결하는 문제는 다르므로 그룹을 설정할 때 구성원 출처, 테스트 조건, 그룹 간 참조 관계를 함께 확인하세요.
자동 테스트 정책 그룹
url-test는 그룹에 포함된 프록시를 통해 지정한 URL에 주기적으로 접속한 뒤 테스트 결과와 관련 매개변수에 따라 아웃바운드를 선택합니다. 테스트 주소는 비교할 접속 경로를 결정하고, 간격과 허용 오차는 전환 빈도에 영향을 줍니다. 너무 자주 전환하면 지속 연결에 적합하지 않을 수 있습니다. 수동 선택을 줄이는 데 유용하지만 대용량 전송 속도나 모든 웹사이트에서의 성능을 보장하지는 않습니다.
GEOIP · IP 지역 매칭
GeoIP는 IP 주소의 지역 정보나 데이터베이스 분류를 기준으로 연결을 매칭하며, 주소 기반 트래픽 분기에 자주 사용됩니다. 결과는 데이터베이스에 따라 달라지고 사용자의 실제 위치를 나타내지 않습니다. 클라우드 서비스 이전, 공유 인프라, 데이터베이스 업데이트로 분류가 달라질 수도 있습니다. 도메인 연결에 이 규칙을 적용할 때는 주소 조회가 필요할 수 있으며, 규칙에 no-resolve를 지정하면 해당 규칙 때문에 별도의 조회를 수행하지 않습니다.
rule-providers · RULE-SET
규칙 세트는 여러 매칭 조건을 별도 리소스로 분리해 rule-providers로 정의하고 RULE-SET으로 참조하므로 중앙 관리와 재사용이 편리합니다. 리소스 형식은 behavior 설정과 맞아야 하며 도메인 목록, 주소 목록, 클래식 규칙 형식을 임의로 섞어 쓸 수 없습니다. 규칙 세트 자체가 아웃바운드를 선택하는 것은 아니며 최종 동작은 이를 참조하는 규칙이 지정합니다. 업데이트 후에는 리소스가 정상적으로 로드되었는지도 확인하세요.
도메인 조회와 연결 전달은 서로 연관되어 있지만 별개의 경로입니다. 웹페이지가 열리지 않는다면 DNS 조회 단계일 수도 있고 라우팅이나 원격 연결 단계일 수도 있습니다.
Domain Name System
DNS는 도메인을 주소 등의 레코드로 변환해 앱이 접속할 대상을 알 수 있게 합니다. 운영체제, 브라우저, 프록시 코어가 각자 DNS 서비스를 사용할 수 있으므로 코어의 DNS 설정을 바꿔도 모든 프로그램의 조회 경로가 바뀌는 것은 아닙니다. 문제를 확인할 때는 먼저 실제 조회 주체를 파악한 다음 조회 성공 여부, 반환 주소가 예상과 일치하는지, 프록시 서버 도메인도 정상적으로 조회되는지 살펴보세요.
enhanced-mode: fake-ip
Fake-IP는 앱에 매핑용 가상 주소를 반환하고, 코어가 주소와 도메인의 대응 관계를 이용해 후속 연결을 처리하여 도메인 정보를 유지하고 라우팅 규칙에 활용하는 방식입니다. 이 주소는 웹사이트 서버의 실제 주소가 아니므로 이것만 보고 조회 오류라고 판단할 수 없습니다. 실제 주소가 필요하거나 이 매핑 방식과 호환되지 않는 앱에는 필요에 따라 fake-ip-filter를 설정하되 예외 범위를 최대한 구체적으로 지정하세요.
DNS leak · 예상하지 못한 조회 경로
DNS 누출은 도메인 조회가 예상한 경로로 전송되지 않고 다른 DNS 서비스로 전달되어 조회한 도메인이 노출될 수 있는 현상입니다. 브라우저의 암호화 DNS, 운영체제의 대체 조회 방식, 트래픽을 가로채지 못한 DNS 요청을 각각 확인해야 합니다. 테스트 사이트에 특정 DNS 사업자 이름이 표시되는 것만으로 전체 조회 경로를 판단할 수는 없습니다. 암호화 DNS는 전송을 보호하지만, 예상한 경로인지 여부는 DNS 서비스 선택과 트래픽 라우팅을 확인해야 합니다.
sniffer
도메인 스니핑은 일부 HTTP 요청이나 TLS 핸드셰이크 정보처럼 연결에서 확인할 수 있는 프로토콜 메타데이터를 분석해 도메인을 추출하고 규칙 판단을 보완합니다. TLS 내용을 복호화하는 기능은 아니며 모든 연결에서 도메인을 알아낼 수도 없습니다. 암호화된 메타데이터나 지원하지 않는 프로토콜에서는 결과가 없을 수 있습니다. 호환성 문제가 발생하면 모든 IP 연결을 정확히 식별할 수 있다고 가정하지 말고 대상에 맞게 스니핑 범위를 줄이세요.
Internet Protocol version 6
IPv6는 128비트 주소를 사용하며, 도메인의 AAAA 레코드는 보통 이러한 주소를 제공합니다. 정상적으로 연결되는지는 로컬 네트워크, DNS 응답, TUN 라우팅 범위, 프록시 아웃바운드 기능에 달려 있으므로 클라이언트의 IPv6 스위치만 보고 판단할 수 없습니다. 일부 웹사이트만 문제가 있다면 IPv4와 IPv6의 조회 및 연결 경로를 비교한 뒤 조정할 계층을 결정하세요. 단일 스위치로 실제 라우팅 문제를 가리지 않도록 주의하세요.
구독은 원격 리소스를 제공하고, 설정 파일은 작동 방식을 정의하며, 오버라이드는 로컬 변경을 유지합니다. 업데이트하기 전에 가져온 항목이 전체 설정인지 프록시 목록만인지 확인하세요.
subscription URL
구독 링크는 원격 설정이나 프록시 목록을 가져오는 주소로, 클라이언트에서 리소스를 주기적으로 업데이트해 노드를 하나씩 입력할 필요를 줄여 줍니다. 서비스마다 전체 YAML, 프록시 목록 등 반환 형식이 다를 수 있으므로 가져오기 전에 클라이언트가 해당 형식을 지원하는지 확인하세요. 링크에는 접근 자격 증명이 포함되는 경우가 많으므로 공개 화면 캡처, 로그, 공유 메시지에 노출하지 마세요. 가져오기 방법은 Clash 구독 링크 가져오기를 참고하세요.
config.yaml · 구조화된 설정 텍스트
YAML은 들여쓰기로 객체와 목록의 계층을 표현하며 Clash 설정에 널리 쓰이는 텍스트 형식입니다. 편집할 때 같은 계층의 필드를 맞추고 들여쓰기는 공백을 사용하세요. 문법 파싱에 성공해도 텍스트 구조를 읽을 수 있다는 뜻일 뿐, 정책 그룹 참조, 필드 이름, 코어 호환성이 올바르다는 의미는 아닙니다. 코드 조각은 올바른 계층에 넣고 최상위 키를 중복하지 않도록 주의하세요. 전체 구조는 Clash 설정 파일에서 확인할 수 있습니다.
proxy-providers
프록시 목록은 proxy-providers로 별도의 프록시 리소스를 관리하고 정책 그룹에서 use 등의 설정으로 참조합니다. 프록시 리소스 업데이트와 로컬 규칙 관리를 분리할 때 유용하지만, 리소스는 사용 중인 코어의 요구사항을 따라야 하며 임의의 전체 설정을 프록시 목록으로 사용할 수는 없습니다. 규칙 세트와도 다릅니다. 전자는 연결 후보를 제공하고 후자는 매칭 조건을 제공합니다.
override · merge · patch
로컬 오버라이드는 구독 내용과 별도로 사용자 설정을 유지하는 기능입니다. 예를 들어 규칙을 추가하거나 수신 포트를 변경해 원격 업데이트가 수동 편집 내용을 덮어쓰지 않도록 할 수 있습니다. 클라이언트마다 병합·대체 방식, 규칙 삽입 위치, 스크립트 실행 순서가 다를 수 있으며 이름이 비슷하다고 동작도 같지는 않습니다. 수정 후에는 편집기 원본만 보지 말고 최종 적용 설정을 확인하고, 재시작이나 구독 업데이트 후에도 원하는 상태가 유지되는지 점검하세요.
external-controller · 관리 API
외부 제어 인터페이스는 대시보드나 클라이언트가 코어 상태를 읽고 정책을 전환하거나 연결을 관리하도록 하며, 수신 주소는 external-controller로 지정합니다. 관리용 진입점이지 브라우저 인터넷 접속용 혼합 포트가 아니므로 두 포트는 서로 대체할 수 없습니다. 로컬에서만 관리한다면 루프백 주소로 제한하고 인증을 설정한 뒤 방화벽도 확인하세요. LAN에 공개하기 전에는 어떤 기기에서 인터페이스에 접근할 수 있는지 명확히 정해야 합니다.