Clash Profile 설정 파일 입문: 여러 구독 전환과 로컬 설정 관리

1. Profile, 구독, 실행 설정의 관계

Clash 클라이언트에서 Profile은 저장해 두고 선택한 다음, 코어에 적용할 수 있는 설정 항목을 말합니다. 구독 URL에서 가져오거나 로컬 YAML 파일을 불러와 만들 수 있습니다. 설정 카드가 세 개 있어도 프록시 세 개가 동시에 활성화되는 것은 아닙니다. 일반적인 데스크톱 클라이언트는 한 번에 기본 설정 하나를 선택하고, 여기에 클라이언트 설정과 오버라이드를 더해 코어에 전달할 실행 설정을 만듭니다.

이 문서에서는 mihomo 코어를 사용하는 Clash Verge Rev 계열 데스크톱 클라이언트를 기준으로 설명합니다. 클라이언트에 따라 메뉴 이름이 ‘구독’, ‘설정’, ‘Profiles’ 등으로 다를 수 있으므로, 아래에서는 찾아야 할 기능도 함께 안내합니다. 구형 Clash 코어와 mihomo는 지원하는 필드가 완전히 같지 않습니다. 파일 확장자가 .yaml이라는 이유만으로 서로 호환된다고 판단하지 마세요.

항목	저장되는 내용	업데이트 방식
원격 Profile	구독 URL, 다운로드한 설정, 클라이언트에 저장된 기록	수동 가져오기 또는 예약 가져오기
로컬 Profile	직접 만들거나 가져온 YAML	직접 편집하며, 외부 파일과 동기화되는지는 클라이언트에 따라 다름
오버라이드 설정	기본 설정에 추가하거나 수정하는 필드 및 규칙	클라이언트의 병합 기능이나 스크립트로 처리
실행 설정	실제로 코어에 전달되는 최종 결과	설정 선택, 적용 또는 다시 불러올 때 생성

구독은 제공하는 콘텐츠 유형도 다릅니다. 완전한 설정을 반환하는 구독도 있고 노드 정보만 반환하는 구독도 있습니다. 완전한 설정에는 일반적으로 프록시, 프록시 그룹, 규칙이 포함됩니다. 노드만 포함된 데이터는 클라이언트가 지원하는 변환 방식이나 proxy-providers를 통해 연결해야 할 수 있으며, 완전한 Profile처럼 바로 사용할 수는 없습니다. 토큰이 포함된 구독 URL을 신뢰할 수 없는 온라인 변환 서비스에 입력하지 마세요.

2. 구독 두 개 가져오기: 이름 지정 후 활성화

여러 설정을 관리할 때 먼저 해결해야 할 문제는 각 설정을 쉽게 구별하는 것입니다. 이름을 ‘구독 1’, ‘구독 2’로만 지정하면 시간이 지난 뒤 어느 설정을 수정할 수 있고 어느 설정이 원격 업데이트되는지 파악하기 어렵습니다. 용도, 출처를 구분하는 이름, 설정 유형을 따로 기록하고, 표시 이름에는 액세스 토큰, 이메일 주소, 전체 구독 URL을 넣지 마세요.

한눈에 구별되는 설정 항목 만들기

왼쪽 메뉴에서 ‘구독’ 또는 ‘Profiles’를 열고 구독 URL 입력란을 찾습니다. 서비스 제공업체에서 받은 Clash 호환 URL을 붙여 넣고 ‘가져오기’를 누릅니다. 설정 카드가 나타날 때까지 기다리세요. 입력이 완료됐다고 해서 다운로드까지 성공한 것은 아닙니다.
카드의 마우스 오른쪽 버튼 메뉴나 더보기 메뉴를 열고 ‘정보 수정’과 같은 항목을 선택합니다. 이름을 ‘일상-A-원격’으로 바꾼 다음, 원격 URL이 올바르게 저장되어 있는지 확인하고 저장합니다.
같은 방법으로 두 번째 구독을 가져와 ‘예비-B-원격’으로 이름을 지정합니다. 가져오는 중 형식 오류가 발생하면 응답이 YAML인지, 웹 로그인 페이지나 만료 안내 페이지인지 먼저 확인하세요.
‘일상-A-원격’ 카드를 클릭합니다. 선택 표시가 나타나면 ‘프록시’ 페이지로 이동해 해당 설정에 정의된 프록시 그룹과 노드가 표시되는지 확인합니다.

위에서 지정한 이름은 클라이언트에 표시되는 이름일 뿐, YAML의 프록시 그룹 name을 자동으로 바꾸지는 않습니다. 규칙이 PROXY라는 프록시 그룹을 참조하는데 그룹 이름만 ‘일상 프록시’로 바꾸고 참조 항목은 수정하지 않으면 설정을 불러오지 못할 수 있습니다. 처음 정리할 때는 카드 이름만 바꾸고 내부 그룹 이름은 그대로 두세요.

3. 구독을 전환한 뒤 네 가지 항목으로 적용 여부 확인

A에서 B로 전환하면 노드 목록만 바뀌는 것이 아닙니다. 기본 설정에 따라 DNS, 규칙, 프록시 그룹 이름, 리스닝 포트, TUN 관련 필드도 달라질 수 있습니다. 한편 클라이언트의 전역 설정이 이 중 일부를 덮어쓸 수도 있습니다. 따라서 ‘노드 이름이 바뀌었다’는 이유만으로 설정 전체가 예상대로 적용됐다고 판단할 수 없습니다.

로드 결과 확인: B를 선택한 뒤 ‘로그’를 열어 설정 파싱 오류나 프록시 그룹 참조 오류가 있는지 확인합니다. 새 설정을 불러오지 못하면 클라이언트 처리 방식에 따라 코어가 이전 설정을 계속 유지하거나 서비스가 중단될 수 있습니다.
프록시 모드 확인: 홈 화면에서 현재 모드가 Rule, Global, Direct 중 무엇인지 확인합니다. 규칙을 검증할 때는 Rule을 선택하세요. Global은 모든 트래픽에 전역 정책을 적용하므로 규칙 순서가 올바른지 검증하는 데 사용할 수 없습니다.
실제 연결 경로 확인: ‘프록시’로 이동해 B의 주요 프록시 그룹에서 사용 가능한 노드를 선택한 다음 테스트 페이지를 엽니다. B의 그룹 이름이 A와 다르면 이전에 저장한 노드 선택이 유지되지 않을 수 있습니다.
새 연결 기록 확인: ‘연결’에서 새 요청에 적용된 규칙과 프록시 체인을 확인합니다. 기존 장기 연결은 이전 연결 경로를 계속 사용할 수 있으므로 테스트 페이지를 닫았다가 다시 여세요. 필요한 경우 해당 테스트 연결만 끊습니다.

포트가 바뀌면 왜 전환 후 인터넷이 끊길까?

예를 들어 앱의 로컬 HTTP 프록시를 127.0.0.1:7890으로 직접 설정했는데 B의 실제 리스닝 포트가 7897로 바뀌었다고 가정해 보겠습니다. 앱이 이전 포트로 계속 요청을 보내면 연결에 실패합니다. 두 포트 번호는 문제 해결을 위한 예시이며 모든 클라이언트의 기본값은 아닙니다. 클라이언트 ‘설정’의 포트 항목에서 현재 값을 확인한 뒤 앱의 프록시 설정과 하나씩 대조하세요.

시스템 프록시, TUN, Profile은 서로 다른 계층입니다. Profile은 코어 실행에 필요한 설정을 제공하고, 시스템 프록시는 시스템 프록시 설정을 따르는 앱에 영향을 주며, TUN은 라우팅 조건에 맞는 트래픽을 처리합니다. Profile을 선택했다고 해서 시스템 프록시나 TUN이 자동으로 활성화되는 것은 아닙니다.

4. 자동 업데이트 간격: 구독 업데이트와 노드 상태 확인 구분하기

원격 Profile의 예약 업데이트는 클라이언트에서 관리합니다. 보통 설정 카드의 ‘정보 수정’에서 ‘업데이트 간격’ 또는 ‘자동 업데이트’ 항목을 찾을 수 있습니다. 값을 입력하기 전에 입력란 옆에 표시된 단위를 확인하세요. 단위가 분이면 720을 입력할 때마다 12시간 간격입니다. 단위가 초라면 12시간은 43200으로 입력해야 합니다. 다른 클라이언트의 화면을 보고 그대로 입력하지 마세요.

일상용 설정: 우선 24시간에 한 번 업데이트하도록 설정할 수 있습니다. 단위가 분이라면 1440을 입력하면 됩니다. 서비스 제공업체가 명확한 업데이트 주기를 안내했다면 해당 지침을 따르세요.
예비 설정: 실제로 전환할 때 URL이 만료된 것을 발견하지 않도록 정기적으로 업데이트하세요. 업데이트 후 노드 수를 확인하고 실제 연결도 한 번 테스트합니다.
로컬 설정: 원격 출처가 없는 설정에는 구독 업데이트 간격을 지정할 필요가 없습니다. 자동 업데이트 버튼을 표시하려고 임의의 URL을 입력하지 마세요.

클라이언트를 종료하면 일반적으로 클라이언트 내부의 예약 작업도 실행되지 않습니다. 컴퓨터가 절전 모드인 동안 정해진 시간에 업데이트될 것으로 기대해서도 안 됩니다. 클라이언트가 다시 실행된 뒤 업데이트를 즉시 따라잡을지는 구현 방식에 따라 다릅니다. 외출 중 예비 설정을 사용해야 한다면 미리 카드 메뉴에서 ‘업데이트’를 눌러 성공 시간을 확인하고 연결 테스트까지 마치는 편이 안전합니다.

서로 다른 세 가지 interval 구분하기

Profile 업데이트 간격은 클라이언트의 설정 항목입니다. YAML의 proxy-providers 아래에 있는 interval은 해당 원격 노드 리소스의 업데이트 주기를 지정하고, health-check.interval은 상태 검사 주기를 지정합니다. mihomo의 이러한 provider 필드에서 간격 단위는 초입니다. 상태 검사 간격을 300초로 바꿔도 검사 주기만 달라질 뿐, 기본 구독이 5분마다 다시 다운로드되지는 않습니다.

5. 로컬 YAML: 스냅샷 보관에 적합하지만 구독 업데이트를 따라가지는 않음

로컬 Profile은 규칙을 실험하거나, 장애 전 설정을 보관하거나, 직접 관리하는 전체 설정을 유지할 때 유용합니다. 일반적인 가져오기 경로는 ‘구독’ → ‘새로 만들기’ 또는 ‘파일 가져오기’입니다. 로컬 YAML을 선택하고 ‘실험-규칙-로컬’이라는 이름으로 저장하세요. 일부 클라이언트는 파일을 자체 데이터 디렉터리에 복사하며 원본 파일을 계속 읽지 않습니다. 따라서 가져온 뒤 외부에서 원본 파일을 편집해도 카드에 반영되지 않을 수 있습니다.

로컬 복사본을 만드는 순서

원격 카드 메뉴에서 ‘파일 편집’ 또는 ‘파일 열기’를 찾아 다운로드한 기본 설정을 복사합니다. 클라이언트에서 내보내기 기능을 제공한다면 이를 사용해도 됩니다.
복사본을 보호된 로컬 디렉터리에 저장한 다음 파일 가져오기 기능으로 새 카드를 추가합니다. 기존 원격 항목을 덮어쓰지 마세요.
수정할 항목 하나만 바꾼 뒤 저장하고 로컬 카드를 선택해 로그를 확인합니다. 변경이 정상적으로 적용된 것을 확인한 다음 다음 항목을 수정하세요.
되돌릴 수 있도록 원격 카드를 남겨 두세요. 실험에 실패하면 원격 카드로 전환한 뒤 프록시 모드, 프록시 그룹 선택, 새 연결 기록을 확인합니다.

아래는 필드를 알아보기 위한 기본 예시이며, 구독을 바로 대체할 수 있는 완전한 프록시 설정이 아닙니다. 마지막 규칙은 나머지 모든 요청을 직접 연결로 보내며 프록시 노드는 제공하지 않습니다. 규칙을 테스트하기 전에 이 결과를 이해해야 하며, 연결 문제를 해결하는 방법으로 사용해서는 안 됩니다.

mixed-port: 7890
mode: rule
log-level: info

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

YAML 들여쓰기에는 탭 대신 공백을 사용하고 같은 수준의 필드는 들여쓰기를 동일하게 유지하세요. 기존 파일을 편집할 때 최상위 rules 또는 dns 키를 두 번 추가하지 마세요. 중복 키는 거부되거나 내용이 덮어써질 수 있습니다. 파일을 저장하기 전에 우선 클라이언트의 설정 검사 기능을 사용하세요.

로컬 복사본에 저장된 노드 인증 정보도 만료될 수 있으므로 한 번 복사했다고 이후에 업데이트할 필요가 없는 것은 아닙니다. 노드는 자동으로 업데이트하면서 개인 규칙을 계속 유지하려면, 고정된 구독 복사본에 의존하기보다 오버라이드나 provider 구조를 사용하세요.

6. 구독 업데이트 후에도 오버라이드 유지하기: 원본과 개인 설정 분리

원격 구독에서 다운로드한 YAML을 직접 편집하면 다음 업데이트 때 새 콘텐츠로 덮어써질 수 있습니다. 더 안전한 구성은 원격 Profile에 서비스 제공업체의 설정을 그대로 두고 개인 규칙은 클라이언트의 오버라이드, 병합 설정 또는 스크립트 설정에 따로 저장하는 것입니다. 클라이언트는 실행 설정을 만들 때마다 자체 처리 순서에 따라 변경 사항을 추가합니다.

이 기능을 지원하는 클라이언트에서는 ‘구독’ 페이지에서 ‘전역 확장 설정’, ‘전역 확장 스크립트’를 찾거나 개별 카드 메뉴에서 ‘확장 설정’을 찾아보세요. 이름과 적용 범위는 버전에 따라 다릅니다. 전역 항목은 모든 Profile에 영향을 줄 수 있지만 개별 설정 확장은 보통 해당 항목에만 연결됩니다. 일상 설정에 적용하기 전에 실험용 복사본으로 적용 범위를 확인하세요.

병합 규칙을 확인한 뒤 분기 규칙 추가하기

맵 항목: DNS 하위 필드를 수정할 때 클라이언트가 재귀적으로 병합하는지 전체 항목을 교체하는지 확인하세요. 기존 DNS 설정이 사라지는 것을 방지할 수 있습니다.
목록 항목: rules, proxies, proxy-groups는 모두 목록입니다. 일반 YAML 조각에 자동으로 ‘추가’ 의미가 부여되는 것은 아니며 구체적인 동작은 클라이언트에 따라 다릅니다.
규칙 순서: Clash 규칙은 순서대로 매칭됩니다. 개인 규칙은 보통 기본 규칙인 MATCH 앞에 배치해야 합니다. MATCH 뒤에 추가하면 대개 해당 규칙이 적용될 기회가 없습니다.
정책 참조: 전역 오버라이드가 A에만 존재하는 프록시 그룹을 참조하면 B로 전환할 때 설정을 불러오지 못할 수 있습니다. 여러 설정에서 재사용하려면 그룹 이름을 통일하거나 확장을 각 설정에 따로 연결하세요.

예를 들어 example.com과 하위 도메인을 직접 연결하려면 규칙을 DOMAIN-SUFFIX,example.com,DIRECT로 작성할 수 있습니다. 이는 규칙 문법을 설명하는 예시일 뿐입니다. 현재 클라이언트에서 명시적으로 지원하는 ‘우선 규칙’ 항목을 사용하거나 확장 스크립트 인터페이스를 통해 삽입하세요. 모든 클라이언트가 같은 prepend-rules 필드를 지원한다고 가정하면 안 됩니다.

업데이트 한 번으로 설정 유지 여부 확인하기

오버라이드를 저장하고 설정을 적용한 다음 최종 실행 설정에서 대상 도메인을 검색합니다. 예상한 횟수만큼만 표시되는지, 기본 규칙보다 앞에 있는지 확인하세요.
해당 도메인에 새 요청을 보내고 ‘연결’에서 대상 규칙 및 DIRECT 정책이 적용됐는지 확인합니다.
원격 Profile을 수동으로 업데이트하고 설정이 다시 로드될 때까지 기다린 뒤 앞의 두 항목을 다시 확인합니다.
예비 Profile로 전환해 전역 오버라이드가 없는 프록시 그룹을 참조하지 않는지 확인합니다. 오류가 발생하면 해당 설정에만 확장을 연결하도록 변경하세요.

업데이트 후에도 규칙이 남아 있고, 요청에 실제 적용되며, 설정 전환 시 오류가 발생하지 않는 세 가지 조건을 모두 만족해야 지속 가능한 설정으로 볼 수 있습니다. 기본 구독 파일에서 개인 규칙이 보이지 않아도 반드시 사라진 것은 아닙니다. 오버라이드는 최종 실행 설정에만 존재할 수 있습니다.

7. 백업 및 복구: 다시 활성화하는 데 필요한 항목만 보관

백업을 프록시 페이지의 스크린샷 한 장으로 끝내지 마세요. 설정 표시 이름, 원격 URL, 개인 오버라이드, 필요한 로컬 YAML, 현재 포트와 모드를 함께 기록하는 것이 좋습니다. proxy-providers, rule-providers 또는 상대 경로를 사용한다면 의존 리소스를 다시 가져올 수 있는지 확인하고, 필요하면 관련 파일도 함께 보관하세요.

증상	우선 확인할 항목	복구 방법
업데이트 후 사용자 규칙이 사라짐	원격 파일을 직접 수정했는지 여부	백업에서 규칙을 복원한 뒤 별도의 오버라이드로 옮기기
전환 후 프록시 그룹이 없다는 오류 표시	전역 오버라이드에 지정된 정책 이름	관련 오버라이드를 끄고 개별 설정 확장 사용
설정은 선택됐지만 앱에서 인터넷에 연결할 수 없음	리스닝 포트, 시스템 프록시, TUN 상태	현재 포트에 맞게 앱 프록시를 다시 설정하고 새 연결 테스트
로컬 파일을 수정해도 변경 사항이 없음	가져오는 과정에서 파일이 복사됐는지 여부	클라이언트가 실제로 사용하는 복사본을 편집하고 다시 적용

구독 URL과 설정 파일에는 실제 연결에 사용할 수 있는 인증 정보가 포함될 수 있습니다. 공개 코드 저장소에 올리지 마세요. 문제 해결 정보를 다른 사람과 공유할 때는 구독 토큰, 노드 비밀번호, 개인 키를 삭제하고 스크린샷에서도 전체 URL을 가리세요. 새 기기로 옮길 때는 정상 작동이 확인된 설정을 먼저 가져와 연결을 테스트하고, 오버라이드를 복원한 다음 마지막으로 예약 업데이트를 켜면 각 단계의 문제를 찾기 쉽습니다.

구독 가져오기, 규칙, TUN의 관계도 살펴보려면 Clash 설정 가이드를 이어서 읽어 보세요. 첫 설치 후 진행 순서는 사용 안내에서 확인할 수 있습니다.