프록시 노드 선택 가이드: 지연 시간·트래픽 배율·지역·프로토콜

먼저 용도를 정하고 노드 수치를 살펴보세요

Clash 노드 목록에 표시되는 지연 시간은 테스트 결과일 뿐, 종합 점수가 아닙니다. 노드가 현재 작업에 적합한지는 대상 사이트, 지속 전송 속도, 변동 폭, 출구 지역, 과금 배율에 따라 달라집니다. 먼저 대상 서비스에 접속할 수 없는 노드를 제외하고, 안정성과 비용을 비교한 뒤, 마지막으로 지연 시간을 기준으로 비슷한 후보를 가려내세요.

후보 노드는 세 개 정도 남겨두는 것이 좋습니다. 일상적으로 사용할 노드, 다른 회선의 예비 노드, 꼭 필요한 특정 지역의 출구 노드입니다. 노드 이름에 붙은 ‘전용 회선’, ‘네이티브’, ‘고속’ 등의 문구는 서비스 제공자가 붙인 이름일 뿐입니다. 실제 테스트를 대신할 수 없으며, 이름만으로 회선 구성을 판단할 수도 없습니다.

• 웹 브라우징 및 원격 작업: 첫 응답 시간, 연속 요청 중 멈춤 여부, 저녁 피크 시간대의 변동 폭을 확인하세요.
• 동영상 및 대용량 파일: 지속 다운로드 속도, 버퍼링 여부, 트래픽 배율을 확인하세요. 한 번의 낮은 지연 시간만으로 전송 성능을 판단할 수 없습니다.
• 지역 제한 서비스: 속도보다 먼저 서비스가 출구 IP를 어떻게 인식하는지 확인하세요. 노드 이름에 표시된 지역과 서비스가 판정하는 지역은 다를 수 있습니다.
• 게임 및 실시간 음성 통화: 앱 트래픽이 실제로 프록시를 통과하는지, 노드가 필요한 UDP 포워딩을 지원하는지 먼저 확인하세요. 일반 웹 지연 시간은 게임 내 지표를 대신할 수 없습니다.

지연 시간 테스트: 측정 대상, 반복 결과, 실제 요청을 확인하세요

Clash에 표시되는 밀리초 수치는 무엇을 측정하나요?

일반적인 노드 지연 시간 테스트는 지정된 프록시를 통해 테스트 URL에 접속하고, 코어가 기록한 요청 소요 시간을 측정합니다. 노드 서버에 단순히 ICMP ping을 보내는 방식은 아닙니다. 테스트 주소, 연결 재사용 방식, 코어 구현에 따라 결과가 달라질 수 있으므로 클라이언트나 테스트 주소가 다른 수치를 그대로 비교하는 것은 적절하지 않습니다.

한 번의 테스트에서 80ms, 다른 테스트에서 130ms가 나왔다면, 해당 테스트에서는 전자가 더 빨랐다는 뜻일 뿐입니다. 실제 웹사이트 접속에는 다른 출구 경로가 사용될 수 있고, 도메인 조회와 TLS 핸드셰이크, 서버 처리 시간도 필요합니다. 테스트 URL에 접속할 수 있어도 모든 대상 사이트에 접속할 수 있다는 의미는 아닙니다.

같은 조건에서 반복 측정하고, 가장 낮은 값만 고르지 마세요

1. 같은 기기, 같은 네트워크, 같은 테스트 주소를 사용하세요. 대용량 다운로드는 일시 중지해 로컬 대역폭이 가득 차지 않도록 합니다.
2. 후보 노드마다 약 10초 간격으로 5회 측정하고 중앙값, 최댓값, 시간 초과 횟수를 기록하세요.
3. 평소 사용하는 시간대와 저녁 피크 시간대에 각각 다시 측정하세요. 예를 들어 10:00와 21:00에 테스트할 수 있습니다. 시간은 기록 조건일 뿐 성능을 보장하지 않습니다.
4. 실제로 사용할 웹사이트를 열고 연속으로 새로고침하거나 같은 작업을 수행해 페이지 리소스까지 정상적으로 로드되는지 확인하세요.

예를 들어 노드 A의 5회 측정값이 65, 70, 68, 900ms, 시간 초과이고, 노드 B는 115, 120, 118, 125, 122ms라고 해보겠습니다. B의 중앙값은 더 높지만 이 표본은 더 안정적입니다. 위 수치는 결과 해석을 위한 예시이며, 이 사이트에서 실제 회선을 측정한 값이 아닙니다. 표본이 적으면 장기 가동률도 추정할 수 없습니다.

트래픽 배율: 과금 규칙에 따라 계산하고 속도와 혼동하지 마세요

배율은 보통 서비스 제공자가 요금제 트래픽을 차감하는 방식을 나타내며, Clash 코어의 가속 설정이 아닙니다. 업로드와 다운로드를 합산해 과금하는 경우를 예로 들면, 실제 전송량이 총 5GB일 때 배율 2인 노드는 약 10GB, 배율 0.5인 노드는 약 2.5GB가 차감됩니다. 실제 과금은 서비스 제공자의 명세를 기준으로 확인하세요. 클라이언트의 연결 통계만으로 과금 오류를 단정할 수는 없습니다.

배율이 높다고 지연 시간이 낮은 것은 아니며, 배율이 낮다고 반드시 느린 것도 아닙니다. 하루 실제 전송량이 4GB라면 30일 동안 120GB입니다. 위 규칙에 따라 배율 2인 노드만 사용하면 약 240GB가 차감됩니다. 선택하기 전에 월간 사용량을 추산해 요금제로 감당할 수 있는지 확인하세요. 월 중순에 데이터가 부족해지는 상황을 피할 수 있습니다.

속도 테스트에도 트래픽이 사용됩니다. 평균 80Mbps로 30초 동안 다운로드하면 다른 트래픽을 제외하고도 약 300MB가 전송됩니다. 수십 개 노드를 하나씩 최대 속도로 테스트할 필요는 없습니다. 먼저 가벼운 지연 시간 테스트로 후보를 좁힌 뒤, 두세 개 노드에서 짧게 전송 속도를 확인하세요.

지역 선택: 접속 지점, 출구, 사이트의 지역 판정을 구분하세요

기기가 연결하는 서버 주소는 접속 지점의 일부로 볼 수 있으며, 대상 웹사이트에는 보통 출구 IP가 표시됩니다. 중계 회선에서는 접속 지점과 출구가 서로 다른 지역일 수 있습니다. 노드 이름에 ‘일본’이라고 표시되어 있어도 기기와 일본 서버 사이에 직접 연결 경로만 있다는 뜻은 아닙니다. 연결 주소만으로 최종 출구를 추정할 수도 없습니다.

거리가 가깝다고 경로가 짧은 것은 아닙니다

지리적 거리는 전파 지연에 영향을 주지만, 통신사 간 연결, 우회 경로, 혼잡도도 성능을 바꿉니다. 같은 노드라도 가정용 인터넷, 회사 네트워크, 모바일 핫스팟에서 결과가 다를 수 있습니다. 네트워크를 바꾼 뒤에는 주로 사용할 노드를 다시 확인하고, 다른 회선에서 얻은 테스트 결과를 그대로 적용하지 마세요.

지역 제한 서비스는 해당 서비스에서 직접 확인하세요

• 후보 노드에 연결한 뒤 대상 서비스의 요청이 규칙에 의해 직접 연결되지 않고 실제로 해당 노드를 통과하는지 확인하세요.
• 대상 서비스가 표시하는 지역 안내나 이용 가능한 콘텐츠를 확인하세요. IP 조회 사이트의 데이터베이스와 대상 서비스의 판정 결과는 다를 수 있습니다.
• 계정 등록 지역, 결제 정보, 기기 위치 정보, 이전 세션도 판정에 반영될 수 있습니다. 출구를 바꾼다고 결과가 반드시 달라지는 것은 아닙니다.
• 장기간 로그인해 사용하는 서비스는 출구를 가능한 한 안정적으로 유지하세요. 지역을 자주 바꾸면 서비스에서 추가 인증을 요구할 수 있습니다.

일반적인 웹 브라우징만 한다면 우선 경로 성능이 좋은 인접 지역부터 테스트하세요. 특정 출구 지역이 꼭 필요한 업무라면 해당 용도로 노드를 따로 유지하면 됩니다. 지역이 다양하다고 이용 가능성이 높아지는 것은 아닙니다.

프로토콜 선택: 코어 지원 여부를 확인한 뒤 현재 네트워크를 살펴보세요

Clash는 클라이언트 생태계에서 널리 쓰이는 이름이며, 클라이언트마다 사용하는 코어가 다를 수 있습니다. Clash Meta(현재는 보통 mihomo라고 부름)가 지원하는 프로토콜은 구버전 Clash와 완전히 같지 않습니다. 구독을 가져올 수 있다는 사실은 설정이 어느 단계까지 수락되었다는 뜻일 뿐입니다. 실제 노드 유형, 필드, 전송 옵션은 현재 코어에서 지원하는지 확인해야 합니다.

현재 네트워크에서 UDP를 제한하면 UDP 기반 전송은 연결되지 않을 수 있지만, 같은 구독의 TCP 기반 후보 노드는 정상 작동할 수 있습니다. 반대로 지연 시간이 높거나 패킷 손실이 있는 일부 환경에서는 적절히 설정된 QUIC 기반 전송이 더 나은 성능을 보일 수도 있습니다. 같은 네트워크에서 테스트한 결과를 기준으로 판단하고, 프로토콜 이름만으로 순위를 매기지 마세요.

‘속도 향상’을 위해 인증서 검증을 무작정 끄지 마세요. 인증서 오류가 발생하면 기기 시간, 서버 이름, 구독 설정을 확인하고 필요한 경우 서비스 제공자에게 문의하세요. 프로토콜 연결 성공과 올바른 인증서 검증은 별개의 문제이며, 검증을 우회하는 것은 일반적인 문제 해결 방법이 아닙니다.

Clash에서 확인하기: 실제로 어떤 노드로 트래픽이 전달되는지 점검하세요

노드를 선택한 뒤에도 느리다면 대상 요청이 선택한 정책 그룹을 거치지 않는 경우가 흔합니다. 규칙 모드에서는 규칙 순서에 따라 일치 항목을 찾고 해당 정책으로 처리합니다. 일부 도메인은 DIRECT로 설정되어 있거나 다른 자동 선택 그룹으로 전달될 수 있습니다. 클라이언트의 ‘연결’ 또는 로그 화면에서 대상 도메인, 일치한 규칙, 실제 프록시 경로를 확인하세요. 메뉴 이름과 위치는 클라이언트마다 다를 수 있습니다.

먼저 노드를 고정하고 자동 정책과 비교하세요

mihomo의 select 그룹은 후보 노드를 수동으로 고정할 때 적합합니다. url-test는 테스트 URL 결과를 바탕으로 노드를 선택하고, fallback은 후보 순서에 따라 사용 가능한 노드를 선택합니다. 자동 테스트는 테스트 주소의 성능을 측정할 뿐, 동영상 화질이나 계정 지역, 트래픽 배율까지 자동으로 고려하지는 않습니다.

아래는 기존 mihomo 설정에 추가할 수 있는 정책 그룹 조각입니다. 구독에 이미 있는 proxy-provider를 참조하므로 단독으로 가져올 수 있는 완전한 설정 파일은 아닙니다. 테스트 그룹은 300초마다 상태를 확인합니다. 같은 노드로 반복 비교할 수 있도록 수동 선택 그룹도 남겨두세요.

proxy-groups:
  - name: 일상 수동 선택
    type: select
    use:
      - provider-main

  - name: 지연 시간 후보
    type: url-test
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 300

provider-main은 설정에 실제로 존재하는 제공자 이름으로 바꿔야 합니다. 테스트 URL은 연결 상태 확인용이며 실제 업무 대상의 성능을 나타내지는 않습니다. 설정을 수정하기 전에 사본을 저장해 구독 업데이트로 로컬 변경 사항이 덮어써지지 않도록 하세요. 제공자와 규칙 작성법은 YAML 안내서에서 확인할 수 있습니다.

노드를 바꾼 뒤에는 새 연결로 다시 테스트하세요

1. 후보 노드를 하나씩 고정하고 대상 웹사이트를 열어 로딩이나 다운로드 성능을 기록하세요.
2. 다른 후보 노드로 바꾼 뒤 요청을 새로 시작하세요. 이미 열린 장시간 연결은 이전 프록시 경로를 계속 사용할 수 있습니다.
3. 필요한 경우 해당 앱의 기존 연결만 종료하세요. 다른 다운로드나 회의까지 중단하지 않도록 주의합니다.
4. 같은 파일을 비슷한 시간대에 비교하고, 최고 속도뿐 아니라 멈춤 현상도 기록하세요.

최종 정리: 주 사용 노드, 예비 노드, 용도를 기록하세요

비교가 끝나면 네트워크 환경, 테스트 시간, 노드 이름, 실제 출구 지역, 배율, 지연 시간 중앙값, 시간 초과 횟수, 실제 업무 성능을 한 줄로 기록하세요. 매번 측정한 모든 수치를 장기간 보관할 필요는 없지만, 선택한 이유는 남겨두세요. 구독이 갱신되거나 네트워크가 바뀌었을 때 다시 확인하기 쉽습니다.

• 주 사용 노드: 대상 업무에 사용할 수 있고, 자주 쓰는 시간대에 안정적이며, 배율이 일상적인 사용량에 적합한 노드입니다.
• 예비 노드: 가능한 한 접속 지점이나 회선이 다른 노드를 선택하세요. 이름만 다른 두 노드라면 장애를 분리하는 효과가 없을 수 있습니다.
• 특정 용도 노드: 해당 지역이나 프로토콜 기능이 꼭 필요할 때만 사용하고, 모든 트래픽을 맡길 필요는 없습니다.
• 재확인 시점: 인터넷 회선을 바꾸거나 클라이언트 코어를 업데이트하거나 구독 설정이 변경된 경우, 또는 시간 초과가 계속 발생하면 같은 조건으로 다시 테스트하세요.

실용적인 판단 순서는 업무에 사용할 수 있는지 → 연결이 안정적인지 → 배율을 감당할 수 있는지 → 지연 시간과 전송 속도가 적절한지입니다. 이 네 단계를 나눠 확인하면 ‘최저 지연 시간’을 반복해서 누르는 것보다 현재 네트워크에 맞는 노드를 찾기 쉽습니다.