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

PROFILE / 01

Profile에는 무엇이 저장되나요

Clash 그래픽 클라이언트에서 Profile은 일반적으로 코어가 읽을 수 있는 하나의 설정을 뜻합니다. 원격 구독 주소에서 가져올 수도 있고, 직접 가져온 로컬 YAML 파일일 수도 있습니다. 클라이언트는 Profile의 다운로드, 저장, 전환 및 업데이트를 담당하며, Clash 또는 mihomo 코어는 현재 활성화된 설정에 따라 수신 포트를 만들고 노드를 불러오며 프록시 그룹을 구성하고 규칙에 따라 연결을 처리합니다.

클라이언트마다 Profile을 표시하는 한국어 명칭은 완전히 같지 않습니다. 흔히 “설정”, “설정 파일”, “구독” 또는 “Profiles”로 표시됩니다. 이름은 달라도 기본 구조는 비슷합니다. 설정 목록에는 여러 파일을 저장할 수 있지만, 한 번에 코어에서 실행되는 주 설정은 보통 하나뿐입니다. 항목을 전환하는 것은 단순히 노드만 바꾸는 일이 아닙니다. 포트, DNS, 프록시 그룹, 규칙, TUN 매개변수가 함께 바뀔 수 있습니다.

구성 요소	주요 역할	전환 시 영향
`proxies`	연결 가능한 프록시 노드 정의	설정에 따라 노드 목록 변경
`proxy-groups`	수동 선택, 자동 테스트 및 장애 조치 전략 구성	프록시 그룹 이름과 선택 항목이 다시 구성될 수 있음
`rules`	도메인, IP 또는 프로세스에 적용할 정책 결정	트래픽 분기 결과가 즉시 변경됨
`dns`	DNS 수신, 해석 모드 및 상위 서버 제어	도메인 해석 경로가 변경될 수 있음
`mixed-port`	HTTP 및 SOCKS5 혼합 프록시 포트 제공	시스템 프록시 포트를 함께 변경해야 할 수 있음
`tun`	가상 네트워크 어댑터의 트래픽 인계 방식 구성	네트워크 인터페이스가 다시 생성될 수 있음

간소화한 설정으로 이러한 구성 요소의 관계를 확인할 수 있습니다. 실제 구독에는 보통 더 많은 노드와 규칙이 포함되며, 지원되는 필드 범위는 사용하는 코어 버전에 따라 달라집니다.

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

proxies:
  - name: example-node
    type: socks5
    server: 192.0.2.10
    port: 1080

proxy-groups:
  - name: 노드 선택
    type: select
    proxies:
      - example-node
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,노드 선택
  - MATCH,DIRECT

SOURCE / 02

구독 설정과 로컬 설정의 차이

원격 구독 Profile은 하나의 구독 주소에서 제공됩니다. 클라이언트에 주소를 저장하면 필요할 때나 예약된 시간에 설정을 다시 다운로드할 수 있습니다. 업데이트된 내용은 보통 클라이언트 캐시에 저장된 이전 버전을 대체하므로, 다음에 불러올 때 노드 추가·삭제, 프록시 그룹 조정 및 규칙 변경이 적용됩니다. 구독 주소에는 접근 인증 정보가 포함되는 경우가 많으므로 비밀번호처럼 취급하고 공개 스크린샷, 로그 또는 문의 글에 붙여 넣지 마세요.

로컬 Profile은 기기에 저장된 YAML 파일에서 가져옵니다. 직접 작성한 규칙, 고정 포트, 실험적인 DNS 설정을 보관하거나 문제 진단용 최소 설정으로 사용하기 좋습니다. 로컬 파일에는 원격 출처가 없으므로 클라이언트가 자동으로 업데이트하지 않는 경우가 일반적입니다. 이후 변경 사항은 파일을 다시 편집하거나 수정한 사본을 다시 가져와야 합니다.

혼동하기 쉬운 경우도 있습니다. 일부 클라이언트는 원격 설정을 복사해 로컬 사본을 만들 수 있습니다. 이 사본은 생성 시점에 구독 내용을 물려받지만, 이후에는 원본 구독과 함께 자동 업데이트되지 않는 경우가 많습니다. 설정의 출처를 확인하려면 항목에 구독 주소, 업데이트 시간, 업데이트 주기 또는 새로고침 버튼이 표시되는지 살펴보세요. 파일 경로와 수정 시간만 표시된다면 로컬 파일일 가능성이 높습니다.

비교 항목	원격 구독	로컬 YAML
콘텐츠 출처	구독 주소를 통해 다운로드	기기 파일 또는 직접 생성
업데이트 방식	수동 새로고침 또는 예약된 가져오기	편집 후 다시 불러오기
임시 변경	다음 업데이트 때 덮어써질 수 있음	저장 후 계속 유지됨
적합한 용도	노드 및 일반 정책 관리	사용자 지정 규칙, 테스트 및 백업

구독 업데이트와 사용자 지정 규칙의 장기 보존이 모두 필요하다면 클라이언트에서 제공하는 덮어쓰기, 병합 또는 확장 기능을 우선 사용하세요. 기능 이름은 Override, Mixin, Merge 또는 덮어쓰기 설정일 수 있습니다. 이러한 기능은 구독 다운로드가 끝난 뒤 지정된 필드를 추가하거나 수정해 캐시 파일을 직접 편집할 때 발생하는 덮어쓰기 문제를 줄여 줍니다. 클라이언트마다 병합 문법이 다르므로 이전하기 전에 해당 클라이언트의 필드 설명을 확인해야 합니다.

IMPORT / 03

설정 가져오기 및 첫 점검

원격 구독을 가져올 때는 클라이언트의 Profile 페이지에서 “URL에서 가져오기”와 같은 메뉴를 사용하세요. 구독 주소를 노드 이름, 규칙 편집기 또는 브라우저 프록시 설정에 붙여 넣으면 안 됩니다. 가져오기에 성공했다는 것은 클라이언트가 응답을 받았다는 뜻일 뿐이며, 반환된 내용을 현재 코어가 해석할 수 있는지도 확인해야 합니다. 서버가 로그인 페이지, 안내 문구 또는 형식이 완전하지 않은 YAML을 반환하면 항목은 만들어져도 코어를 불러오는 과정에서 오류가 발생할 수 있습니다.

로컬 파일을 가져오기 전에 확장자와 텍스트 인코딩을 확인하세요. YAML은 보통 .yaml 또는 .yml을 사용하며 UTF-8로 저장하는 것이 좋습니다. YAML은 들여쓰기로 계층을 표현하므로 공백을 사용하고 같은 계층에 탭 문자를 섞지 마세요. 프록시 그룹이 참조하는 노드 이름은 노드 정의와 일치해야 하며, 규칙이 가리키는 정책 이름도 실제로 존재해야 합니다.

현재 사용 가능한 설정을 보존하세요.새 Profile을 처음 가져오기 전에 기존 설정을 바로 삭제하지 마세요. 로드에 실패했을 때 빠르게 되돌릴 수 있습니다.
가져오기를 완료하고 업데이트 시간을 확인하세요.원격 항목에는 최근 가져온 시간이 표시되어야 하며, 로컬 항목은 파일 이름을 인식할 수 있어야 합니다.
설정을 활성화하고 코어 상태를 확인하세요.클라이언트에 해석 실패, 시작 실패 또는 포트 충돌 오류가 계속 표시되지 않는지 확인합니다.
프록시 그룹을 점검하세요.그룹에 선택 가능한 노드가 있는지, 자동 테스트 그룹이 지연 시간 측정을 완료할 수 있는지 확인합니다.
트래픽 인계 방식을 확인하세요.시스템 프록시 모드에서는 수신 포트를 확인하고, TUN 모드에서는 가상 네트워크 어댑터 상태와 권한을 확인합니다.
직접 연결 대상과 프록시 대상은 따로 테스트하세요.웹페이지 하나가 열리는 것만으로는 규칙, DNS 및 모든 정책이 올바르다고 볼 수 없습니다.

mihomo 설정에서는 특정 코어만 지원하는 필드에도 주의해야 합니다. mihomo 클라이언트에서 정상 작동하는 Profile이라고 해서 이전 버전의 원본 Clash 코어에 그대로 적용할 수 있는 것은 아닙니다. “알 수 없는 필드” 또는 해석 오류가 발생하면 구독 주소를 반복해서 수정하기보다 코어 종류와 버전을 비교하세요.

SWITCH / 04

여러 Profile을 올바르게 전환하기

설정을 전환하기 전에 현재 실행 모드와 사용 중인 프록시 그룹을 기록하세요. 일부 클라이언트는 Profile별로 정책 선택을 저장하고, 다른 클라이언트는 새 설정에서 같은 이름의 정책을 복원하려고 합니다. 두 설정에 모두 “노드 선택”이 있어도 그룹에 포함된 노드가 완전히 다르면 화면이 첫 번째 사용 가능한 항목으로 돌아갈 수 있습니다. 전환 후에는 기존 선택을 그대로 믿지 말고 주요 정책을 다시 확인하세요.

포트는 별도로 확인해야 하는 필드입니다. 설정 A가 mixed-port: 7890을 사용하고 설정 B가 mixed-port: 7893을 사용할 때 시스템 프록시가 여전히 7890을 가리키면, 설정 B로 전환한 뒤 브라우저는 연결되지 않지만 코어 자체는 정상처럼 보일 수 있습니다. 일부 데스크톱 클라이언트는 시스템 프록시 포트를 자동으로 동기화하지만, 일부는 설정을 불러오는 역할만 합니다. 따라서 설정을 전환할 때마다 클라이언트에 표시되는 실제 수신 주소를 확인해야 합니다.

TUN 모드 전환의 영향 범위는 더 넓습니다. Profile마다 DNS 모드, 라우팅 제외 항목, 자동 라우팅 설정 및 인터페이스 검색 매개변수가 다를 수 있습니다. 전환 중에는 가상 네트워크 어댑터가 잠시 다시 생성될 수 있으며, 기존 연결은 종료될 때까지 이전 경로를 계속 사용할 수도 있습니다. 새 설정을 검증할 때는 테스트 앱을 다시 열고, 필요하면 기존 연결을 끊은 뒤 규칙 적중 여부를 확인하세요.

일상 사용에 적합한 전환 순서

대상 Profile의 최근 업데이트가 성공했는지 확인하고 로드 오류가 있는지 살펴봅니다.
현재 프록시 그룹 선택을 기록합니다. 특히 수동 선택 그룹과 글로벌 모드의 출구를 확인하세요.
대상 Profile로 전환하고 코어가 다시 로드될 때까지 기다립니다.
실행 모드가 Rule, Global 또는 Direct 중 무엇인지 확인하여 다른 설정이 모드를 덮어쓰지 않았는지 점검합니다.
시스템 프록시 또는 TUN 상태를 확인하고 실제 수신 포트를 점검합니다.
연결 로그를 열고 직접 연결 규칙 하나와 프록시 규칙 하나를 테스트합니다.

전환 후 출구만 바꾸고 규칙과 DNS는 교체할 필요가 없다면 현재 Profile의 프록시 그룹에서 노드를 선택하는 편이 적합합니다. 불필요한 설정 전환을 줄이면 포트, 규칙 및 TUN 매개변수가 동시에 바뀌어 발생하는 진단 비용도 낮출 수 있습니다.

CATALOG / 05

여러 설정 정리 및 이름 지정 방법

설정 수가 늘어나면 문제는 가져오기보다 식별에서 발생하는 경우가 많습니다. 여러 항목이 모두 config.yaml로 표시되면 출처, 용도 및 업데이트 방식을 구분하기 어렵습니다. 이름에는 최소한 “출처 유형”과 “사용 시나리오”를 포함하세요. 예를 들면 “구독-A-일상”, “로컬-규칙 테스트”, “백업-이전 전”과 같이 지정할 수 있습니다. 이름에 구독 인증 정보, 전체 URL 또는 노드 서버 주소를 넣을 필요는 없습니다.

날짜는 “백업-2026-05-18”처럼 일회성 스냅샷에 넣는 것이 좋습니다. 계속 업데이트되는 구독은 매번 이름을 바꾸지 마세요. 구분하기 어려운 중복 항목이 많이 생깁니다. 장기간 사용할 설정은 코어 요구 사항, 포트, DNS 모드 및 사용자 지정 내용을 별도 기록에 저장하고 기억에 의존하지 않는 것이 좋습니다.

daily

일상 설정

안정적인 구독과 자주 사용하는 정책을 저장하고 임시 실험 필드는 넣지 않습니다.

test

테스트 설정

DNS, TUN 또는 새 규칙을 검증하는 용도로 사용하고 이름에 테스트 목적을 표시합니다.

backup

이전 백업

코어를 업그레이드하거나 클라이언트를 교체하기 전에 저장하고 생성 날짜와 출처를 기록합니다.

권장 보관 정보

출처: 원격 구독인지, 로컬 파일인지, 구독에서 복사한 로컬 사본인지 기록합니다.
용도: 일상 사용, 규칙 디버깅, TUN 테스트 또는 이전 백업인지 기록합니다.
코어 요구 사항: 원본 Clash용인지, mihomo 확장 필드가 필요한지 기록합니다.
트래픽 인계 방식: 시스템 프록시, TUN 또는 LAN 기기에만 프록시 포트를 제공하는 방식인지 기록합니다.
수정 사항: DNS, 포트, 규칙 또는 프록시 그룹을 조정했는지 기록합니다.
업데이트 시간: 구독을 마지막으로 새로고침한 시간 또는 로컬 파일을 마지막으로 수정한 날짜를 기록합니다.

설정을 삭제하기 전에 현재 사용 중인지 확인하세요. 일부 클라이언트는 현재 Profile의 삭제를 막지만, 다른 클라이언트는 목록의 다른 항목으로 자동 전환할 수 있습니다. 안전하게 처리하려면 먼저 정상 작동이 확인된 설정을 활성화한 다음 중복 항목을 삭제하세요. 중요한 수동 규칙이 포함된 로컬 파일은 먼저 명확한 백업 폴더로 내보내야 합니다.

REVISION / 06

업데이트, 수정 및 덮어쓰기 관계

원격 Profile의 핵심은 “로컬 캐시가 원격 콘텐츠에 의해 관리된다”는 점입니다. 클라이언트 캐시에서 노드, 규칙 또는 DNS 필드를 직접 수정하면 당장은 적용될 수 있지만, 다음 구독 새로고침 때 새 파일로 교체되는 경우가 많습니다. 사용자 지정 규칙이 업데이트 후 계속 사라진다면 업데이트 실패를 코어 문제로 오해하기보다 먼저 수정한 위치를 확인하세요.

장기간 수정하려면 세 가지 방법을 사용할 수 있습니다. 첫째, 클라이언트의 덮어쓰기 또는 병합 기능을 사용해 변경할 필드만 저장합니다. 둘째, 구독을 로컬 설정으로 복사한 뒤 직접 관리합니다. 셋째, proxy-providers와 rule-providers를 사용해 노드 모음, 규칙 모음 및 주 설정을 분리합니다. 세 번째 방법은 YAML과 mihomo 설정 구조에 익숙한 사용자에게 적합하며, 원격 리소스 형식이 해당 provider의 요구 사항에 맞는지 확인해야 합니다.

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

proxy-providers는 클라이언트 Profile과 같은 것이 아닙니다. Profile은 코어에 전달되는 주 설정이고, provider는 주 설정이 참조하는 외부 리소스입니다. 하나의 Profile이 여러 provider를 참조할 수도 있고 provider를 전혀 사용하지 않을 수도 있습니다. 둘을 구분해야 클라이언트 구독을 새로고침해야 하는지, provider를 업데이트해야 하는지, 아니면 주 설정을 다시 불러와야 하는지 판단할 수 있습니다.

YAML을 편집할 때는 목록 덮어쓰기에도 주의해야 합니다. 일부 병합 도구는 새로운 rules로 기존 목록 전체를 교체하고, 일부는 앞이나 뒤에 삽입하는 기능을 지원합니다. 규칙은 위에서 아래로 일치하므로 사용자 지정 규칙이 MATCH 뒤에 추가되면 파일을 정상적으로 불러와도 해당 규칙은 절대 적중되지 않습니다. 병합을 완료한 후에는 덮어쓰기 조각만 확인하지 말고 최종 생성된 설정을 확인하세요.

PROOF / 07

여러 Profile에서 자주 발생하는 문제 진단

전환 후 모든 앱에서 인터넷에 연결되지 않음

먼저 코어가 실행 중인지 확인한 다음 시스템 프록시 포트와 현재 Profile의 수신 포트가 일치하는지 점검하세요. TUN을 사용한다면 가상 네트워크 어댑터가 정상적으로 생성되었는지, 클라이언트에 필요한 권한이 있는지 확인합니다. 트래픽 인계 기능을 잠시 끄고 기본 네트워크 자체가 정상인지 검증할 수도 있습니다. 처음부터 설정을 삭제하지 마세요. 포트 불일치나 TUN 재생성 실패가 더 흔한 원인입니다.

설정 업데이트는 성공했지만 노드가 바뀌지 않음

현재 활성화된 항목이 정말 방금 업데이트한 Profile인지 확인하세요. 이름이 비슷한 중복 Profile 때문에 쉽게 잘못 판단할 수 있습니다. 그다음 업데이트 시간, 프록시 그룹 내용 및 코어 로그를 확인합니다. 주 설정이 provider를 참조한다면 Profile과 provider의 새로고침 상태를 각각 확인해야 합니다. 한 계층만 업데이트해서는 노드 목록이 즉시 바뀌지 않을 수 있습니다.

로컬 규칙을 저장했지만 다시 사라짐

이는 대개 구독 캐시를 편집한 뒤 다음 업데이트가 변경 사항을 덮어썼다는 뜻입니다. 규칙을 클라이언트가 지원하는 덮어쓰기 기능으로 옮기거나 별도의 로컬 Profile을 만드세요. 이전할 때 규칙이 참조하는 프록시 그룹 이름도 함께 복사해야 규칙은 남아 있지만 대상 정책이 사라지는 문제를 피할 수 있습니다.

한 설정이 이전 클라이언트에서는 정상인데 새 클라이언트에서 로드되지 않음

클라이언트 이름만 비교하지 말고 양쪽에서 실제로 사용하는 코어를 비교하세요. mihomo가 지원하는 확장 필드는 버전에 따라 발전하며, 원본 Clash와 각 분기마다 지원하는 필드 집합도 다릅니다. 오류 메시지에 표시된 필드를 확인하고 문법 또는 들여쓰기 문제인지, 필드 유형 문제인지, 코어가 지원하지 않는 문제인지 구분하세요. 불리언, 숫자 및 문자열은 올바른 유형을 유지해야 하며, 오류를 피하려고 모두 따옴표로 감싸지 마세요.

전환 후 프록시 그룹 선택이 초기화됨

먼저 새 설정과 이전 설정에 완전히 동일한 프록시 그룹 이름이 있는지, 새 그룹에 기존에 선택한 노드가 포함되어 있는지 확인하세요. 대상이 없으면 클라이언트는 사용 가능한 항목으로만 돌아갈 수 있습니다. 자동 테스트 그룹은 지연 시간에 따라 노드를 다시 선택할 수도 있습니다. 이는 그룹 유형에 따른 정상 동작이며 Profile 전환 실패를 뜻하지 않습니다.

일부 도메인만 접속할 수 없음

연결 로그를 열어 요청이 적중한 규칙과 정책을 확인하세요. 도메인 해석에 실패했다면 DNS 설정, fake-ip 필터 항목 및 상위 서버 연결 가능성을 추가로 점검합니다. 잘못된 정책이 적용됐다면 규칙 순서를 확인하세요. 여러 설정을 사용하는 환경에서는 현재 보고 있는 규칙 편집기가 실행 중인 Profile에 속하는지도 확인해야 합니다. 비활성 항목을 계속 수정하는 일을 피할 수 있습니다.

효과적인 문제 기록에는 현재 Profile 이름, 출처 유형, 코어 이름과 버전, 실행 모드, 수신 포트, 트래픽 인계 방식 및 구체적인 오류 하나가 포함되어야 합니다. 공유하기 전에 구독 주소와 노드 인증 정보는 숨기세요. 이러한 정보가 있으면 문제를 “설정 해석”, “코어 시작”, “포트 인계”, “DNS 해석” 또는 “규칙 일치”로 빠르게 분류할 수 있어 방향 없는 반복 가져오기를 줄일 수 있습니다.

FINAL CHECK / 08

여러 설정 관리 점검표

설정 이름만으로 출처와 용도를 구분할 수 있으며 기본 파일 이름에 의존하지 않습니다.
원격 구독과 로컬 파일을 별도로 관리하고 어떤 내용이 업데이트로 덮어써지는지 명확히 파악합니다.
전환 후 실행 모드, 프록시 그룹, 수신 포트 및 시스템 프록시 또는 TUN 상태를 확인합니다.
중요한 사용자 지정 규칙을 덮어쓰기 설정이나 로컬 파일에 저장하고 복구 가능한 백업을 마련합니다.
클라이언트나 코어를 업그레이드하기 전에 Profile이 특정 분기의 확장 필드를 사용하는지 확인합니다.
문제 진단 시 현재 활성화된 항목부터 확인하여 실행되지 않는 설정을 수정하지 않도록 합니다.
중복 설정을 삭제하기 전에 검증이 끝난 사용 가능한 Profile로 먼저 전환합니다.

Profile 관리의 핵심은 가능한 한 많은 설정을 저장하는 것이 아니라 각 설정의 출처, 용도 및 업데이트 범위를 명확히 하는 데 있습니다. 일상 설정은 안정적으로 유지하고 테스트 내용은 별도 항목에 넣으며 원격 구독의 캐시는 직접 수정하지 마세요. 전환 후 포트, 모드, 정책 및 DNS 순서로 확인하면 여러 설정을 함께 사용할 때 문제를 훨씬 쉽게 찾을 수 있습니다.