Clash Meta 첫 연결 가이드: 노드 선택, 지연 시간 측정 및 프록시 작동 확인

첫 연결 시 확인 순서

먼저 설정을 활성화하고 노드를 선택한 다음 트래픽을 프록시로 전달합니다. Clash Meta에서 사용하는 mihomo 코어는 설정을 해석하고 규칙에 따라 트래픽을 분류해 외부 연결을 구성합니다. 클라이언트 화면에서는 구독과 각종 스위치를 관리합니다. 구독을 성공적으로 가져왔다는 것은 설정을 받아왔다는 뜻일 뿐, 브라우저 요청이 프록시를 통과한다는 의미는 아닙니다.

설정이 활성화됐는지 확인: 설정 목록에서 방금 가져온 구독을 선택한 뒤 코어 로그를 확인해 YAML 파싱 오류나 존재하지 않는 전략 그룹 참조 등의 문제가 없는지 살펴봅니다.
규칙 모드로 전환: 화면에는 ‘규칙’ 또는 ‘Rule’로 표시될 수 있습니다. 첫 연결을 확인할 때는 구독에 설정된 규칙을 그대로 두고 DNS, 규칙 세트, TUN 설정을 동시에 바꾸지 마세요.
사용 가능한 외부 연결 선택: 프록시 또는 전략 그룹 화면에서 대상 사이트에 실제로 적용되는 그룹을 찾아 사용 가능한 노드를 선택합니다.
트래픽 전달 방식 하나 활성화: 브라우저로 처음 테스트할 때는 시스템 프록시를 우선 사용하세요. 시스템 프록시 설정을 따르지 않는 앱까지 트래픽을 전달해야 한다면 TUN 모드를 별도로 확인합니다.
새 요청 보내기: 연결 기록, 적용된 규칙, 외부 IP를 함께 확인하세요. 스위치 색상만으로 판단하지 마세요.

전략 그룹에서 어떤 노드를 선택해야 할까요?

전략 그룹은 규칙과 외부 연결 사이에서 트래픽을 어디로 보낼지 선택하는 계층입니다. 예를 들어 규칙이 특정 사이트의 트래픽을 PROXY로 보내면, 이 그룹은 다시 노드나 다른 전략 그룹을 가리킵니다. 그룹 이름은 설정 작성자가 정하므로 ‘노드 선택’, ‘해외 사이트’ 등 다양한 이름을 사용할 수 있습니다. 이름만 보고 용도를 짐작하지 마세요.

규칙을 따라 최종 연결 대상 찾기

클라이언트에서 프록시 목록을 열고 수동 선택 그룹을 펼칩니다. 설정의 유형은 보통 select입니다.
DIRECT와 REJECT는 피하세요. 전자는 직접 연결, 후자는 연결 거부를 뜻하며 원격 프록시 노드가 아닙니다.
선택한 항목이 다른 전략 그룹이라면 계속 펼쳐 최종 대상이 실제 노드인지 확인하세요. 다시 직접 연결로 이어져서는 안 됩니다.
노드를 선택한 뒤 대상 사이트를 다시 열고 연결 기록에서 해당 요청에 적용된 그룹과 최종 연결 대상을 확인합니다.

처음 연결할 때는 노드를 하나 직접 지정하는 것이 좋습니다. 자동 지연 시간 측정 그룹 url-test은 설정된 테스트 주소, 주기, 허용 오차를 기준으로 연결 대상을 선택합니다. 장애 조치 그룹 fallback은 일반적으로 사용 가능한 항목을 순서대로 선택합니다. 어느 쪽도 ‘다운로드 속도가 가장 빠른 노드’를 뜻하지는 않습니다. 먼저 노드를 고정하면 테스트 중 자동 전환으로 인한 변수를 줄일 수 있습니다.

노드 이름만으로 실제 상태를 판단할 수 없습니다

노드 이름에 포함된 지역, 배율, 회선 정보는 구독 제공자가 붙인 설명이지 코어가 측정한 사실이 아닙니다. 특정 지역 이름이 붙은 노드라도 외부 IP의 위치 정보는 다르게 표시될 수 있으며, 위치 정보 데이터베이스의 갱신이 늦을 수도 있습니다. 먼저 노드 사용 가능 여부와 규칙 적용을 확인한 다음, 이용하려는 서비스에 맞춰 지역과 안정성을 비교하세요.

규칙 모드에서는 한국 내 사이트에 직접 연결하고 해외 사이트에는 프록시를 사용하는 구성이 흔합니다. 따라서 규칙이 직접 연결로 분류한 사이트를 열어도 선택한 프록시 노드가 트래픽을 처리하는지 확인할 수는 없습니다.

지연 시간 측정값과 시간 초과의 의미

클라이언트의 지연 시간 테스트는 보통 ICMP Ping이 아닙니다. mihomo는 지정된 URL에 HTTP 또는 HTTPS 요청을 보내 노드를 통해 전달하고, 요청에 걸린 시간을 표시하는 방식으로 테스트하는 경우가 많습니다. 테스트 주소, 연결 재사용, DNS, TLS 핸드셰이크, 대상 사이트의 응답 등이 결과에 영향을 줄 수 있습니다. 클라이언트나 테스트 URL이 다르면 측정값을 직접 비교하기 어렵습니다.

같은 주소로 세 번 연속 측정하기

예를 들어 클라이언트에서 테스트 URL을 설정할 수 있다면 https://www.gstatic.com/generate_204로 통일하고 시간 초과는 5000밀리초로 설정할 수 있습니다. 이 주소는 흔히 사용하는 테스트 대상이지만 모든 네트워크와 노드에서 접속할 수 있는 것은 아닙니다. 구독에 상태 확인 주소가 지정되어 있다면 먼저 기존 값을 기록해 두세요. 테스트 주소 문제를 노드 장애로 오해하지 않도록 주의해야 합니다.

측정값이 낮음: 이번 테스트 요청이 빠르게 완료됐다는 뜻입니다. 동영상 전송 속도가 빠르거나 대상 서비스에 접속할 수 있다는 보장은 아닙니다.
측정값 변동이 큼: 무선 네트워크, 네트워크 간 경로, 노드 혼잡, 테스트 서버 응답 등이 원인일 수 있습니다. 동일한 조건에서 다시 측정하세요.
Timeout 또는 시간 초과: 제한 시간 안에 테스트가 완료되지 않았다는 뜻입니다. 노드에 연결할 수 없는 경우뿐 아니라 테스트 주소 차단, DNS 문제, 노드 인증 실패 등이 원인일 수 있습니다.
값이 없거나 아직 테스트하지 않음: 먼저 테스트를 실행하세요. 값이 없다고 노드가 작동하지 않는다고 단정할 수는 없습니다.

세 번 측정한 결과가 86 ms, 92 ms, 89 ms이고 다른 노드의 결과가 45 ms, 시간 초과, 610 ms라면 처음 연결할 때는 첫 번째 노드를 우선 확인해 볼 수 있습니다. 이 수치는 판단 방법을 설명하기 위한 예시이며, 이 사이트에서 직접 측정한 결과가 아닙니다. 한 번 가장 낮게 나온 값보다 요청이 꾸준히 완료되는지가 더 중요합니다.

시스템 프록시와 로컬 포트 확인

클라이언트 설정에서 ‘시스템 프록시’ 스위치와 실제 수신 대기 포트를 확인합니다. 클라이언트마다 메뉴 위치가 다르므로 화면과 실제 적용된 설정을 기준으로 확인하세요. 시스템 프록시는 운영체제 설정에 프록시 주소를 지정하는 방식이며, 해당 설정을 따르는 앱만 이 프록시를 사용합니다. 명령줄 도구, 게임, 자체 네트워크 스택을 사용하는 일부 앱은 설정을 무시할 수 있습니다.

로컬 포트와 노드 포트 구분하기

127.0.0.1:7890은 내 컴퓨터의 프록시 진입점 주소이지 원격 노드 주소가 아닙니다. 아래는 설명을 위한 mihomo 설정 예시입니다. 7890은 예시 포트이며 모든 클라이언트의 기본값은 아닙니다. 이 예시는 수신 대기 포트와 모드만 설명하며, 연결 가능한 노드나 전략 그룹, 규칙은 포함하지 않습니다. 구독 설정 전체를 이 내용으로 덮어쓰지 마세요.

mixed-port: 7890
allow-lan: false
mode: rule

mixed-port는 하나의 포트에서 HTTP와 SOCKS 프록시 연결을 모두 받을 수 있습니다. 클라이언트에 실제 포트가 7897로 표시된다면 이후 명령에도 7897을 사용해야 합니다. 관리 인터페이스 포트 9090을 트래픽 프록시 포트로 사용하지 마세요. 관리 인터페이스는 코어를 제어하기 위한 것으로 여기서 설명하는 HTTP 프록시 진입점 역할을 하지 않습니다.

명시적 프록시 요청으로 문제 분리하기

macOS 또는 Linux에서는 다음 명령을 실행할 수 있습니다. Windows PowerShell에서는 일부 환경에서 같은 이름의 별칭이 인자 해석에 영향을 주지 않도록 명령 맨 앞의 curl을 curl.exe로 바꾸세요.

curl --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 https://api.ipify.org

이 명령은 로컬 HTTP 프록시를 명시적으로 사용하며 이번 요청의 프록시 우회 목록을 비웁니다. 이를 통해 ‘로컬 프록시 진입점이 작동하는지’와 ‘앱이 시스템 프록시를 사용하는지’를 구분할 수 있습니다. 요청이 mihomo에 도달한 뒤에는 현재 규칙이 적용되므로 IP가 출력되더라도 원격 노드를 사용했다고 단정할 수 없습니다. 연결 기록도 확인해야 합니다.

바로 연결이 거부되면 코어가 실행 중인지, 포트 번호가 맞는지, 다른 프로그램이 포트를 점유하고 있는지 먼저 확인하세요.
연결은 됐지만 시간 초과가 발생하면 노드 핸드셰이크, DNS, 상위 서버 연결 로그를 확인하세요. 시스템 프록시 스위치를 반복해서 전환하지 마세요.
명령은 성공하지만 브라우저에서 실패한다면 클라이언트를 재설치하기보다 브라우저 확장 프로그램, 개별 프록시 설정, PAC, 기존 연결을 먼저 확인하세요.

브라우저와 외부 IP 교차 확인

검증할 때는 새 요청이 mihomo에 들어가 예상한 규칙에 따라 분류되고, 예상한 연결 대상을 선택해 응답을 받는지 확인해야 합니다. 외부 IP는 보조 증거이며, 연결 기록을 보면 요청이 직접 연결되거나 프록시를 거친 이유를 파악할 수 있습니다.

기준값을 기록한 뒤 같은 대상을 비교하기

TUN과 시스템 프록시를 끄고 다른 VPN도 실행하지 않은 상태에서 브라우저로 https://api.ipify.org에 접속해 현재 외부 IP를 기록합니다. IP 조회 서비스에는 이번 요청의 외부 IP가 전달됩니다.
같은 네트워크와 테스트 주소를 유지한 채 시스템 프록시를 켭니다. 기존 탭을 닫고 다시 접속하세요. 필요하다면 브라우저를 종료한 뒤 다시 실행해 기존 연결이 재사용되는 영향을 줄입니다.
클라이언트의 ‘연결’ 또는 ‘Connections’ 화면에서 api.ipify.org를 찾습니다. 적용된 규칙, 전략 그룹 경로, 최종 연결 대상을 기록하세요. 요청이 짧아 금방 사라질 수 있으므로 로그도 함께 확인하면 좋습니다.
도메인에 DIRECT 규칙이 적용됐다면 현재 규칙상 프록시를 사용해야 하는 다른 테스트 대상을 선택하세요. 또는 영향을 충분히 이해한 상태에서 잠시 전역 모드로 테스트할 수 있습니다.

전역 모드에서는 라우팅 선택 방식이 바뀌지만 전역 전략 그룹에서 원격 노드를 선택해야 합니다. DIRECT를 선택하면 여전히 직접 연결됩니다. 테스트 후에는 규칙 모드로 복원해 임시 테스트 상태를 평소 설정으로 사용하지 않도록 하세요.

외부 IP가 기준값과 다르고 연결 기록에도 선택한 노드가 표시된다면 프록시가 작동한다는 비교적 확실한 증거입니다. IP가 같다면 규칙을 함께 확인하세요. 요청이 직접 연결됐을 수도 있고 프록시 출구와 기존 네트워크가 같은 공인 IP를 공유할 수도 있습니다. 반대로 다른 VPN을 사용했거나 네트워크가 바뀌어도 IP가 달라질 수 있으므로 IP만으로 결론 내리면 안 됩니다.

자주 발생하는 문제의 점검 순서

노드 지연 시간은 표시되지만 웹페이지가 열리지 않음

먼저 명시적 프록시 명령을 실행하세요. 명령은 성공하면 브라우저가 시스템 프록시를 사용하는지 확인합니다. 명령도 실패하면 해당 요청에 적용된 규칙과 연결 대상을 확인하세요. 테스트 URL에는 접속되지만 실제 서비스에는 접속할 수 없는 경우 대상 사이트의 제한, DNS, 프로토콜 차이, 노드 회선 문제가 원인일 수 있습니다. 한 번의 테스트 결과를 모든 사이트에 그대로 적용하지 마세요.

IP는 바뀌었지만 명령줄에서는 직접 연결됨

브라우저와 터미널은 서로 다른 방식으로 프록시 트래픽을 전달할 수 있습니다. 터미널 도구에는 자체 프록시 인자나 http_proxy, https_proxy 환경 변수가 필요할 수 있습니다. 처음 확인할 때는 단일 명령의 --proxy 인자를 사용하세요. 성공 여부를 확인한 뒤에 장기적으로 사용할 환경 변수를 설정하고, 변수 변경 후에는 새 프로세스에 적용됐는지도 확인합니다.

일반 웹페이지는 열리지만 게임이나 UDP 앱은 작동하지 않음

HTTP 요청이 성공해도 해당 경로를 사용할 수 있다는 뜻일 뿐 UDP까지 지원한다는 뜻은 아닙니다. 앱의 트래픽 전달 방식, 노드 프로토콜, 서버 측 UDP 지원 여부를 각각 확인하세요. TUN을 사용하면 더 많은 앱의 트래픽을 전달할 수 있지만 UDP를 지원하지 않는 원격 노드에 UDP 기능이 생기는 것은 아닙니다. TUN을 켜기 전에 시스템 권한, 가상 네트워크 어댑터, 다른 VPN과의 라우팅 충돌도 확인해야 합니다.

노드를 바꿨는데도 웹사이트에 기존 외부 IP가 표시됨

이미 연결된 장시간 연결은 노드를 바꿔도 바로 전환되지 않을 수 있습니다. 대상 페이지나 앱을 닫고, 필요하면 클라이언트에서 관련 연결을 종료한 뒤 새 요청을 보내세요. 모든 연결을 종료하면 다운로드, 회의 등 다른 세션도 중단되므로 영향을 먼저 확인해야 합니다. 변경한 전략 그룹이 대상 규칙에서 실제로 참조되는지도 확인하세요. 사용되지 않는 그룹만 바꿨을 수 있습니다.

첫 연결을 마친 뒤 기록할 내용

재현 가능한 정보를 로컬에 기록해 두면 단순히 ‘작동함’이라고 적어 두는 것보다 이후 문제를 파악하기 쉽습니다. 다음 다섯 항목을 저장하되 구독 URL, 인증 정보, 전체 설정 파일은 공개하지 마세요.

실행 환경: 운영체제 버전, 클라이언트 버전, 화면에 표시된 mihomo 코어 버전.
적용된 설정: 현재 설정 이름, 마지막 업데이트 시각, 규칙 모드 또는 임시 전역 모드.
연결 대상: 규칙에서 참조한 전략 그룹, 최종 노드, 같은 대상을 세 번 측정한 지연 시간 결과.
트래픽 전달 방식: 시스템 프록시 또는 TUN, 실제 로컬 포트, 다른 VPN의 동시 실행 여부.
검증 근거: 테스트 시각, 테스트 도메인, 적용된 규칙, 외부 IP, 요청 결과.

마지막으로 평소 사용할 규칙 모드로 복원하고 안정적인 노드 하나를 지정한 뒤 터미널, 다운로드 도구, 게임을 차례대로 확인하세요. 구독 업데이트 후 전략 그룹 이름이나 규칙이 바뀌었다면 최종 연결 대상을 다시 점검해야 합니다. 첫 연결 완료의 기준은 지연 시간 숫자가 표시되는 것이 아니라, 대상 앱의 새 요청이 예상한 규칙에 따라 전달되어 안정적으로 응답을 받는 것입니다.