Clash 사용 설명서

1. 핵심 개념과 트래픽 흐름

클라이언트, 커널, 노드와 구독

Clash는 특정 설치 파일 하나를 가리키는 이름이 아닙니다. 실제로는 GUI 클라이언트가 설정, 프록시, 연결 목록과 시스템 전환 기능을 제공하고, 커널이 연결을 받아 목적지를 파악한 뒤 규칙을 적용해 출구 연결을 만듭니다. mihomo는 이 생태계에서 널리 쓰이는 커널입니다. 화면이 비슷해도 커널 기능까지 같은 것은 아닙니다. 특정 필드가 작동하는지 확인하려면 클라이언트의 설정 생성 방식과 커널의 지원 여부를 함께 살펴보세요.

노드는 원격 서비스에 연결하기 위한 매개변수 모음으로, 보통 서버 주소, 포트, 프로토콜, 인증 정보가 포함됩니다. 클라이언트 자체가 노드 서비스인 것은 아니며, 설치만으로 사용할 수 있는 회선이 생기지는 않습니다. 구독은 설정이나 노드 목록을 받아 업데이트하는 방법 중 하나입니다. 구독 링크에는 접근 자격 증명이 포함되는 경우가 많으므로 비밀번호처럼 관리하세요. 스크린샷, 로그, 문의 내용에 전체 링크를 공개하지 마세요.

설정 파일은 이러한 구성 요소를 하나로 묶습니다. 인바운드 포트는 로컬 트래픽을 받고, 노드는 원격 출구를 지정하며, 프록시 그룹은 선택 가능한 출구를 구성합니다. 규칙은 각 연결을 어느 그룹으로 보낼지 결정합니다. 구독은 전체 설정을 제공할 수도 있고 노드 목록만 제공할 수도 있습니다. 가져온 뒤에는 실제로 어떤 항목이 생성됐는지 확인하세요. 설정 화면에 이름 하나가 보인다고 연결 준비가 끝난 것은 아닙니다.

먼저 트래픽 유입을 확인하고, 다음에 라우팅을 살펴보세요

한 번의 접속은 두 가지로 나눠 볼 수 있습니다. 첫째, 앱의 트래픽이 시스템 프록시, 앱 자체 프록시 설정 또는 TUN을 통해 커널로 들어오는지 확인합니다. 둘째, 유입된 트래픽이 규칙, 프록시 그룹, 노드에 따라 어디로 나가는지 확인합니다. 따라서 연결 목록에 기록이 전혀 없는 문제와 기록은 있지만 원격 연결이 시간 초과되는 문제는 원인이 다릅니다. 전자는 트래픽 유입을, 후자는 규칙과 DNS, 출구를 확인하세요.

시스템 프록시는 시스템 설정을 따르는 앱에 프록시 주소를 제공할 뿐, 모든 네트워크 연결이 반드시 거치는 경로를 만드는 것은 아닙니다. 브라우저는 설정을 따를 수 있지만 일부 게임, 명령줄 도구, 백그라운드 서비스는 무시할 수 있습니다. TUN은 가상 네트워크 어댑터와 라우팅을 이용해 트래픽 유입 범위를 넓히지만, 제외 경로, 앱 동작, 시스템 권한의 영향을 받습니다. 트래픽이 제대로 유입됐는지는 스위치 색상이 아니라 연결 기록으로 확인하세요.

네 가지 점검 항목으로 판단 근거를 마련하세요

문제 해결을 시작할 때는 현재 설정이 활성화됐는지, 커널이 실행 중인지, 앱 연결이 커널에 들어왔는지, 선택된 정책으로 접속할 수 있는지 차례로 확인하세요. 설정 화면의 활성 상태, 로그의 리스닝 정보, 연결 화면의 대상 도메인과 정책 체인처럼 각 단계에서 관찰할 수 있는 결과를 남겨 두세요. 증거가 없는 단계에서 점검을 멈추고 원인을 확인하세요. DNS, 노드, 규칙을 한꺼번에 바꾸면 변경 사항이 서로 영향을 가려 원인을 찾기 어렵습니다.

지연 시간 테스트와 실제 서비스 접속도 구분해야 합니다. 클라이언트 테스트는 대개 특정 테스트 주소에 요청을 보내므로, 해당 경로가 응답했는지는 알 수 있지만 모든 웹사이트, 동영상 서비스, 로그인 API가 작동한다는 뜻은 아닙니다. 실제로 사용하는 앱으로 추가 검증하고 시간, 네트워크 환경, 오류 증상을 기록하세요. 그래야 설정을 비교할 때 서로 다른 접속 상황이 아니라 같은 경로를 비교할 수 있습니다.

2. 클라이언트 및 플랫폼 선택

운영체제, 아키텍처, 유지 관리 상태를 기준으로 선택하세요

처음 사용한다면 Clash Plus를 먼저 고려하고, 플랫폼에 따라 다른 클라이언트도 비교해 보세요. 화면부터 고르기보다 운영체제와 프로세서 아키텍처를 먼저 확인해야 합니다. Windows 기기는 보통 x64지만 일부는 ARM64를 사용합니다. macOS는 Intel과 Apple Silicon을 구분해야 하며, Android에서는 설치 파일이 지원하는 명령어 세트를 확인하세요. 아키텍처가 맞지 않으면 설치나 실행이 안 되거나 에뮬레이션이 필요할 수 있습니다. 파일 확장자만으로 호환성을 판단하지 마세요.

운영체제 버전 요구 사항은 다운로드 페이지와 클라이언트의 최신 안내를 기준으로 확인하세요. Windows나 Android라는 이유만으로 모든 세대의 운영체제에서 같은 설치 파일이 작동한다고 단정할 수 없습니다. 다운로드 전 설치 권한, 저장 공간, 가상 네트워크 어댑터 생성 가능 여부도 확인하세요. 조직에서 관리하는 기기는 네트워크 확장이나 서비스 설치가 제한될 수 있습니다. 이때는 기기 관리자에게 정책을 확인하고, 권한 제한을 노드 문제로 오해해 회선을 계속 바꾸지 마세요.

데스크톱과 모바일의 차이

Windows에서는 보통 시스템 프록시로 브라우저 연결을 먼저 확인한 뒤 TUN 사용 여부를 결정합니다. macOS는 칩 아키텍처와 함께 앱 및 네트워크 확장 권한 요청도 확인해야 합니다. Linux 데스크톱은 시스템 프록시 지원이 환경마다 달라, 설정 스위치가 작동해도 터미널 프로그램이 이를 따르지 않을 수 있습니다. 서버나 라우터에서 mihomo를 직접 실행할 수 있지만 서비스 시작, 설정 경로, 리스닝 범위, 로그 관리를 직접 처리해야 합니다.

Android 클라이언트는 보통 시스템 VPN 인터페이스로 트래픽을 가져오므로 데스크톱의 시스템 프록시 설정 순서를 그대로 적용할 수 없습니다. 처음 실행할 때 VPN 권한을 승인하고, 계속 실행하려면 배터리 절전 설정도 확인하세요. Surfboard의 설정 문법은 Clash YAML과 다릅니다. 파일 확장자만 바꾸지 말고 구독이 호환 형식을 제공하는지 확인하세요. 백그라운드 설정은 Android 배터리 소모 및 백그라운드 실행 안내를 참고하세요.

iOS에서는 Clash Plus를 사용할 수 있습니다. App Store 제품 페이지에서 시스템 요구 사항을 확인하고, 제품 공식 웹사이트는 clashplus.io입니다. VPN 설정을 승인한 뒤 호환되는 설정을 가져오고 실제 접속을 확인해야 합니다. 휴대폰에 VPN 표시가 나타나는 것은 관련 네트워크 인터페이스가 사용 중이라는 뜻일 뿐, 구독이 유효하거나 선택한 출구에 연결할 수 있다는 증거는 아닙니다.

이전 비용도 고려하세요

Clash for Windows와 ClashX Meta는 유지 관리가 중단됐으므로 기존 환경을 참고하는 용도로만 보고, 새 기기의 기본 선택지로는 권장하지 않습니다. 구형 클라이언트가 실행되더라도 현재 구독에서 사용하는 프로토콜과 필드를 지원한다는 보장은 없습니다. 이전하기 전에 기존 규칙, 프록시 그룹 선택, LAN 설정을 기록한 뒤 새 클라이언트에 설정을 별도로 가져오세요. 복구에 필요한 정보가 사라지지 않도록 기존 디렉터리를 바로 덮어쓰지 마세요.

한 기기에 여러 클라이언트를 설치해 비교할 수는 있지만, 검증할 때는 트래픽을 처리하는 인스턴스를 하나만 실행하세요. 시스템 프록시 스위치, VPN 인터페이스, TUN 라우팅이 동시에 여러 개 작동하면 트래픽 경로를 파악하기 어렵습니다. 각 플랫폼의 설치 파일은 클라이언트 다운로드 페이지에서 확인하세요. 후보를 정한 뒤 최소한의 연결 테스트를 먼저 하고, 단축키, 설정 덮어쓰기 방식, 연결 패널을 비교하세요. 처음부터 모든 고급 설정을 옮길 필요는 없습니다.

3. 설치와 초기 점검

설치 전 기기의 네트워크 상태를 기록하세요

먼저 실행 중인 프록시 클라이언트와 VPN을 종료하고, 일반 네트워크에서 평소 사용하는 사이트에 접속할 수 있는지 확인하세요. 시스템 프록시가 이미 활성화됐는지, DNS를 수동으로 설정했는지, 기기가 기업 네트워크에 연결됐는지도 기록합니다. 그래야 설치 후 문제가 생겼을 때 복구 기준을 명확히 잡을 수 있습니다. 기기가 원래 조직에서 제공한 프록시로 네트워크에 접속하는 경우 기존 설정을 바로 지우지 마세요. 주소와 포트를 저장하고 다른 네트워크 도구를 함께 사용해도 되는지 확인하세요.

다운로드 페이지에서 아키텍처에 맞는 설치 파일을 받아 운영체제의 설치 절차에 따라 설치하세요. 데스크톱의 설치 권한과 평소 실행 권한은 다릅니다. 서비스를 설치할 때는 관리자 권한이 필요할 수 있지만, 일반적인 시스템 프록시 사용에는 필요하지 않을 수 있습니다. 모든 가능성을 배제하겠다고 클라이언트를 계속 최고 권한으로 실행하지 마세요. TUN이 필요할 때 클라이언트 안내에 따라 보조 서비스를 설치하고, 서비스의 출처와 설치 경로가 현재 클라이언트에 해당하는지 확인하세요.

처음 실행하면 설정, 프록시, 연결, 로그 영역부터 찾아보세요. 설정 화면에서는 현재 사용할 파일을 정하고, 프록시 화면에서는 출구로 사용할 프록시 그룹을 선택합니다. 연결 화면에서는 트래픽이 커널에 들어오는지 확인하고, 로그에서는 설정 로드와 연결 오류를 확인할 수 있습니다. 위치는 클라이언트 화면 구성 안내를 참고하세요. 처음에는 시작 프로그램 등록, LAN 공유, TUN을 꺼 두어 변수를 줄여도 됩니다.

리스닝 포트와 시스템 프록시 확인

유효한 설정을 가져온 뒤 커널이 정상적으로 시작됐는지, 혼합 포트가 리스닝 중인지 확인하세요. 혼합 포트는 보통 HTTP와 SOCKS 프록시 요청을 모두 받을 수 있으며, 실제 포트는 활성 설정에 따라 달라집니다. 아래는 인바운드와 직접 연결을 확인하기 위한 독립 설정 예시이며 프록시 노드는 포함하지 않습니다. 따라서 원격 프록시 서비스 검증에는 사용할 수 없습니다. 사용 전에 해당 포트를 다른 프로세스가 점유하고 있지 않은지 확인하고, 테스트가 끝나면 자신의 설정으로 돌아가세요.

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

rules:
  - MATCH,DIRECT

시스템 프록시의 서버 주소는 로컬 리스닝 주소를 가리켜야 하고, 포트는 현재 커널의 포트와 일치해야 합니다. YAML의 포트만 바꿔도 클라이언트가 시스템에 설정한 프록시 항목까지 자동으로 변경되는 것은 아닙니다. 포트가 충돌하면 클라이언트에서 지원하는 설정을 통해 바꾸고 양쪽 값이 일치하는지 다시 확인하세요. 설정을 전환할 때 유효 포트도 달라질 수 있으므로 모든 앱이 예전 포트를 사용하도록 고정하지 마세요.

curl을 사용할 수 있는 환경에서는 아래 명령을 실행해 로컬 HTTP 프록시를 지정할 수 있습니다. HTTP 응답을 받으면 해당 요청이 지정한 인바운드를 거쳐 접속을 완료했다는 뜻입니다. 원격 서버가 반환한 서비스 상태는 별도로 확인해야 합니다. 브라우저에서는 실패하지만 이 명령이 성공한다면 클라이언트를 곧바로 재설치하기보다 브라우저 확장 프로그램, 별도 프록시 설정, 기존 연결을 먼저 확인하세요.

curl -I --proxy http://127.0.0.1:7890 https://example.com

Windows UWP 루프백 및 예외

일부 Windows 앱 컨테이너는 루프백 접속이 제한되어 일반 데스크톱 프로그램처럼 로컬 프록시에 연결하지 못합니다. 브라우저는 정상인데 특정 스토어 앱의 연결 기록은 나타나지 않는 것이 대표적인 증상입니다. 먼저 해당 앱이 시스템 프록시를 실제로 사용하는지 확인하고, 필요할 때 클라이언트에서 제공하는 UWP 루프백 도구를 사용하세요. 꼭 필요한 신뢰할 수 있는 앱에만 예외를 설정하고 변경 사항을 기록하세요. 루프백 예외는 모든 스토어 앱의 네트워크 문제를 해결하는 만능 설정이 아닙니다.

초기 점검을 마친 기준은 설정이 정상적으로 로드되고, 리스닝 포트를 확인했으며, 테스트 요청이 기록되고, 클라이언트를 종료한 뒤 네트워크가 복구되는 것입니다. 클라이언트가 비정상 종료된 후에도 브라우저가 로컬 포트를 가리킨다면 남아 있는 시스템 프록시를 먼저 끄고 백그라운드 프로세스를 확인하세요. 설치 문제와 노드 문제는 따로 기록해야 합니다. 전자는 프로그램 실행 여부를, 후자는 활성 설정이 예상한 출구 연결을 만드는지 확인하는 문제입니다.

4. 구독 가져오기와 설정 관리

구독 내용을 확인한 뒤 가져오기 방식을 선택하세요

설정 화면에서 원격 설정 추가, 링크로 가져오기와 같은 메뉴를 선택하고 서비스 제공자가 안내한 호환 구독 링크를 붙여 넣은 뒤 알아보기 쉬운 이름을 지정하세요. 복사할 때 공백, 줄바꿈, 메신저가 덧붙인 문장 부호가 포함되지 않도록 주의하세요. 가져오기 전에 링크의 용도를 확인해야 합니다. 웹 관리 주소, 구매 페이지, 구독 주소는 서로 다른 리소스입니다. 브라우저에서 웹페이지가 열린다고 해서 커널이 읽을 수 있는 설정이라는 뜻은 아닙니다.

다운로드가 끝나면 설정에 노드, 프록시 그룹, 규칙이 포함됐는지 확인하세요. 일부 링크는 인코딩된 노드 목록만 반환하므로 클라이언트가 해당 가져오기 방식을 명시적으로 지원해야 합니다. 전체 YAML을 반환하는 링크도 있습니다. 형식 오류가 발생하면 먼저 오류가 난 줄 주변을 읽고 받은 내용이 설정 파일인지 로그인 페이지나 오류 페이지인지 확인하세요. 자격 증명이 포함된 구독을 출처가 불분명한 온라인 변환 서비스에 입력하지 마세요. 변환을 맡기면 서비스 운영자가 구독 내용을 볼 수 있습니다.

설정을 가져오는 것과 활성화하는 것은 별개의 작업입니다. 설정 목록에 새 항목이 추가된 뒤에는 해당 항목을 활성 설정으로 지정하고, 커널이 다시 로드될 때까지 기다린 다음 프록시 화면에 그룹이 표시되는지 확인하세요. 로드 실패 메시지가 나오면 이전에 정상 작동한 설정을 보존하고 같은 이름의 복사본을 연달아 가져오지 마세요. 이번에 내려받은 내용이 온전한지, 필드가 호환되는지 확인한 후 형식을 수정할지 제공자에게 문의할지 결정하세요.

원격 설정과 로컬 변경 사항을 분리하세요

원격 설정을 업데이트하면 구독 파일에 직접 적용한 변경 사항이 덮어써질 수 있습니다. 장기간 유지해야 하는 LAN 규칙, DNS 설정, 프록시 그룹 보완은 클라이언트에서 지원하는 오버라이드, 병합 또는 스크립트 확장 기능을 우선 사용하세요. 병합 순서는 클라이언트마다 다르므로 규칙을 앞에 추가하는지 뒤에 추가하는지, 목록을 교체하는지 병합하는지 확인해야 합니다. 저장한 뒤에는 편집창의 원본 텍스트만 보지 말고 최종 적용 설정을 확인하세요.

오버라이드 기능을 당장 사용하지 않는다면 로컬 설정을 복사해 연습할 수 있습니다. 다만 로컬 복사본은 원격 노드 변경 사항을 자동으로 반영하지 않습니다. 원본 구독, 테스트 복사본, 검증 완료 복사본에 서로 다른 이름을 붙이고 최근 변경 목적을 기록하는 것이 좋습니다. 업데이트 후 문제가 생기면 상위 설정의 변경인지 로컬 규칙의 덮어쓰기인지 파악할 수 있어 전체 설정을 처음부터 다시 만들 필요가 없습니다.

구독 업데이트 실패 시 단계별로 처리하기

먼저 다운로드 실패와 파싱 실패를 구분하세요. 다운로드 실패는 네트워크 연결 불가, 인증서 시간 오류, 링크 만료, 서버 거부 등이 원인일 수 있습니다. 파싱 실패는 보통 내용을 받은 뒤 발생합니다. 로그에서 오류 유형과 발생 시간을 확인하고 빨간색 상태 표시만 보지 마세요. 기기 시간이 크게 어긋나 있다면 먼저 시간을 맞추세요. 서버가 권한이나 사용량 관련 안내를 반환하면 DNS를 반복해서 바꾸기보다 서비스 관리 페이지에서 계정 상태를 확인하세요.

업데이트 요청이 어떤 경로를 이용하는지도 확인해야 합니다. 일부 클라이언트에서는 직접 연결하거나 현재 프록시를 통해 업데이트할 수 있습니다. 현재 설정이 유효하지 않은 상태에서 그 설정을 이용해 업데이트하려 하면 시작 단계에서 막힐 수 있습니다. 신뢰할 수 있는 네트워크에서 다른 업데이트 경로를 시도할 수 있지만, 클라이언트마다 메뉴가 같다고 가정하지 마세요. 한 번에 업데이트 방식 하나만 바꾸고 나머지 설정은 유지하세요. 다운로드가 복구된 것을 확인한 다음 새 설정의 유효성을 점검하세요.

업데이트가 성공해도 점검을 끝내면 안 됩니다. 상위 설정에서 노드 이름, 프록시 그룹, 규칙이 바뀌면 이전에 직접 선택한 항목의 참조가 끊길 수 있습니다. 활성 설정, 프록시 그룹의 선택 항목, 실제 연결을 각각 확인한 뒤 평소처럼 접속하세요. 간단한 절차는 구독 가져오기 가이드를 참고하세요. 이 장의 유지 관리 원칙은 원격 설정을 업데이트할 수 있게 하고, 로컬 변경을 추적하며, 문제 발생 시 되돌릴 수 있도록 하는 것입니다.

5. 프록시 모드와 프록시 그룹

규칙, 전역, 직접 연결의 적용 범위

규칙 모드에서는 설정 파일의 규칙에 따라 출구를 정하므로 로컬 서비스, 일반 사이트, 프록시 대상 사이트를 구분해 사용하는 데 적합합니다. 전역 모드에서는 보통 커널에 들어온 연결을 전역 정책으로 보내므로 분류 규칙 문제인지 확인할 때 유용합니다. 직접 연결 모드에서는 커널에 들어온 연결을 직접 출구로 보냅니다. 모드는 이미 커널에 들어온 트래픽에만 영향을 줍니다. 전역 모드가 시스템 프록시를 무시하는 앱까지 자동으로 가져오거나 TUN을 대신하지는 않습니다.

문제를 비교할 때 전역 모드로 잠시 전환해 볼 수 있습니다. 같은 대상이 전역 모드에서는 정상인데 규칙 모드에서 실패한다면 규칙 매칭과 프록시 그룹 선택을 먼저 확인하세요. 두 모드 모두 실패하면 노드, DNS, 네트워크를 점검하세요. 비교할 때는 같은 노드를 사용하고 새 연결을 만드세요. 기존 장기 연결은 이전 출구를 계속 사용할 수 있습니다. 새 연결이 만들어지도록 관련 앱을 닫았다가 다시 테스트하세요. 새로고침만으로는 충분하지 않을 수 있습니다.

직접 연결 모드가 클라이언트를 끄는 것은 아닙니다. 시스템 프록시와 TUN이 계속 활성화되어 있으면 연결은 여전히 커널에서 받아 처리됩니다. 클라이언트를 거치지 않는 원래 네트워크 경로로 돌아가려면 해당 트래픽 유입 기능을 끄고 시스템 프록시와 VPN 인터페이스 상태도 확인해야 합니다. 이 차이를 알면 클라이언트가 여전히 네트워크 경로를 차지하는 상황을 시스템 네트워크 고장으로 오해하지 않으며, 직접 연결 모드에서도 연결 목록에 기록이 남는 이유를 이해할 수 있습니다.

프록시 그룹: 노드 하나가 아니라 출구를 선택합니다

프록시 그룹에는 노드뿐 아니라 다른 프록시 그룹도 포함할 수 있습니다. 수동 선택 그룹은 출구를 고정할 때 적합합니다. 자동 테스트 그룹은 테스트 결과에 따라 후보를 선택하며, 장애 조치 그룹은 지정된 순서에 따라 사용할 수 있는 항목을 찾습니다. 자동 선택 방식은 테스트 주소, 간격, 허용 오차, 커널 구현의 영향을 받습니다. 자동 정책이 모든 대상에 가장 빠른 출구를 고른다고 생각하지 마세요. 설정에 지정된 테스트 조건에 따라 선택할 뿐입니다.

아래는 유효한 기존 설정에 추가할 수 있는 프록시 그룹 예시입니다. 연습용에는 기본 제공되는 직접 연결과 거부 정책만 있으므로 설정을 불러올 수는 있어도 원격 프록시는 사용할 수 없습니다. 실제로 사용하려면 확인된 노드 목록에 후보를 추가하고 규칙에서 같은 그룹 이름을 참조하세요. 대소문자, 공백, 문자를 정확히 맞춰야 합니다. 존재하지 않는 그룹을 규칙에서 참조하면 설정 검증이 실패하거나 의도한 라우팅이 되지 않을 수 있습니다.

proxy-groups:
  - name: 출구 선택
    type: select
    proxies:
      - DIRECT
      - REJECT

rules:
  - DOMAIN-SUFFIX,example.com,출구 선택
  - MATCH,DIRECT

설정에 PROXY가 있다고 해서 커널이 유일하게 고정해 둔 프록시 이름이라는 뜻은 아닙니다. 작성자가 정한 프록시 그룹 이름일 뿐이며, 출구 선택과 같은 다른 이름도 사용할 수 있습니다. 이름과 기능의 관계를 이해하면 여러 단계로 구성된 정책도 쉽게 파악할 수 있습니다. 서비스 규칙이 먼저 서비스 그룹으로 들어가고, 서비스 그룹이 지역 그룹을 선택한 다음, 지역 그룹이 노드를 선택하는 구조입니다. 문제를 해결할 때는 첫 번째 그룹 이름만 보지 말고 전체 정책 체인을 펼쳐 확인하세요.

사용 목적에 맞게 노드 선택을 검증하세요

노드를 선택할 때는 실제 연결 가능 여부, 서비스의 지역 요건, 회선 안정성, 서비스 측 트래픽 과금 정책을 함께 고려해야 합니다. 지연 시간이 낮다는 것은 테스트 경로가 짧거나 응답이 빠르다는 뜻이지, 지속적인 다운로드 속도가 더 빠르다는 의미는 아닙니다. 동영상, 회의, 게임을 테스트할 때는 실제 서비스가 일정 시간 동안 어떻게 작동하는지 관찰하세요. 시간과 네트워크 환경이 다른 단일 테스트 결과를 그대로 비교하지 마세요.

일부 서비스는 출구가 바뀌면 민감하게 반응하므로 자동 정책이 백그라운드에서 노드를 바꿀 때 재인증이 필요하거나 세션이 끊길 수 있습니다. 이 경우 해당 서비스에 별도의 수동 선택 그룹을 만들어 출구를 고정하고, 일반 웹 탐색에는 자동 선택을 사용하세요. 비교 방법은 노드 지연 시간, 배율, 지역, 프로토콜 선택 안내에서 확인할 수 있습니다. 먼저 한 노드가 안정적으로 작동하는지 확인한 다음 정책 계층을 추가하면 유지 관리 부담이 줄어듭니다.

6. 규칙 기반 라우팅과 매칭 확인

위에서 아래로 규칙을 읽으세요

규칙 기반 라우팅은 위에서 아래 순서로 매칭하며, 먼저 일치한 규칙이 연결을 어느 정책에 보낼지 결정합니다. 따라서 구체적인 예외는 범위가 넓은 규칙보다 앞에, 최종 기본 규칙은 맨 끝에 두는 것이 일반적입니다. 도메인이 앞쪽의 접미사 규칙과 이미 일치했다면 뒤쪽의 더 구체적인 항목은 보통 적용되지 않습니다. 규칙을 추가하기 전에 기존 순서를 먼저 살펴보세요. 한 줄 더 추가한다고 기존 동작을 덮어쓸 수 있는 것은 아닙니다.

도메인 규칙은 커널이 대상 도메인을 확인할 수 있어야 작동합니다. 앱이 IP에 직접 연결하거나 트래픽 유입 과정에서 대상 정보가 사라지면 예상한 도메인 규칙과 일치하지 않을 수 있습니다. 이때 연결 화면에 대상 주소만 표시될 수 있으므로 DNS 모드, 스니핑 기능, 앱 동작을 함께 확인하세요. 규칙이 일치하지 않는다고 전체 네트워크 범위의 프록시 적용을 넓히지 마세요. 로컬 기기나 원래 직접 연결해야 하는 서비스까지 프록시 출구로 보낼 수 있습니다.

최소 규칙부터 만들고 하나씩 확장하세요

연습할 때는 확인하기 쉬운 도메인 규칙과 직접 연결 기본 규칙부터 사용해 순서와 대상 정보가 맞는지 확인한 다음 프록시 그룹을 추가하세요. 아래 예시는 기존 설정의 규칙 영역에 넣어 사용하는 것으로, 루프백과 흔한 사설 주소는 직접 연결하고 예시 도메인으로 접미사 매칭을 확인합니다. 모든 LAN 주소나 IPv6 상황을 다루는 완전한 목록은 아니므로 모든 네트워크에 적용되는 최종 템플릿으로 사용하면 안 됩니다.

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

no-resolve는 현재 IP 규칙을 위해 도메인 조회를 일부러 시작하지 않도록 합니다. 설정 전체에서 DNS를 사용하지 않는다는 뜻은 아닙니다. 연결 대상이 이미 IP라면 주소 대역 규칙에 매칭될 수 있지만, 대상이 도메인이고 아직 주소를 얻지 못했다면 이 규칙이 일치하지 않을 수 있습니다. 지리 기반 규칙은 데이터베이스와 DNS 조회 결과에도 의존하므로 웹사이트의 언어나 운영 주체의 소재지를 기준으로 판단하는 규칙과 같지 않습니다.

원격 규칙 제공자를 사용할 때는 제공자 이름, 형식, 동작 유형, 업데이트 시간도 확인해야 합니다. 규칙 세트가 로컬에 캐시돼 있다고 해서 업데이트가 성공한 것은 아닙니다. 업데이트가 성공해도 대상 사이트와 관련된 도메인이 모두 포함된다는 보장은 없습니다. 메인 페이지, 로그인, 이미지, API가 서로 다른 도메인을 사용할 수 있습니다. 실제 연결 기록을 참고해 필요한 항목을 추가하고, 브라우저 주소창에 보이는 도메인 하나만 등록하지 마세요.

출구 확인용 웹페이지에 의존하지 말고 연결 기록으로 검증하세요

규칙을 저장하고 설정을 다시 불러온 뒤 새 요청을 보내세요. 연결 화면에서 대상, 매칭 규칙, 정책 체인, 최종 출구를 확인할 수 있습니다. 출구 IP 조회는 해당 조회 요청이 사용한 출구만 알려주며 다른 앱도 같은 정책을 사용한다는 증거는 아닙니다. 비교할 때는 특정 페이지를 다시 열거나 명령줄 요청을 한 번 보내는 것처럼 반복할 수 있는 작업을 선택하고, 기록이 나타난 직후 매칭 정보를 확인하세요.

사용자 지정 규칙을 저장한 뒤 사라진다면 원격 구독을 직접 편집했는지, 병합 과정에서 오버라이드가 교체됐는지 확인하세요. 규칙은 남아 있지만 매칭되지 않는다면 순서, 도메인 확인 여부, 기존 연결 재사용을 살펴보세요. 올바른 정책에 매칭됐는데도 접속에 실패하면 규칙을 계속 쌓지 말고 노드와 DNS를 점검하세요. 인터넷 속도 저하 시 단계별 문제 해결 순서를 함께 참고하면 모든 네트워크 증상을 라우팅 문제로만 돌리지 않을 수 있습니다.

7. TUN 및 DNS 설정

시스템 프록시가 안정된 뒤 트래픽 유입 범위를 넓히세요

TUN은 시스템 프록시를 따르지 않는 앱의 트래픽까지 가져와야 할 때 적합하지만, 가상 네트워크 어댑터, 라우팅, DNS 경로라는 변수가 추가됩니다. 데스크톱에서는 먼저 시스템 프록시로 설정과 노드가 정상인지 확인한 다음 클라이언트 안내에 따라 서비스를 설치하거나 네트워크 권한을 허용하세요. 모바일은 데스크톱 서비스와 다른 방식으로 시스템 VPN 인터페이스를 사용하므로 같은 이름의 버튼을 무작정 찾지 마세요. 인터페이스를 만들 수 있는지와 트래픽을 올바르게 전달할 수 있는지도 각각 확인해야 합니다.

활성화 전에 기존 VPN, 가상 머신, 컨테이너 네트워크를 기록해 두세요. 경로가 겹치면 연결이 우회할 수 있습니다. 활성화 후에는 일반 도메인에 접속한 다음 LAN 기기, 업무용 네트워크, 기존 VPN도 점검하세요. LAN 접속만 실패한다면 원격 노드를 바꾸기보다 직접 연결 규칙, 제외 경로, 대상 네트워크 대역을 먼저 확인하세요. 조직 내부 도메인에 접속할 때는 전용 DNS 조회 경로를 유지해야 할 수도 있습니다.

DNS, Fake-IP와 대상 식별

DNS는 도메인을 IP 주소로 변환하지만 프록시 연결이 시스템 DNS만으로 결정되는 것은 아닙니다. 앱 자체 DNS, 브라우저의 보안 DNS, 시스템 DNS, 커널 DNS가 동시에 작동할 수 있습니다. 문제를 해결할 때는 먼저 요청을 실제로 어떤 구성 요소가 처리하는지 확인한 뒤 해당 설정을 변경하세요. 요청이 커널 DNS에 들어오지 않는다면 상위 DNS 서버만 바꿔도 실제 결과는 달라지지 않을 수 있습니다. 암호화 DNS는 처음 연결할 때 부트스트랩 조회가 필요할 수도 있습니다.

Fake-IP 모드에서는 앱에 매핑용 주소를 반환하고, 커널이 주소와 도메인 사이의 관계를 저장해 두었다가 이를 바탕으로 대상을 복원하고 규칙을 적용합니다. 이 주소는 원격 서버의 실제 공인 IP가 아니므로 서버 위치를 판단하는 데 사용할 수 없습니다. 실제 주소, 브로드캐스트 탐색, 특수한 DNS 동작에 의존하는 앱은 예외 처리해야 할 수 있습니다. 작동 원리는 Fake-IP와 Redir-Host 안내를 참고하세요.

아래는 해당 필드를 지원하는 데스크톱 mihomo 환경을 위한 독립적인 직접 연결 테스트 설정입니다. DNS는 로컬의 높은 포트에서 리스닝하며, TUN 자동 라우팅과 인터페이스 탐색에는 시스템 권한이 필요합니다. 필드의 의미와 트래픽 유입 여부를 확인하는 용도이며 프록시 노드는 포함하지 않습니다. 사내 네트워크, 다른 VPN, 특수 라우팅 환경에서는 충돌 여부를 먼저 평가하세요. 정상 작동 중인 전체 설정을 그대로 덮어쓰지 마세요.

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

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

rules:
  - MATCH,DIRECT

라우팅과 DNS 조회를 각각 검증하세요

dns-hijack는 지정된 DNS 트래픽을 받지만, 앱이 HTTPS 등으로 자체 DNS 조회를 수행하면 일반 DNS 포트에 대한 하이재킹 설정만으로 이를 자동 대체하지는 않습니다. auto-route는 관련 라우팅을 자동으로 설정하고 auto-detect-interface는 출구 인터페이스를 탐색합니다. 다중 네트워크 어댑터, 가상 네트워크, 기본 경로 변경이 있는 환경에서는 직접 확인이 필요할 수 있습니다. 필드가 설정에 있다고 해서 현재 환경에서 출구를 항상 올바르게 자동 선택하는 것은 아닙니다.

브라우저는 정상이지만 다른 앱이 실패한다면 앱 요청이 연결 화면에 나타나는지 확인하세요. 도메인은 실패하지만 알려진 IP에 접속할 수 있다면 DNS를 중점적으로 점검하세요. TUN을 켠 뒤 모든 연결이 끊기면 TUN을 먼저 꺼 원래 경로를 복구한 다음 서비스 권한, 기본 경로, 중복 트래픽 유입을 확인하세요. DNS 모드를 변경한 뒤에는 앱 연결을 새로 만들고 필요하면 해당 캐시를 비우세요. 이전 매핑을 사용해 새 설정을 검증하지 않도록 주의해야 합니다.

최종 검증은 웹페이지가 열리는지만 확인하는 것이 아닙니다. 절전 모드에서 깨어난 뒤, 네트워크를 전환한 뒤, 클라이언트를 종료한 뒤에도 정상적으로 복구되는지 확인해야 합니다. TUN을 꺼도 문제가 계속되면 보조 서비스와 가상 인터페이스가 정상적으로 종료됐는지, 시스템 프록시가 남아 있는지 확인하세요. 트래픽 유입 범위가 넓을수록 복구 경로가 중요합니다. 검증을 마친 시스템 프록시 설정을 보관하면 복잡한 네트워크 문제에서 명확한 비교 기준으로 사용할 수 있습니다.

8. 유지 관리와 복구

업데이트를 세 종류로 나누세요

클라이언트, 커널, 구독 업데이트는 서로 다른 문제를 해결합니다. 클라이언트 업데이트는 화면, 서비스, 설정 생성 방식에 영향을 줄 수 있고, 커널 업데이트는 프로토콜과 필드 지원에 영향을 줍니다. 구독 업데이트는 노드, 정책, 규칙을 변경합니다. 유지 관리할 때는 한 번에 한 종류만 업데이트하고 안정성을 확인한 뒤 다음 작업을 진행하세요. 세 가지가 한꺼번에 바뀌면 문제가 생겼을 때 무엇을 되돌려야 할지 파악하기 어렵고 설정 차이를 프로그램 결함으로 오해할 수 있습니다.

업데이트 전에 활성 설정, 오버라이드 내용, 주요 설정을 보관하고 시스템 프록시 포트, 현재 정책 선택, TUN 상태, 서비스 설치 여부를 기록하세요. 백업은 화면 캡처가 아니라 실제 실행 상태를 복원할 수 있어야 합니다. 업데이트 후에는 최종 적용 설정을 확인하고, 특히 클라이언트가 자동 관리하는 필드를 점검하세요. 일부 클라이언트는 화면 설정으로 YAML 값을 덮어쓰므로 원본 파일만 비교해서는 전체 변경 사항을 알 수 없습니다.

복구도 계층별로 진행하세요. 구독이 바뀌었다면 검증된 로컬 복사본으로 돌아가고, 오버라이드 오류라면 해당 확장을 일시적으로 끄세요. 클라이언트 업데이트에 문제가 생기면 해당 설치 안내에 따라 프로그램과 서비스를 처리해야 합니다. 이전 버전 프로그램을 새 설정 디렉터리에 바로 덮어쓰지 마세요. 설정 구조나 데이터베이스가 호환되지 않을 수 있습니다. 구형 환경을 테스트할 때는 별도의 백업을 사용하고, 같은 포트나 네트워크 인터페이스를 두 인스턴스가 동시에 점유하지 않도록 하세요.

시작 프로그램 등록과 백그라운드 실행

시작 프로그램 등록은 대개 클라이언트를 실행할 뿐, 커널, 구독, 시스템 프록시까지 모두 준비되는 것을 보장하지 않습니다. 수동 실행으로 먼저 검증한 다음 클라이언트의 자동 시작 옵션을 켜세요. 다음에 재부팅한 뒤 프로그램 실행, 활성 설정, 예상한 트래픽 유입 기능 활성화를 차례로 확인하고 마지막으로 실제 접속을 테스트하세요. 커널이 리스닝하기 전에 시스템 프록시가 먼저 켜지면 시작 과정에서 잠시 네트워크에 접속하지 못할 수 있습니다.

절전 모드에서 깨어난 뒤와 네트워크를 전환한 뒤의 동작도 점검해야 합니다. Wi-Fi에서 유선, 모바일 핫스팟, 다른 라우터로 바뀌면 기본 네트워크 어댑터와 DNS가 달라질 수 있으며 TUN이 경로를 다시 파악해야 합니다. 깨어날 때마다 연결이 실패한다면 인터페이스 변경과 로그 시간을 기록한 뒤 트래픽 유입 기능이나 커널을 순서대로 재시작해 보세요. 반복되는 문제를 단순히 노드 불안정으로 치부하면 기기의 라우팅 복구 문제를 놓칠 수 있습니다.

Android의 백그라운드 실행은 제조사별 절전 정책에 맞춰 설정하세요. 필요한 백그라운드 활동을 허용하고 화면을 잠근 뒤 연결이 끊기는지 확인한 다음 배터리 최적화 제외 목록에 추가할지 결정하세요. 모든 앱 권한을 한꺼번에 허용하지 말고, 상시 알림을 줄이려고 시스템이 요구하는 포그라운드 실행 방식을 망가뜨리지 마세요. 배터리 사용량은 비슷한 화면 밝기, 네트워크, 사용 시간에서 비교하고 디스플레이, 무선 신호, 프록시 트래픽의 영향을 구분하세요.

로그는 필요한 만큼만 남기고 복구 목록을 준비하세요

평소에는 info와 같은 적절한 수준으로 로그를 남기고, 원인이 분명한 문제가 발생했을 때만 상세 수준을 일시적으로 높이세요. 발생 시간, 대상 앱, 오류 증상, 당시 사용한 설정을 기록하면 확인 범위를 좁힐 수 있습니다. 로그에는 접속 도메인, 노드 주소, 인증 관련 정보가 포함될 수 있으므로 공개 전에 확인해야 합니다. 원인을 찾은 뒤에는 일반 로그 수준으로 되돌리고 더 이상 필요하지 않은 진단 파일을 삭제해 민감한 접속 기록이 오래 쌓이지 않도록 하세요.

‘Clash가 인터넷에 연결되지 않음’ 문제가 생기면 먼저 트래픽 유입 기능을 끄고 원래 네트워크를 확인하세요. 그런 다음 정상 작동이 확인된 설정을 복구하고 노드와 구독 상태를 점검합니다. 원래 네트워크도 작동하지 않으면 기기 연결, 라우터, 통신사 문제를 먼저 해결해야 합니다. 특정 앱 하나만 실패한다면 앱의 프록시 사용 여부와 연결 기록을 확인하세요. 프록시 대상 전체가 실패하지만 직접 연결은 정상이라면 노드, 서비스 상태, 출구 연결을 중점적으로 살펴보세요.

LAN 공유도 정기적으로 다시 확인해야 합니다. LAN 연결 허용을 켜면 다른 기기가 로컬 리스닝 포트에 접근할 수 있는 범위가 달라집니다. ‘집의 Wi-Fi에 연결되어 있다’는 이유만으로 접근 경계를 무시하지 마세요. 공유가 꼭 필요하다면 인증을 설정하고 방화벽에서 허용할 출처 범위를 제한한 뒤 네트워크를 바꿀 때마다 다시 확인하세요. 유지 관리의 목적은 모든 기능을 항상 켜 두는 것이 아니라 현재 기기의 네트워크 경로에 어떤 기능이 영향을 주는지 파악하는 것입니다.

9. 고급 설정과 독립적인 문제 해결

자동화를 추가하기 전에 설정 차이를 관리하세요

고급 설정은 출처를 더 많이 추가하는 것이 아니라 현재 설정 파일의 내용을 설명할 수 있는 데서 시작합니다. 구독에서 관리하는 부분, 클라이언트가 생성하는 부분, 직접 관리하는 부분을 나누고 각 항목의 수정 위치를 하나로 정하세요. 같은 DNS 필드가 화면 설정, 구독 파일, 오버라이드에 동시에 있다면 변경하기 전에 최종 우선순위를 확인하세요. 그렇지 않으면 재시작할 때마다 ‘설정이 적용되지 않는다’고 착각할 수 있습니다.

다음 단계로 노드 제공자와 규칙 제공자를 익혀 연결 매개변수, 정책 로직, 서비스 규칙을 나눠 관리할 수 있습니다. 분리하면 각각 업데이트하기 쉽지만 이름 참조, 경로, 캐시, 다운로드 의존성이 추가됩니다. 처음에는 작은 항목 하나만 분리하고 다운로드, 형식, 정책 참조가 정상인지 확인한 다음 나머지로 확장하세요. 모든 원격 리소스를 한꺼번에 추가하고 한 번 실행한 결과만으로 완료 여부를 판단하지 마세요.

자동 테스트와 장애 조치도 실제 서비스 요구에 맞춰 설정해야 합니다. 로그인 세션을 유지해야 하는 서비스는 지연 시간이 조금 늘더라도 연결을 자주 바꾸지 않는 편이 나을 수 있습니다. 일반적인 웹 탐색은 자동 선택에 따른 출구 변경을 허용할 수 있습니다. 테스트 간격은 트래픽 양과 탐지 속도를 고려해 정하고, 테스트 주소는 필요한 경로를 안정적으로 나타내는 주소를 사용하세요. 여러 프록시 그룹에서 같은 노드를 반복 테스트하면 불필요한 백그라운드 요청이 늘어날 수 있습니다.

재현 가능한 작은 실험을 구성하세요

복잡한 문제를 해결할 때는 먼저 예상 결과를 적어 두세요. 어떤 앱이 어떤 대상에 접속하고, 어떤 규칙에 매칭되며, 최종적으로 어떤 출구를 사용해야 하는지 정합니다. 그런 다음 새 브라우저 창에서 고정된 페이지를 열거나 명시적 프록시 명령으로 요청하는 등 최소한의 동작을 선택하세요. 매번 조건 하나만 바꾸고 연결이 생성됐는지, 어떤 규칙에 매칭됐는지, 어느 단계에서 오류가 났는지 기록합니다. 이렇게 하면 결과를 재현할 수 있고 다른 사람에게도 상황을 정확히 설명할 수 있습니다.

세 가지 환경을 비교해 보세요. 트래픽 유입을 끈 원래 네트워크, 정상 작동이 확인된 설정의 시스템 프록시, 동일한 설정의 TUN입니다. 원래 네트워크는 정상인데 시스템 프록시가 실패한다면 인바운드와 출구를 점검하세요. 시스템 프록시는 정상인데 TUN이 실패한다면 라우팅과 DNS 트래픽 처리를 확인하세요. 특정 도메인만 실패한다면 연관 도메인, 서비스 제한, 규칙 체인을 살펴보세요. 전체 프로그램을 다시 설치할 필요는 없습니다.

서버 실행과 원격 관리로 확장하기 전에

mihomo를 직접 실행하면 GUI 클라이언트가 대신 처리하던 설정 디렉터리, 작업 디렉터리, 서비스 사용자, 로그 순환, 장애 시 재시작을 직접 관리해야 합니다. 먼저 포그라운드에서 설정을 불러올 수 있는지 확인한 뒤 시스템 서비스에 등록하세요. 서비스 시작에 성공했다고 트래픽 유입까지 완료된 것은 아닙니다. 리스닝 주소, 라우팅, 권한을 확인해야 합니다. 라우터에서는 저장 공간, 아키텍처, 기존 방화벽 규칙도 고려해야 합니다.

원격 제어 인터페이스를 사용하면 연결을 확인하고 정책을 변경할 수 있습니다. 필요한 경우에만 활성화하고 접근을 로컬이나 관리되는 네트워크로 제한한 뒤 인증을 설정하세요. 휴대폰 패널에 연결하려고 공용 인터넷에 직접 노출하지 말고 제어 포트와 프록시 인바운드 포트를 혼동하지 마세요. 설정을 공유하기 전에 인증 정보를 삭제하세요. 원격 관리에 문제가 생기면 무작정 리스닝 범위를 넓히지 말고 접근 범위와 인증부터 확인하세요.

이 단계를 마쳤다면 요청이 커널에 어떻게 들어오고, 대상 정보를 어떻게 얻으며, 어떤 규칙에 매칭되고, 어떤 출구에 도달하는지 설명할 수 있어야 합니다. 문제가 발생했을 때 어느 계층에서 막혔는지도 찾을 수 있어야 합니다. 가장 간단한 연결 절차를 다시 확인하려면 연결 확인 가이드를 참고하세요. 각 기능의 작동 원리를 더 알아보려면 주제별 글에서 이어서 읽을 수 있습니다. 새로운 기능을 익힐 때마다 검증 기록과 복구 방법을 남긴 뒤 다음 설정으로 넘어가세요.