Clash 첫 연결 실전 가이드: 노드 선택·지연 시간 측정·프록시 적용 확인 3단계

시작 전 확인: 구성이 로드되었고 포트가 충돌하지 않는지 확인

첫 연결에서는 문제를 세 단계로 나누어 확인하는 것이 좋습니다. 구성이 정상적으로 로드되었는지, 노드가 연결을 설정할 수 있는지, 애플리케이션 트래픽이 실제로 Clash로 들어가는지 순서대로 점검하세요. 클라이언트 메인 화면에 표시되는 “실행 중” 상태만으로는 충분하지 않습니다. 이는 보통 코어 프로세스가 실행 중이라는 뜻일 뿐, 구독 노드가 사용 가능하거나 브라우저가 로컬 프록시 포트를 사용한다는 의미는 아닙니다.

클라이언트를 연 뒤 먼저 「구성」 또는 「Profiles」 페이지로 이동해 방금 가져온 구독이 선택되어 있는지 확인하세요. 구성 옆에는 업데이트 시간, 파일 이름 또는 구독 이름이 표시되어야 합니다. 파싱 실패, 빈 구성 파일이 표시되거나 구성을 전환하자마자 코어가 종료된다면 노드 테스트보다 먼저 가져오기 문제를 해결해야 합니다.

로컬 수신 포트 확인

일반적인 구성에서는 HTTP 포트 7890, SOCKS5 포트 7891을 사용합니다. 최신 구성 중에는 mixed-port: 7890으로 같은 포트에서 HTTP와 SOCKS5 트래픽을 모두 받기도 합니다. 정확한 값은 구성 파일과 클라이언트 설정에 따라 달라지므로 특정 포트로 억지로 바꿀 필요는 없습니다. 다만 시스템 프록시에 입력한 포트는 Clash가 실제로 수신 중인 포트와 일치해야 합니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

그래픽 클라이언트에서 포트 설정은 보통 「설정」→「일반 설정」→「포트」 또는 「General」→「Port」에 있습니다. 7890을 다른 프록시 프로그램이 이미 사용 중이면 bind failed, address already in use 또는 시작 실패 메시지가 표시될 수 있습니다. 이때 해당 포트를 사용하는 프로그램을 종료하거나 Clash 포트를 7892로 변경한 뒤 시스템 프록시를 다시 활성화하세요.

1단계: 정책 그룹에서 적절한 노드 선택

구독을 가져온 뒤 노드는 보통 홈 화면에 바로 나타나지 않고 「프록시」 또는 「Proxies」 페이지의 정책 그룹 안에 표시됩니다. 흔히 사용하는 그룹 이름은 “노드 선택”, “프록시”, “Proxy”, “수동 선택” 등입니다. 먼저 주요 트래픽 출구를 담당하는 선택형 정책 그룹을 찾고, 그룹 안에서 노드 하나를 선택하세요. DIRECT, REJECT 등이 함께 표시되는 전체 목록에서 무작정 클릭하지 않는 것이 좋습니다.

수동 선택 그룹부터 시작

「프록시」→「노드 선택」으로 이동해 현재 모드가 「규칙」 또는 Rule인지 확인하세요.
주요 프록시 정책 그룹을 펼친 다음, 지리적으로 가깝고 이름 정보가 명확한 노드를 선택하세요.
다른 정책 그룹이 “노드 선택”을 참조한다면 해당 그룹을 계속 가리키도록 두면 됩니다. 그룹마다 반복해서 지정할 필요는 없습니다.
홈 화면으로 돌아가 코어 상태가 실행 중인지 확인한 뒤 「시스템 프록시」를 활성화하세요.

첫 테스트에서는 노드 하나를 수동으로 고정하는 것이 좋습니다. 그래야 이후 지연 시간 측정, IP 조회, 연결 로그가 어떤 출구에 해당하는지 명확해집니다. 처음부터 url-test, 자동 선택 또는 부하 분산 그룹을 사용하면 테스트 중 클라이언트가 노드를 바꿔 결과가 앞뒤로 달라질 수 있습니다.

노드 이름은 필터링 단서일 뿐

노드 이름에 포함된 지역, 배율, 전용 회선 등의 정보는 구독 제공자가 정한 텍스트이며 실시간 품질을 보장하지 않습니다. 실제 사용감은 내 기기와 서버 사이의 네트워크 경로, 서버 부하, 프로토콜 매개변수, 대상 웹사이트의 회선에 주로 영향을 받습니다. 가까운 노드는 왕복 시간이 짧은 경우가 많지만 다운로드 속도가 가장 빠르다고 보장되지는 않습니다. 낮은 배율이 연결 안정성을 의미하는 것도 아닙니다.

선택 기준	첫 연결 시 권장 사항	이것만으로는 알 수 없는 것
노드 지역	네트워크 거리가 가까운 지역부터 테스트	실시간 대역폭과 서버 부하는 알 수 없음
지연 시간 수치	시간 초과 및 고지연 노드 제외에 활용	다운로드 속도와 같지는 않음
노드 배율	구독 트래픽 규칙과 함께 고려	회선 품질을 의미하지 않음
자동 정책 그룹	단일 노드 검증을 마친 뒤 활성화	작동하지 않는 노드나 잘못된 구성을 고쳐 주지는 않음

정책 그룹에 DIRECT만 있거나 노드 목록이 완전히 비어 있다면 보통 “노드가 선택되지 않은” 문제가 아닙니다. 구독 내용이 현재 코어가 지원하는 구성으로 정상 변환되지 않았을 가능성이 큽니다. 「구성」 페이지로 돌아가 구독을 업데이트하고 오류 로그를 확인하세요. 또한 사용 중인 클라이언트의 mihomo 코어 버전이 구성에 포함된 프록시 프로토콜과 필드를 인식할 수 있는지도 확인해야 합니다.

2단계: 지연 시간을 측정하고 노드 사용 가능 여부 확인

노드를 선택한 뒤 정책 그룹 오른쪽의 지연 시간 테스트 버튼을 클릭하세요. 클라이언트에 따라 속도 측정 아이콘, 번개 아이콘 또는 “Test”로 표시될 수 있습니다. 테스트 주소는 보통 용량이 매우 작은 HTTP 또는 HTTPS 페이지입니다. 클라이언트는 연결을 설정하고 응답을 받을 때까지 걸린 시간을 기록하며 결과는 밀리초로 표시됩니다.

지연 시간 결과 해석 방법

50–150ms: 회선이 가깝고 상태가 정상인 노드에서 흔히 나타나며, 웹 페이지 조작이 대체로 원활합니다.
150–300ms: 일반적인 웹 탐색과 다운로드에는 사용할 수 있지만 실시간 상호작용에서 대기감이 커질 수 있습니다.
300–800ms: 우회 경로, 혼잡 또는 높은 노드 부하가 있을 수 있으므로 같은 지역의 다른 노드와 비교해 보세요.
Timeout: 테스트 시간 안에 유효한 응답을 받지 못했다는 뜻입니다. 테스트 주소에 접근할 수 없는 경우, 노드가 작동하지 않는 경우, 로컬 네트워크가 차단한 경우를 구분해야 합니다.

이 구간은 문제 해결을 위한 참고값이지 고정된 합격 기준이 아닙니다. 한 번은 82ms, 다음에는 210ms가 표시된다면 회선에 변동이 있다는 뜻입니다. 세 번 연속 측정한 결과가 86ms, 91ms, 89ms라면 한 번의 최저값만 보는 것보다 의미가 큽니다. 첫 선별에서는 연속으로 성공하고 변동이 작은 노드 두세 개를 남겨 두세요.

지연 시간이 정상이어도 모든 웹사이트가 열리는 것은 아닙니다

지연 시간 테스트는 “내 기기 → 노드 → 테스트 주소”라는 하나의 요청 경로만 확인합니다. 모든 대상 웹사이트나 대용량 파일 처리량을 테스트하는 것은 아닙니다. 어떤 노드의 지연 시간이 95ms여도 특정 웹사이트는 규칙에 따른 DIRECT 처리, 대상 사이트의 제한, 비정상적인 DNS 결과 또는 노드 출구 네트워크 차이로 접속되지 않을 수 있습니다.

반대로 Timeout이 노드가 완전히 작동하지 않는다는 뜻도 아닙니다. 테스트 URL이 대상 네트워크에서 제한되었거나 클라이언트의 시간 제한이 너무 짧을 수 있습니다. 「설정」→「지연 시간 테스트」에서 테스트 주소와 시간 제한 값을 확인하세요. 흔히 사용하는 시간 제한은 5000ms입니다. 테스트 주소를 바꾼 뒤 모든 노드에 결과가 다시 표시된다면 문제는 전체 구독이 아니라 기존 테스트 주소에 있을 가능성이 큽니다.

모든 노드에서 동시에 시간 초과가 발생하면 먼저 로컬 환경 확인

수십 개 노드가 같은 시각에 모두 Timeout이라면 노드를 하나씩 바꾸는 효과가 크지 않습니다. 먼저 다른 네트워크로 전환해 보세요. 예를 들어 가정용 Wi-Fi에서 휴대폰 핫스팟으로 바꾼 뒤 다시 테스트합니다. 핫스팟에서 정상화되면 라우터, 현재 인터넷 회선 또는 로컬 네트워크 필터링이 원인일 수 있습니다. 두 네트워크 모두 실패한다면 구독 업데이트 시간, 시스템 시간, 코어 로그, 노드 프로토콜 매개변수를 확인하세요.

컴퓨터의 시간 오차로 TLS 핸드셰이크가 실패할 수도 있습니다. Windows에서는 「설정」→「시간 및 언어」→「날짜 및 시간」으로 이동해 자동 시간 설정을 켜고 즉시 동기화하세요. macOS에서는 「시스템 설정」→「일반」→「날짜 및 시간」으로 이동해 자동 설정이 활성화되어 있는지 확인합니다. 동기화한 뒤에는 프록시 페이지를 새로 고치는 데 그치지 말고 코어를 다시 시작하세요.

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

노드에 지연 시간 결과가 표시된 뒤에는 트래픽 검증도 완료해야 합니다. 가장 확실한 판단 기준은 세 가지입니다. 시스템 프록시 또는 TUN이 활성화되어 있고, 출구 IP가 직접 연결 상태와 다르며, Clash 연결 패널에 방금 생성한 요청이 보여야 합니다. 세 조건이 모두 충족되어야 “노드를 사용할 수 있다”는 사실과 “애플리케이션이 프록시를 사용한다”는 사실을 연결할 수 있습니다.

직접 연결 출구 IP 먼저 기록

Clash의 「시스템 프록시」와 「TUN 모드」를 잠시 끄세요.
브라우저에서 신뢰할 수 있는 IP 조회 페이지를 열고 현재 공인 IP와 지역을 기록하세요.
해당 페이지를 닫고 Clash를 다시 활성화한 뒤 앞에서 선택한 노드를 그대로 유지하세요.
조회 페이지를 다시 열어 공인 IP, 네트워크 사업자, 지역을 비교하세요.

프록시 사용 후 출구 IP가 직접 연결 IP와 다르고 지역도 노드 출구와 대체로 일치한다면 브라우저 요청이 프록시를 거쳤을 가능성이 높습니다. 그러나 IP 조회는 해당 접속 하나의 출구만 확인할 뿐 모든 애플리케이션과 프로토콜이 프록시에 연결되었다는 뜻은 아닙니다. 일부 브라우저는 페이지를 캐시할 수 있으므로 테스트 전에 시크릿 창을 사용하거나 페이지를 강제로 새로 고치세요.

연결 패널에서 요청 경로 확인

클라이언트의 「연결」 또는 「Connections」 페이지를 연 다음, 브라우저에서 이전에 열어 보지 않은 웹사이트에 접속하세요. 연결 목록에 새로운 도메인, 대상 주소, 규칙 이름, 정책 그룹, 실제 노드가 표시되어야 합니다. 흔히 다음과 같은 기록이 나타납니다.

Host: example.com
Network: TCP
Rule: DomainSuffix
Chain: 노드 선택 → HK-01
Upload: 3.2 KB
Download: 18.7 KB

Chain 또는 Chains는 정책 그룹이 최종적으로 어떤 노드로 연결되었는지를 나타냅니다. 경로에 “노드 선택 → HK-01”이 표시되면 요청이 해당 노드를 거친다는 뜻입니다. DIRECT라면 규칙에 따라 직접 연결된 것입니다. 규칙 모드에서 DIRECT가 표시되는 것은 정상일 수 있습니다. 로컬 네트워크 주소, 국내 웹사이트 또는 구성에서 지정한 도메인은 원래 직접 연결하도록 설정되어 있을 수 있습니다.

연결 패널에 새 요청이 전혀 나타나지 않는다면 대개 애플리케이션이 Clash를 사용하지 않는 것입니다. 「설정」→「시스템 프록시」가 켜져 있는지 확인하고, 시스템 프록시 주소가 127.0.0.1인지, 포트가 Clash의 HTTP 또는 mixed 포트와 일치하는지 점검하세요. 브라우저에 프록시 확장 프로그램이 설치되어 있다면 시스템 설정을 덮어쓰거나 다른 포트를 가리키고 있지 않은지도 확인하세요.

시스템 프록시와 TUN 모드의 적용 범위

시스템 프록시는 운영체제의 프록시 설정을 따르는 애플리케이션에 주로 적용됩니다. 일반적인 브라우저와 일부 데스크톱 프로그램이 이에 해당합니다. 일부 게임, 명령줄 프로그램, 스토어 앱, UDP 트래픽은 시스템 프록시를 자동으로 읽지 않습니다. 이러한 트래픽까지 연결하려면 클라이언트의 「설정」→「네트워크」→「TUN 모드」에서 TUN을 활성화하세요.

TUN은 가상 네트워크 인터페이스를 만들어 더 많은 IP 계층 트래픽을 mihomo가 처리하도록 전달합니다. 처음 활성화할 때 관리자 권한이 필요할 수 있으며, Windows에서는 관련 네트워크 구성 요소를 설치하거나 활성화해야 할 수도 있습니다. 활성화한 뒤 「연결」 패널을 다시 확인해 대상 프로세스에서 발생한 연결이 표시되는지 확인하세요. 시스템 프록시를 다른 프로그램으로 잘못 지정하면 HTTP 요청과 TUN 트래픽이 서로 다른 결과를 보일 수 있으므로 주의해야 합니다.

흔한 오해 세 가지: 연결된 것처럼 보여도 문제가 남아 있는 경우

오해 1: 홈 화면의 스위치만 확인하기

홈 화면에 “실행 중”이라고 표시되는 것은 코어가 성공적으로 시작되었다는 뜻일 뿐입니다. 완전한 정상 상태라면 구성 로드 성공, 노드 지연 시간 테스트 결과, 시스템 프록시 또는 TUN 활성화, 연결 패널의 요청 기록이 모두 필요합니다. 하나라도 빠지면 클라이언트는 실행 중인데 웹 페이지가 직접 연결되거나 접속되지 않을 수 있습니다.

오해 2: 지연 시간이 가장 짧으면 속도도 가장 빠르다고 생각하기

지연 시간 테스트는 전송 데이터가 적어 주로 응답 시간을 반영합니다. 다운로드 속도는 서버 대역폭, 회선 혼잡, 노드 부하, 단일 연결 제한, 대상 사이트 성능에도 영향을 받습니다. 두 노드의 지연 시간이 각각 70ms와 110ms라면 후자가 더 안정적인 다운로드 처리량을 제공할 수도 있습니다. 일상적인 사용에서는 웹 응답, 연결 지속 안정성, 실제 전송 속도를 함께 관찰하세요.

오해 3: 출구 IP가 바뀌지 않으면 노드가 작동하지 않는다고 판단하기

규칙 모드에서는 IP 조회 사이트가 DIRECT로 설정되어 있어 로컬 출구가 계속 표시될 수 있습니다. 먼저 「연결」 페이지에서 해당 도메인에 어떤 규칙이 적용되었는지 확인하세요. 기록에 DIRECT가 표시되면 잠시 전역 모드로 전환해 다시 테스트할 수 있습니다. 전역 모드에서 출구가 바뀐다면 노드 자체는 사용할 수 있으므로 규칙을 조정하거나 올바른 프록시 정책 그룹을 선택해야 합니다.

브라우저에서 보안 DNS, 별도 프록시 확장 프로그램 또는 기업 정책을 사용하는 경우도 있습니다. 이러한 설정은 도메인 해석이나 프록시 경로를 바꿀 수 있습니다. 문제를 확인할 때는 먼저 추가 확장 프로그램을 끄고 시스템 프록시 하나만 남긴 뒤 연결 패널을 관찰하세요. DNS 조회 결과와 웹 페이지의 TCP 연결은 서로 다른 단계이므로 DNS 서버의 위치만으로 전체 트래픽이 프록시를 사용하는지 판단해서는 안 됩니다.

첫 연결에 실패했을 때의 고정 문제 해결 순서

웹 페이지가 열리지 않거나 속도 테스트가 모두 시간 초과되고 출구 IP도 바뀌지 않는다면 설정을 무작정 바꾸기보다 정해진 순서대로 확인하는 편이 빠릅니다. 한 번에 변수 하나만 변경하고, 변경 후에는 요청을 다시 보내세요.

구성: 구독이 선택된 상태인지, 업데이트 중 파싱 오류가 없었는지, 노드 목록이 비어 있지 않은지 확인하세요.
코어: 상태가 실행 중인지, 로그에 포트 사용 중·필드 오류·권한 오류가 없는지 확인하세요.
노드: 노드 하나를 고정해 세 번 테스트한 뒤 같은 지역의 다른 노드와 비교하세요.
포트: mixed, HTTP, SOCKS5 포트가 시스템 프록시 설정과 일치하는지 확인하세요.
애플리케이션 진입점: 브라우저는 먼저 시스템 프록시로 테스트하고, 시스템 프록시를 읽지 않는 애플리케이션에는 TUN을 고려하세요.
규칙: 연결 패널에서 DIRECT, REJECT, 프록시 정책 그룹 중 어디에 매칭되었는지 확인하세요.
네트워크: 휴대폰 핫스팟으로 전환해 다시 테스트하여 클라이언트 설정 문제와 현재 로컬 네트워크 문제를 구분하세요.
로그: timeout, connection refused, TLS handshake 등 구체적인 메시지를 기준으로 문제가 발생한 단계를 찾으세요.

예를 들어 노드 지연 시간은 정상이고 IP 조회에는 직접 연결로 표시되지만 연결 패널에 기록이 없다면, 우선 시스템 프록시가 적용되지 않은 경우를 의심해야 합니다. 연결 패널에 기록이 있고 선택한 노드로 경로가 연결되어 있지만 요청에 timeout이 표시된다면 노드와 대상 네트워크를 계속 확인하세요. 기록에 REJECT가 명확히 표시된다면 포트를 바꿀 것이 아니라 규칙을 점검해야 합니다.

점검을 마친 뒤 권장하는 일상 설정

연결이 성공한 것을 확인했다면 모드를 Rule로 유지해 구성이 도메인, IP, 규칙 집합에 따라 DIRECT 또는 프록시를 결정하도록 하세요. 주요 정책 그룹은 안정적인 노드에 계속 고정해도 되고 url-test 자동 선택 그룹으로 전환해도 됩니다. 자동 그룹을 사용하기 전에는 그룹 안의 모든 노드가 독립적으로 연결되는지 확인해야 합니다. 자동 테스트는 사용 가능한 노드 중에서 선택할 뿐, 작동하지 않는 구성을 고쳐 주지는 않습니다.

시스템 프록시 사용자는 로컬 수신 주소를 127.0.0.1로 유지하고, LAN 공유가 필요하지 않다면 Allow LAN을 끄세요.
게임, 명령줄 프로그램 또는 시스템 프록시를 읽지 않는 소프트웨어를 사용할 때만 TUN을 활성화하고, 연결 패널에서 해당 트래픽이 인식되는지 확인하세요.
구독 업데이트 후 노드 이름이 바뀌었다면 수동 정책 그룹이 여전히 유효한 노드를 가리키는지 다시 확인하세요.
웹 페이지에 문제가 생기면 먼저 연결 기록과 규칙 매칭을 확인하고, 구성 전체를 바로 삭제하지 마세요.
지연 시간 테스트를 세 번 진행하고 실제 접속까지 확인한 예비 노드 하나를 남겨 두면 빠르게 비교할 수 있습니다.

첫 연결의 핵심은 모든 스위치를 켜는 것이 아니라 명확한 검증 경로를 만드는 데 있습니다. 먼저 특정 노드 하나를 선택하고, 지연 시간 테스트로 기본 연결을 확인한 뒤, 출구 IP와 연결 패널로 요청 경로를 검증하세요. 이 세 단계를 마치면 이후 속도 저하, 특정 웹사이트 접속 실패, 특정 애플리케이션의 프록시 미적용 문제가 노드·규칙·트래픽 진입점 중 어디에서 발생했는지 명확히 파악할 수 있습니다.