Clash 고급 설정 가이드

전략 그룹 유형과 실제 구성

먼저 ‘노드 선택’과 ‘판단’을 구분하세요

전략 그룹은 규칙과 프록시 노드 사이에 있습니다. 규칙은 연결을 특정 전략 이름으로 넘기는 역할만 하며, 실제로 어떤 경로를 사용할지는 전략 그룹이 결정합니다. 둘을 한데 섞으면 설정에 노드 이름이 반복해서 등장하고, 노드를 조정할 때마다 규칙도 수정해야 하는 경우가 많습니다. 더 안정적인 구조는 ‘노드 선택’, ‘자동 선택’, ‘스트리밍’, ‘메신저’, ‘기타 트래픽’처럼 용도별로 안정적인 전략 그룹을 먼저 만드는 것입니다. 규칙은 이 이름을 계속 참조하고, 노드 변경은 구독과 전략 그룹에서 처리하도록 구성하세요.

select는 수동 선택 그룹으로, 출구를 명확히 제어해야 하는 상황에 적합합니다. 클라이언트 화면에서 노드, 다른 전략 그룹 또는 DIRECT를 선택하면 설정을 다시 불러오거나 영구 저장 상태가 바뀔 때까지 선택이 유지됩니다. 회선 품질을 자동으로 검사하지 않으므로 최상위 진입점으로 사용하기 좋습니다. 하위 그룹에 ‘자동 선택’, ‘장애 조치’와 여러 지역 그룹을 함께 배치할 수 있습니다. 자동화는 유지하면서 특정 사이트의 호환성 문제가 생겼을 때 빠르게 전환할 수 있습니다.

url-test는 지정한 주소에 주기적으로 연결 테스트를 수행하고 결과가 더 나은 노드를 선택합니다. 웹 브라우징이나 소프트웨어 업데이트처럼 응답 시간에 민감하고 연결을 다시 수립할 수 있는 트래픽에 적합합니다. 테스트 결과는 테스트 대상과의 연결 상태만 보여 주며 모든 웹사이트의 실제 속도를 의미하지는 않습니다. 테스트 주소까지는 빠르더라도 대상 서비스로 우회할 수 있습니다. 따라서 검사 간격을 지나치게 짧게 설정하지 말고, 한 번의 테스트를 회선 품질에 대한 영구적인 결론으로 받아들이지도 마세요.

fallback은 목록 순서에 따라 처음으로 사용 가능한 항목을 선택합니다. 매번 최저 지연을 추구하기보다 안정적인 우선순위를 중시합니다. 주 회선은 고정하고 장애가 발생했을 때만 예비 회선이 인계하는 환경에 적합합니다. load-balance는 여러 노드에 연결을 분산하므로 대량의 동시 요청이나 서로 독립적인 요청에 사용할 수 있지만, 같은 서비스에서 여러 출구 주소가 동시에 보이면 로그인 상태가 바뀌거나 위험 제어가 작동할 수 있습니다. 인터넷 뱅킹, 계정 관리와 지속적인 세션은 부하 분산 그룹에 함부로 맡기지 마세요.

provider로 동적 노드 관리

구독 노드는 자주 추가·삭제되므로 각 전략 그룹에 전체 노드 목록을 직접 작성하면 설정의 유지 관리성이 빠르게 떨어집니다. mihomo에서는 use로 proxy-providers를 참조한 뒤 filter 또는 exclude-filter로 노드 이름을 필터링할 수 있습니다. 필터 표현식은 이름만 처리하고 노드의 실제 위치는 검증하지 않으므로, 구독에서 일관된 이름 규칙을 사용하는 것이 중요합니다. 제공업체가 이름을 자주 바꾼다면 전체 노드를 포함하는 자동 그룹을 우선 사용하고, 소수의 특수 회선만 전용 그룹에 수동으로 넣으세요.

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

proxy-groups:
  - name: 노드 선택
    type: select
    proxies:
      - 자동 선택
      - 장애 조치
      - DIRECT

  - name: 자동 선택
    type: url-test
    use:
      - primary
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80

  - name: 장애 조치
    type: fallback
    use:
      - primary
    url: https://www.gstatic.com/generate_204
    interval: 600

tolerance는 작은 변동으로 인한 잦은 전환을 줄입니다. 두 회선의 차이가 몇 ms에 불과할 때 출구를 계속 바꾸는 것은 현재 회선을 유지하는 것보다 오히려 나쁠 수 있습니다. 검사 주소는 가볍고 안정적이며 접근 가능한 응답을 반환해야 합니다. 검사 대상 자체가 규칙에 의해 직접 연결되거나 DNS 오류로 잘못 해석되거나 현재 네트워크에서 접근할 수 없다면 그룹 전체의 상태가 왜곡됩니다. 문제를 확인할 때는 먼저 검사 요청이 실제로 어떤 경로를 통과했는지 확인한 다음 노드가 정말 사용할 수 없는지 판단하세요.

전략 그룹의 정렬 순서도 사용 경험에 영향을 줍니다. 최상위 수동 그룹은 규칙이 직접 참조하는 위치에 두고, 지역 그룹과 자동 그룹은 하위 기능으로 배치하며 순환 참조를 만들지 마세요. 예를 들어 A 그룹이 B를 포함하고 B가 다시 A를 포함하면 커널은 유효한 출구를 결정할 수 없습니다. 수정 후에는 먼저 클라이언트의 전략 페이지에서 각 그룹에 선택 가능한 항목이 있는지 확인한 다음, 연결 로그에서 ‘규칙 이름—전략 그룹—실제 노드’의 세 정보를 확인하세요. 규칙의 위에서 아래로 내려가는 매칭 순서를 더 이해하려면 사용자 정의 규칙 문법과 우선순위 자세히 보기를 읽어 보세요.

규칙 세트 구독 관리

개별 규칙에서 rule-provider로 분리하기

소수의 사용자 정의 규칙은 rules에 직접 작성해도 되지만, 도메인·네트워크 대역·애플리케이션 분류가 수백 개에 이르면 기본 설정을 검토하기 어려워집니다. 규칙 세트는 규칙 내용을 별도 파일로 분리하고, rule-providers가 다운로드·캐시·주기적 업데이트를 담당하게 합니다. 기본 규칙 목록에는 참조 순서만 남습니다. 광고 필터, 사설 네트워크, 특정 서비스와 지역 네트워크 규칙을 각각 관리할 수 있고, 특정 출처에 문제가 생겨도 전체 구독을 바꾸지 않고 해당 규칙 세트만 비활성화할 수 있습니다.

provider의 behavior는 파일 내용을 해석하는 방식을 결정합니다. domain은 도메인 모음에 사용하며 순수 도메인 분류에 적합합니다. ipcidr은 IPv4 및 IPv6 네트워크 대역을 대상으로 하고, classical은 DOMAIN-SUFFIX, PROCESS-NAME, IP-CIDR처럼 유형이 포함된 완전한 규칙을 받습니다. 세 유형은 임의로 바꿔 사용할 수 없습니다. domain으로 선언한 파일에 완전한 규칙 문법을 넣으면 로드 시 형식 오류가 발생하거나 예상대로 매칭되지 않을 수 있습니다.

format은 일반적으로 yaml, text 또는 바이너리 규칙 형식입니다. YAML은 사람이 검토하기 쉽고, 텍스트 형식은 한 줄에 하나씩 작성된 단순한 출처에 적합합니다. 어떤 형식을 선택하든 선언과 원격 파일의 실제 내용이 일치해야 합니다. path는 로컬 캐시 위치이므로 서로 다른 provider가 같은 파일을 공유해서는 안 됩니다. 나중에 다운로드된 내용이 이전 내용을 덮어쓸 수 있기 때문입니다. 데스크톱 클라이언트는 보통 설정 디렉터리를 관리하므로, 특정 사용자 디렉터리를 고정한 절대 경로보다 상대 경로가 이식성이 좋습니다.

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

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

  regional-cidr:
    type: http
    behavior: ipcidr
    format: yaml
    path: ./rules/regional-cidr.yaml
    url: "https://example.com/rules/regional-cidr.yaml"
    interval: 86400

rules:
  - RULE-SET,private-network,DIRECT
  - RULE-SET,service-domains,노드 선택
  - RULE-SET,regional-cidr,DIRECT,no-resolve
  - MATCH,기타 트래픽

순서, 해석과 no-resolve

Clash 규칙은 위에서 아래 순서로 매칭되며, 일치하면 이후 검사를 중단합니다. 따라서 ‘규칙 세트에 이미 특정 도메인이 포함되어 있다’고 해서 반드시 그 규칙 세트가 사용되는 것은 아닙니다. 앞쪽 규칙이 먼저 일치하면 뒤의 provider는 실행될 기회를 얻지 못합니다. 일반적으로 범위가 좁고 의도가 명확한 로컬 규칙을 앞에 두고, 업무 규칙 세트를 중간에 배치하며, 지역 네트워크 대역과 최종 대체 규칙은 뒤에 둡니다. 특정 사이트를 임시로 수정할 때도 대형 원격 모음을 바로 변경하기보다 기본 설정 상단에 명확한 규칙 하나를 추가하는 편이 좋습니다.

IP 규칙은 도메인 해석을 유발할 수 있습니다. 연결에 처음부터 도메인만 포함되어 있고 규칙 엔진이 대상 IP가 특정 네트워크 대역에 속하는지 판단해야 한다면, 커널은 먼저 주소를 가져와야 합니다. no-resolve는 매칭을 위해 이 규칙이 능동적으로 해석을 수행하지 않도록 하며, 도메인 규칙 뒤에 배치하는 IP 규칙에 적합합니다. 불필요한 DNS 요청을 줄이고 해석 과정이 원래 판단을 바꾸는 것을 막을 수 있습니다. 다만 트래픽 진입점이 IP만 제공한다면 IP 규칙은 여전히 직접 매칭됩니다. no-resolve는 해당 규칙을 비활성화하는 옵션이 아닙니다.

원격 규칙 세트를 사용할 수 없을 때는 ‘업데이트 실패’와 ‘로컬 캐시 사용 불가’를 구분해야 합니다. 유효한 캐시가 있다면 일시적인 네트워크 장애로 모든 규칙이 즉시 사라지는 경우는 드뭅니다. 반면 최초 로드, 캐시 파일 손상 또는 형식 변경은 provider를 준비되지 않은 상태로 만들 수 있습니다. 로그에서는 최종 연결 실패만 보지 말고 provider 이름, HTTP 상태, 해석 오류와 로컬 경로를 중점적으로 확인하세요. 원격 URL은 안정적인 HTTPS 주소를 사용하고 업데이트 빈도에 맞는 간격을 설정하는 것이 좋습니다. 하루에 한 번 바뀌는 모음을 몇 분마다 다운로드할 필요는 없습니다.

규칙을 구독으로 관리한다고 해서 모든 규칙을 외부에서 관리해야 하는 것은 아닙니다. 로컬 네트워크 도메인, 홈 서버, 회사 테스트 환경과 개인 예외는 로컬 오버라이드 파일에 보관하는 편이 좋습니다. 공용 규칙 세트는 넓은 분류를 담당하고 로컬 규칙은 정확한 보정을 담당합니다. 규칙 출처를 대규모로 교체하기 전에는 기존 캐시와 기본 설정 사본을 보관한 다음, 몇 가지 명확한 대상에 대해 직접 연결·프록시·차단 세 결과를 검증하세요. 각 테스트 연결이 왜 현재 출구로 향했는지 설명할 수 있어야 마이그레이션이 완료된 것입니다.

DNS 설정과 해석 경로 최적화

요청이 어디에서 시작되는지 이해하기

DNS 설정의 핵심은 서버를 더 많이 입력하는 것이 아니라, 각 조회를 누가 시작하고 어떤 네트워크 경로를 거치며 결과가 규칙 판단에 어떻게 들어가는지 명확히 하는 데 있습니다. 시스템 애플리케이션은 운영체제 DNS에 직접 질의할 수도 있고 자체 암호화 DNS를 사용할 수도 있습니다. TUN과 DNS 가로채기를 활성화하면 일반적인 53번 포트 조회는 mihomo로 넘길 수 있지만, 애플리케이션에 내장된 암호화 해석은 여전히 우회할 수 있습니다. ‘브라우저는 열리는데 다른 앱은 안 된다’면 노드를 반복해서 바꾸기보다 두 앱이 실제로 어떤 해석 방식을 사용하는지 먼저 비교하세요.

nameserver는 일반적인 도메인 해석을 담당하는 주요 업스트림입니다. default-nameserver는 DoH 또는 DoT 업스트림 자체의 도메인을 해석하는 데 사용하므로 보통 직접 접근 가능한 IP 주소를 입력합니다. 그렇지 않으면 ‘도메인 형태의 DNS 업스트림에 연결하려면 먼저 업스트림 도메인을 해석해야 하는데, 해석은 아직 연결되지 않은 업스트림에 의존하는’ 순환이 발생할 수 있습니다. proxy-server-nameserver는 프록시 서버 주소를 전용으로 해석하며, 노드 호스트 이름의 IP를 안정적인 해석 경로로 얻어야 할 때 유용합니다.

nameserver-policy를 사용하면 도메인별로 지정한 업스트림에 요청을 전달할 수 있습니다. 예를 들어 내부 도메인은 로컬 네트워크 DNS로, 특정 서비스는 다른 해석기로 보낼 수 있습니다. 이는 ‘도메인을 누가 해석할지’를 정하는 기능이지 ‘해석된 연결이 어떤 전략 그룹을 사용할지’를 정하는 기능은 아닙니다. 후자는 여전히 규칙이 결정합니다. 정책 범위가 지나치게 넓으면 많은 도메인이 기본 nameserver를 우회할 수 있습니다. 수정 후에는 정책이 적용되는 도메인, 일반 도메인과 노드 도메인을 각각 테스트해 세 경로가 독립적으로 작동하는지 확인하세요.

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  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://cloudflare-dns.com/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    "+.lan":
      - 192.168.1.1
    "+.internal.example":
      - 192.168.1.1
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "time.*.gov"

동시 업스트림은 단순한 개수 경쟁이 아닙니다

업스트림을 늘린다고 안정성이 반드시 향상되는 것은 아닙니다. 여러 해석기가 서로 다른 CDN 주소, IPv6 결과 또는 지역별 경로를 반환하면 같은 도메인이 짧은 시간 안에 일관되지 않게 동작할 수 있습니다. 더 중요한 것은 업스트림마다 조회 경로가 다를 수 있다는 점입니다. 가장 빨리 반환된 결과가 최종 출구에 적합하다는 보장은 없습니다. 예를 들어 직접 연결 DNS가 반환한 주소는 로컬 네트워크에는 적합하지만, 이후 원격 노드를 통해 연결하면 대상 CDN에는 최적이 아닐 수 있습니다. 설정할 때는 먼저 주요 출구를 정한 뒤 네트워크 모델에 맞는 업스트림 조합을 선택하세요.

ipv6은 DNS 모듈이 AAAA 결과를 반환할지 제어하지만, 실제로 IPv6 연결이 가능한지는 물리 네트워크, TUN 스택, 라우팅과 프록시 노드에 달려 있습니다. 반환은 활성화했지만 사용 가능한 IPv6 경로가 없으면 애플리케이션이 완료되지 않는 연결을 먼저 시도한 뒤 IPv4로 폴백하여 첫 접속이 느려질 수 있습니다. IPv6 비활성화는 문제 해결을 위한 수단일 뿐 링크 역량을 판단하는 과정을 대신할 수 없습니다. 가정용 인터넷, 서버와 노드가 모두 IPv6를 지원한다면 활성화한 상태에서 직접 연결과 프록시 결과를 따로 검증하세요.

해석 캐시는 반복 요청을 줄여 주지만 잘못된 결과도 일정 시간 유지시킬 수 있습니다. hosts, nameserver-policy 또는 fake-ip-filter를 수정한 뒤에도 이전 캐시가 애플리케이션, 시스템 또는 커널에서 계속 사용될 수 있습니다. 일반적인 문제 해결 순서는 설정을 다시 불러오고, 클라이언트 DNS 캐시를 비운 다음, 필요하면 운영체제 캐시를 정리하고 대상 애플리케이션을 다시 시작하는 것입니다. 웹페이지만 새로 고치는 것으로는 모든 캐시 계층이 갱신되지 않을 수 있습니다. 브라우저는 별도의 연결 풀과 DNS 캐시도 유지할 수 있으므로 새 창을 열거나 완전히 종료한 뒤 다시 시작하는 편이 더 확실합니다.

로컬 도메인과 특수 서비스 필터링

Fake-IP 모드에서는 일부 장치 검색, 로컬 네트워크 서비스, 시간 동기화와 실제 주소 검증에 의존하는 애플리케이션이 매핑 주소를 받기에 적합하지 않으므로 fake-ip-filter에 추가해야 합니다. 필터 범위는 최대한 좁게 유지하세요. 지나치게 넓은 와일드카드를 직접 추가하면 많은 도메인이 실제 IP 모드로 돌아가 도메인 규칙의 안정성이 약해집니다. 필터 항목을 추가할 때마다 화면 공유에서 장치를 찾지 못함, 로컬 호스트 이름에 접근할 수 없음, 시간 서비스가 응답을 거부함처럼 해당 현상을 기록하여 나중에 예외가 여전히 필요한지 판단할 수 있게 하세요.

DNS 리스닝 주소에도 범위 설정이 필요합니다. 데스크톱 클라이언트가 로컬에서만 사용된다면 포트를 전체 로컬 네트워크에 노출할 필요가 없습니다. 라우터가 게이트웨이로 다른 장치에 서비스를 제공한다면 접근 가능한 주소에서 수신하고 방화벽으로 출처를 제한해야 합니다. 리스닝에 성공했다고 시스템이 이미 해당 DNS를 사용한다는 뜻은 아닙니다. 시스템 DNS, TUN 가로채기와 포트 점유 여부를 계속 확인해야 합니다. 시작 로그에 bind 오류가 표시되면 포트 충돌 확인 절차를 참고하여 기존 프로세스를 확인한 뒤 리스닝 포트를 변경하세요.

TUN 모드와 Fake-IP 연동

TUN은 시스템 프록시가 포착하지 못하는 연결을 처리합니다

시스템 프록시는 프록시 설정을 능동적으로 읽는 애플리케이션에서만 작동합니다. 명령줄 프로그램, 게임, 일부 스토어 앱과 UDP를 직접 사용하는 소프트웨어는 이를 완전히 무시할 수 있습니다. TUN 모드는 가상 네트워크 인터페이스를 만들고 시스템 라우팅을 통과하는 트래픽을 IP 계층에서 인계하므로 적용 범위가 더 넓습니다. 그렇다고 ‘더 강력한 전역 모드’인 것은 아닙니다. 규칙 모드, 전역 모드와 직접 연결 모드가 인계 후의 분기 방식을 결정하고, TUN은 원래 보이지 않던 연결을 커널로 전달하는 역할만 합니다.

TUN을 활성화하려면 보통 관리자 권한 또는 시스템 승인이 필요합니다. 플랫폼마다 가상 인터페이스, 라우팅 테이블과 DNS 설정을 구현하는 방식이 다릅니다. 클라이언트가 자동 구성을 최대한 처리하더라도 절전 모드 복귀, 네트워크 전환, VPN 공존과 보안 소프트웨어 차단으로 이전 경로가 남을 수 있습니다. 활성화 후 네트워크가 완전히 끊기면 먼저 TUN을 끄고 기본 네트워크가 복구되는지 확인한 뒤, 로그에서 인터페이스 생성, 라우팅 기록과 DNS 가로채기 오류를 점검하세요. 관련 옵션을 여러 개 연속으로 전환하지 마세요. 어느 단계에서 시스템 상태가 바뀌었는지 확인하기 어려워집니다.

auto-route는 커널이 라우팅을 자동으로 기록하도록 하며 일반적인 데스크톱 환경에 적합합니다. auto-detect-interface는 현재 기본 출구를 식별하여 프록시 연결이 다시 TUN으로 들어가는 순환을 방지합니다. 여러 네트워크 카드, 가상 머신, 핫스팟 공유 또는 유선·무선 동시 연결 환경에서는 자동 식별이 예상과 다른 인터페이스를 선택할 수 있습니다. 이때는 인터페이스 이름을 추측하지 말고 라우팅 테이블과 로그에 기록된 실제 인터페이스를 확인하세요. strict-route는 우회 트래픽을 더 엄격하게 제한하여 일부 우회를 줄일 수 있지만 로컬 네트워크 접근과 다른 가상 네트워크에도 영향을 줄 수 있습니다.

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

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

Fake-IP로 도메인 의미 보존

기존 redir-host 방식은 먼저 실제 IP를 얻은 다음 연결을 규칙 엔진에 넘깁니다. 여러 도메인이 같은 CDN 주소를 공유하면 IP만으로 원래 대상을 판단하기 어렵습니다. Fake-IP는 조회된 도메인에 예약 주소 범위의 매핑 값을 할당합니다. 애플리케이션이 이 매핑 주소로 연결하면 커널이 원래 도메인을 역조회하여 도메인 규칙과 원격 해석을 적용할 수 있습니다. 핵심 가치는 모든 DNS 조회를 빠르게 만드는 것이 아니라 도메인 의미를 보존하는 데 있습니다.

매핑 주소는 일반적으로 실행 중인 커널과 해당 캐시 안에서만 의미가 있습니다. 애플리케이션이 198.18.0.0/16과 같은 주소에 연결한다고 해서 대상이 실제로 해당 네트워크 대역에 있다는 뜻은 아닙니다. DNS 조회가 mihomo를 거치지 않았는데 애플리케이션이 이전 매핑 주소를 받았거나 연결이 TUN에 의해 인계되지 않으면 ‘해석되지만 연결되지 않는’ 단절이 발생할 수 있습니다. 따라서 Fake-IP, DNS 가로채기와 트래픽 인계를 하나의 흐름으로 점검해야 합니다. enhanced-mode만 활성화하고 시스템은 다른 DNS를 계속 사용하게 두면 설정이 완전히 적용되지 않습니다.

UDP는 TUN 문제 해결에서 빠뜨리기 쉬운 계층입니다. 음성 통화, 게임, QUIC와 일부 DNS 조회는 UDP에 의존하므로 노드 프로토콜, 클라이언트 설정과 대상 서비스가 해당 경로를 모두 지원해야 합니다. 웹페이지가 열린다는 것은 일부 TCP 트래픽이 정상이라는 뜻일 뿐 TUN의 UDP 경로가 완전하다는 의미는 아닙니다. 먼저 일반 TCP를 테스트한 다음 DNS UDP, QUIC 또는 실제 애플리케이션을 테스트하세요. UDP만 실패한다면 TUN 전체를 부정하기보다 노드 기능, 규칙 정책과 시스템 방화벽을 확인해야 합니다.

MTU, 로컬 네트워크와 다른 터널

일부 네트워크에서는 작은 요청은 정상인데 업로드, 동영상 또는 큰 페이지가 멈출 수 있으며 MTU와 조각화가 원인일 수 있습니다. TUN 캡슐화는 추가 오버헤드를 만들고, 하위 네트워크가 그 크기의 패킷을 통과시키지 못하면 특정 부하에서 연결이 정지합니다. MTU는 조금씩 조정하고 반복 가능한 대용량 파일 요청으로 검증해야 합니다. 임의의 끊김을 모두 MTU 탓으로 돌려서는 안 됩니다. 특정 노드에서만 발생한다면 해당 노드 프로토콜과 전송 계층의 추가 오버헤드도 비교하세요.

로컬 네트워크 접근이 실패하면 먼저 사설 네트워크 대역 규칙이 앞쪽에 있고 DIRECT를 가리키는지 확인한 다음 strict-route, 방화벽과 대상 장치가 현재 인터페이스의 접근을 허용하는지 점검하세요. 다른 VPN과 동시에 실행하면 두 프로그램 모두 기본 경로와 DNS를 수정할 수 있으며 최종 결과는 라우팅 우선순위에 따라 달라집니다. 가장 확실한 검증 방법은 먼저 Clash만 단독으로 활성화한 뒤 다른 터널을 하나씩 다시 켜는 것입니다. 반드시 공존해야 한다면 어떤 네트워크 대역을 어떤 인터페이스가 담당하는지 명확히 정하고, 시작 순서에 기대지 마세요.

도메인 스니핑과 대상 복원

스니핑은 ‘IP만 보이는’ 연결을 처리합니다

규칙 엔진은 도메인을 받는 것을 가장 선호합니다. 도메인이 공유 IP보다 업무 의미를 더 잘 표현하는 경우가 많기 때문입니다. 하지만 애플리케이션이 자체 DNS를 사용하거나 시스템이 실제 주소를 캐시했거나 투명 프록시 단계에서 도메인이 전달되지 않아 연결이 IP만 가진 상태로 커널에 들어올 수 있습니다. 도메인 스니핑은 연결 초기에 보이는 프로토콜 정보를 읽어 HTTP Host, TLS SNI 등의 필드에서 대상 도메인을 복원한 뒤 도메인 규칙에 전달합니다. 이는 누락된 정보를 보완하는 기능이지 DNS를 대체하는 기능은 아닙니다.

스니핑 기능은 프로토콜 자체의 한계를 받습니다. 일반적으로 평문 HTTP의 Host는 보이고 TLS 핸드셰이크의 SNI에서도 도메인을 확인할 수 있습니다. 애플리케이션이 도메인 없는 연결 방식을 사용하거나 프로토콜 내용을 식별할 수 없거나 암호화 방식이 핸드셰이크 정보를 숨기면 스니핑으로 복원할 수 없습니다. UDP 프로토콜의 가시성도 서로 다르므로 모든 트래픽에서 도메인을 얻을 수 있다고 가정해서는 안 됩니다. 설정에는 합리적인 IP 규칙과 최종 대체 정책을 계속 유지하세요.

override-destination은 도메인을 식별한 뒤 원래 대상을 대신해 연결 처리에 사용할지를 결정합니다. 활성화하면 도메인 규칙과 원격 해석을 적용하는 데 도움이 되지만, 고정 IP에 의존하거나 인증서 동작이 특수하거나 도메인과 연결 주소가 의도적으로 다른 일부 애플리케이션에서는 호환성 문제가 생길 수 있습니다. 먼저 일반적인 포트에만 적용한 뒤 skip-domain으로 예외 도메인을 지정하거나, 알려진 문제 애플리케이션의 원본 주소를 대상으로 좁은 범위의 예외를 만드는 방식이 안전합니다.

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

force-dns-mapping과 parse-pure-ip

force-dns-mapping은 DNS 매핑과 관련된 연결에 스니퍼가 집중하도록 하며 Fake-IP 경로에 적합합니다. parse-pure-ip는 대상이 순수 IP로 보이는 트래픽을 분석하도록 시도합니다. 두 옵션을 모두 활성화하면 적용 범위가 넓어지는 동시에 더 많은 연결이 식별 과정에 들어갑니다. 최신 장치는 보통 이 정도 오버헤드를 감당할 수 있지만, 라우터처럼 리소스가 제한된 환경에서는 연결 수, CPU 사용량과 로그 양을 관찰해야 합니다. 옵션이 존재한다는 이유만으로 모두 켜지는 마세요.

포트 범위는 스니핑 정확도를 제어하는 중요한 경계입니다. HTTP 스니핑을 모든 포트에 적용하면 HTTP가 아닌 프로토콜의 초기 데이터까지 반복적으로 해석하려 하여 오버헤드와 오판 가능성이 커집니다. 먼저 80, 8080과 일반적인 웹 포트처럼 명확한 범위에서 시작하세요. TLS는 보통 443과 소수의 사용자 지정 포트에 집중됩니다. 특정 애플리케이션이 특수 포트를 실제로 사용한다면 연결 로그를 확인한 뒤 추가하세요. 설정이 구체적일수록 매칭 결과를 설명하기 쉽습니다.

스니핑과 Fake-IP는 모두 도메인 복원에 도움을 주지만 작동 시점이 다릅니다. Fake-IP는 DNS 조회 시 매핑을 만들고 애플리케이션은 이후 매핑 주소로 연결합니다. 스니핑은 연결이 도착한 뒤 프로토콜 핸드셰이크에서 정보를 추출합니다. 전자는 보통 더 안정적이고, 후자는 커널 DNS를 우회한 연결, 실제 IP 연결과 투명 프록시 환경을 보완하는 데 중요합니다. 하나의 연결에 매핑 도메인과 스니핑 도메인이 모두 존재한다면 로그에서 최종적으로 어느 값이 사용되었는지 확인하세요. 특히 CDN 리디렉션이나 인증서가 공용 도메인을 사용하는 경우에 주의해야 합니다.

오판이 발생했다고 스니핑 전체를 바로 끄지 마세요

특정 애플리케이션이 스니핑 활성화 후 이상해졌다면 먼저 해당 연결을 정확히 찾으세요. 로그에서 원래 대상 IP, 복원된 도메인, 매칭된 규칙과 최종 전략을 확인합니다. 복원된 도메인이 대상 업무와 뚜렷하게 맞지 않으면 해당 도메인을 건너뛰기 목록에 추가하거나 해당 프로토콜의 포트 범위를 줄이세요. 로컬 네트워크 서비스 하나만 이상하다면 해당 도메인이나 네트워크 대역에 예외를 둘 수 있습니다. 전역 스니핑을 끄면 도메인 식별에 의존하는 다른 연결이 IP 규칙으로 돌아가 더 알아차리기 어려운 분기 변화가 생길 수 있습니다.

스니핑을 테스트할 때는 규칙 결과가 명확한 도메인을 선택하세요. 직접 연결되어야 하는 서비스와 프록시를 사용해야 하는 서비스를 하나씩 준비하고, 애플리케이션 연결 캐시를 지운 뒤 각각 접속합니다. 그런 다음 연결 상세 정보에 도메인이 표시되는지 확인하세요. IP만 보인다면 트래픽이 TUN을 통과하는지, 프로토콜을 식별할 수 있는지, 포트가 sniff 범위에 포함되는지 점검합니다. 도메인은 표시되지만 전략이 잘못되었다면 문제는 규칙 순서나 전략 그룹에 있으며 스니핑에 있지 않습니다. ‘대상 식별’과 ‘출구 선택’을 나누어 판단하면 잘못된 계층의 매개변수를 반복해서 바꾸는 일을 피할 수 있습니다.

도메인 스니핑도 잘못된 DNS를 고칠 수는 없습니다. 애플리케이션이 연결 전에 이미 접근할 수 없는 주소를 받았다면 스니핑으로 도메인을 식별하더라도 하위 라우팅, 인증서 또는 대상 서비스가 영향을 받을 수 있습니다. 안정적인 설정은 올바른 DNS 인계를 기본으로 하고, 스니핑으로 순수 IP 연결을 보완하며, 복원할 수 없는 트래픽은 IP 규칙으로 처리합니다. 세 계층이 각각 하나의 문제를 담당할 때 완전한 판단 흐름이 만들어집니다.

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

상위 설정을 업데이트 가능한 입력으로 취급하기

구독 설정은 서비스 제공업체가 관리하므로 업데이트 시 프록시 노드, 전략 그룹과 규칙이 교체될 수 있습니다. 구독에서 생성된 파일을 직접 수정하면 다음 업데이트에서 로컬 변경 내용이 보통 덮어써집니다. 올바른 접근은 구독을 입력으로 보고 로컬 요구 사항을 독립적인 오버라이드 계층에 두는 것입니다. 구독은 노드와 기본 구조를 담당하고, 로컬 계층은 포트, DNS, TUN, 규칙 우선순위와 전용 전략 그룹을 담당합니다. Clash Plus 같은 그래픽 클라이언트는 보통 설정 오버라이드, 스크립트 또는 병합 진입점을 제공합니다. 이름은 다를 수 있지만 목표는 로컬 변경을 반복 적용할 수 있게 하는 것입니다.

오버라이드에는 ‘교체’와 ‘병합’이라는 두 가지 의미가 있습니다. mixed-port와 mode 같은 스칼라 필드는 보통 직접 교체됩니다. dns 같은 매핑 필드는 키 단위로 병합될 수도 있고 전체가 덮어써질 수도 있습니다. rules와 proxy-groups 같은 배열 필드는 특히 혼동이 많습니다. 일부 클라이언트는 새 배열을 뒤에 추가하고, 일부는 이름에 따라 병합하며, 또 일부는 전체를 교체합니다. 따라서 어떤 병합 스크립트를 사용하든 먼저 최종 설정을 내보내 실제 결과를 확인해야 하며, 입력 조각만 검사해서는 안 됩니다.

규칙 배열은 앞에 넣는지 뒤에 넣는지 특히 구분해야 합니다. 사용자 정의 직접 연결 규칙을 MATCH 뒤에 배치하면 적용되지 않습니다. 특정 업무의 분기를 수정하는 규칙은 보통 원격 공용 규칙보다 앞에 삽입해야 합니다. 병합 도구가 prepend와 append를 지원한다면 의도에 맞는 방식을 명확히 선택하세요. 전략 그룹을 이름으로 병합할 때도 로컬 그룹과 상위 그룹의 이름은 같지만 유형이 다른 상황을 피해야 합니다. 업데이트 후 이전 필드가 남아 이해하기 어려운 혼합 구조가 될 수 있습니다.

# 로컬 오버라이드 예시: 실제 병합 진입점은 클라이언트가 제공
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

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

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

rules:
  - DOMAIN-SUFFIX,internal.example,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

여러 구독은 단순한 이어 붙이기가 아닙니다

여러 구독을 병합할 때 가장 먼저 부딪히는 문제는 이름 충돌입니다. 서로 다른 출처가 모두 ‘자동 선택’, ‘노드 선택’ 또는 완전히 같은 노드 이름을 포함할 수 있습니다. 클라이언트가 이름으로 중복 제거하면 나중에 추가된 항목이 이전 항목을 덮어쓸 수 있고, 중복 제거를 하지 않으면 화면에 구분하기 어려운 중복 항목이 나타납니다. provider 계층에서는 출처별 이름을 유지하고, use로 여러 provider를 동시에 참조하는 자체 통합 전략 그룹을 만드는 방법이 좋습니다. 모든 노드를 정적 배열로 펼치지 않아도 되고 특정 출처만 별도로 일시 중지할 수도 있습니다.

두 번째 문제는 업데이트 주기입니다. 여러 구독을 동시에 자주 업데이트하면 요청량이 늘고 설정을 다시 불러올 때 기존 연결이 중단될 수 있습니다. 노드 정보는 보통 분 단위로 갱신할 필요가 없습니다. provider는 긴 주기로 업데이트하고, 서비스 제공업체의 명확한 변경이나 노드 이상이 발생했을 때 수동 업데이트로 검증할 수 있습니다. 상태 검사는 구독 다운로드와 별개입니다. 전자는 기존 노드를 테스트하고 후자는 새 노드 목록을 가져옵니다. 매우 짧은 구독 업데이트 간격으로 상태 검사를 대신하지 마세요.

세 번째 문제는 출처별 기능 차이입니다. 어떤 노드는 UDP를 지원하고 어떤 노드는 지원하지 않으며, 특정 회선은 고정 지역 업무에 적합하고 다른 회선은 일반 브라우징에 적합합니다. 모든 노드를 하나의 자동 그룹에 섞으면 업무 요구와 맞지 않는 출구가 선택될 수 있습니다. 안정적으로 확인 가능한 이름이나 출처를 기준으로 ‘출처 A 자동’, ‘출처 B 예비’ 같은 전용 그룹을 만들고, 최상위 ‘노드 선택’에서 이 그룹들을 참조하세요. 노드 이름으로 기능을 안정적으로 표현할 수 없다면 실제 연결 테스트와 수동 그룹으로 관리해야 합니다.

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

수정할 때마다 오버라이드 조각만이 아니라 이전에 정상 작동한 최종 설정을 보관하세요. 최종 설정에는 병합 후의 실제 순서가 반영되므로 어느 부분이 바뀌었는지 비교하기도 쉽습니다. 한 번에 하나의 모듈만 조정하는 것이 좋습니다. 먼저 전략 그룹, 다음 규칙, DNS, 마지막으로 TUN과 스니핑을 적용하세요. 각 단계에서 최소한 설정 로드, 기본 웹페이지 접근, 직접 연결 대상 하나와 프록시 대상 하나가 예상대로 작동하는지 확인해야 합니다. 여러 항목을 동시에 바꾸면 조작 횟수는 줄지만 실패 원인을 빠르게 찾을 수 없습니다.

구독 업데이트 후 이상이 생기면 먼저 provider가 정상인지, 전략 그룹이 비어 있지 않은지, 규칙이 참조하는 이름이 여전히 존재하는지 비교하세요. 많은 문제는 노드가 고장 난 것이 아니라 상위 설정에서 전략 이름을 바꿨는데 로컬 규칙이 이전 이름을 계속 참조해서 발생합니다. 커널은 로드 시 전략 또는 provider를 찾을 수 없다고 보통 보고합니다. 클라이언트에 ‘설정 실패’만 표시된다면 상세 로그를 열어 구체적인 키 이름을 확인하세요. 연결을 복구하려고 로컬 오버라이드를 전부 삭제하면 가장 중요한 차이 단서를 잃게 됩니다.

로컬 오버라이드는 짧고 설명 가능하게 유지하세요. 모듈별로 주석을 작성하여 특정 규칙이 해결한 문제를 기록할 수 있지만, 오래전에 효력을 잃은 실험 매개변수를 파일에 계속 남겨 두지는 마세요. 일정한 주기로 예외 항목을 검토하여 대상 서비스가 여전히 존재하는지, 원격 규칙 세트가 이미 포함하는지, 이전 네트워크 환경이 바뀌었는지 확인하세요. 설정 관리의 목표는 필드 수를 늘리는 것이 아니라 남겨 둔 각 필드의 용도와 한계를 설명할 수 있게 하는 것입니다.

외부 제어 패널과 API의 경계

제어 포트로 할 수 있는 일

mihomo의 외부 제어 인터페이스를 사용하면 그래픽 클라이언트나 웹 패널에서 전략 그룹을 읽고, 노드를 전환하고, 연결을 확인하고, provider 업데이트를 실행하며, 일부 실행 상태를 조정할 수 있습니다. 데스크톱 클라이언트의 전략 페이지, 연결 목록과 로그 창도 대부분 이 인터페이스를 기반으로 합니다. 이는 제어면이지 프록시 진입점이 아닙니다. mixed-port, HTTP 포트와 SOCKS 포트는 트래픽 전달을 담당하고, external-controller는 관리 요청만 처리합니다.

로컬에서만 사용할 때는 제어 주소를 루프백 인터페이스에 바인딩하는 것이 가장 안전합니다. 127.0.0.1에 바인딩하면 같은 로컬 네트워크의 다른 장치가 직접 접근할 수 없습니다. 다른 장치에서 라우터의 커널을 관리해야 한다면 로컬 네트워크 주소에서 수신할 수 있지만, 접근 자격 증명을 설정하고 방화벽으로 출처를 제한하며 포트를 공용 인터넷에 매핑하지 않아야 합니다. 관리 인터페이스는 연결 대상을 확인하고 출구를 변경할 수 있으므로 권한을 로컬 관리자 권한과 동일한 수준으로 취급하세요.

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

# 선택 사항: 커널이 로컬 제어 패널 파일을 호스팅하도록 설정
external-ui: ./ui

secret이 비어 있으면 제어 포트에 접근할 수 있는 프로그램이 인증 없이 인터페이스를 호출할 수 있습니다. 로컬 루프백 환경에서도 같은 장치의 다른 프로세스가 접근할 위험을 고려해야 하며, 로컬 네트워크에서 수신한다면 반드시 자격 증명을 설정해야 합니다. 예시의 값은 교육용으로 쉽게 알아볼 수 있는 값일 뿐이므로 실제 사용에서는 별도의 자격 증명으로 바꾸고 구독 주소, 시스템 계정 또는 다른 서비스와 공유하지 마세요. 패널 연결에 실패하면 주소, 포트, 프로토콜과 자격 증명이 완전히 일치하는지 확인하세요.

external-ui는 정적 패널 파일 디렉터리를 가리킵니다. 커널이 이 파일을 호스팅하면 제어 주소를 통해 화면을 열 수 있으며, 클라이언트에 내장된 제어 패널을 사용할 수도 있습니다. 화면 파일과 커널 API는 호환되어야 합니다. 페이지는 로드되지만 전략 그룹이 비어 있다면 노드 구독을 다시 다운로드하기보다 먼저 브라우저 네트워크 요청과 제어 인터페이스 응답을 확인하세요. 정적 파일 로드 성공은 웹 리소스에 접근할 수 있다는 뜻일 뿐 API 인증까지 통과했다는 의미는 아닙니다.

로컬 네트워크 접근과 리버스 프록시

홈 서버나 라우터에서 사용할 때 흔한 구조는 제어 포트를 로컬에서만 수신하게 하고, 관리되는 리버스 프록시가 HTTPS 진입점을 제공하도록 하는 방식입니다. 이렇게 하면 접근 제어와 인증서를 한곳에서 처리하고 관리 포트를 직접 노출하지 않을 수 있습니다. 하지만 리버스 프록시 설정이 잘못되면 WebSocket이나 인증 헤더가 누락되어 패널 첫 화면은 정상인데 연결 목록이 실시간으로 갱신되지 않을 수 있습니다. 문제를 확인할 때는 정적 페이지, 일반 API 요청과 실시간 연결 채널을 각각 테스트하여 어느 계층에 문제가 있는지 확인하세요.

0.0.0.0에서 직접 수신한다면 장치 방화벽을 반드시 확인해야 합니다. allow-lan은 주로 프록시 포트의 로컬 네트워크 장치 사용 허용 여부를 제어하며, 제어 인터페이스의 방화벽을 의미하는 옵션으로 오해해서는 안 됩니다. 제어 인터페이스의 접근 가능 여부는 자체 수신 주소와 시스템 네트워크 규칙에 달려 있습니다. 로컬 네트워크의 다른 장치에서 포트를 테스트할 수 있지만, 테스트가 끝나면 출처 네트워크 대역을 제한해야 합니다. ‘일시적으로 편리한 접근’을 장기간 개방 상태로 굳히지 마세요.

제어 패널에 표시되는 연결 정보는 커널의 현재 상태에서 가져옵니다. 전략을 전환해도 보통 새로 만드는 연결에만 영향을 주며, 이미 수립된 TCP 세션은 연결이 종료될 때까지 이전 노드를 계속 사용할 수 있습니다. 노드 전환을 테스트할 때는 패널에서 기존 연결을 닫거나 대상 애플리케이션을 다시 시작한 뒤 새 연결의 경로를 확인하세요. 전략 그룹의 현재 선택만 보고 진행 중인 세션까지 이동했다고 판단할 수는 없습니다.

API 문제 해결 순서

패널에 연결할 수 없으면 먼저 커널이 실행 중인 장치에서 제어 포트가 수신 중인지 확인하고, 다음으로 접속 측에서 네트워크 접근 가능성을 테스트한 뒤 마지막으로 인증을 확인하세요. 이 세 단계의 순서를 바꾸면 안 됩니다. 포트가 수신 중이 아니라면 브라우저 설정을 바꿔도 의미가 없고, 방화벽이 네트워크를 차단하고 있다면 자격 증명을 계속 바꿔도 성공하지 않습니다. 포트가 다른 프로그램과 충돌하면 제어 포트를 변경한 뒤 클라이언트나 패널 주소도 함께 업데이트해야 합니다.

패널은 상태를 효율적으로 관찰하게 해 주지만 유일한 설정 출처가 되어서는 안 됩니다. 중요한 변경은 백업 가능한 YAML, 오버라이드 파일 또는 클라이언트 설정에 남겨야 합니다. 실행 중 API로만 전환한 상태는 재시작이나 재로드 후 기본값으로 돌아갈 수 있습니다. 장기간 사용할 전략 선택은 클라이언트의 영구 저장 기능에 맡길 수 있지만, 구조적인 변경은 설정 파일로 관리해야 합니다. 임시 조작과 영구 설정을 구분해야 ‘화면에서 바꿨지만 재시작 후 사라지는’ 문제를 피할 수 있습니다.

원격 관리에서는 로그 범위도 제한해야 합니다. 연결 목록에는 대상 도메인, 출처 주소와 트래픽 정보가 포함될 수 있으므로 통제되지 않은 네트워크에 공개하기에 적합하지 않습니다. 일상적인 실행에서는 문제 해결에 필요한 일반 로그 수준만 사용하고, 문제가 발생했을 때만 잠시 상세 수준으로 높인 뒤 복구하세요. 외부 제어 패널의 가치는 규칙과 연결을 명확히 확인하는 데 있으며 모든 접근 기록을 장기간 보관하는 데 있지 않습니다.

설정 검증, 연동 테스트와 문제 위치 찾기

문법을 먼저 검증하고 동작을 확인하세요

설정 문제 해결은 두 계층으로 나뉩니다. 첫 번째는 YAML 들여쓰기, 필드 유형, 전략 참조와 provider 형식을 포함하여 커널이 구조를 읽을 수 있는지 확인하는 단계입니다. 두 번째는 로드가 성공한 뒤 실제 연결이 예상대로 DNS, 규칙과 전략 그룹을 통과하는지 확인하는 단계입니다. 문법 검증에 성공했다고 분기가 올바르다는 뜻은 아닙니다. 반대로 애플리케이션이 인터넷에 연결되지 않는 것도 반드시 문법 오류 때문은 아니며, 특정 규칙이 사용할 수 없는 노드를 선택했을 수 있습니다.

YAML은 공백으로 계층을 표현하므로 Tab, 잘못된 들여쓰기와 콜론 뒤의 형식이 구조를 바꿀 수 있습니다. 목록 항목 앞의 하이픈은 올바른 계층에 있어야 하며, 불리언과 숫자에는 따옴표가 필요하지 않습니다. 특수 문자가 포함된 이름이나 URL에는 따옴표를 사용할 수 있습니다. 전략 그룹 이름은 정확히 참조됩니다. ‘노드 선택’과 ‘노드 선택 ’은 비슷해 보이지만 뒤의 공백 때문에 서로 다른 문자열이 됩니다. 설정이 길다면 먼저 로그에서 보고한 줄 주변을 확인한 뒤 위로 올라가 해당 모듈을 찾으세요.

mihomo는 명령줄을 통해 설정 디렉터리를 검사할 수 있으며, 구체적인 실행 파일 이름은 플랫폼과 설치 방식에 따라 달라집니다. 아래 명령은 일반적인 검사 방식을 보여 줍니다. 설정 디렉터리를 지정해 테스트하고 장기 서비스를 직접 시작하지 않습니다. 그래픽 클라이언트 사용자는 클라이언트의 설정 검사 기능을 사용하고 코어 로그에서 첫 번째 오류를 확인할 수도 있습니다. 이후 오류는 첫 번째 구조 오류로 연쇄 발생하는 경우가 많으므로 가장 먼저 나타난 오류부터 수정하세요.

mihomo -t -d /path/to/config-directory

# 필요한 경우 포그라운드에서 로드 과정을 확인
mihomo -d /path/to/config-directory

최소 검증 매트릭스 만들기

수정할 때마다 최소 네 가지 대상을 검증하세요. 로컬 네트워크 주소는 직접 연결되어야 하고, 명확한 일반 사이트 하나는 예상한 전략으로 연결되어야 하며, 프록시 출구에서만 사용할 수 있는 대상 하나는 프록시를 거쳐야 합니다. 전용 규칙이 적용되지 않는 대상 하나는 최종 대체 그룹으로 들어가야 합니다. TUN을 활성화했다면 시스템 프록시를 무시하는 애플리케이션 하나를 추가하고, IPv6를 활성화했다면 A와 AAAA 연결을 각각 검증하세요. 고정된 테스트 대상을 사용하면 설정 간 결과를 비교하기 쉽습니다.

연결 로그는 처리 흐름에 따라 읽어야 합니다. 먼저 인바운드 유형을 확인하여 연결이 HTTP, SOCKS 또는 TUN에서 들어왔는지 봅니다. 다음으로 대상이 도메인인지 IP인지 확인하여 DNS 매핑이나 스니핑이 작동했는지 판단합니다. 이어서 매칭된 규칙과 전략 그룹을 확인하고, 마지막으로 실제 노드 또는 DIRECT를 확인하세요. 진입점부터 잘못되었다면 규칙을 계속 조정해도 의미가 없습니다. 규칙은 올바른데 노드가 잘못되었다면 문제는 전략 그룹 선택에 있습니다. 노드도 올바른데 연결되지 않는다면 노드 기능, 대상 서비스와 하위 네트워크를 점검하세요.

DNS 문제는 별도로 검증해야 합니다. 조회 도메인, 업스트림, 반환 유형과 연결 대상을 기록하고 단순히 ‘웹페이지가 열리지 않는다’는 이유만으로 DNS 오류라고 판단하지 마세요. 먼저 간단한 nameserver 설정을 사용해 기준선을 만든 다음 policy, Fake-IP 필터와 여러 업스트림을 단계적으로 복구할 수 있습니다. 항목을 하나씩 복구할 때마다 같은 테스트를 반복하세요. 복잡한 DNS 설정을 한 번에 전체 교체하면 업스트림 접근 불가, 과도하게 넓은 정책 범위와 캐시 잔류를 하나의 문제로 오인하기 쉽습니다.

한 번에 변수 하나만 변경

효율적인 문제 해결에는 재현성이 필요합니다. 모든 고급 기능을 끄고 기본 연결을 복구한 다음 DNS, Fake-IP, TUN, 스니핑과 규칙 provider를 순서대로 활성화하는 방식이 무작위로 옵션을 전환하는 것보다 빠릅니다. 각 단계의 변경 내용과 결과를 기록하고 실패하면 이전의 정상 설정으로 돌아가세요. 클라이언트가 설정 사본을 지원한다면 ‘기본’, ‘TUN 테스트’, ‘전체 규칙’ 세 가지 독립 설정을 만들어 같은 파일을 계속 덮어쓰지 않도록 하세요.

포트 관련 오류는 어떤 프로세스가 실제로 수신 중인지 확인해야 합니다. mixed-port, DNS 수신 포트와 external-controller가 모두 다른 프로그램과 충돌할 수 있으며 오류 로그의 포트 번호가 어느 항목을 확인해야 하는지 알려 줍니다. 포트를 변경한 뒤에는 시스템 프록시, 패널 주소 또는 다른 의존 클라이언트도 함께 업데이트해야 합니다. 자세한 명령과 플랫폼별 차이는 Clash 포트 점유 확인 절차를 참고하세요.

모든 노드에서 시간 초과가 발생하면 먼저 상태 검사 주소에 접근할 수 있는지 확인한 뒤 노드 하나를 수동으로 테스트하세요. 모든 provider가 동시에 실패한다면 모든 노드가 우연히 동시에 고장 났다기보다 로컬 네트워크, DNS, 구독 업데이트 또는 시스템 시간이 원인일 가능성이 높습니다. 특정 출처만 실패한다면 해당 provider의 URL, 캐시와 노드 프로토콜을 확인하세요. 첫 연결의 기본 검증은 노드 선택, 지연 시간 테스트와 프록시 적용 확인에서 단계별로 점검할 수 있습니다.

성능 조정은 정확성 확인 후 진행하세요

상태 검사 간격을 줄이고, DNS 업스트림을 늘리고, 스니핑 범위를 넓히고, 더 많은 규칙 세트를 활성화하면 작업량은 증가하지만 사용 경험이 반드시 좋아지는 것은 아닙니다. 먼저 기본값이나 보수적인 매개변수로 정확하고 안정적인 처리 흐름을 만든 뒤 명확한 현상에 따라 조정하세요. 웹페이지 첫 접속이 느리다면 DNS 시간과 연결 시간을 따로 측정하고, 노드 전환이 잦다면 tolerance를 높이거나 검사 간격을 늘리며, 라우터 부하가 높다면 규칙 세트 수와 검사 빈도를 줄이고 스니핑 포트 범위를 좁히세요.

로그 수준도 관찰성과 오버헤드에 영향을 줍니다. 일상적인 사용에서는 일반 정보 수준으로 충분하며, 문제를 재현할 때만 잠시 상세 수준으로 높이고 기록이 끝나면 복구하세요. 연결 세부 정보를 장기간 대량으로 출력하면 디스크 쓰기가 늘고 불필요한 접근 기록이 쌓일 수 있습니다. 문제 해결 로그에는 문제 발생 전후의 전체 흐름이 포함되어야 하지만 무기한 보관할 필요는 없습니다.

성숙한 설정은 필드 수로 평가하지 않습니다. 진입, 해석, 매칭, 결정과 출구의 다섯 단계가 모두 설명 가능하고, 어떤 고급 기능도 기본 연결을 망가뜨리지 않고 독립적으로 끌 수 있는지가 더 중요합니다. 이 페이지의 모듈식 설정을 완료한 뒤에는 최종 YAML과 오버라이드 파일을 내보내고 클라이언트의 주요 옵션을 기록하는 것이 좋습니다. 다른 장치로 옮겨야 한다면 먼저 다운로드 페이지에서 해당 플랫폼의 클라이언트를 선택하세요. 여러 플랫폼을 지원하는 Clash Plus를 우선 권장하며, 설명할 수 없는 거대한 설정을 그대로 복사하지 말고 모듈별로 하나씩 복원하세요.