Clash 고급 설정 가이드

Chapter 01 / Baseline

설정 골격 및 디버깅 기준선

Clash 설정은 서로 독립된 옵션 목록이 아니라 순서가 있는 처리 체인입니다. 클라이언트는 먼저 수신 포트, 실행 모드, DNS 같은 기본 항목을 읽고 프록시 노드와 프록시 그룹을 불러온 다음 규칙과 규칙 세트를 로드합니다. 마지막으로 시스템 프록시 또는 TUN이 트래픽을 커널로 전달합니다. 어느 한 계층에서 존재하지 않는 이름을 참조하면 이후 동작에 영향을 줍니다. 가장 흔한 예는 규칙이 이미 이름을 바꾼 프록시 그룹을 가리키는 경우입니다. 설정 자체는 파싱되더라도 매칭된 트래픽이 예상한 출구를 선택하지 못할 수 있습니다. 따라서 고급 설정의 첫 단계는 옵션을 더 추가하는 것이 아니라, 설명하고 검증하고 되돌릴 수 있는 기준선 설정을 만드는 것입니다.

클라이언트 설정과 커널 설정을 먼저 구분하세요

Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu 같은 그래픽 클라이언트는 보통 설정을 두 계층으로 나눕니다. 첫 번째는 앱 자체의 설정으로, 시작 시 자동 실행, 시스템 프록시 전환, 설정 업데이트 주기, 화면 테마, 서비스 설치 상태 등이 해당합니다. 두 번째가 mihomo 커널에 전달되는 YAML입니다. 시스템 프록시 버튼은 일반적으로 구독 파일을 수정하지 않고 운영체제의 프록시 진입점만 바꿉니다. TUN 스위치는 클라이언트가 실행 시 오버라이드 값을 생성할 수 있으므로 원본 구독에서 동일한 필드를 찾지 못할 수도 있습니다. 문제를 확인할 때는 현재 적용된 설정과 구독 원문을 함께 살펴보고, 다운로드한 YAML만 확인해서는 안 됩니다.

디버깅에 적합한 기본 섹션은 간결하게 유지하는 것이 좋습니다. 로그 레벨은 먼저 info를 사용하면 연결, 규칙 매칭, DNS 오류를 확인하기에 충분합니다. 특정 요청을 추적해야 할 때만 일시적으로 debug로 전환하세요. 포트를 명시해야 하는지는 클라이언트 관리 방식에 따라 달라지며, 데스크톱 클라이언트는 시작할 때 자체 포트를 주입할 수 있습니다. 설정 파일을 직접 관리한다면 아래 구조를 사용할 수 있지만, 해당 포트가 다른 프록시 프로그램에서 사용 중이지 않은지 확인해야 합니다.

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

profile:
  store-selected: true
  store-fake-ip: true

mode: rule은 규칙에 따라 직접 연결, 프록시 또는 거부를 결정합니다. unified-delay는 측정 기준을 전체 연결 과정에 가깝게 만들지만 실제 네트워크 품질을 바꾸지는 않습니다. store-selected는 프록시 그룹 선택을 저장하므로 재시작 후 그룹마다 다시 선택할 필요가 없습니다. store-fake-ip는 Fake-IP 매핑을 저장해 재시작 직후 매핑이 바뀌면서 발생하는 연결 변동을 줄입니다. 모바일 환경에서 시스템이 앱 프로세스를 회수할 수 있으므로 영속 설정이 특히 중요하지만, 클라이언트가 정상적으로 백그라운드에서 실행되도록 허용되어 있어야 합니다.

가장 짧은 경로로 검증 흐름을 만드세요

변경할 때마다 먼저 커널이 설정을 불러오는지 확인하고, 다음으로 프록시 노드가 연결을 수립하는지 확인하세요. 그 후 테스트 요청 하나가 어떤 규칙에 매칭됐는지 살펴보고, 마지막으로 대상 앱을 점검합니다. 설정 파싱 단계에서 이미 오류가 발생했다면 노드를 바꿔도 의미가 없습니다. 노드 핸드셰이크가 실패했다면 먼저 구독과 네트워크를 처리하고 DNS부터 수정하지 마세요. 브라우저는 정상인데 특정 앱만 실패한다면 해당 앱이 시스템 프록시를 우회하는지, 독립 DNS나 QUIC을 사용하는지 확인하세요. 이 순서를 따르면 문제를 하나의 계층으로 좁힐 수 있습니다.

설정 파일의 들여쓰기에는 공백만 사용하고 탭은 섞지 마세요. 콜론, 샵 또는 특수 문자가 포함된 텍스트는 따옴표로 감쌀 수 있으며, 규칙에서 참조하는 프록시 그룹 이름은 변경 후에도 일관되게 유지해야 합니다. 클라이언트를 바꿔야 한다면 먼저 다운로드 페이지에서 플랫폼에 맞는 항목을 선택하세요. 모든 플랫폼에서는 우선 Clash Plus를 고려하고, 운영체제와 사용 습관에 따라 다른 클라이언트를 선택하면 됩니다. 이전할 때는 같은 구독을 먼저 가져와 기본 연결을 확인한 다음 로컬 오버라이드를 옮기세요. 이전 클라이언트가 생성한 런타임 필드를 범용 설정으로 그대로 복사하지 않는 것이 좋습니다.

Chapter 03 / Rules

규칙 세트 구독으로 관리하기

규칙이 수십 개에서 수백 개로 늘어나면 모든 내용을 주 설정에 계속 넣는 방식은 빠르게 유지 관리가 어려워집니다. rule-providers는 주제별 규칙을 독립 리소스로 분리하고, 주 설정에서 다운로드 주소, 형식, 업데이트 주기와 매칭 동작을 선언할 때 사용합니다. 주 파일에는 호출 순서만 남기고 규칙 내용은 해당 규칙 세트가 관리하게 됩니다. 광고 차단, 로컬 네트워크, 개발 서비스 또는 스트리밍 규칙을 각각 업데이트할 수 있고, 특정 규칙 세트에 문제가 생겨도 전체 구독을 다시 작성하지 않고 빠르게 비활성화할 수 있습니다.

provider 정의와 RULE-SET 호출

규칙 제공자의 이름은 로컬 참조용 식별자일 뿐이며, 실제 파싱에 영향을 주는 것은 behavior, format과 리소스 내용입니다. behavior: domain은 도메인 항목만 포함된 모음에 적합하고, ipcidr은 IP 대역을 대상으로 하며, classical은 유형 접두사가 붙은 고전 규칙을 담을 수 있습니다. 형식은 원격 파일과 일치해야 합니다. 일반 텍스트 규칙은 text, YAML 규칙은 yaml을 사용할 수 있습니다. classical 형식의 내용을 domain으로 선언하지 마세요. 로드에 성공했다고 해서 매칭 의미까지 올바른 것은 아닙니다.

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

  developer:
    type: http
    behavior: classical
    format: text
    path: ./ruleset/developer.list
    url: https://example.com/rules/developer.list
    interval: 86400

rules:
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,developer,개발 서비스
  - GEOIP,LAN,DIRECT,no-resolve
  - MATCH,전체 선택

예시 도메인은 필드 구조만 보여 주므로, 실제 사용 시에는 접근 가능 여부와 콘텐츠 신뢰성을 확인한 규칙 공급원으로 바꿔야 합니다. path는 로컬 캐시 위치이며, 서로 다른 provider가 같은 경로를 공유해서는 안 됩니다. interval은 초 단위입니다. 공용 규칙은 보통 몇 분마다 업데이트할 필요가 없으며, 지나치게 잦은 업데이트는 요청과 쓰기 작업만 늘립니다. 업데이트에 실패해도 커널은 일반적으로 기존 캐시를 계속 사용하므로, 문제를 확인할 때는 “최초 다운로드 실패”와 “업데이트는 실패했지만 이전 규칙이 계속 적용되는 상태”를 구분해야 합니다. 캐시를 삭제한 뒤 재시도하면 이 복구 조건을 잃게 되므로 첫 단계로 수행하지 마세요.

규칙 순서가 곧 우선순위입니다

Clash는 위에서 아래로 내려가며 처음 매칭되는 규칙을 찾고, 매칭되면 이후 규칙을 더 확인하지 않습니다. 구체적인 규칙은 포괄적인 규칙보다 앞에 배치해야 합니다. 사설 도메인과 로컬 네트워크는 보통 먼저 직접 연결하고, 서비스 도메인은 해당 정책으로 보내며, IP 규칙은 주소 확인이 필요한 위치에 배치하고, 마지막에 MATCH로 나머지 트래픽을 처리합니다. 넓은 범위의 프록시 규칙을 맨 위에 두면 뒤에 있는 직접 연결 예외는 영원히 실행되지 않습니다. 잘못된 분기 문제를 확인할 때는 도메인이 어떤 분류에 속하는지 추측하기보다 로그에서 “어떤 규칙에 매칭됐는지” 확인하는 편이 정확합니다.

no-resolve는 IP 규칙을 매칭할 때 IP를 얻기 위해 DNS 조회를 능동적으로 수행하지 않도록 합니다. 불필요한 조회를 줄일 수 있지만 모든 규칙 뒤에 기계적으로 추가해서는 안 됩니다. 도메인 요청에 앞선 도메인 규칙이 없고 이후 GEOIP 판단에 의존한다면, 조회를 완전히 막아 해당 규칙에 필요한 주소를 얻지 못할 수 있습니다. 추가 여부는 규칙 유형과 DNS 모드에 따라 결정하세요. 대상 IP를 이미 직접 알고 있는 연결은 IP 규칙으로 정상 매칭할 수 있습니다.

로컬의 소수 예외는 rules 맨 위에 직접 작성하면 됩니다. 서너 개 항목을 위해 원격 규칙 세트를 만들 필요는 없습니다. 특정 업무 도메인을 반드시 직접 연결하거나 어떤 앱의 API를 “개발 서비스”에 고정해야 한다면, 구독 규칙 세트보다 앞에 해당 규칙을 배치하세요. 예외가 계속 늘어나면 로컬 provider로 옮기면 됩니다. 이렇게 하면 주 설정의 가독성을 유지하면서 사소한 변경마다 원격 파일을 배포하지 않아도 됩니다.

rules:
  - DOMAIN,router.local,DIRECT
  - DOMAIN-SUFFIX,corp.example,DIRECT
  - DOMAIN-SUFFIX,github.com,개발 서비스
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,developer,개발 서비스
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,전체 선택

규칙 세트 장애를 확인하는 순서

먼저 provider 상태가 로드를 완료했는지 확인하고, 원격 응답 내용이 선언한 형식과 일치하는지 살펴보세요. 그다음 규칙 세트 이름이 RULE-SET 참조와 일치하는지 확인하고 마지막으로 호출 위치를 점검합니다. 상태는 정상인데 전혀 매칭되지 않는다면 동작 유형이 잘못되었거나, 앞선 포괄 규칙에 가로막혔거나, 대상 연결이 IP만 노출하는데 규칙 세트에는 도메인만 있는 것이 흔한 원인입니다. 업데이트 후 잘못된 분기가 급증했다면 이전 로컬 캐시를 복원하거나 해당 규칙 세트를 일시적으로 주석 처리해 문제가 상위 공급원 변경에서 비롯됐는지 확인하세요.

규칙 공급원이 많아질수록 업데이트 주기와 이름을 통일하기 어려워집니다. 더 안정적인 구조는 용도에 맞는 소수의 규칙 세트만 선택하고, 각 서비스에 하나의 주요 공급원만 두며, 로컬 예외를 최우선으로 배치하는 것입니다. 범위가 비슷한 전체 규칙 세트를 여러 개 동시에 추가한 뒤 순서가 충돌을 자동으로 해결해 주기를 기대하지 마세요. 여러 기기에서 동기화해야 한다면 다중 기기 설정 동기화 방법을 참고해 주 설정, 구독 링크와 로컬 규칙을 분리해 관리하세요.

Chapter 05 / Network stack

TUN 모드와 Fake-IP 연동

시스템 프록시는 프록시 설정을 능동적으로 따르는 앱만 처리할 수 있습니다. 명령줄 도구, 일부 게임, 독립 네트워크 스택을 사용하는 앱, UDP를 직접 전송하는 프로그램은 시스템 프록시를 완전히 우회할 수 있습니다. TUN 모드는 가상 네트워크 인터페이스로 시스템 라우팅을 연결하고 이런 트래픽을 Clash 커널로 보내므로 적용 범위가 더 넓습니다. Fake-IP는 DNS 단계에서 매핑 주소를 반환해 커널이 연결을 받을 때 원래 도메인을 복원하고 도메인 규칙을 실행하도록 합니다. 두 기능은 자주 함께 사용되지만 역할은 다릅니다. TUN은 트래픽을 안으로 들여오고 Fake-IP는 도메인 의미를 보존합니다.

TUN 필드와 시스템 권한

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

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

stack은 TUN이 사용할 네트워크 스택 구현을 결정합니다. 지원되는 커널에서 mixed는 호환성과 성능을 균형 있게 제공하며, 특정 플랫폼에서 문제가 생기면 system 또는 gvisor를 각각 테스트할 수 있습니다. 단, 비교 기준 없이 자주 전환하지 마세요. auto-route는 라우팅을 자동으로 작성하고, auto-detect-interface는 현재 출구 네트워크 인터페이스를 식별하려고 합니다. Wi-Fi, 모바일 네트워크, 유선 네트워크 사이를 전환할 때 이 옵션은 인터페이스를 수동으로 지정하는 부담을 줄입니다. strict-route는 트래픽 우회를 더 엄격하게 막지만 다른 VPN, 가상 머신, 컨테이너 네트워크와 라우팅 충돌을 일으킬 수 있습니다.

TUN을 시작하려면 시스템 수준의 VPN 또는 네트워크 확장 권한이 필요합니다. Windows 클라이언트는 서비스 모드로 네트워크 작업 권한을 높일 수 있고, macOS는 네트워크 확장을 허용해야 하며, Android와 iOS에서는 시스템 VPN 승인이 표시됩니다. 권한을 거부하면 화면의 스위치가 잠시 켜졌다가 다시 꺼질 수 있고, 로그에 장치 생성 또는 라우팅 작성 오류가 나타납니다. 이때 구독을 반복해서 가져와도 소용이 없으므로 먼저 시스템 권한을 처리하세요. macOS의 구체적인 대화상자와 복구 절차는 네트워크 확장 및 키체인 처리 가이드를 참고하세요.

Fake-IP 매핑 과정

Fake-IP 모드는 도메인 조회를 받으면 실제 주소를 앱에 바로 전달하지 않고 예약된 주소 대역에서 매핑 값을 할당합니다. 앱이 해당 주소로 연결하면 커널이 매핑 테이블을 통해 도메인을 복원한 뒤 DOMAIN, DOMAIN-SUFFIX 또는 규칙 세트와 매칭합니다. 앱이 대상 주소만 네트워크 계층에 전달하더라도 Clash가 원래 도메인을 파악할 수 있다는 점이 장점입니다. 매핑 주소는 원격 서버 주소가 아니므로 공용 인터넷 라우팅 테스트에 사용해서는 안 됩니다. 198.18.0.0/16 범위의 결과가 보인다면 일반적으로 Fake-IP가 정상적으로 조회에 참여하고 있다는 뜻입니다.

일부 로컬 네트워크 검색, 시간 동기화, 프린터, 게임 플랫폼 또는 실제 DNS 응답에 의존하는 프로그램은 Fake-IP와 맞지 않으므로 fake-ip-filter에 추가해야 합니다. 필터 범위는 가능한 한 구체적으로 지정하세요. 너무 넓은 도메인 집합을 제외하면 많은 요청이 실제 주소 모드로 돌아가 도메인 복원 효과가 약해지고 IP 매칭 규칙에 의존하게 될 수 있습니다. 호환성 문제가 생기면 먼저 로그에서 도메인을 확인하고 접미사 하나씩 추가하며 다시 테스트하세요. 출처가 불분명한 긴 필터 목록을 그대로 복사하지 마세요.

MTU, UDP 및 네트워크 전환

페이지는 열리지만 일부 이미지, 업로드 또는 특정 앱이 멈춘다면 경로 MTU가 맞지 않을 수 있습니다. TUN 캡슐화는 추가 오버헤드를 만들며, 하위 네트워크에 이미 VPN, PPPoE 또는 모바일 네트워크 제한이 있다면 1500바이트에서 단편화나 패킷 손실이 발생할 수 있습니다. 다른 설정은 유지한 채 MTU를 단계적으로 낮춰 보세요. 예를 들어 1400 안팎부터 테스트하고 문제가 안정적으로 사라지는지 관찰할 수 있습니다. MTU가 작을수록 안전한 것은 아닙니다. 너무 작으면 패킷 수와 처리 비용이 늘어나므로 효과를 확인한 뒤 안정적으로 작동하는 가장 큰 값을 선택하세요.

UDP 문제는 세 가지 계층으로 나눠 확인해야 합니다. 앱이 UDP를 전송하는지, TUN이 이를 연결하는지, 노드 프로토콜과 네트워크가 해당 전송을 지원하는지입니다. DNS 조회, QUIC, 게임과 음성 통화는 모두 UDP를 사용할 수 있습니다. QUIC을 끈 뒤 브라우저가 복구되었다고 해서 UDP 경로에 문제가 집중되었다는 뜻일 뿐, DNS나 노드 전체를 사용할 수 없다는 의미는 아닙니다. 모바일 기기가 Wi-Fi와 셀룰러 네트워크 사이를 전환한 뒤에는 이전 세션이 기존 인터페이스에 묶여 있을 수 있으므로, 필요하다면 전체 설정을 지우기보다 TUN을 다시 연결하세요.

활성화 순서는 다음과 같습니다. 먼저 시스템 프록시로 노드와 규칙이 정상인지 확인하고, 그다음 TUN만 켜서 라우팅과 권한을 확인한 뒤, 마지막으로 Fake-IP를 활성화하고 소수의 호환성 예외를 처리하세요. TUN을 켠 뒤 기기 전체가 인터넷에 연결되지 않으면 먼저 TUN을 꺼서 네트워크를 복구한 다음 기본 라우팅, DNS 가로채기, 다른 VPN을 확인하세요. Windows 서비스 모드, 포트 충돌과 시스템 프록시 설정은 Windows 설치 및 설정 전체 과정에서 확인할 수 있습니다.

Chapter 07 / Merge

로컬 오버라이드 및 다중 구독 병합

구독은 원격에서 관리되는 노드와 기본 설정을 제공하고, 로컬 오버라이드는 기기나 개인 환경에만 필요한 조정을 저장합니다. 두 내용을 같은 파일에서 직접 수정하면 다음 구독 업데이트에서 로컬 내용이 덮어써질 수 있고, 완전히 정적인 설정으로 복사하면 노드 업데이트를 잃게 됩니다. 더 나은 구조는 구독을 상위 입력으로 두고 포트, DNS, 프록시 그룹 추가, 규칙 우선 배치와 TUN 설정을 반복 적용 가능한 오버라이드 계층에 넣는 것입니다. 클라이언트마다 오버라이드 기능의 이름은 Merge, Mixin, Script 또는 전역 확장 등으로 다를 수 있지만, 업데이트 후 적용 설정을 다시 생성한다는 목표는 같습니다.

교체, 추가와 깊은 병합을 구분하세요

YAML 객체는 키 기준으로 병합할 수 있지만 배열은 의미가 다를 수 있습니다. dns.enable을 수정하면 보통 단일 필드만 교체하지만, rules는 규칙을 앞에 추가할지, 뒤에 추가할지, 배열 전체를 교체할지 명확히 해야 합니다. 병합기가 새 배열로 기존 배열을 직접 덮어쓰면 로컬 규칙 세 개만 포함한 오버라이드가 구독의 기존 규칙을 모두 없앨 수 있습니다. 클라이언트 내장 병합 기능을 사용하기 전에는 오버라이드 조각이 저장됐는지만 보지 말고 최종 적용 설정을 확인하세요.

prepend-rules:
  - DOMAIN,router.local,DIRECT
  - DOMAIN-SUFFIX,corp.example,DIRECT

append-rules:
  - MATCH,전체 선택

override:
  mode: rule
  log-level: info
  ipv6: false

위 구조는 “앞에 추가, 뒤에 추가, 교체”라는 세 가지 의도를 설명하기 위한 것입니다. 구체적인 키 이름은 클라이언트의 병합 구현에 따라 달라지므로 확인 없이 mihomo 기본 설정으로 바로 불러와서는 안 됩니다. mihomo가 최종적으로 받는 것은 완전한 설정 한 부입니다. 검증하려면 클라이언트가 생성한 런타임 설정을 열어 로컬 규칙이 예상 위치에 있는지, 프록시 그룹이 중복되지 않았는지, 최종적으로 MATCH가 하나만 남았는지 확인하세요. 클라이언트에 설정 검사 기능이 있다면 업데이트마다 한 번씩 실행하는 것이 좋습니다.

다중 구독 병합은 노드 계층 중심으로 구성하세요

여러 구독을 동시에 사용할 때는 보통 각각을 서로 다른 proxy-providers로 선언하고, 로컬 프록시 그룹에서 use로 불러오는 방식이 가장 안정적입니다. 여러 완전한 설정 파일을 직접 이어 붙이면 각 파일에 포트, DNS, 프록시 그룹과 규칙이 들어 있어 같은 키가 덮어쓰이고 같은 그룹이 충돌할 수 있으며, 최종 결과가 병합 도구의 구현에 따라 달라집니다. 노드 제공자는 노드 모음만 담당하고, 로컬 주 설정은 정책과 규칙을 통합해 역할을 분명히 유지하세요.

proxy-providers:
  primary:
    type: http
    url: https://example.com/subscription/primary
    path: ./providers/primary.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

  backup:
    type: http
    url: https://example.com/subscription/backup
    path: ./providers/backup.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 900

proxy-groups:
  - name: 전체 선택
    type: select
    use:
      - primary
      - backup
    proxies:
      - DIRECT

예시의 구독 주소는 구조를 보여 주기 위한 것이므로 실제 사용 시 자신의 유효한 주소로 바꾸고, 접근 인증 정보가 포함된 링크를 문서, 스크린샷 또는 공유 저장소에 공개하지 마세요. 두 provider는 서로 다른 캐시 경로를 사용해야 합니다. 상태 확인 간격은 기기와 노드 수에 맞춰 조정할 수 있지만, 모바일에서는 많은 노드를 높은 빈도로 조회하지 않는 것이 좋습니다. 상위 노드 이름이 중복되면 화면에서 출처를 구분하기 어려우므로, 병합 계층에서 클라이언트가 지원하는 접두사 기능을 사용하거나 provider별로 독립된 지역 그룹에 넣으세요. 긴 목록에 바로 섞어 넣는 방식은 피하는 편이 좋습니다.

업데이트 실패와 설정 드리프트

다중 구독 환경에서 흔한 문제는 특정 설정을 불러오지 못하는 것이 아니라, 시간이 지나면서 기대한 상태에서 조금씩 벗어나는 것입니다. 상위 공급원이 노드 이름을 바꾸면 필터 표현식이 무효화될 수 있고, 특정 지역이 삭제되면 프록시 그룹이 빈 그룹이 될 수 있으며, 같은 이름의 노드가 추가되면 수동 선택이 다른 출처를 가리킬 수 있습니다. 업데이트 후에는 provider 상태, 프록시 그룹 구성원 수의 적정성, 핵심 서비스 규칙이 여전히 존재하는 그룹을 가리키는지 확인하세요. 감시 조건으로 임의의 고정 노드 수를 사용하지 말고 “그룹이 비어 있는지”, “참조 대상이 존재하는지”, “핵심 요청이 매칭되는지”에 집중하세요.

여러 기기에서 동기화할 때 클라이언트 전체 데이터 디렉터리를 그대로 동기화하는 것은 권장하지 않습니다. 데스크톱과 모바일은 권한, 경로, TUN 인터페이스 이름, 캐시 위치가 서로 다릅니다. 동기화하기에 적합한 것은 구독 진입점, 로컬 주 설정 템플릿, 규칙 세트와 오버라이드 로직이며, 기기 전용 항목은 각 클라이언트에 남겨 두세요. WebDAV, 구독 배포와 수동 가져오기의 차이는 Clash 다중 기기 설정 동기화 방법에서 더 확인할 수 있습니다.