고급 활용법 기본 설정으로는 부족할 때

설정 파일을
제대로 활용하기.

초보자 가이드를 마친 분들을 위해, 설정 파일을 더 깊이 활용할 수 있는 여섯 가지 방향을 소개합니다: 프록시 그룹의 자동 속도 테스트와 장애 복구, 규칙 세트의 구독 방식 관리, DNS와 도메인 스니핑 최적화, LAN 공유 게이트웨이, 여러 구독의 로컬 오버라이드, 외부 패널을 통한 설정 관리. 각 섹션에는 바로 사용할 수 있는 YAML 스니펫이 포함되어 있습니다.

프록시 그룹 고급 활용법

프록시 그룹은 규칙이 매칭된 후 실제로 어떤 노드를 사용할지 결정합니다. 적절히 조합하면 자동 속도 테스트, 장애 복구, 부하 분산을 구현할 수 있습니다.

유형	동작	적합한 상황
select	목록에서 수동으로 노드를 선택하며 자동 전환은 없음	특정 노드를 장기간 고정해서 사용해야 할 때
url-test	일정한 주기로 속도를 테스트해 지연이 가장 낮은 노드를 자동 선택	항상 낮은 지연을 유지하고 싶지만 수동 전환은 피하고 싶을 때
fallback	목록의 첫 번째 사용 가능한 노드를 사용하고, 실패 시 자동으로 다음 노드로 전환	메인 노드가 불안정해 자동 장애 복구가 필요할 때
load-balance	정책(라운드로빈 / 일관성 해시)에 따라 여러 노드에 연결을 분산	노드 수가 충분하고 대역폭 부하를 분산하고 싶을 때

proxy-groups.yaml

proxy-groups:
  # 자동 속도 측정, 지연이 가장 낮은 노드 선택
  - name: Auto
    type: url-test
    proxies: [HK-01, HK-02, SG-01]
    url: http://www.gstatic.com/generate_204
    interval: 300      # 300초마다 속도 측정
    tolerance: 50      # 지연 차이가 50ms 미만이면 전환하지 않음, 흔들림 방지
  # 메인 그룹에 문제가 생기면 순서대로 자동으로 백업으로 전환
  - name: Fallback
    type: fallback
    proxies: [Auto, HK-01, SG-01]
    url: http://www.gstatic.com/generate_204
    interval: 180
  # 규칙에 노출되는 최종 진입점, 언제든 수동 전환 가능
  - name: PROXY
    type: select
    proxies: [Auto, Fallback, HK-01, SG-01, DIRECT]

팁: 규칙에서는 보통 가장 바깥쪽의 select 그룹(위 예시의 PROXY 등)만 참조하며, 속도 테스트와 장애 복구 로직은 그 후보 목록 안에 캡슐화되어 있습니다. 규칙 자체는 어떤 노드를 사용할지 신경 쓸 필요가 없습니다.

규칙 세트로 구독 방식 규칙 관리하기

Rule Provider는 수백~수천 개의 규칙을 독립된 파일로 호스팅하며 주기적으로 자동 업데이트되어, 하나씩 수동으로 관리할 필요가 없습니다.

behavior는 규칙 세트에 저장된 데이터 유형을 결정합니다: domain(도메인 목록), ipcidr(IP 범위 목록), classical(완전한 규칙 문법 라인). type은 소스를 결정합니다: http는 원격 구독으로 interval에 따라 자동 업데이트되며, file은 로컬 파일로 직접 관리해야 합니다.

rule-providers.yaml

rule-providers:
  reject:
    type: http
    behavior: domain
    url: https://example.com/reject.txt
    path: ./ruleset/reject.yaml
    interval: 86400   # 24시간마다 자동 업데이트
  direct:
    type: http
    behavior: classical
    url: https://example.com/direct.txt
    path: ./ruleset/direct.yaml
    interval: 86400

rules:
  # 규칙 세트 참조, 작성 방식은 RULE-SET,규칙세트이름,정책
  - RULE-SET,reject,REJECT
  - RULE-SET,direct,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

팁: ACL4SSR, blackmatrix7 시리즈 등 인기 공개 규칙 세트는 광고 차단, 로컬 네트워크 직접 연결, 자주 쓰는 앱 라우팅 등 다양한 목록을 이미 관리하고 있으니, 특별한 요구가 없다면 바로 참조해서 사용하면 됩니다.

DNS 설정 최적화

DNS 해석 방식은 규칙 매칭 정확도와 접속 속도에 직접적인 영향을 미치므로, 고급 설정 중 가장 시간을 들일 만한 항목입니다.

enhanced-mode는 fake-ip를 추천합니다: 클라이언트가 먼저 가상 IP를 반환하고, 연결이 성립될 때 실제 도메인을 복원해 규칙 매칭에 사용하므로 속도와 정확성을 모두 확보할 수 있습니다. fallback-filter를 사용하면 DNS 결과가 로컬 ISP의 IP 대역에 속하지 않을 때만 채택하도록 해 DNS 오염이나 하이재킹을 감지하고 방지할 수 있습니다.

dns.yaml

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver: [223.5.5.5, 119.29.29.29]   # DoH/DoT 도메인 자체를 해석하기 위한 기본 DNS
  nameserver: ['https://doh.pub/dns-query', 'tls://dot.pub:853']
  fallback: ['https://1.1.1.1/dns-query', 'https://dns.google/dns-query']
  fallback-filter:
    geoip: true
    geoip-code: CN   # 지정한 지역 밖의 IP일 때만 fallback 결과 사용(CN은 예시이며 자신의 지역으로 바꿀 것)

팁: fake-ip를 활성화한 후 일부 LAN 기기(스마트 스피커, NAS 검색 등)에 문제가 발생하면, fake-ip-filter에 해당 도메인을 예외로 추가해 항상 실제 IP를 반환하도록 설정할 수 있습니다.

도메인 스니핑(Sniffer) 활성화

TUN 모드에서는 일부 연결에 대상 IP만 있고 도메인 정보가 없는 경우가 있습니다. 스니핑은 트래픽에서 실제 도메인을 복원해 도메인 기반 규칙을 계속 적용할 수 있게 합니다.

Sniffer는 트래픽 내용을 복호화하지 않고, TLS 핸드셰이크의 SNI나 HTTP 요청 헤더의 Host 같은 평문 필드를 읽어 대상 도메인을 판단한 후 규칙 모듈로 전달합니다. TUN 모드나 도메인 정보가 전달되지 않는 일부 전달 상황에서 자주 사용됩니다.

sniffer.yaml

sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true
  sniff:
    TLS:
      ports: [443, 8443]
    HTTP:
      ports: [80, 8080]
    QUIC:
      ports: [443]

다른 기기와 LAN 공유하기

Clash를 실행 중인 기기를 LAN 내 프록시 게이트웨이로 만들어, 클라이언트를 개별 설치하기 어려운 스마트폰, 태블릿, 스마트 TV 등의 기기도 프록시를 공유할 수 있게 합니다.

allow-lan을 활성화하고 리스닝 주소를 0.0.0.0 또는 구체적인 LAN IP로 변경하세요.
다른 기기의 Wi-Fi 설정에서 HTTP / SOCKS 프록시를 Clash를 실행 중인 기기의 LAN IP와 mixed-port로 지정하세요.
기기의 모든 트래픽(브라우저뿐 아니라)을 커버해야 한다면, 해당 기기를 라우터로 설정하거나 라우터에서 정책 기반 라우팅을 설정하는 것을 고려해 보세요.

lan.yaml

mixed-port: 7890
allow-lan: true
bind-address: '*'
authentication:
  # LAN 공유 시 계정과 비밀번호를 추가해 같은 네트워크의 다른 기기가 무단으로 사용하는 것을 방지하는 것을 권장
  - user1:strong-password

팁: LAN 공유를 활성화한 후에는 시스템 방화벽이 해당 포트로의 인바운드 연결을 허용하는지 확인하고, 인증용 사용자 이름과 비밀번호를 먼저 설정해 공공 Wi-Fi 환경에서 알 수 없는 기기가 접속하는 것을 방지하세요.

여러 구독 통합 및 로컬 오버라이드

구독에서 가져온 설정 파일을 직접 수정하면 다음 업데이트 시 프로바이더가 반환하는 새 내용으로 덮어씌워집니다. 오버라이드 기능을 사용해 커스텀 부분을 별도로 유지해야 합니다.

대부분의 GUI 클라이언트(Clash Verge, Clash for Windows 계열)에는 "Override(오버라이드)" 또는 "설정 통합" 기능이 있습니다: 구독에서 생성된 기본 설정을 불러온 후, 직접 관리하는 로컬 YAML 스니펫을 덧붙여 적용합니다. 두 설정이 통합된 상태로 실제 반영됩니다. 구독 업데이트 시에는 기본 부분만 교체되고 오버라이드 스니펫은 영향을 받지 않습니다.

클라이언트의 구독 설정에서 Override(오버라이드) 항목을 찾아 새 로컬 오버라이드 파일을 만드세요.
오버라이드 파일에는 추가하거나 변경하려는 필드만 작성하세요. 예를 들어 커스텀 rules, dns, proxy-groups 등입니다.
저장 후에는 클라이언트가 구독을 불러올 때마다 이 오버라이드를 자동으로 덧붙여 적용하므로, 구독을 업데이트해도 커스텀 내용이 사라지지 않습니다.

여러 프로바이더의 구독이 있다면, 통합 기능을 사용해 모든 노드를 하나의 규칙과 프록시 그룹으로 묶어 한꺼번에 관리할 수도 있습니다.

외부 제어 패널로 설정 관리하기

RESTful API를 활성화하면 브라우저 패널(yacd, metacubexd 등)로 연결을 실시간으로 확인하고, 노드를 전환하고, 설정을 핫 리로드할 수 있어 변경할 때마다 클라이언트를 재시작할 필요가 없습니다.

대부분의 GUI 클라이언트에는 이런 종류의 패널이 이미 내장되어 있습니다. 순수 코어(Mihomo core)만 운영 중이라면, 수동으로 외부 제어를 활성화하고 오픈소스 패널 프로젝트와 함께 사용할 수 있습니다.

external-controller.yaml

external-controller: 127.0.0.1:9090
secret: 'replace-with-a-strong-secret'   # 패널 접속 시크릿, 반드시 직접 변경하세요

팁: 리스닝 주소를 127.0.0.1로 유지하고 충분히 복잡한 secret을 설정하세요. 이 포트를 인터넷에 노출하지 않으면 설정에 대한 무단 접근이나 변조를 효과적으로 방지할 수 있습니다.

FAQ

고급 설정 자주 묻는 질문

오버라이드, DNS, 외부 패널에 관한 주요 질문

로컬 설정을 변경했는데 구독 업데이트 한 번에 사라지는 이유는 무엇인가요?

구독을 업데이트하면 프로바이더가 반환한 새 내용으로 설정 파일 전체가 덮어씌워져, 직접 변경한 필드는 원래대로 돌아갑니다. 클라이언트의 "Override(오버라이드)" 기능을 사용해 커스텀 부분을 별도로 관리하는 것을 추천합니다. 구독 업데이트 시에는 프로바이더 부분만 교체되고 오버라이드 부분은 이후 자동으로 다시 적용됩니다.

fake-ip와 redir-host 중 어떤 것을 선택해야 하나요?

fake-ip는 성능이 더 좋고 규칙 매칭을 위한 실제 대상 도메인을 더 빨리 식별할 수 있어 현재 주류로 추천됩니다. 다만 실제 IP 반환값에 의존하는 일부 상황(일부 LAN 기기 검색 프로토콜 등)에서는 redir-host나 특정 도메인에 대한 fake-ip 예외 설정이 필요할 수 있습니다.

외부 제어 패널을 활성화하면 안전에 문제가 있나요?

리스닝 주소를 127.0.0.1로 유지하고 충분히 복잡한 secret을 설정하면 위험은 매우 낮습니다. 외부 제어 포트를 0.0.0.0에 바인딩해 인터넷이나 신뢰할 수 없는 LAN에 노출하는 것은 권장하지 않습니다.

아직 기본 사용법에 익숙하지 않으신가요?

먼저 사용 가이드를 확인해 보세요: 설치, 구독 가져오기, 프록시 모드, 메인 화면을 자세히 설명합니다.

다운로드 페이지로 이동 →

Windows / macOS / Android / iOS / Linux 전 플랫폼 지원, 전부 무료.

설정 파일을 제대로 활용하기.