Clash 첫 연결: 노드 선택부터 지연 시간 측정, 프록시 작동 확인까지

연결 전에 설정이 정상적으로 작동하는지 확인하기

구독 가져오기에 성공했다는 것은 클라이언트가 설정 파일을 가져왔다는 뜻일 뿐, 프록시 연결이 수립되었다는 의미는 아닙니다. 처음 사용할 때는 설정, 코어, 정책 모드와 시스템 트래픽 적용 방식이 서로 일치하는지 먼저 확인해야 합니다. 클라이언트마다 메뉴 이름은 조금씩 다르지만, 일반적으로 「설정」 → 「구독」에서 방금 가져온 설정을 선택한 다음 「설정」 → 「매개변수 설정」에서 코어가 실행 중인지 확인합니다.

mihomo 코어를 사용하는 클라이언트는 보통 실행 상태, 코어 버전과 컨트롤 포트를 표시합니다. 메인 화면에 계속 “실행되지 않음”이 표시되거나 로그에 새 기록이 전혀 없다면 먼저 코어를 실행해야 하며, 곧바로 노드 테스트를 반복해서는 안 됩니다. 노드 지연 시간 버튼은 코어 기능을 호출하므로 코어가 실행 중이 아니면 모든 노드가 동시에 시간 초과로 표시될 수 있습니다.

첫 연결 전 확인할 네 가지

설정 선택 확인: 설정 목록에서 현재 설정으로 지정된 파일만 규칙 매칭에 사용됩니다. 구독을 방금 업데이트했다면 클라이언트가 이전 로컬 설정을 계속 사용하고 있지 않은지도 확인해야 합니다.
실행 모드 확인: 처음에는 「규칙」 모드를 권장합니다. 이 모드는 설정에 정의된 규칙에 따라 직접 연결 또는 프록시를 결정하므로 연결 화면에서 실제 매칭 과정을 확인하기 쉽습니다.
프록시 적용 활성화: 데스크톱 브라우저는 보통 「시스템 프록시」를 켜야 합니다. 시스템 프록시를 읽지 않는 앱까지 트래픽을 적용하려면 TUN 모드를 사용하세요.
포트 충돌 확인: 일반적인 설정에서는 HTTP 또는 mixed-port가 7890이고 SOCKS 포트는 7891인 경우가 많습니다. 최종 값은 현재 설정과 클라이언트의 설정 화면을 기준으로 확인하세요.

시스템 프록시와 TUN을 동시에 켜면 테스트 결과에 두 가지 적용 경로가 섞일 수 있습니다. 처음 문제를 확인할 때는 한 가지 방식만 사용하세요. 먼저 시스템 프록시로 브라우저를 확인한 뒤 필요할 때 TUN을 테스트하는 것이 좋습니다. 이렇게 해야 TUN 라우팅이 정상인 것을 시스템 프록시가 정상이라고 잘못 판단하거나, 브라우저 자체의 프록시 설정 문제를 노드 장애로 오해하는 일을 줄일 수 있습니다.

1단계: 정책 그룹에서 올바른 노드 선택하기

Clash 설정은 보통 특정 노드를 규칙에서 직접 참조하지 않고 먼저 정책 그룹을 참조합니다. 정책 그룹이 사용할 노드 또는 다음 단계의 정책 그룹을 결정하는 방식입니다. 흔히 「노드 선택」, 「프록시」, 「수동 선택」, 「자동 선택」, 「장애 조치」 같은 이름을 사용하지만, 이름은 구독 제공자가 정하므로 모든 설정이 동일하지는 않습니다.

규칙이 최종적으로 참조하는 정책 그룹 찾기

「프록시」 페이지를 열면 여러 그룹이 표시됩니다. select로 표시된 그룹은 수동 선택이 필요하고, url-test는 테스트 결과에 따라 자동으로 선택하며, fallback은 사용 가능한 노드를 우선 사용합니다. load-balance는 정책에 따라 여러 노드에 연결을 분산합니다. 첫 연결은 결과를 통제하기 쉬운 수동 선택 그룹에서 시작하는 것이 가장 좋습니다.

특정 지역 그룹에서만 노드를 선택해서는 안 됩니다. 상위 그룹이 해당 지역 그룹을 실제로 참조하는지도 확인해야 합니다. 예를 들어 「노드 선택」이 현재 「자동 선택」을 가리키고 있는데 사용자가 「홍콩 노드」에서 특정 회선만 바꿨다면 최종 출구는 여전히 「자동 선택」이 결정할 수 있습니다. 정책 그룹은 중첩될 수 있으므로 화면의 선택 표시를 최상위 그룹부터 아래까지 차례로 확인하세요.

정책 그룹 유형	첫 연결에서의 활용법	주의할 점
`select`	노드 하나를 수동 지정해 반복적으로 확인하기 좋음	그룹 안에서 선택해도 상위 그룹이 해당 그룹을 선택한 것은 아님
`url-test`	여러 노드를 테스트하고 지연 시간이 낮은 노드를 자동 선택	지연 시간이 짧다고 대역폭이 높거나 대상 웹사이트에 접속할 수 있다는 뜻은 아님
`fallback`	주 노드를 사용할 수 없을 때 순서대로 전환	상태 점검 결과에 따라 현재 표시 노드가 바뀔 수 있음
`load-balance`	여러 연결을 여러 노드에 분산	단일 출구 IP만으로 판단하는 방식에는 적합하지 않음

처음에는 어떤 노드를 선택해야 할까

먼저 지리적으로 가깝고 지연 시간 결과가 안정적인 노드를 선택하세요. 목록에서 가장 작은 숫자만 고집할 필요는 없습니다.
연속으로 세 번 테스트하세요. 결과가 68ms, 71ms, 74ms라면 42ms, 190ms, 시간 초과처럼 크게 흔들리는 경우보다 안정성이 높은 편입니다.
이름에 배수, 실험용 또는 속도 제한이 명시된 회선은 잠시 피하고, 먼저 반복 측정 가능한 기본 결과를 확보하세요.
같은 지역에 여러 프로토콜 노드가 있다면 구독에서 기본 추천하는 일반 회선을 먼저 선택한 뒤 실제 처리량과 안정성을 비교하세요.

노드 이름은 설정 제공자가 입력한 라벨일 뿐, 물리적 위치나 회선 품질을 단독으로 증명하지는 못합니다. 최종 판단은 지연 시간, 연결 로그, 출구 주소와 실제 접속 결과를 함께 확인해야 합니다. 고정 세션이 필요한 로그인 서비스에서는 짧은 시간에 노드를 자주 바꾸면 출구 주소도 바뀔 수 있으므로, 전환할 때마다 연결을 새로 수립한 뒤 다시 확인하세요.

2단계: 지연 시간을 테스트하고 결과 올바르게 읽기

클라이언트의 지연 시간 테스트는 전통적인 ICMP Ping과 다릅니다. Clash 또는 mihomo는 보통 지정된 노드로 테스트 URL을 요청하고, 프록시 연결을 수립해 응답을 받기까지 걸린 시간을 기록합니다. 테스트 주소는 https://www.gstatic.com/generate_204 또는 https://cp.cloudflare.com/generate_204처럼 HTTP 204를 반환하는 경우가 많습니다. 구체적인 주소는 설정 또는 클라이언트 설정에 따라 달라집니다.

지연 시간 수치가 의미하는 것

테스트 결과	일반적인 해석	다음에 할 일
40–100 ms	거리가 가깝거나 경로가 짧아 상호작용 응답이 대체로 빠름	실제 출구와 웹페이지 접속을 계속 확인
100–250 ms	지역 간 회선에서 흔히 나타남	세 번의 결과가 안정적인지 관찰
250–500 ms	경로가 길거나 혼잡하거나 핸드셰이크 시간이 김	같은 지역의 다른 노드와 비교
시간 초과	테스트 URL이 제한 시간 안에 응답하지 않음	노드, DNS, 네트워크와 테스트 주소 확인

이 구간은 1차 선별에만 사용하세요. 55ms 노드도 대역폭 혼잡으로 다운로드가 느릴 수 있고, 180ms 노드도 지속 전송에서는 안정적일 수 있습니다. 지연 시간은 주로 짧은 연결의 응답을 반영하며 다운로드 속도, 패킷 손실률 또는 피크 시간대 용량과 직접 같지 않습니다.

여러 노드를 테스트할 때는 빠르게 연속으로 클릭하지 마세요. 한 번에 수십 개의 노드를 테스트하면 대량의 연결이 순간적으로 생성되어 라우터, DNS 서비스 또는 원격 서버가 속도를 제한할 수 있습니다. 이번 결과가 모두 표시될 때까지 기다린 뒤 10~20초 간격으로 두 번째 라운드를 진행하는 것이 좋습니다. 한 번의 최저값보다 세 차례의 데이터가 더 참고할 만합니다.

모든 노드가 동시에 시간 초과라면 테스트 경로부터 확인하기

「로그」를 열고 속도 테스트를 클릭한 뒤 연결 시도가 기록되는지 확인하세요. 로그가 전혀 없다면 보통 코어가 실행되지 않았거나 인터페이스가 컨트롤 포트에 연결되지 않은 경우입니다.
이 컴퓨터에서 테스트 주소를 직접 확인할 수 있는지 점검하세요. DNS 오류가 발생하면 정상적인 노드도 한꺼번에 시간 초과로 표시될 수 있습니다.
테스트 URL을 다른 안정적인 204 주소로 바꾼 뒤 다시 테스트하세요. 특정 테스트 사이트에 접속할 수 없다고 해서 모든 노드가 동시에 고장 난 것은 아닙니다.
로컬 시간이 정확한지 확인하세요. 시스템 시간 오차가 크면 TLS 연결의 핸드셰이크가 실패할 수 있습니다.
로그에서 timeout, connection refused, network is unreachable 등의 정보를 확인하고, 각각 시간 초과, 포트 거부와 라우팅 불가 문제를 구분해 처리하세요.

3단계: 트래픽이 실제로 프록시를 통과하는지 확인하기

프록시 확인은 시스템 프록시 스위치의 색상 변화만 보거나 노드 옆에 지연 시간이 표시되는지만 확인해서는 안 됩니다. 출구 주소, Clash 연결 기록과 규칙 매칭 결과를 함께 살펴보는 것이 신뢰할 수 있는 방법입니다. 세 항목이 서로 일치해야 요청이 예상한 노드를 통과했다고 확인할 수 있습니다.

방법 1: 직접 연결과 프록시의 출구 주소 비교

시스템 프록시와 TUN을 끄고 공인 IP를 표시하는 서비스에 접속해 직접 연결의 출구 주소를 기록합니다.
시스템 프록시를 다시 켜고 방금 테스트한 노드를 고정 선택합니다.
새 시크릿 창에서 공인 IP를 다시 조회해 페이지 캐시의 영향을 줄입니다.
두 주소를 비교하고 Clash의 「연결」 페이지에서 해당 도메인 요청을 찾습니다.

로드 밸런싱 정책 그룹을 사용하면 연결마다 출구가 달라질 수 있으므로 매번 조회 결과가 완전히 같을 필요는 없습니다. 수동으로 단일 노드를 선택했다면 출구 주소는 대체로 비교적 안정적이어야 합니다. 공인 IP가 바뀌지 않았다고 바로 실패로 판단하지 마세요. 현재 규칙이 조회 서비스를 DIRECT로 설정했을 수 있으므로 먼저 연결 기록의 아웃바운드 정책을 확인해야 합니다.

방법 2: 터미널에서 프록시 포트를 명시적으로 지정

터미널 프로그램은 일반적으로 데스크톱의 시스템 프록시를 자동으로 읽지 않습니다. curl에 로컬 프록시를 명시하면 “터미널이 시스템 설정을 상속하는지”와 “Clash 포트가 작동하는지”를 나누어 테스트할 수 있습니다. 다음 명령은 HTTP 또는 mixed-port가 7890이라고 가정합니다.

curl --proxy http://127.0.0.1:7890 https://api.ipify.org

Windows PowerShell에서는 curl이 다른 명령으로 해석될 수 있는 구버전 환경을 피하기 위해 curl.exe를 사용하는 것이 좋습니다.

curl.exe --proxy http://127.0.0.1:7890 https://api.ipify.org

설정에서 SOCKS5 포트 7891을 별도로 열었다면 도메인 이름 조회도 프록시를 통해 수행할 수 있습니다.

curl --proxy socks5h://127.0.0.1:7891 https://api.ipify.org

socks5h의 h는 호스트 이름 해석을 SOCKS 프록시에 맡긴다는 뜻입니다. 명령 실행 결과 연결이 거부되면 먼저 실제로 수신 대기 중인 포트를 확인하고, 곧바로 노드를 바꾸지는 마세요. 최신 설정 중에는 mixed-port만 활성화되어 별도의 socks-port가 없을 수도 있습니다.

방법 3: 연결 세부 정보와 규칙 체인 확인

클라이언트의 「연결」 페이지를 열고 대상 웹페이지를 새로고침하세요. 요청 세부 정보에는 보통 대상 호스트, 소스 주소, 업로드·다운로드 트래픽, 매칭된 규칙과 최종 정책 체인이 표시됩니다. 예를 들어 다음과 같이 표시될 수 있습니다.

example.com
규칙: DomainSuffix
정책 체인: 노드 선택 → 홍콩 노드 → HK-01
네트워크: TCP
상태: Active

DIRECT가 표시되면 해당 요청이 규칙에 따라 직접 연결된다는 뜻입니다. 특정 노드 이름이 표시되면 프록시를 통해 아웃바운드 연결된 것이고, REJECT가 표시되면 규칙이 요청을 차단한 것입니다. 연결 목록에 대상 요청이 없다면 트래픽이 Clash에 들어오지 않았을 수 있으므로 브라우저 프록시, 앱 내부 프록시, TUN 라우팅 또는 로컬 방화벽을 우선 점검해야 합니다.

“속도는 측정되지만 프록시는 사용하지 않는” 가짜 연결 구분하기

가짜 연결은 노드 지연 시간이 정상이고 클라이언트도 실행 중으로 표시되지만 대상 앱은 여전히 직접 연결을 사용하는 경우가 가장 흔합니다. 원인은 대개 노드 자체가 아니라 정책 그룹 선택, 규칙 매칭 또는 앱 적용 범위에 있습니다. 구독을 반복해서 업데이트하는 것보다 다음 순서대로 확인하는 편이 효과적입니다.

최상위 정책 그룹이 방금 테스트한 노드를 선택하지 않음

「홍콩 노드」 그룹에서 HK-01을 선택했지만 실제 규칙은 「노드 선택」을 참조하고 있고 「노드 선택」은 여전히 「자동 선택」을 가리킬 수 있습니다. 이 경우 HK-01은 정상적으로 속도 테스트를 통과해도 실제 트래픽을 처리하지 않습니다. 최상위 그룹으로 돌아가 현재 선택 항목을 따라가며 최종 노드 이름이 예상과 일치하는지 단계별로 확인하세요.

대상 도메인이 규칙에서 직접 연결로 지정됨

규칙 모드는 정해진 순서대로 매칭합니다. DOMAIN-SUFFIX, GEOSITE, GEOIP와 최종 규칙인 MATCH가 출구를 바꿀 수 있습니다. 연결 기록에 DIRECT가 표시된다면 시스템 프록시는 정상 작동하지만 규칙이 직접 연결을 선택했을 가능성이 있습니다. 잠시 전역 모드로 전환해 비교한 뒤, 확인이 끝나면 규칙 모드로 돌아와 규칙 순서를 점검하세요.

브라우저 또는 앱이 시스템 프록시를 우회함

일부 브라우저는 확장 프로그램이나 기업 정책으로 프록시를 별도로 설정할 수 있으며, 개발 도구, 게임 런처, 컨테이너와 터미널 프로그램도 직접 연결을 만들 수 있습니다. 시스템 프록시는 운영체제의 프록시 설정을 능동적으로 읽는 프로그램에만 영향을 줍니다. 이런 앱에는 로컬 HTTP/SOCKS 주소를 직접 설정하거나 시스템 호환성을 확인한 뒤 TUN 모드를 사용하세요.

TUN은 켜졌지만 라우팅 또는 권한이 준비되지 않음

TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 트래픽을 처리합니다. Windows, macOS와 Linux에서는 관리자 권한이나 시스템 확장 설치가 필요할 수 있습니다. 켠 뒤에는 TUN 상태, 가상 인터페이스와 로그를 확인하세요. 스위치가 켜져 있다는 사실만으로 라우팅이 성공적으로 등록되었다고 볼 수는 없습니다. 로그에 인터페이스 생성 실패 또는 권한 부족이 표시되면 먼저 권한을 해결한 뒤 노드를 테스트하세요.

노드 전환 후 기존 연결이 재생성되지 않음

노드를 바꿔도 기존 TCP, QUIC 또는 장기 연결이 모두 즉시 새 노드로 이동하지는 않습니다. 브라우저 탭, 동영상 클라이언트와 메신저가 기존 연결을 계속 사용할 수 있습니다. 전환한 뒤 해당 연결을 닫고 페이지를 다시 불러오며, 필요하면 앱을 종료했다가 다시 실행하세요. 웹페이지를 테스트할 때 새 시크릿 창을 사용하면 캐시, Service Worker와 지속 연결의 영향을 줄일 수 있습니다.

IPv4와 IPv6가 서로 다른 경로를 사용함

대상 도메인이 A와 AAAA 레코드를 동시에 반환할 수 있습니다. 앱이 IPv6을 선택했는데 현재 프록시 또는 TUN 라우팅이 IPv4만 처리하면 일부 요청은 직접 연결되고 일부는 프록시를 통과하는 혼합 결과가 나타납니다. 연결 페이지와 로그에서 요청에 사용된 주소 체계를 확인할 수 있습니다. 공인 IP 페이지 하나만으로 전체 트래픽 경로를 판단하지 마세요.

반복 가능한 첫 연결 점검 절차 만들기

연결에 한 번 성공한 뒤에는 문제 확인 절차를 고정할 수 있습니다. 이후 구독을 업데이트하거나 네트워크를 바꾸거나 클라이언트를 전환할 때도 같은 순서로 확인하면 설정 문제, 노드 문제와 앱 적용 문제를 빠르게 구분할 수 있습니다.

현재 구독 설정을 선택하고 mihomo 또는 다른 호환 코어가 실행 중인지 확인합니다.
규칙 모드를 유지하고 TUN을 동시에 켜지 않은 상태에서 시스템 프록시만 먼저 활성화합니다.
최상위 수동 정책 그룹에서 특정 노드 하나를 선택합니다.
10~20초 간격으로 세 번 테스트하고 지연 시간과 시간 초과 발생 여부를 기록합니다.
대상 페이지에 접속하면서 「연결」과 「로그」에 해당 요청이 표시되는지 확인합니다.
매칭된 규칙, 정책 체인과 최종 노드 이름을 대조합니다.
직접 연결과 프록시의 출구 주소를 비교한 뒤 터미널에서 127.0.0.1:7890을 명시해 별도로 확인합니다.
기본 경로가 정상임을 확인한 뒤 자동 선택, 장애 조치 또는 TUN을 활성화합니다.

노드 선택, 지연 시간 측정과 프록시 확인은 서로 독립적인 세 단계입니다. 노드 선택은 “누구를 사용할지”를 결정하고, 지연 시간 테스트는 “탐색 요청이 통과하는지”를 확인하며, 출구와 연결 기록은 “실제 트래픽이 어디로 갔는지”를 보여줍니다. 세 단계를 나누어 판단해야 지연 시간 숫자 하나를 전체 연결 결과로 오해하지 않을 수 있습니다.