PC·스마트폰 설정 동기화: Clash 구독 링크·WebDAV·비공개 Git 비교
Clash 설정을 여러 기기에서 동기화하는 구독 링크, WebDAV 백업, 비공개 Git 방식을 비교하고 업데이트 시점과 충돌 해결법, 적합한 사용 사례를 안내합니다.
1. 공유 설정, 노드 구독, 클라이언트 설정 구분하기
PC와 스마트폰에서 같은 구독 주소를 사용한다고 해서 두 기기의 모든 설정이 동기화되는 것은 아닙니다. Mihomo는 프록시 연결, 규칙, DNS를 처리하는 코어이고, 클라이언트는 설정 가져오기와 예약 업데이트, 화면 옵션 저장, 시스템 권한 요청을 담당합니다. WebDAV 백업과 Git 가져오기는 보통 클라이언트나 외부 도구의 기능이며, Mihomo 코어가 자동으로 동기화하는 절차는 아닙니다.
작업을 시작하기 전에 구독에서 어떤 내용이 제공되는지 확인하세요. 전체 설정에는 보통 proxies 또는 proxy-providers, proxy-groups, rules 등의 항목이 포함됩니다. 노드 정보만 있는 구독은 클라이언트에서 변환하거나 별도의 기본 설정에서 참조해야 합니다. 노드 목록을 전체 설정으로 가져오면 노드는 표시되지만 기대한 프록시 그룹과 규칙이 없는 상황이 생길 수 있습니다.
- 공유하기 적합: 프록시 그룹 이름, 트래픽 분기 규칙, 규칙 세트 참조, 호환성을 확인한 노드 공급원.
- 기기별로 저장하기 적합: 시스템 프록시 설정, TUN 권한, Android 앱별 프록시 목록, 클라이언트 창 및 시작 설정.
- 별도 검토 필요: DNS 수신 주소, 인바운드 포트, 네트워크 인터페이스 이름, 외부 컨트롤 인터페이스, 로컬 파일 경로.
2. 세 가지 방식의 업데이트 방법과 적합한 상황
| 방식 | 동기화 대상 | 업데이트 시점 | 충돌 처리 | 적합한 상황 |
|---|---|---|---|---|
| 구독 링크 | 서버에서 제공하는 노드 또는 설정 | 클라이언트에서 수동 또는 예약으로 가져오기 | 원격 내용을 다시 가져오며 로컬 수정 사항이 덮어써질 수 있음 | 여러 기기에서 같은 게시 콘텐츠를 사용하는 경우 |
| WebDAV | 클라이언트에서 지원하는 백업 패키지 또는 파일 | 백업 및 복원. 자동화 지원 여부는 클라이언트에 따라 다름 | 사본을 보관한 뒤 복원할 백업 선택 | 기기 교체, 재설치, 같은 계열 클라이언트로 이전 |
| 비공개 Git | 텍스트 설정, 규칙, 수정 이력 | 커밋·푸시·가져오기 후 적용 | 줄 단위로 비교한 뒤 수동 병합 | 규칙을 직접 관리하거나 여러 기기에서 협업하고 변경 사항을 되돌려야 하는 경우 |
세 가지 방식을 함께 사용할 수 있지만, 세 도구가 같은 적용 파일을 동시에 수정하게 해서는 안 됩니다. 예를 들어 Git에는 규칙 원본을 보관하고, 구독 주소로 생성 결과를 배포하며, WebDAV에는 클라이언트의 로컬 설정을 백업할 수 있습니다. 데이터 유형마다 수정 주체를 하나로 정하면 덮어쓰기 문제도 쉽게 추적할 수 있습니다.
3. 구독 링크: 같은 출처에서 각 기기별로 업데이트
가져온 뒤에는 업데이트 시각보다 설정 내용을 먼저 확인하세요
- 제공업체 관리 화면에서 Clash 또는 Mihomo용 구독 주소를 확인하고, 요금제가 여러 기기 사용과 동시 접속을 허용하는지 확인하세요.
- PC와 스마트폰의 설정 관리 화면에서 원격 주소를 각각 가져오세요. 클라이언트마다 메뉴 이름은 다를 수 있으므로 ‘URL에서 가져오기’ 또는 이에 해당하는 원격 설정 메뉴를 선택하면 됩니다.
- 한 번 수동으로 업데이트한 뒤 프록시 그룹 이름, 규칙 수, 현재 활성화된 설정을 확인하세요. 다운로드가 완료되었다고 해서 해당 설정으로 전환된 것은 아닙니다.
- 두 기기에서 각각 시스템 프록시를 설정하거나 VPN 권한을 허용한 뒤 웹 요청을 보내고, 연결 기록에서 적용된 규칙과 출구를 확인하세요.
먼저 클라이언트의 전체 설정 업데이트 간격을 24시간으로 설정할 수 있습니다. 이는 시작할 때 참고할 값이지 코어의 고정 기본값은 아닙니다. 제공업체에 별도 업데이트 제한이 있다면 해당 기준을 따르세요. Android의 백그라운드 예약과 배터리 절약 설정, PC 절전 모드로 업데이트가 늦어질 수 있으므로 노드 변경 후에는 수동으로 새로고침하고 결과를 확인하세요.
전체 설정 업데이트와 provider 업데이트는 별개의 타이머입니다
클라이언트의 예약 구독 다운로드는 보통 전체 설정을 교체하거나 다시 가져오는 작업입니다. Mihomo에서 HTTP 유형 proxy-providers의 interval은 해당 노드 공급원의 업데이트 주기를 제어하며, 단위는 초입니다. 예를 들어 interval: 3600은 1시간을 뜻합니다. HTTP 유형 규칙 세트의 업데이트 주기도 해당 rule-providers 항목에서 설정해야 합니다. 이 값을 변경해도 클라이언트의 전체 설정 업데이트 일정은 바뀌지 않습니다.
사용자 지정 규칙을 유지하려면 클라이언트가 공식 지원하는 덮어쓰기 또는 병합 기능을 사용하세요. 다운로드한 YAML에 규칙 한 줄을 추가했다고 해서 계속 유지되는 것은 아닙니다. 다음 구독 업데이트 때 파일이 덮어써질 수 있습니다. 병합 후에는 규칙 순서도 확인하세요. 특히 MATCH 기본 규칙이 뒤따르는 요청을 먼저 가로채지 않도록 주의해야 합니다.
4. WebDAV: 양방향 동기화보다 백업과 복원에 적합
WebDAV는 원격 파일에 접근하는 기능을 제공하지만 ‘백업 업로드’, ‘다운로드 후 복원’, ‘지속적인 양방향 동기화’는 서로 다른 작업입니다. WebDAV를 지원하는 클라이언트라도 자체 데이터베이스만 백업할 수 있으며, 그 백업을 다른 클라이언트에 바로 가져오지 못할 수도 있습니다. 이전하기 전에 두 클라이언트가 같은 백업 형식을 지원하는지, 백업에 구독 주소와 민감한 인증 정보가 포함되는지 확인하세요.
복원까지 고려한 백업 절차 만들기
- 저장소에 전용 폴더를 만들고, 동기화 도구에는 해당 폴더에만 접근할 수 있는 계정이나 앱 비밀번호를 할당하세요.
- HTTPS 주소로 연결하세요. HTTPS는 보통 TCP 443 포트를 사용합니다. 서비스에서 다른 포트를 지정했다면 서버의 실제 주소를 사용하세요.
- 먼저 PC에서 백업을 업로드한 뒤 스마트폰에서 직접 다운로드하거나 복원하세요. 복원하기 전에 스마트폰의 현재 설정을 저장해 두고, 유일한 사용 가능 사본을 바로 덮어쓰지 마세요.
- 복원 후 구독, 프록시 그룹, 로컬 권한을 확인하세요. VPN 권한과 시스템 프록시 상태는 대상 기기에서 별도로 점검해야 합니다.
외부 파일 도구로 YAML을 동기화한다면 원격 파일을 임시 디렉터리에 다운로드하고 검증한 뒤 클라이언트로 가져오세요. 동기화 도구가 클라이언트에서 사용 중인 파일을 계속 덮어쓰게 하지 않는 편이 안전합니다. 전송 도중 연결이 끊기거나 파일 충돌이 발생해도 현재 사용 중인 설정이 즉시 교체되지 않습니다.
두 기기에서 모두 수정한 경우의 선택 방법
예를 들어 PC에서 09:00에 규칙을 수정하고, 오프라인 상태였던 스마트폰에서 09:10에 구독을 수정한 뒤 두 기기에서 같은 이름의 백업을 업로드했다고 가정해 보겠습니다. 수정 시간이 더 최근이라는 이유만으로 최신 백업에 다른 기기의 변경 사항까지 포함됐다고 볼 수는 없습니다. 기기 시간이 서로 다를 수도 있습니다. 먼저 두 사본을 각각 보관한 다음 구독과 규칙을 비교해 기준 버전 하나를 정하세요.
바이너리 또는 암호화된 백업 패키지는 텍스트처럼 줄 단위로 병합할 수 없습니다. 한 기기에서 백업을 게시하고 다른 기기에서는 주로 복원하도록 역할을 나누는 것이 안전합니다. 백업에 인증 정보가 포함된다면 클라이언트의 암호화 기능을 사용하세요. HTTPS로 전송하더라도 서버에 저장된 파일까지 암호화되는 것은 아닙니다.
5. 비공개 Git: 규칙 변경을 추적하고 인증 정보는 따로 관리
도메인 규칙을 자주 조정하거나 변경 내용을 검토하고 이전 버전으로 되돌려야 한다면 Git이 적합합니다. 텍스트 변경 이력이 남아 각 규칙을 누가, 언제, 왜 수정했는지 확인할 수 있습니다. 다만 비공개 저장소에도 계정, 협업자, 자동화 도구의 접근 권한이 있으므로 노드 비밀번호, 구독 토큰, 컨트롤 인터페이스 키를 그대로 커밋해서는 안 됩니다.
파일을 구분한 뒤 동기화 연결하기
아래는 원본 파일을 구성하는 한 가지 방법이며, Mihomo가 자동으로 인식하는 디렉터리 규칙은 아닙니다. Mihomo는 최종적으로 완전하고 유효한 설정 파일을 불러와야 합니다. 파일을 나눴다면 명확한 조립 절차를 거쳐야 하며, 코어가 자동으로 병합한다고 가정해서는 안 됩니다.
proxy-config/
├── base.yaml
├── rules/
│ └── local.yaml
├── devices/
│ ├── desktop.yaml
│ └── android.yaml
├── .gitignore
└── README.mdbase.yaml에는 공통 구조를, rules/에는 규칙 원본을, devices/에는 비밀 정보가 포함되지 않은 플랫폼별 설정을 보관합니다. 실제 구독 주소와 생성된 설정은 저장소 밖에 둡니다. 아래 제외 규칙은 이 방식에서 정한 파일 이름만 대상으로 하며, 커밋 전 검토를 대신할 수 없습니다.
# .gitignore
secrets/
private-provider.yaml
runtime.yaml
*.log수정할 때마다 같은 절차를 따르세요
- 먼저
git pull --ff-only를 실행해 원격 변경 사항을 가져옵니다. 브랜치가 분기됐다는 메시지가 나오면 차이를 먼저 해결하고, 강제로 덮어쓰지 마세요. - 규칙을 수정한 뒤
git diff로 변경 내용을 확인하고 실제 구독 주소나 노드 비밀번호가 포함되지 않았는지 점검하세요. - 프로젝트 절차에 따라
runtime.yaml을 생성하고 대상 기기에 해당하는 Mihomo 버전으로 설정을 검사하세요. - 검증을 통과하면 원본 파일을 커밋한 뒤 비공개 저장소에 푸시하세요. 다른 기기에서는 변경 사항을 가져와 설정을 다시 생성한 다음 가져오면 됩니다.
mihomo -v
mihomo -t -f runtime.yaml
git diff --check
git add base.yaml rules/local.yaml
git commit -m "로컬 도메인 분기 규칙 수정"
git pushmihomo -t -f runtime.yaml은 설정을 검사하는 명령입니다. 원격 노드에 연결할 수 있는지 또는 TUN 권한이 준비됐는지를 확인해 주지는 않습니다. 설정에서 상대 경로나 외부 규칙 파일을 참조한다면 같은 작업 디렉터리와 종속 파일도 준비해야 합니다. Windows에서는 실제 코어 실행 파일 이름을 사용하세요. 클라이언트에 내장된 코어의 경로는 설치 방식에 따라 다릅니다.
스마트폰에서는 Git 도구나 임의 디렉터리 접근을 지원하지 않을 수 있습니다. 안정적인 가져오기와 배포 절차를 마련하기 어렵다면 PC에서 저장소를 관리하고, 제어된 HTTPS 주소로 결과를 게시해 스마트폰에서 구독하는 방식을 권장합니다. 설정 동기화를 위해 저장소 접근 토큰을 구독 URL에 직접 넣지 마세요.
6. 플랫폼별 포트·TUN·DNS 설정 유지하기
‘설정 하나를 공유한다’는 것은 모든 항목을 똑같이 맞춘다는 뜻보다 규칙 로직을 공유한다는 의미에 가깝습니다. 데스크톱에서는 시스템 프록시를 설정할 수 있지만 Android 클라이언트는 보통 VpnService로 트래픽을 처리합니다. 권한, 라우팅, 앱별 프록시 설정 방식은 서로 다릅니다.
| 항목 또는 기능 | 권장 사항 | 확인할 점 |
|---|---|---|
mixed-port |
기기별 포트 사용 현황에 맞게 설정 | 7890은 흔히 쓰이는 예시이며 모든 클라이언트의 고정 포트는 아닙니다 |
allow-lan |
LAN 접속이 필요하지 않다면 사용하지 않도록 설정 | 사용할 경우 수신 주소, 방화벽, 인증도 확인 |
| TUN 및 VPN | 플랫폼별 권한 및 라우팅 설정 | 데스크톱 TUN 설정으로 Android VPN 권한을 대신할 수 없습니다 |
DNS 및 dns-hijack |
기기의 네트워크 환경에서 테스트 | DNS 요청이 실제로 코어에 전달되는지 확인 |
external-controller |
원격 관리가 필요하지 않다면 외부에 공개하지 마세요 | 로컬 관리에는 루프백 주소를 우선 사용하고 접근 키를 설정하세요 |
기기별 덮어쓰기의 병합 방식도 확인해야 합니다. 일부 클라이언트는 dns 항목 전체를 교체하고, 일부는 맵을 병합하지만 rules 배열은 추가하거나 교체합니다. 덮어쓰기 편집기에 보이는 몇 줄만 확인하지 말고 최종 적용 설정을 확인하세요. Android의 앱별 프록시 설정은 실제 설치된 앱 패키지 이름에 따라 달라지므로 데스크톱 프로세스 규칙을 그대로 재사용하기 어렵습니다.
7. 업데이트 충돌·롤백·적용 여부 확인
업데이트 후 규칙이 사라짐
규칙이 원격 구독, 클라이언트 덮어쓰기, 임시 생성 파일 중 어디에 있는지 먼저 확인한 뒤 이번 업데이트가 어느 계층을 덮어썼는지 살펴보세요. 직접 관리하는 원본 파일에 # profile-revision: 2026-08-23-01과 같은 주석을 추가하는 방법도 있습니다. 이는 배포 버전을 식별하기 위한 표시일 뿐 트래픽 분기에는 영향을 주지 않습니다. 실제로 불러왔는지는 최종 설정과 로그를 함께 확인해야 합니다.
PC에서는 되지만 스마트폰에서 인터넷이 연결되지 않음
현재 설정 이름과 업데이트 시각, 코어 버전, 노드 공급원, 프록시 그룹 선택을 차례로 비교한 뒤 스마트폰의 VPN 권한과 백그라운드 제한을 확인하세요. 같은 구독을 사용해도 두 기기에서 같은 시점에 같은 노드를 이용한다는 보장은 없습니다. 수동 선택 결과와 연결 상태 확인 정보가 기기별로 저장될 수도 있습니다. 먼저 출구를 통일한 뒤 테스트해야 변수를 줄일 수 있습니다.
새 설정을 불러오지 못함
- 오류가 난 파일과 로그를 보관하고 문제가 발생한 항목이나 줄 번호를 기록하세요.
- 검증을 마친 이전 설정으로 되돌려 연결부터 복구하고, 여러 설정을 연달아 변경하지 마세요.
- Git을 사용한다면 최근 커밋을 확인하세요. WebDAV라면 별도로 보관한 이전 백업을 복원하고, 구독 방식이라면 제공업체가 이전 버전을 지원하는지 확인하세요.
- 수정 후 한 기기에서 먼저 테스트하고 나머지 기기에 배포하세요.
최종 점검에는 최소한 세 가지가 포함돼야 합니다. 코어가 설정을 불러오는지, 프록시가 필요한 요청에 예상한 규칙이 적용되는지, 직접 연결해야 할 요청이 잘못 전달되지 않는지 확인하세요. 공유 설정에 DNS 또는 TUN 변경이 포함됐다면 Wi-Fi와 모바일 네트워크에서 각각 이름 확인과 연결을 점검해야 합니다. ‘구독 업데이트 성공’만으로 전체 설정이 정상 작동한다고 판단하지 마세요.
8. 관리 방식에 맞는 동기화 방법 선택
- 서비스 제공업체 구독을 주로 사용하는 경우: 두 기기에 같은 주소를 가져오고 각각 업데이트 주기를 설정하세요. 사용자 지정 규칙은 로컬 덮어쓰기 기능을 사용하고 내보낸 사본을 보관하세요.
- 재설치와 기기 교체가 주된 목적이라면: 클라이언트가 지원하는 WebDAV 백업을 선택하세요. 먼저 복원 형식을 확인한 뒤 자동 백업 사용 여부를 결정하세요.
- 사용자 지정 트래픽 분기 규칙을 주로 관리한다면: 비공개 Git에 텍스트 원본을 보관하고 검증을 거쳐 배포하세요. 스마트폰에는 사용 가능한 결과만 가져오면 됩니다.
장기간 관리할 때는 모든 기기가 실시간으로 서로 덮어쓰도록 하는 것보다 ‘원본 파일의 위치, 수정 담당자, 검증 방법, 되돌리는 방법’을 정해 두는 것이 중요합니다. 공유 규칙은 한곳에서 관리하고 플랫폼별 권한은 기기에서 설정하며, 업데이트 전에 사용 가능한 사본을 보관해야 설정 변경 시 문제 지점을 찾을 수 있습니다. 항목을 더 자세히 확인하려면 규칙 및 설정 문서를 참고하세요. 클라이언트 설치와 권한 설정은 사용 가이드에서 확인할 수 있습니다.