Clash 설정 파일 YAML 매뉴얼

01설정 파일 총괄: YAML 문법과 최상위 구조

Clash 설정은 YAML 형식을 사용합니다. YAML은 들여쓰기로 계층을 표현하며, 규칙이 많지 않지만 하나라도 어기면 오류가 납니다: 들여쓰기는 공백으로 통일하고(관례상 두 칸씩 한 단계), 탭은 절대 사용하지 않습니다. 키와 값 사이의 콜론 뒤에는 반드시 공백이 하나 있어야 합니다. 목록 항목은 「하이픈 + 공백」으로 시작합니다. #부터 줄 끝까지는 주석입니다. 문자열은 보통 따옴표가 필요 없지만, 값에 콜론·해시·중괄호 같은 특수 문자가 들어가거나 숫자·*·~로 시작할 때는 따옴표로 감싸야 합니다. 그러지 않으면 해석 결과가 예상과 달라질 수 있습니다 — 비밀번호, 구독 URL, 와일드카드 도메인 이 세 가지 값은 항상 따옴표를 붙이는 것을 권장합니다.

설정 파일은 어디에 있나

그래픽 클라이언트(Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu 등)는 설정 디렉터리를 자체적으로 관리합니다: 구독을 가져오면 profile 형태로 저장되며, 확인과 수정은 클라이언트 내장 편집기나 오버라이드 기능을 통해 이루어지므로 일반적으로 파일 시스템에서 경로를 직접 찾을 필요가 없습니다. 커널을 직접 실행하는 사용자(서버, 라우터 환경)는 기본적으로 작업 디렉터리에서 config.yaml을 읽습니다. Linux에서 관례적인 경로는 ~/.config/mihomo/config.yaml이며, -f 옵션으로 파일을 명시적으로 지정하거나 -d 옵션으로 작업 디렉터리를 지정할 수도 있습니다.

최상위 블록 개요

완전한 설정은 여러 최상위 블록으로 이루어지며, 각 블록은 자기 역할만 담당하고 서로 침범하지 않습니다. 아래 표는 전체 지도이며, 이후 각 장에서 이 순서대로 하나씩 자세히 설명합니다:

최소 동작 예제

아래 설정은 선택 항목을 모두 제거하고 「입력 포트 하나, 노드 하나, 정책 그룹 하나, 규칙 세 줄」만 남긴 것으로, 문법 검사를 통과하고 정상 동작하는 최소 골격입니다. 이것을 이해하면 이후 각 장은 이 골격에 살을 붙여 나가는 과정입니다:

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies:
  - name: "예시 노드"
    type: ss
    server: example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"

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

rules:
  - DOMAIN-SUFFIX,example.com,노드 선택
  - GEOIP,CN,DIRECT
  - MATCH,노드 선택

세 블록의 협력 관계: proxies는 「어떤 출구가 있는지」를 정의하고, proxy-groups는 그 출구를 「어떻게 고를지」로 조직하며, rules는 「어떤 트래픽을 어느 그룹에 맡길지」를 결정합니다. 규칙의 출구는 그룹 이름일 수도 있고, 노드 이름 또는 내장된 DIRECT(직결)나 REJECT(거부)를 직접 써도 됩니다. 이 골격을 좀 더 쉽게 단락별로 풀어 쓴 글은 블로그 《Clash 설정 파일 구조 단락별 해부》에서 볼 수 있습니다.

02공통 필드: 포트, 모드와 실행 제어

공통 필드는 설정 파일 맨 위에 위치하며 어떤 블록에도 속하지 않고, 커널이 「어떤 자세로 동작할지」를 결정합니다. 이 필드들이 잘못되면 분류 오류가 나지는 않지만, 연결이 안 되거나 잘못된 포트로 연결되거나 로그가 폭주하는 문제가 생기므로 하나씩 확실히 알아둘 가치가 있습니다.

인바운드 포트와 로컬 네트워크 공유

port는 HTTP 프록시를 수신하고, socks-port는 SOCKS5를 수신하며, mixed-port는 같은 포트에서 두 프로토콜을 동시에 받습니다 — 요즘 설정은 대부분 mixed-port: 7890 한 줄만 써서 포트 두 개를 관리하는 수고를 줄입니다. Linux 전용인 redir-port와 tproxy-port는 투명 프록시 환경에서 쓰이며, 데스크톱 사용자는 무시해도 됩니다. allow-lan은 같은 로컬 네트워크의 다른 기기 연결을 허용할지 결정합니다: true로 설정하면 같은 Wi-Fi에 있는 휴대폰이나 TV가 이 기기로 프록시 주소를 지정할 수 있습니다. bind-address는 수신할 네트워크 인터페이스 주소를 추가로 제한하며, 기본값 "*"는 모든 인터페이스를 의미합니다.

mode: 세 가지 동작 모드

mode는 유효한 값이 세 가지뿐입니다. rule은 rules 블록을 순서대로 매칭해 분류하는, 평소 유일하게 권장되는 모드입니다. global은 모든 트래픽을 같은 출구로 보내며 단일 노드를 테스트할 때만 임시로 씁니다. direct는 전부 직결로, 수신 포트는 유지하지만 프록시 처리는 전혀 하지 않는 것과 같습니다. 세 모드는 클라이언트 화면에서 대응하는 스위치가 있으며 의미는 설정 필드와 완전히 동일합니다. 실무적인 선택 기준은 튜토리얼 페이지 두 번째 단계를 참고하세요.

로그, 외부 제어와 상태 저장

log-level은 적은 것부터 많은 순서로 silent, error, warning, info, debug가 있습니다. 평소에는 info를 쓰고, 분류 문제를 조사할 때만 잠시 debug로 바꾸면 각 연결이 어느 규칙에 걸렸는지 볼 수 있습니다. 조사가 끝나면 원래대로 되돌리는 걸 잊지 마세요, 그러지 않으면 로그 파일이 빠르게 커집니다. external-controller는 RESTful API를 활성화합니다(관례상 127.0.0.1:9090에서 수신). 웹 패널과 서드파티 도구는 모두 이 API로 상태를 읽고 노드를 전환합니다. secret은 이 API의 접근 암호로, 수신 주소가 로컬로만 제한되지 않는다면 반드시 설정해야 합니다. profile 블록은 두 가지 저장 항목을 제어합니다: store-selected는 각 정책 그룹에서 마지막으로 수동 선택한 노드를 기억해 재시작 후에도 유지하고, store-fake-ip는 fake-ip 매핑 테이블을 디스크에 기록해 재시작 후 해석이 흔들리는 것을 줄여줍니다.

mixed-port: 7890
allow-lan: false
bind-address: "*"
mode: rule
log-level: info
ipv6: false
external-controller: 127.0.0.1:9090
secret: "your-secret"
profile:
  store-selected: true
  store-fake-ip: true

03dns 블록: 도메인 해석과 fake-ip

분류 규칙 중 많은 항목이 도메인으로 매칭하는데, 도메인 해석 자체가 오염되거나 가로채질 수 있습니다 — 커널이 시스템 DNS 결과를 그대로 쓰면 규칙 판단과 실제 연결 모두 엉뚱한 방향으로 흘러갑니다. dns 블록은 커널이 직접 해석을 담당하게 합니다: 어떤 업스트림을 쓸지, 암호화 채널을 쓸지, fake-ip를 켤지 모두 여기서 선언합니다. TUN 모드를 켜면 이 블록은 반드시 활성화되어야 합니다. 그러지 않으면 가로챈 DNS 질의에 응답할 곳이 없습니다.

enhanced-mode: fake-ip와 redir-host

fake-ip는 현재 주류 방식입니다: 앱이 도메인 조회를 시작하면 커널은 즉시 fake-ip-range(관례상 198.18.0.1/16)에서 가짜 주소를 하나 골라 돌려주고, 「가짜 주소 ↔ 도메인」매핑을 기록합니다. 앱이 그 가짜 주소로 연결을 시도하면 커널은 매핑을 통해 도메인을 복원한 뒤 규칙 매칭과 실제 해석을 수행합니다. 장점은 사전 해석 한 번을 절약하고 규칙이 항상 도메인 기준으로 정확히 매칭된다는 것입니다. 대가는 일부 프로그램이 198.18로 시작하는 주소를 받으면 혼란스러워한다는 점입니다 — 로컬 기기 탐색, NTP 시간 동기화, 일부 게임 플랫폼이 대표적인 사례이며, 이것이 바로 fake-ip-filter가 존재하는 이유입니다: 여기에 나열된 도메인은 fake-ip를 건너뛰고 실제 주소를 바로 돌려줍니다. redir-host 모드는 항상 실제 IP를 반환해 호환성은 가장 좋지만 규칙 매칭 정밀도와 성능이 모두 떨어져, fake-ip가 문제를 일으킨다고 확인된 경우에만 되돌려 사용합니다.

업스트림 서버의 3단계 구조

default-nameserver는 가이드 계층으로, 이후 DoH 서버 자체 도메인을 해석하는 데만 쓰이므로 반드시 순수 IP를 넣어야 합니다. nameserver는 주력 계층으로 평소 조회는 모두 여기로 보내며, DoH(https://로 시작) 또는 DoT(tls://로 시작) 주소를 권장합니다. fallback은 보조 계층으로 fallback-filter와 함께 동작합니다 — 대표적인 전략은 geoip: true와 geoip-code: CN을 함께 쓰는 것으로, 주력 계층의 해석 결과가 중국 본토 IP 대역이면 그대로 채택하고, 아니면 fallback 결과로 바꿔서 오염에 대응합니다. 이 밖에 정밀 지정 도구인 nameserver-policy로 특정 도메인에 전용 업스트림을 지정할 수 있습니다. 예를 들어 회사 내부망 도메인을 내부 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.*.com"
    - "ntp.*.com"
  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
  fallback-filter:
    geoip: true
    geoip-code: CN

fake-ip-filter는 두 가지 와일드카드를 지원합니다: *는 한 단계만 매칭하고, +는 여러 단계를 매칭합니다(+.local은 a.b.local도 포함). fake-ip 관련 필드를 수정한 뒤에는 커널을 재시작하고 클라이언트의 fake-ip 캐시를 비워 이전 매핑을 무효화하는 것을 권장합니다. 또한 TUN 모드의 DNS 처리와 브라우저 인증서 오류 사이에는 놓치기 쉬운 인과관계가 있는데, 자세한 분석은 블로그 《프록시를 켠 뒤 브라우저에 HTTPS 인증서 오류가 뜬다면?》에서 확인할 수 있습니다.

04tun 블록: 가상 네트워크 카드와 시스템 수준 인수

일반적인 「시스템 프록시」는 운영체제에 HTTP/SOCKS 포트를 등록하는 것에 불과해서, 사용 여부는 전적으로 애플리케이션의 협조에 달려 있습니다 — 커맨드라인 도구, 일부 게임 클라이언트, 많은 백그라운드 서비스는 이 설정을 전혀 읽지 않습니다. TUN 모드는 접근 방식이 다릅니다: 가상 네트워크 카드를 만들고 기본 경로를 그쪽으로 돌려, 모든 트래픽을 네트워크 계층에서 가로채므로 애플리케이션이 우회할 여지가 없습니다. 대가는 더 높은 시스템 권한이 필요하고, 시스템 프록시와는 별개의 두 가지 병렬 메커니즘이 된다는 점입니다.

핵심 필드

stack은 프로토콜 스택 구현을 선택합니다: system은 시스템 네트워크 스택을 사용해 성능이 가장 좋으며 데스크톱 플랫폼의 기본 권장값입니다. gvisor는 사용자 모드 구현으로 호환성이 필요한 경우의 대안입니다. mixed는 둘을 절충한 방식입니다. auto-route는 라우팅 테이블을 자동으로 수정해 기본 경로를 가상 네트워크 카드로 향하게 하며, 거의 항상 켜야 합니다. auto-detect-interface는 실제 물리 출구 네트워크 카드를 자동으로 식별해, 트래픽이 가상 네트워크 카드 안에서 맴돌며 루프가 생기는 것을 막아줍니다. dns-hijack은 가로챌 DNS 대상을 선언하는데, any:53으로 쓰면 53번 포트로 가는 모든 질의를 가로채 커널 dns 블록이 응답하게 합니다 — 이것이 「TUN을 켜면 dns도 반드시 켜야 하는」 이유입니다. strict-route는 경로를 더 엄격히 조여 우회를 막지만, 일부 가상 머신·컨테이너 환경에서 통신이 안 되는 문제를 일으킬 수 있으니 문제가 생기면 끄면 됩니다.

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
  mtu: 1500

플랫폼별 권한과 차이점

05proxies: 프록시 노드 필드

proxies는 목록이며, 각 항목이 하나의 노드를 완전히 기술합니다. 구독을 사용하는 경우 이 블록은 항공사(기항지 서비스 제공자)가 생성하고 구독 갱신 때마다 함께 갱신되므로 보통 직접 작성할 필요가 없습니다. 그래도 필드를 이해해 두는 것은 필요합니다 — 「특정 노드가 연결되지 않는」 문제를 조사할 때 첫 단계가 바로 여기 파라미터를 대조하는 것입니다. 모든 프로토콜이 공유하는 기본 필드 네 가지: name(노드 이름, 정책 그룹과 규칙이 이걸로 참조하며 같은 설정 안에서 중복될 수 없음), type(프로토콜 종류), server와 port(서버 주소와 포트). udp: true는 해당 노드가 UDP 전달을 지원함을 선언하며, 음성 통화와 게임이 여기에 의존합니다.

Shadowsocks(ss)

필드가 가장 적은 프로토콜입니다: cipher는 암호화 방식을 지정하고(흔히 aes-128-gcm, chacha20-ietf-poly1305 같은 AEAD 계열), password는 사전 공유 키입니다. 양쪽의 cipher와 password는 완전히 일치해야 하며, 하나라도 잘못 입력하면 오류 메시지 없이 「즉시 연결 실패」로 나타납니다.

VMess

uuid를 신원 증명으로 사용하며, alterId는 최신 배포에서 0으로 고정하고, cipher는 보통 auto로 씁니다. VMess는 전송 계층 위장과 함께 쓰이는 경우가 많습니다: network: ws는 WebSocket 전송을 활성화하며, 함께 쓰는 ws-opts의 path와 headers.Host는 서버 쪽과 약속한 값과 반드시 일치해야 합니다. tls: true는 바깥에 TLS 계층을 한 겹 더 씌웁니다. 이런 노드는 파라미터가 많고 서로 얽혀 있어, 연결이 안 될 때는 필드를 하나씩 구독 원본과 대조해 보는 것이 우선입니다.

Trojan과 그보다 새로운 프로토콜

Trojan은 원래부터 TLS 위에서 동작하므로 핵심 필드는 password와 sni(TLS 핸드셰이크 시 선언하는 서버 이름)뿐입니다. skip-cert-verify는 인증서 검증을 건너뛸지 결정합니다 — 아래 경고를 참고하세요. VLESS, Hysteria2, TUIC 등 더 최신 프로토콜은 mihomo 커널의 지원이 필요하며, 클래식 Clash 커널은 이를 해석할 수 없습니다. 본 사이트 다운로드 페이지에 수록된 Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu는 모두 mihomo 기반이라 이런 프로토콜을 별도 설정 없이 바로 쓸 수 있습니다.

proxies:
  - name: "SS-홍콩-01"
    type: ss
    server: hk01.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

  - name: "VMess-일본-01"
    type: vmess
    server: jp01.example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    alterId: 0
    cipher: auto
    tls: true
    network: ws
    ws-opts:
      path: /your-path
      headers:
        Host: jp01.example.com

  - name: "Trojan-싱가포르-01"
    type: trojan
    server: sg01.example.com
    port: 443
    password: "your-password"
    sni: sg01.example.com
    udp: true

06proxy-groups: 정책 그룹 필드

정책 그룹은 노드와 규칙 사이의 중간 계층입니다: 규칙은 특정 노드를 직접 가리키지 않고 그룹을 가리키며, 그룹 안에서 현재 어떤 노드를 쓸지 결정합니다. 이 간접 구조 덕분에 「노드 교체」는 규칙을 손댈 필요가 없고, 「노드 장애」는 자동으로 전환될 수 있습니다. 각 그룹에는 반드시 name, type과 구성원 목록(proxies)이 있어야 하며, 구성원은 노드 이름, 다른 그룹 이름, 그리고 내장된 DIRECT와 REJECT일 수 있습니다.

다섯 가지 그룹 유형

select는 수동 선택으로, 패널에서 클릭한 노드를 그대로 쓰는 가장 흔한 「메인 스위치 그룹」입니다. url-test는 url로 지정한 테스트 주소로 주기적으로 요청을 보내 지연이 가장 낮은 구성원을 자동으로 선택합니다. interval은 테스트 간격(초)이고, tolerance는 전환 허용 오차입니다 — 신구 노드의 지연 차이가 이 밀리초 값보다 작으면 전환하지 않아, 비슷한 두 노드 사이에서 계속 오가는 것을 막아줍니다. lazy: true는 그룹이 규칙에 의해 실제로 사용되기 전까지는 테스트를 시작하지 않게 해 트래픽을 절약합니다. fallback은 구성원 목록 순서대로 첫 번째로 사용 가능한 노드를 선택하며, 우선 노드가 죽으면 자동으로 다음으로 넘어가고 복구되면 자동으로 다시 돌아옵니다. 「하나를 주로 쓰고 여러 개를 대기용으로」 두는 상황에 적합합니다. load-balance는 연결을 여러 구성원에 나눠 분산시키며, strategy는 consistent-hashing(같은 목적지 사이트는 항상 같은 노드로)이나 round-robin(순환 방식) 중 선택할 수 있습니다. relay는 구성원을 순서대로 이어 연결 체인을 만들며, 트래픽이 한 홉씩 차례로 지나가므로 지연과 장애율이 체인 길이에 따라 누적됩니다. 특수한 필요가 있을 때만 사용하세요.

그룹의 중첩

그룹은 다른 그룹을 참조할 수 있습니다. 흔한 계층 구조는: 지역별로 각각 url-test 그룹을 하나씩 만들고(홍콩 자동, 일본 자동...), 그런 다음 select 총괄 그룹을 만들어 이 지역 그룹들과 DIRECT를 모두 담는 방식입니다. 평소에는 총괄 그룹만 조작하고, 지역 내부의 최적 선택은 자동 속도 테스트에 맡깁니다. url-test 패널에 표시되는 밀리초 값은 「테스트 주소까지의 핸드셰이크 왕복 시간」을 나타내는 것이며 실제 대역폭과는 다른 개념이므로, 노드를 고를 때 지연만 보고 판단하지 마세요 — 원리 분석은 블로그 《Clash 노드 지연 테스트 원리》를 참고하세요.

proxy-groups:
  - name: "노드 선택"
    type: select
    proxies:
      - "자동 테스트"
      - "장애 조치"
      - "SS-홍콩-01"
      - "VMess-일본-01"
      - DIRECT

  - name: "자동 테스트"
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true
    proxies:
      - "SS-홍콩-01"
      - "VMess-일본-01"
      - "Trojan-싱가포르-01"

  - name: "장애 조치"
    type: fallback
    url: https://www.gstatic.com/generate_204
    interval: 300
    proxies:
      - "SS-홍콩-01"
      - "VMess-일본-01"

07rules: 규칙 문법과 매칭 순서

rules는 문자열 목록으로, 각 항목은 유형,매칭값,출구 형태입니다(일부 유형은 매칭값이 없거나 추가 파라미터가 붙습니다). 커널은 새 연결마다 위에서 아래로 하나씩 대조하며, 가장 먼저 일치한 규칙이 즉시 적용되고 그 뒤의 모든 규칙은 더 이상 참여하지 않습니다 — 순서가 곧 우선순위이며, 이것이 모든 분류 동작을 이해하는 핵심입니다. 목록 끝에는 반드시 MATCH 하나가 있어야 하며, 없으면 매칭되지 않은 트래픽의 동작이 정의되지 않습니다.

규칙 유형 빠른 참조

no-resolve: IP 규칙이 불필요한 해석을 유발하지 않게 하기

목적지가 아직 도메인일 때, IP 계열 규칙(IP-CIDR, GEOIP 등)은 기본적으로 먼저 도메인을 IP로 해석한 뒤 대조합니다 — 이 해석이 불필요할 수도 있고 매칭 속도도 늦춥니다. IP 규칙 끝에 no-resolve 파라미터를 붙이면 도메인 트래픽은 그 규칙을 건너뛰고, 원래부터 IP를 목적지로 하는 연결만 매칭에 참여합니다. 경험 법칙: 도메인 규칙 뒤에 배치되어 오직 IP 트래픽을 兜底(마지막 처리)하기 위한 IP 규칙에는 항상 no-resolve를 붙이세요. 유일한 예외는 GEOIP,CN,DIRECT가 도메인 트래픽에도 적용되길 원하는 경우입니다.

정렬 권장 순서와 흔한 실수

권장하는 배열 순서: 프로세스 규칙과 정확한 도메인 규칙을 맨 앞에, DOMAIN-SUFFIX 대량 규칙을 중간에, RULE-SET과 GEOSITE 큰 집합을 그 다음에, GEOIP,CN,DIRECT를 뒤에서 두 번째, MATCH를 맨 끝에 두는 것입니다. 자주 발생하는 실수 두 가지: 첫째, DOMAIN-KEYWORD의 매칭 범위가 매우 넓어서, DOMAIN-KEYWORD,go,노드 선택 같은 짧은 키워드는 관련 없는 도메인을 대량으로 잘못 걸러냅니다. 둘째, 넓은 규칙을 좁은 규칙 앞에 두면 뒤에 있는 세밀한 규칙이 영원히 실행되지 않습니다 — 조사할 때는 log-level: debug를 켜서 연결이 실제로 어느 규칙에 걸렸는지 보면 바로 위치를 찾을 수 있습니다. GEOIP와 GEOSITE는 로컬 데이터베이스 파일에 의존하며, 데이터베이스 버전이 매칭 결과에 직접 영향을 줍니다. 다운로드 소스 선택과 갱신 방법은 블로그 《Clash GeoIP·GeoSite 데이터베이스 업데이트 가이드》를 참고하세요.

rules:
  - PROCESS-NAME,Telegram.exe,노드 선택
  - DOMAIN,dl.google.com,노드 선택
  - DOMAIN-SUFFIX,github.com,노드 선택
  - DOMAIN-SUFFIX,githubusercontent.com,노드 선택
  - DOMAIN-KEYWORD,youtube,노드 선택
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,노드 선택

08proxy-providers와 rule-providers

Provider 메커니즘은 「노드 목록」과 「규칙 세트」를 메인 설정에서 분리해, 독립적으로 다운로드하고 갱신할 수 있는 외부 리소스로 만듭니다. 장점은 명확합니다: 구독 갱신은 노드 파일만 새로 고치고, 정성껏 관리해 온 정책 그룹과 규칙은 손대지 않습니다. 또한 규칙 세트는 커뮤니티가 관리하는 완성된 목록을 그대로 참조할 수 있어, 수천 줄의 도메인을 직접 관리할 필요가 없습니다.

proxy-providers: 외부 노드 소스

각 provider는 사용자 지정 키 이름을 가집니다. type: http는 url에서 주기적으로 가져온다는 의미이며(interval 단위는 초, 86400이면 하루에 한 번), 다운로드 결과는 path에 캐시됩니다. type: file은 로컬 파일을 직접 읽습니다. health-check 하위 블록은 이 노드들의 상태 검사를 설정하며, 파라미터 의미는 url-test 그룹과 동일합니다. 정책 그룹은 use 필드로 provider를 참조하며, proxies 목록과 병용할 수 있습니다 — 직접 작성한 상시 노드와 구독 노드를 같은 그룹에 섞어 넣는 것도 완전히 정상적인 사용법입니다. 구독 링크 자체는 Base64, Clash YAML 등 여러 형식이 있는데, provider가 요구하는 건 Clash YAML 형식의 주소입니다. 형식 식별과 변환 방법은 블로그 《Clash 구독 링크 형식 총정리》를 참고하세요.

rule-providers: 외부 규칙 세트

필드 구성은 proxy-providers와 대체로 같지만, 핵심적으로 behavior가 하나 더 있습니다: domain은 파일 내용이 전부 도메인이라는 의미(커널이 도메인 트리로 효율적으로 매칭), ipcidr은 전부 IP 대역, classical은 여러 규칙 유형을 섞어 쓸 수 있지만 매칭 비용이 가장 큽니다 — 앞의 두 가지로 처리할 수 있다면 classical은 쓰지 마세요. 규칙 파일의 형식은 format으로 선언합니다(yaml 또는 text). 정의를 마친 뒤 rules에서 RULE-SET,키이름,출구 형태로 참조하며, 이 항목의 정렬 원칙은 일반 규칙과 완전히 동일합니다.

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

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

rule-providers:
  cn-domains:
    type: http
    behavior: domain
    format: yaml
    url: "https://example.com/ruleset/cn.yaml"
    path: ./ruleset/cn.yaml
    interval: 86400

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

09오버라이드와 병합: 변경 사항을 잃지 않고 설정 수정하기

구독은 항공사(기항지 서비스 제공자)가 생성한 완전한 설정으로, 갱신될 때마다 로컬 profile 전체를 덮어씁니다 — 구독 파일에서 직접 dns를 바꾸거나 규칙을 추가해도 다음 갱신에서 전부 초기화됩니다. 오버라이드(Override/Merge) 메커니즘이 이 모순을 해결합니다: 수정 내용을 따로 저장해 두고, 클라이언트가 매번 구독을 로드할 때 자동으로 덧붙여, 구독을 마음대로 갱신해도 변경 사항은 계속 유효합니다.

클라이언트 내 오버라이드 진입점

본 사이트 다운로드 페이지에 수록된 주요 클라이언트(Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu)는 모두 구독 오버라이드 기능을 제공하며, 진입점 이름은 조금씩 다르지만 흔히 「오버라이드」, 「전역 확장 설정」, 「Merge」 등으로 불립니다. 대부분의 클라이언트는 두 가지 형태를 함께 제공합니다: 선언형 YAML 병합(조각을 작성해 키 이름 기준으로 덧붙이기)과 스크립트형 오버라이드(JavaScript 함수로 설정 객체를 직접 가공, 자유도가 더 높음)입니다. 일상적인 필요에는 YAML 병합으로 충분하고, 스크립트는 「조건에 따라 노드 이름을 일괄 변경」 같은 프로그래밍적인 상황에 남겨 두세요.

병합 규칙: 무엇이 덮어써지고 무엇이 추가되는가

병합을 이해하는 핵심은 값 유형을 구분하는 것입니다: 스칼라 키(mode, log-level 등)와 매핑 키(dns 블록 전체 등)는 오버라이드 조각에 나타나면 구독의 동일한 키 내용을 곧바로 대체합니다. 목록 키(rules, proxies 등)는 기본적으로도 전체가 대체됩니다 — 이것이 원하는 결과가 아닌 경우가 많아서, Clash Verge Rev 스타일의 병합에서는 prepend-와 append- 접두사를 제공합니다: prepend-rules는 구독 규칙 맨 앞에 몇 개의 규칙을 끼워 넣습니다(「먼저 매칭되면 먼저 적용된다」는 원리를 이용해 우선순위를 선점). append-rules는 MATCH 앞의 대열 끝에 추가합니다. 같은 방식으로 prepend-proxies, prepend-proxy-groups 등도 있습니다.

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

append-rules:
  - DOMAIN-KEYWORD,tracker,REJECT

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://doh.pub/dns-query

수정 후에는 먼저 검증하고, 그다음 적용을 논하라

직접 편집이든 오버라이드든, 저장 전에는 문법 검증을 한 번 거치는 것이 좋습니다. 그래픽 클라이언트의 내장 편집기는 보통 오류 줄을 즉시 빨간색으로 표시합니다. 커맨드라인 환경에서는 mihomo에 설정 검사 파라미터가 내장되어 있어, 실행하지 않고 검증만 할 수 있습니다:

mihomo -t -f config.yaml

검증을 통과하면 설정을 다시 불러오는 것만으로 적용되며, 클라이언트를 전체 재시작할 필요는 없습니다. 로드 후 동작이 예상과 다르다면 이 매뉴얼의 블록 순서대로 스스로 확인해 보세요: 인바운드 포트가 맞는지 → dns가 활성화되어 있는지 → 규칙 순서에서 넓은 규칙이 앞을 가로채고 있지 않은지 → 정책 그룹에서 현재 선택된 노드가 무엇인지. 그래도 해결되지 않는다면 FAQ의 「문제 해결」 분류를 먼저 확인하세요. 처음부터 다시 시작하는 전체 절차는 빠른 시작 튜토리얼을 되돌아보고, 아직 클라이언트를 설치하지 않았다면 바로 클라이언트 받기 페이지로 가서 Clash Plus를 우선 선택하세요.