mihomo 고급 설정 가이드

01 / 설정 기준선

설정 출처, 실행 파일 및 검증 순서

클라이언트의 설정 페이지에서 현재 활성화된 설정을 찾은 다음 실행 설정 또는 코어 설정 메뉴를 확인하세요. 구독에서 다운로드한 파일, 로컬에서 편집한 파일, mihomo에 최종 전달되는 파일은 서로 다를 수 있습니다. 시스템 프록시, 포트, DNS 또는 TUN 스위치도 설정 생성 과정에 관여할 수 있습니다. 문제를 살펴볼 때는 먼저 현재 설정 이름, 설정 디렉터리, 실제 수신 대기 포트를 기록하세요. 구독 편집기의 필드 한 줄만 보고 코어가 그 값을 사용한다고 단정할 수 없습니다. 적용 여부는 실행 로그와 최종 생성 파일부터 확인해야 합니다.

되돌릴 수 있는 설정 기준선 만들기

먼저 현재 인터넷에 연결되는 설정을 내보내고 로컬 오버라이드 내용은 별도로 저장하세요. 백업에는 구독 주소, 서버 암호, 컨트롤 인터페이스 암호가 포함될 수 있으므로 로컬의 접근 제한된 디렉터리에 보관하고, 화면을 공유할 때는 해당 정보를 가리세요. 한 번에 모듈 하나만 바꾸는 것이 좋습니다. 예를 들어 정책 그룹을 먼저 바꾸고, DNS를 조정한 다음 TUN을 켜세요. 그러면 문제가 발생했을 때 직전 변경 사항과 정확히 연결할 수 있습니다. 코어를 직접 실행한다면 실행 명령과 작업 디렉터리도 기록하세요. 상대 경로는 설정 디렉터리에 영향을 받으므로 다른 위치에서 실행하면 규칙 파일이나 패널 리소스를 찾지 못할 수 있습니다.

YAML을 읽을 때는 먼저 들여쓰기 단계와 중복 키를 확인하세요. 들여쓰기에는 공백을 사용하고 같은 단계에서는 일관된 간격을 유지하며, 목록 항목 앞에는 하이픈을 붙입니다. 필드 이름에 들어가는 하이픈과 목록 표시용 하이픈은 역할이 다릅니다. 특수 문자가 포함된 문자열은 따옴표로 감쌀 수 있으며, 특히 암호, 쿼리 매개변수가 포함된 주소, 콜론이 들어간 텍스트는 주의하세요. 파일 끝에 두 번째 dns 또는 rules 최상위 키를 덧붙여 오버라이드를 흉내 내지 마세요. 파서에 따라 오류가 나거나 한쪽만 남을 수 있어 편집할 때 예상한 결과와 달라질 수 있습니다.

# 기존에 작동하는 설정에 반영하고 원래 출구와 규칙은 유지
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

문법을 확인한 뒤 실제 연결을 살펴보세요

독립 실행형 코어를 사용한다면 아래 명령으로 파일을 검사할 수 있습니다. 경로는 실제 로컬 위치에 맞게 바꾸세요. 검사로 파싱할 수 없는 YAML, 일부 필드 오류, 참조 문제를 찾을 수 있지만 원격 서버 접속 가능 여부나 시스템 트래픽이 해당 프로세스를 거치는지는 확인할 수 없습니다. 그래픽 클라이언트에 설정 검사, 다시 불러오기 또는 로그 메뉴가 있다면 우선 그 기능을 사용하세요. 검사에 실패하면 로그에서 의미 있는 첫 오류부터 확인하세요. 뒤따르는 오류는 같은 들여쓰기 문제에서 비롯됐을 수 있으므로 무작정 하나씩 수정하면 정상적인 부분까지 망가질 수 있습니다.

mihomo -t -f ./config.yaml

문법 검사를 통과하면 설정을 다시 불러온 뒤 테스트 앱의 기존 연결을 종료하고 새 요청을 보내세요. 연결 페이지에서 대상 도메인, 일치한 규칙, 정책 경로, 출구 이름을 확인합니다. 페이지 새로고침만 하면 브라우저가 기존 연결을 재사용해 새 규칙이 적용되지 않은 것처럼 보일 수 있습니다. 로컬 진입 경로와 원격 출구를 구분해야 한다면 로컬 프록시 포트를 명시해 테스트하세요. 아래 명령은 HTTP 프록시 진입 경로만 확인하므로 TUN 라우팅 검증을 대신하지 않습니다. 포트는 실행 설정과 일치해야 하며, 대상 사이트는 현재 점검할 공개 사이트로 바꿔도 됩니다.

curl -I --proxy http://127.0.0.1:7890 https://example.com

클라이언트에 따라 설정 메뉴 위치도 달라집니다. 새로 설치한다면 클라이언트 다운로드 페이지에서 우선 추천하는 Clash Plus를 선택하고 시스템 칩에 맞는 패키지를 받으세요. 이미 Clash Verge Rev 또는 FlClash를 사용 중이라면 현재 클라이언트를 계속 사용해도 됩니다. 실제로 실행되는 코어와 지원 필드를 확인하는 것이 중요합니다. 설정 구조를 항목별로 읽으려면 config.yaml 구조 해설을 참고하세요. 포트 사용 중, 권한 거부, 시작 실패가 발생하면 고급 설정을 계속하기 전에 도움말 센터에서 기본 문제를 해결해 환경 문제를 규칙 문제로 오인하지 않도록 하세요.

02 / 출구 선택

정책 그룹 유형과 자동 최적 선택

프록시 페이지에서 규칙이 마지막으로 어떤 정책 그룹을 가리키는지 확인한 다음 해당 그룹의 구성원을 펼쳐 보세요. 정책 그룹은 출구 선택 계층이지 트래픽 식별 계층이 아닙니다. 규칙이 연결을 어느 그룹으로 보낼지 결정하고, 그룹은 사용할 출구를 선택합니다. 그룹 내부의 선택지를 바꿀 때 전체 규칙을 수정할 필요는 없는 경우가 많으므로, 업무 목적과 구독의 실제 구성을 분리하는 데 유용합니다. 예를 들어 업무 규칙이 모두 ‘업무 출구’를 가리키게 하고, 이 그룹에 수동 선택과 자동 선택 경로를 함께 넣을 수 있습니다. 그룹 이름은 원하는 대로 지정할 수 있지만 공백, 대소문자, 문장 부호까지 모든 참조 이름이 정확히 일치해야 합니다.

수동 선택, 최적 선택, 장애 조치를 구분하세요

select는 출구를 직접 지정하거나 상위 메뉴에서 여러 하위 그룹을 전환할 때 적합합니다. url-test는 탐지 결과를 바탕으로 지연 시간이 낮은 사용 가능한 구성원을 선택합니다. fallback은 구성원 순서를 중시하며 일반적으로 앞에 있는 사용 가능한 구성원을 우선 사용합니다. 어떤 방식도 대상 서비스의 실제 체감 품질이 탐지 결과와 같다고 보장하지는 않습니다. 테스트 주소는 해당 주소에 접속하는 조건만 보여 줍니다. 동영상, 다운로드, 기업 시스템은 서로 다른 네트워크 경로를 사용할 수 있습니다. 문제를 진단할 때는 먼저 사용 가능 여부를 확인한 구성원 하나를 고정한 뒤 업무 연결을 관찰하세요. 자동 전환을 켜 두면 테스트 조건이 계속 달라질 수 있습니다.

load-balance는 새 연결을 정책에 따라 분산하는 기능이지, 여러 출구의 대역폭을 하나의 연결에 합치는 기능이 아닙니다. 로그인 세션, 결제 페이지, 출구 일관성을 요구하는 서비스는 출구가 자주 바뀌면 재인증이 발생할 수 있으므로 트래픽 특성이 분명한 경우에 더 적합합니다. 안정적인 접속이 필요한 업무에는 별도의 select 그룹을 만들어 출구를 고정할 수 있습니다. 그룹 구성이 복잡할수록 연결 경로를 읽는 비용도 커집니다. 일반적인 용도라면 수동 그룹 하나와 최적 선택 그룹 하나로 시작하고 실제 사용 상황에 따라 점차 나누세요.

로컬 프록시 컬렉션으로 2단계 선택 구성

아래 예제는 설정 디렉터리에 providers/nodes.yaml이 있고, 파일에 유효한 proxies 목록이 있다는 전제에서 작성되었습니다. 내용은 기존 구독이나 로컬 설정에서 가져와야 합니다. 이 예제는 원격 계정을 만들거나 구독을 대신하지 않습니다. 먼저 프록시 컬렉션을 불러올 수 있는지 확인한 다음 기존 설정에 두 그룹을 추가하세요. use는 프록시 컬렉션을 참조하고 proxies는 개별 출구나 다른 그룹을 참조합니다. 둘 다 구독 URL을 입력하는 위치가 아닙니다. 탐지 주소는 안정적으로 접속할 수 있고 현재 네트워크에 적합한 주소를 사용하세요.

proxy-providers:
  local-nodes:
    type: file
    path: ./providers/nodes.yaml

proxy-groups:
  - name: 자동 선택
    type: url-test
    use:
      - local-nodes
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
  - name: 업무 출구
    type: select
    proxies:
      - 자동 선택
      - DIRECT
    use:
      - local-nodes

interval은 탐지 간격이며 단위는 초입니다. tolerance는 전환 허용 오차이며 단위는 밀리초로, 결과가 비슷할 때 잦은 전환을 줄이는 데 사용됩니다. 간격을 지나치게 짧게 설정하면 탐지 요청과 기기 깨우기 빈도가 늘어나고 모바일 네트워크에서 추가 데이터가 소모됩니다. 같은 프록시 컬렉션에 상태 확인을 켜고 여러 정책 그룹도 각각 테스트한다면 중복 탐지가 있는지 점검하세요. 탐지 계층마다 목적이 다르므로 모든 검사를 동시에 켜기보다 설명하고 관찰할 수 있는 구성을 우선 유지하세요.

검증할 때는 규칙에서 테스트할 도메인 하나를 ‘업무 출구’로 보내고, ‘자동 선택’과 특정 구성원을 각각 선택한 뒤 새 연결을 만들어 정책 경로를 확인하세요. 상위 그룹이 간접적으로 자기 자신을 참조하면 순환이 발생합니다. 구독 업데이트 후 그룹에 삭제된 구성원만 고정해 두었다면 그룹이 비거나 참조 오류가 날 수도 있습니다. 컬렉션을 필터링할 때 필터 필드를 사용할 수 있지만, 먼저 프록시 페이지에서 결과에 실제 구성원이 있는지 확인하세요. 자동 최적 선택은 후보 출구 간 선택 문제를 해결할 뿐입니다. DNS, 인증, 대상 서비스 제한 문제는 별도로 진단해야 합니다.

03 / 규칙 관리

규칙셋 구독 관리와 매칭 우선순위

실행 설정의 rules 섹션을 열고 사용자 지정 규칙이 구독 규칙보다 앞에 있는지 뒤에 있는지 확인하세요. mihomo는 일반적으로 위에서 아래 순서로 규칙을 검사하고, 경로를 결정할 수 있는 규칙을 만나면 해당 결과를 적용합니다. 따라서 구체적인 업무 예외는 앞에, 범위가 넓은 지역 규칙과 최종 기본 규칙은 뒤에 두세요. 규칙 목록을 규칙셋으로 분리하면 내용 관리와 라우팅 의도를 나눌 수 있습니다. 규칙셋은 도메인이나 네트워크 대역을 나열하고, 주 설정은 해당 항목을 직접 연결, 프록시 또는 차단 중 어디로 보낼지 결정합니다.

규칙 내용과 behavior부터 맞춰 보세요

rule-providers는 규칙 출처를 정의하고, RULE-SET은 주 규칙 목록에서 이를 호출합니다. behavior: domain은 도메인 목록, ipcidr은 주소 대역 목록, classical은 유형이 지정된 기존 규칙 항목을 대상으로 합니다. 파일 형식과 동작 방식은 서로 다른 기준입니다. YAML, 텍스트, 바이너리는 파일 저장 방식을 설명하고, behavior는 각 항목을 해석하는 방식을 설명합니다. 규칙 구독을 받으면 먼저 형식 설명을 읽으세요. 확장자만 보고 내용을 판단하거나 완성된 클라이언트 설정을 규칙셋으로 불러오면 안 됩니다.

원격 파일을 바로 연결하는 것보다 로컬 파일로 최소 테스트를 먼저 하면 문제를 찾기 쉽습니다. 첫 번째 조각은 설정 디렉터리 아래의 rules/local-direct.yaml에 저장하고, 두 번째 조각은 주 설정에 반영합니다. 예제에서는 classical 동작을 사용하며 각 규칙에 유형과 일치 내용을 적고 최종 정책은 규칙 파일에 넣지 않습니다. 주 설정의 RULE-SET이 컬렉션 전체를 DIRECT로 보냅니다. 기본 규칙에는 앞 장에서 만든 ‘업무 출구’를 사용합니다. 다른 그룹 이름을 쓴다면 참조도 함께 바꾸세요.

# rules/local-direct.yaml
payload:
  - DOMAIN-SUFFIX,apple.com
  - DOMAIN-SUFFIX,example.com
  - IP-CIDR,192.168.0.0/16,no-resolve

# 주 설정에 반영
rule-providers:
  local-direct:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-direct.yaml

rules:
  - RULE-SET,local-direct,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,업무 출구

원격 업데이트와 로컬 예외를 분리하세요

로컬 규칙이 일치하는지 확인한 다음 지속적으로 관리할 컬렉션을 type: http로 바꾸고 신뢰할 수 있는 출처의 실제 규칙 URL, 캐시 경로, 업데이트 간격을 지정하세요. interval의 단위는 초이며, 최신 상태를 위해 지나치게 작은 값으로 설정할 필요는 없습니다. 규칙셋마다 서로 다른 로컬 캐시 경로를 사용해 파일이 덮어쓰이지 않도록 하세요. 처음 실행할 때 캐시가 없다면 원격 규칙을 정상적으로 가져올 수 있어야 합니다. 캐시가 이미 있는 경우의 동작은 파일 상태와 코어 처리 방식에 따라 달라질 수 있으므로 다운로드 로그와 규칙셋 로드 결과를 모두 확인하세요.

규칙셋 다운로드에도 네트워크 경로가 필요합니다. 다운로드 주소 접속에 프록시가 필요한데 프록시 경로가 아직 불러오지 않은 같은 규칙셋에 의존하면 시작 단계에서 순환 의존이 생길 수 있습니다. 클라이언트의 리소스 다운로드 정책에서 이미 사용 가능한 출구를 지정하거나 규칙 출처 도메인에 명확하고 작동하는 접속 경로를 설정하세요. 규칙 페이지에 컬렉션 이름이 표시되는지만 보지 말고 로드 로그, 업데이트 시각, 실제 일치 여부도 확인해야 합니다. 다운로드가 성공해도 항목 수가 이상하거나 동작 유형이 맞지 않거나 내용이 비어 있으면 라우팅 결과가 예상과 달라집니다.

no-resolve는 IP 유형 규칙에서 자주 사용되며, 해당 규칙에 일치시키기 위해 도메인을 IP로 능동적으로 해석하지 않는다는 뜻입니다. 연결 전체의 DNS를 끈다거나 이후 주소 정보가 사라진다는 뜻은 아닙니다. 이미 IP인 요청은 여전히 주소 규칙에 일치할 수 있습니다. 도메인 규칙은 동작을 이해하기 쉽고, IP 규칙은 네트워크 대역이나 도메인이 없는 연결에 적합합니다. 범위가 넓은 IP 규칙을 업무 도메인 규칙보다 앞에 두면 트래픽이 너무 일찍 직접 연결이나 프록시로 분류될 수 있으므로 연결 페이지에서 실제 일치한 규칙 유형과 순서를 확인하세요.

규칙을 더 세분화하려면 사용자 지정 규칙 문법과 우선순위 및 국내외 트래픽 분기 설정을 참고하세요. 구독 업데이트 후 예외가 사라진다면 원격 생성 파일을 반복해서 편집하지 말고 오버라이드 병합 위치를 조정하세요. 설정을 공유하기 전에는 규칙 출처가 신뢰할 만한지, 민감한 트래픽이 예상하지 못한 출구로 향하지 않는지 확인하세요. 규칙을 정상적으로 파싱할 수 있다는 사실만으로 정책이 사용 목적에 맞는 것은 아닙니다.

04 / 도메인 조회

DNS 설정 최적화와 조회 경로 분리

DNS 설정을 열기 전에 로그를 확인해 문제가 도메인 조회, 프록시 서버 연결, 대상 사이트 응답 중 어디에서 발생했는지 구분하세요. DNS는 도메인을 이후에 사용할 정보로 변환하지만 브라우저, 운영체제, 클라이언트, 원격 프록시가 모두 조회에 관여할 수 있습니다. 명령줄에서는 열리는데 브라우저에서 열리지 않는다면 브라우저 자체의 암호화 DNS를 사용하고 있을 수 있습니다. 프록시 서버 도메인 조회가 실패해도 대상 웹사이트의 DNS에 문제가 있다는 뜻은 아닙니다. ‘무엇을 조회하는지’와 ‘요청이 어디로 가는지’를 먼저 구분한 뒤 바꿀 필드를 결정하세요.

초기 조회와 일반 질의를 구분하세요

nameserver는 기본 업스트림을 지정하고, default-nameserver는 DNS 업스트림 자체의 도메인 조회 등 초기 연결에 필요한 조회에 사용됩니다. proxy-server-nameserver는 프록시 서버 도메인을 조회합니다. 도메인 이름을 사용하는 암호화 DNS 주소에 연결하려면 코어가 먼저 해당 서버의 IP를 알아야 합니다. 초기 조회가 아직 준비되지 않은 프록시에 의존하면 시작 단계에서 멈출 수 있습니다. 아래는 역할을 이해하기 위한 최소 구성 예시입니다. 공개 DNS 서비스를 사용하지만 모든 네트워크 환경에서 동일하게 접속된다는 뜻은 아닙니다.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - 223.5.5.5
  fake-ip-filter:
    - "*.lan"
    - "localhost"

수신 주소를 루프백 인터페이스로 설정하면 로컬 프로세스나 TUN 가로채기 경로에서 접근할 수 있고, 로컬 네트워크에 노출되는 위험도 줄어듭니다. 포트 1053은 선택 가능한 예시일 뿐이며 실행 설정과 관련 리디렉션 설정이 일치해야 합니다. listen을 설정해도 macOS의 모든 DNS 질의가 자동으로 코어에 전달되지는 않습니다. 시스템 DNS, TUN의 DNS 가로채기, 앱 자체 조회를 각각 확인해야 합니다. 다른 기기에서 로컬 DNS 서비스를 사용하게 하려면 수신 주소, 방화벽, 접근 범위, 반환 경로도 점검해야 하며 모든 인터페이스에서 수신하도록 바꾸는 것만으로는 충분하지 않습니다.

서비스를 무작정 늘리기보다 도메인별로 업스트림을 지정하세요

nameserver-policy를 사용하면 특정 도메인이나 일치하는 도메인 그룹에 업스트림을 지정할 수 있어 사내 도메인, 홈 네트워크 도메인, 특정 조회 출처가 필요한 업무에 적합합니다. 우선 도메인 하나에 정책을 설정해 확인한 뒤 범위를 넓히세요. 업스트림을 한꺼번에 많이 추가하면 요청 병렬 처리와 경로의 불확실성, 문제 해결 비용이 늘어날 수 있습니다. 규칙셋을 DNS 일치 조건으로 사용할 때는 현재 코어가 해당 문법을 지원하고 규칙셋이 이미 로드되었는지도 확인하세요. 라우팅 규칙의 정책 이름과 DNS 업스트림 설정은 문법이 다르므로 한쪽 문자열을 그대로 다른 쪽에 옮길 수 없습니다.

respect-rules를 켜면 업스트림 DNS 연결에 해당 라우팅 규칙이 적용되므로 프록시 서버 도메인을 별도로 조회하는 설정이 특히 중요합니다. 사용 가능한 출구가 준비되기도 전에 조회가 프록시에 의존하면 순환이 발생할 수 있습니다. 먼저 프록시 서버 도메인을 명확하게 접속 가능한 조회 서비스로 해석할 수 있게 한 뒤 일반 웹사이트 조회를 설정하세요. 설정에 fallback과 필터 조건이 함께 있다면 실제 판정 방식을 확인하세요. 이는 단순히 ‘첫 번째 서버가 실패하면 두 번째 서버를 사용한다’는 기능이 아니므로 전통적인 예비 DNS 서버처럼 동작한다고 가정해서는 안 됩니다.

조회 결과를 검증할 때는 실제 IP 모드와 Fake-IP 모드를 구분하세요. Fake-IP에서 매핑된 대역의 주소가 보이는 것은 일반적인 동작이며, 주소가 웹사이트의 공인 IP처럼 보이지 않는다고 조회 오류로 판단해서는 안 됩니다. DNS를 변경한 뒤에는 연결을 새로 만들고 필요한 경우 관련 캐시를 정리하세요. 모든 캐시를 한꺼번에 지우면 진단 단서가 사라지고 일시적인 연결 문제를 일으킬 수 있습니다. DNS 서비스는 현재 네트워크, 개인정보 보호 요구, 접속 대상에 맞춰 선택하면 되며 공개 설정을 무조건 그대로 따라 할 필요는 없습니다. 로컬 내부 네트워크 서비스를 사용한다면 조정 중 업무 네트워크가 끊기지 않도록 기존 DNS 설정을 되돌릴 수 있게 보관하세요.

05 / 시스템 연결

TUN, 시스템 프록시, Fake-IP 함께 사용하기

시스템 프록시를 켠 뒤 필요한 앱이 시스템 프록시를 따르는지 먼저 확인하세요. 일부 앱이나 명령줄 도구만 연결되지 않는다면 그때 TUN을 고려합니다. 시스템 프록시는 앱에 HTTP, HTTPS, SOCKS 접속 정보를 제공하며 실제 사용 여부는 앱 구현에 달려 있습니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 더 광범위한 IP 트래픽을 처리합니다. 둘은 반드시 함께 켜야 하는 가속 스위치가 아닙니다. 이미 검증된 연결 방식 하나를 유지하고 대상 앱의 트래픽이 코어로 들어오는지 확인한 다음 필요에 따라 처리 범위를 넓히세요.

TUN을 켜기 전에 시스템 권한 확인

macOS 클라이언트에서 TUN 또는 서비스 모드 메뉴를 찾아 안내에 따라 보조 서비스를 설치하고 시스템 권한을 허용한 다음 실행 로그를 다시 확인하세요. 클라이언트마다 버튼 이름이 다르고 권한 절차도 시스템 버전에 따라 달라질 수 있으므로 현재 화면의 안내를 따르세요. 권한 문제를 해결하려고 시스템 보안 기능을 끄지 마세요. 코어를 독립 실행할 때도 충분한 네트워크 권한이 필요합니다. 활성화에 실패하면 권한, 가상 인터페이스 생성, 라우팅 설정부터 확인하세요. 원격 프록시 사용 가능 여부는 그 다음 단계이므로 두 종류의 문제를 따로 검증해야 합니다.

# 기존에 작동하는 설정에 반영하고 이전 장의 유효한 DNS 설정을 계속 사용
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

auto-route는 가로채기 라우트를 자동으로 설정하고, auto-detect-interface는 출구 인터페이스를 감지하며, stack은 TUN에서 사용할 네트워크 스택을 정합니다. 예제의 mixed는 선택지 중 하나입니다. 호환성 문제가 있다면 MTU, DNS, 규칙, 시스템 라우트를 동시에 바꾸지 말고 코어 지원 여부에 따라 다른 스택을 비교하세요. dns-hijack은 해당 경로로 들어오는 일반 DNS 질의를 가로채지만, 앱이 암호화 DNS 서비스로 직접 보내는 HTTPS 요청은 목적지 포트가 네트워크 요청이라는 이유만으로 일반 DNS 질의로 바뀌지 않습니다.

Fake-IP 주소로 웹사이트에 연결할 수 있는 이유

Fake-IP는 도메인에 매핑 주소를 할당하고 연결이 들어오면 매핑을 통해 도메인을 복원해 규칙을 적용합니다. 따라서 코어는 대상의 실제 주소를 미리 알아내지 않고도 도메인 정보를 유지할 수 있어 도메인 기반 분기에 유리하며, 일부 로컬 조회 경로가 결과에 미치는 영향도 줄일 수 있습니다. 그렇다고 매핑 대역이 실제 웹사이트가 있는 네트워크가 되는 것은 아니며 최종적으로 웹사이트에 연결할 필요가 없어지는 것도 아닙니다. 프록시 출구와 직접 연결 출구에서 원격 연결을 설정하는 방식은 프로토콜, DNS 설정, 출구 동작에 따라 달라집니다.

fake-ip-filter는 지정된 도메인이 가상 매핑을 사용하지 않도록 합니다. 로컬 네트워크 서비스 검색이나 주소 결과에 민감한 프로그램처럼 실제 조회 결과가 필요한 경우에 적합합니다. 문제가 생긴 도메인만 예외로 지정하고 기능이 복구되는지 테스트하세요. 증상을 숨기려고 모든 도메인을 필터 목록에 넣지 마세요. Fake-IP 대역을 변경한다면 기존 네트워크, 기업 VPN, 다른 가상 인터페이스와 충돌하는지 확인하세요. 이전 매핑을 캐시한 앱은 계속 예전 주소로 접근할 수 있으므로 변경 후 연결과 DNS 캐시가 얼마나 유지되는지도 고려해야 합니다.

TUN을 검증할 때 --proxy를 지정한 명령만 실행해서는 안 됩니다. 프록시를 명시한 요청은 검증하려는 시스템 트래픽 가로채기 경로를 우회할 수 있습니다. 프록시를 따로 설정하지 않는 앱을 선택해 새 연결을 만들고 클라이언트 연결 페이지에서 해당 연결을 찾으세요. 그런 다음 로컬 네트워크 장치, 절전 후 복귀, 네트워크 전환도 테스트합니다. Wi-Fi에서 유선 네트워크로 바꾼 뒤 로그가 이전 인터페이스를 계속 가리킨다면 인터페이스 감지와 라우트 복구를 먼저 확인하세요. 여러 프록시 클라이언트에서 동시에 TUN을 켜면 라우트 충돌, 중복 DNS 가로채기, 루프가 생길 수 있으므로 테스트 중에는 필요한 한 가지 방식만 유지하세요.

활성화 후 전체 기기에서 인터넷이 끊기면 역순으로 되돌리세요. 먼저 TUN을 끄고 시스템 프록시 상태를 확인한 뒤 원래 DNS와 네트워크 연결을 복구합니다. 설정을 전부 지우지 마세요. 원인을 찾을 수 있는 문제를 재설치 작업으로 바꾸게 됩니다. 화면에 스위치가 켜져 있어도 실제로 가상 인터페이스, 라우트, DNS가 모두 정상이라는 뜻은 아닙니다. 권한 로그, 인터페이스 상태, 대상 연결 기록을 함께 봐야 문제가 연결 계층인지 출구 계층인지 판단할 수 있습니다. 기본 복구 절차는 도움말 센터에서도 확인할 수 있습니다.

06 / 연결 식별

도메인 스니핑의 용도와 한계, 문제 해결

연결 페이지를 열고 실제로 도메인 정보가 없는 연결을 찾은 다음 스니핑이 필요한지 판단하세요. 일부 앱은 IP를 직접 전달하거나 별도의 조회 경로를 사용해 코어가 연결을 받을 때 원래 도메인 정보가 없을 수 있습니다. 도메인 스니핑은 일부 프로토콜 핸드셰이크나 평문 요청 정보에서 도메인을 추출해 규칙 매칭에 필요한 정보를 보충합니다. 암호화된 모든 내용을 읽는 범용 도구도 아니고, 켜기만 하면 모든 IP 트래픽이 도메인으로 바뀌는 기능도 아닙니다. 대상에 식별 가능한 정보가 포함되는지, 프로토콜이 지원되는지, 핸드셰이크를 확인할 수 있는지에 따라 결과가 달라집니다.

먼저 제한적으로 켜고, 대상 주소를 덮어쓸지는 나중에 결정하세요

HTTP 요청에는 호스트 정보가 포함될 수 있고 TLS 핸드셰이크에는 서버 이름이 포함될 수 있으며, QUIC의 일부 핸드셰이크에서도 식별 단서를 얻을 수 있습니다. 최신 암호화 핸드셰이크 보호, 비표준 프로토콜, IP만 사용하는 서비스, 읽을 수 없는 핸드셰이크는 식별을 제한합니다. 설정의 sniff는 식별을 시도할 프로토콜과 포트 범위를 지정할 뿐, 해당 포트의 모든 트래픽이 그 프로토콜을 사용한다는 뜻은 아닙니다. 아래 설정은 기존 연결 대상을 유지하고 식별 조건만 추가하므로 스니핑이 규칙 판정에 도움이 되는지 관찰하기에 적합합니다.

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

parse-pure-ip는 도메인 정보가 없는 순수 IP 연결에 대한 식별을 시도하고, force-dns-mapping은 DNS 매핑 상황의 처리와 관련됩니다. 대상 주소를 덮어쓸지는 override-destination으로 제어합니다. 이는 ‘규칙에 사용할 도메인을 알아내는 것’과는 다른 수준의 결정입니다. 원래 목적지 주소를 유지하면 앱이 선택한 주소가 교체되는 차이를 줄일 수 있습니다. 실제로 덮어써야 한다면 대상 업무별로 검증하세요. 특정 CDN 주소, 전용 게이트웨이, 고정 접속 경로에 의존하는 앱은 도메인을 올바르게 식별해도 목적지를 바꾸는 것이 적절하지 않을 수 있습니다.

같은 연결에서 규칙 적용 근거 비교

문제를 진단할 때는 먼저 정책 그룹 구성원을 고정한 뒤 구체적인 업무 하나를 선택하세요. 스니핑을 끈 상태에서 새 연결을 만들고 대상, 규칙 유형, 출구 경로를 기록한 다음 스니핑을 켜고 같은 작업을 반복합니다. 서로 다른 웹페이지나 이미 재사용된 연결을 직접 비교하지 마세요. 로그에 도메인이 나타나지 않더라도 필드가 적용되지 않았다고 단정할 수 없습니다. 트래픽이 코어를 거치지 않거나 포트가 식별 범위에 없거나 프로토콜에서 추출할 정보가 없을 수 있습니다. 먼저 연결 진입 경로를 확인하고, 다음으로 프로토콜 식별을 살핀 뒤, 마지막에 규칙을 조정하세요. 순서를 바꾸면 문제가 더 복잡해집니다.

스니핑 결과는 DNS 조회 결과를 대신하지 않습니다. 연결에서 확인한 서버 이름은 진입 도메인일 뿐일 수 있고, 앱이 이후 접근하는 콘텐츠 도메인은 다를 수 있습니다. 하나의 IP에서 여러 도메인을 서비스할 수도 있습니다. 주소 역조회만으로 도메인을 추측해도 앱의 원래 의도를 안정적으로 복원할 수 없습니다. 규칙에는 한 번 포착한 호스트 이름을 서비스 전체의 영구 기준으로 삼기보다 검증 가능한 업무 도메인 목록을 사용하세요. 로그인, 미디어, 업데이트 서비스를 처리할 때는 리디렉션 도메인과 리소스 도메인이 서로 다른 출구를 사용하는지도 고려해야 합니다.

활성화 후 앱의 핸드셰이크가 실패하거나 연결 대기 시간이 늘거나 잘못된 진입점에 접속한다면 먼저 목적지 주소 덮어쓰기를 끄고 해당 업무의 스니핑 범위를 좁히세요. 현재 코어가 지원하는 스킵 도메인 등의 필드로 개별 예외를 설정할 수 있지만 구체적인 문법은 사용 중인 코어 문서에 맞춰야 합니다. 한 업무에서 문제가 생겼다고 전역 DNS, TUN, 스니핑을 한꺼번에 초기화하지 마세요. 비교 기준을 잃게 됩니다. 기존에 작동하는 경로를 유지하면서 식별 동작 하나만 바꾸고 로그에서 실제 연결에 영향을 줬는지 확인하는 것이 더 효과적입니다.

문제 해결 자료를 공유할 때는 필요한 대상 도메인, 규칙 유형, 오류 정보만 캡처하고 연결 기록 전체를 올리지 마세요. 도메인과 접속 시간에도 업무 및 개인 정보가 포함될 수 있습니다. 규칙 작성 방식을 더 확인해야 한다면 규칙셋 장으로 돌아가 도메인 규칙이 앞선 IP 규칙에 가로막히지 않았는지 점검하세요. 연결이 목록에 전혀 나타나지 않는다면 TUN 및 시스템 프록시 장에서 앱의 네트워크 경로를 확인하세요. 스니핑은 명확한 식별 정보 부족을 해결하기 위한 기능이지 모든 연결 문제에 기본으로 켜는 스위치가 아닙니다.

07 / 설정 유지 관리

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

설정 관리 페이지에서 클라이언트가 제공하는 오버라이드, 확장 또는 병합 메뉴를 찾은 다음 사용자 지정 내용을 어디에 둘지 결정하세요. 원격 구독은 계속 업데이트되는 데이터 출처이므로 다운로드한 파일을 직접 편집하면 다음 새로고침 때 변경 사항이 사라질 수 있습니다. 구독은 프록시 데이터를 제공하고 로컬 오버라이드는 포트, DNS, 업무 규칙, 정책 구성을 유지하도록 역할을 나누는 편이 안전합니다. 이러한 기능의 이름과 실행 순서는 클라이언트마다 다르므로 오버라이드 파일을 복사하는 것만으로 모든 클라이언트가 같은 방식으로 처리한다고 가정해서는 안 됩니다.

객체 병합과 목록 병합부터 구분하세요

설정의 매핑 객체와 목록은 서로 다른 방식으로 처리해야 합니다. 매핑 객체는 필드별로 재귀 병합될 수도 있고 전체가 교체될 수도 있습니다. 목록은 앞에 추가, 뒤에 추가, 이어 붙이기, 전체 교체 방식으로 처리될 수 있습니다. 규칙 목록의 순서는 매칭 우선순위를 결정하므로 ‘추가됨’이 곧 ‘예외가 적용됨’을 뜻하지는 않습니다. 사용자 지정 직접 연결 규칙이 MATCH 뒤에 있으면 트래픽을 처리할 기회가 없습니다. DNS 하위 필드도 클라이언트 설정에 의해 다시 덮어써질 수 있으므로 오버라이드 편집기에 저장된 내용만 보지 말고 최종 실행 파일을 확인해야 합니다.

먼저 로컬 예외를 하나만 추가해 실행 설정에서 위치를 확인한 뒤 전체 규칙을 옮기세요. 아래는 원하는 최종 결과를 이해하기 위한 규칙 조각이며 모든 클라이언트에서 사용할 수 있는 오버라이드 파일 형식은 아닙니다. 앞 장에서 만든 ‘업무 출구’를 사용하고 로컬 주소와 사설 네트워크 대역을 범위가 넓은 규칙보다 앞에 둔다는 전제입니다. 해당 주소를 직접 연결해도 되는지는 실제 네트워크 요구 사항에 따라 판단하세요. 기업 네트워크의 전용 대역, 다른 VPN이 할당한 주소, 컨테이너 네트워크도 하나씩 점검해 지나치게 넓은 범위로 실제 라우팅 요구를 가리지 않도록 하세요.

# 목표 실행 설정의 규칙 순서
rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,업무 출구

여러 구독을 별도의 프록시 컬렉션으로 나누기

여러 구독을 병합할 때는 출처에서 완성된 Clash 설정을 제공하는지, 아니면 프록시 컬렉션으로 바로 읽을 수 있는 내용을 제공하는지 먼저 확인하세요. 완성된 설정에는 DNS, 규칙 및 기타 최상위 필드가 포함되므로 프록시 목록만 기대하는 위치에 그대로 넣을 수 없습니다. 사용할 수 있는 각 출처를 별도의 proxy-providers로 구성한 다음 로컬 정책 그룹에서 참조하면 유지 관리가 쉬워집니다. 출처마다 서로 다른 컬렉션 키와 캐시 경로를 사용하고 업무 규칙은 안정적인 로컬 그룹 이름만 참조하세요. 그러면 상위 출처의 서버 목록이 바뀌어도 주 규칙을 자주 수정할 필요가 없습니다.

병합 시 프록시 이름 충돌은 흔히 놓치는 위험 요소입니다. 서로 다른 두 출처가 같은 이름을 사용하면서 실제 서버는 다를 수 있습니다. proxies를 수동으로 합치면 이름이 중복되거나 참조가 모호해질 수 있습니다. 우선 출처를 분리한 채 각 컬렉션의 구성원을 확인하고, 지원되는 이름 처리 방식이 필요한지 판단하세요. 노드 이름을 임의로 바꾼 뒤 기존 정책 그룹 참조를 그대로 두거나 여러 파일의 같은 최상위 키를 단순히 이어 붙이지 마세요. 스크립트 변환이 불가피하다면 현재 클라이언트가 명확히 지원하는 인터페이스를 사용하고 원본 파일을 되돌릴 수 있도록 보관하세요.

수정이 끝나면 구독을 직접 한 번 업데이트하고 사용자 지정 내용이 유지되는지 확인하세요. 며칠 뒤 규칙이 작동하지 않는 것을 발견하는 것보다 문제를 쉽게 찾을 수 있습니다. 내보낸 실행 설정에 유지 관리 로직이 모두 포함되는 것도 아닙니다. 병합 순서, 스크립트, 외부 컬렉션 출처가 빠지고 병합된 결과만 들어 있을 수 있습니다. 따라서 백업에는 설정 데이터와 생성 방식이 모두 포함되어야 하지만 민감한 구독 주소는 안전하게 보관해야 합니다. 다른 사람에게 설정을 보여 줄 때는 계정 정보를 제거한 최소 재현 파일을 사용하고 개인 백업 전체를 공유하지 마세요.

클라이언트에서 필요한 병합 기능을 제공하지 않는다면 검토하기 어려운 구독 변환 체인을 자동화에 도입하기보다 안정적인 주 설정과 로컬 파일 컬렉션을 사용해 보세요. 변환이 꼭 필요하다면 구독 정보가 제3자 서비스에 노출될 수 있다는 점을 이해해야 합니다. URL, 클립보드, 로컬 파일 가져오기 방식의 차이는 구독 형식과 가져오기 방법에서 확인하세요. 이 페이지에서는 가져온 뒤 장기적으로 유지하는 방법만 다룹니다. 유지 관리 방식을 평가할 때는 설정 파일이 복잡한지보다 업데이트를 반복할 수 있는지, 예외가 보존되는지, 최종 결과를 설명할 수 있는지를 확인하세요.

08 / 로컬 제어 인터페이스

외부 컨트롤러와 설정 변경 검증 과정

외부 컨트롤러가 필요하다면 먼저 실행 설정에서 external-controller의 수신 주소를 확인하고 패널이 어디에서 실행되는지 살펴보세요. 제어 인터페이스는 연결 조회, 정책 전환, 코어 실행 상태 관리에 사용되며 앱이 웹사이트에 접속할 때 사용하는 프록시 포트가 아닙니다. 패널을 7890 같은 mixed-port에 연결해도 일반적으로 제어 인터페이스 응답을 받을 수 없습니다. 로컬에서 사용할 때는 루프백 주소로 수신하는 방식을 우선하고 기존 클라이언트의 관리 기능을 유지하세요. 그래픽 클라이언트가 같은 인터페이스를 사용할 수 있으므로 포트를 함부로 바꾸면 UI와 코어의 연결이 끊길 수 있습니다.

로컬 인터페이스와 정적 패널 리소스를 별도로 설정

external-ui는 호환되는 패널의 페이지 리소스가 들어 있는 로컬 정적 파일 디렉터리를 지정합니다. 디렉터리 필드가 있다고 해서 코어가 필요한 프런트엔드 파일까지 자동으로 갖추는 것은 아닙니다. 아래 예제는 로컬 수신 주소와 로컬 디렉터리의 관계만 보여 줍니다. 반영 전에 포트가 비어 있는지, 클라이언트에서 제어 인터페이스를 수정할 수 있는지 확인하세요. 암호가 필요하다면 클라이언트에서 지원하는 안전한 로컬 설정 방식으로 충분히 강한 별도 암호를 설정하고 패널에도 같은 값을 입력하세요. 실제 암호를 공개 예제, 화면 캡처, 동기화되어 공유될 수 있는 설정 링크에 기록하지 마세요.

# 로컬 전용 설정. 패널 정적 파일을 먼저 해당 디렉터리에 넣으세요
external-controller: 127.0.0.1:9090
external-ui: ./ui

패널에는 보통 인터페이스 주소, 포트, 인증 정보를 입력해야 합니다. 인터페이스 연결이 거부되면 먼저 수신 상태를 확인하고, 인증 오류가 나면 암호를 확인하세요. 명령줄에서는 접속되는데 브라우저에서만 실패할 때 교차 출처, 보안 컨텍스트, 혼합 콘텐츠 제한을 점검하면 됩니다. 루프백 주소는 언제나 접속하는 기기 자신을 가리킵니다. 휴대전화 브라우저에 127.0.0.1을 입력해도 컴퓨터에 연결되지 않습니다. 여러 기기에서 제어해야 한다면 통제된 보안 접속 방식을 사용하고 수신 범위를 넓힐 때의 위험을 이해하세요. 관리 포트를 곧바로 공용 인터넷에 노출해서는 안 됩니다.

쓰기 작업보다 읽기 전용 점검을 먼저 하세요

패널에 처음 연결하면 현재 모드, 정책 그룹, 연결 목록을 확인해 의도한 코어 인스턴스에 연결되었는지 살펴보세요. 컴퓨터에서 클라이언트 두 개를 동시에 실행하면 패널이 이전 프로세스에 연결될 수 있습니다. 그러면 정책을 바꿔도 현재 트래픽에는 영향이 없는 것처럼 보일 수 있습니다. 수신 포트, 현재 설정, 새 연결 하나를 대조하면 이런 오판을 줄일 수 있습니다. 아래 명령은 로컬 버전 인터페이스에 읽기 전용 요청을 보내는 예시이며 응답으로 인터페이스 접속 여부를 확인할 수 있습니다. 인증을 켰다면 실제 로컬 설정에 맞는 인증 헤더를 보내야 합니다. 인증 없이 요청해 거부된 것을 코어 손상으로 오해하지 마세요.

curl --fail --silent --show-error \
  http://127.0.0.1:9090/version

패널에서 그룹 구성원을 바꾼 뒤에는 변경 사항을 지속적으로 저장해야 하는지 확인하세요. 실행 상태, 클라이언트 설정, 원격 구독은 서로 다른 계층이며 재시작 후 선택이 복원되는지는 코어 설정과 클라이언트 관리 방식에 따라 다릅니다. 인터페이스에 한 번 값을 썼다고 로컬 오버라이드 파일까지 업데이트된 것은 아닙니다. 스크립트로 자동 조작한다면 먼저 응답과 대상 그룹 이름을 확인한 뒤 범위를 제한해 변경하세요. 인터페이스 오류, 그룹 이름 변경, 현재 설정 전환으로 스크립트가 잘못된 대상을 수정할 수 있습니다. 자동화의 장점은 검사를 생략하는 데 있지 않고 작업을 반복해도 안정적이라는 데 있습니다.

연결 목록은 도메인, 규칙, 정책 경로를 확인하는 데 적합하고 로그는 다운로드, 조회, 핸드셰이크 오류를 확인하는 데 적합합니다. 디버깅 중에는 로그 상세도를 일시적으로 높여도 되지만 작업이 끝나면 일상적인 수준으로 되돌려 접속 기록이 지나치게 쌓이지 않도록 하세요. 패널 출처도 신중하게 선택해야 합니다. 제어 인터페이스를 호출할 수 있는 페이지는 연결 정보를 읽고 관리 작업을 실행할 수 있으므로 신뢰할 수 있는 로컬 리소스나 배포 방식을 명확히 아는 패널만 사용하세요. 브라우저에서 인증서, 교차 출처, 콘텐츠 보안 경고가 나타나면 호출 관계를 먼저 확인하고 패널을 열기 위해 모든 출처를 광범위하게 허용하지 마세요.

마지막으로 전체 과정을 점검하세요. 구독이 업데이트되고 프록시 컬렉션과 규칙셋이 로드되는지, 시스템 프록시나 TUN이 예상대로 트래픽을 받는지, DNS가 자주 쓰는 도메인을 처리하는지, 내부 네트워크 서비스가 계속 접속되는지, 패널이 현재 인스턴스를 제어하는지 확인합니다. 절전 후 복귀와 네트워크 전환도 테스트해 시작 직후에만 작동하는 것은 아닌지 살펴보세요. 어느 단계에서든 실패하면 이 가이드의 해당 장으로 돌아가 범위를 좁히세요. 첫 설치와 기본 가져오기는 빠른 시작 가이드를, 클라이언트 선택은 다운로드 페이지를, 일반적인 문제는 도움말 센터를 참고하세요. 모든 고급 기능을 한꺼번에 켜기보다 설명하고 복구할 수 있는 설정을 유지하는 편이 장기적으로 관리하기 쉽습니다.