Clash 첫 연결 시 노드 선택 방법: 지연 시간 측정·노드 전환·프록시 작동 확인

먼저 연결 경로를 완성한 뒤 노드를 비교하세요

Clash 또는 Mihomo 코어 기반 클라이언트를 처음 사용할 때는 노드 목록의 지연 시간 수치부터 확인하지 마세요. 완전한 연결에는 최소 네 단계가 필요합니다. 설정을 불러오고, 전략 그룹에서 노드를 선택하고, 시스템 트래픽을 클라이언트로 전달하며, 노드가 대상 웹사이트에 접속할 수 있어야 합니다. 어느 한 단계라도 완료되지 않으면 “노드에는 지연 시간이 표시되지만 웹페이지가 열리지 않는” 상황이 발생할 수 있습니다.

다음 순서로 진행하는 것이 좋습니다. 구독을 가져오고 설정을 업데이트한 다음 프록시 모드를 선택하고, 시스템 프록시 또는 TUN 모드를 켠 뒤 전략 그룹에서 노드를 선택하세요. 그래픽 클라이언트마다 명칭은 조금씩 다르지만, 일반적인 경로는 「구독」→「업데이트」이며 이후 「프록시」→대상 전략 그룹으로 이동합니다. 클라이언트만 실행하고 시스템 프록시를 활성화하지 않으면 브라우저는 대개 기존 네트워크를 통해 직접 연결합니다.

1. 「구독」 또는 「설정」 페이지에서 현재 Profile이 활성화되어 있는지 확인하고 수동 업데이트를 한 번 실행하세요.
2. 「프록시」 페이지로 이동해 실행 모드를 「규칙」으로 설정하세요. 첫 테스트에서는 「직접 연결」을 바로 사용하는 것을 권장하지 않습니다.
3. 「설정」→「시스템 프록시」를 열고 스위치가 활성화되어 있는지 확인하세요.
4. 「프록시」→주요 전략 그룹으로 돌아가 지연 시간 측정을 완료할 수 있는 노드를 선택하세요.
5. 프록시 사용 전후의 출구 IP를 조회해 주소가 바뀌었는지 확인한 뒤 실제 웹사이트를 테스트하세요.

수동 선택·자동 속도 측정·장애 조치의 차이

Clash 설정에서 실제 노드 선택은 전략 그룹에서 이루어집니다. 전략 그룹은 프록시 노드와 선택 로직을 묶은 것입니다. 가장 흔한 유형은 select, url-test, fallback, load-balance입니다. 구독 서비스에서는 이를 “노드 선택”, “자동 선택”, “장애 조치” 또는 “부하 분산”으로 표시할 수 있습니다.

첫 연결에서는 수동 전략 그룹을 우선 사용하세요

수동 선택은 변수가 적기 때문에 첫 테스트에 더 적합합니다. 먼저 select 유형의 전략 그룹에서 노드 하나를 고정하고 출구 IP, 웹페이지 접속, 명령줄 테스트를 완료하세요. 연결이 정상이면 자동 속도 측정 그룹으로 전환합니다. 이렇게 하면 자동 선택 결과가 좋지 않을 때 문제가 속도 측정 로직에 있는지, 시스템 프록시나 구독 가져오기에 있는지 명확히 구분할 수 있습니다.

노드 이름의 지역, 배율, 회선 태그는 분류 정보일 뿐 실제 측정을 대신할 수 없습니다. 예를 들어 “홍콩 01”이 반드시 “일본 02”보다 빠른 것은 아니며, “전용 회선”이라는 표시만으로 국내 네트워크에서 입구 서버까지의 품질을 알 수도 없습니다. 거리가 가까우면 왕복 시간이 줄어드는 데 유리하지만 통신사 간 연동, 피크 시간대의 혼잡, 노드 부하도 결과에 영향을 줍니다.

자동 속도 측정은 테스트 대상을 기준으로 합니다

url-test는 설정에 지정된 테스트 주소에 주기적으로 요청을 보내고 후보 노드의 응답 시간을 비교합니다. 일반적인 Mihomo 설정 예시는 다음과 같습니다.

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

interval: 300은 약 300초마다 다시 테스트한다는 뜻입니다. tolerance: 50은 후보 결과의 차이가 작을 때 현재 노드를 유지해 잦은 전환을 줄인다는 의미입니다. 테스트 주소의 응답이 빠르다는 것은 해당 노드가 그 테스트 대상에 현재 빠르게 접속한다는 뜻일 뿐, 동영상·코드 저장소·업무 서비스에서도 가장 빠르다는 보장은 없습니다.

지연 시간 수치는 어떻게 해석해야 할까요

클라이언트에 표시되는 지연 시간은 일반적인 ICMP Ping이 아닌 경우가 많습니다. 대부분의 Clash 그래픽 클라이언트는 프록시를 통해 HTTP 요청을 보내 연결을 수립하고 응답을 받는 데 걸린 시간을 기록합니다. 이 결과에는 로컬 네트워크, 프록시 입구, 노드 출구, DNS, TLS 핸드셰이크, 테스트 서버 상태가 함께 영향을 줍니다. 따라서 지연 시간은 선별 도구이지 대역폭 테스트가 아닙니다.

한 번 65ms가 나왔다고 노드가 안정적이라고 단정하지 마세요. 더 신뢰할 수 있는 방법은 10초 간격으로 세 번에서 다섯 번 테스트하는 것입니다. 예를 들어 같은 노드가 차례로 72, 75, 79, 74ms를 기록하면 변동이 작습니다. 다른 노드가 48, 210, 93ms, 시간 초과를 기록한다면 최저 수치는 더 좋아 보여도 실제 사용에서는 대개 더 불안정합니다. 동영상과 다운로드에서는 지속 처리량도 확인해야 하며, 원격 터미널과 웹 상호작용에서는 지연 시간과 지터를 더 중요하게 봐야 합니다.

속도 측정이 모두 시간 초과일 때 먼저 확인할 항목

• 컴퓨터 자체에서 일반 웹사이트에 직접 접속할 수 있는지 확인해 Wi-Fi 연결 끊김이나 게이트웨이 장애를 배제하세요.
• 「구독」→「업데이트」에서 설정을 다시 가져와 만료된 노드 정보를 사용하지 않도록 하세요.
• 시스템 시간과 시간대를 확인하세요. 시간 차이가 지나치게 크면 TLS 인증서 검증이 실패할 수 있습니다.
• TUN을 잠시 끄고 시스템 프록시만 활성화해 테스트하세요. 여러 트래픽 가로채기 방식이 서로 영향을 주는 것을 피할 수 있습니다.
• 로컬 혼합 포트가 다른 프로그램에 의해 사용되고 있지 않은지 확인하세요. 일반적으로 7890을 사용합니다.
• 클라이언트 로그에서 timeout, connection refused, network unreachable를 중점적으로 확인하세요.

노드를 전환했는데 왜 바로 바뀌지 않나요

전략 그룹에서 새 노드를 선택하면 새로 만들어지는 연결은 보통 새 선택을 사용하지만, 이미 연결된 세션은 기존 채널을 계속 재사용할 수 있습니다. 브라우저의 HTTP/2·HTTP/3 장기 연결, 다운로드 도구의 분할 작업, 메신저의 상시 연결 때문에 이전 출구가 잠시 유지될 수 있습니다. 따라서 전환 직후 같은 페이지를 새로 고쳐도 출구가 바뀐 것을 바로 확인하지 못할 수 있습니다.

다음 순서로 새 연결을 다시 수립하세요

1. 「프록시」→주요 전략 그룹으로 이동해 선택 표시가 새 노드로 옮겨졌는지 확인하세요.
2. 테스트 중인 웹페이지 탭을 닫고 5~10초 기다리세요.
3. 페이지 캐시와 기존 연결의 영향을 피하기 위해 새 시크릿 창을 여세요.
4. 출구 IP를 다시 조회해 전환 전 주소와 비교하세요.
5. 그래도 바뀌지 않으면 브라우저를 재시작하고, 필요하다면 클라이언트의 연결 페이지에서 기존 연결을 닫으세요.

규칙 모드에서 테스트 웹사이트가 예상한 전략 그룹에 할당되었는지도 확인해야 합니다. 규칙 모드는 도메인, IP, 프로세스 또는 규칙 집합을 위에서부터 순서대로 매칭합니다. 출구 IP 조회 도메인이 DIRECT에 매칭되면 주요 전략 그룹에서 프록시를 선택했더라도 페이지에는 로컬 공인 주소가 표시됩니다. 문제를 확인할 때는 클라이언트 로그나 연결 목록에서 해당 도메인을 찾아 적용된 규칙, 전략 그룹, 실제 노드를 대조하세요.

잠시 전역 모드로 전환해 비교 테스트를 할 수도 있습니다. 전역 모드에서는 트래픽이 대개 지정한 프록시 노드로 일괄 전달됩니다. 전역 모드에서 출구가 바뀌지만 규칙 모드에서는 바뀌지 않는다면 문제는 대부분 규칙 매칭이나 전략 그룹 참조에 있습니다. 테스트가 끝나면 규칙 모드로 되돌려 원래 직접 연결해야 하는 로컬 네트워크나 국내 서비스까지 프록시를 거치지 않도록 하세요.

출구 IP 페이지로 프록시 작동 여부 확인

가장 직관적인 방법은 먼저 시스템 프록시를 끄고 공인 IP 조회 서비스에 접속해 현재 출구 주소를 기록하는 것입니다. 그런 다음 시스템 프록시를 켜고 조회 페이지를 새로 고치세요. 두 결과가 다르고 프록시 사용 후 지역이 선택한 노드와 대략 일치하면 브라우저 트래픽이 프록시를 통과하고 있다는 뜻입니다. 페이지에 표시된 국가나 도시만 보지 말고 IP 주소 자체를 비교 기준으로 삼으세요.

1. Clash의 「시스템 프록시」를 끄고 IP 조회 페이지를 연 다음 IPv4 또는 IPv6 주소를 기록하세요.
2. 「시스템 프록시」를 다시 켜고 전략 그룹에서 노드 하나를 고정하세요.
3. 새 브라우저 시크릿 창을 열고 출구 IP를 다시 조회하세요.
4. 다른 지역의 노드로 전환한 뒤 조회 탭을 닫고 다시 열어 주소가 다시 바뀌는지 확인하세요.
5. 클라이언트의 「연결」 페이지로 돌아가 조회 도메인이 대상 전략 그룹을 통과했는지 확인하세요.

IPv4는 바뀌었지만 IPv6에는 여전히 로컬 통신사 주소가 표시된다면 클라이언트가 IPv6를 가로채고 있는지, 브라우저가 이용한 조회 서비스가 IPv6를 우선 반환하는지 확인해야 합니다. IPv6 처리는 운영체제, TUN 설정, 네트워크 환경에 따라 달라집니다. IPv4만 테스트해서 모든 IPv6 트래픽도 같은 경로를 지난다고 판단할 수는 없습니다.

명령줄에서 직접 연결과 프록시 연결을 각각 테스트

명령줄 테스트는 브라우저 확장 프로그램, 캐시, 장기 연결을 거치지 않으므로 로컬 프록시 포트가 작동하는지 더 쉽게 확인할 수 있습니다. 아래 예시는 Mihomo의 혼합 포트가 127.0.0.1:7890이라고 가정합니다. 혼합 포트는 HTTP와 SOCKS 연결을 모두 허용합니다. 클라이언트에서 다른 포트를 사용한다면 「설정」→「포트 설정」에 표시된 값을 기준으로 하세요.

Windows PowerShell

Windows 10 또는 Windows 11에서는 먼저 curl.exe가 실제 프로그램인지 확인하세요. PowerShell 구버전에서 curl을 다른 명령으로 해석하는 문제를 피할 수 있습니다. 직접 연결과 프록시 요청을 각각 실행합니다.

curl.exe --noproxy "*" https://api.ipify.org
curl.exe -x http://127.0.0.1:7890 https://api.ipify.org

macOS 및 Linux

curl --noproxy "*" https://api.ipify.org
curl -x http://127.0.0.1:7890 https://api.ipify.org

첫 번째 명령은 프록시를 강제로 건너뛰어 로컬 네트워크의 공인 출구를 반환합니다. 두 번째 명령은 요청을 Clash 혼합 포트로 명시적으로 보냅니다. 두 명령이 서로 다른 주소를 반환하고 두 번째 요청이 클라이언트 연결 기록에도 나타나면 HTTP 프록시 경로가 정상적으로 작동하는 것입니다. 두 번째 명령에서 127.0.0.1:7890에 연결할 수 없다고 나오면 클라이언트 실행 여부, 포트 입력값, 로컬 접근을 허용하는 리슨 주소를 확인하세요.

SOCKS5도 테스트하면서 도메인 조회를 프록시 측에서 수행하게 할 수 있습니다.

curl --socks5-hostname 127.0.0.1:7890 https://api.ipify.org

--socks5-hostname과 단순한 --socks5에는 중요한 차이가 있습니다. 전자는 도메인 조회를 SOCKS 프록시에 맡기므로 로컬 DNS 조회 결과가 테스트에 미치는 영향을 배제하는 데 적합합니다. HTTP 프록시는 작동하지만 SOCKS 요청이 실패한다면 현재 포트가 혼합 포트인지, HTTP 포트인지, 별도의 SOCKS 포트인지 확인하세요.

로컬 포트가 리슨 중인지 확인

Windows에서는 다음을 실행하세요.

netstat -ano | findstr :7890

macOS에서는 다음을 실행하세요.

lsof -nP -iTCP:7890 -sTCP:LISTEN

Linux에서는 다음을 실행하세요.

ss -lntp | grep 7890

127.0.0.1:7890 또는 0.0.0.0:7890이 리슨 상태라면 해당 포트의 연결을 받는 프로그램이 있다는 뜻이지만, 이것만으로 노드가 작동한다고 증명할 수는 없습니다. 프록시 요청 결과와 클라이언트 로그를 함께 확인해야 합니다. 리슨 중인 프로세스가 현재 Clash 클라이언트가 아니라면 포트 충돌일 수 있으므로 충돌하는 프로그램을 종료하거나 클라이언트 포트와 시스템 프록시 설정을 함께 변경하세요.

브라우저는 되지만 다른 앱이 연결되지 않을 때

브라우저에 접속된다고 해서 모든 프로그램이 시스템 프록시를 읽는 것은 아닙니다. 일부 게임, 명령줄 도구, 스토어 앱, 자체 네트워크 스택을 사용하는 프로그램은 HTTP 프록시 설정을 무시합니다. 먼저 앱 자체에 프록시 옵션이 있는지 확인하세요. 지원한다면 HTTP 프록시에 127.0.0.1:7890을 입력하거나 SOCKS5 프록시에도 같은 혼합 포트를 사용하면 됩니다.

앱에 프록시 설정이 없다면 TUN 모드를 고려할 수 있습니다. 일반적인 경로는 「설정」→「Mihomo」 또는 「코어 설정」→「TUN 모드」입니다. 처음 활성화할 때 관리자 권한이 필요하고 가상 네트워크 어댑터가 생성될 수 있습니다. 켠 뒤에는 출구 IP와 대상 앱을 다시 테스트하고, 로컬 네트워크 장치·프린터·회사 내부망이 여전히 규칙에 따라 직접 연결되는지도 확인하세요.

TUN 모드 확인 핵심 항목

• 클라이언트 로그에서 대상 앱이 생성한 새 연결을 확인할 수 있습니다.
• 연결 기록에 올바른 규칙과 전략 그룹이 표시되며, 의도치 않게 DIRECT에 매칭되지 않습니다.
• DNS 요청이 정상적으로 완료되고 연속적인 조회 시간 초과가 발생하지 않습니다.
• 시스템 프록시를 끈 뒤에도 대상 앱이 TUN 모드에서 규칙에 따라 연결됩니다.
• 클라이언트를 종료한 후 네트워크가 정상적으로 복구되고 기본 경로와 DNS에 이상이 남지 않습니다.

시스템 프록시, TUN, 전역 모드, 여러 노드를 동시에 반복해서 전환하지 마세요. 한 번에 하나의 변수만 바꾸고 결과를 기록하세요. 예를 들어 먼저 “일본 02”를 고정하고 시스템 프록시만 켭니다. 명령줄 프록시가 작동하는 것을 확인한 뒤 TUN을 활성화하고, 마지막으로 규칙 모드로 되돌립니다. 이 순서로 확인하면 문제가 노드, 포트, 규칙, 트래픽 가로채기 계층 중 어디에 있는지 빠르게 찾을 수 있습니다.

첫 연결 안정성 점검 목록

지연 시간이 낮은 노드를 선택한 뒤 연속 테스트를 한 번 더 진행하세요. 서로 다른 유형의 웹사이트 세 곳을 열어 5분간 유지하고, 약 50MB 크기의 공개 테스트 파일을 다운로드해 속도가 지속되는지 확인하세요. 페이지를 두 번 전환하면서 클라이언트 연결 기록도 살펴보세요. 잠깐 속도 측정에는 성공했지만 몇 분 뒤 시간 초과가 많이 발생한다면 노드 부하, 회선 지터 또는 로컬 네트워크 불안정이 원인일 가능성이 큽니다.

• Profile이 업데이트되었고 클라이언트에 표시된 설정 업데이트 시간이 예상과 일치합니다.
• 주요 전략 그룹에서 노드 하나가 명확히 선택되어 있으며 DIRECT를 잘못 선택하지 않았습니다.
• 지연 시간 테스트를 세 번 연속 실행해도 큰 폭으로 튀거나 자주 시간 초과되지 않습니다.
• 시스템 프록시 또는 TUN 중 하나 이상이 활성화되어 있고 테스트 대상에 맞게 설정되어 있습니다.
• 프록시 사용 전후의 출구 IP가 다르고 연결 로그에 대상 노드 이름이 표시됩니다.
• 규칙 모드에서 자주 사용하는 웹사이트가 예상한 전략 그룹에 매칭됩니다.
• 클라이언트를 종료한 뒤 시스템 네트워크가 정상적으로 복구됩니다.

최종 선택에서 목록의 최저 수치만 추구할 필요는 없습니다. 110ms 안팎으로 안정적이며 연속 사용에 문제가 없는 노드가 45ms에서 400ms 사이를 크게 오가는 노드보다 일상적인 작업에 더 적합한 경우가 많습니다. 먼저 사용 가능성과 안정성을 확보한 다음 동영상 속도, 웹페이지 응답 또는 특정 지역 요구에 맞춰 전략 그룹을 조정하세요.