여러 기기에서 Clash 설정 동기화하는 3가지 방법: 구독 링크·WebDAV 백업·수동 내보내기 비교

왜 여러 기기의 설정은 쉽게 "따로따로" 되는가

한 사람이 Windows PC, Android 휴대폰, iPad, 심지어 macOS 노트북까지 동시에 사용해 네트워크에 접속하는 일은 이제 흔합니다. 각 기기에 설치된 Clash 클라이언트는 서로 독립적으로 동작하며, 설정 파일·노드 목록·규칙 세트가 각각 로컬에 저장되어 있어 원래부터 서로를 인식하지 못합니다. PC에서만 분기 규칙을 하나 바꿔도 휴대폰에는 자동으로 반영되지 않고, 휴대폰에서 구독을 새로 추가해도 PC에서는 보이지 않습니다. 시간이 지나면 기기마다 프록시 동작이 조금씩 "어긋나기" 시작해, 같은 사이트가 PC에서는 열리는데 휴대폰에서는 안 열리거나, 어떤 기기가 계속 만료된 오래된 노드에 접속해 있는 등의 현상이 나타납니다.

이런 불일치의 원인은 소프트웨어 결함이 아니라 설정 데이터 자체의 저장 방식에 있습니다. Clash 계열 클라이언트(원본 Clash 코어 기반이든 Clash Meta / mihomo 코어 기반 GUI든)는 설정을 로컬 파일 형태로 저장하며, 보통 YAML 형식의 config.yaml 파일 안에 프록시 노드, 규칙 세트, 그룹 정책 등의 정보를 담습니다. 파일이 로컬 디스크에 놓여 있는 이상 원래부터 기기 간 이동 능력이 없으므로, 별도의 방법으로 그것을 다른 기기로 "옮기거나" 여러 기기가 같은 데이터 소스를 읽도록 해야 합니다.

아래에서는 "설정 갱신 빈도"와 "작업 복잡도" 두 기준으로 흔히 쓰이는 3가지 방법을 정리합니다: 구독 링크 통합 관리, 클라이언트 내장 WebDAV 백업 동기화, 설정 파일 수동 내보내기. 세 가지는 서로 배타적이지 않으며, 많은 사람이 함께 사용합니다 — 구독으로 일상 노드를 관리하고, WebDAV로 전체 백업을 보조하며, 수동 내보내기로 오프라인 사본을 하나 남기는 식입니다.

방법 1: 구독 링크 통합 관리

구독 링크는 현재 가장 널리 쓰이는 동기화 방식입니다. 원리는 간단합니다: 서비스 제공자가 원격 주소를 유지하며, 그 안에 정해진 형식으로 노드 목록(때로는 규칙까지)을 기술해 두고, Clash 클라이언트가 주기적으로 이 주소를 요청해 반환된 내용을 로컬 설정으로 해석합니다. 여러 기기에 같은 구독 링크를 입력해 두면 이론상 동일한 노드 집합을 받을 수 있습니다.

1. 각 기기의 클라이언트에 같은 구독 링크 추가

   클라이언트마다 화면 문구는 조금씩 다르지만 절차는 대체로 같습니다: "구독 관리", "프로필", "Profiles" 같은 항목을 찾아 링크를 붙여넣고 다운로드 또는 가져오기를 누릅니다.

2. 자동 갱신 주기 설정

   대부분의 클라이언트는 구독을 주기적으로 새로 고치는 기능을 지원하며, 흔한 기본값은 24시간마다 한 번입니다. 더 짧은 주기로 바꾸거나, 클라이언트를 열 때마다 직접 "업데이트"를 눌러도 됩니다.

3. 노드 수와 그룹이 일치하는지 확인

   갱신이 끝나면 두 기기에서 각각 노드 목록을 열어 개수와 그룹 이름이 일치하는지 확인하는 것이 좋습니다. 해석 차이로 어떤 기기에서 일부 노드가 빠지는 일을 막을 수 있습니다.

구독 링크의 장점은 "가볍다"는 점입니다: 별도 소프트웨어가 필요 없고, 로컬 저장 공간을 차지하지 않으며, 갱신도 수동적이고 자동적이어서 사람이 손댈 일이 거의 없습니다. 한계도 뚜렷한데, 구독 링크는 보통 노드와 일부 규칙만 다루며, 사용자 정의 분기 규칙, DNS 설정, TUN 모드의 세부 파라미터 같은 "개인화 설정"은 대부분 구독에 포함되지 않고 로컬에서 따로 관리해야 합니다. 즉, 구독이 해결하는 것은 "노드 일치"이지 "전체 설정 일치"는 아닙니다.

방법 2: 클라이언트 내장 WebDAV 백업 동기화

일부 주요 클라이언트(예: mihomo 코어 기반 데스크톱 클라이언트인 Clash Verge Rev 등)는 WebDAV 백업 기능을 내장하고 있어, 완전한 설정 파일, 구독 목록, 화면 환경설정을 통째로 압축해 WebDAV 서버에 업로드하고 다른 기기에서 같은 주소에서 내려받아 복원할 수 있습니다. 구독 링크보다 WebDAV 백업의 단위는 더 크며, 사실상 "전체 스냅샷"에 해당해 노드 목록보다 더 완전한 설정 상태를 복원할 수 있습니다.

1. WebDAV 서비스 주소 준비

   직접 구축한 WebDAV 서비스일 수도 있고, WebDAV 프로토콜을 지원하는 클라우드 스토리지 서비스일 수도 있습니다. 주소, 계정, 비밀번호를 기록해 둡니다.

2. 클라이언트의 백업 설정에 WebDAV 정보 입력

   "백업", "동기화", "WebDAV" 관련 항목을 찾아 주소와 인증 정보를 입력하고, 먼저 한 번 "백업 업로드"를 실행해 오류가 없는지 확인합니다.

3. 다른 기기에서 "다운로드 및 복원" 실행

   같은 계정 정보를 다른 기기의 클라이언트에 입력하고 "WebDAV에서 복원"을 선택합니다. 다운로드가 끝나면 클라이언트를 재시작해 설정을 적용합니다.

WebDAV 방식의 장점은 "전체 이전"이 편리하다는 점으로, 특히 새 기기로 바꾸거나 시스템을 재설치한 뒤 기존 환경을 빠르게 복원할 때 유용하며 항목별로 다시 설정할 필요가 없습니다. 다만 자연스러운 한계가 있습니다: 보통 이 기능을 지원하는 데스크톱 클라이언트 사이에서만 작동하며, 모바일(Android, iOS) 클라이언트는 같은 WebDAV 백업 형식을 지원하지 않을 수 있으므로, 플랫폼 간 복원 시 대상 클라이언트가 백업 파일 구조와 호환되는지 먼저 확인해야 합니다. 또한 백업은 수동 또는 예약으로 실행되는 스냅샷이지 실시간 동기화가 아니므로, 변경 후 다시 백업하는 것을 잊으면 복원되는 것은 여전히 옛 버전입니다.

방법 3: 설정 파일 수동 내보내기 및 가져오기

가장 원초적이지만 가장 직접적인 방법은 config.yaml 또는 클라이언트가 내보낸 설정 패키지를 다른 기기로 그대로 복사하는 것입니다. 대부분의 클라이언트는 "설정 내보내기", "설정 폴더 열기" 같은 항목을 제공하며, 로컬에 저장된 YAML 파일을 찾아 USB, 로컬 네트워크 전송, 클라우드 동기화 폴더 등의 방법으로 대상 기기로 옮긴 다음, 해당 클라이언트의 "설정 가져오기" 기능으로 불러올 수 있습니다.

1. 설정 파일 위치 찾기

   클라이언트 설정에서 "설정 폴더 열기" 또는 비슷한 항목을 찾으면, 현재 적용 중인 YAML 파일과 구독 캐시 파일을 볼 수 있습니다.

2. 대상 기기로 파일 복사

   로컬 네트워크 공유, 클라우드 스토리지, 데이터 케이블 등 원하는 전송 방식으로 대상 기기가 접근할 수 있는 경로에 파일을 둡니다.

3. 대상 클라이언트에서 가져오기

   "파일에서 설정 가져오기" 기능으로 해당 파일을 선택하고, 클라이언트의 해석이 끝나면 노드와 규칙이 정상적으로 로드되었는지 확인합니다.

이 방식은 어떤 네트워크 서비스에도 의존하지 않아 오프라인에서도 완료할 수 있으며, 설정에 수동 조정이 많고 서드파티 WebDAV 서비스를 쓰고 싶지 않은 경우에 적합합니다. 일회성 "설정 이전"이나 오프라인 보관용 사본을 남기는 데도 자주 쓰입니다. 단점도 명확합니다: 전적으로 수동 작업이라 변경 사항이 다른 기기로 자동 전파되지 않으므로 기기가 많아지면 갱신을 빠뜨리기 쉽고, 클라이언트마다 YAML 필드 지원 정도가 조금씩 달라서 예를 들어 특정 데스크톱 전용 그룹 정책 필드는 모바일 클라이언트에서 제대로 해석되지 않을 수 있어, 가져온 뒤 항목별로 확인해야 합니다.

3가지 방법 선택 가이드: 상황별 비교

실제 사용에서는 셋 중 하나만 고르기보다 함께 쓰는 경우가 많습니다. 비교적 안전한 조합은: 평소에는 구독 링크로 노드를 갱신하고, 주기적으로 WebDAV로 전체 백업을 만들어 설정 손실을 방지하며, 큰 변경을 하기 전에는 수동으로 YAML을 내보내 보관해 두는 것입니다. 이렇게 3중 안전장치를 두면 어느 한 층에 문제가 생기더라도 다른 대안이 남아 있습니다.

동기화 후 흔히 겪는 문제 점검 방법

방법을 잘 골라도 동기화 후 "설정이 적용되지 않는" 상황을 겪을 수 있습니다. 다음은 자주 확인해야 할 몇 가지 방향입니다:

• 클라이언트가 설정을 다시 불러왔는지 확인. 일부 클라이언트는 설정을 가져오거나 갱신한 뒤 수동으로 "적용"을 누르거나 코어를 재시작해야 반영되며, 모든 필드가 자동으로 즉시 반영되지는 않습니다.
• 구독 해석이 중간에 끊겼는지 확인. 구독 링크가 반환하는 내용이 너무 크거나 클라이언트가 지원하지 않는 필드를 포함하면 해석이 중간에 실패해 노드 목록이 "일부 빠진" 것처럼 보일 수 있습니다. 이런 경우 클라이언트 로그나 업데이트 로그를 확인해 오류 원인을 파악하는 것이 좋습니다.
• TUN 모드 등 시스템 수준 설정이 함께 이전되었는지 확인. TUN 모드는 가상 네트워크 카드와 시스템 라우팅 테이블과 관련되며, 일부 클라이언트는 이런 설정을 YAML 설정 파일이 아니라 앱 레이어 환경설정에 두므로, 설정 파일만 동기화해서는 TUN 스위치 상태가 함께 옮겨지지 않아 새 기기에서 따로 확인해야 합니다.
• 모바일과 데스크톱의 규칙 문법 차이. 규칙 세트에서 로컬 파일 경로(원격 규칙 세트 주소가 아닌)를 참조하고 있다면, 다른 기기로 옮기면 경로가 유효하지 않을 가능성이 큽니다. 가능한 한 로컬 파일 참조 대신 원격 규칙 세트를 사용해 이전 시 경로 의존성을 줄이는 것이 좋습니다.

정리

여러 기기의 설정이 일치하지 않는 문제는 본질적으로 "로컬 파일"과 "기기 간 이동" 사이의 근본적인 모순입니다. 구독 링크는 노드 수준의 자동 동기화를 해결하고, WebDAV 백업은 전체 스냅샷 형태의 이전 능력을 제공하며, 수동 내보내기는 가장 기본적이지만 가장 통제 가능한 오프라인 방식입니다. 어느 하나도 만능은 아니며, 자신의 사용 빈도, 기기 수, 사용자 정의 규칙에 대한 의존도에 맞춰 조합해야 여러 기기에서 프록시 동작을 실제로 일관되게 유지할 수 있습니다.