Clash 고급 설정: 정책, DNS 및 트래픽 가로채기

01 / 정책 구성

정책 그룹 유형과 실제 조합

정책 그룹은 규칙과 개별 프록시 사이에 위치합니다. 규칙은 연결이 어떤 트래픽에 속하는지만 판단하고, 실제로 어떤 프록시를 사용할지, 자동 테스트를 수행할지, 실패하면 어떻게 전환할지는 정책 그룹이 결정합니다. 장기적으로 관리하기 쉬운 설정의 핵심은 모든 노드를 하나의 그룹에 넣는 것이 아니라 용도별로 안정적인 추상화 계층을 먼저 만드는 것입니다. 예를 들어 규칙은 “해외 웹사이트”, “스트리밍”, “메신저”, “기타 트래픽”만 참조하게 하면 구독이 바뀌어 노드 이름이 달라져도 규칙을 함께 수정할 필요가 없습니다.

select, url-test, fallback 및 load-balance

select는 수동 선택 그룹으로, 출구를 직접 제어해야 하는 상황에 적합합니다. 노드 품질을 자동으로 판단하지 않으며 현재 멤버를 사용할 수 없게 되어도 다른 멤버로 자동 전환하지 않습니다. 따라서 일반적으로 원본 노드만 넣기보다 여러 자동 정책 그룹을 select 안에 배치합니다. url-test는 지정한 주소를 주기적으로 테스트한 뒤 결과가 더 나은 멤버를 선택합니다. 테스트 결과는 테스트 주소까지의 연결 상태를 보여 줄 뿐 모든 웹사이트의 실제 속도를 의미하지는 않습니다. 간격을 너무 짧게 설정하면 추가 연결이 발생하므로 모바일 네트워크에서는 특히 자주 실행할 필요가 없습니다.

fallback은 멤버 순서대로 사용 가능한 첫 항목을 선택하므로 최단 테스트 시간을 고르는 방식이 아니라 안정적인 주 회선과 예비 회선을 구성하는 데 초점이 있습니다. 고정 회선을 우선 사용하고 장애 시 예비 회선으로 전환하려면 url-test보다 결과를 예측하기 쉽습니다. load-balance는 여러 멤버에 연결을 분산하며, 동시 요청이 많고 서비스 측에서 출구 변경을 허용하는 환경에 적합합니다. 로그인, 결제, 보안 심사가 엄격한 웹사이트는 짧은 시간 내 출구가 바뀌는 것을 이상 동작으로 판단할 수 있으므로 모든 트래픽의 기본 정책으로 설정해서는 안 됩니다.

안정적인 2단계 정책 구조 만들기

일반적인 구조는 1단계에서 지역이나 회선 특성에 따라 자동 선택하고, 2단계에서 서비스 용도별로 수동 선택하는 방식입니다. 아래 예시의 “자동 선택”은 구독 제공자에서 노드를 필터링하고, “해외 웹사이트”는 자동 선택, 장애 전환, 직접 연결 중에서 바꿀 수 있게 합니다. 이렇게 구성하면 규칙은 “해외 웹사이트”만 참조하고 일상적인 조정은 정책 그룹에 집중할 수 있어, 특정 구독 서비스와 규칙 파일이 지나치게 결합되는 것을 막을 수 있습니다.

proxy-groups:
  - name: 자동 선택
    type: url-test
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80

  - name: 장애 전환
    type: fallback
    use:
      - provider-main
      - provider-backup
    url: https://www.gstatic.com/generate_204
    interval: 600

  - name: 해외 웹사이트
    type: select
    proxies:
      - 자동 선택
      - 장애 전환
      - DIRECT

use는 프록시 제공자를 참조하고, proxies는 명시적으로 나열한 프록시나 다른 정책 그룹을 참조합니다. 구독 노드를 필터링할 때는 filter를 사용할 수 있지만, 정규식은 안정적인 키워드를 중심으로 작성해야 하며 구독 이름에서 자주 바뀌는 장식 문자는 피해야 합니다. 노드 이름만으로 용도를 안정적으로 구분하기 어렵다면 오탐을 일으키는 넓은 표현식을 쓰기보다 수동 선택을 유지하는 편이 낫습니다.

정책 그룹을 조정한 뒤에는 먼저 참조 관계를 확인해야 합니다. 규칙 대상과 정책 그룹 멤버가 모두 존재해야 하며 그룹끼리 순환 참조를 만들면 안 됩니다. 클라이언트에서 가져온 뒤 설정 파싱 오류가 표시되면 새로 추가한 그룹을 잠시 제거한 다음 구간별로 다시 복원해 보세요. 정책 그룹 자체에 매칭되는 트래픽이 없으면 연결 경로가 바뀌지 않으므로, 문제를 찾을 때는 로그를 함께 확인해 최종 규칙이 실제로 해당 그룹을 가리키는지 확인해야 합니다.

02 / 규칙 관리

규칙 제공자와 매칭 순서

Clash 규칙은 위에서 아래로 처리되며, 일치하는 즉시 중단됩니다. 규칙 수보다 순서가 중요합니다. 정확한 도메인을 더 넓은 접미사 규칙 뒤에 두면 의미가 없어지고, 로컬 네트워크나 직접 연결해야 하는 서비스가 넓은 프록시 규칙 뒤에 있으면 먼저 가로채일 수 있습니다. 마지막에는 보통 MATCH를 두어 앞선 규칙에 포함되지 않은 연결을 처리하고 모든 트래픽에 명확한 목적지를 부여합니다.

인라인 규칙과 규칙 제공자

개인 환경과 밀접한 소량의 규칙은 주 설정의 rules에 작성하는 것이 적합합니다. 예를 들어 가정용 저장 장치, 개발 환경 도메인, 반드시 직접 연결해야 하는 특정 웹사이트 등이 있습니다. 규모가 크고 지속적인 업데이트가 필요한 공용 규칙은 rule-providers에 맡기는 편이 좋습니다. 규칙 제공자를 사용하면 규칙 내용과 주 설정을 분리하고 다운로드 주소, 로컬 캐시 경로, 형식 및 업데이트 주기를 지정할 수 있습니다. 업데이트에 실패해도 코어는 보통 캐시된 규칙 파일을 계속 사용하므로 캐시 경로에 쓰기 권한이 있어야 하며 여러 제공자가 같은 파일을 가리켜서는 안 됩니다.

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

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

rules:
  - DOMAIN,router.local,DIRECT
  - DOMAIN-SUFFIX,lan,DIRECT
  - RULE-SET,private-direct,DIRECT
  - RULE-SET,service-proxy,해외 웹사이트
  - GEOIP,CN,DIRECT
  - MATCH,해외 웹사이트

예시의 도메인은 예약된 테스트 도메인이므로 실제로 이용할 수 있는 규칙 주소를 뜻하지 않습니다. 실제 사용 시에는 신뢰할 수 있고 직접 관리할 수 있는 규칙 소스로 바꾸세요. behavior: domain은 도메인 규칙만 담으므로 파일을 간결하게 유지할 수 있습니다. classical은 DOMAIN-SUFFIX, IP-CIDR, PROCESS-NAME 등 기존 규칙 문법을 담을 수 있어 호환 범위가 넓지만, 파싱과 매칭 구조는 더 복잡합니다. 동작 유형은 원격 파일의 실제 내용과 일치해야 하며 주 설정의 필드만 바꾸고 규칙 파일 형식을 무시해서는 안 됩니다.

좁은 규칙부터 넓은 규칙 순으로 배치하기

설명 가능한 순서는 보통 로컬 예외 규칙, 로컬 네트워크 직접 연결, 명확히 프록시가 필요한 서비스, 명확히 직접 연결해야 하는 서비스, 지역 데이터베이스 규칙, 마지막으로 MATCH입니다. 특정 도메인이 공용 규칙을 덮어써야 한다면 사용자 지정 규칙을 해당 공용 규칙보다 앞에 배치하세요. IP 규칙에는 no-resolve를 추가해 매칭 과정에서 대상 IP를 얻기 위한 DNS 조회가 자동으로 발생하지 않게 할 수 있습니다. 다만 연결 자체에 이미 IP가 제공되거나 앞선 과정에서 IP를 얻을 수 있을 때만 의미가 있습니다.

rules:
  - DOMAIN,api.example.invalid,DIRECT
  - DOMAIN-SUFFIX,example.invalid,해외 웹사이트
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,해외 웹사이트

위 예시는 먼저 특정 호스트 하나를 직접 연결한 뒤, 같은 접미사를 사용하는 다른 도메인은 프록시로 보냅니다. 이는 “더 구체적인 규칙을 앞에 둔다”는 원칙을 보여 줍니다. 실제 설정에서는 DOMAIN-KEYWORD도 주의해야 합니다. 같은 문자열을 포함하지만 용도가 전혀 다른 도메인까지 잘못 매칭하기 쉽기 때문입니다. 접미사 규칙으로 표현할 수 있다면 우선 DOMAIN-SUFFIX를 사용하고, 단일 호스트를 정확히 제어해야 할 때는 DOMAIN을 사용하세요.

규칙 업데이트와 롤백

규칙 제공자 업데이트를 클라이언트 업그레이드와 같은 작업으로 취급해서는 안 됩니다. 클라이언트, 코어, 구독 노드 및 규칙 제공자는 각각 다른 변경 주기를 가집니다. 한 번에 한 계층만 바꾸고, 로그에서 규칙 제공자가 정상적으로 로드되는지 확인한 뒤 대표 도메인 몇 곳을 검증하세요. 업데이트 후 여러 웹사이트의 경로가 이상해지면 DNS, TUN, 정책 그룹을 동시에 수정하기보다 먼저 이전 규칙 캐시를 복원하거나 새 제공자를 잠시 비활성화하세요. 개인 규칙을 별도 파일에 저장하면 구독 새로 고침으로 로컬 수정 사항이 덮어써지는 것을 막을 수 있습니다.

로그에 규칙 제공자 다운로드 실패가 표시되면 먼저 URL 접근 가능 여부, 파일 형식 일치 여부, 캐시 디렉터리의 쓰기 권한을 확인하세요. 시작 단계에서만 실패하고 이후 수동 업데이트는 성공한다면 기기가 인터넷에 연결된 직후 네트워크가 아직 준비되지 않았을 가능성이 있습니다. 이 경우 자동 업데이트 간격을 늘리고 유효한 캐시를 유지하세요. 규칙 관련 기본 용어는 개념 빠른 확인에서 찾아볼 수 있습니다. 규칙 이름만 보고 효과를 판단하지 말고, 최종 기준은 연결 로그에 표시되는 매칭 규칙과 정책 그룹입니다.

03 / 이름 확인

DNS 설정 최적화와 조회 경로

DNS 설정은 도메인을 주소로 변환하는 방식과 규칙이 충분한 정보를 확보할 수 있는지에 영향을 줍니다. 문제를 노드 불량으로 오해하기 쉽지만, 노드 연결이 정상이어도 도메인 조회 실패, 부적절한 응답 또는 잘못된 네트워크로의 조회는 웹페이지가 열리지 않는 결과를 만들 수 있습니다. 문제를 진단할 때는 “DNS 조회를 누가 처리하는가”, “어디로 조회를 보내는가”, “결과가 규칙 매칭에 어떻게 들어가는가”를 세 단계로 나누어 확인하고 노드만 반복해서 바꾸지 마세요.

기본 리스너와 업스트림 역할 분담

enable은 mihomo DNS 모듈의 활성화 여부를 제어하고, listen은 수신 주소를 결정합니다. 기기 내부에서만 사용할 때는 루프백 주소에서 수신하는 것이 우선입니다. Android 클라이언트는 보통 앱이 수신과 VPN 가로채기를 관리하므로 로컬 네트워크 기기에 포트를 개방할 필요가 없습니다. default-nameserver는 주로 암호화 DNS 업스트림 자체의 도메인을 확인하는 데 사용하므로 직접 접근 가능한 IP 주소 기반 리졸버를 지정하는 경우가 많습니다. nameserver는 일반 조회를 담당하고, proxy-server-nameserver는 프록시 서버 도메인을 별도로 확인해 아직 구성되지 않은 프록시 경로에 의존하는 문제를 줄입니다.

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 1.1.1.1
    - 8.8.8.8
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  proxy-server-nameserver:
    - 1.1.1.1
    - 8.8.8.8

업스트림 주소는 현재 네트워크에서 접근 가능한지를 기준으로 선택해야 하며, 많다고 좋은 것은 아닙니다. 여러 리졸버에 병렬로 조회하면 서로 다른 결과가 나올 수 있고 원인 파악도 어려워집니다. 먼저 안정적인 업스트림 세트로 기준을 만든 다음 필요할 때 분기 조회를 추가하세요. 프록시 서버가 도메인을 사용한다면 프록시 시작 전에 해당 도메인을 확인할 수 있어야 합니다. 그렇지 않으면 “프록시를 만들려면 DNS가 필요하지만 DNS에는 프록시가 필요한” 순환이 발생합니다.

redir-host와 fake-ip의 차이

redir-host는 실제 조회 주소를 반환하므로 시스템의 기존 동작과 가깝고 호환성을 이해하기 쉽습니다. 다만 이후 단계에서 코어가 IP만 볼 수 있어 도메인 규칙의 적용 여부는 트래픽 진입점과 매핑 정보에 따라 달라집니다. fake-ip는 예약된 네트워크 대역의 임시 주소를 도메인에 할당합니다. 앱이 해당 주소로 연결하면 코어가 매핑을 통해 원래 도메인을 복원한 뒤 규칙을 적용합니다. 일반적으로 TUN 환경에서 도메인 규칙을 일관되게 적용하고 실제 DNS 결과가 앱에 먼저 노출되는 기회를 줄이는 데 도움이 됩니다.

Fake-IP는 원격 서버 주소가 아니므로 DNS 오류로 보면 안 됩니다. 198.18.0.0/16 범위의 결과가 보인다면 보통 향상된 모드가 작동 중이라는 뜻입니다. 실제로 확인할 부분은 연결이 코어에 의해 가로채어졌는지와 해당 매핑이 아직 존재하는지입니다. 일부 로컬 네트워크 검색, 기기 화면 전송, 연결 상태 확인, 특수한 DNS 응답에 의존하는 앱은 Fake-IP와 맞지 않을 수 있으므로 필터 목록을 사용해 해당 도메인이 실제 결과를 반환하도록 할 수 있습니다.

dns:
  enhanced-mode: fake-ip
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "+.stun.*.*"
    - "connectivitycheck.gstatic.com"

필터 항목은 실제 로그를 보면서 단계적으로 추가해야 합니다. 너무 많은 접미사를 필터 목록에 넣으면 Fake-IP의 도메인 식별 기능이 약해지고, 너무 적게 넣으면 로컬 네트워크 서비스 검색이 실패할 수 있습니다. 변경 후에는 이전 DNS 캐시를 삭제하거나 코어를 재시작해 기존 매핑이 판단에 영향을 주지 않게 하세요.

도메인별 리졸버 선택

nameserver-policy를 사용하면 특정 도메인이나 규칙 제공자에 지정한 리졸버를 적용할 수 있습니다. 예를 들어 내부 도메인은 가정용 라우터에 맡기고 공용 도메인은 암호화 DNS로 보낼 수 있습니다. 정책은 한 방향으로 설명 가능해야 합니다. 내부 리졸버를 모든 조회의 무작위 후보로 사용하지 말고 내부 도메인에만 연결하세요. 모바일 기기가 Wi-Fi와 셀룰러 네트워크 사이를 오갈 때 로컬 네트워크 리졸버에 갑자기 접근할 수 없게 될 수 있으므로, 로컬 주소에 의존하는 정책은 네트워크 변경 후의 실패 상황도 고려해야 합니다.

dns:
  nameserver-policy:
    "router.local": 192.168.1.1
    "+.home.arpa": 192.168.1.1
    "+.example.invalid":
      - https://1.1.1.1/dns-query

DNS 문제를 확인하는 순서는 고정하는 것이 좋습니다. 먼저 도메인 조회 로그가 생성되는지 확인하고, 다음으로 업스트림이 응답했는지, 그다음 규칙이 매칭되었는지, 마지막으로 예상한 정책 그룹을 통해 연결되었는지 확인하세요. IP 주소로는 접근되지만 도메인으로는 접근되지 않는다면 문제는 조회 계층에 있을 가능성이 큽니다. 도메인이 이미 확인되었고 로그에 연결 실패가 표시된다면 DNS를 계속 바꾸지 말고 노드, 라우팅 또는 TUN을 점검하세요.

04 / 트래픽 가로채기

TUN, Fake-IP 및 Android VPN 인터페이스

TUN 모드는 가상 네트워크 인터페이스로 시스템 트래픽을 받아 시스템 프록시 설정을 읽지 않는 앱도 mihomo로 전달합니다. Android 클라이언트는 시스템 VPN 권한으로 이 인터페이스를 만들므로 상태 표시줄에 VPN 아이콘이 나타나는 것은 정상입니다. TUN은 트래픽 진입점을 해결하고 Fake-IP는 도메인 매핑과 식별을 해결합니다. 둘은 자주 함께 사용되지만 같은 기능은 아닙니다.

자동 라우팅과 엄격한 라우팅

auto-route는 코어가 라우팅을 자동으로 구성해 대상 트래픽을 TUN 인터페이스로 보냅니다. strict-route는 예상대로 인터페이스에 들어오지 않은 경로를 더 엄격하게 제한해 다른 라우팅으로 우회하는 트래픽을 줄이지만, 핫스팟 공유, 로컬 네트워크 접근, 기업 VPN 또는 특수한 시스템 라우팅과의 충돌을 키울 수도 있습니다. 처음 활성화할 때는 자동 라우팅으로 기본 접근이 정상인지 확인한 뒤 누수 방지와 앱 호환성 요구에 따라 엄격한 라우팅을 검토하세요.

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

stack은 TUN 네트워크 스택 구현을 결정합니다. mixed는 일반적으로 호환성과 성능을 함께 고려할 때 사용합니다. 시스템과 클라이언트 패키징에 따라 선택 가능한 값이 다를 수 있으므로 현재 클라이언트가 허용하는 설정을 기준으로 해야 합니다. 네트워크 스택 전환은 진단 수단이며 명확한 장애 증거 없이 자주 바꾸지 마세요. auto-detect-interface는 실제 외부 연결 인터페이스를 식별하는 기능으로, Wi-Fi와 모바일 네트워크를 오가는 기기에서 유용합니다.

DNS 가로채기의 범위

dns-hijack은 일반적인 DNS 포트로 전송되는 조회를 mihomo DNS 모듈로 넘겨 앱이 통합 조회 정책을 우회하기 어렵게 합니다. 하지만 앱에 내장된 암호화 DNS까지 반드시 가로채는 것은 아닙니다. 암호화 DNS는 일반 HTTPS 또는 TLS 연결처럼 보이기 때문입니다. 브라우저가 자체 보안 DNS를 사용하면 해당 도메인 조회가 mihomo의 일반 DNS 로그에 나타나지 않을 수 있습니다. 동작을 통일하려면 앱 설정에서 독립적인 조회 기능을 끄거나, 두 조회 경로를 모두 허용하고 각각 따로 진단해야 합니다.

가로채기 범위를 무한히 넓혀서도 안 됩니다. 로컬 네트워크 기기 검색, 통신사 인증 페이지 또는 기업 내부 도메인은 로컬 DNS에 의존할 수 있습니다. Wi-Fi 연결 후 인증 페이지가 나타나지 않거나 프린터 이름을 확인할 수 없다면 먼저 TUN을 일시 중지해 비교한 뒤, 직접 연결 규칙·실제 IP 필터·로컬 DNS 정책 중 적절한 방법을 선택하세요. DNS 설정을 전부 삭제하는 것은 마지막 수단입니다.

Android 앱별 트래픽 분기

Android의 VPN 인터페이스는 보통 한 번에 하나의 앱만 사용할 수 있습니다. 다른 VPN, 업무 프로필 관리 도구, VPN 기반 방화벽이나 필터 앱이 Clash Plus, Clash Meta for Android, FlClash, Surfboard와 충돌할 수 있습니다. 화면에는 시작됨으로 표시되지만 시스템에 VPN 인터페이스가 만들어지지 않는다면 다른 앱이 여전히 권한을 보유하고 있는지와 시스템이 백그라운드 실행 권한을 철회했는지 확인하세요.

클라이언트가 앱별 포함 또는 제외를 지원한다면 지정한 앱만 가로채거나 일부 로컬 네트워크 도구를 우회시킬 수 있습니다. 포함 모드는 테스트에 편리합니다. 먼저 브라우저 하나를 선택해 경로를 확인한 뒤 다른 앱을 단계적으로 추가하세요. 제외 모드는 대부분의 앱은 가로채고 은행 앱이나 로컬 네트워크 제어 앱만 예외로 둘 때 적합합니다. 두 모드를 동시에 적용하면 해석이 어려워지므로 하나의 명확한 규칙만 선택하고 어떤 앱이 시스템을 통해 직접 연결되는지 기록하세요.

TUN의 기본 작동 원리를 먼저 이해하려면 Android Clash TUN 모드 원리와 활성화 방법을 읽어 보세요. 이 장에서는 매개변수 간 관계에 더 집중합니다. 최종 판단은 스위치가 켜져 있는지가 아니라 시스템 VPN 인터페이스, DNS 로그, 연결 로그 및 규칙 매칭이 완전한 경로를 이루는지를 기준으로 해야 합니다.

05 / 도메인 복원

도메인 스니핑의 용도, 적용 범위와 한계

일부 연결은 코어에 들어올 때 대상 IP만 포함하므로 규칙 시스템이 원래 도메인을 직접 알 수 없습니다. 도메인 스니핑은 TLS 핸드셰이크의 서버 이름이나 HTTP 요청의 호스트 필드처럼 연결 초기에 확인할 수 있는 프로토콜 메타데이터를 읽어 도메인을 복원하고 다시 규칙 매칭에 참여시킵니다. 웹페이지 본문을 읽는 기능은 아니며 모든 암호화 연결에서 도메인을 얻을 수도 없습니다. 프로토콜에 확인 가능한 메타데이터가 있는지, 핸드셰이크 단계에서 연결을 가로챌 수 있는지가 결과에 영향을 줍니다.

TLS, HTTP 및 QUIC 스니핑

TLS 스니핑은 ClientHello의 SNI를 읽는 데 사용하고, HTTP 스니핑은 Host를 읽으며, QUIC 스니핑은 UDP 기반의 관련 핸드셰이크를 처리합니다. 활성화하는 프로토콜이 많을수록 적용 범위는 넓어지지만 오판과 호환성 문제도 늘어납니다. 처음에는 실제로 필요한 포트 범위만 활성화하고 제외 목록을 유지하는 것이 좋습니다. 특정 앱이 연결 직후 반복해서 재시도하거나 동영상 재생이 시작되지 않거나 로그의 도메인이 실제 서비스와 다르면 모든 규칙 시스템을 끄지 말고 해당 도메인이나 대상 네트워크 대역에서 스니핑을 비활성화하세요.

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

parse-pure-ip는 순수 IP 대상에서 도메인 복원을 시도하도록 합니다. force-dns-mapping은 DNS 매핑 정보를 함께 사용해 식별을 보조하며, Fake-IP와 코어 DNS가 이미 도메인 매핑을 알고 있을 때 특히 유용합니다. override-destination은 스니핑한 도메인을 이후 연결의 원래 대상에 덮어쓸지 결정합니다. 덮어쓰기는 일부 도메인 규칙의 일관성을 높일 수 있지만 고정 IP, 특수 인증서 동작 또는 사설 프로토콜에 의존하는 서비스에는 차이를 만들 수 있으므로 필요성을 확인한 뒤 활성화하는 편이 좋습니다.

스니핑과 Fake-IP 조합

Fake-IP 환경에서는 코어가 보통 가상 주소 매핑으로 원래 도메인을 이미 얻을 수 있으므로, 스니핑은 코어 DNS를 우회하거나 실제 IP에 직접 연결하는 트래픽을 보완하는 역할을 합니다. redir-host 또는 일부 투명 프록시 환경에서는 도메인 복원에 스니핑이 더 중요합니다. 두 기능을 함께 사용할 때는 도메인의 출처를 이해해야 합니다. 로그의 도메인은 DNS 매핑에서 왔을 수도 있고 프로토콜 핸드셰이크에서 왔을 수도 있습니다. 둘이 다르면 어떤 이름을 규칙 매칭과 연결에 사용할지는 덮어쓰기 정책이 결정합니다.

도메인 규칙을 설정했는데도 IP 규칙에 매칭된다고 해서 반드시 스니핑이 실패한 것은 아닙니다. 연결에 스니핑할 필드가 없거나, 암호화된 클라이언트 인사말 확장을 사용하거나, 스니핑이 끝나기 전에 IP 규칙으로 처리되었거나, 앱이 사용자 지정 프로토콜을 직접 사용할 수 있습니다. 문제를 진단할 때는 일반 HTTPS 웹사이트를 기준으로 삼아 로그에 SNI가 표시되는지 확인한 뒤 문제가 있는 앱을 테스트하세요. 스니핑을 지원하지 않는 프로토콜 하나만으로 전체 기능을 판단하지 마세요.

제외 목록과 위험 관리

skip-domain은 로컬 네트워크 도메인, 기기 검색 서비스, 스니핑 후 이상 동작이 확인된 서비스 도메인에 적합합니다. 일부 설정은 대상 주소나 출발지 주소 기준의 제외도 지원해 내부 네트워크에 활용할 수 있습니다. 제외 규칙은 가능한 한 구체적으로 작성하고 지나치게 넓은 접미사는 피하세요. 흔한 최상위 도메인 전체를 제외 목록에 넣으면 많은 공용 연결에서 도메인 복원 기능을 잃게 됩니다.

도메인 스니핑은 올바른 DNS 설정을 대신할 수 없습니다. DNS가 이미 실패하면 앱이 스니핑 가능한 연결 자체를 시작하지 못할 수 있고, IP로 연결하는 경우에도 스니핑이 반드시 이름을 복원해 주지는 않습니다. 먼저 DNS와 TUN 경로를 안정화한 다음 순수 IP 트래픽을 보완하는 방식으로 스니핑을 활성화하세요. 변경할 때마다 로그의 대상, 스니핑 결과, 매칭 규칙 및 최종 정책 그룹을 확인해야 하며 네 항목이 일치해야 기대한 동작으로 볼 수 있습니다.

모바일 네트워크에서는 UDP와 QUIC의 경로가 TCP와 다를 수 있습니다. 웹페이지는 열리지만 동영상이나 실시간 통신이 이상하다면 QUIC 스니핑을 일시적으로 끄거나 UDP 443을 차단하는 규칙으로 비교해 앱이 TCP로 폴백하도록 할 수 있습니다. 이 작업은 원인 파악을 위한 것이며 모든 UDP를 기본적으로 장기간 차단해서는 안 됩니다. 구체적인 서비스와 네트워크 조건을 확인한 뒤 유지할 프로토콜 범위를 결정하세요.

06 / 설정 구성

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

구독은 보통 서비스 제공자가 관리하며 새로 고칠 때 노드, 정책 그룹 또는 규칙이 바뀔 수 있습니다. 구독으로 생성된 주 설정을 직접 편집하면 다음 업데이트에서 로컬 수정 사항이 쉽게 사라집니다. 오버라이드의 목적은 “원격에서 자주 바뀌는 부분”과 “로컬에서 오래 유지할 부분”을 분리하는 것입니다. 노드 목록은 구독에서 가져오고 DNS, TUN, 개인 규칙 및 정책 구조는 로컬 오버라이드로 안정적으로 관리할 수 있습니다.

오버라이드 우선순위와 최소 수정 범위

클라이언트마다 오버라이드 구현의 명칭이 다르며 오버라이드, 믹스인, 설정 패치 또는 스크립트 처리라고 부르기도 합니다. 이름과 관계없이 먼저 병합 방향을 확인해야 합니다. 로컬 필드가 원격 필드를 덮어쓰는지, 배열을 원격 배열에 추가하는지 확인하세요. 매핑 필드는 키 기준으로 병합할 수 있지만 배열 필드는 통째로 교체될 수 있습니다. 규칙과 정책 그룹은 모두 배열이므로 “추가”라고 생각했지만 실제로는 “교체”가 발생하면 구독의 기존 규칙이 전부 사라질 수 있습니다.

가장 안전한 방법은 오버라이드 범위를 작게 유지하는 것입니다. DNS 향상 모드, TUN 스위치, 외부 제어 수신 주소, 규칙 상단의 개인 예외처럼 반드시 제어해야 하는 필드만 수정하세요. 정책 그룹을 로컬에서 완전히 관리한다면 원격 규칙이 더 이상 존재하지 않는 그룹 이름을 참조하지 않는지도 함께 확인해야 합니다. 이름은 참조 관계의 일부이며 공백, 대소문자 또는 전각 기호가 달라지는 것만으로도 대상을 찾지 못할 수 있습니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

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

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

store-selected는 정책 그룹 선택을 저장해 구독을 새로 고치거나 코어를 다시 시작한 뒤에도 매번 다시 선택하지 않도록 합니다. store-fake-ip는 Fake-IP 매핑을 저장해 재시작 후 기존 연결의 대응 관계가 사라지는 영향을 줄일 수 있습니다. 활성화 여부는 클라이언트의 저장 권한과 실제 증상을 함께 고려하세요. 매핑이 이상해지면 이전 상태를 계속 누적하기보다 캐시를 삭제하고 새로 구성할 수 있습니다.

proxy-providers로 여러 구독 가져오기

여러 구독을 단순히 복사해 하나의 거대한 노드 배열로 만들지 마세요. proxy-providers를 사용하면 각 출처를 독립적으로 업데이트하고 캐시할 수 있으며 정책 그룹에서 필요할 때 참조할 수 있습니다. 주 구독과 보조 구독은 서로 다른 파일 경로를 사용해 업데이트 실패 시에도 서로 덮어쓰지 않게 하세요. 상태 확인은 제공자 계층에 배치하면 해당 제공자를 참조하는 여러 정책 그룹이 결과를 공유할 수 있습니다.

proxy-providers:
  provider-main:
    type: http
    url: https://example.invalid/subscription/main
    path: ./providers/main.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

  provider-backup:
    type: http
    url: https://example.invalid/subscription/backup
    path: ./providers/backup.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 900

예시 주소는 예약된 테스트 도메인이며 실제 구독 주소는 민감한 설정이므로 공개 파일, 스크린샷 또는 공유 로그에 넣지 마세요. 여러 출처의 노드 이름이 겹치면 코어 또는 클라이언트가 병합 과정에서 덮어쓰거나 이름을 바꾸거나 로드를 거부할 수 있습니다. 제공자에서 접두사, 접미사 또는 필터를 사용해 출처를 구분하세요. 예를 들어 보조 출처에 “보조” 접두사를 일괄 추가할 수 있습니다. 정책 그룹에서 필터링할 때도 접두사와 지역 키워드를 조합해 이름이 같은 노드의 출처를 구분할 수 있게 하세요.

업데이트 실패와 롤백 전략

구독 자동 업데이트 간격은 너무 짧게 설정하지 않는 것이 좋습니다. 노드 변경은 보통 분 단위 새로 고침이 필요하지 않으며, 잦은 요청은 실패 가능성을 높이고 일시적인 네트워크 오류 때 불완전한 내용으로 현재 설정을 바꿀 수 있습니다. 클라이언트에 “설정 자동 업데이트 · 간격 1440분”과 같은 옵션이 있다면 하루 단위 업데이트로 일반적인 변화를 충분히 반영할 수 있습니다. 업데이트 후에는 문법 검사를 먼저 완료한 다음 실행 중인 설정으로 전환하세요. 이전 설정 보관을 지원하는 클라이언트라면 최소한 직전의 정상 실행 버전을 저장해야 합니다.

다중 구독을 병합한 뒤 시작되지 않는다면 계층별로 나누어 확인하세요. 먼저 로컬 기본 설정만 남기고, 그다음 주 제공자, 보조 제공자, 마지막으로 정책 그룹과 규칙을 차례로 추가합니다. 파싱 오류는 보통 필드나 줄 번호로 범위를 좁힐 수 있고, 논리 오류는 “노드가 로드되었는가, 그룹에 멤버가 있는가, 규칙 대상이 존재하는가”의 세 단계로 확인해야 합니다. 실패한 상태에서 변환 스크립트를 계속 추가하지 마세요. 원래 오류가 더 많은 처리 계층에 가려집니다.

데스크톱과 Android 사이에서 이전해야 한다면 기기 경로가 포함되지 않은 공통 필드를 우선 옮기세요. Windows와 Android는 파일 경로, 수신 권한, TUN 구현 및 앱별 분기 처리 방식이 다르므로 동일한 전체 설정이 모든 플랫폼에서 바로 재사용된다고 가정해서는 안 됩니다. 지원이 중단된 클라이언트에서 옮기는 방법은 mihomo 코어 클라이언트로 이전하는 설정 방법을 참고하세요.

07 / 제어 인터페이스

외부 제어 패널과 인터페이스 보안 범위

mihomo의 외부 제어 인터페이스를 사용하면 호환 패널에서 정책 그룹을 읽고 멤버를 전환하며 연결과 로그를 확인할 수 있습니다. 이는 관리 기능을 제공할 뿐 프록시 포트가 아닙니다. 제어 인터페이스는 mixed-port, HTTP 프록시 포트 및 SOCKS 포트와 별도로 계획해야 합니다. 기기 내부에서만 사용할 때는 루프백 주소에서 수신하도록 설정해 로컬 네트워크의 다른 기기가 제어 화면에 접근할 가능성을 줄이세요.

수신 주소와 접근 비밀번호

external-controller: 127.0.0.1:9090
secret: "replace-with-a-local-password"
external-ui: ./ui
external-ui-name: dashboard

external-controller는 수신 주소와 포트를 지정합니다. 127.0.0.1은 같은 기기의 연결만 허용하므로 클라이언트 내장 패널이나 해당 기기의 브라우저에 적합합니다. 로컬 네트워크에서 관리해야 한다면 네트워크에서 접근 가능한 주소로 바꿀 수 있지만, 반드시 접근 비밀번호를 설정하고 시스템 방화벽으로 출발지를 제한하세요. 제어 인터페이스는 실행 상태를 변경하고 연결 정보를 볼 수 있으므로 인터넷에 직접 노출해서는 안 됩니다.

external-ui는 정적 패널 파일 디렉터리를 가리킵니다. 패널은 제어 인터페이스의 프런트엔드일 뿐이며, 로드되었다고 해서 코어와 연결된 것은 아닙니다. 페이지가 비어 있거나 정책 그룹이 표시되지 않으면 정적 파일 존재 여부, 브라우저의 제어 주소 접근 여부, 비밀번호 일치 여부, 패널에 입력한 프로토콜과 포트가 올바른지를 각각 확인하세요. 클라이언트에 내장 패널 진입점이 있다면 수동으로 디렉터리를 설정하기보다 클라이언트가 관리하는 경로를 우선 사용하세요.

다른 기기에서 로컬 네트워크 제어 화면에 접근하기

기기 간 접근에는 네 가지 조건이 모두 필요합니다. 코어가 루프백이 아닌 주소에서 수신하고, 운영체제 방화벽이 해당 포트를 허용하며, 접속 기기가 호스트의 로컬 네트워크 주소에 도달하고, 제어 비밀번호가 맞아야 합니다. 하나라도 충족하지 않으면 패널 연결 실패로 나타납니다. 먼저 코어가 실행 중인 기기에서 로컬 주소에 접근한 뒤 같은 네트워크의 다른 기기에서 테스트하세요. 처음부터 프록시 포트, TUN 라우팅 및 제어 인터페이스를 함께 바꾸지 마세요. 각각 다른 문제를 해결하는 설정입니다.

allow-lan 활성화는 주로 프록시 포트가 로컬 네트워크 연결을 받을지에 영향을 주며, 이를 외부 제어 인터페이스의 유일한 스위치로 보면 안 됩니다. 제어 인터페이스는 자체 수신 주소로 결정됩니다. 다른 기기가 프록시만 사용하고 코어를 관리하지 못하게 하려면 프록시 포트만 열고 제어 인터페이스는 계속 루프백 주소로 제한하세요. 반대로 제어 인터페이스만 연다고 해서 로컬 네트워크 기기에 프록시 기능이 자동으로 제공되지는 않습니다.

인터페이스로 상태 확인하기

디버깅할 때는 로컬 기기에서 제어 인터페이스에 요청을 보내 코어가 응답하는지 확인할 수 있습니다. 아래 예시는 버전 정보와 프록시 그룹 목록만 요청하며 실제 비밀번호는 포함하지 않습니다. 비밀번호를 설정했다면 요청 헤더에 해당 인증 정보를 제공해야 합니다. 명령은 코어가 실행 중인 같은 기기에서 실행하세요.

curl http://127.0.0.1:9090/version
curl http://127.0.0.1:9090/proxies

첫 번째 요청은 제어 서비스가 시작되었는지 확인하고, 두 번째 요청은 정책 그룹이 정상적으로 로드되었는지 확인합니다. 포트 연결이 거부되면 수신 주소, 포트 사용 여부 및 코어 시작 로그를 먼저 확인하세요. 인증되지 않았다는 응답이 오면 인터페이스는 존재하지만 접근 비밀번호가 일치하지 않는다는 뜻입니다. 데이터가 반환되는데 패널에 표시되지 않으면 문제는 정책 그룹 자체가 아니라 패널 설정, 브라우저 제한 또는 정적 리소스에 있습니다.

로그 수준과 연결 관찰

log-level: info는 일상적인 문제 해결에 적합하며 규칙 매칭과 연결 수립 정보를 확인할 수 있습니다. 더 자세한 디버그 수준은 기록이 매우 많아지므로 문제를 재현할 때만 잠시 활성화하세요. 로그에는 접근한 도메인, 로컬 네트워크 주소 및 정책 이름이 포함될 수 있으므로 공유하기 전에 개인 구독 주소, 인증 필드 및 관련 없는 연결을 삭제해야 합니다. 진단이 끝나면 일반 수준으로 되돌려 장시간 기록으로 인한 저장 공간 부담을 줄이세요.

외부 패널은 상태를 관찰하는 용도이며 설정 파일 자체의 버전 관리를 대신해서는 안 됩니다. 정책 그룹 전환은 실행 중 상태에 해당하고, 규칙·DNS·TUN 매개변수는 계속 설정 원본에서 수정해야 합니다. 그렇지 않으면 재시작, 구독 새로 고침 또는 클라이언트 변경 후 패널에서 수행한 임시 작업으로 전체 의도를 복원할 수 없습니다.

08 / 문제 해결

설정 진단 순서와 장기 유지 관리

복잡한 설정에 문제가 생겼을 때 가장 효과적인 방법은 모든 스위치를 연달아 바꾸는 것이 아니라 변수를 줄이는 것입니다. 경로를 설정 파싱, 프록시 제공자, DNS, 규칙 매칭, 정책 선택, 트래픽 가로채기 및 대상 연결의 일곱 계층으로 나누고 한 번에 한 계층이 정상인지 확인하세요. 로그의 첫 번째 오류는 뒤따르는 연쇄 오류보다 가치가 큰 경우가 많습니다. 설정을 읽을 수 없거나 제공자를 불러오지 못하는 상위 문제를 먼저 처리한 뒤 특정 웹사이트 연결을 확인하세요.

최소 실행 설정부터 시작하기

진단 기준으로 사용할 최소 설정을 만들고 사용 가능한 프록시 하나, 수동 정책 그룹 하나, 기본 DNS 및 최종 규칙만 남기세요. 시작이 확인되면 정책 그룹, 규칙 제공자, TUN, Fake-IP, 스니핑, 오버라이드 순서로 각 계층을 복원합니다. 각 계층을 복원할 때마다 직접 연결되는 웹사이트 하나, 프록시를 사용해야 하는 웹사이트 하나, 로컬 네트워크 주소 하나, 문제가 있는 앱 하나를 같은 방식으로 테스트하세요. 테스트 대상을 고정하면 웹사이트 자체의 변동을 설정 변경으로 잘못 판단하는 일을 줄일 수 있습니다.

mixed-port: 7890
mode: rule
log-level: info

proxies:
  - name: local-test
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: 테스트 정책
    type: select
    proxies:
      - local-test
      - DIRECT

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,테스트 정책

예시의 로컬 SOCKS 서비스는 기기에서 해당 포트가 실제로 실행 중일 때만 사용할 수 있으며, 최소 구조를 보여 주기 위한 것이지 공용 노드가 아닙니다. 실제 진단에서는 정상 작동을 확인한 구독 노드로 바꾸세요. 최소 설정의 목적은 클라이언트, 코어 및 기본 네트워크 경로가 작동하는지 확인하는 것입니다. 그래도 시작되지 않는다면 먼저 YAML 들여쓰기, 지원되는 필드 범위 및 포트 충돌을 점검하세요.

현상에 따라 점검 계층 선택하기

“연결됨으로 표시되지만 인터넷이 되지 않음”이라면 먼저 기본 정책이 사용 가능한 멤버를 선택했는지 확인하고, 다음으로 DNS 응답과 TUN 가로채기를 확인하세요. 전체 목록은 Android 단계별 문제 해결 목록을 참고하세요. “일부 웹사이트만 실패”한다면 규칙, IPv6, DNS 결과, UDP 또는 대상 서비스의 출구 제한과 관련되었을 가능성이 큽니다. “모든 노드가 느림”은 로컬 Wi-Fi, 셀룰러 네트워크 및 시스템 절전 제한을 먼저 배제하고, “특정 노드 하나만 느림”은 노드와 회선을 우선 확인하세요. 속도 문제는 노드·회선·로컬 설정의 3단계 진단법에서 계속 확인할 수 있습니다.

로그에 DIRECT가 표시되는데 프록시를 사용해야 한다면 규칙 순서와 도메인 복원 여부를 확인하세요. 올바른 정책 그룹이 표시되지만 연결에 실패하면 해당 그룹의 현재 멤버를 확인해야 합니다. 연결 로그가 전혀 없다면 앱이 시스템 프록시나 TUN에 들어왔는지 확인하세요. DNS 로그는 있지만 이후 연결이 없다면 앱 캐시, 예상과 다른 조회 결과 또는 시스템 계층의 차단일 수 있습니다. 현상마다 확인해야 할 계층이 다르므로 “노드 바꾸기”만으로 처리하지 마세요.

YAML 구조와 흔한 파싱 오류

YAML은 공백으로 계층을 표현하므로 탭을 섞어 사용할 수 없습니다. 목록 항목의 하이픈은 같은 계층의 항목과 맞춰야 하며 콜론, 해시 또는 특수 문자가 포함된 이름은 따옴표로 감싸는 것이 좋습니다. 중복 키는 파서에 의해 덮어써지거나 즉시 오류가 날 수 있습니다. 여러 설정을 병합할 때는 특히 dns가 두 개이거나 rules가 두 개이거나 이름이 같은 제공자가 여러 개 생기지 않았는지 확인하세요. 설정이 파싱된다고 해서 참조 관계가 올바른 것은 아니므로 정책 그룹, 규칙 제공자 및 제공자 이름도 확인해야 합니다.

오류 줄 번호가 표시되면 그 앞의 몇 줄도 함께 확인하세요. 실제 들여쓰기나 따옴표 누락 위치는 오류가 표시된 줄보다 앞에 있는 경우가 많습니다. 최근 추가한 전체 블록을 먼저 삭제해 복구되는지 확인한 뒤 블록을 절반씩 다시 추가하는 이분 탐색 방식으로 위치를 좁힐 수 있습니다. 오류가 표시된 줄만 삭제하지 마세요. 그 줄은 파서가 처음으로 더 이상 해석하지 못한 위치일 뿐일 수 있습니다.

변경 기록, 백업 및 업데이트 주기

세 가지 상태를 보관하는 것이 좋습니다. 마지막으로 정상 작동을 확인한 설정, 현재 테스트 중인 설정, 구독 또는 규칙을 업데이트하기 전의 스냅샷입니다. 파일 이름에 날짜와 용도를 사용할 수 있지만 공개된 위치에 구독 주소를 저장하지 마세요. 변경할 때마다 “왜 바꿨는지, 어떤 필드를 바꿨는지, 어떻게 검증했는지”를 기록하면 단순히 사본을 많이 저장하는 것보다 롤백하기 쉽습니다. 클라이언트 업그레이드, 코어 변경, 구독 업데이트 및 규칙 제공자 업데이트는 분리해서 진행해 한 번의 변화가 네 계층을 동시에 덮어쓰지 않게 하세요.

현재 플랫폼에 적합하고 계속 유지 관리되는 패키지를 우선 선택하세요. Android에서는 설치 패키지 페이지의 Android 섹션에서 Clash Plus, Clash Meta for Android, FlClash 및 Surfboard를 확인할 수 있습니다. 데스크톱은 해당 플랫폼에 맞는 클라이언트를 선택하세요. Clash for Windows와 ClashX Meta는 유지 관리가 중단되었으므로 이전할 때는 먼저 공통 설정을 내보낸 뒤 플랫폼 전용 필드를 처리하고, 기존 클라이언트에 패치를 계속 추가하지 마세요.

장기간 안정적인 설정은 보통 복잡하지 않습니다. 명확한 정책 계층, 제한적이고 신뢰할 수 있는 규칙 출처, 설명 가능한 DNS 경로, 통제된 TUN 범위 및 롤백 가능한 오버라이드로 구성됩니다. 자동화는 이러한 관계가 명확해진 뒤에 도입해야 합니다. 목표는 모든 옵션을 켜는 것이 아니라 각 연결의 진입점, 이름 확인, 규칙 매칭 및 출구 선택을 로그로 설명할 수 있게 하는 것입니다.