Clash 고급 설정 - 프록시 그룹, DNS, TUN 및 규칙 세트 가이드

설정 모델, 로드 순서 및 검증 기준

클라이언트, 커널, 설정 출처를 먼저 구분하기

Clash 생태계의 데스크톱 및 모바일 클라이언트는 구독 관리, 설정 편집, 시스템 권한 요청과 화면 표시를 담당하며, 실제 연결 처리는 커널이 수행합니다. Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu 등의 클라이언트는 호환 커널을 호출할 수 있지만, 구독 오버라이드와 설정 병합, 외부 인터페이스의 구현 방식은 서로 다릅니다. 문제를 해결할 때는 먼저 어느 계층에 속하는지 확인해야 합니다. 다운로드 및 설치 문제는 클라이언트 계층, YAML 필드를 인식하지 못하는 문제는 커널 및 설정 계층, 노드 자체를 사용할 수 없는 문제는 프록시 경로에 해당합니다. 세 계층을 혼동하면 잘못된 규칙은 고치지 않은 채 클라이언트만 계속 바꾸게 됩니다.

설정은 일반적으로 클라이언트가 생성한 기본 필드, 구독에서 반환된 노드와 정책, 사용자가 작성한 로컬 오버라이드, 실행 중 상태라는 네 가지 출처에서 구성됩니다. 실행 중 상태에는 현재 선택한 정책, 캐시된 규칙 세트와 DNS 매핑이 포함되며, 이러한 정보가 항상 YAML에 완전히 기록되는 것은 아닙니다. 일부 클라이언트는 구독을 업데이트할 때 설정을 다시 생성하므로, 생성된 임시 파일을 직접 편집하면 다음 업데이트에서 수정 내용이 덮어써질 수 있습니다. 장기적으로 유지할 설정은 클라이언트가 제공하는 오버라이드, 병합 또는 스크립트 진입점에 두고, 테스트용 변경만 현재 설정을 직접 편집하는 방식이 적합합니다.

인바운드에서 아웃바운드까지 데이터 경로 이해하기

연결이 커널에 들어오면 일반적으로 인바운드 식별, 도메인 복원 또는 스니핑, 규칙 매칭, 프록시 그룹 결정, 프록시 아웃바운드 순서로 처리됩니다. TUN을 활성화하면 시스템 라우팅이 먼저 트래픽을 가상 인터페이스로 전달합니다. Fake-IP를 활성화하면 DNS 조회가 예약 주소를 먼저 반환하고, 커널이 매핑 테이블을 바탕으로 원래 도메인을 복원할 수 있습니다. 규칙의 DOMAIN-SUFFIX, GEOSITE 또는 도메인 규칙 세트는 도메인 정보에 의존하며, IP-CIDR와 GEOIP는 대상 주소를 처리합니다. 이 경로를 이해해야 같은 앱이 시스템 프록시 모드에서는 정상인데 TUN 모드에서는 다른 규칙에 매칭되는 이유를 설명할 수 있습니다.

규칙은 순서대로 매칭되며 첫 번째로 일치한 뒤에는 검사를 중단합니다. 따라서 구체적인 도메인, 서비스 전용 규칙과 차단 규칙은 일반적인 지역 규칙보다 앞에 두고, MATCH는 반드시 마지막에 배치해야 합니다. 프록시 그룹은 규칙의 대상 이름일 뿐 트래픽을 자동으로 매칭하지 않습니다. 예를 들어 DOMAIN-SUFFIX,example.com,업무 트래픽을 작성했다면 설정 안에 이름이 완전히 같은 프록시 그룹이나 프록시 노드가 있어야 합니다. 전각 공백, 대소문자 차이, 이름 변경 누락은 로드 실패나 선택 불가의 원인이 됩니다.

최소 동작 설정부터 만들기

복잡한 설정을 수백 줄짜리 템플릿에서 시작할 필요는 없습니다. 먼저 하나의 리스닝 포트, 하나의 노드 출처, 수동 선택 그룹 하나와 기본 규칙 하나만 남겨 설정이 로드되고 연결되는지 확인한 뒤 규칙 세트, DNS, TUN을 단계적으로 추가하세요. 아래 골격은 필드 간 참조 관계를 보여줍니다. 예제 노드 주소는 예약 도메인을 사용하므로 구조 설명에만 활용하며 실제 프록시 연결에는 사용할 수 없습니다.

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

proxies:
  - name: Example-Node
    type: socks5
    server: proxy.example.com
    port: 1080

proxy-groups:
  - name: 수동 선택
    type: select
    proxies:
      - Example-Node
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,수동 선택
  - MATCH,수동 선택

로드할 때는 먼저 들여쓰기를 확인하세요. YAML은 공백으로 계층을 표현하며, Tab 문자, 같은 수준의 필드에 서로 다른 들여쓰기, 콜론 뒤 공백 누락은 구문 분석 실패를 일으킬 수 있습니다. 이름에 콜론, 샵, 대괄호 또는 앞뒤 공백이 포함되면 따옴표로 감싸는 것이 좋습니다. 배열은 여러 줄 목록이나 대괄호 형식으로 작성할 수 있지만, 같은 구간에서는 한 가지 방식만 사용해야 검토하기 쉽습니다. 불리언 값은 true 또는 false를 사용하고, 인터페이스에서 흔히 보이는 “켜기”, “끄기” 텍스트를 섞지 마세요.

설정 변경 후 회귀 점검

변경할 때마다 최소 네 가지 트래픽을 검증하세요. 직접 연결해야 하는 사이트, 프록시를 사용해야 하는 사이트, 순수 IP를 사용하는 연결, 로컬 네트워크 서비스입니다. 브라우저 접속 성공이 모든 앱의 정상 작동을 의미하지는 않습니다. 브라우저가 별도의 보안 DNS나 QUIC 기반 연결을 사용할 수 있기 때문입니다. 시스템 명령으로 해석 결과와 연결 경로도 함께 확인하는 것이 좋습니다. 예를 들어 nslookup example.com으로 시스템 DNS를 확인하고, curl -I https://example.com으로 명령줄 프로그램이 예상한 진입점을 통과하는지 검증하세요. 시스템 프록시와 TUN을 동시에 활성화했다면 각각 하나씩 끄고 재시험해 중복 인계를 배제해야 합니다.

설정 파일의 안정성은 롤백 가능성에 달려 있습니다. 같은 파일을 계속 덮어쓰기보다 “최근 정상”, “현재 테스트”, “배포 예정” 세 상태를 보관하는 편이 안전합니다. 프록시 그룹 이름을 바꿀 때는 규칙, 규칙 세트, 하위 프록시 그룹과 단축 스크립트에 남은 이전 이름을 전체 검색하세요. 노드 제공기를 삭제하기 전에는 어떤 프록시 그룹도 use로 해당 제공기를 참조하지 않는지 확인해야 합니다. 클라이언트 재시작, 구독 업데이트, 기기 재부팅 후에도 설정이 일관되게 유지되어야 검증이 완료된 것입니다.

프록시 그룹 유형과 실제 조합 방식

select: 최종 선택을 사용자에게 맡기기

select는 가장 기본적인 프록시 그룹 유형입니다. 그룹 안에는 노드, DIRECT, REJECT를 넣거나 다른 프록시 그룹을 참조할 수 있습니다. 자동 속도 측정은 수행하지 않고 현재 선택만 기록합니다. “전체 출구”, “업무 트래픽”, “스트리밍”처럼 결과를 명확히 제어해야 하는 최상위 정책에 적합합니다. 클라이언트는 일반적으로 선택 상태를 저장하지만, 저장 위치가 원본 설정이 아닌 실행 중 캐시일 수 있습니다. 재시작 후 선택을 유지하려면 커널이 지원하는 profile.store-selected를 활성화하고, 클라이언트가 시작할 때마다 설정을 초기화하지 않는지도 확인하세요.

최상위 선택 그룹에 수백 개의 노드를 직접 넣는 방식은 피하는 것이 좋습니다. 자동 속도 측정, 장애 조치, 지역별 노드를 각각 하위 그룹으로 구성한 뒤 최상위 그룹에서 이 하위 그룹을 선택하는 편이 명확합니다. 이렇게 하면 규칙은 안정적인 최상위 이름만 참조하므로 구독 노드가 늘거나 줄어도 규칙을 함께 수정할 필요가 없습니다. 임시로 직접 연결해야 하는 업무라면 최상위 그룹에 DIRECT를 추가할 수 있지만, 이는 프록시 경로를 우회하므로 고정 출구가 필요한 연결에는 적합하지 않습니다.

url-test: 측정 결과에 따라 사용 가능한 노드 선택

url-test는 설정한 URL을 주기적으로 조회해 노드를 테스트하고, 응답 성능이 조건에 맞는 노드를 선택합니다. 테스트 결과는 측정 대상의 연결 상태만 보여줄 뿐 모든 웹사이트와 프로토콜의 품질을 보장하지 않습니다. 테스트 주소는 안정적이고 응답 본문이 작으며 실제 필요한 프로토콜을 사용해야 합니다. interval이 너무 짧으면 백그라운드 요청과 모바일 기기의 배터리 소모가 늘고, 너무 길면 노드 장애 후 전환이 늦어질 수 있습니다. tolerance는 성능이 비슷한 노드 사이의 잦은 전환을 줄입니다. 값이 클수록 차이가 작을 때 현재 노드를 유지하기 쉽습니다.

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

  - name: 전체 출구
    type: select
    proxies:
      - 자동 선택
      - 장애 조치
      - DIRECT

lazy: true는 프록시 그룹을 실제로 사용할 때 필요한 테스트를 수행한다는 뜻으로, 사용하지 않는 그룹의 백그라운드 측정을 줄일 수 있습니다. 인터페이스에 모든 노드가 시간 초과로 표시되어도 곧바로 노드가 전부 무효라고 결론 내리지 마세요. 테스트 URL이 현재 네트워크에서 접근 가능한지, DNS가 올바른지, 시스템 시간이 정확한지, 프록시 프로토콜의 핸드셰이크가 네트워크 진입점에서 차단되지 않았는지 확인해야 합니다. 노드 시간 초과 문제 해결 순서를 참고해 단계별로 점검할 수 있습니다.

fallback: 우선순위와 장애 전환

fallback은 사용 가능성과 목록 순서를 중시합니다. 일반적으로 목록 앞쪽에 있으면서 테스트를 통과한 노드를 우선 사용하고, 현재 노드가 실패하면 뒤의 사용 가능한 항목으로 전환합니다. url-test보다 주 출구와 예비 출구를 고정하고 출발지 주소를 비교적 안정적으로 유지해야 하는 서비스에 적합합니다. 지연 시간이 짧은 노드를 무조건 앞에 둘 필요는 없습니다. 업무가 특정 지역이나 공급원에 의존한다면 먼저 업무 조건에 따라 정렬한 뒤 응답 시간을 고려하세요.

장애 전환은 세션 이전이 아닙니다. 출구가 바뀌면 기존 TCP 연결은 대개 다시 설정해야 하므로 다운로드, 원격 터미널 또는 장시간 연결이 끊길 수 있습니다. 연속성이 중요한 작업은 애플리케이션 계층에서 재시도를 설정하고, 잦은 상태 점검으로 잘못 전환되지 않게 하세요. 노드가 일시적으로 불안정할 때는 측정 간격을 늘리거나 그룹 내 순서로 선호 출구를 유지할 수 있지만, 테스트 시간이 가장 짧은 것만 추구해서는 안 됩니다.

load-balance: 연결 분배이지 대역폭 합산이 아님

load-balance는 서로 다른 연결을 여러 노드에 분배합니다. 하나의 TCP 연결을 여러 회선으로 나누어 대역폭을 합산하지는 않습니다. 일반적인 방식으로는 대상 주소에 따라 일관성을 유지하는 해시와 연결을 더 고르게 순환 배분하는 방식이 있습니다. 로그인 상태, 출발지 주소 검증 또는 안정적인 위험 제어가 필요한 업무는 동일한 대상 매핑을 유지하는 방식을 사용하거나 select와 fallback을 직접 선택하세요. 순환 방식은 서로 독립적인 짧은 연결에 적합하지만, 같은 서비스에서 짧은 시간 안에 여러 출구 주소가 보일 수 있습니다.

유형	판단 기준	적합한 상황	주요 한계
`select`	수동 선택 또는 지속 상태	최상위 출구, 업무 전용 그룹	장애 노드를 자동으로 제외하지 않음
`url-test`	측정 결과와 허용 오차	일상적인 자동 선택	측정 대상이 모든 업무를 대표하지 않음
`fallback`	목록 순서와 사용 가능성	고정 주·예비 출구	전환 시 기존 연결이 중단됨
`load-balance`	연결 해시 또는 순환 배분	독립 연결 분산	단일 연결의 대역폭을 합산하지 않음

필터로 구독 노드 관리하기

노드 제공기는 filter, exclude-filter 또는 클라이언트가 제공하는 정규식 필터를 통해 지역별 그룹을 만들 수 있습니다. 정규식은 구독에 실제로 존재하는 이름 형식과 일치해야 하며, 모든 제공자가 같은 약어를 사용한다고 가정하면 안 됩니다. 먼저 클라이언트에서 노드의 원래 이름을 확인한 뒤 표현식을 작성하세요. 일치 결과가 비어 있으면 프록시 그룹에 선택 가능한 항목이 없을 수 있습니다. 지역명이 여러 방식으로 표시된다면 (홍콩|HK|Hong Kong)처럼 그룹 표현식을 사용할 수 있습니다. “만료”, “잔여 트래픽” 같은 정보 노드를 제외할 때는 별도의 제외 조건을 작성해 속도 측정 그룹에 들어가지 않도록 하세요.

프록시 그룹 설계의 핵심은 안정적인 참조입니다. 규칙은 소수의 고정 그룹 이름만 참조하고, 그룹 내부에서 계속 바뀌는 노드를 구성하세요. 일반적인 구조는 “전체 출구”가 “자동 선택”, “장애 조치”, “지역 선택”, “DIRECT”를 참조하도록 만드는 것입니다. 업무 규칙은 “전체 출구”나 소수의 전용 그룹만 가리키게 하세요. 모든 규칙 세트마다 기능이 같은 프록시 그룹을 만들면 설정이 빠르게 비대해지고 구독 업데이트 후 실제 출구를 확인하기도 어려워집니다. 그룹 이름의 의미를 명확히 하고 계층은 세 단계 이내로 유지하며, 두 그룹이 서로를 참조하는 순환도 피하세요.

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

규칙 내용과 정책 결정을 분리하기

규칙 세트 제공기 rule-providers는 로컬 파일이나 원격 주소에서 규칙 묶음을 불러옵니다. 규칙 내용의 업데이트를 담당할 뿐 어떤 노드를 사용할지는 결정하지 않습니다. 기본 설정은 RULE-SET,규칙 세트 이름,프록시 그룹 이름으로 규칙 내용을 정책 결정에 연결합니다. 같은 규칙 세트를 여러 설정에서 서로 다른 프록시 그룹으로 지정할 수 있으며, 규칙 파일 자체를 수정하지 않고 프록시 그룹을 바꿔 임시로 라우팅할 수도 있습니다.

구독 방식의 관리는 규모가 크고 별도로 업데이트해야 하는 도메인 분류, IP 대역, 업무 목록에 적합합니다. 몇 개뿐이고 장기간 변하지 않는 로컬 규칙은 rules에 직접 작성하는 편이 검토하기 쉽습니다. 형식을 맞추겠다고 모든 단일 규칙을 원격 파일로 분리하지 마세요. 원격 출처를 추가하면 다운로드 실패, 캐시 만료, 형식 변경이라는 세 가지 변수가 생깁니다. 중요한 로컬 네트워크, 관리 주소와 최종 기본 규칙은 주 설정에 남겨 외부 규칙 세트에 일시적으로 접근할 수 없어도 기본 라우팅을 예측할 수 있게 하세요.

behavior가 규칙 파일의 의미를 결정합니다

behavior: domain은 도메인 집합에 사용하며, 내용은 보통 완전한 도메인, 도메인 접미사 또는 특정 도메인 표현입니다. behavior: ipcidr은 IPv4와 IPv6 네트워크 대역에 사용합니다. behavior: classical은 각 항목에 DOMAIN-SUFFIX, PROCESS-NAME, IP-CIDR 같은 완전한 규칙 유형을 포함할 수 있습니다. 주 설정에서 선언한 동작은 파일 내용과 일치해야 합니다. IP 대역을 domain으로 읽거나 완전한 클래식 규칙을 순수 도메인 집합으로 불러오면 구문 오류가 나거나 규칙이 매칭되지 않을 수 있습니다.

규칙 형식은 YAML 텍스트, 일반 텍스트 또는 커널이 지원하는 바이너리 규칙 형식일 수 있습니다. 바이너리 형식은 로드 효율이 높지만 직접 검토하기에는 적합하지 않습니다. 텍스트 형식은 문제 해결과 버전 비교가 쉽습니다. 클라이언트와 커널의 지원 범위는 완전히 같지 않으므로 설정을 옮길 때 대상 커널이 해당 format을 인식하는지 먼저 확인하세요. 용량보다 호환성이 중요하다면 대상 클라이언트에서 지원이 확인된 YAML 또는 텍스트 형식을 우선 사용하세요.

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

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

rules:
  - DOMAIN,router.local,DIRECT
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,service-rules,전체 출구
  - GEOIP,LAN,DIRECT,no-resolve
  - MATCH,전체 출구

path는 규칙 세트의 로컬 캐시 위치입니다. 서로 다른 제공기가 같은 경로를 공유하면 업데이트 중 서로 덮어쓸 수 있습니다. 경로가 있는 디렉터리에는 쓰기 권한이 필요하며, 모바일 및 제한된 데스크톱 환경에서는 보통 클라이언트가 관리합니다. interval은 초 단위로 업데이트 주기를 제어합니다. 규칙을 자주 업데이트한다고 항상 좋은 것은 아니며, 주기가 너무 짧으면 시작 요청과 원본 서버 부담이 늘어납니다. 업무 변화가 잦지 않다면 몇 분마다 갱신하는 것보다 하루 단위 업데이트가 안정적입니다.

규칙 수보다 규칙 순서가 중요합니다

커널은 위에서 아래로 매칭합니다. 사설 네트워크, 로컬 네트워크 도메인과 반드시 직접 연결해야 하는 관리 주소는 앞에 두세요. 정확한 업무 규칙은 광범위한 지역 규칙보다 앞에 배치해야 하며, 차단 규칙은 이를 허용할 수 있는 일반 규칙보다 앞에 있어야 합니다. MATCH는 앞에서 매칭되지 않은 연결만 처리합니다. 넓은 범위의 도메인 집합을 맨 위에 두면 뒤의 구체적인 규칙은 올바르게 작성되어도 실행되지 않습니다.

도메인 규칙은 일반적으로 먼저 IP를 조회할 필요가 없으며, 매칭 비용과 결과도 더 직접적입니다. IP 규칙은 도메인 해석을 일으킬 수 있습니다. 규칙이 이미 명확한 대상 주소만 확인한다면 커널 문법에 따라 no-resolve를 추가해 매칭을 위한 추가 DNS 조회를 막을 수 있습니다. 그러나 모든 IP 규칙에 기계적으로 이 매개변수를 넣어서는 안 됩니다. 연결에 도메인만 있고 규칙이 대상 IP를 기준으로 판단해야 한다면, 해석을 막는 순간 매칭 조건을 잃게 됩니다. 인바운드가 주소를 제공할 수 있는지, DNS 모드와 스니핑 상태를 함께 고려해야 합니다.

로컬 규칙 세트의 구조와 테스트

YAML 규칙 세트는 일반적으로 payload를 목록의 진입점으로 사용합니다. domain 동작 파일에는 도메인 패턴만 저장하고, classical 동작 파일에는 완전한 규칙을 저장합니다. 업데이트하기 전에 개별 파일의 문법을 먼저 검사한 뒤 주 설정에서 참조하세요. 원격 규칙 세트가 다운로드 성공으로 표시되지만 매칭되지 않는다면 네 가지를 확인해야 합니다. 제공기 이름이 RULE-SET과 일치하는지, behavior가 내용과 맞는지, 더 앞선 항목이 규칙을 가로채지 않았는지, 대상 연결에 도메인 정보가 남아 있는지입니다.

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

규칙 출처가 작동하지 않을 때 커널은 기존 캐시를 계속 사용할 수도 있고, 캐시가 없으면 최초 로드에서 해당 규칙 그룹이 비어 있을 수도 있습니다. 중요한 규칙은 로컬 기준본을 준비하고, 모든 접근 제어를 하나의 원격 주소에 의존하지 마세요. 구독 주소 파싱 이상과 규칙 세트 형식 오류는 비슷하게 보일 수 있으며 둘 다 업데이트 실패로 표시될 수 있습니다. 구독 만료 및 설정 파싱 복구 절차에 따라 HTTP 응답, 파일 내용, 캐시와 YAML 구조를 구분해 확인하세요.

유지 관리 가능한 이름과 변경 기록 만들기

제공기 이름은 출처가 아니라 내용을 나타내야 합니다. 예를 들어 work-domain, private-cidr처럼 지정하고 “규칙1”, “최신 규칙”처럼 장기적으로 의미를 알 수 없는 이름은 피하세요. 프록시 그룹 이름은 인터페이스 사용자를 위한 것이므로 한국어를 사용할 수 있지만, 제공기와 경로 이름은 플랫폼 간 경로 및 스크립트 처리 차이를 줄이기 위해 안정적인 ASCII 문자가 적합합니다. 원격 주소, behavior 또는 형식을 수정하는 것은 구조 변경으로 간주하고 해당 캐시를 먼저 정리한 뒤 테스트하세요. 오래된 캐시가 새 파일의 오류를 가릴 수 있습니다.

규칙 세트 규모가 커지면 각 집합의 용도, 데이터 유형, 업데이트 출처, 대상 정책과 마지막 수동 검증 결과를 기록하는 것이 좋습니다. 중요한 것은 규칙 수가 아니라 각 계층의 역할이 명확한지 여부입니다. 예기치 않은 매칭이 발생하면 로그에서 첫 번째 매칭 규칙을 찾은 뒤 해당 집합으로 돌아가 내용을 확인하는 것이 전역 모드를 무작정 바꾸는 것보다 효과적입니다. 중국 본토 및 해외 대상의 직접 연결, 프록시, 차단과 기본 경로의 전체 순서는 규칙 라우팅 설정 실전에서 계속 확인할 수 있습니다.

DNS 설정 최적화와 조회 라우팅

DNS는 규칙 엔진이 볼 수 있는 정보를 결정합니다

DNS 설정은 단순히 조회 서버를 바꾸는 일이 아닙니다. 도메인 조회 경로, 규칙에서 도메인을 유지할 수 있는지 여부, Fake-IP 매핑, 프록시 노드 서버 주소를 어떤 경로로 조회할지에도 영향을 줍니다. 시스템이 도메인을 어떤 리스너에 먼저 전달하는지, 조회를 직접 연결로 보낼지 프록시로 보낼지, 실제 주소를 반환할지 예약 주소를 반환할지에 따라 이후 규칙 동작이 달라집니다. “노드는 사용 가능하지만 웹페이지가 열리지 않음”, “브라우저는 정상인데 명령줄은 실패함”, “같은 도메인이 계속 다른 정책에 매칭됨” 같은 현상이 나타나면 DNS를 독립적인 경로로 점검해야 합니다.

nameserver는 일반 도메인 조회를 담당합니다. default-nameserver는 주로 암호화 DNS 서버 자체의 도메인을 해석하거나 초기 연결을 설정할 때 사용하므로, 보통 직접 접근 가능한 IP 형식의 해석기를 지정합니다. proxy-server-nameserver는 프록시 노드 서버 도메인을 전용으로 처리해 노드 도메인이 잘못된 정책으로 해석되는 것을 막을 수 있습니다. nameserver-policy는 도메인별로 해석기를 지정합니다. 지원 필드는 커널에 따라 다르며 클라이언트 인터페이스에는 일부만 표시될 수 있습니다.

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  respect-rules: true

  default-nameserver:
    - 1.1.1.1
    - 8.8.8.8

  nameserver:
    - https://dns.google/dns-query
    - https://cloudflare-dns.com/dns-query

  proxy-server-nameserver:
    - 1.1.1.1
    - 8.8.8.8

  nameserver-policy:
    "geosite:private":
      - system

  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "stun.*.*"

예시는 필드 간 관계를 보여줄 뿐 모든 네트워크가 같은 공용 해석기를 사용해야 한다는 뜻은 아닙니다. 해석기를 선택할 때는 현재 네트워크의 접근 가능성과 개인정보 보호 요구 사항을 먼저 확인하세요. 암호화 DNS 주소 자체가 도메인이라면 커널에는 여전히 초기 해석 경로가 필요하며, 이것이 default-nameserver의 역할입니다. 초기 해석기에 접근할 수 없으면 암호화 조회조차 시작되지 않습니다. respect-rules를 활성화하면 DNS 연결도 규칙 라우팅을 따릅니다. 이때 정책 선택이 아직 완료되지 않은 DNS 결과에 다시 의존해 순환이 생기지 않도록 해야 합니다.

redir-host와 fake-ip의 차이

redir-host는 실제 IP를 반환하므로 기존 DNS와 비슷하게 동작합니다. Fake-IP와 호환되지 않는 프로그램에 비교적 우호적이지만, 해석이 끝난 뒤 연결에 대상 주소만 남으면 TUN이 인계한 순수 IP 연결이 도메인 규칙에 매칭되지 않을 수 있습니다. fake-ip는 예약 주소 대역에서 매핑 주소를 반환합니다. 애플리케이션이 해당 주소로 연결하면 커널이 원래 도메인을 복원해 규칙을 적용합니다. 이를 통해 실제 해석 결과가 시스템 경로로 먼저 노출되는 것을 줄이고 TUN 환경에서도 도메인 규칙을 안정적으로 유지할 수 있습니다.

Fake-IP는 프록시 주소가 아니며 인터넷에 직접 노출되지도 않습니다. 로컬 커널의 매핑 테이블에서 특정 도메인을 나타낼 뿐입니다. 애플리케이션이 예약 주소를 받은 뒤에는 계속 연결을 Clash에 넘겨야 합니다. 시스템 라우팅, 별도 라우터 규칙 또는 보안 소프트웨어가 해당 주소 대역을 가로채면 연결이 실패합니다. 따라서 Fake-IP와 TUN의 라우팅 인계를 함께 검증해야 하며, DNS 조회가 주소를 반환했는지만 확인해서는 안 됩니다.

fake-ip-filter의 적용 범위

로컬 네트워크 검색, 프린터, 화면 전송, 시간 동기화, 일부 음성 통화와 STUN에 의존하는 프로그램은 실제 주소나 특수한 DNS 응답을 요구할 수 있습니다. 이러한 도메인은 fake-ip-filter에 추가해 Fake-IP 매핑을 우회할 수 있습니다. 필터 범위는 가능한 한 구체적으로 지정해야 합니다. 너무 넓은 와일드카드를 필터 목록에 넣으면 많은 도메인이 실제 해석으로 돌아가 도메인 복원과 규칙 매칭의 안정성이 떨어집니다. 앱 이상이 발생하면 먼저 로그나 패킷 캡처로 실제 조회 도메인을 확인한 뒤 최소한의 규칙만 추가하세요. 설명할 수 없는 긴 필터 목록을 그대로 복사하지 마세요.

일부 커널은 블랙리스트 또는 화이트리스트 방식의 필터 모드를 지원합니다. 블랙리스트는 목록에 있는 도메인만 실제 해석을 사용한다는 뜻으로 흔히 사용됩니다. 화이트리스트는 목록에 있는 도메인에만 Fake-IP를 활성화할 수 있습니다. 설정을 옮길 때는 모드 필드도 함께 이전해야 같은 도메인 목록이 정반대의 결과를 내지 않습니다. 클라이언트 인터페이스가 단순한 스위치만 제공한다면 내보낸 최종 설정에서 실제 값을 확인하세요.

IPv6, 캐시와 브라우저 독립 DNS

ipv6: false는 일반적으로 내장 DNS가 AAAA 결과를 반환하지 않는다는 뜻이지 운영체제의 IPv6를 완전히 끈다는 의미는 아닙니다. 시스템이 다른 해석기를 통해 IPv6 주소를 얻을 수 있고, 앱이 캐시된 주소에 직접 연결할 수도 있습니다. 네트워크에 안정적인 IPv6 출구가 없다면 먼저 Clash DNS에서 반환을 끈 뒤 시스템 네트워크 어댑터와 브라우저 설정을 각각 확인하세요. IPv6를 정상적으로 사용할 수 있는 네트워크라면 IPv6 라우팅 규칙도 준비해 모든 IPv6 연결이 설계하지 않은 기본 경로로 빠지지 않게 해야 합니다.

브라우저가 별도의 보안 DNS를 활성화해 시스템이 지정한 Clash DNS를 우회할 수 있습니다. 문제를 해결할 때는 브라우저의 독립 해석을 잠시 끄고, 시스템 명령으로 지정된 리스닝 포트를 조회한 뒤 시스템 및 브라우저 캐시를 삭제해 보세요. 설정을 바꾼 뒤에도 이전 주소가 보인다고 새 설정이 적용되지 않은 것은 아닙니다. 캐시가 아직 만료되지 않았을 수 있습니다. 커널을 재시작해도 커널 일부 상태만 정리되므로 운영체제, 브라우저, 앱 내부 캐시는 각각 처리해야 합니다.

현상	우선 확인할 항목	검증 방법
도메인 규칙이 매칭되지 않음	DNS가 커널을 우회하는지, 대상 IP만 남았는지	연결 로그에서 Host와 규칙 유형 확인
Fake-IP를 반환하지만 연결되지 않음	예약 주소 대역이 TUN에 의해 인계되는지	시스템 라우팅과 TUN 로그 확인
노드 도메인 해석 실패	초기 해석기와 노드 전용 해석기	노드 서버 도메인을 직접 조회
브라우저와 명령줄 결과가 다름	브라우저 독립 DNS와 앱 캐시	독립 해석을 끈 뒤 조회 결과 비교

TUN 인계, Fake-IP 매핑과 플랫폼별 한계

TUN과 시스템 프록시는 서로 다른 범위의 문제를 해결합니다

시스템 프록시는 애플리케이션이 운영체제의 프록시 설정을 직접 읽는 방식에 의존하며, 일반적으로 브라우저와 시스템 설정을 따르는 데스크톱 프로그램을 대상으로 합니다. TUN은 가상 네트워크 인터페이스를 만들고 시스템 라우팅을 통해 더 많은 TCP, UDP 및 프록시 설정을 읽지 않는 앱의 트래픽을 커널로 전달합니다. 따라서 게임, 명령줄 도구, 스토어 앱 또는 고정된 직접 연결 앱이 시스템 프록시에서 Clash에 들어오지 않는 것은 반드시 규칙 문제는 아닙니다. 애초에 프록시 진입점을 거치지 않았을 수 있습니다. TUN은 인계 범위를 넓히지만 라우팅, 권한, DNS 하이재킹과 로컬 네트워크 접근이라는 추가 변수도 가져옵니다.

TUN을 활성화하기 전에 일반 시스템 프록시 모드가 정상인지 확인하세요. 노드, 정책과 DNS 기준이 아직 검증되지 않았다면 TUN을 바로 켜 입구 문제와 아웃바운드 문제를 겹치게 하지 마세요. 권장 순서는 TUN을 끄고 노드를 검증한 다음, TUN을 켜되 복잡한 라우팅은 아직 조정하지 않고 일반 웹페이지와 명령줄 연결이 커널에 들어오는지 확인하는 것입니다. 이후 로컬 네트워크, IPv6, 앱 제외와 엄격한 라우팅을 단계적으로 처리하세요.

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

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

stack, auto-route와 strict-route

stack은 TUN 패킷을 어떤 네트워크 스택으로 처리할지 결정합니다. 일반적인 값으로는 시스템 스택, 사용자 공간 스택 또는 혼합 모드가 있습니다. 시스템 스택은 호환성이 비교적 직접적이고, 사용자 공간 스택은 커널이 연결을 일관되게 처리하기 쉽습니다. 혼합 모드는 TCP와 UDP 상황 사이의 균형을 시도합니다. 운영체제, 클라이언트 패키징 방식, 앱 프로토콜에 따라 결과가 달라질 수 있으므로 모든 기기에 적용되는 최적값은 없습니다. UDP, 로컬 네트워크 검색 또는 특정 앱에 이상이 있을 때 stack을 바꾸는 것은 유효한 비교 실험이지만, 한 번에 이 항목만 변경하세요.

auto-route는 대상 트래픽이 가상 인터페이스로 들어가도록 시스템 라우팅을 작성합니다. auto-detect-interface는 실제 출구 네트워크 어댑터를 식별해 데이터가 다시 TUN으로 돌아오는 루프를 막습니다. strict-route는 우회 경로를 더 엄격하게 제한해 일부 시스템 조회나 트래픽이 인계를 우회하는 것을 줄이지만, 다중 네트워크 어댑터, 가상 머신, 기업 네트워크와 로컬 네트워크 서비스에 영향을 줄 수 있습니다. 유선, 무선, VPN 또는 컨테이너 브리지를 동시에 사용하는 기기에서는 자동 감지가 잘못된 출구를 선택할 수 있으므로 라우팅 테이블에서 기본 경로를 확인하세요.

DNS 하이재킹과 Fake-IP 주소 대역

dns-hijack은 일반적인 53번 포트 조회를 내장 DNS로 전달해 앱의 일반 DNS 요청이 정해진 해석 경로로 들어오게 합니다. 앱에 내장된 암호화 DNS를 자동으로 인계하거나 다른 보안 소프트웨어가 가로챈 요청을 복구하지는 못합니다. 시스템에서 다른 VPN, 필터링 소프트웨어 또는 가상 네트워크 도구를 함께 실행하면 여러 구성 요소가 DNS와 기본 라우팅을 놓고 경쟁할 수 있습니다. 이때는 한 번에 하나의 인계 구성 요소만 남겨 Clash가 단독으로 작동하는지 확인한 뒤 다른 소프트웨어를 다시 활성화하세요.

Fake-IP는 기본적으로 전용 예약 네트워크 대역을 사용해 도메인 매핑을 만듭니다. 이 대역은 TUN 라우팅이 인계해야 하며 기업 네트워크, 테스트 환경 또는 다른 가상 네트워크의 실제 주소 설계와 충돌해서도 안 됩니다. 다른 구성 요소가 같은 대역을 실제 내부 네트워크로 취급하면 앱 연결이 잘못된 인터페이스로 전달됩니다. Fake-IP 범위를 바꾼 뒤에는 DNS 캐시와 커널 매핑을 정리해야 하며, 이전 주소가 자동으로 새 매핑을 나타내지는 않습니다.

MTU와 연결은 되지만 전송이 멈추는 현상

MTU가 너무 크면 일부 경로에서 단편화나 경로 MTU 탐색이 막혀 핸드셰이크는 성공하고 적은 데이터는 전송되지만, 큰 페이지나 업로드 또는 특정 프로토콜이 오랫동안 멈출 수 있습니다. MTU가 너무 작으면 패킷 수와 처리 부담이 늘어납니다. 기본값은 대부분의 이더넷 환경을 처리합니다. 모바일 네트워크, 중첩 터널과 일부 광대역 환경에서 이상이 생기면 MTU를 단계적으로 낮춰 비교하되 처음부터 극단적인 값을 설정하지 마세요. 테스트에는 작은 요청, 큰 응답, 업로드와 UDP를 포함하고 첫 화면이 열리는지만 확인하지 마세요.

일부 웹사이트만 중간에 로딩이 멈춘다면 먼저 DNS와 규칙 문제를 배제한 뒤 MTU를 확인하세요. 로그에서 연결이 이미 성립했는지, 실패가 큰 응답에 집중되는지 관찰할 수 있습니다. 시스템 명령의 구체적인 매개변수는 플랫폼마다 다르지만 원칙은 같습니다. 단편화를 금지한 패킷을 보내고 크기를 단계적으로 조정해 안정적인 상한을 찾은 뒤 터널 헤더를 위한 여유를 남기세요. 조정 후에는 단일 측정에 의존하지 말고 실제 업무를 다시 테스트해야 합니다.

Windows, macOS, Android, iOS와 Linux의 차이

Windows와 macOS에서 TUN을 활성화하려면 일반적으로 관리자 권한이나 시스템 네트워크 확장 권한이 필요합니다. 권한이 철회되면 인터페이스의 스위치가 활성화로 표시되어도 라우팅이 실제로 작성되지 않을 수 있습니다. Android와 iOS는 보통 시스템 VPN 인터페이스로 트래픽을 인계하며 동시에 하나의 연결만 유지할 수 있는 경우가 많습니다. 배터리 최적화, 백그라운드 제한과 앱별 프록시 옵션도 적용 범위에 영향을 줍니다. Linux에서는 TUN 장치, 라우팅 작성 권한과 방화벽 규칙을 확인해야 하며, 서버 환경에서는 원격 관리 연결이 프록시로 잘못 전달되어 접속이 끊기지 않게 주의해야 합니다.

클라이언트 구현에 따라 앱 제외, 라우팅 우회와 자동 복구를 인터페이스에서 설정할 수 있는지가 달라집니다. 클라이언트를 선택할 때는 플랫폼 기능을 기준으로 판단하세요. 다운로드 경로는 다운로드 페이지에서 확인할 수 있습니다. 모든 플랫폼을 우선 고려한다면 Clash Plus를, 데스크톱에서는 필요에 따라 Clash Verge Rev, FlClash와 Clash Nyanpasu를 비교할 수 있습니다. 유지 관리가 중단된 Clash for Windows와 ClashX Meta는 이전 환경과의 호환성을 확인할 때만 참고하고, 새 커널 기능에 의존해서는 안 됩니다.

로컬 네트워크, 가상 머신과 컨테이너 접근

TUN을 켜면 사설 네트워크 대역은 일반적으로 규칙 앞부분에서 직접 연결하고 실제 네트워크에 맞는 라우팅을 유지해야 합니다. GEOIP,LAN,DIRECT만 작성하는 것으로는 충분하지 않을 수 있습니다. 트래픽이 규칙 엔진에 들어오기 전에 시스템 라우팅이 잘못된 인터페이스로 보낼 수 있기 때문입니다. 시스템 라우팅, TUN 제외 대역과 Clash 규칙을 함께 확인해야 합니다. 로컬 네트워크에 여러 사설 대역이 있다면 실제 대역을 명시하고 모든 장치가 같은 서브넷에 있다고 가정하지 마세요.

가상 머신, 컨테이너와 WSL 계열 환경에는 독립적인 가상 스위치와 DNS가 있을 수 있습니다. 호스트에서 TUN을 활성화한 뒤 서브시스템 트래픽이 호스트를 통과할 수도 있고 별도의 NAT를 사용할 수도 있습니다. 먼저 서브시스템에서 기본 게이트웨이와 DNS를 확인하고, Clash의 리스닝 주소를 로컬 네트워크에 공개해야 하는지 판단하세요. allow-lan을 활성화한다면 방화벽으로 신뢰할 수 있는 대역을 제한해 프록시 포트가 통제되지 않은 네트워크에 노출되지 않게 하세요. TUN 문제를 해결할 때는 설정 오류 후 복구할 수 있도록 해당 라우팅을 거치지 않는 관리 경로를 항상 하나 남겨두세요.

도메인 스니핑의 역할, 설정과 오판 방지

스니핑은 도메인 정보를 보완합니다

일부 연결은 대상 IP만 포함한 채 커널에 들어와 도메인 규칙 매칭에 사용할 호스트 이름이 없습니다. 도메인 스니핑은 HTTP Host, TLS ClientHello의 서버 이름 또는 식별 가능한 QUIC 핸드셰이크 정보에서 도메인을 추출해 규칙 판단에 사용합니다. DNS 조회가 아니며 HTTPS 내용을 복호화하지도 않습니다. 스니핑은 연결 설정 단계에서 원래 노출되는 메타데이터만 읽습니다. TUN, 투명 프록시와 앱이 미리 해석한 연결에서는 도메인 규칙의 매칭률을 높일 수 있습니다.

스니핑은 강할수록 좋은 기능이 아닙니다. 연결에 도메인이 없거나, 프로토콜이 특수하게 캡슐화되었거나, 앱이 암호화된 클라이언트 인사를 사용하거나, 대상이 순수 IP 서비스라면 이름을 안정적으로 복원할 수 없습니다. 잘못된 대상 주소를 덮어쓰면 정상 연결이 맞지 않는 도메인으로 라우팅될 수도 있습니다. 설정에서는 프로토콜과 포트를 제한하고, 호환되지 않는 것으로 알려진 서비스에는 건너뛰기 규칙을 지정하세요.

sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true

  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
      override-destination: true
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443
        - 8443

  force-domain:
    - "+.example.com"

  skip-domain:
    - "Mijia Cloud"
    - "+.push.example.com"

parse-pure-ip는 순수 IP 대상 연결에서 프로토콜 파싱을 시도할 수 있게 합니다. force-dns-mapping은 DNS 매핑과 연동해 커널이 이전에 처리한 도메인을 복원하는 데 도움을 줍니다. override-destination은 도메인을 성공적으로 얻었을 때 스니핑 결과를 이후 대상 판단에 사용하거나 대체한다는 뜻입니다. 필드의 세부 동작은 커널 구현에 따라 달라질 수 있으므로 가져오기 전에 클라이언트가 최종 생성한 설정을 확인하세요. 인터페이스의 스위치와 직접 작성한 구간이 동시에 존재해 서로 덮어쓰지 않도록 주의해야 합니다.

HTTP, TLS와 QUIC에서 확인 가능한 범위

평문 HTTP는 보통 Host 요청 헤더에서 도메인을 얻을 수 있지만 반드시 80번 포트에서만 동작하는 것은 아닙니다. 일반적인 프록시나 개발 포트를 포트 범위에 추가하면 내부 서비스를 식별하는 데 도움이 되지만, 범위가 넓을수록 커널이 HTTP가 아닌 트래픽을 파싱하려는 경우도 늘어납니다. TLS 스니핑은 주로 핸드셰이크의 서버 이름을 읽습니다. 앱이 IP를 직접 사용하거나 서버 이름이 숨겨졌거나 표준 TLS 핸드셰이크가 아니면 유효한 도메인을 얻을 수 없습니다. QUIC은 UDP 기반이므로 TUN과 노드 경로가 해당 UDP 트래픽을 지원하는지도 확인해야 합니다.

포트 목록은 실제 업무에서 정해야 합니다. 모든 포트를 모든 프로토콜에 넣으면 더 넓게 처리하는 것처럼 보이지만 오판과 처리 비용이 늘어납니다. 일반 웹페이지는 80, 443과 실제로 사용하는 소수의 대체 포트를 우선 대상으로 하세요. 데이터베이스, 원격 데스크톱, 게임과 음성 프로토콜에 도메인 규칙이 필요하지 않다면 HTTP나 TLS로 강제 파싱하지 마세요. 로그에 스니핑 실패가 계속 표시되어도 연결 자체에 영향을 주지 않을 수 있지만, 현재 포트 범위가 너무 넓다는 신호일 수 있습니다.

force-domain과 skip-domain

force-domain은 스니핑을 우선 시도해야 하는 도메인 패턴을 지정하며, DNS 매핑이 불완전하지만 반드시 도메인별로 라우팅해야 하는 서비스에 적합합니다. skip-domain은 호환되지 않거나 도메인 결과가 불안정하거나 대상을 덮어쓰면 안 되는 연결을 제외합니다. 도메인 패턴 문법은 대상 커널의 요구 사항에 맞춰 작성해야 합니다. 일반적인 +.example.com은 루트 도메인과 하위 도메인을 포함한다는 뜻입니다. 제외 항목은 실제 장애 근거가 있어야 하며, 낯선 템플릿에서 로컬 앱과 관련 없는 이름을 대량으로 복사하지 마세요.

특정 앱이 스니핑을 활성화한 뒤 실패한다면 먼저 스니핑을 끈 상태에서 복구되는지 비교한 다음 연결 로그에서 추출된 도메인을 확인하세요. 로그의 도메인이 앱의 실제 대상과 다르면 해당 도메인이나 관련 프로세스를 제외 범위에 넣습니다. 이름이 전혀 추출되지 않았다면 DNS, 규칙과 IP 라우팅으로 돌아가 확인해야 합니다. 강제 도메인을 계속 추가해도 없는 정보가 생기지는 않습니다. 스니핑은 보조 수단이며 올바른 DNS 인계를 대신할 수 없습니다.

스니핑과 규칙 순서의 연계

스니핑 성공은 규칙 엔진이 도메인을 얻었다는 뜻일 뿐 예상한 정책에 매칭된다는 보장은 아닙니다. 더 앞선 IP 규칙, 프로세스 규칙 또는 광범위한 규칙 세트가 여전히 먼저 매칭될 수 있습니다. 문제를 해결할 때는 “sniff success”만 보지 말고 로그에 표시된 대상 도메인, 대상 주소, 매칭 규칙과 프록시 그룹을 확인하세요. 도메인 규칙을 우선하려면 연결을 가로챌 수 있는 일반 IP 규칙보다 구체적인 도메인 규칙을 앞에 배치해야 합니다.

프로세스 규칙은 플랫폼에 따라 사용 가능성이 크게 다릅니다. 데스크톱에서는 프로세스 이름이나 경로를 식별할 수 있지만, 모바일에서는 시스템 제한으로 같은 수준의 정보를 얻기 어렵습니다. 모든 도메인 규칙을 프로세스 규칙으로 대체하지 마세요. 도메인 규칙을 기본으로 하고 전용 클라이언트나 도메인을 안정적으로 식별할 수 없는 트래픽만 프로세스 규칙으로 처리하는 방식이 더 안정적입니다. 프로세스 이름은 업데이트로 바뀔 수 있으므로 로그에서 실제 이름을 확인하세요.

모든 프로토콜을 한 번에 적용하지 말고 단계적으로 활성화하기

먼저 TLS 443 포트만 활성화하고 자주 사용하는 웹페이지와 앱에서 매칭 변화를 관찰하세요. 이상이 없으면 HTTP와 QUIC을 추가합니다. 프로토콜을 하나 추가할 때마다 직접 연결, 프록시, 로컬 네트워크와 장시간 연결을 각각 테스트하세요. QUIC을 켠 뒤 일부 앱에서만 문제가 생기면 UDP 전달은 유지한 채 QUIC 스니핑만 일시적으로 꺼서 문제가 프로토콜 식별에 있는지 전송 경로에 있는지 구분할 수 있습니다.

도메인 스니핑이 가장 유용한 상황은 투명 인계 후 도메인 정보가 사라진 경우이지 모든 대상을 “추측”하는 경우가 아닙니다. 설정이 명확할수록 문제를 해결하기 쉽습니다. 장기적으로 유지할 때는 각 강제 또는 제외 항목의 이유를 기록하고 재현되지 않는 호환 항목은 주기적으로 삭제하세요. 하나의 서비스가 작동하려면 많은 스니핑 예외가 필요하다면 DNS 모드, Fake-IP 필터와 앱 자체의 해석 방식을 다시 확인해야 합니다. 원인은 대개 스니핑 목록 자체에 있지 않습니다.

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

먼저 클라이언트의 병합 계층 확인하기

다중 구독 병합은 일반적으로 Clash 설정 형식의 단일 공통 필드가 아니라 클라이언트가 수행합니다. 클라이언트는 기본 설정, 전역 오버라이드, 구독 전용 오버라이드, JavaScript 스크립트 또는 시각적 병합기를 제공할 수 있습니다. 각 진입점의 실행 순서가 최종 결과에 영향을 줍니다. 뒤에 실행된 동일한 스칼라 값은 보통 이전 값을 덮어쓰고, 매핑은 재귀적으로 병합될 수 있으며, 배열은 전체 교체, 추가 또는 이름 기준 중복 제거가 될 수 있습니다. 특정 클라이언트의 병합 방식을 모든 클라이언트에 그대로 가정해서는 안 됩니다.

시작하기 전에 클라이언트가 커널에 전달하는 최종 설정을 내보내고 작은 실험을 해보세요. 구독에 두 개의 프록시 그룹을 남기고 오버라이드에 한 개의 그룹을 추가한 뒤 최종 배열이 추가되는지 교체되는지 관찰합니다. 동작을 확인한 뒤 전체 규칙을 이전하세요. Clash Plus는 모든 플랫폼에서 우선 고려할 수 있으며, 데스크톱의 Clash Verge Rev, FlClash와 Clash Nyanpasu도 서로 다른 구독 관리 기능을 제공합니다. 구체적인 진입점은 현재 클라이언트 인터페이스를 기준으로 확인하세요. 클라이언트 간에 이전할 때는 먼저 표준 YAML을 옮기고 클라이언트 전용 병합 로직은 다시 구성합니다.

스칼라, 매핑과 배열의 처리 차이

mixed-port, mode, log-level은 스칼라 값이므로 뒤 계층의 설정이 보통 직접 대체합니다. dns와 tun은 매핑이므로 하위 필드별로 병합될 수 있습니다. proxies, proxy-groups, rules는 배열이라 예상치 못한 문제가 가장 쉽게 발생합니다. 병합기가 배열을 통째로 교체한다면 규칙 세 개만 담은 로컬 오버라이드가 구독의 기존 규칙을 전부 삭제할 수 있습니다. 병합기가 추가 방식이라면 로컬 기본 규칙이 구독의 MATCH 뒤에 배치되어 실제로는 영원히 매칭되지 않을 수도 있습니다.

따라서 규칙 배열에는 “앞에 추가”, “뒤에 추가” 또는 “교체”라는 의미를 명확히 지정해야 합니다. 로컬 네트워크 직접 연결과 업무별 정확한 규칙은 앞에 두고, 최종 MATCH는 하나만 유지해 마지막에 배치하세요. 프록시 그룹 배열은 name을 기준으로 중복을 제거해야 하며, 이름은 같지만 유형이 다른 그룹을 단순히 이어 붙여서는 안 됩니다. 노드 배열도 중복 이름을 처리해야 합니다. 그렇지 않으면 인터페이스에 하나만 표시되거나 규칙이 실제 대상을 판단할 수 없습니다.

# 로컬 기본 오버라이드: 장기간 안정적인 스칼라와 매핑만 배치
mode: rule
log-level: info
ipv6: true

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

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

tun:
  auto-route: true
  auto-detect-interface: true

위 조각에는 노드, 프록시 그룹과 규칙 배열이 포함되지 않아 재귀적 매핑 병합을 지원하는 클라이언트가 구독에 추가하기 적합합니다. 클라이언트가 전체 구간을 교체하는 방식이라면 병합 미리보기에서 dns의 다른 하위 필드가 유지되는지 확인해야 합니다. 가장 안전한 방법은 추측하지 않고 최종 YAML을 확인하는 것입니다. 결과를 표시할 수 없는 병합 도구는 운영 설정에 바로 사용하기에 적합하지 않습니다.

다중 구독 노드의 이름과 출처 분리

두 구독에 같은 노드 이름이 포함될 수 있습니다. 그대로 병합하면 정책 선택, 상태 점검과 지속 상태가 잘못된 노드를 가리킬 수 있습니다. 병합 단계에서 출처별로 안정적인 접두사를 추가하는 것이 좋습니다. 예를 들어 “주요 출처 / 노드 이름”, “백업 / 노드 이름”처럼 지정하고 프록시 그룹 참조도 함께 업데이트하세요. 접두사에 구독 제목에 따라 바뀌는 만료일이나 트래픽 정보를 넣지 마세요. 업데이트할 때마다 새 노드로 인식되어 저장된 선택이 무효화될 수 있습니다.

더 명확한 방법은 여러 proxy-providers를 유지하고 프록시 그룹이 use로 출처를 참조하게 하는 것입니다. 모든 노드를 하나의 거대한 배열로 펼치지 않아도 되므로 제공기별 업데이트 주기, 상태 점검과 필터 규칙을 설정하고 특정 출처를 임시로 비활성화하기도 쉽습니다. 제공기 경로는 고유해야 합니다. 원격 주소가 작동하지 않을 때는 최근 정상 캐시를 유지하되 인터페이스에 업데이트 실패를 명확히 표시해야 하며, 오래된 캐시를 방금 성공한 업데이트로 오인하게 해서는 안 됩니다.

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

  backup:
    type: http
    url: https://sub.example.com/backup.yaml
    path: ./providers/backup.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: 주 구독
    type: select
    use:
      - primary
  - name: 백업 구독
    type: fallback
    use:
      - backup
    url: https://www.gstatic.com/generate_204
    interval: 600

민감한 필드와 설정 배포

구독 주소, 외부 제어 키와 노드 인증 정보는 공개 저장소, 스크린샷 또는 온라인 포맷터에 복사하기에 적합하지 않습니다. 여러 사람이 관리할 때는 민감한 내용이 없는 규칙과 오버라이드를 별도로 저장하고 구독 및 인증 정보는 클라이언트 로컬에 보관하세요. 기기 간 동기화가 필요하다면 접근이 통제된 비공개 저장소를 사용하고 동기화 범위를 제한해야 합니다. 예제 설정은 필드 구조만 보여줄 뿐 실제 구독 주소를 복사해서는 안 됩니다.

외부 규칙과 로컬 오버라이드는 분리해 관리하는 것이 좋습니다. 규칙 세트는 “어떤 대상이 어떤 범주에 속하는가”를 담당하고, 로컬 설정은 “그 범주의 대상이 어떤 정책을 사용하는가”를 담당합니다. 이렇게 하면 구독이나 클라이언트를 바꿔도 규칙 자산을 재사용할 수 있습니다. 노드, 규칙, DNS와 기기별 경로를 하나의 거대한 파일에 모두 작성하면 어느 한 항목의 업데이트도 충돌 가능성을 높입니다.

업데이트 후 자동 점검 목록

구독을 업데이트할 때마다 먼저 제공기 상태와 노드 수가 정상적인지 확인하고, 최상위 프록시 그룹에 여전히 구성원이 있는지, 선택 상태가 존재하는 노드를 가리키는지, 규칙이 참조하는 정책 이름이 모두 갖춰졌는지 점검하세요. 이어서 DNS 설정이 구독에 의해 덮어써지지 않았는지, TUN과 외부 제어 API가 로컬에서 기대한 값을 유지하는지 확인합니다. 클라이언트가 설정 전처리 스크립트를 지원한다면 스크립트 오류 발생 시 부분적으로 병합된 파일을 출력하지 말고 새 설정 적용을 중단해야 합니다.

다중 구독 문제는 “업데이트 후 노드가 없음” 또는 “프록시 그룹이 비어 있음”으로 나타나는 경우가 많습니다. 구독 내용이 비어 있는 것이 아니라 필터 정규식이 모든 노드를 제외했거나, 동일 이름 중복 제거 로직이 잘못되었거나, 제공기 파일 파싱에 실패했거나, 병합기가 전체 배열을 교체했을 수도 있습니다. 원본 응답, 단일 구독 파싱, 병합 전 구조, 최종 설정과 커널 로드라는 다섯 단계를 하나씩 확인하세요. 구체적인 복구 절차는 구독 만료 및 설정 파싱 실패를 참고할 수 있습니다.

외부 제어 API, 패널 연결과 보안 경계

제어 API와 프록시 포트는 서로 다른 서비스입니다

external-controller는 실행 상태, 정책 전환, 연결 관리, 로그와 설정 다시 불러오기 등의 제어 기능을 제공합니다. HTTP 또는 SOCKS 프록시 포트가 아니므로 앱이 일반 네트워크 요청을 이 포트로 전달할 수 없습니다. 일반적인 제어 패널은 이 API에서 프록시 그룹을 읽고 선택 작업을 전송하며, 클라이언트 자체가 그래픽 인터페이스를 구현하기 위해 같은 API를 호출할 수도 있습니다. 제어 API는 실행 상태를 변경할 수 있으므로 신뢰할 수 있는 네트워크에만 공개해야 합니다.

127.0.0.1에 리스닝하면 로컬 프로그램만 접근할 수 있어 데스크톱 클라이언트와 로컬 패널에 적합합니다. 0.0.0.0에 리스닝하면 사용 가능한 모든 인터페이스에 바인딩되어 로컬 네트워크 장치가 접근할 수 있으므로 강력한 키와 방화벽의 출발지 제한을 함께 설정해야 합니다. 모든 인터페이스로 리스닝 주소를 바꾼다고 원격 관리가 완성되는 것은 아닙니다. 시스템 방화벽, 라우팅, 리버스 프록시와 브라우저의 출처 제한도 확인해야 합니다. 원격 접근이 필요 없다면 로컬 리스닝을 유지하세요.

external-controller: 127.0.0.1:9090
secret: "change-this-secret"

# 패널 파일이 클라이언트 또는 로컬 배포에서 제공될 때만 활성화
external-ui: ./dashboard

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

예시 키는 필드 설명에만 사용하며, 실제 배포에서는 로컬에서 예측하기 어려운 독립 값을 생성해야 합니다. 제어 키를 구독 주소, 시스템 로그인 비밀번호 또는 다른 서비스 자격 증명과 재사용하지 마세요. 키를 변경하면 패널의 연결 설정도 함께 업데이트해야 합니다. 패널이 계속 인증되지 않았다고 응답하면 먼저 요청에 올바른 인증 정보가 포함되었는지 확인한 뒤, 클라이언트가 시작할 때 다른 설정 파일로 secret을 덮어쓰는지 확인하세요.

외부 패널 연결 절차

제어 패널에는 일반적으로 제어 API 주소와 인증 키가 필요합니다. 패널은 API에서 프록시 그룹, 프록시 노드, 현재 연결과 로그를 읽은 뒤 사용자의 조작에 따라 전환 또는 종료 요청을 보냅니다. 패널 페이지는 열리지만 데이터가 없다면 “정적 페이지 로드”와 “API 연결”을 나누어 확인하세요. 전자는 패널 파일이나 웹 서비스에 달려 있고, 후자는 제어 API 주소, 인증, 브라우저의 동일 출처 제한과 네트워크 접근 가능성에 달려 있습니다.

패널과 API가 모두 로컬에서만 리스닝하면 설정이 가장 간단합니다. 패널이 다른 기기에 있을 때 브라우저가 접속하는 127.0.0.1은 Clash가 실행 중인 호스트가 아니라 브라우저가 실행되는 기기를 가리킵니다. 이는 흔한 주소 오판입니다. 이 경우 신뢰할 수 있는 로컬 네트워크에서 Clash 호스트가 사용하는 주소를 지정하고 방화벽으로 출처를 제한해야 합니다. 제어 API를 인터넷에 노출하는 위험은 높으므로 통제된 보안 접근 계층을 사용하고 포트를 직접 공개하지 마세요.

일반 상태 확인과 읽기 전용 관찰

문제 해결 시 먼저 읽기 전용 정보로 제어 화면이 올바른 커널에 연결되었는지 확인하세요. 현재 설정 모드, 프록시 그룹 목록, 커널 로그와 활성 연결을 확인합니다. 여러 클라이언트나 커널이 동시에 실행되면 포트가 이미 사용 중일 수 있고, 패널이 이전 인스턴스에 연결될 수도 있습니다. 프로세스, 리스닝 포트와 로그 시작 시간을 통해 대상 인스턴스를 확인하세요. 정책을 전환한 뒤 새 연결이 어떤 출구를 사용하는지 관찰합니다. 기존 연결이 모두 자동으로 이동하지는 않으므로 필요하면 관련 연결을 종료하고 다시 설정해야 합니다.

연결 목록은 앱이 커널에 들어왔는지, 대상 도메인이 복원되었는지, 어떤 규칙에 매칭되었는지와 실제 정책 경로를 판단하는 데 유용합니다. 앱이 연결 목록에 전혀 나타나지 않으면 시스템 프록시, TUN, 앱 우회 설정과 방화벽을 먼저 확인하세요. 나타나지만 정책이 잘못되었다면 규칙 순서와 프록시 그룹을 확인하고, 정책은 올바르지만 연결이 실패한다면 노드와 대상 네트워크를 확인하세요. 이 계층적 순서가 노드를 계속 바꾸는 것보다 원인을 찾기 쉽습니다.

설정 다시 불러오기와 실행 중 상태

API를 통해 설정을 다시 불러올 때는 먼저 문법 검증을 완료해야 합니다. 잘못된 설정은 거부될 수도 있고 일부 기능만 재시작될 수도 있습니다. 정책 선택, Fake-IP 매핑과 규칙 세트 캐시의 유지 여부는 설정과 커널 상태에 따라 달라집니다. profile.store-selected는 정책 선택 저장에, profile.store-fake-ip는 매핑 상태 저장에 사용됩니다. Fake-IP 주소 대역을 바꾸거나 캐시를 삭제하거나 설정 디렉터리를 옮길 때는 이러한 상태가 다시 생성될 수 있음을 예상하세요.

다시 불러온 후 리스닝 포트, 제어 주소, DNS와 TUN이 여전히 정상인지 확인하세요. 제어 API 자체의 주소를 바꾸면 현재 패널 연결이 끊기므로 새 주소로 다시 연결해야 합니다. 프록시 포트를 바꾸면 시스템 프록시가 여전히 이전 포트를 가리킬 수 있습니다. TUN 장치 이름이나 라우팅 설정을 바꾼 뒤에는 이전 라우팅을 클라이언트가 정리해야 할 수도 있습니다. 전체 재시작은 더 오래 걸리지만 리스너, 가상 인터페이스와 라우팅이 관련된 경우 연속적인 핫 리로드보다 확실한 상태를 얻기 쉽습니다.

로그 수준과 장애 원인 파악

silent, error, warning, info와 debug는 서로 다른 상세 수준을 제공합니다. 일상적인 사용에서는 info를 유지하면 규칙 세트 업데이트, 리스닝 실패와 연결 오류를 확인하기 쉽습니다. DNS, 스니핑 또는 규칙 매칭을 분석할 때만 debug를 일시적으로 사용하고, 문제를 한 번 재현한 뒤 필요한 부분을 저장하고 즉시 일반 수준으로 되돌리세요. 로그에는 대상 도메인, 로컬 네트워크 주소와 노드 이름이 포함될 수 있으므로 공유하기 전에 민감한 정보를 삭제해야 합니다.

로그를 읽을 때는 특정 연결 하나를 시간순으로 따라가세요. 먼저 인바운드 유형과 출처를 확인하고, 대상 도메인 또는 주소, 매칭 규칙, 정책 경로, 실제 노드와 최종 오류를 차례로 봅니다. 마지막 줄의 “timeout”만 잘라서는 원인을 판단하기 부족합니다. 시간 초과는 DNS, 노드 핸드셰이크, 프록시에서 대상까지의 연결, UDP 전달 또는 앱의 응답 대기 중 어느 단계에서도 발생할 수 있습니다. 문제 해결의 분류별 질문과 함께 확인하면 오류가 진입, 해석, 규칙 또는 아웃바운드 중 어느 계층에 속하는지 먼저 판단할 수 있습니다.

안전하게 공개하기 위한 최소 원칙

제어 API는 필요한 주소에만 바인딩하고, 프록시 포트는 필요한 장치에만 공개하세요. allow-lan과 제어 API 공개 여부는 별도로 판단해야 합니다. 로컬 네트워크 장치가 프록시를 사용할 수 있다고 해서 정책을 전환하거나 연결을 볼 필요까지 있는 것은 아닙니다. 시스템 방화벽은 출발지 주소를 기준으로 제어 포트를 제한하고, 패널과 API에는 별도의 키를 사용하세요. 기기가 신뢰할 수 있는 네트워크를 벗어나거나 공용 네트워크에 연결될 때 리스닝 정책이 서비스를 계속 노출하지 않는지 확인해야 합니다.

외부 패널 파일은 확인된 클라이언트 구성 요소나 통제된 배포에서 가져와야 하며, 패널 업데이트와 커널 업데이트는 분리해 진행하세요. 패널 표시 이상이 프록시 코어 중단을 의미하는 것은 아니며, 코어 연결이 정상이어도 제어 API가 안전하다는 뜻은 아닙니다. 유지 관리 시 커널 설정, 패널 버전 출처, 리스닝 주소와 접근 범위를 각각 기록하고 모든 문제를 “패널 연결 실패”로 묶지 마세요.

반복 가능한 변경 절차 만들기

안정적인 고급 설정은 일정한 절차를 따라야 합니다. 현재 정상 설정을 내보내고, 하나의 기능 영역만 수정한 뒤 YAML과 참조를 검사하고, 테스트 설정으로 실행해 직접 연결, 프록시, DNS, TUN과 제어 API를 검증한 다음 정식 설정으로 교체하세요. 구독 업데이트 후에도 핵심 점검을 반복하고 롤백 복사본을 보관합니다. 최초 연결 절차는 사용 문서로 돌아가 확인하고, 클라이언트 설치 파일과 플랫폼 선택은 다운로드 페이지에서 확인할 수 있습니다.

최종 설정에 사용 가능한 필드를 모두 포함할 필요는 없습니다. 프록시 그룹은 명확한 결정 의미가 있는 계층만 남기고, 규칙 세트는 출처와 용도를 설명할 수 있는 집합만 유지하세요. DNS와 TUN은 현재 네트워크에 실제로 필요한 기능만 활성화하고, 스니핑 예외는 이유를 설명할 수 있어야 하며, 제어 API는 최소 범위로 공개해야 합니다. 설정이 진입점에서 출구까지 데이터 경로를 명확히 설명할수록 문제가 생겼을 때 반복적인 초기화나 전체 템플릿 교체 없이 로그로 원인을 찾기 쉽습니다.