1. Clash, Mihomo, Clash Verge Rev는 무엇이 다른가요?

Clash는 프록시 도구와 설정 생태계에서 널리 쓰이는 이름이고, Mihomo는 프록시 코어이며, Clash Verge Rev는 Mihomo를 사용하는 데스크톱 클라이언트입니다. 클라이언트는 구독 관리, 프록시 선택, 시스템 프록시 설정, 로그 확인 기능을 제공하고, 코어는 실제 연결과 DNS 처리, 규칙 매칭을 담당합니다. 클라이언트를 설치해도 사용할 수 있는 노드가 자동으로 생기는 것은 아닙니다.

Mihomo는 예전에 Clash.Meta라는 이름으로 알려졌습니다. 예전 가이드를 검색하면 Clash Meta나 Meta 코어 같은 표현을 볼 수 있지만, 코어와 버전에 따라 지원하는 설정 항목이 다를 수 있습니다. 설정 오류가 발생하면 먼저 클라이언트 버전, 코어 버전, 전체 오류 메시지를 기록한 다음 호환성 문제인지 확인하세요.

  • 클라이언트: Clash Verge Rev처럼 설정과 조작 기능을 화면에 표시합니다.
  • 코어: 실행 시 설정을 읽고 프록시 연결을 구성해 트래픽 분기 규칙을 적용합니다.
  • 구독: 서비스 제공업체에서 받는 설정 또는 노드 목록입니다. 클라이언트가 자동으로 생성하지 않습니다.

이 글은 Clash Verge Rev의 데스크톱 사용 방식을 중심으로 설명합니다. Android의 VPN 권한과 데스크톱의 시스템 프록시는 서로 다른 방식이므로, 두 플랫폼의 설정을 그대로 대응시킬 수 없습니다. 클라이언트를 고를 때는 먼저 클라이언트 비교를 참고하세요.

2. 구독 링크란 무엇이며 어디서 받을 수 있나요?

구독 링크는 설정을 가져오는 주소이며, 보통 계정 토큰이 포함됩니다. 서비스 제공업체에 따라 계정 관리 페이지, 일반 노드 구독, Clash 설정 구독 등 여러 주소가 제공될 수 있습니다. Clash Verge Rev에 가져올 때는 Clash 또는 Mihomo 설정과 호환되는 주소를 선택하세요. 브라우저 주소창에 표시된 계정 홈페이지 주소를 복사하면 안 됩니다.

가져오기 전 확인할 3가지

  1. 본인 서비스 계정에서 받은 링크인지, 이용권이나 권한이 유효한지 확인하세요.
  2. 지원되는 설정 데이터가 반환되는지 확인하세요. 로그인 페이지, 결제 안내 또는 웹 오류 페이지가 반환되면 안 됩니다.
  3. 링크가 온전한지 확인하세요. 메신저에서 줄이 바뀌거나 복사 과정에서 공백이 추가되고 쿼리 매개변수가 빠지면 요청이 실패할 수 있습니다.

전체 설정에는 proxies, proxy-groups, rules 등의 항목이 포함될 수 있습니다. proxy-providers를 통해 노드를 불러오는 방식도 있으므로 proxies가 없다는 이유만으로 설정이 잘못됐다고 단정할 수 없습니다. 노드 목록만 있는 구독은 기존 설정과 함께 사용해야 할 수도 있습니다.

3. Clash Verge Rev에 구독을 어떻게 가져오나요?

먼저 가져오고, 설정을 활성화한 다음, 노드를 선택하세요. 각각 설정 가져오기, 코어에서 설정 불러오기, 프록시 출구 선택에 해당합니다. 가져오기에 성공한 것만으로는 첫 단계만 완료된 상태입니다.

  1. 왼쪽 메뉴에서 「구독」 페이지를 열고 구독 링크 입력란에 주소를 붙여 넣은 다음 「가져오기」를 실행하세요. 버전에 따라 새 구독 메뉴 안에 기능이 있을 수 있으니 실제 화면을 확인하세요.
  2. 구독 카드가 나타날 때까지 기다리세요. 업데이트 결과, 노드 수, 트래픽 정보가 표시되는지 확인합니다. 해당 정보의 표시 여부는 서버가 데이터를 제공하는지에 따라 달라집니다.
  3. 구독을 선택해 현재 사용할 설정으로 지정하세요. YAML 구문이나 항목 오류가 표시되면 먼저 오류를 해결하고, 네트워크 전체를 가로채는 설정을 한꺼번에 켜지 마세요.
  4. 「프록시」 페이지로 이동해 실제 규칙에서 참조하는 정책 그룹을 찾고 사용할 노드를 선택하세요.
  5. 처음 확인할 때는 「규칙」 모드와 「시스템 프록시」를 사용해 브라우저에서 테스트한 다음, 「연결」 페이지에서 요청을 확인하세요.

수동 업데이트는 실패했지만 기존 설정을 계속 사용할 수 있다면 구독 주소와 업데이트 요청 경로부터 확인하세요. 유일하게 작동하는 설정을 먼저 삭제하지 마세요. 서버가 401 또는 403을 반환하면 권한, 토큰, 서버 접근 제한을 확인하세요. 200 응답도 내용이 정상이라는 뜻은 아니므로 HTML 페이지가 잘못 반환된 것은 아닌지 살펴보세요.

처음 설치하고 구독을 가져오는 전체 과정은 빠른 시작 가이드를 참고하세요. 클라이언트를 바꿀 때는 원본 구독을 다시 가져온 다음 로컬 설정을 별도로 옮기는 것이 좋습니다.

4. 규칙, 전역, 직접 연결 모드 중 무엇을 선택해야 하나요?

일상적으로 사용할 때는 규칙 모드를 선택하세요. 모드는 코어가 트래픽을 어떤 경로로 보낼지 결정하지만, 모든 프로그램의 트래픽이 자동으로 코어에 들어가지는 않습니다. 트래픽이 어디서 유입되는지는 시스템 프록시, TUN, 앱 자체의 프록시 설정에 따라 달라집니다.

모드작동 방식적합한 상황
규칙 Rule설정에 있는 규칙을 순서대로 확인하고 해당 정책 또는 정책 그룹으로 전달일상적인 트래픽 분기, 직접 연결과 프록시 대상 구분
전역 Global코어에 들어온 요청을 전역 정책에서 선택한 출구로 전달규칙에 따른 경로를 확인하기 위한 짧은 테스트
직접 연결 Direct코어에 들어온 요청을 프록시 노드 없이 대상에 직접 연결로컬 네트워크 확인 또는 프록시 출구의 임시 비활성화

전역 모드는 「모든 기기의 트래픽을 가로채는 기능」이 아니며 모든 웹사이트의 속도를 높여 주지도 않습니다. 앱이 시스템 프록시를 사용하지 않고 TUN으로도 가로채지 않는다면 전역 모드로 바꿔도 요청이 클라이언트를 우회할 수 있습니다. 전역 정책에서 DIRECT를 선택한 경우에도 원격 프록시 노드를 거치지 않습니다.

규칙 모드에서는 보통 위에서 아래 순서로 규칙을 확인하고, 일치하는 규칙의 정책을 적용합니다. 대상이 앞쪽의 직접 연결 규칙에 먼저 걸리면 목록 끝의 기본 규칙을 바꿔도 해당 요청에는 영향이 없습니다. 웹사이트의 지역만 보고 추측하지 말고 연결 기록에서 어떤 규칙이 적용됐는지 확인하세요.

5. 시스템 프록시와 TUN 모드는 어떻게 다른가요?

브라우저부터 확인하려면 시스템 프록시를, 더 많은 네트워크 트래픽을 가로채려면 TUN을 사용하세요. 시스템 프록시는 운영체제에 로컬 프록시 주소를 등록하지만, 앱에 따라 이를 따르지 않을 수 있습니다. TUN은 가상 네트워크 인터페이스와 라우팅을 이용해 트래픽을 가로채므로 명시적 프록시를 지원하지 않는 프로그램에 적합합니다. 다만 서비스 권한이 필요하고 기존 네트워크 환경에 영향을 줄 수 있습니다.

필요한 범위부터 단계적으로 활성화하세요

  • 브라우저만 사용: 먼저 시스템 프록시를 켜고 브라우저의 별도 프록시 확장 프로그램은 잠시 꺼서 설정이 서로 덮어쓰지 않도록 하세요.
  • 터미널 도구: 도구가 시스템 설정을 따르는지 확인하거나 HTTP, SOCKS 프록시를 별도로 설정하세요.
  • 게임 및 일부 데스크톱 앱: 프로토콜과 노드 지원 여부를 확인한 뒤 TUN을 고려하세요. 시스템 프록시만으로는 모든 UDP 트래픽 문제를 해결하기 어렵습니다.

Clash Verge Rev의 「설정」에서 「시스템 프록시」와 「TUN 모드」 항목을 확인할 수 있습니다. TUN을 사용할 수 없다면 해당 버전의 서비스 모드 설치 및 실행 상태를 점검하세요. 운영체제마다 권한 처리 방식이 다르므로 항상 관리자 권한으로 실행하는 것을 유일한 해결책으로 삼지 마세요.

회사 VPN, 다른 프록시 프로그램, 가상 네트워크 어댑터 도구를 함께 사용 중이라면 현재 상태를 기록한 뒤 트래픽을 가로채는 방식 하나만 남겨 테스트하세요. TUN 문제는 라우팅, DNS, 네트워크 대역 충돌과 관련되는 경우가 있어 노드만 반복해서 바꿔도 해결되지 않을 수 있습니다.

6. 노드 지연 시간은 표시되는데 웹페이지가 열리지 않는 이유는 무엇인가요?

지연 시간 테스트는 특정 테스트 요청이 당시 응답을 받았다는 것만 보여 줍니다. 다운로드 속도나 웹사이트 접속 가능 여부를 뜻하지 않으며, 모든 정책 그룹이 해당 노드를 선택했다는 의미도 아닙니다. 노드에 80ms가 표시되더라도 다른 웹사이트에 접속하지 못할 수 있습니다. 이 수치는 판독 방법을 설명하기 위한 예시이지 실제 측정 결과가 아닙니다.

  1. 대상 요청이 어떤 정책 그룹을 사용하는지 확인하세요. 구독을 업데이트하면 그룹 이름이나 선택된 노드가 바뀔 수 있습니다.
  2. 해당 그룹이 최종적으로 어떤 출구를 사용하는지 확인하세요. 그룹을 선택한 뒤 다른 정책 그룹을 한 번 더 참조할 수도 있습니다.
  3. 정상 작동이 확인된 다른 HTTPS 주소로 테스트해 특정 사이트만의 문제인지 전반적인 문제인지 구분하세요.
  4. 「연결」 및 「로그」 페이지에서 요청 결과를 확인하세요. 프록시 페이지의 지연 시간 색상만으로 판단하지 마세요.

지연 시간 테스트가 시간 초과됐다고 해서 노드가 반드시 작동하지 않는 것은 아닙니다. 테스트 주소에 접속할 수 없거나 서버가 해당 대상을 제한했을 수 있고, 테스트 시간 제한이 너무 짧을 수도 있습니다. 실제 웹 요청, 연결 오류, 같은 네트워크에서 다른 노드의 결과를 함께 살펴보세요.

일반 웹페이지는 열리지만 대용량 파일이나 동영상이 계속 실패한다면 노드 품질, 대상 서비스의 제한, 프로토콜 호환성을 추가로 확인하세요. 지연 시간이 가장 짧은 노드만을 기준으로 선택하지 마세요.

7. 「연결됐는데 웹페이지가 열리지 않음」 문제는 어떤 순서로 해결하나요?

먼저 요청이 클라이언트에 들어오는지 확인하고, 그다음 규칙, 노드, DNS를 점검하세요. 화면에 실행 중이라고 표시되는 것은 보통 코어나 트래픽 가로채기 기능이 시작됐다는 뜻일 뿐, 대상 웹사이트까지의 연결이 정상이라는 뜻은 아닙니다.

요청 하나를 정해 다음 6가지를 확인하세요

  1. 로컬 네트워크: 시스템 프록시와 TUN을 잠시 끄고 원래 직접 연결할 수 있는 웹사이트에 접속해 보세요. 기본 인터넷 연결도 되지 않는다면 Wi-Fi, 게이트웨이 또는 네트워크 로그인 페이지부터 확인하세요.
  2. 현재 설정: 구독이 활성화됐는지, 코어에서 설정 로드 오류가 발생하지 않았는지 확인하세요.
  3. 트래픽 유입: 대상 웹페이지를 새로고침하고 「연결」에 해당 도메인이나 대상 IP가 나타나는지 확인하세요. 기록이 없다면 브라우저의 별도 프록시 설정, 시스템 프록시 포트, TUN 라우팅, 우회 목록을 점검하세요.
  4. 규칙 결과: 새 연결에 적용된 규칙과 정책 경로를 확인해 DIRECT가 잘못 선택되거나 REJECT에 걸리지 않았는지 살펴보세요.
  5. 프록시 출구: 같은 정책 그룹에서 노드를 바꾼 뒤 새 요청을 보내세요. 기존 장기 연결은 노드 선택을 바꿔도 바로 전환되지 않을 수 있습니다.
  6. 오류 유형: 로그를 확인해 도메인 조회 실패, 연결 거부, 연결 시간 초과, TLS 오류를 구분한 뒤 각각에 맞게 해결하세요.

문제 해결이 끝나면 규칙 모드로 되돌리세요. 시스템 방화벽을 계속 꺼 두거나 인증서 검증을 건너뛰어 TLS 오류를 숨기지 마세요. TLS 오류가 발생하면 시스템 시간, 인증서 체인, 대상 서비스, HTTPS 검사 소프트웨어 설치 여부를 확인해야 합니다.

8. DNS 문제와 프록시 포트 오류는 어떻게 구분하나요?

DNS는 도메인을 주소로 변환하고, 프록시 포트는 앱의 요청을 받습니다. 둘은 서로 다른 단계에서 작동합니다. 로그에 lookup, no such host 등이 표시되면 먼저 이름 조회를 확인하세요. 로컬 프록시 주소로 연결할 때 거부된다면 포트와 코어의 수신 상태부터 점검하세요.

아래 명령은 HTTP 프록시 주소를 명시해 테스트하는 예시입니다. 7897은 예시 포트이므로 클라이언트의 현재 실행 설정에 있는 HTTP 포트나 혼합 포트로 바꿔야 합니다. 예전 가이드의 7890을 고정 기본값으로 간주하지 마세요.

curl --proxy http://127.0.0.1:7897 --connect-timeout 10 --max-time 20 --head https://example.com/

Windows PowerShell에서는 일부 환경에서 curl이 다른 명령에 연결되는 문제를 피하도록 curl.exe를 사용할 수 있습니다. 예시의 연결 시간 제한은 10초, 전체 시간 제한은 20초입니다. 대상 주소는 테스트 방법을 설명하기 위한 것이므로 실제 문제를 확인할 때는 오류가 발생한 주소로 바꾸세요. HTTP 응답을 받았다면 요청이 애플리케이션 계층까지 진행된 것이지만, 해당 웹사이트의 모든 기능이 정상이라는 뜻은 아닙니다.

  • 로컬 연결이 거부됨: 포트, 수신 주소, 코어 실행 여부, 다른 프로세스의 포트 사용 여부를 확인하세요.
  • 요청이 클라이언트에 들어온 뒤 이름 조회 실패: 실행 중인 DNS 설정과 상위 DNS 서버에 연결할 수 있는지 확인하세요.
  • 브라우저에서만 문제가 발생함: 브라우저 프록시 확장 프로그램, 보안 DNS, 캐시, 앱 자체 설정을 추가로 점검하세요.

Fake-IP는 도메인을 다른 주소에 매핑하는 방식이지 실제 원격 서버 주소가 아닙니다. 활성화 후 조회 결과에 가상 주소가 나타나도 반드시 오류인 것은 아닙니다. DNS를 수정하기 전에 실제 적용 중인 설정을 확인하세요. 시스템 명령 nslookup의 결과가 코어에서 사용하는 조회 경로와 다를 수도 있습니다.

9. 구독을 업데이트하면 노드 선택과 로컬 규칙이 바뀌나요?

원격 구독 내용은 업데이트에 따라 달라질 수 있으므로, 로컬 설정은 오버라이드에 보관하세요. 내려받은 원격 YAML을 직접 수정하면 다음 업데이트에서 변경 사항이 덮어써질 수 있습니다. 노드 선택이 유지되는지는 클라이언트의 저장 방식과 업데이트 전후 정책 그룹 이름 및 노드 이름이 같은지에 따라 달라집니다.

설정을 3개 층으로 나눠 보세요

  • 원격 설정: 서비스 제공업체가 제공하는 노드, 정책 그룹, 규칙 및 관련 설정입니다.
  • 로컬 오버라이드: 구독 설정에 항목을 병합하거나 조정해 개인적인 트래픽 분기 규칙과 매개변수를 저장하는 방식입니다.
  • 실행 설정: 클라이언트가 처리한 뒤 Mihomo에 전달되어 로드되는 최종 설정입니다.

Merge 오버라이드를 사용할 때 모든 목록이 자동으로 추가된다고 가정하지 마세요. 규칙 목록의 병합 방식, 스크립트 처리 순서, 클라이언트의 확장 설정이 최종 결과에 영향을 줄 수 있습니다. 저장한 뒤 실행 설정을 확인하고 실제 요청을 보내 규칙이 적용되는지 검증하세요.

예를 들어 특정 도메인을 직접 연결하려면 DOMAIN,example.com,DIRECT를 작성하는 것만으로는 충분하지 않습니다. 실제 규칙의 순서와 앞쪽 규칙에 먼저 걸리는지도 확인해야 합니다. 처음에는 구독의 기존 규칙을 유지하고, 안정적으로 작동하는 것을 확인한 뒤 고급 사용법을 참고해 로컬 오버라이드를 하나씩 추가하세요.

10. 클라이언트를 종료한 뒤 인터넷이 안 될 때 복구하고 문제를 제대로 전달하는 방법

먼저 로컬 주소를 가리키는 프록시 설정이 남아 있는지 확인하세요. 시스템 프록시가 127.0.0.1의 프록시 포트를 가리키는데 클라이언트 코어가 중지됐다면, 해당 프록시 설정을 따르는 앱은 연결할 수 없습니다.

  1. 클라이언트를 다시 실행해 「시스템 프록시」와 「TUN 모드」를 끈 다음 정상적으로 종료하고 인터넷이 복구됐는지 확인하세요.
  2. Windows 11에서는 「설정」→「네트워크 및 인터넷」→「프록시」→「수동 프록시 설정」을 확인하세요. 직접 설정한 로컬 프록시만 정리하고, 회사나 기관에서 관리하는 설정은 함부로 삭제하지 마세요.
  3. macOS에서는 「시스템 설정」→「네트워크」→ 현재 네트워크 서비스 →「세부사항」→「프록시」로 이동해 HTTP, HTTPS, SOCKS 항목을 확인하세요.
  4. 문제가 계속되면 다른 VPN, 브라우저의 별도 프록시 설정, 터미널의 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY 환경 변수를 확인하세요.

TUN이 비정상 종료된 경우에는 시스템 프록시 설정이 남은 문제와 달리 가상 네트워크 어댑터, 라우팅, DNS 상태도 영향을 줄 수 있습니다. 우선 클라이언트에서 트래픽 가로채기와 서비스를 정상적으로 종료하고, 필요하면 네트워크에 다시 연결하세요. 용도를 모르는 상태에서 라우팅이나 가상 네트워크 어댑터를 일괄 삭제하지 마세요.

문의를 보낼 때 다음 최소 진단 정보를 포함하세요

  • 운영체제 버전, 클라이언트 버전, Mihomo 코어 버전
  • 현재 모드, 시스템 프록시와 TUN 활성화 여부, 사용 중인 로컬 포트
  • 문제가 발생한 시각, 대상 도메인, 「연결」에서 확인한 적용 규칙과 정책 경로
  • 문제 발생 시각 전후의 오류 로그, 시도한 조치와 각 조치의 결과

공유 전에 구독 토큰과 기타 계정 정보를 삭제하세요. 노드 화면 전체를 캡처하는 것보다 문제를 재현할 수 있는 과정을 명확히 설명하는 편이 원인 파악에 도움이 됩니다. 초보자가 문제를 확인할 때는 구독 유효성, 설정 적용 여부, 요청 유입 여부, 규칙 적용 여부, 출구 정상 여부 순으로 살펴본 뒤 DNS와 복잡한 트래픽 가로채기 설정을 조정하세요.