Clash 설정 파일이란: Profile 구조 분석과 다중 프로필 전환 관리

Profile은 단순한 노드 목록이 아닙니다

Clash 클라이언트에서 Profile은 보통 코어가 불러올 수 있는 하나의 설정 파일을 뜻합니다. 구독 주소에서 가져올 수도 있고, 로컬 config.yaml을 직접 불러올 수도 있습니다. 정상적으로 사용할 수 있는 설정에는 서버 주소뿐 아니라 수신 포트, DNS 동작, 프록시 노드, 프록시 그룹, 분할 라우팅 규칙, TUN 매개변수까지 포함됩니다. Profile을 전환한다는 것은 클라이언트가 이 전체 실행 상태를 다시 불러오는 과정입니다.

구독 서비스가 반환하는 내용이 항상 완전한 Clash YAML인 것은 아닙니다. 일부 링크는 Base64로 인코딩된 노드 목록을 반환하므로 구독 변환 서비스로 Clash 형식을 만들어야 합니다. 반면 proxies, proxy-groups, rules가 포함된 YAML을 바로 반환하는 링크도 있습니다. 가져오기에 성공했다는 것은 클라이언트가 텍스트를 받아들였다는 의미일 뿐이며, 실제 인터넷 연결 여부는 필드 호환성, 노드 유효성, 규칙 참조 관계에 따라 달라집니다.

설정 파일을 불러올 때 일어나는 일

클라이언트가 YAML을 읽고 들여쓰기, 필드 형식, 필수 매개변수를 확인합니다.
Clash 또는 mihomo 코어가 로컬 수신 포트를 열고, 예를 들어 HTTP와 SOCKS 혼합 포트 7890을 설정합니다.
코어가 노드와 프록시 그룹을 만들고 각 그룹이 참조하는 구성원을 해석합니다.
규칙은 위에서 아래 순서로 매칭기에 전달되며, 규칙 제공자는 필요할 때 원격 콘텐츠를 다운로드합니다.
TUN을 활성화하면 Android 클라이언트가 시스템 VPN 권한을 요청하고 가상 네트워크 인터페이스를 만듭니다.

이 과정 중 어느 한 단계라도 실패하면 “설정은 가져왔지만 시작할 수 없음”과 같은 문제가 발생할 수 있습니다. 예를 들어 YAML 들여쓰기가 잘못되면 파싱 단계에서 중단되고, 프록시 그룹이 존재하지 않는 노드 이름을 참조하면 설정 검증 단계에서 오류가 발생합니다. 원격 규칙 집합에 접근할 수 없다면 해당 규칙 집합에 의존하는 분할 라우팅 결과만 영향을 받을 수도 있습니다.

config.yaml 핵심 필드 단계별 분석

YAML은 들여쓰기로 계층을 표현하며, 일반적으로 공백 두 칸을 사용하고 탭은 사용하지 않습니다. 아래는 구조를 이해하기 위한 간단한 예시입니다. 서버 주소, 인증 정보, 프로토콜 매개변수는 필드 위치를 보여주기 위한 것일 뿐이므로 실제 연결 설정으로 그대로 사용하면 안 됩니다.

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

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

proxies:
  - name: HK-A
    type: ss
    server: example.net
    port: 443
    cipher: aes-128-gcm
    password: example-password

proxy-groups:
  - name: 노드 선택
    type: select
    proxies:
      - HK-A
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,노드 선택
  - GEOIP,CN,DIRECT
  - MATCH,노드 선택

기본 수신 설정과 실행 모드

mixed-port: 7890은 하나의 포트에서 HTTP와 SOCKS5 프록시 연결을 모두 받는다는 뜻입니다. 데스크톱 프로그램에서는 시스템 프록시를 127.0.0.1:7890으로 지정하는 경우가 많습니다. Android 클라이언트는 주로 VpnService 또는 TUN으로 트래픽을 처리하지만, 혼합 포트는 LAN 디버깅이나 특정 앱의 수동 설정에도 사용할 수 있습니다.

mode: rule: rules를 위에서 아래로 매칭하는 방식으로, 일상적인 사용에서 가장 일반적입니다.
mode: global: 대부분의 트래픽을 전역 프록시 그룹으로 보내며, 일반적인 분할 라우팅 규칙을 순서대로 판단하지 않습니다.
mode: direct: 트래픽을 프록시 없이 직접 연결합니다. 문제가 프록시 경로에서 발생했는지 임시로 확인할 때 적합합니다.
allow-lan: false: LAN 기기에 로컬 프록시 포트를 개방하지 않습니다. 공유가 필요하다면 수신 주소와 시스템 방화벽도 함께 확인해야 합니다.
log-level: info: 일반적인 실행 기록을 남깁니다. 짧은 시간 동안 문제를 진단할 때는 debug로 바꾼 뒤, 완료되면 다시 복원하세요.

proxies: 실제 출구 노드

proxies 아래의 각 항목은 하나의 노드를 나타냅니다. 프로토콜마다 필요한 필드가 다릅니다. 예를 들어 Shadowsocks는 cipher와 password를 사용하고, Trojan은 일반적으로 password와 TLS 서버 이름 등의 매개변수를 사용합니다. mihomo는 더 많은 프로토콜과 확장 필드를 지원하지만, 그렇다고 모든 구버전 Clash 코어가 이를 인식하는 것은 아닙니다.

name은 설정 내부에서 참조할 때 사용하는 키입니다. 프록시 그룹에 입력한 이름은 공백, 대소문자, 기호까지 포함해 노드 이름과 완전히 일치해야 합니다. 두 노드의 이름이 같으면 일부 클라이언트는 로드를 거부하고, 다른 구현에서는 앞선 항목을 덮어쓸 수 있으므로 구독 생성 단계에서 이름을 고유하게 유지해야 합니다.

proxy-groups: 선택과 자동 테스트

프록시 그룹은 여러 노드 또는 다른 프록시 그룹을 하나의 출구로 묶어 규칙에서 참조할 수 있게 합니다. 일반적인 유형으로는 수동 선택 방식인 select, 테스트 결과에 따라 선택하는 url-test, 장애 전환용 fallback, 부하 분산용 load-balance가 있습니다.

proxy-groups:
  - name: 자동 선택
    type: url-test
    proxies:
      - HK-A
      - SG-A
      - JP-A
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80

이 설정은 600초마다 테스트를 실행합니다. tolerance: 80은 지연 시간 차이가 80 ms를 넘지 않으면 현재 노드를 자주 바꾸지 않는다는 뜻입니다. 간격을 30초로 줄이면 네트워크 요청과 백그라운드 깨우기 횟수가 늘어나므로, 모바일 기기에서는 일반적으로 지속적인 고빈도 테스트가 필요하지 않습니다.

rules: 위에서 아래로 이루어지는 최초 매칭

Clash 규칙은 모든 연결에 대해 모든 조건을 실행하는 방식이 아니라, 순서대로 확인해 처음 일치하는 항목을 찾는 방식입니다. 더 구체적인 도메인 규칙을 범위가 넓은 규칙보다 앞에 배치해야 하며, 마지막에는 보통 MATCH로 남은 트래픽을 처리합니다. MATCH,DIRECT를 첫 줄에 두면 뒤에 있는 프록시 규칙은 적용될 기회를 얻지 못합니다.

DOMAIN,api.example.com,노드 선택: 완전한 도메인 이름만 매칭합니다.
DOMAIN-SUFFIX,example.com,노드 선택: 주 도메인과 하위 도메인을 매칭합니다.
IP-CIDR,192.168.0.0/16,DIRECT: 지정한 IPv4 대역을 매칭합니다.
GEOIP,CN,DIRECT: IP 지리 데이터베이스를 기준으로 매칭합니다.
MATCH,노드 선택: 앞선 규칙에서 매칭되지 않은 연결을 처리합니다.

DNS, Fake-IP, TUN 매개변수의 연동 방식

DNS 필드는 도메인을 해석하는 방식을 정하지만, 트래픽의 출구까지 단독으로 결정하지는 않습니다. 도메인이 DNS 모듈에서 처리된 뒤에도 연결은 규칙 시스템으로 들어가야 합니다. fake-ip을 활성화하면 로컬 DNS가 매핑 주소를 반환하고, 코어가 이 매핑을 통해 도메인을 복원해 규칙을 매칭합니다. 이를 통해 앱이 자체적으로 DNS를 해석해 도메인 규칙이 무효화되는 문제를 줄일 수 있습니다.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query
  fallback:
    - https://1.1.1.1/dns-query

tun:
  enable: true
  stack: mixed
  auto-route: true
  strict-route: true
  dns-hijack:
    - any:53

198.18.0.0/16은 흔히 사용되는 Fake-IP 매핑 대역입니다. 앱이 이 대역으로 연결한다고 해서 인터넷상의 같은 이름의 주소에 접속 중이라는 뜻은 아닙니다. mihomo 코어가 도메인과 매핑 주소의 관계를 관리한 다음 연결을 규칙과 대상 노드로 전달합니다.

Fake-IP 필터가 필요한 경우

LAN 기기 검색, 일부 게임 플랫폼, 실제 LAN 주소에 의존하는 앱은 Fake-IP를 사용하기에 적합하지 않을 수 있습니다. 이때 fake-ip-filter에 정확한 도메인이나 와일드카드 규칙을 추가할 수 있습니다. 필터 범위를 모든 주요 도메인으로 넓히면 도메인 규칙의 완성도가 떨어지고, 앱이 프록시 DNS를 우회하는 문제가 다시 나타날 수 있으므로 주의해야 합니다.

TUN 설정과 Android 권한 상태는 별개입니다

설정의 tun.enable은 코어 매개변수일 뿐입니다. Android에서 VPN 인터페이스를 만들 수 있는지는 시스템 VpnService 권한이 결정합니다. 처음 시작할 때는 보통 시스템 연결 요청에서 승인이 필요하며, 동시에 다른 VPN 앱이 실행 중이면 새 인터페이스를 만들지 못할 수 있습니다.

Android 클라이언트마다 메뉴 구성과 이름이 완전히 같지는 않습니다. 일반적인 경로는 「설정」→「환경 설정」→「TUN 모드」이며, 홈 화면의 서비스 카드에서 바로 활성화할 수도 있습니다. stack, 라우팅 제외 항목, DNS 하이재킹을 변경한 뒤에는 서비스를 중지했다가 다시 시작해 기존 연결과 라우팅 테이블을 새로 만들어야 합니다.

구독 업데이트로 덮어써지는 항목

원격 Profile에는 보통 구독 URL이 저장됩니다. 클라이언트가 업데이트를 실행하면 해당 주소에서 내용을 다시 내려받은 뒤, 해당 설정에 연결된 원격 스냅샷을 교체합니다. 노드 추가·삭제, 프록시 그룹 구성원, 규칙 순서가 새 콘텐츠에 따라 달라질 수 있습니다. 다운로드한 YAML을 직접 편집해도 다음 업데이트 때 대개 덮어써집니다.

원격 콘텐츠, 로컬 덮어쓰기, 실행 설정

세 가지 상태를 구분하면 “분명히 수정했는데 적용되지 않는” 문제를 피하는 데 도움이 됩니다. 첫 번째는 구독 서버가 반환한 원본 설정, 두 번째는 클라이언트가 저장한 로컬 Profile, 세 번째는 덮어쓰기·스크립트·호환성 변환을 거쳐 코어에 전달되는 최종 설정입니다. 화면에 표시되는 내용은 두 번째 계층일 수 있지만, 로그에 기록된 실제 매개변수는 세 번째 계층에서 가져옵니다.

먼저 현재 Profile 이름과 업데이트 시간을 기록합니다. 예: 2026-07-30 09:40.
구독을 수동으로 업데이트하고 반환 상태가 정상인지 확인한 뒤 노드 수가 바뀌었는지 점검합니다.
설정 미리보기를 열고 proxy-groups와 rules가 여전히 유효한 이름을 참조하는지 확인합니다.
「설정」→「환경 설정」에서 DNS, 라우팅, 덮어쓰기 옵션을 확인합니다.
설정을 다시 불러오거나 서비스를 재시작한 다음 연결 로그에서 실제로 매칭된 규칙과 프록시 그룹을 확인합니다.

자동 업데이트 간격은 구독 내용이 바뀌는 빈도에 맞춰 설정해야 합니다. 노드 정보가 하루에 한 번만 변경된다면 15분마다 가져올 필요가 없습니다. 일반적인 설정은 1440분부터 시작할 수 있으며, 일시적으로 변경 사항을 동기화해야 할 때만 수동 업데이트를 실행하세요. 간격이 지나치게 짧으면 백그라운드 요청과 실패 재시도만 늘어납니다.

로컬에 보관하기 적합한 변경 사항

고정된 LAN 직접 연결 규칙, 개인 도메인 규칙, 기기 전용 DNS 매개변수는 원격 파일을 직접 수정하기보다 덮어쓰기 계층으로 관리하는 편이 좋습니다. 클라이언트가 Merge, Mixin 또는 덮어쓰기 기능을 지원한다면 새 필드를 구독 결과와 병합할 수 있습니다. 병합하기 전에 배열 처리 방식을 확인해야 합니다. 구현에 따라 rules를 추가하기도 하고 전체를 교체하기도 합니다.

규칙 순서는 특히 민감합니다. 개인 직접 연결 규칙을 마지막 MATCH 뒤에 추가하면 절대 매칭되지 않습니다. 올바른 방법은 범위가 넓은 규칙과 최종 규칙 앞에 삽입한 뒤, 로그에서 DOMAIN-SUFFIX 또는 IP-CIDR 같은 규칙의 매칭 기록을 확인하는 것입니다.

다중 프로필 공존과 전환 관리

회사 네트워크, 가정 네트워크, 테스트 환경을 각각 별도의 Profile로 저장할 수 있습니다. 다중 프로필의 장점은 모든 노드를 하나의 파일에 몰아넣는 것이 아니라 규칙과 매개변수를 분리하는 데 있습니다. 각 Profile에는 Daily-Meta, Office-Direct, Lab-TUN처럼 알아보기 쉬운 이름을 붙이고 출처와 용도도 기록하세요.

전환 전에 확인할 네 가지 차이

코어 호환성: 설정에 mihomo 전용 필드가 사용되었는지 확인합니다. 구버전 Clash 코어는 알 수 없는 프로토콜이나 규칙 집합 형식을 만나면 로드에 실패할 수 있습니다.
포트 사용 여부: 두 로컬 서비스가 동시에 7890 또는 DNS 포트 1053을 수신하려 하면 나중에 시작한 서비스에서 바인딩 오류가 발생합니다.
모드 상태: 일부 클라이언트는 rule, global, direct를 전역 화면 상태로 관리하므로 Profile과 함께 전환되지 않을 수 있습니다.
덮어쓰기 범위: 전역 덮어쓰기는 모든 Profile에 적용될 수 있지만, 설정별 덮어쓰기는 현재 항목에만 영향을 줍니다.

설정을 전환한 뒤에도 기존 TCP 연결이 종료될 때까지 이전 출구를 계속 사용할 수 있습니다. 확인할 때는 앱을 다시 열거나 테스트 연결을 종료한 뒤 새 로그를 관찰해야 합니다. 웹페이지만 새로 고쳐서는 새 연결이 만들어지지 않을 수 있습니다. HTTP/2와 QUIC이 기존 세션을 재사용할 수 있기 때문입니다.

백업할 때 저장해야 할 항목

직접 작성한 로컬 설정은 별도 사본으로 보관하고 수정 날짜를 기록해야 합니다. 원격 구독은 구독 주소, 덮어쓰기 규칙, 클라이언트 설정을 중점적으로 저장하면 되며, 매번 내려받은 임시 사본을 모두 원본 파일처럼 보관할 필요는 없습니다. 구독 URL에는 접근 인증 정보가 포함되는 경우가 많으므로 통제된 위치에 백업하고, 공개 로그·스크린샷·문제 제보에 붙여 넣지 마세요.

구형 클라이언트에서 Clash Meta 또는 mihomo 클라이언트로 이전할 때는 먼저 Profile 하나를 가져와 검증한 뒤 나머지 설정을 옮기세요. proxy-providers, rule-providers, 프록시 그룹 필터 표현식, TUN 필드를 중점적으로 확인해야 합니다. YAML 파싱에 성공했다고 해서 원격 제공자를 반드시 다운로드할 수 있는 것은 아니며, 현재 코어가 모든 노드 프로토콜을 지원한다는 뜻도 아닙니다.

설정 로드 실패를 진단하는 순서

설정 문제는 계층별로 점검하는 것이 좋습니다. 먼저 파일을 파싱할 수 있는지 확인하고, 다음으로 노드 연결이 가능한지, 마지막으로 규칙이 트래픽을 예상한 출구로 보내는지 확인하세요. 파싱 오류를 건너뛰고 노드만 반복해서 테스트하면 유효한 결론을 얻기 어렵습니다.

첫 번째 계층: YAML 및 필드 검증

콜론 뒤에 공백이 있는지 확인합니다. 예: mode: rule.
목록 항목 -과 상위 필드의 들여쓰기를 확인합니다.
콜론, 샵 또는 특수 기호가 포함된 이름은 따옴표로 감쌀 수 있습니다.
프록시 그룹, 규칙, 제공자가 참조하는 이름이 실제로 존재하는지 확인합니다.
클라이언트 로그에서 줄 번호를 확인하고 첫 번째 파싱 오류부터 우선 수정합니다.

두 번째 계층: 노드 및 네트워크 연결

단일 노드를 선택해 지연 시간을 테스트해도 테스트 URL의 연결 결과만 알 수 있으며, 모든 웹사이트에 접근할 수 있다는 뜻은 아닙니다. 먼저 모드를 global로 바꿔 짧게 확인한 뒤 rule로 되돌릴 수 있습니다. 전역 모드에서는 작동하지만 규칙 모드에서 작동하지 않는다면 규칙 매칭과 프록시 그룹의 현재 선택을 확인하세요. 두 모드 모두 작동하지 않으면 노드 매개변수, 시스템 시간, DNS, 네트워크 제한을 계속 점검해야 합니다.

세 번째 계층: 규칙 및 최종 출구

로그에서 대상 도메인에 해당하는 매칭 기록을 찾아 어떤 규칙과 일치했는지, 어느 프록시 그룹으로 들어갔는지, 최종적으로 어떤 노드가 선택되었는지 확인합니다. 로그에 도메인 없이 IP만 표시된다면 DNS를 Clash가 처리하는지, 앱이 자체 암호화 DNS를 사용하는지 점검하세요. 문제를 진단하는 동안 로그 수준을 debug로 높일 수 있으며, 기록이 끝나면 info로 복원합니다.

관리하기 쉬운 Profile 사용 습관 만들기

설정 관리의 핵심은 출처와 역할을 구분하는 것입니다. 구독은 노드와 기본 정책을 제공하고, 로컬 덮어쓰기는 개인 규칙을 담당하며, 클라이언트 설정은 시스템 인터페이스와 앱 동작을 담당합니다. 세 가지를 하나의 원격 파일에 섞으면 업데이트 후 무엇이 바뀌었는지 파악하기 어렵습니다.

각 Profile에 용도가 분명한 이름을 지정하고 출처 설명을 남깁니다.
업데이트 전에 현재 사용할 수 있는 노드와 프록시 그룹 선택을 기록하고, 업데이트 후 핵심 필드를 비교합니다.
개인 규칙은 반복 적용할 수 있는 덮어쓰기 계층에 넣고 삽입 위치를 확인합니다.
고빈도 자동 속도 테스트와 구독 새로고침을 줄이고, 모바일 기기에서는 백그라운드 깨우기를 우선적으로 제한합니다.
Profile을 전환한 뒤 테스트 연결을 새로 만들고, 상태 아이콘만 보지 말고 로그로 규칙을 확인합니다.
코어를 업그레이드하기 전에 설정 호환성을 확인하며, 특히 프로토콜 확장, 규칙 제공자, TUN 매개변수를 점검합니다.

Profile을 “노드, 프록시 그룹, 규칙, DNS, 시스템 트래픽 처리 매개변수를 담은 전체 스냅샷”으로 이해하면 구독 업데이트와 다중 프로필 전환을 훨씬 쉽게 파악할 수 있습니다. 문제가 발생해도 설정 파싱, 노드 연결, DNS 처리, 규칙 매칭, 시스템 라우팅을 단계별로 확인할 수 있어 같은 파일을 반복해서 삭제하고 다시 가져올 필요가 없습니다.