Clash 첫 연결 가이드: 노드 선택, 지연 시간 측정, 프록시 적용 확인

연결 전에 구독이 로드되었는지 확인

Clash를 처음 사용할 때는 과정을 구성 사용 가능, 노드 사용 가능, 정책 그룹 선택, 시스템 트래픽 연결의 네 가지 상태로 나누어 확인하는 것이 좋습니다. 클라이언트에 ‘실행 중’이라고 표시되어도 커널 프로세스가 시작되었다는 뜻일 뿐, 브라우저가 이미 프록시를 통해 네트워크에 접속한다는 의미는 아닙니다.

구성 이름과 업데이트 시간 확인

아래 설명은 Clash Verge Rev 2.4.x와 mihomo 1.19.x의 일반적인 화면을 기준으로 합니다. 클라이언트마다 버튼 이름은 조금 다를 수 있지만, 구성·프록시·연결·설정 페이지의 역할은 대체로 같습니다.

「구독」 또는 「구성」 페이지를 열고 방금 가져온 구성이 목록에 표시되는지 확인합니다.
구성 카드를 클릭해 현재 활성 구성으로 지정합니다. 로컬에 다운로드만 하고 선택하지 않았다면 커널은 해당 구성의 노드와 규칙을 사용하지 않습니다.
업데이트 시간을 확인합니다. 몇 주 전으로 표시된다면 먼저 「구독 업데이트」를 한 번 실행합니다.
「프록시」 페이지로 이동해 정책 그룹과 노드 이름이 표시되는지 확인합니다. 목록이 비어 있으면 안 됩니다.

커널을 시작하고 오류 메시지 확인

「설정」→「Clash 설정」 또는 「설정」→「커널 설정」으로 돌아가 현재 커널이 mihomo인지 확인합니다. 시작에 성공하면 로그에 구성 로드, 수신 포트, 규칙 초기화 정보가 보통 나타납니다. 일반적인 로컬 수신 값은 HTTP 포트 7890, SOCKS5 포트 7891이며, mixed-port: 7890 하나로 통합해 사용하기도 합니다.

로그에 address already in use가 표시되면 해당 포트를 다른 프로그램이 사용 중이라는 뜻입니다. YAML 파싱 오류가 나타나면 구성 형식에 문제가 있는 것입니다. 이때는 노드 테스트를 계속하지 말고 먼저 커널이 안정적으로 실행되도록 조치하세요.

올바른 정책 그룹에서 노드 선택

Clash의 「프록시」 페이지에는 노드와 정책 그룹이 함께 표시되는 경우가 많습니다. 노드는 실제 회선이고, 정책 그룹은 특정 트래픽을 최종적으로 어느 회선에 전달할지 결정합니다. 첫 연결에서 가장 흔한 문제는 노드가 없는 것이 아니라 실제 분기에 참여하지 않는 그룹에서 노드를 선택하는 것입니다.

먼저 정책 그룹 유형 구분하기

일반적인 이름	대표 유형	첫 연결 시 처리 방법
노드 선택, PROXY, Proxy	`select`	구체적인 노드 하나를 직접 선택합니다. 첫 문제 해결에 적합합니다.
자동 선택, Auto	`url-test`	테스트 결과에 따라 더 빠른 노드를 자동으로 사용하지만, 처음 문제를 해결할 때는 수동 선택보다 직관적이지 않습니다.
폴백, Fallback	`fallback`	목록에서 사용 가능한 앞쪽 노드를 우선 사용하고, 실패하면 다음 노드로 전환합니다.
로드 밸런싱, Load Balance	`load-balance`	여러 회선에 연결을 분산하므로 개별 노드의 품질을 판단하는 용도로는 적합하지 않습니다.
DIRECT, 직접 연결	직접 연결 출구	트래픽이 프록시 노드를 거치지 않고 대상에 직접 접속합니다.

먼저 「노드 선택」, 「수동 선택」과 비슷한 이름의 그룹이나 PROXY 그룹을 열고, “일본 01” 또는 “싱가포르 02”처럼 지역이 명확히 표시된 노드를 하나 선택하세요. 그다음 페이지 상단이나 주 정책 그룹이 이 그룹을 참조하는지 확인합니다. 주 그룹이 여전히 DIRECT로 선택되어 있으면 노드 카드가 활성화되어도 출구가 바뀌지 않습니다.

첫 테스트는 규칙 모드로 진행

「설정」→「시스템 설정」 또는 클라이언트 홈에서 프록시 모드를 찾아 「규칙」을 선택합니다. 규칙 모드는 구성의 규칙을 위에서 아래로 대조합니다. 로컬 네트워크와 일반적인 중국 본토 주소는 보통 직접 연결하고, 프록시가 필요한 대상은 정책 그룹으로 보내며, 마지막에는 MATCH가 일치하지 않은 트래픽을 처리합니다.

규칙 모드: 일상적인 사용에 적합하며 구독의 트래픽 분기가 정상인지 확인할 수 있습니다.
전역 모드: 대부분의 트래픽을 전역 정책 그룹으로 전달하며, 규칙 문제를 잠시 배제할 때 적합합니다.
직접 연결 모드: 프록시를 우회합니다. 이 모드를 잘못 선택하면 IP 확인 결과에 계속 로컬 출구가 표시됩니다.

지연 시간 테스트에서는 지연·시간 초과·변동을 함께 확인

클라이언트의 지연 시간 테스트는 보통 ICMP Ping이 아닙니다. Clash는 지정된 노드를 통해 테스트 URL에 접속하고 연결 수립, TLS 협상 또는 응답 수신에 걸린 시간을 기록합니다. 프록시 사용 가능성에 더 가까운 결과지만 다운로드 속도와 같은 의미는 아닙니다.

비교 가능한 일괄 테스트 한 번 실행

「프록시」 페이지로 이동해 현재 사용하는 정책 그룹을 찾습니다.
그룹 오른쪽 위의 속도 테스트 버튼을 클릭하고 모든 노드가 완료될 때까지 기다립니다. 연속해서 반복 클릭하지 마세요.
지연 시간, 시간 초과 노드 수, 같은 노드에서 세 번 연속 측정한 결과의 변화를 기록합니다.
지연 시간이 적절하고 변동이 작은 노드 중 하나를 직접 선택한 뒤 웹페이지 테스트를 진행합니다.

테스트 결과	일반적인 의미	권장 조치
40–120 ms	대체로 응답이 빠름	웹페이지, 채팅, 가벼운 요청에 우선 사용할 수 있습니다.
120–250 ms	사용 가능하지만 상호작용 지연이 더 큼	두 번 더 측정해 안정적인지 확인합니다.
250–500 ms	경로가 멀거나 혼잡하거나 중계 구간이 많음	한 번의 결과만 보지 말고 같은 지역의 다른 노드와 비교합니다.
Timeout	테스트 시간 동안 유효한 응답을 받지 못함	구독을 업데이트한 뒤 다시 테스트하고, 계속 시간 초과가 나면 노드를 바꿉니다.
80, 310, 95ms처럼 연속으로 크게 변동	지터가 뚜렷함	실시간 통신이 불안정할 수 있으므로 변동이 작은 회선을 우선 선택합니다.

예를 들어 노드 A의 세 번 측정 결과가 86, 91, 89ms이고 노드 B가 52, 420, 77ms라고 하겠습니다. 노드 B의 최저값이 더 낮더라도 첫 연결 테스트에는 보통 노드 A가 더 적합합니다. 우연히 한 번 낮게 나온 지연 시간보다 안정성이 더 중요한 참고 기준입니다.

지연 시간은 정상인데 웹페이지가 느린 이유

지연 시간은 짧은 요청의 응답 시간만 반영합니다. 회선 대역폭, 피크 시간대 혼잡, 대상 사이트의 속도 제한, 패킷 손실률, 기기 성능도 실제 체감 속도에 영향을 줍니다. 65ms 노드가 처리량은 낮을 수 있고, 150ms 노드가 오히려 큰 파일을 안정적으로 전송할 수도 있습니다.

테스트 주소에 연결할 수 있는지도 확인해야 합니다. mihomo 구성에서는 https://www.gstatic.com/generate_204를 상태 확인 주소로 사용하는 경우가 많습니다. 현재 네트워크 환경에서 테스트 주소 자체가 차단되어 있으면 모든 노드가 시간 초과로 표시될 수 있지만, 이것이 모든 프록시 회선이 동시에 중단되었다는 뜻은 아닙니다.

시스템 프록시를 켜서 브라우저 트래픽을 Clash로 전달

노드를 선택한 뒤에는 애플리케이션 트래픽을 Clash의 로컬 수신 포트로 보내야 합니다. 일반적인 브라우저는 시스템 프록시로 연결할 수 있지만, 게임·명령줄 프로그램·스토어 앱·UDP를 사용하는 일부 소프트웨어는 시스템 프록시를 무시할 수 있습니다. 이런 경우 TUN 모드나 애플리케이션 자체의 프록시 설정이 필요합니다.

Windows와 macOS의 시스템 프록시 확인

클라이언트 홈에서 「시스템 프록시」를 켭니다. Windows 11에서는 「설정」→「네트워크 및 인터넷」→「프록시」에서 수동 프록시 상태를 확인할 수 있습니다. 일반적인 주소는 127.0.0.1, 포트는 7890입니다. 클라이언트가 다른 mixed-port를 사용한다면 시스템 설정의 포트도 동일해야 합니다.

macOS에서는 「시스템 설정」→「네트워크」→「Wi-Fi」→「세부사항」→「프록시」에서 웹 프록시와 보안 웹 프록시를 확인할 수 있습니다. 보통 클라이언트가 자동으로 설정하므로, 클라이언트 실행 중에 다른 프록시 도구로 이 항목을 동시에 수정하는 것은 권장하지 않습니다.

충돌할 수 있는 네트워크 도구부터 종료

7890, 7891 또는 동일한 컨트롤 포트를 사용하는 다른 프록시 클라이언트를 종료합니다.
브라우저에서 별도로 설정한 프록시 확장 프로그램을 일시 중지해 요청이 다른 주소 그룹으로 전달되지 않도록 합니다.
시스템 시간이 정확한지 확인합니다. 시간이 크게 어긋나면 HTTPS 인증서 검증이 실패할 수 있습니다.
첫 검증에서는 애플리케이션 내부의 사용자 지정 DNS 또는 프록시 체인 설정을 잠시 끄고 변수를 줄입니다.

출구 IP로 프록시 적용 여부 확인

웹페이지가 열린다고 해서 요청이 반드시 프록시를 거친다는 뜻은 아닙니다. 가장 직접적인 방법은 Clash를 켜기 전과 후에 공인 IP를 각각 조회해 주소, 통신사, 지역 정보를 비교하는 것입니다. 같은 브라우저와 같은 네트워크 환경에서 테스트하세요.

브라우저 확인 절차

클라이언트의 「시스템 프록시」를 잠시 끄고 IP 조회 페이지를 연 다음, 원래 공인 IP의 앞 두 구간과 지역을 기록합니다.
시스템 프록시를 다시 켜고 모드가 「규칙」 또는 「전역」인지 확인한 뒤, 방금 테스트를 통과한 노드를 선택합니다.
새 시크릿 창을 열고 서로 다른 IP 조회 페이지 두 곳을 방문합니다.
두 페이지 모두 프록시 노드가 있는 지역을 표시하고 IP가 원래 출구와 다르다면 브라우저 프록시가 적용된 것으로 볼 수 있습니다.
Clash의 「연결」 페이지로 돌아가 조회 페이지를 새로 고친 뒤 해당 도메인, 대상 주소, 정책 그룹, 노드 이름이 표시되는지 확인합니다.

예를 들어 프록시를 끄면 출구가 203.0.113.24이고 켠 뒤 198.51.100.76으로 바뀌며, 연결 기록에 해당 요청이 PROXY에 매칭되어 “싱가포르 02”로 전달된다고 표시된다면 브라우저 트래픽이 Clash로 들어간 것입니다. 여기의 주소는 판단 방법을 설명하기 위한 예시일 뿐입니다.

명령줄에서 직접 연결과 프록시 요청 비교

Windows 11, macOS 및 일반적인 Linux 배포판에서는 보통 curl을 사용할 수 있습니다. 로컬 혼합 포트가 7890이라면 다음 명령을 각각 실행합니다:

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

첫 번째 명령은 현재 시스템과 터미널 환경을 통해 접속하고, 두 번째 명령은 Clash의 HTTP 프록시를 명시적으로 지정합니다. 두 결과의 IP가 다르면 로컬 프록시 포트가 요청을 전달할 수 있다는 뜻입니다. 브라우저에 여전히 원래 IP가 표시된다면 노드를 계속 바꾸기보다 시스템 프록시나 브라우저 자체 설정을 확인하세요.

연결 기록도 함께 확인

클라이언트의 「연결」 페이지를 열면 정상적인 요청에 호스트 이름, 소스 주소, 업로드·다운로드량, 매칭 규칙, 정책 체인, 최종 노드가 표시됩니다. 연결 항목을 클릭하면 DIRECT, REJECT, 또는 특정 프록시 노드를 거쳤는지 확인할 수 있습니다.

IP 조회 요청이 DIRECT에 매칭되면 먼저 전역 모드로 전환해 비교하세요. 전역 모드에서 출구가 바뀐다면 노드와 시스템 프록시는 작동하며 문제는 규칙이나 정책 그룹에 있습니다. 전역 모드에서도 연결 기록이 없다면 트래픽이 현재 Clash 인스턴스로 들어오지 않는 것입니다.

시스템 프록시가 작동하지 않을 때 TUN 모드 활성화

TUN 모드는 mihomo가 가상 네트워크 인터페이스를 만들어 네트워크 계층에서 트래픽을 수신하도록 합니다. 시스템 프록시를 읽지 않는 프로그램에 적합하고 UDP를 사용하는 환경도 더 폭넓게 처리할 수 있습니다. 첫 연결부터 모든 기능을 동시에 켤 필요는 없습니다. 먼저 일반 시스템 프록시를 확인한 뒤 애플리케이션 필요에 따라 TUN을 켜면 문제를 더 명확하게 추적할 수 있습니다.

TUN 활성화 순서

「설정」→「Clash 설정」→「TUN 모드」로 이동합니다.
클라이언트 안내에 따라 서비스 모드를 설치하거나 활성화합니다. Windows에서는 처음 설치할 때 관리자 권한이 필요한 경우가 많습니다.
TUN을 켠 뒤 가상 인터페이스가 생성될 때까지 기다리고 IP 조회 페이지에 접속합니다.
「연결」과 「로그」를 확인해 대상 애플리케이션의 요청이 기록되는지 확인합니다.
네트워크에 문제가 생기면 먼저 TUN을 끄고 시스템 네트워크가 복구되는지 확인한 다음 DNS와 라우팅 설정을 점검합니다.

mihomo의 TUN은 DNS 하이재킹, 자동 라우팅, 엄격한 라우팅과 함께 사용하는 경우가 많습니다. 클라이언트마다 이러한 매개변수를 토글로 묶어 제공합니다. 처음 사용하는 경우 구성 출처를 이해하지 못한 상태에서 인터페이스 이름, MTU, 라우팅 테이블, DNS 수신 포트를 동시에 변경하지 않는 것이 좋습니다.

DNS 문제인지 판단하는 방법

특정 IP에는 접속되지만 도메인으로 웹사이트를 열 수 없거나 로그에 도메인 확인 실패가 계속 나타난다면 DNS 문제일 수 있습니다. Fake-IP 모드에서는 DNS 모듈이 먼저 매핑 주소를 반환하고, 커널이 원래 도메인을 기준으로 규칙을 매칭합니다. 198.18.0.0/16 범위의 매핑 주소가 보인다고 해서 대상 웹사이트가 실제로 해당 네트워크에 있다는 뜻은 아닙니다.

먼저 클라이언트에서 제공하는 DNS 정리 기능을 한 번 실행하거나 커널을 재시작한 뒤 다시 테스트합니다. Windows에서는 터미널에서 ipconfig /flushdns를 실행해 시스템 캐시를 지울 수도 있습니다. 특정 도메인만 실패한다면 모든 트래픽을 곧바로 전역으로 바꾸기보다 연결 로그에서 매칭된 규칙과 DNS 응답 결과를 확인하세요.

첫 연결 실패 시 빠른 점검표

증상	우선 확인할 항목	다음 단계
프록시 페이지에 노드가 없음	구독이 정상적으로 업데이트되었는지, 구성이 선택되었는지	구성을 다시 로드하고 파싱 로그를 확인합니다.
모든 노드가 시간 초과로 표시됨	테스트 URL, 시스템 시간, 현재 네트워크	네트워크를 바꾼 뒤 다시 테스트하고 구독 제공자에게 회선 상태를 확인합니다.
노드 지연 시간은 정상인데 브라우저에서 웹페이지가 열리지 않음	시스템 프록시 주소와 포트	`127.0.0.1:7890`인지 확인한 다음 연결 기록을 확인합니다.
웹페이지는 열리지만 출구 IP가 바뀌지 않음	직접 연결 모드, 규칙 매칭, 브라우저 프록시	일시적으로 전역 모드로 전환해 비교합니다.
브라우저는 되지만 게임이나 터미널은 작동하지 않음	애플리케이션이 시스템 프록시를 지원하는지	애플리케이션 프록시를 설정하거나 필요에 따라 TUN을 활성화합니다.
TUN을 켠 뒤 도메인을 확인할 수 없음	DNS 설정과 가상 인터페이스 상태	TUN을 꺼서 네트워크를 복구한 뒤 DNS 로그를 확인합니다.
시작 시 포트 사용 중 오류가 표시됨	`7890`, `7891`을 사용하는 프로세스	충돌하는 프로그램을 종료하거나 수신 포트와 시스템 프록시 포트를 일치시키도록 변경합니다.

연결 완료를 판단하는 최소 검증 기준

현재 구성이 선택되어 있고 업데이트 작업에서 형식 오류가 반환되지 않았습니다.
mihomo 커널이 안정적으로 실행되며 로컬 수신 포트가 생성되었습니다.
하나 이상의 노드가 세 번 연속 테스트에서 시간 초과 없이 응답했고 지연 변동이 허용 범위에 있습니다.
실제 트래픽 분기에 참여하는 정책 그룹이 해당 노드를 선택했으며 DIRECT가 아닙니다.
브라우저 요청이 「연결」 페이지에 나타나고 최종 사용 노드가 표시됩니다.
서로 독립적인 두 IP 조회 결과가 프록시를 끈 상태와 다릅니다.

이 여섯 가지를 충족하면 첫 연결이 완료된 것입니다. 이후 자동 속도 테스트, 정책 그룹 세분화, 규칙 조정, 구독 자동 업데이트, TUN 상시 실행 같은 고급 설정을 다루면 됩니다. 한 번에 하나의 변수만 변경하고 연결 기록과 출구 IP로 결과를 다시 확인하면 문제를 더 빠르게 찾을 수 있습니다.