Clash 완전 정복 매뉴얼

01핵심 개념: 코어, 클라이언트, 설정 파일

코어와 클라이언트는 서로 다른 두 계층

Clash 생태계는 두 계층으로 이루어져 있습니다. 하위 계층은 코어입니다: 로컬 포트를 감시하고 애플리케이션 트래픽을 받아 규칙에 따라 매칭한 뒤 해당 프록시 서버나 다이렉트 출구로 전달하는 커맨드라인 프로그램입니다. 현재 생태계의 주류 코어는 mihomo(즉 Clash Meta 분기)로, 오리지널 Clash 코어가 아카이브된 뒤에도 계속 유지 관리되며 아웃바운드 프로토콜, 규칙 세트, TUN 스택을 확장했습니다. 자세한 내용은 블로그 《mihomo 코어와 오리지널 Clash의 차이점》을 참고하세요.

상위 계층은 그래픽 클라이언트입니다: Clash Plus, Clash Verge Rev, FlClash처럼 이름은 다양하지만 본질적으로 모두 코어의 "조종석" 역할을 합니다 — 구독 가져오기, 노드 전환, 시스템 프록시와 TUN 켜기/끄기, 로그와 연결 상태 표시를 담당합니다. 이 점을 이해하면 많은 의문이 자연히 풀립니다: 클라이언트마다 다른 기능은 대부분 인터페이스와 패키징 차이일 뿐이고, 실제 분산 능력은 코어가 결정합니다. 클라이언트를 바꾼다고 구독을 바꿀 필요는 없으며, 설정 파일은 코어와 호환되는 어떤 클라이언트에서도 그대로 사용할 수 있습니다.

설정 파일의 세 가지 블록

코어의 모든 동작은 하나의 YAML 설정 파일(보통 config.yaml이라 부르며, 클라이언트에서는 Profile이라고 표시)로 결정됩니다. 파일 길이가 얼마든 골격은 항상 세 블록입니다:

1. 인바운드와 전역 파라미터: 감시 포트, LAN 접속 허용 여부, 실행 모드, 로그 레벨, DNS 설정.
2. proxies와 proxy-groups: 노드 목록(각 노드는 프록시 서버 하나의 주소·포트·프로토콜·인증 정보)과 프록시 그룹(노드를 전략별로 묶어 규칙에서 참조).
3. rules: 각 연결이 어느 프록시 그룹을 통할지 결정하는 분산 규칙 목록.

가장 단순하게 읽을 수 있는 전역 파라미터 블록은 다음과 같습니다:

mixed-port: 7890        # HTTP와 SOCKS5를 통합한 혼합 인바운드 포트
allow-lan: false        # LAN 기기 접속 허용 여부
mode: rule              # rule / global / direct 세 가지 실행 모드
log-level: info         # silent / error / warning / info / debug
external-controller: 127.0.0.1:9090   # 로컬 API 제어 포트

자주 나오는 용어 빠른 정리

02클라이언트 선택: 플랫폼 매트릭스와 절충

먼저 플랫폼, 그다음 취향

클라이언트 선택의 첫 번째 제약은 운영체제입니다. 아래 표는 다운로드 센터의 목록과 동일하며, 각 칸은 추천 순서대로 배열했습니다:

Clash Plus는 전 플랫폼 1순위 추천입니다: 다섯 개 플랫폼에서 인터페이스와 조작 로직이 동일해 기기를 바꿔도 새로 배울 필요가 없고, mihomo 코어가 내장되어 구독 가져오기, TUN, 규칙 분산을 바로 사용할 수 있습니다. Clash Verge Rev는 데스크톱에서 더 세밀한 설정 기능을 제공합니다. 오버라이드 스크립트, 외부 제어, 코어 전환까지 진입점이 있어 문서를 읽을 의지가 있는 사용자에게 적합합니다. FlClash는 Flutter로 만들어져 데스크톱과 Android를 하나의 인터페이스로 아우르며, 극단적으로 단순한 조작을 선호한다면 선택할 만합니다. Clash Nyanpasu는 Windows용 또 다른 Verge 계열 분기로, 화면 스타일은 다르지만 기능 범위는 비슷합니다. Clash Meta for Android는 Android에서 코어의 네이티브 동작에 가장 가까운 클라이언트이며, Surfboard는 Clash 설정 형식과 호환되어 Android용 대안이 됩니다.

03설치: 5개 플랫폼 하나씩 살펴보기

Windows

다운로드 센터 Windows 섹션에서 설치 파일을 받아 더블클릭으로 실행하고, 마법사를 따라 설치 경로를 선택하면 됩니다. 흔히 막히는 두 지점: 첫째, SmartScreen이 "PC가 보호되었습니다"라고 표시하는 것은 새로 배포된 설치 파일에 대한 시스템의 기본 차단이므로 "추가 정보 → 실행"을 눌러 계속 진행하세요. 둘째, 설치 완료 후 창을 못 찾는 경우 — Clash 계열 클라이언트는 실행 후 기본적으로 작업 표시줄 트레이로 들어가므로 트레이의 고양이 아이콘을 클릭해 메인 창을 불러오세요. TUN 모드를 사용할 계획이라면 첫 실행 시 클라이언트가 요청하는 서비스 설치나 관리자 권한 승인을 허용하세요. 7장에서 다시 다룹니다.

macOS

.dmg 이미지를 내려받아 열고, 앱 아이콘을 Applications 폴더로 드래그하세요. 칩 버전을 구분하는 데 주의하세요: Apple Silicon(M 시리즈)과 Intel은 서로 다른 설치 파일을 사용하며 다운로드 페이지에 각각 표시되어 있습니다. 처음 열 때 "개발자를 확인할 수 없음" 메시지가 뜨면 「시스템 설정 → 개인정보 보호 및 보안」 페이지 하단에서 "그래도 열기"를 누르거나, 앱 아이콘을 우클릭해 "열기"를 선택한 뒤 다시 확인하세요. 클라이언트가 보조 서비스 설치(시스템 프록시와 TUN 인수용)를 요청하면 비밀번호를 입력해 허용합니다.

Linux

데스크톱 배포판에는 .deb 패키지를 권장하며, Debian / Ubuntu 계열은 바로 설치할 수 있습니다:

# 파일명은 실제 다운로드한 파일 기준
sudo apt install ./clash-verge-rev_amd64.deb
# 또는 dpkg 사용 후 의존성 보완
sudo dpkg -i ./clash-verge-rev_amd64.deb
sudo apt -f install

설치 후 애플리케이션 메뉴에서 실행하세요. TUN 모드를 사용하려면 코어에 CAP_NET_ADMIN 권한을 부여하거나 서비스 방식으로 실행해야 하며, 클라이언트 설정에는 보통 원클릭 "서비스 모드" 항목이 있습니다. 데스크톱이 없는 서버 환경이라면 GUI를 건너뛰고 mihomo 코어를 직접 사용하세요. 9장에서 다룹니다.

Android

다운로드 센터 Android 섹션에서 APK를 받고, 설치 시 시스템 안내에 따라 "이 소스의 앱 설치"를 허용하세요. 처음 연결을 누르면 시스템이 VPN 연결 요청 대화상자를 표시합니다 — VpnService 메커니즘의 표준 승인 절차로, 확인하면 상태 표시줄에 열쇠 아이콘이 나타나 트래픽이 클라이언트로 들어왔음을 나타냅니다. 배터리 관리가 엄격한 제조사 커스텀 시스템에서는 클라이언트를 절전 화이트리스트와 자동 시작 허용 목록에도 추가하는 것을 권장합니다. 그렇지 않으면 화면을 잠시 잠근 뒤 시스템이 프록시를 회수할 수 있습니다. 자세한 내용은 블로그 《Clash Android 클라이언트 사용 요점》을 참고하세요.

iOS

iOS는 App Store를 통해 Clash Plus를 받으며, 다운로드 페이지 iOS 섹션에 스토어 바로가기와 공식 사이트 clashplus.io 링크가 있습니다. 설치 후 처음 실행하면 마찬가지로 VPN 구성 추가를 요청하며, 「설정 → 일반 → VPN 및 기기 관리」에서 해당 프로필을 확인할 수 있습니다. 구독 가져오기와 노드 전환의 조작 로직은 데스크톱 버전과 동일하며, 이후 장의 개념도 모두 그대로 적용됩니다.

04구독 가져오기와 설정 관리

구독 링크란

구독은 서비스 제공자가 생성하는 HTTPS 주소로, 노드 변경에 따라 실시간으로 갱신되는 완전한 설정 파일을 담고 있습니다. 클라이언트가 "구독 가져오기"를 할 때 하는 일은 다음과 같습니다: 이 주소로 요청 → 반환된 YAML을 하나의 Profile로 저장 → 현재 적용 설정으로 지정. 따라서 구독 링크는 계정 인증 정보와 같으므로 공개된 장소에 붙여넣거나 스크린샷에 그대로 노출하지 마세요.

가져오기와 업데이트

1. 서비스 제공자의 사용자 센터에서 구독 링크를 복사하세요. Clash 또는 mihomo 형식을 선택할 때 주의하세요(일부 패널은 코어에 따라 다른 내용을 출력합니다).
2. 클라이언트의 Profile / 설정 페이지를 열고 링크를 붙여넣은 뒤 가져오기를 누르세요. 목록에 새 항목이 나타나고 트래픽과 만료 시간(패널에서 제공하는 경우)이 표시되면 성공입니다.
3. 해당 항목을 선택해 활성화하세요. 이후 노드 목록, 프록시 그룹, 규칙은 모두 이 설정에서 가져옵니다.
4. 자동 업데이트 간격을 설정하세요(보통 24시간). 서비스 제공자가 노드 주소를 교체한 뒤 로컬에서 업데이트하지 않으면 "전부 타임아웃"이 발생합니다.

로컬 설정과 다중 Profile 관리

구독 외에도 클라이언트는 빈 Profile을 새로 만들거나 로컬 YAML 파일을 가져오는 기능을 지원하며, 자체 서버를 운영하거나 규칙을 완전히 통제하고 싶은 사용자에게 적합합니다. 여러 Profile은 서로 배타적으로 전환됩니다: 한 시점에는 하나만 적용되며, 전환하면 포트·노드·규칙 세 블록이 통째로 교체됩니다. 흔한 관리 전략은 "구독 하나 + 로컬 실험용 하나"입니다: 평소에는 구독을 쓰고 규칙을 만질 때는 로컬 복사본으로 전환해, 잘못돼도 언제든 되돌릴 수 있습니다. 구독은 업데이트마다 원격 내용을 덮어쓰므로 구독 Profile을 직접 수정하면 그 변경 사항은 사라집니다 — 영구적인 커스터마이징은 9장의 오버라이드 메커니즘을 사용하세요. Profile 구조에 대한 자세한 설명은 블로그 《Clash 설정 파일이란》을 참고하세요.

05프록시 모드와 시스템 프록시

세 가지 실행 모드

설정의 mode 필드는 세 가지 값을 가집니다. rule(규칙): 각 연결이 rules 목록을 하나씩 매칭해 걸린 대로 처리하는 방식으로, 국내는 다이렉트, 해외는 프록시를 타는 일상 추천 모드입니다. global(전역): 규칙을 건너뛰고 모든 트래픽이 같은 프록시 그룹으로 들어가며, "규칙이 제대로 매칭되지 않는 게 아닐까" 임시로 점검할 때만 씁니다. direct(다이렉트): 모든 트래픽이 프록시를 타지 않아 클라이언트는 켜져 있지만 길을 비켜주는 것과 같습니다. 전환 진입점은 클라이언트 메인 화면에 있으며 보통 세 옵션이 나란히 있습니다.

시스템 프록시가 하는 일

"시스템 프록시" 스위치를 켜면 클라이언트가 운영체제에 HTTP/SOCKS 프록시 주소를 등록합니다. 기본값은 127.0.0.1:7890(앞서 나온 mixed-port 혼합 포트)입니다. 브라우저와 시스템 프록시 설정을 따르는 대부분의 앱은 이 포트로 스스로 트래픽을 보냅니다. 한계도 바로 이 "스스로"에 있습니다: 커맨드라인 도구, 일부 게임과 오래된 앱은 시스템 프록시 설정을 읽지 않아 트래픽이 코어를 지나가지 않습니다 — 이런 상황은 7장의 TUN 모드가 맡습니다.

링크가 정상 작동하는지 확인하기

연결 후에는 두 단계로 확인합니다. 첫 단계는 클라이언트 연결 패널을 보는 것입니다: 임의의 웹사이트에 접속했을 때 패널에 새 연결 기록이 나타나고 매칭된 규칙과 출구가 표시되면 트래픽이 실제로 들어온 것입니다. 두 번째 단계는 커맨드라인에서 프록시를 명시적으로 지정해 테스트하는 것입니다:

# 로컬 혼합 포트로 요청을 보내 응답 헤더가 반환되면 연결이 정상 작동
curl -x http://127.0.0.1:7890 -I https://www.cloudflare.com

다이렉트는 정상인데 프록시를 타면 타임아웃이 발생한다면 순서대로 확인하세요: 노드가 사용 가능한지(다른 노드로 바꿔 재시도), 구독이 만료됐는지, 로컬 방화벽이 클라이언트를 차단하고 있는지.

06규칙 분산: 연결마다 제 갈 길로

규칙은 어떻게 매칭되는가

rules 목록은 위에서 아래로 하나씩 매칭하며 걸리면 즉시 멈춥니다. 각 규칙은 "타입, 매칭값, 목표 정책"으로 구성되며, 목표 정책은 특정 프록시 그룹이거나 내장된 DIRECT(다이렉트), REJECT(차단)일 수 있습니다. 목록 맨 끝에는 반드시 MATCH 항목을 두어 앞에서 걸리지 않은 모든 트래픽을 받아야 합니다. 자주 쓰는 규칙 타입은 다음과 같습니다:

순서에 민감하다는 점은 초보자가 가장 자주 밟는 함정입니다: GEOIP,CN,DIRECT를 해외 도메인 규칙보다 앞에 두면, 그 도메인이 마침 국내 CDN으로 해석될 때 연결이 미리 다이렉트로 걸려버립니다. 원칙은 정밀한 규칙을 앞에, 범위가 넓은 규칙을 뒤에, MATCH는 항상 맨 마지막에 두는 것입니다.

프록시 그룹의 네 가지 전략

규칙의 목표는 보통 단일 노드가 아니라 프록시 그룹이며, 그룹 내 전략이 실제 출구를 결정합니다: select는 수동 선택으로 화면에서 누른 것이 그대로 사용됩니다. url-test는 주기적으로 테스트 주소에 지연을 측정해 가장 빠른 노드를 자동으로 선택합니다. fallback은 목록 순서대로 첫 번째 사용 가능한 노드를 사용하며 앞선 노드가 죽으면 자동으로 다음으로 넘어갑니다. load-balance는 연결을 여러 노드로 분산시킵니다. 바로 적용할 수 있는 조합은 다음과 같습니다:

proxy-groups:
  - name: PROXY
    type: select
    proxies: [AUTO, HK-01, JP-01, US-01]
  - name: AUTO
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    proxies: [HK-01, JP-01, US-01]

rules:
  - DOMAIN-SUFFIX,openai.com,PROXY
  - RULE-SET,streaming,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

평소에는 PROXY 그룹을 AUTO에 두어 자동으로 속도를 측정하게 하고, 특정 지역이 필요할 때(예: 스트리밍 해제)는 해당 노드로 수동 전환하세요. 노드 선택의 네 가지 기준 — 지연, 배율, 지역, 프로토콜 — 에 대한 자세한 분석은 블로그 《Clash 노드는 어떻게 고를까》를 참고하세요.

DNS와 Fake-IP

분산이 정확히 이루어지려면 도메인 정보가 손실되지 않아야 합니다. mihomo의 dns 블록은 두 가지 모드를 지원합니다: redir-host는 실제 해석 후 IP로 매칭하고, fake-ip는 예약된 네트워크 대역으로 가짜 응답을 만들고 연결을 맺을 때 실제 도메인을 복원합니다. 후자는 해석 지연을 크게 줄이고 DNS 오염이 분산을 방해하는 것을 막아줍니다. 실제 IP에 의존하는 일부 앱(LAN 검색, 특정 게임 플랫폼)은 fake-ip-filter에 등록해 제외해야 하며, 전체 메커니즘은 블로그 《Fake-IP 모드 동작 원리 완전 정리》에서 확인하세요.

07TUN 모드: 시스템 전체 트래픽 인수

원리와 적용 상황

TUN 모드는 코어가 가상 네트워크 카드를 만들고 시스템 기본 라우트를 그곳으로 가리키게 합니다 — 모든 앱의 트래픽이 네트워크 계층에서 가로채지므로 앱이 시스템 프록시 설정을 따르는지와 상관없어집니다. 커맨드라인 도구, 게임 클라이언트, UWP 앱처럼 "시스템 프록시를 인식하지 않는" 트래픽도 TUN 아래에서는 모두 규칙 엔진으로 들어갑니다. 두 방식의 차이는 다음과 같습니다:

활성화 절차

1. 먼저 권한 전제 조건을 만족하세요: Windows는 클라이언트 설정에서 서비스 모드를 설치(또는 관리자 권한으로 실행)하고, macOS는 보조 서비스 권한을 승인하며, Linux는 클라이언트의 서비스 모드를 활성화하거나 코어에 네트워크 관리 권한을 부여하세요.
2. 클라이언트 설정에서 TUN 스위치를 켜세요. Verge 계열 클라이언트는 이중 인수를 피하기 위해 시스템 프록시 스위치를 동시에 끄는 것을 권장합니다.
3. DNS 하이재킹이 켜져 있는지 확인하세요. 그렇지 않으면 앱이 시스템 DNS로 직접 연결해 분산을 우회할 수 있습니다.

해당 설정 블록(클라이언트 GUI 스위치는 결국 이 필드들을 쓰는 것입니다):

tun:
  enable: true
  stack: system        # system / gvisor / mixed
  auto-route: true     # 기본 라우트를 자동으로 인수
  auto-detect-interface: true
  dns-hijack:
    - any:53           # 53번 포트로 전송되는 모든 DNS 쿼리를 가로챔

08일상 유지 관리와 문제 해결

세 가지는 항상 최신으로 유지

구독: 자동 업데이트를 켜고 간격은 24시간 이내로 설정하세요. 서비스 제공자가 노드 교체를 공지한 뒤 수동으로 한 번 업데이트하면 즉시 적용됩니다. 클라이언트와 코어: 유지 관리 중인 클라이언트는 버전 업데이트에 따라 코어도 갱신되며, 새 프로토콜과 수정 사항이 모두 여기에 의존합니다. 업그레이드 전에 업데이트 설명에 설정 필드 변경이 있는지 확인하세요. GEO 데이터와 규칙 세트: GeoIP / GeoSite 데이터베이스와 RULE-SET이 참조하는 외부 파일 모두 업데이트 메커니즘이 있으며, 클라이언트 설정에는 보통 "GEO 데이터 업데이트" 버튼이 있습니다. 규칙 매칭 결과가 예상과 다를 때는 먼저 업데이트한 뒤 점검하세요.

매일 확인할 두 가지 창

로그 페이지: log-level을 임시로 debug로 바꾸면 각 연결의 매칭 과정을 볼 수 있어 "이 트래픽이 정확히 어느 규칙에 걸렸는지" 가장 직접적으로 확인할 수 있습니다. 확인이 끝나면 info로 되돌려 로그가 넘쳐 자원을 낭비하지 않게 하세요. 연결 패널: 활성 연결의 목표, 매칭된 규칙, 출구 노드, 트래픽을 실시간으로 나열합니다. 특정 앱이 잘못된 출구로 나가는 것을 발견하면 여기서 목표 도메인을 확인하고 설정에 정밀 규칙을 추가하세요.

문제 해결 대조표

09심화 학습 로드맵: 사용에서 숙달로

오버라이드: 구독 업데이트 후에도 커스터마이징 유지하기

구독은 업데이트마다 Profile을 통째로 덮어쓰므로 파일을 직접 수정한 커스터마이징은 다음 업데이트를 넘기지 못합니다. 올바른 방법은 오버라이드(Merge / Override)입니다: 클라이언트에서 별도의 패치를 관리해 구독이 업데이트될 때마다 설정에 자동으로 덧씌우는 방식입니다. 대표적인 사용 예는 자신만의 규칙 추가, DNS 대역 고정, TUN 필드 강제 활성화입니다. Clash Verge Rev는 JavaScript 스크립트 오버라이드도 지원해 조건에 따라 노드와 프록시 그룹을 대량으로 재작성할 수 있어 규칙이 많은 사용자에게 적합합니다.

외부 제어 API와 웹 패널

코어는 external-controller를 통해 RESTful API 세트를 노출하며, 클라이언트 화면 자체도 이 API를 사용하는 소비자입니다. 직접 호출할 수도 있습니다:

# 현재 설정 확인
curl http://127.0.0.1:9090/configs
# select 그룹의 출구 노드 전환
curl -X PUT http://127.0.0.1:9090/proxies/PROXY \
  -d '{"name": "HK-01"}'

external-ui 필드를 함께 쓰면 웹 제어 패널을 연결해 브라우저에서 실행 중인 코어를 관리할 수 있습니다 — 라우터와 서버 환경에서 표준적으로 쓰는 방식입니다.

GUI 없는 환경에서 코어 직접 실행하기

서버, 소프트 라우터, NAS에서는 GUI가 필요 없습니다. 다운로드 센터 코어 섹션에서 해당 아키텍처의 mihomo 바이너리(AMD64 / ARM64 / ARMv7 / MIPS 등)를 받아 설정을 지정된 디렉터리에 두고 실행하세요:

# -d 로 설정 디렉터리를 지정, 디렉터리 안에 config.yaml과 GEO 데이터 배치
./mihomo -d /etc/mihomo
# systemd로 상시 실행, 부팅 시 자동 시작
sudo systemctl enable --now mihomo

LAN의 다른 기기가 게이트웨이나 프록시를 이 기기로 지정하면 가족 전체가 같은 분산 규칙을 공유할 수 있습니다.

추천하는 심화 학습 순서

1. Profile 구조 입문과 다중 설정 관리 — 4장의 설정 골격을 완전히 이해하기.
2. 노드 선택 4가지 기준 — 자신만의 노드 선택 절차 세우기.
3. Fake-IP 동작 원리 — DNS 계층에서 일어나는 일 이해하기.
4. mihomo와 오리지널 코어의 차이 — 지금 쓰는 도구의 한계가 어디인지 알기.
5. 직접 실습하기: 오버라이드로 자신만의 규칙 패치를 관리하고, 유휴 기기 한 대에 순수 코어를 배포해 보세요. 이 다섯 단계를 마치면 이 매뉴얼의 9개 장이 진짜 자신의 지식이 됩니다.