홈/고급 설정

Clash 고급 설정 가이드

기본 연결을 성공한 후, Clash의 사용성을 실제로 좌우하는 것은 규칙 엔진과 프록시 그룹의 조합 방식입니다. 이 글에서는 매칭 순서, 4가지 프록시 그룹의 동작 차이, DNS와 Fake-IP의 원리, TUN 모드의 내부 동작 방식을 깊이 있게 분석하며, 각 섹션마다 실제로 사용 가능한 YAML 예시를 제공합니다.

🕒 읽는 데 약 20분 🧭 먼저 설치 가이드를 완료해 주세요 🔄 최근 업데이트: 2026년 7월

규칙 엔진은 어떻게 매칭될까

Clash의 규칙은 「위에서 아래로, 매칭되면 즉시 종료」되는 목록입니다. 모든 네트워크 요청은 rules 설정의 첫 줄부터 하나씩 비교되며, 어떤 규칙이 매칭되면 즉시 해당 규칙의 동작을 실행하고 이후 규칙은 전혀 확인하지 않습니다.

즉, 규칙의 순서 자체가 우선순위 설계입니다. 일반적인 구성 방식은 먼저 "반드시 직접 연결"해야 하는 규칙(내부망 주소, 국내 사이트 등)을 작성하고, 다음으로 "반드시 프록시를 거쳐야" 하는 특정 규칙을 작성한 뒤, 마지막으로 MATCH 기본 규칙으로 마무리해 "위 규칙에 모두 해당하지 않을 때 어떻게 할지"를 정의하는 것입니다.

config.yamlyaml
rules:
  # 1. 사설 네트워크 대역을 우선 직접 연결시켜 프록시를 통한 LAN 기기 접속의 우회를 방지
  - PRIVATE,DIRECT
  # 2. 중국 본토 IP는 직접 연결 (GEOIP 규칙 세트는 자동 업데이트됨)
  - GEOIP,CN,DIRECT
  # 3. 특정 도메인을 특정 프록시 그룹으로 강제 전달
  - DOMAIN-SUFFIX,openai.com,US-Node
  - DOMAIN-KEYWORD,googlevideo,Auto
  # 4. 기본 규칙: 위에서 매칭되지 않은 트래픽은 자동 선택으로
  - MATCH,Auto
⚠️

흔한 실수: MATCH 규칙을 중간에 작성하는 경우입니다. 매칭은 처음 일치하는 순간 종료되므로 MATCH 이후의 규칙은 절대 실행되지 않습니다. 반드시 rules 목록의 마지막 줄에 위치해야 합니다.

규칙 유형 상세 설명

Clash가 지원하는 규칙 유형은 크게 도메인 기준, 네트워크 주소 기준, 기타 속성 기준의 세 가지로 나뉩니다. 아래 표는 가장 자주 사용되는 유형을 정리한 것입니다.

규칙 유형예시설명
DOMAINDOMAIN,ad.example.com,REJECT단일 도메인을 정확히 매칭
DOMAIN-SUFFIXDOMAIN-SUFFIX,github.com,Proxy해당 도메인과 모든 하위 도메인을 매칭, 가장 많이 사용됨
DOMAIN-KEYWORDDOMAIN-KEYWORD,youtube,Proxy도메인에 키워드가 포함되면 매칭, 오탐 가능성에 주의
IP-CIDR / IP-CIDR6IP-CIDR,192.168.0.0/16,DIRECTIPv4/IPv6 대역으로 매칭
GEOIPGEOIP,CN,DIRECTIP가 속한 국가/지역 데이터베이스로 매칭
DST-PORT / SRC-PORTDST-PORT,443,Proxy목적지/출발지 포트로 매칭
PROCESS-NAMEPROCESS-NAME,WeChat.exe,DIRECT연결을 시작한 로컬 프로세스 이름으로 매칭(데스크톱 전용)
RULE-SETRULE-SET,reject,REJECTRule Provider 규칙 세트를 참조, 다음 섹션 참고
MATCHMATCH,Auto기본(catch-all) 규칙, 반드시 마지막 줄에 위치해야 함

각 규칙의 마지막 항목은 "동작"이며, DIRECT(직접 연결), REJECT(차단, 광고 제거에 자주 사용), 또는 특정 프록시 그룹의 이름(해당 그룹의 전략에 따라 노드를 선택하도록 트래픽을 넘김) 중 하나로 지정합니다.

Rule Provider: 규칙 세트 구독

수백 개의 도메인 규칙을 직접 작성하는 것은 현실적이지 않습니다. Clash는 rule-providers 기능을 제공해, 원격 URL에서 규칙 세트 파일을 다운로드하고 주기적으로 자동 업데이트할 수 있습니다. 설정에서는 한 번만 참조하면 됩니다.

config.yamlyaml
rule-providers:
  reject:
    type: http
    behavior: domain
    url: "https://example.com/rules/reject.txt"
    path: ./rules/reject.yaml
    interval: 86400

rules:
  - RULE-SET,reject,REJECT

behavior는 이 규칙 세트의 내용을 어떻게 해석할지 결정하며, 세 가지 값이 있습니다.

behavior규칙 세트 내용일반적인 용도
domain한 줄에 도메인 하나씩 (와일드카드 접두사 지원)광고 필터링, 사이트별 라우팅 도메인 목록
ipcidr한 줄에 IP 대역 하나씩GEOIP 데이터베이스에 없는 사용자 지정 IP 대역
classicalrules와 동일한 형식의 완전한 규칙 줄여러 규칙 유형이 혼합된 복잡한 집합

interval은 초 단위이며, 규칙 세트를 자동으로 다시 가져오는 간격을 의미합니다. "새로 차단해야 할 광고 도메인"이나 "새로 직접 연결해야 할 도메인"을 수동으로 유지 관리하지 않아도 최신 상태로 유지할 수 있습니다.

프록시 그룹: 4가지 스케줄링 전략

프록시 그룹(proxy-groups)은 여러 개의 구체적인 노드를 하나의 "전략 단위"로 묶은 것입니다. 규칙에서는 특정 노드가 아닌 그룹 이름을 참조하는데, 이를 통해 "자동으로 가장 빠른 노드 선택", "특정 노드가 다운되면 자동 전환" 같은 효과를 구현할 수 있습니다.

select: 수동 선택

  • 현재 사용할 노드를 완전히 수동으로 지정
  • 어떤 회선을 사용해야 할지 명확히 알고 있는 경우에 적합
  • 자동 속도 측정이나 자동 전환은 하지 않음

url-test: 자동 속도 측정

  • 그룹 내 모든 노드에 주기적으로 속도 측정 요청을 보냄
  • 항상 지연 시간이 가장 낮은 노드를 자동으로 사용
  • "신경 쓰기 싫고, 그냥 가장 빠른 걸 원한다"는 경우에 가장 적합

fallback: 장애 조치

  • 설정 순서대로 첫 번째 "정상" 노드를 사용
  • 현재 노드의 속도 측정이 실패했을 때만 다음 노드로 전환
  • 명확한 우선순위가 있고 장애 시에만 전환하고 싶은 경우에 적합

load-balance: 로드 밸런싱

  • 서로 다른 연결을 여러 노드에 분산
  • strategy는 일관 해싱 또는 라운드로빈 중 선택 가능
  • 여러 노드로 부하를 분산해 단일 노드의 속도 제한을 피하고 싶은 경우에 적합
config.yamlyaml
proxy-groups:
  - name: Auto
    type: url-test
    proxies: [HK01, HK02, JP01]
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50

  - name: US-Node
    type: fallback
    proxies: [US-West01, US-East01]
    url: "https://www.gstatic.com/generate_204"
    interval: 300

tolerance는 "허용 오차"이며 단위는 밀리초입니다. 새로운 속도 측정 결과가 현재 노드의 지연 시간과 이 범위 내에서 차이 난다면 노드를 자주 전환하지 않아, "지연 시간이 비슷한 두 노드 사이를 계속 왔다 갔다 하는" 현상을 방지합니다.

DNS와 Fake-IP

DNS 해석의 정확성은 규칙 기반 라우팅이 제대로 작동하는지를 좌우하는 핵심 요소입니다. 도메인이 잘못된 IP로 해석되거나 통신사 DNS가 변조되면, 아무리 정확한 규칙이라도 소용이 없습니다. Clash의 내장 DNS 모듈은 바로 이 문제를 해결하기 위해 만들어졌습니다.

핵심은 두 가지 도메인 해석 모드입니다.

Fake-IP 모드

  • 각 도메인에 로컬에서만 유효한 가상 IP를 할당
  • 실제 DNS 해석은 연결이 실제로 시작될 때까지 지연됨
  • 규칙 매칭을 도메인으로 직접 수행할 수 있어 호환성이 가장 뛰어남
  • 데스크톱 TUN 모드에서 권장되는 기본 설정

Redir-Host 모드

  • 실제 해석 결과를 그대로 반환
  • "전통적인" 네트워크 동작 방식에 가까우며, IP에 민감한 일부 프로그램과 호환성이 좋음
  • 규칙 내 IP-CIDR/GEOIP 판단이 더 정확해짐
  • 라우터/게이트웨이 환경에서 더 흔히 사용됨
config.yamlyaml
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

핵심 아이디어는 다음과 같습니다: nameserver에는 사용 중인 ISP의 일반 DNS를 설정해 빠른 로컬 해석에 우선 사용합니다. fallback-filter가 결과가 의심스럽다고 판단하면(해석된 IP가 예상 지역과 일치하지 않거나, 변조가 의심되거나, 해당 도메인이 실제로 다른 지역에 있는 경우) fallback에 있는 암호화 DNS로 다시 해석해 속도와 정확성을 모두 확보하는 방식입니다.

TUN 모드의 내부 동작 원리

시스템 프록시는 "프록시를 사용해야 한다는 것을 아는" 애플리케이션(브라우저, 대부분의 데스크톱 소프트웨어)만 처리할 수 있지만, 많은 프로그램(게임, 커맨드라인 도구, 일부 모바일 앱)은 시스템 프록시 설정을 읽지 않습니다. 이때 필요한 것이 TUN 모드입니다.

TUN 모드의 본질은 운영체제 안에 가상 네트워크 어댑터를 생성하고, 시스템의 기본 라우팅을 이 어댑터로 지정하는 것입니다. 이렇게 하면 어떤 프로그램이 "프록시를 인식하고 있는지" 여부와 관계없이, 해당 프로그램이 보내는 모든 네트워크 패킷이 먼저 이 가상 어댑터를 통과하게 되고, Clash가 이를 가로채 규칙에 따라 처리한 뒤 직접 연결할지 특정 프록시 노드로 전달할지 결정합니다. 이는 애플리케이션 계층에서 프로그램에게 프록시를 사용하도록 "설득"하는 것이 아니라, 네트워크 계층에서 전체를 가로채는 방식입니다.

config.yamlyaml
tun:
  enable: true
  stack: system
  dns-hijack:
    - any:53
  auto-route: true
  auto-detect-interface: true

stack은 일반적으로 system 또는 gvisor 중에서 선택할 수 있습니다. system은 시스템의 네이티브 네트워크 스택을 사용해 성능이 더 좋고, gvisor는 순수 사용자 공간에서 구현된 네트워크 스택으로 호환성이 더 뛰어나며, 일부 시스템에서 TUN 드라이버가 불안정할 때 전환해 시도해볼 수 있습니다.

💡

TUN 모드는 네트워크 계층에서 동작하기 때문에 가상 네트워크 어댑터를 생성하기 위한 시스템 권한(관리자/root, 또는 macOS의 시스템 확장 승인)이 필요합니다. 이것이 설치 가이드에서 "관리자 권한으로 실행"이 반복해서 언급되는 이유입니다.

스크립트와 Logic 규칙

일반 규칙 유형으로 부족할 때, Clash의 확장 코어(mihomo 등)는 더 유연한 두 가지 작성 방식을 지원합니다.

  • Logic 규칙: AND / OR / NOT으로 여러 조건을 조합합니다. 예를 들어 "목적지 포트가 443이고 동시에 특정 IP 대역에 속할 때만" 프록시를 사용하도록 하려면 AND,((DST-PORT,443),(IP-CIDR,10.0.0.0/8))처럼 작성합니다.
  • Script Provider: 짧은 스크립트를 작성해, 실행 시점에 해당 요청이 어떤 프록시 그룹을 사용해야 하는지 동적으로 반환할 수 있습니다. "현재 네트워크 환경에 따라", "시간대에 따라" 등 일반 규칙으로는 표현할 수 없는 복잡한 판단에 사용되는 고급 기능이므로, 먼저 일반 규칙에 익숙해진 뒤 시도하는 것을 권장합니다.

성능 및 사용성 튜닝

  • url-test의 interval을 줄이면 느려진 노드를 더 빨리 감지할 수 있지만, 속도 측정 요청 빈도와 배터리 소모도 함께 증가합니다. 데스크톱에서는 300초, 모바일에서는 600초 이상을 권장합니다.
  • 규칙 세트를 너무 많이 추가하지 마세요. rule-providers를 하나 추가할 때마다 메모리를 사용하고 규칙 매칭 연산량도 늘어납니다. 서로 겹치는 소스 십여 개를 쌓기보다는 활발히 관리되고 범위가 넓은 규칙 세트를 우선 선택하세요.
  • rules를 합리적으로 정렬하세요. 매칭률이 가장 높은 규칙(예: GEOIP,CN,DIRECT)을 가능한 앞쪽에 배치하면 대부분의 요청이 더 빠르게 매칭을 완료해, 불필요한 줄 단위 비교를 줄일 수 있습니다.
  • 모바일에서는 TUN보다 시스템 프록시를 우선 사용하세요. 프록시를 인식하지 못하는 앱을 반드시 처리해야 하는 경우가 아니라면, TUN 모드는 일부 스마트폰에서 백그라운드 배터리 소모를 더 높입니다.

이 섹션들의 내용을 실제 설정과 대조하며 한 번 읽어본 뒤에는, 설정 파일 전체 레퍼런스를 참고해 각 항목의 기본값과 값 범위를 하나씩 확인하며 전체적인 지식 지도를 완성하시기 바랍니다.