Advanced Manual

Clash 고급 설정 매뉴얼

기본 설치를 마친 사용자를 대상으로, 정책 그룹·규칙 분기·DNS·TUN과 Fake-IP·도메인 스니핑·오버라이드 병합·제어판까지 7대 주제로 나누어 필드 의미와 파라미터 선택, 재사용 가능한 설정 예시를 정리했습니다.

이 페이지는 설치 튜토리얼과 상호 보완적인 두 갈래 경로입니다. 튜토리얼 페이지는 "다운로드부터 연결까지"의 주요 흐름을 다뤄 Clash를 처음 접하는 사용자가 단계별로 따라 하기 좋고, 이 페이지는 체계적으로 찾아볼 수 있는 매뉴얼로서 특정 필드를 수정하거나 특정 유형의 분기 이상을 조사하거나 설정 뒤의 동작 원리를 이해하고 싶을 때 목차에서 해당 챕터로 바로 이동하면 됩니다. 본문의 모든 예시는 현재 주류 클라이언트가 널리 채택한 mihomo 커널 문법을 기준으로 하며, 다운로드 페이지에 나열된 Clash Plus, Clash Verge Rev, FlClash 등 클라이언트에서 바로 사용할 수 있습니다. 일부 필드는 구버전 오리지널 커널에 존재하지 않으며, 해당 부분은 별도로 표시했습니다. 용어가 헷갈릴 때는 언제든 개념 사전을 참고하세요.

설정 파일 뼈대와 표기 규칙

Clash의 모든 동작은 하나의 YAML 설정 파일로 구동됩니다. 클라이언트 UI의 모든 스위치—프록시 모드, LAN 공유, TUN, 패널 포트—는 결국 이 파일의 특정 필드로 귀결됩니다. 최상위 필드의 역할 분담을 이해하는 것이 이후 모든 챕터를 읽어내는 전제입니다. 인바운드 부분은 트래픽이 어디로 들어오는지(포트, TUN 어댑터)를 결정하고, 아웃바운드 부분은 트래픽이 어디로 나가는지(노드, 정책 그룹)를 결정하며, 규칙 부분은 "어떤 트래픽이 어떤 출구로 갈지"를 결정하고, DNS와 스니핑 부분은 커널이 연결의 실제 목적지를 어떻게 식별하는지를 결정합니다.

최상위 필드 개요

필드범위한 줄 설명
mixed-port인바운드HTTP와 SOCKS5를 통합한 혼합 리스닝 포트, 시스템 프록시가 이곳을 가리킴
allow-lan인바운드LAN 내 다른 기기가 본 기기 포트에 접속하는 것을 허용할지 여부
tun인바운드가상 네트워크 어댑터 설정, 시스템 프록시가 커버하지 못하는 트래픽을 인수
mode스케줄링rule / global / direct 세 가지 실행 모드
proxies아웃바운드노드 정의 목록, 보통 구독에서 제공
proxy-groups아웃바운드정책 그룹, 노드를 선택 가능하고 속도 측정 가능한 집합으로 구성
proxy-providers아웃바운드노드 제공자, 여러 구독을 URL 기준으로 외부화 관리
rules스케줄링분기 규칙, 위에서 아래로 매칭하여 트래픽 출구를 결정
rule-providers스케줄링규칙 제공자, 대용량 규칙을 갱신 가능한 규칙셋으로 외부화
dns해석내장 DNS 모듈, Fake-IP·분기 해석·유출 방지 설정 포함
sniffer해석도메인 스니핑, 트래픽에서 실제 도메인을 복원
external-controller관리RESTful API 리스닝 주소, 외부 제어판이 이에 의존
log-level관리로그 레벨, 문제 해결 시 임시로 debug로 전환

표기 규칙

이후 모든 YAML 예시는 세 가지 규칙을 따릅니다. 들여쓰기는 항상 공백 2칸을 사용하며 탭은 쓰지 않습니다. 불리언 값은 항상 소문자 true / false로 표기합니다. 예시 조각은 구독 원문을 수정하지 않고 클라이언트의 오버라이드 영역(오버라이드 챕터 참고)에 바로 붙여넣어 효과를 확인할 수 있습니다. 필드명 전체 목록과 항목별 설명은 개념 사전의 설정 파일 필드 분류에 정리되어 있으며, 이 페이지에서는 고급 사용 중 실제로 손대야 하는 부분만 다룹니다.

커널 차이에 관하여

오리지널 Clash 커널 저장소는 이미 보관 처리(archive)되었으며, 이 페이지에서 다루는 sniffer, nameserver-policy 일부 문법, format: mrs 등의 기능은 mihomo 커널만 지원합니다. 두 세대 커널의 전체 차이 비교는 블로그 글 《mihomo 커널과 오리지널 Clash 코어 차이 총정리》에서 확인할 수 있습니다.

정책 그룹 유형과 실전

정책 그룹(proxy-groups)은 노드와 규칙 사이의 스케줄링 계층입니다. 규칙은 특정 노드를 직접 가리키지 않고 정책 그룹을 가리키며, 그룹 내부에서 현재 실제로 사용할 노드를 결정합니다. 이 간접 계층은 두 가지 이점을 줍니다. 구독 노드가 추가·삭제·이름 변경되어도 규칙을 따라 바꿀 필요가 없고, "자동 속도 측정", "장애 전환", "수동 지정" 등 서로 다른 전략으로 용도별 트래픽을 관리할 수 있습니다.

자주 쓰는 네 가지 유형

유형선택 로직대표 용도
select완전히 사용자가 수동으로 선택, 자동 전환 없음최상위 총괄 스위치 그룹, 고정 출구가 필요한 업무 그룹
url-test주기적으로 지연 시간을 측정해 가장 빠른 노드를 자동 선택일상 브라우징 등 속도에 민감한 일반 트래픽
fallback목록 순서대로 가용성을 검사, 처음 살아있는 노드가 적용됨주/보조 구조: 평소엔 메인 노드, 장애 시 자동으로 보조로 전환
load-balance해시 또는 라운드로빈으로 연결을 여러 노드에 분산대량 동시 다운로드, 단일 노드의 속도 제한 회피

이 외에 relay(체인 릴레이) 유형도 있으나 mihomo는 더 이상 권장하지 않으며, 체인 연결이 필요하면 노드 단위의 dialer-proxy 필드로 구현하는 것이 더 제어하기 쉽습니다.

핵심 파라미터 선택

자동형 정책 그룹의 동작은 네 가지 파라미터로 결정됩니다. url은 헬스 체크의 대상 주소로, 가볍고 안정적인 프로브 엔드포인트를 선택해야 하며 흔히 https://www.gstatic.com/generate_204를 사용합니다. interval은 검사 주기(초)로, 너무 짧으면 프로브가 자주 발생해 트래픽을 낭비하고 너무 길면 장애 전환이 둔감해지므로 일상적으로는 300초가 균형점입니다. tolerance는 url-test에만 적용되며, 신구 노드의 지연 차이가 이 밀리초 값을 초과해야 전환한다는 뜻으로 50~100으로 설정하면 지연이 근접한 두 노드 사이의 왔다 갔다 하는 흔들림을 줄일 수 있습니다. lazy를 true로 설정하면 사용되지 않는 그룹은 헬스 체크를 실행하지 않아 백그라운드 프로브량을 크게 줄일 수 있습니다.

proxy-groups:
  - name: 노드 선택
    type: select
    proxies:
      - 자동 속도 측정
      - 장애 전환
      - 홍콩 노드
      - 일본 노드
      - DIRECT

  - name: 자동 속도 측정
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 60
    lazy: true
    proxies:
      - 홍콩 노드
      - 일본 노드

  - name: 홍콩 노드
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    include-all: true
    filter: "(?i)hk|hong|港"

중첩 그룹 실전

규모 있는 관리에서 흔히 쓰는 방식은 2계층 구조입니다. 하단은 지역별 자동 그룹(홍콩, 일본, 싱가포르 각각 하나의 url-test 그룹, filter 정규식으로 전체 노드 중에서 걸러냄)을 만들고, 상단은 용도별 수동 그룹(스트리밍, 개발 도구, 총 출구 각각 하나의 select 그룹, 후보는 개별 노드가 아니라 지역 그룹)을 만드는 것입니다. 이렇게 하면 구독의 노드가 바뀌어도 지역 그룹이 자동으로 다시 정리되고, 사용자는 일상적으로 상단 그룹 사이에서만 전환하면 되며 패널 목록도 수백 개의 노드 이름에 파묻히지 않습니다. include-all: true와 filter의 조합은 mihomo가 제공하는 필터링 문법으로, 정규식은 대소문자를 구분하지 않도록 (?i) 접두사를 붙이는 것을 권장합니다. 그룹을 작성한 뒤에는 rules 안의 출구 이름과 그룹 이름이 글자 하나까지 일치하는지 확인해야 하며, YAML에서 그룹 이름에 공백이나 특수문자가 포함되면 인용부호로 감싸는 것이 더 안전합니다.

규칙 분기 기초와 매칭 순서

규칙(rules)은 Clash의 핵심 스케줄링 표로, mode: rule일 때만 적용됩니다. 각 규칙은 "유형, 매칭 값, 출구" 세 부분으로 구성되며, 커널은 새 연결마다 위에서 아래로 하나씩 대조하고 첫 번째로 일치하면 즉시 멈추며 이후 규칙은 더 이상 관여하지 않습니다. 이 "첫 매칭 우선" 원칙은 규칙 순서 자체가 우선순위임을 의미합니다. 같은 도메인이 10번째 규칙과 200번째 규칙에 동시에 매칭될 수 있어도 실제로 적용되는 것은 항상 10번째입니다. "어떤 사이트가 왜 잘못된 출구로 나가는지" 조사할 때 첫 단계는 언제나 로그나 패널의 연결 페이지에서 어느 규칙에 매칭됐는지 확인하는 것입니다.

자주 쓰는 규칙 유형

  • DOMAIN: 완전한 도메인 정확 매칭, 완전히 동일한 호스트명만 매칭됩니다.
  • DOMAIN-SUFFIX: 접미사 매칭, example.com은 자기 자신과 모든 서브도메인에 매칭되며 가장 흔히 쓰이는 유형입니다.
  • DOMAIN-KEYWORD: 키워드 매칭, 도메인 내 어느 위치든 포함되면 매칭되며 오탐 범위가 넓어 신중히 사용해야 합니다.
  • IP-CIDR / IP-CIDR6: 목적지 IP 대역으로 매칭, 로컬 네트워크 직결과 특정 서비스의 IP 대역에 흔히 사용됩니다.
  • GEOIP: IP 지리 데이터베이스로 매칭, GEOIP,CN,DIRECT는 중국 본토 IP 직결의 표준 표기입니다.
  • GEOSITE: 내장 도메인 분류 라이브러리로 매칭(mihomo 특성), 하나의 규칙으로 한 카테고리 전체 사이트를 커버합니다.
  • PROCESS-NAME: 연결을 시작한 프로세스 이름으로 매칭, 특정 앱을 전체 직결 또는 전체 프록시로 보내는 데 적합하며 데스크톱과 TUN 모드에서 사용 가능합니다.
  • RULE-SET: 외부 규칙셋을 참조, 다음 챕터 참고.
  • MATCH: 기본 규칙, 남은 모든 트래픽에 매칭되며 반드시 마지막 줄에만 위치해야 합니다.

no-resolve와 순서 권장 사항

IP 계열 규칙(IP-CIDR, GEOIP)에는 눈에 잘 보이지 않는 부작용이 있습니다. 연결 목적지가 도메인일 때 커널은 대조 전에 반드시 도메인을 IP로 해석해야 하며, 이 해석은 로컬 DNS를 거칠 수 있어 매칭을 지연시키고 불필요한 해석 요청을 유발할 수 있습니다. IP 규칙 끝에 no-resolve 파라미터를 붙이면 해당 규칙이 순수 도메인 연결은 건너뛰고 이미 IP인 목적지만 대조하게 됩니다. 실무에서 권장하는 순서는: 프로세스 규칙과 정확한 도메인 규칙을 가장 앞에, 도메인 접미사와 규칙셋을 중간에, GEOIP,CN 같은 IP 규칙은 모든 도메인 규칙 뒤에, MATCH를 마지막에 두는 것입니다. 이렇게 하면 대부분의 연결이 도메인 단계에서 분기가 끝나 해석을 트리거하지 않습니다.

rules:
  - PROCESS-NAME,Telegram,노드 선택
  - DOMAIN,dl.google.com,노드 선택
  - DOMAIN-SUFFIX,openai.com,노드 선택
  - RULE-SET,ads-block,REJECT
  - RULE-SET,cn-sites,DIRECT
  - GEOSITE,category-games,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,노드 선택
주의

MATCH 뒤에 오는 어떤 규칙도 죽은 코드입니다. MATCH가 없으면 매칭되지 않은 트래픽의 흐름은 커널 기본 동작에 따라 달라져 문제 해결 시 혼란스러울 수 있습니다. 규칙 작성을 마치면 마지막 줄이 반드시 MATCH이고 출구가 실제로 존재하는 정책 그룹을 가리키는지 확인하세요. 사용자 정의 규칙을 조직하는 더 많은 아이디어는 튜토리얼 페이지의 모드 선택 섹션을 참고하세요.

규칙셋 구독화 관리

수천 개의 도메인 규칙을 메인 설정에 직접 작성하면 두 가지 장기적 비용이 발생합니다. 설정 파일이 비대해지고 읽기 어려워지며, 규칙 라이브러리를 갱신할 때마다 설정 전체를 통째로 교체해야 합니다. rule-providers(규칙 제공자)는 규칙을 독립된 파일로 외부화하여 커널이 주기적으로 자동 다운로드·갱신하게 하고, 메인 설정에는 RULE-SET 참조 한 줄만 남깁니다. 이렇게 하면 규칙 내용의 유지보수가 메인 설정과 분리되며, 이것이 커뮤니티가 관리하는 대형 분기 규칙 라이브러리의 표준 연동 방식입니다.

필드 구조

rule-providers:
  cn-sites:
    type: http
    behavior: domain
    format: yaml
    url: "https://example.com/rules/cn-domains.yaml"
    path: ./rules/cn-sites.yaml
    interval: 86400
  ads-block:
    type: http
    behavior: domain
    format: mrs
    url: "https://example.com/rules/reject.mrs"
    path: ./rules/ads-block.mrs
    interval: 86400

type이 http이면 원격 다운로드를 의미합니다(그 외 file은 로컬 파일 참조). path는 로컬 캐시 경로로, 다운로드에 실패해도 커널은 캐시를 계속 사용하므로 한 번의 네트워크 변동으로 규칙 전체를 잃지 않습니다. interval은 자동 갱신 주기(초)로, 규칙 라이브러리는 보통 하루에 한 번 갱신되므로 86400이면 충분합니다. format은 yaml, text, 그리고 mihomo 고유의 바이너리 포맷 mrs를 지원하며, 후자는 용량이 작고 로딩이 빨라 대형 규칙셋에 우선 권장됩니다.

behavior의 세 가지 값

값파일 내용매칭 의미
domain순수 도메인 목록, +.example.com은 서브도메인 포함을 의미전체 집합이 도메인 접미사 기준으로 매칭, 성능이 가장 좋음
ipcidr순수 IP 대역 목록전체 집합이 CIDR 기준으로 매칭, 참조 시 no-resolve를 붙일 수 있음
classical완전한 규칙 라인, 유형이 혼재규칙을 한 줄씩 인라인으로 넣는 것과 동일, 유연하지만 오버헤드가 가장 큼

behavior는 파일의 실제 내용과 반드시 일치해야 하며, 잘못 쓰면 규칙셋을 로드해도 전부 매칭되지 않습니다. 이는 규칙셋이 작동하지 않는 가장 흔한 원인이며, 그 다음은 RULE-SET 참조 이름과 provider 키 이름이 일치하지 않는 경우입니다. 또한 규칙셋 자체의 다운로드 요청도 하나의 트래픽이라는 점에 주의해야 합니다. 규칙 라이브러리의 소스 서버가 프록시를 거쳐야만 접근 가능하다면 provider에 proxy: 노드 선택을 추가해 다운로드 출구를 지정하면, 처음 시작할 때 "규칙이 다운로드되지 않아 사용할 규칙이 없는" 교착 상태를 피할 수 있습니다.

DNS 설정 최적화와 유출 방지

DNS는 고급 설정 중 투자 대비 효과가 가장 높으면서도 가장 쉽게 간과되는 부분입니다. 기본적으로 운영체제의 DNS 조회는 프록시를 거치지 않습니다. 트래픽 자체는 이미 암호화되어 전달되고 있어도 도메인 해석 요청은 여전히 평문으로 로컬 통신사의 DNS 서버로 전송될 수 있습니다. 이것이 바로 "Clash DNS 유출"의 원인으로, 해석 기록에는 어떤 사이트에 접속했는지가 그대로 노출됩니다. 커널의 dns 모듈을 활성화하고 계층별로 올바르게 설정해야 해석 동작도 통제 범위에 넣을 수 있습니다.

해석기의 세 계층

mihomo의 DNS 설정은 세 계층으로 나뉩니다. default-nameserver는 딱 한 가지 역할, 즉 이후 DoH/DoT 서버 자신의 도메인을 해석하는 역할만 하므로 반드시 순수 IP 주소로 채워야 합니다. nameserver는 메인 해석 그룹으로 대부분의 조회를 담당하며, 암호화 전송을 지원하는 DoH 주소를 채우는 것을 권장합니다. fallback은 선택적인 보조 그룹으로 fallback-filter와 함께 사용됩니다. 메인 그룹이 반환한 결과가 필터 조건에 걸리면(예: 해석 결과가 GEOIP CN 범위 밖에 있는 경우) 보조 그룹의 결과로 대체합니다. 이 메커니즘의 목적은 중국 본토 도메인은 응답이 빠른 국내 해석기가 처리하고 해외 도메인은 오염되지 않은 암호화 해석기가 처리하도록 하여 속도와 정확성을 모두 확보하는 것입니다.

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://doh.pub/dns-query
    - https://dns.alidns.com/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

nameserver-policy로 정밀 분기

fallback의 "결과 기준 둘 중 하나 선택"이 충분히 세밀하지 않다면, nameserver-policy는 조회 대상 도메인에 따라 해석기를 직접 지정할 수 있게 합니다. 키는 도메인 접미사, geosite: 카테고리, 심지어 rule-set: 참조도 가능하며, 값은 해석기 목록입니다. 대표적인 사용법은 geosite:cn은 국내 DoH로, 그 외는 해외 DoH로 보내 조회 입구 단계부터 분기를 완료하는 것으로, 결과를 받은 후 보완하는 방식보다 앞서 처리됩니다.

dns:
  nameserver-policy:
    "geosite:cn":
      - https://doh.pub/dns-query
    "+.internal.corp":
      - 10.0.0.53
유출 자가 점검

설정을 마쳤다면 실제로 검증해야 합니다. 브라우저로 임의의 DNS 유출 검사 사이트에 접속해 나열된 해석 서버에 여전히 로컬 통신사 주소가 포함되는지 확인하세요. 시스템 프록시 모드를 사용 중이라면 브라우저 자체의 보안 DNS(DoH) 설정이 Clash의 직결 해석기를 우회할 수 있다는 점에 주의하고, 테스트 전 브라우저 내장 DoH를 먼저 끄고 판단하세요. TUN 모드에서는 dns-hijack과 함께 사용하면 모든 평문 해석을 강제로 가로챌 수 있습니다. 다음 챕터에서 다룹니다.

TUN 모드와 Fake-IP 메커니즘

시스템 프록시의 본질은 "알림"입니다. 운영체제가 프록시 주소를 환경 설정에 기록하고, 이 약속을 따르는 애플리케이션(브라우저, 대부분의 데스크톱 소프트웨어)이 자발적으로 트래픽을 Clash에 넘깁니다. 하지만 커맨드라인 도구, 일부 게임 클라이언트, 그리고 거의 모든 UDP 트래픽은 이 약속을 신경 쓰지 않으며 이들의 연결은 프록시를 직접 우회합니다. TUN 모드는 다른 방식을 취합니다. 시스템에 가상 네트워크 어댑터를 만들어 기본 라우팅을 인수하면, 모든 트래픽이 네트워크 계층에서 가로채져 애플리케이션이 우회할 방법이 없어집니다. 두 메커니즘의 전체 비교와 시나리오별 선택은 블로그 글 《Clash TUN 모드와 시스템 프록시의 차이점》에서 확인할 수 있습니다.

tun 필드 설정

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

stack은 TUN 패킷을 처리하는 프로토콜 스택을 결정합니다. system은 운영체제 네트워크 스택을 그대로 사용해 성능이 좋지만 시스템 환경에 민감합니다. gvisor는 사용자 공간 구현으로 호환성이 가장 안정적입니다. mixed는 두 장점을 취합니다(TCP는 system, UDP는 gvisor)으로, 현재 대부분의 시나리오에서 권장되는 값입니다. auto-route는 라우팅 테이블에 자동으로 기록해 트래픽을 가상 네트워크 어댑터로 유도하고, auto-detect-interface는 물리적 출구 어댑터를 자동으로 식별해 루프백을 방지합니다. 이 두 항목은 라우터 등 복잡한 네트워크 토폴로지에서 라우팅을 수동으로 제어해야 하는 경우가 아니라면 일반적으로 켜둔 상태로 유지합니다. dns-hijack은 임의 주소의 53번 포트로 향하는 평문 DNS 조회를 강제로 커널 해석으로 가로채는 것으로, TUN 모드에서 DNS 유출을 막는 핵심 항목입니다. 데스크톱에서 TUN을 활성화하려면 관리자 권한이나 설치된 시스템 서비스가 필요하며, Clash Plus와 Clash Verge Rev는 처음 켤 때 권한 부여를 안내합니다.

Fake-IP: 해석 결과가 왜 198.18로 시작하는가

enhanced-mode: fake-ip는 TUN과 가장 잘 어울리는 해석 모드입니다. 동작 방식은 다음과 같습니다. 애플리케이션이 도메인 조회를 시작하면 커널은 실제 해석을 하지 않고 즉시 예약된 네트워크 대역 198.18.0.0/16에서 "가짜 IP"를 할당해 반환하고, 이 IP와 도메인의 매핑을 기억합니다. 애플리케이션이 가짜 IP로 연결을 시작하면 커널은 매핑을 역조회해 도메인을 복원한 뒤 도메인 규칙에 따라 분기합니다. 장점은 두 가지입니다. 실제 해석 대기 시간을 절약해 연결이 더 빨라지고, 도메인 정보가 규칙 매칭 단계까지 보존되어 해석 여부에 영향받지 않고 분기 정밀도가 유지됩니다. 대가는 실제 IP에 의존하는 일부 프로그램이 이상 동작을 보일 수 있다는 점입니다. LAN 검색, NTP 시간 동기화, 일부 게임 로그인 서버 등이 그렇습니다. 이런 도메인은 fake-ip-filter 화이트리스트에 넣어 실제 해석을 거치게 해야 합니다.

dns:
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "ntp.*.com"
    - "+.stun.*.*"

사용 환경이 주로 브라우저 기반이고 해석 결과를 서드파티 프로그램에 넘겨야 하는 일이 자주 있다면 enhanced-mode: redir-host(실제 IP 모드)로 되돌릴 수도 있으며, 대가는 매 연결마다 실제 해석 완료를 기다려야 한다는 점입니다. 두 모드는 언제든 전환할 수 있으며, 전환 후에는 DNS 캐시를 한 번 비우고 관찰하는 것을 권장합니다.

도메인 스니핑: IP를 도메인으로 복원하기

규칙 분기의 이상적인 입력은 도메인이지만, 두 유형의 트래픽은 커널에 도달했을 때 IP만 남습니다. 하나는 애플리케이션 자체 DNS(예: 브라우저 내장 DoH)가 커널 해석을 우회해 연결 목적지가 곧바로 실제 IP인 경우이고, 다른 하나는 Fake-IP 화이트리스트 밖에서도 프로그램이 과거 해석 결과를 캐시해 둔 경우입니다. 목적지가 IP만 남으면 모든 도메인 규칙이 전부 무효가 되어 트래픽은 GEOIP나 MATCH 기본 규칙으로만 떨어지고 분기 정밀도가 크게 떨어집니다. 도메인 스니핑(sniffer)은 이를 보완하는 수단입니다. 커널이 연결 헤더의 평문 특징(HTTP 요청의 Host 헤더, TLS 핸드셰이크의 SNI 필드, QUIC 초기 패킷)을 검사해 실제 도메인을 "스니핑"해내고, 이를 다시 규칙 매칭에 사용합니다.

설정 예시

sniffer:
  enable: true
  sniff:
    HTTP:
      ports: [80, 8080-8880]
      override-destination: true
    TLS:
      ports: [443, 8443]
    QUIC:
      ports: [443, 8443]
  force-domain:
    - "+.v2ex.com"
  skip-domain:
    - "+.push.apple.com"
    - "Mijia Cloud"

세 프로토콜 블록은 각각 어떤 포트에서 스니핑을 시도할지 선언합니다. override-destination이 true이면 스니핑한 도메인으로 연결의 목적지 주소를 덮어써, 이후 규칙과 로그가 모두 도메인으로 표시됩니다. force-domain에 나열된 도메인은 이미 해석 결과가 있어도 강제로 스니핑 값으로 덮어써, CDN 도메인과 해석 결과가 맞지 않는 사이트를 처리하는 데 적합합니다. skip-domain은 반대로 나열된 목적지의 스니핑을 건너뜁니다. 애플 푸시, 일부 제조사의 장기 연결은 연결 헤더 검사에 민감하므로 건너뛰기 목록에 넣으면 이유 없는 연결 끊김을 피할 수 있습니다. 스니핑은 프로토콜 핸드셰이크 단계에서 원래 평문인 필드만 읽으며 어떤 암호화된 페이로드도 복호화하지 않습니다. 오버헤드는 각 새 연결의 첫 데이터 패킷에 집중되어 일상 사용에서는 거의 체감되지 않습니다. TUN + Fake-IP + 스니핑 세 가지를 동시에 활성화하는 것이 현재 분기 정밀도가 가장 높은 조합입니다.

로컬 오버라이드와 다중 구독 병합

구독 파일은 서버 측에서 생성되며 갱신될 때마다 로컬 내용을 통째로 덮어씁니다. 구독 파일을 직접 수정해 DNS를 바꾸거나 규칙을 추가하면 다음 갱신 때 전부 사라집니다. 올바른 방법은 개인 커스터마이징을 "오버라이드" 계층에 넣는 것입니다. 클라이언트는 매번 구독을 로드한 뒤 사용자의 오버라이드 내용을 자동으로 최종 설정에 병합하여, 구독은 구독대로 커스터마이징은 커스터마이징대로 서로 간섭하지 않습니다. 이는 Clash를 오래 사용할 때 반드시 만들어야 할 습관입니다.

클라이언트별 오버라이드 기능

다운로드 페이지에서 첫손에 꼽는 Clash Plus는 오버라이드 편집기를 내장해 YAML 조각 형태로 필드를 추가하거나 교체할 수 있어 이 페이지의 모든 예시를 실제로 적용하는 데 적합합니다. Clash Verge Rev는 Merge(선언형 병합)와 Script(자바스크립트 프로그래밍형 수정) 두 가지 전역 확장을 제공합니다. Merge에서 dns, tun 등의 키는 구독의 동일한 필드를 통째로 교체하고, 접두사 표기법으로 목록 추가도 가능하며, 복잡한 로직은 Script를 사용합니다. FlClash도 설정 오버라이드를 지원해 모바일에서도 사용자 정의 규칙을 지킬 수 있습니다. 갱신이 중단된 클라이언트에서 오버라이드 설정을 마이그레이션하는 전체 경로는 블로그 《Clash for Windows 업데이트 중단 후 대안》을 참고하세요. 일반적인 Merge 오버라이드는 다음과 같습니다.

dns:
  enable: true
  enhanced-mode: fake-ip
prepend-rules:
  - DOMAIN-SUFFIX,corp.example.com,DIRECT
append-rules:
  - GEOIP,CN,DIRECT

proxy-providers로 여러 구독 병합

여러 프록시 서비스 구독을 갖고 있어도 클라이언트에서 설정을 번갈아 전환할 필요는 없습니다. proxy-providers는 각 구독을 노드 제공자로 선언한 뒤 정책 그룹에서 use로 참조할 수 있게 해, 여러 구독의 노드를 하나의 그룹 체계로 통합해 속도 측정과 분기를 일괄 관리할 수 있습니다.

proxy-providers:
  provider-a:
    type: http
    url: "https://example.com/sub-a?token=xxxx"
    path: ./providers/a.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300
  provider-b:
    type: http
    url: "https://example.net/sub-b?token=xxxx"
    path: ./providers/b.yaml
    interval: 3600

proxy-groups:
  - name: 전체 노드
    type: url-test
    use:
      - provider-a
      - provider-b
    url: https://www.gstatic.com/generate_204
    interval: 300

provider 단위의 health-check는 어떤 그룹에서도 사용되기 전에 노드가 이미 헬스 상태를 가지도록 합니다. filter, exclude-filter 필드는 provider 계층에서 만료 안내, 트래픽 공지 같은 비(非)노드 항목을 미리 걸러낼 수 있습니다. 주의할 점은 두 구독에 동일한 이름의 노드가 있으면 로딩 충돌이 발생할 수 있다는 것으로, override.additional-prefix를 사용해 각 provider의 노드에 통일된 접두사를 붙여 출처를 구분할 수 있습니다. 여러 기기에서 이 병합 설정을 공유하는 LAN 활용법은 블로그 《Clash 혼합 포트와 LAN 연결 허용 설정》도 참고하세요.

외부 제어판 연동

커널은 실행 중에 RESTful API를 노출하며, 정책 그룹 전환, 지연 시간 테스트, 연결 조회, 설정 리로드까지 모두 이를 통해 처리할 수 있습니다. 데스크톱 클라이언트의 그래픽 인터페이스는 본질적으로 이 API를 감싼 것입니다. Clash가 라우터, NAS, 헤드리스 서버에서 실행될 때(배포 방식은 블로그 《라우터에서 Clash 커널 직접 실행하는 방안 개요》 참고) 외부 제어판이 유일하게 편리한 관리 창구가 됩니다.

API와 패널 활성화

external-controller: 127.0.0.1:9090
secret: "your-strong-secret"
external-ui: ./ui
external-ui-url: "https://example.com/dashboard/dist.zip"

external-controller는 API 리스닝 주소를 지정합니다. 로컬 관리만 필요하면 127.0.0.1을 유지하고, LAN 내 다른 기기의 접근이 필요하면 0.0.0.0으로 바꿉니다. secret은 API 접근 토큰으로 패널이 연결할 때 Authorization: Bearer 헤더에 담아 전달합니다. external-ui는 로컬 정적 패널 디렉터리를 지정하며 external-ui-url과 함께 사용하면 커널이 패널 배포 패키지를 자동으로 다운로드하게 할 수 있고, 이후 브라우저로 http://127.0.0.1:9090/ui에 접속하면 열립니다. 커뮤니티에서 흔히 쓰는 패널로는 metacubexd, zashboard, yacd 계열이 있으며 모두 순수 정적 페이지이므로 마음에 드는 것을 고르면 됩니다. 데스크톱 사용자는 보통 별도로 배포할 필요가 없으며, Clash Plus와 Clash Verge Rev는 이미 패널 뷰를 내장하고 있습니다.

API 직접 호출

# 커널 버전 확인
curl -H "Authorization: Bearer your-strong-secret" \
  http://127.0.0.1:9090/version

# "노드 선택" 그룹을 "홍콩 노드"로 전환
curl -X PUT -H "Authorization: Bearer your-strong-secret" \
  -d '{"name":"홍콩 노드"}' \
  http://127.0.0.1:9090/proxies/노드 선택

# 지정 그룹의 지연 시간 테스트 트리거
curl -H "Authorization: Bearer your-strong-secret" \
  "http://127.0.0.1:9090/group/자동 속도 측정/delay?url=https://www.gstatic.com/generate_204&timeout=3000"
보안 경계

API는 커널에 대한 완전한 제어 권한을 갖습니다. external-controller를 0.0.0.0으로 노출하면서 secret을 설정하지 않으면 LAN 내 어떤 기기에도 프록시 스케줄링 권한을 넘겨주는 것과 같습니다. 해당 기기 자체가 공용 IP를 가지고 있다면 위험은 더 커집니다. 원칙은: 127.0.0.1로 가능하면 전체 네트워크에 노출하지 말고, 전체 네트워크에 노출한다면 반드시 강력한 비밀번호를 설정하고 방화벽이 9090 포트를 공용 네트워크에 개방하지 않았는지 확인하는 것입니다.

여기까지 7대 주제의 고급 설정을 모두 다뤘습니다. 권장하는 실전 경로는: 먼저 튜토리얼 페이지에서 기본 연결이 되는지 확인한 뒤, DNS와 정책 그룹 두 챕터부터 시작해 예시를 하나씩 적용하고, 하나를 바꿀 때마다 패널의 연결 뷰로 효과를 검증하는 것입니다. 필드 의미는 언제든 개념 사전에서 찾아보고, 클라이언트 선택과 다운로드는 다운로드 페이지를, 사이트의 방향성과 유지보수 원칙은 프로젝트 소개를 참고하세요.