Clash 최초 연결 가이드: 노드 선택, 지연 시간 테스트 및 프록시 상태 확인

최초 연결 전에 네 가지 단계를 구분하세요

Clash 클라이언트를 설치했다고 해서 네트워크가 자동으로 프록시를 거치는 것은 아닙니다. 일반적인 연결 과정은 구성 불러오기, 정책 그룹의 출구 선택, 클라이언트 코어 실행, 운영체제 또는 애플리케이션 트래픽의 Clash 유입이라는 서로 독립적인 네 단계로 이루어집니다. 어느 한 단계라도 완료되지 않으면 “클라이언트는 열려 있지만 웹페이지가 달라지지 않는” 상황이 발생할 수 있습니다.

구독은 노드, 정책 그룹, 규칙 등의 구성 정보를 제공합니다. 노드는 실제로 사용하는 프록시 출구이고, 규칙은 요청을 어느 정책 그룹으로 보낼지 결정합니다. 시스템 프록시 또는 TUN 모드는 트래픽을 Clash로 전달합니다. 처음 사용할 때는 이 순서대로 확인하고, 클라이언트를 계속 껐다 켜거나 노드를 연달아 바꾸지 않는 것이 좋습니다.

클라이언트마다 메뉴 이름은 조금씩 다를 수 있습니다. 예를 들어 “구성”은 Profiles, “프록시”는 Proxies, “일반”은 General로 표시되기도 합니다. Clash Meta（mihomo）코어 기반 클라이언트에는 DNS, TUN, 규칙 오버라이드와 같은 추가 옵션이 있을 수 있지만, 최초 연결에서 이러한 고급 항목을 바로 수정할 필요는 없습니다. 먼저 구독의 기존 구성으로 최소 연결을 완성하면 문제가 어느 단계에서 발생했는지 더 쉽게 확인할 수 있습니다.

구독을 가져오고 구성이 적용되었는지 확인하세요

서비스 제공업체에서 Clash 또는 Clash Meta 호환 구독 주소를 받은 뒤, 클라이언트의 구성 화면으로 이동해 URL 가져오기 기능으로 구독을 추가합니다. 데스크톱 클라이언트는 보통 구독 주소를 붙여 넣어 구성을 다운로드할 수 있으며, 모바일 클라이언트에서는 이 항목이 “URL에서 가져오기” 또는 “새 구성 만들기”로 표시될 수 있습니다. 구독 주소는 계정 구성 정보이므로 공개 페이지에 게시하지 말고, 일반 노드 주소로 착각해 하나씩 추가하지도 마세요.

가져오기가 완료되면 구성 목록에 새 항목이 나타나야 합니다. 업데이트 시간, 구성 이름 또는 노드 수가 표시되는지 확인하고, 해당 구성을 현재 사용 항목으로 직접 지정하세요. 목록에 다운로드만 되어 있고 선택하지 않았다면 클라이언트가 내장된 빈 구성, 이전 구성 또는 과거에 가져온 다른 구성을 계속 사용할 수 있습니다.

구독을 성공적으로 가져왔는지 확인하는 방법

• 구성 화면에 해당 항목이 표시되고, 수동 업데이트 시 형식 분석 오류가 발생하지 않습니다.
• 프록시 화면에 정책 그룹과 그룹 내 노드가 표시되며 DIRECT와 REJECT만 보이지 않습니다.
• 규칙 화면에 도메인, IP, 프로세스 또는 기본 처리 규칙이 있고 구성 내용이 비어 있지 않습니다.
• 클라이언트 로그에 구성 파일 없음, YAML 분석 실패 또는 포트 사용 중이라는 메시지가 반복해서 나타나지 않습니다.

구성은 다운로드되지만 프록시 화면에 노드가 없다면 먼저 구독 유형이 Clash에 적합한지 확인하세요. 일부 서비스는 일반 구독, 단일 노드 링크, Clash 구성 주소를 함께 제공하며, 클라이언트에는 Clash 또는 mihomo 구성으로 명확히 표시된 주소가 필요합니다. 업데이트 시 로그인 페이지, 권한 오류 또는 만료 안내가 반환된다면 먼저 구독 계정 상태를 해결해야 합니다. 클라이언트를 다시 설치해도 원격 구독 만료 문제는 해결되지 않습니다.

구성을 업데이트하면 정책 그룹의 선택 결과가 유지될 수도 있고 새 구성에 따라 다시 만들어질 수도 있습니다. 노드 이름이나 그룹이 변경되었다면 프록시 화면에 다시 들어가 현재 선택 항목을 확인하세요. 구독에서 삭제된 이전 노드를 계속 가리키는 일을 피할 수 있습니다.

규칙 모드, 전역 모드, 직접 연결 모드 이해하기

Clash의 일반적인 실행 모드는 규칙 모드, 전역 모드, 직접 연결 모드입니다. 최초 연결에는 규칙 모드를 우선 사용하는 것이 좋습니다. 구성의 규칙에 따라 요청의 경로가 결정되므로, 프록시가 필요한 트래픽은 프록시 정책 그룹으로 보내고 로컬 네트워크나 지정된 사이트는 직접 연결할 수 있으며, 어느 규칙에도 해당하지 않는 요청은 마지막 기본 규칙으로 처리됩니다.

전역 모드는 Clash로 들어온 대부분의 트래픽을 전역 정책 그룹으로 전달합니다. 특정 노드가 출구 역할을 할 수 있는지 짧게 확인할 때 유용하지만, 운영체제 수준에서 “모든 프로그램이 반드시 인계된다”는 뜻은 아닙니다. 트래픽이 클라이언트로 들어오는지는 여전히 시스템 프록시, TUN 모드, 애플리케이션 자체의 네트워크 동작에 달려 있습니다.

직접 연결 모드는 일반적으로 프록시 출구를 거치지 않습니다. 프록시 노드의 영향을 임시로 배제할 때는 유용하지만, 최초 연결의 최종 상태로 사용하기에는 적합하지 않습니다. 클라이언트가 정상 실행 중인데 외부 연결 결과가 계속 직접 연결과 같다면 모드가 DIRECT에 머물러 있지 않은지, 현재 정책 그룹이 DIRECT를 선택하지 않았는지 확인하세요.

정책 그룹과 노드 선택하기

프록시 화면에 들어가면 보통 여러 정책 그룹이 표시됩니다. 노드 선택, 자동 지연 시간 측정, 장애 조치, 스트리밍 서비스 또는 최종 출구를 나타내는 이름이 흔히 사용됩니다. 그룹 이름은 구독 구성에서 제공하며 모든 클라이언트가 동일하지는 않습니다. 최초 연결에서는 주요 프록시 트래픽을 담당하는 선택 그룹을 찾은 뒤, 현재 해당 그룹이 특정 노드, 다른 정책 그룹, DIRECT 중 무엇을 가리키는지 확인하세요.

그룹 안에 “자동 선택” 또는 URL-Test 유형의 정책 그룹이 있다면 구성에 지정된 테스트 주소와 주기에 따라 가용성을 측정하고 후보 노드 중 결과가 적절한 항목을 선택합니다. Fallback 유형은 장애 전환을 중시하며 보통 현재 사용 가능한 앞쪽 노드를 선택합니다. Select 유형은 사용자가 직접 지정해야 합니다. 화면에 지연 시간 수치가 표시된다고 해서 모든 정책 그룹이 자동으로 노드를 바꾸는 것은 아니며, Select 그룹은 수동 선택 결과를 따릅니다.

처음 노드를 선택할 때 유용한 기준

1. 먼저 연결 가능 여부를 확인하세요. 지연 시간 테스트를 안정적으로 완료하는 노드가 가끔 매우 낮은 수치를 보이지만 자주 시간 초과되는 노드보다 우선입니다.
2. 그다음 지연 시간을 보세요. 지연 시간이 짧으면 일반적으로 웹 응답과 상호작용에 유리하지만, 다운로드 대역폭을 직접 의미하지는 않습니다.
3. 사용 목적을 고려하세요. 일부 사이트는 출구 지역, IP 유형 또는 계정 지역을 요구하므로 실제 접속 목적에 맞춰 선택해야 합니다.
4. 한 번에 너무 많이 바꾸지 마세요. 최초 확인에서는 명확한 노드 하나만 선택하고, 연결에 성공한 뒤 다른 회선을 비교하세요.

정책 그룹은 서로를 참조할 수 있습니다. 예를 들어 “노드 선택” 그룹 안에 “자동 선택”이 포함되고, 규칙이 요청을 다시 “노드 선택”으로 보낼 수 있습니다. 이때 실제 출구는 여러 단계의 선택으로 결정됩니다. 선택 후에도 변화가 없다면 정책 그룹의 참조 관계를 단계별로 따라가 최종적으로 특정 노드를 가리키는지 확인하세요. DIRECT나 사용할 수 없는 하위 그룹에 계속 머물러서는 안 됩니다.

지연 시간 테스트 결과를 올바르게 이해하기

클라이언트의 지연 시간 테스트는 일반적인 ICMP Ping이 아닌 경우가 많습니다. Clash는 노드를 통해 지정된 테스트 URL에 HTTP 또는 HTTPS 요청을 보내고 연결 설정 및 응답 수신에 걸린 시간을 기록합니다. 따라서 결과는 로컬 네트워크, 프록시 프로토콜 핸드셰이크, 노드 부하, 테스트 사이트, 회선 품질의 영향을 함께 받습니다. 운영체제 명령줄에서 특정 서버에 ping이 성공해도 프록시 프로토콜 연결이 가능하다는 직접적인 증거는 아닙니다.

전체 테스트를 클릭했다면 먼저 한 차례 완료될 때까지 기다린 다음, 같은 노드의 여러 테스트 결과가 안정적인지 확인하세요. 수십 또는 수백 밀리초라는 값은 특정 네트워크 환경에서 측정된 결과일 뿐 모든 지역에 적용되는 고정 기준은 없습니다. 단일 수치보다 연속적인 결과가 중요합니다. 정상 수치와 시간 초과를 자주 오가는 노드는 실제 웹 탐색에서도 첫 화면 로딩이 길어지거나 연결이 끊길 가능성이 큽니다.

모든 노드가 동시에 시간 초과된다면 모든 노드가 함께 고장 났다고 단정하기보다 공통 조건을 먼저 의심하세요. 로컬 네트워크에서 외부 테스트 주소에 접속할 수 있는지, 시스템 시간이 정확한지, 구독이 방금 업데이트되었는지, DNS에 이상이 없는지, 방화벽이 클라이언트 코어의 인터넷 연결을 차단하지 않는지 확인합니다. 회사, 학교 또는 공용 네트워크에서는 특정 프로토콜이나 포트를 제한할 수 있으므로 모바일 핫스팟으로 비교 테스트해 보세요.

일부 노드만 시간 초과된다면 같은 그룹에서 결과를 안정적으로 반환하는 노드를 선택해 계속 확인하세요. 지연 시간 테스트에 성공해도 대상 웹사이트가 반드시 작동하는 것은 아닙니다. 대상 사이트에 지역 제한이 있거나 규칙이 해당 사이트를 다른 정책 그룹으로 보낼 수 있기 때문입니다. 최종 판단은 연결 로그와 실제 요청 결과를 함께 확인해야 합니다.

코어를 시작하고 시스템 프록시 설정하기

구성과 노드 준비가 끝나면 Clash 코어가 실행 중인지 확인하세요. 일부 클라이언트는 화면을 열 때 코어를 자동으로 실행하지만, 다른 클라이언트는 “서비스”, “실행” 또는 기본 연결 스위치를 켜야 합니다. 코어가 실행되지 않은 상태에서는 시스템에 프록시 주소가 입력되어 있어도 로컬 수신 포트가 없어 인터넷에 연결되지 않을 수 있습니다.

데스크톱 운영체제의 “시스템 프록시”는 일반적으로 운영체제의 HTTP 및 HTTPS 프록시 설정을 Clash의 로컬 수신 주소로 지정합니다. 시스템 프록시 설정을 따르는 브라우저와 애플리케이션은 요청을 Clash로 전달합니다. 일부 프로그램은 별도의 프록시 설정을 사용하거나 직접 연결을 만들거나 자체 네트워크 스택을 구현하므로 시스템 프록시를 자동으로 따르지 않습니다.

최초 연결에서는 시스템 프록시와 TUN을 동시에 켤 필요가 없습니다. 먼저 시스템 프록시로 브라우저 트래픽을 확인하면 경로가 더 명확하고 권한 요구도 적습니다. 기본 프록시가 정상적으로 작동하는 것을 확인한 뒤, 시스템 프록시를 따르지 않는 애플리케이션이나 UDP 트래픽 또는 더 많은 시스템 연결을 인계해야 할 때 클라이언트 안내에 따라 TUN 모드를 활성화하세요.

TUN 모드와 시스템 프록시의 차이

TUN 모드는 가상 네트워크 인터페이스와 시스템 라우팅을 통해 트래픽을 받으므로 일반적으로 시스템 프록시보다 적용 범위가 넓습니다. mihomo 코어 기반 클라이언트에는 자동 라우팅, DNS 하이재킹, 엄격한 라우팅과 같은 설정이 있을 수 있습니다. TUN을 활성화하려면 관리자 권한, 네트워크 확장 승인 또는 VPN 권한이 필요할 수 있으며, 다른 VPN, 가상 네트워크 어댑터, 기업 보안 소프트웨어와 충돌할 수도 있습니다.

처음 사용할 때 여러 트래픽 인계 방식을 동시에 켜면 원인을 판단하기 어려워집니다. 시스템 프록시만으로 브라우저가 정상 연결된다면 먼저 그 결과를 기록하고 TUN을 별도로 테스트하세요. 전환하기 전 다른 VPN을 끄고, 실패한 뒤에는 상태 표시줄 아이콘만 믿지 말고 클라이언트 로그에서 실제 전달이 설정되었는지 확인하세요.

세 단계로 프록시 상태 확인하기

연결 확인은 클라이언트 버튼의 색상만 보고 판단해서는 안 됩니다. 더 신뢰할 수 있는 방법은 클라이언트 로그, 실제 웹페이지 접속, 출구 정보를 차례로 확인하는 것입니다. 세 단계의 결과를 서로 대조하면 “코어가 시작됨”, “요청이 Clash로 들어옴”, “요청이 대상 노드를 통해 완료됨”을 구분할 수 있습니다.

첫 번째 단계: 연결 기록 확인

클라이언트의 연결 또는 로그 화면을 열고 브라우저에서 웹페이지를 새로 고침하세요. 정상이라면 새로운 도메인, 대상 주소, 매칭된 규칙, 정책 경로 기록이 나타납니다. 로그에는 요청이 특정 규칙과 매칭되어 정책 그룹을 거쳐 특정 노드로 전달되었다는 내용이 표시될 수 있습니다. 기록에 DIRECT가 표시된다면 현재 규칙에 따라 직접 연결된 것이며, 반드시 오류라는 뜻은 아닙니다.

브라우저를 새로 고친 뒤에도 새로운 연결 기록이 전혀 없다면 대개 트래픽이 아직 Clash로 들어오지 않은 것입니다. 이때 시스템 프록시가 켜져 있는지, 브라우저가 별도 프록시를 사용하는지, 클라이언트 수신 포트가 정상인지, 운영체제의 프록시 설정이 다른 프로그램에 의해 변경되지 않았는지 확인하세요.

두 번째 단계: 일반 웹페이지 접속

현재 네트워크 환경에서 결과가 명확한 웹페이지를 선택해 테스트하세요. 먼저 페이지가 열리는지 확인한 뒤 이미지, 스크립트, API 요청이 모두 정상인지 살펴봅니다. 홈페이지 하나만 열어서는 모든 연결을 확인할 수 없습니다. 페이지 리소스가 여러 도메인에 분산되어 있고 서로 다른 규칙으로 처리될 수 있기 때문입니다. 본문은 표시되지만 이미지나 동영상이 실패한다면 연결 기록에서 해당 리소스 도메인의 정책 경로를 찾아보세요.

세 번째 단계: 출구 정보 대조

신뢰할 수 있는 IP 정보 페이지에서 현재 출구 주소와 지역을 확인한 뒤, 시스템 프록시를 끈 상태의 결과와 비교하세요. 출구가 변경되고 로그에도 선택한 노드를 통한 요청으로 표시되어야 해당 브라우저 요청이 프록시를 통해 전달된 것으로 볼 수 있습니다. 출구가 바뀌지 않는다면 현재 정책이 DIRECT를 선택했는지, 조회 사이트가 직접 연결 규칙에 매칭되었는지, 브라우저에 시스템 프록시 우회 기능이 켜져 있는지 확인하세요.

1. 현재 노드를 그대로 유지하고 시스템 프록시를 켠 다음 테스트 페이지를 새로 고침하세요.
2. 연결 목록에서 테스트 페이지에 해당하는 도메인 요청을 찾으세요.
3. 정책 경로가 DIRECT가 아닌 예상 노드로 최종 연결되는지 확인하세요.
4. 출구 정보를 기록한 뒤 시스템 프록시를 끄고 한 번 더 비교하세요.
5. 테스트가 끝나면 필요한 트래픽 인계 방식을 다시 켜고 클라이언트 상태를 확인하세요.

최초 연결 실패 시 고정된 문제 해결 순서

문제를 해결할 때는 한 번에 조건 하나만 바꾸고 구성 단계에서 시스템 단계로 차근차근 진행하세요. 계속 재설치하거나 구독을 바꾸고 DNS까지 동시에 수정하면 간단한 문제도 비교 가능한 결과를 잃게 됩니다. 다음 순서는 대부분의 데스크톱 및 모바일 클라이언트에 적용할 수 있습니다.

“시스템 프록시를 켠 뒤 모든 웹페이지에 접속할 수 없음” 문제가 발생하면 먼저 시스템 프록시를 끄고 로컬 네트워크를 복구한 다음, 코어가 실행 중인지와 로컬 포트가 사용 중인지 확인하세요. 로그에 수신 실패가 나타난다면 다른 프록시 클라이언트가 같은 포트를 사용 중일 수 있습니다. 다른 프록시나 VPN 프로그램을 완전히 종료한 뒤 Clash를 다시 시작하는 편이 여러 포트를 임의로 변경하는 것보다 원인을 확인하기 쉽습니다.

“지연 시간 테스트는 정상인데 웹페이지가 열리지 않음” 문제가 발생하면 실제 요청 로그를 중점적으로 확인하세요. 테스트 URL과 대상 웹페이지는 서로 다른 사이트이므로 다른 규칙에 매칭되거나 DNS 결과가 다를 수 있습니다. 브라우저에서 HTTP/3, 별도 DNS 또는 확장 프로그램의 프록시 설정을 사용하고 있는지도 확인해야 합니다. 시스템 프록시를 따르는 다른 브라우저로 잠시 비교할 수 있지만, 노드와 실행 모드를 동시에 바꾸지는 마세요.

“일부 사이트는 정상이고 일부 사이트는 실패함”은 일반적으로 기본 연결은 성립했으며 문제가 규칙, 정책 그룹, DNS 또는 대상 사이트 제한에 있을 가능성이 높다는 뜻입니다. 실패한 도메인의 연결 기록을 찾아 어떤 규칙과 매칭되었고 어느 정책 그룹으로 전달되었는지 확인한 뒤 해당 그룹의 실제 출구를 점검하세요. 규칙 모드는 위에서 아래로 매칭되며 먼저 매칭된 규칙이 처리 방식을 결정합니다. 마지막 MATCH는 보통 기본 처리 역할을 합니다.

연결 성공 후 기본 설정

최초 확인이 끝나면 자동 업데이트, 시작 시 실행, 정책 저장을 설정할 수 있습니다. 구독 업데이트 주기는 지나치게 짧게 설정하지 말고 서비스 제공업체와 클라이언트의 기본 주기를 따르세요. 구성 업데이트 후에는 노드 이름, 정책 그룹 구조, 규칙이 변경되었는지 살펴보고 중요한 정책 그룹의 선택 상태를 다시 확인해야 합니다.

시작 시 실행을 활성화할 때는 “클라이언트 자동 실행”, “코어 자동 실행”, “시스템 프록시 자동 활성화”를 구분해야 합니다. 세 항목은 서로 독립적인 옵션일 수 있습니다. 공용 컴퓨터나 네트워크를 자주 전환하는 기기에서는 수동으로 시스템 프록시를 켜는 습관을 유지하는 편이 좋습니다. 클라이언트 코어가 준비되기 전에 작동하지 않는 시스템 프록시가 남는 일을 방지할 수 있습니다.

일상적인 사용에서는 안정적인 노드 하나를 기준 노드로 유지할 수 있습니다. 네트워크에 문제가 생기면 먼저 기준 노드를 테스트한 뒤 다른 노드와 비교하세요. 단일 회선의 변동인지, 로컬 네트워크·구독·클라이언트 전체의 문제인지 판단하는 데 도움이 됩니다. 더 넓은 범위의 트래픽을 인계해야 할 때는 TUN, DNS, 라우팅 옵션을 하나씩 설정하고, 변경할 때마다 “연결 기록—웹페이지 접속—출구 정보”의 세 단계 검사를 반복하세요.