동기화 범위: 규칙은 공유하고 기기별 설정은 유지

PC와 스마트폰에서 Clash 설정을 공유한다고 해서 실행 중인 YAML 파일을 그대로 복사해 모든 기기에 넣는 것은 아닙니다. 각 기기에서 같은 노드와 라우팅 규칙을 참조하되, 시스템에 종속된 설정은 따로 저장하는 방식이 일반적입니다. 구독은 노드를 제공하고, 설정 파일은 노드와 규칙을 구성하며, 클라이언트는 이를 가져오고 업데이트한 뒤 코어를 실행합니다. 각 계층의 상태가 다르므로 파일을 한 번 복사하는 것만으로 모두 맞출 수는 없습니다.

예를 들어 Windows의 시스템 프록시는 로컬 주소 127.0.0.1:7890을 사용하지만, 스마트폰은 보통 시스템 VPN 인터페이스를 통해 트래픽을 처리합니다. 두 기기에서 같은 이름의 정책 그룹을 쓸 수는 있어도 TUN 매개변수, 네트워크 인터페이스 이름, 파일 경로까지 똑같이 지정할 필요는 없습니다. Android의 앱별 프록시 설정과 데스크톱 시스템의 프로세스 규칙도 서로 바꿔 쓸 수 있는 설정이 아닙니다.

설정 계층 동기화하기 좋은 항목 기기에만 저장할 항목
노드 및 구독 구독 주소, 노드 목록, 업데이트 정책 기기별 자격 증명, 트래픽 또는 연결 수 제한
라우팅 정책 도메인 규칙, 정책 그룹 이름, 규칙 세트 참조 로컬 네트워크 예외, 프로세스 규칙, 앱 제외 목록
실행 환경 각 플랫폼에서 검증된 공통 필드 수신 포트, 컨트롤러 인터페이스, TUN, DNS 처리 방식

방법 1: 모든 기기에서 같은 구독 주소 사용

PC와 스마트폰에서 같은 노드 목록만 사용하면 된다면, 각 기기에 같은 구독 주소를 가져오는 것이 가장 간단합니다. 먼저 서비스 제공업체가 여러 기기에서의 사용을 허용하는지 확인하고, 동시 접속 수와 트래픽 집계 방식, 요금제 제한을 살펴보세요. 설정을 복사할 수 있다고 해서 계정에서 기기 수를 제한 없이 허용하는 것은 아닙니다.

구독이 어떤 형식으로 제공되는지 확인

  • 전체 Clash YAML: 보통 proxies, proxy-groups, rules를 포함합니다. 클라이언트가 지원하는 방식으로 원격 설정을 가져올 수 있습니다.
  • 노드 목록: 노드 프로바이더에 사용하는 형식으로, 최상위 키는 대개 proxies입니다. 전체 설정에 필요한 정책 그룹과 라우팅 규칙까지 자동으로 제공하지는 않습니다.
  • Base64 노드 링크 또는 다른 코어 형식: 가져올 수 있는지는 클라이언트가 파싱이나 변환 기능을 제공하는지에 달려 있습니다. 파일 확장자가 .yaml이라고 해서 내용까지 호환된다는 뜻은 아닙니다.

원격 설정 업데이트와 proxy-providers 업데이트도 구분해야 합니다. 전자는 설정 파일 전체를 교체할 수 있고, 후자는 주로 프로바이더의 노드 목록을 새로 가져옵니다. 노드 프로바이더를 업데이트해도 기본 설정의 rules가 서비스 제공업체의 최신 규칙으로 바뀌지는 않습니다. 전체 설정 주소를 노드 프로바이더 주소로도 쓸 수 있는지는 대상 코어의 실제 파싱 결과로 확인하세요.

업데이트 주기는 실시간 동기화가 아닙니다

지원되는 HTTP 노드 프로바이더에서 interval: 3600은 업데이트 간격이 3,600초, 즉 1시간이라는 뜻입니다. 클라이언트의 원격 설정 자동 업데이트 주기는 별도로 지정해야 하며 이 필드로 대체할 수 없습니다. 스마트폰이 절전 상태이거나 백그라운드 실행이 제한되거나 클라이언트가 꺼져 있으면 예상보다 늦게 갱신될 수 있습니다.

  1. 첫 번째 기기에 구독을 가져온 뒤 노드 수, 정책 그룹 이름, 설정 로드 로그를 확인합니다.
  2. 두 번째 기기에서도 같은 주소를 가져오고 직접 업데이트해 오래된 로컬 사본을 불러온 것은 아닌지 확인합니다.
  3. 예를 들어 업데이트 주기를 1시간으로 통일하고, 두 클라이언트가 해당 주기와 백그라운드 업데이트 방식을 모두 지원하는지 확인합니다.
  4. 서비스 제공업체에서 노드를 바꾼 뒤 각 기기의 업데이트 시각을 따로 확인하세요. PC에서 업데이트됐다고 스마트폰도 업데이트됐다고 판단하면 안 됩니다.

이 방법은 유지 관리가 가장 간단하지만, 라우팅 규칙이 일치하는지는 구독 내용과 로컬 오버라이드에 따라 달라집니다. 예를 들어 스마트폰에서 가져올 때 규칙 세트가 자동으로 추가되고 PC에는 추가되지 않았다면 두 기기의 동작은 달라집니다.

방법 2: 비공개 저장소에 설정과 규칙 보관

직접 관리하는 도메인 예외, 규칙 순서, 여러 기기의 설정이 필요하다면 비공개 Git 저장소를 설정의 버전 관리 원본으로 활용하는 편이 좋습니다. 변경 이력을 확인하고 되돌릴 수 있지만, 클라이언트 간 실시간 동기화 서비스는 아니며 클라이언트가 파일을 내려받을 때 필요한 인증 문제도 해결해 주지 않습니다.

공유 계층과 기기별 계층으로 저장소 구성

clash-config/
├── shared/
│   └── rules.yaml
├── desktop/
│   └── override.yaml
├── mobile/
│   └── override.yaml
└── README.md

위 구성은 파일을 정리하는 한 가지 예일 뿐, Clash가 자동으로 인식하는 디렉터리 규칙은 아닙니다. 폴더 이름을 shared로 지정해도 클라이언트가 내용을 자동 병합하지 않습니다. 규칙 세트는 기본 설정에서 rule-providers로 참조하고 RULE-SET 규칙에 연결해야 합니다. 오버라이드 파일은 클라이언트가 해당 병합 또는 가져오기 방식을 지원해야 합니다.

YAML 형식의 도메인 규칙 세트를 사용한다면 아래 내용을 형식 예제로 참고할 수 있습니다. 여기서 example.com은 문서용 예시 도메인이며, 직접 연결을 권장하는 서비스 주소가 아닙니다.

payload:
  - "+.example.com"

이 형식은 behavior: domain 및 format: yaml로 설정한 규칙 프로바이더에서 사용할 수 있습니다. 기본 설정에는 프로바이더 이름과 가져오기 방식, 규칙이 일치했을 때 적용할 정책도 정의해야 합니다. 규칙 세트 파일에는 접속 지점 선택 정보가 없으므로 전체 rules 목록을 대신할 수 없습니다.

비공개 저장소 인증 정보는 별도로 관리

  • 브라우저에서 열려도 클라이언트가 가져올 수 있는 것은 아닙니다: 브라우저에는 로그인 세션이 있지만, 코어의 요청에는 보통 해당 쿠키가 전달되지 않습니다.
  • 다운로드 링크는 단기간만 유효할 수 있습니다: 임시 인증 매개변수가 포함된 원본 파일 주소는 만료된 뒤 로그인 페이지나 오류 페이지를 반환할 수 있습니다.
  • 인증 지원은 클라이언트마다 다릅니다: 사용자 지정 요청 헤더나 별도 인증 절차가 필요한 주소는 각 클라이언트에서 하나씩 확인해야 합니다.
  • 구독 인증 정보는 커밋 이력에 넣지 마세요: 저장소를 비공개로 설정하면 접근 범위를 줄일 수는 있지만, 이력과 복제본, 백업에 남은 정보가 유출될 위험까지 없애지는 못합니다.

Git에는 구독 토큰이 포함되지 않은 규칙 원본 파일을 저장하는 편이 좋습니다. 비공개 주소는 로컬 설정에서 주입하세요. 합성 설정을 배포해야 한다면 접근 권한을 제한하고, 배포 로그에 전체 내용이 출력되지 않는지 확인합니다. 스마트폰에서 편하게 가져오게 하려고 비공개 설정을 공개 파일로 바꾸지 마세요.

변경 롤백과 배포는 별도로 진행

데스크톱 관리 환경에서는 아래 명령으로 변경 사항을 확인하고 이미 커밋한 잘못된 변경을 되돌릴 수 있습니다. 롤백 커밋을 만든 뒤에도 각 클라이언트가 설정을 다시 가져와 적용해야 합니다. Git 작업이 성공했다고 스마트폰 설정까지 적용된 것은 아닙니다.

git diff -- shared/rules.yaml
git add shared/rules.yaml
git commit -m "공유 도메인 규칙 수정"
git log --oneline -5
git revert HEAD

방법 3: 구독에 로컬 오버라이드 또는 스크립트 추가

구독은 노드 변경을 담당하고 로컬 오버라이드는 개인별 설정을 유지합니다. 여러 기기를 사용하는 환경에서 균형 잡힌 방식입니다. 오버라이드는 업데이트 때마다 덮어써지는 구독 캐시 파일을 직접 수정하지 말고, 클라이언트가 제공하는 별도 계층에 저장해야 합니다.

파일 내용보다 병합 규칙이 중요합니다

클라이언트에 따라 얕은 병합, 깊은 병합, 목록 교체 또는 별도 앞부분 추가 방식이 적용될 수 있습니다. 같은 YAML 조각도 한 클라이언트에서는 규칙이 추가되지만 다른 클라이언트에서는 목록 전체를 교체할 수 있습니다. 아래는 최종 설정에 넣으려는 필드의 예시일 뿐, 모든 클라이언트에서 통용되는 가져오기 형식은 아닙니다:

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

mixed-port는 HTTP와 SOCKS가 함께 사용하는 수신 포트입니다. 서로 다른 두 기기에서 모두 7890을 사용해도 대개 충돌하지 않습니다. 같은 기기에서 동일한 주소와 포트를 사용하는 프로세스 두 개를 실행할 때 포트 바인딩 충돌이 발생할 수 있습니다. 스마트폰 클라이언트에서 사용자가 이 포트를 덮어쓸 수 있는지는 앱 화면과 실제 실행 설정을 기준으로 확인하세요.

규칙 목록은 특히 주의해서 검토해야 합니다. 예를 들어 로컬 도메인 규칙을 기본 규칙 앞에 두려면 단순히 파일 끝에 한 줄을 추가하는 것이 아니라 순서를 조정해야 합니다. MATCH가 나머지 모든 트래픽을 이미 처리한다면 그 뒤에 추가한 규칙은 실행되지 않습니다. 공유 규칙에서 참조하는 정책 그룹 이름이 최종 설정에 존재하는지도 확인하세요.

스크립트는 클라이언트 기능이며 공통 코어 필드가 아닙니다

일부 데스크톱 클라이언트는 JavaScript로 설정 객체를 처리하는 기능을 제공해 구독을 불러온 뒤 설정을 수정할 수 있습니다. 스크립트의 진입 함수와 실행 시점, 사용할 수 있는 API는 클라이언트마다 다릅니다. 이를 모든 Android 또는 iOS 클라이언트에 그대로 복사할 수는 없으며, 과거 Clash 설정에서 제공하던 스크립트 기능과 혼동해서도 안 됩니다.

  1. 스크립트 실행 환경에 대한 의존성을 줄이려면 고정 필드는 정적 오버라이드로 처리합니다.
  2. 노드나 정책 그룹에 따라 내용을 동적으로 생성해야 할 때만 클라이언트 스크립트를 사용합니다.
  3. 스크립트가 대상으로 하는 클라이언트와 적용 버전, 테스트 날짜를 기록하고 클라이언트를 업그레이드한 뒤 출력 결과를 다시 확인합니다.
  4. 스크립트가 저장됐는지만 보지 말고 최종 실행 설정을 확인합니다.

플랫폼별 차이: DNS, TUN, 코어 기능

Clash 설정 생태계에는 다양한 코어와 GUI 클라이언트가 있습니다. mihomo를 사용하는 클라이언트 두 개도 코어 버전, 클라이언트의 설정 생성 방식, 시스템 권한에 따라 다르게 동작할 수 있습니다. 호환성은 실제 코어와 버전을 기준으로 판단해야 합니다. 앱 이름에 Clash가 들어간다고 모든 필드가 공통으로 지원되는 것은 아닙니다.

차이 항목 기기별 설정 방법 확인 위치
TUN 트래픽 처리 기기별로 권한, 라우팅, 제외 항목 설정 시작 로그, 시스템 VPN 상태, 연결 목록
DNS 수신 데스크톱 전용 바인딩 주소와 포트를 복사하지 않기 최종 DNS 설정과 포트 바인딩 로그
프로세스 및 앱 규칙 데스크톱 프로세스 이름과 모바일 앱 선택을 따로 관리 실제 앱 연결에 적용된 규칙
파일 경로 각 클라이언트에서 허용하는 작업 디렉터리 사용 프로바이더 다운로드 결과 및 파일 읽기 오류

DNS의 fake-ip 모드는 가상 주소를 사용해 코어가 연결을 처리하도록 합니다. 기기에서 실행 중에 생성된 DNS 캐시를 동기화할 설정으로 취급해서는 안 됩니다. 스마트폰에서 Wi-Fi와 모바일 네트워크를 전환하면 업스트림 DNS 서버에 연결할 수 있는지도 달라질 수 있습니다. 설정이 같더라도 두 네트워크 환경에서 각각 테스트해야 합니다.

iOS에서 프록시와 유사한 기능을 제공하는 앱이 반드시 mihomo를 사용하거나 전체 Clash YAML을 직접 지원하는 것은 아닙니다. 앱을 고를 때 구독 가져오기 형식과 규칙 의미, 로컬 오버라이드 기능부터 확인한 다음 어떤 원본 파일을 공유할지 결정하세요. 다른 코어용으로 변환한 설정은 프로토콜 매개변수와 규칙 동작도 다시 검토해야 합니다. 노드 이름이 표시되는지만 확인해서는 부족합니다.

업데이트 확인: 두 기기에 같은 버전이 적용됐는지 확인

설정 동기화에는 반복해서 실행할 수 있는 확인 절차가 필요합니다. 아래는 권장 점검 순서이며 특정 클라이언트의 실측 성능 결과가 아닙니다. 메뉴 이름은 클라이언트에 따라 다를 수 있으므로 원격 설정 업데이트, 실행 설정, 연결, 로그에 해당하는 메뉴를 찾아 진행하세요.

  1. 설정 출처 기록: 설정 이름과 구독 업데이트 시각, 공유 규칙의 Git 커밋 축약 번호를 기록합니다. 기록에 전체 구독 토큰을 포함하지 마세요.
  2. 직접 새로고침: 두 기기에서 각각 원격 설정을 업데이트합니다. 프로바이더를 사용한다면 노드 및 규칙 프로바이더의 업데이트 시각도 확인합니다.
  3. 로드 성공 여부 확인: 로그에 YAML 파싱 오류, 알 수 없는 정책 그룹, 프로바이더 가져오기 실패, 포트 바인딩 실패가 없는지 확인합니다.
  4. 최종 설정 확인: 실행 모드가 rule인지 확인하고, 오버라이드가 유지됐는지와 기본 규칙이 여전히 마지막에 있는지 살펴봅니다.
  5. 실제 연결 확인: 각 기기에서 직접 연결해야 하는 주소와 프록시를 거쳐야 하는 주소에 접속한 뒤 연결 목록에서 적용된 규칙과 접속 지점을 확인합니다. 지연 시간 테스트에 성공해도 테스트 대상에 연결된다는 것만 알 수 있습니다.
  6. 네트워크 전환 후 재확인: 스마트폰은 Wi-Fi와 모바일 네트워크에서 각각 확인하고, 데스크톱에서는 로컬 네트워크 서비스에 계속 예상대로 접속할 수 있는지 살펴봅니다.

PC에서는 정상이고 스마트폰에서 실패한다면 스마트폰이 실제로 불러온 설정과 프로바이더 업데이트 시각부터 확인한 다음 VPN 권한, 백그라운드 업데이트, DNS, 프로토콜 지원 여부를 살펴보세요. 모든 규칙을 먼저 전역 프록시로 바꾸면 라우팅 문제를 일시적으로 우회할 수는 있지만 원인을 찾을 단서가 사라질 수 있습니다.

추천 조합과 인증 정보 관리

  • 노드만 공유: 모든 기기에서 같은 주소를 구독하고 기기별 설정은 각각 저장합니다. 계정 제한과 업데이트 상태를 중점적으로 관리합니다.
  • 노드와 일부 예외 규칙 공유: 구독에 별도 오버라이드를 추가합니다. 모든 기기에서 표현할 수 있는 정적 규칙을 우선 사용하고 목록 병합 방식을 기기별로 확인합니다.
  • 여러 기기를 장기 관리: 비공개 저장소에 규칙 원본 파일과 변경 이력을 보관하고 구독 인증 정보는 기기에 저장합니다. 플랫폼에 맞는 설정을 각각 생성하거나 가져옵니다.
  • 정책 그룹을 동적으로 생성: 해당 기능을 지원하는 관리 환경에서 처리한 뒤 다른 기기에는 호환되는 결과를 전달합니다. 스마트폰에서 데스크톱 스크립트를 실행할 수 있다고 가정하지 마세요.

구독 URL에는 대개 인증 정보가 포함됩니다. QR 코드와 설정 내보내기 파일, 로그 스크린샷에도 같은 접근 권한이 담길 수 있습니다. 문제 화면을 공유하기 전에 쿼리 매개변수와 노드 암호, 컨트롤러 키를 가리세요. 주소를 다른 사람이 알게 됐다면 서비스 제공업체 관리 화면에서 구독 토큰을 재설정한 다음 모든 기기의 설정을 업데이트해야 합니다. 채팅 메시지를 삭제하거나 저장소를 다시 비공개로 바꿔도 이미 복사된 주소는 무효화되지 않습니다.

컨트롤러 인터페이스 역시 스마트폰과 공유할 공용 접속 지점이 아닙니다. 원격 관리를 위해 external-controller를 인터넷에 직접 공개하지 마세요. 여러 기기의 동기화 목적은 설정과 규칙을 배포하는 것이지, 기기별 관리 권한을 공유하는 것이 아닙니다. 공유할 계층을 먼저 정하고 기기별 차이를 유지하는 편이 YAML의 모든 바이트를 같게 만드는 것보다 관리하기 쉽습니다.