Clash 고급 설정 가이드

프록시 그룹 유형과 트래픽 분기 실전

규칙, 프록시 그룹, 노드를 구분하세요

규칙은 연결을 어디로 보낼지 정하고, 프록시 그룹은 다음에 어떤 출구를 선택할지 결정하며, 노드는 실제 프록시 연결을 담당합니다. 서로 다른 설정 계층입니다. 모드를 규칙 모드로 바꾸면 연결은 규칙 순서대로 매칭된 뒤 대상 프록시 그룹으로 전달됩니다. 프록시 그룹이 다른 그룹을 참조할 수도 있으며, 마지막에 노드 또는 내장 정책인 DIRECT, REJECT가 선택됩니다. 따라서 규칙에 PROXY가 매칭되었다고 해서 특정 노드를 통해 연결된 것은 아닙니다. 프록시 체인을 펼쳐 최종 선택을 확인하세요.

설정에서 이름은 문자열로 참조되므로 대소문자, 공백, 문장 부호까지 일치해야 합니다. 그룹 이름을 “자동 선택”에서 “자동”으로 바꾸면 해당 그룹을 참조하는 규칙과 다른 그룹의 이름도 함께 수정해야 합니다. proxy not found와 같은 오류가 발생하면 구독을 반복해서 업데이트하기보다 누락된 이름부터 찾으세요. 일부 인터페이스는 이전에 수동 선택한 항목을 유지합니다. 그룹 구조를 바꾸면 이전 선택이 더는 유효하지 않을 수 있으므로 다시 불러온 뒤 현재 출구를 확인하세요.

수동 선택, 자동 선택, 장애 조치

select는 출구를 직접 제어해야 하는 경우에 적합합니다. 선택은 사용자가 결정하며 일반적으로 탐지 결과에 따라 자동으로 바뀌지 않습니다. url-test는 후보를 대상으로 연결 상태를 테스트하고 허용 오차 등의 조건에 따라 테스트 결과가 적절한 후보를 선택합니다. fallback은 후보의 설정 순서를 우선합니다. 앞쪽 후보가 사용 가능하면 이를 먼저 선택합니다. load-balance는 지정한 방식으로 연결을 분배하며, 파일 하나를 전송할 때 여러 회선으로 자동 분할하는 기능은 아닙니다.

아래는 프록시 그룹 구성 예제입니다. 기존 proxies 또는 노드 제공자에 “노드-A”와 “노드-B”가 있다고 가정합니다. 두 이름은 예시이므로 실제 사용할 때는 실행 설정에 있는 이름으로 바꾸세요. 테스트 주소는 연결 상태를 확인하기 위한 대상이며 실제 서비스 사이트를 의미하지 않습니다. 해당 주소가 현재 네트워크에서 별도로 차단되면 자동 선택 결과가 부정확할 수 있습니다. 먼저 수동 선택으로 연결이 되는지 확인한 다음 자동 선택을 추가하면 문제 발생 계층을 더 쉽게 찾을 수 있습니다.

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - 자동 선택
      - 노드-A
      - 노드-B
  - name: 자동 선택
    type: url-test
    proxies:
      - 노드-A
      - 노드-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

잦은 전환보다 안정적인 출구가 중요할 때

interval은 테스트 간격을 초 단위로 지정합니다. tolerance는 자동 선택 시 전환 허용 폭을 설정해 작은 변동만으로 출구가 바뀌지 않도록 합니다. lazy는 사용하지 않는 그룹의 불필요한 테스트를 줄일 수 있습니다. 모든 그룹의 간격을 지나치게 짧게 설정하지 마세요. 노드 제공자도 자체 상태 확인을 할 수 있습니다. 두 계층의 테스트가 동시에 자주 실행되면 요청량과 모바일 기기의 백그라운드 부담만 늘어날 뿐, 웹페이지가 더 빨리 열린다는 보장은 없습니다.

로그인 서비스, 결제 페이지, 장시간 유지되는 세션에는 보통 고정된 정책이 적합합니다. 자동으로 출구가 바뀌면 같은 계정이 짧은 시간에 서로 다른 출구를 사용해 서비스 측의 위험 관리에 걸릴 수 있습니다. 업무별로 별도의 수동 그룹을 만들고 관련 도메인 규칙을 해당 그룹에 연결하면 자동 선택을 전역에서 끄는 것보다 정확합니다. 로드 밸런싱을 사용한다면 선택한 분배 방식과 세션 유지의 관계를 이해하고, 연결마다 다른 출구를 사용할 수 있다는 점을 감안하세요.

검증할 때는 연결 페이지에서 대상 도메인을 찾아 매칭된 규칙, 프록시 그룹, 최종 노드를 기록하세요. 그런 다음 정상 작동이 확인된 다른 노드를 수동으로 선택하고 기존 연결을 닫은 뒤 다시 접속합니다. 이미 맺어진 TCP 연결은 그룹을 바꿔도 일반적으로 자동으로 이동하지 않습니다. 연결에 이전 출구가 계속 표시되면 연결 재사용인지 설정 미적용인지 먼저 구분하세요. 새 출구로 표시되는데도 실패한다면 대상 서비스, 노드 연결 상태, DNS를 확인하고 모든 문제를 프록시 그룹 탓으로 돌리지 마세요.

룰셋 구독 관리

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

mihomo의 일반 규칙 목록은 대개 위에서 아래로 확인하며, 일치하는 규칙을 찾으면 지정된 정책으로 연결을 전달합니다. 구체적인 예외 규칙은 범위가 넓은 규칙보다 위에 두고, 마지막에는 MATCH를 기본 규칙으로 배치하세요. 특정 도메인에 프록시를 지정했더라도 그 위에 더 광범위한 직접 연결 규칙이 있으면 예외가 적용되지 않습니다. 문제를 확인할 때는 연결 상세 정보에서 실제로 매칭된 규칙부터 살펴보세요. 요청에 포함된 도메인이나 대상 IP와 규칙 순서를 확인하고, 파일에서 사이트 이름만 검색하는 데 그치지 마세요.

DOMAIN은 완전한 도메인과 일치합니다. DOMAIN-SUFFIX는 지정한 접미사와 하위 도메인에 일치합니다. DOMAIN-KEYWORD는 문자열에 키워드가 포함되어 있는지만 확인하므로 범위가 넓어지기 쉽습니다. 알고 있는 서비스에는 완전한 도메인이나 명확한 접미사 규칙을 우선 사용하세요. 웹페이지 하나가 로그인, 정적 리소스, API 도메인에 동시에 접속할 수 있으므로 첫 페이지의 도메인만 처리해서는 전체 동작을 포괄하지 못할 수 있습니다. 연결 기록을 확인해 실제 의존 도메인을 추가하고, 모든 연결을 곧바로 전역 모드로 전환하지 마세요.

규칙 내용과 규칙 적용 위치를 분리하세요

rule-providers는 규칙 내용의 출처를 선언하고, RULE-SET은 이를 어느 위치에서 사용할지와 적용할 정책을 지정합니다. 이렇게 분리하면 규칙 파일을 따로 업데이트하고 기본 설정에는 명확한 실행 순서만 남길 수 있습니다. 아래 예제는 구조를 먼저 확인하기 위한 로컬 파일 방식입니다. 클라이언트 설정 작업 디렉터리 아래에 rules/local-direct.yaml 파일을 저장하세요. 클라이언트의 실행 디렉터리가 샌드박스에 있다면 지원되는 파일 관리 기능으로 실제 위치를 확인해야 합니다.

rule-providers:
  local-direct:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-direct.yaml

rules:
  - DOMAIN,example.com,DIRECT
  - RULE-SET,local-direct,DIRECT
  - MATCH,PROXY

위 기본 설정 예제의 PROXY는 이미 정의되어 있어야 합니다. 다음은 이에 대응하는 로컬 규칙 파일 내용입니다. example.org는 접미사 규칙을 설명하기 위한 예시이며, 실제로 관리할 때는 직접 연결할 도메인을 입력하세요. 도메인 형식 룰셋은 일반 규칙 목록이 아니므로 각 항목에 정책 이름을 넣으면 안 됩니다. 작은 룰셋부터 정확히 매칭되는지 확인한 뒤 많은 규칙을 옮기면 경로, 형식, 내용 오류를 따로 해결하기 쉽습니다.

payload:
  - '+.example.org'
  - 'example.net'

올바른 behavior와 업데이트 방식 선택

behavior: domain은 도메인 집합에, ipcidr은 IP 주소 대역 집합에 사용합니다. classical은 규칙 유형을 포함한 기존 형식의 규칙을 표현할 수 있습니다. 규칙 제공자의 format도 파일 형식과 일치해야 하며, 확장자만으로 내용 형식을 판단할 수는 없습니다. DOMAIN-SUFFIX,example.org를 도메인 형식 집합에 그대로 넣거나 정책 이름이 포함된 규칙 전체를 클래식 집합에 넣으면 파싱 오류가 나거나 예상과 다른 방식으로 매칭될 수 있습니다.

원격으로 관리한다면 제공자 유형을 type: http로 설정하고 신뢰할 수 있는 규칙 소스가 실제 제공하는 url, 개별 path, 적절한 interval을 입력하세요. 여러 제공자가 캐시 파일 하나를 공유하게 하지 마세요. 한쪽을 업데이트할 때 다른 룰셋이 덮어써질 수 있습니다. 규칙 소스가 바뀌면 먼저 내용을 일부 확인해 도메인 목록 대신 웹페이지나 오류 메시지가 내려오지 않는지 살펴본 뒤 클라이언트에서 제공자를 업데이트하세요. 설정을 다시 불러오는 것만으로 모든 원격 파일이 다시 다운로드되는 것은 아닙니다.

매칭 경로를 따라 룰셋 문제 확인

규칙이 적용되지 않으면 먼저 실행 모드가 규칙 모드인지 확인한 뒤 제공자가 로드되었는지, 이름이 RULE-SET 참조와 일치하는지, 위쪽 항목에 먼저 매칭되지 않았는지 살펴보세요. IP 규칙의 no-resolve는 해당 IP 규칙을 위해 도메인을 새로 조회하지 않도록 합니다. 도메인 규칙을 IP 규칙으로 바꾸거나 시스템의 DNS 조회를 완전히 중지하는 옵션은 아닙니다. 대상 IP가 이미 있는 연결은 IP 규칙에 매칭될 수 있으므로 연결 상세 정보를 기준으로 결과를 확인하세요.

GEOIP는 해당 지리 정보 데이터베이스에 의존합니다. 룰셋 파일이 정상이어도 데이터베이스는 정상적이지 않을 수 있습니다. GeoIP 관련 오류가 발생하면 로그에서 파일 경로와 다운로드 실패 원인을 확인하고 클라이언트가 제공하는 데이터베이스 업데이트 기능을 사용하세요. 설정 디렉터리 전체를 반복해서 삭제하지 마세요. “규칙은 늘어나는데 문제를 찾기 어려운” 상황이라면 로컬 예외, 업무별 그룹, 공통 규칙, 최종 기본 규칙의 네 계층으로 정리한 뒤 하나씩 검증하세요. 기본 개념은 용어집에서, 구체적인 문제 해결 방법은 도움말 센터에서 확인할 수 있습니다.

DNS 설정 최적화와 조회 경로

누가 누구에게 조회하는지 먼저 정리하세요

DNS 문제를 확인할 때는 앱, 운영체제, mihomo, 상위 DNS 서버를 구분해야 합니다. 브라우저에 자체 보안 DNS가 켜져 있을 수 있고, 시스템에 수동 설정한 서버가 남아 있을 수 있으며, TUN이 일부 DNS 요청을 가로챌 수도 있습니다. nameserver를 바꿔도 웹페이지에 변화가 없다면 항목이 무효인 것이 아니라 요청이 mihomo를 거치지 않았을 수 있습니다. 먼저 클라이언트 로그에서 대상 도메인 조회를 확인한 다음 시스템 DNS, 브라우저 설정, 트래픽 처리 방식을 조정하세요.

도메인 형식의 암호화 DNS 서버는 서버 주소를 조회하는 과정도 먼저 필요합니다. 이를 부트스트랩 조회라고 합니다. default-nameserver는 이와 관련된 부트스트랩 과정에 쓰이며 모든 서비스 조회의 첫 번째 서버를 의미하는 것은 아닙니다. 노드 서버가 도메인으로 지정되어 있다면 proxy-server-nameserver도 확인하세요. 노드 연결 전에 노드 도메인을 조회해야 하고, 조회를 위해서는 먼저 프록시에 연결해야 하는 순환 문제가 생기지 않도록 해야 합니다. 프록시 시작 여부와 서비스 도메인의 정상적인 조회 여부는 따로 검증하세요.

명확한 DNS 서버 몇 개부터 시작하세요

아래는 부트스트랩 조회, 서비스 도메인 조회, 노드 도메인 조회의 역할을 나눈 DNS 설정 예제입니다. 모든 네트워크에서 그대로 쓸 수 있는 정답은 아닙니다. 공용 DNS 서버에 연결할 수 있는지, 현재 네트워크에서 사용할 수 있는지 직접 테스트해야 합니다. 예제에는 로컬 수신 주소가 설정되어 있지 않습니다. 시스템이나 다른 장치에서 mihomo DNS에 직접 접근해야 한다면 listen을 별도로 설정하고 포트 사용 여부, 권한, 방화벽을 함께 확인하세요. 수신 항목만 추가한 뒤 LAN에 무작정 개방하지 마세요.

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  fake-ip-filter:
    - '*.lan'
    - '*.local'

dns.ipv6: false는 해당 DNS 모듈이 AAAA 조회를 처리하는 방식에 영향을 줍니다. 운영체제에서 IPv6를 끄는 설정이 아니며 모든 IPv6 트래픽을 가로챈다고 보장하지도 않습니다. 시스템에 IPv6 경로가 남아 있으면 앱이 캐시나 다른 조회 경로를 통해 IPv6를 사용할 수 있습니다. 실행 설정 최상위의 IPv6 항목, TUN 경로, 연결 기록도 함께 확인하고 DNS 스위치 하나로 전체 네트워크 동작을 설명하려 하지 마세요.

도메인별로 정책을 설정하고 불필요한 대체 경로는 줄이세요

nameserver-policy는 지정한 도메인을 특정 DNS 서버로 보내며 사내 도메인이나 별도의 조회 요구가 있는 서비스에 적합합니다. 사내 DNS 서버는 사무실 네트워크에 연결해야만 접근할 수 있는 경우가 많습니다. 이를 모든 도메인의 상위 서버로 설정하면 사무실 밖에서 전체 조회가 시간 초과될 수 있습니다. 내부 도메인 범위를 한정하고 올바른 네트워크 인터페이스를 통해 조회되는지 확인하는 편이 안전합니다. 해당 도메인에 직접 연결 규칙도 필요한지는 대상 주소에 연결할 수 있는지 따로 확인해 결정하세요.

DNS 서버를 많이 지정한다고 반드시 안정성이 높아지는 것은 아닙니다. fallback과 필터 조건이 결과 선택에 함께 영향을 주므로 목록 순서만 보고 “첫 번째 서버가 실패해야 두 번째 서버에 질의한다”고 판단하면 안 됩니다. respect-rules로 DNS 연결이 라우팅 규칙을 따르게 한다면 노드 도메인 조회와 규칙 간의 의존성도 고려해 독립적으로 작동하는 노드 조회 경로를 유지해야 합니다. 분명한 요구가 없다면 연결 가능한 상위 서버 몇 개부터 사용하고, 안정적으로 작동한 뒤 도메인별 정책을 추가해 서로 얽힌 의존성을 줄이세요.

DNS 오류와 연결 오류를 구분하세요

문제를 확인할 때는 “조회 요청을 받았는지, 결과를 반환했는지, 대상에 연결할 수 있는지”의 세 단계로 살펴보세요. 조회가 시간 초과되면 DNS 서버 연결 상태를 우선 확인합니다. 주소를 받았지만 TCP 연결이 시간 초과되면 프록시 정책, 출구, 라우팅을 확인하세요. 특정 브라우저에서만 실패한다면 해당 브라우저의 별도 DNS, 프록시 설정, 캐시를 확인합니다. Fake-IP 모드에서 예약 주소가 보이는 것은 정상 동작일 수 있습니다. 이를 곧바로 DNS 오염으로 단정하거나 서비스 도메인을 해당 주소에 수동으로 고정하지 마세요.

설정을 바꾼 뒤에는 대상 앱의 기존 연결을 먼저 닫고 클라이언트에서 지원하는 방법으로 DNS 및 Fake-IP 캐시를 비우세요. 필요할 때만 시스템 캐시를 비우고, 매번 시스템 네트워크 전체를 초기화하지는 마세요. 인증서 오류도 DNS를 바꾼다고 해결되는 것은 아닙니다. 시스템 시간, 인증서 발급자, 접속 도메인을 확인하고 브라우저의 인증서 검증은 켜 두세요. 특정 출구에서만 문제가 발생하면 같은 도메인을 직접 연결과 해당 출구로 각각 테스트하고 차이를 기록한 뒤 조정 방향을 정하세요.

TUN 모드와 Fake-IP 함께 사용하기

트래픽 가로채기와 응답 주소는 별개의 기능입니다

TUN은 가상 네트워크 인터페이스와 라우팅 설정으로 트래픽을 받아 시스템 프록시 설정을 따르지 않는 앱을 처리할 수 있습니다. Fake-IP는 DNS 응답과 도메인 매핑 방식으로, 예약 주소를 사용해 커널이 후속 연결의 도메인을 연결할 수 있도록 돕습니다. 둘을 함께 쓰는 경우가 많지만 같은 기능은 아닙니다. 시스템 프록시는 작동하는데 특정 앱만 실패한다면 앱이 프록시를 우회하고 있을 수 있습니다. TUN을 켠 뒤에도 실패한다면 권한 문제, 라우팅 충돌, 앱 자체의 통신 방식 때문일 수 있으며 DNS 모드를 반드시 바꿔야 하는 것은 아닙니다.

사용하기 전에 현재 Clash 클라이언트가 TUN을 지원하는지, 서비스 모드나 관리자 권한이 필요한지 확인하세요. Windows에서는 관련 서비스나 권한 상승이 필요할 수 있고, macOS에서는 시스템 권한 승인과 클라이언트 구현 방식이 관여합니다. Linux에서는 가상 인터페이스 생성과 라우팅 관리 권한이 필요합니다. Android는 보통 시스템 VPN 인터페이스로 트래픽을 처리하므로 데스크톱 서비스 모드 절차를 그대로 따라 할 수 없습니다. 설치와 권한 부여 방법은 클라이언트의 실제 인터페이스를 확인하세요. 기능을 찾을 수 없다면 다운로드 센터에서 클라이언트 선택을 다시 확인하세요.

되돌릴 수 있는 기본 설정부터 구성하세요

아래는 데스크톱 환경의 TUN 설정 예제입니다. DNS 항목은 앞 장의 설정과 함께 확인해야 합니다. auto-route는 관련 경로의 자동 설정을 요청하고, auto-detect-interface는 출구 인터페이스를 식별하며, dns-hijack은 조건에 맞는 DNS 트래픽을 가로챕니다. any:53을 설정해도 모든 암호화 DNS를 식별할 수 있는 것은 아닙니다. 앱이 HTTPS 포트로 보내는 별도의 DoH 요청은 일반적인 53번 포트 DNS 조회와 다릅니다.

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

stack에서 사용할 수 있는 옵션은 실행 환경과 커널 기능에 따라 다르며 일반적인 값으로 system, gvisor, mixed가 있습니다. 네트워크 스택 변경, MTU 조정, 엄격한 라우팅 설정을 한꺼번에 적용한 뒤 한 번의 접속 결과로 어떤 변경이 효과가 있었는지 판단하지 마세요. 먼저 클라이언트 권장값을 사용해 웹페이지, 다운로드, LAN 접속이 모두 정상인지 확인합니다. 반복해서 발생하는 문제가 있을 때만 네트워크 스택을 하나씩 비교하고 노드, 규칙, 테스트 앱은 동일하게 유지하세요.

Fake-IP 호환성과 LAN 접속 문제 해결

일부 기기 검색 기능, LAN 서비스, 실제 주소에 직접 의존하는 앱은 Fake-IP 응답과 호환되지 않을 수 있습니다. 이때 DNS 모드 전체를 바꾸기보다 해당 도메인을 fake-ip-filter에 추가해 실제 주소로 조회하도록 설정하세요. 필터 규칙은 관련 DNS 동작에만 영향을 주며 직접 연결 경로를 자동으로 만들지는 않습니다. 내부 서비스에 직접 연결해야 한다면 규칙, 시스템 라우팅, 사용 중인 네트워크 인터페이스도 확인하세요. 도메인이 사설 주소로 조회되더라도 현재 네트워크에서 해당 주소에 연결할 수 있다는 뜻은 아닙니다.

모든 도메인을 필터 목록에 넣으면 Fake-IP의 주요 기능을 잃고 실제 동작을 파악하기도 더 어려워집니다. Fake-IP 모드, 주소 범위, 필터 규칙을 바꾼 뒤에도 이전 캐시 때문에 앱이 기존 예약 주소로 연결할 수 있습니다. 관련 앱의 연결을 닫고 해당 캐시를 비운 다음 다시 테스트하세요. 기업 VPN, 컨테이너 네트워크, 실험 환경에서 Fake-IP 범위와 겹치는 주소 대역을 사용 중이라면 범위를 다시 계획하고 캐시도 함께 비워야 합니다. 경로 하나만 바꿔 충돌을 덮으려 하지 마세요.

권한, 라우팅, DNS, 연결 순서로 확인하세요

TUN이 켜지지 않으면 로그에 권한 부족, 장치 생성 실패, 경로 추가 실패가 있는지 먼저 확인한 다음 해당 운영체제 계층의 문제를 해결하세요. 켜졌는데 접속할 수 없다면 다른 VPN이나 네트워크 가속 프로그램이 기본 경로를 동시에 가로채는지 확인합니다. 현재 네트워크의 출구가 잘못 감지되지 않았는지 살펴본 뒤 DNS 조회가 커널에 전달되는지 확인하세요. 모든 보안 프로그램과 시스템 방화벽을 한꺼번에 끄지 말고 관련 프로세스, 인터페이스, 규칙을 확인해 필요한 권한만 허용하세요.

웹페이지는 정상인데 게임, 음성 통화 등 UDP 앱이 실패한다면 노드와 상위 연결이 해당 UDP 전달을 지원하는지 확인한 뒤 규칙이 올바른 출구로 보내는지 살펴보세요. TUN이 UDP를 받았다고 원격 서버가 반드시 처리할 수 있는 것은 아닙니다. 큰 응답이나 특정 전송에서만 실패한다면 MTU와 경로 문제를 검토하고 같은 조건으로 변경 전후를 비교하세요. 연결 기록과 앱의 실제 결과를 함께 확인해야 합니다. 인터페이스에 TUN이 켜졌다고 표시되는 것은 트래픽 가로채기 기능이 활성화되었다는 뜻일 뿐, 모든 앱이 예상대로 분기된다는 의미는 아닙니다.

도메인 스니핑과 규칙 매칭 문제 해결

도메인 정보가 필요한 연결 확인

도메인 규칙을 적용하려면 연결에서 사용할 수 있는 도메인 정보가 있어야 합니다. 앱이 IP에 직접 연결하거나 자체 조회 경로를 사용하거나 DNS 요청이 mihomo를 거치지 않으면 연결 목록에 대상 주소만 표시될 수 있습니다. 도메인 스니핑은 일부 프로토콜의 핸드셰이크 정보에서 도메인을 추출해 후속 처리에 활용합니다. 일부 연결 정보를 보완할 수는 있지만 모든 DNS 문제를 해결하는 스위치는 아니며, 모든 앱의 연결에서 도메인을 복원할 수 있다고 보장하지 않습니다.

HTTP의 호스트 정보, TLS 핸드셰이크의 서버 이름, 일부 QUIC 핸드셰이크 정보가 도메인 식별에 활용될 수 있습니다. TLS 스니핑은 HTTPS 본문을 복호화하는 기능이 아닙니다. 패킷 캡처용 루트 인증서를 설치할 필요도 없고 이를 통해 암호화된 내용을 읽을 수도 없습니다. 암호화된 클라이언트 헬로와 같은 기능을 사용하면 도메인 정보가 제한될 수 있습니다. 이런 연결은 식별에 한계가 있다는 점을 받아들이고, 스니핑 범위를 계속 넓히기보다 알려진 주소 대역, 앱 규칙, 신뢰할 수 있는 DNS 경로를 사용하세요.

포트를 명확히 지정하고 적용 범위를 제한하세요

아래는 흔히 사용하는 프로토콜의 스니핑 설정 예제입니다. HTTP와 TLS 포트 범위를 지정해 식별을 시도할 트래픽을 제한하고 모든 포트에 무차별적으로 적용하지 않도록 합니다. 예제에서는 override-destination을 끄고 도메인 식별이 개선되는지 먼저 확인합니다. 대상 주소의 처리 방식까지 즉시 바꾸지는 않습니다. 클라이언트에 따라 그래픽 옵션이 같은 설정 항목을 생성할 수 있습니다. 사용하기 전에 구독에 sniffer가 이미 있는지 확인해 로컬 설정이 다른 계층에 덮어써지지 않도록 하세요.

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

parse-pure-ip는 순수 IP 연결도 처리하도록 시도하는 옵션이지, 해당 연결에 반드시 도메인이 들어 있다는 뜻은 아닙니다. force-dns-mapping은 DNS 매핑과 관련된 상황의 처리 방식에 영향을 주며 올바른 DNS 설정을 대신하지 않습니다. override-destination은 스니핑한 도메인으로 대상 처리 방식을 바꿀지 결정하므로 실제 서비스로 검증해야 합니다. 프로토콜별 오버라이드 설정도 있다면 최종 적용값을 확인하세요. 최상위 스위치만 보고 모든 연결의 동작을 판단할 수는 없습니다.

도메인 식별과 출구 변경을 따로 검증하세요

원래 IP만 표시되고 안정적으로 재현되는 요청 하나를 선택하세요. 스니핑을 켠 뒤 새 연결을 만들어 연결 상세 정보에 도메인이 표시되는지, 매칭 규칙이 바뀌었는지 확인합니다. 도메인은 식별됐지만 계속 직접 연결된다면 규칙 순서와 프록시 그룹 선택을 살펴보세요. 여전히 도메인이 표시되지 않는다면 대상 프로토콜, 포트, 핸드셰이크가 식별 가능한 범위인지 확인합니다. 연결 하나에 변화가 없다고 전체 설정이 로드되지 않았다고 단정하지 마세요. 같은 페이지의 리소스도 서로 다른 프로토콜을 사용할 수 있습니다.

스니핑한 도메인을 무조건 정확한 정보로 간주해서도 안 됩니다. 한 연결을 여러 서비스가 함께 사용할 수 있고, IP로 접속하면서 다른 이름 정보를 포함하는 연결도 있습니다. 대상 오버라이드를 켠 뒤 특정 서비스만 실패한다면 오버라이드를 끄고 비교하되 스니핑 기능 자체는 유지해 보세요. 호환성 문제가 실제로 확인되면 명확한 도메인에 skip-domain 등의 제외 설정을 사용하세요. 예외는 이유를 설명할 수 있게 유지하고 검증되지 않은 서비스 이름을 대량으로 추가하지 마세요.

호환성, 개인정보 보호, 성능의 한계

스니핑은 연결 초기 데이터를 처리해 식별을 시도합니다. 효과는 현재 DNS 경로와 서비스 유형에 따라 달라집니다. 대부분의 연결이 Fake-IP로 도메인에 올바르게 연결되어 있다면 식별 범위를 더 넓힐 필요가 없을 수 있습니다. 서버와 장시간 연결되거나 사용자 지정 프로토콜을 사용하는 경우에는 기존 대상 의미를 우선 유지하세요. 로그에 도메인을 더 많이 표시하려고 정상 연결을 희생하지 마세요. 문제 해결을 마치면 임시 디버그 로그를 꺼서 불필요한 도메인 및 접속 경로 정보가 장기간 저장되지 않도록 하세요.

인증서 경고가 나타나면 먼저 인증서가 접속하려는 사이트의 것인지 확인한 다음 대상 오버라이드를 켰을 때와 껐을 때를 비교하세요. 스니핑은 인증서 경고를 무시할 이유가 아니며, 안전하지 않은 연결을 허용해 “수정 여부를 확인”해서도 안 됩니다. 도메인 식별과 규칙이 모두 올바른데 특정 노드에서만 실패하면 출구와 원격 서비스 쪽을 확인하세요. 식별할 수 없는 프로토콜이라면 스니핑 설정을 계속 쌓기보다 앱 자체의 프록시 지원, DNS 조회, IP 규칙을 다시 살펴보는 편이 효과적입니다.

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

변경 사항이 어느 단계에서 유지되는지 먼저 확인하세요

구독 원본, 로컬 설정 사본, 오버라이드 규칙, 최종 실행 설정은 서로 다른 대상입니다. 구독을 내려받은 파일을 직접 편집하면 다음 업데이트에서 덮어써질 수 있습니다. 최종 실행 설정을 편집해도 다음에 다시 불러올 때 재생성될 수 있습니다. 장기간 유지할 규칙은 클라이언트가 지원하는 로컬 오버라이드, 확장 설정, 스크립트 기능에 넣으세요. Clash 클라이언트마다 메뉴 이름과 처리 순서가 다르므로 특정 클라이언트의 스크립트 인터페이스를 mihomo 공통 설정 항목으로 간주하면 안 됩니다.

인터페이스에서 현재 설정의 출처와 전역 오버라이드 및 개별 구독 오버라이드가 있는지 확인하세요. 쉽게 구분할 수 있는 규칙 하나로 최소한의 테스트를 진행합니다. 저장하고 설정을 다시 불러온 뒤 실행 설정을 확인하고, 구독을 업데이트한 다음 실행 설정을 다시 확인하세요. 모든 단계에서 예상대로 동작하는 것을 확인한 뒤에 많은 사용자 설정을 옮기세요. 업데이트 후 규칙이 사라지면 직접 붙여 넣는 횟수를 늘리는 대신 어느 설정 계층에 기록했는지 먼저 찾으세요. 수동 복구만 반복하면 설정 출처를 추적하기 더 어려워집니다.

전체 구독과 노드 제공자를 구분하세요

완전한 Clash YAML에는 보통 노드, 프록시 그룹, 규칙 및 기타 설정이 포함됩니다. 노드 구독에는 이런 구조가 없을 수 있으며 Base64로 인코딩된 노드 목록을 완전한 YAML처럼 사용할 수도 없습니다. 여러 구독을 병합하기 전에 입력 형식을 확인하세요. 구조의 차이는 구독 형식 및 변환 안내에서 확인할 수 있습니다. 구독 주소의 인증 정보는 로컬에만 보관하고 공개 로그, 스크린샷, 온라인 변환 페이지에 올리지 마세요.

기존 데이터가 mihomo 노드 제공자 형식에 맞으면 proxy-providers를 사용해 노드 출처와 기본 설정을 분리할 수 있습니다. 아래는 로컬 노드 파일로 구조를 설명하는 예제이며 파일에 실제 proxies 목록이 있어야 합니다. 임의의 전체 구독을 그대로 대체하는 입력 방식은 아닙니다. 입력 파일이 웹페이지 안내 문구나 인코딩된 텍스트뿐이라면 신뢰할 수 있는 로컬 절차로 올바른 형식으로 변환한 뒤 제공자가 읽도록 하세요.

proxy-providers:
  office:
    type: file
    path: ./providers/office.yaml
  travel:
    type: file
    path: ./providers/travel.yaml

proxy-groups:
  - name: PROXY
    type: select
    use:
      - office
      - travel

원격 노드 제공자를 사용할 때는 출처마다 고유한 이름과 캐시 경로를 지정한 뒤 실제 주소와 업데이트 간격을 입력하세요. 노드 파일과 룰셋 파일이 같은 경로를 사용하게 하지 마세요. 클라이언트 자체 가져오기 기능으로 구독을 관리한다면 인터페이스에서 업데이트를 계속 처리하고, 생성된 노드를 로컬 오버라이드에서 참조할 수도 있습니다. 다만 업데이트 후에도 참조가 유효한지 확인해야 합니다. 임시 파일 이름이나 변경될 수 있는 내부 디렉터리에 의존하지 마세요.

배열, 같은 이름의 객체, 우선순위

병합에서 가장 혼동하기 쉬운 부분은 배열 처리 방식입니다. 새 rules 배열을 오버라이드에 추가했을 때 어떤 클라이언트는 기존 배열을 교체하고, 어떤 클라이언트는 앞이나 뒤에 삽입하는 옵션을 제공하며, 다른 클라이언트는 스크립트에서 명시적으로 결합해야 합니다. 맵 형식 필드도 반드시 재귀적으로 병합되는 것은 아닙니다. 인터페이스에 “병합”이라고 표시된 것만 믿고 모든 항목이 유지된다고 가정하지 말고 생성된 전체 설정을 확인하세요. 특히 기존 MATCH가 여전히 맨 끝에 있는지, 로컬 예외가 공통 규칙보다 앞에 배치됐는지 확인해야 합니다.

여러 구독에 같은 노드 이름과 프록시 그룹 이름이 들어 있는 경우가 많아 단순히 이어 붙이면 참조가 모호해지고 이름이 충돌하거나 가져오기에 실패할 수 있습니다. 관리되는 병합 절차에서 노드 이름에 출처 접두사를 붙이고 그룹 참조도 함께 갱신하세요. 제공자의 필터 표현식을 사용한다면 이름 변경이 필터 결과에 영향을 주는지도 확인해야 합니다. 표시 이름만 바꾸고 규칙의 예전 대상을 남겨 두지 마세요. 병합한 뒤에는 어떤 규칙에서든 실제 존재하는 프록시 그룹과 유효한 노드 또는 내장 정책까지 추적할 수 있어야 합니다.

검증, 롤백, 마이그레이션

mihomo의 설정 테스트 모드로 문법과 참조 관계를 확인할 수 있습니다. 실행 파일이 있는 명령줄 환경에서 아래 명령을 실행하고 config.yaml에는 테스트할 파일의 경로를 지정하세요. 상대 경로 리소스는 실행 디렉터리를 기준으로 하며 그래픽 클라이언트의 실제 작업 디렉터리와 다를 수 있습니다. 명령줄 검사를 통과했더라도 클라이언트에서 설정을 다시 불러오고 제공자가 정상적으로 로드되었는지 확인해야 합니다. 문법이 올바르다는 것은 설정을 파싱할 수 있다는 뜻일 뿐, 구독 출처에 연결할 수 있거나 모든 노드가 연결된다는 보장은 아닙니다.

mihomo -t -f config.yaml

롤백할 때는 이번에 추가한 오버라이드를 먼저 비활성화하고 이전에 정상 작동하던 설정을 복구한 뒤 다시 불러와 확인하세요. “변경 목적, 관련 항목, 검증 도메인, 복구 위치”를 간단히 기록해 두는 편이 구분하기 어려운 설정 사본을 여러 개 보관하는 것보다 유용합니다. 클라이언트를 바꿀 때는 먼저 구독을 옮기고 규칙과 DNS를 옮긴 다음 인터페이스 계층의 스크립트를 이전하세요. 클라이언트마다 시작 설정, TUN 권한, 오버라이드 인터페이스를 다시 구성해야 하는 경우가 많으므로 YAML 하나만 복사하고 마이그레이션이 끝났다고 생각하면 안 됩니다.

외부 컨트롤러와 LAN 공유

프록시 포트와 관리 포트를 따로 설정하세요

프록시 포트는 앱 트래픽을 처리하고 제어 인터페이스는 상태 조회, 정책 전환, 연결 관리를 담당합니다. 같은 네트워크의 기기에 프록시를 공유해도 제어 인터페이스까지 열 필요는 없습니다. mixed-port는 HTTP와 SOCKS가 함께 사용하는 프록시 수신 포트입니다. external-controller는 관리 API 주소입니다. 역할과 권한, 위험이 서로 다릅니다. 휴대폰에서 컴퓨터 프록시에 연결되지 않는 문제를 관리 포트를 열어 해결하려 하지 마세요.

한 기기에서만 사용할 때는 제어 인터페이스가 루프백 주소에서만 수신하도록 설정하세요. 아래는 로컬 관리 예제입니다. 예시 비밀번호는 교육용 가짜 값이므로 실제 사용 전 이 기기에서 별도의 긴 무작위 비밀번호를 생성해 설정하세요. 예시 값을 그대로 사용하지 마세요. secret은 제어 인터페이스 인증에 쓰이며 노드 비밀번호나 구독 인증 정보와는 다른 항목입니다. 클라이언트가 이미 제어 인터페이스 설정을 관리한다면 설정 화면에서 변경해 시작 과정에서 수동 설정이 다시 생성되지 않도록 하세요.

mixed-port: 7890
allow-lan: false
external-controller: 127.0.0.1:9090
secret: "your-password"

패널을 연결하기 전에 수신 상태와 인증을 확인하세요

패널에는 보통 제어 인터페이스 주소와 비밀번호를 입력해야 합니다. 제어 인터페이스가 실행 중이고 주소에 연결할 수 있으며 인증도 통과해야 프록시 그룹과 연결 정보를 읽을 수 있습니다. 패널이 열리지 않는 문제와 패널은 열리지만 커널에 연결되지 않는 문제는 다릅니다. 전자는 패널 리소스를, 후자는 API 주소, 포트, 인증, 브라우저 네트워크 제한을 확인하세요. 로그에 address already in use가 표시되면 해당 포트를 사용 중인 프로세스를 찾으세요. 모든 수신 주소를 전체 네트워크 인터페이스로 바꿔 해결하려 하지 마세요.

패널을 로컬에서 호스팅하려면 확보한 신뢰할 수 있는 정적 패널 파일을 설정 작업 디렉터리 아래 별도 폴더에 넣고 external-ui로 경로를 지정하세요. 사용자 디렉터리 전체를 정적 리소스 경로로 지정하면 관련 없는 파일까지 노출될 수 있습니다. 브라우저에서 접속할 때는 페이지 프로토콜도 고려해야 합니다. HTTPS 페이지에서 일반 HTTP API를 요청하면 혼합 콘텐츠 제한이 적용될 수 있습니다. 출처가 다른 요청에는 허용 출처 설정이 필요할 수도 있습니다. 이는 구독이 만료된 문제가 아닙니다.

패널은 커널을 조작할 수 있으므로 읽기 전용 대시보드가 아닙니다. 제어 비밀번호를 공개 링크의 쿼리 매개변수, 공개 스크린샷, 공유 북마크에 넣지 말고 인증을 생략하려고 비밀번호를 지우지도 마세요. 원격 관리가 꼭 필요하다면 관리 요청을 통제된 전용 네트워크나 보안 터널로 보내고 접속 출처를 제한하세요. 리버스 프록시, 접근 인증, TLS도 각각 올바르게 설정해야 합니다. 복잡한 비밀번호 하나로 네트워크 경계를 대신할 수는 없습니다.

LAN 공유는 필요한 프록시 포트만 개방하세요

공유하기 전에 두 기기가 서로 통신할 수 있는 네트워크에 연결되어 있는지, 컴퓨터의 현재 LAN 주소가 안정적인지, 라우터에서 클라이언트 격리가 켜져 있지 않은지 확인하세요. 그런 다음 Clash 클라이언트에서 “LAN 연결 허용”을 켜고 실제 수신 주소와 시스템 방화벽을 확인해 신뢰할 수 있는 필요한 네트워크 대역만 프록시 포트에 접근하도록 하세요. 휴대폰에는 컴퓨터의 LAN 주소를 입력해야 합니다. 127.0.0.1은 휴대폰에서 휴대폰 자신을 가리키며 컴퓨터를 자동으로 가리키지 않습니다.

아래는 프록시 공유 설정 예제이며 제어 인터페이스는 계속 루프백 주소에서만 수신합니다. bind-address는 관련 LAN 허용 설정이 켜졌을 때 해당 의미에 따라 적용되므로 실제 수신 상태를 함께 확인하세요. 예시 인증 값은 교육용 가짜 값이므로 실제 사용할 때는 이 기기만을 위한 별도 인증 정보로 바꾸세요. 일부 기기의 시스템 프록시 설정 화면은 인증을 지원하지 않습니다. 이런 경우 기기의 기능과 통제 가능한 네트워크 범위를 검토하고, 신뢰할 수 없는 네트워크에 프록시 포트를 그대로 노출하지 마세요.

mixed-port: 7890
allow-lan: true
bind-address: '*'
authentication:
  - "lan-user:your-password"
external-controller: 127.0.0.1:9090
secret: "your-password"

휴대폰 Wi-Fi의 HTTP 프록시 설정은 보통 해당 설정을 따르는 앱에만 적용되며 모든 앱과 UDP 트래픽을 가로채지는 않습니다. 컴퓨터에서 TUN을 켜도 컴퓨터가 자동으로 휴대폰의 투명 게이트웨이가 되는 것은 아닙니다. 기기 전체의 트래픽을 처리하려면 게이트웨이, 라우팅, DNS를 명확하게 설계해야 합니다. “LAN 연결 허용”과 “TUN 공유”를 같은 기능으로 혼동하지 마세요. 일반적인 가정 환경에서는 앱이 지원하는 명시적 프록시를 먼저 사용하면 적용 범위를 제어하고 문제를 찾기 쉽습니다.

최소한의 테스트로 공유를 확인하세요

공유를 검증할 때는 먼저 컴퓨터 자체에서 프록시 접속이 되는지 확인하고, 두 번째 기기에서 컴퓨터 주소에 연결할 수 있는지 확인한 다음 프록시를 설정하고 컴퓨터의 연결 목록을 살펴보세요. 새 연결이 전혀 없다면 주소, 포트, 인증, 방화벽을 확인합니다. 연결은 보이는데 접속에 실패한다면 매칭 규칙, 최종 노드, DNS를 확인하세요. 일부 앱에서만 작동하면 해당 앱이 시스템 프록시를 따르는지 먼저 확인하고 제어 인터페이스를 계속 수정하지 마세요. 공용 Wi-Fi나 게스트 네트워크에서는 단말 간 통신이 차단될 수 있으므로 네트워크 이름이 같아도 서로 연결된다고 볼 수 없습니다.

설정을 마치면 임시로 개방한 포트와 디버그 로그를 끄고 제어 인터페이스가 의도한 범위에서만 보이는지, 구독 업데이트가 로컬 보안 설정을 덮어쓰지 않았는지 확인하세요. 장기간 사용할 수 있도록 프록시 포트, 수신 범위, 인증 정보 보관 위치, 오버라이드 경로, 복구 방법을 간단히 기록하되 비밀번호 자체는 기록에 적지 마세요. 기본 절차부터 다시 진행하려면 사용 가이드로 돌아가세요. 가져오기 실패나 시스템 프록시 설정 잔류 같은 일상적인 문제는 도움말 센터를 먼저 확인하면 됩니다. 고급 설정 전체를 다시 덧붙일 필요는 없습니다.