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

먼저 핵심부터: 노드에 숫자가 표시된다고 앱 트래픽까지 프록시를 통과하는 것은 아닙니다

처음 확인할 때는 다음 순서로 진행하세요. 설정이 활성화되어 있는지 확인하고, 사용할 수 있는 노드를 선택한 다음 시스템 프록시를 켭니다. 새 요청을 보내 연결 기록을 확인하고, 마지막으로 외부 IP를 조회하세요. TUN을 켜고 DNS를 바꾸고 규칙을 수정하고 노드까지 바꾸는 일을 한꺼번에 하지 마세요. 페이지가 정상으로 돌아와도 어떤 변경이 효과를 냈는지 알기 어렵습니다.

Clash는 클라이언트와 코어 생태계를 아우르는 일반적인 명칭입니다. mihomo 코어를 사용하는 클라이언트는 버튼 배치와 세부 기능이 다를 수 있지만, 세 가지 과정을 구분해야 합니다. 구독은 노드와 규칙을 제공하고, 정책 그룹은 사용할 노드를 결정하며, 트래픽 진입 경로는 앱의 요청이 코어에 도달할지 결정합니다. 구독 가져오기에 성공했다는 사실만으로 이 세 과정이 모두 연결된 것은 아닙니다.

1. 설정이 활성화되어 있는지 확인하세요. 구독 목록에 이름이 나타나는지만 보지 말고, 현재 실행 중인 설정이 방금 가져온 설정인지도 확인하세요.
2. 작동 모드를 규칙 모드로 설정하세요. 처음 확인할 때는 기존 규칙을 유지해 모든 트래픽이 프록시로 강제 전송되지 않도록 합니다.
3. 실제로 사용하는 정책 그룹에서 노드를 선택하세요. 규칙이 ‘해외 사이트’나 ‘스트리밍’ 등 여러 그룹을 참조할 수 있으므로, 참조되지 않는 그룹 하나만 바꾸면 안 됩니다.
4. 시스템 프록시를 켠 뒤 새 요청을 보내세요. 연결 패널을 열어 요청이 코어에 들어간 다음 어디로 전달되는지 확인합니다.

지연 시간 테스트는 무엇을 측정할까? 같은 주소로 테스트한 뒤 노드를 비교하세요

노드 목록에 표시되는 밀리초 값은 대개 코어가 해당 노드를 통해 지정된 URL에 요청을 보내는 데 걸린 시간입니다. ICMP ping이나 다운로드 속도로 바로 해석해서는 안 됩니다. 연결 설정, 프록시 프로토콜 핸드셰이크, TLS 협상, HTTP 응답 대기 시간이 포함될 수 있으며, 정확한 측정 구간은 코어와 테스트 방식에 따라 다릅니다.

같은 조건에서 테스트해야 결과를 비교할 수 있습니다

클라이언트의 지연 시간 테스트 설정이나 설정 파일의 url-test 정책 그룹을 먼저 확인하세요. 흔히 HTTP 204를 반환하는 주소를 테스트 대상으로 사용합니다. 예를 들면 https://www.gstatic.com/generate_204입니다. 테스트 주소마다 네트워크 위치와 접속 가능성이 다르므로, 한 주소에서 측정한 80ms와 다른 주소에서 측정한 120ms를 그대로 비교해 순위를 매길 수는 없습니다.

• 테스트 주소를 고정하세요: 비교하는 동안 같은 URL을 사용하고 다른 사이트로 바꾸지 마세요.
• 세 차례 테스트하세요: 예를 들어 10초 간격으로 연속 측정값을 기록하세요. 이는 직접 결과를 관찰하기 위한 방법이며, 코어의 주기 설정을 변경하라는 뜻은 아닙니다.
• 대용량 작업은 잠시 중단하세요: 다운로드, 클라우드 드라이브 동기화, 시스템 업데이트는 로컬 대역폭을 사용해 결과에 영향을 줄 수 있습니다.
• 네트워크 환경을 기록하세요: 같은 노드라도 집 Wi-Fi, 휴대폰 핫스팟, 사무실 네트워크에서 성능이 크게 달라질 수 있습니다.

표의 수치는 측정값을 해석하는 방법을 보여 주기 위한 가상 예시이며, 특정 서비스에 대한 이 사이트의 실측 순위가 아닙니다. 세 차례 측정은 노드를 추리는 데 도움이 될 뿐, 장기적인 패킷 손실률을 계산하거나 혼잡 시간대의 품질을 보장하지 않습니다.

시간 초과가 발생해도 노드를 전혀 사용할 수 없다고 단정할 수는 없습니다

테스트 주소 차단, DNS 조회 실패, 노드 인증 만료, 로컬 네트워크 끊김 등 여러 원인으로 시간 초과가 발생할 수 있습니다. 모든 노드에서 동시에 시간 초과가 발생하면 네트워크와 테스트 URL부터 확인하세요. 한 노드에서만 계속 실패하면 다른 노드와 비교합니다. 테스트는 성공했는데 원하는 사이트가 열리지 않는다면 해당 사이트 자체를 테스트해야 합니다. HTTP 204 응답만으로 모든 사이트에 접속할 수 있다고 증명되는 것은 아닙니다.

용도에 따라 노드 고르기: 지연 시간, 안정성, 출구 지역을 따로 확인하세요

연속 테스트에서 모두 응답하는 노드를 먼저 고른 뒤 실제 사용 목적에 맞춰 추리세요. 노드 이름에 표시된 지역, 배수, ‘전용 회선’ 등의 문구는 제공업체의 표기일 뿐입니다. 실제 출구를 확인하는 절차를 대신할 수 없고, 회선 품질을 증명하지도 않습니다. 클라이언트에 지연 시간이 낮게 표시되더라도 특정 사이트의 지역 제한이나 계정 이용 가능 여부까지 보장하지는 않습니다.

• 웹 탐색 및 온라인 문서: 처음 열 때 원활한지, 연속해서 작업할 때 오류가 발생하지 않는지 확인하세요. 가끔 빠르지만 자주 시간 초과되는 노드보다 지연 시간이 다소 높아도 안정적인 노드가 쓰기 편합니다.
• 동영상 재생 및 파일 전송: 실제 버퍼링과 지속 전송 속도를 확인하세요. 짧은 요청 테스트로는 장시간 전송 성능을 알 수 없습니다. 다운로드 테스트 전에 트래픽 한도와 요금 부과 방식을 확인하세요.
• 화상 회의 및 실시간 통신: 지터, 패킷 손실, UDP 지원 여부와 앱 트래픽이 프록시로 들어오는지도 확인해야 합니다. HTTP 테스트 성공만으로 음성 통신이 가능하다고 단정할 수 없습니다.
• 특정 지역 출구가 필요한 서비스: 출구 지역, 사이트 규칙, 서비스 자체의 이용 조건을 함께 확인하세요. IP 데이터베이스의 국가 정보와 사이트가 판단하는 지역은 다를 수 있습니다.

처음 문제를 확인할 때는 노드 하나를 수동으로 고정하세요

url-test는 테스트 결과에 따라 노드를 자동 선택하고, fallback 그룹은 대개 설정된 순서대로 사용 가능한 항목을 고릅니다. 수동 선택 그룹은 사용자가 직접 지정합니다. 자동 정책이 노드를 바꾸면 앞뒤 요청이 서로 다른 출구를 사용할 수 있습니다. 결과를 재현하기 쉽도록 설정에서 허용하는 경우 관련 선택 그룹을 잠시 같은 노드에 고정해 확인한 뒤 자동 정책으로 되돌리세요.

정책 그룹이 중첩되어 있는지도 확인하세요. 예를 들어 ‘해외 사이트’ 그룹에서 ‘자동 선택’을 선택하고, ‘자동 선택’ 그룹이 구체적인 노드를 가리킬 수 있습니다. 화면에 표시된 바깥 그룹 이름이 최종 출구는 아니므로, 다음 단계에서 연결 세부 정보로 정책 경로를 따라가며 확인해야 합니다.

첫 번째 확인 방법: 연결 패널에서 대상 도메인과 정책 경로 확인하기

연결 패널은 가장 직접적인 확인 수단입니다. 클라이언트에서 ‘연결’ 또는 ‘Connections’라고 표시된 페이지를 열어 둔 다음 브라우저에서 대상 사이트에 접속하세요. 메뉴 이름은 클라이언트마다 다를 수 있습니다. 노드 지연 시간 목록이 아니라 대상 주소, 트래픽, 규칙을 표시하는 활성 연결 목록을 찾으면 됩니다.

1. 다른 다운로드를 잠시 중단하고 연결 목록에서 대상 도메인을 검색하세요.
2. 새 페이지나 시크릿 창을 열어 실제 네트워크 요청을 보내세요. 캐시된 페이지를 보기만 하면 새 연결이 생성되지 않을 수 있습니다.
3. 새로 나타난 기록을 열어 대상 도메인이나 IP, 적용된 규칙, 정책 경로, 업로드 및 다운로드 바이트를 확인하세요.
4. 정책 경로가 예상한 노드로 이어지는지 확인하세요. DIRECT 또는 REJECT로 끝나서는 안 됩니다.

DIRECT가 적용됐다면 요청은 코어에 들어왔지만 규칙에 따라 직접 연결된 것입니다. 이는 ‘브라우저가 Clash를 우회한다’는 문제와 다릅니다. 전자는 규칙 순서와 정책 그룹의 연결을 확인하고, 후자는 시스템 프록시, 브라우저 확장 프로그램, 앱 자체의 프록시 설정 또는 TUN 경로를 확인해야 합니다.

웹페이지 하나가 연결 하나를 의미하지는 않습니다. 기본 문서, 이미지, 로그인 API, 동영상이 서로 다른 도메인을 사용해 각각 다른 규칙이 적용될 수 있습니다. 특정 동영상이 재생되지 않는 이유를 파악하려면 사이트 도메인만 찾는 것으로는 부족하며, 실패한 리소스의 요청도 확인해야 합니다.

두 번째 확인 방법: 로그로 진입 경로, 규칙, 상위 연결 오류 구분하기

연결 패널에서는 요청이 어디로 향하는지, 로그에서는 처리 과정을 확인할 수 있습니다. 먼저 info 수준으로 설정해 문제를 한 번 재현하세요. 정보가 부족한 경우에만 잠시 debug 수준으로 올립니다. 확인이 끝나면 평소 수준으로 되돌려 불필요한 로그가 중요한 정보를 묻지 않도록 하세요.

코어 버전에 따라 로그 형식이 달라지므로 영어 문구가 완전히 똑같은 항목을 찾을 필요는 없습니다. 작업 시간, 대상 도메인, 선택한 노드를 기록하고 문제를 한 번만 재현한 뒤 같은 시간대의 기록을 추려 보는 편이 더 정확합니다. 스크린샷을 공유하기 전에 구독 주소, 인증 정보, 노드 서버 주소와 관련 없는 방문 도메인을 가리세요.

로그와 연결 목록 모두에서 해당 요청이 보이지 않으면 현재 실행 중인 코어의 기록을 보고 있는지 먼저 확인한 다음, 앱의 트래픽 진입 경로를 점검하세요. 트래픽이 코어에 들어오지 않은 상태에서 구독 규칙을 계속 바꿔도 대개 문제가 해결되지 않습니다.

세 번째 확인 방법: 외부 IP를 비교하되 조회 페이지만 믿지 마세요

IP 조회 페이지로 알 수 있는 것은 ‘이 조회 서비스에 접속할 때 사용한 출구’입니다. 모든 앱이 같은 노드를 거치거나 모든 프로토콜이 프록시로 전달된다는 뜻은 아닙니다. 규칙 모드에서는 조회 사이트가 직접 연결되고 대상 사이트는 프록시를 사용할 수 있습니다. 따라서 IP 결과와 해당 조회 요청의 연결 기록을 함께 확인해야 합니다.

명시적 프록시 명령으로 브라우저 설정과 분리해 확인하기

아래는 Windows의 curl.exe를 사용해 로컬 7890 포트로 요청을 명시적으로 보내는 예시입니다. macOS와 Linux에서는 대개 curl을 사용하며 옵션은 같습니다. 이 포트에서 HTTP 프록시 또는 혼합 프록시를 제공해야 합니다. SOCKS만 지원하는 포트에 그대로 적용할 수는 없습니다.

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

첫 번째 명령은 HTTP 프록시를 명시적으로 사용하고, 두 번째 명령은 curl이 앱 수준 프록시를 사용하지 않도록 합니다. 두 명령의 연결 설정 시간 제한은 10초, 전체 시간 제한은 20초입니다. 조회 서비스는 제3자가 운영하므로 이번 요청의 외부 IP를 확인할 수 있습니다. 결과를 공개할 필요는 없습니다.

• 명시적 프록시는 성공하지만 브라우저는 실패: 해당 명령이 사용한 경로는 작동한다는 뜻입니다. 브라우저의 트래픽 진입 경로, 확장 프로그램, 관련 도메인 규칙을 확인하세요.
• 연결 거부 메시지가 표시됨: 클라이언트가 실행 중인지, 포트 번호가 맞는지부터 확인하세요. 요청이 아직 노드 선택 단계까지 도달하지 않았을 수 있습니다.
• 두 출구가 서로 다름: 두 요청이 다른 출구를 사용했다는 뜻입니다. 프록시 요청에 실제로 적용된 정책은 연결 패널에서 확인해야 합니다.
• 두 출구가 같음: 곧바로 실패라고 판단하지 마세요. 조회 도메인에 직접 연결하는 규칙이 적용됐거나, TUN·다른 VPN을 사용 중이거나, 공인 IP 출구가 같을 수 있습니다.

조회 도메인을 프록시로 보내는 규칙이 실제로 적용되는 경우에만 로컬 포트에 명시적으로 연결한 요청이 프록시 노드까지 전달됩니다. 로컬 프록시 포트에 연결하는 것과 최종적으로 원격 출구를 사용하는 것은 서로 다른 단계의 확인입니다.

브라우저는 정상인데 다른 앱은 연결되지 않음: TUN 및 앱별 프록시 설정을 확인하세요

시스템 프록시가 모든 프로그램의 트래픽을 강제로 가로채는 것은 아닙니다. 일부 터미널 도구는 환경 변수를 사용하고, 일부 앱은 자체 HTTP 또는 SOCKS 설정을 제공하며, 시스템 프록시를 읽지 않는 앱도 있습니다. 브라우저는 정상인데 다른 앱의 연결 기록이 없다면 먼저 해당 앱의 프록시 지원 여부를 확인한 뒤 TUN을 켤지 결정하세요.

TUN은 더 많은 트래픽을 처리하기 위한 기능이지, 지연 시간을 줄이는 스위치가 아닙니다

TUN은 가상 네트워크 인터페이스와 라우팅을 통해 더 많은 트래픽을 코어로 전달합니다. 다만 실제 작동 여부는 관리자 권한, 서비스 상태, 라우팅 설정, DNS 처리 여부에 따라 달라집니다. 노드를 더 빠르게 만들어 주지는 않으며 규칙 모드를 자동으로 전역 프록시로 바꾸지도 않습니다. 트래픽이 TUN에 들어온 뒤에도 규칙에 따라 직접 연결될 수 있습니다.

1. 현재 설정을 먼저 저장하고 TUN만 켜세요. DNS 모드나 구독 내용은 동시에 바꾸지 마세요.
2. 클라이언트에서 가상 인터페이스가 만들어졌다고 표시되는지, 필요한 권한과 서비스가 준비되어 있는지 확인하세요.
3. 대상 앱을 다시 시작하거나 기존 연결을 끊은 다음 새 요청을 보내고 연결 패널을 확인하세요.
4. 회사 VPN이나 다른 터널 도구와 충돌한다면 기존 설정을 복구한 뒤 하나씩 따로 테스트하세요. 시스템 라우트를 무작정 삭제하지 마세요.

UDP 앱을 사용하려면 노드 프로토콜, 서버, 로컬 설정이 모두 UDP 전달을 지원해야 합니다. TUN에 앱 연결이 표시되더라도 HTTP 지연 시간 수치만으로 게임이나 회의 품질을 판단할 수는 없습니다. 앱 자체의 네트워크 통계에서 패킷 손실과 지터를 확인하고, 프록시를 사용하지 않을 때의 결과와 비교하세요.

설정 위치와 기본 용어는 입문 가이드와 사용 설명서의 프록시 모드 안내에서 확인할 수 있습니다. 연결이 안정적으로 작동한다면 테스트 수치를 낮추려고 여러 설정을 한꺼번에 바꿀 필요는 없습니다.

첫 연결 확인 목록

스크린샷에 아주 낮은 밀리초 값이 표시되는 것보다 아래 다섯 가지를 확인하는 편이 중요합니다. 네트워크 환경, 대상 도메인, 노드 이름, 실제 출구, 확인 시간을 기록해 두면 다음에 문제가 생겼을 때 같은 조건으로 다시 테스트할 수 있습니다.

• 설정: 예상한 구독이 현재 실행 중이며 노드와 규칙이 로드되어 있습니다.
• 노드: 같은 테스트 주소에 여러 차례 응답하며 실제 대상 사이트도 정상적으로 이용할 수 있습니다.
• 진입 경로: 브라우저나 대상 앱의 새 요청이 연결 패널에 실제로 표시됩니다.
• 경로: 예상한 규칙이 적용되고 정책 경로가 선택한 노드로 이어지며, 의도치 않은 직접 연결은 발생하지 않습니다.
• 출구: IP 조회 결과와 해당 요청의 정책 기록이 서로 일치하며, 다른 앱은 별도로 확인합니다.

어느 단계에서든 통과하지 못하면 해당 단계에서 계속 확인하세요. 연결이 없으면 진입 경로를, 연결은 있지만 직접 연결되면 규칙을, 노드를 선택했는데도 실패하면 상위 연결을 점검합니다. 한 번에 변수 하나만 바꾸는 편이 모든 스위치를 반복해서 켰다 끄는 것보다 원인을 찾기 쉽습니다.