Clash 심화 설정 가이드

읽기 전 준비와 설정 파일 구조

계속하기 전에 두 가지를 확인하세요: 클라이언트가 이미 정상적으로 인터넷에 연결되어 있는지(튜토리얼 페이지의 핵심 과정을 마쳤는지), 그리고 현재 사용 중인 설정이 어느 구독에서 온 것인지 알고 있는지. 심화 설정의 모든 변경은 "정상 작동하는 기준선"이 있다는 전제 위에서 이루어집니다. 기준선이 불안정하면 이후 조정을 검증할 방법이 없습니다.

mihomo의 설정 파일은 YAML 형식이며, 최상위 키는 역할에 따라 다섯 개 영역으로 나눌 수 있습니다. 이 매뉴얼의 챕터 구성도 이와 하나씩 대응됩니다:

• 인바운드: port, socks-port, mixed-port, tun——트래픽이 어디로 들어오는지;
• 아웃바운드: proxies, proxy-providers, proxy-groups——트래픽이 어디로 나갈 수 있는지;
• 라우팅: rules, rule-providers——어떤 트래픽이 어떤 출구로 나가는지;
• 해석: dns, sniffer——도메인이 어떻게 주소로 변환되고, 주소가 어떻게 도메인으로 복원되는지;
• 제어: external-controller, external-ui, secret——실행 상태를 외부에 어떻게 노출하는지.

최소 실행 가능 골격

모든 선택 항목을 제거하면 실행 가능한 설정은 이런 모습입니다. 이후 각 챕터의 예제 코드는 모두 이 골격의 해당 위치에 붙는다고 가정합니다:

mixed-port: 7890
mode: rule
log-level: info

proxies: []        # 일반적으로 구독에서 제공됨

proxy-groups:
  - name: 노드 선택
    type: select
    proxies:
      - DIRECT

rules:
  - GEOIP,CN,DIRECT
  - MATCH,노드 선택

플랫폼 차이: iOS와 데스크톱

iOS의 Clash Plus는 Network Extension을 기반으로 동작하며, 설정 관리 방식은 "구독을 기반으로 오버라이드를 증분 적용"하는 방식입니다——보통 구독 원문을 직접 수정하지 않고, 클라이언트 안에서 자신의 수정 사항을 덧씌웁니다(6장에서 자세히 설명). 데스크톱의 Clash Verge Rev, FlClash는 설정 전체를 직접 편집할 수 있습니다. 어떤 클라이언트를 쓰든 이 매뉴얼에서 다루는 것은 커널 계층의 문법이며, 작성 방식은 공통입니다.

마지막으로 습관화할 만한 것 하나: 설정을 수정할 때마다 "설정 리로드 → 로그 확인 → 동작 검증" 세 단계를 고정적으로 거치세요. 로그 레벨별 확인 순서와 자주 나오는 오류의 의미는 블로그 《Clash 실행 로그 읽는 법》에서 항목별로 설명하며, 이 매뉴얼의 뒤쪽 챕터에서도 이 검증 방법을 계속 사용합니다.

프록시 그룹 유형과 실전 구성

프록시 그룹(proxy-groups)은 규칙과 노드 사이의 중간 계층입니다. 규칙이 매칭되면 대상은 단일 노드, 내장 출구(DIRECT / REJECT)일 수도 있고, 또 다른 프록시 그룹일 수도 있습니다. 그리고 프록시 그룹의 구성원 역시 노드이거나 또 다른 프록시 그룹일 수 있습니다. "그룹은 그룹을 중첩할 수 있다"는 이 원리를 이해하는 것이 복잡한 트래픽 분배를 구성하는 전제 조건입니다.

mihomo는 다섯 가지 그룹 유형을 제공하며, 선택 로직이 각각 다릅니다:

자동 테스트 그룹의 4가지 핵심 파라미터

url-test와 fallback은 헬스체크에 의존하며, 동작은 네 가지 파라미터로 결정됩니다. url은 속도 측정 대상이며, 관례적으로 204를 반환하는 가벼운 주소를 사용합니다. interval은 검사 주기(초)로, 300이 안정적인 값이며 너무 낮게 설정하면 노드 트래픽을 헛되이 소모합니다. tolerance는 전환 허용 오차(밀리초)로, 신구 노드의 지연 차이가 이 값보다 작으면 전환하지 않아 지연이 비슷한 두 노드 사이를 오가며 떠는 현상을 방지합니다. lazy: true는 그룹이 사용되지 않을 때 속도 측정을 중지한다는 의미로, 모바일 기기에서는 전력과 트래픽 절약을 위해 켜두는 것을 권장합니다.

실전: 3계층 구조

대부분의 상황에서 명확한 설정은 3계층만 있으면 됩니다: 수동 메인 진입 그룹이 최상단, 자동 테스트와 장애 조치가 중간, 구독 노드가 최하단입니다. 규칙은 모두 메인 진입 그룹을 가리키며, 일상적인 전환은 이 그룹 하나만 조작하면 됩니다:

proxy-groups:
  - name: 노드 선택
    type: select
    proxies:
      - 자동 테스트
      - 장애 조치
      - DIRECT

  - name: 자동 테스트
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true
    use:
      - main-sub

  - name: 장애 조치
    type: fallback
    url: https://www.gstatic.com/generate_204
    interval: 300
    use:
      - main-sub

예제의 use 필드는 프록시 컬렉션(proxy-providers, 6장에서 자세히 설명)을 참조하며, 그룹의 구성원이 구독 업데이트에 따라 자동으로 동기화되어 노드 이름을 직접 작성할 필요가 없습니다. 주의할 점 두 가지: 그룹 이름을 rules에서 참조할 때는 한 글자도 다르면 안 되며, 공백 하나만 더 있어도 실행이 실패합니다. 그룹끼리 서로 참조할 때 순환이 생기면 안 되며, 커널은 시작 시 즉시 오류를 내고 로드를 거부합니다.

규칙셋 구독화 관리

수천 줄의 규칙을 rules에 직접 작성하면 두 가지 대가가 따릅니다: 설정 본체가 비대해져 읽기 어려워지고, 규칙이 바뀔 때마다 메인 설정을 수정해야 합니다. rule-providers의 발상은 규칙을 별도 파일로 외부화하여, 커널이 주기적으로 자동으로 가져와 업데이트하고, 메인 설정에는 참조 한 줄만 남기는 것입니다.

rule-providers:
  streaming:
    type: http
    behavior: domain
    format: yaml
    url: https://example.com/rules/streaming.yaml
    path: ./rule-sets/streaming.yaml
    interval: 86400

rules:
  - RULE-SET,streaming,노드 선택
  - GEOIP,CN,DIRECT
  - MATCH,노드 선택

필드를 하나씩 살펴보면: type은 http(원격 다운로드) 또는 file(로컬 파일)을 선택합니다. url과 path는 각각 원격 주소와 로컬 캐시 경로입니다. interval은 자동 업데이트 주기(초)로, 규칙셋 내용은 자주 바뀌지 않으므로 86400(하루)이면 충분합니다. format은 yaml, text, mrs를 지원합니다——mrs는 mihomo의 바이너리 규칙 형식으로 용량이 작고 로딩이 빨라, 규칙 소스에서 제공된다면 우선적으로 선택하는 것이 좋습니다.

behavior: 가장 쉽게 실수하는 필드

behavior는 이 규칙셋의 내용 형태를 선언하며, 파일의 실제 내용과 반드시 일치해야 합니다:

GeoSite / GeoIP와의 관계

GEOSITE와 GEOIP 규칙 뒤에는 또 다른 형태의 "미리 패키징된 규칙셋"이 있습니다——두 개의 바이너리 데이터베이스로, 국가 또는 사이트별로 도메인과 IP 대역을 분류해 수록합니다. 이들은 rule-providers와 충돌하지 않습니다: geo 데이터베이스는 일반적인 대분류를 다루고, rule-providers는 개인화된 항목을 보완합니다. 데이터베이스가 너무 오래되면 분기 정확도가 바로 떨어지므로, 업데이트 방법은 블로그 《GeoIP·GeoSite 데이터베이스 업데이트 가이드》를 참고하세요. rules 내 각 유형의 문법과 위에서 아래로 적용되는 우선순위 원칙은 블로그 《Clash 커스텀 규칙 작성법 상세 설명》에서 완전히 다루므로 여기서는 반복하지 않습니다.

DNS 설정 최적화

먼저 "커널이 왜 DNS를 직접 관리해야 하는가"에 답해보겠습니다. 규칙 기반 분기는 해석 결과에 크게 의존합니다: GEOIP,CN,DIRECT는 도메인을 IP로 해석한 뒤에야 소속을 판단할 수 있습니다. 해석을 시스템에 맡겼는데 시스템이 오염된 주소를 받으면, GEOIP는 원래 프록시를 타야 할 트래픽을 직접 연결로 잘못 판단하게 되고, 이는 "규칙은 맞는데 접속이 안 되는" 형태로 나타납니다. 커널이 신뢰할 수 있는 암호화 DNS로 직접 해석하게 하는 것이 분기 정확도의 기반입니다.

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
  nameserver:
    - https://doh.pub/dns-query
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - https://doh.pub/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://doh.pub/dns-query

세 종류의 nameserver가 각각 담당하는 영역

이 필드들은 헷갈리기 쉬운데, "누가 해석되는가"를 기준으로 기억하면 됩니다: default-nameserver는 순수 IP만 입력할 수 있으며, nameserver에 있는 DoH 주소 자체의 도메인을 해석하는 데 전용으로 쓰입니다——닭이 먼저냐 달걀이 먼저냐 문제를 풀어주는 부트스트래퍼입니다. nameserver는 주력 해석기로, 모든 일반 조회를 담당하며 DoH(https:// 접두사) 또는 DoT(tls:// 접두사) 방식을 권장합니다. 평문 53번 포트는 일부 네트워크 환경에서 하이재킹될 수 있습니다. proxy-server-nameserver는 프록시 노드 자체의 서버 도메인 해석을 전담하며, 이를 로컬 직결 DoH로 고정하면 "노드 도메인 해석이 프록시를 타야 하는데, 프록시는 다시 노드에 의존한다"는 순환 잠금을 피할 수 있습니다.

nameserver-policy: 도메인별로 해석기 분배

nameserver-policy는 도메인 패턴별로 해석기를 지정할 수 있게 해주며, 가장 흔히 쓰는 예가 예제에 있는 geosite:cn입니다: 중국 본토 사이트는 로컬 DoH로 고정 해석해 가까운 CDN 주소를 얻고, 나머지 도메인은 주력 nameserver에 맡깁니다. 키에는 일반 도메인 패턴도 쓸 수 있어(예: 사내망 DNS를 가리키는 "+.internal.example.com"), 사무실 네트워크 환경에도 적합합니다.

예제의 enhanced-mode: fake-ip는 DNS와 TUN이 만나는 지점에서 가장 중요한 스위치이므로 별도의 챕터로 다룰 가치가 있습니다——아래에서 계속됩니다.

TUN 모드와 Fake-IP

시스템 프록시는 "프록시 설정을 읽으려는" 애플리케이션만 커버할 수 있으며, 명령줄 도구, 일부 게임, 백그라운드 서비스는 그대로 우회합니다. TUN 모드의 방식은 더 근본적입니다: 가상 네트워크 카드를 하나 생성하고 라우팅 테이블과 함께 기기의 모든 트래픽을 커널로 끌어들여 처리합니다——애플리케이션이 우회할 방법이 없는 것은, 그것들이 보내는 모든 패킷이 이 가상 카드를 반드시 거쳐야 하기 때문입니다.

플랫폼 차이를 먼저 명확히 하겠습니다: iOS의 Clash Plus는 Network Extension의 터널링 메커니즘을 기반으로 동작하며, 그 동작 방식이 본질적으로 TUN과 동등하므로 별도의 스위치가 필요하지도, 존재하지도 않습니다. 아래의 tun 설정 블록은 주로 데스크톱과 라우터 환경을 대상으로 합니다(Windows는 관리자 권한으로 가상 네트워크 카드 드라이버를 설치해야 하고, macOS는 시스템 설정에서 네트워크 확장을 승인해야 합니다). 라우터에서 커널을 직접 구동하는 전체적인 방식은 블로그 《라우터에서 mihomo 커널 직접 구동하기》를 참고하세요.

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

stack은 프로토콜 스택 구현 방식을 결정합니다: system은 시스템 스택을 사용해 성능이 좋지만 호환성은 플랫폼에 따라 다릅니다. gvisor는 사용자 공간 스택을 사용해 호환성이 안정적입니다. mixed는 두 가지의 장점을 모두 취하므로 보통 이것을 바로 선택하면 됩니다. auto-route는 라우팅 테이블을 자동으로 작성하고, auto-detect-interface는 물리적 출구 네트워크 카드를 자동으로 인식해 루프백을 방지합니다. 이 두 항목은 켜둔 상태를 유지하세요. dns-hijack: any:53은 53번 포트로 향하는 모든 평문 DNS 조회를 커널 해석으로 가로챕니다——이것이 TUN 모드에서 "해석은 반드시 커널을 거친다"는 것을 보장하는 핵심 요소입니다.

Fake-IP: 대기 한 번을 줄이는 해석 모드

앞 챕터의 enhanced-mode로 돌아가 보겠습니다. 전통적인 redir-host 모드에서는 커널이 DNS 조회를 받으면 한 번 실제로 해석해야 응답할 수 있습니다. fake-ip 모드는 예약된 네트워크 대역(기본값 198.18.0.1/16)에서 즉시 가짜 주소를 할당해 반환하면서 "이 가짜 IP는 이 도메인에 대응한다"는 것을 기억해둡니다. 애플리케이션이 가짜 IP로 연결을 시작하면 커널은 매핑을 통해 도메인을 복원해 규칙과 매칭합니다——프록시를 타는 트래픽은 도메인을 그대로 원격 서버에 넘겨 해석하게 하므로, 로컬에서의 실제 해석 한 번이 완전히 생략되어 연결이 더 빠르고 도메인 매칭도 더 정확해집니다.

호환성 문제는 fake-ip-filter로 해결합니다: 반드시 실제 IP를 확보해야 하는 도메인——LAN 기기 검색, NTP 시간 동기화, 일부 게임 대전 플랫폼——을 목록에 추가해 실제 해석을 거치게 합니다:

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

도메인 스니핑: 잃어버린 도메인 되찾기

앞 두 챕터에서는 "도메인을 어떻게 해석하는가"를 다뤘지만, 커널의 DNS를 전혀 거치지 않는 트래픽 유형도 있습니다: 애플리케이션이 자체 암호화 DNS를 내장한 경우(예: 브라우저 내장 DoH), 혹은 서버 IP를 코드에 하드코딩한 경우입니다. 이런 연결이 커널에 도달할 때는 목적지 IP만 있고, 설정에서 정성껏 관리한 도메인 규칙(DOMAIN-SUFFIX, GEOSITE)은 모두 무효가 되어 IP 규칙에만 의존하게 되므로 분기 정확도가 크게 떨어집니다.

도메인 스니핑(sniffer)의 방식은 트래픽 자체에서 도메인을 되찾는 것입니다: TLS 핸드셰이크의 ClientHello에는 SNI가 들어 있고, HTTP 요청 헤더에는 Host가 있으며, 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:
    - "Mijia Cloud"

세 개의 프로토콜 블록은 각각 어떤 포트에서 해당 프로토콜을 스니핑할지 선언합니다. override-destination은 스니핑으로 얻은 도메인으로 연결의 목적지 주소를 덮어쓴다는 의미로, 보통 켜둔 상태를 유지합니다. force-domain에 나열된 도메인은 해석 결과가 정상이더라도 스니핑 결과로 강제 덮어씁니다. 일부 CDN 도메인과 IP가 맞지 않는 경우에 대응하기 위한 것입니다. skip-domain은 반대로, 스니핑 후 오히려 문제가 생기는 대상을 제외합니다——일부 스마트홈 전용 프로토콜이 오인식될 때 여기에 추가하면 됩니다.

비용 측면에서, 스니핑은 각 연결의 초기 핸드셰이크 데이터만 읽으므로 오버헤드는 무시할 수 있는 수준입니다. fake-ip와는 대체 관계가 아니라 상호 보완 관계입니다: fake-ip는 커널 DNS를 거치는 트래픽에 도메인이 붙어 있도록 보장하고, 스니핑은 커널 DNS를 우회하는 부분을 보완합니다. 두 가지를 동시에 켜야 도메인 규칙의 적용 범위가 완전해집니다.

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

누구나 겪는 문제가 있습니다: 구독 파일은 서버 측에서 생성되므로, 그 안에 직접 추가한 규칙이나 수정한 DNS는 다음 구독 업데이트 때 통째로 덮어써져 사라집니다. 올바른 방법은 구독을 원본 그대로 유지하고, 자신의 수정 사항을 오버라이드로 선언하는 것입니다——구독이 업데이트될 때마다 클라이언트가 자동으로 오버라이드를 다시 덧씌웁니다.

두 가지 오버라이드 형태

주요 클라이언트는 두 종류의 오버라이드를 제공합니다. 선언형(merge): YAML 조각을 작성해 어떤 최상위 키를 교체할지, 어떤 목록을 앞뒤에 추가할지 선언하는 방식으로, 직관적이고 실수가 적습니다. 스크립트형: 완전한 설정 객체를 받아 수정된 설정을 반환하는 함수를 작성하는 방식으로, 유연하지만 디버깅 부담을 스스로 져야 합니다. Clash Plus와 Clash Verge Rev 모두 오버라이드 입력창을 내장하고 있으며, 일상적인 요구에는 선언형만으로 충분합니다. 흔히 쓰이는 merge 문법을 예로 들면:

# 오버라이드 조각: dns 키 전체 교체, 규칙 앞부분에 두 줄 추가
dns:
  enable: true
  enhanced-mode: fake-ip

prepend-rules:
  - DOMAIN-SUFFIX,internal.example.com,DIRECT
  - PROCESS-NAME,Terminal,DIRECT

merge를 이해하려면 한 가지만 기억하면 됩니다: 일반 최상위 키는 전체 교체이고, prepend / append 접두사가 붙은 키는 목록에 추가하는 방식입니다. 규칙은 위에서 아래로 매칭되므로, 커스텀 규칙을 먼저 적용하고 싶으면 앞부분 추가를 사용하고, 최종 보완용으로만 쓰고 싶으면 뒷부분 추가를 사용하세요.

다중 구독 병합: proxy-providers

여러 개의 구독을 가지고 있을 때, 클라이언트에서 설정을 왔다갔다 전환할 필요는 없습니다. proxy-providers는 각 구독을 하나의 노드 컬렉션으로 선언하고, 프록시 그룹이 use로 해당 컬렉션을 참조하면 모든 구독의 노드가 하나의 설정으로 통합됩니다:

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

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

필드 구조는 2장의 rule-providers와 동일합니다: interval은 구독 자동 업데이트 주기를 제어하며, 43200(반나절)이 대부분의 구독에 충분합니다. health-check는 컬렉션 내 노드에 가용성 상태를 부여해 url-test / fallback 그룹이 바로 활용할 수 있게 합니다. 1장 예제의 use: [main-sub]가 참조하는 것이 바로 이것입니다——그룹 구성원이 구독 업데이트에 따라 자동으로 늘어나거나 줄어들며, 설정 본체는 한 줄도 수정할 필요가 없습니다. 구독 업데이트가 실패하면 먼저 로그의 가져오기 오류를 확인하고, 그다음 URL이 만료되었는지 확인하세요.

외부 제어와 패널

커널이 실행 중일 때의 모든 상태——노드 지연, 활성 연결, 실시간 로그, 현재 모드——는 하나의 RESTful API를 통해 외부에 노출됩니다. 이것이 외부 제어 인터페이스입니다. 클라이언트의 연결 목록, 웹 패널, 명령줄 조회는 내부적으로 모두 동일한 API를 사용합니다.

external-controller: 127.0.0.1:9090
secret: "your-secret"
external-ui: ./ui

external-controller는 리스닝 주소와 포트를 선언합니다. secret은 접근 토큰으로, 모든 요청이 헤더에 담아 전송해야 합니다. external-ui는 정적 패널 디렉터리를 가리키며, 커널이 같은 포트의 /ui 경로 아래에 이를 호스팅하므로 브라우저에서 바로 접속할 수 있습니다. 주요 웹 패널은 모두 순수 프런트엔드 프로젝트이므로, 해당 디렉터리에 압축을 풀어놓으면 바로 사용할 수 있습니다.

curl로 커널과 직접 대화하기

# 전체 프록시 그룹과 노드 상태 확인
curl -H "Authorization: Bearer your-secret" \
  http://127.0.0.1:9090/proxies

# "노드 선택" 그룹의 현재 출구 전환
curl -X PUT -H "Authorization: Bearer your-secret" \
  -d '{"name": "자동 테스트"}' \
  http://127.0.0.1:9090/proxies/노드 선택

# 실시간 로그 스트림 / 활성 연결
curl -H "Authorization: Bearer your-secret" \
  http://127.0.0.1:9090/logs
curl -H "Authorization: Bearer your-secret" \
  http://127.0.0.1:9090/connections

자주 쓰는 엔드포인트는 네 개만 기억하면 됩니다: /proxies(그룹과 노드), /connections(활성 연결, "이 트래픽이 어느 출구로 나갔는지" 확인하는 가장 직접적인 방법), /logs(실시간 로그 스트림), /configs(실행 중인 설정 읽기 및 무중단 업데이트). 자동화 스크립트——예를 들어 네트워크 전환 후 자동으로 그룹을 바꾸는 것——도 이 엔드포인트들을 중심으로 작성합니다.

iOS 상황을 덧붙이면: Clash Plus의 내장 패널은 클라이언트 내부에서 동일한 인터페이스를 사용하므로, 일반적인 사용에는 이 절의 내용을 수동으로 설정할 필요가 없습니다. 실제로 외부 제어가 필요한 경우는 데스크톱 디버깅과 라우터의 헤드리스 배포, 이 두 가지 상황입니다.