Clash 완전 정복: 설치 설정과 규칙 분류 완전 가이드

Clash 계열 클라이언트를 뜯어보면 본질적으로 세 가지 일만 합니다: 로컬 컴퓨터에 리스닝 포트를 열어 트래픽을 받고, 정해진 규칙에 따라 각 연결이 어느 경로로 갈지 판단하고, 프록시로 결정된 연결을 원격 노드로 전달하는 것입니다. 이후 장에서 등장하는 모든 설정 항목은 이 세 가지 중 하나로 귀결됩니다. 이 장에서는 아무것도 조작하지 않고 이후에 필요한 수준까지만 개념을 다룹니다.

프록시 클라이언트가 하는 일

클라이언트를 실행하면 로컬 컴퓨터에서 하나 이상의 포트를 리스닝하는데, 가장 흔한 형태는 HTTP와 SOCKS5를 함께 지원하는 혼합 포트입니다. 운영체제나 브라우저가 네트워크 요청을 이 포트로 보내면 클라이언트는 요청을 받아 규칙표를 확인합니다: 직접 연결 규칙에 걸리면 로컬 네트워크 카드로 바로 나가고, 프록시 규칙에 걸리면 캡슐화하여 원격 프록시 서버로 전달해 서버가 대신 접속하게 합니다. 시스템의 다른 프로그램 입장에서는 클라이언트가 일반적인 로컬 프록시로 보이고, 대상 웹사이트 입장에서는 접속 출처가 원격 노드로 보입니다.

초보자가 가장 자주 혼동하는 부분: 클라이언트를 설치했다고 해서 프록시 능력이 생기는 건 아닙니다. 클라이언트 자체에는 노드가 포함되어 있지 않으며, 클라이언트는 '스케줄러' 역할만 합니다. 노드는 구독이나 수동 추가를 통해 들어오며, 이것이야말로 트래픽의 '출구'입니다. 두 가지 모두 필요하며, 4장에서 노드가 어떻게 들어오는지 자세히 다룹니다.

커널: mihomo가 현재 주력 버전

Clash 생태계에는 두 가지 커널 계보가 있습니다. 원조 Clash 커널은 이미 업데이트가 중단되어 보관 상태이며, 커뮤니티 주력 계보는 Clash Meta로 시작해 이후 mihomo로 이름이 바뀌었습니다. 본 사이트의 다운로드 센터에서 제공하는 그래픽 클라이언트는 모두 mihomo 기반입니다. mihomo는 원조 버전을 기반으로 더 많은 프록시 프로토콜, 규칙 유형, TUN 강화 기능을 추가했으며 설정 문법은 하위 호환을 유지해 기존 설정 파일을 거의 그대로 옮길 수 있습니다. 두 커널 계보의 상세한 차이는 블로그의 《Clash 커널 차이: 원조 Clash, Clash Meta, mihomo》에서 항목별로 정리했으니, 여기서는 결론만 정리합니다: 새로 설치할 때는 무조건 mihomo 계열 클라이언트를 선택하세요.

노드, 규칙, 구독: 세 가지 핵심 요소

노드(Proxy)는 원격 프록시 서버 한 대와 주소, 포트, 프로토콜, 인증 정보 등의 연결 파라미터 묶음입니다. Shadowsocks, VMess, Trojan, Hysteria 등이 흔한 프로토콜이며, 클라이언트가 프로토콜에 따른 캡슐화를 처리하므로 일반 사용자는 캡슐화 세부 사항을 신경 쓸 필요가 없습니다.

규칙(Rule)은 분류 판단 조건으로, '도메인 접미사가 특정 값이면 직접 연결'과 같은 형태입니다. 규칙표는 순서가 있는 목록으로, 6장에서 자세히 다룹니다.

정책 그룹(Proxy Group)은 규칙과 노드 사이의 중간 계층입니다. 규칙은 특정 노드를 직접 가리키지 않고 정책 그룹을 가리키며, 그룹 안에서 어떤 노드를 사용할지 결정합니다. 수동으로 선택할 수도, 자동 속도 측정으로 선택할 수도 있습니다. 5장에서 자세히 다룹니다.

구독(Subscription)은 주기적으로 설정 텍스트를 반환하는 URL로, 이 텍스트 안에 노드, 정책 그룹, 규칙이 함께 담겨 있습니다. 구독만 있으면 위 세 가지가 한 번에 준비되며, 4장에서 자세히 다룹니다.

요청 하나의 전체 경로

브라우저로 웹사이트에 접속하는 경우를 예로 들면: 브라우저가 요청을 시스템 프록시 설정이 지정한 로컬 포트로 넘기고, 클라이언트가 연결을 받아 규칙표를 위에서부터 차례로 비교하며, '프록시' 정책 그룹에 걸리면 그룹이 자체 정책에 따라 노드를 선택하고, 클라이언트가 해당 노드와 암호화 연결을 맺어 요청을 전달하며, 응답은 같은 경로로 돌아옵니다. 이 모든 과정은 로컬 컴퓨터에서 이루어지며 브라우저 입장에서는 전혀 눈치채지 못합니다.

클라이언트에 절대적인 우열은 없으며, 플랫폼과 사용 습관에 맞는지가 중요합니다. 이 장에서는 플랫폼별 선택 결론을 제시하며, 개별 클라이언트의 상세 비교는 클라이언트 비교 페이지에서, 설치 파일은 다운로드 센터에서 플랫폼별로 받을 수 있습니다.

5개 플랫폼별 선택

Windows: 우선 추천은 Clash Plus로, 인터페이스와 커널이 동기화되어 업데이트됩니다. 대안으로 Clash Verge Rev(기능이 풍부한 패널), FlClash(플랫폼 간 통일된 경험), Clash Nyanpasu(독특한 인터페이스)가 있습니다.

macOS: 우선 추천은 Clash Plus로, Apple Silicon과 Intel 두 아키텍처용 설치 파일을 각각 제공합니다. 대안으로 Clash Verge Rev와 FlClash가 있으며 마찬가지로 칩 아키텍처를 구분해야 합니다. 아키텍처를 잘못 설치하면 실행은 되지만 성능이 저하됩니다.

Android: 우선 추천은 Clash Plus입니다. 대안으로 Clash Meta for Android(커널과 동일한 이름의 클라이언트, 업데이트가 빠름), FlClash, Surfboard(매우 심플한 인터페이스)가 있습니다.

iOS: Clash Plus는 App Store에 등록되어 있어 검색해서 바로 설치할 수 있고, 공식 사이트 clashplus.io에 플랫폼별 안내가 있습니다. iOS에서는 프록시 클라이언트가 시스템 수준의 설정 형태로 동작하며, 사용 경험은 데스크톱과 동일합니다.

Linux: 데스크톱 환경에서는 Clash Verge Rev나 FlClash를 사용하며, deb와 rpm 패키지가 제공됩니다. 서버나 라우터 등 인터페이스가 없는 환경에서는 mihomo 커널을 직접 배포하고 설정 파일과 외부 컨트롤러로 관리합니다. 9장에서 자세히 다룹니다.

커널 계보: 원조와 mihomo

원조 Clash 커널의 업데이트가 중단되면서 이를 기반으로 한 대표 클라이언트들도 유지 관리가 중단되었습니다: Windows용 Clash for Windows, macOS용 ClashX Meta가 그 예입니다. 다운로드 페이지에는 이 두 클라이언트를 보관용 참고 자료로만 남겨두었으며 카드에 '유지 관리 중단' 표시가 있습니다. 새로 설치하는 사용자는 과거 이력을 신경 쓸 필요 없이 mihomo 계열의 현재 유지 관리 중인 클라이언트를 바로 선택하면 됩니다. 프로토콜 지원이 가장 풍부하고 규칙 유형도 최신입니다.

유지 관리가 중단된 클라이언트에서 마이그레이션하기

기기에서 아직 Clash for Windows나 ClashX Meta를 사용 중이라면 단기간 계속 사용해도 문제는 없지만, 새로운 프로토콜과 규칙 유형은 더 이상 지원되지 않습니다. 노드가 연결되지 않는 문제가 생기면 이 점을 먼저 의심해 보세요. 마이그레이션 비용은 매우 낮습니다: 기존 구독 링크를 기록해두고 mihomo 계열 클라이언트를 설치한 뒤 구독을 다시 가져오면 됩니다. 구독에 포함된 정책 그룹과 규칙도 자동으로 함께 들어오므로 일일이 옮겨 적을 필요가 없습니다.

이 장에서는 플랫폼별 설치 경로와 설치 후 확인 사항을 다룹니다. 다운로드 링크는 여기서 중복해서 다루지 않으며, 모두 다운로드 센터에서 플랫폼별로 받으세요. 4대 플랫폼의 첫 설치 시 공통 흐름과 초보자가 흔히 겪는 문제는 블로그의 《Clash 첫 설치 및 초기 설정》도 함께 참고하세요.

Windows

.exe 설치 파일을 받아 안내에 따라 설치하면 됩니다. 대부분의 클라이언트는 포터블 버전도 제공하는데, 압축을 풀면 바로 사용할 수 있고 레지스트리를 건드리지 않으므로 USB 이동이나 여러 기기 간 이전에 적합합니다. 시스템 요구 사항은 다운로드 페이지의 각 카드 표시를 기준으로 하며, 주요 클라이언트는 Windows 10 이상을 요구합니다. 첫 실행 시 방화벽 알림이 뜨면 클라이언트가 전용 네트워크와 통신하도록 허용해주세요. 로컬 전용으로 사용하더라도 허용해두는 것이 좋습니다. 나중에 네트워크 문제를 진단할 때 방해 요소를 하나 줄일 수 있습니다.

macOS

칩 아키텍처에 맞는 dmg를 받으세요: Apple Silicon은 arm64 버전, Intel 기종은 x64 버전을 선택합니다. 앱을 '응용 프로그램' 폴더로 끌어다 놓은 뒤 처음 실행할 때 '개발자를 확인할 수 없음'이라는 알림이 뜨면 '시스템 설정 → 개인정보 보호 및 보안'에서 '그래도 열기'를 클릭하세요. 메뉴 막대에 클라이언트 아이콘이 나타나면 실행 성공입니다.

Android와 iOS

Android는 다운로드 페이지에서 apk를 받아 직접 설치하며, 시스템이 '알 수 없는 소스의 앱 설치 허용'을 요구합니다. 설치 후에는 이 권한을 다시 꺼도 됩니다. 처음 연결할 때 시스템이 VPN 연결 요청을 표시하는데, 이는 Android에서 프록시 클라이언트가 동작하는 표준 방식이므로 반드시 허용해야 합니다. 허용하지 않으면 클라이언트가 어떤 트래픽도 처리할 수 없습니다. iOS는 App Store에서 Clash Plus를 설치하며, 첫 설정 추가 시 시스템이 표시하는 VPN 설정 요청도 마찬가지로 허용해야 합니다.

Linux

데스크톱 배포판에서는 deb 또는 rpm 패키지로 Clash Verge Rev나 FlClash를 설치하고, 설치 후 애플리케이션 메뉴에서 실행합니다. 서버와 라우터 환경에서는 그래픽 인터페이스가 필요 없습니다: 해당 아키텍처의 mihomo 커널 바이너리를 받아 config.yaml을 준비하고 systemd로 프로세스를 관리하며 외부 컨트롤러로 제어하면 됩니다. 구체적인 방법은 9장을 참고하세요.

첫 실행 시 확인할 네 가지

설치 후 바로 구독을 가져오지 말고 2분 정도 시간을 내어 다음 네 가지를 확인하세요:

• 인터페이스 언어: 대부분의 클라이언트는 첫 실행 시 설정에서 한국어(또는 원하는 언어) 인터페이스로 전환할 수 있습니다.
• 부팅 시 자동 시작: 설정에서 켜두면 매번 수동으로 실행할 필요가 없습니다.
• 시스템 프록시 스위치의 위치: 먼저 위치를 확인해두세요. 4장에서 구독을 가져온 뒤 이 스위치를 켜야 트래픽이 실제로 클라이언트로 들어갑니다.
• 혼합 포트 번호: 메모해두세요(기본값은 보통 7890). 이후 명령줄 도구를 임시로 프록시로 연결하거나 로컬 네트워크에서 공유할 때 이 포트가 필요합니다.

네 가지를 확인했다면 설치 단계는 끝난 것입니다. 이제 4장에서 구독을 가져와 보세요.

노드, 정책 그룹, 규칙 이 세 가지는 구독 링크 하나로 한 번에 준비됩니다. 이 장에서는 구독이 무엇인지, 어떻게 가져오는지, 어떻게 업데이트하는지, 업데이트가 실패했을 때 어떤 순서로 점검할지를 다룹니다.

구독 링크란

구독 링크는 설정 텍스트를 반환하는 URL로, 텍스트 안에는 노드 목록, 정책 그룹, 규칙표가 들어 있습니다. 클라이언트는 주기적으로 이 URL을 요청해 최신 설정을 받아옵니다. 구독 링크는 노드 서비스 제공자가 제공하며, 클라이언트 자체에는 노드가 포함되어 있지 않습니다. 링크에는 보통 사용자 인증 정보가 담겨 있어 계정 비밀번호와 동일하게 다뤄야 합니다: 공개된 곳에 붙여넣지 말고, 출처가 불명확한 구독은 가져오지 말며, 기기를 바꿀 때는 채팅방에 전달하는 대신 직접 옮기세요.

구독을 가져오는 세 가지 방법

URL 가져오기(가장 흔한 방법): 구독 링크를 복사한 뒤 클라이언트의 '설정/구독' 페이지를 열어 새 프로필을 만들고 URL을 붙여넣은 다음 이름을 지어 저장합니다. 클립보드로 가져오기: 일부 클라이언트는 클립보드에 있는 구독 링크를 인식해 클라이언트를 열면 원클릭 가져오기를 제안합니다. 로컬 파일 가져오기: 이미 config.yaml 파일이 있다면 설정 페이지에서 '로컬 파일 가져오기'를 선택하거나 파일을 클라이언트의 설정 디렉터리에 직접 넣으면 됩니다.

가져오기는 목록에 프로필을 등록하는 것일 뿐이며, 이를 '활성/사용 중' 프로필로 설정해야 클라이언트가 실제로 이 설정에 따라 동작합니다. 여러 구독을 동시에 등록할 수 있으며, 활성 프로필을 전환하면 노드와 규칙 전체가 함께 바뀝니다.

구독 업데이트와 자동 업데이트

노드는 늘거나 줄고 규칙도 수정되므로 구독은 주기적으로 업데이트해야 합니다. 클라이언트는 보통 수동 '업데이트' 버튼과 자동 업데이트 간격을 함께 제공하는데, 24시간 자동 업데이트를 켜두고 '노드 상태가 이상하면 일단 수동으로 업데이트해본다'는 습관을 들이는 것을 권장합니다. 업데이트에 실패해도 클라이언트는 기존 설정으로 계속 동작하므로 즉시 네트워크가 끊기지는 않지만, 장기간 업데이트가 실패하면 노드 목록이 예전 상태에 머물러 있게 되어 만료된 노드가 계속 쌓이게 됩니다.

구독 업데이트 실패: 4단계 점검

①네트워크 접근 가능 여부: 구독 주소 자체에 접속할 수 있는지 확인합니다. 먼저 시스템 프록시를 끄고 직접 연결로 시도해보세요. 일부 구독 주소는 프록시 환경에서 오히려 차단됩니다. ②링크 유효성: 링크가 만료되었거나 재설정되었거나 요금제가 만료되지 않았는지 서비스 제공자에게 확인합니다. ③클라이언트 식별: 일부 서비스는 클라이언트 UA에 따라 다른 형식을 배포하므로 클라이언트를 바꾸거나 최신 버전으로 업데이트한 뒤 다시 시도합니다. ④시스템 시간: TLS 인증서 검증은 시스템 시간에 의존하므로 시간 오차가 크면 핸드셰이크 자체가 실패합니다. 시간을 맞춘 뒤 다시 업데이트하세요.

구독이 반환하는 설정 텍스트는 다음과 같은 형태입니다(일부):

proxies:
  - name: "노드-예시"
    type: ss
    server: example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"

proxy-groups:
  - name: PROXY
    type: select
    proxies: ["노드-예시", "DIRECT"]

rules:
  - GEOSITE,cn,DIRECT
  - MATCH,PROXY

설정을 받으면 이 세 부분을 알아볼 수 있어야 이후 장에서 설정을 수정할 때 헤매지 않습니다: proxies는 노드, proxy-groups는 정책 그룹, rules는 규칙표입니다.

세 가지 프록시 모드는 '규칙표를 쓰는지, 어떻게 쓰는지'를 결정합니다. 전환 메뉴는 보통 클라이언트 홈이나 트레이 메뉴에 있으며 언제든 전환할 수 있고 즉시 적용되므로 클라이언트를 재시작할 필요가 없습니다. 현재 어떤 모드인지는 클라이언트 홈이나 트레이 아이콘의 모드 표시를 보면 알 수 있습니다.

규칙 모드(Rule)

기본으로 추천되며 일상적으로 상시 사용합니다. 모든 연결은 규칙표를 위에서 아래로 차례로 대조합니다: 프록시에 걸리면 노드를 거치고, 직접 연결에 걸리면 로컬 네트워크 카드를 거칩니다. 국내 사이트는 직접 연결로 속도를 보장하고 해외 사이트는 프록시로 접속 가능성을 보장하여 서로 방해하지 않습니다. 구독에 포함된 규칙표는 이미 주요 상황을 대부분 다루고 있어 대부분의 사용자는 오랫동안 손댈 필요가 없습니다.

전역 모드(Global)

모든 연결이 조건 없이 프록시 정책 그룹이 선택한 노드로 나가며 규칙표는 전체적으로 비활성화됩니다. 다음 두 가지 상황에 적합합니다: 노드가 제대로 동작하는지 임시로 확인할 때, 반드시 동일한 출구를 유지해야 하는 서비스에 접속할 때입니다. 전역 모드를 장기간 켜두면 국내 트래픽까지 해외 노드로 우회하게 되어 속도가 느려지고 웹사이트의 위험 관리 시스템에 걸리기 쉬우니 사용 후에는 규칙 모드로 되돌리세요.

직접 연결 모드(Direct)

모든 연결이 어떤 노드도 거치지 않으며 클라이언트는 처리만 하고 전달하지 않습니다. 다음 상황에 적합합니다: 대조 테스트—'노드가 고장 났는지 클라이언트가 고장 났는지' 의심될 때 직접 연결로 전환해 접속이 되면 클라이언트와 규칙에는 문제가 없고 노드에 문제가 있다는 뜻입니다. 완전히 신뢰할 수 있는 네트워크에서 프록시를 잠시 끄고 싶을 때도 사용할 수 있습니다.

정책 그룹: 노드를 담는 컨테이너

정책 그룹은 규칙과 노드 사이의 중간 계층입니다. 규칙은 노드를 직접 가리키지 않고 정책 그룹을 가리키며, 정책 그룹은 자신의 유형에 따라 최종 사용할 노드를 결정합니다. 흔히 쓰이는 네 가지 유형은 다음과 같습니다:

• select 수동 선택: 그룹 안에 노드를 나열하고 사용자가 직접 클릭해 전환합니다. 가장 흔하게 쓰이며 '주력 노드 + 대체 노드'의 고정 조합에 적합합니다.
• url-test 자동 속도 측정: 그룹 내 노드에 주기적으로 속도 측정 요청을 보내 지연 시간이 가장 낮은 노드로 자동 전환합니다. 노드가 많고 수동 관리를 원하지 않는 경우에 적합합니다.
• fallback 장애 복구: 목록 순서대로 첫 번째로 사용 가능한 노드를 사용하며, 장애가 발생하면 자동으로 다음 노드로 전환합니다. 속도보다 안정성을 추구하는 경우에 적합합니다.
• load-balance 로드 밸런싱: 연결을 그룹 내 여러 노드에 분산합니다. 대용량 다운로드 같은 상황에 적합합니다.

정책 그룹은 설정에서 다음과 같은 형태입니다:

proxy-groups:
  - name: PROXY
    type: select
    proxies: ["자동 선택", "노드-예시", "DIRECT"]
  - name: 자동 선택
    type: url-test
    proxies: ["노드-예시"]
    url: http://example.com/generate_204
    interval: 300

구독에 포함된 정책 그룹은 보통 그것만으로 충분합니다: 수동 선택 그룹 하나로 일상을 관리하고 자동 속도 측정 그룹 하나로 백업을 관리하는 식입니다. 지역별, 용도별로 직접 그룹을 나누고 싶다면 9장의 설정 직접 작성 내용을 참고하세요.

규칙 분류는 Clash 계열 클라이언트의 핵심 기능이며, '전체를 터널로 보내는' 방식의 도구와 구별되는 핵심 가치입니다. 이 장에서는 규칙 유형을 빠짐없이 설명하고 매칭 순서를 완전히 파헤친 뒤, 국내외 분류를 위한 실전 설정과 검증 방법을 제시합니다. 더 세부적인 규칙 작성 예시는 블로그의 《Clash 규칙 분류 설정 실전》을 참고하세요.

규칙 유형 목록

mihomo가 지원하는 규칙 유형은 다양하지만 일상적으로 자주 쓰이는 것은 다음 몇 가지입니다:

• DOMAIN: 단일 도메인을 정확히 매칭합니다. 예: DOMAIN,example.com,PROXY는 이 도메인 하나만 매칭합니다.
• DOMAIN-SUFFIX: 도메인 접미사를 매칭합니다. 예: DOMAIN-SUFFIX,example.com,PROXY는 해당 도메인과 모든 하위 도메인을 매칭하며, 가장 흔히 쓰이는 도메인 규칙입니다.
• DOMAIN-KEYWORD: 도메인에 특정 키워드가 포함되면 매칭됩니다. 예: DOMAIN-KEYWORD,example,PROXY는 커버 범위가 넓은 만큼 오탐 범위도 넓어 신중히 사용해야 합니다.
• GEOSITE: 도메인 분류 라이브러리로 매칭합니다. 예: GEOSITE,cn,DIRECT는 분류 라이브러리에 등록된 중국 본토 도메인 모음을 매칭하며, 한 줄이 수만 줄의 수동 규칙을 대신합니다.
• IP-CIDR: 대상 IP 대역으로 매칭합니다. 예: IP-CIDR,192.168.0.0/16,DIRECT는 로컬 네트워크 주소를 모두 직접 연결시킵니다. no-resolve 파라미터가 붙은 규칙은 DNS 해석을 트리거하지 않으며 순수 IP 연결만 매칭됩니다.
• GEOIP: IP 소속 지역으로 매칭합니다. 예: GEOIP,CN,DIRECT는 도메인을 먼저 IP로 해석한 뒤 소속 지역 라이브러리를 조회합니다.
• PROCESS-NAME: 연결을 시작한 프로세스 이름으로 매칭합니다. 데스크톱에서 사용 가능하며, 특정 다운로드 도구를 항상 프록시로 보내는 식으로 활용할 수 있습니다.
• DST-PORT / SRC-IP-CIDR: 대상 포트, 출발지 IP 대역으로 매칭하며, 로컬 네트워크 공유와 게이트웨이 환경에서 자주 쓰입니다.
• MATCH: 모든 것을 매칭하는 기본 규칙으로, 반드시 규칙표의 마지막에 있어야 합니다.

매칭 순서: 위에서 아래로, 첫 매칭에서 종료

규칙표는 순서가 있는 목록입니다: 새 연결마다 첫 번째 줄부터 아래로 차례로 비교하며, 매칭되는 규칙을 만나면 그 규칙을 실행하고 뒤에 있는 규칙은 더 이상 확인하지 않습니다. 이 원리에서 두 가지 원칙이 나옵니다: ①더 구체적이고 특수한 규칙일수록 앞에, 더 범용적인 규칙일수록 뒤에 두어야 합니다. ②MATCH 기본 규칙은 항상 마지막에 있어야 합니다. 앞쪽에 배치하면 뒤의 모든 규칙이 무효화됩니다. '특정 사이트가 원치 않는 경로로 나간다'는 문제를 진단할 때는 먼저 순서를 확인하세요. 더 범용적인 규칙이 앞에 있어서 가로챈 것은 아닌지 살펴보세요.

규칙이 지정하는 대상은 정책 그룹일 수도 있고 예약어일 수도 있습니다: DIRECT는 직접 연결, REJECT는 연결 거부(광고 및 추적 도메인 차단에 자주 사용), 정책 그룹 이름이면 해당 그룹이 출구를 결정합니다.

GEOSITE와 GEOIP 데이터 파일

GEOSITE와 GEOIP 규칙은 두 개의 분류 데이터 파일(geosite.dat와 geoip 계열 데이터)에 의존하며, 이 파일들은 클라이언트와 함께 배포되고 커뮤니티에서 지속적으로 업데이트됩니다. 데이터 파일이 오래되면 새 도메인의 분류가 부정확해져 '직접 연결해야 할 것이 프록시로 나가는' 식의 현상이 생길 수 있습니다. 주요 클라이언트는 설정에서 데이터 파일 업데이트 메뉴를 제공하니, 구독 업데이트와 함께 월간 유지 관리 항목으로 넣는 것을 권장합니다. 자세한 내용은 8장을 참고하세요.

실전: 국내외 분류 설정

국내외 분류에 흔히 쓰는 규칙표 예시입니다(일부, 순서가 곧 매칭 순서입니다):

rules:
  # 로컬 네트워크와 예약 주소는 직접 연결
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  # 국내 도메인과 IP는 직접 연결
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  # 나머지는 모두 프록시 정책 그룹으로
  - MATCH,PROXY

이 기본 구조를 바탕으로 조정할 수 있습니다: 특정 해외 사이트를 강제로 프록시로 보내고 싶다면 GEOSITE 줄 앞에 DOMAIN-SUFFIX,대상도메인,PROXY를 추가하고, 특정 광고 도메인을 차단하고 싶다면 GEOSITE,category-ads-all,REJECT를 추가해 맨 앞에 배치하세요. 구독에 규칙표가 이미 포함되어 있다면 구독 파일을 직접 수정하지 말고 클라이언트의 '오버라이드/커스텀 규칙' 메뉴에 추가하는 것이 좋습니다. 구독이 업데이트되면 직접 수정한 내용은 사라지기 때문입니다.

분류 결과 검증하기

규칙을 수정한 뒤에는 반드시 검증해야 합니다. 클라이언트의 '연결' 패널을 열고 대상 웹사이트에 접속한 뒤 새로 생긴 연결 항목을 확인하세요: 패널에는 이 연결이 어떤 규칙에 매칭되었는지, 최종적으로 어떤 정책 그룹과 노드를 거쳤는지 표시됩니다. 결과가 예상과 다르면 연결 패널에 표시된 규칙 이름을 확인해 순서를 조정하세요. 클라이언트 로그를 debug 수준으로 올리면 규칙 판정 과정을 줄 단위로 출력해주므로 더 세밀한 진단에 적합합니다.

시스템 프록시에는 태생적인 사각지대가 있습니다. '시스템 프록시 설정을 따르는' 애플리케이션에만 효과가 있다는 점입니다. 브라우저와 대부분의 데스크톱 소프트웨어는 시스템 프록시를 읽지만, 명령줄 도구, 일부 게임, 자체 네트워크 스택을 관리하는 일부 애플리케이션, 그리고 거의 모든 UDP 트래픽은 이를 우회해 직접 연결합니다. TUN 모드가 바로 이 사각지대를 해결합니다.

TUN이란

TUN 모드는 시스템에 가상 네트워크 카드를 만들고 라우팅 테이블을 수정해 시스템 전체의 TCP/UDP 트래픽이 먼저 이 가상 네트워크 카드를 거쳐 클라이언트로 들어가게 한 뒤, 클라이언트가 규칙에 따라 분류하도록 합니다. 처리가 네트워크 계층에서 일어나므로 애플리케이션의 협조 여부에 의존하지 않아 명령줄, 게임, 시스템 서비스, UDP 애플리케이션 모두 분류 범위에 포함됩니다. Android에서는 클라이언트가 원래부터 VPN 서비스 방식으로 동작하므로 효과가 TUN과 동일합니다. TUN은 주로 데스크톱(Windows/macOS/Linux)의 강화 스위치입니다.

시스템 프록시와의 역할 분담

두 가지는 충돌하지 않고 함께 사용할 수 있습니다: 시스템 프록시는 '말을 잘 듣는 애플리케이션'을, TUN은 '말을 안 듣는 애플리케이션'을 처리합니다. 대부분의 클라이언트는 TUN을 켤 때 시스템 프록시와의 관계를 자동으로 처리해주므로 수동으로 둘 중 하나를 고를 필요는 없습니다. 주로 웹 서핑만 하고 가끔 명령줄을 쓰는 사용자는 시스템 프록시만으로 충분하며, 명령줄 도구를 자주 쓰거나 해외 서버 게임을 하거나 UDP 전달이 필요한 사용자는 TUN을 상시 켜두는 것을 권장합니다.

활성화 조건

TUN은 시스템 네트워크 스택을 다루므로 일반 프록시보다 높은 권한이 필요합니다. Windows에서는 주요 클라이언트가 '서비스 모드'로 구현되어 있어, 클라이언트 설정에서 안내에 따라 서비스를 설치하면 이후에는 TUN 스위치만으로 정상 사용할 수 있고 매번 관리자 권한으로 클라이언트 본체를 실행할 필요가 없습니다. macOS는 처음 켤 때 시스템 비밀번호를 입력해 헬퍼 프로그램 설치를 승인해야 합니다. Linux 데스크톱도 마찬가지로 승인이 필요하며, 서버에서 커널로 직접 TUN을 켤 때는 프로세스에 적절한 네트워크 권한이 있어야 합니다.

설정 예시

그래픽 클라이언트에서는 TUN이 보통 단순한 스위치이지만, 내부적으로는 설정의 tun 섹션에 대응하며 직접 설정을 작성하면 다음과 같은 형태입니다:

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

주요 필드 몇 가지: stack은 가상 네트워크 카드의 프로토콜 스택 구현이며 mixed는 호환성과 성능을 함께 고려한 흔한 값입니다. auto-route는 클라이언트가 라우팅 테이블을 자동으로 설정하게 하고, auto-detect-interface는 출구 네트워크 카드를 자동으로 인식해 트래픽 루프를 방지합니다. dns-hijack은 시스템의 53번 포트로 향하는 모든 DNS 조회를 클라이언트의 DNS 모듈로 가로채며, 9장의 DNS 설정과 함께 사용합니다.

주의 사항

①다른 VPN/가속기와의 충돌: 시스템에 라우팅 테이블을 수정하는 가상 네트워크 카드가 동시에 두 개 존재하면 트래픽 흐름을 예측할 수 없으므로 한 번에 하나만 유지하세요. ②방화벽 차단: 일부 보안 소프트웨어가 가상 네트워크 카드 드라이버를 차단할 수 있으니 TUN을 켠 뒤 인터넷이 끊기면 이 항목을 먼저 확인하세요. ③깔끔하게 종료해야 함: 비정상 종료 시 라우팅 테이블 항목이 남아 인터넷 연결이 끊길 수 있는데, 클라이언트를 재시작해 TUN을 한 번 껐다 켜거나 시스템을 재시작하면 복구됩니다. ④모든 상황에 필요한 것은 아님: 단순히 웹 서핑만 한다면 TUN을 켜지 않는 것이 처리 계층을 하나 줄여 문제 발생 소지도 줄입니다.

클라이언트를 설치한 뒤 정말 시간이 드는 것은 설정이 아니라 유지 관리입니다: 구독은 업데이트되고, 데이터 파일은 오래되고, 노드는 실패하며, 클라이언트 자체도 계속 발전합니다. 이 장에서는 바로 실행할 수 있는 유지 관리 체크리스트와 흔한 문제의 진단 경로를 제시합니다. FAQ 페이지에는 더 세부적인 질의응답이 정리되어 있으니, 이 장에서는 체계적인 유지 관리 동작만 다룹니다.

유지 관리 체크리스트

구독 업데이트: 24시간 자동 업데이트를 켜두세요. 노드가 대규모로 연결되지 않을 때는 가장 먼저 수동으로 구독을 한 번 업데이트해 '클라이언트가 만료된 노드 목록을 갖고 있는' 가장 흔한 원인을 배제하세요.

GEOSITE / GEOIP 데이터 업데이트: 매달 한 번, 클라이언트 설정에 메뉴가 있습니다. 데이터 파일은 도메인과 IP 분류의 정확도를 결정하며, 오래 업데이트하지 않으면 분류 결과가 점점 실제와 어긋나게 됩니다.

클라이언트 업데이트: 클라이언트에 내장된 업데이트 알림을 따르면 됩니다. 커널 업데이트에는 프로토콜 및 보안 수정이 자주 포함되므로 오래된 버전에 머무는 것은 권장하지 않습니다. 업데이트 전에 기존 버전을 삭제할 필요는 없으며 설정은 그대로 유지됩니다.

설정 백업: 구독 링크는 비밀번호 관리자나 암호화된 메모에 따로 기록해두세요. 직접 작성한 설정(커스텀 규칙, 오버라이드)은 사본을 내보내 보관하세요. 기기를 바꾸거나 재설치할 때 구독 링크와 오버라이드 백업이 있으면 완전히 복원할 수 있습니다.

노드 실패 시 대처

노드 하나가 연결되지 않으면 먼저 정책 그룹에서 대체 노드로 수동 전환해보고, 서둘러 설정을 바꾸지 마세요. 그룹 전체가 타임아웃되면 다음 순서로 확인하세요: 구독 수동 업데이트 → 전역 모드로 전환해 규칙 오탐 여부 확인 → 직접 연결 모드로 전환해 로컬 네트워크 정상 여부 확인 → 네트워크 환경을 바꿔(휴대폰 핫스팟 등) 인터넷 회선 출구 문제 배제. 네 단계를 모두 거쳐도 해결되지 않으면 노드 서비스 제공자에게 문의하세요.

로그와 연결 패널

클라이언트에는 두 가지 진단 도구가 있습니다. 연결 패널: 각 연결의 프로세스, 대상, 매칭된 규칙, 출구 노드, 트래픽 카운트를 실시간으로 나열해 '왜 이 사이트가 프록시를 거치지 않는지'를 한눈에 파악할 수 있습니다. 로그: 기본적으로 info 수준에서 핵심 이벤트를 기록하며, 문제가 복잡할 때는 debug로 올리면 규칙 판정 과정과 DNS 해석 세부 사항을 볼 수 있습니다. 확인이 끝나면 info로 되돌리세요. debug 로그는 양이 많고 접속 대상까지 기록하므로 상시 켜두는 것은 적합하지 않습니다.

흔한 문제 자가 진단표

자가 진단표로 해결되지 않는 문제는 FAQ 페이지에서 분류별로 확인해보세요. 블로그의 문제 해결 태그에도 증상별로 정리된 전문 글이 있습니다. 예를 들어 《Clash DNS 유출 검사》가 있습니다.

앞의 8개 장을 마쳤다면 일상 사용에는 이미 어려움이 없을 것입니다. 이 장에서는 더 깊이 배우고 싶은 사용자를 위한 로드맵을 제시합니다. 투입 정도가 낮은 것부터 높은 것 순으로 배열했으며, 각 단계마다 명확한 목표와 관련된 사이트 내 자료를 함께 제공합니다.

첫 번째 단계: 구독 설정 오버라이드

구독에 포함된 설정은 서비스 제공자가 관리하므로 직접 수정하면 다음 업데이트 때 덮어써집니다. 올바른 방법은 클라이언트의 '오버라이드/Mixin' 기능을 사용하는 것입니다: 자신만의 보충 조각—규칙 추가, 정책 그룹 조정, 포트 수정 등—을 정의해두면 클라이언트가 매번 구독을 업데이트한 뒤 자동으로 이 조각을 병합해줍니다. 이것이 '구독을 쓰는 것'에서 '설정을 관리하는 것'으로 넘어가는 첫걸음이며, 투입은 적고 효과는 즉시 나타납니다.

두 번째 단계: 규칙 제공자 rule-providers

규칙이 많아지면 rules 목록에 전부 쌓아두기가 어려워집니다. mihomo는 rule-providers를 지원합니다: 한 종류의 규칙(예: 특정 애플리케이션의 모든 도메인)을 독립된 외부 규칙 세트 파일이나 온라인 주소로 만들어 설정에서 이름으로 참조할 수 있으며, 규칙 세트는 독립적으로 업데이트할 수 있습니다. 정책 그룹과 함께 사용하면 '애플리케이션 하나에 규칙 세트 하나, 출구 하나'라는 명확한 구조를 만들 수 있습니다.

세 번째 단계: DNS 모듈

DNS는 분류 정확도의 기반입니다. 클라이언트에 내장된 DNS 모듈이 도메인 해석을 처리합니다: nameserver는 일반 해석 서버를 지정하고, fallback은 해외 도메인을 위한 대체 해석 경로를 지정하며, enhanced-mode는 강화 해석 동작을 제어합니다. 제대로 설정하면 DNS 오염이 GEOIP 판정에 주는 영향을 없앨 수 있고, 해석 요청이 프록시 통로 밖으로 유출되는 것도 막을 수 있습니다. 이 단계는 내용이 많으므로 블로그의 두 전문 글을 바로 참고하세요: 《Clash DNS 상세 설정》은 파라미터를, 《Clash DNS 유출 검사》는 검증과 수정을 다룹니다.

네 번째 단계: 로컬 네트워크 공유와 게이트웨이

설정에서 allow-lan: true를 켜면 로컬 네트워크의 다른 기기(휴대폰, 태블릿, TV)가 이 컴퓨터의 IP와 혼합 포트로 프록시를 지정해 같은 클라이언트를 공유할 수 있습니다. 한 단계 더 나아가 클라이언트를 소프트 라우터나 상시 켜진 기기에 배포하고 TUN으로 전체 네트워크 대역을 처리하게 하면 가정용 게이트웨이 방식이 됩니다. 인터넷에 연결하는 모든 기기가 별도 설정 없이 분류를 적용받습니다.

다섯 번째 단계: 서버와 라우터에 mihomo 배포

그래픽 인터페이스가 없는 환경에서는 커널을 직접 사용합니다: 해당 아키텍처의 mihomo 바이너리를 받아 완전한 config.yaml을 준비하고 systemd로 프로세스를 관리해 부팅 시 자동 시작과 충돌 시 재시작을 구현하세요. external-controller를 켜면 API나 웹 대시보드를 통해 원격 관리할 수 있습니다. 노드 전환, 연결 확인, 로그 조회 모두 서버에 로그인할 필요 없이 처리할 수 있습니다. 예시 유닛 파일:

[Unit]
Description=mihomo proxy core
After=network.target

[Service]
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure

[Install]
WantedBy=multi-user.target

설정 디렉터리 /etc/mihomo에 config.yaml과 GEOSITE/GEOIP 데이터 파일을 넣습니다. 설정을 수정한 뒤에는 systemctl restart mihomo로 적용하고 journalctl -u mihomo로 로그를 확인합니다.

지속적인 학습 경로

심화 콘텐츠의 업데이트 창구는 사이트 내 세 곳입니다: FAQ 페이지는 '기본 개념 / 설치 설정 / 사용 팁 / 문제 해결'로 분류된 고빈도 질의응답을 모아둡니다. 블로그는 커널, 설정, DNS, 진단 네 가지 주제의 전문 글을 지속적으로 올립니다. 튜토리얼 페이지는 새 동료나 새 기기에 빠르게 안내할 때 적합합니다. 이 가이드가 다루지 않는 상황을 만나면 먼저 FAQ의 분류 메뉴를 확인하고, 그다음 블로그 태그를 살펴보세요.