Clash 고급 설정 가이드

설정 계층과 편집 진입점

파라미터를 하나씩 조정하기 전에, 실제로 적용되는 설정이 어떤 계층으로 구성되는지 먼저 파악해야 합니다. 계층을 이해해야 내가 수정한 내용이 구독 업데이트로 덮어써질지, 커스텀 내용은 어느 계층에 넣어야 하는지 알 수 있습니다.

4개 설정 계층의 우선순위

Clash Verge의 런타임 설정은 4개 계층이 겹겹이 쌓여 구성되며, 낮은 순서에서 높은 순서로는 다음과 같습니다.

• 구독 설정:구독 링크에서 받아온 원본 YAML 또는 직접 가져온 로컬 파일입니다. 이 계층은 서비스 제공자나 사용자가 관리하며, 클라이언트가 구독을 업데이트할 때마다 새 내용으로 전체가 교체됩니다.
• 로컬 설정:클라이언트에 내장된 기본 조각으로, 보통 포트·모드 같은 필드만 제공합니다. 편집은 가능하지만 용도가 제한적입니다.
• 오버라이드 설정:구독 설정을 증분 수정하는 YAML로, prepend / append 병합 지시어를 지원합니다. 구독을 업데이트해도 오버라이드는 계속 적용되므로, 장기 사용에서 가장 중요한 커스텀 계층입니다.
• 스크립트 설정:병합이 끝난 최종 설정을 프로그래밍 방식으로 수정하는 JavaScript입니다. 조건 분기나 일괄 생성이 필요한 상황에 적합합니다.

런타임 최종 설정 = 구독 → 로컬 → 오버라이드 → 스크립트 순서로, 뒤 계층이 앞 계층의 동일 키를 덮어씁니다. "수정했는데 적용이 안 된다"는 문제가 보이면 이 체인을 따라 더 높은 계층이 값을 되돌려 놓은 건지 확인하세요.

설정 파일 위치와 백업

각 플랫폼의 기본 경로:

• Windows:%APPDATA%\clash-verge\profiles\
• macOS:~/Library/Application Support/io.github.clash-verge-rev.clash-verge-rev/profiles/
• Linux:~/.config/clash-verge/profiles/

각 구독은 UUID로 이름 붙은 디렉터리에 대응하며, 그 안의 config.yaml은 받아온 원본 내용, merge.yaml과 script.js는 각각 오버라이드와 스크립트입니다. 백업할 때는 profiles 디렉터리 전체를 복사하면 됩니다. 직접 수정이 필요하면 「설정」 페이지에서 해당 구독을 선택하고 「편집」을 눌러 오버라이드나 스크립트를 수정하는 것을 권장합니다. 받아온 config.yaml을 직접 고치면 다음 구독 업데이트 때 수정 내용이 모두 사라지기 때문입니다.

공통 필드 빠른 참조

다음 필드는 mihomo 코어가 직접 읽는 값으로, 설정 최상위에 작성하며 어떤 구독에서도 사용됩니다.

설정 예제 · 최상위 공통 필드

port: 7890              # HTTP 프록시 포트
socks-port: 7891        # SOCKS5 프록시 포트
allow-lan: false        # LAN 장치 연결 허용 여부
mode: rule              # rule / global / direct
log-level: info         # silent / error / warning / info / debug
ipv6: false             # IPv6 트래픽 처리 여부
external-controller: 127.0.0.1:9090
secret: ""              # API 접근 토큰

• mode: rule은 규칙 기반 분기, global은 전부 프록시, direct는 전부 직결입니다. 평소에는 rule을 유지하세요.
• log-level을 debug로 바꾸면 로그에 각 연결이 어떤 규칙에 매칭됐는지 표시되어 문제 해결에 유용합니다. 해결한 뒤에는 info로 되돌리는 걸 잊지 마세요.
• allow-lan을 켜면 같은 LAN의 휴대폰·태블릿에서 프록시를 이 PC로 지정할 수 있습니다. 단, 시스템 방화벽에서 해당 포트를 허용해야 합니다.

편집과 검증

YAML 편집을 마쳤으면 「설정」 페이지의 디버그 버튼을 누르거나 로그 창에 파싱 오류가 없는지 확인하세요. 흔한 오류는 세 가지입니다:들여쓰기에 Tab 사용(반드시 공백 사용), 콜론 뒤 공백 누락, 따옴표 미닫힘. mihomo의 오류 메시지는 줄 번호까지 정확히 알려주므로 해당 줄을 찾아가면 됩니다. 전체 설정의 섹션별 구조는 《Clash 설정 파일 YAML 구조 섹션별 해설》과 함께 읽어보세요.

프록시 그룹 유형과 실전 활용

프록시 그룹(proxy-groups)은 여러 노드 중 어떤 노드를 어떤 로직으로 선택할지 결정합니다. 규칙이 최종적으로 가리키는 대상은 단일 노드가 아니라 프록시 그룹인 경우가 많습니다. 그룹을 잘 구성하면 규칙 계층은 훨씬 단순해집니다.

5가지 내장 유형

select:수동 선택. 패널에서 원하는 노드를 클릭해 사용하며, "메인 노드"처럼 언제든 전환해야 하는 그룹에 적합합니다.

설정 예제 · select 그룹

- name: 메인
  type: select
  proxies:
    - 홍콩 01
    - 일본 01
    - 직결

url-test:자동 속도 측정. 주기적으로 모든 멤버에 테스트 요청을 보내 지연 시간이 가장 낮은 노드를 선택합니다. interval은 측정 간격(초), tolerance는 허용 오차(밀리초)입니다. 두 노드의 지연 차이가 허용 오차보다 작으면 현재 노드를 유지해 불필요한 전환을 막습니다.

fallback:목록 순서대로 사용하다가 현재 노드를 사용할 수 없게 되면 자동으로 다음 노드로 전환합니다. "특정 회선을 우선 사용하다가 장애 시에만 교체"하는 시나리오에 적합합니다.

load-balance:부하 분산. 연결을 여러 노드에 분산합니다. strategy는 consistent-hashing(같은 도메인은 같은 노드에 고정, 호환성 최고), round-robin(순환), sticky(세션 유지)를 지원합니다. 다운로드·대용량 트래픽에는 이 그룹으로 멀티 회선을 최대한 활용할 수 있습니다.

relay:체인 프록시. 트래픽이 그룹 순서대로 각 노드를 거쳐갑니다. 주로 "출발지-도착지" 조합에 사용합니다. relay는 프로토콜 지원이 제한적이라 일부 공급자 노드는 체인 전달을 지원하지 않으므로, 켜기 전에 패널에서 노드별로 검증하세요.

특수 그룹과 중첩

DIRECT와 REJECT는 프록시 그룹이 아니지만 proxies 목록에 넣을 수 있으며, 각각 직결과 거부를 뜻합니다. 프록시 그룹은 중첩할 수 있습니다. 바깥 그룹이 안쪽 그룹을 참조하고, 규칙은 가장 바깥 그룹만 가리키면 됩니다. mihomo는 include-all: true로 설정의 모든 노드를 자동 포함하고, include-other-group로 다른 그룹의 멤버를 참조할 수도 있습니다. 구독 노드가 자주 바뀌는 환경에서는 이 두 파라미터로 유지보수 부담을 크게 줄일 수 있습니다.

실전 템플릿 모음

설정 예제 · 스트리밍 / 게임 / 다운로드 3그룹 템플릿

proxy-groups:
  - name: 스트리밍
    type: url-test
    proxies: [홍콩 01, 홍콩 02, 일본 01]
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
  - name: 게임
    type: fallback
    proxies: [홍콩 01, 일본 01, 직결]
  - name: 다운로드
    type: load-balance
    proxies: [홍콩 01, 홍콩 02]
    strategy: consistent-hashing
  - name: 메인
    type: select
    proxies: [스트리밍, 게임, 다운로드, 직결]

• 스트리밍 그룹은 url-test로 가장 빠른 회선을 자동 선택하고, tolerance는 50ms로 두어 몇 ms 차이로 전환이 반복되며 재생이 끊기는 일을 방지합니다.
• 게임 그룹은 fallback을 사용합니다. 우선 회선의 지연이 높아져도 끊기지 않으면 url-test는 전환해버리지만, fallback은 정말 사용할 수 없을 때만 전환하므로 장기 연결에 더 유리합니다.
• 테스트 URL은 http://www.gstatic.com/generate_204를 사용하세요. 204를 반환해 트래픽이 발생하지 않습니다. 접근이 안 되면 http://cp.cloudflare.com/generate_204로 바꾸세요.

흔한 실수

• tolerance를 0으로 설정:지연 차이가 1ms만 나도 전환되어, 짧은 연결 위주 환경에서는 잦은 끊김이 발생합니다.
• select 그룹에 노드를 수십 개씩 나열:패널 선택 목록이 너무 길어집니다. 자동 그룹이 노드를 받아오도록 하고 select는 그룹만 참조하는 게 좋습니다.
• 기본으로 켜져 있는 lazy를 무시:선호 노드가 즉시 측정되지 않아 패널에 표시되는 지연 시간은 자리 표시자일 뿐입니다. 실제 값을 바로 확인하려면 수동으로 측정을 눌러야 합니다.
• 그룹 이름 대소문자 불일치:규칙에서 그룹 이름을 참조할 때 대소문자를 구분합니다. 잘못 써도 오류가 나지 않아 트래픽이 폴백 규칙으로 빠집니다.

룰셋 구독 관리

규칙(rules)은 설정에서 가장 쉽게 비대해지는 부분입니다. 수백 개의 규칙을 메인 설정에 직접 쓰면 읽기 어려울 뿐 아니라 구독 업데이트 때 함께 덮어써집니다. 룰셋(rule-providers)은 규칙을 별도 파일로 분리해 개별 업데이트하고, 메인 설정에는 참조만 남깁니다.

룰셋의 세 가지 동작 방식

behavior는 룰셋이 어떻게 해석될지를 결정합니다.

• domain:도메인 목록을 내용으로 가지며, 한 줄에 도메인 하나씩 작성합니다. +로 시작하면 서픽스 매칭입니다. 직접 관리하는 사이트 목록에 적합합니다.
• ipcidr:IP 또는 CIDR 대역을 내용으로 가지며, IP 규칙에 사용됩니다.
• classical:완전한 규칙 문법을 지원합니다. 한 줄에 DOMAIN,xxx,그룹 또는 IP-CIDR,1.2.3.0/24,그룹 형태로 작성하며 가장 유연합니다.

원격 룰셋과 로컬 룰셋

설정 예제 · rule-providers 두 가지 소스

rule-providers:
  geosite:
    type: http
    behavior: domain
    format: yaml
    url: "https://example.com/rules/geosite.yaml"
    path: ./rules/geosite.yaml
    interval: 86400
  my-custom:
    type: file
    behavior: classical
    format: text
    path: ./rules/custom.txt

• type: http는 원격에서 받아오는 방식이며, interval은 자동 업데이트 간격(초)으로 86400이면 하루 한 번입니다. path는 로컬 캐시 경로로, 받아오기에 실패하면 코어는 캐시로 계속 동작합니다.
• type: file은 로컬 파일 방식으로, 직접 관리하는 규칙에 적합하며 원격 업데이트에 참여하지 않습니다.
• format: yaml이면 내용을 YAML 목록으로 작성해야 하고, format: text면 한 줄에 하나씩 작성하는 일반 텍스트 방식에 더 가깝습니다.

rules에서 참조하기

설정 예제 · RULE-SET 참조

rules:
  - RULE-SET,geosite,스트리밍
  - RULE-SET,my-custom,직결
  - MATCH,메인

RULE-SET의 첫 번째 인자는 룰셋 이름, 두 번째 인자는 매칭될 프록시 그룹입니다. 룰셋 내부가 classical 동작이고 각 규칙에 그룹이 이미 포함되어 있다면 두 번째 인자는 생략할 수 있습니다.

업데이트와 유지보수

• 원격 룰셋은 「구독」 페이지에서 개별 업데이트하거나 interval이 만료되어 자동 업데이트될 때까지 기다릴 수 있습니다.
• 구독 업데이트는 룰셋을 건드리지 않습니다. 룰셋은 독립 파일이기 때문이며, 이것이 규칙을 메인 설정에서 분리하는 핵심 이점입니다.
• 룰셋 파일에는 목록 외의 내용을 쓰지 마세요. format: yaml 모드에서는 최상위가 반드시 목록이어야 하며, 형식이 잘못되면 룰셋 전체가 로드되지 않아 해당 규칙이 모두 무효화되고 트래픽이 폴백 규칙으로 빠집니다.
• 룰셋이 적용됐는지 확인하려면 로그 창에서 rule-provider를 검색해 로드·업데이트 기록을 보세요. debug 로그에서는 각 연결이 매칭된 규칙도 확인할 수 있습니다.

분기 설계

흔한 구성은 "도메인 룰셋 + IP 룰셋 + 폴백" 3계층입니다. 먼저 광고·추적 도메인을 REJECT하고, 스트리밍 도메인은 스트리밍 그룹으로, 국내 도메인은 직결로 보낸 뒤, 마지막에 MATCH로 메인 그룹을 태웁니다. mihomo는 위에서 아래로 매칭해 첫 번째로 맞는 규칙이 적용되므로 REJECT와 직결 규칙을 앞쪽에 배치해야 합니다.

DNS 설정 최적화

DNS는 분기 품질을 가르는 분수령입니다. 도메인 해석 결과가 연결이 프록시를 탈지 직결로 갈지를 결정하므로, 설정이 잘못되면 "프록시를 타야 할 트래픽이 직결로 나감", "DNS 누출", "해석 시간 초과" 같은 문제가 생깁니다.

dns 섹션 기본 구조

설정 예제 · 국내 DoH 기본 해석 + 해외 DoH 폴백

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  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://dns.google/dns-query
  fallback-filter:
    geoip: true
    geosite: geolocation-!cn

• default-nameserver는 DNS 서버 자체의 도메인을 해석할 때만 사용되므로 반드시 IP 주소를 써야 합니다. 그렇지 않으면 시작 시 DNS 해석 단계에서 멈춥니다.
• nameserver는 기본 해석 채널입니다. 국내 DoH(알리바바, 텐센트)는 속도가 빠르고 국내 도메인 해석 정확도가 높습니다.
• fallback은 예비 채널로, 기본 채널이 반환한 결과가 fallback-filter에서 이상하다고 판정될 때 사용됩니다. geoip: true와 geosite: geolocation-!cn의 의미는 nameserver가 반환한 IP가 해외인데 도메인이 국내 도메인이 아닐 때 fallback으로 다시 해석하라는 뜻입니다. 이는 국내 DNS가 해외 도메인 해석을 오염시키는 것을 막는 표준 방식입니다.
• ipv6: false이면 시스템에 IPv6가 있어도 mihomo는 A 레코드만 요청합니다. IPv6 출구가 필요할 때만 켜세요.

enhanced-mode 선택 방법

fake-ip:도메인을 실제로 해석하지 않고 fake-ip-range(기본값 198.18.0.1/16)의 가상 IP에 바로 매핑합니다. 앱이 가상 IP에 연결하면 코어가 전달 시 도메인을 복원해 규칙 매칭을 수행합니다. 속도가 빠르고 DNS 누출을 막아 TUN 모드에서 권장됩니다.

redir-host:실제 해석 결과를 반환하고 규칙 매칭도 실제 IP로 수행합니다. 호환성은 더 안정적이지만 매 연결마다 해석이 끝나기를 기다려야 하고, 결과가 오염될 수도 있습니다.

가로채기와 캐시

dns-hijack은 tun 섹션에서 설정하며, 53번 포트로 향하는 DNS 요청을 코어 자체의 DNS 서비스로 가로챕니다.

설정 예제 · DNS 가로채기와 캐시

tun:
  dns-hijack:
    - any:53

cache:
  enabled: true
  size: 4096
  ttl: 300

cache 섹션은 해석 결과를 캐시해 반복 조회를 줄입니다. ttl은 캐시 유지 시간(초)입니다. 너무 짧으면 캐시 의미가 없고, 너무 길면 도메인 IP가 바뀌었을 때 지연이 커집니다. 300초가 흔히 쓰는 값입니다.

문제 해결 분기

• 웹페이지를 열 때마다 몇 초씩 기다려야 한다면 nameserver가 DoH를 쓰는지, DoH 서버에 직접 연결되는 네트워크 환경인지 확인하세요. 일부 네트워크에서는 해외 DoH 접근이 불안정하므로 예비 DoH를 nameserver 목록에 추가하세요.
• 국내 사이트가 해외 IP로 해석된다면 fallback-filter의 geosite 규칙이 적용되지 않은 것입니다. 코어가 geosite 데이터 소스를 받아올 수 있는지 확인하거나 geox-url을 직접 지정하세요.
• 구독에 포함된 dns 섹션과 오버라이드가 충돌한다면 오버라이드에서 dns 키를 통째로 덮어쓰세요. 필드 단위 병합은 피해야 합니다.

TUN 모드와 Fake-IP

시스템 프록시는 "프록시 설정을 스스로 읽는" 앱만 가로챕니다. CLI 도구, 게임, UDP 트래픽은 종종 이를 우회합니다. TUN 모드는 시스템에 가상 네트워크 카드를 만들어 모든 IP 트래픽을 코어로 끌어오므로 "전역 가로채기"의 정답입니다. Fake-IP는 TUN 모드에서 DNS·규칙 매칭의 파트너 역할을 합니다.

시스템 프록시와 TUN의 차이

시스템 프록시는 시스템 설정을 수정해 앱에 "트래픽을 127.0.0.1:7890으로 보내라"고 알리지만, 앱이 이 설정을 읽지 않으면 동작하지 않습니다. TUN 모드는 IP 계층에서 동작해 가상 네트워크 카드가 모든 아웃바운드 IP 패킷을 받으므로 앱의 협조가 필요 없습니다. 차이는 바로 여기서 드러납니다.

• CLI 도구, curl, git은 기본적으로 시스템 프록시를 읽지 않지만, TUN 모드에서는 하나씩 export할 필요가 없습니다.
• 게임과 UDP 앱은 시스템 프록시로는 사실상 처리할 수 없지만 TUN은 가로챌 수 있습니다.
• TUN이 가로채는 것은 IP 패킷입니다. 앱이 DNS 조회를 먼저 보낸 뒤 TCP 연결을 맺으므로 TUN은 반드시 DNS 가로채기와 함께 사용해야 합니다. 그렇지 않으면 도메인 해석이 여전히 시스템 DNS를 타고, 규칙 매칭이 도메인을 얻지 못합니다.

tun 섹션 전체 설정

설정 예제 · tun 섹션

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

• stack:패킷 처리 스택. system은 호환성이 가장 좋지만 성능은 보통입니다. gvisor는 성능이 좋고 리소스 사용이 적지만 일부 구형 시스템과 호환되지 않습니다. mixed는 코어가 플랫폼에 따라 자동 선택하므로 새 버전에서는 우선 사용해 보세요.
• auto-route:기본 라우트를 가상 네트워크 카드가 가로채도록 자동 추가합니다. 반드시 켜야 합니다.
• auto-detect-interface:출구 네트워크 인터페이스를 자동 감지합니다. 유선 + 무선 + 가상 머신처럼 여러 인터페이스가 있는 환경에서는 켜는 걸 권장합니다. 잘못된 출구를 선택하면 인터넷이 끊길 수 있습니다.
• strict-route:Windows에서 켜면 라우팅 테이블을 엄격히 가로채 "일부 트래픽 누출"을 막아줍니다. 다만 VPN·가상 네트워크 카드와 충돌하기 쉬우므로 문제 해결 시에는 먼저 꺼보세요.

Fake-IP 동작 원리

enhanced-mode: fake-ip를 켜면 코어는 도메인 해석 요청을 받았을 때 실제 DNS에 조회하지 않고 fake-ip-range(기본값 198.18.0.1/16)에서 가상 IP를 반환하며, "도메인 ↔ 가상 IP" 매핑을 메모리에 기록합니다. 앱이 가상 IP에 연결하면 코어는 매핑을 통해 도메인을 복원한 뒤 규칙 매칭을 수행합니다. 이점은 두 가지입니다. 해석이 실제 DNS 왕복을 기다리지 않아 연결이 빨라지고, 규칙 매칭이 항상 도메인 기준이라 IP 오염에 흔들리지 않습니다.

fake-ip-filter는 가상 IP가 필요 없는 도메인을 제외하는 데 사용합니다. 주로 로컬 서비스나 실제 IP 직결이 필요한 사이트가 대상입니다.

설정 예제 · fake-ip 범위와 필터

dns:
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "stun.*"

플랫폼별 주의사항

• Windows:서비스 모드로 실행해야 합니다. 설치 시 "서비스 설치"를 체크하거나, 이후 설정에서 서비스 모드를 켜세요. 시스템 방화벽에서 코어 프로세스를 허용해야 합니다.
• macOS:TUN을 켜려면 관리자 권한이 필요하며, 처음 활성화할 때 비밀번호 입력창이 뜹니다. 시스템 업데이트 후 권한이 풀릴 수 있으니 TUN을 껐다 켜면 됩니다.
• Linux:cap_net_admin 권한이 필요합니다. 일반 사용자로 실행한다면 바이너리에 해당 capability가 있는지 확인하거나 systemd 서비스로 시작하세요.
• Android:Clash Meta for Android 같은 클라이언트도 TUN을 지원하며, 시스템 VPN 권한이 필요합니다. 시스템 프록시와는 상호 배타적인 두 가지 동작 방식입니다.

문제 해결 분기

• TUN을 켠 뒤 완전히 인터넷이 끊긴다면 먼저 strict-route를 끄고, stack: system으로 바꾼 뒤 auto-detect-interface가 올바른 인터페이스를 선택했는지 확인하세요.
• 국내는 되는데 해외가 타임아웃된다면 TUN과 DNS 가로채기 연동에 문제가 있는 것입니다. tun 섹션에 dns-hijack: [any:53]이 있고 dns.enable이 true인지 확인하세요.
• 일부 앱의 연결이 리셋된다면 앱이 대상 IP를 검증하고 있을 수 있습니다. 해당 도메인을 fake-ip-filter에 추가해 실제 해석을 타게 하세요.

도메인 스니핑

TUN 모드가 가로채는 것은 IP 패킷입니다. 앱이 IP에 직접 연결하거나 이미 해석된 주소에 연결하면 코어는 도메인을 얻지 못해 규칙 매칭을 IP로만 해야 합니다. 도메인 스니핑(sniffing)은 연결 내용에서 도메인을 "찾아내" 이 빈자리를 채웁니다.

어떤 상황에서 스니핑이 필요한가

• 앱이 자체적으로 DNS 해석을 수행하는 경우(일부 게임 클라이언트, 특정 앱의 IP 직결):트래픽이 TUN에 도달할 때 IP만 있고 도메인이 없습니다.
• QUIC / HTTP3 연결:UDP 트래픽에는 가로챌 전통적인 DNS 조회가 없습니다.
• 연결 재사용:같은 TCP 연결의 이후 요청에서는 DNS를 다시 보내지 않으므로 규칙을 IP로만 매칭할 수밖에 없습니다.

설정 예제

설정 예제 · sniffing 섹션

sniffing:
  enable: true
  override-destination: false
  force-doman: true
  parse-pure-ip: true
  skip-dest-address:
    - 192.168.0.0/16
    - 198.18.0.1/16

• enable:전체 스위치.
• override-destination:스니핑으로 도메인을 찾은 뒤 연결 대상을 도메인으로 바꿀지 여부입니다. 켜면 규칙 매칭이 더 정확해지지만 QUIC 같은 일부 프로토콜은 변경을 지원하지 않습니다. false로 두고 코어가 안전하게 바꿀 수 있을 때만 바꾸도록 하는 걸 권장합니다.
• force-doman:설정에 IP 규칙이 적혀 있어도 규칙 매칭에 스니핑된 도메인을 강제로 사용합니다.
• parse-pure-ip:순수 IP 연결에서도 TLS SNI 같은 필드를 통해 도메인을 해석하려 시도합니다.
• skip-dest-address:스니핑이 필요 없는 대상 대역을 건너뜁니다. 보통 내부 대역과 fake-ip-range를 제외해 가상 IP에 대한 무의미한 스니핑을 막습니다.

스니핑과 규칙 매칭의 순서

연결이 들어온 뒤의 매칭 순서는 다음과 같습니다. 먼저 연결이 Fake-IP 매핑에 해당하는지 확인하고(도메인이 있으면 바로 도메인 사용), 그다음 skip 대상인지 확인한 뒤 스니핑을 시도합니다. 스니핑으로 도메인을 찾으면 "도메인 규칙 → IP 규칙 → 폴백" 순서로 매칭합니다. 따라서 스니핑을 켜면 DOMAIN으로 시작하는 규칙의 적용 범위가 넓어지고, IP 규칙은 여전히 유효하지만 도메인 규칙 뒤에 배치됩니다.

주의사항

• 스니핑은 연결의 앞쪽 패킷 몇 개만 읽으므로 성능 영향이 매우 작습니다. 하지만 override-destination을 켜면 일부 앱이 대상 주소가 바뀌어 오류를 내는 경우가 있습니다. "특정 앱이 TUN을 켜면 연결이 안 된다"면 이 항목을 먼저 꺼보세요.
• 비TLS 평문 HTTP 트래픽은 Host 헤더를 스니핑하고, TLS 트래픽은 SNI를 읽으며, QUIC 트래픽은 CHLO의 SNI를 읽습니다. 다만 UDP 세션에는 안정적인 "연결" 개념이 없어 일부 구현에서는 스니핑 범위가 제한됩니다.
• Fake-IP와의 관계:Fake-IP는 DNS 계층에서 이미 도메인을 확보하므로, 스니핑은 주로 "DNS 가로채기를 거치지 않은" 트래픽을 보완합니다. 둘을 동시에 켜는 것은 중복 작업이 아니라 서로 다른 진입점을 커버하는 것입니다.

로컬 오버라이드와 멀티 구독 병합

구독에서 받아온 설정을 직접 수정하면 업데이트 한 번에 모두 사라집니다. 오버라이드(merge)는 Clash Verge가 제공하는 증분 수정 계층입니다. 구독이 업데이트된 뒤에도 오버라이드의 변경 사항이 자동으로 다시 적용됩니다. 멀티 구독 환경에서는 오버라이드로 서로 다른 구독의 노드를 같은 프록시 그룹에 병합할 수도 있습니다.

오버라이드 문법

오버라이드 파일 자체는 YAML이며 두 종류의 지시어를 지원합니다.

• 키 덮어쓰기:대상 키와 값을 직접 작성해 구독의 동일 키를 교체합니다. DNS, TUN처럼 섹션 전체를 다시 쓰는 상황에 사용합니다.
• 추가 지시어:prepend-와 append- 접두사가 붙은 키로, 내용을 구독의 해당 목록 앞이나 뒤에 삽입합니다. prepend-proxies, append-proxies, prepend-proxy-groups, append-proxy-groups, prepend-rules, append-rules 등을 지원합니다.

설정 예제 · 추가 지시어

prepend-rules:
  - DOMAIN-SUFFIX,company.com,직결
append-rules:
  - GEOIP,CN,직결
  - MATCH,메인
prepend-proxy-groups:
  - name: 업무
    type: select
    proxies:
      - 회사 전용선
      - 메인

완전한 오버라이드 예제

설정 예제 · 노드 병합 + 커스텀 규칙 + DNS 고정

# 오버라이드:두 구독의 노드 병합, 커스텀 규칙 추가, DNS 고정
prepend-proxy-groups:
  - name: 전체 노드
    type: select
    proxies:
      - 구독A 노드
      - 구독B 노드
      - 직결
prepend-rules:
  - DOMAIN-SUFFIX,corp.example.com,직결
  - RULE-SET,my-custom,메인
append-rules:
  - MATCH,전체 노드
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.alidns.com/dns-query

주의:오버라이드에 dns 키를 쓰면 구독의 dns 섹션 전체가 교체됩니다. 구독의 DNS를 유지하면서 한 곳만 바꾸려면 구독의 전체 dns 섹션을 복사해 수정하거나, prepend-dns/append-dns로 목록에 추가해야 합니다. 하지만 dns 섹션의 필드는 중첩 객체라 추가 지시어는 목록에만 동작하므로, 가장 안전한 방법은 섹션 전체를 덮어쓰는 것입니다.

멀티 구독 병합

• 「설정」 페이지에서 여러 구독을 추가하면 각 구독이 독립적으로 업데이트되어 서로 간섭하지 않습니다.
• "전체 노드" 같은 프록시 그룹으로 여러 구독의 노드를 모으고, include-all 또는 오버라이드의 proxies에서 그룹 이름을 참조하세요.
• 구독을 전환하면 현재 적용 중인 profile 전체가 바뀌며, 오버라이드와 스크립트는 항상 "현재 구독" 위에 겹쳐 적용됩니다. 따라서 오버라이드에서 노드 이름을 참조할 때는 모든 구독에 같은 이름의 노드가 존재하는지 확인해야 합니다. 그렇지 않으면 프록시 그룹이 빈 멤버를 참조하게 됩니다.
• 스크립트 모드(script.js)는 더 복잡한 병합 로직에 적합합니다. 예를 들어 구독 이름 접두사로 자동 그룹화하거나, 키워드에 "만료"가 포함된 노드를 필터링하는 작업입니다. 스크립트는 오버라이드 이후에 실행되며 config 객체를 받아 수정된 객체를 반환합니다.

유지보수 제안

• 오버라이드 내용은 용도별로 구분하고 "규칙", "프록시 그룹", "DNS" 주석을 달아두면 반년 후에 봐도 한눈에 이해됩니다.
• 구독을 업데이트할 때마다 로그에 merge 실패류 메시지가 없는지 확인해 오버라이드 문법이 구독 내용과 충돌하지 않았는지 점검하세요.
• 규칙은 가능한 한 룰셋으로 관리하고, 오버라이드에는 소수의 개인화 규칙만 두세요. 오버라이드 자체가 두 번째 메인 설정으로 비대해지는 것을 막아야 합니다.

외부 컨트롤 패널

평소 노드 전환이나 연결 확인은 클라이언트 UI로 충분합니다. 하지만 일괄 작업, 규칙 매칭 확인, 원격 관리가 필요하다면 mihomo의 외부 컨트롤 API를 사용해야 합니다. 패널은 HTTP로 코어와 대화하며, external-controller만 설정하면 바로 사용할 수 있습니다.

기본 설정

설정 예제 · 외부 컨트롤 리슨 주소와 토큰

external-controller: 127.0.0.1:9090
secret: "your-long-random-token"

• external-controller 형식은 "주소:포트"입니다. 로컬에서만 접근한다면 127.0.0.1:9090으로 쓰고, LAN에서 접근하려면 0.0.0.0:9090으로 바꾼 뒤 방화벽을 설정하세요. 단, 공인망에 직접 노출하지 마세요. 패널은 프록시 전환과 연결 정보 조회가 가능하므로, 공인망에 열린 포트는 프록시 제어권을 누구에게나 넘겨주는 것과 같습니다.
• secret은 접근 토큰으로 패널과 API 요청 모두에 포함해야 합니다. 충분히 긴 랜덤 문자열을 사용하세요. Verge의 설정 페이지에서도 secret을 생성·저장할 수 있습니다.
• external-controller나 secret을 수정한 뒤에는 코어를 재시작해야 적용됩니다.

자주 쓰는 패널

mihomo 공식 저장소는 Yacd, MetaXD 같은 패널을 제공합니다. 빌드한 뒤 코어와 같은 디렉터리의 ui 폴더에 넣고 브라우저에서 http://127.0.0.1:9090/ui에 접속하면 열립니다. 패널을 처음 열면 백엔드 주소와 secret을 입력하라고 합니다. Verge의 「설정 → 외부 컨트롤」에도 패널 진입점이 있어 바로 사용할 수 있습니다.

REST API 주요 엔드포인트

호출 예제 · curl 조회와 전환

curl -H "Authorization: Bearer your-long-random-token" \
  http://127.0.0.1:9090/proxies

curl -X PUT -H "Authorization: Bearer your-long-random-token" \
  -d '{"name":"홍콩 01"}' \
  http://127.0.0.1:9090/proxies/메인

• GET /connections로 "이 연결이 왜 직결로 나갔지"를 점검할 수 있습니다. 응답에 rule과 rulePayload 필드가 포함되어 매칭된 규칙을 바로 보여줍니다.
• PUT /configs는 모드 전환에 적합합니다. {"mode":"global"}로 임시 전역 프록시를 쓴 뒤, 끝나면 rule로 되돌리세요.
• 모든 API는 Authorization 헤더가 필요하며 형식은 Bearer <secret>입니다.

보안 권장사항

• 패널과 API는 루프백 주소에서만 리슨하거나, SSH 터널을 통해 LAN 밖의 머신에 접근하세요.
• secret은 동기화되는 메모에 쓰지 말고, 명령줄 히스토리에 평문으로 반복 노출하지 마세요. 환경 변수나 클라이언트 내장 secret 관리 기능을 사용하세요.
• 주기적으로 GET /configs로 mode가 변경되지 않았는지 확인하세요. mode가 global로 바뀌어 있고 본인이 바꾼 게 아니라면 포트 노출을 의심한 뒤 secret을 교체하세요.