Clash 완전 정복: 설치, 구독, 규칙 분할 매뉴얼

이 매뉴얼은 학습 순서대로 구성되어 있으며 앞 장이 뒷 장의 전제가 됩니다. 커널과 클라이언트의 역할 분담을 먼저 파악해야 뒤에 나오는 각 설정 항목이 어디에 속하는지 이해할 수 있고, 구독을 먼저 가져와야 규칙과 TUN이 조정할 대상이 생깁니다. 처음에는 순서대로 한 번 읽어 보고, 이후에는 참고 매뉴얼처럼 필요한 장을 위 목차에서 바로 찾아보세요. 본문의 모든 설정 예시는 config.yaml의 해당 섹션에 그대로 복사할 수 있으며, 예시에 나오는 서버 주소와 비밀번호, 구독 링크는 모두 자리 표시자 값으로 실제 사용 시에는 구독이나 직접 운영하는 서버에서 제공됩니다.

핵심 개념: Clash, 커널, 클라이언트의 관계

Clash라는 단어는 문맥에 따라 세 가지를 가리킵니다. 규칙 기반 프록시의 설정 규격, 그 규격을 구현한 커널 프로그램, 그리고 그 위에 그래픽 인터페이스를 얹은 클라이언트입니다. 초보자가 가장 많이 막히는 지점은 'Clash 하나 다운로드'를 '프로그램 하나 다운로드'로 이해하는 것입니다. 실제로 매일 클릭해서 쓰는 것은 GUI 클라이언트이고, 연결을 맺고 도메인을 해석하며 규칙에 따라 데이터를 전달하는 것은 커널입니다. 이 두 계층의 역할 분담을 이해하면 이후 설정 항목이 어디에 놓이는지, 왜 어떤 설정은 바꾼 뒤 커널을 재시작해야 하는지가 자연스럽게 풀립니다.

커널: 트래픽을 실제로 처리하는 계층

커널은 인터페이스가 없는 명령줄 프로그램입니다. 시작할 때 YAML 설정 파일 하나를 읽고 네 가지 일을 합니다. 로컬 포트를 열어 애플리케이션이 보내는 연결을 받고, 설정에 있는 노드 정보를 사용 가능한 아웃바운드로 구성하고, rules 항목을 따라 각 연결이 어느 아웃바운드로 나갈지 결정하고, 그 결정 과정을 로그에 기록합니다.

mihomo(구 Clash Meta)가 현재 커뮤니티에서 유지보수하는 메인라인 커널이며, 원본 Clash 커널은 유지보수가 중단되어 새로 나오는 클라이언트는 대부분 mihomo 기반입니다. 커널 자체는 구독을 관리하지 않습니다. 설정을 스스로 내려받지도, 자동으로 업데이트하지도 않으며 시작할 때 읽은 그 파일만 인식합니다. 설정 파일이 바뀌면 다시 로드하거나 커널을 재시작해야 적용됩니다.

GUI 클라이언트: 설정 관리와 사용자 인터페이스

GUI 클라이언트는 커널 바깥의 모든 일을 담당합니다. 구독 링크를 config.yaml로 내려받고, 모드와 노드를 전환하는 스위치를 제공하고, 커널 로그를 읽기 쉬운 패널로 보여주고, 시스템 트레이나 알림 영역에 상주하고, 부팅 시 커널을 실행합니다. 같은 설정 파일이라도 클라이언트마다 보여주는 방식은 다르지만 결국 파일을 커널에 넘겨 실행한다는 점은 같습니다.

여기서 아주 실용적인 결론이 하나 나옵니다. 클라이언트를 바꿔도 구독 링크는 보통 그대로 쓸 수 있고, 다시 맞춰야 하는 것은 클라이언트 자체 설정, 즉 포트 번호와 TUN 스위치, 규칙 재정의 위치뿐입니다. 노드 정의는 클라이언트 안에 있지 않으므로 껍데기를 바꿔도 노드를 다시 만들 필요가 없습니다.

설정 파일의 3계층 구조

일반적인 config.yaml은 세 부분으로 나뉩니다. 기본 설정(포트, 모드, 로그 레벨, DNS), 아웃바운드 정의(proxies와 proxy-groups), 분할 규칙(rules)입니다. 파일 안에서 세 부분의 순서는 바꿀 수 있지만 논리 관계는 고정입니다. 먼저 어떤 노드와 출구 그룹이 있는지 정의하고, 그다음 어떤 트래픽이 어느 출구로 나갈지 정합니다.

mixed-port: 7890
mode: rule
log-level: info

proxies:
  - name: "node-a"
    type: ss
    server: 203.0.113.10
    port: 8443
    cipher: aes-128-gcm
    password: "your-password"

proxy-groups:
  - name: "PROXY"
    type: select
    proxies: ["node-a", "DIRECT"]

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

예시의 203.0.113.10은 문서용 예약 주소이며, 실제 설정에서 server와 password는 구독이 제공하므로 직접 적을 필요가 없습니다. 이 예시는 이미 최소 실행 골격입니다. 로컬 7890 포트로 연결을 받고, 규칙 모드로 동작하며, 수동 선택 그룹 하나와 위에서 아래로 매칭되는 규칙 세 개가 있습니다.

이 매뉴얼과 빠른 시작 가이드의 역할 분담

빠른 시작 가이드는 구독 가져오기, 모드 선택, 연결 확인이라는 3단계 흐름으로 최대한 빨리 작동시키는 것이 목표입니다. 이 페이지는 체계적인 참고 매뉴얼로, 같은 9단계를 다루되 각 단계에서 원리와 파라미터 의미, 경계 상황, 문제 해결 분기를 함께 설명합니다. 처음 설치할 때는 가이드 페이지를 따라 흐름을 끝까지 가 보고, '왜 이렇게 설정하는가'라는 의문이 생기면 이 페이지의 해당 장으로 돌아오세요.

클라이언트 선택: 플랫폼과 유지보수 상태로 거르기

세 가지 판단 기준

첫째는 커널입니다. 클라이언트가 mihomo 기반인지, Clash 설정 문법과 호환되는지에 따라 해석할 수 있는 필드가 달라집니다. 원본 Clash 커널 기반 클라이언트는 새로운 프로토콜과 규칙 유형을 따라가지 못하며, 구독에 모르는 필드가 있으면 바로 오류를 내거나 조용히 무시합니다. '구독 업데이트는 성공했는데 노드가 절반으로 줄었다'는 증상이 여기서 나옵니다.

둘째는 유지보수 상태입니다. 클라이언트의 업데이트 주기가 새 운영체제 버전에 얼마나 빨리 적응하는지를 결정합니다. 유지보수가 중단된 클라이언트도 여전히 실행되지만, 운영체제가 업데이트되거나 커널에 새 기능이 생겨도 수정이 나오지 않으므로 문제가 생기면 직접 해결해야 합니다.

셋째는 기능 범위입니다. 차이가 가장 큰 세 가지는 TUN 모드 지원 여부, 여러 설정을 빠르게 전환할 수 있는지, 규칙 재정의와 병합을 지원하는지입니다. 브라우저 프록시만 쓰는 사용자에게는 첫 번째 항목이 와닿지 않지만, 게임이나 UWP 앱을 프록시로 태워야 하는 사용자는 반드시 확인해야 합니다.

데스크톱: Windows와 macOS

Windows에서는 Clash Plus가 현재 첫 번째 추천이며, 설치 패키지가 x64와 ARM64 두 아키텍처를 지원합니다. Clash Verge Rev와 FlClash는 비슷한 설정 관리 기능을 제공하되 인터페이스 구성 방식이 다릅니다. Clash Nyanpasu는 인터페이스가 더 간결해서 기본 기능만 필요한 사용자에게 맞습니다. Clash for Windows는 유지보수가 중단되어 구형 환경 호환이나 기존 설정 이전 시의 아카이브 선택지로만 남아 있습니다.

macOS에서도 Clash Plus가 첫 번째 추천이고 Clash Verge Rev와 FlClash가 대안입니다. ClashX Meta는 유지보수가 중단되었으므로 여기서 옮겨 오는 사용자는 설정 차이에 주의해야 합니다. 정책 그룹 이름과 DNS 섹션 구조가 새 커널에서 더 엄격해져 예전 설정의 축약 필드는 인식되지 않을 수 있습니다.

모바일: Android와 iOS

Android 생태계에서는 Clash Plus, Clash Meta for Android, FlClash 모두 TUN과 앱별 프록시를 지원합니다. 앱별 프록시는 어떤 앱을 프록시로 보내고 어떤 앱을 다이렉트로 보낼지 정하는 기능으로, 휴대폰에서는 데스크톱보다 훨씬 유용합니다. Surfboard는 다른 설정 형식을 사용하므로 구독을 가져오기 전에 해당 형식 출력을 제공하는지 확인해야 합니다.

iOS는 시스템 제약 때문에 App Store를 통해서만 클라이언트를 설치할 수 있습니다. Clash Plus는 App Store에서 제공되며 공식 사이트 주소는 clashplus.io이고, 설정 가져오기 방식은 다른 iOS 프록시 도구와 비슷하게 시스템 VPN 구성 프로파일을 사용합니다.

Linux와 서버 환경

Linux 데스크톱 배포판에서는 Clash Verge Rev나 FlClash를 쓸 수 있고 deb, rpm 패키지가 모두 있습니다. 서버와 라우터에는 그래픽 인터페이스가 없으므로 mihomo 커널을 직접 사용합니다. 해당 아키텍처의 압축 파일을 내려받아 풀고 명령줄로 실행하면서 systemd 유닛이나 프로세스 감시 스크립트로 상주시키면 됩니다. 이 경로의 장점은 리소스 사용량이 가장 낮다는 것이고, 대가는 모든 설정을 직접 작성해야 한다는 점입니다.

전체적인 비교와 선택 조언은 클라이언트 선택 가이드에 있고, 모든 설치 패키지는 플랫폼별로 다운로드 페이지에 정리되어 있으며 플랫폼 항목을 누르면 해당 섹션으로 바로 이동합니다. 선택 단계에서 너무 고민할 필요는 없습니다. 같은 구독이 대부분의 클라이언트에서 통용되므로 하나 먼저 설치해 쓰면서 실제로 부족한 기능을 기준으로 바꾸면 됩니다.

설치: 시스템 요구 사항, 권한, 첫 실행

설치 전 확인할 세 가지

시스템 버전. Windows 10 1809 이상이 필요하며, 그보다 낮은 버전에서는 시스템 프록시 모드만 쓸 수 있고 가상 네트워크 어댑터 드라이버와 일부 시스템 인터페이스를 사용할 수 없습니다. macOS는 네트워크 확장 메커니즘을 지원하는 비교적 최신 버전이 필요하며, 구형 시스템에서는 TUN 권한을 승인할 수 없습니다. Android는 브라우저나 파일 관리자에서 앱 설치를 허용해야 하고, 일부 ROM은 설치 시 한 번 더 확인합니다. Linux 배포판은 클라이언트가 요구하는 glibc 버전을 충족해야 하며, 너무 오래된 배포판이라면 커널 명령줄 방식을 바로 쓰는 편이 낫습니다.

권한. TUN 모드는 관리자 권한(Windows) 또는 root, 네트워크 확장 승인(macOS, Linux)이 필요합니다. 시스템 프록시 모드만 쓴다면 일반 권한으로 충분합니다. 설치 단계에서는 TUN을 켜지 않고 설정 가져오기를 마친 뒤에 켜는 편이 좋습니다. 변수 두 개가 동시에 바뀌는 상황을 피할 수 있습니다.

네트워크 환경. 첫 실행 시 규칙 세트나 GEOIP 데이터베이스를 내려받아야 할 수 있어 네트워크가 막혀 있으면 클라이언트가 초기화 상태에서 멈춥니다. 접속이 제한된 네트워크라면 클라이언트가 보내는 초기화 요청이 차단되는지 먼저 확인하고, 그다음 오프라인 설정으로 바꿀지 결정하세요.

Windows 설치 순서

• 다운로드 페이지의 Windows 섹션에서 해당 아키텍처의 설치 패키지를 고릅니다. 일반 PC는 x64, ARM 기기는 ARM64를 선택하며, 아키텍처를 잘못 고르면 호환되지 않는다는 안내가 바로 나옵니다.
• 설치 프로그램을 실행하고 설치 경로는 기본값 그대로 두면 됩니다.
• 첫 실행 시 관리자 권한 요청이 뜨면 허용하세요. TUN 모드를 위한 가상 네트워크 어댑터 드라이버를 준비하는 과정입니다.
• 실행 후 트레이 아이콘이 나타나는지 확인하고, 오른쪽 클릭 메뉴에 모드 전환, 설정 관리, 종료 세 항목이 보여야 합니다.
• 설치 후 실행되지 않는다면 먼저 시스템이 서명되지 않은 드라이버 설치를 차단했는지, 다음으로 백신이 실행 파일을 격리했는지, 마지막으로 구버전의 서비스 프로세스가 남아 포트를 점유하고 있는지 확인하세요.

macOS와 Linux

macOS는 dmg를 내려받아 응용 프로그램 폴더로 끌어다 놓습니다. 처음 열 때 Gatekeeper가 막으면 '시스템 설정 → 개인정보 보호 및 보안'에서 그래도 열기를 선택하세요. TUN을 켜면 시스템이 네트워크 확장 승인을 요구하는데, 이 단계를 허용하지 않으면 TUN이 트래픽을 가져갈 수 없습니다. 승인했는데도 적용되지 않으면 클라이언트를 한 번 재시작해 확장을 다시 로드하세요.

Linux 데스크톱 배포판은 deb 또는 rpm 패키지를 우선 사용하고, 설치 후 애플리케이션 메뉴에서 실행합니다. 일부 클라이언트는 '인터페이스 + 서비스'가 분리된 구조를 씁니다. 커널이 서비스 신분으로 실행되고 인터페이스가 로컬 API로 이를 제어하므로 인터페이스에 root 권한이 필요 없습니다. 설치 안내에 따라 서비스 구성 요소를 설치하면 됩니다. 서버 환경에서는 GUI를 설치하지 않고 mihomo 커널 압축 파일을 내려받아 푼 뒤 -d로 설정 디렉터리를, -f로 설정 파일을 지정해 실행합니다.

모바일 설치

Android는 APK를 설치한 뒤 첫 실행 시 VPN 권한을 요청합니다. 이 권한이 TUN 모드의 기반이며, 거부하면 시스템 프록시를 수동으로 설정해야 하는데 모바일에서 수동 시스템 프록시 설정은 경험이 좋지 않습니다. iOS는 App Store에서 설치한 뒤 처음 연결할 때 VPN 구성 프로파일 추가를 안내하므로, 안내에 따라 시스템 설정에서 허용하고 클라이언트로 돌아와 구독을 가져오면 됩니다.

첫 설치에서 자주 걸리는 문제(권한, 포트, 시스템 프록시 세 가지)는 블로그 《Clash 첫 설치와 초기 설정》에 정리해 두었으니 설치 후 한 번 대조해 보세요.

구독 가져오기: 링크, 호스팅 설정, 로컬 파일

구독 링크의 본질

구독은 URL 하나입니다. 클라이언트가 요청하면 YAML 설정이나 인코딩된 노드 목록이 돌아옵니다. Clash 계열 클라이언트는 Clash 형식(YAML)이 필요하므로, 서비스 제공자가 범용 형식을 준다면 먼저 변환하거나 해당 형식 출력을 지원하는 구독을 선택해야 합니다. 링크에는 보통 신원 식별용 쿼리 파라미터가 붙기 때문에 링크 자체가 자격 증명입니다. 공개적으로 공유하지 말고 스크린샷에 전체 파라미터를 노출하지 마세요.

가져오기 작업 순서

• 구독 링크를 물음표 뒤 파라미터까지 전부 복사합니다.
• 클라이언트의 설정 또는 구독 페이지를 열고 새 설정 항목을 만듭니다. 클라이언트마다 이 메뉴를 Profiles, 구독, 설정, 노드 등으로 부르며 위치는 보통 사이드바 첫 항목입니다.
• 링크를 붙여 넣고 이름을 지정합니다. 이름은 로컬 표시에만 영향을 주고 연결에는 영향이 없습니다.
• 다운로드 또는 업데이트를 눌러 설정 가져오기가 끝날 때까지 기다립니다. 이 단계에서 노드 목록과 규칙을 함께 가져오므로 네트워크 상태가 나쁘면 한 번 더 시도해야 할 수 있습니다.
• 이 설정을 선택해 커널이 로드하도록 합니다.
• 프록시 페이지로 돌아가 노드 목록이 나타났는지 확인하고 아무 노드나 하나 선택합니다.

호스팅 설정과 로컬 수정의 충돌

원격 구독은 업데이트할 때마다 로컬 파일을 통째로 덮어쓰므로 구독으로 내려받은 config.yaml을 직접 수정하면 다음 업데이트에서 사라집니다. 초보자가 가장 자주 좌절하는 지점입니다. 30분 들여 작성한 규칙이 하룻밤 사이에 없어집니다. 대응 방법은 세 가지입니다.

• 클라이언트에 내장된 재정의 또는 병합 기능을 씁니다. 사용자 지정 규칙을 별도 재정의 파일에 작성해 두면 구독 업데이트 시 자동으로 병합되고 원본 구독은 그대로 유지됩니다.
• 로컬 설정. 구독 내용을 로컬 파일로 따로 저장한 뒤 직접 관리합니다. 완전히 통제할 수 있다는 장점이 있고, 노드 목록이 자동으로 갱신되지 않는다는 것이 대가입니다.
• 직접 호스팅. 전체 설정을 직접 관리하고 구독의 노드 섹션은 proxy-providers로 가져오며 규칙과 정책 그룹은 모두 직접 작성합니다.

proxy-providers:
  provider-a:
    type: http
    url: "https://example.com/subscribe?token=xxxx"
    interval: 86400
    path: ./providers/provider-a.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300

interval 단위는 초이며 86400은 하루에 한 번 업데이트한다는 뜻입니다. health-check는 노드 지연 테스트의 대상 주소와 주기를 정합니다. provider로 노드를 가져오면 proxy-groups에서 노드 이름을 하나씩 나열하는 대신 use: ["provider-a"]로 참조합니다. 구독이 업데이트되어 노드가 바뀌어도 정책 그룹은 수정할 필요가 없습니다.

업데이트 실패 시 대처

먼저 클라이언트 로그에서 구독 요청의 응답 코드를 봅니다. 401이나 403은 대개 링크 만료, 파라미터 변경, 또는 서비스 제공자가 현재 IP를 제한한 경우입니다. 요청 시간 초과는 로컬에서 구독 서버까지의 구간이 막힌 것이고, 응답 내용 파싱 실패는 받은 내용이 Clash 형식이 아니라는 뜻으로 서비스 제공자가 클라이언트 종류에 따라 다른 형식을 돌려줬을 수 있습니다. 업데이트 후 일부 노드만 바뀌었다면 정상입니다. 서비스 제공자가 노드를 조정하는 것은 일상적인 일이라 따로 처리할 필요가 없습니다.

여러 기기에서 설정을 일관되게 유지하는 방법은 블로그 《Clash 멀티 디바이스 설정 동기화》를 참고하세요. 세 가지 방식의 적용 상황과 유지보수 비용 비교를 그 글에 정리했습니다.

프록시 모드: 규칙, 글로벌, 다이렉트, 시스템 프록시

세 가지 모드의 역할

규칙 모드(rule)는 rules 항목을 위에서부터 하나씩 매칭해 걸린 규칙을 따르며, 일상에서는 기본으로 이 모드를 씁니다. 글로벌 모드(global)는 모든 트래픽을 현재 선택한 노드로 보내고 규칙을 무시합니다. 이 모드의 가치는 문제 확인에 있습니다. 규칙이 잘못됐다는 의심이 들 때 글로벌로 바꿔서 연결이 정상이라면 문제는 규칙에 있습니다. 다이렉트 모드(direct)는 모든 트래픽을 프록시 없이 보내 클라이언트 자체의 영향을 배제할 때 씁니다. 다이렉트에서도 안 되면 문제는 프록시 경로에 있지 않습니다.

세 가지 모드는 설정 파일에서 mode 필드로 정해지며, 클라이언트 화면에서 임시로 바꿀 수도 있지만 재시작하면 설정 파일 값이 기준이 됩니다.

시스템 프록시와 TUN의 차이

시스템 프록시는 클라이언트가 운영체제의 프록시 설정(Windows의 인터넷 옵션, macOS의 네트워크 환경설정)을 바꾸는 방식으로, 시스템 프록시를 따르는 프로그램에만 적용됩니다. 브라우저와 대부분의 명령줄 도구는 따르지만, 일부 게임과 UWP 앱, 자체적으로 네트워크 스택을 구현한 소프트웨어는 영향을 받지 않고 트래픽이 그대로 나갑니다.

TUN 모드는 가상 네트워크 어댑터를 만들고 시스템 라우팅 테이블의 기본 경로를 그쪽으로 돌려 모든 IP 계층 트래픽을 커널이 가져갑니다. 앱이 시스템 프록시를 따르는지와 무관합니다. 대가는 관리자 권한이 필요하고 일부 VPN, 가상 머신 네트워크와 라우팅 충돌이 생길 수 있다는 점입니다.

또 다른 차이는 DNS입니다. 시스템 프록시 모드에서는 앱의 DNS 질의를 시스템이 처리하지만, TUN 모드에서는 DNS도 커널이 가져갑니다. 그래야 Fake-IP와 함께 도메인 기반 규칙 매칭을 할 수 있으며, 이 내용은 7장에서 자세히 다룹니다.

포트와 컨트롤 인터페이스

mixed-port는 HTTP와 SOCKS5 두 프로토콜을 동시에 제공하는 현재 권장 단일 진입점입니다. 예전 설정에는 port(HTTP)와 socks-port(SOCKS5) 두 필드로 나뉘어 있을 수 있습니다. external-controller는 컨트롤 인터페이스로, 패널이 이를 통해 연결 목록과 로그를 읽습니다. 기본값은 127.0.0.1만 수신하므로 로컬에서만 접근할 수 있습니다. 같은 LAN의 다른 기기에서 패널에 접근해야 한다면 수신 주소를 0.0.0.0으로 바꾸고 secret을 설정하세요. 그렇지 않으면 컨트롤 인터페이스를 LAN 전체에 열어 두는 셈입니다.

mixed-port: 7890
allow-lan: false
external-controller: 127.0.0.1:9090
secret: "your-password"
mode: rule
log-level: info

allow-lan은 LAN 기기가 이 컴퓨터를 통해 인터넷에 나갈 수 있는지를 정하며 external-controller와는 다른 항목입니다. 전자는 프록시 포트를, 후자는 컨트롤 인터페이스를 여는 설정입니다.

선택 순서 권장

먼저 시스템 프록시와 규칙 모드로 연결을 성공시키고 노드가 쓸 만한지, 브라우저가 정상적으로 열리는지 확인한 다음, 적용되지 않는 프로그램이 있을 때 TUN을 켜세요. 처음부터 TUN을 켜지 마세요. 문제가 생기면 노드, DNS, 가상 네트워크 어댑터, 라우팅 테이블 네 가지를 동시에 따져야 해서 원인 파악 비용이 훨씬 커집니다. 노드가 연결되지 않을 때의 일곱 단계 점검은 블로그 《Clash 노드 시간 초과로 연결 불가》에 정리해 두었습니다.

규칙 분할: rules 문법, 정책 그룹, 우선순위

매칭 방식: 위에서 아래로, 일치하면 종료

커널은 rules 배열의 첫 항목부터 하나씩 비교하고, 처음 일치한 규칙이 그 연결의 목적지를 결정하며 뒤 규칙은 관여하지 않습니다. 따라서 배열 순서가 곧 우선순위입니다. 범위가 가장 좁고 명확한 규칙을 앞에, 넓은 기본 처리를 마지막에 둡니다. MATCH는 반드시 마지막 항목이어야 하며, 앞에 두면 그 뒤의 모든 규칙이 무효가 됩니다. 규칙을 잘못 쓴 경우 중 결과가 가장 심각한 유형입니다.

자주 쓰는 규칙 유형

• DOMAIN: 도메인을 정확히 일치시켜 적어 둔 그 하나만 해당합니다.
• DOMAIN-SUFFIX: 도메인 접미사를 매칭해 example.com이 a.example.com과 b.example.com에 모두 해당합니다.
• DOMAIN-KEYWORD: 도메인에 키워드가 포함되면 매칭되는 넓은 범위의 규칙으로, 엉뚱한 도메인까지 걸리기 쉬워 신중히 사용하세요.
• IP-CIDR: 대상 IP 대역을 매칭합니다. 순수 IP 규칙은 DNS 해석 결과를 먼저 받아야 판단할 수 있으므로 no-resolve를 붙이면 규칙 매칭을 위해 해석을 한 번 더 하는 일을 피할 수 있습니다.
• GEOIP: IP 소재지로 매칭하며, 주로 중국 본토 주소를 다이렉트로 보낼 때 쓰고 보통 도메인 규칙 뒤에 둡니다.
• PROCESS-NAME: 연결을 시작한 프로그램 이름으로 매칭하며 데스크톱에서는 쓸 수 있지만 모바일에서는 대개 지원하지 않습니다.
• RULE-SET: 외부 규칙 세트 파일을 참조해 수백, 수천 개 규칙을 별도 파일에서 관리합니다.
• MATCH: 남은 모든 연결을 처리하는 기본 규칙으로 반드시 마지막에 둡니다.

정책 그룹: 규칙이 가리키는 출구

proxy-groups는 규칙이 가리킬 수 있는 출구 그룹을 정의하며, 그룹 안에는 노드를 넣을 수도 있고 다른 그룹을 넣을 수도 있습니다. 자주 쓰는 네 가지 유형은 다음과 같습니다. select는 수동 선택으로 화면에서 고른 것을 사용하고, url-test는 주기적으로 그룹 내 노드 속도를 측정해 지연이 가장 낮은 노드를 자동 선택하며, fallback은 순서대로 첫 번째 사용 가능한 노드를 고르고, load-balance는 여러 노드에 연결을 분산합니다.

그룹은 중첩할 수 있습니다. 흔한 3계층 구조는 '수동 선택 그룹 → 자동 속도 측정 그룹 → 개별 노드'이며, 평소에는 자동 속도 측정 그룹을 쓰고 특정 노드를 지정해야 할 때 수동 그룹에서 바꿉니다.

proxy-groups:
  - name: "PROXY"
    type: select
    proxies: ["AUTO", "DIRECT"]
  - name: "AUTO"
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies: ["node-a", "node-b"]

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - DOMAIN-KEYWORD,analytics,DIRECT
  - IP-CIDR,203.0.113.0/24,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

tolerance는 전환 임계값(밀리초)입니다. 새 노드의 지연이 현재 노드보다 이 값 이상 낮아야 전환하므로 지연이 비슷한 두 노드 사이에서 계속 오가는 현상을 막습니다. interval은 속도 측정 주기(초)이며, 너무 짧게 잡으면 성능이 낮은 기기가 계속 측정 요청을 돌리게 됩니다.

자주 하는 실수

• MATCH를 중간에 둠: 뒤의 모든 규칙이 죽은 코드가 됩니다.
• GEOIP를 구체적인 도메인 규칙보다 앞에 둠: 프록시로 보내야 할 도메인이 중국 본토 주소로 판정되어 다이렉트로 나갑니다.
• IP-CIDR에 no-resolve를 붙이지 않음: 연결마다 DNS 해석을 한 번씩 하느라 지연이 늘어납니다.
• 규칙이 존재하지 않는 정책 그룹 이름을 가리킴: 커널이 오류를 내거나 연결이 거부되며 로그에 분명한 안내가 남습니다.
• 유형 이름의 대소문자 혼용: domain-suffix는 인식되지 않으며 유형 이름은 반드시 대문자여야 합니다.
• 규칙 세트 파일 경로 오타: 시작할 때 조용히 건너뛰어, 해당 규칙 세트가 담당하던 도메인이 전부 기본 규칙으로 흘러갑니다.

항목별 해설과 더 많은 작성 예시는 블로그 《Clash 사용자 지정 규칙 문법과 우선순위》를 참고하세요.

TUN 모드: 가상 네트워크 어댑터, DNS, Fake-IP

TUN이 하는 일

활성화하면 커널이 가상 네트워크 어댑터(Windows에서는 Wintun, macOS와 Linux에서는 utun 또는 tun)를 만들고 시스템 기본 경로를 그쪽으로 돌립니다. 앱이 보낸 패킷은 먼저 가상 어댑터로 들어오고, 커널이 읽어 규칙에 따라 처리한 뒤 다이렉트로 보낼지 프록시로 보낼지 결정합니다. IP 계층에서 동작하므로 앱이 시스템 프록시 설정을 따르는지에 의존하지 않아 게임, UWP 앱, 자체 네트워크 스택을 구현한 소프트웨어까지 모두 처리할 수 있습니다.

대가도 같은 계층에서 나옵니다. 라우팅 테이블이 바뀌므로 VPN, 가상 머신, 다중 네트워크 어댑터 환경과 충돌할 수 있습니다.

핵심 설정 항목

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

stack은 사용자 공간 프로토콜 스택 구현을 정합니다. system은 성능이 좋지만 호환성이 보통이고, gvisor는 호환성이 좋지만 처리량이 조금 낮으며, mixed는 커널이 상황에 따라 알아서 고릅니다. auto-route는 커널이 라우팅 테이블을 자동으로 쓰게 하고, auto-detect-interface는 물리 출구 네트워크 어댑터를 자동으로 인식합니다. 이 두 항목은 네트워크 어댑터가 여러 개인 컴퓨터에서 특히 중요하며, 꺼 두면 돌아오는 트래픽이 엉뚱한 어댑터로 나가 연결은 되지만 속도가 매우 느리거나 자주 끊기는 증상이 나타납니다. dns-hijack은 53번 포트로 가는 DNS 질의를 커널이 가로채 처리하게 하며, TUN 모드에서 DNS가 새지 않기 위한 전제 조건입니다.

DNS와 Fake-IP

TUN 모드에서는 DNS를 반드시 커널이 처리해야 합니다. 그렇지 않으면 앱이 실제 IP를 직접 해석해 버려 규칙의 도메인 매칭이 무력해집니다.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "+.pool.ntp.org"
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

Fake-IP의 동작 방식은 이렇습니다. 커널이 DNS 질의를 받으면 즉시 198.18.x.x 대역의 가짜 주소를 돌려주고, 그 가짜 주소가 어느 도메인에 대응하는지 기록합니다. 앱이 그 가짜 주소로 연결하면 커널이 매핑 테이블에서 도메인을 꺼내 규칙 매칭에 사용합니다. 장점은 두 가지입니다. 앱이 먼저 해석한 뒤 연결하더라도 규칙 매칭이 항상 도메인 기준으로 이뤄지고, 실제 해석을 기다리는 시간이 없어 첫 연결이 더 빠릅니다.

fake-ip-filter에 있는 도메인은 Fake-IP를 쓰지 않고 실제 주소를 돌려줍니다. LAN 기기 이름, NTP 시간 서버, 실제 IP가 필요한 일부 LAN 서비스는 반드시 넣어야 합니다. 그렇지 않으면 웹페이지는 열리는데 LAN 기기에 접속되지 않는 식의 이상한 현상이 생깁니다. nameserver에는 로컬에서 도달 가능한 DNS 서버를 적고, 이미 프록시로 처리되는 주소를 적지 마세요. 해석 요청이 한 바퀴 돌아 자기 자신에게 돌아오는 루프가 생깁니다.

자주 발생하는 문제

• 켠 뒤 인터넷이 전혀 안 됨: 먼저 로그에서 가상 네트워크 어댑터가 정상 생성됐는지 보고, 다음으로 auto-detect-interface가 물리 어댑터를 제대로 인식했는지 확인한 뒤, 마지막으로 다른 VPN이 라우팅을 가로채고 있는지 점검하세요.
• 일부 앱만 이상함: 해당 앱을 fake-ip-filter에 추가하거나 규칙에서 다이렉트로 지정하세요.
• Windows에서 UWP 앱이 적용되지 않음: UWP 앱은 앱 컨테이너에서 실행되므로 루프백 예외를 켜야 하며, 클라이언트가 보통 해당 스위치를 제공합니다.
• 가상 머신과 충돌: 가상 머신의 가상 네트워크 어댑터가 TUN 라우팅 규칙의 영향을 받으므로 제외 목록에 추가하거나 시간을 나눠 사용해야 합니다.

노드 시간 초과의 전체 점검 순서는 블로그 《Clash 노드 시간 초과로 연결 불가》를 참고하세요.

일상 유지보수: 업데이트, 로그, 멀티 디바이스 동기화

구독 업데이트

업데이트 주기는 서비스 제공자의 노드 변동 빈도에 따르며 하루 한 번이 흔한 설정입니다. 업데이트하면 클라이언트가 설정을 다시 로드하므로 진행 중이던 연결이 잠깐 끊깁니다. 노드 목록이 오랫동안 그대로라면 먼저 수동으로 업데이트를 한 번 실행하고 로그의 응답 내용을 확인하세요. 업데이트는 성공했는데 노드가 그대로라면 서비스 제공자가 실제로 조정하지 않은 것입니다.

로그와 연결 패널

log-level은 silent, error, warning, info, debug 순으로 점점 자세해집니다. 문제를 볼 때는 임시로 debug로 올려 연결이 맺어질 때 커널이 내린 실제 결정, 즉 어느 규칙이 걸렸고 어느 출구로 나갔고 해석 실패가 있었는지 확인하세요. 평소에는 info면 충분합니다. debug는 로그 양을 크게 늘려 성능이 낮은 기기에서 오래 켜 두면 느려집니다.

external-controller가 제공하는 인터페이스를 패널이 읽어 각 연결의 매칭 규칙, 출구 노드, 업로드·다운로드 바이트 수를 보여줍니다. 규칙이 의도대로 적용되는지 판단할 때는 로그보다 연결 패널이 더 직접적입니다. 해당 연결을 찾아 매칭된 규칙 번호와 출구 그룹 이름을 작성해 둔 규칙과 대조하세요.

멀티 디바이스 동기화

구독 링크 동기화: 모든 기기가 같은 링크를 가져오면 노드 목록이 자동으로 일치합니다. 노드 중심이고 로컬 사용자 지정이 적은 환경에 맞으며, 대가는 기기마다 규칙 설정이 따로 놀아 한 곳을 고쳐도 다른 기기로 동기화되지 않는다는 점입니다.

직접 설정 호스팅: 전체 설정을 직접 관리하고 모든 기기가 같은 주소를 가져오면 규칙과 정책 그룹이 완전히 일치합니다. 기기가 여러 대이고 규칙이 복잡한 환경에 맞지만 유지보수 비용이 가장 큽니다. 설정에 문제가 생기면 모든 기기가 영향을 받습니다.

수동 내보내기·가져오기: 설정 파일을 LAN이나 클라우드 저장소로 다른 기기에 전달합니다. 자주 바뀌지 않는 환경에 맞고, 앞의 두 방식의 백업 수단으로도 적합합니다.

리소스 사용량과 안정성

규칙 항목 수는 연결마다의 매칭 소요 시간에 직접 영향을 줍니다. 수천 개 규칙은 데스크톱에서는 거의 체감되지 않지만 라우터처럼 성능이 낮은 기기에서는 규모를 조절해야 하므로, 큰 덩어리의 규칙은 RULE-SET으로 나눠 필요할 때 로드하세요. GEOIP 데이터베이스는 커널과 함께 업데이트되므로 직접 교체할 필요가 없습니다. 메모리 사용량은 활성 연결 수와 DNS 캐시 규모에 좌우되며, 오래 실행한 뒤 메모리가 계속 늘어난다면 url-test 그룹이 자주 속도를 측정하고 있는지, 로그 레벨이 계속 debug로 남아 있는지 먼저 확인하세요.

멀티 디바이스 동기화 세 가지 방식의 전체 비교는 블로그 《Clash 멀티 디바이스 설정 동기화》를 참고하세요.

심화 과정: 커널 기능, 직접 설정, 문제 해결 방법

mihomo가 가져온 변화

mihomo는 원본 Clash를 기반으로 인바운드 유형, 규칙 유형, DNS 기능을 확장했습니다. 더 많은 인바운드 프로토콜, 더 많은 규칙 매칭 축(프로세스, 규칙 세트, 논리 조합), 더 세밀한 DNS 정책, 더 완성도 높은 TUN 구현이 그것입니다. 구독에 원본 커널이 모르는 필드가 있으면 mihomo 기반 클라이언트로 바꾸면 해석됩니다. 원본 Clash 커널은 유지보수가 중단되었으므로 장기적으로 쓸 생각이라면 처음부터 mihomo 계열 클라이언트로 시작하는 편이 좋습니다.

구독 사용자에서 설정 관리자로

심화의 첫걸음은 구독을 완성된 설정이 아니라 노드 공급원으로 보는 것입니다. 방법은 4장에서 이미 제시했습니다. proxy-providers로 노드를 가져오고 규칙, 정책 그룹, DNS는 모두 직접 작성합니다. 장점은 서비스 제공자를 바꿀 때 provider 주소만 고치면 되고 규칙 체계는 건드릴 필요가 없다는 점, 그리고 구독 쪽 기본 규칙에 묶이지 않고 자신의 사용 습관에 맞게 규칙을 세밀하게 조정할 수 있다는 점입니다.

두 번째 단계는 규칙 세트의 관리 방식을 이해하는 것입니다. 큰 덩어리의 규칙을 RULE-SET이 참조하는 외부 파일로 나누고 주기적으로 업데이트하며 메인 설정은 간결하게 유지합니다. 규칙 세트의 장점은 업데이트할 때 메인 설정에 영향이 없다는 것이고, 단점은 파일 의존성이 한 겹 늘어 경로를 잘못 쓰면 조용히 무효가 된다는 것입니다.

세 번째 단계는 설정을 버전 관리에 넣는 것입니다. 수정 전마다 백업을 남기고 변경 기록을 분명히 적어 둡니다. 설정에 문제가 생겼을 때 한 줄씩 대조하는 것보다 훨씬 빠르게 되돌릴 수 있습니다.

재사용할 수 있는 문제 해결 순서

1. 구독: 최근 업데이트가 성공했는지, 노드 목록이 비어 있지 않은지.
2. 노드: 글로벌 모드로 바꿔 노드 하나만 따로 테스트해 규칙 요인을 배제.
3. DNS: Fake-IP가 켜져 있는지, filter가 엉뚱한 도메인을 걸고 있지 않은지, 해석이 정상인지.
4. 포트: 로컬 포트를 다른 프로그램이 점유하고 있지 않은지.
5. 시스템 프록시 또는 TUN: 스위치 상태가 실제 기대와 일치하는지.
6. 규칙: 연결 패널에 보이는 것이 기대한 정책 그룹인지.
7. 로그: 위 여섯 단계의 관찰 결과와 로그를 대조해 실제 문제가 있는 계층을 찾기.

이 순서의 가치는 각 단계가 한 종류의 요인을 배제한다는 데 있습니다. 모든 단계를 동시에 의심하는 것이 아닙니다. 일곱 단계를 다 거쳐도 연결되지 않는다면 문제는 더 아래 계층(물리 네트워크, 서버, 시스템 방화벽)에 있으므로 로그를 들고 서비스 제공자나 클라이언트 커뮤니티에 도움을 요청하면 됩니다.

더 깊이 들어갈 방향

• 커널 설정 문서: 각 설정 항목의 기본값을 이해하는 것이 권장값을 외우는 것보다 유용합니다.
• 규칙 세트 생태계: 흔히 쓰이는 규칙 세트의 관리 방식과 업데이트 주기를 파악하고 활발히 유지보수되는 출처를 고르세요.
• 네트워크 기초: DNS 해석 경로, 라우팅 테이블, TCP 핸드셰이크. 문제 해결에 가장 유용한 세 가지 지식입니다.
• 자동화: 스크립트로 설정 버전과 규칙 업데이트를 관리하고 변경 사항을 기록하세요.

커널 차이의 구체적인 비교는 블로그 《mihomo 커널과 원본 Clash 차이》에, 첫 설치 점검 목록은 블로그 《Clash 첫 설치와 초기 설정》에 있습니다. 클라이언트 비교를 먼저 보고 싶다면 클라이언트 선택 가이드로, 결정했다면 다운로드 페이지에서 해당 플랫폼 설치 패키지를 받고, 첫 설정은 빠른 시작 가이드를 따라 한 번 진행하면 됩니다.