ADVANCED CONFIGURATION

Clash 고급 설정 가이드

정책 그룹, 규칙 제공자와 DNS부터 시작해 TUN, Fake-IP, 도메인 스니핑, 로컬 오버라이드와 외부 제어까지 점검합니다. 각 장에서는 설정 계층을 먼저 설명한 뒤 수정 방법과 검증 경로를 제시합니다.

내용 살펴보기 먼저 빠른 시작 보기
proxy-groups rule-providers dns tun sniffer

READING GUIDE

먼저 수정할 계층을 정하세요

이 페이지는 체계적인 확인을 위한 자료이며 최초 설치 절차를 대신하지 않습니다. 아직 구독 가져오기, 시스템 프록시 활성화와 기본 연결 확인을 완료하지 않았다면 먼저 사용 가이드에 따라 기본 절차를 진행하세요. 기본 연결은 정상인데 트래픽 분배 방식, DNS 동작 또는 투명 프록시를 조정해야 할 때 이 페이지의 해당 장으로 돌아오면 됩니다.

설정 문제 해결은 단일 변수 원칙을 지켜야 합니다. 현재 작동하는 설정을 저장한 뒤 필드 하나만 수정하고, 다시 불러온 후 연결 로그와 규칙 매칭을 확인하세요. 구독, DNS, 규칙 제공자와 정책 그룹을 동시에 바꾸면 장애 계층이 섞여 결국 전체 설정을 되돌리게 됩니다.

CHAPTER 01

정책 그룹 유형과 실전 활용

정책 그룹은 규칙과 프록시 노드 사이에 있습니다. 규칙의 마지막 인자는 보통 특정 노드가 아니라 정책 그룹 이름이며, 정책 그룹이 요청을 어떤 노드, 자동 테스트 그룹 또는 직접 연결로 보낼지 결정합니다. “규칙은 매칭되는데 출구가 이상한” 경우 먼저 로그의 규칙 이름을 확인한 다음 해당 정책 그룹을 열어 현재 선택 항목을 확인하세요. 규칙을 수정해도 수동 선택 그룹의 상태는 바뀌지 않고, 노드를 전환해도 규칙이 수정되지는 않으므로 두 작업은 따로 검증해야 합니다.

select, url-test, fallback과 load-balance의 차이

select는 수동 선택 그룹으로, “프록시 선택”, “스트리밍”, “다운로드”처럼 출구를 직접 지정해야 하는 상황에 적합합니다. 특정 노드뿐 아니라 다른 정책 그룹도 포함할 수 있습니다. 자동 속도 측정 그룹을 수동 그룹에 넣으면 평소에는 자동 그룹을 선택하고, 특정 지역이 필요할 때 해당 지역 그룹으로 전환할 수 있어 구조가 명확하고 되돌리기도 쉽습니다. 수십 개의 노드를 각 업무 정책에 직접 나열하지 마세요. 노드 이름이 바뀌면 여러 참조가 동시에 깨질 수 있습니다.

url-test는 일정한 간격으로 테스트 주소에 접속해 후보 노드 중 결과가 더 좋은 노드를 선택합니다. 측정 결과는 지정한 주소의 연결 상태일 뿐 모든 웹사이트나 대용량 전송 성능을 의미하지는 않습니다. interval은 테스트 간격을 제어하며 너무 짧으면 백그라운드 요청이 늘어납니다. tolerance는 작은 변동으로 인한 잦은 전환을 억제합니다. 현재 노드가 계속 사용 가능하고 최적 결과와의 차이가 허용 오차 이내라면 현재 노드를 유지하는 편이 대체로 더 안정적입니다.

fallback은 사용 가능성의 우선순위를 중시합니다. 목록 앞쪽 노드가 복구되면 앞쪽 항목으로 돌아가려는 특성이 있어 주·예비 출구가 명확한 환경에 적합합니다. load-balance는 여러 노드에 연결을 분산하며 출구 변경을 허용할 수 있는 동시 요청에 적합합니다. 로그인 상태, 지역 일관성 또는 위험 제어에 민감한 웹사이트에는 부적합할 수 있습니다. 같은 업무의 연결마다 출구가 달라질 수 있기 때문입니다.

proxy-groups:
  - name: 프록시 선택
    type: select
    proxies:
      - 자동 선택
      - 장애 조치
      - DIRECT

  - name: 자동 선택
    type: url-test
    include-all: true
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80
    lazy: true

  - name: 장애 조치
    type: fallback
    include-all: true
    url: https://www.gstatic.com/generate_204
    interval: 600
    lazy: true

필터 조건으로 후보 노드 제어하기

구독 노드가 많다면 자동 그룹이나 지역 그룹 안에서 필터 조건을 사용하고 노드 이름을 수동으로 복사하지 마세요. 관련 필드를 지원하는 커널에서는 include-all로 노드를 포함한 뒤 filter로 이름을 매칭하고, exclude-filter로 배율·테스트 항목이나 제외할 대상을 걸러낼 수 있습니다. 필터 표현식은 노드 이름을 기준으로 하므로 구독 제공자가 이름을 바꾸면 후보가 비어 있을 수 있습니다. 구독을 업데이트할 때마다 정책 그룹을 열어 사용 가능한 멤버가 하나 이상 있는지 확인하세요.

정책 그룹은 다른 그룹을 참조할 수 있지만 순환 구조는 만들지 마세요. 예를 들어 “프록시 선택”이 “자동 선택”을 포함하는 것은 정상입니다. 반대로 “자동 선택”이 다시 “프록시 선택”을 후보로 포함하면 커널이 확정된 출구를 결정할 수 없습니다. 그룹 이름은 규칙 끝의 이름과 완전히 일치해야 하며 공백, 대소문자와 전각 문자도 차이로 처리됩니다. 설정 로드에 실패하면 먼저 같은 이름의 그룹이 중복되는지 검색한 다음 규칙이 참조하는 그룹이 실제로 존재하는지 확인하세요.

유형 선택 방식 적용 상황 주요 위험
select 사용자가 직접 지정 고정 지역, 스트리밍, 다운로드 선택한 노드가 실패해도 자동으로 변경되지 않음
url-test 테스트 결과에 따른 자동 선택 일반 웹 브라우징과 범용 프록시 테스트 주소의 성능이 모든 업무의 성능을 보장하지 않음
fallback 사용 가능한 항목을 순서대로 사용 주 노드와 예비 노드 후보 순서를 잘못 설정하면 예상과 다른 출구를 선택함
load-balance 여러 노드에 연결 분배 여러 출구를 허용할 수 있는 동시 연결 로그인 세션과 지역 판정이 일치하지 않을 수 있음

CHAPTER 02

규칙 제공자 구독 관리

규칙이 많아지면 모든 항목을 기본 설정에 넣는 방식에서 세 가지 문제가 생깁니다. 구독 업데이트 때 로컬 수정이 덮어쓰기되고, 규칙 출처를 따로 업데이트하기 어려우며, 문제 해결 시 어느 그룹이 매칭되었는지 판단하기 어렵습니다. rule-providers는 규칙을 독립된 집합으로 분리하고, 기본 설정에는 출처, 저장 경로, 업데이트 간격과 참조 순서만 남깁니다. 광고, 로컬 네트워크, 직접 연결 영역과 프록시 서비스 규칙을 각각 관리할 수 있지만 최종 매칭 순서는 기본 설정의 rules가 결정합니다.

behavior가 결정하는 규칙 파일 형식

domain 유형은 순수 도메인 집합에 사용하며 규칙 파일의 payload에는 보통 도메인, 접미사 또는 와일드카드 표현식을 작성합니다. ipcidr은 IP 대역에 사용하고, classical은 DOMAIN-SUFFIX, PROCESS-NAME, IP-CIDR처럼 유형이 포함된 전체 규칙을 담을 수 있습니다. 유형을 잘못 선택하면 파일을 정상적으로 내려받아도 파싱되지 않을 수 있습니다. 먼저 규칙 원본의 내용을 확인한 뒤 behavior를 정하세요. 파일명만 보고 추측하지 마세요.

type: http는 원격 업데이트를, url은 출처 주소를, path는 로컬 캐시 위치를, interval은 새로 고침 주기를 의미합니다. provider마다 서로 다른 경로를 사용해야 하며, 그렇지 않으면 나중에 내려받은 파일이 앞선 파일을 덮어씁니다. 원격 업데이트에 실패해도 커널은 보통 기존 캐시를 계속 사용합니다. 처음 시작할 때 캐시가 없고 원격 주소에도 연결할 수 없다면 해당 규칙 집합을 로드할 수 없으므로, 중요한 로컬 네트워크 규칙은 소량의 인라인 항목으로 남겨 시작을 보장할 수 있습니다.

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

  service-proxy:
    type: http
    behavior: classical
    format: yaml
    path: ./ruleset/service-proxy.yaml
    url: https://example.com/rules/service-proxy.yaml
    interval: 86400

rules:
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,service-proxy,프록시 선택
  - GEOIP,CN,DIRECT
  - MATCH,프록시 선택

예시 주소는 필드 구조를 설명하기 위한 것이므로 실제 운영에서는 관리 중인 규칙 출처로 바꿔야 합니다. 규칙 파일을 YAML로 사용할 때 domain provider는 다음과 같이 작성할 수 있습니다.

payload:
  - localhost
  - "*.lan"
  - "+.example.internal"

규칙 수보다 중요한 것은 정렬 순서입니다

Clash 규칙은 위에서 아래로 확인하며 처음 매칭된 뒤 중지합니다. 구체적인 업무 규칙은 넓은 지역 규칙보다 앞에 두고, 로컬 네트워크와 예약 주소는 기본 프록시보다 앞에 배치해야 하며, MATCH는 반드시 마지막에 둬야 합니다. 먼저 GEOIP,CN,DIRECT를 작성한 뒤 IP 판정이 필요한 프록시 규칙을 작성하면 앞의 규칙이 요청을 먼저 가져갈 수 있습니다. 넓은 도메인 접미사를 먼저 작성한 뒤 같은 주 도메인의 특정 하위 도메인을 작성해도 뒤 규칙은 실행되지 않습니다.

규칙 충돌이 발생했을 때 예외를 계속 추가하기보다 먼저 요청이 실제로 매칭된 항목을 기록해야 합니다. 클라이언트 로그나 외부 제어 패널에는 보통 규칙 유형, 규칙 내용과 대상 정책이 표시됩니다. 잘못 매칭된 것을 확인했다면 더 구체적인 규칙을 앞쪽으로 이동하세요. 도메인을 확인할 수 없거나 연결에 IP만 남거나 애플리케이션이 시스템 확인을 우회하는 경우에만 IP 규칙 추가를 고려해야 합니다. 도메인과 IP 규칙을 무작정 쌓으면 결과를 예측하기 어려워집니다.

no-resolve는 IP 규칙 매칭을 위해 추가 DNS 확인을 발생시키고 싶지 않을 때 사용합니다. 예를 들어 GEOIP,CN,DIRECT,no-resolve는 대상 IP를 이미 사용할 수 있을 때만 판단합니다. 추가 조회를 줄일 수 있지만 현재 연결에 도메인만 있다면 먼저 조회한 뒤 매칭하지 않습니다. 사용 전 규칙 단계에서 요청이 도메인인지 IP인지 확인해야 하며, no-resolve를 범용 성능 옵션으로 사용해서는 안 됩니다.

업데이트 실패와 규칙 미적용은 나누어 처리하세요

provider 다운로드 실패는 출처 계층의 문제입니다. 먼저 직접 연결로 주소에 접근할 수 있는지 확인한 뒤 URL, 응답 형식과 캐시 디렉터리 권한을 점검하세요. 다운로드는 성공했지만 매칭되지 않는다면 참조 계층의 문제입니다. rules에 해당 RULE-SET이 있는지, 정책 그룹 이름이 올바른지, 앞선 규칙이 먼저 매칭되지 않았는지 확인하세요. 파일 파싱 실패는 형식 계층의 문제이므로 behavior, format, YAML 들여쓰기와 payload 계층을 집중적으로 확인합니다.

규칙 업데이트 후 설정을 한 번 다시 불러오고 고정 도메인으로 테스트하세요. 여러 웹사이트를 동시에 사용해 확인하지 마세요. 브라우저 백그라운드 요청, QUIC과 캐시가 로그에 섞일 수 있습니다. 하나의 대상을 선택해 연결 기록을 지운 뒤 한 번 접속하고, 도메인·매칭 규칙·최종 정책이 일치하는지 확인하세요. 규칙 기본 개념은 용어 가이드에서 확인할 수 있습니다. 모든 노드가 시간 초과되면 노드 연결 시간 초과 문제 해결 순서로 이동하고 규칙 제공자를 계속 수정하지 마세요.

CHAPTER 03

DNS 설정 최적화

DNS 문제는 노드 문제로 오해하기 쉽습니다. 브라우저에 연결 실패가 표시되어도 도메인이 확인되지 않았거나, 잘못된 결과가 캐시되었거나, 조회가 Clash로 들어오지 않았거나, 규칙 단계에서 원래 도메인을 얻지 못한 것일 수 있습니다. 진단할 때는 먼저 “DNS 조회를 누가 처리하는가”와 “확인 결과를 연결에 어떻게 사용하는가”를 구분하세요. 시스템 DNS, 클라이언트 내장 DNS, 브라우저 보안 DNS와 애플리케이션 자체 확인이 동시에 존재할 수 있으므로 조회 경로를 확인해야 설정 항목이 의미를 가집니다.

먼저 nameserver, default-nameserver와 fallback을 이해하세요

nameserver는 주요 확인 업스트림입니다. 일반 UDP/TCP DNS뿐 아니라 DoH나 DoT도 사용할 수 있습니다. default-nameserver는 주로 암호화 DNS 업스트림 자체의 도메인을 확인하는 데 사용하며, DoH 도메인에 연결하려고 다시 DoH에 의존하는 순환을 피하도록 직접 접근 가능한 IP 주소를 입력하는 것이 일반적입니다. 모든 업무 조회의 기본 출구가 아니며 많은 주소를 넣어서도 안 됩니다.

fallback과 필터 설정은 여러 확인 결과 중 하나를 선택하는 데 사용합니다. 이 기능은 설정이 복잡하므로 오염된 응답이나 분할 확인이 꼭 필요한 것이 아니라면 안정적인 nameserver만 사용해 기본 확인을 먼저 검증한 뒤 fallback을 추가하세요. 업스트림을 많이 넣는다고 빨라지는 것은 아닙니다. 병렬 조회로 로그가 복잡해지고 결과별 캐시 차이가 생길 수도 있습니다. 역할이 분명한 업스트림 두세 개를 우선 유지하세요.

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  use-hosts: true
  respect-rules: true
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  fake-ip-filter:
    - "*.lan"
    - localhost.ptlogin2.qq.com
    - time.*.com
    - time.*.gov

proxy-server-nameserver는 프록시 서버 자체의 도메인을 확인하는 데 사용합니다. 노드 주소가 도메인으로 작성되어 있다면 먼저 노드 IP를 얻어야 프록시 연결을 만들 수 있습니다. 이 조회가 아직 연결되지 않은 프록시에 잘못 의존하면 시작 교착이 발생합니다. 프록시에 먼저 연결해야 하는데 연결하려면 다시 프록시를 통해 확인해야 하기 때문입니다. 노드 도메인은 직접 연결 가능한 업스트림에서 확인하도록 분리하세요.

Fake-IP와 redir-host 선택

fake-ip는 도메인을 즉시 실제 대상 IP로 확인하지 않고 예약 주소 풀의 매핑 주소를 반환합니다. 애플리케이션이 해당 주소에 연결하면 커널이 매핑 테이블에서 도메인을 복원한 뒤 도메인 규칙으로 처리합니다. 도메인 정보를 더 온전히 유지하고 실제 DNS 결과가 애플리케이션에 일찍 노출되는 것을 줄일 수 있지만, 일부 로컬 네트워크 검색, 기기 미러링, 시간 동기화, 게임과 실제 IP 검증에 의존하는 프로그램은 호환되지 않을 수 있으므로 fake-ip-filter로 제외해야 합니다.

redir-host는 실제 확인 결과를 반환하므로 기존 프록시에 가까운 호환 경로를 제공하지만, 규칙 단계에서 DNS 결과와 스니핑에 더 의존할 수 있습니다. 모드를 선택할 때 “웹페이지가 열리는가”만 보지 마세요. 로컬 네트워크 기기, 시스템 시간, 자주 사용하는 메신저와 지역 판정이 필요한 서비스를 함께 확인해야 합니다. 특정 유형의 도메인만 이상하다면 전체 모드를 redir-host로 바꾸기보다 해당 도메인을 필터 목록에 추가하세요.

IPv6 설정은 로컬 네트워크와 함께 판단해야 합니다

ipv6: false는 AAAA 결과를 억제하며, 로컬 IPv6가 불완전하거나 노드가 IPv6를 지원하지 않거나 IPv6 우선 연결이 자주 실패하는 환경에 적합합니다. 로컬과 출구 모두 안정적인 IPv6를 지원한다면 활성화한 뒤 A·AAAA 조회와 실제 출구를 각각 확인하세요. 시스템에서만 IPv6를 껐는데 Clash가 AAAA를 반환하면 애플리케이션이 접근할 수 없는 주소를 먼저 시도할 수 있습니다. 반대로 네트워크가 IPv6를 지원해도 DNS에서 AAAA를 차단하면 IPv6를 사용할 수 없습니다.

DNS 유출은 하나의 검사 웹페이지만으로 판단할 수 없습니다. 먼저 시스템 DNS가 클라이언트 수신 주소를 가리키는지 확인하고, 브라우저에서 독립 보안 DNS가 활성화되어 있는지 확인한 다음 조회 로그가 커널로 들어오는지 관찰하세요. 브라우저 DoH가 시스템 DNS를 우회해도 연결 트래픽은 프록시를 통과할 수 있습니다. 이는 조회 경로가 다른 것이지 모든 트래픽이 직접 연결된다는 뜻은 아닙니다. 경로를 통일하려면 브라우저의 독립 확인을 끄거나 해당 업스트림도 규칙으로 올바르게 처리하세요.

현상별 DNS 문제 진단

“도메인은 열리지 않지만 IP로는 직접 접속 가능”하면 확인 업스트림과 수신 포트를 먼저 점검하세요. “첫 접속은 느리지만 새로 고치면 정상”이면 업스트림 연결, 캐시와 IPv6 시간 초과를 확인합니다. “일부 로컬 네트워크 기기를 찾지 못함”이면 Fake-IP 필터를 확인하세요. “로그에 IP만 표시되고 도메인 규칙이 매칭되지 않음”이면 애플리케이션이 DNS를 우회하는지, 스니핑이 활성화되어 있는지, 투명 프록시가 해당 연결을 캡처했는지 확인합니다. 수정 후 시스템과 브라우저 DNS 캐시를 지우고 대상 애플리케이션을 다시 시작해 기존 연결의 영향을 제거하세요.

현상 우선 확인할 항목 다음 단계
모든 도메인 확인 실패 DNS 수신 설정, 업스트림 접근성 로컬 조회 명령으로 수신 포트를 지정해 테스트
노드 도메인만 실패 proxy-server-nameserver 직접 연결로 노드 도메인을 확인할 수 있는 업스트림으로 변경
로컬 네트워크 서비스 이상 fake-ip-filter 해당 도메인에 맞춰 제외 항목 추가
도메인 규칙이 매칭되지 않음 조회가 커널로 들어오는지 확인 브라우저 DoH, 스니핑과 TUN 캡처 확인

CHAPTER 04

TUN과 Fake-IP

시스템 프록시는 프록시 설정을 능동적으로 읽는 애플리케이션에만 영향을 줍니다. 명령줄 프로그램, 일부 게임, 가상 머신과 자체 네트워크 스택을 사용하는 소프트웨어는 이를 완전히 무시할 수 있습니다. TUN 모드는 시스템에 가상 네트워크 인터페이스를 만들고 라우팅을 통해 더 많은 TCP·UDP 트래픽을 커널로 전달하므로 투명한 트래픽 인계가 필요한 환경에 적합합니다. TUN은 트래픽 유입을, Fake-IP는 도메인 매핑을 해결합니다. 함께 사용하는 경우가 많지만 같은 기능은 아닙니다.

설정 전에 라우팅 충돌부터 제외하세요

TUN을 시작하려면 가상 인터페이스를 만들고 라우팅을 설정하며 DNS를 인계해야 하므로 보통 시스템 권한이 필요합니다. 클라이언트 화면에 TUN이 켜졌다고 표시되는데도 대상 애플리케이션이 직접 연결된다면 먼저 가상 인터페이스의 존재를 확인하고, 기본 라우팅과 제외 라우팅이 적용되었는지 점검하세요. VPN, 가상 머신, 컨테이너, 게임 가속기와 다른 프록시 프로그램이 동시에 라우팅을 수정할 수 있습니다. 문제를 찾을 때는 유사한 도구를 먼저 종료하고 하나의 트래픽 인계 프로그램만 남기세요.

auto-route는 커널이 라우팅을 자동으로 구성하게 하며 일반적인 데스크톱 사용에 적합합니다. auto-detect-interface는 실제 아웃바운드 네트워크 카드를 식별해 프록시 트래픽이 다시 TUN으로 들어가는 루프를 방지합니다. 유선에서 무선으로, 가정 네트워크에서 핫스팟으로 전환하면 이전 인터페이스 정보가 무효화될 수 있습니다. 네트워크 전환 후 갑자기 모든 연결이 시간 초과되면 노드를 즉시 바꾸기보다 TUN이나 클라이언트를 다시 시작해 인터페이스를 재탐색하세요.

tun:
  enable: true
  stack: mixed
  device: Mihomo
  auto-route: true
  auto-redirect: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53
  strict-route: true
  mtu: 1500

stack은 TUN 데이터가 사용자 공간 네트워크 스택으로 들어가는 방식을 결정합니다. mixed는 일반적으로 TCP와 UDP를 함께 사용하는 데스크톱 환경에 적합합니다. 특정 시스템에서 호환성 문제가 생기면 클라이언트가 지원하는 범위에서 다른 스택과 비교하되 한 번에 이 항목만 변경하세요. strict-route는 트래픽 경로를 더 엄격하게 제한해 우회를 줄일 수 있지만 로컬 네트워크, 가상 네트워크 카드와 다중 네트워크 카드 환경에 영향을 줄 수 있습니다. 활성화한 직후 게이트웨이, 로컬 네트워크 기기와 주요 서비스를 테스트하세요.

DNS 하이재킹은 수신 설정과 맞춰야 합니다

dns-hijack는 TUN을 통과하는 일반적인 53번 포트 조회를 내장 DNS로 전달합니다. 애플리케이션이 자체적으로 시작한 DoH를 직접 해독할 수 없고 TUN을 거치지 않은 조회까지 인계한다고 보장할 수도 없습니다. 하이재킹을 설정했지만 dns.enable이 꺼져 있거나 수신 주소가 충돌하면 모든 도메인이 작동하지 않는 것처럼 보일 수 있습니다. 이때는 규칙을 먼저 건드리지 말고 DNS 모듈이 시작되었는지, 포트를 다른 서비스가 사용 중인지 확인하세요.

Fake-IP 주소 풀은 보통 별도의 예약 범위를 사용합니다. 애플리케이션이 해당 주소를 확인한 뒤 연결이 동일한 커널을 계속 통과해야 커널이 매핑 테이블에서 도메인을 복원할 수 있습니다. Clash가 DNS 조회에 Fake-IP를 반환했지만 이후 연결이 TUN이나 시스템 프록시를 우회하면 애플리케이션은 라우팅할 수 없는 예약 주소에 직접 접속하게 되어 “확인은 되지만 연결 실패”가 발생합니다. 이 문제는 DNS 업스트림을 바꿀 것이 아니라 트래픽 유입 경로가 일치하는지 확인해야 합니다.

MTU와 UDP는 흔한 경계 문제입니다

웹페이지는 열리지만 대용량 파일, 이미지 또는 일부 TLS 연결이 멈춘다면 MTU를 고려해야 합니다. 가상 인터페이스 캡슐화는 추가 오버헤드를 만들고 하위 네트워크는 더 작은 유효 MTU를 사용할 수 있습니다. 먼저 특정 네트워크에서만 발생하는지 확인한 뒤 TUN의 MTU를 조금씩 낮춰 테스트하세요. 한 번에 너무 작게 낮추지 마세요. 값이 너무 낮으면 조각화와 처리 오버헤드가 늘고, 너무 높으면 경로 중 블랙홀을 만날 수 있습니다.

게임, 음성 통화와 QUIC은 UDP에 의존합니다. TUN이 UDP를 캡처한다고 해서 노드 프로토콜과 출구가 반드시 지원하는 것은 아닙니다. 확인 순서는 로그에 UDP 연결이 나타나는지, 규칙이 올바른 정책에 매칭되는지, 선택한 노드가 UDP를 지원하는지, 시스템 방화벽이 가상 인터페이스를 허용하는지입니다. 브라우저 페이지에 문제가 있을 때는 QUIC을 임시로 끄고 TCP 경로가 정상인지 비교할 수 있지만, 이는 원인 확인용이며 장기 해결책으로 사용해서는 안 됩니다.

플랫폼별 주요 확인 항목

Windows에서는 드라이버 권한, 시스템 서비스와 다른 VPN 가상 네트워크 카드를 확인하세요. macOS에서는 네트워크 확장 권한과 시스템 네트워크 서비스 순서를 확인합니다. Linux에서는 TUN 장치 권한, 정책 라우팅, 포워딩과 방화벽 규칙을 확인하세요. Android와 iOS의 Clash 계열 클라이언트는 보통 시스템 VPN 인터페이스로 트래픽을 인계하며, 시스템에서는 동시에 하나의 주요 VPN 세션만 허용됩니다. 다른 VPN을 켜면 현재 연결이 교체될 수 있습니다. 적합한 클라이언트를 선택하려면 다운로드 센터에서 플랫폼별 목록을 확인하세요. Clash Plus는 모든 플랫폼에 우선 추천되는 항목입니다.

CHAPTER 05

도메인 스니핑

애플리케이션이 IP에 직접 연결하거나 캐시된 결과를 사용하거나 DNS 조회가 Clash를 거치지 않으면 규칙 단계에서 대상 IP만 보일 수 있습니다. 도메인 스니핑은 연결 초기 데이터에서 호스트 이름을 추출합니다. 예를 들어 TLS 핸드셰이크의 SNI나 HTTP 요청의 Host를 가져와 규칙 시스템에 전달합니다. 이는 라우팅 근거를 보완하는 기능이지 모든 암호화 콘텐츠를 해석하는 기능은 아니며, 모든 프로토콜에서 도메인을 복원한다고 보장할 수도 없습니다.

스니핑을 활성화해야 하는 경우

로그에 IP만 계속 표시되어 DOMAIN, DOMAIN-SUFFIX와 도메인 규칙 제공자가 매칭되지 않을 때 스니핑이 유용합니다. Fake-IP를 사용하면 커널이 이미 도메인을 알고 있는 경우가 많아 필요성이 낮아지지만, 내장 DNS를 우회하는 연결에는 도움이 될 수 있습니다. “기능이 더 많다”는 이유만으로 모든 포트를 무조건 활성화하지 말고, 먼저 문제가 되는 연결의 프로토콜과 포트를 확인한 뒤 캡처 범위를 정하세요.

sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true
  override-destination: false
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
      override-destination: true
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443
  skip-domain:
    - Mijia Cloud
    - "+.push.apple.com"

parse-pure-ip는 순수 IP를 대상으로 하는 연결에서 도메인 추출을 시도하게 합니다. force-dns-mapping은 기존 DNS 매핑을 함께 사용하며, override-destination은 스니핑으로 얻은 도메인으로 원래 대상을 바꿀지 결정합니다. 대상을 덮어쓰면 도메인 규칙이 적용될 수 있지만 고정 IP, 인증서 검증 또는 사설 프로토콜을 사용하는 일부 애플리케이션에는 부작용이 생길 수 있습니다. 먼저 프로토콜별 설정에서 덮어쓰기를 활성화하고 처음부터 전역 적용하지 않는 것이 좋습니다.

HTTP 스니핑은 평문 요청 헤더에 의존하고, TLS 스니핑은 핸드셰이크 단계에서 보이는 SNI를 읽으며, QUIC은 프로토콜 구현과 암호화된 핸드셰이크의 영향을 받습니다. ECH 같은 메커니즘은 기존 SNI를 숨겨 스니핑이 대상 도메인을 얻지 못하게 할 수 있습니다. 이는 설정 오류가 아니라 연결에 추출 가능한 평문 식별자가 없기 때문입니다. 이때는 DNS 조회를 커널로 전달하거나 명확한 IP, 프로세스와 규칙 제공자 정책으로 보완하세요.

skip-domain으로 호환성 문제 처리하기

로컬 네트워크 기기 검색, 푸시 서비스, 시스템 연결 확인과 일부 게임은 대상 변경에 적합하지 않을 수 있습니다. “스니핑을 끄면 정상인데 켜면 특정 애플리케이션만 실패”한다면 먼저 로그에서 스니핑으로 얻은 도메인을 확인한 뒤 해당 도메인을 skip-domain에 추가하세요. 제외 범위는 최대한 좁게 유지하고, 너무 넓은 최상위 접미사는 사용하지 마세요. 정상 연결 다수가 도메인 규칙 기능을 잃을 수 있습니다.

일부 클라이언트는 그래픽 인터페이스의 오버라이드 설정에 스니핑 옵션을 두므로 구독을 업데이트해도 변경되지 않습니다. 다른 클라이언트는 설정 파일을 직접 읽습니다. 문제를 해결하기 전에 구독 원문이 아니라 최종 적용 설정을 확인하세요. 클라이언트에 “실행 설정” 또는 “현재 설정”을 보는 메뉴가 있다면 그 내용을 기준으로 삼아야 합니다. 로컬 오버라이드가 이미 sniffer를 수정했을 수 있으므로 구독 파일을 직접 편집해도 효과가 없을 수 있습니다.

스니핑이 실제 라우팅에 참여하는지 확인하기

로그에 IP만 표시되는 대상을 하나 선택하고 기존 연결을 지운 뒤 요청을 다시 시작하세요. 원래 대상, 스니핑 도메인, 매칭 규칙과 최종 정책을 차례로 기록합니다. 도메인이 보인다고 해서 규칙이 반드시 그 도메인을 사용한 것은 아닙니다. 매칭 항목이 IP 규칙에서 예상한 도메인 규칙으로 바뀌었는지도 확인해야 합니다. 도메인은 올바른데 기본 규칙이 매칭된다면 규칙 순서와 접미사 표기를 점검하세요. 스니핑 도메인이 잘못되었다면 먼저 대상 덮어쓰기를 끄고 해당 도메인이나 애플리케이션을 제외 목록에 추가하세요.

프로세스 규칙은 데스크톱에서 보완 수단으로 사용할 수 있지만 운영체제마다 프로세스 식별 지원과 권한이 다릅니다. 프로세스 이름도 런처, 하위 프로세스나 샌드박스에 따라 달라질 수 있으므로 모든 업무를 프로세스에 연결해서는 안 됩니다. 안정적인 트래픽 분배는 도메인 규칙을 중심으로 하고, IP와 프로세스 규칙은 도메인을 얻을 수 없는 일부 연결을 보완하는 데 사용하세요.

CHAPTER 06

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

원격 구독은 노드와 기본 정책을 제공하는 데 적합하지만 장기간 수동 편집하는 공간으로는 적합하지 않습니다. 클라이언트가 구독을 업데이트하면 설정을 다시 생성하는 경우가 많아 구독 파일에 직접 작성한 DNS, 규칙과 정책 그룹이 덮어써질 수 있습니다. 로컬 오버라이드의 목적은 “업스트림이 업데이트를 담당하는 내용”과 “이 장치에 장기간 보존할 내용”을 분리하는 것입니다. 수정하기 전에 클라이언트가 필드 오버라이드, 스크립트 처리, 설정 조각 병합 또는 전체 설정 관리를 지원하는지 확인하세요. 이름은 비슷해도 병합 순서는 다릅니다.

먼저 최종 설정 생성 순서를 확인하세요

일반적인 흐름은 원격 구독을 읽고, 노드와 정책 그룹을 파싱한 다음, 로컬 선행 스크립트나 조각을 적용하고 실행 설정에 기록하는 방식입니다. 일부 클라이언트는 로컬 규칙을 구독 규칙 앞에 추가하고, 일부는 뒤에 추가합니다. 같은 이름의 키를 덮어쓰는 클라이언트가 있는가 하면 배열을 이어 붙이는 클라이언트도 있습니다. 순서를 모르면 새 규칙이 MATCH 뒤에 놓여 영원히 매칭되지 않을 수 있고, 같은 이름의 정책 그룹이 노드 하나만 추가되는 대신 전체 교체될 수도 있습니다.

가장 확실한 확인 방법은 세 가지를 비교하는 것입니다. 원격 구독 원문, 로컬 오버라이드 내용과 클라이언트의 최종 실행 설정입니다. 편집기의 조각만 봐서는 적용 여부를 증명할 수 없습니다. 수정할 때마다 대상 필드를 검색해 최종 설정에 한 번만 나타나는지, 계층이 올바른지, 참조 대상이 존재하는지 확인하세요. 특히 YAML에서 배열과 객체의 차이에 주의해야 합니다. rules와 proxies는 순서가 있는 목록이고 dns와 tun은 보통 키-값 객체이므로 잘못된 병합 전략이 의미를 직접 바꿀 수 있습니다.

prepend-rules:
  - DOMAIN-SUFFIX,example.internal,DIRECT
  - PROCESS-NAME,backup-client,DIRECT

append-proxies:
  - name: 로컬 출구
    type: socks5
    server: 127.0.0.1
    port: 1081

override:
  ipv6: false
  log-level: info

위 예시는 일반적인 오버라이드 의도를 보여주는 것이며, 조각 파일의 필드 이름은 클라이언트마다 다르므로 실제 안내를 따라야 합니다. 일반적인 Clash 설정에는 최상위 필드 prepend-rules가 없으므로 오버라이드 도구의 문법을 config.yaml에 그대로 복사하면 안 됩니다. 설정 오류를 진단할 때 첫 단계는 “커널 기본 필드”와 “클라이언트 병합기 필드”를 구분하는 것입니다.

다중 구독 병합은 먼저 이름 충돌을 처리해야 합니다

두 구독에 “자동 선택”, “프록시 선택” 같은 정책 그룹이 동시에 있거나 같은 이름의 노드가 포함될 수 있습니다. 단순히 이어 붙이면 이름이 중복되거나 참조가 어긋나고 뒤의 설정이 앞의 설정을 덮어쓸 수 있습니다. 병합 전 출처에 안정적인 접두사를 붙이세요. 예를 들어 “업무”, “예비”처럼 용도를 표시한 뒤 자체 상위 정책 그룹을 구성합니다. 상위 규칙은 직접 만든 그룹만 참조하고 업스트림에서 언제든 바뀔 수 있는 그룹에는 직접 의존하지 않아야 특정 구독을 업데이트해도 전체 규칙에 영향을 주지 않습니다.

노드 이름은 참조 키이자 필터 기준입니다. 서로 다른 구독에서 같은 이름의 노드가 들어오면 서버가 달라도 정책 그룹에서 구분하기 어렵습니다. 이름 변경은 노드가 정책 그룹에 들어가기 전에 완료하고 지역, 용도와 출처 정보를 짧고 명확하게 유지하세요. 구독 만료일이나 잔여 트래픽처럼 동적인 문구를 장기 필터 조건에 넣지 마세요. 업스트림이 문구를 업데이트하면 정규식이 예상치 않게 매칭될 수 있습니다.

proxy-groups:
  - name: 전체 출구
    type: select
    proxies:
      - 주 구독 자동 선택
      - 예비 구독 자동 선택
      - DIRECT

  - name: 주 구독 자동 선택
    type: url-test
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 600

  - name: 예비 구독 자동 선택
    type: fallback
    use:
      - provider-backup
    url: https://www.gstatic.com/generate_204
    interval: 600

오버라이드 범위가 작을수록 업데이트 비용이 낮습니다

장기 오버라이드에는 이 장치에 실제로 필요한 내용만 남기는 것이 좋습니다. 로컬 네트워크 직접 연결 규칙, DNS 선택, TUN 매개변수, 자체 정책 그룹과 소수의 업무 예외 정도입니다. 업스트림 설정 전체를 복사해 수정하지 마세요. 구독 업데이트에 따른 노드 변경을 잃게 됩니다. 전체 설정을 관리해야 한다면 구독을 노드 provider로 낮추고 프록시 노드만 읽도록 하며, 모든 정책과 규칙은 로컬 설정이 담당하게 하세요.

병합에 실패하면 세 계층으로 나누어 확인하세요. 문법 계층에서는 YAML 들여쓰기, 목록 기호와 중복 키를 봅니다. 참조 계층에서는 정책 그룹, provider와 규칙 이름이 존재하는지 확인합니다. 실행 계층에서는 클라이언트가 생성된 설정을 실제로 선택했는지 확인합니다. 설정은 로드되지만 노드가 비어 있다면 대개 provider나 필터 문제입니다. 설정을 로드할 수 없다면 중복 이름과 알 수 없는 필드를 먼저 확인하세요. 업데이트 후 로컬 설정이 사라졌다면 오버라이드 실행 순서나 저장 위치가 잘못된 것입니다.

더 많은 자동 처리를 추가하는 것보다 되돌릴 지점을 마련하는 일이 중요합니다. 검증이 끝난 기본 설정을 보관하고 각 로컬 조각의 용도를 기록한 뒤 수정 후 다시 불러오기 테스트를 실행하세요. 클라이언트를 업데이트하거나 장치를 이전할 때는 먼저 기본 설정을 로드해 커널과 네트워크가 정상인지 확인한 다음 오버라이드를 하나씩 복원합니다. 플랫폼별 클라이언트는 다운로드 센터에서 선택하고, 최초 이전 절차는 사용 가이드를 참고하세요.

CHAPTER 07

외부 제어 패널

외부 제어 인터페이스는 연결, 로그, 규칙과 정책 그룹 상태를 읽고 정책 전환, 연결 종료 또는 설정 다시 불러오기도 수행할 수 있습니다. 이는 문제 해결 도구이며 트래픽 전달 입구가 아닙니다. 제어 패널은 커널이 제공하는 API를 호출할 뿐, 페이지 자체가 커널을 대신하거나 설정을 자동으로 복구하지 않습니다. 화면에 오프라인으로 표시되면 먼저 제어 주소와 인증을 확인하고, 이어서 커널 프로세스가 실행 중인지 확인하세요.

수신 주소가 노출 범위를 결정합니다

external-controller는 제어 인터페이스의 수신 주소를 지정합니다. 로컬에서만 사용할 때는 127.0.0.1에 바인딩하는 것이 우선입니다. 0.0.0.0에 바인딩하면 같은 네트워크의 다른 장치가 해당 포트에 접근할 수 있으므로 접근 제어와 방화벽을 반드시 함께 설정해야 합니다. 브라우저 페이지 연결을 위해 수신 범위를 바로 넓히지 마세요. 먼저 패널과 커널이 같은 장치에 있는지 확인하고, 같은 장치라면 루프백 주소를 사용하는 것이 가장 간단합니다.

external-controller: 127.0.0.1:9090
secret: "replace-with-a-long-random-string"
external-ui: ./ui
external-ui-name: dashboard
external-ui-url: https://example.com/dashboard.zip

secret은 제어 인터페이스의 인증 정보이며 패널 연결 시 동일한 내용을 입력해야 합니다. 수정하면 기존 패널이 즉시 접근 권한을 잃는데 이는 정상입니다. 인증 실패는 보통 인터페이스에는 접근할 수 있지만 정책이나 연결 정보를 읽지 못하는 형태로 나타납니다. 제어 키를 공개 페이지, 스크린샷이나 공유 설정에 기록하지 마세요. 다른 사람에게 진단 정보를 제공할 때는 제어 주소, 인증 필드, 구독 주소와 노드 자격 증명을 삭제해야 합니다.

external-ui는 로컬 정적 패널 디렉터리를 가리키고, external-ui-url은 패널 파일을 가져오는 데 사용할 수 있습니다. 커널 API와 패널 파일은 별개입니다. API는 정상인데 페이지가 비어 있다면 UI 파일 경로가 잘못되었을 수 있고, 페이지는 열리지만 데이터가 없다면 제어 주소, 교차 출처 설정 또는 인증 오류일 수 있습니다. 따로 테스트해야 문제가 어느 계층에 있는지 확인할 수 있습니다.

장치 간 접근에는 추가 제한이 필요합니다

정말로 로컬 네트워크의 다른 장치에서 접근해야 한다면 수신 주소를 로컬 네트워크에서 접근 가능한 인터페이스로 바꾸고 시스템 방화벽에서 신뢰할 수 있는 네트워크 대역만 해당 포트에 접근하도록 허용하세요. 라우터 포트 포워딩과 공개망 수신은 위험을 크게 넓히므로 일반적인 원격 관리 방식으로 사용해서는 안 됩니다. 더 안전한 방법은 통제된 사설 네트워크나 로컬 터널을 통해 루프백 인터페이스에 접근하고 인증을 유지하는 것입니다.

브라우저 패널은 HTTP 또는 WebSocket으로 제어 인터페이스에 연결합니다. 패널이 HTTPS를 사용하고 제어 인터페이스가 일반 HTTP라면 브라우저가 혼합 콘텐츠를 차단할 수 있습니다. 이때 브라우저 보안 제한을 끄지 말고 패널과 API가 동일한 통제된 진입점을 통해 접근하도록 하세요. WebSocket이 반복해서 끊기면 리버스 프록시가 업그레이드 헤더를 올바르게 전달하는지, 시스템 절전이 커널을 일시 중지하지 않았는지, 방화벽이 유휴 연결을 정리하지 않는지도 확인해야 합니다.

패널을 이용해 요청을 계층별로 확인하기

연결 목록에서는 최소한 네 가지를 확인해야 합니다. 대상 도메인 또는 IP, 매칭 규칙, 정책 체인과 최종 노드입니다. 도메인이 비어 있으면 DNS와 스니핑 장으로 돌아가고, 규칙이 잘못되었으면 규칙 순서를 확인하세요. 정책 체인은 올바른데 최종 노드가 이상하면 정책 그룹의 현재 선택을 확인합니다. 모든 정보가 올바른데 연결에 실패할 때만 노드 핸드셰이크, UDP 지원과 로컬 네트워크를 확인하세요. 이 순서를 지키면 “시간 초과”만 보고 모든 설정을 바꾸는 일을 피할 수 있습니다.

규칙 페이지에서는 보통 provider가 로드되었는지와 규칙 수가 존재하는지 확인할 수 있지만, 수량만으로 품질을 판단하지 마세요. 연결 로그가 더 중요합니다. 고정 대상을 하나 선택하고 기존 연결을 종료한 뒤 한 번 요청하여 도메인부터 출구까지의 전체 경로를 확인하세요. 일상적인 진단에는 로그 수준 info면 충분합니다. 핸드셰이크와 규칙 세부 정보가 필요할 때만 잠시 debug로 전환하고 완료 후 되돌려 중요한 이벤트가 많은 로그에 묻히지 않게 하세요.

패널에서 정책을 바꿔도 기존 장기 연결이 새 노드로 즉시 이동하지 않을 수 있습니다. 출구를 확인할 때는 해당 기존 연결을 종료하고 필요하면 대상 애플리케이션을 다시 시작한 뒤 새 요청을 보내세요. 브라우저 탭, 다운로드 작업과 메신저는 연결 풀을 유지하므로 정책 그룹 화면만 바뀌었다고 현재 요청이 새 출구를 사용한다고 단정할 수 없습니다.

반복 가능한 종합 문제 해결 경로를 마련하세요

설정을 여러 번 수정한 뒤에는 먼저 현재 실행 설정과 최근 로그를 내보내세요. 그다음 TUN을 끄고 시스템 프록시만 남겨 기본 노드 연결을 확인합니다. DNS를 활성화해 고정 도메인 확인을 점검하고, 이어서 규칙 제공자를 복원해 매칭을 확인한 뒤 Fake-IP, 스니핑과 TUN을 순서대로 켭니다. 각 계층을 복원할 때 같은 테스트 대상을 사용하세요. 특정 단계에서 실패가 시작되면 문제는 방금 복원한 계층 또는 이전 계층과의 경계에 있습니다.

일부 노드만 시간 초과되면 노드 연결 시간 초과 문제 해결 순서를 확인하세요. 전체 속도가 느려졌다면 속도 저하 계층별 진단을 참고해 노드, 회선과 로컬 설정을 구분합니다. 설정 파일 로드에 실패했다면 문법과 참조 관계로 돌아가야 하며, 연결 문제 해결 글의 노드 교체 절차를 확인 오류에 적용하지 마세요.