플랫폼 워크플로 예상 읽기 시간 13분

Clash 멀티 디바이스 설정 동기화: 구독, 오버라이드 및 비공개 저장소 활용법

구독 링크, 오버라이드 파일, 비공개 저장소를 비교하고 인증 정보 분리, 충돌 해결, 업데이트 순서를 설명합니다.

Windows, macOS, Linux 및 모바일 기기에서 Clash 또는 mihomo를 사용할 때 동기화해야 할 것은 보통 YAML 파일 하나가 아닙니다. 프록시 노드는 구독에서 가져오고, 규칙은 원격 규칙 Provider에서 제공되며, 프록시 그룹은 개인 설정에 해당합니다. 반면 포트, TUN, LAN 접근, DNS 리스닝 주소는 기기 환경에 따라 달라집니다. 클라이언트의 데이터 디렉터리 전체를 그대로 복사하면 캐시, 실행 상태, 데이터베이스, 플랫폼 전용 필드까지 다른 기기로 함께 옮겨져 포트 충돌, 설정 로드 실패, 로컬 변경 사항 덮어쓰기 같은 문제가 발생하기 쉽습니다.

더 안정적인 방법은 먼저 설정 계층을 나누는 것입니다. 계속 업데이트되는 원격 데이터는 구독 또는 Provider에 맡기고, 여러 기기에서 동일해야 하는 규칙과 정책은 검토 가능한 기본 설정에 넣습니다. 포트, TUN, DNS, LAN 관련 값은 기기별 오버라이드 계층에 둡니다. 구독 링크, 오버라이드 파일, 비공개 저장소는 서로 배타적인 선택지가 아닙니다. 각각 데이터 배포, 기기별 차이, 버전 관리를 해결합니다.

먼저 동기화 범위를 정하세요: 설정 소스, 기기 매개변수, 실행 데이터

멀티 디바이스 동기화의 첫 단계는 도구를 고르는 것이 아니라 어떤 데이터가 하나의 권위 있는 소스를 따라야 하는지 정하는 것입니다. Clash 설정은 다음 네 가지로 나누는 것을 권장합니다.

  • 원격 리소스: 프록시 노드 구독, 프록시 Provider, 규칙 Provider입니다. 원격에서 관리하며 클라이언트가 설정된 주기에 따라 갱신합니다.
  • 공유 로직: 프록시 그룹 이름, 규칙 순서, 도메인 규칙, 지역별 라우팅과 기본 처리 정책입니다. 기본 YAML 또는 버전 관리 저장소에 두기 좋습니다.
  • 기기 매개변수: mixed-port, 컨트롤 포트, LAN 리스닝, TUN 활성화, 네트워크 인터페이스 선택, 일부 DNS 리스닝 설정입니다. 기기별로 관리해야 합니다.
  • 실행 데이터: 로그, 캐시, 연결 기록, Geo 데이터 다운로드 결과, Provider 캐시, 클라이언트 데이터베이스입니다. 각 기기에서 직접 생성해야 합니다.

클라이언트의 ‘설정 디렉터리’에는 위와 같은 여러 데이터가 함께 들어 있는 경우가 많으므로, 클라우드 드라이브로 디렉터리 전체를 양방향 동기화하는 것은 적합하지 않습니다. 두 기기를 동시에 실행하면 데이터베이스와 상태 파일이 반복해서 덮어써질 수 있고, 운영체제마다 경로, 권한, 줄바꿈 형식도 다르게 기록됩니다. 마이그레이션이 필요할 때는 사용 중인 데이터 디렉터리를 공유 폴더처럼 취급하지 말고, 명확한 YAML 파일이나 클라이언트가 제공하는 백업 파일을 내보내야 합니다.

내용 권장 소스 기기 간 동일 여부
프록시 노드 구독 또는 프록시 Provider 대체로 동일
프록시 그룹 및 규칙 순서 기본 설정 또는 비공개 저장소 대체로 동일
TUN, 포트 및 네트워크 인터페이스 기기 오버라이드 대체로 다름
로그 및 Provider 캐시 클라이언트에서 로컬 생성 동기화하지 않음

첫 번째 방식: 구독 링크로 노드 동기화

구독 링크는 ‘여러 기기에서 동일한 노드 목록을 받는’ 문제를 해결하는 데 가장 적합합니다. 각 기기에서 같은 구독 주소를 가져온 뒤 클라이언트가 주기적으로 업데이트하도록 합니다. 노드 목록을 수동으로 복사할 필요가 없고, 노드 이름이나 주소, 사용 가능 상태가 바뀌어도 각 기기가 독립적으로 새 정보를 받을 수 있습니다.

다만 구독은 보통 프록시 항목만 제공하거나 서버에서 생성한 전체 설정을 제공합니다. 서버의 전체 설정에 프록시 그룹과 규칙이 포함되어 있다면 클라이언트 업데이트 시에도 원격 콘텐츠가 우선됩니다. 로컬 설정이 덮어써지는 것을 막으려면 수정하지 않은 구독 설정을 별도로 보관하고, 클라이언트가 지원하는 병합, 스크립트 또는 오버라이드 기능으로 기기별 규칙을 추가하세요. 클라이언트마다 ‘오버라이드’, ‘설정 병합’, ‘전처리 스크립트’의 동작 방식이 다르므로 클라이언트를 바꾸기 전에 처리 순서를 확인해야 합니다.

mihomo 설정에서는 노드 소스를 proxy-providers로 선언하여 공유 기본 설정이 원격 Provider만 참조하도록 만들 수도 있습니다. 다음 구조는 업데이트 주기, 캐시 경로, 상태 확인의 관계를 보여 줍니다.

proxy-providers:
  primary:
    type: http
    url: https://sub.example.net/profiles/team-laptop.yaml
    path: ./providers/primary.yaml
    interval: 21600
    health-check:
      enable: true
      interval: 600
      url: https://www.gstatic.com/generate_204

proxy-groups:
  - name: 수동 선택
    type: select
    use:
      - primary
    proxies:
      - DIRECT

interval은 Provider를 가져오는 주기를 제어합니다. 상태 확인 주기는 Provider에 포함된 프록시를 검사하는 간격이며, 구독을 다시 다운로드하는 주기와는 다릅니다. 캐시 경로는 현재 기기의 로컬 경로로 유지하고 동기화 저장소에 넣지 않아도 됩니다. 예시 도메인은 구조 설명을 위한 것이므로 실제 사용 시 자신의 구독 주소를 입력하고 네트워크 환경에 맞는 접근 가능한 테스트 주소를 선택하세요.

구독 인증 정보 분리 방법

구독 URL에는 리소스에 접근할 수 있는 인증 정보가 포함되는 경우가 많으므로 민감 정보로 취급해야 합니다. 실제 구독 주소를 공개 저장소, 스크린샷, 장애 로그 또는 공개 공유 설정 조각에 넣지 마세요. 여러 기기에서 사용할 때는 각 클라이언트에 구독 주소를 로컬로 저장하고, 공유 저장소에는 인증 정보가 없는 정책과 규칙만 관리하는 방식이 좋습니다. 서버에서 기기별 전용 주소를 발급할 수 있다면 기기별 인증 정보를 사용하면 특정 기기의 접근만 중지하기도 쉽습니다.

일반 Clash 클라이언트가 Git 로그인 세션이 필요한 비공개 저장소 주소를 직접 읽을 수 있다고 보장할 수는 없습니다. 브라우저에서 비공개 파일이 열린다고 해서 커널이 HTTP 요청을 보낼 때 같은 인증 정보를 함께 전송하는 것은 아닙니다. 단기간만 유효한 다운로드 주소도 만료 후 자동 업데이트를 실패하게 만듭니다. 따라서 구독 배포 서버는 클라이언트가 장기간 가져갈 수 있는 접근 방식을 제공해야 합니다.

두 번째 방식: 오버라이드 파일로 기기별 차이 저장

오버라이드 계층은 ‘규칙은 대체로 같지만 시스템 매개변수는 다른’ 상황에 적합합니다. 예를 들어 데스크톱에서는 시스템 프록시를 사용하지 않는 일부 프로그램을 TUN으로 처리해야 하고, 업무용 기기에서는 시스템 프록시만 활성화하며, 가정용 기기에서는 LAN 접근을 허용할 수 있습니다. 이런 차이를 하나의 YAML에 억지로 넣으면 동기화할 때마다 로컬 매개변수를 수동으로 되돌려야 합니다.

공유 기본 설정은 중립적인 상태로 유지하고, 기기마다 간단한 차이 파일을 관리할 수 있습니다. 논리적으로는 다음과 같이 나눌 수 있습니다.

profiles/
  base.yaml
overrides/
  windows-desktop.yaml
  macbook.yaml
  linux-shell.yaml
rules/
  local-direct.yaml
  service-routing.yaml

Windows 데스크톱 오버라이드에서는 TUN과 자동 라우팅을 활성화할 수 있고, Linux 명령줄 환경에서는 고정된 혼합 포트만 필요할 수 있습니다. macOS에서는 사용하는 클라이언트와 시스템 권한에 따라 TUN 활성화 여부를 결정합니다. allow-lan, bind-address, 외부 컨트롤러 리스닝 주소도 기기 매개변수로 봐야 합니다. 이 값들이 LAN에서 접근 가능한 범위를 바꾸기 때문입니다.

mixed-port: 7890
allow-lan: false

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

오버라이드라고 해서 모든 YAML을 자동으로 합칠 수 있다는 뜻은 아닙니다. 클라이언트마다 얕은 병합, 깊은 병합, 스크립트 처리, 필드 교체 등 방식을 다르게 사용할 수 있으며 배열은 특히 차이가 발생하기 쉽습니다. 예를 들어 오버라이드의 rules 배열이 기본 설정의 규칙 뒤에 추가되지 않고 기본 설정 전체를 대체할 수 있습니다. 프록시 그룹 배열도 통째로 교체될 수 있습니다. 동기화 절차를 처음 만들 때는 소수의 테스트 규칙으로 실제 병합 결과를 확인한 뒤 전체 설정을 옮기세요.

DNS 설정도 공유 항목과 기기 항목을 나눠야 합니다

DNS 규칙 로직은 공유할 수 있습니다. 예를 들어 Fake-IP 사용 여부, 제외 목록에 넣을 도메인, 라우팅에 사용할 규칙 집합 등이 그렇습니다. 하지만 리스닝 주소, LAN DNS 서비스, 시스템 DNS를 가로채는 방식은 기기 환경에 따라 달라집니다. 모바일 핫스팟, 가정용 LAN, 회사 네트워크에서는 내부 도메인 해석 요구 사항이 서로 다를 수 있습니다. 모든 기기에 동일한 nameserver와 리스닝 설정을 동기화하더라도 한 기기에서 정상이라고 다른 기기에도 적합한 것은 아닙니다.

TUN을 사용할 때는 클라이언트 커널 버전과 플랫폼 권한이 해당 필드를 지원하는지도 확인해야 합니다. mihomo 확장 설정을 구형 원본 Clash 필드만 지원하는 클라이언트에 그대로 전달해서는 안 됩니다. 여러 플랫폼에서 동기화하기 전에 각 클라이언트가 실제로 사용하는 커널을 확인하고, 공유 설정에 사용할 필드 집합을 결정하세요.

세 번째 방식: 비공개 저장소로 공유 설정과 변경 이력 관리

사용자 지정 규칙이 많고 여러 기기 오버라이드와 장기 유지 관리 스크립트가 필요하다면, YAML을 반복해서 주고받는 것보다 비공개 Git 저장소가 변경 사항을 추적하기 쉽습니다. 저장소의 핵심 가치는 구독 서비스를 직접 대체하는 데 있지 않습니다. ‘누가 어느 로직을 왜 수정했는지, 문제가 생기면 어디로 되돌릴지’를 기록하는 데 있습니다.

저장소에는 검토 가능한 소스 파일만 저장하고 클라이언트 실행 디렉터리는 커밋하지 않는 것이 좋습니다. 기본 YAML, 기기별 오버라이드, 규칙 텍스트, 생성 스크립트, 사용 설명서는 버전 관리에 포함할 수 있습니다. 로그, 캐시, 데이터베이스, 실제 구독 주소, 클라이언트가 자동으로 다운로드하는 Provider 파일은 제외해야 합니다.

clash-config/
  profiles/
    base.yaml
  overrides/
    desktop.yaml
    laptop.yaml
    server.yaml
  rules/
    private-network.yaml
    work-services.yaml
  scripts/
    build-config.js
  README.md
  .gitignore

팀이나 가족 구성원이 같은 규칙 세트를 공유해야 한다면 저장소에서 프록시 그룹 이름을 약속하세요. 예를 들어 규칙은 수동 선택, 자동 선택, DIRECT만 참조하고 기기 오버라이드에서는 이름을 임의로 바꾸지 않도록 합니다. 그러면 새 규칙을 추가할 때 특정 기기에 대상 프록시 그룹이 없어 로드에 실패하는 일을 막을 수 있습니다.

비공개 저장소의 설정은 두 가지 방식으로 배포할 수 있습니다. 첫 번째는 각 기기에서 저장소를 가져온 뒤 로컬 스크립트로 기본 계층과 기기 계층을 합쳐 최종 YAML을 만드는 방법입니다. 두 번째는 통제된 환경에서 최종 설정을 생성한 뒤 클라이언트가 접근할 수 있는 배포 주소로 게시하는 방법입니다. 전자는 로컬 디버깅이 편하지만 기기에 Git과 생성 환경이 필요합니다. 후자는 구독 가져오기만 담당하는 클라이언트에 더 적합하지만 배포 권한을 신중하게 관리해야 합니다.

저장소와 클라이언트가 수정 권한을 두고 경쟁하지 않게 하세요

저장소와 클라이언트 중 어느 쪽이 권위 있는 소스인지 명확히 정해야 합니다. 규칙을 저장소 기준으로 관리한다면 클라이언트가 생성한 최종 설정을 장기간 직접 수정하지 마세요. 변경이 필요하면 소스 파일로 돌아가 수정하고 테스트한 뒤 다시 생성해야 합니다. 특정 기기에서 임시로 규칙을 추가했다면 먼저 로컬 실험으로 기록하고, 유효성을 확인한 뒤 공유 계층에 병합하세요. 그렇지 않으면 다음 가져오기 또는 생성 과정에서 클라이언트의 변경 사항이 사라지고, 저장소에서도 그 차이가 어디서 생겼는지 설명할 수 없습니다.

YAML 앵커는 하나의 파일 안에서 반복되는 내용을 줄여 주지만, 여러 독립 파일을 자연스럽게 넘나들 수는 없습니다. 설정을 분할한 뒤 결합하는 방식은 여전히 클라이언트의 오버라이드 기능이나 외부 생성 단계에 따라 달라집니다. 파일 확장자만 보고 직접 병합할 수 있다고 판단하지 마세요.

업데이트 순서를 고정하세요: 원격 리소스, 오버라이드, 최종 검증 순서

멀티 디바이스 동기화에서 가장 흔한 문제는 설정을 잘못 작성해서가 아니라 업데이트 순서가 서로 다르기 때문에 발생합니다. 한 기기는 구독을 먼저 업데이트한 뒤 오버라이드를 적용하고, 다른 기기는 전체 설정을 먼저 덮어쓴 뒤 구독을 업데이트하면 최종 프록시 그룹과 규칙이 달라질 수 있습니다. 모든 기기에서 다음과 같은 동일한 절차를 사용하세요.

  1. 현재 권위 있는 소스를 확인합니다. 이번에 수정할 대상이 구독인지, 공유 기본 설정인지, 기기 오버라이드인지 확인하고 생성 결과를 직접 편집하지 않습니다.
  2. 공유 설정을 가져옵니다. 비공개 저장소에서 최신 기본 계층과 규칙 파일을 가져오고, 먼저 버전 충돌을 처리합니다.
  3. 원격 리소스를 업데이트합니다. 프록시 Provider와 규칙 Provider를 새로 고치고 주소에 계속 접근할 수 있는지 확인합니다.
  4. 기기 오버라이드를 적용합니다. 현재 기기의 포트, TUN, DNS 리스닝, LAN 매개변수를 추가합니다.
  5. 설정 테스트를 실행합니다. 클라이언트의 설정 검사 또는 커널 테스트 기능으로 YAML 문법, 프록시 그룹 참조, 규칙 대상이 유효한지 확인합니다.
  6. 다시 로드하고 트래픽을 검증합니다. 직접 연결 도메인, 프록시 도메인, DNS 조회, 시스템 프록시를 사용하지 않는 애플리케이션을 각각 테스트합니다.
  7. 의도적으로 보존할 변경 사항을 커밋합니다. 공유 로직에 해당하는 변경만 저장소에 반영하고, 임시 포트와 로컬 경로는 기기 계층에 둡니다.

업데이트 중에는 여러 기기가 같은 클라우드 드라이브 파일에 동시에 결과를 쓰게 하지 않는 것이 좋습니다. Git은 텍스트 버전을 처리할 수 있지만 클라이언트 데이터베이스와 생성 파일은 보통 병합에 적합하지 않습니다. 다른 기기에서 계속 수정해야 한다면 먼저 커밋하고 푸시한 뒤 대상 기기에서 가져오세요. 양쪽이 이전 버전을 바탕으로 같은 규칙을 동시에 편집하는 일을 피할 수 있습니다.

변경 유형 수정할 위치 동기화 작업
노드 추가 또는 만료 구독 또는 Provider 서버 클라이언트에서 원격 리소스 새로 고침
새 도메인 라우팅 추가 공유 규칙 파일 저장소에 커밋한 뒤 다시 생성
로컬 프로그램이 포트를 사용 중 기기 오버라이드 현재 기기만 수정
특정 기기에서 TUN을 활성화하지 않음 기기 오버라이드 공유 기본 계층은 수정하지 않음

동기화 충돌 및 설정 로드 실패 진단 방법

구독 업데이트 후 사용자 지정 규칙이 사라짐

사용자 지정 규칙이 구독으로 생성된 파일에 직접 작성되었는지 먼저 확인하세요. 그렇다면 업데이트 때 원격 전체 설정으로 덮어써지는 것은 예상된 동작입니다. 규칙을 클라이언트가 지원하는 오버라이드 계층으로 옮기거나, 별도의 기본 설정에서 관리하고 rule-providers로 규칙을 참조하세요. 오버라이드 적용 순서도 확인해야 합니다. 일부 클라이언트는 구독 업데이트 후 오버라이드를 자동으로 다시 적용하지만, 다른 클라이언트는 설정을 수동으로 다시 생성해야 합니다.

한 기기에서는 같은 설정이 작동하지만 다른 기기에서는 시작되지 않음

먼저 커널 유형, 필드 지원 여부, 로컬 리소스를 확인하세요. 원본 Clash, Clash Meta, mihomo는 확장 필드 지원 범위가 서로 다릅니다. TUN은 시스템 권한과 플랫폼 네트워크 스택에도 의존합니다. 그다음 포트 사용 여부, 로컬 경로 존재 여부, 외부 컨트롤러 주소 충돌을 확인하세요. 규칙을 서둘러 삭제할 필요는 없습니다. 규칙은 보통 리스닝 포트를 생성하지 못하게 만드는 원인이 아닙니다.

프록시 그룹에서 프록시 또는 Provider를 찾을 수 없다고 표시됨

use에서 참조하는 Provider 이름이 proxy-providers의 이름과 완전히 일치하는지 확인하고 Provider가 정상적으로 다운로드되었는지도 확인하세요. 공유 설정에서 프록시 그룹 이름을 고정했다면 기기 오버라이드에서 이름을 바꾸지 않아야 합니다. YAML은 들여쓰기에 민감하므로 Provider가 잘못된 계층에 들어가도 참조 대상이 없는 것처럼 보일 수 있습니다.

기기마다 규칙 매칭 결과가 다름

저장소의 소스 파일만 비교하지 말고 최종 로드 설정을 먼저 비교하세요. 기기마다 규칙 Provider 캐시 버전이 다를 수 있고, 오버라이드 과정에서 rules 배열 전체가 교체되었을 수도 있습니다. 규칙 순서가 같은지, 특히 범위가 넓은 도메인 규칙, GEOIP 규칙, 마지막 MATCH 기본 처리를 확인하세요. Clash는 일반적으로 규칙을 위에서 아래로 검사하므로 먼저 일치한 규칙이 이후 트래픽의 경로를 결정합니다.

비공개 저장소 주소는 브라우저에서 열리지만 클라이언트 업데이트가 실패함

대개 인증 방식이 원인입니다. 브라우저에는 로그인 상태가 저장되어 있지만 Clash 커널의 Provider 요청에는 같은 인증 정보가 없습니다. 주소가 웹 세션, 임시 권한, 리디렉션 페이지에 의존하는지 확인하세요. 클라이언트는 YAML 콘텐츠를 직접 가져오고 정상적인 HTTP 응답을 받아야 합니다. 로그인 페이지가 반환되면 상태가 성공처럼 보여도 콘텐츠가 유효한 YAML이 아니므로 파싱에 실패합니다.

세 가지 방식의 조합 권장안

개인 기기가 두세 대뿐이고 규칙 변경도 많지 않다면 ‘구독 링크 + 클라이언트 오버라이드’ 구성을 사용할 수 있습니다. 노드는 구독으로 업데이트하고 포트와 TUN은 각 기기에 두며, 사용자 지정 규칙은 클라이언트가 명확히 지원하는 오버라이드 설정에 넣습니다. 유지 관리 비용이 낮은 방식입니다.

많은 규칙을 장기간 관리해야 한다면 ‘구독 Provider, 공유 기본 설정, 기기 오버라이드’의 3계층 구조를 사용할 수 있습니다. 기본 설정은 프록시 그룹과 규칙 순서를 담당하고, Provider는 노드와 원격 규칙을 담당하며, 기기 오버라이드는 플랫폼별 차이를 담당합니다. 최종 설정은 클라이언트가 병합하거나 로컬 스크립트로 생성합니다.

여러 사람이 협업하거나 기기가 많다면 비공개 저장소를 추가해 기본 설정, 규칙, 생성 과정을 관리하세요. 저장소에는 실제 구독 인증 정보를 저장하지 않고 클라이언트 캐시도 동기화하지 않습니다. 변경 사항은 가져오기, 테스트, 커밋, 배포 절차를 거치며 각 기기는 자신에게 맞는 최종 설정만 사용합니다.

어떤 조합을 선택하든 여러 권위 있는 소스가 동시에 존재하지 않게 해야 합니다. 노드는 구독에서, 규칙은 저장소에서, 기기 매개변수는 로컬 오버라이드에서 관리하고 각 데이터 유형은 한 곳에서만 편집하세요. 경계가 명확해지면 멀티 디바이스 동기화는 ‘설정 전체 복사’에서 ‘계층별 업데이트와 검증’으로 바뀝니다. 구독 업데이트, 규칙 변경, 플랫폼별 차이도 서로 독립적으로 처리하기 쉬워집니다.

Clash 다운로드