PC와 모바일에서 Clash 설정 공유하기: 구독 호스팅·WebDAV·비공개 Git 저장소 동기화

Clash 여러 기기 설정 동기화: 먼저 공유할 항목 구분하기

PC와 모바일에서 같은 설정을 사용하려면 ‘같은 노드 공급원’, ‘같은 분기 규칙’, ‘같은 클라이언트 상태’를 구분해야 합니다. 같은 구독 주소를 사용하면 두 기기에서 동일한 노드를 가져올 수 있지만, 현재 선택한 노드나 시스템 프록시 스위치, TUN 권한까지 자동으로 동기화되지는 않습니다. WebDAV와 Git은 파일 전송을 담당할 뿐, 클라이언트에서 설정을 가져오거나 활성화해 주지는 않습니다.

Clash GUI 클라이언트는 설정 관리와 시스템 연동을 담당하고, 코어는 설정을 읽어 규칙을 적용하고 연결을 수립합니다. Clash Meta는 이후 mihomo라는 이름으로 유지 관리되고 있습니다. mihomo를 사용하는 클라이언트끼리도 코어 버전, 설정 덮어쓰기 방식, 인터페이스 기능이 다를 수 있습니다. 따라서 앱 데이터 디렉터리 전체를 복사하기보다 서로 지원하는 설정 항목을 동기화하는 것이 좋습니다.

공유해도 되는 항목과 기기별로 유지할 항목

공유에 적합: 노드 구독 공급원, 정책 그룹 이름, 규칙 순서, 규칙 세트 주소, 두 클라이언트가 모두 지원하는 DNS 정책.
기기별로 유지: 시스템 프록시 스위치, TUN 스위치와 권한, 시작 시 자동 실행, 네트워크 인터페이스 이름, 로그 위치, 클라이언트 창 설정.
별도 확인: mixed-port, external-controller, secret, LAN 수신 설정. 데스크톱 관리 인터페이스 설정이 그대로 모바일에 적용되지 않도록 주의하세요.

세 가지 동기화 방식의 용도

먼저 동기화할 대상에 맞춰 방식을 선택하세요. 노드만 업데이트하려면 구독 링크가 가장 간단합니다. 복구 가능한 설정 사본이 필요하다면 WebDAV가 적합하고, 규칙을 장기간 관리하며 수정 이력을 추적하려면 비공개 Git 저장소가 편리합니다. 여러 방식을 함께 써도 되지만, 어느 위치를 기준 원본으로 삼을지 명확히 정해야 합니다.

방식	동기화 대상	기기 측 요구 사항	업데이트 방식
구독 링크 호스팅	노드 또는 전체 설정	원격 구독 및 해당 형식 지원	수동 업데이트 또는 클라이언트의 주기적 가져오기
WebDAV 백업	내보낸 YAML 파일	WebDAV 내장 기능 또는 파일 앱으로 다운로드한 뒤 가져오기	업로드, 다운로드, 다시 가져오기 또는 새로고침
비공개 Git 저장소	규칙 원본 파일 및 수정 이력	Git 도구 또는 권한이 관리되는 배포 절차	커밋, 가져오기, 검증 후 적용

‘원격 구독 지원’은 ‘WebDAV 로그인 지원’이나 ‘비공개 저장소 직접 읽기’를 뜻하지 않습니다. 클라이언트에서 인증 정보를 전달할 수 없다면, 인증이 필요한 파일 주소를 일반 구독 주소로 사용할 수 없습니다. 배포 전에는 클라이언트 이름만 보지 말고 현재 버전의 구독 관리, 파일 가져오기, 인증 기능을 확인하세요.

구독 링크 호스팅: PC와 모바일에서 같은 공급원 가져오기

가져오기 및 업데이트 절차

서비스 제공업체에서 대상 코어에 맞는 구독 주소를 받은 뒤, 응답이 전체 Clash 설정인지 노드 목록인지 다른 형식인지 확인하세요. 노드만 포함된 콘텐츠라면 클라이언트나 설정 템플릿으로 실행 가능한 설정을 구성해야 합니다.
PC와 모바일의 구독 관리 화면에서 각각 원격 설정을 추가하고 같은 주소를 붙여 넣습니다. 메뉴 이름은 ‘구독’, ‘설정’ 또는 ‘Profiles’ 등으로 표시될 수 있으며, 실제 명칭은 사용 중인 버전에 따라 다릅니다.
다운로드가 끝나면 각 기기에서 해당 설정을 선택하고 활성화합니다. 정책 그룹과 규칙 수, 노드가 모두 있는지 확인한 다음 기기별로 필요한 시스템 연동 방식을 켭니다.
주기적 업데이트 기능이 있다면 우선 24시간 간격으로 설정해 보세요. 노드가 일시적으로 작동하지 않거나 제공업체가 변경 사항을 알린 경우에는 수동으로 업데이트하고 업데이트 시간이 바뀌었는지 확인합니다.

24시간은 관리하기 편한 초기 권장값일 뿐, 모든 클라이언트의 기본값은 아닙니다. 모바일 OS는 백그라운드 작업을 제한할 수 있으므로 자동 업데이트를 설정했더라도 중요한 사용 전에 앱을 열어 최근 업데이트 시간을 확인하세요. 두 기기의 새로고침 시점이 다르면 잠시 노드 목록이 다르게 표시될 수 있습니다.

전체 구독과 proxy-providers의 차이

GUI 클라이언트에서 원격 설정을 업데이트하면 보통 설정 파일을 다시 가져옵니다. 반면 mihomo의 proxy-providers는 설정 내부에서 노드 공급자를 정의합니다. HTTP 유형 공급자에서 interval: 3600은 업데이트 간격이 3600초라는 뜻이며, 클라이언트 전체 구독을 매시간 다시 불러오거나 앱 설정을 동기화한다는 의미는 아닙니다. 어떤 수준에서 업데이트할지는 설정 구성 방식에 따라 결정하세요.

원격 구독에 규칙이 포함되어 있다면 다운로드한 YAML을 직접 수정해도 다음 업데이트 때 변경 내용이 덮어써질 수 있습니다. 사용자 지정 분기 규칙이 필요하면 클라이언트가 명시적으로 지원하는 로컬 덮어쓰기, 병합 또는 스크립트 기능을 사용하고 어떤 필드에 적용되는지 확인하세요. PC와 모바일이 같은 덮어쓰기 방식을 지원하지 않는다면, 관리되는 서버에서 두 기기 모두 읽을 수 있는 최종 설정을 생성할 수 있습니다.

WebDAV 백업: 설정 파일 전송 및 복구용 사본 보관

WebDAV는 원격 파일을 읽고 쓸 수 있어 정리된 설정을 개인 저장소에 보관한 뒤 다른 기기에서 복구하기 좋습니다. 다만 파일을 전송하는 기능이므로, 클라이언트에 자동 복구 기능이 명시적으로 제공되지 않는 한 업로드 후에도 파일을 다운로드해 가져오고 활성화해야 합니다.

양방향 덮어쓰기보다 단방향 배포가 문제를 찾기 쉽습니다

저장소 서비스에 clash-config/ 같은 전용 디렉터리를 만듭니다. HTTPS와 전용 앱 비밀번호를 사용하고, 배포 기기에는 쓰기 권한을 부여하되 읽기 기기에는 가능한 한 읽기 권한만 부여하세요.
PC에서 공유할 YAML을 내보낸 뒤 노드 비밀번호, 구독 토큰, 제어 인터페이스 키와 같은 민감한 정보가 포함되어 있는지 확인합니다. 백업 목적에 따라 필요한 항목만 남기세요.
먼저 shared-2026-08-14.yaml처럼 날짜가 포함된 파일을 업로드하고, 이전에 사용할 수 있었던 사본도 보관합니다. 파일이 온전한지 확인한 다음 저장소 서비스가 지원하는 방법으로 고정 파일명을 갱신하세요.
모바일에서 WebDAV 복구를 지원하면 해당 메뉴를 사용하세요. 지원하지 않는 경우 WebDAV를 지원하는 파일 앱으로 다운로드한 뒤 프록시 클라이언트의 로컬 파일 가져오기 메뉴에서 불러오면 됩니다.
활성화한 뒤 규칙과 연결 로그를 확인하세요. 복구에 실패하면 백업을 즉시 삭제하지 말고 이전 설정을 다시 가져오세요.

두 기기 모두 shared.yaml에 파일을 쓴다면 나중에 업로드한 파일이 먼저 수정된 내용을 덮어쓸 수 있습니다. 조건부 쓰기, 잠금, 충돌 처리는 서버와 클라이언트 구현에 따라 달라지므로 WebDAV가 YAML을 자동으로 병합한다고 가정하면 안 됩니다. PC에서 배포하고 모바일에서는 읽기만 하는 방식을 권장합니다. 모바일의 임시 노드 선택은 기기에 그대로 유지하세요.

설정 백업과 앱 데이터 백업은 구분해야 합니다

클라이언트 전체 백업에는 데이터베이스, 내부 설정 식별자, 시스템 경로가 포함될 수 있어 일반적으로 같은 클라이언트에서 복구할 때 적합합니다. Windows, macOS, Android 간에 옮길 때는 읽을 수 있는 설정 파일을 우선 내보내세요. iOS에서는 사용하는 프록시 클라이언트가 실제로 지원하는 형식과 가져오기 경로를 확인해야 합니다. 임의의 mihomo 설정을 바로 읽을 수 있다고 가정하지 마세요.

인증 정보가 포함된 사본을 원격 저장소에 보관해야 한다면 먼저 암호화해 압축한 뒤 WebDAV에 업로드하세요. 암호화 파일은 복구용으로만 사용할 수 있습니다. 신뢰할 수 있는 기기에서 복호화한 다음 클라이언트로 가져오세요. 일반 YAML 구독처럼 직접 가져올 수는 없습니다.

비공개 Git 저장소: 규칙 버전 관리와 기기별 차이 반영

Git을 사용하면 규칙을 수정한 이유와 되돌릴 수 있는 버전, 데스크톱과 모바일의 차이를 기록하기 좋습니다. 저장소에는 인증 정보가 없는 규칙 원본 파일을 보관하고, 구독 주소와 노드 비밀번호는 로컬이나 접근이 통제된 배포 환경에 저장하세요. 저장소를 비공개로 설정해도 커밋 이력에 남은 비밀 정보가 자동으로 삭제되지는 않습니다.

노드 인증 정보가 없는 규칙 파일부터 시작하세요

아래는 공유 설정 구조를 설명하기 위한 최소 구성입니다. example.com은 문서용 예시 도메인입니다. 프록시 노드는 없으며 모든 연결은 최종적으로 직접 연결되므로 서비스 제공업체의 구독을 대체할 수 없습니다. 실제 노드를 연결한 뒤에는 클라이언트의 병합 기능이나 설정 생성 절차에서 해당 정책 그룹과 노드 정의가 유지되도록 해야 합니다.

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

proxies: []

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - MATCH,DIRECT

7890은 예시 로컬 혼합 프록시 포트로, HTTP와 SOCKS 프록시 연결을 모두 받을 수 있습니다. 포트가 이미 사용 중이라면 PC에서 사용 가능한 포트로 변경하고 시스템 프록시 설정도 일치시켜야 합니다. 모바일 클라이언트는 수신 포트와 VPN 연동 방식을 자체 관리할 수 있으므로 이 항목이 로컬 설정을 덮어쓰는지는 클라이언트 구현에 따라 다릅니다.

로컬 버전 기록 만들기

Git을 설치하고 커밋 작성자 정보를 설정한 뒤 policy.yaml이 있는 디렉터리에서 다음 명령을 실행합니다. 이 단계에서는 로컬 이력만 생성됩니다. 비공개 원격 저장소에 동기화하려면 저장소 서비스의 안내에 따라 SSH 또는 액세스 토큰을 설정하세요.

git init
git add policy.yaml
git commit -m "공유 분기 설정 기록"

git diff -- policy.yaml
git log --oneline -- policy.yaml

구독 인증 정보는 별도의 로컬 비밀 파일에 저장하고 .gitignore로 제외하세요. 무시 규칙을 추가해도 이미 추적 중인 파일은 저장소에서 제거되지 않습니다.
배포 전에 git diff를 검토해 의도한 규칙만 변경되었는지 확인하세요. 데스크톱과 모바일에 서로 다른 TUN 설정을 공유 규칙 파일에 섞지 마세요.
동기화해서 읽는 기기에는 읽기 전용 배포 자격 증명을 우선 사용하고, 모든 휴대폰에 저장소 쓰기 권한을 부여하지 마세요.
이미 공유한 변경 사항을 되돌리려면 git revert로 역방향 커밋을 생성한 다음 설정을 다시 생성해 가져오세요. 변경 이력은 그대로 보존됩니다.

프록시 클라이언트는 보통 git pull을 실행하지 않으며, 비공개 저장소의 웹페이지 주소도 YAML 원문 주소가 아닙니다. 모바일에서는 파일을 직접 다운로드해 가져오거나, 관리되는 배포 절차로 규칙과 구독을 결합한 인증된 HTTPS 설정 주소를 제공할 수 있습니다. 이 경우에도 클라이언트가 해당 인증 방식을 지원하는지 확인하고 빌드 로그에서 토큰을 숨겨야 합니다.

업데이트 검증: 설정이 같아도 기기 연동 상태는 다를 수 있습니다

먼저 한 기기에서 검증한 뒤 다른 기기에 배포하는 것이 좋습니다. 한 번에 한 단계씩 확인하세요. 파일 가져오기를 확인하고, 설정이 로드되는지 살펴본 다음, 시스템 연동과 네트워크 동작을 점검합니다. 이렇게 하면 동기화 실패, 코어 호환성 문제, 로컬 권한 문제를 구분하기 쉽습니다.

원본 파일 확인: 다운로드 결과가 로그인 페이지가 아니라 YAML인지 확인하세요. HTTP 401은 인증 실패, 403은 접근 거부, 404는 리소스가 없음을 나타내는 경우가 많습니다. 저장소나 호스팅 서비스에서 권한과 주소를 확인하세요.
파싱 확인: 클라이언트 오류 로그를 살펴보고 들여쓰기 오류, 중복 필드, 지원하지 않는 프로토콜 매개변수가 없는지 확인하세요. 정책 그룹에서 참조하는 이름이 실제로 존재해야 하며, 규칙은 위에서부터 먼저 일치하는 항목이 적용됩니다.
활성화 상태 확인: 설정을 다운로드했더라도 현재 선택된 파일을 다시 불러왔는지 확인해야 합니다. 노드 선택 상태가 복원되는지는 클라이언트 캐시와 정책 그룹 이름이 유지되는지에 따라 달라집니다.
시스템 연동 확인: PC에서 시스템 프록시를 켜면 시스템 프록시를 지원하는 앱만 해당 설정을 따릅니다. Android 등 모바일 플랫폼은 보통 VPN 인터페이스로 연결하며 필요한 권한은 기기에서 직접 승인해야 합니다.
실제 연결 확인: 같은 테스트 대상에 연결해 양쪽의 연결 로그에서 적용된 규칙과 정책을 확인하세요. 페이지가 열린다는 사실만으로는 예상한 프록시를 거쳐 연결되었다고 단정할 수 없습니다.

노드와 규칙이 완전히 같더라도 PC와 모바일은 Wi-Fi, 이동통신망, DNS 환경, IPv6 경로가 달라 결과가 다를 수 있습니다. ‘PC에서는 정상인데 모바일에서는 실패’하는 경우 같은 Wi-Fi에서 다시 테스트한 뒤 모바일 권한, 노드 프로토콜 지원 여부, 로그 오류를 확인하세요. 공유 설정을 반복해서 덮어쓰는 것은 피해야 합니다.

여러 기기 동기화 권장 조합과 관리 주기

기기 두 대: 같은 구독, 기기별 연동 설정

PC와 모바일에서 각각 같은 구독을 가져오고 업데이트 상태를 정기적으로 확인하세요. 시스템 프록시, TUN, 시작 방식은 기기별로 유지합니다. 분기 규칙을 자주 수정하지 않는다면 업데이트나 중요한 변경 전에 날짜가 포함된 YAML 백업을 하나 저장하는 것으로 충분합니다. 저장소나 배포 절차를 추가할 필요는 없습니다.

장기적인 규칙 관리: Git으로 기록, 구독 업데이트, WebDAV에 보관

인증 정보가 없는 규칙은 비공개 Git 저장소에 보관하고 노드는 구독으로 관리하세요. 검증을 마친 설정은 접근이 통제된 방식으로 배포하고, 복구 가능한 사본은 WebDAV에 저장합니다. 규칙을 변경한 뒤에는 바로 검증하고 배포하세요. 구독은 클라이언트 주기에 따라 업데이트하고, 새 설정이 정상 작동하는지 확인한 뒤 백업을 생성합니다. 세 가지 업데이트를 한 번에 처리할 필요는 없습니다.

업데이트할 때마다: 설정 출처, 업데이트 시간, 현재 활성화 상태를 기록하고 직접 연결 규칙 하나와 프록시 연결이 예상되는 규칙 하나를 확인하세요.
클라이언트 또는 코어 변경 시: 테스트용 사본을 먼저 가져와 프로토콜, 규칙 세트, DNS, TUN 항목이 지원되는지 확인한 뒤 평소 사용하는 설정을 교체하세요.
기기를 분실하거나 사용을 중단할 때: 해당 기기의 WebDAV 및 저장소 접근 자격 증명을 폐기하세요. 구독 링크가 노출되었을 가능성이 있다면 제공업체의 절차에 따라 재설정하세요.

기본 사용 방법은 구독 가져오기 안내를, 규칙 순서와 코어별 차이는 규칙 기술 참고와 코어 안내를 확인하세요. 여러 기기를 동기화할 때는 노드와 규칙의 출처를 명확히 하고, 포트와 권한, 시스템 연동은 기기별로 관리하는 것이 핵심입니다.