Clash 멀티 디바이스 설정 동기화 비교: 구독 링크, WebDAV, 수동 내보내기

먼저 동기화할 설정의 범위를 구분하세요

Clash의 ‘설정’은 하나의 파일만을 의미하지 않습니다. 컴퓨터와 스마트폰에 노드, 규칙, 프록시 그룹이 표시되더라도 원격 구독에서 가져온 내용일 수 있고 클라이언트 자체 데이터베이스에 저장된 내용일 수도 있습니다. 동기화를 시작하기 전에 데이터를 세 가지 계층으로 나누면 적합한 방법을 훨씬 쉽게 선택할 수 있습니다.

핵심 설정: 노드, 프록시 그룹, 규칙, DNS

핵심 설정은 보통 YAML 파일이며 proxies, proxy-groups, rules, dns 등의 필드를 포함합니다. mihomo 코어는 rule-providers, proxy-providers, sniffer와 더 다양한 TUN 매개변수도 지원합니다. 이 계층은 구독 링크로 중앙 배포하는 방식이 가장 적합합니다.

mixed-port: 7890
mode: rule
allow-lan: false

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

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

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

클라이언트 설정: 시스템 프록시, TUN, 시작 동작

‘시작 시 연결’, ‘시스템 시작 시 실행’, ‘시스템 프록시’, ‘LAN 연결 허용’ 같은 스위치는 대개 클라이언트 로컬 설정에 속합니다. 두 기기에 같은 YAML을 가져와도 이러한 옵션까지 동기화되지는 않습니다. Windows에서 시스템 프록시를 활성화해도 Android나 iOS에서 VPN이 자동으로 연결되는 것은 아니며, macOS의 TUN 권한 역시 설정 파일만으로 다른 기기에 복사할 수 없습니다.

실행 상태: 현재 노드와 지연 시간 기록

현재 선택된 노드, 최근 속도 측정 결과, 로그, 트래픽 통계는 대부분 실행 상태로 관리됩니다. 클라이언트 데이터베이스에 기록될 수도 있고 재시작 후 초기화될 수도 있습니다. 이러한 상태까지 동기화 대상으로 삼으면 ‘설정은 같은데 화면은 다른’ 결과가 생기기 쉽습니다. 프록시 그룹 구조만 동기화하고 각 기기에서 직접 속도를 측정해 노드를 선택하는 편이 더 안정적입니다.

방법 1: 구독 링크로 중앙 배포하기

구독 링크는 두 대 이상의 기기를 장기간 사용할 때 적합하며 규칙을 가장 간편하게 관리할 수 있는 방법입니다. 서버에 기본 설정 하나를 저장하고 컴퓨터, 스마트폰, 태블릿에서 같은 구독 주소를 추가합니다. 규칙이 바뀌면 원본만 수정한 뒤 각 기기에서 업데이트를 실행하면 됩니다.

실제 설정 순서

신뢰할 수 있는 구독 관리 서비스에서 기본 설정을 준비하고, 대상 코어가 YAML을 정상적으로 불러오는지 확인합니다.
데스크톱 클라이언트에서 ‘설정’ → ‘구독’ 또는 ‘Profiles’ → ‘New Profile’로 이동해 HTTPS 주소를 붙여 넣습니다.
모바일 클라이언트에서 ‘설정’ → ‘URL에서 가져오기’로 이동해 같은 주소를 입력하고 저장합니다.
자동 업데이트 주기를 설정합니다. 일반적인 사용에는 1440분, 규칙 변경이 잦다면 360분으로 설정할 수 있습니다.
첫 업데이트가 완료되면 프록시 그룹 수, 규칙 수, DNS 모드, 마지막 업데이트 시간을 확인합니다.

클라이언트마다 메뉴 이름은 다를 수 있습니다. 일부 데스크톱 클라이언트는 ‘설정’ → ‘새로 만들기’ → ‘URL’을 사용하고, 일부 모바일 클라이언트는 ‘설정’ 오른쪽 위의 더하기 버튼에 해당 메뉴를 둡니다. ‘업데이트 완료’만 보고 성공 여부를 판단하지 말고 설정 세부 정보에서 파일 크기가 0KB가 아닌지, YAML 파싱 오류가 없는지도 확인해야 합니다.

기기별 차이는 로컬에 남겨 두세요

하나의 구독에 모든 기기의 로컬 매개변수를 강제로 넣는 것은 바람직하지 않습니다. 데스크톱에서는 mixed-port: 7890이 필요할 수 있지만 모바일에서는 시스템 VPN 인터페이스가 트래픽을 처리하므로 이 포트를 사용하지 않습니다. TUN의 네트워크 인터페이스 이름, 라우팅 권한, DNS 하이재킹 방식도 플랫폼마다 다릅니다.

안정적인 구조는 원격 구독이 노드, 프록시 그룹, 규칙 집합, 공통 DNS 정책을 담당하고, 시스템 프록시, TUN, LAN 접근, 시작 동작은 각 기기에 저장하는 방식입니다. 클라이언트가 오버라이드나 Mixin을 지원한다면 전체 기본 설정을 복사하지 말고 로컬에 필요한 매개변수만 추가하세요.

# 기본 설정은 공통 로직을 담당
mode: rule
log-level: info

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

구독 방식의 한계

네트워크 연결 필요: 새 기기에서 처음 가져올 때 구독 주소에 접속할 수 있어야 설정을 받을 수 있습니다.
업데이트 시 로컬 수정 내용이 덮어써질 수 있음: 내려받은 구독 파일을 직접 수정해도 다음 새로 고침에서 원격 버전으로 되돌아가는 경우가 많습니다.
링크 자체를 보호해야 함: 구독 URL에 액세스 토큰이 포함될 수 있으므로 공개 저장소, 스크린샷, 단체 채팅 기록에 올려서는 안 됩니다.
클라이언트별 변환 동작 차이: 일부 클라이언트는 필드를 자동 변환하지만 다른 클라이언트는 원본 YAML을 엄격하게 파싱합니다.

방법 2: WebDAV로 백업 및 복원하기

WebDAV는 동일한 YAML을 실시간으로 함께 편집하는 방식이라기보다 ‘클라이언트 스냅샷을 저장하는’ 방식에 가깝습니다. WebDAV를 지원하는 클라이언트는 설정, 환경설정, 백업 패키지를 원격 디렉터리에 업로드하고 다른 기기에서 내려받아 복원합니다. 기기 교체나 동일 클라이언트로의 이전에는 적합하지만, 플랫폼 간 호환성은 백업 내용에 따라 달라집니다.

먼저 클라이언트가 실제로 무엇을 백업하는지 확인하세요

어떤 클라이언트는 구독 목록만 업로드하고, 어떤 클라이언트는 로컬 설정, 프록시 그룹 선택, 앱 설정까지 함께 저장합니다. WebDAV 기능 없이 수동 가져오기·내보내기만 제공하는 경우도 있습니다. 작업 전에 ‘설정’ → ‘백업 및 복원’ 또는 ‘설정’ → ‘WebDAV’를 열어 구독, 오버라이드, 규칙, 로컬 환경설명이 포함되는지 확인하세요.

백업 패키지에 클라이언트 데이터베이스가 포함되어 있다면 보통 같은 앱 또는 호환 버전에서만 복원할 수 있습니다. 예를 들어 버전 2.1.0에서 만든 데이터베이스를 다른 mihomo 그래픽 클라이언트가 읽지 못할 수 있습니다. 양쪽이 모두 mihomo 코어를 사용하더라도 UI 계층의 데이터 구조는 다를 수 있습니다.

권장 WebDAV 작업 순서

첫 번째 기기에서 ‘설정’ → ‘백업 및 복원’ → ‘WebDAV’로 이동합니다.
HTTPS 서버 주소, 사용자 이름, 앱 전용 비밀번호, 원격 디렉터리를 입력합니다.
‘연결 테스트’를 눌러 성공 응답을 확인한 뒤 수동 백업을 한 번 실행합니다.
백업 시간과 파일 크기를 기록합니다. 예를 들어 정상 백업이 428KB인데 새 파일이 2KB뿐이라면 먼저 내용이 완전한지 확인해야 합니다.
두 번째 기기에 같은 클라이언트를 설치하고, 먼저 시스템 프록시나 VPN을 활성화하지 않은 상태로 둡니다.
같은 WebDAV 디렉터리에 연결한 뒤 방금 생성한 백업을 선택해 복원합니다.
복원 후 VPN, TUN, 시스템 프록시를 다시 승인하고 규칙 매칭을 테스트합니다.

WebDAV 주소는 서버 루트 경로만 입력해야 할 수도 있고 전체 디렉터리 경로가 필요할 수도 있습니다. 예를 들어 서버 진입점이 https://dav.example.net/remote.php/dav/files/user/인데 클라이언트가 사용자 이름을 자동으로 덧붙이면 경로가 중복되어 HTTP 404가 반환될 수 있습니다. HTTP 401은 일반적으로 계정이나 앱 비밀번호 오류를 뜻하고, HTTP 403은 디렉터리에 쓰기 권한이 없을 때 자주 발생합니다.

두 기기가 서로의 백업을 덮어쓰지 않게 하세요

WebDAV가 설정 충돌 병합을 지원하는 것은 아닙니다. 컴퓨터가 10:20에 업로드하고 스마트폰이 10:23에 오래된 설정을 다시 업로드하면 서버의 최신 파일에 방금 수정한 규칙이 오히려 빠질 수 있습니다. 한 대를 업로드 전용 주 기기로 정하고 다른 기기는 기본적으로 복원만 하거나, 기기 이름별로 디렉터리를 나누는 편이 안전합니다.

/ClashBackup/
  desktop-main/
    backup-2026-06-20.zip
  macbook/
    backup-2026-06-20.zip
  phone/
    backup-2026-06-20.zip

클라이언트가 이전 버전 보존을 지원한다면 최근 백업을 최소 3개 이상 남기는 것이 좋습니다. 한 번의 잘못된 덮어쓰기로 모든 백업이 즉시 손상되는 일을 막을 수 있습니다. 복원 전에는 현재 설정도 먼저 내보내야 하며, 특히 스마트폰에 로컬 오버라이드가 이미 있다면 더욱 그렇습니다.

방법 3: YAML 또는 백업 파일 수동 내보내기

수동 내보내기는 가장 직관적이고 변경 범위도 가장 쉽게 통제할 수 있습니다. 원격 서비스에 의존하지 않으므로 기기가 두 대뿐이거나 설정 변경이 적을 때, 또는 오프라인으로 이전해야 할 때 적합합니다. 일반적인 메뉴는 ‘설정’ → ‘설정 디렉터리 열기’, ‘설정’ → ‘내보내기’, 또는 설정 항목 오른쪽의 공유 메뉴입니다.

YAML 내보내기와 전체 백업은 다릅니다

YAML 내보내기로는 보통 핵심 설정만 가져올 수 있습니다. 시스템 프록시 스위치, 현재 노드, 클라이언트 테마, 단축키, TUN 권한은 새 기기에서 다시 설정해야 합니다. 전체 백업에는 더 많은 앱 상태가 포함될 수 있지만 다른 클라이언트로 옮기기는 더 어렵습니다.

Windows에서 macOS로 이전한다면 표준 YAML을 우선 내보내세요. 같은 모바일 앱 사이에서 기기를 교체하는 경우에는 앱에서 제공하는 백업 패키지를 우선 사용하는 편이 좋습니다. 실행 디렉터리 전체를 그대로 복사하지 마세요. 캐시, 로그, 데이터베이스 잠금 파일, 특정 플랫폼 경로가 섞여 있을 수 있습니다.

가져오기 전 확인할 네 가지

포트 충돌: 다른 프로그램이 mixed-port: 7890을 사용 중이면 7891로 변경한 뒤 다시 불러옵니다.
절대 경로: C:\Users\name\rules\local.yaml은 macOS나 Android에서 그대로 사용할 수 없습니다.
규칙 파일: rule-providers가 참조하는 로컬 파일도 함께 복사했는지 확인합니다.
코어 필드: 대상 클라이언트가 geodata-mode, sniffer, tun 등의 옵션을 지원하는지 확인합니다.

가져온 직후 전역 TUN을 바로 켜지 마세요. 먼저 코어를 시작하고 로그에서 설정 로드 결과를 확인한 다음 시스템 프록시로 기본 동작을 테스트하세요. 데스크톱에서 흔히 사용하는 HTTP·SOCKS 혼합 포트는 7890이고 컨트롤러 포트는 9090인 경우가 많지만 실제 값은 설정을 기준으로 해야 합니다.

파일명으로 버전 단서를 남기세요

수동 복사에서 가장 흔한 문제는 파일이 사라지는 것이 아니라 어느 파일이 최신인지 구분하기 어렵다는 점입니다. 파일명에 날짜, 기기 용도, 수정 번호를 포함하세요. 예를 들면 clash-main-2026-06-20-r03.yaml처럼 지정할 수 있습니다. 한 번에 한 가지 주제만 수정하고 같은 디렉터리에 간단한 변경 기록도 저장하세요.

2026-06-20 r03
- DIRECT LAN 규칙 추가
- 자동 선택 테스트 주기를 300초로 조정
- Fake-IP 모드 유지
- 데스크톱에서는 로컬 TUN 활성화, 모바일에서는 기본 설정에 기록하지 않음

두 기기에서 파일을 각각 수정했다면 파일 크기만으로 최신 여부를 판단하지 마세요. proxy-groups, rule-providers, rules를 구간별로 비교하고, 규칙은 위에서 아래 순서로 매칭된다는 점에 특히 주의하세요. 순서가 바뀌면 연결 경로가 바로 달라질 수 있습니다.

세 가지 동기화 방식 선택하기

세 가지 방법은 서로 배타적이지 않습니다. 구독은 지속적인 배포를, WebDAV는 클라이언트 상태 복원을, 수동 내보내기는 오프라인 보관을 담당하는 조합이 실제 사용에 더 가깝습니다. 아래에서 관리 비용과 호환 범위를 비교합니다.

방식	적합한 기기 수	주요 동기화 내용	클라이언트 간 호환성	대표적인 용도
구독 링크	2대 이상	노드, 프록시 그룹, 규칙, 공통 DNS	높은 편이나 코어 필드의 영향을 받음	장기간 중앙 관리
WebDAV	1~3대	구독 목록, 클라이언트 설정 또는 백업 패키지	보통이며 같은 클라이언트를 요구하는 경우가 많음	기기 교체 및 복원
수동 내보내기	1~2대	YAML 파일 하나 또는 전체 백업	YAML은 높은 편, 백업 패키지는 낮은 편	오프라인 이전 및 보관

개인 기기 2대

컴퓨터와 스마트폰을 자주 사용하지 않고 규칙을 한 달에 한두 번만 바꾼다면 YAML을 직접 내보내도 충분합니다. 수정할 때마다 날짜와 수정 번호를 갱신한 뒤 시스템 파일 공유 기능으로 다른 기기에 가져오세요. 노드가 구독 서비스에서 제공된다면 오버라이드와 사용자 지정 규칙만 수동으로 관리하면 됩니다.

컴퓨터, 스마트폰, 태블릿을 장기간 함께 사용

구독 링크를 기본 방식으로 사용하는 것이 좋습니다. 프록시 그룹 이름을 ‘노드 선택’, ‘자동 선택’, ‘장애 조치’처럼 통일하면 기기별 화면을 확인하기도 쉽습니다. WebDAV는 클라이언트 백업만 저장하고 일상적인 규칙 편집에는 사용하지 마세요.

자주 재설치하거나 여러 클라이언트를 테스트

가능한 한 표준에 가까운 mihomo YAML을 기준 설정으로 보관하고, 특정 그래픽 클라이언트의 데이터베이스를 유일한 원본으로 삼지 마세요. 클라이언트 전용 기능은 로컬 오버라이드로 추가합니다. 업그레이드 전마다 수동 내보내기를 하고 WebDAV에는 최근 복원 가능한 스냅샷 3개를 저장하세요.

여러 플랫폼에서 규칙을 일관되게 유지하는 실전 방법

프록시 그룹 이름을 통일해 규칙 대상이 무효화되지 않게 하기

규칙 끝의 정책 이름은 프록시 그룹 이름과 완전히 같아야 합니다. 기본 설정에 DOMAIN-SUFFIX,example.com,노드 선택이 적혀 있는데 모바일에서 프록시 그룹 이름을 ‘수동 선택’으로 바꾸면 로드 오류가 발생하거나 원하는 트래픽 분리가 되지 않을 수 있습니다. 이름을 정한 뒤에는 한 기기에서만 따로 수정하지 않는 것이 좋습니다.

플랫폼별 차이는 오버라이드 계층에 모으기

공통 설정에는 노드, 규칙, DNS의 기본 로직을 남기고 플랫폼별 매개변수는 로컬 오버라이드에 넣으세요. Windows에서는 7890 혼합 포트와 시스템 프록시를 사용할 수 있고, macOS에서는 클라이언트 권한에 따라 TUN을 설정합니다. Android와 iOS는 앱이 VPN 인터페이스를 만듭니다. 이렇게 하면 구독을 업데이트할 때 플랫폼 설정이 반복해서 덮어써지지 않습니다.

고정 테스트 체크리스트

동기화할 때마다 같은 순서로 확인하면 보통 3분 안에 대부분의 문제를 발견할 수 있습니다:

설정 업데이트 시간이 예상과 일치하는지 확인합니다.
프록시 그룹 수와 기본 선택 항목이 같은지 확인합니다.
자동 선택 그룹에서 지연 시간 테스트를 한 번 실행하고 사용 가능한 노드 수를 기록합니다.
로그를 열어 yaml, provider, dns 관련 오류가 없는지 확인합니다.
DIRECT로 연결되어야 하는 사이트와 프록시를 거쳐야 하는 사이트에 각각 접속해 규칙이 올바르게 적용되는지 확인합니다.
시스템 프록시나 VPN을 껐다가 다시 켜고 설정을 다시 불러온 뒤에도 정상 작동하는지 확인합니다.

차이가 생기면 먼저 업데이트 경로를 확인하세요

한 기기에서는 규칙이 정상인데 다른 기기에서 이전 내용이 계속 사용된다면 먼저 구독 업데이트 시간을 비교한 뒤 원격 파일이 캐시되고 있는지 확인하세요. 자동 업데이트 주기가 1440분이면 방금 수정한 내용이 즉시 나타나지 않으므로 ‘업데이트’를 직접 눌러야 합니다. 업데이트 후에도 다르면 클라이언트가 오래된 로컬 설정을 사용하고 있는지, 오버라이드가 규칙을 수정했는지, 대상 코어가 지원하지 않는 필드를 건너뛰었는지 확인하세요.

장기간 유지하기 좋은 조합

대부분의 멀티 플랫폼 사용자에게는 ‘구독 기본 설정 + 로컬 플랫폼 설정 + 정기적인 수동 백업’ 구조가 적합합니다. 기본 설정은 HTTPS 구독으로 노드, 프록시 그룹, 규칙, 공통 DNS를 통일하고, 각 기기에서 시스템 프록시, TUN, VPN 권한, 시작 동작을 별도로 관리합니다. 설정을 크게 변경하기 전에는 날짜가 포함된 YAML 파일을 하나 내보내세요.

클라이언트가 WebDAV를 지원한다면 복원 계층을 추가할 수 있습니다. 매주 또는 업그레이드 전에 백업을 한 번 업로드하고 최근 3~5개만 보관하세요. WebDAV는 규칙을 병합하지 않으며 구독을 대신하지도 않습니다. 따라서 구독 내용에 문제가 생겨도 수동 파일이나 이전 백업에서 되돌릴 수 있습니다.

동기화의 핵심은 모든 기기의 화면을 완전히 똑같이 만드는 것이 아니라 규칙의 의도를 일치시키는 데 있습니다. 같은 도메인은 같은 정책에 매칭되고, 같은 프록시 그룹은 같은 용도로 사용하며, 플랫폼 전용 매개변수는 각 기기에 남겨 두는 방식입니다. 기본 설정과 로컬 상태를 분리하면 멀티 디바이스 관리는 ‘집 전체를 복사하는 일’에서 ‘필요한 서랍만 옮기는 일’로 바뀝니다.