이 글이 맞는 독자
검색창에 Clash for Windows(약칭 CFW)와 함께 노드 바꾸기, 지연 측정, 정책 그룹 같은 말을 넣었다면, 이미 클라이언트는 실행 중이고 구독이나 프로필도 어느 정도 들어간 상태일 가능성이 큽니다. 다만 메뉴 이름이 영문이라 어디서 클릭해야 하는지, 측정 숫자가 체감 속도와 왜 다른지 헷갈리기 쉽습니다.
이 문서는 다운로드·첫 설치·구독 URL 붙여 넣기 같은 입문 단계를 일부러 건너뛰고, Proxies(노드 목록) 화면을 중심으로 수동 전환 → 일괄 지연 테스트 → 정렬로 후보 좁히기 흐름만 압축해서 정리합니다. 버전과 스킨에 따라 단추 문구가 조금 다를 수 있으나, 큰 줄기는 동일한 경우가 많습니다.
잠깐만: CFW 유지 보수 전제
원 Clash for Windows 프로젝트는 공개 저장소 기준으로 적극 유지 단계가 아닌 빌드로도 알려져 있습니다. 그래도 과거 자료·습관으로 CFW를 쓰는 분이 많아, ‘화면에서 노드만 갈아타는 법’은 여전히 자주 찾습니다. 보안 패치나 신규 프로토콜 대응이 필요하면 Clash Verge Rev처럼 활발히 갱신되는 클라이언트를 함께 보는 편이 안전합니다. 이 글의 조작 설명은 UI 패턴을 이해하는 데 초점을 둡니다.
Proxies 화면 구조 익히기
좌측 또는 상단 메뉴에서 Proxies를 열면, 대개 정책 그룹(proxy-groups)이 접혀 있다가 펼치면 그 아래에 개별 노드(proxies) 목록이 보입니다. 그룹 이름은 구독 제공자가 만든 YAML에 따라 GLOBAL, Proxy, ♻️ 자동 선택, 🎬 스트리밍처럼 제각각입니다.
사용자가 클릭으로 고르는 대상은 보통 두 겹입니다. 첫째, 어느 정책 그룹에서 결정을 내릴지(예: 메인 회선 그룹). 둘째, 그 안에서 어느 후보 노드를 활성으로 둘지입니다. 규칙 기반 클라이언트에서는 특정 트래픽이 어떤 그룹으로 보내지는 rules 절에 묶여 있으므로, ‘바꿔도 반응이 없다’면 실제 트래픽이 다른 그룹을 타고 있는지 의심해 봐야 합니다.
| 용어 | 한 줄 설명 |
|---|---|
| 정책 그룹 | 여러 노드 후보를 묶어 수동·자동·폴백 등 방식으로 하나를 고르게 하는 단위입니다. |
| 활성 노드 | 그룹 안에서 현재 선택되어 굵게·강조 표시된 항목입니다. 클릭 한 번으로 바뀝니다. |
| 지연(ms) | 테스트 대상까지 왕복에 가까운 응답 시간 추정치입니다. 구현·URL에 따라 체감과 괴리가 날 수 있습니다. |
노드 수동 전환(가장 먼저 익힐 동작)
수동 전환은 가장 확실하게 ‘지금 이 그룹은 이 회선이다’라고 고정하는 방법입니다.
- Proxies 탭을 연다.
- 사용 중인 메인 그룹(예:
Proxy,🔰 메인등)을 펼친다. - 목록에서 원하는 회선 이름을 한 번 클릭한다. 선택이 바뀌면 UI에 즉시 반영되는 경우가 대부분이다.
- 브라우저에서 테스트 페이지를 새로 고침하거나, 터미널에서
curl로 외부 IP 확인 등 짧은 검증을 한다.
여기서 막힌다면 (1) 화면 상단 프로필이 활성인지, (2) General에서 시스템 프록시나 코어가 꺼져 있지 않은지부터 확인하세요. 노드 이름은 보이는데 트래픽이 안 바뀐다면, 방금 고른 그룹이 규칙상 해당 사이트에 쓰이지 않는 그룹일 수 있습니다.
일괄 지연 측정(‘원클릭 속도’에 가까운 기능)
CFW 계열 UI에는 그룹 상단이나 하단에 번개 아이콘·지연 테스트·Latency Test 류의 단추가 있는 경우가 많습니다. 누르면 해당 묶음 또는 전체 후보에 대해 짧은 핑·HTTP 헤드 요청류를 날려 숫자를 채웁니다.
이때 기억할 점은 세 가지입니다. 첫째, 측정 대상 URL과 방식은 설정과 코어 버전에 따라 다릅니다. 둘째, 방화벽·다른 VPN·사내 보안 에이전트가 테스트 패킷을 버리면 전부 타임아웃으로 보일 수 있습니다. 셋째, 숫자는 ‘대역폭이 얼마나 나오나’가 아니라 짧은 왕복이 성공했는지에 가깝습니다.
- 숫자가 안정적으로 작다: 그 테스트 조건에서는 후보가 살아 있다는 뜻에 가깝습니다.
- 간헐적으로 튄다: Wi-Fi 혼잡, 무선 절전, 백그라운드 업데이트 등 외부 요인을 의심합니다.
- timeout·실패: 서버 다운·포트 막힘·로컬 차단 가능성이 큽니다. 다른 그룹에서도 같으면 로컬 환경을 먼저 봅니다.
지연 정렬로 빠르게 ‘답’ 찾기
후보가 수십 줄을 넘어가면 눈으로 전부 비교하기 어렵습니다. UI에 정렬 옵션이 있거나, 헤더 클릭으로 지연 오름차순을 토글할 수 있는 빌드라면 이를 활용하세요. 흔한 워크플로는 다음과 같습니다.
- 먼저 일괄 지연 테스트를 돌려 숫자를 채운다.
- 지연 오름차순으로 정렬한다.
- 상위 몇 개를 번갈아 수동 선택해 실제 이용 시나리오(웹·메신저·터미널)로 확인한다.
- 체감이 이상하면 상위권을 고집하지 말고 중간대도 시험한다.
이 과정이 바로 많은 사용자가 말하는 ‘원클릭으로 줄 세워 보고 골라 쓰기’에 가깝습니다. 다만 정렬은 측정 시점의 스냅샷일 뿐이므로, 장시간 세션에서는 가끔 다시 재생합니다.
YAML 쪽 이야기: url-test·fallback·load-balance
화면에서 보이는 일부 그룹은 코어가 주기적으로 지연을 다시 재고 자동으로 후보를 바꿉니다. 대표적으로 url-test는 일정 간격으로 측정해 가장 얕은 숫자 쪽을 고릅니다. fallback은 순서대로 내려가며 살아 있는 첫 후보를 씁니다. load-balance는 부하를 나누는 패턴입니다.
사용자 입장에서는 수동으로 클릭한 값이 잠시 후 자동 그룹이 덮어쓸 수 있다는 점만 기억하면 됩니다. “내가 고른 건데 왜 바뀌지?”라는 느낌이 든다면, 지금 보고 있는 그룹 타입이 자동인지 YAML이나 제공자 문서로 확인하세요. 반대로, 수동 그룹이라면 안정적인 회선 하나를 길게 고정하고 심리적 스트레스를 줄이는 전략도 흔합니다.
규칙과 정책 그룹이 엇갈릴 때
가끔 Proxies에서 A 그룹만 바꾸는데 실제 연결은 B 그룹을 타는 착시가 생깁니다. rules에서 특정 도메인 묶음이 DIRECT로 빠지거나, 스트리밍 전용 그룹으로 라우팅되는 경우가 대표적입니다.
이때는 Rules 탭에서 해당 트래픽이 어느 줄에 매칭되는지 대략만 훑어도 원인이 드러나는 경우가 많습니다. 초보 단계에서는 YAML을 직접 뜯기보다, 제공자가 배포한 프로필 설명이나 커뮤니티 FAQ를 함께 읽는 편이 시간 대비 효율이 좋습니다.
한 페이지 요약 워크플로
실사용에서 자주 쓰는 순서를 다시 압축하면 다음과 같습니다. ① 활성 프로필 확인 → ② Proxies에서 메인 그룹 펼치기 → ③ 일괄 지연 측정 → ④ 정렬 후 상위 후보 몇 개를 번갈아 수동 선택 → ⑤ 실제 사이트·앱으로 짧게 검증. 장애가 길게 이어지면 같은 순서를 다른 그룹에도 반복하되, 전부 막힐 때는 로컬 네트워크·방화벽을 우선 의심합니다.
자주 묻는 질문
숫자 옆 ms는 정확한 핑인가요?
반드시 ICMP 핑과 같지는 않습니다. 클라이언트는 HTTP 기반 헬스 체크나 코어 기본값에 가까운 방식을 쓰는 경우가 많고, 그 대상 서버가 사용자의 실제 목적지와 다를 수 있습니다. 그래서 상대 비교용으로 쓰는 편이 안전합니다.
다른 Clash 계열 앱에도 통하나요?
큰 그림은 비슷하지만 메뉴 이름과 단추 배치는 다릅니다. 예를 들어 Clash Verge Rev나 Android 측 앱은 ‘프로필·프록시’ 구조가 조금씩 달라서, 이 글의 스크린 용어를 그대로 기대하긴 어렵습니다. 다만 그룹 펼치기 → 후보 클릭 → 측정·정렬이라는 행동 단위는 이식됩니다.
아주 옛 CFW 빌드인데 버튼이 없어요.
빌드 시점에 따라 지연 일괄 버튼·정렬이 빠진 포크도 있습니다. 그럴 때는 상위 릴리스로 올리거나, 프록시 화면에서 개별 줄 우측의 작은 지연 아이콘만 있는 경우도 있습니다. 그래도 없다면 외부 핑 도구로 대략만 보고 수동 전환에 의존해야 합니다.
도구를 바꿀 때와 Clash를 고를 때
브라우저 확장만 켜 두고 특정 사이트만 우회하는 방식은 빠르게 시작할 수 있지만, 앱마다 따로 프록시 포트를 넣거나 예외를 반복해야 하는 번거로움이 생깁니다. 반대로 일부 상용 VPN 클라이언트는 회선 목록은 단순한 대신 룰·그룹 단위 세밀 제어가 부족해 ‘이 도메인만 다른 노드’ 같은 요구에 답답함이 남기도 합니다.
Clash 계열은 구독과 YAML을 통해 정책 그룹·규칙·측정을 한 화면에 모아 두는 편이라, 오늘 정리한 수동 전환과 지연 정렬을 루틴으로 삼으면 회선 실험 비용이 줄어듭니다. CFW가 레거시로 남는 추세라면, 같은 습관을 최신 클라이언트로 옮겨도 워크플로 자체는 크게 달라지지 않습니다. 새 환경을 찾는다면 플랫폼별 빌드를 한곳에서 비교할 수 있는 다운로드 허브를 함께 보는 편이 링크 추적 시간을 줄여 줍니다.