Clash 입문부터 고급 활용까지 사용 설명서

먼저 Clash의 핵심 개념과 트래픽 경로 이해하기

클라이언트, 핵심 엔진과 설정 파일은 서로 다른 계층입니다

일상적으로 Clash라고 부르는 대상은 대개 세 가지로 나뉩니다. 첫째는 Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu처럼 그래픽 인터페이스를 제공하는 클라이언트입니다. 설정 관리, 트레이 메뉴, 시스템 프록시 전환, 서비스 설치와 로그 표시를 담당합니다. 둘째는 네트워크 연결을 처리하는 핵심 엔진입니다. 현재 많은 클라이언트가 mihomo를 사용하며, 엔진은 포트 수신, 규칙 해석, 정책 선택, 프록시 연결 수립과 DNS 처리를 담당합니다. 셋째는 YAML 설정 파일로, 포트, 노드, 정책 그룹, 규칙과 DNS 동작을 정의합니다.

이 세 계층은 반드시 나누어 판단해야 합니다. 인터페이스가 열렸다는 것은 클라이언트 프로그램이 시작되었다는 뜻일 뿐입니다. 핵심 엔진이 실행 중이어야 로컬 프록시 포트가 수신을 시작했다는 의미가 됩니다. 브라우저가 대상 사이트에 접속하려면 시스템 트래픽이 실제로 해당 포트로 들어가고, 규칙이 유효한 정책을 선택하며, 노드 연결과 DNS 조회도 정상이어야 합니다. 'Clash는 실행 중인데 인터넷이 안 되는' 문제는 대부분 설치 프로그램 자체가 아니라 엔진 이후의 어느 계층에서 발생합니다.

설정 파일은 구독과도 다릅니다. 구독 주소는 보통 서비스 제공자가 생성하며, 클라이언트가 해당 주소에 접속해 설정 내용을 받아 로컬 설정으로 저장합니다. 단일 노드 링크는 서버 하나만 설명하므로 완전한 정책 그룹과 라우팅 규칙을 자동으로 포함하지 않습니다. 로컬 YAML 파일은 이미 완성된 설정이라 바로 가져올 수 있지만, 이후 자동 업데이트 여부는 클라이언트의 관리 방식에 따라 달라집니다. 형식을 더 자세히 구분하려면 구독 링크, YAML 설정과 주요 가져오기 형식 안내를 참고하세요.

앱 요청부터 최종 출구까지의 전체 경로

브라우저로 HTTPS 사이트에 접속하는 경우를 예로 들면, 먼저 도메인을 주소로 조회해야 합니다. 이후 브라우저가 TCP 또는 QUIC 연결을 만들고, 시스템은 프록시 설정이나 가상 네트워크 인터페이스 라우팅에 따라 연결을 Clash로 전달합니다. 엔진은 대상 도메인, 주소, 포트와 프로세스 등의 정보를 읽어 규칙을 위에서부터 순서대로 대조합니다. 규칙이 일치하면 요청을 해당 정책 그룹에 넘깁니다. 정책 그룹은 특정 노드를 직접 선택할 수도 있고 다른 그룹을 참조할 수도 있으며, 최종적으로 '프록시', '직접 연결' 또는 '거부' 같은 동작이 결정됩니다.

따라서 문제를 점검할 때는 경로 순서대로 확인해야 합니다. 앱이 시스템 프록시를 따르는지, 아니면 TUN이 트래픽을 인계했는지 확인하고, 로컬 수신 포트가 존재하는지, 도메인이 올바르게 조회되는지, 규칙이 예상 항목과 일치하는지, 정책 그룹이 사용 가능한 출구를 선택했는지, 원격 노드가 연결을 수립할 수 있는지를 살펴보세요. 중간 계층을 건너뛰고 노드만 계속 바꾸면 잠시 문제가 가려질 수는 있어도 잘못된 시스템 프록시, DNS 또는 규칙 설정은 해결되지 않습니다.

클라이언트 선택 및 각 플랫폼 설치 완료

먼저 플랫폼과 연결 요구 사항에 맞춰 선택하기

그래픽 클라이언트의 핵심 역할은 구독 내용을 바꾸는 것이 아니라 설정 관리와 시스템 연결의 복잡성을 낮추는 데 있습니다. 이 사이트의 다운로드 목록에서는 Clash Plus를 Windows, macOS, Android와 iOS의 우선 선택지로 안내하며, 여러 주요 플랫폼에서 비슷한 사용 흐름을 원하는 사용자에게 적합합니다. Windows와 macOS에서는 Clash Verge Rev와 FlClash도 선택할 수 있습니다. Windows에서는 Clash Nyanpasu를 사용할 수 있고, 유지 관리가 중단된 Clash for Windows 아카이브도 제공합니다. macOS에는 유지 관리가 중단된 ClashX Meta도 있습니다. Android에서는 Clash Meta for Android, FlClash 또는 Surfboard를 선택할 수 있으며, Linux 데스크톱에서는 Clash Verge Rev와 FlClash를 사용할 수 있습니다.

선택할 때는 인터페이스의 외관만 보지 마세요. 현재 시스템 아키텍처에 맞는 설치 패키지가 있는지, 필요한 엔진을 지원하는지, 시스템 서비스를 설치할 수 있는지, TUN 연결을 제공하는지, 구독 업데이트와 로그 확인이 명확한지를 우선 확인해야 합니다. 브라우저와 시스템 프록시를 따르는 소수의 프로그램만 사용한다면 일반 시스템 프록시로 충분합니다. 명령줄, 게임 런처, 가상 머신 보조 프로그램 또는 시스템 프록시를 읽지 않는 앱까지 연결해야 한다면 TUN을 안정적으로 관리하는 클라이언트를 우선 선택하세요.

서버와 라우터 사용자는 보통 mihomo 엔진을 직접 실행하지만, 이 방식은 설정 파일, 프로세스 권한, 시작 서비스와 로그 순환을 직접 관리해야 합니다. 일반 데스크톱 사용자는 '더 가볍게' 쓰기 위해 그래픽 클라이언트를 건너뛸 필요가 없습니다. 이후 유지 관리 비용이 절약되는 인터페이스 리소스보다 큰 경우가 많기 때문입니다. 전체 패키지 목록, 플랫폼별 진입점과 유지 관리 중단 상태는 클라이언트 다운로드 페이지를 기준으로 확인하세요.

Windows, macOS와 Linux 설치 시 확인할 점

Windows에 설치하기 전 기존 프록시 프로그램이 실행 중인지 확인하세요. 여러 프로그램이 같은 포트를 동시에 수신하면 새 엔진이 시작되지 않을 수 있습니다. 여러 프로그램이 시스템 프록시를 번갈아 수정하면 인터페이스에는 켜진 것으로 보여도 시스템은 다른 포트를 가리키는 상황이 생깁니다. 기존 클라이언트를 종료한 뒤 새 클라이언트를 설치하고, 처음 실행할 때는 시스템 보안 알림에서 앱의 네트워크 접근을 허용하세요. 시스템 서비스나 TUN을 사용하려면 클라이언트에서 서비스 설치를 완료하고 시스템 권한을 승인해야 하는 경우가 많습니다. 서비스 설치 성공과 TUN 활성화는 서로 다른 상태이므로 혼동하지 마세요.

macOS 설치 후 앱 출처나 네트워크 확장 권한을 묻는다면 시스템 설정에서 승인을 완료하세요. Apple Silicon과 Intel은 소프트웨어 패키지의 아키텍처가 다르므로 '이 Mac에 관하여'에서 칩 정보를 확인해 선택해야 합니다. 시스템 프록시는 macOS 프록시 설정을 따르는 연결만 처리합니다. 강화된 연결 기능을 켜면 VPN 설정 추가나 네트워크 확장 허용을 요구할 수 있습니다. 권한이 거부되었다면 시작 버튼을 계속 누르지 말고 개인정보 보호 및 보안, 네트워크 또는 VPN 관련 페이지로 돌아가 다시 확인하세요.

Linux의 차이는 주로 배포판 패키지 형식, 데스크톱 환경과 권한 모델에서 발생합니다. Debian과 Ubuntu 계열은 보통 deb 패키지를 사용하며, 다른 배포판은 클라이언트가 제공하는 호환 형식을 선택할 수 있습니다. 설치 후 인터페이스는 열리지만 트래픽을 연결하지 못한다면 데스크톱 시스템 프록시가 실제로 기록되었는지, 현재 세션이 해당 설정을 읽는지, TUN에 필요한 네트워크 관리 권한이 있는지 확인하세요. 서버 환경에서 엔진을 실행할 때는 전용 서비스 계정이 설정 및 로그 디렉터리에 접근하도록 하고, 대화형 터미널 프로세스로 장기간 실행하지 않는 것이 좋습니다.

Android와 iOS의 연결 방식

Android 클라이언트는 VpnService로 로컬 VPN 인터페이스를 만들고 기기 트래픽을 엔진에 전달합니다. 처음 연결할 때 시스템에 VPN 권한 창이 표시되며, 승인해야만 트래픽을 인계할 수 있습니다. 화면을 잠근 뒤 연결이 끊기거나 네트워크를 전환한 뒤 작동하지 않는 문제는 대부분 시스템 절전 정책, 백그라운드 제한 또는 제조사의 자동 정리 기능과 관련이 있습니다. 클라이언트의 백그라운드 실행을 허용하고 시스템 설정에서 배터리 최적화 예외로 추가하세요. 제조사별 경로는 다르므로 Android VpnService, 백그라운드 실행과 절전 설정을 계속 참고할 수 있습니다.

iOS는 시스템 VPN 설정을 통해 작동합니다. Clash Plus를 설치한 뒤 처음 활성화할 때 VPN 설정 추가를 승인해야 합니다. 시스템 상태 표시줄의 VPN 표시는 설정이 연결되었다는 뜻일 뿐이며, 실제 접속 가능 여부는 구독, 정책과 노드에 달려 있습니다. Wi-Fi에서 모바일 네트워크로 전환하면 기존 연결이 다시 만들어지므로 잠시 끊기는 것은 정상적인 전환 과정입니다. 오래 복구되지 않는다면 연결을 중지하고 시스템 VPN 상태가 완전히 사라질 때까지 기다린 뒤 다시 시작하세요. 같은 구독을 반복해서 가져오지는 마세요.

구독 가져오기와 기본 설정 구조 이해하기

구독 주소, 노드 링크와 YAML 파일 구분하기

구독 주소는 보통 HTTPS URL이며, 접속하면 Clash에서 사용할 설정이나 인코딩된 노드 목록을 반환합니다. 구독의 장점은 업데이트가 가능하다는 것입니다. 서비스 제공자가 노드, 정책 또는 규칙을 조정하면 클라이언트가 다시 가져와 새 내용을 받을 수 있습니다. 로컬 YAML 파일은 정적인 스냅샷이므로 백업, 사용자 지정 또는 오프라인 관리에 적합하지만 원본 구독이 바뀌어도 자동 동기화되지 않습니다. 단일 노드 링크에는 프로토콜, 서버, 포트와 인증 정보만 들어 있으므로 가져온 뒤 정책 그룹과 규칙을 직접 만들어야 할 수 있습니다.

가져오기 전에 주소가 완전한지, 메신저에서 잘리지 않았는지, 복사 과정에서 앞뒤 공백이 섞이지 않았는지 확인하세요. 구독 주소는 브라우저 주소창의 검색창이 아니라 클라이언트의 구독 또는 설정 가져오기 메뉴에 붙여 넣습니다. 가져오기에 성공하면 먼저 설정 이름, 업데이트 시간과 프록시 그룹이 표시되는지 확인한 뒤 해당 설정을 현재 활성 항목으로 지정하세요. '다운로드 성공'만 하고 '현재 설정으로 전환'하지 않았다면 엔진은 계속 이전 파일을 사용할 수 있습니다.

가져오기 실패는 크게 세 계층으로 나뉩니다. 네트워크 계층에는 연결 시간 초과, 도메인 조회 실패와 인증서 오류가 있고, 서비스 계층에는 인증 만료, 접근 거부 또는 웹 페이지 안내가 있습니다. 설정 계층에는 YAML 들여쓰기 오류, 필드 형식 불일치와 존재하지 않는 정책 그룹 참조가 있습니다. 클라이언트 로그에 HTTP 상태 문제가 표시되면 먼저 구독 자체를 확인하세요. 특정 줄의 해석 실패가 표시되면 프록시 노드를 바꿀 것이 아니라 설정 내용을 점검해야 합니다.

기본 설정에서 먼저 알아둘 주요 필드

실행 가능한 설정에는 보통 로컬 수신 매개변수, 프록시 노드, 정책 그룹, 규칙과 DNS 설정이 포함됩니다. 그래픽 클라이언트는 일부 전역 필드를 자체 설정 데이터베이스에 저장할 수 있으므로 내보낸 설정에 모든 인터페이스 옵션이 들어 있지는 않습니다. 아래 예시는 실제 서버 정보 없이 기본 구조만 보여 줍니다. 프록시 노드 부분도 필드 관계를 설명하기 위한 것입니다.

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

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,PROXY
  - GEOIP,LAN,DIRECT
  - MATCH,PROXY

mixed-port는 하나의 로컬 포트에서 HTTP와 SOCKS 연결을 동시에 받아 앱에 프록시 주소를 직접 입력하기 편하게 합니다. 포트가 로컬에서만 수신할 때 자주 사용하는 주소는 127.0.0.1입니다. allow-lan은 같은 네트워크의 다른 기기가 현재 기기의 프록시 포트에 연결할 수 있는지 제어합니다. 평소 이 기기에서만 사용한다면 끄는 편이 명확합니다. mode는 전체 대조 모드를 결정하며 보통 rule을 사용합니다. log-level은 로그 상세도를 조절합니다. 정상 사용에서는 info로 두고, 문제를 해결할 때만 잠시 높였다가 많은 로그가 쌓이지 않도록 원래대로 돌리세요.

proxies는 실제 출구를 정의하고, proxy-groups는 여러 출구를 선택하거나 자동 테스트할 수 있는 정책으로 묶으며, rules는 트래픽을 정책 그룹에 전달합니다. 규칙에서 참조하는 정책 이름은 대소문자와 기호를 포함해 그룹 이름과 완전히 같아야 합니다. 그룹 이름을 PROXY에서 다른 이름으로 바꾸면 해당 이름을 참조하는 모든 규칙도 함께 수정해야 합니다. 그렇지 않으면 설정 검증에 실패합니다.

업데이트, 덮어쓰기와 로컬 수정의 관계

구독 업데이트는 보통 원격 내용을 다시 다운로드해 캐시를 덮어쓰므로, 구독에서 생성된 YAML을 직접 편집하면 다음 업데이트에서 수정 사항이 사라질 수 있습니다. 장기간 유지할 사용자 지정 내용은 클라이언트가 제공하는 오버라이드, 병합, 스크립트 처리 또는 전역 확장 기능을 우선 사용하세요. 이런 기능이 없다면 로컬 설정을 복사해 독립적으로 관리할 수 있지만 이후 노드 변경 사항을 직접 동기화해야 합니다.

업데이트에 실패했다고 원래 설정을 바로 삭제하지 마세요. 마지막으로 정상 작동한 캐시를 보존하고 구독 주소가 여전히 유효한지 확인한 뒤 수동 새로 고침을 시도하세요. 업데이트 후 갑자기 사용할 수 없게 되었다면 이전 캐시로 돌아가 프록시 그룹, 규칙과 DNS 영역이 어떻게 바뀌었는지 비교할 수 있습니다. 좋은 클라이언트는 '원격 구독', '로컬 캐시'와 '현재 활성 설정'을 구분합니다. 이 세 상태를 이해하면 유일하게 쓸 수 있는 설정을 실수로 삭제하는 일을 피할 수 있습니다.

시스템 프록시, 실행 모드와 연결 검증 익히기

시스템 프록시와 Clash 실행 상태의 차이

클라이언트가 엔진을 시작하면 로컬에 HTTP, SOCKS 또는 혼합 프록시 포트가 생기지만 운영체제가 모든 트래픽을 자동으로 그곳에 보내지는 않습니다. 시스템 프록시 스위치는 로컬 프록시 주소를 Windows, macOS 또는 데스크톱 환경의 네트워크 설정에 기록합니다. 브라우저처럼 시스템 프록시를 따르는 프로그램은 이후 해당 포트에 연결하지만, 시스템 프록시를 무시하는 프로그램은 계속 직접 연결합니다. 따라서 '엔진 실행 중'과 '시스템 프록시 활성화'는 서로 독립적인 조건입니다.

앱의 프록시를 수동으로 설정할 때 서버 주소는 보통 127.0.0.1로 입력하고, 포트는 설정의 mixed-port, HTTP 포트 또는 SOCKS 포트를 입력합니다. 원격 노드 포트를 브라우저에 직접 입력하지 마세요. 원격 프로토콜이 브라우저에서 지원하는 HTTP 프록시가 아닐 수 있습니다. 클라이언트가 로컬 포트를 변경했다면 시스템 프록시와 앱의 수동 설정도 동일하게 맞춰야 합니다.

일부 명령줄 프로그램은 데스크톱 시스템 프록시를 자동으로 읽지 않고 환경 변수를 사용합니다. 임시 테스트에서는 현재 터미널에 프록시 변수를 설정할 수 있습니다. 터미널을 닫으면 보통 변수가 사라지므로, 프로그램이 로컬 포트를 통해 연결할 수 있는지 확인하는 데 적합합니다.

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

Windows PowerShell에서는 현재 세션에 필요한 환경 변수를 설정하고 앱을 종료한 뒤 정리할 수 있습니다. 프록시 변수를 시스템 환경에 장기간 기록하기 전에는 클라이언트 전환에 따라 포트가 바뀌지 않는지 확인하세요. 그렇지 않으면 클라이언트가 실행되지 않을 때 해당 변수를 사용하는 도구가 존재하지 않는 로컬 포트에 계속 연결을 시도합니다.

규칙, 전역과 직접 연결 모드의 용도

규칙 모드는 설정의 규칙을 위에서부터 순서대로 판단하며 일상 사용의 기본 모드입니다. 로컬 네트워크, 자주 쓰는 국내 서비스 또는 지정 도메인은 직접 연결하고 프록시가 필요한 연결은 정책 그룹으로 보내며, 접근하지 않을 대상은 거부할 수 있습니다. 규칙 모드의 결과는 규칙의 품질과 순서에 달려 있습니다. 특정 사이트만 잘못된 출구로 연결된다면 전체 실행 모드를 바꾸기 전에 일치한 규칙을 확인하세요.

전역 모드는 보통 엔진으로 들어온 모든 트래픽을 지정된 정책 그룹으로 보냅니다. 짧은 비교 테스트에 적합합니다. 규칙 모드에서는 접속되지 않지만 전역 모드에서는 접속된다면 노드와 기본 경로는 대체로 정상이며, 문제는 규칙, 정책 그룹 참조 또는 DNS 매핑에 있을 가능성이 큽니다. 전역 모드라고 해서 시스템의 모든 트래픽이 자동으로 인계되는 것은 아닙니다. 프록시 포트나 TUN으로 들어오지 않은 연결은 여전히 처리되지 않습니다.

직접 연결 모드는 엔진으로 들어온 트래픽을 대상에 바로 연결합니다. 문제가 프록시 출구와 관련 있는지 판단할 때 유용합니다. 직접 연결에서도 접속되지 않는다면 DNS, 시스템 네트워크, 대상 서비스 또는 로컬 방화벽을 추가로 확인해야 합니다. 문제 해결이 끝나면 임시 테스트 상태를 장기 설정으로 착각하지 않도록 규칙 모드로 되돌리세요.

연결 기록과 로그로 검증을 완성하기

웹 페이지가 '열린다'는 사실만으로는 라우팅이 올바른지 검증할 수 없습니다. 클라이언트의 연결 페이지에는 보통 대상 도메인, 대상 주소, 규칙 경로와 최종 정책이 표시됩니다. 테스트 대상에 접속한 뒤 연결 목록에 나타나는지 확인하세요. 기록이 없으면 트래픽이 엔진에 들어오지 않았을 수 있습니다. 기록은 있지만 잘못된 정책으로 향한다면 규칙이나 정책 그룹 선택에 문제가 있습니다. 정책은 올바르지만 연결에 실패한다면 노드, 프로토콜 핸드셰이크와 DNS 로그를 계속 확인하세요.

로그는 마지막 한 줄만 보지 말고 명확한 오류가 발생한 지점을 기준으로 앞뒤를 읽어야 합니다. 포트 점유는 엔진 시작 단계에서 나타나는 경우가 많고, 설정 참조 오류는 로딩 단계에서, 노드 시간 초과는 실제 연결을 수립할 때 발생합니다. 로그의 실패가 백그라운드 프로그램에서 발생했을 수도 있어 현재 테스트 중인 브라우저와 반드시 관련된 것은 아닙니다. 먼저 로그를 지우거나 시간을 기록한 뒤 하나의 테스트 동작만 실행하는 것이 좋습니다.

관리 가능한 규칙, 정책 그룹과 DNS 설정 만들기

규칙은 위에서부터 대조되며 순서가 곧 우선순위입니다

Clash 규칙의 기본 구조는 '유형, 대조 내용, 대상 정책'입니다. 예를 들어 DOMAIN-SUFFIX,example.com,PROXY는 대상 도메인이 example.com으로 끝날 때 PROXY로 보내고, IP-CIDR,192.168.0.0/16,DIRECT,no-resolve는 지정 주소 대역을 직접 연결하되 이 규칙을 대조할 때 도메인 조회를 능동적으로 실행하지 않습니다. MATCH,PROXY는 앞에서 일치하지 않은 모든 연결을 받아 주며 보통 규칙 목록의 마지막에 둡니다.

엔진은 처음 일치하는 규칙을 찾으면 검색을 멈추므로 더 구체적인 예외를 더 넓은 규칙보다 앞에 배치해야 합니다. 특정 하위 도메인만 프록시로 보내고 나머지 동일한 주 도메인은 직접 연결하려면 하위 도메인 규칙을 먼저 쓰고 도메인 접미사 규칙을 뒤에 작성하세요. MATCH를 중간에 두면 뒤의 규칙은 절대 일치할 기회를 얻지 못합니다. 대규모 규칙 세트를 조정할 때는 대상이 도메인 규칙인지, 주소 규칙인지, 프로세스 규칙인지 먼저 판단한 뒤 앞의 넓은 규칙에 먼저 가로채이지 않는지 확인하세요.

rules:
  - DOMAIN,api.example.com,PROXY
  - DOMAIN-SUFFIX,example.com,DIRECT
  - DOMAIN-KEYWORD,media,MEDIA
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - GEOIP,LAN,DIRECT
  - MATCH,FINAL

DOMAIN은 완전한 도메인과 일치하므로 정확한 예외에 적합합니다. DOMAIN-SUFFIX는 주 도메인과 하위 도메인을 모두 포함하는 자주 쓰는 유형입니다. DOMAIN-KEYWORD는 범위가 넓어 이름이 비슷한 도메인까지 잘못 대조할 수 있으므로 신중하게 사용하세요. IP-CIDR과 IP-CIDR6은 대상 주소를 직접 대조하므로 로컬 네트워크와 명확한 대역에 적합합니다. 프로세스 규칙은 운영체제와 트래픽 연결 방식에 따라 달라집니다. 시스템 프록시 환경에서는 항상 신뢰할 수 있는 프로세스 정보를 얻는다고 할 수 없으므로 사용 전에 연결 기록에서 확인하세요.

정책 그룹은 단순한 노드 목록이 아니라 출구를 결정하는 계층입니다

정책 그룹은 규칙과 실제 노드 사이에서 결정을 내리는 계층으로 이해할 수 있습니다. select 그룹은 사용자가 직접 선택하므로 결과가 안정적이고 문제 해결이 쉽습니다. url-test는 지정한 테스트 주소와 간격으로 후보 노드를 측정해 조건에 맞는 결과를 선택합니다. fallback은 보통 사용 가능 여부에 따라 순서대로 전환하고, load-balance는 정책에 따라 여러 후보에 연결을 분배합니다. 고급 매개변수의 표시 방식은 엔진과 클라이언트에 따라 다를 수 있으므로 설정 검증 결과를 기준으로 판단하세요.

proxy-groups:
  - name: FINAL
    type: select
    proxies:
      - AUTO
      - MANUAL
      - DIRECT

  - name: MANUAL
    type: select
    use:
      - main-provider

  - name: AUTO
    type: url-test
    use:
      - main-provider
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80

자동 테스트는 클라이언트에서 테스트 대상까지의 연결 상태만 반영하며 모든 웹 사이트의 이용 경험이 똑같다는 뜻은 아닙니다. 테스트 주소, 노드 출구와 대상 서비스 사이의 네트워크 경로는 다를 수 있고, 동영상, 다운로드와 웹 탐색은 대역폭, 지연 변동과 연결 재사용에 요구하는 조건도 다릅니다. 일상적으로는 자동 그룹으로 기준 상태를 확인하고 특정 대상이나 장애 전환을 위해 수동 그룹을 남겨 두는 것이 좋습니다. 정책 그룹끼리 서로 참조할 수 있지만 순환 참조는 피하세요.

구독에서 provider로 노드를 관리한다면 use는 개별 노드가 아니라 provider 이름을 참조합니다. 서비스 제공자가 새 노드를 추가하면 provider를 업데이트하는 것만으로 관련 정책 그룹에 들어갑니다. 정책 그룹에 노드 이름을 고정해 두면 새 노드는 자동으로 나타나지 않습니다. 수정하기 전에 클라이언트가 시각적 오버라이드를 제공하는지 확인하고 원격 구독 캐시를 직접 편집하지 않는 것이 좋습니다.

DNS는 엔진이 어떤 대상 정보를 볼 수 있는지 결정합니다

DNS 문제는 웹 페이지가 오래 대기하거나 일부 도메인만 열리지 않거나, 규칙이 도메인이 아닌 주소와 일치하거나, 시스템이 예상과 다른 조회 경로를 감지하는 형태로 나타납니다. Clash DNS 모듈은 조회 요청을 인계해 도메인별로 지정된 상위 DNS에 보내고, 규칙과 함께 도메인 정보를 제공할 수 있습니다. 대표적인 강화 모드로 fake-ip와 redir-host가 있습니다. fake-ip는 먼저 예약 주소를 반환한 뒤 연결 단계에서 엔진이 실제 도메인을 복원하므로 더 완전한 도메인 대조 능력을 유지하는 경우가 많습니다. 다만 일부 로컬 네트워크 기기, 특수 앱과 연결성 확인 기능은 필터 목록에 추가해야 할 수 있습니다.

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

예시의 상위 DNS는 문법을 보여 주기 위한 것이며 실제 선택은 현재 네트워크에서의 접근성, 조회 결과와 개인정보 보호 요구를 고려해야 합니다. DNS 수신 주소가 엔진이나 이 기기에서만 사용된다면 로컬 주소로 제한하세요. TUN을 켜면 DNS 하이재킹으로 시스템의 53번 포트 요청을 엔진으로 가져오는 경우가 많습니다. 이때 시스템에 다른 DNS 필터, 암호화 DNS 클라이언트 또는 보안 프로그램이 동시에 연결되어 있으면 서로 경쟁하거나 순환이 발생하기 쉽습니다.

DNS 이상 여부를 판단할 때는 먼저 '도메인 조회 결과가 없는지'와 '주소는 받았지만 연결에 실패했는지'를 구분하세요. 전자는 DNS 로그, 상위 DNS 접근성과 시스템 캐시를 확인하고, 후자는 규칙 일치, 대상 주소와 노드 연결을 확인합니다. DNS를 변경한 뒤에는 엔진을 재시작하고 시스템 상황에 따라 캐시를 삭제한 다음 이전에 방문하지 않은 도메인으로 테스트하세요. 조회 경로가 걱정된다면 FAQ의 관련 점검 항목과 사이트의 Clash DNS 및 연결 이상 문답을 참고하세요.

TUN 연결 설정과 권한 및 라우팅 충돌 처리

TUN이 시스템 프록시의 한계를 보완하는 방식

시스템 프록시는 앱이 운영체제의 프록시 설정을 능동적으로 읽는 것을 전제로 합니다. 브라우저와 대부분의 데스크톱 앱은 지원하지만, 명령줄 도구, 일부 게임, 가상 머신 구성 요소, UDP 앱과 자체 네트워크 스택을 사용하는 프로그램은 완전히 무시할 수 있습니다. TUN 모드는 가상 네트워크 인터페이스를 만들고 시스템 라우팅으로 연결을 Clash에 전달하므로 더 넓은 범위를 포함하며 UDP와 프록시를 인식하지 못하는 앱도 더 많이 처리할 수 있습니다.

TUN이 시스템 프록시보다 본질적으로 빠른 것은 아닙니다. 가상 네트워크 카드, 라우팅, DNS 하이재킹과 프로토콜 변환 단계가 추가되며, 장점은 네트워크 거리를 줄이는 것이 아니라 전체 연결을 인계하는 데 있습니다. 브라우저 프록시만 필요하다면 시스템 프록시가 더 간단합니다. 앱 우회가 명확하거나 UDP가 필요하거나 시스템 트래픽을 통합 관리하려는 경우에 TUN을 켜세요. 문제를 해결할 때도 먼저 일반 프록시를 작동시킨 뒤 TUN을 추가해 노드 문제와 시스템 라우팅 문제를 분리하는 것이 좋습니다.

주요 TUN 매개변수 이해하기

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

dns:
  enable: true
  enhanced-mode: fake-ip

stack은 TUN이 사용할 네트워크 스택 구현을 지정하며, 흔한 값으로 system, gvisor와 mixed가 있습니다. 실제 사용 가능한 항목은 엔진에 따라 다릅니다. system은 보통 시스템 네트워크 기능을 활용하므로 호환성과 성능이 플랫폼 구현의 영향을 받습니다. gvisor는 사용자 공간에서 더 많은 네트워크 로직을 처리해 일부 환경에서 격리가 명확합니다. mixed는 프로토콜에 따라 조합된 방식을 사용합니다. 명확한 문제가 없다면 클라이언트 기본 선택을 유지하고 이름만 보고 성능을 추측하지 마세요.

auto-route는 엔진이 필요한 라우팅을 자동으로 기록하도록 하고, auto-detect-interface는 실제 연결 인터페이스를 찾으므로 Wi-Fi와 유선 네트워크를 전환할 때 유용합니다. strict-route는 라우팅 제약을 강화해 트래픽 우회를 줄이지만, 가상 머신, 컨테이너, 기업 VPN 또는 특수한 로컬 네트워크 라우팅이 있으면 추가 조정이 필요할 수 있습니다. dns-hijack는 지정된 DNS 요청을 Clash DNS로 보내 앱이 시스템 53번 포트를 직접 사용해 라우팅을 우회하지 못하게 합니다.

플랫폼별 권한과 충돌 원인

Windows에서 TUN을 켜려면 관리자 권한, 시스템 서비스 또는 드라이버 구성 요소가 필요한 경우가 많습니다. 클라이언트에 서비스가 설치되지 않았다고 표시되면 먼저 설정에서 서비스 설치를 완료한 뒤 엔진을 다시 시작하세요. 가상 네트워크 카드 생성에 실패하면 다른 VPN, 네트워크 가속기와 보안 프로그램이 라우팅이나 필터 드라이버를 관리하고 있지 않은지 확인합니다. 두 개의 전역 VPN 연결 프로그램을 동시에 켜지 마세요. 기본 라우팅을 계속 덮어써 연결이 주기적으로 끊길 수 있습니다.

macOS는 보통 시스템 네트워크 확장이나 VPN 설정으로 연결을 구현합니다. 처음 켤 때 시스템 승인을 완료해야 합니다. 설정이 남아 다시 연결되지 않는다면 시스템 네트워크 설정에서 기존 VPN 항목을 먼저 비활성화한 뒤 클라이언트가 다시 만들도록 하세요. Android와 iOS는 본래 시스템 VPN 인터페이스로 연결하므로 일반적으로 한 번에 하나의 주요 VPN 설정만 활성 상태일 수 있습니다. 클라이언트를 전환하기 전에 현재 연결을 먼저 끊으세요.

Linux에서 엔진을 직접 실행하려면 TUN 장치를 만들고 라우팅을 수정할 권한이 필요합니다. systemd로 서비스를 관리할 때는 배포판의 보안 정책에 따라 필요한 네트워크 권한만 부여하고, 관리자 터미널을 장시간 열어 두는 방식은 피하세요. 컨테이너 환경에서는 TUN 장치와 네트워크 관리 권한도 명시적으로 제공해야 합니다. 호스트에 이미 방화벽 규칙이 있다면 엔진이 기록한 라우팅과 포워딩 규칙이 나중에 덮어써지지 않는지 확인하세요.

로컬 네트워크, 가상 머신과 기업 VPN의 경계

TUN을 켠 뒤 프린터, 라우터 관리 페이지 또는 NAS에 접속할 수 없다면 로컬 네트워크 라우팅이 인계되었을 가능성이 큽니다. 먼저 IPv4의 일반적인 사설 네트워크 대역과 IPv6 로컬 주소 같은 사설 주소 대역이 직접 연결로 유지되는지 확인하세요. 그런 다음 엄격한 라우팅이 특정 인터페이스를 차단하는지 살펴봅니다. 기업 VPN은 내부 네트워크 대역만 전용 인터페이스로 보낼 수 있는데 Clash가 해당 라우팅을 덮어쓰면 내부 도메인이나 업무 시스템에 접근할 수 없습니다. 해결할 때는 모든 라우팅을 단순히 끄기보다 기업 VPN에 남겨야 할 대역을 명확히 정해야 합니다.

가상 머신과 컨테이너는 별도의 브리지를 통해 네트워크에 접근할 수 있습니다. 호스트의 TUN이 이 트래픽을 인계하는지는 라우팅, 포워딩과 네트워크 모드에 따라 달라지므로 호스트 브라우저 결과만으로 판단할 수 없습니다. 충돌이 발생하면 TUN을 켜기 전후의 라우팅 테이블 변화를 기록하고 자동 라우팅을 잠시 꺼서 비교한 뒤 제외 대역을 추가할지 인터페이스 우선순위를 조정할지 결정하세요.

일상 유지 관리, 이전과 문제 해결 절차 만들기

일상 업데이트는 모든 항목을 동시에 업데이트하는 것이 아닙니다

Clash 환경에는 보통 업데이트 가능한 대상이 클라이언트 프로그램, 프록시 엔진, 구독 설정과 규칙 데이터 네 가지 있습니다. 클라이언트 업데이트는 인터페이스와 시스템 통합을 바꿀 수 있고, 엔진 업데이트는 프로토콜, 규칙 문법 또는 TUN 동작에 영향을 줄 수 있습니다. 구독 업데이트는 주로 노드와 서비스 제공자 설정을 바꾸며, 규칙 세트 업데이트는 라우팅 결과를 바꿉니다. 이들을 동시에 업데이트하면 문제가 생겼을 때 원인을 특정하기 어렵습니다.

더 안정적인 방법은 마지막으로 정상 작동한 설정을 유지한 채 먼저 구독을 업데이트하고 검증한 다음 클라이언트나 엔진을 업데이트하는 것입니다. 중요한 기기를 업데이트하기 전 현재 설정 이름, 프록시 모드, 정책 선택, 수신 포트, DNS 모드와 TUN 상태를 기록하세요. 클라이언트에서 설정 내보내기를 지원한다면 백업을 보관할 수 있지만, 백업에 구독 주소나 인증 정보가 들어 있을 수 있으므로 관리되는 장소에 보관하고 공개 저장소나 공개 문의 화면에 업로드하지 마세요.

구독 업데이트 주기는 실제 변경 빈도에 맞추세요. 지나치게 자주 새로 고쳐도 노드 품질이 좋아지지 않으며, 일시적인 네트워크 불안정 중에 실패 기록만 계속 만들 수 있습니다. 업데이트 후 정책 그룹이 비어 있다면 provider가 로드되었는지, 노드 필터 조건이 지나치게 엄격하지 않은지, 구독 반환 형식이 바뀌지 않았는지 확인하세요. 백업 없이 기존 설정을 삭제하고 다시 가져오지 마세요. 이전 캐시는 중요한 비교 자료입니다.

'인터넷이 전혀 되지 않음'을 계층별로 점검하기

첫 번째로 시스템 기본 네트워크를 확인합니다. 시스템 프록시와 TUN을 끈 상태에서 직접 연결이 정상인지 봅니다. 직접 연결도 실패한다면 Wi-Fi, 유선 연결, 게이트웨이 또는 시스템 DNS부터 처리하세요. 두 번째로 시스템을 연결하지 않은 채 Clash 엔진을 시작하고 설정 해석 오류와 포트 충돌이 있는지 확인합니다. 세 번째로 시스템 프록시를 켜고 브라우저로 테스트 사이트에 접속하면서 연결 기록을 확인합니다. 연결 기록이 없으면 시스템 프록시 주소를 점검하고, 기록이 나타난 뒤에는 일치한 정책과 노드 오류를 살펴보세요.

모든 노드가 시간 초과되면 구독 만료인지, 노드 전체에 접근할 수 없는지, 로컬 네트워크가 차단했는지 판단해야 합니다. 같은 설정의 직접 연결 정책으로 전환하면 로컬 네트워크를 확인하는 데 도움이 되고, 다른 지역이나 다른 프로토콜의 노드를 선택하면 특정 출구 문제인지 판단할 수 있습니다. 노드 하나만 실패했다면 전체 DNS와 규칙 설정을 바꾸지 마세요. 모든 노드에서 즉시 인증 오류가 반환된다면 구독 상태와 서비스 권한을 다시 확인해야 합니다.

HTTPS 인증서 오류는 일반적인 연결 실패와 나누어 처리해야 합니다. 먼저 시스템 날짜, 시간대와 인증서 체인을 확인한 뒤 HTTPS를 검사하는 보안 프로그램이나 중간 프록시가 켜져 있는지 확인하세요. Clash의 일반적인 전달 기능은 일반 HTTPS 사이트에 사이트 인증서를 설치할 것을 요구하지 않습니다. 자세한 판단 순서는 프록시 환경에서 HTTPS 인증서 오류 처리하기를 참고하세요.

일부 웹 사이트나 앱만 이상할 때 점검하기

특정 웹 사이트 하나만 이상하다면 먼저 연결 기록을 열어 도메인, 일치한 규칙과 최종 정책을 확인하세요. 규칙이 잘못되었다면 더 구체적인 도메인 규칙을 조정합니다. 정책은 올바르지만 연결에 실패한다면 같은 그룹의 다른 노드를 시도하세요. 연결 기록에 주소만 있고 도메인이 없다면 DNS 연결과 fake-ip 동작을 점검합니다. 대상이 QUIC을 사용한다면 UDP 지원도 결과에 영향을 줄 수 있습니다. 브라우저 QUIC을 잠시 비활성화해 비교할 수 있지만, 그 비교 설정을 영구적인 결론으로 삼아서는 안 됩니다.

브라우저는 정상인데 명령줄이나 다른 앱이 작동하지 않는다면 해당 앱이 시스템 프록시를 따르지 않는 경우가 많습니다. 먼저 앱이 수동 HTTP 또는 SOCKS 프록시를 지원하는지 확인한 뒤 환경 변수로 테스트하세요. 장기간 통합 연결이 필요하면 TUN을 고려합니다. 모바일 앱만 화면을 잠근 뒤 연결이 끊긴다면 백그라운드 실행과 절전 제한을 확인하세요. 로컬 네트워크 리소스만 접근할 수 없다면 사설 대역 직접 연결, TUN 엄격 라우팅과 로컬 도메인에 대한 DNS 처리를 점검합니다.

프록시를 끈 뒤에도 시스템에서 인터넷에 연결되지 않는다면 클라이언트가 비정상 종료되어 시스템 프록시가 남아 있을 수 있습니다. 시스템 네트워크 설정에서 프록시 주소와 스위치를 확인하고 작동하지 않는 수동 프록시를 끄세요. TUN을 사용했다면 가상 VPN이 끊겼고 기본 라우팅이 복구되었는지도 확인합니다. 클라이언트를 다시 시작한 뒤 정상적인 종료 버튼으로 연결을 해제하면 프로세스를 강제 종료하는 것보다 시스템 설정이 복구되기 쉽습니다.

전체 화면 캡처보다 유효한 로그 수집하기

문의를 제출하기 전에 운영체제, 클라이언트 이름, 현재 연결 방식, 문제가 시작된 시간과 최소 재현 절차를 기록하세요. 로그는 오류 전후의 짧은 구간만 남기고 구독 주소, 서버 주소, 사용자 이름과 인증 필드는 가리세요. 화면 캡처에는 상태와 오류 영역만 포함하면 되며 관련 없는 데스크톱 전체를 보낼 필요는 없습니다. 'TUN을 끄면 정상이고 켜면 실패한다' 또는 '전역은 정상이고 규칙 모드만 실패한다'처럼 비교 결과를 설명하는 것이 막연히 '사용할 수 없다'고 하는 것보다 훨씬 유용합니다.

더 많은 짧은 질문은 자주 묻는 질문에서 기본 개념, 설치 및 설정, 사용 팁과 문제 해결로 나누어 확인할 수 있습니다. 인터페이스의 프록시, 설정과 로그 페이지가 익숙하지 않다면 Clash 클라이언트 인터페이스 기능 한눈에 보기를 읽고 먼저 해당 상태를 찾은 뒤 이 장의 경로에 따라 원인을 좁혀 보세요.

안정적인 사용에서 고급 설정과 장기 유지 관리로 나아가기

먼저 모듈형 설정 관점 만들기

고급 설정의 목표는 규칙을 많이 쌓는 것이 아니라 노드 출처, 정책 결정, 규칙 출처, DNS와 시스템 연결을 독립적으로 검증할 수 있는 모듈로 나누는 것입니다. 노드는 proxy provider가 관리하고 규칙은 rule provider가 관리하도록 하며, 고정된 정책 그룹과 전역 설정은 기본 설정에 남겨 둘 수 있습니다. 이렇게 하면 노드를 업데이트해도 사용자 지정 정책이 덮어써지지 않고, 규칙을 업데이트할 때도 설정 전체를 다시 복사할 필요가 없습니다.

모듈화하기 전에 각 정책 그룹의 역할을 명확히 정하세요. 예를 들면 '수동 선택', '자동 선택', '미디어 서비스', '개발 서비스', '최종 출구'처럼 구분할 수 있습니다. 그룹 이름은 안정적이고 로그에서 쉽게 알아볼 수 있어야 하며, 기호만으로 구분되는 비슷한 이름을 자주 만들지 마세요. 규칙은 일시적인 특정 노드가 아니라 역할 그룹을 참조해야 합니다. 노드가 바뀌면 그룹 구성원만 조정하고 규칙 계층은 그대로 유지할 수 있습니다.

원격 provider에는 적절한 업데이트 간격을 설정하고 로컬 캐시를 유지하세요. 규칙 출처에 일시적으로 접근할 수 없어도 엔진이 캐시로 시작할 수 있어야 합니다. 모든 핵심 내용을 실시간 다운로드 한 번에 의존하면 네트워크가 이상한 순간에 시작하지 못할 수 있습니다. 외부 리소스의 형식과 동작은 서로 맞아야 합니다. 도메인 집합, IP 대역 집합과 클래식 규칙 형식을 임의로 섞어서는 안 됩니다.

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,FINAL

예시 주소는 구조를 보여 주기 위한 것입니다. 실제로 원격 규칙을 사용하기 전에는 출처, 콘텐츠 업데이트 방식과 지원 형식을 확인하세요. 규칙 세트는 클수록 좋은 것이 아닙니다. 겹치는 항목이 많으면 이해와 문제 해결 비용이 커지고, 잘못 분류하면 직접 연결해야 할 트래픽이 프록시로 보내질 수 있습니다. 자신의 사용 환경과 관련된 소수의 예외를 우선 관리하고 경계가 명확한 범용 규칙 출처를 선택하세요.

mihomo 확장 기능의 적용 범위 이해하기

mihomo는 원본 Clash 설정 방식에 더해 다양한 프로토콜, 규칙 유형, DNS 기능, provider 옵션과 TUN 동작을 확장했습니다. 기존 설정을 이전할 때는 기본 필드와 정책 그룹을 먼저 검증하고 새 기능을 단계적으로 도입하세요. 여러 출처의 조각을 한꺼번에 붙여 넣어서는 안 됩니다. 클라이언트마다 내장 엔진 빌드, 기본 매개변수와 오버라이드 방식이 다를 수 있으므로 한 클라이언트에서 작동한 조각이 다른 클라이언트에서도 완전히 같은 방식으로 로드된다고 보장할 수 없습니다.

호환 관계, 확장 규칙과 이전 시 유의점을 체계적으로 확인하려면 mihomo 엔진 기능과 원본 Clash의 차이를 참고하세요. 학습할 때는 클라이언트가 실제로 생성한 실행 설정을 기준으로 삼는 것이 좋습니다. 인터페이스에서 저장한 설정은 시작할 때 구독 설정에 병합될 수 있으며, 실제 동작을 결정하는 것은 최종적으로 엔진에 전달된 내용입니다.

설정 변경을 위한 검증과 되돌리기 체계 만들기

장기 유지 관리에는 세 가지 파일을 보관하세요. 시작이 확인된 기준 설정 하나, 현재 사용 중인 설정 하나, 수정 중인 테스트 설정 하나입니다. 수정 후에는 먼저 클라이언트가 제공하는 설정 검사를 실행한 다음 테스트를 시작하세요. 엔진 시작, 시스템 프록시, 규칙 일치, DNS와 TUN이 모두 정상임을 확인한 뒤 현재 설정을 교체합니다. 텍스트 설정은 로컬 버전 관리로 변경 내역을 기록할 수 있지만 인증 정보와 구독 주소는 공개 저장소에 넣지 마세요.

변경할 때마다 '개발 도메인을 지정 정책으로 보내기', '가정용 로컬 네트워크 제외', '시스템 프록시를 따르지 않는 앱에 TUN 켜기'처럼 목적을 적으세요. 한 문장으로 목적을 설명할 수 없다면 한 번의 수정에 너무 많은 변수가 섞였을 가능성이 큽니다. 문제가 재발하면 기록을 바탕으로 이전 상태로 복구한 뒤 변경을 더 작은 단위로 나누세요. 유지 관리성은 설정 파일의 길이가 아니라 안정적인 이름, 명확한 역할과 되돌릴 수 있는 절차에서 나옵니다.

권장 고급 학습 순서

첫 단계에서는 규칙 모드, 수동 정책 그룹과 연결 기록을 능숙하게 사용하고 한 번의 접속이 왜 특정 출구로 향했는지 설명할 수 있어야 합니다. 두 번째 단계에서는 DOMAIN, IP-CIDR, RULE-SET과 provider를 익혀 소수의 사용자 지정 라우팅을 만듭니다. 세 번째 단계에서는 DNS 요청 경로, fake-ip와 도메인 스니핑을 이해해 조회 문제와 연결 문제를 구분할 수 있어야 합니다. 네 번째 단계에서 TUN 라우팅, 로컬 네트워크 제외, IPv6와 다중 VPN 공존을 공부하세요. 자동 테스트, 부하 분산, 스크립트 오버라이드와 복잡한 규칙 세트는 마지막에 다루는 것이 좋습니다.

이 경로를 마치면 문제가 생겼을 때 클라이언트를 반복해서 재설치하지 않고 앱 연결, 엔진 수신, DNS, 규칙, 정책과 노드 순서로 원인을 찾을 수 있습니다. 클라이언트를 바꿀 때도 어떤 내용이 구독에 속하고 어떤 내용이 로컬 설정이며 어떤 내용이 플랫폼에 의존하는지 구분할 수 있습니다. 현재 목표가 첫 연결 완료라면 빠른 사용 가이드로 돌아가 가장 짧은 절차를 따르세요. 다시 클라이언트를 선택하려면 Clash 클라이언트 선택 가이드와 전 플랫폼 다운로드를 확인하세요.