설정 참고 mihomo 코어

Clash 설정 고급 가이드

정책 그룹, 규칙 세트와 네트워크 트래픽 처리 설정의 관계를 살펴봅니다.

주제별로 구성된 이 페이지는 구독을 가져온 뒤 트래픽 분기와 네트워크 동작을 조정하려는 사용자를 위한 자료입니다. 처음 사용한다면 빠른 시작 가이드에서 구독 가져오기, 모드 선택, 연결 확인을 마친 뒤 관련 항목을 살펴보세요. 두 페이지의 역할은 다릅니다. 가이드는 작업 순서를, 이 페이지는 설정 항목 간의 연동 방식과 변경 사항의 적용 시점, 이상 발생 시 점검할 계층을 설명합니다.

YAML 설정 예제 규칙은 위에서 아래로 매칭 실제 적용 설정 기준

정책 선택 / proxy-groups

정책 그룹 유형과 실제 트래픽 출구

정책 그룹은 규칙에 매칭된 트래픽을 어디서 처리할지 결정합니다. 규칙에 쓰인 Proxy는 이름일 뿐, 코어에 내장된 프록시 출구를 뜻하지 않습니다. 해당 이름에 대응하는 노드나 정책 그룹이 있어야 합니다. 연결은 업무 규칙에 먼저 매칭된 뒤 수동 선택 그룹을 거쳐 자동 테스트 그룹의 노드로 전달될 수 있습니다. 여러 그룹을 만드는 것보다 이 참조 구조를 이해하는 것이 중요합니다. 변경 전에는 구독에 포함된 노드 이름, 기존 그룹 이름, 규칙에서 참조하는 이름을 확인해 중복이나 끊어진 참조로 설정 로드가 실패하지 않도록 하세요.

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

select는 출구를 직접 선택할 수 있어 명확한 제어가 필요한 경우에 적합합니다. url-test는 지정한 테스트 주소의 응답을 기준으로 후보를 선택하므로 일상적인 자동 선택에 유용합니다. 다만 특정 네트워크 경로만 측정하므로 모든 웹사이트의 속도를 나타내지는 않습니다. fallback은 설정된 순서대로 사용 가능한 후보를 선택합니다. 우선순위를 유지하고 장애 시 전환하는 것이 목적이며, 지연 시간이 가장 짧은 후보를 고르는 기능은 아닙니다. 세 유형을 중첩할 수 있지만 구조는 단순하게 유지하고, 그룹끼리 서로를 참조하지 않도록 하세요.

load-balance는 여러 연결을 후보 노드에 분산합니다. 하나의 다운로드 연결에 여러 노드의 대역폭을 합산하는 기능은 아닙니다. 계정 세션, 출구 지역이나 서버의 위험 관리가 중요한 서비스에는 보통 고정 출구가 더 적합합니다. 분산 방식은 strategy의 영향을 받습니다. 예를 들어 consistent-hashing은 같은 대상이 비슷한 출구에 연결되도록 하지만, 후보가 바뀌면 결과도 달라질 수 있습니다. 사용자 신원이나 공인 IP가 계속 유지된다는 보장으로 이해해서는 안 됩니다.

config.yaml · 기존 provider를 참조하는 정책 그룹 예제
proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - 자동 선택
      - 장애 조치
      - DIRECT

  - name: 자동 선택
    type: url-test
    use:
      - 구독 소스
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: 장애 조치
    type: fallback
    use:
      - 구독 소스
    url: https://www.gstatic.com/generate_204
    interval: 300

노드 출처, 테스트와 선택 상태

위 예제를 사용하려면 이름이 “구독 소스”인 proxy-providers가 이미 있어야 합니다. use는 provider에 포함된 노드를 가져오고, proxies는 지정된 노드 이름, 정책 그룹 이름 또는 내장 정책을 참조합니다. 구독에서 노드가 추가되거나 삭제될 때 provider를 사용하면 항목을 일일이 관리하는 수고를 덜 수 있지만, provider 파일이 정상적으로 로드되는지는 확인해야 합니다. 클라이언트에서 그룹까지 포함된 전체 구독을 가져왔다면 같은 이름의 최상위 proxy-groups를 그대로 추가하지 마세요. 오버라이드나 유효 설정 편집으로 목록을 병합해야 합니다.

interval은 초 단위 테스트 간격입니다. tolerance는 자동 선택 시 허용하는 지연 시간 차이로, 단위는 밀리초입니다. 작은 차이로 자주 전환되는 현상을 줄이는 데 도움이 됩니다. 테스트 주소는 안정적으로 접속할 수 있고 실제 업무 경로와 최대한 비슷한 주소를 선택하세요. 노드 테스트 성공은 해당 테스트 요청이 완료됐다는 뜻일 뿐, 특정 웹사이트나 UDP, 모든 지역의 서비스가 사용 가능하다는 뜻은 아닙니다. 문제를 확인할 때는 테스트 연결과 실제 접속을 따로 살펴보세요.

provider의 상태 확인과 정책 그룹의 테스트는 설정 위치와 역할이 다릅니다. 전자는 노드의 사용 가능 여부를 관리하고, 후자는 그룹 내 노드를 선택하는 데 쓰입니다. 원인을 쉽게 찾으려면 처음 설정을 바꿀 때 테스트 주소, 간격, 필터 조건, 그룹 유형을 한꺼번에 변경하지 마세요. 먼저 확실히 사용할 수 있는 후보 출구를 하나 남기고 자동 그룹이 이를 참조하는지 확인합니다. 후보 목록이 비어 있다면 글로벌 모드를 반복해서 바꾸기보다 provider와 필터 표현식을 먼저 점검하세요.

유형주요 용도주의 사항
select수동으로 고정 선택DIRECT를 선택하면 직접 연결
url-test테스트 결과에 따라 자동 선택테스트 주소가 판단에 영향
fallback순서에 따라 장애 조치후보 순서가 우선순위 결정
load-balance연결별로 트래픽 분산단일 연결의 대역폭을 합산하지 않음

규칙과 정책 그룹의 연결 관계 확인

변경 후에는 연결 상세 정보에서 매칭된 규칙과 정책 경로를 먼저 확인하세요. 규칙이 업무 그룹에 매칭됐는데 마지막 출구가 DIRECT라면 도메인 규칙보다 그룹의 선택 항목을 점검하는 편이 좋습니다. 노드가 실제로 바뀌었는데도 페이지 상태가 그대로라면 기존 연결을 닫고 다시 시도하세요. 이미 열린 TCP 세션은 그룹을 수동으로 바꿔도 다른 출구로 자동 이동하지 않습니다. 브라우저 연결 풀, 앱의 백그라운드 연결, 캐시 때문에 결과가 늦게 반영될 수 있으므로 새 연결로 확인하세요.

실제 설정은 전체 진입 그룹 하나를 두고, 필요한 업무에 한해 소수의 하위 그룹을 나누는 편이 좋습니다. 특정 업무에 고정 지역, 다른 전송 기능 또는 별도의 장애 대응이 필요할 때만 그룹을 나누는 것이 효과적입니다. 노드 선택, 테스트 결과와 지역 판단의 차이는 프록시 노드 선택 방법에서 확인하세요. 클라이언트 화면의 동작과 코어의 결과가 다르다면 자주 묻는 질문에서 프록시 모드와 시스템 프록시의 차이를 먼저 살펴보세요.

규칙 관리 / rule-providers

규칙 세트 구독 관리와 매칭 순서

규칙 목록은 “이 연결을 어떤 정책으로 보낼지” 결정합니다. Rule 모드에서 코어는 일반적으로 rules를 위에서 아래로 확인하며, 처음 매칭된 규칙이 이후 정책을 결정합니다. 더 구체적인 규칙을 찾아 계속 검사하지 않습니다. 따라서 순서는 설정의 의미를 결정합니다. 개인 예외는 넓은 범위의 규칙보다 앞에, 최종 기본 규칙은 맨 마지막에 둡니다. 항목을 보기 좋게 정렬한다고 논리가 맞아지는 것은 아닙니다. 예외, 업무 분류와 기본 규칙의 우선순위를 관리해야 합니다.

규칙 관리 출처와 로컬 정책 분리

rule-providers에서 재사용할 규칙 세트를 정의하고, 주 규칙 목록에서는 RULE-SET으로 이를 참조합니다. 규칙 세트는 어떤 대상을 매칭할지 정하고, 실제로 적용할 정책은 참조하는 규칙 행에서 지정합니다. 이 구조를 사용하면 상위 규칙 파일을 수정하지 않고도 여러 기기에서 같은 도메인 목록에 서로 다른 출구를 적용할 수 있습니다. 자주 업데이트해야 하는 대용량 목록을 구독에 통째로 복사하는 것보다 검토하고 되돌리기도 쉽습니다.

로컬 파일로 먼저 전체 흐름을 확인한 다음 원격 소스로 전환하면 문제를 찾기 쉽습니다. 다음은 실제로 사용할 수 있는 로컬 규칙 세트입니다. 주 설정 파일과 규칙 파일은 모두 mihomo 작업 디렉터리를 기준으로 배치합니다. 실제 작업 디렉터리는 실행 방식과 클라이언트의 관리 방식에 따라 달라지며, 다운로드 폴더와 같다고 볼 수 없습니다. 경로가 잘못되면 파일 내용이 올바르더라도 코어가 규칙 세트를 로드하지 못합니다.

config.yaml · 로컬 classical 규칙 세트
mode: rule
rule-providers:
  development:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/development.yaml

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - RULE-SET,development,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy
rules/development.yaml
payload:
  - DOMAIN-SUFFIX,github.com
  - DOMAIN-SUFFIX,githubusercontent.com

behavior와 format은 콘텐츠에 맞춰 설정

behavior: classical은 예제의 DOMAIN-SUFFIX처럼 규칙 유형이 포함된 항목을 사용합니다. 항목에 Proxy를 추가로 쓰지 않는 이유는 정책이 RULE-SET 참조 행에 지정되기 때문입니다. domain은 도메인 목록, ipcidr은 주소 범위 목록에 사용하며, classical과 항목 문법을 혼용할 수 없습니다. format은 YAML이나 일반 텍스트 같은 페이로드 형식을 나타냅니다. 파일 확장자만으로 올바른 형식 선언을 대신할 수는 없습니다.

HTTP 소스로 바꿀 때는 type을 http로 변경하고, 실제로 접속할 수 있는 url과 초 단위 interval을 추가한 뒤 캐시용 path를 지정하세요. provider마다 서로 다른 파일 경로를 사용해 내용이 덮어쓰이지 않게 합니다. 다운로드된 오류 페이지, 접근 확인 페이지, 로그인 페이지는 규칙 파일이 아닙니다. 브라우저에서 링크가 열린다고 해서 코어가 예상한 페이로드를 받았다는 뜻은 아닙니다.

원격 규칙을 처음 배포할 때는 콜드 스타트에서도 파일을 가져올 수 있는지 확인하세요. 규칙을 가져오는 도메인에 접속하려면 해당 규칙이 먼저 필요한 상황이라면 시작 단계에서 의존성이 발생합니다. 다운로드 경로가 작동하는지 먼저 확인하고 검증된 로컬 캐시를 유지하는 편이 안전합니다. 규칙 provider 다운로드 실패와 프록시 노드 사용 불가는 서로 다른 문제입니다. 업데이트 로그와 연결 로그를 각각 확인하고, 웹사이트가 열리지 않는다는 이유만으로 어느 계층의 문제인지 단정하지 마세요.

범위를 좁혀 요청하고 트래픽 분기 확인

새 규칙을 확인할 때는 대상 규칙 세트에 확실히 포함된 도메인 하나를 선택해 새 연결을 만든 뒤, 연결 상세 정보에서 매칭 규칙, 규칙 페이로드와 정책 경로를 확인하세요. 앞에 있는 DIRECT 규칙에 먼저 매칭됐다면 우선순위를 조정합니다. 예상한 규칙 세트가 나타나지 않으면 provider 이름, 로드 상태와 파일 내용을 확인하세요. IP 유형 규칙은 조회 결과나 대상 주소 정보에도 영향을 받으므로 도메인 매칭을 언제나 대신할 수 있다고 가정해서는 안 됩니다.

LAN 기기, 프린터와 로컬 서비스에는 명확한 직접 연결 범위를 우선 적용하고, 넓은 프록시 규칙에 먼저 잡히지 않는지 확인하세요. REJECT 규칙을 추가하기 전에는 대상 도메인을 여러 업무가 함께 사용하는지 살펴봐야 합니다. 콘텐츠 전송 도메인을 잘못 거부하면 로그인, 이미지 표시나 업데이트에 문제가 생길 수 있습니다. 문제를 찾는 동안 의심스러운 규칙을 결과를 확인할 수 있는 정책으로 잠시 바꾸고 기록을 남기세요. 규칙 전체를 바로 삭제하면 단서를 잃을 수 있습니다.

규칙 세트 업데이트는 외부 입력 변경이므로 구독 노드 업데이트와 따로 관리해야 합니다. 업데이트 뒤 특정 유형의 웹사이트만 문제가 생겼다면 DNS와 TUN을 동시에 초기화하기보다 해당 규칙 파일을 되돌리거나 관련 RULE-SET을 잠시 비활성화하세요. 개인 예외는 가능한 한 로컬 오버라이드에 보관하고, 이유와 적용 대상을 주석으로 적어 두면 상위 목록을 업데이트해도 설정을 유지할 수 있습니다. 코어와 구버전 규칙 기능의 차이는 mihomo와 원본 Clash 코어 비교에서 확인하세요.

해석 경로 / dns

DNS 설정 최적화와 조회 경로

DNS 설정에서는 세 가지를 먼저 확인해야 합니다. 누가 조회를 시작하는지, 어떤 출구를 통해 DNS 서버에 도달하는지, 조회 결과를 어떤 연결에서 사용하는지입니다. 시스템 DNS, 브라우저 보안 DNS, 앱 내장 조회와 mihomo DNS가 동시에 작동할 수 있습니다. nameserver만 바꿔서는 모든 앱의 DNS 조회가 코어를 거친다고 보장할 수 없습니다. 웹페이지가 열린다는 이유만으로 예상한 방식으로 조회됐다고 판단할 수도 없습니다. 여러 서버 주소를 한꺼번에 입력하기보다 실제 조회 경로를 먼저 그려 보세요.

시작 단계의 조회와 일반 도메인 조회 구분

default-nameserver는 DNS 서버 자체의 도메인을 조회할 때 사용합니다. 암호화된 DNS 서버에 요청하려면 먼저 서버 주소를 알아야 하는 문제를 해결합니다. nameserver는 일반 도메인 조회에 사용하는 상위 DNS 서버입니다. proxy-server-nameserver는 프록시 노드 도메인 조회에 사용하며, 프록시 연결에 필요한 기본 조회와 일반 도메인 조회를 분리하는 데 도움이 됩니다. 각 항목은 서로 다른 단계에서 쓰이므로 단순한 첫 번째, 두 번째, 세 번째 예비 서버 순서가 아닙니다.

먼저 프록시 출구에 의존하지 않는 기본 설정을 살펴보겠습니다. 이 설정으로 리스닝 주소, 상위 DNS 서버와 도메인 정책이 작동하는지 확인할 수 있지만, 모든 네트워크에서 개인정보 보호나 접속 가능성을 보장하지는 않습니다. DNS 서버 주소는 실제 네트워크와 유지 관리 조건에 맞춰 선택하세요. 한 네트워크에서 사용할 수 있는 공용 DNS 서버가 모든 접속 환경에서 동작하는 것은 아닙니다.

config.yaml · 기본 DNS 설정 예제
dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  nameserver:
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    '+.example.com':
      - https://dns.alidns.com/dns-query

도메인별 DNS 서버 선택과 규칙별 출구 선택

nameserver-policy는 도메인에 따라 사용할 상위 DNS 서버를 선택합니다. 예제의 +.example.com은 해당 도메인과 하위 도메인에 적용됩니다. 이 설정은 “어떤 DNS 서버에 물어볼지”를 정할 뿐, “웹사이트 연결을 어디로 보낼지”를 직접 결정하지 않습니다. 연결 정책은 프록시 모드, 규칙과 정책 그룹이 정합니다. 기업 내부 도메인은 조직 내부 DNS가 필요할 수 있으며, 공용 DNS에는 해당 레코드가 없을 수도 있습니다. 현재 네트워크에서 내부 DNS에 접속할 수 있는지 먼저 확인하세요.

DNS 상위 서버 연결에도 라우팅 규칙을 적용하려면 respect-rules 사용을 검토할 수 있습니다. 활성화하기 전에 프록시 노드 도메인을 조회하는 방법을 마련해야 합니다. 노드 조회에 프록시가 필요하지만 프록시 연결에도 노드 조회가 필요한 순환 문제가 생길 수 있습니다. “DNS 누출 방지” 설정을 그대로 복사했다고 구성이 끝난 것은 아닙니다. 특히 캐시가 비어 있는 첫 실행 때 노드 조회, 상위 서버 연결과 일반 도메인 조회를 각각 확인하세요.

fallback과 fallback-filter에는 별도의 응답 필터링 방식이 있으므로 단순히 “첫 번째 서버가 실패하면 두 번째 서버에 질의”하는 기능으로 보면 안 됩니다. 상위 DNS 서버를 많이 추가한다고 안정성이 높아지는 것도 아닙니다. 서로 다른 주소를 반환해 콘텐츠 전달 경로나 장애 양상이 달라질 수 있습니다. 명확한 필터링 필요가 없다면 설명하기 쉬운 소수의 서버부터 사용하고, 조회 경로를 기록한 뒤 설정을 확장하세요.

리스닝, 캐시와 IPv6 범위

예제는 루프백 주소의 1053 포트에서 요청을 받습니다. 포트가 열려 있다고 해서 시스템이 자동으로 이를 사용하는 것은 아닙니다. 시스템 DNS 설정에서 사용자 지정 포트를 직접 지정할 수 없는 경우가 많으므로 TUN의 DNS 가로채기, 시스템 DNS 서비스의 전달 기능 또는 포트 지정이 가능한 테스트 도구가 필요합니다. dig로 리스닝 주소를 직접 확인할 수 있지만, 명령 결과는 코어에 명시적으로 보낸 해당 조회만을 나타냅니다. 모든 앱이 연결됐다는 뜻은 아닙니다.

dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com AAAA

dns.ipv6는 코어 DNS가 AAAA 조회를 처리하는 방식을 제어하고, 최상위 ipv6는 코어의 IPv6 지원과 관련됩니다. 서로 다른 계층의 설정입니다. 둘 중 하나를 끈다고 운영체제나 브라우저가 IPv6를 완전히 사용하지 않는 것은 아닙니다. 일부 앱만 예상한 경로를 우회한다면 DNS 설정의 한 값만 반복해서 바꾸기보다 시스템 IPv6 경로, 앱의 보안 DNS, 프록시 연결 방식과 기존 연결을 확인하세요.

DNS 정책을 바꾼 뒤에도 캐시 때문에 이전 결과가 표시될 수 있습니다. 코어, 시스템과 브라우저 캐시를 각각 고려하고 필요하면 기존 연결을 닫은 뒤 다시 조회하세요. Fake-IP 주소가 보인다고 실제 서버의 지역을 판단할 수는 없습니다. Fake-IP는 코어가 할당한 매핑 주소일 뿐입니다. DNS 오염, 가로채기 범위와 암호화 DNS 경로를 확인하려면 DNS 누출 검사 및 해결 방법을 참고해 검사, 수정, 재검사 순서로 하나씩 확인하세요.

네트워크 가로채기 / tun

TUN 모드와 Fake-IP의 연동

TUN은 가상 네트워크 인터페이스를 통해 시스템 라우팅이 전달한 IP 트래픽을 받습니다. 시스템 HTTP 프록시를 따르지 않는 앱에 적합합니다. Fake-IP는 DNS 동작 방식 중 하나로, 도메인에 매핑용 주소를 반환합니다. 두 기능을 함께 설정하는 경우가 많지만 해결하는 문제는 다릅니다. TUN은 트래픽이 코어에 들어오는 방식을 정하고, Fake-IP는 코어가 도메인과 연결의 관계를 유지하도록 돕습니다. TUN을 켠다고 모든 DNS 경로가 자동으로 수정되는 것은 아니며, 모든 상황에서 Fake-IP에 TUN이 필요한 것도 아닙니다.

권한과 시스템 라우팅부터 확인

데스크톱 클라이언트는 서비스 모드나 권한 상승을 통해 가상 인터페이스와 경로를 만들 수 있습니다. 모바일은 흔히 시스템 VPN 인터페이스로 연결되며, 화면에 VPN 모드라고 표시될 수도 있습니다. 데스크톱의 네트워크 인터페이스 설정을 그대로 적용해서는 안 됩니다. Linux 역시 실행 권한, 라우팅 관리와 DNS 서비스가 배포 방식에 따라 달라집니다. 처음 활성화할 때는 클라이언트에서 트래픽 가로채기 성공 여부를 확인한 뒤 라우팅과 DNS를 점검하세요. 스위치가 켜졌다는 표시만으로 네트워크 스택이 정상 작동한다고 판단하지 마세요.

아래 예제는 자동 라우팅과 DNS 가로채기의 관계를 보여주며, 앞 장의 DNS 설정과 함께 사용해야 합니다. stack은 시스템과 코어의 지원 여부에 따라 선택할 수 있습니다. mixed가 모든 기기에서 더 빠르다는 보장은 없습니다. 다른 VPN, 컨테이너 네트워크나 기업용 터널이 이미 있으면 자동 라우팅이 충돌할 수 있으므로 복구할 수 있는 로컬 환경에서 항목별로 테스트하세요.

config.yaml · TUN과 DNS 연동 설정 예제
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'

DNS 가로채기는 모든 DNS 프로토콜을 제어하는 설정이 아님

dns-hijack의 any:53은 가로채기 경로로 들어오는 일반 DNS 트래픽에 적용됩니다. 앱이 HTTPS나 다른 암호화 프로토콜로 DNS 서버에 접속하면, 내용이 DNS라고 해서 자동으로 53번 포트 요청으로 바뀌지 않습니다. 브라우저 보안 DNS와 앱 자체 DNS 조회는 따로 확인해야 합니다. DNS 경로를 통일하려면 앱이 시스템 DNS를 사용하도록 하고, 시스템 조회가 실제로 코어에 들어오는지 확인하세요.

auto-detect-interface는 실제 출구 네트워크 인터페이스를 선택하는 데 도움이 됩니다. 하지만 여러 네트워크 카드, 핫스팟 공유, 네트워크 전환이나 기존 터널 때문에 자동 선택이 의도와 다를 수 있습니다. TUN을 켠 뒤 모든 연결이 시간 초과되고 끄면 바로 복구되는 경우가 대표적입니다. 이때는 실제 기본 출구와 라우팅이 순환하는지 확인한 뒤 코어 연결 로그를 살펴보세요. 노드를 계속 바꾸는 것으로 출구 선택 문제를 해결하기는 어렵습니다. 원격 서버를 관리할 때는 특히 별도의 복구 경로를 마련하세요.

일부 시스템에서는 strict-route로 라우팅 제약을 강화할 수 있지만, LAN 접속에 영향을 주거나 다른 네트워크 구성 요소와 충돌할 수도 있습니다. 원인을 찾지 못한 상태에서 무작정 켜기에는 적합하지 않습니다. 먼저 최소 설정으로 직접 연결, 프록시와 로컬 네트워크의 동작을 기록한 뒤 명확한 필요에 따라 제한을 추가하세요. 플랫폼마다 방화벽과 라우팅 구현이 다르므로 같은 설정 조각이 같은 결과를 보장하지 않습니다.

Fake-IP 예외와 로컬 서비스

일부 기기 검색, LAN 서비스나 실제 주소가 필요한 앱은 Fake-IP 매핑에 적합하지 않습니다. fake-ip-filter로 예외를 설정할 수 있습니다. 예제에는 보통 로컬 DNS 조회가 필요한 도메인 접미사가 들어 있지만, 실제 예외는 사용하는 앱에 따라 정해야 합니다. 예외에 추가된 도메인은 해당 모드에 따라 실제 조회 결과를 반환합니다. 그렇다고 관련 트래픽이 반드시 직접 연결되는 것은 아닙니다. 이후 규칙에 따라 실제 주소 연결이 프록시로 전달될 수도 있습니다.

Fake-IP 모드나 매핑 범위를 바꾼 뒤에도 앱이 이전 주소를 계속 사용할 수 있습니다. 기존 매핑과 새 코어 상태가 일치하지 않으면 DNS 조회는 성공한 것처럼 보이지만 연결은 실패할 수 있습니다. 먼저 관련 앱의 연결을 종료하고 해당 계층의 DNS 캐시를 갱신한 다음 다시 요청하세요. 예약 주소 범위 전체를 원격 서비스 주소로 간주해 일반 프록시 규칙에 추가하지 마세요. 이 주소는 로컬 매핑에 쓰이며 실제 대상은 코어의 연관 정보로 복원됩니다.

문제 해결 순서는 다음과 같이 고정하는 편이 좋습니다. 먼저 가상 인터페이스와 권한을 확인하고, 일반 DNS가 가로채기되는지 살펴본 뒤, 연결이 코어에 들어오는지 확인하고 마지막으로 규칙과 정책 그룹을 점검하세요. UDP 앱만 문제가 있다면 TUN 스택만 바꾸지 말고 노드 프로토콜, 서버와 네트워크 경로가 필요한 UDP를 지원하는지도 확인해야 합니다. LAN에 프록시를 공유하려는 경우에는 리스닝 주소, 방화벽과 접속 범위도 따로 살펴보세요. mixed-port 및 allow-lan 설정을 참고할 수 있습니다. TUN을 켜는 것만으로 다른 기기에 프록시가 설정되지는 않습니다.

도메인 연결 정보 / sniffer

도메인 스니핑의 용도와 한계

도메인 스니핑은 연결 정보에 대상 IP만 있고 신뢰할 만한 도메인 정보가 없을 때, 일부 프로토콜의 핸드셰이크나 요청에서 도메인을 추출해 규칙 판정을 보조합니다. DNS와는 다릅니다. DNS는 이름을 조회하고, 스니핑은 이미 코어에 들어온 연결을 살펴봅니다. 암호화된 연결을 해독하는 프록시도 아니므로 기능을 켠다고 모든 HTTPS 본문을 읽을 수 있는 것은 아닙니다. 스니핑의 효과를 따지기 전에 트래픽이 코어에 도달했는지 먼저 확인하세요. 가로채지 못한 연결은 처리 대상이 아닙니다.

지원 프로토콜과 포트 범위를 명확히 지정

mihomo에서는 HTTP, TLS, QUIC 등을 스니핑 대상으로 설정할 수 있습니다. HTTP에서는 Host 정보를 확인할 수 있고, TLS는 보통 핸드셰이크의 서버 이름에서 단서를 얻습니다. QUIC에도 이에 맞는 처리 경로가 있습니다. 하지만 프로토콜의 변화, 암호화된 핸드셰이크 방식, 클라이언트 구현과 트래픽 형태에 따라 결과가 달라지므로 모든 연결에서 도메인이 보인다고 보장할 수 없습니다. IP를 직접 사용하는 앱이나 지원되지 않는 프로토콜은 결국 IP 유형 규칙과 기본 정책을 사용해야 할 수 있습니다.

처음에는 필요한 포트만 지정하고 규칙 매칭이 개선되는지 확인한 뒤 범위를 넓히세요. 포트는 필터 조건일 뿐 해당 트래픽이 반드시 특정 프로토콜을 사용한다는 뜻은 아닙니다. 모든 포트를 포함해도 결과를 더 쉽게 설명할 수 있는 것은 아닙니다. 아래 예제는 연결의 실제 대상을 덮어쓰지 않고 도메인 추출만 활성화합니다. “무엇을 식별했는지”와 “대상을 변경했는지”를 나눠 테스트하기에 적합합니다.

config.yaml · 보수적인 스니핑 설정 시작점
sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true
  override-destination: false
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
    TLS:
      ports:
        - 443
    QUIC:
      ports:
        - 443
  skip-domain:
    - '+.example.com'

도메인 식별과 연결 대상 덮어쓰기 구분

parse-pure-ip를 사용하면 도메인 정보가 없는 IP 연결에서도 스니핑을 시도할 수 있습니다. force-dns-mapping은 DNS 매핑과 관련된 연결의 처리 범위를 넓힙니다. 어느 설정도 성공을 보장하지 않으며 DNS 설정을 무시해도 된다는 뜻도 아닙니다. override-destination은 스니핑 결과로 연결 대상을 덮어쓸지 결정합니다. 단순히 도메인을 식별하는 것보다 영향이 크므로 대상 서비스의 특성을 이해한 뒤 검토하세요.

예를 들어 앱이 자체 분산 로직으로 서비스 IP를 선택한 다음 TLS 핸드셰이크에 도메인을 포함할 수 있습니다. 대상을 덮어쓴 뒤 도메인 기준으로 다시 연결하면 실제 주소 선택이 달라져 기존 분산 로직이나 접속 가능성에 영향을 줄 수 있습니다. 따라서 “스니핑을 켠 뒤 일부 사이트가 이상하다”면 도메인 규칙이 바뀐 것인지 연결 대상이 덮어써진 것인지 먼저 구분하세요. 전체 설정을 초기화하는 것보다 연결 로그를 남기고 같은 요청에서 대상 덮어쓰기와 스니핑을 각각 끄고 비교하는 편이 진단에 도움이 됩니다.

skip-domain을 사용하면 지정한 도메인을 스니핑 대상에서 제외할 수 있습니다. 위 예제의 example.com은 문법 설명용이며 일반적으로 필요한 예외가 아닙니다. 실제로 필요한 도메인만 남기세요. 예외 범위가 너무 넓으면 스니핑에 의존하던 도메인 분기 기준이 사라질 수 있고, 너무 좁으면 하위 도메인 일부가 빠질 수 있습니다. 예외를 추가한 뒤 새 연결을 만들고 식별된 이름이 예상과 같은지 확인하세요.

검증할 수 있는 트래픽 분기 경로에 스니핑 적용

검증에는 반복해서 사용할 수 있는 대상을 하나 고르세요. 스니핑을 끈 상태에서 대상 주소, 규칙과 정책을 기록하고, 스니핑을 켠 뒤 새 연결을 만듭니다. 규칙이 IP 유형에서 DOMAIN-SUFFIX로 바뀌었다면 도메인 정보가 매칭에 사용된 것입니다. 아무 변화가 없더라도 기능이 작동하지 않는다고 바로 판단하지 마세요. 연결에 이미 DNS 매핑 정보가 있었거나 스니핑에서 사용할 수 있는 이름을 얻지 못했을 수 있습니다. 페이지 로딩에 여러 도메인이 관여한다면 홈페이지의 기본 도메인만 보지 말고 실패한 연결을 확인하세요.

스니핑으로 식별한 이름이 주소 표시줄의 도메인과 같다는 보장도 없습니다. 리디렉션, 콘텐츠 전송, 리소스와 백엔드 서비스에서 서로 다른 이름을 사용할 수 있습니다. 업무에 안정적인 지역이나 고정 출구가 필요하다면 기본 도메인 하나로 전체 리소스를 추정하지 말고 실제 연결에 사용되는 도메인 목록을 관리하세요. 규칙이 매칭된 뒤에도 노드 선택은 정책 그룹이 담당합니다. 스니핑으로 노드 접속 불가, 계정 만료나 서버 제한을 해결할 수는 없습니다.

실제 운영에서는 꼭 필요한 최소 범위만 유지하고, 스니핑을 설정 오류를 덮는 수단으로 사용하지 마세요. 먼저 시스템 DNS, Fake-IP 매핑과 TUN 가로채기가 각각 올바르게 동작하도록 한 뒤 도메인 정보가 없는 연결을 스니핑으로 보완하세요. 특정 앱에서만 문제가 생긴다면 해당 앱에 필요한 예외를 지정하고 주석을 남긴 뒤 원인을 확인해 장기 대책을 정하세요. 기본 개념은 용어집에서 확인할 수 있습니다. 처음 구독을 가져온 뒤 인터넷에 연결되지 않는 문제라면 스니핑 범위부터 넓히지 말고 시작 가이드의 순서에 따라 프록시 연결과 노드를 확인하세요.

설정 변경 주기 / merge

로컬 오버라이드와 여러 구독 병합

구독 파일은 외부에서 제공되는 입력이고, 로컬 오버라이드는 사용자가 관리하는 설정 계층입니다. 실제 적용 설정은 클라이언트가 두 항목을 처리해 만든 결과입니다. 이 세 가지를 혼동해서는 안 됩니다. 다운로드한 구독 파일을 직접 수정하면 다음 업데이트 때 변경 내용이 덮어써질 수 있습니다. 오버라이드 템플릿만 수정하고 현재 설정에 적용하지 않으면 코어 동작도 바뀌지 않습니다. 변경하기 전에 클라이언트에서 현재 활성화된 설정, 오버라이드 적용 범위와 최종 생성 파일을 확인해 잘못된 대상을 계속 수정하지 않도록 하세요.

설정 계층별 관리 주체부터 정하기

클라이언트마다 오버라이드 화면과 병합 방식이 다르므로 모든 그래픽 클라이언트에서 통용되는 override 최상위 YAML 항목은 없습니다. 현재 클라이언트가 제공하는 오버라이드, 병합 또는 스크립트 기능을 사용하고 매핑, 목록과 빈 값이 어떻게 처리되는지 확인하세요. 다운로드 페이지에는 Clash Plus, Clash Verge Rev, FlClash 등 여러 플랫폼용 클라이언트가 있지만 설정 편집 화면이 모두 같다는 뜻은 아닙니다.

비교적 관리하기 쉬운 구조는 구독이 노드 정보를 맡고 로컬 설정 계층이 정책 그룹, 규칙, DNS와 제어 인터페이스를 맡는 방식입니다. 구독에 이미 전체 트래픽 분기 설정이 포함되어 있다면 상위 구조를 유지할지, 노드만 가져와 로컬에서 관리할지 먼저 정하세요. 두 구조를 함께 적용하면 이름이 같은 그룹, 중복된 MATCH 규칙과 설정 덮어쓰기가 생길 수 있습니다. 장기적인 유지 관리에서 중요한 것은 파일을 더 크게 만드는 것이 아니라 각 항목을 어느 출처에서 관리할지 명확히 정하는 것입니다.

provider로 여러 노드 출처 분리

아래 예제는 원격 구독 주소를 포함하지 않고 로컬 노드 provider 두 개의 구조를 보여줍니다. 각 provider 파일에는 올바른 proxies 목록과 실제로 사용할 수 있는 노드가 필요하며, 주 설정에서 use로 가져옵니다. 먼저 클라이언트에서 내보낸 유효한 provider 파일로 확인한 뒤 HTTP 소스를 추가하면 소스 다운로드 문제와 노드 설정 문제를 분리할 수 있습니다.

config.yaml · 두 출처 병합 예제
proxy-providers:
  source-a:
    type: file
    path: ./providers/source-a.yaml
  source-b:
    type: file
    path: ./providers/source-b.yaml

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - 출처 A
      - 출처 B
      - DIRECT
  - name: 출처 A
    type: select
    use:
      - source-a
  - name: 출처 B
    type: select
    use:
      - source-b

rules:
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

전체 구독과 노드 provider 파일의 구조는 다릅니다. rules, proxy-groups 등 최상위 항목이 포함된 전체 설정은 다운로드 주소에 접속할 수 있다는 이유만으로 올바른 노드 provider 페이로드가 되지 않습니다. 클라이언트에서 구독 변환이나 추출 기능을 제공한다면 변환 결과의 형식을 확인하세요. 개인 구독 링크를 다룰 때는 통제 가능한 로컬 처리 방식을 우선 사용하고, 출처를 알 수 없는 변환 서비스에 접근 정보를 제공하지 마세요.

매핑, 목록과 이름 충돌 처리

YAML 매핑은 키를 기준으로 병합할 수 있지만, 목록에는 공통된 기본 병합 방식이 없습니다. 클라이언트가 rules 목록 전체를 교체하거나 앞이나 뒤에 추가할 수 있으므로 실제 생성 결과를 확인해야 합니다. 로컬 예외가 상위 MATCH 뒤에 추가되면 파일에 있어도 적용되지 않습니다. 반대로 proxy-groups를 모두 교체하면 상위 규칙에서 참조하는 기존 그룹 이름이 사라질 수 있습니다. 설정 검사를 통과했다는 것은 구조와 참조에 큰 문제가 없다는 뜻일 뿐, 트래픽 분기 의도까지 맞다는 보장은 아닙니다.

하나의 YAML 매핑에 dns나 rules를 중복으로 써서 파서가 자동 병합할 것이라고 기대하지 마세요. 중복 키는 거부되거나 뒤쪽 값으로 덮어써질 수 있으며 결과는 파서 구현에 따라 다릅니다. 하나의 키 아래에 전체 내용을 정리하고 들여쓰기 계층을 유지하세요. YAML 들여쓰기에 탭은 적합하지 않습니다. 콜론 뒤 공백, 목록 앞 하이픈, 문자열 따옴표도 올바르게 입력해야 합니다. 복잡한 도메인 패턴이나 특수 문자가 포함된 값은 따옴표로 명시하는 편이 안전합니다.

여러 출처의 노드 이름이 겹칠 수 있습니다. 이를 단일 목록으로 병합하면 참조가 모호해지거나 클라이언트가 이름을 바꿀 수 있습니다. 출처별 그룹을 사용하면 구분하기 쉽지만, 적용 설정에 표시되는 노드 식별자와 이름도 확인해야 합니다. 화면에 두 출처가 보인다고 완전히 분리된 것은 아닙니다. 상태 확인, 캐시 파일과 저장된 선택 상태도 각각 검증하세요.

적용, 검사와 되돌리기

변경 전에 정상적으로 작동하던 설정을 저장하고 로컬 오버라이드도 별도로 기록하세요. 아래 문법 검사는 mihomo 명령줄 도구를 사용할 수 있는 환경에서 실행할 수 있습니다. 실제 설정 파일과 해석 가능한 참조 리소스가 필요합니다. 그래픽 클라이언트가 코어를 관리한다면 클라이언트의 검사와 적용 기능을 우선 사용하고, 같은 포트에서 코어를 하나 더 실행하지 마세요.

mihomo -t -f ./config.yaml

DNS, 정책 그룹, 규칙, TUN 순으로 한 번에 한 종류만 변경하고, 적용 후 유효 설정과 새 연결을 확인하세요. 실패하면 가장 최근에 변경한 부분만 되돌리면 됩니다. 구독을 모두 삭제하거나 클라이언트를 다시 설치할 필요는 없습니다. 구독 업데이트 후에는 개인 예외가 유지됐는지, 출처가 갱신됐는지, 기본 규칙이 여전히 맨 마지막에 있는지 다시 확인하세요. 설정을 공유할 때는 구독 주소, 노드 인증 정보와 제어 비밀번호도 삭제해야 합니다. 문제 해결에는 보통 항목 구조와 민감 정보가 가려진 로그면 충분하며, 전체 개인 설정을 공유할 필요는 없습니다.

실행 상태 / external-controller

외부 컨트롤 패널과 실행 상태 확인

외부 컨트롤 패널은 mihomo의 제어 API를 통해 상태를 확인하고 정책을 전환하거나 관리 작업을 수행합니다. 새로운 프록시 프로토콜도 아니며 일반 트래픽이 들어오는 지점도 아닙니다. external-controller는 관리 인터페이스를, mixed-port는 HTTP와 SOCKS 혼합 프록시 리스닝을 설정합니다. 용도가 다릅니다. 브라우저 프록시를 제어 포트로 지정해도 정상적인 프록시 연결이 되지 않으며, 컨트롤 패널을 혼합 포트에 연결해도 실행 상태를 가져올 수 없습니다.

로컬 루프백 주소부터 사용

로컬에서 사용할 때는 127.0.0.1에 리스닝하도록 설정해 LAN이나 공용 인터넷에 관리 기능이 노출되지 않게 하세요. 아래 비밀번호는 설명용으로 만든 명시적인 가짜 값입니다. 실제로 배포할 때는 로컬의 관리되는 설정에서 별도로 지정해야 합니다. external-ui는 준비된 로컬 정적 패널 디렉터리를 가리킵니다. 경로가 존재하고 파일이 모두 있어야 코어가 해당 페이지를 제공할 수 있습니다. 패널 파일이 없어도 API로 상태를 확인할 수 있으므로 페이지가 없다는 이유만으로 제어 인터페이스가 실행되지 않는다고 판단하지 마세요.

config.yaml · 로컬 관리 인터페이스 설정 예제
mixed-port: 7890
allow-lan: false
external-controller: 127.0.0.1:9090
secret: "your-password"
external-ui: ./dashboard

로컬 패널은 보통 http://127.0.0.1:9090/ui/에서 열고 연결 설정에 제어 주소와 비밀번호를 입력합니다. 패널마다 항목 이름이 다를 수 있으므로 실제 설정 화면에 표시된 항목을 기준으로 입력하세요. 그래픽 클라이언트가 제어 인터페이스를 직접 관리해 파일 설정을 덮어쓸 수도 있습니다. 수동 편집 후에도 포트가 바뀌지 않는다면 다른 코어를 실행해 포트 경쟁을 만들기 전에 유효 설정과 시작 로그부터 확인하세요.

API로 연결, 인증과 화면 문제 구분

아래 요청은 정책 정보를 조회하는 방법만 보여주며 인증 값은 위의 설명용 가짜 값에 해당합니다. 실제 문제를 해결할 때는 진짜 비밀번호를 공개 스크린샷, 공유 명령이나 문의 티켓에 넣지 마세요. 요청은 코어가 실행 중인 기기에서 보내야 합니다. 다른 컴퓨터의 127.0.0.1은 그 컴퓨터 자체를 가리키므로 프록시 서버에 자동으로 연결되지 않습니다.

curl --noproxy '*' \
  -H 'Authorization: Bearer your-password' \
  http://127.0.0.1:9090/proxies

연결이 거부되면 리스닝 주소, 포트 사용 여부와 코어 실행 상태를 확인하세요. 인증 실패 응답을 받으면 비밀번호와 요청 헤더를 확인합니다. API는 정상 응답을 주는데 페이지가 표시되지 않는다면 패널 파일, 브라우저 콘솔과 프런트엔드 연결 설정을 살펴보세요. 이 순서대로 네트워크, 인증과 화면 계층을 구분하면 처음부터 프록시 규칙을 바꾸지 않아도 됩니다. 브라우저에 교차 출처 제한이 표시되면 모든 웹사이트에서 제어 포트에 접근할 수 있도록 허용하기보다 패널과 API의 출처 관계를 확인하세요.

원격 관리는 인증, 전송 암호화와 접근 범위를 별도로 설계해야 합니다. 일반적으로는 로컬 리스닝을 유지하고 통제된 보안 채널을 통해 접속하는 편이 안전합니다. 모든 인터페이스에 리스닝하도록 바꾸고 공용 인터넷 포트를 여는 방식은 피하세요. 리버스 프록시를 사용해야 한다면 WebSocket, 교차 출처 정책과 서버 접근 제어도 함께 검토하세요. 제어 API는 실행 상태를 변경할 수 있으므로 일반적인 읽기 전용 웹페이지와 같은 수준으로 취급해서는 안 됩니다.

패널 상태와 저장된 설정은 다름

패널에서 정책 그룹을 바꾸면 주로 실행 상태가 변경됩니다. 재시작 후에도 선택이 유지되는지는 코어의 저장 설정과 클라이언트 관리 방식에 달려 있습니다. API로 임시 변경한 값도 구독이나 오버라이드를 다시 적용할 때 원래 값으로 돌아갈 수 있습니다. 장기적으로 사용할 규칙과 네트워크 설정은 관리되는 로컬 설정 계층에 저장하세요. 패널은 상태 확인과 검증에 적합하지만 유일한 설정 기록으로 사용해서는 안 됩니다. 변경 후 직접 다시 불러오고 확인해 예상한 동작을 재현할 수 있는지 점검하세요.

연결을 확인할 때는 대상 도메인, 대상 주소, 매칭 규칙, 정책 경로와 오류 로그를 함께 살펴보세요. 관련 연결이 코어에 전혀 들어오지 않으면 시스템 프록시, TUN이나 앱 자체 연결 방식을 확인합니다. 연결은 들어오지만 잘못된 규칙에 매칭되면 규칙 순서를 점검하세요. 규칙은 맞는데 출구가 다르면 정책 그룹의 선택 항목을 확인합니다. 출구도 맞는데 실패한다면 노드 기능, DNS 결과와 대상 서버를 살펴보세요. 이렇게 점검하면 여러 설정을 오가며 무작정 바꾸는 일을 줄일 수 있습니다.

관찰된 결과우선 확인할 항목다음 확인 단계
대상 연결이 없음트래픽 유입과 시스템 라우팅앱이 실제로 사용하는 네트워크 경로 확인
매칭 규칙이 예상과 다름규칙 순서, 규칙 세트와 도메인 정보새 연결을 만들고 규칙 상세 정보 확인
정책 경로가 직접 연결로 이어짐그룹 선택 항목과 중첩 참조검증된 후보 출구 하나를 고정
제어 API는 작동하지만 페이지에 문제 발생패널 파일과 연결 설정페이지 요청과 인증 응답 확인

재현 가능한 설정 검증 완료

마지막으로 고정된 테스트 항목을 준비하세요. 직접 연결되어야 하는 대상 하나, 프록시를 거쳐야 하는 대상 하나, LAN 서비스 하나와 실제로 필요한 UDP 앱을 포함합니다. 설정을 변경할 때마다 이 항목들로 새 연결을 확인하고 유효 설정과 로그를 기록하세요. 재시작, 구독 갱신과 네트워크 전환 뒤에도 같은 결과가 나와야 조정이 끝난 것입니다. 일반적인 연결 문제는 자주 묻는 질문 및 문제 해결에서 확인할 수 있습니다. 가져오기 과정을 다시 점검하려면 빠른 시작 가이드로 돌아가세요. 설명할 수 있는 설정을 저장하는 편이 검증하지 않은 스위치를 더 많이 남기는 것보다 유지 관리에 도움이 됩니다.