Clash 첫 연결 점검 가이드: 노드 선택, 지연 시간 테스트와 프록시 작동 확인

1. 연결 전 점검: 설정, 코어, 트래픽 진입 경로

구독을 성공적으로 가져왔다는 것은 클라이언트가 설정을 받았다는 뜻일 뿐, 트래픽이 mihomo 코어로 들어간다는 보장은 아닙니다. 첫 연결은 설정 로드 여부, 트래픽 진입 경로, 정책 그룹의 노드 선택, 대상 연결의 실제 아웃바운드 순으로 확인하세요. DNS, TUN, 규칙을 한꺼번에 변경하면 문제가 생겼을 때 원인을 찾기 어렵습니다.

현재 설정 확인. 클라이언트의 「설정」 또는 「Profiles」 페이지에서 방금 가져온 구독이 선택되어 있는지 확인하세요. 다운로드만 하고 활성화하지 않은 설정은 현재 적용 중인 규칙과 노드를 바꾸지 않습니다.
코어 실행 상태 확인. 시작 로그에서 설정 파싱 오류, 포트 사용 중 오류, 프로세스 종료 기록이 있는지 살펴보세요. YAML 파싱 오류가 있다면 노드를 바꾸기 전에 설정부터 수정해야 합니다.
규칙 모드 선택. 첫 연결은 보통 Rule／규칙 모드로 확인하는 것이 좋습니다. Global／전역 모드는 임시 비교에 쓸 수 있지만, Direct／직접 연결 모드는 프록시 노드 검증의 시작점으로 적합하지 않습니다.
실제 포트 확인. 클라이언트 설정이나 적용 중인 설정에서 HTTP／혼합 포트를 확인하세요. 예를 들어 mixed-port: 7890은 해당 진입점에서 HTTP와 SOCKS 프록시 연결을 모두 받을 수 있다는 뜻입니다. 실제 포트 번호는 현재 설정을 따릅니다.

시스템 프록시와 TUN 중 선택하기

데스크톱에서는 먼저 시스템 프록시로 브라우저 요청을 확인하는 편이 문제를 찾기 쉽습니다. 시스템 프록시를 켜면 시스템 프록시 설정을 따르는 프로그램만 해당 진입점을 사용합니다. 일부 명령줄 도구, 게임, 네트워크를 자체 관리하는 앱은 시스템 프록시를 따르지 않습니다. TUN 모드는 가상 네트워크 인터페이스로 라우팅된 IP 트래픽을 받습니다. 적용 범위는 라우팅, 제외 설정, 플랫폼 권한에 따라 달라지므로 스위치를 켠다고 모든 연결이 코어로 들어가는 것은 아닙니다.

첫 테스트에서는 시스템 프록시를 가로채거나 프록시 라우트를 만드는 클라이언트를 두 개 이상 동시에 실행하지 마세요. Android와 iOS에서는 보통 시스템 VPN 권한을 통해 연결하므로, 권한 승인이 끝났고 연결이 계속 활성화되어 있는지 확인해야 합니다. 데스크톱 브라우저의 시스템 프록시 설정 방법을 그대로 적용할 수는 없습니다.

2. 정책 그룹 선택: 실제 아웃바운드를 결정하는 노드 찾기

「프록시」→「정책 그룹」 페이지에 표시되는 카드는 단일 노드일 수도 있고 다른 정책 그룹일 수도 있습니다. 규칙이 먼저 사용할 정책 그룹을 정하고, 해당 그룹이 최종 노드를 선택합니다. 대상 규칙에서 참조하지 않는 그룹의 노드만 바꾸면 해당 웹사이트에는 영향이 없습니다.

그룹 유형	선택 방식	첫 점검 항목
`select`	구성원 수동 선택	선택된 항목이 특정 노드인지, 다른 정책 그룹인지, DIRECT인지 확인
`url-test`	탐지 결과에 따라 자동 선택	테스트 주소, 탐지 주기, 현재 실제로 선택된 노드 확인
`fallback`	구성원 순서에 따라 사용 가능한 항목 선택	최저 지연 시간만 보지 말고 앞쪽 구성원의 정상 작동 여부 확인
`load-balance`	설정된 정책에 따라 연결 분배	연결마다 다른 노드를 사용할 수 있으므로 한 번의 출구 확인만으로 판단하지 않기

첫 검증에는 고정 노드 사용

대상 웹사이트의 규칙이 참조하는 정책 그룹을 찾으세요. 규칙이 어디를 가리키는지 모르면 먼저 웹사이트에 접속한 다음 연결 기록에서 확인할 수 있습니다.
해당 그룹에서 수동 선택을 지원한다면 특정 노드를 선택하세요. 테스트 도중 자동으로 노드가 바뀌면 결과를 비교하기 어렵습니다.
그룹에서 「자동 선택」 같은 하위 그룹을 선택했다면 계속 펼쳐 최종 사용 노드를 확인하세요. 바깥쪽 그룹 이름만 기억해서는 안 됩니다.
노드를 바꾼 뒤에는 테스트 연결을 새로 만드세요. 기존 TCP 장기 연결, HTTP/2 연결, QUIC 세션은 새 노드로 즉시 옮겨가지 않을 수 있습니다.

DIRECT는 직접 연결을 뜻하며, 특별한 이름의 프록시 노드가 아닙니다. REJECT는 연결 거부를 뜻합니다. 노드 상태가 정상으로 보여도 대상 규칙의 최종 아웃바운드가 이 둘 중 하나라면, 지연 시간이 아무리 낮아도 해당 요청은 예상대로 프록시를 거치지 않습니다.

3. 지연 시간 테스트: 수치, 시간 초과, 전송 속도 구분하기

클라이언트에 표시되는 노드 지연 시간은 단순한 ICMP ping이 아닌 경우가 많습니다. mihomo의 URL 탐지는 노드를 통해 설정된 테스트 주소에 접속하므로, 노드 연결 및 프로토콜 핸드셰이크, 테스트 사이트 응답, 로컬 네트워크 상태가 결과에 영향을 줍니다. 클라이언트의 구체적인 시간 측정 방식은 호출 방법에 따라 달라질 수 있으므로 같은 조건에서 비교하는 용도로만 사용하세요.

테스트 조건을 통일한 다음 비교하기

같은 URL 사용: 적용 중인 설정에서 url 값을 확인하세요. 일반적으로 https://www.gstatic.com/generate_204를 탐지 주소로 사용합니다. 테스트 대상이 다르면 수치를 직접 비교하기 어렵습니다.
같은 네트워크 사용: 동일한 Wi-Fi 또는 유선 네트워크에서 한 차례 테스트하세요. 모바일 데이터 결과를 섞지 마세요.
반복해서 확인: 연속으로 3회 테스트하고 각 결과를 기록하세요. 예를 들어 한 그룹이 82, 91, 86 ms이고 다른 그룹이 65, 460, 시간 초과라면, 안정성은 앞의 그룹부터 확인하는 편이 좋습니다. 수치는 설명을 위한 예시이며 이 사이트에서 측정한 결과가 아닙니다.
단일 테스트와 주기적 탐지 구분: 버튼을 눌러 수동으로 테스트하면 한 번의 결과가 나옵니다. 정책 그룹의 상태 확인은 자체 설정에 따라 실행되므로 결과가 갱신되는 시점이 서로 다를 수 있습니다.

다음은 정책 그룹 설정에서 필드를 확인하기 위한 예시입니다. 기존 PROXY 그룹을 참조하므로 전체 설정으로 바로 사용할 수 없습니다. interval: 300의 단위는 초이고, tolerance: 50의 단위는 밀리초입니다. 후자는 작은 지연 시간 변화로 인한 노드 전환을 줄이는 값이며 요청 시간 초과 설정이 아닙니다.

proxy-groups:
  - name: AUTO
    type: url-test
    proxies:
      - PROXY
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

지연 시간이 낮아도 다운로드가 빠른 것은 아닙니다

짧은 요청의 완료 시간과 지속 전송 처리량은 서로 다른 지표입니다. 지연 시간이 70 ms인 노드라도 출구 대역폭, 혼잡, 서버 측 속도 제한 때문에 다운로드가 느릴 수 있습니다. 반대로 160 ms인 노드는 장시간 전송이 더 안정적일 수 있습니다. 첫 연결에서는 먼저 웹페이지가 정상적으로 열리는지 확인한 뒤, 실제 용도에 따라 동영상, 파일 전송, 응답 속도를 테스트하세요. 목록에서 가장 낮은 수치만 보고 계속 사용할 노드를 정하지 마세요.

4. 프록시 작동 확인: 진입 경로, 규칙, 출구 증거

연결 스위치만 보는 것보다 한 번의 요청에 대한 증거를 연결해 확인하는 것이 정확합니다. 트래픽이 코어에 들어왔는지, 예상한 규칙에 일치했는지, 예상한 노드로 나갔는지를 확인하세요. 브라우저에서 웹사이트가 열린다는 사실은 사용할 수 있는 경로가 있다는 뜻일 뿐입니다. 해당 사이트에 원래 직접 연결할 수 있었다면 이것만으로 프록시 작동을 입증할 수 없습니다.

명시적 프록시로 로컬 진입점 확인

혼합 포트가 7890임을 확인했다고 가정합니다. 다음 명령을 사용하면 앱이 시스템 프록시를 따르는지 여부를 변수에서 제외할 수 있습니다. Windows PowerShell에서는 같은 이름의 별칭이 인수 해석에 영향을 주지 않도록 curl.exe를 사용하세요. macOS와 Linux에서는 명령어를 curl로 바꿔도 됩니다.

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

--noproxy ""는 이 명령에서 프록시 우회 목록을 비우는 옵션입니다. 이 명령으로 확인할 수 있는 것은 명시한 진입점이 작동하는지뿐입니다. 시스템 프록시 설정이 올바른지 확인해 주는 것도 아니고, 규칙이 프록시 노드를 선택하도록 강제하지도 않습니다. 규칙에 따라 IP 조회 서비스가 직접 연결되면 로컬 네트워크의 출구 IP가 반환될 수 있습니다.

연결 기록에서 같은 요청 추적하기

클라이언트의 「연결」 페이지를 열고 api.ipify.org 같은 대상 도메인으로 필터링하세요.
새 요청을 보내고 대상 도메인 또는 IP, 일치한 규칙, 정책 경로, 최종 노드를 확인하세요. 짧은 연결은 기록에서 금방 사라질 수 있으므로 기록 내역이나 로그도 함께 살펴보세요.
연결 경로가 DIRECT가 아니며 최종 노드가 직접 선택한 노드와 일치하는지 확인하세요. 하위 그룹 이름이 표시된다면 실제 구성원을 더 살펴보세요.
기록이 전혀 없다면 원격 노드를 탓하기 전에 포트, 앱의 프록시 설정, TUN 라우트를 확인하세요.

로그의 info 레벨이면 일반적인 연결과 규칙 정보를 확인하는 데 대체로 충분합니다. 추가로 조사해야 할 때만 일시적으로 debug를 활성화하고, 작업이 끝나면 원래 레벨로 되돌리세요. 클라이언트에 따라 로그 형식이 다르게 표시될 수 있으므로 대상, 규칙, 아웃바운드를 중점적으로 확인하고 문구 형식까지 완전히 같을 필요는 없습니다.

출구 IP 비교

먼저 직접 연결이 허용되는 테스트 환경에서 같은 IP 조회 서비스의 직접 연결 결과를 기록한 다음, 프록시 규칙을 확인하고 같은 조회를 다시 실행하세요. 두 결과가 다르고 프록시 요청의 연결 기록이 예상한 노드를 가리켜야 더 확실하게 판단할 수 있습니다. IP 위치 정보 데이터베이스는 최신 정보가 아닐 수 있으며, 노드 이름에 적힌 도시와 데이터베이스가 표시하는 도시가 다를 수도 있습니다.

두 결과가 같다면 먼저 조회 요청이 직접 연결 규칙에 일치했는지 확인하고, 프록시 출구가 현재 네트워크와 우연히 같은 공인 IP를 공유하는지도 살펴보세요. 듀얼 스택 네트워크에서는 IPv4와 IPv6를 구분해야 합니다. IPv4 조회 한 번으로 IPv6 트래픽도 프록시를 거친다고 단정할 수 없습니다. 검사 페이지에 특정 결과를 표시하려고 IPv6를 무작정 끄지 말고, 먼저 클라이언트의 IPv6, DNS, 라우팅 설정을 확인하세요.

5. 자주 발생하는 문제: 증상에 따라 점검 범위 좁히기

증상	우선 확인할 항목	다음 조치
노드 테스트는 성공하지만 브라우저 연결 기록이 없음	시스템 프록시, 브라우저 자체 프록시 설정	명시적 프록시 명령을 실행해 진입점 문제와 브라우저 설정 문제 구분
연결 기록에 DIRECT 표시	모드, 규칙 순서, 정책 그룹 선택	일치한 규칙을 확인하세요. 규칙은 위에서부터 차례로 적용되므로 마지막 기본 규칙만 확인해서는 안 됩니다.
로컬 포트 연결 거부	코어 실행 상태와 실제 수신 포트	시작 로그를 확인해 7890이 실제로 현재 혼합 포트인지 확인
도메인 조회 실패	코어 DNS, 상위 DNS 서버 연결 가능 여부	문제가 로컬 조회에서 발생했는지 프록시 원격 측에서 발생했는지 확인하세요. DNS 설정을 한꺼번에 바꾸지 마세요.
노드를 바꿔도 출구 IP가 달라지지 않음	기존 연결 재사용, 자동 선택 그룹, 로드 밸런싱	연결을 새로 만들고 최종 노드를 확인하세요. 필요한 경우 해당 대상의 기존 연결만 종료하세요.
브라우저는 정상이지만 다른 앱은 연결 실패	앱의 시스템 프록시 지원 여부, UDP, 라우팅	앱의 프록시 지원 여부를 확인한 다음 TUN 연결이 필요한지 판단하세요.

TUN을 켠 뒤에만 문제가 생긴다면 관리자 권한이나 시스템 확장 권한, 가상 네트워크 어댑터, 라우팅, DNS 가로채기를 집중적으로 확인하세요. auto-route, dns-hijack이 포함된 설정 조각을 구독 전체에 그대로 덮어쓰지 마세요. 이 설정은 플랫폼, 코어 버전, 클라이언트의 관리 방식에 따라 달라지며 잘못 덮어쓰면 다음 구독 업데이트 때 설정이 다시 바뀔 수도 있습니다.

유지 관리 담당자에게 문제를 알릴 때는 운영체제, 클라이언트 버전, mihomo 코어 버전, 현재 모드, 진입 포트, 대상 도메인, 민감 정보를 가린 오류 내용을 제공하세요. 구독 링크, 인증 매개변수, 컨트롤 인터페이스 키는 공개하지 마세요. 연결 로그에 방문 기록이 포함될 수 있으므로 파일 전체를 그대로 공개해서도 안 됩니다.

6. 첫 연결 완료 기준

현재 Profile이 활성화되어 있고 코어가 계속 실행 중이며, 로그에 설정 로드 오류가 없어야 합니다.
테스트 대상 앱의 트래픽이 코어로 들어오고 연결 페이지에서 해당 대상을 찾을 수 있어야 합니다.
대상 요청이 예상한 규칙에 일치하고 정책 경로의 최종 아웃바운드가 선택한 노드와 일치해야 합니다.
같은 조건에서 지연 시간 테스트를 여러 번 실행하고 실제 대상에 접속해 사용 가능 여부를 확인해야 합니다.
출구 IP 조회 결과와 연결 기록이 서로 일치해야 하며, IPv4와 IPv6 중 어디까지 확인했는지 구분해야 합니다.

점검을 마친 다음 자동 선택 그룹을 다시 사용하거나 TUN 환경으로 확장하세요. 설정은 한 번에 하나씩만 바꾸고 테스트 연결을 새로 만드세요. 구독을 반복해서 새로고침하거나 노드를 바꾸고 클라이언트를 재설치하는 것보다 문제 원인을 찾기 쉽습니다. 기본 사용 방법은 사용 가이드에서, 개념 차이는 개념 빠른 참조에서 확인하세요.