Clash 설정 파일 완벽 가이드

1. 가이드 개요와 YAML 구조 총정리

Clash 계열 클라이언트(그리고 실행 코어인 mihomo)는 YAML 형식의 설정 파일을 읽어 모든 동작을 결정합니다. 구독 링크의 본질은 서버에 호스팅되어 수시로 업데이트를 받아오는 설정 파일이며, 클라이언트 화면의 모든 스위치도 결국 이 파일의 특정 필드로 귀결됩니다. 구조를 이해하면 구독 내용, 클라이언트 설정 항목, 코어 로그 이 세 가지가 서로 어떻게 대응하는지 한눈에 파악할 수 있어 문제 해결 시 화면을 이리저리 눌러볼 필요가 없습니다.

이 페이지와 사용 가이드의 역할 구분은 「빠른 입문 vs 심도 있는 참고」입니다: 가이드는 구독 가져오기부터 연결 확인까지 전체 흐름을 안내하고, 이 페이지는 그 흐름 밖에서 「이 필드는 무엇을 의미하고 어떻게 더 쓸 수 있는지」를 체계적으로 답합니다. 두 페이지는 서로 보완적이므로 가이드에서 간략히 다룬 필드가 있다면 위 목차를 통해 해당 챕터로 이동하면 됩니다.

최상위 구조: 5가지 블록

완전한 설정 파일은 대략 5개 블록으로 나뉩니다. 파일 안에서의 작성 순서는 해석 결과에 영향을 주지 않지만, 대부분의 구독은 아래 표 순서로 구성되어 있어 다른 사람의 설정을 읽을 때 이 순서를 기준으로 빠르게 위치를 찾을 수 있습니다:

YAML 문법 3대 원칙

YAML은 형식에 매우 민감해서 설정 오류의 90%는 필드 문제가 아니라 문법 문제입니다. 설정을 작성하기 전에 세 가지를 기억하세요: 첫째, 들여쓰기는 오직 공백만 사용해야 하며, Tab 문자 하나만 있어도 파일 전체 해석이 실패할 수 있고 오류 줄 번호는 종종 실제 문제 위치보다 뒤를 가리켜 발견하기 어렵습니다. 둘째, 콜론 뒤에는 반드시 공백이 있어야 합니다. port:7890은 잘못된 표기이고 port: 7890이 올바른 표기입니다. 셋째, 노드 이름에 이모지, 井자, 인용부호가 포함되거나 특수 문자로 시작할 경우 전체 문자열을 큰따옴표로 감싸야 합니다. 그렇지 않으면 주석이나 문법 구조로 잘못 해석될 수 있습니다. 줄 앞의 #는 주석을 의미하며, 디버깅 중 특정 규칙을 임시로 끄고 싶을 때는 삭제하는 대신 줄 앞에 井자를 붙이는 것이 더 안전합니다. 용어가 헷갈릴 때는 용어집의 「구독과 설정」 항목을 참고하세요.

2. 공통 필드: 포트, 모드, 실행 파라미터

공통 필드는 파일 최상위에 위치하며 어떤 들여쓰기 블록에도 속하지 않고, 코어가 어떤 방식으로 동작할지 결정합니다. 아래는 바로 시작점으로 쓸 수 있는 최소 설정 예시입니다:

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

포트 계열: mixed-port와 그 형제들

mixed-port는 현재 가장 널리 쓰이는 포트 필드로, 하나의 포트에서 HTTP와 SOCKS5 두 프로토콜의 인바운드 연결을 동시에 받아들입니다. 시스템 프록시를 이 포트로 지정하면 되며 따로 나눠 설정할 필요가 없습니다. 예전 설정에서 흔히 보이는 port(HTTP 전용)와 socks-port(SOCKS5 전용)도 여전히 유효하며, 두 프로토콜을 서로 다른 프로그램에 나눠 쓰는 경우에 적합합니다. 그 외에 redir-port와 tproxy-port가 있는데, 이는 Linux 투명 프록시나 라우터 배포 환경을 위한 것으로 일반 데스크톱 사용자는 설정할 필요가 없습니다. 포트 값은 1024 이하의 시스템 예약 구간을 피해야 하며, 시작 시 로그에 bind: address already in use가 뜨면 다른 프로그램(대개 종료되지 않은 다른 프록시 프로세스)이 해당 포트를 점유하고 있다는 의미이므로 포트 번호를 바꾸거나 점유 중인 프로세스를 종료하면 됩니다.

mode: 3가지 실행 모드

클라이언트 화면의 「규칙/전역/직결」 전환 버튼이 바로 이 필드를 바꿉니다. 문제 해결 시 먼저 direct로 전환해 로컬 네트워크가 정상인지 확인하고, 그다음 global로 전환해 노드 사용 가능 여부를 확인한 뒤, 마지막으로 rule로 돌아가 규칙을 검토하는 것이 가장 빠른 3단계 진단법입니다.

그 외 자주 쓰는 필드

allow-lan을 true로 설정하면 같은 네트워크의 다른 기기들이 게이트웨이 프록시를 본 기기 포트로 지정해 TV박스, 게임기 등이 프록시를 공유할 수 있습니다. 이를 켤 때는 bind-address로 청취할 네트워크 인터페이스를 제한하는 것을 권장하며, 공용 네트워크에서 낯선 기기에 포트를 노출하지 않도록 주의해야 합니다. log-level은 상세한 순서부터 조용한 순서로 debug, info, warning, error, silent가 있으며, 규칙 매칭 상황을 확인할 때 임시로 debug로 올리면 각 연결이 어떤 규칙에 매칭되었는지 로그에서 확인할 수 있습니다. external-controller는 패널형 도구가 상태를 읽고 노드를 전환할 수 있는 RESTful 인터페이스를 엽니다. secret 필드를 지정하면 인터페이스 접근 시 동일한 키가 필요하며, 예시에서는 항상 secret: "xxxx"처럼 가짜 값을 사용합니다. ipv6은 기본적으로 꺼져 있으며, IPv6 환경이 완전하지 않은 네트워크에서 무턱대고 켜면 오히려 해석 지연이 발생할 수 있습니다.

3. DNS 블록: 해석 모드와 Fake-IP

「규칙을 분명히 제대로 썼는데 작동하지 않는다」, 「일부 사이트가 접속이 되다 안 되다 한다」 같은 문제의 근본 원인은 대부분 DNS에 있습니다. 코어가 자체 DNS 설정을 갖는 이유는 분기 규칙 중 도메인과 지역 판단에 기반한 것이 많기 때문입니다: 이 해석 단계가 오염되거나 코어를 건너뛰게 되면 이후 매칭은 잘못된 답을 기준으로 판단을 내리게 됩니다. 아래는 자주 쓰이는 DNS 블록 예시입니다:

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "+.local"
  nameserver:
    - https://223.5.5.5/dns-query
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

enhanced-mode: fake-ip와 redir-host

fake-ip 모드에서는 코어가 도메인 조회를 받으면 실제 해석을 하지 않고 fake-ip-range로 지정된 예약 대역(기본값 198.18.0.1/16)에서 「가짜 주소」를 바로 반환하며 도메인과 가짜 주소의 매핑을 기억합니다. 앱이 실제로 이 가짜 주소로 연결을 시도하면 코어는 매핑을 통해 도메인을 복원해 규칙 매칭을 진행합니다. 장점은 해석 대기 시간이 줄고 도메인 규칙 매칭률이 매우 높다는 것이며, 대가는 실제 IP에 의존하는 일부 시나리오(LAN 기기 탐색, 일부 게임 온라인 플레이, IP를 반환해야 하는 인증 서비스)에서 가짜 주소를 받아 오류가 날 수 있다는 점입니다. 이것이 바로 fake-ip-filter가 존재하는 이유입니다: 여기 나열된 도메인은 가짜 주소 로직을 건너뛰고 실제 해석 결과를 반환합니다. redir-host 모드는 항상 실제 IP를 반환해 호환성은 더 좋지만 해석 경로가 더 깁니다. 두 모드의 전체 원리 비교는 블로그 글 《Fake-IP 모드란 무엇인가》를 참고하세요.

nameserver와 fallback의 역할 분담

nameserver는 기본 상위 서버로, 보통 지리적으로 가깝고 응답이 빠른 서버를 지정합니다. fallback은 보조 상위 서버로, fallback-filter가 기본 서버의 응답이 의심스럽다고 판단할 때(예: geoip: true일 때 해외 도메인인데 국내 지역 IP로 해석된 경우) 대신 사용됩니다. 상위 주소는 네 가지 표기를 지원합니다: 순수 IP(UDP 53), tls://(DoT), https://(DoH), quic://(DoQ). 암호화 표기를 사용하면 해석 요청이 경로 중간에서 조작되는 것을 방지할 수 있습니다. 주의할 점은 nameserver에는 최소한 직접 해석 가능한 주소가 하나 있어야 한다는 것입니다. 그렇지 않으면 「닭이 먼저냐 달이 먼저냐」 문제가 생깁니다: 프록시 서버 도메인 자체를 해석하는 데도 DNS가 필요하기 때문입니다.

4. 프록시 노드 필드: proxies 항목별 설명

proxies는 각 항목이 하나의 노드를 설명하는 리스트입니다. 평소 구독을 사용할 때 이 부분은 구독 서버에서 생성되므로 직접 작성할 필요는 없지만, 이를 이해하는 것에는 두 가지 실질적 가치가 있습니다: 하나는 노드가 연결되지 않을 때 필드 수준에서 문제를 판단할 수 있다는 점(포트 오류, 전송 계층 파라미터 누락, 암호화 방식 불일치)이고, 다른 하나는 임시로 자체 구축한 노드를 추가할 때 변환 도구 없이도 가능하다는 점입니다. 모든 프로토콜은 네 가지 기본 필드를 공유합니다: name(그룹 내에서 참조하는 고유 식별자, 이름이 중복되면 해석에 실패), type(프로토콜 종류), server, port. udp: true는 해당 노드가 UDP 트래픽을 전달함을 선언하며, 음성 통화나 게임류 앱이 이에 의존합니다.

자주 쓰이는 세 가지 프로토콜의 필드 형태

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

  - name: "예시-VMess"
    type: vmess
    server: node2.example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    alterId: 0
    cipher: auto
    tls: true
    network: ws
    ws-opts:
      path: /ws
      headers:
        Host: node2.example.com

  - name: "예시-Trojan"
    type: trojan
    server: node3.example.com
    port: 443
    password: "your-password"
    sni: node3.example.com

Shadowsocks(ss)의 핵심은 cipher와 password가 서버 측과 완전히 일치해야 한다는 점입니다. 암호화 방식이 한 글자만 달라도 연결이 조용히 실패합니다. VMess는 uuid를 신원 확인용으로 사용하며 alterId는 현재 프로토콜 기준으로 0으로 고정합니다. network는 전송 계층 형태를 결정하며 ws를 선택하면 ws-opts로 경로와 Host 헤더를 함께 지정해야 하고, grpc를 선택하면 grpc-opts가 대응됩니다. Trojan은 기본적으로 TLS 위에서 동작하며 sni가 인증서 도메인과 일치하지 않으면 핸드셰이크가 거부됩니다. 자체 서명 인증서를 사용하는 테스트 환경에서는 skip-cert-verify: true를 추가할 수 있지만 실제 운영에서는 권장하지 않습니다.

mihomo 확장 프로토콜

현재 주류로 쓰이는 실행 코어인 mihomo는 위의 전통적인 프로토콜 외에도 VLESS, Hysteria2, TUIC 등 더 최신 프로토콜을 지원하며, 각각 독립된 필드 집합을 가집니다(예: Hysteria2의 up/down 대역폭 선언). 사용 가능 여부는 클라이언트에 내장된 코어 버전에 따라 달라지는데, 이것이 클라이언트 비교 페이지가 mihomo 코어 기반 클라이언트(전 플랫폼용 Clash Plus, 데스크톱용 Clash Verge Rev 등)를 우선 추천하는 이유 중 하나입니다: 오래된 코어를 사용하는 클라이언트는 새 프로토콜 노드를 만나면 「unsupport proxy type」 오류를 내며 설정 파일 전체 로드를 거부합니다.

5. 정책 그룹 필드: proxy-groups 4가지 유형

proxies가 원재료라면 proxy-groups는 그 원재료를 「결정 단위」로 조직하는 계층입니다: 규칙은 노드를 직접 가리키지 않고 정책 그룹을 가리키며, 그룹 내부 로직(수동 선택 또는 자동 속도 측정)이 최종 출구를 결정합니다. 이 계층 설계 덕분에 「노드를 바꾸는」 작업이 규칙을 건드릴 필요 없이 가능해집니다. 4가지 그룹 유형의 동작은 다음과 같습니다:

proxy-groups:
  - name: "노드 선택"
    type: select
    proxies:
      - 자동 속도 측정
      - 예시-SS
      - 예시-VMess
      - DIRECT

  - name: "자동 속도 측정"
    type: url-test
    url: http://cp.example.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true
    proxies:
      - 예시-SS
      - 예시-VMess

필드 세부 사항과 중첩 기법

자동형 그룹의 url은 204 상태 코드를 반환하는 가벼운 주소를 지정해야 합니다(각 클라이언트에는 기본 측정 주소가 내장되어 있어 입력하지 않으면 기본값이 사용됩니다). interval은 재측정 주기를 초 단위로 지정하며 300이 흔히 쓰이는 값입니다. tolerance는 전환 임계값으로, 신규/기존 노드의 지연 차이가 이 밀리초 값보다 작으면 전환하지 않아 지연이 비슷한 두 라인 사이에서 빈번하게 오가며 연결이 계속 리셋되는 것을 막습니다. lazy: true는 그룹이 사용되지 않을 때 속도 측정을 건너뛰게 해 노드 수가 많을 때 백그라운드 트래픽을 눈에 띄게 줄여줍니다. 그룹의 멤버는 노드 이름뿐 아니라 다른 그룹 이름이나 내장 정책 DIRECT(직결), REJECT(연결 거부)도 될 수 있어 「수동 그룹 안에 자동 그룹」 같은 계층 구조를 만들 수 있습니다: 평소에는 「자동 속도 측정」을 선택해 신경 쓰지 않고, 특수한 시기에는 수동으로 특정 노드에 고정할 수 있습니다. 유일하게 피해야 할 것은 두 그룹이 서로를 참조해 순환을 만드는 경우로, 코어는 시작 시 오류를 내며 로드를 거부합니다. 그룹 이름도 전역에서 고유해야 하며 규칙 원문에서 그대로 참조되므로 그룹 이름을 바꿀 때는 이를 참조하는 모든 규칙 줄도 함께 수정해야 합니다.

6. 규칙 문법: rules 매칭과 우선순위

rules는 분기 결정의 최종 판단 계층입니다. 새 연결이 생성될 때마다 코어는 목록 첫 번째 항목부터 순서대로 비교하며, 매칭되면 즉시 멈추고 이후 규칙은 더 이상 참여하지 않습니다. 따라서 규칙의 작성 순서가 곧 우선순위이며, 같은 규칙이라도 순서를 바꾸면 분기 결과가 완전히 달라질 수 있습니다. 각 규칙의 공통 형식은 유형,매칭값,정책이며, 정책은 그룹 이름, 노드 이름 또는 내장된 DIRECT/REJECT가 될 수 있습니다:

rules:
  - DOMAIN,dl.example.com,노드 선택
  - DOMAIN-SUFFIX,example.org,노드 선택
  - DOMAIN-KEYWORD,tracker,REJECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,fd00::/8,DIRECT,no-resolve
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - RULE-SET,ads,REJECT
  - MATCH,노드 선택

규칙 유형 비교

no-resolve와 정렬 원칙

IP형 규칙은 기본적으로 목적지 IP를 얻기 위해 한 번 도메인 해석을 실행한 뒤 비교합니다. 만약 이 규칙이 「원래부터 IP로 직결되는」 트래픽(예: LAN 대역)만 매칭하려는 의도였다면 이 해석 과정은 순전히 낭비이며 오히려 매 연결을 느리게 만들 수 있습니다. 규칙 끝에 no-resolve 파라미터를 추가하면 「대상이 도메인일 때는 이 규칙을 건너뛴다」고 선언할 수 있습니다. 정렬 원칙은 두 가지입니다: 정확하고 비용이 낮은 것을 앞에 배치(DOMAIN 계열), 해석이나 데이터베이스 조회가 필요한 것을 뒤에 배치(GEOIP). 거부형 규칙은 가능한 앞쪽에 두어 광고 요청이 더 무거운 매칭에 들어가기 전에 걸러지도록 합니다. GEOSITE와 GEOIP의 판단 정확도는 로컬 데이터베이스의 신선도에 따라 달라지며, 데이터베이스가 오래 업데이트되지 않으면 분기 정확도가 떨어집니다. 업데이트 방법은 《GeoIP와 GeoSite 데이터베이스가 만료되면 어떻게 해야 할까》를 참고하세요.

7. 구독과 규칙셋: proxy-providers와 rule-providers

수백 개의 노드와 수만 개의 규칙을 메인 설정 파일에 직접 써넣으면 파일이 비대해지고 업데이트도 어려워집니다. Provider 메커니즘은 이를 독립적으로 가져오고 캐시하며 주기적으로 자동 갱신되는 외부 리소스로 분리합니다: 메인 설정은 「참조」만 담당하고 실제 내용은 원격에서 호스팅됩니다. 이것이 현대 구독 생태계의 표준 형태이며, 사용하는 구독 링크는 대개 proxy-providers 의미에서의 노드 목록입니다.

proxy-providers: 노드 소스 호스팅

proxy-providers:
  main:
    type: http
    url: "https://sub.example.com/subscribe?token=xxxx"
    path: ./providers/main.yaml
    interval: 3600
    health-check:
      enable: true
      url: http://cp.example.com/generate_204
      interval: 600

type: http는 원격에서 가져오는 방식으로 url과 로컬 캐시 경로 path를 함께 지정합니다. type: file은 로컬 파일을 직접 읽는 방식으로 수동으로 관리하는 자체 구축 노드 목록에 적합합니다. interval은 자동 재조회 주기를 초 단위로 지정하며, health-check는 코어가 주기적으로 목록 내 노드의 상태를 체크해 정책 그룹이 필터링에 사용할 수 있게 합니다. 정책 그룹이 Provider의 노드를 사용하려면 proxies 필드 대신(또는 함께) use 필드를 사용합니다:

proxy-groups:
  - name: "구독 노드"
    type: url-test
    use:
      - main
    url: http://cp.example.com/generate_204
    interval: 300

rule-providers: 규칙셋 호스팅

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

규칙셋에서 가장 흔히 겪는 함정은 behavior와 파일 내용이 서로 맞지 않는 경우입니다. 값은 세 가지입니다: domain(파일 전체가 도메인), ipcidr(전체가 네트워크 대역), classical(각 줄이 완전한 「유형,값」 규칙). 원격 파일이 도메인 목록인데 classical로 선언하면 로딩 시 오류는 나지 않지만 한 건도 매칭되지 않아 문제 파악이 매우 헷갈립니다. format은 yaml과 text를 지원하며, mihomo는 크기가 더 작고 로딩이 더 빠른 바이너리 형식 mrs도 지원합니다. 선언된 집합은 RULE-SET,ads,REJECT와 같은 규칙 줄을 통해 메인 규칙표에 연결되며, 규칙셋을 업데이트할 때 더 이상 메인 설정을 바꿀 필요가 없다는 점이 장기 관리 측면에서 가장 큰 가치입니다. 예시의 token=xxxx는 자리표시자 가짜 값이며 실제로는 구독 서비스가 제공하는 완전한 링크를 사용해야 합니다.

8. 오버라이드와 병합: 구독 업데이트가 로컬 수정을 덮어쓰지 않게 하기

구독으로 받은 설정 파일을 직접 수정하면 치명적인 문제가 하나 있습니다: 다음 구독 자동 업데이트 시 원격 내용이 로컬 파일 전체를 덮어써서 손수 추가한 규칙과 수정한 DNS 설정이 모두 사라진다는 점입니다. 오버라이드(Override)와 병합(Merge) 메커니즘은 바로 이 문제를 해결합니다: 「내가 수정한 내용」과 「구독의 내용」을 따로 저장해두고, 매번 구독이 업데이트될 때 클라이언트가 자동으로 수정 사항을 다시 덧씌웁니다. 설정을 바꾸기 전에 먼저 사용 중인 클라이언트가 어떤 메커니즘을 지원하는지 확인하세요:

선언형 병합 작성법

Clash Verge Rev의 Merge를 예로 들면, 병합 파일 자체도 하나의 YAML입니다: 최상위에 직접 쓴 필드(예: mixed-port)는 구독 내 동일 이름 필드를 전체 교체합니다. prepend-/append- 접두사가 붙은 필드는 내용을 구독 내 해당 목록의 맨 앞이나 맨 뒤에 삽입하며, 구독 규칙보다 앞서 자신만의 고우선순위 규칙을 추가할 때 자주 사용됩니다:

mixed-port: 7893

prepend-rules:
  - DOMAIN-SUFFIX,corp.example.com,DIRECT
  - PROCESS-NAME,steam.exe,노드 선택

append-proxies:
  - name: "자체 구축-백업"
    type: ss
    server: node9.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"

「규칙표 맨 앞에 prepend로 삽입」이라는 점은 특히 중요합니다: 규칙은 매칭되면 즉시 멈추므로, 구독 규칙보다 앞에 배치되어야만 내 개인 규칙이 먼저 매칭될 기회를 얻습니다. 딕셔너리형 필드(예: dns)를 병합할 때 전체 교체인지 키 단위 병합인지는 클라이언트 구현에 따라 다소 차이가 있으니, 작성 후 반드시 이미 알고 있는 트래픽으로 효과를 검증하세요. 각 클라이언트의 오버라이드 입구 위치와 조작 차이는 클라이언트 비교 페이지에서 가로 비교로 정리되어 있습니다. Windows에서 설치부터 서비스 모드까지 전체 과정은 《Windows에서 Clash Verge Rev 사용하기》를 참고하세요.

9. 자주 발생하는 오류와 설정 자가진단 체크리스트

설정 로딩에 실패하면 코어 로그가 대개 문제 유형을 이미 짚어주므로, 먼저 로그를 읽고 파일을 수정하면 무작정 시도하는 시간을 크게 줄일 수 있습니다. 자주 발생하는 몇 가지 오류에 대한 대응법: yaml: line N으로 시작하면 문법 오류이므로 N번째 줄 근처의 들여쓰기(특히 섞여 들어간 Tab)와 콜론 뒤 공백을 확인하세요. proxy not found나 proxy group ... not found는 정책 그룹이나 규칙이 존재하지 않는 이름을 참조한다는 뜻으로, 대개 노드 이름을 바꾼 뒤 참조를 동기화하지 않았거나 이름 속 공백·이모지가 완전히 일치하지 않는 경우입니다. unsupport proxy type은 설정에 현재 코어가 인식하지 못하는 프로토콜이 있다는 뜻이므로 클라이언트를 업그레이드하거나 해당 노드를 제거해야 합니다. bind: address already in use는 포트 점유 문제로 2장을 참고하세요. 규칙셋이 「로딩은 성공했지만 전혀 매칭되지 않는다」면 7장에서 다룬 behavior 선언이 내용과 맞지 않는지부터 의심하세요.

설정 변경 전후 7단계 자가진단

1. 변경 전 백업: 현재 정상 작동하는 설정 파일을 복사해두면 어떤 변경이든 문제가 생겼을 때 즉시 되돌릴 수 있어 가장 비용이 낮은 안전장치가 됩니다.
2. 문법 확인: 저장 후 즉시 클라이언트에서 설정을 다시 불러와 로딩이 성공한 후에 효과를 논하세요. 로딩에 실패하면 먼저 로그 줄 번호를 따라 문법을 고치고, 문법 오류를 남겨둔 채 계속 변경을 쌓지 마세요.
3. 이름 일치 확인: 참조된 노드 이름과 그룹 이름을 전체 검색해 proxies, proxy-groups, rules 세 곳의 표기가 인용부호 안 공백까지 정확히 일치하는지 확인하세요.
4. 규칙 순서 검증: MATCH가 마지막 줄에 있는지, 거부형 규칙이 충분히 앞에 있는지, 개인 규칙이 구독 규칙보다 앞에 배치되었는지(오버라이드를 사용할 때는 prepend로 처리되는지) 확인하세요.
5. DNS 동작 검증: Fake-IP를 켠 뒤 LAN 프린터, 화면 미러링 등 로컬 서비스가 정상인지 테스트하고, 정상이 아니면 해당 도메인을 fake-ip-filter에 추가하세요.
6. 3단계 모드 진단: 「연결 안 됨」이 발생하면 먼저 direct로 전환해 로컬 네트워크 문제를 배제하고, 다음으로 global로 전환해 노드 문제를 배제한 뒤, 마지막으로 rule로 돌아가 규칙을 확인하세요. 한 번에 하나의 변수만 바꾸세요.
7. 업데이트 주기 한 번 관찰: 구독이 자동 업데이트된 후에도 오버라이드 내용이 여전히 적용되고, 포트와 DNS 설정이 기본값으로 되돌아가지 않았는지 확인하세요.

체크리스트를 모두 따라도 문제를 찾지 못했다면 사용 가이드로 돌아가 기본 흐름에 빠진 단계가 있는지 확인하세요. 최초 설치 단계의 공통 점검 항목은 《Clash 처음 설치할 때 해야 할 7가지 초기 설정》을 참고하세요. 클라이언트 버전이 너무 오래되면 각종 호환성 문제가 커질 수 있으니 다운로드 페이지에서 최신 버전으로 업데이트한 뒤 다시 테스트하는 것이 문제 해결 과정에서 매우 효율적인 단계입니다.