PC와 모바일에서 Clash 설정 공유하기: 구독 업데이트, 설정 호스팅 및 수동 동기화

먼저 동기화 범위를 정하세요: 공통 소스와 기기별 설정 분리

PC와 모바일에서 같은 Clash 구독을 사용할 수 있지만, 클라이언트 데이터 디렉터리 전체를 그대로 동기화하는 것은 피해야 합니다. 노드, 프록시 그룹, 규칙은 공통 소스에서 관리하고 시스템 프록시, TUN, 수신 포트, 인터페이스 설정은 각 기기에서 따로 지정하는 방식이 안전합니다. 구독을 업데이트해도 PC의 네트워크 인터페이스 설정이 모바일에 함께 적용되지 않습니다.

‘설정을 공유한다’고 해서 ‘실행 상태까지 공유한다’는 뜻은 아닙니다. PC에서 직접 선택한 노드, 모바일의 현재 연결, 속도 측정 결과와 트래픽 통계는 대개 각 클라이언트에 로컬로 저장되므로 구독 주소가 같아도 자동 동기화되지 않습니다. 서비스 제공업체의 기기 수, 동시 연결 수, 트래픽 제한도 그대로 적용되므로 먼저 계정 이용 조건을 확인하세요.

방법 1: PC와 모바일에 같은 구독 추가하기

각 기기에 따로 추가하고 클라이언트 폴더는 복사하지 마세요

1. 서비스 제공업체 계정 페이지에서 Clash 또는 mihomo용 구독 주소를 복사합니다. 출력 형식이 여러 개라면 양쪽 기기의 코어에서 모두 지원하는 형식을 선택하세요.
2. PC에서 설정 관리 화면을 엽니다. Clash Verge Rev를 예로 들면 ‘구독’ 페이지의 링크 입력란에 주소를 붙여 넣고 가져온 다음 새 설정을 선택합니다.
3. 모바일에도 같은 주소를 별도로 추가합니다. Clash for Android의 일반적인 화면에서는 ‘설정’ → ‘＋’ → ‘URL에서 가져오기’를 차례로 열고 이름, URL, 자동 업데이트 주기를 입력한 뒤 저장합니다.
4. 두 기기에서 각각 한 번씩 직접 업데이트해 노드 목록과 프록시 그룹이 불러와졌는지 확인한 다음, 각 기기의 시스템 프록시 또는 VPN 연결을 활성화하세요.

클라이언트 버전이나 번역에 따라 버튼 이름이 달라질 수 있습니다. ‘설정’, ‘구독’, ‘URL에서 가져오기’와 같은 메뉴를 찾으세요. 구독 주소를 HTTP 프록시 서버 주소 입력란에 넣으면 안 됩니다. 요청 매개변수나 클라이언트 식별 정보에 따라 구독 응답이 달라질 수 있으므로 같은 URL을 사용해도 양쪽 기기에 완전히 같은 파일이 전달된다고 보장할 수는 없습니다.

업데이트 주기는 우선 24시간으로 설정

대부분의 개인 기기는 24시간 간격으로 시작하면 충분합니다. 입력 단위가 분이면 1440, 초이면 86400을 입력하세요. 클라이언트의 구독 업데이트 주기와 YAML에 지정된 provider의 interval은 서로 다른 데이터를 갱신하므로 혼동하지 마세요.

모바일의 백그라운드 작업은 절전 설정, 네트워크 상태, 시스템 스케줄링의 영향을 받으므로 예약 업데이트가 정확한 시각에 실행되지는 않습니다. 오랫동안 전원을 끄거나 절전 상태로 둔 뒤에는 먼저 직접 업데이트한 다음 노드가 작동하지 않는지 확인하세요. 계정 페이지의 만료 시각, 구독의 최근 업데이트 시각, 노드 속도 측정 시각도 각각 다른 정보를 나타냅니다.

• 전체 구독: 클라이언트가 설정 파일 전체를 다시 내려받으며 노드, 프록시 그룹, 규칙이 함께 교체될 수 있습니다.
• 노드 provider: proxy-providers는 노드 목록을 갱신하며 기본 설정의 모든 규칙을 자동으로 교체하지는 않습니다.
• 규칙 provider: rule-providers는 규칙 데이터를 갱신하며, 이를 참조하는 방식은 기본 설정에서 결정됩니다.

업데이트 후 사용자 규칙을 유지하려면 영구 오버라이드 사용

내려받은 원격 YAML을 직접 수정하면 다음 구독 업데이트 때 변경 내용이 덮어써지는 경우가 많습니다. 계속 유지할 규칙은 클라이언트가 지원하는 영구 오버라이드, 병합 설정 또는 확장 스크립트에 작성하세요. 지원 기능은 클라이언트마다 다르며 Clash 코어를 사용하는 모든 앱이 같은 오버라이드 방식을 제공하는 것은 아닙니다.

먼저 규칙 하나만 추가하고 구독을 업데이트한 뒤 ‘최종 적용 설정’을 확인해 병합 순서가 올바른지 살펴보세요. 그다음 필요한 규칙을 추가하면 됩니다. 아래는 규칙 순서를 설명하기 위한 mihomo 형식의 부분 설정 예시이며, 단독으로 가져올 수 있는 전체 구독 파일은 아닙니다.

rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,출구 선택

출구 선택은 최종 설정에 실제로 존재하는 프록시 그룹 이름이어야 합니다. 상위 설정에서 그룹 이름을 바꾸면 이 참조도 함께 수정해야 합니다. 규칙은 위에서부터 차례대로 적용되며 MATCH는 마지막에 둬야 합니다. 기존 MATCH 뒤에 새 직접 연결 규칙을 추가해도 기대한 대로 작동하지 않습니다.

목록 병합과 전체 교체를 구분하세요

• 일부 병합 기능은 rules 배열에 항목을 하나씩 추가하는 대신 배열 전체를 교체합니다. 저장한 뒤 기존 라우팅 규칙이 그대로 남아 있는지 확인하세요.
• 클라이언트가 ‘우선 규칙’을 지원한다면 LAN 예외 규칙을 기존 규칙보다 앞에 넣는 편이 규칙 목록 전체를 다시 작성하는 것보다 관리하기 쉽습니다.
• PC와 모바일의 오버라이드 설정은 각각 따로 저장하세요. PC용 확장 스크립트가 모바일에서도 실행된다고 가정하지 마세요.

복잡한 규칙을 두 기기에서 장기간 똑같이 사용하려면 기본 설정과 규칙 소스를 한곳에서 관리하세요. 기기별 예외가 몇 개뿐이라면 짧은 로컬 오버라이드를 각 기기에서 따로 관리하는 편이 명확합니다.

방법 2: 비공개 저장소에서 설정을 관리하고 접근을 통제해 배포

비공개 저장소는 규칙 변경 기록, 설정 차이 비교, 이전 버전 복원에 유용합니다. 하지만 저장소를 비공개로 설정해도 클라이언트에 원본 파일 주소를 붙여 넣으면 자동으로 읽을 수 있는 것은 아닙니다. 브라우저에 로그인된 세션은 Clash에 전달되지 않으며, 로그인이 필요한 웹페이지 주소도 바로 가져올 수 있는 YAML 주소가 아닙니다.

저장소는 버전을 관리하고 배포 서버는 접근을 관리합니다

1. 인증 정보가 없는 기본 규칙, 그룹 구조, 기기별 차이 설명을 저장소에 넣으세요. 먼저 파일에 노드 비밀번호나 구독 토큰이 없는지 확인해야 합니다.
2. 통제된 배포 절차로 최종 YAML을 생성하고 보호된 저장소에서 민감한 정보를 주입하세요. 토큰을 저장소 기록에 남기지 마세요.
3. HTTPS로 설정 파일을 제공하고 클라이언트가 실제로 지원하는 인증 방식을 설정하세요. 필요한 요청 헤더를 클라이언트가 지원하지 않는다면 접근 통제를 해제하지 말고, 접근이 통제된 방식으로 파일을 내려받아 로컬에서 가져오세요.
4. 먼저 테스트 기기 한 대에서 업데이트해 파싱과 연결을 확인한 다음 다른 기기에서도 새로고침하세요. 문제가 생겼을 때 되돌릴 수 있도록 이전에 작동한 설정도 보관하세요.

일부 호스팅 서비스의 원본 파일 링크는 일정 시간이 지나면 만료되거나 로그인 페이지, 리디렉션 페이지를 반환할 수 있습니다. YAML 파싱 오류가 발생하면 응답이 HTML이 아니라 실제 설정 내용인지 먼저 확인하세요. 로그에 전체 요청 주소가 포함되어 있다면 공유하기 전에 토큰과 사용자 정보를 가리세요.

자동 배포가 필요 없다면 비공개 저장소에 규칙 버전만 보관하고 기기 소유자가 파일을 내려받아 가져올 수도 있습니다. 온라인 배포 단계를 줄일 수 있지만 각 기기에서 현재 어떤 버전을 사용하는지는 계속 기록해야 합니다.

방법 3: YAML을 내보내 다른 기기에 직접 가져오기

수동 동기화는 휴대전화를 교체하거나 임시 테스트를 하거나 네트워크 이용이 불편할 때 적합합니다. 내보내는 시점의 설정 사본만 전달하므로 원격 구독 주소나 자동 업데이트 설정까지 유지된다고 보장할 수는 없습니다. 내보내기 전에 파일이 원본 구독인지, 최종 적용 설정인지, 클라이언트 전체 백업인지 확인하세요. 세 가지는 서로 다릅니다.

1. 원본 기기에서 구독을 업데이트하고 현재 설정이 정상적으로 작동하는지 확인합니다.
2. 클라이언트의 설정 내보내기 또는 설정 파일 열기 기능으로 YAML을 가져옵니다. 실행 중인 앱의 데이터 디렉터리 전체를 그대로 복사하지 마세요.
3. 운영체제의 근거리 전송 기능이나 접근이 통제된 파일 전송 방법으로 대상 기기에 전달하세요. 누구나 볼 수 있는 공유 링크는 피하세요.
4. 대상 클라이언트에서 ‘파일에서 가져오기’를 선택합니다. 파싱이 완료되면 프록시 그룹, DNS, 트래픽 연결 설정을 다시 확인하세요.
5. 내보낸 날짜를 기록하세요. 예: profile-2026-09-09.yaml. 파일을 임시 전달 용도로만 사용했다면 가져오기를 마친 뒤 다운로드 폴더와 채팅 첨부 파일에서 삭제하세요.

수동 가져오기 후 자동 업데이트를 사용하려면 원본 원격 구독도 별도로 추가해야 합니다. 로컬 파일 경로를 구독 URL로 사용하면 안 됩니다. 내보낸 파일에 원격 소스 정보가 항상 포함되는 것은 아니며, 처리 방식은 클라이언트마다 다릅니다.

플랫폼별 설정: 포트, TUN, DNS를 따로 확인

Clash 설정은 여러 클라이언트가 사용하는 형식이지만 모든 클라이언트가 같은 항목을 지원하는 것은 아닙니다. 기존 Clash 코어, Clash Meta(현재 이름은 mihomo), 기타 호환 클라이언트는 지원 프로토콜과 설정 옵션이 서로 다를 수 있습니다. 반복해서 재설치하기보다 양쪽 앱의 ‘정보’ 또는 코어 정보 화면에서 버전을 먼저 확인하세요.

DNS 설정이 같아도 네트워크 환경까지 같은 것은 아닙니다

모바일에서 셀룰러 네트워크로 전환하면 DNS 상위 서버에 연결할 수 있는지가 가정용 인터넷과 다를 수 있습니다. Fake-IP를 사용한다면 양쪽 기기가 같은 enhanced-mode와 필터 옵션을 지원하는지 확인하세요. LAN 기기 이름을 해석하는 기능은 현재 네트워크의 DNS 서버에도 영향을 받습니다. 특정 기기의 임시 Fake-IP 매핑 데이터베이스를 동기화 대상으로 삼지 마세요.

Android는 보통 VpnService로 트래픽을 연결하며 시스템 권한 승인이 필요합니다. 데스크톱은 시스템 프록시나 TUN을 사용할 수 있습니다. 설정은 같은데 접속 결과가 다르다면 먼저 트래픽이 코어에 전달되는지 확인하고, 그다음 규칙이 양쪽에서 같은 출구를 선택했는지 살펴보세요.

두 기기의 결과가 다를 때는 네 단계로 점검하세요

1. 소스 계층: 구독 URL, 출력 형식, 최근 업데이트 시각을 확인하세요. 업데이트에 실패하면 클라이언트가 이전 설정을 계속 사용할 수 있습니다. 노드가 표시된다고 업데이트가 완료된 것은 아닙니다.
2. 병합 계층: 최종 적용 설정의 프록시 그룹과 규칙을 비교하세요. 오버라이드가 목록 전체를 교체하지 않았는지, 그룹 참조가 끊기지 않았는지, 기본 규칙이 먼저 적용되지 않았는지 확인합니다.
3. 트래픽 연결 계층: PC의 시스템 프록시나 TUN이 켜져 있는지, 모바일에서 VPN 권한을 허용했는지 확인하세요. 연결 기록에 대상 앱의 요청이 없다면 먼저 트래픽 연결 문제를 해결해야 합니다.
4. 네트워크 계층: 양쪽 기기에서 같은 노드를 선택하고 같은 대상에 접속해 적용된 규칙, 출구, 오류 로그를 각각 기록하세요. 같은 Wi-Fi와 셀룰러 네트워크에서도 비교해 설정 문제와 네트워크 차이를 구분합니다.

일상적인 관리에는 일정한 절차를 정해 두면 좋습니다. 먼저 한 기기를 업데이트하고 자주 쓰는 웹사이트, LAN 서비스, DNS를 확인하세요. 문제가 없으면 나머지 기기도 업데이트합니다. 문제가 다시 발생하면 설정 버전을 되돌리고 노드, DNS, TUN, 규칙을 한꺼번에 변경하지 마세요.

마지막으로 설정을 계층별로 관리하세요. 노드는 구독으로 업데이트하고, 공통 규칙은 변경 이력을 추적할 수 있는 소스에서 관리하며, 기기 권한과 트래픽 연결은 각 기기에 맡기면 됩니다. 트래픽 연결과 접속을 더 자세히 확인하려면 문제 해결 가이드를 참고하세요. 프록시 그룹이나 규칙 provider 등의 항목이 낯설다면 용어집을 확인할 수 있습니다.