Clash Meta 고급 설정 가이드

01

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

프록시 그룹은 설정의 의사 결정 계층입니다. 프록시 노드가 “어떻게 연결할지”를 해결한다면, 프록시 그룹은 “이 유형의 트래픽을 어디로 보낼지”를 결정합니다. 유지 관리하기 쉬운 설정에서는 규칙이 특정 노드를 직접 가리키기보다 먼저 “일상 선택”, “자동 테스트”, “장애 조치”, “다운로드 분리”처럼 안정적인 이름을 만들고 규칙에서 이를 참조합니다. 이렇게 하면 구독이나 노드 이름을 바꿔도 규칙 계층을 다시 작성할 필요가 없습니다. 프록시 그룹 이름에 한글을 사용할 수 있지만, proxy-groups와 rules, 다른 그룹의 proxies에서 이름이 완전히 일치해야 합니다. 공백, 대소문자와 기호도 생략할 수 없습니다.

select, url-test, fallback 및 load-balance

select는 수동 선택 그룹으로, 출구를 직접 지정해야 하는 상황에 적합합니다. 자체적으로 노드 품질을 판단하지 않고 현재 선택만 저장합니다. 자동 그룹, 장애 조치 그룹과 자주 사용하는 일부 노드를 하나의 select 그룹에 넣으면 안정성과 수동 제어 사이를 전환할 수 있습니다. url-test는 설정한 간격마다 테스트 주소에 접속해 사용 가능한 노드 중 측정 지연 시간이 가장 짧은 항목을 선택합니다. 웹 브라우징이나 API 요청처럼 응답 속도가 중요한 짧은 연결에 적합합니다. 측정 결과는 현재 기기에서 테스트 대상까지의 성능만 나타내며, 모든 웹사이트와 스트리밍 서비스의 속도가 같다는 뜻은 아닙니다.

fallback은 목록 순서대로 가용성을 확인하고 앞쪽 노드를 우선 사용하다가 현재 노드를 사용할 수 없을 때만 다음 항목으로 전환합니다. 주 회선과 예비 회선을 고정하는 구조, 로그인 상태나 출구 지역이 자주 바뀌면 안 되는 서비스에 적합합니다. load-balance는 여러 연결을 여러 노드에 분산하므로 병렬 다운로드나 다중 대상 접속에 사용할 수 있지만, 한 웹사이트의 여러 연결이 서로 다른 출구에서 나가면 로그인 인증이 다시 요구될 수 있습니다. 따라서 로드 밸런싱을 일상적인 기본 그룹으로 바로 대체하지 말고 별도 규칙에서 정확히 참조해야 합니다.

유지 관리하기 쉬운 계층 구조

아래 구조는 노드 공급을 프록시 제공자에 맡기고, 자동 선택과 장애 조치를 하위 그룹으로 구성한 다음 “기본 프록시” 하나를 규칙에 노출합니다. include-all: true는 사용 가능한 프록시 제공자의 노드를 그룹에 포함합니다. 클라이언트나 기존 설정에서 프록시 제공자를 사용하지 않는다면 proxies에 노드를 직접 나열할 수도 있습니다. interval은 상태 확인 또는 속도 측정 간격이며 단위는 초입니다. tolerance는 새 결과가 현재 노드보다 얼마나 좋아야 전환할지를 뜻합니다. 적절한 허용 오차를 두면 지연 시간이 비슷한 두 노드 사이를 계속 오가는 현상을 줄일 수 있습니다.

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

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

테스트 주소는 응답 크기가 작고 상태가 안정적인 응답을 반환해야 합니다. 현재 네트워크에서 대상이 리디렉션되거나 캐시되거나 접속할 수 없으면 그룹의 모든 노드가 실패로 표시될 수 있습니다. 이때는 먼저 로그에서 DNS 해석 실패인지, 연결 시간 초과인지, TLS 오류인지 확인한 다음 테스트 주소를 바꾸세요. 더 작은 숫자를 얻으려고 측정 간격을 지나치게 짧게 설정하지 마세요. 잦은 테스트는 연결 수와 배터리 사용량을 늘리고 모바일 네트워크를 계속 깨울 수 있습니다.

노드를 쌓기보다 용도별로 그룹 나누기

장기적으로 사용할 설정은 모든 지역과 노드를 수십 개의 진입점으로 펼치기보다 “스트리밍”, “개발 서비스”, “대용량 파일 다운로드”처럼 용도에 따라 이름을 정하는 편이 좋습니다. 용도 그룹이 지역 그룹을 참조하고, 지역 그룹이 자동 테스트 그룹을 참조하도록 2~3단계의 명확한 관계를 구성할 수 있습니다. 계층이 지나치게 깊으면 문제 해결이 어려워지고 순환 참조가 생길 수 있습니다. A 그룹이 B를 포함하고 B가 다시 A를 포함하면 설정 검사가 실패합니다. 수정 후에는 먼저 클라이언트의 설정 검사 기능이나 mihomo의 테스트 실행 방식으로 문법을 확인한 뒤, 로그에서 규칙이 최종적으로 어떤 프록시 그룹에 일치했는지 확인하세요. 세 가지 자동 그룹의 판단 차이와 조합 사례는 프록시 그룹 유형 선택 가이드에서 이어서 확인할 수 있습니다.

02

룰셋 구독 관리

규칙은 요청을 직접 연결, 프록시, 거부 또는 특정 용도 그룹으로 보낼지 결정합니다. 수천 개의 도메인과 IP를 주 설정에 직접 작성해도 작동하지만 업데이트, 검토와 원인 파악이 어려워집니다. rule-providers는 규칙 내용을 별도 파일로 분리하고, 주 설정에서 출처, 동작 유형, 저장 경로와 갱신 간격을 선언합니다. 실제 규칙에서는 RULE-SET만 참조하면 됩니다. 미디어 규칙, 내부망 규칙 또는 개발 서비스 규칙을 따로 업데이트할 수 있고, 규칙 출처에 일시적으로 접속할 수 없어도 로컬 캐시를 계속 사용할 수 있습니다.

behavior와 format은 내용과 일치해야 함

behavior는 룰셋에 저장된 콘텐츠 형태를 설명합니다. domain은 도메인 항목용으로 전체 도메인, 도메인 접미사와 키워드 모음에 적합합니다. ipcidr은 IPv4 및 IPv6 네트워크 대역용입니다. classical은 DOMAIN-SUFFIX,example.org 또는 IP-CIDR,192.0.2.0/24처럼 유형 접두사가 포함된 완전한 규칙을 저장합니다. 세 유형은 필드 이름만 바꿔 서로 변환할 수 없으며 원격 파일의 실제 구조가 선언과 일치해야 합니다. format의 일반적인 값은 yaml, text, mrs입니다. 형식은 규칙 출처가 제공하는 파일에 따라 정해야 하며 일반 텍스트 링크를 바이너리 규칙 형식으로 선언해서는 안 됩니다.

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

  private-networks:
    type: http
    behavior: ipcidr
    format: yaml
    url: https://rules.example.com/private-networks.yaml
    path: ./ruleset/private-networks.yaml
    interval: 86400

rules:
  - RULE-SET,private-domains,DIRECT
  - RULE-SET,private-networks,DIRECT,no-resolve
  - GEOIP,LAN,DIRECT,no-resolve
  - MATCH,기본 프록시

예시 도메인은 구조를 설명하기 위한 것입니다. 실제로 사용할 때는 신뢰할 수 있는 규칙 출처가 제공하는 완전한 파일 주소로 바꾸세요. path는 코어 작업 디렉터리 아래의 캐시 위치이며, 작업 디렉터리는 클라이언트마다 다릅니다. mihomo를 직접 실행한다면 프로세스에 해당 디렉터리의 쓰기 권한이 있는지 확인하세요. 규칙 파일을 처음 다운로드할 때 실패하고 로컬 캐시도 없으면 해당 제공자는 매칭에 참여할 수 없습니다. 이전 다운로드가 성공했다면 코어는 대개 캐시를 계속 읽을 수 있지만 원격에 추가된 내용은 반영되지 않습니다.

규칙은 위에서 아래로 매칭됨

rules의 순서는 결정적입니다. 요청이 적용 가능한 첫 번째 규칙에 일치하면 이후 매칭을 중단합니다. 따라서 범위가 좁고 의도가 명확한 규칙을 앞에, 포괄적인 규칙을 뒤에 배치해야 하며 MATCH는 마지막 대체 규칙으로만 사용하세요. 예를 들어 회사 내부 도메인을 직접 연결해야 한다면 일반 프록시 도메인 모음보다 앞에 둬야 합니다. 사설 네트워크 대역도 포괄적인 IP 규칙보다 먼저 처리해야 합니다. 넓은 범위의 프록시 모음을 맨 앞에 두면 뒤의 직접 연결 예외는 문법이 올바르더라도 절대 실행되지 않습니다.

no-resolve는 IP 유형 규칙에 사용하며, 매칭 단계에서 대상 IP를 얻기 위해 추가 DNS 해석을 능동적으로 수행하지 않는다는 뜻입니다. 불필요한 조회를 줄이고 도메인이 아직 해석되지 않았을 때 매칭 경로가 바뀌는 것을 막을 수 있습니다. 하지만 모든 규칙에 기계적으로 추가할 필요는 없습니다. 도메인 규칙은 도메인 자체에 의존하며, 프로세스가 IP만 제공하고 스니핑 결과도 없다면 이후 IP 규칙이 판단을 맡아야 합니다. 규칙 문제를 분석할 때는 그룹 이름만 보지 말고 로그의 대상 호스트, 규칙 유형과 최종 정책을 함께 확인하세요.

업데이트 실패와 롤백 처리

룰셋 업데이트 실패는 대개 네 가지 원인에서 발생합니다. 원격 주소가 만료되었거나, DNS 해석에 실패했거나, 다운로드에 프록시가 필요하지만 현재 정책이 준비되지 않았거나, 캐시 디렉터리에 쓸 수 없는 경우입니다. 먼저 로그의 HTTP 상태나 네트워크 오류를 확인한 뒤 같은 기기에서 브라우저 또는 명령줄로 규칙 주소에 접속해 보세요. 코어만 접속하지 못한다면 프록시를 통해 규칙 제공자를 다운로드해야 하는지, 초기 DNS가 규칙 출처의 도메인을 해석할 수 있는지 점검하세요. 디렉터리 권한 문제는 파일 생성, 임시 파일 이름 변경 또는 쓰기 실패 메시지로 나타납니다.

원격 규칙을 사용한다고 해서 시작할 때마다 반드시 온라인으로 가져와야 하는 것은 아닙니다. 운영 환경에서는 마지막으로 정상 작동한 캐시를 보존하고, 업데이트 전에 파일 형식을 확인하며, 변경 범위를 제한하는 것이 좋습니다. 모든 규칙 출처, DNS 설정과 프록시 그룹을 한 번에 교체하면 어느 계층에서 문제가 생겼는지 판단하기 어렵습니다. 더 안전한 순서는 먼저 제공자를 추가하되 참조하지 않고 다운로드 성공 여부를 확인하는 것입니다. 그런 다음 RULE-SET 하나를 추가해 매칭을 관찰하고, 마지막으로 기존 규칙을 삭제하세요. 되돌릴 때는 주 설정의 참조를 복구하면 되며 캐시 파일은 확인을 위해 남겨 두어도 됩니다.

규칙 수가 설정 품질을 결정하지 않음

규칙이 많다고 트래픽 분리가 자동으로 더 정확해지는 것은 아닙니다. 중복 모음은 로딩 시간을 늘리고 같은 도메인에 서로 충돌하는 결론을 만들 수 있습니다. 먼저 요구 사항에 따라 소수의 용도 그룹을 정한 다음 해당 용도를 포괄하는 룰셋을 선택하세요. “특정 웹사이트가 잘못된 그룹으로 연결되는” 경우에는 먼저 로그에서 실제로 일치한 첫 규칙을 찾고 순서를 조정하거나 정확한 예외를 추가하세요. 전체 규칙 세트를 바로 바꾸면 새로운 미지의 변화가 생길 수 있습니다. GeoIP 또는 규칙 제공자 업데이트 이상에 대한 추가 점검은 자주 묻는 질문의 해당 문제 해결 항목을 확인하세요.

03

DNS 설정 최적화

DNS 계층은 도메인을 주소로 변환하며 규칙이 올바른 대상을 확인할 수 있는지에도 직접 영향을 줍니다. “노드는 연결되지만 웹페이지가 열리지 않음”, “같은 도메인이 가끔 직접 연결되고 가끔 프록시로 연결됨”, “로그에 IP만 표시되어 도메인을 판단할 수 없음” 같은 문제는 노드 속도보다 DNS 요청 경로, 캐시 결과와 트래픽 가로채기 방식이 서로 맞지 않아 발생하는 경우가 많습니다. DNS를 설정할 때는 먼저 세 가지 질문에 답해야 합니다. 조회를 누가 처리하는가, 어떤 해석기로 보내는가, 해석기 자체의 도메인은 어떻게 해석하는가. 이 세 관계가 명확해진 후 Fake-IP 사용 여부를 결정하세요.

nameserver, default-nameserver 및 프록시 전용 해석기

nameserver는 일반 도메인 조회의 주요 해석기입니다. 기존 UDP/TCP DNS를 입력할 수도 있고 DoH 같은 암호화 형식을 사용할 수도 있습니다. default-nameserver는 주로 DoH 서버 도메인이나 프록시 서버 도메인처럼 시작 단계에서 필요한 항목을 해석하는 데 사용합니다. 직접 접속할 수 있는 IP 형식의 해석기를 넣으면 “DNS 서비스 도메인을 먼저 해석해야 해당 DNS 서비스를 사용할 수 있는” 순환을 피할 수 있습니다. proxy-server-nameserver는 프록시 노드 서버 도메인을 전담해 처리하여 노드 주소 해석을 일반 업무 도메인과 분리하고, 업무 규칙이 프록시 연결에 역으로 영향을 줄 가능성을 낮춥니다.

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  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

  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query
    "geosite:geolocation-!cn":
      - https://1.1.1.1/dns-query

예시는 필드 간 관계를 보여 주기 위한 것이며 모든 네트워크에 동일한 해석기 조합이 적합하다는 뜻은 아닙니다. DNS 서비스를 선택할 때는 현재 네트워크에서의 접근성, 반환 결과와 개인정보 보호 요구 사항을 고려하세요. 특정 DoH 서비스에 프록시가 필요하고 시작 단계에서 유일한 해석 경로로 지정하면 프록시가 아직 연결되지 않았는데 DNS가 프록시를 기다리는 의존성 고리가 생길 수 있습니다. 직접 접근 가능한 기본 해석 경로를 남겨 두고 프록시 서버 도메인은 별도로 해석하면 대체로 안정적입니다.

nameserver-policy의 매칭 용도

nameserver-policy는 도메인, 규칙 모음 또는 geosite 분류에 따라 사용할 해석기를 지정할 수 있습니다. 예를 들어 로컬 도메인은 가까운 해석기로, 나머지 도메인은 다른 해석기 그룹으로 보낼 수 있습니다. 이는 “조회 요청을 어디로 보낼지”를 정하는 기능이지 “최종 트래픽을 어느 프록시 그룹으로 보낼지”를 정하는 기능이 아닙니다. 연결 정책은 여전히 rules가 결정합니다. DNS 정책과 라우팅 규칙은 비슷한 분류를 사용할 수 있지만 완전히 같을 필요는 없습니다. 서로 겹치는 도메인 모음을 많이 함께 작성하면 어떤 해석기가 사용되었는지 파악하기 어려우므로, 구체적인 항목에서 포괄적인 항목 순서를 지켜야 합니다.

respect-rules: true는 DNS 연결 자체가 라우팅 규칙을 따르도록 합니다. 활성화한 뒤에는 DNS 서버의 도메인과 주소에 시작을 완료할 수 있는 경로가 있는지 확인해야 합니다. 그렇지 않으면 해석기 요청이 아직 사용할 수 없는 프록시 그룹으로 전송될 수 있습니다. 이 항목을 수정한 후 모든 도메인 해석이 실패한다면 먼저 직접 접근 가능한 해석기를 임시로 사용해 확인한 뒤, DNS 서비스 도메인이 어떤 규칙에 일치했는지 점검하세요.

IPv6, 캐시 및 결과 차이

ipv6: false는 일반적으로 DNS 모듈이 AAAA 결과를 반환하지 않는다는 뜻이며, 기기나 출구에 안정적인 IPv6 연결이 없는 경우에 적합합니다. 로컬 네트워크와 프록시 노드 모두 사용 가능한 IPv6를 제공한다면 켤 수 있지만 TUN, 시스템 라우팅과 규칙의 IPv6 대역 처리도 함께 확인해야 합니다. DNS에서만 IPv6를 활성화하고 TUN이나 출구가 지원하지 않으면 애플리케이션이 IPv6 연결을 먼저 시도한 뒤 오래 기다리다가 IPv4로 되돌아갈 수 있습니다.

DNS를 변경해도 이전 결과가 운영체제, 브라우저, 클라이언트와 코어 캐시에 남아 있을 수 있습니다. 문제를 점검할 때는 먼저 관련 클라이언트를 재시작하거나 시스템 DNS 캐시를 삭제한 후 같은 도메인을 반복 테스트하세요. 브라우저가 독립적인 보안 DNS를 사용하면 시스템 해석 경로를 우회할 수 있습니다. 시스템 도구에서는 정상인데 브라우저에서만 문제가 생긴다면 브라우저 자체 설정을 확인하세요. 반대로 브라우저는 정상이고 터미널만 이상하다면 시스템 DNS, 환경 변수 또는 터미널 프로그램이 예상한 트래픽 경로를 사용하지 않는 경우일 가능성이 높습니다.

04

TUN과 Fake-IP

시스템 프록시는 애플리케이션이 프록시 설정을 능동적으로 읽어야 하며, 브라우저는 대체로 잘 지원하지만 일부 터미널 프로그램, 게임, 시스템 서비스와 사용자 지정 네트워크 스택을 사용하는 앱은 완전히 무시할 수 있습니다. TUN 모드는 가상 네트워크 카드와 시스템 라우팅을 통해 더 넓은 범위의 TCP 및 UDP 트래픽을 가로챈 뒤 mihomo로 전달합니다. Fake-IP는 DNS 단계에서 도메인에 예약 주소를 할당하고, 앱이 해당 주소에 연결하면 코어가 매핑을 통해 원래 도메인을 복원합니다. 이를 통해 더 많은 상황에서 도메인 규칙을 적용할 수 있습니다. 둘은 자주 함께 사용되지만 역할은 다릅니다. TUN은 트래픽을 가로채고 Fake-IP는 도메인 매핑을 담당합니다.

TUN 기본 설정과 플랫폼 권한

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

stack은 TUN 패킷을 처리할 네트워크 스택을 결정하며, mixed는 일반적인 호환성 선택입니다. 실제 사용 가능한 값과 효과는 코어 기능과 플랫폼 구현에 따라 달라집니다. auto-route는 필요한 라우팅을 자동으로 추가하고, auto-detect-interface는 기본 출구를 기준으로 물리 네트워크 카드를 식별합니다. 유선, 무선, 핫스팟 또는 VPN 사이를 전환할 때 특히 유용합니다. dns-hijack은 조건에 맞는 DNS 요청을 코어의 DNS 모듈로 전달해 시스템이 기존 해석기로 계속 조회하지 않도록 합니다. strict-route는 우회 경로를 더 엄격하게 제한해 누수와 라우팅 불일치를 줄일 수 있지만, 가상 머신·로컬 네트워크 공유 또는 다른 VPN과의 라우팅 충돌을 더 쉽게 드러낼 수도 있습니다.

가상 네트워크 카드를 만들고 라우팅을 수정하려면 대개 관리자 권한이 필요합니다. Windows 클라이언트는 서비스 모드로 권한 작업을 처리할 수 있고, macOS는 네트워크 확장 또는 시스템 권한을 요청합니다. Linux에서 코어를 직접 실행할 때는 필요한 네트워크 권한을 부여하고 systemd 서비스의 권한 설정도 확인해야 합니다. 활성화 후 기기 전체의 인터넷이 끊기면 먼저 노드를 바꾸지 말고 TUN을 끈 뒤 기본 네트워크가 복구되는지 확인하세요. 그런 다음 가상 네트워크 카드가 생성되었는지, 기본 경로가 잘못 덮어쓰였는지 점검합니다.

Fake-IP 작동 경로

enhanced-mode: fake-ip에서는 DNS 모듈이 fake-ip-range 안의 주소를 도메인에 반환합니다. 애플리케이션이 해당 주소에 연결하면 코어가 매핑 테이블에서 원래 도메인을 가져오고, 도메인 규칙에 따라 정책을 선택한 뒤 실제 대상을 해석합니다. 198.18.0.0/15는 성능 측정용으로 예약된 주소 대역이며 이러한 매핑에 자주 사용됩니다. Fake-IP 주소를 원격 서버의 실제 주소로 오해하지 마세요. 패킷 캡처나 로그에 이 대역이 보인다고 해서 낯선 호스트로 DNS가 탈취된 것이 아니라 매핑 경로가 작동 중이라는 뜻입니다.

Fake-IP의 장점은 도메인 정보를 비교적 온전히 보존해 규칙 판단이 직접적이고, 앱이 실제 IP를 미리 받아 도메인 규칙을 우회하는 상황을 줄인다는 것입니다. 반면 일부 앱은 DNS 반환값을 검증하거나, 로컬 네트워크 검색에 의존하거나, 특수 UDP 프로토콜을 사용하거나, 같은 코어를 거치지 않는 프로세스에 해석 결과를 전달할 수 있어 매핑에 적합하지 않을 수 있습니다. 이때는 Fake-IP를 완전히 끄기보다 fake-ip-filter로 특정 도메인에 실제 주소를 반환하도록 하세요.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "ntp.*.com"
    - geosite:private

blacklist 모드는 목록에 있는 도메인에는 Fake-IP를 사용하지 않고 나머지 도메인은 계속 매핑합니다. 필터 범위는 최대한 정확하게 지정해야 합니다. 지나치게 넓은 와일드카드를 추가하면 많은 요청이 실제 IP 모드로 돌아가 도메인 규칙의 효과가 약해집니다. 로컬 네트워크 장치 검색에 문제가 생기면 먼저 장치가 사용하는 .local, 사설 도메인 또는 제조사 서비스에 예외를 추가하고 로그를 관찰하세요. 흔한 최상위 도메인 전체를 한 번에 제외해서는 안 됩니다.

다른 VPN, 가상 머신 및 로컬 네트워크와의 충돌

TUN을 기업 VPN, 게임 가속 도구, 가상 머신 네트워크 카드, 컨테이너 네트워크와 동시에 사용하면 충돌은 대개 라우팅 우선순위, DNS 가로채기 또는 동일한 예약 대역에서 발생합니다. 먼저 TUN을 끈 상태의 기본 라우팅과 DNS를 기록한 뒤 네트워크 구성 요소를 하나씩 활성화하면 어느 단계에서 출구가 바뀌었는지 찾을 수 있습니다. 회사 VPN이 특정 대역만 허용한다면 해당 대역에 올바른 경로를 남기고 내부 도메인은 기업 DNS로 보내야 합니다. 그렇지 않으면 프록시 노드가 사용 가능해도 해석과 라우팅이 분리되어 내부 서비스에 연결되지 않을 수 있습니다.

로컬 네트워크 접속에 실패하면 사설 네트워크 대역이 DIRECT로 설정되어 있는지, TUN이 로컬 네트워크 경로를 보존하는지, 시스템 방화벽이 가상 네트워크 카드의 접근을 허용하는지 확인하세요. 라우터나 보조 게이트웨이에 배포할 때는 클라이언트 트래픽이 자기 자신으로 돌아와 루프를 만들지 않도록 해야 합니다. Linux에서는 ip route와 ip rule로 라우팅과 정책 규칙을 확인할 수 있고, Windows에서는 route print, macOS에서는 netstat -rn을 사용할 수 있습니다. 관찰만 할 때는 이 명령으로 시스템 설정을 변경할 필요가 없습니다.

# Linux: 라우팅 및 정책 규칙 확인
ip route
ip rule

# Windows: IPv4 및 IPv6 라우팅 확인
route print

# macOS: 현재 라우팅 테이블 확인
netstat -rn

브라우저와 일반 데스크톱 프로그램만 프록시를 사용하면 된다면 시스템 프록시가 구조가 더 단순하고 원인 파악도 쉽습니다. 시스템 프록시를 읽지 않는 앱이 실제로 있을 때만 TUN을 활성화하세요. 두 방식의 적용 범위, 권한과 성능 차이는 TUN 모드와 시스템 프록시 비교에서 확인할 수 있습니다.

05

도메인 스니핑

모든 연결이 코어에 들어올 때 도메인을 포함하는 것은 아닙니다. 앱이 먼저 DNS를 직접 해석한 뒤 대상 IP에 바로 연결할 수도 있고, 투명 프록시나 게이트웨이 환경에서는 주소만 보이는 경우가 많습니다. 도메인 스니핑은 연결 초기의 프로토콜 특징을 읽어 HTTP Host, TLS SNI 또는 QUIC 핸드셰이크 정보에서 도메인을 추출하고 규칙 매칭에 사용합니다. 업무 내용을 복호화하는 기능도 아니며 모든 프로토콜에서 작동하지도 않습니다. 핸드셰이크 단계에서 원래 보이는 대상 식별자만 활용해 라우팅 판단에 필요한 정보를 보완합니다.

프로토콜과 포트로 범위 제한

sniffer:
  enable: true
  parse-pure-ip: true
  force-dns-mapping: true

  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
      override-destination: true
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443
        - 8443

  force-domain:
    - "+.example.org"

  skip-domain:
    - "Mijia Cloud"
    - "+.push.apple.com"

parse-pure-ip는 원래 대상이 IP인 연결에서도 스니핑을 시도하도록 하며 투명 가로채기 환경에 적합합니다. force-dns-mapping은 DNS 매핑과 결합해 도메인 정보를 찾으며 Fake-IP와 함께 사용하는 경우가 많습니다. 프로토콜별로 포트를 제한하면 HTTP, TLS 또는 QUIC가 아닌 연결에서 불필요한 판단을 피할 수 있습니다. 포트 범위는 실제 앱에 맞게 조정하세요. 모든 포트를 모든 스니퍼에 맡긴다고 정확도가 높아지는 것은 아니며 오히려 오판과 문제 해결 비용이 증가할 수 있습니다.

override-destination은 스니핑으로 얻은 대상을 원래 대상 정보에 덮어씁니다. 활성화하면 도메인 규칙이 더 쉽게 일치하지만 잘못된 스니핑 결과가 연결 방향에 직접 영향을 주므로 명확한 프로토콜에서만 켜는 것이 일반적입니다. force-domain은 특정 도메인이 스니핑 결과를 사용하도록 강제하고, skip-domain은 호환되지 않는 것으로 알려진 서비스에 사용합니다. 도메인 매칭 문법은 코어가 지원하는 와일드카드 규칙을 따라야 하며, 수정 후 로그에서 추출된 도메인이 실제 요청과 일치하는지 확인하세요.

스니핑, DNS와 규칙의 처리 순서

하나의 연결에는 앱이 제출한 도메인, DNS 매핑에 저장된 도메인, 스니핑으로 얻은 도메인이라는 세 종류의 대상 정보가 포함될 수 있습니다. 앱이 일반 프록시 프로토콜로 도메인을 제출한다면 대개 추가 스니핑이 필요하지 않습니다. 앱이 IP에만 연결한다면 코어가 매핑이나 핸드셰이크에서 도메인을 복원해야 합니다. 규칙 엔진이 최종적으로 어떤 정보를 사용할지는 트래픽 가로채기 방식과 설정에 따라 달라집니다. 문제를 점검할 때 로그에서 대상이 IP에서 도메인으로 바뀌었는지, 어떤 규칙에 일치했는지, 최종 연결의 실제 주소가 무엇인지 확인하세요.

스니핑은 DNS를 대체할 수 없습니다. 스니핑은 연결이 시작된 후에 발생하므로 노드 서버 도메인, 규칙 제공자 주소와 식별 가능한 핸드셰이크가 없는 일부 프로토콜은 여전히 정상적인 해석에 의존합니다. 스니핑은 규칙 설계도 대체하지 않습니다. 도메인을 추출한 뒤에도 해당 연결을 올바른 프록시 그룹으로 보내려면 DOMAIN, DOMAIN-SUFFIX 또는 룰셋이 필요합니다. 로그에 이미 올바른 도메인이 표시되는데도 잘못된 그룹으로 연결된다면 스니핑 포트를 계속 늘리지 말고 규칙 순서를 다시 점검하세요.

일반적인 오판과 예외 처리

일부 앱은 비표준 포트에서 사용자 지정 프로토콜을 사용하며 데이터 시작 부분이 우연히 HTTP나 TLS와 비슷할 수 있습니다. 공유 주소와 프런트 도메인을 사용하는 서비스에서는 핸드셰이크 도메인이 사용자 화면의 서비스 도메인과 다를 수도 있습니다. 스니핑을 켠 뒤 연결에 실패하고 끄면 복구된다면 먼저 대상 IP, 포트, 스니핑된 도메인과 일치 규칙을 기록하세요. 특정 서비스 하나의 문제로 확인되면 전체 스니핑을 끄기보다 해당 서비스를 건너뛰기 목록에 추가하는 편이 적절합니다.

QUIC는 UDP 기반이므로 네트워크, 방화벽과 프록시 노드의 UDP 지원 여부에 큰 영향을 받습니다. 브라우저가 같은 웹사이트에 접속할 때 QUIC와 TCP/TLS 사이를 전환할 수 있어 문제가 간헐적으로 나타나기도 합니다. 로그에서 두 연결의 대상과 정책을 비교하세요. 노드가 UDP를 지원하지 않는다면 정책을 조정하거나 앱이 폴백하도록 해야 하며 모든 UDP 문제를 DNS 탓으로 돌려서는 안 됩니다. 모바일 기기가 절전에서 깨어나거나 Wi-Fi에서 셀룰러 데이터로 전환한 뒤에는 이전 연결이 남아 있을 수 있으므로 새 설정을 확인하려면 연결을 다시 만들어야 합니다.

로그로 재현 가능한 사례 만들기

스니핑 설정을 조정할 때마다 필드는 하나만 바꾸고 같은 앱, 같은 도메인과 같은 네트워크로 테스트를 고정하세요. 끈 상태와 켠 상태의 대상 표시, 규칙 일치 결과와 오류 유형을 기록합니다. 오류가 timeout이면 대상에 접근할 수 없는지, 정책 노드에 접근할 수 없는지, UDP를 사용할 수 없는지 추가로 구분해야 합니다. 인증서 도메인이 일치하지 않는 오류라면 덮어쓴 대상이 올바른지 중점적으로 확인하세요. 로그 필드와 흔한 연결 오류를 읽는 방법은 Clash 실행 로그 문제 해결 가이드를 참고하세요.

06

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

구독은 보통 노드, 기본 프록시 그룹과 일부 규칙을 제공하지만, 사용자의 로컬 네트워크 예외, DNS 선호 설정과 TUN 설정을 원격 구독에 직접 기록하는 것은 적합하지 않습니다. 구독이 업데이트되면 클라이언트가 설정을 다시 생성하므로 생성된 파일을 직접 편집한 내용은 덮어쓰일 수 있습니다. 더 안정적인 구조는 원격 콘텐츠를 “입력”으로 보고 장기간 유지할 로컬 설정을 오버라이드, 병합 스크립트 또는 독립된 주 설정에 두는 것입니다. 클라이언트마다 “오버라이드”, “확장”, “병합”의 명칭과 문법이 완전히 같지 않으므로, 사용 전에 실제로 대체하는지 얕은 병합인지 깊은 병합인지 확인하세요.

대체, 추가와 깊은 병합 구분하기

YAML 매핑과 목록은 병합 방식이 다릅니다. 매핑의 dns.enable은 키 단위로 덮어쓸 수 있지만 rules, proxies, proxy-groups는 목록입니다. 많은 도구는 목록을 만나면 자동으로 추가하지 않고 전체를 대체합니다. 로컬 규칙 한 줄만 작성했는데 구독의 기존 규칙이 모두 교체되어 로컬 항목만 남을 수 있습니다. 일부 클라이언트는 prepend, append 같은 명시적 작업을 제공해 목록의 앞이나 끝에 규칙을 삽입할 수 있습니다. 시작하기 전에 쉽게 식별할 수 있는 테스트 규칙 하나를 사용해 최종 설정을 내보내고, 규칙의 위치와 기존 내용 보존 여부를 확인하세요.

로컬 오버라이드는 포트, 로그 수준, DNS, TUN, 스니핑과 소수의 규칙 예외를 저장하는 데 적합합니다. 노드와 자주 바뀌는 원격 규칙은 구독이나 provider가 계속 관리하도록 두는 편이 좋습니다. 같은 필드를 여러 계층에서 동시에 수정하지 마세요. 예를 들어 구독 변환 템플릿, 클라이언트 오버라이드와 시작 매개변수에서 모두 mixed-port를 설정하면 최종값이 적용 순서에 따라 달라져 원인을 추적하기 어렵습니다.

# 로컬 주 설정 예시: 노드는 provider가 업데이트하고,
# 규칙과 정책 이름은 안정적으로 유지합니다.
proxy-providers:
  work-subscription:
    type: http
    url: https://subscription.example.com/work.yaml
    path: ./providers/work.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: 기본 프록시
    type: select
    use:
      - work-subscription
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,internal.example,DIRECT
  - GEOIP,LAN,DIRECT,no-resolve
  - MATCH,기본 프록시

예시 주소는 provider 구조를 보여 주기 위한 것입니다. 실제 구독 주소에는 보통 접근 자격 증명이 포함되므로 공개 로그, 스크린샷 또는 공유 설정에 복사해서는 안 됩니다. use가 참조하는 것은 proxy-providers의 이름이지 노드 이름이 아닙니다. provider가 업데이트되면 이를 참조하는 프록시 그룹에 새 노드가 들어오고, 규칙은 안정적인 “기본 프록시”를 계속 가리킵니다. 따라서 구독 측에서 노드를 추가하거나 삭제해도 라우팅 계층이 깨지지 않습니다.

다중 구독 병합 시 이름 지정과 중복 제거

업무용, 개인용 또는 서로 다른 출처의 구독을 함께 사용할 때 가장 흔한 문제는 노드 이름 중복입니다. 두 provider에 모두 “홍콩 01”이 있으면 하나의 목록에 그대로 펼쳤을 때 출처를 구분하기 어렵습니다. 각 provider를 독립적으로 보관하고 filter, exclude-filter 또는 클라이언트가 지원하는 이름 접두사로 구분하는 편이 좋습니다. 필터 표현식은 간단한 키워드부터 시작해 그룹 안의 노드 수가 적절한지 확인한 다음 조건을 늘리세요. 정규식이 지나치게 복잡하면 모든 노드가 필터링될 수 있습니다.

다중 구독을 사용한다고 해서 모든 노드를 하나의 자동 테스트 그룹에 넣어야 하는 것은 아닙니다. “업무 회선”과 “일상 회선”이라는 두 하위 그룹을 만든 다음 상위 수동 그룹에서 선택할 수 있습니다. 업무 서비스 규칙은 업무 그룹만 가리키고 일상 트래픽은 기본 그룹으로 보내 자동 테스트 중 업무 출구가 요구 사항에 맞지 않는 출처로 바뀌는 것을 막으세요. 서로 다른 구독에 이름이 같은 프록시 그룹이 있다면 로컬 주 설정에서 일관되게 다시 이름을 정하고 원격 그룹 이름이 계속 유지될 것이라고 기대하지 마세요.

업데이트 전 확인과 실패 시 복구

구독을 업데이트하기 전에 원본 구독만 저장하지 말고, 마지막으로 작동한 최종 설정을 보존하세요. 업데이트가 끝나면 네 가지를 확인합니다. 설정이 정상적으로 파싱되는지, 핵심 프록시 그룹이 여전히 존재하는지, 그룹 안에 노드가 있는지, 규칙 마지막에 대체 규칙이 남아 있는지입니다. 그 후 연결을 테스트하세요. 업데이트 후 클라이언트가 시작되지 않으면 먼저 이전 최종 설정을 복구한 다음 노드, 그룹 이름과 목록 들여쓰기를 비교하세요. 작동하지 않는 설정을 계속 수정할 필요는 없습니다.

YAML은 들여쓰기에 민감하며 목록 항목은 올바른 계층에 있어야 합니다. 탭, 전각 문장 부호와 비슷해 보이는 특수 공백도 파싱 실패를 일으킬 수 있습니다. 구독 변환 도구가 생성한 설정도 일반 설정처럼 검사해야 하며 자동 생성되었다는 이유로 검증을 건너뛰어서는 안 됩니다. provider 경로를 사용하는 경우 디렉터리가 존재하고 쓰기 가능한지 확인하세요. 여러 파일을 사용한다면 주 설정을 옮긴 뒤 상대 경로도 함께 점검해야 합니다.

클라이언트 간 설정 이전

Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu 등의 클라이언트는 모두 mihomo 설정을 기반으로 사용할 수 있지만, 화면에서 오버라이드를 적용하는 방식, 설정 디렉터리와 서비스 모드는 서로 다릅니다. 이전할 때는 기기 전용 경로가 없는 핵심 YAML을 먼저 가져온 다음 새 클라이언트 화면에서 시스템 프록시, TUN 권한과 시작 시 실행을 설정하세요. 캐시, 잠금 파일과 플랫폼 경로가 새 환경에 따라 들어올 수 있으므로 기존 클라이언트의 데이터 디렉터리 전체를 그대로 복사하지 마세요. 클라이언트 선택과 플랫폼별 차이는 클라이언트 비교에서 확인할 수 있습니다.

07

외부 컨트롤 패널

mihomo는 연결 확인, 정책 전환, 제공자 업데이트와 로그 조회에 사용할 외부 제어 인터페이스를 제공합니다. 데스크톱 클라이언트의 기본 화면은 대개 이 인터페이스에 연결되어 있습니다. 서버, 라우터 또는 순수 명령줄 환경에서는 독립적인 웹 컨트롤 패널을 함께 사용할 수 있습니다. 제어 인터페이스는 실행 상태를 변경할 수 있으므로 일반 웹 서비스가 아닌 관리 진입점으로 취급해야 합니다. 안전한 설정의 핵심은 수신 범위를 제한하고 접근 자격 증명을 설정하며, 신뢰할 수 있는 네트워크나 리버스 프록시를 통해 원격 접근을 제공하는 것입니다.

수신 주소와 접근 범위

external-controller: 127.0.0.1:9090
secret: "your-control-secret"
external-ui: ./ui
external-ui-name: dashboard

127.0.0.1:9090은 로컬 기기의 연결만 허용하므로 데스크톱 클라이언트나 컨트롤 패널과 코어가 같은 기기에서 실행되는 경우에 적합합니다. 0.0.0.0:9090으로 바꾸면 로컬 네트워크의 다른 기기도 접근할 수 있으므로 방화벽과 강력한 접근 자격 증명을 함께 설정해야 합니다. 예시의 자격 증명은 교육용 가짜 값입니다. 실제 배포에서는 별도의 추측하기 어려운 값을 사용하고 구독 주소나 다른 계정과 공유하지 마세요.

external-ui는 정적 컨트롤 패널 파일 디렉터리를 가리키며, 디렉터리에는 패널 진입 파일이 있어야 합니다. external-ui-name은 화면 디렉터리의 이름을 구분하거나 지정하는 데 사용합니다. 구체적인 다운로드 및 업데이트 방식은 사용하는 컨트롤 패널과 코어 설정에 따라 달라집니다. 인터페이스에는 연결되지만 페이지가 비어 있다면 정적 파일 경로와 프로세스 작업 디렉터리를 확인하세요. 페이지는 열리지만 코어에 연결할 수 없다는 메시지가 나오면 제어 인터페이스 주소, 프로토콜, 브라우저의 동일 출처 제한과 자격 증명을 점검해야 합니다.

로컬 네트워크와 원격 접근의 경계

로컬 네트워크에서 관리할 때는 제어 인터페이스가 내부 주소를 수신하도록 하고 관리 기기가 속한 네트워크 대역만 접근하도록 제한할 수 있습니다. 제어 포트를 인터넷에 직접 노출하지 마세요. 원격 관리가 필요하다면 먼저 신뢰할 수 있는 VPN에 접속하거나 인증과 TLS를 사용하는 리버스 프록시를 통해 접근하는 편이 적절합니다. 리버스 프록시에서도 허용 메서드, 요청 본문 크기와 출처를 제한해 웹에 접근할 수 있는 사람이 누구나 코어를 조작하지 못하게 해야 합니다.

컨트롤 패널에서 정책을 전환하면 현재 실행 상태가 바뀌지만 원본 설정에 기록되는 것은 아닐 수 있습니다. 재시작 후 선택을 유지할지는 profile.store-selected 같은 영속화 설정과 클라이언트 구현에 따라 달라집니다. 재시작 후에도 정책 선택을 복원하려면 해당 영속화 기능을 활성화하세요. 서버가 시작할 때마다 고정 출구로 돌아가야 한다면 저장을 끄고 설정에서 기본 순서를 명확히 지정해야 합니다.

profile:
  store-selected: true
  store-fake-ip: true

log-level: info
unified-delay: true
tcp-concurrent: true

store-selected는 프록시 그룹의 현재 선택을 저장하고, store-fake-ip는 Fake-IP 매핑을 저장해 재시작 후 일부 연결 동작을 유지하는 데 도움을 줍니다. 저장 파일을 만들려면 작업 디렉터리에 쓰기 권한이 필요합니다. log-level: info는 일상적인 관찰에 적합합니다. 문제를 해결할 때는 일시적으로 더 자세한 수준으로 높일 수 있지만 상세 로그를 장기간 남기면 디스크 쓰기와 정보 노출 범위가 늘어납니다. unified-delay는 지연 시간 테스트를 보다 통일된 방식으로 계산하며, tcp-concurrent는 대상 주소에 동시에 연결을 시도해 일부 듀얼 스택 연결 수립을 개선합니다. 적합성은 기기 자원과 네트워크 성능을 기준으로 테스트해야 합니다.

컨트롤 패널에서 올바르게 문제 해결하기

연결 목록은 세 가지 질문에 답하는 데 유용합니다. 앱이 어느 대상에 연결했는지, 어떤 규칙에 일치했는지, 마지막으로 어떤 정책을 사용했는지입니다. 웹사이트가 열리지 않으면 먼저 대상 도메인으로 연결을 필터링해 요청이 나타나는지 확인하세요. 연결 기록이 없다면 트래픽이 코어에 들어오지 않았을 수 있으므로 시스템 프록시나 TUN을 점검해야 합니다. 기록은 있지만 대상이 IP뿐이라면 DNS와 스니핑을 추가로 확인하세요. 규칙과 정책은 올바른데 연결 시간이 초과된다면 노드와 대상의 접근성을 점검합니다.

프록시 그룹 페이지의 지연 시간 테스트는 건강 상태 확인의 한 방법일 뿐 회선 점수가 아닙니다. 테스트 주소에는 빠르게 응답해도 특정 서비스에는 사용할 수 없는 노드가 있을 수 있습니다. 실제 연결 로그와 함께 판단하세요. 제공자 페이지에서 업데이트가 실패하면 프록시 제공자인지 규칙 제공자인지 확인하고 구독 주소, 규칙 주소, DNS와 쓰기 권한을 각각 점검합니다. 한 번의 클릭으로 업데이트를 여러 번 연속 실행하면 요청이 겹칠 수 있으므로 현재 작업이 끝난 후 다시 시도하는 편이 명확한 로그를 얻기 쉽습니다.

설정 변경의 안전한 절차

제어 인터페이스로 설정을 다시 불러오기 전에 별도 위치에서 문법 검사를 완료하세요. 원격 서버에서 수신 주소, TUN 또는 기본 경로를 변경할 때는 현재 관리 세션을 유지하고 이전 설정을 복구할 수 있는 서비스 명령을 준비해야 합니다. systemd로 배포했다면 먼저 서비스 로그를 확인한 뒤 통제된 재시작을 수행하세요. 새 설정을 읽을 수 있는지 확인하기 전에는 기존 파일을 삭제하지 마세요. 서비스가 반복적으로 시작에 실패한다면 자동 재시작을 중지하고 최초 실패의 오류 행을 직접 확인하세요. 이후 오류는 대부분 첫 번째 문제의 연쇄 결과일 뿐입니다.

# 서비스 상태와 최근 로그 확인
systemctl status mihomo
journalctl -u mihomo -n 100 --no-pager

# 설정 확인 후 재시작
sudo systemctl restart mihomo

시스템 서비스 이름은 실제 설치 방식에 따라 달라질 수 있으므로 실행 전에 로컬 시스템의 유닛 이름을 확인하세요. 순수 명령줄 배포에는 더 많은 시스템 관리 지식이 필요합니다. 구독, 정책과 시스템 프록시를 직접 관리하려는 데스크톱 사용자는 먼저 Linux 클라이언트나 해당 플랫폼의 GUI 클라이언트로 시작하는 것이 좋습니다. Linux 데스크톱과 systemd 두 배포 방식은 Clash Linux 설치 가이드에서 이어서 확인할 수 있습니다.