Clash 처음부터 완벽까지: 시스템 설정 매뉴얼

01 · 핵심 개념: 코어, 설정 파일, 구독

먼저 세 단어의 경계를 명확히 해두면 이후 모든 장이 이 세 개념 위에서 이해됩니다. 코어는 실제로 네트워크 트래픽을 처리하는 커맨드라인 프로그램으로, 현재 생태계의 주류 코어는 Mihomo(Clash Meta 프로젝트를 이어받음)이며 설정 파일을 읽어 규칙에 따라 각 연결이 어느 출구로 나갈지 결정합니다. 클라이언트는 코어를 감싸는 그래픽 인터페이스로, 구독 가져오기, 노드 전환, 시스템 프록시 켜고 끄기 같은 일상 작업을 담당합니다. 다운로드 페이지에 있는 Clash Plus, Clash Verge Rev, FlClash가 모두 이 계층에 속합니다. 구독은 서비스 제공자가 제공하는 URL로, 클라이언트가 이 주소에서 주기적으로 노드 목록과 사전 설정된 규칙을 가져와 최종적으로 코어에 전달할 설정을 합성합니다.

코어는 한 가지 입력만 인식합니다: YAML 형식의 설정 파일로, 보통 config.yaml이라 부릅니다. 이 파일은 고정된 최상위 구조를 가지며, 자주 쓰는 필드는 네 가지로 나눌 수 있습니다.

• mixed-port, allow-lan, mode, log-level 등 전역 파라미터로, 리스닝 포트와 실행 모드를 결정합니다.
• proxies: 노드 목록으로, 각 항목은 하나의 프록시 서버의 주소, 포트, 프로토콜, 인증 정보입니다.
• proxy-groups: 전략 그룹으로, "수동 선택" "자동 속도 테스트" 같은 전환 가능한 노드 집합을 구성합니다.
• rules: 분기 규칙으로, 위에서 아래로 순서대로 매칭하며 트래픽이 어느 전략 그룹으로 갈지 결정합니다.

가장 단순하게 실행 가능한 전역 파라미터 예시는 다음과 같습니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

mixed-port: 7890은 코어가 로컬 7890 포트에서 HTTP와 SOCKS5 두 프록시 프로토콜을 동시에 리스닝한다는 의미로, 시스템 프록시 설정을 이 포트로 지정하면 됩니다. allow-lan은 같은 네트워크의 다른 기기 접속을 허용할지 결정하며, 가정용 환경에서는 기본적으로 꺼져 있습니다. mode는 실행 모드를 결정하며 5장에서 자세히 다룹니다. log-level은 로그 상세도에 영향을 주며, 문제 해결 시 debug로 바꾸고 평소에는 info를 유지합니다.

구독과 설정 파일의 관계는 따로 설명이 필요합니다: 구독 링크가 반환하는 내용은 완전한 Clash YAML(바로 사용 가능)일 수도 있고, Base64로 인코딩된 노드 목록(클라이언트나 변환 서비스가 전략 그룹과 규칙을 추가해야 함)일 수도 있습니다. 두 형식의 차이와 상호 변환은 《Clash 구독 형식 완전 정리》 글을 참고하세요. 일상적으로는 설정을 직접 손으로 작성할 일이 거의 없습니다(클라이언트가 대신 합성해 줌). 다만 구조를 이해하는 것이 이후 규칙 수정, TUN 활성화, 증분 수정의 전제가 됩니다. 낯선 용어가 나오면 언제든 용어집을 참고하세요. 그곳은 "코어와 프로토콜 / 규칙과 분기 / 출구 전략" 등으로 분류해 자주 쓰는 용어를 정리해 두었습니다.

마지막으로 혼동하기 쉬운 부분: Clash 원본 프로젝트는 업데이트가 중단되었고, 지금 말하는 "Clash"는 대체로 전체 생태계를 가리킵니다—Mihomo 코어와 각종 그래픽 클라이언트를 합친 것입니다. 프로토콜 측면에서 Mihomo는 Shadowsocks, VMess, VLESS, Trojan, Hysteria2 등 주류 프로토콜을 지원하므로, 구독에 어떤 프로토콜의 노드가 있든 코어가 바로 사용할 수 있어 프로토콜에 따라 소프트웨어를 바꿀 필요가 없습니다. 이것이 Clash 계열 클라이언트를 선택하는 주요 이유 중 하나입니다: 하나의 구독으로 여러 프로토콜을 커버하고, 규칙 분기 기능도 통일되어 있습니다.

02 · 클라이언트 선택: 플랫폼과 요구사항 비교

클라이언트는 일상 사용 경험을 결정하고, 코어는 기능의 상한선을 결정합니다. 현재 주류 클라이언트는 모두 Mihomo 코어를 내장하고 있어 기능 차이는 크지 않으며, 선택은 주로 플랫폼 지원 범위와 인터페이스 취향에 달려 있습니다. 아래 표는 각 플랫폼별 선택지와 본 사이트의 추천 순서로, 다운로드 페이지 구성과 동일합니다.

사용 패턴별로 세 가지 선택 기준을 제시합니다. 처음 사용하고 설정을 파고들고 싶지 않다면: Clash Plus를 바로 설치하세요. 다섯 개 플랫폼 모두 버전이 있고, 구독 가져오기·모드 전환·노드 속도 테스트가 한 화면에 모여 있어 기본값 그대로 정상 작동하며, 여러 기기를 쓰는 사용자도 일관된 조작감을 유지할 수 있습니다. 설정을 세밀하게 조정하고 싶다면: Clash Verge Rev가 노출하는 코어 파라미터가 가장 풍부하고, 설정 증분 수정(9장에서 다룸)을 지원하며 TUN 스위치와 코어 로그가 모두 UI 상단에 있어 문서를 읽으며 조작하려는 사용자에게 적합합니다. Android에서 경량화를 원한다면: Clash Meta for Android가 가장 단순한 UI로 백그라운드 부담이 적고, FlClash는 크로스 플랫폼 일관성이 강점이라 데스크톱과 모바일에서 같은 조작 방식을 유지합니다.

두 가지 역방향 주의사항이 있습니다. 첫째, 예전 튜토리얼에서 자주 언급된다고 해서 Clash for Windows나 ClashX Meta를 설치하지 마세요—둘 다 개발이 중단되어 코어 버전이 과거에 멈춰 있고, 새 프로토콜 노드(예: Hysteria2)를 아예 인식하지 못할 수 있으며 문제가 생겨도 더 이상 수정되지 않습니다. 둘째, 한 기기에 여러 클라이언트를 동시에 설치할 필요는 없습니다. 모두 7890 포트를 리스닝하고 시스템 프록시를 접수하려 하므로 동시 실행하면 반드시 충돌이 발생합니다. 비교가 필요하다면 하나를 완전히 종료한 뒤 다른 하나를 실행하세요.

선택 기준의 전체 내용—코어 버전 정책, TUN 지원 정도, 설정 방식의 차이, "초보자 / 다중 기기 / 고급 사용자" 세 유형별 상세 결론—은 클라이언트 비교 페이지와 《주요 Clash 클라이언트 종합 비교》 글에서 확인할 수 있습니다. 이 매뉴얼의 이후 장에서는 Clash Plus와 Clash Verge Rev를 기준으로 설명하며, 다른 클라이언트는 메뉴 표현이 조금 다를 뿐 개념과 흐름은 완전히 동일합니다: "구독/설정" 항목을 찾아 가져오고, "모드" 항목을 찾아 전환하고, "시스템 프록시/TUN" 스위치를 찾아 트래픽을 접수하면 됩니다.

03 · 설치 및 최초 실행

설치 파일은 모두 다운로드 페이지에서 받으며, 플랫폼 탭을 전환한 뒤 해당 클라이언트와 아키텍처를 선택하세요. 이 장에서는 플랫폼별 설치 동작, 최초 실행 시 나타나는 시스템 안내, 각 플랫폼의 주요 디렉터리 위치를 정리합니다.

Windows

설치 프로그램을 실행하고 안내에 따라 완료하세요. 서명이 없거나 서명이 최근에 만들어진 설치 파일을 처음 실행하면 SmartScreen이 "Windows에서 PC를 보호했습니다"라는 창을 띄울 수 있는데, "추가 정보"를 누른 뒤 "실행"을 선택하면 계속 진행됩니다. 설치가 끝나면 시작 메뉴에서 실행하고, 클라이언트는 작업 표시줄 트레이에 상주합니다. 창이 보이지 않으면 트레이부터 확인하고 다시 실행하지 마세요. 시스템 프록시나 TUN을 처음 켤 때 관리자 권한(UAC 창)을 요청하면 허용해야 합니다. 실행 시 bind: address already in use 오류가 뜬다면 7890 포트가 다른 프로그램에 점유된 상태이며, 처리 방법은 《Clash 포트 충돌 해결법》을 참고하세요. 설정과 로그 디렉터리는 보통 %USERPROFILE%\.config 또는 앱 데이터 폴더 아래에 있으며, 클라이언트의 "폴더 열기" 메뉴로 바로 이동할 수 있습니다.

macOS

dmg를 열고 앱을 "응용 프로그램" 폴더로 드래그하세요. 설치 파일은 Intel용과 Apple Silicon용 두 종류로 나뉘므로 "이 Mac에 관하여"에서 칩 종류를 확인한 뒤 다운로드해야 합니다. 잘못된 아키텍처를 설치하면 눈에 띄게 느려지거나 실행되지 않을 수 있습니다. 최초 실행 시 Gatekeeper가 인터넷에서 받은 앱이라는 경고를 표시하는데, 팝업에서 "열기"를 누르거나 "시스템 설정 → 개인정보 보호 및 보안" 페이지 아래쪽에서 "그래도 열기"를 누르세요. 시스템 프록시를 켜면 클라이언트가 네트워크 환경설정을 변경하므로 로그인 비밀번호를 요구할 수 있고, TUN을 켜려면 시스템 확장 설치나 보조 프로그램 권한이 필요하니 안내에 따라 하나씩 허용하세요. 설정 디렉터리는 기본적으로 ~/.config 아래의 클라이언트 하위 폴더에 있습니다.

Android

apk 설치 시 "알 수 없는 앱 설치가 허용되지 않음" 안내가 나오면 시스템 설정에서 브라우저나 파일 관리자에 "알 수 없는 앱 설치" 권한을 부여하세요. 연결을 처음 누르면 시스템이 VPN 연결 요청 창을 띄우는데, 이는 Android가 트래픽을 접수하는 표준 방식이므로 반드시 허용해야 프록시가 작동합니다. 중국산 커스텀 OS(MIUI, ColorOS 등)에서는 클라이언트를 배터리 최적화 화이트리스트에 추가하고 백그라운드 실행을 허용해야 합니다. 그렇지 않으면 화면이 꺼진 후 일정 시간이 지나면 프로세스가 종료되어 "쓰다 보면 끊긴다"는 증상이 나타납니다.

iOS와 Linux

iOS는 App Store에서 Clash Plus를 설치하고, 최초 실행 시 프로파일 형식의 VPN 권한 요청이 뜨는데 마찬가지로 허용하면 됩니다. Linux 데스크톱 배포판은 deb 패키지로 Clash Verge Rev를 설치하고(sudo apt install ./패키지명.deb), TUN을 켜려면 코어에 네트워크 권한을 부여해야 하는데 클라이언트 설정에 원클릭 권한 부여 버튼이 있습니다. 데스크톱 환경이 없는 서버라면 Mihomo 코어 바이너리를 직접 받아 systemd로 운영하는데, 이는 9장의 심화 내용에 해당합니다.

어떤 플랫폼이든 최초 실행 후 세 가지를 해두는 것을 권장합니다: 로그 화면을 열어 빨간색 오류가 없는지 확인하고, 설정 디렉터리 위치를 기억해두고(백업과 문제 해결에 필요), 기본 포트와 DNS 설정은 아직 손대지 마세요—기본값은 대부분의 환경에 맞춰져 있으며, 변경은 이유를 명확히 안 이후에 해야 합니다. 클라이언트가 열자마자 꺼진다면 《실행 시 크래시 및 강제 종료 해결법》의 순서대로 로그부터 확인하세요.

04 · 구독 가져오기와 업데이트

구독 링크는 서비스 제공자가 제공하며, 보통 사용자 패널의 "구독 / 원클릭 가져오기" 위치에 있고 형식은 https://example.com/api/v1/client/subscribe?token=xxxx와 같습니다. 이 URL은 계정 인증 정보와 같아서—다른 사람에게 유출하는 것은 계정을 공유하는 것과 같습니다—공개된 곳에 붙여넣지 말고, 스크린샷을 찍을 때도 가려주세요.

세 가지 가져오기 방법

1. URL 가져오기(추천): 클라이언트의 "구독 / 설정" 화면에 링크를 붙여넣고 가져오기를 누르세요. 클라이언트가 이 주소를 기억해 이후 원클릭 업데이트나 주기적 자동 갱신을 설정할 수 있고 노드 변경도 자동으로 반영됩니다. "지속적으로 동기화"할 수 있는 유일한 방법입니다.
2. 파일 가져오기: 서비스 제공자가 준 YAML 파일을 직접 끌어다 놓거나 선택해 가져옵니다. 오프라인 환경에 적합하지만, 노드가 갱신되면 수동으로 파일을 바꿔야 하는 단점이 있습니다.
3. 클립보드 / QR코드 가져오기: 모바일에서 흔하며, 본질은 URL 가져오기와 같고 입력 경로만 다릅니다.

가져오기 성공 여부는 이렇게 판단합니다: 구독 항목 아래에 노드 목록이 펼쳐지고, 전략 그룹 화면에서 그룹이 보이면 성공입니다. 가져오기 오류가 나면 세 단계로 원인을 찾습니다: 먼저 브라우저에서 구독 링크를 직접 열어 YAML이나 Base64 텍스트가 보이면 링크 자체는 유효합니다. 다음으로 클라이언트 오류 메시지의 핵심 단어를 확인하는데, invalid syntax 계열은 형식 불일치를, 타임아웃 계열은 네트워크 문제를 가리킵니다. 마지막으로 구독 형식과 클라이언트가 일치하는지 확인하세요—일부 서비스 제공자는 클라이언트별로 다른 형식의 링크를 제공하므로 "Clash" 항목을 선택해야 합니다. 일부 서비스는 요청의 User-Agent도 검사해 Clash 계열 UA에만 YAML을 반환하므로, 브라우저에서 열었을 때 깨진 글자가 나오는 것은 정상입니다.

업데이트 전략

구독은 한 번 가져오면 끝나는 것이 아닙니다: 서비스 제공자는 노드 도메인과 포트를 계속 바꾸므로 이전 설정의 노드는 점차 무효화됩니다. 클라이언트에서 자동 업데이트 주기를 12~24시간으로 설정하고, "어제까지 되던 게 오늘 다 타임아웃" 상황이 오면 가장 먼저 구독을 수동으로 한 번 업데이트해보세요. 업데이트가 실패할 때는 순환 문제에 주의해야 합니다: 구독 주소 자체가 프록시를 거쳐야 접속되는 경우가 있는데, 대부분의 클라이언트는 "프록시로 업데이트" 스위치를 제공하니 아직 살아 있는 노드가 있다면 이를 켜세요. 전부 죽었다면 다른 네트워크 환경(예: 휴대폰 테더링)으로 바꿔서 업데이트해야 합니다.

구독 변환

구독 형식이 클라이언트와 맞지 않을 때(예: 범용 Base64 노드 목록인데 클라이언트는 완전한 YAML만 인식하는 경우), 구독 변환 서비스를 거쳐야 합니다: 변환기가 원본 구독을 가져와 규칙 템플릿을 씌워 표준 Clash 설정을 출력합니다. 변환 원리, 공개 변환 서비스의 개인정보 위험(변환기가 구독 내용을 볼 수 있음), 자체 구축 방안은 《Clash 구독 형식 완전 정리》에서 자세히 다룹니다. 원칙적으로 클라이언트가 직접 처리할 수 있는 구독은 변환기를 거치지 않는 것이 좋습니다. 경로가 짧을수록 안정적입니다.

여러 구독을 쓰는 사용자를 위한 관리 팁: 각 구독은 독립된 설정 항목으로 유지하고, 여러 서비스의 노드를 하나의 파일로 수동 합치지 마세요—합치면 개별 업데이트가 불가능해지고 문제 발생 시 노드 출처도 구분할 수 없습니다. 구독 간 노드를 통합해야 할 때는 proxy-providers 메커니즘(9장)을 써서 코어가 실행 중에 가져와 합치도록 하고, 정적 파일을 직접 수정하지 마세요.

05 · 프록시 모드: 규칙, 전체, 직접 연결

코어에는 세 가지 실행 모드가 있으며, 설정 파일의 mode 필드가 취할 수 있는 세 값에 해당하고 클라이언트 화면에서는 보통 하나의 라디오 버튼 그룹으로 표시됩니다.

일상적으로는 규칙 모드에 두어야 합니다. 이 모드의 가치는 분기에 있습니다: 국내(중국 본토) 사이트 접속은 직접 연결되어 노드 트래픽을 소모하지도 지연을 늘리지도 않고, 해외 트래픽은 규칙에 따라 프록시를 타며, 광고 도메인은 바로 차단할 수 있습니다. 전체 모드는 문제 해결용 도구이지 상시 사용할 상태가 아닙니다—모든 트래픽이 프록시를 거치면 국내 사이트도 크게 돌아가야 해서 속도가 느려지고 트래픽 소모도 두 배가 됩니다. 실용적인 문제 해결 방법 하나: 특정 사이트가 안 열리면 먼저 전체 모드로 전환해보고, 열리면 규칙이 제대로 매칭되지 않은 것이니 6장으로 돌아가 규칙을 수정하고, 여전히 안 열리면 노드 문제이니 노드를 바꾸거나 속도 계층별 진단을 참고하세요.

모드 이외: 트래픽이 코어에 들어가는 방식

모드는 트래픽이 코어에 들어간 후 어떻게 흐르는지를 결정하고, 트래픽이 코어에 들어갈 수 있는지는 별도의 스위치가 결정합니다: 시스템 프록시입니다. 켜면 운영체제가 HTTP/HTTPS 트래픽을 127.0.0.1:7890으로 보내고, 브라우저와 시스템 프록시 설정을 따르는 대부분의 앱이 이에 따라 작동합니다. 다만 일부 프로그램(커맨드라인 도구, 일부 게임과 클라이언트 소프트웨어)은 시스템 프록시를 읽지 않아 트래픽이 코어를 우회합니다—이것이 "브라우저는 되는데 터미널은 안 되는" 전형적인 이유이며, 해결법은 두 가지입니다: 해당 프로그램에 개별적으로 프록시 환경 변수를 설정하거나(예: HTTP_PROXY=http://127.0.0.1:7890), 아예 7장의 TUN 모드로 시스템 전체를 접수하는 것입니다.

연결 확인

모드를 설정한 뒤에는 순서대로 세 가지를 확인합니다: 클라이언트의 "연결" 화면에 활성 연결 항목이 보이면 트래픽이 실제로 코어에 들어간 것이고, 항목의 출구 열에 예상한 전략 그룹과 노드가 표시되면 규칙이 정확히 매칭된 것이며, 브라우저로 해외 사이트에 접속되면 전체 경로가 정상 작동하는 것입니다. 세 단계 중 어디에서 막혔는지가 바로 확인해야 할 계층입니다—이것이 사이트 전체의 기본적인 문제 해결 방법론입니다: 먼저 계층을 찾고, 그다음 수정하세요. 전략 그룹의 선택(수동 노드 선택인지 자동 속도 테스트인지)은 경험에 직접 영향을 주는데, 그룹 유형의 차이는 다음 장에서 규칙과 함께 다룹니다.

06 · 규칙 분기: 문법, 우선순위, 전략 그룹

규칙은 Clash의 핵심 기능으로, 설정의 rules 목록에 작성되며 각 규칙은 3단 구성입니다: 유형,매칭값,출구. 코어는 새 연결마다 위에서 아래로 순서대로 매칭하며 걸리면 즉시 멈춥니다—순서가 곧 우선순위이며, 이것이 모든 분기 문제를 이해하고 디버깅하는 핵심 키입니다. 자주 쓰는 규칙 유형:

구조가 완전한 규칙 예시로, 주석에 정렬 논리를 표시했습니다.

rules:
  # 정확 매칭 규칙을 앞에: 우선순위가 가장 높은 수동 오버라이드
  - DOMAIN-SUFFIX,openai.com,PROXY
  - DOMAIN-SUFFIX,github.com,PROXY
  # 사설망과 예약 주소는 직접 연결, no-resolve로 순수 도메인 연결의 불필요한 해석 방지
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  # 지역 판별 기본값: 국내(중국 본토) IP는 직접 연결
  - GEOIP,CN,DIRECT
  # 최종 기본값: 위에서 걸리지 않은 나머지는 프록시로
  - MATCH,PROXY

자주 쓰이는 문법 요점 세 가지. 첫째, DOMAIN-SUFFIX,github.com은 github.com과 api.github.com을 모두 매칭하지만 github.io는 매칭하지 않습니다—접미사 매칭은 점(.)을 경계로 합니다. 둘째, GEOIP와 IP-CIDR은 대상 IP를 매칭하는데, 연결 대상이 도메인이면 코어가 먼저 DNS 해석을 해야 비교할 수 있습니다. 내부망 대역 규칙에 no-resolve를 추가하면 모든 도메인 연결이 강제로 미리 해석되는 것을 막아 지연과 DNS 유출 범위를 줄일 수 있습니다. 셋째, MATCH 뒤에 오는 규칙은 절대 실행되지 않으므로 새 규칙은 반드시 그 앞에 넣어야 합니다. "규칙을 수정했는데 적용이 안 된다"는 문제의 첫 번째 확인 포인트는 더 앞선 규칙에 먼저 걸린 건 아닌지 보는 것입니다—클라이언트의 "연결" 화면에는 각 연결이 실제로 매칭된 구체적인 규칙이 표시되니 이를 기준으로 확인하세요.

전략 그룹: 규칙의 출구

규칙의 세 번째 항목인 출구는 내장된 DIRECT(직접 연결)와 REJECT(차단) 외에는 대부분 전략 그룹을 가리킵니다. 전략 그룹은 노드를 전환 가능한 집합으로 구성하며 자주 쓰는 유형은 네 가지입니다: select는 수동 선택으로 화면에서 고르는 노드를 사용하고, url-test는 테스트 주소로 주기적으로 요청을 보내 지연이 가장 낮은 노드를 자동으로 선택하며, fallback은 목록 순서대로 첫 번째로 사용 가능한 노드를 사용해 1순위가 죽으면 자동으로 다음 노드로 넘어가고, load-balance는 연결을 여러 노드에 분산시킵니다. 예시:

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - HK-01
      - JP-01
  - name: AUTO
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    proxies:
      - HK-01
      - JP-01

이 구조는 널리 쓰이는 모범 사례입니다: PROXY는 규칙이 가리키는 총 진입점으로 수동 선택 유형이며, 첫 번째 옵션이 자동 속도 테스트 그룹 AUTO입니다. 평소에는 이를 선택해 자동 최적화를 누리고, 특수한 요구(예: 특정 지역 고정)가 있을 때만 수동으로 구체적인 노드로 전환하면 됩니다. interval: 300은 5분마다 재측정한다는 의미입니다. 구독에 기본 포함된 설정도 보통 이런 구조를 이미 갖고 있으니, 이 구조를 이해하면 어떤 구독 설정이든 읽을 수 있고 9장에서 직접 설정을 수정할 기초도 다질 수 있습니다.

07 · TUN 모드와 시스템 수준 접수

5장에서 시스템 프록시의 사각지대를 언급했습니다: 프록시 설정을 읽지 않는 프로그램은 코어를 우회합니다. TUN 모드는 더 근본적인 층위에서 이 문제를 해결합니다—코어가 가상 네트워크 카드를 만들고 운영체제의 기본 라우팅을 이쪽으로 지정해, 모든 IP 트래픽(프로그램이 프록시를 지원하는지 여부, TCP인지 UDP인지 무관하게)이 먼저 코어를 거친 후 규칙에 따라 분기됩니다. 커맨드라인 도구, 게임, UDP 음성 통화까지 모두 커버됩니다. 대가로 더 높은 시스템 권한이 필요하고, 라우팅을 수정하는 다른 소프트웨어와는 상호 배타적입니다.

설정과 파라미터

주요 클라이언트는 TUN을 하나의 스위치로 만들어 두었으며(Clash Verge Rev는 설정 화면에, Clash Plus는 연결 방식 옵션에), 스위치 뒤에는 설정의 이 부분이 대응합니다.

tun:
  enable: true
  stack: system
  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를 가로채지 않으면 앱이 직접 해석한 IP로 바로 접속해버려 도메인 계열 규칙이 통째로 무력화될 수 있습니다.

플랫폼별 권한 요구사항

Windows에서는 처음 켤 때 관리자 권한을 요청하고 가상 네트워크 카드 드라이버를 설치하므로 UAC 창을 허용해야 합니다. 켠 후 시스템 전체가 인터넷이 끊긴다면 보통 드라이버 설치가 불완전한 경우이니 시스템을 재부팅하고 다시 켜보세요. macOS는 시스템 확장 권한이 필요해 "시스템 설정 → 개인정보 보호 및 보안"에서 허용해야 하며, 최신 버전에서는 "로그인 항목 및 확장"에서도 확인이 필요할 수 있습니다. Linux는 코어 바이너리에 CAP_NET_ADMIN 권한을 부여해야 하는데, Clash Verge Rev 설정의 권한 부여 버튼이 대신 처리해줍니다. Android와 iOS 클라이언트는 이미 VPN 서비스 방식으로 동작하고 있어 TUN과 본질적으로 동일하므로 추가 작업이 필요 없습니다.

사용 범위와 흔한 함정

• TUN과 시스템 프록시를 동시에 켤 필요는 없습니다. TUN을 켰다면 시스템 프록시는 꺼두는 것이 좋습니다. 트래픽이 두 번 접수되는 것을 피해 문제 해결 난이도가 괜히 올라가는 것을 막을 수 있습니다.
• TUN은 다른 VPN이나 가상 네트워크 카드 소프트웨어와 상호 배타적입니다—두 프로그램이 기본 라우팅을 두고 경쟁하면 대부분 인터넷이 끊깁니다. TUN을 켜기 전에 다른 VPN 계열 소프트웨어를 먼저 종료하세요.
• 켠 후에는 모든 트래픽이 코어를 거치므로 규칙의 완성도가 경험을 좌우합니다: GEOIP,CN,DIRECT 같은 직접 연결 기본값은 반드시 있어야 하며, 없으면 시스템 업데이트나 클라우드 동기화 같은 대용량 트래픽이 모두 프록시를 타게 됩니다.
• 클라이언트를 종료했는데도 인터넷이 끊긴 상태라면 라우팅이 완전히 정리되지 않은 것이니, 네트워크 인터페이스를 재시작하거나 시스템을 재부팅하면 복구됩니다. 이런 문제의 더 자세한 처리법은 헬프 센터의 문제 해결 분류를 참고하세요.

한 줄로 정리하면: 브라우저 위주의 가벼운 사용자는 시스템 프록시만으로 충분하고 권한도 깔끔합니다. 커맨드라인, 게임, 임의의 UDP 앱까지 커버해야 하는 사용자는 바로 TUN을 쓰세요. 한 번 설정해두면 "켜놓고 잊어버려도 되는" 안정적인 상태가 됩니다.

08 · 일상 관리: 업데이트, 백업, 빠른 진단

설정을 마친 후 Clash의 일상 관리 부담은 크지 않지만, 주기적으로 해두면 대부분의 "갑자기 안 되는" 상황을 피할 수 있는 몇 가지가 있습니다.

세 가지 업데이트

구독 업데이트가 가장 빈도가 높습니다: 자동 업데이트(12~24시간)를 켜두는 것 외에, "노드 전체가 타임아웃"되는 순간이 오면 먼저 구독을 수동으로 한 번 업데이트하고 문제를 진단하세요. GeoIP / Geosite 데이터베이스 업데이트는 놓치기 쉽습니다: 6장의 GEOIP,CN 규칙은 로컬 IP 국가 데이터베이스에 의존하는데, 데이터베이스가 오래되면 일부 국내(중국 본토) IP가 해외로 오판되어 불필요하게 프록시를 타면서 "국내 사이트가 이상하게 느려지는" 현상이 나타납니다. 주요 클라이언트는 설정에 원클릭 업데이트 버튼을 제공하니 한두 달에 한 번씩 눌러주고, 업데이트 후 코어를 재시작해야 적용됩니다. 클라이언트와 코어 업데이트: 클라이언트는 보통 자체 업데이트 확인 기능이 있으며, 업그레이드 전에는 다음 항목의 백업을 먼저 해두세요. 새 기능을 급하게 쫓지 않는다면 안정적으로 도는 버전을 자주 올릴 필요는 없습니다.

무엇을, 어떻게 백업할까

백업할 만한 것은 세 가지뿐입니다: 구독 링크 자체(비밀번호 관리자에 저장해두면 새 기기에서도 모든 걸 복구할 수 있음), 직접 수정한 설정이나 오버라이드 조각, 클라이언트 설정 내보내기(내보내기 기능을 제공하는 경우). 설정 디렉터리 전체를 압축해두는 것도 괜찮지만 캐시와 로그는 백업할 가치가 없습니다. 기기를 옮길 때 표준 절차는 다음과 같습니다: 새 기기에 클라이언트 설치 → 구독 링크 붙여넣기 → 커스텀 조각 복원, 5분이면 끝나고 바이너리 파일을 옮길 필요는 없습니다.

로그: 문제 해결의 첫 현장

모든 문제 해결은 추측이 아니라 로그에서 시작해야 합니다. 클라이언트 화면의 로그 페이지에는 코어 실행 로그가 표시됩니다: error 등급 줄은 실패 원인(포트 점유, 설정 문법 오류, 노드 핸드셰이크 실패)을 직접 알려주고, info 등급은 각 연결의 매칭 과정을 보여줍니다. 화면 로그가 부족하면 설정 디렉터리에 완전한 로그 파일이 있습니다. log-level을 임시로 debug로 바꾸면 DNS 해석과 규칙 매칭의 모든 단계를 볼 수 있는데, 확인 후에는 다시 info로 돌려놓으세요. debug 로그는 양이 매우 많습니다.

빠른 진단 표

표의 네 번째 행 "시스템 시간 오차"는 따로 짚을 만합니다: VMess 등 프로토콜은 시간에 민감해서 로컬 시간이 약 90초 이상 차이 나면 핸드셰이크가 바로 실패해 해당 프로토콜의 모든 노드가 동시에 타임아웃되는데, 증상이 구독이 죽은 것과 매우 비슷합니다. 문제 해결 시 "시스템 시간이 자동 동기화되고 있는지"를 일상 점검 항목에 포함하세요. 더 세부적인 질의응답 형식의 내용은 헬프 센터에 기본 개념, 설치 및 설정, 사용 팁, 문제 해결 네 가지로 정리되어 있습니다.

09 · 심화 로드맵: 오버라이드, 외부 제어, 커맨드라인 코어

1장부터 8장까지 마쳤다면 일상적인 사용에는 이미 충분합니다. 이 장에서는 더 깊이 들어가려는 사용자를 위해 투입 비용이 낮은 순서부터 세 가지 경로를 제시합니다.

경로 1: 설정 오버라이드, 구독 원본은 건드리지 않기

구독으로 생성된 설정 파일을 직접 편집하는 것은 초보자가 자주 하는 실수입니다—다음 구독 업데이트 때 수정 내용이 전부 덮어씌워집니다. 올바른 방법은 오버라이드(override)입니다: 수정 내용을 독립된 조각으로 작성해두면 클라이언트가 매 구독 업데이트 후 자동으로 최종 설정에 병합해줍니다. Clash Verge Rev는 YAML 병합과 스크립트 두 가지 오버라이드 방식을 지원하며, 대표적인 용도는 구독 규칙 맨 앞에 자신만의 고우선순위 규칙을 삽입하거나, 직접 관리하는 노드를 추가하거나, 구독의 비합리적인 속도 테스트 주기를 강제로 바꾸는 것입니다. 규칙 목록 앞부분에 두 줄을 추가하는 최소한의 병합 오버라이드 예시입니다.

prepend-rules:
  - DOMAIN-SUFFIX,internal.example.com,DIRECT
  - DOMAIN-KEYWORD,tracker,REJECT

오버라이드와 마찬가지로 "관리 위임" 사상에 속하는 것으로 proxy-providers / rule-providers가 있습니다: 코어가 실행 중에 URL에서 노드 세트와 규칙 세트를 가져와 주기적으로 갱신하도록 하고, 메인 설정에는 참조만 작성합니다. 여러 구독 통합이나 커뮤니티에서 관리하는 규칙 세트(예: 광고 도메인 목록)는 모두 이 두 메커니즘에 의존하며, 수동 복사-붙여넣기로 하지 않습니다.

경로 2: 외부 제어 API

코어에는 자체 HTTP 제어 인터페이스가 내장되어 있으며, 설정에 두 줄만 추가하면 켜집니다.

external-controller: 127.0.0.1:9090
secret: "your-password"

켜면 노드 전환, 모드 변경, 연결 조회, 지연 측정을 모두 HTTP 요청으로 처리할 수 있습니다—클라이언트 화면은 본질적으로 이 API의 프론트엔드일 뿐입니다. 이를 익히면 할 수 있는 일들: 웹 대시보드(클라이언트에 보통 내장된 진입점)로 브라우저에서 코어를 관리하거나, 스크립트로 정기적으로 속도를 측정하고 전략 그룹을 자동 전환하거나, 홈 서버 환경에서 화면 없는 코어를 원격으로 관리할 수 있습니다. 지켜야 할 보안 원칙 두 가지: secret은 반드시 설정하고 충분히 무작위여야 하며, 리스닝 주소는 127.0.0.1로 유지하고 정말 같은 네트워크에서 접근해야 한다면 방화벽으로 접근 원본을 제한하세요.

경로 3: 커맨드라인으로 Mihomo 코어 직접 실행

서버, 소프트 라우터, NAS처럼 데스크톱 환경이 없는 경우, 그래픽 클라이언트를 건너뛰고 코어를 직접 실행합니다. 다운로드 페이지의 코어 항목에서 각 아키텍처용 바이너리를 제공합니다. 기본 사용법은 mihomo -d /etc/mihomo이며, -d로 지정한 디렉터리에 config.yaml과 지리 데이터베이스를 넣어둡니다. systemd로 서비스 유닛을 작성해 부팅 시 자동 시작과 크래시 시 재시작을 구현하고, 경로 2의 제어 API로 원격 관리하면 온 집안의 트래픽을 분기하는 게이트웨이의 초기 형태가 됩니다. 이 경로는 1장부터 6장까지의 설정 구조를 완전히 이해했다는 전제가 필요합니다—여기까지 오면 "처음부터 완벽까지"의 순환이 완성됩니다.

추천 학습 순서

1. 이 페이지 6장의 규칙 문법을 자신의 설정에서 실제로 검증해보세요: 규칙 하나를 추가하고 연결 화면에서 매칭 여부를 확인합니다.
2. 오버라이드 메커니즘으로 자주 쓰는 수정 사항을 고정해보고, "구독을 업데이트해도 수정 내용이 사라지지 않는" 작업 흐름을 체감해보세요.
3. 외부 제어를 켜고 하루 동안 클라이언트 화면 대신 브라우저 대시보드로 조작해보며 코어와 화면의 경계를 이해해보세요.
4. 여유 있는 기기가 있다면 커맨드라인으로 코어를 배포해보고, 데스크톱에서 쌓은 경험을 서버 쪽으로 옮겨보세요.

각 단계는 이전 단계 위에 쌓이므로 건너뛸 필요가 없습니다. 구체적인 용어가 나오면 용어집으로, 구체적인 오류가 나오면 8장의 빠른 진단 표로, "어떤 걸 설치해야 하나" 고민되면 비교 페이지로 돌아가세요—이 매뉴얼은 늘 곁에 두고 참고하는 배선도처럼 사용하시면 됩니다.