Clash 고급 설정
프록시 그룹, DNS, TUN

라우팅과 출구

프록시 그룹 유형과 활용

프록시 그룹은 규칙과 프록시 노드 사이에서 연결을 이어 주는 계층입니다. 규칙은 연결을 어떤 출구로 보낼지 정하고, 프록시 그룹은 해당 출구에서 사용할 노드를 선택합니다. 규칙이 개별 노드를 직접 가리키면 노드 이름이 바뀔 때마다 여러 규칙을 수정해야 합니다. 안정적인 그룹 이름을 지정하면 구독 내용이 갱신되어도 규칙을 그대로 사용할 수 있습니다. 먼저 수동 선택, 자동 선택, 기본 대체 출구 등 필요한 용도를 정한 다음 그룹 후보를 구성하세요. 지역별 그룹을 무작정 늘리는 방식은 피하는 것이 좋습니다.

선택 방식에 따라 그룹 유형 구분하기

select는 사용자가 직접 선택하는 방식으로, 출구를 명확히 제어해야 할 때 적합합니다. url-test는 후보를 주기적으로 측정해 결과에 따라 노드를 선택합니다. 측정 결과는 지정한 주소에 대한 연결 가능성과 응답 상태일 뿐, 모든 사이트의 속도를 보장하지는 않습니다. fallback은 설정된 순서에 따라 사용 가능한 후보를 찾아 주므로 주·대기 구성에 적합합니다. load-balance는 여러 연결을 정책에 따라 분산하며, 단일 다운로드 연결에 여러 노드의 대역폭을 합산하지는 않습니다.

그룹을 중첩하면 설정 중복을 줄일 수 있지만, 단계가 늘어날수록 문제를 찾기 어려워집니다. 업무 그룹이 수동 그룹을 가리키고 수동 그룹이 다시 자동 그룹을 가리킨다면, 패널에 표시된 첫 번째 그룹 이름이 실제 노드와 다를 수 있습니다. 문제를 확인할 때는 선택 체인을 끝까지 펼쳐 최종 출구를 확인하세요. 로그인이나 장시간 세션이 중요한 서비스는 출구를 안정적으로 유지하는 편이 좋습니다. 자동 전환 시 새 연결은 다른 주소를 사용하고 기존 연결은 이전 노드에 남아 잠시 두 출구가 함께 사용될 수 있습니다.

노드 제공기로 구독 변경 분리하기

아래 설정은 로컬 노드 제공기 파일이 이미 있고, 최상위에 proxies 목록이 있다고 가정합니다. 파일 경로는 브라우저 다운로드 폴더가 아니라 코어의 작업 디렉터리를 기준으로 합니다. 자동 그룹은 use로 제공기를 참조하고, 상위 프록시 그룹은 자동 그룹과 내장 직결 출구만 참조합니다. 실제로 사용할 때는 기존 구독의 노드를 이 파일로 내보내거나, 클라이언트가 지원하는 구독 관리 기능으로 제공기를 생성하세요. 일반 웹페이지를 YAML 파일로 저장한 뒤 그대로 참조할 수는 없습니다.

proxy-providers:
  로컬 노드:
    type: file
    path: ./providers/nodes.yaml

proxy-groups:
  - name: 자동 선택
    type: url-test
    use:
      - 로컬 노드
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true
  - name: 프록시
    type: select
    proxies:
      - 자동 선택
      - DIRECT

interval 단위는 초이며, tolerance는 후보 간 응답 차이가 작을 때 잦은 전환을 방지하는 허용 오차입니다. lazy를 사용하면 사용하지 않는 동안 측정을 줄일 수 있습니다. ‘실시간 최적 노드’를 만들겠다며 측정 간격을 지나치게 짧게 설정하지 마세요. 잦은 측정은 요청을 늘리고 모바일 기기의 배터리를 더 소모합니다. 모든 후보의 측정이 실패하면 먼저 해당 노드로 측정 주소에 접속할 수 있는지 확인한 뒤 노드 상태를 점검하세요. 패널 결과만으로 구독 전체가 만료됐다고 단정할 수 없습니다.

필터링, 이름 지정, 검증 순서

filter로 제공기 노드를 필터링할 때는 대개 정규식으로 이름을 검색하며, 지역을 자동으로 판별하지 않습니다. 구독에서 노드 이름이 바뀌거나 기호와 대소문자가 달라지면 필터 결과가 비어 있을 수 있습니다. 먼저 패널에서 제공기에 노드가 있는지 확인하고, 필터 표현식을 검증한 다음, 프록시 그룹에 후보가 표시되는지 확인하세요. 그룹 이름은 규칙에 지정된 대상과 정확히 일치해야 합니다. 전각 공백, 비슷한 문장 부호, 복사 과정에서 들어간 보이지 않는 문자에 특히 주의하세요.

검증할 때는 먼저 사용 가능한 노드를 명확히 선택하고 규칙 모드로 대상 사이트에 접속하세요. 연결 상세 정보에서 일치한 규칙, 프록시 그룹, 최종 노드를 확인해야 합니다. 클라이언트의 전체 스위치만 확인해서는 안 됩니다. 수동 선택은 정상인데 자동 그룹만 작동하지 않는다면 측정 주소, 필터 조건 또는 자동 선택 방식에 문제가 있을 가능성이 큽니다. 모든 그룹이 실패하면 구독과 네트워크 경로부터 다시 확인하세요. 구독 가져오기와 파싱 문제는 구독 업데이트 실패 점검표도 참고해, 가져오기 문제를 라우팅 문제로 오인하지 않도록 하세요.

규칙 관리

규칙 세트 구독 관리

규칙 세트는 도메인, IP 대역 또는 전체 규칙을 주 설정 파일에서 분리해 관리하는 방식입니다. 주 설정에는 참조 관계와 규칙 순서만 남길 수 있습니다. 이를 통해 관리 규모를 줄일 수 있지만, 먼저 일치한 규칙이 출구를 결정한다는 기본 원칙은 바뀌지 않습니다. 규칙 세트에 항목이 많더라도 앞에서 더 포괄적인 규칙이 일치하면 해당 세트는 적용되지 않습니다. 먼저 LAN과 명확한 예외를 배치하고, 업무별 규칙 세트와 지역 규칙을 이어 둔 뒤 마지막에 기본 대체 규칙을 추가하세요. 순서 오류를 중복 규칙으로 보완하지 마세요.

내용의 의미를 먼저 정한 뒤 형식 선택하기

behavior는 규칙 세트에 담긴 내용의 유형을 지정합니다. domain은 도메인 목록, ipcidr은 IP 대역 목록, classical은 규칙 유형이 포함된 항목에 사용할 수 있습니다. 이 값은 파일 확장자와 별개입니다. YAML 파일이라도 노드 구독이나 전체 설정일 수 있습니다. 가져오기 전에 원본을 열어 최상위 구조와 각 항목을 확인하세요. 다운로드 주소의 확장자만으로 호환성을 판단하면 안 됩니다.

형식은 내용의 의미와 맞아야 합니다. YAML 규칙 세트는 보통 최상위에 payload 배열을 사용하고, 텍스트 형식은 한 줄씩 항목을 읽습니다. MRS는 컴파일된 규칙 형식이며, 지원 범위는 코어 구현에 따라 달라집니다. DOMAIN-SUFFIX,example.org처럼 완전한 규칙 항목을 담은 파일은 적절한 classical 의미로 지정해야 하며, 순수 도메인 목록에 넣어서는 안 됩니다. 출처를 바꿀 때는 behavior와 format을 함께 확인하고 URL만 바꾸지 마세요.

로컬에서 검증한 뒤 원격 업데이트 연결하기

먼저 로컬 파일로 설정을 검증하는 것이 좋습니다. 아래 주 설정은 로컬 규칙 세트 두 개를 참조합니다. 업무 도메인은 도메인 목록, 로컬 대역은 IP 대역 목록을 가리킵니다. 두 파일은 실제로 디스크에 있어야 합니다. 프록시 그룹 프록시도 미리 정의해야 합니다. no-resolve는 IP 규칙을 일치시키기 위해 추가 DNS 조회를 하지 않도록 하는 옵션입니다. 모든 상황에서 DNS를 건너뛴다는 뜻은 아니며, 이후 규칙에서 필요한 조회까지 막지는 않습니다.

rule-providers:
  업무 도메인:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/business.yaml
  로컬 대역:
    type: file
    behavior: ipcidr
    format: yaml
    path: ./rules/private.yaml

rules:
  - RULE-SET,로컬 대역,DIRECT,no-resolve
  - RULE-SET,업무 도메인,프록시
  - MATCH,프록시

예를 들어 business.yaml은 아래와 같은 구조로 작성할 수 있습니다. 여기서는 문법 설명을 위한 예약 도메인을 사용하며 실제 트래픽 분기에는 사용하지 않습니다. 필요한 도메인으로 바꾼 뒤 코어가 파일을 불러오는지 확인하고 대상 요청을 점검하세요. 도메인 규칙에는 URL 경로가 포함되지 않습니다. 프로토콜, 포트, 웹페이지 경로까지 포함한 전체 주소를 입력하면 안 됩니다. 같은 도메인에서 경로별로 나누려는 경우에도 단순 도메인 규칙으로는 조건을 표현할 수 없습니다.

payload:
  - "+.example.org"
  - "example.net"

HTTP 제공기로 전환하려면 신뢰할 수 있는 출처의 url, 로컬 캐시용 path, 업데이트 간격인 interval을 설정하세요. 여러 출처의 캐시 경로는 서로 다르게 지정해 같은 파일을 덮어쓰지 않도록 해야 합니다. 업데이트 간격은 규칙이 바뀌는 빈도에 맞추면 되며 노드 측정 간격과 같을 필요는 없습니다. 다운로드에 실패했을 때 기존 캐시를 계속 사용할 수 있는지는 캐시 유효성과 코어 상태에 따라 달라집니다. 새 기기에 설치할 때는 첫 다운로드 경로에 접근할 수 있는지도 별도로 확인하세요.

업데이트 결과와 규칙 일치 결과를 따로 확인하기

제공기에 업데이트 성공이라고 표시되어도 파일을 가져와 파싱했다는 뜻일 뿐, 대상 요청에 규칙이 일치한다는 뜻은 아닙니다. 먼저 규칙 세트 항목을 확인하고, 다음으로 주 규칙 체인에서의 위치를 확인한 뒤, 연결이 도메인 이름과 대상 IP 중 무엇을 사용하는지 점검하세요. 브라우저 캐시, 기존 장기 연결, 앱 내장 DNS로 테스트 결과가 예상과 다를 수 있습니다. 규칙을 바꾼 뒤에는 클라이언트 전체를 반복해서 재시작하기보다 대상 앱 연결을 닫고 새 요청을 보내는 편이 로그를 비교하기 쉽습니다.

여러 출처를 관리한다면 각 규칙 세트의 역할을 명확히 정하고, 이해하기 쉬운 로컬 예외만 남기세요. 같은 업무를 포괄하는 대규모 목록을 여러 개 구독한 뒤 순서에 따라 무엇이 적용될지 추측하지 마세요. 출처를 제거하기 전에는 모든 RULE-SET 참조를 확인하고, 출처를 합칠 때는 사용 권한, 업데이트 안정성, 내용 차이를 살펴보세요. 규칙이 예상대로 일치하지 않는다면 대상 도메인에 임시로 정확한 규칙을 추가해 출구를 확인한 뒤 삭제하세요. 임시 수정이 기존 로직을 계속 가리지 않도록 해야 합니다.

DNS 처리 경로

DNS 설정 최적화

DNS 설정에서는 최소한 세 가지를 고려해야 합니다. 앱의 DNS 요청을 누가 받는지, 대상 도메인을 누가 조회하는지, 프록시 서버 자체의 도메인을 어떻게 IP 주소로 변환하는지입니다. 이 경로를 모두 하나의 업스트림에 맡기면 단순해 보이지만 의존성 순환이 생길 수 있습니다. 예를 들어 프록시 서버를 조회하려면 먼저 프록시에 연결해야 하는데, 프록시 연결에는 서버 이름의 조회가 필요할 수 있습니다. 최적화에 앞서 세 경로를 정리하고 부트스트랩 조회가 독립적으로 완료되는지 확인한 뒤 암호화 업스트림, 도메인별 DNS 지정, 캐시 동작을 검토하세요.

부트스트랩 조회와 일반 DNS 조회 구분하기

default-nameserver는 DNS 업스트림 자체의 도메인 조회 같은 부트스트랩 용도에 주로 사용하며, 보통 명확한 IP 주소를 지정합니다. nameserver는 일반 DNS 업스트림이고, nameserver-policy는 특정 도메인이나 규칙에 조회 경로를 지정합니다. proxy-server-nameserver는 프록시 노드 서버의 도메인을 조회할 때 사용합니다. 각 항목이 클라이언트에서 유지되는지는 생성된 실행 설정으로 확인해야 합니다. 구독 편집기에 입력한 내용만 확인해서는 안 됩니다.

아래는 각 항목의 역할을 이해하기 위한 기본 설정입니다. 업스트림 주소를 명시해 예제에 도메인 부트스트랩 의존성이 생기지 않도록 했습니다. 수신 포트를 로컬의 비표준 포트로 지정해도 시스템 DNS 요청이 자동으로 이곳에 전달되지는 않습니다. 활성화하기 전에 로컬 포트가 사용 중인지 확인하세요. TUN으로 DNS 요청을 가로채려면 다음 장의 설정에 따라 트래픽을 코어 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
    - 1.1.1.1
  nameserver:
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - 223.5.5.5
  nameserver-policy:
    "+.lan":
      - 192.168.1.1

예제의 LAN DNS 서버는 현재 네트워크에서 실제로 사용할 수 있는 라우터나 사내 DNS로 바꿔야 합니다. 내부 도메인을 사용할 일이 없다면 해당 정책을 삭제하세요. 사내 도메인을 공용 DNS에 조회하면 대개 존재하지 않는다는 결과만 받습니다. 반대로 모든 공용 도메인을 내부 레코드만 처리하는 서버에 맡겨도 광범위한 조회 실패가 발생합니다. 특정 도메인에 적합한 DNS인지 판단하려면 조회 결과와 연결 경로를 확인해야 하며, 레코드가 반환되는지만 봐서는 안 됩니다.

fallback은 모든 실패를 해결하는 만능 대체 기능이 아닙니다

fallback과 fallback-filter는 특정 조건에서 어떤 DNS 결과를 사용할지 결정하며, 네트워크 출구용 주·대기 프록시 그룹이 아닙니다. 필터 조건에는 지역 정보, IP 범위, 도메인 등이 들어갈 수 있습니다. 조건이 너무 넓으면 많은 조회가 대체 업스트림으로 넘어가고, 너무 좁으면 적절하지 않은 결과가 계속 사용될 수 있습니다. 선택 조건을 이해하기 어렵다면 먼저 명확한 nameserver-policy로 필요한 도메인만 나누고, fallback이 실제로 필요한지 검토하세요.

respect-rules로 DNS 업스트림 연결이 라우팅 규칙을 따르게 할 때는 프록시 서버 도메인을 별도로 조회해야 합니다. 그렇지 않으면 DNS 조회와 프록시 연결이 서로를 기다리는 순환이 생길 수 있습니다. 암호화 DNS는 조회가 전송되는 방식을 바꿀 뿐, 조회가 프록시를 경유한다고 보장하지 않으며 반환된 IP가 현재 출구에 적합하다는 보장도 없습니다. 대상 도메인이 조회되는데 연결 시간이 초과된다면 결과가 올바른 네트워크에 해당하는지 확인한 뒤 정책과 라우팅을 점검하세요. 업스트림 주소를 무작정 추가하지 마세요.

조회, 응답, 연결 단계별로 문제 확인하기

문제를 확인할 때는 먼저 앱의 DNS 요청이 코어에 들어오는지 확인하고, 다음으로 코어가 예상한 업스트림에 요청하는지 살펴본 뒤, 대상 연결이 어떤 IP 주소를 사용하는지 대조하세요. 시스템 DNS 조회 도구에 로컬 수신 주소와 포트를 지정할 수 있습니다. 포트를 직접 지정할 수 없는 도구라면 시스템 DNS 서버에 질의한 결과를 코어의 결과로 잘못 기록하지 마세요. 내부 도메인, 공용 도메인, 프록시 노드 도메인을 각각 하나씩 테스트하면 웹페이지 하나를 반복해서 새로고침하는 것보다 단절 지점을 찾기 쉽습니다.

DNS를 변경한 뒤에는 시스템, 브라우저, 코어가 각각 캐시를 보유하고 있을 수 있습니다. 먼저 대상 앱의 기존 연결을 닫고, 필요하면 클라이언트에서 지원하는 방식으로 DNS 캐시를 지운 다음 새 요청을 보내세요. IPv6 경로를 사용할 수 없는 네트워크에서 IPv6 주소가 반환되면 DNS 결과와 실제 라우팅 가능성을 구분해야 합니다. DNS 스위치 하나만 바꿔 모든 앱에 적용되지 않을 수도 있습니다. IPv6 사용 여부는 시스템 라우팅, 코어 설정, 노드 지원을 함께 확인하세요. 특정 사이트 하나가 열린다는 이유만으로 전체가 정상이라고 판단하지 마세요.

DNS 처리와 규칙 분기는 서로 선후 관계가 있지만 같은 설정은 아닙니다. 도메인 규칙은 도메인 정보가 유지되면 바로 일치할 수 있지만, IP 규칙은 DNS 조회를 유발할 수 있습니다. no-resolve는 이 조회를 제한합니다. 요청의 도메인, 반환 IP, 일치 규칙, 출구를 함께 기록해야 설정이 어떻게 작동하는지 알 수 있습니다. 세부 항목 조합과 DNS 하이재킹 범위는 DNS 옵션과 하이재킹 설정 안내를 참고하세요.

트래픽 처리

TUN과 Fake-IP

시스템 프록시는 앱이 운영체제의 프록시 설정을 따르는 방식이고, TUN은 가상 네트워크 인터페이스를 통해 코어로 라우팅된 트래픽을 받습니다. 두 방식은 트래픽이 클라이언트에 들어오는 경로를 정할 뿐, 트래픽이 반드시 프록시를 거치게 하지는 않습니다. TUN을 켜도 규칙 모드에서 LAN과 특정 업무를 직결로 보낼 수 있습니다. 전역 프록시를 켰다고 시스템의 모든 트래픽이 처리되는 것도 아닙니다. 처리 범위를 확인하려면 스위치 하나만 보지 말고 대상 앱의 연결 기록과 라우팅 테이블을 살펴보세요.

권한과 라우팅 조건부터 확인하기

데스크톱 클라이언트는 인터페이스와 라우트를 만들 때 서비스 구성 요소, 관리자 권한 또는 시스템 권한 승인이 필요할 수 있습니다. 모바일 플랫폼에서는 시스템 VPN 인터페이스가 트래픽 처리 기능을 제공하며, 설정 방식도 데스크톱과 다릅니다. 처음 켜기 전에 기존 시스템 프록시와 DNS 설정을 기록하고, 라우트를 처리할 수 있는 다른 VPN은 일시 중지한 뒤 클라이언트의 TUN 스위치를 조작하세요. 다른 코어 인스턴스를 수동으로 동시에 실행하면 포트, 가상 네트워크 어댑터, 기본 라우트가 서로 충돌할 수 있습니다.

아래는 Mihomo에서 흔히 사용하는 일부 설정입니다. auto-route는 관련 라우트를 자동으로 설정하고, auto-detect-interface는 출구 인터페이스를 식별하며, dns-hijack은 지정한 기존 DNS 요청을 코어가 처리하도록 전달합니다. 이 설정은 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

stack은 프로토콜 스택 구현을 선택하는 항목이며 모든 시스템에 맞는 고정된 최적값은 없습니다. 호환성 문제가 생기면 한 번에 이 항목만 변경하고 같은 서비스로 다시 테스트하세요. 연결이 성립하는지, 전송이 계속되는지, UDP가 정상인지 기록하면 됩니다. 스택, MTU, DNS, 노드를 동시에 바꾸면 문제가 해결되어도 어떤 설정이 영향을 줬는지 알 수 없습니다. 인터페이스 자동 감지가 제대로 되지 않으면 유선과 무선 네트워크를 전환한 뒤 특히 시스템의 실제 출구 인터페이스를 확인하세요.

Fake-IP는 도메인 매핑용 가상 주소이며 실제 서버 주소가 아닙니다

Fake-IP 모드에서는 앱에 예약 주소 대역의 가상 IP를 반환하고, 코어는 해당 IP와 도메인의 매핑을 기록합니다. 이후 연결이 코어에 들어오면 이를 바탕으로 규칙을 적용하고 출구를 선택합니다. 앱에 표시된 가상 IP를 매핑에 관여하지 않은 다른 기기에서 그대로 사용할 수는 없습니다. 이 주소가 원격 서버의 실제 주소라는 뜻도 아닙니다. 문제를 확인할 때는 매핑된 도메인과 최종 출구를 함께 확인해야 하며, 시스템 도구에 표시된 대상 IP만으로 규칙 분기가 정확한지 판단해서는 안 됩니다.

일부 LAN 기기 검색, 장치 관리 또는 실제 DNS 주소에 의존하는 서비스는 Fake-IP에서 제외해야 할 수 있습니다. 명확한 도메인을 지정해 fake-ip-filter에 추가하세요. 제외된 도메인은 실제 IP로 조회되며, 이후 규칙에서 도메인 정보가 유지되는지는 앱 동작과 스니핑 여부에 따라 달라집니다. 기기 하나의 문제를 해결하려고 모든 도메인을 제외하지 말고, 먼저 실제 요청 도메인을 확인한 뒤 최소 범위로 테스트하세요. 주소 풀이 기존 VPN이나 테스트 네트워크와 충돌한다면 코어 지원 범위에 맞춰 조정하고 매핑을 다시 생성해야 합니다.

되돌릴 수 있는 절차로 트래픽 처리 확인하기

검증할 때는 정상 작동이 확인된 규칙과 노드를 유지한 채 TUN만 켜세요. 기존에 시스템 프록시를 따르지 않던 앱을 선택해 새 연결을 만들고 연결 목록에 나타나는지 확인합니다. 연결은 표시되지만 접속할 수 없다면 트래픽 처리는 대체로 완료된 상태이므로 규칙, DNS, 출구를 점검하세요. 기록이 전혀 없다면 앱이 현재 네트워크 경로를 우회하는지, 인터페이스 라우트가 설정됐는지, 다른 네트워크 도구가 먼저 연결을 가로채는지 확인해야 합니다.

기존 DNS 하이재킹만으로 모든 암호화 DNS를 자동 차단할 수는 없습니다. 앱 자체 DoH나 다른 암호화 프로토콜은 일반 암호화 연결처럼 보이므로 대상 포트가 일반적인 DNS 포트가 아니라는 이유만으로 로컬 DNS 모듈에 전달되지 않습니다. 도메인 정보가 누락되면 앱의 보안 DNS 설정을 먼저 확인하고 다음 장의 스니핑 기능도 함께 검토하세요. dns-hijack을 켰다는 이유만으로 모든 조회 경로가 통합됐다고 볼 수는 없습니다.

네트워크 연결이 끊기면 먼저 TUN을 끄고 라우트와 DNS가 복구되는지 확인한 다음 충돌 원인을 처리하세요. 클라이언트를 종료한 뒤에도 문제가 계속되면 남아 있는 시스템 프록시, 다른 VPN 상태, 시스템 네트워크 설정을 확인하세요. 새 라우트를 계속 추가하지 마세요. 원격 서버를 관리할 때는 트래픽 처리 후 접속이 끊기는 상황에 대비해 별도의 복구 경로를 마련해야 합니다. 전체 작동 원리와 시스템 프록시 비교는 TUN 트래픽 처리 안내를 참고하세요. 첫 설치는 빠른 시작 가이드를 따라 진행하면 됩니다.

도메인 정보 보완

도메인 스니핑

도메인 규칙을 적용하려면 대상 도메인을 알아야 하지만, 코어에 들어오는 연결에는 대상 IP만 포함되는 경우가 있습니다. 앱이 캐시된 주소로 직접 연결하거나 자체적으로 DNS를 처리해 코어 DNS를 우회할 수 있습니다. 스니핑은 지원되는 프로토콜의 핸드셰이크나 요청 정보에서 도메인을 복원해 규칙 적용 또는 대상 처리에 활용합니다. 연결 메타데이터를 보완하는 기능이지 모든 암호화 콘텐츠를 복호화하지는 않으며, 적절한 DNS 경로나 체계적인 규칙 설계를 대신할 수도 없습니다.

인식 범위와 정보 출처

HTTP 스니핑은 보통 요청의 호스트 정보를 사용하고, TLS 스니핑은 핸드셰이크의 서버 이름을 사용합니다. QUIC은 해당 트래픽에 대한 코어 지원이 필요합니다. 지원하지 않는 프로토콜이거나 핸드셰이크 정보가 보이지 않는 경우, 또는 이름을 숨기는 방식을 사용하면 도메인을 확인하지 못할 수 있습니다. 패널에 도메인이 표시되지 않는다고 반드시 클라이언트 오류는 아닙니다. 트래픽 자체에 확인 가능한 정보가 없을 수도 있습니다. 이때는 IP 규칙과 명확한 기본 대체 규칙을 유지하고 스니핑 포트 범위를 무작정 넓히지 마세요.

아래 설정은 일반적인 웹 포트를 시작점으로 삼고 TLS와 QUIC 범위를 포함합니다. 가능한 기능을 설정하는 예시일 뿐 모든 연결에서 도메인을 확인할 수 있다는 뜻은 아닙니다. parse-pure-ip는 대상이 IP 주소뿐인 연결도 처리하도록 시도하며, force-dns-mapping은 DNS 매핑 상황에서의 스니핑 동작과 관련됩니다. 처음 활성화할 때는 스니핑 설정만 추가하고 DNS와 규칙은 함께 바꾸지 마세요. 그래야 활성화 전후의 도메인과 일치 결과를 비교할 수 있습니다.

sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true
  override-destination: false
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
      override-destination: false
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443

포트 범위는 실제 업무에 맞춰 설정하세요. 모든 포트를 모든 프로토콜로 분석하면 불필요한 처리가 늘고 대상이 아닌 프로토콜까지 복잡한 판정 과정에 들어갈 수 있습니다. 자체 서비스가 비표준 포트를 사용한다면 실제 프로토콜을 확인한 다음 해당 항목에만 포트를 추가하세요. QUIC은 보통 UDP를 사용하며, 프록시 가능 여부는 노드 프로토콜, 서버, 네트워크 경로의 지원에도 달려 있습니다. QUIC 스니핑을 켰다고 UDP 출구가 준비된 것은 아닙니다.

규칙 매칭과 연결 대상 변경 구분하기

override-destination은 스니핑한 도메인으로 연결 대상을 덮어쓸지 결정합니다. 규칙 판단에 도메인을 사용하는 것과 도메인으로 다시 연결하는 것은 서로 다른 동작입니다. 일부 서비스는 특정 IP, 내부 DNS 결과 또는 IP 고정에 의존하므로 대상을 바꾸면 기존 연결의 의미가 달라질 수 있습니다. 예제에서는 영향을 최소화하도록 대상 덮어쓰기를 끄고 도메인 복원 여부를 확인합니다. 필요한 경우에만 프로토콜이나 업무별로 조정하고, 현재 코어가 전역 값과 프로토콜별 값의 상속을 어떻게 처리하는지 점검하세요.

하나의 대상 IP에 여러 도메인이 연결될 수 있고, 하나의 도메인이 여러 IP를 가리킬 수도 있습니다. IP가 바뀌었다는 사실만으로 스니핑이 정확한지 판단할 수는 없습니다. 원래 대상, 스니핑된 도메인, 일치 규칙, 최종 출구를 함께 확인하세요. 앱이 요청을 다른 중간 프록시에 넘기면 스니핑 정보가 중간 연결만 나타낼 수도 있습니다. 모든 연결 목록의 이름을 사용자가 접속한 전체 사이트로 해석하지 말고 대상 앱에 가까운 트래픽 진입점에서 분석하세요.

범위는 제한하고 호환성 예외는 유지하기

활성화 후 일부 서비스만 문제가 생긴다면 먼저 대상 덮어쓰기를 끄고 다시 테스트한 뒤, 호환되지 않는 도메인을 skip-domain으로 제외하는 방안을 검토하세요. 특정 도메인을 반드시 처리해야 하는 경우에만 force-domain을 고려하고, 일반적인 허용 목록처럼 사용하지 마세요. 예외 항목에는 업무상 이유를 적어 두어 나중에 출처를 알 수 없는 도메인 목록이 되지 않도록 하세요. 사내 시스템은 사설 인증서, 비표준 핸드셰이크, 고정 IP 접속 방식에 특히 주의해야 하며 공용 사이트와 같은 방식으로 처리해서는 안 됩니다.

검증은 새 연결로 해야 합니다. 브라우저의 연결 풀, HTTP/2 재사용, 앱의 장기 연결 때문에 설정을 바꿔도 새 핸드셰이크가 바로 나타나지 않을 수 있습니다. 먼저 대상 앱의 관련 연결을 닫고 반복 테스트할 수 있는 페이지를 연 다음 로그에 예상 도메인이 표시되는지 확인하세요. 비교 기준을 잃지 않도록 시스템 네트워크 설정 전체를 한꺼번에 초기화하지 마세요. 디버그 로그를 저장해야 한다면 해당 문제와 관련된 시간대만 보관하고 방문 도메인, 노드 주소 등 개인정보를 가리세요.

스니핑 후 다른 규칙이 일치했다고 해서 결과가 더 정확해진 것은 아닙니다. 새 규칙이 실제 업무 목적에 맞는지 확인하세요. 특히 범위가 넓은 도메인 접미사 규칙은 기존의 정확한 IP 예외보다 먼저 적용될 수 있습니다. 대상 도메인에 명확한 규칙을 임시로 추가해 확인한 뒤 결과를 장기 규칙 설계에 반영하세요. 스니핑을 끄고 DNS 조정만으로 안정적인 도메인 정보를 얻을 수 있다면 구조가 단순하고 의존성이 적은 경로를 우선하세요. 모든 문제를 새 기능 스위치로 보완하지 않는 것이 좋습니다.

계속 인식되지 않는 트래픽은 IP 주소, 포트 또는 신뢰할 수 있는 프로세스 정보에 따라 처리해야 합니다. 프로세스 규칙 사용 가능 여부는 플랫폼, 권한, 코어 기능에 따라 달라지며 모바일과 데스크톱도 같지 않습니다. 불확실한 트래픽은 출구를 설명할 수 있도록 명확한 기본 대체 그룹으로 보내세요. 용어가 익숙하지 않다면 용어 가이드에서 DNS, 규칙, 네트워크 스택 개념을 확인한 뒤 연결 상세 정보를 하나씩 대조하세요. 도메인이 표시되지 않는다는 이유만으로 프록시가 작동하지 않는다고 단정하지 마세요.

설정 생성과 업데이트

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

구독 설정은 업데이트될 때마다 다시 생성되므로 구독 파일에서 포트, DNS, 규칙을 직접 수정하면 다음 업데이트에서 사라질 수 있습니다. 로컬 오버라이드는 사용자가 장기간 관리할 설정을 원격 구독 내용과 분리하는 기능입니다. 노드는 구독에서 갱신하고 개인 규칙, 수신 범위, 필요한 DNS 정책은 로컬 계층에 보관하세요. 작업 전에 클라이언트가 필드 병합, 규칙 앞에 추가, 뒤에 추가, 스크립트 처리 중 무엇을 지원하는지 확인해야 합니다. 모두 단순한 텍스트 추가로 볼 수는 없습니다.

설정 소유권과 처리 순서부터 확인하기

설정은 보통 구독 다운로드, 파싱, 클라이언트 변환, 오버라이드, 코어 실행 단계를 거칩니다. 편집기에는 항목이 있지만 실행 설정에 없다면 YAML 문법 오류가 아니라 후속 처리 단계에서 덮어쓴 것일 수 있습니다. Clash Plus와 다른 호환 클라이언트는 메뉴 이름이 다를 수 있으므로 로컬 설정, 오버라이드, 실행 설정 보기 기능을 실제 화면에서 찾아보세요. 다른 클라이언트의 메뉴 경로만 보고 현재 클라이언트에 코어 기능이 없다고 판단하지 마세요.

매핑 필드는 키 단위로 병합될 수 있지만 배열 필드는 전체가 교체되거나 별도의 앞뒤 추가 기능으로 처리될 수 있습니다. rules, proxy-groups, nameserver는 모두 목록을 포함하므로 항목을 추가하면 원격의 나머지 항목이 자동으로 보존된다고 가정해서는 안 됩니다. 오버라이드를 처음 사용할 때는 영향이 작고 결과를 확인하기 쉬운 변경 하나부터 적용하세요. 실행 결과로 병합 방식을 확인한 뒤 다른 설정을 옮기면 됩니다.

여러 구독은 출처별로 분리한 뒤 공통 출구로 연결하기

여러 구독의 노드를 하나의 목록에 무작정 넣지 마세요. 출처마다 같은 이름의 노드, 프록시 그룹, 제공기 식별자가 있을 수 있으며 덮어쓰기 순서는 클라이언트 구현에 따라 달라집니다. 더 안전한 방법은 각 출처를 별도의 제공기로 관리하고 출처별 그룹을 만든 뒤 공통 출구 그룹에서 참조하는 것입니다. 아래 설정은 로컬 파일 두 개가 모두 유효한 노드 제공기 파일이라고 가정합니다. 전체 구독은 클라이언트가 지원하는 변환 과정을 먼저 거쳐야 하며, 파일 이름만 바꿔 노드 목록으로 가장할 수는 없습니다.

proxy-providers:
  출처 A:
    type: file
    path: ./providers/source-a.yaml
  출처 B:
    type: file
    path: ./providers/source-b.yaml

proxy-groups:
  - name: 그룹 A
    type: select
    use:
      - 출처 A
  - name: 그룹 B
    type: select
    use:
      - 출처 B
  - name: 프록시
    type: select
    proxies:
      - 그룹 A
      - 그룹 B

이 구조는 규칙과 구독 출처를 분리하지만, 같은 이름의 노드와 그룹이 충돌하는 문제는 여전히 처리해야 합니다. 클라이언트가 출처별 노드 이름에 접두사를 붙이는 기능을 지원한다면 짧고 안정적이며 알아보기 쉬운 접두사를 사용하세요. 스크립트로 이름을 변경한다면 이름으로 참조하거나 필터링하는 모든 표현식도 함께 확인해야 합니다. 출처를 삭제하기 전에 공통 출구에서 참조를 제거한 다음 제공기를 삭제하세요. 업데이트 후 후보가 비어 있으면 설정을 다시 만들기 전에 출처가 로드됐는지와 필터 조건을 확인하세요.

원격 구독에는 노드뿐 아니라 규칙, DNS, 컨트롤 인터페이스 설정도 포함될 수 있습니다. 병합할 때는 어떤 항목을 실행 설정에 반영할지 명확히 정하세요. 전체 설정 두 개를 그대로 이어 붙인 뒤 코어가 우선순위를 알아서 판단할 것이라고 기대해서는 안 됩니다. 특히 external-controller, allow-lan, 수신 주소는 로컬 정책으로 통합 관리해야 합니다. 구독 변환 서비스를 사용한다면 링크의 기밀성과 변환 서비스가 접근할 수 있는 내용을 평가하고, 가능하면 직접 통제할 수 있는 처리 경로를 선택하세요.

한 번에 한 계층만 변경하고 복구용 파일을 보관하기

원본 구독, 로컬 오버라이드, 최종 실행 설정을 구분할 수 있도록 각각 보관하고 같은 파일을 계속 덮어쓰지 마세요. 먼저 최종 설정의 문법을 확인한 뒤 클라이언트에 불러오고 연결을 테스트하세요. Mihomo를 명령줄에서 독립 실행한다면 아래 명령으로 설정을 검사할 수 있습니다. 이 검사는 문법과 설정 간 관계를 확인할 뿐 구독 서버, 규칙 다운로드, 모든 서비스 연결이 정상임을 보장하지 않습니다. 실행 후에도 로그를 계속 확인해야 합니다.

mihomo -t -f ./config.yaml

오버라이드 변경 후 클라이언트가 갑자기 종료되거나 시작되지 않으면 최근 로컬 변경부터 되돌리고, 정상 작동이 확인된 설정을 복구한 뒤 클라이언트 자체 문제인지 판단하세요. 오류 메시지의 줄 번호는 원격 원본이 아니라 생성된 파일의 위치일 수 있습니다. 실행에 사용된 파일을 열어 들여쓰기, 중복 키, 잘못된 참조, 목록 교체 여부를 확인하세요. 시작 오류를 더 자세히 해결하려면 클라이언트 시작 오류 해결을 참고하세요.

백업 파일에는 구독 주소, 노드 비밀번호, 컨트롤 인증 정보가 포함될 수 있으므로 공개 문의에 그대로 첨부해서는 안 됩니다. 설정을 공유하기 전에 민감한 내용을 삭제하고 문제를 재현하는 데 필요한 최소 구조만 남긴 뒤, 교육용 가짜 값으로 대체하세요. 다른 기기로 옮길 때는 YAML뿐 아니라 로컬 제공기, 규칙 세트, 컨트롤 패널 디렉터리, 상대 경로도 확인해야 합니다. 설정 내용이 같아도 작업 디렉터리가 다르면 파일을 찾지 못하거나 오래된 캐시를 읽을 수 있습니다.

실행 상태 확인과 제어

외부 컨트롤러

외부 컨트롤 인터페이스를 사용하면 패널에서 프록시 그룹, 연결, 규칙, 로그를 읽고 정책 전환 등의 작업을 실행할 수 있습니다. 패널은 코어를 제어하는 진입점이지 별도의 프록시 출구가 아니며, 코어 대신 TUN 라우트를 생성하지도 않습니다. 화면에 연결할 수 없어도 브라우저 인터넷은 정상일 수 있고, 반대로 패널에 접속된다고 프록시 연결이 정상인 것은 아닙니다. 페이지 리소스 로드 여부, 컨트롤 인터페이스 연결 여부, 인증 성공 여부, 실제 서비스 연결 성공 여부를 각각 확인하세요.

기본값은 로컬 수신으로 유지하기

로컬에서 사용할 때는 컨트롤 인터페이스를 루프백 주소에 바인딩하고 별도의 인증 정보를 설정하세요. 아래의 your-password는 설명용 가짜 값입니다. 실제 환경에서는 직접 생성한 길고 무작위적인 문자열로 바꾸고 구독이나 다른 서비스에서 쓰는 값과 공유하지 마세요. external-ui는 로컬 패널 리소스 디렉터리를 가리키며, 해당 디렉터리에 패널 시작 파일이 있어야 합니다. 경로는 코어 작업 디렉터리를 기준으로 합니다. 패널 파일을 준비하지 않았다면 먼저 API만 테스트한 뒤 화면을 설정할 수 있습니다.

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

루프백 수신은 같은 기기에서만 접근할 수 있습니다. 휴대전화 브라우저에서 컴퓨터의 루프백 주소를 열면 컴퓨터가 아니라 휴대전화에 연결됩니다. 여러 기기에서 관리해야 한다면 출처, 사용자 신원, 접근 범위를 제한할 수 있는 통제된 사설 연결을 우선 사용하세요. 편의를 위해 컨트롤 인터페이스를 인터넷에 직접 공개하지 마세요. 프록시 포트의 allow-lan과 컨트롤 인터페이스 수신 설정은 별개입니다. LAN 프록시를 켠다고 컨트롤 패널이 올바르게 설정되거나 보호되는 것은 아닙니다.

API부터 확인한 다음 패널 연결 문제 살펴보기

먼저 코어가 실행 중인 기기에서 컨트롤 API에 요청을 보내세요. 아래 명령은 현재 설정 개요를 읽습니다. 터미널에 입력하는 인증 정보도 예시일 뿐입니다. 인증 오류가 나면 현재 실행 설정의 인증 정보를 확인하세요. 연결이 거부되면 수신 주소, 포트, 프로세스 상태를 살펴보고, 요청 시간이 초과되면 라우트와 방화벽도 확인해야 합니다. 인터페이스에 접속할 수 없을 때 패널을 반복해서 다시 설치하지 마세요. 패널 파일로는 실행 중이지 않은 컨트롤 서비스를 복구할 수 없습니다.

curl --fail \
  -H "Authorization: Bearer your-password" \
  http://127.0.0.1:9090/configs

API는 정상인데 브라우저 패널만 실패한다면 패널에 입력한 백엔드 주소, 프로토콜, 포트를 확인하세요. HTTPS 페이지에서 HTTP 백엔드에 연결하면 브라우저 보안 정책이 혼합 콘텐츠를 차단할 수 있습니다. 출처가 다른 페이지에서 접속하면 출처 제한도 적용될 수 있습니다. 로컬 패널과 제한된 컨트롤 인터페이스가 명확하고 일관된 경로를 사용하도록 설정하세요. 다른 출처에서 접속해야 할 때는 코어가 지원하는 범위에서 필요한 출처만 지정하고, 모든 출처 허용을 일반적인 해결책으로 사용하지 마세요.

패널은 브라우저 저장소에 백엔드 주소와 인증 정보를 저장할 수 있습니다. 브라우저를 바꾸면 다시 설정해야 할 수 있고, 다른 사람의 기기를 사용한 뒤에는 저장된 정보를 삭제하세요. 스크린샷을 찍을 때 연결 도메인, 구독 출처, 노드 주소, 인증 정보를 가리세요. 디버그 정보를 복사할 때는 오류와 관련된 항목만 남기세요. 로그를 공유하기 전에는 파일 이름뿐 아니라 본문도 확인해야 합니다. 연결 상세 정보는 기본 설정 파일보다 구체적인 접속 기록을 드러낼 수 있습니다.

연결 상세 정보로 검증 과정 마무리하기

정책 페이지에서는 선택 경로를, 연결 페이지에서는 일치한 규칙과 최종 출구를, 로그 페이지에서는 DNS 조회 실패, 제공기 업데이트, 라우팅 오류를 확인할 수 있습니다. 규칙을 조정할 때는 테스트 요청의 시간과 대상을 기록한 다음 해당 연결을 대조하세요. 계속 갱신되는 목록에서 다른 프로세스의 연결을 잘못 선택하지 않도록 해야 합니다. 변경 전에 이미 생성된 일부 연결은 정책을 바꿔도 즉시 새 출구로 라우팅되지 않습니다. 필요하다면 해당 연결만 닫고 새 요청을 보내 다른 서비스에 미치는 영향을 줄이세요.

패널의 자동 측정과 실제 서비스 테스트는 구분해서 확인하세요. 측정이 한 번 성공했다는 것은 해당 시점에 측정 요청이 완료됐다는 뜻일 뿐입니다. 노드에서 대상 서비스에 접속할 수 있는지는 프로토콜, 포트, UDP 지원, 서비스 측 제한, 출구 경로에 따라 달라집니다. 특정 사이트에 문제가 생기면 자동 전환으로 변수가 생기지 않도록 수동 노드를 잠시 고정하고 DNS 조회, 일치 규칙, 연결 오류를 확인하세요. 잦은 측정으로 구체적인 장애 기록을 대신하거나 한 번의 결과만으로 전체 규칙 순서를 바꾸지 마세요.

컨트롤 인터페이스에서 바꾼 설정은 설정 파일에서 바꾼 값과 유지 방식이 다를 수 있습니다. 일부 패널 조작은 메모리 상태만 바꾸고, 일부 선택은 코어나 클라이언트에 저장될 수 있습니다. 다시 불러온 뒤 유지되는지는 실제 구현에 따라 다릅니다. 장기간 사용할 설정은 로컬 설정이나 클라이언트 설정에 저장하고 다시 불러온 뒤 확인하세요. 임시 진단 설정은 변경 내용을 기록하고 바로 복구해야 합니다. 다음 문제 해결을 파일과 달라진 실행 상태에서 시작하지 않도록 주의하세요.

고급 설정을 조정한 뒤에는 순서대로 확인하세요. 설정이 파싱되는지, 제공기가 정상적으로 로드되는지, DNS 경로를 설명할 수 있는지, 대상 연결이 코어에 들어오는지, 예상한 규칙이 일치하는지, 최종 출구가 목적에 맞는지 점검합니다. 한 번에 주요 요소 하나만 바꾸고 정상 설정으로 복구할 수 있도록 파일을 보관하세요. 일반 설치와 첫 연결은 빠른 시작 가이드를 참고하세요. 플랫폼이나 클라이언트를 바꾸려면 다운로드 페이지에서 선택하고, 설정 개념은 용어 가이드에서 확인할 수 있습니다.