Clash 고급 설정 매뉴얼

정책 그룹 유형과 실전 구성

정책 그룹은 설정 파일에서 규칙과 실제 연결을 잇는 계층입니다. 규칙은 "어떤 종류의 트래픽을 어떤 그룹에 넘길지"를 결정하고, 정책 그룹은 "그 그룹이 지금 어떤 노드를 쓸지"를 결정합니다. 트래픽 분배가 매끄러운지는 대부분 정책 그룹 구조를 얼마나 합리적으로 설계했는지에 달려 있습니다. mihomo 커널은 5가지 기본 유형을 지원하며, 동작 방식은 다음과 같습니다.

5가지 유형의 동작 차이

select는 가장 많이 쓰이면서도 그 가치가 저평가되기 쉬운 유형입니다. 자동 판단을 전혀 하지 않지만, 그렇기 때문에 동작이 완전히 예측 가능해 "사람이 직접 결정하는" 메인 진입점으로 적합합니다. url-test와 fallback의 차이는 자주 혼동됩니다 — 전자는 항상 "현재 가장 빠른" 노드를 추구하기 때문에 노드가 불안정할 때 자주 왔다 갔다 할 수 있고, 후자는 "순서상 가장 앞선 사용 가능한" 노드를 추구해 현재 노드가 실패했을 때만 전환되므로 안정성이 우선입니다. 원격 데스크톱, 음성 통화 같은 상호작용형 앱에는 전환이 곧 연결 재구성을 의미하기 때문에 대체로 fallback이 url-test보다 체감상 나은 경험을 줍니다.

url-test의 핵심 파라미터 3가지

자동 속도 측정 그룹의 동작은 세 파라미터로 제어됩니다. interval은 측정 주기(초)로 보통 300을 사용합니다. 너무 짧게 설정하면 대량의 탐지 요청이 발생하며 모바일에서는 배터리 소모도 커집니다. tolerance는 허용 오차(밀리초)로, 새로운 최속 노드가 현재 노드보다 이 값만큼 더 빠를 때만 전환이 발생합니다. 50 정도부터 시작하면 불필요한 전환을 크게 줄일 수 있습니다. lazy를 true로 설정하면 트래픽이 지나가지 않을 때 측정을 건너뛰어, 노드 수가 많은 설정에서 상당한 탐지 부하를 줄일 수 있습니다.

실전 그룹 구조

추천 구조는 3계층입니다. 최상위는 select 방식의 메인 진입 그룹, 중간층은 지역이나 용도별 그룹, 최하위층은 실제 노드입니다. 규칙은 항상 최상위나 중간층 그룹을 가리키며 노드를 직접 가리키지 않습니다 — 이렇게 하면 서버(기관)를 바꾸거나 노드 이름을 바꿔도 규칙을 수정할 필요가 없습니다. 예시:

proxy-groups:
  - name: 节点选择
    type: select
    proxies: [自动测速, 故障转移, 香港节点, 日本节点, DIRECT]

  - name: 自动测速
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true
    proxies: [HK-01, HK-02, JP-01]

  - name: 故障转移
    type: fallback
    url: https://www.gstatic.com/generate_204
    interval: 300
    proxies: [HK-01, JP-01, SG-01]

  - name: 香港节点
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    proxies: [HK-01, HK-02]

규칙 세트 구독 방식 관리

수백, 수천 개의 규칙을 메인 설정에 직접 적어 넣는 것은 유지보수 재앙의 시작입니다. 구독이 업데이트될 때마다 전부 다시 써야 하고, 규칙 하나를 고치려면 긴 파일을 뒤져야 합니다. 규칙 세트(rule-providers)는 규칙을 별도의 원격 파일로 분리합니다. 메인 설정에는 참조만 남기고, 규칙 내용은 주기적으로 자동 업데이트되며, 메인 설정은 십여 줄로 깔끔하게 유지됩니다.

behavior 3가지 유형

각 규칙 세트는 behavior를 선언해야 하며, 이는 파일 내용을 어떻게 해석할지를 결정합니다. 세 유형은 혼용할 수 없습니다. domain 유형 파일은 도메인만 포함할 수 있고(+. 와일드카드 접두사 지원) 매칭 효율이 가장 높습니다. ipcidr는 IP 대역(CIDR 표기법)만 포함할 수 있습니다. classical은 완전한 규칙 문법(DOMAIN-SUFFIX, IP-CIDR, DST-PORT 등을 혼합)을 허용해 유연하지만 매칭 오버헤드가 약간 더 큽니다. 원칙은 domain이나 ipcidr로 처리할 수 있으면 classical을 쓰지 않고, classical은 정말로 조건 혼합이 필요한 경우에만 남겨두는 것입니다.

format과 업데이트 주기

format은 yaml, text, mihomo 전용 바이너리 포맷인 mrs를 지원합니다. mrs는 사전 컴파일된 산출물로 크기가 작고 로딩이 빠릅니다. 대용량 도메인/IP 집합(예: 특정 지역 전체 IP 데이터베이스)에는 mrs를 우선 고려하고, 직접 작성하고 관리하는 소규모 규칙 세트에는 yaml이나 text로 충분합니다. interval은 자동 업데이트 주기(초)를 제어합니다. 규칙 세트 내용은 변경 빈도가 낮으므로 86400(하루)이면 합리적이며 더 짧게 설정할 필요는 없습니다.

rule-providers:
  streaming:
    type: http
    behavior: classical
    format: yaml
    url: https://example.com/rules/streaming.yaml
    path: ./rule-sets/streaming.yaml
    interval: 86400
  cn-ip:
    type: http
    behavior: ipcidr
    format: mrs
    url: https://example.com/rules/cn-ip.mrs
    path: ./rule-sets/cn-ip.mrs
    interval: 86400

rules:
  - RULE-SET,streaming,节点选择
  - RULE-SET,cn-ip,DIRECT
  - MATCH,节点选择

참조 문법은 RULE-SET,규칙세트이름,정책입니다. 규칙은 여전히 위에서 아래로 순서대로 매칭되고 일치하면 즉시 멈춘다는 점에 주의하세요. RULE-SET의 배치 순서도 일반 규칙과 마찬가지로 중요합니다. 적중률이 높은 세트를 앞에 두고, IP 유형 규칙은 도메인 유형 규칙 뒤에 배치하세요(IP 규칙은 DNS 조회를 트리거하므로 미리 트리거되면 낭비입니다). MATCH 기본 규칙은 항상 마지막 줄에 둡니다.

DNS 설정 최적화

DNS는 트래픽 분배 품질의 기반입니다. 도메인 해석이 오염되면 IP 규칙은 잘못된 IP를 근거로 판단하게 되고, 해석 서버 선택이 부적절하면 직접 연결 트래픽이 멀리 우회하거나 CDN이 저속 노드로 배정됩니다. 커널에는 완전한 DNS 모듈이 내장되어 있으며, 각 필드의 역할을 이해하면 "규칙은 분명 맞게 썼는데 적용이 안 된다"는 문제 대부분이 저절로 해결됩니다.

nameserver와 default-nameserver의 역할 구분

nameserver는 메인 해석 서버 목록으로, 모든 서비스 도메인의 해석을 담당하며, 평문 53번 포트의 간섭을 피하기 위해 DoH(DNS over HTTPS) 주소 사용을 권장합니다. 여기서 닭과 달걀 문제가 생깁니다 — DoH 주소 자체도 도메인이기 때문에 해석이 필요합니다. 이것이 default-nameserver가 존재하는 이유로, nameserver 목록에 등장하는 도메인만 해석하며 순수 IP 형태의 전통적인 DNS를 지정해야 합니다. 둘은 역할이 다르므로 서로 대체할 수 없습니다.

nameserver-policy를 통한 도메인별 분배

nameserver-policy는 도메인 패턴별로 전용 해석 서버를 지정할 수 있게 합니다. 국내(해당 지역) 도메인은 국내 DNS로 보내 가까운 CDN을 얻고, 나머지 도메인은 믿을 수 있는 암호화 DNS로 보내 오염을 방지합니다. geosite 카테고리 참조를 지원해 한 줄로 대규모 도메인군을 커버할 수 있어 현재 권장되는 분배 해석 방식이며, 기존의 fallback + fallback-filter 조합보다 더 직관적이고 동작이 예측 가능합니다.

dns:
  enable: true
  listen: 0.0.0.0:1053
  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
  nameserver-policy:
    "geosite:cn":
      - https://doh.pub/dns-query
    "geosite:geolocation-!cn":
      - https://dns.cloudflare.com/dns-query

enhanced-mode는 강화된 해석 모드를 결정하며 값은 fake-ip 또는 redir-host이고, TUN과의 연동 세부 사항은 다음 챕터에서 다룹니다. listen은 커널 DNS의 수신 대기 주소로, TUN 모드에서는 dns-hijack과 함께 시스템 DNS 조회를 여기로 가로채 모든 해석이 커널을 거치도록 합니다.

TUN과 Fake-IP

시스템 프록시 모드의 근본적인 단점은 "프록시 설정을 지키는 프로그램만 관리한다"는 점입니다. 커맨드라인 도구, 게임, 일부 클라이언트 프로그램은 시스템 프록시를 전혀 읽지 않습니다. TUN 모드는 시스템에 가상 네트워크 카드를 만들어 모든 트래픽을 네트워크 계층에서 커널로 끌어들여, 접수 범위가 불완전한 문제를 근본적으로 해결합니다. UWP 앱의 루프백 제한, 터미널의 git이나 패키지 관리자도 TUN 모드에서는 별도 처리가 필요 없어집니다.

TUN 활성화와 stack 선택

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

auto-route는 시스템 라우팅을 자동으로 인수하고, auto-detect-interface는 물리적 출구 네트워크 카드를 자동으로 감지합니다. 둘 다 보통 켜둔 상태를 유지합니다. dns-hijack은 임의의 53번 포트로 향하는 조회를 커널 DNS로 가로채는 것으로, TUN과 Fake-IP 연동의 핵심 부분입니다. stack은 가상 네트워크 카드의 프로토콜 스택 구현을 결정합니다 — system은 운영체제 네트워크 스택을 직접 사용해 처리량이 좋고, gvisor는 사용자 공간 구현으로 호환성이 좋으며, mixed는 둘의 절충으로 TCP는 system, UDP는 gvisor를 사용합니다. 데스크톱에서는 mixed부터 시도해볼 수 있습니다. 플랫폼별 활성화 조건은 다음과 같습니다.

Fake-IP 원리와 fake-ip-filter

Fake-IP는 TUN과 함께 동작하는 해석 전략입니다. 프로그램이 도메인 조회를 시작하면, 커널은 실제 해석 완료를 기다리지 않고 예약된 대역(기본값 198.18.0.1/16)에서 즉시 "가짜 IP"를 반환하며 매핑 관계를 기억합니다. 연결이 도착하면 가짜 IP로 도메인을 역조회해 바로 도메인 규칙으로 매칭합니다 — 직렬 DNS 대기 시간을 없애 연결 수립이 빨라지고 규칙 적중도 더 정확해집니다. 대가는 일부 프로그램이 가짜 IP를 받으면 문제가 생긴다는 점입니다. LAN 검색, 시간 동기화, 네트워크 연결 상태 확인처럼 "IP를 실제 값으로 취급하는" 상황은 예외 처리가 필요하며, 이것이 fake-ip-filter의 용도입니다.

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

필터 목록에 걸린 도메인은 실제 해석을 거쳐 진짜 IP를 반환합니다. 목록은 남발하지 말고 필요한 것만 정확히 넣어야 합니다 — 많이 추가할수록 Fake-IP의 이점이 그만큼 희석됩니다. 또한 Fake-IP와 redir-host를 전환한 후에는 시스템과 브라우저에 이전 해석 캐시가 남아 있을 수 있어 일정 시간 동안 일부 사이트가 이상하게 동작하는데, 클라이언트를 재시작하거나 시스템 DNS 캐시를 새로 고치면 정상화됩니다.

도메인 스니핑

규칙에서 가장 편하게 작성할 수 있는 것은 도메인 규칙이지만, 커널에 도착했을 때 IP만 있고 도메인이 없는 트래픽이 두 종류 있습니다. 첫째는 프로그램이 스스로 DNS 해석을 마친 뒤 IP로 직접 연결하는 경우(커널의 해석 단계를 건너뜀)이고, 둘째는 Fake-IP 매핑 범위 밖의 경우입니다. 도메인이 없으면 DOMAIN-SUFFIX 같은 규칙은 전부 무용지물이 되고, 트래픽은 IP 규칙이나 기본 규칙에만 걸리게 됩니다. 도메인 스니핑(sniffer)의 역할은 트래픽 자체에서 도메인을 "읽어" 되살리는 것입니다. TLS 핸드셰이크의 SNI 필드, HTTP 요청의 Host 헤더, QUIC 핸드셰이크 패킷에는 모두 목표 도메인이 담겨 있으며, 커널은 연결 초기에 이러한 프로토콜 특징을 해석해 복원한 도메인을 다시 규칙 엔진에 넘겨 매칭합니다.

설정 구조

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

sniff 아래에 프로토콜별로 스니핑할 포트 범위를 선언하며, 선언된 포트만 스니핑하므로 범위를 좁게 잡을수록 오버헤드가 줄어듭니다. override-destination은 도메인을 스니핑한 후 이를 연결의 목표 주소로 덮어쓸지를 결정합니다 — 켜면 연결이 도메인 형태로 계속 처리되고 규칙 매칭과 DNS 분배도 도메인 기준으로 이루어집니다. force-domain은 일치하는 도메인에 스니핑 오버라이드를 강제 적용하며, Fake-IP를 받고도 스스로 IP로 연결하는 일부 앱에 주로 사용합니다. skip-domain은 화이트리스트로, 일치하는 도메인은 오버라이드를 건너뜁니다. 연결 목표에 민감한 장기 연결인 푸시 서비스류는 이 목록에 넣어 스니핑 간섭을 피하는 것을 권장합니다.

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

구독으로 받은 설정 파일을 직접 수정하는 것은 초보자가 가장 흔히 빠지는 유지보수 함정입니다. 구독이 업데이트되면 서버(기관) 측 템플릿이 로컬 파일을 전체 덮어써서 수동으로 수정한 내용이 한순간에 사라집니다. 블로그 《Clash 구독 업데이트 실패 원인 진단》의 상당수 사례가 바로 이 문제에서 비롯됩니다. 올바른 방법은 "서버(기관)가 제공한 것"과 "직접 작성한 것"을 분리하는 것입니다 — 구독은 노드 소스로만 쓰고, 개인화 내용은 오버라이드 레이어나 별도의 provider에 넣습니다.

클라이언트 오버라이드: Merge와 Script

Clash Verge Rev는 2단계 오버라이드를 제공하며, 둘 다 구독 업데이트 후·커널 로딩 전에 작동하므로 구독에 덮어씌워지는 일이 없습니다. Merge 오버라이드는 선언적입니다 — YAML 조각을 작성해 필드 단위로 최종 설정에 병합하며, DNS 설정 추가, rule-providers, 최상단에 몇 개의 커스텀 규칙을 고정하는 등의 구조적 수정에 적합합니다. Script 오버라이드는 JavaScript 함수 하나로, 완전한 설정 객체를 받아 수정된 객체를 반환합니다 — 로직이 필요한 경우에 적합합니다. 예를 들어 이름 정규식으로 노드를 필터링하거나, 정책 그룹에 노드를 일괄로 채우거나, 노드 수에 따라 그룹을 동적으로 생성하는 경우입니다. 두 방식은 함께 사용할 수 있으며, 먼저 Merge를 우선 시도하고 정말 프로그래밍이 필요할 때만 Script를 사용하는 것을 권장합니다. Clash Plus도 마찬가지로 구독과 로컬 설정을 분리해서 관리하는 방식을 제공하며, 각 클라이언트의 세부 차이는 클라이언트 비교를 참고하세요.

proxy-providers를 통한 다중 구독 병합

여러 구독을 보유하고 있다면 설정을 왔다 갔다 전환할 필요가 없습니다. proxy-providers는 각 구독을 하나의 노드 소스로 선언해 각자 독립적으로 업데이트하고, 정책 그룹의 use 필드를 통해 여러 소스의 노드를 하나의 그룹으로 합칠 수 있습니다.

proxy-providers:
  airport-a:
    type: http
    url: https://a.example.com/sub?token=xxxx
    path: ./providers/airport-a.yaml
    interval: 43200
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600
  airport-b:
    type: http
    url: https://b.example.com/sub?token=xxxx
    path: ./providers/airport-b.yaml
    interval: 43200

proxy-groups:
  - name: 节点选择
    type: select
    use: [airport-a, airport-b]
  - name: 自动测速
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    use: [airport-a, airport-b]

use와 proxies는 같은 그룹 안에 함께 존재할 수 있습니다. 전자는 provider의 모든 노드를 가져오고, 후자는 수동으로 작성한 노드나 다른 그룹을 추가합니다. health-check를 사용하면 provider 자체적으로 상태 확인을 하며, url-test 그룹에서 참조할 때 그 결과를 바로 재사용할 수 있습니다. interval은 구독 가져오기 주기(초)로, 43200(반나절)이면 대부분의 서비스에 충분합니다. 특정 provider의 가져오기가 실패해도 다른 소스에 영향을 주지 않는데, 이는 다중 구독 구조가 본래 지닌 장애 대응력입니다.

외부 컨트롤 패널

커널은 실행 중 RESTful 컨트롤 인터페이스 세트를 노출합니다. 노드 전환, 지연 시간 테스트, 연결 조회, 설정 다시 로드가 모두 이를 통해 이루어지며 — 데스크톱 클라이언트의 화면은 본질적으로 이 인터페이스를 감싸놓은 것입니다. 외부 컨트롤을 직접 사용하는 것은 두 상황에서 가치가 있습니다. 하나는 라우터, 서버에서 GUI 없이 커널만 단독으로 실행하는 경우이고, 다른 하나는 브라우저 패널이나 스크립트로 자동화 관리를 하고 싶은 경우입니다.

인터페이스 활성화와 인증

external-controller: 127.0.0.1:9097
secret: "your-strong-secret"
external-ui: ./ui

external-controller는 수신 대기 주소와 포트를 선언합니다. 로컬에서만 사용한다면 127.0.0.1에 바인딩하고, LAN 내 다른 기기(예: 휴대폰으로 라우터의 커널 관리)에서 접근해야 할 때만 0.0.0.0에 바인딩합니다. 이때 secret은 충분히 강력한 랜덤 문자열로 반드시 설정해야 합니다 — 모든 요청은 Authorization 헤더에 이를 담아 보내야 합니다. external-ui는 정적 웹 패널 디렉터리를 가리키며, 커널이 직접 서빙해 브라우저로 컨트롤 주소에 접속하면 바로 열립니다. 주요 오픈소스 웹 패널(metacubexd, yacd 계열)을 이 디렉터리에 압축 해제하면 바로 사용할 수 있습니다.

API로 자동화하기

인터페이스는 표준 HTTP + JSON이므로 curl로도 제어할 수 있습니다. 모든 정책 그룹과 노드 상태 조회:

특정 select 그룹의 선택 노드를 전환하려면 그룹명에 PUT 요청을 보냅니다:

자주 쓰는 엔드포인트로는 /connections(실시간 연결 목록, "이 트래픽이 실제로 어떤 정책을 탔는지" 확인하는 첫 단서), /logs(로그 스트림), /configs(런타임 중 포트와 모드 변경) 등이 있습니다. 이러한 엔드포인트를 스크립트에 연결하면 정기 속도 측정, 이상 자동 전환 같은 무인 운영 로직도 구현할 수 있습니다.

참고 경로와 더 읽어보기

7개 챕터 사이에는 명확한 의존 관계가 있습니다. 정책 그룹과 규칙 세트는 골격이고, DNS는 기반이며, TUN, Fake-IP, 스니핑은 "얼마나 빠짐없이 잡아내고 얼마나 정확히 매칭하는지"를 해결합니다. 오버라이드와 병합은 장기 유지보수를 해결하고, 외부 컨트롤은 런타임 관측과 자동화를 담당합니다. 실제 겪고 있는 문제에 맞춰 필요한 챕터부터 읽는 것을 권장하며 처음부터 끝까지 다 읽을 필요는 없습니다. 설정에서 낯선 용어를 만나면 용어집이 "커널과 클라이언트 / 프록시 프로토콜 / 규칙과 정책 그룹 / DNS와 트래픽 처리 / 설정 파일 필드"의 5개 분류로 정의를 정리해 두었습니다. 설정을 수정한 뒤 오류나 이상 동작이 나타나면 먼저 자주 묻는 질문의 문제 해결 카테고리를 확인하세요. 어떤 클라이언트로 이 설정들을 운용할지 아직 정하지 못했다면 클라이언트 비교에서 플랫폼과 사용 습관에 따른 선택 결론을 제공합니다. 최초 설치 시 전체 체크리스트는 블로그 《Clash 클라이언트 최초 설치 설정 체크리스트》를 참고하세요. 이 페이지는 커널 설정 필드의 변화에 맞춰 계속 업데이트되므로 즐겨찾기에 저장해 두는 것을 권장합니다.