Clash Profile 설정 파일 입문: 가져오기, 전환 및 여러 설정 관리

Profile은 전환 가능한 실행 설정입니다

Clash 클라이언트에서 Profile은 일반적으로 커널이 읽을 수 있는 하나의 설정 파일을 뜻합니다. 보통 YAML 형식을 사용하며, 수신 포트, 프록시 노드, 정책 그룹, 라우팅 규칙, DNS 설정, 프록시 제공자와 규칙 제공자 등을 포함할 수 있습니다. 클라이언트에서 Profile을 선택하면 해당 파일을 해석한 뒤 유효한 설정을 Clash 또는 mihomo 커널에 전달합니다.

Profile은 단일 노드와 같은 의미가 아닙니다. 노드는 설정에 포함된 하나의 연결 항목일 뿐이며, 정책 그룹은 여러 노드나 다른 정책을 묶어 관리합니다. 규칙은 도메인, IP, 프로세스 등의 조건에 따라 요청을 적절한 정책 그룹으로 전달합니다. 노드 전환은 보통 한 정책 그룹에서 현재 선택된 구성원만 바꾸지만, Profile 전환은 노드 목록, 규칙 순서, DNS 모드, 포트, TUN 매개변수까지 함께 바꿀 수 있어 영향 범위가 더 큽니다.

클라이언트마다 Profile을 부르는 방식은 조금씩 다를 수 있습니다. 예를 들어 ‘설정’, ‘구독’, ‘설정 파일’ 또는 ‘Profiles’라고 표시합니다. 메뉴 이름은 달라도 핵심 구조는 거의 같습니다. 클라이언트가 설정 출처를 저장하고, 커널이 현재 설정을 읽으며, 사용자가 정책 그룹에서 실제 연결 경로를 조정합니다.

대상	주요 내용	일반적인 작업
Profile	포트, DNS, 노드, 정책 그룹 및 규칙	가져오기, 업데이트, 전환, 복사
정책 그룹	여러 프록시 노드 또는 내장 정책	수동 선택, 자동 테스트, 장애 조치
노드	서버 주소, 포트 및 프로토콜 매개변수	지연 시간 테스트, 연결 경로 선택
규칙	요청 매칭 조건 및 대상 정책	순서 조정, 도메인 또는 규칙 집합 추가

설정 출처가 업데이트 방식을 결정합니다

일반적인 Profile 출처는 세 가지입니다. 구독 주소로 가져오기, 로컬 YAML 파일에서 가져오기, 클라이언트에서 직접 만들거나 복사해 관리하기입니다. 출처에 따라 이후 업데이트 방식도 달라집니다. 여러 설정 체계를 만들기 전에 각 설정이 원격 관리인지 로컬 관리인지 먼저 확인해야 합니다.

구독 주소로 가져오기

구독 주소는 원격 설정 내용을 반환합니다. 클라이언트는 보통 이 주소를 저장하고 수동 새로고침 또는 설정된 주기에 따른 업데이트를 지원합니다. 새로고침하면 클라이언트가 원격 내용을 다시 요청한 뒤 해당 캐시 버전을 새 내용으로 교체합니다. 로컬 수정 내용을 보존하는지는 클라이언트 구현에 따라 다르므로, 새로고침으로 덮어써질 원격 설정을 장기간 직접 수정해서는 안 됩니다.

구독 주소에는 계정 식별 정보가 포함될 수 있으므로 민감한 인증 정보처럼 관리해야 합니다. 주소를 공개 스크린샷, 공개 코드 저장소, 공유 문서 또는 오류 로그에 남기지 마세요. 다른 기기에 가져와야 한다면 신뢰할 수 있는 경로로 전달하고, 더 이상 사용하지 않는 기기에서는 해당 설정을 삭제하세요.

로컬 YAML 파일 가져오기

로컬 파일은 테스트, 직접 만든 규칙, 오프라인 백업에 적합합니다. 일부 클라이언트는 파일 내용을 자체 설정 디렉터리에 복사하므로 원본 파일을 수정해도 자동으로 동기화되지 않습니다. 반대로 지정된 경로를 직접 참조하는 클라이언트도 있습니다. 가져온 뒤 식별하기 쉬운 설명 필드나 규칙을 하나 수정하고 다시 불러와, 클라이언트가 복사본과 원본 경로 중 무엇을 실제로 읽는지 확인하세요.

설정을 직접 만들거나 복사하기

기존 Profile을 복사한 뒤 조정하는 방식은 안정 버전을 보존하면서 새 규칙을 테스트할 때 유용합니다. 예를 들어 ‘일상 안정’ 설정을 복사해 ‘DNS 테스트’를 만들고 DNS와 관련 규칙만 수정할 수 있습니다. 테스트가 끝나면 변경 사항을 장기 사용 설정에 반영할지 결정하세요. 이렇게 하면 유일하게 사용할 수 있는 설정을 반복해서 직접 편집하는 일을 피할 수 있습니다.

Profile 전환 후 단계별로 적용 상태를 확인하세요

화면에서 Profile을 선택했다는 것은 클라이언트가 해당 설정을 사용하려고 준비한다는 뜻일 뿐입니다. 실제 적용 여부는 설정 해석, 커널 실행, 시스템 트래픽 진입점이라는 세 단계로 확인해야 합니다. 안정적인 전환 순서는 현재 작업 저장, 대상 Profile 선택, 해석 완료 대기, 정책 그룹 상태 확인, 시스템 프록시 또는 TUN 점검입니다.

대상 설정 선택: Profile 목록에서 사용할 항목을 선택하고 현재 표시가 대상 설정으로 이동했는지 확인하세요.
로드 결과 확인: 클라이언트에 YAML 문법 오류, 필드 호환성 문제, 포트 충돌 또는 프록시 제공자 다운로드 실패 메시지가 표시되는지 확인하세요.
정책 그룹 확인: 주요 정책 그룹이 존재하는지 확인하고 현재 노드를 계속 사용할 수 있는지 살펴보세요. 설정마다 이름이 같은 정책 그룹에 완전히 다른 노드가 들어 있을 수도 있습니다.
실행 모드 확인: Rule, Global 또는 Direct 모드를 확인하세요. 일반적인 일상 라우팅에는 Rule을 사용하고, Global은 대부분의 요청을 전역 정책으로 전달하며, Direct는 직접 연결합니다.
트래픽 진입점 확인: 브라우저처럼 시스템 프록시를 따르는 프로그램은 시스템 프록시가 올바른 상태여야 합니다. 시스템 프록시를 읽지 않는 프로그램은 보통 TUN 또는 애플리케이션 자체의 프록시 설정이 필요합니다.
접속 확인 실행: 직접 연결 대상, 프록시 대상, DNS 해석을 각각 테스트하세요. 노드 지연 시간만으로 설정이 완전히 적용되었다고 판단하지 마세요.

수신 포트가 다른 Profile로 전환할 때는 시스템 프록시에 저장된 포트도 일치해야 합니다. 예를 들어 이전 설정이 mixed-port: 7890을 사용하고 새 설정이 mixed-port: 7897로 바뀌었는데 시스템이 계속 이전 포트를 가리키면 애플리케이션이 연결되지 않을 수 있습니다. 일부 클라이언트는 시스템 프록시 포트를 자동으로 동기화하지만, 전환 후 한 번 직접 확인하는 것이 좋습니다.

mixed-port: 7890
mode: rule
allow-lan: false

dns:
  enable: true
  ipv6: false
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

이 예시는 설정 계층만 보여 주며 완전한 Profile이 아닙니다. 실제 설정은 사용하는 커널 버전, 노드 프로토콜, 규칙 구조, 로컬 네트워크 환경에 맞아야 합니다. YAML은 공백으로 계층을 표현하므로 Tab 문자, 잘못된 들여쓰기 또는 중복 필드로 인해 로드가 실패할 수 있습니다.

여러 설정은 용도·출처·상태를 기준으로 이름을 정하세요

설정 수가 늘어나면 가장 흔한 문제는 파일이 사라지는 것이 아니라 어떤 설정을 사용 중인지, 어떤 설정을 업데이트할 수 있는지 판단하기 어려워지는 것입니다. ‘설정 1’, ‘새 설정’, ‘최종본’ 같은 이름만 사용하면 장애 발생 시 빠르게 되돌리기 어렵습니다. 이름에는 최소한 용도와 출처를 포함하고, 필요하면 상태나 날짜도 덧붙이세요.

이름 예시	용도	관리 방식
일상-원격 구독	일반적인 웹 이용 및 규칙 기반 라우팅	주기적으로 새로고침
일상-안정 백업	원격 업데이트 오류 발생 시 복구	로컬 저장, 자동 업데이트 안 함
개발-TUN	명령줄 및 시스템 프록시를 읽지 않는 애플리케이션	TUN 매개변수 로컬 관리
규칙 테스트-임시	새 규칙 및 DNS 변경 확인	테스트 후 보관 또는 삭제

일상적인 사용에서는 중복 사본을 많이 보관할 필요가 없습니다. 주로 사용하는 원격 설정 하나, 검증이 끝난 로컬 안정 백업 하나, 상황별 테스트 설정 몇 개면 대부분의 전환과 복구 요구를 충족할 수 있습니다. 사본이 너무 많으면 정책 그룹 선택, 업데이트 시점, 구독 출처가 뒤섞일 수 있습니다.

시스템 프록시 설정과 TUN 설정을 구분하세요

시스템 프록시는 주로 운영체제의 프록시 설정을 따르는 애플리케이션에 영향을 주며 구조가 비교적 단순합니다. TUN 모드는 가상 네트워크 인터페이스를 만들고 더 넓은 범위의 트래픽을 가로채며, 라우팅·DNS 가로채기·인터페이스 자동 감지·권한까지 관련됩니다. 두 모드를 자주 전환한다면 Profile을 별도로 관리해 여러 매개변수를 매번 수동으로 바꾸지 않도록 하세요.

mihomo 커널을 사용할 때 TUN 설정에는 stack, auto-route, auto-detect-interface 및 DNS 가로채기와 같은 필드가 포함될 수 있습니다. 지원 여부는 커널 버전, 운영체제, 클라이언트 권한에 따라 달라집니다. 한 플랫폼에 맞는 TUN 구간을 다른 플랫폼에 그대로 복사하면 인터페이스 선택 오류, 로컬 네트워크 접속 문제 또는 DNS 경로 변경이 발생할 수 있습니다.

검증된 복구 지점을 하나 남겨 두세요

안정 백업은 방금 다운로드했지만 아직 사용하지 않은 파일이 아니라 실제로 정상 실행된 설정에서 만들어야 합니다. 백업할 때 내보낸 날짜, 커널 종류, 적용 환경을 기록하세요. 구독 내용 이상, 규칙 제공자 접속 불가, 새 버전 필드 비호환이 발생하면 먼저 안정 설정으로 돌아가 연결을 복구한 뒤 업데이트 내용을 따로 점검할 수 있습니다.

구독 업데이트와 로컬 수정은 계층을 나누어 관리하세요

원격 구독은 노드, 정책 그룹, 규칙을 출처 제공자가 일괄 업데이트할 수 있다는 장점이 있지만, 새로고침 시 해당 Profile에 직접 기록한 변경 사항이 덮어써질 수 있습니다. 업데이트와 사용자 지정을 함께 관리하려면 ‘원격 생성 내용’과 ‘로컬 개인 설정’을 분리해야 합니다.

방법 1: 클라이언트 오버라이드 기능 사용

일부 클라이언트는 오버라이드, 믹스인 또는 스크립트 처리를 지원합니다. 원격 설정을 다운로드한 뒤 지정된 필드를 추가하거나 수정하는 방식입니다. 예를 들어 포트를 일괄 조정하고, 로컬 네트워크 접속을 활성화하며, 규칙을 추가하거나 DNS 설정을 바꿀 수 있습니다. 오버라이드 문법은 모든 Clash 클라이언트가 공유하는 표준이 아니므로 클라이언트를 옮기기 전에 형식을 내보내 확인해야 합니다.

방법 2: proxy-providers와 rule-providers 사용

mihomo는 프록시 제공자와 규칙 제공자를 통해 외부 콘텐츠를 분리해 관리할 수 있습니다. 기본 설정은 포트, DNS, 정책 그룹, 규칙 순서를 담당하고, 제공자는 URL 또는 파일 경로를 통해 노드와 규칙 집합을 불러옵니다. 따라서 기본 설정 전체를 교체하지 않고 외부 데이터만 업데이트할 수 있습니다.

proxy-providers:
  remote-nodes:
    type: http
    url: "https://example.invalid/subscription"
    path: ./providers/remote-nodes.yaml
    interval: 3600
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 600

proxy-groups:
  - name: PROXY
    type: select
    use:
      - remote-nodes

예시 주소는 해석되지 않는 예약 도메인을 사용하며 구조를 보여 주기 위한 용도입니다. 실제로 사용할 때는 유효한 출처를 입력하고 반환 내용이 프록시 제공자 형식에 맞는지 확인해야 합니다. 완전한 구독 설정과 provider 파일의 구조는 서로 다를 수 있으므로, 임의의 구독 주소를 proxy-providers에 넣기만 하면 해석될 것이라고 가정해서는 안 됩니다.

방법 3: 완전한 로컬 설정 관리

규칙 순서, DNS 경로, TUN 동작을 정밀하게 제어해야 한다면 완전한 로컬 YAML을 관리하면서 노드 부분을 수동으로 업데이트할 수 있습니다. 제어 범위가 명확한 대신 관리 비용도 높습니다. 수정할 때마다 먼저 설정을 검사한 뒤 현재 Profile로 전환해야 하며, 검증하지 않은 파일로 안정 버전을 바로 대체해서는 안 됩니다.

가져오기 실패 및 전환 이상 문제 해결 경로

Profile 문제는 ‘출처 가져오기—파일 해석—커널 실행—시스템 트래픽 처리—규칙 매칭’ 순서로 점검할 수 있습니다. 단계별로 원인을 좁히는 편이 반복해서 삭제하고 다시 가져오는 것보다 효과적이며, 오류 상황도 보존할 수 있습니다.

구독을 가져온 뒤 목록이 비어 있음

구독 주소가 여전히 유효한지 확인하고, 클라이언트에 HTTP 상태 코드나 시간 초과 정보가 표시되는지 살펴보세요.
반환된 내용이 Clash에서 읽을 수 있는 YAML인지 확인하세요. 로그인 페이지, 오류 메시지 또는 다른 클라이언트 전용 형식일 수 있습니다.
시스템 시간을 확인하세요. 시스템 시간이 크게 틀리면 인증서 검증, 구독 유효 기간, 원격 요청에 영향을 줄 수 있습니다.
현재 네트워크에서 구독 출처에 접속할 수 없다면 먼저 기존의 안정적인 Profile로 연결을 만든 뒤 업데이트를 실행하세요.

설정을 가져올 수 있지만 전환할 수 없음

로그에서 구체적인 필드와 줄 번호를 확인하고 YAML 들여쓰기, 배열 형식, 중복 키를 중점적으로 점검하세요.
설정에서 사용하는 필드가 현재 커널에서 지원되는지 확인하세요. mihomo용 확장 필드를 구버전 Clash 커널이 반드시 받아들일 수 있는 것은 아닙니다.
수신 포트가 다른 프로그램이나 다른 커널 인스턴스에서 이미 사용 중인지 확인하세요.
규칙이 참조하는 정책 그룹이 존재하는지 확인하세요. 이름의 대소문자와 문자가 정확히 일치해야 합니다.
외부 provider 파일이 정상적으로 다운로드되었는지, 경로에 쓸 수 있는지, 내용 형식이 해당 유형에 맞는지 확인하세요.

전환은 성공했지만 접속 경로가 바뀌지 않음

클라이언트 화면의 현재 Profile 표시가 바뀌었는지 확인하고 커널이 다시 로드를 완료했는지 점검하세요.
시스템 프록시 주소가 새 Profile의 수신 포트와 일치하는지 확인하세요.
현재 실행 모드가 Direct가 아닌지 확인하고 대상 요청이 최종적으로 어떤 규칙에 매칭되었는지 점검하세요.
TUN을 사용할 때는 가상 인터페이스, 라우팅, 권한 상태를 확인하세요. TUN을 끈 뒤 남아 있는 시스템 프록시도 별도로 점검해야 합니다.
브라우저나 애플리케이션이 기존 연결을 재사용할 수 있습니다. 전환 후 관련 연결을 닫거나 애플리케이션을 다시 시작한 다음 테스트하세요.

반복 가능한 일상 설정 절차 만들기

관리하기 쉬운 절차는 가져오기, 이름 지정, 확인, 활성화, 테스트, 백업의 여섯 단계로 정리할 수 있습니다. 처음 가져올 때 출처와 용도를 기록하고, 로드 전에 문법과 호환성을 점검하세요. 활성화한 뒤 정책 그룹, DNS, 규칙 매칭, 트래픽 진입점을 각각 확인하고, 안정성이 검증되면 로컬 복구 버전을 만드세요.

원격 설정을 업데이트할 때는 노드 수가 바뀌었는지만 확인해서는 안 됩니다. 주요 정책 그룹 이름, 규칙 순서, DNS 모드, 수신 포트도 점검해야 합니다. 이러한 항목은 클라이언트의 기존 선택과 시스템 설정에 직접 영향을 줍니다. 업데이트 후 문제가 생기면 먼저 검증된 Profile로 되돌린 뒤 두 설정의 구조적 차이를 비교하세요.

자주 외근하거나 네트워크 환경을 바꾸는 기기라면 ‘가정용 시스템 프록시’, ‘모바일 네트워크 TUN’, ‘개발 환경 로컬 규칙’처럼 상황별 설정을 보관할 수 있습니다. 각 설정은 명확한 용도 하나만 맡기고, 일관된 이름 규칙을 공유하세요. 그러면 네트워크가 바뀔 때 많은 필드를 임시로 수정하는 대신 검증된 환경으로 전환하면 됩니다.

Profile 관리의 핵심은 파일을 더 많이 쌓는 것이 아니라 각 설정의 출처, 업데이트 방식, 적용 환경, 복구 관계를 판단할 수 있게 하는 것입니다. 원격 구독과 로컬 수정을 계층별로 나누고, 노드 선택과 전체 설정 전환을 구분한 뒤, 정해진 순서로 적용 상태를 확인하면 여러 설정도 명확하게 관리할 수 있습니다.