브라우저에서 URL을 열 때 트래픽이 직접 전송되지 않습니다. Clash는 로컬에서 하나 이상의 포트를 수신하고 모든 아웃바운드 연결을 가로채며 규칙 엔진의 판단에 따라 「직접 연결」 또는 「프록시 아웃바운드」를 결정합니다.
전체 링크는 5단계로 나뉘며 각 단계마다 Clash의 명확한 개입 지점이 있습니다.
rules 목록에 따라 도메인, IP, 프로세스 이름 등의 조건을 위에서 아래로 하나씩 비교합니다.
규칙 엔진은 Clash의 가장 핵심적인 기능입니다. rules 목록의 첫 번째 항목부터 마지막까지 한 줄씩 비교합니다. 가장 먼저 일치하는 규칙이 즉시 적용되며 후속 규칙은 더 이상 실행되지 않습니다. 순서가 모든 것을 결정합니다.
가장 흔히 사용되는 유형으로 도메인 또는 접미사 수준까지 정확하여 특정 웹사이트의 분할에 적합합니다.
대상 IP 주소 또는 GeoIP 데이터베이스 판단을 기반으로 하며 「국내 직접 연결, 해외 프록시」의 핵심 규칙입니다.
응용 프로그램 프로세스 이름이나 포트 번호에 따라 트래픽을 라우팅하며 특정 소프트웨어(예: 개발 도구, 게임 클라이언트)의 출구를 별도로 구성하는 데 적합합니다.
수백 또는 수천 개의 규칙을 원격 구독 파일로 패키징하고 클라이언트가 정기적으로 업데이트를 가져오는 대규모 라우팅 솔루션의 표준 관행입니다.
interval을 설정하여 정기적인 자동 업데이트가 가능합니다.규칙은 위에서 아래로 순차적으로 일치시킵니다. 첫 번째 일치가 적용되고 후속 규칙은 실행되지 않습니다. 흔한 실수: GEOIP 앞에 MATCH,DIRECT를 두면 모든 트래픽이 직접 연결됩니다. 권장 순서:
IP-CIDR 192.168.0.0/16) → DIRECTGEOIP,CN,DIRECT—IP가 중국에 속하면 직접 연결.MATCH,Proxy—낙수 효과, 일치하지 않는 트래픽은 프록시 사용.Clash는 트래픽을 인계받는 두 가지 방법을 지원합니다. 잘못된 모드를 선택하는 것은 「일부 앱이 프록시를 사용하지 않는」 일반적인 근본 원인입니다.
stack 옵션: system은 고성능을 위해 시스템 네트워크 스택을 사용하고, gvisor 사용자 공간 네트워크 스택은 호환성이 더 좋습니다. Mihomo 커널은 mixed 혼합 모드도 지원합니다.
DNS 유출은 프록시 사용자가 가장 간과하기 쉬운 보안 사각지대입니다. 트래픽은 프록시를 통과하지만 DNS 쿼리는 로컬 ISP로 평문 전송되어 방문하는 도메인이 노출될 수 있습니다. Clash는 이를 해결하기 위해 완벽한 내장 DNS 모듈을 갖추고 있습니다.
Clash가 DNS 요청을 받으면 즉시 가짜 IP(예: 198.18.x.x)를 반환하여 앱이 가능한 한 빨리 연결을 시작할 수 있도록 합니다. 실제 DNS 파싱은 프록시 쪽으로 지연되어 로컬에서의 조기 도메인 노출을 방지합니다.
198.18.0.1 반환실제 DNS 파싱이 먼저 로컬에서 완료되고 도메인이 실제 IP로 변환된 후 규칙 엔진에 전달되어 GEOIP 일치를 수행합니다. 호환성은 더 좋지만 DNS 쿼리 자체가 로컬 ISP에 유출될 위험이 있습니다.
fallback 및 fallback-filter 연동: 도메인이 해외 IP로 파싱되면 오염을 방지하기 위해 암호화된 DoT / DoH 서버를 사용하여 자동으로 재해석합니다.
프로토콜은 트래픽 암호화 및 난독화 전략을 결정합니다. Clash는 기본적으로 여러 프로토콜을 지원하며 Mihomo(Clash Meta) 커널은 차세대 프로토콜에 대한 지원을 더욱 확장합니다.
대칭 암호화(AES / ChaCha20)를 사용하여 트래픽을 암호화하여 심층 패킷 분석(DPI)에 저항하는 무작위 데이터처럼 보이게 합니다. 간단한 프로토콜 설계와 가장 광범위한 클라이언트 지원을 제공합니다.
V2Ray 프로젝트에서 설계한 독점 프로토콜로 암호화 외에 타임스탬프 확인 및 난독화 기능을 추가합니다. WebSocket + TLS와 함께 사용하여 HTTPS 트래픽으로 위장할 수 있으며 강력한 차단 방지 기능이 있습니다.
프록시 데이터를 TLS 계층에서 직접 전송하여 추가 난독화 없이 일반 HTTPS와 똑같이 보이게 합니다. 서버는 프록시 특성을 더욱 숨기기 위해 실제 웹 응답도 제공합니다.
QUIC(UDP) 기반의 차세대 고성능 프로토콜로 지연 시간이 길고 패킷 손실이 많은 환경(예: 국가 간 링크)에서 TCP 프로토콜보다 월등히 뛰어난 성능을 발휘합니다. 불안정한 네트워크 시나리오를 위해 설계되었습니다.
마찬가지로 QUIC 기반이며 저지연 및 연결 재사용에 중점을 둡니다. 0-RTT 핸드셰이크 설계로 첫 패킷 지연을 줄여 응답 속도에 민감한 시나리오(예: 게임, 실시간 시청각)에 적합합니다.
최소한의 코드와 간단한 감사를 제공하는 현대적인 VPN 프로토콜로 ChaCha20 + Poly1305 암호화를 사용하며 커널 수준 구현으로 매우 높은 성능을 제공합니다. Mihomo는 WireGuard를 아웃바운드 프로토콜로 지원합니다.
정책 그룹은 규칙을 「패키징」하고 노드를 「스케줄링」하는 핵심 메커니즘입니다. 규칙에 일치하면 트래픽이 노드로 직접 전송되지 않고 정책 그룹으로 전송됩니다. 정책 그룹은 자동 속도 테스트 및 장애 조치와 같은 기능을 통해 사용할 노드를 결정합니다.
사용자가 노드 목록에서 현재 사용할 노드를 수동으로 선택하며 일반적으로 클라이언트 인터페이스에 직접 표시됩니다. 출구를 정밀하게 제어하려는 사용자에게 적합합니다.
정기적으로 모든 노드에 HTTP 프로브 요청을 보내고 응답 지연 시간이 가장 낮은 노드를 자동으로 선택합니다. 지연 시간이 임계값을 초과할 때만 전환하여 빈번한 지터를 방지합니다.
순서대로 첫 번째 노드를 사용하며 건강 상태 확인에 실패하면 자동으로 두 번째 노드로 전환합니다. 안정성 보장이 필요한 시나리오에 적합합니다.
여러 노드가 번갈아 가며 트래픽을 처리하여 연결을 분산시키고 전체 처리량을 향상시킵니다. Mihomo는 동일한 세션이 동일한 노드를 사용하도록 일관된 해싱을 지원합니다.
Clash는 현재 두 개의 주요 브랜치가 있으며 일상적으로 혼용되지만 프로토콜 지원 및 TUN 향상 기능에서 큰 성능 차이가 있습니다.
결론: 신규 사용자는 타협 없이 더 완벽한 프로토콜 지원과 TUN 기능을 얻으려면 Mihomo(Clash Meta) 커널을 기반으로 하는 클라이언트(예: Clash Verge Rev, Mihomo Party, Clash Meta for Android)를 직접 선택해야 합니다. 클래식 Clash 커널 클라이언트는 여전히 안정적이지만 프로토콜 생태계의 지속적인 업데이트는 Mihomo 브랜치에 집중되어 있습니다.
MATCH가 맨 위에 있으면 그 아래의 모든 규칙은 트리거되지 않습니다. 합리적인 순서는 다음과 같습니다: 로컬 네트워크 → 명시적 프록시 도메인 → 명시적 직접 연결 도메인 → GEOIP → MATCH 낙수 효과.198.18.x.x IP 범위를 특별하게 처리하여 이상 현상을 일으킬 수 있습니다. Clash는 fake-ip-filter 구성 항목을 제공하여 특정 도메인을 Fake-IP에서 제외하고 일반적인 DNS 파싱을 사용하도록 설정할 수 있습니다.system 스택은 gvisor보다 성능이 높습니다. 기기 성능이 부족한 경우 전역적으로 TUN을 활성화하는 대신 특정 앱에 대해 시스템 프록시를 활성화할 수 있습니다.http://www.gstatic.com/generate_204(빈 204 응답 반환) 또는 http://cp.cloudflare.com/generate_204가 사용됩니다. 국내 주소로 인한 오판을 방지하기 위해 프록시를 통해 접근 가능한 해외 주소를 사용하는 것이 좋습니다.