PC와 스마트폰에서 Clash 설정 동기화하기: 구독 호스팅·비공개 Git 저장소·WebDAV 비교

1. 공통 설정과 기기별 설정 나누기

PC와 스마트폰에서 Clash 설정을 함께 사용할 때는 노드 소스, 프록시 그룹 이름, 라우팅 규칙을 공유하는 것이 좋습니다. 클라이언트 데이터 디렉터리 전체를 공유하는 것은 적절하지 않습니다. Clash Meta에서 사용하는 mihomo 코어는 설정을 읽고 연결을 처리하며, 클라이언트는 구독 업데이트, 시스템 프록시, VPN 권한, 설정 오버라이드를 별도로 관리합니다. 이 두 계층의 설정을 혼동하지 마세요.

예를 들어 Windows에서는 시스템 프록시를 127.0.0.1:7890으로 설정할 수 있지만, Android는 일반적으로 클라이언트가 VPN 인터페이스를 만들어 트래픽을 처리합니다. 두 기기에서 같은 rules를 읽더라도 트래픽이 코어로 전달되는 방식은 다릅니다. 동기화가 제대로 됐다는 것은 규칙과 노드 소스가 같고 각 기기의 트래픽 처리 방식이 올바르다는 뜻이지, 모든 스위치가 똑같아야 한다는 뜻은 아닙니다.

공통 설정:proxy-providers, proxy-groups, rule-providers, rules, 두 기기에서 검증한 DNS 정책
기기별 설정:mixed-port, allow-lan, tun, 리슨 주소, 컨트롤러 API 키, 로컬 파일 경로
클라이언트 상태:현재 선택한 노드, 속도 측정 결과, 로그, 캐시, VPN 권한. 기본적으로 설정 동기화 대상에 포함하지 않습니다.

2. 세 가지 동기화 방식의 업데이트 흐름 비교

방식	기기까지 업데이트되는 과정	주요 제약	적합한 상황
구독 링크 호스팅	클라이언트가 HTTP로 정기 또는 수동 요청	서버 콘텐츠와 클라이언트 오버라이드를 따로 관리	노드가 자주 바뀌고 스마트폰은 주로 설정을 불러오는 경우
비공개 Git 저장소	먼저 저장소를 가져온 다음 파일을 가져오거나 다시 불러오기	Git 도구와 별도의 가져오기 과정 필요	규칙 변경이 잦고 검토와 되돌리기가 필요한 경우
WebDAV	동기화 도구가 파일을 내려받은 후 클라이언트에서 가져오기	파일 충돌 해결과 설정 적용은 별개의 작업	비공개 저장소를 이미 사용하며 주로 한 기기에서 편집하는 경우

원격 Git 저장소에 새 커밋이 올라와도 mihomo가 자동으로 가져오지는 않으며 WebDAV를 자동 감시하지도 않습니다. 클라이언트가 해당 연결 방식을 지원하는지 각각 확인하세요. 클라이언트의 WebDAV 백업 기능도 설정과 구성 인덱스만 저장할 수 있으며, 원격 YAML 파일을 실시간 구독하는 기능과는 다를 수 있습니다.

3. 구독 호스팅: 소스는 통일하고 로컬 오버라이드는 유지하기

먼저 구독에서 어떤 형식의 콘텐츠를 제공하는지 확인하기

완전한 Clash 설정에는 proxies, proxy-groups, rules가 포함될 수 있습니다. 노드 목록만 제공되는 경우에는 proxy-providers로 불러와야 할 수 있습니다. 일부 구독은 인코딩된 노드 링크를 반환하는데, 이 형식은 mihomo에서 바로 불러올 수 있는 YAML이 아닙니다. 두 기기에서 같은 설정 형식을 사용해야 하며, 링크의 확장자만 보고 판단하면 안 됩니다.

PC 클라이언트의 설정 관리에서 원격 설정을 추가하고 서비스에서 제공한 실제 구독 URL을 입력한 뒤, 먼저 수동으로 업데이트합니다.
스마트폰에도 같은 링크를 가져와 프록시 그룹 이름과 규칙 수를 확인합니다. 결과가 다르면 구독 형식 옵션을 확인하고, 서비스가 클라이언트 식별 정보에 따라 서로 다른 콘텐츠를 반환하는지 살펴보세요.
기기별 차이는 해당 설정에 연결된 로컬 오버라이드에 넣으세요. 다음 업데이트 때 덮어써질 원격 파일을 직접 수정하지 마세요.
각 기기에서 업데이트 주기를 따로 설정하세요. 클라이언트가 지원한다면 24시간으로 설정할 수 있습니다. 스마트폰은 백그라운드 작업이 시스템 제약을 받으므로 예약 업데이트가 정해진 시각에 실행된다고 보장할 수 없습니다.

최상위 원격 설정의 가져오기 주기는 보통 클라이언트가 관리합니다. proxy-providers 안의 interval: 3600은 해당 제공자의 업데이트 주기가 3600초라는 뜻이며, 전체 구독을 업데이트하는 클라이언트 설정을 대신하지 않습니다. 규칙 제공자에도 별도의 업데이트 주기가 있으므로 각각 확인해야 합니다.

호스팅 및 변환 서비스의 보안 범위

구독 URL을 원격 변환 서비스에 입력하면 서비스 운영자가 구독에 포함된 노드 정보를 읽을 수 있습니다. 직접 운영하는 변환 서비스도 접근 경로, 요청 로그, 캐시를 보호해야 합니다. 두 기기에서 실제로 형식 변환이 필요한 경우에만 이 단계를 추가하세요. 원본 구독이 이미 mihomo 호환 설정을 제공한다면 바로 가져오는 편이 문제를 찾기 쉽습니다.

전체 설정을 직접 호스팅하려면 HTTPS와 접근 제어를 사용하고 로그에 민감한 URL이 남지 않도록 제한하세요. 요청 헤더 인증을 지원하는 클라이언트에서는 전용 인증 정보를 사용할 수 있습니다. URL만 지원하는 클라이언트라면 링크를 안전하게 보관해야 합니다. 링크가 유출되면 토큰을 폐기하거나 교체하세요. 로컬 설정 이름만 바꿔서는 접근 권한을 회수할 수 없습니다.

4. 비공개 Git 저장소: 규칙 버전 관리와 되돌리기 기록

Git은 사용자 지정 도메인 규칙, 프록시 그룹 구조, 기기별 오버라이드를 관리하는 데 적합합니다. 저장소에는 검토 가능한 설정 원본만 두는 것이 좋습니다. 구독 토큰, 노드 비밀번호, 컨트롤러 API 키는 각 기기에서 별도로 관리하세요. 비공개 저장소로 접근 범위를 제한하더라도 커밋 기록, 협업자 권한, CI 로그는 계속 관리해야 합니다.

다음과 같이 디렉터리를 구성할 수 있습니다. base.yaml에는 공통 로직을 저장하고, 두 개의 오버라이드 파일에는 기기별 차이를 담습니다. 디렉터리만 나눈다고 설정이 자동으로 병합되지는 않습니다. 최종적으로 클라이언트의 오버라이드 기능을 사용하거나 직접 빌드 절차를 작성해 유효한 설정을 생성해야 합니다.

clash-config/
├── base.yaml
├── overrides/
│   ├── desktop.yaml
│   └── android.yaml
└── README.md

PC에서 수행하는 기본 업데이트 절차

복제한 저장소 디렉터리에서 다음 명령을 실행하세요. 먼저 작업 트리에 커밋하지 않은 변경 사항이 있는지 확인한 다음, 업데이트 중 의도치 않은 병합 커밋이 생기지 않도록 fast-forward 방식으로만 가져옵니다. 가져오기가 끝나면 프로젝트에서 정한 절차에 따라 실행 설정을 생성하고, 실제로 불러오기 전에 테스트하세요.

git status --short
git pull --ff-only
git log -3 --oneline

mihomo -t -f ./runtime.yaml

runtime.yaml은 이 절차에서 생성하는 완전한 설정 파일이며 Git에서 자동으로 만들어지는 파일이 아닙니다. 테스트 명령을 실행하려면 로컬에 mihomo가 설치되어 있어야 합니다. 로컬 제공자 파일을 참조하는 경우 실제 실행 환경과 같은 작업 디렉터리를 사용하고, 필요하면 -d로 지정하세요. 테스트 통과는 설정을 검사할 수 있다는 뜻일 뿐, 모든 노드에 연결할 수 있다는 의미는 아닙니다.

스마트폰에서는 신뢰할 수 있는 Git 도구로 저장소를 가져온 다음, 클라이언트의 로컬 파일 가져오기 기능으로 업데이트할 수 있습니다. 일반 저장소 웹페이지 URL을 구독 주소로 사용하지 마세요. 비공개 저장소에서 원본 파일을 다운로드하려면 보통 인증이 필요하며, 클라이언트가 해당 인증 방식을 지원하지 않을 수도 있습니다.

설정이 손상됐을 때 되돌리는 방법

현재 실행 중인 설정을 먼저 보관한 다음 가장 최근 규칙 변경 사항을 비교하세요. 공유된 커밋은 모든 기기가 의존하는 기록을 강제로 다시 쓰는 대신 git revert로 되돌림 커밋을 만들 수 있습니다. 민감한 구독 정보가 이미 기록에 포함됐다면 최신 버전에서 해당 줄만 삭제해도 유출을 막을 수 없습니다. 먼저 인증 정보를 교체한 뒤 저장소 기록과 복제본을 정리하세요.

5. WebDAV: 파일 전송과 설정 불러오기를 분리하기

WebDAV는 NAS나 비공개 저장 공간을 이미 사용하는 환경에 적합합니다. 한 기기에서 쓰고 다른 기기에서는 읽는 방식을 권장합니다. 두 기기에서 동시에 config.yaml을 편집하면 나중에 업로드한 파일이 먼저 올린 파일을 덮어쓰거나 동기화 도구가 충돌 파일을 만들 수 있습니다. Clash 클라이언트는 이런 파일을 병합해 주지 않습니다.

저장소 서비스에 설정 전용 디렉터리를 만들고 스마트폰에는 읽기 전용 인증 정보를 부여하세요. 구체적인 권한 설정은 서버가 지원하는 기능에 따라 달라집니다.
PC에서 배포할 설정을 config-2026-09-08.yaml처럼 버전별 파일로 업로드한 다음, 정해 둔 배포 파일을 업데이트합니다.
스마트폰에서는 먼저 파일을 로컬에 다운로드한 뒤 클라이언트의 파일 가져오기 기능으로 불러옵니다. 클라이언트가 WebDAV 설정을 기본 지원한다면 설정 본문까지 실제로 업데이트되는지 먼저 확인하세요.
이전의 정상 작동 파일을 보관하세요. 가져오기에 실패하면 이전 파일을 복원하고, 유일한 사본을 반복해서 덮어쓰지 마세요.

WebDAV 계정 비밀번호를 URL에 직접 붙이지 마세요. 일반적인 '원격 구독' 입력란이 WebDAV 인증을 지원하지 않을 수 있습니다. HTTP 401 오류가 발생하면 인증 정보와 클라이언트 지원 여부를 확인하세요. TLS 검증을 끄는 방식으로 우회해서는 안 됩니다. 인증서 오류는 인증서 체인, 도메인 일치 여부, 기기 시간을 점검해 해결하세요.

6. 기기별 오버라이드: 포트, TUN, 규칙 목록

데스크톱 오버라이드 예시

아래는 오버라이드 병합을 지원하는 클라이언트에서 사용하는 기기별 설정 조각이며, 단독으로 가져올 수 있는 완전한 구독 설정이 아닙니다. 데스크톱에서는 시스템 프록시 연결을 유지하고 TUN을 끄세요. 처음 동기화할 때 두 가지 트래픽 처리 방식을 동시에 바꾸지 않도록 하기 위해서입니다. 클라이언트에 'LAN 허용'이나 포트 설정 화면이 있다면 저장 후에도 해당 값이 덮어써지지 않았는지 확인하세요.

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

시스템 프록시의 HTTP 프록시 주소는 127.0.0.1, 포트는 7890이어야 합니다. 다른 프로그램이 해당 포트를 사용 중이면 7891로 바꾸고 시스템 프록시와 앱 내부의 수동 프록시 설정도 함께 업데이트하세요. YAML만 수정하고 시스템 프록시 포트를 그대로 두지 마세요.

Android 오버라이드 예시

스마트폰에서는 두 환경이 공통으로 지원하는 기본 항목만 오버라이드하고, VPN 연결은 클라이언트가 처리하도록 할 수 있습니다. Android 클라이언트마다 TUN 파일 디스크립터를 만들고 전달하는 방식이 다르므로 데스크톱의 tun.auto-route, 인터페이스 이름, 경로 제외 설정을 그대로 가져오지 않는 것이 좋습니다.

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

Android의 VPN 연결 권한을 승인하고 클라이언트의 앱별 프록시 목록을 확인하세요. 원격 규칙이 같더라도 VPN에서 제외된 앱은 mihomo의 규칙 매칭 과정을 거치지 않습니다. 각 기기의 로컬 포트가 모두 7890이어도 서로 다른 기기이므로 충돌하지 않습니다.

규칙 오버라이드가 자동으로 추가된다고 가정하지 않기

YAML의 맵 항목과 목록 항목을 어떻게 병합하는지는 클라이언트 구현에 따라 다릅니다. 아래는 rules 전체를 교체하는 최소 예시이며, 최종 설정에 '노드 선택'이라는 프록시 그룹이 있어야 합니다. 규칙 한 줄만 앞에 추가하려면 클라이언트가 명시적으로 제공하는 규칙 우선 삽입 기능을 사용하세요. 목록이 자동으로 이어 붙는다고 가정하면 안 됩니다.

rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - MATCH,노드 선택

규칙은 순서대로 적용되므로 MATCH는 마지막에 배치해야 합니다. 위 설정 조각은 LAN 직접 연결과 기본 처리만 보여 주며, 원래 구독에 있던 다른 라우팅 규칙은 포함하지 않습니다. 그대로 교체하면 기존 규칙이 사라집니다. 도메인 매칭만으로 home.arpa를 해석할 수는 없으므로, 내부 도메인은 연결 가능한 로컬 DNS에서 해석해야 합니다. 두 기기의 네트워크 환경은 다를 수 있으니 DNS 업스트림과 내부 DNS 주소는 기기별 설정으로 관리하세요.

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

한 기기에서 먼저 검증한 다음 다른 기기를 업데이트하세요. 구독 업데이트, DNS 교체, TUN 활성화, 규칙 순서 변경을 한꺼번에 하지 마세요. 연결이 실패했을 때 원인을 찾기 어려워집니다. 다음 항목은 임의의 속도 측정 결과에 의존하지 않으며 클라이언트 화면과 로그에서 확인할 수 있습니다.

소스 일치:두 기기가 같은 구독 또는 같은 Git 커밋을 사용하는지 확인합니다. WebDAV를 사용한다면 다운로드한 파일 이름과 수정 시간을 확인하세요.
병합 확인:구독 원문만 보지 말고 최종 실행 설정을 확인하세요. 포트가 7890이고 모드가 rule인지, 오버라이드로 프록시 그룹이 잘못 삭제되지 않았는지 점검합니다.
규칙 적용 확인:규칙을 지정한 도메인에 접속한 뒤 연결 기록에서 적용된 규칙과 최종 정책을 확인하세요. 외부 IP만 비교해서는 안 됩니다.
로컬 네트워크 확인:실제로 존재하는 라우터 관리 주소나 내부 서비스를 열어 LAN 규칙과 DNS가 작동하는지 확인하세요.
업데이트 반복 확인:구독을 한 번 더 수동 업데이트하고 기기별 오버라이드가 유지되는지, 규칙 순서가 바뀌지 않았는지 확인하세요.

PC에서는 되는데 스마트폰에서는 안 될 때 확인할 항목

먼저 Android VPN이 실행 중인지, 대상 앱이 VPN에서 제외되지 않았는지 확인한 뒤 설정 로드 오류를 살펴보세요. '정책이 없습니다'라는 오류가 나오면 규칙에서 참조하는 프록시 그룹 이름을 확인하세요. 로컬 파일을 읽지 못한다면 공통 설정에 PC 전용 경로가 들어 있지 않은지 살펴보세요. 두 기기의 코어 지원 범위가 다르다면 각 클라이언트와 코어 버전을 기록하고, 클라이언트 이름만으로 호환 여부를 판단하지 말고 오류가 난 항목을 기준으로 점검하세요.

최종 동기화 방식 선택하기

서비스 업데이트에 맞춰 노드만 갱신하면 된다면 같은 구독을 사용하고 로컬 오버라이드를 적용하세요. 규칙을 자주 수정하고 변경 사항을 검토해야 한다면 비공개 Git으로 공통 설정 원본을 관리하세요. 비공개 저장소가 이미 있고 주로 PC에서 편집한다면 WebDAV를 파일 배포에 사용할 수 있습니다. 세 방식을 조합할 수도 있습니다. 예를 들어 Git으로 규칙을 관리하고 구독으로 노드를 제공하며 권한과 포트는 기기별로 설정하는 방식입니다. 다만 각 계층의 업데이트 책임을 명확히 정해 여러 경로가 서로 덮어쓰지 않도록 하세요.