Clash 첫 연결 문제 해결: 노드 선택, 지연 시간 테스트, 프록시 적용 확인

1. 설정, 코어, 트래픽 진입점 확인

구독을 성공적으로 가져왔다는 것은 클라이언트가 설정을 받아 인식했다는 뜻일 뿐, 트래픽이 노드를 통과한다는 뜻은 아닙니다. 프록시 연결은 보통 앱이 요청을 로컬 진입점으로 전달하고, mihomo가 규칙에 따라 정책을 선택한 다음, 정책 그룹이 노드를 고르고, 노드가 대상 서비스에 연결되는 순서로 이뤄집니다. 구독을 반복해서 업데이트하기보다 이 흐름을 따라 단계별로 확인하는 편이 효과적입니다.

이 글은 mihomo 코어를 사용하는 데스크톱 클라이언트를 기준으로 합니다. 클라이언트마다 버튼 위치는 다를 수 있으니 먼저 ‘설정’, ‘프록시’, ‘연결’, ‘로그’ 페이지를 찾고 시스템 프록시나 TUN 상태를 확인하세요. Android는 보통 VpnService로 트래픽을 처리하므로 데스크톱의 시스템 프록시 설정 절차를 그대로 따를 필요가 없습니다.

테스트 전 확인할 네 가지

설정이 활성화되어 있는지 확인: 구독 이름이 보이는 것만으로는 부족합니다. 현재 설정으로 선택되어 있는지 확인하세요. ‘다운로드됨’과 ‘활성화됨’은 서로 다른 상태입니다.
코어가 실행 중인지 확인: 로그에 설정 파싱 실패, 포트 충돌, 프로세스 종료가 반복해서 나타나지 않아야 합니다. 프로토콜을 지원하지 않는다면 먼저 클라이언트에서 사용하는 코어를 확인하세요.
규칙 모드 사용: 첫 확인은 ‘규칙’ 또는 rule 모드로 시작하고 현재 선택된 정책 그룹을 기록하세요. 규칙과 DNS를 동시에 변경하지 마세요.
트래픽 처리 경로는 하나만 사용: 데스크톱에서는 다른 프록시 프로그램과 VPN을 먼저 끄고 시스템 프록시만 테스트하세요. 시스템 프록시를 따르지 않는 앱의 트래픽까지 처리해야 할 때 TUN을 테스트하세요.

2. 노드 선택: 실제 적용된 정책 경로 확인

‘프록시’ 페이지의 항목은 노드일 수도 있고 정책 그룹일 수도 있습니다. 수동 선택 그룹 select은 지정한 항목을 사용합니다. 자동 지연 시간 측정 그룹 url-test은 테스트 결과와 허용 오차에 따라 선택하며, 장애 조치 그룹 fallback은 보통 설정 순서에 따라 사용 가능한 항목을 고릅니다. 지역명이 붙은 항목 하나만 보고 실제 출구가 바뀌었다고 단정할 수는 없습니다.

예를 들어 규칙이 요청을 ‘웹 접속’ 그룹으로 보내고, 그 그룹이 다시 ‘자동 선택’을 고르면 마지막에 특정 노드가 선택됩니다. 이 경우 다른 ‘수동 노드’ 그룹을 바꿔도 해당 요청에는 영향이 없을 수 있습니다. 프록시 페이지에서 강조된 항목만 보지 말고 연결 상세 정보에서 정책 경로를 추적하세요.

처음 노드를 선택하는 순서

클라이언트의 ‘프록시’ 페이지를 열고 접속하려는 대상에 사용되는 정책 그룹을 찾습니다. 아직 확실하지 않다면 우선 기본 선택 그룹의 이름을 기록하세요.
수동 선택이 가능한 그룹에서 이름이 명확하고 테스트에 성공한 노드를 하나 고릅니다. 여러 단계로 중첩된 그룹을 한꺼번에 바꾸지 마세요.
대상에 다시 접속한 뒤 ‘연결’ 페이지에서 규칙, 정책 그룹, 최종 노드를 확인하세요.
노드를 바꿔야 한다면 해당 항목만 변경하고 같은 테스트를 반복하세요. 대상 URL과 네트워크 환경은 그대로 유지합니다.

지역명은 서비스 제공자가 붙인 표시일 뿐, 물리적 거리나 실제 출구를 증명하지는 않습니다. 첫 테스트에서는 지리적으로 가까운 지역을 후보로 골라도 되지만, 최종 선택은 연결 성공률, 반복 테스트의 편차, 실제 서비스 접속 결과를 기준으로 하세요. 구독 만료, 트래픽 소진, 서버 인증 실패로 여러 노드를 한꺼번에 사용할 수 없게 될 수도 있습니다.

3. 지연 시간 테스트: 밀리초 수치의 의미

클라이언트의 지연 시간 테스트는 보통 코어가 지정된 노드를 통해 테스트 URL에 요청을 보내고 소요 시간이나 실패 여부를 보고하는 방식입니다. 일반적으로 ICMP ping이나 다운로드 속도 측정과는 다릅니다. 연결 수립 시간을 포함하는지, 연결을 재사용하는지, 성공 여부를 어떻게 판단하는지는 코어 구현과 설정에 따라 달라집니다. 테스트 주소나 클라이언트가 다르면 표시된 수치를 직접 비교하기 어렵습니다.

화면 표시	알 수 있는 점	다음 단계
86ms 표시	해당 테스트가 지정된 대상에 성공했고 소요 시간이 측정되었습니다.	테스트를 반복한 뒤 실제로 접속해야 하는 웹사이트도 확인하세요.
timeout 표시	제한 시간 안에 테스트가 완료되지 않았습니다. 원인은 아직 알 수 없습니다.	로그를 확인해 노드 연결, DNS, 테스트 대상 문제를 구분하세요.
0 또는 빈 값 표시	테스트 전이거나 대기 중일 수 있으며, 화면에서 특수 값으로 표시했을 수도 있습니다.	테스트를 직접 실행하세요. 지연 시간이 0이라고 해석하지 마세요.
측정값이 크게 달라짐	현재 네트워크, 서버 부하 또는 연결 경로가 불안정할 수 있습니다.	대상과 네트워크를 고정하고 다른 후보 노드와 비교하세요.

대상을 고정하고 세 번 반복 측정

약 10초 간격으로 테스트를 세 번 실행하고 결과를 기록해 보세요. 아래는 결과를 해석하는 예시이며, 이 사이트에서 실제로 측정한 값은 아닙니다. 노드 A는 82, 88, 85ms이고 노드 B는 48ms, 760ms, 시간 초과라고 가정해 봅시다. 처음에는 B의 최저값만 보고 고르기보다 A를 선택해 안정성을 확인하는 편이 낫습니다. 대용량 파일 전송 속도, 동영상 버퍼링, 게임 UDP 성능은 각각 따로 테스트해야 합니다.

모든 노드에서 동시에 시간 초과가 발생하면 클라이언트의 테스트 주소부터 확인하세요. 특정 테스트 서버에 접속할 수 없으면 정상 노드도 실패로 표시될 수 있습니다. 클라이언트의 속도 측정 설정에서 응답이 빠르고 신뢰할 수 있는 다른 HTTPS 주소로 바꿔 비교해 보세요. 테스트 실패만으로 구독 전체를 덮어쓰지는 마세요.

4. 시스템 프록시 확인: 로컬 포트를 지정해 테스트

데스크톱 시스템 프록시는 시스템 설정을 따르는 앱에 로컬 프록시를 사용하도록 알리지만, 모든 프로그램의 트래픽을 자동으로 처리하지는 않습니다. 명령줄 도구, 프록시를 별도로 설정한 브라우저, 일부 게임과 UDP 앱은 다른 경로를 사용할 수 있습니다. 먼저 클라이언트에 표시된 HTTP 또는 혼합 포트를 확인한 다음 프록시를 명시해 테스트하면 노드 문제와 시스템 프록시 적용 문제를 분리할 수 있습니다.

포트 및 시스템 설정 확인

Windows 11: ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’로 이동해 수동 프록시 주소와 포트를 확인하세요. 클라이언트에서 자동 구성 스크립트를 사용한다면 해당 항목도 확인합니다.
macOS: ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 연결 → ‘세부사항’ → ‘프록시’로 이동해 웹 프록시 또는 보안 웹 프록시 설정을 확인하세요.
클라이언트: 로컬 수신 포트를 확인하세요. 아래 예시는 7890을 사용하므로 실제 HTTP 또는 혼합 포트가 이 값일 때만 명령을 그대로 실행할 수 있습니다.

로컬 프록시 주소는 보통 127.0.0.1입니다. 설정에서 SOCKS 포트만 열려 있다면 아래 HTTP 프록시 명령을 그대로 사용하지 마세요. 올바른 프로토콜을 선택하거나 클라이언트의 혼합 포트를 사용하세요. 로컬 테스트를 위해 ‘LAN 연결 허용’을 켤 필요도 없습니다.

# macOS / Linux: 로컬 HTTP 또는 혼합 포트를 명시적으로 사용
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 --verbose --output /dev/null https://example.com/

# Windows PowerShell: 이전 환경의 명령 별칭 차이를 피하려면 curl.exe 사용
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 --verbose --output NUL https://example.com/

--connect-timeout 10은 연결 단계의 대기 시간을 제한하고, --max-time 20은 요청 전체의 제한 시간을 설정합니다. 예시 대상은 연결 확인용 주소일 뿐이므로 모든 서비스 웹사이트의 접속 가능 여부를 판단할 수는 없습니다. --proxy는 코어로 들어가는 진입점만 지정합니다. 원격 노드를 거칠지는 현재 모드와 규칙에 따라 결정됩니다.

로컬 포트 연결이 거부됨: 코어가 실행 중인지, 포트 번호가 맞는지, 해당 포트가 HTTP 프록시를 지원하는지 먼저 확인하세요.
CONNECT 200이 표시됨: 프록시가 터널 연결 요청을 수락했다는 뜻입니다. 이어서 TLS와 최종 HTTP 응답을 확인해야 하며, 이 한 줄만으로 접속이 완전히 성공했다고 볼 수는 없습니다.
프록시를 명시하면 성공하지만 브라우저에서는 실패: 구독을 바꾸기 전에 시스템 프록시, 브라우저 확장 프로그램, 별도 프록시 설정, 기존 연결을 먼저 확인하세요.

5. 연결 패널: 요청의 규칙 적용과 최종 출구 확인

브라우저에서 웹페이지가 열린다고 해서 원격 프록시를 거친 것은 아닙니다. DIRECT가 적용됐거나 요청이 코어에 전혀 들어오지 않았을 수도 있습니다. 제대로 확인하려면 연결 패널에 새 요청이 표시되는지, 예상한 규칙이 적용됐는지, 정책 경로가 의도한 노드에 도달하는지 세 가지를 모두 확인해야 합니다.

전체 트래픽이 아니라 개별 요청을 확인하세요

‘연결’ 페이지를 열고 현재 시각을 기록한 다음, 브라우저에서 새 창을 열어 확인할 대상에 접속하세요.
대상 도메인으로 연결을 필터링하세요. 연결이 매우 짧게 끝난다면 로그를 미리 열어 두고 확인하세요. 일부 클라이언트는 종료된 연결을 저장하지 않습니다.
상세 정보를 펼쳐 대상 도메인 또는 IP, 적용된 규칙, 정책 경로, 업로드 및 다운로드 바이트를 확인하세요. 프로세스 이름은 플랫폼과 권한에 따라 표시되지 않을 수 있으므로 필수 증거는 아닙니다.
DIRECT로 표시되면 규칙 설계에 맞는지 먼저 확인하세요. 규칙 모드에서 로컬 서비스나 일부 웹사이트에 직접 연결되는 것은 정상적인 분기일 수 있습니다.
노드를 바꾼 뒤에는 기존 탭을 닫거나 해당 연결을 종료하고 새 요청을 보내세요. 기존 TCP 장기 연결은 정책을 바꿔도 자동으로 다른 노드로 이동하지 않는 경우가 많습니다.

출구 IP 조회는 보조 확인 수단으로 활용할 수 있습니다. 같은 조회 서비스를 사용해 직접 연결과 예상한 프록시 연결 결과를 비교하고, 연결 패널에서 해당 조회에 프록시 정책이 적용됐는지도 확인하세요. 서로 다른 웹사이트에 표시된 지역명만 비교하지 마세요. 데이터베이스, IPv4와 IPv6의 차이로 잘못 판단할 수 있습니다. 출구 IP가 바뀌더라도 해당 조회의 경로만 확인된 것이며 모든 앱의 트래픽이 처리된다는 뜻은 아닙니다.

6. TUN 및 자주 발생하는 문제: 한 번에 변수 하나만 변경

프록시를 명시한 테스트는 성공했는데 특정 프로그램이 연결 패널에 계속 표시되지 않을 때 TUN을 고려하세요. TUN은 가상 네트워크 인터페이스와 관련 라우팅을 통해 트래픽을 처리하므로 시스템 프록시를 따르지 않는 앱에 적합합니다. 그래도 코어의 규칙과 정책 그룹을 사용하며 모든 요청이 원격 노드를 통과하는 것은 아닙니다. 활성화할 때 관리자 권한, 서비스 모드 또는 드라이버가 필요할 수 있으니 클라이언트 안내를 따르세요.

증상	우선 확인할 항목	확인 방법
속도 테스트는 성공했지만 연결 페이지에 브라우저 요청이 없음	시스템 프록시가 적용되지 않았거나 앱이 프록시를 우회했거나 기존 연결을 계속 사용 중입니다.	프록시 포트를 명시해 테스트한 뒤 브라우저 연결을 다시 시작하세요.
요청은 코어에 들어오지만 DIRECT로 연결됨	현재 모드, 처음 일치한 규칙, 중첩된 정책 그룹을 확인하세요.	해당 연결의 규칙 상세 정보를 보고 예상한 동작인지 확인하세요.
특정 노드에서 연결 시간 초과가 계속 발생	노드 연결 가능 여부, 서비스 상태, 인증 정보를 확인하세요.	같은 대상을 유지하고 다른 노드로 비교 테스트하세요.
로그에 도메인 이름 확인 실패가 표시됨	클라이언트의 DNS 설정과 상위 DNS 서버에 연결할 수 있는지 확인하세요.	기존 설정은 유지하고 실패한 도메인과 DNS 로그를 확인하세요.
TUN을 켠 뒤 전체 네트워크에 문제가 발생	다른 VPN, 가상 네트워크 어댑터, 라우팅, DNS 처리 간 충돌을 확인하세요.	TUN을 끄고 기존 상태를 복원한 뒤 권한과 충돌을 하나씩 확인하세요.

잠시 전역 모드와 비교한 뒤 규칙 모드로 복원

규칙 모드에서 대상 접속에 실패하면 잠시 전역 모드로 전환하고 GLOBAL 그룹에서 사용 가능한 동일 노드를 명시적으로 선택한 뒤 새 연결을 시도하세요. 전역 모드에서는 성공하지만 규칙 모드에서는 실패한다면 대상에 적용된 규칙과 정책을 중점적으로 확인합니다. 둘 다 실패하면 노드와 대상 서비스를 계속 점검하세요. 전역 모드는 진단을 위한 비교 수단일 뿐, 코어에 들어오지 않는 앱까지 자동으로 프록시를 사용하게 하지는 않습니다.

문제를 확인하는 동안 노드 변경, DNS 수정, TUN 활성화, 규칙 업데이트를 동시에 하지 마세요. 결과의 원인을 찾기 어려워집니다. 단계마다 ‘시각, 대상, 모드, 진입 포트, 노드, 오류 메시지’를 기록하면 문제를 재현하기 쉽습니다. 로그의 timeout, connection refused, 인증 오류는 서로 다른 단계의 문제를 가리키므로 모두 ‘네트워크 연결 안 됨’으로 묶지 말고 구체적인 오류에 맞춰 대응하세요.

7. 첫 연결 성공 여부 확인 기준

현재 설정이 활성화되어 있고 mihomo 코어가 정상 실행되며 로컬 프록시 포트에 연결할 수 있습니다.
같은 테스트 대상을 사용해 후보 노드에서 반복 테스트가 성공하고 지속적인 시간 초과가 발생하지 않습니다.
실제 앱이 새 요청을 보냈을 때 연결 패널에 표시되고 예상한 규칙이 적용됩니다.
프록시가 필요한 요청은 의도한 노드로 연결되고 직접 연결 요청은 예상한 DIRECT 경로를 유지합니다.
실제 서비스에 접속할 수 있습니다. 전역 모드 결과만 확인하지 말고 규칙 모드로 돌아가 다시 테스트하세요.

이 다섯 가지를 확인하면 로컬 진입점부터 최종 출구까지의 증거를 확보할 수 있습니다. 이후 연결이 끊기면 같은 순서로 다시 확인하고 먼저 달라진 단계를 찾은 뒤 설정을 조정하세요. 구독 가져오기와 시스템 트래픽 처리 방법은 입문 가이드에서 확인할 수 있습니다. 설정 개념과 매개변수는 전체 문서를 참고하세요.