Mac·iPhone·Windows에서 Clash 설정 동기화하는 방법

동기화 범위: 규칙은 공유하고 기기별 설정은 유지

‘설정을 함께 쓴다’는 것은 같은 설정 파일을 그대로 적용한다기보다 설정의 공통 출처를 공유한다는 의미에 가깝습니다. 노드, 정책 그룹 이름, 라우팅 규칙은 최대한 통일할 수 있지만, 로컬 리스닝 포트, TUN 처리 방식, 컨트롤러 인터페이스, 클라이언트 환경설정은 기기별로 관리하는 것이 좋습니다. 그래야 노드를 업데이트할 때 다른 기기의 네트워크 설정까지 덮어쓰지 않습니다.

먼저 코어와 GUI 클라이언트를 구분해야 합니다. mihomo는 지원하는 설정을 해석하고 규칙을 매칭해 프록시 연결을 설정합니다. 클라이언트는 구독 업데이트, 설정 선택, 오버라이드, 시스템 연동을 담당합니다. 각 클라이언트마다 기능을 제공하는 화면과 저장 방식이 다릅니다. iPhone 클라이언트가 mihomo를 사용하는 것도 아닙니다. 노드 구독을 가져올 수 있다고 해서 Clash YAML의 규칙, DNS, 정책 그룹을 모두 적용할 수 있는 것은 아닙니다.

공유하기 좋은 항목: 노드 출처, 안정적으로 유지할 정책 그룹 이름, 도메인 규칙, 모든 기기에서 지원하는 규칙 세트
기기별로 유지할 항목: mixed-port, external-controller, 컨트롤러 인터페이스 키, TUN 및 네트워크 인터페이스 관련 설정
호환성을 확인할 항목: 프로토콜 지원 여부, proxy-providers, rule-providers, DNS 필드, 클라이언트 전용 확장 기능

세 가지 동기화 방식 비교

구독 링크는 공급자의 노드 업데이트를 계속 받는 데 적합합니다. iCloud 폴더는 소수의 기기에서 직접 관리하는 파일을 주고받기 좋습니다. 비공개 Git 저장소는 규칙 변경을 검토하고 이전 버전으로 되돌려야 할 때 유용합니다. 어느 방식이든 설정을 기기에 전달할 뿐, 현재 연결 상태나 선택한 노드, 시스템 프록시 켜기/끄기까지 자동으로 동기화하지는 않습니다.

방식	적합한 내용	업데이트 방법	주요 제한 사항
구독 링크	노드 및 공급자의 전체 설정	기기별로 구독 새로고침	응답 형식과 필드 지원이 다를 수 있음
iCloud 폴더	직접 관리하는 YAML 파일	파일 동기화 후 다시 가져오거나 새로고침	클라이언트가 원본 파일을 계속 읽는다고 보장할 수 없음
비공개 Git 저장소	규칙, 템플릿, 로컬 오버라이드 예시	가져오기, 검토, 적용	인증 정보와 배포 절차를 별도로 관리해야 함

주된 목적이 ‘Mac과 휴대폰에서 같은 노드를 쓰는 것’이라면 구독부터 시도하세요. ‘규칙을 바꾸면 모든 기기에 반영하는 것’이 목적이라면 공통 규칙 출처를 먼저 마련한 뒤 파일 동기화와 Git 배포 중 적합한 방법을 선택하세요. 노드를 공유하려고 각 기기의 클라이언트 데이터 폴더 전체를 복사하지는 마세요.

구독 링크: 모든 기기에서 가져와 같은 출처로 업데이트

가져오기와 새로고침 순서

서비스 제공업체에 구독 출력 형식을 확인하세요. 전체 Clash 설정인지, 노드 목록인지, 다른 클라이언트 전용 형식인지 확인합니다.
Mac 클라이언트의 설정 관리 화면에서 링크를 가져온 다음 한 번 수동으로 업데이트하세요. 정책 그룹과 규칙이 있는지 확인한 뒤 해당 설정을 활성화합니다.
Windows 클라이언트에서도 같은 출처의 구독을 가져와 실제 응답이 동일한지 확인하세요. 서비스에 따라 요청 매개변수나 클라이언트 식별 정보에 따라 형식이 달라질 수 있습니다.
iPhone 클라이언트에서 지원되는 구독 유형을 선택해 가져온 결과를 확인하세요. 노드만 가져온 경우 규칙과 DNS는 별도로 설정해야 합니다.

세 클라이언트의 구독 새로고침은 각각 따로 실행해야 합니다. Mac에서 업데이트해도 iPhone이 자동으로 새로고침되지는 않으며, 모바일 기기는 백그라운드 실행에 제한이 있을 수 있습니다. 자동 업데이트 간격은 우선 24시간으로 설정하고 노드가 바뀌었을 때 수동으로 새로고침해 보세요. 이는 시작 설정을 위한 제안이며, 실제 설정 가능한 간격과 백그라운드 동작은 클라이언트에 따라 다릅니다.

구독 업데이트로 수정 사항이 덮어쓰이지 않게 하기

구독으로 내려받은 파일을 직접 수정하면 다음 새로고침 때 변경 내용이 사라질 수 있습니다. 오버라이드를 지원하는 클라이언트에서는 로컬 포트, DNS 조정, 사용자 지정 규칙을 별도 오버라이드에 두세요. 지원하지 않는다면 로컬 설정 파일을 별도로 보관하고 노드를 어떻게 업데이트할지 정해 두어야 합니다. 모든 기기가 지원하는 경우 노드 공급자를 사용해 노드 업데이트와 기본 설정을 분리할 수도 있습니다.

구독 주소에는 보통 액세스 토큰이 포함되므로 비밀번호처럼 관리하세요. 전체 주소를 공개 스크린샷이나 로그, 공개 저장소에 올리지 말고, 형식을 변환한다는 이유로 낯선 온라인 서비스에 함부로 전달하지 마세요. 링크가 유출됐다면 서비스 제공업체에서 토큰을 교체한 다음 각 기기의 구독 출처를 업데이트하세요.

iCloud 폴더: 파일 동기화 후 다시 가져오기

Mac의 ‘Finder’ → ‘iCloud Drive’에서 전용 폴더를 만드세요. 예를 들어 ClashConfig 폴더를 만들고 배포할 설정 파일만 넣습니다. iPhone에서는 ‘파일’ → ‘둘러보기’ → ‘iCloud Drive’에서 확인할 수 있습니다. Windows에서는 iCloud를 설치하고 로그인한 뒤 iCloud Drive를 켜야 해당 폴더에 접근할 수 있습니다.

한 기기를 주 편집 기기로 정하고 shared.yaml을 저장한 다음 업로드가 완료될 때까지 기다리세요.
대상 기기에서 파일이 클라우드에만 있는 자리표시자가 아니라 로컬에 다운로드되었는지 확인하세요.
클라이언트의 파일 가져오기 기능으로 해당 파일을 선택하고, 파싱 결과를 확인한 다음 현재 설정으로 전환하세요.
수정한 뒤에는 먼저 한 기기에서 확인하고, 다른 기기에서는 파일을 다시 가져오거나 클라이언트가 지원하는 새로고침 기능을 사용하세요.

핵심은 ‘원본 파일을 읽는 것’과 ‘복사본을 가져오는 것’을 구분하는 데 있습니다. 일부 클라이언트는 YAML을 자체 데이터 폴더에 복사합니다. 이 경우 iCloud 파일은 바뀌어도 클라이언트는 이전 복사본을 계속 사용합니다. 어떤 설정을 적용했는지 쉽게 확인할 수 있도록 정책 그룹 이름을 잠시 바꾼 뒤 다시 가져와 화면이 바뀌는지 확인하면 실제로 읽어 온 위치를 파악할 수 있습니다.

두 기기에서 같은 YAML을 동시에 편집하지 마세요. 파일 동기화 과정에서 충돌 사본이 생길 수 있고, 수동으로 병합하다 들여쓰기나 규칙 순서가 잘못될 수도 있습니다. 한 번에 한 기기에서만 편집하고, 사용 가능한 이전 파일을 보관하세요. 수신 기기에서 변경 사항이 적용된 것을 확인한 뒤 다음 수정 작업을 진행하는 것이 좋습니다.

비공개 Git: 규칙 검토와 설정 되돌리기

Git은 직접 관리하는 규칙과 설정 구조를 저장하는 데 적합하며 계정 인증 정보를 보관하는 용도는 아닙니다. 아래처럼 디렉터리를 나눌 수 있습니다. 파일 이름은 프로젝트에서 정한 규칙일 뿐 Clash나 mihomo가 자동으로 인식하지 않습니다. 클라이언트에서 직접 가져오거나 자체 생성 절차로 파일을 조합해야 합니다.

clash-config/
├── shared.yaml
├── rules/
│   └── direct.yaml
├── local/
│   ├── mac.yaml
│   └── windows.yaml
└── .gitignore

shared.yaml에는 공통 정책 그룹과 규칙을 저장하고, local/에는 기기별 설정을 저장합니다. 실제 구독 주소와 키가 포함된 파일은 커밋 대상에서 제외하세요. 비밀 정보가 이미 Git 기록에 포함됐다면 나중에 무시 규칙을 추가해도 기록에서 사라지지 않으므로 인증 정보를 교체해야 합니다. 비공개 저장소는 접근 제어 수단 중 하나일 뿐, 모든 비밀 정보를 장기간 보관해도 된다는 뜻은 아닙니다.

커밋, 가져오기, 검증

git diff -- shared.yaml rules/
git add shared.yaml rules/
git commit -m "직접 연결 규칙 순서 조정"

# 다른 데스크톱 기기에서 작업 사본 업데이트
git pull --ff-only

git pull --ff-only는 분기된 변경 사항이 있으면 멈춥니다. 로컬 변경 내용을 먼저 처리할 수 있어 의도치 않은 병합이 생기는 일을 방지합니다. 가져오기에 성공한 뒤에도 클라이언트에서 설정을 다시 불러와야 합니다. iPhone에서 적절한 Git 작업 흐름을 사용할 수 없다면 신뢰할 수 있는 파일 가져오기 방식으로 배포 파일을 받으면 됩니다. 휴대폰에서 데스크톱 개발 환경을 통째로 재현할 필요는 없습니다.

mihomo 기반 데스크톱 환경에서는 적용 전에 최종 생성 파일을 테스트할 수 있습니다. 아래의 effective.yaml은 공통 설정과 기기별 설정을 병합한 파일을 뜻합니다. 이 명령을 실행하려면 mihomo 실행 파일을 로컬에서 호출할 수 있어야 합니다.

mihomo -t -f effective.yaml

설정 테스트에 통과했다는 것은 코어가 해당 설정을 받아들였다는 뜻입니다. 원격 노드에 연결할 수 있거나 시스템 프록시가 켜졌다는 의미는 아닙니다. 문제가 생기면 Git에서 이전 파일을 가져와 다시 가져오거나 새로고침하세요. 파일을 되돌려도 시스템 네트워크 설정은 복원되지 않으므로 별도로 확인해야 합니다.

로컬 오버라이드: 포트, TUN, 규칙 순서

Mac과 Windows는 규칙 로직을 공유하되 각 기기의 진입 설정은 별도로 유지할 수 있습니다. 아래는 mihomo 기반 데스크톱에서 사용하는 로컬 설정 필드의 일부이며, 완전한 프록시 설정은 아닙니다. 예시에서는 혼합 포트 7890을 사용하고 컨트롤러 인터페이스는 루프백 주소 127.0.0.1:9090에만 바인딩합니다.

mixed-port: 7890
allow-lan: false
mode: rule
external-controller: 127.0.0.1:9090
tun:
  enable: false

이 필드는 클라이언트가 지원하는 로컬 설정이나 오버라이드 기능을 통해 적용해야 합니다. 모든 클라이언트가 YAML을 같은 방식으로 병합한다고 가정하지 마세요. 특히 목록 필드는 기능에 따라 목록 전체를 바꾸거나 앞에 추가하거나 뒤에 덧붙일 수 있습니다. 적용한 뒤 최종 설정을 확인해 기존 프록시 그룹과 규칙이 실수로 사라지지 않았는지 살펴보세요.

포트: 먼저 다른 프로세스가 7890을 사용 중인지 확인하세요. 포트를 바꿨다면 터미널 프록시 환경 변수와 수동으로 설정한 앱 프록시도 함께 변경해야 합니다.
TUN: 데스크톱에서는 권한, 라우팅, 다른 VPN과의 연동을 고려해야 합니다. iPhone은 보통 시스템 네트워크 확장으로 트래픽을 처리하므로 데스크톱의 tun.stack이나 네트워크 인터페이스 이름을 그대로 적용할 수 없습니다.
DNS: 먼저 각 기기에서 작동하는 DNS 설정을 유지하세요. DNS 정책을 공유하려면 필드별 지원 여부를 확인해야 합니다. YAML 파싱에 성공했다는 이유만으로 동작까지 같다고 판단하지 마세요.
컨트롤러 인터페이스: 일반적으로 기기 간에 개방할 필요가 없습니다. LAN을 통한 제어가 꼭 필요하다면 인증과 접근 범위를 별도로 설정하세요. 바인딩 주소를 모든 네트워크 인터페이스로 단순히 바꾸지 마세요.

사용자 지정 규칙은 기본 처리 규칙보다 앞에 두기

Clash 스타일 규칙은 순서대로 매칭됩니다. 아래 규칙은 도메인 직접 연결 규칙을 최종 기본 처리 규칙보다 앞에 둬야 한다는 점을 보여주는 예시입니다. PROXY는 전체 설정에 이미 정의된 프록시 또는 정책 그룹 이름이어야 합니다.

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

기존 MATCH 뒤에 새 규칙을 추가하면 대개 해당 규칙까지 도달하지 못합니다. 공유 규칙에서는 특정 기기에만 있는 정책 그룹 이름도 피해야 합니다. 모든 기기에서 같은 이름의 그룹을 유지하고 그룹 안에서 기기별로 다른 노드를 선택하는 방식을 권장합니다. 그룹 이름을 통일해도 노드 선택까지 같을 필요는 없습니다.

회사 내부 도메인, LAN 주소, 특정 Wi-Fi에만 적용되는 예외 규칙은 로컬 설정에 두는 것이 좋습니다. Mac이 연결된 네트워크에서만 유효할 수 있으며, 휴대폰의 셀룰러 네트워크에 복사하면 쓸모가 없거나 예상과 다른 네트워크 출구를 선택할 수 있습니다.

동기화 후 확인 및 자주 발생하는 문제

업데이트할 때마다 ‘출처 → 최종 설정 → 규칙 매칭 → 실제 트래픽 출구’ 순서로 확인하면 클라이언트를 반복해서 재설치하는 것보다 효과적입니다. 먼저 한 기기에서 검증한 다음 다른 기기에 적용하면 문제 범위를 좁힐 수 있습니다.

출처 확인: 구독 업데이트 시각, 파일 수정 시각 또는 Git 커밋 기록을 확인해 세 기기에 같은 변경 사항이 전달됐는지 살펴보세요.
설정 확인: 현재 활성화된 설정의 이름과 정책 그룹 수를 확인하고, 추가한 규칙이 최종 적용 설정에 포함됐는지 살펴보세요.
트래픽 처리 확인: 데스크톱에서는 시스템 프록시나 TUN 상태를 확인하세요. iPhone에서는 클라이언트 연결 상태를 확인하고 다른 VPN과 충돌하는지도 살펴보세요.
라우팅 확인: 직접 연결되어야 하는 서비스와 프록시를 거쳐야 하는 서비스를 각각 열어 보세요. 연결 기록에서 적용된 규칙, 정책 그룹, 실제 노드를 확인합니다.

같은 구독인데 노드 목록이 다름

먼저 출력 형식, 클라이언트의 프로토콜 지원 여부, 로컬 필터 설정을 확인한 뒤 새로고침 시각을 비교하세요. 구독 서비스는 클라이언트 식별 정보에 따라 서로 다른 내용을 제공할 수도 있습니다. 노드 개수만으로 동기화 실패를 판단하지 마세요. 토큰이 포함된 전체 응답을 공개해 비교하는 일도 피해야 합니다.

규칙은 같은데 트래픽 출구가 다름

정상적인 상황일 수 있습니다. 수동으로 선택한 그룹의 현재 노드는 보통 각 기기에 로컬로 저장됩니다. 자동 속도 측정 그룹은 기기마다 연결된 네트워크에서 따로 측정합니다. Mac은 집 Wi-Fi에, iPhone은 셀룰러 네트워크에 연결되어 있다면 정책 그룹 정의가 같아도 다른 노드를 선택할 수 있습니다. 문제를 재현하려면 각 기기에서 일시적으로 같은 노드를 선택한 뒤 차이를 확인하세요.

파일을 업데이트했는데 클라이언트에는 이전 내용이 표시됨

먼저 복사본을 가져온 것은 아닌지, 다른 설정이 활성화된 것은 아닌지, 구독 업데이트 후 새로고침이 완료됐는지 확인하세요. 현재 작동하는 설정은 보관한 뒤 다시 가져와 테스트합니다. 장기적으로는 ‘같은 구독 또는 규칙 출처 + 기기별 로컬 오버라이드’ 구조를 권장합니다. 규칙 변경 기록을 추적하려면 Git을 추가하고, 소량의 파일을 수동으로 주고받을 때는 iCloud를 사용하세요. 동기화 범위를 명확히 할수록 플랫폼 간 문제를 쉽게 찾을 수 있습니다.

포트와 규칙 필드는 YAML 설정 가이드에서 확인할 수 있습니다. 처음 가져오기와 네트워크 트래픽 처리 방법은 설정 안내를 참고하세요.