Clash 데스크톱
처음부터 고급 설정까지

Clash는 단순한 “스위치”가 아니라 로컬 컴퓨터에서 실행되는 트래픽 처리 체계입니다. 애플리케이션은 먼저 연결을 로컬 리스닝 포트나 가상 네트워크 인터페이스로 전달합니다. Clash의 코어는 대상 도메인, 대상 IP, 네트워크 프로토콜, 프로세스 등의 정보를 읽은 뒤 설정 파일의 규칙을 위에서부터 순서대로 대조하고, 마지막으로 DIRECT, 특정 프록시 그룹 또는 REJECT에 연결을 넘깁니다. 이 경로를 이해하는 것이 클라이언트 화면의 버튼을 외우는 것보다 중요합니다. 시스템 프록시를 켰는데도 특정 프로그램이 직접 연결되거나, 노드는 테스트를 통과했지만 웹페이지에 접속할 수 없거나, 규칙 모드와 전역 모드의 결과가 다른 경우에도 대개 이 경로의 어느 한 단계에서 원인을 찾을 수 있습니다.

클라이언트, 코어와 설정 파일

데스크톱 클라이언트는 화면, 설정 관리, 시스템 프록시 전환, 로그 표시와 업데이트 등을 담당합니다. Mihomo 같은 호환 코어는 실제 포트 리스닝, 규칙 해석과 연결 전달을 담당하며, YAML 설정 파일은 포트, DNS, 프록시 노드, 프록시 그룹과 규칙을 정의합니다. 세 요소는 분리해서 이해해야 합니다. 클라이언트를 바꿔도 설정 문법이 반드시 달라지는 것은 아니며, 같은 설정을 사용할 수 있는지는 주로 코어가 지원하는 필드와 클라이언트의 가져오기 방식에 좌우됩니다. 클라이언트가 정상적으로 시작되었다고 해서 구독 내용, DNS 또는 시스템 프록시까지 올바르게 설정되었다는 뜻은 아닙니다.

일반적인 로컬 포트에는 HTTP 프록시 포트, SOCKS5 포트, 두 프로토콜을 모두 받는 mixed-port가 있습니다. 데스크톱 클라이언트는 보통 이 값을 자동으로 관리합니다. 예를 들어 mixed-port: 7890으로 설정했다면 브라우저나 터미널의 프록시 주소를 127.0.0.1:7890으로 지정해야 연결이 코어로 들어갑니다. external-controller는 제어 인터페이스로, 클라이언트 화면에서 연결 정보를 읽거나 프록시 그룹을 전환하고 설정을 불러올 때 사용합니다. 프록시 포트와 혼동해서는 안 됩니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: true
external-controller: 127.0.0.1:9090

시스템 프록시와 TUN의 경계

시스템 프록시는 운영체제가 애플리케이션에 제공하는 HTTP 또는 SOCKS 프록시 설정입니다. 브라우저와 대부분의 데스크톱 소프트웨어는 이를 읽지만, 터미널 명령, 게임, 일부 스토어 앱, 가상 머신과 자체 네트워크 스택을 사용하는 프로그램은 무시할 수 있습니다. TUN 모드는 더 낮은 계층에서 IP 트래픽을 가로채는 가상 네트워크 인터페이스를 만들어 보통 더 넓은 범위를 처리합니다. 두 기능은 속도 단계가 아니며 반드시 함께 켜야 하는 것도 아닙니다. 일상적인 웹 브라우징에는 시스템 프록시를 우선 사용하고, 시스템 프록시를 읽지 않는 것이 분명한 앱에 한해 TUN이 필요한지 검토하세요.

도메인, DNS와 규칙 대조

사용자가 도메인을 입력하면 DNS가 먼저 이름을 IP로 변환합니다. 규칙 엔진은 해석 전에 도메인으로 대조할 수도 있고, IP를 얻은 뒤 GEOIP 또는 IP-CIDR 규칙을 계속 적용할 수도 있습니다. DNS 요청이 잘못된 네트워크 경로를 사용하면 웹페이지가 열리지 않거나, 규칙 적중 결과가 예상과 다르거나, 로컬 네트워크 도메인이 작동하지 않을 수 있습니다. “노드는 정상인데 웹사이트가 열리지 않는다”는 문제는 프록시 노드 자체가 아니라 도메인 해석, IPv6, 브라우저 보안 DNS 또는 규칙 순서의 문제인 경우가 많습니다.

로그와 연결 페이지는 이 처리 경로를 살펴보는 두 가지 진입점입니다. 로그에서는 설정 로드 여부, 포트 사용 여부와 DNS 오류를 확인할 수 있고, 연결 페이지에서는 어떤 앱이 세션을 만들었는지, 대상이 무엇인지, 어떤 규칙이 적중했는지, 최종적으로 어떤 정책을 사용했는지 볼 수 있습니다. 클라이언트를 처음 사용할 때는 클라이언트 화면 빠르게 보기를 함께 참고해 프록시, 설정, 연결과 로그 페이지의 역할을 익혀 보세요. 이 개념을 잡아 두면 이후 설치, 구독과 규칙 설정이 단순한 클릭 작업으로 느껴지지 않습니다.

데스크톱에서 선택할 수 있는 클라이언트로는 Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu, Clash for Windows와 ClashX Meta가 있으며, 모바일에는 Clash Meta for Android와 Surfboard도 있습니다. 이 사이트의 다운로드 목록에서는 모든 플랫폼을 지원하는 Clash Plus를 우선 추천합니다. Windows, macOS, Android와 iOS에서 비슷한 사용 흐름을 유지하려는 사용자에게 적합하기 때문입니다. 커뮤니티 기반 데스크톱 클라이언트를 선호한다면 Clash Verge Rev, FlClash와 Nyanpasu를 비교해 보세요. Clash for Windows와 ClashX Meta는 유지 관리가 중단되었으므로 기존 환경이나 이전 설정을 처리할 때만 사용하고, 새 설치의 기본 선택으로는 권장하지 않습니다.

Windows: 아키텍처, 설치 경로와 루프백 제한

대부분의 Windows 컴퓨터는 x64 설치 패키지를 사용합니다. ARM 기기는 클라이언트가 명시적으로 제공하는 ARM 패키지를 선택해야 하며, 시스템 화면이 비슷하다는 이유만으로 서로 바꿔 사용할 수 없습니다. 설치가 끝나면 먼저 클라이언트를 정상적으로 실행해 트레이 아이콘, 설정 페이지와 로그 페이지가 열리는지 확인한 다음 구독을 가져오세요. 시스템에서 인터넷에서 받은 앱의 실행 여부를 묻는다면 다운로드 경로와 파일명을 확인한 뒤 운영체제의 절차에 따라 처리하세요. 한 번의 경고를 피하려고 보안 기능 전체를 끄지는 마세요.

시스템 프록시를 켜면 기존 데스크톱 브라우저는 대개 바로 사용할 수 있습니다. 일부 UWP 앱은 Windows의 루프백 격리로 인해 로컬 프록시 포트에 접근하지 못합니다. 이 경우 클라이언트가 제공하는 UWP 루프백 도구를 사용해 실제로 프록시가 필요한 앱을 예외 목록에 추가한 뒤 대상 앱을 다시 시작하세요. 루프백 설정은 “앱이 로컬 프록시에 연결하지 못하는” 문제를 해결할 뿐, 만료된 구독, 잘못된 노드 또는 DNS 설정을 고쳐 주지는 않습니다. 플랫폼별 전체 절차와 자주 발생하는 문제는 Windows에서 Clash 설치하기를 참고하세요.

macOS: 칩 아키텍처와 네트워크 권한

“이 Mac에 관하여”에서 프로세서가 Apple Silicon인지 Intel인지 확인한 뒤 해당 설치 패키지를 선택하세요. 아키텍처가 맞지 않으면 앱이 시작되지 않거나 별도의 호환 계층이 필요할 수 있습니다. 시스템 프록시, 서비스 모드 또는 TUN을 처음 켤 때 macOS에서 관리자 인증과 네트워크 확장 승인을 요구할 수 있습니다. 권한은 시스템 대화상자의 안내에 따라 승인하면 됩니다. 클라이언트를 응용 프로그램 폴더 밖으로 옮긴 뒤 계속 실행하면 로그인 시 시작 항목과 보조 서비스 경로가 작동하지 않을 수 있으니 피하세요.

Linux: 패키지 형식과 데스크톱 세션

Debian, Ubuntu와 파생 배포판은 보통 DEB를 사용하고, Fedora와 RHEL 계열 배포판은 보통 RPM을 사용합니다. 설치 후 메뉴 항목이 바로 나타나지 않으면 데스크톱 세션을 종료했다가 다시 로그인하거나, 터미널에서 한 번 실행해 구체적인 오류를 확인하세요. Linux 데스크톱 환경은 시스템 프록시를 구현하는 방식이 서로 완전히 같지 않습니다. 브라우저는 GNOME 또는 KDE 프록시 설정을 읽을 수 있지만, 터미널 도구는 보통 환경 변수를 사용합니다. 전체 트래픽을 가로채야 할 때만 TUN을 설정하고, 먼저 가상 네트워크 인터페이스를 만들고 라우팅을 수정할 권한이 있는지 확인하세요.

# Debian / Ubuntu 로컬 DEB 패키지 설치
sudo apt install ./client-package.deb

# 자주 사용하는 포트가 이미 사용 중인지 확인
ss -lntp | grep -E '7890|9090'

아직 클라이언트를 비교 중이라면 Clash Plus, Verge Rev와 FlClash 비교를 확인해 보세요. 선택할 때는 화면 요소의 수보다 현재 시스템 지원 여부, TUN 구현, 설정 호환성과 업데이트 상태를 우선 고려하세요. 선택을 마쳤다면 다운로드 센터에서 해당 플랫폼으로 이동해 설치 패키지와 설정 안내를 서로 다른 출처에서 섞어 사용하지 않도록 하세요.

Clash 설정은 보통 YAML 파일로 존재합니다. 완전한 설정에는 프록시 노드뿐 아니라 프록시 그룹, 규칙, DNS, TUN과 리스닝 포트가 포함될 수 있습니다. 구독 링크는 설정을 가져오는 원격 출처이며, 클라이언트는 링크에서 내용을 다운로드해 로컬 설정으로 저장합니다. 가져오기가 끝난 뒤 코어가 실제로 읽는 것은 로컬 사본입니다. 구독을 업데이트하면 원격 내용을 다시 받아오므로 구독에서 생성된 설정을 직접 수정하면 다음 업데이트 때 덮어써질 수 있습니다.

먼저 현재 가진 콘텐츠의 종류 확인하기

브라우저 주소창에 입력해 가져올 수 있는 구독 URL, 인코딩 문자열이 길게 이어지는 범용 구독, proxies:, proxy-groups:, rules:가 포함된 YAML 파일은 서로 다른 전달 형식입니다. 클라이언트에서 형식 오류가 표시되면 가져오기 버튼을 계속 누르기보다 링크가 실제로 반환하는 콘텐츠부터 확인하세요. 서버가 로그인 페이지, 만료 안내 또는 일반적인 Base64 노드 목록을 반환하면 클라이언트가 이를 저장할 수는 있어도 완전한 Clash 설정으로 불러오지 못할 수 있습니다.

유효한 YAML은 들여쓰기에 민감하므로 탭이 아닌 공백을 사용해야 합니다. 같은 수준의 필드는 동일한 들여쓰기를 유지하고, 목록 항목은 하이픈으로 시작하세요. 콜론, 샵 또는 특수 문자가 포함된 이름은 따옴표로 감싸는 것이 좋습니다. 브라우저에서 복사할 때는 전각 문장 부호와 스마트 따옴표도 피해야 합니다. YAML, Base64와 형식 변환의 차이는 Clash 구독 형식과 변환 방법에서 이어서 확인할 수 있습니다.

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

proxy-groups:
  - name: "노드 선택"
    type: select
    proxies:
      - "자동 선택"
      - DIRECT

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

rules:
  - DOMAIN-SUFFIX,example.com,노드 선택
  - GEOIP,CN,DIRECT
  - MATCH,노드 선택

가져오기, 활성화와 업데이트는 서로 다른 작업입니다

가져오기는 구독이나 파일을 클라이언트의 설정 목록에 추가하는 작업이고, 활성화는 그중 하나를 선택해 코어에 실행시키는 작업이며, 업데이트는 원격 콘텐츠를 다시 가져오는 작업입니다. 먼저 설정 페이지에 구독 주소를 붙여 넣고 다운로드가 끝났는지 확인한 뒤 해당 설정을 선택하세요. 그런 다음 프록시 페이지에서 프록시 그룹 정책을 선택하고 마지막으로 시스템 프록시를 켭니다. 설정 목록에 파일이 여러 개 있다면 현재 활성화된 항목을 분명히 확인하세요. A 설정을 수정했지만 실제로는 B 설정이 실행되는 상황을 피할 수 있습니다.

구독 업데이트가 실패하면 HTTP 요청 흐름을 따라 점검하세요. 먼저 링크가 만료되지 않았고 현재 네트워크에서 접근 가능한지 확인합니다. 다음으로 시스템 시간을 확인하세요. 시간 오차로 TLS 연결이 실패할 수 있습니다. 그다음 클라이언트 로그에서 상태 코드나 해석 오류를 확인합니다. 401, 403 응답은 대개 인증이나 링크 상태와 관련 있고, HTML이 반환되면 주소가 설정 콘텐츠가 아니라 웹페이지를 가리킬 가능성이 큽니다. 해석 오류라면 YAML 구조와 클라이언트 코어의 호환성을 집중적으로 확인하세요. 전체 구독 링크를 포럼이나 스크린샷에 공개하지 마세요. 링크 자체에 접근 자격 증명이 포함될 수 있습니다.

덮어쓰기 위험과 로컬 확장

사용자 지정 규칙을 추가해야 한다면 클라이언트에서 제공하는 오버라이드, 설정 병합, 스크립트 확장 또는 규칙 세트 기능을 우선 사용하세요. 그러면 서비스 제공자가 관리하는 노드 부분과 로컬 규칙을 분리할 수 있습니다. 클라이언트가 병합을 지원하지 않는다면 구독 설정을 로컬 파일로 복사해 사본을 수정하고, 업데이트와 대조를 위해 원본 구독은 보존하세요. 업데이트 후 노드와 프록시 그룹의 변경 사항을 로컬 사본에 다시 병합하는 편이 자동 업데이트 파일을 직접 편집하는 것보다 복구하기 쉽습니다.

설정 로드에 실패하면 로그의 줄 번호가 파서가 문제를 발견한 위치를 가리키는 경우가 많지만, 실제 들여쓰기 오류는 그보다 몇 줄 앞에 있을 수 있습니다. 오류가 난 줄에서 위로 올라가 같은 수준의 필드, 따옴표 닫힘과 목록 들여쓰기를 확인하세요. 설정은 로드되지만 프록시 그룹이 비어 있다면 proxy-groups가 참조하는 노드명이 proxies와 완전히 일치하는지 확인합니다. 노드는 존재하지만 선택할 수 없다면 그룹 유형, provider 참조 또는 구독 변환 결과가 완전한지 점검하세요. “다운로드 실패, 해석 실패, 실행 실패”를 구분해 기록하면 문제를 더 직접적으로 좁힐 수 있습니다.

Clash 클라이언트의 일반적인 Rule, Global과 Direct 모드는 코어가 최종 정책을 결정하는 방식을 제어합니다. 애플리케이션이 트래픽을 Clash로 전달하는지 여부를 바꾸거나 사용할 수 없는 노드를 자동으로 고쳐 주지는 않습니다. 시스템 프록시가 꺼져 있으면 Global로 전환해도 로컬 프록시 포트에 들어오지 않은 브라우저 연결은 코어를 거치지 않습니다. TUN이 트래픽을 가로채는 상태라면 전환한 모드는 가로채진 연결에만 적용됩니다. 따라서 모드 선택은 전체 트래픽 경로 안에서 이해해야 합니다.

Rule: 규칙을 순서대로 결정

Rule은 일상 사용에 적합한 기본 선택입니다. 코어는 규칙 목록의 맨 위부터 대조하며, 일치하는 규칙을 찾으면 아래 규칙은 더 이상 확인하지 않습니다. 일반적으로 로컬 네트워크와 명시적인 직접 연결 도메인은 DIRECT로 보내고, 프록시가 필요한 도메인은 프록시 그룹으로 보내며, 광고나 연결을 원하지 않는 대상은 REJECT로 처리합니다. 나머지 트래픽은 마지막 MATCH가 처리합니다. 규칙 모드의 장점은 모든 트래픽을 같은 출구로 보내는 것이 아니라 접근 범위, 네트워크 경로와 로컬 서비스 호환성을 함께 유지하는 데 있습니다.

Global: 전체 그룹으로 선택 집중

Global 모드는 보통 코어에 들어온 모든 연결을 전역 프록시 그룹으로 보냅니다. “문제가 규칙에서 비롯되었는가”를 임시로 확인할 때 유용합니다. 예를 들어 Rule에서는 실패하지만 Global에서는 성공한다면 노드와 기본 프록시 경로는 정상일 가능성이 높으므로 규칙 적중, DNS 또는 프록시 그룹 선택을 확인해야 합니다. 두 모드 모두 실패한다면 노드, 포트, 시스템 프록시와 도메인 해석을 우선 점검하세요. Global을 잘못된 규칙을 가리는 방법으로 장기간 사용하지는 마세요. 로컬 서비스, LAN 장치와 프록시가 필요 없는 연결까지 프록시로 전송될 수 있습니다.

Direct: 가로챈 트래픽을 직접 연결

Direct 모드는 코어에 들어온 연결을 대상에 직접 연결합니다. 클라이언트의 트래픽 가로채기 자체가 영향을 주는지 판단하거나, 프록시를 잠시 비활성화하면서 코어는 계속 실행할 때 사용할 수 있습니다. 하지만 Direct가 클라이언트를 완전히 종료한다는 뜻은 아닙니다. 로컬 포트, TUN, DNS 모듈과 연결 기록은 계속 작동할 수 있습니다. 운영체제의 원래 네트워크 경로로 되돌리려면 시스템 프록시 또는 TUN을 끄고 코어를 종료한 다음 운영체제의 프록시 설정이 복원되었는지 확인하세요.

실제 출구에 더 가까운 것은 모드보다 프록시 그룹입니다

모드는 “어디에서 정책을 찾을지”를 정하고, 실제로 어떤 노드나 하위 그룹을 사용할지는 프록시 그룹이 결정합니다. select 그룹은 사용자가 직접 선택하고, url-test는 지정한 테스트 주소를 주기적으로 측정해 사용 가능한 후보를 선택하며, fallback은 순서대로 사용 가능한 노드를 선택합니다. load-balance는 구현과 정책에 따라 연결을 분산합니다. 테스트 결과는 테스트 주소에 연결할 수 있는지만 보여 줄 뿐 모든 웹사이트의 체감 품질이나 지속적인 대역폭을 의미하지는 않습니다.

노드를 전환해도 이미 연결된 TCP, QUIC 또는 장시간 연결이 반드시 새 노드로 이동하는 것은 아닙니다. 브라우저가 기존 연결을 재사용하거나 앱이 DNS 캐시를 유지할 수도 있습니다. 전환 결과를 확인하려면 연결 페이지에서 관련 세션을 닫고 대상 앱을 다시 연 뒤, 필요하다면 기존 연결이 해제될 때까지 기다리세요. 규칙이 대상을 다른 프록시 그룹으로 보내고 있다면 현재 그룹을 전환해도 결과가 바뀌지 않습니다. 따라서 프록시 페이지의 강조 표시만 보지 말고 먼저 연결 페이지에서 규칙과 경로를 확인해야 합니다.

모드 전환은 무작정 시도하기 위한 것이 아니라 원인을 판단하기 위한 수단이어야 합니다. 전환할 때마다 대상 도메인, 적중 규칙, 실제 정책과 연결 결과를 기록하면 규칙 문제와 경로 문제를 빠르게 구분할 수 있습니다. 일상적인 상태는 Rule로 되돌리고 사용자 지정 규칙으로 일부 예외를 조정하는 편이 Global을 장기간 사용하는 것보다 관리하기 쉽습니다.

규칙 목록은 위에서 아래 순서로 실행되며, 처음 일치한 규칙이 연결 정책을 결정합니다. 규칙 시스템은 여러 조건의 종합 점수로 판단하지 않으며 “더 구체적인” 규칙을 자동으로 선택하지도 않습니다. 앞부분에 이미 포괄적인 DOMAIN-SUFFIX, GEOIP 또는 IP-CIDR가 있다면 뒤에 작성한 예외 규칙은 실행될 기회를 영원히 얻지 못할 수 있습니다. 규칙은 “정확한 예외를 앞에, 포괄적인 분류를 중간에, 최종 대체 규칙을 뒤에” 두는 구조로 설계하세요.

자주 사용하는 규칙 유형

DOMAIN은 전체 도메인을 정확히 대조합니다. 예를 들어 api.example.com만 일치시킵니다. DOMAIN-SUFFIX는 지정한 도메인과 하위 도메인을 대조하므로 사이트 체계별 분기에 적합합니다. DOMAIN-KEYWORD는 도메인에 포함된 문자열로 대조해 범위가 넓고 오탐이 발생하기 쉽습니다. IP-CIDR와 IP-CIDR6는 각각 IPv4와 IPv6 네트워크 대역을 대조합니다. GEOIP는 IP 지리 데이터베이스에 따라 분류하고, PROCESS-NAME은 프로세스명으로 대조하지만 운영체제, 권한과 코어 지원 여부에 따라 사용할 수 있습니다. MATCH는 앞에서 일치하지 않은 나머지 연결을 처리합니다.

rules:
  - DOMAIN,printer.lan,DIRECT
  - DOMAIN-SUFFIX,example.org,노드 선택
  - DOMAIN-KEYWORD,example,노드 선택
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR6,fd00::/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,노드 선택

no-resolve는 IP 유형 규칙을 실행할 때 대조를 위해 도메인을 추가로 해석하지 않도록 코어에 지시합니다. 이미 대상 IP를 얻은 연결에 적합하며 불필요한 DNS 조회를 줄일 수도 있습니다. 그러나 규칙이 도메인 해석 후의 IP에 의존한다면 이 매개변수를 추가했을 때 결과가 달라질 수 있습니다. 매개변수는 기계적으로 붙이지 말고 규칙 유형과 연결 메타데이터를 함께 고려해 판단하세요.

정책 필드는 실제로 존재하는 그룹을 참조해야 합니다

규칙의 마지막 항목은 임의의 라벨이 아니라 프록시 그룹명, 노드명 또는 내장 정책입니다. 설정에 노드 선택을 작성했다면 proxy-groups에 같은 이름의 그룹이 있어야 하며 문자, 공백과 대소문자가 모두 일치해야 합니다. DIRECT는 직접 연결, REJECT는 연결 거부를 뜻합니다. 사용자 지정 이름에 한국어를 사용해도 문제는 없지만 여러 설정과 오버라이드 파일에서 관리할 때는 짧고 일관된 이름이 참조 오류를 줄여 줍니다.

로컬 예외를 관리하기 쉬운 위치에 배치하기

가정용 NAS, 프린터, 라우터 관리 페이지와 사내 네트워크는 보통 직접 연결이 필요합니다. 먼저 명확한 도메인을 나열하고, 일반적인 사설 주소 대역을 추가로 처리하면서 로컬 도메인 해석도 유지하세요. 모든 미확인 주소를 프록시로 보내면 LAN 접근 경로가 우회되거나 실패할 수 있습니다. 반대로 지나치게 넓은 직접 연결 규칙은 프록시가 필요한 대상까지 너무 일찍 일치시킬 수 있습니다. 규칙을 추가할 때는 웹페이지에 표시된 이름으로 도메인을 추측하지 말고 연결 페이지에서 실제 대상을 복사하세요. 하나의 페이지도 여러 API, 정적 리소스와 인증 도메인에 접근하기 때문입니다.

규칙 세트와 provider

대규모 규칙을 주 설정에 모두 작성하는 것은 적합하지 않습니다. rule-provider를 지원하는 코어는 로컬 파일이나 원격 주소에서 규칙 세트를 불러온 뒤 RULE-SET으로 참조할 수 있습니다. 규칙 세트에는 동작 유형, 형식, 업데이트 간격과 저장 경로를 명확히 지정해야 합니다. 원격 규칙 업데이트가 실패했을 때 코어가 캐시를 계속 사용할 수도 있고 설정 방식에 따라 오류를 낼 수도 있으므로, 핵심 규칙은 캐시 정책과 실패 시 동작을 함께 검토하세요.

rule-providers:
  private-network:
    type: http
    behavior: ipcidr
    format: yaml
    path: ./ruleset/private-network.yaml
    url: https://example.com/rules/private-network.yaml
    interval: 86400

rules:
  - RULE-SET,private-network,DIRECT
  - MATCH,노드 선택

규칙을 점검할 때는 먼저 연결 페이지에서 대상 세션을 찾아 Host, 대상 IP, 적중 규칙과 최종 정책을 기록하세요. 적중 규칙이 예상과 다르면 더 앞에 포괄적인 규칙이 있는지 확인합니다. 규칙은 맞지만 정책이 잘못되었다면 프록시 그룹의 현재 선택을 확인하세요. 도메인 규칙이 나타나지 않으면 앱이 IP를 직접 사용하는지, DNS를 다른 프로그램이 처리하는지, 기존 세션을 재사용하는지 점검합니다. 수정한 뒤에는 설정을 다시 불러오고 새 연결을 만들어 테스트하세요. 기존 연결로 새 규칙을 검증하지 마세요.

구독 설정은 업데이트할 때 rules를 다시 작성하는 경우가 많습니다. 사용자 지정 규칙을 장기적으로 관리하려면 클라이언트의 prepend, append 또는 오버라이드 기능을 우선 사용하세요. 먼저 적용해야 하는 예외는 규칙 목록 앞에 두고, 일반적인 추가 규칙은 MATCH 앞에 배치합니다. 각 사용자 지정 규칙 옆에 용도를 기록하고 더 이상 유효하지 않은 항목은 정기적으로 삭제하세요. 규칙이 많다고 효과가 좋아지는 것은 아닙니다. 각 규칙의 출처, 우선순위와 대상을 설명할 수 있어야 유지 관리 가능한 분기 설정입니다.

TUN 모드는 가상 네트워크 인터페이스로 IP 트래픽을 받은 뒤 연결을 Clash 규칙 엔진으로 전달합니다. 터미널 도구, 게임, 일부 스토어 앱과 네트워크 연결을 자체적으로 관리하는 소프트웨어에 적합합니다. 시스템 프록시보다 TUN의 적용 범위가 넓지만 라우팅, DNS, 방화벽, 가상 머신과 다른 VPN 소프트웨어의 영향을 더 쉽게 받습니다. 시스템 프록시로 대상 앱을 처리할 수 없을 때만 활성화하세요. 일상적인 웹 브라우징에 TUN을 항상 켜 둘 필요는 없습니다.

활성화 전 기본 조건

Windows에서는 가상 네트워크 인터페이스를 만들고 라우팅을 수정하기 위해 클라이언트 보조 서비스나 관리자 권한이 필요한 경우가 많습니다. macOS에서는 네트워크 확장을 승인해야 하고, Linux에서는 TUN 장치 권한과 라우팅 및 방화벽 규칙을 수정할 권한이 필요합니다. 클라이언트에 “서비스 모드”가 있다면 먼저 서비스 설치가 성공했는지 확인한 뒤 TUN을 켜세요. 스위치가 즉시 원래 상태로 돌아가거나 로그에 permission denied, operation not permitted 또는 interface 생성 실패가 표시된다면 문제는 권한과 서비스 계층에 있습니다. 이때 프록시 노드를 계속 바꾸지 마세요.

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
  ipv6: true
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

stack은 TUN 네트워크 스택 구현을 지정합니다. 일반적인 값으로 system, gvisor와 mixed가 있으며 구체적인 지원 범위는 코어와 운영체제에 따라 다릅니다. system은 운영체제 네트워크 스택에 더 의존하고, gvisor는 사용자 공간에서 더 많은 네트워크 동작을 처리하며, mixed는 호환성과 성능 사이에서 프로토콜을 분배하려고 합니다. 특정 UDP, 게임 또는 LAN 연결에 문제가 생기면 네트워크 스택을 별도 변수로 테스트할 수 있지만, 변경할 때마다 코어를 완전히 다시 시작하고 기존 연결을 정리해야 합니다.

auto-route는 코어가 트래픽 가로채기에 필요한 라우팅을 자동으로 작성하게 합니다. auto-detect-interface는 현재 출구 네트워크 인터페이스를 식별하며 유선과 무선 네트워크 사이를 전환할 때 유용합니다. 여러 네트워크 인터페이스, 가상 머신, 컨테이너, 전화 접속 연결 또는 다른 VPN이 동시에 존재하면 자동 감지가 잘못된 인터페이스를 선택할 수 있습니다. TUN을 켠 뒤 전체 네트워크가 끊기거나 LAN에 접근할 수 없거나 트래픽이 두 가상 인터페이스 사이를 순환하는 현상이 나타날 수 있습니다. 이때는 먼저 다른 네트워크 가로채기 소프트웨어를 끄고 시스템 라우팅 테이블과 기본 출구를 확인하세요.

DNS 가로채기와 fake-ip

dns-hijack는 지정된 포트의 DNS 조회를 코어가 처리하게 해 앱이 Clash DNS를 우회하지 못하도록 합니다. fake-ip 모드에서는 도메인에 예약 주소를 반환하고, 코어가 매핑을 통해 원래 도메인을 복원한 뒤 규칙을 적용합니다. 도메인 규칙 적중이 더 안정적이라는 장점이 있지만, 실제 IP에 의존하는 LAN 장치, 일부 게임, 기업 인증과 특수 프로토콜은 fake-ip-filter에 추가해야 할 수 있습니다. redir-host는 실제 해석 결과를 반환하므로 호환 경로가 다릅니다. 향상된 모드를 전환하면 캐시와 기존 연결에 영향을 주므로 확인하기 전에 시스템과 브라우저의 DNS 캐시를 갱신하세요.

LAN과 예약 주소

TUN을 켠 뒤에도 사설 네트워크 대역, 링크 로컬 주소와 로컬 도메인이 직접 연결되도록 해야 합니다. 가정용 네트워크에서 자주 사용하는 IPv4 대역은 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16이며 IPv6 로컬 주소도 실제 환경에 맞게 처리해야 합니다. 직접 연결 규칙만으로는 충분하지 않습니다. DNS가 NAS 이름을 외부 해석기로 보내면 올바른 주소를 받지 못할 수 있습니다. 내부 도메인은 LAN DNS로 보내거나 hosts, nameserver-policy 등에서 해석 경로를 명시하세요.

최소 문제 해결 절차

TUN을 켠 뒤 네트워크가 끊기면 첫째 TUN을 꺼 원래 네트워크가 복구되는지 확인합니다. 둘째 로그에서 권한, 인터페이스와 라우팅 오류를 확인합니다. 셋째 다른 VPN과 가상 네트워크 프로그램을 종료합니다. 넷째 enable, stack, auto-route, auto-detect-interface 등 필요한 필드만 남겨 테스트합니다. 다섯째 DNS 가로채기와 사용자 지정 라우팅을 추가합니다. 웹페이지는 정상인데 특정 게임만 실패한다면 TCP, UDP, IPv4와 IPv6 경로를 비교하세요. 설정 전체를 바로 폐기하지는 마세요.

TUN의 검수는 브라우저, 터미널, LAN과 시스템 복구 네 가지를 포함해야 합니다. 브라우저가 규칙에 따라 접속할 수 있어야 하고, 프록시 환경 변수를 설정하지 않은 터미널 연결이 연결 페이지에 표시되어야 합니다. 라우터나 NAS에도 계속 접근할 수 있어야 하며, TUN을 끈 뒤 시스템의 기본 라우팅과 DNS가 복구되어야 합니다. 네 가지를 모두 통과해야 트래픽 가로채기와 종료 경로가 완성되었다고 볼 수 있습니다.

안정적인 사용에는 많지 않지만 지속적인 관리가 필요합니다. 사용 가능한 설정을 보관하고, 필요할 때 구독을 업데이트하며, 클라이언트와 코어의 업데이트 내용을 확인하고, 만료된 규칙을 정리하세요. 시스템 네트워크가 바뀐 뒤에는 프록시 설정도 검증해야 합니다. 문제가 발생했을 때 클라이언트를 다시 설치하는 것은 보통 첫 단계가 아닙니다. 구독, 시스템 프록시, DNS, TUN 권한과 규칙 오류는 재설치 후에도 그대로 남기 때문입니다. 더 효과적인 방법은 애플리케이션 계층, 트래픽 가로채기 계층, 코어 계층, 정책 계층과 원격 경로를 순서대로 확인하는 것입니다.

반복 가능한 상태 점검 만들기

클라이언트나 설정을 업데이트할 때마다 먼저 코어가 시작되었는지, 설정이 로드되었는지, 포트가 리스닝 중인지 확인한 다음 브라우저 페이지 하나와 터미널 요청 하나로 검증하세요. 연결 페이지에 해당 세션이 나타나고 규칙 필드가 예상과 일치하며 프록시 그룹이 실제 선택한 항목을 가리켜야 합니다. 마지막으로 LAN 주소 하나를 테스트해 직접 연결 예외가 영향을 받지 않았는지 확인하세요. 이 점검을 자주 할 필요는 없지만 설정을 크게 바꾸거나 시스템을 업그레이드하거나 네트워크 환경을 전환한 뒤에는 매우 유용합니다.

# macOS / Linux: 현재 터미널에서만 프록시 설정
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

# 테스트가 끝나면 설정 삭제
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

# PowerShell: 현재 창에만 적용
$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"

# 현재 창의 설정 삭제
Remove-Item Env:HTTP_PROXY
Remove-Item Env:HTTPS_PROXY

터미널 환경 변수와 시스템 프록시는 서로 독립적입니다. 브라우저는 접속되지만 명령줄은 접속되지 않는다면 먼저 터미널 프로그램이 시스템 프록시를 읽는지 확인하고, 이어서 HTTP_PROXY, HTTPS_PROXY와 ALL_PROXY를 확인하세요. 반대로 클라이언트를 종료했는데도 터미널이 계속 127.0.0.1:7890에 연결하려 한다면 환경 변수가 남아 있는 경우가 많습니다. 브라우저와 터미널을 나누어 점검하는 방법은 시스템 프록시가 작동하지 않을 때의 두 가지 점검 경로에서 확인할 수 있습니다.

자주 발생하는 문제와 확인 지점

포트 사용과 잔류 프로세스

로그에 address already in use가 나타나면 다른 프로세스가 같은 포트를 이미 리스닝 중이라는 뜻입니다. 중복 실행된 코어, 다른 프록시 클라이언트 또는 비정상 종료 후 남은 프로세스일 수 있습니다. 먼저 시스템 작업 관리자나 포트 도구에서 점유자를 확인한 뒤 해당 프로그램을 정상적으로 종료하세요. 포트를 다른 숫자로 바꾸면 코어는 시작될 수 있지만 브라우저, 터미널과 시스템 프록시는 여전히 이전 포트를 가리킬 수 있어 “클라이언트는 정상인데 트래픽이 통하지 않는” 새로운 문제가 생깁니다. 실제로 포트를 변경했다면 모든 참조 위치도 함께 수정하세요.

업데이트 정책과 롤백

클라이언트, 코어, 구독과 규칙 세트는 서로 다른 네 가지 업데이트 경로입니다. 이들을 같은 시점에 모두 업데이트하지 마세요. 먼저 현재 설정과 클라이언트 설정을 저장한 뒤 한 항목만 업데이트하고 기본 테스트를 완료합니다. 코어를 업데이트한 뒤에는 설정 필드 호환성을, 구독 업데이트 후에는 프록시 그룹명과 규칙 변경을, 규칙 세트 업데이트 후에는 적중 결과를, 클라이언트 업데이트 후에는 시스템 프록시, 서비스 모드와 시작 항목을 중점적으로 확인하세요. 문제가 생기면 모든 설정을 다시 만들기보다 어느 계층을 되돌릴지 명확히 정하는 편이 안정적입니다.

시스템 절전, 네트워크 전환 또는 회사 네트워크에서 가정용 네트워크로 돌아온 뒤에는 기존 연결, 기본 네트워크 인터페이스와 DNS 캐시가 남아 있을 수 있습니다. 이때 먼저 코어를 다시 시작하고 대상 앱을 다시 여세요. TUN에서 자동 출구 감지를 사용한다면 현재 기본 인터페이스가 변경되었는지 확인합니다. 특정 웹사이트 하나만 문제라면 해당 사이트의 연결과 DNS 캐시만 정리하면 되며 시스템 네트워크 전체를 초기화할 필요는 없습니다. 유지 관리의 목표는 변경 범위를 줄이고, 매번 무엇이 바뀌었는지 설명할 수 있는 정보를 남기는 것입니다.

앞의 일곱 장을 마치면 클라이언트에는 안정적인 기본 경로가 갖춰져야 합니다. 애플리케이션 트래픽이 코어로 들어오고, 구독이 업데이트되며, Rule 모드가 예상대로 분기되고, TUN은 필요할 때만 활성화되며, 로그와 연결 페이지로 문제를 찾을 수 있어야 합니다. 고급 단계에서는 기능을 계속 쌓기보다 설정을 명확하고 검증 가능하며 되돌릴 수 있는 모듈로 나누는 것이 중요합니다. 설정의 완성도는 규칙의 개수가 아니라 네트워크 전환, 구독 업데이트와 클라이언트 업그레이드 후에도 계속 작동하는지로 판단하세요.

1단계: 설정 책임 분리

주 설정에는 포트, 모드, DNS, 프록시 그룹과 규칙 진입점만 남기고, 서비스 제공자 구독은 노드와 기본 그룹을 담당하게 하세요. 로컬 오버라이드는 고정된 사용자 지정 규칙을 담당하고, 대규모 규칙은 rule-provider에 넣으며, 장치별 설정은 별도로 기록합니다. 이렇게 하면 구독을 업데이트해도 로컬 정책이 덮어써지지 않고, 클라이언트를 바꿀 때도 어떤 부분을 이전할 수 있는지 빠르게 판단할 수 있습니다. 설정 파일명에는 용도와 환경을 포함하세요. 예를 들어 desktop-rule, laptop-tun, home-lan처럼 지정하고 “새 설정2”처럼 오래 기억하기 어려운 이름은 피하세요.

여러 기기에서 같은 정책을 관리해야 한다면 노드 자격 증명이 포함된 완전한 파일을 그대로 동기화하지 마세요. 민감한 내용이 없는 규칙 조각, DNS 템플릿과 설명 문서만 동기화한 뒤 각 기기에서 구독을 따로 가져오세요. 그러면 분기 로직은 통일하면서도 기기마다 다른 포트, 네트워크 인터페이스와 로컬 경로가 서로 덮어써지는 일을 피할 수 있습니다.

2단계: 도메인별 DNS 정책 설정

복잡한 네트워크에서는 하나의 nameserver가 모든 도메인에 적합하지 않을 수 있습니다. 코어가 지원한다면 nameserver-policy를 사용해 내부 도메인, 특정 공용 도메인 또는 서로 다른 규칙 세트에 해석기를 지정할 수 있습니다. 설계하기 전에 문제를 먼저 명확히 하세요. 내부 도메인을 LAN DNS에서만 해석할 수 있는지, 특정 도메인의 잘못된 결과를 피해야 하는지, IPv6 경로가 불안정한지부터 확인합니다. 목표가 분명하지 않은 상태에서 여러 해석기 그룹, fallback과 필터 조건을 동시에 추가하지 마세요.

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8
  nameserver-policy:
    "+.home.arpa":
      - 192.168.1.1
    "+.internal.example":
      - 10.0.0.53
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "+.home.arpa"

내부 DNS 주소는 해당 네트워크에서 실제로 접근 가능해야 합니다. 노트북이 가정이나 회사 네트워크를 벗어나면 이러한 주소가 시간 초과될 수 있으므로 네트워크 환경 전환을 고려해야 합니다. 클라이언트가 설정 전환을 지원한다면 네트워크별로 독립적인 DNS 오버라이드를 준비하세요. 하나의 설정만 유지한다면 내부 도메인 규칙이 일반 공용 해석에 영향을 주지 않도록 해야 합니다. DNS를 조정한 뒤에는 명확한 도메인으로 해석 결과와 연결 페이지의 규칙 적중을 확인하세요. 웹페이지가 최종적으로 열리는지만 보지 마세요.

3단계: 제어 인터페이스로 읽기 전용 진단 수행

제어 인터페이스에서는 현재 설정, 프록시 그룹과 연결 상태를 읽을 수 있습니다. 기본적으로 로컬 주소에서만 리스닝하게 하는 편이 안전하며 데스크톱 클라이언트에도 충분합니다. 명령줄에서 인터페이스에 접근하기 전에 external-controller의 주소와 포트를 확인하세요. secret을 설정했다면 클라이언트 방식에 맞게 인증 정보를 제공해야 합니다. 제어 인터페이스를 공용 네트워크에 직접 노출해서는 안 됩니다. 아래 예시는 로컬 제어 포트를 읽어 인터페이스가 응답하는지 확인하는 용도로만 사용합니다.

curl http://127.0.0.1:9090/configs
curl http://127.0.0.1:9090/proxies
curl http://127.0.0.1:9090/connections

진단할 때는 수정하기보다 먼저 읽어 보세요. /configs에서는 현재 모드와 일부 실행 매개변수를 확인할 수 있고, /proxies에서는 프록시 그룹 구조를, /connections에서는 활성 연결을 확인할 수 있습니다. 호환 코어마다 인터페이스 필드가 다를 수 있으므로 자동화 스크립트는 필드 누락과 인터페이스 사용 불가를 처리해야 합니다. 모든 클라이언트가 동일한 구조를 반환한다고 가정해서는 안 됩니다.

4단계: 변경 사항을 위한 테스트 목록 만들기

규칙이나 DNS를 변경할 때마다 최소한 네 종류의 대상을 테스트하세요. 명확히 직접 연결되어야 하는 LAN 서비스, 분명히 프록시를 사용해야 하는 도메인, MATCH가 처리하는 미지의 대상, 특별한 처리가 필요한 앱입니다. 대상, 예상 정책, 실제 규칙과 최종 경로를 기록하세요. 테스트 목록은 감으로 몇 개의 웹사이트를 둘러보는 것보다 포괄적인 규칙의 조기 적중, DNS 정책 누락과 프록시 그룹 참조 오류를 더 잘 찾아냅니다.

설정에서 TUN을 사용한다면 종료 테스트도 추가해야 합니다. TUN을 끈 뒤 기본 라우팅이 복구되고 시스템 DNS가 작동하며 브라우저가 더 이상 로컬 포트에 의존하지 않아야 합니다. 부팅 시 자동 실행을 사용한다면 시스템을 다시 시작한 뒤 보조 서비스, 코어, 설정과 시스템 프록시의 시작 순서를 확인하세요. 시작 항목이 활성화로 표시된다고 해서 모든 계층이 준비된 것은 아닙니다. 로그의 시간 순서를 보면 설정 로드가 네트워크 연결보다 먼저 되었는지, 시스템 프록시가 아직 리스닝하지 않는 포트를 가리키고 있는지 확인할 수 있습니다.

이후 학습은 세 방향으로 확장할 수 있습니다. 더 세밀한 분기가 필요하다면 rule-provider, 프록시 그룹 체인과 프로세스 규칙을 깊이 살펴보세요. 더 많은 앱을 처리해야 한다면 TUN 라우팅, DNS 가로채기와 여러 네트워크 인터페이스의 동작을 연구하세요. 장기 관리가 필요하다면 설정 버전 기록, 변경 내역과 자동화된 문법 검사를 구축하세요. 세 방향을 동시에 진행하지 말고 현재 환경에서 가장 분명한 문제 하나를 먼저 선택하세요.

처음부터 고급 설정까지 익히는 최종 목표는 모든 필드를 외우는 것이 아닙니다. 연결이 Clash로 어떻게 들어오는지, 왜 특정 규칙이 적중하는지, 최종적으로 어떤 정책이 선택되는지, 문제가 생겼을 때 어느 계층을 확인해야 하는지를 설명할 수 있으면 됩니다. 가장 짧은 작업 흐름을 다시 따라가려면 입문 가이드로 돌아가세요. 클라이언트를 설치하거나 바꾸려면 다운로드 센터로 이동하세요. 빠른 작업과 체계적인 참고를 분리하면 일상적인 관리가 더 안정적입니다.