Clash 프록시 그룹, 규칙 집합 및 네트워크 스택 설정

프록시 그룹 유형과 유지 관리하기 쉬운 분기 구조

프록시 그룹은 노드를 단순히 묶어 두는 폴더가 아니라 규칙과 실제 출구 사이의 안정적인 인터페이스입니다. 규칙은 “프록시”, “스트리밍”, “다운로드”처럼 장기간 유지되는 정책 이름만 참조하고, 노드 추가·삭제, 구독 변경, 지역 조정은 프록시 그룹 내부에서 처리하면 됩니다. 이렇게 하면 구독을 바꿀 때 규칙을 다시 작성할 필요가 없고, 특정 서비스의 출구를 변경할 때도 도메인을 하나씩 찾을 필요가 없어집니다. 프록시 그룹을 설계할 때는 먼저 트래픽 계층을 그린 뒤 그룹 유형을 정해야 하며, 구독의 모든 노드를 하나의 선택 그룹에 한꺼번에 넣어서는 안 됩니다.

자주 쓰는 네 가지 그룹 유형 선택법

select는 수동 선택 그룹으로, 전체 진입점이나 특정 지역, 안정적인 출구가 필요한 서비스에 적합합니다. 현재 선택 항목을 자동으로 바꾸지 않으므로 동작을 가장 쉽게 예측할 수 있습니다. url-test는 테스트 주소와 간격에 따라 가용성을 확인하고 후보 중 응답이 빠른 노드를 선택하므로 일상적인 웹 브라우징에 적합합니다. fallback은 목록 순서대로 사용 가능한 첫 번째 노드를 선택해 우선순위와 연속성을 중시하며, 주 회선이 끊긴 뒤에만 백업 회선으로 전환하려는 경우에 알맞습니다. load-balance는 여러 노드에 연결을 분산하므로 병렬 요청이 많은 작업에 적합하지만, 같은 사이트의 연결마다 출구가 달라질 수 있어 로그인 상태나 보안 검사가 엄격한 사이트에는 적합하지 않을 수 있습니다.

지연 시간 테스트 결과는 당시 네트워크 조건에서 테스트 대상이 응답한 시간을 나타낼 뿐, 다운로드 속도와 같지 않으며 실제 사용 가능 여부를 대신 판단할 수도 없습니다. 테스트 주소는 안정적이고 용량이 작으며 빠르게 응답하는 HTTPS 리소스를 선택해야 합니다. interval이 너무 짧으면 지속적으로 탐색 요청이 발생하고, 너무 길면 노드 장애가 발생한 뒤에도 상태 갱신이 늦어집니다. 가정용 네트워크에서는 보통 몇 분 단위 간격부터 시작하는 편이 적절합니다. 모바일 네트워크에서는 백그라운드 제한과 네트워크 전환도 고려해야 하므로 테스트 그룹만으로 복구를 보장할 수 없습니다.

먼저 지역 그룹을 만들고 서비스 그룹을 구성

보다 안정적인 구조는 보통 세 계층으로 나눕니다. 하위 계층은 노드 또는 프록시 제공자이고, 중간 계층은 “홍콩 자동”, “일본 백업”, “미국 수동 선택”과 같은 지역 그룹입니다. 최상위 계층은 “프록시”, “스트리밍”, “개발 서비스”와 같은 서비스 그룹입니다. 서비스 그룹은 지역 그룹을 참조하고, 규칙은 서비스 그룹만 참조하도록 구성하세요. 각 서비스 그룹에 원본 노드를 수십 개씩 직접 넣으면 구독 이름 변경, 노드 만료와 중복 노드 때문에 모든 그룹의 유지 관리가 어려워집니다.

proxy-groups:
  - name: 홍콩 자동
    type: url-test
    use:
      - provider-main
    filter: "(?i)港|HK|Hong Kong"
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80

  - name: 일본 백업
    type: fallback
    use:
      - provider-main
    filter: "(?i)日|JP|Japan"
    url: https://www.gstatic.com/generate_204
    interval: 600

  - name: 프록시
    type: select
    proxies:
      - 홍콩 자동
      - 일본 백업
      - DIRECT

  - name: 개발 서비스
    type: select
    proxies:
      - 프록시
      - 홍콩 자동
      - 일본 백업
      - DIRECT

use는 proxy-providers 이름을 참조하고, proxies는 실제 노드, 내장 정책 또는 다른 프록시 그룹을 참조합니다. 두 항목은 임의로 바꿔 쓸 수 없습니다. 필터 표현식은 제공자마다 다른 이름을 최대한 포괄해야 하므로 중국어 지역명, 영어 약어와 전체 영어 이름을 함께 고려하세요. 다만 표현식이 너무 넓으면 안 됩니다. “US”가 다른 단어에 잘못 매칭될 수 있으므로 이름 구분자와 실제 구독 형식을 기준으로 테스트하는 편이 좋습니다.

프록시 그룹 사이의 순환 참조도 피해야 합니다. 예를 들어 “프록시”가 “자동 선택”을 포함하고, “자동 선택”이 다시 “프록시”를 후보로 지정하면 코어가 최종 출구를 결정할 수 없습니다. 수정 후 그룹이 비어 있거나 정책을 선택할 수 없거나 설정을 불러오지 못한다면 먼저 이름이 완전히 일치하는지 확인한 다음 참조 방향을 점검하세요. 중국어 구두점, 앞뒤 공백과 대소문자 차이만으로도 겉보기에는 같지만 실제로는 다른 이름이 될 수 있습니다.

마지막으로 명확한 전체 진입점 그룹을 하나 남겨 두면 임시 문제 해결이 쉬워집니다. 특정 사이트에 문제가 생기면 먼저 전체 진입점을 다른 지역 또는 DIRECT로 수동 전환한 뒤 문제가 노드, 규칙 또는 대상 사이트 중 어디에 있는지 판단하세요. 전체 진입점을 바꾼 직후 정상화되면 현재 노드와 지역 그룹을 우선 확인하고, 계속 직접 연결된다면 규칙 순서와 모드를 확인하세요. 모든 정책으로 접근할 수 없다면 DNS, TUN과 시스템 네트워크 스택을 점검해야 합니다. 프록시 그룹을 명확하게 설계하면 이후의 모든 장을 더 쉽게 검증할 수 있습니다.

규칙 집합 구독 관리와 매칭 순서

수천 개의 도메인 또는 IP 규칙을 주 설정에 직접 작성하면 파일을 읽기 어려워지고 업데이트 때마다 전체 설정을 교체하게 됩니다. rule-providers는 규칙 내용을 별도로 다운로드하고 캐시하며 업데이트할 수 있는 집합으로 분리하고, 주 설정에는 제공자 정의와 소수의 RULE-SET 참조만 남기는 기능입니다. 규칙 집합을 업데이트할 때 프록시 그룹을 수정할 필요가 없으며 설정 구조도 버전 관리하기 쉬워집니다. 광고 도메인, 로컬 네트워크 주소, 특정 서비스 도메인과 지역 IP 대역은 구독형으로 관리하기에 적합합니다. 한두 개 도메인에만 적용되는 개별 규칙은 주 설정 상단에 두는 편이 더 직관적입니다.

behavior가 규칙 집합 해석 방식을 결정

domain은 도메인 집합에 사용하며 항목은 전체 도메인, 도메인 접미사 또는 키워드 형식일 수 있습니다. 구체적인 작성 방식은 페이로드 형식에 따라 달라집니다. ipcidr은 IPv4 및 IPv6 네트워크 대역에 사용하며 매칭하려면 대상 IP가 필요합니다. classical은 DOMAIN-SUFFIX, IP-CIDR, PROCESS-NAME과 같이 유형 접두사와 매개변수가 포함된 기존 규칙을 담을 수 있습니다. 원본 파일이 기존 규칙 형식인데 behavior를 domain으로 설정하면 다운로드는 성공해도 항목이 예상대로 작동하지 않습니다. 규칙 집합을 만들기 전에 파일 내용을 확인하고 파일 이름만으로 판단하지 마세요.

format에는 보통 yaml, text 또는 코어가 지원하는 바이너리 형식을 사용합니다. YAML 페이로드에는 일반적으로 최상위 payload 키가 포함되고, 텍스트 형식은 대개 한 줄에 하나의 항목을 둡니다. path는 로컬 캐시 위치이므로 각 제공자는 서로 다른 경로를 사용해야 나중에 다운로드한 파일이 이전 파일을 덮어쓰지 않습니다. interval은 업데이트 간격을 제어합니다. 규칙 자체가 자주 바뀌지 않는다면 몇 분마다 가져올 필요가 없습니다. 원격 요청이 실패해도 기존 캐시는 계속 사용할 수 있으므로 일시적인 업데이트 실패를 모든 규칙이 무효화된 것으로 오해하지 마세요.

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

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

  private-ip:
    type: http
    behavior: ipcidr
    format: yaml
    path: ./ruleset/private-ip.yaml
    url: https://example.com/rules/private-ip.yaml
    interval: 86400

rules:
  - DOMAIN,router.local,DIRECT
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,service-rules,프록시
  - RULE-SET,private-ip,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,프록시

예시의 주소는 구조를 보여 주기 위한 것입니다. 실제 설정에서는 직접 접근 가능하고 형식이 일치하는지 확인한 규칙 소스로 바꿔야 합니다. 규칙 파일에 인증이 필요하다면 장기간 사용하는 자격 증명을 공개 동기화되는 주 설정에 넣지 마세요. 로컬 생성 과정, 제어된 리버스 프록시 또는 클라이언트가 지원하는 보안 저장 방식을 사용하고, 내보낸 진단 정보에 접근 매개변수가 포함되지 않도록 해야 합니다.

규칙은 위에서 아래로 평가되며 첫 번째 일치에서 중단

Clash에서는 규칙 개수보다 규칙 순서가 중요합니다. 정확한 도메인과 개인 오버라이드는 앞에 두고, 서비스 규칙 집합은 중간에 배치하며, 범위가 넓은 지역 규칙은 뒤에 둔 뒤 마지막에 MATCH로 나머지 트래픽을 처리하세요. GEOIP,CN,DIRECT를 먼저 작성하면 뒤의 서비스 규칙 집합이 해당 IP를 프록시로 보내려 해도 이미 매칭된 연결은 아래 규칙을 다시 확인하지 않습니다. 마찬가지로 MATCH를 중간에 두면 이후 규칙은 모두 작동하지 않습니다.

no-resolve는 규칙 매칭 단계에서 도메인을 능동적으로 해석하지 않으려는 IP 규칙에 적합합니다. 대상이 원래 IP라면 계속 매칭할 수 있지만, 대상이 도메인인 경우 네트워크 대역을 판단하기 위한 추가 주소 조회를 수행하지 않습니다. 이 매개변수는 불필요한 DNS 동작을 줄일 수 있지만, 특정 IP 규칙으로 출구를 결정하는 설정이라면 대상 주소가 규칙 시스템에 들어오기 전에 사용할 수 있는지 확인해야 합니다. 모든 IP 규칙에 기계적으로 이 매개변수를 추가하지 마세요.

규칙 집합이 매칭되지 않을 때는 먼저 세 가지를 확인하세요. 제공자 상태가 성공인지, 파일 형식과 behavior가 일치하는지, 대상 요청에 매칭 가능한 도메인이 포함되어 있는지입니다. 브라우저가 암호화 DNS를 사용하거나 애플리케이션이 IP에 직접 연결하거나 TUN이 해당 프로세스를 인계하지 않은 경우, 실제 매칭 대상이 예상과 달라질 수 있습니다. 이때는 규칙 순서를 반복해서 바꾸기보다 연결 목록에서 실제 대상, 매칭된 규칙과 정책을 함께 확인해야 합니다.

장기적으로 관리할 때는 각 규칙 집합의 출처, 용도, 동작 유형과 연결된 프록시 그룹을 기록해 두면 좋습니다. 새 규칙은 먼저 개별 규칙으로 주 설정 상단에 며칠 동안 적용해 오작동이 없는지 확인한 뒤 직접 만든 규칙 집합에 병합하세요. 규칙을 삭제할 때도 연결 로그를 먼저 확인하여 “현재 접근하지 않음”을 “앞으로도 필요 없음”으로 오해하지 않도록 합니다. 주 설정 각 구간의 배치 관계를 더 이해하려면 Clash 설정 파일 YAML 각 구간과 필드 해설을 참고하세요.

DNS 설정 최적화와 누수 점검

DNS 설정은 서로 다른 세 가지 문제를 해결해야 합니다. 도메인을 누가 해석하는지, 조회 요청이 어느 네트워크 출구에서 나가는지, 해석 결과를 규칙 시스템에 어떻게 전달하는지입니다. 공용 DNS 주소 하나만 바꿔서는 이 세 가지를 동시에 해결할 수 없습니다. 시스템 DNS, Clash 내장 DNS, 브라우저 보안 DNS와 애플리케이션 자체 해석기가 함께 존재할 수 있으므로 문제를 해결할 때는 먼저 실제 요청 경로를 확인한 다음 서버를 선택해야 합니다. 일반적으로는 관리 대상 애플리케이션을 모두 Clash DNS로 보내고 규칙과 프록시 정책이 이후 연결을 결정하도록 구성하는 것이 제어하기 쉽습니다.

nameserver, proxy-server-nameserver와 direct-nameserver

nameserver는 일반 도메인 조회에 사용하는 주요 상위 DNS 서버입니다. HTTPS 또는 TLS 방식을 사용하면 로컬 네트워크가 평문 조회에 개입하는 것을 줄일 수 있지만, 연결이 암호화되었다고 해서 조회가 반드시 프록시를 통과하는 것은 아닙니다. 실제 출구는 코어의 기능, 규칙과 부트스트랩 해석에 따라 달라집니다. proxy-server-nameserver는 주로 프록시 서버 자체의 도메인을 해석하는 데 사용하여 “프록시에 연결하려면 도메인 해석이 필요한데, 해석은 아직 연결되지 않은 프록시를 거쳐야 하는” 순환을 피합니다. direct-nameserver는 명시적으로 직접 연결할 조회에 사용하며, 로컬 네트워크 장치 이름이나 LAN 서비스에 적합하지만 클라이언트와 코어가 해당 필드를 지원해야 합니다.

default-nameserver는 암호화 DNS 서버 주소 자체를 해석할 때 주로 사용하며, 보통 직접 접근 가능한 IP 형식의 해석기를 입력합니다. 모든 조회의 최종 상위 DNS가 아니므로 주소를 지나치게 많이 넣을 필요도 없습니다. 암호화 DNS URL에 도메인을 사용하면서 기본 해석기에 접근할 수 없으면 클라이언트가 시작된 뒤 모든 도메인이 멈추지만 IP에 직접 접근하면 정상인 현상이 나타날 수 있습니다.

dns:
  enable: true
  listen: 0.0.0.0: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://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "time.*.gov"
    - "+.stun.*.*"
    - "+.stun.*.*.*"

listen이 모든 인터페이스에서 수신하도록 설정되면 LAN의 다른 장치가 해당 포트에 접근할 수 있습니다. 로컬 컴퓨터에서만 사용할 경우 루프백 주소에 우선 바인딩하세요. LAN DNS로 제공해야 한다면 시스템 방화벽, 접근 제어와 라우터 설정도 함께 점검해야 합니다. 포트가 이미 사용 중이면 코어가 시작되지 않거나 DNS 모듈이 수신하지 못할 수 있습니다. Windows에서는 시스템 네트워크 도구로 점유 프로세스를 찾고, macOS와 Linux에서는 lsof 또는 ss로 확인할 수 있습니다.

# Windows PowerShell
Get-NetUDPEndpoint -LocalPort 1053

# macOS
lsof -nP -iUDP:1053

# Linux
ss -lunp | grep 1053

Fake-IP와 redir-host 선택

fake-ip는 먼저 예약 주소 대역의 매핑 주소를 반환하고, 연결이 코어에 도착하면 원래 도메인으로 복원합니다. 이를 통해 규칙 시스템이 도메인 정보를 유지하기 쉬워지고 도메인 규칙 매칭도 안정되며, “해석 결과가 특정 IP로 나와 IP만으로 판단해야 하는” 상황도 줄어듭니다. 대신 일부 LAN 검색, 시간 동기화, 게임 연결, 프린터 또는 실제 해석 결과에 의존하는 프로그램이 호환되지 않을 수 있어 fake-ip-filter에 추가해야 합니다. 필터 항목은 실제로 실패한 도메인을 기준으로 점진적으로 추가하고, 지나치게 긴 목록을 그대로 복사하지 마세요. 많은 도메인이 Fake-IP를 우회하면 통합 분기 효과가 약해집니다.

redir-host는 실제 해석 결과를 반환하므로 호환성이 더 직관적인 경우가 많지만, 도메인과 연결의 연계가 DNS 매핑 캐시에 더 의존합니다. CDN, 다중 주소 순환과 애플리케이션 자체 해석기를 사용할 때는 규칙 판단이 Fake-IP보다 불안정할 수 있습니다. 선택할 때 특정 테스트 사이트의 결과만 보지 말고 자주 사용하는 애플리케이션, LAN 서비스, 절전 모드 복귀와 네트워크 전환을 모두 검증해야 합니다.

DNS 누수는 요청 경로를 기준으로 확인

일반적으로 누수란 제어된 상위 DNS 또는 프록시 경로에서 처리되어야 할 조회가 시스템, 라우터, 통신망 또는 브라우저에 의해 별도로 전송되는 현상을 뜻합니다. 온라인 검사는 테스트 페이지가 발생시킨 일부 조회만 보여 주므로 모든 애플리케이션이 같은 경로를 사용하는지 증명할 수 없습니다. 먼저 브라우저 내장 보안 DNS를 끄거나 시스템 설정과 동일하게 구성한 뒤 Clash 로그, 시스템 DNS 설정과 로컬 포트 트래픽을 관찰하는 편이 더 정확합니다. 사이트의 Clash DNS 누수 검사 방법과 누수 방지 설정 절차에서는 온라인 검사와 로컬 관찰을 조합한 과정을 소개합니다.

“IP는 열리지만 도메인은 열리지 않는” 경우에는 DNS 모듈의 시작 상태, 수신 포트와 상위 DNS 접근성부터 확인하세요. “일부 도메인만 느리게 해석되는” 경우에는 여러 상위 서버 중 하나가 지속적으로 시간 초과되는지, IPv6 조회가 네트워크에서 차단되는지 점검합니다. “규칙상 프록시여야 하는데 직접 연결되는” 경우에는 애플리케이션이 시스템 해석을 우회하는지, 연결 목록에 도메인이 유지되는지, 대상 규칙이 범위가 넓은 직접 연결 규칙보다 앞에 있는지 확인하세요.

TUN을 켜고 끈 뒤 시스템에 잘못된 DNS가 남았다면 먼저 클라이언트를 완전히 종료하고 네트워크 어댑터를 자동 DNS로 되돌린 다음 다시 시작하세요. 시스템 프록시, 가상 네트워크 어댑터 또는 DNS를 변경하는 네트워크 도구를 동시에 실행하지 마세요. 각 도구가 단독으로는 정상 작동하더라도 나중에 시작한 도구가 앞선 도구를 덮어써 간헐적인 장애를 일으킬 수 있습니다.

TUN 모드, Fake-IP와 시스템 네트워크 스택

시스템 프록시는 프록시 설정을 능동적으로 읽는 애플리케이션에만 영향을 줍니다. 명령줄 프로그램, 게임, 스토어 구성 요소, 일부 데스크톱 클라이언트와 소켓을 직접 만드는 프로그램은 이를 완전히 무시할 수 있습니다. TUN 모드는 가상 네트워크 어댑터로 더 넓은 IP 트래픽을 가로채 Clash 규칙에 전달하므로 프록시를 인식하지 못하는 애플리케이션도 통합 처리해야 할 때 적합합니다. 이는 “더 강력한 시스템 프록시 스위치”가 아니라 라우팅, DNS, 가상 인터페이스와 권한이 관련된 네트워크 경로입니다. 따라서 활성화하기 전에 일반 시스템 프록시 모드가 정상 작동하는지 먼저 확인해야 합니다.

핵심 필드와 스택 선택

enable은 TUN을 제어하고, auto-route는 코어가 필요한 라우팅을 설치하도록 합니다. auto-detect-interface는 현재 기본 아웃바운드 인터페이스를 식별하여 유선, 무선과 핫스팟 전환 후 수동 수정의 필요성을 줄입니다. dns-hijack은 지정 포트의 DNS 요청을 내장 DNS로 전달합니다. stack은 네트워크 스택 구현을 결정하며 일반적인 값으로 system, gvisor와 혼합 처리를 지원하는 스택이 있습니다. 지원 범위는 코어와 플랫폼마다 다르므로 현재 클라이언트에서 실제로 제공하는 옵션을 기준으로 해야 합니다.

system은 일반적으로 시스템 네트워크 기능을 활용하므로 성능과 호환성이 자연스럽지만 운영체제 차이의 영향을 받습니다. gvisor는 사용자 공간 네트워크 스택을 사용해 격리가 명확하고 일부 환경에서는 시스템 스택의 제한을 우회할 수 있지만, 특수 프로토콜이나 고동시성 연결에서 다른 동작을 보일 수 있습니다. 스택 전환은 문제 해결 수단이므로 장애 근거 없이 자주 변경하지 마세요. 한 번에 하나의 변수만 바꾸고 같은 네트워크 조건에서 검증해야 합니다.

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

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

strict-route는 트래픽이 예상하지 않은 경로로 우회할 가능성을 줄이지만, 가상 머신, 컨테이너, 회사 VPN과 복잡한 LAN 환경에서는 기존 라우팅에 영향을 줄 수 있습니다. 활성화 후 LAN 장치, 원격 데스크톱 또는 개발 컨테이너에 갑자기 접근할 수 없다면 활성화 전후의 라우팅 테이블을 비교하여 사설 네트워크 대역이 올바른 인터페이스를 통과하는지 확인하세요. LAN에 접근해야 한다면 규칙으로 사설 주소를 직접 연결로 지정할 수 있지만, 이미 잘못된 시스템 라우팅에 의해 가로채인 연결을 규칙만으로 복구할 수는 없습니다.

Fake-IP 주소는 실제 목적지 주소가 아님

Fake-IP를 활성화한 뒤 패킷 캡처나 시스템 연결 목록에 198.18.0.0/16과 같은 주소가 보이는 것은 정상입니다. 애플리케이션은 먼저 이 매핑 주소에 연결하고, 코어는 매핑 테이블에 따라 도메인을 복원한 뒤 규칙과 실제 해석을 수행합니다. 이 주소 대역을 일반 직접 연결 라우팅에 추가하거나 원격 서버 주소로 해석하지 마세요. Fake-IP로 연결된 뒤 TUN이 이를 인계하지 못하면 시스템은 예약 주소를 실제 대상이라고 생각해 즉시 실패하거나 오래 기다리게 됩니다.

따라서 Fake-IP와 TUN의 핵심은 순환 구조입니다. DNS 조회는 Clash가 매핑 주소를 반환하고, 애플리케이션은 매핑 주소에 연결하며, 라우팅은 이 연결을 다시 Clash로 보냅니다. 어느 한 단계라도 다른 도구가 인계하면 매핑이 깨질 수 있습니다. 대표적인 충돌로는 시스템 DNS를 우회하는 브라우저의 독립 DNS, 기본 라우팅을 가로채는 다른 가상 어댑터, 예약 대역을 필터링하는 회사 보안 소프트웨어, 절전 모드 복귀 후 높은 라우팅 우선순위를 유지하는 오래된 가상 인터페이스가 있습니다.

플랫폼별 권한과 충돌 이해

Windows에서 활성화 후 인터넷이 완전히 끊기면 먼저 TUN을 끄고 기본 프록시가 복구되는지 확인한 다음 가상 네트워크 어댑터가 정상적으로 생성되었는지와 기본 인터페이스가 올바르게 식별되었는지 점검하세요. macOS에서는 클라이언트에 네트워크 확장 권한이 있는지 확인하고 동시에 실행 중인 다른 VPN을 종료해야 합니다. Linux 서버에서는 커널이 TUN 장치를 제공하는지, 실행 중인 사용자가 인터페이스를 생성하고 라우팅을 변경할 권한이 있는지도 확인해야 합니다. Android는 시스템 VpnService에 의존하며 일반적으로 한 번에 하나의 활성 VPN만 유지할 수 있습니다. 관련 권한과 백그라운드 제한은 Android VpnService 권한 및 배터리 절전 예외 목록 설정 요점을 참고하세요.

TUN 문제를 해결하는 가장 효과적인 방법은 계층별 테스트입니다. 먼저 TUN을 끄고 시스템 프록시만 사용해 노드를 확인한 다음, 간단한 규칙을 유지한 채 TUN을 활성화하세요. 그 후 도메인, 직접 IP, LAN 주소와 시스템 프록시를 읽지 않는 애플리케이션을 테스트하고, 마지막에 복잡한 DNS, 스니핑과 규칙 집합을 추가합니다. 처음부터 모든 고급 옵션을 동시에 활성화하면 한 곳의 실패도 “네트워크를 사용할 수 없음”으로 나타나 실제 장애 지점을 판단하기 어렵습니다.

도메인 스니핑의 용도, 설정과 한계

규칙 기반 분기에 가장 이상적인 입력은 도메인입니다. 도메인은 계속 바뀌는 CDN 주소보다 서비스 소속을 표현하기 쉽기 때문입니다. 하지만 일부 애플리케이션은 먼저 직접 해석한 뒤 IP에 바로 연결하고, 일부 투명한 가로채기 환경에서는 연결 초기에 대상 주소만 확인할 수 있습니다. 도메인 스니핑은 TLS 핸드셰이크의 SNI, HTTP 요청 헤더 또는 기타 식별 가능한 정보에서 대상 도메인을 복원하여 도메인 규칙이 다시 매칭될 기회를 제공합니다. 이는 연결 메타데이터를 보완하는 기능이지 DNS를 대체하는 만능 기능은 아닙니다.

TLS와 HTTP 스니핑은 각각 무엇을 확인하는가

TLS 스니핑은 일반적으로 핸드셰이크 단계에서 공개적으로 확인 가능한 서버 이름을 읽으며 이후 내용을 복호화하지 않습니다. HTTP 스니핑은 평문 요청의 Host 필드를 읽을 수 있습니다. 대상 프로토콜에 도메인이 포함되지 않거나, 애플리케이션이 IP에 직접 연결하거나, 연결이 기존 채널을 재사용하거나, 서버 이름을 숨기는 방식을 사용하면 스니핑 결과를 얻지 못할 수 있습니다. UDP 프로토콜의 식별 범위도 코어 구현과 실제 트래픽에 따라 달라지므로 모든 UDP 연결에서 도메인을 복원할 수 있다고 가정해서는 안 됩니다.

스니핑으로 얻은 도메인은 연결의 실제 목적지와 일치해야 합니다. 하나의 공유 IP에서 여러 사이트를 제공하는 경우 잘못된 대상 덮어쓰기로 규칙이 오판할 수 있고, 일부 애플리케이션은 인증서나 SNI와 일치하지 않는 전용 주소에 연결하기도 합니다. 설정할 때는 먼저 자주 사용하는 포트만 활성화하고 연결 기록을 관찰한 뒤 범위를 넓힐지 결정하세요. 로그에 표시되는 “도메인 비율”을 높이려고 모든 포트를 스캔하지 마세요.

sniffer:
  enable: true
  parse-pure-ip: true
  force-dns-mapping: true
  override-destination: false
  sniff:
    TLS:
      ports:
        - 443
        - 8443
    HTTP:
      ports:
        - 80
        - 8080-8880
  skip-domain:
    - "Mijia Cloud"
    - "+.push.apple.com"

parse-pure-ip는 순수 IP 대상에서 도메인 복원을 시도하도록 하며, 투명 프록시 환경에서 자주 사용하는 기능입니다. force-dns-mapping은 DNS 매핑을 활용해 대상을 식별하며 Fake-IP와 함께 사용할 때 특히 흔합니다. override-destination은 스니핑 결과로 원래 목적지를 덮어쓸지 결정합니다. 활성화하면 규칙과 연결 대상이 도메인 기준에 더 가까워질 수 있지만 잘못된 스니핑의 영향도 직접 커집니다. 먼저 끈 상태로 두고 로그의 복원 결과가 안정적인지 확인한 뒤 실제 필요에 따라 결정하세요.

언제 제외 목록을 추가해야 하는가

제외 목록은 스니핑이나 대상 덮어쓰기에 적합하지 않은 대상을 명시할 때 사용합니다. LAN 장치, 스마트 홈 기기, 푸시 서비스, 특수 인증 프로그램과 일부 게임은 고정 주소나 비표준 핸드셰이크에 의존할 수 있습니다. 스니핑을 끄면 정상인데 켠 뒤 지속적으로 실패하고 연결 로그에 관련 없는 도메인이 복원된다면 해당 도메인 또는 프로세스 관련 대상을 제외 범위에 추가할 수 있습니다. 다만 문제가 실제로 스니핑에서 비롯되었는지 먼저 확인하고 TUN, MTU, UDP 또는 노드 자체의 문제와 구분해야 합니다.

목록 항목은 현재 코어가 지원하는 도메인 매칭 문법을 따라야 합니다. 전체 도메인은 하나의 서비스에 적합하고 도메인 접미사는 여러 하위 도메인에 적합합니다. 범위가 넓은 접미사일수록 신중해야 합니다. 예를 들어 최상위 도메인 전체를 제외하면 많은 연결에서 스니핑 기능을 잃게 됩니다. 애플리케이션 이름처럼 보이는 항목이 유효한지는 코어가 특수 표기를 어떻게 해석하는지에 따라 달라지므로 다른 클라이언트로 옮길 때 다시 확인해야 합니다.

스니핑과 규칙, DNS의 처리 순서

연결이 코어에 들어오면 먼저 Fake-IP 매핑에서 도메인을 얻거나 스니핑으로 도메인을 복원한 다음 규칙에 따라 정책을 선택할 수 있습니다. DNS 매핑이 이미 안정적이라면 스니핑은 보완 기능에 가깝고, 애플리케이션이 Clash DNS를 완전히 우회한다면 스니핑이 도메인 규칙을 적용하는 핵심 수단이 될 수 있습니다. 같은 애플리케이션이 어떤 때는 도메인 규칙을 사용하고 어떤 때는 IP 또는 최종 규칙으로 빠진다면 서로 다른 연결이 서로 다른 해석 및 전송 경로를 사용하고 있다는 뜻인 경우가 많습니다.

검증할 때는 세 단계의 규칙을 준비하세요. 정확한 도메인 규칙 하나, 해당 IP 또는 지역 규칙 하나, 마지막으로 MATCH입니다. 대상에 접근한 뒤 어느 단계에서 매칭되었는지 확인합니다. 정확한 도메인 규칙이 계속 발동하지 않지만 연결 기록에는 올바른 도메인이 보인다면 규칙 순서와 철자를 확인하세요. 기록에 IP만 있다면 DNS 매핑과 스니핑을 확인하고, 연결 자체가 나타나지 않는다면 애플리케이션이 시스템 프록시 또는 TUN에 의해 인계되는지 점검하세요. 이런 비교가 웹 페이지가 열리는지만 확인하는 것보다 진단 가치가 높습니다.

그래픽 클라이언트에 따라 이 필드가 “도메인 스니핑”, “대상 덮어쓰기”, “순수 IP 해석” 등의 스위치로 나뉘거나 일부 기능만 제공될 수 있습니다. Clash Plus, Clash Verge Rev, FlClash 등 클라이언트의 설정 위치는 완전히 같지 않지만 최종적으로는 내보낸 실제 설정과 코어 로그를 기준으로 판단해야 합니다. 클라이언트를 옮길 때는 최소한의 스니핑 설정만 유지하고 현재 코어가 해당 필드를 인식하는지 확인한 다음 고급 옵션을 하나씩 복원하세요.

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

원격 구독은 노드 배포 문제를 해결하고, 로컬 오버라이드는 개인 정책을 장기간 보존하는 역할을 합니다. DNS, 규칙, 프록시 그룹과 실험적 매개변수를 구독 파일에 직접 기록하면 다음 업데이트에서 대부분 덮어써집니다. 업데이트를 완전히 막으면 노드 변경을 놓치게 됩니다. 더 나은 구조는 원격 구독을 입력으로, 로컬 오버라이드를 반복 적용 가능한 변환으로 취급하고 최종 실행 설정을 클라이언트 또는 변환 과정에서 생성하는 것입니다. 이렇게 하면 노드를 업데이트하면서도 개인 규칙과 네트워크 스택 설정을 유지할 수 있습니다.

교체, 추가와 앞에 삽입 구분

클라이언트마다 오버라이드 명칭은 완전히 같지 않지만 동작은 보통 세 가지로 나뉩니다. 최상위 필드를 교체하거나, 배열 끝에 항목을 추가하거나, 배열 앞에 항목을 삽입하는 방식입니다. DNS와 TUN 같은 완전한 객체는 명시적으로 교체하거나 깊이 병합하는 편이 적합합니다. 규칙 배열은 개인의 정확한 규칙을 앞에 두고 최종 규칙은 마지막에 남겨야 하며, 프록시 그룹은 이름을 기준으로 중복을 제거해야 하므로 두 배열을 단순히 이어 붙이면 안 됩니다.

가장 위험한 작업은 구독 원본 내용을 다시 포함하지 않은 채 전체 rules 또는 proxy-groups를 덮어쓰는 것입니다. 그러면 노드는 존재하지만 프록시 그룹에서 참조하지 않거나 규칙이 개인 항목 몇 개만 남을 수 있습니다. 수정하기 전에 현재 유효한 설정을 내보내고 오버라이드가 구독 업데이트 전후 어느 단계에서 실행되는지, 클라이언트의 병합 순서가 어떤지 확인하세요. 같은 스크립트라도 클라이언트마다 실행 시점이 달라 결과도 달라질 수 있습니다.

# 로컬 앞단 규칙 예시
rules:
  - DOMAIN,router.local,DIRECT
  - DOMAIN-SUFFIX,example.internal,DIRECT
  - DOMAIN-SUFFIX,developer.example,개발 서비스

# 로컬 DNS 오버라이드 예시
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query

YAML 병합에서는 앵커, 빈 값과 유형 변경도 문제가 됩니다. 원본에서는 배열인 필드를 오버라이드에서 객체로 작성하면 일반적으로 예상대로 병합되지 않습니다. null은 도구 구현에 따라 삭제를 의미할 수도 있고 단순히 빈 필드를 만들 수도 있습니다. 이식성을 높이려면 일반 매핑과 배열을 사용하고 특정 그래픽 클라이언트에만 있는 스크립트 인터페이스에 의존하지 마세요. 스크립트가 꼭 필요하다면 입력 구조, 처리 순서와 예상 출력을 함께 기록해야 합니다.

다중 구독은 먼저 이름을 분리

두 구독을 병합할 때 가장 흔한 문제는 노드 프로토콜이 아니라 이름 중복입니다. 양쪽 모두 “자동 선택”, “장애 조치”, “프록시” 같은 그룹 이름을 포함할 수 있고 노드 이름도 겹칠 수 있습니다. 단순히 이어 붙이면 나중에 나온 객체가 앞의 객체를 덮어쓰거나 프록시 그룹이 잘못된 노드를 참조할 수 있습니다. 안전한 방법은 각 출처에 고정 접두사를 붙이는 것입니다. 예를 들어 “주 구독 / 홍콩 01”과 “보조 구독 / 홍콩 01”처럼 이름을 분리한 뒤 로컬 프록시 그룹에서 통합해 참조하세요.

클라이언트가 proxy-providers를 지원한다면 여러 출처를 각각 제공자로 만들고 use와 filter로 지역 그룹을 구성할 수 있습니다. 모든 노드를 주 파일에 먼저 펼치는 방식보다 업데이트 경계가 명확하고, 한 출처가 실패해도 다른 출처의 캐시를 직접 손상시키지 않습니다. 제공자 이름, 캐시 경로와 상태 확인 주소는 각각 독립적으로 관리해야 합니다.

proxy-providers:
  provider-main:
    type: http
    url: https://example.com/subscriptions/main.yaml
    path: ./providers/main.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

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

proxy-groups:
  - name: 전체 출처
    type: select
    use:
      - provider-main
      - provider-backup
    proxies:
      - DIRECT

예시 주소는 필드 관계를 설명하기 위한 것입니다. 실제 구독 주소에는 접근 자격 증명이 포함되는 경우가 많으므로 스크린샷, 질문 게시물, 공개 저장소 또는 진단 파일에 붙여 넣어서는 안 됩니다. 설정을 공유하기 전에는 proxy-providers의 URL, 노드 서버 주소, 사용자 이름과 인증 필드를 삭제하고 구조 문제를 재현하는 데 필요한 최소 부분만 남기세요.

되돌릴 수 있는 설정 절차 만들기

큰 변경을 하기 전마다 세 가지를 보관하세요. 처리하지 않은 구독 입력, 로컬 오버라이드 파일, 최종 생성된 실행 설정입니다. 문제가 발생하면 먼저 최종 설정이 예상과 일치하는지 비교한 다음 구독 변경, 병합 로직 또는 코어 동작 중 원인을 판단하세요. 최종 파일만 보관하면 오류가 어느 단계에서 발생했는지 구분하기 어렵고 다음 구독 업데이트 후 같은 구성을 다시 만들기도 어렵습니다.

조정 과정은 일정한 순서를 따르는 것이 좋습니다. 먼저 하나의 구독을 업데이트하고 노드가 작동하는지 확인한 뒤 이름 필터와 제공자 상태 확인을 적용합니다. 다음으로 프록시 그룹을 추가하고 개인 규칙을 앞에 배치한 후 마지막에 DNS, TUN과 스니핑을 활성화하세요. 각 단계마다 설정을 다시 불러오고 로그를 확인해야 합니다. 최종 설정이 실패하더라도 어느 단계에서 처음 이상이 나타났는지 정확히 찾을 수 있습니다.

병합 후 “노드는 보이지만 선택할 수 없는” 경우에는 대개 프록시 그룹이 참조하는 객체가 존재하지 않는 것입니다. “업데이트 후 개인 규칙이 사라지는” 경우에는 오버라이드가 잘못된 단계에서 실행된 경우가 많고, “동일한 이름의 노드가 무작위로 바뀌는” 경우에는 출처별 이름 분리가 이루어지지 않은 경우가 많습니다. 문제를 클라이언트 화면에서 반복해서 삭제하고 다시 가져오기보다 입력, 변환, 출력의 세 계층으로 나누어 확인하는 편이 효과적입니다.

외부 컨트롤러와 안전한 원격 관리

외부 컨트롤러 인터페이스를 사용하면 그래픽 패널에서 프록시 그룹, 연결, 규칙, 로그와 제공자 상태를 읽을 수 있고 정책 전환, 제공자 업데이트와 연결 종료도 수행할 수 있습니다. 코어 실행과 관리 화면을 분리할 수 있어 서버, 라우터와 독립 코어 배포에서 자주 사용됩니다. 이 인터페이스에는 실제 제어 권한이 있으므로 일반 상태 페이지처럼 공용 네트워크에 노출해서는 안 됩니다.

수신 주소, 키와 패널 디렉터리

external-controller는 API 수신 주소를 정의합니다. 로컬에서만 사용할 때는 루프백 주소에 바인딩하는 것이 가장 안전합니다. LAN에서 접근해야 한다면 LAN 인터페이스 또는 모든 인터페이스에 바인딩할 수 있지만 방화벽으로 출처를 제한해야 합니다. secret은 컨트롤러 인증 정보이므로 충분히 길고 별도의 값을 사용하며 구독, 시스템 계정 또는 다른 서비스와 공유하지 마세요. external-ui는 로컬 정적 패널 디렉터리를 가리킵니다. 코어는 파일과 API를 제공할 뿐 디렉터리 내용의 신뢰성을 자동으로 보장하지 않습니다.

external-controller: 127.0.0.1:9090
secret: "your-password"
external-ui: ./dashboard
external-ui-name: metacubexd
external-ui-url: https://example.com/dashboard.zip

예시의 비밀번호와 패널 주소는 문법만 보여 주기 위한 것입니다. 실제 사용 시 비밀번호를 바꾸고 직접 확인한 출처에서 패널 파일을 가져오세요. 그래픽 클라이언트에 컨트롤러 패널이 이미 내장되어 있다면 일반적으로 원격 다운로드 주소를 다시 설정할 필요가 없습니다. 여러 인스턴스는 동일한 IP와 포트를 수신할 수 없습니다. 포트 충돌이 발생하면 나중에 시작한 코어가 바인딩 실패를 보고하고 패널에는 이전 인스턴스의 데이터가 계속 표시될 수 있어 설정이 적용되지 않았다고 오해하기 쉽습니다.

브라우저에서 로컬 패널에 접근할 때는 페이지 주소와 API 주소를 구분해야 합니다. 패널 파일은 특정 웹 서비스가 제공하고 API는 Clash 코어가 수신할 수 있습니다. 두 주소의 프로토콜, 호스트 또는 포트가 다르면 교차 출처 요청이 발생하며 허용 여부는 코어와 브라우저 정책에 따라 달라집니다. 패널은 열리지만 계속 연결할 수 없다고 표시된다면 먼저 로컬 컴퓨터에서 API 포트가 수신 중인지 확인하고, 그다음 패널에 입력한 컨트롤러 주소와 키를 점검하세요. 바로 코어를 재설치할 필요는 없습니다.

LAN 접근에 필요한 최소 공개 범위

휴대폰이나 다른 컴퓨터에서 관리해야 한다면 컨트롤러를 LAN 주소에 바인딩하고 시스템 방화벽에서 신뢰할 수 있는 사설 네트워크 대역만 허용할 수 있습니다. 라우터에서 컨트롤러 포트를 공용 포트로 전달하거나 약한 키를 사용하지 마세요. 공용 네트워크의 장치는 흔한 관리 포트를 능동적으로 검색할 수 있으며, 컨트롤러에 접근하면 연결 대상 확인, 정책 변경 또는 트래픽 중단이 가능해집니다.

더 안전한 원격 방식은 기존의 제어된 사설망, 기기 간 보안 터널 또는 시스템 원격 관리 기능을 통해 먼저 로컬 네트워크에 들어온 뒤 루프백 또는 LAN 인터페이스에 접근하는 것입니다. 이렇게 하면 컨트롤러를 인터넷에 직접 노출하지 않아도 됩니다. 리버스 프록시로 컨트롤러를 공개해야 한다면 접근 인증, 출처 제한과 WebSocket 처리를 올바르게 구성해야 합니다. 다만 프록시 계층이 하나 더 생기면 설정 복잡성도 커지므로 가정용 단일 컴퓨터에서는 필요하지 않습니다.

# Linux: 컨트롤러 포트가 루프백 주소에서만 수신하는지 확인
ss -lntp | grep 9090

# macOS: 수신 중인 프로세스 확인
lsof -nP -iTCP:9090 -sTCP:LISTEN

# Windows PowerShell: 포트 상태 확인
Get-NetTCPConnection -LocalPort 9090 -State Listen

컨트롤러로 연결 문제 찾기

패널의 가장 큰 가치는 원클릭 전환보다 연결, 규칙과 정책을 함께 관찰할 수 있다는 점입니다. 특정 사이트를 점검할 때는 대상 도메인 또는 프로세스로 연결을 필터링하고 매칭 규칙, 정책 체인과 최종 노드를 기록하세요. 그런 다음 해당 연결을 종료하고 애플리케이션이 새로 연결하도록 해야 수정 전 정책을 기존 연결이 계속 사용하는 일을 피할 수 있습니다. 그룹만 전환하고 연결을 다시 만들지 않으면 화면은 바뀌었지만 실제 요청은 이전 출구를 사용하는 것처럼 보일 수 있습니다.

제공자 페이지에서는 구독과 규칙 집합이 최근에 성공적으로 업데이트되었는지 확인할 수 있지만 “성공”만으로 내용이 올바르다고 판단할 수는 없습니다. 제공자 항목 수가 비정상적이지 않은지, 필터링 후 프록시 그룹이 비어 있지 않은지, 규칙 집합의 동작 유형이 일치하는지도 확인해야 합니다. 로그 페이지는 해석 실패, 인터페이스 바인딩 실패, 규칙 파일 읽기 오류와 노드 핸드셰이크 오류를 확인하는 데 적합합니다. 상세 로그를 장시간 유지하면 기록량과 개인정보 노출이 증가하므로 문제 해결 후 일반 로그 수준으로 되돌리세요.

설정 완료 후 전체 검증

고급 설정을 마친 뒤에는 무작위로 둘러보는 것보다 정해진 사례로 검수하는 편이 더 정확합니다. 먼저 직접 연결 사이트, 프록시 사이트와 LAN 장치를 확인하세요. 다음으로 브라우저, 명령줄과 시스템 프록시를 읽지 않는 애플리케이션 하나를 테스트하고, 이어서 DNS 조회, Fake-IP 매핑과 도메인 규칙을 점검합니다. 마지막으로 절전 모드 복귀, Wi-Fi 전환과 구독 업데이트를 확인하세요. 각 항목에 예상 정책과 실제 매칭 결과를 기록하고, 문제가 생기면 해당 장으로 돌아가 처리합니다.

설정을 불러오지 못할 때는 먼저 YAML 들여쓰기, 콜론 뒤 공백, 배열 계층과 중복 키를 확인하세요. 설정은 성공적으로 불러왔지만 트래픽이 없다면 시스템 프록시 또는 TUN 인계를 점검합니다. 트래픽은 있지만 정책이 잘못되었다면 도메인 정보, 규칙 순서와 프록시 그룹 참조를 확인하세요. 정책은 올바르지만 연결이 실패할 때 노드, 프로토콜과 대상 사이트를 점검해야 합니다. 이 순서를 따르면 모든 문제를 노드 탓으로 돌리는 일을 피할 수 있습니다.

문제가 어느 계층에 속하는지 여전히 판단하기 어렵다면 문제 해결의 설치·설정 및 장애 해결 분류를 확인하세요. 그래픽 클라이언트를 바꾸거나 다른 시스템에서 설정을 재현해야 한다면 클라이언트 다운로드 페이지에서 Windows, macOS, Android, iOS 또는 Linux 버전을 선택할 수 있습니다. 그래픽 인터페이스는 일상적인 전환과 관찰에 적합하지만 최종 판단은 실제 실행 설정, 연결 기록과 코어 로그를 기준으로 해야 합니다.