Clash YAML
설정 파일 참고서

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

수신 포트의 역할 구분

port는 HTTP 프록시 수신을 제공하고, socks-port는 SOCKS5 수신을 제공하며, mixed-port는 하나의 포트에서 HTTP와 SOCKS5를 동시에 받습니다. 데스크톱 그래픽 클라이언트는 보통 mixed-port 하나만 사용하며 시스템 프록시가 자동으로 이 포트를 가리킵니다. 다른 프로그램에서 SOCKS5 주소를 명시적으로 요구한다면 socks-port를 별도로 설정할 수 있습니다. 여러 수신 포트가 같은 포트 번호를 사용하거나 시스템의 다른 서비스와 충돌해서는 안 됩니다.

redir-port와 tproxy-port는 주로 Linux 게이트웨이, 라우터 또는 투명 프록시 규칙에 사용됩니다. 데스크톱 사용자는 ‘더 많은 트래픽을 처리한다’는 이유만으로 임의로 활성화하지 않는 것이 좋습니다. TUN 모드는 별도의 가상 네트워크 카드와 라우팅 처리 경로를 사용하며, 단순히 수신 포트를 하나 추가하는 것과도 다릅니다. 두 가지 트래픽 가로채기 방식을 비교하려면 TUN 모드와 시스템 프록시의 차이를 참고하고, 먼저 트래픽이 어디로 커널에 들어오는지 확인한 뒤 관련 필드를 선택하세요.

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

external-controller: 127.0.0.1:9090
secret: "your-controller-secret"

profile:
  store-selected: true
  store-fake-ip: true

LAN 접근과 바인딩 주소

allow-lan은 다른 기기가 현재 기기의 프록시 포트를 통해 연결할 수 있는지 결정합니다. false로 설정하면 단일 기기 사용에 적합합니다. true로 설정한 뒤에는 운영체제 방화벽, 수신 주소와 LAN 격리 설정도 확인해야 합니다. LAN 접근을 허용한다고 해서 휴대폰이나 TV가 자동으로 프록시를 사용하게 되는 것은 아닙니다. 대상 기기에서 Clash가 실행 중인 기기의 LAN 주소와 수신 포트를 직접 입력해야 합니다. 주소가 바뀌면 연결이 끊길 수 있으므로 장기간 공유할 때는 호스트에 안정적인 LAN 주소를 지정하세요.

bind-address는 수신 범위를 제한합니다. 일부 클라이언트는 ‘LAN 연결 허용’ 스위치에 따라 이 필드를 자동으로 생성하므로, 시작할 때 파일의 값이 화면 설정으로 덮어써질 수 있습니다. 문제를 확인할 때는 실제 수신 주소를 확인해야 합니다. 127.0.0.1만 수신하면 다른 기기가 접근할 수 없고, 모든 인터페이스에서 수신하면 제어 인터페이스와 프록시 포트가 신뢰할 수 없는 네트워크에 직접 노출되지 않도록 해야 합니다. 프록시 수신과 외부 제어 인터페이스는 서로 다른 서비스이므로 혼동하지 마세요.

실행 모드, 로그와 상태 저장

mode: rule은 rules를 위에서부터 순서대로 매칭하는 일상 설정의 기본 모드입니다. global은 트래픽을 전체 정책으로 보내 특정 노드의 사용 가능 여부를 임시로 확인할 때 적합합니다. direct는 요청을 직접 연결해 문제가 프록시 경로 때문인지 확인할 때 사용합니다. 그래픽 클라이언트의 모드 버튼은 실행 중 상태를 바꾸는 경우가 많아 구독 원본 파일에 다시 기록되지 않을 수 있습니다. 따라서 파일의 mode만 보지 말고 클라이언트의 현재 화면도 확인하세요.

log-level은 보통 info를 사용하고, 문제를 해결할 때만 일시적으로 debug로 높인 뒤 복원하세요. 로그가 지나치게 많으면 판단을 방해할 수 있습니다. ipv6은 커널이 IPv6 관련 기능을 처리할지 결정하지만, 로컬 네트워크에 IPv6 라우팅이 없는 문제를 해결해 주지는 않습니다. 활성화 후 연결이 계속 대기한다면 DNS가 IPv6 주소를 반환하는지, 시스템에 사용 가능한 IPv6 출구가 있는지, 규칙이 해당 주소를 포함하는지 확인하세요.

external-controller는 화면과 커널이 통신할 제어 주소를 제공하며, 보통 로컬 루프백 주소에 바인딩합니다. secret은 제어 인터페이스의 접근 인증 정보이므로 예시 값은 반드시 바꿔야 합니다. 이는 프록시 노드 비밀번호가 아니며 원격 연결에도 사용되지 않습니다. profile.store-selected는 정책 그룹 선택을 저장하고, profile.store-fake-ip는 Fake-IP 매핑 상태를 저장합니다. 구독을 업데이트할 때마다 정책 선택이 초기화된다면 YAML만 수정하지 말고 클라이언트 자체의 영속화 옵션도 확인하세요.

프록시 노드 필드와 프록시 제공자

노드 객체의 공통 구조

proxies는 정적 노드 목록입니다. 각 항목에는 최소한 이름, 유형, 서버 주소와 포트가 포함되어야 하며 프로토콜에 따라 인증 및 전송 필드를 추가합니다. name은 전체 설정에서 사용하는 참조 식별자이며 정책 그룹이 이를 통해 노드를 찾습니다. 이름이 중복되면 선택과 오버라이드 결과가 불확실해질 수 있으므로 구독을 병합한 뒤 이름이 고유한지 확인하세요. server는 도메인 또는 IP일 수 있고, port는 서버가 실제로 수신하는 포트와 일치해야 합니다.

프로토콜 유형에 따라 사용할 수 있는 필드가 달라지므로 한 프로토콜의 매개변수를 다른 프로토콜에 기계적으로 복사해서는 안 됩니다. 암호화 방식, 사용자 식별자, 전송 계층, TLS와 서버 이름은 모두 서버 설정과 일치해야 합니다. 클라이언트가 YAML을 불러올 수 있다는 것은 문법과 필드 구조가 기본적으로 유효하다는 뜻일 뿐, 원격 인증이 반드시 성공한다는 뜻은 아닙니다. 로그의 핸드셰이크 실패, 인증 실패, 연결 거부와 시간 초과는 서로 다른 단계를 가리키므로 오류가 발생한 단계에 맞춰 처리해야 합니다.

proxies:
  - name: "SS 테스트 노드"
    type: ss
    server: ss.example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

  - name: "Trojan 테스트 노드"
    type: trojan
    server: trojan.example.com
    port: 443
    password: "your-password"
    sni: service.example.com
    skip-cert-verify: false
    udp: true

  - name: "Hysteria2 테스트 노드"
    type: hysteria2
    server: hy2.example.com
    port: 443
    password: "your-password"
    sni: service.example.com
    skip-cert-verify: false

인증, TLS와 전송 필드

Shadowsocks 노드의 일반적인 필드에는 cipher, password와 udp가 있습니다. 암호화 방식은 서버와 동일해야 하며 이름이 비슷하더라도 서로 바꿔 사용할 수 없습니다. Trojan 계열 노드는 TLS에 의존하고 비밀번호 외에 sni가 필요한 경우가 많습니다. SNI는 핸드셰이크에 사용하는 서버 이름으로, 연결 주소와 같을 수도 있고 서비스 제공자가 별도로 지정할 수도 있습니다. 잘못 입력하면 TCP 연결은 성공해도 TLS 핸드셰이크가 실패할 수 있습니다.

skip-cert-verify는 인증서 검증을 제어합니다. 정상적인 설정에서는 false를 유지하고 서버 이름, 시스템 시간과 인증서 체인 문제를 먼저 수정해야 합니다. true로 바꾸는 것은 인증서 검증이 장애 지점인지 확인할 때만 사용해야 하며 일반적인 해결책으로 삼아서는 안 됩니다. 시스템 시간 오차, 제한된 네트워크의 가로채기와 잘못된 SNI 모두 인증서 관련 오류를 일으킬 수 있습니다. ‘연결 실패’라는 문구만으로는 원인을 판단할 수 없으므로 로그의 핸드셰이크 단계와 함께 확인해야 합니다.

VMess, VLESS, TUIC, Hysteria2 등의 유형에는 사용자 식별자, 네트워크 유형, WebSocket 경로, HTTP 헤더, 흐름 제어 또는 혼잡 제어 필드가 추가될 수 있습니다. 필드 구성은 커널 기능과 서버 배포 방식에 따라 달라집니다. 노드를 수동으로 옮길 때는 원본 구독과 현재 커널 문서를 기준으로 삼고, 다른 노드의 겉모양만 보고 필드를 추가하지 마세요. 원본 Clash, Meta와 mihomo의 이름 및 호환 관계는 커널 버전 선택 안내에서 확인할 수 있습니다.

proxy-providers를 활용한 필요 시 로드

노드가 많거나 원격 업데이트가 필요하다면 proxy-providers를 사용할 수 있습니다. 제공자는 노드 모음이며 정책 그룹이 use로 이를 참조합니다. 일반적인 유형은 HTTP 또는 로컬 파일이고, 원격 제공자에는 주소, 업데이트 간격, 저장 경로와 상태 확인 설정이 포함됩니다. 저장 경로는 클라이언트가 쓰기를 허용하는 위치여야 하며 컨테이너나 서비스 모드에서는 디렉터리 권한도 확인해야 합니다. 원격 주소의 쿼리 매개변수에 접근 인증 정보가 포함될 수 있으므로 공개 로그나 예시 파일에 기록하지 마세요.

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

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

interval은 새로고침 간격이며, 시작할 때마다 반드시 즉시 다운로드한다는 뜻은 아닙니다. 클라이언트에 자체 업데이트 버튼과 캐시 정책이 있을 수도 있습니다. health-check는 고정된 주소로 노드 접근 가능성을 확인하며 그 결과를 화면 표시나 자동 정책 선택에 사용합니다. 하지만 하나의 테스트 주소가 모든 웹사이트에 접근할 수 있음을 보장하지는 않습니다. 테스트가 실패하면 먼저 현재 네트워크에서 테스트 주소에 접근 가능한지 확인한 뒤 노드 장애 여부를 판단하세요.

proxies와 use는 같은 정책 그룹에 함께 사용할 수 있습니다. 전자는 고정 노드나 내장 동작을 나열하고, 후자는 제공자 모음을 가져옵니다. 오버라이드 도구는 이 두 필드를 다르게 처리할 수 있으며, 정적 노드를 추가해도 제공자에 자동으로 포함되지 않을 수 있습니다. 구독 업데이트 후 노드가 사라졌다면 원격 제공자가 정상적으로 새로고침되었는지, 저장 경로에 쓸 수 있는지, 정책 그룹이 여전히 올바른 제공자 이름을 참조하는지 확인하세요.

규칙 문법, 매칭 순서와 규칙 세트

규칙은 위에서 아래 순서로 매칭됩니다

rules는 순서가 있는 목록입니다. 요청이 첫 번째 일치 규칙을 만나면 이후 검사를 중단하므로 구체적인 규칙을 넓은 규칙보다 앞에 배치하고 마지막에는 MATCH로 나머지 트래픽을 처리해야 합니다. MATCH를 맨 위에 두면 뒤의 규칙은 절대 적용되지 않습니다. 넓은 도메인 접미사를 먼저 작성한 뒤 하위 도메인의 예외 규칙을 작성하면 하위 도메인도 앞의 규칙에 의해 먼저 처리됩니다.

규칙은 보통 ‘유형, 매칭 값, 정책 대상’으로 구성되며 일부 규칙에는 추가 매개변수를 붙일 수 있습니다. 쉼표는 필드 구분자이고 정책 이름은 proxy-groups에 존재하거나 DIRECT, REJECT 같은 내장 동작이어야 합니다. 규칙 행의 불필요한 공백이 값의 일부가 될 수 있으므로 수동 편집 시 형식을 일관되게 유지하세요.

rules:
  - DOMAIN,api.example.com,노드 선택
  - DOMAIN-SUFFIX,example.com,노드 선택
  - DOMAIN-KEYWORD,example,노드 선택
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - PROCESS-NAME,example-app.exe,DIRECT
  - GEOIP,CN,DIRECT
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,service-domain,노드 선택
  - MATCH,노드 선택

도메인, 주소와 프로세스 규칙

DOMAIN은 완전한 도메인만 매칭하므로 단일 호스트에 적합합니다. DOMAIN-SUFFIX는 지정된 도메인과 하위 도메인을 매칭하므로 사이트 전체 범위에 적합합니다. DOMAIN-KEYWORD는 도메인에 키워드가 포함되기만 해도 매칭될 수 있어 범위가 가장 넓고 오탐도 가장 쉽게 발생합니다. 완전한 도메인을 사용할 수 있다면 키워드를 사용하지 말고, 명확한 접미사를 사용할 수 있다면 너무 짧은 문자열을 작성하지 마세요.

IP-CIDR와 IP-CIDR6는 대상 주소 대역으로 매칭합니다. LAN, 컨테이너 네트워크와 회사 내부망은 보통 직접 연결을 우선하지만 주소 범위가 실제 네트워크와 일치해야 합니다. no-resolve는 매칭을 위해 IP를 얻으려고 도메인을 추가로 해석하지 않도록 하며 불필요한 DNS 조회를 줄일 수 있습니다. 이미 존재하는 IP 트래픽을 차단한다는 뜻도 아니고 앱이 이미 완료한 해석을 바꾸지도 않습니다.

PROCESS-NAME과 프로세스 경로 규칙은 플랫폼 기능, 권한과 트래픽 가로채기 방식에 의존합니다. 시스템 프록시 모드에서는 모든 트래픽의 프로세스 정보를 안정적으로 얻을 수 없고, 모바일 플랫폼도 같은 프로세스 규칙을 지원하지 않을 수 있습니다. 여러 플랫폼에서 사용할 설정이라면 도메인과 주소 규칙을 기반으로 삼고 프로세스 규칙은 특정 기기의 보조 기능으로 사용하세요. 데스크톱에서는 적중하지만 휴대폰에서는 적중하지 않는다면 먼저 해당 규칙 유형이 플랫폼 간 호환되는지 확인하세요.

GEOIP는 IP 데이터베이스에 따라 분류하고, GEOSITE 또는 규칙 세트는 도메인 모음에 따라 분류합니다. 실제 사용 가능 여부는 커널과 데이터 파일에 따라 달라집니다. 데이터베이스 규칙은 넓은 범위를 다루기 편하지만 분류 데이터에는 업데이트 주기가 있으므로 명확한 업무 규칙을 대신할 수 없습니다. 특정 도메인을 반드시 지정된 정책으로 보내려면 데이터베이스 규칙보다 앞에 정확한 규칙을 배치하세요.

rule-providers로 대규모 규칙 세트 관리

규칙이 많다면 rule-providers에 넣는 것이 적합합니다. 각 제공자에는 이름, 유형, 동작, 출처, 저장 경로와 업데이트 간격이 필요합니다. behavior는 콘텐츠 형식을 결정하므로 도메인 모음, IP 주소 대역과 기존 규칙 행을 서로 섞을 수 없습니다. 제공자 다운로드가 성공했다고 해서 자동으로 분기에 참여하는 것은 아닙니다. rules에서 같은 이름의 RULE-SET을 사용해야 합니다.

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

  service-domain:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/service-domain.yaml

rules:
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,service-domain,노드 선택
  - MATCH,노드 선택

domain 동작은 도메인 또는 도메인 접미사 모음에 적합하고, ipcidr은 주소 대역에 적합하며, classical은 기존 규칙 표현식을 허용합니다. 원격 콘텐츠 형식은 선언과 일치해야 합니다. 제공자 파일 자체에 완전한 payload 구조가 포함되어 있다면 저장 후 커널이 해당 형식에 맞춰 읽습니다. 일반 구독 파일을 규칙 세트로 잘못 지정하면 해석 단계에서 오류가 발생합니다.

규칙 세트 새로고침이 실패하면 먼저 네트워크 요청 상태를 확인한 다음 저장 디렉터리 권한과 파일 형식을 확인하세요. 이전 캐시가 계속 작동할 수 있으므로 ‘현재 접속 가능하다’는 사실만으로 업데이트 성공을 증명할 수 없습니다. 서비스 모드에서 상대 경로는 실행 디렉터리나 클라이언트 설정 디렉터리를 기준으로 하며 YAML 파일이 있는 디렉터리를 기준으로 하지 않을 수 있습니다. 기기를 옮긴 뒤 규칙 제공자가 작동하지 않는다면 경로 차이가 흔한 원인입니다.

결과를 추측하지 말고 규칙 적중을 확인하기

클라이언트 연결 기록에는 보통 대상 도메인, 적중한 규칙과 최종 정책이 표시됩니다. 테스트할 때는 브라우저의 기존 연결을 끊거나 새 요청을 사용해야 합니다. 연결을 재사용하면 이전 정책이 계속 적용될 수 있습니다. 규칙을 수정한 뒤 설정을 다시 불러오고 새 연결이 새 규칙에 적중하는지 확인하세요. 웹페이지가 열리는지만 봐서는 직접 연결인지 프록시인지 구분할 수 없습니다.

사용자 지정 규칙은 소수의 정확한 항목부터 시작하세요. 먼저 명확한 도메인 규칙 하나를 작성해 적중을 확인한 다음 접미사나 규칙 세트로 범위를 단계적으로 넓히세요. 새 규칙 때문에 많은 웹사이트에 문제가 생기면 너무 짧은 키워드, 지나치게 넓은 주소 대역 또는 앞쪽에 배치된 MATCH가 있는지 즉시 확인하세요. 규칙 분기의 핵심은 개수가 아니라 순서가 명확하고 대상이 존재하며 범위를 설명할 수 있는지에 있습니다.

설정 검사, 로드 절차와 장애 단계 구분

먼저 문법을 확인한 다음 네트워크를 확인하기

설정 장애는 파일 인코딩과 YAML 문법, 필드 구조와 참조, 수신 포트, DNS, 노드 연결, 정책 그룹, 규칙 적중, 앱 가로채기 순서로 처리해야 합니다. 이전 단계가 통과되지 않았다면 다음 단계로 넘어가지 마세요. 문법 오류는 전체 설정을 로드하지 못하게 하지만 노드 오류는 해당 연결에만 영향을 주고, 규칙 오류는 트래픽을 잘못된 정책으로 보낼 수 있습니다. 장애 범위를 구분해야 모든 설정을 목적 없이 바꾸는 일을 피할 수 있습니다.

그래픽 클라이언트에는 보통 설정 검사 또는 다시 불러오기 버튼이 있습니다. 서버와 명령줄 환경에서는 현재 커널이 제공하는 테스트 매개변수를 사용할 수 있지만, 실행 파일 이름과 매개변수는 설치 패키지의 안내를 기준으로 해야 합니다. 검사 명령은 실제 설정 디렉터리를 가리켜야 합니다. 상대 경로가 잘못되면 같은 이름의 다른 파일을 검사할 수 있습니다. ‘설정이 유효함’이 표시된 뒤에도 시작 로그를 확인하세요. 포트 충돌, 디렉터리 권한과 네트워크 연결은 실행 단계의 문제이기 때문입니다.

# 실제 설정 디렉터리로 이동한 다음 현재 커널의 설정 검사 매개변수를 호출하는 예시
cd /path/to/clash-config
mihomo -t -d .

# 로컬 포트가 이미 사용 중인지 확인할 때는 운영체제에 맞는 도구를 사용
# Linux
ss -lntup

# Windows PowerShell
Get-NetTCPConnection -State Listen

해석 오류가 자주 발생하는 위치

오류에 줄 번호가 포함되어 있다면 해당 줄과 그 위의 몇 줄을 함께 확인하세요. YAML 파서는 계속 해석할 수 없게 된 시점에 오류를 표시하는 경우가 많아 실제 원인은 이전 줄의 닫히지 않은 따옴표, 콜론 뒤의 공백 누락 또는 목록 들여쓰기 중단일 수 있습니다. 매핑 키가 중복되었다는 메시지가 나오면 같은 수준의 동일한 필드를 검색하세요. 유형이 맞지 않는다는 메시지가 나오면 원래 목록이어야 할 위치에 하이픈이 빠졌는지, 정수가 객체로 잘못 작성되지 않았는지 확인하세요.

채팅 앱이나 서식 있는 텍스트에서 복사한 내용에는 전각 콜론, 굽은 따옴표, 줄 바꿈 없는 공백과 보이지 않는 문자가 포함될 수 있습니다. 가장 안전한 방법은 일반 텍스트 편집기에서 문제가 된 줄을 다시 입력하는 것입니다. 한글 정책 그룹 이름은 정상적으로 사용할 수 있지만 구두점은 일반적인 반각 YAML 구분 기호를 사용해야 합니다. 주석은 샵으로 시작해야 하며 유효한 값과 적절한 공백을 두어야 합니다.

설정을 해석할 수 있지만 대상이 없다는 메시지가 나오면 노드 이름, 제공자 이름, 정책 그룹 이름과 규칙 세트 이름을 확인하세요. 정책 그룹이 구독 업데이트로 이름이 바뀐 노드를 참조하거나, 규칙이 오버라이드로 삭제된 그룹을 가리키거나, RULE-SET 이름과 제공자 키가 일치하지 않는 경우가 흔합니다. 이름을 검색할 때는 따옴표 안의 전체 텍스트를 포함하고 끝의 공백과 비슷하게 생긴 문자를 주의하세요.

포트, 시스템 프록시와 TUN 확인 경로

클라이언트는 실행 중으로 표시되지만 앱이 인터넷에 연결되지 않는다면 먼저 수신 포트가 존재하는지 확인한 뒤 시스템 프록시 주소를 대조하세요. YAML의 mixed-port를 새 값으로 바꿨는데 시스템 프록시가 여전히 이전 값을 가리키면 브라우저 연결은 즉시 실패합니다. 시스템 프록시를 따르지 않는 앱만 연결되지 않는다면 기본 프록시는 정상일 가능성이 있으므로 노드 프로토콜을 계속 수정하기보다 TUN 사용을 검토해야 합니다.

TUN을 켠 뒤 인터넷이 완전히 끊기면 권한, 가상 네트워크 카드, 라우팅, DNS 가로채기와 다른 네트워크 프로그램의 충돌을 확인해야 합니다. 먼저 TUN을 끄고 시스템 프록시 경로가 작동하는지 확인한 뒤 TUN을 별도로 처리하세요. 클라이언트를 종료한 뒤에도 인터넷이 되지 않으면 시스템 프록시가 켜진 채 남아 있는지, 가상 네트워크 카드의 라우팅이 복구되었는지 확인합니다. 같은 테스트에서 여러 프록시 클라이언트를 동시에 켜지 마세요. 시스템 프록시, 포트와 라우팅을 서로 차지하려 할 수 있습니다.

노드 사용 가능성과 규칙 적중 확인

노드 테스트가 실패하면 DNS 해석 실패, TCP 연결 시간 초과, 연결 거부, TLS 핸드셰이크 실패와 인증 실패를 먼저 구분하세요. 해석 실패는 노드 서버 도메인과 proxy-server-nameserver를 확인하고, 시간 초과는 네트워크와 원격 주소를 확인해야 합니다. 거부는 보통 대상 포트가 연결을 받지 않는다는 뜻이고, 핸드셰이크 실패는 시스템 시간, SNI와 인증서를 확인해야 하며, 인증 실패는 비밀번호, 사용자 식별자와 프로토콜 필드를 확인해야 합니다. 오류가 다르면 해결 방법도 달라야 합니다.

노드 테스트는 성공하지만 대상 웹사이트에 접속할 수 없다면 연결 기록에서 적중 규칙과 정책을 확인하세요. DIRECT에 적중했다면 규칙 순서나 모드에 문제가 있을 수 있습니다. 예상한 노드에 적중했다면 대상 도메인 해석, 노드 출구와 웹사이트 측 제한을 계속 확인하세요. 전체 모드로 임시 전환하면 규칙 문제인지 구분하는 데 도움이 되지만 테스트 후에는 규칙 모드로 되돌려야 합니다. 전체 모드에서 접속된다고 해서 원래 규칙이 올바르다는 뜻은 아니며, 특정 프록시 경로가 사용 가능하다는 뜻일 뿐입니다.

최소 작동 설정 만들기

복잡한 설정에서 원인을 찾기 어렵다면 포트 하나, 노드 하나, 수동 정책 그룹 하나와 규칙 두 개로 시작하세요. 설정을 불러오고 연결할 수 있는지 확인한 뒤 DNS, 자동 정책, 규칙 제공자와 TUN을 차례로 추가합니다. 계층을 하나 추가할 때마다 작동하는 사본을 저장하세요. 수천 줄의 구독 설정에서 계속 추측하는 것보다 빠르고, 클라이언트와 커널이 실제로 지원하는 필드도 명확히 알 수 있습니다.

최소 설정 테스트에 사용하는 노드는 정보가 완전한지 확인해야 하며 테스트 도메인도 안정적이어야 합니다. 최소 설정에서도 실패한다면 문제는 규칙 세트보다 노드, 시스템 네트워크, 권한 또는 클라이언트 설치에 있을 가능성이 큽니다. 이때는 사용 가이드로 돌아가 초기화 절차를 확인하거나 구독, 모드와 연결 상태에 관한 10가지 질문을 참고하세요. 다시 설치해야 한다면 다운로드 센터에서 해당 플랫폼을 선택하고, 데스크톱과 모바일 모두 Clash Plus를 우선 확인하세요.

문제 해결이 끝나면 임시로 사용한 debug 로그, 넓은 테스트 규칙과 인증서 검증 변경을 정상 설정으로 되돌리세요. 더 이상 사용하지 않는 포트, 중복 정책 그룹과 만료된 제공자를 삭제하고 사용자 지정 부분에는 짧은 주석을 남기세요. 설정의 장기적인 유지 관리성은 필드 수가 아니라 각 모듈의 역할이 명확한지에 달려 있습니다. 각 규칙이 존재하는 이유, 각 그룹이 참조하는 대상, 각 DNS 해석기의 역할을 설명할 수 있어야 지속적으로 업데이트할 수 있는 설정입니다.

작동하는 설정에서 계속하기

아직 클라이언트를 설치하지 않았다면 먼저 플랫폼에 맞는 설치 패키지를 받으세요. 설치는 완료했지만 화면 조작이 익숙하지 않다면 빠른 시작 절차에 따라 구독을 가져오고 정책을 선택한 뒤 연결을 확인하세요.

다운로드 센터로 이동 사용 가이드 보기