Clash 첫 연결 가이드: 노드 선택, 지연 시간 측정, 프록시 적용 확인

1. 첫 연결 확인 순서

먼저 정책 그룹에서 노드를 선택하고 연결을 테스트한 다음, 앱 요청이 실제로 어떤 경로로 나가는지 확인합니다. 클라이언트에 ‘연결됨’이라고 표시되더라도 보통 커널이나 VPN 인터페이스가 시작되었다는 뜻일 뿐입니다. 노드 옆에 지연 시간이 표시되는 것도 테스트 요청에 응답이 왔다는 의미입니다. 이 두 상태만으로 브라우저가 프록시를 사용한다고 단정할 수는 없습니다.

이 글은 Clash 또는 mihomo 커널을 사용하는 그래픽 클라이언트를 기준으로 설명합니다. 클라이언트마다 메뉴 이름은 다를 수 있으니 ‘설정’, ‘프록시’, ‘연결’, ‘로그’ 등의 화면을 찾아보세요. 처음 확인할 때는 브라우저 하나, 대상 웹사이트 하나, 직접 선택한 노드 하나만 사용해 여러 설정을 동시에 바꾸지 않는 것이 좋습니다.

1. ‘설정’ 화면에서 구독이 목록에 다운로드만 된 것이 아니라 활성화되었는지 확인합니다.
2. ‘프록시’ 화면에서 규칙 모드를 사용하고 대상 웹사이트가 이용할 정책 그룹을 찾습니다.
3. 노드를 테스트한 뒤 응답이 있는 항목 하나를 직접 선택합니다.
4. 시스템 프록시를 켜거나 앱에 필요한 경우 TUN을 활성화합니다.
5. 새 웹 요청을 보내고 외부 IP, 규칙, 프록시 체인을 함께 확인합니다.

2. 정책 그룹에서 실제 노드 선택하기

구독을 불러오면 목록에 노드와 정책 그룹이 함께 표시될 수 있습니다. 노드에는 서버와 프로토콜 설정이 포함되고, 정책 그룹은 노드를 선택하거나 다른 정책 그룹을 참조합니다. 최상위 그룹을 눌렀다고 선택이 끝난 것은 아닐 수 있으므로 참조 관계를 따라 최종 출구까지 확인해야 합니다.

수동 선택과 자동 선택 구분하기

예를 들어 최상위 ‘프록시 선택’ 그룹이 ‘자동 선택’을 가리키고, 이 그룹이 다시 특정 노드를 가리킨다면 실제 경로는 정책 그룹 두 개와 노드 하나로 구성됩니다. 처음 문제를 확인할 때 설정에 수동 노드 선택 옵션이 있다면 노드를 직접 선택해 자동 전환으로 인한 변수를 줄일 수 있습니다. 그룹 이름은 구독 제작자가 정하므로 이름에 ‘프록시’가 들어 있다고 해서 프록시 노드가 반드시 선택된 것은 아닙니다.

규칙 모드와 전역 모드 중 무엇을 선택할까

• 일상적인 사용에는 규칙 모드부터 사용하세요: 커널은 rules의 순서대로 규칙을 확인하며, 요청에 따라 프록시, 직접 연결 또는 거부가 적용될 수 있습니다.
• 전역 모드는 비교용으로만 사용하세요: 일시적으로 전환한 뒤에도 GLOBAL에서 실제로 선택된 항목을 확인해야 합니다. 전역 모드만으로 시스템 프록시나 TUN을 통한 트래픽 유입이 설정되는 것은 아닙니다.
• 테스트가 끝나면 규칙 모드로 되돌리세요: 조회 페이지에 다른 주소를 표시하려고 모든 로컬 및 중국 본토 서비스를 같은 출구로 장기간 보내지 마세요.

규칙 모드에서는 특정 웹사이트가 직접 연결되지만 전역 모드에서는 프록시를 사용할 수 있다면, 클라이언트를 바로 다시 설치하지 말고 먼저 규칙 적용 여부와 정책 그룹 선택을 확인하세요.

3. 지연 시간을 일괄 측정해 사용 가능한 노드 찾기

‘프록시’ 화면에서 지연 시간 테스트나 새로고침 버튼을 찾아 현재 정책 그룹을 먼저 테스트한 뒤 응답이 있는 노드를 선택합니다. 테스트는 보통 노드를 거쳐 지정된 URL에 접속합니다. 측정 시간은 테스트 주소, DNS, 연결 설정, TLS, 테스트 방식에 따라 달라지며 노드 서버에 ICMP Ping을 한 번 보내는 것과는 다릅니다.

1. 먼저 로컬 네트워크가 연결되어 있는지 확인하고 구독에 포함된 노드가 모두 표시될 때까지 기다립니다.
2. 현재 그룹의 일괄 테스트를 시작하고 한 차례 결과가 나올 때까지 기다립니다. 불필요한 동시 요청이 생기지 않도록 연속으로 누르지 마세요.
3. 응답이 있는 노드 하나를 선택한 뒤 약 10초 간격으로 두 번 더 테스트해 반복적으로 시간 초과가 발생하는지 확인합니다.
4. 같은 대상 웹페이지를 열어 연결을 확인하고, 마지막으로 인접 지역의 대체 노드와 비교합니다.

판단 방법을 보여 주기 위한 예시 데이터입니다. 노드 A의 세 차례 결과는 82, 89, 86ms이고 노드 B는 45ms, 시간 초과, 310ms입니다. 첫 연결에는 A를 선택하는 편이 낫습니다. B의 최저값은 더 낮지만 결과 편차와 시간 초과를 보면 이번 테스트에서는 안정성이 떨어집니다. 이는 이 사이트에서 특정 서비스를 직접 측정해 순위를 매긴 결과가 아닙니다.

지연 시간이 다운로드 속도를 뜻하는 것은 아닙니다. 지연 시간이 짧은 노드도 대역폭, 혼잡, 대상 사이트의 제한, 출구 공유 여부에 영향을 받을 수 있습니다. 첫 연결을 확인할 때는 작은 HTTPS 페이지가 안정적으로 열리는지만 먼저 확인하고, 바로 대용량 속도 테스트를 할 필요는 없습니다.

4. 트래픽 유입 설정: 시스템 프록시 또는 TUN

노드를 사용할 수 있게 된 뒤에는 앱의 요청이 커널로 전달되도록 설정해야 합니다. 시스템 프록시는 시스템 프록시 설정을 따르는 브라우저와 앱에 적합합니다. TUN은 가상 네트워크 인터페이스를 통해 트래픽을 처리하므로 시스템 프록시를 읽지 않는 더 많은 앱에서 사용할 수 있지만, 라우팅, 제외 항목, 클라이언트 설정에 따라 동작이 달라질 수 있습니다.

먼저 시스템 프록시로 브라우저 확인하기

클라이언트에서 ‘시스템 프록시’를 켭니다. Windows에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 설정이 반영되었는지 확인할 수 있습니다. macOS에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 서비스 → ‘세부사항’ → ‘프록시’에서 확인합니다. 시스템 버전에 따라 메뉴 이름이 달라질 수 있으므로 클라이언트에 표시된 수신 주소와 포트를 기준으로 확인하세요.

아래는 각 항목의 의미를 설명하기 위한 YAML 일부이며 완전한 구독 설정이 아닙니다. 7890은 예시 포트입니다. 클라이언트에 7897로 표시된다면 이후 명령에도 7897을 사용해야 합니다. 클라이언트의 재정의 기능이 구독 설정을 덮어쓸 수 있으므로 최종적으로는 커널의 실행 설정과 실제 수신 상태를 기준으로 판단하세요.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

• mixed-port: 하나의 포트에서 HTTP와 SOCKS 프록시 요청을 모두 받습니다.
• allow-lan: false: 로컬 네트워크에 프록시를 공개하지 않습니다. 처음 로컬 기기에서 확인할 때는 보통 활성화할 필요가 없습니다.
• mode: rule: 규칙에 따라 출구를 결정합니다. 모든 요청이 노드를 사용하는 것은 아닙니다.
• log-level: info: 일반적인 연결 정보를 확인할 수 있습니다. 실제로 표시되는 내용은 클라이언트와 커널에 따라 다릅니다.

TUN은 필요한 경우에만 활성화하기

브라우저는 정상적으로 연결되는데 게임이나 다른 앱은 계속 직접 연결된다면, 먼저 해당 앱이 프록시를 지원하는지 확인한 뒤 TUN을 고려하세요. 데스크톱 클라이언트는 보통 서비스 모드나 관리자 권한이 필요하고, 모바일에서는 일반적으로 시스템 VPN 권한이 필요합니다. 라우팅을 제어하는 VPN 클라이언트를 여러 개 동시에 실행하면 기본 경로와 DNS 설정이 서로 영향을 줄 수 있으니 피하세요.

TUN을 켠 뒤에는 테스트 연결을 새로 만들어야 합니다. 기존 TCP 연결은 계속 이전 경로를 사용할 수 있으므로, 연결을 재사용하는 페이지를 새로고침하는 것만으로는 새 설정이 반영됐는지 확인하기 어려울 수 있습니다.

5. 외부 IP와 연결 로그를 교차 확인하기

확실하게 확인하려면 두 가지 증거가 필요합니다. 조회 서비스가 확인한 접속 주소와 커널에 기록된 실제 프록시 체인입니다. 조회 페이지는 해당 요청이 어디에서 나갔는지 보여 주고, 연결 기록은 커널이 왜 그 경로를 선택했는지 보여 줍니다.

먼저 직접 연결 상태를 기록한 뒤 프록시 결과와 비교하기

1. 시스템 프록시와 TUN을 잠시 끄고 일반 네트워크로 공인 IP를 한 번 조회해 시간, 주소, 통신사 정보를 기록합니다.
2. 프록시 설정을 다시 켜고 앞서 테스트를 통과한 노드를 선택합니다.
3. IP 조회를 다시 실행하는 동시에 클라이언트의 ‘연결’ 화면을 열고 조회 서비스 도메인을 검색합니다.
4. 적용된 규칙, 대상 주소, 프록시 체인을 확인하고 최종 항목이 DIRECT가 아닌지 확인합니다.

IP 조회 사이트 자체가 규칙에 따라 직접 연결될 수도 있습니다. 주소가 바뀌지 않았다면 먼저 로그를 확인하세요. 주소는 바뀌었는데 로그에 해당 요청이 없다면 브라우저 확장 프로그램이나 다른 VPN이 프록시를 사용하고 있는지도 살펴봐야 합니다. IP 위치 데이터베이스는 최신 정보가 아닐 수 있으므로 국가나 도시 표시는 참고 자료로만 사용하세요.

명령으로 브라우저 설정의 영향을 배제하기

아래 명령은 로컬 HTTP 혼합 포트 7890을 사용해 api.ipify.org에서 외부 IPv4 주소를 조회하는 예입니다. Windows PowerShell에서는 curl.exe를 사용하고, macOS와 Linux에서는 같은 인수로 curl을 실행합니다.

# Windows: 애플리케이션 프록시를 사용하지 않음
curl.exe -4 --noproxy "*" --max-time 15 https://api.ipify.org

# Windows: 로컬 HTTP 프록시를 명시적으로 사용
curl.exe -4 --proxy http://127.0.0.1:7890 --noproxy "" --max-time 15 https://api.ipify.org

--noproxy "*"는 curl의 애플리케이션 프록시만 우회할 뿐 TUN이나 상위 VPN을 우회하지는 않습니다. 직접 연결 기준값을 측정하기 전에도 이러한 트래픽 유입 기능을 꺼야 합니다. 두 번째 명령은 로컬 포트를 명시적으로 사용하지만 커널이 여전히 규칙을 적용하므로 ‘원격 노드를 강제로 이용하는’ 명령은 아닙니다. 해당 요청에 적용된 규칙과 최종 출구를 함께 확인해야 합니다.

정상 연결 기록 읽는 방법

‘연결’ 화면에서 필터를 설정한 뒤 명령을 다시 실행합니다. 짧은 요청은 금방 끝날 수 있으므로 연결 목록에 활성 연결만 표시된다면 ‘로그’ 화면을 확인하세요. 로그 형식이 특정한 모양이어야 하는 것은 아니며, 다음 항목을 중점적으로 살펴보면 됩니다.

• 대상: 도메인이 방금 접속한 서비스와 일치해야 하며, 포트는 보통 443입니다.
• 규칙: 도메인 규칙, 규칙 세트 또는 최종 규칙인 MATCH가 적용될 수 있습니다. 실제로 어떤 항목이 적용됐는지 기록하세요.
• 프록시 체인: 예상한 정책 그룹을 거쳐 선택한 노드로 연결되는지 확인합니다.
• 결과: 요청 결과 주소가 표시되고 인증, 핸드셰이크 또는 연결 시간 초과 오류가 계속 발생하지 않아야 합니다.

6. 첫 연결 문제 해결 순서

노드에 지연 시간은 표시되지만 브라우저에서 페이지가 열리지 않음

먼저 프록시를 명시한 curl 명령으로 테스트합니다. 명령은 성공하는데 브라우저에서 실패한다면 브라우저가 별도의 프록시 확장 프로그램을 사용하는지, 시스템 프록시를 무시하는지, 기존 연결을 다시 만들어야 하는지 확인하세요. 127.0.0.1:7890에 연결할 수 없다는 오류가 나오면 수신 포트와 커널 상태부터 확인합니다. 이 경우 요청은 아직 원격 노드에 도달하지 않은 상태입니다.

외부 IP는 바뀌지 않았지만 웹페이지는 열림

먼저 조회 도메인에 DIRECT가 적용되었는지 확인한 다음 정책 그룹의 최종 선택 항목을 살펴보세요. 필요하다면 전역 모드로 잠시 전환해 비교하고 GLOBAL의 구성원도 확인합니다. 확인이 끝나면 원래 모드로 되돌리세요. 기업 네트워크, 상위 VPN 또는 같은 출구를 사용하는 서비스 때문에 주소 비교가 명확하지 않을 수도 있습니다. 이럴 때는 IP 위치보다 프록시 체인 기록이 더 유용합니다.

모든 노드에서 시간 초과 발생

• 구독 유효 기간, 계정 잔여 트래픽, 노드 목록 갱신 상태를 확인합니다.
• 기기 시간을 확인합니다. 시간이 크게 어긋나면 TLS 인증서 검증에 문제가 생길 수 있습니다.
• 가정용 Wi-Fi에서 휴대전화 핫스팟으로 전환하는 등 다른 네트워크에서도 비교해 봅니다.
• 로그에서 이름 해석, 인증, 핸드셰이크 오류를 확인한 뒤 필요할 때 DNS 설정을 조정합니다.

일부 앱만 프록시를 사용함

이 경우 모든 노드를 다시 테스트하기보다 트래픽 유입 설정을 확인해야 합니다. 앱이 시스템 프록시를 읽는지, UDP 또는 QUIC을 사용하는지, TUN 라우팅에 해당 앱의 트래픽이 포함되는지 확인하세요. HTTP 프록시 명령이 성공했다는 것은 해당 HTTP 프록시 경로를 사용할 수 있다는 뜻일 뿐, 모든 UDP 트래픽도 처리된다는 의미는 아닙니다.

문제를 문의할 때는 클라이언트 이름, 커널 버전, 운영체제 버전, 수신 포트, 작업 시간, 오류 유형을 기록해 두세요. 스크린샷을 공유하기 전에 구독 URL, 인증 정보, 개인 네트워크 주소를 가리고 전체 설정을 공개 토론 공간에 그대로 올리지 마세요.

7. 첫 연결 완료 확인

다음 항목을 모두 확인했다면 평소 사용으로 돌아가도 됩니다. 이후 노드만 바꾸는 경우에는 보통 시스템 프록시, DNS, TUN 설정을 다시 변경할 필요가 없습니다.

• 현재 설정이 활성화되어 있고 커널이 정상적으로 실행 중이며 수신 포트가 클라이언트에 표시된 값과 일치합니다.
• 대상 정책 그룹이 최종적으로 사용 가능한 노드를 가리키며 반복 테스트에서 계속 시간 초과가 발생하지 않습니다.
• 브라우저 또는 대상 앱의 트래픽이 커널로 전달되고 있습니다.
• 외부 IP 조회 결과와 연결 기록이 서로 일치하며 대상 요청이 예상한 노드를 거쳤습니다.
• 테스트에 사용한 전역 모드를 원래대로 되돌렸고 다른 VPN이나 프록시 설정과 충돌하지 않습니다.

프록시 적용 여부는 ‘어떤 앱에서, 어떤 대상을, 어느 요청으로’ 확인했는지 구체적으로 따져야 합니다. 확인 범위를 이렇게 정해야 노드 연결 가능 여부, 규칙 설정, 트래픽 유입이라는 서로 다른 문제를 구분할 수 있습니다.