Clash 여러 기기 설정 동기화: 구독 URL·비공개 호스팅·로컬 오버라이드 비교

먼저 동기화 범위 정하기: 노드, 규칙, 기기별 설정

Clash 설정을 여러 기기에서 동기화한다고 해서 클라이언트 폴더 전체를 복사해야 하는 것은 아닙니다. 노드 인증 정보, 라우팅 규칙, 시스템 프록시 상태는 각각 다른 설정입니다. 데스크톱 설정을 그대로 스마트폰에 가져오면 지원하지 않는 필드, 포트 충돌, TUN 실행 실패가 발생할 수 있습니다. 노드 소스와 규칙의 의도는 공유하되, 네트워크 인터페이스와 수신 포트, 시스템 연동 설정은 기기별로 관리하는 편이 안전합니다.

클라이언트와 코어도 구분해야 합니다. mihomo를 사용하는 데스크톱 클라이언트는 같은 코어 필드를 지원할 수 있지만, 설정 병합과 백그라운드 업데이트, 스크립트 실행은 클라이언트가 처리합니다. 다른 코어나 모바일 프록시 앱이 Clash 형식의 일부를 읽을 수 있더라도 mihomo 설정을 모두 사용할 수 있다는 뜻은 아닙니다. 이 문서의 YAML 예시는 mihomo를 기준으로 하므로, 가져오기 전에 대상 코어와 필드 지원 여부를 확인하세요.

설정 항목	권장 범위	이유
노드, 구독 주소	같은 계정의 기기끼리 공유	인증 정보와 트래픽 한도는 보통 서버에서 통합 관리
규칙, 정책 그룹 이름	가능한 한 통일	기기마다 같은 도메인이 서로 다른 아웃바운드로 연결되는 상황 방지
`mixed-port`、`allow-lan`	기기별로 관리	수신 설정과 로컬 네트워크에 공개되는 범위가 다름
`tun`, 컨트롤 인터페이스	기기별로 관리	시스템 권한, 네트워크 스택, 클라이언트 관리 방식에 따라 달라짐

방법 1: 같은 구독 URL을 각 기기에 추가

같은 서비스의 구독을 두세 대의 기기에서 사용한다면 구독 URL을 공유하는 방식이 대체로 관리 부담이 가장 적습니다. 각 클라이언트의 구독 또는 설정 화면에서 같은 주소를 추가한 뒤 직접 업데이트하고 해당 설정을 활성화하세요. 이 방식은 각 기기가 서버에서 설정을 가져오는 것이며, 클라이언트끼리 설정을 직접 전송하는 것은 아닙니다.

설정 업데이트와 연결 상태를 따로 확인

먼저 PC에서 구독을 가져와 노드 목록, 정책 그룹, 규칙이 제대로 작동하는지 확인한 다음 스마트폰과 태블릿에도 추가합니다.
기기별 구독 업데이트 설정을 확인하세요. 클라이언트에서 허용한다면 확인 주기를 24시간으로 설정할 수 있습니다. 이는 관리상 권장값이며 Clash의 공통 기본값은 아닙니다.
서비스 제공자가 노드를 변경할 때마다 각 기기에서 직접 한 번씩 업데이트하고, 현재 활성화된 설정이 해당 구독인지 확인하세요.
연결 화면에서 실제로 적용된 규칙과 아웃바운드를 확인하세요. 설정 파일에 ‘업데이트 성공’이라고 표시되는지만 봐서는 안 됩니다.

구독을 업데이트해도 정책 그룹에서 현재 선택한 노드까지 자동으로 동기화되지는 않습니다. PC에서 특정 지역 노드를 선택해도 스마트폰에는 기존 선택이 남아 있을 수 있습니다. 연결 기록, 시스템 프록시 스위치, TUN 스위치도 대개 기기마다 별도로 저장됩니다. 기기 간 정책을 일치시키려면 설정에서 같은 자동 선택 그룹을 사용할 수 있지만, 네트워크 환경이 달라 각 기기의 측정 지연 시간까지 같아지지는 않습니다.

주요 제한 사항: 업데이트 시점은 클라이언트 스케줄에 좌우됨

시스템이 백그라운드의 모바일 앱을 일시 중지할 수 있습니다. 업데이트 주기를 24시간으로 설정해도 지정된 시각에 반드시 가져온다고 보장할 수는 없습니다. PC가 절전 모드에 있거나 구독 서버에 접속할 수 없는 경우에도 업데이트가 늦어집니다. 기존 노드를 사용 중지할 계획이라면 기기별로 전환 시간을 확보하고, 스마트폰에서는 앱을 열어 직접 한 번 업데이트하세요.

서비스 제공자의 허용 기기 수, 동시 연결 수, 계정 이용 약관도 확인해야 합니다. 구독을 공유한다고 무제한으로 배포해도 되는 것은 아닙니다. 구독 URL에는 접근 토큰이 포함되는 경우가 많아, 주소를 가진 사람이 노드 정보를 가져갈 수 있습니다. 계정 인증 정보와 동일하게 취급하세요.

방법 2: 비공개 YAML 호스팅으로 규칙 중앙 관리

사용자 지정 규칙이 많거나 설정 변경을 검토해야 한다면 비공개 저장소에 설정 원본을 보관하고, 접근이 통제된 HTTPS 주소로 기기에 배포할 수 있습니다. 저장소는 버전 이력을 관리하고 다운로드 주소는 인증을 처리하므로 두 역할을 혼동해서는 안 됩니다. 비공개 저장소의 웹 주소는 보통 로그인 페이지를 반환하므로 YAML 구독 URL로 바로 사용할 수 없습니다.

전체 설정과 독립 규칙 세트의 차이

전체 설정을 호스팅한다면 기기에서 가져왔을 때 프록시, 정책 그룹, 규칙이 모두 포함된 실행 가능한 설정이어야 합니다. 규칙 세트만 호스팅하는 경우에는 기본 설정에서 rule-providers로 불러온 뒤 rules에서 참조해야 합니다. 규칙 세트 파일만으로는 전체 구독 설정을 활성화할 수 없습니다.

아래에서는 로컬 파일로 규칙 세트의 구조를 살펴봅니다. 먼저 코어 작업 디렉터리에 규칙 파일을 rules/shared-direct.yaml 경로로 저장하고 다음 내용을 넣습니다. example.com은 규칙 형식을 확인하기 위한 예약 예시 도메인입니다. 실제 배포 시에는 업무에 사용하는 도메인으로 바꾸세요.

payload:
  - DOMAIN-SUFFIX,example.com

기본 설정에 다음 내용을 추가하고 기존 노드와 정책 그룹은 유지하세요. 예시는 기존 정책 그룹 이름이 ‘노드 선택’이라고 가정합니다. 이름이 다르면 마지막 줄에 실제 설정의 그룹 이름을 입력하세요.

rule-providers:
  shared-direct:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/shared-direct.yaml

rules:
  - RULE-SET,shared-direct,DIRECT
  - MATCH,노드 선택

rules는 위에서 아래로 규칙을 확인하며, 마지막의 MATCH는 기본 규칙입니다. 위 목록은 순서를 설명하기 위한 것으로, 구독에 있는 기존 규칙을 전부 덮어쓰면 안 됩니다. HTTP 규칙 제공자로 바꾸려면 type: http를 사용하고 실제 다운로드 주소, 캐시 경로, interval을 별도로 지정해야 합니다. 예를 들어 interval: 86400은 업데이트 주기가 86400초, 즉 24시간이라는 뜻입니다. 이는 규칙 제공자의 업데이트 주기이며 전체 구독 업데이트 주기가 아닙니다.

접근 권한과 롤백용 사본

대상 클라이언트마다 다운로드 주소에 접속해 YAML이 반환되는지 확인하세요. 로그인 페이지, 리디렉션 페이지, 오류 메시지가 반환되어서는 안 됩니다.
사용자 지정 인증 헤더가 필요하다면 클라이언트와 해당 다운로드 방식이 이를 지원하는지 먼저 확인하세요. 브라우저에서 로그인된 상태라고 해서 클라이언트에서도 접근할 수 있는 것은 아닙니다.
저장소에는 가능하면 규칙과 생성 로직만 보관하세요. 노드 비밀번호, 구독 토큰, 컨트롤 인터페이스 키는 별도로 관리해야 합니다.
배포할 때마다 검증을 마친 이전 버전을 하나 보관하세요. 설정 파싱에 실패하면 로컬 사본으로 되돌릴 수 있습니다.

비공개 저장소에 올렸다고 비밀 정보가 유출되지 않는 것은 아닙니다. 인증 정보가 한 번 커밋되면 파일을 나중에 삭제해도 버전 기록에서는 사라지지 않습니다. 잘못 커밋했다면 기록을 정리하기 전에 먼저 인증 정보를 폐기하거나 교체하세요. 토큰이 포함된 다운로드 주소를 공개 이슈나 스크린샷에 올리지 마세요.

방법 3: 구독 업데이트 후 로컬 오버라이드 적용

노드는 상위 구독을 따르면서 기기별 설정은 유지해야 하는 경우 로컬 오버라이드가 적합합니다. 일반적으로 클라이언트가 구독을 가져온 다음 설정 병합이나 스크립트를 통해 최종 실행 설정을 만듭니다. 다만 ‘오버라이드’는 모든 Clash 클라이언트가 따르는 공통 규격이 아닙니다. 파일 형식, 병합 순서, 스크립트 지원 여부는 사용하는 클라이언트에서 확인해야 합니다.

데스크톱에서는 클라이언트의 설정 병합 또는 오버라이드 기능을 사용해 아래 기기별 설정을 관리할 수 있습니다. 이 예시는 로컬에서만 혼합 프록시 포트를 수신하며, 시스템 프록시를 설정하거나 TUN을 활성화하지 않습니다.

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule

클라이언트가 수신 포트를 통합 관리한다면 설정 화면에서 변경하는 것이 좋습니다. 화면 설정과 오버라이드 파일이 서로 덮어쓰는 상황을 피할 수 있습니다. 스마트폰의 VPN 연결 방식은 데스크톱 시스템 프록시와 다르므로 ‘동기화’를 위해 데스크톱 포트 설정을 그대로 복사할 필요는 없습니다.

목록 병합은 실수가 가장 많이 발생하는 부분

rules, proxies, proxy-groups는 모두 목록입니다. 클라이언트에 따라 목록 전체를 교체할 수도 있고, 앞이나 뒤에 추가하거나 스크립트로 처리할 수도 있습니다. 로컬 규칙 두 개를 추가해도 기존 규칙 수천 개가 그대로 남는다고 가정하지 마세요. 수정 후에는 최종 실행 설정을 확인해 기존 목록이 실수로 지워지지 않았는지 살펴보세요.

사용자 지정 직접 연결 규칙은 실제로 적용될 수 있는 위치에 두세요. 보통 마지막의 MATCH보다 앞에 배치해야 합니다.
새 규칙에서 참조하는 정책 그룹이 실제로 존재해야 하며, 그룹 이름의 공백과 대소문자도 일치해야 합니다.
DNS 설정은 전체적으로 확인해야 합니다. enhanced-mode만 바꾼다고 모든 플랫폼에서 같은 방식으로 DNS가 처리되는 것은 아닙니다.
TUN의 기기 이름, 라우팅 제외 항목, 권한 설정은 로컬에 유지해 다른 운영체제에 그대로 적용하지 않도록 하세요.

세 가지 방식의 업데이트 속도와 관리 비용

방식	적용 조건	주요 관리 항목
공통 구독 URL	각 기기에서 설정을 정상적으로 가져와 활성화	업데이트 주기, 계정 제한, 상위 설정 변경
비공개 YAML 호스팅	게시가 완료되고 클라이언트가 다운로드 주소에 접근 가능	인증, 버전 롤백, 설정 호환성
로컬 오버라이드 병합	구독 업데이트 후 병합 절차가 정상 적용	기기별 병합 방식과 규칙 순서

PC 한 대, 스마트폰 한 대, 태블릿 한 대를 사용한다고 가정해 보겠습니다. 먼저 공통 구독으로 노드를 업데이트하고, PC에는 별도의 로컬 수신 설정을 유지합니다. 공유 규칙을 자주 수정해야 할 때 규칙 세트 호스팅을 추가하세요. 필요한 관리 절차만 늘릴 수 있어 처음부터 설정 생성 서비스를 구축할 필요가 없습니다.

세 기기 모두 앱이 열려 있다면 예약 작업을 기다리는 것보다 직접 업데이트하는 편이 결과를 확인하기 쉽습니다. 다만 이를 근거로 동기화에 걸리는 시간을 초 단위로 보장할 수는 없습니다. 실제 소요 시간에는 게시, 클라이언트 스케줄링, 네트워크 다운로드, 다시 불러오기가 모두 포함됩니다. 설정된 확인 주기만 비교하지 말고 실제 업데이트 시각을 기록하세요.

배포 및 문제 해결: 동일한 연결로 검증하기

첫 배포 전 확인할 다섯 가지

환경 기록. 클라이언트 이름과 버전, 코어 이름과 버전을 각각 기록하세요. 단순히 ‘최신 버전’이라고만 적지 마세요.
기존 설정 저장. 현재 정상 작동하는 설정을 내보내고 정책 그룹의 현재 선택 항목도 기록하세요. 백업 파일은 인증 정보가 포함된 자료처럼 안전하게 보관해야 합니다.
기기별로 업데이트. PC를 먼저 업데이트한 다음 스마트폰을 업데이트하세요. 각 기기의 다운로드 시각과 현재 활성 설정을 확인하고, 모든 기기를 한꺼번에 수정하지 마세요.
실행 설정 확인. mode, 규칙 순서, 참조된 그룹 이름을 확인해 오버라이드가 최종 설정에 반영됐는지 살펴보세요.
실제 연결 테스트. 같은 도메인에 접속해 연결 기록에서 적용된 규칙, 정책 그룹, 최종 노드를 비교한 다음 직접 연결되어야 하는 사이트도 테스트하세요.

같은 설정인데 기기마다 트래픽 분기가 다른 이유는?

먼저 모든 기기가 규칙 모드인지 확인하세요. 전역 모드에서는 같은 규칙 목록으로 트래픽을 분기하지 않습니다. 다음으로 앱 트래픽이 코어를 거치는지 살펴보세요. 데스크톱에서는 브라우저만 시스템 프록시를 사용하고 다른 프로그램은 프록시를 사용하지 않을 수 있으며, 스마트폰에서는 VPN이 트래픽을 처리할 수 있습니다. 그다음 DNS 결과, 규칙 제공자 캐시, 정책 그룹의 현재 선택 항목을 비교하세요.

업데이트에 성공했는데 이전 규칙이 남아 있는 이유는?

‘파일 다운로드 → 현재 활성 항목 → 병합 결과 → 코어 실행 설정’ 순서로 확인하세요. 자주 발생하는 원인은 활성화되지 않은 구독을 업데이트했거나, 마지막 단계에서 로컬 오버라이드가 이전 규칙을 다시 쓴 경우입니다. 전체 구독과 HTTP 규칙 세트는 캐시를 각각 관리할 수도 있으므로 구독 업데이트 후 규칙 제공자 상태도 확인하세요.

문제 해결 기록을 보존하면서 롤백하려면?

오류 내용과 실패한 버전을 먼저 저장한 뒤 이전에 정상 작동한 설정으로 되돌리세요. TUN이나 시스템 프록시를 변경했다면 해당 기기의 스위치도 원래대로 복구해야 합니다. 클라이언트를 종료한 뒤에도 시스템이 작동하지 않는 수신 포트를 가리킬 수 있습니다. 이후에는 한 번에 한 계층씩 수정하세요. 노드 소스를 확인하고, 공유 규칙을 검증한 다음, 마지막으로 로컬 오버라이드를 활성화합니다. 여러 기기 동기화의 목표는 모든 파일을 한 글자까지 똑같이 만드는 것이 아니라 트래픽 분기 정책을 추적하고 기기별 차이를 설명할 수 있게 하는 것입니다.