Clash YAML
설정 파일 참고

CHAPTER / 01

YAML 구조 전체 보기와 해석 순서

최상위 구조부터 확인한 뒤 참조 관계를 점검하세요

로드할 수 있는 Clash 설정이라고 해서 올바르게 트래픽을 분기하는 설정인 것은 아닙니다. YAML 파서는 먼저 들여쓰기, 목록과 키-값 유형을 처리하고, 코어는 최상위 필드를 읽은 다음 노드, 정책 그룹, 규칙 프로바이더와 규칙 사이의 참조를 해석합니다. 검토할 때는 이 순서대로 확인해야 합니다. 먼저 파일이 유효한 YAML인지 확인하고, 각 참조 이름이 실제로 존재하는지 확인한 뒤, 마지막으로 실행 중 동작을 살펴보세요. 특정 규칙부터 바로 조사하면 상위 단계의 이름 오류나 들여쓰기 오류를 놓치기 쉽습니다.

일반적인 최상위 영역에는 수신 포트, 작동 모드, 로그 수준, 제어 인터페이스, DNS, 프록시 노드, 노드 프로바이더, 정책 그룹, 규칙 프로바이더와 규칙이 포함됩니다. 필드 순서는 보통 의미를 바꾸지 않지만, 용도별로 일관되게 배치하면 유지보수 비용을 크게 줄일 수 있습니다. 기본 수신 필드는 위쪽에, 용량이 큰 노드와 프로바이더는 중간에, 정책 그룹은 노드 뒤에, 규칙은 마지막에 두는 방식을 권장합니다. 이렇게 배치하면 읽을 때 ‘재료—편집—인쇄’의 자연스러운 순서가 만들어집니다.

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

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

proxies:
  - name: "예시 노드"
    type: ss
    server: example.net
    port: 443
    cipher: aes-128-gcm
    password: "your-password"

proxy-groups:
  - name: "노드 선택"
    type: select
    proxies:
      - "예시 노드"
      - DIRECT

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

위 설정은 완전한 참조 연결을 보여줍니다. 규칙은 “노드 선택”으로 요청을 전달하고, 정책 그룹은 다시 “예시 노드”를 참조하며, 노드 영역은 실제 연결 매개변수를 제공합니다. 이름에 공백, 전각 기호 또는 대소문자 차이가 하나라도 있으면 참조가 끊깁니다. 한국어 이름을 사용할 수는 있지만, 장기적으로 관리할 때는 표기를 완전히 동일하게 유지해야 합니다. 이름에 콜론, 샵, 쉼표 또는 앞뒤 공백이 포함된다면 파서가 해당 문자를 YAML 문법으로 해석하지 않도록 따옴표를 사용하는 편이 좋습니다.

들여쓰기, 목록 및 데이터 유형

YAML은 공백으로 계층을 표현하며 탭을 들여쓰기로 사용할 수 없습니다. 두 칸 공백으로 통일하고 같은 계층의 필드를 정확히 맞추는 방식을 권장합니다. 하이픈으로 시작하는 항목은 목록 요소입니다. 하이픈 뒤의 노드 객체에는 여러 키를 계속 포함할 수 있습니다. 가장 흔한 문제는 정책 그룹의 proxies 목록을 잘못된 계층에 들여쓰는 것입니다. 이 경우 코어가 이를 알 수 없는 필드로 보거나 정책 그룹에 선택 가능한 항목이 없다고 판단할 수 있습니다.

불리언 값은 true 또는 false로 작성하고, 포트는 보통 따옴표 없는 정수로 작성하며, 이름과 주소는 문자열로 처리합니다. 일부 파서는 yes, on 같은 오래된 불리언 표기도 허용하지만, 클라이언트 간에 설정을 옮길 때 차이가 생기기 쉽습니다. 안정적인 설정에는 명확한 표준 표기를 사용하세요. 숫자로 된 비밀번호, 0으로 시작하는 식별자와 특수 문자가 포함된 텍스트는 자동 유형 추론을 막기 위해 따옴표로 감싸야 합니다.

최소 설정으로 오류 위치 찾기

수천 줄의 구독 파일을 다룰 때 가장 효과적인 문제 해결 방법은 원본을 계속 수정하는 것이 아니라, 포트 하나, 노드 하나, 선택 그룹 하나와 규칙 두 개만 남긴 최소 설정을 별도로 저장하는 것입니다. 최소 설정이 로드된다면 기본 필드와 클라이언트 환경은 정상입니다. 이후 DNS, 프로바이더와 사용자 규칙을 구간별로 추가하면 어느 부분에서 오류가 생겼는지 확인할 수 있습니다. 한 번에 하나의 논리 영역만 추가하고 다시 로드한 직후 로그를 확인해야 여러 변경 사항이 동시에 들어가 원인을 판단하지 못하는 일을 피할 수 있습니다.

CHAPTER / 02

포트, 모드 및 제어 인터페이스 등 공통 필드

수신 포트의 역할과 범위

port는 HTTP 프록시 수신에 사용되고, socks-port는 SOCKS5 프록시 수신에 사용되며, mixed-port는 하나의 포트에서 두 유형의 요청을 모두 받습니다. 그래픽 클라이언트는 시스템 프록시와 SOCKS5를 지원하는 애플리케이션이 하나의 진입점을 공유할 수 있어 보통 mixed-port를 우선 사용합니다. 세 포트를 모두 동시에 켤 필요는 없습니다. 동시에 설정한다면 포트가 서로 겹치지 않고 브라우저 개발자 도구, 로컬 개발 서버 또는 다른 프록시 프로그램이 사용하고 있지 않은지 확인하세요.

시스템 프록시 설정은 운영체제의 HTTP 또는 SOCKS 요청을 수신 포트로 보내는 역할만 하며, 설정에 적힌 숫자를 자동으로 수정하지는 않습니다. mixed-port를 변경했다면 클라이언트의 시스템 프록시 스위치가 새 포트를 읽고 있는지도 확인해야 합니다. 브라우저에 연결 거부가 표시되지만 코어 로그에 요청 기록이 전혀 없다면 규칙을 수정하기보다 먼저 시스템 프록시 주소와 실제 수신 포트를 확인하세요.

port: 7891
socks-port: 7892
mixed-port: 7890
redir-port: 7893
tproxy-port: 7894

allow-lan: false
bind-address: "*"
mode: rule
log-level: info
ipv6: false

redir-port와 tproxy-port는 주로 Linux 게이트웨이, 라우터 또는 투명 프록시 환경을 대상으로 합니다. 운영체제의 전달 규칙과 함께 사용해야 하며, YAML에만 작성한다고 트래픽이 자동으로 코어에 들어가지는 않습니다. 데스크톱 사용자는 보통 이 두 포트를 직접 켤 필요가 없습니다. 더 많은 애플리케이션 트래픽을 가로채야 한다면 지원되는 클라이언트에서 TUN 모드를 설정하는 편이 적합합니다. Linux 클라이언트와 코어 진입점은 다운로드 페이지의 Linux 섹션에서 확인할 수 있습니다.

LAN 접근 및 바인딩 주소

allow-lan은 로컬 장치 외부에서 들어오는 연결을 허용할지 결정합니다. false이면 현재 장치에서 주로 사용하고, true로 설정하면 bind-address, 운영체제 방화벽과 LAN 주소를 함께 확인해 실제 접근 범위를 판단해야 합니다. LAN 수신을 켜기 전에 가정 또는 사무실 네트워크의 경계를 확인하고, 제어 인터페이스가 신뢰할 수 없는 네트워크에 노출되지 않도록 하세요.

bind-address는 수신 주소를 지정합니다. 별표는 코어 규칙에 따라 사용 가능한 인터페이스에서 수신한다는 의미이며, 구체적인 동작은 플랫폼과 클라이언트 구현의 영향도 받습니다. 로컬에서만 사용할 경우 클라이언트 기본 설정을 유지해도 됩니다. 휴대폰이 컴퓨터의 프록시를 사용해야 한다면 두 장치를 같은 LAN에 연결하고, 휴대폰의 프록시 설정에 컴퓨터의 LAN 주소와 mixed-port를 입력한 뒤 해당 방화벽 인바운드 규칙을 허용하세요.

rule, global 및 direct 모드

mode: rule은 rules를 위에서 아래로 매칭하는 방식으로, 일상적인 사용에서 가장 흔한 모드입니다. global은 트래픽을 전역 정책 그룹으로 보내며, 특정 노드가 연결되는지 임시로 확인할 때 유용하지만 기존 분기 판단을 우회합니다. direct는 트래픽을 직접 연결하므로 문제가 프록시 경로에서 발생했는지 확인할 때 적합합니다. 문제 해결 중에는 비교를 위해 잠시 모드를 바꿀 수 있지만, 결론을 얻은 뒤에는 rule 모드로 되돌려야 합니다.

모드 전환은 트래픽 결정의 진입점만 바꿀 뿐 노드 매개변수나 DNS 응답을 수정하지 않습니다. global 모드에서도 연결되지 않는다면 노드, 네트워크와 시간 설정을 계속 확인해야 합니다. global은 작동하지만 rule이 작동하지 않는다면 규칙 순서, 대상 정책 그룹 또는 규칙 프로바이더에 문제가 있을 가능성이 큽니다. 모드를 진단 스위치로 활용하면 노드 필드를 계속 고쳐 쓰는 것보다 명확한 결론을 얻기 쉽습니다.

로그 및 외부 컨트롤러

log-level의 일반적인 값에는 silent, error, warning, info와 debug가 있습니다. 일상적인 사용에서는 info를 유지하면 규칙 적용 결과를 확인하기 좋습니다. 복잡한 문제를 찾을 때는 잠시 debug를 사용할 수 있지만, 작업이 끝나면 되돌려 많은 세부 정보가 핵심 오류를 묻지 않도록 하세요. 로그의 “매칭 규칙—선택 정책—실제 노드”는 하나의 완전한 검토 단서이므로 세 항목을 차례로 대조해야 합니다.

external-controller는 그래픽 인터페이스와 코어가 통신하는 데 사용되며, 예를 들어 로컬 루프백 주소의 특정 포트에서 수신하도록 설정할 수 있습니다. 클라이언트가 이 필드를 보통 자동 관리하므로 인터페이스의 연결 방식을 모른다면 함부로 바꾸지 않는 것이 좋습니다. 패널이 정책 그룹을 읽지 못하지만 프록시 자체는 작동한다면 프록시 노드를 먼저 삭제하기보다 제어 인터페이스 주소, 포트와 클라이언트 설정을 확인하세요.

CHAPTER / 03

DNS 필드, 향상 모드 및 해석 체인

DNS 영역은 단일 서버 주소만 다루지 않습니다

Clash의 DNS 설정은 여러 역할을 수행합니다. 어떤 해석기에 도메인을 조회할지, 애플리케이션이 보낸 DNS 요청을 가로챌지, 규칙 매칭을 위해 도메인 정보를 어떻게 보존할지, 프록시 연결 전에 노드 서버 도메인을 어떻게 해석할지를 결정합니다. nameserver 한 줄만 바꿔서는 모든 문제가 해결되지 않는 경우가 많습니다. 프록시 노드의 서버 주소, 직접 연결 도메인과 프록시 도메인은 서로 다른 해석 단계를 거칠 수 있기 때문입니다.

dns.enable은 내장 DNS 모듈의 활성화 여부를 제어합니다. listen은 수신 주소와 포트를 지정하며, 그래픽 클라이언트는 보통 TUN 또는 시스템 설정과 연동해 자동으로 관리합니다. ipv6은 DNS 모듈이 IPv6 결과를 반환할지 결정합니다. 최상위 ipv6과 관련은 있지만 역할은 다릅니다. 전자는 해석 결과에 영향을 주고, 후자는 코어 전체의 IPv6 사용 여부에 영향을 줍니다. 네트워크에 안정적인 IPv6 경로가 없다면 사용 가능성이 불확실한 AAAA 레코드 때문에 연결이 지연될 수 있습니다.

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:
    - 1.1.1.1
    - 8.8.8.8
  nameserver:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  proxy-server-nameserver:
    - 1.1.1.1
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
    - "time.*.com"

default-nameserver와 nameserver의 역할 구분

nameserver는 기본 해석기 목록으로, 일반 UDP 주소나 코어가 지원하는 암호화 DNS 주소를 입력할 수 있습니다. 도메인 형식의 암호화 DNS를 사용하려면 코어가 먼저 해당 DNS 서비스 도메인의 IP를 알아야 하며, 이 초기 단계는 보통 default-nameserver가 지원합니다. 따라서 default-nameserver에는 직접 접근할 수 있는 IP 주소를 넣는 것이 적합합니다. 먼저 해석해야 하는 도메인을 다시 입력하면 순환 의존성이 생깁니다.

proxy-server-nameserver는 프록시 노드의 서버 도메인을 해석하는 데 사용됩니다. 노드 주소가 도메인으로 작성되어 있다면 코어는 프록시 연결을 수립하기 전에 IP를 얻어야 하며, 아직 만들어지지 않은 프록시 터널에 의존할 수 없습니다. 네트워크 환경마다 해석기의 접근성이 다르므로 “노드가 모두 시간 초과되지만 노드 서버를 IP로 입력하면 정상화되는” 현상이 나타난다면 이 필드와 로컬 네트워크의 DNS 접근성을 우선 확인하세요.

일부 mihomo 설정에서는 nameserver-policy도 사용하며, 도메인별로 조회를 지정된 해석기에 전달합니다. 같은 도메인에 대해 외부와 내부 네트워크가 서로 다른 결과를 반환하는 환경에 적합하지만, 정책 자체도 명확하게 유지해야 합니다. 중복된 도메인 정책을 대량으로 작성하면 DNS 계층과 규칙 계층이 동시에 분기를 담당해 문제 해결 시 결과의 출처를 판단하기 어려워집니다. 보통 DNS 해석을 먼저 안정화한 다음 규칙으로 트래픽 방향을 제어하세요.

fake-ip와 redir-host

fake-ip는 애플리케이션에 예약 주소 풀의 매핑 주소를 반환하고, 코어는 이를 통해 도메인 연결 관계를 보존합니다. 덕분에 도메인 규칙과 스니핑 후 트래픽 결정을 수행하기 쉬워집니다. 이 주소가 대상 웹사이트의 실제 주소라는 뜻은 아닙니다. 애플리케이션이 가짜 주소에 연결하면 코어가 매핑을 조회해 실제 연결을 수립합니다. 이 모드는 일반적으로 최신 데스크톱과 모바일 클라이언트에 적합하며, 먼저 해석한 뒤 매칭할 때 생기는 정보 손실도 줄일 수 있습니다.

redir-host는 전통적인 해석 흐름에 더 가깝습니다. 애플리케이션이 실제 해석 결과를 받은 뒤 연결을 시작합니다. 로컬 네트워크 장비, LAN 검색 또는 특수한 DNS 동작에 의존하는 일부 프로그램은 이 모드에서 호환성이 더 좋을 수 있지만, 코어가 얻는 도메인 맥락은 fake-ip보다 적을 수 있습니다. 두 모드 중 어느 하나가 모든 상황에서 절대적으로 우선하는 것은 아닙니다. 클라이언트 기본값, TUN 구현과 애플리케이션 호환성을 기준으로 선택하고, 서로 다른 설정 조각에서 두 모드를 자주 섞어 쓰지는 마세요.

fake-ip-filter는 가짜 주소를 반환하기에 적합하지 않은 도메인을 제외합니다. LAN 장치, 시간 동기화, 일부 로그인 및 연결성 검사 도메인은 실제 결과가 필요할 수 있습니다. 필터 규칙을 무제한으로 늘려서는 안 됩니다. 일반 도메인을 대량으로 추가하면 fake-ip의 도메인 매핑 장점이 약해집니다. 항목을 추가할 때마다 해당 오류 현상을 기록하고, 애플리케이션 업데이트나 네트워크 변경 후 다시 확인하세요.

CHAPTER / 04

프록시 노드 필드 및 연결 매개변수

모든 노드는 네 가지 기본 정보에서 시작합니다

proxies는 로컬 노드 목록입니다. 각 목록 항목에는 최소한 이름, 유형, 서버 주소와 포트가 필요하며, 이후 프로토콜에 따라 인증, 전송 및 TLS 필드를 추가합니다. 노드 이름은 설정 내부에서 참조되는 식별자이고, 정책 그룹은 이름으로 노드를 찾습니다. 서버 주소는 실제 연결 대상이며, 포트는 원격 서비스의 수신 포트로 로컬 mixed-port와는 전혀 다릅니다. 두 종류의 포트를 혼동하는 것은 설정을 직접 옮겨 적을 때 가장 흔한 오류 중 하나입니다.

노드 매개변수는 서버 설정과 한 세트로 일치해야 합니다. 프로토콜 유형, 암호화 방식, 인증 정보, 전송 계층, 호스트 이름과 경로 중 하나라도 다르면 시간 초과나 핸드셰이크 실패로 나타날 수 있습니다. 정책 그룹을 계속 바꾼다고 노드 자체의 매개변수 오류가 해결되지는 않습니다. 검토할 때는 프로토콜 기본 필드부터 시작해 TLS, WebSocket 또는 기타 전송 옵션을 단계적으로 추가하고, 매번 로그에서 실패 단계가 어떻게 바뀌는지 확인하세요.

proxies:
  - name: "SS 예시"
    type: ss
    server: example.net
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

  - name: "Trojan 예시"
    type: trojan
    server: edge.example.net
    port: 443
    password: "your-password"
    sni: service.example.net
    skip-cert-verify: false
    udp: true

예시에 사용된 주소와 인증 문자열은 구조를 보여주기 위한 것이며, 실제 사용 시에는 합법적인 서비스 설정에서 제공된 값을 사용해야 합니다. udp는 노드가 UDP 트래픽을 전달할 수 있는지 나타내지만, 프로토콜 구현, 서버와 네트워크 경로의 영향도 함께 받습니다. 필드가 true여도 서버에 해당 기능이 없으면 사용할 수 있는 UDP 전달이 이루어지지 않습니다. 게임, 음성 통화와 일부 DNS 트래픽에 문제가 생기면 노드 기능과 정책 그룹이 해당 노드를 선택했는지 각각 확인하세요.

TLS, SNI 및 인증서 검사

TLS를 사용하는 프로토콜은 올바른 서버 이름이 필요한 경우가 많습니다. sni는 핸드셰이크 때 대상 호스트 이름을 전송하는 필드로, 연결에 사용하는 server 필드와 반드시 같지는 않지만 서버 인증서와 배포 방식에 맞아야 합니다. 로그에 인증서 이름 불일치가 나타나면 인증서 검사를 먼저 끄기보다 서비스 제공자가 안내한 SNI를 확인하세요.

skip-cert-verify는 인증서 검사를 건너뛸지 제어합니다. 안정적인 설정에서는 false를 우선 유지하고 장치 시간, 인증서 체인, SNI 또는 네트워크 차단 문제를 해결해야 합니다. 장치 시간 차이로 아직 유효하지 않거나 이미 만료된 것으로 잘못 판단할 수 있으며, 시스템 루트 인증서 환경 이상도 연결에 영향을 줄 수 있습니다. 이 필드를 true로 바꾸는 것은 짧은 비교 테스트로만 사용하고 근본 원인 확인을 대신해서는 안 됩니다.

전송 계층 필드는 하나의 객체로 읽어야 합니다

WebSocket 같은 전송 방식에는 보통 경로와 요청 헤더가 포함됩니다. 경로의 슬래시, 대소문자와 인코딩은 서버와 일치해야 하며, Host 요청 헤더가 리버스 프록시 라우팅에 관여할 수도 있습니다. 들여쓰기 오류로 ws-opts 아래 필드가 노드 객체에서 분리되면 코어가 설정을 무시할 수 있습니다. “TCP는 연결됐지만 곧 끊기는” 현상이 나타나면 TLS 핸드셰이크, HTTP 업그레이드와 애플리케이션 프로토콜의 세 단계를 따라 로그를 확인하세요.

  - name: "WS 예시"
    type: vmess
    server: edge.example.net
    port: 443
    uuid: "00000000-0000-4000-8000-000000000000"
    alterId: 0
    cipher: auto
    tls: true
    servername: service.example.net
    network: ws
    ws-opts:
      path: /gateway
      headers:
        Host: service.example.net

코어와 프로토콜에 따라 sni, servername 등 서로 다른 필드 이름을 사용하므로 의미가 비슷하다는 이유만으로 바꿔 쓸 수 없습니다. mihomo 코어로 이전하기 전에 현재 클라이언트의 지원 범위를 대조해 필드를 확인하세요. 코어 간 관계와 호환성 경계는 mihomo 코어와 원본 Clash의 차이에서 계속 확인할 수 있습니다.

노드 이름, 중복 항목 및 상태 점검

노드 이름은 고유해야 합니다. 두 노드가 같은 이름을 사용하면 정책 그룹의 참조가 예상하지 못한 객체를 가리킬 수 있고, 클라이언트 화면에서도 구분하기 어렵습니다. 구독 프로바이더의 중복 이름은 업데이트 후 다시 나타날 수 있으므로 오버라이드 단계에서 접두사, 접미사 또는 필터 규칙을 추가하는 방법이 적합합니다. 이름에는 지역, 회선 또는 용도를 표시하고, 실시간 지연 시간을 넣는 것은 권장하지 않습니다. 업데이트 후 값이 쉽게 달라지기 때문입니다.

노드가 목록에 표시된다는 것은 YAML을 읽었다는 뜻일 뿐, 연결 가능하다는 의미는 아닙니다. 클라이언트가 제공하는 연결성 테스트를 사용한 뒤 실제 웹페이지나 대상 애플리케이션으로 확인하세요. 테스트 주소, DNS, 노드 프로토콜과 대상 웹사이트는 서로 다른 경로를 사용할 수 있으므로 하나의 테스트 결과만으로 모든 상황을 판단할 수 없습니다. 모든 노드가 동시에 실패하면 로컬 네트워크, DNS와 시스템 시간을 먼저 점검하고, 단일 노드만 실패할 때 해당 노드 필드를 집중적으로 확인하세요.

CHAPTER / 05

정책 그룹 유형, 참조 및 선택 로직

정책 그룹은 노드와 규칙 사이의 편집 작업대입니다

proxy-groups는 새로운 프로토콜 연결을 만드는 것이 아니라, 기존 노드나 다른 정책 그룹을 선택, 테스트 또는 장애 조치에 사용할 수 있는 논리 단위로 구성합니다. 규칙의 마지막 열은 보통 정책 그룹을 가리키고, 정책 그룹이 사용할 노드를 결정합니다. 정책 그룹 이름에 “노드 선택”, “스트리밍”, “직접 연결 서비스”처럼 용도를 적는 편이 프로토콜 이름을 나열하는 것보다 읽기 쉽습니다.

정책 그룹은 노드를 참조할 수도 있고, 앞에서 정의한 다른 정책 그룹을 참조할 수도 있습니다. 여러 계층의 참조는 지역 선택과 업무별 분기를 분리할 때 유용하지만, 계층이 너무 깊으면 원인을 찾기 어려워집니다. 두세 단계로 유지하는 것이 좋습니다. 하위에는 실제 노드나 프로바이더, 중간에는 지역 또는 테스트 그룹, 상위에는 업무 정책을 둡니다. 오류가 발생하면 규칙의 대상부터 최종 노드까지 계층별로 펼쳐 보세요.

proxy-groups:
  - name: "자동 선택"
    type: url-test
    proxies:
      - "노드 A"
      - "노드 B"
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 80

  - name: "노드 선택"
    type: select
    proxies:
      - "자동 선택"
      - "노드 A"
      - "노드 B"
      - DIRECT

  - name: "장애 조치"
    type: fallback
    proxies:
      - "노드 A"
      - "노드 B"
    url: "https://www.gstatic.com/generate_204"
    interval: 300

select, url-test 및 fallback의 차이

select는 사용자가 구성원 하나를 직접 선택합니다. 결과가 안정적이고 설명하기 쉬워 최상위 진입점으로 적합합니다. 클라이언트가 선택 상태를 저장한다면 설정을 다시 불러온 뒤에도 이전 선택을 복원하는 경우가 많지만, 이름이 바뀌거나 그룹이 재생성되면 기본 항목으로 돌아갈 수 있습니다. 처음 설정을 불러올 때 예상치 못한 경로가 선택되는 일을 줄이려면 가장 우선할 구성원을 목록 앞에 배치하세요.

url-test는 일정한 간격으로 테스트 주소에 접속하고 측정 결과에 따라 구성원을 자동 선택합니다. 이는 노드에서 테스트 대상까지의 연결성과 응답을 보여주는 값이지, 모든 웹사이트의 실제 속도와 같지는 않습니다. interval은 테스트 간격을 제어하며, 너무 짧게 설정하면 백그라운드 요청이 늘어납니다. tolerance는 결과가 비슷할 때 잦은 전환을 줄이는 데 사용됩니다. 자동 그룹은 일상적인 선택에 적합하지만, 중요한 업무에서는 실제 접속 상태도 확인해야 합니다.

fallback은 사용 가능한 구성원을 순서대로 사용하고 현재 구성원이 작동하지 않으면 다음 구성원으로 전환합니다. 최소 응답 시간보다 안정성을 중시하는 방식입니다. 따라서 목록 순서가 실제 의미를 가지며 우선 회선을 앞에 둬야 합니다. 현재 네트워크에서 테스트 주소에 접근할 수 없다면 모든 노드가 사용 불가로 잘못 판단될 수 있으므로, 테스트 대상은 안정적이고 응답 내용이 짧으며 노드가 접근할 수 있는 네트워크 범위와 맞아야 합니다.

load-balance와 트래픽 연속성

load-balance는 여러 구성원 사이에 연결을 분배하며, 구체적인 방식은 코어 지원 범위와 그룹 매개변수에 따라 달라집니다. 하나의 다운로드 작업을 여러 노드에 단순히 합산하는 기능이 아니며, 모든 요청이 무작위로 전환된다는 보장도 없습니다. 로그인 상태나 발신 주소에 민감한 서비스는 노드 간 분배에 적합하지 않을 수 있습니다. 같은 세션에서 출구가 바뀌면 재인증이나 연결 끊김이 발생할 수 있기 때문입니다.

로드 밸런싱을 선택하기 전에 업무가 출구 변경을 허용하는지 확인해야 합니다. 웹 브라우징과 다중 연결 다운로드에는 도움이 될 수 있지만, 원격 관리, 결제 로그인과 장시간 연결에는 경로 안정성이 더 중요합니다. 정책 그룹은 기능 수를 늘리는 것보다 업무 제약을 기준으로 설계해야 합니다. 명확한 요구가 없다면 select와 하나의 url-test 그룹만으로도 충분히 이해하기 쉽습니다.

use로 프로바이더 노드 가져오기

노드가 proxy-providers에서 제공되는 경우 정책 그룹에서 use로 프로바이더 전체를 참조할 수 있으므로 proxies에 각 노드 이름을 일일이 작성할 필요가 없습니다. 구독 업데이트로 추가되거나 삭제된 노드도 프로바이더를 통해 그룹에 반영되므로 장기적인 관리에 적합합니다. 코어가 지원한다면 proxies와 use를 함께 사용할 수 있지만, 최종 구성원에 중복 노드가 포함되지 않는지 확인해야 합니다.

proxy-groups:
  - name: "구독 노드"
    type: select
    use:
      - provider-main
    proxies:
      - DIRECT

  - name: "자동 속도 측정"
    type: url-test
    use:
      - provider-main
    url: "https://www.gstatic.com/generate_204"
    interval: 600
    tolerance: 100

정책 그룹이 비어 있으면 이를 참조하는 규칙은 유효한 노드를 얻을 수 없습니다. 흔한 원인은 프로바이더 다운로드 실패, 필터 표현식이 모든 노드를 제외한 경우, 프로바이더 이름 오타 또는 그룹이 아직 존재하지 않는 로컬 노드를 참조한 경우입니다. 클라이언트 화면에 빈 그룹이 표시되면 즉시 규칙을 수정하기보다 먼저 프로바이더 상태와 원본 노드 수를 확인한 뒤 필터 조건을 점검하세요.

CHAPTER / 06

규칙 문법, 순서 및 매칭 범위

규칙은 위에서 아래로 처리되며 처음 매칭된 항목만 사용합니다

rules는 순서가 있는 목록입니다. 요청이 규칙 모드로 들어오면 코어는 첫 번째 규칙부터 확인하고, 매칭되는 즉시 지정된 정책으로 트래픽을 전달한 뒤 더 구체적인 규칙을 찾지 않습니다. 따라서 정확한 범위는 넓은 범위보다 앞에 두고, 예외 항목은 이를 덮어쓸 일반 항목보다 앞에 두며, 최종 규칙은 반드시 마지막에 배치해야 합니다. 규칙 내용이 같아도 순서가 다르면 최종 동작은 완전히 달라질 수 있습니다.

각 규칙은 보통 규칙 유형, 매칭 내용과 대상 정책으로 구성되며 영문 쉼표로 구분합니다. 대상은 정책 그룹일 수도 있고 DIRECT, REJECT 같은 내장 동작일 수도 있습니다. 한국어 쉼표는 비슷해 보여도 필드 구분자로 인식되지 않습니다. 규칙을 복사한 뒤에는 구두점, 앞뒤 공백과 대상 이름을 확인하세요. 특히 편집 문서에서 복사할 때 전각 문자가 섞이지 않았는지 주의해야 합니다.

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,노드 선택
  - DOMAIN-KEYWORD,example,노드 선택
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - PROCESS-NAME,example.exe,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,노드 선택

도메인 규칙의 정밀도 차이

DOMAIN은 완전한 도메인만 매칭하므로 단일 호스트의 예외 처리에 적합합니다. DOMAIN-SUFFIX는 지정한 도메인과 하위 도메인을 매칭하므로 전체 사이트 체계를 대상으로 하기 좋습니다. DOMAIN-KEYWORD는 도메인에 지정한 텍스트가 포함되기만 해도 매칭될 수 있어 범위가 넓고, 이름이 비슷하지만 무관한 도메인까지 잘못 포함할 가능성이 큽니다. 설정에서는 정확한 도메인과 접미사를 우선 사용하고, 대상 도메인이 자주 바뀌면서 규칙이 명확할 때만 키워드를 사용하세요.

예를 들어 DOMAIN,internal.example.com,DIRECT를 먼저 작성하고 DOMAIN-SUFFIX,example.com,노드 선택을 뒤에 작성해야 내부 호스트를 직접 연결할 수 있습니다. 접미사 규칙이 앞에 있으면 정확한 규칙은 실행될 기회를 얻지 못합니다. 도메인이 잘못 분기되는 문제를 찾을 때는 로그에서 실제 요청 도메인을 확인한 뒤, 규칙 위에서부터 처음 매칭될 가능성이 있는 항목을 찾으세요. 예상한 규칙이 존재하는지만 확인해서는 안 됩니다.

IP-CIDR 및 no-resolve

IP-CIDR은 네트워크 대역으로 대상 IPv4 주소를 매칭하며, IPv6에는 해당 IPv6 규칙 유형을 사용합니다. CIDR 접미사는 네트워크 프리픽스 길이를 나타내므로 범위를 너무 넓게 잡으면 많은 주소를 포함하게 됩니다. LAN 대역은 보통 프록시 규칙보다 앞에서 직접 연결해야 라우터, 프린터 또는 저장 장치 접근이 원격 노드로 전달되는 일을 막을 수 있습니다.

no-resolve는 해당 IP 규칙을 매칭할 때 도메인만 있는 요청에 대해 추가 해석을 실행하지 않는다는 뜻입니다. 이미 존재하는 대상 IP만 확인하면 되는 규칙에 적합하며 불필요한 DNS 조회를 줄일 수 있습니다. 이 매개변수를 추가할지는 규칙 목적에 따라 결정해야 합니다. 도메인을 해석해야 대상 IP를 얻는 규칙에는 기계적으로 추가해서는 안 됩니다. 매개변수를 그대로 따라 쓰는 것보다 해석 시점을 이해하는 것이 중요합니다.

프로세스 규칙 및 플랫폼 차이

PROCESS-NAME, PROCESS-PATH 같은 프로세스 규칙은 운영체제 권한, 코어 기능과 클라이언트의 트래픽 인계 방식에 의존합니다. Windows, macOS, Linux와 Android는 프로세스 정보를 얻는 조건이 서로 다르므로 한 플랫폼에서 매칭된다고 다른 플랫폼에서도 같은 결과가 나온다는 보장은 없습니다. TUN 모드에서 프로세스를 식별할 수 있는지도 클라이언트 구현과 권한 설정의 영향을 받습니다.

프로세스 규칙이 작동하지 않으면 먼저 디버그 로그에서 코어가 인식한 프로세스 이름 또는 경로를 확인한 뒤 실제 값에 맞춰 규칙을 작성하세요. 실행 파일이 업데이트되면 경로가 바뀔 수 있고, 대소문자와 확장자도 플랫폼에 맞춰 확인해야 합니다. 여러 플랫폼에서 공유하는 설정에는 프로세스 경로보다 도메인 규칙을 일관되게 유지하기 쉽습니다. 프로세스 규칙은 모든 장치가 공유하는 구독 본문에 넣기보다 플랫폼 전용 오버라이드로 사용하는 편이 적합합니다.

GEOIP, 규칙 세트 및 최종 처리

GEOIP는 대상 IP가 속한 데이터베이스 지역을 기준으로 매칭하며, 결과는 데이터베이스의 내용과 업데이트 시점에 영향을 받습니다. 비교적 뒤쪽에 지역 단위 판단으로 배치하는 데 적합하지만, 명확한 도메인 규칙을 대신하기에는 적합하지 않습니다. 도메인 해석 결과는 네트워크와 CDN 라우팅에 따라 달라질 수 있고 하나의 서비스가 여러 지역에 분산되기도 하므로, 중요한 업무에는 더 명확한 규칙 세트나 도메인 규칙을 사용해야 합니다.

MATCH는 앞에서 매칭되지 않은 모든 요청을 처리하며 반드시 마지막에 배치해야 합니다. 중간에 있으면 아래 규칙은 모두 무효가 됩니다. 최종 처리를 직접 연결로 할지 프록시로 할지는 설정 목적에 따라 정해야 합니다. 목록에 있는 대상만 프록시로 처리하려면 분류되지 않은 트래픽을 직접 연결할 수 있고, 기본적으로 프록시를 사용하려면 전체 선택 그룹으로 보낼 수 있습니다. 어느 방식을 택하든 그룹 이름에 결과가 분명히 드러나야 합니다.

rules:
  # 로컬 및 명확한 예외
  - DOMAIN,printer.lan,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

  # 업무 규칙
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,proxy-domain,노드 선택
  - RULE-SET,private-ip,DIRECT

  # 지역 판단 및 최종 처리
  - GEOIP,CN,DIRECT
  - MATCH,노드 선택

사용자 규칙 전체 점검은 Clash 사용자 규칙 문법 상세 가이드와 함께 확인할 수 있습니다. 수정 후 설정이 성공적으로 로드되는지만 보지 말고, 정확한 도메인, 하위 도메인, IP와 최종 처리 상황을 대표하는 대상을 몇 개 선택해 로그의 매칭 규칙과 최종 정책을 하나씩 확인하세요.

CHAPTER / 07

노드 프로바이더, 규칙 프로바이더 및 구독 업데이트

proxy-providers로 업데이트 가능한 노드 소스 관리

proxy-providers는 원격 또는 로컬 노드 모음을 주 설정에서 분리합니다. 주 설정은 정책 구조를 담당하고 프로바이더는 노드 내용을 담당하므로 두 구성의 업데이트 주기를 다르게 운영할 수 있습니다. 이렇게 하면 구독을 업데이트할 때 전체 규칙을 다시 작성할 필요가 없고, 여러 정책 그룹에서 같은 노드 모음을 공유하기도 쉽습니다. 클라이언트가 프로바이더를 지원한다면 대량의 노드를 proxies에 직접 펼치는 것보다 이런 계층 구조가 유지보수에 적합합니다.

각 프로바이더에는 고유한 이름, 유형, 소스 주소, 캐시 경로와 업데이트 간격이 필요합니다. 원격 유형은 보통 HTTP로 YAML을 가져오며, path는 로컬 캐시 위치를 지정합니다. 클라이언트마다 상대 경로의 기준 디렉터리를 처리하는 방식이 다를 수 있습니다. 설정을 옮긴 뒤 파일을 만들 수 없거나 캐시가 갱신되지 않는다면 클라이언트 작업 디렉터리와 파일 권한을 확인하세요.

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

프로바이더의 상태 점검은 내부 노드에 주기적으로 테스트를 수행하지만, 정책 그룹의 url-test와는 다른 계층에서 작동합니다. 전자는 노드의 사용 가능 상태를 관리하고 후자는 그룹 안에서 선택을 수행합니다. 두 간격을 모두 너무 짧게 설정하면 중복 요청이 발생하므로 노드 변화 빈도와 실제 사용 목적에 맞춰 정해야 합니다. 구독 주소가 만료되어도 클라이언트가 로컬 캐시를 계속 사용할 수 있으므로 “현재 연결된다”는 사실만으로 원격 업데이트가 정상이라고 판단할 수 없습니다.

rule-providers로 규칙을 그룹 단위 관리

rule-providers는 많은 도메인 또는 네트워크 대역 규칙을 별도 파일에 저장하고, 주 설정에서는 RULE-SET으로 참조합니다. 일반적인 behavior에는 domain, ipcidr와 classical이 있습니다. domain 규칙 세트는 도메인 매칭에, ipcidr은 네트워크 대역에, classical은 규칙 유형이 포함된 전통적인 항목에 사용할 수 있습니다. 프로바이더 내용의 형식은 behavior와 일치해야 하며, 파일 다운로드가 성공해도 형식이 다르면 해석되지 않을 수 있습니다.

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

  private-ip:
    type: http
    behavior: ipcidr
    format: yaml
    path: ./rules/private-ip.yaml
    url: "https://example.com/rules/private-ip.yaml"
    interval: 86400

rules:
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,private-ip,DIRECT,no-resolve
  - MATCH,노드 선택

domain behavior 형식의 파일에는 보통 도메인 값만 넣고 대상 정책은 작성하지 않습니다. 정책은 주 설정의 RULE-SET 행에서 지정합니다. classical 형식에는 DOMAIN-SUFFIX 같은 완전한 규칙 접두사가 포함될 수 있습니다. 두 형식을 혼동하면 “규칙 세트는 다운로드됐지만 매칭되지 않는” 것처럼 보일 수 있습니다. 검토할 때는 프로바이더 상태, 해석된 항목 수와 주 규칙의 참조 이름을 함께 확인하세요.

구독 업데이트와 로컬 설정의 경계

Profile에는 보통 원격 구독과 로컬 설정이 함께 포함됩니다. 원격 구독은 노드 변경 사항을 받는 데 적합하고, 로컬 설정은 장치별 포트, DNS와 규칙을 저장하는 데 적합합니다. 구독에서 생성된 파일을 직접 편집하면 다음 업데이트 때 변경 사항이 사라질 수 있고, 모든 노드를 로컬 파일로 복사하면 자동 업데이트 기능을 잃게 됩니다. 더 안정적인 방법은 구독을 원본으로 유지하고 클라이언트 오버라이드나 독립적인 주 설정으로 정책을 구성하는 것입니다.

여러 설정을 관리할 때는 각 Profile에 “데스크톱 일상”, “모바일 네트워크”, “규칙 실험”처럼 용도를 표시하세요. 가져온 날짜만으로 이름을 정하면 구분하기 어렵습니다. 설정을 전환한 뒤에는 현재 활성 항목, 시스템 프록시 상태와 정책 선택을 확인해야 합니다. 클라이언트가 Profile별로 상태를 따로 저장할 수 있기 때문입니다. 가져오기, 전환과 정리 방법은 Clash Profile 설정 파일 기초에서 확인하세요.

업데이트 실패의 계층별 점검

프로바이더 업데이트가 실패하면 먼저 네트워크 오류, HTTP 상태 오류, 파일 형식 오류와 캐시 쓰기 오류를 구분해야 합니다. 네트워크 오류는 주소로 연결을 만들 수 없다는 뜻이고, HTTP 오류는 원격 서버가 예상하지 않은 상태를 반환했다는 뜻입니다. 형식 오류는 보통 다운로드가 끝난 뒤 해석하는 단계에서 발생하며, 캐시 오류는 경로와 권한에 관련됩니다. 로그에 나타난 단계 정보가 업데이트 버튼을 반복해서 누르는 것보다 훨씬 유용합니다.

원격 주소에 프록시를 통해 접근해야 한다면 코어가 프로바이더를 업데이트할 때 사용하는 네트워크 경로도 확인해야 합니다. 처음 시작할 때는 정책이 아직 완전히 준비되지 않았으므로 핵심 설정을 가져오는 데 프록시를 과도하게 의존하면 시작 순환이 생길 수 있습니다. 직접 초기화할 수 있는 기본 설정을 남겨 두고, 프로바이더가 실패해도 명확한 로그와 사용할 수 있는 로컬 캐시가 있도록 하세요.

CHAPTER / 08

오버라이드, 병합 및 최종 설정 검토

실제로 적용되는 것은 병합 후 결과입니다

많은 그래픽 클라이언트는 원격 구독 위에 오버라이드, 스크립트 또는 병합 설정을 적용할 수 있습니다. 사용자가 편집한 조각은 여러 입력 중 하나일 뿐이며, 코어가 최종적으로 읽는 것은 클라이언트가 처리한 결과물입니다. 문제를 해결할 때 원래 구독이나 오버라이드 파일만 보고 최종 설정을 확인하지 않으면 필드가 적용됐다고 잘못 판단할 수 있습니다. 클라이언트가 실행 설정을 내보낼 수 있다면 내보낸 결과를 우선 확인하고 예상한 내용과 항목별로 비교하세요.

병합에는 보통 교체, 추가와 삭제라는 세 가지 동작이 포함됩니다. mixed-port 같은 스칼라 필드는 뒤의 값이 앞의 값을 덮어쓰는 경우가 많습니다. dns 같은 매핑 객체는 키 단위로 병합될 수도 있고 전체가 교체될 수도 있습니다. rules와 proxy-groups 같은 목록은 클라이언트마다 동작 차이가 가장 큽니다. 어떤 클라이언트는 추가하고, 어떤 클라이언트는 이름으로 처리하며, 어떤 클라이언트는 통째로 덮어씁니다. 모든 클라이언트가 같은 알고리즘을 사용한다고 가정해서는 안 되며, 설정을 옮길 때는 먼저 작은 샘플로 테스트해야 합니다.

# base.yaml
mode: rule
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1

rules:
  - GEOIP,CN,DIRECT
  - MATCH,노드 선택

# override.yaml
dns:
  ipv6: false

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

클라이언트가 dns를 깊이 병합한다면 최종 결과에 enable, enhanced-mode, nameserver와 새로 추가한 ipv6이 함께 남을 수 있습니다. 전체 교체 방식이라면 최종 DNS 영역에 ipv6만 남아 설정이 예상대로 작동하지 않을 수 있습니다. 규칙 목록에서는 뒤에 추가된 정확한 예외가 기존 GEOIP 또는 MATCH에 먼저 가로채일 수 있으므로 앞에 삽입할지 전체 순서를 다시 정리할지 명확히 결정해야 합니다.

이름으로 정책 그룹을 병합할 때의 위험

일부 오버라이드 도구는 이름이 같은 정책 그룹을 하나의 객체로 보고 구성원을 병합합니다. 이를 이용하면 기존 “노드 선택” 그룹에 로컬 그룹을 추가할 수 있지만, 중복 구성원이 생기거나 필요 없는 기존 필드가 남을 수도 있습니다. 다른 도구는 새 객체로 기존 그룹을 완전히 교체합니다. 오버라이드 조각에 type, proxies 또는 use를 모두 작성하지 않으면 최종 그룹이 불완전해질 수 있습니다.

정책 그룹을 처리할 때는 오버라이드 조각의 목적을 명확히 적는 것이 좋습니다. 그룹을 완전히 교체할지, 구성원만 추가할지 구분해야 합니다. 클라이언트의 의미를 확신할 수 없다면 새 그룹 이름을 사용해 규칙이 올바르게 참조되는지 먼저 확인한 뒤 기존 그룹을 대체하세요. 이름이 바뀌면 클라이언트가 저장한 수동 선택에도 영향을 주므로 업데이트 후 선택이 갑자기 기본값으로 돌아갔다면 병합 과정에서 그룹 이름이 변경됐는지 확인해야 합니다.

규칙 오버라이드는 순서의 의도를 보존해야 합니다

로컬 규칙은 보통 장치별 직접 연결, 프로세스 규칙 또는 업무 예외를 추가하는 데 사용됩니다. 이러한 규칙은 구독의 넓은 규칙보다 앞에 있어야 하므로 단순히 뒤에 추가하면 효과가 없습니다. 안정적인 방식은 규칙을 “로컬 예외, 원격 규칙 세트, 지역 판단, 최종 처리”의 네 구간으로 나누고 최종 설정에서 순서를 고정하는 것입니다. 클라이언트에 규칙 앞 삽입과 뒤 삽입 기능이 있다면 예외는 앞에, 추가 최종 처리는 뒤에 배치하되, 전체 설정에는 실제 최종 MATCH를 하나만 남겨야 합니다.

규칙 중복 제거는 전체 행 텍스트만 비교해서는 안 됩니다. 두 규칙이 겹치는 범위를 매칭하더라도 대상이 다를 수 있습니다. 예를 들어 정확한 도메인 직접 연결과 접미사 프록시는 순서로 예외를 표현하면서 둘 다 유지해야 합니다. 자동 중복 제거 스크립트가 뒤에 나온 항목만 남기면 원래 의도가 바뀔 수 있습니다. 규칙 생성 로직을 수정할 때마다 대표 도메인을 선택해 로그를 확인하고 파일의 행 수만 비교하지 마세요.

해석 오류부터 실행 오류까지의 점검 목록

첫 번째 계층은 YAML 문법입니다. 들여쓰기, 콜론, 하이픈, 따옴표와 데이터 유형을 확인하세요. 두 번째는 구조 참조입니다. 정책 그룹, 노드, 프록시 프로바이더와 규칙 프로바이더 이름을 확인합니다. 세 번째는 리소스 로드입니다. 원격 파일 다운로드 성공 여부, 캐시 쓰기 가능 여부와 behavior 일치 여부를 확인하세요. 네 번째는 실행 환경입니다. 포트 사용 여부, 권한, 시스템 프록시 또는 TUN이 현재 코어를 가리키는지 확인합니다. 다섯 번째 단계에서야 DNS 결과, 규칙 매칭, 정책 그룹 선택과 최종 노드를 확인합니다.

이런 계층적 접근은 하위 단계의 변경으로 상위 단계의 오류를 가리는 일을 막아 줍니다. 예를 들어 포트 충돌이 있을 때 DNS를 수정해도 도움이 되지 않습니다. 정책 그룹이 비어 있을 때 규칙을 더 추가하면 더 많은 트래픽이 빈 그룹으로 들어갈 뿐입니다. 노드의 TLS 매개변수가 잘못됐다면 global 모드로 전환해도 실패합니다. 매번 로그에서는 현재 계층과 관련된 정보만 확인하고, 통과한 뒤 다음 단계로 넘어가야 문제 범위를 점차 좁힐 수 있습니다.

되돌릴 수 있는 수정 절차 만들기

수정할 때마다 이전에 작동했던 설정을 보존하고, 이번 변경으로 어떤 문제 하나를 해결하려는지 기록하세요. 파일 이름에 용도와 수정 번호를 포함할 수 있지만, 여러 디렉터리에 이름은 같고 내용은 다른 복사본을 보관하지는 마세요. 수정 후에는 먼저 문법 로드를 수행하고, 직접 연결 대상 하나, 프록시 대상 하나, LAN 대상 하나와 특수 규칙이 필요한 대상 하나를 테스트하세요. 네 가지 샘플로 대부분의 설정 경로를 확인할 수 있습니다.

클라이언트 업데이트 후 동작이 달라졌다면 구독 내용이 바뀌었다고 바로 단정하지 말고 최종 설정과 코어 로그를 먼저 비교하세요. 클라이언트가 기본 DNS, TUN 스택, 병합 의미 또는 설정 디렉터리를 변경했을 수 있습니다. 핵심 필드를 로컬 오버라이드에 명시하고 용도를 기록하면 기본값 변경으로 인한 불확실성을 줄일 수 있습니다. 다만 더 이상 근거가 없는 오래된 예외는 정기적으로 삭제해야 합니다.

설정 검토를 마친 뒤 사용 튜토리얼의 연결 확인 절차로 돌아가 시스템 프록시, 정책 선택부터 웹페이지 접속까지 전체 흐름을 한 번 진행해 보세요. 그래픽 클라이언트를 바꿔야 한다면 다운로드 페이지에 소개된 Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu 등은 YAML 지원 범위가 서로 완전히 같지 않습니다. 이전하기 전에 현재 설정이 의존하는 코어 필드를 확인하세요. 데스크톱과 모바일 플랫폼의 권장 진입점은 Clash 다운로드 센터에서 확인할 수 있습니다.

신뢰할 수 있는 Clash YAML은 필드가 많다고 좋은 것이 아니라, 각 필드의 용도가 분명하고 모든 참조를 추적할 수 있으며 업데이트마다 설명 가능한 최종 결과를 얻을 수 있는 설정입니다. 구조, 공통 필드, DNS, 노드, 정책 그룹, 규칙, 프로바이더와 오버라이드 순서로 점검하는 것은 글자부터 레이아웃까지 단계별로 교정하는 일과 같습니다. 먼저 문자가 정확한지 확인하고, 다음으로 조합이 올바른지 확인한 뒤, 마지막으로 실제 적용 결과가 예상과 일치하는지 검증하세요.