Clash Profile이란? 여러 설정 전환, 로컬 파일 및 구독 자동 업데이트 관리

Profile과 config.yaml: 설정 항목과 실행 설정의 차이

Profile은 일반적으로 클라이언트에 저장된 설정 항목 하나를 가리킵니다. 구독 URL에서 가져오거나 로컬 YAML 파일을 가져와 만들 수 있습니다. 설정 내용 외에도 클라이언트가 항목 이름, 출처 URL, 업데이트 시간과 간격, 로컬 처리 규칙을 저장할 수 있습니다. Profile은 클라이언트에서 설정을 관리하는 개념이며, YAML 최상위에 반드시 작성해야 하는 필드는 아닙니다.

config.yaml은 흔히 사용하는 설정 파일 이름입니다. 커널이 실제로 읽는 것은 설정 내용과 실행 시 지정된 파일 경로이며, 모든 설정 파일의 이름이 이와 같을 필요는 없습니다. 클라이언트에는 Profile을 여러 개 저장할 수 있지만, 커널 실행 인스턴스 하나는 보통 최종 설정 하나만 불러옵니다. 다른 Profile을 선택하면 클라이언트가 새로운 실행 설정을 생성하거나 불러옵니다.

대상	저장되는 내용	수정 시 영향
원격 Profile	구독 URL, 다운로드한 YAML, 업데이트 설정	다음 업데이트에서 다운로드한 내용으로 바뀔 수 있음
로컬 Profile	로컬에서 가져오거나 만든 설정 내용	일반적으로 노드와 규칙을 직접 관리해야 함
실행 설정	원본 설정과 클라이언트 덮어쓰기 설정을 합친 결과	직접 수정해도 다시 불러올 때 반영되지 않을 수 있음
클라이언트 환경설정	시스템 프록시, 인터페이스 설정, 일부 TUN 스위치 등	Profile을 바꿔도 유지될 수 있음

따라서 “파일을 수정했는데 포트가 바뀌지 않았다”고 해서 반드시 저장에 실패한 것은 아닙니다. 클라이언트가 자체 설정으로 mixed-port 값을 덮어쓰고 있거나 다른 Profile을 사용 중일 수 있습니다. 문제를 확인할 때는 먼저 현재 선택된 항목을 확인한 뒤, 클라이언트가 제공하는 최종 설정이나 시작 로그를 살펴보세요.

로컬 파일과 구독 설정: 관리 출처에 따른 구분

원격 Profile: 구독 업데이트 유지

구독 URL에서 반환되는 내용은 사용 중인 커널이 지원하는 형식이어야 합니다. Clash YAML을 지원하는 구독에는 보통 노드, 프록시 그룹, 규칙이 포함됩니다. 노드 목록만 제공하는 구독은 완전한 설정을 바로 대체할 수 없습니다. URL은 설정을 가져오는 경로일 뿐, 응답이 곧바로 불러올 수 있는 YAML이라는 뜻은 아닙니다.

원격 Profile은 노드 변경을 계속 반영해야 할 때 적합합니다. 다운로드한 사본에 규칙을 직접 추가하면 현재 로컬 파일에만 적용되며, 다음 구독 업데이트에서 파일 전체가 다시 기록될 수 있습니다. 일부 클라이언트는 수정한 결과를 별도로 저장하지만, 실제 동작은 업데이트를 한 번 시험해 확인해야 합니다. 파일 이름만 보고 판단하지 마세요.

로컬 Profile: 고정 사본과 독립 테스트

원격 설정을 로컬 파일로 내보낸 뒤 새 항목으로 가져오면 별도의 사본을 만들 수 있습니다. 규칙 문제를 확인하거나 DNS를 시험하거나 장애 발생 전 상태를 보관할 때 유용합니다. 다만 주 구독에서 노드 이름, 주소 또는 인증 정보가 바뀌어도 로컬 사본에는 보통 자동 반영되지 않습니다.

실제로 관리할 때는 “일상용 원격 항목”과 “문제 확인용 로컬 사본”을 함께 보관하는 편이 좋습니다. 원격 항목은 업데이트를 받고, 로컬 사본은 문제를 확인하거나 변경 사항을 시험할 때만 사용하세요. 하나의 설정에 두 가지 관리 방식을 섞지 않는 것이 좋습니다.

여러 설정의 이름 지정과 전환: 한 번에 변수 하나만 변경

출처·용도·날짜를 이름에 포함

파일 이름은 출처를 식별하는 용도로 사용하고 구독 키는 넣지 않는 것이 좋습니다. 다음 예시처럼 이름을 지정하면 원격 항목과 고정 사본을 쉽게 구분할 수 있습니다. 날짜는 백업을 만든 날이며 구독 만료일이 아닙니다.

remote-main: 주 구독으로, 일상적으로 사용하며 정기 업데이트를 허용합니다.
remote-backup: 백업 구독으로, 사용 전에 유효한지 직접 확인합니다.
local-main-2026-09-30.yaml: 해당 날짜에 만든 주 설정의 로컬 사본입니다.
local-dns-test-2026-09-30.yaml: DNS 매개변수를 비교할 때만 사용하는 테스트 설정입니다.

전환 전후에 확인할 여섯 단계

클라이언트마다 메뉴 이름이 “설정”, “Profiles” 또는 “구독”으로 다를 수 있습니다. 특정 클라이언트의 메뉴 이름을 모든 버전에 그대로 적용하지 않고, 작업 대상에 따라 설명합니다.

현재 상태를 기록합니다. 사용 중인 Profile, 규칙 모드, 선택된 노드, 시스템 프록시와 TUN 스위치 상태를 적어 두세요. 문제를 재현할 때는 파일 이름보다 이 정보가 더 중요합니다.
현재 사용 가능한 설정을 백업합니다. 항목의 내보내기 또는 복사 기능으로 YAML을 저장하고, 사용 중인 커널 이름과 버전도 기록하세요.
먼저 가져온 다음 활성화합니다. 새 파일을 설정 목록에 추가하고 클라이언트의 설정 검사를 먼저 실행하세요. 알 수 없는 필드가 표시되면 커널 호환성을 확인합니다.
대상 Profile을 선택합니다. 로딩이 끝나면 로그에서 파싱 오류, 프록시 그룹 참조 오류 또는 포트 바인딩 실패가 있는지 확인하세요.
실제 적용된 정책을 확인합니다. 규칙 모드가 원하는 상태인지, 프록시 그룹이 예상치 못한 기본 노드로 돌아가지 않았는지, 시스템 프록시 포트가 실행 설정과 일치하는지 확인하세요.
새 연결로 테스트합니다. 대상 페이지를 새로 열고 연결 목록에서 적용된 규칙과 출구를 확인하세요. 기존 다운로드 작업만 지켜봐서는 전환 결과를 판단하기 어렵습니다.

설정을 전환할 때 기존 연결을 처리하는 방식은 클라이언트와 커널에 따라 다릅니다. 기존 연결이 이전 출구를 계속 사용할 수도 있고, 다시 불러오는 과정에서 끊길 수도 있습니다. 새 규칙이 적용됐는지 확인하려면 새 요청을 보내세요. 중요한 데이터 전송 중이라면 작업이 끝난 뒤 설정을 전환하는 것이 좋습니다.

구독 자동 업데이트: 클라이언트와 리소스의 업데이트 주기를 따로 확인

전체 Profile 구독 업데이트는 보통 클라이언트에서 관리합니다. 업데이트 메뉴는 대개 해당 항목의 편집 화면이나 전체 구독 설정에 있습니다. 먼저 수동 업데이트로 다운로드와 파싱이 되는지 확인한 뒤 자동 업데이트를 켜면 네트워크 문제와 예약 실행 문제를 구분하기 쉽습니다.

간격을 설정할 때 단위를 확인

단위가 분이라면 360은 6시간, 1440은 24시간입니다. 단위가 시간이라면 각각 6 또는 24를 입력해야 합니다. 이는 간격 환산 예시이며 모든 클라이언트의 기본값은 아닙니다. 다른 클라이언트의 화면에 나온 숫자를 그대로 입력하지 마세요.

짧은 시간에 반복 요청하지 않도록 구독 제공자가 안내하는 업데이트 주기를 먼저 확인하세요.
컴퓨터가 절전 모드에 들어가거나 앱을 종료했거나 모바일 운영체제가 백그라운드 활동을 제한하면 예약 작업이 늦어질 수 있습니다. “6시간마다” 설정해도 매번 정각에 실행되는 것은 아닙니다.
업데이트가 완료된 뒤 현재 Profile이 자동으로 다시 불러와지는지 확인하세요. 일부 클라이언트는 캐시만 업데이트하므로 항목을 다시 선택하거나 새로고침해야 합니다.
업데이트에 실패하면 시간과 오류 유형을 기록한 뒤 네트워크, 구독 유효 기간, 서버 응답과 반환 내용을 확인하세요.

provider의 interval과 혼동하지 마세요

해당 필드를 지원하는 Clash 또는 Clash Meta(mihomo) 커널에서는 HTTP 유형의 proxy-providers와 rule-providers에 interval을 설정할 수 있습니다. 단위는 보통 초입니다. 예를 들어 interval: 86400은 해당 리소스를 24시간마다 업데이트한다는 뜻입니다. 이 설정은 리소스 업데이트 주기만 제어하며 Profile 구독 URL 전체를 자동으로 새로고침하지 않습니다.

마찬가지로 profile.store-selected는 프록시 그룹 선택 상태를 저장하는 옵션이지 구독 예약 기능이 아닙니다. 이 옵션을 지원하는 커널에서 profile.store-fake-ip는 Fake-IP 매핑 저장과 관련된 설정이지 여러 설정을 나열하는 목록이 아닙니다. 클라이언트의 Profile 목록과 YAML의 profile 필드는 서로 다른 계층에 속합니다.

로컬 규칙 유지: 오버레이, 리소스 분리, 전체 사본

구독 자동 업데이트를 유지하면서 사용자 지정 규칙을 보존하려면 클라이언트에서 공식 지원하는 덮어쓰기, 병합 또는 스크립트 기능을 우선 사용하세요. 이런 기능은 구독 내용이 업데이트된 뒤 로컬 변경 사항을 적용하기 위한 것입니다. 기능 이름과 실행 순서, 문법은 클라이언트마다 다르므로 특정 덮어쓰기 파일을 일반 Clash 설정처럼 가져오면 안 됩니다.

규칙 삽입 위치에 따라 일치 여부가 달라집니다

rules는 순서대로 규칙을 적용합니다. 사용자 지정 규칙을 MATCH 뒤에 두면 보통 처리되지 않습니다. 반대로 규칙 목록 전체를 교체하면 구독에 포함된 기존 트래픽 분기 로직이 사라질 수 있습니다. 작업 전에 도구가 “앞에 삽입”, “추가”, “전체 교체” 중 어떤 방식으로 처리하는지 확인하고, 최종 실행 설정에서 결과를 검토하세요.

아래는 Profile 전환과 포트, 규칙 순서를 확인하기 위한 독립형 최소 로컬 예시 설정입니다. 직접 연결과 거부 정책만 제공하며 원격 프록시 노드는 포함하지 않으므로 구독 설정을 대체할 수 없습니다.

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

proxy-groups:
  - name: LocalChoice
    type: select
    proxies:
      - DIRECT
      - REJECT

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

활성화하면 example.com과 하위 도메인으로 향하는 새 연결은 먼저 직접 연결 규칙과 일치합니다. 그 밖의 연결은 LocalChoice로 전달됩니다. 같은 기기의 다른 프로세스가 이미 7890을 사용 중이면 포트를 바인딩하지 못할 수 있습니다. 클라이언트에서 전체 포트 덮어쓰기를 켰다면 실제 포트는 화면과 로그를 기준으로 확인하세요.

규칙은 직접 관리하고 노드만 업데이트하려면 고정된 주 설정에 노드 provider를 연결하는 방법도 있습니다. 단, 사용 중인 커널이 이 기능을 지원하고 원격 응답이 provider 형식에 맞으며 프록시 그룹에서 해당 리소스를 올바르게 참조해야 합니다. 전체 구독을 가져오는 것보다 복잡하므로 설정 간 참조 관계를 이해하는 사용자에게 적합합니다.

백업과 롤백: 원본과 실행 환경을 함께 보관

백업에 포함할 항목

설정 내용: 사용할 수 있는 YAML을 저장하고 구독 원본과 병합된 실행 설정을 구분합니다.
로컬 덮어쓰기: 덮어쓰기·병합·스크립트 파일을 별도로 저장하고, 어떤 Profile에 연결했는지 기록합니다.
실행 환경: 클라이언트와 커널 버전, 포트, 모드, TUN 상태를 기록합니다.
참조 리소스: 오프라인으로 복원할 때 외부 규칙 집합, 노드 provider와 지리 데이터베이스를 사용할 수 있는지도 확인해야 합니다.

큰 폭으로 수정하기 전에는 날짜가 포함된 스냅샷을 저장하고, 정상 작동을 확인한 설정을 최소 한 개 보관하세요. 클라이언트가 임시로 생성한 실행 파일만 백업하지 마세요. 시스템별 경로가 들어 있을 수 있고 다음 실행 때 다시 생성될 수도 있습니다. 클라이언트 관리 데이터를 내보낼 때는 로컬 덮어쓰기 설정과 구독 URL이 포함되는지도 확인하세요.

“설정, 덮어쓰기, 상태” 순서로 롤백

문제가 발생한 항목의 자동 업데이트를 일시적으로 끄고, 이후 비교할 수 있도록 오류가 난 설정은 보관하세요.
정상 작동이 확인된 로컬 스냅샷을 가져온 뒤 문법을 검사하고 활성화하세요.
새로 추가한 덮어쓰기 계층을 일시 중지해 이전 스냅샷이 같은 잘못된 규칙으로 다시 수정되지 않도록 하세요.
기존 규칙 모드와 프록시 그룹 선택, 프록시 연결 방식을 복원한 뒤 새 연결로 테스트하세요.
정상적으로 복원됐는지 확인하고 변경 사항을 하나씩 다시 적용하세요. 원격 내용이 정상임을 확인한 뒤 자동 업데이트를 다시 켭니다.

자주 묻는 문제: 전환이 적용되지 않음, 노드 변경, 업데이트로 인한 덮어쓰기

Profile을 전환했는데 시스템 프록시가 바뀌지 않는 이유는 무엇인가요?

Profile을 전환하면 보통 커널 설정이 바뀌지만 운영체제의 프록시 설정까지 다시 쓰는 것은 아닙니다. 시스템 프록시가 여전히 127.0.0.1:7890을 가리키는데 새 설정은 7891에서 수신 대기한다면 앱이 연결되지 않을 수 있습니다. 시스템 프록시 포트를 클라이언트가 실제로 사용하는 수신 포트와 일치시키고, 해당 앱이 시스템 프록시를 사용하는지도 확인하세요.

전환 후 노드 선택이 기본값으로 돌아가는 이유는 무엇인가요?

선택 상태는 커널이나 클라이언트에 캐시될 수 있습니다. 새 설정에서 프록시 그룹이나 노드 이름이 바뀌거나 기존 노드가 삭제되면 이전 선택 항목을 찾을 수 없습니다. 선택 저장 옵션을 켰더라도 구독을 업데이트한 뒤 주요 프록시 그룹을 확인하세요. 이름 변경을 노드 연결 오류와 혼동하지 마세요.

구독 업데이트는 성공했는데 사용자 지정 규칙이 사라진 이유는 무엇인가요?

먼저 변경 사항을 원격 다운로드 사본에 작성했는지 확인하세요. 해당 파일을 업데이트하면서 내용이 덮어써지는 것은 원격 항목에서 일반적으로 발생하는 동작입니다. 오래 유지해야 하는 변경 사항은 지원되는 로컬 덮어쓰기 계층으로 옮긴 뒤 수동 업데이트를 한 번 실행해 최종 규칙 순서를 확인하세요. 클라이언트에 덮어쓰기 기능이 없다면 별도의 로컬 사본을 사용하고 수동으로 관리해야 합니다.

설정 두 개를 동시에 적용할 수 있나요?

같은 커널 실행 인스턴스에서는 일반적인 Profile 전환으로 현재 설정 하나를 선택합니다. 설정 파일 두 개를 자동으로 합치는 기능이 아닙니다. 노드나 규칙을 조합해야 한다면 명시적인 병합 로직이나 provider 참조를 사용해야 합니다. 설정 조각의 적용 순서와 같은 이름의 프록시 그룹 처리, 포트 설정을 모두 확인해야 하며, 파일 두 개를 동시에 선택했다고 병합된다고 가정해서는 안 됩니다.

일상적인 관리는 세 가지로 정리할 수 있습니다. 원격 항목은 업데이트를 맡고, 로컬 덮어쓰기는 변경 사항을 보존하며, 날짜가 포함된 스냅샷은 롤백에 사용합니다. 한 번에 한 계층만 변경한 뒤 새 연결로 결과를 확인하면 설정이 바뀐 원인을 찾기 쉽습니다. 필드와 참조 관계는 고급 설정에서, 처음 가져오는 방법은 입문 가이드에서 확인하세요.