Clash 사용 가이드
처음부터 차근차근

1. 핵심 개념: 클라이언트, 코어, 트래픽 진입점 구분하기

클라이언트는 조작을, 코어는 트래픽 전달을 담당합니다

Clash 생태계에서는 하나의 설치 파일이 모든 기능을 제공하지 않습니다. GUI 클라이언트는 구독 가져오기, 설정 화면, 프록시 그룹 선택, 로그 확인 기능을 제공합니다. 코어는 설정을 읽고 도메인 조회, 규칙 매칭, 연결 전달을 처리합니다. mihomo는 이 생태계에서 널리 쓰이는 코어입니다. 비슷한 코어를 사용하는 클라이언트라도 설정 덮어쓰기 방식, 시스템 통합 기능, 설정 파일 저장 위치가 다를 수 있습니다. 화면에 같은 버튼이 있다고 해서 동작까지 같다고 단정할 수는 없습니다.

설정 파일은 클라이언트와 코어를 연결하는 약속이며, 보통 YAML 형식으로 작성합니다. 파일에는 프록시 노드뿐 아니라 프록시 그룹, 분기 규칙, 수신 대기 포트, DNS 설정이 포함될 수 있습니다. 구독은 이러한 정보를 가져오는 방법 중 하나입니다. 주소에 전체 설정이 담겨 있을 수도 있고, 노드 목록만 제공될 수도 있습니다. 가져오기에 성공했다는 것은 클라이언트가 입력을 받아들였다는 뜻일 뿐, 규칙이 올바르거나 출구를 사용할 수 있거나 모든 앱이 프록시를 거친다는 뜻은 아닙니다. 각 항목을 따로 확인해야 합니다.

연결 과정을 세 가지 질문으로 파악하기

접속 문제를 해결할 때는 먼저 트래픽이 코어에 들어왔는지, 다음으로 어떤 규칙과 일치했는지, 마지막으로 선택한 출구에서 연결이 되는지 확인하세요. 시스템 프록시는 시스템 설정을 따르는 앱에 HTTP 또는 SOCKS 진입점을 제공합니다. 앱에서 직접 프록시를 설정했다면 로컬 수신 포트에 바로 연결할 수도 있습니다. TUN은 가상 네트워크 인터페이스를 통해 라우팅 조건에 맞는 트래픽을 전달합니다. 진입 방식에 따라 적용 범위와 문제 해결 방법이 다르므로 브라우저에서 접속된다고 모든 앱도 정상이라고 볼 수는 없습니다.

코어에 들어온 트래픽은 일반적으로 규칙을 위에서 아래로 확인하고, 일치하는 규칙에 지정된 정책으로 전달합니다. 정책은 직접 연결일 수도 있고 프록시 그룹일 수도 있습니다. 프록시 그룹이 사용할 노드를 선택하고, 노드는 원격 프록시 서버와 연결합니다. 따라서 ‘규칙 모드’는 노드 프로토콜이 아니며, ‘시스템 프록시’도 프록시 그룹이 아닙니다. 서로 다른 계층의 설정을 혼동하면 진입점 문제를 해결하지 못한 채 노드만 계속 바꾸게 될 수 있습니다.

기능 범위를 파악한 뒤 설정하기

클라이언트 자체가 사용 가능한 원격 프록시 서비스를 제공하는 것은 아닙니다. 노드 주소, 포트, 인증 정보와 이용 범위는 설정 출처에 따라 다릅니다. 구독이 만료되었거나 인증이 유효하지 않거나 서비스 이용이 제한된 경우에는 TUN을 켜도 해결되지 않는 경우가 많습니다. 반대로 프록시가 대상 웹사이트의 로그인 제한이나 서비스 장애를 해결해 주는 것도 아닙니다. 테스트는 접근 권한이 있는 서비스에서 진행하고, 거주 지역의 법률과 네트워크 관리 규정, 서비스 약관을 준수하세요. 서비스 측에서 거부된 요청을 클라이언트 문제로 오해하지 않도록 주의해야 합니다.

시작하기 전에 운영체제, 클라이언트 이름, 설정 출처, 현재 진입 방식, 적용하려는 앱을 간단히 기록해 두세요. 구독 키는 공개 메모에 남기지 마세요. 먼저 브라우저 접속을 확인하고, 그다음 다른 앱으로 범위를 넓힌 뒤 마지막에 전체 트래픽을 처리하도록 설정하세요. 한 번에 변수 하나씩만 추가해야 문제가 생겼을 때 직전의 정상 경로로 돌아갈 수 있습니다. 코어와 GUI의 관계는 Clash 생태계와 클라이언트 계보 안내에서도 확인할 수 있습니다.

2. 클라이언트 선택: 플랫폼을 먼저 확인하고 설정 기능을 비교하세요

처음이라면 한 가지 일관된 사용 경로를 선택하세요

이 배포 페이지에서는 지원 플랫폼의 기본 선택지로 Clash Plus를 안내합니다. 구독, 정책, 연결 관리를 하나의 제품에서 익히려는 사용자에게 적합합니다. 다만 실제 선택은 기기 지원 여부와 필요한 기능을 기준으로 해야 합니다. 데스크톱 사용자는 서비스 모드, 규칙 덮어쓰기, 창 관리 기능을 중요하게 볼 수 있고, 모바일 사용자는 VPN 권한, 백그라운드 실행, 배터리 소모를 더 살펴볼 수 있습니다. 먼저 꼭 해결해야 할 문제를 정한 뒤 클라이언트를 비교하면 여러 제품을 동시에 설치하는 것보다 안정적으로 사용할 수 있습니다.

Windows 다운로드 항목에는 Clash Verge Rev, FlClash, Clash Nyanpasu와 지원이 중단된 Clash for Windows도 있습니다. macOS용으로는 Clash Plus, Clash Verge Rev, FlClash와 지원이 중단된 ClashX Meta를 제공합니다. 보관된 클라이언트는 구형 환경을 확인하거나 마이그레이션할 때 유용하지만, 오래된 튜토리얼과 화면이 같다는 이유만으로 새 설치에 기본 선택지로 삼는 것은 권장하지 않습니다. 이전할 때는 구독 출처와 사용자 규칙을 먼저 백업한 다음 새 클라이언트에서 시스템 통합 설정을 다시 구성하세요.

화면보다 중요한 플랫폼 제약

Android에서는 설정 호환성을 고려해 Clash Plus, Clash Meta for Android, FlClash, Surfboard 중에서 선택할 수 있습니다. Surfboard의 설정 체계는 Clash YAML과 다르므로 임의의 전체 YAML 파일을 그대로 가져올 수는 없습니다. iOS 다운로드 항목에는 Clash Plus 앱 스토어 링크와 공식 웹사이트 clashplus.io가 안내되어 있습니다. 모바일 운영체제는 일반적으로 시스템 VPN 기능으로 터널을 구성하므로 데스크톱의 시스템 프록시 포트 설정 절차를 그대로 따라 해서는 안 됩니다.

Linux GUI 클라이언트로는 Clash Verge Rev와 FlClash가 있습니다. 서버, 라우터를 사용하거나 서비스를 직접 관리하려는 경우 독립형 mihomo 코어를 고려할 수 있습니다. 독립형 코어는 실행 인수, 작업 디렉터리, 권한, 로그, 서비스 관리 등을 직접 설정해야 하며 GUI 클라이언트의 구독 버튼이 자동으로 제공되지 않습니다. 일상적인 데스크톱 사용이 목적이라면 먼저 GUI에서 작동하는 설정을 만든 뒤 코어 배포를 익히는 편이 동시에 처리해야 할 변수를 줄이는 데 도움이 됩니다.

설정 호환이 모든 확장 기능의 호환을 뜻하지는 않습니다

클라이언트를 비교할 때는 노드 프로토콜, 규칙 문법, 클라이언트 확장 기능을 각각 확인하세요. 한 코어가 인식하는 필드가 다른 코어에서는 거부될 수 있으며, GUI 클라이언트가 지원하는 스크립트나 덮어쓰기 형식이 표준 설정에 포함되지 않을 수도 있습니다. 튜토리얼에서 특정 필드를 추가하라고 한다면 어떤 제품과 코어를 대상으로 하는지 먼저 확인하세요. 오류를 없애려고 DNS나 프록시 그룹 설정을 통째로 삭제하지 마세요. 파일이 불러와지더라도 원래 의도한 트래픽 분기 방식이 달라질 수 있습니다.

주요 시스템 트래픽을 처리할 클라이언트는 하나만 남겨 두세요. 다른 제품을 비교용으로 사용할 수 있지만 테스트 전에는 기존 클라이언트를 종료하고 시스템 프록시를 끈 다음 백그라운드 서비스 상태도 확인해야 포트나 라우팅 충돌을 막을 수 있습니다. 설치 파일과 아키텍처 안내는 클라이언트 페이지에서 확인하세요. 이전 버전 사용자는 지원 중단 클라이언트 마이그레이션 안내를 먼저 읽고 어떤 설정을 그대로 옮길 수 있는지, 무엇을 다시 구성해야 하는지 확인할 수 있습니다.

3. 설치와 초기 점검: 되돌릴 수 있는 로컬 환경 만들기

아키텍처와 기존 환경 확인하기

다운로드 전 시스템 정보를 확인하고 PC 브랜드만으로 프로세서 아키텍처를 판단하지 마세요. macOS에서는 Apple Silicon과 Intel을 구분해야 합니다. Android에서는 기기가 지원하는 명령어 세트에 맞는 패키지를 선택해야 하며, Linux에서는 아키텍처와 배포판별 패키지 형식도 확인해야 합니다. 설치 파일을 다운로드할 수 있다고 해서 현재 기기에 맞는 것은 아닙니다. 실행 불가, 형식 미지원, 아키텍처 불일치가 발생하면 같은 파일을 계속 설치하지 말고 시스템 정보부터 다시 확인하세요.

설치 전에 기존 시스템 프록시 설정, 실행 중인 VPN, 회사 네트워크 요구 사항을 기록하세요. 이전 프록시 클라이언트를 사용했다면 해당 화면에서 트래픽 처리를 끄고 정상 종료한 뒤 필요하면 백그라운드 서비스도 확인하세요. 용도를 확인하지 않은 상태에서 기존 설정 디렉터리를 삭제하지 마세요. 마이그레이션 중에는 사용자 규칙과 구독 출처가 남아 있을 수 있습니다. 더 안전한 방법은 로컬에서만 접근할 수 있는 백업을 만든 뒤 새 클라이언트의 설정을 별도로 구성하는 것입니다.

기능에 필요한 권한만 부여하기

Windows에서 일반 시스템 프록시와 높은 권한이 필요한 TUN은 서로 다른 기능입니다. 서비스 모드는 권한이 필요한 작업을 백그라운드 서비스에 맡기는 데 주로 사용하며, 구체적인 설정 위치는 클라이언트에 따라 다릅니다. 서비스를 설치하기 전에 권한 요청이 현재 제품에 해당하는지 확인하세요. 브라우저 연결만을 위해 GUI 전체를 항상 관리자 권한으로 실행할 필요는 없습니다. 조직 정책으로 설치 디렉터리가 제한되어 있다면 기기 관리자에게 문의하고 보안 기능을 꺼서 관리 정책을 우회하지 마세요.

macOS에서는 처음 실행할 때 앱 허용과 네트워크 확장 권한이 필요할 수 있습니다. Android와 iOS에서는 보통 시스템 VPN 설정 확인 창이 나타납니다. 권한을 승인한 뒤 클라이언트로 돌아와 실제 연결 상태를 확인하세요. Linux GUI 클라이언트는 데스크톱 환경 구성 요소나 시스템 서비스 권한을 필요로 할 수 있습니다. 종속 항목 누락이나 권한 부족 안내가 표시되면 전체 오류 내용을 보관하고 배포판 및 클라이언트 안내에 따라 조치하세요. 모든 실행 문제를 구독 탓으로 돌려서는 안 됩니다.

첫 실행에서는 기본 항목만 확인하기

구독을 가져오기 전에 설정, 프록시 그룹, 연결, 로그 화면을 찾아 각 메뉴의 위치를 확인하세요. 수신 포트는 현재 클라이언트 설정을 기준으로 해야 합니다. 이 가이드의 7897은 예시일 뿐이며 모든 제품의 기본 포트를 의미하지 않습니다. 포트가 이미 사용 중이라면 어떤 프로세스가 점유하는지 확인한 뒤 기존 서비스를 종료하거나 새 포트를 설정하세요. 변경 후에는 프록시를 수동 설정한 앱도 함께 수정해 이전 주소로 계속 연결하지 않도록 해야 합니다.

초기 문제 해결 단계에서는 로컬 터미널에서 환경 변수를 확인해 명령줄 도구가 이전 프록시 설정의 영향을 받는지 살펴볼 수 있습니다. 터미널마다 확인 방법은 다릅니다. 아래 명령은 현재 프로세스에서 확인할 수 있는 변수만 읽으며 시스템 설정을 변경하지 않습니다. 프록시 변수가 있으면 현재 터미널 세션, 사용자 설정 파일, 개발 도구 중 어디에서 설정됐는지 확인해야 합니다. GUI 스위치만 껐다고 환경 변수까지 지워졌다고 볼 수는 없습니다.

# Linux / macOS: 자주 쓰는 프록시 환경 변수 확인
env | grep -iE '^(http|https|all|no)_proxy='

# Windows PowerShell: 현재 프로세스의 프록시 환경 변수 확인
Get-ChildItem Env: | Where-Object Name -Match '^(HTTP|HTTPS|ALL|NO)_PROXY$'

설치 완료 여부는 화면이 열리는지가 아니라 설정을 불러올 수 있는지, 수신 포트가 충돌하지 않는지, 트래픽 처리를 끌 수 있는지, 로그를 정상적으로 확인할 수 있는지로 판단해야 합니다. 먼저 이 기본 점검을 마치면 이후 문제가 생겼을 때 비교할 기준이 생깁니다. Windows의 서비스 권한과 시작 시 자동 실행 방법은 Clash Verge Rev 설치 안내를 참고하세요. 다른 클라이언트에 같은 이름의 메뉴가 있다고 절차를 그대로 적용해서는 안 됩니다.

4. 구독과 설정: 원격 출처와 로컬 변경 구분하기

먼저 입력 데이터의 유형 확인하기

구독 주소는 전체 Clash 설정, 노드 목록, 인코딩된 링크 목록 또는 다른 제품 형식의 데이터를 반환할 수 있습니다. 가져오기 전에 제공업체의 형식 안내를 확인하고 현재 클라이언트용이라고 명시된 링크를 우선 사용하세요. 클라이언트의 구독 또는 설정 화면에서 원격 설정을 추가하고 주소를 붙여 넣어 다운로드한 다음 불러오기 결과를 확인합니다. 파싱 오류가 발생하면 노드를 계속 새로 고치기보다 응답 내용이 실제 설정인지 먼저 확인하세요.

구독 링크에는 계정을 식별할 수 있는 정보가 들어 있는 경우가 많으므로 계정 인증 정보처럼 안전하게 보관하세요. 스크린샷을 공유하거나 공개적으로 질문하거나 로그를 복사하기 전에는 전체 주소와 인증 필드를 가리세요. 형식 변환을 위해 개인 구독 정보를 신뢰할 수 없는 데이터 처리 서비스에 넘기지 마세요. 사용법에서는 주소 형식을 나타내는 예로 https://example.com/sub?token=xxxx를 사용할 수 있지만, 실제 구독 정보가 없는 예시이므로 연결에 사용할 수 없습니다. 실제 주소는 권한이 있는 출처에서만 받아야 합니다.

가져온 뒤 확인할 순서

다운로드가 끝나면 먼저 새 설정으로 전환해 실제 사용 중인 설정이 되었는지 확인하세요. 다음으로 프록시 그룹이 있는지, 그룹에서 선택할 수 있는 출구가 있는지, 규칙이 유효한 정책을 참조하는지 확인합니다. 일부 클라이언트의 ‘구독 업데이트 완료’ 표시는 파일 저장만 뜻할 수 있으며, 문법이나 참조 오류 때문에 코어가 설정을 다시 불러오지 못할 수도 있습니다. 업데이트 버튼의 성공 메시지만 보지 말고 현재 설정 표시와 로그를 함께 확인해 실제 적용 결과를 판단하세요.

YAML은 들여쓰기와 구조에 민감하므로 공백을 사용하고 탭을 섞지 않는 것이 좋습니다. 목록 항목은 보통 하이픈으로 시작하며 같은 계층의 들여쓰기를 일관되게 유지해야 합니다. 특수 문자가 포함된 문자열은 따옴표로 감쌀 수 있습니다. 실제 오류가 발생한 줄의 다음 줄을 오류 위치로 표시하는 경우도 있으므로 앞뒤 구조를 함께 살펴보세요. 아래 예시는 설정 구조만 보여 줍니다. 프록시 노드가 포함되어 있지 않아 구독을 그대로 대체할 수는 없으며, 실제 설정에는 출처에서 제공한 유효한 노드와 정책을 유지해야 합니다.

# 구조 예시: 실제 구독과 병합해서 사용해야 합니다
mixed-port: 7897
allow-lan: false
mode: rule
log-level: info

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

구독 업데이트와 개인 설정을 분리하기

원격 구독 파일을 직접 편집하면 다음 업데이트 때 변경 사항이 덮어써질 수 있습니다. 계속 유지해야 할 규칙, DNS 또는 포트 설정은 클라이언트에서 지원하는 덮어쓰기, 병합 설정, 별도 규칙 파일에 두고 적용 순서를 확인하세요. 어떤 제품은 설정을 먼저 병합한 뒤 최종 설정을 생성하고, 어떤 제품은 스크립트로 객체를 수정합니다. 이러한 방식은 제품마다 다릅니다. 변경 후에는 최종 적용 설정을 확인해 구독의 같은 이름 항목이 변경 사항을 다시 덮어쓰지 않았는지 살펴보세요.

업데이트 실패는 네트워크, 응답 내용, 설정 파싱 세 방향으로 나누어 확인하세요. 시간 초과나 인증서 오류는 보통 가져오기 단계에서 발생합니다. 다운로드는 됐지만 YAML 오류가 표시되면 응답이 로그인 페이지, 만료 안내, 오류 문구로 바뀌지 않았는지 확인하세요. 노드가 있지만 연결되지 않는다면 인증과 출구를 점검해야 합니다. 현재 사용할 수 있는 설정이 있다면 보관하세요. 출처가 일시적으로 응답하지 않는다고 로컬 캐시를 삭제하면 마지막으로 작동하던 환경까지 잃을 수 있습니다.

구독 변환은 형식을 맞추는 데 쓰이며, 사용할 수 없게 된 노드를 복구하거나 모든 필드를 완벽하게 변환해 주지는 않습니다. 변환 후에는 프록시 그룹 이름, 규칙 순서, DNS 설정을 특히 확인해 노드만 남고 원래 정책이 사라지지 않았는지 살펴보세요. 최종 확인에는 설정 다시 불러오기와 실제 접속 테스트가 포함되어야 합니다. 간단한 절차부터 시작하려면 구독 가져오기 가이드를 참고하고, 흔한 실패 원인은 자주 묻는 질문에서 확인할 수 있습니다.

5. 프록시 모드와 검증: 연결 경로 확인하기

규칙, 전역, 직접 연결 모드는 정책을 바꿉니다

규칙 모드는 설정의 규칙에 따라 출구를 선택하므로 로컬 서비스와 원격 리소스를 함께 이용하는 일상 환경에 적합합니다. 전역 모드는 보통 코어에 들어온 연결을 전역 정책으로 보내 특정 출구의 사용 가능 여부를 임시로 확인하기 편합니다. 직접 연결 모드는 코어에 들어온 연결을 대상에 바로 전달합니다. 어떤 모드도 모든 앱이 코어에 들어오게 해 주지는 않습니다. 따라서 Clash에서 전역 모드를 켰는데 앱이 클라이언트를 완전히 우회한다면 먼저 진입 경로를 확인해야 합니다.

테스트할 때는 주요 진입 방식을 하나만 사용하세요. 데스크톱에서는 먼저 시스템 프록시를 켜고 규칙 모드를 선택한 다음 자주 쓰는 프록시 그룹에서 출구 하나를 지정합니다. 모바일에서는 시스템 VPN 연결부터 설정하세요. 그 뒤 접속 가능한 것으로 확인된 테스트 사이트를 열고 연결 목록에서 대상 도메인, 일치한 규칙, 최종 정책을 확인합니다. 페이지는 열렸지만 연결 목록에 해당 기록이 없다면 브라우저 캐시, 연결 재사용, 앱이 예상한 진입 방식을 사용하지 않는 경우를 살펴봐야 합니다.

비교 테스트로 문제 범위 좁히기

브라우저와 터미널이 같은 프록시 설정을 사용하는 것은 아닙니다. 명령줄에서 로컬 HTTP 프록시를 명시하면 환경 변수 차이를 제외하고 수신 포트가 작동하는지 확인할 수 있습니다. 아래 예시는 혼합 포트가 7897이라고 가정하므로 실행 전에 현재 설정에 맞게 바꾸세요. 공개 예시 도메인에 접속하는 명령이며, 해당 요청 한 번의 연결 상태만 확인할 수 있습니다. 모든 웹사이트, 프로토콜, 앱이 정상이라는 뜻은 아닙니다.

# 로컬 HTTP 프록시를 명시적으로 사용
curl -I --proxy http://127.0.0.1:7897 https://example.com

# 비교를 위해 프록시를 명시적으로 우회
curl -I --noproxy "*" https://example.com

첫 번째 명령에서 로컬 포트에 연결할 수 없다고 나오면 클라이언트 실행 여부, 포트 번호, 수신 대기 여부를 확인하세요. 로컬 연결은 되지만 원격 요청이 실패한다면 선택한 노드와 규칙, 로그를 살펴보세요. 직접 연결은 되는데 프록시 연결이 실패한다면 사용할 수 있는 다른 출구와 비교해 볼 수 있습니다. 둘 다 실패한다면 대상 서비스, 현재 네트워크, 시스템 시간도 확인해야 합니다. 한 번의 테스트에서 노드, DNS, 진입 방식, 규칙을 모두 바꾸면 어떤 변경이 효과가 있었는지 알기 어렵습니다.

프록시 그룹과 연결 재사용 이해하기

수동 선택 그룹은 출구를 고정해야 할 때 적합합니다. 자동 테스트 그룹은 설정된 탐지 조건에 따라 후보를 선택하고, 장애 조치 그룹은 현재 후보를 사용할 수 없을 때 전환하는 데 중점을 둡니다. 탐지 주소, 간격, 허용 오차에 따라 선택 결과가 달라질 수 있으며 탐지에 성공해도 모든 서비스에 접속할 수 있는 것은 아닙니다. 문제 해결 초기에는 자동 전환의 영향을 줄이기 위해 출구를 수동으로 하나 고정하고, 경로를 파악한 뒤 자동 정책을 다시 사용하세요.

모드나 노드를 바꿔도 이미 연결된 장시간 연결이 즉시 새 경로로 옮겨가지는 않을 수 있습니다. 브라우저 연결 풀, 다운로드 작업, 메신저 앱은 이전 연결을 계속 사용할 수 있습니다. 새 정책을 확인하려면 요청을 다시 보내고 필요하면 클라이언트에서 해당 연결을 닫거나 대상 앱을 재시작하세요. 매번 기기 전체를 재시작할 필요는 없습니다. 프록시 그룹에서 무엇이 선택되어 있는지만 보는 것보다 연결이 생성된 시각과 실제 출구를 확인하는 편이 해당 앱의 경로를 더 정확히 파악할 수 있습니다.

접속 성공과 개인정보 보호 목표도 구분해야 합니다. 연결이 프록시를 거친다고 해서 DNS, 앱 원격 측정, 계정 활동까지 같은 범위로 보호되는 것은 아닙니다. 브라우저의 보안 DNS, 앱 자체 DNS 조회, UDP 트래픽도 별도로 살펴볼 수 있습니다. 스토어 앱이 예상한 프록시를 따르지 않는다면 Windows UWP 루프백 예외 안내를 참고하세요. 먼저 앱 유형과 제한을 확인한 뒤 루프백 예외를 적용할지 진입 방식을 바꿀지 결정해야 합니다.

6. 규칙 기반 트래픽 분기: 의도를 설명할 수 있는 순서로 작성하기

예외 규칙을 먼저, 일반 규칙은 나중에 작성하기

분기 규칙은 보통 위에서 아래로 확인하며 처음 일치한 규칙이 다음 정책을 결정하므로 순서 자체가 설정 로직입니다. 흔히 명확한 서비스 예외를 먼저 두고, 그다음 LAN 같은 주소 범위를 처리한 뒤 넓은 범위의 규칙 모음을 적용하고 마지막에 기본 규칙을 둡니다. 포괄적인 직접 연결이나 프록시 규칙을 세부 규칙보다 앞에 두면 뒤에 있는 항목은 문법이 맞더라도 적용되지 않을 수 있습니다.

도메인 규칙은 서비스 이용 의도를 표현할 때, 주소 규칙은 네트워크 범위를 표현할 때 적합합니다. DOMAIN은 전체 도메인과 일치하고, DOMAIN-SUFFIX는 지정한 도메인과 하위 도메인을 포함합니다. IP-CIDR은 주소 대역과 일치하며, GEOIP는 지리 정보 데이터를 사용해 주소를 판별합니다. MATCH는 마지막 기본 규칙으로 사용합니다. 도메인 접미사 규칙은 임의의 문자열 포함 검색이 아닙니다. 경로, 프로토콜 접두사, 쿼리 매개변수를 도메인 필드에 넣지 말고 실제 도메인 경계를 사용하세요.

정책 이름을 먼저, 문법은 그다음 확인하기

마지막 규칙은 실제로 존재하는 정책을 가리켜야 합니다. 아래의 PROXY는 예시 프록시 그룹 이름이므로 사용 전에 현재 설정에 같은 이름의 그룹이 있는지 확인하세요. 없다면 유효한 이름으로 바꿔야 합니다. DIRECT는 내장 직접 연결 정책입니다. 예시는 구체적인 규칙에서 기본 규칙으로 이어지는 순서를 보여줄 뿐 누구에게나 맞는 전체 규칙 목록은 아닙니다. 기존 구독에 더 세밀한 서비스 규칙이 있다면 병합할 때 필요한 로직을 유지하세요.

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

no-resolve는 일부 주소 규칙이 도메인 매칭을 위해 추가 조회를 실행하지 않도록 하는 옵션이며, 모든 DNS를 끈다는 뜻은 아닙니다. 불필요한 조회를 줄일 수 있지만 대상 주소 등 조건이 이미 갖춰져야 규칙을 예상대로 판별할 수 있습니다. 지리 정보 데이터 역시 서비스의 실제 소재를 절대적으로 증명하지는 않습니다. 콘텐츠 전송 네트워크, 여러 지역에 걸친 서비스, 주소 할당 변경 때문에 GeoIP만 사용하면 실제 접속 요구와 다른 정책이 적용될 수 있습니다.

규칙 모음과 로컬 덮어쓰기의 역할 구분하기

규칙이 많아지면 규칙 제공자를 통해 모음을 관리하고 RULE-SET으로 참조할 수 있습니다. 제공자 설정에는 일반적으로 동작 유형, 가져오기 방식, 저장 경로, 업데이트 간격이 필요하며 모음 내용은 선언한 유형과 일치해야 합니다. 도메인 모음을 임의의 규칙 텍스트처럼 사용할 수는 없습니다. 처음에는 규칙 몇 개를 직접 작성해 이해한 뒤 모음을 도입하세요. 그렇지 않으면 트래픽이 잘못 분기될 때 참조, 다운로드 실패, 모음 자체 중 무엇이 원인인지 파악하기 어렵습니다.

규칙을 추가한 뒤에는 먼저 최종 적용 파일에서 규칙 위치를 확인하고, 대상에 접속하면서 연결 상세 정보를 살펴보세요. 일치하지 않으면 실제 대상 도메인, 앞선 규칙에 먼저 걸렸는지, 앱이 주소만 제공하는지, 이전 연결이 재사용되는지 차례로 확인하세요. 웹사이트는 여러 도메인을 사용하는 경우가 많습니다. 홈페이지는 프록시를 거치지만 로그인 API는 직접 연결되어 서비스가 실패할 수도 있습니다. 실제 연결을 기준으로 필요한 범위만 추가하고 모든 트래픽을 같은 정책으로 바꾸지는 마세요.

장기적으로 관리하려면 사용자 규칙을 추가한 이유를 적고 구독 내용과 분리해 저장하세요. 오래된 예외 때문에 서비스가 새 정책을 계속 우회할 수 있으므로 서비스 복구나 규칙 모음 업데이트 후에는 해당 예외가 여전히 필요한지 확인해야 합니다. Clash GeoIP 업데이트는 모든 연결 끊김을 해결하는 만능 방법이 아니라 데이터 관리의 일부로 다뤄야 합니다. 낯선 용어는 용어 안내에서 확인하세요. 각 규칙에 ‘왜 여기에 있는지, 무엇과 일치하는지, 최종적으로 어디에 전달되는지’를 설명할 수 있어야 합니다.

7. TUN과 DNS: 트래픽 처리 범위를 넓히기 전에 이름 조회 이해하기

TUN은 진입 문제를 해결하며 출구 설정을 대신하지 않습니다

TUN은 가상 네트워크 인터페이스와 라우팅을 통해 연결을 코어에 전달합니다. 시스템 프록시를 따르지 않는 프로그램이나 더 많은 프로토콜 트래픽을 한곳에서 처리해야 하는 경우에 적합합니다. 시스템 권한, 네트워크 스택, 클라이언트 구현에 따라 달라지므로 모든 플랫폼에서 같은 스위치나 매개변수를 사용하지는 않습니다. 데스크톱에서 켜기 전에는 시스템 프록시 경로가 작동하는지 확인하고 라우팅을 변경하는 다른 VPN 도구를 일시 중지하세요. 기본 출구가 검증되기 전에 다른 계층을 추가하면 문제 원인이 늘어날 수 있습니다.

TUN을 켠 뒤에는 가상 인터페이스가 만들어졌는지, 대상 트래픽이 연결 목록에 나타나는지, 규칙과 일치했는지, LAN 리소스에 계속 접근할 수 있는지 순서대로 확인하세요. 회사 VPN, 컨테이너 네트워크, 가상 머신을 함께 사용하면 자동 라우팅이 해당 주소 범위와 충돌할 수 있습니다. 이 경우 실제 네트워크에 맞게 제외 범위를 설정하거나 다른 진입 방식을 선택하세요. 네트워크 스택을 무작정 반복해서 바꾸는 것은 피해야 합니다. 원격 관리 기기에서는 라우팅 변경으로 현재 관리 연결이 끊길 수 있으므로 특히 주의하세요.

DNS는 도메인을 연결 대상 주소로 바꿉니다

앱은 시스템 DNS, 브라우저 보안 DNS, 앱에 내장된 조회 기능을 사용할 수 있습니다. 클라이언트의 DNS 설정은 해당 클라이언트 처리 경로로 들어온 조회에만 적용됩니다. 따라서 ‘DNS 서버를 설정했다’는 것과 ‘모든 조회가 그 서버를 거친다’는 것은 다릅니다. Clash DNS 유출을 점검하려면 먼저 어떤 조회를 어떤 경로로 보낼지 정한 뒤 클라이언트 로그와 시스템 설정을 확인하세요. 웹페이지 하나를 테스트한 결과만으로 기기 전체의 동작을 단정할 수는 없습니다.

Fake-IP는 도메인에 예약 주소 대역의 매핑 주소를 할당하고, 코어가 도메인과 연결의 대응 관계를 저장해 이후 트래픽 분기를 돕습니다. 이 주소는 대상 서버의 실제 주소가 아니므로 이런 주소가 보인다고 반드시 조회 오류인 것은 아닙니다. 일부 LAN 장치 검색, 기기 제어, 실제 주소 검증이 필요한 앱은 이 방식과 호환되지 않을 수 있습니다. 용도에 따라 필터를 설정하거나 다른 조회 모드를 사용하세요. 영향을 파악하지 않은 채 DNS 처리를 전부 끄기보다는 예외 범위를 좁히는 것이 좋습니다.

# mihomo 일부 설정 예시: 수신 포트와 플랫폼 지원 여부를 먼저 확인하세요
dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query

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

이 설정은 유효한 mihomo 설정에 병합해야 하며 모든 GUI 클라이언트에 적용되는 것은 아닙니다. 클라이언트가 화면 설정을 바탕으로 해당 필드를 다시 생성할 수도 있습니다. 로컬 포트에서 DNS 수신을 설정해도 시스템 DNS 설정이 자동으로 바뀌지는 않습니다. TUN에서 DNS를 처리한다고 해서 앱이 직접 만드는 암호화 DNS 연결까지 처리할 수 있는 것도 아닙니다. 예시의 상위 DNS 서버는 선택 가능한 설정일 뿐 모든 네트워크에 적합하다고 보장할 수 없습니다. 사용 전에 연결 가능성, 신뢰 관계, 현지 네트워크 요구 사항을 고려하세요.

영향 범위에 따라 문제 발생 시 되돌리기

TUN을 켠 뒤 모든 접속이 실패하면 먼저 TUN을 끄고 이전에 검증한 진입 방식으로 되돌린 다음 기본 네트워크가 복구되는지 확인하세요. 그 후 권한, 라우팅, DNS 로그를 살펴봅니다. 사내 도메인만 실패한다면 원격 노드를 바로 바꾸지 말고 사내 DNS, 검색 도메인, 라우팅을 확인하세요. 특정 앱만 문제라면 시스템 조회, 앱 자체 조회, Fake-IP 예외를 비교해 차이를 찾습니다. 모바일에서는 백그라운드 정책도 고려해야 합니다. 관련 내용은 Android 배터리 소모와 백그라운드 실행 문제 해결을 참고하세요.

8. 유지 관리: 업데이트, 백업, 문제 기록

서로 다른 네 가지 업데이트 구분하기

클라이언트, 코어, 구독, 규칙 데이터 업데이트는 서로 다른 작업입니다. 클라이언트 업데이트는 화면과 시스템 통합에 영향을 주고, 코어 업데이트는 프로토콜 지원이나 필드 동작을 바꿀 수 있습니다. 구독 업데이트는 노드와 설정 출처를 바꾸며, GeoIP, GeoSite, 규칙 모음 업데이트는 규칙 일치 결과에 영향을 줍니다. 변경이 생겼다면 어떤 항목이 업데이트됐는지 먼저 확인해 모든 문제를 막연히 ‘소프트웨어 업데이트’ 탓으로 돌리지 마세요. 복잡한 기록이 아니더라도 변경 전후의 주요 차이를 되짚을 수 있어야 합니다.

환경이 안정적이라면 모든 구성 요소를 한꺼번에 업데이트하거나 DNS를 동시에 다시 설정하지 마세요. 먼저 백업하고 항목별로 변경한 뒤 매번 자주 쓰는 기능을 확인하세요. 데스크톱 클라이언트에서 코어를 따로 바꿀 수 있더라도 실행 파일 이름만 보고 교체하지 말고 호환성 안내를 먼저 읽으세요. 출처를 모르는 오래된 설치 파일을 많이 보관하는 것보다 마지막으로 작동한 설정을 남기는 편이 중요합니다. 되돌릴 때는 설정 문법도 고려해야 합니다. 이전 코어가 새 필드를 읽지 못할 수 있습니다.

파일뿐 아니라 설정 의도까지 백업하기

제대로 된 백업에는 구독 출처, 사용자 규칙, 덮어쓰기 설정, 프록시 그룹 선택, 필요한 시스템 통합 설명이 포함되어야 합니다. 클라이언트에서 내보낸 설정에는 노드 비밀번호와 구독 인증 정보가 들어갈 수 있으므로 접근을 제한해 보관하고 공개 코드 저장소에는 올리지 마세요. 시스템 프록시, 시작 시 자동 실행, 서비스 설치 상태는 내보낸 파일에 포함되지 않을 수 있습니다. 기기를 바꾼 뒤에는 권한을 다시 부여하고 포트를 확인해야 합니다. 백업 파일이 있다는 사실만으로 복원 가능성이 검증되는 것은 아닙니다.

일상적인 사용에 지장을 주지 않는 시점에 한 번 복원을 테스트할 수 있습니다. 임시 설정을 만들고 백업을 가져온 다음 정책 참조와 규칙 순서를 확인하고 원래 설정으로 돌아오세요. 클라이언트를 바꿀 때는 먼저 공통 YAML 설정을 복원한 뒤 새 제품 방식에 맞춰 덮어쓰기와 시스템 설정을 다시 구성합니다. 기존 디렉터리 전체를 새 클라이언트 데이터 디렉터리에 덮어쓰지 마세요. 이전 캐시, 데이터베이스, 클라이언트 전용 필드는 호환되지 않을 수 있습니다. 마이그레이션이 끝나도 자주 쓰는 환경을 모두 확인할 때까지 원본 백업을 보관하세요.

구체적인 실패 상황을 중심으로 문제 기록하기

문제가 발생하면 시간, 대상 앱, 도메인, 현재 진입 방식, 선택한 정책을 먼저 기록한 뒤 한 번 재현하세요. 로그를 일시적으로 더 자세히 기록할 때는 디스크 사용량과 민감 정보 노출에 주의하고 문제 해결 후 적절한 수준으로 되돌리세요. 공개적으로 문의할 때는 필요한 오류 맥락만 남기고 구독, 인증 정보, 개인 경로를 가리세요. 판단에 필요한 오류 유형까지 지우고 ‘연결 실패’만 남기면 원인을 찾기 어려워집니다.

Clash 시작 시 자동 실행은 별도로 확인해야 합니다. 재부팅 후 클라이언트가 실행되는지, 백그라운드 서비스가 작동하는지, 설정이 불러와지는지, 트래픽 처리가 예상대로 이뤄지는지 확인하세요. 앱에 따라 로그인 후에 시작되거나 데스크톱보다 서비스가 먼저 실행될 수 있으므로 같은 기준으로 판단할 수 없습니다. 구독 자동 업데이트에는 최초 네트워크 연결 조건도 고려해야 합니다. 구독 다운로드에 아직 복구되지 않은 프록시 경로가 필요하다면 로컬에서 사용할 수 있는 설정을 보관해 시작 시 설정을 가져오는 과정과 연결을 만드는 과정이 서로를 기다리는 상황을 피하세요.

문제가 해결되면 임시 전역 모드, 디버그 로그, 지나치게 넓은 예외 규칙을 되돌리고 원인과 해결 결과를 짧게 기록하세요. 문제 해결용 설정을 계속 사용하는 환경에 그대로 남기지 마세요. 같은 문제가 반복되면 자주 묻는 질문에서 기본 개념, 설치와 설정, 사용 팁, 문제 해결 항목을 찾아보세요. 추가로 도움을 요청할 때는 실패 화면만 올리기보다 재현 절차와 민감 정보를 가린 설정 일부를 제공하는 것이 효과적입니다.

9. 고급 설정: 작동하는 설정에서 관리하기 쉬운 설정으로

스위치 개수가 아니라 검증 가능한 목표로 개선하기

앞의 8개 장을 마쳤다면 고급 설정의 목표는 모든 기능을 켜는 것이 아니라 설정을 설명하고 이전하고 되돌릴 수 있게 만드는 것입니다. 예를 들어 업무 서비스를 특정 정책에 고정하거나, 기기 그룹마다 다른 출구를 사용하거나, 반복되는 규칙을 모음으로 분리하는 등 명확한 목표를 하나 정하세요. 먼저 완료 여부를 판단할 조건을 작성한 다음 필요한 필드를 선택합니다. 기존 규칙으로 이미 문제가 해결됐다면 스니핑, 스크립트, 복잡한 그룹 연결을 계속 추가할수록 유지 관리 비용과 문제 해결 범위만 커질 수 있습니다.

첫 단계에서는 설정을 기본 수신 설정, DNS, 노드 출처, 프록시 그룹, 규칙의 다섯 부분으로 나누고 각각 누가 관리하는지 표시할 수 있습니다. 원격 구독은 노드를 관리하고, 로컬 덮어쓰기는 개인 설정을 담당하며, 규칙 제공자는 재사용 가능한 모음을 관리합니다. 이러한 역할 구분은 거대한 파일 하나를 직접 관리하는 것보다 명확합니다. 클라이언트가 설정을 생성하는 방식이라면 입력 파일과 최종 파일의 차이도 알아야 합니다. 최종 파일은 결과 확인에 유용하지만 장기간 직접 편집할 파일로 적합하지 않을 수 있습니다.

정적 검사를 먼저, 실제 서비스 검증은 그다음

mihomo를 독립적으로 사용할 때는 설정 검사로 문법과 참조 관계를 확인한 뒤 실제 네트워크 트래픽 처리를 시작할 수 있습니다. 아래 명령은 실행 파일이 명령 검색 경로에 있고 현재 디렉터리에 검사할 설정 파일이 있다고 가정합니다. 검사를 통과해도 코어가 파일을 읽을 수 있다는 뜻일 뿐, 노드 인증 정보가 유효하거나 상위 DNS에 연결되거나 라우팅이 요구에 맞는다는 의미는 아닙니다. GUI 클라이언트에 설정 검증 기능이 있다면 지원되는 경로를 우선 사용하고 내부 작업 디렉터리를 임의로 조작하지 마세요.

# 독립형 mihomo: 현재 설정 검사
mihomo -t -f ./config.yaml

# 독립형 mihomo: 지정한 설정 파일로 실행
mihomo -f ./config.yaml

그다음 간단한 회귀 테스트 목록을 만드세요. 직접 연결 대상 하나, 프록시 대상 하나, LAN 서비스 하나, 실제로 필요한 UDP 또는 장시간 연결 서비스를 포함하면 됩니다. 변경할 때마다 진입 경로, 규칙, 출구를 따로 확인하고 예상대로 작동하는지 기록하세요. 테스트 대상은 실제 환경에 맞게 정해야 하며 공개 탐지 주소의 결과를 서비스 품질로 간주해서는 안 됩니다. 로그인, 결제, 고정된 지역이 필요한 서비스에서는 출구 변경으로 계정의 부정 사용 감지나 세션 만료가 발생할 수 있다는 점도 고려하세요.

자동화와 원격 관리의 접근 범위 제한하기

제어 인터페이스나 패널을 사용하기 전에 수신 범위와 접근 인증을 확인하세요. 로컬에서만 관리한다면 루프백 주소에 바인딩해야 합니다. 휴대폰에서 패널을 보려고 모든 네트워크 인터페이스에 관리 포트를 공개하지 마세요. LAN 관리가 꼭 필요하다면 접근 제어와 방화벽을 함께 설정하고 프록시 수신 서비스와 제어 인터페이스가 별개라는 점을 알아야 합니다. LAN 연결 허용이 모든 기기에 사용 권한을 주는 것은 아니므로 실제 필요에 맞게 네트워크 노출 범위를 제한하세요.

서버와 라우터에 배포하려면 서비스 실행 주기도 익혀야 합니다. 어떤 사용자로 실행하는지, 어느 디렉터리에서 데이터를 읽는지, 재시작 후 복구되는지, 로그를 어떻게 순환하는지, 비정상 종료를 어떻게 처리하는지 확인하세요. 투명 프록시, 방화벽 전달, 정책 라우팅을 설정할 때는 별도의 복구 계획을 세워야 합니다. 익숙하지 않은 라우팅 규칙을 원격 관리 중인 기기에서 바로 시험하지 마세요. 로컬에서 접근할 수 있는 테스트 환경에서 검증한 뒤 장기간 가동할 기기로 옮기면 연결이 끊길 위험을 줄일 수 있습니다.

계속 학습할 때는 현재 코어와 클라이언트의 설정 문서를 우선 확인하세요. 특히 필드가 속한 계층, 기본 동작, 호환 제한을 살펴봐야 합니다. 오래된 글은 원리를 이해하는 데 도움이 되지만 현재 적용 중인 설정을 직접 확인하는 일을 대신할 수는 없습니다. 복습하려면 이 페이지의 핵심 개념으로 돌아가 트래픽 경로를 다시 정리하세요. 환경을 새로 만들려면 빠른 시작 가이드를 따라가면 됩니다. 각 설정이 어떤 문제를 해결하고, 어떻게 검증하며, 어떻게 되돌리는지 설명할 수 있어야 ‘일단 작동하는 설정’을 ‘오랫동안 관리할 수 있는 설정’으로 발전시킬 수 있습니다.