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

Profile은 설정 항목이지, 개별 노드가 아닙니다

Clash 클라이언트에서 Profile은 보통 설정 목록에 저장된 설정 항목 하나를 가리킵니다. 구독 링크에서 가져오거나 로컬 YAML 파일을 가져와 만들 수 있습니다. Profile 세 개를 목록에 보관한다고 해서 코어에서 설정 세 개가 동시에 실행되는 것은 아닙니다. 일반적인 데스크톱 클라이언트는 주 설정 하나를 활성화하고, 클라이언트에서 지원하는 오버라이드, 병합 설정 또는 실행 옵션을 추가로 적용합니다.

먼저 ‘설정’, ‘구독’, ‘노드’를 구분해야 합니다. 구독은 설정 내용을 가져오는 경로이고, YAML은 내용을 저장하는 흔한 파일 형식입니다. Profile은 클라이언트에서 이 내용을 관리하는 항목이며, 노드는 설정에 포함된 프록시 아웃바운드 하나입니다. 노드 전환은 보통 특정 프록시 그룹의 선택만 바꾸지만, Profile을 전환하면 규칙, DNS, 수신 포트, 프록시 그룹까지 함께 바뀔 수 있습니다.

여러 설정 이름 짓기: 출처·용도·날짜를 구분해 기록

먼저 서비스 제공자의 업데이트를 받는 원격 설정과 테스트 및 롤백용 로컬 설정을 따로 보관하는 것이 좋습니다. ‘구독 1’, ‘구독 2’처럼 모호하게 이름 짓지 말고, 전체 구독 링크를 표시 이름에 넣지도 마세요. 링크에 포함된 토큰은 계정 권한과 연결될 수 있어 스크린샷을 찍을 때 노출되기 쉽습니다.

설정 세 개의 이름 예시

• 일상-A-원격: 일상적으로 사용하며 기존 구독 출처를 유지하고 클라이언트 설정에 따라 자동 업데이트합니다.
• 예비-B-원격: 예비 회선용으로 출처와 만료 정보를 별도로 보관하며 일상 설정과 섞지 않습니다.
• 테스트-규칙-로컬-20261016: 사용 가능한 설정을 복사해 만든 로컬 사본으로, 규칙 변경 테스트에만 사용합니다.

표시 이름은 YAML의 공통 최상위 필드가 아닙니다. Profile 이름을 바꾸려고 설정에 profile-name을 임의로 추가하지 마세요. 클라이언트의 설정 항목 이름 변경 또는 편집 기능을 사용하세요. 편집 화면에 이름 필드가 없다면 가져오기 전에 알아보기 쉬운 파일명을 사용하면 됩니다.

가져오기와 활성화는 별도 단계입니다

1. 설정 관리 화면을 엽니다. 클라이언트에 따라 ‘설정’, ‘구독’ 또는 ‘Profiles’라고 표시될 수 있으므로 실제 화면을 기준으로 확인하세요.
2. 구독 주소나 로컬 파일을 가져온 뒤 새 항목의 이름, 출처 유형, 업데이트 시간을 먼저 확인합니다.
3. 새 항목을 직접 선택하고 클라이언트에서 로드 성공 알림이 표시될 때까지 기다린 다음 현재 적용 중인 설정 표시를 확인합니다.
4. 프록시 그룹 화면으로 이동해 그룹 이름과 노드 목록이 바뀌었는지 확인합니다. 설정 목록에 표시되는 것만으로는 활성화된 것이 아닙니다.

로컬 파일을 가져오면 보통 클라이언트 데이터 디렉터리에 파일이 복사되지만, 제품에 따라 관리 방식이 다를 수 있습니다. 데스크톱의 원본 파일을 수정해도 클라이언트에 저장된 사본에 반영된다고 볼 수 없습니다. 다시 가져오거나 클라이언트에서 제공하는 ‘파일 편집’ 또는 ‘설정 파일 열기’ 기능으로 실제 관리 파일을 수정하세요.

Profile 전환: 모드, 포트, 프록시 그룹 확인

안전하게 전환하려면 ‘로드 성공 여부’와 ‘트래픽이 예상한 경로를 지나는지’를 모두 확인해야 합니다. 설정에 mode: rule이 있더라도 화면이 반드시 규칙 모드로 동작하는 것은 아닙니다. 일부 클라이언트는 실행 옵션으로 파일의 값을 덮어쓸 수 있습니다. 클라이언트의 현재 상태, 코어 로그, 연결 상세 정보를 함께 확인해 판단하세요.

전환 전후 확인할 네 가지

1. 현재 사용 가능한 설정 백업: 현재 Profile 이름과 주요 프록시 그룹 선택을 기록하고, 필요하면 설정 사본을 내보냅니다.
2. 로드 결과 확인: 로그에서 YAML 파싱 오류, 알 수 없는 필드, 존재하지 않는 프록시 그룹 참조 등이 있는지 살펴봅니다.
3. 트래픽 진입점 확인: 시스템 프록시, TUN, 수신 포트를 확인합니다. 노드 목록만 봐서는 안 됩니다.
4. 새 연결로 확인: 테스트 페이지를 다시 열고 연결 상세 정보에서 매칭된 규칙, 프록시 그룹, 실제 아웃바운드를 확인합니다.

예를 들어 기존 설정의 혼합 포트가 7890이고 새 설정에서 7891로 바뀌었는데 터미널은 여전히 이전 프록시 환경 변수를 사용한다면 연결되지 않을 수 있습니다. 아래는 서로 다른 두 설정의 포트 예시이며, 두 값을 한 파일에 동시에 넣으라는 뜻은 아닙니다.

# 일상 설정의 진입 포트
mixed-port: 7890
mode: rule

# 다른 설정으로 전환한 뒤 진입 포트가 7891로 바뀔 수 있습니다
# mixed-port: 7891

클라이언트가 포트를 고정으로 관리하면 위 파일에 설정된 값이 덮어써질 수도 있습니다. 문제를 확인할 때는 먼저 클라이언트에 표시된 실제 포트를 살펴본 다음 브라우저, 터미널, 개발 도구에서 프록시 주소를 직접 설정했는지 확인하세요. TUN 활성화 여부, 가상 네트워크 인터페이스 생성 여부, 라우트 설치 성공 여부도 각각 확인해야 합니다. Profile 이름만으로는 알 수 없습니다.

구독 업데이트로 변경 사항이 사라질 때: 출처 설정과 개인 설정 분리

원격 Profile에서 다운로드한 내용을 직접 편집하면 보통 다음 업데이트 전까지만 변경 사항이 유지됩니다. 업데이트 시 서비스 제공자의 설정을 다시 가져오면서 로컬 캐시를 교체할 수 있습니다. 직접 추가한 우회 규칙이 사라지거나, 수동으로 바꾼 DNS가 복구되거나, 프록시 그룹 이름이 원래대로 돌아오는 일이 흔합니다.

변경 목적에 따라 저장 위치 선택

예를 들어 intranet.example.com에 직접 연결하려면 다음과 같은 규칙을 사용할 수 있습니다. 도메인은 설명을 위한 예시이므로 실제 내부 도메인으로 바꿔야 합니다. 이 조각만으로는 가져올 수 있는 완전한 설정이 아닙니다.

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

여기서 Proxy는 최종 설정에 이미 정의된 노드 이름이나 프록시 그룹 이름이어야 합니다. Auto 그룹만 포함된 다른 Profile로 전환하면 기존 참조가 작동하지 않을 수 있습니다. 여러 설정에서 오버라이드를 공유하려면 프록시 그룹 이름을 통일하거나 설정별로 오버라이드를 연결해야 합니다. 규칙 텍스트만 복사해서는 안 됩니다.

‘병합’이 자동으로 규칙을 추가한다는 뜻은 아닙니다. 도구에 따라 rules 목록 전체를 교체하거나, 앞이나 뒤에 추가하거나, 스크립트로 처리할 수 있습니다. 규칙은 MATCH 같은 기본 규칙보다 앞에 배치해야 합니다. 뒤에 두면 보통 매칭되지 않습니다. 설정을 마친 뒤 클라이언트가 생성한 실행 설정을 확인해 기존 규칙이 유지되고 순서가 예상대로인지 점검하세요.

두 구독 함께 사용하기: 전환과 통합은 다릅니다

설정 목록에 구독 A와 B를 가져오면 보통 서로 전환할 수 있는 Profile 두 개가 만들어집니다. 두 구독의 노드가 자동으로 하나의 프록시 그룹에 합쳐지지는 않습니다. 예비용 설정만 필요하다면 항목을 따로 보관하는 편이 문제를 확인하기 쉽습니다. 두 구독의 노드를 함께 선택해야 할 때만 노드 제공자나 클라이언트에서 명시적으로 지원하는 통합 기능을 고려하세요.

주 설정과 노드 제공자의 역할

• 주 설정은 proxy-groups, rules, DNS 등 전체 동작을 담당합니다.
• proxy-providers는 호환되는 형식의 노드 목록을 가져오며, 프록시 그룹은 use를 사용해 제공자 이름을 참조합니다.
• 전체 설정 구독을 확인 없이 노드 제공자로 사용할 수는 없습니다. 반환 형식의 지원 여부는 코어와 구독 내용에 따라 달라집니다.

mihomo를 예로 들면 HTTP 유형 노드 제공자의 interval: 3600은 해당 제공자를 3600초 간격으로 업데이트한다는 뜻이지, 클라이언트가 매시간 전체 Profile을 업데이트한다는 뜻은 아닙니다. 제공자 안의 health-check.interval은 상태 확인 간격이며 구독 업데이트 주기가 아닙니다. 클라이언트에서 원격 Profile 자동 업데이트는 별도로 설정하는 경우가 많고, 단위가 분 또는 시간으로 표시될 수도 있습니다.

관리할 때는 다음 세 작업의 시점을 따로 기록하세요. 전체 설정 업데이트, 노드 목록 업데이트, 노드 연결 상태 확인입니다. 이렇게 하면 ‘노드는 바뀌었는데 규칙은 그대로’인 상황에서 제공자만 업데이트된 것인지 먼저 확인할 수 있어 모든 설정을 반복해서 삭제하고 다시 가져올 필요가 없습니다.

설정 백업 및 이전: 원본 파일, 오버라이드, 상태를 각각 저장

실행 중인 YAML 파일 하나만 내보내서는 일상 환경을 완전히 복원하지 못할 수 있습니다. 실행 파일에 오버라이드가 이미 병합되어 원격 구독 주소가 남아 있지 않을 수도 있고, 노드 비밀번호, 구독 토큰, 로컬 수신 설정이 포함될 수도 있습니다. 당시 설정 내용을 복원하는 데는 도움이 되지만 클라이언트 데이터 백업을 대신하지는 않습니다.

백업해 둘 항목

1. 설정 출처: 구독 출처 설명과 Profile 이름을 저장하고, 필요한 경우 구독 링크도 보관합니다. 민감한 링크는 보호된 저장 공간에 두세요.
2. 로컬 YAML: 직접 작성한 설정과 테스트 전의 정상 작동 사본을 보관합니다. 예: daily-local-20261016.yaml.
3. 개인 오버라이드: 규칙, 스크립트, 연결 대상은 별도로 저장하고 처리 순서도 기록합니다.
4. 실행 설정: 포트, 시스템 프록시, TUN, DNS 관련 설정과 클라이언트 및 코어의 실제 버전을 기록합니다.
5. 선택 상태: 자주 쓰는 프록시 그룹의 선택을 기록합니다. 이 상태를 저장하는 위치와 방식은 클라이언트마다 다를 수 있습니다.

이전할 때는 클라이언트에서 제공하는 내보내기 및 복원 기능을 우선 사용하세요. 데이터 디렉터리를 복사해야 한다면 먼저 클라이언트를 종료한 뒤 로컬의 안전한 위치에 복사합니다. 데이터베이스나 상태 파일에 계속 기록 중인 상태에서 복사하지 마세요. 고정 경로를 추측해서는 안 됩니다. 실제 경로는 설치 방식, 포터블 모드, 운영체제에 따라 달라집니다.

복원 후 순서대로 확인

먼저 설정을 가져오고, 오버라이드를 복원한 다음 시스템 프록시나 TUN을 하나씩 활성화합니다. 처음 확인할 때는 필요한 트래픽 진입점 하나만 켜야 문제 원인을 찾기 쉽습니다. 설정 로드, 도메인 확인, 연결이 모두 정상인지 확인한 뒤 자동 업데이트와 백그라운드 시작을 복구하세요.

다른 클라이언트로 이전할 때 YAML의 기본 필드는 재사용할 수 있어도 클라이언트의 설정 색인, 오버라이드 스크립트, 화면 상태는 호환되지 않을 수 있습니다. 다른 코어로 옮긴다면 전용 필드도 확인해야 합니다. 로드에 실패하면 로그에서 문제가 된 필드를 먼저 찾고, 이전 클라이언트의 데이터 디렉터리 전체를 새 클라이언트에 그대로 덮어쓰지 마세요.

자주 묻는 질문: 설정이 있는데 왜 예상대로 동작하지 않을까요?

전환 후 노드는 바뀌었는데 규칙은 왜 그대로인가요?

먼저 두 설정이 원래 같은 규칙을 사용하는지 확인한 다음, 클라이언트에 전역 오버라이드가 있는지 확인하세요. 공통 오버라이드가 rules를 교체한다면 원본 Profile을 전환해도 규칙은 그대로일 수 있습니다. 원본 파일 미리보기가 아니라 최종 실행 설정과 새 연결에서 매칭된 결과를 기준으로 판단하세요.

Profile을 삭제하면 구독 계정도 함께 삭제되나요?

로컬 항목을 삭제해도 보통 클라이언트에 저장된 설정만 영향을 받으며 서비스 제공자 계정은 해지되지 않습니다. 캐시, 연결된 오버라이드, 로컬 사본까지 삭제되는지는 클라이언트의 삭제 안내를 확인하세요. 필요한 내용은 작업 전에 내보내세요. 구독 링크가 유출됐다면 로컬 Profile만 삭제하지 말고 서비스 제공자에게 링크 재설정을 요청해야 합니다.

로컬 설정은 자동으로 바뀌지 않나요?

로컬 파일 자체는 보통 원격 Profile처럼 업데이트되지 않지만, 자동 업데이트되는 proxy-providers 또는 rule-providers를 참조하거나 클라이언트 실행 설정이 추가로 적용될 수 있습니다. 문제를 재현해야 한다면 이러한 외부 출처와 업데이트 시각도 기록하세요. 최상위 YAML만 저장해서는 충분하지 않습니다.

일상적인 관리를 위해 최소한 무엇을 해야 하나요?

롤백용으로 정상 작동하는 설정을 하나 보관하고, 원격 구독과 로컬 테스트 설정을 구분해 이름을 지정하세요. 장기간 유지할 변경은 보존 가능한 오버라이드 계층에 두고, 전환할 때마다 새 연결로 규칙과 아웃바운드를 확인합니다. 첫 가져오기 방법은 구독 가져오기 튜토리얼에서, 필드 간 관계는 YAML 구조 레퍼런스에서 확인할 수 있습니다.