YAML 한눈에 보기: 무엇이 먼저 읽히나

Clash 계열 코어(mihomo 포함)는 대부분 단일 YAML 파일로 동작합니다. 화면에서 구독만 넣어도 내부적으로는 이 파일이 생성·갱신되며, 고급 사용자는 직접 편집해 세밀한 분기와 장애 대응을 넣습니다. 핵심은 세 블록의 관계입니다. proxies와 proxy-providers가 “후보 노드 풀”을 만들고, proxy-groups가 그 풀을 조합해 “사용자가 고르거나 자동으로 고르는 전략 그룹”을 만듭니다. 마지막으로 rules가 도메인·IP·프로세스 등 조건에 따라 트래픽을 특정 그룹이나 직접 연결·차단으로 보냅니다.

규칙은 위에서 아래로만 평가됩니다. 첫 번째로 맞는 한 줄이 최종 결정이므로, “넓은 조건”을 위에 두고 “좁은 예외”를 아래에 두면 의도와 반대로 동작합니다. 예를 들어 전체를 프록시로 보내는 규칙을 맨 위에 두면, 그 아래에 적어 둔 국내 사이트 직접 연결 규칙은 영원히 실행되지 않습니다. 운영할 때는 항상 “가장 구체적인 규칙이 위에 오는가?”를 점검하는 습관이 필요합니다.

최상위 필드: 포트·모드·로그

파일 맨 위에는 보통 port(HTTP 프록시), socks-port, 혹은 둘을 합친 mixed-port, 그리고 allow-lan, mode, log-level 등이 옵니다. mode: rule일 때만 위에서 설명한 rules 분기가 의미가 있습니다. global이면 사용자가 고른 단일 노드로 모두 나가고, direct는 프록시를 쓰지 않습니다. 초보자가 규칙을 아무리 잘 써도 모드가 global이면 기대와 다른 결과가 나오므로, GUI에서 모드 표시를 항상 확인하세요.

external-controller는 REST API용 주소입니다. 대시보드나 외부 스크립트가 프록시 그룹을 바꿀 때 쓰며, 로컬에서만 열어두고 불필요하면 끄는 편이 안전합니다. 블로그의 다른 글에서 다루는 클라이언트별 화면은 결국 이 YAML을 덜 어렵게 만드는 껍데기라고 보면 됩니다.

proxies와 proxy-providers

proxies 아래에는 각 노드의 타입(ss, vmess, trojan 등), 서버, 포트, 암호, TLS 옵션이 나열됩니다. 이름(name)은 이후 proxy-groups와 rules에서 참조하는 식별자이므로, 공백과 대소문자를 일관되게 쓰는 것이 좋습니다.

proxy-providers는 원격 구독 URL이나 로컬 파일에서 노드 목록을 불러옵니다. 대량 노드를 YAML에 직접 붙여 넣지 않아도 되고, 구독 갱신 시 자동으로 후보가 바뀝니다. health-check를 켜 두면 지연 측정이 주기적으로 돌아가 url-test 그룹과 궁합이 좋습니다. 구독 포맷이 표준이 아니면 파싱 오류가 나므로, 그때는 변환 도구로 Clash 호환 YAML을 만든 뒤 다시 넣는 흐름이 일반적입니다.

proxy-groups: 전략 그룹의 종류와 쓰임

proxy-groups는 “이름 붙은 의사결정 단위”입니다. 대표 유형은 다음과 같습니다.

  • select: 사용자가 UI에서 하나를 고릅니다. 지역별·용도별 프리셋을 나눌 때 많이 씁니다.
  • url-test: 지정한 URL에 대해 지연을 재고 가장 빠른 노드를 고릅니다. interval, tolerance, lazy로 측정 빈도와 전환 민감도를 조절합니다.
  • fallback: 순서대로 헬스 체크하며 쓸 수 있는 첫 노드를 씁니다. 한국·일본 순으로 백업을 두는 패턴에 맞습니다.
  • relay: 나열된 프록시를 순차적으로 거쳐갑니다. 다중 홉이 필요할 때만 쓰며, 지연이 누적된다는 점을 감안해야 합니다.
  • load-balance: (지원하는 빌드에서) 연결을 분산합니다. 정책·코어 버전에 따라 동작이 다를 수 있어 문서 확인이 필요합니다.

그룹은 다른 그룹을 멤버로 둘 수 있어, “메인 선택 → 지역별 url-test → 실제 노드”처럼 계층을 쌓을 수 있습니다. 다만 순환 참조만 피하면 됩니다. 규칙에서는 최종적으로 proxy-groups의 이름을 타깃으로 쓰므로, 클라이언트 프록시 탭에 보이는 이름과 YAML의 name이 같아야 혼란이 없습니다.

팁

url-test의 url은 실제로 자주 쓰는 사이트와 가까운 엔드포인트를 고르세요. 글로벌 CDN 앞단만 재면 모든 노드가 비슷하게 나와 선택이 의미 없어질 수 있습니다.

rules: 분기 우선순위와 RULE-SET

각 규칙 줄은 대략 “조건, 대상, 동작” 형태입니다. 도메인 접미사, 키워드, 전체 도메인, IP 대역, GEOIP, 프로세스 이름 등이 조건으로 올 수 있고, 동작은 DIRECT, REJECT, 또는 앞서 만든 proxy-groups 이름입니다. GEOIP는 국가 코드와 함께 쓰여 “이 국가 IP 대역은 직접” 같은 정책을 간단히 넣을 수 있습니다. 다만 데이터베이스 갱신 시점에 따라 오판이 생길 수 있어, 중요한 도메인은 도메인 규칙으로 보완하는 편이 안전합니다.

mihomo 등 최신 코어에서는 RULE-SET으로 외부 규칙 묶음을 가져옵니다. 광고 차단·스트리밍·클라우드 IP 목록을 커뮤니티 rule-set으로 나눠 쓰면 YAML 길이를 줄이고 유지보수를 쉽게 할 수 있습니다. rule-providers에 URL·경로·동작 방식(domain, ipcidr, classical)을 선언한 뒤, rules에서 RULE-SET,provider_name,Policy 형태로 참조합니다.

맨 아래에는 반드시 MATCH 같은 포괄 규칙을 두어 “위에서 처리되지 않은 나머지”를 수집합니다. 이 줄이 없거나 의도치 않은 그룹을 가리키면 예상 밖의 경로로 트래픽이 나갑니다.

DNS와 Fake-IP: 왜 쓰고, 무엇을 조심하나

프록시를 쓸 때 DNS가 먼저 새는 것이 흔한 “DNS 유출”입니다. 애플리케이션이 시스템이나 ISP DNS로 도메인을 물어보면, 접속 대상이 노출되거나 지역 판별에 쓰일 수 있습니다. Clash의 dns 섹션에서 enhanced-mode: fake-ip를 켜면, 로컬로 들어온 DNS 질의에 대해 코어가 임시 가짜 IP(보통 198.18.0.0/16 대역)를 빠르게 돌려주고, 실제로 연결이 일어날 때 도메인과의 매핑을 사용해 프록시로 넘깁니다. 이렇게 하면 “로컬에서 미리 진짜 IP를 알아내지 않는” 흐름을 만들 수 있습니다.

redir-host 모드는 전통적인 방식에 가깝고, 호환성은 좋을 수 있지만 Fake-IP만큼 트래픽·DNS를 깔끔히 분리하지 못하는 경우가 있습니다. 최근 클라이언트·코어 조합에서는 Fake-IP가 더 자주 권장되지만, LAN·캐스트·특정 게임 클라이언트처럼 가짜 IP에 잘못 반응하는 프로그램이 있으면 fake-ip-filter에 도메인이나 IP 대역을 넣어 예외 처리해야 합니다.

fake-ip-filter와 nameserver/fallback

fake-ip-filter에는 “가짜 IP를 주면 안 되는 이름”을 적습니다. 예를 들어 *.lan, 라우터 관리 주소, 스트리밍·원격 데스크톱 등 실제 IP가 필요한 서비스 도메인을 넣습니다. 여기를 소홀히 하면 특정 사이트만 접속이 안 되거나, 분할 터널 의도와 다르게 동작합니다.

nameserver는 일반 질의에 쓰고, fallback은 차단·오염 의심 시 쓰는 보조 서버로 두는 패턴이 많습니다. fallback-filter에 GEOIP 조건을 넣으면 “특정 국가 결과가 나오면 fallback으로 재질의” 같은 정책을 구성할 수 있습니다. DoH·DoT URL은 YAML에 그대로 넣을 수 있어, 평문 DNS보다 중간자 공격에 강합니다.

dns:
  enable: true
  listen: 0.0.0.0:53
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - '+.msftconnecttest.com'
  nameserver:
    - https://dns.google/dns-query
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

위 예시는 개념 설명용입니다. 실제로는 사용 중인 구독·환경에 맞게 서버를 바꾸고, 국내 직결 도메인은 rules에서 DIRECT로 보내는지 함께 확인해야 합니다.

주의

TUN 모드를 켜면 DNS가 코어로 모이기 쉬워 Fake-IP와 궁합이 좋지만, OS·방화벽 설정에 따라 여전히 일부 앱이 시스템 DNS를 쓸 수 있습니다. “완전 무유출”을 목표로 할 때는 클라이언트 로그와 캡처 도구로 한 번 검증하는 것이 좋습니다.

실전 체크리스트

설정을 바꾼 뒤에는 다음을 순서대로 점검해 보세요. 대부분의 이상 증상은 이 목록 안에서 원인이 좁혀집니다.

  1. 모드가 rule인가, 규칙 파일이 현재 프로필에 로드됐는가.
  2. rules 상단에 과하게 넓은 규칙이 있어 아래 규칙이 무시되지 않는가.
  3. proxy-groups 이름이 규칙·멤버 참조와 정확히 일치하는가(오타·공백).
  4. DNS에서 Fake-IP 사용 시 fake-ip-filter에 예외가 필요한 도메인이 빠지지 않았는가.
  5. TUN/시스템 프록시 중 무엇을 쓰는지에 따라, 분할 터널(국내 직결) 규칙이 기대대로 적용되는가.

한 번에 모든 옵션을 바꾸기보다, DNS만 바꾸고 규칙은 유지하거나, 반대로 규칙만 정리하고 DNS는 나중에 손대는 식으로 단계를 나누면 되돌리기도 쉽습니다.

정리: YAML은 “지도”, 클라이언트는 “운전대”

규칙 분기·전략 그룹·Fake-IP는 서로 독립이 아니라 한 흐름으로 맞물립니다. DNS가 가짜 IP를 돌려주고, 규칙이 그 연결을 올바른 그룹으로 붙이고, 그룹이 노드나 다른 그룹을 선택합니다. 한 군데만 어긋나도 “분명 규칙을 넣었는데 왜 직접 나가지?” 같은 증상이 나오므로, 위에서 아래로의 규칙 순서와 DNS 모드를 함께 보는 습관이 중요합니다.

직접 YAML을 만지지 않아도, 어떤 값이 화면의 스위치와 연결되는지 알면 문제가 났을 때 로그와 설명 문서를 훨씬 빨리 이해할 수 있습니다. 규칙 세트를 크게 바꾸기 전에는 항상 백업을 남기고, 가능하면 테스트 기기 한 대에서만 먼저 검증하세요.

GUI로 구독만 쓰는 경우에도, 위 개념을 알아 두면 클라이언트 다운로드 페이지에서 안내하는 최신 빌드와 잘 맞는 설정을 고르는 데 도움이 됩니다. 수동 편집과 시각적 관리를 모두 지원하는 앱을 쓰면, YAML의 유연함과 사용 편의를 동시에 누릴 수 있습니다. → Clash를 무료로 내려받고, 규칙·DNS·전략 그룹을 한 번에 정리해 보세요.