Mac·iPhone·iPad에서 Clash 설정 공유하기: 원격 구독과 iCloud 동기화

먼저 결론: 규칙 출처는 공유하고 기기별 설정은 유지하세요

Mac·iPhone·iPad에서 Clash 설정을 오래 함께 사용하려면 하나의 원격 설정 소스를 공유하고 기기별 로컬 설정은 따로 관리하는 방식을 우선 고려하세요. iCloud Drive는 파일을 직접 전달할 때, 비공개 Git 저장소는 규칙 변경을 관리하고 이전 버전으로 되돌릴 때 적합합니다. 세 방법은 동기화하는 대상이 다르므로 ‘파일이 업데이트됐다’고 해서 ‘클라이언트에 적용됐다’고 볼 수는 없습니다.

여기서 ‘같은 설정’이란 노드 출처, 정책 그룹 이름, 트래픽 분기 규칙이 일치한다는 뜻입니다. 각 기기의 최종 YAML까지 글자 하나하나 똑같을 필요는 없습니다. macOS의 수신 포트, TUN 라우팅, 보조 서비스 설정을 iOS 클라이언트에 그대로 옮기는 것은 적절하지 않습니다. iPhone과 iPad용 클라이언트가 Clash YAML을 바로 읽지 못할 수도 있습니다.

방법	적합한 상황	업데이트 방법	주요 관리 부담
원격 설정 구독	여러 기기에서 호환되는 클라이언트를 사용하고 설정 출처가 안정적인 경우	기기별로 가져온 뒤 다시 불러오기	구독, 덮어쓰기 설정, 업데이트 상태 관리
iCloud Drive	기기가 적고 전체 파일을 가끔 직접 수정하는 경우	파일 다운로드를 기다린 후 직접 가져오기	파일 사본과 충돌을 정리하고 중복 가져오기 처리
비공개 Git 저장소	사용자 지정 규칙이 많고 변경 내역을 관리해야 하는 경우	검토하고 병합한 뒤 배포하거나 가져오기	권한, 인증 정보, 배포 절차 관리

동기화 전 확인 사항: 코어, 설정 계층, 기기별 상태

Apple 칩 아키텍처가 설정 형식을 결정하지는 않습니다

Apple 칩을 탑재한 Mac에는 arm64 빌드를, Intel Mac에는 x86_64 빌드를 선택하세요. 이 차이는 프로그램 실행에 영향을 주지만 YAML 문법을 바꾸지는 않습니다. 설정 호환성을 좌우하는 것은 코어와 클라이언트 구현입니다. 클래식 Clash, Clash Meta(현 mihomo), 다른 코어를 사용하는 iOS 클라이언트는 프로토콜, 규칙 세트, DNS, TUN 필드 지원 여부가 서로 다를 수 있습니다.

각 기기에서 클라이언트 버전, 코어 버전, 설정 이름, 마지막으로 정상 로드된 시간을 기록해 두세요. 앱 버전이 같아도 코어까지 같다는 뜻은 아닙니다. 구독 업데이트 성공은 다운로드가 완료됐을 가능성만 보여 줍니다. 파싱 결과와 현재 활성화된 설정도 확인해야 합니다.

설정을 세 가지 계층으로 나누세요

공유 항목: 노드 출처, 정책 그룹 이름, 도메인·IP 분기 규칙, 규칙 세트 주소. 여러 기기에서 가능한 한 동일하게 유지합니다.
기기별 설정: 수신 포트, 로컬 네트워크 접근, TUN, DNS 가로채기, 로그 수준. 운영체제와 네트워크 환경에 맞게 각각 설정합니다.
실행 상태: 현재 선택한 노드, 속도 측정 결과, 연결 기록. 대개 클라이언트 데이터베이스에 저장되며 YAML 파일만으로 자동 동기화되지 않습니다.

예를 들어 모든 기기에 ‘일상 프록시’라는 정책 그룹이 있어도 같은 노드가 자동으로 선택되는 것은 아닙니다. 동일한 출구를 사용하려면 각 기기에서 정책 그룹의 현재 선택 항목을 확인하세요. 자동 속도 측정 그룹도 Wi-Fi·셀룰러 네트워크나 측정 시점에 따라 결과가 달라질 수 있습니다.

방법 1: 동일한 원격 구독을 사용하고 기기별로 업데이트

원격 구독은 일상적인 사용에 가장 적합합니다. 신뢰할 수 있는 HTTPS 주소에서 설정을 제공하고 각 기기가 개별적으로 가져옵니다. 먼저 주소가 완성된 Clash YAML을 반환하는지, 노드 목록만 반환하는지, Base64로 인코딩된 노드 문자열을 반환하는지 확인하세요. 뒤의 두 형식은 규칙과 정책 그룹이 포함된 완성된 설정으로 바로 사용할 수 없습니다.

처음 가져오고 업데이트하는 순서

Mac 클라이언트의 설정 관리 화면에서 원격 설정을 추가하고 구독 주소를 붙여 넣으세요. ‘Apple 기기 공유 규칙’처럼 알아보기 쉬운 이름을 지정하면 편리합니다.
다운로드한 뒤 파싱 로그를 확인해 proxies 또는 proxy-providers, proxy-groups, rules 등 필요한 항목이 모두 있는지 확인하고 현재 설정으로 지정하세요.
iPhone과 iPad 클라이언트의 원격 설정 가져오기 메뉴에서 같은 출처를 추가하세요. 해당 형식을 지원하지 않으면 제공 측에서 지원하는 형식으로 바꾸세요. 파일 확장자만 바꾸면 안 됩니다.
세 기기에서 각각 업데이트와 다시 불러오기를 실행하고 규칙 수, 정책 그룹 이름, 로드 오류를 확인하세요. 설정에 표시된 이름만 비교해서는 안 됩니다.
마지막으로 직접 연결과 프록시 연결을 하나씩 테스트하고 연결 기록에서 실제로 적용된 규칙과 출구를 확인하세요.

클라이언트마다 메뉴 이름은 ‘설정’, ‘Profiles’, ‘구독’ 등으로 다를 수 있으며 모든 앱에 공통으로 적용되는 절차는 없습니다. 시스템 프록시나 VPN 스위치 조작과 설정 업데이트도 별개의 작업입니다. 새 파일을 내려받은 뒤에도 일부 클라이언트는 새 내용을 적용하려면 설정을 전환하거나 터널에 다시 연결해야 합니다.

전체 구독 업데이트와 노드 제공자 업데이트는 다릅니다

클라이언트의 ‘구독 자동 업데이트’는 보통 설정 전체를 업데이트합니다. 반면 mihomo의 proxy-providers는 노드 제공자 내용을 업데이트합니다. 제공자의 interval: 3600이 3600초마다 업데이트를 시도한다는 뜻이어도 주 설정의 rules까지 바뀌지는 않습니다. 마찬가지로 rule-providers는 해당 규칙 세트를 업데이트할 뿐 YAML 전체를 다시 내려받는 기능은 아닙니다.

사용자 지정 규칙이 필요하면 클라이언트가 공식적으로 지원하는 로컬 덮어쓰기, 병합 또는 스크립트 기능을 우선 사용하세요. 다운로드 캐시의 YAML을 직접 편집하면 다음 구독 업데이트에서 수정 내용이 덮어써질 수 있습니다. 덮어쓰기 기능이 모든 기기에 있는 것은 아니므로 다운로드 전·후 또는 로드 시점 중 언제 적용되는지 확인해야 합니다.

방법 2: iCloud Drive로 파일을 동기화하고 클라이언트에 직접 가져오기

iCloud는 설정 파일 하나를 직접 관리하며 가끔 나머지 두 기기에 전달할 때 적합합니다. 파일은 동기화하지만 YAML을 검사하거나 클라이언트가 파일 변경을 감지한다고 보장하지는 않습니다. 시스템 파일 선택기로 가져오면 앱이 자체 샌드박스에 사본을 만들 수 있으며, 이후 원본이 바뀌어도 사본은 자동으로 업데이트되지 않습니다.

명확한 파일 전달 절차를 정하세요

Mac에서 ‘시스템 설정’ → ‘Apple 계정’ → ‘iCloud’ → ‘iCloud Drive’를 열고 동기화가 켜져 있는지 확인하세요. 구형 시스템에서는 ‘Apple ID’로 표시될 수 있습니다.
Finder의 ‘iCloud Drive’에 Clash-Shared 폴더를 만들고 UTF-8 인코딩의 shared.yaml을 저장하세요. 서식 있는 텍스트 형식이 추가되는 편집 방식은 피하세요.
iPhone과 iPad에서 ‘설정’ → ‘Apple 계정’ → ‘iCloud’ → ‘iCloud Drive’를 열고 ‘이 iPhone 동기화’ 또는 ‘이 iPad 동기화’를 켜세요.
‘파일’ 앱에서 ‘둘러보기’ → ‘iCloud Drive’ → Clash-Shared로 이동하세요. 파일 이름이 보이는 것만 확인하지 말고 실제 다운로드가 끝날 때까지 기다리세요.
클라이언트의 로컬 파일 가져오기 기능으로 해당 YAML을 선택하세요. 가져온 뒤 이름, 파싱 결과, 활성화 상태를 확인합니다. 원본을 다시 수정했다면 같은 절차로 다시 가져오거나 새로 고침하세요.

위 경로는 최근 운영체제에서 일반적으로 쓰이는 메뉴 이름을 기준으로 안내합니다. 시스템 버전에 따라 메뉴 위치가 달라질 수 있습니다. ‘파일’ 앱에서 iCloud Drive가 보이지 않으면 계정과 Drive 설정을 먼저 확인하세요. 클라우드 동기화 문제를 해결하려고 설정을 계속 새로 만들지는 마세요.

수정 표시를 남겨 새 파일을 받았는지 확인하세요

지원되는 클라이언트에서 원문을 확인할 수 있도록 YAML 맨 위에 주석 한 줄을 남겨 두면 편리합니다. 이 주석은 사람이 파일을 식별하기 위한 것으로 규칙 동작을 바꾸지 않으며 클라이언트 목록에 표시된다고 보장할 수도 없습니다.

# config-revision: 2026-09-09-r1

Mac에서만 주 파일을 편집하고 iPhone과 iPad에서는 가져오기만 하도록 정해 두면 동시에 수정해 생기는 충돌 사본을 줄일 수 있습니다.
예를 들어 shared-2026-09-08.yaml처럼 이전에 정상 작동한 파일을 보관하세요. 세 기기에서 문제가 없는 것을 확인한 뒤 오래된 사본을 정리합니다.
앱이 iCloud Drive 파일에 계속 접근할 수 없다면 시스템 파일 선택기에서 다시 권한을 부여하거나 파일을 다시 가져오세요. 이전 접근 권한이 영구적으로 유지된다고 가정하지 마세요.

방법 3: 비공개 Git 저장소로 규칙 변경과 롤백 관리

분기 규칙을 자주 바꾼다면 Git의 장점은 변경 사항을 기록하고 차이를 검토해 이전 버전으로 되돌릴 수 있다는 데 있습니다. iOS에서 Git을 자동으로 실행하는 용도가 아닙니다. 더 안정적인 방식은 공개해도 되는 규칙과 템플릿만 저장소에 보관하고, Mac에서 가져와 최종 설정을 생성한 다음 원격 주소나 파일 가져오기로 휴대폰과 태블릿에 전달하는 것입니다.

규칙과 인증 정보는 따로 보관하세요

사용자 지정 규칙은 rules.yaml에 두고 실제 구독 주소와 로컬 생성 파일은 커밋하지 않는 디렉터리에 보관하는 것이 좋습니다. 아래는 사용할 수 있는 .gitignore 내용입니다. 파일 이름은 실제 생성 절차에 맞추세요.

secrets/
runtime/
*.local.yaml
.DS_Store

.gitignore는 아직 추적되지 않는 파일에만 적용되며 커밋 기록에 이미 포함된 인증 정보는 삭제하지 않습니다. 토큰을 커밋한 적이 있다면 먼저 서버에서 폐기하거나 교체한 뒤 저장소 기록을 정리하세요. 비공개 저장소로 접근을 제한할 수는 있지만, 오래 사용할 구독 인증 정보를 버전 기록에 넣지 않는 것이 안전합니다.

Mac에서 변경 사항을 검토한 뒤 다른 기기에 배포하세요

아래 명령은 저장소가 이미 복제되어 있고 원격 이름이 origin, 공유 브랜치가 main이라고 가정합니다. 먼저 작업 트리 상태를 확인하고 원격 규칙의 변경 사항을 살펴보세요. 완료되지 않은 로컬 수정이 있다면 덮어쓰지 않도록 먼저 저장하고 처리해야 합니다.

git status --short
git fetch origin
git diff HEAD..origin/main -- rules.yaml
git pull --ff-only

업데이트 후 Mac에서 생성된 설정을 확인하고 실제 클라이언트로 로드 테스트를 하세요. mihomo 명령줄 프로그램이 설치되어 있다면 최종 파일을 다음과 같이 검사할 수 있습니다.

mihomo -t -f runtime/shared.yaml

검사가 통과하면 해당 코어의 유효성 검사를 통과했다는 뜻일 뿐, 모든 프록시 노드에 연결할 수 있다는 뜻은 아닙니다. iOS 클라이언트의 호환성 테스트도 별도로 해야 합니다. 그런 다음 설정을 배포하거나 iCloud에 넣어 나머지 기기에서 업데이트하세요. 원격 규칙 세트는 클라이언트가 지원하는 behavior와 파일 형식도 충족해야 합니다. 일반 규칙 조각을 아무 규칙 제공자 파일로 간주할 수는 없습니다.

비공개 Git 저장소의 원본 파일 주소는 인증이 필요하거나 리디렉션, 캐시, 접근 만료가 발생하는 경우가 많습니다. 웹 페이지 주소를 클라이언트에 붙여 넣기만 하면 YAML을 내려받을 수 있다고 가정하지 마세요. 로그인 페이지가 아니라 파일 본문이 반환되는지 확인해야 합니다. 클라이언트에서 안전하게 인증하기 어렵다면 Mac에서 가져와 파일로 배포하는 방식을 유지하는 편이 관리하기 쉽습니다.

Mac·iPhone·iPad에서 로컬로 유지해야 할 설정

동기화 경계를 먼저 정해 두면 ‘Mac은 정상인데 휴대폰은 인터넷에 연결되지 않는’ 문제를 줄일 수 있습니다. 아래는 해당 필드를 지원하는 Clash 계열 코어를 위한 로컬 설정 예시입니다. 노드와 정책 그룹을 포함한 완성 설정이 아니며, 그래픽 인터페이스에서 포트를 관리하는 클라이언트는 최종 적용 설정을 기준으로 해야 합니다.

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

항목	Mac	iPhone / iPad
연결 방식	앱 요구 사항에 따라 시스템 프록시 또는 TUN 선택	보통 클라이언트가 제공하는 VPN 터널로 트래픽 처리
수신 포트	예: 로컬 혼합 포트 7890, 포트 사용 여부 확인	클라이언트 구현에 따라 다르므로 Mac 포트를 그대로 사용하지 않음
로컬 네트워크 접근	프록시 공유가 필요하지 않다면 끄기	여러 기기 동기화의 전제 조건으로 삼지 않기
DNS / TUN	로컬 라우팅, DNS 해석, 다른 VPN과의 충돌 확인	앱에서 지원하는 DNS 및 터널 설정 우선 사용

여기서 포트 7890은 예시일 뿐 모든 클라이언트의 기본값이 아닙니다. Mac에서 시스템 프록시를 켜도 해당 설정을 따르는 앱에만 영향을 줍니다. TUN이 처리하는 범위는 라우팅과 제외 항목에 따라 달라집니다. 설정 동기화만으로 macOS 보조 서비스 권한을 부여하거나 iOS VPN 설정 권한을 대체할 수는 없습니다.

DNS 설정도 무작정 복사해서는 안 됩니다. 가정용 Wi-Fi, 회사 네트워크, 셀룰러 네트워크에서 동일한 DNS 서비스가 다르게 작동할 수 있습니다. 공유 설정에 fake-ip, 분기 DNS, DNS 가로채기 설정이 포함되어 있다면 각 기기의 지원 여부를 확인하세요. 먼저 DNS 해석이 정상인지 확인한 뒤 규칙 적용 여부를 살펴보세요. 그래야 DNS 실패를 구독 오류로 오해하지 않습니다.

동기화 후 규칙이 다를 때 확인할 다섯 가지

출처가 같은지 확인하세요. 세 기기에서 동일한 설정 출처, 형식, 옵션을 사용하는지 살펴보세요. 구독 변환 옵션이 다르면 노드와 규칙도 달라질 수 있습니다.
최신 내용을 받았는지 확인하세요. 마지막 업데이트 성공 시간, 수정 주석, 규칙 수를 살펴보세요. iCloud에 파일이 표시된다고 다운로드가 완료된 것은 아닙니다. 원격 요청에서 HTTP 200을 반환해도 오류 안내문일 수 있습니다.
설정이 로드됐는지 확인하세요. 설정 목록만 보지 말고 현재 활성화된 설정을 확인하세요. 로드에 실패해도 이전 설정을 계속 실행하는 클라이언트가 있으므로 오류 로그를 살펴보세요.
덮어쓰기 순서를 확인하세요. 로컬 덮어쓰기가 mode, DNS, 정책 그룹, 규칙을 바꾸는지 살펴보세요. 일반 규칙은 보통 순서대로 적용되므로 앞에 있는 포괄적 규칙이 뒤의 구체적 규칙보다 먼저 적용될 수 있습니다.
실제 출구를 확인하세요. 연결 기록에서 대상 도메인, 적용된 규칙, 정책 그룹, 최종 노드를 비교하세요. 같은 정책 그룹도 기기별 수동 선택이나 속도 측정 결과가 다를 수 있습니다.

작은 변경 하나로 전체 흐름을 검증하세요

먼저 수정 주석을 바꾸고, 설정에 실제로 존재하는 정책 그룹을 사용해 알고 있는 테스트 도메인의 구체적인 규칙 하나를 수정하세요. 이 규칙은 먼저 적용될 수 있는 포괄적 규칙보다 위에, 기본 처리 규칙인 MATCH보다 앞에 배치합니다. 세 기기에서 업데이트하고 다시 로드한 뒤 새 연결로 테스트하고 적용 기록을 확인하세요. 기존에 오래 유지된 연결은 새 규칙에 따라 다시 연결되지 않을 수 있습니다.

파일 전달이 완료됐는지만 확인하려면 수정 주석을 비교하면 됩니다. 분기 규칙이 적용됐는지 확인하려면 연결 기록을 봐야 합니다. 두 테스트를 따로 진행해야 ‘전송 내용이 업데이트되지 않음’, ‘파싱 실패’, ‘규칙 순서 오류’를 구분할 수 있습니다. 테스트가 끝나면 임시 규칙을 되돌리고 정상 작동한 버전을 유지하세요.

설정을 시작하기 전에 클라이언트 비교에서 플랫폼별 형식과 기능을 확인한 뒤 빠른 시작 가이드에 따라 처음 가져오기를 진행하세요. 연결이나 DNS 해석에 문제가 생겼다면 문제 해결 가이드를 참고해 항목별로 확인하세요. 구독, DNS, 터널 모드를 한꺼번에 바꾸지 않는 것이 좋습니다.