Clash 멀티 디바이스 설정 동기화 방법 비교: 구독 링크, WebDAV 백업, 수동 내보내기는 각각 누구에게 맞을까
휴대폰, PC, 태블릿에 각각 클라이언트를 설치하면 설정을 어떻게 일치시켜야 할까요? 이 글에서는 구독 링크로 일괄 배포하는 방식, WebDAV 클라우드 백업, 수동 내보내기/가져오기 세 가지 방법의 적용 상황, 작업 비용, 흔한 함정을 비교합니다.
멀티 디바이스 설정이 "각자 따로 놀기" 쉬운 이유
PC에는 Clash Verge Rev를, 휴대폰에는 FlClash나 Clash Meta for Android를, 태블릿에는 또 ClashX Meta를 설치하는 것—이것이 대부분 사용자의 실제 사용 형태입니다. 문제는 Clash 계열 클라이언트의 핵심 설정(프록시 노드, 규칙 세트, DNS 구간)이 보통 하나의 로컬 YAML 파일로 저장되고, 세 대의 기기가 각자 한 벌씩 관리하다 보면 시간이 지나면서 노드 정보가 오래되거나 규칙 버전이 서로 달라지거나 어느 한 기기의 업데이트가 빠지는 상황이 발생한다는 점입니다. 더 곤란한 것은, 규칙을 수동으로 손보는 습관이 있는 경우(예: 특정 도메인에 DIRECT 규칙 하나를 추가) 그 수정 내용이 그 순간 사용하던 기기에만 남고, 다른 기기로 바꾸면 찾을 수 없다는 점입니다.
해결 방향은 크게 세 가지입니다: 설정이 "스스로 업데이트"되게 하기(구독 링크), 설정을 "클라우드에 저장"하기(WebDAV 백업), 설정을 "사람이 직접 옮기기"(내보내기/가져오기). 세 방법은 서로 배타적이지 않고 실제로는 조합해서 쓰는 경우가 많지만, 중점과 유지 비용이 크게 다르므로 잘못 선택하면 나중에 계속 구멍을 메워야 합니다.
방법 1: 구독 링크로 일괄 배포
가장 흔하면서도 주력 방식으로 가장 추천되는 방법입니다. 서비스 제공업체가 구독 링크(Subscription URL)를 하나 주면, 클라이언트가 주기적으로 이 링크를 요청해서 최신 노드 목록을 받아오고, 클라이언트에 설정한 규칙 템플릿에 따라 완전한 설정으로 재구성합니다. 여러 기기가 모두 같은 구독 링크를 입력해두면, 이론적으로는 노드 정보가 동기화된 상태를 유지할 수 있습니다—모두가 같은 "원본"에서 가져오기 때문입니다.
# 일반적인 구독 링크 구조 예시
https://sub.example-provider.com/link/abcdef123456?clash=1
# 클라이언트는 내부적으로 이 링크를 주기적으로 요청하여 proxies와 proxy-groups 필드를 갱신합니다
구독 링크 동기화의 한계는 명확히 알아둬야 합니다: 동기화되는 것은 노드와 서비스 제공업체가 미리 만들어둔 그룹 템플릿이며, 로컬에서 새로 추가한 사용자 정의 규칙, DNS 오버라이드, 인터페이스 설정은 포함되지 않습니다. PC에서 rules 규칙 몇 개를 수동으로 추가했다면, 휴대폰에서 구독을 새로고침해도 이 수동 규칙은 자동으로 나타나지 않습니다—클라이언트가 "오버라이드(Override)" 기능을 지원해서 사용자 정의 부분을 별도 오버라이드 파일로 저장하고 구독과 함께 사용하는 경우는 예외입니다.
- 적합한 사용자: 노드를 구독 서비스에서 받고 규칙을 거의 수동으로 손대지 않는 사용자.
- 장점: 한 번 설정해두면 이후 노드 업데이트는 전부 자동이며, 여러 기기 간 노드 정보가 자연스럽게 일치합니다.
- 한계: 사용자 정의 규칙, 그룹 이름, UI 설정은 함께 동기화되지 않습니다.
구독 링크는 보통 요청 빈도 제한이 걸려 있어서, 너무 자주 수동으로 새로고침하면 서비스 제공업체 측에서 속도를 제한하거나 비정상 요청으로 판단할 수 있습니다. 여러 기기에서 각각 자동 업데이트 주기를 설정할 때는 간격을 엇갈리게 두는 것이 좋으며, 모두 "실행할 때마다 업데이트"로 설정할 필요는 없습니다.
방법 2: WebDAV 클라우드 백업
일부 주요 클라이언트(예: Clash Verge Rev)는 설정 파일의 WebDAV 백업 및 복원 기능을 내장하고 있습니다. 아이디어는 완전한 설정 파일(노드, 규칙, 그룹, 일부 로컬 설정 포함)을 자신이 소유한 WebDAV 서비스(직접 구축한 Nextcloud일 수도, WebDAV 프로토콜을 지원하는 클라우드 스토리지 서비스일 수도 있음)에 업로드하고, 다른 기기는 같은 WebDAV 디렉터리에서 가져와 복원하는 방식입니다. 이 방식의 장점은 "전체 동기화"입니다—노드만 동기화하는 구독 링크와 달리, WebDAV 백업은 직접 조정한 규칙과 그룹 순서도 함께 옮길 수 있습니다.
# WebDAV 설정 항목 예시(클라이언트 설정 화면에서 입력, 설정 파일을 직접 작성하는 것이 아님)
WebDAV 주소: https://dav.example.com/remote.php/dav/files/username/
사용자 이름: your-account
비밀번호: 앱 전용 비밀번호(로그인용 메인 비밀번호를 사용하지 마세요)
WebDAV 동기화를 사용할 때 간과하기 쉬운 부분이 있습니다: 이는 "백업/복원" 모델이며 문서 협업 소프트웨어처럼 실시간 양방향 병합이 아닙니다. 즉 PC에서 규칙을 바꾸고 백업을 업로드한 뒤, 휴대폰에서 최신 백업을 먼저 받지 않고 다른 부분을 수정하면, 두 쪽의 수정 내용은 병합되지 않고 서로 덮어씁니다. 올바른 작업 습관은: 설정을 수정하기 전에 현재 기기에서 먼저 "최신 백업 가져오기"를 하고, 수정을 마친 뒤 "백업 업로드"를 하는 것입니다. 이 순서를 지키면 대부분의 충돌을 피할 수 있습니다.
- 적합한 사용자: 규칙을 자주 손으로 조정하며 여러 기기의 설정을 완전히 일치시키고 싶은(노드뿐 아니라) 사용자.
- 장점: 사용자 정의 규칙과 그룹 구조를 포함한 전체 동기화.
- 한계: 자체 WebDAV 서비스가 필요하고, 자동 병합을 지원하지 않아 순서를 잘못 지키면 서로 덮어씁니다.
방법 3: 수동 내보내기/가져오기
가장 원초적이지만 가장 제어하기 쉬운 방식입니다: 한 기기에서 설정 파일(보통 .yaml 또는 .yml)을 내보낸 뒤, 임의의 방법(이메일, 메신저, 로컬 네트워크 전송, USB 드라이브)으로 다른 기기에 전달하고, 대상 클라이언트에서 수동으로 가져옵니다. 이 방식은 클라우드 서비스나 구독 메커니즘에 전혀 의존하지 않아, 임시로 문제를 진단하거나, 직접 조정한 분기 규칙을 다른 사람에게 공유하거나, 기기 수가 적고 아주 드물게만 업데이트하는 상황에 적합합니다.
# 대부분 클라이언트의 설정 파일 로컬 저장 위치는 대략 다음과 같습니다
Windows: %USERPROFILE%\.config\clash\profiles\
macOS: ~/Library/Application Support/clash/profiles/
Linux: ~/.config/clash/profiles/
수동 내보내기/가져오기의 가장 큰 단점은 자동 업데이트가 되지 않는다는 점입니다—오늘 옮긴 파일은 노드 정보가 내보낸 그 순간에 영원히 멈춰 있어서, 서비스 제공업체 쪽에서 노드 주소를 바꾸더라도 수동으로 가져온 설정은 따라서 바뀌지 않습니다. 따라서 이 방식은 "일회성 이전"이나 "긴급 백업" 용도로 쓰는 것이 적합하며, 장기적인 멀티 디바이스 동기화의 주력 수단으로는 권장하지 않습니다. PC에서 조정한 규칙 조각을 휴대폰에서 참고만 하도록 공유하고 싶은 정도라면, 오히려 이 방식이 가장 직접적이며 별도의 클라우드 서비스 계정 설정이 필요 없습니다.
- 적합한 사용자: 기기를 가끔 바꾸며 특정 설정 하나를 정확히 제어해야 하는 사용자.
- 장점: 어떤 제3자 서비스에도 의존하지 않아 과정을 완전히 통제할 수 있습니다.
- 한계: 자동 업데이트 기능이 없어 장기간 사용하면 동기화를 잊어 노드 정보가 오래될 수 있습니다.
세 가지 방법, 어떻게 골라야 할까
실제 상황에서 대부분의 사용자는 셋 중 하나만 고르는 것이 아니라, 용도에 맞춰 조합해서 사용합니다. 아래 비교표로 주력 방식을 빠르게 판단해 보세요:
| 항목 | 구독 링크 | WebDAV 백업 | 수동 내보내기/가져오기 |
|---|---|---|---|
| 노드 자동 업데이트 | 지원 | 미지원(재업로드 필요) | 미지원 |
| 사용자 정의 규칙 동기화 | 미지원(오버라이드 필요) | 지원 | 지원(그 순간만) |
| 설정 비용 | 낮음, 링크 한 번 입력 | 중간, WebDAV 계정 준비 필요 | 낮음, 다만 매번 수동 작업 필요 |
| 충돌 위험 | 거의 없음 | 있음(먼저 받고 나중에 올리는 순서 필요) | 없음(단방향 이전) |
| 적합한 빈도 | 일상적인 장기 사용 | 규칙을 자주 바꾸는 헤비 유저 | 가끔 기기를 바꾸거나 임시 공유 |
비교적 안정적인 조합은 이렇습니다: 주력 노드는 구독 링크로 자동 업데이트하고, 사용자 정의 규칙 조각은 오버라이드 파일로 따로 작성해 구독과 함께 사용하는 것; 클라이언트가 WebDAV를 지원한다면, 이를 유일한 동기화 수단이 아니라 "규칙과 그룹 구조"의 정기 백업 수단으로 활용하는 것입니다. 이렇게 하면 언젠가 WebDAV 서비스가 사용할 수 없게 되더라도 구독 링크가 여전히 노드 사용을 보장해 줘서 양쪽 모두 끊기는 상황을 피할 수 있습니다.
자주 겪는 문제 해결
구독을 업데이트했는데 휴대폰 쪽 노드가 여전히 예전 것인 경우, 어떻게 확인해야 하나요?
먼저 클라이언트의 자동 업데이트 주기 설정을 확인하세요(기본값이 실시간이 아니라 몇 시간에 한 번인 경우가 흔합니다). 그런 다음 "지금 구독 업데이트"를 수동으로 한 번 눌러보세요. 수동 업데이트도 효과가 없다면 구독 링크가 서비스 제공업체 측에서 속도 제한을 당했는지, 또는 링크 자체가 만료되어 다시 발급받아야 하는지 확인하세요.
WebDAV로 복원한 뒤 규칙이 줄어들었어요, 동기화에 문제가 생긴 걸까요?
대부분 작업 순서 문제입니다: 다른 기기에서 수정한 뒤 이 기기에서 먼저 최신 백업을 받지 않고 바로 업로드해서, 이전 버전이 새 수정 내용을 덮어쓴 경우입니다. 설정을 수정하기 전에 매번 먼저 최신 백업을 받은 뒤 작업하는 것을 권장합니다.
수동으로 내보낸 설정 파일을 친구에게 바로 보내서 써도 되나요?
규칙 템플릿 부분은 전달해도 되지만, 설정 파일에는 보통 자신의 노드 정보와 구독 링크가 함께 들어 있으므로, 공유하기 전에 개인 노드 항목을 비우거나 교체해서 계정 정보 유출을 막는 것을 권장합니다.