왜 같은 노드인데 속도 차이가 클까요

프록시 품질도 중요하지만, 많은 사용자의 체감 지연과 끊김은 「어느 트래픽을 터널에 태우느냐」에서 갈립니다. 같은 유튜브 영상이라도 규칙이 어설프면 현지 CDN으로 갈 트래픽이 불필요하게 먼 노드를 거쳐 가거나, 반대로 직통이 필요한 결제·뱅킹 페이지가 우회 회선 위에서 돌며 타임아웃이 나기도 합니다. Clash(Mihomo·클래식 계열 포함)가 강한 이유는 한 프로필 안에서 도메인·IP 단위 규칙과 정책 그룹을 동시에 다룰 수 있기 때문입니다.

이 글의 목표는 단순히 「해외만 PROXY」를 넘어, 지역별 직접 연결과 해외 프록시 선택을 한 설정 서사 안에서 균형을 잡는 것입니다. 용어는 구독마다 조금 다를 수 있으니, 예시 속 DIRECT·PROXY 이름은 반드시 본인 구독의 proxy-groups 레이블에 맞게 바꾸세요.

핵심 요약: Rule 모드에서 규칙은 위에서 아래로 첫 매칭에서 즉시 결정됩니다. 속도 최적화는 결국 「자주 오가는 현지 접속은 위쪽에서 빠르게 DIRECT로 보내고, 불특정 해외 접속만 아래쪽에서 고르게 처리」하기입니다.

Rule·Global·Direct를 다시 나누는 이유

클라이언트 상단 메뉴의 모드 이름은 글마다 표기가 다르지만 의미는 일정합니다. Direct는 이름 그대로 터널을 타지 않고, Global은 모든 트래픽을 기본 선택 그룹으로 몰아넣으며, Rule은 다음 절에서 설명하는 rules 섹션으로 갈림길을 만듭니다.

속도 향상이라는 목적만 놓으면 글로벌 모드처럼 보이는 선택이 간단하지만, 그만큼 로컬 콘텐츠와 인트라넷 접속까지 먼 회선으로 돌게 될 가능성이 커지고 지연·금융 거래 차단 같은 부작용이 생깁니다. 일상에서는 Rule을 기본으로 두고 필요할 때만 잠깐 테스트용으로 다른 모드를 사용하는 패턴을 권장합니다.

규칙 리스트 순서가 곧 라우팅 설계도

Clash 계열에서는 rules 배열 내 순서 그대로가 우선순위입니다. 상단에서는 보통 다음과 같은 묶음을 둡니다. 실제 순서와 항목은 환경에 맞춰 줄이거나 늘립니다만, 사고 줄이려면 사설 네트워크 예외와 명시적인 직통 도메인을 앞쪽에 두는 것이 안전합니다.

  1. 사설 및 링크로컬: 회사 네트워크·프린터 같은 내부 대역 접속 건들을 즉시 DIRECT.
  2. 확실한 현지 금융·정부·스트리밍 라인: 자주 깨지는 서비스는 DOMAIN-KEYWORD나 DOMAIN-SUFFIX로 명시해서 의도적으로 직통 혹은 지정 우회 노드로 분기.
  3. 제한된 메신저·CDN 이슈 도메인: 제공자가 제공한 추천 룰이 있다면 해당 블록을 유지하면서 순서 위치만 본 환경에 맞춰 재배치.
  4. GEOIP 국가/지역 줄: 나머지 대규모를 국가 코드별로 처리.
  5. MATCH 줄: 마지막 포괄 규칙으로 위에서 정의하지 못한 트래픽을 선택 그룹에 붙입니다.

이 구조 자체가 곧 속도 패턴입니다. 한국 접속이라면 GEOIP,KR,DIRECT 계열 줄이 프록시로 보내지기 전에 맞도록 위쪽에 놓거나, 제공 구독이 이미 포함했는지 검토해야 합니다. 중국의 경우 구독에서 자주 제공하는 「대륙 분리」 패턴도 같은 원리로, 로컬 대역과 국가 코드가 PROXY 위로 올라오면 의도와 반대로 터널링됩니다.

DNS가 규칙보다 먼저 흔들리면 생기는 일

브라우저가 보여 주는 주소는 도메인이지만, 실제 연결은 IP로 이루어집니다. dns 섹션에서 fake-ip를 쓰는 경우, 내부적으로는 가짜 IP 대역과 실제 접속 간 매핑이 이루어지며 규칙 매칭은 대개 도메인 관점과 맞춰집니다. 설정이 크게 다른 redir-host 계열로 바꿨다면, 동일 규칙이라도 결과가 바뀌는 일이 있습니다.

속도 문제로 자주 들어 오는 패턴 하나는 「DNS 요청만 시스템 리졸버로 새어 ISP DNS를 타거나, 업스트림이 느린 경우」입니다. 그래서 trusted DNS와 fallback DNS를 분리하고, 클라이언트가 허용하는 범위 내에서 업스트림을 바꿔 테스트하는 과정은 필수입니다. 아래는 개념 이해용 최소 형태이며 숫자·모드 값은 제공 구독이나 Mihomo 버전 표기에 따라 조정해야 합니다. 

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - udp://프로바이더-기본-dns
    - tls://1.1.1.1
  fallback:
    - tls://8.8.8.8
    - tls://1.0.0.1
확인 절차: 속도 디버깅 시에는 브라우저 개발자 도구 네트워크 탭의 DNS 시각 외에, 클라이언트 로그에 찍히는 실제 접속 라인을 함께 보면 규칙 미스 때문인지 업스트림 RTT 때문인지 구별하기 쉽습니다.

GEOIP 줄과 현지 사용자 시나리오

GEOIP는 대량의 접속 분기에서 유용합니다만, 라우팅 DB가 어느 대륙까지 커버하는지에 따라 결과가 미세하게 달라질 수 있습니다. 제공자가 커스텀 Geo 규칙을 함께 배포했다면 업데이트 주기까지 묶여 있으므로, 구독 자동 새로고침을 꺼둔 채 지나치게 오래된 패치를 들고 있는지도 확인하세요. 

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,KR,DIRECT
  - MATCH,외부선택그룹

위 패턴은 「한국의 IP 대역까지는 직통, 나머지는 해외 접속 묶음」이라는 간단 서사입니다. 회사 LAN을 끌어오는 형태에서는 DIRECT,no-resolve와 같은 줄이 충돌을 줄여 줍니다. 중국의 인트라넷처럼 광역망 속도 차이가 큰 사용자는 제공 중인 GEOIP 블록이 내륙 접속 우선 규칙을 이미 포함하는지를 보고 순서 조정량을 결정하는 편이 낫습니다.

해외 속도를 정말 책임지는 proxy-groups 레이어

규칙이 「어느 그룹으로 보낼지」까지 정하면, 속도 선택은 해당 그룹의 타입이 맡습니다. selector는 사용자가 특정 노드를 고정할 때 간단하지만 회선 상태가 들쭉날쭉하면 신경 쓰이는 시간이 많아집니다. url-test는 주어진 테스트 URL 기준 최저 왕복 지연 노드를 선택하며 일상 자동 분배용으로 많이 사용됩니다. fallback은 하나의 노드 실패 후 다음 줄로 순차 진행하게 해 안정 우선 패턴입니다. load-balance류는 패밀링을 전제로 대역 활용 극대화를 노리지만 제공 구독이 동일 제공자 다중 줄인지 반드시 확인해야 합니다. 

proxy-groups:
  - name: "외부선택그룹"
    type: select
    proxies:
      - 해외-auto
      - 수동프리미엄
  - name: 해외-auto
    type: url-test
    proxies:
      - 서울린1
      - 도쿄린2
      - 싱가포르린3
    url: https://cp.cloudflare.com/generate_204
    interval: 300

테스트 URL 자체가 특정 회사나 지역까지 가려면 결과가 크게 바뀝니다. 실제 접속 패턴과 유사한 엔드포인트가 있다면 교체 테스트를 권장합니다. 또한 테스트 주기(interval)를 지나치게 짧게 잡아 네트워크 과부와 로그 플래딩만 키우지 않도록 적절히 조절해야 합니다.

운영 주의: 과도하게 긴 사용자 정의 룰이나 Geo 리스트 커스터마이징은 디버깅 난도를 높입니다. 속도 극복에만 집중하려면 먼저 기본 패턴을 깨지 않았는지 확인하고, 증분으로 한 줄씩 추가하는 접근을 추천합니다.

클라이언트 모드가 분할 속도 체감에 주는 변수

규칙 자체와 별개로, 시스템 프록시는 HTTP(S) 레이어 친숙 프로그램에만 영향 주는 경우가 많고, 게임처럼 레이턴시에 민감하면서 SOCKS를 따라가지 않는 프로세스는 기대대로 라우팅되지 않을 수 있습니다. TUN(또는 OS 상 이에 준하는 가상 NIC 경로)은 보다 많은 프로그램의 트래픽을 Clash 처리 큐까지 끌고 오지만 관리자 권한과 드라이버 상태에 의존합니다.

속도 디버깅 시에는 브라우저만 테스트하지 말고, 실제 업무 프로그램·게임 라이브러리에 대해서도 패킷이 원하는 줄로 간다 로그 증명을 하는 것이 중요합니다. 그렇게 해야 GEOIP 순서 수정이 규칙에만 해당하는 문제인지, 아니면 TUN 레벨 처리 한계 때문인지 갈림길에서 시간을 줄일 수 있습니다.

설정 검증 할 일 목록

아래는 커뮤니티 티켓 패턴 기준 간단 검증 순서입니다. 실제 순서 조정 노트만 메모하면 다음 환경 이전 때도 속도 디버깅 시간이 줄어듭니다.

증상이나 우려 우선 확인
국내 접속 페이지가 간헐히만 느림 상단 GEOIP 순서 및 직통 도메인 목록 존재 여부
해외 접속 간헐 끊김 url-test 테스트 URL 교체 가능성
앱 간 편차 TUN vs 시스템 프록시 적용 범위 차이
DNS 레벨 간헐 차단감 nameserver·fallback 교차 설정

자주 묻는 질문

아래는 본문이 다루는 범위에서 반복 확인되는 포인트입니다.

Rule 모드인데 왜 현지 접속까지 우회하나요?

상단에 예외 줄이 빠져 있거나, 도메인이 사실상 해외 회신을 타는 패턴이라면 발생합니다. 제공 구독이 이미 포함한 줄을 그대로 쓰더라도, 개인 패치를 하면서 순서만 어긋난 예가 많습니다.

GEOIP 줄을 무조건 바닥 MATCH 직전에 두면 되나요?

일반 패턴에서는 그렇게 설계되지만 특정 플랫폼 접속처럼 패턴 분명한 서비스는 위쪽 명시 줄이 속도 우위를 만듭니다. MATCH 직행 전에 많은 줄을 줄일수록 디버깅도 쉽습니다.

fake-ip 때문에 규칙이 이상하게 느껴져요.

모드 교체 또는 스니핑 옵션에 따른 차이 때문일 수 있습니다. 클라이언트별 문서의 DNS 섹션을 처음부터 다시 따라가며 점검하세요.

한국이라면 무엇을 DIRECT 줄에 거는 게 좋아요?

GEOIP,KR,DIRECT 한 줄 외에, 자주 깨지는 증권 시세·OTP 앱 게이트웨이처럼 앱이 따로 정의한 백엔드 도메인을 직접 적는 일이 체감 지연을 줄여 줍니다.

url-test가 너무 자주 돌아가요.

주기를 늘리고 노드 수를 줄이면 왕복이 줄어듭니다. 공급자가 이미 자동 그룹을 제공한다면 그 주기를 참고하세요.

TUN이 있어야 분할이 완성되나요?

분할은 규칙으로 이루어지고 TUN은 적용 범위를 넓힙니다. 반드시 필수는 아니지만 앱 스펙트럼이 넓을수록 도움이 됩니다.

도구가 아니라 설계로 속도를 이기는 법

단일 노드 전용 앱은 화면이 단순해 보이지만, 대화형으로 스트리밍·결제·클라우드 콘솔을 오갈 때마다 수동으로 모드를 바꿔야 하는 번거로움이 생깁니다. 일부 상용 VPN은 전체 터널 위주라 지역 서비스와 겹칠 때 예외를 세밀히 주기 어렵고, YAML 수준에서 정책 그룹을 묶어 두기도 힘듭니다.

반면 Clash 계열은 본문에서 다룬 것처럼 규칙 순서·DNS·프록시 그룹 타입을 한 파일에서 연결해 서술할 수 있어, 같은 해외 노드라도 불필요한 홉을 줄이는 공간이 큽니다. 클라이언트만 바꿔도 개념을 그대로 옮길 수 있다는 점도 유지보수 비용을 낮춥니다.

지금 사용 중인 구독이 어떤 GEOIP 블록을 포함하는지, 그리고 위에서 제시한 순서 검토를 한 번만 적용해 보아도 체감 지연과 데이터 낭비가 동시에 줄어드는 경우가 많습니다. 동일한 목표를 더 단순한 인터페이스로는 맞추기 어렵다면, 아래 링크에서 플랫폼에 맞는 Clash 기반 클라이언트를 받아 직접 비교해 보시길 권합니다.

Clash 클라이언트 무료 다운로드하고 규칙 분할을 적용해 보기 →