SELECTION BASELINE

먼저 노드 선택 목표 정하기

Clash 노드를 고를 때 지연 시간이 가장 낮다고 해서 실제 사용 경험이 가장 좋은 것은 아닙니다. 현재 작업에 적합한 노드인지는 연결 안정성, 가용 대역폭, 네트워크 경로, 목적지 지역, 트래픽 배율, 클라이언트 지원 여부에 따라 달라집니다. 웹 브라우징, 동영상 재생, 대용량 파일 다운로드, 실시간 통화와 원격 개발은 각각 요구하는 회선 조건이 다르므로 한 번의 지연 시간 수치만 보고 판단하면 쉽게 결론을 그르칠 수 있습니다.

일반적인 웹 접속은 연결 수립 속도와 안정성이 중요합니다. 동영상 재생에는 지속적인 대역폭이 필요합니다. 버퍼링이 끝난 뒤 일시적으로 지연 시간이 높아지는 것은 재생에 큰 영향을 주지 않을 수 있지만, 짧은 시간의 패킷 손실과 큰 지터는 화질 저하를 일으킵니다. 음성 통화, 회의와 게임은 낮은 지터, 낮은 패킷 손실, 안정적인 왕복 시간에 더 크게 의존합니다. 대용량 파일 다운로드는 주로 지속 처리량을 확인하되, 노드 배율에 따른 트래픽 소모도 함께 고려해야 합니다.

선별을 시작하기 전에 용도를 일상 기본 노드, 특정 지역 노드, 고대역폭 임시 노드의 세 가지로 나누세요. 일상 노드는 안정성을 우선해 규칙 모드에서 대부분의 프록시 트래픽 출구로 사용하기 좋아야 합니다. 특정 지역 노드는 지역에 따라 결과가 달라지는 서비스에 사용합니다. 고대역폭 노드는 업데이트, 동기화 또는 다운로드에 적합하지만 장시간 연결을 유지하는 용도로는 적합하지 않을 수 있습니다. 모든 상황을 충족하는 ‘가장 빠른 노드’ 하나를 찾는 것보다 이런 분류가 더 안정적입니다.

LATENCY TEST

Clash 지연 시간 테스트 제대로 이해하기

Clash 클라이언트의 지연 시간 테스트는 일반적으로 시스템 명령의 ICMP Ping과 다릅니다. 보통 해당 프록시 노드를 통해 테스트 주소에 요청을 보내고, 연결을 수립해 응답을 받기까지 걸린 시간을 측정합니다. 따라서 프록시 경로의 HTTP 또는 HTTPS 연결성을 확인하는 데 더 가깝지만, 여전히 소량 요청에 대한 한 번의 테스트일 뿐 지속적인 다운로드 속도를 직접 나타내지는 않습니다.

같은 노드를 연속으로 테스트해도 결과가 달라질 수 있습니다. 로컬 Wi-Fi 변동, 통신사 네트워크 혼잡, 프록시 서버 부하, 국제 라우팅 변화, DNS 확인 시간, 테스트 대상의 응답 속도 등이 원인입니다. 첫 번째 테스트에는 도메인 확인, TCP 연결 수립 또는 TLS 핸드셰이크 비용이 포함될 수 있고, 이후 테스트에서는 캐시가 재사용되어 수치가 더 낮게 나올 수 있습니다. 판단할 때는 최솟값 하나가 아니라 여러 결과의 범위를 확인해야 합니다.

지연 시간 수치는 어떻게 읽어야 할까

  • 수치가 안정적임: 여러 번 측정한 결과가 비슷하다면 목록에서 가장 낮은 수치가 아니어도 일반적인 사용에 적합한 경우가 많습니다.
  • 수치 변동이 큼: 인접한 테스트 사이에 수백 밀리초씩 차이가 난다면 경로나 부하가 불안정하다는 뜻이므로 더 관찰해야 합니다.
  • 시간 초과 표시: 노드를 사용할 수 없거나 테스트 주소가 해당 노드를 통해 접속되지 않는 것일 수 있으므로 한 번의 시간 초과만으로 설정에서 바로 삭제해서는 안 됩니다.
  • 지연 시간은 낮지만 다운로드가 느림: 소량 요청에 빠르게 응답한다고 해서 서버의 출구 대역폭이 충분하거나 사용량이 많은 시간대에도 처리량을 유지한다는 뜻은 아닙니다.
  • 지연 시간은 높지만 재생이 안정적임: 지속 대역폭이 충분하고 패킷 손실이 적다면 이미 버퍼링된 동영상은 원활하게 재생될 수 있습니다.

더 실용적인 방법은 3~5회 연속 테스트해 중앙값과 변동 범위를 기록하는 것입니다. 예를 들어 두 노드의 중앙 지연 시간이 각각 80ms와 110ms인데 첫 번째 노드는 자주 600ms까지 튀고 두 번째 노드는 계속 100~130ms를 유지한다면, 회의·원격 터미널·지속적인 웹 브라우징에는 보통 두 번째 노드가 더 적합합니다.

모든 노드가 동시에 시간 초과된다면 먼저 구독이 최신 상태인지, 설정이 정상적으로 로드되었는지, 기기 네트워크가 정상인지, Clash 코어가 실행 중인지 확인하세요. 특정 정책 그룹만 시간 초과된다면 그룹 안의 노드가 유효한지도 확인해야 합니다. TUN 모드를 활성화한다고 노드 지연 시간이 자동으로 낮아지는 것은 아닙니다. TUN은 트래픽이 프록시 코어로 들어가는 방식을 바꿀 뿐이며, 실제 경로 품질은 로컬 네트워크·노드 서버·목적지 네트워크가 함께 결정합니다.

REGION AND ROUTE

지역과 실제 네트워크 경로 기준으로 선택하기

지역 태그는 노드 서버나 진입점이 위치한 지역을 나타내지만 지리적 거리는 지연 시간에 영향을 주는 여러 요인 중 하나일 뿐입니다. 어떤 통신사를 거치는지, 우회 경로인지, 진입점과 출구가 분리되어 있는지에 따라 실제 결과가 달라집니다. 가까운 노드라도 상호 접속 품질이 나쁘면 지연 시간이 더 높을 수 있고, 먼 노드라도 안정적인 회선을 이용하면 지터가 더 낮을 수 있습니다.

일상용 노드를 고를 때는 지리적으로 가까운 지역부터 테스트한 뒤, 다른 지역의 노드 한두 개를 예비로 남겨두세요. 모든 후보를 같은 지역에 두면 지역 네트워크 장애, 서버 점검 또는 저녁 시간대 혼잡이 여러 노드에 동시에 영향을 줄 수 있습니다. 예비 노드는 계속 방치하는 것이 아니라 주 노드에서 연속적인 시간 초과나 속도 저하가 발생했을 때 빠르게 전환하기 위한 것입니다.

지역 선택 시 자주 확인할 기준

사용 시나리오 우선 확인할 항목 추가 확인 사항
웹 브라우징 및 검색 연결 속도·안정성 페이지 리소스가 모두 로드되는지
동영상 재생 지속 대역폭·패킷 손실 사용량이 많은 시간대의 속도 저하 여부
실시간 회의 지연 시간·지터·패킷 손실 장시간 연결이 자주 재연결되는지
지역 제한 서비스 출구 지역 대상 서비스가 해당 출구를 인식하는지
파일 동기화 지속 처리량 배율과 잔여 트래픽

노드 이름의 지역 정보가 네트워크 경로 전체를 정확히 설명하지는 않습니다. 일부 서비스는 중계 진입점을 사용하므로 노드 이름에는 출구 지역이 표시되어도 실제로는 다른 위치의 진입점에 먼저 연결될 수 있습니다. 이름에 회선 코드나 통신사 약어가 포함되기도 합니다. 확인하기 어렵다면 실제 테스트 결과와 서비스 제공업체가 안내한 노드 설명을 기준으로 판단하세요.

‘대상 서비스의 지역’과 ‘프록시 노드의 지역’도 구분해야 합니다. 전 세계 CDN에 배포된 웹사이트에 접속하면 노드에 따라 출구와 가까운 엣지 서버가 할당될 수 있으므로 출구 지역이 콘텐츠 전달 경로에 영향을 줍니다. 지역 조건이 없는 일상적인 접속에는 안정적이고 경로가 짧은 노드를 우선 선택하고, 대상 서비스가 지역을 명확히 요구할 때만 출구 위치를 최우선 조건으로 삼으세요.

TRAFFIC RATE

배율과 실제 트래픽 비용 판단하기

노드 배율은 일반적으로 구독 서비스가 사용하는 트래픽 과금 계수이며 Clash 프로토콜 자체의 속성이 아닙니다. 1배로 표시된 노드에서 데이터 1GB를 사용하면 보통 요금제에서 1GB로 계산되고, 2배라면 같은 전송량이 2GB로 집계될 수 있습니다. 구체적인 집계 범위와 계산 방식은 구독 서비스 안내를 따라야 합니다. Clash 클라이언트는 설정에 있는 노드를 사용할 뿐 배율 규칙을 통일해 정의하지 않습니다.

배율이 높다고 반드시 더 빠른 것은 아닙니다. 높은 배율은 비용이 더 높은 회선, 혼잡이 적은 진입점 또는 특정 지역 리소스를 의미할 수 있지만 노드의 현재 부하는 계속 변합니다. 반대로 낮은 배율의 노드도 사용량이 적은 시간대에는 충분한 속도를 제공할 수 있습니다. 따라서 배율은 비용 지표로 보고 지연 시간·안정성·처리량과 분리해 평가해야 합니다.

작업별 배율 선택

  1. 일상적인 웹 브라우징과 메신저에는 안정적인 일반 배율 노드를 우선 사용해 잦은 수동 전환을 줄이세요.
  2. 시스템 이미지, 게임 업데이트와 클라우드 동기화는 많은 트래픽을 사용하므로 먼저 잔여 할당량을 확인한 다음 낮은 배율 노드의 지속 속도를 비교하세요.
  3. 지역이나 회선에 명확한 조건이 있는 임시 작업에는 높은 배율 노드를 사용하고, 작업이 끝나면 기본 정책으로 돌아가세요.
  4. 속도 테스트 자체도 트래픽을 소모합니다. 대용량 파일 테스트를 연속으로 실행하면 사용량이 빠르게 늘어나므로 모든 노드에 반복해서 실행하기에는 적합하지 않습니다.

PROTOCOL REVIEW

주요 프록시 프로토콜과 클라이언트 지원 비교

구독 목록에는 Shadowsocks, VMess, VLESS, Trojan, Hysteria2, TUIC 등의 노드가 함께 포함될 수 있습니다. 프로토콜은 연결 및 전송 방식을 결정하지만 프로토콜 이름만으로 노드가 더 빠르다고 증명할 수는 없습니다. 서버 위치, 회선 대역폭, 혼잡도, 전송 계층 설정과 클라이언트 코어 버전이 더 큰 영향을 미치는 경우가 많습니다.

Shadowsocks

Shadowsocks는 설정이 비교적 단순하며, 일반적인 Clash 코어는 다양한 암호화 방식을 지원합니다. 실제 사용 가능 여부는 클라이언트 코어가 노드에 지정된 암호화 방식이나 확장 형식을 지원하는지에 달려 있습니다. 구독을 가져온 뒤 cipher, plugin 또는 unsupported 관련 오류가 표시된다면 지연 시간을 반복해서 테스트하기보다 먼저 코어 지원 여부를 확인하세요.

VMess와 VLESS

VMess와 VLESS는 TCP, WebSocket, gRPC, TLS 등의 전송 설정과 함께 사용되는 경우가 많습니다. VLESS 자체가 특정 회선 품질을 보장하는 것은 아니며 Reality, TLS 또는 기타 보안 전송 매개변수도 코어가 올바르게 지원해야 합니다. 구버전 Clash 코어와 Clash Meta 기반의 현재 mihomo 코어는 프로토콜 및 확장 기능 지원 범위가 다를 수 있습니다. 구독에 새 필드가 나타나면 해당 설정 형식을 계속 지원하는 클라이언트와 코어를 사용해야 합니다.

Trojan

Trojan은 일반적으로 TLS 연결에서 동작하며 설정에 서버 이름, 인증서 검증과 전송 계층 매개변수가 포함됩니다. 기기 시간이 잘못되었거나 도메인 확인에 문제가 있거나 서버 인증서에 오류가 있으면 핸드셰이크가 실패할 수 있습니다. 이런 장애는 보통 노드가 연결을 수립하지 못하는 형태로 나타나므로 단순히 지연 시간이 높다고 오해해서는 안 됩니다.

Hysteria2와 TUIC

Hysteria2와 TUIC는 UDP 기반 전송을 사용합니다. 지연 시간이 높거나 일정한 패킷 손실이 있는 네트워크에서는 처리량이 더 좋을 수 있지만, 로컬 네트워크·라우터·통신사 경로가 UDP 전송을 정상적으로 지원해야 합니다. 일부 회사 네트워크, 공용 Wi-Fi 또는 방화벽은 UDP를 제한하므로 이때 노드가 시간 초과될 수 있습니다. TCP 기반 후보 노드로 전환하면 문제의 원인을 더 쉽게 판단할 수 있습니다.

프로토콜 선택은 호환성을 우선해야 합니다. 먼저 클라이언트 코어가 설정을 해석하고 연결을 수립할 수 있는지 확인한 다음 사용 경험을 비교하세요. 여러 프로토콜 노드가 같은 진입점과 비슷한 경로를 사용한다면 실제 차이는 작을 수 있습니다. 프로토콜 이름이 새롭다는 이유만으로 기본값으로 지정할 필요는 없으며, 오류 로그가 없는데 구독에서 생성된 프로토콜 매개변수를 임의로 수정해서도 안 됩니다.

PROXY GROUPS

Clash 정책 그룹으로 자동 선별하기

노드가 많다면 정책 그룹을 활용해 수동 전환을 줄일 수 있습니다. Clash와 mihomo 설정에서 자주 사용하는 정책 그룹에는 select, url-test, fallback, load-balance가 있습니다. 각각 해결하는 문제가 다르므로 그룹 이름만 보고 동작을 판단해서는 안 됩니다.

  • select: 사용자가 노드나 하위 정책 그룹을 직접 선택합니다. 기본 출구와 특정 지역 선택에 적합합니다.
  • url-test: 후보 노드를 주기적으로 테스트하고 결과에 따라 조건을 충족하는 낮은 지연 시간의 노드를 선택합니다.
  • fallback: 후보를 순서대로 확인하고 앞의 노드를 사용할 수 없을 때 다음 노드로 전환합니다.
  • load-balance: 설정된 정책에 따라 여러 노드에 연결을 분산합니다. 단일 다운로드 연결의 대역폭을 단순히 합산하는 방식은 아닙니다.

간단한 자동 테스트 그룹은 아래와 같은 구조로 구성할 수 있습니다. 실제 필드 지원 여부는 사용하는 코어 버전에 따라 달라지며, 노드 이름은 설정에 있는 프록시 항목과 일치해야 합니다.

proxy-groups:
  - name: AUTO
    type: url-test
    proxies:
      - HK-01
      - SG-01
      - JP-01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

interval은 테스트 간격을 제어하며 너무 짧게 설정하면 요청 횟수와 리소스 사용량이 늘어납니다. tolerance는 지연 시간 차이가 작을 때 잦은 전환을 줄이는 데 사용합니다. 코어 버전에 따라 전환 조건과 상태 확인 필드의 구현이 다를 수 있으므로 수정하기 전에 현재 코어의 설정 문서를 확인하세요.

자동 선택에는 후보 노드의 품질과 지역별 용도가 비슷한 그룹이 적합합니다. 서로 다른 지역·배율·용도의 노드를 하나의 url-test 그룹에 모두 넣으면 지연 시간이 가장 낮은 노드가 지역 조건에 맞지 않거나 트래픽 비용이 더 높을 수 있습니다. 지역이나 용도별로 먼저 그룹을 나눈 뒤 그룹 내부에서 자동 테스트하고, 최상위에서는 ‘자동 노드’, ‘특정 지역’ 또는 ‘수동 선택’을 select로 고르는 구성이 더 합리적입니다.

규칙 모드는 도메인, IP, 프로세스 또는 기타 규칙에 따라 연결을 지정된 정책 그룹으로 보냅니다. 노드 선택은 정책 그룹이 최종적으로 사용할 출구만 결정하며, 규칙이 위에서 아래로 매칭되고 일치하면 중지되는 기본 로직은 바꾸지 않습니다. 특정 웹사이트가 예상한 노드를 사용하지 않는다면 노드만 바꾸지 말고 규칙 매칭 결과와 정책 그룹의 현재 선택을 함께 확인하세요.

TEST PROCESS

재현 가능한 노드 선별 절차 만들기

신뢰할 수 있는 선별은 비슷한 로컬 네트워크 조건과 비슷한 시간대에 진행해야 합니다. Wi-Fi로 테스트한다면 먼저 기기 신호가 안정적인지 확인하고 백그라운드의 대용량 다운로드, 클라우드 동기화와 시스템 업데이트를 일시 중지하세요. 모바일 네트워크와 유선 인터넷은 경로가 다르므로 한 네트워크에서 가장 좋았던 노드가 네트워크를 바꾼 뒤에도 우수하다는 보장은 없습니다.

  1. 구독 업데이트: 클라이언트가 최신 설정을 로드했는지 확인해 이미 종료되었거나 매개변수가 변경된 노드를 계속 테스트하지 않도록 합니다.
  2. 전체 그룹 연결성 테스트 한 번 실행: 계속 시간 초과되거나 핸드셰이크에 실패하거나 설정을 지원하지 않는 노드를 제외합니다.
  3. 후보를 소수로 추리기: 목표 지역에서 지연 시간이 낮고 변동이 작은 노드 3~5개를 남깁니다.
  4. 반복 테스트: 수십 초 간격으로 여러 번 테스트해 중앙 지연 시간, 최댓값과 시간 초과 횟수를 확인합니다.
  5. 실제 작업으로 검증: 자주 사용하는 웹페이지를 열고 동영상을 재생하거나 짧게 다운로드하면서 로딩, 처리량과 재연결 여부를 확인합니다.
  6. 배율과 할당량 확인: 사용 경험이 비슷하다면 트래픽 비용이 적절한 노드를 우선 선택합니다.
  7. 예비 노드 유지: 다른 서버 또는 다른 지역의 후보를 남겨 주 노드에 장애가 발생했을 때 전체 목록에서 다시 선별하지 않도록 합니다.

테스트 결과는 시간대별로 기록하는 것이 좋습니다. 오전에는 안정적이던 노드가 저녁에 뚜렷하게 느려진다면 일반적으로 사용량이 많은 시간대의 부하나 네트워크 상호 연결이 변한 것입니다. 새벽에 한 번만 속도를 측정한 결과로는 일상적인 사용 시간대를 대표할 수 없습니다. 업무용이라면 오전·오후·저녁에 각각 짧게 테스트하고 하루나 이틀 동안 계속 관찰한 뒤 기본 노드를 정하세요.

노드를 바꿔도 이미 연결된 세션이 새 노드로 즉시 이동하지는 않습니다. 브라우저 연결 풀, 다운로드 작업, 동영상 세션과 터미널의 장시간 연결은 연결이 종료되거나 시간 초과될 때까지 기존 출구를 계속 사용할 수 있습니다. 새 노드를 검증할 때는 테스트 페이지를 다시 열거나 관련 연결을 재시작하세요. 시스템 프록시나 TUN을 활성화했다면 대상 애플리케이션의 트래픽이 실제로 Clash에 들어오는지도 확인해야 합니다. 클라이언트 화면에서 노드를 선택했다고 모든 애플리케이션이 해당 노드를 사용한다는 뜻은 아닙니다.

ERROR CHECK

흔한 오판과 해결 방법

목록에서 지연 시간이 가장 낮은 노드만 선택하기

최솟값은 우연한 한 번의 테스트 결과이거나 테스트 주소의 응답만 반영한 수치일 수 있습니다. 반복 횟수를 늘리고 자주 사용하는 서비스로 검증하세요. 최저 지연 노드가 자주 끊긴다면 조금 느리더라도 안정적인 노드가 기본 출구로 더 적합합니다.

속도 테스트 실패만으로 구독이 만료되었다고 판단하기

노드 하나의 실패와 전체 구독의 무효화는 별개의 문제입니다. 먼저 다른 노드가 연결되는지 확인한 뒤 클라이언트 로그에서 DNS, 핸드셰이크, 시간 초과, 프로토콜 미지원 또는 네트워크 연결 불가 정보를 확인하세요. 모든 노드가 동시에 실패할 때만 구독 업데이트, 설정 로드와 로컬 프록시 상태를 추가로 점검하면 됩니다.

노드를 바꾼 뒤에도 접속이 되지 않기

문제가 노드가 아니라 규칙에 있을 수 있습니다. 현재 모드가 규칙·글로벌·직접 연결 중 무엇인지 확인하고 대상 연결이 어떤 정책 그룹에 매칭되었는지 확인하세요. DNS 캐시, 브라우저의 기존 연결과 대상 서비스 자체의 장애도 전환 후 즉시 복구되지 않는 원인이 될 수 있습니다. 먼저 기존 연결을 종료한 뒤 사용 가능한 것으로 확인된 다른 웹사이트를 열어 비교 테스트를 진행하세요.

TUN 모드를 가속 옵션으로 오해하기

TUN 모드는 시스템 프록시 설정을 따르지 않는 더 많은 트래픽을 인계하는 기능입니다. 게임, 명령줄 프로그램 또는 특정 애플리케이션을 더 넓게 처리할 수 있지만 프록시 서버의 대역폭을 늘리지는 않습니다. 활성화 후 사용 경험이 달라지는 것은 대개 트래픽 경로나 DNS 처리 방식이 바뀌기 때문입니다. 문제가 생기면 테스트 빈도를 계속 높이기보다 TUN 권한, 라우팅, DNS와 애플리케이션 호환성을 확인하세요.

한 번의 대용량 파일 테스트로 트래픽을 너무 많이 소모하기

대용량 파일은 지속 처리량을 확인하는 데 유용하지만 모든 노드에서 실행할 필요는 없습니다. 먼저 소량 요청으로 후보를 추린 다음 2~3개 노드에서 짧게 실제 다운로드를 진행하세요. 테스트가 끝나면 즉시 작업을 중지하고 클라이언트 트래픽 통계와 구독 관리 화면에서 사용량을 확인하세요.

클라이언트 다운로드 및 추가 설정

기기 플랫폼에 맞는 Clash 클라이언트를 선택하고 구독을 가져온 뒤 지연 시간 테스트와 정책 그룹으로 노드를 선별하세요.

다운로드 페이지 튜토리얼 보기