Clash 프로필이란: 설정 파일 기본 개념과 다중 설정 전환 관리 입문

프로필이 정확히 무엇인가: YAML 하나에 담긴 네 가지 요소

Clash 및 그 파생 코어(Clash Premium, Clash Meta, mihomo)의 맥락에서 프로필(설정 파일)은 클라이언트가 실제로 불러와 적용하는 완전한 YAML 파일을 가리킵니다. '구독'과 동의어도 아니고 '노드 목록'과 동의어도 아닙니다—구독은 설정 파일을 얻는 하나의 경로일 뿐이고, 노드는 설정 파일 안의 일부 내용일 뿐입니다. 이 포함 관계를 명확히 이해해야 이후에 다룰 저장 위치, 업데이트 로직, 다중 설정 전환을 혼동 없이 설명할 수 있습니다.

일반적인 Clash 설정 파일은 보통 다음 순서로 구성됩니다:

• 공통 실행 파라미터: 포트(port / socks-port), LAN 접속 허용 여부(allow-lan), 실행 모드(mode: rule / global / direct), 로그 레벨(log-level), 외부 컨트롤러 주소(external-controller) 등으로, 클라이언트 실행 후의 기본 동작을 결정합니다.
• DNS 설정 구간: 내장 DNS 사용 여부, 업스트림 서버 주소, fake-ip 모드 사용 여부, 특정 도메인에 DoH/DoT를 적용할지 여부로, 도메인 해석 속도와 트래픽 분기 정확도에 직접적인 영향을 줍니다.
• proxies 노드 목록: 각 프록시 서버의 연결 파라미터—프로토콜 종류(Shadowsocks, VMess, Trojan, Hysteria2 등), 서버 주소, 포트, 암호화 방식과 키 등입니다. '연결이 되는지'를 결정하는 기초 항목입니다.
• proxy-groups 정책 그룹: proxies의 노드를 용도별로 분류하고 선택 방식(select 수동 선택, url-test 자동 속도 테스트 전환, fallback 장애 조치, load-balance 로드 밸런싱)을 정의합니다. '노드를 어떻게 사용할지'를 결정하는 논리 계층입니다.
• rules 규칙 구간: 도메인, IP 대역, GEOIP, 프로세스명 등의 조건에 따라 트래픽을 특정 정책 그룹이나 직접 연결/차단으로 매칭합니다. '어떤 트래픽이 어느 경로로 갈지'를 결정하는 스케줄링 계층입니다.

이 다섯 구간이 합쳐져야 비로소 완전하게 사용 가능한 프로필이 됩니다. proxies 구간이 없으면 정책 그룹이 선택할 노드가 없고, rules 구간이 없으면 클라이언트는 mode의 전역 기본 동작에 따라 모든 트래픽을 처리할 수밖에 없어 '트래픽 분기'라 할 수 없습니다.

설정 파일의 세 가지 출처: 구독, 로컬 가져오기, 직접 작성

획득 방식에 따라 프로필은 대체로 세 가지로 나뉘며, 실제 사용에서는 종종 섞어서 사용합니다:

1. 구독 링크를 통한 자동 생성

가장 흔한 방식입니다. 서비스 제공자가 HTTP(S) 링크를 제공하고, 클라이언트가 이 링크를 요청하면 서버가 노드 정보를 반환합니다(완전한 YAML을 그대로 반환하는 경우도 있고, Base64로 인코딩된 노드 목록인 경우도 있습니다). 대부분의 Clash 계열 클라이언트(Clash Verge, FlClash, ClashX Meta 등)는 노드 데이터를 받은 후 내장 또는 사용자 지정 규칙 템플릿과 결합해 완전하게 사용 가능한 프로필을 조립한 뒤 로컬에 저장합니다. 같은 구독 링크라도 클라이언트마다 정책 그룹 구조나 규칙 수가 완전히 같지 않을 수 있는 이유가 바로 조립 템플릿이 다르기 때문입니다.

2. 로컬 파일 가져오기

다른 사람이 공유했거나 직접 정리한 YAML 파일이 있다면, 클라이언트의 '파일에서 가져오기' 기능으로 네트워크 요청 없이 바로 불러올 수 있습니다. 이런 프로필은 자동으로 업데이트되지 않고 내용이 완전히 고정되어 있어, 디버깅이나 오프라인 상황에 적합합니다.

3. 직접 작성 / 온라인 에디터로 수정

숙련된 사용자는 텍스트 에디터나 클라이언트 내장 설정 편집 패널을 이용해 proxy-groups, rules 구간을 직접 작성하거나 수정합니다. 흔한 사례로는 특정 정책 그룹에 사용자 노드를 추가하거나, 특정 앱에 별도의 출구를 지정하거나, 특정 도메인을 차단하는 경우가 있습니다. 이런 수정을 하기 전에는 원본 파일을 백업해 두는 것이 좋으며, 문법 오류로 클라이언트 로딩이 실패했을 때 되돌릴 수 없는 상황을 방지할 수 있습니다.

설정 파일은 어디에 저장되나: 클라이언트별 경로 차이

프로필은 로컬 파일이며 구체적인 저장 경로는 클라이언트마다 다릅니다. 문제를 진단할 때는 종종 디렉터리에 직접 들어가 파일이 실제로 업데이트됐는지 확인해야 합니다. 주요 클라이언트의 대략적인 저장 규칙은 다음과 같습니다:

강조할 점은, 대부분의 그래픽 클라이언트에서는 앱 데이터 디렉터리에 있는 이 자동 생성 파일을 사용자가 직접 수정하는 것을 권장하지 않는다는 점입니다—클라이언트 자체의 업데이트 로직이 다음 새로고침 시 수동으로 수정한 내용을 덮어쓸 수 있기 때문입니다. 사용자 규칙을 장기적으로 유지해야 한다면, 클라이언트가 제공하는 '설정 병합' 또는 '오버라이드(override)' 기능을 이용해 사용자 정의 조각을 별도로 저장하고 구독으로 생성된 메인 설정 위에 덧씌우는 방식이 더 안전합니다.

설정 파일 업데이트 방법: 자동 새로고침과 수동 업데이트의 차이

구독 링크로 얻은 프로필만 '업데이트'라는 동작을 가지고 있으며, 로컬에서 가져왔거나 직접 작성한 파일은 스스로 변하지 않습니다. 업데이트 메커니즘은 주로 다음 두 항목에 좌우됩니다:

• update-interval: 일부 클라이언트는 구독 정보에 이 값을 기록합니다(단위는 보통 분). 지정된 시간 간격에 도달하면 구독 링크에 자동으로 다시 요청을 보내고, 최신 노드를 받아 기존 파일의 proxies 구간을 덮어씁니다.
• 수동 업데이트 버튼: 클라이언트의 구독 관리 화면에는 보통 '업데이트' 또는 새로고침 아이콘이 있어, 클릭하면 update-interval의 제한 없이 즉시 요청이 실행됩니다. 서비스 측이 노드를 방금 교체해 바로 동기화해야 할 때 주로 사용됩니다.

업데이트 시 클라이언트는 보통 노드 관련 내용만 교체하며, 사용자가 로컬에서 추가한 사용자 규칙은 건드리지 않습니다(단, '병합/오버라이드' 메커니즘을 사용했고 자동 생성 파일 본체를 직접 수정하지 않았다는 전제하에서입니다). 업데이트 후 사용자 정의 분기 규칙이 사라졌다면, 대부분 덮어써지는 메인 파일에 직접 수정을 가한 경우이므로 오버라이드 기능을 사용해 다시 설정해야 합니다.

여러 설정 파일을 전환하고 관리하는 방법

대부분의 사용자는 설정 하나만 사용하지 않습니다—예를 들어 두 서비스 제공자를 동시에 구독하거나, 스트리밍 분기용 커스텀 버전과 일상용 미니멀 버전을 로컬에 각각 저장해 두는 경우입니다. 이런 상황에서는 설정 파일의 '전환'과 '관리'가 일상적인 사용에서 피할 수 없는 부분이 됩니다.

전환 로직: 동시에 활성화되는 설정은 하나뿐

클라이언트 코어는 실행 중 프로필 하나만 불러옵니다. 그래픽 화면에서 보이는 '설정 목록'은 본질적으로 저장된 여러 개의 YAML 파일이며, 항목을 클릭하면 해당 파일이 현재 활성 설정으로 지정되고 클라이언트가 코어를 다시 읽어 새로운 proxies, proxy-groups, rules를 적용합니다. 전환 과정에서 짧은 연결 끊김이 발생하는 것은 정상적인 현상입니다.

명명과 분류에 대한 제안

설정 수가 많아지면 기본으로 생성된 파일명만으로는 용도를 구분하기 어렵습니다. 클라이언트에서 각 설정의 이름을 다시 지정해 출처와 용도를 명확히 표시하는 것이 좋습니다. 예를 들어 '일상 구독', '임시 테스트', '로컬 커스텀 규칙' 등으로 구분하면 잘못된 설정을 선택할 확률을 줄일 수 있습니다. 일부 클라이언트는 설정에 태그를 달거나 그룹으로 묶는 기능을 지원해 상황별로 정리할 수 있습니다.

병합과 오버라이드: 전환하지 않고도 규칙을 덧씌우는 방법

기존 구독을 기반으로 사용자 규칙 몇 개만 추가하고 싶다면(예: 특정 내부 서비스 도메인을 강제로 직접 연결), 완전한 설정을 새로 만들 필요 없이 클라이언트의 '오버라이드(override)' 또는 '설정 병합' 기능을 사용하는 것이 좋습니다. 이 기능들은 작은 YAML 조각(보통 추가하거나 대체할 규칙만 포함)을 따로 관리할 수 있게 해주며, 적용 시 메인 설정 위에 덧씌워집니다. 메인 설정이 업데이트되어도 오버라이드 조각은 그대로 유지되어 다시 추가할 필요가 없습니다.

삭제와 정리

오랫동안 쓰지 않는 테스트 설정은 되도록 빨리 삭제하는 것이 좋습니다. 특히 실제 노드 인증 정보가 담긴 파일은 더욱 그렇습니다—구독이 이미 만료되었더라도 파일 안의 키 정보는 여전히 평문으로 로컬에 저장되어 있으므로, 오래된 설정을 정리하는 것도 기본적인 사용 습관 중 하나입니다.

자주 묻는 질문 빠른 정리

이 점들을 명확히 정리하고 나서 클라이언트 화면의 '설정 관리', '구독 정보', '오버라이드' 같은 항목을 보면, 본문에서 다룬 저장·업데이트·중첩이라는 세 가지 메커니즘과 자연스럽게 연결되어 프로필, 구독, 노드, 규칙이라는 개념을 더 이상 혼동하지 않게 됩니다.