Clash 처음부터 끝까지 종합 가이드

핵심 개념: 요청이 Clash를 통과하는 방식 이해하기

클라이언트, 커널과 구성 파일의 관계

Clash는 하나의 화면을 가리키는 이름이 아니라 커널, 그래픽 클라이언트와 구성 파일이 함께 작동하는 구조입니다. 커널은 로컬 포트를 수신하고 구성을 해석하며 규칙을 매칭하고 프록시 연결과 DNS를 처리합니다. 그래픽 클라이언트는 설치, 업데이트, 구성 관리, 시스템 프록시 전환과 로그 표시를 담당합니다. 구성 파일에는 수신 포트, 프록시 노드, 정책 그룹, 규칙과 DNS 동작이 정의됩니다. mihomo는 흔히 Clash Meta 커널이라고 불리며 Clash 구성 체계를 이어받는 동시에 프로토콜, 규칙과 시스템 트래픽 가로채기 기능을 확장했습니다. 세 요소의 경계를 이해하면 문제 해결이 쉬워집니다. 화면이 열리지 않으면 클라이언트 계층을, 구성 로드에 실패하면 먼저 YAML을, 특정 사이트가 잘못된 경로로 연결되면 규칙과 정책 그룹을 확인하세요.

일반적인 브라우저 요청은 먼저 시스템 프록시나 TUN 가상 네트워크 카드로 들어간 뒤 커널로 전달됩니다. 커널은 요청의 도메인, 대상 주소, 포트와 네트워크 유형을 읽고 구성의 rules를 위에서부터 확인해 처음 일치하는 항목을 찾습니다. 일치 항목은 보통 특정 서버가 아니라 정책 그룹을 가리킵니다. 정책 그룹은 현재 선택, 자동 테스트 또는 폴백 로직에 따라 실제 프록시, 직접 연결 또는 거부를 결정합니다. 이 과정은 “트래픽 진입 → 규칙 매칭 → 정책 그룹 → 아웃바운드 연결”로 요약할 수 있습니다. 어느 한 계층의 설정만 달라도 “클라이언트에는 연결됨으로 표시되지만 접속 결과가 예상과 다름”이라는 문제가 발생할 수 있습니다.

수신 포트와 시스템 프록시

Clash의 일반적인 진입점에는 HTTP, SOCKS와 mixed-port가 있습니다. HTTP 프록시는 시스템 프록시나 수동 프록시를 지원하는 프로그램에 적합하고, SOCKS는 더 범용적인 TCP 요청을 처리할 수 있습니다. mixed-port는 하나의 포트에서 HTTP와 SOCKS를 동시에 받아 포트 수를 줄이는 데 유용합니다. 시스템 프록시 전환은 운영체제의 프록시 주소를 로컬 수신 포트로 지정할 뿐, 구성 파일의 규칙을 바꾸거나 시스템 프록시를 완전히 무시하는 앱을 제어하지는 않습니다. “브라우저는 되는데 특정 프로그램은 안 됨”이라면 먼저 해당 프로그램이 시스템 프록시를 읽는지 확인하세요. 읽지 않는다면 프로그램 내부에서 별도로 프록시를 설정하거나 TUN을 활성화해야 합니다.

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

위의 최소 구성은 커널이 로컬에서 혼합 포트를 수신하고, 기본적으로 같은 네트워크의 다른 기기에는 공개하지 않으며, 규칙 모드와 일반 로그 수준을 사용하는 예입니다. 포트 번호는 변경할 수 있지만 변경 후에는 시스템 프록시나 앱 프록시의 포트도 함께 수정해야 합니다. 시작 로그에 수신 실패가 나타나면 대개 다른 프로세스가 이미 해당 포트를 사용 중인 경우입니다. Clash 포트 충돌 확인 절차에서 프로세스를 확인한 뒤 충돌 프로그램을 종료할지 포트를 변경할지 결정하세요.

노드, 정책 그룹과 규칙은 서로 다른 계층입니다

노드는 서버, 포트, 프로토콜과 인증 정보 등을 포함하는 구체적인 아웃바운드 연결 정의입니다. 정책 그룹은 여러 노드나 다른 정책을 묶어 관리하는 방식이고, 규칙은 요청을 정책 그룹으로 보냅니다. 일상적으로 경로를 바꿀 때는 규칙을 반복해서 편집하기보다 정책 그룹을 조작하는 것이 좋습니다. 예를 들어 “프록시 선택” 수동 그룹과 “자동 선택” 속도 테스트 그룹을 만든 뒤, 두 그룹을 상위의 “기본 출구”에 넣을 수 있습니다. 동영상, 다운로드, 업무 서비스 등의 규칙은 안정적인 그룹 이름만 참조합니다. 이렇게 하면 구독이나 노드를 바꿔도 규칙 계층을 다시 작성할 필요가 없습니다.

클라이언트 선택: 플랫폼, 커널과 관리 방식 비교

기능이 완비된 그래픽 클라이언트를 우선 선택

대부분의 사용자는 그래픽 클라이언트부터 시작하는 것이 좋습니다. 이 사이트에서 각 플랫폼의 우선 추천 제품은 Clash Plus입니다. 주요 플랫폼의 설치 경로, 구성 관리와 연결 제어를 제공하므로 처음 사용할 때와 일상적인 유지 관리에 적합합니다. Windows, macOS, Android와 iOS 사용자는 먼저 다운로드 페이지에서 플랫폼을 선택하고 시스템 요구 사항을 확인한 뒤 설치하세요. 클라이언트를 고를 때는 화면 디자인만 보지 말고 다음 네 가지를 확인해야 합니다. 현재 운영체제와 프로세서 아키텍처를 지원하는지, 현재 구성과 호환되는 커널을 사용하는지, Profile 업데이트와 전환을 제공하는지, 필요에 따라 시스템 프록시나 TUN을 관리할 수 있는지 확인하세요.

Windows와 Linux에서는 Clash Verge Rev 또는 FlClash를 선택할 수 있고, Windows에서는 Clash Nyanpasu도 사용할 수 있습니다. Android에서는 Clash Meta for Android, FlClash 또는 Surfboard를 선택할 수 있으며, macOS에서는 보관 상태인 ClashX Meta도 확인할 수 있습니다. Clash for Windows 역시 유지 관리가 중단된 보관 클라이언트입니다. 보관 상태라고 해서 기존 구성이 즉시 무효가 되는 것은 아니지만, 새 배포의 장기적인 기반으로는 적합하지 않습니다. 기존 환경이 구형 클라이언트에 의존한다면 마이그레이션 전에 구성과 오버라이드 설정을 내보낸 뒤 새 클라이언트에서 항목별로 복원하세요. 클라이언트, 커널, DNS와 TUN을 동시에 바꾸면 문제의 원인을 구분하기 어렵습니다.

프로세서 아키텍처 구분

설치 파일 이름의 x64, AMD64, ARM64, Apple Silicon 등의 표기는 서로 다른 프로세서 아키텍처를 의미합니다. 대부분의 일반적인 Windows PC는 x64를 사용하며, Windows on ARM 기기는 클라이언트가 ARM64 빌드를 제공하는지 확인해야 합니다. 최신 Mac은 대개 Apple Silicon을 사용하므로 ARM 빌드에 해당하고, 구형 Intel Mac은 x64 빌드를 사용합니다. Android 기기는 일반적으로 arm64 패키지를 우선 사용하며, 아키텍처가 불분명하거나 설치에 실패할 때만 범용 패키지를 고려하세요. Linux에서는 AMD64와 ARM뿐 아니라 deb, rpm과 압축된 커널 파일도 구분해야 합니다. 데스크톱 배포판은 해당 패키지 관리 형식이 적합하고, 서버와 라우터 환경에서는 mihomo 커널을 직접 실행하는 경우가 많습니다.

그래픽 클라이언트와 독립 커널의 경계

독립 mihomo 커널은 시작 매개변수, 구성 디렉터리, 서비스 권한과 로그 출력을 정밀하게 제어해야 하는 환경에 적합합니다. 데스크톱 그래픽 화면을 자동으로 제공하지 않으며 시스템 프록시도 대신 변경하지 않습니다. 서버에 배포할 때는 일반적으로 명령줄에서 구성 디렉터리를 지정한 뒤 시스템 서비스 관리자로 실행 상태를 유지합니다. 데스크톱 사용자가 구독을 가져와 연결하려는 목적이라면 커널 압축 파일부터 시작할 필요가 없습니다. 그래픽 클라이언트가 커널 수명 주기, Profile 전환과 시스템 설정을 처리하므로 문제를 더 쉽게 찾을 수 있습니다.

같은 기기에서 여러 클라이언트가 동일한 포트를 동시에 사용하거나 TUN을 동시에 활성화하지 않도록 주의하세요. 마이그레이션할 때는 먼저 기존 클라이언트를 종료하고 백그라운드 커널이 멈췄는지 확인한 다음 새 클라이언트를 시작하세요. 새 클라이언트에서 포트 사용 중이라는 메시지가 표시되어도 무작위 포트를 연달아 바꾸지 말고 잔존 프로세스부터 확인해야 합니다. 시스템 프록시가 여전히 이전 포트를 가리키면 기존 프록시 상태를 끈 뒤 새 클라이언트가 다시 설정하도록 하세요. “활성 커널 하나, 현재 구성 하나, 명확한 진입점 하나”를 유지하면 상호 간섭을 크게 줄일 수 있습니다.

플랫폼별 설치: 권한, 진입점과 최초 실행 확인

Windows와 macOS 설치

Windows 설치 전에 실행 중인 유사 클라이언트를 종료하여 기존 커널이 수신 포트를 계속 사용하지 않도록 하세요. 설치와 최초 실행이 끝나면 모든 스위치를 바로 켜지 말고 설정 화면에서 커널 상태, 구성 디렉터리와 mixed-port를 확인한 뒤 구성을 가져오세요. 시스템 프록시를 활성화하면 클라이언트가 시스템 프록시 주소를 로컬 루프백 주소와 수신 포트로 지정합니다. 브라우저가 이전 설정을 계속 사용한다면 시스템 프록시를 한 번 끈 뒤 다시 활성화하세요. 스토어 앱이나 UWP 앱만 연결되지 않는 경우에는 전역 규칙을 수정하기보다 해당 앱이 로컬 루프백 접근을 허용하는지 확인해야 합니다.

macOS 설치 시 프로세서에 맞는 Apple Silicon 또는 Intel 빌드를 선택해야 합니다. 처음 실행할 때 시스템 보안 정책에 의해 차단되면 시스템 설정에서 앱 출처와 안내 내용을 확인하세요. 시스템 프록시를 활성화하려면 네트워크 설정 변경 권한이 필요할 수 있고, TUN이나 네트워크 확장을 켤 때는 추가 승인이 나타납니다. 승인 후에는 시스템 팝업이 사라졌다는 사실만 믿지 말고 클라이언트로 돌아가 스위치 상태를 확인하세요. 기존 클라이언트가 보조 서비스를 설치했다면 마이그레이션 전에 정상적으로 서비스를 종료하여 두 보조 구성 요소가 동시에 네트워크 설정을 변경하지 않도록 하세요.

Android와 iOS 설치

Android 클라이언트는 일반적으로 시스템 VPN 인터페이스를 통해 트래픽을 가로챕니다. 처음 연결할 때 시스템에 VPN 승인 화면이 표시되며 승인하면 상태 표시줄에 연결 아이콘이 나타납니다. 앱을 전환한 뒤 연결이 빠르게 끊기면 배터리 최적화, 백그라운드 활동과 절전 제한을 확인하세요. 일부 제조사 시스템은 화면을 잠근 뒤 백그라운드 서비스를 종료하므로 클라이언트를 백그라운드 실행 허용 목록에 추가해야 합니다. 앱별 프록시, LAN 우회와 IPv6 동작은 클라이언트와 구성에 따라 달라집니다. 처음 테스트할 때는 단순한 설정을 유지하고 일반 웹 페이지 접속이 정상인지 확인한 뒤 앱별 규칙을 추가하세요.

iOS에서 Clash Plus를 사용할 때는 App Store에서 설치하고 최초 연결 시 VPN 구성 추가를 승인하세요. 시스템에서는 한 번에 하나의 활성 VPN 구성만 유지할 수 있으므로 다른 네트워크 도구가 연결되어 있다면 먼저 끊고 테스트해야 합니다. Wi-Fi와 셀룰러 네트워크를 전환한 뒤에도 클라이언트가 연결을 유지하는지 관찰하고 실제 접속 결과로 규칙 적용 여부를 확인하세요. 모바일 운영체제에서는 일부 하위 수준 로그가 숨겨지므로 문제 발생 환경이 Wi-Fi인지 셀룰러인지 또는 둘 다인지 기록하고, 특정 앱에만 영향을 주는지도 확인해야 합니다.

Linux 데스크톱과 커널 배포

Linux 데스크톱에 deb 또는 rpm 패키지를 설치한 뒤에도 데스크톱 환경이 시스템 프록시 설정을 읽는지 확인해야 합니다. 데스크톱 환경마다 HTTP, HTTPS와 SOCKS 설정 위치가 다르며 클라이언트의 “시스템 프록시” 버튼이 모든 세션에 적용되지 않을 수 있습니다. 먼저 브라우저에서 테스트한 뒤 프록시 환경 변수를 명시적으로 지원하는 명령으로 확인하세요. 독립 커널을 배포할 때는 구성용 고정 디렉터리를 만들고, 첫 실행은 포그라운드에서 진행하여 구문 오류가 터미널에 바로 표시되게 하세요. 구성을 정상적으로 읽는 것을 확인한 후 서비스 관리자로 넘기면 됩니다.

mkdir -p ~/.config/mihomo
mihomo -d ~/.config/mihomo

-d는 작업 디렉터리를 지정하며, 커널은 해당 디렉터리에서 구성과 관련 데이터 파일을 읽습니다. 실제 실행 파일 이름과 배치 경로는 다운로드 패키지를 기준으로 확인하세요. 장기 실행할 계획이라면 권한이 제한된 전용 사용자를 만들고 구성 파일과 로그 디렉터리의 소유자를 명확히 지정하세요. 권한 문제를 피하려고 전체 디렉터리의 접근 범위를 무작정 넓히면 안 됩니다. 서비스 시작에 실패하면 서비스 상태만 확인하기보다 같은 명령을 포그라운드에서 먼저 실행하는 편이 YAML 행 번호, 포트 충돌이나 리소스 파일 누락을 확인하기 쉽습니다.

최초 실행 후 확인할 네 가지

설치가 끝나면 정해진 순서로 확인하세요. 첫째, 클라이언트에 커널이 실행 중으로 표시되는지 확인합니다. 둘째, 현재 Profile이 선택되어 있고 파싱 오류가 없는지 확인합니다. 셋째, 시스템 프록시 또는 VPN/TUN 중 예상한 진입점 하나만 활성 상태인지 확인합니다. 넷째, 정책 그룹에 선택 가능한 아웃바운드가 있는지 확인합니다. 이어서 일반 사이트에 접속하고 연결 기록을 확인하여 요청이 커널에 들어왔고 규칙과 일치했으며 아웃바운드가 생성되었는지 확인하세요. 클라이언트 홈 화면의 상태 문구만으로 성공 여부를 판단하지 마세요. 시스템 프록시가 아직 적용되지 않았거나 앱이 프록시를 우회하거나 DNS를 다른 네트워크 구성 요소가 처리할 수 있습니다.

구독 및 구성: 업데이트와 롤백이 가능한 Profile 만들기

Profile은 전체 구성의 진입점입니다

Profile은 로컬 YAML 파일이나 원격 구독 주소에서 가져올 수 있습니다. 단순한 노드 목록이 아니라 정책 그룹, 규칙, DNS와 오버라이드 설정까지 포함할 수 있습니다. 원격 주소를 가져오면 클라이언트는 대개 내용을 로컬 사본으로 저장하고 업데이트 출처를 기록합니다. 이후 업데이트를 실행하면 원격 내용이 같은 Profile의 수동 수정 사항을 덮어쓸 수 있으므로 자동 업데이트 파일 안에 장기적인 사용자 설정을 직접 흩어 놓지 않는 것이 좋습니다. 원본 구독을 기반으로 보존하고 클라이언트의 오버라이드, 스크립트 또는 별도로 관리하는 로컬 구성으로 규칙을 추가하는 방식이 더 안전합니다.

여러 Profile을 관리할 때는 각 구성에 “일상 규칙”, “모바일 네트워크 테스트”, “로컬 최소 구성”처럼 용도를 나타내는 이름을 지정하세요. 가져온 시간만 나열된 이름은 피하는 것이 좋습니다. Profile을 전환하면 커널이 구성을 다시 로드하며 정책 그룹의 선택이 해당 구성의 상태로 돌아갈 수 있습니다. 전환 후에는 현재 파일 이름, 모드와 주요 정책 그룹을 확인하여 화면에는 전환된 것으로 보여도 실제로 이전 구성을 사용하고 있지는 않은지 확인하세요. 여러 구성의 업데이트 관계와 전환 방식은 Clash Profile 가져오기와 다중 구성 관리에서 계속 확인할 수 있습니다.

YAML 구조와 들여쓰기

Clash 구성은 YAML을 사용합니다. 들여쓰기가 계층을 나타내며 일반적으로 공백을 사용하고 탭 문자는 섞지 않아야 합니다. 목록 항목은 하이픈으로 시작하고 키 뒤의 콜론은 값과 올바른 구조를 유지해야 합니다. 이름에 콜론, 샵, 쉼표 또는 기타 특수 문자가 포함되면 따옴표를 사용하는 편이 안전합니다. 구성 로드에 실패하면 먼저 로그에 표시된 행 번호를 확인한 뒤 해당 행과 그 위쪽 계층을 점검하세요. 실제 오류는 앞선 목록 항목의 들여쓰기가 불완전해서 발생하는 경우가 많습니다.

mixed-port: 7890
mode: rule
log-level: info

proxy-groups:
  - name: "프록시 선택"
    type: select
    proxies:
      - "자동 선택"
      - DIRECT

  - name: "자동 선택"
    type: url-test
    proxies:
      - DIRECT
    url: "https://www.gstatic.com/generate_204"
    interval: 300

rules:
  - GEOIP,LAN,DIRECT
  - MATCH,프록시 선택

이 조각은 계층 관계를 보여주기 위한 예이며 “자동 선택” 그룹에는 DIRECT만 있으므로 구문 설명용으로만 사용합니다. 실제 노드는 일반적으로 구독이나 프록시 제공자가 작성합니다. MATCH는 마지막 기본 규칙이므로 규칙 목록의 끝에 배치해야 합니다. 그 앞의 규칙이 LAN과 기타 명시적인 대상을 우선 처리합니다. 정책 그룹 이름은 공백과 대소문자를 포함해 규칙에서 참조하는 이름과 완전히 같아야 합니다. 이름을 바꾼 뒤 규칙을 함께 수정하지 않으면 구성이 로드되지 않거나 요청이 존재하지 않는 정책으로 전달될 수 있습니다.

원격 업데이트와 로컬 오버라이드

구독 업데이트에 실패하면 먼저 “주소에 접근할 수 없음”, “서버가 오류를 반환함”, “유효한 YAML이 아님”과 “클라이언트 쓰기 실패”를 구분하세요. 업데이트 로그에서 네트워크 상태와 파싱 결과를 확인할 수 있습니다. 주소, 권한 또는 형식 문제는 반복해서 업데이트를 눌러도 해결되지 않으므로 연속으로 요청하지 마세요. 기존 로컬 사본을 계속 사용할 수 있다면 현재 활성 구성을 먼저 보존한 뒤 업데이트 출처를 별도로 점검하세요. 업데이트 후 노드는 바뀌었지만 규칙이 그대로라면 구성 제공 방식의 차이일 수 있습니다. 정책 그룹 이름까지 바뀌었다면 로컬 규칙 참조도 함께 조정해야 합니다.

오버라이드 설정은 로컬 포트, LAN 접근, DNS 선호도와 소수의 고정 규칙을 넣는 데 적합하지만, 오버라이드가 가져오기 전과 후 중 언제 적용되는지 기록해야 합니다. 나중에 적용되는 같은 이름의 필드는 앞선 값을 덮어쓰는 경우가 많고, 목록 필드는 클라이언트 구현에 따라 교체, 앞에 추가 또는 뒤에 추가될 수 있습니다. 수정 전 작동하는 구성을 내보내고, 수정 후에는 한 종류의 변화만 적용한 즉시 다시 로드하세요. 포트, DNS, 규칙과 TUN을 동시에 바꾸면 장애 원인을 확인하기 어렵습니다.

프록시 모드: Rule, Global과 Direct의 적용 범위 이해하기

일상적인 기본값으로 Rule 모드 사용

Rule 모드는 규칙을 하나씩 읽고 요청을 일치하는 정책 그룹으로 전달합니다. LAN, 자주 사용하는 직접 연결 대상, 프록시 대상과 거부 대상을 나눠 처리할 수 있어 장기 사용에 적합합니다. 규칙은 위에서 아래로 확인하며 처음 일치하면 중지하므로 규칙 수보다 순서가 중요합니다. 더 구체적인 규칙을 더 넓은 규칙보다 앞에 배치하세요. 예를 들어 완전한 도메인을 도메인 접미사보다 앞에 두고, 사설 네트워크 주소를 일반 IP 규칙보다 앞에 배치하며, 마지막에는 MATCH로 미일치 트래픽을 처리합니다.

Rule 모드의 “프록시 선택”은 모드 스위치가 아니라 정책 그룹의 현재 아웃바운드입니다. 정책 그룹에서 특정 노드, 자동 테스트 그룹 또는 DIRECT를 선택할 수 있습니다. 특정 사이트가 잘못된 경로로 연결되면 먼저 Global 모드로 바꾸기보다 연결 기록에서 일치한 규칙과 정책 이름을 확인하세요. Global 모드는 노드 자체의 사용 가능 여부를 빠르게 확인하는 데 유용하지만 기존 분기 로직을 우회하므로 규칙 구성이 올바르다는 것을 증명하지는 않습니다.

규칙 문제를 분리할 때 Global 모드 사용

Global 모드는 일반적으로 커널에 들어온 트래픽을 전부 전역 정책 그룹으로 보냅니다. 짧은 진단에 적합합니다. Rule 모드에서 실패했지만 Global 모드에서 같은 노드로 접속된다면 문제는 규칙, DNS 결과 또는 정책 그룹 참조에 있을 가능성이 큽니다. 두 모드 모두 실패하면 노드, 대상 네트워크, 수신 진입점과 시스템 권한을 계속 확인해야 합니다. 진단을 마치면 Rule 모드로 돌아가 LAN, 소프트웨어 업데이트와 로컬 서비스까지 불필요하게 프록시로 보내지 않도록 하세요.

Global 모드는 원래 커널에 들어오지 않는 트래픽까지 자동으로 끌어오지 않습니다. 특정 앱이 시스템 프록시를 무시하면 클라이언트를 Global로 전환해도 계속 직접 연결할 수 있습니다. 이 경우 연결 기록에서 해당 앱의 요청이 보이지 않는 경우가 많습니다. 앱 자체의 프록시 설정을 확인하거나 필요성을 검토한 뒤 TUN을 활성화하세요. 핵심은 다음과 같습니다. 모드는 “커널에 들어온 뒤의 처리 방식”을 결정하고, 시스템 프록시와 TUN은 “요청이 커널에 들어오는지”를 결정합니다. 두 기능은 서로 대체할 수 없습니다.

Direct 모드와 실제 종료

Direct 모드는 보통 커널에 들어온 요청을 대상에 직접 연결합니다. 비교 테스트에는 적합하지만 클라이언트를 완전히 종료한 것과 같지는 않습니다. 시스템 프록시는 여전히 Clash를 가리킬 수 있고 DNS도 커널이 처리할 수 있으며 앱 연결 기록도 계속 나타날 수 있습니다. 운영체제의 원래 네트워크 경로를 복원하려면 먼저 시스템 프록시나 TUN을 끄고 커널을 중지하세요. 클라이언트에 “시스템 프록시 복원” 기능이 있다면 이를 정상적으로 실행하여 운영체제에 잘못된 로컬 프록시 주소가 남지 않도록 하세요.

지연 시간은 상대적인 참고값으로만 사용

정책 그룹의 지연 시간 테스트는 보통 특정 주소에 연결하여 노드에 도달할 수 있는지와 특정 테스트 경로를 비교합니다. 모든 사이트의 실제 응답 시간과 같지 않으며 대역폭, 패킷 손실, 연결 재사용, DNS, 혼잡과 대상 서버 상태를 완전히 반영하지도 않습니다. 자동 테스트 그룹에는 안정적이고 응답 본문이 작은 테스트 주소를 사용하고 적절한 간격을 설정하세요. 간격이 너무 짧으면 추가 연결이 늘고, 너무 길면 경로 변화를 제때 감지하지 못합니다. 자세한 원리는 Clash 지연 시간 테스트 수치 해석을 참고하세요.

규칙 분기: 매칭 순서부터 사용자 지정 정책까지

자주 사용하는 규칙 유형

DOMAIN은 완전한 도메인과 일치하므로 단일 호스트를 정확히 지정할 때 적합합니다. DOMAIN-SUFFIX는 도메인과 하위 도메인을 함께 매칭하여 같은 계열의 서비스를 묶을 때 사용합니다. DOMAIN-KEYWORD는 도메인 안의 키워드로 매칭하므로 범위가 넓어 신중하게 배치해야 합니다. IP-CIDR과 IP-CIDR6은 주소 대역과 일치하고, GEOIP는 주소 데이터베이스에 따라 분류합니다. PROCESS-NAME은 프로세스 식별을 지원하는 플랫폼에서 프로그램 이름으로 매칭합니다. RULE-SET은 외부 규칙 모음을 참조합니다. 마지막의 MATCH는 앞에서 매칭되지 않은 모든 요청을 처리합니다.

도메인 규칙은 보통 DNS가 대상 주소를 반환하기 전에 판단할 수 있어 도메인 규칙을 연결과 쉽게 연계할 수 있습니다. IP 규칙은 해석 결과나 실제 대상 주소에 의존합니다. 도메인 정보 없이 IP로 직접 접속하는 연결은 IP 규칙이나 기본 규칙으로만 처리할 수 있습니다. no-resolve를 활성화하면 일부 IP 규칙이 매칭을 위해 추가 해석을 실행하는 것을 막을 수 있지만, 적합성은 규칙 유형과 구성 목적에 따라 달라집니다. 규칙을 작성할 때는 단순히 적용 범위를 넓히기보다 먼저 정책 그룹의 역할을 정의하고, 규칙이 안정적인 역할 이름을 참조하게 하세요.

rules:
  - DOMAIN,updates.example.test,DIRECT
  - DOMAIN-SUFFIX,example.test,프록시 선택
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,LAN,DIRECT
  - MATCH,프록시 선택

예시는 예약된 테스트 도메인을 사용해 구문을 설명합니다. 첫 번째 완전한 도메인 규칙이 뒤의 접미사 규칙보다 우선하므로 update 호스트는 직접 연결되고, 같은 접미사를 가진 다른 호스트는 “프록시 선택”으로 전달됩니다. 사설 주소 대역은 직접 연결로 유지되며 마지막에는 MATCH가 기본 처리합니다. 실제 구성에서는 로컬 네트워크에 필요한 주소 대역을 추가하고 LAN 서비스가 원격 아웃바운드로 전달되지 않는지 확인해야 합니다.

규칙 순서가 최종 결과를 결정합니다

Clash는 모든 규칙 중 “가장 정확한 하나”를 찾지 않고 처음 일치하는 규칙을 사용합니다. 따라서 넓은 범위의 DOMAIN-SUFFIX가 앞에 있으면 뒤의 완전한 도메인 예외 규칙은 절대 적용되지 않습니다. MATCH를 앞에 배치하면 이후의 모든 규칙도 무효가 됩니다. 규칙을 조정할 때는 먼저 연결 기록에서 대상 도메인, 대상 주소와 현재 일치 항목을 찾고, 충돌을 일으키는 넓은 규칙보다 앞에 예외 규칙을 배치하세요.

규칙 모음도 현재 위치의 순서를 따릅니다. 여러 규칙 모음을 참조할 때는 각 모음의 범위와 업데이트 출처를 명확히 하세요. 역할이 겹치는 모음을 대량으로 동시에 불러오면 앞선 모음이 같은 도메인을 먼저 가로채 후속 규칙을 이해하기 어려워집니다. 규칙을 “로컬 및 사설 네트워크, 명시적 직접 연결, 명시적 프록시, 특정 서비스, 주소 규칙, 최종 기본값”으로 나눠 관리하고, 변경할 때마다 대표 대상을 몇 개 선택해 연결 기록을 확인하세요.

규칙을 쌓는 것보다 정책 그룹 설계가 중요합니다

일반적인 정책 그룹 유형에는 select, url-test, fallback과 load-balance가 있습니다. select는 사용자가 직접 선택하고, url-test는 후보 아웃바운드를 주기적으로 비교하며, fallback은 순서대로 사용 가능한 항목을 선택하고, load-balance는 여러 아웃바운드에 연결을 분산합니다. 자동 테스트가 모든 작업에 맞는 것은 아닙니다. 고정 출구가 필요한 로그인 세션에는 수동 그룹이 더 적합하고, 연속성이 중요한 다운로드 작업도 자주 전환되어서는 안 됩니다. 먼저 “수동 선택”과 “자동 선택”을 만든 다음 업무, 미디어, 다운로드 등의 용도별 상위 그룹을 만들 수 있습니다.

정책 그룹은 다른 정책 그룹을 참조해 계층 구조를 만들 수 있지만 계층이 지나치게 깊으면 문제 해결 비용이 커집니다. 업무 규칙은 안정적인 상위 그룹 몇 개만 참조하고, 하위 노드의 변경은 구독과 자동 그룹이 처리하도록 하는 것이 좋습니다. 정책 그룹을 삭제하기 전에는 이름을 전체 검색하여 규칙, 프록시 제공자나 다른 정책 그룹이 계속 참조하는지 확인하세요. 사용자 지정 규칙의 전체 수정 방법은 실제 구성에 맞춰 사이트의 사용 문서를 참고하고, mihomo로 마이그레이션할 때는 mihomo 커널 기능과 구성 차이를 확인하세요.

DNS 및 TUN: 시스템 트래픽 가로채기와 도메인 해석

시스템 프록시 외에 TUN이 필요한 이유

시스템 프록시는 프록시 설정을 능동적으로 읽는 앱에만 영향을 줍니다. 게임, 일부 명령줄 도구, 독립 업데이트 프로그램과 특수 네트워크 스택을 사용하는 프로그램은 직접 연결할 수 있습니다. TUN은 가상 네트워크 인터페이스를 만들어 라우팅 조건에 맞는 IP 트래픽을 커널로 보내므로 적용 범위가 더 넓습니다. 그러나 관리자 권한, 라우팅 테이블, DNS 가로채기, 가상 네트워크 카드, 다른 VPN과 보안 소프트웨어라는 변수가 추가됩니다. 처음 TUN을 활성화하기 전에는 일반 시스템 프록시가 Rule 모드에서 안정적으로 작동하도록 한 뒤 TUN을 별도 단계로 테스트하세요.

TUN을 활성화한 뒤 웹 페이지가 모두 열리지 않으면 먼저 커널 로그에서 가상 인터페이스가 성공적으로 생성되었는지 확인하고 기본 경로와 DNS를 점검하세요. LAN 기기만 접근할 수 없다면 사설 주소가 TUN을 우회하는지, 로컬 네트워크 대역 경로가 유지되는지, 규칙에서 LAN 주소를 DIRECT로 지정했는지 확인해야 합니다. TUN을 끈 뒤에도 네트워크가 복구되지 않으면 클라이언트를 종료하고 시스템에 가상 인터페이스나 잘못된 프록시 설정이 남아 있는지 확인하세요. 장애 상태에서 여러 VPN 도구를 반복 전환하지 마세요. 동일한 라우팅을 계속 덮어쓸 수 있습니다.

DNS 모드와 요청 경로

DNS는 도메인을 주소로 변환하는 방식을 결정하며 도메인 규칙이 연결과 올바르게 연계되는지에도 영향을 줍니다. 시스템 DNS가 Clash 외부에서 처리되면 도메인 요청이 지정한 업스트림을 우회할 수 있고, 앱이 자체적으로 암호화 DNS를 사용하면 커널에는 대상 주소만 보일 수 있습니다. Clash의 DNS 구성에서는 수신 주소, 활성화 여부, IPv6 동작, 향상 모드, 기본 리졸버와 업스트림 서버를 지정할 수 있습니다. 업스트림은 접근 가능성과 용도를 함께 고려해 선택하고 주소를 무작정 많이 추가하지 마세요. 구성이 복잡할수록 각 리졸버가 어느 단계를 담당하는지 기록해야 합니다.

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - "https://dns.alidns.com/dns-query"

fake-ip 모드는 도메인에 예약 주소 대역의 매핑 주소를 반환하여 이후 연결에서도 커널이 도메인 관계를 유지하도록 하므로 규칙 매칭에 유리합니다. 일부 LAN 서비스, 기기 검색, 로그인 인증 또는 해석 결과에 특수한 요구가 있는 도메인은 fake-ip에 적합하지 않을 수 있어 필터 목록에 추가해야 합니다. 필터 항목을 무한정 늘리지 말고, 추가하기 전에 문제가 실제로 fake-ip 매핑 때문에 발생했는지 확인하고 대상 도메인을 기록하세요. redir-host로 바꾸면 해석과 연결 동작이 달라지므로 전환 후 시스템과 앱의 DNS 캐시를 비운 뒤 비교해야 합니다.

TUN 구성의 핵심 필드

tun:
  enable: true
  stack: mixed
  dns-hijack:
    - "any:53"
    - "tcp://any:53"
  auto-route: true
  auto-detect-interface: true
  strict-route: false

stack은 TUN이 사용할 네트워크 스택 구현을 결정하며 mixed는 다양한 트래픽을 함께 처리할 때 자주 사용됩니다. dns-hijack은 일반적인 53번 포트의 DNS 요청을 커널로 전달하고, auto-route는 필요한 경로를 자동으로 작성하며, auto-detect-interface는 현재 출구 네트워크 카드를 식별하려고 시도합니다. 엄격한 라우팅은 일부 트래픽 우회를 줄일 수 있지만 가상 머신, 컨테이너, LAN 공유와 다른 VPN에 충돌할 수도 있습니다. 이 필드들은 하나씩 조정하며 테스트하고, 플랫폼별 매개변수가 많이 포함된 구성을 통째로 복사하지 마세요.

Windows에서는 TUN에 보통 권한 상승이나 보조 서비스가 필요합니다. macOS에서는 네트워크 확장과 해당 권한이 필요하고, Linux에서는 TUN 장치에 접근하고 경로를 수정할 수 있어야 합니다. 모바일에서는 일반적으로 시스템 VPN 인터페이스를 사용합니다. 같은 YAML이라도 플랫폼에 따라 권한 조건이 완전히 같지 않을 수 있습니다. 문제가 발생하면 “구문이 올바른 구성”과 “운영체제가 실행을 허용하는지”를 나누어 확인하세요.

DNS 해석이 예상대로 작동하는지 확인

DNS 문제를 해결할 때는 시스템 측과 커널 측을 함께 관찰해야 합니다. 먼저 시스템 DNS 요청이 Clash로 들어오는지 확인하고, 커널이 어떤 업스트림을 선택했으며 어떤 유형의 결과를 반환했는지 확인한 뒤 대상 연결이 어떤 규칙과 일치했는지 살펴보세요. 진단 사이트의 한 번의 결과는 브라우저 보안 DNS, 캐시, IPv6와 네트워크 출구의 영향을 받을 수 있으므로 하나의 결론만으로 판단하면 안 됩니다. 브라우저를 바꾸거나 브라우저 자체 DNS를 끈 뒤 다시 테스트하고 연결 로그를 비교하세요. 더 자세한 점검 경로는 Clash DNS 누출 점검과 방지 설정을 참고하세요.

일상적인 유지 관리: 업데이트, 백업, 로그와 장애 분리

롤백 가능한 업데이트 절차 만들기

클라이언트, 커널, 구독과 규칙 모음은 서로 다른 네 가지 업데이트 대상입니다. 모두를 동시에 업데이트해서는 안 됩니다. 안정적인 순서는 현재 작동하는 구성을 먼저 백업하고 주요 정책 그룹 선택을 기록한 다음, 구독만 업데이트해 검증하는 것입니다. 이후 필요에 따라 클라이언트나 커널을 업데이트하고 마지막으로 외부 규칙 모음을 업데이트하세요. 각 단계에서 시작, 파싱, 연결과 규칙 일치 여부를 확인해야 합니다. 호환성 문제가 발생해도 어느 계층이 바뀌었는지 명확히 알 수 있고 이전의 정상 상태로 되돌릴 수 있습니다.

백업에는 최소한 로컬 Profile, 오버라이드 규칙, 스크립트, 정책 그룹 이름과 주요 DNS/TUN 설정이 포함되어야 합니다. 구독 주소 자체는 업데이트 출처일 뿐 로컬 백업을 대신할 수 없습니다. 원격 내용이 바뀐 뒤 다시 다운로드해도 이전 상태가 복원되지 않을 수 있습니다. 백업 파일은 용도와 날짜별로 정리하고, 클라이언트가 중복 사본을 여러 개 동시에 검색하지 않도록 하세요. 그렇지 않으면 Profile 목록에서 구성을 구분하기 어려워집니다. 복원할 때는 시스템 프록시와 TUN을 활성화하지 않은 상태에서 먼저 구성이 로드되는지 확인한 뒤 단계적으로 트래픽 가로채기를 복원하세요.

로그 수준과 연결 기록

info는 일상적인 사용에 적합하며 시작, 구성 로드와 주요 연결 정보를 확인할 수 있습니다. 규칙이나 네트워크 세부 사항을 조사해야 할 때는 일시적으로 로그 상세 수준을 높일 수 있지만, 상세 로그를 장기간 유지하면 디스크 쓰기와 확인 비용이 늘어납니다. 로그를 분석할 때는 시간대를 중심으로 접근하세요. 문제를 유발한 구체적인 작업을 기록한 뒤 같은 시간 범위에서 DNS, 규칙, 정책과 연결 오류를 찾습니다. 마지막 오류 한 줄만 확인하는 것으로는 부족한 경우가 많습니다. 원인이 그 이전의 구성 리로드나 인터페이스 생성 단계에 있을 수 있기 때문입니다.

연결 기록은 세 가지 질문에 답하는 데 유용합니다. 요청이 커널에 들어왔는지, 어떤 규칙과 일치했는지, 최종적으로 어떤 아웃바운드를 사용했는지 확인할 수 있습니다. 기록이 없다면 시스템 프록시, TUN과 앱 자체의 네트워크 설정을 점검하세요. 규칙이 예상과 다르면 도메인, 주소와 순서를 확인하고, 아웃바운드는 올바르지만 연결에 실패하면 노드, 대상 서비스와 네트워크 환경을 확인합니다. 간헐적인 문제라면 발생 당시 네트워크, Profile, 모드와 정책 그룹 선택을 기록하세요. 재현하기 전에 설정을 계속 바꾸면 안 됩니다.

일반적인 장애의 계층별 처리

포트 충돌은 시작 문제 중 가장 흔한 원인입니다. 포트를 변경하기 전에 점유 프로세스를 확인하세요. 점유자가 기존 Clash 커널이라면 서로 다른 포트를 사용하는 두 인스턴스를 장기간 함께 실행하지 말고 기존 프로세스를 정상적으로 종료해야 합니다. DNS 문제는 일부 사이트만 실패하거나 규칙 일치가 이상하거나 네트워크 전환 후 잠시 복구되는 현상으로 나타나는 경우가 많습니다. 이때 도메인 해석 실패, 예상과 다른 해석 결과, 대상 주소 연결 실패를 구분해야 하며 세 경우의 처리 계층은 서로 다릅니다.

읽기 쉽고 마이그레이션 가능한 구성 유지

정책 그룹 이름은 안정적이고 명확해야 하며 규칙은 역할별로 나누고 외부 규칙 모음은 출처와 용도를 기록해야 합니다. 같은 구성에 이미 무효가 된 노드, 중복 규칙과 사용하지 않는 정책 그룹을 대량으로 남겨 두지 마세요. 정리할 때마다 구성 검사나 클라이언트 리로드로 구문을 확인한 뒤 대표 대상을 몇 개 테스트하세요. 클라이언트를 마이그레이션할 예정이라면 기존 클라이언트의 시스템 프록시와 TUN을 먼저 끄고 구성을 내보낸 다음 새 클라이언트에서 가져와 오버라이드 기능을 확인해야 합니다. 클라이언트마다 데이터베이스, 캐시와 화면 상태가 호환되지 않을 수 있으므로 앱 데이터 디렉터리 전체를 그대로 복사하지 마세요.

일상적인 사용에서는 진단 기준으로 “최소 작동 구성”을 하나 보관하는 것이 좋습니다. 수신 포트, 명확한 아웃바운드 하나, 간단한 정책 그룹, LAN 직접 연결과 MATCH만 포함합니다. 복잡한 구성에 문제가 생기면 먼저 최소 구성으로 클라이언트와 네트워크 진입점이 정상인지 확인한 뒤 DNS, 규칙 모음과 TUN을 계층별로 추가하세요. 수천 줄의 구성에서 무작위로 필드를 지우는 것보다 안정적이며, 문제가 기본 환경에 있는지 확장 구성에 있는지도 판단할 수 있습니다.

고급 설정 경로: 안정적인 사용에서 관리 가능한 구성 체계로

1단계: 기본 진입점 고정

고급 구성의 출발점은 규칙을 더 추가하는 것이 아니라 기본 진입점을 예측 가능하게 만드는 것입니다. mixed-port를 고정하고 LAN 접근 허용 여부를 명확히 하며 일상적으로 사용할 Rule 모드를 선택하세요. 시스템 프록시와 TUN을 여러 클라이언트가 동시에 제어하지 않도록 해야 합니다. 최소 Profile을 만들고 구성 디렉터리, 클라이언트 이름과 커널 유형을 기록하세요. 완료 후에는 요청이 어디에서 들어오는지, 현재 어떤 구성인지, 기본 정책 그룹이 무엇인지, 클라이언트를 종료한 뒤 시스템 네트워크를 어떻게 복원하는지 명확히 설명할 수 있어야 합니다.

이 단계에서는 테스트 방법도 정해야 합니다. LAN 주소 하나, 직접 연결되어야 하는 대상 하나와 프록시를 사용해야 하는 대상 하나를 선택해 각각 연결 기록을 관찰하세요. 테스트할 때는 노드와 네트워크를 고정하고 한 번에 하나의 매개변수만 조정합니다. 기본 진입점이 불안정하다면 원격 규칙 모음, 복잡한 DNS나 프로세스 규칙을 급히 추가하지 마세요. 이런 기능은 관찰해야 할 변수를 늘립니다.

2단계: 정책 그룹과 규칙 재구성

노드 계층, 선택 계층과 업무 계층을 분리하세요. 하위 계층은 구독이 노드를 제공하고, 중간 계층에는 수동 선택, 자동 선택과 장애 폴백을 만들며, 상위 계층에는 “기본 출구”, “업무 서비스”, “다운로드 작업”처럼 용도별 안정적인 정책을 구성합니다. 업무 규칙은 상위 이름만 참조해야 합니다. 구독 노드가 바뀌어도 중간 및 상위 구조를 다시 작성할 필요가 없고, 임시로 경로를 바꿀 때도 규칙 파일이 아니라 정책 그룹만 조작하면 됩니다.

그 다음 규칙 순서를 정리하세요. 사설 네트워크와 명확한 예외를 먼저 처리하고, 업무 규칙 모음과 도메인 규칙을 배치한 다음 주소 규칙을 처리하며 마지막에 MATCH를 사용합니다. 규칙 모음을 추가할 때마다 적용 범위, 업데이트 주기와 대상 정책을 기록하세요. 두 모음의 범위가 크게 겹치면 역할이 더 명확한 하나만 남기세요. 자주 바뀌는 예외는 별도의 작은 로컬 규칙 영역으로 관리하고 넓은 규칙 모음보다 앞에 배치할 수 있습니다.

3단계: 구성 제공자와 규칙 제공자

노드와 규칙을 독립적으로 업데이트해야 할 때는 프록시 제공자와 규칙 제공자를 사용해 원격 콘텐츠를 주 구성에서 분리할 수 있습니다. 주 구성에는 포트, DNS, 정책 그룹과 참조 관계를 남기고 제공자가 외부 파일을 일정한 간격으로 업데이트하도록 합니다. 분리하면 관리하기 쉽지만 다운로드 실패, 경로 권한과 형식 호환성이라는 확인 항목이 늘어납니다. 제공자 업데이트에 실패하면 커널은 보통 캐시를 사용하므로 캐시 디렉터리에 쓰기 권한이 있어야 하며 최근 정상 콘텐츠를 보존해야 합니다.

rule-providers:
  local-service:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/local-service.yaml
    url: "https://example.invalid/rules/local-service.yaml"
    interval: 86400

rules:
  - RULE-SET,local-service,DIRECT
  - MATCH,프록시 선택

예시 주소는 구조를 보여주기 위한 예약 테스트 주소입니다. 실제 사용 시 규칙 파일의 동작 유형은 콘텐츠와 일치해야 합니다. domain은 도메인 모음에, ipcidr은 주소 대역에, classical은 완전한 규칙 표현식에 적합합니다. 경로는 커널이 쓰기 가능한 작업 디렉터리에 있어야 합니다. 제공자 이름도 안정적인 인터페이스이므로 변경 후 모든 RULE-SET 참조를 함께 수정하세요.

4단계: 플랫폼별 프로세스와 LAN 처리

프로세스 규칙은 운영체제와 커널이 프로세스 정보를 가져오는 기능에 의존하므로 플랫폼마다 지원 수준이 다를 수 있습니다. 사용하기 전에 연결 기록에서 프로세스 이름이 표시되는지 확인한 뒤 PROCESS-NAME 규칙을 작성하세요. 프로세스 경로, 스토어 앱 패키징과 하위 프로세스가 매칭에 영향을 줄 수 있으므로 화면에 표시된 이름만 보고 추측해서는 안 됩니다. 모바일에서는 시스템 권한과 앱 식별자를 클라이언트가 직접 처리하므로 클라이언트가 제공하는 앱별 프록시 화면을 사용하는 편이 적합합니다.

LAN 공유에는 allow-lan, 수신 주소, 방화벽과 접근 제어를 함께 고려해야 합니다. allow-lan만 켠다고 다른 기기에서 반드시 접근할 수 있는 것은 아닙니다. 로컬 방화벽이 여전히 포트를 차단할 수 있습니다. 반대로 모든 인터페이스에서 수신하면 접근 범위가 넓어집니다. 로컬에서만 사용할 때는 LAN 접근을 꺼 두세요. 공유가 꼭 필요하다면 신뢰할 수 있는 네트워크로 제한하고 다른 기기가 사용할 로컬 LAN 주소와 포트를 명확히 지정하세요. TUN에서는 사설 네트워크 대역을 직접 연결로 유지하여 프린터, 저장 장치와 개발 서비스가 프록시로 전달되지 않게 해야 합니다.

5단계: 변경 기록과 검증 목록 만들기

장기적으로 유지할 구성에는 간단한 변경 기록이 필요합니다. 수정할 때마다 목적, 필드, 검증 대상과 롤백 방법을 적으세요. 예를 들어 “특정 완전한 도메인에 직접 연결 예외를 추가하고 해당 접미사 규칙보다 앞에 배치함. 홈페이지와 다운로드 API를 확인하며, 문제가 생기면 해당 줄을 삭제하고 리로드함”처럼 작성할 수 있습니다. 설명 없이 여러 사본만 보관하는 것보다 이런 기록이 훨씬 유용합니다. 문제가 발생해도 전체 구성을 다시 읽지 않고 변경 순서에 따라 원인을 찾을 수 있습니다.

최종 검증 목록에는 클라이언트 시작, Profile 로드, 시스템 프록시, TUN, DNS, LAN, 직접 연결 대상, 프록시 대상, 정책 그룹 전환, 구독 업데이트와 규칙 모음 업데이트가 포함되어야 합니다. 사소한 변경마다 전부 확인할 필요는 없지만 진입점, DNS 또는 TUN을 변경했다면 전체 점검을 완료해야 합니다. 테스트 후 로그에 지속적인 재시도, 해석 실패나 인터페이스 오류가 있는지 확인하세요. 겉으로는 접속이 정상이어도 반복 오류를 처리해야 이후 네트워크 전환 때 문제가 한꺼번에 드러나는 것을 막을 수 있습니다.

추가로 읽을 자료와 실습 순서

이 매뉴얼을 마친 뒤에는 실제 필요에 따라 다음 단계를 선택하세요. 기본 연결을 빠르게 만들려면 사용 문서로 돌아가 가장 짧은 흐름을 다시 확인하세요. 클라이언트를 교체하려면 플랫폼별 다운로드에서 아키텍처와 시스템 요구 사항을 확인하세요. 포트 오류가 발생하면 수신 포트 문제 해결을, DNS 결과가 이상하면 DNS 점검과 수정을, 여러 구성을 관리하려면 Profile 관리 방법을, 기존 구성을 마이그레이션하려면 mihomo 구성 차이를 참고하세요.

처음부터 안정적으로 사용하는 핵심은 복잡한 구성을 한 번에 작성하는 것이 아니라 계층별로 진행하는 데 있습니다. 먼저 클라이언트와 커널이 안정적으로 시작되게 하고 업데이트 가능한 Profile을 만드세요. Rule, Global과 Direct를 이해한 뒤 사용자 지정 규칙을 작성하고, 시스템 프록시가 작동한 뒤 TUN을 활성화하세요. DNS 요청 경로를 확인한 뒤 향상 모드를 조정하고, 마지막으로 제공자, 프로세스 규칙과 자동 유지 관리를 도입합니다. 각 계층을 완료할 때마다 롤백 가능한 상태를 남겨 두면 클라이언트, 구독과 네트워크 환경이 바뀌어도 구성 체계를 계속 관리할 수 있습니다.