Clash 고급 설정 가이드

정책 그룹 종류와 활용

정책 그룹은 규칙에 매칭된 연결이 최종적으로 어떤 출구를 사용할지 결정합니다. 시스템 트래픽을 가로채거나 도메인을 주소로 변환하는 기능은 아닙니다. 문제를 확인할 때는 먼저 연결이 커널에 들어왔는지 확인하고, 매칭된 규칙이 어느 정책 그룹을 가리키는지 살핀 뒤 그룹 안에서 선택된 항목을 확인하세요. 프록시 페이지에서 출구만 바꾸고 규칙의 대상 그룹을 확인하지 않으면 현재 연결과 무관한 그룹을 계속 조정할 수 있습니다.

수동 선택과 자동 선택 구분하기

select는 출구를 직접 지정하는 수동 선택 그룹으로, 연결 경로를 명확히 제어해야 할 때 적합합니다. url-test는 탐지 결과를 바탕으로 자동 선택하므로 연결 상태 변화에 민감한 자주 쓰는 출구에 알맞습니다. fallback은 목록 순서에 따라 사용 가능한 항목을 선택하며, 매번 가장 빠른 항목을 찾기보다는 우선순위를 따릅니다. 세 유형의 차이는 선택 방식에 있으며 노드 자체의 회선 품질을 바꾸지는 않습니다.

load-balance는 여러 출구에 연결을 분산하는 기능이지, 한 번의 다운로드를 여러 회선으로 나눠 대역폭을 합산하는 기능은 아닙니다. 분산 방식에 따라 같은 서비스에 표시되는 접속 주소가 달라질 수 있습니다. 계정 서비스에서 세션 유지가 필요하다면 고정 출구를 사용하거나 일관성 있는 분산 방식이 요구사항에 맞는지 확인하세요. 자동 전환을 모든 사이트에 적용되는 기본 설정으로 간주하지 않는 것이 좋습니다.

상태 확인은 그룹에 설정된 테스트 주소를 대상으로 하지만 실제 서비스는 다른 도메인, 프로토콜, 포트를 사용할 수 있습니다. 테스트 성공은 해당 경로에 접속할 수 있다는 뜻일 뿐 모든 사이트에 접속 가능하다는 의미는 아닙니다. 검사 주기가 지나치게 짧으면 연결이 늘고 모바일 기기가 자주 깨어날 수 있으니 사용 환경에 맞게 설정하세요. 화면을 계속 새로고침하려고 주기를 무리하게 줄이지 마세요.

설명하기 쉬운 작은 설정부터 시작하기

아래 그룹은 내장된 직접 연결 및 거부 정책만 참조해 이름과 참조 관계를 보여주는 예제이며, 프록시 출구를 만들지는 않습니다. 설정을 불러온 뒤 프록시 페이지에서 선택을 바꾸고 새 테스트 연결을 시작해 허용과 거부의 차이를 확인하세요. 이 흐름을 이해한 다음 기존 구독에 실제 노드 이름이나 하위 그룹 이름을 추가할 수 있습니다. 이름은 한 글자도 다르지 않게 입력해야 합니다.

proxy-groups:
  - name: 수동 출구
    type: select
    proxies:
      - DIRECT
      - REJECT

rules:
  - DOMAIN-SUFFIX,example.com,수동 출구
  - MATCH,DIRECT

실제로 사용할 때는 서비스 그룹이 자동 선택 그룹을 가리키도록 하거나, 문제 해결을 위한 직접 연결을 수동 선택지로 남겨둘 수 있습니다. 다만 그룹 참조는 한 방향으로 이어져야 합니다. A 그룹이 B 그룹을 포함하고 B 그룹이 다시 A 그룹을 포함해서는 안 됩니다. 노드 이름을 바꿔도 규칙이나 그룹 구성원에 남은 이전 이름이 새 이름을 가리키도록 바뀌지는 않습니다. 설정을 불러오지 못하면 로그에서 존재하지 않는 대상과 순환 참조 메시지를 먼저 확인하세요.

구성원이 proxy-providers에서 제공된다면 그룹은 보통 use로 제공자를 참조합니다. 제공자 이름을 노드처럼 proxies에 넣는 방식이 아닙니다. 제공자는 노드 집합의 출처이고 정책 그룹은 그 집합에서 대상을 선택하는 역할을 합니다. 두 계층을 분리하면 구독이 바뀌어도 출처만 조정하고 서비스 규칙에서는 안정적인 그룹 이름을 계속 사용할 수 있습니다.

선택 결과와 연결 수명 확인하기

그룹에서 선택한 항목 변경은 보통 이후에 새로 만들어지는 연결에 적용됩니다. 브라우저가 재사용하는 연결, 진행 중인 다운로드, 장시간 연결을 유지하는 앱은 이전 출구를 계속 쓸 수 있습니다. 테스트하기 전에 해당 연결을 닫고 새 요청을 보내세요. 작업 중인 연결을 끊어야 한다면 먼저 작업을 저장하세요. 페이지를 새로고침하는 것만으로 새 출구가 적용됐다고 판단하지 말고, 연결 페이지에 표시된 경로를 확인하는 편이 정확합니다.

자동 그룹이 계속 전환된다면 구성원이 너무 많지 않은지, 테스트 대상이 별도 처리되지 않는지, DNS가 테스트 경로에 영향을 주는지 먼저 확인한 뒤 허용 오차와 검사 간격을 조정하세요. 한 번에 한 가지 요인만 바꾸고 기존 값과 결과를 기록하세요. 모든 구성원이 실패한다면 자동 선택 단계를 더 추가하기보다 로컬 네트워크, 구독 유효성, 노드 도메인 조회처럼 공통으로 의존하는 요소부터 확인하세요.

규칙 집합 구독 관리

규칙 집합을 사용하면 도메인, 주소 또는 클래식 규칙을 기본 설정에서 분리해 자주 바뀌는 서비스 목록을 관리할 수 있습니다. 기본 설정에는 출처 정의, 참조 위치, 출구 선택만 남기고 콘텐츠 업데이트는 규칙 제공자가 맡습니다. 도메인을 하나 추가할 때마다 구독 전체를 수정하지 않아도 되고, 매칭 조건 변경과 출구 정책 변경을 구분하기도 쉬워집니다.

규칙 내용, 형식, 참조 구분하기

rule-providers는 불러올 규칙 소스를 정의하고, RULE-SET은 해당 소스를 규칙 매칭 과정에 넣습니다. 제공자만 선언하고 참조하지 않으면 규칙은 적용되지 않습니다. 규칙에서 지정하는 대상은 이미 존재하는 정책 그룹이나 내장 정책이어야 합니다. 규칙 집합 자체에 서비스 출구를 넣는 것은 일반적으로 피해야 합니다. 그래야 같은 목록을 여러 설정에서 재사용할 수 있습니다.

behavior는 규칙 콘텐츠의 의미를 나타냅니다. domain은 도메인 목록, ipcidr은 IP 주소 대역, classical은 클래식 규칙 표현식에 사용됩니다. format은 저장 형식을 나타냅니다. 클래식 규칙 파일을 도메인 목록으로 불러오면 파일 다운로드가 성공해도 파싱에 실패할 수 있습니다. 소스를 선택할 때 콘텐츠 형식과 동작 유형을 모두 확인하세요.

아래 예제는 로컬 클래식 규칙 집합을 사용하므로 먼저 경로와 참조 관계를 확인하기 좋습니다. 상대 경로는 웹 페이지나 설치 디렉터리가 아니라 커널의 작업 디렉터리를 기준으로 해석됩니다. 클라이언트에서 관리할 수 있고 커널에 읽기 권한이 있는 설정 디렉터리에 파일을 만든 뒤 로그에서 실제 로드 위치를 확인하세요. 클라이언트마다 작업 디렉터리 구성이 다를 수 있습니다.

# 기본 설정에 넣을 일부 항목
rule-providers:
  work-sites:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/work-sites.yaml

rules:
  - RULE-SET,work-sites,DIRECT
  - MATCH,DIRECT

# ./rules/work-sites.yaml
payload:
  - DOMAIN-SUFFIX,example.com
  - DOMAIN,example.org

원격 업데이트는 다운로드 경로를 따로 확인하세요

로컬 파일에서 원격 규칙 소스로 옮길 때는 출처 문서에 따라 type: http, 실제 주소, 캐시 경로와 업데이트 간격을 설정해야 합니다. 웹 소개 페이지를 원본 규칙 파일 주소로 사용하지 마세요. HTML이 반환되는 응답은 다운로드에 성공한 것처럼 보여도 커널이 사용할 수 있는 규칙 콘텐츠가 아닙니다. 먼저 브라우저에서 응답 내용의 형태를 확인하고 커널 로그에서 다운로드 및 파싱 결과를 살펴보세요.

규칙 업데이트 실패와 규칙 미매칭은 서로 다른 문제입니다. 전자는 원격 주소, 연결 상태, 파싱, 디렉터리 쓰기 권한을 확인해야 합니다. 후자는 파일에 대상이 포함되어 있는지, 참조가 존재하는지, 앞선 규칙이 먼저 처리했는지 살펴보세요. 네트워크에 문제가 있어도 기존 캐시가 남아 있을 수 있으므로 현재 트래픽이 분기된다는 사실만으로 최근 업데이트 성공을 판단할 수는 없습니다.

업데이트 간격은 보통 초 단위로 지정하며 소스의 갱신 주기에 맞춰야 합니다. 변경이 적은 서비스 목록은 자주 다운로드할 필요가 없고, 요청이 잦으면 서버의 요청 제한에 걸릴 수 있습니다. 제공자마다 캐시 경로를 다르게 지정해 파일이 덮어써지지 않도록 하세요. 소스 주소를 바꾸기 전에는 기존에 사용할 수 있던 파일을 보존하고, 새 콘텐츠가 정상적으로 파싱되는지 확인한 뒤 이전 정의를 삭제하면 잘못된 업데이트로 인한 설정 중단을 줄일 수 있습니다.

첫 번째로 매칭되는 규칙을 기준으로 순서 정하기

규칙은 위에서부터 차례로 검사합니다. 구체적인 서비스 예외는 일반적인 규칙보다 앞에 두고, 마지막에는 기본 처리 규칙인 MATCH를 배치하는 것이 좋습니다. 같은 도메인이 여러 규칙 집합에 있어도 어느 집합이 더 구체적인지 자동 비교하지 않습니다. 먼저 매칭된 참조가 트래픽의 경로를 결정합니다. 여러 목록을 관리한다면 중복 콘텐츠뿐 아니라 기본 규칙 목록에서 각 목록의 우선순위도 기록하세요.

IP 규칙은 매칭할 주소를 얻기 위해 도메인 조회가 필요할 수 있습니다. no-resolve는 특정 IP 규칙이 이 절차를 직접 시작하지 않도록 하는 옵션이지, DNS 전체를 끄는 설정은 아닙니다. 모든 IP 규칙에 무조건 추가하면 조회 결과에 의존하는 트래픽이 기본 규칙으로 빠질 수 있습니다. 앱이 도메인과 대상 주소 중 무엇을 전달하는지, 앞선 규칙이 이미 매칭됐는지를 확인해 판단하세요.

규칙을 검증할 때는 해당 집합에 포함된 것이 확실한 테스트 도메인을 선택하고, 기존 연결을 닫은 뒤 다시 접속해 연결 페이지의 매칭 유형과 대상을 확인하세요. 로그에 로드 오류가 없는데도 트래픽이 계속 기본 규칙으로 향한다면 앱이 별도 DNS를 사용하는지, 주소에 직접 연결하는지, 다른 규칙이 먼저 도메인을 처리했는지 살펴보세요. 웹사이트가 대체로 정상 작동한다는 인상으로 구체적인 연결 증거를 대신하지 마세요.

DNS 설정 최적화

DNS는 도메인을 주소로 변환하지만 프록시 연결에서 도메인을 조회하는 위치는 여러 곳일 수 있습니다. 시스템 DNS, 브라우저의 암호화 DNS, Mihomo 내장 DNS, 프록시 서버 측 조회를 같은 것으로 취급하면 안 됩니다. Clash DNS 누출이나 조회 오류를 확인할 때는 어떤 프로그램이 요청을 보내고 어디로 전송하는지 먼저 파악한 뒤 커널 DNS 필드 변경 여부를 판단하세요.

서비스 조회와 부트스트랩 조회 이해하기

nameserver는 일반 도메인 조회에 사용할 업스트림 서버를 지정합니다. 업스트림 주소가 도메인으로 되어 있다면 해당 주소를 먼저 조회할 경로도 필요합니다. default-nameserver는 주로 이런 부트스트랩 조회에 사용되며 모든 서비스 도메인이 반드시 거치는 공통 입구는 아닙니다. 부트스트랩 업스트림과 프록시 출구가 서로를 필요로 하면 연결이 만들어지기 전에 프록시를 통해 조회해야 하는 순환 의존이 발생할 수 있습니다.

proxy-server-nameserver는 프록시 노드 도메인을 별도로 조회해 노드 연결이 자기 자신에게 의존하는 상황을 막는 데 사용할 수 있습니다. nameserver-policy는 매칭 조건에 따라 서비스 도메인의 업스트림을 지정하며, 내부망이나 기업 서비스처럼 특정 조회 결과가 필요한 경우에 적합합니다. 각 필드는 해결하려는 문제가 다르므로 예비용이라는 이유만으로 같은 서버를 모든 목록에 반복해서 넣지 마세요.

아래 예제는 Fake-IP를 활성화하고 일반 조회에 암호화된 업스트림을 사용합니다. 필드의 구성 관계를 보여주는 예제일 뿐 모든 네트워크에서 접속 가능하다는 보장은 없습니다. 사용 전에 업스트림이 현재 네트워크에서 접근 가능한지 확인하세요. 클라이언트가 이미 DNS 설정을 생성했다면 기존 매핑에 항목을 병합해야 합니다. 최상위 dns 키를 중복으로 남기면 어떤 설정이 적용되는지 모호해질 수 있습니다.

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://cloudflare-dns.com/dns-query

조회 경로와 연결 경로를 추적할 수 있게 구성하기

암호화 DNS는 조회가 전송되는 과정을 보호하지만 조회가 자동으로 프록시를 따르지는 않으며, 결과가 현재 연결의 출구에 적합하다는 보장도 없습니다. 직접 연결하는 서비스에는 로컬에서 접근 가능한 주소가 필요할 수 있고, 프록시 서비스의 도메인은 출구 측에서 조회될 수 있습니다. 일부 사이트에서 주소는 정상적으로 조회되지만 연결에 실패한다면 업스트림 이름만 보고 설정을 판단하지 말고 조회 결과, 규칙 경로, 실제 출구를 함께 확인하세요.

DNS 연결이 라우팅 규칙을 따르게 하려면 respect-rules를 검토할 수 있습니다. 다만 활성화하기 전에 노드 도메인을 별도로 조회할 경로를 마련하고 DNS 업스트림 자체가 어떤 규칙의 적용을 받는지 확인해야 합니다. 그렇지 않으면 DNS 조회에는 프록시가 필요하고 프록시 노드 도메인은 같은 조회가 있어야 해석되는 상황이 생겨 시작 단계부터 사용 가능한 출구를 확보할 수 없습니다.

기업 도메인과 로컬 네트워크 도메인은 특히 신중히 다뤄야 합니다. 공용 DNS 서버는 내부 주소를 알지 못할 수 있으며 시스템 DNS를 임의로 바꾸면 업무용 앱이 작동하지 않을 수 있습니다. 내부 도메인 접미사, 지정된 DNS 서버, 해당 서버에 접근할 경로를 확인한 뒤 정책으로 적용 범위를 제한하세요. 모든 도메인을 내부 전용 서버로 보내거나 내부 조회를 실수로 외부 업스트림에 전달하지 마세요.

캐시, 조회 출처, 주소 유형별로 나눠 확인하기

DNS를 변경한 뒤에는 앱 캐시, 시스템 캐시, 커널 캐시를 각각 고려해야 합니다. 브라우저가 기존 연결을 재사용하면 시스템 캐시를 지워도 새 조회가 발생하지 않을 수 있습니다. 대상 연결을 먼저 닫고 필요하면 테스트 앱을 다시 시작한 다음 로그를 살펴보세요. 명령줄 조회는 해당 도구가 사용한 조회 경로만 증명하므로 브라우저, 게임, 다른 앱도 같은 경로를 쓴다고 단정하면 안 됩니다.

ipv6: false는 여기서 커널 DNS의 관련 응답 동작을 제어합니다. 운영체제의 IPv6 전체를 끄는 설정이 아니며 모든 앱이 IPv6 연결을 시도하지 않는다는 뜻도 아닙니다. 네트워크에서 IPv6를 사용할 수 있다면 해당 트래픽을 가로챌지 명확히 결정하세요. 특정 주소 유형에서만 연결이 실패한다면 프로토콜을 무조건 끄기보다 같은 도메인의 주소 결과와 라우팅을 비교하세요.

DNS 누출을 확인할 때는 먼저 예상 동작을 정의해야 합니다. 어떤 앱이 커널을 통해 조회해야 하는지, 내부망 조회는 로컬 경로를 유지할지, 브라우저의 독립 암호화 DNS를 허용할지 정하세요. 검사 페이지에 표시된 DNS 서비스 이름은 단서일 뿐입니다. 시스템 DNS 설정, 앱 설정, 연결 기록, 필요하다면 네트워크 캡처를 함께 살펴보고 의도된 직접 조회와 예상치 못한 우회를 구분하는 것이 더 정확합니다.

TUN 및 Fake-IP

TUN은 가상 네트워크 인터페이스를 통해 트래픽을 받으며 Fake-IP는 합성 주소와 도메인 매핑을 유지합니다. 두 기능은 역할이 다릅니다. TUN을 켰다고 DNS가 모두 커널에 들어오는 것은 아니며, Fake-IP를 활성화했다고 모든 앱이 가로채지는 것도 아닙니다. 가상 인터페이스, 시스템 라우팅, DNS 조회 경로, 규칙 매칭을 함께 확인해야 합니다. 하나라도 빠지면 일부만 정상 작동하는 것처럼 보일 수 있습니다.

되돌릴 수 있는 트래픽 가로채기부터 구성하기

시스템 프록시 설정을 따르는 앱에는 시스템 프록시가 적합하며, 해당 설정을 읽지 않는 프로그램에는 TUN이 필요할 수 있습니다. 두 기능을 반드시 함께 켜야 하는 것은 아닙니다. 처음 테스트할 때는 현재 작동하는 방식을 유지하고 기존 시스템 프록시와 DNS 설정을 기록한 뒤 서비스 모드와 TUN을 켜세요. 기본 네트워크까지 끊기면 새로 추가한 가로채기 기능을 먼저 끄고 연결을 복구한 다음 로그를 분석하세요.

Clash Verge Rev의 TUN 기능은 서비스 권한과 플랫폼 지원에 따라 달라집니다. Windows에서는 서비스가 정상인지, 가상 인터페이스가 생성되는지, 보안 소프트웨어가 이를 차단하지 않는지 확인하세요. macOS에서는 필요한 권한을 승인하고 Linux에서는 실행 권한, 라우팅, 방화벽 환경을 점검해야 합니다. 동일한 YAML도 운영체제마다 라우팅 방식이 다를 수 있으므로 스위치가 켜져 있다는 이유만으로 트래픽 가로채기가 성공했다고 판단하지 마세요.

다음은 자주 쓰이는 트래픽 가로채기 설정 예제입니다. DNS 항목은 앞 절의 기존 매핑과 병합해야 합니다. auto-route는 커널에 라우팅 설정을 요청하고, auto-detect-interface는 출구 인터페이스를 자동으로 찾으며, dns-hijack은 지정된 기존 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가 반환하는 합성 주소는 원래 도메인을 커널에서 연결하기 위한 값이지 웹사이트의 실제 서버 주소가 아닙니다. 앱이 해당 주소에 연결하면 커널은 도메인을 다시 찾아 도메인 규칙을 적용할 수 있습니다. 진단 도구에 합성 주소가 표시된다는 사실만으로 조회 오류라고 볼 수는 없습니다. 이후 연결이 같은 커널에 전달되는지, 매핑이 여전히 남아 있는지 확인해야 합니다.

앱이 합성 주소를 받은 뒤 TUN을 우회해 직접 연결하거나, 절전 모드에서 복귀한 뒤 이전 매핑을 계속 캐시하면 연결에 실패할 수 있습니다. 이때는 라우팅과 캐시 수명을 먼저 확인하고 모든 도메인을 제외 목록에 넣지 마세요. 실제 주소가 필요한 앱, 특수 연결 검사를 수행하는 앱, 로컬 네트워크 검색을 사용하는 앱에 한해 fake-ip-filter를 최소 범위로 설정하세요.

제외 목록의 의미는 필터 모드에 따라 달라지므로 항목을 추가하기 전에 현재 모드의 동작을 확인하세요. 일반 제외 모드에서는 매칭된 도메인에 실제 조회 결과가 반환됩니다. 다른 필터 모드를 사용하면 목록의 의미가 바뀔 수 있습니다. 서로 반대되는 의미를 가진 예제를 여러 가이드에서 복사해 섞지 마세요. 변경 후 관련 캐시를 비우고 앱의 실제 사용 흐름을 테스트하세요.

여러 네트워크 인터페이스, 다른 터널, 절전 복귀 다루기

네트워크 인터페이스가 여러 개면 자동 감지가 예상과 다른 기본 출구를 선택할 수 있습니다. 회사 네트워크, 모바일 핫스팟, 다른 VPN이 함께 작동한다면 어느 연결이 인터넷에 나가고 어느 연결이 기업 자원에 접근하는지 먼저 파악하세요. 라우팅은 스위치를 많이 켤수록 완전해지는 것이 아닙니다. 여러 도구가 기본 경로와 DNS를 동시에 바꾸면 연결이 순환하거나 잘못된 인터페이스로 전달될 수 있습니다.

strict-route는 특정 플랫폼에서 라우팅을 더 엄격하게 제한할 수 있지만 처음부터 모든 문제를 해결하는 만능 설정은 아닙니다. 로컬 네트워크 접근이나 다른 소프트웨어와의 호환성에 영향을 줄 수 있습니다. 일반 자동 라우팅에서 우회가 발생한다고 확인하고 해당 운영체제의 동작을 이해한 뒤 항목별로 테스트하세요. 웹, 로컬 네트워크 서비스, 기업 앱, 절전 후 복귀까지 확인해야 합니다.

DNS 가로채기는 지정된 기존 DNS 요청을 대상으로 하며 앱 내부의 암호화 DNS까지 자동으로 일반 요청으로 바꾸지는 않습니다. 브라우저나 앱 자체의 조회 연결은 별도 설정과 규칙 처리가 필요할 수 있습니다. 특정 프로그램이 예상한 연결 기록에 나타나지 않는다면 DNS 가로채기 항목을 계속 추가하기보다 네트워크 권한, 프록시 설정, 독립 조회 기능을 먼저 확인하세요.

TUN을 켠 뒤 인터넷이 끊기면 커널이 시작됐는지, 서비스가 작동하는지, 인터페이스가 생성됐는지, 기본 경로가 적절한지, DNS 응답이 오는지 차례로 확인한 뒤 프록시 출구를 살펴보세요. TUN을 끈 상태와 비교하면 원인을 좁힐 수 있습니다. 노드, DNS, 네트워크 스택, 규칙 소스를 한꺼번에 바꾸면 복구되더라도 어떤 변경이 효과를 냈는지 알기 어렵습니다.

도메인 스니핑

도메인 스니핑은 연결 초기에 주고받는 프로토콜 데이터에서 호스트 이름을 찾아 대상 주소만 있는 연결에 도메인 정보를 보충하려는 기능입니다. 도메인 규칙 매칭을 개선하는 데 유용할 수 있지만 암호 해독 도구는 아니며 모든 연결에서 도메인을 알아낼 수 있는 것도 아닙니다. 켜기 전에 부족한 정보가 도메인인지, 규칙 내용인지, 트래픽 가로채기 경로인지 확인하세요. 관련 없는 연결 문제를 모두 스니핑 설정 탓으로 돌리지 마세요.

확인할 수 있는 정보의 범위 파악하기

일반 HTTP 요청에는 호스트 필드가 포함될 수 있고, 일부 TLS 핸드셰이크에서는 서버 이름을 확인할 수 있으며 QUIC에도 식별 방법이 있습니다. 실제로 확인할 수 있는 정보는 프로토콜, 구현, 암호화 방식에 따라 달라집니다. 암호화된 클라이언트 인사말 같은 기능을 사용하면 원래 식별에 쓰이던 이름을 직접 확인하지 못할 수 있습니다. 모든 HTTPS 연결에서 정확한 도메인을 복구할 수 있다고 보장할 수는 없습니다.

스니핑으로 확인된 이름이 앱에서 실제 사용하는 서비스 도메인 전체를 나타내는 것은 아닙니다. 앱 하나가 여러 서비스 도메인에 연결할 수 있고, 콘텐츠 전송 플랫폼은 여러 서비스가 주소를 공유할 수 있습니다. 연결을 재사용하면 이후 요청에서 핸드셰이크가 반복되지 않을 수도 있습니다. 연결별로 확인해야 하며 한 번 스니핑에 성공했다고 그 앱의 모든 트래픽이 같은 서비스 정책 그룹을 사용한다고 단정하지 마세요.

아래 예제는 HTTP와 TLS의 특정 포트 범위에서만 식별을 시도하며 원래 대상은 그대로 두고 강제로 변경하지 않습니다. 먼저 식별 결과가 규칙 판단을 개선하는지 확인한 뒤 범위를 넓힐지 결정하는 데 적합합니다. 클라이언트마다 화면 옵션과 생성되는 설정이 다를 수 있으므로 저장한 뒤 실행 중인 설정을 확인하세요. 화면에서 선택한 옵션이 완전한 YAML 구문과 일치한다고 가정하면 안 됩니다.

sniffer:
  enable: true
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
      override-destination: false
    TLS:
      ports:
        - 443
        - 8443
      override-destination: false

도메인 식별과 대상 변경을 따로 테스트하기

override-destination은 식별한 도메인으로 연결 대상을 바꿀지 결정하며, 화면에 표시되는 이름뿐 아니라 이후 조회와 실제 연결 방식에도 영향을 줍니다. 일부 서비스는 원래 주소, 접속 지역, 전용 진입점을 요구하므로 대상을 바로 바꾸면 정상 작동하던 동작이 깨질 수 있습니다. 먼저 보수적인 설정으로 확인하고 꼭 필요한 범위에만 적용하세요.

앱이 이미 프록시 프로토콜을 통해 도메인을 전달하거나 Fake-IP 매핑에서 도메인 정보를 얻을 수 있다면 스니핑의 효과가 크지 않을 수 있습니다. 프로토콜마다 포트 범위를 넓히면 처리 부담이 커지고 문제 경로도 복잡해집니다. 도메인 정보가 이미 충분한 환경에서는 모든 프로토콜에 적용하기보다 범위를 제한하는 편이 관리하기 쉽습니다.

특정 사이트에서 스니핑을 켠 뒤 문제가 발생하면 같은 출구와 규칙을 사용해 재현 가능한 테스트를 먼저 진행하세요. 새 연결을 사용해 켜고 끈 상태의 대상, 매칭 규칙, 오류 유형을 비교합니다. 원인이 스니핑으로 확인된 뒤에만 skip-domain으로 예외 범위를 좁히세요. 일부 호환성 문제를 가리려고 공용 도메인 접미사 전체를 제외하지 마세요.

DNS, 규칙, 로그를 함께 살펴 원인 찾기

연결 기록에 주소만 표시된다면 먼저 예상한 프로토콜과 포트인지 확인한 다음 앱이 기존 연결을 재사용하는지 살펴보세요. 스니핑은 보통 연결이 시작될 때 얻는 정보에 의존하므로 중간에 기능을 켜도 기존 연결에서 도메인을 복원하지 못할 수 있습니다. 스위치를 반복해서 바꾸기보다 대상 연결을 닫고 새 요청을 보내 관찰 조건을 명확히 하세요.

도메인이 표시되는데도 잘못된 출구를 사용한다면 스니핑 범위를 넓히지 말고 규칙 순서를 확인하세요. 도메인 복원은 정보 부족을 해결할 뿐 존재하지 않는 규칙을 자동으로 만들지는 않습니다. 도메인 규칙이 매칭됐는데도 서비스가 실패한다면 선택한 노드, DNS, 대상 연결 상태를 추가로 살펴보세요. 식별 성공과 연결 성공은 별도의 결과로 기록해야 합니다.

QUIC은 UDP를 사용하므로 문제를 확인할 때 출구와 트래픽 가로채기 경로가 해당 트래픽을 지원하는지도 확인해야 합니다. 앱이 실패 후 다른 프로토콜로 전환해 어떤 때는 되고 어떤 때는 안 되는 것처럼 보일 수 있습니다. 스니핑이 작동하는지 확인하려고 프로토콜을 전역 차단하지 마세요. 연결 증거를 수집한 뒤 프로토콜별 정책이 필요한지, 앱 설정을 바꿀지, 특정 서비스만 예외로 둘지 판단하세요.

진단에 필요한 동안만 로그 수준을 높이고 재현을 마치면 원래 수준으로 되돌리세요. 로그와 연결 정보에는 접속 도메인, 프로세스 경로, 서비스 주소가 포함될 수 있으므로 화면을 공유하기 전에 불필요한 정보를 제거하세요. 설정 차이를 기록할 때는 필드와 오류 유형만 남기면 됩니다. 전체 구독, 노드 인증 정보, 문제와 무관한 접속 기록을 첨부하지 마세요.

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

구독은 원격 콘텐츠를 제공하고 로컬 오버라이드는 기기별 설정과 개인 요구사항을 유지합니다. 원격 구독 파일을 직접 수정하면 다음 업데이트에서 원래 내용으로 덮어써질 수 있고, 실행 중인 설정을 직접 편집해도 클라이언트가 다시 생성할 때 변경 사항이 사라질 수 있습니다. 장기적으로 관리하려면 원본 구독, 오버라이드 입력값, 실행 결과를 구분하고 각 변경 사항을 어느 계층에서 저장할지 정하세요.

오버라이드 위치와 적용 범위 먼저 확인하기

Clash Verge Rev에서는 구독별 확장 또는 전역 확장 메뉴에서 로컬 설정을 관리해야 합니다. 화면에 표시되는 메뉴 이름은 실제 클라이언트에 따라 다를 수 있습니다. 전역 오버라이드는 기기 공통 설정에, 구독별 오버라이드는 특정 소스에만 적용할 예외에 적합합니다. 두 계층에서 같은 필드를 바꾸면 실제 적용 순서를 확인해야 하며 편집기에서 마지막으로 저장한 위치만 보고 결과를 판단하면 안 됩니다.

Merge 오버라이드는 클라이언트에서 정한 방식으로 동작하므로 모든 확장 필드가 Mihomo 기본 설정인 것은 아닙니다. 아래의 prepend-rules는 해당 Merge 방식에서 규칙을 앞에 배치한다는 뜻입니다. 처리 후 최종 rules에 결과가 반영됐는지 확인하세요. 이를 일반 커널 설정에 바로 넣어도 같은 병합 동작이 적용되지는 않습니다.

# 이 필드를 지원하는 Merge 오버라이드 위치에 추가
prepend-rules:
  - DOMAIN-SUFFIX,example.com,DIRECT

dns:
  ipv6: false

예제는 서비스 규칙 하나를 추가하고 기존 DNS 매핑의 필드를 조정할 뿐, 완전한 조회 방식을 정의하지 않습니다. 저장 후 실행 설정을 확인해 다른 DNS 업스트림이 의도치 않게 삭제되지 않았는지, 규칙이 예상한 위치에 들어갔는지 살펴보세요. 클라이언트의 병합 결과가 예상과 다르면 같은 오버라이드에 설정을 더 추가하지 말고 필드 하나만 분리해 테스트하세요.

목록과 매핑은 서로 다른 방식으로 병합 여부를 확인해야 합니다

YAML 매핑은 키 단위로 이해할 수 있지만 목록에는 순서, 중복, 전체 교체 여부가 중요합니다. 규칙 목록의 앞뒤 배치는 첫 매칭 결과에 직접 영향을 줍니다. 정책 그룹 목록이 통째로 교체되면 원격 규칙이 참조하는 그룹 이름이 사라질 수도 있습니다. 확장 방식마다 목록을 처리하는 방법이 다르므로 병합 성공 여부는 최종 설정과 커널 로드 결과를 함께 확인해야 합니다.

확장 스크립트는 이름 변경, 중복 제거, 필터링, 구조 변환이 필요할 때 유용하지만 복잡성도 높아집니다. 입력 및 반환 객체의 규칙을 먼저 확인하고 수정하지 않은 필드는 유지하세요. 규칙 하나나 불리언 설정 하나만 필요하다면 내용을 직접 검토할 수 있는 Merge 구문을 우선 사용하세요. 스크립트가 실행된다고 해서 출력 구조까지 커널 요구사항에 맞는 것은 아닙니다.

구독을 업데이트한 뒤에는 사용자 정의 그룹이 구성원을 계속 참조할 수 있는지 확인하세요. 제공자가 이름을 바꾸거나 노드를 삭제하거나 그룹 구조를 변경하면 특정 노드 이름에 의존하는 로컬 오버라이드가 작동하지 않을 수 있습니다. 서비스 규칙은 안정적인 로컬 그룹을 참조하고 그룹 내부에서 소스 변경을 관리하는 편이 안전하지만, 빈 그룹과 이름 충돌도 주의해야 합니다. 모든 소스에 영구적으로 적용되는 설정은 없습니다.

여러 구독은 파일을 단순히 이어 붙이는 방식이 아닙니다

클라이언트 목록에 구독이 여러 개 있다고 해서 기본적으로 하나의 실행 설정에 모두 포함되는 것은 아닙니다. 일반적으로 현재 사용할 구독 하나를 선택합니다. 여러 소스를 함께 사용하려면 노드 제공자나 명시적인 집계 기능을 검토하세요. 병합하기 전에 클라이언트가 해당 입력 방식을 지원하는지 확인해야 합니다. 완전한 YAML 파일 두 개를 그대로 붙여 넣어도 자동으로 조정되지는 않습니다.

여러 소스를 병합할 때는 노드 이름 중복, 정책 그룹 이름 중복, 규칙 우선순위, 전역 필드 충돌을 최소한 처리해야 합니다. 두 소스가 DNS, 수신 포트, 기본 규칙을 모두 정의한다면 최종 설정을 명확하게 결정해야 합니다. 하나의 기본 구조를 유지하고 다른 소스는 노드 집합만 제공하도록 구성한 뒤 서로 다른 제공자 이름으로 참조하면 전체 서비스 규칙을 섞는 것보다 검토하기 쉽습니다.

이전 클라이언트에서 옮길 때는 먼저 구독을 가져와 기본 연결을 확인하고, 포트와 규칙, DNS를 옮긴 다음 스크립트 로직을 처리하세요. 이전 Parsers의 필드와 실행 환경은 Merge와 동일하지 않습니다. Clash for Windows 마이그레이션 안내를 참고해 항목별로 확인하고 작동하지 않는 기존 설정 전체를 새 클라이언트에 덮어쓰지 마세요.

수정할 때마다 목적, 적용 범위, 되돌리는 방법을 포함한 로컬 변경 기록을 저장하세요. 문제가 생기면 새 오버라이드를 먼저 비활성화하고 원래 구독을 불러와 정상 작동을 확인한 뒤 항목을 하나씩 다시 켜세요. 백업 파일은 관리되는 위치에 보관하고 구독 주소와 인증 정보는 공개 저장소에 올리지 마세요. 공유 예제에는 구조에 필요한 필드만 남기세요.

외부 컨트롤러

외부 컨트롤러는 Mihomo 제어 인터페이스를 통해 상태를 읽고 정책을 바꾸거나 일부 관리 작업을 수행합니다. 혼합 프록시 포트와는 다르며 앱이 인터넷에 연결할 때 사용하는 주소도 아닙니다. 설정할 때 프록시 데이터 경로와 관리 경로를 구분하세요. 앱은 프록시 포트에 연결하고 관리 패널은 제어 인터페이스에 연결합니다. 두 주소를 서로 바꿔 입력하면 보통 연결 오류나 올바르지 않은 응답이 발생합니다.

로컬 인터페이스와 명확한 인증을 우선 사용하세요

external-controller는 수신 주소를 지정합니다. 127.0.0.1에 바인딩하면 로컬 IPv4 루프백에서만 접속을 허용합니다. secret은 인터페이스 인증에 사용하므로 충분히 강하고 다른 곳에서 재사용하지 않는 값을 설정하세요. 아래 비밀번호는 설명용 예시일 뿐 실제 배포에 사용하면 안 됩니다. 클라이언트가 이 필드를 이미 관리하고 있을 수 있으므로 덮어쓰기 전에 내장 화면이 현재 인터페이스에 의존하는지 확인하세요.

external-controller: 127.0.0.1:9090
secret: "your-password"

컨트롤러 접속 실패를 해결하려고 수신 주소를 모든 인터페이스로 바꾸거나 인증을 제거하지 마세요. 정책 전환과 실행 상태가 더 넓은 네트워크에 노출됩니다. 다른 기기에서 관리해야 한다면 먼저 통제된 접속 경로를 마련하고 방화벽으로 허용할 출처를 제한하세요. 일반 데스크톱 사용자는 로컬 관리를 유지하면 되며 일상적인 프록시 사용을 위해 원격 제어를 열 필요는 없습니다.

제어 인터페이스 주소는 보통 프로토콜, 호스트, 포트로 구성되며 관리 패널의 인증값은 커널의 현재 값과 같아야 합니다. 포트를 다른 프로그램이 사용 중이거나 커널이 실행되지 않았거나 클라이언트 재시작 후 인증값이 바뀌면 패널 연결이 끊길 수 있습니다. 커널 시작 로그와 수신 상태를 먼저 확인한 뒤 패널에 저장된 이전 설정을 살펴보세요. 관리 연결 오류를 프록시 회선 문제로 오인하지 마세요.

패널 파일, 제어 인터페이스, 브라우저 제한 구분하기

external-ui는 임의의 웹 주소가 아니라 로컬 패널의 정적 파일 디렉터리를 가리킵니다. 해당 디렉터리에는 실제 시작 파일과 리소스가 있어야 하며 커널에 읽기 권한이 필요합니다. 디렉터리 이름만 지정한다고 패널이 자동으로 생성되지는 않습니다. 클라이언트에 내장된 화면으로 관리할 수 있다면 별도의 정적 패널을 설정하지 않아도 됩니다. 파일 업데이트와 인터페이스 노출을 관리할 부담도 줄어듭니다.

별도의 브라우저 패널을 사용하면 교차 출처 요청, 혼합 콘텐츠, 브라우저의 로컬 네트워크 접근 제한이 문제가 될 수 있습니다. HTTPS 페이지에서 로컬 HTTP 인터페이스로 요청하는 것이 허용되지 않을 수 있으며, 이는 비밀번호 오류와는 다른 문제입니다. 브라우저 오류가 네트워크 거부, 교차 출처 차단, 인증 실패 중 무엇인지 먼저 확인하세요. 출처 제한을 전부 완화해 문제를 해결하려고 하지 마세요.

패널의 출처도 신뢰 경계에 포함됩니다. 관리 자격 증명에 접근할 수 있는 페이지는 제어 인터페이스에 요청을 보낼 수 있으므로 알 수 없는 페이지에 제어 비밀번호를 입력하지 마세요. 교차 출처 접근을 허용해야 한다면 사용 중인 커널이 지원하는 설정으로 정확한 출처만 지정하고 브라우저에서 실제로 사용되는 프로토콜과 포트를 확인하세요. 출처가 맞지 않으면 구체적인 값을 바로잡고 모든 사이트를 허용하지 마세요.

일시적 제어와 영구 설정을 구분하기

패널에서 변경하는 내용은 현재 실행 상태에 적용됩니다. 일부 설정은 클라이언트에 저장될 수 있지만 설정을 다시 불러오면 원래 값으로 돌아갈 수도 있습니다. 장기간 유지할 DNS, 규칙, 트래픽 가로채기 설정은 클라이언트 설정이나 오버라이드 메뉴에서 관리하세요. 패널에서 임시로 바꾼 내용이 원본 파일까지 변경됐다고 생각하면 안 됩니다. 특히 재시작, 구독 전환, 자동 업데이트 뒤에는 결과를 다시 확인하세요.

화면이나 연결 기록을 공유할 때는 도메인, 프로세스 경로, 기기 주소, 인터페이스 인증 정보에 유의하세요. 문제 보고에는 보통 오류 유형, 관련 필드, 재현 절차만 있으면 됩니다. 구조는 남기고 구체적인 서비스 정보는 삭제할 수 있습니다. 특정 규칙이 매칭되지 않는다는 사실을 보여주려고 전체 구독 파일을 보내거나 일반적인 지원 방법으로 제어 인터페이스를 다른 사람에게 공개하지 마세요.

클라이언트 선택과 커널 설정은 따로 판단해야 합니다. 여러 플랫폼에서 쓸 클라이언트를 고를 때는 Clash Plus부터 살펴보고, 데스크톱 오버라이드 요구사항에 따라 Clash Verge Rev 같은 클라이언트와 비교해 보세요. 클라이언트마다 화면과 확장 방식이 다르므로 같은 설정 메뉴가 같은 위치에 있다고 가정할 수 없습니다. 설치 및 플랫폼 정보는 다운로드 센터에서 확인하고 기존 설정은 현재 커널의 지원 여부에 따라 항목별로 옮기세요.

전체 문제 해결 과정을 통해 네 가지를 확인할 수 있어야 합니다. 트래픽이 커널에 들어오는지, 도메인이 어떻게 조회되는지, 규칙이 왜 매칭됐는지, 최종 출구가 무엇인지입니다. 컨트롤러는 상태를 살펴보는 창일 뿐 이 순서를 대신하지 않습니다. 안정적인 설정으로 돌아간 뒤에는 평소 로그 수준을 복구하고 임시로 열어둔 관리 인터페이스를 닫으세요. 검증된 오버라이드 변경 사항은 보관해 다음 업데이트 때 다시 확인할 수 있도록 합니다.