Clash 설정 파일(Profile)이란? 구조 분석과 여러 설정 전환 관리 방법

Profile은 구독 주소가 아니라 코어가 실제로 읽는 실행 설정입니다

Clash, Clash Meta 또는 mihomo 클라이언트에서 Profile은 보통 ‘설정’ 또는 ‘설정 파일’을 뜻합니다. 최종적으로는 YAML 문서이며, 노드뿐 아니라 수신 포트, DNS, 프록시 그룹, 분할 규칙, TUN 매개변수와 제어 인터페이스까지 정의합니다. 코어가 시작할 때 읽는 것은 브라우저에 입력한 구독 URL이 아니라 이 설정 파일입니다.

구독 주소는 설정을 가져오는 원격 경로에 가깝습니다. 클라이언트가 구독 URL에 요청을 보내 서버 응답을 내려받고, 그 결과를 로컬 Profile로 저장합니다. 이후 잠시 오프라인이 되더라도 로컬 파일이 남아 있고 노드 인증 정보가 유효하면 대개 해당 설정을 계속 불러올 수 있습니다. ‘구독 업데이트’를 누르면 클라이언트가 다시 내려받아 해당 로컬 내용을 덮어쓰거나 새로 만듭니다.

완전한 설정에는 보통 무엇이 들어갈까

최소 실행 구조는 코어 버전과 클라이언트 구성에 따라 다르지만, 자주 쓰이는 필드는 다음 여섯 계층으로 나눌 수 있습니다.

• port, socks-port, mixed-port: 로컬 프록시 수신 포트입니다.
• proxies 또는 proxy-providers: 개별 노드나 원격 노드 모음입니다.
• proxy-groups: 수동 선택, 자동 속도 측정, 장애 조치 등의 정책 그룹입니다.
• rules 또는 rule-providers: 도메인, IP, 프로세스와 규칙 집합의 매칭 순서입니다.
• dns: DNS 수신, 업스트림 서버, Fake-IP 또는 Redir-Host 동작을 설정합니다.
• tun, sniffer, external-controller: 시스템 트래픽 가로채기, 도메인 스니핑과 제어 인터페이스를 담당합니다.

아래는 계층을 이해하기 위한 간단한 예시입니다. 7890 포트는 HTTP와 SOCKS 혼합 진입점으로, 9090은 외부 제어 인터페이스로 사용합니다. 실제 인증 정보는 생략했으므로 연결 가능한 설정으로 바로 사용해서는 안 됩니다.

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

proxies:
  - name: Tokyo-A
    type: ss
    server: 203.0.113.10
    port: 443
    cipher: aes-128-gcm
    password: example-password

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - Tokyo-A
      - DIRECT

  - name: AUTO
    type: url-test
    proxies:
      - Tokyo-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

세 가지 핵심 구간: proxies, proxy-groups, rules

Profile을 이해할 때는 수백 줄의 DNS와 규칙 집합부터 볼 필요가 없습니다. 세 가지 핵심 구간만 파악하면 됩니다. proxies가 출구를 제공하고, proxy-groups가 출구를 구성하며, rules가 각 연결을 어느 그룹에 맡길지 결정합니다. 세 요소는 하위 계층에서 상위 계층으로 이어지는 참조 체계입니다.

proxies: 노드 본체와 연결 매개변수

proxies는 정적 노드 배열입니다. 각 항목에는 최소한 이름, 프로토콜, 서버 주소, 포트와 인증 정보가 들어갑니다. 프로토콜에 따라 Shadowsocks의 암호화 방식, Trojan의 비밀번호와 TLS 매개변수, VMess의 UUID, VLESS의 흐름 제어와 전송 설정 같은 필드가 추가됩니다.

노드 이름은 현재 설정 안에서 식별 가능해야 합니다. 프록시 그룹은 이름으로 노드를 참조하므로 노드 이름을 바꿀 때는 proxy-groups도 함께 확인해야 합니다. 그룹에 이전 이름이 남아 있으면 설정 검증이 바로 실패하거나, 화면에 빈 그룹 또는 사용할 수 없는 구성원이 표시될 수 있습니다.

proxies:
  - name: HK-01
    type: trojan
    server: hk01.example.net
    port: 443
    password: change-me
    sni: hk01.example.net
    udp: true

대규모 구독은 보통 모든 노드를 주 파일에 직접 작성하지 않고 proxy-providers를 사용합니다. Provider는 원격에서 노드 모음을 가져와 지정한 주기로 업데이트할 수 있습니다. 다만 ‘노드 출처’만 담당할 뿐, 이 노드를 어떤 사이트에 사용할지는 자동으로 결정하지 않습니다.

proxy-groups: 노드를 실행 가능한 정책으로 구성하기

proxy-groups는 클라이언트의 ‘프록시’ 화면에서 사용자가 실제로 조작하는 대상입니다. 일반적인 유형은 네 가지입니다.

그룹은 노드를 참조할 수도 있고 다른 그룹을 참조할 수도 있습니다. 흔히 전체 그룹 PROXY를 만들고 HK-AUTO, JP-AUTO, Fallback, DIRECT를 넣습니다. 규칙은 전체 그룹이나 업무 그룹만 참조하므로 하위 노드가 업데이트되어도 규칙을 하나씩 수정할 필요가 없습니다.

proxy-groups:
  - name: Streaming
    type: select
    proxies:
      - HK-AUTO
      - JP-AUTO
      - PROXY

  - name: HK-AUTO
    type: url-test
    use:
      - provider-main
    filter: "(?i)홍콩|HK|Hong Kong"
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 100

rules: 위에서 아래로, 일치하면 즉시 중단

rules는 순서가 있는 매칭 목록입니다. 요청은 첫 번째 규칙부터 검사하며, 일치하면 지정된 정책에 연결을 넘기고 아래 규칙은 더 이상 확인하지 않습니다. 구체적인 규칙을 포괄적인 규칙보다 앞에 배치하고 마지막에는 MATCH로 처리합니다.

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - PROCESS-NAME,git.exe,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Fallback

이 구간에서는 api.example.com이 직접 연결됩니다. 그 밖의 example.com 하위 도메인은 프록시를 사용합니다. Windows에서 git.exe가 생성하고 코어가 식별할 수 있는 연결은 PROXY로 보냅니다. 로컬 네트워크 주소는 직접 연결하고, 나머지 중국 본토 IP도 직접 연결하며, 끝까지 일치하지 않은 트래픽은 Fallback으로 보냅니다.

Profile과 구독 업데이트: 무엇이 덮어써질까

구독으로 생성된 YAML을 직접 수정하면 단기적으로는 적용되지만 다음 업데이트에서 변경 사항이 모두 사라질 수 있습니다. 이유는 간단합니다. 클라이언트가 원격 응답을 해당 Profile의 기준 버전으로 보고, 업데이트할 때 노드·정책 그룹·규칙을 다시 기록하기 때문입니다. 별도의 오버라이드 방식이 없다면 직접 추가한 PROCESS-NAME, DNS 업스트림이나 사용자 지정 그룹도 원격 내용으로 대체됩니다.

세 가지 출처의 동작 차이

1. 로컬 파일 가져오기: 디스크에서 YAML을 불러오며 보통 원격에 자동으로 접속하지 않습니다. 직접 관리하는 설정에 적합합니다.
2. 구독 URL 가져오기: 클라이언트가 설정한 주기로 원격 서버에 요청합니다. 일반적인 업데이트 간격은 24시간이며 수동 실행도 가능합니다.
3. Provider 분리: 주 설정에는 DNS, 그룹과 규칙만 남기고 proxy-providers로 노드만 업데이트합니다. 규칙 구조를 장기간 관리해야 하는 경우에 적합합니다.

일반적인 GUI 클라이언트를 예로 들면 가져오기 경로는 보통 ‘설정’ → ‘새로 만들기’ → ‘URL에서 가져오기’이며, 업데이트는 해당 설정 카드의 ‘업데이트’ 버튼에서 실행합니다. 포트는 대개 ‘설정’ → ‘매개변수 설정’ → ‘혼합 포트’에서 조정합니다. 클라이언트마다 Profile을 ‘설정’, ‘구독’ 또는 ‘설정 관리’라고 부르고 버튼 위치도 다를 수 있지만 기본 관계는 같습니다.

mihomo의 Provider 구조를 사용하면 원격 노드를 로컬 파일에 캐시할 수 있습니다. 아래의 interval: 86400은 86400초, 즉 24시간마다 한 번 확인한다는 뜻입니다. 상태 확인은 600초마다 실행됩니다.

proxy-providers:
  provider-main:
    type: http
    url: https://subscription.example.net/clash
    path: ./providers/provider-main.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

클라이언트가 오버라이드, 확장 스크립트 또는 Merge 설정을 지원한다면 로컬 DNS, 규칙과 정책 그룹을 오버라이드 계층에 우선 배치하세요. 원격에는 노드만 맡기고 개인 설정은 로컬에 보관하는 방식입니다. 그러면 노드 80개를 업데이트해도 개발 환경용 직접 연결 규칙까지 함께 덮어쓰지 않습니다.

여러 서비스·용도별 설정을 이름 짓고 함께 관리하는 방법

설정이 많아지면 YAML보다 먼저 무너지는 것은 대개 이름 체계입니다. 목록에 ‘새 설정’, ‘구독 2’, ‘테스트 복사본 최종판’이 늘어나면 몇 주 뒤 어떤 설정이 사용 중이고 무엇을 지워도 되는지 판단하기 어렵습니다. 이름에는 출처, 용도와 업데이트 시점을 직접 드러내는 것이 좋습니다.

권장 이름 형식

[출처]-[용도]-[업데이트 방식]-[날짜]

서비스A-일상-자동-20260625
서비스B-스트리밍-자동-20260625
로컬-개발 분할-수동-20260625
긴급-기본 직접 연결-수동-20260625

날짜를 노드가 업데이트될 때마다 바꿀 필요는 없습니다. 설정 구조를 마지막으로 직접 조정한 시점을 기록하는 용도로 더 적합합니다. 자동 구독의 실제 업데이트 시점은 클라이언트 기록에 맡기세요. 매일 이름을 바꾸면 불필요한 잡음만 늘어납니다.

출처별로 나눌까, 용도별로 나눌까

처음에는 출처마다 Profile 하나를 유지하는 것이 가장 간단합니다. 규칙 요구 사항이 안정된 뒤 ‘주 설정 하나와 여러 Provider’ 구조로 옮기세요. 처음부터 모든 출처, 수십 개의 업무 그룹과 수만 개의 규칙을 한 파일에 넣는 것은 권장하지 않습니다. 들여쓰기 하나의 오류가 장애 진단 범위를 크게 넓힐 수 있습니다.

비상용 설정 하나를 보관하기

비상용 설정은 복잡할 필요가 없습니다. 사용 가능한 노드 하나, select 그룹 하나와 기본 규칙 몇 개만 남기고 불필요한 TUN과 복잡한 DNS는 끄세요. 주 설정 업데이트가 실패하거나 규칙 집합 주소에 접근할 수 없거나 TUN 드라이버에 문제가 생겼을 때 비상용 설정으로 전환하면, 먼저 기본 연결을 복구한 뒤 원인을 확인할 수 있습니다.

비상용 설정은 로컬 YAML을 사용하고, 시작할 때마다 원격 규칙 집합을 내려받는 방식은 피하세요. 매달 한 번 수동으로 불러와 설정 검증 통과 여부, 노드 연결 가능 여부와 7890 포트를 다른 프로그램이 사용하고 있지 않은지 확인합니다.

Profile을 전환할 때 클라이언트 내부에서 일어나는 일

Profile 전환은 단순히 노드 목록을 바꾸는 작업이 아닙니다. 클라이언트는 보통 현재 코어를 중지하거나 다시 불러온 뒤 새 YAML을 코어에 넘겨 검증하고, 수신 포트·DNS·TUN 네트워크 인터페이스와 정책 상태를 다시 구성합니다. 설정이 복잡할수록 다시 불러오는 과정에서 관여하는 시스템 구성 요소가 많아집니다.

기존 연결이 자동으로 이전되지는 않습니다

전환 전에 이미 만들어진 TCP 연결은 끊길 수도 있고 시간 초과까지 유지될 수도 있으며, 구체적인 동작은 클라이언트의 다시 불러오기 방식에 따라 달라집니다. 새 연결은 새 규칙으로 처리됩니다. 대용량 파일을 다운로드하거나 Git push를 실행 중이거나 SSH 세션을 유지하고 있다면 Profile을 함부로 전환하지 마세요.

재현 가능한 전환 점검은 다음처럼 진행할 수 있습니다. 먼저 연결 패널에서 활성 연결 수를 확인합니다(예: 23개). 다운로드 작업을 중지하고 설정을 전환한 뒤 코어 상태가 ‘실행 중’으로 돌아올 때까지 기다립니다. 그런 다음 테스트 도메인을 열어 새 연결에 적용된 규칙을 확인합니다. 일반적인 데스크톱 환경에서는 간단한 설정을 1~3초 안에 다시 불러올 수 있지만, TUN·원격 규칙 집합·다수의 Provider를 활성화하면 더 오래 걸릴 수 있습니다.

정책 선택은 저장될 수도, 초기화될 수도 있습니다

일부 클라이언트는 정책 그룹 이름별로 마지막 선택을 저장합니다. 예를 들어 두 Profile에 모두 PROXY 그룹이 있으면 전환 후 이전에 선택한 노드를 복원하려고 할 수 있습니다. 하지만 새 설정에 같은 이름의 노드가 없으면 해당 그룹의 첫 번째 사용 가능한 구성원으로 돌아갑니다.

따라서 여러 설정에서 동일한 정책 의미를 공유한다면 PROXY, Streaming, Fallback 같은 그룹 이름을 통일해도 좋습니다. 의미가 다른 그룹에 억지로 같은 이름을 붙이지는 마세요. 화면에서는 선택이 유지된 것처럼 보여도 실제 출구 로직은 달라질 수 있습니다.

TUN 설정 전환 시 추가로 확인할 항목

TUN 모드는 더 많은 시스템 트래픽을 가로챕니다. 두 Profile에서 각각 다른 stack, DNS 하이재킹 또는 라우팅 제외 항목을 설정했다면 전환 과정에서 가상 네트워크 인터페이스와 라우팅 테이블을 다시 만들어야 할 수 있습니다. 전환 후에는 다음을 확인하세요.

• TUN 상태가 시스템 프록시만 남은 채 꺼진 것이 아니라 다시 활성화되었는지 확인합니다.
• 192.168.1.1 같은 로컬 네트워크 주소에 여전히 직접 연결할 수 있는지 확인합니다.
• DNS 요청이 새 설정의 수신 포트(예: 0.0.0.0:1053)로 전달되는지 확인합니다.
• 제외해야 할 프로세스나 네트워크 대역이 여전히 route-exclude-address에 포함되어 있는지 확인합니다.
• 브라우저, 명령줄과 시스템 프록시를 읽지 않는 프로그램이 모두 예상대로 트래픽을 분할하는지 확인합니다.

실행 가능한 설정 관리 절차

Profile 관리에 복잡한 도구는 필요하지 않습니다. 가져오기, 검증, 전환과 되돌리기를 분리하고 현재 유일하게 사용 가능한 설정에서 바로 시행착오를 하지 않는 것이 핵심입니다.

1단계: 복사한 뒤 수정하기

DNS, TUN 또는 규칙을 수정하기 전에 현재 설정을 복사하고 날짜를 붙이세요. 원본은 그대로 보관합니다. 클라이언트에 복사 기능이 없다면 YAML을 내보내 별도 디렉터리에 저장하세요. 수정본은 먼저 ‘테스트’라는 이름으로 두고 검증이 끝난 뒤 주 설정을 교체합니다.

2단계: 먼저 구문 검증하기

YAML은 공백으로 계층을 표현하므로 Tab, 잘못된 들여쓰기와 따옴표 누락이 로드 실패를 일으킬 수 있습니다. 특히 콜론이 포함된 이름, 정규 표현식과 URL을 확인하세요. 코어 오류에 특정 줄 번호가 표시되면 해당 줄 위쪽의 목록 들여쓰기부터 살펴보세요. 오류 위치는 파서가 더 이상 진행할 수 없게 된 지점일 뿐, 항상 문제의 시작점은 아닙니다.

# 오류가 나기 쉬운 예: 콜론이 포함된 그룹 이름에 따옴표가 없음
- name: Work: Git

# 더 안전한 방식
- name: "Work: Git"

3단계: 고정 샘플로 트래픽 분할 검증하기

네 가지 고정 샘플을 준비하세요. 국내 도메인 하나, 프록시가 필요한 도메인 하나, 로컬 네트워크 주소 하나, 지정 프로세스 하나입니다. 클라이언트 연결 로그를 열고 각 항목의 규칙 유형, 적용 정책과 최종 노드를 확인하세요. 브라우저로 IP만 확인하지 마세요. 브라우저 캐시, HTTP/3와 기존 연결이 판단을 방해할 수 있습니다.

1. 국내 도메인은 DIRECT 또는 예상한 국내 정책과 일치해야 합니다.
2. 프록시 도메인은 마지막 MATCH로 바로 떨어지지 않고 업무 그룹과 일치해야 합니다.
3. 192.168.0.0/16 같은 사설 네트워크 대역은 직접 연결 상태를 유지해야 합니다.
4. 지정 프로세스 규칙은 해당 프로그램이 새 연결을 만든 뒤 로그에 나타나야 합니다.
5. DNS 로그에 시간 초과나 반복 조회가 계속 발생해서는 안 됩니다.

4단계: 되돌릴 지점 기록하기

현재 안정적인 설정의 파일 이름, 혼합 포트, TUN 스위치와 주 정책 선택을 기록해 두세요. 테스트 설정에 문제가 생기면 ‘설정’ → ‘안정적인 설정’으로 전환한 다음 ‘설정’ → ‘매개변수 설정’에서 7890 등의 포트가 복구되었는지 확인합니다. 코어가 자동으로 다시 시작되지 않으면 ‘중지’를 한 번 누른 뒤 ‘시작’을 수동으로 실행하세요.

자주 발생하는 문제: 가져오기는 성공했지만 설정을 사용할 수 없음

설정 목록은 있는데 프록시 그룹이 비어 있음

먼저 proxies에 노드가 있는지 또는 proxy-providers 다운로드가 성공했는지 확인합니다. 그런 다음 그룹의 proxies 이름과 Provider의 use 이름이 완전히 일치하는지 확인하세요. 이름은 대소문자와 문자를 구분하며 불필요한 공백 하나만 있어도 참조가 실패합니다.

업데이트 후 사용자 지정 규칙이 사라짐

구독 결과물을 직접 수정했을 때 흔히 나타나는 결과입니다. 사용자 지정 내용을 클라이언트 오버라이드 계층으로 옮기거나, 로컬 주 설정을 만들고 Provider로 원격 노드를 불러오세요. 클라이언트가 오버라이드를 지원하지 않는다면 로컬 복사본을 보관하고 수동으로 병합해야 합니다. 구독 캐시 파일을 장기적인 편집 대상으로 계속 사용하지 마세요.

설정을 전환한 뒤에도 브라우저가 이전 노드를 사용함

먼저 시크릿 창을 새로 열거나 브라우저를 완전히 종료해 연결 재사용을 배제합니다. 그런 다음 연결 패널에 새 연결이 생성되었는지 확인하세요. 새 연결도 이전 노드를 사용한다면 동명의 정책 그룹이 과거 선택을 복원했는지, 규칙이 실제로 다른 그룹을 참조하고 있지는 않은지 확인합니다. TUN을 사용 중이라면 가상 네트워크 인터페이스가 새 설정에 맞게 다시 로드되었는지도 확인해야 합니다.

규칙을 추가했지만 항상 MATCH와 일치함

규칙 순서, 도메인 유형과 DNS 동작을 확인하세요. DOMAIN은 완전한 도메인만 매칭하고 DOMAIN-SUFFIX는 하위 도메인까지 포함합니다. IP 규칙은 연결 대상에서 해당 IP를 얻을 수 있어야 하며, no-resolve가 있으면 매칭을 위해 DNS 조회를 능동적으로 실행하지 않습니다. 프로세스 규칙은 플랫폼과 코어가 프로세스 정보를 가져올 수 있는지에도 영향을 받습니다.

결론: Profile을 버전 관리 가능한 실행 설정으로 다루기

Profile의 핵심은 ‘노드가 얼마나 많은가’가 아니라 진입점, 출구, 정책과 매칭 순서를 코어가 실행할 수 있는 하나의 설정으로 구성하는 데 있습니다. proxies가 출구를 제공하고, proxy-groups가 정책을 조합하며, rules가 연결을 분배합니다. DNS와 TUN은 도메인과 시스템 트래픽이 이 경로에 어떻게 들어오는지를 결정합니다.

여러 설정을 함께 사용할 때는 읽기 쉬운 이름을 정하고, 자동 구독과 로컬 설정을 구분하며 비상용 Profile 하나를 보관하세요. 업데이트 후에는 노드·정책 그룹·규칙 적용을 확인하고, 전환 전에는 중요한 연결을 중지한 뒤 전환 후 포트·DNS·TUN을 점검합니다. 이렇게 하면 구독이나 규칙이 바뀌어도 작동하는 상태로 빠르게 돌아갈 수 있습니다.