MANUAL / 01—09 체계적인 학습 경로

Clash 처음부터 고급 기능까지완벽 사용 가이드

클라이언트, 코어, 구독의 관계부터 시작해 설치, 설정 가져오기, 모드 선택, 규칙 분기, TUN 연결, 일상적인 유지 관리와 고급 문제 해결까지 순서대로 진행합니다. 실제 작업 순서에 맞춰 구성했으며 목차에서 현재 문제를 바로 찾을 수도 있습니다.

클라이언트 선택 빠른 튜토리얼 보기

1. 핵심 개념: 먼저 클라이언트, 코어, 구독을 구분하기

세 구성 요소는 서로 다른 역할을 맡습니다

일상적으로 말하는 “Clash”는 그래픽 클라이언트나 프록시 코어를 뜻할 수도 있고, Clash 설정 형식과 호환되는 도구들을 통칭할 수도 있습니다. 시작하기 전에 세 요소를 구분해야 합니다. 클라이언트는 창, 트레이 메뉴, 설정 관리와 시스템 권한 진입점을 제공합니다. 코어는 설정을 읽고 로컬 포트를 열며 규칙을 실행하고 네트워크 연결을 수립합니다. 구독 서비스는 서버 정보, 정책 그룹과 규칙을 제공합니다. 클라이언트를 설치했다고 사용할 수 있는 회선이 자동으로 생기는 것은 아니며, 구독을 가져왔다고 애플리케이션 트래픽이 이미 프록시를 거치는 것도 아닙니다.

Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu는 모두 그래픽 인터페이스를 갖춘 클라이언트입니다. 클라이언트에 mihomo 같은 코어가 통합되어 있을 수도 있고 코어를 바꿀 수 있는 경우도 있습니다. mihomo는 과거에 사용되던 Clash Meta라는 명칭과 계보상 관련이 있으며, 설정 필드를 인식하고 DNS를 처리하며 규칙과 TUN을 실행합니다. 인터페이스에 표시된 스위치는 최종적으로 코어 매개변수나 운영체제 네트워크 설정으로 변환됩니다. 따라서 같은 기능도 클라이언트마다 이름과 위치가 다를 수 있으며, 실제 판단은 생성된 설정과 코어 로그를 기준으로 해야 합니다.

구독은 별도의 출처입니다. 구독 주소는 일반적으로 사용자가 선택한 서비스에서 제공하며, 이 사이트와 클라이언트 프로젝트가 설치 완료만으로 구독을 자동 제공하지는 않습니다. 하나의 구독에는 노드, 프록시 정책 그룹, 원격 규칙 세트와 DNS 설정이 포함될 수도 있고, 기본 노드 목록만 들어 있을 수도 있습니다. “클라이언트는 열리지만 선택할 정책이 없다면” 클라이언트를 반복해서 재설치하기보다 먼저 구독 내용이 완전한지 확인해야 합니다.

애플리케이션에서 출구까지의 기본 트래픽 경로

시스템 프록시 환경에서는 애플리케이션이 운영체제의 HTTP 또는 SOCKS 프록시 설정을 읽고 클라이언트가 수신 대기 중인 로컬 포트로 요청을 전달합니다. 이후 코어가 설정된 모드에 따라 요청을 처리합니다. 규칙 모드에서는 위에서부터 규칙을 확인하며 첫 번째 일치 항목이 DIRECT, REJECT 또는 특정 정책 그룹 사용 여부를 결정합니다. 글로벌 모드는 일반적으로 프록시 가능한 대부분의 트래픽을 지정된 정책 그룹으로 보냅니다. 직접 연결 모드는 지원되는 트래픽을 대상에 직접 연결합니다. TUN 모드는 가상 네트워크 인터페이스를 만들어 네트워크 계층에 더 가까운 위치에서 트래픽을 인계하지만, DNS와 라우팅, 규칙 평가 과정은 여전히 거칩니다.

따라서 “클라이언트가 실행 중이다”, “로컬 포트가 수신 대기 중이다”, “시스템 프록시가 켜져 있다”, “대상 애플리케이션이 실제로 시스템 프록시를 사용한다”, “규칙이 사용 가능한 출구를 선택했다”는 서로 다른 다섯 가지 상태입니다. 브라우저에서 특정 페이지가 열린다는 사실은 브라우저의 현재 경로가 작동한다는 뜻일 뿐, 터미널·게임·가상 머신도 같은 경로를 사용한다는 의미는 아닙니다. 문제를 점검할 때는 애플리케이션 설정, 운영체제 프록시, 로컬 수신 포트, 코어 규칙, 원격 연결을 순서대로 확인해야 하며 클라이언트 메인 화면의 상태 표시 하나만 봐서는 안 됩니다.

클라이언트와 코어

설정, 정책 그룹과 노드

노드는 하나의 구체적인 연결 출구를 설명하고, 정책 그룹은 하나 이상의 노드·직접 연결 옵션·다른 정책 그룹을 선택 가능한 목적지로 묶습니다. 규칙은 특정 요청을 정책 그룹으로 전달합니다. 규칙의 PROXY는 정책 그룹 이름의 예시일 뿐이며, proxy-groups에 같은 이름의 정의가 반드시 있어야 합니다.

검증 가능한 최소 개념부터 세우기

처음부터 많은 YAML을 수정할 필요는 없습니다. 먼저 최소한의 순환 구조를 완성하세요. 플랫폼에 맞는 클라이언트를 설치하고, 출처가 명확한 구독을 가져온 뒤, 설정과 정책 그룹을 선택하고, 한 가지 트래픽 인계 방식을 켠 다음 브라우저와 터미널에서 각각 검증합니다. 이 흐름을 완료한 뒤 규칙 적용 범위, DNS와 TUN을 학습하면 여러 변수를 동시에 도입하는 일을 피할 수 있습니다. 이후에도 한 번에 한 계층만 수정하고, 수정 전 설정을 보관하며, 변경 후 나타난 로그나 접속 결과를 기록하는 원칙을 지키세요.

2. 클라이언트 선택: 플랫폼과 관리 방식으로 판단하기

먼저 조작 환경을 고르고 고급 기능을 확인하세요

클라이언트는 서로 다른 프로젝트를 단순한 성능 순위로 비교하기보다 운영체제, 설치 방식과 평소 관리 습관을 기준으로 선택해야 합니다. 처음 사용하는 사람이라면 Clash Plus를 우선 고려할 수 있습니다. 일반적인 데스크톱과 모바일 플랫폼을 지원하며 그래픽 인터페이스에서 구독 관리, 정책 선택과 연결 제어를 수행하기 좋습니다. Windows, macOS 또는 Linux에서 여러 설정을 관리해야 한다면 Clash Verge Rev와 FlClash를 비교할 수 있고, Windows 사용자는 Clash Nyanpasu도 선택할 수 있습니다. 보관된 클라이언트가 여전히 실행되더라도 지속적인 호환성 업데이트가 필요한 새로운 환경에는 적합하지 않습니다.

Android에서는 Clash Plus 외에도 기기 아키텍처와 사용 습관에 따라 Clash Meta for Android, FlClash 또는 Surfboard를 고려할 수 있습니다. iOS의 주요 진입점은 Clash Plus입니다. Linux 데스크톱 사용자는 Clash Verge Rev 또는 FlClash를 선택할 수 있으며, 서버·라우터·헤드리스 환경에는 mihomo 코어를 직접 배포하는 편이 적합합니다. 전체 플랫폼별 진입점과 최신 설치 파일은 다운로드 페이지에서 확인하세요. 그래픽 클라이언트의 설치 절차를 명령줄 코어에 그대로 적용하지 않도록 주의해야 합니다.

환경별 선택 포인트
사용 환경 우선 확인할 항목 적합한 선택지 이후 유지 관리 포인트
개인용 데스크톱 시스템 아키텍처, 시스템 프록시와 TUN 권한 Clash Plus、Clash Verge Rev、FlClash 구독 업데이트, 시작 시 실행, 코어 호환성
Android 프로세서 아키텍처, VPN 권한, 백그라운드 제한 Clash Plus、Clash Meta for Android、FlClash、Surfboard 배터리 정책, 앱별 분기, 네트워크 전환
iOS 스토어 진입점, VPN 설정 권한 Clash Plus 필요할 때 연결, 설정 업데이트와 시스템 제한
헤드리스 Linux 아키텍처, 서비스 계정, 설정 디렉터리 mihomo 코어 systemd, 로그, 권한과 원격 제어 범위

시스템 아키텍처와 패키지 형식 확인

일반적인 Windows 기기는 x64 아키텍처를 사용하므로 다운로드 페이지에서 실제로 제공하는 빌드에 맞춰 설치 파일을 선택해야 합니다. macOS는 Apple Silicon과 Intel을 구분해야 합니다. “이 Mac에 관하여”에서 칩 또는 프로세서 정보를 확인한 뒤 Apple 칩은 ARM 빌드, Intel 프로세서는 x64 빌드를 선택하세요. Android는 기기 정보나 신뢰할 수 있는 하드웨어 정보 페이지에서 ARM64, ARM 또는 범용 패키지인지 확인할 수 있습니다. 최신 기기의 대부분은 ARM64를 사용하지만 시스템 버전만으로 추정해서는 안 됩니다.

Linux에서는 배포판의 패키지 관리 방식도 맞춰야 합니다. Debian, Ubuntu 및 파생 시스템은 일반적으로 .deb를 사용하고, Fedora와 RHEL 계열은 보통 .rpm을 사용합니다. 독립 코어 압축 파일을 사용한다면 설정 디렉터리, 서비스 파일과 업데이트 절차를 직접 준비해야 합니다. 그래픽 클라이언트와 순수 코어의 차이는 창의 유무에 그치지 않습니다. 전자는 권한 요청, 시스템 프록시 반영과 코어 수명 주기를 대신 처리하는 경우가 많지만, 후자는 실행 사용자, 작업 디렉터리, 로그와 재시작 정책을 직접 관리해야 합니다.

기능을 평가할 때 실제 작업 흐름을 확인하세요

브라우저와 일반적인 데스크톱 애플리케이션만 프록시로 사용한다면 복잡한 오버라이드 기능보다 안정적인 시스템 프록시 제어와 구독 업데이트가 중요합니다. 시스템 프록시를 읽지 않는 애플리케이션까지 인계해야 한다면 클라이언트의 TUN, 권한 설치와 라우팅 복원 기능을 확인하세요. 여러 구독을 자주 관리한다면 설정 전환, 오버라이드, 구독 업데이트와 백업 메뉴가 명확한지 점검해야 합니다. 인터페이스에 특정 스위치가 있다고 해서 현재 코어가 모든 필드를 지원한다고 단정해서는 안 됩니다. 고급 설정 기능은 결국 코어 버전, 설정 형식과 운영체제의 제한을 함께 받습니다.

선택의 기준은 기능이 가장 많은 클라이언트를 찾는 것이 아니라 설치 파일과 플랫폼이 맞고, 자주 쓰는 메뉴를 이해할 수 있으며, 구독을 관리할 수 있고, 문제가 생겼을 때 로그를 확인할 수 있는지입니다. 계속 판단하기 어렵다면 플랫폼과 사용 습관에 맞는 클라이언트 선택을 읽은 뒤 다운로드 페이지로 돌아와 설치하세요.

3. 설치 및 권한: 복구 가능한 실행 환경 만들기

데스크톱 시스템의 설치 순서

설치 전에 같은 종류의 프록시 프로그램을 종료하고 현재 시스템 프록시 설정을 기록한 뒤, 설치 파일과 시스템 아키텍처가 일치하는지 확인하세요. Windows에서 처음 실행하면 방화벽이 네트워크 접근 범위를 물을 수 있습니다. 실제로 필요한 네트워크 유형에만 권한을 부여하고, 로컬 프록시 수신을 위해 공용 네트워크의 인바운드 접근을 열 필요는 없습니다. 클라이언트에 “서비스 모드”나 보조 서비스가 있다면 라우팅 변경, TUN 실행 또는 시스템 시작에 필요한 권한을 얻기 위한 기능인 경우가 많습니다. 클라이언트 내부의 공식 메뉴에서 설치하고 알 수 없는 경로에서 서비스 구성 요소를 따로 받지 마세요.

macOS에서는 앱을 “응용 프로그램” 디렉터리로 옮긴 뒤 처음 실행하세요. 다운로드 폴더에서 계속 실행하면 경로와 권한 기록이 달라질 수 있습니다. 시스템에서 앱 보안 확인, 네트워크 확장, VPN 설정 또는 키체인 접근 요청이 차례로 나타날 수 있습니다. VPN 설정은 대개 TUN 또는 Network Extension과 관련되고, 키체인 요청은 자격 증명 저장에 사용될 수 있으며, 네트워크 확장은 네트워크 트래픽 인계에 사용됩니다. 모든 요청을 같은 설치 오류로 보지 말고 사용할 기능에 맞춰 권한을 부여하세요. 자세한 내용은 macOS 권한 안내를 참고하세요.

Linux 그래픽 클라이언트를 배포판 패키지로 설치한 뒤에는 데스크톱 메뉴에서 한 번 실행하고 로그 디렉터리에 쓰기 가능한지 확인하세요. .deb 파일을 사용할 때는 파일이 있는 디렉터리에서 다음을 실행할 수 있습니다:

sudo apt install ./client-package.deb

위 파일명은 실제로 다운로드한 패키지 이름으로 바꿔야 합니다. 패키지 관리자가 의존성을 해결하므로 하위 수준 설치 명령을 직접 호출하는 것보다 누락된 구성 요소를 처리하기 쉽습니다. RPM 시스템에서는 해당 배포판의 패키지 관리 명령을 사용하세요. 헤드리스 환경에 mihomo를 배포할 때는 그래픽 클라이언트의 디렉터리 구조를 그대로 복사하지 말고 설정 디렉터리와 실행 계정을 별도로 만들며 제어 포트의 접근 범위를 제한해야 합니다.

모바일 플랫폼의 시스템 권한

Android와 iOS는 일반적으로 시스템 VPN 인터페이스를 통해 트래픽을 인계합니다. 처음 연결할 때 나타나는 VPN 권한 요청은 운영체제가 가상 네트워크 통로를 만들기 위한 절차이며, 구독 검증이 성공했다는 뜻은 아닙니다. Android에서는 배터리 최적화와 백그라운드 활동 정책도 확인해야 합니다. 화면이 잠긴 뒤 시스템이 클라이언트를 중지하면 연결이 끊기거나 예정된 업데이트가 실행되지 않을 수 있습니다. 필요한 백그라운드 실행을 허용한 뒤 네트워크를 전환했을 때 복구되는지 확인하세요. 처음부터 상시 VPN, 앱별 분기와 복잡한 DNS 오버라이드를 동시에 켜지는 마세요.

일부 Android 시스템에서는 “항상 켜진 VPN”이나 VPN을 거치지 않은 연결 제한을 설정할 수 있습니다. 이런 시스템 옵션을 켜기 전에 클라이언트가 일반 모드에서 안정적으로 연결되는지 확인하고 해제 방법도 준비하세요. 그렇지 않으면 구독 만료나 DNS 설정 오류가 발생했을 때 모든 앱이 인터넷에 연결되지 않는 것처럼 보이고, 프록시 실패인지 시스템 강제 정책이 계속 적용 중인지 구분하기 어려워집니다.

첫 실행 후 기준 상태 점검

설치가 끝나면 먼저 TUN을 켜지 마세요. 클라이언트 로그나 실행 상태 화면을 열어 코어가 시작되고 설정 디렉터리를 읽고 쓸 수 있으며 로컬 수신 포트에 충돌이 없는지 확인합니다. 일반적으로 HTTP, SOCKS 또는 mixed 포트가 사용되지만 구체적인 값은 현재 설정을 기준으로 해야 합니다. 로그에 “address already in use” 같은 메시지가 나타나면 다른 프로세스가 포트를 사용 중이라는 뜻입니다. 기존 프록시 프로그램을 종료하거나 포트를 변경해야 하며 연결 버튼을 반복해서 누를 일은 아닙니다.

그다음 종료 동작을 확인하세요. 창을 닫는 것은 트레이로 숨기는 것일 수 있으며 완전히 종료하려면 트레이 메뉴를 사용해야 합니다. 클라이언트를 삭제하거나 바꾸기 전에는 시스템 프록시와 TUN을 끈 뒤 코어를 종료하세요. 이렇게 해야 클라이언트가 라우팅과 시스템 프록시 상태를 복원할 수 있습니다. 비정상 종료가 발생했다면 운영체제 네트워크 설정에서 프록시 주소가 여전히 로컬 포트를 가리키는지 직접 확인하고 가상 네트워크 인터페이스가 남아 있는지도 점검하세요.

헤드리스 Linux의 서비스 운영 원칙

서버에서 mihomo를 실행할 때는 먼저 포그라운드에서 설정을 불러오고 오류 메시지를 읽은 뒤, 정상 동작을 확인하고 systemd로 넘겨야 합니다. 서비스 파일에는 실행 파일, 작업 디렉터리와 설정 디렉터리를 명확히 지정하고 필요한 최소 권한만 가진 계정을 사용하세요. 설정에서 외부 제어 인터페이스를 켠다면 수신 주소는 우선 로컬로 제한해야 합니다. 원격 관리가 꼭 필요할 때는 통제된 네트워크와 접근 제어를 통해 진입점을 제공하세요. 데스크톱과 서비스 배포의 차이는 Linux 배포 안내에서 더 확인할 수 있습니다.

4. 구독 설정: 가져오기, 선택, 업데이트와 오버라이드

가져오기는 설정을 확보하는 단계일 뿐입니다

구독 주소는 일반적으로 클라이언트가 읽을 수 있는 설정이나 노드 모음을 반환합니다. 가져올 때는 클라이언트의 설정, 구독 또는 Profiles 화면에서 “URL에서 가져오기”를 선택하고 출처가 명확한 주소를 붙여 넣은 뒤 다운로드와 분석이 끝날 때까지 기다리세요. 가져오기에 성공한 뒤에는 해당 설정을 현재 사용 설정으로 지정하고 정책 그룹에 선택 가능한 항목이 있는지 확인해야 합니다. 설정 목록에 이름이 표시되지만 전환 후 코어 오류가 발생한다면 “다운로드 성공”을 “실행 가능한 설정”으로 간주하지 말고 분석 로그에서 구체적인 필드를 확인하세요.

구독 주소에는 접근 권한이 포함될 수 있으므로 민감한 정보로 취급해야 합니다. 공개 스크린샷, 로그 공유 사이트나 질문 게시판에 올리지 마세요. 문제를 점검할 때는 주소와 노드 자격 증명을 가리고 오류 필드, 규칙 구조와 관련 로그만 남길 수 있습니다. 주소가 만료되었거나 로그인 페이지를 반환하거나 네트워크 리디렉션이 발생하면 클라이언트가 YAML 분석 오류를 보고할 수 있습니다. 이때는 파싱에 실패한 응답 내용을 임의로 수정하지 말고 서비스 제공자의 관리 화면에서 구독 상태를 먼저 확인하세요.

완전한 설정의 주요 구조 이해하기

일반적인 설정에는 수신 포트, 실행 모드, DNS, 노드, 정책 그룹과 규칙이 포함됩니다. 다음 예시는 최소 구조의 관계를 보여 주며 서버 주소와 인증 정보는 예시일 뿐 실제 연결에 사용할 수 없습니다:

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

proxies:
  - name: Example-Node
    type: socks5
    server: 192.0.2.10
    port: 1080
    username: demo-user
    password: "your-password"

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - Example-Node
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,PROXY

mixed-port는 일반적인 HTTP와 SOCKS 프록시 요청을 모두 수신합니다. mode: rule은 규칙에 따라 평가한다는 뜻입니다. proxy-groups는 PROXY라는 정책 그룹을 정의하고, 마지막 MATCH 규칙은 앞에서 일치하지 않은 트래픽을 받습니다. 여기서 PROXY는 코어가 자동으로 만드는 출구가 아닙니다. 정책 그룹을 삭제하고 MATCH만 남기면 참조 오류가 발생합니다. no-resolve는 해당 IP 규칙을 처리할 때 매칭을 위해 도메인을 능동적으로 해석하지 않는다는 의미이며 전체 DNS를 끈다는 뜻은 아닙니다.

구독 업데이트 전에 원격 내용과 로컬 수정을 구분하세요

구독으로 생성된 설정을 직접 편집하면 보통 일시적으로만 적용됩니다. 다음 업데이트에서 클라이언트가 원격 내용으로 로컬 사본을 덮어쓰므로 직접 추가한 규칙, DNS 또는 정책 그룹 항목이 사라질 수 있습니다. 오래 유지할 수정은 클라이언트가 제공하는 오버라이드, 병합 또는 스크립트 기능을 우선 사용하세요. 안정적인 오버라이드 기능이 없다면 수정한 설정을 별도의 로컬 파일로 저장하고 구독 업데이트를 자동으로 따라가지 않는 관리 비용을 감수해야 합니다.

업데이트 전에 현재 사용 가능한 설정, 정책 그룹 선택과 주요 오버라이드를 기록하세요. 업데이트가 끝나면 먼저 설정을 분석할 수 있는지 확인하고, 노드 목록과 정책 그룹 참조를 점검한 뒤 트래픽 인계를 복구합니다. 연결이 불안정할 때 여러 번 연속으로 업데이트하지 마세요. 서버 응답, 네트워크 캐시와 클라이언트의 파일 쓰기가 동시에 바뀌어 어느 업데이트가 오류를 만들었는지 알기 어려워질 수 있습니다. 구독 갱신 주기도 근거 없이 짧게 설정하지 말고 서비스 제공자가 허용하는 적절한 간격을 사용하세요.

현상 우선 확인할 항목 다음 단계
구독을 다운로드할 수 없음 주소 상태, 네트워크 경로, 시스템 시간 서비스 진입점과 클라이언트 로그의 HTTP 상태 확인
다운로드 후 분석 실패 반환 내용이 YAML인지, 필드 들여쓰기 확인 첫 번째 분석 오류 행을 찾고 여러 곳을 동시에 수정하지 않기
선택 가능한 정책이 없음 정책 그룹과 노드 참조 구독이 노드 모음만 반환하는지 확인
업데이트 후 사용자 지정 규칙이 사라짐 수정 내용이 구독 사본에 직접 기록되었는지 확인 오버라이드 또는 독립 로컬 설정으로 이전

설정 검증은 세 단계로 나눠야 합니다

구문 검증은 YAML을 분석할 수 있다는 것만 의미합니다. 참조 검증에서는 정책 그룹, 노드와 규칙 대상이 모두 존재하는지 확인해야 하며, 실행 검증에서는 포트, DNS, 권한과 원격 연결을 점검합니다. 클라이언트가 “설정이 유효함”이라고 표시한 뒤에도 접속되지 않는 것은 모순이 아닙니다. 앞의 두 단계만 완료했을 수 있기 때문입니다. 수정 사항을 저장한 뒤 설정을 다시 불러오고 첫 번째 로그 구간을 읽어 가장 먼저 발생한 오류부터 처리하세요. 구독 가져오기의 일반적인 문제는 도움말 센터에서 “설치 및 설정” 분류로 더 찾아볼 수 있습니다.

5. 프록시 모드: 규칙, 글로벌과 직접 연결의 범위

모드는 코어가 목적지를 선택하는 방식을 결정합니다

규칙 모드, 글로벌 모드와 직접 연결 모드는 프록시 경로에 들어온 트래픽을 코어가 처리하는 방식이며, 시스템 프록시·TUN·VPN 스위치와 같은 개념이 아닙니다. 시스템 프록시와 TUN은 어떤 트래픽이 코어에 들어올 기회를 얻는지 결정하고, 실행 모드는 그 트래픽이 어느 출구를 사용할지 결정합니다. 모드를 글로벌로 바꾼다고 시스템 프록시를 전혀 읽지 않는 프로그램이 자동으로 코어에 들어오는 것은 아닙니다. 마찬가지로 TUN을 켠 뒤 직접 연결 모드를 선택하면 트래픽이 가상 인터페이스와 코어의 판단을 거치더라도 최종적으로 로컬 네트워크에 직접 연결될 수 있습니다.

규칙 모드는 일반적인 일상 사용에 적합합니다. 코어는 규칙 목록을 위에서 아래로 확인하며 대상 도메인, IP, 포트 또는 규칙 세트를 기준으로 첫 번째 일치 항목에서 평가를 멈춥니다. 규칙은 DIRECT, REJECT 또는 사용자 지정 정책 그룹을 가리킬 수 있습니다. 규칙의 품질은 결과에 직접 영향을 줍니다. 너무 넓은 규칙을 앞에 두면 뒤의 세밀한 규칙이 가려질 수 있고, 마지막 보완 규칙이 없으면 설정마다 동작을 예측하기 어려워질 수 있습니다.

글로벌 모드는 규칙이 접속 문제를 일으키는지 임시로 확인하거나 명확하게 하나의 출구를 사용해야 하는 짧은 상황에 적합합니다. 글로벌 모드로 전환하면 클라이언트에서 글로벌 정책 그룹이나 노드를 선택하라고 요구하는 경우가 많습니다. 글로벌 모드에서는 작동하지만 규칙 모드에서 실패한다면 노드 자체가 고장 났다고 바로 판단하지 말고 대상이 어떤 규칙에 매칭되었는지, 정책 그룹을 사용할 수 있는지 확인하세요. 글로벌 모드를 오래 사용하면 원래 의도한 분기가 무시되고 로컬 네트워크나 직접 연결해야 할 리소스가 잘못된 출구로 나갈 수 있습니다.

직접 연결 모드는 로컬 네트워크를 빠르게 복구하거나 프록시 사용 전후 결과를 비교하거나, 클라이언트는 실행한 채 프록시 전달만 잠시 중지할 때 사용할 수 있습니다. 클라이언트 종료를 대신하지는 않습니다. 시스템 프록시는 여전히 로컬 포트를 가리킬 수 있고 TUN도 인터페이스와 라우팅을 유지할 수 있으며, 단지 코어가 DIRECT를 선택할 뿐입니다. 유지 관리나 삭제 전에는 직접 연결로 전환하는 데 그치지 말고 트래픽 인계를 끄고 코어를 종료하세요.

모드와 트래픽 인계 방식은 서로 독립된 두 가지 기준입니다
모드 핵심 동작 적용 상황 흔한 오해
Rule 규칙을 순서대로 매칭하고 출구 선택 지속적인 분기와 대상별 처리 규칙 모드가 모든 앱을 자동으로 인계하지는 않음
Global 글로벌 정책 선택으로 일괄 전달 짧은 시간 동안 하나의 출구 사용 또는 규칙 장애 비교 글로벌 모드는 TUN과 같지 않음
Direct 인계된 트래픽을 우선 직접 연결 네트워크 복구와 비교 테스트 직접 연결 모드는 클라이언트 완전 종료와 같지 않음

시스템 프록시는 프록시 설정을 따르는 앱에 적합합니다

시스템 프록시를 켜면 클라이언트는 일반적으로 운영체제의 프록시 주소를 루프백 주소와 로컬 포트로 설정합니다. 예를 들면 127.0.0.1:7890과 같습니다. 브라우저와 일부 데스크톱 앱은 이 설정을 읽지만 터미널 프로그램은 별도로 환경 변수를 설정해야 하는 경우가 많습니다. 어떤 앱은 자체 프록시 옵션으로 시스템 설정을 덮어쓸 수 있고, 일부 프로그램은 원시 네트워크 연결을 사용해 시스템 프록시를 완전히 무시합니다. 따라서 “브라우저는 되지만 터미널은 실패”한다면 먼저 터미널 환경을 확인해야 하며 규칙 모드를 바꿀 문제가 아닙니다.

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7890

curl -I https://example.com

포트는 클라이언트가 현재 수신 대기 중인 포트와 일치해야 합니다. 테스트할 때는 현재 터미널 세션에만 변수를 설정하고 결과를 확인한 뒤 셸 설정 파일에 기록할지 결정하세요. sudo, 컨테이너 또는 원격 세션에서는 환경 변수가 자동으로 상속되지 않을 수 있습니다. 컨테이너 내부의 루프백 주소는 보통 컨테이너 자체를 가리키므로 호스트 주소를 그대로 사용해서는 안 됩니다.

비교 실험으로 문제가 발생한 계층을 확인하세요

신뢰할 수 있는 모드 테스트는 노드와 인계 방식을 그대로 유지하고 한 번에 변수 하나만 바꿔야 합니다. 먼저 규칙 모드에서 대상에 매칭된 규칙을 기록한 다음 글로벌 모드로 전환하고 동일한 실제 출구를 선택하세요. 둘 다 실패한다면 로컬 포트, DNS, 노드 연결과 시스템 시간을 확인합니다. 규칙 모드에서만 실패한다면 규칙 순서와 정책 그룹을 확인하고, 브라우저는 되지만 터미널이 실패한다면 애플리케이션 프록시 설정을 확인하세요. 계층별 점검 방법은 브라우저와 터미널 프록시 문제 해결을 참고하세요.

6. 규칙 분기: 위에서 아래로 매칭과 정책 그룹 이해하기

첫 번째로 매칭된 규칙이 결과를 결정합니다

규칙 분기의 핵심은 규칙 수가 아니라 순서, 매칭 조건과 대상 정책의 일치 여부입니다. 코어는 목록의 맨 위부터 확인하며 요청이 한 규칙에 매칭되면 보통 다음 평가를 진행하지 않습니다. 앞쪽에 범위가 넓은 도메인 접미사 규칙을 두면 뒤에 있는 특정 하위 도메인 규칙이 가려질 수 있습니다. 넓은 IP 규칙도 원래 다른 정책 그룹으로 보내려던 주소를 먼저 처리할 수 있습니다. 따라서 사용자 지정 규칙은 구체적인 항목부터 넓은 항목 순서로 배치하고, 마지막에는 MATCH 또는 이에 준하는 보완 규칙으로 미매칭 트래픽을 처리해야 합니다.

rules:
  - DOMAIN,blocked.example,REJECT
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,PROXY

DOMAIN은 전체 도메인 이름과 매칭되므로 단일 호스트에 적합하고, DOMAIN-SUFFIX는 지정된 도메인과 하위 도메인에 매칭됩니다. IP-CIDR은 주소 범위로 매칭하며 MATCH는 보완 규칙입니다. 위 예시는 지정된 도메인을 먼저 거부한 뒤 example.org와 하위 도메인을 직접 연결하고, 사설 주소 범위도 직접 연결하며, 나머지 요청은 PROXY로 보냅니다. PROXY는 이미 정의된 정책 그룹 이름이어야 합니다. 실제 설정에서 “노드 선택” 같은 다른 이름을 사용한다면 규칙 대상도 정확히 같은 이름이어야 합니다.

정책 그룹은 규칙 결과를 선택 가능한 출구로 바꿉니다

규칙은 일반적으로 하나의 고정 노드에 직접 연결하지 않고 정책 그룹을 가리킵니다. select 그룹은 사용자가 직접 선택하게 하며, 다른 그룹 유형은 사용 가능 여부나 미리 정해진 로직에 따라 구성원을 선택할 수 있습니다. 지원 범위는 코어에 따라 다릅니다. 정책 그룹에는 노드, DIRECT 또는 다른 정책 그룹을 넣을 수 있지만 중첩 관계는 명확하게 유지해야 하며 여러 그룹이 서로를 참조하지 않도록 해야 합니다. 그룹 이름을 바꿀 때는 모든 규칙과 다른 정책 그룹의 참조도 함께 확인하세요.

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - Example-Node
      - DIRECT

  - name: AUTO
    type: url-test
    proxies:
      - Example-Node
      - Backup-Node
    url: https://www.gstatic.com/generate_204
    interval: 300

이 예시는 구조 관계를 설명하기 위한 것이며 모든 구독에 같은 노드가 포함된다는 뜻은 아닙니다. url-test는 지정된 URL로 사용 가능성을 테스트합니다. 테스트 결과는 해당 탐색 대상과 당시 네트워크 조건만 반영하며 실제 업무 대상의 검증을 대신하지 않습니다. 테스트 간격이 너무 짧으면 연결과 로그 오버헤드가 커집니다. 중요한 접속에는 동작을 이해하기 쉬운 정책 그룹을 우선 선택하고 문제가 발생했을 때 현재 그룹이 최종적으로 어떤 구성원을 선택했는지 확인하세요.

도메인 규칙과 IP 규칙은 DNS 경로의 영향을 받습니다

도메인 요청이 코어에 들어오면 DOMAIN 계열 규칙에 바로 참여할 수 있습니다. 애플리케이션이 대상 IP만 제출하거나 규칙이 IP 기준 판단을 요구하는 경우에는 DNS 분석과 연결 단계에서 얻은 주소 정보가 매칭에 영향을 줍니다. no-resolve는 IP 규칙이 매칭을 위해 도메인 분석을 능동적으로 실행하지 않도록 합니다. 불필요한 DNS 조회를 줄이는 데 도움이 되지만 설정의 DNS 서비스를 끄지는 않습니다. fake-ip, 도메인 스니핑 또는 복잡한 DNS 분기를 함께 사용한다면 규칙을 추가하기 전에 클라이언트가 생성한 전체 설정을 먼저 이해하세요.

라우터, 프린터 또는 로컬 서비스에 접근할 때 원격 출구로 보내지 않도록 LAN 주소는 일반적으로 넓은 프록시 규칙보다 먼저 처리해야 합니다. 흔한 사설 주소 범위에는 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16이 있지만 기업 네트워크에서는 더 많은 내부 도메인과 주소 범위를 사용할 수 있습니다. 공개 규칙 세트를 기계적으로 복사한 뒤 현재 네트워크에 맞는다고 가정하지 말고 실제 내부망 범위를 기준으로 보완하고 테스트하세요.

원격 규칙 세트와 로컬 규칙은 각각 관리 비용이 있습니다

원격 규칙 세트는 중앙에서 업데이트하기 편하지만 다운로드 주소, 형식과 업데이트 정책에 의존합니다. 로컬 규칙은 감사하기 쉽지만 직접 관리해야 합니다. 원격 규칙 세트를 사용할 때는 처리하는 범주, 기본 출구와 업데이트 실패 시 동작을 확인하세요. 로컬 규칙을 사용할 때는 각 그룹의 목적을 명확히 적고 중복 항목이 쌓이지 않게 해야 합니다. 규칙이 많다고 분기가 정확해지는 것은 아닙니다. 오래된 도메인, 겹치는 범위와 도달할 수 없는 규칙은 문제 해결 비용만 높입니다.

규칙을 안전하게 조정하는 순서는 다음과 같습니다. 현재 설정을 복사하고, 구체적인 규칙 하나를 추가한 뒤, 다시 불러와 대상과 영향받지 않아야 할 다른 대상을 함께 테스트합니다. 문제가 없다고 확인한 뒤 다음 작업으로 넘어가세요. 구독 업데이트가 규칙을 덮어쓴다면 클라이언트의 오버라이드 계층으로 옮기고 원격 규칙보다 앞에 둘지 뒤에 둘지도 기록해야 합니다.

7. TUN 모드: 인계 범위, DNS와 라우팅 점검

TUN은 트래픽을 코어로 진입시키는 문제를 해결합니다

TUN 모드는 가상 네트워크 인터페이스와 시스템 라우팅을 통해 더 많은 IP 트래픽을 인계합니다. 시스템 프록시를 읽지 않는 앱, 일부 명령줄 도구와 일괄 인계가 필요한 환경에 적합합니다. 노드 자체의 연결 품질을 높이거나 규칙과 정책 그룹을 대신하지는 않습니다. 트래픽이 TUN에 들어온 뒤에도 DNS 분석, 라우팅 판단, 규칙 평가와 출구 연결을 거칩니다. 규칙이 DIRECT를 가리키면 최종적으로 직접 연결될 수 있으며, 설정이나 권한에 오류가 있으면 시스템 프록시보다 영향 범위가 넓을 수 있습니다.

처음 켜기 전에는 먼저 시스템 프록시 모드에서 구독, 노드와 규칙이 기본적으로 작동하는지 확인하세요. 그다음 다른 VPN, 프록시 또는 네트워크 필터링 도구를 끄고 현재 DNS와 기본 라우팅을 기록합니다. 클라이언트에서 서비스 설치, VPN 설정 권한 또는 네트워크 확장 활성화를 요구할 수 있으므로 공식 화면에서 처리하세요. 활성화한 뒤에는 LAN 주소, 자주 쓰는 도메인과 시스템 프록시를 사용하지 않는 프로그램을 먼저 테스트합니다. 세 경로가 예상대로 작동하는지 확인한 뒤 시작 시 실행이나 상시 활성화를 고려하세요.

일반적인 설정 필드의 역할

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

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

auto-route는 코어가 필요한 라우팅을 기록하도록 시도하고, auto-detect-interface는 현재 아웃바운드 인터페이스를 식별하는 데 사용되며, dns-hijack는 지정된 DNS 트래픽을 가로채도록 지시합니다. stack에서 사용할 수 있는 값과 동작은 코어와 플랫폼의 영향을 받으므로 현재 클라이언트 문서 없이 무작정 바꾸지 마세요. 예시의 공용 DNS는 필드 구조를 설명하기 위한 것일 뿐이며 실제 선택은 네트워크 도달성, 개인정보 요구와 구독 설정을 함께 고려해야 합니다. 구독에서 이미 완전한 DNS 구성을 제공한다면 검증되지 않은 오버라이드 세트를 동시에 추가하지 마세요.

fake-ip는 도메인에 예약 범위의 매핑 주소를 반환한 뒤 코어가 도메인을 복원하고 규칙을 적용하도록 합니다. 도메인 정보를 유지하는 데 도움이 되지만 일부 LAN 서비스, 실제 주소가 필요한 애플리케이션 또는 특수 프로토콜은 필터 범위에 추가해야 할 수 있습니다. LAN 기기를 찾을 수 없거나 앱이 비정상 주소를 감지한다면 모든 DNS 기능을 즉시 끄기보다 fake-ip 필터와 LAN 직접 연결을 먼저 확인하세요.

노드 문제보다 라우팅 충돌이 더 흔합니다

기업 VPN, 가상 머신 네트워크, 컨테이너 네트워크 또는 다른 프록시를 동시에 실행하면 각 도구가 기본 라우팅, DNS 또는 가상 인터페이스를 서로 차지하려 할 수 있습니다. TUN을 켠 뒤 인터넷이 완전히 끊기거나, 내부망만 작동하지 않거나, 절전 모드에서 복귀한 뒤 연결되지 않거나, Wi-Fi를 전환해도 트래픽이 이전 인터페이스로 흐르는 현상이 나타날 수 있습니다. 점검할 때는 먼저 다른 인계 도구를 끄고 TUN을 끈 뒤 기본 네트워크가 복구되는지 확인하고 Clash만 단독으로 켜세요. 단독 실행이 정상이라면 다른 도구를 하나씩 다시 켜면서 충돌이 발생하는 시점을 관찰합니다.

Windows에서는 라우팅 테이블과 네트워크 어댑터를 확인할 수 있고, macOS에서는 네트워크 서비스와 VPN 설정을 점검할 수 있으며, Linux에서는 시스템 명령으로 라우팅과 규칙을 확인할 수 있습니다. 진단의 핵심은 모든 출력 내용을 복사하는 것이 아니라 활성화 전후의 기본 라우팅, DNS 방향과 새로 추가된 인터페이스를 비교하는 것입니다. Linux에서 자주 사용하는 점검 명령은 다음과 같습니다:

ip addr
ip route
ip rule
ss -lntup
resolvectl status

배포판에 따라 모든 명령이 제공되지 않을 수 있습니다. ss는 로컬 포트를 확인하고, ip route와 ip rule은 라우팅을 살펴보며, resolvectl은 systemd-resolved를 사용하는 환경에 적합합니다. 용도를 이해하지 못한 채 라우팅 규칙을 일괄 삭제하지 마세요. 먼저 클라이언트를 종료해 정리 작업을 수행하게 하고, 그다음 네트워크 서비스나 시스템을 재시작한 뒤 마지막으로 수동 복구를 고려하세요.

DNS 장애는 분석과 연결을 구분해야 합니다

IP로는 접속되지만 도메인으로는 접속되지 않는다면 먼저 DNS를 확인해야 합니다. 도메인이 해석되지만 연결이 실패한다면 규칙, 출구와 방화벽을 계속 확인하세요. nslookup, dig 또는 시스템 내장 분석 도구를 사용해 시스템 분석 결과와 클라이언트 로그를 비교할 수 있습니다. 로그에 대상 요청이 전혀 나타나지 않는다면 애플리케이션, 시스템 라우팅 또는 DNS가 코어에 도달하기 전 단계에서 문제가 발생했을 수 있습니다. 요청은 보이지만 정책이 잘못되었다면 규칙과 DNS 설정으로 돌아가 확인하세요.

TUN이 안정적으로 작동하는지 판단하려면 시작, 종료, 절전 복귀, 네트워크 전환과 LAN 접속을 모두 테스트해야 합니다. 웹페이지 한 번이 열린 것만으로 라우팅 정리와 DNS 복구가 정상이라고 증명할 수 없습니다. 모바일 기기에서는 백그라운드와 화면 잠금 동작을 테스트하고, 데스크톱에서는 클라이언트 종료 후 프록시와 라우팅이 남지 않는지 확인하세요.

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

클라이언트, 코어와 구독을 분리해 업데이트하세요

클라이언트 업데이트, 코어 업데이트와 구독 업데이트는 서로 다른 세 경로입니다. 클라이언트 업데이트는 인터페이스, 권한 보조 구성 요소와 설정 저장 방식을 바꿀 수 있습니다. 코어 업데이트는 지원 필드, 기본 동작과 프로토콜 기능을 바꿀 수 있습니다. 구독 업데이트는 노드, 정책 그룹과 규칙을 변경합니다. 일상적인 유지 관리에서는 어느 계층이 바뀌었는지 기록해야 하며, 같은 날 세 계층을 모두 업데이트해 회귀 원인을 찾기 어렵게 만들지 마세요. 안정적으로 사용 중이라면 설정을 먼저 백업하고 구독을 업데이트한 뒤 검증할 수 있습니다. 클라이언트나 코어를 업데이트할 때는 별도의 테스트 일정으로 진행하세요.

업데이트 전에 구독 주소, 현재 정책 선택, 로컬 오버라이드와 중요한 사용자 지정 규칙을 저장하세요. 구독이 생성한 YAML만 복사해서는 충분하지 않습니다. 클라이언트가 오버라이드, 정책 선택과 인터페이스 설정을 다른 파일이나 데이터베이스에 저장할 수 있기 때문입니다. 클라이언트가 제공하는 내보내기 기능을 우선 사용하세요. 내보내기 기능이 없다면 다시 만들 수 있는 정보를 항목별로 기록합니다. 백업은 클라이언트 데이터 디렉터리 외부에 보관해 삭제나 캐시 정리 때 함께 지워지지 않도록 하세요.

로그는 재현 가능한 한 번의 작업을 중심으로 읽어야 합니다

유효한 로그에는 명확한 시간 범위와 트리거 동작이 있어야 합니다. 먼저 로그 수준을 일반 정보 수준으로 설정하고 현재 시간을 기록하거나 로그를 비운 다음, 실패 동작을 한 번 수행하고 해당 구간을 즉시 확인하세요. 설정 로드, DNS 조회, 규칙 매칭, 정책 선택, 연결 수립과 시간 초과 메시지를 중점적으로 찾습니다. 디버그 수준을 장기간 켜 두면 기록이 지나치게 많아지고 대상 도메인 같은 사용 정보가 포함될 수 있으므로 문제를 해결하는 동안만 활성화하고 끝나면 복원하세요.

로그를 공유하기 전에 구독 주소, 인증 필드, 제어 인터페이스 자격 증명과 노드 연결 정보를 삭제하세요. 오류 유형, 대상 범주, 규칙 이름과 필요한 맥락만 남기면 됩니다. 마지막 한 줄만 잘라 공유하면 실제 원인을 놓치기 쉽습니다. 예를 들어 연결 실패가 앞에서 발생한 DNS 오류로 유발될 수 있습니다. 문제를 점검할 때는 로그에서 가장 많이 반복된 후속 오류보다 시간 순서상 처음 발생한 이상부터 처리하세요.

계층별 복구 순서를 세우세요

인터넷에 연결되지 않을 때는 먼저 기본 네트워크를 복구한 뒤 프록시를 복구하세요. TUN과 시스템 프록시를 끄고 직접 연결로 전환하거나 클라이언트를 완전히 종료한 다음 운영체제가 정상적으로 분석하고 접속하는지 확인합니다. 기본 네트워크가 복구되면 클라이언트를 시작하되 인계는 아직 켜지 말고 설정 로드와 로컬 포트를 확인하세요. 그다음 시스템 프록시를 켜 브라우저를 테스트하고 마지막에 TUN을 활성화합니다. 이 순서로 권한, 설정, 노드와 라우팅 문제를 분리할 수 있습니다.

특정 사이트나 앱만 실패한다면 먼저 재설치하지 마세요. 같은 대상을 직접 연결, 규칙과 글로벌 모드에서 비교하고 로그의 매칭 규칙을 확인한 뒤 앱에 별도의 프록시 설정이 있는지 점검하세요. 모든 노드가 동시에 실패한다면 구독 상태, 시스템 시간, DNS와 현재 네트워크 제한을 확인합니다. 하나의 노드만 실패한다면 같은 정책 그룹의 다른 구성원으로 바꾸고 문제 범위를 해당 출구로 좁히세요. 일반적인 질문은 도움말 센터에서 계속 확인할 수 있습니다.

실행 시점 권장 작업 검증 결과
구독 업데이트 후 분석, 정책 그룹, 규칙과 오버라이드 확인 자주 사용하는 대상이 기존 정책대로 접속됨
클라이언트 또는 코어 업데이트 후 변경 사항을 읽고 시스템 프록시와 TUN 테스트 시작, 종료와 네트워크 복구가 모두 정상
시스템 주요 버전 업데이트 후 권한, 네트워크 확장과 시작 시 실행 재확인 권한이 유효하고 라우팅이 올바르게 정리됨
기기 이전 전 구독 정보, 오버라이드와 사용자 지정 규칙 내보내기 새 기기에서 최소 설정으로 순환 구조를 다시 구축할 수 있음

설정을 정리할 때 되돌릴 지점을 남기세요

설정이 장기간 누적되면 중복 구독, 만료된 오버라이드와 오래된 규칙이 서로 영향을 줄 수 있습니다. 정리할 때는 먼저 현재 사용 가능한 설정을 복사하고 의심스러운 항목을 즉시 삭제하지 말고 비활성화하세요. 일정 기간 의존하는 곳이 없는지 확인한 뒤 제거합니다. 클라이언트 캐시, 설정 데이터베이스와 코어 디렉터리를 한꺼번에 삭제하지 마세요. 장애 증거와 되돌릴 상태를 동시에 잃을 수 있습니다. 반드시 초기화해야 한다면 필요한 내용을 먼저 내보낸 뒤 최소 설정부터 검증하세요.

보관된 클라이언트는 임시 패치를 계속 쌓기보다 이전하는 것이 핵심입니다. 현재 플랫폼을 지원하고 계속 관리되는 클라이언트를 선택해 기존 구독을 가져온 뒤 기본 연결을 확인하고 로컬 규칙과 TUN 설정을 옮기세요. 기존 클라이언트 디렉터리를 직접 덮어쓰거나 두 클라이언트가 동시에 시스템 프록시 또는 라우팅을 제어하게 하지 마세요. 이전이 끝나면 기존 클라이언트의 시작 시 실행을 끄고 시스템에 명확한 인계 경로 하나만 남았는지 확인하세요.

9. 고급 학습 경로: 사용할 줄 아는 단계에서 직접 진단하는 단계로

먼저 설정 읽기를 익히고 복잡한 오버라이드는 나중에 배우세요

고급 활용의 첫걸음은 더 많은 설정 조각을 모으는 것이 아니라 현재 적용 중인 설정을 읽는 능력입니다. 수신 포트, 실행 모드, DNS, 정책 그룹, 규칙과 TUN 항목을 찾고 요청이 어느 진입점으로 들어와 어떤 규칙에 매칭되며 어느 정책 그룹을 사용하고 최종적으로 어떤 출구를 선택하는지 설명할 수 있어야 합니다. 클라이언트 인터페이스가 일부 기본값을 숨긴다면 내보낸 설정이나 코어 로그를 확인할 수 있지만, 언제 덮어써지는지 확실히 알지 못한다면 프로그램이 자동 생성한 파일을 직접 편집하지 마세요.

두 번째 단계는 관리 가능한 오버라이드 계층을 만드는 것입니다. LAN 직접 연결, 특정 도메인 정책, DNS 예외와 정책 그룹 조정을 각각 독립적인 목적별로 나누고 한 번에 한 그룹만 추가하세요. 규칙 이름과 주석에는 임시 번호보다 이유를 적어야 합니다. 구독 업데이트 후 자동 병합되는 내용은 삽입 위치를 확인해야 합니다. 같은 규칙도 목록의 맨 앞과 맨 뒤에서 완전히 다른 결과를 낼 수 있기 때문입니다. 클라이언트가 YAML 병합을 지원한다면 배열이 추가되는지, 앞에 삽입되는지 또는 전체 교체되는지 확인하세요.

mihomo의 기능과 설정 호환 범위 이해하기

mihomo는 Clash 설정 생태계를 기반으로 프로토콜, DNS, 규칙과 실행 기능을 확장하지만 구체적인 필드는 현재 코어 빌드와 클라이언트 통합 방식의 영향을 받습니다. 기존 설정을 이전할 때는 먼저 대상 코어로 구문을 검사하고 사용 중단된 필드, 규칙 제공자, DNS 강화 모드와 정책 그룹 동작을 확인하세요. 파일 확장자가 같다는 이유만으로 설정을 바로 바꿔 쓸 수 있다고 판단하지 마세요. 관련 배경은 mihomo와 원본 Clash의 차이에서 확인할 수 있습니다.

서버와 라우터 배포에는 실행 사용자, 네트워크 네임스페이스, 방화벽 전달과 영구 라우팅도 관련됩니다. 데스크톱의 “TUN 켜기” 버튼은 권한과 라우팅 작업을 대신 처리하는 경우가 많지만, 순수 코어에서는 배포자가 이 작업을 직접 명확히 맡아야 합니다. 고급 배포 전에는 일반 사용자 공간에서 설정 로드, DNS와 프록시 포트를 먼저 검증한 뒤 투명 인계와 시작 서비스를 단계적으로 추가하세요. 설정 문제와 시스템 네트워크 문제를 한꺼번에 겹치지 않도록 해야 합니다.

대규모 시행착오 대신 최소 재현을 사용하세요

복잡한 문제가 발생하면 설정을 복사한 뒤 진입점 하나, 검증 가능한 노드 하나, 정책 그룹 하나와 소수의 규칙만 남기도록 줄이세요. 최소 설정이 실행되는 것을 확인한 뒤 DNS, 규칙 세트, TUN과 오버라이드를 단계별로 복원합니다. 각 단계를 복원할 때마다 설정 로드, 도메인 분석, 직접 연결 대상, 프록시 대상, LAN 대상과 종료 후 네트워크 복구를 고정 순서로 테스트하세요. 이렇게 하면 장애를 특정 설정 블록으로 좁힐 수 있습니다.

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

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - MATCH,PROXY

이 조각은 코어 구조와 로컬 수신만 검증하기 위한 것이며 사용할 수 있는 프록시 노드는 포함하지 않습니다. PROXY 그룹에 DIRECT만 들어 있으므로 모든 보완 트래픽은 최종적으로 직접 연결됩니다. 실제 구독 노드를 추가하기 전에 설정 로드, 포트 수신과 규칙 로그가 보이는지 확인한 뒤 노드를 단계적으로 추가하세요. 연결이 실패하더라도 YAML 구조나 로컬 포트가 원인이 아니라는 점을 확인할 수 있습니다.

고정된 진단 도구 모음을 마련하세요

데스크톱과 서버 모두 몇 가지 기본 도구를 익혀야 합니다. 수신 포트 확인, 도메인 분석, HTTP 요청 전송, 라우팅 점검, 프로세스 확인과 서비스 로그 읽기입니다. Windows에서는 시스템 네트워크 명령과 PowerShell을 사용할 수 있고, macOS와 Linux에서는 curl, dig 또는 nslookup, netstat 또는 ss를 사용할 수 있습니다. 도구의 가치는 모든 시스템 정보를 한 번에 내보내는 데 있지 않고 “7890 포트가 수신 중인가”, “도메인이 어느 주소로 분석되는가”, “요청이 프록시를 사용하는가” 같은 명확한 질문에 답하는 데 있습니다.

진단할 때는 각 테스트의 예상 결과를 적어 두세요. LAN 주소는 DIRECT로 접속되고 테스트 도메인은 특정 정책 그룹을 사용하며 클라이언트를 종료하면 시스템 프록시가 정리되는 것이 예상 결과일 수 있습니다. 실제 결과가 예상과 다를 때 해당 계층의 로그를 확인하세요. 예상이 없는 테스트는 “웹페이지가 열리면 정상”이라는 모호한 판단에 빠지기 쉽고, 직접 연결해야 할 트래픽이 잘못 프록시되는 문제도 발견하기 어렵습니다.

지속 가능한 학습 순서를 만드세요

이 설명서를 마친 뒤에는 “설정 구조—규칙 순서—DNS 경로—TUN 라우팅—서비스 배포” 순서로 더 깊이 학습할 수 있습니다. 각 단계마다 작동하는 기준 설정을 하나 남기고 실험 내용은 복사본에서 진행하세요. 먼저 단일 장치의 요청 경로를 이해한 다음 원격 규칙 세트, 복잡한 정책 그룹과 라우터 투명 프록시를 연구하고, 네트워크를 복구할 수 있게 된 뒤 시작 시 자동 인계를 활성화하세요.

문제가 특정 플랫폼 권한과 관련되면 설치 장으로 돌아가고, 특정 앱만 작동하지 않으면 프록시 모드 장으로 돌아가며, 대상이 잘못된 출구로 나가면 규칙 장으로 돌아가고, 활성화 후 전체 네트워크가 끊기면 TUN과 DNS 장으로 돌아가세요. 기본 연결만 다시 완료하려면 빠른 튜토리얼로 이동하고, 클라이언트를 바꾸거나 설치 파일을 다시 받으려면 클라이언트 다운로드 페이지를 사용하세요. 계층별로 되돌아가 확인하는 방식이 반복 재설치보다 증거를 보존하고 재현 가능한 결과를 얻기 쉽습니다.