Clash 설정 파일이란: Profile 기본 개념과 멀티 설정 전환 관리
Profile은 Clash의 핵심 요소로 노드, 규칙, 정책 그룹을 결정합니다. 이 글에서는 설정 파일의 구조와 출처를 짚어보고, 여러 구독을 함께 쓸 때 필요한 이름 규칙, 업데이트, 전환 방법을 소개하여 상호 덮어쓰기를 방지합니다.
NT-05.1Profile이란 무엇인가
Clash 클라이언트를 실행하면 화면에 보이는 노드 목록, 정책 그룹, 분산 규칙은 모두 하나의 파일에서 나옵니다. 이를 보통 Profile, 즉 설정 파일이라고 부릅니다. 본질적으로는 YAML 텍스트 파일이며, "어떤 프록시 노드가 있는지", "노드를 어떻게 그룹화할지", "어떤 트래픽이 어떤 정책 그룹을 거칠지" 세 가지를 정의합니다. 클라이언트 자체는 실행기 역할만 하며 노드 정보를 저장하지 않고, 모든 동작은 현재 불러온 Profile에 의해 결정됩니다. 같은 클라이언트라도 설정 파일을 바꾸면 노드, 그룹, 규칙이 완전히 다른 내용으로 바뀌는 이유가 바로 여기에 있습니다.
Profile을 이해하는 것이 중요한 이유는, "노드가 사라졌다", "규칙이 안 먹힌다", "그룹 이름이 바뀌었다" 같은 문제가 생겼을 때 클라이언트 고장을 먼저 의심하는 게 아니라 현재 불러온 설정 파일이 무엇인지, 최근에 업데이트된 적이 있는지부터 확인해야 하기 때문입니다. 사용 중 겪는 대부분의 혼란은 클라이언트 프로그램 자체가 아니라 설정 파일 단계에서 원인을 찾을 수 있습니다.
NT-05.2설정 파일의 구조
표준적인 Clash / mihomo 설정 파일은 여러 최상위 필드로 구성됩니다. 자주 쓰이는 필드와 역할은 아래 표와 같습니다. 필드명은 대소문자를 구분하므로 규격과 정확히 일치하게 작성해야 합니다.
| 필드 | 역할 |
|---|---|
| proxies | 노드 목록. 프로토콜 종류, 주소, 포트, 인증 정보를 항목별로 선언 |
| proxy-groups | 정책 그룹. 여러 노드를 하나로 묶고 선택 방식(수동/자동 속도 측정/로드 밸런싱)을 지정 |
| rules | 분산 규칙. 도메인, IP, 프로세스 등의 조건에 따라 트래픽을 특정 정책 그룹으로 전달 |
| rule-providers | 외부 규칙 세트 참조. 규칙 수가 많을 때 rules에 직접 나열하지 않기 위한 설정 |
| dns | DNS 해석 동작. nameserver, enhanced-mode, fake-ip 범위 등 포함 |
| tun | 가상 네트워크 카드 관련 스위치. 시스템 프록시가 처리하지 못하는 트래픽을 가져오기 위해 사용 |
가장 단순한 구조는 대략 다음과 같습니다. 실제 설정은 필드가 더 많지만 기본 골격은 동일합니다.
proxies:
- name: "샘플 노드"
type: vmess
server: example.example
port: 443
uuid: 00000000-0000-0000-0000-000000000000
proxy-groups:
- name: "자동 선택"
type: url-test
proxies: ["샘플 노드"]
url: "http://www.gstatic.com/generate_204"
interval: 300
rules:
- DOMAIN-SUFFIX,example.com,자동 선택
- MATCH,DIRECT
세 구간은 명확한 의존 순서를 가집니다. proxy-groups는 proxies에 선언된 노드 이름을 참조하고, rules는 다시 proxy-groups의 정책 그룹 이름을 참조합니다. 한 구간의 이름을 바꾸고 다른 두 구간을 함께 수정하지 않으면 "정책 그룹이 노드를 찾지 못함" 또는 "규칙이 존재하지 않는 그룹을 가리킴" 같은 오류가 발생하며, 이는 설정 파일을 직접 손볼 때 가장 흔한 실수입니다.
NT-05.3설정 파일의 출처: 로컬 파일과 구독 링크
설정 파일을 얻는 방법은 보통 두 가지이며, 이후 관리 비용이 크게 달라집니다.
- 로컬 파일: 직접 작성했거나 어딘가에서 내려받은 YAML 파일로, 클라이언트에 가져온 뒤 자동으로 바뀌지 않으며 노드가 만료되면 파일 전체를 수동으로 교체해야 합니다.
- 구독 링크: HTTP/HTTPS 주소로, 클라이언트가 주기적으로 이 주소에 요청을 보내 최신 내용을 받아와 로컬 캐시를 덮어씁니다. 노드 풀 갱신, 만료 안내, 트래픽 정보는 대개 이 링크의 응답 헤더로 함께 전달됩니다.
대부분의 클라이언트는 구독에 자동 업데이트 간격을 설정할 수 있으며, 흔히 하루 한 번이나 몇 시간에 한 번으로 지정합니다. 간격을 너무 짧게 잡으면 구독 서버에 부담을 주고, 일부 서비스는 요청 빈도가 너무 높은 클라이언트를 제한하거나 차단하기도 하므로 업데이트 간격을 서비스 권장치보다 더 짧게 잡을 필요는 없습니다.
NT-05.4여러 설정 파일 병행: 이름 규칙, 업데이트, 전환
여러 구독을 동시에 사용하는 경우도 흔합니다. 예를 들어 하나는 일상용, 하나는 백업용, 하나는 특정 앱 테스트 전용으로 두는 식입니다. 여러 설정이 공존할 때 가장 흔히 생기는 문제는 상호 덮어쓰기입니다. 두 구독이 클라이언트에서 같은 기본 이름으로 표시되어 업데이트할 때 대상을 잘못 고르거나, 전환한 뒤 지금 적용 중인 설정이 어느 것인지 확인하지 않는 식입니다. 다음 몇 가지로 오류 확률을 줄일 수 있습니다.
- 구독을 가져오는 즉시 이름을 바꾸고 용도와 출처 표시를 추가합니다. 예를 들어 "일상"과 "백업"을 구분하며, 클라이언트가 자동 생성한 기본 이름을 그대로 두지 않습니다.
- 업데이트 전에 현재 선택된 설정 대상을 먼저 확인한 뒤 업데이트를 실행합니다. 다른 설정으로 전환한 상태에서 원래 설정의 업데이트 버튼을 잘못 누르는 일을 피할 수 있습니다.
- 용도별로 다른 자동 업데이트 간격을 설정합니다. 오래 쓰지 않는 백업 구독은 자동 업데이트를 꺼서 백그라운드 요청을 줄일 수 있습니다.
- 설정을 전환한 뒤에는 정책 그룹 선택 상태를 다시 확인합니다. 구독마다 그룹 구조와 이름이 다를 수 있어, 전환 전 수동으로 선택했던 노드가 더 이상 존재하지 않을 수 있습니다.
- 규칙이 많고 커스터마이징 정도가 높은 설정은 로컬 백업을 하나 남겨두는 것이 좋습니다. 구독 소스가 바뀌어 사용자 정의 규칙이 통째로 덮어써지는 상황을 막을 수 있습니다.
구독 업데이트는 파일 전체를 덮어쓰는 방식이며 증분 병합이 아닙니다. 클라이언트 화면에서 노드 그룹을 수동으로 조정했거나 사용자 정의 규칙을 추가한 적이 있다면, 다음 구독 업데이트 때 이런 수동 변경 사항이 함께 지워집니다. 단, 클라이언트가 독립적인 "사용자 규칙" 중첩 기능을 지원하는 경우는 예외입니다.
NT-05.5일반적인 문제 해결 순서
"노드 수가 안 맞음", "규칙이 적용되지 않음", "정책 그룹이 사라짐" 같은 현상이 나타나면 다음 순서로 확인해 보세요. 대부분은 클라이언트를 재설치하지 않고도 설정 파일 단계에서 원인을 찾을 수 있습니다.
- 현재 적용 중인 설정 파일이 어느 것인지, 방금 자동 업데이트가 일어났는지 확인합니다.
- 설정 파일 원문을 열어 proxy-groups에서 참조하는 노드 이름이 모두 proxies에 존재하는지 대조합니다.
- rules에서 참조하는 정책 그룹 이름이 proxy-groups의 이름과 대소문자, 전각/반각 기호까지 완전히 일치하는지 확인합니다.
- rule-providers를 사용 중이라면 외부 규칙 세트 주소에 접근이 되는지, 형식이 클라이언트 요구사항에 맞는지 확인합니다.
- 설정 파일 자체 문제를 배제한 뒤에야 노드 서버 측이나 로컬 네트워크 환경 요인을 살펴봅니다.
설정 파일을 통째로 교체해야 하는 블랙박스가 아니라 읽고 대조할 수 있는 텍스트로 다루는 것이 Clash 계열 클라이언트를 장기간 안정적으로 쓰는 기본 습관입니다. 여러 설정을 병행할 때는 명확한 이름 규칙과 업데이트 습관이 어떤 클라이언트 기능 스위치보다 오류 확률을 줄이는 데 효과적입니다.