GLOSSARY

Clash 개념 정리

자주 쓰이는 용어 21개를 5개 분류로 정리했습니다. 각 항목은 2~4문장으로, Clash 맥락에서 이 단어가 정확히 무엇을 뜻하는지와 설정 작성 요점만 설명합니다. 각 카드에는 앵커가 붙어 있어 링크를 그대로 복사해 튜토리얼이나 질문 답변에 인용할 수 있습니다. 필드별 전체 설명이 필요하다면 YAML 가이드를 확인하세요.

용어 선정 기준: 클라이언트 화면, 설정 파일, 오류 메시지에 등장하며 처음 보는 사용자가 막힐 가능성이 큰 단어입니다. 너무 생소한 프로토콜 파라미터는 넣지 않았습니다. 넣어도 어차피 외우기 어렵기 때문입니다.

01 · CORE

핵심 개념

구독, 노드, 정책 그룹, 코어—이 네 단어의 관계를 이해하면 Clash의 동작 방식이 절반은 이해된 셈입니다.

구독 subscription: 구독 제공업체나 직접 구축한 서비스가 제공하는 URL로, 클라이언트가 주기적으로 가져오면 전체 노드 목록과 설정을 얻습니다. 내용은 Base64로 인코딩된 노드 목록일 수도 있고, Clash YAML 전체일 수도 있습니다. 구독을 업데이트하면 노드 정보만 새로 고쳐지며, 로컬에서 수동으로 수정한 내용을 덮어쓸지는 클라이언트의 병합 정책에 따라 다릅니다.
노드 proxy: 하나의 프록시 서버에 대한 연결 파라미터 모음으로, 서버 주소, 포트, 프로토콜 종류, 암호화 방식을 포함합니다. 설정 파일의 proxies 블록에서 각 노드는 하나의 항목입니다. 노드 품질은 회선, 서버 부하, 프로토콜 특성이 함께 결정하며, 이름에 적힌 지역과 반드시 일치하지는 않습니다.
정책 그룹 proxy-groups: 여러 노드를 용도별로 묶어 그룹을 만들고, 그룹 안에서의 선택 방식을 정합니다. select는 수동 선택, url-test는 자동으로 속도를 측정해 가장 빠른 것을 선택, fallback은 순서대로 장애를 넘겨가며 전환합니다. 규칙에 걸린 트래픽은 먼저 정책 그룹으로 전달되고, 그룹 내부 로직이 최종적으로 어느 노드를 사용할지 결정합니다.
mihomo 코어: 현재 주요 Clash 클라이언트가 사용하는 코어로, 원래의 Clash 코어 개발이 중단된 뒤 커뮤니티가 이어서 유지보수하고 있으며 이전 이름은 Clash.Meta였습니다. 이전 코어보다 더 많은 프로토콜(Hysteria2, TUIC 등)과 더 세밀한 규칙 유형을 지원합니다. Clash Verge Rev, ClashX Meta 같은 그래픽 클라이언트는 모두 이 코어를 감싼 껍데기입니다.
지연 시간 테스트 url-test: 클라이언트가 지정된 테스트 주소로 요청을 한 번 보내고 완료까지 걸린 시간을 밀리초 단위로 기록합니다. 이 값은 핸드셰이크와 왕복 시간을 나타낼 뿐 대역폭이 아닙니다. 지연 시간이 낮은 노드라고 해서 영상이 반드시 더 부드럽게 재생되는 것은 아닙니다. 테스트 주소, 프로토콜 핸드셰이크 방식, 결과 캐시 여부가 모두 패널에 표시되는 숫자에 영향을 줍니다.

02 · PROTOCOL

프로토콜과 전송

노드 항목의 type 필드에 자주 쓰이는 값과, 그 위에 덧씌우는 전송 계층을 정리했습니다.

Shadowsocks ss: 가벼운 암호화 프록시 프로토콜로 구조가 단순하고 성능 오버헤드가 적으며, Clash가 가장 먼저 지원한 프로토콜 중 하나입니다. 설정 필드에는 주로 cipher(암호화 방식)와 password가 있습니다. 노드 항목에서 type은 ss로 쓰며, 암호화 방식은 서버 쪽과 반드시 일치해야 하고 그렇지 않으면 연결이 곧바로 실패합니다.
VMess vmess: V2Ray 프로젝트의 기본 프로토콜로 UUID 기반 인증을 사용하며, 클라이언트와 서버의 UUID는 완전히 일치해야 합니다. WebSocket, TLS와 함께 써서 프록시 트래픽을 일반 HTTPS 접속처럼 위장하는 경우가 많습니다. 필드가 비교적 많으며, 최신 배포에서는 alterId를 보통 0으로 고정합니다.
Trojan trojan: HTTPS 동작을 모방하는 프록시 프로토콜로 유효한 TLS 인증서가 반드시 필요하며, 트래픽 특성이 일반 웹사이트 접속과 비슷합니다. 설정의 핵심은 password와 sni입니다. 서버 인증서와 SNI가 일치하지 않으면 핸드셰이크 단계에서 거부됩니다.
Hysteria2 hysteria2: QUIC/UDP 기반의 고처리량 프로토콜로, 손실률이 높고 거리가 먼 회선에 맞춰 혼잡 제어를 최적화했으며 국가 간 회선에서 흔히 쓰입니다. mihomo 같은 최신 코어에서만 인식할 수 있고, 구버전 Clash 코어는 이런 노드가 포함된 설정을 불러오면 오류가 발생합니다. 사용 중인 네트워크가 UDP를 차단하면 이 프로토콜은 전혀 동작하지 않습니다.
WebSocket 전송 ws: 자주 쓰이는 전송 계층 위장 방식으로, 프록시 데이터를 하나의 WebSocket 연결에 담고 그 위에 TLS를 씌웁니다. 겉에서 보면 일반적인 웹페이지 장기 연결과 다를 바 없습니다. 표준 443 포트를 쓰고 CDN을 경유할 수 있어 회선 생존율을 높이는 데 자주 사용됩니다. 노드 필드에서는 network: ws와 ws-opts에 대응합니다.

03 · RULES

규칙과 라우팅

rules 블록이 각 연결의 경로를 결정하며, 이는 Clash가 일반적인 전역 프록시 도구와 구별되는 핵심입니다.

규칙 라우팅 rules: 설정 파일의 rules 블록은 위에서부터 아래로 하나씩 일치 여부를 검사하고, 일치하면 즉시 멈추며 그 뒤의 규칙은 관여하지 않습니다. 자주 쓰이는 유형으로 DOMAIN-SUFFIX(도메인 접미사), IP-CIDR(IP 대역), GEOIP(IP 소속 지역)가 있습니다. 규칙을 적는 순서가 라우팅 결과를 직접 좌우하며, 같은 규칙이라도 순서를 바꾸면 동작이 완전히 달라질 수 있습니다.
GeoIP GEOIP: IP 소속 지역으로 매칭하는 규칙 유형으로, 로컬 데이터베이스 파일(주로 Country.mmdb)이 필요합니다. 대표적인 작성 예는 GEOIP,CN,DIRECT로, 중국 본토 IP로 해석되는 연결을 직접 연결하게 합니다. 데이터베이스는 주기적으로 업데이트해야 하며, 오래된 데이터베이스는 새로 할당된 IP 대역을 잘못된 방향으로 분류할 수 있습니다.
GeoSite GEOSITE: 도메인 분류 데이터베이스로 매칭하는 규칙 유형으로, 수많은 도메인을 google, cn 같은 카테고리로 미리 묶어두어 규칙 하나로 한 카테고리 전체 사이트를 처리할 수 있어 규칙 목록을 크게 줄여줍니다. 분류 데이터베이스와 GeoIP 데이터베이스는 서로 다른 파일이며, 각각 별도로 관리·업데이트됩니다.
DIRECT / REJECT 내장 정책: 따로 정의하지 않아도 바로 쓸 수 있는 내장 정책 두 가지입니다. DIRECT는 어떤 프록시도 거치지 않고 대상에 직접 연결함을 뜻하고, REJECT는 해당 연결을 즉시 거부함을 뜻하며 광고와 원격 측정 도메인을 차단할 때 자주 쓰입니다. 둘 다 일반 정책 그룹처럼 규칙의 동작 위치에 그대로 넣을 수 있습니다.
MATCH 기본 처리 규칙: 규칙 목록 맨 끝에 두는 기본 처리 항목으로, 앞의 규칙에 걸리지 않은 모든 트래픽을 처리하며 MATCH,PROXY처럼 씁니다. 이 항목이 없으면 빠져나간 트래픽의 경로가 코어의 기본 동작에 의존하게 되어 라우팅 결과를 예측하기 어려워집니다. “일부 사이트가 잘못된 경로로 나간다”는 문제를 조사할 때는 먼저 기본 처리가 어느 정책 그룹을 가리키는지 확인하세요.

04 · CONFIG

설정 필드

config.yaml을 열면 앞부분에서 곧바로 만나는 필드들과, 사용 경험에 가장 큰 영향을 주는 두 가지 스위치를 정리했습니다.

YAML config.yaml: Clash 설정 파일에 쓰이는 텍스트 형식으로, 들여쓰기로 계층 구조를 표현하며 공백에 매우 민감합니다. 들여쓰기는 반드시 공백만 써야 하고 Tab은 쓸 수 없으며, 콜론 뒤에는 공백을 하나 넣어야 합니다. “설정을 불러오지 못했습니다” 같은 오류의 대부분은 내용이 잘못된 것이 아니라 YAML 문법 문제가 원인입니다.
mode rule / global / direct: 전체 동작 모드를 지정하는 필드로 세 가지 값이 있습니다. rule은 규칙에 따라 라우팅하고, global은 모든 트래픽이 프록시를 거치며, direct는 모든 트래픽을 직접 연결합니다. 일상적으로는 rule을 유지해야 하며, global은 “규칙 문제인지 아닌지”를 임시로 확인할 때만 적합하고 장기간 켜두면 트래픽을 낭비합니다.
TUN 모드 tun: 코어가 가상 네트워크 어댑터를 만들어 네트워크 계층에서 시스템의 모든 트래픽을 넘겨받습니다. 애플리케이션이 시스템 프록시 설정을 따르는지에 의존하지 않으므로, 명령줄 도구나 게임처럼 “프록시를 인식하지 못하는” 프로세스까지 처리할 수 있습니다. 활성화하려면 관리자 권한이나 시스템 확장 승인이 필요하며, 보통 DNS 하이재킹과 함께 써야 완전하게 동작합니다.
Fake-IP enhanced-mode: DNS 응답 방식의 하나로, 클라이언트가 먼저 예약된 대역의 가짜 IP(기본값 198.18.0.0/16)를 응답으로 돌려주고, 애플리케이션이 연결을 시작하면 코어가 이 가짜 IP를 실제 도메인으로 다시 매핑해 처리합니다. 실제 DNS 조회를 한 번 줄여 연결이 더 빨라지며, 실제 IP에 의존하는 일부 프로그램은 fake-ip-filter에 넣어 제외해야 합니다.
allow-lan LAN 공유: true로 설정하면 Clash가 로컬 루프백뿐 아니라 모든 네트워크 어댑터에서 대기합니다. 같은 LAN에 있는 휴대폰이나 TV가 이 기기를 프록시 서버로 지정해 하나의 출구를 함께 쓸 수 있습니다. 활성화하면 포트가 LAN 전체에 노출되므로 방화벽이나 authentication으로 접근을 제한하는 것이 좋습니다.

05 · NETWORK

네트워크 기초

Clash만의 개념은 아니지만 문제를 진단할 때 반드시 알아야 합니다.

DNS 유출 DNS leak: 프록시를 켰는데도 도메인 해석 요청이 여전히 로컬 통신사의 DNS 서버로 직접 전달되어, 어떤 사이트에 접속했는지가 로컬 네트워크에 노출되는 현상입니다. 시스템 프록시만 설정하고 DNS를 넘겨받지 않은 경우에 흔히 나타납니다. TUN 모드를 DNS 하이재킹과 함께 켜거나 Fake-IP 모드를 사용하면 상당히 개선됩니다.
시스템 프록시 system proxy: 운영체제 수준의 HTTP/SOCKS 프록시 설정으로, 브라우저처럼 “규칙을 따르는” 애플리케이션이 능동적으로 읽어 사용합니다. 이는 강제가 아니라 일종의 약속이라, 일부 프로그램은 그냥 무시합니다. 어떤 프로그램이 도무지 프록시를 타지 않는다면 먼저 시스템 프록시를 따르는지 확인하고, 따르지 않는다면 TUN 모드로 바꾸세요.
UDP 릴레이 udp: true: 프록시 회선이 UDP 트래픽을 처리할 수 있게 하는 기능으로, 온라인 게임, 음성 통화, QUIC 기반 웹사이트가 모두 이에 의존합니다. 프로토콜 자체, 서버 설정, 노드 필드 세 가지가 동시에 지원해야 하며 노드에서는 보통 udp: true로 씁니다. 게임 지연은 정상인데 자주 끊긴다면 대부분 UDP가 제대로 전달되지 않은 경우입니다.
혼합 포트 mixed-port: 하나의 포트에서 HTTP와 SOCKS5 두 프록시 프로토콜을 동시에 수신하는 방식으로, port와 socks-port를 통합해 대체합니다. 최신 클라이언트는 기본값으로 mixed-port: 7890을 많이 사용하며, 다른 프로그램에 프록시 주소를 입력할 때는 프로토콜을 구분하지 않고 127.0.0.1:7890만 적으면 됩니다.

다음 단계

용어 정리는 “이 단어가 무엇인가”만 해결합니다. 필드의 전체 값 범위와 설정 예시는 YAML 가이드에서 항목별로 다룹니다. “왜 연결이 안 되나” 같은 구체적인 문제는 먼저 FAQ의 문제 해결 분류를 확인하세요. 처음부터 끝까지의 전체 절차는 튜토리얼을 참고하세요. 아직 클라이언트를 설치하지 않았다면 클라이언트 받기 페이지에서 플랫폼별로 선택하세요.