여러 기기에서 Clash 설정 동기화하기: 구독 재사용, 오버라이드 파일과 프라이빗 스토리지

설정에서 동기화할 부분과 기기 전용 부분부터 나누기

여러 기기에서 Clash를 동기화한다고 해서 하나의 완성된 YAML 파일을 모든 단말에 복사해야 하는 것은 아닙니다. 데스크톱과 모바일 운영체제, 클라이언트마다 설정 디렉터리, 네트워크 인터페이스, 시스템 프록시, TUN 권한을 처리하는 방식이 다릅니다. 실행 중인 설정 전체를 그대로 덮어쓰면 노드는 불러와지지만 포트가 충돌하거나 TUN이 시작되지 않고, 모바일 기기에서 데스크톱에만 존재하는 파일 경로를 참조하는 일이 흔히 발생합니다.

더 안정적인 방법은 설정을 세 계층으로 나누는 것입니다. 원격 구독은 노드와 서비스 제공자가 내려주는 정책 정보를 담당하고, 공유 오버라이드는 사용자 지정 규칙, 정책 그룹 이름, 공통 DNS 로직을 담당합니다. 기기 로컬 계층에는 수신 주소, 포트, 컨트롤러, TUN, 네트워크 인터페이스와 클라이언트 상태를 둡니다. 동기화는 앞의 두 계층에만 적용하고, 기기 로컬 계층은 각 클라이언트가 별도로 저장합니다.

방법 1: 모든 기기에서 같은 구독 재사용하기

구독 재사용은 여러 기기에서 설정을 맞추는 가장 간단한 방법입니다. 각 기기에 같은 구독 주소를 저장하면 클라이언트가 정해진 주기에 따라 구독을 가져와 로컬 설정을 생성합니다. 노드 추가·삭제, 이름 변경, 서비스 제공자의 규칙 업데이트는 구독 새로고침과 함께 반영되고, 포트·TUN·시스템 프록시 상태는 각 기기의 로컬 클라이언트가 관리합니다.

기기 수가 많지 않고 노드 목록을 일치시키는 것이 주된 목적이라면 적합합니다. 기기끼리 서로 검색 가능할 필요도, 컴퓨터를 계속 켜 둘 필요도 없습니다. 한 기기에서 업데이트에 실패해도 다른 기기는 각자의 업데이트 주기에 따라 계속 작동합니다.

구독 재사용의 한계

구독 주소에는 계정 식별에 사용되는 매개변수가 포함되는 경우가 많으므로 일반 웹 링크가 아닌 접근 자격 증명으로 취급해야 합니다. 구독 주소를 공개 코드 저장소, 스크린샷, 문의 티켓, 공개 공유 문서에 넣지 마세요. 기기를 양도하거나 분실했거나 더 이상 사용하지 않을 때는 클라이언트에서 구독을 삭제하고, 서비스 제공자가 지원한다면 구독 자격 증명도 갱신해야 합니다.

서비스 약관의 동시 연결 수와 기기 수 제한도 확인해야 합니다. 하나의 구독을 여러 클라이언트에 가져올 수 있다고 해서 서버가 해당 기기들의 대량 동시 연결을 허용한다는 뜻은 아닙니다. 노드는 보이지만 연결이 거부된다면 계정 상태, 동시 연결 한도, 노드 사용 가능성을 함께 점검해야 합니다.

업데이트 주기와 실패 처리

1. 먼저 자주 사용하는 한 기기에서 수동으로 새로고침하고, 구독 응답이 Clash 또는 mihomo에서 해석할 수 있는 설정인지 확인합니다.
2. 그다음 다른 기기는 일정한 주기에 따라 업데이트하도록 설정해 짧은 시간에 요청이 반복되지 않게 합니다.
3. 업데이트 후 정책 그룹에 여전히 구성원이 있는지 확인해 노드 이름 변경으로 직접 작성한 정책 참조가 끊기지 않았는지 점검합니다.
4. 클라이언트에 직전의 정상 설정을 보관해 두세요. 새 설정을 해석하지 못하면 먼저 이전 설정으로 되돌린 다음 응답 내용과 필드 호환성을 확인합니다.

구독 재사용은 ‘노드 출처를 일치시키는’ 방법이지, 직접 추가한 규칙이나 정책 그룹 선택 결과, 기기별 클라이언트 설정까지 자동으로 동기화하는 방법은 아닙니다. 이런 항목까지 통일하려면 구독이 생성한 기본 설정을 반복해서 편집하지 말고 오버라이드 계층을 추가해야 합니다.

방법 2: 오버라이드 파일로 규칙과 정책 구조 통일하기

오버라이드 파일은 사용자가 관리하는 설정 로직을 구독 결과 위에 적용할 때 사용합니다. 오버라이드, 병합 또는 스크립트 처리를 지원하는 클라이언트라면 구독 업데이트 후 규칙을 자동으로 추가하고 정책 그룹을 수정하거나 일부 DNS 필드를 바꿀 수 있습니다. 원격 노드 업데이트는 유지하면서 새로고침할 때마다 생성된 파일을 다시 편집하는 수고를 줄일 수 있습니다.

클라이언트마다 ‘오버라이드’를 정의하는 방식은 다릅니다. YAML 키를 기준으로 병합하는 클라이언트가 있는가 하면 JavaScript로 설정 객체를 처리하거나 단순한 앞단·뒷단 규칙만 제공하는 경우도 있습니다. 적용하기 전에 클라이언트가 실제로 지원하는 처리 순서를 확인하고, 특히 배열이 추가·교체되는지 또는 이름을 기준으로 병합되는지 점검해야 합니다. rules, proxies, proxy-groups는 배열 처리 방식에 따라 최종 결과가 직접 달라집니다.

공유 오버라이드는 작고 명확하게 유지하기

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - DOMAIN-SUFFIX,internal.example,DIRECT
  - MATCH,노드 선택

위 예시는 규칙 순서만 보여 주며 포트, 컨트롤러 또는 TUN은 다루지 않습니다. 실제로 사용할 때는 노드 선택이 최종 설정의 정책 그룹 이름과 정확히 일치해야 합니다. 규칙은 위에서 아래 순서로 매칭되므로 기본 규칙은 마지막에 두어야 합니다. 오버라이드 도구가 규칙 삽입 위치를 잘못 처리하면 새 항목이 영원히 매칭되지 않을 수 있습니다.

실행 상태를 설정 동기화로 착각하지 않기

정책 그룹에서 현재 선택된 노드는 클라이언트가 로컬 데이터베이스나 캐시에 기록할 수 있으며 YAML에 반드시 존재하는 것은 아닙니다. 두 기기가 같은 설정을 불러와도 A 기기에서는 ‘홍콩 노드’를 선택하고 B 기기에서는 ‘자동 선택’을 유지할 수 있습니다. 모바일 네트워크, 가정용 인터넷, 회사 네트워크의 지연 시간이 서로 다르기 때문에 이는 대체로 정상적인 동작입니다. 통일해야 할 것은 정책 그룹 구조이지, 일회성 선택 상태를 억지로 복사하는 것이 아닙니다.

방법 3: 로컬 네트워크로 설정 파일 전송하기

로컬 네트워크 전송은 임시 마이그레이션, 최초 배포, 소수의 관리 대상 기기에 적합합니다. 예를 들어 컴퓨터에서 설정을 정리한 뒤 시스템 파일 공유, AirDrop, USB 케이블 파일 전송, 로컬 파일 서버를 통해 휴대폰이나 태블릿으로 전달할 수 있습니다. 공개 공유 페이지를 거칠 필요가 없고 전송이 끝나면 공유 서비스를 끌 수도 있습니다.

이 방법은 과정이 직관적이고 완성된 YAML, 규칙 세트, 설명 파일을 전달하기 좋다는 장점이 있습니다. 반면 이후 업데이트는 계속 수동으로 해야 합니다. 기기 수가 늘어나면 파일 이름은 같지만 내용이 다르거나, 새 설정이 이전 설정으로 덮어써지거나, 특정 기기만 업데이트에서 빠지는 문제가 쉽게 발생합니다. 따라서 로컬 네트워크 전송은 ‘배포 작업’으로는 적합하지만 장기적인 자동 동기화 방식으로는 적합하지 않습니다.

로컬 네트워크 전송 점검 목록

1. 전송하기 전에 설정 편집기의 자동 저장 충돌 기능을 끄고 파일 내용이 완전히 기록되었는지 확인합니다.
2. 파일 이름이나 같은 디렉터리의 설명에 날짜와 버전을 기록해 여러 버전을 config.yaml만으로 구분하지 않도록 합니다.
3. 가져온 후 먼저 설정 구문을 검사하고 시스템 프록시나 TUN을 시작합니다.
4. 수신 기기에 송신 측의 로컬 네트워크 수신 주소, 컨트롤러 주소, 플랫폼 전용 경로가 그대로 적용되지 않았는지 확인합니다.
5. 전송이 끝나면 임시 공유 디렉터리를 닫고 수신 기기의 다운로드 디렉터리에 있는 중복 사본을 삭제합니다.

HTTP로 로컬 네트워크에서 파일을 제공한다면 신뢰할 수 있는 네트워크에서만 접근 가능한 주소에 바인딩하고 공유 시간을 제한해야 합니다. 공용 무선 네트워크에서는 다른 단말도 같은 네트워크 대역에 있을 수 있으므로 ‘로컬 네트워크에서만’ 제공한다고 해서 접근 범위가 자동으로 통제되는 것은 아닙니다.

방법 4: 프라이빗 스토리지로 공유 설정 관리하기

규칙과 오버라이드 파일을 지속적으로 관리해야 한다면 공유 계층을 직접 관리하는 Git 저장소, WebDAV, 가정용 스토리지 장치, 접근 제어가 적용된 객체 스토리지에 둘 수 있습니다. 각 기기는 클라이언트가 지원하는 원격 설정 기능, 파일 동기화 도구, 수동 다운로드를 통해 최신 버전을 가져옵니다. 기기가 많고 설정 변경 이력이 명확하게 관리되어야 하는 경우에 더 적합한 방식입니다.

프라이빗 스토리지의 핵심은 단순히 파일을 원격에 두는 것이 아니라 접근 자격 증명, 버전 롤백, 충돌 처리 방식을 정하는 데 있습니다. 동기화 도구가 파일이 완전히 기록되기 전에 클라이언트 새로고침을 실행하면 일시적인 구문 오류가 발생할 수 있습니다. 보다 안전한 흐름은 먼저 임시 파일로 다운로드하고 구문 검사를 마친 뒤 정식 설정으로 교체하는 것입니다. 클라이언트 내장 원격 구독을 사용한다면 다운로드와 전환은 클라이언트에 맡기고, 다른 동기화 도구가 같은 파일을 동시에 수정하지 않도록 해야 합니다.

민감한 정보와 공유 로직 분리하기

공유 저장소에는 규칙, 정책 그룹 템플릿, 공개 규칙 세트 참조를 보관하는 것이 적합합니다. 구독 자격 증명, 컨트롤러 비밀번호, 비공개 노드 인증 정보는 더 엄격한 권한이 적용된 위치에 두거나 각 기기에 별도로 입력해야 합니다. 저장 서비스에 로그인이 필요하더라도 최소 권한 원칙에 따라 계정의 접근 범위를 제한하고, 여러 가족 구성원이나 기기가 관리 권한을 공유하지 않도록 하세요.

클라이언트가 변수 치환이나 외부 키 파일을 지원하지 않는다면 자동화를 위해 모든 정보를 장기간 동기화되는 하나의 YAML에 합치지 마세요. 기기 자격 증명이 없는 기본 템플릿을 보관한 뒤 단말에 가져온 후 로컬 필드를 추가할 수 있습니다. 한 단계가 더 필요하지만 장애 범위가 명확하고 기기를 더 이상 사용하지 않을 때 접근 권한을 개별적으로 철회하기도 쉽습니다.

Git, WebDAV, 가정용 스토리지 선택하기

권장 작업 흐름: 구독, 공유 계층, 로컬 계층을 분리해 관리하기

대부분의 개인 사용자에게 균형 잡힌 구조는 다음과 같습니다. 각 기기에 구독 주소를 별도로 저장하고, 규칙과 정책 템플릿은 통제된 위치에 보관하며, 포트·TUN·컨트롤러·시스템 프록시 설정은 로컬에 둡니다. 이렇게 하면 노드 목록은 구독으로 업데이트되고 공유 규칙은 하나의 출처에서만 관리되며 플랫폼 차이가 원격 파일에 의해 반복해서 덮어써지지 않습니다.

1. 기준 기기 설정: 먼저 데스크톱 기기 하나를 선택해 구독, 규칙 순서, DNS 해석, 정책 그룹 참조를 검증하고 현재 코어가 설정을 완전히 불러오는지 확인합니다.
2. 공유 계층 추출: 여러 플랫폼에서 공통으로 사용하는 필드만 남기고 수신 포트, TUN 네트워크 카드, 컨트롤러, 로컬 경로는 공유 파일에서 제외합니다.
3. 소규모 검증: 두 번째 기기에 먼저 가져와 클라이언트의 오버라이드 의미, 배열 병합 방식, 필드 지원 여부를 확인합니다.
4. 설정 버전 기록: 수정할 때마다 정책 그룹 이름 변경이나 규칙 세트 추가처럼 하나의 주제만 처리해 여러 변경 사항이 동시에 모든 기기에 적용되지 않게 합니다.
5. 롤백 경로 유지: 업데이트 전에 불러올 수 있는 이전 설정을 보관합니다. 구문 오류, DNS 이상, 규칙 불일치가 발생하면 먼저 실행 상태를 복구한 다음 변경 내용을 비교합니다.
6. 기기 정기 정리: 더 이상 사용하지 않는 구독, 원격 스토리지 자격 증명, 오래된 설정 사본을 삭제해 사용 중지된 기기가 이후 업데이트를 계속 가져가지 않도록 합니다.

동기화 후 반드시 확인할 항목

• 설정 검사가 통과했는지, 로그에 알 수 없는 필드·중복 정책 이름·규칙 세트 로딩 오류가 없는지 확인합니다.
• 정책 그룹에 유효한 노드가 포함되어 있는지, 직접 작성한 규칙이 참조하는 정책 이름이 여전히 존재하는지 확인합니다.
• DIRECT, 프록시 정책, REJECT가 예상대로 매칭되는지, 모든 요청이 마지막 규칙으로 빠지지 않는지 확인합니다.
• DNS 요청이 예상한 리졸버에서 처리되는지, Fake-IP 또는 Redir-Host 모드가 클라이언트의 지원 범위에 맞는지 확인합니다.
• 데스크톱의 시스템 프록시와 모바일 기기의 VPN 권한이 여전히 로컬 상태에 의해 제어되는지 확인합니다.
• TUN을 시작한 후 라우팅 루프, 로컬 네트워크 접근 중단, 다른 VPN 소프트웨어와의 충돌이 발생하지 않는지 확인합니다.

기기 수와 관리 목적에 따라 방식 선택하기

기기가 두세 대뿐이고 주로 노드 일치를 원한다면 구독 재사용을 우선 적용하세요. 트래픽 분기 규칙까지 통일해야 할 때는 작은 오버라이드 파일을 추가하면 됩니다. 데스크톱 설정을 가끔 휴대폰으로 옮기는 경우에는 로컬 네트워크 전송을 사용할 수 있지만 플랫폼별 필드를 수동으로 확인해야 합니다. 기기가 많거나 규칙이 장기적으로 발전하고 변경 사항을 검토해야 한다면 프라이빗 Git 저장소와 접근이 통제된 파일 스토리지가 더 적합합니다.

모든 실행 상태를 동기화해야 하는 단일 방식은 없습니다. Clash와 mihomo 설정 중 일부는 프록시 로직을 설명하고, 나머지는 운영체제의 네트워크 스택과 직접 연결됩니다. 전자는 중앙에서 관리할 수 있지만 후자는 기기별 차이를 존중해야 합니다. 모든 단말을 덮는 하나의 파일을 찾기보다 동기화 범위를 명확히 나누는 편이 더 안정적입니다.

최종 구조는 다음 네 가지로 요약할 수 있습니다. 구독은 노드 출처를, 오버라이드는 공통 규칙을, 프라이빗 스토리지는 버전과 배포를, 로컬 설정은 시스템 인터페이스를 담당합니다. 이 네 항목을 기준으로 차례로 점검하면 문제가 원격 업데이트, 병합 과정, 파일 전송, 기기 권한 중 어디에서 발생했는지 빠르게 판단할 수 있어 여러 개의 완성된 설정 사본을 반복해서 대조할 필요가 없습니다.