Clash 사용 설명서: 초보자부터 전문가까지 9단계

클라이언트 선택: 플랫폼별 설치 대상 정하기

각 플랫폼마다 선택할 수 있는 클라이언트는 하나 이상이지만, 대부분의 사용자에게는 선택 과정이 짧습니다. 아래 표는 다운로드 페이지의 패키지 목록과 일치하며, 플랫폼별로 우선 추천과 대안을 제시합니다.

Clash Plus를 우선 추천하는 이유

Clash Plus는 현재 Windows, macOS, Android, iOS 전 플랫폼을 아우르는 유일한 선택지로, 화면 구성과 조작 방식이 모든 기기에서 동일합니다. PC에서 익힌 구독 관리, 노드 전환, 모드 선택 방법을 휴대폰으로 옮겨도 다시 적응할 필요가 없습니다. mihomo 코어를 내장해 버전과 함께 업데이트되며 다국어 인터페이스를 지원해, Clash를 처음 접하는 사용자도 학습 비용이 가장 낮습니다. 여러 기기를 사용하는 사용자라면 특히 전 플랫폼에서 동일한 클라이언트를 통일해 사용하는 것을 추천합니다. 문제를 해결할 때 하나의 화면 구성만 기억하면 되기 때문입니다.

대안 클라이언트의 포지션

Clash Verge Rev와 FlClash는 모두 활발히 유지 관리되는 오픈소스 클라이언트입니다. 전자는 데스크톱에서 기능이 풍부하고 설정 오버라이드와 스크립트 확장을 지원해 설정을 손수 다루길 좋아하는 사용자에게 적합하며, Linux 데스크톱에서 추천하는 선택이기도 합니다. 후자는 Windows, macOS, Android, Linux를 아우르며 인터페이스가 간결합니다. Clash Nyanpasu는 Windows 버전만 제공합니다. Clash for Windows와 ClashX Meta는 둘 다 유지 관리가 중단되어 더 이상 코어와 보안 업데이트를 받지 못하며, 다운로드 페이지에 남겨둔 것은 기존 설정을 이전하기 위한 과도기용일 뿐이니 신규 사용자는 이들로 시작하지 말아야 합니다. 유지 관리 중단 배경은 사이트 내 관련 소식을 참고하세요.

대상을 정했다면 다운로드 페이지의 해당 섹션에서 설치 파일을 받으세요: Windows 클라이언트, macOS 클라이언트, 나머지 플랫폼은 같은 페이지 하단에 있습니다.

설치: 5개 플랫폼별 주의 사항

설치 자체는 복잡하지 않지만, 플랫폼마다 걸리기 쉬운 시스템 메커니즘이 하나씩 있습니다. 이 챕터는 플랫폼별로 설명하니, 사용 중인 기기에 해당하는 절만 골라 읽으면 됩니다.

Windows

다운로드한 설치 프로그램을 실행하고 안내에 따라 완료하면 됩니다. 두 가지 유의점이 있습니다. 첫째, Windows의 SmartScreen이 'PC를 보호했습니다'라는 차단 창을 띄울 수 있는데, 이는 다운로드 수가 적은 실행 파일에 대한 시스템의 일반적인 안내이므로 '추가 정보' → '실행' 순서로 눌러 계속 진행하면 됩니다. 둘째, 설치 경로에 한글이나 공백이 포함된 폴더는 피하세요. 일부 코어 기능(서비스 모드 등)은 경로에 민감합니다. 설치가 끝나고 처음 실행하면 클라이언트는 시스템 트레이에 아이콘을 상시 표시하며, 메인 창을 닫아도 종료된 것이 아니므로 이후 프록시 켜기/끄기는 트레이나 메인 화면을 통해 진행합니다. 7장의 TUN 모드를 사용할 계획이라면, 설정에서 미리 시스템 서비스를 설치해 코어가 충분한 권한으로 실행되도록 준비해 두는 것을 권장합니다.

macOS

dmg 이미지를 열고 앱 아이콘을 '응용 프로그램' 폴더로 끌어다 놓습니다. 처음 열 때 Gatekeeper가 개발자 확인 알림을 띄울 수 있는데, 차단되었다면 '시스템 설정 → 개인정보 보호 및 보안'으로 이동해 페이지 하단에서 '그래도 열기'를 찾으세요. 클라이언트가 처음 시스템 프록시나 TUN을 켤 때, 시스템은 네트워크 확장 설치나 네트워크 설정 변경 권한을 요청하며 관리자 비밀번호 입력이 필요합니다. 이는 macOS의 정상적인 권한 절차이며 거부하면 프록시가 작동하지 않습니다. Apple Silicon과 Intel 칩은 각각 다른 설치 파일을 사용하며, 다운로드 페이지에 별도로 나열되어 있으니 '이 Mac에 관하여'에서 칩 종류를 확인해 선택하세요.

Android

apk를 설치할 때 시스템이 '알 수 없는 앱 설치 허용'을 요구할 수 있으며, 팝업된 설정 화면에서 브라우저나 파일 관리자에 한 번 권한을 부여하면 됩니다. 프록시를 처음 켤 때 시스템이 VPN 연결 요청을 띄우는데 반드시 허용해야 합니다. Android 클라이언트는 VpnService를 통해 트래픽을 처리하므로 이 권한을 거부하면 전혀 작동하지 않습니다. 또한 클라이언트를 배터리 최적화 예외 목록에 추가하는 것을 권장합니다(설정 → 배터리 → 제한 없음). 그렇지 않으면 일부 제조사 시스템이 화면을 끈 뒤 백그라운드 프로세스를 종료해 '잠시 두면 프록시가 끊기는' 현상이 나타납니다.

iOS

iOS에서는 App Store를 통해 Clash Plus를 설치합니다. 스토어 진입 경로와 안내는 다운로드 페이지의 iOS 섹션을 참고하세요. 설치 후 처음 프록시를 켤 때 시스템이 VPN 설정 추가를 요청하는데, 팝업에서 허용하고 한 번 인증하면 이후 켜고 끌 때 다시 권한을 부여할 필요가 없습니다.

Linux

데스크톱 배포판은 deb 패키지를 예로 들면, 다운로드 후 터미널에서 다음을 실행합니다:

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

dpkg -i 대신 apt install을 사용하면 의존성을 자동으로 채워주는 장점이 있습니다. 설치 후에는 애플리케이션 메뉴에서 실행하며, TUN 모드를 사용할 경우 클라이언트가 권한을 가진 서비스 프로세스 설치를 안내합니다. 서버나 데스크톱 환경이 없는 경우 GUI 클라이언트가 필요 없으며 mihomo 코어를 직접 실행하면 되는데, 방법은 9장에서 설명합니다.

구독 가져오기: 클라이언트에 노드 전달하기

클라이언트를 설치하면 화면은 비어 있습니다. 노드가 하나도 없는데, 노드 정보는 서비스 제공업체가 구독을 통해 제공하기 때문입니다. 이 챕터는 가져오기, 업데이트, 흔한 실패 원인 세 가지를 다룹니다.

세 가지 가져오기 방법

가장 흔한 방법은 URL로 가져오기입니다. 서비스 제공업체의 사용자 패널에서 구독 링크를 복사하고(예: https://sub.example.com/token/clash.yaml) 클라이언트의 '설정' 또는 '구독' 화면을 열어 새로 만들기/가져오기를 누른 뒤 링크를 붙여넣고 확인합니다. 클라이언트는 즉시 해당 URL을 요청해 설정을 내려받고 모든 노드를 나열합니다. 두 번째는 클립보드 가져오기로, 일부 클라이언트는 클립보드에 구독 링크가 있음을 감지하면 가져올지 먼저 물어보는데, 본질은 URL 가져오기와 같습니다. 마지막은 로컬 파일 가져오기로, 이미 완성된 YAML 설정(예: 직접 관리하는 설정, 9장 참고)이 있다면 파일 형태로 바로 불러올 수 있지만, 이런 설정은 자동으로 업데이트되지 않으므로 변경 사항은 직접 수정해야 합니다.

업데이트 방식

URL로 가져온 구독은 업데이트를 지원합니다. 구독 항목의 새로고침 버튼을 눌러 클라이언트가 URL을 다시 요청하고 받아온 내용으로 로컬 설정을 전체 교체합니다. 대부분의 클라이언트는 자동 업데이트 주기 설정도 지원합니다(흔히 12시간 또는 24시간). 제공업체가 노드 주소를 바꾼 경우 구독을 한 번 업데이트하면 다시 사용할 수 있으며, '모든 노드가 갑자기 전부 타임아웃'되는 상황을 만나면 구독 업데이트가 언제나 첫 번째로 시도할 조치입니다. 주의할 점은 업데이트가 전체 교체 방식이라는 것입니다. 구독 설정에 직접 수동으로 한 수정은 덮어씌워지므로, 지속적으로 유지하고 싶은 커스터마이징은 클라이언트의 오버라이드 기능이나 별도의 로컬 설정을 통해 구현해야 합니다.

가져오기가 실패하는 세 가지 원인

첫째, 링크가 불완전하게 복사됨: 구독 URL은 보통 길어서 메신저로 전달할 때 잘리거나 줄바꿈이 섞이기 쉽습니다. 실패했다면 먼저 제공업체 패널로 돌아가 다시 복사하세요. 둘째, 네트워크 연결 문제: 일부 구독 서버는 접속에 특정 네트워크 조건이 필요하므로, 네트워크 환경을 바꿔 다시 시도해 볼 수 있습니다. 셋째, 형식 불일치: 구독은 Clash 형식과 그 외 형식으로 나뉘며, 가져오기에서 '분석 실패'가 뜨는 경우 대부분 Clash 형식이 아닌 링크를 사용한 것입니다. 제공업체 패널은 보통 여러 형식의 링크를 제공하니 Clash라고 표시된 것을 정확히 선택하세요.

가져오기가 성공하면 첫 연결을 진행할 수 있습니다. 노드 그룹 선택, 지연 시간 측정, 프록시 켜기와 검증까지 전체 흐름은 튜토리얼 페이지의 연결 단계를 참고하고, 지연 시간 수치를 더 자세히 해석하고 검증하는 방법은 《Clash 첫 연결 전체 과정》 글을 참고하세요.

프록시 모드와 포트: 트래픽이 어디로 들어와 무엇을 기준으로 흐르는가

노드에 연결한 뒤 경험을 좌우하는 것은 두 가지입니다. 코어가 어떤 모드로 트래픽의 방향을 정하는지, 시스템 트래픽이 어떤 진입점을 통해 코어로 전달되는지입니다.

세 가지 실행 모드

대부분의 시간은 규칙 모드에 두어야 합니다. 국내 트래픽은 직접 연결로 속도를 보장하고, 국외 트래픽은 규칙에 따라 프록시를 거칩니다. 전역 모드는 문제 해결용 도구일 뿐 일상적인 선택이 아닙니다. 장기간 전역 모드를 켜두면 국내 트래픽도 노드를 거치게 되어 속도와 트래픽 할당량 양쪽에서 손해를 보게 됩니다. 모드 전환의 구체적인 위치는 튜토리얼 페이지의 모드 선택 단계를 참고하세요.

인바운드 포트

코어는 로컬 포트를 감시해 트래픽을 받아들이며, 설정 파일 상단의 포트 섹션이 감시 동작을 결정합니다:

mixed-port: 7890        # HTTP와 SOCKS5 통합 포트, 하나로 통일해 사용 추천
allow-lan: false        # 같은 네트워크의 다른 기기 접속 허용 여부
mode: rule              # 시작 시 기본 모드
log-level: info         # 로그 레벨: silent / error / warning / info / debug
external-controller: 127.0.0.1:9090   # RESTful 제어 인터페이스, 패널형 도구에서 호출

mixed-port는 현재 주로 쓰이는 방식으로, 같은 포트에서 HTTP와 SOCKS5 두 종류의 프록시 요청을 모두 받아들여 예전 설정의 port와 socks-port를 분리해 쓰던 방식을 대체합니다. 7890은 관례적인 기본값일 뿐 강제 사항은 아니며, 이 포트가 다른 프로그램에 점유되었다면(클라이언트 로그에 bind 실패가 표시됨) 비어 있는 포트로 바꾸면 되지만 시스템 프록시 설정도 함께 맞춰야 합니다. allow-lan을 켜면 같은 네트워크에 있는 휴대폰, TV 등이 게이트웨이 프록시를 이 컴퓨터의 IP와 포트로 지정해 프록시 출구를 공유할 수 있습니다. 공용 네트워크 환경에서는 꺼두어야 합니다.

시스템 프록시: 애플리케이션의 트래픽을 넘겨받기

'시스템 프록시' 스위치를 켜면 클라이언트가 운영체제의 프록시 설정을 127.0.0.1:7890으로 지정하며, 시스템 프록시 설정을 따르는 브라우저 등의 애플리케이션은 자동으로 요청을 코어에 넘깁니다. 한계도 바로 여기에 있습니다. '시스템 프록시를 따르는' 애플리케이션만 적용되며, 많은 명령줄 도구와 일부 데스크톱 소프트웨어는 이 설정을 무시합니다. 이것이 바로 7장의 TUN 모드가 해결하려는 문제입니다. 시스템 프록시를 켰는데도 브라우저나 터미널이 프록시를 거치지 않는다면, 브라우저와 터미널 두 갈래로 각각 점검하세요. 방법은 《Clash 시스템 프록시가 작동하지 않을 때 점검법》을 참고하세요.

TUN과 DNS: 모든 트래픽 처리하기

5장에서 시스템 프록시의 한계를 이야기했습니다. 프록시 설정을 따르지 않는 프로그램은 다룰 수 없다는 것입니다. TUN 모드는 네트워크 계층에서 이 문제를 해결하며, 데스크톱 심화 활용의 분수령입니다.

TUN의 동작 방식

TUN을 켜면 코어가 시스템에 가상 네트워크 카드를 만들고 라우팅 테이블을 조정해 이를 기본 출구로 설정합니다. 이후 모든 네트워크 트래픽은 애플리케이션이 프록시 설정을 지원하는지와 무관하게 먼저 이 가상 네트워크 카드로 들어가고, 코어가 규칙에 따라 처리합니다. 결과적으로 '기기 단위 처리'와 같아, 명령줄 도구, 게임, 시스템 구성 요소의 트래픽까지 모두 분기 대상이 됩니다. 대가는 더 높은 권한이 필요하다는 점입니다. Windows에서는 서비스 모드로 코어 구성 요소를 설치해야 하고, macOS에서는 네트워크 확장 권한이 필요하며, Linux에서는 특권 서비스가 필요합니다. 각 클라이언트의 설정 화면에는 해당하는 원클릭 설치 진입점이 마련되어 있습니다. TUN을 켠 뒤에는 시스템 프록시 스위치를 꺼야 합니다. 둘을 동시에 켜는 것은 의미가 없고 루프백을 일으킬 수 있습니다.

DNS 처리와 Fake-IP

TUN 모드에서는 DNS를 반드시 코어가 처리하도록 해야 합니다. 그렇지 않으면 '트래픽은 프록시를 거쳤지만 도메인 해석은 로컬에서 평문으로 나가는' 유출이 발생할 수 있고, 도메인 기반 규칙도 제대로 작동하지 않을 수 있습니다. 설정 파일의 dns 섹션이 이 부분의 동작을 제어합니다:

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "+.local"
  nameserver:
    - https://doh.example.com/dns-query

enhanced-mode에는 두 가지 값이 있습니다. redir-host는 전통적인 경로로, 먼저 실제로 도메인을 해석한 뒤 그 결과에 따라 전달합니다. 동작이 직관적이지만 해석 지연이 한 번 더 발생하고, 해석 결과가 오염될 수 있습니다. fake-ip는 애플리케이션이 도메인을 조회하는 순간 예약된 대역(기본값 198.18.0.0/16) 안의 가상 주소를 즉시 반환하고, 코어가 '가상 IP ↔ 도메인' 매핑을 기록합니다. 애플리케이션이 이 가상 IP에 연결하면 코어가 도메인 기준으로 규칙을 매칭해 전달합니다. 장점은 응답이 빠르고 규칙 매칭이 항상 원래 도메인을 기준으로 이뤄진다는 점이고, 부작용은 실제 IP에 의존하는 일부 상황(같은 네트워크 내 기기 검색, 일부 내부망 서비스)에서 이상이 생길 수 있다는 것인데, 해당 도메인을 fake-ip-filter에 추가해 제외하면 됩니다. nameserver는 상위 해석이 방해받지 않도록 암호화 DNS(DoH/DoT)를 사용하는 것을 권장합니다.

TUN이 필요한 시점

판단 기준은 간단합니다. 필요한 작업이 모두 브라우저 안에서 일어난다면 시스템 프록시만으로 충분하니 TUN의 권한 복잡성을 들일 필요가 없습니다. 터미널 명령줄, 개발 도구, 게임 등 시스템 프록시를 읽지 않는 프로그램이 관련되면, TUN이 소프트웨어마다 프록시 환경 변수를 설정하는 것보다 훨씬 확실한 방법입니다. TUN이 제대로 작동하는지 확인하려면 터미널에서 직접 요청을 보내 출구 IP를 확인하면 되며, 방법은 튜토리얼 페이지의 검증 단계를 참고하세요.

일상 유지 관리: 업데이트, 로그, 문제 대조표

설정이 정상적으로 작동한 뒤에는 일상적으로 해야 할 일이 많지 않지만, 제대로 해두면 대부분의 갑작스러운 문제 해결을 줄일 수 있습니다.

항상 최신으로 유지해야 할 세 가지

구독: 자동 업데이트를 켜거나 며칠에 한 번씩 수동으로 새로고침하는 습관을 들이세요. 서비스 제공업체 쪽의 노드 변경은 업데이트해야만 동기화됩니다. 클라이언트와 코어: 클라이언트 업데이트에는 보통 코어 업데이트가 포함되며, 새 코어는 프로토콜과 규칙 기능의 발전을 따라가므로 새 버전 알림이 뜨면 바로 업그레이드하는 것을 권장합니다. Geo 데이터베이스: GEOIP 등의 규칙이 의존하는 지역 데이터베이스는 대부분의 클라이언트가 원클릭 업데이트 진입점을 제공하며, 데이터베이스가 오래되면 일부 IP 소속 판단에 오차가 생길 수 있습니다.

로그 읽는 법 익히기

클라이언트의 로그/연결 패널은 문제 해결에 가장 직접적인 창구입니다. 연결 화면에서는 각 활성 연결이 어떤 규칙에 일치했고 어느 출구로 나갔는지 볼 수 있어, '이 사이트가 왜 직접 연결됐지'와 같은 질문은 한눈에 답을 찾을 수 있습니다. 로그 화면은 코어 이벤트를 기록하며, 시작 실패, 포트 점유, 구독 가져오기 오류가 모두 여기에 명확한 정보로 남습니다. 각 패널의 기능 구성은 《Clash 클라이언트 화면 한눈에 보기》를 참고하세요. 어떤 문제든 점검하기 전에 로그 레벨을 잠시 debug로 올려 전체 정보를 확보하고, 해결한 뒤 info로 되돌리세요.

자주 발생하는 문제 빠른 점검

백업과 자동 시작

구독 URL, 오버라이드 스크립트, 직접 관리하는 로컬 설정은 비밀번호 관리자나 개인 노트에 사본을 남겨 두는 것을 추천합니다. 기기를 바꾸거나 재설치할 때 몇 분 안에 원래 상태로 복원할 수 있습니다. 데스크톱에서는 설정에서 '시작 시 실행'과 '자동 연결'을 켜두면 TUN이나 시스템 프록시와 함께 재부팅 후에도 수동 개입이 필요 없습니다. 서버 환경의 자동 시작 방안은 다음 챕터에서 설명합니다.

심화 로드맵: 설정을 사용하는 것에서 관리하는 것으로

여기까지 왔다면 클라이언트 차원의 활용 능력은 거의 완성된 셈입니다. 심화 방향은 설정에 대한 통제권을 점점 자신의 손으로 가져오는 것으로, 대략 세 단계로 나뉩니다.

1단계: 오버라이드와 수동 미세 조정

구독 업데이트는 설정을 전체적으로 덮어쓰므로, 지속적으로 유지되는 커스터마이징을 위한 올바른 방법은 클라이언트의 오버라이드(Override) 기능입니다. 여러분이 수정한 부분(규칙 추가, DNS 조정, 포트 변경)을 별도의 조각으로 작성해 두면, 클라이언트가 구독을 업데이트할 때마다 자동으로 병합합니다. 6장의 문법에 충분히 익숙해지면, 한 단계 더 나아가 완전히 직접 작성한 로컬 설정을 관리할 수도 있습니다. proxies 섹션은 구독에서 추출하고, 나머지 섹션은 원하는 대로 구성하면 됩니다. YAML을 작성할 때 가장 흔히 빠지는 함정은 들여쓰기입니다. 계층은 반드시 공백만 사용해야 하고 같은 레벨의 필드는 정확히 정렬되어야 하며, 탭 하나만 섞여도 설정 전체가 해석에 실패할 수 있습니다. 자세한 내용은 설정 구조 상세 설명 글을 참고하세요.

2단계: 코어 직접 실행

GUI 없이 mihomo 코어를 직접 실행하는 방식은 서버나 장기간 무인 운영 환경에 적합합니다. 다운로드 페이지의 코어 섹션에서 해당 아키텍처의 바이너리 파일을 받아 압축을 풀고 설정 디렉터리를 지정해 실행합니다:

# 설정 파일은 ~/.config/mihomo/config.yaml에 둡니다
./mihomo -d ~/.config/mihomo

# 설정 문법만 검증하고 시작하지 않음
./mihomo -t -d ~/.config/mihomo

-t 파라미터는 기억해 둘 만합니다. 설정을 수정한 뒤 먼저 한 번 검증을 실행하는 것이 시작 실패 후 로그를 뒤지는 것보다 효율적입니다. Linux에서는 systemd로 서비스 유닛을 하나 작성하면 부팅 시 자동 시작과 충돌 시 자동 재기동을 구현할 수 있습니다. external-controller를 켜면 웹 패널로 원격에서 연결 상태를 보고 노드를 전환할 수도 있어 GUI가 없는 불편함을 보완합니다.

3단계: 라우터와 서브 라우터 배포

코어를 라우터나 서브 라우터에서 실행하면, 집 안의 모든 기기—클라이언트를 설치할 수 없는 TV, 게임기까지—가 네트워크에 접속하는 것만으로 자동으로 분기 기능을 얻게 되어 기기 쪽에서는 설정이 전혀 필요 없습니다. 이 경로는 하드웨어 선택, 투명 프록시, DNS 처리, 자동 시작 감시 등 한 세트의 주제를 아우릅니다. 메인 라우터와 서브 라우터 두 가지 구성의 장단점과 전체 배포 방식은 《라우터와 서브 라우터에서 Clash 코어 직접 실행하기: mihomo 배포 방안 개요》를 참고하세요.