Clash 고급 설정가이드

프록시 그룹 유형과 활용

프록시 그룹은 규칙과 노드 사이에 있습니다. 규칙은 연결을 어느 그룹에 맡길지 결정하고, 그룹은 사용할 출구를 정합니다. 규칙이 노드를 직접 가리키면 단순하지만 노드 이름이 바뀔 때마다 참조를 수정해야 합니다. 업무별로 고정된 그룹을 규칙에서 참조하고, 그 그룹이 수동 선택 또는 자동 선택 그룹을 참조하도록 구성하면 관리가 편리합니다. 그룹은 실제 필요에 맞춰 구성하고, 웹사이트마다 같은 계층을 반복해서 만들 필요는 없습니다.

네 가지 유형의 용도

select는 수동 선택 그룹으로, 고정 출구가 필요하거나 일시적으로 문제를 진단할 때 적합합니다. url-test는 탐지 결과에 따라 출구를 자동으로 선택하므로 경로가 바뀌어도 되는 일반적인 연결에 적합합니다. fallback은 설정 순서에 따라 사용 가능한 항목을 선택합니다. 주 목적은 주·보조 경로이며 가장 빠른 경로를 항상 고르는 것은 아닙니다. load-balance는 여러 출구에 연결을 분산합니다. 단일 다운로드 연결의 대역폭을 여러 배로 합쳐 주지는 않습니다.

탐지 주소는 안정적이고 응답이 가벼우며 모든 후보 노드에서 접근할 수 있는 주소를 사용하세요. 주소 자체가 차단되면 그룹의 모든 노드가 비정상으로 표시될 수 있지만 실제 서비스에는 문제가 없을 수도 있습니다. 반대로 한 사이트에 연결되는 것을 확인했다고 해서 스트리밍 이용 권한, 업무 시스템 로그인, 지역 제한까지 해결되는 것은 아닙니다. 문제를 진단할 때 상태 확인과 실제 서비스 테스트 결과를 따로 기록하세요.

업무별 진입점 고정

아래 예제는 자동 선택 그룹을 수동 선택 그룹 안에 구성합니다. include-all은 전체 설정에 이미 포함된 프록시 후보를 가져옵니다. 사용 가능한 노드가 설정에 로드되어 있어야 합니다. 노드 공급원이 아니며 프록시를 새로 만들어 주지도 않습니다. 예제의 탐지 주소는 일반적인 연결 확인용입니다. 현재 네트워크에서 접근할 수 없다면 연결 가능 여부를 확인한 다른 경량 주소로 바꾸세요.

proxy-groups:
  - name: 자동 선택
    type: url-test
    include-all: true
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
  - name: 네트워크 출구
    type: select
    proxies:
      - 자동 선택
      - DIRECT

interval은 초 단위로 탐지 주기를 설정합니다. tolerance는 밀리초 단위의 전환 허용 오차로, 결과가 비슷한 경로 사이에서 잦은 전환을 줄이는 데 사용됩니다. 주기가 짧다고 반드시 좋은 것은 아닙니다. 백그라운드 요청이 늘고 일시적인 변동에 더 민감해질 수 있습니다. 노트북이나 모바일 네트워크에서는 우선 여유 있는 주기를 사용하고 로그를 살펴보세요. 속도 측정 빈도가 연결 품질을 보장하지는 않습니다.

프록시 공급자 목록을 사용한다면 이미 정의된 proxy-providers 이름을 use로 참조해 그룹에 노드 이름을 하나씩 쓰지 않을 수 있습니다. 공급자 이름과 노드 이름은 서로 다른 계층입니다. 공급자 이름은 노드 출처를 관리하고, 노드 이름은 실제 출구를 가리킵니다. 공급자에 필터 표현식을 적용할 때는 상위 출처에서 이름이 변경되거나 필터 결과가 비는 경우를 고려하세요. 수정 후에는 설정을 불러온 것만 확인하지 말고 후보 목록도 살펴봐야 합니다.

전환 조건과 복구 방법

자동 그룹 전환은 일반적으로 새 연결에 적용되며 이미 설정된 장기 연결은 즉시 이동하지 않을 수 있습니다. 웹페이지를 새로고침해도 기존 출구가 사용된다면 해당 앱의 연결을 종료한 뒤 다시 시도하세요. 프록시 그룹이 작동하지 않는다고 바로 판단할 필요는 없습니다. 동영상 재생, 터미널 세션, 업무 시스템은 출구 변경을 견디는 정도가 다릅니다. 접속 IP를 유지해야 하는 서비스에는 여러 지역을 자동으로 오가는 그룹보다 수동 고정 그룹이 더 적합합니다.

그룹끼리 서로 참조할 수 있지만 순환 참조를 만들면 안 됩니다. 예를 들어 ‘네트워크 출구’가 ‘업무’를 참조하고 ‘업무’가 다시 ‘네트워크 출구’를 참조하면 최종 출구를 정할 수 없습니다. 참조를 따라가며 마지막에 실제 노드나 DIRECT 같은 내장 정책에 도달하는지 확인하세요. 그룹 이름을 노드 이름과 똑같이 만들지 마세요. 인터페이스 표시와 규칙 대상을 구분하기 어려워집니다.

검증은 먼저 프록시 페이지에서 후보가 비어 있지 않은지 확인하고, 사용 가능한 노드를 하나 수동으로 고정한 다음 자동 선택을 활성화하는 순서로 진행하세요. 고정 노드는 작동하지만 자동 그룹이 실패한다면 탐지 주소, 필터 조건, 참조 계층을 확인하세요. 고정 노드도 실패한다면 노드 인증과 기본 네트워크부터 점검하고 그룹을 더 추가하지 마세요. 인터페이스 사용법은 프록시·설정·로그 페이지 안내를 참고하세요.

DNS 설정과 조회 경로

DNS 설정에서는 세 가지를 확인해야 합니다. 앱의 조회를 누가 받는지, 상위 DNS 서버가 어디인지, 조회 요청이 어떤 네트워크 경로로 전송되는지입니다. 상위 주소를 암호화 DNS로 바꾸는 것만으로 모든 앱의 DNS 조회가 코어를 거치는 것은 아닙니다. 브라우저 보안 DNS, 시스템 캐시, 앱 내장 리졸버, 로컬 네트워크 게이트웨이가 우회 경로가 될 수 있습니다. Clash DNS 누수를 점검하기 전에 현재 기기의 실제 조회 경로를 먼저 정리하세요.

수신, 부트스트랩, 일반 조회 구분

listen은 코어 DNS 서비스의 수신 주소를 지정합니다. nameserver는 일반 조회에 사용하는 상위 DNS 서버입니다. default-nameserver는 상위 DNS 서버 자체의 도메인을 조회하는 부트스트랩 등에 사용하며, 실패한 모든 조회를 자동으로 넘기는 범용 백업 서버가 아닙니다. 호스트 이름이 있는 HTTPS 리졸버는 자신의 주소를 알아내기 위해 먼저 조회가 필요합니다. 리졸버에 접속해야 리졸버의 주소를 알 수 있는 순환 문제를 피하세요.

아래는 로컬 진단을 위해 별도의 루프백 포트를 사용하는 DNS 설정 예제입니다. 운영체제의 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
  nameserver:
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    '+.example.com':
      - 223.5.5.5

예제 주소는 설정 구조를 보여주기 위한 것입니다. 실제 서버 선택은 통신사 네트워크, 지역, 접속 정책을 고려하세요. nameserver-policy로 특정 도메인의 리졸버를 지정하면 내부 DNS 조회나 특정 지역 결과가 필요한 경우에 유용합니다. 업무 도메인 전체를 공용 리졸버에 맡기면 내부 주소가 반환되지 않을 수 있습니다. 매칭 범위는 가능한 한 좁게 설정하고 도메인 하나부터 확인한 뒤 하위 도메인으로 확대하세요.

DNS 조회와 출구 정책 연동

DNS 연결이 라우팅 규칙을 따르게 하려면 respect-rules를 검토하고 노드 서버의 호스트 이름을 조회할 proxy-server-nameserver도 올바르게 설정하세요. 그렇지 않으면 노드 주소를 알아내려면 프록시가 필요한데 프록시를 연결하려면 노드 주소가 필요한 순환 문제가 생길 수 있습니다. 모든 구독에 적용되는 단일 옵션 조합은 없습니다. 아직 연결되지 않은 프록시에 의존하지 않는 부트스트랩 경로를 하나 이상 확보하는 것이 핵심입니다.

direct-nameserver는 직접 연결 출구에 필요한 DNS 조회에 사용할 수 있습니다. 도메인 정책과 함께 사용한다면 nameserver-policy를 따르는지도 확인하세요. 동작을 살펴보지 않은 상태에서 여러 nameserver, fallback, 정책 매핑을 한꺼번에 지정하지 마세요. 설정이 복잡해지면 같은 도메인에 여러 조회가 발생할 수 있고 응답 출처를 추적하기도 어려워집니다.

기존의 fallback과 fallback-filter는 DNS 응답을 선택하는 방식입니다. ‘첫 번째 DNS가 시간 초과되면 두 번째 DNS를 요청한다’고 단순하게 이해하면 안 됩니다. 필터 조건, 지리 정보, 후보 응답이 최종 결과에 영향을 줍니다. 현재 환경에서 명시적인 도메인 정책으로 문제가 해결된다면 설정을 단순하게 유지하세요. 오염이나 비정상 응답이 재현되는 경우에만 실제 사례를 바탕으로 필터 조건을 설계하세요.

응답 결과와 요청 경로를 따로 확인

dig가 설치된 환경에서는 아래 명령으로 로컬 수신 서버를 조회할 수 있습니다. Windows 기본 도구는 기본 포트가 아닌 경우 지원 방식에 차이가 있을 수 있으므로 시스템 DNS 조회 결과를 로컬 코어 조회 결과로 착각하지 마세요. 조회 시간과 응답 유형, 로그에 표시된 상위 DNS 선택, 앱 연결을 함께 기록해야 근거를 온전히 확인할 수 있습니다.

dig @127.0.0.1 -p 1053 example.com A

Fake-IP 모드에서 가상 주소가 반환되는 것은 정상 동작입니다. 공용 DNS 결과와 다르다는 이유만으로 조회 오류라고 판단하면 안 됩니다. IPv6도 코어 전체 설정, DNS의 AAAA 응답, 시스템 IPv6 라우팅, 노드의 전송 지원 여부를 구분해야 합니다. 예제에서 DNS의 IPv6 응답을 끄는 것은 초기 진단 변수를 줄이기 위한 것이며 모든 네트워크에서 IPv6를 영구적으로 끄라는 뜻은 아닙니다.

일반적인 DNS 누수 테스트는 특정 웹 요청에서 사용된 조회 출처를 확인할 뿐 모든 앱과 프로토콜을 검사하지는 않습니다. 브라우저에서 별도의 보안 DNS를 사용한다면 해당 설정을 따로 확인하세요. 기업 기기에는 조직에서 관리하는 정책이 적용될 수도 있습니다. 특정 테스트 페이지를 통과하려고 시스템 설정을 계속 바꾸지 마세요. 먼저 보호 범위와 조회 가로채기 범위를 정한 뒤 로그, 라우팅, 앱 동작을 교차 확인하세요.

도메인 스니핑과 인식 범위

도메인 스니핑은 연결이 코어에 들어온 뒤 일부 프로토콜의 초기 데이터에서 대상 호스트 정보를 추출합니다. 일반적인 정보 출처로 HTTP의 Host와 TLS 핸드셰이크의 서버 이름이 있습니다. 대상 IP만 있는 연결에 도메인 규칙을 적용하는 데 도움이 될 수 있지만 DNS를 대신하거나 모든 암호화 트래픽을 인식하는 기능은 아닙니다. 완전한 앱 식별 기능이라기보다 보조 정보로 보는 것이 정확합니다.

트래픽이 들어와야 인식할 수 있습니다

스니핑은 코어가 이미 수신한 연결만 처리합니다. 앱이 시스템 프록시를 우회하고 TUN에도 들어오지 않는다면 스니핑을 켜도 트래픽이 자동으로 들어오지 않습니다. 반대로 연결에 이미 신뢰할 수 있는 도메인 정보가 있다면 추가 스니핑이 필요하지 않을 수 있습니다. 문제를 진단할 때는 먼저 클라이언트 연결 페이지에 해당 연결이 표시되는지 확인한 뒤 도메인 필드, 적용 규칙, 최종 출구를 살펴보세요. 처음부터 스니핑 대상 포트를 확대하지 마세요.

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

예제는 일반적으로 사용하는 프로토콜 포트로 스니핑 범위를 제한하고 원래 대상 주소를 덮어쓰지 않아 인식 결과를 먼저 확인할 수 있습니다. 포트는 프로토콜이 사용할 수 있는 위치일 뿐, 실제 데이터가 해당 프로토콜임을 보장하지 않습니다. 443번 포트에서도 다른 프로토콜이 사용될 수 있습니다. 모든 포트를 스니핑하면 불필요한 처리가 늘고 비표준 서비스의 호환성 문제를 찾기 어려워집니다. 실제 업무에 따라 범위를 점진적으로 넓히세요.

도메인 인식과 대상 주소 변경은 별개입니다

override-destination은 스니핑한 결과로 연결 대상을 덮어쓸지 결정합니다. 지정 IP에 의존하는 서비스는 주소를 바꾸면 다른 서버에 연결될 수 있고, CDN을 사용하는 사이트는 다시 조회하면서 서버 선택이 달라질 수 있습니다. 분할 판단만 개선하려는 목적이라면 먼저 대상 주소를 유지하고 연결 기록으로 규칙 동작을 확인하세요. 실제로 주소를 덮어써야 하는 경우에만 해당 옵션을 사용하면 됩니다.

parse-pure-ip를 활성화하면 IP만 대상으로 하는 일부 트래픽도 스니핑할 수 있지만, 인식 여부는 프로토콜에 읽을 수 있는 도메인이 포함되어 있는지에 달려 있습니다. IP로 직접 접속하는 HTTP 요청에는 기대하는 도메인이 없을 수 있고 TLS에도 서버 이름이 없을 수 있습니다. 앱 자체 암호화 프로토콜은 HTTP, TLS, QUIC 분석 방식에 맞지 않을 수 있습니다. 실패하더라도 ‘HTTPS에 접속했다’는 이유만으로 반드시 인식될 것이라고 판단하면 안 됩니다.

특정 연결의 스니핑을 강제하거나 건너뛰려면 force-domain, skip-domain 등의 설정으로 범위를 지정할 수 있습니다. 예외는 재현 가능한 서비스에 한정하고 출처를 모르는 도메인 목록을 통째로 복사하지 마세요. 공유 IP, 리버스 프록시, 내부 게이트웨이가 있는 환경에서는 인식된 이름이 연결의 최초 목적을 뜻하지 않을 수 있으므로 원래 대상도 함께 확인해야 합니다.

암호화 프로토콜과 개인정보 보호의 한계

일부 TLS 환경에서는 암호화된 클라이언트 인사말 등의 기능으로 기존 서버 이름 추출이 작동하지 않을 수 있습니다. QUIC는 UDP 기반이라 TCP와 프로토콜 처리 방식이 다르고 노드의 UDP 지원, 라우팅, 네트워크 정책의 영향도 받습니다. 브라우저에서는 접속되지만 클라이언트가 도메인을 인식하지 못할 수 있습니다. 반드시 설정 오류인 것은 아닙니다. 다른 신뢰할 수 있는 정보로 규칙이 정상적으로 작동한다면 모든 연결에 도메인 이름이 표시될 필요는 없습니다.

스니핑은 HTTPS 본문을 복호화하지 않으므로 일반적인 도메인 인식을 위해 기기에 자체 서명 루트 인증서를 설치할 필요가 없습니다. 사용자의 로그인 비밀번호나 웹페이지 내용도 읽지 않습니다. 다만 도메인 이름만으로도 방문 의도를 알 수 있으므로 로그를 내보내거나 대시보드를 공유할 때는 주의하세요. 문제를 공유할 때 개인 도메인, 구독 정보, 노드 인증 정보를 제거하고 규칙 문제를 재현하는 데 필요한 내용만 남기세요.

검증할 때는 도메인을 하나 선택해 스니핑을 끈 상태와 켠 상태에서 각각 새 연결을 만들고 도메인 필드와 규칙 적용 결과를 비교하세요. 웹페이지가 열리는지만 확인하면 안 됩니다. 두 경우 모두 같은 기본 규칙을 사용해 접속에 성공했을 수 있습니다. 활성화 후 접속에 문제가 생기면 먼저 대상 주소 덮어쓰기를 끄고 포트 범위를 좁히세요. 여전히 문제가 있으면 스니핑을 잠시 끄고 DNS 매핑과 규칙 설정부터 확인하세요.

금융 서비스 로그인, 기업 내부망, 고정 주소를 사용하는 서비스에서는 인식 범위를 넓히는 것보다 안정성이 중요합니다. 명확한 주소 규칙이나 도메인 규칙을 유지하고 호환되지 않는 서비스에는 좁은 범위의 예외를 설정할 수 있습니다. 스니핑 설정의 기준은 ‘모든 연결에 이름이 표시되는가’가 아니라 ‘대상 서비스가 예상대로 분할되고 문제가 발생하지 않는가’여야 합니다. 화면을 보기 좋게 만들려고 실제 사용성을 희생하지 마세요.

외부 제어 대시보드와 보안 범위

외부 제어 대시보드는 mihomo 제어 인터페이스를 통해 실행 상태를 읽고 프록시 그룹을 전환하거나 연결을 확인합니다. 프록시 연결 지점도 구독 서버도 아닙니다. 혼합 포트는 앱 트래픽을 처리하고 제어 포트는 관리 작업을 처리하므로 서로 바꿔 쓸 수 없습니다. 대시보드가 열리지 않으면 정적 페이지 로드, 제어 인터페이스 연결, 인증 성공 여부를 각각 확인하세요. 인터넷에 연결하는 혼합 포트를 바로 변경하지 마세요.

로컬 관리에는 루프백 수신 사용

데스크톱 클라이언트에 내장된 인터페이스를 사용한다면 일반적으로 별도의 제어 포트를 열 필요가 없습니다. 로컬 대시보드를 연결해야 한다면 먼저 루프백 주소를 사용해 관리 인터페이스가 로컬 네트워크에 노출되지 않도록 하세요. 아래 인증 정보는 교육용 예시일 뿐입니다. 실제로 사용할 때는 직접 생성한 강력한 비밀번호로 바꾸고 로컬에만 보관하세요. 다른 기기에서 접근할 수 있는 서비스에 예시 값을 사용하면 안 됩니다.

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

external-ui는 준비된 대시보드 정적 파일 디렉터리를 가리키며 코어 작업 디렉터리를 기준으로 해석됩니다. 설정만으로 대시보드 파일이 생성되지는 않습니다. 디렉터리는 있지만 진입 파일이 없으면 인터페이스는 정상이어도 페이지에서 오류가 발생할 수 있습니다. 신뢰할 수 있는 프로젝트 출처에서 대시보드 파일을 받아 안내에 따라 로컬에 배포하세요. 알 수 없는 웹페이지에 입력하는 제어 인증 정보를 일반 사이트 로그인 정보처럼 취급하지 마세요.

127.0.0.1에 바인딩하면 해당 주소를 통해 로컬 기기에서만 접근할 수 있습니다. 모든 인터페이스에서 수신하도록 변경하면 로컬 네트워크나 그 밖의 연결 가능한 네트워크에서도 포트에 접근할 수 있습니다. 실제로 연결 가능한지는 방화벽과 네트워크 구성에 따라 달라집니다. 한편 allow-lan은 주로 프록시 수신 범위를 제어하며 제어 인터페이스 전체를 관리하는 옵션이 아닙니다. 이 값을 꺼도 제어 포트의 수신 및 접근 제한을 대신할 수는 없습니다.

연결, 인증, 브라우저 제한을 구분

인터페이스 연결이 거부되면 코어 실행 여부, 수신 주소, 포트 사용 여부를 먼저 확인하세요. 연결은 되지만 인증되지 않았다는 응답이 돌아온다면 방화벽을 계속 조정하기보다 대시보드에 저장된 제어 비밀번호를 확인하세요. 페이지는 표시되지만 데이터를 가져오지 못한다면 브라우저의 교차 출처 제한이나 페이지와 인터페이스 주소 불일치가 원인일 수 있습니다. 브라우저 개발자 도구에서 실제 요청 결과를 확인하세요.

HTTPS 페이지에서 HTTP 제어 인터페이스에 접근하면 혼합 콘텐츠 제한이 발생할 수 있습니다. 교차 출처 설정이 필요하지 않도록 같은 기기에서 같은 출처로 로컬 배포하는 방식을 우선 사용하세요. 리버스 프록시가 필요하다면 TLS, 인증, 출처 제한을 각각 어느 계층에서 처리할지 명확히 정합니다. 브라우저 오류를 없애려고 모든 출처를 허용하지 마세요. 제어 비밀번호를 공개 URL에 넣으면 방문 기록, 로그, 공유 내용에 남을 수 있습니다.

여러 기기에서 관리해야 한다면 관리되는 보안 터널을 사용하거나 신뢰할 수 있는 관리 네트워크에서만 접근하도록 설정하고 시스템 방화벽으로 허용 기기 범위를 좁히세요. 제어 인터페이스를 인터넷에 직접 공개하면 상태 확인뿐 아니라 사용 중인 정책과 설정까지 변경될 수 있어 위험이 커집니다. 비밀번호 하나만 설정했다고 전송 암호화, 무차별 대입 공격, 대시보드 출처의 신뢰성까지 해결되는 것은 아닙니다.

설정 변경 후 검증 절차 완료

대시보드에서 그룹을 전환한 뒤 클라이언트 인터페이스와 새 연결의 실제 출구가 함께 바뀌었는지 확인하세요. 대시보드에서 실행 모드를 변경했다면 현재 규칙 검증에 영향이 있는지도 살펴봅니다. 대시보드 표시, 설정 파일, 실행 상태가 항상 동일하게 유지되지는 않습니다. 일부 선택은 클라이언트에 저장되지만 일부는 다시 불러올 때 덮어써질 수 있습니다. 계속 적용해야 하는 매개변수는 제어 인터페이스에서 임시 변경하는 대신 관리 위치가 명확한 설정에 반영하세요.

로그는 문제 해결에 필요한 최소 범위로 유지하세요. 디버깅할 때만 일시적으로 상세도를 높이고 재현이 끝나면 평소 수준으로 되돌려 방문 도메인이 장시간 대량 기록되지 않도록 합니다. 자료를 공유하기 전에 노드 인증 정보, 구독 링크, 제어 비밀번호, 개인 접속 기록을 확인하세요. 관리 인증 정보가 공개되었다면 실제 사용 중인 값을 변경하고 대시보드에 저장된 이전 값도 삭제해야 합니다. 스크린샷에서 글자만 지우는 것으로는 충분하지 않습니다.

가이드 전체의 최종 점검은 다음 순서로 진행하세요. 설정을 불러올 수 있는지, 노드 출처를 사용할 수 있는지, 프록시 그룹 참조가 완결되는지, 규칙이 올바르게 일치하는지, DNS 경로가 명확한지, TUN이 예상대로 트래픽을 처리하는지, 스니핑으로 호환성 문제가 생기지 않는지, 제어 인터페이스가 필요한 범위에서만 접근 가능한지 확인합니다. 한 번에 변수 하나만 바꾸고 되돌릴 지점을 남겨 두면 매개변수를 계속 추가하는 것보다 관리하기 쉽습니다. 원인을 찾기 어렵다면 민감 정보를 가린 로그와 함께 문제 해결 분류에서 증상별로 확인하세요.