Clash 설정 심화 매뉴얼

CH-01프록시 그룹: 설정 속의 변속 장치

먼저 두 가지를 구분해야 합니다. 규칙은 이 트래픽을 누가 처리할지 판단하는 역할을 하고, 프록시 그룹은 그 처리를 담당한 뒤 구체적으로 어떤 노드를 거칠지 결정하는 역할을 합니다. 오래 쓸 수 있는 설정에서는 거의 모든 규칙의 출구가 개별 노드를 직접 지정하지 않고 프록시 그룹을 가리킵니다—노드는 오늘 있다가 내일 사라질 수 있지만 그룹 이름은 바뀌지 않습니다. 그룹을 잘 구성해 두면 이후 공급자를 바꾸거나 노드를 교체할 때 탄창만 바꾸는 것과 같아서 총 자체는 손댈 필요가 없습니다.

다섯 가지 유형, 하나의 규격표

선택 기준은 단순합니다: 기계가 판단하도록 맡길 때는 url-test, 사람이 직접 결정해야 할 때는 select를 쓰고, 나머지 세 가지는 특정 상황에서만 쓰는 전용 부품입니다. 초보자라면 앞의 두 가지만 익혀도 요구 사항의 90%는 충족됩니다.

url-test의 세 가지 조절 항목

url은 속도 측정 대상 주소로, 관례적으로 204 상태 코드를 반환하는 가벼운 주소를 씁니다. 예를 들어 https://www.gstatic.com/generate_204는 빈 응답만 돌려주기 때문에 웹페이지 로딩 시간이 섞이지 않은 순수한 링크 지연만 측정할 수 있습니다. interval은 측정 주기로 단위는 초이며, 300이면 5분마다 한 번 측정합니다. 값을 너무 작게 하면 측정 요청이 지나치게 자주 발생하고, 너무 크게 하면 노드가 죽은 지 한참 지나서야 알아챕니다. tolerance는 허용 오차로 단위는 밀리초입니다: 기존과 새로 측정한 최속 노드의 지연 차이가 이 값을 넘지 않으면 전환하지 않습니다. 이를 설정하지 않으면 두 노드의 지연이 80과 85 사이를 오가며 그룹도 함께 흔들려 장시간 연결이 반복적으로 끊길 수 있습니다. 자주 쓰는 항목 하나를 더 덧붙이면 lazy: true입니다—그룹이 사용되지 않을 때는 측정을 시작하지 않아 불필요한 백그라운드 요청을 줄일 수 있습니다.

오래 쓸 수 있는 계층 구조

실전에서는 3단 구조를 추천합니다: 맨 위는 select로 만든 메인 스위치, 중간에는 자동 측정 그룹과 각 지역 그룹을 두고, 가장 아래에 구체적인 노드를 배치합니다. 규칙은 항상 그룹 이름을 가리키며 개별 노드를 직접 지정하지 않습니다. 특정 지역을 수동으로 고정하고 싶다면 메인 스위치에서 전환하고, 완전 자동으로 쓰고 싶다면 자동 측정 그룹으로 다시 전환하면 됩니다. 구조는 다음과 같습니다:

proxy-groups:
  - name: 수동 메인
    type: select
    proxies: [자동 측정, 홍콩 노드, 일본 노드, DIRECT]

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

  - name: 홍콩 노드
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    proxies: [HK-01, HK-02]

  - name: 일본 노드
    type: select
    proxies: [JP-01, JP-02]

CH-02규칙 세트: 규칙을 교체 가능한 탄창으로

수백 개의 규칙을 하나씩 메인 설정에 적어 넣는 것은 모든 부품을 기판에 용접해 붙이는 것과 같습니다—하나만 바꾸려 해도 전체를 분해해야 합니다. rule-providers의 아이디어는 규칙을 탈착 가능한 탄창으로 분리하는 것입니다: 메인 설정에는 RULE-SET 참조 한 줄만 남기고, 탄창 본체는 외부 주소에 두어 정해진 시간에 자동으로 업데이트합니다. 관리자가 탄창을 수정해도 이쪽에서는 아무것도 손댈 필요가 없습니다.

슬롯 규격

각 provider에는 다섯 가지 핵심 필드가 있습니다. type은 http(URL에서 가져오기)와 file(로컬 파일 읽기) 두 가지로 나뉩니다. behavior는 탄창 안에 어떤 종류의 탄환이 들어 있는지 선언하는 항목으로 다음 절에서 설명합니다. format은 파일 형식으로 yaml 또는 text입니다. path는 다운로드 후 저장되는 로컬 캐시 경로입니다. interval은 자동 업데이트 주기로 단위는 초이며, 86400이면 하루에 한 번 교체됩니다. 캐시의 의미는 이렇습니다: 네트워크가 끊긴 상태로 재시작해도 코어가 로컬 사본을 바로 읽어, 규칙을 받아오지 못해 시작이 안 되는 상황을 막아줍니다.

behavior 세 가지 중 어떻게 고를까

domain 탄창에는 도메인만 담기며, 코어가 이를 위한 전용 인덱스를 만들어 매칭 속도가 가장 빠르고 메모리도 가장 적게 씁니다. ipcidr에는 IP 대역만 담기며 마찬가지로 전용 매칭을 사용합니다. classical은 어떤 유형이든 담을 수 있어(DOMAIN-SUFFIX, IP-CIDR, PROCESS-NAME을 섞어서 사용) 유연하지만 한 줄씩 순차 매칭하므로 규칙이 많아지면 성능을 많이 소모합니다. 선택 기준: 순수 도메인 목록은 domain, 순수 IP 대역은 ipcidr, 섞여 있을 때만 classical을 씁니다. classical로 순수 도메인 목록을 처리하는 것도 동작은 하지만, 소포 하나를 트럭으로 배달하는 것과 다름없습니다.

구성 예제와 업데이트 주기

rule-providers:
  streaming:
    type: http
    behavior: classical
    format: yaml
    url: "https://example.com/rulesets/streaming.yaml"
    path: ./rulesets/streaming.yaml
    interval: 86400
  cn-ip:
    type: http
    behavior: ipcidr
    format: text
    url: "https://example.com/rulesets/cn-ip.txt"
    path: ./rulesets/cn-ip.txt
    interval: 86400

rules:
  - RULE-SET,streaming,수동 메인
  - RULE-SET,cn-ip,DIRECT,no-resolve
  - MATCH,수동 메인

업데이트 주기는 탄창의 성격에 따라 정합니다: 커뮤니티가 관리하는 분기 목록은 하루에 한 번이면 충분하고, 직접 관리하며 자주 조정하는 목록은 몇 시간 단위로 줄일 수 있습니다. 규칙 세트 가져오기가 실패했을 때의 점검 방법은 구독 업데이트 실패와 동일하며, 헬프 센터의 문제 해결 분류를 참고하면 됩니다.

CH-03DNS 설정 최적화: 절반의 원인은 해석에 있다

'프록시는 켰는데 웹페이지가 안 열린다', '규칙을 분명히 적었는데 매칭이 안 된다'—이런 문제의 절반은 DNS에서 발생합니다. 코어에는 DNS 리졸버가 내장되어 있어 설정이 적절하면 해석이 빠르고 안정적이지만, 설정이 엉망이면 오염과 유출이 번갈아 나타납니다. 이 장에서는 해석 경로에 있는 각 항목을 하나씩 설명합니다.

먼저 해석 경로를 이해하기

리졸버는 세 개의 계층으로 이루어집니다. default-nameserver는 부트스트랩 계층입니다: 주력 리졸버 자체가 도메인 형태(예: DoH 주소 https://doh.pub/dns-query)일 때는 먼저 이 도메인을 IP로 해석해 줄 존재가 필요한데, 그 역할을 부트스트랩 계층이 맡습니다. 그래서 여기에는 순수 IP만 넣을 수 있으며, 도메인을 넣으면 닭이 먼저냐 달걀이 먼저냐 하는 순환에 빠집니다. nameserver는 주력 계층으로 일상적인 조회는 모두 여기를 거칩니다. fallback은 보조 계층으로, 주력 계층이 오염될 수 있는 상황에 대응합니다. 세 계층은 각자 역할이 다르므로 DoH 주소를 부트스트랩 계층에 넣거나 주력 계층을 비워 두면 안 됩니다.

nameserver와 fallback의 역할 분담

동작 방식은 동시 요청입니다: 한 번의 조회를 주력과 보조 계층에 동시에 보내고, fallback-filter가 어느 쪽 응답을 채택할지 판정합니다. 가장 흔히 쓰는 판정 방식은 geoip: true와 geoip-code: CN을 함께 쓰는 것입니다: 주력 계층이 돌려준 IP가 중국 본토 대역이면 주력 응답을 채택하고(정상적인 국내 해석이라는 뜻), 해외 대역이면 보조 계층의 응답으로 바꿉니다(국내 리졸버가 해외 IP를 내놓았다면 오염되었을 가능성이 있습니다). 이 방식은 조회마다 요청을 하나 더 보내는 대가로 오염 방지 능력을 얻는 구조입니다. 주력 계층이 이미 암호화 채널(DoH/DoT)을 사용한다면 오염 위험이 낮으므로 fallback을 간단하게 구성해도 됩니다.

nameserver-policy: 도메인별 전용 리졸버 지정

어떤 도메인은 어디서 해석해야 하는지 이미 명확히 알고 있는 경우가 있습니다: 국내 서비스는 국내 리졸버를 써서 가까운 CDN 노드를 얻고, 속도 측정용 도메인이나 로컬 네트워크 도메인은 각자 전용 목적지가 있습니다. nameserver-policy는 바로 이런 지정 분류표로, 와일드카드와 geosite 분류를 지원합니다. 전체 예제는 다음과 같습니다:

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://doh.pub/dns-query
    - https://dns.alidns.com/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
  nameserver-policy:
    "geosite:cn": https://doh.pub/dns-query
    "+.lan": 223.5.5.5

CH-04TUN과 Fake-IP: 시스템 계층 백업과 가짜 주소 번호판

TUN: 말을 듣지 않는 트래픽까지 인수하기

시스템 프록시는 일종의 신사협정입니다: '시스템 프록시 설정을 따르겠다'는 앱만 이를 경유합니다. 커맨드라인 도구, 일부 게임 클라이언트, 몇몇 데스크톱 소프트웨어는 이 설정을 무시하고 트래픽을 곧바로 내보냅니다. TUN 모드는 가상 네트워크 카드를 하나 끼워 넣어 기기 전체의 아웃바운드 트래픽을 네트워크 계층에서 붙잡아 코어에 넘기는 방식입니다—앱이 협조하든 말든 상관없이, 빠져나가려는 트래픽도 검사를 받아야 합니다.

Android에서의 상황도 함께 짚어보겠습니다: 클라이언트에서 '시작'을 누를 때 시스템에 요청하는 VPN 채널은 본질적으로 TUN 네트워크 카드입니다. 그래서 Android 사용자는 원래부터 TUN 모드 안에 있으며 이 부분을 수동으로 설정할 필요가 없습니다. TUN을 명시적으로 켜야 하는 쪽은 데스크톱 플랫폼입니다. 각 플랫폼 클라이언트는 다운로드 페이지에서 받을 수 있고, 플랫폼 간 차이는 비교 리뷰에서 확인할 수 있습니다. 데스크톱의 핵심 항목: stack은 프로토콜 스택 구현 방식으로, system은 성능이 좋지만 시스템 기능에 의존하고, gvisor는 사용자 공간 구현으로 호환성이 안정적이며, mixed는 둘의 장점을 모두 취하니 확신이 없다면 mixed를 선택하세요. auto-route는 라우팅 테이블을 자동으로 인수합니다. dns-hijack은 임의의 53번 포트로 향하는 평문 DNS 요청을 코어로 가로채어 앱 자체 리졸버가 분기 설정을 우회하는 것을 막습니다.

Fake-IP: 먼저 번호표를 발급하고 나중에 처리하기

은행의 번호표 발급 방식과 같은 원리입니다. 앱이 '이 도메인의 IP가 뭐냐'고 물으면 코어는 실제로 해석하지 않고 198.18.0.1/16이라는 예약 대역에서 즉시 가짜 주소를 번호표처럼 발급합니다—지연이 전혀 없습니다. 앱은 이 번호표로 연결을 시작하고, 연결이 코어에 도달하면 코어는 번호표로 도메인을 역으로 조회해 도메인 규칙에 따라 분기시킵니다. 프록시를 거쳐야 하는 트래픽이라면 실제 해석은 출구 쪽에서 처리합니다. 장점은 두 가지입니다: 로컬에서의 실제 해석 대기 시간이 사라져 연결이 빨리 시작되고, 코어가 매 연결 뒤에 어떤 도메인이 있는지 항상 알고 있어 도메인 규칙의 적중률도 높아집니다.

대가는 이 번호표를 실제 창구에서는 쓸 수 없다는 점입니다. 로컬 네트워크 기기 탐색, 프린터, 일부 게임 온라인 플레이, IP를 서버에 다시 전달해야 하는 상황에서는 가짜 주소를 받으면 곤란해집니다. 해결책은 fake-ip-filter입니다: 목록에 있는 도메인에는 번호표를 발급하지 않고 실제 해석을 그대로 수행합니다.

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

dns:
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "+.local"
    - "+.msftconnecttest.com"
    - "+.stun.*.*"

fake-ip와 redir-host 비교

CH-05도메인 스니핑: 인바운드 지점에 붙인 코드 리더기

Fake-IP로 틈을 막았어도 경로상에는 아직 빈틈이 하나 남아 있습니다: 일부 트래픽이 코어에 도달할 때 손에 IP만 있고 도메인이 없는 경우입니다. 대표적인 원인은 앱이 자체적으로 사용하는 암호화 해석(코어의 DNS를 거치지 않는 앱 내장 DoH)이거나, IP를 고정해 직접 연결하는 클라이언트입니다. 도메인 규칙은 이런 트래픽에 대해 전혀 인식하지 못해 IP 규칙이나 MATCH로만 처리해야 하므로 분기 정밀도가 크게 떨어집니다.

sniffer는 인바운드 지점에 붙인 바코드 리더기입니다: 트래픽이 들어올 때 TLS 핸드셰이크의 SNI 필드나 HTTP 요청 헤더의 Host 필드에서 도메인을 다시 읽어내어 해당 연결에 다시 붙이고, 규칙 매칭으로 넘깁니다. 도메인을 되찾으면 규칙이 정상적으로 동작할 수 있습니다.

설정 항목 규격

sniff 아래에는 프로토콜별로 스캔할 포트를 선언합니다: TLS는 보통 443과 8443을 스캔하고, HTTP는 80과 흔히 쓰는 프록시 포트 구간을 스캔합니다. override-destination은 스니핑으로 얻은 도메인이 원래 목적지 주소를 덮어쓸지 결정하며, HTTP 상황에서는 켜는 것을 권장합니다. force-domain은 강제 스니핑 목록으로, 여기에 있는 도메인은 이미 해석 결과가 있어도 다시 스니핑합니다. skip-domain은 검사 제외 목록입니다—인증서 검증이 엄격하거나 SNI 변경에 민감한 서비스(애플 푸시가 대표적)는 스니핑이 오히려 연결을 끊어버릴 수 있으므로 이 목록에 넣어 바로 통과시킵니다.

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

CH-06로컬 오버라이드와 다중 구독 병합: 업데이트와 충돌 걱정 없이 수정하기

구독 파일을 직접 수정하지 않는 이유

구독으로 받은 설정 파일에서 바로 규칙을 고치고 노드를 추가하면 손맛은 좋지만 결말은 좋지 않습니다: 구독이 업데이트되는 순간 서버가 내려준 새 버전이 파일 전체를 덮어써 버려 그동안의 수정이 모두 사라집니다. 올바른 방법은 오버라이드입니다—구독 원문은 항상 읽기 전용으로 두고, 수정 내용은 로컬의 별도 계층에 기록해 구독이 업데이트될 때마다 새 파일에 자동으로 다시 적용합니다. 이렇게 하면 수정과 구독이 서로 간섭하지 않습니다.

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

주요 클라이언트에는 대부분 이 기능이 내장되어 있으며 이름은 다르지만 아이디어는 같습니다. Clash Verge Rev를 예로 들면 두 단계가 제공됩니다: Merge는 선언형 조각으로 병합하는 방식으로 규칙 추가나 프록시 그룹 추가 같은 구조적인 수정에 적합하고, Script는 스크립트로 설정 전체를 프로그래밍 방식으로 재작성하는 방식으로 노드를 일괄 이름 변경하거나 조건에 따라 필터링하는 복잡한 작업에 적합합니다. Merge로 해결되는 것은 Script를 쓰지 마세요—선언형 조각은 한눈에 이해할 수 있지만 스크립트에서 오류가 나면 원인을 찾는 비용이 훨씬 큽니다. 각 클라이언트의 오버라이드 기능 차이는 비교 리뷰에서 따로 다루고 있습니다.

proxy-providers로 다중 구독 병합하기

두 곳 이상의 공급자를 이용한다면 설정 파일을 오가며 바꾸지 마세요. proxy-providers는 규칙 세트의 provider와 같은 아이디어입니다: 각 구독이 하나의 노드 탄창이 되고, 프록시 그룹에서 use 필드로 여러 탄창을 동시에 연결하면 두 공급자의 노드가 같은 자동 측정 그룹에 함께 편성되어 더 빠른 쪽을 사용합니다.

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

proxy-groups:
  - name: 전체 노드
    type: url-test
    use: [airport-a, airport-b]
    url: https://www.gstatic.com/generate_204
    interval: 300

health-check는 탄창 안 노드들을 주기적으로 점검해 죽은 노드는 자동 측정 그룹에서 건너뜁니다. interval: 43200은 구독 본체를 12시간마다 새로 받아온다는 뜻입니다. 구독 링크의 형식 인식과 가져오기 방법은 다음 글을 먼저 참고하세요: Clash 구독 링크 가져오기 가이드.

CH-07외부 제어판: 코어에 원격 제어 인터페이스 달기

세 항목으로 원격 제어 켜기

external-controller는 RESTful API의 수신 주소를 선언하며 관례적으로 127.0.0.1:9090을 씁니다. secret은 접근 비밀번호로 모든 요청에 반드시 포함되어야 합니다. external-ui는 로컬 디렉터리를 가리키며, 여기에 웹 패널의 정적 파일을 넣어두면 브라우저에서 수신 주소로 바로 접속해 그래픽 인터페이스를 열 수 있습니다. 시중의 웹 패널(metacubexd, yacd 계열)은 본질적으로 모두 이 API의 프런트엔드 스킨일 뿐, 껍데기만 다르고 속은 같습니다.

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

패널 없이도 사용 가능: 자주 쓰는 세 가지 명령

API 자체가 바로 활용 가능한 도구이므로 스크립트나 자동화 작업에서 직접 호출하면 됩니다:

# 모든 프록시 그룹과 노드 상태 보기
curl -H "Authorization: Bearer your-strong-password" \
  http://127.0.0.1:9090/proxies

# '수동 메인' 그룹을 HK-01로 전환
curl -X PUT -H "Authorization: Bearer your-strong-password" \
  -d '{"name":"HK-01"}' \
  http://127.0.0.1:9090/proxies/수동 메인

# 노드 하나의 지연을 한 번 측정
curl -H "Authorization: Bearer your-strong-password" \
  "http://127.0.0.1:9090/proxies/HK-01/delay?timeout=5000&url=https://www.gstatic.com/generate_204"

패널에서 자주 쓰면 좋은 세 가지 기능

연결 목록: 각 연결이 어떤 규칙에 매칭됐고 어떤 출구를 거쳤는지 실시간으로 볼 수 있어 '이 트래픽이 왜 직접 연결됐지' 같은 문제를 한눈에 확인할 수 있습니다. 로그: 레벨을 임시로 debug로 올리면 규칙 매칭의 전체 과정이 한 줄씩 출력되니, 점검이 끝나면 다시 낮춰야 합니다. debug 로그는 양이 매우 많습니다. Provider 관리: interval이 될 때까지 기다리지 않고 특정 구독이나 규칙 세트를 수동으로 즉시 업데이트할 수 있습니다.

CH-08설정 문제 해결 요약표

증상에 맞춰 먼저 가장 흔한 원인을 확인하고, 링크를 따라 해당 장이나 글로 이동하세요. 대부분의 문제는 처음 두 단계에서 해결됩니다.

표에 없는 문제는 헬프 센터에서 '기초 개념 / 설치와 설정 / 사용 팁 / 문제 해결' 네 가지 분류를 살펴보세요. 클라이언트 자체의 문제로 의심된다면 먼저 비교 리뷰에서 해당 클라이언트의 기능 범위를 확인하고, 필요하다면 다운로드 페이지에서 우선 추천하는 Clash Plus로 바꿔 시도해 보세요. 기본 조작이 기억나지 않는다면 언제든지 빠른 시작으로 돌아가 다시 확인할 수 있습니다.