#Clash 자주 묻는 질문: 구독, 노드와 시스템 프록시 문제 해결

Clash는 규칙 기반 프록시 도구 생태계로, YAML 설정 파일로 노드, 정책 그룹, 분기 규칙을 정의하는 것이 핵심입니다. 오리지널 Clash 코어의 업데이트가 중단된 후 커뮤니티 포크인 Clash Meta가 개발을 이어가며 mihomo로 이름을 바꿨고, 현재 주요 클라이언트(Clash Plus, Clash Verge Rev, FlClash 등)는 모두 mihomo 코어를 내장하며 설정 형식은 하위 호환됩니다.

코어(mihomo)는 실제 트래픽 전달과 규칙 매칭을 수행하는 커맨드라인 프로그램이고, 클라이언트는 코어를 감싸는 그래픽 인터페이스로 구독 관리, 노드 전환, 시스템 프록시 켜기/끄기 등의 조작 창구를 제공합니다. 일반 사용자는 클라이언트 하나만 설치하면 되며, 코어는 클라이언트에 내장되어 버전과 함께 업데이트되므로 서버나 라우터에 배포하는 경우가 아니라면 따로 다운로드할 필요가 없습니다.

이 사이트에 소개된 클라이언트는 모두 오픈소스 프로젝트 또는 무료로 배포되는 소프트웨어로, 다운로드와 사용에 비용이 들지 않습니다. 비용이 드는 것은 보통 프록시 구독 서비스, 즉 노드 서비스 자체이며 클라이언트와는 무관합니다. 「Clash 활성화 코드」나 「클라이언트 멤버십」 명목으로 요금을 받는 채널은 오픈소스 커뮤니티와 관련이 없으니, 공식 배포 페이지나 이 사이트의 다운로드 페이지에서만 설치 파일을 받는 것을 권장합니다.

프록시 구독 서비스는 프록시 노드를 제공하는 제3자 업체이며, 구독은 하나의 URL로 클라이언트가 이 URL에서 주기적으로 노드 목록과 분기 규칙을 가져옵니다. 이 사이트는 클라이언트 다운로드와 설정 문서만 제공하며 어떤 노드 서비스도 운영하거나 추천하지 않습니다. 구독 주소는 본인이 이용하는 서비스 제공업체의 사용자 센터에서 직접 받아야 합니다.

규칙 모드는 설정 파일의 분기 규칙을 하나씩 매칭해 해당하는 규칙으로 트래픽을 보내는 일상적으로 권장되는 모드입니다. 전역 모드는 모든 트래픽을 선택한 프록시 노드로 보내며 규칙이 제대로 동작하지 않을 때 임시로 점검하기 적합합니다. 다이렉트 모드는 모든 트래픽이 프록시를 거치지 않도록 해 분기 기능을 임시로 끄는 것과 같습니다. 모드를 전환해도 이미 연결된 세션은 즉시 바뀌지 않으므로 필요하면 연결 페이지에서 수동으로 끊어야 합니다.

가장 먼저 추천하는 것은 x64 설치 파일을 제공하고 인터페이스가 완성도 있으며 업데이트가 활발한 Clash Plus이며, Clash Verge Rev와 FlClash도 자주 쓰이는 선택지입니다. Clash for Windows는 유지보수가 중단되어 보관용으로만 남아 있으므로 신규 사용자에게는 권장하지 않습니다. 구체적인 차이는 클라이언트 비교 페이지에서 확인할 수 있고, 다운로드 링크는 클라이언트 받기 페이지의 Windows 탭에 있습니다.

이는 공증되지 않은 앱에 대한 Gatekeeper의 기본 차단입니다. 「시스템 설정 → 개인정보 보호 및 보안」 페이지 하단에서 차단된 앱을 찾아 「그래도 열기」를 클릭하면 됩니다. 손상되었다는 메시지가 뜨면 터미널에서 xattr -dr com.apple.quarantine 뒤에 앱 경로를 붙여 실행해 격리 속성을 제거한 뒤 다시 열어보세요. Intel과 Apple Silicon 버전을 구분해야 하며, 아키텍처를 잘못 받으면 실행이 실패할 수 있습니다.

Clash Plus 또는 Clash Meta for Android를 예로 들면, 설정(Profiles) 페이지에 들어가 새로 만들기를 누르고 URL 유형을 선택한 뒤 프록시 구독 서비스가 제공한 구독 주소를 붙여넣고 저장하면 클라이언트가 자동으로 설정을 다운로드합니다. 홈 화면으로 돌아가 해당 설정을 선택하고 시작 버튼을 누르면 첫 실행 시 VPN 연결을 위한 시스템 권한 요청이 뜨는데, 동의하면 트래픽을 인계받습니다.

iOS용 Clash Plus는 App Store를 통해 배포되며, 다운로드 페이지의 iOS 탭에서 스토어 상세 페이지로 바로 이동할 수 있고, 공식 사이트 clashplus.io에서 버전 정보를 확인할 수도 있습니다. 설치 후에도 설정 페이지에서 구독 주소를 붙여넣어 가져오면 되며, 첫 연결 시 시스템에서 뜨는 VPN 설정 요청에 동의하면 됩니다.

데스크톱 클라이언트는 보통 설정에서 부팅 시 자동 시작 스위치를 제공합니다. Windows에서는 시작 항목으로 등록되고, macOS에서는 로그인 항목에 추가됩니다. 「자동 연결/마지막 상태 복원」을 함께 체크하면 재시작 후 조용히 프록시를 복원할 수 있습니다. TUN 모드를 사용할 때 Windows 클라이언트는 보통 관리자 권한의 서비스 모드로 실행해야 하며, 그렇지 않으면 자동 시작 후 TUN이 만들어지지 않습니다.

각 클라이언트의 프록시 페이지에는 지연 시간 테스트 버튼이 있으며, 테스트 URL(기본값은 대부분 Google의 generate_204)에 요청을 보내 소요 시간을 기록하는 방식입니다. 이 값은 현재 네트워크와 노드 사이의 핸드셰이크 지연만을 나타낼 뿐 대역폭과는 무관하므로, 노드를 고를 때는 여러 번 측정하고 실제 사용 환경에서 안정성을 함께 살펴보는 것이 좋습니다. 정책 그룹에서 url-test 유형을 사용하면 코어가 지연이 가장 낮은 노드를 자동으로 선택하게 할 수도 있습니다.

정책 그룹은 여러 노드나 하위 정책 그룹을 하나의 선택 가능한 단위로 묶은 것으로, 분기 규칙은 특정 노드가 아니라 정책 그룹을 가리킵니다. 흔한 유형으로는 select(수동 선택), url-test(지연 최저 자동 선택), fallback(장애 조치)이 있습니다. 일상적인 사용법은 클라이언트의 프록시 페이지에서 용도별 정책 그룹(예: 해외 트래픽, 스트리밍, AI 서비스)에 각각 노드를 지정하는 것으로, 규칙을 하나씩 고칠 필요가 없습니다.

시스템 프록시는 프록시 설정을 따르는 앱만 커버할 수 있으며, 커맨드라인 도구나 일부 게임, 클라이언트는 시스템 프록시를 따르지 않습니다. TUN 모드는 가상 네트워크 카드를 통해 네트워크 계층에서 모든 트래픽을 인계받아 커버 범위가 더 완전합니다. 대신 더 높은 권한이 필요한데, Windows는 관리자 또는 서비스 모드가, macOS는 시스템 확장 승인이나 비밀번호 입력이 필요하며, Android와 iOS의 VPN 모드는 그 자체로 동일한 메커니즘이라 추가 설정이 필요 없습니다.

컴퓨터 클라이언트 설정에서 LAN 연결 허용(allow-lan)을 켜고 혼합 포트(mixed-port, 흔히 7890)를 확인한 뒤 방화벽에서 해당 포트를 허용했는지 확인합니다. 그런 다음 휴대폰이나 TV의 Wi-Fi 고급 설정에서 프록시를 수동으로 입력하고, 서버에는 컴퓨터의 LAN IP를, 포트에는 혼합 포트를 입력하면 됩니다. 두 기기는 같은 LAN에 있어야 합니다.

가능합니다. 대부분의 클라이언트는 설정 파일 항목에서 자동 업데이트 간격을 제공하며 흔히 1440분, 즉 하루에 한 번으로 설정합니다. 기한이 되면 클라이언트가 백그라운드에서 구독 URL을 다시 가져와 즉시 반영합니다. 프록시 구독 서비스의 규칙이 자주 바뀐다면 간격을 좀 더 줄이면 되고, 업데이트가 실패해도 클라이언트는 기존 설정을 유지하므로 인터넷 연결이 끊기지 않습니다.

순서대로 확인하세요. 첫째, 구독 주소가 완전한지, 공백이 섞여 있거나 입력기에 의해 잘리지 않았는지 확인합니다. 둘째, 구독 자체가 만료되었는지 브라우저에서 해당 URL을 직접 열어 내용이 반환되는지 확인합니다. 셋째, 업데이트가 프록시를 거쳤는지 확인합니다 — 구독 도메인이 오염되었다면 클라이언트에서 「프록시로 업데이트」를 켜거나 반대로 꺼서 다시 시도해 보세요. 넷째, 네트워크 환경을 바꿔(예: 휴대폰 테더링) 다시 업데이트해 보면 로컬 네트워크 문제와 구독 서비스 문제를 구분할 수 있습니다.

먼저 로컬 네트워크가 정상인지, 즉 다이렉트 모드에서 웹페이지가 열리는지 확인합니다. 다음으로 시스템 시간이 정확한지 확인하세요. 일부 프로토콜은 시간 오차에 민감합니다. 그런 다음 클라이언트 로그에서 구체적인 오류를 확인합니다 — DNS 해석 실패는 보통 로컬 DNS가 오염된 경우이므로 설정에서 암호화 DNS를 활성화할 수 있습니다. 특정 포트대의 노드만 시간 초과된다면 통신사가 해당 포트대를 차단했을 가능성이 있으니 서비스 제공업체에 연락해 포트나 노드를 교체하세요.

두 가지 경우로 나뉩니다. 브라우저가 프록시를 타지 않는 경우: 클라이언트의 시스템 프록시 스위치가 켜져 있는지, 브라우저에 자체적으로 프록시를 관리하는 확장 프로그램이 설치되어 시스템 설정을 덮어쓰고 있는지 확인하세요. 커맨드라인 도구가 프록시를 타지 않는 경우: 터미널은 기본적으로 시스템 프록시를 읽지 않으므로 http_proxy와 https_proxy 환경 변수를 수동으로 혼합 포트로 지정해야 하며, 아니면 TUN 모드로 바꿔 네트워크 계층에서 직접 인계받는 방법도 있습니다.

Windows는 보안 정책상 기본적으로 UWP 앱이 로컬 루프백 주소에 접근하지 못하도록 막고 있어, 127.0.0.1에 있는 프록시 포트에 연결할 수 없습니다. 해결 방법: 클라이언트에 내장된 UWP 루프백 예외 도구(EnableLoopback 메커니즘 기반)를 사용해 대상 앱을 체크해서 허용하거나, 아예 TUN 모드를 켜서 루프백 제한을 우회하면 됩니다.

대부분 포트 충돌이나 잔존 설정 문제입니다. 첫째, 혼합 포트가 다른 소프트웨어에 점유되어 있는지 확인하고 포트를 바꿔 다시 시도하세요. 둘째, 이전에 비정상 종료된 적이 있다면 시스템 프록시에 무효한 127.0.0.1 설정이 남아 있을 수 있으니, 시스템 네트워크 설정에서 수동으로 프록시를 끄고 클라이언트에서 다시 켜보세요. 셋째, 여러 프록시 소프트웨어를 동시에 실행하면 시스템 프록시를 서로 빼앗으므로 하나만 남기세요. 넷째, 실패한 노드를 잘못 선택했는지 확인하고 사용 가능한 노드나 규칙 모드로 바꿔 확인하세요.