Clash Profile이란? 구독 설정과 로컬 설정의 차이, 여러 설정 전환·관리

Profile은 클라이언트가 관리하는 설정 프로필

Profile은 일반적으로 클라이언트에 저장된 설정 프로필을 뜻하며, 노드 하나나 프록시 프로토콜 하나를 가리키는 말이 아닙니다. 원격 구독에서 가져올 수도 있고 로컬 YAML 파일에서 가져올 수도 있습니다. 클라이언트는 출처, 이름, 업데이트 정보와 선택 상태를 저장하고, 코어는 최종 생성된 설정을 읽어 수신 포트를 열고 노드를 불러와 라우팅 규칙을 적용합니다.

하나의 완전한 설정에는 mixed-port, mode, dns, proxies, proxy-groups, rules가 함께 들어갈 수 있습니다. 노드는 연결 정보이고, 프록시 그룹은 노드를 선택하는 진입점이며, 규칙은 연결에 적용할 정책을 결정합니다. Profile을 전환하면 이 세 부분이 모두 바뀔 수 있으므로 서버 하나만 바꾸는 것으로 보면 안 됩니다.

클라이언트에 따라 메뉴가 ‘설정’, ‘구독’ 또는 ‘Profiles’로 표시될 수 있습니다. 이는 화면상의 명칭일 뿐, Clash나 mihomo 코어에서 공통으로 정한 메뉴는 아닙니다. 작업이 적용됐는지 확인하려면 목록에 카드가 추가됐는지만 보지 말고 현재 설정 표시, 코어 로드 결과와 실제 규칙을 확인하세요.

원격 구독과 로컬 YAML의 차이

두 방식의 핵심 차이는 출처와 업데이트 방식이지, YAML의 기능이 아닙니다. 원격 구독은 보통 클라이언트가 URL을 통해 가져오고, 로컬 설정은 사용자가 가져오거나 만들고 편집합니다. 원격에서 받은 내용도 완전한 Clash 설정이라면 대개 YAML 형식이지만, ‘구독 링크’가 곧바로 불러올 수 있는 완전한 설정을 반환한다고 보장할 수는 없습니다.

확인 항목	원격 구독 Profile	로컬 YAML Profile
출처	클라이언트에 저장된 구독 URL	디스크 파일 또는 클라이언트 편집기
콘텐츠 변경 방식	수동 또는 예약 업데이트	수동 편집 또는 외부 도구로 업데이트
직접 편집 시 주의점	다음 업데이트 때 수정 내용이 덮어써질 수 있음	일반적으로 원격 구독 새로고침의 영향을 받지 않음
노드 최신성	서비스 제공자가 반환하는 내용에 따름	복사해 온 노드는 자동으로 갱신되지 않음
마이그레이션 시 확인 사항	출처와 로컬 오버라이드 설정 저장	파일과 파일에서 참조하는 외부 리소스 저장

구독 주소가 설정 파일 주소와 같지는 않습니다

일부 서비스는 완전한 YAML을 반환하고, 일부는 노드 목록만 제공하며, 또 다른 곳은 인코딩된 프로토콜 링크 모음을 반환합니다. 뒤의 두 형식은 클라이언트가 해당 가져오기 형식을 지원하거나 신뢰할 수 있는 변환 절차를 거쳐야 사용할 수 있는 설정이 됩니다. 브라우저에서 URL이 열린다는 것은 요청에 응답이 왔다는 뜻일 뿐, 현재 코어에 맞는 형식이라는 의미는 아닙니다.

가져온 뒤 필드 누락이나 파싱 오류가 표시되면 먼저 응답이 로그인 페이지, 오류 메시지 또는 호환되지 않는 형식인지 확인하세요. 구독 URL에는 접근 토큰이 포함되는 경우가 많으므로 문제 해결 중 주소 전체를 공개하거나 출처가 불분명한 온라인 변환 서비스에 입력하지 마세요.

간단한 YAML로 설정의 범위 이해하기

아래는 필드 간 관계를 이해하기 위한 로컬 설정 예시입니다. 127.0.0.1:7890에서 수신하고 모든 연결에 내장 정책인 DIRECT를 사용합니다. 원격 프록시 노드가 없으므로 프록시 출구를 확인하는 용도로는 사용할 수 없습니다. 격리된 테스트 설정에서 YAML 로드와 규칙 구조를 점검하는 데 적합합니다.

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

proxy-groups:
  - name: ROUTE
    type: select
    proxies:
      - DIRECT

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

mixed-port: 7890은 하나의 포트에서 HTTP와 SOCKS 프록시 연결을 모두 받는다는 뜻입니다. 해당 포트를 이미 사용 중이라면 비어 있는 포트로 바꾸세요.
mode: rule은 규칙 목록에 따라 연결을 처리한다는 뜻입니다. 실행 중 전역 모드로 전환했다면 이 설정의 규칙으로 라우팅 결과를 판단할 수 없습니다.
ROUTE는 프록시 그룹 이름입니다. 규칙에서 이 이름을 참조한다면 동일하게 유지해야 합니다. 내장 정책인 DIRECT는 별도의 노드를 만들 필요가 없습니다.
MATCH는 마지막에 적용되는 기본 규칙입니다. 뒤에 있는 규칙은 매칭 기회가 없으므로 이 예시에서는 마지막에 배치해야 합니다.

들여쓰기에는 공백을 사용하고 탭은 사용하지 마세요. 기존 구독을 가져올 때 이 예시 전체를 원본 파일에 덮어쓰지 마세요. 이 예시는 구조만 보여 주며 서비스 제공자의 노드와 정책은 포함하지 않습니다. 전체 필드 설명은 설정 필드 안내를 참고하세요.

여러 설정의 이름 지정, 업데이트와 전환

이름에는 용도, 메모에는 출처 기록

‘용도－출처－관리 방식’ 형식으로 이름을 붙이는 것을 권장합니다. 예: ‘일상－구독 A－원격’, ‘업무－로컬 규칙－오버라이드’, ‘문제 해결－직접 연결－로컬’. ‘설정 1’, ‘설정 2’처럼만 쓰지 말고 구독 토큰도 이름에 넣지 마세요. 클라이언트에서 메모를 지원한다면 가져온 날짜, 코어 종류와 오버라이드 위치를 따로 기록해 이름에 모든 정보를 몰아넣지 않는 것이 좋습니다.

업데이트와 전환은 단계별로 확인

업데이트 전에 복구 경로를 확보하세요: 사용할 수 있는 설정을 내보내고 현재 프록시 그룹 선택과 로컬 오버라이드를 저장하세요. 내보낸 파일에 노드 인증 정보가 포함될 수 있으므로 접근이 제한된 폴더에 보관하세요.
대상 항목만 업데이트하세요: 작업할 항목의 이름과 출처를 확인하고 업데이트 시간이 바뀌었는지 살펴보세요. 업데이트 시간이 바뀌었다고 설정이 활성화된 것은 아닙니다.
로드 결과를 확인하세요: 대상 Profile을 활성화한 뒤 코어 로그를 확인해 YAML 파싱 오류, 알 수 없는 필드로 인한 로드 실패, 정책 참조 오류가 없는지 살펴보세요.
실행 설정을 다시 확인하세요: 프록시 모드, 수신 포트, DNS와 TUN 활성화 여부를 점검하세요. 일부 클라이언트는 전역 설정으로 파일에 있는 같은 이름의 필드를 덮어씁니다.
새 연결로 검증하세요: 새 요청을 보내고 연결 패널에서 매칭된 규칙, 정책 경로와 출구를 확인하세요. 노드 지연 시간만 확인해서는 안 됩니다.

예를 들어 이전 설정은 7890 포트를 사용하고 새 설정은 7891로 바뀌었다고 해도, 터미널에 설정된 기존 http_proxy 값은 자동으로 바뀌지 않습니다. 브라우저의 시스템 프록시와 터미널 환경 변수도 서로 다른 설정입니다. 여러 설정에서 로컬 수신 포트를 고정하면 전환 후 포트 불일치를 줄일 수 있습니다.

사용자 지정 규칙이 구독 업데이트로 덮어써지지 않게 하려면

개인 규칙은 구독을 내려받은 사본을 직접 수정하기보다 클라이언트가 지원하는 영구 오버라이드 계층에 저장하는 것이 좋습니다. 병합 설정, 규칙 앞에 추가하는 방식, 설정 처리 스크립트 등이 흔히 사용되지만 명칭과 적용 범위, 배열 병합 방식은 클라이언트마다 다릅니다. 모든 클라이언트에 통용되는 오버라이드 파일 형식은 없으므로 작업 전에 현재 클라이언트의 안내를 확인하세요.

삽입 위치를 확인한 다음 정책 이름을 확인하세요

예시 도메인을 직접 연결하려면 아래 규칙을 최종 rules 목록의 앞쪽에 배치하면 됩니다. 아래는 최종 설정에서 기대하는 순서를 보여 주는 예시이지, 어떤 클라이언트에나 그대로 적용할 수 있는 오버라이드 문법은 아닙니다.

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

규칙 모드에서는 규칙을 순서대로 확인해 처음 일치하는 규칙의 정책을 적용합니다. 개인 규칙을 MATCH 뒤에 추가하면 대개 기대한 대로 동작하지 않습니다. ROUTE를 참조하도록 바꾸려면 최종 설정에 같은 이름의 프록시 그룹이 있어야 합니다. 구독 업데이트로 그룹 이름이 바뀌면 기존 오버라이드도 수정해야 합니다.

적용 범위 확인: 오버라이드가 하나의 Profile에만 연결되는지, 모든 설정에 적용되는지 확인하세요. 업무용 규칙이 다른 설정에 뜻하지 않게 적용되어서는 안 됩니다.
목록 병합 방식 확인: 클라이언트가 rules 배열 전체를 바꿀 수도 있고 항목을 앞이나 뒤에 추가할 수도 있습니다. ‘병합’이라는 표현만으로 동작을 추측하지 마세요.
최종 결과 확인: 클라이언트에서 실행 설정 미리보기를 지원한다면 개인 규칙이 포함됐는지, 순서가 올바른지, 대상 정책이 존재하는지 확인하세요.
업데이트 후 다시 검증: 오버라이드를 저장한 뒤 구독을 직접 새로고침하고 규칙과 새 연결을 확인해 수정 내용이 업데이트 후에도 유지되는지 검증하세요.

클라이언트가 영구 오버라이드를 지원하지 않는다면 로컬 설정으로 복사해 편집할 수 있습니다. 다만 이 사본은 원래 구독의 노드 변경 사항을 자동으로 받지 못합니다. ‘사본을 직접 관리할지’와 ‘원격 업데이트를 계속 사용할지’를 분명히 선택하고, 로컬 수정과 자동 새로고침을 임시 파일 하나에 섞지 마세요.

proxy-providers와 여러 Profile은 관리 계층이 다릅니다

proxy-providers는 설정 안에서 노드 제공자를 참조하는 기능이고, 여러 Profile은 클라이언트에 여러 설정 프로필을 저장하는 방식입니다. mihomo를 예로 들면 로컬 설정 하나에서 여러 제공자를 참조해 노드 출처와 로컬 규칙을 따로 관리할 수 있습니다. 단, 프록시 그룹이 해당 제공자를 올바르게 참조하도록 설정해야 합니다.

제공자 업데이트는 일반적으로 해당 제공자가 제공하는 노드만 갱신하며, 기본 설정 전체를 다시 다운로드하는 것과는 다릅니다. 제공자 URL도 현재 구현에서 허용하는 형식으로 응답해야 합니다. 어떤 ‘구독 링크’든 그대로 입력할 수 있다고 단정하지 마세요. rule-providers도 사용한다면 규칙 모음 다운로드와 기본 설정 업데이트를 별도로 점검해야 합니다.

일반적인 사용 환경에서는 안정적인 구독 하나를 유지하고 필요한 로컬 오버라이드를 추가하는 것부터 시작하면 됩니다. 노드 출처, 규칙 모음과 업데이트 주기를 분리해야 할 때만 제공자 구조를 고려하세요. 중복 규칙을 여러 벌 관리하다 최종 설정의 출처를 파악하기 어려워지는 일을 피할 수 있습니다.

설정 전환 후 문제가 생기면 네 단계로 확인

출처 단계: 대상 Profile을 업데이트했는지, 응답이 웹 페이지가 아닌 설정 파일인지 확인하세요. 구독이 만료됐는지도 살펴보고 같은 잘못된 주소를 연속해서 다시 가져오지 마세요.
로드 단계: 코어가 새 설정을 받아들였는지 확인하세요. 들여쓰기 오류, 존재하지 않는 정책, 필드 비호환성이 있다면 노드 시간 초과로 단정하지 말고 먼저 로드 문제를 해결하세요.
수신 단계: 7890 또는 사용자 지정 포트가 수신 중인지, 시스템 프록시와 터미널이 같은 주소를 가리키는지 확인하세요. TUN은 권한, 라우팅과 DNS 가로채기 상태도 별도로 확인해야 합니다.
라우팅 단계: 실행 모드가 rule인지 확인하고 새 연결에 적용된 규칙과 프록시 그룹 선택을 살펴본 다음 원격 노드나 서버 문제인지 판단하세요.

구독 세 개를 가져오면 노드가 자동으로 합쳐지나요?

대부분은 그렇지 않습니다. 일반적인 클라이언트는 한 번에 기본 설정 하나만 활성화하고, 다른 구독은 목록에 보관합니다. 합쳐야 한다면 클라이언트가 명시적으로 지원하는 병합 기능을 사용하거나 호환되는 코어에서 제공자로 노드를 구성해야 합니다. 목록에 항목이 세 개 있다고 자동 병합되는 것은 아닙니다.

Profile을 바꾸면 TUN도 자동으로 전환되나요?

반드시 그런 것은 아닙니다. TUN은 클라이언트의 전역 스위치로 관리될 수도 있고 설정과 오버라이드가 함께 결정할 수도 있으며, 시스템 권한도 필요합니다. 가져온 파일에 tun 필드가 있는지만 보지 말고 클라이언트 실행 상태와 최종 설정을 확인하세요.

YAML 파일 하나를 백업하면 완전히 마이그레이션할 수 있나요?

반드시 그렇지는 않습니다. 기본 설정이 로컬 규칙 파일, 제공자 캐시, 인증서 경로 또는 클라이언트 오버라이드를 참조할 수 있고, 구독 URL과 화면에서 선택한 정책도 별도로 저장될 수 있습니다. 마이그레이션 전에 의존 항목을 정리하고 새 기기에서 가져온 뒤 포트, 규칙과 새 연결을 확인하세요. 인증 정보가 포함된 파일도 안전하게 처리해야 합니다.

여러 설정을 관리할 때는 ‘출처 업데이트’, ‘로컬 수정’, ‘실행 중인 설정 선택’을 따로 기록하는 것이 핵심입니다. 정상 작동을 확인한 설정 하나를 보관하고 대상 항목만 업데이트한 뒤 전환할 때마다 최종 규칙과 새 연결을 검증하면, 반복해서 삭제하고 다시 가져오는 것보다 문제를 쉽게 찾을 수 있습니다.