Clash 고급 사용법: 정책, 규칙 및 트래픽 가로채기

설정 읽기 방법과 변경 순서

먼저 설정의 다섯 가지 처리 단계를 구분하세요

연결이 mihomo에 들어왔다고 해서 곧바로 특정 노드로 연결되는 것은 아닙니다. 코어는 먼저 대상 주소를 확인합니다. 앱이 IP만 전달하면 도메인 스니핑으로 도메인을 복원할 수 있고, DNS 모듈은 조회 방식과 실제 주소 또는 Fake-IP 매핑을 관리합니다. 규칙 시스템은 위에서 아래로 내려가며 처음 일치하는 항목을 찾고, 결과는 정책 그룹으로 전달되어 실제 프록시, 직접 연결 또는 거부를 선택합니다. TUN은 시스템 네트워크에 더 가까운 위치에서 작동하며 시스템 프록시로 들어오지 않는 트래픽을 코어로 보냅니다. 이 흐름을 이해하면 “가로채졌는가, 도메인이 있는가, 조회가 되었는가, 어떤 규칙이 일치했는가, 최종적으로 무엇을 선택했는가” 순서로 문제를 해결할 수 있습니다.

설정 파일은 일반적으로 포트, 실행 모드, DNS, TUN, 프록시 제공자, 정책 그룹, 규칙 제공자 및 규칙으로 구성됩니다. 필드의 위치가 실행 순서를 의미하는 것은 아니지만 YAML의 계층과 들여쓰기는 필드가 올바른 모듈에 속하는지를 결정합니다. 두 칸 들여쓰기가 일반적이며 목록 항목에는 하이픈을 사용합니다. 불리언 값은 true 또는 false로 작성하고 따옴표를 붙이지 마세요. 포트는 정수로 작성하며 콜론, 샵 또는 특수 문자가 포함된 일반 문자열은 따옴표로 감싸는 것이 좋습니다. 저장하기 전에 클라이언트의 설정 검사 기능으로 형식 오류를 먼저 배제한 뒤 네트워크 동작을 확인하세요.

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

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

dns:
  enable: true
  enhanced-mode: fake-ip

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,노드 선택

위의 골격은 계층 관계만 보여 주며 완전한 구독 설정이 아닙니다. mixed-port는 HTTP와 SOCKS 연결을 모두 받아 로컬 앱에서 하나의 포트를 공통으로 지정하기 좋습니다. mode: rule은 규칙에 따라 처리한다는 뜻이고, store-selected는 정책 그룹 선택을 기억하는 데 사용됩니다. MATCH는 최종 폴백 규칙입니다. 클라이언트가 구독에서 프록시와 정책 그룹을 이미 생성했다면 예제를 적용하려고 기존 항목을 삭제하지 말고 오버라이드 영역에 필요한 필드만 추가하세요.

되돌릴 수 있는 변경 절차 만들기

안정적인 설정 변경에는 구독 원본 설정, 현재 사용 가능한 설정, 테스트 중인 변경 설정의 세 가지 상태를 보존하는 것이 좋습니다. 구독 원본은 상위 제공 내용을 확인하는 데 사용하고, 현재 사용 가능한 설정은 되돌림 지점으로 삼으며, 테스트 설정에는 “개발 도메인을 항상 직접 연결” 또는 “TUN으로 명령줄 도구를 가로채기”처럼 하나의 명확한 목표만 부여합니다. 클라이언트가 오버라이드를 지원한다면 로컬 변경 사항은 구독 다운로드 결과를 직접 편집하지 말고 오버라이드 파일에 작성하세요. 구독을 새로 고치면 주 설정이 교체될 수 있어 직접 수정한 내용이 사라질 수 있지만, 독립된 오버라이드는 검토와 마이그레이션이 더 쉽습니다.

변경할 때마다 먼저 비용이 낮은 항목부터 확인하세요. 설정이 로드되는지, 로그에 구문 오류가 없는지, 시스템 프록시 또는 TUN이 정상적으로 시작되는지, 직접 연결 대상과 프록시 대상이 각각 작동하는지를 확인합니다. 그다음 규칙 일치와 DNS를 검증하세요. 단순히 “웹페이지가 열렸다”는 사실만 성공 기준으로 삼지 마세요. 브라우저 캐시, 기존 연결, 시스템 DNS 캐시가 문제를 가릴 수 있습니다. 규칙을 테스트할 때는 새 도메인을 사용하거나 대상 앱을 재시작하고, DNS를 테스트할 때는 앱 연결을 정리한 뒤 코어 로그에서 조회 및 일치 기록을 확인하세요.

로그 수준은 일상적인 사용에서 info를 권장합니다. 규칙과 DNS를 추적해야 할 때만 잠시 debug로 전환하고 완료 후 다시 되돌리세요. 로그가 너무 많으면 원인 파악이 어려워질 수 있습니다. 인터페이스 안내와 코어 로그가 다를 때는 코어가 설정을 로드했는지와 실제 연결이 나타나는지를 기준으로 판단하세요. 그래도 원인을 확인하기 어렵다면 FAQ에서 기본 문제 분류를 확인하세요. 시스템 프록시와 TUN 선택 문제라면 TUN 모드와 시스템 프록시의 작동 방식 비교를 이어서 읽어 보세요.

정책 그룹 유형과 실제 조합

선택, 자동 테스트 및 장애 조치

정책 그룹은 규칙 결과와 실제 프록시 사이의 중간 계층입니다. 규칙은 구독에 따라 바뀌는 특정 노드를 직접 가리키기보다 “노드 선택”, “스트리밍”, “개발 서비스”처럼 업무 의미가 있는 그룹 이름을 가리키는 것이 좋습니다. 그러면 구독을 업데이트하거나 노드를 삭제하거나 경로를 임시로 변경할 때 많은 규칙을 수정하지 않고 정책 그룹만 조정할 수 있습니다. 가장 많이 사용하는 select는 사용자가 구성원을 직접 선택하므로 동작이 안정적이며, 전체 진입점이나 고정된 출구가 필요한 업무에 적합합니다. 그룹에는 실제 프록시와 다른 정책 그룹을 함께 넣을 수 있어 “업무 그룹 → 지역 그룹 → 자동 속도 테스트 그룹”과 같은 계층도 만들 수 있습니다.

url-test는 설정한 주소를 기준으로 그룹 내 프록시를 주기적으로 테스트하고 결과가 더 좋은 구성원을 선택합니다. 일상적인 자동 선택에 적합하지만 테스트 결과는 테스트 주소까지의 연결 상태만 나타내며 대상 웹사이트가 반드시 같은 경로를 사용하는 것은 아닙니다. fallback은 사용 가능성 순서를 중시하며 일반적으로 앞에서부터 사용 가능한 첫 구성원을 선택하므로 주 회선과 예비 회선을 준비할 때 적합합니다. load-balance는 여러 구성원에게 연결을 분산하며 실제로 연결 분산이 필요한 경우에 사용합니다. 짧은 시간 안에 같은 서비스가 서로 다른 출구를 사용할 수 있으므로 로그인, 결제 또는 세션 일관성이 필요한 서비스에는 함부로 사용하지 마세요.

proxy-groups:
  - name: 노드 선택
    type: select
    proxies:
      - 자동 선택
      - 장애 조치
      - DIRECT

  - name: 자동 선택
    type: url-test
    use:
      - provider-main
    url: https://www.example.com/
    interval: 600
    tolerance: 80
    lazy: true

  - name: 장애 조치
    type: fallback
    use:
      - provider-main
    url: https://www.example.com/
    interval: 600
    lazy: true

use는 프록시 제공자를 참조하므로 구독에 따라 노드가 동적으로 바뀌는 경우에 적합합니다. proxies는 고정된 구성원이나 다른 그룹 이름을 직접 나열합니다. interval은 테스트 간격이며 너무 짧게 설정하면 네트워크 요청과 모바일 기기의 배터리 소모가 늘고, 너무 길면 사용할 수 없는 경로를 발견하는 시점이 늦어질 수 있습니다. tolerance는 수치의 작은 변동으로 인한 잦은 전환을 줄입니다. 새 결과가 충분히 차이 날 때만 선택이 변경됩니다. lazy를 활성화하면 그룹을 오랫동안 사용하지 않을 때 불필요한 능동 테스트를 줄일 수 있습니다.

규칙 수가 아니라 업무 기준으로 그룹 구성하기

정책 그룹 이름은 규칙의 출처가 아니라 의사결정을 설명해야 합니다. “동영상 규칙 제공자”라는 그룹은 규칙과 정책을 강하게 결합하지만, “스트리밍”으로 바꾸면 도메인 규칙이나 규칙 제공자 중 어디에서 일치했든 출구의 의미가 분명합니다. 기본 구조에는 일반적으로 전체 진입점, 자동 선택, 장애 조치 및 직접 연결만 있으면 되며, 실제 차이가 있는 업무에만 그룹을 추가하세요. 그룹이 많을수록 구독을 새로 고친 뒤 확인할 선택지가 늘고 순환 참조가 생기기 쉽습니다. mihomo는 순환 정책에서 최종 프록시를 결정할 수 없습니다. 예를 들어 A가 B를 참조하고 B가 다시 A만 참조하는 구조는 설계 단계에서 피해야 합니다.

지역 그룹은 프록시 제공자의 필터를 사용해 만들 수 있지만, 필터는 노드 이름에 의존합니다. 이름은 구독 제공처에서 오므로 지역명, 영문 약어 또는 기호가 섞일 수 있습니다. 표현식을 너무 좁게 작성하면 노드를 놓치고, 너무 넓게 작성하면 원치 않는 노드가 포함될 수 있습니다. 설정을 완료한 뒤에는 구문 검사 통과 여부만 보지 말고 클라이언트에서 그룹을 열어 실제 구성원 목록을 확인하세요. 고정된 출구가 필요한 서비스는 select를 사용해 수동으로 고정하고, 일반적인 웹 탐색은 전체 진입점이 자동 선택을 기본으로 가리키게 할 수 있습니다.

proxy-groups:
  - name: 개발 서비스
    type: select
    proxies:
      - 노드 선택
      - 장애 조치
      - DIRECT

  - name: 로컬 직접 연결
    type: select
    proxies:
      - DIRECT
      - 노드 선택

rules:
  - DOMAIN-SUFFIX,internal.example,DIRECT
  - RULE-SET,development,개발 서비스
  - GEOIP,LAN,DIRECT,no-resolve
  - MATCH,노드 선택

DIRECT와 REJECT도 규칙 대상이 될 수 있는 내장 정책입니다. 직접 연결은 코어를 우회한다는 뜻이 아닙니다. 규칙 모드에서는 연결이 먼저 Clash에 들어온 뒤 코어가 직접 연결을 수립할 수 있습니다. 로컬 네트워크 장치에 접근할 수 없다면 규칙이 직접 연결인지, TUN이 충돌하는 라우팅을 만들었는지, 운영체제 방화벽이 어떤 상태인지 함께 확인하세요. 거부 정책은 명확히 필요 없는 도메인에 적합하지만 규칙 제공자의 범위가 너무 넓으면 페이지 리소스가 누락될 수 있습니다. 변경 후에는 메인 페이지, 로그인, 이미지 및 API 요청을 테스트해야 하며 첫 화면이 열리는지만 확인해서는 안 됩니다.

정책 그룹을 점검할 때는 먼저 그룹에 구성원이 있는지 확인하고, 현재 구성원이 연결을 수립할 수 있는지 확인한 다음, 규칙이 실제로 해당 그룹을 가리키는지 확인하세요. 구독 업데이트 후 그룹이 비어 있다면 프록시 제공자 로드 실패 또는 새 노드 이름과 필터 조건이 일치하지 않는 것이 흔한 원인입니다. 그룹은 작동하지만 재시작할 때마다 기본값으로 돌아간다면 profile.store-selected가 활성화되어 있는지, 클라이언트가 영구 저장 디렉터리를 임시 설정으로 덮어쓰는지 확인하세요. 클라이언트는 다운로드 페이지에서 플랫폼별로 비교할 수 있습니다. 그래픽 인터페이스 사용자는 먼저 Clash Plus를 사용하고, 시스템 요구 사항에 따라 Clash Verge Rev 또는 FlClash를 선택하세요.

규칙 제공자 구독화 관리

규칙 순서가 최종 결과를 결정합니다

Clash 규칙은 위에서 아래로 내려가며 처음 일치하는 즉시 처리를 중단합니다. 규칙 수보다 우선순위가 더 중요합니다. 일반적으로 단일 도메인, 특정 접미사 및 로컬 네트워크 주소처럼 범위가 명확한 사용자 규칙을 앞에 배치하고, 그다음 업무별 규칙 제공자를 배치하며, 뒤쪽에서 지역 IP, 일반 직접 연결 및 최종 폴백을 처리합니다. MATCH를 중간에 배치하면 뒤의 규칙은 절대 실행되지 않습니다. 범위가 넓은 도메인 접미사를 정확한 규칙보다 앞에 두면 정확한 규칙이 덮어쓸 기회를 잃습니다.

DOMAIN은 완전한 도메인과 일치하므로 단일 호스트에 적합합니다. DOMAIN-SUFFIX는 도메인과 하위 도메인에 일치하므로 하나의 사이트 체계에 적합합니다. DOMAIN-KEYWORD는 범위가 더 넓어 오탐이 발생하기 쉬우므로 도메인 구조가 실제로 일정하지 않을 때만 사용하세요. IP-CIDR과 IP-CIDR6은 주소 대역을 처리합니다. IP 규칙은 조회를 유발할 수 있으므로 앞에서 도메인으로 이미 판단했거나 규칙 대상이 현재 IP에만 관련된 경우에는 상황에 따라 no-resolve를 추가해 불필요한 조회를 줄일 수 있습니다.

rule-providers의 동작 유형

규칙 제공자는 외부 규칙 파일을 주 설정과 분리해 관리합니다. behavior: domain은 도메인 항목만 포함한 모음에 적합하고, behavior: ipcidr은 주소 대역 모음에 사용하며, behavior: classical은 규칙 유형과 매개변수를 포함한 완전한 항목을 지원해 표현력이 가장 높습니다. 동작 유형은 파일 내용과 일치해야 합니다. DOMAIN-SUFFIX,example.com을 도메인 데이터만 허용하는 파일에 넣거나 순수 주소 대역을 classical 방식으로 사용하면 로드 실패 또는 규칙 불일치가 발생할 수 있습니다.

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

  local-network:
    type: file
    behavior: ipcidr
    format: yaml
    path: ./ruleset/local-network.yaml

rules:
  - DOMAIN,build.internal.example,DIRECT
  - RULE-SET,development,개발 서비스
  - RULE-SET,local-network,DIRECT,no-resolve
  - MATCH,노드 선택

type: http은 URL에서 업데이트한다는 뜻이고, type: file은 로컬 파일만 읽는다는 뜻입니다. path는 캐시 또는 로컬 파일 위치이므로 각 제공자에 독립적인 파일 이름을 지정해 여러 규칙 소스가 서로 덮어쓰지 않도록 하세요. interval은 업데이트 주기를 초 단위로 사용합니다. 규칙 내용이 자주 바뀌지 않는다면 지나치게 짧은 주기는 필요하지 않습니다. 하루에 한 번 업데이트하는 편이 요청량을 관리하기 쉽습니다. 원격 주소는 안정적인 HTTPS 출처를 사용하고, 조직 내부 규칙은 관리되는 서비스에 두어 임시 링크에 의존하지 않도록 하세요.

payload:
  - DOMAIN,api.example.com
  - DOMAIN-SUFFIX,developer.example
  - PROCESS-NAME,git
  - IP-CIDR,192.0.2.0/24,no-resolve

이는 classical YAML 규칙 파일의 일반적인 구조입니다. 제공자 파일에는 일치 조건만 작성하고 최종 정책은 작성하지 않습니다. 정책은 주 설정의 RULE-SET,development,개발 서비스에서 지정합니다. 이렇게 하면 같은 규칙 제공자를 기기마다 다른 정책으로 연결할 수 있습니다. 예를 들어 데스크톱에서는 “개발 서비스”로 보내고 서버에서는 고정 출구를 사용할 수 있습니다. 정책을 바꿀 때는 규칙 데이터를 복사해 두 번째로 관리할 필요 없이 주 설정만 수정하면 됩니다.

구독형 규칙의 관리 범위

규칙 제공자를 무한히 나누어서는 안 됩니다. 각 제공자는 다운로드, 구문 분석, 캐시 및 장애 원인 파악 비용을 추가합니다. 독립된 제공자로 관리하기 적합한 내용은 담당 범위가 명확하고, 서로 다른 사람이 관리하거나 업데이트 주기가 다르거나 여러 설정에서 재사용하거나 별도로 켜고 끌 필요가 있는 경우입니다. 세네 개뿐이고 장기간 변하지 않는 로컬 규칙은 주 규칙의 상단에 직접 작성하는 편이 더 명확합니다. 이름은 work-services, private-network처럼 용도를 표현하고 의미가 불분명한 rules1은 사용하지 마세요.

업데이트에 실패하면 먼저 “원격 다운로드 실패”와 “파일 구문 분석 실패”를 구분하세요. 전자는 URL 접근 가능 여부, DNS 정상 여부, 프록시 제공자가 프록시를 통해 업데이트해야 하는지를 확인합니다. 후자는 동작 유형, 형식, 들여쓰기 및 데이터 구조를 확인하세요. 캐시가 남아 있으면 일부 클라이언트가 기존 파일을 계속 사용할 수 있으므로 페이지가 잠시 열리는 것만으로 업데이트 성공을 판단해서는 안 됩니다. 로그에서 제공자 이름과 업데이트 시간을 확인하고 수동 업데이트 후 새로운 오류가 나타나는지 확인하세요. GeoIP 또는 GeoSite 데이터베이스 관련 규칙에 문제가 있다면 GeoIP 및 GeoSite 데이터베이스 업데이트 방법을 참고하세요.

규칙 관리가 끝나면 고정된 테스트 세트를 마련하세요. 명확히 직접 연결되는 도메인 하나, 명확히 프록시를 사용하는 도메인 하나, 로컬 네트워크 주소 하나, IP만 있는 연결 하나, 최종 폴백 대상 하나를 포함합니다. 규칙 소스를 업데이트할 때마다 같은 테스트를 수행하면 순서 변경, 규칙 소스 오류 및 오탐을 빠르게 발견할 수 있습니다. 결과는 일치한 규칙과 정책 이름으로 판단하고 웹페이지의 겉보기 동작으로 대신하지 마세요. 이렇게 하면 규칙 제공자가 계속 커져도 설명 가능성을 유지할 수 있습니다.

DNS 설정 최적화 및 분기

먼저 mihomo DNS의 역할을 명확히 이해하세요

mihomo DNS를 활성화하면 코어가 규칙에 따라 도메인 조회를 처리하고 조회 결과를 이후 연결과 연결할 수 있습니다. 이는 단순히 “DNS 주소를 바꾸는” 기능이 아니라 도메인 조회와 프록시 결정을 하나의 흐름으로 묶는 기능입니다. 앱이 자체 암호화 DNS를 사용하거나 고정 주소에 직접 연결하거나 별도의 hosts 파일을 읽으면 조회가 코어를 우회할 수 있습니다. 이 경우 nameserver만 수정해도 앱의 동작이 바뀌지 않을 수 있으므로 TUN의 DNS 하이재킹, 브라우저 설정 및 도메인 스니핑을 함께 확인해야 합니다.

default-nameserver는 주로 다른 DNS 서버 자체의 도메인을 조회하는 데 사용하며, “암호화 DNS에 접속하려면 먼저 그 주소를 조회해야 하는데 현재 사용할 DNS가 없다”는 순환을 피하기 위해 직접 접근 가능한 IP 주소를 주로 사용합니다. nameserver는 일반 조회를 처리합니다. proxy-server-nameserver는 프록시 서버 도메인을 전용으로 조회해 일반 분기에 의존하는 문제를 줄일 수 있습니다. nameserver-policy는 도메인별로 DNS 서버를 지정하며 내부 도메인, 로컬 네트워크 도메인 또는 실제로 조회 결과가 다른 업무에 적합합니다.

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.example.com/dns-query
  proxy-server-nameserver:
    - 223.5.5.5
  nameserver-policy:
    "+.internal.example":
      - 192.168.1.1
  fake-ip-filter:
    - "*.lan"
    - "+.internal.example"
    - "time.*"

예제의 주소는 현재 네트워크에 맞게 바꿔야 합니다. listen은 실제로 로컬의 다른 프로그램이 조회해야 할 때만 설정하세요. 모든 인터페이스에 바인딩한다면 시스템 방화벽과 로컬 네트워크 접근 범위도 확인해야 합니다. 데스크톱 클라이언트는 일반적으로 수신 주소를 자동으로 관리하므로 설정을 복사하려고 억지로 개방할 필요가 없습니다. ipv6: false는 DNS 모듈이 IPv6 결과를 반환하지 않도록 하며 현재 네트워크에 안정적인 IPv6 경로가 없을 때 적합합니다. 네트워크와 프록시가 모두 IPv6를 완전히 지원한다면 활성화한 뒤 직접 연결과 프록시 대상을 각각 검증하세요.

Fake-IP와 redir-host 선택 기준

fake-ip 모드는 먼저 앱에 매핑 주소를 반환하고, 앱이 해당 주소로 연결하면 코어가 원래 도메인을 복원해 도메인 규칙을 적용합니다. 이를 통해 규칙 일치가 직접적으로 이루어지고, “먼저 IP로 조회한 뒤 주소만으로 판단해야 하는” 정보 손실도 줄일 수 있습니다. 매핑 주소는 로컬 코어 안에서만 의미가 있으므로 대상의 실제 주소로 간주해서는 안 됩니다. 패킷 캡처, 로그 또는 앱 진단 화면에서 198.18.0.0/16과 같은 주소가 보이면 비정상적인 DNS 결과로 판단하기 전에 Fake-IP 매핑인지 먼저 확인하세요.

일부 로컬 네트워크 서비스, 장치 검색, 네트워크 연결 확인, 시간 동기화 또는 실제 주소에 의존하는 앱은 Fake-IP와 맞지 않으므로 fake-ip-filter에 추가해야 합니다. 필터링된 도메인은 실제 조회 결과를 반환합니다. 처음부터 필터 범위를 지나치게 넓히면 안 됩니다. 예를 들어 많은 최상위 도메인을 한꺼번에 제외하면 Fake-IP의 도메인 연결 장점이 약해집니다. 호환성 문제가 발생하면 구체적인 도메인부터 시작해 로그로 확인한 뒤 접미사를 추가하세요. redir-host는 실제 IP를 반환해 전통적인 조회 방식에 더 가깝지만 도메인과 연결을 연결하는 방식은 다릅니다. Fake-IP 호환성 문제가 명확하고 필터로 해결되지 않을 때만 전체 전환을 고려하세요.

nameserver-policy와 조회 경로

내부 서비스는 라우터나 기업 DNS를 통해 조회해야 하는 경우가 많으며 공개 DNS에는 해당 레코드가 없습니다. nameserver-policy를 사용해 특정 접미사를 내부 서버로 보내고, 규칙 상단에서는 해당 도메인을 직접 연결하도록 설정할 수 있습니다. DNS 분기와 연결 분기는 일치해야 합니다. 내부 DNS가 사설 주소를 반환했는데 규칙이 외부 프록시로 보내면 일반적으로 접근할 수 없습니다. 반대로 공개 DNS가 공인 주소를 반환했는데 내부 서비스로 처리하려 해도 오류가 발생합니다. 설정할 때 “누가 조회하는가”와 “연결이 어떤 정책을 따르는가”를 한 쌍으로 검토하세요.

respect-rules로 DNS 연결이 규칙을 따르게 할 때는 프록시 노드 도메인을 조회하는 경로가 아직 만들어지지 않은 프록시에 의존하지 않도록 해야 합니다. 이를 위해 정상적으로 직접 연결할 수 있는 proxy-server-nameserver를 설정하고 DNS 규칙이 순환하지 않도록 하세요. 시작 후 모든 연결이 조회 단계에서 멈춘다면 잠시 직접 연결 가능한 기본 DNS를 사용해 프록시 서버 도메인이 조회되는지 확인한 뒤 암호화 DNS와 규칙 기반 분기를 단계적으로 복원하세요.

문제를 해결할 때는 먼저 로그로 조회가 mihomo에 도달하는지 확인하세요. 조회 기록이 전혀 없다면 시스템 DNS가 코어를 가리키는지, TUN의 DNS 하이재킹이 적용되었는지, 앱이 독립 DNS를 사용하는지 확인합니다. 조회는 있지만 실패한다면 상위 서버에 접근할 수 있는지, 도메인 형식의 DNS 주소를 default-nameserver로 조회할 수 있는지 확인하세요. 조회에 성공했는데도 연결이 실패하면 DNS 단계에 머물지 말고 규칙 정책과 실제 대상을 계속 확인하세요. 로컬 네트워크 장치 이름만 실패한다면 모든 도메인을 직접 연결로 바꾸기보다 검색 도메인, 라우터 DNS 및 Fake-IP 필터를 확인하세요.

DNS 최적화에는 하나의 정답이 없습니다. 안정적인 설정에는 일반적으로 세 가지 특징이 있습니다. 기본 조회 경로가 독립적으로 시작되고, 내부 도메인의 조회와 연결 정책이 일치하며, Fake-IP 예외에 구체적인 이유와 명확한 범위가 있어야 합니다. 설정 후 일반 웹페이지, 로컬 네트워크 도메인, 프록시 서버 도메인 및 IPv6만 지원하는 대상을 각각 테스트하세요. 각 대상의 예상 DNS 서버와 정책을 기록해 두면 네트워크를 바꾼 뒤 문제가 로컬 네트워크 변화인지 설정 저하인지 빠르게 판단할 수 있습니다.

TUN 및 Fake-IP 연동 설정

TUN이 필요한 경우

시스템 프록시는 운영체제의 프록시 설정을 능동적으로 읽는 앱에만 적용됩니다. 명령줄 프로그램, 일부 게임, 가상 머신, 직접 연결 소켓을 고정해 사용하는 소프트웨어는 시스템 프록시를 우회할 수 있습니다. TUN은 운영체제 네트워크 계층에 가상 인터페이스를 만들고 라우팅을 통해 더 많은 TCP 및 UDP 트래픽을 코어로 보내므로 통합 가로채기가 필요한 환경에 적합합니다. 그렇다고 시스템 프록시보다 본질적으로 빠른 것은 아니며 모든 문제의 기본 해결책으로 사용해서도 안 됩니다. 브라우저와 일반 데스크톱 앱이 시스템 프록시로 안정적으로 작동한다면 단순한 설정을 유지하는 편이 관리하기 쉽습니다.

TUN을 시작하려면 가상 네트워크 카드, 라우팅 테이블, DNS 및 시스템 권한이 필요합니다. 데스크톱 클라이언트는 일반적으로 서비스 설치 또는 네트워크 확장 권한을 요청하고, 모바일 기기는 시스템 VPN 인터페이스를 사용합니다. 토글이 활성화되었다고 해서 모든 트래픽이 코어로 들어온다는 뜻은 아닙니다. 로그에서 TUN 인터페이스, 라우팅 및 DNS 하이재킹이 정상적으로 생성되었는지 확인하고 대상 연결도 점검하세요. macOS에서 네트워크 확장 또는 키체인 권한 문제가 발생하면 macOS 네트워크 확장 및 키체인 처리 단계를 참고하세요.

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

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

auto-route는 코어가 필요한 라우팅을 자동으로 추가하도록 합니다. auto-detect-interface는 현재 네트워크에 맞는 출구 인터페이스를 선택하므로 유선, 무선 및 모바일 핫스팟을 오가는 기기에 적합합니다. strict-route는 트래픽 우회를 줄이지만 가상 머신, 컨테이너 및 다른 VPN의 라우팅과 충돌할 수 있습니다. 활성화한 뒤 로컬 네트워크나 회사 네트워크에 갑자기 접근할 수 없다면 프록시 노드를 바꾸기보다 먼저 라우팅 충돌을 확인하고 엄격한 라우팅을 끄거나 명시적인 제외를 추가할지 결정하세요.

stack, MTU 및 UDP 동작

TUN 스택은 코어 버전과 플랫폼 기능에 따라 달라지며 일반적인 선택지로 system, gvisor, mixed가 있습니다. 시스템 스택은 운영체제의 네트워크 구현을 활용하므로 호환성과 성능이 플랫폼의 영향을 받습니다. gVisor 사용자 공간 스택은 다른 처리 경로를 제공해 특정 시스템 스택 문제를 비교할 때 사용할 수 있습니다. mixed는 서로 다른 트래픽을 조합해 처리하며 많은 데스크톱 환경에서 시작점으로 적합합니다. 이름만 보고 우열을 판단하지 말고 같은 네트워크와 대상을 기준으로 TCP, UDP, 로컬 네트워크 및 절전 모드 복귀를 각각 테스트하세요.

MTU가 너무 크면 일부 경로에서 발생하는 단편화 또는 경로 탐색 문제가 “작은 페이지는 열리지만 큰 파일이나 특정 요청은 멈추는” 현상으로 나타날 수 있습니다. 너무 작게 설정하면 패킷 수와 추가 오버헤드가 늘어납니다. 기본값이 정상적으로 작동한다면 수정하지 마세요. MTU가 의심될 때는 먼저 문제가 TUN에서만 발생하는지 확인하고 시스템 프록시로 전환해 비교한 뒤 수치를 단계적으로 낮춰 테스트하세요. 스택과 DNS를 동시에 바꾸지는 마세요. UDP 문제가 있다면 선택한 프록시가 해당 전송을 지원하는지도 확인해야 합니다. TUN은 가로채기만 담당하며 UDP를 지원하지 않는 프록시에 기능을 추가해 주지는 않습니다.

Fake-IP가 TUN과 함께 사용되는 이유

TUN은 원래 시스템 프록시를 거치지 않던 연결을 대량으로 수신합니다. 연결 전에 발생하는 DNS 조회까지 mihomo로 하이재킹하면 Fake-IP가 도메인 정보를 보존해 이러한 연결에도 도메인 규칙을 적용할 수 있습니다. DNS 조회가 코어 밖에서 완료되면 TUN에는 실제 IP만 보이므로 규칙이 IP 일치나 최종 폴백으로 퇴화할 수 있습니다. 따라서 TUN, DNS 하이재킹 및 Fake-IP를 하나의 흐름으로 점검해야 합니다. 앱의 조회가 코어에 들어오는지, 매핑 주소가 저장되는지, 앱이 매핑 주소로 연결한 뒤 도메인이 복원되는지, 규칙이 예상 항목과 일치하는지를 확인하세요.

일부 앱은 하드코딩된 IP에 직접 연결하므로 처음부터 도메인이 없습니다. 이때 Fake-IP는 도메인을 만들어 낼 수 없으며 IP 규칙, 프로세스 규칙 또는 도메인 스니핑이 프로토콜 내용에서 대상을 식별할 수 있는지에 의존해야 합니다. 프로세스 규칙의 지원 수준은 플랫폼마다 다르고 모바일에서는 제한이 더 많은 경우가 많습니다. 설정에는 최종 폴백을 남겨 두고 로그에서 실제로 확인 가능한 정보에 맞춰 규칙 유형을 선택하세요. 모든 연결에서 도메인을 복원할 수 있다고 가정하지 마세요.

일반적인 충돌 원인은 다른 VPN, 가상 머신 브리지, 컨테이너 네트워크, 로컬 네트워크 프록시 도구 및 보안 소프트웨어입니다. 여러 프로그램이 동시에 기본 라우팅이나 DNS를 수정하면 나중에 시작한 프로그램이 먼저 시작한 프로그램의 설정을 덮어쓸 수 있습니다. 문제를 해결할 때 시작 순서를 기록하고 다른 네트워크 도구를 잠시 끈 뒤 Clash만 단독으로 활성화하세요. 절전 모드에서 복귀한 뒤 작동하지 않으면 먼저 TUN 인터페이스를 재시작하고, Wi-Fi를 전환한 뒤 문제가 생기면 출구 인터페이스 자동 감지를 확인하세요. 라우팅이 정상적으로 생성된 것을 확인한 뒤에야 규칙과 프록시를 분석해야 합니다.

모바일 기기에서 TUN을 계속 활성화하면 코어가 상주하게 되고, 속도 테스트 주기, 복잡한 규칙 및 잦은 DNS 조회가 배터리 소모에 영향을 줍니다. 자동 테스트 빈도를 낮추고 사용하지 않는 규칙 제공자를 정리하며 클라이언트가 시스템 백그라운드 정책에서 안정적으로 실행되도록 허용하세요. 반복적으로 중지되고 연결이 재생성되는 일을 줄일 수 있습니다. Android의 구체적인 확인 순서는 Android 백그라운드 정책 및 배터리 소모 점검 목록을 참고하세요.

도메인 스니핑과 규칙 보완

스니핑은 부족한 정보를 보완합니다

연결이 mihomo에 들어올 때 대상이 IP만 가지고 있는 경우가 있습니다. 도메인 스니핑은 연결 초반의 프로토콜 정보를 확인해 HTTP Host나 TLS ClientHello의 서버 이름 등에서 도메인을 복원한 뒤 도메인 규칙을 결정에 참여시킵니다. 모든 앱 내용을 읽는 기능도 아니며 DNS를 대체하지도 않습니다. 암호화 연결에서 식별할 수 있는 것은 핸드셰이크 단계에 공개된 대상 이름입니다. 프로토콜에 도메인이 없거나 핸드셰이크가 추가로 암호화되었거나 연결이 IP를 직접 사용하면 스니핑으로 결과를 얻을 수 없습니다.

스니핑은 “DNS는 코어 밖에서 처리되었지만 연결에는 여전히 도메인 정보가 포함된” 상황을 보완하는 데 적합합니다. 예를 들어 앱이 자체 DNS로 실제 주소를 조회한 뒤 TLS 연결을 시작하면 코어가 핸드셰이크에서 서버 이름을 복원할 수 있습니다. 복원된 뒤에도 규칙 순서에 따라 판단합니다. 스니핑한 도메인과 원래 대상 IP의 대응 관계가 특수한 경우 목적지를 함부로 덮어쓰면 연결 오류가 발생할 수 있습니다. 따라서 처음에는 일반적인 HTTP 및 TLS 포트부터 설정하고 모든 포트와 프로토콜을 한꺼번에 덮어쓰지 마세요.

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
  force-domain:
    - "+.example.com"
  skip-domain:
    - "Mijia Cloud"
    - "+.push.example"
  skip-src-address:
    - 192.168.0.0/16

parse-pure-ip는 IP만 있는 대상 연결에서 프로토콜 도메인을 조회해 보도록 허용합니다. force-dns-mapping은 DNS 매핑 정보를 함께 사용합니다. override-destination은 스니핑 결과로 원래 대상을 바꿀지 결정합니다. 처음 활성화할 때는 목적지 주소를 바꾸지 않고 로그에서 도메인이 복원되는지만 관찰하세요. 특정 서비스가 스니핑한 도메인 기반 라우팅을 필요로 한다는 것을 확인한 뒤 덮어쓰기를 활성화할지 평가합니다. 필드 지원 여부는 클라이언트 코어에 따라 다르므로 설정을 로드한 뒤 로그에서 해당 매개변수가 허용되었는지 확인하세요.

force-domain과 skip-domain의 범위

force-domain은 스니핑이 반드시 필요한 도메인에 적합하고, skip-domain은 호환성이 알려져 있지 않거나 변경해서는 안 되는 대상에 사용합니다. 두 목록 모두 로그와 재현 결과를 바탕으로 관리해야 하며 출처가 불분명한 대규모 제외 목록을 그대로 복사하지 마세요. 장치 검색, 로컬 네트워크 서비스, 푸시 장기 연결 및 특수한 인증서 검증을 사용하는 일부 앱은 제외가 필요할 수 있습니다. 하지만 연결 실패가 발생했다고 해서 먼저 DNS, 규칙 및 프록시 자체를 배제하지 않고 모든 원인을 스니핑 탓으로 돌려서는 안 됩니다.

소스 주소 제외는 로컬 네트워크 장치가 이 기기를 통해 전달되지만 도메인 식별은 원하지 않는 경우에 적합합니다. 대역을 설정할 때 실제 로컬 네트워크 범위를 확인하세요. 너무 넓으면 많은 연결에서 도메인 규칙을 사용할 수 없게 됩니다. 포트 범위도 절제해야 합니다. HTTP 스니핑은 일반적인 평문 포트에, TLS는 흔한 암호화 포트에, QUIC는 주로 UDP에 배치하세요. 모든 포트를 모든 프로토콜에 동시에 맡기면 불필요한 판단이 늘고 로그도 읽기 어려워집니다.

스니핑이 실제로 적용되었는지 확인하는 방법

검증할 때는 알고 있는 도메인을 하나 선택하세요. 먼저 로그에서 연결 초기 대상이 IP인지 확인하고, 그다음 스니핑 후 도메인이 나타나는지, 최종적으로 도메인 규칙과 IP 규칙 중 어느 쪽이 일치했는지 확인합니다. 연결 시작부터 도메인이 있었다면 정상적으로 일치했다는 사실만으로 스니핑이 작동했다고 증명할 수 없습니다. 같은 앱에서 스니핑을 끈 상태와 비교할 수 있지만 기존 연결을 정리해야 합니다. 브라우저는 일반적으로 연결 풀을 사용하므로 단순히 페이지를 새로 고치는 것만으로 새 연결이 생성되지 않을 수 있습니다.

로그에 스니핑 결과가 없다면 트래픽이 mihomo에 들어오는지, 포트가 설정 범위에 포함되는지, 프로토콜이 HTTP, TLS 또는 QUIC인지 확인하세요. 도메인은 복원되지만 예상대로 분기되지 않는다면 규칙 순서와 도메인 표기를 확인합니다. override-destination을 켠 뒤 연결이 실패하면 먼저 덮어쓰기를 끄고 도메인 복원만 유지하세요. 목적지 변경이 원인임을 확인한 뒤 대상을 제외 목록에 추가합니다. 제외 항목에는 구체적인 도메인이나 접미사를 작성하고 이유도 함께 기록해 나중에 다시 검토하기 쉽게 하세요.

장기적으로 관리할 때는 스니핑 예외를 해당 앱, 프로토콜 및 장애 현상과 함께 기록하세요. 도메인만 남기고 이유를 적지 않으면 몇 달 뒤 그 제외 항목이 여전히 필요한지 판단하기 어렵습니다. 클라이언트나 코어를 변경한 뒤에는 과거의 모든 제외 목록을 그대로 복사하지 말고 작은 범위부터 다시 검증하세요. “정보 부족 확인 → 제한된 프로토콜 활성화 → 도메인 복원 검증 → 덮어쓰기 여부 결정” 순서로 진행해야 스니핑을 통제 가능한 도구로 사용할 수 있습니다.

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

구독은 입력으로 보고 최종 설정으로 직접 사용하지 마세요

원격 구독은 일반적으로 프록시 노드, 기본 정책 및 일부 규칙을 제공하지만 로컬 네트워크, 내부 도메인, 앱 사용 방식 및 플랫폼 권한까지 고려하지는 않습니다. 구독 내용을 입력으로 받아 로컬 오버라이드로 최종 설정을 만드는 방식이 장기 관리에 더 적합합니다. 구독을 업데이트하면 노드 목록은 교체될 수 있지만 로컬 오버라이드는 DNS, TUN, 사용자 규칙 및 정책 그룹 변경을 유지합니다. 오버라이드를 지원하는 클라이언트는 YAML 오버라이드, 스크립트 처리 또는 병합 인터페이스를 제공할 수 있습니다. 진입점은 다르지만 목표는 새로 고칠 때 덮어써지는 주 설정을 직접 편집하지 않는 것입니다.

오버라이드에는 변경이 필요한 키만 포함하는 것이 좋습니다. 주 설정 전체를 복사하면 상위 제공자가 추가한 새 필드가 차단되고 이미 사라진 노드 이름이 남기 쉽습니다. 매핑 필드는 키 단위로 병합할 수 있지만 배열 필드는 특히 주의해야 합니다. 클라이언트에 따라 교체, 앞에 추가, 뒤에 추가 또는 스크립트 처리 방식이 다를 수 있습니다. rules는 가장 대표적인 순서 배열입니다. 단순히 교체하면 구독 규칙이 사라지고, 단순히 뒤에 추가하면 MATCH 뒤에 놓여 영원히 적용되지 않을 수 있습니다. 클라이언트의 “규칙 앞에 추가” 기능을 사용하거나 병합 스크립트에서 최종 폴백 앞에 명시적으로 삽입하세요.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-filter:
    - "+.internal.example"

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

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

이러한 로컬 오버라이드에는 구독 프록시가 포함되지 않으므로 노드 업데이트와 로컬 네트워크 설정을 분리하는 데 적합합니다. 저장 후에는 오버라이드 파일만 확인하지 말고 최종 적용 설정을 확인하세요. 클라이언트에 “병합 결과 미리 보기” 또는 “실행 설정 열기” 기능이 있다면 DNS와 TUN 필드가 한 번만 나타나는지, 들여쓰기가 올바른지, 규칙 삽입 위치가 예상과 일치하는지 확인하세요. 같은 이름의 키가 충돌하면 어느 계층이 우선인지 명확히 정하고 추측으로 해결하지 마세요.

다중 구독 병합 구조 설계

다중 구독은 모든 노드 텍스트를 단순히 이어 붙인다는 뜻이 아닙니다. 각 출처에 독립적인 proxy-providers를 만들고 서로 다른 캐시 경로를 설정한 뒤 정책 그룹에서 use로 참조하는 방식이 더 안정적입니다. 한 출처의 업데이트가 실패해도 다른 출처의 캐시에 영향을 주지 않으며 구성원이 어디에서 왔는지도 확인하기 쉽습니다. 제공자 이름은 안정적으로 유지하고, 정책 그룹은 제공자만 참조하며 변경될 수 있는 노드 이름을 직접 나열하지 마세요.

proxy-providers:
  provider-main:
    type: http
    url: https://subscription.example.com/main.yaml
    path: ./providers/main.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.example.com/
      interval: 900

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

proxy-groups:
  - name: 노드 선택
    type: select
    use:
      - provider-main
      - provider-backup
    proxies:
      - 자동 선택
      - DIRECT

  - name: 자동 선택
    type: url-test
    use:
      - provider-main
      - provider-backup
    url: https://www.example.com/
    interval: 600
    tolerance: 80

예제 URL은 구조를 보여 주기 위한 것이므로 실제로는 자신의 구독 주소를 사용하고 구독 주소를 민감한 정보로 관리해야 합니다. 각 제공자는 서로 다른 path를 사용해야 합니다. 경로가 같으면 나중에 업데이트된 내용이 이전 캐시를 덮어쓸 수 있습니다. 상태 확인과 정책 그룹 속도 테스트는 서로 다른 단계입니다. 제공자 상태 확인은 구성원의 사용 가능 여부를 표시하고, url-test는 그룹 내 선택을 결정합니다. 두 주기를 모두 너무 짧게 설정하면 테스트가 중복되며 모바일 기기에서는 특히 간격을 넉넉하게 설정해야 합니다.

여러 출처에 같은 이름의 노드가 포함될 수 있습니다. 인터페이스에 이름만 표시되면 어떤 노드를 선택했는지 판단하기 어렵습니다. 병합 단계에서 출처 접두사를 추가하거나 제공자별로 “주 구독”, “보조 구독”이라는 중간 그룹을 만든 뒤 전체 진입점에서 참조할 수 있습니다. 구독 업데이트로 순서가 바뀔 수 있으므로 노드 배열 순서에 의존하지 마세요. 필터 규칙도 출처별로 확인해 이름이 바뀌었을 때 지역 그룹이 갑자기 비지 않도록 해야 합니다.

업데이트, 실패 및 되돌리기

구독을 업데이트하기 전에 현재 캐시가 사용 가능한지 확인하세요. 업데이트가 실패해도 클라이언트가 기존 캐시를 계속 사용하는 경우가 많으므로 캐시를 삭제하고 반복해서 재시도하지 마세요. 먼저 구독 주소 조회, 네트워크 경로 및 반환 형식을 확인합니다. 원격 내용을 다운로드할 수 있지만 로드되지 않는다면 완전한 Clash 설정인지 단순 프록시 제공자 형식인지 확인하세요. 두 형식의 구조는 다릅니다. 클라이언트가 변환 기능을 제공하지 않는 한 완전한 설정을 provider 파일로 직접 사용할 수 없습니다.

로컬 오버라이드를 업그레이드할 때는 작은 단계로 마이그레이션하세요. 먼저 기본 profile과 DNS를 병합해 로드 여부를 확인하고, 다음으로 규칙 앞 추가를 넣으며, 마지막에 TUN과 스니핑을 활성화합니다. 이전 기기의 설정 전체를 한 번에 복사하면 플랫폼 전용 필드, 경로 및 인터페이스 이름이 호환되지 않을 수 있습니다. Windows, macOS, Android 및 Linux는 권한과 네트워크 스택이 다릅니다. 같은 논리는 유지하되 수신 주소, TUN 권한 및 로컬 경로는 다시 확인하세요.

클라이언트를 마이그레이션할 때는 먼저 구독 주소와 사용자 오버라이드를 내보내고 정책 그룹의 현재 선택을 기록하세요. 클라이언트 내부 캐시 디렉터리를 장기 백업으로 간주하지 마세요. 플랫폼에 따라 디렉터리 구조가 바뀔 수 있습니다. 유지 관리가 중단된 원본 클라이언트에서 옮기는 방법은 FlClash와 Clash Verge Rev 마이그레이션 방안 비교를 참고하세요. 새로 설치할 때는 클라이언트 다운로드 페이지에서 Clash Plus를 우선 선택하고 시스템과 프로세서 아키텍처에 맞게 설치한 뒤 위 설정을 단계별로 가져오세요.

외부 컨트롤러와 보안 경계

컨트롤 인터페이스로 할 수 있는 일

mihomo의 외부 컨트롤 인터페이스는 실행 상태 조회, 정책 그룹 전환, 제공자 업데이트, 연결 및 로그 확인에 사용됩니다. 그래픽 클라이언트 자체도 이 인터페이스를 통해 코어와 통신할 수 있습니다. 독립 컨트롤러는 인터페이스를 보여 주는 프런트엔드일 뿐 코어를 대체하지 않으며 설정 파일의 권한 범위도 변경하지 않습니다. 인터페이스 접근 가능 여부는 external-controller의 수신 주소, 시스템 방화벽 및 인증 키가 함께 결정합니다.

로컬에서만 사용할 때는 127.0.0.1:9090처럼 루프백 주소에서 수신하세요. 그러면 다른 로컬 네트워크 기기가 직접 연결할 수 없습니다. 다른 기기에서 관리해야 할 때만 로컬 네트워크 주소를 수신하도록 고려하고, 강력한 인증을 설정하며 방화벽의 출처를 제한하고 현재 네트워크를 신뢰할 수 있는지 확인하세요. 모든 네트워크 카드에서 인터페이스를 수신하면 접근 범위가 넓어집니다. 컨트롤러 페이지에 “키 입력란이 있어 보인다”는 사실만으로 안전하다고 판단해서는 안 되며 실제 보호는 API 연결 계층에서 이루어져야 합니다.

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

log-level: info
allow-lan: false

secret 예제 값은 반드시 기기 전용 값으로 바꾸고 구독 주소나 다른 계정 자격 증명과 공유하지 마세요. 클라이언트가 이미 컨트롤 인터페이스 설정을 자동으로 생성한다면 수동 오버라이드와 인터페이스 설정이 서로 덮어쓰지 않도록 클라이언트 설정에서 변경하는 것이 좋습니다. external-ui는 로컬 정적 컨트롤러 파일 디렉터리를 가리킵니다. 일부 클라이언트는 컨트롤러 리소스를 자동으로 다운로드하고 관리하지만 다른 클라이언트는 API만 제공하므로 호환되는 프런트엔드를 직접 준비해야 합니다. 경로는 클라이언트가 읽을 수 있는 설정 디렉터리 안에 있어야 합니다.

컨트롤러 연결 확인 순서

컨트롤러가 열리지 않을 때는 먼저 정적 페이지와 API를 구분하세요. 브라우저에서 컨트롤러 파일을 열 수 없다면 external-ui 경로와 클라이언트 리소스 관리를 확인합니다. 페이지는 열리지만 연결할 수 없다고 표시되면 컨트롤 주소, 포트, 키 및 브라우저 접근 출처를 확인하세요. 컨트롤 인터페이스가 루프백 주소에서 수신 중이라면 다른 기기에서 이 기기의 로컬 네트워크 IP를 입력해도 연결되지 않는 것이 정상입니다. 로컬 네트워크에서 수신하도록 바꿀 때는 운영체제 방화벽이 지정된 출처만 허용하는지 확인하고 전체 네트워크에 개방하지 마세요.

컨트롤러 주소에 HTTP와 HTTPS 중 무엇을 사용할지는 배포 방식에 따라 달라집니다. 루프백 주소를 통한 로컬 사용과 로컬 네트워크 원격 관리는 위험 수준이 다릅니다. 여러 기기에서 관리해야 한다면 관리되는 로컬 네트워크나 기존 보안 터널을 통해 접근하는 편이 안전하며 컨트롤 포트를 공인 인터넷에 직접 노출하지 마세요. 인터페이스는 정책을 전환하고 연결 대상을 조회하며 실행 상태를 변경할 수 있으므로 일반 상태 페이지가 아니라 관리 인터페이스로 취급해야 합니다.

curl -H "Authorization: Bearer your-control-secret" \
  http://127.0.0.1:9090/version

curl -H "Authorization: Bearer your-control-secret" \
  http://127.0.0.1:9090/proxies

이 명령은 로컬 API가 응답하는지 확인하는 데 사용합니다. 첫 번째 명령은 인터페이스와 인증이 작동하는지 확인하고, 두 번째 명령은 정책 및 프록시 구조를 조회합니다. 권한 없음이 반환되면 키가 일치하는지 확인하고, 연결이 거부되면 코어가 실행 중인지와 포트가 수신 중인지 확인하세요. 연결은 되지만 경로가 응답하지 않으면 현재 코어 인터페이스의 호환성을 확인합니다. 디버깅이 끝난 뒤 인증 정보가 포함된 명령을 공유 스크립트나 공개 로그에 저장하지 마세요.

연결 정보와 로그를 올바르게 활용하기

컨트롤러의 연결 목록은 세 가지 질문에 답하는 데 적합합니다. 트래픽이 코어로 들어오는가, 대상 정보가 도메인인가 IP인가, 최종적으로 어떤 규칙과 정책을 사용했는가입니다. 연결이 많이 보인다고 해서 비정상은 아닙니다. 최신 웹페이지는 여러 리소스를 동시에 요청합니다. 문제를 해결할 때는 대상 앱이나 도메인으로 필터링하고 기존 연결을 닫은 뒤 요청을 한 번 새로 보내는 것이 계속 스크롤되는 전체 목록을 바라보는 것보다 효과적입니다.

정책 그룹을 전환해도 기존 TCP 연결은 일반적으로 새 프록시로 자동 이동하지 않습니다. 테스트 결과가 달라지지 않는다면 해당 연결을 닫거나 대상 앱을 재시작한 뒤 새 연결이 사용하는 정책을 확인하세요. 규칙 제공자를 업데이트한 뒤에도 새 연결이 일치하는지 확인해야 하며 업데이트 버튼이 완료된 것만으로 판단해서는 안 됩니다. 컨트롤러에는 실행 상태가 표시되고 설정 파일은 다음 로드 상태를 결정합니다. 임시 전환이 재시작 후에도 유지되는지는 profile.store-selected와 클라이언트의 영구 저장 방식에 따라 달라집니다.

컨트롤러와 클라이언트 인터페이스에 서로 다른 상태가 표시되면 먼저 두 인터페이스가 같은 코어 인스턴스와 포트에 연결되어 있는지 확인하세요. 한 기기에서 이전 클라이언트 서비스, 명령줄 코어 및 새 클라이언트가 동시에 실행 중일 수 있습니다. 컨트롤러가 다른 인스턴스에 연결되면 “정책을 전환해도 효과가 없다”는 착각이 생깁니다. 프로세스, 수신 포트 및 설정 디렉터리를 확인하고 필요하지 않은 인스턴스를 종료한 뒤 다시 연결하세요. 완료 후 컨트롤 주소, 컨트롤러 경로 및 설정 파일 위치를 기기 문서에 기록하면 다음 마이그레이션이 더 쉬워집니다.

설정 검증, 문제 해결 및 장기 관리

고정된 순서로 전체 흐름을 검증하세요

복잡한 설정을 완료한 뒤 여러 앱을 동시에 사용해 테스트하지 마세요. 먼저 코어가 설정을 로드했고 YAML 또는 필드 오류가 없는지 확인합니다. 그다음 시스템 프록시 또는 TUN의 가로채기가 성공했는지 확인하고, 이어서 DNS 조회, 도메인 스니핑, 규칙 일치, 정책 그룹 선택 및 프록시 연결을 검증합니다. 각 단계에서는 하나의 질문만 확인하세요. 첫 단계에서 이미 실패했다면 뒤의 웹페이지 오류는 분석 가치가 없습니다. 고정된 순서를 지키면 실제 문제는 TUN 라우팅이 생성되지 않았는데 정책 그룹에서 노드만 바꾸는 일을 피할 수 있습니다.

로컬 테스트 표를 하나 준비해 대상, 예상 규칙, 예상 정책 및 검증 결과를 기록하는 것이 좋습니다. 최소한 로컬 네트워크 직접 연결, 일반 직접 연결, 프록시가 필요한 도메인, IP만 제공되는 연결, UDP 앱 및 최종 폴백을 포함하세요. 테스트할 때 컨트롤러나 로그에 실제 일치 항목을 기록합니다. 구독, 규칙 제공자, DNS 또는 클라이언트를 업데이트한 뒤 같은 테스트를 반복하면 결과를 비교할 수 있고 내용 변경인지 클라이언트 환경 변화인지 빠르게 확인할 수 있습니다.

# 로컬 혼합 프록시 포트가 수신 중인지 확인
curl -x http://127.0.0.1:7890 https://www.example.com/

# 외부 컨트롤 인터페이스 확인
curl -H "Authorization: Bearer your-control-secret" \
  http://127.0.0.1:9090/version

명령은 포트와 요청 경로만 확인하며 모든 규칙이 올바르다는 뜻은 아닙니다. 첫 번째 명령이 성공하면 앱이 로컬 프록시를 통해 요청을 보낼 수 있다는 뜻입니다. 브라우저가 여전히 작동하지 않으면 브라우저의 프록시 출처와 기존 연결을 확인하세요. 명령이 실패하면 오류를 연결 거부, DNS 실패, 인증 실패 또는 요청 시간 초과로 구분해 대응합니다. 모든 오류를 “노드를 사용할 수 없음”으로 묶지 마세요. 로컬 포트가 수신 중이지 않은 경우와 원격 프록시 장애는 처리 방법이 완전히 다릅니다.

증상별로 문제 해결 분기를 만드세요

“모든 대상이 실패”하면 코어, 포트, 권한, DNS 기본 경로 및 현재 정책 구성원을 먼저 확인합니다. “특정 도메인 하나만 실패”하면 도메인 조회, 규칙 일치 및 해당 서비스의 출구 요구 사항을 먼저 확인합니다. “특정 앱만 실패”하면 시스템 프록시에 들어오는지, 독립 DNS를 사용하는지, UDP만 사용하는지 확인합니다. “네트워크를 바꾼 뒤 실패”하면 출구 인터페이스, 라우팅 및 로컬 네트워크 DNS를 확인합니다. “구독 업데이트 후 실패”하면 제공자 형식, 정책 그룹 구성원 및 규칙 순서를 확인하세요.

로그에서 처음 발생한 오류가 뒤따르는 연쇄 오류보다 대개 더 중요합니다. DNS 초기화 실패는 노드 도메인 조회 실패, 제공자 업데이트 실패 및 모든 프록시 요청 시간 초과를 연이어 일으킬 수 있습니다. 마지막 오류만 보면 여러 구독이 동시에 무효화된 것으로 오해하기 쉽습니다. 일시적으로 debug를 활성화한 뒤 코어 시작 단계부터 읽으며 이번 변경과 관련된 첫 오류를 찾으세요. 수정한 뒤 다시 시작해 해당 오류가 사라졌는지 확인하고 다음 항목을 처리합니다.

업그레이드 및 마이그레이션 시 변수 통제

클라이언트 업그레이드, 코어 교체 및 설정 마이그레이션을 동시에 진행하지 마세요. 먼저 기존 클라이언트에서 작동하는 설정과 로컬 오버라이드를 내보냅니다. 새 클라이언트를 설치한 뒤 구독만 가져와 기본 연결을 완료하고, 그다음 정책 그룹, 규칙 제공자 및 DNS를 추가하며 마지막에 TUN, 스니핑 및 외부 컨트롤러를 활성화하세요. 이렇게 하면 문제가 발생한 단계가 필드 지원 문제인지, 플랫폼 권한 문제인지, 설정 내용 문제인지 분명해집니다. 플랫폼 간 마이그레이션에서는 경로 구분자, 서비스 권한, 네트워크 확장 및 방화벽도 다시 확인해야 합니다.

특정 인터페이스 이름이 영원히 유지된다고 가정하지 마세요. 장기 관리 기록은 “profile.store-selected를 활성화해 그룹 선택 저장”처럼 설정 필드와 동작을 중심으로 작성하고, “세 번째 화면의 두 번째 토글을 켬”처럼 작성하지 않는 것이 좋습니다. 인터페이스가 업데이트되면 버튼 위치는 바뀔 수 있지만 필드의 의미는 더 안정적입니다. 인터페이스를 통해 반드시 수행해야 하는 시스템 권한 부여는 플랫폼별 경로와 확인되는 현상을 추가로 기록할 수 있습니다.

문제가 발생하면 먼저 로그, 현재 설정 및 재현 절차를 보존한 뒤 되돌리세요. 오류 화면 하나만 남겨서는 연결이 어떤 단계들을 거쳤는지 판단하기 어렵습니다. 재현 절차에는 클라이언트, 가로채기 방식, 대상 앱, 예상 정책, 실제 일치 항목 및 네트워크 환경을 포함해야 합니다. 기본 개념이 여전히 불분명하다면 FAQ에서 “기본 이해, 설치 및 설정, 사용 팁, 문제 해결”을 기준으로 찾아보세요. 구독 가져오기와 모드 선택을 처음부터 다시 진행해야 한다면 사용 가이드로 돌아가세요.

장기간 안정적으로 사용할 수 있는 Clash 설정은 대개 복잡하지 않습니다. 구독은 프록시를 제공하고, 정책 그룹은 출구 선택을 표현하며, 규칙 제공자는 재사용 가능한 일치를 담당합니다. DNS는 도메인 정보를 보존하고, TUN은 필요할 때만 더 많은 트래픽을 가로채며, 스니핑은 누락된 도메인을 보완하고, 외부 컨트롤 인터페이스는 명확한 경계 안에 제한합니다. 한 번에 한 계층만 변경하고 고정된 테스트 세트로 검증하면 기능을 늘리면서도 설정을 읽기 쉽고 되돌리기 쉽고 마이그레이션하기 쉽게 유지할 수 있습니다.