Clash 완벽 가이드: 설치·구독·규칙·TUN

핵심 개념: 클라이언트, 코어와 설정부터 구분하기

Clash는 하나의 설치 파일이 아닙니다

“Clash”는 일반적으로 규칙 기반 프록시를 중심으로 한 클라이언트와 코어 생태계를 뜻하며, 하나의 고정된 인터페이스를 가진 단일 프로그램을 의미하지는 않습니다. 사용자가 직접 조작하는 것은 Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu, Clash Meta for Android 또는 ClashX Meta 같은 그래픽 클라이언트입니다. 실제로 프록시 연결을 만들고 설정을 해석하며 규칙을 매칭하는 역할은 코어가 담당합니다. 현재 많이 사용되는 클라이언트는 대부분 mihomo 코어를 기반으로 작동하며, 인터페이스는 코어의 기능을 스위치, 목록과 상태 화면으로 정리해 보여줍니다.

이 관계를 이해하는 것은 중요합니다. 인터페이스가 열리지 않는 문제, 구독 업데이트 실패, 특정 규칙 미적용은 서로 다른 계층의 문제일 수 있습니다. 인터페이스가 충돌하면 먼저 클라이언트 자체를 확인하고, 프로토콜이나 규칙 동작이 이상하면 코어 로그와 설정을 확인해야 합니다. 구독 내용이 불완전하다면 먼저 구독 제공처를 점검해야 합니다. 세 요소를 한꺼번에 의심하면 실제 원인은 건드리지 못한 채 프로그램만 반복해서 재설치하게 됩니다.

하나의 연결은 어떤 과정을 거칠까요?

애플리케이션이 네트워크 요청을 보내면 트래픽은 먼저 Clash로 들어와야 합니다. 시스템 프록시는 운영체제의 프록시 설정을 통해 해당 설정을 지원하는 앱으로 트래픽을 유도하고, TUN 모드는 가상 네트워크 인터페이스를 만들어 네트워크 계층에서 더 넓은 범위의 트래픽을 받습니다. 코어는 요청을 받은 뒤 대상 도메인, 대상 IP, 포트와 프로세스 등의 정보를 식별하고 설정 파일의 규칙을 위에서부터 순서대로 매칭합니다. 매칭 결과는 특정 정책 그룹을 가리키며, 정책 그룹이 실제 노드, 직접 연결 또는 연결 거부를 결정합니다.

도메인 요청은 DNS도 거칩니다. DNS는 도메인을 IP로 바꾸는 것뿐 아니라 규칙이 원래 도메인을 확인할 수 있는지, DNS 오염이 발생하는지, IPv4와 IPv6 중 어떤 연결을 선택하는지에도 영향을 줍니다. 정상적인 흐름은 다음과 같이 요약할 수 있습니다. 애플리케이션 요청 → 시스템 프록시 또는 TUN 연결 → DNS 주소 확인 또는 도메인 매핑 → 규칙 매칭 → 정책 그룹의 출구 선택 → 노드 연결. 이후 장에서 다루는 대부분의 설정은 이 흐름의 특정 단계를 조정합니다.

구독, 설정 파일과 노드의 차이

구독 링크는 설정 내용을 가져오는 입구입니다. 클라이언트가 구독 링크에 접속하면 서버가 완전한 YAML을 바로 반환할 수도 있고, 인코딩된 노드 목록을 반환할 수도 있습니다. 완전한 설정에는 일반적으로 프록시 노드, 정책 그룹, 규칙, DNS 및 기타 코어 매개변수가 포함됩니다. 노드 목록만 제공되는 구독은 클라이언트 템플릿이나 구독 변환 서비스로 정책 그룹과 규칙을 보완해야 합니다. 노드는 연결 출구일 뿐, 완전한 설정을 대신할 수 없습니다.

로컬에 저장하는 설정 파일은 보통 YAML 형식으로 작성합니다. YAML은 들여쓰기에 민감하므로 계층에는 일반적으로 공백을 사용하고 탭 문자는 섞지 않아야 합니다. 같은 단계의 필드는 동일한 들여쓰기를 유지해야 하며, 목록 항목은 하이픈으로 시작합니다. 많은 “설정 파싱 실패”는 프로토콜 호환성 문제가 아니라 콜론 뒤 공백 누락, 잘못된 들여쓰기, 중복 필드 또는 특수문자 인용 오류 때문에 발생합니다. 수정하기 전에 원본 파일을 보관하는 편이 나중에 기억에 의존해 복구하는 것보다 안전합니다.

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

proxies:
  - name: "Example Node"
    type: socks5
    server: 192.0.2.10
    port: 1080

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

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

제어판에서 자주 보이는 상태

“시스템 프록시”는 클라이언트가 운영체제의 프록시 설정을 수정하고 있다는 뜻이지만, 모든 프로그램이 이를 따른다는 의미는 아닙니다. “TUN”은 가상 네트워크 인터페이스를 통한 연결이 활성화되었다는 뜻이지만, 라우팅, DNS와 권한이 정상인지도 확인해야 합니다. “Rule”은 규칙 모드로, 연결을 규칙에 따라 분기한다는 의미입니다. “Global”은 글로벌 모드로, 일반적으로 모든 요청을 하나의 정책 그룹에 전달합니다. “Direct”는 가능한 한 직접 연결합니다. 이 상태들은 서로 다른 차원의 스위치이며 하나만 선택해야 하는 것이 아닙니다. 예를 들어 시스템 프록시와 Rule 모드를 동시에 켤 수 있고, TUN과 Rule 모드를 함께 사용할 수도 있습니다.

초보 단계에서 모든 필드를 한 번에 이해할 필요는 없습니다. 클라이언트는 조작을 담당하고, 코어는 실행하며, 설정은 동작을 정의하고, 구독은 설정을 업데이트하며, 규칙은 출구를 선택한다고 기억하세요. 기능을 하나씩 추가할 때마다 이 다섯 위치 중 어디에 해당하는지 판단할 수 있습니다. 낯선 클라이언트를 만나도 화면의 명칭이 달라 보일 뿐, 기능을 기준으로 필요한 설정을 찾을 수 있습니다.

클라이언트 선택: 플랫폼과 사용 방식에 맞추기

그래픽 클라이언트를 쓸까, 코어를 직접 실행할까

대부분의 데스크톱과 모바일 사용자는 그래픽 클라이언트부터 시작하는 것이 좋습니다. 그래픽 클라이언트는 설정 저장, 시스템 프록시, 시작 시 실행, 구독 업데이트, 정책 그룹 전환과 로그 확인을 처리해 주므로 문제가 생겼을 때 상태를 확인하기도 쉽습니다. mihomo 코어를 직접 실행하는 방식은 서버, 라우터, 컨테이너 환경 또는 서비스 프로세스를 직접 관리해야 하는 사용자에게 적합합니다. 이 경우 설정, 수신 포트, 실행 매개변수와 백그라운드 서비스를 직접 준비하고 권한 및 로그 순환도 관리해야 합니다.

이 사이트의 다운로드 페이지는 Windows, macOS, Android, iOS, Linux와 코어로 분류되어 있습니다. Clash Plus는 주요 플랫폼에서 우선 추천하는 선택지로, 비슷한 조작 흐름을 유지하면서 구독을 바로 가져오고 싶은 사용자에게 적합합니다. Clash Verge Rev, FlClash와 Clash Nyanpasu는 데스크톱 그래픽 인터페이스를 제공합니다. Clash Meta for Android와 Surfboard는 Android용이며, ClashX Meta는 유지 관리가 중단된 macOS 보관용 클라이언트입니다. Clash for Windows 역시 유지 관리가 중단되었으므로 기존 설정을 확인하거나 데이터를 마이그레이션하는 경우에만 사용하는 것이 좋습니다.

Windows와 macOS, 어떻게 선택할까

Windows 사용자는 먼저 시스템 아키텍처를 확인해야 합니다. 일반적인 PC는 대부분 x64를 사용하며, ARM Windows 기기는 해당 아키텍처용 패키지가 필요합니다. 설치형 프로그램은 보통 바로 가기를 만들고 제거를 처리해 주지만, 압축 파일 버전은 독립적으로 보관하기 쉽고 업데이트와 파일 연결은 직접 관리해야 할 수 있습니다. 처음 실행할 때 Windows 방화벽 알림이 나타나면 실제 사용 범위에 따라 개인 네트워크 액세스를 허용할지 결정하세요. 같은 로컬 네트워크의 기기가 이 컴퓨터의 프록시 포트에 연결해야 할 때만 로컬 네트워크 액세스를 추가로 허용하면 됩니다.

macOS 사용자는 Apple Silicon과 Intel을 구분해야 합니다. Apple Silicon 패키지는 M 시리즈 칩을 사용하는 기기용이고, Intel 패키지는 이전 x86_64 기기용입니다. 아키텍처가 맞지 않으면 실행되지 않거나 호환성 계층을 통해 실행되면서 추가 문제가 생길 수 있습니다. 클라이언트가 처음 시스템 프록시를 수정하거나 네트워크 확장을 만들고 TUN을 활성화할 때 관리자 승인을 요청할 수 있습니다. 이는 네트워크 설정을 기록하는 정상적인 절차입니다. 구독만 먼저 확인하려면 TUN을 잠시 끄고 시스템 프록시로 기본 연결부터 테스트하세요.

모바일 플랫폼에서는 기능 수보다 안정성이 중요합니다

Android 클라이언트는 보통 시스템 VPN 인터페이스를 통해 트래픽을 가로챕니다. 설치 후 클라이언트의 VPN 연결 생성을 허용하고, 기기 제조사의 설정에 따라 배터리 최적화, 백그라운드 활동과 자동 시작 권한을 조정해야 합니다. 백그라운드로 전환한 지 몇 분 뒤 연결이 끊긴다면 노드를 바로 바꾸기보다 시스템의 절전 정책을 먼저 확인하세요. 앱별 프록시를 사용하면 터널에 들어갈 앱을 제어할 수 있지만, 클라이언트마다 “포함 모드”와 “제외 모드”의 의미가 반대일 수 있으므로 저장 전에 설명을 확인해야 합니다.

iOS와 iPadOS도 시스템 VPN 구성으로 작동합니다. 처음 연결할 때 시스템 승인 창이 나타나며, 승인해야 터널을 만들 수 있습니다. Wi-Fi와 셀룰러 네트워크를 전환할 때 잠시 재연결되는 것은 네트워크 경로가 바뀌었기 때문입니다. 계속 복구되지 않으면 연결을 끊었다가 다시 연결하고, 구독의 노드가 사용 가능한지 확인하세요. 모바일 기기는 리소스가 제한적이므로 처음부터 지나치게 큰 규칙 세트와 많은 설정 사본을 불러오지 않는 것이 좋습니다.

유지 관리가 중단된 클라이언트는 어떻게 할까

유지 관리가 중단되었다고 기존 설정이 즉시 무효가 되는 것은 아닙니다. 다만 향후 시스템 업데이트, 프로토콜 변경과 보안 문제에 대응하지 못할 수 있다는 뜻입니다. Clash for Windows와 ClashX Meta는 기존 환경을 옮길 때 사용할 수 있지만, 새로 설치할 장기 사용 클라이언트로는 적합하지 않습니다. 마이그레이션할 때는 먼저 기존 설정 폴더를 찾거나 내보내고, 자주 쓰던 정책 그룹 선택을 기록한 뒤 새 클라이언트에서 구독을 다시 가져오세요. 기존 클라이언트의 프로그램 폴더 전체를 새 클라이언트 폴더에 그대로 덮어쓰지 마세요. 데이터 구조와 설정 필드가 다를 수 있습니다.

클라이언트를 선택할 때 설정 항목이 가장 많은 제품을 고를 필요는 없습니다. 구독을 안정적으로 업데이트하고, 시스템 프록시 또는 TUN을 제대로 활성화하며, 로그를 쉽게 확인할 수 있다면 대부분의 요구를 충족합니다. 설치 파일이 필요하면 다운로드 센터에서 플랫폼 태그를 선택하세요. 먼저 플랫폼과 아키텍처를 확인한 다음 알맞은 파일을 다운로드하면, 실제로는 패키지 유형이 맞지 않아 생기는 복잡해 보이는 문제를 피할 수 있습니다.

설치와 최초 실행: 기본 연결부터 확인하기

설치 전에 기존 환경 정리하기

한 기기에 여러 클라이언트를 저장할 수는 있지만, 동시에 시스템 프록시를 수정하거나 TUN을 만드는 것은 권장하지 않습니다. 새 클라이언트를 설치하기 전에 기존 클라이언트에서 시스템 프록시와 TUN을 끄고 프로그램을 완전히 종료하세요. Windows에서는 시스템 네트워크 프록시 설정에서 수동 프록시가 꺼졌는지 확인하고, macOS에서는 현재 네트워크 서비스의 프록시 화면에서 HTTP, HTTPS와 SOCKS 항목을 확인합니다. 모바일에서는 기존 VPN 연결이 끊겼는지 확인하세요. 이렇게 하면 두 클라이언트가 포트를 차지하거나 시스템 설정을 반복해서 덮어쓰는 일을 막을 수 있습니다.

기존 설정을 옮길 예정이라면 먼저 설정 폴더를 복사하거나 YAML을 내보내세요. 보존할 대상은 구독 주소, 직접 수정한 규칙, 정책 그룹 설정과 DNS 변경 사항이지 캐시, 로그와 임시 데이터베이스가 아닙니다. 구독 주소는 개인 사용 정보이므로 공개 스크린샷, 포럼이나 코드 저장소에 올리면 안 됩니다. 백업을 완료한 뒤 다운로드 센터에서 플랫폼에 맞는 설치 파일을 선택하세요.

Windows 설치와 최초 확인

Windows 설치 프로그램 다운로드가 끝나면 마법사에서 설치 위치를 선택하고 클라이언트를 실행합니다. 네트워크 구성 요소 설치나 관리자 권한을 요구하는 알림이 나타나면 지금 조작하는 파일이 방금 다운로드한 클라이언트인지 확인한 뒤 진행하세요. 앱이 실행되면 모든 스위치를 서둘러 켜지 말고 먼저 “설정” 또는 “구독” 화면을 찾아 인터페이스가 정상적으로 로드되는지 확인합니다. 그다음 설정 화면에서 혼합 포트, 시스템 프록시와 TUN 상태를 확인하세요.

일반적으로 로컬 혼합 포트는 7890이지만 반드시 이 값을 사용할 필요는 없습니다. 다른 프로그램이 사용하지 않고 수동 프록시를 설정하는 앱이 동일한 포트를 사용한다면 어떤 값이든 괜찮습니다. 로그에 “address already in use”가 표시되면 수신 포트가 충돌한 것입니다. 다른 프록시 프로그램을 종료하거나 mixed-port를 사용하지 않는 포트로 변경하세요. 포트를 바꾼 뒤에는 브라우저 확장 프로그램, 개발 도구와 명령줄 환경의 프록시 주소도 함께 수정해야 합니다.

netstat -ano | findstr :7890

curl.exe -x http://127.0.0.1:7890 https://example.com/

첫 번째 명령은 Windows에서 어떤 프로세스가 7890 포트를 사용 중인지 확인하고, 두 번째 명령은 로컬 HTTP 프록시를 통해 요청을 보내는 데 사용합니다. 테스트 주소는 프록시 포트가 연결을 받을 수 있는지만 확인할 뿐, 실제 서비스 사이트에 접속할 수 있는지를 보장하지 않습니다. curl이 127.0.0.1에 연결되지 않으면 원격 노드보다 먼저 클라이언트 코어가 실행 중인지 확인하세요.

macOS 설치와 시스템 권한 승인

macOS에서 다운로드한 앱은 보통 “응용 프로그램” 폴더로 옮긴 뒤 해당 폴더에서 실행해야 합니다. 처음 실행할 때 출처 확인이나 권한 알림이 나타날 수 있으므로 시스템의 보안 설정에서 승인하세요. 시스템 프록시를 수정할 때 관리자 승인을 요청할 수 있으며, TUN이나 네트워크 확장을 활성화할 때는 새 VPN 구성을 허용해야 할 수도 있습니다. 승인이 끝나면 클라이언트로 돌아와 스위치가 실제로 켜졌는지 확인하세요. 팝업이 사라진 것만으로 성공을 판단하면 안 됩니다.

메뉴 막대에 다른 프록시 클라이언트 아이콘이 있다면 먼저 기존 프로그램을 종료하세요. 시스템 프록시가 켜져 있지만 브라우저에 전혀 영향을 주지 않는다면 “시스템 설정 → 네트워크 → 현재 네트워크 → 세부사항 → 프록시”에서 주소가 127.0.0.1을 가리키는지, 포트가 클라이언트와 일치하는지 확인합니다. 클라이언트를 종료하기 전에는 시스템 프록시를 먼저 끄는 것이 좋습니다. 비정상 종료로 프록시 설정이 남았다면 시스템 네트워크 설정에서 직접 해제할 수 있습니다.

Android, iOS와 Linux 최초 실행

Android 설치 후 먼저 VPN 연결 생성에 필요한 권한을 허용하세요. 시스템에서 “항상 켜진 VPN”을 활성화하고 다른 앱에 연결한 상태라면 새 클라이언트가 트래픽을 가로챌 수 없으므로 먼저 설정을 변경해야 합니다. 일부 시스템은 백그라운드 네트워크와 배터리 사용을 제한합니다. 연결은 되지만 화면을 잠근 뒤 끊긴다면 백그라운드 실행 허용 목록에 클라이언트를 추가하세요. 최초 테스트에서는 복잡한 앱별 규칙을 끄고 모든 앱이 연결되는지 확인한 다음 제외 항목을 단계적으로 추가합니다.

iOS 또는 iPadOS에서 App Store로 Clash Plus를 설치한 뒤, 처음 연결할 때 새 VPN 구성을 허용해야 합니다. 상태 표시줄의 VPN 표시는 터널이 만들어졌다는 뜻일 뿐, 구독의 모든 노드가 사용 가능하다는 의미는 아닙니다. 클라이언트로 돌아가 연결 로그를 확인하고 일반 웹페이지로 테스트하세요. 셀룰러 네트워크는 되지만 Wi-Fi가 되지 않는다면 현재 Wi-Fi의 DNS, 인증 페이지와 라우팅 제한을 확인해야 합니다.

Linux 그래픽 클라이언트의 설치 방법은 패키지 유형과 배포판에 따라 달라집니다. Debian, Ubuntu 및 파생 시스템은 deb 패키지를 설치할 수 있고, 다른 배포판은 호환되는 패키지 유형을 선택해야 합니다. 설치 후 트레이 아이콘이 보이지 않아도 코어가 실행되지 않는다는 뜻은 아닙니다. 앱 창과 프로세스 목록에서 확인하세요. mihomo 코어를 별도로 실행할 때는 설정 디렉터리를 명확히 지정하고 먼저 설정 테스트를 실행해야 합니다.

mihomo -t -d ./clash-config
mihomo -d ./clash-config

-t는 설정을 파싱할 수 있는지 확인하고, -d는 설정 파일과 실행 데이터를 포함하는 디렉터리를 지정합니다. 먼저 테스트한 다음 실행하면 YAML 형식 오류와 네트워크 연결 오류를 구분할 수 있습니다. 장기 서비스로 실행할 때는 시스템 서비스 관리자를 사용해 자동 시작, 충돌 후 재시작과 로그를 관리하세요. 터미널 창을 계속 foreground로 둘 필요는 없습니다.

최초 실행 후 최소 점검

설치가 끝나면 정해진 순서로 확인하세요. 클라이언트 인터페이스가 정상적으로 열리는지, 코어 상태가 실행 중인지, 로컬 포트가 정상적으로 수신 중인지, 시스템 프록시 또는 VPN/TUN 중 하나 이상의 트래픽 연결 방식이 선택되어 있는지, 설정을 가져온 뒤 정책 그룹이 보이는지, 사용 가능한 노드를 선택했을 때 연결 로그가 생성되는지 확인합니다. 특정 웹사이트 하나의 접속 여부만으로 판단하지 마세요. 사이트 자체, DNS, 규칙과 노드 출구가 모두 결과에 영향을 줄 수 있습니다.

기본 연결이 아직 되지 않았다면 Fake-IP, 규칙 세트와 스크립트를 먼저 조정하지 마세요. 기본 설정을 유지해야 문제를 찾기 쉽습니다. 다운로드와 설치에 관한 자주 묻는 질문은 다운로드 페이지 FAQ에서 확인할 수 있습니다. 가장 짧은 절차만 따라가고 싶다면 사용 가이드로 돌아가세요.

구독 가져오기: 링크에서 사용 가능한 설정까지

가져오기 전에 구독이 무엇을 반환하는지 확인하기

구독 링크는 보통 서비스 제공자가 생성하며 식별 매개변수가 포함될 수 있으므로 계정 정보처럼 보관해야 합니다. 전체 주소를 공개 스크린샷, 브라우저 동기화 메모나 공개 저장소에 넣지 마세요. 가져오기 전에 링크가 아직 유효한지, 서비스 제공자가 Clash 또는 mihomo 형식을 명시적으로 지원하는지 확인할 수 있습니다. 브라우저에서 링크가 열린다고 해서 클라이언트가 반드시 파싱할 수 있는 것은 아닙니다. 브라우저가 텍스트를 다운로드했다고 해서 그 내용이 완전한 YAML이라는 뜻도 아닙니다.

완전한 설정에는 최소한 프록시 노드와 정책 그룹이 포함되어야 하며, 흔히 proxies, proxy-groups와 rules 필드를 사용합니다. 반환 내용이 인코딩된 문자열 하나뿐이라면 클라이언트가 먼저 범용 구독으로 인식한 뒤 Clash 설정으로 변환해야 할 수 있습니다. 원격 변환 서비스를 이용한다면 해당 서비스가 구독 주소를 읽는다는 점을 이해해야 합니다. 서비스 제공자가 명확히 지원하는 형식을 우선 사용하고, 중간 단계를 줄일수록 장애 지점도 줄어듭니다.

클라이언트에서 구독 추가하기

클라이언트에 따라 메뉴 이름은 “구독”, “설정”, “Profiles” 또는 “원격 설정”일 수 있지만 흐름은 대체로 같습니다. 원격 설정을 새로 만들고 링크를 붙여 넣은 뒤 식별하기 쉬운 이름을 입력하고 저장한 다음 업데이트를 실행합니다. 업데이트가 완료되면 해당 설정을 현재 설정으로 선택하고 정책 그룹 화면에서 사용할 출구를 지정하세요. 링크를 목록에 추가하기만 하고 현재 설정으로 전환하지 않는 것은 초보자가 자주 놓치는 부분입니다.

설정 이름은 “일상 구독”이나 “백업 설정”처럼 용도를 설명하는 방식이 좋습니다. 접속 자격 정보를 이름에 넣을 필요는 없습니다. 자동 업데이트 간격도 지나치게 짧게 설정하지 마세요. 구독 내용은 분 단위로 바뀌지 않으므로 잦은 새로고침은 요청만 늘리고 서버 제한을 유발할 수 있습니다. 하루 한 번 또는 서비스 제공자의 권장 주기에 맞추고, 변경 내용을 즉시 받아야 할 때만 수동으로 새로고침하세요.

업데이트 실패 시 응답 단계별로 확인하기

“연결할 수 없음”은 보통 요청이 유효한 응답을 받지 못했다는 뜻이므로 현재 네트워크, 도메인 확인, 시스템 시간과 링크 전체를 점검해야 합니다. “요청 거부” 또는 HTTP 인증 오류는 링크 만료, 누락된 매개변수나 접근 조건과 관련된 경우가 많습니다. “파싱 실패”는 내용을 받았지만 형식이 클라이언트의 예상과 다르다는 뜻입니다. 반환된 웹페이지, 인코딩된 구독, YAML 들여쓰기 오류 또는 지원되지 않는 필드가 흔한 원인입니다. “업데이트 성공했지만 노드가 없음”이라면 구독 자체에 노드가 포함되어 있는지, 필터 규칙이 모든 노드를 제외하지 않았는지 확인하세요.

문제를 확인할 때는 먼저 현재 기기의 브라우저 주소창에 링크를 붙여 넣어 응답 유형만 확인하세요. 다른 사람에게 전달하면 안 됩니다. 로그인 페이지, 오류 페이지 또는 인증 화면으로 이동한다면 클라이언트가 이를 설정으로 파싱할 수 없는 것이 정상입니다. 브라우저가 파일을 다운로드했다면 텍스트 편집기로 첫 부분을 확인하세요. 완전한 YAML은 보통 키 이름과 들여쓰기가 보이고, 웹페이지는 HTML 태그로 시작하며, 인코딩된 구독은 한 줄의 연속된 문자로 표시될 수 있습니다.

일부 서비스는 요청의 User-Agent에 따라 다른 형식을 반환합니다. 클라이언트 설정에 구독 User-Agent 옵션이 있다면 서비스 제공자가 요구한 값을 우선 사용하고, 여러 위장 이름을 무작위로 시도하지 마세요. 구독 파싱, 캐시와 형식 변환 문제를 더 자세히 확인하려면 Clash 구독 링크 오류 자가 점검 절차를 참고하세요.

로컬 수정과 원격 업데이트의 덮어쓰기 관계

원격 구독을 업데이트하면 설정이 다시 기록되는 경우가 많으므로, 구독에서 생성된 YAML에 규칙을 직접 추가하면 다음 업데이트 때 사라질 수 있습니다. 장기적으로 유지할 수정은 클라이언트가 제공하는 덮어쓰기, 병합 또는 스크립트 기능을 사용하세요. 이런 기능이 없다면 별도의 로컬 설정을 보관하고 명확한 업데이트 절차를 마련해야 합니다. 원격 설정을 자동 업데이트하면서 동시에 영구적인 수동 편집 파일처럼 취급하지 마세요.

병합 방식은 보통 앞에 삽입, 뒤에 추가와 필드 덮어쓰기로 나뉩니다. 규칙에는 순서가 있으므로 사용자 지정 규칙을 우선 적용하려면 일반 규칙보다 앞에 삽입해야 합니다. DNS, 포트와 모드 같은 단일 값 필드는 보통 나중에 입력된 값이 앞선 값을 덮어씁니다. 클라이언트마다 덮어쓰기 문법이 완전히 같지는 않으므로 클라이언트를 바꿀 때는 기존 스크립트를 그대로 사용할 수 있다고 가정하지 말고 다시 확인하세요.

prepend-rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - DOMAIN,api.example.net,PROXY

append-rules:
  - MATCH,PROXY

위 구조는 “특정 규칙을 앞에 배치하고 마지막 기본 처리를 유지한다”는 개념을 보여줍니다. 실제 필드 이름은 클라이언트의 덮어쓰기 기능을 기준으로 해야 합니다. 표준 Clash 설정을 직접 편집한다면 규칙을 rules 목록에 넣고 마지막 기본 처리 규칙은 하나만 남겨야 합니다. 여러 MATCH 중에서는 가장 먼저 만나는 항목만 의미가 있습니다.

구독 변환은 어떤 문제를 해결할까

구독 변환은 주로 노드 목록을 클라이언트가 읽을 수 있는 설정으로 정리하거나 규칙 및 정책 그룹 템플릿을 적용하는 데 사용합니다. 이미 만료된 노드를 복구하거나 연결 품질을 높여 주지는 않습니다. 변환 후에는 노드 이름, 정책 그룹과 규칙이 달라질 수 있으므로 업데이트 전에 기존 설정을 보관하세요. 변환 결과 노드 수가 갑자기 줄었다면 링크가 열리는지만 보지 말고 템플릿의 필터 조건, 프로토콜 지원과 노드 이름 정규식을 확인해야 합니다.

가져오기를 완료한 뒤에는 먼저 규칙 모드에서 특정 노드를 선택하고 시스템 프록시를 켠 다음 로그를 관찰하세요. 기본 연결이 정상인지 확인한 후 자동 선택, 복잡한 규칙과 TUN을 활성화합니다. 검증 단계를 나누어야 문제가 발생했을 때 구독 내용, 정책 선택 또는 트래픽 연결 방식 중 원인을 좁힐 수 있습니다.

프록시 모드: Rule, Global과 Direct 중 무엇을 선택할까

Rule 모드는 장기 사용에 적합합니다

Rule 모드는 설정의 규칙을 위에서부터 하나씩 확인해 요청이 어느 정책 그룹으로 갈지 결정합니다. 일반적인 결과는 PROXY, DIRECT, REJECT 또는 사용자 지정 정책 그룹입니다. 장점은 “자동으로 빨라진다”는 것이 아니라 용도에 따라 트래픽의 출구를 나눌 수 있다는 점입니다. 로컬 서비스는 직접 연결하고, 프록시가 필요한 도메인은 프록시 그룹으로 보내며, 광고나 알려진 무효 요청은 거부할 수 있습니다. 규칙을 합리적으로 설계하면 클라이언트 전체를 자주 켜고 끌 필요가 없습니다.

규칙은 위에서 아래로 매칭되며 일치하면 검색을 멈춥니다. 따라서 구체적인 규칙은 포괄적인 규칙보다 앞에 두어야 합니다. 예를 들어 단일 도메인 규칙은 더 넓은 도메인 접미사나 규칙 세트보다 앞에 배치해야 하며, 로컬 네트워크와 예약 주소는 마지막 프록시 기본 규칙보다 먼저 처리하는 것이 일반적입니다. 마지막에는 MATCH를 기본 규칙으로 두어 앞선 규칙에서 식별하지 못한 연결에도 명확한 경로를 지정하세요.

Global 모드는 임시 검증에 사용합니다

Global 모드는 보통 가로챌 수 있는 모든 트래픽을 글로벌 정책 그룹에 전달한 뒤 사용자가 노드나 출구를 선택하게 합니다. “문제가 규칙 때문인지” 판단할 때 유용합니다. Rule 모드에서 특정 사이트가 열리지 않지만 Global로 전환하자 정상적으로 열리면 노드와 트래픽 연결 경로는 대체로 정상입니다. 다음으로 도메인 규칙, IP 규칙과 DNS를 확인해야 하며 클라이언트를 재설치할 필요는 없습니다.

글로벌 모드라고 해서 기기의 모든 패킷이 자동으로 프록시로 들어가는 것은 아닙니다. 트래픽을 가로챌지는 여전히 시스템 프록시 또는 TUN에 달려 있습니다. Global로 전환했지만 어떤 연결 방식도 켜지 않았다면 많은 앱이 직접 연결합니다. 반대로 TUN을 켜고 Direct 모드를 선택하면 트래픽이 코어를 거치더라도 직접 연결로 처리될 수 있습니다. 모드와 트래픽 연결 방식은 분리해서 봐야 합니다.

Direct 모드는 빠른 우회에 사용합니다

Direct 모드는 트래픽을 가능한 한 직접 연결합니다. 프록시 결정을 잠시 중단하거나, 직접 연결과 프록시의 차이를 비교하거나, 클라이언트를 실행한 상태로 로컬 네트워크를 점검할 때 사용할 수 있습니다. 이것이 반드시 클라이언트가 완전히 종료된다는 뜻은 아닙니다. 로컬 포트가 계속 수신 중일 수 있고 TUN이 트래픽을 가로챈 뒤 직접 연결할 수도 있습니다. 원래 네트워크 상태로 완전히 되돌리려면 시스템 프록시와 TUN을 끄고 클라이언트를 종료하세요.

일부 클라이언트에는 Script 같은 확장 모드도 있으며 동작은 스크립트 구현에 따라 달라집니다. 초보 단계에서는 스크립트 모드를 기본 방식으로 사용하지 않는 것이 좋습니다. 스크립트 오류, 실행 환경과 반환값 때문에 문제를 확인할 단계가 늘어나기 때문입니다. 규칙으로 명확하게 표현할 수 있는 로직은 표준 규칙을 우선 사용하세요.

모드 이후 실제 출구를 결정하는 것은 정책 그룹입니다

규칙은 일반적으로 특정 노드를 직접 지정하지 않고 정책 그룹을 가리킵니다. select 그룹은 사용자가 직접 선택하고, url-test는 테스트 결과에 따라 후보 노드를 선택하며, fallback은 사용 가능한 노드를 순서대로 시도합니다. load-balance는 정책에 따라 여러 노드에 연결을 분산합니다. 그룹마다 해결하는 문제가 다르므로 이름에 “자동”이 들어갔다는 이유만으로 우열을 판단해서는 안 됩니다.

자동 테스트는 지정한 테스트 주소와 간격을 사용하며, 해당 주소까지의 연결 상태만 보여 줍니다. 테스트 결과가 좋다고 해서 모든 서비스에 동일하게 접속할 수 있다는 뜻은 아닙니다. 노드 출구 위치, 라우팅, 대상 사이트의 제한과 연결 재사용이 실제 사용감에 영향을 줍니다. 일상적으로는 수동 선택 그룹 하나와 자동 테스트 그룹 하나를 유지하는 것이 좋습니다. 자동 그룹은 일반적인 웹 탐색에 사용하고, 특정 서비스에 문제가 생기면 수동 그룹으로 전환해 확인하세요.

proxy-groups:
  - name: "수동 선택"
    type: select
    proxies:
      - "노드 A"
      - "노드 B"
      - DIRECT

  - name: "자동 선택"
    type: url-test
    proxies:
      - "노드 A"
      - "노드 B"
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 80

interval은 테스트 간격을 초 단위로 나타내며 너무 짧으면 추가 요청이 발생합니다. tolerance는 노드 간 차이가 작을 때 불필요한 전환을 막는 데 사용합니다. 테스트 주소는 안정적으로 가벼운 응답을 반환해야 합니다. 현재 네트워크에서 테스트 주소에 접근할 수 없으면 자동 그룹이 모든 노드를 비정상으로 판단할 수 있으므로 현재 환경에 맞는 테스트 주소로 바꾸세요.

모드를 전환할 때 확인하는 방법

먼저 사용 가능한 것으로 확인된 노드 하나를 고정하고 시스템 프록시 또는 TUN을 켠 다음 Rule과 Global을 각각 테스트하세요. 둘 다 실패하면 로컬 수신, 노드 연결과 DNS를 확인합니다. Global은 성공하지만 Rule이 실패하면 로그에서 매칭된 규칙과 정책 그룹을 확인하세요. 브라우저는 되지만 명령줄이 실패한다면 명령줄 프로그램이 시스템 프록시를 읽는지 확인하고, 필요하면 명시적 프록시 매개변수나 TUN을 사용하세요.

현재 모드를 판단할 때 홈 화면 버튼의 색상만 보지 마세요. 로그에 기록된 규칙 매칭과 출구 이름이 더 정확합니다. 완전한 기록에는 대상 도메인 또는 IP, 매칭 규칙, 정책 그룹과 최종 노드가 포함되어야 합니다. 이 네 가지를 파악하면 “특정 앱이 연결되지 않음”을 점검 가능한 단계로 나눌 수 있고, 모든 스위치를 무작정 전환할 필요가 없습니다.

규칙 분기와 DNS: 요청을 올바른 출구로 보내기

규칙 유형과 매칭 순서

도메인 규칙은 가장 읽기 쉽습니다. DOMAIN은 완전한 도메인만 매칭하고, DOMAIN-SUFFIX는 지정한 접미사와 하위 도메인을 매칭하며, DOMAIN-KEYWORD는 도메인에 포함된 키워드로 매칭합니다. IP 규칙은 대상 주소를 기준으로 판단하며, IP-CIDR, IP-CIDR6와 지리 데이터베이스 규칙이 흔히 사용됩니다. 프로세스 규칙은 프로그램 이름이나 경로에 따라 트래픽을 분기할 수 있지만, 지원 범위와 권한 요구 사항은 운영체제마다 다릅니다. 규칙 세트는 많은 규칙을 별도 파일로 분리해 업데이트와 재사용을 쉽게 합니다.

규칙의 범위가 넓을수록 뒤에 배치해야 합니다. 먼저 DOMAIN-SUFFIX,example.com,PROXY를 작성하고 뒤에 DOMAIN,internal.example.com,DIRECT를 작성하면 내부 도메인은 접미사 규칙에 먼저 매칭되어 뒤의 직접 연결 규칙이 실행되지 않습니다. 구체적인 예외를 일반 규칙보다 앞에 두는 것이 올바른 방법입니다. 마지막에는 MATCH를 기본 규칙으로 사용해 요청이 불명확한 상태로 남지 않게 하세요.

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

no-resolve는 해당 IP 규칙을 매칭할 때 IP를 얻기 위해 추가로 도메인 확인을 수행하지 않는다는 뜻입니다. 이미 대상 IP를 받은 연결이나 IP 규칙이 불필요하게 도메인 확인을 일으키지 않기를 원하는 경우에 적합합니다. 모든 IP 규칙에 이 옵션을 기계적으로 추가해서는 안 됩니다. 도메인 확인 결과가 규칙 판단에 필요하다면 확인을 허용해야 합니다.

규칙 세트, GeoIP와 GeoSite

규칙 세트는 도메인, IP 또는 클래식 규칙을 별도 리소스에 저장하고, 기본 설정에서는 RULE-SET으로 참조합니다. 규칙만 따로 업데이트할 수 있어 매번 전체 구독을 교체할 필요가 없습니다. 사용할 때는 규칙 세트의 동작 유형과 실제 내용이 일치하는지 확인해야 합니다. domain 유형은 도메인 기반 동작만 포함하고, ipcidr 유형은 네트워크 대역에 사용하며, classical 유형은 완전한 규칙 행을 담을 수 있습니다. 유형을 잘못 지정하면 로드에 실패하거나 규칙이 매칭되지 않을 수 있습니다.

GeoIP는 IP 지리 데이터베이스를 기준으로 분류하고, GeoSite는 도메인 목록을 기준으로 분류합니다. 둘 다 로컬 데이터베이스에 의존하므로 데이터베이스를 오랫동안 업데이트하지 않으면 새 도메인이 누락되거나 주소 분류가 부정확해질 수 있습니다. 설정은 정상적으로 파싱되지만 분기가 점점 부정확해진다면 데이터베이스 업데이트 시점과 다운로드 출처를 확인하세요. 구체적인 업데이트 방법은 GeoIP와 GeoSite 데이터베이스 업데이트 가이드를 참고하세요.

DNS가 규칙에 영향을 주는 이유

앱이 도메인에 접속할 때 먼저 직접 이름을 확인한 뒤 프록시에 IP 연결을 요청할 수도 있고, 도메인을 그대로 프록시에 전달할 수도 있습니다. 전자의 경우 코어에는 IP만 보일 수 있어 도메인 규칙이 적용되기 어렵습니다. 후자의 경우 코어가 도메인 정보를 유지하므로 도메인 규칙에 따라 분기할 수 있습니다. 시스템 프록시, SOCKS, TUN, 브라우저의 보안 DNS와 앱 내장 확인 방식이 이 경로를 바꿀 수 있습니다.

DNS 설정에는 일반적으로 수신 주소, IPv6, 향상된 모드, 기본 확인 서버와 주요 nameserver가 포함됩니다. 기본 확인 서버는 다른 DNS 서버 자체의 도메인을 확인하는 데 사용하므로 현재 네트워크에서 직접 접근할 수 있는 주소를 선택해야 합니다. “DNS에 접근하려면 먼저 프록시가 필요하지만 프록시 노드 도메인도 먼저 확인해야 하는” 순환이 생기지 않도록 주의하세요. 주요 nameserver는 일반 조회를 담당하며 네트워크 환경에 따라 UDP, TCP, DoH 또는 DoT를 지원하는 서비스를 선택할 수 있습니다.

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

이 설정은 필드 간 관계를 보여 주기 위한 예시이며 모든 네트워크 환경에서 그대로 복사해 사용하라는 뜻은 아닙니다. 0.0.0.0에서 수신하면 모든 로컬 인터페이스가 해당 포트에 접근할 수 있으므로 신뢰할 수 없는 네트워크에 연결된 기기라면 방화벽을 함께 사용하거나 로컬 주소로 제한하세요. IPv6를 끄면 Clash DNS가 IPv6 결과를 반환하지 않지만, 시스템과 다른 앱이 IPv6 요청을 계속 보낼지는 트래픽 연결 방식과 시스템 네트워크에 따라 달라집니다.

Fake-IP와 Redir-Host의 차이

Fake-IP 모드는 먼저 앱에 예약 주소를 반환하고, 코어가 이 주소와 원래 도메인의 매핑을 관리합니다. 앱이 예약 주소에 연결하면 코어는 원래 도메인을 알고 있으므로 도메인 규칙을 더 일찍 판단할 수 있고 일부 중복 확인도 줄일 수 있습니다. 예약 주소는 대상 사이트의 실제 주소가 아니라 로컬 매핑 과정에서만 사용됩니다. 자세한 원리와 필터 방법은 Clash Fake-IP 모드 설명을 참고하세요.

일부 로컬 네트워크 검색, 프린터, 게임, 시간 동기화 또는 실제 IP 반환값에 의존하는 앱은 Fake-IP와 맞지 않으므로 fake-ip-filter에 추가할 수 있습니다. 필터에 범위가 넓은 도메인을 한꺼번에 많이 넣으면 Fake-IP의 도메인 매핑 장점이 약해질 수 있습니다. 특정 앱에 문제가 생기면 먼저 로그에서 도메인을 확인한 뒤 최소 범위의 필터를 추가하고 다시 테스트하세요.

Redir-Host는 실제 주소를 먼저 확인한 다음 연결을 처리하는 방식에 가까워 실제 DNS 결과에 의존하는 일부 프로그램과 호환성이 좋지만, DNS 경로 품질의 영향을 더 많이 받을 수 있습니다. 두 모드 중 절대적으로 우수한 방식은 없습니다. 데스크톱에서 일상적으로 사용할 때는 우선 클라이언트 기본값을 유지하세요. 로컬 네트워크 기기 검색 실패, 특정 앱 로그인 오류 또는 도메인 규칙 누락이 발생할 때 로그를 바탕으로 조정하면 됩니다.

규칙이 매칭되지 않을 때 확인하는 방법

첫 단계는 연결 로그에 도메인과 IP 중 무엇이 표시되는지 확인하는 것입니다. IP만 보인다면 도메인 규칙이 매칭되지 않을 수 있으므로 앱의 이름 확인 방식, TUN 스니핑과 DNS 연결을 점검해야 합니다. 두 번째로 대상 규칙이 더 포괄적인 규칙보다 앞에 있는지 확인합니다. 세 번째로 규칙이 가리키는 정책 그룹 이름이 대소문자, 공백과 기호까지 완전히 일치하는지 확인합니다. 네 번째로 규칙 세트가 정상적으로 다운로드되었고 동작 유형이 맞는지 확인합니다. 데이터베이스와 캐시는 마지막에 살펴보세요.

수정 후에는 설정을 다시 로드하고 새 연결을 만들어 테스트해야 합니다. 기존 연결은 이전 출구를 계속 재사용할 수 있어 웹페이지를 새로고침해도 새 연결이 만들어지지 않을 수 있습니다. 해당 앱을 종료하거나 연결 기록을 정리하고 연결이 종료될 때까지 기다린 뒤 다시 시도하세요. 규칙 순서, DNS 모드와 TUN 매개변수를 동시에 변경하지 마세요. 정상으로 돌아와도 무엇이 실제로 효과가 있었는지 알 수 없게 됩니다.

TUN 모드: 시스템 프록시를 읽지 않는 트래픽도 연결하기

TUN이 필요한 경우

시스템 프록시는 운영체제의 프록시 설정을 적극적으로 읽는 프로그램에만 적용됩니다. 브라우저는 대체로 잘 지원하지만, 명령줄 도구, 게임 런처, 일부 데스크톱 앱, 컨테이너와 자체 네트워크 스택을 사용하는 소프트웨어는 이를 무시할 수 있습니다. TUN 모드는 가상 네트워크 인터페이스를 만들고 시스템 라우팅을 통해 더 넓은 범위의 IP 트래픽을 코어로 전달하므로 시스템 프록시가 포함하지 못하는 앱을 처리할 때 적합합니다.

TUN은 “더 고급이므로 반드시 켜야 하는” 스위치가 아닙니다. 브라우저와 시스템 프록시를 따르는 앱만 사용한다면 시스템 프록시 방식이 더 단순하고 문제를 확인하기도 쉽습니다. 시스템 프록시로 연결되지 않는 프로그램이 명확히 있거나 UDP, 명령줄과 여러 앱을 한꺼번에 처리해야 할 때 TUN을 활성화하세요. TUN은 가상 인터페이스, 라우팅, DNS 가로채기와 권한이라는 추가 요소를 도입하므로 잘못 설정하면 다른 VPN, 가상 머신 네트워크와 보안 소프트웨어가 충돌하기 쉽습니다.

핵심 매개변수 이해하기

enable은 TUN 활성화 여부를 제어합니다. stack은 사용자 영역과 시스템 네트워크 스택 사이에서 패킷을 처리하는 방식을 정하며, 일반적인 값으로 system, gVisor와 mixed가 있습니다. 구체적인 지원 여부는 현재 코어와 클라이언트에 따라 다릅니다. auto-route는 라우팅을 자동으로 기록하고, auto-detect-interface는 기본 출구 인터페이스를 찾으며, dns-hijack은 지정한 DNS 요청을 Clash가 처리하도록 전달합니다. 그래픽 클라이언트의 스위치는 보통 이러한 필드를 생성하거나 덮어씁니다.

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

mixed는 보통 여러 트래픽 처리 경로를 함께 사용하지만 모든 기기에서 반드시 선택해야 하는 것은 아닙니다. 클라이언트에 stack 선택 항목이 있다면 먼저 기본값을 사용하세요. strict-route는 라우팅 누수를 더 엄격하게 제한하지만 일부 시스템에서 로컬 네트워크, 핫스팟 또는 가상 네트워크에 영향을 줄 수 있습니다. 처음 활성화할 때는 꺼 둔 상태로 기본 트래픽을 확인한 뒤 필요에 따라 테스트하는 것이 좋습니다.

데스크톱 시스템에서 활성화하기

다른 VPN과 기존 클라이언트의 TUN을 먼저 끄고 현재 클라이언트만 실행 상태로 유지하세요. 시스템 프록시 모드에서 사용 가능한 것으로 확인한 설정을 가져오고, 사용 가능한 노드 하나를 고정한 뒤 TUN을 켭니다. 시스템에서 관리자 권한을 요청하면 승인하고, 클라이언트에 코어 실행, 가상 인터페이스 생성과 라우팅 기록이 성공으로 표시되는지 확인하세요. 이때 시스템 프록시를 잠시 끄고 원래 시스템 프록시를 읽지 않는 명령줄 도구로 테스트하면 트래픽이 실제로 TUN을 통해 들어오는지 확인할 수 있습니다.

Windows에서 TUN을 켠 뒤 인터넷이 완전히 끊기면 먼저 TUN을 끄고 남아 있는 다른 가상 인터페이스, 타사 VPN, Hyper-V 또는 보안 소프트웨어의 네트워크 필터를 확인하세요. 다시 켜기 전에 클라이언트를 재시작하고 자동 라우팅을 복원해 볼 수 있습니다. macOS는 네트워크 확장 또는 VPN 구성 승인 여부를 확인해야 하며, 권한이 거부되면 스위치가 즉시 꺼질 수 있습니다. Linux는 TUN 장치 생성과 라우팅 수정 권한이 필요하고, 서비스 프로세스에도 설정을 읽고 실행 디렉터리에 기록할 권한이 있어야 합니다.

curl https://example.com/
curl --noproxy "*" https://example.com/

TUN이 올바르게 트래픽을 가로채고 있다면 두 번째 명령이 curl에 기존 프록시 환경 변수를 사용하지 말라고 지시하더라도 시스템 라우팅을 통해 TUN으로 들어갈 수 있습니다. 이 테스트는 “프로그램이 HTTP 프록시를 읽은 것인지”와 “트래픽이 가상 인터페이스에 의해 연결된 것인지”를 구분하는 데 도움이 됩니다. 테스트할 때는 Clash 로그에 해당 연결이 나타나는지도 확인해야 하며, 웹페이지 결과만으로 판단해서는 안 됩니다.

DNS 가로채기와 Fake-IP 조합

TUN이 IP 트래픽을 가로챈 뒤에도 DNS가 앱에서 로컬 네트워크의 확인 서버로 직접 전송되면 코어에는 확인된 IP만 보일 수 있고 도메인 규칙과 Fake-IP 매핑이 영향을 받습니다. dns-hijack은 일반적인 DNS 요청을 Clash DNS로 전달합니다. 최신 브라우저와 일부 앱은 암호화된 DNS를 사용할 수 있어 일반적인 53번 포트 가로채기만으로는 이러한 요청을 읽을 수 없습니다. 앱에서 독립 보안 DNS를 끄거나 해당 연결 자체가 규칙에 따라 올바르게 처리되도록 해야 합니다.

DNS 가로채기를 활성화한 뒤 로컬 네트워크 도메인이 확인되지 않으면 라우터 DNS가 처리해야 하는 로컬 도메인인지 확인하고 nameserver-policy 또는 적절한 대체 경로를 설정하세요. 프린터, NAS와 회사 내부 도메인은 특정 네트워크의 DNS에만 존재하는 경우가 많아 공용 확인 서버가 응답할 수 없습니다. 모든 DNS를 다시 직접 연결로 돌리기보다 해당 도메인을 올바른 로컬 확인 서버로 보내는 것이 해결 방법입니다.

로컬 네트워크, 가상 머신과 컨테이너의 경계

TUN이 라우팅을 수정하면 로컬 네트워크 접근도 코어를 거칠 수 있습니다. 설정에는 사설 네트워크 대역을 직접 연결하는 규칙을 남겨 두고 IPv6 로컬 주소에도 주의하세요. 다른 기기가 이 컴퓨터의 프록시를 사용해야 한다면 allow-lan을 별도로 켜고 적절한 인터페이스에서 수신하도록 설정한 뒤 방화벽을 구성해야 합니다. 이는 본체의 TUN과는 별개의 문제입니다. 본체 트래픽을 연결하기 위해 프록시 포트를 모든 네트워크에 함부로 노출하지 마세요.

가상 머신과 컨테이너는 자체 가상 인터페이스와 네트워크 대역을 사용합니다. TUN 자동 라우팅이 Docker, 가상 머신 브리지, WSL 또는 기업 VPN의 라우팅을 덮어쓸 수 있습니다. 문제가 가상 환경에서만 발생한다면 TUN을 켜기 전후의 라우팅 테이블을 비교하고 대상 네트워크를 어느 인터페이스가 담당하는지 확인하세요. 필요하면 모든 규칙을 끄기보다 가상 네트워크 대역을 제외 라우팅 또는 직접 연결 규칙에 추가합니다.

TUN 실패 시 고정된 확인 순서

먼저 같은 노드가 시스템 프록시에서 작동하는지 확인해 노드 문제를 제외합니다. 다음으로 TUN 스위치가 실제로 켜진 상태인지, 가상 인터페이스가 생성되었는지 확인합니다. 그다음 자동 라우팅과 기본 인터페이스 인식을 확인하고, DNS가 연결되었는지와 로그에 요청이 나타나는지 살펴봅니다. 마지막으로 다른 VPN, 보안 소프트웨어, 가상 인터페이스와 방화벽을 점검하세요. 각 단계에서는 한 번에 하나만 바꾸고 수정 후 새 연결을 만들어야 합니다.

시스템 프록시는 정상인데 TUN만 작동하지 않는다면 구독을 다시 가져올 필요가 없는 경우가 많습니다. 권한, 라우팅, DNS와 네트워크 충돌에 집중하세요. 더 자세한 작동 원리, stack 선택과 플랫폼별 차이는 Clash TUN 모드 활성화 튜토리얼에서 확인할 수 있습니다.

일상적인 관리와 고급 설정: 복구 가능한 설정 유지하기

안정적인 일상 점검 주기 만들기

Clash가 정상적으로 작동한다면 자주 조정할 필요가 없습니다. 일상적으로는 구독 업데이트 가능 여부, 자주 사용하는 정책 그룹에 사용 가능한 노드가 있는지, 규칙과 지리 데이터베이스가 너무 오래되지 않았는지, 클라이언트 업데이트 후 핵심 설정이 유지되었는지만 확인하면 됩니다. 구독은 하루 한 번 또는 서비스 제공자가 권장하는 주기로 업데이트하세요. 규칙 세트와 데이터베이스는 실제 변경 주기에 맞추면 됩니다. 자동 테스트와 구독 새로고침을 지나치게 자주 실행하면 요청이 늘고 노드 선택이 계속 바뀔 수 있습니다.

클라이언트를 실행한 뒤 설정이 기본값으로 돌아갔다면 설정을 전환했는지, 휴대용 디렉터리를 사용하는지, 설정 디렉터리에 쓰기 권한이 있는지 먼저 확인하세요. 시스템 업데이트 후 TUN 권한이 사라졌다면 네트워크 확장 또는 가상 인터페이스 승인을 다시 확인합니다. 절전 모드에서 깨어난 뒤 잠시 연결이 끊긴 경우에는 네트워크 인터페이스가 복구될 때까지 기다렸다가 코어를 다시 연결하세요. 매번 자동 복구되지 않는다면 기본 인터페이스 인식과 클라이언트의 백그라운드 동작을 점검합니다.

가장 가치 있게 백업할 항목

구독 주소 목록, 사용자 지정 규칙, 덮어쓰기 스크립트, DNS 변경 사항과 독립적인 로컬 설정을 우선 백업하세요. 캐시 데이터베이스, 임시 연결 기록과 일반 실행 로그는 보통 장기 보관할 필요가 없습니다. 백업 파일에는 구독 매개변수, 노드 인증 정보와 로컬 네트워크 주소가 포함될 수 있으므로 관리되는 위치에 보관하고 공개 코드 저장소에 직접 업로드하지 마세요.

여러 기기에서 동기화할 때는 구독 링크를 중앙에서 배포하는 방식이 관리하기 가장 쉽지만, 기기별 설정까지 억지로 공유해서는 안 됩니다. 데스크톱의 TUN stack, Android 앱별 프록시와 macOS 네트워크 확장은 플랫폼에 따라 다릅니다. 모든 기기에서 노드와 기본 규칙을 공유하고 시스템 관련 필드는 로컬 덮어쓰기 계층에 두세요. 구독, WebDAV와 수동 내보내기 방식의 비교는 Clash 멀티 플랫폼 설정 동기화 방식 비교를 참고하세요.

로그 읽는 방법

로그 수준에는 보통 silent, error, warning, info와 debug가 있습니다. 일상적인 사용에서는 info면 충분합니다. 짧은 시간 동안 문제를 확인할 때만 debug로 바꾸고 재현한 즉시 원래대로 돌려 로그가 빠르게 늘어나는 것을 막으세요. 로그를 읽을 때는 먼저 문제가 발생한 정확한 시간을 찾은 다음 대상 도메인 또는 IP, 매칭 규칙, 정책 그룹, 최종 출구와 오류 유형을 확인합니다. 많은 로그 중 무작위로 오류 하나를 골라 결론을 내리지 마세요.

연결 시간 초과는 일반적으로 요청이 전송되었지만 제때 완료되지 않았다는 뜻이며, 노드, 라우팅, 대상 서비스 또는 네트워크 제한 때문일 수 있습니다. 연결 거부는 대상 주소가 명확히 거부했다는 뜻입니다. DNS 오류는 이름 확인 단계의 실패를 의미하고, TLS 오류는 시스템 시간, 인증서 체인, 도메인 불일치 또는 중간 네트워크와 관련될 수 있습니다. 설정 파싱 오류라면 YAML의 행 번호와 필드로 돌아가야 합니다. 오류가 발생한 계층에 따라 다음에 확인할 대상이 달라집니다.

일반적인 문제 해결 트리: 범위가 가장 작은 곳부터 확인하기

모든 웹사이트가 열리지 않으면 먼저 클라이언트 코어, 로컬 포트, 트래픽 연결 방식과 노드를 확인하세요. 한 사이트만 열리지 않으면 규칙 매칭, DNS, 노드 출구와 사이트 자체의 제한을 먼저 봅니다. 한 앱만 열리지 않으면 시스템 프록시를 읽는지, 독립 DNS 또는 QUIC을 사용하는지 확인하세요. TUN만 작동하지 않으면 권한, 라우팅과 충돌을 점검합니다. 구독 업데이트만 실패한다면 프록시 규칙을 바꾸지 말고 링크 응답과 형식을 바로 확인하세요.

시스템 프록시를 껐는데도 직접 연결로 복구되지 않으면 운영체제의 프록시 설정이 남아 있는지, 환경 변수가 존재하는지, 브라우저에 독립 프록시가 설정되어 있는지 확인하세요. TUN을 껐는데도 이상이 계속되면 가상 인터페이스와 라우팅이 정리되었는지 확인하고, 필요하면 정상적으로 시스템을 재시작해 네트워크 스택을 다시 구성하세요. 출처가 불분명한 “원클릭 네트워크 복구” 스크립트는 사용하지 마세요. DNS, 방화벽과 인터페이스를 동시에 초기화해 중요한 문제 상황 정보를 지울 수 있습니다.

# macOS와 Linux에서 일반적인 프록시 환경 변수 확인
env | grep -i proxy

# 현재 터미널 세션에서 프록시 변수 임시 제거
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY
unset http_proxy https_proxy all_proxy

# 로컬 프록시 포트 테스트
curl -x http://127.0.0.1:7890 https://example.com/

환경 변수는 이를 읽는 프로그램과 현재 세션에만 영향을 줍니다. 그래픽 클라이언트가 시스템 프록시를 수정해도 터미널에 수동으로 설정한 변수까지 자동으로 지워 주지는 않습니다. 반대로 터미널에 HTTPS_PROXY를 설정해도 다른 데스크톱 앱이 이를 사용한다는 뜻은 아닙니다. 각 앱이 어떤 방식으로 트래픽을 연결하는지 파악하는 것이 안정적인 장기 사용의 중요한 습관입니다.

클라이언트 업그레이드와 설정 마이그레이션

업그레이드 전에 클라이언트가 제공하는 변경 사항을 확인하고 설정 디렉터리, 코어 필드 또는 네트워크 확장에 변화가 있는지 점검하세요. 핵심 설정을 먼저 내보낸 뒤 기존 버전을 정상적으로 종료하고 새 버전을 설치합니다. 업그레이드 후에는 설정이 로드되는지, 구독이 업데이트되는지, 시스템 프록시와 TUN 권한이 유지되는지 확인한 다음 복잡한 덮어쓰기를 복원하세요. 업그레이드 당일에 구독, 규칙 템플릿과 DNS 설정까지 동시에 바꾸지 마세요. 변화가 겹치면 문제를 되짚기 어려워집니다.

유지 관리가 중단된 Clash for Windows 또는 ClashX Meta에서 마이그레이션할 때는 전체 데이터베이스를 복사하기보다 원격 구독을 다시 가져오는 것이 좋습니다. 직접 작성한 규칙은 별도로 옮기고 정책 그룹 선택은 새로 확인하세요. 새 클라이언트가 mihomo 코어를 사용하면 일부 확장 필드가 더 다양할 수 있지만, 기존 필드의 호환 여부는 설정 테스트와 로그로 확인해야 합니다.

일상적인 사용에서 고급 설정으로 나아가기

기본 연결을 완료한 뒤에는 의존 관계에 따라 학습을 진행할 수 있습니다. 첫 단계는 연결 로그와 규칙 순서를 읽고 특정 요청이 왜 해당 출구로 갔는지 설명하는 것입니다. 두 번째 단계는 정책 그룹을 익혀 수동 선택, 자동 테스트와 장애 시 대체 동작을 각각 맡기는 것입니다. 세 번째 단계는 DNS, Fake-IP와 규칙 세트를 이해해 도메인 식별과 분기 정확도를 높이는 것입니다. 네 번째 단계에서 TUN, 프로세스 규칙, 로컬 네트워크 공유와 멀티 플랫폼 동기화를 깊이 다루면 됩니다.

서버나 라우터 사용자는 서비스 관리, 설정 디렉터리 권한, 로그 순환, 수신 주소와 방화벽도 익혀야 합니다. 제어 인터페이스나 프록시 포트를 외부에 직접 노출하면 접근 범위가 넓어지므로 제어 포트는 신뢰할 수 있는 인터페이스로 제한하고 적절한 인증을 설정해야 합니다. 설정의 로컬 네트워크 접근 기능은 실제로 필요할 때만 켜고, 시스템 방화벽으로 접근 출처를 제한하세요.

Clash를 제대로 이해했는지는 설정 파일의 길이가 아니라 다음 네 가지 질문에 답할 수 있는지로 판단하세요. 트래픽은 어떻게 코어로 들어오는가? 이 요청은 어떤 규칙에 매칭되었는가? 규칙은 어느 정책 그룹을 가리키는가? 정책 그룹은 최종적으로 어떤 출구를 선택하는가? 이 흐름에 따라 문제를 찾을 수 있다면 클라이언트나 플랫폼을 바꾸고 설정을 조정할 때도 처음부터 다시 헤맬 필요가 없습니다.

이 가이드 다음에 읽을 순서

아직 첫 연결을 완료하지 않았다면 사용 가이드로 돌아가 단계별로 진행하세요. 클라이언트를 바꾸거나 시스템 아키텍처를 확인하려면 다운로드 센터로 이동하세요. 약어와 필드 이름이 낯설다면 용어 가이드를 열어 보세요. 구독 파싱, TUN, Fake-IP, 데이터베이스 업데이트와 멀티 플랫폼 동기화에는 각각 별도의 기술 노트가 있으므로 현재 문제에 맞춰 필요한 부분만 깊이 살펴보면 됩니다. 모든 고급 설정을 한 번에 읽을 필요는 없습니다.

안정적인 설정의 원칙은 간단합니다. 먼저 기본 연결을 확인한 다음 분기하고, 로그를 먼저 본 뒤 매개변수를 바꾸며, 한 번에 하나의 변수만 수정하고, 변경 전 복구 가능한 버전을 보관하세요. 이 순서를 따르면 Clash의 설정 항목이 많아도 각 문제를 명확한 단계로 좁힐 수 있어 복잡하게 얽힌 문제로 남지 않습니다.