Clash 노드 선택 방법: 지연 시간·배율·지역·프로토콜 4가지 지표 이해하기

먼저 노드 선택으로 해결하려는 문제를 정하세요

Clash에서 구독을 가져오면 「프록시」 화면에 수십 개에서 수백 개의 노드가 표시되는 경우가 많습니다. 노드 이름에는 국가나 지역, 회선 약어, 배율, 프로토콜, 번호가 함께 들어갈 수 있습니다. 예를 들어 “일본 IEPL 01｜0.8x” 또는 “싱가포르 Hysteria2｜1.0x”처럼 표시됩니다. 이러한 정보는 단순한 속도 순위가 아닙니다. 지연 시간은 상호작용 반응성을, 배율은 차감되는 트래픽을, 지역은 접속 경로와 콘텐츠 이용 범위를, 프로토콜은 연결 수립 방식과 전송 오버헤드를 보여줍니다.

선택하기 전에 먼저 용도를 정해야 합니다. 웹 브라우징과 원격 터미널은 낮은 지연 시간과 안정성이 중요하고, 대용량 파일 다운로드와 클라우드 동기화는 지속적인 처리량과 배율이 더 중요합니다. 지역 제한 콘텐츠를 시청하려면 먼저 올바른 지역을 선택한 뒤 회선을 비교해야 합니다. 모바일 네트워크에서 자주 전환한다면 패킷 손실과 로밍에 대한 프로토콜의 대응력도 확인해야 합니다. 노드 이름에 있는 “고속”이라는 단어만 믿거나 지연 시간 테스트를 한 번만 실행해서는 신뢰할 만한 결론을 얻기 어렵습니다.

구독 노드, 정책 그룹, 실제 출구의 관계

구독은 노드 목록과 함께 규칙을 제공할 수 있으며, 정책 그룹은 현재 사용할 노드를 선택합니다. 프록시 규칙은 특정 요청을 해당 정책 그룹으로 보낼지 결정합니다. 예를 들어 동영상 서비스는 “스트리밍” 정책 그룹으로, 웹 트래픽은 “노드 선택” 정책 그룹으로 보내도록 설정되어 있다면 “노드 선택”에서 노드를 바꿔도 동영상 앱의 출구는 바뀌지 않을 수 있습니다.

• 노드: 서버 주소, 포트, 프로토콜, 인증 매개변수를 포함하는 개별 프록시 진입점입니다.
• 정책 그룹: 노드를 수동으로 선택하거나 자동 측정, 장애 조치, 부하 분산에 사용하는 노드 집합입니다.
• 규칙: 도메인, IP, 프로세스 또는 규칙 집합에 따라 연결을 지정된 정책 그룹으로 보내거나 직접 연결합니다.
• 출구: 요청이 최종적으로 통과하는 서버이며, IP 조회 페이지나 애플리케이션 로그로 확인할 수 있습니다.

테스트를 시작하기 전에 「프록시」→대상 정책 그룹으로 이동해 다른 중첩 정책 그룹이 아니라 특정 노드를 선택했는지 확인하세요. 클라이언트에 현재 경로가 표시된다면 경로의 마지막이 실제로 원하는 지역인지도 점검해야 합니다. 문제를 확인하는 동안에는 자동 정책 그룹이 테스트 중 출구를 바꾸지 않도록 노드를 하나로 고정하는 것이 좋습니다.

지표 1: 지연 시간·지터·패킷 손실을 올바르게 읽기

Clash 그래픽 클라이언트의 지연 시간 테스트는 일반적으로 ICMP Ping이 아닙니다. 클라이언트가 노드를 통해 테스트 URL에 HTTP 요청을 보내고 연결 및 응답에 걸린 시간을 기록합니다. 흔히 204 상태를 반환하는 가벼운 페이지를 테스트 주소로 사용합니다. 이 수치는 로컬 네트워크, 프록시 서버까지의 회선, 프록시 핸드셰이크, 테스트 사이트의 응답 시간을 모두 포함하며 노드의 다운로드 속도와 같지 않습니다.

한 번 낮게 나온 지연 시간이 장기적인 안정성을 보장하지는 않습니다

같은 시각에 세 노드의 측정값이 각각 68ms, 92ms, 145ms라고 가정해 보겠습니다. 68ms 노드가 가장 빨라 보이지만, 5회 연속 테스트 결과가 68, 310, 75, 시간 초과, 240ms이고 92ms 노드가 88~105ms로 안정적이라면 후자가 동영상, 회의, 원격 작업에 더 적합합니다. 전자는 평균값과 최고값이 모두 높아 혼잡, 패킷 손실 또는 경로 변동이 있을 가능성을 보여줍니다.

같은 지역의 노드는 다음 방법으로 비교할 수 있습니다. 먼저 진행 중인 대용량 다운로드를 중지하고 동일한 네트워크에서 약 10초 간격으로 5회 연속 테스트하세요. 로컬 네트워크 단절로 발생한 것이 분명한 이상값은 하나 제외하고, 중앙값·최고값·시간 초과 횟수를 기록합니다. 지연 시간 중앙값이 낮고 최고값이 중앙값에 가까우며 시간 초과가 없는 노드를 우선순위에 두면 됩니다.

이 구간은 동일한 네트워크 환경에서 1차 선별할 때만 참고하세요. 중국 본토에서 일본 노드에 연결하는 경우와 유럽 사용자가 일본 노드에 연결하는 경우의 기준은 다릅니다. 가정용 광대역, 학교 네트워크, 회사 네트워크, 모바일 네트워크도 서로 직접 비교할 수 없습니다. 테스트는 환경과 무관한 고정 수치를 좇는 것이 아니라 실제 연결 상태를 판단하는 데 활용해야 합니다.

지연 시간은 낮지만 다운로드가 느린 흔한 원인

• 테스트 요청의 크기가 작아 서버의 최대 대역폭과 장시간 연결의 처리량을 반영하지 못합니다.
• 노드 진입점은 가깝지만 중계 회선이나 대상 웹사이트로 향하는 경로가 혼잡합니다.
• 서버의 동시 연결이 너무 많아 짧은 요청은 처리되지만 대용량 전송이 제한됩니다.
• 로컬 Wi-Fi 신호가 약하거나 공유기 부하가 높고, 통신사 피크 시간대에 혼잡이 발생합니다.
• 규칙에 따라 속도 측정 요청과 다운로드 요청이 서로 다른 정책 그룹으로 배정되었습니다.

1차 선별 후 50~200MB 크기의 고정 테스트 파일을 하나 선택해 각 노드에서 30~60초씩 다운로드하며 속도가 안정적인지 확인할 수 있습니다. 결과에 대상 사이트 차이가 섞이지 않도록 테스트 파일은 같은 서버에서 제공되어야 합니다. 측정에도 실제 트래픽이 발생하고 배율 노드는 배율에 따라 차감되므로 수백 개의 노드 모두에서 대용량 파일 테스트를 할 필요는 없습니다.

지표 2: 배율은 트래픽 차감량을 결정합니다

노드 이름의 0.5x, 1x, 1.5x, 2x는 일반적으로 구독 서비스의 트래픽 과금 배율을 뜻합니다. 실제로 데이터 1GB를 전송할 때 0.5x 노드는 요금제에서 0.5GB가 차감될 수 있고, 2x 노드는 2GB가 차감될 수 있습니다. 배율은 구독 제공자가 정하는 값이며 Clash나 Mihomo가 자동으로 계산하는 성능 점수가 아닙니다. 또한 노드 속도를 직접 나타내지도 않습니다.

실제 사용량으로 배율의 적합성을 판단하세요

월간 요금제가 100GB이고 매일 동영상을 시청하며 실제로 3GB를 사용한다고 가정해 보겠습니다. 1x 노드를 계속 사용하면 30일 동안 약 90GB가 필요하고, 1.5x 노드는 약 135GB가 차감되어 요금제를 초과합니다. 0.5x 노드는 약 45GB만 차감됩니다. 가끔 웹 페이지만 열어 본다면 배율 차이가 크지 않을 수 있지만, 시스템 업데이트·클라우드 백업·고화질 동영상이 필요하다면 속도보다 배율을 먼저 고려해야 합니다.

1. 구독 관리 화면에서 배율의 정의를 확인하고 업로드와 다운로드가 모두 차감 대상인지 확인하세요.
2. 애플리케이션 재생 시간만 보지 말고 하루 실제 전송량을 추정하세요.
3. 실제 사용량에 노드 배율을 곱한 뒤 요금제의 잔여 트래픽과 비교하세요.
4. 고배율 노드는 회선상 분명한 이점이 있을 때만 사용하고, 배율을 품질 보증으로 여기지 마세요.

저배율 노드도 피크 시간대에는 혼잡할 수 있고, 고배율 노드도 단지 비용이 더 높은 회선일 수 있습니다. 실제 선택은 두 그룹으로 나누는 것이 좋습니다. 0.5x 또는 1x의 안정적인 노드는 일상적인 트래픽에 사용하고, 지터가 낮거나 특정 지역을 이용할 수 있는 고배율 노드는 회의·라이브 방송·일시적인 작업에 남겨 두세요. 이렇게 하면 고배율 노드 하나를 계속 사용하는 것보다 사용량을 관리하기 쉽습니다.

지표 3: 지역은 경로·출구·콘텐츠 범위에 영향을 줍니다

노드 지역에는 적어도 두 가지 의미가 있습니다. 서버 진입점이 위치한 지역과 웹사이트에서 확인하는 출구 IP의 소속 지역입니다. 대부분 일치하지만 중계 회선, 지역 간 출구 또는 부정확한 노드 이름 때문에 다를 수도 있습니다. 특정 지역의 출구가 필요하다면 노드 이름의 국기나 약어가 아니라 실제 IP 위치와 대상 서비스의 결과를 기준으로 판단해야 합니다.

일상적인 브라우징은 지리적으로 가까운 지역을 우선 선택하세요

다른 조건이 비슷하다면 거리가 가까울수록 물리적 경로가 짧고 왕복 시간이 낮은 경우가 많습니다. 동아시아 네트워크 환경에서는 일본·싱가포르·한국 노드가 낮은 지연 시간의 브라우징에 자주 사용됩니다. 유럽 내 서비스에 접속할 때는 프랑크푸르트·암스테르담·런던 출구가 더 적합한 대상 경로를 제공할 수 있습니다. 실제 사용 경험을 결정하는 것은 통신사 간 라우팅과 혼잡 상태이며, 지리적 거리는 1차 선별 기준일 뿐입니다.

먼저 목표 지역에서 3~5개 노드를 고른 뒤 지연 시간을 연속으로 측정하세요. 도쿄·로스앤젤레스·런던의 지연 시간을 한 목록에 넣고 최저값 하나만 고르면 안 됩니다. 작업에 따라 필요한 출구가 다를 수 있기 때문입니다. 지역 제한 콘텐츠에 접속할 때는 “지역이 올바른가 → 서비스 이용이 가능한가 → 지연 시간과 속도가 충분한가” 순서로 확인하세요.

콘텐츠 이용 가능 여부가 달라지는 이유

• 출구 IP의 데이터베이스상 소속 지역과 노드에 표시된 지역이 일치하지 않습니다.
• 같은 지역의 서로 다른 IP 대역이 대상 서비스에서 서로 다른 정책으로 처리됩니다.
• DNS 요청은 로컬에서 해석되고 실제 연결은 프록시를 통과해 지역 판정이 충돌합니다.
• 브라우저에 이전 쿠키, 계정 지역 또는 위치 권한 정보가 저장되어 있습니다.
• 정책 규칙이 일부 도메인만 프록시로 보내 로그인·미디어·API 요청이 같은 출구를 사용하지 않습니다.

지역 인식이 잘못되면 먼저 「프록시」에서 노드를 고정한 다음 「연결」 페이지에서 대상 도메인에 적용된 규칙과 정책 그룹을 확인하세요. 이어서 대상 사이트의 사이트 데이터를 삭제하고 다시 로그인합니다. TUN 모드를 사용 중이라면 DNS와 라우팅을 현재 설정이 함께 관리하는지 점검하세요. 시스템 프록시만 사용하는 경우에는 애플리케이션이 실제로 시스템 프록시 설정을 따르는지도 확인해야 합니다.

지표 4: 프로토콜은 연결 방식을 바꾸지만 속도를 단독으로 결정하지는 않습니다

구독에서 흔히 볼 수 있는 프로토콜로 Shadowsocks, Trojan, VMess와 Mihomo가 지원하는 VLESS, Hysteria2, TUIC 등이 있습니다. 프로토콜마다 핸드셰이크, 암호화, 전송 계층, UDP 지원 방식이 다르지만 노드 속도는 서버 성능·회선 품질·대역폭 제한·로컬 네트워크·클라이언트 코어에 의해 함께 결정됩니다. 특정 프로토콜 이름만 보고 “반드시 더 빠르다”고 단정해서는 안 됩니다.

주요 프로토콜에서 확인할 항목

Hysteria2와 TUIC는 주로 UDP 전송을 사용합니다. UDP가 허용되고 회선이 적합하다면 높은 지연 시간이나 가벼운 패킷 손실 환경에서도 비교적 좋은 처리량을 유지할 수 있습니다. 그러나 회사 네트워크·학교 네트워크·일부 모바일 네트워크에서는 UDP가 제한될 수 있으며, 이 경우 연결 실패·핸드셰이크 시간 초과·속도 불안정이 나타납니다. 이럴 때는 먼저 같은 지역의 TCP 계열 노드로 전환해 비교하세요. 곧바로 모든 DNS와 규칙을 수정할 필요는 없습니다.

프로토콜 호환성은 코어에도 좌우됩니다. Clash Nyanpasu는 Mihomo 코어와 함께 사용할 수 있지만 구독의 각 필드를 현재 코어 버전이 인식해야 합니다. 코어를 업데이트한 뒤에도 특정 유형의 노드가 모두 실패한다면 로그에서 “unsupported”, “authentication failed”, “TLS handshake”, “timeout” 등의 메시지를 확인하세요. 프로토콜 미지원, 인증 오류, 회선 시간 초과는 서로 다른 문제이며 해결 방법도 다릅니다.

TUN 모드가 노드를 자동으로 빠르게 만들어 주는 것은 아닙니다

TUN 모드는 가상 네트워크 인터페이스로 더 많은 애플리케이션 트래픽을 인계받으며, 시스템 프록시 설정을 따르지 않는 터미널 프로그램·게임 런처·일부 데스크톱 애플리케이션에 적합합니다. 바뀌는 것은 트래픽이 Clash로 들어오는 방식이지 프록시 서버의 대역폭이 아닙니다. TUN을 켠 뒤 측정 속도가 떨어진다면 중복 프록시, 부적절한 MTU, DNS 우회 또는 보안 소프트웨어 차단 여부를 확인하세요.

데스크톱의 일반적인 레이아웃에서는 「설정」→「Clash 설정」→「TUN 모드」에서 상태를 확인할 수 있습니다. 노드 전환은 「프록시」→정책 그룹→노드 이름에서 진행합니다. 버전에 따라 표시 문구가 조금 다를 수 있습니다. 비교 테스트에서는 모드를 동일하게 유지하세요. 노드 A는 시스템 프록시로 테스트하고 노드 B는 TUN으로 테스트하면 결과에 인계 방식의 차이까지 포함됩니다.

반복 실행할 수 있는 노드 선택 절차

노드가 많아도 전부 하나씩 측정할 필요는 없습니다. 용도·지역·배율로 후보를 줄인 뒤 짧은 테스트로 뚜렷한 이상 노드를 걸러내고, 마지막으로 실제 애플리케이션에서 검증하세요. 아래 절차를 따르면 보통 10분 안에 수십 개 노드 중 일상용 주 노드와 예비 노드를 고를 수 있습니다.

1. 용도 확인: 웹 브라우징, 동영상, 다운로드, 원격 연결 또는 특정 지역 서비스 중 무엇인지 적어 두세요.
2. 지역 제한: 원하는 출구를 제공하는 지역에서 5~10개 노드를 남기세요.
3. 배율 확인: 요금제 잔여량을 기준으로 장기간 사용하기 어려운 고배율 노드를 제외하세요.
4. 지연 시간 연속 측정: 후보마다 5회씩 테스트하고 중앙값·최고값·시간 초과를 기록하세요.
5. 단시간 처리량 테스트: 남은 2~3개 노드에서 같은 파일을 사용해 30~60초 동안 테스트하세요.
6. 실제 애플리케이션 검증: 대상 웹 페이지를 열거나 동영상을 재생하거나 원격 연결을 실제로 설정하세요.
7. 예비 노드 확보: 주 노드와 예비 노드는 서로 다른 서버나 회선에서 선택하는 것이 좋습니다.

자동 정책 그룹 설정 방법

구독에서 로컬 설정 덮어쓰기를 허용한다면 url-test를 사용해 후보 노드 그룹에서 지연 시간이 낮은 노드를 주기적으로 선택할 수 있습니다. 아래 예시는 300초마다 테스트하며 허용 오차는 50ms입니다. 노드 간 차이가 작을 때 허용 오차를 두면 잦은 전환을 줄일 수 있습니다. 노드 이름은 설정에 실제로 존재하는 이름으로 바꿔야 합니다.

proxy-groups:
  - name: 일상 자동 선택
    type: url-test
    proxies:
      - 일본-01
      - 일본-02
      - 싱가포르-01
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

url-test는 주로 테스트 URL의 응답 시간을 기준으로 노드를 자동 선택하며 배율·지역별 콘텐츠 이용 가능 여부·대용량 파일 처리량은 고려하지 않습니다. 후보 목록은 미리 선별해야 하며 모든 지역과 모든 배율을 한데 섞어서는 안 됩니다. 이용 가능성을 우선해야 한다면 fallback을 고려할 수 있지만, 실제 서비스 검증을 대신할 수는 없습니다.

흔한 오해와 문제 판단

지연 시간이 시간 초과로 표시되지만 웹 페이지는 열리는 경우

테스트 URL이 일시적으로 접속되지 않거나 대상 네트워크에서 제한되었을 수 있고, 클라이언트의 테스트 제한 시간이 너무 짧을 수도 있습니다. 노드 자체는 다른 웹사이트를 계속 프록시할 수 있습니다. 먼저 테스트 주소를 안정적인 가벼운 페이지로 바꾼 뒤 실제 연결과 로그로 판단하세요. 모든 노드에서 동시에 시간 초과가 발생한다면 노드를 하나씩 삭제하기보다 로컬 네트워크·구독 상태·코어 프로세스·방화벽을 먼저 확인해야 합니다.

노드를 선택했지만 출구가 바뀌지 않는 경우

가장 흔한 원인은 잘못된 정책 그룹을 전환한 것입니다. 「연결」에서 대상 요청에 적용된 규칙·정책 그룹·노드 경로를 확인하세요. 규칙이 요청을 “스트리밍”으로 보내는데 “노드 선택”만 수정했다면 출구가 바뀌지 않는 것이 정상입니다. 브라우저에서 별도의 프록시 확장 프로그램을 사용 중인지, 터미널에 HTTP_PROXY·HTTPS_PROXY·ALL_PROXY 환경 변수가 설정되어 있는지도 점검하세요.

자동 선택이 몇 개 노드 사이에서 계속 오가는 경우

노드 간 지연 시간 차이가 10~30ms에 불과하면 네트워크의 작은 변동만으로 순위가 바뀔 수 있습니다. 테스트 간격을 300~600초로 설정하고 약 50ms의 허용 오차를 두어 뚜렷한 이득이 없는 전환을 줄이세요. 원격 터미널·회의·장시간 연결 작업에서는 최저 지연 시간을 계속 좇기보다 안정적인 노드를 수동으로 고정하는 편이 더 적합합니다.

같은 지역으로 표시된 노드의 성능 차이가 큰 경우

일본이나 싱가포르에 함께 위치한다고 해서 같은 통신사·진입점·국제 회선·서버 부하를 사용하는 것은 아닙니다. 노드 번호도 품질 등급을 의미하지 않습니다. 안정적으로 작동하는 노드는 별도 정책 그룹에 기록하고, 다른 회선 하나를 예비로 남겨 두세요. 저녁 피크 시간대에 한 번 더 측정하면 낮에 한 번만 테스트하는 것보다 장기적인 사용 경험을 정확히 파악할 수 있습니다.

마지막에는 네 가지 기록으로 결정하세요

노드 선택은 간단한 기록표로 정리할 수 있습니다. 지연 시간에는 중앙값과 최고값을, 배율에는 실제 차감 규칙을, 지역에는 실제 출구와 대상 서비스 결과를, 프로토콜에는 현재 네트워크에서의 연결 안정성을 적으세요. 예를 들어 “일본-02: 지연 시간 중앙값 86ms, 최고 112ms, 1x, 일본 출구, Trojan, 60초 연속 다운로드 안정”이라고 기록하면 “일본 노드가 빠름”보다 이후 비교가 훨씬 쉽습니다.

일상용 주 노드가 모든 지표에서 1위일 필요는 없습니다. 안정적이고 배율이 감당할 만하며 용도에 맞는 출구를 제공하고 실제 애플리케이션에서 계속 사용할 수 있다면 더 실용적인 선택입니다. 네트워크 상태는 통신사 라우팅·서버 부하·시간대에 따라 바뀌므로, 매일 노드를 반복해서 바꾸기보다 눈에 띄는 끊김이 생겼을 때 짧은 테스트를 다시 실행하세요.