Clash 설정 파일 구조 완벽 해설: port부터 rules까지 YAML 읽는 법

먼저 설정 파일의 처리 흐름부터 파악하기

Clash 또는 mihomo 설정은 단순한 “노드 목록”이 아닙니다. 커널은 시작할 때 YAML을 먼저 파싱한 뒤 로컬 리스닝 포트, DNS 모듈, 프록시 노드와 정책 그룹을 구성하고, 마지막으로 rules를 위에서부터 차례로 대조해 연결을 처리합니다. 한 섹션이 문법 검사를 통과했다고 해서 다른 섹션과의 참조까지 올바른 것은 아닙니다. 규칙이 존재하지 않는 정책 그룹을 가리키거나, 정책 그룹이 이름이 바뀐 노드를 참조할 수도 있습니다.

설정을 이해할 때는 파일을 다섯 계층으로 나누어 보면 됩니다. 기본 실행 매개변수는 포트와 작동 모드를 담당하고, DNS 섹션은 도메인 이름 해석을 담당합니다. proxies는 사용할 개별 아웃바운드를 정의하며, proxy-groups는 이를 선택식 또는 자동 테스트 방식의 정책으로 묶습니다. rules는 각 연결을 최종적으로 어떤 정책에 보낼지 결정합니다. 구독 설정에는 외부 파일에서 노드나 규칙 모음을 불러오는 proxy-providers와 rule-providers가 추가되기도 합니다.

YAML에서 가장 자주 실수하는 세 가지 기본 사항

계층은 공백으로 들여쓰기하며 Tab은 사용할 수 없습니다. 일반적으로 각 계층에 공백 2칸을 사용합니다.
콜론 뒤에는 보통 공백 하나를 둡니다. 예를 들어 mode: rule처럼 작성하며, 목록 항목은 하이픈과 공백으로 시작합니다.
true, false, 숫자와 문자열은 서로 의미가 다릅니다. 포트는 7890처럼 작성하고, 특수 문자가 포함된 이름이나 비밀번호는 따옴표로 감싸는 편이 안전합니다.

일반적인 데스크톱 클라이언트에서는 「설정」→현재 설정 선택→「편집」을 통해 YAML을 열 수 있습니다. 저장한 뒤에는 「설정」→「다시 불러오기」 또는 「적용」을 실행합니다. 클라이언트마다 버튼 이름은 조금씩 다르지만 확인 순서는 같습니다. 먼저 저장하고, 커널에 파싱 오류가 없는지 확인한 다음 프록시 연결을 테스트하세요. 문제를 추적할 때는 「로그」→「로그 수준」→「debug」로 들어가고, 확인이 끝나면 info로 되돌려 디버그 정보가 장시간 쌓이지 않게 하세요.

공통 필드: 포트, 모드와 제어 인터페이스

설정 파일 앞부분에는 보통 로컬 리스닝과 커널 실행 매개변수가 들어갑니다. 다음은 로컬 데스크톱 환경에서 이해하기 쉬운 예시입니다. HTTP 프록시는 7890, SOCKS5 프록시는 7891에서 수신하고, 외부 제어 인터페이스는 로컬 루프백 주소에만 바인딩합니다.

port: 7890
socks-port: 7891
allow-lan: false
bind-address: "*"
mode: rule
log-level: info
ipv6: false
external-controller: 127.0.0.1:9090
secret: "change-this-token"

필드	주요 기능	일반적인 판단 기준
`port`	HTTP 프록시 리스닝 포트 제공	시스템 프록시는 보통 `127.0.0.1:7890`으로 설정합니다.
`socks-port`	SOCKS4 및 SOCKS5 프록시 진입점 제공	SOCKS5를 지원하는 앱은 `127.0.0.1:7891`에 연결할 수 있습니다.
`mixed-port`	하나의 포트에서 HTTP와 SOCKS 연결을 동시에 수신	사용할 때는 보통 같은 용도의 포트를 별도로 설정하지 않습니다.
`allow-lan`	LAN 기기가 이 기기의 프록시 포트에 연결할 수 있는지 결정	활성화한 뒤에도 바인딩 주소, 시스템 방화벽과 접근 제어를 확인해야 합니다.
`mode`	`rule`, `global` 또는 `direct` 선택	일상적인 사용에는 보통 `rule`을 사용합니다.
`external-controller`	그래픽 인터페이스 또는 패널에 제어 API 제공	로컬에서만 사용할 경우 `127.0.0.1`에 바인딩하는 편이 적합합니다.

mode: rule은 각 연결을 규칙 대조 과정으로 보내고, global은 모든 연결을 전역 정책으로 전달하며, direct는 직접 연결합니다. 여기서 모드는 특정 프록시 프로토콜을 뜻하지 않으며 노드 자체의 매개변수도 바꾸지 않습니다. “노드 속도 측정은 되지만 특정 사이트가 프록시를 사용하지 않는” 경우에는 먼저 실수로 직접 연결 모드로 전환되지 않았는지 확인한 다음 어떤 정책에 규칙이 매칭되었는지 살펴보세요.

LAN 공유는 스위치 하나만 바꿔서는 안 됩니다

allow-lan을 true로 바꾼 뒤에는 휴대폰이나 다른 컴퓨터에서 Clash가 실행 중인 기기의 LAN 주소를 사용해야 합니다. 예를 들어 192.168.1.20:7890을 입력해야 하며 상대 기기 자체의 127.0.0.1을 사용하면 안 됩니다. 또한 TCP 7890 포트를 허용해야 합니다. 컴퓨터 주소가 DHCP로 자동 할당된다면 라우터에 다시 연결한 뒤 주소가 바뀔 수 있으므로, 라우터에서 해당 기기에 고정 임대 주소를 설정하는 것이 좋습니다.

DNS 섹션: 해석 경로와 fake-ip 모드

DNS 설정은 도메인에서 IP 주소를 얻는 방식을 결정하며, 도메인 규칙이 안정적으로 매칭되는지에도 영향을 줍니다. mihomo에서 자주 사용하는 향상 모드로는 fake-ip과 redir-host가 있습니다. 전자는 애플리케이션에 예약 주소 풀의 매핑 주소를 반환하고, 커널이 연결을 받은 뒤 원래 도메인을 복원합니다. 후자는 전통적인 실제 주소 해석 흐름에 더 가깝습니다. TUN 모드에서 fake-ip을 사용하면 더 많은 도메인 정보를 유지할 수 있지만, 일부 LAN 서비스나 네트워크 연결 확인 기능, 실제 주소에 의존하는 앱은 필터 목록에 추가해야 합니다.

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "+.msftconnecttest.com"

default-nameserver는 주로 초기 해석을 담당하므로 일반적으로 순수 IP 형식의 DNS 주소를 입력합니다. 암호화 DNS 서버 자체를 도메인으로 적었다면 커널이 먼저 해당 도메인을 어디서 해석할지 알아야 합니다. nameserver는 일반 질의에 사용하는 업스트림입니다. mihomo의 proxy-server-nameserver는 프록시 서버 도메인 전용 해석에 사용할 수 있어 “노드 주소는 아직 해석되지 않았는데 DNS 질의가 프록시 노드를 기다리는” 의존성 문제를 줄여 줍니다.

DNS 설정은 정상인데도 사이트가 열리지 않을 때

로그에 dns resolve failed, 시간 초과 또는 인증서 연결 오류가 나타나는지 확인합니다.
시스템 또는 TUN의 DNS 요청이 실제로 커널의 리스너로 들어가는지, 기존 LAN DNS로 계속 전송되고 있지는 않은지 확인합니다.
잠시 enhanced-mode를 redir-host로 바꾸어 다시 테스트하고, 문제가 fake-ip 호환성과 관련 있는지 확인합니다.
fake-ip-filter를 확인하고, 호환성 문제가 실제로 확인된 도메인만 목록에 추가하세요. 적용 범위가 지나치게 넓은 와일드카드 규칙은 피하는 것이 좋습니다.
도메인과 IP를 각각 테스트합니다. IP는 접속되지만 도메인은 접속되지 않는다면 우선 DNS를 점검하고, 둘 다 실패한다면 정책 그룹과 노드 연결을 계속 확인하세요.

예시에 나온 198.18.0.1/16은 흔히 사용하는 fake-ip 주소 풀입니다. 앱에 이 주소가 보인다고 해서 웹사이트가 실제로 그곳에 배포된 것은 아니며, 커널이 관리하는 임시 매핑입니다. 패킷 캡처에서 198.18.x.x가 반복해서 보인다면 Clash 로그의 원래 도메인과 함께 판단해야 하며, 이를 원격 서버 주소로 바로 해석해서는 안 됩니다.

proxies: 개별 노드를 YAML로 작성하는 방법

proxies는 노드 객체 목록입니다. 각 객체에는 최소한 고유한 name, 프로토콜 type, 서버 주소 server와 포트 port가 필요하며, 나머지 필드는 프로토콜에 따라 달라집니다. 아래에서는 Shadowsocks와 SOCKS5를 사용해 구조를 보여 줍니다. 예시 도메인과 인증 정보는 형식 설명만을 위한 것입니다.

proxies:
  - name: "도쿄-SS"
    type: ss
    server: ss-node.example.com
    port: 443
    cipher: aes-128-gcm
    password: "demo-password"
    udp: true

  - name: "로컬-SOCKS"
    type: socks5
    server: 192.168.1.30
    port: 1080
    username: "proxy-user"
    password: "demo-password"
    udp: false

필드 이름은 프로토콜 정의와 일치해야 합니다. Shadowsocks는 cipher와 password를 사용하고, SOCKS5에는 username과 password를 넣을 수 있습니다. 다른 프로토콜에는 TLS, 전송 계층, 서버 이름 등의 매개변수가 추가될 수 있습니다. 그래픽 인터페이스에서 두 노드가 모두 한 줄로 표시된다고 해서 한 프로토콜의 필드를 다른 프로토콜에 그대로 복사할 수는 없습니다.

노드 이름은 사실상 참조 키입니다

name은 표시용일 뿐 아니라 정책 그룹에서 그대로 참조됩니다. 노드 정의가 “도쿄-SS”인데 정책 그룹에 “도쿄 SS”로 적으면 중간 문자가 달라 유효하지 않은 참조가 됩니다. 노드 이름을 정책 그룹과 동일하게 짓는 것도 피하세요. 로그와 규칙 대상을 확인할 때 어느 계층을 가리키는지 빠르게 판단하기 어려워집니다.

같은 목록에서는 이름을 고유하게 유지하고, “지역-프로토콜-번호”처럼 일정한 형식을 사용하는 것이 좋습니다.
콜론, 해시, 별표 또는 앞뒤 공백이 포함된 이름은 YAML이 해당 문자를 문법으로 해석하지 않도록 따옴표로 감싸야 합니다.
udp: true는 해당 노드 설정에서 UDP를 허용한다는 뜻일 뿐이며, 실제 사용 가능 여부는 프로토콜, 서버와 트래픽 가로채기 방식에 따라 달라집니다.
서버 주소에 도메인을 입력했다면 노드 도메인을 해석하는 DNS 경로도 함께 확인해야 합니다.

proxy-groups: 노드를 조작 가능한 정책으로 묶기

규칙은 보통 특정 고정 노드를 직접 가리키지 않고 정책 그룹을 가리킵니다. 덕분에 “업무 서비스”, “스트리밍”, “기본 프록시”처럼 용도별 아웃바운드를 독립적으로 선택할 수 있습니다. 정책 그룹은 클라이언트 프록시 페이지에서 주로 조작하는 대상이기도 합니다. 사용자가 전환하는 것은 규칙 자체가 아니라 특정 select 그룹에서 현재 선택된 구성원인 경우가 많습니다.

proxy-groups:
  - name: "수동 선택"
    type: select
    proxies:
      - "자동 속도 측정"
      - "도쿄-SS"
      - "로컬-SOCKS"
      - DIRECT

  - name: "자동 속도 측정"
    type: url-test
    proxies:
      - "도쿄-SS"
      - "로컬-SOCKS"
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    lazy: true

  - name: "기본 프록시"
    type: select
    proxies:
      - "수동 선택"
      - "자동 속도 측정"
      - DIRECT

그룹 유형	선택 방식	적합한 상황
`select`	사용자가 구성원을 직접 선택	지역, 회선 또는 직접 연결을 명확히 지정해야 할 때
`url-test`	주기적으로 테스트 주소를 요청해 지연 시간이 낮은 구성원을 선택	노드가 많고 자동으로 최적의 노드를 선택하고 싶을 때
`fallback`	사용 가능한 구성원을 순서대로 사용하고 현재 구성원이 실패하면 전환	고정 우선순위와 장애 조치를 중시할 때
`load-balance`	지정한 정책에 따라 여러 연결을 여러 구성원에게 분배	연결을 분산해야 하고 업스트림 환경이 허용할 때

예시의 interval: 300은 300초마다 주기적인 테스트를 수행한다는 뜻이고, tolerance: 50은 지연 시간 차이가 작을 때 불필요한 잦은 전환을 막는 설정입니다. 속도 측정값은 테스트 URL에 요청을 보내는 데 걸린 시간만 보여 주며 다운로드 대역폭과는 다릅니다. 한 번의 측정에서 노드 A의 지연 시간이 86밀리초, 노드 B가 112밀리초였다면 해당 테스트 주소에는 A가 더 빠르게 응답했다는 뜻일 뿐입니다. 다른 지역의 서비스에 접속하면 결과가 반대일 수 있습니다.

정책 그룹의 순환 참조 확인하기

정책 그룹은 다른 정책 그룹을 참조할 수 있지만 순환 구조를 만들 수는 없습니다. 예를 들어 “기본 프록시”에 “수동 선택”이 포함되고, “수동 선택”이 다시 “기본 프록시”를 포함하면 커널은 최종 아웃바운드를 결정할 수 없습니다. 복잡한 설정은 규칙 대상에서 시작해 아래로 추적하세요. 규칙이 어느 그룹을 가리키는지, 해당 그룹에 어떤 구성원이 있는지, 구성원이 최종적으로 노드나 DIRECT, REJECT로 연결되는지 확인하면 됩니다.

rules: 순서대로 각 연결의 경로 결정하기

rules는 순서가 있는 매칭 목록입니다. 연결은 첫 번째 규칙부터 확인하며, 매칭되는 즉시 해당 규칙이 지정한 정책을 사용하고 아래 규칙은 더 이상 확인하지 않습니다. 정확한 규칙은 범위가 넓은 규칙보다 앞에 배치하고, 일반적으로 앞에서 매칭되지 않은 트래픽은 마지막에 MATCH로 처리합니다.

rules:
  - DOMAIN,api.example.com,기본 프록시
  - DOMAIN-SUFFIX,example.net,기본 프록시
  - DOMAIN-KEYWORD,video,수동 선택
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,기본 프록시

DOMAIN은 전체 도메인 이름과 일치하고, DOMAIN-SUFFIX는 지정된 도메인과 하위 도메인에 일치합니다. DOMAIN-KEYWORD는 도메인에 해당 키워드가 포함되기만 해도 매칭될 수 있어 범위가 넓고 오탐 가능성도 큽니다. IP-CIDR은 주소 대역으로 판단하며, GEOIP는 커널이 로드한 지리 데이터베이스에 의존합니다. MATCH는 최종 대체 규칙입니다.

no-resolve는 IP 유형 규칙에서 주로 사용하며, 매칭을 위해 IP를 얻으려고 도메인을 추가로 해석하지 말라는 뜻입니다. 모든 규칙에 반드시 붙여야 하는 고정 접미사는 아닙니다. 도메인 규칙은 원래 도메인을 기준으로 판단하고, 주소 결과가 필요한 일부 상황에서는 정상적인 해석이 계속 필요합니다.

규칙이 맞아 보이는데도 매칭되지 않는 이유

앞에 더 넓은 규칙이 있음: 예를 들어 DOMAIN-SUFFIX,example.com,DIRECT를 먼저 작성하면 뒤의 DOMAIN,api.example.com,기본 프록시는 실행될 기회가 없습니다.
앱이 IP에 직접 접속함: 로그에 대상 주소만 표시되고 도메인 정보가 없다면 도메인 규칙은 매칭에 참여할 수 없습니다. IP 규칙을 사용하거나 DNS 가로채기 방식을 조정하세요.
정책 이름의 철자가 다름: 규칙 대상은 proxy-groups에 정의된 이름과 완전히 일치해야 합니다.
설정을 다시 불러오지 않음: 로컬 파일을 편집했지만 클라이언트가 여전히 이전 설정으로 실행 중일 수 있습니다. 저장한 뒤 「설정」→「다시 불러오기」를 실행하고 로그를 확인하세요.
연결이 다시 수립되지 않음: 기존 TCP 또는 QUIC 세션은 이전 경로를 계속 사용할 수 있습니다. 앱 연결을 닫고 몇 초 기다린 뒤 다시 테스트하면 결과를 더 명확히 확인할 수 있습니다.

provider 섹션: 노드와 규칙을 외부 파일로 분리하기

노드가 구독에서 제공되거나 규칙 모음이 많을 때는 provider를 사용할 수 있습니다. proxy-providers는 외부 노드 모음을 관리하고, rule-providers는 규칙 모음을 관리합니다. provider가 트래픽 경로를 자동으로 결정하는 것은 아닙니다. 노드 provider는 여전히 정책 그룹에서 참조해야 하며, 규칙 provider는 RULE-SET을 통해 rules에 추가해야 합니다.

proxy-providers:
  airport:
    type: http
    url: "https://subscription.example.com/clash.yaml"
    path: ./providers/airport.yaml
    interval: 3600
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 600

rule-providers:
  private-sites:
    type: http
    behavior: domain
    format: yaml
    path: ./rules/private-sites.yaml
    url: "https://rules.example.com/private-sites.yaml"
    interval: 86400

노드 provider는 정책 그룹의 use로 불러올 수 있고, 규칙 provider는 RULE-SET,private-sites,DIRECT처럼 작성해야 합니다. behavior는 규칙 파일의 내용과 맞아야 합니다. domain은 도메인 규칙용, ipcidr은 주소 대역용, classical은 고전적인 규칙 표현식용입니다. 형식 선언과 파일 내용이 다르면 provider 다운로드는 성공해도 파싱에 실패하는 경우가 많습니다.

proxy-groups:
  - name: "구독 자동 선택"
    type: url-test
    use:
      - airport
    url: "https://www.gstatic.com/generate_204"
    interval: 300

rules:
  - RULE-SET,private-sites,DIRECT
  - MATCH,구독 자동 선택

interval: 3600은 노드 provider가 3600초마다 업데이트를 시도한다는 뜻이며, 규칙 예시의 86400은 24시간입니다. 업데이트 주기는 출처의 변경 빈도에 맞춰 설정해야 합니다. 너무 짧으면 불필요한 네트워크 요청이 발생하고, 너무 길면 변경된 노드나 규칙이 한동안 적용되지 않을 수 있습니다.

읽기 쉬운 최소 설정을 하나로 연결하기

앞에서 살펴본 구조를 합치면 학습에 적합한 최소 설정을 만들 수 있습니다. 노드 프로토콜, DNS 업스트림과 트래픽 분기 대상은 실제 환경에 맞게 입력해야 하므로 범용 완성본은 아니지만, 필드 간 참조 관계를 명확히 보여 줍니다.

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

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"

proxies:
  - name: "도쿄-SS"
    type: ss
    server: ss-node.example.com
    port: 443
    cipher: aes-128-gcm
    password: "demo-password"
    udp: true

proxy-groups:
  - name: "프록시"
    type: select
    proxies:
      - "도쿄-SS"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.net,프록시
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,프록시

api.example.net에 연결할 때 커널은 먼저 DNS 섹션을 통해 도메인을 해석한 다음 DOMAIN-SUFFIX,example.net,프록시에 매칭되어 “프록시” 그룹으로 보냅니다. 그룹에서 현재 “도쿄-SS”가 선택되어 있다면 연결은 해당 노드로 전달됩니다. 사용자가 프록시 페이지에서 그룹을 DIRECT로 전환해도 같은 규칙이 계속 매칭되지만, 최종 경로는 직접 연결로 바뀝니다. 이것이 “규칙”과 “정책 선택”을 나누어 이해해야 하는 이유입니다.

저장 후 확인 순서

먼저 YAML 들여쓰기, 목록 기호와 콜론 뒤 공백을 확인합니다.
각 규칙 대상이 정책 그룹에 존재하고, 각 정책 그룹 구성원이 노드 또는 내장 정책으로 연결되는지 확인합니다.
설정을 다시 불러온 뒤 시작 로그에 필드 오류, 참조 실패 또는 포트 사용 중 오류가 나타나는지 확인합니다.
7890, 9090, 1053 등의 포트를 다른 프로그램이 사용하고 있지 않은지 확인합니다.
직접 연결 대상과 프록시 대상 하나씩 테스트하고, 로그에서 실제로 매칭된 규칙을 확인합니다.
마지막으로 시스템 프록시 또는 TUN을 활성화하세요. 여러 변수를 동시에 바꾸면 문제를 추적하기 어려워집니다.

커널이 시작하자마자 종료된다면 설정을 대량으로 삭제하기보다 섹션별로 범위를 좁히는 것이 가장 효과적입니다. 먼저 공통 필드와 사용 가능한 노드 하나만 남기고, 다음으로 정책 그룹, DNS, 마지막으로 규칙과 provider를 차례로 추가하세요. 각 섹션을 추가할 때마다 다시 불러오면 오류가 어느 필드에서 발생했는지 좁힐 수 있습니다. 200줄 설정을 예로 들면 다섯 단계로 복원하는 데 보통 5~8번만 로드하면 되므로, 한 줄씩 추측하는 것보다 빠릅니다.

자주 하는 실수와 유지 관리 팁

구독 링크를 노드 주소로 직접 입력하기

구독 URL은 노드 모음이나 전체 설정을 반환하며, 특정 노드의 server 값이 아닙니다. 전체 구독은 클라이언트의 구독 관리 기능이나 proxy-providers에 맡기고, 개별 노드 정보는 프로토콜 필드에 맞춰 proxies에 작성해야 합니다. 두 데이터는 계층이 다르므로 서로 바꿔 사용할 수 없습니다.

속도 측정 수치만 보고 정책 매칭을 확인하지 않기

노드 속도 측정이 성공했다는 것은 커널이 해당 노드를 통해 테스트 주소에 접속할 수 있다는 뜻입니다. 실제 서비스 연결은 규칙에 따라 DIRECT, 다른 정책 그룹 또는 다른 노드로 전달될 수 있습니다. 문제를 추적할 때는 먼저 로그에서 규칙 대상을 확인하고, 다음으로 정책 그룹의 현재 선택을 확인한 뒤 노드 연결 결과를 점검하세요.

모든 문제를 DNS 탓으로 돌리기

DNS는 해석 경로의 일부만 담당합니다. 포트 사용 중, 시스템 프록시 미활성화, TUN 라우팅 미적용, 규칙 순서 오류, 비어 있는 정책 그룹, 노드 프로토콜 매개변수 불일치도 “웹페이지가 열리지 않는” 원인이 될 수 있습니다. DNS 주소를 계속 바꾸기보다 계층별로 점검하는 방식이 더 신뢰할 수 있습니다.

자동 업데이트 설정을 장기간 직접 편집하기

구독을 새로 고치면 직접 추가한 규칙, 정책 그룹 또는 DNS 필드가 새로 생성된 내용으로 교체될 수 있습니다. 장기 유지 시에는 계층을 명확히 나누세요. 구독은 노드 업데이트를 담당하고, 로컬 오버라이드는 고정 매개변수를 담당하며, 규칙 provider는 대규모 규칙 모음을 담당합니다. 소량의 개인 규칙은 순서를 제어할 수 있는 앞부분 규칙 영역에 두면 됩니다. 이렇게 하면 노드를 업데이트할 때 YAML 전체를 다시 병합할 필요가 없습니다.