Clash 설정 파일(Profile) 구조 분석: 필드 의미와 다중 구독 관리 방법

Profile이란 무엇인가

Clash 생태계에서 "설정 파일"(Profile)이란 로컬 포트, 아웃바운드 노드 목록, 프록시 그룹의 분류 로직, 그리고 일련의 트래픽 분산 규칙이 담긴 YAML 형식의 텍스트를 말합니다. 클라이언트 화면에서 보이는 정책 그룹, 지연 시간 측정, 규칙 매칭 결과는 결국 이 YAML이 해석되어 렌더링된 결과입니다. 구독 링크를 직접 입력하든 로컬 파일을 가져오든, 클라이언트가 실제로 하는 일은 원격 또는 로컬의 이 텍스트를 가져와 형식을 검증한 뒤 코어(Clash Premium 또는 mihomo)에 넘겨 실행시키는 것입니다.

Profile의 구조를 이해하면 문제를 더 빠르게 파악할 수 있을 뿐만 아니라, 더 중요하게는 "어떤 변경이 안전하고 어떤 변경이 다음 구독 갱신 시 사라질지"를 판단할 수 있게 됩니다. 이것이 이 글에서 명확히 설명하려는 핵심 문제입니다.

필드 분석: Profile에는 무엇이 담겨 있나

완전한 Profile은 대략 네 개의 영역으로 나눌 수 있으며 순서가 강제되지는 않지만, 클라이언트 화면은 보통 아래 논리에 따라 그룹으로 표시합니다.

1. 기본 실행 파라미터

이 부분은 코어가 어떤 포트를 리스닝하고 어떤 모드로 동작할지를 결정하며, 자주 등장하는 필드는 다음과 같습니다.

이 필드들은 대부분 기본값을 가지며, 클라이언트 화면의 "포트 설정", "혼합 포트", "LAN 연결" 같은 스위치가 바꾸는 것도 결국 이 영역의 내용입니다.

2. proxies: 노드 목록

proxies는 배열이며 각 항목이 하나의 아웃바운드 노드를 나타냅니다. 자주 쓰이는 필드로 name(노드 표시 이름), type(ss, vmess, trojan, hysteria2 등 프로토콜 종류), server, port, 그리고 프로토콜별 암호화 방식, UUID, 비밀번호 등의 파라미터가 있습니다. 이 부분은 거의 수동으로 편집할 필요가 없는데, 구독 서비스 제공자가 생성해 주기 때문에 사용자는 구독 링크 자체가 유효한지만 확인하면 됩니다.

3. proxy-groups: 정책 그룹

proxy-groups는 노드가 어떻게 선택 가능한 그룹으로 "묶이는지"를 결정합니다. 자주 쓰이는 필드는 다음과 같습니다.

• name: 그룹 이름으로, 규칙 섹션에서 이 이름을 참조합니다
• type: 그룹 유형으로, select(수동 선택), url-test(자동 속도 측정 후 전환), fallback(장애 시 자동 전환), load-balance(로드 밸런싱)가 흔히 쓰입니다
• proxies: 해당 그룹에 포함되는 노드 또는 다른 그룹의 이름
• url / interval: url-test와 fallback 유형에서 사용되며, 속도 측정 주소와 검사 간격(초)을 지정합니다

클라이언트 화면에 줄줄이 나열된 "노드 선택" 드롭다운은 바로 여기서 select 유형으로 정의된 각 그룹에 대응합니다.

4. rules: 트래픽 분산 규칙

rules는 위에서 아래로 순서대로 매칭되는 목록으로, 형식은 보통 유형,매칭 내용,대상 정책입니다. 흔히 쓰이는 유형에는 DOMAIN-SUFFIX(도메인 접미사 매칭), DOMAIN-KEYWORD(도메인 키워드), IP-CIDR(IP 대역 매칭), GEOIP(지역 정보 데이터베이스 기준 판단), RULE-SET(외부 규칙 집합 참조)가 있습니다. 마지막에는 보통 MATCH,정책명이 기본값으로 붙어, 앞쪽 규칙에 매칭되지 않은 트래픽을 모두 이 규칙이 처리합니다. 규칙 목록에서 위에 있을수록 우선순위가 높고, 한 번 매칭되면 이후 규칙은 더 이상 판단하지 않습니다.

구독 업데이트 시 어떤 내용이 덮어써지는가

이 부분이 가장 흔히 실수하는 지점입니다. 구독 링크는 서비스 제공자가 호스팅하는 완전한 YAML 파일을 가리키며, 클라이언트의 "구독 업데이트" 동작은 본질적으로 이 파일을 다시 다운로드해 로컬 캐시를 전체 교체하는 것입니다. 즉 proxies(노드 목록), proxy-groups(정책 그룹 구조), rules(규칙 목록) 이 세 부분은 구독 서비스 제공자의 원본 파일에 존재하는 한, 업데이트 후 서비스 제공자가 제공하는 최신 버전으로 전체 덮어써집니다. 수동으로 추가한 사용자 정의 규칙, 조정했던 그룹 순서는 대부분 함께 사라집니다.

반면 포트, LAN 스위치, 모드 같은 기본 실행 파라미터는 클라이언트에 따라 상황이 다릅니다. 대부분의 그래픽 클라이언트는 이런 파라미터를 별도의 "런타임 오버라이드"로 저장하고 구독 파일 자체에 다시 쓰지 않기 때문에, 구독을 새로고침해도 보통 포트 설정에는 영향이 없습니다. 하지만 로컬 YAML 파일을 직접 편집한 뒤 이를 "로컬 설정"으로 불러와 사용하고 구독 링크 갱신 메커니즘을 거치지 않는다면, 애초에 "다시 다운로드"라는 동작이 없으므로 덮어쓰기 문제 자체가 존재하지 않습니다.

특히 주의해야 할 경우는, 일부 구독 서비스 제공자가 링크 생성 시 파라미터를 추가해 사용자 정의 규칙을 삽입하거나 특정 그룹을 강제로 지정할 수 있게 지원한다는 점입니다. 이런 내용 역시 매번 업데이트할 때마다 다시 기록되어 로컬 수정 사항과 공존할 수 없습니다. 판단 기준은 한 문장으로 정리됩니다. 내용이 "다운로드"를 통해 온 것이라면 "직접 입력"한 것이 아닌 한, 다음 업데이트 시 다시 다운로드되어 덮어써집니다.

여러 설정 파일 관리하기: 전환, 중복 제거, 백업

대부분의 그래픽 클라이언트(Clash Verge Rev, FlClash, ClashX Meta 등)는 여러 Profile을 동시에 저장할 수 있도록 지원하며, 화면의 목록을 통해 서로 다른 구독 또는 로컬 파일 사이를 전환해도 서로 영향을 주지 않습니다. 여러 설정을 관리할 때는 다음 원칙을 따르는 것이 좋습니다.

용도별로 나눠 저장하고, 같은 파일을 반복해서 수정하지 않기

여러 구독 서비스를 동시에 사용하거나, 하나는 일상용으로 다른 하나는 새 노드 테스트용으로 사용한다면, 이를 각각 독립된 Profile로 저장해야 합니다. 같은 파일 안에서 내용을 계속 복사해 바꿔 넣는 방식은 피하는 것이 좋습니다. 이렇게 하면 전환할 때 클라이언트 목록에서 클릭만 하면 되고 텍스트 편집이 필요 없어 오류 발생 가능성이 가장 낮습니다.

로컬 오버라이드 규칙으로 구독 업데이트에 덮어써지는 것 방지하기

특정 내부 서비스에 화이트리스트로 직접 연결을 추가하는 등 사용자 정의 규칙을 장기적으로 유지해야 한다면, 클라이언트가 제공하는 "오버라이드" 또는 "병합" 기능을 사용하는 것이 더 안전합니다. 대부분의 최신 클라이언트는 구독과 별도로 로컬 오버라이드 파일을 유지할 수 있도록 지원하며, 구독 업데이트 시에는 서비스 제공자의 원본 내용만 교체되고 로컬 오버라이드 부분은 독립적으로 유지되어 함께 사라지지 않습니다. 클라이언트에 이 기능이 없다면, 차선책으로 매번 업데이트 전에 현재 적용 중인 YAML을 수동으로 백업해두고 업데이트 후 사용자 정의 규칙 부분을 다시 붙여 넣는 방법이 있습니다.

중복 및 만료된 노드를 주기적으로 정리하기

같은 구독 계정을 오래 사용하면 노드 목록이 중복되거나 이미 서비스가 종료된 노드가 그룹에 남아 있는 경우가 생기기 쉽습니다. 다음과 같이 주기적으로 점검하는 습관을 들이는 것이 좋습니다.

1. 현재 적용 중인 Profile을 열어 proxies 개수가 구독 서비스 관리 페이지에 표시된 노드 수와 일치하는지 확인합니다
2. url-test 유형 그룹에 대해 수동으로 속도를 측정해 오랫동안 사용할 수 없는 노드를 제거합니다(일부 클라이언트는 화면에서 직접 그룹에서 제외할 수 있습니다)
3. proxy-groups에서 같은 노드가 중복 참조되어 그룹이 혼란스러워지지 않았는지 확인합니다

백업 시 필요한 최소 항목

새 기기로 이전하거나 클라이언트를 다시 설치해야 할 경우, 다음 두 가지만 보관해두면 기존 사용 상태를 거의 그대로 복원할 수 있습니다. 구독 링크 자체(언제든 최신 노드와 규칙을 다시 가져오는 용도), 그리고 로컬 오버라이드 또는 사용자 정의 규칙 파일(있는 경우)입니다. 클라이언트가 캐시해 둔 임시 파일까지 별도로 백업할 필요는 없으며, 이는 다음번 구독을 가져올 때 자동으로 다시 생성됩니다.

흔한 문제 해결 상황과 관련 필드

앞서 설명한 필드 구분을 참고하면, 자주 발생하는 몇 가지 문제는 대부분 특정 영역으로 좁혀서 원인을 찾을 수 있습니다.

• 인터넷에 연결되지 않거나 프록시가 동작하지 않음: 먼저 기본 실행 파라미터 영역의 포트 설정과 mode 값이 예상대로 되어 있는지 확인합니다
• 특정 사이트가 원하지 않는 노드를 경유함: rules 영역으로 돌아가 순서대로 더 앞쪽에 있는 규칙이 먼저 매칭되지 않았는지 확인합니다. 규칙 목록은 위에서부터 매칭되면 즉시 멈추는 방식입니다
• 노드를 전환해도 적용되지 않음: 해당 proxy-groups의 type이 select인지 확인하고, 클라이언트 화면에서 선택한 그룹과 규칙에서 참조하는 그룹 이름이 일치하는지 확인합니다
• 구독 업데이트 후 사용자 정의 규칙이 사라짐: 이는 앞서 설명한 덮어쓰기 메커니즘에 따른 정상적인 동작이며, 사용자 정의 내용은 로컬 오버라이드 방식으로 저장해야 합니다

Profile을 알 수 없는 YAML 텍스트 뭉치가 아니라 구조화된 설정 설명서로 이해하면, 대부분의 문제 해결 작업이 훨씬 근거 있게 진행됩니다. 화면의 어떤 스위치가 예상과 다르게 동작할 때는, 클라이언트를 반복해서 재설치하기보다 해당 필드의 값을 먼저 확인하는 것이 더 효과적입니다.