Clash 프록시 그룹(proxy-groups): 기초부터 고급까지

Clash에서 프록시 그룹이란?

설정 파일(YAML)의 proxy-groups 항목은 가상 프록시를 정의합니다. 여기 적힌 이름들은 그 자체로 서버가 아니라, 하나 이상의 실제 프록시(또는 다른 그룹) 위에 얹힌 스케줄링 정책입니다. 규칙이 특정 그룹 이름으로 연결을 넘기면, Clash는 해당 그룹의 type에 따라 최종 노드를 고릅니다.

한 줄로 압축하면 이렇습니다. 규칙은 「프록시를 태울지 말지」를 정하고, 프록시 그룹은 「그중 어떤 노드가 실제로 나갈지」를 정한다. 이 분리 때문에 게임 지연 시간, 스트리밍 지역, 일상적인 끊김 여부가 갈립니다. 생태계가 처음이라면 먼저 Clash 튜토리얼에서 흐름을 익힌 뒤, 이 페이지로 돌아와 그룹만 다듬어도 충분합니다.

커뮤니티에서 받은 프로필은 대개 이미 층으로 나뉩니다. UI에서 사용자가 고르는 소수의 「진입」 그룹과, 뒤에서 자동으로 지연을 재는 지역 풀 같은 숨은 레이어가 함께 존재합니다. 그 구조를 읽을 줄 알면 업스트림이 구독을 갱신해도 내가 덧댄 설정을 합치기 쉽습니다. select, url-test, fallback, load-balance 같은 용어는 Clash Meta 계열 클라이언트(Clash Verge Rev, 각종 GUI 포크, 헤드리스 배포)에서도 그대로 통하므로 한 번 익혀 두면 이득입니다.

마지막으로, 구독 제공자가 내려주는 것은 보통 proxies 목록(노드)뿐입니다. 노드를 어떤 이름으로 묶고, 화면에 어떻게 노출할지는 전부 사용자 YAML 설계입니다. 같은 구독을 써도 proxy-groups와 rules가 다르면 체감 경로는 완전히 달라질 수 있습니다.

자주 쓰는 네 가지 프록시 그룹 타입

대부분의 Clash·Clash Meta 프로필은 아래 네 타입을 축으로 돌아갑니다. 각각 수동 제어, 지연 기준 자동 선택, 순서대로 장애 조치, 부하 분산에 초점이 있습니다.

웹에서 복사한 스니펫을 붙이기 전에, 자신이 쓰는 빌드가 그 type을 지원하는지 확인하세요. Clash Meta는 추가 동작을 더하지만, 일상 설정의 뼈대는 여전히 이 네 가지입니다. 지원하지 않는 타입을 참조하면 파서 오류가 나거나 그룹이 무시될 수 있으니, 수정 후에는 반드시 검증합니다.

① select — 수동 선택

select는 가장 단순한 그룹입니다. 클라이언트 UI에서 사용자가 멤버를 고르면 그대로 유지되며, 자동 측정이나 로테이션은 없습니다. 은행 앱처럼 특정 리전에 고정하고 싶을 때, 또는 DNS를 의심하며 노드 하나만 켜 두고 디버깅할 때 적합합니다.

사용자가 클릭하기 전에는 바뀌지 않으므로, 입문 단계에서도 가장 안전한 출발점입니다. 후보 목록은 짧게 유지해 메뉴를 읽기 쉽게 하고, 나중에 필요하면 그중 하나 뒤에 더 풍부한 url-test 풀을 중첩하면 됩니다. 많은 템플릿은 상위에 「Proxy」「Global」 같은 단일 select만 노출해, 일반 사용자가 하위 이름까지 파고들지 않게 합니다.

proxy-groups:
  - name: "Manual"
    type: select
    proxies:
      - HK-01
      - JP-01
      - US-01
      - DIRECT

② url-test — 가장 낮은 지연 선택

url-test는 주기적으로 프로브 URL(가벼운 204 엔드포인트가 흔함)로 후보들을 측정하고, 가장 낮은 지연을 유지합니다. 반응 속도가 중요한 게임, 화상·음성, 대화형 SSH 등에 쓰기 좋습니다. tolerance는 몇 ms 차이로 노드가 바끼는 현상을 줄여 줍니다.

프로브 대상까지의 지연이 모든 서비스와 1:1로 같지는 않지만, 자동화가 필요할 때 현실적인 대용입니다. 이그레스 조건이 까다로운 스트리밍만 따로 쓰고 싶다면, 해당 서비스용 select를 따로 두어 자동 선택을 덮어쓸 수 있게 규칙을 짜면 됩니다.

proxy-groups:
  - name: "Auto fastest"
    type: url-test
    url: "http://www.gstatic.com/generate_204"
    interval: 300        # re-test every 300 seconds
    tolerance: 50        # do not switch if within 50 ms
    proxies:
      - HK-01
      - HK-02
      - JP-01

③ fallback — 순서대로 장애 조치

fallback는 목록을 위에서부터 훑으며, 헬스 체크를 통과한 첫 프록시에 붙습니다. 실패하면 다음으로 넘어갑니다. 「가장 빠른 것이 이긴다」가 아니라 우선순위가 먼저라는 점이 url-test와 다릅니다. 원시 ping보다 「1순위가 살아 있으면 그걸 쓴다」가 중요한 업무용 흐름에 잘 맞습니다.

운영 환경에서는 안정적인 데이터센터 노드를 앞에, 비용이 낮은 후보를 뒤에 두는 식으로 미러링하기도 합니다. YAML 옆에는 나중에 손댈 사람을 위해 의도를 메모해 두세요. 순서만 바꿔도 장애 조치 의미가 바뀌는데, 파일이 「겉보기 멀쩡해」 보일 수 있기 때문입니다.

proxy-groups:
  - name: "Failover"
    type: fallback
    url: "http://www.gstatic.com/generate_204"
    interval: 180
    proxies:
      - Primary-HK
      - Backup-JP
      - Emergency-SG

④ load-balance — 연결 분산

load-balance는 여러 노드로 트래픽을 나눕니다. round-robin과 consistent-hashing이 대표적입니다. HTTPS에서는 동일 호스트명이 한 출구에 붙도록 하는 consistent-hashing이 자주 쓰이며, 세션을 출구 IP에 묶는 사이트에서 로그인이 자주 풀리는 현상을 줄이는 데 도움이 됩니다.

한 리전으로 가는 건강한 경로가 여러 개일 때 부하를 분산하고 싶다면 고려하세요. 반대로 은행·일부 SaaS처럼 단일 고정 IP를 요구하는 서비스에는 맞지 않을 수 있으니, 그런 트래픽은 select나 멤버가 하나뿐인 그룹으로 보내는 편이 안전합니다.

proxy-groups:
  - name: "Load balance"
    type: load-balance
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    strategy: consistent-hashing
    proxies:
      - HK-01
      - HK-02
      - HK-03

그룹을 겹쳐 쓰면 정책이 유연해진다

proxies 배열에는 실제 프록시 이름과 다른 그룹 이름을 함께 넣을 수 있습니다. 이렇게 계층을 쌓으면 아래층에는 지역별 url-test 풀, 위층에는 용도별 수동 선택기, 최상단에는 rules가 가리키는 단일 진입점만 두는 식으로 정리할 수 있습니다. 규칙 표는 짧게 유지되고, 대부분의 줄은 안정적인 그룹 이름 하나만 가리키면 됩니다.

순환 참조는 허용되지 않습니다. A가 B를 품고 B가 다시 A를 품으면 결정적인 경로를 계산할 수 없습니다. 잘 모르겠으면 종이에 그래프를 그려 보세요. 잎은 실제 프록시, 중간 노드는 그룹, 간선은 proxies 목록을 따릅니다. 방향 그래프가 순환이 없으면 예측 가능하고, 순환이 있으면 코어 버전에 따라 오류나 정의되지 않은 동작이 날 수 있습니다.

proxy-groups:
  # Tier 1: regional pools (url-test per region)
  - name: "HK pool"
    type: url-test
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    proxies: [HK-01, HK-02, HK-03]

  - name: "JP pool"
    type: url-test
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    proxies: [JP-01, JP-02]

  # Tier 2: manual pick among regions
  - name: "Pick region"
    type: select
    proxies:
      - HK pool
      - JP pool
      - DIRECT

  - name: "Streaming"
    type: select
    proxies:
      - US-01
      - JP pool

끝까지 이어지는 YAML 예시

아래는 일상 사용에 가까운 층 구조입니다. 최상위 선택기, 자동 최저 지연 풀, 스트리밍 전용 선택, 지역별 url-test, 마지막에 직접 연결로 돌아갈 수 있는 캐치올까지 포함합니다. 이름은 자신의 proxies 섹션에 맞게 바꿉니다.

proxy-groups:
  - name: "Main"
    type: select
    proxies: [Auto, HK, JP, US, DIRECT]

  - name: "Auto"
    type: url-test
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    proxies: [HK-01, HK-02, JP-01, SG-01]

  - name: "Streaming"
    type: select
    proxies: [US, JP, HK]

  - name: "HK"
    type: url-test
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    proxies: [HK-01, HK-02]

  - name: "JP"
    type: url-test
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    proxies: [JP-01, JP-02]

  - name: "US"
    type: url-test
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    proxies: [US-01, US-02]

  - name: "Catch-all"
    type: select
    proxies: [Main, DIRECT]

프록시 그룹과 rules는 어떻게 맞물리나

rules는 정책 대상으로 그룹 이름을 적습니다. 예를 들어 국내 도메인은 DIRECT, 스트리밍 목록은 Streaming, 마지막 MATCH는 Main이나 Catch-all로 보내는 식입니다. 이름이 흔들리면 안 됩니다. rules와 proxy-groups 어느 한쪽에 오타가 있으면 조용히 엉뚱한 출구로 가거나, 라우팅이 깨집니다.

GEOIP, DOMAIN-SUFFIX, PROCESS-NAME 같은 정책 규칙은 모두 문자열 타깃으로 연결을 넘깁니다. 그 타깃은 프록시 이름·그룹 이름이거나 DIRECT / REJECT 같은 내장 키워드여야 합니다. 그래서 숙련자들이 그룹 이름을 바꿀 때 규칙 전체를 함께 고치는 이유입니다. 「HK」를 「HongKong」으로 바꾸면 예전 토큰을 참조하던 모든 규칙 줄을 손봐야 합니다.

그룹 구성을 바꾼 뒤에는 클라이언트가 프로필을 캐시하고 있으면 재시작이나 「프로필 업데이트」가 필요할 수 있습니다. Clash Meta를 최신으로 따라가는 빌드를 쓰려면 다운로드 페이지에서 설치·업데이트 경로를 통일해 두는 편이 덜 헷갈립니다.

타입 고르기 빠른 비교

무엇을 써야 할지 막막하면 사용 의도부터 보세요. 감사·테스트용으로 노드를 고정해야 한다면 select. 클라이언트가 ping을 쫓아 자동으로 고르게 하려면 url-test. 1·2순위 이야기가 명확하면 fallback. 건강한 노드 여러 개로 부하를 나누려면 load-balance와 장기 HTTPS 흐름에 consistent-hashing을 염두에 두면 됩니다.

한 스택 안에서 타입을 섞는 것은 흔합니다. 맨 위는 사람이 고르는 select, 아래 층은 지역별 url-test, 관리용 노드만 fallback 체인으로 묶는 식입니다. 요령은 사용자에게 보이는 표면은 좁게 유지하면서도, 비상 시 DIRECT·REJECT는 필요한 곳에 노출하는 것입니다.

자주 하는 실수

• 유령 이름: 구독에서 빠진 프록시를 그대로 참조하면 목록에 끊긴 항목이 남습니다. 제공자가 노드를 갱신할 때마다 그룹도 정리합니다.
• 과도한 재측정: interval을 지나치게 짧게 잡으면 똑똑해 보이지만, 요금제·레이트 리밋·노트북 배터리에는 불리할 수 있습니다.
• tolerance 설정: 0이면 노이즈 많은 회선에서 노드가 자주 바끼고, 너무 크면 평범한 노드에 붙어 있기도 합니다. 실사용에 맞춰 조절합니다.
• 규칙 불일치: 다른 프로필에서 규칙만 복사하고 그룹 이름을 맞추지 않으면, 전부 엉뚱한 출구로 가는 가장 빠른 지름길이 됩니다.

실무 튜닝 팁

• 간격: url-test와 fallback에는 보통 180~300초가 무난합니다. 너무 공격적이면 배터리·대역을 태우고, 너무 느리면 나쁜 노드에 오래 붙습니다.
• 프로브 URL: 제공자가 허용하는 엔드포인트를 쓰세요. 공개 204 URL이 흔하고, 일관성을 위해 자기 도메인에 미러하는 사용자도 있습니다.
• 이름: UTF-8(이모지 포함)도 가능하지만, rules와 중첩 참조에서 한 글자라도 같아야 하며 대소문자를 구분합니다. 손으로 편집한다면 단순 ASCII가 실수가 적습니다.
• 깊이: 깊게 중첩하면 강력하지만, 신규 사용자에게는 혼란만 줄 수 있습니다. 최상위 그룹만 문서화하고 YAML 안의 「공개 API」처럼 다루세요.
• 로그: 이상하면 연결 로그에서 어떤 그룹 이름이 흐름을 잡았는지 확인한 뒤, 중첩을 거슬러 올라가 실제 프록시까지 추적합니다.

믿기 전에 검증하기

구조를 손댔다면 프로필을 다시 불러온 뒤, 대표적인 사이트 몇 곳을 직접 열어 보세요. DIRECT가 맞는 국내 뉴스, 검색 엔진, 그리고 본인이 가장 민감한 서비스(스트리밍, 클라우드 콘솔, 게임 런처)입니다. 한 카테고리만 이상하면 그에 매칭된 규칙과 타깃 그룹이 아직 존재하는지부터 좁혀 갑니다.

대량 수정은 백업 YAML을 버전 관리에 두면 롤백이 쉽습니다. 구독 번들 전체를 다시 받느니 텍스트 diff가 낫습니다. 파서나 생태계 변화는 Clash 블로그에서 가끔 확인해 두면 도움이 됩니다.

자주 묻는 질문

일회성 VPN 토글과 비교하면, Clash는 의도는 규칙에, 실행은 그룹에 나누어 구조적으로 잡을 수 있습니다. 잘 관리되는 클라이언트일수록 그 스택을 매일 쓰기 편해집니다. Clash를 무료로 받아 직접 차이를 확인해 보세요.