Clash 설정 파일이란? Profile 구조 입문과 다중 설정 전환 관리

Clash를 처음 접하는 사용자는 "설정 파일"과 "구독 링크"를 같은 것으로 혼동하는 경우가 많아, 규칙이 적용되지 않거나 노드를 전환해도 반응이 없거나 설정을 업데이트했는데 오히려 작동하지 않는 문제가 생기면 손을 대기 어려워합니다. 사실 Clash 계열 클라이언트(mihomo 커널을 사용하는 Clash Verge, Clash for Windows 파생판, ClashX 등 포함)의 핵심은 YAML 형식의 설정 파일 한 장이며, 업계에서는 이를 흔히 config.yaml 또는 클라이언트 안에서 Profile이라고 부릅니다. 이 구조와 출처, 업데이트 방식을 이해하는 것이 대부분의 사용 문제를 해결하는 전제 조건입니다.

config.yaml의 3가지 구조 블록

완전한 Clash 설정 파일은 본질적으로 순수 텍스트이며, 기능별로 세 부분으로 나눌 수 있습니다: 기본 포트 및 실행 파라미터, 프록시 그룹(proxy-groups), 규칙(rules). 이 세 요소가 출구 노드 정의(proxies)와 함께 작동하여 트래픽이 최종적으로 어떤 경로로 흐를지 결정합니다.

port: 7890
socks-port: 7891
mixed-port: 7892
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

proxy-groups:
  - name: 자동 선택
    type: url-test
    proxies: [홍콩01, 일본01, 싱가포르01]
    url: http://www.gstatic.com/generate_204
    interval: 300

rules:
  - DOMAIN-SUFFIX,googlevideo.com,자동 선택
  - GEOIP,CN,DIRECT
  - RULE-SET,reject,REJECT
  - MATCH,자동 선택

첫 번째 부분은 포트와 실행 모드입니다: port / socks-port는 각각 HTTP와 SOCKS5 로컬 프록시 포트를 열며, mixed-port는 두 기능을 합친 혼합 포트로 대부분의 최신 클라이언트는 기본적으로 이 하나만 사용합니다. allow-lan은 같은 로컬 네트워크의 다른 기기가 이 프록시에 접속할 수 있는지를 결정하며, mode의 대표적인 값은 rule(규칙에 따른 분기), global(전체를 같은 노드로), direct(직결, 프록시 미사용)입니다.

두 번째 부분은 프록시 그룹으로, "어떤 노드를 선택할지"를 결정합니다. select 타입은 수동 선택으로 클라이언트에서 클릭 한 번으로 전환하며, url-test는 설정된 interval 주기마다 자동으로 속도를 측정해 지연이 가장 낮은 노드를 선택합니다. fallback은 주 노드를 사용할 수 없을 때 순서대로 대체 노드로 넘어가며, load-balance는 요청을 해시나 라운드로빈 방식으로 여러 노드에 분산시켜 안정적인 세션 유지가 필요한 경우에 자주 사용됩니다.

세 번째 부분은 규칙으로, "어떤 트래픽이 어떤 그룹으로 갈지"를 결정합니다. 규칙은 위에서 아래로 한 줄씩 매칭되며 일치하면 즉시 멈춥니다. 흔히 쓰는 규칙 유형은 다음과 같습니다:

DOMAIN-SUFFIX · DOMAIN-KEYWORD · GEOIP · IP-CIDR · RULE-SET · MATCH

DOMAIN-SUFFIX: 도메인 접미사로 매칭, 예를 들어 googlevideo.com은 모든 하위 도메인에 일치합니다;
GEOIP: 목적지 IP가 속한 국가/지역으로 매칭하며, GEOIP,CN,DIRECT로 중국 본토 트래픽을 직결시키는 데 자주 사용됩니다;
RULE-SET: 외부 규칙 세트 파일을 참조해 많은 도메인을 메인 설정에 몰아넣지 않고 관리하기 쉽게 합니다;
MATCH: 마지막 보루 규칙으로 반드시 맨 마지막 줄에 두어야 하며, "위 규칙 전부 불일치 시 어떻게 할지"를 결정합니다.

규칙은 위에서 아래로 한 줄씩 매칭되므로, 순서를 뒤바꿔 쓰면(예: MATCH를 중간에 두는 경우) 그 뒤의 규칙은 영원히 실행되지 않습니다. 초보자가 가장 자주 빠지는 함정 중 하나입니다.

구독 링크와 로컬 설정 파일의 관계

구독 링크는 본질적으로 클라이언트가 직접 fetch할 수 있는 URL이며, 서버가 반환하는 내용이 바로 위에서 설명한 YAML 텍스트(또는 클라이언트가 한 번 더 변환해야 하는 범용 구독 형식)입니다. 클라이언트는 이 텍스트를 받으면 매번 다시 요청하는 것이 아니라 로컬 파일로 저장하는데, 이렇게 저장된 파일이 바로 Profile입니다. 즉 구독 링크는 "설정의 출처"이고 Profile은 "설정이 로컬에 자리 잡은 형태"입니다—네트워크가 끊겨도 클라이언트는 지난번에 동기화한 Profile로 정상 작동할 수 있습니다.

Profile은 반드시 구독에서 온 것일 필요는 없으며 완전히 직접 작성했거나 다른 곳에서 내려받은 로컬 파일일 수도 있습니다. 두 경우 모두 클라이언트에서는 같은 지위를 가지며 설정 목록에 나타나 전환할 수 있습니다. 차이는 구독형 Profile에는 원격 주소가 있어 설정된 update-interval(보통 시간 단위)에 따라 자동으로 최신 내용을 다시 받아와 로컬 파일을 덮어쓸 수 있다는 점뿐입니다. 로컬 파일형 Profile에는 이런 자동 업데이트 동작이 없어 변경은 수동으로 다시 가져와야만 반영됩니다.

많은 구독 서비스는 응답 헤더에 subscription-userinfo 필드를 담아 사용한 트래픽, 총 트래픽, 만료 시간을 전달하며, 클라이언트는 이를 분석해 Profile 목록 옆에 표시합니다. 이 때문에 어떤 구독은 가져온 뒤 트래픽 진행 바가 보이지만 어떤 구독은 순수한 파일명만 표시되는 경우도 있는데, 이는 서버가 해당 정보를 제공하는지에 달린 것이며 클라이언트 자체와는 무관합니다.

클라이언트에서 Profile 가져오기·업데이트·전환하기

클라이언트마다 화면상의 표현은 조금씩 다르지만 설정을 가져오는 방식은 크게 두 가지입니다: 구독 링크를 붙여넣거나 로컬 파일을 선택하는 것. 아래는 일반적인 작업 흐름이며 실제 메뉴 위치는 각 클라이언트의 화면을 참고하세요.

클라이언트의 "설정" "Profiles" 또는 "구독 관리" 페이지를 엽니다;
추가 버튼을 눌러 "URL에서 가져오기"를 선택하고 구독 링크를 붙여넣은 뒤 확인하면, 클라이언트가 자동으로 내려받아 새 Profile로 파싱합니다;
로컬 설정 파일이라면 "파일에서 가져오기"를 선택해 이미 내려받은 .yaml 파일을 지정하면 됩니다;
가져오기가 끝나면 목록에서 해당 항목을 클릭해 현재 사용할 설정으로 지정합니다. 대부분의 클라이언트는 체크 표시나 강조 테두리로 "사용 중"인 항목을 표시합니다;
업데이트가 필요하면 해당 항목 옆의 새로 고침 아이콘을 눌러 원격 내용을 다시 받아오면 되며, 삭제 후 재생성할 필요는 없습니다.

자동 업데이트와 관련해서는 간격을 12~24시간 사이로 설정하는 것을 권장하며, 너무 짧게 잡지 마세요. 구독 인터페이스를 자주 요청하는 것은 불필요할 뿐 아니라(노드 목록은 보통 하루에도 여러 번 바뀌지 않습니다) 일부 서비스는 고빈도 요청에 속도 제한이나 임시 차단을 걸기도 합니다.

동작	적용 대상	설명
URL에서 가져오기	구독 링크	원격 주소를 저장하며, 이후 수동 또는 자동으로 업데이트 가능
파일에서 가져오기	로컬 .yaml	원격 주소 없음, 업데이트하려면 수동으로 다시 가져와 덮어써야 함
수동 업데이트	구독형 Profile	자동 주기를 기다리지 않고 즉시 최신 내용을 한 번 받아옴
사용 항목 전환	모든 유형	선택된 Profile 하나만 현재 프록시 동작을 이끕니다

강조할 점은, 클라이언트에 여러 개의 Profile을 저장해도 서로 간섭하지 않는다는 것입니다—동시에 실제로 작동하는 것은 선택된 그 하나뿐이고, 선택되지 않은 나머지 설정들은 정적으로 보관될 뿐 실행 중인 포트를 점유하거나 추가 리소스를 소모하지 않습니다. 이 때문에 "다중 설정 관리"는 실용적인 요구입니다: 출장 중에는 지연이 낮은 국내 경유 설정으로 바꾸고, 평소에는 주 구독으로 되돌리며, 새 규칙을 테스트할 때는 임시 초안으로 전환해도 서로 영향을 주지 않습니다.

다중 설정 관리에서 흔히 저지르는 실수

가져오기와 전환을 익혔다면, 다음은 실제 사용 중 가장 자주 걸려 넘어지는 지점들입니다.

수동으로 고친 내용이 구독 업데이트로 덮어씌워짐

구독형 Profile의 로컬 파일에 직접 규칙을 손으로 추가했다면, 다음 자동 업데이트 시 원격에서 받아온 새 내용으로 전체가 덮어씌워져 수동으로 고친 부분이 함께 사라집니다. 구독 내용을 유지하면서 장기적으로 커스텀 규칙을 쓰고 싶다면, 클라이언트가 제공하는 "오버레이" "Override" 또는 "패치 설정" 기능을 사용해야 합니다—구독 원본 위에 독립적으로 저장되는 커스텀 규칙/프록시 그룹 계층을 얹는 방식으로, 구독을 업데이트할 때는 기본 부분만 교체되고 이 계층은 영향을 받지 않습니다.

여러 구독의 프록시 그룹 이름 충돌

서비스마다 구독에 "홍콩 노드" "자동 선택" 같은 흔한 이름을 쓰는 경우가 많아, 두 구독의 내용을 수동으로 하나의 설정에 합치려 하면 규칙이 참조하는 프록시 그룹 이름이 어긋나기 쉽고, 규칙이 매칭되어도 해당하는 그룹을 찾지 못해 트래픽이 예상 노드가 아닌 마지막 보루 MATCH 분기로 흘러갈 수 있습니다. 구독 간 설정을 합치기 전에는 프록시 그룹 이름이 겹치지 않는지 먼저 확인하는 것을 권장합니다.

Profile 전환을 노드 전환으로 오해

Profile을 전환하는 것은 포트, 규칙, 프록시 그룹 정의를 포함한 설정 전체를 바꾸는 일입니다. 반면 일상적으로 "노드 라인을 바꾸는" 작업은 대개 현재 Profile 안의 특정 프록시 그룹에서 다시 노드를 선택하는 것만으로 충분하며 설정 전체를 전환할 필요가 없습니다. 이 두 동작을 혼동하면 규칙과 분기 로직까지 함께 바뀌어 버려서, 문제를 조사할 때 진짜 원인을 찾지 못하게 됩니다.

업데이트 간격을 너무 짧게 설정

앞서 언급했듯, 자동 업데이트 간격을 몇 분 단위로 설정하면 겉보기에는 "더 즉각적"으로 보이지만 실제로는 대부분의 구독 노드 목록이 짧은 시간 내에 자주 바뀌지 않으며, 지나치게 높은 빈도의 요청은 오히려 속도 제한에 걸릴 위험을 키웁니다. 적절한 구간은 12~24시간이며, 중요한 변경이 있을 것으로 예상될 때만 수동으로 한 번 업데이트하면 됩니다.

자주 묻는 질문

Profile과 구독 링크는 여러 개 저장해도 되나요? 서로 충돌하지 않나요?

원하는 만큼 Profile을 동시에 저장할 수 있으며, 이들은 목록 안의 독립된 항목일 뿐이라 서로 충돌하지 않습니다. 충돌은 여러 내용을 수동으로 하나의 설정 파일에 합칠 때, 이름이나 규칙 순서를 잘못 처리한 경우에만 발생합니다.

구독을 업데이트했더니 왜 갑자기 규칙이 작동하지 않나요?

대부분은 구독 서버가 규칙 세트나 프록시 그룹 구조를 업데이트하면서 기존에 손으로 고친 내용이 전체 덮어씌워진 경우입니다. 오버레이/패치 기능으로 커스텀 부분을 별도 저장하면 이 문제가 반복되는 것을 막을 수 있습니다.

로컬 파일형 Profile도 자동 업데이트를 설정할 수 있나요?

불가능합니다. 자동 업데이트는 요청할 수 있는 원격 주소가 있어야 하는데, 순수 로컬 파일에는 이 주소가 없어서 내용 변경은 수동으로 다시 가져오는 방식으로만 반영됩니다.

config.yaml의 3가지 구조 블록

구독 링크와 로컬 설정 파일의 관계

클라이언트에서 Profile 가져오기·업데이트·전환하기

다중 설정 관리에서 흔히 저지르는 실수

수동으로 고친 내용이 구독 업데이트로 덮어씌워짐

여러 구독의 프록시 그룹 이름 충돌

Profile 전환을 노드 전환으로 오해

업데이트 간격을 너무 짧게 설정

자주 묻는 질문

Clash 클라이언트 받기