Clash 전체 플랫폼 설치 및 설정 가이드

01 / BEFORE INSTALLATION

공통 준비: 클라이언트, 구독, 트래픽 처리 방식

먼저 클라이언트와 코어의 역할을 확인하세요

Clash 생태계에는 그래픽 클라이언트와 실제 트래픽을 전달하는 코어가 있습니다. 클라이언트는 구독, 트레이, 권한과 설정 화면을 관리하고, 코어는 설정을 읽어 연결을 처리합니다. 화면 구성이 비슷해도 지원하는 설정 항목이 같은 것은 아닙니다. 특히 구형 Clash 설정과 mihomo 확장 설정은 차이가 큽니다. 클라이언트를 선택할 때는 지원 플랫폼을 확인한 뒤 구독에서 사용하는 프로토콜과 코어의 지원 범위를 비교하세요. 이 가이드에서는 지원 플랫폼에서 Clash Plus를 우선 소개합니다. 다른 화면이나 데스크톱 관리 기능이 필요하다면 설치 파일 페이지에서 Clash Verge Rev, FlClash 등의 클라이언트를 선택할 수 있습니다.

시작하기 전에 운영체제, 프로세서 아키텍처, 설치 권한을 확인하세요. 데스크톱 기기는 보통 x64와 ARM64로 나뉩니다. Apple Silicon용과 Intel용 macOS 설치 파일은 파일명에 macOS라고 적혀 있다는 이유만으로 구분할 수 없습니다. Android도 arm64와 구형 ARM 아키텍처를 구분할 수 있습니다. 설치가 끝나도 백그라운드 서비스나 가상 네트워크 어댑터에 별도 권한이 필요할 수 있습니다. 회사 기기에서 드라이버, 네트워크 확장 기능 또는 관리자 권한이 제한되어 있다면 기기 관리 정책을 먼저 따르세요. 조직 정책을 우회하려고 시스템 보호 기능을 끄지 마세요.

구독을 준비하고 복구 가능한 설정을 보관하세요

클라이언트 자체에는 바로 사용할 수 있는 원격 프록시가 포함되어 있지 않습니다. 사용 권한이 있는 구독 URL, 단일 연결 정보 또는 로컬 설정 파일을 준비하고 선택한 클라이언트와 호환되는지 확인하세요. 구독 링크에는 접속 정보가 들어 있을 수 있으므로 공개 스크린샷이나 로그, 온라인 변환 사이트에 붙여 넣지 마세요. 가져오기 전에 기존 클라이언트의 모드, 선택한 정책 그룹, 사용자 지정 규칙을 기록해 두면 편리합니다. 다만 마이그레이션할 때 새 클라이언트의 데이터 디렉터리 전체를 덮어쓰지는 마세요. 호환되지 않는 데이터베이스나 경로가 함께 복사될 수 있습니다.

원격 구독과 최종 적용 설정은 서로 다른 단계입니다. 구독을 업데이트하면 콘텐츠를 다시 가져오므로 구독 본문에서 직접 수정한 포트나 규칙은 덮어써질 수 있습니다. 계속 유지할 변경 사항은 클라이언트에서 제공하는 오버라이드, 병합 또는 확장 설정 기능에 저장하세요. 목록 병합 방식은 클라이언트마다 다르므로 규칙 순서와 정책 그룹이 통째로 교체되지 않았는지 특히 확인해야 합니다. 처음 가져올 때는 기존 설정을 그대로 유지하고 실행 여부를 확인한 뒤 로컬 사본을 저장하세요. 이후에는 한 번에 한 종류의 설정만 변경하는 것이 좋습니다.

규칙 모드와 트래픽 진입 방식을 구분하세요

규칙·전역·직결은 연결이 코어에 들어온 뒤 적용되는 처리 모드이고, 시스템 프록시와 TUN은 연결을 코어에 전달하는 방식입니다. 규칙 모드를 켠다고 모든 앱이 자동으로 프록시를 사용하는 것은 아니며, TUN을 켜도 모든 연결이 원격으로 전송되는 것은 아닙니다. 시스템 프록시는 시스템 프록시 설정을 따르는 브라우저와 데스크톱 앱에 적합합니다. TUN은 가상 네트워크 인터페이스로 더 많은 트래픽을 처리하며 라우팅, DNS, 권한 설정이 필요합니다. 처음 문제를 확인할 때는 간단한 진입 방식부터 사용하고, 여러 클라이언트나 트래픽 처리 기능을 동시에 켜지 마세요.

아래는 mihomo의 기본 설정 항목 예시입니다. 원격 프록시 정보는 포함하지 않으므로 완전한 구독 설정을 대신할 수 없습니다. 혼합 포트는 HTTP와 SOCKS 요청을 모두 받으며, 루프백 주소에 바인딩하면 이 기기에서만 접근할 수 있습니다. 클라이언트가 수신 포트나 DNS를 관리한다면 최종 생성된 설정을 기준으로 확인하세요. 같은 이름의 항목을 여러 오버라이드에 나누어 넣지 마세요. YAML은 공백으로 들여쓰기하며 같은 단계의 키를 중복해서 쓸 수 없습니다. 수정한 뒤에는 클라이언트의 설정 검사를 실행하고 코어를 다시 불러오세요.

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

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query

단계별로 확인하세요. 코어가 실행 중인지, 설정이 로드되었는지, 정책 그룹에서 항목을 선택할 수 있는지 확인한 다음 대상에 접속해 연결 기록의 적용 규칙을 살펴보세요. 연결 테스트는 특정 테스트 대상의 결과만 보여 주므로 모든 웹사이트, UDP 또는 로그인 기능이 정상이라는 뜻은 아닙니다. 나중에 설정 변경, 원격 장애, 로컬 네트워크 변경을 구분할 수 있도록 테스트 당시의 네트워크 환경과 오류 시간을 기록하세요. 처음 연결하는 방법만 필요하다면 사용 가이드에서 순서대로 진행하세요.

03 / MACOS

macOS: 아키텍처 선택과 네트워크 권한

칩에 맞는 클라이언트를 선택해 응용 프로그램에 설치하세요

‘이 Mac에 관하여’를 열어 Apple Silicon인지 Intel 프로세서인지 확인한 뒤 macOS 설치 파일에서 알맞은 파일을 선택하세요. Clash Plus를 우선 고려할 수 있으며, 화면 구성이 더 마음에 든다면 Clash Verge Rev 또는 FlClash를 선택해도 됩니다. ClashX Meta는 유지 관리가 중단되어 기존 환경과의 호환이 필요한 경우에 주로 사용됩니다. 구형 클라이언트의 설정 디렉터리를 새 클라이언트 디렉터리에 그대로 복사하지 마세요. 구독, 규칙, 설정을 구분해 옮기고, 구형 설정에 남아 있는 절대 경로와 더 이상 사용할 수 없는 스크립트에 특히 주의하세요.

디스크 이미지 형식의 설치 파일은 앱을 ‘응용 프로그램’으로 드래그한 뒤 해당 디렉터리에서 실행하세요. 마운트된 이미지에서 계속 직접 실행하지 않는 것이 좋습니다. 처음 열 때 시스템 보안 경고가 나타나면 출처를 확인하고 시스템에서 제공하는 정상적인 권한 설정 절차를 따르세요. 출처를 알 수 없는 일괄 격리 해제 명령을 따라 하거나 클라이언트를 실행하려고 시스템 보안 기능 전체를 끄지 마세요. 앱을 실행했는데 기본 창이 보이지 않으면 메뉴 막대 아이콘을 확인하세요. 메뉴 막대 앱은 창이 보이지 않아도 실행 중일 수 있습니다.

구독을 가져오고 설정 및 정책 그룹 확인

설정 관리에서 구독 링크나 로컬 YAML 파일을 가져온 뒤 업데이트가 끝나면 현재 설정으로 지정하세요. 다음으로 프록시 화면에서 선택 그룹과 자동 정책 그룹이 생성됐는지 확인합니다. 가져온 콘텐츠에 연결 정보만 있고 완전한 Clash 설정이 없다면 클라이언트에 맞는 가져오기 기능을 사용하세요. 형식이 다른 파일의 확장자만 YAML로 바꾸지 마세요. 정책 그룹 이름은 규칙에서 참조하는 이름과 일치해야 합니다. 사용자 지정 규칙을 복사할 때 새 구독에 없는 그룹 이름이 남아 있지 않은지 확인하세요.

처음 확인할 때는 규칙 모드를 유지하고 사용 가능한 항목을 하나 선택한 뒤 접속 중 연결 기록을 살펴보세요. 화면에서 속도 측정에 성공했지만 웹사이트가 열리지 않는다면 DNS 조회, 연결 수립, TLS 중 어느 단계에서 실패했는지 확인하세요. 단계마다 원인이 다르므로 모든 문제를 ‘회선 속도가 느리다’고 단정하지 마세요. 자동 정책 그룹의 검사 간격과 허용 오차는 전환 빈도에 영향을 주지만, 만료된 구독이나 잘못된 로컬 프록시 진입 설정을 해결해 주지는 않습니다. 설정 선택은 정책 그룹 유형과 사용 사례를 참고하세요.

네트워크 서비스별로 적용되는 시스템 프록시

시스템 프록시를 켠 뒤 현재 네트워크 서비스의 프록시 설정을 확인하세요. macOS에서는 Wi-Fi, 이더넷 및 다른 네트워크 서비스마다 프록시 항목을 따로 저장할 수 있으므로 인터페이스를 바꾸면 결과가 달라질 수 있습니다. 아래 명령으로 먼저 서비스 이름을 확인한 다음 Wi-Fi의 HTTP 및 SOCKS 프록시를 조회합니다. 시스템에 표시되는 서비스 이름이 다르면 목록에 나온 실제 이름을 사용하세요. 이 명령은 상태만 조회하며 네트워크 설정을 변경하지 않습니다.

networksetup -listallnetworkservices
networksetup -getwebproxy "Wi-Fi"
networksetup -getsecurewebproxy "Wi-Fi"
networksetup -getsocksfirewallproxy "Wi-Fi"

HTTP, HTTPS, SOCKS 프록시 항목을 클라이언트에서 지원하는 진입 방식에 맞추세요. 클라이언트가 혼합 포트를 제공하면 여러 프록시 프로토콜이 하나의 포트를 공유할 수 있지만 실제 설정을 확인해야 합니다. 터미널 도구는 시스템 네트워크 프록시를 읽지 않을 수 있으므로 도구 자체의 프록시 옵션을 사용하거나 현재 터미널 세션에 프록시 환경 변수를 설정하세요. 임시 테스트 설정을 모든 셸 시작 파일에 바로 추가하지 마세요. 클라이언트가 종료된 뒤에도 새 터미널이 중지된 로컬 포트에 계속 연결을 시도할 수 있습니다.

TUN, 백그라운드 보조 서비스, 다른 네트워크 도구

데스크톱 클라이언트에서 TUN을 켜려면 구현 방식에 따라 권한이 필요한 보조 서비스 설치, 네트워크 확장 기능 승인, 백그라운드 구성 요소 실행이 필요할 수 있습니다. 요청된 권한이 현재 작업에 맞는지 확인하세요. 권한을 승인한 뒤 코어를 다시 불러오고 로그에서 가상 인터페이스와 라우팅 상태를 확인하세요. 화면에서 TUN 스위치가 켜졌다는 사실만으로 트래픽 처리가 성공했다고 볼 수는 없습니다. 이전에 시스템 프록시를 따르지 않던 앱으로 확인하고 해당 연결이 기록에 나타나는지 살펴보세요.

기기에서 기업 VPN, 콘텐츠 필터링 프로그램 또는 다른 가상 네트워크 도구를 함께 실행하면 기본 경로와 DNS 설정이 서로 영향을 줄 수 있습니다. 문제를 확인할 때는 중지할 수 있는 구성 요소를 한 번에 하나씩 끄고 결과를 기록하세요. 조직에서 사용하도록 요구한 소프트웨어는 임의로 제거하지 마세요. TUN을 켠 뒤 로컬 네트워크 프린터, 공유 디렉터리, 개발 서비스에 접근할 수 없다면 주소 범위와 경로를 먼저 확인한 후 필요한 대상에만 직결 규칙을 추가하세요. 모든 사내 도메인을 프록시로 보내거나 DNS 기능을 전부 끄는 방식으로 원인을 숨기지 마세요.

잠자기에서 깨어나거나 Wi-Fi 핫스팟을 바꾼 뒤에는 이전 TCP 연결과 DNS 캐시에 기존 네트워크 정보가 남아 있을 수 있습니다. 관련 앱 연결을 종료한 뒤 클라이언트 설정을 다시 불러오세요. 시스템 프록시는 켜져 있지만 코어가 실행되지 않는다면 클라이언트를 정상적으로 시작하거나 해당 프록시를 끈 뒤 다시 확인하세요. 앱을 제거하기 전에 시스템 프록시와 TUN을 직접 끄고 클라이언트가 제공하는 방법으로 보조 서비스를 정리하세요. 앱을 휴지통으로 옮기는 것만으로 백그라운드 구성 요소나 현재 네트워크 설정까지 삭제되지는 않을 수 있습니다.

05 / IOS

iOS: Clash Plus 가져오기 및 연결 확인

스토어에서 설치하고 가져오기 메뉴 확인

iOS에서는 Clash Plus를 사용합니다. App Store의 Clash Plus 페이지에서 설치할 수 있으며 제품 정보는 공식 웹사이트 clashplus.io에서 확인하세요. 사이트의 iOS 다운로드 섹션에도 같은 링크가 있습니다. 설치한 뒤 먼저 앱이 정상적으로 열리는지 확인하고 구독 정보를 준비하세요. 화면 이름은 클라이언트 업데이트에 따라 달라질 수 있습니다. 설정, 구독, 연결 기능을 기준으로 메뉴를 찾으면 되며 데스크톱과 완전히 같은 메뉴 이름을 찾을 필요는 없습니다.

가져오기 전에 보유한 정보의 종류를 확인하세요. 웹 관리 주소, 구독 주소, 단일 연결 정보, 완전한 설정 파일은 서로 다릅니다. 링크를 복사할 때는 전체 매개변수를 포함하고 메신저에서 주소가 잘리거나 끝에 문장부호가 붙지 않도록 주의하세요. 시스템 공유 메뉴를 사용하거나 다른 앱에서 가져오기로 이동한 경우에도 저장하기 전에 대상과 이름을 확인하세요. 클립보드에 복사한 구독에는 접속 정보가 포함될 수 있습니다. 가져온 뒤 공개 메모에 붙여 넣지 말고, 문제를 해결한다는 이유로 전체 주소를 그대로 보내지 마세요.

설정을 활성화하고 VPN 연결을 시작하세요

클라이언트에서 구독이나 설정을 추가하고 콘텐츠를 가져온 뒤 현재 사용 항목으로 지정하세요. 사용할 수 있는 정책이 있는지도 확인합니다. 가져오기에 성공했다는 것은 콘텐츠가 저장됐다는 뜻일 뿐, 실제로 활성화하고 연결을 시작해야 합니다. 처음 트래픽을 처리할 때 iOS에서 VPN 설정 추가를 요청하면 시스템 안내에 따라 기기 인증을 완료하세요. 그런 다음 클라이언트로 돌아가 연결 상태를 확인하고 대상 앱을 열어 기록을 살펴보세요. 시스템에 VPN 상태가 표시되어도 터널 세션이 존재한다는 뜻일 뿐, 원격 경로, 특정 도메인 또는 서비스가 정상이라는 보장은 없습니다.

연결을 시작하자마자 중지된다면 연결 버튼을 반복해서 누르지 말고 클라이언트 오류 메시지와 시스템 VPN 상태부터 확인하세요. 설정 구문 분석 오류, 원격 매개변수 비호환, 현재 네트워크의 연결 실패, 다른 VPN 설정의 처리 등이 원인일 수 있습니다. 현재 설정의 사본을 보관하고 최소한의 변경만으로 확인하세요. 시스템에서 VPN 설정을 삭제하면 클라이언트가 다음에 권한을 다시 요청할 수 있지만 구독의 잘못된 항목까지 해결되지는 않습니다. VPN 설정을 반복해서 삭제하는 방법을 일반적인 해결책으로 사용하지 마세요.

모바일 운영체제의 트래픽 처리와 규칙 범위 이해하기

iOS의 트래픽 처리는 플랫폼의 네트워크 확장 기능을 사용하므로 데스크톱 설정의 HTTP 시스템 프록시 스위치와 같지 않습니다. 클라이언트에서 경로, 규칙 또는 모드를 선택할 수 있다면 실제 지원 방식에 맞게 설정하세요. 규칙 모드는 대상별 송신 경로를 구분하고, 전역 모드는 처리 범위에 들어온 연결을 선택한 정책으로 보냅니다. 전역 모드에서도 시스템이나 클라이언트가 제외 범위를 지정할 수 있으므로 모든 시스템 서비스가 같은 경로를 거친다고 단정하지 마세요.

처음 확인할 때는 정책 항목 하나를 명확히 선택하고 실제 대상 페이지에 요청을 보낸 뒤 도메인, 규칙, 최종 송신 경로를 확인하세요. 웹페이지는 열리지만 앱 로그인이 실패한다면 로그인 API, 인증 코드, 리소스 도메인, UDP 연결 요구 사항을 각각 살펴보세요. 일부 서비스는 계정 상태나 서버 측 지역 정책에도 영향을 받으므로 네트워크 연결만으로 모든 조건이 바뀌지는 않습니다. 브라우저 결과만 보고 규칙 전체를 반복해서 바꾸지 마세요. 먼저 실패한 요청이 클라이언트에 들어왔는지, 예상한 정책이 적용됐는지 확인하세요.

구독 업데이트, DNS, 네트워크 전환

구독을 업데이트하면 사용할 수 있는 항목과 정책 참조가 바뀔 수 있습니다. 업데이트 전에 로컬 변경 사항이 덮어써지는지 확인하세요. 클라이언트에 별도의 규칙 또는 오버라이드 기능이 있다면 계속 유지할 변경 사항은 해당 기능에서 관리하세요. 가져온 내용을 직접 편집해야 하는 클라이언트라면 먼저 사본을 저장하고 다음 업데이트 후 변경 내역을 다시 확인하세요. 정책 그룹이 삭제된 항목을 참조하면 화면에 이름은 남아도 연결할 수 없습니다. 업데이트가 끝나면 현재 선택 항목과 실제 접속을 확인하세요. 마지막 업데이트 시간만 확인해서는 안 됩니다.

Wi-Fi, 셀룰러 네트워크, 공용 핫스팟은 DNS와 네트워크 접속 조건이 서로 다릅니다. 네트워크를 바꾼 뒤 기존 연결이 끊길 수 있으므로 새로 연결해야 할 수 있습니다. 호텔이나 공항처럼 웹 인증이 필요한 네트워크에서는 먼저 정상적인 로그인 절차를 마친 뒤 클라이언트를 연결하세요. 그렇지 않으면 구독 가져오기와 원격 연결이 로그인 페이지에 막힐 수 있습니다. 특정 네트워크에서 계속 실패한다면 연결을 끊었을 때 기본 페이지에 접근할 수 있는지 비교하고, 실패한 단계를 기록하세요. 접속 네트워크 문제를 클라이언트 설정 손상으로 오해하지 않도록 합니다.

DNS 설정은 Clash Plus가 실제로 지원하는 기능을 기준으로 하세요. 이 문서의 다른 섹션에 있는 mihomo 예시는 설정 항목의 의미를 설명하기 위한 것으로, 모든 모바일 클라이언트에 그대로 붙여 넣어 사용할 수 있는 것은 아닙니다. 사용자 지정 리졸버, 시스템 네트워크 설정, 브라우저 기능이 함께 결과에 영향을 줄 수 있으므로 문제를 확인할 때는 한 번에 한 항목만 바꾸세요. Fake-IP의 매핑 방식과 감지 범위를 더 알아보려면 DNS 검사 및 유출 방지 설정을 참고한 뒤 클라이언트 기능에 맞게 적용하세요.

장기간 사용할 때는 모든 설정을 자주 지우기보다 구독이 유효한지, 현재 정책이 올바른지 정기적으로 확인하세요. 다른 기기로 옮기면 시스템 네트워크 권한을 다시 승인해야 합니다. 구독을 복구해도 이전 기기의 모든 연결 상태가 복원되는 것은 아닙니다. 클라이언트를 삭제하려면 먼저 연결을 끊고 시스템 네트워크가 정상으로 돌아왔는지 확인하세요. 문제 해결 자료에는 필요한 시간, 오류 유형, 민감 정보를 제거한 설정만 남기고 구독 주소나 연결 인증 정보가 스크린샷에 노출되지 않도록 하세요.

07 / DIAGNOSTICS

자주 묻는 설정 질문: 연결 단계별 문제 해결

구독 업데이트 실패와 설정 구문 분석 실패

구독 업데이트가 실패하면 먼저 가져오기 단계부터 확인하세요. 주소가 완전한지, 시스템 시간이 올바른지, 구독이 유효한지, 현재 네트워크에서 구독 서버에 접속할 수 있는지 살펴보세요. 주소가 로그인 페이지, 요청 제한 안내, 오류 문구를 반환한다면 이후 발생한 구문 분석 오류는 결과일 뿐입니다. YAML 들여쓰기를 바꿔서 해결하려 하지 마세요. 업데이트에 프록시를 사용하는지는 클라이언트 구현에 따라 다릅니다. 연결해야만 구독을 가져올 수 있는 경우도 있지만 이전 프록시가 작동하지 않아 업데이트가 막힐 수도 있습니다. 클라이언트의 업데이트 네트워크 설정을 확인하고 조건을 바꿔 비교하세요.

콘텐츠를 다운로드했지만 코어가 로드를 거부할 때는 문법, 설정 항목, 참조를 확인하세요. YAML은 공백으로 들여쓰기하고 목록 항목의 위치를 일치시켜야 합니다. 같은 매핑에서 중복 키로 값을 덮어쓰지 마세요. 규칙에서 참조하는 정책 그룹과 정책 그룹에서 참조하는 프록시 또는 프록시 그룹이 실제로 존재해야 합니다. 코어마다 지원하는 프로토콜과 설정 항목이 다릅니다. 파일 확장자를 YAML로 바꿔도 형식이 변환되지는 않습니다. 모든 설정을 한꺼번에 삭제하기보다 최근 오버라이드를 되돌린 뒤 한 부분씩 복구하면 원인을 찾기 쉽습니다.

포트, 수신 주소, 트래픽의 코어 유입 여부 확인

앱에서 연결 거부 오류가 나타나면 코어 실행 여부, 로컬 포트의 수신 여부, 앱 프록시 주소가 서로 일치하는지 먼저 확인하세요. 127.0.0.1에서 수신하는 서비스는 이 기기에서만 사용할 수 있습니다. 다른 기기에서 접속할 때 해당 기기 자체의 루프백 주소를 이 컴퓨터의 주소로 사용하면 안 됩니다. 기기 간에 사용하려면 서버의 로컬 네트워크 주소, 허용된 수신 범위, 방화벽 규칙을 명확히 설정하세요. 문제를 확인하려고 모든 인터페이스를 바로 개방하지 마세요. 먼저 이 기기에서 프록시를 명시해 테스트한 뒤 통제된 로컬 네트워크 범위로 단계적으로 확대하세요.

대상에 접속할 때 연결 기록이 전혀 바뀌지 않는다면 송신 정책보다 진입 방식을 먼저 확인하세요. 앱이 시스템 프록시를 따르지 않거나 별도 설정을 사용하거나 모바일 기기의 처리 범위에 포함되지 않을 수 있습니다. 기록은 있지만 직결로 나간다면 적용된 규칙과 순서를 확인하세요. 예상한 프록시가 기록에 표시되는데도 실패한다면 원격 연결, 인증, 대상 서비스 상태를 살펴보세요. 이처럼 단계별로 확인하면 모든 오류를 사용할 수 없는 노드 탓으로 돌리거나 구독을 불필요하게 다시 가져오는 일을 줄일 수 있습니다.

DNS, Fake-IP, 규칙 순서

Fake-IP는 도메인에 예약 주소를 매핑해 이후 연결에서도 도메인을 기준으로 규칙을 판단할 수 있게 합니다. 이런 주소가 보인다고 DNS가 고장 난 것은 아닙니다. 다만 실제 DNS 응답을 필요로 하는 프로그램에는 정확한 예외 규칙이 필요할 수 있습니다. 가능한 한 특정 도메인에만 예외를 적용하세요. 넓은 범위의 대상을 제외하면 도메인 규칙이 의도대로 작동하지 않을 수 있습니다. 사내 또는 로컬 도메인은 해당 이름을 조회할 수 있는 로컬 DNS도 필요합니다. 공용 리졸버는 회사나 가정 네트워크의 비공개 도메인을 모를 수 있습니다.

규칙은 순서대로 적용됩니다. 구체적인 규칙을 넓은 범위의 규칙보다 앞에 두고, MATCH는 마지막 기본 규칙으로 배치하세요. 아래는 전체 설정에 추가하는 예시이며 사용자 지정 그룹 이름에 의존하지 않고 내장 직결 정책을 사용합니다. 순서와 문법만 보여 주는 것으로 완전한 분할 라우팅 설정은 아닙니다. 실제 구독의 원격 프록시와 선택 그룹은 그대로 유지해야 합니다. 수정한 뒤 다시 불러오고 연결 기록에서 적용 항목을 확인하세요. 파일이 저장됐는지만 확인해서는 안 됩니다.

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

DNS 검사 결과에 표시된 리졸버 위치만으로 실제 트래픽의 송신 경로가 예상대로인지 판단할 수 없습니다. DNS 요청 경로, 대상 연결, 규칙 로그를 함께 확인하세요. 브라우저의 보안 DNS, 앱 내장 DNS, 캐시도 비교 결과에 영향을 줍니다. 더 자세한 설정은 DNS 유출 검사 및 방지 설정 실전 가이드를 참고하세요. DNS 옵션을 많이 켠다고 신뢰성이 자동으로 높아지는 것은 아닙니다. 각 항목의 역할을 이해한 뒤 하나씩 테스트하세요.

정책 선택, 연결 재사용, 업데이트 후 복구

자동 정책 그룹은 검사 대상과 자체 로직에 따라 경로를 선택합니다. 유형에 따라 지연 시간, 사용 가능 여부, 부하 분산 중 우선하는 기준이 다릅니다. 검사에 성공해도 특정 서비스가 작동한다는 보장은 없으며, 검사 실패도 검사 주소에 접근할 수 없어서일 수 있습니다. 먼저 항목을 직접 선택해 실제 대상을 확인한 뒤 검사 매개변수를 바꾸세요. 정책을 전환해도 기존 장기 연결은 이전 경로를 계속 사용할 수 있습니다. 해당 연결을 닫거나 앱을 다시 시작한 뒤 비교해야 정책 전환이 적용되지 않았다고 오해하지 않습니다.

클라이언트나 코어를 업그레이드한 뒤 문제가 생기면 로그와 현재 설정을 보관하고 백업 설정과 비교하세요. 사용자 지정 확장 항목, 구형 경로, 규칙 그룹 캐시, 권한 변경이 실행에 영향을 줄 수 있습니다. 백업 없이 업그레이드, 데이터 삭제, 설정 재작성을 한꺼번에 진행하면 어떤 단계가 문제를 해결했는지 알기 어렵습니다. 구형 클라이언트에서 옮기는 방법은 Clash for Windows 지원 종료 후 대체 클라이언트 및 마이그레이션을 참고하세요. 모든 실행 데이터를 복사하지 말고 구독과 규칙을 우선 옮기세요.

문제 해결에 필요한 정보만 기록하고 복구 경로를 남기세요

추가로 문제를 확인해야 한다면 운영체제와 아키텍처, 클라이언트 이름, 트래픽 처리 방식, 실패한 대상 유형, 오류 시간을 기록하고 민감 정보를 제거한 관련 로그를 첨부하세요. 로그 수준을 일시적으로 높였다면 문제 재현 후 일반 수준으로 되돌려 불필요한 접속 기록이 쌓이지 않도록 합니다. 연결 인증 정보, 구독 매개변수, 관리 인터페이스 인증 정보는 공개 자료에 포함하지 마세요. 복구는 설정을 추가한 순서의 역순으로 진행합니다. 먼저 새로 추가한 경로나 TUN을 끄고 프록시와 DNS를 복구한 다음 클라이언트가 정상적으로 종료됐는지 확인하세요. 플랫폼별 메뉴는 이 페이지의 해당 섹션에서 확인할 수 있으며 기본 사용 방법은 빠른 시작 가이드를 참고하세요.