Clash 완전 마스터 가이드

Clash는 규칙 기반으로 동작하는 네트워크 프록시 도구입니다. 동작 방식을 한 문장으로 요약하면: YAML 형식의 설정 파일을 읽고, 그 안에 정의된 규칙에 따라 각 네트워크 연결을 직접 전송할지, 특정 프록시 노드를 통해 전달할지 결정합니다. 이 한 문장을 이해하면 이후 모든 챕터는 이를 구체적으로 풀어낸 내용입니다.

코어와 클라이언트

"Clash"라는 이름은 일상적으로 두 가지를 가리킵니다. 첫 번째는 코어로, 그래픽 인터페이스가 없는 커맨드라인 프로그램이며 실제 트래픽 처리, 규칙 매칭, 프로토콜 구현을 담당합니다. 원조 Clash 코어는 이미 아카이브 처리되었고, 현재 커뮤니티에서 활발히 유지 관리되는 후속 프로젝트는 mihomo 코어입니다. 두 번째는 클라이언트로, 코어를 감싸는 그래픽 인터페이스이며 구독 관리, 스위치 전환, 로그 표시 등 사용자와의 상호작용을 담당합니다. Clash Plus, Clash Verge Rev, FlClash 같은 이름은 모두 클라이언트 계층에 속하며, 내부적으로는 같은 계열의 코어를 사용합니다. 이는 흔한 질문에 대한 답이기도 합니다. 왜 서로 다른 클라이언트가 같은 구독을 사용할 수 있을까요? 설정 파일은 코어를 위해 작성된 것이고, 클라이언트는 그것을 전달하는 역할만 하기 때문입니다. 프로젝트 계보에 대한 전체 정리는 이 글에서 확인할 수 있습니다.

피할 수 없는 4가지 용어

• 노드(proxy): 사용 가능한 프록시 서버 한 대를 의미하며, 설정 파일의 proxies 항목 하나에 해당합니다. 서버 주소, 포트, 프로토콜, 키 정보를 포함합니다.
• 구독(subscription): 서비스 제공자가 호스팅하는 URL로, 접속하면 전체 설정 또는 노드 목록을 반환합니다. 클라이언트가 주기적으로 가져오며, 노드가 변경되면 자동으로 동기화되어 파일을 직접 수정할 필요가 없습니다.
• 정책 그룹(proxy-group): 여러 노드를 하나의 선택 단위로 묶은 것으로, 예를 들어 '수동 선택 그룹', '자동 속도 테스트 그룹' 등이 있습니다. 규칙의 출구는 특정 노드가 아니라 정책 그룹을 가리킵니다.
• 규칙(rule): '일치 조건 + 출구'로 이루어진 한 줄의 선언으로, 예를 들어 'github.com으로 끝나는 도메인은 프록시 그룹으로 보낸다'와 같은 형태입니다. 규칙 목록은 위에서 아래로 매칭되며, 일치하는 순간 멈춥니다.

연결 하나가 거치는 전체 과정

브라우저가 접속을 시작하면, 연결은 먼저 Clash가 대기하는 로컬 포트로 들어갑니다. 코어는 목적지 도메인이나 IP를 추출해 규칙 목록의 첫 번째 항목부터 하나씩 비교하고, 일치하는 규칙을 찾으면 해당 규칙이 지정한 정책 그룹으로 연결을 넘깁니다. 정책 그룹은 자신의 유형(수동 선택 또는 자동 속도 테스트)에 따라 최종 노드를 결정하고, 데이터는 해당 노드를 거쳐 목적지로 전달됩니다. 이 모든 과정은 로컬 기기에서 밀리초 단위로 완료됩니다. 이후 다룰 모든 기능—모드 전환, 규칙 작성, TUN—은 이 과정의 특정 구간을 바꾸는 것일 뿐입니다.

클라이언트를 잘못 선택해도 손해가 생기는 것은 아니지만 시간이 낭비됩니다. 선택은 세 가지 질문에 답하면 됩니다. 어떤 시스템을 사용하는가, 전체 트래픽을 접수하는 TUN 모드가 필요한가, 프로젝트가 여전히 유지 관리되고 있는가. 세 번째 질문이 가장 쉽게 무시되는데, 유지 관리가 중단된 클라이언트는 코어 업데이트를 따라가지 않아 새로운 프로토콜이나 규칙 유형을 사용할 수 없고, 시스템을 업그레이드한 뒤 호환성 문제가 생길 수도 있습니다.

플랫폼별 빠른 참고표

선택에 도움이 되는 몇 가지 경험

Clash Plus는 다섯 개 플랫폼을 모두 지원하고 인터페이스가 통일되어 있으며 구독 관리 기능도 완비되어 있어 부담 없는 기본 선택입니다. 여러 기기를 사용하는 사용자는 일관된 조작 방식에서 특히 이점을 얻습니다. Clash Verge Rev는 mihomo 코어 기반으로 설정 자유도가 가장 높아 YAML을 다뤄볼 의향이 있는 사용자에게 적합하며 Linux 데스크톱에서도 첫 번째 선택입니다. FlClash는 경량화 노선을 택해 리소스 사용량이 낮아 오래된 기기나 백그라운드 상시 실행 환경에서 잘 작동합니다. Clash Nyanpasu는 Windows 전용으로 독특한 인터페이스를 가지고 있으며 기능은 Verge Rev와 비슷합니다. Surfboard는 Android용 경량 클라이언트로 기본적인 프록시 기능만 제공하며 고급 기능은 지향하지 않습니다.

시스템 사용량, TUN 지원, 구독 관리, 사용 편의성 네 가지 항목별 점수 비교는 비교 평가 페이지에서 더 자세한 결론을 확인할 수 있으며, 블로그의 선택 가이드 노트에서는 구체적인 사용 시나리오를 추가로 다룹니다. 선택을 마쳤다면 바로 다운로드 페이지로 이동하세요. 플랫폼별 설치 파일이 같은 순서로 정리되어 있습니다.

설치 자체는 복잡하지 않지만 플랫폼마다 시스템 차원의 관문이 하나씩 있습니다. 데스크톱 시스템의 보안 경고, 모바일 시스템의 VPN 권한 요청입니다. 어떤 알림이 뜨고 어느 버튼을 눌러야 하는지 미리 알아두면 첫 단계에서 막히지 않습니다.

Windows

다운로드 페이지에서 설치 프로그램을 받아 더블 클릭으로 실행합니다. 처음 실행할 때 SmartScreen이 'Windows에서 PC를 보호했습니다'라는 창을 띄울 수 있는데, 이는 서명되지 않았거나 다운로드 수가 적은 프로그램에 대한 일반적인 안내이며 바이러스 경고가 아닙니다. '추가 정보'를 클릭한 뒤 '실행'을 누르면 계속 진행됩니다. 설치 경로는 기본값을 유지하는 것이 좋습니다. 이후 TUN 모드를 사용하려면 처음 실행할 때 클라이언트 안내에 따라 시스템 서비스를 설치하면 되고, 한 번 권한을 부여하면 이후에는 다시 묻지 않습니다.

macOS

.dmg 이미지를 다운로드하고 열어서 앱 아이콘을 Applications 폴더로 드래그합니다. 처음 열 때 Gatekeeper가 앱이 인터넷에서 다운로드되었다는 알림을 표시하면 '열기'를 선택해 확인합니다. 칩 아키텍처에 주의해야 합니다. Apple Silicon 기종(M 시리즈)은 arm 버전을, Intel 기종은 x64 버전을 다운로드해야 합니다. 아키텍처를 잘못 설치하면 변환 계층을 통해 실행되어 성능이 눈에 띄게 떨어집니다. 강화 모드나 TUN을 켤 때 시스템이 비밀번호를 요구하며 보조 도구를 설치하는데, 이는 정상적인 권한 부여 과정입니다.

Android

APK를 설치할 때 시스템이 '알 수 없는 소스의 앱 설치를 허용하지 않음'이라는 안내를 표시할 수 있는데, 설정에서 브라우저나 파일 관리자에 해당 권한을 일시적으로 허용하면 됩니다. 처음 연결을 누르면 시스템이 'XX에서 VPN 연결을 설정하려고 합니다' 대화상자를 띄웁니다. Android 클라이언트는 시스템 VPN 인터페이스를 통해 트래픽을 접수하므로 동의해야 작동하며 이 단계는 한 번만 나타납니다. 일부 제조사의 시스템은 백그라운드 앱을 적극적으로 정리하므로, 배터리 최적화 설정에서 클라이언트를 화이트리스트에 추가하는 것을 권장합니다. 그렇지 않으면 화면을 잠근 뒤 연결이 끊길 수 있습니다.

iOS

iOS의 배포 채널은 App Store로, Clash Plus를 검색하거나 공식 사이트 clashplus.io에서 제공하는 링크를 통해 받을 수 있습니다. 설치 후 처음 실행하면 VPN 구성 추가 권한을 요청하는데, 시스템 팝업에서 확인하고 Face ID나 비밀번호로 한 번 인증하면 됩니다. iOS의 프록시는 시스템 네트워크 계층에서 작동하므로 모든 앱이 클라이언트의 규칙을 통일적으로 따르며 앱마다 개별 설정을 할 필요가 없습니다. 처음 설정할 때의 단계별 스크린샷 가이드는 블로그의 iPhone 첫 설정 노트에서 확인할 수 있습니다.

Linux

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

sudo apt install ./clash-verge.deb
# 의존성 누락 안내가 나타나면:
sudo apt --fix-broken install

Fedora 계열은 .rpm 패키지와 dnf install을 사용합니다. 그래픽 인터페이스가 없는 서버는 mihomo 코어 바이너리를 직접 다운로드해 압축을 풀고 systemd로 상시 실행하면 되며, 코어 다운로드 링크도 다운로드 페이지 코어 영역에 있습니다.

클라이언트를 설치한 직후에는 비어 있는 상태입니다. 노드가 없어 어디에도 연결할 수 없습니다. 노드 데이터는 구독을 통해 클라이언트로 들어오며, 이는 전체 과정에서 외부에서 제공받아야 하는 유일한 요소입니다.

구독의 본질

구독은 서비스 제공자가 호스팅하는 URL입니다. 클라이언트가 이 URL에 접속하면 완전한 Clash 설정(또는 노드 목록)을 받게 되며, 그 안에는 이미 proxies, proxy-groups, rules 세 개 섹션이 작성되어 있습니다. 이후 클라이언트는 설정된 간격에 따라 다시 가져오며, 서비스 제공자가 서버를 교체하거나 노드를 추가/삭제하면 로컬에서 자동으로 동기화됩니다. 가져오는 방식은 모든 클라이언트가 동일합니다. 구독 링크를 복사해 구독 또는 설정 페이지에 붙여넣고 다운로드를 확인하면 됩니다. 각 플랫폼에서 정확히 어디를 눌러야 하는지는 튜토리얼 페이지에 단계별로 안내되어 있으므로 여기서는 반복하지 않습니다.

설정 파일의 뼈대 이해하기

구독을 다운로드하면 YAML 텍스트 하나가 됩니다. 직접 작성할 필요는 없지만 뼈대를 이해하면 문제 해결에 큰 도움이 됩니다. 최소한의 설정에서 전역 섹션은 다음과 같은 형태입니다:

mixed-port: 7890          # HTTP와 SOCKS가 공유하는 로컬 리스닝 포트
allow-lan: false          # 로컬 네트워크의 다른 기기 접속 허용 여부
mode: rule                # 시작 시 프록시 모드
log-level: info           # 로그 레벨, 문제 해결 시 임시로 debug로 변경 가능
external-controller: 127.0.0.1:9090   # 로컬 제어 인터페이스

그 다음에는 순서대로 proxies(노드 목록), proxy-groups(정책 그룹), rules(규칙 목록)가 이어집니다. 세 섹션의 관계는 규칙이 정책 그룹을 가리키고, 정책 그룹이 노드를 가리키는 구조입니다. 어느 한 섹션의 이름이라도 맞지 않으면 설정 로드가 실패하며, 클라이언트 로그에 구체적인 줄 번호가 표시됩니다.

구독 변환이란

서비스 제공자가 다른 형식의 노드 정보(예: 범용 공유 링크)만 제공하는 경우, "구독 변환" 서비스를 거쳐 Clash 설정 형식으로 바꿔야 합니다. 변환 과정은 제3자 서버를 경유하며 구독 내용이 그 서버에 노출되므로 유출 위험이 존재합니다. 원본 Clash 구독을 받을 수 있다면 그것을 우선 사용하고, 변환이 꼭 필요하다면 신뢰할 수 있는 자체 구축 또는 오픈소스 변환 서버를 선택하세요.

여러 기기가 하나의 구독을 함께 사용할 때는 설정 파일을 서로 복사하기보다 "구독 링크를 중앙에서 관리"하는 방식을 권장합니다. 세 가지 동기화 방안의 장단점은 멀티 디바이스 동기화 노트에서 확인할 수 있습니다.

모드는 "규칙 목록이 결정에 참여하는지 여부"를 결정합니다. 세 가지 모드는 서로 배타적인 전역 스위치이며, 클라이언트 메인 화면에서 한 번의 클릭으로 전환할 수 있고, 설정 파일의 mode 필드에 대응합니다.

흔한 잘못된 사용은 GLOBAL을 계속 켜두는 것입니다. 전역 모드에서는 중국 본토 사이트의 트래픽도 해외 노드를 거치게 되어 속도가 오히려 느려지고 트래픽 할당량도 불필요하게 소모됩니다. 올바른 방식은 99%의 시간을 RULE에 두고, GLOBAL과 DIRECT는 문제 해결 도구로만 짧게 사용하는 것입니다. "GLOBAL로 바꾸면 접속되고 RULE로 돌아오면 안 된다"면 문제는 규칙에 있고, "DIRECT로 바꿔도 접속이 안 된다"면 문제는 프록시와 무관합니다.

시스템 프록시와 모드의 차이

또 하나 혼동하기 쉬운 스위치는 "시스템 프록시"입니다. 이는 세 가지 모드에 속하지 않으며, "운영체제가 트래픽을 Clash로 보낼지 여부"를 결정합니다. 켜면 시스템 차원의 프록시 설정이 Clash의 로컬 포트를 가리키게 되어, 이 설정을 따르는 앱(브라우저 등)의 트래픽만 들어오고, 시스템 프록시를 따르지 않는 앱(일부 게임, 커맨드라인 프로그램)은 완전히 우회합니다. 모든 프로그램을 예외 없이 Clash로 들어오게 하려면 7장의 TUN 모드가 필요합니다. 계층 관계는 한 문장으로 기억하세요. 시스템 프록시/TUN은 트래픽이 들어오는지를 결정하고, 모드는 들어온 뒤 어떻게 흘러갈지를 결정합니다.

규칙 라우팅은 Clash를 단순 프록시 도구와 구별짓는 핵심 기능이며, RULE 모드 이면의 모든 로직이기도 합니다. 구독에 기본 포함된 규칙 세트가 대부분의 요구를 충족하지만, 언젠가는 "특정 사이트의 라우팅이 잘못됐다"는 순간을 만나게 됩니다. 이때는 규칙을 이해하고, 필요하다면 직접 한 줄을 추가해야 합니다.

규칙 문법

각 규칙은 쉼표로 구분된 한 줄의 선언입니다: 유형,일치 값,출구. 출구는 정책 그룹 이름일 수도 있고, 내장된 DIRECT(직접 연결)나 REJECT(차단)일 수도 있습니다. 자주 쓰이는 유형은 다음과 같습니다:

순서가 모든 것을 결정한다

규칙 목록은 위에서 아래로 매칭되며, 처음 일치하는 규칙이 즉시 적용되고 이후의 규칙은 모두 무시됩니다. 따라서 배치에는 정해진 원칙이 있습니다. 정확한 것은 앞에, 범위가 넓은 것은 뒤에, 기본값은 맨 마지막에 둡니다. 중국 본토와 해외를 구분하는 최소한의 규칙 세트는 다음과 같습니다:

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - DOMAIN-SUFFIX,openai.com,PROXY
  - DOMAIN-KEYWORD,google,PROXY
  - DOMAIN-SUFFIX,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

읽는 방법: 알려진 해외 도메인과 일치하면 프록시를 거치고, .cn 접미사는 직접 연결, 해석된 IP가 중국 본토에 속하면 직접 연결, 이 중 아무것도 일치하지 않으면 기본값으로 프록시를 거칩니다. GEOIP는 먼저 DNS 해석을 해야 IP를 얻을 수 있으므로 도메인 규칙을 그 앞에 두면 대부분의 연결이 해석 전에 라우팅을 마칠 수 있습니다. IP-CIDR 규칙에 no-resolve 매개변수를 추가하면 순수 도메인 연결에 불필요한 해석이 발생하는 것을 막을 수 있습니다.

정책 그룹: 규칙의 출구

위 예시의 PROXY는 정책 그룹 이름입니다. 자주 쓰이는 그룹 유형은 select(수동 선택), url-test(주기적으로 속도를 테스트해 가장 빠른 노드를 자동 선택), fallback(우선 노드 장애 시 자동으로 대체 노드로 전환)입니다. 대표적인 조합은 다음과 같습니다:

proxy-groups:
  - name: PROXY
    type: select
    proxies: [AUTO, 香港节点, 日本节点]
  - name: AUTO
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    proxies: [香港节点, 日本节点]

수동 그룹 안에 자동 속도 테스트 그룹을 넣어두면, 평소에는 AUTO를 선택해 편리하게 사용하고 특별한 필요가 있을 때는 특정 노드를 수동으로 고정할 수 있습니다.

규칙이 적용되지 않을 때의 문제 해결 절차

1. 현재 RULE 모드인지 확인하세요. GLOBAL과 DIRECT에서는 규칙이 전혀 작동하지 않습니다.
2. 클라이언트의 연결 패널을 열어 대상 연결을 찾아 실제로 어떤 규칙이 적용됐는지 확인하세요. 대부분의 "잘못된 라우팅"은 목록 앞쪽에 있는 범위가 넓은 규칙에 먼저 걸리기 때문입니다.
3. 직접 추가한 규칙이 구독 규칙 뒤에 작성되었는지 확인하세요. MATCH 뒤에 추가한 규칙은 절대 적용될 차례가 오지 않습니다.
4. 도메인 규칙은 적용되지 않는데 IP 규칙은 적용된다면, 보통 DNS 계층의 간섭 때문이므로 7장의 fake-ip 내용과 함께 확인하세요.

실제 사례를 담은 실전 가이드는 블로그의 규칙 라우팅 실전 노트에서 확인할 수 있습니다.

5장에서 남겨둔 빈틈이 하나 있습니다. 시스템 프록시는 "시스템 프록시 설정을 따르는" 앱에만 유효합니다. 커맨드라인 도구, 일부 게임 클라이언트, 몇몇 메신저 프로그램은 자체적으로 연결을 만들어 프록시를 완전히 우회합니다. TUN 모드는 이 빈틈을 채우는 해결책입니다.

원리

TUN을 켜면 클라이언트가 시스템에 가상 네트워크 카드를 만들고 이를 기본 경로로 설정합니다. 프록시 설정을 따르는지 여부와 관계없이 모든 앱의 네트워크 트래픽은 먼저 이 가상 카드를 거쳐 Clash 코어로 들어간 뒤 규칙에 따라 라우팅됩니다. 효과는 모바일의 VPN 접수 방식과 같습니다. 앱은 이를 인식하지 못하며 라우팅은 시스템 전체에 적용됩니다. 대가는 더 높은 시스템 권한이 필요하다는 점입니다. Windows에서는 서비스 방식으로 실행하거나 관리자 권한을 부여해야 하고, macOS에서는 시스템 확장 프로그램 권한을 승인해야 하며, Linux에서는 해당하는 네트워크 관리 권한이 필요합니다. 각 클라이언트는 처음 켤 때 권한 부여 과정을 안내하며, 한 번 승인하면 계속 유효합니다.

설정 예시

tun:
  enable: true
  stack: system
  auto-route: true              # 라우팅 테이블 자동 설정
  auto-detect-interface: true   # 물리적 출구 네트워크 카드 자동 감지

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://223.5.5.5/dns-query
    - https://120.53.53.53/dns-query

그래픽 클라이언트에서는 이런 항목들이 대부분 이미 만들어진 스위치로 제공되어 직접 작성할 필요가 없습니다. 여기에 보여주는 이유는 스위치 뒤에서 실제로 바뀌는 것이 무엇인지 알려주기 위해서입니다. stack은 프로토콜 스택 구현으로, 구현마다 호환성이 약간 다르므로 특정 앱에서 이상이 생기면 다른 것으로 바꿔 다시 시도해볼 수 있습니다.

TUN이 항상 fake-ip와 함께 등장하는 이유

TUN이 트래픽을 접수하면 DNS 해석도 Clash가 통합해서 처리해야 합니다. 그렇지 않으면 "해석은 바깥에서, 트래픽은 안에서"라는 불일치가 생겨 도메인 규칙이 무효화됩니다. fake-ip 모드에서는 코어가 매번 도메인 해석 요청에 예약된 네트워크 대역의 가상 IP를 반환하고, 앱은 이 가상 IP로 연결을 시작하며, 코어는 매핑 테이블을 이용해 원래 도메인을 복원한 뒤 규칙을 매칭합니다. 이렇게 하면 실제 해석 대기 시간을 건너뛰면서도 도메인 규칙이 항상 안정적으로 작동합니다. 부작용으로는 IP에 민감한 일부 프로그램(로컬 네트워크 검색, 일부 로그인 검증)이 제대로 동작하지 않을 수 있는데, 이럴 때는 관련 도메인을 fake-ip 필터 목록에 추가하면 됩니다.

설정이 정상 작동하는 것은 시작일 뿐입니다. 프록시는 오래 사용할 기반 인프라이므로, 10분을 투자해 부담 없는 유지 관리 습관을 만들어두면 "어느 날 갑자기 전부 끊기는" 상황에서 허둥대지 않을 수 있습니다.

구독 업데이트 전략

클라이언트에서 구독의 자동 업데이트 간격을 설정하세요. 24시간에 한 번이 합리적인 기본값입니다. 서비스 제공자가 서버 교체를 공지하면 즉시 수동으로 업데이트를 한 번 실행하세요. 업데이트에 실패해도 기존 노드가 사라지지 않고 클라이언트는 이전 캐시를 계속 사용하므로, 가끔 발생하는 업데이트 실패는 걱정할 필요가 없습니다. 여러 날 연속으로 실패할 때만 구독 주소가 서비스 제공자에 의해 재설정되었는지 확인하면 됩니다.

로그: 문제 해결의 첫 현장

모든 클라이언트는 로그 패널을 제공합니다. 평소에는 info 레벨을 유지하면 됩니다. 문제를 해결할 때는 임시로 debug로 바꾸면 각 연결의 규칙 매칭, DNS 해석, 출구 선택을 확인할 수 있습니다. 로그를 보는 기본 방법은 문제를 재현한 뒤 최신 몇 줄을 바로 확인하는 것으로, 주로 error, timeout, refused 같은 키워드를 찾습니다. 원인을 파악한 뒤에는 info로 다시 돌려놓는 것을 잊지 마세요. debug 로그는 양이 많아 장기간 켜두면 디스크가 낭비됩니다.

백업과 멀티 디바이스 일관성

실제로 백업해야 할 것은 그리 많지 않습니다. 구독 링크 자체, 직접 작성한 규칙 조각, 클라이언트에서 변경한 설정 항목입니다. 구독 링크는 비밀번호 관리자에 저장하고, 직접 작성한 규칙은 별도의 텍스트 파일로 보관하세요. 여러 기기를 사용하는 경우 설정 파일을 수동으로 옮기기보다 각 기기가 같은 구독을 각자 가져오게 하는 방식을 우선하세요. 일부 클라이언트는 WebDAV 백업을 지원해 인터페이스 설정까지 동기화할 수 있습니다. 세 가지 방식의 전체 비교는 멀티 디바이스 동기화 노트에서 확인할 수 있습니다.

클라이언트 업그레이드

클라이언트 업데이트는 보통 코어 업데이트도 함께 가져오므로 따라가는 것이 좋습니다. 새로운 규칙 유형과 프로토콜 지원은 모두 코어 버전에 의존합니다. 업그레이드 전에는 릴리스 노트에 설정 비호환 안내가 있는지 확인하세요. 주요 클라이언트는 업그레이드 시 구독과 설정을 유지하지만, 큰 버전을 건너뛰기 전에는 구독 링크를 미리 적어두는 것이 좋습니다. 비용은 거의 없고 안심할 수 있다는 이점이 있습니다. 새 버전 설치 파일은 항상 다운로드 페이지의 해당 플랫폼에서 받을 수 있습니다.

앞선 8개 챕터를 마치면 일상적인 사용에는 걸림돌이 없습니다. 이 챕터에서는 더 깊이 들어갈 수 있는 세 가지 방향을 투입 대비 효과 순서로 제시합니다.

방향 1: 자신만의 규칙 만들기

구독에 기본 포함된 규칙은 서비스 제공자의 범용 방안이며, 심화 학습의 첫걸음은 자신만의 규칙 계층을 만드는 것입니다. 대부분의 최신 클라이언트는 "설정 오버라이드" 또는 "Merge/Script" 메커니즘을 지원합니다. 구독 원문을 수정하지 않으면서 직접 작성한 규칙을 규칙 목록 상단에 주입할 수 있으며, 구독을 업데이트해도 수정한 내용이 사라지지 않습니다. 작은 것부터 시작하세요. 일상적으로 마주치는 라우팅 오류를 하나씩 수정해 3개월 정도 쌓으면 자신의 사용 습관에 완전히 맞는 규칙 계층을 얻게 됩니다. 규칙 세트(rule-providers)는 더 체계적인 구성 방식으로, 규칙을 용도별로 나누어 독립적으로 업데이트할 수 있는 원격 파일로 만드는 것이며 규칙이 백 개를 넘으면 도입할 만한 가치가 있습니다.

방향 2: mihomo의 확장 기능 이해하기

mihomo 코어는 기존 Clash 설정 형식 위에 다양한 기능을 확장했습니다. 더 많은 프로토콜 지원, 더 세밀한 DNS 제어, 프로세스 단위 매칭 규칙, 아웃바운드 인터페이스 바인딩 등입니다. 이런 기능들은 대부분 직접 설정 조각을 작성해야 활성화되며, 공식 문서가 유일하게 권위 있는 출처입니다. 학습 방법은 하나씩 실험하는 것입니다. 매번 한 구간만 추가하고, 정상적으로 로드되면 다음 구간을 추가하며, 설정에 오류가 생기면 로그에 정확한 줄 번호가 표시됩니다. 서버나 소프트웨어 라우터에 코어와 systemd를 직접 배포하는 것은 이 방향의 졸업 프로젝트라 할 수 있습니다. 그래픽 인터페이스라는 안전망 없이 모든 동작이 직접 작성한 YAML로 결정됩니다.

방향 3: 생태계를 이해하고 정보를 판단하기

Clash 생태계는 프로젝트가 많고 이름이 자주 바뀌어, 검색으로 찾은 튜토리얼이 이미 아카이브된 옛 프로젝트를 기준으로 작성된 경우가 흔하며 그대로 따라 하면 함정에 빠지기 쉽습니다. 어떤 코어가 활발히 유지되고 있는지, 어떤 클라이언트가 그것을 기반으로 하는지, 어떤 프로젝트가 유지 관리를 멈췄는지에 대한 계보를 파악해두면 튜토리얼의 시의성을 빠르게 판단할 수 있습니다. 오픈소스 계보 정리를 시작점으로 삼고, 이후에는 재게시된 글보다 각 프로젝트의 릴리스 페이지를 직접 확인하세요.

추천 학습 순서

1. 튜토리얼 페이지로 기본 흐름을 익히고 2주 동안 안정적으로 사용해보세요.
2. 6장으로 돌아가 구독에 포함된 규칙 목록을 이해하고, 실제로 마주친 라우팅 오류 하나를 수정해보세요.
3. TUN을 켜고 fake-ip를 이해하여, 커맨드라인과 전역 시나리오까지 포함해보세요.
4. 설정 오버라이드를 도입해 자신만의 규칙 계층을 만들어보세요.
5. 여유 있는 기기에 순수 코어를 배포하여 사용자에서 관리자로 전환을 완성하세요.

각 단계는 이전 단계에서 쌓은 익숙함을 바탕으로 하므로 단계를 건너뛰지 않는 것이 좋습니다. 구체적인 용어가 필요할 때는 용어 설명을 참고하고, 클라이언트 관련 궁금증은 비교 평가를 확인하며, 도구 자체는 언제든 다운로드 페이지에서 받을 수 있습니다.