Clash 완전 정복 가이드

Clash는 설정 파일로 동작하는 규칙 기반 프록시 코어입니다. 자체 그래픽 인터페이스는 없으며, 실행 시 YAML 형식의 설정을 읽어들여 로컬에서 여러 포트를 열고, 해당 포트로 들어오는 요청을 규칙에 따라 하나씩 매칭해 직접 연결할지, 특정 프록시 노드를 통할지, 아예 거부할지를 결정합니다. 각종 클라이언트에서 보는 스위치, 노드 목록, 모드 전환 등은 모두 이 설정과 매칭 로직을 감싼 것뿐입니다. 이 점을 이해하면 이후 챕터가 훨씬 쉬워집니다.

원래의 Clash 코어는 개발이 중단되었고, 현재 생태계의 사실상 표준은 커뮤니티가 이어가고 있는 Mihomo 코어(흔히 Clash Meta라고도 부름)입니다. Mihomo는 기존 설정 형식을 완전히 지원하면서 더 많은 프록시 프로토콜, 규칙 유형, DNS 기능을 추가했습니다. 본 사이트의 클라이언트 다운로드 페이지에 소개된 소프트웨어는 Mihomo를 내장하거나 그 설정 형식과 호환되므로, 이 가이드의 예제도 기본적으로 Mihomo의 동작을 기준으로 합니다.

클라이언트와 코어는 서로 다른 층위의 존재입니다. 코어가 실제 트래픽 전달을 담당하고, 클라이언트는 코어를 관리합니다. 즉 구독을 다운로드하고, 설정을 생성하고, 코어 프로세스를 실행하고, 시스템 프록시를 설정하고, 노드 지연을 표시하는 일을 대신해줍니다. 클라이언트를 바꿔도 코어에 대한 이해는 그대로 유지되며, 설정 파일은 클라이언트 간에도 대체로 호환됩니다. 그래서 소프트웨어를 고르기 전에 개념을 먼저 익히는 것이 중요합니다.

완전한 설정 파일은 대략 다섯 부분으로 구성됩니다. 포트 선언, 노드 목록(proxies), 프록시 그룹(proxy-groups), 규칙(rules), DNS 설정입니다. 기본 골격은 다음과 같습니다.

mixed-port: 7890        # HTTP와 SOCKS를 함께 받는 혼합 리스닝 포트
mode: rule              # 실행 모드: rule / global / direct
log-level: info

proxies: []             # 노드 목록, 보통 구독으로 채워짐
proxy-groups: []        # 프록시 그룹: 노드를 선택 가능한 전략으로 묶음
rules:                  # 규칙: 위에서 아래로 매칭, 일치하면 즉시 종료
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

규칙 엔진의 매칭 방식은 단 하나의 절대 원칙을 따릅니다. 위에서 아래로 하나씩 비교하며 처음 일치한 규칙이 해당 연결의 경로를 결정하고, 이후 규칙은 더 이상 확인하지 않습니다. 따라서 규칙의 순서가 곧 우선순위이며, 정확한 규칙은 앞에, 기본(포괄) 규칙은 맨 뒤에 두는 원칙이 6장 전체를 관통합니다.

프록시 그룹은 Clash를 단순한 프록시 도구와 구별 짓는 핵심 개념입니다. 규칙의 출구는 특정 노드를 직접 가리키지 않고 그룹을 가리키며, 그룹 내부에서 어느 노드를 쓸지 결정합니다. 수동으로 선택할 수도 있고 지연 시간을 기준으로 자동 선택할 수도 있습니다. 구독 갱신과 노드 추가·삭제는 모두 그룹 내부에서 일어나므로 규칙 자체는 손댈 필요가 없어 장기적으로 유지보수하기 좋은 구조가 됩니다.

마지막으로 포트입니다. 코어는 기본적으로 로컬 루프백 주소 127.0.0.1에서만 대기하며, 브라우저나 시스템 프록시가 이 포트로 트래픽을 넘겨야 코어가 동작을 시작합니다. 포트 번호와 리스닝 주소는 설정 가능하며, LAN 공유가 필요한 경우에만 개방하면 됩니다. 자세한 내용은 5장에서 다룹니다.

클라이언트를 고르기 전에 세 가지를 먼저 정하세요. 사용하는 OS, TUN 모드로 전체 트래픽을 관리할지 여부, 설정에 시간을 들일 의향이 있는지입니다. 이 세 가지가 정리되면 선택 범위가 확 좁아집니다. 아래 표는 본 사이트 다운로드 페이지에 등록된 클라이언트를 빠르게 비교한 것으로, 클라이언트 다운로드 페이지 내용과 일치합니다.

Clash Plus는 전 플랫폼에서 첫손에 꼽는 선택입니다. Windows, macOS, Android, iOS 네 플랫폼을 모두 지원하며 목록 중 유일하게 App Store에 등록된 앱이라 iOS 사용자에게는 실질적으로 유일한 정식 경로입니다. 구독, 모드, 노드 선택을 한 메뉴에 모아두어 초보자에게도 기본 설정이 친숙하고 고급 옵션도 축소되지 않아 첫 클라이언트로 적합합니다.

Clash Verge Rev는 Linux 데스크톱의 주력 클라이언트이며 이 가이드의 Linux 예제도 기본적으로 이를 기준으로 합니다. Mihomo 코어를 직접 내장하고 deb, rpm 설치 패키지를 제공하며 설정 오버라이드, Merge 스크립트, 서비스 모드를 지원합니다. TUN 관련 권한 처리도 완성도가 높아 설정을 깊이 파고들고 싶은 사용자에게 잘 맞습니다.

FlClash는 Flutter로 작성되어 데스크톱과 모바일 인터페이스가 거의 동일합니다. PC와 스마트폰을 자주 오가며 동일한 조작감을 원한다면 가장 편한 선택입니다. Clash Nyanpasu는 Windows용 또 다른 활발한 포크로, 인터페이스가 더 가볍고 기능 방향은 Verge Rev와 비슷하며 대안으로 충분히 안정적입니다.

Android에서는 Clash Plus 외에 Clash Meta for Android가 코어의 원래 동작에 가장 가까운 선택입니다. 설정 항목이 코어 필드에 그대로 매핑되어 있어 내부 동작을 파악하고 싶은 사용자에게 적합합니다. Surfboard는 가벼운 사용을 지향하며 구독을 가져오면 바로 쓸 수 있습니다. Clash for Windows와 ClashX Meta는 모두 유지보수가 중단되어, 기존 사용자는 계속 사용할 수 있지만 새로 설치하는 것은 추천하지 않습니다.

서버나 라우터 환경에서는 그래픽 인터페이스가 필요 없으므로 바로 Mihomo 코어만 배포합니다. 바이너리 파일 하나와 설정 디렉터리 하나면 장기 운영이 가능하며, systemd로 프로세스를 관리하는 방법은 8장과 9장에서 자세히 다룹니다.

모든 설치 파일은 클라이언트 다운로드 페이지에서 플랫폼별 카드를 통해 받을 수 있습니다. Linux 사용자는 먼저 배포판과 CPU 아키텍처를 확인하세요. 주요 데스크톱 배포판은 대부분 x86_64(amd64)이므로 패키지 이름의 아키텍처 표기를 확인하고 arm64 패키지를 인텔이나 AMD 기기에 설치하지 않도록 주의하세요.

Ubuntu / Debian 계열

.deb 패키지를 받아 apt로 로컬 설치하세요. apt가 의존성을 자동으로 해결해주므로 dpkg로 직접 설치할 때보다 의존성 문제를 덜 겪습니다.

sudo apt update
sudo apt install ./clash-verge-rev_amd64.deb

명령어의 ./ 접두사는 생략하면 안 됩니다. 이는 apt에게 이것이 저장소의 패키지 이름이 아니라 로컬 파일임을 알려주는 표시입니다. 설치가 끝나면 애플리케이션 메뉴에서 아이콘을 찾을 수 있고, 터미널에 프로그램 이름을 입력해 바로 실행할 수도 있습니다.

Fedora 계열

sudo dnf install ./clash-verge-rev.rpm

dnf도 마찬가지로 의존성을 처리해줍니다. webkit2gtk 같은 구성 요소가 없다는 안내가 나오면 그대로 설치를 승인하면 됩니다. 이는 그래픽 인터페이스 렌더링에 필요한 시스템 라이브러리이며 소프트웨어 자체의 문제가 아닙니다.

Arch 계열

# 이미 바이너리 패키지가 있을 때 로컬 설치
sudo pacman -U clash-verge-rev.pkg.tar.zst

# 또는 AUR에서 빌드(예: paru 사용)
paru -S clash-verge-rev

AUR 방식의 장점은 시스템과 함께 롤링 업데이트되는 것이고, 단점은 빌드 시간이 걸리는 것입니다. 두 방법으로 설치한 결과는 동일하므로 취향에 맞게 선택하세요.

다른 플랫폼

Windows는 설치 프로그램을 더블클릭해 안내에 따라 진행하며, 첫 실행 시 방화벽이 네트워크 접근 허용 여부를 물으면 허용을 선택해야 합니다. 그렇지 않으면 코어가 포트를 열 수 없습니다. macOS는 앱을 '응용 프로그램' 폴더로 드래그하고, 첫 실행 시 시스템이 막으면 '시스템 설정 → 개인정보 보호 및 보안'에서 '그래도 열기'를 클릭하세요. 다운로드 전에 Apple Silicon과 Intel 패키지를 구분해야 합니다. Android는 APK를 바로 설치하며, '알 수 없는 앱 설치' 권한을 요청하면 브라우저나 파일 관리자에 한 번만 허용하면 됩니다. iOS는 App Store에서 Clash Plus를 검색해 설치하세요.

첫 실행 체크리스트

플랫폼과 관계없이 처음 실행 후 1분만 투자해 다음 세 가지를 확인하세요. 첫째, 트레이나 상태 표시줄에 프로그램 아이콘이 나타났는지(메인 프로세스가 살아 있다는 뜻입니다). 둘째, 클라이언트의 로그 페이지를 열어 코어 시작 로그가 정상적으로 출력되고 빨간색 오류가 없는지. 셋째, 설정에서 '시작 시 자동 실행' 항목을 찾아 필요에 따라 켜는지입니다. Linux 데스크톱에서 클라이언트가 '서비스 모드'를 제공한다면 이 시점에 함께 설치하는 것을 추천합니다. 시스템 서비스를 등록해 충분한 권한으로 코어를 실행해주며, 7장에서 다룰 TUN 모드에도 필요합니다.

구독은 본질적으로 URL입니다. 서비스 제공자가 노드 목록(보통 완전한 Clash 설정 또는 클라이언트가 변환 가능한 노드 목록)을 이 주소에 게시하고, 클라이언트가 주기적으로 가져와 로컬 설정 파일로 저장한 뒤 코어에 넘겨 불러오게 합니다. '구독 = 원격 설정의 출처'라는 관계를 이해하면 이후 갱신, 오버라이드, 실패 진단이 모두 자연스럽게 이해됩니다.

구독 가져오기

클라이언트마다 절차는 동일합니다. 서비스 제공자가 준 구독 링크를 전체 복사하고, 클라이언트의 '구독' 또는 'Profiles' 페이지를 열어 입력란에 붙여넣고 가져오기 또는 다운로드를 클릭하세요. 성공하면 목록에 설정 항목이 생기며, 클릭해 활성화한 뒤 '프록시' 페이지로 돌아가면 노드 목록이 보입니다. 노드 목록이 비어 있다면 다운로드나 파싱 단계에서 문제가 생긴 것이니 같은 동작을 반복하지 말고 아래 실패 진단 절차를 따르세요.

구독 갱신

서비스 제공자의 노드는 계속 바뀌므로 구독을 주기적으로 갱신해야 합니다. 대부분의 클라이언트는 자동 갱신 주기(예: 24시간마다)를 설정할 수 있고, 언제든 수동으로 갱신 버튼을 눌러도 됩니다. 여기서 놓치기 쉬운 점 하나: 구독을 갱신하면 원격 내용이 로컬 파일을 덮어씁니다. 구독 파일 안에 직접 추가한 커스텀 규칙은 다음 갱신 때 사라집니다. 올바른 방법은 클라이언트의 '오버라이드' 또는 'Merge' 기능을 사용해 커스텀 내용을 구독과 별도의 파일에 두고, 갱신 시 자동으로 합쳐지도록 하는 것입니다. 자세한 내용은 9장에서 다룹니다.

가져오기 실패 진단

구독 가져오기 오류가 나면 단계별로 확인하세요. 링크가 잘려 있지 않은지(끝부분 파라미터가 누락되는 경우가 흔함), 브라우저에서 링크를 열었을 때 텍스트가 반환되는지(404나 일반 웹페이지가 아닌지), 서비스 제공자가 User-Agent를 제한하는지(일부 구독은 Clash 계열 UA에만 설정을 반환), 반환된 내용이 유효한 YAML인지 순서대로 확인합니다. 전체 체크리스트는 기술 노트 《Clash 구독 링크 실패 및 파싱 오류 체크리스트》에서 확인할 수 있습니다.

설정 파일은 어디에 있나요

클라이언트는 구독을 자체 설정 디렉터리에 저장합니다. Linux에서는 보통 ~/.config나 ~/.local/share 아래 클라이언트 이름의 하위 디렉터리에 있고, 순수 코어는 기본적으로 ~/.config/mihomo/config.yaml을 읽습니다. 위치를 알아두면 백업할 수 있고, 클라이언트 화면에 이상이 있을 때 파일 내용을 직접 확인해 설정 문제인지 프로그램 문제인지 구분할 수 있습니다.

설정을 직접 관리하는 사용자는 구독 없이도 사용할 수 있습니다. config.yaml을 직접 작성해 proxies에 노드를 적고, 클라이언트에서 '로컬 파일'로 가져오면 됩니다. 이 방식은 자유도가 가장 높지만 필드 이해도도 가장 많이 요구되므로, 먼저 구독으로 전체 흐름을 익힌 뒤 점진적으로 전환하는 것을 추천합니다.

코어는 설정의 mode 필드에 대응하는 세 가지 모드를 지원합니다. 규칙 모드(rule)는 일상적인 기본값으로, 모든 연결이 규칙표를 거쳐 직결할지 프록시를 탈지 결정되어 속도와 가용성을 동시에 확보합니다. 전역 모드(global)는 모든 트래픽을 프록시 출구로 보내며, '분流 규칙 자체가 문제인지' 임시로 확인할 때 유용하지만 장기간 켜두기엔 부적합합니다. 중국 본토 트래픽까지 해외 노드를 돌아가면 느리고 트래픽도 낭비됩니다. 직결 모드(direct)는 모든 트래픽을 프록시 없이 보내며, 프로그램을 종료하지 않고도 임시로 비활성화하는 것과 같은 효과를 냅니다. 문제를 진단할 때 세 모드를 전환해 비교하는 것이 가장 빠른 방법 중 하나입니다.

포트: 트래픽의 입구

모드는 트래픽이 어디로 갈지를, 포트는 트래픽이 어떻게 들어올지를 결정합니다. 최신 설정에서는 mixed-port 하나만 선언하는 것을 권장합니다(관례상 7890 사용). 이 포트는 HTTP와 SOCKS5를 동시에 받아, 브라우저, 시스템 프록시, 명령줄 도구가 모두 이 포트 하나만 가리키면 되어 port와 socks-port를 따로 관리할 필요가 없습니다.

'Clash를 켰는데 브라우저가 프록시를 안 탄다'는 문제의 가장 흔한 원인은 트래픽이 이 포트로 들어오지 않았기 때문입니다. 데스크톱 클라이언트의 '시스템 프록시' 스위치가 하는 일은 OS의 프록시 설정을 127.0.0.1:7890으로 가리키게 하는 것뿐이며, 이 스위치가 꺼져 있으면 코어는 그냥 대기만 하고 있는 상태입니다. GNOME 사용자는 '설정 → 네트워크 → 네트워크 프록시'에서, KDE는 '시스템 설정 → 네트워크 → 프록시'에서 루프백 주소와 포트 번호가 표시되는지 확인하세요.

터미널 프로그램은 시스템 프록시를 인식하지 않습니다

Linux의 많은 명령줄 도구(curl, git, 패키지 관리자)는 데스크톱 환경의 프록시 설정을 읽지 않고 환경 변수를 봅니다. 현재 터미널 세션에만 임시로 프록시를 적용하려면 다음과 같이 합니다.

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export all_proxy=socks5://127.0.0.1:7890

~/.bashrc에 넣으면 계속 적용되지만, 필요할 때만 켜고 끄는 셸 함수로 만드는 것을 더 추천합니다. 프록시가 꺼진 상태에서 터미널 요청이 전부 멈추는 것을 피할 수 있습니다. 적용 여부는 curl -I https://www.google.com이 빠르게 응답 헤더를 반환하는지로 확인하세요.

LAN 공유와 포트 충돌

기본적으로 127.0.0.1에서만 대기한다는 것은 이 기기에서만 사용할 수 있다는 뜻입니다. allow-lan을 true로 설정하고 바인딩 주소를 개방하면 같은 네트워크의 스마트폰, TV 셋톱박스가 이 기기를 프록시 서버처럼 사용할 수 있습니다. 설정 방법과 방화벽 허용, 보안 경계에 대한 전체 논의는 기술 노트 《Clash 혼합 포트와 LAN 프록시 공유 설정》을 참고하세요. 또 하나 흔한 문제는 실행 시 address already in use 오류인데, 7890 포트를 다른 프로세스가 이미 쓰고 있다는 뜻입니다. 원인 파악과 포트 변경 전체 절차는 《Clash 포트 충돌 해결 방법》을 참고하세요. mixed-port를 바꾼 뒤에는 시스템 프록시와 환경 변수의 포트 번호도 함께 갱신해야 합니다. 하나라도 빠뜨리면 '일부 프로그램만 정상 작동하는' 이상한 현상이 나타납니다.

규칙 분流는 Clash의 핵심입니다. 각 규칙은 세 부분으로 구성됩니다. 유형,매칭 대상,출구이며 출구는 특정 프록시 그룹이거나 내장된 DIRECT(직결) 또는 REJECT(거부)일 수 있습니다. 1장에서 언급한 절대 원칙을 다시 강조합니다. 위에서 아래로 매칭하며 첫 번째로 일치한 규칙이 최종 결정됩니다. 자주 쓰는 규칙 유형은 다음과 같습니다.

특별히 짚어둘 세부사항이 두 가지 있습니다. 첫째, IP 계열 규칙은 도메인 해석을 유발합니다. 연결 목표가 여전히 도메인이면 코어는 먼저 IP를 해석해야 IP-CIDR과 비교할 수 있는데, 이 해석 과정에서 지연이 늘거나 쿼리가 노출될 수 있습니다. 순수 내부망 대역 규칙에는 no-resolve 옵션을 붙여 '원래부터 IP인 연결'만 매칭하게 하는 것이 일반적입니다. 둘째, MATCH는 반드시 맨 마지막에 두어야 합니다. 이는 다른 모든 규칙이 일치하지 않았을 때의 최종 출구이며, 이 출구가 어느 그룹을 가리키느냐가 '알려지지 않은 트래픽'의 기본 경로를 결정합니다.

프록시 그룹: 규칙의 출구

규칙의 출구는 노드가 아니라 그룹을 가리키며, 그룹 유형이 선택 전략을 결정합니다. select는 수동 선택, url-test는 주기적으로 지연을 측정해 가장 빠른 노드를 자동 선택, fallback은 순서대로 사용 가능한 첫 노드를 찾음, load-balance는 요청을 여러 노드에 분산합니다. 그룹은 서로 중첩할 수도 있습니다. 수동 그룹 안에 자동 측정 그룹을 넣어 평소엔 자동에 맡기고 특수한 경우엔 수동으로 지정하는 방식이 가장 흔한 구성입니다.

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT
  - name: AUTO
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    proxies: []        # 구독 노드는 보통 provider를 통해 주입됨

rules:
  - DOMAIN-SUFFIX,openai.com,PROXY
  - DOMAIN-KEYWORD,github,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

이 다섯 개 규칙은 그대로 사용할 수 있는 최소 골격입니다. 앞의 두 줄은 확실히 프록시가 필요한 도메인을 PROXY 그룹으로 보내고, 세 번째는 내부망을 통과시키며, 네 번째는 소속 국가가 중국 본토인 IP를 직결시키고, 마지막 줄은 나머지 모두를 프록시로 보냅니다. 일상적인 확장은 앞쪽에 더 정확한 도메인 규칙을 추가하는 방식으로 이뤄집니다.

유지 관리 원칙을 마지막으로 한 번 더 강조합니다. 커스텀 규칙은 구독 파일에 직접 쓰지 마세요(다음 갱신 때 덮어써짐). 클라이언트의 오버라이드 기능으로 구독 규칙 앞에 주입하세요. 규칙은 앞쪽일수록 우선순위가 높으므로 '내 규칙이 위, 구독 규칙이 중간, GEOIP와 MATCH가 맨 아래'라는 3단 구조가 안정적입니다. GEOIP 판단은 로컬 데이터베이스에 의존하므로 오랫동안 갱신하지 않으면 국가 판단 오류가 생길 수 있습니다. 갱신 방법은 8장에서 설명합니다.

시스템 프록시에는 본질적인 한계가 있습니다. 이는 하나의 '권고'일 뿐이며 따를지 말지는 애플리케이션이 스스로 결정합니다. 브라우저는 대부분 따르지만, 많은 게임이나 채팅 프로그램, UDP를 사용하는 프로그램은 프록시 설정을 전혀 보지 않습니다. TUN 모드는 다른 방식을 취합니다. 코어가 가상 네트워크 카드를 만들고 라우팅 규칙과 함께 시스템 전체의 아웃바운드 트래픽을 이 카드로 유도합니다. 애플리케이션은 이를 전혀 인지하지 못합니다. 이들 입장에서는 네트워크가 원래 이렇게 구성된 것처럼 보입니다. '모든 프로그램이 예외 없이 분流를 타게 하려면' TUN이 정답입니다.

설정 예시

tun:
  enable: true
  stack: system          # system / gvisor / mixed 중 선택
  auto-route: true       # 라우팅 테이블 자동 설정
  auto-detect-interface: true
  dns-hijack:
    - any:53             # 53번 포트로 향하는 DNS 쿼리를 가로챔

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

항목별 설명: stack은 가상 네트워크 카드의 프로토콜 스택 구현 방식입니다. system은 OS에 의존하며 성능이 좋고, gvisor는 사용자 공간 구현으로 호환성 문제가 적으며, mixed는 둘의 절충안입니다. Linux에서는 보통 system을 먼저 시도합니다. auto-route와 auto-detect-interface는 라우팅 테이블을 자동으로 추가·삭제해 트래픽은 가상 네트워크 카드로, 코어 자체의 아웃바운드 트래픽은 물리 네트워크 카드로 흐르게 합니다. 이를 켜지 않으면 라우팅을 수동으로 관리해야 하고 자칫 스스로 네트워크를 차단당한 상태에 빠질 수 있습니다.

TUN이 DNS를 반드시 관리해야 하는 이유

TUN이 받는 것은 IP 계층 트래픽이므로 DNS 해석이 여전히 시스템 계층에서 이뤄지면 코어는 IP만 보게 되어 도메인 기준 분流가 불가능해집니다. 그래서 dns-hijack이 DNS 쿼리도 함께 가로챕니다. fake-ip 모드는 여기서 한 걸음 더 나갑니다. 코어가 각 도메인 쿼리에 예약된 대역의 가짜 IP를 먼저 반환하고, 애플리케이션은 이 가짜 IP로 연결을 시도하며, 코어는 가짜 IP로 역으로 도메인을 조회해 규칙 매칭을 수행합니다. 실제 해석 한 번을 건너뛰어 지연이 낮아집니다. 부작용으로 IP를 검증하는 일부 프로그램이 오작동할 수 있는데, 그럴 때는 redir-host 모드로 바꾸거나 특정 도메인에 fake-ip-filter 제외 설정을 추가하면 됩니다.

Linux에서의 권한

가상 네트워크 카드 생성과 라우팅 변경에는 CAP_NET_ADMIN 권한이 필요합니다. 데스크톱 클라이언트는 '서비스 모드'가 가장 편합니다. 클라이언트가 시스템 서비스를 등록해 특권으로 코어를 실행하며, 인터페이스에서 TUN을 한 번의 클릭으로 켜고 끌 수 있습니다. 순수 코어 사용자는 setcap으로 바이너리에 권한을 부여해 매번 sudo를 쓰지 않아도 됩니다.

sudo setcap 'cap_net_admin,cap_net_bind_service=+ep' /usr/local/bin/mihomo

흔히 겪는 함정은 세 가지입니다. 첫째, TUN과 시스템 프록시를 동시에 켜두면 트래픽이 두 번 처리되므로 시스템 프록시 스위치를 꺼야 합니다. 둘째, 네트워크를 전환(랜선 재연결, 다른 Wi-Fi 연결 등)하면 NetworkManager가 라우팅을 다시 써서 연결이 끊길 수 있는데, TUN을 다시 켜서 auto-route가 라우팅을 재구성하도록 하면 됩니다. 셋째, 코어가 비정상 종료되어 라우팅 정리가 안 된 경우 Clash를 끄면 오히려 인터넷이 안 되는 현상이 나타나는데, 마찬가지로 '다시 켜고 끄기' 또는 네트워크 서비스 재시작으로 복구합니다. TUN을 켠 뒤에는 프록시 설정을 지원하지 않는 명령줄 프로그램으로 네트워크에 접속해보고, 클라이언트 연결 페이지에 해당 프로세스 이름이 뜨는지 확인하는 방식으로 검증할 수 있습니다.

설정이 잘 돌아가기 시작하면 유지 관리 작업은 사실 많지 않지만, 몇 가지를 습관으로 만들면 '갑자기 연결이 안 되는' 확률을 크게 줄일 수 있습니다.

정기적으로 갱신해야 할 세 가지

첫째는 구독입니다. 자동 갱신을 켜거나 매주 한 번 수동으로 눌러주세요. 노드가 바뀌어도 서비스 제공자가 일일이 알려주지 않습니다. 둘째는 GeoIP / Geosite 데이터베이스입니다. 6장의 GEOIP,CN,DIRECT는 로컬 데이터베이스를 기준으로 IP 소속 국가를 판단하는데, 데이터베이스가 오래되면 직결해야 할 트래픽이 프록시로 가거나 반대 상황이 생길 수 있습니다. 대부분의 클라이언트는 설정에서 한 번에 갱신하는 기능을 제공하고, 순수 코어는 설정 디렉터리의 데이터베이스 파일을 교체한 뒤 재시작하면 됩니다. 셋째는 클라이언트 자체입니다. 설치한 방법으로 그대로 업그레이드하세요. apt로 설치했으면 apt로 업그레이드, AUR로 설치했으면 시스템과 함께 롤링 업데이트합니다. 같은 기기에 설치 경로를 섞어 쓰지 마세요. '깨끗하게 제거되지 않고 두 버전이 충돌하는' 이상 현상의 원인이 됩니다.

로그 읽는 법 익히기

로그는 문제 진단의 가장 중요한 현장입니다. 설정에서 log-level: info는 일상적으로 사용하기 적당하고, 진단할 때는 임시로 debug로 올려 세부 정보를 확인한 뒤 문제 해결 후 다시 낮추세요(debug는 양이 많고 성능에 영향을 줍니다). 자주 보이는 로그 몇 줄은 익혀두면 좋습니다. dial tcp ... i/o timeout은 보통 노드에 접속할 수 없다는 뜻이고, connection refused는 목표 포트가 열려 있지 않거나 로컬 방화벽이 막고 있는 경우가 많습니다. 규칙 매칭 로그는 특정 연결이 실제로 어떤 규칙에 걸려 어떤 출구로 나갔는지 알려줍니다. 분流가 예상과 다를 때는 규칙을 무작정 고치기 전에 이 줄을 먼저 확인하세요. 항목별 해설은 기술 노트 《Clash 실행 로그 읽는 법》을 참고하세요.

백업과 복구

백업할 가치가 있는 것은 설정 디렉터리뿐입니다. 구독 주소, 오버라이드 파일, 커스텀 규칙이 모두 그 안에 있으니 하나로 묶어 일반 백업 루틴에 포함시키면 됩니다. 기기를 바꾸거나 재설치할 때 원래 경로에 풀어놓기만 하면 복원됩니다. 순수 코어라면 명령 한 줄이면 됩니다. tar czf mihomo-backup.tar.gz ~/.config/mihomo. 클라이언트를 쓴다면 먼저 설정에서 설정 디렉터리 경로를 확인한 뒤 압축하세요.

시작 시 자동 실행

데스크톱 클라이언트는 설정에서 자동 실행을 체크하면 됩니다. 서버의 순수 코어는 systemd로 관리하며 서비스 유닛을 작성합니다.

# /etc/systemd/system/mihomo.service
[Unit]
Description=mihomo daemon
After=network-online.target

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

[Install]
WantedBy=multi-user.target

이후 sudo systemctl enable --now mihomo 한 줄로 등록과 시작이 동시에 끝나고, journalctl -u mihomo -f로 로그를 실시간으로 확인할 수 있습니다. Restart=on-failure는 프로세스가 비정상 종료됐을 때 자동으로 재시작되게 하므로 장기간 무인 운영 환경에서는 반드시 설정해야 합니다.

마지막으로 진단의 대원칙 하나를 남깁니다. 한 번에 변수 하나만 바꾸세요. 포트를 바꿨다면 포트부터 검증하고, 노드를 바꿨다면 노드부터 테스트하세요. 세 곳을 동시에 바꾼 뒤 문제가 생기면 어디가 원인인지 알 수 없습니다. 실행 관련 오류(강제 종료, 흰 화면, 코어가 뜨지 않음)의 유형별 진단은 《Clash 클라이언트 실행 시 강제 종료 및 크래시 해결》을 참고하세요.

여기까지 8개 챕터를 마쳤다면 일상 사용에는 아무런 걸림이 없을 것입니다. 이 장은 더 깊이 들어가고 싶은 사용자를 위한 로드맵입니다. 각 방향마다 얻는 이점이 명확하니 필요에 따라 골라서 진행하면 되고, 모두 다 마스터할 필요는 없습니다.

방향 1: 오버라이드와 설정 병합

4장에서 구독 갱신이 로컬 변경을 덮어쓴다고 언급했는데, 오버라이드 기능이 이 문제의 해법입니다. 커스텀 포트, TUN 설정, 개인 규칙을 별도의 오버라이드 파일에 작성해두면 클라이언트가 구독을 불러올 때마다 자동으로 합쳐줍니다. Clash Verge Rev는 Merge(YAML 레벨의 필드 병합)와 스크립트(코드로 최종 설정을 재작성) 두 방식을 제공하는데, 전자는 대부분의 필요를 충족하고 후자는 정말 특수한 경우를 위한 것입니다. 오버라이드를 익히면 개인화된 설정이 구독과 완전히 분리되어, 구독이나 서비스 제공자를 바꿔도 자신의 설정은 그대로 유지됩니다.

방향 2: provider로 분리하기

proxy-providers와 rule-providers는 노드와 규칙을 메인 설정에서 분리해 각각 원격 또는 로컬 파일로 독립시키고 갱신 주기도 개별로 설정할 수 있게 합니다. 규칙 세트(rule-set)는 특히 유용합니다. 커뮤니티가 용도별로 분류한 도메인 목록을 관리하고 있어서, 설정에서는 도메인을 일일이 나열하는 대신 목록 이름만 참조하면 됩니다. 규칙표가 수백 줄에서 십여 줄로 줄어 가독성과 유지보수성이 크게 좋아집니다.

방향 3: 외부 제어 인터페이스

설정에 external-controller: 127.0.0.1:9090을 선언하면 코어가 RESTful 인터페이스를 열어 노드 전환, 연결 확인, 지연 측정 등을 모두 HTTP 요청으로 처리할 수 있습니다. 커뮤니티의 웹 패널과 함께 사용하면 브라우저에서 실행 중인 코어를 관리할 수 있는데, 이는 서버 환경의 표준적인 운영 방식이자 '클라이언트가 실제로 무엇을 대신해주는지'를 이해하는 가장 좋은 교재입니다. 클라이언트 화면의 모든 버튼은 결국 이 인터페이스의 어떤 호출을 실행하는 것에 불과합니다.

방향 4: 서버에서 순수 코어로 운영하기

8장의 systemd 유닛, 이 장의 외부 제어 인터페이스, 7장의 TUN을 조합하면 우회 게이트웨이나 소프트웨어 라우터의 완전한 구성이 됩니다. LAN의 기기들이 게이트웨이를 이 기기로 지정하면 집안의 모든 기기가 통일된 분流를 적용받고, 각 단말에는 아무것도 설치할 필요가 없습니다. 이 방향은 라우팅과 DNS 인프라를 직접 다루는 만큼, 실제 네트워크에 적용하기 전에 가상 머신에서 한 번 연습해보고 게이트웨이를 거치지 않는 별도의 관리용 접속 경로도 남겨두는 것을 권장합니다.

학습 자료 활용 순서

권장하는 참고 순서는 다음과 같습니다. 개념이 궁금하면 먼저 용어 사전을 확인하세요(코어와 클라이언트, 프록시 프로토콜, 규칙과 분流, 네트워크와 포트, 설정 파일 필드 다섯 분류로 정리되어 있습니다). 조작 절차는 사용 설명서를 다시 확인하세요. 구체적인 오류는 기술 노트의 진단 글을 항목별로 따라가세요. 자주 나오는 짧은 질문은 FAQ 콘텐츠에 대체로 답이 있습니다. 이 가이드도 코어와 클라이언트 생태계 변화에 따라 계속 수정됩니다. 실제 화면과 다른 부분이 있다면 클라이언트 안의 최신 문구를 기준으로 삼고, 접근 방식 자체는 바뀌지 않습니다.

숙련에는 왕도가 없지만 명확한 기준은 있습니다. 로그 한 줄을 보고 어느 단계에 속하는지 말할 수 있고, 낯선 설정을 받아 분流 동작을 예측할 수 있으며, 네트워크에 문제가 생겼을 때 어떤 모드로 먼저 바꿔야 할지, 어느 줄의 로그를 봐야 할지 아는 것입니다. 그 지점에 다다르면 이 가이드는 제 역할을 다한 것입니다. 좋은 결과가 있기를 바랍니다.