Clash 설정 파일이란? Profile 구조와 여러 구독 전환·관리 방법

Profile, 설정 파일, 구독 링크

Clash 클라이언트에서 Profile은 일반적으로 코어가 불러올 설정과 이를 관리하는 기록을 뜻합니다. 설정 본문은 주로 YAML 형식이며, 흔히 .yaml 또는 .yml 확장자를 사용합니다. 관리 기록에는 표시 이름, 구독 주소, 자동 업데이트 주기 등이 저장될 수 있습니다. 이러한 정보가 설정 본문에 포함되지 않을 수도 있습니다.

구독 링크는 설정을 가져오는 경로이지 프록시 노드 그 자체가 아닙니다. 클라이언트가 링크에 접속하면 서버는 전체 Clash 설정을 반환하거나 노드 목록만 반환할 수 있습니다. 가져오기에 성공했다는 것은 클라이언트가 인식 가능한 데이터를 받았다는 뜻일 뿐입니다. 노드 사용 가능 여부, 규칙의 정확성, 트래픽이 프록시로 전달되는지는 이 상태만으로 판단할 수 없습니다.

항목	저장되는 내용	주요 작업
로컬 설정 파일	노드, 프록시 그룹, 규칙 및 코어 매개변수	가져오기, 편집, 백업
원격 구독	설정 또는 노드를 가져오는 주소	다운로드, 업데이트, 주소 변경
Profile 관리 기록	이름, 출처, 업데이트 설정 등 클라이언트 정보	활성화, 이름 변경, 업데이트 예약
실행 설정	현재 코어에 실제로 적용된 설정	병합 결과와 실행 로그 확인

세 가지 주요 섹션의 연결 방식

설정은 아웃바운드 참조 관계부터 살펴보면 이해하기 쉽습니다. proxies는 노드를 정의하고, proxy-groups는 노드나 다른 정책을 그룹으로 구성하며, rules는 연결을 어떤 아웃바운드로 보낼지 정합니다. 일부 설정은 proxy-providers로 노드를 가져오기도 하므로 로컬 proxies가 비어 있어도 반드시 오류는 아닙니다.

proxies: 노드 연결 매개변수

각 노드에는 보통 name, type, server, port와 프로토콜에 필요한 인증 및 전송 필드가 포함됩니다. 노드 이름은 다른 설정에서 참조할 때 사용하는 식별자입니다. 이름을 바꾸면 프록시 그룹에서 참조하는 이름도 함께 수정해야 합니다. 한쪽만 바꾸면 프록시를 찾을 수 없다는 로드 오류가 발생할 수 있습니다.

노드의 접속 지역, 인증 정보, 서버 포트는 제공업체가 결정합니다. 클라이언트의 로컬 수신 포트를 노드 서버 포트로 입력하지 마세요. 이름만 보고 프로토콜을 판단해서도 안 됩니다. 이름에 ‘홍콩’이나 ‘백업’이라고 적혀 있어도 이는 단순한 라벨일 뿐, 연결 프로토콜 선택에는 영향을 주지 않습니다.

proxy-groups: 수동 선택과 자동 선택

select: 그룹 구성원을 직접 선택합니다. 출구 노드를 지정해서 사용해야 할 때 적합합니다.
url-test: 지정된 주소의 테스트 결과에 따라 노드를 자동 선택합니다. 테스트 결과가 파일 다운로드 속도와 같지는 않습니다.
fallback: 구성원을 순서대로 확인하고, 사용 가능한 구성원 중 앞에 있는 항목을 우선 사용합니다.
load-balance: 지원되는 정책에 따라 연결을 분산합니다. 다운로드 연결 하나의 대역폭을 단순히 합산한다는 뜻은 아닙니다.

규칙이 참조하는 것은 정책 그룹 이름이지 ‘현재 마우스로 선택한 노드’가 아닙니다. 예를 들어 규칙이 ‘웹 트래픽 출구’ 그룹을 가리킨다면 해당 그룹과 하위 그룹에서 실제로 선택된 항목을 확인해야 합니다. 관련 없는 다른 정책 그룹에서 노드를 바꿔도 해당 규칙의 아웃바운드는 달라지지 않습니다.

rules: 위에서 아래 순서로 매칭

자주 쓰는 규칙에는 정확한 도메인 일치 DOMAIN, 도메인 접미사 일치 DOMAIN-SUFFIX, IP 대역 일치 IP-CIDR, 마지막 기본 규칙 MATCH가 있습니다. 규칙 모드에서는 일반적으로 가장 먼저 일치한 규칙에 따라 연결 경로가 결정됩니다. 구체적인 규칙을 포괄적인 규칙보다 앞에 두고 MATCH는 맨 마지막에 배치하세요.

DIRECT와 REJECT는 각각 직접 연결과 연결 거부를 뜻하는 내장 아웃바운드입니다. 규칙의 마지막 항목에는 정의된 정책 그룹 이름을 입력할 수도 있습니다. 공백, 대소문자, 문장 부호까지 이름을 정확히 일치시켜야 합니다. 모양이 비슷한 전각 쉼표는 규칙에 사용하는 영문 쉼표를 대신할 수 없습니다.

최소 설정으로 YAML 구조 확인하기

아래는 구조를 이해하기 위한 직접 연결 예시입니다. 원격 프록시 노드가 없으므로 원격 프록시 서비스에 사용할 수 없습니다. 예시에서는 HTTP와 SOCKS 혼합 수신 포트를 7890으로 설정하고, LAN 접근은 끈 뒤 수동 그룹 하나를 규칙과 내장 직접 연결 아웃바운드에 연결합니다.

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

proxies: []

proxy-groups:
  - name: 수동 출구
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,수동 출구

proxies: []는 이 섹션에 정의된 노드가 없다는 뜻입니다. 정책 그룹에서는 내장 DIRECT를 계속 참조할 수 있습니다.
DOMAIN-SUFFIX,example.com,DIRECT는 예시 도메인과 하위 도메인에 일치합니다. 문법을 설명하기 위한 것으로 특정 서비스의 실제 트래픽 분리 요구를 나타내지는 않습니다.
192.168.0.0/16은 사설 IP 주소 범위입니다. no-resolve는 이 IP 규칙을 위해 도메인 조회를 자동으로 수행하지 않도록 합니다.
앞선 규칙에 일치하지 않은 연결은 ‘수동 출구’로 전달되며, 이 예시에서 해당 그룹의 구성원은 직접 연결 하나뿐입니다.

YAML 들여쓰기에는 공백을 사용하고 Tab은 사용하지 않습니다. 여기서는 각 단계마다 공백 두 칸을 들여씁니다. 키 뒤의 콜론과 값 사이에는 공백을 둡니다. 이름에 # 같은 특수 문자가 포함되면 따옴표로 감싸야 합니다. 오류를 확인할 때는 먼저 로그에 표시된 줄 번호를 보고, 바로 앞 줄의 들여쓰기와 따옴표가 제대로 닫혔는지 확인하세요.

구독 가져오기와 첫 연결 확인

Clash Verge Rev의 일반적인 화면을 예로 들어 보겠습니다. 먼저 ‘구독’으로 이동해 제공업체가 안내한 구독 주소 전체를 입력란에 붙여 넣고 가져오기를 실행합니다. 배포 버전에 따라 버튼 문구는 다를 수 있지만 ‘구독 추가’, ‘내용 업데이트’, ‘설정 활성화’는 서로 다른 작업입니다. 구독을 추가했다고 현재 실행 설정이 자동으로 전환되는 것은 아닙니다.

응답 형식을 확인합니다. 제공업체가 Clash 또는 mihomo용으로 표시한 구독 주소를 사용하세요. 다운로드 결과가 로그인 페이지, 오류 메시지, 인코딩된 노드 주소 문자열이라면 이를 완전한 YAML 설정으로 바로 사용하지 마세요.
Profile 이름을 지정합니다. 가져온 직후 알아보기 쉬운 로컬 이름을 설정하고, 목록에서 출처별로 구분할 수 있는지 확인하세요.
대상 설정을 활성화합니다. 해당 Profile을 선택하고 코어가 로드를 완료할 때까지 기다리세요. 오류가 발생하면 먼저 로그를 확인하고, 같은 주소를 연속으로 가져와 중복 기록을 만들지 마세요.
정책 그룹을 확인합니다. ‘프록시’로 이동해 원하는 그룹이 있고 그룹 안에 선택 가능한 구성원이 있는지 확인한 다음 출구를 선택하세요.
트래픽 전달을 확인합니다. 먼저 시스템 프록시처럼 한 가지 전달 방식을 사용하세요. 대상 앱에서 새 연결을 만든 다음 연결 기록에서 적용된 규칙과 아웃바운드를 확인합니다.

실제 혼합 포트가 7890이라면 터미널에서 다음 명령으로 HTTP 프록시를 명시해 앱이 시스템 프록시를 따르지 않는 문제와 프록시 자체의 문제를 구분할 수 있습니다. 이 명령은 이번 요청이 로컬 프록시를 통과하는지만 테스트하며, TUN이나 다른 앱의 트래픽도 정상적으로 전달된다는 뜻은 아닙니다.

curl --proxy http://127.0.0.1:7890 --head --max-time 15 https://example.com/

포트가 다르면 실제 값을 사용하세요. 연결이 거부되면 먼저 클라이언트가 실행 중인지, 해당 포트에서 수신 중인지 확인합니다. 로컬 프록시 연결은 됐지만 원격 요청이 실패한다면 노드 인증, 대상 사이트, DNS 로그를 확인하세요. 모든 오류를 구독 만료 탓으로 돌리지 마세요.

여러 구독의 이름 지정과 전환

대부분의 데스크톱 클라이언트는 여러 Profile을 저장할 수 있지만, 코어는 보통 최종 실행 설정 하나만 불러옵니다. 구독 세 개를 저장해도 세 가지 규칙이 자동으로 합쳐지는 것은 아닙니다. Profile을 전환하면 일반적으로 노드, 정책 그룹, 규칙이 교체됩니다. 클라이언트의 전역 설정과 오버라이드 기능은 계속 적용될 수 있습니다.

이름으로 출처를 구분하고 메모로 용도를 기록

업무용 기본: 일상 업무에 사용할 설정을 저장하고, 메모에 필요한 정책 그룹과 트래픽 분리 조건을 기록합니다.
가정용 백업: 다른 출처의 설정을 저장해 기본 설정을 사용할 수 없을 때 수동으로 전환합니다. 기본 설정과 하나의 업데이트 기록으로 합치지 마세요.
로컬 규칙 테스트: 설정을 복사해 규칙을 수정할 때 사용합니다. 사용 가능한 원격 구독을 직접 덮어쓰지 않도록 하세요.

Profile 이름에 구독 주소 전체나 토큰을 적지 마세요. 이름이 스크린샷, 로그, 화면 공유에 노출될 수 있습니다. 백업할 때는 어떤 클라이언트 기록이 포함되는지도 확인해야 합니다. YAML만 내보내면 원격 주소, 예약 작업, 정책 그룹에서 이전에 선택한 항목은 포함되지 않을 수 있습니다.

전환 후 확인할 네 가지

대상 Profile에 현재 활성 표시가 있는지 확인하고 로그에 로드 실패가 없는지 살펴봅니다.
규칙이 참조하는 정책 그룹을 다시 확인하세요. 이전 설정에서 선택했던 항목이 새 설정에도 유지된다고 가정하면 안 됩니다.
시스템 프록시나 TUN을 의도한 상태로 유지하세요. 전달 방식과 구독을 동시에 바꾸면 문제의 원인을 찾기 어려워집니다.
대상 앱을 종료한 뒤 다시 연결하고 새 연결의 아웃바운드를 확인하세요. 기존의 장시간 연결은 새 노드로 즉시 전환되지 않을 수 있습니다.

여러 출처의 노드를 함께 사용하려면 proxy-providers나 클라이언트가 명시적으로 지원하는 통합 기능을 고려하세요. YAML 두 개를 그대로 이어 붙이지 마세요. 최상위 키, 중복 노드 이름, 정책 그룹 이름이 겹치면 파싱 오류나 참조 혼선이 생길 수 있습니다. 전체 설정 구독을 provider용 노드 데이터로 바로 사용할 수 있다고 보장할 수도 없으므로 반환 형식을 확인해야 합니다.

업데이트 주기와 로컬 수정 내용 보존

‘구독 업데이트’와 ‘노드 테스트’는 서로 다른 작업입니다. 전자는 원격 콘텐츠를 가져오고, 후자는 이미 있는 노드를 탐색합니다. 업데이트 주기를 짧게 설정해도 지연 시간이 자동으로 줄거나 사용할 수 없는 계정이 활성화되지는 않습니다. 변경이 드문 구독은 우선 하루 한 번으로 설정하고 제공업체의 안내에 따라 조정할 수 있습니다.

작업	설정 위치 또는 필드	확인할 사항
전체 Profile 업데이트	클라이언트의 구독 관리 화면	화면에 표시된 분 또는 시간 단위로 입력합니다. YAML 단위를 그대로 적용하면 안 됩니다.
노드 provider 업데이트	`proxy-providers`의 `interval`	mihomo에서 이 필드는 초 단위이며 `86400`은 하루입니다.
자동 정책 그룹 탐색	`url-test` 등 그룹의 `interval`	초 단위이며 `300`은 5분입니다. 구독 갱신 주기가 아닙니다.

원격 업데이트를 실행하면 보통 다운로드한 설정 본문이 교체됩니다. 원격 파일에 직접 사용자 규칙을 추가하면 다음 업데이트에서 사라질 수 있습니다. 수정 내용을 계속 유지하려면 클라이언트에서 지원하는 오버라이드나 병합 기능을 사용하세요. 한 번만 오프라인으로 테스트하려면 로컬 Profile로 따로 저장하고, 이후 원격 업데이트가 자동 반영되지 않는다는 점을 기억하세요.

오버라이드의 병합 방식도 확인해야 합니다. 규칙 목록을 뒤에 추가할지, 앞에 넣을지, 통째로 교체할지는 클라이언트 구현에 따라 다릅니다. 사용자 규칙이 MATCH 뒤에 추가되면 예상대로 적용되지 않습니다. 저장 후에는 편집기에 해당 줄이 있는지만 확인하지 말고 최종 규칙 순서를 살펴보세요.

가져오기 실패와 설정 오류 점검 순서

다운로드 실패: 주소와 가져오기 경로 확인

구독 주소의 기존 쿼리 매개변수를 그대로 유지하고 토큰을 빠뜨리지 마세요. 메신저가 주소 뒤에 붙인 마침표까지 함께 복사하지 않도록 주의하세요. HTTP 상태 코드 401 또는 403은 인증이나 접근 제한과 관련된 경우가 많습니다. 429는 요청 빈도 제한을 뜻하므로 반복해서 새로고침하지 마세요. 구독 업데이트에 프록시가 필요하다면 사용 가능한 설정을 먼저 보존해 ‘노드가 없어 노드를 다운로드할 수 없는’ 상황을 피하세요.

파싱 실패: 형식과 코어 호환성 확인

YAML 오류가 표시되면 먼저 응답 본문이 HTML이 아닌지 확인한 다음 들여쓰기와 콜론을 살펴보세요. 지원되지 않는 프록시 유형이나 필드가 보이면 현재 코어와 제공업체의 요구 사항을 확인하세요. 오류를 없애려고 인증 필드를 함부로 삭제하지 마세요. 설정은 로드되지만 그룹 구성원을 찾지 못한다면 노드 이름, provider 참조, 그룹 이름이 일치하는지 확인하세요.

로드되지만 접속되지 않음: 실제 아웃바운드 확인

먼저 아웃바운드 모드가 rule인지 확인하세요. 전역 모드나 직접 연결 모드에서는 설정에 작성된 규칙 경로와 다른 경로가 관찰될 수 있습니다. 그런 다음 연결 기록에서 매칭된 규칙, 정책 그룹, 대상 주소를 확인하세요. 필요하면 앞서 소개한 명시적 프록시 요청과 비교합니다. DNS, 시스템 프록시, TUN 설정은 고급 설정을 참고하고, 기본 트래픽 전달 방법은 시스템 프록시 안내에서 확인할 수 있습니다.

안정적인 관리 순서는 사용 가능한 Profile을 먼저 보존하고 새 출처를 가져온 다음, 규칙과 아웃바운드를 확인한 뒤 업데이트를 예약하는 것입니다. 장기적으로 유지할 수정은 관리 가능한 오버라이드 계층에 두세요. 매번 한 가지 요소만 바꿔야 다운로드, 파싱, 선택, 트래픽 전달 중 어느 단계에서 문제가 생겼는지 파악할 수 있습니다.