Clash 고급 설정 매뉴얼

정책 그룹 유형과 실전 활용

정책 그룹(proxy-groups)은 분기 규칙과 실제 노드 사이의 중간 계층입니다. 규칙이 매칭되면 정책 그룹에 넘겨지고, 정책 그룹은 자체 로직에 따라 실제로 어떤 노드를 사용할지 결정합니다. 각 유형의 판정 방식을 이해하는 것이 설정을 "일단 작동함"에서 "쓰기 편함"으로 바꾸는 첫걸음입니다. mihomo가 지원하는 주요 유형은 다섯 가지이며 판정 로직이 크게 다르기 때문에, 유형을 잘못 고르면 지연 흔들림과 빈번한 끊김의 흔한 원인이 됩니다.

다섯 가지 유형의 판정 로직

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

url은 속도 측정 대상으로, 보통 204 빈 응답을 반환하는 주소를 사용하며 트래픽 소모는 무시할 수 있는 수준입니다. interval은 측정 주기(초)로, 너무 짧으면 구독 노드의 측정 트래픽이 늘어나고 너무 길면 노드 상태가 나빠져도 늦게 전환되므로 일반적으로 300 정도가 균형점입니다. tolerance는 전환 허용 차이(밀리초)로, 새 노드가 현재 노드보다 이 값 이상 빨라야만 전환됩니다. tolerance를 설정하지 않으면 지연이 60ms와 65ms인 두 노드가 계속 왔다 갔다 하며, 전환마다 진행 중인 연결이 끊길 수 있으므로 최소 50 이상 설정하는 것을 권장합니다.

proxy-groups:
  - name: 자동 속도측정
    type: url-test
    proxies: [HK-01, HK-02, JP-01]
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: 장애 전환
    type: fallback
    proxies: [메인-HK, 백업-JP, 최종-US]
    url: https://www.gstatic.com/generate_204
    interval: 180

  - name: 균등 분산
    type: load-balance
    strategy: consistent-hashing
    proxies: [SG-01, SG-02, SG-03]

load-balance의 두 가지 strategy

consistent-hashing은 목적지 주소를 해시하여 동일 사이트의 요청이 항상 같은 노드로 향하게 하며, 분산과 세션 안정성을 함께 챙길 수 있어 기본 추천 방식입니다. round-robin은 연결마다 노드를 순환시켜 가장 철저하게 분산되지만, 같은 사이트의 서로 다른 요청이 다른 IP에서 발생하므로 세션 검증이 엄격한 서비스에서는 로그아웃되기 쉬워 순수 다운로드 그룹에만 사용하는 것을 권장합니다.

그룹 조합의 실전 패턴

실전에서는 보통 2단계 구조를 사용합니다. 하위 계층에는 "HK 자동", "JP 자동"처럼 지역별 url-test 그룹을 만들고, 상위 계층에는 이런 지역 그룹과 "수동 선택"을 함께 모은 select 그룹을 만들어, 규칙은 이 상위 select 그룹을 가리키게 합니다. 이렇게 하면 평소에는 자동 속도측정에 맡기고, 특정 지역을 고정하고 싶을 때는 클라이언트 패널에서 해당 지역 그룹으로 한 번에 전환할 수 있어 규칙을 수정할 필요가 없습니다. 정책 그룹은 다른 정책 그룹을 중첩해서 참조할 수도 있지만(proxies 목록에 그룹 이름을 적으면 됨), 순환 참조를 만들면 안 됩니다. 커널이 이런 설정의 로드를 거부합니다. 세 가지 자동 유형의 더 세밀한 비교와 파라미터 실험은 블로그의 정책 그룹 유형 비교 글을 참고하고, 어떤 노드를 그룹에 넣어야 할지 모르겠다면 노드 선택의 네 가지 기준을 먼저 읽어보세요.

규칙셋 구독화 관리

수천 줄의 분기 규칙을 rules 항목에 그대로 쌓아두는 것은 설정을 관리하기 어렵게 만드는 주된 원인입니다. 구독이 갱신될 때마다 직접 추가한 규칙이 덮어씌워지고, 특정 종류의 사이트 방향을 조정하려면 긴 목록에서 하나씩 찾아야 합니다. rule-providers는 규칙을 용도별로 독립된 파일로 나눠 구독 형태로 불러오는 방식으로, rules 항목에는 십여 줄의 "골격"만 남아 가독성과 유지보수성이 눈에 띄게 개선됩니다.

rule-providers 필드의 의미

type은 http(원격 구독, interval에 따라 자동 갱신) 또는 file(로컬 파일, 직접 관리)을 사용합니다. behavior는 이 규칙 파일의 내용 형태를 선언하는데, domain은 순수 도메인 목록, ipcidr은 순수 IP 대역 목록이며, classical은 여러 규칙 유형을 혼용할 수 있어 범용성이 가장 높지만 매칭 비용이 조금 더 듭니다. format은 yaml, text와 mihomo의 바이너리 형식 mrs를 지원하며, mrs는 용량이 작고 로딩이 빨라 대규모 규칙셋에는 우선 선택하는 것이 좋습니다. path는 로컬 캐시 경로이고, 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
  - GEOIP,CN,DIRECT
  - MATCH,자동 속도측정

규칙 순서와 기본 처리

rules 항목은 위에서 아래로 매칭되며 한 번 매칭되면 멈추므로 순서가 곧 우선순위입니다. 개인 예외 규칙은 맨 앞에, 대형 규칙셋은 중간에, GEOIP,CN,DIRECT 같은 지리 규칙은 뒤쪽에 두고, 마지막 줄은 반드시 MATCH 기본 처리여야 합니다. 기본 처리가 없으면 매칭되지 않은 트래픽의 방향이 커널 기본 동작에 따라 결정돼 문제를 진단할 때 매우 혼란스러워집니다. 또 다른 흔한 실수는 IP 계열 규칙(GEOIP/IP-CIDR)을 도메인 규칙보다 앞에 두는 것입니다. IP 규칙은 목적지 IP를 얻기 위해 DNS 해석을 한 번 유발해 매칭을 지연시킬 뿐 아니라 원치 않는 해석 동작을 일으킬 수 있으므로, 해석을 유발하고 싶지 않다면 규칙에 no-resolve 파라미터를 추가하세요.

GeoIP와 GeoSite 데이터베이스

GEOIP,CN은 커널이 로드한 GeoIP 데이터베이스에 의존하고, GEOSITE 규칙은 GeoSite 데이터베이스에 의존하며, 둘 다 시간이 지나면 낡습니다. 데이터베이스가 너무 오래되면 실제로 중국 본토에 있는 일부 IP가 해외로 잘못 판정돼 불필요하게 프록시를 경유하게 됩니다. 대부분의 유지보수 중인 클라이언트는 설정에서 "Geo 데이터베이스 업데이트" 항목을 제공하니 한두 달에 한 번씩 직접 클릭해주는 것을 권장하며, mihomo도 설정에서 geo-auto-update: true와 업데이트 주기를 선언해 커널이 자동으로 가져오게 할 수 있습니다. 데이터베이스 파일은 클라이언트의 작업 디렉터리, 설정 파일과 같은 위치에 저장되며 업데이트 후에는 설정을 다시 로드해야 적용됩니다.

DNS 설정 최적화

분기 정확도의 절반은 DNS에 좌우됩니다. 도메인 해석이 오염되면 GEOIP 규칙이 잘못된 IP를 받아 분기 전체가 틀어지고, 부적절한 서버로 해석이 진행되면 현재 경로와 거리가 먼 CDN 노드를 받아 "노드 지연은 낮은데 웹은 그냥 느린" 현상으로 나타납니다. dns 항목은 설정에서 시간을 들여 조정할 가치가 가장 큰 부분입니다.

enhanced-mode: redir-host와 fake-ip

프록시 클라이언트의 기본 선택으로는 fake-ip가 종합적인 체감이 더 좋으며, 특히 TUN 모드에서는 거의 표준 조합입니다(4장 참고). fake-ip-filter는 반드시 실제 IP를 받아야 하는 도메인을 나열하는 항목으로, 로컬 네트워크 장비 검색, NTP 시간 동기화, 일부 게임 플랫폼의 연결 점검 등은 가짜 IP를 받으면 정상 동작하지 않으므로 아래 예시처럼 작성합니다. enhanced-mode를 전환한 뒤에는 클라이언트의 DNS 캐시를 한 번 비우는 것을 권장합니다(대부분의 클라이언트가 설정에 버튼을 제공하거나 커널을 재시작하면 됨). 그래야 신구 매핑이 섞이지 않습니다.

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "+.local"
    - time.windows.com
    - "+.ntp.org"
  nameserver:
    - https://223.5.5.5/dns-query
    - https://doh.pub/dns-query
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

nameserver, fallback과 분리 해석

nameserver는 기본 해석 그룹으로, 직접 연결 가능한 현지 DoH 서버를 넣어 현지 도메인 해석이 빠르고 가까운 CDN을 받도록 하는 것이 좋습니다. fallback은 검증 그룹으로 해외 DoH를 넣습니다. 커널은 두 그룹의 결과를 비교하여, nameserver가 반환한 IP가 fallback-filter에 선언된 범위(예: geoip-code가 CN)를 벗어나면 오염 가능성이 있다고 판단해 fallback의 결과를 사용합니다. 이 방식은 현지 해석 속도와 해외 해석의 순수성을 함께 챙길 수 있습니다. 더 나아가 nameserver-policy로 도메인별로 해석 서버를 지정할 수 있는데, 예를 들어 특정 규칙셋의 도메인을 전부 해외 DoH로 보내는 방식이며 정밀도는 가장 높지만 설정량도 많아지므로 필요에 따라 사용하면 됩니다.

해석 프로토콜의 선택

DNS 서버 주소는 여러 프로토콜 접두사를 지원합니다. 순수 UDP(223.5.5.5)는 가장 빠르지만 평문이라 조작될 수 있고, DoT(tls://)와 DoH(https://)는 암호화 전송으로 오염 방지 능력이 강해 모든 서버를 DoH 형태로 적는 것을 권장합니다. 단, DoH 서버 도메인 자체도 해석이 필요하므로 커널은 default-nameserver(순수 IP의 UDP 서버를 넣어야 함)로 이 부트스트랩 단계를 처리하며, 빠뜨리면 시작 시 모든 해석이 실패합니다. 속도 저하가 DNS와 관련 있다고 의심되면 3단계 진단법의 로컬 설정 단계를 하나씩 확인해보고, 더 많은 해석 관련 문제는 FAQ의 문제 해결 분류에 정리돼 있습니다.

TUN과 Fake-IP

시스템 프록시는 "프록시 설정을 존중하는" 앱에만 적용되며, 커맨드라인 도구, 게임 클라이언트, 일부 메신저의 UDP 트래픽은 이를 우회합니다. TUN 모드는 시스템에 가상 네트워크 카드를 만들어 3계층 트래픽 전체를 커널로 끌어들여 처리하는 방식으로, 가장 완전한 범위를 커버하며 UDP와 비정상 포트 트래픽을 처리하는 정답이기도 합니다.

핵심 파라미터

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 요청을 커널 DNS 처리로 가로채는 항목으로, fake-ip와 함께해야 TUN 하에서 도메인 분기가 정확해집니다. 이 때문에 TUN과 Fake-IP는 거의 항상 짝을 이룹니다. 앱이 가상 네트워크 카드를 통해 보낸 DNS 조회를 커널이 받아 즉시 가짜 IP로 응답하고, 이후 연결이 가짜 IP 대역에 매칭되면 커널이 원래 도메인을 역으로 조회해 도메인 규칙으로 정확히 분기시키며, 이 전체 과정이 시스템 리졸버에 의존하지 않습니다.

stack의 세 가지 프로토콜 스택

플랫폼별 권한 차이

TUN은 네트워크 카드를 생성할 시스템 권한이 필요하며 플랫폼마다 방식이 다릅니다. Windows에서는 클라이언트를 관리자 권한으로 실행하거나 클라이언트 설정에서 시스템 서비스를 설치해 서비스가 권한을 대신 갖도록 하면 평소에는 권한 상승이 필요 없습니다. macOS는 처음 활성화할 때 시스템 확장/네트워크 확장 권한 창이 뜨는데, "시스템 설정 → 개인정보 보호 및 보안"에서 허용한 뒤 스위치를 다시 켜야 합니다. Linux는 root 권한이 필요하거나 커널 바이너리에 cap_net_admin 권한을 부여해야 합니다. Android는 TUN이 아니라 VpnService라는 이름을 쓰며 처음 켤 때 VPN 연결 권한 창이 뜨는데 동의하면 되지만, 제조사의 절전 정책이 백그라운드 서비스를 종료해 연결이 끊기는 경우가 많아 클라이언트를 절전 화이트리스트에 추가해야 합니다. 자세한 방법은 Android 사용 시 주의점을 참고하세요. iOS 클라이언트(App Store 버전 Clash Plus 등)는 Network Extension 기반으로 권한 절차를 시스템이 일괄 처리합니다. 플랫폼별 클라이언트는 다운로드 페이지에서 확인할 수 있습니다.

도메인 스니핑

모든 연결이 도메인 정보를 자연스럽게 담고 있는 것은 아닙니다. 앱이 자체 DNS(브라우저 내장 DoH 등)를 사용하면 커널이 보는 것은 목적지 IP뿐이라 도메인 규칙이 전부 매칭되지 않고 GEOIP 판정으로 퇴화합니다. fake-ip-filter로 허용된 도메인도 마찬가지로 실제 IP 형태로 나타납니다. 도메인 스니핑(sniffer)은 트래픽 자체에서 도메인을 복원합니다. HTTP 요청의 Host 헤더, TLS 핸드셰이크의 SNI 필드, QUIC 초기 패킷에는 평문 도메인이 들어 있는데, 커널이 이를 읽어 연결 메타데이터를 다시 써서 도메인 규칙을 한 번 더 거치게 하여 "IP만 보이는" 연결을 정밀 분기 대상으로 되돌립니다.

설정 예시

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

sniff 아래에서 프로토콜별로 스니핑할 포트 범위를 선언하며, 세 프로토콜이 대부분의 상황을 커버합니다. override-destination은 스니핑으로 얻은 도메인으로 연결의 목적지 주소를 덮어쓸지 결정하며, 켜면 분기와 로그가 모두 도메인 기준으로 표시됩니다. skip-domain은 스니핑 후 오히려 문제가 생기는 도메인을 제외하는 항목으로, 일부 푸시 서비스나 인증서 검증이 엄격한 클라이언트는 목적지가 재작성되면 연결에 실패하니 이런 경우 해당 도메인을 추가하세요. force-domain은 반대로 매칭된 도메인에 강제로 덮어쓰기를 적용합니다.

필요할 때와 필요 없을 때

fake-ip를 이미 켜두고 모든 앱이 커널 DNS로 해석하는 경우, 연결 자체가 이미 도메인을 담고 있어 스니핑의 효과가 크지 않습니다. 실제로 도움이 되는 경우는 TUN 하에서 자체 DoH를 쓰는 브라우저 트래픽, 시스템 해석을 우회하는 모바일 앱, 그리고 redir-host 모드에서의 분기 정확도 보완입니다. 스니핑은 새 연결마다 첫 패킷을 한 번 분석하므로 CPU 부담이 매우 적어 상시 켜둬도 무방하지만, 특정 앱이 스니핑을 켠 뒤 이상하게 연결이 끊긴다면 목적지 덮어쓰기 동작을 먼저 의심하고 전체를 끄기보다 skip-domain으로 정확히 제외하세요. 로그(7장 참고)에서 연결 항목이 IP에서 도메인으로 바뀌면 스니핑이 적용되고 있다는 신호입니다.

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

구독으로 내려온 설정 파일을 직접 편집하는 것은 가장 흔한 관리 실수입니다. 구독이 갱신되는 순간 수동으로 고친 내용이 전부 사라집니다. 올바른 방식은 "구독이 제공하는 노드"와 "직접 관리하는 규칙, DNS, 정책 그룹"을 분리하는 것입니다. 구독은 노드만 담당하고, 로컬 오버라이드가 나머지 전부를 담당하면 구독을 갱신해도 노드만 바뀌고 개인 설정은 절대 건드려지지 않습니다.

클라이언트 계층의 오버라이드 메커니즘

유지보수 중인 데스크톱 클라이언트는 대부분 오버라이드 기능을 내장하고 있습니다. Clash Verge Rev는 "전역 확장 설정"과 스크립트 오버라이드를 제공해 YAML 병합이나 JavaScript 함수로 구독 설정이 적용되기 전에 임의 필드를 재작성할 수 있으며, Clash Plus와 FlClash도 각자의 오버라이드/믹스 입력창을 제공합니다. Verge Rev의 Merge 오버라이드를 예로 들면 접두사 의미는 다음과 같습니다. prepend-는 원래 목록 맨 앞에 삽입, append-는 맨 뒤에 추가, 필드 이름만 직접 쓰면 해당 항목 전체를 교체합니다.

prepend-rules:
  - DOMAIN-SUFFIX,internal.example.com,DIRECT
append-rules:
  - MATCH,자동 속도측정
dns:
  enable: true
  enhanced-mode: fake-ip

위 예시는 내부망 직접 연결 규칙 한 줄을 모든 구독 규칙보다 앞에 삽입해(우선 매칭을 보장) 기본 처리 규칙 한 줄을 추가하고, dns 항목 전체를 교체합니다. 규칙 계열 오버라이드는 prepend를 우선 사용해야 하는데, rules는 순서대로 매칭되므로 앞에 넣어야 확실히 적용됩니다.

커널 계층의 proxy-providers로 다중 구독 병합

여러 구독을 동시에 갖고 있을 때 클라이언트에서 설정을 오가며 전환할 필요 없이 proxy-providers로 여러 구독을 노드 소스로 삼아 하나의 설정에 통합할 수 있습니다.

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

proxy-groups:
  - name: 전체 노드
    type: select
    use: [sub-a, sub-b]
  - name: 홍콩 자동
    type: url-test
    use: [sub-a, sub-b]
    filter: "(?i)hk|香港"
    url: https://www.gstatic.com/generate_204
    interval: 300

정책 그룹은 노드 이름을 하나씩 적는 대신 use로 provider를 참조하며, filter 정규식과 함께 쓰면 두 구독의 홍콩 노드가 자동으로 같은 측정 그룹에 모입니다. 구독은 각자 interval에 따라 갱신되어 서로 영향을 주지 않습니다. health-check는 provider 내 노드가 독립적으로 생존 여부를 확인하게 하여 죽은 노드가 그룹에 남아있는 것을 방지합니다. 두 구독에 동일한 이름의 노드가 있으면 커널이 충돌을 보고하는데, provider의 override.additional-prefix로 노드 이름에 통일된 접두사를 붙여 구분할 수 있습니다.

외부 제어 패널

mihomo 커널은 RESTful 제어 인터페이스(일반적으로 external controller라 부름)를 노출하며, 클라이언트 패널 자체도 이 인터페이스의 소비자입니다. 인터페이스를 열어두면 독립적인 웹 패널을 연결하거나 커맨드라인으로 직접 커널을 조회하고 제어할 수 있어, 원격으로 소프트 라우터의 커널을 관리하거나 자동화 스크립트를 작성할 때 활용됩니다.

인터페이스 활성화

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

external-controller는 리스닝 주소를 선언합니다. 로컬에서만 사용한다면 127.0.0.1:9090로 쓰고, 로컬 네트워크의 다른 기기에서 접근해야 할 때(예: 소프트 라우터 관리)는 0.0.0.0:9090으로 바꾸며, 이때 secret은 반드시 강력한 값으로 설정해야 합니다. 이 인터페이스는 모든 연결 기록을 읽고 노드를 전환할 수 있으므로, 무방비 상태로 두면 로컬 네트워크의 누구에게나 제어권을 넘기는 것과 같습니다. external-ui는 정적 패널 디렉터리를 가리키며 커널이 같은 포트의 /ui 경로에서 이를 서빙합니다. external-ui-url은 커널이 패널 압축 파일을 자동으로 다운로드해 해당 디렉터리에 풀도록 해 수동 배포를 줄여줍니다.

자주 쓰는 인터페이스 빠른 참조

커맨드라인으로 인터페이스가 정상 동작하는지 확인하고 노드를 수동으로 한 번 전환하는 예시입니다.

curl -H "Authorization: Bearer your-secret" \
  http://127.0.0.1:9090/proxies

curl -X PUT \
  -H "Authorization: Bearer your-secret" \
  -H "Content-Type: application/json" \
  -d '{"name":"홍콩 자동"}' \
  http://127.0.0.1:9090/proxies/수동 선택

연결 뷰로 분기 문제 진단하기

이 인터페이스가 실무에서 가장 유용한 부분은 "특정 사이트가 어떤 규칙을 탔는지" 진단하는 것입니다. 패널의 연결 페이지(또는 GET /connections)를 열어 도메인으로 필터링하면 각 연결에 매칭된 규칙과 최종 출구 노드가 표시됩니다. 분기가 예상과 다를 때는 먼저 여기서 규칙을 잘못 썼는지, 순서가 틀렸는지, 아니면 DNS/스니핑 단계에서 도메인을 얻지 못했는지(항목이 순수 IP로 표시되는 것이 그 신호이며, 3장과 5장 내용으로 해결) 확인하는 것이 무작정 설정을 고치는 것보다 훨씬 효율적입니다. 로그 레벨은 설정에서 log-level: info로 조정할 수 있으며, 진단 중에는 임시로 debug로 바꾸고 끝나면 반드시 되돌려 로그 폭주로 성능이 저하되는 것을 방지하세요.