Clash 사용 설명서: 핵심 개념부터 안정적인 라우팅까지

Clash 이해하기: 코어, 클라이언트 및 프록시 경로

설치를 시작하기 전에 혼동하기 쉬운 몇 가지 명칭부터 구분해야 합니다. Clash는 일반적으로 프록시 설정 형식의 한 종류를 가리키기도 하고, 해당 형식을 사용하는 클라이언트 생태계를 뜻하기도 합니다. 클라이언트는 그래픽 인터페이스를 제공하고 설정을 읽으며 시스템 기능을 호출합니다. 실제로 DNS 조회, 규칙 매칭 및 연결 전달을 수행하는 부분은 코어라고 합니다. 현재 널리 사용되는 오픈 소스 코어 계열은 Mihomo이며, Clash Meta의 설정 기능을 계승하고 확장했습니다. Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu 등은 클라이언트이므로 클라이언트 이름을 코어 이름으로 혼동해서는 안 됩니다. 다운로드 페이지에는 플랫폼별 클라이언트가 정리되어 있으니, 선택할 때는 먼저 운영체제를 확인한 다음 인터페이스와 기능 지원 범위를 살펴보세요.

일반적인 접속은 네 단계로 진행됩니다. 먼저 애플리케이션이 대상 도메인이나 IP 주소를 만들면, 클라이언트가 현재 설정에 따라 요청을 가로챌지 결정합니다. 이후 코어가 DNS를 처리하고 규칙 순서에 따라 처음 일치하는 항목을 찾습니다. 규칙은 요청을 특정 프록시 그룹, 직접 연결 정책 또는 거부 정책으로 전달합니다. 마지막으로 노드가 대상 서버와 연결을 수립합니다. 어느 한 단계에서 문제가 발생해도 ‘웹페이지가 열리지 않음’으로 보일 수 있지만, 해결 방법은 서로 다릅니다. 규칙 매칭이 잘못됐다면 노드를 바꿔도 소용없고, DNS가 잘못된 주소를 반환했다면 프록시 그룹만 바꿔서는 해결되지 않습니다. 시스템이 트래픽을 클라이언트로 전달하지 않는 경우에는 설정 자체가 정상일 수도 있습니다.

설정 파일과 실행 상태는 서로 다릅니다

YAML 설정 파일에는 포트, 프록시 노드, 프록시 그룹, 규칙, DNS 등의 선언적 내용이 저장됩니다. 클라이언트가 시작되면 이 내용을 메모리에 불러온 뒤 현재 모드, 네트워크 인터페이스 및 실행 권한에 따라 상태를 구성합니다. 파일을 수정하고 다시 불러오지 않으면 인터페이스에서는 여전히 이전 설정을 사용할 수 있습니다. 반대로 인터페이스에서 노드를 임시로 전환해도 원본 구독이 수정되는 것은 아닙니다. 이 차이를 이해하면 문제가 ‘파일이 업데이트되지 않은 것’인지, ‘실행 상태에 적용되지 않은 것’인지 판단하기 쉬워집니다. 설정 다시 불러오기, 구독 업데이트, 클라이언트 재시작은 서로 다른 동작이며 뒤에서 각각 설명합니다.

요청부터 노드까지의 전체 경로

브라우저로 도메인에 접속하는 경우를 예로 들어 보겠습니다. 브라우저가 먼저 운영체제에 연결을 요청하면 시스템 프록시 설정 또는 TUN 인터페이스가 트래픽을 Clash로 보낼지 결정합니다. 코어는 요청을 받은 뒤 DNS 모드에 따라 대상 주소를 확인하고 rules를 위에서부터 검색합니다. DOMAIN-SUFFIX가 일치하면 요청을 지정된 정책 그룹으로 전달합니다. 정책 그룹은 수동 선택, 장애 조치 또는 URL Test 결과에 따라 프록시 노드를 선택합니다. 노드 프로토콜의 핸드셰이크가 완료된 후에야 대상 요청이 전송됩니다. 경로에서 표시되는 ‘지연 시간’은 테스트 주소의 TCP 연결 수립 시간만 의미할 수 있으며, 웹페이지 전체 로딩 시간과는 다릅니다. 속도 측정 지표의 차이는 Clash 지연 시간 테스트 원리에서 확인할 수 있습니다.

‘프록시 클라이언트’와 ‘프록시 서비스’도 구분해야 합니다. 클라이언트는 로컬 설정을 실행하고, 구독 서비스는 노드 정보와 트래픽 서비스를 제공합니다. 두 업체는 같은 조직이 아니며 계정을 공유하지도 않습니다. 구독 주소는 반드시 서비스 제공업체에서 받아야 합니다. 웹사이트의 클라이언트 링크는 프로그램 다운로드를 위한 것이며 노드를 생성하거나 구독을 제공하지 않습니다. 개념을 구분했다면 2장에서 운영체제와 사용 목적에 맞는 클라이언트를 선택하세요.

클라이언트 선택: 시스템 기능과 사용 목적을 기준으로 판단하기

클라이언트는 이름이나 스크린샷만 보고 선택해서는 안 됩니다. 필요한 연결 방식이 운영체제에서 지원되는지, 구독과 규칙을 인터페이스에서 처리할 수 있는지, 코어 버전이 필요한 프로토콜과 DNS 기능을 지원하는지 세 가지를 확인해야 합니다. 일반적인 데스크톱 사용자는 트레이 실행, 시스템 프록시, 설정 다시 불러오기 및 로그 확인 기능이 필요합니다. 모바일에서는 백그라운드 제한, 배터리 정책 및 시스템 VPN 권한도 고려해야 합니다. 서버나 소프트 라우터 사용자는 명령줄 실행, 설정 파일 위치 및 프로세스 관리 기능을 더 중요하게 봅니다. 다운로드 페이지에서는 각 플랫폼의 첫 번째 항목에 Clash Plus를 배치했으며 그래픽 인터페이스 입문용으로 적합하지만, 클라이언트마다 메뉴 이름은 다를 수 있습니다.

Windows와 macOS 선택 기준

Windows 사용자는 Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu를 우선 확인할 수 있습니다. 전통적인 데스크톱 제어와 간결한 옵션을 원한다면 읽기 쉬운 인터페이스의 클라이언트를 선택하세요. Mihomo 옵션, TUN 또는 규칙 디버깅이 더 필요하다면 코어 로그와 전체 설정 영역을 표시하는 클라이언트가 적합합니다. Clash for Windows는 유지 관리가 중단되어 새로 설치할 기본 선택으로 적합하지 않습니다. 기존 설정은 이전할 수 있지만, 이전 전에 구독 주소와 사용자 지정 규칙을 저장해야 합니다. macOS에서는 Clash Plus, Clash Verge Rev, FlClash 및 ClashX Meta를 선택할 수 있습니다. ClashX Meta는 유지 관리가 중단되었으므로 기존 설정을 읽는 용도로만 보관하고 새 환경의 기본 클라이언트로 사용하는 것은 권장하지 않습니다.

Android와 iOS의 제약 사항

Android 클라이언트는 시스템 VPN 또는 VpnService를 통해 트래픽을 가로채야 하며, 처음 실행할 때 시스템 권한 요청이 표시됩니다. Clash Plus, Clash Meta for Android, FlClash 및 Surfboard는 설정 위치가 서로 다르지만 VPN 스위치가 실행 상태인지 확인해야 합니다. Android의 배터리 절약 정책이 백그라운드 프로세스를 중지하면 화면을 잠근 뒤 연결이 끊길 수 있습니다. 이 경우 클라이언트를 시스템 배터리 최적화 예외에 추가하고 백그라운드 데이터 권한도 확인하세요. Android에서는 알림 권한, 항상 켜짐 VPN 옵션 및 로컬 네트워크 접근 권한도 중요합니다. 자세한 내용은 Android VpnService 및 배터리 절약 설정을 참고하세요.

iOS의 시스템 프록시 권한은 VPN 구성 승인에 집중되어 있으며, 클라이언트 설치와 설정 가져오기도 시스템 인터페이스의 제어를 받습니다. 다운로드 페이지에서는 Clash Plus의 App Store 링크를 제공하고 공식 웹사이트 clashplus.io를 표시합니다. 처음 실행할 때는 먼저 설정을 가져온 다음 시스템에서 VPN 구성 추가를 허용하고, 마지막으로 클라이언트에서 연결을 시작하세요. iOS의 백그라운드 동작, 주문형 연결 및 네트워크 전환 정책에는 시스템이 관여하므로 셀룰러 네트워크와 Wi-Fi에서 동작이 다르면 각각 테스트해야 합니다.

Linux와 Mihomo 코어

Linux 데스크톱 사용자는 Clash Verge Rev 또는 FlClash부터 시작할 수 있습니다. 서버, 라우터 및 데스크톱 환경이 없는 장치에는 Mihomo를 직접 실행하는 방식이 더 적합합니다. 코어 패키지는 실행 파일이나 압축 파일만 제공하며 systemd 서비스를 자동으로 만들거나 설정을 작성하고 포트를 열어 주지 않습니다. 설치 후에는 아키텍처, 파일 권한, 설정 디렉터리 및 리스닝 주소를 직접 확인해야 합니다. 관리 패널을 공용 인터넷에 노출하면 위험이 커지므로 일반적으로 로컬 주소에만 바인딩하고 SSH 터널이나 로컬 네트워크로 관리하는 것이 좋습니다.

선택을 마친 뒤 여러 클라이언트를 동시에 설치하고 모두 시스템 프록시를 켜 두지 마세요. 여러 프로그램이 같은 포트를 경쟁하거나 시스템 프록시를 반복해서 덮어쓰면 상태를 파악하기 어려워집니다. 처음 설정할 때는 실행 중인 클라이언트를 하나만 남기고 연결, 규칙 및 DNS가 정상인지 확인한 다음 다른 프로그램으로 이전하는 것이 좋습니다.

설치 및 초기 설정: 되돌릴 수 있는 환경부터 만들기

설치 전에 운영체제 버전, CPU 아키텍처 및 다른 VPN이나 프록시 도구의 실행 여부를 기록하세요. 데스크톱에서는 현재 계정에 설치 권한이 있는지 확인하고, 모바일에서는 시스템 VPN 승인을 준비해야 합니다. 클라이언트 페이지에서 플랫폼을 선택한 뒤 카드의 안내에 따라 설치 패키지를 고르세요. 처음부터 TUN을 켜거나 DNS를 수정하지 말고, 최소 권한으로 일반 시스템 프록시 연결을 한 번 완료하세요. 이후 기능을 하나씩 추가하면 문제 범위를 명확하게 좁힐 수 있습니다.

데스크톱 초기 설정 순서

설치가 끝나면 클라이언트를 실행하고 설정, Profiles, 구독과 같은 이름의 영역을 먼저 찾으세요. 구독이 없다면 프로그램이 정상적으로 열리는지, 코어가 시작되는지, 로그 영역에 시작 메시지가 있는지만 확인하세요. 테스트를 위해 출처가 불분명한 주소를 입력해서는 안 됩니다. 설정을 가져온 뒤 프록시 그룹에 노드가 표시되는지, 규칙 영역에 규칙 수나 규칙 파일이 로드되는지 확인합니다. 그런 다음 설정에서 혼합 포트, HTTP 포트, SOCKS 포트 및 외부 제어 주소를 기록하세요. 클라이언트마다 기본 포트가 다를 수 있으므로 다른 프로그램의 포트를 그대로 사용하면 안 됩니다.

시스템 프록시는 일반적으로 시스템 프록시 설정을 따르는 애플리케이션에만 영향을 줍니다. 브라우저, 명령줄 도구 및 일부 데스크톱 프로그램은 HTTP, HTTPS 또는 SOCKS 설정 중 하나만 읽거나 시스템 프록시를 완전히 무시할 수 있습니다. 시스템 프록시를 켠 뒤 먼저 브라우저로 확인 가능한 사이트에 접속하고, 그다음 명령줄에서 테스트하세요. 브라우저는 되지만 명령줄이 안 된다면 즉시 TUN을 켜기보다 명령줄에 별도의 환경 변수가 필요한지 먼저 확인해야 합니다.

모바일 초기 설정 순서

Android를 처음 실행하면 클라이언트가 VPN 연결을 요청합니다. 시스템 팝업의 애플리케이션 이름이 현재 설치한 클라이언트와 일치하는지 확인하세요. 승인한 뒤 클라이언트로 돌아와 상태가 중지에서 실행으로 바뀌었는지 확인하고, 알림 영역에 VPN 표시가 나타나는지 살펴보세요. iOS에서는 클라이언트가 VPN 구성을 추가하도록 허용해야 하며, 승인되면 시스템 설정의 VPN 상태가 바뀝니다. 시스템에서 이미 VPN을 사용 중이라고 표시되면 먼저 다른 VPN을 끈 다음 다시 승인하여 두 네트워크 확장이 동시에 실행되지 않도록 하세요.

Linux에서 Mihomo 코어를 최소한으로 실행하기

Linux에서 Mihomo를 직접 실행할 때는 먼저 설정 파일을 명확한 디렉터리에 배치하고 포그라운드로 실행해 로그를 확인하세요. 설정이 정상적으로 읽히고 포트가 올바르게 리스닝되는 것을 확인한 뒤 systemd나 다른 프로세스 관리자로 넘기면 됩니다. 아래 명령은 일반적인 실행 방식만 보여 주므로 경로를 실제 파일 위치로 바꿔야 합니다:

mkdir -p "$HOME/.config/mihomo"
cp config.yaml "$HOME/.config/mihomo/"
mihomo -d "$HOME/.config/mihomo"

시작 로그에서는 설정 파싱, DNS 초기화, 프록시 그룹 로드 및 포트 리스닝을 중점적으로 확인하세요. YAML 들여쓰기가 잘못되면 코어는 보통 시작 단계에서 즉시 오류를 출력합니다. 설정은 로드되지만 노드를 사용할 수 없는 경우에는 실제 연결이나 상태 점검 단계에서 오류가 나타납니다. 두 종류의 로그를 혼동하지 마세요. 포그라운드 실행이 안정적인 것을 확인한 뒤 서비스 파일을 설정하고, 서비스에 고정된 작업 디렉터리와 사용자 권한을 지정하세요.

설정 파일의 기본 구조

다음 조각은 읽기 쉬운 최소 구조를 보여 줍니다. 노드 내용과 구독 서비스가 제공하는 필드는 실제 설정을 기준으로 해야 하며, 예시의 이름은 참조 관계를 설명하기 위한 것입니다:

mixed-port: 7890
mode: rule
allow-lan: false

proxies:
  - name: "예시 노드"
    type: ss
    server: example.net
    port: 443
    cipher: aes-128-gcm
    password: "your-password"

proxy-groups:
  - name: "PROXY"
    type: select
    proxies:
      - "예시 노드"
      - DIRECT

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

이 설정의 비밀번호는 예시 값이므로 연결에 직접 사용할 수 없습니다. 실제 설정에는 TLS, UDP, 포트 다중화 및 특정 프로토콜 필드가 추가될 수 있습니다. 구독 내용, 비밀번호 또는 관리 키를 공개 저장소에 게시하지 말고, 스크린샷에도 전체 구독 주소가 노출되지 않도록 하세요. 설치를 마치면 다음 장에서 실제 구독으로 예시 설정을 교체하세요.

구독 및 노드: 설정을 업데이트하고 프록시 그룹의 출처 이해하기

구독은 일반적으로 서비스 제공업체가 생성한 URL이며, 클라이언트가 접속하면 노드와 규칙 설정을 가져옵니다. 구독 업데이트는 ‘특정 노드 테스트’가 아니라 설정을 다시 다운로드하고 파싱하는 작업입니다. 업데이트가 성공해야 새 노드, 만료된 노드 또는 새로운 프록시 그룹이 클라이언트에 표시될 수 있습니다. 구독을 가져올 때는 서비스 제공업체가 제공한 원본 주소를 사용하고, 주소를 출처가 불분명한 변환 페이지에 붙여 넣지 마세요. 공개 채팅, 스크린샷 또는 문의글에 전체 링크를 노출해서도 안 됩니다. 구독 주소에는 접근 자격 증명이 포함되는 경우가 많으므로 유출되었다면 서버에서 재설정하거나 다시 생성해야 합니다.

첫 가져오기 확인 방법

클라이언트의 구독 관리 영역에 주소를 추가하고 용도를 알아보기 쉬운 이름을 입력한 다음 업데이트를 실행하세요. 업데이트가 끝나면 상태 메시지와 업데이트 시간을 먼저 확인하고, 설정 세부 정보에서 노드 수, 프록시 그룹 및 규칙이 표시되는지 확인합니다. ‘업데이트 성공’이라는 문구만 믿어서는 안 됩니다. 일부 주소는 HTML 오류 페이지를 반환할 수 있어 클라이언트가 다운로드 완료라고 표시해도 유효한 설정으로 파싱하지 못할 수 있습니다. 프록시 그룹이 비어 있다면 응답 형식, 구독 만료 여부 및 클라이언트의 설정 형식 지원 여부를 확인하세요.

구독 업데이트가 실패하면 다음 순서로 범위를 좁혀 보세요. 첫째, 현재 네트워크에서 주소에 직접 접속할 수 있는지 확인합니다. 둘째, TLS 인증서 검증에는 정확한 시간이 필요하므로 시스템 시간을 확인합니다. 셋째, 클라이언트가 기존 프록시를 통해 업데이트해야 하는지 확인합니다. 넷째, 로그에서 HTTP 상태 코드와 파싱 오류를 확인합니다. 다섯째, 주소 끝에 불필요한 공백이나 줄바꿈이 없는지 확인합니다. 브라우저에서는 주소가 열리지만 클라이언트에서 실패한다면 브라우저만 프록시를 사용하고 클라이언트에는 아직 프록시가 설정되지 않았을 수 있습니다. 클라이언트가 직접 연결에서는 실패하고 기존 프록시를 사용하면 성공한다면 구독 설정에서 올바른 업데이트 프록시를 선택하세요.

노드, 프록시 그룹 및 정책의 관계

노드는 원격 연결을 위한 구체적인 진입점이고, 프록시 그룹은 여러 노드를 묶어 선택하는 도구입니다. 가장 단순한 select 그룹은 사용자가 직접 노드를 선택합니다. URL Test는 테스트 결과에 따라 노드를 선택하고, fallback은 현재 노드를 사용할 수 없을 때 전환하며, load-balance는 정책에 따라 요청을 분배합니다. 테스트 결과는 테스트 URL과 테스트 시점만 반영하므로 실제 이용 경험을 대신할 수 없습니다. 노드의 지역, 회선 혼잡도, 대상 사이트 위치 및 프로토콜 호환성에 따라 결과가 달라집니다. 먼저 select 그룹으로 제어 가능한 기준을 만든 뒤 규칙이 정확한지 확인하고 자동 선택을 시도하는 것이 좋습니다.

구독 업데이트와 로컬 수정

많은 클라이언트는 구독 설정과 로컬 오버라이드를 별도로 저장합니다. 구독으로 생성된 파일을 직접 수정하면 다음 업데이트에서 변경 사항이 덮어써질 수 있습니다. 더 안정적인 방법은 클라이언트가 제공하는 오버라이드, Merge 또는 Patch 기능을 사용해 사용자 지정 프록시 그룹, 규칙 및 DNS를 별도 파일에 넣는 것입니다. 오버라이드를 지원하지 않는 클라이언트라면 최소한 수정 전에 백업을 내보내고 변경 위치를 기록하세요. 수정이 적용됐는지 확인할 때는 디스크 파일만 보지 말고 실행 중인 설정 미리보기와 로그를 확인해야 합니다.

노드 필터링은 최저 지연 시간만 추구해서는 안 됩니다. 가끔 매우 낮은 수치가 나오는 노드보다 패킷 손실이 적고 안정적인 회선이 장기간 사용에 더 적합합니다. 트래픽 배율, 출구 지역, UDP 지원 여부 및 대상 서비스의 출구 제한도 확인해야 합니다. Clash 노드 선택 방법을 참고해 자신만의 필터링 기록을 만들어 보세요. 구독이 정상적으로 업데이트된 뒤 다음 장에서 프록시 모드를 선택하면 모드가 정해지지 않은 상태에서 규칙 효과를 잘못 판단하는 일을 줄일 수 있습니다.

프록시 모드: Direct, Global, Rule은 어떻게 사용할까

프록시 모드는 코어가 요청을 받은 뒤 어떤 방식으로 결정할지 정합니다. Direct는 요청을 대상에 직접 연결하므로 네트워크 자체를 확인하거나 규칙의 영향을 점검할 때 사용합니다. Global은 대부분의 요청을 하나의 프록시 그룹으로 보내므로 특정 회선으로 대상에 접속할 수 있는지 빠르게 확인하는 데 적합하지만, 세밀한 라우팅을 장기간 적용하는 방식으로는 적합하지 않습니다. Rule은 rules를 위에서부터 순서대로 매칭하며 일상적인 사용에서 가장 흔한 모드입니다. 모드를 바꿔도 노드 자체가 변경되거나 DNS, 시스템 프록시 및 TUN 권한 문제가 자동으로 해결되지는 않으므로 로그와 연결 기록을 함께 확인해야 합니다.

Direct 모드로 기준선 만들기

웹페이지가 열리지 않을 때 잠시 Direct로 전환해 대상에 정상적으로 연결되는지 확인할 수 있습니다. Direct는 정상인데 Rule이 실패한다면 규칙, 프록시 노드 또는 프록시 그룹에 문제가 있을 수 있습니다. Direct도 실패한다면 로컬 네트워크, DNS, 대상 사이트 상태 또는 시스템 방화벽을 점검해야 합니다. Direct는 프록시 경로를 우회하므로 규칙이 올바르다는 증거가 아닙니다. 테스트가 끝나면 원래 모드로 돌아가야 예상한 라우팅 정책을 유지할 수 있습니다.

Global 모드로 노드 확인하기

Global 모드는 요청을 선택한 프록시 그룹으로 모아 ‘이 노드 그룹으로 대상에 접속할 수 있는가’를 확인할 때 사용합니다. Global에서는 접속되지만 Rule에서는 안 된다면 규칙 매칭과 프록시 그룹 참조를 먼저 확인하세요. Global에서도 접속되지 않는다면 현재 노드, 프로토콜 핸드셰이크, 출구 지역 및 원격 응답을 점검해야 합니다. Global을 사용하면 직접 연결해야 하는 중국 본토 사이트, 로컬 네트워크 주소 또는 로컬 IP가 필요한 서비스까지 프록시를 거칠 수 있으므로 단기 진단용으로만 사용하고 끝나면 Rule로 되돌리세요.

Rule 모드에서 중점적으로 볼 항목

Rule 모드의 핵심은 규칙 수가 아니라 순서와 적용 범위입니다. 하나의 도메인이 여러 조건에 동시에 해당할 수 있으며, 코어는 일반적으로 먼저 매칭되는 규칙을 적용합니다. 흔한 설정은 로컬 네트워크, 사설 IP 및 특정 도메인을 먼저 처리한 다음 광고나 지역 목록을 처리하고 마지막에 MATCH로 나머지를 처리합니다. MATCH가 없으면 매칭되지 않은 요청이 기본 정책을 따를 수 있어 예상과 다르게 동작합니다. 프록시 그룹을 선택할 때는 그룹 이름과 규칙에서 참조하는 이름이 완전히 일치하는지 확인하세요.

클라이언트의 연결 기록에는 보통 요청 도메인, 매칭된 규칙 및 최종 정책이 표시됩니다. 접속 문제가 발생하면 먼저 연결 기록을 지우거나 필터링한 뒤 대상 페이지 하나만 열어 요청이 나타나는지, 규칙 필드에 무엇이 표시되는지, 최종적으로 어떤 노드가 선택됐는지 확인하세요. 브라우저는 여러 도메인에 동시에 요청할 수 있으므로 페이지가 열린다고 해서 모든 리소스가 같은 경로를 사용한다는 뜻은 아닙니다. 애플리케이션 문제라면 QUIC, DoH 또는 자체 프록시를 사용하는지도 확인해야 합니다. 이런 트래픽은 일반 브라우저 연결과 다르게 표시될 수 있습니다.

시스템 프록시와 TUN의 경계

시스템 프록시는 주로 시스템 설정을 따르는 TCP 애플리케이션을 가로채고, TUN은 가상 네트워크 인터페이스를 통해 더 넓은 범위의 시스템 트래픽을 가로챕니다. TUN을 켜면 시스템 프록시를 우회하던 일부 프로그램도 코어로 들어올 수 있지만 권한, 라우팅 및 DNS 처리의 복잡성이 커집니다. 먼저 시스템 프록시 모드에서 구독, 규칙 및 노드를 검증하고, 시스템 프록시를 따르지 않는 애플리케이션까지 반드시 가로채야 할 때만 7장의 TUN 설정으로 넘어가세요.

규칙 라우팅: 매칭 순서부터 검증 가능한 정책 설계까지

규칙 라우팅의 목적은 서로 다른 요청을 명확한 조건에 따라 직접 연결, 프록시 또는 다른 정책 그룹으로 보내는 것입니다. 규칙은 많을수록 좋은 것이 아니라 경계가 명확하고 순서가 안정적이며 기본 처리가 분명해야 합니다. 일반적인 규칙 유형에는 전체 도메인을 매칭하는 DOMAIN, 접미사를 매칭하는 DOMAIN-SUFFIX, 키워드를 매칭하는 DOMAIN-KEYWORD, IP나 네트워크 대역을 매칭하는 IP-CIDR, 그리고 매칭되지 않은 요청을 마지막에 처리하는 MATCH가 있습니다. 규칙 오른쪽의 정책 이름은 설정의 proxy-groups나 예약된 정책에 존재해야 합니다. 그렇지 않으면 파일에 규칙을 작성해도 예상대로 실행되지 않습니다.

도메인 규칙의 차이

DOMAIN,api.example.com,PROXY는 지정한 전체 도메인만 매칭합니다. DOMAIN-SUFFIX,example.com,PROXY는 일반적으로 해당 도메인과 하위 도메인을 포함합니다. DOMAIN-KEYWORD,example,PROXY는 도메인 안의 키워드를 매칭하므로 범위가 넓고 잘못 매칭될 가능성도 큽니다. 서비스 하나에 규칙을 추가할 때는 전체 도메인이나 접미사 규칙을 우선 사용하고, 도메인 구조가 복잡하며 영향 범위를 확인한 경우에만 키워드 규칙을 사용하세요. 규칙의 도메인에는 프로토콜, 경로 또는 포트를 포함하면 안 됩니다. https://example.com/path를 입력하면 원하는 대로 매칭되지 않습니다.

규칙 순서와 로컬 네트워크 예외

로컬 네트워크와 본인 장치의 주소는 일반적으로 앞쪽에 배치해야 합니다. 이렇게 하면 프린터, 라우터 관리 페이지 및 가정용 서버 요청이 원격 노드로 전송되는 것을 막을 수 있습니다. 예시 순서는 다음과 같습니다:

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

no-resolve는 IP 규칙이 도메인 판단을 위해 추가 DNS 조회를 수행하는 것을 막아 줍니다. 이미 IP 네트워크 대역을 기준으로 판단하는 상황에 적합합니다. 모든 규칙에 반드시 추가해야 하는 옵션은 아니므로 사용하기 전에 현재 DNS 모드와 규칙 엔진의 동작을 이해해야 합니다. GEOIP는 IP 데이터베이스에 의존하므로 데이터베이스 업데이트 상태가 결과에 영향을 줍니다. 특정 사이트에 출구나 도메인 정책이 명확히 필요하다면 지역 판정에 전적으로 의존하지 말고 도메인 규칙을 우선 작성하세요.

규칙 세트와 로컬 오버라이드

대규모 도메인 목록은 보통 rule-provider나 규칙 세트 형태로 불러옵니다. 규칙 세트는 중앙 관리에 적합하지만 디버깅할 때 실제 매칭 출처를 알고 있어야 합니다. 로컬 규칙을 수정한 뒤에는 먼저 설정을 저장하고 다시 불러오세요. 규칙 세트가 원격 주소라면 업데이트가 성공했는지도 확인해야 합니다. 문제 해결을 쉽게 하려면 개인 예외 규칙 몇 개를 독립 파일의 맨 위에 두고, 그 뒤에 일반 규칙 세트를 배치하며 마지막에는 명확한 MATCH를 남겨 두세요. 이렇게 하면 개인 예외를 빠르게 적용하면서 상위 구독을 직접 수정하지 않을 수 있습니다.

규칙 하나를 검증하는 방법

검증할 때는 대상 도메인 하나만 선택하세요. 연결 기록을 지우고 대상을 방문한 뒤 연결 상세 정보에서 도메인, 해석된 주소, 매칭 규칙 및 최종 정책을 확인합니다. 기록이 없다면 애플리케이션이 시스템 프록시나 TUN을 거치는지 먼저 확인하세요. 기록은 있지만 MATCH가 적용됐다면 규칙 파일이 로드됐는지와 규칙 순서가 올바른지 점검합니다. 대상 규칙이 매칭됐는데도 실패한다면 문제는 규칙 계층에서 정책 그룹, 노드 또는 원격 응답 계층으로 넘어간 것입니다. 세 곳의 설정을 동시에 바꾸지 마세요. 어떤 변경이 결과를 만들었는지 알 수 없게 됩니다.

규칙 라우팅은 캐시의 영향도 받습니다. 브라우저가 DNS, 연결 또는 리디렉션 결과를 캐시할 수 있고 클라이언트도 연결 상태를 유지할 수 있습니다. 규칙을 수정한 뒤 대상 페이지를 닫고 설정을 한 번 다시 불러온 다음, 필요하면 연결을 새로 수립해 새로운 요청을 확인하세요. 장기적으로 관리하려면 개인 규칙을 날짜와 용도 설명이 포함된 독립 조각으로 작성하고, 더 이상 필요하지 않은 예외는 정기적으로 삭제하세요. 규칙표가 설명할 수 없는 블랙박스로 변하는 것을 막을 수 있습니다.

TUN 및 DNS: 시스템 프록시가 처리하지 못하는 트래픽 다루기

TUN은 가상 네트워크 인터페이스입니다. 시스템이 트래픽을 이 인터페이스로 보내면 Clash 코어가 네트워크 계층에 더 가까운 위치에서 요청을 받을 수 있어 시스템 프록시를 따르지 않는 프로그램도 라우팅 대상에 포함될 수 있습니다. TUN은 ‘더 빠른 프록시 모드’가 아니며 켠다고 모든 네트워크 문제가 사라지는 것도 아닙니다. 시스템 권한, 라우팅 설정 및 올바른 DNS 구성이 필요하고, 다른 VPN, 가상 네트워크 카드 또는 기업 보안 프로그램과 함께 실행하면 라우팅 충돌이 발생할 수 있습니다. 일반 시스템 프록시로 대상 애플리케이션을 처리할 수 없을 때만 활성화하는 것이 좋습니다.

활성화 전 준비

먼저 다른 VPN을 끄고 현재 네트워크가 정상적으로 작동하는지 기록하세요. 데스크톱 클라이언트에서 TUN, 확장 모드 또는 가상 네트워크 카드 설정을 찾아 코어가 해당 기능을 지원하는지 확인합니다. Windows에서는 드라이버나 관리자 권한 요청이 표시될 수 있고, macOS에서는 네트워크 확장 허용이 필요할 수 있으며, Linux에서는 CAP_NET_ADMIN 또는 root 권한이 필요할 수 있습니다. 모바일에서는 VPN 가로채기를 시스템 애플리케이션 계층에서 제어하므로 일반적으로 데스크톱과 같은 TUN 스위치를 사용하지 않습니다. 활성화하기 전에 TUN을 끄고 되돌릴 수 있는 경로를 남겨 두어 재시작 후 네트워크가 복구되지 않는 상황을 피하세요.

DNS 모드의 역할

DNS는 도메인을 IP로 바꾸는 기능만 하지 않습니다. 규칙은 보통 먼저 도메인을 확인해야 하며, DNS 처리 방식은 규칙 매칭, Fake-IP 매핑, 로컬 네트워크 접근 및 오염 우회에 영향을 줍니다. 대표적인 방식으로 redir-host와 fake-ip가 있습니다. redir-host는 실제 해석 주소를 반환해 호환성을 직관적으로 유지하지만 일부 도메인의 결과가 현재 네트워크의 영향을 받을 수 있습니다. fake-ip는 도메인에 가상 주소를 할당하고 코어가 매핑 테이블에 도메인 정보를 보존하므로 연결 단계에서도 도메인 기반 매칭을 이어 갈 수 있습니다. 다만 일부 로컬 네트워크 장치, IP를 하드코딩한 애플리케이션 및 특수 인증 절차와 호환되지 않을 수 있습니다.

예시 설정은 다음과 같습니다. 실제 DNS 서버는 네트워크 환경과 클라이언트 지원 여부에 따라 조정해야 합니다:

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
    - "+.local"

Fake-IP 주소 대역은 실제 로컬 네트워크 대역과 충돌해서는 안 되며, 필터 목록도 무작정 그대로 사용하면 안 됩니다. 로컬 네트워크 호스트 이름, 스마트홈 기기 또는 사내 네트워크에 접근해야 한다면 해당 도메인을 필터 범위에 추가하고 로컬 DNS가 계속 접근 가능한지 확인하세요. 어떤 애플리케이션이 도메인이 아닌 IP 주소를 표시한다면 Fake-IP가 원래 도메인을 복원하지 못할 수 있습니다. 이런 애플리케이션은 필터에 추가하거나 더 적합한 가로채기 방식을 사용해야 합니다.

TUN 활성화 후 문제 해결 순서

활성화한 뒤 먼저 로컬 네트워크 게이트웨이를 테스트하고, 다음으로 일반 도메인, 마지막으로 프록시가 필요한 대상을 테스트하세요. 로컬 네트워크가 실패하면 라우팅, Fake-IP 필터 및 로컬 네트워크 허용 설정을 확인합니다. 일반 도메인이 실패하면 DNS 로그, 가상 네트워크 카드 및 시스템 DNS를 확인합니다. 앞의 두 단계가 정상인데 프록시 대상만 실패할 때 규칙, 프록시 그룹 및 노드를 점검하세요. 모든 네트워크가 끊기면 즉시 TUN을 끄거나 클라이언트를 종료해 기본 네트워크를 복구한 뒤 권한과 라우팅 로그를 확인하세요. 설정을 계속 추가해서는 안 됩니다.

DNS 캐시 때문에 변경 사항이 적용되지 않은 것처럼 보일 수도 있습니다. 설정을 수정한 뒤 클라이언트 설정을 다시 불러오고 네트워크를 재연결한 다음, 운영체제에 맞게 DNS 캐시를 갱신하세요. 브라우저의 보안 DNS가 시스템 DNS를 우회하거나 애플리케이션 자체 해석기가 코어를 우회할 수도 있습니다. 문제를 해결할 때는 테스트 도구가 어떤 해석 경로를 사용하는지 명확히 해야 합니다. TUN과 DNS 검증을 마쳤다면 복잡한 설정을 위해 옵션을 계속 늘리지 마세요. 안정적이고 설명 가능한 설정이 기능을 쌓는 것보다 장기 관리에 적합합니다.

일상 관리와 고급 설정 로드맵: 설명 가능한 설정 유지하기

Clash를 안정적으로 사용하는 핵심은 자주 바꾸는 것이 아니라 정해진 점검 주기를 만드는 데 있습니다. 구독을 업데이트할 때마다 업데이트 시간, 노드 유지 여부 및 프록시 그룹 참조 상태를 확인하세요. 클라이언트를 업그레이드할 때마다 코어 로그와 시스템 프록시 상태를 확인하고, 규칙이나 DNS를 수정할 때는 한 번에 변수 하나만 바꿔 대상 테스트를 수행하세요. 설정을 한 번 가져오면 영원히 변하지 않는 값이 아니라 관리해야 하는 실행 파일로 생각하면 ‘어제까지 됐는데 오늘 갑자기 안 됨’과 같은 상황에서도 원인을 훨씬 쉽게 찾을 수 있습니다.

보관을 권장하는 기록

최소한 현재 사용하는 클라이언트 이름, 설정 출처, 프록시 모드, 혼합 포트, TUN 활성화 여부, DNS 모드 및 사용자 지정 규칙 파일을 기록해 두세요. 구독 주소는 공개 문서에 직접 적지 말고 용도와 서버 관리 위치만 기록할 수 있습니다. 문제가 발생하면 발생 시간, 네트워크 유형, 대상 도메인, 연결 로그의 매칭 규칙 및 오류 메시지를 함께 남기세요. ‘인터넷이 안 됨’이라는 한마디보다 이런 맥락 정보가 구독, 규칙, DNS, 노드 또는 시스템 권한 중 무엇이 바뀌었는지 파악하는 데 훨씬 도움이 됩니다.

클라이언트와 코어 업데이트 시 이전 절차

업그레이드 전에 현재 설정을 내보내거나 로컬 오버라이드 파일을 복사하고, 사용자 지정 규칙과 프록시 그룹 이름을 기록하세요. 새 클라이언트를 설치한 뒤에는 TUN을 바로 켜지 말고 설정을 가져와 프록시 그룹을 확인합니다. 그다음 시스템 프록시를 켜고 브라우저로 테스트한 뒤, 마지막으로 TUN, DNS 및 시작 시 자동 실행을 복원하세요. 클라이언트마다 필드, 외부 제어 인터페이스 및 오버라이드 문법 지원이 완전히 같지 않습니다. 기존 설정을 가져올 수 있다고 해서 모든 옵션이 적용되는 것은 아닙니다. 시작 오류가 발생하면 최소 설정으로 되돌린 뒤 구간별로 복원해야 하며, 기존 디렉터리 전체를 새 클라이언트에 덮어써서는 안 됩니다.

일반적인 장애 판단 트리

클라이언트가 열리지 않으면 설치 패키지, 권한 및 시스템 로그를 먼저 확인하세요. 클라이언트는 열리지만 노드가 없다면 구독 업데이트와 설정 파싱을 확인합니다. 노드는 있지만 모든 요청이 실패한다면 프록시 그룹 선택, 노드 핸드셰이크 및 시스템 시간을 점검하세요. 일부 도메인만 실패한다면 규칙 매칭, DNS 및 대상 사이트 제한을 확인합니다. 브라우저는 되지만 특정 애플리케이션만 안 된다면 애플리케이션이 시스템 프록시를 따르는지 확인하세요. TUN을 켠 뒤 전체 네트워크가 끊기면 TUN을 끄고 라우팅, 권한 및 다른 VPN을 확인합니다. 이 순서는 로컬 프로그램에서 원격 서비스로 점검 범위를 단계적으로 넓히므로 모든 문제를 노드 탓으로 돌리는 일을 막아 줍니다.

FAQ 페이지에는 구독 업데이트 실패, 시스템 프록시 및 설정 가져오기와 같은 짧은 질문을 정리했습니다. 특정 용어를 찾을 때는 사이트 내 클라이언트 및 설정 설명에서 해당 장으로 이동할 수 있습니다. 블로그 글은 Fake-IP 원리나 iOS 설정 가져오기처럼 특정 주제를 읽는 데 적합하고, 이 페이지는 설정 중 필요한 장을 반복해서 찾는 데 적합합니다. 세 콘텐츠의 용도가 다르므로 문제가 생겼다고 문서 전체를 처음부터 다시 읽을 필요는 없습니다.

Mihomo 설정 더 알아보기

기본 라우팅을 완료한 뒤에는 프록시 그룹 정책, rule-provider, 스크립트 규칙, 외부 제어 인터페이스 및 서비스 실행을 순서대로 학습할 수 있습니다. 고급 설정은 두 가지 원칙을 따라야 합니다. 새 기능마다 어떤 문제를 해결하는지 설명할 수 있어야 하고, 모든 원격 출처마다 누가 관리하는지 알 수 있어야 합니다. 다른 사람의 전체 설정을 그대로 복사해 DNS, 스크립트 및 규칙 세트를 한 번에 많이 활성화하지 마세요. 설정이 복잡해질수록 장애 범위가 넓어지고 상위 설정 변경으로 오래된 필드가 작동하지 않을 수 있습니다. 설정을 읽을 때는 먼저 포트와 모드를 보고, 다음으로 DNS, 그다음 프록시 그룹과 규칙, 마지막으로 고급 실험 옵션을 확인하세요.

서버나 라우터에서는 Mihomo 프로세스 권한, 설정 디렉터리 및 관리 인터페이스를 분리해 계획하는 것이 좋습니다. 관리 인터페이스는 신뢰할 수 있는 주소에만 바인딩하고, 설정 파일의 읽기 권한을 제한하며, 서비스를 재시작한 뒤 로그를 확인하세요. 업그레이드할 때는 이전에 작동하던 코어 파일을 보관해야 합니다. 데스크톱과 모바일에서는 백그라운드 권한을 관리하고 여러 VPN이 경쟁하지 않도록 하며 만료된 구독과 오래된 규칙을 정리하는 것이 중요합니다. 플랫폼이 달라도 핵심 문제 해결 방법은 같습니다. 트래픽이 코어에 들어오는지, DNS와 규칙이 어떻게 처리하는지, 정책 그룹과 노드가 연결을 완료했는지를 차례로 확인하세요.

이제 Clash 사용 과정을 안정적인 순서로 정리할 수 있습니다. 시스템에 맞는 클라이언트를 선택해 최소 권한으로 설치하고, 구독을 가져와 검증한 다음 Rule 모드로 라우팅 기준을 세우세요. 연결 기록으로 규칙을 확인하고, 꼭 필요할 때만 TUN과 Fake-IP를 활성화합니다. 정기적으로 구독을 업데이트하고 로그를 확인하며 사용자 지정 설정을 백업하세요. 구체적인 작업 문제가 생기면 빠른 시작으로 돌아가 기본 흐름을 따르고, 전체 클라이언트 패키지 목록이 필요하면 Clash 다운로드 페이지에서 플랫폼에 맞는 항목을 선택하세요.