오픈 소스 코어 · 모든 플랫폼 클라이언트와 설정 가이드

Clash 지식베이스 · 다운로드 및 설정

Clash 다운로드 가이드 보기

기기에 맞는 클라이언트를 선택하고 구독 가져오기, 규칙 기반 라우팅, 연결 문제 해결 순서로 설정하세요.

오픈 소스 코어 mihomo 한국어 사용 가이드 설정 및 로그 대조
설정 문제 해결 순서

먼저 트래픽 가로채기를 확인한 다음 규칙과 DNS를 점검하세요

연결에 실패하면 단계를 나눠 확인하세요. 노드, 모드, DNS를 한꺼번에 바꾸는 것보다 문제 원인을 추적하기 쉽습니다.

구독 가져오기와 시스템 프록시 설정

노드 선택보다 먼저 설정을 정상적으로 불러오세요. 클라이언트를 설치한 뒤 기존 구독이나 로컬 설정을 가져오고, 설정 목록에 항목이 나타나는지 확인한 다음 현재 사용할 설정으로 지정하세요. 구독 URL은 설정을 가져오는 경로이지 소프트웨어 설치 파일이나 공개 공유 링크가 아닙니다. 가져오기에 실패하면 다운로드 오류, 형식 오류, 코어에서 지원하지 않는 필드를 구분하세요. 오류 메시지를 보존하고, 점검 조건을 바꾸지 않은 채 URL만 반복해서 붙여 넣지 마세요. 스크린샷이나 로그를 공유하기 전에는 구독 URL에 포함된 인증 정보를 가리세요.

화면에 실행 중이라고 표시되어도 앱이 프록시를 사용하는 것은 아닙니다. 설정을 정상적으로 불러온 뒤 시스템 프록시를 켜고, 브라우저에서 새 요청을 보낸 다음 클라이언트 연결 기록을 확인하세요. 일부 터미널, 게임, 자체 네트워크 연결을 구현한 앱은 시스템 프록시 설정을 따르지 않습니다. 웹페이지가 열린다는 이유만으로 모든 트래픽이 가로채졌다고 판단할 수는 없습니다. 먼저 같은 앱에서 같은 대상에 반복해서 연결해 확인하세요. 더 많은 프로그램의 트래픽을 처리해야 한다면 그다음에 TUN 권한과 라우팅 설정을 살펴보세요. 처음 실행할 때 모든 기능을 한꺼번에 켤 필요는 없습니다.

연결을 확인할 때는 경로와 결과를 모두 살펴보세요. 정책 그룹에서 노드를 선택하고 테스트 대상에 접속한 뒤 연결 상세 정보에서 대상 도메인, 적용된 규칙, 실제 출구를 확인하세요. 지연 시간 테스트는 해당 시점에 테스트 주소가 응답한 결과일 뿐, 모든 웹사이트나 UDP 서비스가 정상이라는 뜻은 아닙니다. 노드를 바꿨을 때만 연결된다면 노드 자체를 비교하세요. 로그에 요청이 전혀 없다면 트래픽 가로채기 설정부터 확인하세요. 문제 발생 단계를 먼저 찾고 설정이나 규칙을 바꿀지 결정하세요.

사용자 규칙과 정책 그룹의 역할

규칙은 트래픽이 향할 곳을 정하고, 정책 그룹은 사용할 노드를 정합니다. Rule 모드에서 코어는 설정에 적힌 순서대로 규칙을 확인하고, 보통 처음 일치한 규칙의 동작을 적용합니다. 도메인 접미사, 정확한 도메인, 대상 IP는 서로 다른 조건이므로 아무 위치에나 도메인을 넣는다고 적용되는 것은 아닙니다. Clash 사용자 규칙을 추가할 때는 먼저 대상을 명확히 정하고, 더 구체적인 조건을 포괄적인 조건보다 앞에 배치하세요. 규칙에서 참조하는 정책 그룹 이름이 실제로 존재하는지도 확인해야 합니다. 저장 후 설정을 다시 불러오고 새 연결을 만들어 규칙 적용 결과를 확인하세요.

자동 선택 그룹마다 라우팅 방식이 다릅니다.select는 출구를 직접 선택하고, url-test는 테스트 결과에 따라 노드를 선택합니다. fallback은 설정 순서와 노드 사용 가능 여부를 우선하며, load-balance는 지정한 방식에 따라 연결을 분산합니다. 처음 설정할 때는 수동 선택 그룹 하나를 유지하고, 노드 하나가 정상 동작하는지 확인한 뒤 자동 그룹을 추가하세요. 출구가 자주 바뀐다면 테스트 대상, 간격, 그룹 구성원을 확인하세요. 그룹 이름에 ‘자동’이 있다고 연결이 안정적이라는 뜻은 아닙니다.

구독 업데이트와 로컬 수정 사항은 따로 관리하세요. 다운로드한 설정 파일을 직접 수정하면 다음 업데이트 때 변경 사항이 덮어써질 수 있습니다. 계속 유지할 설정은 클라이언트가 지원하는 오버라이드, 병합 또는 별도 규칙 세트 기능을 사용하세요. 병합 순서는 클라이언트마다 다르므로 모든 인터페이스가 똑같이 동작한다고 가정하면 안 됩니다. 수정 전에 복구할 수 있도록 설정을 내보내고, 조건을 한 번에 한 그룹씩 추가하세요. 구독을 업데이트한 뒤 최종 적용 내용을 확인하고, 여러 구독을 병합할 때는 같은 이름의 정책 그룹과 중복 노드도 점검해 잘못된 대상을 참조하지 않도록 하세요.

DNS, Fake-IP 및 연결 로그

도메인에 접속할 수 없다고 해서 반드시 노드 문제인 것은 아닙니다. 앱에서 요청을 보내 연결이 성립하기까지는 도메인 해석, 규칙 매칭, 출구 선택 과정이 있습니다. 먼저 오류가 DNS 시간 초과인지, 연결 거부인지, 핸드셰이크 실패인지 확인한 다음 로그에 표시된 도메인과 대상 주소를 비교하세요. 브라우저에서 자체 보안 DNS를 사용하면 시스템과 다른 경로로 도메인을 해석할 수 있습니다. 코어의 DNS 설정을 바꾸기 전에는 요청을 실제로 처리하는 주체부터 확인하세요. 시스템 DNS 조회 결과만으로 브라우저 요청이 거치는 전체 경로를 알 수는 없습니다.

Fake-IP는 도메인 매핑 방식이지 실제 출구가 아닙니다. 기능을 켜면 코어가 앱에 예약 주소 대역의 가상 IP를 반환하고, 이후 이 매핑을 이용해 원래 도메인을 찾아 트래픽을 라우팅할 수 있습니다. 도구에 이런 주소가 표시되어도 DNS 오류라고 단정하지 마세요. 실제 IP에 의존하는 로컬 네트워크 서비스는 호환성을 고려해 필터 조건을 설정하고, 모든 도메인을 무조건 제외하지 마세요. DNS 모드를 바꾼 뒤에도 앱이나 시스템에 이전 캐시가 남을 수 있습니다. 기존 연결을 종료하고 관련 캐시를 지운 다음 새 요청의 동작을 비교하세요.

TUN 문제를 확인할 때는 라우팅과 권한을 함께 살펴보세요. 가상 네트워크 어댑터는 더 많은 트래픽을 처리할 수 있게 하지만 권한, DNS 가로채기, 라우팅 충돌 등의 변수를 추가합니다. 기능을 켠 뒤 로컬 네트워크 기기에 연결할 수 없다면 우회 라우팅 설정과 다른 VPN 소프트웨어를 먼저 확인하고, 기본 경로가 예상대로 설정되어 있는지 점검하세요. 정상 작동하는 시스템 프록시 설정을 비교 기준으로 유지하고 네트워크 스택과 규칙 세트를 동시에 바꾸지 마세요. 점검이 끝나면 로그 수준을 평소 설정으로 되돌리고, 로그를 공유할 때는 필요한 부분만 남겨 구독 정보, 컨트롤 인터페이스 인증 정보, 개인 접속 기록을 숨기세요.

설정 조각과 클라이언트 화면 이해하기

config.yaml에서 규칙 적용 위치 확인

아래 예시는 로컬 혼합 포트, 수동 정책 그룹, 규칙 순서만 보여줍니다. 예시 그룹에는 기본 제공되는 직접 연결 동작만 포함되어 있으며 프록시 노드는 없습니다. 따라서 인터넷에 연결할 수 있는 완전한 프록시 설정이 아닙니다. 실제로 사용하려면 기존 노드나 구독 프로바이더를 정책 그룹에 연결하고, 각 규칙에서 참조하는 이름이 그룹 이름과 일치하는지 확인해야 합니다.

config.yaml · 구조 예시
  • Profiles
  • Proxies
  • Rules
  • Logs
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxy-groups:
  - name: 수동 선택
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,수동 선택
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,수동 선택

먼저 일치한 규칙이
경로를 결정합니다

클라이언트 다운로드

운영체제와 CPU 아키텍처에 맞게 선택

먼저 기기 유형을 확인한 다음 클라이언트를 비교하세요. 이미 작동하는 설정이 있다면 마이그레이션 과정에서 구독과 네트워크 설정을 동시에 바꾸지 않도록 원본 파일을 보관하세요.

Windows

Clash Plus, Clash Verge Rev 같은 그래픽 클라이언트부터 살펴볼 수 있습니다. 설치 전에 시스템 설정에서 아키텍처를 확인하고, 실행 후에는 코어 상태와 시스템 프록시를 각각 점검하세요. Clash for Windows 대체 프로그램을 찾는다면 설정 가져오기, 오버라이드 방식, 백그라운드 서비스 권한을 중점적으로 비교하세요. 기존 클라이언트의 설정 폴더를 새 클라이언트에 그대로 덮어쓰지 마세요.

다운로드 Windows 클라이언트

macOS

Clash macOS 다운로드 시에는 Apple Silicon용과 Intel용 설치 파일을 구분해야 합니다. ‘이 Mac에 관하여’에서 칩 정보를 확인하세요. 앱을 처음 실행할 때는 시스템 안내에 따라 권한을 설정하고 기존 네트워크 확장과 충돌하는지 확인하세요. TUN이 필요하다면 해당 클라이언트의 서비스 설치 안내를 살펴보세요. 일반적인 브라우저 접속은 먼저 시스템 프록시로 비교해 볼 수 있습니다.

다운로드 macOS 클라이언트

Android

Clash Android 클라이언트를 선택할 때는 먼저 기기 아키텍처와 앱 호환 범위를 확인한 다음 기존 구독을 가져오세요. 처음 연결할 때는 보통 VPN 연결 생성 권한을 허용해야 하며, 같은 시스템 통신 경로를 사용하는 다른 앱은 먼저 중지해야 할 수 있습니다. 백그라운드로 전환한 뒤 연결이 끊기면 배터리 최적화와 백그라운드 실행 제한을 확인한 다음 노드 문제인지 판단하세요. 앱을 포그라운드에 둔 채 속도 테스트만 반복하지 마세요.

다운로드 Android 클라이언트

iOS

다운로드 페이지에서 Clash Plus의 App Store 링크와 공식 웹사이트 clashplus.io를 확인할 수 있습니다. 설치 후 앱 안내에 따라 설정을 가져오고 VPN 연결을 허용하세요. 클라이언트마다 지원하는 필드가 다를 수 있으므로 데스크톱 설정을 휴대폰으로 옮길 때는 가져오기 안내와 실행 로그를 먼저 확인해야 합니다. 스크립트, 오버라이드, 특수 규칙은 그대로 적용된다고 가정하지 말고 하나씩 확인하세요.

다운로드 iOS 클라이언트

Linux

데스크톱에서는 Clash Verge Rev와 FlClash를 비교하고 배포판에 맞는 패키지를 선택할 수 있습니다. 명령줄 프로그램은 데스크톱 환경의 시스템 프록시를 사용하지 않을 수 있으므로 환경 변수나 앱 매개변수를 별도로 확인하세요. 서버나 라우터 사용자는 다운로드 페이지의 코어 항목을 참고하고 서비스 관리, 파일 권한, 수신 범위를 별도로 설정하세요. 데스크톱 설치 절차를 원격 호스트에 그대로 적용하지 마세요.

다운로드 Linux 클라이언트

모든 클라이언트 보기 →

Linux 펭귄 그래픽: Font Awesome Tux, CC BY 4.0. 인라인 벡터만 사용.

오픈 소스 프로젝트와 문서 참고 자료

클라이언트, 코어, 구독 출처 구분하기

이 사이트는 다운로드 링크와 문제 해결 노트를 정리하며 모든 클라이언트의 개발자를 대표하지 않습니다. 소프트웨어 기능은 사용하는 프로젝트의 문서와 실제 실행 결과를 기준으로 확인하세요.

Clash 생태계와 mihomo의 관계

Clash는 규칙 기반 프록시 생태계에서 널리 쓰이는 이름이며, 기존 가이드에는 오리지널 Clash, Clash Meta, mihomo가 함께 등장할 수 있습니다. mihomo는 Clash Meta의 기술 노선을 이어받아 프록시 프로토콜, 정책 그룹, 규칙 매칭, DNS 등의 코어 기능을 제공합니다. 클라이언트는 여기에 그래픽 인터페이스, 구독 관리, 시스템 프록시 전환, 서비스 관리 기능을 더합니다. 이름이 비슷해도 앱의 외관만 보고 설정 호환성을 판단하지 말고 실제 사용하는 코어를 먼저 확인하세요.

오래된 가이드에 나오는 필드나 화면 명칭은 현재 클라이언트에서 지원되지 않을 수 있습니다. 알 수 없는 필드, 미지원 프로토콜, 설정 불러오기 오류가 발생하면 클라이언트 이름과 코어 정보, 원본 오류 메시지를 기록한 뒤 프로젝트 문서와 대조하세요. 오래된 설정을 복사해 저장할 수 있다고 해서 코어가 모든 항목을 적용하는 것은 아닙니다. 최종적으로는 설정을 불러온 결과와 실제 연결 동작을 함께 확인해야 합니다.

오픈 소스 코드로 근거 확인하기

오픈 소스 저장소에서 라이선스, 설정 구현, 이슈 논의, 릴리스 정보를 확인할 수 있습니다. 아래 명령은 mihomo 프로젝트의 공개 저장소를 가리키며, 소스 코드를 읽거나 특정 동작을 추적하려는 사용자에게 유용합니다. 그래픽 클라이언트를 일상적으로 사용하는 데 코어를 직접 빌드할 필요는 없습니다. 동작이 바뀐 이유를 확인할 때는 설정 전체를 처음부터 교체하기보다 릴리스 정보와 관련 이슈를 먼저 읽는 편이 영향 범위를 파악하기 쉽습니다.

코어가 오픈 소스라고 해서 주변 서비스까지 모두 같은 프로젝트에서 제공하는 것은 아닙니다. 노드 연결 품질, 구독 내용, 계정 상태는 해당 서비스 제공처에 따라 달라지며 클라이언트가 작동하지 않는 노드를 복구해 줄 수는 없습니다. 문제를 제출하기 전에 최소 설정으로 재현하고 시스템 환경과 수행한 작업을 설명하세요. 개인 인증 정보와 관련 없는 규칙은 제거해야 코어 결함, 클라이언트 통합 차이, 구독 자체의 문제를 구분할 수 있습니다.

업데이트 전후 되돌릴 수 있는 상태 유지

클라이언트, 코어, 구독은 각각 업데이트할 수 있으며 항상 동시에 바뀌는 것은 아닙니다. 업그레이드 전에 설정과 로컬 오버라이드를 내보내고, 현재 정상 작동하는 프록시 모드와 DNS 설정을 기록하세요. 업그레이드 후에는 같은 대상을 테스트하고 시스템 프록시, TUN 권한, 규칙 세트 로드, 구독 갱신이 예상대로 작동하는지 확인한 다음 자동 업데이트나 복잡한 정책을 다시 활성화하세요. 문제가 재발하면 반복해서 재설치하기보다 업데이트 전후의 차이를 보존하는 편이 원인을 찾는 데 도움이 됩니다.

연결 로그는 요청 과정을 기록할 뿐, 장애 원인을 완전히 판정해 주지는 않습니다. 시간 초과는 DNS 해석, 출구 연결, 대상 응답 단계 어디서든 발생할 수 있으며 같은 오류 메시지도 주변 상황과 함께 해석해야 합니다. 이 사이트의 안내는 ‘작업, 현상, 확인’ 순서로 구성해 설정을 바꾼 결과를 관찰할 수 있도록 했습니다. 안내되지 않은 문제가 발생하면 먼저 자주 묻는 질문을 확인하고, 입문 가이드에 따라 최소 연결 경로부터 다시 점검하세요.

기술 노트

프록시 트래픽 처리와 정책 그룹 문제 해결 기록

문제에 맞는 글을 골라 읽고, 먼저 트래픽이 코어로 들어오는지 확인한 다음 라우팅 방식을 살펴보세요.

모든 글 보기 →