Clash 설정 파일이란? Profile 구조 입문과 여러 설정 관리

Clash Profile에는 무엇이 저장될까

Clash 클라이언트에서 Profile은 보통 ‘설정’ 또는 ‘설정 파일’로 번역됩니다. 단순한 노드 목록이 아니라 프록시 코어의 포트 수신, DNS 해석, 노드 구성, 정책 그룹 생성 및 트래픽 규칙 매칭 방식을 정의하는 구조화된 문서입니다. 클래식 Clash, Clash Meta 및 이후의 mihomo 코어는 주로 YAML 형식을 사용하지만, 그래픽 클라이언트는 YAML 외에도 선택한 정책, 구독 업데이트 시간, 인터페이스 설정을 저장할 수 있습니다.

실행 가능한 기본 설정에는 보통 수신 포트, 실행 모드, 프록시 노드, 정책 그룹과 규칙이 포함됩니다. mihomo를 사용할 때는 TUN, sniffer, rule-providers, proxy-providers 같은 확장 필드도 포함될 수 있습니다. 클라이언트는 Profile을 읽어 YAML을 해석한 뒤 유효한 내용을 코어 프로세스에 전달합니다. 들여쓰기 오류, 필드 형식 불일치, 존재하지 않는 정책 그룹 참조가 있으면 로딩이 중단될 수 있습니다.

자주 사용하는 필드	역할	일반적인 내용
`mixed-port`	HTTP와 SOCKS 혼합 프록시 진입점 제공	`7890`
`mode`	트래픽을 규칙, 글로벌 프록시 또는 직접 연결로 처리할지 결정	`rule`
`proxies`	정적 프록시 노드 정의 저장	노드 이름, 서버, 포트 및 프로토콜 매개변수
`proxy-groups`	수동 선택, 자동 속도 측정 및 장애 조치 전략 구성	`select`、`url-test`、`fallback`
`rules`	위에서부터 도메인, IP, 프로세스 또는 규칙 집합을 순서대로 매칭	`DOMAIN-SUFFIX`、`IP-CIDR`、`MATCH`
`dns`	DNS 수신, 업스트림 서버 및 해석 모드 제어	`fake-ip` 또는 `redir-host`

아래의 간단한 예시는 필드 간 참조 관계를 보여 줍니다. 규칙의 마지막 열은 반드시 기존 정책 그룹을 가리켜야 합니다. 예를 들어 규칙의 ‘노드 선택’은 proxy-groups에 있는 이름과 공백 및 대소문자까지 완전히 일치해야 합니다.

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

proxies:
  - name: "노드 A"
    type: socks5
    server: 192.0.2.10
    port: 1080

proxy-groups:
  - name: "노드 선택"
    type: select
    proxies:
      - "노드 A"
      - DIRECT

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

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

구독 설정은 원격 URL에서 가져옵니다. 클라이언트가 해당 주소로 HTTP 요청을 보내면 서버가 Clash YAML을 반환하고, 클라이언트는 이를 로컬 사본으로 저장한 뒤 불러옵니다. 구독 링크 자체가 접근 자격 증명과 같으므로 로그, 스크린샷 또는 공개 저장소에 복사하면 계정 정보가 노출될 수 있습니다. 평소에도 비밀번호처럼 관리해야 합니다.

로컬 설정은 사용자가 직접 가져오거나 편집하는 YAML 파일입니다. ‘구독 업데이트’를 눌러도 자동으로 바뀌지 않으므로 직접 만든 노드, 고정 규칙, 디버깅 설정 및 오프라인 환경에 적합합니다. 두 설정 모두 최종적으로 코어가 읽을 수 있는 YAML이 되지만, 출처와 업데이트 방식 및 덮어쓰기 동작은 서로 다릅니다.

비교 항목	구독 설정	로컬 설정
콘텐츠 출처	원격 구독 서비스의 응답	로컬 파일 또는 수동 편집
업데이트 방식	주기 또는 수동으로 URL에 다시 요청	파일을 직접 수정한 뒤 다시 불러오기
원격 변경 사항의 덮어쓰기	업데이트 시 보통 다운로드한 사본으로 교체	구독 업데이트의 영향을 받지 않음
적합한 상황	노드가 자주 바뀌고 서비스 제공자가 통합 관리하는 경우	고정 규칙, 실험용 설정, 직접 운영하는 서비스

구독 YAML을 직접 수정하면 쉽게 사라지는 이유

많은 클라이언트에서 현재 구독의 캐시 파일을 열어 편집할 수 있지만, 다음 업데이트 때 문서 전체를 다시 다운로드하면서 직접 추가한 규칙, DNS 매개변수 또는 정책 그룹이 덮어써집니다. 클라이언트가 이전 파일을 보존하더라도 새 Profile에 다른 내부 식별자가 부여되어 수정 내용이 더 이상 사용되지 않을 수 있습니다.

사용자 지정 내용을 장기간 유지하려면 클라이언트가 제공하는 오버라이드, 스크립트 또는 병합 기능을 우선 사용하세요. 클라이언트마다 메뉴 이름은 다르지만 ‘설정’ → ‘오버라이드’, ‘Profiles’ → ‘Merge’ 또는 설정 카드 오른쪽의 편집 메뉴에서 찾을 수 있습니다. mihomo를 사용하는 클라이언트는 DNS, 규칙 및 TUN 필드 오버라이드도 지원할 수 있습니다. 사용하기 전에 병합 순서를 확인해야 합니다. 나중에 입력된 같은 이름의 스칼라 값은 일반적으로 이전 값을 덮어쓰지만, 배열을 교체할지 추가할지는 클라이언트 구현에 따라 다릅니다.

업데이트 및 전환은 실제로 어떻게 동작할까

수동 업데이트와 자동 업데이트

설정 카드의 업데이트 버튼을 누르면 클라이언트는 보통 ‘구독 주소 요청, 응답 확인, 임시 파일 기록, YAML 해석, 기존 캐시 교체, 코어에 다시 불러오도록 알림’ 순서로 동작합니다. HTTP 요청이 성공했다고 설정을 사용할 수 있는 것은 아닙니다. 로그인 페이지, 오류 메시지 또는 형식이 불완전한 YAML이 반환되면 상태 코드는 200이어도 해석 단계에서 실패할 수 있습니다.

자동 업데이트는 같은 과정을 정해진 시간마다 실행하는 기능입니다. 일반적인 간격은 6시간, 12시간 또는 24시간이며, 일부 클라이언트는 구독 응답의 업데이트 간격을 읽고 일부는 ‘설정’ → ‘구성’ 또는 ‘Profiles’ 페이지에서 지정한 고정 주기를 사용합니다. 노트북이 절전 상태인 동안에는 보통 작업이 실행되지 않으며, 깨어난 뒤 즉시 보충 업데이트를 수행할지는 클라이언트의 일정 관리 방식에 따라 달라집니다.

업데이트 전에 현재 Profile 이름과 선택한 정책 그룹을 기록해 두면 업데이트 후 변경 원인을 확인하기 쉽습니다.
시스템 시간이 정확한지 확인하세요. 시간 오차가 너무 크면 HTTPS 인증서 검증에 실패할 수 있습니다.
업데이트 후 노드 수, 정책 그룹 이름 및 마지막 업데이트 시간을 확인하고 ‘요청 성공’만 확인하지 마세요.
코어 로그를 열어 yaml, parse, proxy group 등의 오류가 없는지 확인하세요.
일반 HTTPS 페이지 하나로 규칙 매칭을 확인한 다음 프록시가 필요한 대상도 테스트하세요. 지연 시간 숫자에만 의존하지 마세요.

Profile 전환은 노드만 바꾸는 작업이 아니다

설정 목록에서 다른 Profile을 선택하면 클라이언트가 코어에 전체 설정을 다시 불러오도록 합니다. 수신 포트가 7890에서 7897로 바뀌고, DNS 모드가 fake-ip에서 redir-host로 바뀌며, TUN 활성화 여부, 라우팅 규칙과 정책 그룹도 함께 변경될 수 있습니다. 따라서 전환 후 ‘브라우저는 접속되지만 터미널은 연결되지 않음’ 또는 ‘시스템 프록시가 여전히 이전 포트를 가리킴’ 현상이 나타나면 먼저 포트와 트래픽 가로채기 모드를 확인해야 합니다.

시스템 프록시는 운영체제에 설정된 프록시 주소일 뿐입니다. 예를 들어 Profile이 mixed-port: 7890을 사용하면 클라이언트는 보통 시스템 HTTP 및 HTTPS 프록시를 127.0.0.1:7890로 지정합니다. 새 설정이 7891로 바뀌었는데 그래픽 클라이언트가 시스템 프록시를 동기화하지 않으면 앱은 계속 이전 포트에 연결합니다. 시스템 프록시를 껐다가 다시 켜 클라이언트가 주소를 새로 기록하도록 해 보세요.

TUN 모드는 변경 범위가 더 큽니다. mihomo는 가상 네트워크 인터페이스를 만들고 라우팅 조건에 맞는 트래픽을 가로챕니다. DNS 하이재킹, 엄격한 라우팅 및 자동 라우팅 매개변수는 현재 설정이나 클라이언트 오버라이드에서 가져옵니다. Profile을 전환한 뒤에는 ‘설정’ → ‘네트워크’ 또는 ‘설정’ → ‘TUN 모드’에서 상태를 확인하세요. macOS에서는 네트워크 확장 프로그램이나 관리자 권한을 다시 승인해야 할 수도 있습니다.

여러 설정을 함께 사용할 때의 이름 지정과 그룹화 방법

여러 구독을 동시에 사용할 때 가장 흔한 문제는 설정 수가 아니라 이름의 식별성이 떨어지는 것입니다. ‘서비스 A’, ‘백업’ 또는 자동 생성된 무작위 파일명만 사용하면 몇 달 뒤 설정의 용도, 출처 및 업데이트 방식을 판단하기 어렵습니다. 이름은 당시의 임시 상태가 아니라 사용 목적을 설명해야 합니다.

네 부분으로 구성된 이름을 권장합니다

용도-출처-플랫폼-업데이트 방식

업무-서비스A-macOS-자동12시간
개인-서비스B-전체 플랫폼-수동
테스트-로컬 규칙-mihomo-고정
비상-서비스C-iOS-자동24시간

‘용도’는 업무, 개인, 테스트 또는 비상용을 구분합니다. ‘출처’에는 식별하기 쉬운 약칭만 쓰고 전체 구독 주소는 이름에 넣지 마세요. ‘플랫폼’은 특정 운영체제 규칙이 포함됐는지 표시합니다. ‘업데이트 방식’은 이 설정이 자동으로 바뀌는지 알려 줍니다. 클라이언트에서 이름 길이가 제한되면 Work-A-Mac-12h처럼 줄일 수 있지만, 모든 설정에서 같은 순서를 유지해야 합니다.

모든 노드를 하나의 파일에 몰아넣지 않기

여러 출처를 하나의 큰 YAML로 합치면 편리해 보이지만 실제로는 이름 충돌, 규칙 덮어쓰기 및 업데이트 어려움이 생깁니다. 두 구독에 모두 ‘자동 선택’이나 ‘홍콩 노드’ 같은 이름이 포함될 수 있으며, 병합 도구에 안정적인 이름 변경 규칙이 없으면 정책 그룹이 잘못된 노드를 참조하게 됩니다. 노드가 수백 개에 이르면 속도 측정 요청도 짧은 시간에 많은 연결을 만들어 냅니다.

더 명확한 방법은 Profile을 각각 유지하고, 출처를 넘나들며 선택해야 할 때 proxy-providers를 사용하는 것입니다. mihomo의 provider는 여러 원격 파일에서 노드를 불러올 수 있으며, 주 설정에서 use로 참조합니다. 이렇게 하면 주 설정은 규칙과 정책을 담당하고 노드 출처는 독립적으로 업데이트됩니다.

proxy-providers:
  provider-a:
    type: http
    url: "https://subscription.example/provider-a.yaml"
    path: ./providers/provider-a.yaml
    interval: 43200
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: "자동 선택"
    type: url-test
    use:
      - provider-a
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

예시의 interval: 43200은 provider를 12시간마다 업데이트한다는 뜻입니다. 상태 확인은 600초마다 실행되고 정책 그룹은 300초마다 지연 시간을 다시 평가합니다. 실제 간격을 지나치게 짧게 설정할 필요는 없습니다. 노드가 많을 때 60초마다 전체 테스트를 실행하면 연결 수와 배터리 소모가 늘어납니다. 모바일 기기에서는 정책 평가 간격을 600~1800초로 조정할 수 있습니다.

백업 및 복구에서 보존해야 할 항목

설정 백업의 목적은 앱 디렉터리 전체를 복사하는 것이 아니라 실행 환경을 재구성하는 데 필요한 자료를 보존하는 것입니다. 클라이언트마다 디렉터리 구조와 데이터베이스 형식이 버전에 따라 달라지므로 앱 데이터 디렉터리를 그대로 덮어쓰면 이전 버전의 상태가 새 버전에 유입될 수 있습니다. 읽을 수 있는 YAML, 구독 출처 설명 및 주요 설정 기록을 함께 보관하는 편이 더 안전합니다.

권장하는 다섯 가지 백업 자료

로컬 YAML: 직접 작성한 주 설정, 오버라이드 파일, 사용자 지정 규칙 및 provider 정의를 포함합니다.
구독 목록: 서비스 이름, 용도 및 업데이트 주기를 기록합니다. 구독 URL은 보호된 비밀번호 관리 도구에 보관해야 합니다.
클라이언트 설정: 시스템 프록시, TUN, 시작 시 자동 실행, 로컬 네트워크 연결 허용 및 포트 설정을 기록합니다.
버전 정보: 그래픽 클라이언트 버전과 코어 버전을 기록합니다. 예를 들어 클라이언트 2.0.0, mihomo v1.19.x처럼 기록하면 필드 호환성을 재현하기 쉽습니다.
복구 안내: 가져오기 순서, 기본 Profile, 자주 사용하는 정책 그룹 및 필요한 시스템 권한 승인 절차를 적어 둡니다.

백업 파일은 clash-profile-backup-2026-07-09처럼 날짜별로 보관할 수 있습니다. DNS, TUN 또는 규칙을 크게 변경하기 전 버전을 하나 저장하고 파일명에 용도를 추가하세요(예: work-mac-before-tun-change.yaml). YAML은 Git으로 변경 내역을 관리하기에 적합하지만, 구독 주소·인증 매개변수·개인 서버 정보가 포함된 파일은 접근이 제한된 비공개 저장소에만 보관해야 합니다.

복구할 때 모든 기능을 한꺼번에 활성화하지 않기

기존 환경과 호환되는 클라이언트 버전을 설치하고 먼저 시스템 프록시와 TUN을 꺼 둡니다.
YAML을 가져온 뒤 코어가 시작되는지 확인하고 로그에 필드 해석 오류가 없는지 점검합니다.
사용 가능한 노드를 하나 수동으로 선택한 뒤 127.0.0.1:7890을 사용해 로컬 프록시 포트를 테스트합니다.
시스템 프록시를 켜고 시스템 프록시를 따르는 브라우저와 앱을 확인합니다.
마지막으로 TUN을 켜고 DNS, 로컬 네트워크 접속 및 절전 모드 해제 후 네트워크 상태를 확인합니다.

단계적으로 복구하면 문제가 Profile, 노드, 시스템 프록시 또는 TUN 중 어디에 있는지 명확히 알 수 있습니다. 가져온 직후 모든 기능을 켜면 네트워크가 끊겼을 때 로그에 DNS, 라우팅 및 연결 오류가 동시에 나타나 최초 실패 지점을 찾기 어렵습니다.

자주 발생하는 Profile 문제와 해결 방법

설정은 업데이트됐지만 노드 목록이 바뀌지 않음

먼저 현재 활성화된 Profile을 업데이트했는지, 이름이 비슷한 다른 설정을 업데이트한 것은 아닌지 확인하세요. 그런 다음 업데이트 시간과 구독 응답 내용을 확인합니다. 원격에서 실제로 새 노드를 반환했는데도 화면에 이전 목록이 표시되면 다른 Profile로 전환했다가 돌아오거나 코어를 재시작해 다시 불러오도록 하세요. 그래도 바뀌지 않으면 클라이언트에서 고정 오버라이드나 provider 캐시를 사용 중인지 확인합니다.

YAML을 가져온 뒤 해석 실패가 표시됨

YAML은 공백으로 계층을 표현하므로 Tab 들여쓰기에 의존할 수 없습니다. 목록 항목 앞의 하이픈, 콜론 뒤의 공백, 특수 문자가 포함된 노드 이름 및 중복 필드를 중점적으로 확인하세요. 오류 로그에 행 번호가 표시되면 해당 행에서 위쪽으로 올라가 전체 블록을 점검해야 합니다. 실제 들여쓰기 문제는 앞선 몇 줄에서 발생하는 경우가 많습니다.

# 올바른 예: proxies는 배열
proxies:
  - name: "노드 A"
    type: socks5

# 잘못된 예: 목록 항목과 필드의 계층이 일치하지 않음
proxies:
 - name: "노드 A"
    type: socks5

설정 전환 후 모든 웹사이트가 직접 연결됨

mode가 direct인지, 규칙 마지막이 MATCH,DIRECT로 작성됐는지, 대상 도메인이 직접 연결 규칙에 매칭됐는지 확인하세요. mihomo 로그에는 연결 대상, 매칭된 규칙 및 최종 정책이 표시됩니다. 로그에 새 연결이 전혀 없다면 문제는 대개 규칙 자체가 아니라 시스템 프록시, 앱 프록시 설정 또는 TUN 가로채기에 있습니다.

정책 그룹 선택이 재시작할 때마다 초기화됨

클래식 설정의 profile.store-selected: true 필드를 사용하면 이 필드를 지원하는 코어가 정책 그룹 선택을 저장할 수 있습니다. mihomo도 Profile 상태 저장 관련 설정을 지원합니다. 다만 그래픽 클라이언트가 이 상태를 대신 관리하거나 업데이트할 때마다 새 설정 식별자를 만들 수 있습니다. 상태 저장을 활성화하는 것뿐 아니라 정책 그룹 이름도 일정하게 유지하고, 구독 변환 과정에서 날짜나 노드 수가 자동으로 추가되지 않도록 해야 합니다.

profile:
  store-selected: true
  store-fake-ip: true

초보자 관리 절차: 하나의 설정으로 시작하기

처음 사용할 때 여러 구독을 바로 합치거나 복잡한 규칙을 작성할 필요는 없습니다. 우선 주로 사용할 구독 하나만 유지하고 업데이트, 노드 전환, 시스템 프록시 및 로그 확인이 정상적으로 작동하는지 확인하세요. 두 번째 설정은 비상용으로만 사용하고 명확한 이름으로 구분합니다. 여러 출처에서 노드를 선택해야 할 때가 되면 provider 또는 오버라이드 기능을 도입하세요.

일상 작업은 다음과 같은 짧은 절차로 고정할 수 있습니다. 매주 한 번 구독 업데이트 시간을 확인하고, 설정 업데이트 후 노드 수와 정책 그룹을 점검하며, 규칙을 수정하기 전 로컬 YAML을 복사합니다. Profile을 전환한 뒤에는 포트와 트래픽 가로채기 모드를 확인하고, 클라이언트를 업그레이드한 뒤 코어 버전을 기록하세요. 이렇게 하면 ‘갑자기 연결되지 않음’ 문제를 검증 가능한 단계로 나눌 수 있어 설정을 반복해서 삭제하고 다시 가져올 필요가 없습니다.

Profile 관리의 핵심은 세 가지 계층을 구분하는 것입니다. 원격에서 관리하는 구독, 로컬에 장기간 보관하는 규칙, 클라이언트가 기록하는 실행 상태입니다. 구독은 변화하는 노드를 제공하고 로컬 설정은 안정적인 라우팅 의도를 표현하며 클라이언트 상태는 현재 선택을 기억합니다. 세 가지를 분리해 관리하면 여러 설정의 공존, 자동 업데이트 및 기기 이전을 더욱 쉽게 제어할 수 있습니다.