대칭 암호화 기반의 경량 프록시 프로토콜로, 클라이언트와 서버가 암호화 방식과 비밀번호만 맞추면 통신할 수 있습니다. 단순하고 효율적인 설계가 목표이며 암호화 부담이 적습니다. 구독 노드에서 type: ss가 이 프로토콜이며, 흔히 쓰는 암호화 방식은 aes-256-gcm과 chacha20-ietf-poly1305입니다.
docs / glossary.md
Clash 용어 사전: 프록시 프로토콜, 규칙 라우팅, 클라이언트 기능 용어 정리
설정 파일의 필드명, 클라이언트 화면의 옵션, 오류 로그에 등장하는 키워드까지 이 페이지에서 뜻을 확인할 수 있습니다. 25개 용어를 5개 분류로 정리했고 각 항목에 관련 설정 필드를 표기했습니다. 가이드를 읽거나 오류를 해결하다 낯선 용어를 만나면 이 페이지에서 검색하면 됩니다.
프록시 프로토콜
V2Ray 생태계의 기본 프로토콜로, UUID로 인증하며 핸드셰이크에 시간 검증이 필요합니다. 로컬 시간과 서버 시간의 오차가 약 90초를 넘으면 바로 연결이 끊깁니다. WebSocket과 TLS 전송 계층과 함께 쓰는 경우가 많으며, 설정 필드는 type: vmess입니다.
VMess의 경량화된 후속 프로토콜로, 내부 암호화를 제거하고 보안을 외부 TLS나 REALITY에 완전히 맡겨 패킷 부담이 더 작습니다. 원조 Clash 코어는 이 프로토콜을 지원하지 않아 mihomo 코어가 필요하며, 주요 GUI 클라이언트에는 이미 내장돼 있습니다.
프록시 트래픽을 일반 HTTPS처럼 위장하는 프로토콜로, 서버는 유효한 TLS 인증서를 갖추고 443 포트를 열어야 하며 트래픽 특징이 일반 웹사이트 접속과 비슷합니다. 클라이언트 설정은 주소, 포트, 비밀번호만 있으면 되고 설정 필드는 type: trojan입니다.
QUIC 기반 프록시 프로토콜로, UDP로 데이터를 전송하고 강력한 혼잡 제어를 내장해 손실률과 지연이 높은 구간에서 TCP 계열 프로토콜보다 처리량이 눈에 띄게 좋습니다. mihomo 코어가 필요하며, 네트워크에서 UDP를 제한하면 오히려 체감 속도가 떨어질 수 있습니다.
코어 및 설정
Clash Meta 코어의 현재 이름으로, 원조 Clash 코어 개발이 중단된 뒤 커뮤니티가 이어가는 프로젝트입니다. Clash Plus, Clash Verge Rev, FlClash 등 주요 클라이언트가 이를 엔진으로 사용해 포트 수신, 설정 해석, 규칙 매칭, 트래픽 전달을 처리합니다. 원조 코어에는 없던 VLESS, Hysteria2 같은 프로토콜도 지원합니다.
코어가 읽는 config.yaml 파일로, 들여쓰기로 계층 구조를 표현하며 주요 항목은 mixed-port, dns, proxies, proxy-groups, rules입니다. 들여쓰기는 반드시 공백만 써야 하고 탭이 섞이면 바로 해석 오류가 나는데, 이는 수동 편집 시 가장 흔한 오류 원인입니다.
혼합 수신 포트로, 하나의 포트에서 HTTP와 SOCKS5 요청을 동시에 처리해 포트를 따로 설정할 필요가 없습니다. 기본값으로 7890을 흔히 씁니다. 실행 시 bind: address already in use 오류가 나오면 해당 포트를 다른 프로세스가 쓰고 있다는 뜻이므로 포트 번호를 바꾸거나 점유 중인 프로세스를 종료하면 됩니다.
코어가 가상 네트워크 카드를 만들어 네트워크 계층에서 로컬 기기의 모든 아웃바운드 트래픽을 가로채며, 앱이 프록시 설정을 읽는지와 무관하게 작동합니다. 명령줄 도구나 게임 클라이언트처럼 시스템 프록시를 무시하는 프로그램은 TUN 모드로만 처리할 수 있습니다. 켜려면 관리자 또는 root 권한이 필요하고, 일부 클라이언트는 먼저 시스템 서비스를 설치해야 합니다.
DNS 동작 모드의 하나로, 코어가 도메인 조회에 198.18.0.0/16 예약 대역의 가상 주소를 즉시 반환하고 실제 해석은 규칙 매칭 이후로 미룹니다. 해석 대기 시간을 없애고 도메인 단위로 정확히 라우팅할 수 있는 장점이 있지만, 실제 IP가 필요한 일부 로컬 네트워크 앱은 fake-ip-filter에 예외로 등록해야 합니다.
코어가 외부에 노출하는 RESTful 제어 인터페이스로, 기본값은 127.0.0.1:9090입니다. 웹 패널은 이를 통해 노드 목록을 불러오고 정책 그룹을 전환하며 연결과 로그를 확인합니다. secret 필드로 접근 비밀번호를 설정하면 같은 네트워크의 다른 기기가 함부로 호출하는 것을 막을 수 있습니다.
규칙 및 라우팅
코어는 새 연결마다 rules 목록을 위에서부터 차례로 대조하다가 처음 일치하는 규칙에서 멈추며, 해당 규칙이 직접 연결, 특정 정책 그룹, 차단 중 무엇을 적용할지 결정합니다. 그래서 규칙 순서가 매우 중요한데, 세밀한 규칙을 앞쪽에 두고 마지막 줄은 항상 MATCH 기본 규칙으로 마무리해야 합니다.
proxy-groups 항목에서 정의하는 노드 모음으로, 규칙의 전달 대상은 보통 개별 노드가 아니라 정책 그룹을 가리킵니다. 흔한 유형은 수동 선택인 select, 지연이 가장 낮은 노드를 자동으로 고르는 url-test, 순서대로 장애 전환하는 fallback입니다. 클라이언트의 프록시 화면에서 전환할 수 있는 그룹이 바로 이것입니다.
IP 소재지 데이터베이스로, GEOIP 규칙과 함께 써서 목적지 주소가 위치한 지역에 따라 라우팅합니다. GEOIP,CN,DIRECT는 거의 모든 설정에 들어가는 한 줄로, 목적지 IP가 중국 본토에 있으면 직접 연결하라는 뜻입니다. 데이터베이스는 코어나 클라이언트와 함께 주기적으로 갱신되며, 오래되면 소재지를 잘못 판단할 수 있습니다.
사이트 용도별로 정리한 도메인 분류 목록으로, GEOSITE,category-ads-all,REJECT 한 줄만으로 광고 도메인 전체를 하나하나 나열하지 않고 처리할 수 있습니다. GeoIP와의 차이는 GEOSITE는 도메인 단계에서, GeoIP는 IP로 해석된 뒤에 매칭한다는 점이며 전자가 먼저 적용됩니다.
rule-providers로 참조하는 외부 규칙 모음으로, 규칙 내용이 별도 파일로 원격에 저장되고 메인 설정에는 RULE-SET,이름,정책 한 줄만 남습니다. interval로 주기적인 자동 갱신을 설정할 수 있어 대규모 커스텀 규칙을 관리할 때 권장되는 방식입니다.
네트워크 기초
프록시를 켰는데도 도메인 조회가 여전히 로컬 통신사 DNS로 직접 전송되는 현상입니다. 결과는 두 가지로, 접속하려는 대상이 로컬 네트워크에 그대로 드러나고 해석 결과가 오염되어 연결이 실패할 수 있습니다. dns 항목에서 enhanced-mode: fake-ip를 켜고 암호화된 업스트림을 설정하는 것이 일반적인 대처법입니다.
프록시 경로가 UDP 패킷을 전달할 수 있는 능력입니다. 웹 브라우징은 대부분 TCP만 쓰지만 게임 멀티플레이, 음성 통화, 영상 회의는 UDP에 크게 의존하며, 노드나 프로토콜이 UDP를 지원하지 않으면 연결이 안 되거나 한쪽 소리만 나올 수 있습니다. 노드 설정의 udp: true가 이 지원 여부를 나타냅니다.
TLS 핸드셰이크에서 목적지 도메인을 평문으로 담는 확장 필드로, 서버가 어떤 인증서를 반환할지 이를 통해 결정하고 중간 장비도 이를 보고 트래픽 방향을 파악할 수 있습니다. Trojan 계열 프로토콜의 위장 효과는 SNI와 직접 관련되며, 노드 설정의 sni 또는 servername 필드가 이 값입니다.
127.0.0.1(localhost)은 기기 자신을 가리키며 데이터가 네트워크 카드 밖으로 나가지 않습니다. 시스템 프록시 설정에 127.0.0.1:7890을 입력하면 브라우저 트래픽을 로컬에서 7890 포트를 수신하는 Clash 클라이언트로 넘기고 이후 경로는 클라이언트가 결정한다는 뜻입니다. 이 주소는 해당 기기에서만 유효하며, 같은 네트워크의 다른 기기는 그 기기의 로컬 IP를 써야 합니다.
클라이언트 기능
서비스 제공자가 주는 URL로, 접속하면 전체 노드 목록(대개 YAML 설정 전체 또는 인코딩된 노드 목록)이 반환됩니다. 클라이언트에 등록하면 수동 또는 주기적으로 갱신을 받아 노드 변경 사항이 자동으로 반영됩니다. 갱신이 실패하면 먼저 브라우저로 구독 링크를 직접 열어 오류 페이지가 아니라 설정 내용이 반환되는지 확인해 보세요.
설정 파일의 proxies 항목에 있는 서버 정보 한 건으로, 주소, 포트, 프로토콜 종류, 인증 정보를 담고 있으며 실제로 트래픽이 빠져나가는 출구입니다. 클라이언트 프록시 화면에서 선택할 수 있는 각 항목이 바로 노드이며, 보통 정책 그룹에 묶여 규칙에 따라 사용 시점이 정해집니다.
클라이언트가 운영체제에 HTTP/SOCKS 프록시 주소를 등록하는 스위치로, 켜면 '시스템 설정을 따르는' 브라우저 등의 앱이 자동으로 프록시를 거칩니다. 다만 적용 범위가 한정적이라 시스템 설정을 읽지 않는 프로그램(대부분의 명령줄 도구, 일부 게임)은 영향을 받지 않으며, 이런 트래픽은 TUN 모드로 처리해야 합니다.
클라이언트가 노드를 거쳐 테스트 주소(흔히 http://www.gstatic.com/generate_204)로 HTTP 요청을 보내고 걸린 시간을 측정하며, 이 값은 단순 ping이 아니라 전체 경로의 품질을 나타냅니다. timeout으로 표시되면 해당 노드를 현재 쓸 수 없다는 뜻이며, url-test 정책 그룹은 이 결과를 기준으로 지연이 가장 낮은 노드를 자동으로 고릅니다.
클라이언트에서 문제를 살펴보는 두 화면입니다. 로그 화면은 코어의 동작 기록을 실시간으로 보여주며(수준은 log-level로 조절), 연결 화면은 현재 활성 연결마다 목적지, 적용된 규칙, 출구 노드를 나열합니다. 라우팅이 기대와 다를 때는 먼저 연결 화면에서 해당 도메인이 실제로 어떤 규칙에 걸렸는지 확인하는 편이 무작정 설정을 고치는 것보다 훨씬 빠릅니다.