여러 기기에서 하나의 Clash 설정 공유하기: 구독·동기화·백업 방법

먼저 동기화 대상을 정하세요: 노드, 규칙 또는 전체 실행 설정

“여러 기기에서 하나의 설정 공유”에는 보통 세 가지 요구가 있습니다. Windows, macOS, 휴대폰에서 같은 노드 목록을 사용하거나, 모든 기기에서 동일한 규칙과 프록시 그룹을 사용하거나, config.yaml 전체를 그대로 복사하는 방식입니다. 세 방식은 동기화 범위가 서로 다릅니다. 노드 구독은 가장 쉽게 통일할 수 있고, 규칙과 프록시 그룹은 중앙에서 관리하는 편이 적합합니다. 반면 전체 실행 설정은 운영체제, 클라이언트, 커널 버전의 영향을 자주 받습니다.

Clash와 mihomo 설정에는 프록시 서버만 들어 있는 것이 아닙니다. 리슨 포트, 컨트롤러 주소, TUN 인터페이스, DNS 하이재킹, LAN 접근, GeoData 모드, 로컬 파일 경로가 하나의 YAML 파일에 함께 기록될 수 있습니다. Windows에서 실행 중인 전체 설정을 macOS에 그대로 덮어쓰면 인터페이스 이름 불일치, 포트 충돌, 규칙 세트 경로 오류가 발생할 수 있습니다.

안정성에 따라 세 계층으로 나누기

공유 데이터 계층: 프록시 노드, 원격 규칙 세트, 프록시 그룹 구조입니다. 모든 기기에서 통일하기에 적합합니다.
플랫폼 매개변수 계층: TUN, DNS, 리슨 주소, 포트, 프로세스 매칭, 인터페이스 선택입니다. 운영체제별로 따로 관리해야 합니다.
클라이언트 상태 계층: 창 크기, 테마, 트레이 동작, 로그 수준, 최근 선택한 설정입니다. 보통 로컬에 두고 동기화하지 않습니다.

방법 1: 모든 기기에서 동일한 구독 링크 사용

구독 링크를 일괄 업데이트하는 방식은 유지 관리 비용이 가장 낮습니다. 각 기기가 구독 정보를 독립적으로 저장하고 필요할 때 같은 주소에서 설정을 가져옵니다. Windows와 macOS의 Clash Verge Rev, Android에서 mihomo 커널을 사용하는 호환 클라이언트는 모두 같은 주소를 개별적으로 가져올 수 있습니다. 기기 간에 로컬 파일을 직접 전송하지 않으므로 실행 상태가 서로 덮어써지지 않습니다.

일반적인 작업 순서

데스크톱 클라이언트에서 「구독」 또는 「설정」 페이지로 이동합니다.
「새로 만들기」 또는 「가져오기」를 선택하고 HTTPS 구독 주소를 붙여 넣습니다.
다운로드가 끝나면 해당 설정을 선택한 뒤 「현재 설정으로 지정」을 실행합니다.
자동 업데이트 설정에서 주기를 지정합니다. 예를 들어 1440분으로 설정하면 하루에 한 번 업데이트됩니다.
다른 기기에서도 가져오기를 반복하되, 첫 번째 기기에서 생성된 캐시 파일은 복사하지 않습니다.

클라이언트마다 메뉴 이름이 조금씩 다를 수 있습니다. Clash Verge Rev 2.x를 예로 들면 구독은 보통 「구독」 페이지에서 관리하고, 커널·시스템 프록시·TUN은 「설정」 페이지에 있습니다. 문제를 확인할 때는 “구독이 업데이트되었는지”와 “현재 설정으로 전환되었는지”를 구분해야 합니다. 전자는 새 콘텐츠를 다운로드할 뿐이고, 후자가 커널에서 실제로 불러올 설정을 결정합니다.

자동 업데이트 주기는 어떻게 설정할까요

노드 정보가 자주 바뀌지 않는다면 12~24시간마다 한 번 업데이트해도 충분합니다. 주기를 5분으로 설정하면 서버 요청이 늘어나고 네트워크 전환 시 설정 파일이 반복해서 저장될 수 있습니다. 일시적으로 노드 누락을 확인할 때는 수동으로 한 번 업데이트한 뒤 클라이언트에 표시되는 업데이트 시간이 바뀌었는지 확인하세요.

항목	통일 여부	처리 방법
노드 목록	통일	모든 기기에서 같은 구독 주소 가져오기
프록시 그룹	대체로 통일	구독 콘텐츠 또는 변환 템플릿으로 생성
현재 노드 선택	기기별로 독립	로컬 네트워크 지연 시간에 따라 선택
시스템 프록시 및 TUN	기기별로 독립	각 클라이언트의 설정 페이지에서 개별적으로 활성화
자동 업데이트 시간	다를 수 있음	데스크톱은 1440분으로 설정하고 모바일은 사용 빈도에 맞게 설정

방법 2: 클라우드 드라이브로 YAML 설정 동기화

클라우드 드라이브 동기화는 사용자 지정 규칙, 프록시 그룹, DNS 설정을 직접 관리하는 사용자에게 적합합니다. 일반적으로 직접 관리하는 YAML 파일을 OneDrive, iCloud Drive 또는 다른 동기화 디렉터리에 넣고 각 클라이언트에서 가져옵니다. 핵심은 클라우드 드라이브의 파일을 “원본 파일”로 취급하는 것이며, 클라이언트가 읽고 쓰는 전체 설정 디렉터리를 그대로 동기화하지 않는 것입니다.

클라이언트 전체 디렉터리 동기화를 권장하지 않는 이유

클라이언트 디렉터리에는 SQLite 데이터베이스, 창 상태, 로그, 캐시, 잠금 파일이 포함될 수 있으며 이러한 내용은 자주 변경됩니다.
두 기기를 동시에 실행하면 클라우드 드라이브가 “충돌 사본”을 만들 수 있고, 커널은 여전히 이전 파일을 읽을 수 있습니다.
운영체제마다 경로 구분자가 다르므로 Windows의 드라이브 문자 경로를 macOS나 Linux에서 바로 사용할 수 없습니다.
클라이언트 업그레이드 후 디렉터리 구조가 변경될 수 있습니다. 이전 디렉터리를 그대로 동기화하면 오래된 상태가 다시 기록될 수 있습니다.

더 안전한 순서는 다음과 같습니다. 클라우드 드라이브에는 shared-base.yaml을 보관하고, 각 기기에서 로컬로 다운로드하거나 복사한 다음 클라이언트에서 「설정」→「로컬 파일 가져오기」를 실행합니다. 규칙을 수정할 때는 원본 파일만 편집하고 YAML을 정상적으로 불러올 수 있는지 확인한 뒤 다른 기기에서 새 버전을 가져오게 하세요. 클라이언트가 덮어쓰기, 병합, 스크립트 기능을 지원한다면 공유 파일에는 규칙과 프록시 그룹만 넣고 TUN과 포트는 로컬 덮어쓰기에서 관리할 수도 있습니다.

설정 디렉터리는 클라이언트의 진입점을 기준으로 확인하세요

설정 디렉터리는 Clash 생태계의 통일된 표준이 아닙니다. mihomo를 명령줄로 실행할 때 일반적인 기본 설정은 Linux의 ~/.config/mihomo/config.yaml이며, 구형 Clash에서는 ~/.config/clash/가 흔합니다. 그래픽 클라이언트에는 별도의 애플리케이션 데이터 디렉터리와 구독 데이터베이스가 있는 경우가 많고, 파일 위치는 애플리케이션 식별자와 버전에 따라 달라집니다.

따라서 디렉터리를 찾을 때는 먼저 클라이언트가 제공하는 버튼을 사용해야 합니다. 예를 들어 Clash Verge Rev 2.x에서는 「설정」→「설정 디렉터리」→「디렉터리 열기」 순서로 이동합니다. 인터페이스에 해당 항목이 없다면 로그 첫 부분에 표시된 작업 디렉터리나 실행 매개변수를 확인하세요. 디렉터리에 config.yaml이 있다는 이유만으로 바로 덮어쓰지 말고, 먼저 로그에 표시된 실제 로드 경로를 확인해야 합니다.

클라우드 드라이브 동기화 시 안전한 작업 순서

설정을 수정할 클라이언트를 종료하여 같은 파일에 동시에 기록하지 않도록 합니다.
클라우드 드라이브 상태가 동기화 완료로 표시될 때까지 기다린 다음 YAML을 엽니다.
저장한 후 shared-base-conflicted-copy.yaml과 같은 충돌 사본이 생성되었는지 확인합니다.
한 기기에서 설정을 가져와 다시 로드하고 프록시 그룹, 규칙, DNS가 모두 정상적으로 해석되는지 확인합니다.
그 다음 다른 기기에서 해당 버전을 가져오고, 이전에 정상 작동하던 사본도 보관합니다.

방법 3: 직접 구축한 설정 호스팅과 원격 규칙 세트

기기가 많고 규칙을 지속적으로 관리해야 한다면 설정을 기본 설정, 프록시 제공자, 규칙 제공자로 나누어 HTTPS로 통합 호스팅할 수 있습니다. 각 기기에는 짧은 진입 설정만 저장하고, 노드와 규칙은 mihomo가 정기적으로 가져옵니다. 이 방식은 YAML을 수동으로 복사하는 것보다 데스크톱, 노트북, 홈 서버, 모바일 기기를 함께 사용할 때 적합합니다.

proxy-providers로 노드 중앙 관리

proxy-providers:
  shared:
    type: http
    url: "https://config.example.net/proxies.yaml"
    path: ./providers/shared.yaml
    interval: 86400
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 600

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

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

interval: 86400은 86400초마다, 즉 24시간마다 한 번 업데이트한다는 뜻입니다. 상태 확인은 600초마다 실행되며, 지정한 테스트 요청을 노드가 완료할 수 있는지만 판단할 뿐 실제 다운로드 속도를 의미하지는 않습니다. 원격 파일을 다운로드하면 ./providers/shared.yaml에 저장됩니다. 이 상대 경로는 커널 작업 디렉터리를 기준으로 하므로 클라이언트에 쓰기 권한이 있는지 확인해야 합니다.

rule-providers로 규칙 통일

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

rules:
  - RULE-SET,private,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

behavior: domain은 도메인 유형 규칙에 적합합니다. 파일에 CIDR 대역이 포함되어 있다면 콘텐츠에 맞는 behavior 유형을 사용해야 합니다. 여러 Clash 규칙 문법을 섞는 경우에는 mihomo 지원 여부에 따라 classical을 사용할 수 있습니다. behavior 유형과 파일 콘텐츠가 일치하지 않으면 규칙 로드에 실패하며, 로그에는 대개 provider 이름과 파싱 오류 위치가 표시됩니다.

원격 호스팅에서 처리해야 할 세부 사항

서버는 HTTPS를 제공하고 올바른 YAML 텍스트 콘텐츠를 반환해야 합니다.
비공개 주소에 접근 토큰이 필요하다면 토큰의 권한과 유효 기간을 제한해야 합니다.
기본 설정을 업데이트하기 전에 이전 버전을 보관하여 한 곳의 문법 오류가 모든 기기에 영향을 주지 않도록 합니다.
규칙 세트에는 안정적인 URL을 사용하여 커밋할 때마다 파일 주소가 바뀌지 않도록 합니다.
원격 파일을 업데이트한 후 새 프록시 그룹 구조를 적용하려면 클라이언트에서 「다시 로드」를 실행해야 할 수도 있습니다.

플랫폼 간 필드 차이: 어떤 내용은 로컬에 남겨야 할까요

공유 설정이 여러 플랫폼에서 실행될 수 있는지는 운영체제 관련 필드를 포함하는지에 달려 있습니다. 규칙 문법, 프록시 그룹, 원격 provider는 대체로 재사용하기 쉽지만 인터페이스, 프로세스, 포트, 로컬 경로는 기기별로 확인해야 합니다. mihomo 커널을 사용한다고 해서 모든 그래픽 클라이언트가 같은 인터페이스 옵션을 지원하는 것은 아닙니다. 클라이언트가 덮어쓰기 파일을 통해 최종 설정을 생성할 수도 있습니다.

TUN 모드와 인터페이스 설정

TUN은 가상 네트워크 인터페이스를 만들고 라우팅을 제어합니다. Windows, macOS, Linux, Android는 권한 모델이 서로 다르므로 그래픽 클라이언트에서 로컬 권한 승인을 요구하는 경우가 많습니다. 공유 파일에는 기본 구조만 남기고 interface-name, device, route-address-set처럼 로컬 환경에 의존하는 필드는 하드코딩하지 않는 편이 좋습니다.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

auto-detect-interface: true를 사용하면 고정 인터페이스 이름으로 인한 플랫폼 간 문제를 줄일 수 있습니다. 하지만 듀얼 NIC, 가상 머신, 회사 VPN을 동시에 실행할 때는 기본 라우팅을 계속 확인해야 합니다. 특정 기기에서 TUN을 켠 뒤 인터넷이 끊기면 먼저 「설정」→「TUN 모드」에서 기능을 끄고, 로그의 라우팅 및 권한 오류를 확인하세요. 공유 규칙을 곧바로 수정해서는 안 됩니다.

리슨 포트와 LAN 접근

mixed-port: 7890
allow-lan: false
bind-address: "*"
external-controller: 127.0.0.1:9090

mixed-port: 7890은 HTTP와 SOCKS 프록시 연결을 동시에 받습니다. 특정 기기에서 다른 프로그램이 포트를 사용 중이라면 해당 기기에서만 7891로 변경할 수 있습니다. external-controller가 로컬 클라이언트 연결에만 사용된다면 127.0.0.1:9090에서 수신하도록 설정하는 편이 좋습니다. LAN 공유가 필요할 때만 실제 요구에 맞게 allow-lan을 활성화하고, 시스템 방화벽과 Wi-Fi 네트워크 유형도 확인하세요.

로컬 경로와 규칙 리소스

Windows 경로는 C:\Users\Public\Clash\rules처럼 쓸 수 있지만 macOS와 Linux는 /로 시작하는 경로를 사용합니다. 플랫폼 간 호환을 위해 규칙 provider에는 가능한 한 ./rules/private.yaml 같은 상대 경로를 사용하세요. 클라이언트의 작업 디렉터리가 보호된 위치에 있다면 현재 사용자가 rules 및 providers 하위 디렉터리를 만들 수 있는지도 확인해야 합니다.

프로세스 규칙의 운영체제별 차이

PROCESS-NAME은 운영체제가 보고하는 프로세스 이름에 의존합니다. Windows에서는 example.exe와 매칭될 수 있고, macOS 애플리케이션의 실행 파일 이름은 Example일 수 있으며, Android에서는 패키지 이름으로 매칭될 수 있습니다. 정확한 프로세스별 라우팅이 필요하다면 플랫폼별 규칙 세트를 따로 두고 로컬 설정에서 참조하세요.

권장 구조: 공유 기본 설정과 로컬 덮어쓰기

Windows, macOS, Linux를 함께 사용하는 환경이라면 공유 기본 설정 하나를 관리하고 플랫폼별로 짧은 덮어쓰기 파일을 준비할 수 있습니다. 기본 설정에는 프록시 provider, 규칙 provider, 프록시 그룹, 공통 DNS 로직을 넣고, 덮어쓰기 파일에서는 포트, TUN, 프로세스 규칙, 컨트롤러 주소만 처리합니다.

파일 구성 예시

clash-config/
├── shared-base.yaml
├── overlays/
│   ├── windows.yaml
│   ├── macos.yaml
│   └── linux.yaml
├── rules/
│   ├── direct.yaml
│   └── reject.yaml
└── backups/
    └── shared-base-2026-08-04.yaml

덮어쓰기를 직접 병합할 수 있는지는 클라이언트 기능에 따라 다릅니다. 일부 클라이언트는 Merge, Mixin, 덮어쓰기, 스크립트 진입점을 제공하지만 다른 클라이언트는 최종 YAML만 가져올 수 있습니다. 자동 병합이 되지 않는다면 컴퓨터에서 windows-final.yaml과 같은 최종 파일을 생성한 뒤 해당 기기에서 가져오세요. 병합 후에는 같은 이름의 키가 어떻게 덮어써졌는지 반드시 확인해야 하며, 특히 rules, dns, proxy-groups처럼 목록이나 중첩 객체로 구성된 항목을 점검해야 합니다.

동기화할 때 현재 노드까지 통일하지 마세요

가정용 인터넷, 사무실 네트워크, 모바일 네트워크는 라우팅 조건이 서로 다릅니다. 같은 노드라도 Windows 데스크톱에서는 지연 시간이 42ms이고 휴대폰 셀룰러 네트워크에서는 180ms에 이를 수 있습니다. 각 기기는 프록시 그룹 선택을 독립적으로 유지하거나 url-test, fallback과 같은 자동 전략을 사용해야 합니다. 공유할 대상은 후보 노드와 테스트 규칙이며, 마지막 선택 결과까지 강제로 공유할 필요는 없습니다.

백업, 롤백, 충돌 처리

설정 동기화는 백업을 대신할 수 없습니다. 동기화는 삭제, 잘못된 들여쓰기, 잘못된 규칙까지 다른 기기로 전파하지만, 백업은 과거의 복구 가능한 버전을 보존하는 역할을 합니다. 최소한 현재 정상 설정, 최근 수정 직전 설정, 장기간 검증된 안정 버전은 보관해야 합니다.

변경하기 전에 확인할 네 가지

현재 파일을 복사하고 config-2026-08-04.yaml처럼 날짜를 붙여 이름을 지정합니다.
YAML이 공백 들여쓰기를 사용하고 Tab 문자가 섞이지 않았는지 확인합니다.
프록시 그룹이 참조하는 provider, 노드 이름, 다른 프록시 그룹이 실제로 존재하는지 확인합니다.
다시 로드한 후 로그를 확인하여 rules, proxy-providers, rule-providers가 모두 정상적으로 로드되었는지 확인합니다.

업데이트 후 모든 기기에서 동시에 문제가 발생하면 먼저 클라우드 드라이브 동기화나 원격 배포를 일시 중지하여 잘못된 버전이 계속 확산되지 않도록 합니다. 그런 다음 이전의 안정 파일을 복원하고 자동 업데이트를 한 번 끈 뒤 커널을 다시 로드합니다. 기본 연결이 복구된 것을 확인한 다음 이번 변경 사항을 부분별로 다시 적용하여 DNS, 규칙, 프록시 그룹, 원격 리소스 중 무엇이 실패를 일으켰는지 찾습니다.

일반적인 충돌 처리 순서

같은 이름의 사본이 두 개 생김: 수정 시간과 콘텐츠를 비교하고 파일 이름만으로 새 파일과 이전 파일을 판단하지 않습니다.
클라이언트에서 YAML 오류 표시: 로그에 표시된 줄 번호에서 위쪽으로 이동하며 들여쓰기와 따옴표를 확인합니다.
규칙은 업데이트되었지만 동작이 바뀌지 않음: 현재 설정을 다시 로드했는지 확인하고 규칙 매칭 순서를 점검합니다.
특정 기기에서 인터넷 연결 끊김: 먼저 해당 기기의 TUN과 시스템 프록시를 끈 뒤 공유 설정 자체를 확인합니다.
원격 provider 다운로드 실패: HTTPS 주소, 접근 권한, DNS, 로컬 캐시 경로를 확인합니다.

세 가지 방법 중 무엇을 선택할까요

사용 환경	권장 방법	주요 관리 항목
개인 기기 2~3대에서 같은 노드만 필요한 경우	동일한 구독 링크	기기별 업데이트 및 노드 선택
사용자 지정 규칙이 있고 변경 빈도가 낮은 경우	클라우드 드라이브의 원본 YAML 동기화	클라이언트 데이터베이스와 캐시 동기화 방지
기기가 많고 규칙을 장기간 관리하는 경우	직접 구축한 HTTPS 호스팅	버전 관리, 권한, 롤백
Windows, macOS, Linux를 함께 사용하는 경우	공유 기본 설정과 플랫폼별 덮어쓰기	TUN, 포트, 경로, 프로세스 규칙

대부분의 개인 사용 환경에서는 구독 링크로 시작하면 충분합니다. 규칙, DNS, 프록시 그룹을 직접 관리해야 할 때만 클라우드 드라이브의 원본 파일을 도입하세요. 기기 수가 늘어나면 노드와 규칙을 provider로 나누어 HTTPS로 정기 업데이트할 수 있습니다. 어떤 방법을 사용하든 운영체제 관련 설정은 로컬에 두고 즉시 롤백할 수 있는 안정적인 설정을 보관해야 합니다.

동기화를 완료한 후 각 기기에서 네 가지 결과를 따로 확인할 수 있습니다. 구독 업데이트 시간이 올바른지, 현재 설정으로 전환되었는지, 규칙 매칭이 예상대로인지, TUN 또는 시스템 프록시를 정상적으로 끄고 다시 켤 수 있는지 확인하세요. 이 네 가지를 나누어 검증하면 단순히 “웹페이지가 열리는지”만 판단하는 것보다 설정 차이를 쉽게 찾을 수 있습니다.