Clash 고급 설정 매뉴얼

01정책 그룹 종류와 실전

정책 그룹(proxy-groups)은 전체 설정의 라우팅 중심축입니다. 규칙 매칭의 결과는 보통 특정 노드를 직접 가리키지 않고 하나의 정책 그룹을 가리키며, 그룹은 자신의 타입에 따라 실제 출구를 결정합니다. 각 그룹 타입의 동작 방식을 이해하는 것이 장기적으로 유지보수 가능한 설정을 만드는 첫걸음입니다. Clash 코어가 지원하는 대표적인 그룹 타입은 네 가지입니다: select, url-test, fallback, load-balance. 각각 서로 다른 라우팅 문제를 해결합니다.

select: 수동 선택 그룹

select는 가장 기본적인 그룹 타입으로, 출구를 사용자가 클라이언트 화면에서 직접 지정합니다. 속도 측정이나 헬스 체크를 전혀 하지 않으며, 선택한 노드가 구독에서 사라지거나 수동으로 변경하기 전까지 계속 그 노드를 사용합니다. 이 "지시에만 따르는" 특성 덕분에 설정의 최상위 계층, 즉 총괄 스위치로 두기에 적합합니다: 여러 기능 그룹과 지역 그룹, 그리고 DIRECT를 함께 "노드 선택"이라는 이름의 select 그룹에 모아두고, 규칙은 모두 이 그룹을 가리키도록 하면 일상적인 전환은 화면에서 한 번 클릭하는 것으로 끝납니다.

select 그룹의 필수 필드는 name, type, proxies 세 가지뿐입니다. proxies 목록에는 구체적인 노드 이름, 다른 정책 그룹 이름, 그리고 두 가지 내장 정책을 혼합해서 넣을 수 있습니다: DIRECT는 프록시를 거치지 않는 직접 연결을, REJECT는 연결을 즉시 거부함을 의미합니다. 그룹 이름을 참조할 때는 정의된 이름과 공백, 대소문자까지 완전히 일치해야 하며, 틀리면 시작 시 "그룹이 존재하지 않음" 오류가 발생합니다.

url-test와 fallback: 자동 라우팅

url-test 그룹은 주기적으로 그룹 내 모든 노드에 가벼운 HTTP 요청을 보내 지연이 가장 낮은 노드를 현재 출구로 선택합니다. 이해해야 할 핵심 파라미터는 세 가지입니다: url은 속도 측정 대상 주소로, 204 상태 코드를 반환하고 응답 본문이 없는 주소를 사용하는 것이 관례이며 측정 자체가 소모하는 트래픽을 최소화합니다; interval은 측정 주기이며 단위는 초, 일반적으로 300을 사용하는데 너무 짧게 설정하면 백그라운드 요청이 빈번해집니다; tolerance는 전환 허용 오차로 단위는 밀리초입니다—새로운 최적 노드가 현재 노드보다 이 값만큼 더 빠를 때만 실제로 전환이 일어납니다. tolerance를 설정하지 않으면 지연이 비슷한 두 노드가 측정 오차 때문에 번갈아 전환되면서 출구 IP가 자주 바뀔 수 있습니다.

fallback 그룹은 proxies 목록에 작성된 순서대로 가용성을 검사하며, 항상 목록에서 검사를 통과한 첫 번째 노드를 사용합니다. 해당 노드가 장애를 일으키면 다음 노드로 넘어가고, 복구되면 자동으로 다시 전환됩니다. url-test와의 본질적 차이는 관심사가 다르다는 점입니다: url-test는 "누가 지연이 가장 낮은가"에 관심을 두고, fallback은 "누가 맨 앞에 있으면서 살아있는가"에 관심을 둡니다. 따라서 fallback은 "주력 라인 + 백업 라인" 구성에 적합합니다—가장 안정적이고 신뢰하는 노드를 첫 번째에 두고, 백업 라인을 순서대로 그 뒤에 배치하면 평소엔 항상 주력 라인을 쓰고 주력이 장애가 나면 무감지 전환됩니다.

load-balance: 로드 밸런싱

load-balance 그룹은 연결을 그룹 내 여러 노드에 분산시킵니다. strategy 필드가 consistent-hashing일 때는 목적지 도메인을 기준으로 일관성 해싱을 수행하여 같은 웹사이트로의 요청이 항상 같은 노드로 고정되므로, 출구 IP가 반복적으로 바뀌어 로그인 상태가 끊기는 문제를 피할 수 있습니다. round-robin일 때는 연결마다 출구를 순환시켜 트래픽이 더 균일하게 분산되지만, 세션에 민감한 사이트에는 불리합니다. 실전에서는 대용량 다운로드나 대량 크롤링처럼 출구 IP에 민감하지 않은 용도에 로드 밸런싱이 더 적합하며, 안정적인 로그인 상태가 필요한 서비스에는 권장하지 않습니다.

그룹 중첩과 구조 설계

실전에서는 "기능 그룹이 지역 그룹을 참조"하는 2계층 구조를 권장합니다: 먼저 지역별로 여러 url-test 그룹(예: "홍콩 자동", "일본 자동")을 만들고, 다음으로 용도별로 여러 select 기능 그룹(예: "스트리밍", "AI 서비스", "백업 선택")을 만들되, 기능 그룹의 후보 항목에는 구체적인 노드 이름이 아니라 지역 그룹의 이름을 적습니다. 이렇게 하면 구독 노드가 추가·삭제·이름 변경되어도 지역 그룹 계층에만 영향을 미치고 규칙과 기능 그룹은 전혀 손댈 필요가 없습니다. 구독을 바꿔도 지역 그룹만 다시 만들면 됩니다. 유일하게 주의할 점은 그룹 간 순환 참조를 만들지 않는 것입니다—A 그룹이 B 그룹을 참조하고 B 그룹이 다시 A 그룹을 참조하면 코어가 시작 시 오류를 내고 로드를 거부합니다.

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

  - name: 香港自动
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 60
    proxies: [HK-01, HK-02, HK-03]

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

  - name: 批量下载
    type: load-balance
    strategy: consistent-hashing
    proxies: [HK-01, HK-02, JP-01]

02규칙 세트 구독화 관리

수천 줄의 분기 규칙을 메인 설정 파일에 직접 적어두면 장기적으로 두 가지 문제가 생깁니다. 첫째, 메인 설정이 비대해져 유지보수가 어려워지고, 규칙 하나를 조정하려 해도 수천 줄 사이에서 찾아야 합니다. 둘째, 규칙 데이터(광고 도메인, 지역 IP 대역)는 계속 갱신되는데 설정에 고정해 두면 작성한 그날에 영원히 멈춰버립니다. rule-providers(규칙 프로바이더)는 규칙을 독립된 파일로 분리해 주기적으로 자동 갱신하고, 메인 설정에는 한 줄의 참조만 남기는 방식으로, 규칙 관리의 표준 방법입니다.

rule-providers의 필드 의미

각 프로바이더는 이름이 붙은 항목으로, 핵심 필드를 하나씩 설명합니다. type이 http이면 원격 주소에서 주기적으로 가져오고, file이면 로컬 파일을 읽어 자동 갱신하지 않습니다; url은 원격 규칙 파일 주소입니다; path는 로컬 캐시 경로를 지정하며, 생략하면 코어가 url의 해시값으로 캐시 파일명을 자동으로 정합니다; interval은 갱신 주기로 단위는 초이며, 86400은 하루에 해당합니다. 규칙 데이터의 갱신 빈도는 높지 않으므로 더 짧게 설정할 필요는 없습니다.

behavior는 파일 내용의 해석 방식을 결정하며, 가장 잘못 설정하기 쉬운 필드입니다: domain은 파일이 순수한 도메인 목록으로 한 줄에 하나씩(+. 와일드카드 접두사 지원) 적혀 있음을 의미합니다; ipcidr은 파일이 IP 대역 목록임을 의미합니다; classical은 파일이 줄 단위로 완전한 규칙을 담고 있어 DOMAIN-SUFFIX, IP-CIDR, PROCESS-NAME 등 여러 타입을 섞어 쓸 수 있음을 의미합니다. behavior와 실제 파일 내용이 맞지 않으면 가볍게는 규칙이 전부 매칭되지 않고, 심하면 로드 오류가 발생합니다. format은 파일 형식을 선언합니다: yaml과 text는 범용성이 가장 좋고; mrs는 mihomo 코어의 바이너리 형식으로 용량이 작고 로딩이 빠르지만 domain과 ipcidr 두 behavior만 지원합니다.

rules에서 참조하기

프로바이더를 정의한 후 rules 항목에서 RULE-SET,프로바이더명,정책그룹명 형식으로 참조합니다. ipcidr 계열 규칙 세트는 끝에 no-resolve 파라미터를 추가하는 것이 좋습니다: IP 계열 규칙은 목적지 IP를 얻어야 매칭할 수 있는데, 연결 목적지가 도메인이면 코어가 먼저 DNS 해석을 한 번 수행한 뒤 비교합니다—no-resolve는 이 해석 과정을 건너뛰라는 지시로, 도메인 기반 연결은 곧바로 비매칭으로 처리되어 다음 규칙으로 넘어갑니다. 이렇게 하면 불필요한 해석 부담을 피하는 동시에 fake-ip 모드에서 불필요한 실제 해석 요청이 발생하는 것도 방지합니다.

rule-providers:
  ad-domains:
    type: http
    behavior: domain
    format: yaml
    url: https://example.com/rulesets/ad-domains.yaml
    path: ./ruleset/ad-domains.yaml
    interval: 86400
  cn-ip:
    type: http
    behavior: ipcidr
    format: mrs
    url: https://example.com/rulesets/cn-ip.mrs
    path: ./ruleset/cn-ip.mrs
    interval: 86400

rules:
  - RULE-SET,ad-domains,REJECT
  - RULE-SET,cn-ip,DIRECT,no-resolve
  - MATCH,节点选择

매칭 순서와 갱신 문제 진단

규칙은 위에서 아래로 하나씩 매칭되며, 첫 번째로 일치한 규칙에서 즉시 멈추고 뒤의 규칙은 더 이상 검사되지 않습니다—그래서 규칙 세트의 배치 순서가 곧 우선순위입니다: 거부 계열(광고)을 맨 앞에, 정확한 도메인 규칙을 앞쪽에, 범위가 넓은 IP 규칙을 뒤쪽에 두고, 마지막에는 반드시 MATCH 백업 규칙이 있어야 합니다. 그렇지 않으면 매칭되지 않은 트래픽의 동작을 예측할 수 없습니다. 특정 사이트가 실제로 어떤 규칙에 매칭됐는지 확인하려면 가장 직접적인 방법은 7장에서 소개하는 컨트롤 패널을 열어 연결 페이지에서 해당 연결의 규칙 열을 확인하는 것입니다.

규칙 세트 갱신 실패는 흔한 문제입니다. 진단 순서: 규칙 파일을 가져오는 과정 자체도 네트워크를 거치므로, 가져오는 주소가 현재 네트워크 환경에서 직접 접속할 수 없으면 콜드 스타트(사용 가능한 프록시가 아직 없는 상태) 시 가져오기가 실패합니다—해결책은 직접 접속 가능한 미러 주소를 선택하거나, 첫 시작 전에 캐시 파일이 이미 존재하도록 준비하는 것입니다; 다음으로 코어 로그에서 provider 관련 오류를 확인하는데, 흔한 원인은 behavior와 파일 내용 불일치, format 선언 오류입니다; 마지막으로 path가 가리키는 캐시 파일을 수동으로 삭제하고 코어를 재시작해 강제로 다시 다운로드받게 할 수 있습니다.

03DNS 설정 최적화

Clash의 내장 DNS는 있어도 되고 없어도 되는 부속 기능이 아닙니다: 도메인 규칙의 매칭, fake-ip 매핑 생성, DNS 요청이 로컬 오염을 피하는지 여부는 모두 이 설정 항목에 좌우됩니다. 기본 설정은 대부분의 상황에서 사용 가능하지만, "직결 도메인은 빠르게 해석되고, 프록시 도메인은 정확한 결과를 얻으며, 전체 과정에서 유출이 없는" 상태를 만들려면 각 필드의 역할을 이해해야 합니다.

기본 필드

enable: true는 내장 DNS를 켭니다; listen은 리스닝 주소와 포트를 지정하며, TUN 모드의 DNS 하이재킹이 시스템 쿼리를 이곳으로 전달합니다; enhanced-mode는 fake-ip와 redir-host 중 하나를 선택하며, 둘의 장단점은 다음 장에서 다룹니다. default-nameserver는 자주 간과되는 필드입니다: 뒤에 나오는 nameserver 목록에 DoH 주소(https://…/dns-query 형태)를 적는 경우, 이 주소들 자체도 도메인이라서 먼저 해석되어야 합니다—default-nameserver가 바로 이 역할을 담당하므로 순수 IP 주소만 적어야 하며, 도메인을 적으면 해석의 무한 루프가 만들어집니다.

nameserver는 메인 해석 그룹으로, 대부분 도메인의 해석을 담당합니다. 현재 네트워크 환경에서 안정적으로 직결 가능한 암호화 DNS 주소를 적는 것이 좋으며, 이는 직결 트래픽의 해석 속도와 정확성을 보장합니다. 평문 53번 포트의 전통적인 DNS도 사용할 수는 있지만, 일부 네트워크에서는 평문 쿼리가 중간 장치에 의해 변조될 수 있으므로 DoH나 DoT를 우선 선택하는 것이 좋습니다.

fallback과 fallback-filter

fallback 그룹은 "메인 해석 그룹의 결과가 오염되었을 가능성이 있는" 도메인을 대상으로 합니다. nameserver와 fallback이 동시에 존재하면 코어는 두 그룹에 동시에 쿼리를 보내고, fallback-filter가 어느 쪽 결과를 채택할지 결정합니다: geoip: true이고 geoip-code: CN이면—nameserver가 반환한 IP가 중국 본토에 속하면 이 도메인은 중국 본토 도메인으로 신뢰할 수 있다고 판단하여 nameserver의 응답을 채택하고, 그렇지 않으면 이 도메인은 해외 해석을 거쳐야 한다고 판단해 fallback의 응답을 채택합니다. ipcidr 하위 필드는 이미 알려진 오염 결과 대역(예: 예약 대역 240.0.0.0/4)을 나열하며, nameserver가 반환한 IP가 이 대역에 속하면 즉시 오염으로 판정해 fallback 결과로 바꿉니다.

이 메커니즘의 효과는 다음과 같습니다: 국내(중국 본토) 도메인은 가까운 국내 DNS가 해석하여 CDN 최적 IP를 얻고, 해외 도메인의 해석 결과는 fallback 그룹의 암호화 채널을 통해 얻어져 로컬 오염의 영향을 받지 않습니다. fallback에 넣는 암호화 DNS 주소는 프록시가 사용 가능할 때 정상적으로 접속되는 주소여야 한다는 점에 주의해야 합니다. 그렇지 않으면 동시 쿼리 중 fallback 쪽이 장시간 타임아웃되어 전체 해석 속도를 늦춥니다.

nameserver-policy: 지정 해석

nameserver-policy는 특정 도메인을 특정 상위 DNS에 배정할 수 있게 해주며, nameserver와 fallback의 범용 로직보다 우선순위가 높습니다. 대표적인 사용 사례는 두 가지입니다: 회사 내부망 도메인은 반드시 내부망 DNS 서버에 맡겨야 해석 결과가 나오는 경우; CDN 스케줄링에 민감한 일부 국내 대형 사이트를 특정 국내 DoH에 고정해서 동시 쿼리 메커니즘이 만드는 불확실성을 피하는 경우입니다. 키는 +. 와일드카드 접두사를 지원하며 자기 자신과 모든 하위 도메인을 매칭합니다.

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://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
  nameserver-policy:
    "+.corp.example.com": 10.0.0.53

유출 검증

설정을 마쳤다면 실제로 한 번 검증해봐야 합니다: 프록시에 연결한 뒤 DNS 유출 탐지 사이트에 접속해 탐지된 해석 서버의 소속 지역을 확인합니다—해외 도메인의 해석 요청이 여전히 로컬 통신사 DNS에서 발생한 것으로 표시된다면 유출이 있다는 뜻이며, 흔한 원인은 시스템에 수동으로 지정한 DNS가 남아있거나 브라우저 자체의 DoH 설정이 Clash를 우회한 경우입니다. 로그 레벨을 debug로 올려서 각 도메인이 실제로 어느 상위 DNS를 거쳤는지 직접 관찰할 수도 있습니다. 전체 검증 절차와 두 DNS 모드의 장단점 분석은 블로그 글 《Clash DNS 설정과 유출 방지 실전 가이드》를 참고하세요.

04TUN 모드와 Fake-IP

두 가지 인수 방식의 차이

시스템 프록시의 본질은 운영체제에 HTTP/SOCKS 포트를 하나 선언하는 것이며, 선언 후 실제로 사용할지는 애플리케이션 자체에 달려 있습니다: 브라우저와 대부분의 그래픽 애플리케이션은 이를 따르지만, 많은 커맨드라인 도구, 일부 게임 클라이언트와 시스템 서비스는 이 설정을 전혀 읽지 않으며 이들의 트래픽은 그대로 직결됩니다. TUN 모드는 다른 방식을 취합니다: 코어가 가상 네트워크 카드를 만들고 시스템 기본 라우팅을 그쪽으로 지정하여, 모든 애플리케이션의 트래픽이 네트워크 계층에서 가로채지며 어떤 애플리케이션의 협조도 필요하지 않습니다. 한마디로: 시스템 프록시는 "초대제"이고 TUN은 "전면 인수"입니다. 두 방식의 완전한 원리 비교는 《Clash TUN 모드와 시스템 프록시의 동작 원리 비교》를 참고하세요.

tun 항목 필드 설명

stack은 프로토콜 스택 구현을 선택합니다: system은 운영체제 프로토콜 스택을 재사용해 성능이 가장 좋고; gvisor는 유저 공간 프로토콜 스택으로 호환성이 좋고 시스템 침투가 적으며; mixed는 둘을 혼합해 TCP는 system, UDP는 gvisor를 사용하는 방식으로, 대부분의 상황에서 합리적인 기본값입니다. auto-route는 라우팅 테이블을 자동으로 작성해 기본 트래픽을 가상 네트워크 카드로 유도합니다; auto-detect-interface는 실제 물리적 출구 네트워크 카드를 자동으로 식별합니다—이 항목이 매우 중요한데, 프록시 노드 자체의 트래픽이 물리 네트워크 카드에서 나가고 가상 네트워크 카드로 다시 들어가지 않도록 보장합니다. 이 설정이 없거나 잘못 식별되면 트래픽 루프가 발생해 TUN을 켜자마자 인터넷이 끊기는 증상으로 나타납니다. strict-route는 라우팅 규칙을 조여 일부 트래픽이 가상 네트워크 카드를 우회하는 것을 방지합니다. dns-hijack은 임의의 주소로 향하는 53번 포트 쿼리를 가로채 내장 DNS로 넘기며, 보통 any:53으로 작성해 시스템과 애플리케이션의 DNS 쿼리가 모두 3장의 해석 체계에 포함되도록 합니다.

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

Fake-IP 원리와 fake-ip-filter

fake-ip 모드에서는 내장 DNS가 쿼리를 받았을 때 실제 해석을 수행하지 않고, fake-ip-range(기본값 198.18.0.1/16 예약 대역)에서 가짜 IP를 하나 배정해 애플리케이션에 반환하며, 내부적으로 "가짜 IP ↔ 도메인" 매핑을 기록합니다. 애플리케이션이 가짜 IP로 연결을 시도하면, 연결이 코어에 도달했을 때 매핑을 역조회해 즉시 원래 도메인을 얻고 도메인 규칙으로 바로 매칭합니다—실제 해석의 왕복 과정이 생략되어 연결 수립이 더 빠르고 도메인 규칙의 매칭도 더 정확합니다. 실제 해석은 직결이 확정되었거나 프록시 서버 원격 측에서 처리될 때만 발생합니다.

부작용은, 일부 시나리오는 실제 IP를 얻어야 정상 동작한다는 점입니다. 로컬 네트워크 장치 검색, NTP 시간 동기화, 일부 게임 런처, Windows의 네트워크 연결성 탐지는 198.18 대역의 가짜 주소를 받으면 바로 이상 동작합니다. fake-ip-filter는 이를 위한 화이트리스트입니다: 여기에 나열된 도메인은 실제 해석으로 돌아가며 fake-ip 매핑에 참여하지 않습니다.

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

플랫폼별 권한 차이

05도메인 스니핑

스니핑이 필요한 이유

코어에 도달할 때 도메인 정보를 얻을 수 없는 트래픽은 두 종류가 있습니다: 하나는 애플리케이션이 자체적으로 DNS 해석을 마치고 IP로 직접 연결을 시도하는 경우(일부 브라우저가 자체 DoH를 켜거나 여러 모바일 앱이 내장 해석 로직을 갖는 경우가 여기에 속함)이고, 다른 하나는 redir-host 경로에서 도메인 정보가 중간에 사라지는 포워딩 시나리오입니다. 도메인이 없으면 도메인 기반 규칙이 모두 무용지물이 되어 해당 연결은 IP 규칙이나 MATCH 백업에만 의존하게 되고 분기 정밀도가 눈에 띄게 떨어집니다. 도메인 스니핑(sniffer)은 트래픽 자체에서 도메인을 "읽어" 복원합니다: TLS 핸드셰이크의 SNI 필드, HTTP 요청의 Host 헤더, QUIC 핸드셰이크 정보에는 모두 목적지 도메인이 담겨 있으며, 코어는 전달 전에 이 프로토콜 헤더들을 해석해 도메인을 복원한 뒤 규칙 매칭에 참여시킵니다.

설정 필드

sniffer.enable은 스니핑을 켭니다; sniff 아래에서 프로토콜별로 개별 설정합니다: ports는 스니핑 대상 포트를 한정하며(TLS는 흔히 443, HTTP는 흔히 80, 포트 구간 표기도 지원), override-destination이 true이면 스니핑한 도메인으로 연결 목적지를 덮어써 규칙 매칭에 사용합니다. force-domain은 강제로 스니핑할 도메인을 나열하며, 연결에 이미 도메인이 있어도 다시 스니핑해서 재확인합니다; skip-domain은 스니핑을 건너뛸 도메인을 나열합니다—가장 흔한 용도는 모바일 푸시 서비스의 장기 연결을 제외하는 것으로, 스니핑이 개입하면 이런 연결의 유지(keep-alive)에 영향을 줄 수 있어 푸시 지연이 발생할 수 있습니다.

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

두 가지 DNS 모드와의 연계

fake-ip 모드에서는 대부분의 도메인이 이미 매핑 역조회로 확보되므로 스니핑은 보조 수단으로, "애플리케이션이 IP로 직결"하는 누락 트래픽만 특별히 보완합니다; redir-host 모드에서는 도메인이 사라질 확률이 훨씬 높아 스니핑이 거의 필수 설정이며, 설정하지 않으면 규칙 매칭률이 크게 떨어집니다. 스니핑은 새 연결마다 프로토콜 헤더 해석 부담을 한 번 더하지만 그 정도는 매우 작아 일반적인 기기에서는 체감되지 않습니다; 극단적인 성능 요구가 있다면 ports 범위를 좁혀 표준 포트만 스니핑하도록 할 수 있습니다. 스니핑이 제대로 동작하는지 판단할 때도 7장의 패널 연결 페이지를 활용하면 됩니다: 연결 목적지가 순수 IP가 아니라 도메인으로 표시되면 스니핑이 복원에 성공했다는 뜻입니다.

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

오버라이드가 필요한 이유

구독 갱신의 본질은 원격의 최신 설정으로 로컬 파일 전체를 덮어쓰는 것입니다—설정에 직접 추가한 규칙, 조정해둔 DNS, 켜둔 TUN은 다음 갱신에서 모두 사라져버립니다. 오버라이드 메커니즘은 "개인 커스터마이징"과 "구독 콘텐츠"를 분리합니다: 구독은 노드 제공에만 집중하고, 규칙, DNS, TUN 같은 로컬 정책은 오버라이드 계층에 작성해두면 구독을 갱신해도 오버라이드가 자동으로 다시 적용되어 두 쪽이 서로 영향을 주지 않습니다. 다운로드 페이지에 수록된 주요 그래픽 클라이언트(우선 추천하는 Clash Plus, Clash Verge Rev 등)는 모두 그래픽 오버라이드 입력창을 제공하며, 보통 Merge와 Script 두 형태로 나뉩니다.

Merge 오버라이드: 선언적 병합

Merge 오버라이드는 정해진 규칙에 따라 구독 설정에 병합되는 YAML 조각입니다: 딕셔너리형 필드(dns, tun, sniffer 등)는 구독의 동일 이름 필드 전체를 덮어씁니다; 리스트형 필드는 prepend-와 append- 접두사로 삽입 위치를 제어합니다—prepend-rules는 규칙 목록의 맨 앞(가장 높은 우선순위)에 규칙을 끼워넣고, append-rules는 맨 뒤에 추가합니다. 개인적으로 쓰는 직결 예외나 회사 내부망 도메인은 prepend에, 자신만의 백업 정책은 append에 두면 됩니다. 이 방식은 선언적이고 직관적이어서 "규칙 몇 개 추가하기, DNS 일부 수정하기" 같은 대다수 요구를 처리할 수 있습니다.

prepend-rules:
  - DOMAIN-SUFFIX,internal.example.com,DIRECT
  - PROCESS-NAME,ssh,DIRECT
append-rules:
  - MATCH,节点选择
dns:
  enable: true
  enhanced-mode: fake-ip
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

Script 오버라이드: 프로그래밍 방식 수정

Merge로는 처리할 수 없는 "조건에 따라 일괄 수정" 요구가 있을 때는 Script 오버라이드를 사용합니다: 클라이언트가 파싱된 설정 객체를 JavaScript 함수에 넘기고, 함수는 수정한 객체를 반환합니다. 대표적인 시나리오: 노드 이름을 정규식으로 매칭해 지역별 그룹을 자동 생성하면 구독에 새 지역 노드가 추가되어도 자동으로 분류됨; 모든 url-test 그룹에 interval과 tolerance를 일괄로 보충; 구독에 섞여 있는 만료 안내용 "가짜 노드"를 일괄 삭제. 스크립트에서는 완전한 JS 문법을 사용할 수 있지만, 함수가 최종적으로 return config를 반환하고 필드 구조를 훼손하지 않아야 하며, 그렇지 않으면 코어 로드가 실패합니다.

function main(config) {
  config["proxy-groups"]
    .filter((g) => g.type === "url-test")
    .forEach((g) => {
      g.interval = 300;
      g.tolerance = 60;
    });
  return config;
}

proxy-providers: 다중 구독 병합

구독을 여러 개 가지고 있다면 클라이언트에서 설정을 왔다갔다 전환할 필요가 없습니다. proxy-providers는 2장의 규칙 프로바이더와 동일한 원리입니다: 각 구독을 노드 프로바이더로 선언하고, 정책 그룹에서 use 필드로 하나 또는 여러 프로바이더를 참조하며, filter는 정규식으로 합쳐진 노드 풀에서 걸러냅니다(예: 이름에 "홍콩"이 포함된 노드만 남기기). 이렇게 하면 하나의 설정으로 여러 구독을 통합 관리할 수 있어 한 구독이 장애를 일으켜도 전체에 영향을 주지 않습니다; health-check 하위 필드는 프로바이더가 스스로 주기적 헬스 체크를 하도록 하며, 장애 노드는 자동으로 제외됩니다.

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

proxy-groups:
  - name: 香港自动
    type: url-test
    use: [provider-a, provider-b]
    filter: "(?i)hk|hong ?kong|香港"

07외부 컨트롤 인터페이스와 패널

외부 컨트롤 활성화

Clash 코어는 RESTful 컨트롤 인터페이스를 내장하고 있으며, 거의 모든 그래픽 클라이언트의 화면과 모든 웹 컨트롤 패널이 내부적으로 이를 호출합니다. external-controller는 리스닝 주소를 지정하며, 로컬에서만 사용한다면 127.0.0.1:9090으로 적습니다; secret은 접근 암호를 설정하며, 모든 요청은 Authorization: Bearer 헤더에 이를 담아야 합니다; external-ui는 정적 패널 디렉터리를 가리키며 코어가 직접 호스팅하므로 브라우저로 리스닝 주소에 접속하면 바로 열립니다.

external-controller: 127.0.0.1:9090
secret: "换成足够长的随机口令"
external-ui: ./ui

자주 쓰는 API 목록

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

curl -X PUT -H "Authorization: Bearer <secret>" \
  -d '{"name":"香港自动"}' \
  "http://127.0.0.1:9090/proxies/节点选择"

패널의 일상적인 활용

웹 패널에서 가장 유용한 것은 연결 페이지와 로그 페이지입니다. "왜 특정 사이트가 잘못된 출구로 나갔는가"를 진단할 때, 연결 페이지에서 해당 연결을 찾아 규칙 열과 프록시 경로 열을 확인하면 어떤 규칙에 매칭됐는지, 어떤 그룹을 거쳤는지, 최종적으로 어떤 노드로 나갔는지 한눈에 알 수 있습니다—설정 파일만 보고 추측하는 것보다 훨씬 효율적입니다. 로그 페이지에서 레벨을 debug로 올리면 각 도메인의 DNS 해석 경로와 규칙 매칭 과정을 볼 수 있으며, 이는 3장의 DNS 문제를 직접 관찰하는 수단입니다.

또 하나 알아둘 세부 동작이 있습니다: 패널이나 클라이언트로 프록시 모드(규칙/글로벌/직결)를 전환해도 이미 수립된 기존 연결은 자동으로 끊기지 않고 수립 당시의 경로대로 계속 전송됩니다; 전환 후 "적용이 안 된 것 같다"면 연결 페이지에서 모든 연결을 끊거나 관련 애플리케이션을 재시작하면 됩니다. 세 모드 간 트래픽 흐름의 차이는 《Clash 규칙 모드와 글로벌 모드의 차이 및 전환 시나리오》를 참고하세요.

08설정 검증과 문제 빠른 참조

시작 전 검증

설정을 수정한 후에는 재적용하기 전에 먼저 검증하면 반복 시행착오에 드는 시간을 크게 줄일 수 있습니다. 커맨드라인 코어는 문법과 의미 검사를 제공합니다: mihomo -t -f config.yaml. 통과하면 성공 메시지가 출력되고, 실패하면 오류가 발생한 줄 번호와 원인이 표시됩니다. YAML에서 흔히 발생하는 몇 가지 함정: 들여쓰기는 반드시 공백을 써야 하며 탭 문자가 섞이면 파싱에 실패합니다; 콜론 뒤에는 반드시 공백이 하나 있어야 합니다; 노드 이름이나 그룹 이름에 :, #, 이모지 등 특수 문자가 포함되면 인용부호로 감싸야 합니다; 목록 항목의 -와 내용 사이에도 공백이 필요합니다. 그래픽 클라이언트는 설정을 저장할 때 보통 자동으로 동등한 검증을 수행하며, 그때 나오는 오류 메시지도 꼼꼼히 읽어볼 가치가 있습니다.

mihomo -t -f config.yaml

흔한 문제 대조표

다음 단계

이 페이지는 설정 계층의 체계적인 지식을 다룹니다. 더 구어체에 가까운 빈출 질문은 FAQ에서 기초 개념, 설치 설정, 사용 팁, 문제 해결 네 가지로 정리되어 있습니다; 본문에 등장하는 프록시 프로토콜, 코어, 규칙 관련 용어는 용어집에서 하나씩 찾아볼 수 있습니다; 단일 주제를 깊이 다루는 장문 글은 블로그에 계속 게시됩니다. 처음부터 시작하는 전체 진행 순서는 사용 튜토리얼로 돌아가 단계별로 따라하면 됩니다.