OPEN SOURCE · CLIENT AND CONFIGURATION
기기에 맞는 유지 관리가 쉬운 Clash 클라이언트를 선택하고 규칙 기반 라우팅, 프록시 그룹 및 한국어 설정 문서를 활용해 구독 가져오기, 시스템 프록시 설정과 연결 문제를 해결하세요.
PLATFORM CONNECTORS
먼저 기기의 운영체제를 확인한 뒤 다운로드 페이지에서 프로세서 아키텍처, 클라이언트 유지 관리 상태와 설치 패키지 유형을 확인하세요. 홈페이지의 링크는 플랫폼을 찾는 용도이며 설치 파일을 직접 제공하지 않습니다.
데스크톱에서 일상적으로 사용하기 좋습니다. 다운로드 페이지에서는 Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu와 기존 설정 이전을 위한 Clash for Windows 보관 버전을 제공합니다. 설치 전 시스템 설정에서 Windows 버전과 프로세서 아키텍처를 확인하세요. 일반 사용자는 그래픽 인터페이스를 제공하고 현재 유지 관리되며 Mihomo를 지원하는 클라이언트를 우선 선택하는 것이 좋습니다.
다운로드할 때 Intel과 Apple Silicon을 구분해야 합니다. 그래픽 클라이언트에서는 시스템 프록시, 규칙 모드와 구독 업데이트를 관리할 수 있으며, 처음 실행할 때는 시스템 안내에 따라 앱 권한을 허용해야 합니다. 구버전 ClashX Meta는 기존 작업 환경 이전 용도로만 사용하고, 새로 설치할 때는 현재 유지 관리되는 클라이언트를 우선 확인하세요.
스마트폰과 태블릿에 적합합니다. 설치 패키지는 일반적으로 ARM64, ARM 또는 범용 아키텍처로 구분되며 최근 주류 기기는 대부분 ARM64를 사용합니다. 구독을 가져온 뒤에는 클라이언트가 로컬 VPN 인터페이스를 만들도록 허용해야 합니다. 배터리 절전 정책으로 백그라운드 연결이 중단될 수 있으므로 계속 사용하려면 시스템의 배터리 최적화 설정을 확인하세요.
App Store에서 Clash Plus를 설치하고 시스템이 제공하는 VPN 구성 기능으로 프록시가 필요한 연결을 처리하세요. 설정을 가져오기 전에 구독 내용을 신뢰할 수 있는지 확인해야 합니다. 같은 설정을 여러 기기에서 사용한다면 기기별로 가져온 후 프록시 그룹 선택을 독립적으로 확인하여 현재 네트워크에 맞지 않는 노드를 그대로 사용하지 않도록 하세요.
데스크톱 환경에서는 Clash Verge Rev 또는 FlClash를 선택할 수 있고, 서버·소프트웨어 라우터·컨테이너 환경에서는 대개 Mihomo 커널을 직접 실행합니다. 커널을 사용할 때는 설정 경로, 서비스 데몬, 파일 권한과 제어 포트를 직접 관리해야 하므로 Clash를 처음 접하는 사용자는 그래픽 클라이언트부터 시작하는 편이 좋습니다.
CONFIGURATION BUS
설정은 서로 무관한 스위치의 모음이 아닙니다. 연결은 먼저 네트워크 인터페이스로 들어간 뒤 도메인 확인, 규칙 매칭과 프록시 그룹 선택을 거치고, 마지막으로 선택한 출구를 통해 처리됩니다. 아래에서는 이 다섯 가지 구조를 역할별로 나누어 설명합니다.
규칙 엔진은 도메인, IP, 프로세스 또는 규칙 집합을 기준으로 연결이 어느 프록시 그룹으로 들어갈지 판단합니다. 설정의 규칙은 위에서 아래로 매칭되며, 일치하면 보통 이후 규칙을 확인하지 않습니다. 따라서 구체적인 도메인 규칙은 포괄적인 규칙보다 앞에 배치해야 하고, MATCH는 앞에서 일치하지 않은 연결을 처리하는 데 사용합니다. 라우팅 오류를 점검할 때는 먼저 현재 모드가 규칙 모드인지 확인한 다음 규칙 순서, 규칙 집합 로딩 상태와 최종 지정된 프록시 그룹 이름을 확인하세요.
전역 스위치만 제공하는 프록시 도구와 달리 Clash의 규칙 체인에서는 직접 연결, 프록시와 차단 동작을 하나의 설정에 함께 정의할 수 있습니다. 규칙 자체가 특정 노드를 결정하는 것은 아니며 트래픽을 프록시 그룹으로 넘기는 역할만 합니다. 이러한 계층 구조 덕분에 규칙 집합은 장기간 재사용하고 출구 노드는 네트워크 상태에 따라 별도로 전환할 수 있습니다.
rules:
- DOMAIN-SUFFIX,example.cn,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXY프록시 그룹은 규칙과 노드 사이에 있습니다. select는 출구를 수동으로 지정할 때 적합하고, url-test는 테스트 결과에 따라 자동으로 선택하며, fallback은 순서대로 사용 가능 여부를 확인합니다. load-balance는 여러 출구에 트래픽을 분배할 때 사용합니다. 실제 설정에서는 안정성 요구에 따라 그룹 유형을 선택해야 하며, 이름이 비슷하다는 이유만으로 서로 바꿔 사용할 수 없습니다. 자동 테스트 주소, 테스트 간격과 시간 초과 설정도 전환 결과에 영향을 줍니다.
업무 규칙에서는 특정 노드 이름을 직접 지정하기보다 안정적인 프록시 그룹 이름을 참조하는 것이 좋습니다. 구독 업데이트로 노드가 추가되거나 삭제되어도 그룹 구성원만 조정하면 되므로 전체 규칙을 다시 작성할 필요가 없습니다. 여러 구독을 병합할 때는 중복 노드 이름을 피하고, 프록시 그룹이 참조하는 제공자가 로딩을 완료했는지도 확인하세요.
proxy-groups:
- name: PROXY
type: select
proxies:
- AUTO
- DIRECTDNS 설정은 도메인을 어떻게 확인할지, 어느 서버로 질의할지, 그리고 확인 결과를 규칙 엔진과 어떻게 연동할지를 결정합니다. Fake-IP를 사용하면 클라이언트가 먼저 예약 주소를 반환하고 도메인 매핑을 저장하므로 이후 연결에서도 도메인 규칙을 적용할 수 있습니다. Redir-Host는 기존 DNS 확인 방식에 더 가깝습니다. 웹사이트의 도메인 확인에 문제가 생기면 시스템 DNS가 가로채졌는지, 상위 DNS 주소에 연결할 수 있는지, 향상된 모드가 현재 네트워크에 맞는지, 필터 목록에 로컬 네트워크 도메인이 포함되어 있는지를 순서대로 확인하세요.
DNS 유출, 오염과 질의 루프는 여러 소프트웨어가 동시에 DNS를 처리하면서 발생하는 경우가 많습니다. 설정할 때 시스템, 클라이언트 또는 라우터 중 어디에서 초기 DNS 질의를 담당할지 명확히 정하고, 프록시를 통해 접속해야 하는 DNS 상위 서버를 실수로 직접 연결 경로에 넘기지 않도록 하세요.
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
- 1.1.1.1TUN 모드는 가상 네트워크 인터페이스를 만들어 시스템 프록시 설정을 읽지 않는 앱도 Clash 처리 체인으로 보냅니다. 명령줄 도구, 일부 게임 런처와 독립 네트워크 스택을 사용하는 소프트웨어에 유용하지만 라우팅, DNS와 권한 설정이 복잡해집니다. 데스크톱에서 활성화하기 전에 클라이언트에 필요한 권한이 있는지 확인하고, 다른 VPN·보안 소프트웨어 또는 가상 네트워크 카드가 같은 라우팅을 사용하고 있지 않은지도 점검하세요.
TUN을 켠 뒤 인터넷이 완전히 끊겼다면 노드를 계속 바꿔서는 안 됩니다. 먼저 TUN을 끄고 기본 상태를 복구한 뒤 스택 유형, 자동 라우팅, DNS 하이재킹과 방화벽 규칙을 확인하는 것이 효과적입니다. 시스템 프록시는 정상인데 특정 앱만 프록시를 거치지 않을 때에만 TUN이 필요한지 추가로 판단하세요.
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true외부 제어 인터페이스는 데스크톱 클라이언트나 제어판에서 프록시 그룹, 연결과 로그를 읽고 정책을 전환하는 데 사용됩니다. 인터페이스는 보통 로컬 주소에서만 수신하면 됩니다. LAN으로 확장할 경우 접근 키와 방화벽 범위도 함께 설정해야 합니다. 제어판은 관리 진입점일 뿐 실제 트래픽은 Clash 또는 Mihomo 커널이 처리합니다. 따라서 제어판이 열리지 않는 문제와 프록시 체인이 작동하지 않는 문제는 서로 다르므로 정적 페이지, 제어 포트와 커널 프로세스를 각각 확인해야 합니다.
원격 관리 시 제어 포트를 직접 외부에 노출해서는 안 됩니다. 제어된 네트워크와 리버스 프록시를 통해 제어판에 접근하고, 인터페이스에 도달할 수 있는 출처를 제한하는 방식이 더 안전합니다. 제어 주소를 변경한 뒤에는 클라이언트 제어판의 연결 매개변수도 함께 업데이트하세요.
external-controller: 127.0.0.1:9090
secret: "your-password"OPEN SOURCE TRACE
Clash 관련 클라이언트, 커널과 설정 형식은 여러 프로젝트가 함께 구성합니다. 특정 클라이언트 이름만 기억하기보다 각 계층의 역할을 파악하는 것이 이후 이전과 문제 해결에 더 도움이 됩니다.
Clash는 규칙 기반 프록시 모델을 바탕으로 설정의 기초를 마련했습니다. 수신 포트, 프록시 노드, 프록시 그룹, 규칙과 DNS가 함께 처리 체인을 구성합니다. 원 프로젝트의 유지 관리 상태가 변한 뒤에도 커뮤니티의 클라이언트와 호환 커널은 계속 발전했습니다. 현재 클라이언트를 선택할 때는 이름에 Clash가 포함되었는지만으로 사용 가능 여부를 판단하지 말고 유지 관리 상태, 커널 유형, 운영체제 지원과 설정 호환 범위를 함께 확인해야 합니다.
Clash for Windows 같은 기존 클라이언트가 오래된 튜토리얼이나 기존 기기에 여전히 등장할 수 있지만, 유지 관리가 중단된 소프트웨어는 새 설치의 기본 선택으로 적합하지 않습니다. 이전할 때는 먼저 기존 설정을 내보내거나 저장한 다음 새 클라이언트가 지원하는 구독 형식, 스크립트 기능과 오버라이드 방식을 확인하세요. 클라이언트 전용 필드를 범용 커널 필드로 잘못 사용하지 않도록 주의해야 합니다.
그래픽 클라이언트는 설치 경험, 구독 관리, 시스템 프록시 전환, 로그 표시와 프록시 그룹 조작을 담당합니다. Mihomo 같은 호환 커널은 설정을 해석하고 수신 포트를 열며 규칙을 실행합니다. 구독 서비스는 노드와 정책 내용을 제공합니다. 세 계층은 조합할 수 있지만 장애가 발생하는 위치는 서로 다릅니다. 클라이언트 화면이 열린다고 해서 커널이 실행 중이라는 뜻은 아니며, 커널이 정상적으로 실행되어도 구독의 노드가 현재 사용 가능하다는 보장은 없습니다.
문제를 찾을 때는 계층별로 확인해야 합니다. 먼저 로컬 네트워크와 시스템 시간을 확인하고, 다음으로 구독 응답과 설정 해석 상태를 확인한 뒤 커널 로그, 프록시 모드, 정책 선택, DNS와 시스템 방화벽을 점검하세요. 계층별 점검을 하면 노드를 사용할 수 없을 때 클라이언트를 반복해서 재설치하는 일을 피할 수 있고, 설정 문법 오류를 시스템 네트워크 장애로 오해하는 것도 막을 수 있습니다.
Mihomo는 Clash의 설정 방식을 이어받으면서 규칙 제공자, 프록시 제공자, DNS, TUN, 트래픽 스니핑과 제어 인터페이스 등의 기능을 확장합니다. 대부분의 최신 그래픽 클라이언트는 커널 다운로드와 실행 과정을 감싸서 제공하므로 일반 사용자는 바이너리 파일을 직접 실행할 필요가 없습니다. 서버, 라우터와 컨테이너 사용자는 설정 디렉터리, 실행 권한, 서비스 데몬과 로그 순환을 직접 관리해야 합니다.
설정 이전은 YAML을 해석할 수 있는지만 확인해서는 충분하지 않습니다. 일부 필드는 특정 커널 버전이나 클라이언트 오버라이드 로직에 의존하며, 같은 구독도 클라이언트에 따라 기본 DNS, TUN 스택과 시스템 프록시 동작이 다를 수 있습니다. 이전 후에는 직접 연결 사이트, 프록시 사이트, 도메인 확인과 앱 종료 후 시스템 프록시 복구 상태를 각각 검증하세요.
클라이언트 업데이트, 커널 업데이트와 구독 업데이트는 해결하는 문제가 서로 다릅니다. 클라이언트 업그레이드는 보통 인터페이스, 시스템 통합과 커널 관리 방식을 바꾸고, 커널 업그레이드는 설정 필드를 추가하거나 네트워크 동작을 수정할 수 있습니다. 구독 업데이트는 노드, 프록시 그룹과 규칙 내용을 변경합니다. 문제가 발생하면 최근에 변경된 계층을 기록한 뒤 설정을 되돌릴지, 노드를 전환할지 또는 클라이언트를 재설치할지 결정하세요.
업데이트 전에 현재 정상 작동하는 설정을 보존하고 시스템 프록시, TUN, DNS와 오버라이드 설정을 기록하세요. 업데이트 후에는 지연 시간 테스트만으로 결과를 판단하지 말고 프록시 그룹이 완전한지, 규칙 제공자가 로딩되었는지, 로그에 해석 오류가 있는지, 브라우저와 시스템 프록시를 읽지 않는 앱이 각각 예상대로 작동하는지 확인하세요.
QUICK DIAGNOSTICS
아래 내용은 문제 해결 순서를 세우기 위한 핵심 결론입니다. 전체 절차가 필요하다면 문제 해결 또는 사용 문서로 이동하세요.
새로 설치할 때는 현재 유지 관리되고 사용 중인 운영체제를 지원하며 호환 커널을 사용하는 클라이언트를 우선 선택하세요. Windows 사용자는 Clash Plus, Clash Verge Rev, FlClash와 Clash Nyanpasu를 먼저 비교할 수 있습니다. 기존 설정을 이전할 때는 구독 주소와 로컬 오버라이드를 먼저 저장한 뒤 시스템 프록시, 프록시 그룹, DNS와 TUN 설정을 하나씩 확인하세요. 자세한 차이는 클라이언트 비교에서 확인할 수 있습니다.
먼저 구독 요청이 성공했는지 확인한 다음 반환된 내용을 현재 클라이언트가 해석할 수 있는지 확인하세요. 로그에 YAML 문법, 필드 유형 또는 프록시 그룹 참조 오류가 표시되면 먼저 설정을 수정해야 합니다. 구독 내용은 정상인데 목록이 갱신되지 않는다면 다시 가져오고 클라이언트가 이전 캐시를 사용하고 있지 않은지 확인하세요. 해석 결과를 확인하기 전에 프록시 모드를 반복해서 바꾸지 마세요.
먼저 시스템 프록시를 끄고 로컬 네트워크 자체가 정상인지 확인한 다음 커널 실행 여부, 노드 연결 가능 여부, 현재 모드와 프록시 그룹이 올바른지 점검하세요. 브라우저에 접속할 수 없다면 DNS도 확인해야 합니다. 특정 앱만 프록시를 거치지 않을 때는 해당 앱이 시스템 프록시를 무시하는지, TUN이 필요한지 판단하세요. 전체 절차는 문제 해결에서 확인할 수 있습니다.
규칙 모드는 설정에 따라 연결별로 직접 연결, 프록시 또는 차단을 결정합니다. 전역 모드는 보통 모든 연결을 하나의 프록시 그룹으로 보내며 노드 경로를 임시로 확인할 때 적합합니다. 직접 연결 모드는 프록시 출구를 건너뛰어 문제가 프록시 체인에서 발생했는지 확인할 수 있습니다. 일상적인 사용에는 규칙 모드를 사용하고, 전역 모드는 규칙 설정을 장기간 대체하기보다 짧은 진단용으로 활용하는 것이 좋습니다.
TECHNICAL NOTES
노드 연결, 구독 해석과 클라이언트 선택을 중심으로 재사용할 수 있는 점검 순서를 정리했습니다. 글의 결론은 설정 계층과 작업 흐름에 초점을 맞추며 재현할 수 없는 성능 수치는 사용하지 않습니다.
로컬 네트워크, 구독 상태, 노드 사용 가능 여부, 프록시 모드, DNS와 시스템 방화벽 순서로 연결 시간 초과의 원인을 찾아 문제가 발생한 계층을 확인하기 전에 클라이언트를 반복 설치하지 않도록 하세요.
전체 글 읽기 →구독 주소 만료, 응답 내용 이상, 설정 형식 오류와 클라이언트 캐시 문제를 구분하고 요청 결과와 커널 로그를 통해 장애가 어느 계층에서 발생했는지 판단하는 방법을 설명합니다.
전체 글 읽기 →플랫폼 지원 범위, 커널 지원, 설정 기능과 유지 관리 상태를 기준으로 주요 클라이언트를 비교하고 데스크톱, 모바일과 서버 환경에 적용할 선택 기준을 설명합니다.
전체 글 읽기 →