용어 한눈에 보기 / 자주 쓰는 용어 25개

Clash 용어집
설정 항목과 네트워크 개념

설정이 속한 계층을 기준으로 용어를 찾아보세요. 먼저 클라이언트와 코어를 구분한 다음 프로토콜, 규칙, DNS, 설정 출처를 살펴보면 됩니다.

각 용어에는 공유할 수 있는 개별 앵커 링크가 있습니다. 여기서는 의미와 적용 범위를 설명합니다. 처음 사용한다면 설정 가이드를 따라 해 보고, 프로토콜별 차이는 프로토콜 가이드에서 확인하세요.

한국어 용어와 설정 항목 대조 실제 코어 지원 여부를 확인하세요

인터페이스와 연결 처리

코어와 클라이언트

하나의 인터페이스에 서로 다른 코어가 탑재될 수 있습니다. 같은 구독을 사용할 수 있는지는 클라이언트의 가져오기 방식과 코어의 프로토콜 지원 여부를 함께 확인해야 합니다.

그래픽 클라이언트GUI client: 구독 관리, 정책 선택, 프록시 켜기·끄기 기능을 제공하는 애플리케이션입니다. Clash Verge Rev, FlClash 등이 여기에 해당합니다. 규칙 매칭과 연결 전달은 보통 코어가 처리하므로 인터페이스 버전과 코어 버전은 서로 다를 수 있습니다. 인터페이스에 특정 설정 메뉴가 없다고 해서 코어가 해당 기능을 지원하지 않는 것은 아닙니다. 설정 파일이나 덮어쓰기 기능으로 활성화해야 할 수도 있습니다.

프록시 코어proxy core: 설정을 읽고 연결을 받아 규칙에 따라 매칭한 뒤 아웃바운드 연결을 만드는 프로그램입니다. 특정 프로토콜이나 설정 항목을 사용할 수 있는지 판단하려면 설치 패키지 이름만 보지 말고 현재 실행 중인 코어의 이름과 버전을 확인해야 합니다. 코어만 교체해도 클라이언트 제어 인터페이스나 설정 호환성에 영향을 줄 수 있으므로, 업데이트 전에 클라이언트의 지원 안내를 확인하세요.

mihomo구 Clash.Meta 프로젝트: Clash.Meta 프로젝트에서 이름이 바뀐 프록시 코어입니다. 기존 Clash 설정 체계를 바탕으로 프로토콜, DNS, 네트워크 트래픽 처리 기능을 확장했습니다. 이전 문서에서 Meta는 이 프로젝트의 옛 이름을 가리키는 경우가 많지만, 모든 구버전 빌드가 현재 기능을 지원한다는 뜻은 아닙니다. 지원하지 않는 필드라는 메시지가 나오면 해당 버전의 문서를 확인하세요. 자세한 내용은 프로토콜 및 코어 참고 자료를 참조하세요.

프록시 노드proxy entry: 클라이언트에서 프록시 서버 연결 정보 묶음을 가리킬 때 주로 쓰는 말입니다. 보통 서버 주소, 포트, 프로토콜, 인증 정보가 포함됩니다. 목록의 이름은 구분을 위한 라벨일 뿐, 서버 위치나 사용 가능한 대역폭, 서비스 품질을 증명하지 않습니다. 같은 서버라도 프로토콜이나 포트가 다르면 여러 노드 항목으로 표시될 수 있습니다.

지연 시간 테스트latency / url-test: 클라이언트가 지정된 프록시를 통해 테스트 주소에 접속하고 요청에 걸린 시간을 측정합니다. 구현 방식에 따라 연결 수립, TLS 협상, 응답 단계 중 어디까지 측정하는지가 다를 수 있습니다. 이 값은 테스트 주소, 연결 재사용 여부, 당시 네트워크 상태에 따라 달라지며 다운로드 속도를 뜻하지 않습니다. 결과를 비교할 때는 가능한 한 같은 조건으로 테스트하고, 실제 앱을 연속해서 사용할 때의 체감 성능도 함께 살펴보세요.

노드 연결 방식

프록시 프로토콜

프로토콜은 클라이언트와 서버가 데이터를 주고받는 방식을 정합니다. 프로토콜 이름이 같아도 전송, 보안, 인증 매개변수가 다를 수 있으므로 이름만 보고 설정을 입력해서는 안 됩니다.

Shadowsocks（SS）type: ss: 암호화된 프록시 전송을 중심으로 하는 프로토콜 계열입니다. 노드 설정에는 보통 서버, 포트, 암호화 방식, 비밀번호가 포함됩니다. 암호화 방식과 프로토콜 세대에 따라 인증 요건이 다를 수 있으며 관련 플러그인도 클라이언트와 서버 양쪽에서 지원해야 합니다. 가져온 뒤 연결되지 않으면 각 매개변수를 확인하고, 노드 이름만으로 구현 방식을 추측하지 마세요.

VMesstype: vmess: V2Ray 생태계에서 사용하는 프록시 프로토콜입니다. 보통 UUID로 사용자를 식별하며 다양한 하위 전송 방식과 함께 사용할 수 있습니다. UUID가 맞는 것만으로는 부족합니다. TLS, 서버 이름, 경로, 전송 방식도 서버 설정과 일치해야 합니다. 기기 시간이 크게 어긋나면 인증에 영향을 줄 수 있으므로 시스템 시간을 확인한 뒤 연결 매개변수를 점검하세요.

Trojantype: trojan: TLS 연결을 통해 프록시 트래픽을 전달하는 프로토콜로, 보통 비밀번호로 사용자를 인증합니다. 서버 주소는 연결을 수립하는 데 쓰이고, 서버 이름은 TLS 핸드셰이크와 인증서 검증에 사용될 수 있어 두 값이 다를 수 있습니다. 인증서 오류가 나면 이름, 유효 기간, 기기 시간을 먼저 확인하세요. 인증서 검증을 건너뛰는 설정을 계속 사용하는 것은 권장하지 않습니다.

VLESStype: vless: Xray 생태계의 경량 프록시 프로토콜입니다. 프로토콜 자체는 암호화를 제공하지 않으며 실제 배포에서는 TLS나 REALITY 같은 보안 기능을 함께 사용합니다. 노드의 전송 방식, 흐름 제어, 보안 매개변수는 사용 중인 코어가 모두 지원해야 합니다. VMess 설정의 유형 이름만 VLESS로 바꿔 사용할 수는 없습니다. 서버에서 제공한 전체 매개변수를 사용하세요.

Hysteria2와 TUICtype: hysteria2 / type: tuic: QUIC 기반 프록시 프로토콜 두 가지입니다. 보통 네트워크에서 해당 UDP 통신을 허용해야 하지만 인증 방식과 설정 항목은 서로 호환되지 않습니다. 연결 성능은 패킷 손실, 혼잡 제어, 서버 리소스, 매개변수 설정에 따라 달라지므로 프로토콜 이름만으로 속도를 판단할 수 없습니다. 사용 중인 네트워크에서 UDP를 제한한다면 먼저 네트워크 조건을 확인하세요. 자세한 차이는 프로토콜 선택 가이드를 참조하세요.

연결이 코어에 들어온 뒤

규칙과 라우팅

규칙은 연결을 어디로 보낼지 정하고, 정책 그룹은 실제로 사용할 출구를 결정합니다. 잘못된 경로로 연결되는 문제를 확인할 때는 먼저 매칭된 규칙을 찾고, 그다음 대상 정책 그룹의 현재 선택 항목을 살펴보세요.

규칙 기반 라우팅rules / mode: rule: 도메인, 대상 IP, 프로세스 등의 조건에 따라 연결을 직접 연결, 프록시 또는 다른 정책으로 보내는 과정입니다. 규칙 모드에서는 보통 위에서 아래로 매칭하며 먼저 일치한 규칙이 처리 방식을 정합니다. 따라서 구체적인 규칙을 범위가 넓은 규칙보다 앞에 둬야 합니다. Clash 사용자 지정 규칙을 수정한 뒤에는 브라우저에서 페이지가 열리는지만 보지 말고 연결 세부 정보에서 실제로 매칭된 규칙을 확인하세요.

프록시 그룹proxy-groups: 노드나 다른 정책 그룹을 묶는 설정 단위입니다. 규칙에서 각 노드를 일일이 지정하는 대신 일관된 이름의 그룹을 참조할 수 있습니다. 수동 선택 그룹에는 보통 select, 자동 테스트 그룹에는 url-test, 장애 조치 그룹에는 fallback을 사용합니다. 자동 선택은 설정된 테스트 방식에 따라 동작할 뿐, 모든 웹사이트에서 처리량이 가장 높은 출구를 골라준다는 뜻은 아닙니다.

아웃바운드 모드rule / global / direct: 코어가 아웃바운드 정책을 선택하는 방식을 정합니다. 규칙 모드는 규칙에 따라 매칭하고, 전역 모드는 전역 정책을 사용하며, 직접 연결 모드는 대상에 바로 연결합니다. 모드 전환은 이미 코어에 들어온 연결에만 영향을 주며, 원래 프록시를 우회하는 앱을 자동으로 코어에 연결해 주지는 않습니다. 전역 정책에서 사용할 항목도 올바르게 선택해야 합니다. 전역 모드로 바꾼다고 기기의 모든 트래픽이 특정 프록시 노드를 사용하는 것은 아닙니다.

GeoIPGEOIP / IP database: IP 주소 데이터베이스를 이용해 지역이나 미리 정의된 주소 집합을 판별하는 방식입니다. 규칙 결과는 대상 IP와 로컬 데이터에 따라 달라집니다. 도메인 소유 기관을 나타내거나 서버의 물리적 위치를 정확히 증명하지는 않습니다. 콘텐츠 전송 네트워크를 사용하는 도메인은 여러 지역의 IP로 해석될 수도 있습니다. 사설 네트워크 주소 집합의 범위도 데이터 파일에 따라 달라지므로 지역 라벨을 변하지 않는 사실로 받아들여서는 안 됩니다.

규칙 집합rule-providers / RULE-SET: 도메인, IP 또는 전체 매칭 규칙을 별도의 데이터 소스로 분리해 용도별로 관리하고 업데이트하는 방식입니다. 설정에서 rule-providers를 정의한 뒤 rules에서 해당 이름을 참조해야 라우팅에 적용됩니다. 데이터 형식은 behavior 등의 설정과 일치해야 합니다. 규칙 집합이 정상적으로 로드되어도 다른 규칙보다 먼저 매칭된다는 뜻은 아닙니다.

이름 해석과 트래픽 진입 경로

DNS와 네트워크 스택

DNS는 도메인을 해석하고, 시스템 프록시와 TUN은 서로 다른 계층에서 트래픽을 연결합니다. 설정들은 서로 연관되어 있지만, 하나를 켰다고 나머지 단계까지 자동으로 올바르게 구성되는 것은 아닙니다.

DNSDomain Name System: 도메인을 IP 주소 등의 레코드로 변환하는 시스템으로, 앱이 대상 서비스를 찾는 데 중요한 역할을 합니다. 운영체제, 브라우저, 프록시 코어가 각자 다른 리졸버를 사용할 수 있으며, 브라우저에서 보안 DNS를 켜면 별도의 조회 경로가 생길 수도 있습니다. 원하는 방식으로 해석되고 있는지는 특정 조회 도구에 표시된 서버 이름만 보지 말고 실제 DNS 설정과 연결 로그를 함께 확인하세요.

Fake-IPenhanced-mode: fake-ip: 코어가 도메인에 가상 주소를 반환하고 주소와 도메인의 매핑을 저장합니다. 연결이 코어에 들어오면 이 매핑으로 도메인을 복원한 뒤 규칙 매칭과 아웃바운드 처리를 진행합니다. 가상 주소는 대상 서버의 실제 공인 IP가 아니므로 서버 위치를 판단하는 데 사용할 수 없습니다. 실제 DNS 응답에 의존하는 앱은 필터링이나 호환 설정이 필요할 수 있습니다. 모드를 변경한 뒤에는 이전 DNS 캐시도 확인하세요.

TUN 모드tun / virtual network interface: 가상 네트워크 인터페이스를 통해 라우팅 조건에 맞는 IP 트래픽을 코어로 전달합니다. 시스템 프록시를 따르지 않는 앱을 연결할 때 주로 사용합니다. 활성화하려면 관련 권한, 드라이버 또는 백그라운드 서비스가 필요할 수 있으며 구체적인 요구 사항은 플랫폼과 클라이언트에 따라 다릅니다. 실제로 처리되는 범위는 라우팅, 제외 설정, 다른 VPN 소프트웨어의 영향도 받습니다. 문제가 생기면 스위치를 반복해서 켜고 끄기보다 이런 조건을 확인하세요.

시스템 프록시system proxy: 운영체제에 프록시 주소와 포트를 등록해 해당 설정을 읽는 앱에서 사용하도록 합니다. 브라우저는 대체로 시스템 프록시를 사용할 수 있지만, 명령줄 도구, 게임, 자체 네트워크 스택을 사용하는 프로그램은 별도 설정이 필요할 수 있습니다. 따라서 시스템 프록시는 모든 트래픽을 처리하는 기능과 같지 않습니다. 클라이언트를 종료한 뒤 네트워크에 문제가 생기면 시스템 프록시가 더 이상 응답하지 않는 로컬 포트를 가리키는지 먼저 확인하세요.

DNS 누출DNS leak: 예정된 경로로 보내야 할 DNS 쿼리가 다른 리졸버로 전송되어 도메인 조회 정보가 의도하지 않은 서비스에 노출될 수 있는 현상입니다. 문제를 확인할 때는 시스템, 브라우저, 코어, IPv6의 조회 경로를 모두 살펴봐야 합니다. 출구 IP만 확인해서는 판단할 수 없습니다. 모든 직접 연결 DNS 조회가 누출인 것은 아닙니다. 해당 도메인을 직접 조회하도록 설정한 경우에는 의도한 정책을 기준으로 판단하세요.

설정의 출처

구독과 설정 파일

구독은 콘텐츠를 가져오는 경로이고, 설정 파일은 코어가 실행될 때 기준으로 삼는 내용입니다. 클라이언트가 둘 사이에서 변환하거나 설정을 덮어쓸 수 있으므로 문제를 확인할 때는 최종 적용된 내용을 살펴보세요.

구독subscription URL: 클라이언트가 노드나 설정을 가져오고 업데이트하는 원격 주소입니다. 링크는 전체 Clash 설정, 노드 목록 또는 다른 형식의 데이터를 반환할 수 있습니다. 브라우저에서 링크가 열린다고 해서 클라이언트가 현재 형식으로 가져올 수 있다는 뜻은 아니므로 콘텐츠 형식과 코어 지원 여부도 확인해야 합니다. 구독 링크에는 접근 인증 정보가 포함되는 경우가 많습니다. 다른 사람과 스크린샷이나 로그를 공유하기 전에 링크를 가려서 정보가 노출되지 않도록 하세요.

YAML 설정 파일config.yaml / .yml: YAML 문법으로 코어 설정을 작성하는 텍스트 파일입니다. 포트, 노드, 정책 그룹, DNS, 규칙 등이 포함되는 경우가 많습니다. 들여쓰기로 계층을 나타내며 목록 항목, 따옴표, 필드 유형도 파싱 결과에 영향을 줍니다. 편집할 때는 탭 대신 공백을 사용하세요. 문법이 올바르더라도 필드가 지원된다는 뜻은 아닙니다. 오류가 발생하면 YAML 파싱 오류인지 코어 설정 검증 오류인지 구분해야 합니다.

프록시 목록proxy-providers: 별도 파일이나 원격 소스에서 노드 목록을 불러오는 방식으로, 노드 업데이트를 기본 설정과 분리해 관리할 수 있습니다. 보통 노드만 제공하며 DNS, 포트, 규칙이 포함된 전체 실행 설정은 아닙니다. 정책 그룹에서 해당 목록을 참조해 사용해야 합니다. 프록시 목록 파일을 가져온 뒤 전체 정책 화면이 보이지 않더라도 데이터가 비어 있다는 뜻은 아닐 수 있습니다. 전체 설정으로 가져온 것이 아니라 목록으로 불러온 것인지 확인하세요.

혼합 포트mixed-port: 하나의 리스닝 포트에서 HTTP와 SOCKS 프록시 요청을 모두 받아 여러 앱에서 같은 포트를 사용할 수 있게 하는 설정입니다. 앱에 프록시를 직접 지정할 때는 주소와 포트가 코어의 실제 리스닝 설정과 일치해야 합니다. 포트를 다른 프로세스가 사용 중이면 설정이 시작되지 않을 수 있습니다. 다른 기기에서 접속하게 하려면 allow-lan, 바인딩 주소, 방화벽도 설정해야 합니다. 포트 하나만 바꿨다고 공유가 완료되는 것은 아닙니다.

설정 덮어쓰기override / merge / patch: 클라이언트가 구독 설정을 불러올 때 지정된 필드를 병합, 교체하거나 스크립트로 처리하는 방식입니다. 로컬 포트나 사용자 지정 규칙 등의 설정을 유지할 때 유용합니다. 배열과 객체의 병합 순서는 클라이언트마다 다를 수 있으며, 실제 동작은 덮어쓰기 후의 최종 설정으로 결정됩니다. 구독에서 생성된 파일을 직접 수정하면 다음 업데이트 때 변경 내용이 사라질 수 있습니다. 작업 전에 클라이언트의 설정 저장 방식을 확인하고 로컬 변경 사항을 백업하세요.

용어 분류로 돌아가기 ↑